2.3.2 Các ràng buộc OCL trong các biểu đồ UML
Ngôn ngữ ràng buộc đối tượng (OCL) [77] là ngơn ngữ hình thức được sử dụng để miêu tả các biểu thức trong các biểu đồ UML. Những biểu thức này thường chỉ rõ các điều kiện bất biến trong hệ thống được mơ hình hóa hoặc ràng buộc trong các đối tượng của các biểu đồ. Các biểu thức OCL có thể được chỉ rõ để xác định các hành động, các toán tử khi thực hiện làm thay đổi trạng thái của hệ thống. Người thiết kế các biểu đồ UML sử dụng OCL để đặc tả các ràng buộc mà nhiều khi không thể biểu diễn được trong các biểu đồ UML. Trong các biểu đồ UML, OCL được sử dụng với các mục đích khác nhau: sử dụng như ngôn ngữ truy vấn, chỉ rõ các bất biến trong các lớp và các loại trong mơ hình lớp, đặc tả các loại bất biến, miêu tả các tiền và hậu điều kiện trong các toán tử và phương thức, miêu tả các điều kiện (guards), các ràng buộc trong các toán tử và các quy tắc dẫn xuất của các thuộc tính cho bất kỳ biểu thức nào trong biểu đồ UML. Hình 2.8 biểu diễn ví dụ biểu đồ lớp có bất biến viết bằng biểu thức OCL: số lượng nhân viên (numberOfEmployees) trong công ty lớn hơn 50
hoặc tuổi của mỗi người (age) phải lớn hơn 18 biểu diễn như sau: context c : Company inv:
c.numberOfEmployees > 50
context Person inv: self.age > 18
Các tiền và hậu điều kiện như sau:
context Person::income(d : Date) : Integer post: result = 5000
Person income(Date) : Integer isMarried : Boolean isUnemployed : Boolean birthDate : Date age : Integer firstName : String lastName : String gender : Gender Company stockPrice() : Real name : String numberOfEmployees : Integer Job title : String startDate : Date salary : Integer Marriage place : String date : Date manager 0..* 1 managedCompanies employee employeer 0..* 0..* 0..1 0..1 wife husband Hình 2.8: Ví dụ biểu đồ lớp.
Các thuộc tính của lớp có thể định nghĩa qua các biểu thức OCL như sau: context Person
def: income : Integer = self.job.salary->sum() def: nickname : String = “Little Red Rooster”
2.3.3 Đồ thị dịng điều khiển
Mục tiêu chính của nghiên cứu là sinh các dữ liệu kiểm thử từ biểu đồ tuần tự UML và các ràng buộc OCL. Tuy nhiên, chúng ta khơng có cách sinh trực tiếp từ cấu trúc dữ liệu này. Để đạt được mục tiêu trên, luận án xây dựng một đồ thị dòng điều khiển (Control Flow Graph – CFG) đặc tả hành vi như cấu trúc dữ liệu trung gian cho việc sinh dữ liệu kiểm thử.
Theo [72], đồ thị dòng điều khiển là đồ thị được biểu diễn trực tiếp tương ứng với biểu đồ tuần tự đưa ra và các thông tin về ràng buộc được lấy từ biểu đồ lớp. Có năm loại nút (đỉnh) của đồ thị (Hình 2.9): block node (BN), decision node (DN), merge node (MN), fork node (FN) và join node (JN). Trong đó, BN là nút tương ứng với từng thông điệp (message) trong đồ thị; Một DN biểu diễn biểu thức điều kiện là các biểu thức logic thỏa mãn cho việc lựa chọn các tốn hạng trong các tốn tử (ví dụ: tốn tử alt, opt, loop, v.v.); Một MN biểu diễn
BN
DN
MN
FN
JN
Hình 2.9: Các loại nút của đồ thị dòng điều khiển
nút ra của các tốn tử lựa chọn (ví dụ alt, opt); Một FN biểu diễn đầu vào trong khi đó JN biểu diễn đầu ra của toán tử song song (parallel) và tuần tự yếu (weak sequencing). Các cạnh biểu diễn dòng điều khiển giữa các nút, các cạnh đi từ DN sẽ được gắn với vị từ.
Đồ thị dòng điều khiển G được định nghĩa [72] như sau: G = (A, E,in, F)
trong đó, A là một tập các nút (bao gồm BN, DN, MN, FN và JN); in là nút khởi tạo và F là tập hợp các nút kết thúc của đồ thị; E là tập các cạnh của đồ thị sao cho: E = {(x, y)|x, y ∈A∪F}. Với cấu trúc của từng nútAi ∈Ađược bao gồm: <noId, noType, noDetails, outEdge>, trong đó:
noId là nhãn duy nhất gắn trong từng nút,
noType là một trong các loại nút in, BN, DN, MN, FN, JN và f ni,
noDetails = <m1, m2, ..., mq> với q là số các thông điệp trong Bi ∈ BN. Mỗi nút Bi biểu diễn một thông điệp hoặc tuần tự các thông điệp mi. Mỗi thông điệp mi bao gồm các thông tin của lớp gửi và lớp nhận trong biểu đồ lớp và có cấu trúc như sau: (mi, parameterList, returnV alue); trong đó,
mỗi thơng điệp hay phương thức mi bao gồm một danh sách các tham số
parameterList= <p1, p2, ..., pn> và giá trị trả về returnV alue. Mỗi tham số pi của phương thức mi trong biểu đồ tuần tự có thể bao gồm thuộc tính với các ràng buộc trong biểu đồ lớp. Tham số và giá trị trả về được lấy kiểu dữ liệu, thông tin về ràng buộc từ biểu đồ lớp và có cấu trúc như sau: <name, dataT ype, value, constraint> trong đó, name là tên tham số hoặc thuộc tính; dataT ype là loại dữ liệu của tham số hoặc thuộc tính tương ứng; value là giá trị được gán cho tham số; constraint chỉ các ràng buộc là các biểu thức OCL được xác định trong thuộc tính của biểu đồ lớp, và
outEdge = {oE1, oE2, ..., oEq}| q là số lượng các cạnh ra từ DN. Mỗi cạnh
oEi ∈ outEdge được xác định gồm: <noId, predicate> trong đó, noId là nhãn được gắn với nút tạo ra và predicate là các biểu thức logic, kiểm tra điều kiện trong các toán tử của biểu đồ tuần tự.
2.4 Các độ bao phủ và độ phân tích đột biến trongkiểm thử kiểm thử
Độ bao phủ là độ đo kiểm thử của một chương trình của một tập ca kiểm thử. Mức độ bao phủ của một bộ kiểm thử (tập các ca kiểm thử) được đo bằng tỷ lệ các thành phần thực sự được kiểm thử so với tổng thể sau khi đã thực hiện các ca kiểm thử. Độ bao phủ càng lớn thì độ tin cậy của bộ các ca kiểm thử càng cao. Độ đo này giúp kiểm soát và quản lý quá trình kiểm thử tốt hơn, với mục tiêu của quá trình kiểm thử là số ca kiểm thử tối thiểu nhưng đạt được độ bao phủ tối đa. Trong luận án có sử dụng độ bao phủ tương tranh và độ bao phủ lặp để sinh các kịch bản và dữ liệu kiểm thử tương ứng theo các độ bao phủ này. Ngồi ra, độ phân tích đột biến cũng được sử dụng để đo khả năng tìm lỗi của các kịch bản kiểm thử được sinh ra.
2.4.1 Độ bao phủ tương tranh
Sinh các kịch bản kiểm thử là bước tiên quyết trước khi sinh các ca kiểm thử. Việc sinh ra tất cả các đường dẫn kiểm thử là không thể cũng như không thể kiểm thử được tất cả các trường hợp với mọi dữ liệu kiểm thử vì nguồn lực kiểm thử có giới hạn. Vì vậy, các tiêu chuẩn bao phủ được đưa ra. Trong tính chất tương tranh của các ứng dụng, được thể hiện bởi toán tử song song, tuần tự yếu và các thông điệp bất đồng bộ trong biểu đồ tuần tự UML, có ba tiêu chuẩn bao phủ tương tranh [95, 93] như sau:
Bao phủ tương tranh yếu: các ca kiểm thử được sinh ra bao phủ chỉ một tuần tự khả thi của các tiến trình song song với khơng có sự đan xen giữa các thơng điệp trong các tiến trình song song đó.
Bao phủ tương tranh trung bình: các ca kiểm thử được sinh ra bao phủ tất cả các tuần tự khả thi của các tiến trình song song với khơng có sự đan
xen giữa các thơng điệp trong các tiến trình song song đó.
Bao phủ tương tranh mạnh: các ca kiểm thử được sinh ra bao phủ tất cả các tuần tự khả thi của các tiến trình song song có sự đan xen giữa các thơng điệp trong các tiến trình song song đó.
Rõ ràng, các tiêu chuẩn bao phủ tương tranh yêu cầu các kịch bản kiểm thử được sinh ra bao phủ ít nhất một tiến trình song song. Cả tiêu chuẩn bao phủ yếu và trung bình đều kiểm thử các thơng điệp và luồng điều khiển trong tiến trình song song theo cách tuần tự. Tiêu chuẩn bao phủ tương tranh mạnh có sự đan xen giữa các thông điệp trong các luồng điều khiển của các tiến trình song song, do vậy số lượng các kịch bản kiểm thử có thể rất lớn và khơng thực tiễn.
2.4.2 Độ bao phủ trong kiểm thử vòng lặp
Phương pháp sinh kiểm thử trong đồ thị dịng điều khiển khơng thể kiểm thử hết các vịng lặp xuất hiện trong các mơ hình. Lý do là các đường đi kiểm thử sinh ra từ đồ thị dòng điều khiển khơng thể chứa hết các vịng lặp. Trong thực tế, lỗi hay xảy ra ở các vịng lặp. Vì lý do này, chúng ta cần sinh các ca kiểm thử cho các vịng lặp nhằm giảm tỷ lệ lỗi của các mơ hình. Với mỗi mơ hình có vịng lặp, độ bao phủ trong kiểm thử vịng lặp có ba trường hợp sau:
Lặp đơn giản: việc sinh kiểm thử từ mơ hình mà các đường dẫn kiểm thử chỉ chứa đúng một vòng lặp (thân của vịng lặp khơng chứa vịng lặp khác).
Lặp liền kề: việc sinh kiểm thử từ mơ hình mà các đường dẫn kiểm thử chứa các lần lặp kế tiếp nhau.
Lặp lồng nhau: việc sinh kiểm thử từ mơ hình gồm các vịng lặp chứa các vòng lặp khác.
Trong nhiều cách tiếp cận [72, 65], việc sinh các đường dẫn kiểm thử chỉ được thực hiện tối đa một lần lặp nên rất khó để phát hiện các lỗi tiềm ẩn bên trong vịng lặp này. Các lỗi có thể xảy ra khi vịng lặp được thực hiện nhiều lần lặp. Để giải vấn đề này, chúng ta cần sinh thêm các ca kiểm thử tương ứng như sau:
Vòng lặp thực hiện 1 lần.
Vòng lặp thực hiện 2 lần.
Vòng lặp thực hiện k lần, 2< k < n−1, với n là số lần lặp tối đa.
Vòng lặp thực hiện n−1 lần.
Vòng lặp thực hiện n lần.
Vòng lặp thực hiện n+ 1 lần.
Trong một số trường hợp có thể khơng xác định được số lần lặp tối đa của các vòng lặp. Trong trường hợp này, chúng ta chỉ cần sinh bốn trường hợp kiểm thử đầu tiên. Tương tự, đa số các trường hợp chúng ta không thể sinh ca kiểm thử để vịng lặp thực hiện n+ 1 lần, vì số lần lặp tối đa là n. Với các mơ hình có các
vòng lặp liền kề, chúng ta tiến hành kiểm thử tuần tự từ trên xuống. Mỗi vòng lặp được kiểm thử bằng bảy ca kiểm thử như vịng lặp đơn giản (như đã mơ tả ở trên). Trong trường hợp các vòng lặp lồng nhau, chúng ta tiến hành kiểm thử tuần tự các vòng lặp theo thứ tự từ trong ra ngồi (mỗi vịng lặp cũng dùng bảy ca kiểm thử như trên). Như vậy, với các trường hợp tương ứng thì trong Phần 4.3.3 thuật toán sinh dữ liệu kiểm thử đối với vịng lặp sẽ được đưa ra.
2.4.3 Độ phân tích đột biến
Độ phân tích đột biến để đánh giá sự hiệu quả của các kỹ thuật kiểm thử phần mềm khác nhau [94]. Kiểm thử đột biến là kỹ thuật kiểm thử dựa trên lỗi khi giả thiết chắc chắn các loại lỗi cấy vào chương trình và sau đó thiết kế các ca kiểm thử với mục đích phát hiện các lỗi đó. Các lỗi được đưa vào chương trình bởi việc tạo một tập các phiên bản lỗi gọi là các đột biến. Những đột biến này được tạo ra từ chương trình gốc bởi việc áp dụng các tốn tử đột biến, mơ tả sự thay đổi vào chương trình gốc. Ca kiểm thử được sử dụng để thực thi những đột biến với mục đích gây nên những đột biến tạo ra kết quả đầu ra khơng chính xác. Độ đo đột biến (Mutation Score – MS) để đo chất lượng của một tập các ca kiểm thử theo công thức sau:
M S(p, t) = Nk
Từ cơng thức (2.1), trong đó: p là chương trình sẽ được cấy đột biến; t là bộ kiểm thử; Nk là số lượng các đột biến bị diệt; Nm là tổng số đột biến; Ne là số đột biến tương đương (đột biến tương đương là đột biến của chương trình, hoạt động hồn tồn giống chương trình gốc và cho ra kết quả giống với chương trình gốc trong mọi trường hợp kiểm thử). Toán tử đột biến là một luật được áp dụng vào chương trình để tạo ra các đột biến. Các tốn tử này được xác định bởi ngơn ngữ của chương trình và hệ thống đột biến được dùng để kiểm thử. Quy trình kiểm thử đột biến: Kiểm thử đột biến là một quy trình được lặp đi lặp lại để cải tiến dữ liệu kiểm thử đối với một chương trình và được chia thành các bước cơ bản [28] như sau:
Bước 1: Sinh đột biến (dùng công cụ sinh tự động hoặc sinh thủ cơng) từ chương trình.
Bước 2: Sinh các dữ liệu kiểm thử.
Bước 3: Thực hiện từng dữ liệu kiểm thử với chương trình gốc. Nếu kết quả đúng thì thực hiện bước tiếp theo. Trong trường hợp ngược lại thì phải chỉnh sửa lại chương trình và tiến hành kiểm thử lại.
Bước 4: Thực hiện từng dữ liệu kiểm thử với từng đột biến còn sống. Trường hợp đột biến bị diệt nếu kết quả ra khơng giống với chương trình gốc, hồn thành kiểm thử. Ngược lại, phân tích các đột biến nếu các đột biến sống sót được qua kiểm thử. Có hai khả năng: trường hợp đột biến không thể bị diệt nếu các đột biến là tương đương; trường hợp cịn lại có thể diệt các đột biến được nhưng các dữ liệu kiểm thử không đủ mạnh để diệt đột biến. Do đó, thực hiện với các dữ liệu kiểm thử khác và lặp lại Bước 1.
Vậy độ đo MS càng cao thì khả năng tìm lỗi càng lớn. MS để đo tính hiệu quả của các kỹ thuật kiểm thử. Trong cách tiếp cận này dùng MS đo các kịch bản kiểm thử và đánh giá phương pháp sinh các ca kiểm thử được đề xuất.
2.5 Tổng quan về sinh dữ liệu kiểm thử tự độngPhần này trình bày một cách tổng quan về các hướng tiếp cận sinh dữ liệu Phần này trình bày một cách tổng quan về các hướng tiếp cận sinh dữ liệu kiểm thử tự động. Sự cần thiết trong việc sinh dữ liệu kiểm thử tự động xuất
phát từ hai mục đích chính: để tăng chất lượng phần mềm và giảm chi phí phát triển. Các trường hợp kiểm thử ngoại lệ thì khơng có một tiêu chuẩn kiểm thử đầy đủ nào. Do đó, xem xét đầy đủ các tiêu chuẩn bao phủ kiểm thử cho các trường hợp cơ bản để hướng tới việc sinh tự động dữ liệu kiểm thử là phương thức hiệu quả mang tính hệ thống. Mục đích của phần này là cung cấp các phương pháp tiếp cận chung cho việc sinh tự động dữ liệu kiểm thử và những khó khăn tồn tại, khả năng ứng dụng vào quy trình kiểm thử trong thực tế.
Ĉӏnh hѭӟng mөc ÿích Dӵa trên chuӛi (chaining) Phѭѫng pháp sӕ Kӻ thuұt tӕi ѭu Kӻ thuұt tӕi ѭu Z Kӻ thuұt dӵa trên cú pháp Kӻ thuұt ÿһc tҧ cho máy hӳu hҥn
trҥng thái Dӵa trên giҧi ràng buӝc Thӵc thi tѭӧng trѭng Giҧm miӅn ÿӝng Ph˱˯ng pháp tƭnh Ph˱˯ng pháp ÿ͡ng Sinh dӳ liӋu kiӇm thӱ ngүu nhiên thi gian các ph ng pháp kim th Hình 2.10: Các hướng tiếp cận của sinh dữ liệu kiểm thử tự động [99].
Hình 2.10 chỉ ra một cách tổng quan về các hướng tiếp cận sinh dữ liệu kiểm thử tự động. Trong đó, theo trục đứng hướng lên trên là chiều tăng dần về thời gian của các phương pháp kiểm thử được đưa ra và trục ngang là các phương pháp kiểm thử khác nhau.
2.5.1 Sinh dữ liệu kiểm thử trong kiểm thử cấu trúc
Các cách tiếp cận dựa trên cấu trúc có thể chia ra làm ba loại: phương pháp tĩnh, phương pháp động và kết hợp cả hai. Các phương pháp tiếp cận tĩnh sử dụng thực thi các tượng trưng để xác định tĩnh các đường đi và sử dụng các tiêu chuẩn khác nhau để sinh ra dữ liệu kiểm thử. Cách tiếp cận động thực thi trực tiếp hệ thống kiểm thử để tìm kiếm dữ liệu kiểm thử mong muốn. Việc sử dụng cả thực thi tượng tương và thực thi SUT là phương pháp kết hợp cả hai.
2.5.1.1 Các phương pháp sinh dữ liệu kiểm thử tĩnh
Đây là những phương pháp kiểm thử được sử dụng cho việc phân tích và