Download luận văn tóm tắt ngành công nghệ thông tin với đề tài: Phương pháp sinh dữ liệu kiểm thử tự động từ biểu đồ tuần tự UML, biểu đồ lớp và ràng buộc OCL, cho các bạn làm luận văn tham khảo

1. ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
NGUYỄN VĂN HÒA
PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG
TỪ BIỂU ĐỒ TUẦN TỰ UML, BIỂU ĐỒ LỚP
VÀ RÀNG BUỘC OCL
LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM
HÀ NỘI – 2016

2. ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
NGUYỄN VĂN HÒA
PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG
TỪ BIỂU ĐỒ TUẦN TỰ UML, BIỂU ĐỒ LỚP
VÀ RÀNG BUỘC OCL
Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60480103
LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM
CÁN BỘ HƯỚNG DẪN KHOA HỌC: PGS. TS. PHẠM NGỌC HÙNG
HÀ NỘI – 2016

3. VIETNAM NATIONAL UNIVERSITY, HANOI
UNIVERSITY OF ENGINEERING TECHNOLOGY
NGUYEN VAN HOA
A METHOD AND TOOL SUPPORTING FOR AUTOMATED
TESTING FROM UML SEQUENCE DIAGRAMS, CLASS
DIAGRAMS AND OCL CONSTRAINS
THE MS. THESIS INFORMATION TECHNOLOGY
Supervisor: Assoc. Prof., PHAM NGOC HUNG, PhD
HÀ NỘI – 2016

4. i
LỜI CẢM ƠN
Đầu tiên, tôi xin gửi lời cảm ơn chân thành và sâu sắc tới thầy Phạm Ngọc Hùng –
Người đã trực tiếp hướng dẫn nhiệt tình, giúp đỡ và động viên tôi rất nhiều, cho tôi có cơ
hội được tiếp xúc với các tài liệu tham khảo quý giá, góp ý cho tôi những lời khuyên chân
thành trong quá trình nghiên cứu để hoàn thành đề tài này.
Tiếp theo tôi xin gửi lời cảm ơn đến các thầy cô giảng viên Trường Đại học Công
Nghệ - Đại học Quốc Gia Hà Nội – những người đã tận tâm truyền đạt những kiến thức
quý báu làm nền tảng cho tôi suốt 2 năm học.
Cuối cùng, tôi xin gửi lời biết ơn sâu sắc tới gia đình vì đã luôn ở bên cạnh tôi,
mang lại cho tôi nguồn động viên tinh thần to lớn và tạo mọi điều kiện thuận lợi cho tôi
trong quá trình học tập và hoàn thành luận văn này.
Với luận văn này tôi rất mong nhận được ý kiến đóng góp từ Thầy, Cô giáo và các
bạn quan tâm để hoàn thiện và phát triển nhiều hơn về các phương pháp mới trong kiểm
thử phần mềm.
Xin trân trọng cảm ơn!
Hà Nội, ngày 10 tháng 10 năm 2016
Học viên
Nguyễn Văn Hòa

5. ii
TÓM TẮT
Luận văn này trình bày một phương pháp nghiên cứu tự động hóa quá trình kiểm
thử dự án phần mềm từ biểu đồ tuần tự UML 2.0. Hướng nghiên cứu dựa trên lý thuyết
kiểm thử dựa trên mô hình. Mục tiêu đề ra là tự động hóa quá trình kiểm thử, nâng cao
hiệu quả kiểm thử, tiết kiệm chi phí và thời gian phát triển dự án. Phương pháp được đề
xuất với nội dung chính như sau. Đầu vào là biểu đồ tuần tự UML 2.0 lưu giữ dưới dạng
tệp xmi. Chương trình kiểm thử biến đổi tệp xmi bằng cách bóc tách các thông điệp, toán
tử và các ràng buộc được đưa vào trong thiết kế, từ đó vẽ đồ thị dòng điều khiển tương
ứng. Từ đồ thị dòng điều khiển sử dụng thuật toán dò tìm, thuật toán sinh ca kiểm thử cho
các toán tử song song có các điểm chia sẻ dữ liệu tìm ra các đường đi từ điểm bắt đầu cho
tới điểm kết thúc gọi là các đường kiểm thử. Tập các đường kiểm thử được chia tương
ứng thành 3 cấp độ kiểm thử khác nhau. Các ràng buộc trên mỗi đường đi được thu thập
và giải lấy kết quả dựa trên công cụ SMT solver kết hợp phương pháp sinh ngẫu nhiên.
Kết quả thu được sau khi giải hệ chính là đầu vào cho các ca kiểm thử tương ứng. Cuối
cùng trích xuất ra tệp excel là các ca kiểm thử theo từng độ bao phủ dùng cho kiểm thử
thiết kế. Để kiểm nghiệm mức độ khả thi của phương pháp, một công cụ hỗ trợ đã được
cài đặt và thử nghiệm với một số ví dụ đơn giản nhằm minh chứng cho tính đúng đắn và
hiệu quả của phương pháp trên. Kết quả thực nghiệm cho thấy hiệu quả của các ca kiểm
thử cũng là khả quan để áp dụng cho các công ty phát triển phần mềm.
Từ khóa: Kiểm thử dựa trên mô hình, kiểm thử tự động, biểu đồ tuần tự, đồ thị
dòng điều khiển, kiểm thử luồng song song, kiểm thử có chia sẻ dữ liệu luồng song song.

6. iii
ABSTRACT
The content of this thesis is research and propose a method to generate a set of test
cases from the UML 2.0 Sequence diagrams. Based on model-based testing in order to
automate the testing process, increase effectiveness, reduce cost and time of testing. The
method follows the following steps. At first, in order to have the input model for testing,
it analyzes and divides the input diagram into fragments. These fragments can be
Sequential or nested based on their relationship. After that, it generates the corresponding
control flow graph for the input Sequence diagram. The final control flow graph is
analyzed to generate a set of testing paths. Symbolic Execution (SE) technique is used to
create reStrictions associated with that set of testing paths. Finally, the method uses SMT
solver to solve the set of reStrictions to find solution and then to generate a set of test
cases. A tool is also implemented and tested with some simple examples in order to show
the correctness and effectiveness of the method. The experimental results give us the
potential application of the tool in automation testing in companies.
Keywords: Model base testing, automated testing, Sequence diagram, control flow
testing, Parallel threading testing, threading testing with data shared.

7. iv
LỜI CAM ĐOAN
Tôi xin cam đoan rằng những nghiên cứu về sinh tự động bộ kiểm thử từ biểu đồ
tuần tự được trình bày trong luận văn này dưới sự hướng dẫn của thầy Phạm Ngọc Hùng
là của tôi. Những gì tôi viết ra không sao chép từ các tài liệu, không sử dụng các kết quả
của người khác mà không trích dẫn cụ thể.
Tôi xin cam đoan công cụ kiểm thử tự động tôi trình bày trong luận văn là do tôi tự
phát triển, không sao chép mã nguồn của người khác. Nếu sai tôi hoàn toàn chịu trách
nhiệm theo quy định của Trường Đại học Công Nghệ - Đại học Quốc Gia Hà Nội.
Hà nội, ngày 10 tháng 10 năm 2016
Học viên:
Nguyễn Văn Hòa

8. v
MỤC LỤC
LỜI CẢM ƠN........................................................................................................................i
TÓM TẮT ............................................................................................................................ii
ABSTRACT ........................................................................................................................iii
LỜI CAM ĐOAN................................................................................................................iv
MỤC LỤC............................................................................................................................v
DANH SÁCH BẢNG BIỂU ..............................................................................................vii
DANH SÁCH HÌNH VẼ...................................................................................................viii
BẢNG THUẬT NGỮ VIẾT TẮT ......................................................................................ix
Chương 1: GIỚI THIỆU.......................................................................................................1
Chương 2: CÁC KHÁI NIỆM VÀ TỔNG QUAN KIỂM THỬ DỰA TRÊN MÔ HÌNH .3
2.1 Quy trình chung của kiểm thử dựa trên mô hình......................................................3
2.2 Đồ thị dòng điều khiển .............................................................................................4
2.3 Các độ đo kiểm thử...................................................................................................5
Chương 3: PHƯƠNG PHÁP SINH ĐỒ THỊ DÒNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ TUẦN
TỰ.........................................................................................................................................7
3.1 Thuật toán biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển ............................7
3.1.1. Thuật toán sinh đồ thị dòng điều khiển ................................................................7
3.1.2. Đồ thị dòng điều khiển tương ứng với các phân đoạn .......................................13
3.2 Kỹ thuật sinh kịch bản kiểm thử.............................................................................21
3.2.1. Kịch bản kiểm thử cho các toán từ thông thường ..............................................21
3.2.2. Kịch bản kiểm thử cho các phân đoạn song song (Par, Seq) .............................26
3.3 Xây dựng hệ ràng buộc...........................................................................................28
3.4 Giải hệ sử dụng SMT-Solver..................................................................................29
Chương 4: CÔNG CỤ VÀ THỰC NGHIỆM ....................................................................31
4.1 Giới thiệu công cụ và môi trường thực nghiệm .....................................................31
4.2 Thực nghiệm...........................................................................................................33

9. vi
4.3 Ý nghĩa thực nghiệm ..............................................................................................37
Chương 5: KẾT LUẬN ................................................................................................39
TÀI LIỆU THAM KHẢO..................................................................................................41

10. vii
DANH SÁCH BẢNG BIỂU
ảng 2.1 Ca kiểm thử độ bao phủ yếu .................................................................................6
ảng 2.2 Ca kiểm thử độ bao phủ trung bình.......................................................................6
ảng 2.3 Ca kiểm thử độ bao phủ mạnh ..............................................................................6
ảng 3.1 Các khóa cơ bản và ý nghĩa trong tệp xmi............................................................7
ảng 3.2 Dữ liệu thu thập tương ứng theo các nốt được nối với nhau ..............................23
ảng 4.1 Môi trường thử nghiệm công cụ sinh ca kiểm thử từ thiết kế.............................32

