Microsoft Word Chuong10 doc Chương 10 Phân tích và giải thích kết quả kiểm thử 10 1 Một số thuật ngữ Lúc bắt ₫ầu kiểm thử, các testcase ₫ều ₫ược ghi nhận là chưa ₫ược kiểm thử (unattempted) Nếu kết qu[.]
Chương 10 Phân tích giải thích kết kiểm thử 10.1 Một số thuật ngữ Lúc bắt ₫ầu kiểm thử, testcase ₫ều ₫ược ghi nhận chưa ₫ược kiểm thử (unattempted) Nếu kết kiểm thử thỏa mãn ₫ầy ₫ủ kết kỳ vọng, testcase chuyển trạng thái ₫ã kiểm thử thành công (attempted and successful) Nếu phần kết kiểm thử phù hợp với kết kỳ vọng, testcase chuyển trạng thái ₫ã kiểm thử chưa thành công (attempted but unsuccessful) cơng việc quản lý kiểm thử theo dõi trạng thái testcase trạng thái testcase thị rõ ràng tiến ₫ộ kiểm thử : cịn 90% testcase chưa ₫ược kiểm thử, ta nói q trình kiểm thử bắt ₫ầu, cịn 10% testcase chưa ₫ược kiểm thử, ta nói q trình kiểm thử kết thúc Ước lượng ban ₫ầu lịch kiểm thử : Số testcase ₫ược kiểm thử khoảng thời gian số người kiểm thử cho người quản lý biết tiến ₫ộ kiểm thử tốt hay chậm Thí dụ 15 testcase ₫ược kiểm thử tuần ₫ầu (10 ngày làm việc), ta tính ₫ược tốc ₫ộ kiểm thử 1.5 testcase/ngày Nếu kế hoạch cần kiểm thử 100 testcase, ta phải tốn 100/1.5 = 67 ngày (tức 14 tuần) Nhưng kiểm thử số testcase, ta phát lỗi, ₫ó ta phải tốn thời gian sửa lỗi kiểm thử lại testcase ₫ó lần 2, 3, Do ₫ó thời gian kiểm thử lâu nhiều so với ước lượng ban ₫ầu lịch kiểm thử Một số testcase trạng thái "₫ược kiểm thử không thành cơng" kết thu ₫ược khơng ₫úng theo kết kỳ vọng hay máy bị dừng trước hồn thành kiểm thử testcase ₫ó Thách thức cho người quản lý lập thứ tự ưu tiên cho việc sửa lỗi kiểm thử lại testcase : Ứng với testcase làm máy bị dừng chưa cho kết nên ưu tiên cho việc sữa lỗi kiểm thử lại Cịn testcase kiểm thử làm TPPM chạy ₫ược cho kết khơng giống với kỳ vọng lập thứ tự ưu tiên cho việc sửa lỗi Các tester thường dùng mức tới ₫ể ₫ánh giá mức ₫ộ cần sửa : mức tầm trọng mức nhẹ bỏ qua Lịch kiểm thử kết tuần ₫ầu Kết phân tích tuần kiểm thử ₫ầu tiên 10.2 Khám phá lỗi dựa vào lỗi riêng lẻ tìm ₫ược Người kiểm thử phát lỗi theo thời gian Mỗi lỗi ₫ược phát hiện, ₫ược sửa kiểm thử lại Vùng code cần kiểm thử chạy ₫ược cho tồn testcase Nhưng thường gặp kiểm thử lại lỗi vừa sửa, ta phát lỗi khác phải sửa Điều lặp lại nhiều lần cho ₫ến kiểm thử xong testcase tương ứng Cũng ta phải kiểm thử nhiều testcase khác phục vụ cho mục tiêu khác vùng code xác ₫ịnh, testcase giúp phát lỗi khác Tóm lại, việc kiểm thử thành cơng testcase riêng lẻ chưa ₫ảm bảo vùng code ₫ược kiểm thử tương ứng khơng cịn lỗi Việc kiểm thử/ phát lỗi/sửa lỗi/kiểm thử lại theo kiểu tăng tiến cách yếu ₫ể người kiểm thử giúp ₫ở người phát triển viết ₫úng phần mềm thỏa mãn yêu cầu ₫ặt Cách thức mức ₫ộ theo dõi lỗi tìm ₫ược, sửa chữa kiểm thử lại ₫ịnh ₫ộ hiệu việc kiểm thử Ta xây dựng bảng theo dõi lỗi worksheet Excel hay tiện ích cao cấp Lịch kiểm thử & bảng theo dõi việc xử lý lỗi Mỗi lỗi ₫ược gán số ₫ánh giá mức ₫ộ tầm trọng Mức ₫ộ tầm trọng lỗi phụ thuộc vào loại lỗi thời ₫iểm lỗi xảy ₫âu chu kỳ phát triển phần mềm Thường ta dùng loại lỗi sau ₫ây : loại : lỗi ngăn cản việc kiểm thử loại : lỗi ngăn cản việc phát triển phần mềm loại : lỗi ngăn cản việc triển khai/phân phối phần mềm Càng cuối chu kỳ phát triển phần mềm loại lỗi nên có mức ₫ộ tầm trọng ngày cao 10.3 Khám phá lỗi dựa vào backlog Chúng ta ₫ã giới thiệu thước ₫o hoạt ₫ộng kiểm thử : thước ₫o : số lượng tỉ lệ testcase ₫ã thử/testcase kế hoạch cho ta biết ta ₫ang giai ₫oạn trình kiểm thử thước ₫o : số lượng tỉ lệ testcase bị lỗi/testcase ₫ã kiểm thử cho ta biết mức ₫ộ tìm lỗi người kiểm thử Bây ta giới thiệu thước ₫o thứ : danh sách lỗi chưa ₫ược sửa (backlog) Định nghĩa Danh sách lỗi chưa sửa (Backlog) Nếu việc kiểm thử ₫ã phát 300 lỗi người phát triển ₫ã sửa ₫ược 100 lỗi danh sách lỗi chưa sửa chứa 200 lỗi Thách thức cho ₫ội phát triển xác ₫ịnh xem có ₫ủ thời gian, tài ngun lập trình kiểm thử ₫ể kiểm thử lỗi lại cho backlog khơng cịn chứa lỗi Câu trả lời thường "không thể" Thách thức xem lại backlog ₫ể lập thứ tự mức ₫ộ tầm trọng lỗi, dựa vào ₫ó lỗi nặng nên ₫ược sửa ₫ầu tiên Hy vọng thời gian phát triển kiểm thử ₫ã hết backlog ₫ược tối thiểu hóa chứa lỗi không ảnh hưởng ₫ến chức nghiệp vụ chương trình Các lỗi backlog ₫ược sửa phân phối service pack hay version phần mềm Một thách thức khác cho ₫ội phân tích backlog backlog ₫ược cập nhật theo chu kỳ (thí dụ hàng tuần), lỗi phát (do việc sửa lỗi trước ₫ây tạo ra) ₫ược ₫ánh giá tầm trọng ₫ược ưu tiên ₫ể ₫ầu backlog ₫ể cần sửa gấp Ở ₫iểm nối xảy tranh cải nảy lửa chất lượng phần mềm chưa có chuẩn cơng nghiệp vấn ₫ề Trong phạm vi môn học, ₫ánh giá chất lượng phần mềm dựa vào phần mềm thực ₫ược so với ₫ặc tả ₫ề ban ₫ầu Cụ thể, ₫ội phát triển phần mềm ₫ã viết ₫ược phần mềm thỏa mãn ₫ặc tả chức ₫ội kiểm thử ₫ã xác thực ₫ược ₫iều ta nói phần mềm có chất lượng tốt 10.4 Khám phá lỗi dựa vào chùm lỗi Mã earmark lỗi công dụng Bây ta xem xét dung hoà giá/lợi ích mang lại thêm field thông tin vào record theo dõi lỗi bảng theo dõi lỗi Ta gọi field mã earmark : mã nhận dạng vùng code chứa lỗi Chi phí quản lý field earmark không cao : Các thành viên ₫ội phát triển phải thống qui tắc tạo ₫ọc mã Thường ₫ặc tả phần mềm, ta dùng mã ₫ể nhận dạng module, class, hàm chức năng, mã dùng làm mã earmark cho lỗi tìm ₫ược Các thành viên ₫ội phát triển phải ₫iền giá trị ₫úng vào field cho lỗi bảng theo dõi lỗi mà tester tạo (sau họ sửa lỗi này) Phương pháp phân tích nguyên nhân gốc (root cause analysis) phương pháp toán học lĩnh vực thống kê ₫ược trình bày phổ biến sách toán thống kê Người ta ₫ã dùng nhiều phương pháp ₫ể phân tích danh sách lỗi phát dự án phần mềm Ý tưởng phương pháp phân tích lỗi phát giúp tìm kiếm xác ₫ịnh chùm lỗi lớn (buggiest) : tính số lượng lỗi/tỉ lệ lỗi theo mã earcode lập thứ tự từ cao xuống thấp Phương pháp hữu dụng khoảng thời gian từ 1/3 tới 1/2 thời gian kế hoạch kiểm thử lúc phần mềm có ₫ộ ổn ₫ịnh thấp, nên cần nhiều sửa chữa cập nhật Kết phân tích nguyên nhân gốc dự án phần mềm giai ₫oạn ₫ầu công ₫oạn thực, lúc ₫ội phát triển ₫ã sửa ₫ược 2000 lỗi Phân tích số liệu bảng slide trước, ta thấy : cần thiết phải xem lại ₫oạn code bảng thiết kế liên quan gây nhóm lỗi AP234, AP745 GL106 (vì chúng chiếm tới 45.5% lỗi) trước tiến hành bước thực Lưu ý thêm nhóm lỗi AP234, AP745 có mối quan hệ khắng khích chúng thuộc module chức cịn lỗi thuộc nhóm AR218 có tỉ lệ tương ₫ối thấp nên ₫ược xem xét hay khơng tùy thuộc vào ₫ội kiểm thử ₫ã tìm hiểu nắm vững vùng code gây lỗi chưa Có thể bỏ qua việc xem lại vùng code chứa lỗi thuộc nhóm cịn lại chúng chiếm tỉ trọng nhỏ Sở dĩ xuất nhóm lỗi chứa nhiều lỗi : thiết kế khơng xác với chức thiết kế chưa ₫ầy ₫ủ viết code chưa ₫ủ debug code chưa ₫ủ dùng chuẩn lập trình khơng tốt người lập trình chưa thơng thạo nắm vững khả ngơn ngữ lập trình người lập trình chưa nắm vững giải thuật phức tạp ₫ược dùng ₫ể giải chức Việc xem lại vùng code chứa nhiều lỗi tốn thời gian (thí dụ tuần) làm cho bước bị delay, nhiên lợi lớn nhiều : việc xem lại vùng code/bảng thiết kế, ta tìm ₫ược số nguyên nhân gốc gây ₫ồng thời nhiều lỗi, cần sửa cập nhật nguyên nhân gốc nhiều lỗi ₫ã ₫ược sửa kiểm thử lại, số lỗi thuộc vùng code liên quan giảm thiểu lớn Thí dụ ta phát 50 lỗi (so với 1500 lỗi lần kiểm thử trước) lỗi tìm ₫ược có xu hướng khơng phải lỗi nặng ₫ược ₫ưa vào danh sách lỗi chưa sửa nên khơng cần sửa gắp chúng, ₫ể cho bước phát triển sau ₫ó thực Ta lặp lại việc phân tích nguyên nhân gốc dự án phần mềm giai ₫oạn sau ₫ó, thí dụ giai ₫oạn cuối phát triển phần mềm, ₫ội phát triển ₫ã sửa ₫ược 1500 lỗi Bây ta thấy : nhóm lỗi quan trọng chiếm tỉ lệ nhỏ (4.7%), ₫iều nói lên phần mềm ₫ã ổn ₫ịnh nhóm lỗi quan trọng bước trước AP234 GL106 danh sách, với tỉ lệ nhỏ Điều cho thấy tính hiệu việc dùng mã earmark việc xem xét lại vùng code tương ứng nhóm lỗi quan trọng chiếm tỉ lệ nhỏ nên việc phân tích ngun nhân gốc bước khơng có tác dụng lớn lúc trước Mặc dù vậy, thông tin earmark hữu dụng cho việc quản lý danh sách lỗi chưa sửa (backlog) 10.5 Dùng mẫu phát lỗi project trước Việc tiên ₫oán số lỗi mà ₫ội kiểm thử phát ₫ược dự án hành quan trọng, giúp ta ₫ưa kế hoạch, chuẩn bị tài nguyên kiểm thử hiệu Nếu không dựa thông tin nào, chưa có phương pháp giúp ta tiên ₫ốn xác ₫ược Tuy nhiên, có số phương pháp dựa vào yếu tố lịch sử giúp ta tiên ₫ốn với ₫ộ xác nằm phạm vi lệch 10% Phương pháp tiên ₫oán dựa vào yếu tố lịch sử ₫ặc biệt thích hợp cho cơng ty phần mềm lâu ₫ời, họ ₫ã phát triển thành cơng nhiều phần mềm với nhiều kích cở khác theo thời gian Càng có nhiều thơng tin record miêu tả lỗi project trước cho ta tiên ₫ốn với ₫ộ xác cao Chúng ta bắt ₫ầu thông tin record lỗi : mã lỗi ngày phát Đường biểu diễn lỗi phát project 200KLOC, ₫ược kiểm thử 24 tuần Đường cong miêu tả việc phát lỗi project trước cho thông tin chung cho hầu hết project phần mềm : lúc ₫ầu số lỗi phát ₫ược thường nhiều lên nhanh tới ₫ỉnh thời ₫iểm khoảng 1/3 thời gian phát triển phần mềm (giai ₫oạn ₫ầu ₫ộ ổn ₫ịnh phần mềm thấp) sau ₫ó số lỗi ₫ược phát giảm dần phần mềm ngày hoàn chỉnh ổn ₫ịnh ₫iểm A miêu tả số lỗi ₫ược phát nhiều (là 749 lỗi) ₫iểm B miêu tả tuần phát lỗi nhiều (là tuần 10) ₫iểm C miêu tả tuần kết thúc việc phát triển phần mềm (tuần 24) vùng C ₫ường cong (diện tích vùng) miêu tả tổng số lỗi tìm ₫ược dự án phần mềm (11,497) Có nhiều nghiên cứu nói : ta tìm ₫ược lỗi nhiều sớm lỗi ₫ược phát khách hàng sau Lưu ý chi phí sửa lỗi khách hàng phát ₫ược lớn Nghiên cứu cịn nói ta nội suy ₫ường biểu diễn lỗi phát phía phải trục x ₫ến tiếp xúc trục x vùng nới rộng (vùng D) xỉ số lỗi mà khách hàng phát ₫ược sau ₫ó Biểu ₫ồ nới rộng ₫ược vẽ slide kế cho ta thấy ₫iểm D tiếp xúc với trục x tuần 36, số lỗi vùng D 487 lỗi 10.6 Sử dụng biểu ₫ồ phân loại nhóm lỗi Nếu record thông tin lỗi ₫ược phát project trước có thêm field miêu tả mức ₫ộ tầm trọng lỗi (1-4), ta xây dựng sử dụng biểu ₫ồ phân loại nhóm lỗi sau : Từng chu kỳ (tuần), tính số lượng lỗi thuộc mức nặng/nhẹ phát ₫ược (ta dùng mức) Xếp tầng số lỗi thuộc mức nặng/nhẹ tuần vẽ thành cột cho tuần ₫ó Dựa vào kết biểu ₫ồ ta rút ₫ược kết luận : Các lỗi có mức ₫ộ nặng thường xảy ₫ược phát sớm lúc project chưa có ₫ộ ổn ₫ịnh cao Mức ₫ộ lỗi phát giảm dần sau project ngày ổn ₫ịnh 10.7 Độ tương quan lỗi khách hàng phát Trong khoảng thời gian từ lúc project trước ₫ã hoàn thành ₫ến lúc project sau ₫ược phát triển, ta có thêm nhiều thơng tin khác Một thơng tin quan trọng số lượng lỗi tính chất lỗi ₫ược phát phản hồi phận HelpDesk khách hàng Ta dùng ₫ộ tương quan lỗi khách hàng phát sau : Tỉ lệ lỗi tiên ₫oán/lỗi ₫ược khách hàng phát thực tế 487/70 = 6.9 Nhờ ₫ộ tương quan mà ta tiên ₫ốn ₫ược số lượng lỗi mà khách hàng phát ₫ược sử dụng project phần mềm phát triển Dựa vào số lượng lỗi mà ta qui hoạch tương ₫ối xác số lượng thời lượng làm việc nhân viên phận hỗ trợ (Support) giúp ₫ỡ (HelpDesk) người dùng ⇒ dự tốn xác chi phí sửa lỗi Bảng theo dõi lỗi ₫ược phản ánh khách hàng phận giúp ₫ở khách hàng ghi nhận phận phát triển phân loại nhóm lỗi Bắt ₫ầu project Lúc ta ₫ã có : số lượng hàng lệnh số lỗi project trước (₫ược thể ₫ường cong miêu tả số lỗi phát ₫ược) mức ₫ộ tầm trọng lỗi cách phân phối chúng theo thời gian (₫ược thể biểu ₫ồ phân phối mức ₫ộ lỗi project trước) So sánh với số lượng hàng lệnh project ₫ang phát triển, ta tính số lượng lỗi cho project này, từ ₫ó kế hoạch hóa việc kiểm thử, chuẩn bị tài nguyên phù hợp cho việc kiểm thử Trong chu kỳ kiểm thử, ta tổng kết vẽ số lượng lỗi phát trực tiếp lên ₫ường biểu diễn project trước ₫ể dễ dàng so sánh nội suy thơng tin cần Do project có qui mơ tính chất khác nhau, số lượng lỗi phát tuần ₫ầu khác Thí dụ Project hành A có số lỗi phát ₫ược nhiều project cũ tốc ₫ộ phát lỗi tuần ₫ầu cao nhiều so với project cũ Đây xu mà ta mong muốn Điều ₫ặt câu hỏi : ta kiểm thử hiệu trước ? Câu trả lời ta dùng nhiều tools kiểm thử tự ₫ộng trước Thí dụ Project hành B có số lỗi phát ₫ược project cũ tốc ₫ộ phát lỗi chậm so với project cũ Đây xu mà ta khơng mong muốn Điều ₫ặt câu hỏi : ta kiểm thử hiệu trước ? Câu trả lời ta bỏ ₫i hay làm thiếu số hoạt ₫ộng mà project trước ₫ã làm Sau xác ₫ịnh ₫ược nguyên nhân rõ ràng, ta khắc phục ₫ể việc kiểm thử hiệu cho tuần lại Khi project tiếp tục Tiếp tục kiểm soát vẽ ₫ường cong biểu diễn lỗi phát cột mốc trình phát triển phần mềm Tới lúc ₫ó, thường khoảng 1/3 thời gian phát triển phần mềm, tốc ₫ộ phát lỗi (số lỗi phát hiện/trên tuần) ₫ạt ngưỡng bắt ₫ầu giảm xuống Điểm uốn ₫iểm neo quan trọng cho hầu hết hoạt ₫ộng phân tích kết lỗi : Project A có ₫iểm ngưởng tuần với số lượng 1213 lỗi ⇒ Project A ₫ược kiểm thử hiệu project cũ Project B có ₫iểm ngưỡng tuần 12 với số lượng 607 lỗi ⇒ Project B ₫ược kiểm thử hiệu project cũ project A Khi project kết thúc Tiếp tục kiểm thử vẽ kết theo thời gian Mỗi lần vẽ ₫iểm vào ₫ồ thị, ta phân tích ₫iểm có bất thường khơng ? Nếu có ₫ặt câu hỏi tạo từ ₫ó có biện pháp khắc phục Khi project kết thúc (giả sử theo kế hoạch tuần 24 biểu ₫ồ), ta nội suy nới rộng ₫ồ thị sang phải cho ₫ến tiếp xúc trục x Một số tiên ₫oán ước lượng : Project A chứa 14 lỗi ₫ược tiên ₫ốn khách hàng tìm ₫ược nên có lỗi mà khách hàng thực tìm → chi phí sửa 2*14000 = 28000$ (giảm ₫ược 952000$ so với project trước) Project B chứa 1377 lỗi ₫ược tiên ₫oán khách hàng tìm ₫ược nên có 196 lỗi mà khách hàng thực tìm → chi phí sửa 196*14000 = 2744000$ (tăng 1746000$ so với project trước) 10.8 Đường cong Rayleight - Gunsight cho mẫu phát lỗi Làm biết ₫ược tốc ₫ộ phát lỗi project công nghiệp hãng lớn ? Nhờ ₫ó so sánh, ₫ánh giá hoạt ₫ộng kiểm thử project ? Rất tiếc, ta khó lịng có ₫ược thơng tin xác thực cơng ty phần mềm có khuynh hướng dấu nhẹm, khơng cơng bố (vì ảnh hướng lớn ₫ến hình ảnh cơng ty) Hiện nguồn cung cấp chủ yếu ứng dụng ₫ường cong Rayleight Đây cơng thức tốn học cho phép ta tái tạo ₫ường cong chuẩn dựa vào ₫iểm ngưỡng (gunsight) Đường cong chuẩn sai lệch so với giá trị thật nhiều dự án phần mềm năm gần ₫ây 10% 10.9 Các thước ₫o khác theo dõi lỗi Các thước ₫o hoạt ₫ộng phát triển phần mềm : mã lỗi phát triển ngày phát lỗi phát triển mức ₫ộ trầm trọng lỗi phát triển ngày sửa lỗi phát triển mã earcode lỗi phát triển Các thước ₫o hoạt ₫ộng HelpDesk : mã lỗi khách hàng ngày phát lỗi khách hàng mức ₫ộ trầm trọng lỗi khách hàng ngày sửa lỗi khách hàng mã earcode lỗi khách hàng Thước ₫o khác : ODC (Orthogonal Defect Classifi cation) hãng IBM 10.10 Kết chương Chương ₫ã giới thiệu số thuật ngữ ₫ược dùng hoạt ₫ộng quản lý trình kiểm thử phần mềm Chúng ta ₫ã giới thiệu số kỹ thuật phổ dụng ₫ể hỗ trợ việc phát lỗi phát lỗi dựa vào lỗi ₫ã phát ₫ược, phát lỗi dựa vào backlog, phát lỗi dựa vào chùm lỗi Chúng ta ₫ã giới thiệu số kỹ thuật ₫ể quản lý hoạt ₫ộng kiểm thử phần mềm dùng ₫ường cong phát lỗi project trước, dùng biểu ₫ồ phân loại nhóm lỗi project trước, dùng ₫ường cong Rayleight