Đột biến yếu

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Kỹ thuật kiểm thử đột biến và ứng dụng để kiểm thử các chương trình Java (Trang 41 - 43)

3.1. Giảm chi phí tính tốn

3.1.3.1. Đột biến yếu

Để tăng tỷ lệ đột biến, kiểm thử đột biến phải diệt các đột biến được thể hiện ở kết quả đầu ra khác với PUT khi nhận cùng đầu vào. Do đó, kiểm thử đột biến mạnh (strong mutation) tiếp tục thực hiện đột biến cho đến khi hoàn thành và so sánh các kết quả đầu ra tiếp theo hoặc các trạng thái chương trình. Nhưng điều này là lãng phí. Hãy so sánh một đột biến với PUT. Từng câu lệnh chương trình là giống nhau ngoại trừ câu lệnh đơn có chứa đột biến, dẫn đến các kết quả đầu ra có thể khác nhau, code “lỗi” này sẽ gây ra một số trạng thái khác ngay sau khi nó được thực hiện. Nếu khơng tìm thấy trạng thái khác thì đột biến sẽ

tiếp tục theo đường chương trình giống nhau và tạo ra đầu ra giống như PUT. Tuy nhiên, nếu tìm thấy trạng thái khác từ điểm này (vị trí tạo ra đột biến) thì điều này cho biết các kết quả đầu ra của chương trình có thể khác nhau và lưu việc thực hiện phần còn lại của đột biến. Đây là tiền đề về sau của kiểm thử đột biến yếu.

Đột biến yếu khác với đột biến mạnh khi so sánh các trạng thái của đột biến và PUT. Cả hai phương pháp có thể được phân loại khi so sánh ở các thái cực đối lập: đột biến yếu so sánh ngay sau câu lệnh đột biến, còn đột biến mạnh so sánh khi kết thúc chương trình. Để bao phủ các phương pháp khác nhau giữa những thái cực này, Woodward và Halewood [18] đã đề xuất ý tưởng đột biến vững chắc (firm mutation). Đột biến này so sánh các trạng thái của các chương trình tại một số điểm sau khi code bị đột biến được thực hiện, nhưng trước khi kết thúc chương trình. Bằng cách quyết định xem có nên diệt đột biến gần với kết thúc tự nhiên của chương trình hơn, nhằm cải thiện chất lượng dữ liệu thử trong khi giữ lại một số lợi ích thực thi từ đột biến yếu.

Những biến đổi này của đột biến yếu đã được nghiên cứu bằng thực nghiệm. Cụ thể, sử dụng phiên bản đã sửa đổi của Mothra, được gọi là Leonardo (quan sát đầu ra mong đợi không phải sau khi trả về nhưng vẫn trong quá trình hoạt động). Offutt và Lee [18] thực hiện các nghiên cứu về đột biến vững chắc bằng cách sử dụng bốn điểm so sánh khác nhau; (i) sau khi thực hiện biểu thức trong cùng nhất bao quanh đột biến đầu tiên; (ii) sau khi thực hiện câu lệnh đột biến đầu tiên - đột biến yếu truyền thống; (iii) sau khi thực hiện khối cơ bản đầu tiên (các lệnh tuần tự với các điểm vào và ra duy nhất) bao quanh đột biến; (iv) sau N lần thực hiện đột biến chứa khối cơ bản trong đó N là lớn hơn 1 và nhỏ hơn số lần khối cơ bản được thực hiện trong PUT - một đột biến bị diệt khi xuất hiện trạng thái khơng chính xác đầu tiên.

Offutt và Lee đã thực hiện hai nghiên cứu so sánh bốn phiên bản trên với đột biến mạnh. Nghiên cứu đầu tiên là tạo ra các tập dữ liệu thử có tỷ lệ đột biến vững chắc (firm-mutation scoring) 100% cho từng phương pháp vững chắc và thực hiện chúng bằng cách sử dụng đột biến mạnh để tạo ra toàn bộ tỷ lệ đột biến. Nghiên cứu thứ hai là tạo ra tập dữ liệu thử với các tỷ lệ đột biến ít hơn 90% và thực hiện bằng bốn phương pháp vững chắc để xác định các tỷ lệ đột biến vững chắc của chúng. Các kết quả khá thú vị. Bằng trực quan, phương pháp (iv) sẽ kiểm tra các trạng thái chương trình gần với kết thúc chương trình tự nhiên hơn và do đó gần với hệ thống đột biến mạnh hơn, cho thấy rằng phương pháp này cung cấp mạnh hơn tức là thu được dữ liệu thử chất lượng hơn. Đây

không phải là trường hợp duy nhất. Nghiên cứu đầu tiên cũng chỉ ra rằng điểm hiệu quả nhất để thực hiện các so sánh trạng thái là sau khi thực hiện câu lệnh bị đột biến (phương pháp ii) hoặc thực hiện khối cơ bản đầu tiên (phương pháp iii). Các kết quả từ nghiên cứu của Offutt và Lee cho thấy rằng đột biến yếu cũng có thể làm giảm đáng kể chi phí tính tốn, với tiết kiệm thường vượt trên 50% số lần thực hiện [18, 26].

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Kỹ thuật kiểm thử đột biến và ứng dụng để kiểm thử các chương trình Java (Trang 41 - 43)

Tải bản đầy đủ (PDF)

(76 trang)