Bài giảng Kiểm thử phần mềm - Chương 10: Phân tích và giải thích kết quả kiểm thử - Nguyễn Văn Hiệp

hối phần mềm. 
 Càng về cuối chu kỳ phát triển phần mềm thì loại lỗi 3 nên có 
mức ₫ộ tầm trọng ngày càng cao. 
10.3 Khám phá lỗi dựa vào backlog 
 Chúng ta ₫ã giới thiệu 2 thước ₫o hoạt ₫ộng kiểm thử : 
 ƒ thước ₫o 1 : số lượng và tỉ lệ testcase ₫ã thử/testcase 
 trong kế hoạch cho ta biết ta ₫ang ở giai ₫oạn nào của 
 quá trình kiểm thử. 
 ƒ 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. 
 Một thách thức khác cho ₫ội phân tích backlog là backlog ₫ược 
cập nhật theo chu kỳ (thí dụ hàng tuần), các lỗi mới phát hiện (do 
việc sửa lỗi trước ₫ây tạo ra) có thể ₫ược ₫ánh giá là tầm trọng và 
₫ược ưu tiên ₫ể ở ₫ầu backlog ₫ể cần sửa gấp. 
 Ở ₫iểm nối này có thể xảy ra tranh cải nảy lửa về chất lượng 
phần mềm vì chưa có chuẩn công nghiệp nào về vấn ₫ề này. 
 Trong phạm vi của môn học, chúng ta ₫ánh giá chất lượng 
phần mềm dựa vào những gì phần mềm thực hiện ₫ược so với 
những ₫ặc tả ₫ề ra ban ₫ầu. Cụ thể, nếu ₫ội phát triển phần mềm 
₫ã viết ₫ược phần mềm thỏa mãn các ₫ặc tả chức năng và ₫ội 
kiểm thử ₫ã xác thực ₫ược ₫iều này thì 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 của lỗi và công dụng 
 Bây giờ ta xem xét sự dung hoà của giá/lợi ích mang lại khi 
thêm 1 field thông tin mới vào từng record theo dõi lỗi trong bảng 
theo dõi lỗi. Ta gọi field này là 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 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. 
 Kết quả phân tích nguyên nhân gốc của 1 dự án phần mềm 
trong giai ₫oạn ₫ầu của công ₫oạn hiện thực, lúc này ₫ội phát triển 
₫ã sửa ₫ược 2000 lỗi. 
 Phân tích số liệu của bảng trong slide trước, ta thấy : 
 ƒ cần thiết phải xem lại các ₫oạn code và bảng thiết kế liên 
 quan gây ra 3 nhóm lỗi AP234, AP745 và GL106 (vì chúng 
 chiếm tới 45.5% lỗi) trước khi tiến hành bước hiện thực kế 
 tiếp. Lưu ý thêm là 2 nhóm lỗi AP234, AP745 có mối quan 
 hệ rất khắng khích vì chúng thuộc cùng 1 module chức 
 năng. 
 ƒ còn các lỗi thuộc nhóm AR218 có tỉ lệ tương ₫ối thấp nên 
 có thể ₫ược xem xét hay không tùy thuộc vào ₫ội kiểm thử 
 ₫ã tìm hiểu và nắm vững về vùng code gây lỗi chưa. 
 ƒ Có thể bỏ qua việc xem lại vùng code chứa các lỗi thuộc 
 các nhóm còn lại vì chúng chiếm tỉ trọng quá nhỏ. 
 Sở dĩ xuất hiện các nhóm lỗi chứa nhiều lỗi là vì : 
 ƒ 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. 
Bây giờ ta thấy : 
ƒ 3 nhóm lỗi quan trọng nhất chỉ chiếm tỉ lệ rất nhỏ (4.7%), 
 ₫iều này nói lên phần mềm ₫ã khá ổn ₫ịnh. 
ƒ các nhóm lỗi quan trọng của bước trước là AP234 và 
 GL106 vẫn còn trong danh sách, nhưng với tỉ lệ rất nhỏ. 
 Điều này cho thấy tính hiệu quả của việc dùng mã 
 earmark và việc xem xét lại vùng code tương ứng. 
ƒ do các nhóm lỗi quan trọng nhất chỉ chiếm tỉ lệ rất nhỏ 
 nên việc phân tích nguyên nhân gốc ở bước này là không 
 có tác dụng lớn như lúc trước nữa. Mặc dù vậy, thông tin 
 earmark vẫn 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 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. 
 Đường biểu diễn lỗi phát hiện trong project 200KLOC, ₫ược 
kiểm thử trong 24 tuần. 
 Đường cong miêu tả việc phát hiện lỗi của project trước cho 
chúng ta những thông tin chung cho hầu hết các project phần 
mềm : 
 ƒ lúc ₫ầu số lỗi phát hiện ₫ược thường rất nhiều và 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ày ₫ộ ổn ₫ịnh của phần mềm 
 còn rất thấp). 
 ƒ sau ₫ó số lỗi ₫ược phát hiện giảm dần khi phần mềm ngày 
 càng hoàn chỉnh và ổn ₫ịnh. 
 ƒ ₫iểm A miêu tả số lỗi ₫ược phát hiện nhiều nhất (là 749 
 lỗi). 
 ƒ ₫iểm B miêu tả tuần phát hiện lỗi nhiều nhất (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 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). 
 ƒ Xếp tầng số lỗi thuộc từng mức nặng/nhẹ trong tuần và vẽ 
 thành 1 cột cho tuần ₫ó. 
 Dựa vào kết quả của biểu ₫ồ ta rút ra ₫ược các kết luận : 
 ƒ Các lỗi có mức ₫ộ càng nặng thường xảy ra và ₫ược phát 
 hiện rất sớm vì lúc này project chưa có ₫ộ ổn ₫ịnh cao. 
 ƒ Mức ₫ộ lỗi phát hiện giảm dần về sau khi project ngày 
 càng ổn ₫ịnh hơn. 
