Kiểm Chứng, Thẩm Định và Kiểm Thử (Verification, Validation, and Testing

)

Mục đích
Sau buổi học sinh viên phải nắm được:

− − − − −

Hiểu các khái niệm: verification, valdation, và testing Nắm được các nguyên lý về kiểm thử Hiểu khái niệm ca kiểm thử (test case) Các phương pháp thiết kế test case Làm thế nào để kiểm thử chương trình Làm thế nào để kiểm thử hệ thống

2

Nội dung
Giới thiệu

Verification,Validation, và Testing

Các nguyên lý về kiểm thử Ca kiểm thử (test case) Các kỹ thuật kiểm thử chương trình
− −

Kiểm thử chức năng Kiểm thử cấu trúc

Các giai đoạn và chiến lược kiểm thử

3

Tài liệu
Pressman, Software Engineering, McGraw Hill (chapter 18 & 19) Sommerville, Software Engineering, Addison-Wesley (chapter 22 & 23) Giáo trình kỹ nghệ phần mềm (chương 5) Các tài liệu điện tử khác

4

Verification,Validation, và Testing
Kiểm chứng (Verification)
− −

có đúng đặc tả không, có đúng thiết kế không phát hiện lỗi lập trình có đáp ứng nhu cầu người dùng không có hoạt động hiệu quả không phát hiện lỗi phân tích, lỗi thiết kế (lỗi mức cao) mục tiêu là phát hiện và sửa lỗi PM, đánh giá tính dùng được của PM

Thẩm định (Validation)
− − −

V&V = Verification and Validation

Thứ tự thực hiện: Verification -> Validation
5