11. viii
DANH SÁCH HÌNH VẼ
Hình 2.1 Qui trình kiểm thử dựa trên mô hình.....................................................................3
Hình 2.2 Đồ thị dòng điều khiển tương ứng của phân đoạn Par..........................................5
Hình 3.1 Đồ thị CFG tương ứng cho phân đoạn Alt. .........................................................15
Hình 3.2 Đồ thị CFG tương ứng cho phân đoạn Opt. ........................................................15
Hình 3.3 Đồ thị CFG tương ứng cho phân đoạn Loop.......................................................16
Hình 3.4 Đồ thị CFG tương ứng cho phân đoạn Break......................................................16
Hình 3.5 Đồ thị CFG tương ứng cho phân đoạn Par..........................................................16
Hình 3.6 Đồ thị CFG tương ứng cho phân đoạn Seq. ........................................................17
Hình 3.7 Đồ thị CFG tương ứng cho phân đoạn Ignore.....................................................18
Hình 3.8 Đồ thị CFG tương ứng cho phân đoạn Consider.................................................18
Hình 3.9 Đồ thị CFG tương ứng cho phân đoạn Neg.........................................................19
Hình 3.10 Đồ thị CFG tương ứng cho phân đoạn Assert...................................................20
Hình 3.11 Đồ thị CFG tương ứng cho phân đoạn Strict.....................................................20
Hình 3.12 Ví dụ cây đồ thị cần duyệt.................................................................................22
Hình 3.13 Đồ thị dòng điều khiển. .....................................................................................23
Hình 3.14 Ví dụ về ràng buộc OCL được khai báo trong thiết kế. ....................................29
Hình 3.15 Mô tả công cụ SMT Solver ...............................................................................30
Hình 4.1 Cấu trúc công cụ thực nghiệm.............................................................................31
Hình 4.2 Đầu vào của ví dụ 1.............................................................................................34
Hình 4.3 Đầu ra đồ thị CFG cho ví dụ 1. ...........................................................................35
Hình 4.4 Ca kiểm thử độ bao phủ yếu cho ví dụ 1.............................................................35
Hình 4.5 Ca kiểm thử độ bao phủ trung bình cho ví dụ 1..................................................36
Hình 4.6 Ca kiểm thử độ bao phủ mạnh cho ví dụ 1..........................................................36
Hình 4.7 Đường đi tương ứng của một ca kiểm thử độ bao phủ mạnh của ví dụ 1...........37

12. ix
BẢNG THUẬT NGỮ VIẾT TẮT
STT Từ viết tắt Tên đầy đủ Ý nghĩa
1 BN Block Node Nốt đơn
2 CFG Control Flow Graph Đồ thị dòng điều khiển
3 DC Decision Node Nốt quyết định
4 FN Fork Node Nốt rẽ nhánh
5 IDE
Integrated Development
Environment
Môi trường phát triển tích
hợp
6 JN Join Node Nốt nối
7 MN Merge Node Nốt sáp nhập
8 OCL Object Constraint Language
Ngôn ngữ ràng buộc trên
đối tượng
9 SUT Software Under Testing
Phần mềm đang được kiểm
thử
10 UML Unified Modeling Language
Ngôn ngữ mô hình hóa
thống nhất

13. 1
Chương 1: GIỚI THIỆU
Công nghệ phần mềm đang ngày càng phát triển và chi phối cuộc sống của con
người. Ngược lại, con người luôn không ngừng sáng tạo để tạo ra những công nghệ mới,
phần mềm và dịch vụ mới. Trong quá trình phát triển đó, cần phải có một qui trình song
song để phát hiện và kiểm soát những sai lầm mà con người có thể vô tình hoặc cố tình
tạo ra, đó chính là kiểm thử. Theo ước tính, quá trình kiểm thử chiếm khoảng 50% thời
gian và 40% - 60% tổng chi phí trong toàn bộ quá trình phát triển phần mềm [1]. Quá
trình kiểm thử cũng quyết định sự thành công, mức độ đảm bảo của dự án phần mềm đặc
biệt là trong các lĩnh vực đòi hỏi độ chính xác cao như hàng không, quân sự, khoa học, vũ
trụ.. Vì vậy, để rút ngắn thời gian phát triển và nâng cao chất lượng dự án phần mềm, quá
trình sinh ca kiểm thử tự động và nâng cao chất lượng ca kiểm thử 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. Kiểm thử tự động đang được xem
là giải pháp chính nhằm giảm chi phí và thời gian mà vẫn đảm bảo chất lượng trong quá
trình phát triển phần mềm. Để giải quyết vấn đề này, nhiều công trình nghiên cứu đã được
đề xuất nhằm giải quyết, tối ưu và tự động hóa quá trình kiểm thử. Mỗi công trình nghiên
cứu mang lại một kết quả khác nhau và áp dụng cho từng mục đích kiểm thử khác nhau.
Một số nghiên cứu có thể kể đến như: phương pháp sinh ca kiểm thử tự động từ biểu đồ
tuần tự trong UML bởi A.V.K. Shanthi và G. Mohan Kumar [5]. Sinh dữ liệu kiểm thử tự
động từ biểu đồ tuần tự UML và ràng buộc OCL bởi Ashalatha Nayak và Debasis
Samanta [4]. Sinh ca kiểm thử từ biểu đồ tuần tự và hệ thống chuyển đổi được gắn nhãn
bởi Emanuela G. Cartaxo [7]. Sinh ca kiểm thử tự động từ biểu đồ tuần tự UML và ràng
buộc OCL bởi Li Bao-Lin, Li Zhi-shu, Li Qing và Chen Yan Hong [10], v.v. Trong đó
một số nghiên cứu mới chỉ dừng lại ở dạng đề xuất, nhiều nghiên cứu khác chưa giải
quyết trọn vẹn bài toán kiểm thử trực tiếp từ biểu đồ tuần tự từ một phần mềm cụ thể. Mỗi
phương pháp hướng tới một mục đích kiểm thử khác nhau. Để hiểu rõ hơn một vài nghiên
cứu trên sẽ được trình bày chi tiết hơn ở chương ba của luận văn.
Bài nghiên cứu này tôi sẽ trình bày một phương pháp khác sinh ca kiểm thử tự
động và cải tiến một công đoạn sinh ca kiểm thử tự động để nâng cao chất lượng kiểm
thử. Cũng như các phương pháp kiểm thử dựa trên mô hình khác, phương pháp này đòi
hỏi phải có các mô hình toán học đặc tả chính xác hành vi của hệ thống và có sẵn trong
thực tế. Các mô hình này thường được biểu diễn bằng các máy hữu hạn trạng thái đơn
định. Tuy nhiên, xây dựng mô hình cho các phần mềm là một công việc khó khăn và tiềm
ẩn nhiều lỗi đối với các công ty. Thay vào đó việc phân tích và thiết kế dựa trên các biểu
đồ tuần tự UML là một công việc dễ dàng và trở nên phổ biến hơn. Do đó việc kiểm thử
tính đúng đắn cho thiết kế dựa trên mô hình đang được nghiên cứu và áp dụng thực tế cho
kiểm thử dự án phần mềm. Không những tự động hóa được qui trình kiểm thử mà thời

14. 2
gian bắt đầu kiểm thử cũng được tiến hành sớm hơn giúp rút ngắn thời gian phát triển
phần mềm.
Giai đoạn kiểm thử thiết kế (kiểm thử dựa trên mô hình) chủ yếu tập trung vào các
ca kiểm thử được sinh ra từ các đường kiểm thử dựa trên đồ thị hoạt động và sinh ra dữ
liệu kiểm thử từ dữ liệu đầu vào là các bản thiết kế từ đặc tả chương trình. Với mục tiêu
kiểm thử phần mềm dựa trên thiết kế của biểu đồ tuần tự, mục tiêu nâng cao chất lượng
kiểm thử cũng như khả năng phát hiện lỗi của các kịch bản kiểm thử trong thiết kế và khi
chương trình được thực thi. Nội dung bài nghiên cứu này được trình bày trong 4 chương
và phần kết luận.
Chương 1 giới thiệu đề tài, lý do chọn đề tài, trình bày tổng quan nội dung nghiên
cứu và bố cục luận văn.
Chương 2 trình bày các khái niệm cơ bản phục vụ cho đề tài bao gồm các vấn đề
liên quan trong kiểm thử dựa trên mô hình, phương pháp đặc tả mô hình bằng máy trạng
thái UML. Các khái niệm về biểu đồ tuần tự và các phân đoạn trong thiết kế. Cuối cùng là
giới thiệu đồ thị dòng điều khiển và đề xuất ba độ đo kiểm thử áp dụng cho bài nghiên
cứu.
Chương 3 nghiên cứu đề xuất cách biến đổi từ biểu đồ tuần tự sang đồ thị dòng
điều khiển và các thuật toán biến đổi. Phương pháp sinh ca kiểm thử sau khi hoàn thành
độ thị dòng điều khiển trong đó chia ra 2 kịch bản kiểm thử. Một cho các phân đoạn thông
thường (các phân đoạn không chứa luồng song song) và một kịch bản kiểm thử cho các
phân đoạn chứa luồng song song (Par, Seq). Phần cuối chương 3 trình bày phương pháp
sinh dữ liệu kiểm thử từ đồ thị dòng điều khiển, một số nghiên cứu liên quan để thấy được
ưu nhược điểm của bài nghiên cứu so với các phương pháp khác.
Chương 4 giới thiệu công cụ thực nghiệm, các ví dụ thể hiện tính đúng đắn và khả
thi của phương pháp đề xuất. Kết quả thu được thực tế từ chương trình và rút ra ý nghĩa
của phương pháp đề xuất.
Cuối cùng là kết luận, định hướng mở rộng và tài liệu tham khảo.

