Đặt vấn đề Trong ngành công nghiệp sản xuất phần mềm, một sản phẩm phần mềm muốn được đưa ra thị trường cần phải đáp ứng được các yêu cầu về tính đúng đắn. Có hai phương pháp phổ biến và được áp dụng nhiều nhất để kiểm tra tính đúng đắn của phần mềm là kiểm tra phầm mềm (software verification) và kiểm thử phần mềm (software testing). Trong đó, kiểm thử phần mềm là phương pháp được chấp nhận và sử dụng rộng rãi đồng thời có hiệu quả cao nhất trong việc kiểm định chất lượng của sản phẩm. Hiện nay, có nhiều chiến lược để thực hiện việc kiểm thử phần mềm, trong đó hai chiến lược chính là kiểm thử hộp đen và kiểm thử hộp trắng [2][21]: - Kiểm thử hộp đen (Black-box testing) là chiến lược dùng để kiểm tra các yêu cầu chức năng của chương trình.
Chiến lược này không yêu cầu kiểm tra viên phải có kiến thức về cấu trúc cũng như là hiện thực cụ thể của chương trình. Thật vậy, kiểm tra viên chỉ cần cung cấp bộ test case dựa trên mô tả chương trình, yêu cầu kiểm tra và thiết kế chương trình. Sau đó, chương trình được thực thi với bộ test case trên để kiểm tra xem các chương trình có hoạt động đúng chức năng hay không. - Kiểm thử hộp trắng (White-box testing) là chiến lược dùng để kiểm tra cấu trúc và hoạt động của chương trình.
Chiến lược này yêu cầu kiểm thử viên phải có kiến thức về cấu trúc và hiện thực của chương trình. Kiểm thử viên tiến hành phân tích chương trình, đưa ra test case phù hợp với những đường đi cần kiểm tra, đồng thời xác định những kết quả đầu ra phù hợp. Sau đó, chương trình được thực thi với 3 test case tìm được để kiểm tra kết quả thực thi có đúng với kết quả mong đợi hay không. Mặc dù kiểm thử hộp trắng có những ưu điểm so với kiểm thử hộp đen trong việc phát hiện lỗi trong chương trình, được thể hiện qua: - Kiểm thử hộp trắng có thể xác định được lỗi và vị trí gây ra lỗi.
Khi có lỗi xảy ra, các kiểm thử viên có thể dựa theo đường đi của chương trình với test case gây ra lỗi để tìm ra vị trí chính xác của lỗi. Trong khi đó, kiểm thử hộp đen không thể xác định được vị trí gây ra lỗi vì các kiểm thử viên không biết chính xác luồng thực thi chương trình. - Ngoài ra, kiểm thử hộp đen thường xảy ra tình huống không phát hiện ra các lỗi tiềm ẩn trong chương trình. Vì các kiểm thử viên không có hiểu biết về cấu trúc và hiện thực của chương trình nên các test case được tạo không thể theo sát và bao phủ được các đường đi khác nhau trong chương trình.
Từ đó, các lỗi phát sinh khi thực thi với các trường hợp hiếm gặp sẽ khó được tìm thấy. Với kiểm thử hộp trắng thì hầu như không xảy ra vấn đề này do các kiểm thử viên đã phân tích và đưa ra test case cho các trường hợp hiếm gặp đó. Tuy nhiên, kiểm thử hộp trắng lại có những khuyết điểm lớn, đó là: - Chi phí cao: Để thực hiện việc kiểm thử hộp trắng, cần phải có kiểm thử viên có trình độ chuyên môn cao, có khả năng phân tích và hiểu rõ đoạn code cũng như yêu cầu của chương trình để có thể sinh ra bộ test case phù hợp. - Hao phí về thời gian: phương pháp kiểm thử hộp trắng yêu cầu phải có một quá trình phân tích chương trình trước khi sinh ra bộ test case.
Hiện nay, quá trình này chủ yếu thực hiện bằng tay và tốn kém nhiều thời gian. - Ngoài ra, việc phân tích dựa trên khả năng quan sát và đánh giá chủ quan của kiểm thử viên nên cũng có thể xảy ra sai sót. Bên cạnh đó, sự phức tạp và nhập nhằng của chương trình cũng gây khó khăn cho việc phân tích. 4 Những khuyết điểm trên không thể được chấp nhận với các sản phẩm mang tính thương mại cao hiện nay.
Chính vì vậy, kiểm thử hộp trắng ngày nay vẫn không được sử dụng rộng rãi như kiểm thử hộp đen. Điều này đặt ra yêu cầu cần phải cải tiến chiến lược kiểm thử hộp trắng để giảm bớt những khuyết điểm so với kiểm thử hộp đen. Một giải pháp được đưa ra để cải tiến chiến lược đó là tự động hóa quá trình phân tích và sinh test case cho chương trình. Hiện nay, có nhiều phương pháp để sinh test case cho chương trình.
Trong số đó, chỉ một số ít phương pháp là tự động, các phương pháp này được chia thành những hướng chính là: hướng mục tiêu (goal-oriented), hướng đường đi (path- oriented), hướng phân tích (analysis-oriented) và ngẫu nhiên (random). Hai phương pháp sinh test case tự động Hướng mục tiêu và Hướng đường đi là hai phương pháp phổ biến nhất, đã được nghiên cứu trong một khoảng thời gian dài và thu được những thành tựu nhất định. Hai phương pháp này được thực hiện dựa trên các phương pháp giải quyết ràng buộc (constraint solving) hoặc dựa trên các giải thuật tối ưu hướng tự nhiên như giải thuật di truyền hay mô phỏng luyện kim. Các phương pháp này đòi hỏi các công cụ sinh test case cần phải “hiểu” được các điều kiện trong chương trình, từ đó mới có thể sinh ra các bộ test case phù hợp để có thể bao phủ tất cả các điều kiện này.
Ngược lại, nếu các công cụ sinh test case không thể “hiểu” được các điều kiện trong chương trình thì không thể sinh ra bộ test case phù hợp. Hiện nay, những công cụ sinh test case chỉ có thể “hiểu” các điều kiện dạng các biểu thức số học, quan hệ hay logic như +, -, *, /, &, |… trên các biến dữ liệu kiểu số nguyên (integer). Còn đối với các điều kiện có chứa các hàm phức tạp như các hàm số mũ và logarit, các hàm lượng giác,… trên các kiểu dữ liệu scalar khác như float, double,… thì các công cụ này đều không thể “hiểu” được. 0: int foo(int x, int y) int foo(int x, int y) { { 1: if(x>y) if(sin(x)>0) { { 2: if(x>2*y) if(cos(y)<1 && cos(y)>0) 3: return 1; return 1; 4: else else 5: return 2; return 2; 5 } } } } (a) (b) Bảng 1.
Hai chương trình C/C++ đơn giản Lấy ví dụ: với các đoạn chương trình trong Bảng 1, ta tiến hành sinh test case cho chương trình bằng việc sử dụng phương pháp hướng mục tiêu (nội dung của phương pháp được mô tả cụ thể ở Chương 2, Mục 2. Với đoạn chương trình ở Bảng 1a, giả sử ta sử dụng công cụ giải quyết ràng buộc (constraint solving) để tìm test case làm cho điều kiện ở dòng 2 đạt giá trị TRUE. Sau khi phân tích chương trình, ta sẽ thu được một biểu thức logic tương ứng để chương trình có thể thực thi được đến dòng này và đạt giá trị đầu ra là TRUE: (x>y)&&(x>2*y). Với công thức này, các công cụ giải quyết ràng buộc có thể dễ dàng giải quyết và tìm ra được các kết quả phù hợp.
Ví dụ, hai giá trị x = 4 và y = 1 là hai giá trị thỏa mãn yêu cầu, cũng chính là test case phù hợp để điều kiện ở dòng 2 đạt giá trị TRUE. Tuy nhiên, với đoạn chương trình trong Bảng 1b, biểu thức logic phân tích được lúc này sẽ là (sin(x)>0)&&(cos(y)<1 && cos(y)>0). Với biểu thức này, các công cụ giải quyết ràng buộc hiện nay không thể giải được để tìm ra test case phù hợp, mặc dù đường đi đến vị trí của điều kiện này là khả thi, nghĩa là tồn tại giá trị x và y thỏa mãn điều kiện trên, ví dụ x = PI/2 (radian) và y = PI/3 (radian). Việc sử dụng giải thuật tối ưu để sinh test case cho đoạn chương trình trong Bảng 1b cũng gặp phải vấn đề tương tự.
Lí do là vì phương pháp này đòi hỏi cần phải sử dụng một công cụ thực thi giả lập (simulation executor) để thực thi đoạn chương trình với các test case đầu vào, đồng thời theo dõi đường đi thực thi tương ứng với các test case đó. Tuy nhiên, với đoạn chương trình trong Bảng 1b thì công cụ thực thi giả lập hiện nay không thể thực thi được. Vì vậy, ta cũng không thể sinh ra bộ test case phù hợp với điều kiện trên bằng việc sử dụng giải thuật tối ưu. Tóm lại, các chương trình có chứa những lời gọi thủ tục, lời gọi hàm thư viện hay chứa các biểu thức phi tuyến tính,… đều không thể áp dụng các kĩ thuật sinh test case 6 hiện nay để sinh ra bộ test case phù hợp.
Những chương trình như vậy ta gọi là những chương trình chứa điều kiện phức tạp. Với những khó khăn nêu trên, vấn đề đặt ra là phải tìm được một phương pháp sinh test case tự động có thể giải quyết được các điều kiện phức tạp trong chương trình, đồng thời phải kế thừa được những ưu điểm của các phương pháp hiện có. Đây chính là vấn đề mà luận văn muốn nghiên cứu và giải quyết.2 Phát biểu đề tài Nội dung nghiên cứu của luận văn là nhằm giải bài toán: Sử dụng phương pháp kiểm thử hộp trắng, xây dựng một hệ thống hỗ trợ việc tự động phân tích và sinh test case cho các chương trình. Yêu cầu của luận văn là phải giải quyết được khó khăn khi sinh test case cho chương trình có chứa những điều kiện phức tạp, trong đó có các lời gọi hàm thư viện, các phép toán phi tuyến tính,… trên miền dữ liệu scalar.
Dữ liệu đầu vào: Đoạn chương trình được viết bởi ngôn ngữ C/C++. Dữ liệu đầu ra: Bộ test case đầy đủ để có thể kiểm tra được tính đúng đắn của chương trình dựa trên một tiêu chuẩn test cụ thể. Yêu cầu của bộ test case là phải bao phủ hết toàn bộ các trường hợp sử dụng có thể của chương trình, đồng thời kích thước của bộ test case là tối thiểu nhất có thể. Một đoạn chương trình được viết bằng ngôn ngữ C/C++ Giới hạn bài toán: Mục tiêu của luận văn là xây dựng một hệ thống hỗ trợ việc sinh test case cho các chương trình được viết bằng ngôn ngữ C/C++.
Hệ thống này có thể hỗ trợ hầu hết các câu lệnh cơ bản của ngôn ngữ C/C++. Hệ thống cũng sẽ hỗ trợ hầu hết các kiểu dữ liệu scalar như int, float, double,…. Tuy nhiên, do tính phức tạp của các ngôn ngữ lập trình nói chung, và ngôn ngữ C/C++ nói riêng, bên cạnh đó là giới hạn thời gian thực hiện đề tài, các cấu trúc dữ liệu phức tạp như array, struct, class, pointer… vẫn chưa được hỗ trợ bởi hệ thống, những cấu trúc này sẽ được nghiên cứu và xử lý ở những phiên bản sau.