Testing) − − − − − .Kiểm chứng/Thẩm định tĩnh và động Kiểm chứng/Thẩm định tĩnh − − − − không thực hiện chương trình xét duyệt yêu cầu. mã nguồn tiến hành ở mọi công đoạn phát triển khó đánh giá tính hiệu quả của sản phẩm thực hiện chương trình cần có mã nguồn phát hiện lỗi lập trình đánh giá tính hiệu quả phần mềm là cách duy nhất để kiểm tra yêu cầu phi chức năng 6 Kiểm chứng/Thẩm định động (kiểm thử . thiết kế.

Mô hình phát triển “V” Đặc tả yêu cầu Đặc tả hệ thống Thiết kế hệ thống Thiết kế chi tiết Kế hoạch kiểm thử chấp nhận Kế hoạch kiểm thử tích hợp HT Kế hoạch kiểm thử tích hợp HT con Mã hóa mô đun & kiểm thử mô đun Dịch vụ Kiểm thử chấp nhận Kiểm thử tích hợp hệ thống Kiểm thử tích hợp các hệ thống con 7 .

Kiểm thử phần mềm (Testing) Tập các hoạt động với mục đích khám phá các lỗi và khuyết tật/khiếm khuyết Mục đích của kiểm thử: − − Thiết kế các ca kiểm thử (test cases) với khả năng tìm kiếm các lỗi/khuyết tật Thực hiện chương trình với mục đích tìm các lỗi/khuyết tật một lỗi được phát hiện một kết quả chỉ ra sự thất bại của thủ tục kiểm thử được trả lại 8 Mỗi phép kiểm thử (a test) chỉ thành công khi − − .

Các loại kiểm thử phần mềm Kiểm thử tìm khuyết tật − − − tìm lỗi lập trình tiến hành dựa trên phân tích đặc tả chức năng. phân tích mã nguồn đánh giá tính dùng được của sản phẩm sử dụng dữ liệu thực (dựa trên thống kê) số người truy cập số giao tác cơ sở dữ liệu lớn Kiểm thử thống kê − − − − − 9 .

Yêu cầu đối với kiểm thử Tính lặp lại − − kiểm thử phải lặp lại được (kiểm tra xem lỗi đã được sửa hay chưa) dữ liệu/trạng thái phải mô tả được đảm bảo kiểm tra hết các trường hợp (coverage) kiểm soát tiến trình/kết quả 10 Tính hệ thống − Được lập tài liệu − .

Các nguyên lý kiểm thử PM Các phép kiểm thử phải tương ứng với các yêu cầu của HT Mỗi phép kiểm thử nên được lập kế hoạch từ rất sớm trước khi tiến hành kiểm thử Qui luật Pareto hay qui luật 80/20 (qui luật thiểu số quan trọng và phân bố nhân tố) − − khoảng 80% kết quả là do 20% nguyên nhân gây ra “80% of all errors uncovered during testing will likely be traceable to 20% of all program modules or classes” 11 .

Ca kiểm thử (test case) Ca kiểm thử: dữ liệu để kiểm tra hoạt động của chương trình Ca kiểm thử tốt − được thiết kế để phát hiện một lỗi của chương trình Kiểm thử thành công: phát hiện ra lỗi Mục đích: − − Chứng minh được sự tồn tại của lỗi Không chứng minh được sự không có lỗi 12 .

. xâu kí tự. màn hình.... file.Nôi dung của test case Tên mô đun/chức năng muốn kiểm thử dữ liệu vào − − − dữ liệu thông thường: số. xâu kí tự... thời gian phản hồi Kết quả mong muốn − − Kết quả thực tế 13 .. thứ tự thao tác (khi kiểm thử giao diện) thông thường: số. OS. file.. môi trường thử nghiệm: phần cứng..

Các kỹ thuật kiểm thử chương trình Kiểm thử chức năng (functional testing) − − − dựa trên đặc tả chức năng phát hiện các sai sót về chức năng không quan tâm đến cách cài đặt kiểm thử có nghiên cứu mã nguồn phân tích thứ tự thực hiện các lệnh Kiểm thử cấu trúc (structured testing) − − 14 .

… 15 .Kiểm tra tính hiệu quả .Kiểm thử chức năng Functional testing / Black box testing Dựa trên đặc tả chức năng • Test case được thiết kế để kiểm tra chức năng • Phát hiện các khiếm khuyết so với đặc tả • Không quan tâm đến cách cài đặt (mã nguồn) . thiếu sót chức năng .Phát hiện lỗi khởi tạo.Sai sót về giao diện của mô đun . lỗi kết thúc.Phát hiện sai sót.

Phân hoạch tương đương Equivalence partitioning • Không thể kiểm thử mọi trường hợp • Chia dữ liệu thành các miền có cùng hành vi • Tạo một test case cho từng miền • Tạo test case cho biên của các miền .nhiều lỗi xuất hiện với giá trị biên 16 .

Phân hoạch tương đương .Ví dụ Hàm tính trị tuyệt đối .miền dữ liệu < 0 Input 100 -20 0 Expected Output 100 20 0 17 .miền dữ liệu ≥ 0 .

dữ liệu ngẫu nhiên 18 . -32768) .số âm.biên của số trong máy tính (vd. 32767.số không (0) .dữ liệu sai kiểu . số thập phân .Mở rộng các test case Tạo test case cho các trường hợp đặc biệt .

vòng lặp • Phù hợp với các mô đun nhỏ • Là sự bổ sung cho kiểm thử chức năng 19 .Kiểm thử cấu trúc Structural testing / White box testing • Xây dựng ca kiểm thử dựa trên phân tích mã nguồn • Xây dựng bộ test case để kiểm tra mọi dòng lệnh • Phân tích các lệnh rẽ nhánh.

Đường đi trong mô đun • Phân tích mô đun để xác định đường đi • Đường đi là thứ tự thực hiện các lệnh từ điểm bắt đầu đến điểm kết thúc của mô đun • Thiết kế các test case để kiểm thử mọi đường đi 20 .

câu lệnh điều kiện .đánh số các hợp điểm của luồng lệnh • Rút gọn flow chart (đồ thị) .tích hợp khối tuần tự vào câu lệnh điều kiện kế tiếp 21 .các khối tuần tự được tích hợp thành một khối .Xác định đường đi • Đánh số các khối lệnh .đánh số các khối lệnh.

Start 1 2 11 End 6 7 9 8 10 3 0 4 5 22 .

1 đường đi: 1-2-3-8-1-9 1-2-4-6-7-8-1-9 9 4 2 3 5 7 8 23 6 .

mọi điều kiện đều được kiểm thử với hai trường hợp true và false 24 .Đường đi độc lập • Không thể chọn mọi đường đi .mọi khối lệnh đều được thực hiện ít nhất một lần .có ít nhất một cặp khối lệnh (một cạnh của đồ thị) chưa xuất hiện trong các đường đi đã có • Bộ các đường đi độc lập là một tập hợp thỏa mãn .chọn các đường đi độc lập • Đường đi độc lập .

1 2 4 3 5 7 8 6 Đường đi độc lập: 1-9 1-2-3-8-1-9 1-2-4-6-7-8-1-9 1-2-4-5-7-8-1-9 9 25 .

Đường đi độc lập có thể tồn tại nhiều bộ đường đi độc lập số đường đi tối thiểu cần kiểm tra = độ phức tạp thuật toán 26 .

Số miền của đồ thị G 2. V(G) = P + 1 P: số các nút điều kiện 27 . V(G) = E .N + 2 E: số cạnh N: số đỉnh 3.Độ phức tạp thuật toán Độ phức tạp V(G) của flow chart G: 1.

1 2 4 3 5 7 8 6 9 Số cạnh E = 11 Số đỉnh N = 9 Số điều kiện = 3 Số miền = 4 Độ phức tạp: 4 28 .

Độ phức tạp thuật toán Độ phức tạp lớn thì xác suất xuất hiện lỗi cao không nên tạo các mô đun có độ phức tạp > 10 phân rã mô đun (tạo các mô đun thứ cấp để giảm độ phức tạp) 29 .

đảm bảo mọi lệnh đều được kiểm tra . Cấu trúc • Kiểm thử chức năng .thuận tiện với các mô đun lớn.Chức năng vs.hiệu quả với các mô đun nhỏ. tích hợp • Kiểm thử cấu trúc . đơn lẻ 30 .kiểm tra tính hiệu quả của phần mềm .

Kiểm thử và gỡ rối Kiểm thử và gỡ rối là hai công việc phân biệt Kiểm thử nhằm phát hiện sự tồn tại của lỗi Gỡ rối nhằm định vị và sửa chữa mã gây lỗi Gỡ rối bao gồm việc sinh ra các giả thiết về hoạt động của chương trình và kiểm thử chương trình để tìm lỗi 31 .

Tiến trình gỡ rối Test results Specification Test cases Locate error Design error repair Repair error Re-test program 32 .

khóa tìm kiếm k (số nguyên) output: vị trí của k trong mảng a[] nếu có.mảng số nguyên a[] đã sắp xếp . -1 nếu không có 33 .Mini test Tạo test case (dựa trên phân hoạch tương đương) cho hàm tìm kiếm sau: input: .

không có trong mảng + nhỏ hơn.lớn hơn 1 Khóa tìm kiếm: .0.có trong mảng + phần tử đầu tiên. cuối cùng + phần tử ở vị trí bất kỳ 34 . lớn hơn + xen kẽ .Tạo test cases cho hàm tìm kiếm nhị phân Số phần tử của mảng: . 1 .

Tạo test cases cho hàm tìm kiếm nhị phân Số p.tử Mảng 0 1 1 1 4 4 4 4 4 4 10 10 10 3 3 3 3 3 3 Khóa 7 20 3 10 1 30 8 3 20 7 Kết quả -1 -1 -1 0 -1 -1 -1 0 3 1 35 7 7 7 7 7 7 10 10 10 10 10 10 20 20 20 20 20 20 .

Validation. và Testing Các nguyên lý về kiểm thử Ca kiểm thử (test case) Các kỹ thuật kiểm thử chương trình − − Kiểm thử chức năng Kiểm thử cấu trúc Các giai đoạn và chiến lược kiểm thử 36 .Nội dung Giới thiệu − Verification.

beta testing Kiểm thử hệ thống 37 .Các giai đoạn kiểm thử Kiểm thử đơn vị Kiểm thử tích hợp top-down − bottom-up − Kiểm thử chấp nhận − alpha.

cấu trúc dữ liệu điều kiện biên.. chương trình riêng lẻ • Người tiến hành: thường là người lập trình • Sử dụng các stubs và drivers • Phối hợp giữa kiểm thử cấu trúc và kiểm thử chức năng .Kiểm thử đơn vị Unit testing • Kiểm thử các mô đun...kiểm tra câu lệnh điều kiện. • Tài liệu thường sơ sài 38 .

Kiểm thử đơn vị driver Module giao diện cấu trúc dữ liệu điều kiện biên đường đi độc lập xử lý lỗi test cases stub stub RESULTS 39 .

Ví dụ sử dụng stub • Kiểm thử mô đun calender() có gọi đến mô đun tính ngày • trong tuần calc_day()chưa được phát triển. cần kiểm thử calc_day() chưa phát triển 40 . calender() đã phát triển.

năm .Ví dụ sử dụng stub Mô đun tính ngày trong tuần calc_day(): .input: ngày. } 41 .output: trả xâu kí tự là thứ của ngày đã cho String calc_day(Date d) { return "Sunday". tháng.

có thể thay thế dữ liệu cố định bằng cách nhập kết quả trực tiếp từ bàn phím. String calc_day(Date d) { String s. cin >> s.Ví dụ sử dụng stub Để tăng độ thích nghi. } 42 . return s. cout << ”Enter day_of_week of ”<< d.

s = calc_day(d). String s. cout << s << endl. cin >> d. } } 43 . while (1) { cout << ”Enter date: ”).Ví dụ về test drive Test drive để thử nghiệm calc_day() void calc_day_test_drive() { Date d.

• Các unit được thêm vào theo một trong 2 chiến lược top-down hoặc bottom-up • Mục đích: ..kiểm tra tính hiệu quả • Thường sử dụng kiểm thử chức năng • Được lập tài liệu 44 .kiểm tra giao diện giữa các unit .kiểm tra tính đúng đắn so với đặc tả . người thiết kế..Kiểm thử tích hợp Intergration testing • Kiểm thử tích hợp các unit • Người tiến hành: người lập trình.

Các chiến lược tích hợp Kiểm thử trên xuống (top-down) Kiểm thử dưới lên (bottom-up) Kiểm thử quay lui (regression) 45 .

có cùng giao diện .có cùng tên với mô đun thật .trả lại kết quả với một hoặc một vài bộ dữ liệu chuẩn 46 .Kiểm thử trên xuống Top-down testing Các mô đun mức trên được kiểm thử trước Các mô đun thuộc cấp được thay bằng bằng các mô đun tạm thời (stub function) .

Kiểm thử trên xuống A Top module được kiểm thử trước với các stubs G B F C Các stubs được thay thế từng cái một E D Mỗi khi một module mới được tích hợp một số ca kiểm thử được thực hiện lại (kiểm thử quay lui) 47 .

thao tác với cấu trúc dữ liệu phức tạp .Ưu nhược điểm của top-down Ưu điểm: Phát hiện sớm các lỗi thiết kế (lỗi cấu trúc) .) 48 . .có thể thẩm định tính dùng được của sản phẩm sớm Nhược điểm Nhiều mô đun cấp thấp rất khó mô phỏng . ảnh..kiểm thử trên xuống kết hợp với phát triển trên xuống sẽ giúp phát hiện sớm các lỗi thiết kế và làm giảm giá thành sửa đổi Có sớm phiên bản thực hiện được .trả lại kết quả phức tạp (con trỏ.phiên bản thực hiện với các chức năng chính có sớm ..

truyền dữ liệu .hiển thị kết quả Thay thế dần các drive 49 .Kiểm thử dưới lên .gọi mô đun cần thử nghiệm .bottom-up testing Các mô đun cấp thấp được kiểm thử trước Mô đun mức trên được thay thế bằng mô đun điều khiển (test driver). có chức năng .

Kiểm thử dưới lên A B F K Thay thế các driver từng cái một C G D E H I cluster cluster Các module mức thấp được tích hợp trước 50 .

Ưu nhược điểm của bottom up • Ưu điểm .Thuận tiện cho phát triển các mô đun để dùng lại • Nhược điểm .Tránh sinh các kết quả nhân tạo (nhập từ bàn phím) .Chậm có phiên bản thực hiện 51 .Tránh xây dựng các mô đun tạm thời (stub) phức tạp .Chậm phát hiện các lỗi kiến trúc .

Top down vs. Bottom up Mỗi chiến lược đều có ưu nhược điểm riêng Chiến lược kiểm thử phải phù hợp với chiến lược phát triển phát triển top-down = top-down testing − phát triển bottom-up = bottom-up testing − Có thể phối hợp các chiến lược: Sandwich testing 52 .

sai sót. thiếu sót so với yêu cầu người dùng • Sử dụng các dữ liệu thực do user cung cấp • Kiểm thử chấp nhận tiến hành ở môi trường khách hàng được gọi là alpha testing 53 .Kiểm thử chấp nhận Acceptance testing • Có sự tham gia của khách hàng/người sử dụng • Dùng kiểm thử chức năng • Mục đích: thẩm định (validation) phần mềm .

thông báo lại kết quả cho người phát triển 54 .Kiểm thử beta • Mở rộng của alpha testing • Được tiến hành với một lượng lớn users • User tiến hành kiểm thử không có sự hướng dẫn của người phát triển.

Kiểm thử hệ thống Mở rộng phạm vi kiểm thử. nhìn nhận phần mềm là một yếu tố trong một HTTT phức tạp Kiểm tra các yếu tố khả năng phục hồi sau lỗi − độ an toàn − hiệu năng và giới hạn của phần mềm − 55 .

tệp kích thước lớn… • Nghiên cứu: mức tới hạn của hệ thống (mức tải khiến hệ thống ngừng hoạt động) phản ứng của hệ thống khi đạt mức tới hạn + biến thiên của thời gian phản hồi + độ an toàn của dữ liệu. phần cứng..Kiểm thử gây áp lực . phần mềm. số giao dịch lớn... các tổ hợp điều kiện khiến hệ ngừng hoạt động + OS.số người sử dụng lớn...Stress Testing Sử dụng các dữ liệu lớn . 56 ..

Sign up to vote on this title
UsefulNot useful