Sinh tự động dữ liệu kiểm thử dựa trên biểu đồ tuần tự UML và ràng buộc OCL

Đồ thị dòng điều khiển

Một thông số hay một giá trị trả về được tách riêng và các thông tin ràng buộc từ biểu đồ lớp và có cấu trúc < name, type, value, constraint > với name là tên của bộ thông số hoặc thuộc tính, type là dạng dữ liệu, value là giá trị được gán. Còn constraint được lấy từ ràng buộc OLC được khai báo từ các thuộc tính biểu đồ lớp hoặc đã được đính kèm vào biểu đồ tuần tự.

Các độ đo kiểm thử

Mỗi thông điệp bao gồm các thông tin bên gửi từ biểu đồ lớp và có cấu trúc < m, ParamList, rValue >. C1: Độ bao phủ yếu: Đường kiểm thử đi qua tất cả các nốt rẽ nhánh (các nốt quyết định) của đồ thị dòng điều khiển.

Thuật toán biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển

Vì vậy thiết kế của phân đoạn Opt trên đồ thị CFG là một nốt quyết định DC nhưng chỉ có hai nhanh trong đó một nhánh đúng cho phép thực hiện các thông điệp tiếp theo, nhánh còn lại không làm gì cả (bỏ qua các thông điệp trong phân đoạn Opt). Việc sinh ca kiểm thử cho điều kiện vòng lặp là rất phức tạp bởi vì trong hầu hết các trường hợp điều kiện vòng lặp bị thay đổi, giá trị biến bên trong bị thay đổi sau mỗi lần thực hiện những câu lệnh trong vòng lặp. Biến đổi tương ứng đối với phân đoạn Seq: Về cơ bản phân đoạn Seq có cấu tạo như phân đoạn Par, tuy nhiên điểm khác biệt cần lưu ý là, với phân đoạn Seq các thông điệp cùng nằm trên một trục thời gian (cùng truyền tới một trục thời gian) thì buộc phải thực hiện theo thứ tự (trình tự thời gian).

Biến đổi tương ứng đối với phân đoạn Neg: Với phân đoạn Neg, trong khi các thông điệp bên trong phân đoạn đang thực thi thì bất kì một thông điệp nào trong cùng khoảng thời gian đó đi từ các trục thời gian (linelife) bên ngoài phân đoạn vào đều bị bỏ qua hoặc không cho phép thực hiện. Ví dụ Hình 3.10, có 3 thông điệp q, v, w được cho phép trong Consider tuy nhiên trong khoảng thời gian phân đoạn Assert diễn ra thì chỉ cho phép thông điệp q được thực thi, các thông điệp khác nếu xảy ra sẽ bị bỏ qua. Phân đoạn Critical region: Do đặc tính ưu tiên vùng then chốt, phân đoạn Critical region giống như một công tắc ngắt chương trình và ưu tiên thực hiện các sự kiện trong phân đoạn khi thỏa mãn điều kiện, sau đó quay lại thực hiện tiếp công việc ở vị trí trước khi xảy ra.

Điều này phá vỡ qui tắc về thời gian của biểu đồ tuần tự, khi biến đổi sang đồ thị dòng điều khiển không kiểm soát được việc thực thi đường kiểm thử (do khó kiểm soát khi nào thì phân đoạn ngắt quãng và chuyển xuống để thực thi).

Kỹ thuật sinh kịch b n kiểm thử

Áp dụng thực tế cho bài nghiên cứu, ví dụ cho đồ thị dòng điều khiển như Hình 3.13. Dựa vào mối liên hệ giữa các nốt trong đồ thị dòng điều khiển dùng thuật toán biến đổi đưa dữ liệu về dạng chuẩn như miêu tả ở Bảng 3.2.

Kịch b n kiểm thử cho các phân đoạn song song (Par, Seq)

Đối với phân đoạn song song, ngoài việc tìm ra tất cả các đường đi trong đồ thị dòng điều khiển, chúng ta còn phải tìm hiểu các thông số, các biến ở mỗi nốt. Khi đó kết quả thực thi và tính toán của đường kiểm thử đơn (đường kiểm thử chỉ chứa một trong các nốt có chia sẻ dữ liệu) có thể sẽ bị ảnh hưởng vì sẽ có hai hành động có khả năng thực hiện cùng lúc, trước hoặc sau lúc đó làm biến đổi giá trị của biến đang thực thi trong đường kiểm thử dẫn tới sai lệch trong kết quả chương trình hoặc kết quả kiểm thử. Ví dụ nốt 3 và nốt 4 trong đồ thị Hình 3.16 là hai nốt có chia sẻ dữ liệu (và là hai nốt song song vì thuộc phân đoạn par: phân đoạn par khi biến đổi sang CFG sẽ bắt đầu từ một nốt FN và kết thúc bằng nốt JN).