15. 3
Chương 2: CÁC KHÁI NIỆM VÀ TỔNG QUAN KIỂM THỬ DỰA TRÊN MÔ
HÌNH
2.1 Quy trình chung của kiểm thử dựa trên mô hình
Mô hình UML được thiết kế từ các đặc tả yêu cầu của hệ thống. Mô hình có thể
được biểu diễn bằng các loại mô hình và biểu đồ khác nhau. Việc xây dựng mô hình còn
phải dựa trên các yếu tố dữ liệu đầu vào và đầu ra. Mô hình này được sử dụng để sinh đầu
vào cho các ca kiểm thử. Tiếp đến, chúng ta sẽ sinh giá trị đầu ra mong muốn ứng với mỗi
bộ đầu vào. Khi kết thúc bước này, chúng ta đã có các ca kiểm thử. Sau khi thực thi các
ca kiểm thử tương ứng theo từng giai đoạn hoặc phương pháp tiếp cận, kết quả thu được
sẽ được so sánh với kết quả mong đợi. Từ đó quyết định hành động tiếp theo như sửa đổi
mô hình hoặc dừng kiểm thử, v.v.
Các bản đặc tả yêu cầu
Mô
hình
Các chuỗi kiểm
thử
Kiểm thử dự
đoán
Kết luận: Pass /
Fail
Thực thi
Thiết kế
Tạo tự động
Điều khiển
Theo dõi
Phản hồi
Phản hồi
Phản hồi
Hình 2.1 Qui trình kiểm thử dựa trên mô hình.
Hình 2.1 mô tả về quy trình chung của kiểm thử tự động dựa trên mô hình [6].
Kiểm thử tự động dựa trên mô hình gồm các giai đoạn sau:
 Sinh mô hình dựa trên các yêu cầu và chức năng của hệ thống.
 Sinh các ca kiểm thử (bộ đầu vào và giá trị đầu ra mong đợi cho mỗi ca kiểm thử).
 Chạy các kịch bản kiểm thử để phát hiện các lỗi/khiếm khuyết của sản phẩm.
 So sánh kết quả đầu ra thực tế với kết quả đầu ra dự kiến.
 Quyết định hành động tiếp theo (sửa đổi mô hình, tạo thêm ca kiểm thử, dừng kiểm
thử, đánh giá chất lượng của phần mềm) [1].

16. 4
2.2 Đồ thị dòng điều khiển
Đồ thị dòng điều khiển (Control Flow Graph - CFG) là đồ thị được sinh ra từ biểu
đồ tuần tự bởi một thuật toán hồi qui, với các ràng buộc và thông số trong thiết kế biểu đồ
tuần tự thì sẽ được bóc tách, biến đổi để sinh dữ liệu kiểm thử. Đồ thị dòng điều khiển là
một đồ thị biểu diễn trực tiếp của biểu đồ tuần tự và được tạo nên từ bảy loại nốt nối với
nhau bởi các đường. Bảy loại nốt đó là [4]:
 Nốt bắt đầu (Start node): là nốt khởi đầu của đồ thị.
 Nốt đơn vị (BN – Block node): là nốt biểu thị cho một thông điệp hoặc một tuần
tự của của các thông điệp. Mỗi thông điệp m(i) bao gồm thông tin của lớp gửi và
lớp nhận và có cấu trúc ( m(i), ParameterList, returnValue ). Mỗi thông số của một
thông điệp có thể là một thuộc tính của ràng buộc OCL.
 Nốt quyết định (DC – Decision node): là nốt biểu thị cho một hàm điều kiện như
điều kiện đúng (hoặc sai) cần được thỏa mãn để lựa chọn các toán hạng tương ứng
trong một phân đoạn.
 Nốt sáp nhập (MN – Merge node): là nốt biểu thị cho sự sáp nhập các nhánh ra từ
một hành vi lựa chọn (chẳng hạn như lối ra từ một phân đoạn ALT hoặc OPT).
 Nốt rẽ nhánh (FN – Fork node): là nốt biểu thị đầu vào của phân đoạn PAR hoặc
SEQ.
 Nốt kết hợp (JN – Join node): là nốt đầu ra (hay kết thúc) của phân đoạn PAR
hoặc SEQ.
 Nốt kết thúc (End node): là nốt kết thúc của tất cả các chu trình trong đồ thị.
Một đồ thị dòng điều khiển G được biểu diễn như sau: G <A, E, in, F> với:
o ‘in’ là nốt khởi tạo (nốt bắt đầu).
o F là tập các nốt hay trạng thái cuối cùng của đồ thị.
o A là tập các nốt bao gồm (BN CN) với BN là nốt đơn vị (Block node),
CN = (DN MN FN JN) được gọi là tập các nốt điều khiển.
o E là tập các cạnh nối giữa các nốt. E = {f (x; y) | x, y A F}
Cấu trúc mỗi nốt A được đề xuất như sau: < nodeId, nodeType, nodeDetails,
outEdge > với:
 nodeId: là nhãn duy nhất được đính kèm vào mỗi nốt.
 nodeType = {decision, merge, fork, join} với mỗi và
nodeType = {block, initial, final} cho tất cả các nốt còn lại.
 nodeDetails = { ,..., | q là số của một tin nhắn trong BN}. Mỗi
nodeDetails được định nghĩa là một bộ ba < m, s, r > với mỗi bản tin xác định

17. 5
được đối tượng gửi s, đối tượng nhận r và tên của mỗi bản tin m cho tất cả các nốt
đơn vị BN. 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 >. Các thông tin này sẽ được đính kèm vào
cả các bộ thông số ParamList = { } và trả về giá trị rValue. Ngoài ra, một
thông số của một phương thức còn có thể được cung cấp từ các thuộc tính,
ràng buộc các lớp. 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ự.
 outEdge = { ,…, | q là số cạnh nối}. Mỗi được xác định
bằng < sourceNode, targetNode > [13].
2.3 Các độ đo kiểm thử
Độ đo kiểm thử là một công cụ giúp ta đo mức độ bao phủ chương trình của một
tập ca kiểm thử cho trước. 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ử. Bài nghiên cứu này chia ra 3 tiêu chuẩn bao phủ, để dễ hình dung
hơn về 3 tiêu chuẩn bao phủ này chúng ta sẽ bám theo ví dụ về kiểm thử phân đoạn Par đã
được biến đổi sang đồ thị dòng điều khiển như Hình 2.16.
I1 I3I2
m1
par m2
m3
m5
Bi
B1
B2
Bk
Bi
B1 B2
Bk
m4
FN1
JN1
Hình 2.2 Đồ thị dòng điều khiển tương ứng của phân đoạn Par.

18. 6
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. Đối với ví dụ Hình 2.16 ta có bảng các ca kiểm thử như sau:
ng 2.1 Ca kiểm thử độ bao phủ yếu
ID Input EO RO Note
tc1 Bi-FN1-B1-JN1-Bk
C2: Độ bao phủ trung bình: Đường kiểm thử đi qua tất cả các nhánh của đồ thị dòng điều
khiển. Bảng các ca kiểm thử tương ứng cho ví dụ Hình 2.16 như sau:
ng 2.2 Ca kiểm thử độ bao phủ trung bình
ID Input EO RO Note
tc1 Bi-FN1-B1-JN1-Bk
tc2 Bi-FN1-B2-JN1-Bk
C3: Độ bao phủ mạnh: Được áp dụng cho các thiết kế có sử dụng các phân đoạn song
song có các luồng chạy song song như Par, Seq. Khi đó các nốt chạy song song có chia sẻ
dữ liệu với nhau sẽ được hoán đổi vị trí để tạo ra các đường kiểm thử phủ được nhiều
trường hợp hơn.
ng 2.3 Ca kiểm thử độ bao phủ mạnh
ID Input EO RO Note
tc1 Bi-FN1-B1-JN1-Bk
tc2 Bi-FN1-B2-JN1-Bk
tc3 Bi-FN1-B1-B2-JN1-Bk
Với ví dụ Hình 2.16, ngoài các ca kiểm thử thông thường không xét đến trường
hợp các thông điệp song song có điểm chia sẻ dữ liệu ta thu được hai ca kiểm thử ct1 và
ct2 như ảng 2.3. Ngoài ra, vì hai thông điệp B1 và B2 nằm trong phân đoạn Par nên
chúng có thể được thực hiện song song hoặc đảo trật theo một thứ tự bất kì. Trong trường
hợp này ta thu được một ca kiểm thử khác là tc3 (Bi-FN1-B1-B2-JN1-Bk) như ảng 2.3.

19. 7
Chương 3: PHƯƠNG PHÁP SINH ĐỒ THỊ DÒNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ
TUẦN TỰ
3.1 Thuật toán biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển
Biểu đồ tuần tự biểu diễn thiết kế theo trình tự thời gian. Bên trong bao gồm nhiều
thành phần và các thông tin đính kèm. Mỗi thành phần, cấu trúc biểu diễn một hoạt động
khác nhau trong ca sử dụng. Biến đổi biểu đồ tuần tự sang đồ thị dòng điều khiển là một
công việc khó khăn vì chúng không tuân theo một qui luật nào cả. Để làm được điều này
chúng ta phải liệt kê tất cả các thành phần, khối toán tử bên trong biểu đồ tuần tự và dùng
thuật toán tương ứng biến đổi cho từng toán tử và thành phần đó. Thuật toán này không
những phải hoạt động đúng mà còn phải đảm bảo tính đúng đắn khi các thành phần và
toán tử lồng ghép vào nhau trong thiết kế.
3.1.1. Thuật toán sinh đồ thị dòng điều khiển
Đầu vào của thuật toán 1 sinh đồ thị dòng điều khiển là tệp xmi là lưu trữ dạng kí
tự của biểu đồ tuần tự. Vì vậy, để biến đổi được từ biểu đồ tuần tự sang đồ thị dòng điều
khiển thì bên trong thuật toán 1 sử dụng các thư viện đọc tệp xmi, từ đó bóc tách dữ liệu
theo các từ khóa tương ứng với từng phần tử thiết kế trong biểu đồ tuần tự. Bảng 3.1 miêu
tả một số từ khóa cơ bản dùng để nhận biết và đọc dữ liệu trong tệp xmi.
ảng 3.1 Các khóa cơ bản và ý nghĩa trong tệp xmi
Khóa Ý nghĩa
<constraints> ắt đầu khai báo các ràng buộc (OCL) trong biểu đồ
</constraints> Kết thúc khai báo các ràng buộc trong biểu đồ
<fragment ắt đầu một phân đoạn
</fragment> Kết thúc một phân đoạn
<lifeline ắt đầu trục thời gian
<message ắt đầu một thông điệp
</message> Kết thúc một thông điệp
<operand ắt đầu khai báo các toán tử bên trong phân đoạn
</operand> Kết thúc khai báo các toán tử bên trong phân đoạn
Cấu trúc dữ liệu của biểu đồ tuần tự là một mảng các phần tử bao gồm thông điệp,
phân đoạn và toán hạng và tất cả các phần tử này được sắp xếp theo trình tự thời gian.

