14/9/2009 1 Chương 5 Kiểm thử Kiểm thử phần mềm Tổng quan — Mặc dù được tự động hoá một phần bởi các công cụ, rất nhiều công đoạn trong quá trình sản xuất phần mềm vẫn được thực hiện bởi con người — Lỗi có thể xảy ra trong tất cả các giai đoạn: phân tích yêu cầu, thiết kế, mã hoá — Do đó phải kiểm thử chương trình trước khi chính thức sử dụng — Kiểm thử phần mềm là hoạt động thực thi chương trình với mục đích tìm ra lỗi Kiêm thử phần mềm – tổng quan — Có 2 kiểu lỗi trong ứng dung: — Không làm những điều phải làm: lỗi bỏ sót, thường xuất hiện ở các ứng dụng mới phát triển. — Làm những điều không cần làm: lỗi của các lệnh đã cư trú trong các ứng dụng bão trì. — Có 2 loại kiểm thử: — Kiểm thử phát triển (development test) : tự tiến hành — Đảm bảo chất lượng (quantity assurance) và kiểm tra chấp nhận (acceptance test): do bên ngoài tiến hành Khái niệm Một số khái niệm — Kiểm thử hộp đen (black-box) : — Kiểm thử các chức năng cụ thể của phần mềm, không quan tâm cấu trúc bên trong — Dữ liệu vào được tạo theo thiết kế để sinh ra các output khác nhau, các kết quả được so sánh với các kết quả thực tế để đánh giá mức độ thành công. — Ba phương pháp chính: Phân hoạch cân bằng. Phân tích cực biên. Đoán lỗi 14/9/2009 2 Kiêm thử phần mềm – khái niệm Kiêm thử phần mềm – khái niệm — Hộp trắng (white-box) : — Kiểm thử cấu trúc điều khiển bên trong chương trình. — Hộp được mở ra và nhìn vào các logic đặc tả của ứng dụng để kiểm tra nó làm việc như thế nào. — Có 3 phương pháp chính: — Kiểm tra logic (logic test), — Chứng minh toán học (mathematical proof), — Phòng sạch (cleanroom test) Mục tiêu Mục tiêu của kiểm thử — Tìm ra lỗi (nếu có) với chi phí thấp nhất — Kiểm thử phần mềm giúp: — Phát hiện được lỗi trong chương trình (nếu có). — Chứng minh được phần mềm hoạt động đúng như đã thiết kế — Chứng minh được phần mềm đáp ứng yêu cầu của user: Góp phần chứng minh chất lượng của phần mềm Kiểm thử phần mềm – mục tiêu — Quá trình kiểm thử phần mềm là tốt khi: — Có khả năng tìm ra lỗi cao — Không dư thừa — Biết chọn lọc: chỉ kiểm nghiệm những phần nào có khả năng tìm ra lỗi đặc trưng — Không quá phức tạp cũng không quá đơn giản — Chú ý: Kiểm thử phần mềm không khẳng định được phần mềm không còn khiếm khuyết, chỉ khẳng định được phần mềm có lỗi 14/9/2009 3 Nguyên lý Các nguyên lý — Việc kiểm thử nên hướng về yêu cầu của khách hàng — Nên được hoạch định trước một thời gian dài. — Áp dụng nguyên lý Pareto: 80% lỗi có nguyên nhân từ 20% các module : cô lập và kiểm tra những module khả nghi nhất. — Không thể kiểm thử triệt để một phần mềm. — Nên được thực hiện bởi những đối tượng KHÔNG tham gia vào quá trình phát triển phần mềm Test-case Trường hợp kiểm thử (Test case) — Khái niệm test-case — Dữ liệu input — Thao tác kiểm nghiệm — Dữ liệu output hay đáp ứng mong đợi của chương trình — Test-case cho kiểm thử black-box: chủ yếu dựa vào các yêu cầu cụ thể của chức năng phần mềm. — Test-case cho kiểm thử white-box: chủ yếu dựa vào cấu trúc điều khiển của phần mềm Kiểm thử phần mềm - test-case Các đường độc lập cơ bản — Kiểm thử white-box dựa vào cấu trúc điều khiển của thiết kế thủ tục để sinh các test-case với tiêu chí — Tất cả các đường thực thi độc lập được thử qua ít nhất một lần — Thử các điều kiện rẽ nhánh ở cả 2 nhánh true và false — Thử qua vòng lặp tại biên cũng như bên trong — Thử qua cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nó — Kiểm thử các đường độc lập cơ bản là một trong những phương cách kiểm thử white-box Kiểm thử phần mềm - test-case Đồ thị dòng chảy — Mỗi node hình tròn biểu diễn một hoặc một vài tác vụ (hơi khác so với lưu đồ thuật giải) sequence if while case until 14/9/2009 4 Kiểm thử phần mềm - test-case 1 2 3 4 5 6 8 7 11 10 9 1 2,3 4,5 6 7 8 9 10 11 Kiểm thử phần mềm - test-case procedure: DoSomething 1: do while x=0 2: if y=0 then 3: z=0; 4: elseif k=0 then 5: z=1; 6: else x=1; 7: endif; endif; 8: enddo 9: end 1 2 3 4 6 5 7 8 9 Kiểm thử phần mềm - test-case — Phải phân rã tất cả các điều kiện phức trở thành các điều kiện đơn — Mỗi node mô tả một điều kiện đơn được gọi là predicate b y x a if a and b then y else x b x a while a or b do x Kiểm thử phần mềm - test-case Procedure AnalyzeTriangle 1 2 3 4 6 5 7 8 9 c > 0 a<b+c a = c a = b b = c a 2 =b 2 +c 2 11 10 12 14/9/2009 5 Kiểm thử phần mềm - test-case Liệt kê các đường độc lập cơ bản — Từ node bắt đầu đến node kết thúc, các đường thực thi cơ bản được liệt kê theo một thứ tự nào đó để đảm bảo rằng: đường đang liệt kê ít nhất đi qua một cạnh chưa được duyệt qua bởi các đường đã liệt kê trước đó — Tổng số đường thực thi cơ bản độc lập nhau được tính bằng — V = P + 1; trong đó P là số node phân nhánh (predicate) Kiểm thử phần mềm - test-case — Đối với chương trình con DoSomething — Tổng số đường : V = 3 + 1 = 4 — Đường 1: 1-9 — Đường 2: 1-2-3-8-1… — Đường 3: 1-2-4-5-7-8-1… — Đường 4: 1-2-4-6-7-8-1… — Chú ý: dấu 3 chấm (…) mang ý nghĩa “không quan tâm”, từ đó có thể đi theo bất kỳ cạnh nào bởi vì các cạnh sau đó đã được duyệt qua rồi 1 2 3 4 6 5 7 8 9 Kiểm thử phần mềm - test-case — Đối với chương trình con AnalyzeTriangle — Tổng số đường : V = 6 + 1 = 7 — Đường 1: 1-3-12 — Đường 2: 1-2-3-12 — Đường 3: 1-2-4-5-12 — Đường 4: 1-2-4-6-7-12 — Đường 5: 1-2-4-6-8-7-12 — Đường 6: 1-2-4-6-8-9-10-12 — Đường 7: 1-2-4-6-8-9-11-12 Kiểm thử phần mềm - test-case Thiết lập các test-case — Test-case : trường hợp kiểm thử — Thiết lập một test-case cho mỗi đường thực thi cơ bản — Dựa vào thuật giải để tìm ra một dữ liệu input, sau đó tính ra dữ liệu output hay đáp ứng mong đợi của thuật giải — Chú ý: có thể không tạo ra được test-case cho một đường thực thi nào đó 14/9/2009 6 Kiểm thử phần mềm - test-case — Sinh test-case cho chương trình con AnalyzeTriangle — Test-case cho đường 1: — Input: a = 3, b = 2, c = 0 — Output mong đợi: type = “Error” — Test-case cho đường 2: — Input: a = 17, b = 5, c = 4 — Output mong đợi: type = “Error” — Test-case cho đường 3: — Input: a = 6, b = 6, c = 6 — Output mong đợi: type = “Equilateral” Kiểm thử phần mềm - test-case — Test-case cho đường 4: — Input: a = 7, b = 7, c = 4 — Output mong đợi: type = “Isosceles” — Test-case cho đường 5: — Input: a = 12, b = 9, c = 9 — Output mong đợi: type = “Isosceles” — Test-case cho đường 6: — Input: a = 5, b = 4, c = 3 — Output mong đợi: type = “Right” — Test-case cho đường 7: — Input: a = 13, b = 11, c = 6 — Output mong đợi: type = “Scalene” Chiến thuật Chiến thuật kiểm thử — Chiến thuật kiểm thử phần mềm tích hợp các phương pháp tạo ra test-case trở thành một chuỗi các bước có thứ tự để có thể kiểm thử phần mềm thành công. — Bao gồm các công việc — Lập kế hoạch kiểm nghiệm — Sinh test-case — Thực hiện kiểm thử, thu thập kết qủa và đánh giá Kiểm thử phần mềm - chiến thuật 14/9/2009 7 Quy trình Quytrình kiểmthử — Đơn vị phát triển tiến hành — Kiểm thử đơn vị (Unit test) — Kiểm thử tích hợp (Sub system integration test) — Kiểm thử hệ thống (System test) — Khách hàng tiến hành — Đảm bảo chất lượng và kiểm thử chấp thuận (Quanlity assurance & Acceptance test) Kiểm thử phần mềm - quy trình Kiểm thử phần mềm - quy trình Kiểm thử đơn vị — Tiến hành tại những giai đoạn sớm nhất. — Tiến hành kiểm thử trên từng đơn vị nhỏ nhất của phần mềm, đó là môđun mã nguồn, sau khi đã thiết kế, mã hoá và biên dịch thành công — Có thể tiến hành kiểm thử cùng lúc nhiều module. — Được thực hiện để xem chức năng của môđun có tương ứng với đặc tả môđun hay không. Kiểm thử phần mềm - quy trình Phương pháp và test-case — Phương pháp: — Kiểm thử hộp đen — Kiểm thử hộp trắng (nếu cần) — Thiết kế các test-case — Chuẩn bị các test-case (số liệu kiểm thử) — Là nhân tố quan trọng ảnh hưởng đến kết quả thậm chí cả chất lượng của hệ thống — Lập tài liệu thiết kế trường hợp kiểm thử và tích lũy dữ liệu kiểm thửsẽ rất có ích cho việc cải tiến phần mềm. 14/9/2009 8 Kiểm thử phần mềm – quy trình Kiểm thử tích hợp — Từng module mã nguồn đã hoạt động đúng. Liệu khi kết hợp chúng lại thành một nhóm lớn chúng có hoạt động đúng không ? — Phải tiến hành kiểm thử tích hợp để phát hiện lỗi liên quan đến giao tiếp giữa các module. — Trước khi tiến hành phải xác định chính xác thứ tự và thời gian các mô đun được kết nối. Kiểm thử phần mềm - quy trình Stub và driver — Mỗi môđun mã nguồn không phải là một chương trình hoàn chỉnh và đôi khi phải gọi các module chưa được kiểm nghiệm khác do đó có thể phải thiết lập driver và/hoặc stub — Driver là một chương trình chính có nhiệm vụ nhận dữ liệu kiểm nghiệm, chuyển dữ liệu đó xuống cho module để kiểm tra và in ra các kết quả kiểm tra tương ứng. — Stub thay thế các module được gọi bởi module đang kiểm tra. Kiểm thử phần mềm – quy trình Kiểm thử phần mềm – quy trình 14/9/2009 9 Kiểm thử phần mềm – quy trình Kiểm thử phần mềm – quy trình Kiểm thử tăng dần — Môđun đã kiểm thử sẽ móc nối liên tiếp với các môđun khác. — Có thể phân 3 loại — Kiểm thử từ trên xuống — Kiểm thử từ dưới lên — Kiểm thử tổ hợp Kiểm thử phần mềm – quy trình — Kiểm thử từ trên xuống — Kiểm thử theo thứ tự từ môđun cao đến môđun thấp — Điều kiện là bản thân chương trình phải được tạo từ thiết kế có cấu trúc — Cần đến stub — Thích hợp cho việc phát triển hệ thống mới Kiểm thử phần mềm – quy trình 14/9/2009 10 Kiểm thử phần mềm – quy trình — Kiểm thử từ dưới lên — Kiểm thử theo thứ tự từ môđun thấp lên môđun cao — Dùng để phát triên hệ thống theo trình tự các môđun thấp đến cao (lập trình từ dưới lên) — Do có nhiều môđun thấp do đó có thể tiến hành kiểm thử đồng thời trong giai đoạn đầu — Cần đến driver — Thích hợp với việc phát triển một phiên bản sửa đổi của hệ thống đang có. Kiểm thử phần mềm – quy trình Kiểm thử phần mềm – quy trình — Kiểm thử tổ hợp — Tổ hợp kiểm thử từ trên xuống và từ dưới lên — Tiến hành đồng thời cho đến khi đạt đến làn ranh thỏa hiệp đã định sẵn — Tốn ít thời gian — Cần đồng thời cả stub và driver Kiểm thử phần mềm – quy trình [...]... 14/9/2009 G r i - Lo i tr nguyên nhân G r i - Theo v t — Phương pháp này d a trên nguyên t c phân chia nh phân — Là m t phương pháp g l i khá ph bi n có th dùng thành công trong các chương trình nh nhưng khó áp d ng cho đ i v i các chương trình r t l n — Cách th c hi n: — Khi m t l i đư c phát hi n, c g ng đưa ra m t danh sách các nguyên nhân có th gây ra l i — Danh sách này đư c nghi m l i đ lo i b d n các... quan bên ngoài — Có th do ngư i s d ng hay đ i di n — Đánh giá khách quan v ng d ng — Tương t ki m th h th ng v m c đích nhưng đư c ti n hành n m ngoài s đi u khi n c a trư ng d án — Ki m th tích h p chương trình/h con — Ki m th ch c năng — Ki m th hi u năng — Ki m th v m hành — Ki m th ph c h i h ng hóc — Ki m th t i — Ki m th ngo i l — Ki m th ch u đ ng G r i — G r i là công vi c khó khăn và d gây... c ti n c a t ch c phát tri n h th ng — Ki m th đ ng th i trên m i môđun Móc n i chúng và ki m th toàn b — Khó tìm l i trong giao di n các môđun — Không c n đ ng c stub và driver — Ch thích h p v i các chương trình nh Ki m th ph n m m – quy trình Ki m th ph n m m – quy trình — Ki m th alpha — Áp d ng k thu t black-box — Đư c ti n hành ngay t i nơi s n xu t ph n m m — Ki m th tính năng bao g m — Nhà phát . chữa. 14/9/2009 12 Kiểm thử phần mềm – quy trình — Các kiểu kiểm thử hệ thống — Kiểm thử tích hợp chương trình/hệ con — Kiểm thử chức năng — Kiểm thử hiệu năng — Kiểm thử. hệ thống — Lập tài liệu thiết kế trường hợp kiểm thử và tích lũy dữ liệu kiểm thửsẽ rất có ích cho việc cải tiến phần mềm. 14/9/2009 8 Kiểm thử phần mềm