3.4 Thực nghiệm
3.4.2 Kết quả và đánh giá
Tất cả các thực nghiệm được thực thi với công cụ SequenceTesting trên máy tính Intel Core i3- 6100U CPU 2.30 GHz với RAM 2GB.
3.4.2.1 Thực nghiệm và đánh giá phần sinh đồ thị trung gian
Công cụ được áp dụng cho các biểu đồ tuần tự từ dạng đơn giản khơng có hoặc có một khối đơn, đến dạng phức tạp chứa các khối lồng ghép, qua đó so sánh kết quả với phương pháp đề xuất ban đầu trong nghiên cứu [72]. Kết quả thu được thể hiện ở Bảng 3.5 cho thấy nghiên cứu đã hoàn chỉnh được hướng đề xuất ban đầu, giải quyết được thêm các khối đơn critical, strict, weak sequencing, assert, consider, ignore, negative. Hơn nữa, cải tiến thuật toán sinh CFG cho tốn tử parallel nhằm mục đích tránh bùng nổ các kịch bản kiểm thử trong trường hợp đó, được giải quyết ở Chương 4.
Bӝ thӵc thi kiӇm thӱ tӵÿӝng Sinh ÿӗ thӏ dịng ÿiӅu khiӇn Cơng cө TiӃn trình Sinh các ca kiӇm thӱ Các ÿoҥn mã kiӇm thӱ (test scripts) Bӝ sinh ÿӗ thӏ dòng ÿiӅu khiӇn tӵ ÿӝng Bӝ sinh các kӏch bҧn và dӳ liӋu kiӇm thӱ Testing Framework UML sequence diagram và
class diagram (XMI file)
KӃt quҧ kiӇm thӱ
Luӗng dӳ liӋu và ÿiӅu khiӇn TiӃn trình tӵ ÿӝng
Hình 3.19: Kiến trúc thực thi của SequenceTesting.
Áp dụng công cụ này cho các biểu đồ tuần tự của các chức năng trong các ứng dụng với các trường hợp chỉ chứa duy nhất một phân đoạn hoặc chứa nhiều phân đoạn lồng ghép nhau, từ đó so sánh kết quả thu được với kết quả của phương pháp đề xuất trong [72] như Bảng 3.5. Với biểu đồ tuần tự đầu vào có các khối đơn chứa critical, strict, weak sequencing, assert, consider, ignore, negative thì phương pháp đề xuất trong [72] chưa giải quyết được. Phương pháp đề xuất giải quyết được các trường hợp biểu đồ tuần tự có các khối lồng ghép và giải quyết thêm được bảy khối như trên của biểu đồ tuần tự.
Thực nghiệm so sánh độ bao phủ:Để thẩm định tính hiệu quả và đúng đắn của cơng cụ, với đầu vào là các biểu đồ tuần tự và các ràng buộc tương ứng trong biểu đồ lớp của các chức năng sau: máy bán hàng tự động (ví dụ 3.1), chức năng sử dụng biến con trỏ động (ví dụ 3.2), chức năng Bán hàng qua mạng, Đăng kí thành viên của một website và Tìm kiếm thơng tin người dùng. Áp dụng công cụ SequenceTesting để sinh các kịch bản và dữ liệu kiểm thử cho các chức năng trên. Theo thực nghiệm, với mỗi chức năng trên khi các kịch bản kiểm thử được sinh ra thì các kịch bản đó giống về mặt ngữ nghĩa với các tuần tự của biểu đồ ban đầu. Kết quả thực nghiệm đưa ra so sánh phần trăm độ bao phủ đường dẫn trong đồ thị sinh ra với phần trăm độ bao phủ thông điệp của
Bảng 3.5: So sánh kết quả đề xuất và kết quả nghiên cứu trong [72]
Thứ tự Khối đơn Phương pháp đưa
ra trong [72]
Phương pháp đề xuất
1 Khơng có khối nào Yes Yes
2 Alternative Yes Yes
3 Loop Yes Yes
4 Option Yes Yes
5 Break Yes Yes
6 Parallel Yes Yes
7 Critical No Yes
8 Strict No Yes
9 Consider No Yes
10 Ignore No Yes
11 Weak sequencing No Yes
12 Nagative No Yes
13 Assertion No Yes
14 Các khối lồng nhau Yes Yes
biểu đồ tuần tự ban đầu và phần trăm độ bao phủ đạt được theo cách tiếp cận của kiểm thử ngẫu nhiên. Từ các kết quả trên của thực nghiệm, luận án có một số thảo luận như sau:
So với nghiên cứu trong [72], điểm mới của phương pháp chuyển đổi CFG được đề xuất là: phát triển thêm cho các toán tử weak sequencing, strict, critical, ignore, consider, assert và negative và cải tiến đối với toán tử par- allel. Việc chuyển đổi sang CFG của toán tử parallel trong nghiên cứu [72] là chuyển từng toán hạng tương ứng với các nút của đồ thị, trong khi đó phương pháp đề xuất thì chuyển đổi từng thơng điệp tương ứng với từng nút để thuật toán sinh các đường dẫn kiểm thử thực hiện đan xen nhau.
Công cụ cài đặt đã thể hiện một quy trình kiểm thử từ các biểu đồ UML 2.0. Để đảm bảo tính đúng đắn của việc chuyển từ biểu đồ tuần tự UML sang CFG, xem xét về mặt thực nghiệm qua các chức năng trên thì ngữ nghĩa tương tác sinh từ CFG giống ngữ nghĩa ban đầu theo đúng tuần tự ban đầu của biểu đồ tuần tự. Hơn nữa, thực nghiệm cũng chỉ ra các thông tin của các phương phức và các ràng buộc của các biến trong các biểu đồ gốc đều được chuyển tương ứng sang CFG. Quy trình này giúp các cơng ty phần mềm có thể thực hiện thiết kế kiểm thử tự động ngay ở giai đoạn đầu
Bảng 3.6: Thực nghiệm đưa ra độ bao phủ các đường dẫn của đồ thị của phươngpháp đưa ra và phương pháp kiểm thử ngẫu nhiên pháp đưa ra và phương pháp kiểm thử ngẫu nhiên
Chức năng Số thông điệp Số kịch bản kiểm thử Độ bao phủ đường dẫn trong phương pháp ngẫu nhiên Độ bao phủ đường dẫn trong phương pháp đưa ra Độ bao phủ thông điệp trong biểu đồ tuần tự Máy bán hàng tự động 12 5 78% 100% 100%
Chức năng biến con trỏ động
4 4 75% 100% 100%
Bán hàng qua mạng 9 5 68% 100% 100%
Đăng kí thành viên 10 9 62% 95% 100%
Tìm kiếm thơng tin 12 10 66% 92% 100%
của quá trình phát triển phần mềm. Tuy nhiên, trong phạm vi của nghiên cứu này, các hệ thống thực nghiệm còn đơn giản.
3.4.2.2 Thực nghiệm và đánh giá phần sinh dữ liệu kiểm thử tự động
Ưu nhược điểm của phương pháp mà luận án đề xuất được thể hiện rõ khi so sánh với phương pháp trong [30]. Trong cách tiếp cận này, với đầu vào là biểu đồ tuần tự và biểu đồ lớp sử dụng đồ thị tham số biến và bộ giải Alloy để sinh ra các dữ liệu kiểm thử. Trong thực nghiệm, tác giả sử dụng cùng một tập các chức năng và dữ liệu được dùng trong [30] đó là: hệ thống bán hàng online (online shoping system – OSHOP) và hệ thống các thành phần mơ hình UML (UML model composition system – COMP). Các mơ hình trong hệ thống OSHOP có một biểu đồ lớp gồm sáu lớp, ba biểu đồ tuần tự và trong từng biểu đồ tuần tự gồm mười đến mười hai thơng điệp và mười hai tốn tử. Các mơ hình trong hệ thống COMP bao gồm một biểu đồ lớp gồm năm lớp, một biểu đồ tuần tự gồm
41 thông điệp và mười bốn toán tử.
Một tập hợp các loại lỗi được đưa ra bởi việc xác định các lỗi phổ biến trong các hệ thống. Danh sách các loại lỗi đó được tạo ra dựa trên việc nghiên cứu các mơ hình thiết kế và độ phân tích đột biến của các biểu đồ UML [31]. Luận án sử dụng một danh sách các lỗi (được miêu tả chi tiết các lỗi trong [30, 36]) tiềm ẩn phổ biến trong các biểu đồ sử dụng như sau: thiếu thông điệp (Missing message – MM); Thứ tự gọi của các thông điệp sai (Faulty order of message – FOM);
Sai thông điệp (Faulty message – FM); Giới hạn phạm vi của cấu trúc điều kiện (Restrict the scope of condition structures – SCS); Mở rộng phạm vi của cấu trúc điều kiện (Broaden the scope of condition structures – BCS); Các tham số sai (Faulty parameters – FP); Thiếu nhánh trong cấu trúc thay thế (Missing branch of an alternative structure – MBA); Điều kiện sai (Faulty condition – FC); Bản số quan hệ giữa các lớp sai (Faulty association end multiplicities – FAM); Cây thừa kế sai (Wrong inheritance tree – WIT); Tham chiếu đến lớp cha sai (wrong reference to parent class – WRP); Các vị từ ràng buộc OCL sai (Faulty OCL predicate – FOP).
Sau đó, thực hiện cấy các lỗi vào hệ thống thực nghiệm. Các lỗi từ các loại trên được cấy vào các biểu đồ từng lỗi một. Thực nghiệm đưa ra tìm được 42lỗi trong các biểu đồ. Thực hiện sinh các kịch bản kiểm thử theo phương pháp tiếp cận trong [30] và theo phương pháp đề xuất. Cả hai phương pháp đều theo các tiêu chuẩn bao phủ khác nhau: tiêu chuẩn bao phủ các thông điệp “All Message Coverage (Msg)” và tiêu chuẩn bao phủ điều kiện “Condition Coverage (Cond)”. Kết quả thực nghiệm trong Bảng 3.7 đưa ra tổng kết số lượng các lỗi được tìm trong từng tiêu chuẩn. Theo phương pháp trong [30] có 42lỗi được cấy vào thì 35 lỗi (khoảng 83%) được tìm thấy bởi đầu vào kiểm thử thỏa mãn tiêu chuẩn bao phủ điều kiện. Theo tiêu chuẩn bao phủ thơng điệp thì tìm được 32
lỗi. Trong khi đó theo phương pháp luận án đề xuất thì tìm được 40lỗi của tiêu chuẩn bao phủ điều kiện (khoảng 95%) và tiêu chuẩn bao phủ thơng điệp tìm được 39 lỗi (khoảng 92%). Có hai lỗi khơng được tìm thấy bởi bất kỳ dữ liệu kiểm thử được sinh ra trong phương pháp này. Hai lỗi không được phát hiện trong biểu đồ lớp. Những lỗi này xảy ra trong trường hợp biểu đồ lớp bị lỗi bởi đặc trưng cho một bộ cấu hình nhỏ hơn biểu đồ lớp ban đầu.
Như vậy, từ kết quả các thực nghiệm, tác giả có một số thảo luận như sau:
Phương pháp đề xuất giải và thực thi được các ràng buộc mà biến có kiểu dữ liệu cấu trúc động và không bị giới hạn kiểu dữ liệu của các biến khi so sánh với nghiên cứu trong [30, 97].
Phương pháp đề xuất sinh ra các kịch bản kiểm thử có độ bao phủ tốt hơn và có thể tìm được nhiều lỗi hơn trong hầu hết các trường hợp so với một số phương pháp hiện tại. Phương pháp thích hợp với các hệ thống mà các
Bảng 3.7: Kết quả thực nghiệm so sánh phương pháp đề xuất với phương pháp [30]
Loại lỗi Số lỗi gieo Phương pháp trong [30] Phương pháp đề xuất
Số lỗi bởi bao phủ điều kiện Số lỗi bởi bao phủ thông điệp Số lỗi bởi bao phủ điều kiện Số lỗi bởi bao phủ thông điệp MM 5 5 5 5 5 FOM 5 4 4 4 4 SCS 2 2 2 2 2 BCS 1 0 0 1 1 FM 5 5 5 5 5 FP 5 4 4 4 5 MBA 5 5 5 5 5 FC 4 3 1 4 3 FAM 4 2 2 4 3 WIT 2 2 2 2 2 WRP 1 0 0 1 1 FOP 3 3 2 3 3 Tổng 42 35 32 40 39
biểu đồ tuần tự và biểu đồ lớp được chỉ rõ các ràng buộc mà biến là các biến số và cấu trúc động.
Tính đúng đắn của các phương pháp đề xuất đã được kiểm chứng dựa trên cơ sở thực nghiệm với một số hệ thống điển hình. Với mỗi hệ thống áp dụng, luận án đã sử dụng phương pháp song mô phỏng để chạy từng bước của thuật toán và so sánh kết quả đạt được với kết quả mong muốn. Với các chức năng được áp dụng trong công cụ cài đặt hiện nay, các kết quả thu được từ q trình song mơ phỏng đều chính xác. Tác giả đang nghiên cứu các giải pháp để chứng minh tính đúng đắn của phương pháp đề xuất về mặt lý thuyết nhưng đây là vấn đề khó.
Khả năng áp dụng cho dự án thực tế: độ phức tạp trong các thuật toán chuyển đổi CFG lớn nhất là độ phức tạp đa thức (phụ thuộc vào số lượng thơng điệp, số tốn hạng, số tốn tử và số lượng biến trong một thông điệp); và độ phức tạp trong các thuật toán sinh tự động dữ liệu kiểm thử là độ phức tạp hàm mũ (phụ thuộc vào số lượng biến trong ràng buộc, số điểm di chuyển từ điểm ban đầu đến điểm tối ưu của hàm vị từ). Tuy nhiên, trong phát triển phần mềm hướng đối tượng các biểu đồ tuần tự UML miêu tả tương ứng với hành vi trong một ca sử dụng, do đó số lượng
các thông điệp, các tốn tử thực tế khơng thể lên tới hàng trăm. Hơn nữa, trong các ràng buộc của các biểu đồ tuần tự UML và biểu đồ lớp thực tế thì số lượng biến trong một ràng buộc hiếm khi lên đến hàng chục. Do đó, với thuật tốn đề xuất hồn tồn có thể khả thi cho các phần mềm trong thực tế.
3.5 Tổng kết
Chương 3 đã đề xuất một phương pháp tự động sinh dữ liệu kiểm thử từ biểu đồ tuần tự UML 2.0 và các ràng buộc OCL của biểu đồ lớp. Biểu đồ tuần tự UML 2.0 áp dụng cho tất cả mười hai tốn tử, có cấu trúc phức tạp, các khối lồng ghép được phân tích và chuyển đổi về CFG tương ứng. So với nghiên cứu trong [72], điểm mới của phương pháp đề xuất phát triển thêm cho các toán tử weak sequencing, strict, critical, ignore, consider, assert và negative và cải tiến đối với toán tử parallel. Các kết quả thực nghiệm chỉ ra rằng phương pháp đề xuất sinh các dữ liệu và kịch bản kiểm thử có độ bao phủ và có khả năng tìm lỗi tốt hơn so với một số phương pháp hiện tại. Các dữ liệu và kịch bản kiểm thử được sinh ra có thể chuyển thủ cơng thành các đoạn mã kiểm thử và thực thi kiểm thử tự động dựa trên các công cụ kiểm thử trong các hệ thống thực. Hơn nữa, so với nghiên cứu trong [30, 97] phương pháp sinh tự động dữ liệu kiểm thử trong các kịch bản kiểm thử không chỉ được áp dụng cho biến với các ràng buộc số mà còn áp dụng cho kiểu dữ liệu cấu trúc động. Với giải pháp này, một số vấn đề khó áp dụng các phương pháp kiểm thử dựa trên mơ hình do thiếu các phương pháp thiết kế kiểm thử được giải quyết.
Các kết quả trên đã được tác giả công bố trong bài báo “Phương pháp sinh các ca kiểm thử tự động từ các mơ hình thiết kế UML và ngơn ngữ ràng buộc đối tượng OCL”, tại Chuyên san các cơng trình Nghiên cứu phát triển và ứng dụng cơng nghệ thông tin và truyền thông (2014); và “Automated Testing for Java Programs with Test Cases Generation from Sequence Diagrams and Object Constraint Language” trong Hội thảo APLAS (2016) “The 14th Asian Symposium on Programming Languages and Systems”.
Tuy nhiên, phương pháp này vẫn còn một số hạn chế cần khắc phục. Các hệ thống thực nghiệm còn đơn giản, chưa thể hiện được sự phức tạp trong các
thiết kế thực tế. Khi thực hiện thiết kế kiểm thử tự động ở giai đoạn đầu trong quá trình phát triển phần mềm thì các kiểm thử viên cũng phải có kiến thức về thiết kế phần mềm, biết sử dụng công cụ để thiết kế các biểu đồ UML. Hơn nữa, thuật toán sinh dữ liệu kiểm thử là hàm tìm kiếm cục bộ, chưa phải tìm kiếm tồn cục. Tính đúng đắn của phương pháp sinh CFG chưa được chứng minh về mặt lý thuyết mà chỉ dựa trên cơ sở thực nghiệm với một số hệ thống điển hình. Tác giả đang nghiên cứu để áp dụng phương pháp này với một số hệ thống thực tế và lớn hơn để chứng minh tính hiệu quả của nó. Trong các nghiên cứu tiếp theo, tác giả sẽ tiến hành chứng minh về mặt lý thuyết tính đúng đắn của phương pháp này. Đồng thời, tiếp tục phát triển sinh các ca kiểm thử từ các loại biểu đồ UML khác hoặc kết hợp các loại biểu đồ khác để các ca kiểm thử có độ bao phủ tốt hơn. Việc sinh ra các kịch bản kiểm thử trong các ứng dụng tương tranh để tránh bùng nổ các ca kiểm thử, hoặc sinh dữ liệu kiểm thử đối với kiểm thử vòng lặp, sinh dữ liệu kiểm thử đối với các ràng buộc chuỗi là các vấn đề sẽ giải quyết trong các chương tiếp theo.
Chương 4
SINH DỮ LIỆU KIỂM THỬ CHO VÒNG LẶP VÀ CÁC ỨNG DỤNG TƯƠNG TRANH
Chương này trình bày phương pháp cải tiến việc sinh dữ liệu kiểm thử từ biểu đồ tuần tự UML 2.0 và biểu đồ lớp với các trường hợp của kiểm thử vịng lặp. Hơn nữa, thuật tốn đề xuất sinh các kịch bản kiểm thử để tránh trường hợp bùng nổ số lượng các kịch bản đối với toán tử song song và tuần tự yếu. Phương pháp cải tiến việc sinh các kịch bản kiểm thử theo các độ bao phủ tương tranh khác nhau, sinh dữ liệu kiểm thử theo độ bao phủ lặp. Một số thực nghiệm chỉ ra khả năng tìm lỗi của các kịch bản và dữ liệu kiểm thử sinh ra tốt hơn so với một số phương pháp hiện tại.