20. 8
Thuật toán phân tích lần lượt từng phần tử trong hàng đợi và trả về các nốt khác nhau. Bắt
đầu từ nốt khởi đầu in – được xem là nốt hiện tại (curNode), mỗi phần tử của hàng đợi sẽ
được đọc bởi câu lệnh (queue.pop()). Tùy thuộc vào số lượng phần tử trong hàng đợi,
thuật toán này sẽ được gọi trả về là BN, DN, MN, FN và JN.
Thuật toán 1 biểu diễn các bước sinh đồ thị CFG từ biểu đồ tuần tự là tệp xmi. Các
bước thực hiện như sau:
 Tạo nốt bắt đầu, đặt nốt bắt đầu là nốt bắt đầu duyệt là curPos.
 Khởi tạo hàng đợi (rỗng).
 Đọc từng phần tử từ tệp xmi và thêm vào hàng đợi rồi chuyển sang phần tử tiếp
theo. Quá trình đọc tệp xmi được lặp lại cho tới khi kết thúc.
Thuật toán 1: Sinh đồ thị CFG
Đầu vào: Biểu đồ tuần tự D (tệp xmi trích xuất từ phần mềm Enterprise Architect)
Đầu ra: Đồ thị G: (A, E, in, F) với: A là tập các nốt (BN, DN, MN, FN, JN);
in là nốt khởi tạo, F là nốt kết thúc; E là tập các cạnh trong đồ thị CFG,
E ={(x, y) | x, y A F}.
1: create initial node in, node x;
2: create empty queue;
3: create curPos point at start element of sequence diagram D in xmi;
4: repeat
5: curPos read each element of D to add to queue
6: curPos move to next Element;
7: until curPos meets end element of xmi file
8: x = processElement(queue, in); // thuật toán 2
9: if x ≠ finalNode then
10: create final Node fn F;
11: Connect edge from x to fn;
12: end if
13: return G;

21. 9
 Hàng đợi thu thập được và nốt bắt đầu được đưa vào thuật toán 2 để sinh các nốt
tương ứng theo thiết kế và lý thuyết chuyển đổi.
 Khởi tạo nốt kết thúc, nối các cạnh giữa các nốt kế tiếp nhau thu được đồ thị CFG
hoàn chỉnh.

22. 10
Thuật toán 2: Phân tích các phần tử trong hàng đợi queue (processElement). [3]
Đầu vào: queue: hàng đợi chứa thông tin các phân đoạn, thông điệp và ràng buộc
OCL, curNode A (nốt bắt đầu), Sequence Diagram: D
Đầu ra: exitNode A, CFG
1: while (queue != empty) do
2: x= queue.pop();
3: if (x==fragment) and (x.type=='opt' or 'alt' or 'loop') then
4: Create a DN ;
5: ConnectEdge(curNode,DN);
6: else if (x==message) then
7: begin
8: BN=CreateBlockNode() //BN is message or a set of message
9: for each message m
10: begin
11: get receiver class in r.className
12: msg=returnMsgStructure(D, m)
13: attr=returnAttributeStructure(D, OCL_Contraint)
14: for all variables in m
15: attachAttributeInfor(attr,m); //attach constraint c[i] to msg
16: end for;
17: ConnectEdge(curNode,DN);
18: exitNode =BN;
19: end for;
20: else if (x==operand) and (x.guard!=null) then
21: attachGuardtoEdge()

23. 11
22: curNode = DN;
23: else if (x== fragment) and (x.type=='par' or 'seq') then
24: Create forkNode FN;
25: ConnectEdge(curNode,FN);
26: curNode = FN;
27: for each operand
28: Create BN to coressponding msg;
29: isAsynToBN() //attach isAsyn toBN with
30: messages of operands having sharing data
31: else if (x== fragment) and (x.type=='ignore') then
32: if(message.attribute==x.attribute)
33: Remove BN to coressponding msg;
34: else if (x== fragment) and (x.type== 'consider') then
35: if (message.attribute!=x.attribute)
36: Remove BN to coressponding msg;
37: else if (x== fragment) and (x.type=='neg') then
38: Create forkNode FN;
39: ConnectEdge(curNode,FN);
40: curNode = FN;
41: if (message from inside linelife)
42: Create BN to the first branch;
43: else if (message from outside linelife)
44: Create BN to the second branch;
45: else if (x== fragment) and (x.type=='assert') then
46: if(message.attribute==x.attribute)
47: Create BN to coressponding msg;
48: else if (x== fragment) and (x.type=='break') then
49: if (curNode inside a fragment)
50: Exit current fragment;

24. 12
Thuật toán 2 với đầu vào là nốt bắt đầu và hàng đợi chứa thông tin các thông điệp
thu thập được từ tệp xmi thông qua thuật toán 1. Đầu ra là đồ thị CFG tương ứng với thiết
kế. Nguyên tắt hoạt động của thuật toán 2 như sau:
 Đọc từng phần tử trong hàng đợi, nếu gặp thông điệp thì tạo một nốt đơn N.
 Nếu gặp một phân đoạn, kiểm tra xem đó là phân đoạn nào.
o Nếu gặp opt, alt, loop: tạo nốt quyết định DC.
o Nếu gặp par, seq: tạo nốt rẽ nhánh FN.
o Nếu gặp ignore: bỏ qua các thông điệp thỏa mãn điều kiện phân đoạn
ignore.
o Nếu gặp consider: chỉ xem xét các thộng điệp thỏa mãn điều kiện phân đoạn
consider.
51: else jump to exitNode;
52: else if (x=='EOF' and x.type=='alt' or 'opt') then //termination condition of frag alt
or opt
53: Create merge node MN
54: ConnectEdge(curNode,MN);
55: exitNode =MN;
56: else if (x=='EOF' and x.type=='par' or 'seq' or ‘neg’) then
57: Create join node JN
58: ConnectEdge(curNode,JN);
59: exitNode =JN;
60: else if (x=='EOF' and x.type=='loop') then
61: attachLoopstoEdge() //attach number of loops to Edge
62: ConnectEdge(curNode,DN);
63: curNode=DN;
64: else if (x=='EOF' and x.type=='ignore' or ‘consider’ or ‘assert’) then
65: continue;
66: end if
67: return exitNode;
68: end while

25. 13
o Nếu gặp neg: tạo nốt rẽ nhánh FN, tiếp tục kiểm tra các thông điệp nằm
trong phân đoạn neg. Nếu thông điệp nào xuất phát từ các trục thời gian bên
trong phân đoạn, thêm vào nhánh thứ nhất. Nếu thông điệp nào xuất phát từ
các trục thời gian bên ngoài phân đoạn, thêm vào nhánh thứ 2. Điều này
thỏa mãn nếu hai thông điệp là trái ngược nhau thì sẽ không bao giờ sảy ra
đồng thời trong cùng một ca sử dụng.
o Nếu gặp assert: chỉ kiểm tra các thông điệp thỏa mãn điều kiện phân đoạn
assert. Các thông điệp khác bỏ qua cho tới khi thoát khỏi phân đoạn hiện tại.
o Nếu gặp break: thoát khỏi phân đoạn hiện tại hoặc nhảy về nốt kết thúc nếu
đang không ở trong một phân đoạn nào cả.
 Nếu gặp EOF (End Of Fragment): kiểm tra phân đoạn đang xử lý:
o Nếu là EOF của phân đoạn par, seq hoặc neg: tạo một nốt FN và liên kết tất
cả các nhánh.
o Nếu là EOF của loop: nốt kết thúc của phân đoạn là nốt quyết định của vòng
lặp.
Quá trình xử lý các phân đoạn được thực hiện đệ qui lồng vào nhau để đảm bảo
tính đúng đắn khi các phân đoạn thiết kế lồng nhau. Thuật toán kết thúc khi tất cả các
phần tử trong hàng đợi được duyệt xong.
3.1.2. Đồ thị dòng điều khiển tương ứng với các phân đoạn
Sau khi áp dụng thuật toán biến đổi sinh đồ thị dòng điều khiển ta thu được kết quả
tương ứng đối với từng phân đoạn như sau:
Biến đổi tương ứng đối với phân đoạn Alt: Phân đoạn Alt đại diện cho một toán
tử lựa chọn. Trong lập trình, phân đoạn Alt được hiểu như một hàm “if-else”. Vì vậy, trên
biểu đồ CFG phân đoạn Alt là một nốt rẽ nhánh DC và kết thúc bởi nốt JN. Sau nốt rẽ
nhánh của phân đoạn Alt có thể bao gồm hai hay nhiều nhánh khác nhau tùy thuộc vào
cấu trúc cũng như thiết kế của phân đoạn Alt trên biểu đồ tuần tự. Hình 3.1 biễu diễn mô
hình biến đổi tương ứng của phân đoạn Alt sang đồ thị CFG.
Biến đổi tương ứng đối với phân đoạn Opt: Phân đoạn Opt đại diện cho một
toán tử lựa chọn khác nhưng chỉ nhận giá trị đúng. Trong lập trình, phân đoạn Opt được
hiểu như một hàm kiểm tra hoặc hàm “if” chỉ nhận một giá trị đúng. Ngược lại thì không
làm gì cả và chuyển sang nốt tiếp theo. 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). Hình 3.2 biễu diễn mô hình biến đổi tương ứng của phân đoạn Opt sang
đồ thị CFG.

