(Luận án tiến sĩ) các kỹ thuật sinh tự động dữ liệu kiểm thử dựa trên các biểu đồ UML luận án TS máy tính 624801

Vì vậy, luận án tập trung vào việc giải quyếtcác đặc trưng, các toán tử của biểu đồ tuần tự UML 2.0; tránh bùng nổ số lượngkịch bản kiểm thử sinh ra, các vòng lặp, các trường hợp khóa ch

CÁC KỸ THUẬT SINH TỰ ĐỘNG DỮ LIỆU KIỂM THỬ DỰA TRÊN CÁC BIỂU ĐỒ UML

VŨ THỊ ĐÀO

Tháng 04 năm 2018

LỜI CẢM ƠN

Luận án được thực hiện tại Trường Đại học Công nghệ, Đại học Quốc gia

Hà Nội, dưới sự hướng dẫn của PGS.TS Nguyễn Việt Hà

Tôi xin gửi lời cảm ơn chân thành và sâu sắc nhất tới PGS.TS NguyễnViệt Hà – Bộ môn Công nghệ phần mềm, Khoa Công nghệ thông tin, TrườngĐại học Công nghệ Người thầy tâm huyết đã tận tình hướng dẫn, động viênkhích lệ, dành nhiều thời gian quí báu để định hướng cho tôi trong quá trìnhtham gia khóa học và hoàn thiện luận án

Tôi xin gửi lời cảm ơn chân thành tới lãnh đạo trường Đại học Công nghệ,lãnh đạo Khoa Công nghệ thông tin, cảm ơn các đồng nghiệp đã tạo điều kiệnthuận lợi cho tôi trong quá trình làm luận án

Tôi xin gửi lời cảm ơn chân thành tới các thầy, cô trong Bộ môn Côngnghệ phần mềm, Khoa Công nghệ thông tin, Trường Đại học Công nghệ, nhữngngười luôn hướng dẫn, định hướng, góp ý cho tôi trong quá trình viết luận án.Cuối cùng, tôi xin gửi lời cảm ơn sâu sắc tới gia đình và bạn bè, nhữngngười đã luôn ủng hộ và hỗ trợ tôi về mọi mặt để tôi yên tâm học tập, nghiêncứu, và hoàn thành luận án

LỜI CAM ĐOAN

Tôi xin cam đoan: Bản luận án tốt nghiệp này là công trình nghiên cứuthực sự của cá nhân Các kết quả được viết chung với các tác giả khác đều được

sự đồng ý của các đồng tác giả trước khi đưa vào luận án Các kết quả nêu trongluận án là trung thực và chưa từng được công bố dưới bất cứ hình thức nàotrước khi trình, bảo vệ và công nhận bởi “Hội Đồng đánh giá luận án tốt nghiệpTiến sĩ Công nghệ Thông Tin”

Một lần nữa, tôi xin khẳng định về sự trung thực của lời cam kết trên

Tác giả:

MỤC LỤC

1.1 Đặt vấn đề 1

1.2 Phương pháp và nội dung nghiên cứu 4

1.3 Cấu trúc luận án 6

Chương 2 KIẾN THỨC NỀN TẢNG 7 2.1 Các khái niệm cơ bản 7

2.2 Kiểm thử dựa trên mô hình 8

2.3 Các biểu đồ UML và ràng buộc OCL 12

2.3.1 Biểu đồ tuần tự UML và các toán tử 12

2.3.2 Các ràng buộc OCL trong các biểu đồ UML 17

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

2.4 Các độ bao phủ và độ phân tích đột biến trong kiểm thử 20

2.4.1 Độ bao phủ tương tranh 20

2.4.2 Độ bao phủ trong kiểm thử vòng lặp 21

2.4.3 Độ phân tích đột biến 22

2.5 Tổng quan về sinh dữ liệu kiểm thử tự động 23

2.5.1 Sinh dữ liệu kiểm thử trong kiểm thử cấu trúc 24

2.5.2 Sinh dữ liệu kiểm thử trong kiểm thử chức năng 28

2.5.3 Sinh dữ liệu kiểm thử tự động từ các biểu đồ UML 30

2.6 Các công cụ sinh dữ liệu kiểm thử hiện tại 31

2.7 Tổng kết 34

Chương 3 SINH DỮ LIỆU KIỂM THỬ CHO KIỂU DỮ LIỆU SỐ VÀ CẤU TRÚC ĐỘNG 35 3.1 Giới thiệu 35

3.2 Những nghiên cứu liên quan 37

3.3 Phương pháp sinh dữ liệu kiểm thử cho biến kiểu dữ liệu số và cấu trúc động 40

3.3.1 Tổng quan về phương pháp đề xuất 40

3.3.2 Chuyển đổi biểu đồ tuần tự UML thành CFG 41

3.3.3 Sinh các kịch bản kiểm thử 57

3.3.4 Chọn các vị từ và chuyển thành các hàm vị từ 60

3.3.5 Hàm vị từ với các ràng buộc OCL 60

3.3.6 Sinh dữ liệu kiểm thử từ các hàm vị từ 65

3.4 Thực nghiệm 78

3.4.1 Công cụ 79

3.4.2 Kết quả và đánh giá 79

3.5 Tổng kết 85

CÁC ỨNG DỤNG TƯƠNG TRANH 87

4.1 Giới thiệu 87

4.2 Những nghiên cứu liên quan 88

4.3 Phương pháp sinh dữ liệu kiểm thử theo các độ bao phủ tương tranh và lặp 92

4.3.1 Tổng quan về phương pháp đề xuất 92

4.3.2 Sinh các kịch bản kiểm thử 93

4.3.3 Sinh dữ liệu kiểm thử 98

4.4 Thực nghiệm 109

4.4.1 Công cụ 109

4.4.2 Kết quả và đánh giá 110

4.5 Tổng kết 113

Chương 5 SINH DỮ LIỆU KIỂM THỬ CHO KIỂU DỮ LIỆU CHUỖI 115 5.1 Giới thiệu 115

5.2 Những nghiên cứu liên quan 117

5.3 Phương pháp sinh tự động dữ liệu kiểm thử cho các ràng buộc chuỗi 119

5.3.1 Tổng quan về phương pháp đề xuất 119

5.3.2 Sinh các kịch bản kiểm thử 120

5.3.3 Giải các ràng buộc chuỗi 122

5.4 Thực nghiệm 137

5.4.1 Công cụ 138

5.4.2 Kết quả và đánh giá 139

5.5 Tổng kết 142

Chương 6 KẾT LUẬN 144 6.1 Các kết quả đạt được của luận án 144

6.2 Hướng nghiên cứu tiếp theo 146

DANH MỤC CÁC CÔNG TRÌNH KHOA HỌC CỦA TÁC GIẢ

DANH MỤC CÁC THUẬT NGỮ VÀ KÝ HIỆU

rộng

sâu

Tên thuật ngữ đầy đủ Chữ viết tắt Giải nghĩa

thỏa được

bản dùng để tự động hóa

nhất

DANH MỤC CÁC BẢNG

2.1 Các biểu đồ UML và sử dụng để mô hình hóa cho kiểm thử [100] 30

3.1 Bảng giá trị chân lý cho các toán tử logic [3] 61

3.2 Hàm vị từ cho các toán tử logic trong OCL [3] 62

3.3 Hàm vị từ cho các toán tử quan hệ OCL cho kiểu dữ liệu số [3] 64 3.4 Các kịch bản kiểm thử được sinh ra của máy bán hàng tự động 70 3.5 So sánh kết quả đề xuất và kết quả nghiên cứu trong [72] 81

3.6 Thực nghiệm đưa ra độ bao phủ các đường dẫn của đồ thị của phương pháp đưa ra và phương pháp kiểm thử ngẫu nhiên 82

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] 84

4.1 Kết quả MS sử dụng cho từng kịch bản kiểm thử được sinh ra trong cách tiếp cận [95] và Phương pháp đề xuất 111

