Chương trình Số phiên bản lỗi Số dịng lệnh Số dòng lệnh thực thi Số ca kiểm thử Bộ Si eme ns print_tockens 7 565 195 4130 print_tockens2 10 510 200 4115 schedule 9 412 152 2650 schedule2 10 307 128 2710 replace 32 563 244 5542 tcas 41 173 65 1608 tot_info 23 406 122 1052 grep 18 13229 3361 810 sed 15 11990 3727 370 space 38 9123 3656 13585
Bộ Siemens [34] đã được sử dụng trong các thử nghiệm của nhiều nghiên cứu liên quan đến định vị lỗi. Bộ Siemens bao gồm 7 chương trình với 132 phiên bản chương trình bị lỗi và tất cả các ca kiểm thử được tải xuống từ Siemens Suite. Trong số 132 phiên bản bị lỗi này, ba phiên bản đã bị loại khỏi thử nghiệm: phiên bản 9 của vì tất cả các bài kiểm tra đều vượt qua phiên bản này và do đó khơng
có bài kiểm tra nào bị lỗi; phiên bản 4 và 6 của ‘‘print_tokens” vì lỗi nằm trong tệp header thay vì tệp C.
Chương trình grep [34] với phiên bản 2.2 có 810 ca kiểm thử và 18 lỗi. Chương trình sed [34] với phiên bản 4.1.5 có 370 ca kiểm thử và 15 lỗi. Chương trình Space [34] có 9123 dịng mã lệnh. Tuy nhiên, nếu ta kết hợp các câu lệnh nhiều dịng làm một dịng mã nguồn, ta có 3656 câu lệnh thực thi. Chương trình Space có 38 phiên bản bị lỗi và bộ 13585 ca kiểm thử được sử dụng trong nghiên cứu này. Ba phiên bản bị lỗi không được sử dụng trong thử nghiệm của luận văn vì khơng có ca kiểm thử nào khơng thành cơng trên các phiên bản bị lỗi này, trong khi tám phiên bản bị lỗi bị loại trừ vì nhiều lý do khác nhau.
Bộ chương trình dữ liệu của luận văn bao gồm các chương trình số lượng dịng lệnh ít như chương trình tcas (173 dịng lệnh), schedule2 (307 dịng lệnh) và các chương trình có số lượng dịng lệnh lớn như grep với hơn 13 nghìn dịng lệnh. Số lượng ca kiểm thử cũng có số lượng trải dài từ 370 ca kiểm thử tới số lượng ca kiểm thử lớn 13585 ca kiểm thử. Ngoài các lỗi chế tác như bộ siemens, chương trình grep, chương trình sed, luận văn cũng đã thử nghiệm với các lỗi thực tế của chương trình space.
4.1.2 Chỉ số đánh giá
Kỹ thuật định vị lỗi T lấy đầu vào một chương trình P và một bộ thử nghiệm có ít nhất một lần thử nghiệm khơng đạt và nó tạo ra dưới dạng danh sách được sắp xếp các vị trí chương trình đáng ngờ, chẳng hạn như dịng, câu lệnh hoặc khai báo. Để so sánh được kỹ thuật định vị lỗi T có hiệu quả hơn kỹ thuật định vị lỗi T’, ta cần có chỉ số đánh giá phù hợp. Có rất nhiều chỉ số để đánh giá về kỹ thuật định vị lỗi được để xuất như: LIL, T-score, EXAM, Expense, …
LIL (Locality Information Loss) [35] đo lường hiệu quả của kỹ thuật định vị lỗi để sửa lỗi chương trình tự động. Chỉ số LIL được Seokhyeon Moon và cộng sự đề xuất để đo lường sự mất mát thơng tin giữa vị trí thực tế của lỗi và vị trí được dự đốn từ kỹ thuật định vị lỗi.
EXAM [23] tính tồn tỷ lệ phần trăm các thành phần mà một nhà phát triển phải kiểm tra cho đến khi tìm ra thành phần bị lỗi đầu tiên trên tổng các câu lệnh của chương trình.
Expense [3] tính tồn tỷ lệ phần trăm các thành phần mà một nhà phát triển phải kiểm tra cho đến khi tìm ra thành phần bị lỗi đầu tiên trên tổng các câu lệnh được thực thi của chương trình.
4.2 Kết quả và đánh giá
Luận văn sử dụng chỉ số đánh giá Expense để đánh giá hiệu quả của các loại phổ trong định vị lỗi. Luận văn so sánh hiệu quả của phổ ESHS, DHS, DHS-def, DHS-use khi sử dụng 12 chỉ số xếp hạng được mô tả trong Bảng 2.2.
Các Hình 4-1, Hình 4-2, Hình 4-3, Hình 4-4, Hình 4-5, Hình 4-6 mơ tả biểu đồ so sánh điểm Expense của các phổ tương ứng với kỹ thuật tương ứng barinel, drt, dstar, jaccard, kulczynski2, mccon, minus, ochiai, op, tarantula, wong3 và zoltar. Với mỗi biểu đồ, trục x thể hiện phần trăm mã được kiểm tra, trục y thể hiện phần trăm phiên bản lỗi được định vị bằng cách kiểm tra lượng mã nhỏ hơn hoặc bằng tương ứng với giá trị trục x.
(a) Barinel (b) DRT
Hình 4-1: Điểm Expense của Barinel và DRT
Các phổ DHS thể hiện hiệu quả tốt hơn phổ ESHS với hầu hết chỉ số xếp hạng. Với các chỉ số xếp hạng Mccon, Op và Wong3 sự chênh lệch này không nhiều. Đường đồ thị điểm Expense của các chỉ số xếp hạng này gần như tương đồng nhau. Ngược lại, Barinel, Dstar, Jaccard, Ochiai và Tarantula thể hiện chênh lệch rõ rệt, điều này tương đương khả năng định vị lỗi với các phổ DHS hiệu quả hơn nhiều. Như Hình 4-1, chúng ta có thể xác định được 83% lượng lỗi bằng cách kiểm tra 30% mã chương trình khi sử dụng kỹ thuật Barinel và phổ DHS-use. Số lượng mã cần kiểm tra nhiều khi dùng kỹ thuật Barinel và phổ ESHS, 40% số câu
lệnh của chương trình. Số lượng mã cần kiểm tra của phổ DHS và DHS-def khoảng 35%.
(a) Dstar (b) Jaccard
Hình 4-2: Điểm Expense của Dstar và Jaccard
Tương tự như Barinel, Dstar và Jaccard cũng thể hiện hiệu quả định vị lỗi với phổ DHS-use và DHS-def (như trong Hình 4-2). Khi kiểm tra 40% mã chương trình, phổ DHS-use có thể chỉ ra 81% lỗi với kỹ thuật Dstar, phổ DHS có thể chỉ ra 76% lỗi. Phổ ESHS và DHS có hiệu quả kém hơn khi chỉ có thể chỉ ra 73% lỗi. Kỹ thuật Jaccard và phổ ESHS lại tìm được nhiều lỗi hơn khi kiểm tra 50% câu lệnh của chương trình. Phổ ESHS tìm được 91% số lỗi, nhiều hơn 5% so với các phổ DHS, DHS-def và DHS-use.
(a) Kulczynski2 (b) Mccon
(a) Minus (b) Ochiai
Hình 4-4: Điểm Expense của Minus và Ochiai
(a) Op (b) Tarantula
Hình 4-5: Điểm Expense của Op và Tarantula
Kỹ thuật Tarantula cho thấy hiệu quả khác biệt rõ rệt giữa các loại phổ được thể hiện trong Hình 4-5. Phổ DHS-use ln thể hiện hiệu tốt hơn các phổ dựa trên cặp def-use còn lại như DHS và DHS-def. Đường điểm Expense của phổ DHS- use luôn nằm bên trên các đường điểm Expense của phổ DHS và DHS-def. Ở khoảng kiểm tra trước 50% mã chương trình, điểm Expense của phổ DHS-use cũng xác định được nhiều lỗi hơn các loại phổ còn lại.
(a) Wong3 (b) Zoltar
Hình 4-6: Điểm Expense của Wong3 và Zoltar
Các Hình 4-7, Hình 4-8, Hình 4-9, Hình 4-10 so sánh hiệu quả của tất cả các kỹ thuật định vị lỗi (hay chỉ số xếp hạng) với phổ ESHS, DHS, DHS-use và DHS- def. Với tất cả các phổ, các kỹ thuật tìm ra số lượng lỗi gần như tương đồng nhau. Số lượng lỗi tìm ra giữ các kỹ thuật chênh lệch không quá 10% tổng lượng lỗi của thử nghiệm.
Với phổ ESHS, kỹ thuật Wong3 có hiệu quả thấp nhất và kỹ thuật Barinel và DRT có hiệu quả cao nhất. Với cách kiểm tra 60% mã chương trình, các kỹ thuật Barinel và DRT định vị lỗi hiệu quả hơn 10% so với kỹ thuật Wong3.
Hình 4-7: Hiệu quả định vị lỗi của các kỹ thuật với phổ ESHS
Chỉ số xếp hạng Ochiai có đường điểm Expense ổn định hơn với các kỹ thuật khác khi kết hợp với các phổ DHS, DHS-def và DHS-use.
Hình 4-9: Hiệu quả định vị lỗi của các kỹ thuật với phổ DHS-def
Hình 4-10: Hiệu quả định vị lỗi của các kỹ thuật với phổ DHS-use
Cơng cụ Zoltar khơng cịn sử dụng được do khơng được duy trì cập nhật. Nên luận văn không thể thực hiện thực nghiệm so sánh hiệu quả điều chỉnh mã nguồn giữa HiFa và Zoltar. Thay vào đó, luận văn đã thực hiện so sánh HiFa và GCC, một công cụ hỗ trợ điều chỉnh mã nguồn.
Bảng 4.2 thể hiện so sánh kích thước tệp thực thi của từng chương trình và kích thước dữ liệu phổ thu thập được sau khi thực thi bộ kiểm thử giữ công cụ
HiFa và GCC. Cột đầu tiên là danh sách các chương trình thử nghiệm. Các cột 2, 3, 4 thể hiện kích thước tệp thực thi tính theo byte tương ứng với biên dịch bởi GCC, biên dịch bởi HiFa cho phổ ESHS và biên dịch với HiFa cho phổ DHS. Các cột tiếp theo 4, 5 và 6 là kích thước phổ dữ liệu thu được sau khi thực hiện kiểm thử tương ứng với cách điều chỉnh mã nguồn bằng GCC, bằng HiFa cho phổ ESHS và HiFa cho phổ DHS. GCC là trình biên dịch cho ngơn ngữ C/C++, hỗ trợ điều chỉnh mã nguồn để lấy thông tin thực thi của từng câu lệnh. Kết quả so sánh cho thấy các tệp thực thi được biên dịch bằng cơng cụ HiFa có kích thước lên hơn nhiều so với tệp thực thi được biên dịch bằng GCC. Tệp thực thi được biên dịch bởi HiFa có kích thước lớn hơn 3 – 4 lần kích thước tệp thực thi được biên dịch bằng GCC. Tệp thực thi của phổ DHS cũng có kích thước lớn hơn của phổ ESHS. Sự khác biệt này là do số lượng cặp def-use luôn nhiều hơn số câu lệnh của chương trình, nên cần bổ sung nhiều thơng tin hơn để có thể lấy phổ DHS. Tuy có kích thước tệp thực thi cao hơn, nhưng các chương trình được điều chỉnh bởi HiFa tạo ra tệp dữ liệu phổ thấp hơn so với GCC. Kích thước dữ liệu phổ thu được sau thi kiểm thử chương trình điều chỉnh bằng GCC cao hơn 4-5 lần chương trình điều chỉnh bằng HiFa cho phổ ESHS. Chương trình có số lượng testcase càng lớn thì sự chênh lệch này càng cao, chương trình replace có 5542 testcase thì kích thước tệp dữ liệu phổ chênh lệch là 5.8 lần, chương trình tot_info có bộ kiểm thử nhỏ hơn (1052 testcase) thì chênh lệch chỉ là 3.3 lần. Từ kết quả này cho thấy phương pháp điều chỉnh mã nguồn để thu thập thơng tin phổ của HiFa có hiệu quả tốt hơn GCC, đặc biệt với các chương trình có bộ kiểm thử lớn.