26. 14
Biến đổi tương ứng đối với phân đoạn Loop: Phân đoạn Loop đại diện cho một
vòng lặp và kiểm tra giá trị tại nốt điều kiện lặp. Trong lặp trình phân đoạn Loop tương
ứng với các vòng lặp “while, for, repeat, v.v”. Tất cả các phương thức lặp đều có điều
kiện lặp để giới hạn số vòng lặp. Vì vậy trong đồ thị CFG phân đoạn Loop cũng được
biểu diễn bằng một nốt quyết định DC tuy nhiên không có JN ở cuối phân đoạn như Alt
hay Opt. Mà nốt kết thúc phân đoạn Loop là chính nó để kiểm tra lại điều kiện lặp và
chuyển sang nốt tiếp theo khi điều kiện lặp không còn thỏa mãn. Hình 3.3 biễu diễn mô
hình biến đổi tương ứng của phân đoạn Loop sang đồ thị CFG. 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.
Ví dụ vòng lặp for trong thiết kế ứng với đoạn mã nguồn sau:
For (int i = 0; i < 10; i++) {
money = money + 500;
if (money > 5000) {
break;
}
}
Từ mã nguồn ta thấy vòng lặp cho phép lặp tối đa 10 lần, sau mỗi lần lặp giá trị
money bị thay đổi. Trong một số trường hợp vòng lặp có thể bị ngắt (không lặp đủ 10 lần)
vì thoải mãn điều kiện bên trong. Những thay đổi này gây khó khăn trong việc xây dựng
hệ và sinh dữ liệu kiểm thử sau khi đã có ca kiểm thử. Điều kiện lặp được đọc một lần và
đưa đưa vào hệ để giải sinh dữ liệu kiểm thử, tuy nhiên nếu số lần lặp nhiều hơn một sẽ
có tương ứng số ràng buộc phải đưa vào để giải hệ. Việc này là không thể thực thi khi
chưa có mã nguồn. Đây cũng là một trong những nhược điểm của kiểm thử dựa trên mô
hình. Để giải quyết bài toán này, tất cả các vòng lặp được qui ước số vòng lặp là một (khi
sinh ca kiểm thử và dữ liệu kiểm thử).
Biến đổi tương ứng đối với phân đoạn Break: Phân đoạn Break cho phép thoát
ra khỏi vòng lặp hay các nốt quyết định khác đang thực thi tới nó và nhảy tới bước tiếp
theo. Trong trường hợp phân đoạn Break không nằm trong phân đoạn nào thì nó sẽ nhảy
tới nốt kết thúc. Trong lặp trình, phân đoạn reak có ý nghĩa tương tự với lệnh ngắt
(break), tuy nhiên lệnh “break” trong lặp trình chỉ thường sử dụng để thoát ra một vòng

27. 15
lặp hay một hàm điều kiện chứ không sử dụng để nhảy tới cuối chương trình. Hình 3.4
biễu diễn mô hình biến đổi tương ứng của phân đoạn reak sang đồ thị CFG.
I1 I3I2
m1
alt m2
m3
m4
m5
m6
Bi
B1
B2
Bk
Bi
B1 B2
Bk
M1
D1
[c1]
[c2]
[c1] [c2]
Hình 3.1 Đồ thị CFG tương ứng cho phân đoạn Alt.
I1 I3I2
m1
opt
m3
m4
m2
Bi
B1
Bk
Bi
B1
Bk
M1
D1
[c1]
[c1] [!c1]
Hình 3.2 Đồ thị CFG tương ứng cho phân đoạn Opt.
Biến đổi tương ứng đối với phân đoạn Par: Phân đoạn Par đại diện cho toán tử
lựa chọn, có thể có nhiều hơn 2 lựa chọn rẽ nhánh và các nhánh này có thể được thực hiện
đồng thời. Để biểu diễn sự khác biệt này, trên đồ thị CFG phân đoạn Par sẽ được biểu
diễn bởi một nốt FN và kết thúc bằng nốt JN. Các nhánh trong phân đoạn Par được qui
ước cho phép hoạt động song song nhau. Hình 3.4 biễu diễn mô hình biến đổi tương ứng
của phân đoạn Par sang đồ thị CFG.

28. 16
I1 I3I2
m1
loop m2
Bi
B1
Bk
Bi
B1
BkD1
[c1]
[c1]
[!c1]
m3
m4
Hình 3.3 Đồ thị CFG tương ứng cho phân đoạn Loop.
I1 I3I2
m1
break m2
Bi
B1
Bk
[c1]
m3
m4
Bi
Bk
D1
[c1] [!c1]
B1
Hình 3.4 Đồ thị CFG tương ứng cho phân đoạn Break.
I1 I3I2
m1
par m2
m3
m5
Bi
B1
B2
Bk
Bi
B1 B2
Bk
m4
FN1
JN1
Hình 3.5 Đồ thị CFG tương ứng cho phân đoạn Par.

29. 17
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). Trong ví dụ Hình 3.6, bình thường khi biến đổi
sang đồ thị CFG có thể tạo thành 3 nhánh thực thi song song nhau. Tuy nhiên vì m3 và
m4 cùng truyền tới I3 nên m3 chắc chắc phải được thực thi trước m4. Vậy, để đảm được
điều này m3 và m4 sẽ được gộp vào một nhánh và sắp xếp theo đúng trình tự. Về thiết kế
biến đổi này sẽ bỏ qua một trường hợp là chương trình thực thi m3 và không thực thi m4.
Tuy nhiên đây chỉ là một khả năng nhỏ trong rất nhiều khả năng khác. Hơn nữa việc thực
thi thêm m4 cũng không gây ảnh hưởng nhiều trong thiết kế kiểm thử nên có thể chấp
nhận được.
I1 I3I2
m1
seq m2
m3
m5
Bi
B1
B3
Bk
Bi
B1
B2
Bk
m4
FN1
JN1
B2
B3
Hình 3.6 Đồ thị CFG tương ứng cho phân đoạn Seq.
Biến đổi tương ứng đối với phân đoạn Ignore: Phân đoạn Ignore sẽ bỏ qua các
thông điệp được khai báo trước. Trong ví dụ Hình 3.7, thông điệp ‘set’ sẽ bị bỏ qua trong
suốt thời gian mà phân đoạn còn hiệu lực.

30. 18
I1 I3I2
m1
ignore{set}
m2{get}
Bi
B1
Bk
m3{set}
m4
Bi
Bk
B1
B2
Hình 3.7 Đồ thị CFG tương ứng cho phân đoạn Ignore.
Biến đổi tương ứng đối với phân đoạn Consider: Ngược lại với phân đoạn
Ignore, phân đoạn Consider sẽ chỉ xem xét các thông điệp được khai báo trước. Các thông
điệp còn lại sẽ bị bỏ qua trong suốt thời gian phân đoạn còn hiệu lực. Hình 3.8 biễu diễn
mô hình biến đổi tương ứng của phân đoạn Consider sang đồ thị CFG.
I1 I3I2
m1
consider{set}
m2{get}
Bi
B1
Bk
m3{set}
m4
Bi
Bk
B2
B2
Hình 3.8 Đồ thị CFG tương ứng cho phân đoạn Consider.
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. Ngược lại, nếu một thông điệp bên ngoài đi vào vào
phân đoạn Neg đang được thực hiện thì các thông điệp bên trong phân đoạn Neg sẽ không
được phép thực hiện hoặc bị bỏ qua. Trong ví dụ Hình 3.9, thông điệp m2 sẽ không được
thực thi do được truyền từ đường I1 từ bên ngoài phân đoạn Neg vào. Và ngược lại, nếu
như thông điệp m2 đang được thực thi thì các thông điệp khác bên trong phân đoạn Neg
là m3 sẽ không được phép thực hiện hoặc bị bỏ qua.

31. 19
Biến đổi tương ứng đối với phân đoạn Assert: Phân đoạn Assert thường sử dụng
kết hợp với Ignore hoặc Consider để biểu diễn các trường hợp bắt buộc hoặc ngoại lệ xảy
ra bên trong. 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. Sau khi kết thúc phân đoạn Assert
thì các thông điệp khác trong Consider diễn ra bình thường.
Biến đổi tương ứng đối với phân đoạn Strict: Phân đoạn Strict dùng để diễn tả
sự tuân thủ nghiêm ngặt theo trình tự của các thông điệp. Ý nghĩa của phân đoạn là không
cho phép hoán đổi hoặc thực thi sai trình tự trong mọi tình huống. Điều này tuân thủ
phương pháp chung trong xây dựng đồ thị CFG từ biểu đồ tuần tự theo thời gian. Các ca
kiểm thử của Strict sẽ luôn được bao phủ bởi các ca kiểm thử ở mức độ bao phủ C2. Hình
3.11 biễu diễn mô hình biến đổi tương ứng của phân đoạn Strict sang đồ thị CFG.
I1 I3I2
m1
neg
m2
Bi
B1
Bk
m3
m4
B2
Bi
B1 B2
Bk
FN1
JN1
Hình 3.9 Đồ thị CFG tương ứng cho phân đoạn Neg.

32. 20
I1 I3I2
m1
consider{q, v, w}
m2{v}
Bi
B1
Bk
m3{q}
m4
Bi
Bk
B1
B2
assert B2
Hình 3.10 Đồ thị CFG tương ứng cho phân đoạn Assert.
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). Vì vậy, để việc kiểm
thử hiệu quả hơn các mô đun chứa phân đoạn critical region sẽ được thiết kế các ca kiểm
thử riêng biệt và không được đề xuất trong bài nghiên cứu này.
I1 I3I2
m1
Strict
m2
Bi
B1
Bk
m3
m5
Bi
Bk
B1
B2
B3m4
B2
B3
Hình 3.11 Đồ thị CFG tương ứng cho phân đoạn Strict.

33. 21
3.2 Kỹ thuật sinh kịch b n kiểm thử
3.2.1. Kịch b n kiểm thử cho các toán từ thông thường
Đồ thị dòng điều khiển được sinh ra từ biểu đồ tuần tự đưa ta trở về bài toán quen
thuộc trong kiểm thử hộp trắng. Có nhiều phương pháp sinh luồng kiểm thử có thể được
áp dụng như: thuật toán tìm theo chiều sâu, thuật toán tìm theo chiều rộng, v.v.
Xét về mặt giải thuật, cả hai thuật toán duyệt theo chiều rộng và thuật toán duyệt
theo chiều sâu đều có thể được sử dụng. Tuy nhiên, với mong muốn sinh lần lượt các ca
kiểm thử tương ứng, tức duyệt lần lượt từng đường đi từ điểm bắt đầu tới điểm kết thúc
thì thuật toán duyệt theo chiều sâu là phù hợp hơn. Vì vậy, trong bài nghiên cứu này tôi sử
dụng giải thuật thuật toán duyệt theo chiều sâu để duyệt đồ thị CFG và sinh ca kiểm thử.
Thuật toán duyệt theo chiều sâu là thuật toán mà quá trình tìm kiếm được phát triển
từ đỉnh con đầu tiên của nút đang tìm kiếm cho tới khi gặp được đỉnh cần tìm hoặc tới
một nút không có con. Khi đó giải thuật quay lui về đỉnh vừa mới tìm kiếm ở bước trước
và tiếp tục tìm kiếm cho tới khi duyệt hết tất cả các đỉnh trong đồ thị.
Ví dụ áp dụng thuật toán duyệt theo chiều sâu cho đồ thị Hình 3.12. Tìm kiếm ưu
tiên chiều sâu bắt đầu thăm đỉnh A, đi theo cạnh trái, tiếp tục tìm kiếm xong ở cây con trái
mới chuyển sang tìm kiếm ở cây con phải. Thứ tự thăm viếng các đỉnh là: A, B, D, F, E,
C, G. Quá trình viếng thăm các đỉnh diễn ra như sau: Sau khi thăm đỉnh A, vì chưa
được thăm nên theo cạnh A ta thăm , tiếp tục theo cạnh BD tới viếng thăm D. Từ D
không thể tiếp tục đi xa hơn, ta quay lại B. Từ , theo F đến thăm F, từ F đến thăm E.
Từ E vì A đã viếng thăm nên ta quay lại F, rồi quay lại B. Tại B vì tất cả các khả năng từ
đã xem xét nên ta quay lại A. Từ A, quá trình tiếp tục với các đỉnh C và G.