4.2 Kết quả MS của phương pháp đề xuất và phương pháp ngẫu nhiên112 5.1 Ví dụ giải các toán tử chuỗi 125

5.2 Cách Z3–str thực hiện xử lý các ràng buộc chuỗi trong Bảng 5.1 125 5.3 Ngữ pháp của các ràng buộc trong Z3–str, mở rộng cho searchvà replaceAll so với [114] 127

5.4 Định nghĩa cho Thuật toán 5.2 [114] 129

5.5 Các quy tắc giảm [114] 131

5.6 Quy tắc giảm sử dụng gọi đệ quy 133

5.7 Các quy tắc tiền xử lý cho các toán tử chuỗi 135 5.8 So sánh khả năng tìm lỗi của các chức năng trong các ứng dụng 140

5.9 So sánh xử lý các toán tử chuỗi và hiệu năng của SeqString vớiphương pháp của nhóm Tác giả Shoichiro [39] 141

DANH MỤC CÁC HÌNH VẼ

1.1 Các nội dung luận án giải quyết trong bài toán kiểm thử dựa trên

mô hình 5

2.1 Quy trình kiểm thử dựa trên mô hình [100] 9

2.2 Ví dụ biểu đồ tuần tự UML có toán tử alt và opt 14

2.3 Ví dụ biểu đồ tuần tự UML có toán tử loop và break 14

2.4 Ví dụ biểu đồ tuần tự UML có toán tử par và seq 15

2.5 Ví dụ biểu đồ tuần tự UML có toán tử strict và critical 16

2.6 Ví dụ biểu đồ tuần tự UML có toán tử ignore và consider 16

2.7 Ví dụ biểu đồ tuần tự UML có toán tử negative và assert 17

2.8 Ví dụ biểu đồ lớp 18

2.9 Các loại nút của đồ thị dòng điều khiển 19

2.10 Các hướng tiếp cận của sinh dữ liệu kiểm thử tự động [99] 24

2.11 Phân loại các công cụ sinh kiểm thử tự động [40] 32

3.1 Sinh ca kiểm thử sử dụng kiểm chứng mô hình theo cách tiếp cận [17] 38

3.2 Các bước cơ bản sinh các dữ liệu kiểm thử 41

3.3 Ví dụ biểu đồ tuần tự UML 43

3.4 File xmi sau khi chuẩn hóa mô tả dữ liệu của biểu đồ tuần tự trong Hình 3.3 43

3.5 Chuyển từ biểu đồ tuần tự sang CFG (của toán tử opt và alt) 48

3.6 Chuyển từ biểu đồ tuần tự sang CFG (của toán tử break và loop) 50 3.7 Chuyển từ biểu đồ tuần tự sang CFG (của toán tử par và seq) 51 3.8 Chuyển từ biểu đồ tuần tự sang CFG (của toán tử strict và critical) 53

3.9 Chuyển từ biểu đồ tuần tự sang CFG (của toán tử ignore và

consider) 54

3.10 Chuyển từ biểu đồ tuần tự sang CFG (của toán tử assert và negative) 55

3.11 Biểu đồ tuần tự của máy bán hàng tự động 71

3.12 Biểu đồ lớp của chức năng máy bán hàng tự động 71

3.13 Đồ thị dòng điều khiển của máy bán hàng tự động 72

3.14 Biểu đồ tuần tự với kiểu dữ liệu biến là cấu trúc động 76

3.15 Đồ thị dòng điều khiển với kiểu dữ liệu biến là cấu trúc động 76

3.16 Đường dẫn con P1 thực thi 77

3.17 Đường dẫn con P2 thực thi 78

3.18 Đường dẫn con P3 thực thi 78

3.19 Kiến trúc thực thi của SequenceTesting 80

4.1 Toán tử lặp chuyển sang CFG 91

4.2 Toán tử song song chuyển sang CFG 92

4.3 Quá trình sinh dữ liệu kiểm thử: phát triển từ [75] cho vòng lặp 100

4.4 Tính điểm chia split phụ thuộc các miền giá trị của biến trong [75].102 4.5 Biểu đồ tuần tự của chức năng chuyển tiền trong hệ thống ngân hàng 107

4.6 Biểu đồ lớp và ràng buộc OCL cho chức năng chuyển tiền 108

4.7 Đồ thị dòng điều khiển của chức năng chuyển tiền 108

4.8 Kiến trúc phát triển của công cụ SequenceConcur 110

5.1 Kiến trúc của Bộ giải Z3–str trong [114] 124

5.2 Biểu đồ tuần tự cho chức năng kiểm tra thông tin của một ứng dụng web 137

5.3 CFG của chức năng kiểm tra thông tin ứng dụng web 138

5.4 Kiến trúc của SeqString 139

TÓM TẮT LUẬN ÁN

Luận án nghiên cứu một số giải pháp hỗ trợ sinh dữ liệu kiểm thử tự động

từ các biểu đồ UML 2.0 Cụ thể, luận án tập trung giải quyết ở giai đoạn thiết

kế kiểm thử: sinh các kịch bản kiểm thử và sinh dữ liệu kiểm thử từ biểu đồtuần tự và các ràng buộc trong biểu đồ lớp Mục tiêu của phương pháp nghiêncứu là sinh dữ liệu kiểm thử có độ bao phủ tốt hơn, có khả năng tìm được nhiềulỗi trong các hệ thống phần mềm Vì vậy, luận án tập trung vào việc giải quyếtcác đặc trưng, các toán tử của biểu đồ tuần tự UML 2.0; tránh bùng nổ số lượngkịch bản kiểm thử sinh ra, các vòng lặp, các trường hợp khóa chết (deadlock)

và đồng bộ trong các ứng dụng tương tranh; giải các ràng buộc với các kiểu dữliệu khác nhau Luận án đã đạt được các kết quả chính như sau:

Thứ nhất, luận án đề xuất một quy trình sinh các dữ liệu kiểm thử từ biểu

đồ tuần tự UML 2.0 và các ràng buộc OCL trong biểu đồ lớp Biểu đồ tuần tựUML 2.0 áp dụng cho tất cả mười hai toán tử, có cấu trúc phức tạp, các khốilồng ghép Phương pháp áp dụng cho các ràng buộc với biến là kiểu dữ liệu số

và cấu trúc động

Thứ hai, luận án đề xuất một phương pháp sinh dữ liệu kiểm thử tự động

từ các biểu đồ tuần tự UML 2.0 và biểu đồ lớp trong trường hợp của bao phủvòng lặp và các ứng dụng tương tranh

Thứ ba, luận án đưa ra một phương pháp cải tiến việc sinh dữ liệu kiểmthử tự động từ các biểu đồ tuần tự UML 2.0 và biểu đồ lớp với việc giải quyếtcác ràng buộc chuỗi

Trong các phương pháp đề xuất, luận án đều xây dựng công cụ để cài đặt

và thực nghiệm trên đó Với mỗi thực nghiệm các dữ liệu kiểm thử và kịch bảnkiểm thử sinh ra được so sánh về độ bao phủ, khả năng tìm lỗi so với các phươngpháp hiện tại Kết quả cho thấy tính hiệu quả và độ tin cậy của phương pháp

về mặt thực nghiệm Những đề xuất đó giải quyết một phần trong hướng tiếpcận lớn về kiểm thử dựa trên mô hình (cụ thể là các biểu đồ UML)

Chương 1

GIỚI THIỆU

Trong quá trình phát triển phần mềm, kiểm thử là giai đoạn quan trọng

và thực sự cần thiết để tạo ra một hệ thống phần mềm có chất lượng cao [9, 67].Trong thực tế hơn 50% nỗ lực phát triển dành cho giai đoạn kiểm thử [6] và rấthiếm các sản phẩm phần mềm được sản xuất ra mà không có lỗi Các công typhần mềm cũng như các tổ chức phát triển phần mềm hướng tới giải pháp tựđộng hóa quá trình kiểm thử Một minh chứng thực tế là ngày càng có nhiềucác công cụ kiểm thử tự động đưa ra và được áp dụng trong thực tế Tuy nhiên,