10.7 Độ tương quan về lỗi do khách hàng phát hiện 
 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 trong các thông tin quan trọng là số lượng lỗi và tính chất lỗi 
₫ược phát hiện và phản hồi về bộ phận HelpDesk bởi khách hàng. 
 Ta dùng ₫ộ tương quan về lỗi do khách hàng phát hiện như 
sau : 
 ƒ Tỉ lệ lỗi tiên ₫oán/lỗi ₫ược khách hàng phát hiện thực tế 
 ƒ 487/70 = 6.9 
 Nhờ ₫ộ tương quan này mà ta có thể tiên ₫oán ₫ược số lượng 
lỗi mà khách hàng phát hiện ₫ược khi sử dụng project phần mềm 
sắp phát triển. Dựa vào số lượng lỗi này mà ta qui hoạch tương ₫ối 
chính xác số lượng và thời lượng làm việc của các nhân viên trong 
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ử. 
 Trong từng chu kỳ kiểm thử, ta tổng kết và vẽ số lượng lỗi phát 
hiện trực tiếp lên ₫ường biểu diễn của project trước ₫ể dễ dàng so 
sánh và nội suy thông tin khi cần. 
 Do các project có qui mô và tính chất khác nhau, số lượng lỗi 
phát hiện trong tuần ₫ầu sẽ khác nhau. 
 Thí dụ Project hiện hành là A có số lỗi phát hiện ₫ược nhiều 
hơn project cũ và tốc ₫ộ phát hiện lỗi trong các tuần ₫ầu cao hơn 
nhiều so với project cũ. Đây là xu thế mà ta mong muốn. Điều này 
có thể ₫ặt ra câu hỏi : tại sao ta kiểm thử hiệu quả hơn trước ? Câu 
trả lời có thể là do ta dùng nhiều tools kiểm thử tự ₫ộng hơn trước. 
 Thí dụ Project hiện hành là B có số lỗi phát hiện ₫ược ít hơn 
project cũ và tốc ₫ộ phát hiện lỗi cũng chậm hơn so với project cũ. 
Đây là xu thế mà ta không mong muốn. Điều này có thể ₫ặt ra câu 
hỏi : tại sao ta kiểm thử kém hiệu quả hơn trước ? Câu trả lời có 
thể là do ta bỏ ₫i hay làm thiếu 1 số hoạt ₫ộng mà project trước ₫ã 
làm. Sau khi xác ₫ịnh ₫ược nguyên nhân rõ ràng, ta sẽ khắc phục 
₫ể việc kiểm thử sẽ hiệu quả hơn cho các tuần còn lại. 
Khi project mới tiếp tục 
 Tiếp tục kiểm soát và vẽ ₫ường cong biểu diễn lỗi phát hiện 
cho tới cột mốc kế tiếp trong quá trình phát triển phần mềm. Tới 1 
lúc nào ₫ó, thường là khoảng 1/3 thời gian phát triển phần mềm, 
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 
 phí sửa là 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 là khách hàng sẽ 
 tìm ₫ược nên sẽ có 196 lỗi mà khách hàng thực sự tìm ra 
 → chi phí sửa là 196*14000 = 2744000$ (tăng hơn 
 1746000$ so với project trước). 
10.8 Đường cong Rayleight - Gunsight cho mẫu phát hiện lỗi 
 Làm sao biết ₫ược tốc ₫ộ phát hiện lỗi trong các project công 
nghiệp của các hãng lớn hiện nay ? Nhờ ₫ó so sánh, ₫ánh giá 
hoạt ₫ộng kiểm thử trong project của mình ? 
 Rất tiếc, ta khó lòng có ₫ược các thông tin xác thực này vì các 
công ty phần mềm có khuynh hướng dấu nhẹm, không công bố (vì 
nó ảnh hướng lớn ₫ến hình ảnh công ty). 
 Hiện nay nguồn cung cấp chủ yếu là ứng dụng ₫ường cong 
Rayleight. Đây là 1 công thức toá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 
này sai lệch so với giá trị thật của nhiều dự án phần mềm trong 5 
năm gần ₫ây dưới 10%. 
10.9 Các thước ₫o khác về sự theo dõi lỗi 
Các thước ₫o của hoạt ₫ộng phát triển phần mềm : 
 ƒ mã lỗi phát triển duy nhất. 
 ƒ ngày phát hiện lỗi phát triển. 
 ƒ mức ₫ộ trầm trọng của lỗi phát triển. 
 ƒ ngày sửa lỗi phát triển. 
 ƒ mã earcode của lỗi phát triển. 
Các thước ₫o của hoạt ₫ộng HelpDesk : 
 ƒ mã lỗi khách hàng duy nhất. 
 ƒ ngày phát hiện lỗi khách hàng. 
 ƒ mức ₫ộ trầm trọng của lỗi khách hàng. 
 ƒ ngày sửa lỗi khách hàng. 
 ƒ mã earcode của lỗi khách hàng. 
Thước ₫o khác : ODC (Orthogonal Defect Classifi cation) của hãng 
IBM. 
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...