34. 22
A
B C E
B C E
Hình 3.12 Ví dụ cây đồ thị cần duyệt.
Á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.
Qui trình:
 Nốt Start được đánh số 0 nối với nốt 1 thu được cặp dữ liệu 0-1.
 Nốt 1 được nối với nốt 2 thu được cặp dữ liệu 1-2.
 Nốt 2 nốt tới nốt 3 và nốt 4 thu được dòng dữ liệu 2-3-4.
 Nốt 3 nối tới nốt 5 thu được cặp dữ liệu 3-5.
 Nốt 4 nối tới nốt 5 thu được cặp dữ liệu 4-5.
 Nốt 5 nối tới nốt 6 thu được cặp dữ liệu 5-6.
 Nốt 6 nối với nốt kết thúc.

35. 23
Start
Cook
food
FN
Heating.start Rotate
JN
Checking
food
End
0
1
2
3 4
5
6
Hình 3.13 Đồ thị dòng điều khiển.
ng 3.2 Dữ liệu thu thập tương ứng theo các nốt được nối với nhau
Nốt bắt đầu Nốt kết
thúc
Dữ liệu thu
thập
Start 1 0 1
1 2 1 2
2 3, 4 2 3 4
3 5 3 5
4 5 4 5
5 6 5 6
6 End |

36. 24
Thuật toán 3 miêu tả quá trình sinh ca kiểm thử cho các thiết kế chứa các phân
đoạn thông thường không có luồng song song. Đầu vào là đồ thị dòng điều khiển (ví dụ
Hình 3.13) và đầu ra là chuỗi các đường kiểm thử. Kết quả thu được ở Bảng 3.2 là một
kết quả trung gian trong quá trình biến đổi. Các bước thực hiện như sau: Từ đồ thị dòng
điều khiển duyệt từng nốt và kiểm tra nốt tiếp theo thu được thông tin ma trận kề (Bảng
3.2). Kết quả ma trận kề được đưa vào thuật toán 4 duyệt theo chiều sâu để tìm ra tất cả
các đường kiểm thử có thể đi từ nốt bắt đầu cho tới nốt kết thúc.
Thuật toán 3: Sinh ca kiểm thử cho các toán tử thông thường.
Đầu vào: Thông tin đường nối tất cả các cạnh trong đồ thị CFG.
E = {(x, y) | x, y A F} : tập tất cả các cạnh trong đồ thị CFG
Trong đó:
sourceList{x}: tập các nốt nguồn - các đỉnh xuất phát x trong tập cạnh (x, y).
targetList{y} : tập các nốt đích - các đỉnh kết thúc y trong tập cạnh (x, y).
Đầu ra: allTestPath p: là tập tất cả các đường kiểm thử
1: Create new String: danhsachke;
2: danhsachke = "-1 0n";
3. for each element sourceList
4: danhsachke += sourceNodeId(i) + " " + targetNodeId(i);
5: if (current sourceNode == current targetNode)
6: danhsachke += " " + target.get(j).getNodeId();
7: end if
8: danhsachke += "n";
9: end for
10: Create new String maTranKe = danhsachke; // maTranKe = "0 1n1 2 3n2 1n3
4n4 5n5 4 6n6 7 8n7 9 10n9 -1n10 -1n8 11n11 8 12n12 -1"
11: allTestPath p = new getAllPaths(maTranKe); // thuật toán duyệt theo chiều sâu
sinh ca kiểm thử

37. 25
Thuật toán 4: Duyệt theo chiều sâu để sinh đường kiểm thử (traverse).
Đầu vào: String maTranKe; với maTranKe là chuỗi các nốt khởi đầu và kết thúc của
các cạnh trong đồ thị CFG. Ví dụ cấu trúc một ma trận kề: maTranKe = "0 1n1 2 3n2
1n3 4n4 5n5 4 6n6 7 8n7 9 10n9 -1n10 -1n8 11n11 8 12n12 -1"
Đầu ra: String testPathString; là chuỗi tất cả các đường kiểm thử
1: CreateObject Vertex (int data, int[] branchId); // tạo đối tượng Vertex
2: Create new ArrayList<Vertex> vertexList ;
3: Create new ArrayList<Vertex> vertexPath;
4. Create new ArrayList<Integer> testPath;
5: Split maTranke line by line;
6: for each line of maTranke
7: vertexList.add(id, branchId)); // thêm tất cả các nốt nguồn và nhánh vào
vertexList là giá trị trung gian dùng để duyệt.
8: traverse(firstNode, new ArrayList<Vertex>() vertexPath) // duyệt ma trận kề
bắt đầu tại nốt đầu tiên
9: vertex v = vertexList.get(0);
10: if (v == null or v.getid() == -1) // kết thúc
11. testPath.add( vertexPath.clone()); // lưu đường đi thành đường kiểm thử
12: else if (check(vertexPath, v.getId())) // duyệt tiếp nếu chưa kết thúc
13: vertexPath.add(v);
14: int temp = v.getBranchLengh();
15: for (int i = 1; i < temp; i++)
16: Vertex u = getVertex(v.getBranchId(i));
17: traverse(u, vertexPath); // duyệt đệ qui
18: vertexPath.remove(vertexPath.size() - 1);
19: end for
20: end if
21: end for
22: return String testPathString = testPath.toString();

38. 26
Thuật toán 4 có đầu vào là ma trận kề, đầu ra là các ca kiểm thử. Các bước thực
hiện như sau:
 Khởi tạo một đối tượng vertex có cấu trúc Vertex (int data, int[] branchId) trong
đó int data để chứa giá trị đang duyệt, int[] branched là mảng chứa các đường
kiểm thử trong quá trình duyệt ma trận.
 Khởi tạo mảng vertexList là biến đổi của ma trận sẽ duyệt.
 Khởi tạo mảng vertexPath chứa đường kiểm thử đang được duyệt.
 Bắt đầu duyệt từng phần tử trong vertexList (bắt đầu từ nốt bắt đầu), nếu là nốt
không có rẽ nhánh lần lượt thêm vào vertexPath.
 Nếu gặp nốt rẽ nhánh (là nốt đi tới nhiều hơn 1 nốt tiếp theo), tiến hành duyệt đệ
qui theo từng nhánh cho tới khi gặp nốt kết thúc thu được một đường kiểm thử.
 Sau khi hoàn thành nhánh thứ nhất, quay lại đệ qui tiêp quá trình duyệt với các
nhánh tiếp theo thu được các đường kiểm thử còn lại.
 Mỗi đường kiểm thử hoàn thành được thêm vào mảng testPath để có thể khôi phục
mảng vertexPath về vị trí ban đầu hoặc vị trí bắt đầu đệ qui trước đó.
3.2.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. Nếu 2 nốt
có sử dụng chung một biến thì được gọi là có chia sẻ dữ liệu. 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ử. Để khắc phục điều này
cần phải thực hiện chung các nốt có chia sẻ dữ liệu trong cùng một test case mà chương
trình có thể thực hiện.
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). Khi đó ngoài 2 đường kiểm thử thông thường: 0-1-
2-3-5-6-End và 0-1-2-4-5-6 End sẽ có thêm 2 đường đi có thể được hình thành như là: 0-
1-2-3-4-5-6-End và 0-1-2-4-3-5-6-End.
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. Sau đó sắp xếp hai nốt này đi chung với nhau (có hoán đổi vị trí) trong một ca kiểm

39. 27
thử tạo ra các ca kiểm thử mới. Trong trường hợp trước và sau hai nốt này còn có các nốt
khác thì thứ tự các nốt trước nó phải được giữ nguyên.
Thuật toán sinh ca kiểm thử chứa các nốt có chia sẻ dữ liệu như sau:
Thuật toán 5: Sinh ca kiểm thử cho các toán tử song song.
Đầu vào: sourceList{x}; targetList{y} : là tập các đỉnh đầu và đỉnh cuối của tất cả các
cạnh trong CFG: E = {(x, y) | x, y A F}.
Đầu ra: allTestPath p: là tập tất cả các đường kiểm thử bao gồm đường kiểm thử cho
các phân đoạn song song.
1: Create new String: danhsachke;
2: danhsachke = "-1 0n";
3: for each element sourceList
4: if (current sourceNode == par or seq)
5: if (current sourceNode is shared data with forwardNode branch(x))
6: danhsachke += sourceNodeId(i) + targetNodeId(i) + startNode in branch(x);
7: else if (current sourceNode is shared data with backwardNode branch(x))
8: danhsachke += sourceNodeId(i) + targetNodeId(i) +
targetNodeId(backwardNodeId());
9: else if
10: danhsachke += sourceNodeId(i) + " " + targetNodeId(i);
11: else
12: danhsachke += sourceNodeId(i) + " " + targetNodeId(i);
13: end if
14: danhsachke += "n";
15: end for
16: Create new String maTranKe = danhsachke; // maTranKe = "0 1n1 2 3n2 1n3
4n4 5n5 4 6n6 7 8n7 9 10n9 -1n10 -1n8 11n11 8 12n12 -1"
17: allTestPath p = new getAllPaths(maTranKe); // thuật toán 4 - duyệt theo chiều sâu
sinh ca kiểm thử

