36
4.2. Thực nghiệm
Tính đúng đắn của các công cụ sử dụng trong luận văn đã được khẳng định trong các báo cáo trước đó. Trong báo cáo nghiên cứu về các phương pháp định vị lỗi [8] của nhóm tác giả W. Eric Wong, phương pháp định vị lỗi quang phổ được tập trung nghiên cứu trong thời gian gần đây, chứng tỏ phương pháp này được quan tâm và luôn có những cập nhật thay đổi để cải thiện tính hiệu quả. Báo cáo cũng đồng thời so sánh các công thức quang phổ trong định vị lỗi và khẳng định Ochiai, là công thức quang phổ được sử dụng trong Gzoltar, có kết quả tốt hơn so với các công thức quan phổ khác như Tarantula. Báo cáo thực nghiệm của Gzoltar, áp dụng phương pháp định vị lỗi quang phổ định vị lỗi cho các chương trình của sinh viên [33] của nhóm tác giả Bob Edmison
và Stephen H. Edwards chỉ ra vì Gzoltar xác định điểm nghi ngờ trên nhiều dòng nên nếu chỉ xét một kết quả điểm nghi ngờ cao nhất thì có 73.3% là Gzoltar chỉ lỗi đúng, nếu xét hai kết quả có điểm nghi ngờ cao nhất thì có 84.4% chắc chắn lỗi nằm trong đó và Gzoltar chỉ lỗi đúng, nếu xét 3 kết quả điểm nghi ngờ cao nhất thì có tới 90% là Gzoltar chỉ lỗi đúng, nếu xét đến 4 kết quả điểm nghi ngời cao nhất thì cũng chỉ có 7% số lần Gzoltar không chỉ được lỗi. Trong báo cáo thực nghiệm của các Gzoltar nêu trên, miền thực nghiệm đều là các chương trình Java đơn giản như thực hiện trò chơi Minesweeper cổ điển với cấu trúc dữ liệu đơn giản sử dụng mảng hai chiều, nhấn mạnh tính logic của câu lệnh, ví dụ thứ hai là triển khai hai phiên bản của hàng đợi, một phiên bản sử dụng mảng nguyên thủy và một phiên bản sử dụng chuỗi liên kết các nút. Miền thực nghiệm trong bài toán này là các chương trình Java do học sinh viết, hầu hết là các chương trình đơn giản về cú pháp và ít chức năng, tương đương với miền thực nghiệm của các công cụ trên. JPlag cũng được nghiên cứu và chứng minh tính hiệu quả tốt hơn so với YAP3 và tương đương MOSS, là một sản phẩm thương mại trên thị trường [24]. Có thể khẳng định về mặt lí thuyết các công cụ được sử dụng trong luận văn cũng có hiệu quả với các chương trình của học sinh.
Mục đích thực nghiệm là xem xét tính hiệu quả của công cụ với các chương trình (code) cụ thể do học sinh viết để khẳng định việc tích hợp và điều chỉnh 2 công cụ trên đem lại hiệu quả đối với giáo viên và học sinh.
4.2.1. Chuẩn bị thực nghiệm
Do công cụ chưa hoàn thiện và đưa vào sử dụng trong trường phổ thông được nên bộ ví dụ thực nghiệm hiện tại chỉ bao gồm mười bài toán1. Với mỗi bài toán có đề bài, bộ các ca kiểm thử, code mẫu và ít nhất bốn code có lỗi cần kiểm tra. Các dữ liệu này được học viên thu thập trong quá trình dạy học trước đó và thiết kế cho phù hợp với yêu cầu, riêng với bài toán tìm ước chung lớn nhất và in ra dãy số nguyên tố ngoài những
37
dữ liệu do học viên chuẩn bị có sử dụng một số code mẫu và code lỗi của sinh viên lấy từ cơ sở dữ liệu OASIS của Trường Đại học Công nghệ. Quy trình thực hiện thực nghiệm với mỗi bài toán bao gồm các bước: xây dựng đề bài, xây dựng code mẫu, xây dựng bộ ca kiểm thử (tuân thủ điều kiện về ca kiểm thử được trình bày ở Mục 2.3), xây dựng các code lỗi, chạy mô-đun định vị lỗi, so sánh và đánh giá kết quả. Các code lỗi được đưa vào thực nghiệm có bài là sản phẩm học tập của học sinh, có bài do học viên xây dựng dựa trên kinh nghiệm dạy học của bản thân mô phỏng những lỗi mà học sinh hay mắc phải. Với gợi ý sửa lỗi chương trình, học viên xây dựng bộ sưu tập các code mẫu làm căn cứ gợi ý bước đầu khi hệ thống chưa hoạt động, chưa có bài đúng của học sinh được đưa vào làm gợi ý. Các bước chuẩn bị dữ liệu và tiến hành thực nghiệm hiện tại đang được học viên thực hiện thủ công nên với thời gian có hạn học viên mới chỉ chuẩn bị được dữ liệu thực nghiệm như trên. Khi hệ thống được triển khai thực tế dữ liệu code lỗi và code đúng để gợi ý sẽ nhiều lên sẽ làm tăng hiệu quả của gợi ý sửa lỗi.
4.2.2. Kết quả thực nghiệm
Trong báo cáo thực nghiệm của Gzoltar [33] đã chỉ ra 2 trường hợp lỗi. Một là GZoltar tạo ra cùng một điểm đáng ngờ cho nhiều dòng trong một chương trình qua ví dụ hàm tạo lớp bị lỗi trong trò chơi Minesweeper. Hai là không chỉ lỗi cho dòng lỗi trong ví dụ hàm tạo chuỗi. Đây là hai trường hợp xác định vị trí lỗi không hiệu quả. Hai trường hợp này được phân tích là do các câu lệnh có sự liên kết với nhau, một ca kiểm thử lỗi có thể chạy qua tất cả các câu lệnh. Do đó hiệu quả chỉ lỗi là không cao. Ngoài ra do tính chất liên kết giữa các câu lệnh nên kỳ vọng Gzoltar chỉ chính xác và duy nhất một câu lệnh lỗi là không khả thi. Để phù hợp với bài toán, dựa trên kinh nghiệm giảng dạy thực tế, học viên xây dựng tiêu chí đánh giá tính hiệu quả của công cụ định vị lỗi đối với các ví dụ thực nghiệm như sau:
i. Trong số các câu lệnh được xác định có nguy cơ lỗi có chính xác câu lệnh bị lỗi.
ii. Điểm số nghi ngờ của câu lệnh lỗi cao hơn những câu lệnh khác để hướng người dùng vào vị trí lỗi có nguy cơ cao nhất trước.
Căn cứ trên các tiêu chí trên, đánh giá hiệu quả định vị lỗi được phân thành ba mức: đúng, khó xác định và sai. Kết quả đúng đảm bảo cả hai tiêu chí trên, kết quả đảm bảo một tiêu chí đầu được đánh giá là khó xác định, còn lại là kết quả sai. Kết quả sai được hiểu là chỉ lỗi tất cả các câu lệnh trong chương trình hoặc không chỉ lỗi ở vị trí nào.
Tính hiệu quả của việc gợi ý sửa lỗi chỉ đánh giá theo hai mức đúng và khó xác định. Vì bước gợi ý sửa lỗi đưa ra gợi ý là một chương trình tương tự, cùng với những gợi ý có được từ bước định vị lỗi (đúng hoặc khó xác định) sẽ giúp học sinh sửa được lỗi, trường hợp này đánh giá hiệu quả gợi ý sửa lỗi là đúng. Trong một số trường hợp, bước định vị lỗi là sai, việc gợi ý trong trường hợp này được đánh giá là khó xác định.
38
Bởi lẽ đưa gợi ý một chương trình mà không có sự tập trung vào một số câu lệnh thì học sinh sẽ phải đi tự so sánh và sửa lỗi trong cả chương trình là bất khả thi, và thường có tỉ lệ tương đồng thấp (dưới 70%).
Kết quả thực nghiệm được thống kê như trong Bảng 4.6 với mười bài toán thực nghiệm. Mỗi bài thống kê số code lỗi, đánh giá kết quả định vị lỗi và gợi ý sử lỗi ở các cột tương ứng. Bài 1 có tám code lỗi; kết quả định vị lỗi có bốn kết quả đúng, ba kết quả khó xác định và một kết quả sai; kết quả gợi ý sửa lỗi có bảy kết quả đúng và một kết quả khó xác định. Bài 2 có bốn code lỗi; kết quả chỉ lỗi có ba kết quả đúng, một kết quả khó xác định; kết quả gợi ý sửa lỗi có ba kết quả đúng, một kết quả khó xác định. Chi tiết ở các bài toán khác như mô tả trong Bảng 4.6.
Bảng 4.6. Thống kê kết quả thực nghiệm
Code Định vị lỗi Gợi ý sửa lỗi
Bài 1: Ước chung lớn nhất
# 1 Khó xác định Đúng # 2 Khó xác định Đúng # 3 Khó xác định Đúng # 4 Đúng Đúng # 5 Sai Khó xác định # 6 Đúng Đúng # 7 Đúng Đúng # 8 Đúng Đúng Bài 2: Số nguyên tố #1 Đúng Đúng #2 Đúng Đúng # 3 Đúng Đúng # 4 Khó xác định Khó xác đị nh
Bài 3: Xếp loại học sinh
# 1 Khó xác định Khó xác định # 2 Khó xác định Đúng # 3 Đúng Đúng # 4 Đúng Đúng Bài 4: Số chính phương # 1 Đúng Đúng # 2 Khó xác định Khó xác định # 3 Khó xác định Đúng # 4 Đúng Đúng Bài 5: Sắp xếp mảng # 1 Đúng Đúng # 2 Khó xác định Đúng # 3 Khó xác định Đúng
39
Code Định vị lỗi Gợi ý sửa lỗi
# 4 Khó xác định Đúng Bài 6: Số Amrstrong #1 Đúng Đúng # 2 Đúng Đúng # 3 Đúng Đúng # 4 Khó xác định Khó xác định
Bài 7: Năm nhuận
# 1 Đúng Đúng
# 2 Đúng Đúng
# 3 Khó xác định Đúng
# 4 Sai Khó xác định
Bài 8: Tìm kiếm trong mảng
# 1 Đúng Đúng # 2 Đúng Đúng # 3 Khó xác định Khó xác định # 4 Khó xác định Khó xác đị nh Bài 9: Chỉ số BMI # 1 Đúng Đúng # 2 Đúng Đúng # 3 Khó xác định Đúng # 4 Khó xác định Đúng
Bài 10: Kiểm tra mật khẩu
# 1 Đúng Đúng
# 2 Đúng Đúng
# 3 Đúng Đúng
# 4 Khó xác định Đúng
Đánh giá hiệu quả của công cụ trên các bài toán thực nghiệm được mô tả tại Bảng 4.7. Tỉ lệ định vị lỗi đúng là 54.68%, học sinh có khả năng dựa trên kết quả chỉ lỗi đúng này để sửa chương trình. Trong trường hợp học sinh không sửa được chương trình sau khi được chỉ vị trí lỗi (43,75% chỉ lỗi khó xác định) thì chức năng gợi ý chương trình có tỉ lệ đúng 71,25% có thể giúp học sinh sửa lỗi. Tỉ lệ định vị lỗi sai là 3.75% và 28.75% gợi ý sửa lỗi khó xác định là những hạn chế của công cụ. Tuy nhiên với những dữ liệu có được có thể đánh giá việc tích hợp hai công cụ có hiệu quả với bài toán thực tế, có thể sử dụng được và hỗ trợ phần nào cho giáo viên trong quá trình dạy học.
Đồ i vợ i như ng chượng trình đánh giá là đị nh vị lồ i khó xác đị nh thì gợ i ý sư a lồ i càng hiề u quá . Tuy nhiên không phá i gợ i ý nào cũ ng có thề dùng đượ c, theo kinh nghiề m cũ a hồ c viên như ng chượng trình gợ i ý có đồ tượng đồ ng trên 80% mợ i có thề sư dũ ng đượ c.
40
Bảng 4.7. Đánh giá hiệu quả của công cụ trên các bài toán thực nghiệm
BÀI
CHỈ LỖIĐịnh vị lỗi Gợi ý sửa lỗi
Đúng Khó xác định Sai Đúng Khó xác định Bài 1 4 (50%) 3 (37,5%) 1 (12.5%) 7 (87.5%) 1 (12.5%) Bài 2 3 (75%) 1 (25%) 0 3 (75%) 1 (25%) Bài 3 2 (50%) 2 (50%) 0 3 (75%) 1 (25%) Bài 4 2 (50%) 2 (50%) 0 3 (75%) 1 (25%) Bài 5 1 (25%) 3 (75%) 0 4 (100%) 0 Bài 6 3 (75%) 1 (25%) 0 3 (75%) 1 (25%) Bài 7 2 (50%) 1 (25%) 1 (25%) 3 (75%) 1 (25%) Bài 8 2 (50%) 2 (50%) 0 2 (50%) 2 (50%) Bài 9 2 (50%) 2 (50%) 0 2 (50%) 2 (50%) Bài 10 2 (50%) 2 (50%) 0 2 (50%) 2 (50%) Trung bình 52,5% 43,75% 3,75% 71,25% 28,75% 4.3. Thảo luận
Quá trình nghiên cứu và triển khai thực nghiệm của luận văn đã thu được một số kết quả. Tìm kiếm và xác định được công cụ phù hợp với yêu cầu bài toán. Xây dựng được công cụ lõi của bài toán đặt ra, giúp xác định vị trí lỗi và gợi ý sửa lỗi cho học sinh. Tiến hành thực nghiệm để khẳng định hiệu quả và sự phù hợp của việc tích hợp các công cụ được lựa chọn. Công cụ này có thể ứng dụng trong thực tế, hỗ trợ giáo viên trong quá trình dạy học, nâng cao hiệu quả thực hành của học sinh, tạo môi trường để học sinh học tập chủ động và tích cực giúp phát huy năng lực của các em.
Các kết quả thực nghiệm thu được như đã trình bày trong Mục 4.2 chưa phải là một kết quả khả quan, tỉ lệ định vị lỗi đúng chỉ đạt 54.68%, nếu kết hợp với gợi ý sửa lỗi đúng thì khả năng học sinh sửa được bài là 71.25%. Mặc dù kết quả trên chưa khả quan nhưng đã có ý nghĩa vì sẽ giúp ích phần nào cho giáo viên trong quá trình dạy học. Thay vì giáo viên phải tự mình hỗ trợ cho từng học sinh thì giờ đây nhờ có công cụ hỗ
41
trợ giáo viên cũng sẽ bớt được một phần công sức và học sinh học tập cũng chủ động và tích cực hơn. Kết quả này là cơ sở để học viên tiếp tục nghiên cứu để xây dựng các giải pháp tốt hơn trong tương lai, là nền tảng để phát triển một hệ thống hoàn chỉnh hỗ trợ học sinh học lập trình.
Nguyên nhân của kết quả trên có thể do một số lí do sau đây:
Đầu tiên là do số lượng các bài thực nghiệm chưa nhiều nên chưa bao quát được tất cả các trường hợp lỗi có thể xảy ra. Trong tương lai học viên sẽ tiến hành thực hiện với nhiều bài hơn, bài được lấy từ nguồn bài tập của học sinh sẽ đa dạng hơn để đánh giá thì kết quả có thể sẽ tốt hơn.
Thứ hai, tỉ lệ định vị lỗi đúng còn thấp là do ba yếu tố: thuật toán, bộ các ca kiểm thử và tính liên đới của các câu lệnh. Thuật toán mà Gzoltar sử dụng để định vị lỗi là Ochiai, tuy được đánh giá là có hiệu quả nhưng cũng như các thuật toán định vị lỗi khác thì không có thuật toán nào là hoàn hảo cả. Bộ các ca kiểm thử sử dụng để định vị lỗi được sinh dựa vào đặc tả bài toán. Nhưng code lỗi của học sinh ngẫu nhiên và đa dạng do đó bộ các ca kiểm thử có thể không bao phủ được hết các trường hợp do đó không phát hiện được lỗi. Các chương trình của học sinh thường gồm một số hàm có thể gọi tới nhau, nếu lỗi sai tại một hàm thì kết quả chỉ lỗi có thể ở cả các hàm liên đới tới nó, do đó khó xác định chính xác vị trí lỗi.
Thứ ba, việc gợi ý sửa lỗi phụ thuộc vào số lượng chương trình đúng được đưa ra làm gợi ý do đó nếu số lượng các bài mẫu ít có khả năng sẽ không tìm được chương trình gợi ý đủ tốt. Kết quả này có thể cải thiện khi hệ thống được triển khai thực tế, các chương trình đúng của học sinh nộp vào bộ sưu tập nhiều lên. Việc gợi ý sửa lỗi lí tưởng là phải tìm được các miếng vá (đoạn code) tương ứng vị trí lỗi để đưa ra gợi ý, là hướng nghiên cứu tiếp theo của học viên trong tương lai.
Để học sinh sử dụng kết quả gợi ý được hiệu quả nhất, giáo viên cần hướng dẫn học sinh cách đọc và sử dụng kết quả chỉ lỗi và kết quả so sánh sao cho hiệu quả nhất. Các lưu ý dưới đây là mang ý nghĩa định hướng cho học sinh trong quá trình sử dụng công cụ.
Việc sử dụng kết quả định vị lỗi cần lưu ý: Câu lệnh có điểm nghi ngờ cao là câu lệnh có khả năng lỗi cao, do đó học sinh nên tập trung sửa một hoặc một số nội dung được cho là có nguy cơ nhất và chạy lại đánh giá chứ không nên tìm cách sửa tất cả các lỗi cùng lúc. Do các câu lệnh có sự liên kết với nhau, hoặc trường hợp một ca kiểm thử chạy qua tất cả các câu lệnh cũng có khả năng làm cho các câu lệnh có chỉ số lỗi tương đương, nên nếu xảy ra trường hợp này học sinh không cần hoang mang mà cần tự đánh giá lại từng phần trong bài hoặc sử dụng gợi ý chương trình tương tự để sửa lỗi.
Việc sử dụng kết quả gợi ý sửa lỗi cần lưu ý: Tỉ lệ trùng lắp càng cao thể hiện chương trình có độ tương đồng càng lớn, có thể dùng để tham khảo. Do bản chất của
42
thuật toán so sánh là so sánh các Token đại diện chứ không phải so sánh từng từ với nhau, nên dù bài có tỉ lệ tương đồng cao nhưng không giống hệt nhau. Điều này là hoàn toàn hợp lí. Trong quá trình sử dụng gợi ý học sinh cần căn cứ vào thứ tự câu lệnh và điểm nghi ngờ có được từ bước trước, cùng với chương trình đúng được gợi ý mà xem xét và sửa lỗi chương trình của mình. Hoạt động này đòi hỏi học sinh phải tư duy chứ không chỉ chép bài là được, do đó giúp phát triển năng lực của học sinh.
43
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN TƯƠNG LAI
Với quá trình nghiên cứu và hoàn thiện luận văn học viên đã học tập thêm được