đa số quá trình thực hiện đều tập trung vào việc thực thi kiểm thử tự động màkhông quan tâm nhiều đến việc thiết kế chúng Hơn nữa, việc phát hiện lỗi phầnmềm chủ yếu là do chất lượng của các kịch bản và dữ liệu kiểm thử được thiết

kế Các dữ liệu kiểm thử có độ bao phủ càng lớn thì độ tin cậy của tập dữ liệukiểm thử càng cao [24], có thể tìm được nhiều lỗi của hệ thống và giúp kiểm soát

và quản lý quá trình kiểm thử tốt hơn Như vậy, quá trình sinh các dữ liệu kiểmthử tự động trở nên thực sự cần thiết, nhất là đối với những phần mềm lớn vàphức tạp Quá trình này làm giảm giá thành phát triển phần mềm, tiết kiệmthời gian, công sức, nâng cao chất lượng và tăng độ tin cậy của phần mềm [41].Trong các hướng tiếp cận sinh tự động dữ liệu kiểm thử hiện nay thườngđược thực hiện từ mã nguồn chương trình, các mô hình hoặc các đặc tả [12, 100]

Có nhiều hướng nghiên cứu phát triển được đưa ra thực hiện từ mã nguồn chươngtrình trong [8, 34, 54, 75, 91, 110] Tuy nhiên, việc sinh tự động dữ liệu kiểmthử này được thực hiện ở giai đoạn sau khi có mã nguồn và số kịch bản kiểmthử được sinh ra rất lớn Hơn nữa, có rất nhiều ngôn ngữ lập trình khác nhaunên phương pháp sinh dữ liệu kiểm thử thường phụ thuộc nhiều vào công nghệ

phân tích mã nguồn Hướng thứ hai là sử dụng các mô hình [16, 72, 97, 24]hoặc các đặc tả [102, 64, 57] để thiết kế tự động các dữ liệu kiểm thử có thểxuất phát từ máy hữu hạn trạng thái (Finite State Machine – FSM), các biểu

đồ UML (Unified Modeling Language) hoặc các đặc tả bằng các ngôn ngữ hìnhthức khác nhau (chẳng hạn Z, B, v.v.) Việc áp dụng các đặc tả hình thức trongthực tiễn là khó thực hiện và tốn thời gian Hơn nữa, khi sử dụng phương phápnày đòi hỏi trình độ của các chuyên gia hiểu về đặc tả hình thức Vì vậy, tácgiả chọn hướng nghiên cứu từ các biểu đồ UML vì các biểu đồ UML được sửdụng phổ biến trong thực tiễn của các công ty phát triển phần mềm Việc sửdụng các biểu đồ UML có thể kết hợp với ngôn ngữ ràng buộc đối tượng (ObjectContraint Language – OCL) để biểu diễn các đặc tả ràng buộc mà nhiều khibiểu đồ không biểu diễn hết được Hơn nữa, việc thiết kế các dữ liệu kiểm thử

từ các biểu đồ này có thể thực hiện ở giai đoạn đầu của quá trình phát triển,không nhất thiết là phải đợi khi đã có mã nguồn chương trình

Kiểm thử từ các biểu đồ UML cũng như việc kiểm thử thông thường đượcthực hiện qua các bước: sinh các kịch bản kiểm thử, sinh dữ liệu kiểm thử vàthực thi các đoạn mã kiểm thử Vì việc thực thi các đoạn mã kiểm thử tự động

có nhiều công cụ hỗ trợ và phụ thuộc vào công nghệ, môi trường ngôn ngữ sửdụng Hơn nữa, vấn đề phát hiện lỗi trong các dự án phần mềm thì chủ yếu phụthuộc vào các kịch bản và dữ liệu kiểm thử được thiết kế Do đó, tác giả chọnhướng tập trung nghiên cứu vào các phương pháp sinh dữ liệu kiểm thử Cáchướng nghiên cứu việc sinh dữ liệu kiểm thử từ các biểu đồ UML phụ thuộcvào loại biểu đồ được sử dụng Tùy vào mục đích kiểm thử, mức độ kiểm thử sẽchọn biểu đồ phù hợp với yêu cầu đưa ra Tác giả Bader và các đồng sự trong [5]đưa ra một phương pháp cho việc sinh các dữ liệu kiểm thử từ biểu đồ trạngthái Tuy nhiên, nghiên cứu này cho rằng biểu đồ trạng thái có ý nghĩa với kiểmthử đơn vị, số lượng kịch bản kiểm thử sinh ra lớn và rất dễ bùng nổ các kịchbản kiểm thử Trong khi đó các dữ liệu kiểm thử và kịch bản kiểm thử sinh từcác biểu đồ tuần tự có ý nghĩa cho kiểm thử tích hợp [33] và số lượng kịch bảnkiểm thử sinh ra ít hơn khi so sánh với biểu đồ trạng thái [2] Hơn nữa, biểu đồtuần tự là biểu đồ chi tiết và giàu hành vi trong các biểu đồ UML Vì vậy, cácnhà nghiên cứu quan tâm đến việc sử dụng các biểu đồ tuần tự để sinh các dữliệu kiểm thử và các kịch bản kiểm thử Trong hướng nghiên cứu đó, với việcgiải quyết các toán tử của biểu đồ tuần tự thì phương pháp trong [72] sinh dữ

liệu kiểm thử từ biểu đồ tuần tự UML giải quyết với năm loại toán tử: alt, opt,break, parallel, loop và thuật toán sinh dữ liệu kiểm thử chủ yếu giải quyết vớikiểu dữ liệu số Trong một vài hướng tiếp cận khác như [97, 84, 65], các phươngpháp kỹ thuật hàm nhỏ nhất trong việc sinh dữ liệu kiểm thử tự động cũng chỉ

áp dụng với kiểu dữ liệu số Như vậy, việc sinh dữ liệu kiểm thử từ các biểu đồUML đối với các ràng buộc mà biến có các kiểu dữ liệu khác nhau như: kiểu dữliệu chuỗi, cấu trúc động và trong các trường hợp của vòng lặp chưa được đưa

ra hoặc chưa có lời giải thỏa đáng

Trong việc giải quyết bài toán sinh dữ liệu kiểm thử tự động từ các biểu

đồ UML thì việc bùng nổ số kịch bản kiểm thử, các trường hợp khóa chết, đồng

bộ trong các luồng song song của hệ thống cũng là vấn đề gặp phải nhiều khókhăn và thách thức Nhóm tác giả Sun và các đồng sự trong [93] đưa ra cáchtiếp cận dựa trên việc chuyển đổi để sinh ra các dữ liệu kiểm thử hướng kịch bản

từ biểu đồ hoạt động UML Cách tiếp cận này dựa trên các quy tắc chuyển đổi

để chuyển về cây nhị phân, sau đó dựa vào các thuật toán tìm kiếm trên cây nhịphân này để sinh các kịch bản kiểm thử Công cụ cài đặt sử dụng phương phápsinh dữ liệu kiểm thử ngẫu nhiên, chưa xét độ bao phủ của các dữ liệu kiểm thửsinh ra; các trường hợp khóa chết và vấn đề bùng nổ các kịch bản kiểm thử chưađược giải quyết Hướng tiếp cận trong [58, 89] đưa ra phương pháp sinh các kịchbản kiểm thử từ biểu đồ tuần tự và biểu đồ hoạt động trong các trường hợptương tranh Các dữ liệu kiểm thử sinh ra theo phương pháp này biểu diễn tínhtương tranh và có thể bao phủ các lỗi đồng bộ, khóa chết Tuy nhiên, phươngpháp đó chưa đưa ra các tiêu chuẩn bao phủ tương tranh khác nhau trong cácứng dụng, việc cài đặt thực thi tính hiệu quả cũng chưa được triển khai

Như vậy, các vấn đề mà luận án sẽ tập trung giải quyết cụ thể như sau:

ˆ Sinh dữ liệu kiểm thử từ các biểu đồ tuần tự UML 2.0 và các ràng buộcOCL trong biểu đồ lớp nhằm giải quyết cho tất cả mười hai toán tử, cócấu trúc lồng ghép nhau; Các ràng buộc với các biến là các biến kiểu dữliệu số và cấu trúc động

ˆ Sinh tự động dữ liệu kiểm thử từ các biểu đồ tuần tự UML 2.0 và các ràngbuộc trong biểu đồ lớp trong các ứng dụng tương tranh và với các độ baophủ khác nhau của vòng lặp

ˆ Sinh tự động dữ liệu kiểm thử từ các biểu đồ tuần tự UML 2.0 và các ràngbuộc trong biểu đồ lớp với việc giải quyết các ràng buộc chuỗi.

Để thực hiện các nội dung nghiên cứu trong luận án, tác giả tiến hành theophương pháp tiếp cận từ trên xuống, phân loại và hệ thống hóa lý thuyết cácphương pháp về sinh dữ liệu kiểm thử tự động từ mô hình, từ đó phân tích,phân loại và tổng hợp các phương pháp đó Theo cách phân loại đưa ra, tácgiả đi sâu phân tích mỗi đặc điểm và ưu nhược điểm của từng loại Từ phươngpháp phân tích và tổng hợp trên của kiểm thử dựa trên mô hình, tác giả chọnđối tượng nghiên cứu trong luận án là từ các biểu đồ tuần tự UML 2.0 và biểu

đồ lớp Từ đó với mỗi đặc trưng của từng loại biểu đồ, tác giả nghiên cứu liênquan để đề xuất cải tiến hoặc đưa ra phương pháp mới về sinh dữ liệu kiểm thử.Trong phạm vi của luận án, tác giả tập trung nghiên cứu chủ yếu về cácphương pháp tự động trong giai đoạn thiết kế kiểm thử theo quy trình pháttriển phần mềm Mục tiêu của luận án nhằm nghiên cứu, cải tiến, đề xuất vàtriển khai một số phương pháp sinh tự động các dữ liệu kiểm thử từ các biểu đồUML trong giai đoạn thiết kế kiểm thử để giải quyết bài toán trên Tuy nhiên,

để đo tính hiệu quả, khả năng tìm lỗi của các dữ liệu kiểm thử sinh ra thì mộtvài tiêu chuẩn bao phủ và độ đo phù hợp với mục đích so sánh các dữ liệu kiểmthử được sinh ra với các phương pháp hiện tại Theo đó, luận án thực hiện cácnội dung cụ thể như sau:

ˆ Tổng hợp, hệ thống hóa các nghiên cứu liên quan và bài toán tổng quan vềcác vấn đề sinh dữ liệu kiểm thử tự động, kiểm thử từ các biểu đồ UML

ˆ Nghiên cứu bài toán sinh dữ liệu kiểm thử tự động từ biểu đồ tuần tự UML

và biểu đồ lớp với việc giải quyết các toán tử, các đặc trưng của biểu đồUML đó Nghiên cứu các phương pháp trong giai đoạn thiết kế kiểm thử

để các kịch bản kiểm thử được sinh ra đạt được số lượng nhỏ nhất và độbao phủ cao nhất, tránh bùng nổ số lượng kịch bản kiểm thử và xem xétcác trường hợp có hoặc không có sự chia sẻ dữ liệu trong các luồng songsong của biểu đồ tuần tự

ˆ Nghiên cứu trong các hệ các ràng buộc từ các biểu đồ UML, xét phươngpháp sinh và thực thi dữ liệu kiểm thử với biến có kiểu dữ liệu số, cấu trúc

dữ liệu động, các ràng buộc chuỗi và kiểm thử với vòng lặp

ˆ Thực nghiệm, triển khai trong các phương pháp cải tiến, đề xuất với cácbiểu đồ tuần tự và các biểu đồ lớp Xem xét áp dụng về các tiêu chuẩn baophủ khác nhau phù hợp với từng loại biểu đồ UML và đo khả năng tìm lỗicủa các dữ liệu kiểm thử được sinh ra

mô hình hóa Các biӇu ÿӗ UML

thӱ, ca kiӇm thӱ

Sҧn phҭm cҫn kiӇm thӱ

Báo cáo kiӇm thӱ

Lҩy kӃt quҧ kiӇm thӱ

Bӝ sinh ÿҫu ra mong muӕn

Giҧi quyӃt vӟi các kiӇu dӳ liӋu sӕ,

có cҩu trúc ÿӝng, các ràng buӝc chuӛi và kiӇm thӱ vòng lһp

Giҧm sӕ lѭӧng và tăng ÿӝ bao phӫ cӫa kӏch bҧn kiӇm thӱ, Tránh bùng nә sӕ lѭӧng trong các luӗng song song, khóa chӃt, ÿӗng bӝ

Hình 1.1: Các nội dung luận án giải quyết trong bài toán kiểm thử dựa trên mô hình.

Các nội dung mà luận án đưa ra trên tập trung giải quyết một số phương phápsinh tự động các kịch bản kiểm thử và sinh dữ liệu kiểm thử Trong Hình 1.1

mô tả quy trình của bài toán kiểm thử dựa trên mô hình, các vấn đề luận ántập trung giải quyết là các hình chữ nhật góc tròn nét đứt Các vấn đề trongcác hướng nghiên cứu đưa ra phương pháp giải quyết các toán tử của biểu đồUML 2.0 chuyển thành một biểu diễn trung gian là đầu vào cho việc sinh cáckịch bản kiểm thử Phương pháp sinh các kịch bản kiểm thử để tránh bùng nổ

số lượng kịch bản và tăng độ bao phủ của chúng, có mối liên hệ với các phươngpháp giải quyết ràng buộc để sinh dữ liệu kiểm thử trong từng kịch bản trên

Các nghiên cứu đó góp phần giải quyết hoàn chỉnh bài toán trong giai đoạn thiết

kế kiểm thử từ các biểu đồ UML

Phần còn lại của luận án được cấu trúc thành năm chương chính Trong

đó, Chương 2 giới thiệu kiến thức nền tảng về các vấn đề nghiên cứu trong luận

án Đây là cơ sở lý thuyết cho việc xây dựng các phương pháp sinh tự động dữliệu kiểm thử từ các biểu đồ UML trong các chương từ Chương 3 đến Chương 5.Theo cách tiếp cận của việc sinh tự động dữ liệu kiểm thử từ các biểu đồ tuần

tự UML và biểu đồ lớp, tác giả tập trung đưa ra đánh giá phân tích các hướngnghiên cứu liên quan; nêu ra một số vấn đề còn tồn tại mà luận án sẽ tập trunggiải quyết Cụ thể, Chương 3 trình bày nội dung kết quả nghiên cứu về phươngpháp sinh tự động dữ liệu kiểm thử giải quyết cho tất cả mười hai toán tử trongbiểu đồ tuần tự UML 2.0 và kiểu dữ liệu số và cấu trúc động Tiếp theo, phươngpháp đề xuất cho việc sinh tự động dữ liệu kiểm thử với trường hợp kiểm thửvòng lặp và các ứng dụng tương tranh được đưa ra trong Chương 4 nhằm giảiquyết vấn đề bùng nổ số kịch bản kiểm thử sinh ra, trường hợp khóa chết vàđồng bộ Chương 5 trình bày nội dung kết quả nghiên cứu về phương pháp sinh

tự động dữ liệu kiểm thử với việc cải tiến khi giải với các ràng buộc chuỗi Cuốicùng, tổng kết lại các kết quả đạt được và hướng phát triển tiếp theo của luận

án, được trình bày trong Chương 6

Chương 2

KIẾN THỨC NỀN TẢNG

Chương này trình bày kiến thức nền tảng về các vấn đề nghiên cứu trongluận án, bao gồm: đưa ra các cơ sở lý thuyết chính về sinh dữ liệu kiểm thử, cácbiểu đồ UML và ràng buộc OCL, các hướng tiếp cận chính của kiểm thử dựatrên mô hình, các biểu đồ UML và OCL Tiếp theo, đưa ra tổng quan về sinh