40. 28
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. 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. 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. Nếu 2 nốt thuộc hai nhánh khác nhau của đồ
thị CFG cùng tác động tới một biến dữ liệu chung thì hai nốt đó được gọi là hai nốt có
điểm chia sẻ dữ liệu. 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.
3.3 Xây dựng hệ ràng buộc
Để thực thi được các ca kiểm thử sinh từ đồ thị dòng điều khiển thì cần có dữ liệu
đầu vào cho các ca kiểm thử. Dữ liệu đầu vào đó sẽ được lấy từ kết quả giải các hệ ràng
buộc tương ứng trên từng đường đi của ca kiểm thử. Dữ liệu đưa vào giải hệ được thu
thập từ ràng buộc OCL và các dữ liệu được khai báo trên thiết kế theo yêu cầu ở mục
3.1.2. Tất cả đều được bóc tách từ tệp xmi và lưu giữ trong các nốt (các thông điệp) tương
ứng.
Giữ liệu kiểm thử sẽ được giải tương ứng cho từng ca kiểm thử. Duyệt từ nốt khởi
đầu tới nốt kết thúc để thu thập các thông điệp và ràng buộc. Các ràng buộc và các biến sẽ
lưu trữ trong hai mang tương ứng như sau:
ArrayList<String> testConstraint
ArrayList<String> DefineList
Trong đó mảng ArrayList<String> DefineList sẽ lưu giữ các biến, mảng được khai
báo trong dữ liệu test. Trong thiết kế mô hình, các biến này thường cũng sẽ được khai báo
trong các biểu đồ lớp tương ứng trong ULM 2.0.

41. 29
Hình 3.14 Ví dụ về ràng buộc OCL được khai báo trong thiết kế.
Ví dụ về một mảng DefineList đã được điền dữ liệu như sau:
defineList = {int max, int money, double time, float transfer};
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. Ví dụ số tiền tối thiểu có trong tài khoản: money >=50, thời gian được
lưu giữ dưới dạng số thực: time > 0.
Ví dụ về một mảng testConstraint đã được fill dữ liệu như sau:
testConstraint = {max <=10, max >0, money >=50, time > 0, transfer = money/max};
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.
3.4 Gi i hệ sử dụng SMT-Solver
SMT-Solver là một chương trình được phát triển để giải các hệ ràng buộc dựa trên
nền tảng Z3. Được phát triển bởi một nhóm sinh viên trường Đại học Công Nghệ - Đại
học Quốc Gia Hà Nội [2]. Đầu vào của SMT-Solver là 2 mảng như mục 3.4. Đầu ra sẽ là
giá trị ngẫu nhiên thỏa mãn các điều kiện trong hệ ràng buộc. SMT-Solve hỗ trợ các loại
dữ liệu về số. Mã nguồn SMT solver sẽ được nhúng vào chương trình để giải các ràng
buộc trong các đường kiểm thử và đưa ra dữ liệu kiểm thử cho các ca kiểm thử tương
ứng.
Với đặc thù không đòi hỏi giải ra tất cả các kết quả thỏa mãn đường đi mà chỉ lấy
một kết quả thỏa mãn dùng làm dữ liệu kiểm thử. Kỹ thuật sinh ngẫu nhiên được xem như

42. 30
một phương pháp truyền thống để giải hệ ràng buộc. Với những bài toán phức tạp với
những biểu thức logic phức tạp thường kỹ thuật sinh ngẫu nhiên sẽ bộc lộ nhược điểm về
thời gian giải ra kết quả. Tuy nhiên trong bài toán này, các thiết kế thường chia làm các
mô hình nhỏ, các ca kiểm thử không quá phức tạp (kiểm thử đơn vị) như trong toán học
nên kỹ thuật sinh ngẫu nhiên là hoàn toàn phù hợp.
SMT Solver
(Z3)
SAT
UNSAT
Hệ ràng buộc
{defineList,
testConstraint}
Hình 3.15 Mô tả công cụ SMT Solver
Hiện nay, công cụ SMT-Solver đã giải quyết được với rất nhiều dạng dữ liệu bao
gồm cả dữ liệu tuyến tính và phi tuyến tính trong đó dữ liệu phi tuyến tính bao gồm các
biểu thức số học, mảng, ma trận, v.v. biểu thức phi tuyến tính như các hàm lượng giác.
Hình 3.15 mô tả qui trình giải hệ sử dụng trong bài nghiên cứu, đầu vào là hai mảng:
defineList: chứa thông tin khai báo kiểu dữ liệu đầu vào của các biến.
testConstraint: chứa thông tin hệ ràng bucc cần giải.
Công cụ SMT solver được thiết kế để giải ra kết quả từ hai mảng đầu vào, nếu có
nghiệm thỏa mãn hệ ràng buộc ta thu được kết quả đầu ra (SAT). Ngược lại, nếu hệ vô
nghiệm sẽ không có kết quả trả về (UNSAT). Nhược điểm duy nhất và cũng là vấn đề
phức tạp nhất với tất cả các phương pháp giải hệ đó là dữ liệu dạng ký tự, chuỗi kí tự
(String, ArrayString..). Đây là hạn chế chung của các phương pháp giải hệ tại thời điểm
hiện tại. Đối với dữ liệu này để thực hiện được cần phải biến đổi, mã hóa các kí tự về các
dạng dữ liệu quen thuộc trước khi đi vào giải.

43. 31
Chương 4: CÔNG CỤ VÀ THỰC NGHIỆM
Để kiểm tra tính đúng đắn, tính khả thi của nghiên cứu, khả năng áp dụng thực tế
và hiệu quả của lập trình so với thiết kế. Chương này tôi sẽ giới thiệu công cụ sinh bộ
kiểm thử dựa trên mô hình, phần mềm được gọi là Automation Test Data Synthesis (gọi
tắt là ATDS) nhằm mục đích kiểm tra lập trình có đúng với thiết kế hay không. Công cụ
được phát triển bằng Eclipse, ngôn ngữ sử dụng là java, chạy trên nền hệ điều hành
Windows 7/8/10. Kiến trúc và nguyên lý hoạt động và hướng phát triển của công cụ sẽ
được trình bày ở các phần từ 4.1 đến 4.4.
4.1 Giới thiệu công cụ và môi trường thực nghiệm
Hình 4.1 biểu diễn cấu trúc công cụ thực nghiệm của luận văn. iểu đồ tuần tự
được thiết kế trên phần mềm Enterprise Architect là phần mềm chuyên dụng được dùng
phổ biến trong các công ty ngày nay. Phần mềm có hỗ trợ tính năng xuất tệp xmi sau khi
thiết kế. Tệp xmi là dữ liệu đầu vào dùng để nghiên cứu trong suốt quá trình kiểm thử.
Qua quá trình phân tích, dữ liệu từ tệp xmi được chuyển đổi để sinh ra đồ thị dòng điều
khiển. Từ đồ thị dòng điều khiển áp dụng kỹ thuật quét theo chiều sâu để sinh ra đường
kiểm thử và các ca kiểm thử tương ứng.
ATDS
(Automation Test Data Synthesis)
Enterprise Architect Software
Write JAVA
source code
UML
Sequence
diagram
XMI File Execution
Module
SMT Solve
JRE System Library
Jeval Library
Jxl Library
Swing2swt Linary
Z3
Test coverage
Test case
(excel file)
OUTPUT
Hình 4.1 Cấu trúc công cụ thực nghiệm.

44. 32
Đườ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. Chúng ta cũng bóc tách được dữ liệu từ tệp xmi
và biến đổi sinh ra hệ ràng buộc là đầu vào của công cụ SMT-Solver. Hệ ràng buộc được
giải để sinh ra các bộ dữ liệu kiểm thử cho các ca kiểm thử tương ứng. 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. Kết quả đầu ra được so sánh với kết
quả mong đợi. Nếu kết quả đầu ra khác với kết quả mong đợi cho thấy thiết kế là sai và có
lỗi. Nếu kết quả đầu ra đúng với kết quả mong đợi cho thấy thiết kế đã đảm bảo tính đúng
đắn so với đặc tả hệ thống.
Dưới đây là các công đoạn hoạt động của công cụ:
1. Sinh đồ thị dòng điều khiển là chuyển đổi tương ứng của biểu đồ tuần
tự.
2. Sinh kịch bản kiểm thử từ đồ thị dòng điều khiển.
3. Sinh các bộ dữ liệu kiểm thử tương ứng cho các ca kiểm thử.
4. Lưu giữ kịch bản ra tệp excel phục vụ cho quá trình kiểm thử.
ng 4.1 Môi trường thử nghiệm công cụ sinh ca kiểm thử từ thiết kế
Vi xử lý
Intel(R) Core(TM) i3/i7-2120 CPU @ 3.30GHz, 3300
Mhz, 2 Core(s), 4 Logical Processor(s)
ộ nhớ vật lý (RAM) 4GB
Hệ điều hành Microsoft Windows 10 Professional
Phiên bản IDE Eclipse Java EE IDE Version 4.5.1
Phiên bản Java Platform 1.8 _ Product 1.8.0_56
Công cụ ATDS được phát triển trên nền tảng Java và được thiết kế để hoạt động
trên môi trường window. Công cụ sử dụng đầu vào là biểu đồ tuần tự lưu trữ dưới định
dạng xmi. Với giao diện trực quan, công cụ cho phép vẽ đồ thị dòng điều khiển và hiển
thị ra màn hình. Đồ thị dòng điều khiển là dẫn xuất biến đổi tương ứng từ biểu đồ tuần tự
theo các qui luật biến đổi được đề xuất trong chương 3. Sau khi vẽ đồ thị dòng điều khiển,

45. 33
công cụ tìm kiếm và thực thi tất cả các đường kiểm thử có thể đi qua để sinh các ca kiểm
thử và dữ liệu kiểm thử tương ứng cho từng ca kiểm thử. Các ca kiểm thử được sinh ra
theo 3 cấp độ kiểm thử đã trình bày ở chương 2 phần 2.4. Người dùng có thể chọn vào
từng ca kiểm thử để kiểm tra đường đi. Đường đi của ca kiểm thử được hiển thị trực tiếp
trên đồ thị dòng điều khiển tương ứng với ca kiểm thử đang được chọn. Cuối cùng, sau
khi hoàn thành tất cả các khâu, người dùng có thể thực hiện xuất ra tệp excel để phục vụ
cho mục đích kiểm thử. Bảng 4.1 trình bày các thông số về môi trường thực nghiệm công
cụ.
4.2 Thực nghiệm
Ví dụ 1: Bài toán chuyển khoản - quản lý tài khoản ngân hàng.
Đầ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. Các bước công việc cụ thể được mô tả như sau:
Khởi tạo hai luồng song song cùng truy cập vào một tài khoản.
Luồng 1:
- Truy nhập tài khoản luồng 1.
- Chuyển tiền từ tài khoản chính sang tài khoản tiết kiệm.
- Kiểm tra số dư tài khoản chính.
- Kiểm tra số dư tài khoản tiết kiệm.
Luồng 2:
- Truy nhập tài khoản luồng 2.
- Tất toán tiền từ tài khoản tiết kiệm sang tài khoản chính.
- Chuyển tiền sang tài khoản tiết kiệm (lặp).
- Kiểm tra số dư tài khoản chính.

