Bên cạnh chi phí tính tốn q tốn kém, khả năng tự động hóa cũng là một trong những rào cản đối với kiểm thử đột biến để được chấp nhận trong ngành công nghiệp phần mềm. Các rào cản này có thể được phân loại như là những khó khăn về tự động hóa với thực trạng hiện tại, đòi hỏi nỗ lực đáng kể từ kiểm thử viên.
Trước hết, dữ liệu thử phải được tạo ra để diệt các đột biến. Trong khi đó, đối với phần lớn các đột biến, dữ liệu thử ngẫu nhiên nào sẽ đáp ứng đủ (cung cấp bằng cách sử dụng các bộ sản sinh dữ liệu thử ngẫu nhiên), một tỷ lệ nhỏ các đột biến khó để diệt đòi hỏi phải rà soát lại mã nguồn và các dữ liệu thử được tạo ra bằng thủ công để xác định các lỗi. Đây là vấn đề tốn nhiều thời gian và đầy thử thách. Hơn nữa, tỷ lệ đột biến được tính tốn khi đo lường chất lượng dữ liệu thử phải giảm số lượng các đột biến tương đương. Đây là vấn đề được
cho là không giải được [4], xác định các đột biến tương đương theo cách truyền thống được thực hiện bằng tay. Một lần nữa, đây lại là công việc tốn kém hơn nữa, cản trở sự thu hút của ngành công nghiệp.
Bên cạnh các đột biến tương đương, tất cả các đột biến khác đã được hiển thị để tạo các đầu ra không đúng so với đầu ra đúng của chương trình gốc. Do đó, chương trình gốc phải cung cấp các kết quả đúng để bắt đầu, được xác định bởi
oracle (một quy trình tự động hoặc bằng tay xác định đầu ra đúng cho bất kỳ dữ
liệu thử nào). Tuy nhiên, quyết định đầu ra được thực hiện là đúng với một đầu vào thường rất khó khăn, và được gọi là vấn đề oracle [18].
3.2.1. Tạo dữ liệu thử tự động
Một trong những nhiệm vụ kỹ thuật khó nhất trong kiểm thử phần mềm là tạo ra các dữ liệu thử cần thiết để đáp ứng các tiêu chuẩn kiểm thử. Để thực hiện được điều này. Offutt đã phát triển kỹ thuật kiểm thử dựa trên ràng buộc (CBT) để tạo ra các tập dữ liệu thử chất lượng dựa trên đột biến [26]. Kỹ thuật này dựa trên khái niệm để diệt được đột biến thì dữ liệu thử phải thỏa mãn ba điều kiện:
1. Điều kiện có thể đạt đến được: Các chương trình đột biến khác so với
PUT bởi một lượng nhỏ thường được chứa trong một câu lệnh đơn. Vì tất cả các câu lệnh khác đều giống nhau, câu lệnh bị đột biến này phải chịu trách nhiệm về một sự khác biệt trong các đầu ra của chương trình. Vì vậy, để dữ liệu thử phân biệt đột biến từ PUT thì câu lệnh bị đột biến này phải đạt đến được (tức là câu lệnh bị đột biến phải được kích hoạt). 2. Điều kiện cần: Khi đạt đến được câu lệnh bị đột biến, điều kiện cần là
câu lệnh đột biến phải gây ra một trạng thái chương trình bên trong không đúng ngay sau khi nó được thực hiện. Nếu khơng thì đột biến khơng thể thất bại vì với tất cả các câu lệnh khác đều giống nhau, khơng có câu lệnh kế tiếp nào có thể gây ra trạng thái bên trong để khác biệt. 3. Điều kiện đủ: Cuối cùng, dữ liệu thử là đủ nếu như trạng thái không
đúng truyền qua đột biến dẫn đến thất bại khi kết thúc. Nếu bất kỳ câu lệnh nào sửa chữa trạng thái bên trong thì hoặc là đột biến tương đương hoặc dữ liệu thử không đủ chất lượng trong việc gây ra đầu ra của chương trình khác biệt.
Các điều kiện này đã được sử dụng bởi bộ sản sinh dữ liệu tự động
Godzilla để tạo ra các tập dữ liệu thử cho Mothra [8]. Godzilla mô tả các điều
kiện bằng miền đầu vào dựa trên các biểu thức đại số được gọi là các ràng buộc, để xác nhận từng điều kiện được đáp ứng. Các ràng buộc về điều kiện có thể đạt đến được được biểu diễn bằng các biểu thức đường dẫn mô tả tất cả các đường dẫn tới câu lệnh bị đột biến. Tương tự như vậy, các ràng buộc về điều kiện cần xác nhận rằng liệu việc thực hiện câu lệnh đột biến có dẫn đến trạng thái bên trong không đúng hay không. Tuy nhiên, không thể tạo ra các ràng buộc về điều kiện đủ vì chúng địi hỏi phải biết trước kết quả của đường dẫn hoàn chỉnh mà chương trình sẽ lấy. Điều này là không thể giải được [18]. Thay vào đó, Godzilla kết hợp các ràng buộc về điều kiện có thể đạt đến được và điều kiện cần, và giải quyết vấn đề này để cung cấp dữ liệu thử thực hiện câu lệnh bị đột biến và tạo ra trạng thái bên trong không nhất quán. Đáng lưu ý, dữ liệu thử có thể tạo ra trạng thái bên trong không nhất quán trong đột biến mà sau đó được sửa chữa để tạo ra đầu ra mong muốn; đột biến sẽ bị diệt khi nó vẫn cịn sống. Các kết quả thực nghiệm trong [26] cho rằng các phương pháp CBT tạo ra dữ liệu thử có tỷ lệ đột biến cao, diệt được trên 90% đột biến.
3.2.2. Xác định các đột biến tƣơng đƣơng tự động
biến tương đương hiển thị đầu ra giống như chương trình gốc cho tất cả các đầu vào có thể có và phải được loại bỏ trước khi tính tốn tỷ lệ đột biến. Nếu chúng không bị loại bỏ, tỷ lệ các đột biến bị diệt không bao giờ có thể đạt được 100% (trong trường hợp các đột biến tương đương vẫn cịn tồn tại), do đó sẽ làm giảm sự tin tưởng của kiểm thử viên vào tính đúng đắn của PUT và dữ liệu thử.
Một tập dữ liệu thử diệt ít hơn 100% các đột biến được tạo ra hoặc là không đủ để diệt các đột biến còn lại, hoặc các đột biến còn lại là tương đương, hoặc cả hai. Tóm lại, kiểm thử viên sẽ không biết chắc chắn về những tình huống phát sinh trừ khi họ có thể xác định được các đột biến tương đương. Tuy nhiên, các đột biến tương đương phải được loại bỏ và do đó các hệ thống đột biến truyền thống trở thành gánh nặng cho các kiểm thử viên vì phải xác định các đột biến tương đương thủ công dễ bị lỗi. Tệ hơn nữa, có nhiều tiềm năng cho một số lượng lớn các đột biến tương đương tồn tại, mỗi đột biến phải được xác định riêng rẽ.
Offutt và Craft [26] thực hiện các thuật toán dựa trên luồng dữ liệu và các kỹ thuật tối ưu hóa trình biên dịch để xác định các chương trình tương đương một cách tự động. Thực tế, các kỹ thuật tối ưu hóa trình biên dịch sử dụng các phép biến đổi tối ưu hóa chương trình để tạo ra các chương trình tương đương bằng cách hoặc là tối ưu hóa hoặc tái tối ưu hóa chương trình gốc, do đó nếu đột biến thỏa mãn quy tắc tối ưu hóa chương trình thì nó có thể là tương đương [18]. Ý tưởng tối ưu hóa trình biên dịch này được đề xuất đầu tiên bởi Baldwin và Sayward trong [18]. Offutt và Craft sử dụng sáu kỹ thuật tối ưu hóa trình biên dịch để xác định các đột biến tương đương được mô tả chi tiết hơn trong [26]:
Xác định các đoạn mã chương trình chết (dead code) - Hình thức rõ ràng nhất: các đoạn mã lệnh khơng thể thực hiện được có chứa câu lệnh được sữa đổi sẽ là tương đương với PUT. Xác định thông qua đồ thị luồng điều khiển.
Truyền hằng số (constant propagation) - Một biến có giá trị được xác định bằng hằng số khi chạy sẽ tạo ra các đột biến tương đương trong một số trường hợp. Ví dụ, hãy xem xét tốn tử đột biến ABS. Một câu lệnh đột biến thực hiện giá trị tuyệt đối của một hằng số ( 0) sẽ luôn luôn tạo ra một đột biến tương đương.
Truyền bất biến (invariant propagation) - Bất biến là một quan hệ đúng giữa hai biến hoặc một biến và một hằng số trong đó được xác định tại một điểm cụ thể trong chương trình. Ví dụ, để diệt một đột biến thay thế
được chúng đều bằng nhau tại điểm này, thì đột biến có khả năng là tương đương.
Xác định biểu thức con chung - Sử dụng kết hợp với kỹ thuật truyền bất biến, xác định các biến tương đương dựa trên các biểu thức con chung. Ví dụ, nếu A = B + C - D và X = B + C - D thì A == X sau khi gán X. Thông tin này được sử dụng bằng kỹ thuật truyền bất biến để xác định các đột biến tương đương.
Xác định bất biến vòng lặp - Tối ưu hóa code thường di chuyển mã bất biến ra bên ngồi vịng lặp. Nếu đột biến thay đổi vị trí này (tức là di chuyển mã vào bên trong hay ra bên ngồi vịng lặp) thì nó là tương đương.
Nâng lên và hạ xuống (hoisting and sinking) - Tối ưu hóa chương trình bằng cách di chuyển đoạn mã chương trình được thực hiện nhiều lần đến vị trí mà nó được thực thi một lần. Các đột biến có ảnh hưởng bởi vị trí này là tương đương.
Offutt và Craft đã kiểm tra việc thực hiện của chúng trên 15 chương trình thử nghiệm. Các kết quả mà họ nhận được là xác định được từ 0 đến 100% các đột biến tương đương, mặc dù giá trị trung bình là khoảng 10%. Tuy nhiên, xét các đột biến tương đương thường phải được xác định bằng tay, phương pháp này được thực hiện để giảm bớt gánh nặng cho các kiểm thử viên.
3.2.3. Vấn đề Oracle
Một vấn đề quan trọng đối với kiểm thử đột biến và kiểm thử nói chung là xác định liệu đầu ra từ việc thực hiện PUT với một dữ liệu thử cụ thể là chính xác hay khơng. Thường thì cơng việc này được làm thủ cơng, địi hỏi rất nhiều nỗ lực của kiểm thử viên. Tình trạng này trở nên xấu hơn khi các bộ sản sinh dữ liệu thử tự động có liên quan, có thể tạo ra các dữ liệu thử mơ hồ, nghĩa là đầu ra của chúng rất khó để xác định. Lý tưởng nhất là kiểm thử viên yêu cầu một quy trình tự động mà có thể quyết định tính đúng đắn của dữ liệu thử dựa trên các đặc tả của chương trình. Chúng được gọi là các Oracle. Thật không may, không phải là khi nào cũng có thể xác định các quy trình như vậy, đây là vấn đề Oracle
[18]. Ví dụ, có thể có trường hợp, các đầu ra đó khơng được xác định cho tồn bộ miền đầu vào. Nghiên cứu này giả sử rằng tồn tại một Oracle thích hợp cho chương trình đang được kiểm thử, do đó tránh được vấn đề Oracle.
3.3. Kết luận
Kiểm thử đột biến được được xem là một kỹ thuật kiểm thử đơn vị mạnh để tìm ra tập dữ liệu thử hiệu quả giúp phát hiện các lỗi trong chương trình. Tuy nhiên, kiểm thử đột biến cịn có một số hạn chế về chi phí tính tốn và tự động hóa, được phân tích ở chương 2.
Nhằm nâng cao hiệu quả của kiểm thử đột biến, các nghiên cứu đã tập trung vào ba phương pháp để giảm chi phí tính tốn: làm ít hơn, làm nhanh hơn và làm thông minh hơn. Tăng tự động hóa trong kiểm thử đột biến mắc phải ba trở ngại chính: tạo ra các dữ liệu thử, xác định các đột biến tương đương, và xác định tính đúng đắn đầu ra của chương trình. Những vấn đề này cần phải được khắc phục, ở một mức độ nhất định, cho ngành công nghiệp chấp nhận kiểm thử đột biến như một công cụ hữu hiệu.
Offutt đã phát triển phương pháp kiểm thử dựa trên ràng buộc (CBT) [80] để sản sinh dữ liệu thử tự động, các kết quả thực nghiệm là khá triển vọng, với CBT diệt được trung bình 97% các đột biến. Các kỹ thuật dựa trên tối ưu hoá trình biên dịch đã được áp dụng để phát hiện đột biến tương đương, các kết quả trong [83] khi thực hiện kiểm tra trên 15 chương trình, cho thấy các phương pháp này phát hiện tỷ lệ trung bình 10% các đột biến tương đương. Kiểm thử phần mềm địi hỏi tính chính xác của dữ liệu thử thực hiện trên PUT được xác định. Nghiên cứu này giả sử rằng tồn tại một quy trình tự động thích hợp cho mỗi PUT mà có thể quyết định tính đúng đắn của dữ liệu thử dựa trên các đặc tả của chương trình.
CHƢƠNG 4 - ỨNG DỤNG KỸ THUẬT KIỂM THỬ ĐỘT BIẾN ĐỂ KIỂM THỬ CÁC CHƢƠNG TRÌNH JAVA
Ngày nay, Java được sử dụng rất rộng rãi, chủ yếu là các ứng dụng được viết trên Internet nhằm khai thác tối đa khả năng của nó trong lĩnh vực viễn thơng, truyền hình, mạng, và các máy tính đơn lẻ. Để góp phần đảm bảo các ứng dụng được phát triển bởi ngôn ngữ Java hoạt động được ổn định, chất lượng và hiệu quả. Chương này giới thiệu một quy trình kiểm thử các chương trình Java ứng dụng kỹ thuật kiểm thử đột biến sử dụng hai công cụ mã nguồn mở miễn phí MuJava và JUnit.