dữ liệu kiểm thử tự động, từ các biểu đồ UML và các công cụ sinh dữ liệu kiểmthử hiện tại Cuối chương, tác giả nêu ra một số vấn đề còn tồn tại mà luận án

sẽ tập trung giải quyết

Kiểm thử phần mềm là quá trình kiểm tra đảm bảo sản phẩm phần mềmthực hiện đúng để thỏa mãn các yêu cầu của khách hàng Mục đích của kiểmthử nhằm đánh giá chất lượng hoặc tính chấp nhận được của sản phẩm Kiểmthử cũng nhằm phát hiện lỗi hoặc bất cứ vấn đề gì về sản phẩm Các khái niệm

cơ bản sau được sử dụng trong phạm vi của luận án

ˆ Ca kiểm thử (Test case) [1, 15]: gồm một tập các dữ liệu đầu vào, các bướcthực hiện và các giá trị đầu ra mong đợi đối với phần mềm Mỗi ca kiểmthử được liên kết với một hành vi trong một chức năng của hệ thống Vớitừng ca kiểm thử cụ thể, kết quả mong đợi được so sánh với kết quả thực

tế của các kịch bản khi thực thi phần mềm

ˆ Dữ liệu kiểm thử (Test data) [46, 15]: là tập các giá trị thực (thỏa mãntiêu chuẩn bao phủ dữ liệu đã chọn) được xác định chỉ rõ là đầu vào đểthực hiện các ca kiểm thử trong quá trình kiểm thử

ˆ Tiêu chuẩn bao phủ dữ liệu kiểm thử (Test data coverage criteria) [107,

100]: là một tập các quy tắc được sử dụng để xác định việc chọn các giátrị dữ liệu kiểm thử Tiêu chuẩn này xác định độ phủ trong không gian dữliệu đầu vào của chương trình hoặc mô hình Tiêu chuẩn bao phủ dữ liệuhữu ích trong trường hợp một tập miền xác định của dữ liệu đầu vào làlớn và đưa ra việc chọn các giá trị dữ liệu tốt cho kiểm thử.

ˆ Kịch bản kiểm thử (Test scenario) [1, 15]: là khái niệm ở mức cao nhữngcái cần kiểm thử, và thường bao gồm nhiều ca kiểm thử liên quan nhau.Mục đích của kịch bản kiểm thử là kiểm tra việc thực hiện chức năng từđầu đến cuối của một chức năng phần mềm và đảm bảo luồng logic đanghoạt động là đúng Khi các kịch bản kiểm thử xác định, các trường hợpkiểm thử được viết cho từng kịch bản với từng bộ dữ liệu đầu vào khácnhau Các ca kiểm thử là các trường hợp miêu tả chi tiết ở mức thấp vềcác kịch bản kiểm thử

ˆ Tiêu chuẩn bao phủ (Coverage criteria) [78, 100]: là một tập các quy tắchoặc yêu cầu mà các bộ kiểm thử cần phải thoả mãn Mục đích để đánhgiá mức độ hiệu quả của các ca kiểm thử, đo phần trăm độ bao phủ củađặc tả hoặc chương trình của các ca kiểm thử so với yêu cầu phần mềm(ví dụ: bao phủ dòng lệnh, bao phủ nhánh, v.v.), thông qua kiểm thử đểloại trừ sai sót và tăng chất lượng phần mềm

Có nhiều khái niệm khác nhau về kiểm thử dựa trên mô hình Trong nghiêncứu [4, 100], kiểm thử dựa trên mô hình là một phương pháp kiểm thử mà các

ca kiểm thử được sinh ra từ mô hình, đặc tả hành vi của hệ thống được kiểmthử (System Under Testing – SUT) Mô hình này được biểu diễn bằng máy hữuhạn trạng thái, ôtômát, đặc tả đại số, các biểu đồ UML, v.v Kiểm thử dựa trên

mô hình tự động hóa các thiết kế chi tiết của ca kiểm thử Cụ thể hơn, thay thếviệc thiết kế hàng trăm ca kiểm thử thủ công thì người thiết kế kiểm thử xâydựng mô hình trừu tượng của SUT, sau đó công cụ kiểm thử dựa trên mô hìnhsinh ra một tập các ca kiểm thử từ mô hình đó Toàn bộ thời gian thiết kế kiểmthử được giảm xuống, và ưu điểm là có thể phát sinh các tập các ca kiểm thử

khác nhau từ cùng một mô hình bằng việc sử dụng các tiêu chuẩn bao phủ khácnhau Quá trình kiểm thử có thể chia thành năm bước chính như sau:

ˆ Bước 1: Mô hình hóa hệ thống kiểm thử

ˆ Bước2: Sinh các trừu tượng kiểm thử (abstract tests) từ mô hình của SUT

ˆ Bước 3: Cụ thể hóa các trừu tượng kiểm thử để tạo ra các đoạn mã kiểmthử có thể thực thi

ˆ Bước 4: Thực thi các đoạn mã kiểm thử trên SUT

ˆ Bước 5: Phân tích kết quả, so sánh kết quả thực tế với kết quả mong đợi

Hình 2.1: Quy trình kiểm thử dựa trên mô hình [100].

Hình 2.1 chỉ quy trình kiểm thử dựa trên mô hình Bước đầu tiên của kiểmthử dựa trên mô hình là xây dựng hay mô hình hoá của SUT Mô hình này tậptrung vào các khía cạnh của hệ thống mà chúng ta muốn kiểm thử Sau khi xâydựng mô hình, chúng ta có thể sử dụng công cụ để kiểm tra tính nhất quán vàcác hành vi mong muốn trên mô hình

Bước thứ hai của kiểm thử dựa trên mô hình là sinh các trừu tượng kiểmthử từ mô hình [79] Chúng ta phải chọn các tiêu chuẩn bao phủ để sinh các

ca kiểm thử theo các tiêu chuẩn bao phủ này vì số lượng các ca kiểm thử cóthể sinh ra luôn là không giới hạn Phần lớn các công cụ kiểm thử dựa trên môhình tạo ra một ma trận tìm dấu vết các yêu cầu phần mềm hoặc các kết quảbao phủ khác nhau như đầu ra của bước này Ma trận dấu vết yêu cầu [100] làquan hệ giữa các yêu cầu chức năng và các ca kiểm thử được tạo ra Đó có thể

là quan hệ nhiều – nhiều: một yêu cầu có thể được bao phủ bởi nhiều ca kiểmthử, và các ca kiểm thử đơn có thể được tao ra từ nhiều yêu cầu phần mềm Cáckết quả bao phủ cho chúng ta biết việc xác định các tập ca kiểm thử được sinh

ra so với các hành vi của mô hình Chúng ta có thể sử dụng các kết quả baophủ tĩnh đơn giản về chất lượng của các tập kiểm thử được sinh ra Việc này cóthể hữu ích để sử dụng công cụ tự động cho việc kiểm tra các hành vi của cácđường dẫn kiểm thử trong mô hình và đưa ra kết quả trong việc sinh các kiểmthử là đầy đủ hay không

Kiểm thử dựa trên mô hình trong bước thứ ba là việc chuyển đổi các trừutượng kiểm thử vào các kiểm thử cụ thể để có thể thực thi được Điều này đượcthực hiện bởi một công cụ chuyển đổi, sử dụng các mẫu khác nhau và chuyểnđổi các ca kiểm thử thành các đoạn mã kiểm thử Mục đích của bước này làcầu nối giữa các ca kiểm thử và hệ thống kiểm thử cụ thể bằng việc thêm cácchi tiết của hệ thống cần kiểm thử ở mức thấp Thuận lợi của hướng tiếp cậnnày là các ca kiểm thử có thể khá độc lập với ngôn ngữ được sử dụng để viếtkiểm thử và môi trường kiểm thử Nhóm nghiên cứu trong [13] chuyển đổi cáctrừu tượng kiểm thử được sinh ra từ công cụ sinh kiểm thử LEIRIOS, sau đócác trừu tượng đó sang mã kiểm thử bằng Java để có thể thực thi tự động.Bước thứ tư để thực thi các mã kiểm thử trong SUT Với kiểm thử trựctuyến, các kiểm thử sẽ được thực thi như các thủ tục, vì vậy công cụ kiểm thửdựa trên mô hình sẽ quản lý tiến trình kiểm thử thực thi trên hệ thống thực vàghi lại kết quả Với kiểm thử không trực tuyến, một tập các đoạn mã kiểm thử