46. 34
Hình 4.2 Đầu vào của ví dụ 1.
Đầu ra:
 Đồ 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òng lặp phân đoạn Loop trong biểu đồ tuần
tự tương ứng với nốt DN trong đồ thị CFG. Thoát ra khỏi phân đoạn Par cũng là
kết thúc chu trình hoạt động tương ứng với nốt JN đồ thị Hình 4.3.
 Ca kiểm thử tương ứng theo 3 độ đo kiểm thử (Hình 4.4, 4.5 và 4.6). Trong đó
Hình 4.4 hiển thị tất cả các ca kiểm thử ở độ đo kiểm thử yếu. Tất cả các nốt quyết
định, các nốt rẽ nhánh trong đồ thị dòng điều khiển được đi qua ít nhất 1 lần.
Các ca kiểm thử độ bao phủ yếu (2 ca kiểm thử):
TC1: Start-DC-M1-M2-M3-M4-JN
TC2: Start-DC-M5-M6-DC-M7-DC-M8-JN
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.
Các ca kiểm thử độ bao phủ trung bình (3 ca kiểm thử):
TC1: Start-DC-M1-M2-M3-M4-JN
TC2: Start-DC-M5-M6-DC-M7-DC-M8-JN
TC3: Start-DC-M5-M6-DC-M8-JN

47. 35
Hình 4.3 Đầu ra đồ thị CFG cho ví dụ 1.
 Ca kiểm thử độ bao phủ yếu – Hình 4.4:
Hình 4.4 Ca kiểm thử độ bao phủ yếu cho ví dụ 1.

48. 36
 Ca kiểm thử độ bao phủ trung bình – Hình 4.5:
Hình 4.5 Ca kiểm thử độ bao phủ trung bình cho ví dụ 1.
 Ca kiểm thử độ bao phủ mạnh – Hình 4.6:
Hình 4.6 Ca kiểm thử độ bao phủ mạnh cho ví dụ 1.
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. Cụ thể các ca kiểm thử độ bao phủ mạnh trong ví dụ 1 như sau:
TC1: M2 và M5 có chia sẻ dữ liệu.
Start-DC-M1-M2-M5-M3-M4-M6-DC-M7-DC-M8-JN
TC2: M3 và M5 có chia sẻ dữ liệu.
Start-DC-M1-M2-M3-M5-M4-M6-DC-M7-DC-M8-JN
TC3: M4 và M5 có chia sẻ dữ liệu.

49. 37
Start-DC-M1-M2-M3-M4-M5-M6-DC-M7-DC-M8-JN
Hình 4.7 Đường đi tương ứng của một ca kiểm thử độ bao phủ mạnh của ví dụ 1.
Hình 4.7 biểu diễn đường đi tương ứng của một ca kiểm thử mạnh. 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. Theo đó, đường đi được miêu tả trong
Hình 4.13 theo thứ tự các nốt như sau:
Start – FN – M1 – M2 – M3 – M5 – M4 – M6 – DN – M7 – DN – M8 – JN – End.
4.3 Ý nghĩa thực nghiệm
Thực thi thành công công cụ kiểm thử tự động từ biểu đồ thiết kế là bằng chứng
chứng minh tính khả dụng và khả năng áp dụng thực tế cho các phương pháp kiểm thử
dựa trên mô hình. Hiện nay kiểm thử dựa trên mô hình vẫn là xu hướng chính trong
nghiên cứu cải tiến thúc đẩy qui trình kiểm thử phần mềm nói chung và kiểm thử tự động
nói riêng. Bằng phương pháp này, các công ty phần mềm có thể tiến hành kiểm thử ngay
từ khâu thiết kế, sinh ca kiểm thử tự động với độ bao phủ theo tùy ý theo các mức độ
mong muốn. Hiệu quả kiểm thử cũng đã được chứng minh vượt trội hơn so với các
phương pháp khác như kiểm thử ngẫu nhiên. Giúp tiết kiệm thời gian phát triển dự án
phần mềm, tiết kiệm nhân lực.

50. 38
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ữ liệu kiểm thử được sinh tự động. 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. và hoàn
thành một chu trình kiểm thử kín ở khâu thiết kế.

51. 39
Chương 5: KẾT LUẬN
Kiểm thử là một công đoạn quan trọng trong quá trình phát triển phần mềm và
phương pháp kiểm thử là yếu tố quyết định đến hiệu quả của việc kiểm thử. Rút ngắn thời
gian hoàn thành dự án, tăng hiệu quả và khả năng phát hiện lỗi luôn là những yêu cầu
hàng đầu trong kiểm thử. Hướng tới mô hình phát triển phần mềm trong môi trường công
nghiệp với đầy đủ các khâu trong thiết kế và phát triển phần mềm một cách bài bản, bài
nghiên cứu này đã đưa ra một phương án hoàn thiện hơn về kiểm thử dựa trên mô hình.
Sử dụng đầu vào sẵn có là biểu đồ tuần tự lưu trữ dưới dạng tệp xmi. Bài nghiên
cứu đã đề xuất một phương pháp sinh ca kiểm thử tự động với hiệu quả kiểm thử tương
đương với kiểm thử hộp trắng dựa trên biểu đồ CFG. Tuy nhiên, lỗi được phát hiện ở giai
đoạn này là sớm hơn nên mang lại hiệu quả cao hơn xét cả về kinh tế và thời gian phát
triển dự án. Một lần nữa, nội dung của bài nghiên cứu đã trình bày những nét cơ bản về
kiểm thử dựa trên mô hình. Vận dụng và đề xuất phương pháp sinh ca kiểm thử tự động
từ biểu đồ tuần tự và ràng buộc OCL. Đầu ra của bài toán là đồ thị trực quan CFG và các
ca kiểm thử được chia làm 3 mức độ. Trong đó mức độ kiểm thử tối ưu nhất cho phép
phát hiện lỗi với những thiết kế có nhiều luồng chạy song song và có điểm chia sẻ dữ liệu.
Đây là một ưu điểm lớn vì lỗi thường phát sinh ở những trường hợp sử lí song song này
(khi có nhiều tác tử cùng tương tác tới một đối tượng hay một biến trong chương trình).
Công cụ thực nghiệm cũng đã cho thấy tính khả thi và khả năng áp dụng thực tế của
phương pháp.
Hướng phát triển
Phần trình bày của phương pháp mới chỉ dừng lại ở việc sinh ca kiểm thử tự động.
Tối ưu hiệu quả của các ca kiểm thử. Việc tính toán kết quả mong muốn của ca kiểm thử
vẫn cần có sự can thiệp của chuyên gia. Để tự động hóa toàn bộ qui trình cần có sự kết
hợp của nhiều giai đoạn kiểm thử để so sánh và đối chiếu kết quả trong và sau mỗi ca
kiểm thử. Ví dụ, với các ca kiểm thử dựa trên mã nguồn, mã nguồn được xây dựng từ các
thiết kế đã được kiểm duyệt. Việc tính toán ra kết quả mong đợi cũng cần có sự can thiệp
của các chuyên gia để đảm bảo tính khách quan trong tính toán. Dựa trên yếu tố này,
chúng ta có thể xây dựng một qui trình kiểm thử mới là kết hợp giữa kiểm thử trên mô
hình và kiểm thử trên mã nguồn để so sánh và đối chiếu kết quả với cùng dữ liệu đầu vào.
Cả hai quá trình đều được thực hiện tự động và tách biệt nên đảm bảo tính khách quan mà
kết quả mang lại. Chỉ những ca kiểm thử cho kết quả khác nhau mới cần kiểm tra lại và
tìm ra kết quả đúng đắn.
Hướng nghiên cứu tiếp theo của tôi là kết hợp phương pháp hiện tại với các giai
đoạn kiểm thử khác để tối ưu hóa hiệu quả kiểm thử. Đề xuất kết hợp với giai đoạn kiểm

52. 40
thử sau khi đã có mã nguồn để so sánh kết quả kiểm thử. Tự động hóa qui trình sinh kết
quả mong muốn từ sự kết hợp giữa hai phương pháp. Phát triển hoặc thay thế công cụ giải
hệ để giải được với tất cả các loại dữ liệu đầu vào như kí tự, chuỗi kí tự.

53. 41
TÀI LIỆU THAM KHẢO
Tiếng Việt
[1]. Phạm Ngọc Hùng, Trương Anh Hoàng, Đặng Văn Hưng (2014), “Giáo trình kiểm
thử phần mềm”, Nhà xuất bản ĐH Quốc Gia HN.
[2]. Nguyễn Đức Anh (2015), “Phương pháp và công cụ hỗ trợ kiểm thử tự động các
đơn vị chương trình C”, Khóa luận tốt nghiệp Đại học, Trường Đại học Công
nghệ, Đại học Quốc Gia Hà Nội.
Tiếng Anh
[3]. Vũ Thị Đào, Phạm Ngọc Hùng, Vũ Việt Hà, Automated Test Data Generation
From Sequence_OCL
[4]. Ashalatha Nayak, Debasis Samanta (2010), “Automatic Test Data Synthesis
using UML Sequence Diagrams”, in Journal of Object Technology , vol. 09, no.
2, March 2010, pp. 75-104.
[5]. A.V.K. Shanthi and G. Mohan Kumar (2012), “Automated Test Cases
Generation from UML Sequence Diagram”, IPCSIT vol. 41 © (2012) IACSIT
Press, Singapore
[6]. Emanuela G. Cartaxo, Francisco G. O. Neto and Patr´ıcia D. L. Machado, "Test
Case Generation by means of UML Sequence Diagrams and Labeled Transition
Systems", IEEE 2007.
[7]. Li Bao-Lin, Li Zhi-shu, Li Qing, Chen Yan Hong , “Test Case automate
Generation from UML Sequence diagram and OCL Expression”, International
Conference on Computational Intelligence and Security 2007, pp 1048-1052.