Kỹ thuật áp dụng trong việc sinh các ca kiểm thử song song là đánh dấu các điểm có chia sẻ dữ liệu: Nốt (data.shared = true) nếu phát hiện ra hai nốt có chung một biến bên trong. Mục đích của thuật toán 5 là sinh ra một ma trận kề tương tự như thuật toán 3, sau đó sử dụng thuật toán 4 để tìm ra tất cả các đường đi thỏa mãn là các ca kiểm thử tương ứng.

Xây dựng hệ ràng buộc

Thuật toán 5 trình bày qui trình sinh ca kiểm thử cho các toán tử song song chứa điểm chia sẻ dữ liệu. Thuật toán 5 kiểm tra trong quá trình duyệt nếu gặp các phân đoạn par hoặc seq sẽ kiểm tra tất cả các nốt bên trong. Thuật toán 5 sẽ chuyển đổi giữa hai ca kiểm thử có chứa điểm chia sẻ dữ liệu đó để tìm ra đường đi có đi qua cả hai điểm.

Mảng ArrayList<String> testConstraint lưu giữ các ràng buộc, dữ kiện chương trình cần thực thi. Hai mảng testConstraint, defineList được dùng làm dữ liệu đầu vào cho công cụ giải hệ SMT-Solver.

Giới thiệu công cụ và môi trường thực nghiệm

Đường kiểm thử là đặc tả chính xác hoạt động của đồ thị dòng điều khiển cũng như biểu đồ tuần tự được thiết kế trên UML. Bộ kiểm thử này được dùng để kiểm tra xem việc lập trình có đúng với thiết kế hay không đồng thời kiểm tra tính đúng đắn của thiết kế. Nếu một hệ ràng buộc được giải ra cho kết quả là vô nghiệm thì khi đó hoặc là đặc tả hay thiết kế sai, hoặc là các ràng buộc có mâu thuẫn dẫn tới ca kiểm thử không thể tồn tại.

Điều đó nói lên chương trình (ca sử dụng) sẽ không bao giờ được thực thi nếu như mã nguồn được tạo ra là đúng với thiết kế. Trong trường hợp thu được kết quả từ việc giải hệ ràng buộc trên đường kiểm thử, kết quả đó sẽ được dùng làm dữ liệu đầu vào trong ca kiểm thử và thực thi.

Thực nghiệm

Đầu vào của công cụ - Hình 4.8: miêu tả quá trình quản lý tài khoản ngân hàng, thực hiện nhiều thao tác khác nhau tới cùng một tài khoản trong đó cho phép thực hiện đồng thời việc gửi tiền, rút tiền, kiểm tra tài khoản, chuyển tiền từ tài khoản chính sang tài khoản tiết kiệm và ngược lại.  Đồ thị CFG - Hình 4.3: Ứng với phân đoạn Par trong biểu đồ tuần tự là nốt FN chia hai nhánh hoạt động song song. Vì thuật toán duyệt lần lượt từng đường đi của đồ thị CFG, điều kiện độ bao phủ yếu được thỏa mãn sau 2 lần duyệt.

Ngoài các ca kiểm thử độ bao phủ yếu và ca kiểm thử độ bao phủ trung bình, ca kiểm thử độ bao phủ mạnh dành riêng cho các trường hợp đồ thị có chứa các nốt có điểm chia sẻ dữ liệu. Ca kiểm thử này không tuân theo qui luật đường đi trong đồ thị CFG mà có sự chuyển đổi giữa các nốt có sự trao đổi dữ liệu trong các nhánh khác nhau.

Ý nghĩa thực nghiệm

So với các nghiên cứu khác, chương trình thực nghiệm sử dụng đầu vào là các biểu đồ thiết kế thực tế mà các công ty phần mềm luôn phải thực hiện. Từ đó có thể tiến hành ngay các bước kiểm thử với ba độ đo kiểm thử khác nhau tùy thuộc thời gian phát triển dự án. Ở độ đo kiểm thử độ bao phủ mạnh, công cụ mang lại hiệu quả cao khi xét tới các trường hợp luồn song song có chứa điểm chia sẻ dữ liệu.

Việc biểu diễn trực quan đồ thị dòng điều khiển cùng với các đường kiểm thử giúp kiểm thử viên có thể quan sát trực tiếp các kịch bản mà phần mềm sẽ thực thi. Dù còn một số hạn chế về kiểu dữ liệu đầu vào nhưng bài nghiên cứu này sẽ là tiền đề để mở rộng, áp dụng các phương pháp giải khác cho các kiểu dữ liệu mảng, chuẫn kí tự, v.v.