có thể viết bằng một vài ngôn ngữ, vì vậy chúng có thể được sử dụng trong cáccông cụ kiểm thử thực thi các đoạn mã kiểm thử và đưa ra kết quả Các nhómtác giả trong [35, 71] miêu tả về thực thi kiểm thử tự động, các thực thi kiểmthử được sinh ra theo hướng tiếp cận kiểm thử dựa trên mô hình

Bước thứ năm là phân tích kết quả của thực thi kiểm thử Trong các kiểmthử mà kết quả thông báo bị lỗi, chúng ta phải xác định lỗi và nguyên nhângây ra lỗi Điều này tương tự như tiến trình phân tích kiểm thử truyền thống.Việc thiết kế các ca kiểm thử được dựa trên các loại hành vi mong đợi, nhưngvới việc thiết kế ca kiểm thử thủ công thì mô hình này chỉ hướng là những môhình phi hình thức Bằng việc tạo ra các mô hình hình thức rõ ràng nên có thể

sử dụng công cụ kiểm thử dựa trên mô hình để sinh các ca kiểm thử tự động

đạt được các độ bao phủ khác nhau Do vậy, việc sử dụng những thay đổi nàylàm tăng lên cả về số lượng và chất lượng của các bộ kiểm thử Như vậy, việc

sử dụng quy trình kiểm thử dựa trên mô hình có thể tự động một phần hoặctoàn bộ giúp giảm bớt công sức trong giai đoạn kiểm thử, tăng lên về số lượngcủa các ca kiểm thử sinh ra và nâng cao chất lượng phần mềm Trong thực tiễn,các kiểm thử viên thường thực hiện công việc của mình bằng các phương pháptruyền thống (thủ công) nên thời gian và chi phí dành cho các hoạt động nàythường rất cao Kiểm thử dựa trên mô hình là một giải pháp hiệu quả nhằmgóp phần giải quyết vấn đề này Sau đây là tóm tắt những ưu điểm của kiểmthử dựa trên mô hình:

ˆ Khả năng dò tìm lỗi: mục đích chính của quá trình kiểm thử là tìm lỗitrong các hệ thống phần mềm Trong thực tiễn áp dụng của các công tyIBM và BMW thì kiểm thử dựa trên mô hình luôn luôn dò tìm lỗi lớn hơnhoặc bằng số lượng lỗi tìm được so với tiến trình thủ công [32] Trong ứngdụng của Microsoft, số lượng các lỗi dò tìm được của kiểm thử dựa trên môhình gấp mười lần [92, 103] Khả năng dò tìm lỗi vẫn phụ thuộc vào kinhnghiệm, kỹ năng của người kiểm thử viên trong khi xây dựng mô hình vàchọn các tiêu chuẩn bao phủ kiểm thử khi sinh các ca kiểm thử

ˆ Giảm chi phí và thời gian: do quá trình kiểm thử hầu hết được thực hiện

tự động nên tính hiệu quả của phương pháp này cao trong khi thời gianđược giảm một cách tối thiểu

ˆ Độ bao phủ tốt hơn: nếu mô hình của hệ thống được xây dựng tốt thì quátrình kiểm thử dựa trên mô hình sinh ra nhiều ca kiểm thử và phát hiệnnhiều lỗi Kiểm thử mô hình cũng cho phép giảm các lỗi chủ quan do ngườikiểm thử sinh ra trong quá trình kiểm thử sản phẩm

ˆ Đầy đủ tài liệu: mô hình hệ thống, các đường đi, các ca kiểm thử, v.v làcác tài liệu quan trọng trong quá trình phát triển phần mềm nói chung vàquá trình kiểm thử phần mềm nói riêng Các tài liệu này cũng giúp chocác kiểm thử viên hiểu hơn về các ca kiểm thử và các kịch bản kiểm thử

ˆ Tự động tạo và kiểm tra tránh các ca kiểm thử trùng nhau hoặc khônghữu hiệu; có khả năng đánh giá chất lượng phần mềm

ˆ Khả năng sử dụng lại cao: mỗi khi phần mềm tiến hóa thì việc sinh thêmcác ca kiểm thử và kiểm thử lại một cách nhanh chóng, dễ dàng và hiệuquả hơn.

ˆ Hiểu hơn về hệ thống: kiểm thử dựa trên mô hình giúp người phát triểnhiểu hơn về SUT thông qua việc xây dựng và phân tích mô hình hệ thống.Sớm phát hiện lỗi và sự không rõ ràng trong đặc điểm kỹ thuật và thiết

kế, vì vậy sẽ tăng thời gian giải quyết vấn đề trong kiểm thử

Tuy nhiên, kiểm thử dựa trên mô hình có một số khó khăn khi áp dụngtrong thực tế Thứ nhất, khó xây dựng mô hình chính xác: kiểm thử dựa trên

mô hình cần có mô hình đặc tả chính xác hành vi của hệ thống Trong thực tế,việc xây dựng mô hình là rất khó và tiềm ẩn nhiều lỗi Thứ hai là yêu cầu cao

về kiểm thử viên: phải xây dựng mô hình của hệ thống, vì vậy người kiểm thửphần mềm phải yêu cầu là những người có khả năng phân tích và thiết kế hệthống Hơn nữa, người kiểm thử cần có kiến thức tốt về các phương pháp hìnhthức và đặc tả hình thức, có hiểu biết chi tiết và chính xác về hệ thống Cuốicùng, khó khăn nhất đối với kiểm thử dựa trên mô hình là tạo ra các giá trị đầu

ra mong đợi cho các ca kiểm thử

2.3.1 Biểu đồ tuần tự UML và các toán tử

Biểu đồ tuần tự UML [76]: biểu diễn mối quan hệ giữa các đối tượng, giữacác đối tượng và tác nhân theo thứ tự thời gian Biểu đồ tuần tự nhấn mạnhthứ tự thực hiện của các tương tác Các thành phần cơ bản của một biểu đồtuần tự là:

ˆ Các đối tượng (object): được biểu diễn bởi các hình chữ nhật, bên trong

là tên của đối tượng Trong biểu đồ tuần tự, không phải các đối tượng đềuxuất hiện ở trên cùng của biểu đồ mà chúng chỉ xuất hiện (về mặt thờigian) khi thực sự tham gia vào tương tác

ˆ Các thông điệp (message): được biểu diễn bằng các mũi tên hướng từ đốitượng gửi sang đối tượng nhận Tên các thông điệp có thể biểu diễn dưới

dạng phi hình thức (như các thông tin trong kịch bản) hoặc dưới dạnghình thức (giống như các phương thức) Biểu đồ tuần tự cho phép có cácthông điệp từ một đối tượng tới chính bản thân nó Trong biểu đồ này cónhiều loại thông điệp khác nhau tuỳ theo mục đích sử dụng và tác độngcủa thông điệp đến đối tượng.

ˆ Đường sống (lifeline): mỗi đối tượng có một vòng đời (bắt đầu từ khi hìnhthành đối tượng và kết thúc khi phá hủy), đường sống biểu diễn một đường

kẻ nối dài phía dưới đối tượng, mô tả quá trình của một đối tượng trongtương tác thuộc biểu đồ

Sau đây là danh sách các toán tử tương tác [76] trong các biểu đồ tuần tựUML 2.0:

Toán tử alternative (alt): toán tử tương tác alt chỉ ra rằng phân đoạn kếthợp biểu diễn một sự lựa chọn hành vi Toán hạng trong toán tử có biểu thứcđiều kiện (guard expression), nếu biểu thức đó đúng thì toán hạng đầu sẽ đượcthực thi Nếu toán hạng không có biểu thức điều kiện thì biểu thức được ngầmhiểu là đúng Nếu biểu thức điều kiện là sai thì toán hạng sau sẽ được thực thi.Hình 2.2 biểu diễn ví dụ minh họa của toán tử alt: nếu số dư (balance) trongtài khoản lớn hơn 0 thì cho phép thực hiện rút tiền (withdraw()), ngược lại thì

từ chối (reject())

Toán tử tương tác option (opt): chỉ ra rằng phân đoạn kết hợp biểu diễnmột sự lựa chọn hành vi Trong phân đoạn chỉ có một toán hạng, toán hạngnày có thể được thực thi hoặc không được thực thi tùy vào biểu thức điều kiện.Toán tử opt gần giống với toán tử alt, chỉ có điều trong opt chỉ có một toánhạng duy nhất Hình 2.2 biểu diễn ví dụ minh họa của toán tử opt: đăng bìnhluận (post_comments()) nếu không có lỗi xảy ra (no errors)

Toán tử tương tác loop: chỉ ra rằng phân đoạn kết hợp biểu diễn vòng lặp.Toán hạng lặp sẽ được lặp đi lặp lại một số lần Điều kiện trong toán tử có thểgồm một cận dưới (minint), một cận trên (maxint) và một biểu thức boolean.Sau minint lần lặp, biểu thức được kiểm tra đến khi nào biểu thức còn đúng và

số lần lặp còn nhỏ hơn hoặc bằng maxint thì vòng lặp vẫn tiếp tục Hình 2.3biểu diễn ví dụ minh họa của toán tử loop: vòng lặp với cận dưới là 4, cận trên

là 9 Sau khi lặp hết 4 lần, nếu điều kiện size < 0 đúng và số vòng lặp nhỏ hơn

Hình 2.3: Ví dụ biểu đồ tuần tự UML có toán tử loop và break.

hoặc bằng 9 thì vòng lặp vẫn tiếp tục, ngược lại thì dừng lặp

Toán tử break: khi biểu thức điều kiện của toán tử tương tác break đúngthì toán hạng trong phân đoạn kết hợp break sẽ được thực thi thay cho phầncòn lại của toán tử tương tác bao gói bên ngoài Hình 2.3 biểu diễn ví dụ minhhọa của toán tử break: nếu điều kiện x > 0 thì thực hiện save() rồi thoát luônkhỏi vòng lặp

Toán tử parallel (par): chỉ ra rằng các toán hạng trong phân đoạn kết hợp

có thể được thực thi song song với nhau Các sự kiện trong các toán hạng khácnhau có thể đan xen vào nhau theo bất cứ cách nào, miễn là thứ tự của các sựkiện trong mỗi toán hạng được bảo toàn Hình 2.4 biểu diễn ví dụ minh họa củatoán tử par: thứ tự thực hiện các thông điệp chỉ cần thỏa mãn 1a trước 2 và 1btrước 3, vì vậy có các thứ tự thực hiện sau: 1a 2 1b 3; 1a 1b 2 3; 1b 1a 3 2; 1b1a 2 3; 1b 3 1a 2

Toán tử weak sequence (seq): chỉ ra rằng phân đoạn kết hợp biểu diễn mộttrình tự yếu giữa các hành vi của các toán hạng Trình tự yếu được định nghĩabởi tập các vết với các đặc tính: Thứ tự của các sự kiện trong mỗi một toán

Hình 2.4: Ví dụ biểu đồ tuần tự UML có toán tử par và seq.

hạng được duy trì; Các sự kiện trên các lifeline khác nhau ở các toán hạng khácnhau có thể xảy ra theo thứ tự bất kỳ; Các sự kiện trên cùng lifeline ở các toánhạng khác nhau được sắp thứ tự sao cho một sự kiện của toán hạng thứ nhấtxảy ra trước sự kiện của toán hạng thứ hai Hình 2.4 biểu diễn minh họa củatoán tử seq: tìm kiếm trên Google (searchGoogle()) song song với tìm kiếm trênBring (searchBring()) và Yahoo (searchYahoo()) Tuy nhiên, searchBring() vàsearchYahoo() cùng một lifeline nên tìm kiếm Bring luôn phải trước Yahoo.Toán tử strict: chỉ ra rằng phân đoạn kết hợp biểu diễn một trình tự nghiêmngặt giữa các hành vi của các toán hạng Hình 2.5 biểu diễn ví dụ minh họa củatoán tử strict: thực hiện theo đúng trình tự là tìm kiếm bằng Google, rồi tìmkiếm Bring, sau đó là Yahoo

Toán tử critical (critical region): chỉ ra phân đoạn kết hợp biểu diễn mộtvùng then chốt Một vùng then chốt nghĩa là các vết trong vùng này không thể

bị đan xen bởi các sự kiện khác (trên các lifeline bị phủ bởi vùng này) Hình 2.5biểu diễn ví dụ minh họa của toán tử critical: các cuộc gọi cho 911 phải nối tiếp,không được chồng lấn nhau, tuy nhiên các cuộc gọi thường (100) thì đan xennhau thoải mái Điều hành viên (operator) phải chuyển tiếp cuộc gọi cho số 911trước khi làm bất cứ thứ gì khác

Toán tử ignore: chỉ ra rằng có một số kiểu thông điệp không được hiển thịtrong phân đoạn kết hợp này Các kiểu thông điệp này có thể bị coi là vô nghĩa

và bị mặc nhiên bỏ qua Hình 2.6 biểu diễn ví dụ minh họa của toán tử ignore:

bỏ qua thông điệp get() và set() nếu có trong các toán hạng

Toán tử consider: chỉ ra những thông điệp được thực hiện trong phân đoạnkết hợp này, và các thông điệp còn lại khác bị bỏ qua Hình 2.6 biểu diễn ví dụminh họa của toán tử consider: chỉ thực hiện các thông điệp add() và remove(),

bỏ qua các thông điệp khác

caller

critical

2: call (100)

3: call (911) 4: call (911)

Hình 2.5: Ví dụ biểu đồ tuần tự UML có toán tử strict và critical.

Hình 2.6: Ví dụ biểu đồ tuần tự UML có toán tử ignore và consider.

Toán tử negative (neg): chỉ ra rằng phân đoạn kết hợp biểu diễn các vết(traces) được định nghĩa là không hợp lệ Hình 2.7 biểu diễn ví dụ minh họa củatoán tử neg: toán tử neg để xác định rằng không được phép mở cửa lò vi sóng(open()) trong khi đang nấu

Toán tử assert: chỉ ra rằng phân đoạn kết hợp biểu diễn các vết hợp lệ.Toán tử assert thường được sử dụng cùng với ignore hoặc consider Hình 2.7biểu diễn ví dụ minh họa của toán tử assert: toán tử assert chỉ chấp nhận thôngđiệp set() là hợp lệ, nếu thông điệp remove() xảy ra thay cho set() thì remove()không hợp lệ

Hình 2.7: Ví dụ biểu đồ tuần tự UML có toán tử negative và assert.

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àythườ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àngbuộ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áicủa hệ thống Người thiết kế các biểu đồ UML sử dụng OCL để đặc tả các ràngbuộc mà nhiều khi không thể biểu diễn được trong các biểu đồ UML Trong cácbiể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ìnhlớ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 trongbiể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ểuthứ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 > 50context Person inv:

self.age > 18Các tiền và hậu điều kiện như sau:

context Person::income(d : Date) : Integer

post: result = 5000

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

