Bài giảng Kiểm tra phần mềm - Chương 10: Phân tích và giải thích kết quả kiểm thử

Nội dung text: Bài giảng Kiểm tra phần mềm - Chương 10: Phân tích và giải thích kết quả kiểm thử

1. Thách thức cho người quản lý là lập thứ tự ưu tiên cho việc sửa lỗi và kiểm thử lại các testcase này : ƒ Ứng với testcase làm máy bị dừng khi chưa cho kết quả thì nên ưu tiên cho việc sữa lỗi nó và kiểm thử lại ngay. ƒ Còn các testcase kiểm thử làm TPPM chạy ₫ược nhưng cho kết quả không giống với kỳ vọng thì sẽ lập thứ tự ưu tiên cho việc sửa lỗi. Các tester thường dùng 4 mức 1 tới 4 ₫ể ₫ánh giá mức ₫ộ cần sửa : mức 1 là tầm trọng nhất và mức 4 là nhẹ nhất và có thể bỏ qua.
2. Người kiểm thử phát hiện từng lỗi theo thời gian. Mỗi khi lỗi ₫ược phát hiện, nó có thể ₫ược sửa và kiểm thử lại. Vùng code cần kiểm thử có thể chạy ₫ược cho toàn bộ testcase. Nhưng thường gặp hơn là khi kiểm thử lại lỗi vừa sửa, ta phát hiện lỗi khác và phải sửa nó. Điều này có thể lặp lại nhiều lần cho ₫ến khi kiểm thử xong testcase tương ứng. Cũng có thể ta phải kiểm thử nhiều testcase khác nhau phục vụ cho những mục tiêu khác nhau trên cùng vùng code xác ₫ịnh, và mỗi testcase sẽ giúp phát hiện các lỗi khác nhau. Tóm lại, việc kiểm thử thành công 1 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 hiện lỗi/sửa lỗi/kiểm thử lại theo kiểu tăng tiến là cách chính 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 các yêu cầu ₫ặt ra. Cách thức và mức ₫ộ theo dõi các lỗi tìm ₫ược, sửa chữa và kiểm thử lại sẽ quyết ₫ịnh ₫ộ hiệu quả của việc kiểm thử. Ta có thể xây dựng bảng theo dõi lỗi bằng worksheet Excel hay bằng 1 tiện ích cao cấp hơn.
3. ƒ thước ₫o 2 : số lượng và tỉ lệ testcase bị lỗi/testcase ₫ã kiểm thử cho ta biết mức ₫ộ tìm lỗi của người kiểm thử. Bây giờ ta sẽ giới thiệu thước ₫o thứ 3 : danh sách các 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 hiện 300 lỗi và người phát triển ₫ã sửa ₫ược 100 lỗi thì danh sách các lỗi chưa sửa sẽ chứa 200 lỗi. Thách thức cho ₫ội phát triển là xác ₫ịnh xem có ₫ủ thời gian, tài nguyên lập trình và kiểm thử ₫ể kiểm thử các lỗi còn lại sao cho backlog không còn chứa lỗi nào. Câu trả lời thường là "không thể". Thách thức kế tiếp là xem lại backlog ₫ể lập thứ tự mức ₫ộ tầm trọng của lỗi, dựa vào ₫ó các lỗi càng nặng thì nên ₫ược sửa ₫ầu tiên. Hy vọng rằng khi thời gian phát triển và kiểm thử ₫ã hết thì backlog sẽ ₫ược tối thiểu hóa và chỉ chứa các lỗi không ảnh hưởng ₫ến chức năng nghiệp vụ của chương trình. Các lỗi trong backlog sẽ ₫ược sửa và phân phối trong service pack hay trong version kế tiếp của phần mềm.
4. 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 nhất qui tắc tạo và ₫ọc mã này. Thường trong ₫ặc tả phần mềm, ta dùng 1 mã ₫ể nhận dạng 1 module, 1 class, 1 hàm chức năng, mã này cũng có thể 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 này cho từng lỗi trong bảng theo dõi lỗi mà tester tạo ra (sau khi họ sửa lỗi này). Phương pháp phân tích nguyên nhân gốc (root cause analysis) là 1 phương pháp toán học trong lĩnh vực thống kê ₫ược trình bày khá phổ biến trong các sách về toán thống kê. Người ta ₫ã dùng khá nhiều phương pháp này ₫ể phân tích danh sách lỗi phát hiện của dự án phần mềm. Ý tưởng cơ bản của phương pháp này trong phân tích lỗi phát hiện là giúp tìm kiếm và xác ₫ịnh các chùm lỗi lớn nhất (buggiest) : ƒ tính số lượng lỗi/tỉ lệ lỗi theo từng mã earcode. ƒ lập thứ tự từ cao xuống thấp. Phương pháp này rất hữu dụng trong khoảng thời gian từ 1/3 tới 1/2 thời gian trong kế hoạch kiểm thử vì lúc này phần mềm có ₫ộ ổn ₫ịnh rất thấp, nên cần nhiều sửa chữa và cập nhật.
5. ƒ thiết kế không chính xác với chức năng hoặ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 và nắm vững khả năng của 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 quyết chức năng. Việc xem lại vùng code chứa nhiều lỗi cũng tốn thời gian (thí dụ 3 tuần) và làm cho bước kế tiếp bị delay, tuy nhiên cái lợi thì lớn hơn nhiều : ƒ trong việc xem lại vùng code/bảng thiết kế, ta có thể tìm ra ₫ược 1 số nguyên nhân gốc gây ra ₫ồng thời nhiều lỗi, chỉ cần sửa và cập nhật các nguyên nhân gốc này thì rất nhiều lỗi ₫ã ₫ược sửa. ƒ và khi kiểm thử lại, số lỗi thuộc các vùng code liên quan sẽ giảm thiểu rất lớn. Thí dụ ta chỉ còn phát hiện 50 lỗi (so với 1500 lỗi của lần kiểm thử trước). các lỗi tìm ₫ược này có xu hướng không phải là lỗi nặng và có thể ₫ượ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, có thể ₫ể cho bước phát triển sau ₫ó thực hiện. Ta có thể lặp lại việc phân tích nguyên nhân gốc của 1 dự án phần mềm trong các giai ₫oạn sau ₫ó, thí dụ tại giai ₫oạn cuối của phát triển phần mềm, ₫ội phát triển ₫ã sửa ₫ược 1500 lỗi.
6. 10.5 Dùng mẫu về phát hiện lỗi của project trước Việc tiên ₫oán số lỗi mà ₫ội kiểm thử sẽ phát hiện ₫ược trong dự án hiện hành là rất quan trọng, nó giúp ta ₫ưa ra kế hoạch, chuẩn bị tài nguyên kiểm thử hiệu quả. Nếu không dựa trên thông tin nào, hiện nay chưa có phương pháp nào giúp ta tiên ₫oán chính xác ₫ược. Tuy nhiên, có 1 số phương pháp dựa vào yếu tố lịch sử sẽ giúp ta tiên ₫oán với ₫ộ chính xác nằm trong 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ác 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 nhau theo thời gian. Càng có nhiều thông tin trong record miêu tả lỗi trong project trước càng cho ta tiên ₫oán với ₫ộ chính xác cao hơn. Chúng ta hãy bắt ₫ầu bởi 2 thông tin cơ bản trong record lỗi : mã lỗi và ngày phát hiện.
7. ƒ vùng C dưới ₫ường cong (diện tích của vùng) miêu tả tổng số lỗi tìm ₫ược trong dự án phần mềm (11,497). Có nhiều nghiên cứu nói rằng : nếu ta tìm ₫ược lỗi càng nhiều và càng sớm thì lỗi ₫ược phát hiện bởi khách hàng sau này càng ít. Lưu ý rằng chi phí sửa lỗi do khách hàng phát hiện ₫ược là rất lớn. Nghiên cứu này còn nói là nếu ta nội suy ₫ường biểu diễn lỗi phát hiện về phía phải trục x ₫ến khi tiếp xúc trục x thì vùng nới rộng này (vùng D) sẽ sắp xỉ bằng số lỗi mà khách hàng sẽ phát hiện ₫ượ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 là 487 lỗi. 10.6 Sử dụng biểu ₫ồ phân loại các nhóm lỗi Nếu trong record thông tin về lỗi ₫ược phát hiện trong project trước có thêm field miêu tả mức ₫ộ tầm trọng của lỗi (1-4), ta có thể xây dựng và sử dụng biểu ₫ồ phân loại các nhóm lỗi như sau : ƒ Từng chu kỳ (tuần), tính số lượng lỗi thuộc từng mức nặng/nhẹ phát hiện ₫ược (ta dùng 4 mức).
8. 2 bộ phận hỗ trợ (Support) và giúp ₫ỡ (HelpDesk) người dùng ⇒ dự toán chính xác chi phí sửa lỗi. Bảng theo dõi các lỗi ₫ược phản ánh bởi khách hàng do bộ phận giúp ₫ở khách hàng ghi nhận và bộ phận phát triển phân loại nhóm lỗi. Bắt ₫ầu project mới Lúc này ta ₫ã có : ƒ số lượng hàng lệnh và số lỗi của project trước (₫ược thể hiện trong ₫ường cong miêu tả số lỗi phát hiện ₫ược). ƒ mức ₫ộ tầm trọng của các lỗi và cách phân phối chúng theo thời gian (₫ược thể hiện trong biểu ₫ồ phân phối mức ₫ộ lỗi của project trước). So sánh với số lượng hàng lệnh của project ₫ang phát triển, ta có thể tính số lượng lỗi cho project mới 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ử.
9. tốc ₫ộ phát hiện lỗi (số lỗi phát hiện/trên tuần) sẽ ₫ạt ngưỡng và bắt ₫ầu giảm xuống. Điểm uốn này là ₫iểm neo quan trọng nhất cho hầu hết mọi hoạt ₫ộng phân tích kết quả về lỗi : ƒ Project A có ₫iểm ngưởng ở tuần 6 với số lượng 1213 lỗi ⇒ Project A ₫ược kiểm thử hiệu quả hơn 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ử kém hiệu quả hơn project cũ và project A. Khi project mới kết thúc Tiếp tục kiểm thử và vẽ kết quả theo thời gian. Mỗi lần vẽ 1 ₫iểm mới vào ₫ồ thị, ta phân tích ₫iểm này có bất thường gì không ? Nếu có hãy ₫ặt câu hỏi tạo sao và từ ₫ó có biện pháp khắc phục. Khi project mới kết thúc (giả sử theo kế hoạch là tuần 24 như trong biểu ₫ồ), ta nội suy và nới rộng ₫ồ thị sang phải cho ₫ến khi tiếp xúc trục x. Một số tiên ₫oán và ước lượng : ƒ Project A chứa 14 lỗi ₫ược tiên ₫oán là khách hàng sẽ tìm ₫ược nên sẽ có 2 lỗi mà khách hàng thực sự tìm ra → chi
10. 10.10 Kết chương Chương này ₫ã giới thiệu 1 số thuật ngữ ₫ược dùng trong hoạt ₫ộng quản lý quá trình kiểm thử phần mềm. Chúng ta cũng ₫ã giới thiệu 1 số kỹ thuật phổ dụng ₫ể hỗ trợ việc phát hiện lỗi như phát hiện lỗi mới dựa vào lỗi ₫ã phát hiện ₫ược, phát hiện lỗi mới dựa vào backlog, phát hiện lỗi mới dựa vào chùm lỗi Chúng ta cũng ₫ã giới thiệu 1 số kỹ thuật ₫ể quản lý hoạt ₫ộng kiểm thử phần mềm như dùng ₫ường cong phát hiện lỗi của các project trước, dùng biểu ₫ồ phân loại các nhóm lỗi của các project trước, dùng ₫ường cong Rayleight