Kiểm thử là quá trình kiểm tra chương trình với mục đích phát hiện lỗi. Kiểm thử phần mềm cần nhiều thời gian và chi phí của dự án, thông thường chiếm 50% chi phí của dự án và 35% tổng thời gian phát triển phần mềm. Bài viết này tóm tắt các kỹ thuật chính trong việc sinh dữ liệu kiểm thử tự động từ mã nguồn và một số hướng nghiên cứu cải tiến.
TỔNG QUAN VỀ PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG TỪ MÃ NGUỒN Trần Nguyên Hương Trường Cao đẳng Sư phạm Trung ương Email: huongtw@gmail.com Vũ Mạnh Điệp Trường Cao đẳng Sư phạm Trung ương Email: diepvm@gmail.com Tóm tắt: Kiểm thử trình kiểm tra chương trình với mục đích phát lỗi Kiểm thử phần mềm cần nhiều thời gian chi phí dự án, thơng thường chiếm 50% chi phí dự án 35% tổng thời gian phát triển phần mềm Bước quan trọng kiểm thử phần mềm tự động sinh liệu kiểm thử từ mã nguồn cách tối ưu dựa tiêu chuẩn cho trước Bài báo tóm tắt kỹ thuật việc sinh liệu kiểm thử tự động từ mã nguồn số hướng nghiên cứu cải tiến Từ khóa: Kiểm thử phần mềm, sinh liệu kiểm thử tự động, kiểm thử tĩnh, kiểm thử động, mã nguồn I TỔNG QUAN VỀ SINH DỮ LIỆU KIỂM THỬ DỰA TRÊN MÃ NGUỒN Trong trình phát triển phần mềm, kiểm thử giai đoạn quan trọng thực cần thiết để tạo phần mềm có chất lượng cao Có nhiều mức kiểm thử giai đoạn này, bao gồm kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống kiểm thử chấp nhận Trong mức kiểm thử đơn vị (unit test) pha quan trọng để đảm bảo chất lượng phần mềm Hai phương pháp sử dụng phổ biến kiểm thử đơn vị gồm kiểm thử hộp đen (black-box testing) kiểm thử hộp trắng (white-box testing) Kiểm thử hộp đen kiểm tra tính đắn đầu với đầu vào cho trước mà không quan tâm đến mã nguồn chương trình Ngược lại, phương pháp kiểm thử hộp trắng đánh giá chất lượng mã nguồn cách sử dụng kĩ thuật phân tích mã nguồn Do kiểm thử hộp trắng sâu vào phân tích mã nguồn nên kĩ thuật cho phép phát lỗi tiềm ẩn mà kiểm thử hộp đen không phát Tuy nhiên, chi phí kiểm thử hộp trắng lớn nhiều so với kiểm thử hộp đen Đặc biệt, dự án cơng nghiệp, chi phí kiểm thử hộp trắng chiếm 50% tổng chi phí phát triển phần mềm Nguyên nhân tình trạng số lượng hàm cần kiểm thử lên tới hàng nghìn, chí hàng chục nghìn Kết chi phí để kiểm thử hết hàm lớn, ảnh hưởng nhiều đến tốc độ phát triển dự án Vì thế, q trình kiểm thử hộp TẠP CHÍ KHOA HỌC QUẢN LÝ VÀ CÔNG NGHỆ trắng cần tự động hóa để giải tốn chi phí Hiện nay, đa số q trình thực tự động hóa tập trung vào việc thực thi ca kiểm thử (test case) mà không quan tâm đến việc thiết kế ca kiểm thử (việc phát lỗi phần mềm phụ thuộc chủ yếu vào chất lượng ca kiểm thử) Hai thành phần thiết kế ca kiểm thử thiết kế liệu kiểm thử kết đầu mong đợi (expected output) Tuy nhiên, thiết kế kết đầu mong đợi khó khăn, khó tự động hóa Do thiết kế ca kiểm thử người ta quan tâm nhiều đến sinh liệu kiểm thử Cho đến nay, có hai kĩ thuật để sinh liệu kiểm thử kĩ thuật kiểm thử tĩnh (static testing) kiểm thử động (dynamic testing) Điểm chung kĩ thuật sử dụng kĩ thuật thực thi tượng trưng (symbolic execution) sinh liệu kiểm thử qua giải hệ ràng buộc sử dụng kĩ thuật sinh ngẫu nhiên giải SMT-Solver Kĩ thuật thực thi tượng trưng, nêu James C King giới thiệu lần vào năm 1976, sau có số cải tiến [5][6] kĩ thuật phổ biến để sinh liệu kiểm thử tự động Trong toán sinh liệu kiểm thử, từ đầu vào đường thi hành, kỹ thuật thay giá trị đầu vào cụ thể giá trị tượng trưng để đại diện cho miền mà hành vi chương trình Tư tưởng kỹ thuật kiểm thử tĩnh sinh liệu kiểm thử phân tích mã nguồn (khơng thực thi mã nguồn) sử dụng kĩ thuật thực thi tượng trưng Quy trình thực sau: (1) mã nguồn phân tích chuyển thành đồ thị dịng điều khiển (control flow graph - CFG) theo tiêu chuẩn bao phủ (coverage criteria) cho trước; (2) sinh đường kiểm thử (test path) cách duyệt đồ dòng điều khiển; (3) sinh hệ ràng buộc từ đường kiểm thử; (4) sinh liệu kiểm thử (ngẫu nhiên sử dụng giải SMTsolver) Các bước (2), (3), (4) lặp lại đạt tiêu chí độ phủ duyệt hết TẠP CHÍ KHOA HỌC QUẢN LÝ VÀ CÔNG NGHỆ đường kiểm thử Kỹ thuật kiểm thử tĩnh có ưu điểm tốc độ thực thi nhanh so với kỹ thuật kiểm thử động, số liệu kiểm thử sinh (đặc biệt trường hợp chương trình có vịng lặp) Tuy nhiên có hạn chế độ phức tạp cao phải phân tích tồn mã nguồn, kỹ thuật khó áp dụng cho dự án cơng nghiệp hỗ trợ tất cú pháp điều Trái ngược với kỹ thuật kiểm thử tĩnh, kỹ thuật kiểm thử động khơng u cầu phải phân tích cú pháp chương trình để sinh liệu kiểm thử Để giảm chi phí phân tích mã nguồn mà đạt độ phủ cao, kỹ thuật kiểm thử động kết hợp q trình phân tích cú pháp chương trình với trình biên dịch [1] [2] [3] [10] Bởi thế, kỹ thuật kiểm thử động dễ dàng đạt độ phủ cao mà khơng cần phải phân tích chương trình nhiều Kỹ thuật kiểm thử động gồm hai kĩ thuật kiểm thử sử dụng phổ biến gồm kĩ thuật EGT (execution generated testing) kĩ thuật kiểm thử tự động định hướng (concolic testing): Kĩ thuật EGT áp dụng công cụ sinh liệu kiểm thử tự động tiếng KLEE [2] – công cụ đánh giá cao tính hiệu Tư tưởng kĩ thuật EGT vừa chạy chương trình vừa sinh liệu kiểm thử trực tiếp Chẳng hạn, gặp điều kiện (điểm định đồ thị CFG), liệu kiểm thử tương ứng nhánh nhánh sai điều kiện sinh Tại đây, với liệu kiểm thử, tiến trình tạo phân tích chương trình theo nhánh đúng/sai Q trình sinh liệu kiểm thử dừng ba điều kiện sau thỏa mãn (i) đạt độ phủ tối đa (ii) khơng cịn nhánh đúng/sai để phân tích tiếp, (iii) đạt đến giới hạn thời gian cho phép Nhược điểm kĩ thuật EGT hiệu suất thấp kiểm thử hàm chứa vịng lặp có số lần lặp lớn, chứa lời gọi đệ quy Khi đó, số tiến trình tạo từ hàng trăm tới hàng nghìn Kĩ thuật thể tính hiệu tìm lỗi tiềm ẩn chương trình EGT xem xét trường hợp xảy Tuy nhiên, kĩ thuật EGT không phù hợp với toán sinh liệu kiểm thử đạt độ phủ tối đa khơng cần xem xét hết trường hợp sinh liệu kiểm thử Kĩ thuật kiểm thử tự động định hướng đề xuất vào năm 2005 cài đặt công cụ DART [3] Tư tưởng kĩ thuật kiểm thử tự động định hướng sinh liệu kiểm thử từ liệu kiểm thử trước Sau này, kĩ thuật kiểm thử tự động định hướng liên tục cải tiến công cụ PathCrawler [10], CUTE [4], CAUT [8][9], CREST [1] Quy trình kiểm thử tự động định hướng Koushik Sen cộng đề xuất DART [3] gồm bước sau: Bước 1: Chèn câu lệnh đánh dấu vào hàm cần kiểm thử (instrument function) Các câu lệnh đánh dấu giúp xác định danh sách câu lệnh thực thi chạy chương trình Bước 2: Sinh ngẫu nhiên liệu kiểm thử dựa tham số truyền vào hàm (kiểu sở, trỏ, mảng, dẫn xuất) Bước 3: Thực thi chương trình với liệu kiểm thử vừa tìm Nếu khơng thực thi (lỗi xảy ra) quay lại bước để sinh giá trị khác Bước 4: Tìm tập câu lệnh qua với liệu kiểm thử bước (đường thi hành – test path) để xây dựng hệ ràng buộc tương ứng Bước 5: Tính độ phủ đạt với liệu kiểm thử Nếu độ phủ đạt tối đa hết thời gian, trình sinh liệu kiểm thử kết thúc Ngược lại sang bước Bước 6: Phủ định hệ ràng buộc thu bước để sinh hệ ràng buộc có tác dụng sinh liệu kiểm thử Nếu sinh hệ phủ định khác, thuật toán kết thúc Bước 7: Giải hệ ràng buộc thu bước để sinh liệu kiểm thử Nếu khơng có liệu kiểm thử thỏa mãn, quay bước để tìm hệ ràng buộc phủ định cho khác hệ ràng buộc Ngược lại, quay lại bước để chạy liệu kiểm thử II NHỮNG HƯỚNG NGHIÊN CỨU HIỆN NAY 2.1 Phân tích chương trình, tiền xử lý mã nguồn Trước thực thi chương trình để sinh liệu kiểm thử tự động từ mã nguồn, chương trình cần phải phân tích, tiền xử lý mã nguồn Tuy nhiên, phân tích đầy đủ mã nguồn cho ngơn ngữ lập trình điều khó khăn ngơn ngữ lập trình thường xuyên có nâng cấp thành phiên Hiện nay, ngơn ngữ lập trình phân tích nhiều ngôn ngữ C/C++, Java, C# Tuy nhiên, việc phân tích mã nguồn chủ yếu tập trung hỗ trợ cú pháp kiểu liệu bản, kiểu trỏ, kiểu mảng, xử lý vòng lặp Kỹ thuật thường áp dụng sử dụng thư viện phân tích mã nguồn, chẳng hạn Eclipse CDT cho C/C++ Đầu vào Eclipse CDT mã nguồn, đầu cú pháp trừu tượng (Abstract Syntax Tree – AST) ứng với mã nguồn Từ AST, người ta xây dựng đồ thị CFG làm sở cho việc thực thi bước trình kiểm thử tự động Hiện có số nghiên cứu quan tâm đến giải tính hướng đối tượng ngơn ngữ lập trình, chẳng hạn chương trình có tính đa hình động, khn hình lớp Vấn đề phân tích mã nguồn cần tiếp tục cải tiến để hỗ trợ phân tích đầy đủ cho chương trình C/C++, Java… nhiều TẠP CHÍ KHOA HỌC QUẢN LÝ VÀ CƠNG NGHỆ ngơn ngữ khác Các vấn đề nghiên cứu vấn đề quản lý nhớ, phân tích chương trình có tính kế thừa, chồng tốn tử, chồng hàm, khn hình v.v Mặt khác, tối ưu hóa q trình phân tích mã nguồn vấn đề mở cần nghiên cứu 2.2 Chiến lược tìm đường thi hành Sau thực thi liệu kiểm thử, tập hợp câu lệnh thực thi tạo thành đường thi hành (test path) Hiện tại, nhiều cơng trình nghiên cứu đưa nhiều chiến lược chọn đường thi hành khác để sinh liệu kiểm thử tăng độ phủ tốt [1], [8], [10] Theo tư tưởng kĩ thuật kiểm thử tự động định hướng, liệu kiểm thử sinh từ nhánh/ câu lệnh chưa qua liệu kiểm thử trước Có hai loại chiến lược tìm đường thi hành bao gồm chiến lược truyền thống dựa đồ thị dòng điều khiển (CFG-based) Chiến lược truyền thống được Patrice Godefroid đề xuất vào năm 2005 áp dụng công cụ DART Các kĩ thuật tìm kiếm chiến lược truyền thống gồm: tìm kiếm theo chiều sâu (DFS), tìm kiếm theo chiều rộng (BFS) tìm kiếm ngẫu nhiên Theo chiến lược này, điều kiện cuối đường thi hành phủ định để sinh liệu kiểm thử mà không xét đến trạng thái đồ thị luồng điều khiển Tuy nhiên, việc phủ định khiến q trình sinh liệu kiểm thử bị lặp vô hạn trường hợp hàm có vịng lặp Sau này, nghiên cứu PathCrawler [10] CUTE [4] giải vấn đề cách hạn chế số lần lặp tối đa vịng lặp Tiếp nối với nghiên cứu trước đó, số lượng liệu kiểm thử giảm thiểu nghiên cứu nhóm CREST [1], nhóm CAUT [8] [9] áp dụng chiến lược dựa đồ thị dòng điều khiển để chọn nhánh phủ định tốt Cụ thể CREST sử dụng thuật tốn Dijkstra để tìm đường thi hành ngắn TẠP CHÍ KHOA HỌC QUẢN LÝ VÀ CƠNG NGHỆ từ câu lệnh/nhánh thăm tới khối lệnh chưa thăm; CAUT cố gắng tìm đường thi hành tốt từ câu lệnh thăm đến khối lệnh chưa khám phá Các tác giả Nguyễn Đức Anh Phạm Ngọc Hùng đề xuất kĩ thuật xếp hạng đường thi hành theo độ ưu tiên [7] Đường thi hành tăng độ phủ lớn độ ưu tiên cao Mức độ tăng độ phủ đánh giá qua trạng thái đồ thị dòng điều khiển (CFG) Trong trường hợp hai đường thi hành tăng độ phủ đường thi hành ngắn ưu tiên Ngun nhân chi phí phân tích mã nguồn lớn, đường thi hành ngắn ưu tiên đường thi hành khác để giảm chi phí phân tích mã nguồn Ngồi chiến lược trên, hai nhóm chiến lược sau nghiên cứu sử dụng nhóm chiến lược tìm kiếm heuristic (Heuristic Search Strategy) nhóm chiến lược loại bỏ dư thừa (Pruning Redundance Strategy) Đây nghiên cứu có nhiều kết tốt phù hợp 2.3 Tối ưu hóa giải hệ ràng buộc Kích thước hệ ràng buộc lớn, cấu trúc phức tạp làm tăng thời gian giải hệ ràng buộc Điều dẫn đến tốn tối ưu hệ ràng buộc trước sử dụng SMT-Solver để giải hệ ràng buộc + Loại bỏ ràng buộc không liên quan: Trước giải hệ ràng buộc cần xem xét để loại bỏ ràng buộc không liên quan, nhằm tối ưu hóa hệ ràng buộc Một vài kĩ thuật đơn giản để giảm độ phức tạp ràng buộc kĩ thuật đơn giản hóa biểu thức (ví dụ: x+0 > đơn giản hóa thành x >1), kĩ thuật suy biến nhanh giá trị biến (ví dụ: x+1=10 đơn giản hóa thành x=9), kĩ thuật loại bỏ hệ ràng buộc hiển nhiên (ví dụ: x0)^(z>0)^(y0)^(z>0)& ¬(y