wife husband

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ựctiế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ấutrú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), decisionnode (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ễnbiể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 toánhạng trong các toán tử (ví dụ: toán tử alt, opt, loop, v.v.); Một MN biểu diễn

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 toán tử lựa chọn (ví dụ alt, opt); Một FN biểu diễn đầu vàotrong 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áccạ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útkhở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 baogồ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ỗithô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ố

p i của phương thức m i trong biểu đồ tuần tự có thể bao gồm thuộc tínhvới các ràng buộc trong biểu đồ lớp Tham số và giá trị trả về được lấykiể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ặcthuộ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 = {oE 1 , 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.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ểmthử Việc sinh ra tất cả các đường dẫn kiểm thử là không thể cũng như khôngthể 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ựckiểm thử có giới hạn Vì vậy, các tiêu chuẩn bao phủ được đưa ra Trong tínhchấ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êuchuẩ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ộttuần tự khả thi của các tiến trình song song với không có sự đan xen giữacá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ácthô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ếntrì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 songsong, 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ểmthử 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ểmthử sinh ra từ đồ thị dòng điều khiển không thể chứa hết các vòng lặp Trongthự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 cakiể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ácvò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ỉ đượcthự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 trongvò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 0 lần

để 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ácvò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ònglặ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 ngoài (mỗi vòng lặp cũng dùngbảy ca kiểm thử như trên) Như vậy, với các trường hợp tương ứng thì trongPhầ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ỗikhi 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 cakiể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ìnhbở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 toá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 độtbiế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ínhxá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

N m − N e

(2.1)

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 hoàn toàn giống chương trình gốc và cho ra kết quả giống với chươngtrì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 toán tử này được xác địnhbở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 đilặ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ànhcá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ếtquả đúng thì thực hiện bước tiếp theo Trong trường hợp ngược lại thì phảichỉ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ườnghợ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, hoànthà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ốngsó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ảnkiểm thử và đánh giá phương pháp sinh các ca kiểm thử được đề xuất

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ệukiể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áttriể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áctrường hợp cơ bản để hướng tới việc sinh tự động dữ liệu kiểm thử là phươngthức hiệu quả mang tính hệ thống Mục đích của phần này là cung cấp cácphương pháp tiếp cận chung cho việc sinh tự động dữ liệu kiểm thử và nhữngkhó khăn tồn tại, khả năng ứng dụng vào quy trình kiểm thử trong thực tế.

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ệukiể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ácphươ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ươngphá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áctiêu chuẩn khác nhau để sinh ra dữ liệu kiểm thử Cách tiếp cận động thực thitrự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àkiểm tra tĩnh của hệ thống chẳng hạn như các tài liệu yêu cầu, các biểu đồ thiết

kế và mã nguồn phần mềm, có thể thực hiện thủ công hoặc tự động, thực tếkhông chạy phần mềm Một trong những nghiên cứu sớm nhất để tự động hóaviệc tạo ra dữ liệu kiểm thử là phương pháp thực thi tượng trưng của tác giảClarke [19] Phương pháp này tập trung vào việc thực thi các tượng trưng đểsinh dữ liệu kiểm thử dựa trên cấu trúc Hệ thống thực thi tượng trưng thực hiệnbằng cách duyệt các đường dẫn đưa ra trong CFG và xây dựng biểu diễn cáctượng trưng của các biến đầu vào Các nhánh trong chương trình được đưa rabởi các ràng buộc của các biến Đây là giải pháp cho các ràng buộc này đại diệncho dữ liệu kiểm thử trên đường dẫn đưa ra Nhóm tác giả đưa ra phương pháp

đó thực thi các tượng trưng của đường dẫn trong chương trình ANSI Fortran

để sinh ra một tập các ràng buộc Giải pháp giải cho các ràng buộc tuyến tính

để sinh dữ liệu đầu vào trên đường dẫn thực thi được chỉ rõ Tuy nhiên, phươngpháp có một số giới hạn sau: vấn đề bùng nổ đường dẫn được sinh ra hoặc với

hệ thống không bao gồm đường dẫn nào được chọn; vấn đề chỉ số của mảng phụthuộc vào dữ liệu đầu vào, bất kỳ giải pháp nào cho các ràng buộc đều gây raviệc thực thi của đường dẫn đó với điều kiện tương ứng

Casegen và các đồng sự trong [80] xây dựng dựa trên công việc của Clarkevới mục đích cải tiến quá trình xử lý với các mảng Cách tiếp cận không thựcthi tượng trưng của một mảng khi phụ thuộc dữ liệu đầu vào cho đến khi các

dữ liệu thỏa mãn các ràng buộc Giá trị cho các biến theo mảng được truy cậpphụ thuộc vào cách xác định đầu tiên Điều này cho phép truy cập mảng đượcxác định hoàn toàn Phương pháp yêu cầu tạo ra một tượng trưng mới thay thếcủa mảng, giống với trường hợp thay thế trước trừ phần tử được yêu cầu Do

đó, cách tiếp cận này yêu cầu một không gian bộ nhớ lớn để lưu trữ tất cả cácbiểu diễn tượng trưng của từng mảng

Coen–Porisini và các đồng sự trong [21] đưa ra giải quyết vấn đề với bộnhớ, phát triển từ kinh nghiệm của Casegen bằng cách gợi ý một cách tiếp cậngia tăng Điều này liên quan đến các ràng buộc của từng biến đến một tập cácgiá trị tượng trưng và những ràng buộc mà theo đó mỗi giá trị sẽ được giữ.Những bộ giá trị này được cập nhật từng bước nhằm giảm sự tăng trưởng quá

mức của cả hai không gian tính toán và thời gian thực hiện thuật toán trên Mặc

dù có những cải tiến, điểm yếu vẫn còn liên quan đến các con trỏ và vòng lặpkhông giới hạn với thực thi tượng trưng Việc kiểm thử phần mềm ở mức caohơn kiểm thử đơn vị cũng có thể thực hiện bằng phương pháp thực thi tượngtrưng nhưng khá tốn kém

DeMillo và các đồng sự trong [26, 74, 29], đã mở rộng ứng dụng thực thitượng trưng, nhằm mục tiêu giải quyết với những đột biến, như được yêu cầutrong kiểm thử đột biến Phương pháp này đưa ra quá trình kiểm thử dựa trênràng buộc Đây là một ràng buộc miêu tả điều kiện cần thiết để diệt các độtbiến trong một chương trình Tuy nhiên, điều này không thể đảm bảo chắc chắnrằng đột biến sẽ bị diệt (đây là một vấn đề khó giải quyết như trong nghiên cứu[74]) Sức mạnh của cách tiếp cận là nâng cao các định nghĩa của ràng buộc vị

từ Khi một biểu thức vị từ bị đột biến, các ràng buộc bổ sung được tạo ra.Chúng buộc kết quả của vị từ bột biến khác biệt so với vị từ gốc Ví dụ, nếubiến X trong vị từ ban đầu là X > 0, đột biến để đưa ra Y > 0, điều kiện cầnthiết là X 6= Y và vị từ ràng buộc sẽ là: (X > 0) 6= (Y > 0)

Một hướng tiếp cận nữa là các thủ tục tìm kiếm Việc giảm miền được sửdụng để tìm các giải pháp cho các đường điều kiện kết hợp, điều kiện cần thiết

và điều kiện vị từ xác định Giảm miền bằng cách sử dụng thông tin trong hệthống ràng buộc để giảm trực tiếp các miền của biến như sau:

i Các miền biến ban đầu xuất phát từ thông tin về loại dữ liệu của biến

ii Giảm một miền của biến sử dụng thông tin trong một ràng buộc Thôngtin này được truyền thông qua hệ thống ràng buộc

(a) Cho các ràng buộc của quan hệ x<C (trong đó, x là một biến và C làmột hằng), miền của biến x sẽ giảm và < là toán tử quan hệ

(b) Cho các ràng buộc của quan hệ x<y (trong đó, x và y là các biến), cácmiền của cả hai biến x và y đều giảm và < là toán tử quan hệ

iii Tiếp tục từ bước ii với từng biến lần lượt cho đến khi không thể giảm đượcthêm nữa

iv Chỉ định giá trị ngẫu nhiên cho biến với miền nhỏ nhất, đưa ra miền hiệuquả với từng phần tử riêng lẻ Điều này sau đó được thực hiện với tất cảcác ràng buộc hệ thống Tiếp tục từ bước ii