đồ án xây dựng công cụ kiểm thử dòng điền khiển tự động java

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Dương Tuấn Anh

XÂY DỰNG CÔNG CỤ KIỂM THỬ DÒNG ĐIỀU
KHIỂN TỰ ĐỘNG CHO CÁC ĐƠN VỊ CHƯƠNG
TRÌNH JAVA

KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công nghệ thông tin

HÀ NỘI - 2016

HÀ NỘI – 2016


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Dương Tuấn Anh

XÂY DỰNG CÔNG CỤ KIỂM THỬ DÒNG ĐIỀU
KHIỂN TỰ ĐỘNG CHO CÁC ĐƠN VỊ CHƯƠNG
TRÌNH JAVA

KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công Nghệ Thông Tin

Cán bộ hướng dẫn: PGS. TS. Phạm Ngọc Hùng

HÀ NỘI - 2016

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ


VIETNAM NATIONAL UNIVERSITY, HANOI
UNIVERSITY OF ENGINEERING AND TECHNOLOGY

Duong Tuan Anh

A METHOD AND TOOL SUPPORTING FOR
AUTOMATED TESTING OF JAVA PROGRAMS

THE BS THESIS
Major: Information Technology

Supervisor: Assoc. Prof. Dr. Pham Ngoc Hung

LỜI CẢM ƠN

HANOI - 2016

VIETNAM NATIONAL UNIVERSITY, HANOI
UNIVERSITY OF ENGINEERING AND TECHNOLOGY


LỜI CẢM ƠN

Đầu tiên, tôi xin gửi lời cám ơn chân thành tới PGS. TS. Phạm Ngọc Hùng – giảng

viên bộ môn Công Nghệ Phần Mềm – người đã hướng dẫn tận tình, tỉ mỉ, chu đáo tôi trong
suốt hai năm tham gia nghiên cứu khoa học và làm khóa luận tốt nghiệp. Quãng thời gian
được thầy hướng dẫn đã giúp tôi học hỏi, đúc kết được nhiều kinh nghiệm về phương pháp
nghiên cứu, kĩ năng giao tiếp, kĩ năng làm việc nhóm, kĩ năng trình bày. Thầy còn truyền
cho tôi ngọn lửa yêu nghiên cứu khoa học, niềm tin vượt qua những khó khăn trong cuộc
sống và dạy tôi cách vượt qua những khó khăn đó. Tôi cảm thấy tự hào và may mắn khi là
một sinh viên được thầy hướng dẫn trong những năm tháng đại học.
Ngoài ra, tôi xin gửi lời cám ơn chân thành đến tập thể lớp K57 đã giúp đỡ tôi nhiệt
tình để hoàn thành khóa luận sao cho đạt hiệu quả cao nhất. Các bạn đã giúp đỡ tôi bằng
hành động, bằng lời nói mỗi khi tôi gặp khó khăn, thất bại. Bốn năm bên nhau không phải
là dài nhưng đối với tôi, đây là quãng thời gian tuyệt vời nhất và không thể nào quên.
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 để tôi tiếp tục đi xa hơn nữa trong lĩnh vực công nghệ thông tin.
Cuối cùng, tôi xin được cảm ơn gia đình đã nuôi tôi khôn lớn để trở thành người có
ích cho xã hội, giúp tôi có một điểm tựa vững chắc để yên tâm học hành trong suốt bao năm
qua. Tôi xin gửi lời cám ơn chân thành tới cha, mẹ, em gái đã luôn động viên và cổ vũ tôi
mỗi khi tôi gặp khó khăn và thử thách.
Hà Nội, ngày 27 tháng 05 năm 2016
Sinh viên

Dương Tuấn Anh


TÓM TẮT
Ngôn ngữ lập trình Java vẫn luôn là một trong những ngôn ngữ lập trình phổ biến
nhất, có chỗ đứng lâu nhất, bền bỉ và có tầm ảnh hưởng nhất. Java được sử dụng trong
khoảng 97% máy tính để bàn và có khoảng 1 tỷ bản Java tải về mỗi năm. Hơn nữa, Java
không đứng yên mà còn phát triển với một phiên bản Java mới là Java 8 đã được phát hành
năm ngoái và phiên bản Java 9 dự kiến được phát hành vào năm 2016. Vì sự phổ biến và

phát triển không ngừng đó, quá trình kiểm thử trong các dự án Java ngày càng tốn nhiều
công sức và chi phí hơn. Lượng mã nguồn lớn và phức tạp gây rất nhiều khó khăn trong
việc sinh các ca kiểm thử, đặc biệt là trong kĩ thuật kiểm thử hộp trắng. Vì vậy, việc tự động
hóa quá trình kiểm thử được xem như là một giải pháp để giảm bớt chi phí cho quá trình
kiểm thử mà vẫn đảm bảo được chất lượng sản phẩm. Hiện nay cũng đã có nhiều công cụ
hỗ trợ kiểm thử tự động cho ngôn ngữ Java nhưng đa số chỉ tập trung vào việc thực thi các
ca kiểm thử mà không chú trọng vào việc sinh ca kiểm thử tự động. Một số công cụ hỗ trợ
tự động sinh ca kiểm thử nhưng còn chưa đủ tốt và còn có những hạn chế nhất định.
Vì vậy, khóa luận đề xuất một phương pháp sinh ca kiểm thử tự động cho các đơn vị
chương trình Java và cài đặt công cụ hỗ trợ CFT4JUnit. Phương pháp sử dụng kĩ thuật kiểm
thử tự động hộp trắng dòng điều khiển theo hướng tĩnh. Đầu vào gồm một hàm Java có
chứa các biến số nguyên, số thực, các biến mảng và tiêu chí phủ kiểm thử, số vòng lặp tối
đa. Đầu ra gồm tập các ca kiểm thử đáp ứng được tiêu chí phủ kiểm thử và tập các ca kiểm
thử cho kiểm thử các vòng lặp. Cụ thể, ở bước đầu tiên, đồ thị dòng điều khiển ứng với tiêu
chí phủ kiểm thử được xây dựng bằng cách phân tích mã nguồn hàm đầu vào. Sau đó, đồ
thị này được phân tích để thu được một tập các đường thi hành sao cho sau khi thực hiện
chúng tiêu chí phủ kiểm thử được thỏa mãn. Tiếp theo, các đường kiểm thử chứa vòng lặp
được xử lí để sinh thêm các đường kiểm thử mới dùng kiểm thử tính đúng đắn của vòng
lặp. Kế tiếp, bằng kĩ thuật thực thi tượng trưng, các đường thi hành sẽ được phân tích thành
hệ ràng buộc tương ứng. Cuối cùng, các ca kiểm thử sẽ được thực thi để thu được kết quả
kiểm thử. Cuối cùng, các ca kiểm thử được sinh ra từ việc giải hệ các ràng buộc. Kết quả
thực nghiệm cho thấy phương pháp có thể sinh tự động được các ca kiểm thử với số lượng
tối thiểu nhưng vẫn đạt được độ phủ tối đa. Ngoài ra, khả năng phát hiện lỗi tương đối cao,
thời gian sinh các ca kiểm thử cũng được cải thiện đáng kể.
Từ khóa: Kiểm thử tự động, hàm Java, đồ thị dòng điều khiển, đường thi hành, ca
kiểm thử, Symbolic Execution, SMT-Solver


ABSTRACT
Java programming language has always been one of the most common programming

languages, has oldest standing, persistent and most influential. Java is used in about 97%
of the desktop and has about 1 billion download per year. Moreover, Java always grows up,
the newest version of Java is Java 8 was released last year and the Java version 9 is expected
to be released in 2016. As of the popularity and continued growth, the process of testing for
Java projects is more labor-intensive and take more cost. The amount of large and complex
source caused many difficulties in the test case generation, especially in the white-box
testing techniques. Thus, the automated testing process is seen as a solution to reduce the
cost of testing process while maintaining product quality. Currently, many tools are support
test automation for the Java language, but most of them focus only on the execution of test
cases instead of focused on test cases generation. Some tools support automatically
generates test cases, but still not good enough and there are certain restrictions.
Therefore, this thesis proposes a method of automated generating test cases for Java
unit and install a supporting tool. This method use automated testing techniques for white
box control flow graph with static direction. Inputs include a Java function contains integer
variables, real numbers, variables and arrays tested negative criteria, the maximum number
of loops. Output consists of a set of test cases to meet the criteria set of government testing
and test cases for testing the loop. Specifically, in the first step, the control flow graph with
specific coverage criteria is built by analyzing the source code input function.
Then this graph is analyzed to obtain a set of lines that execution after execution they
test negative criteria are met. Next, the test contains a loop road is processed to generate
additional new tests used road testing the correctness of the loop. Next, using symbolic
execution techniques, the implementation of the road will be analyzed in the corresponding
binding system. Then, the test cases are executed in order to obtain test results. Finally, the
test cases are generated by solving the system of constraints. Experimental results show
that the method can be automatically generated test cases with the minimum amount but
still achieve maximum coverage. In addition, the possibility of a relatively high error
detection, time of birth of test cases has also improved significantly.
Keywords: automatic testing, Java method, control flow graph, test path, test case,
Symbolic Execution, SMT-Solver

LỜI CAM ĐOAN

Tôi xin cam đoan rằng những nghiên cứu về kiểm thử tự động cho các đơn vị chương
trình Java được trình bày trong luận án này là của tôi và chưa từng được nộp như một báo
cáo khóa luận tại trường Đại học Công Nghệ - Đại học Quốc Gia Hà Nội hoặc bất kỳ trường
đại học khác. 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 khoá luậ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 27 tháng 05 năm 2016
Sinh viên

Dương Tuấn Anh


MỤC LỤC
Đặt vấn đề ...................................................................................................... 1
Tổng quan kĩ thuật kiểm thử tự động hộp trắng dòng điều khiển ........... 4
2.1. Tổng quan về kĩ thuật kiểm thử hộp trắng dòng điều khiển ..................................... 4
2.1.1. Đồ thị dòng điều khiển ........................................................................................ 4
2.1.2. Các tiêu chí phủ kiểm thử .................................................................................... 5
2.1.3. Tự động hóa quy trình kiểm thử hộp trắng dòng điều khiển ............................... 6
2.2. Tổng quan về kiểm thử tự động hộp trắng dòng điều khiển theo hướng động ......... 7
2.3. Tổng quan về kiểm thử tự động hộp trắng dòng điều khiển theo hướng tĩnh........... 8
2.4. So sánh kiểm thử tự động hộp trắng dòng điều khiển theo hướng tĩnh và động ...... 9
Phương pháp sinh ca kiểm thử tự động dòng điều khiển cho các đơn vị
của chương trình Java..................................................................................................... 11

3.1 Tổng quan về phương pháp kiểm thử đề xuất.......................................................... 11
3.2. Sinh đồ thị CFG ...................................................................................................... 12
3.2.1. Tổng quan phương pháp sinh đồ thị CFG ......................................................... 15
3.2.2. Phân tích mã nguồn ........................................................................................... 16
3.2.3. Phân tích cây AST từ mã nguồn ........................................................................ 16
3.2.4. Xây dựng đồ thị dòng điều khiển CFG .............................................................. 18
3.2.4.1. Tổng quan thuật toán sinh đồ thị CFG từ cây AST ................................... 18
3.2.4.2. Xử lí các nút đơn giản ............................................................................... 20
3.2.4.2. Xử lý nút khối ............................................................................................ 20
3.2.4.2. Xử lý nút câu lệnh if..else .......................................................................... 21
3.2.4.2. Xử lý nút câu lệnh for ................................................................................ 22
3.2.4.2. Xử lý nút câu lệnh while ............................................................................ 23
3.2.4.2. Xử lý nút câu lệnh do…while .................................................................... 24


3.2.4.2. Xử lý nút câu lệnh đặc biệt ........................................................................ 24
3.2.4.2. Liên kết các câu lệnh thực, xóa câu lệnh ảo .............................................. 25
3.2.5. Chuẩn hóa biểu thức .......................................................................................... 26
3.3. Xây dựng đường kiểm thử từ đồ thị CFG ............................................................... 27
3.3.1. Sinh tập đường đi độc lập .................................................................................. 27
3.3.2. Sinh tập đường kiểm thử cho các tiêu chí phủ .................................................. 29
3.3.3. Sinh tập đường kiểm thử cho vòng lặp .............................................................. 29
3.3.3.1. Sinh tập đường kiểm thử cho vòng lặp đơn .............................................. 30
3.3.3.2. Sinh tập đường kiểm thử cho vòng lặp lồng nhau..................................... 31
3.4. Sinh ca kiểm thử từ tập đường kiểm thử ................................................................. 32
3.4.1. Xây dựng hệ ràng buộc ...................................................................................... 32
3.4.2. Sinh ca kiểm thử từ hệ ràng buộc ...................................................................... 34
3.4.2.1. Phương pháp giải hệ ràng buộc bằng kĩ thuật sinh giá trị ngẫu nhiên ...... 34
3.4.2.2. Phương pháp giải hệ ràng buộc bằng công cụ SMT-Solver ...................... 35
Công cụ và thực nghiệm ............................................................................. 38

4.1. Giới thiệu về công cụ .............................................................................................. 38
4.1.1. Tổng quan về công cụ ........................................................................................ 38
4.1.2. Đồ thị dòng điều khiển CFG .............................................................................. 39
4.1.3. Tập các đường kiểm thử .................................................................................... 41
4.1.4. Tập các ca kiểm thử ........................................................................................... 41
4.1.5. Các thư viện hỗ trợ ............................................................................................ 42
4.1.5.1. Giới thiệu bộ giải Z3 ................................................................................. 42
4.1.5.2. Giới thiệu công cụ JDT ............................................................................. 42
4.2. Thực nghiệm ........................................................................................................... 43
4.2.1. Kiểm thử hàm đơn giản ..................................................................................... 43


4.2.2. Kiểm thử hàm phức tạp ..................................................................................... 44
4.2.3. Kiểm thử hàm có lỗi tiềm ẩn. ............................................................................ 45
4.2.4. Ý nghĩa của thực nghiệm ................................................................................... 46
Kết luận ........................................................................................................ 47


DANH SÁCH KÝ HIỆU, CHỮ VIẾT TẮT

Kí hiệu

Tên đầy đủ

Ý nghĩa

AST

Abstract Syntax Tree

Cây cấu trúc trừu tượng

CFG

Control Flow Graph

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

JDT

Java Development Tooling

Thư viện phân tích hỗ phân tích
mã nguồn file Java

SMTSolver

Satisfiability Modulo Theories Solver

Bộ giải hệ các phương trình

SAT

Scholastic Aptitude Test

Logic mệnh đề

SE

Symbolic Execution

Kĩ thuật thực thi tượng trưng

EO

Expected Output

Đầu ra mong muốn


DANH SÁCH HÌNH VẼ
Hình 2.1. Các loại đỉnh cơ bản trong đồ thị CFG. ........................................................................... 5
Hình 2.2. Các cấu trúc điều khiển phổ biến của chương trình. ....................................................... 5
Hình 2.3. Quy trình kiểm thử đơn vị chương trình dựa trên độ đo. ................................................ 6
Hình 2.4. Quy trình chung của kiểm thử hộp trắng dòng điều khiển theo hướng động. ................. 8
Hình 2.5. Quy trình chung của kiểm thử tự động hộp trắng dòng điều khiển. ................................ 9
Hình 3.1. Quy trình kiểm thử một hàm java theo phương pháp đề xuất. ...................................... 11
Hình 3.2. Đồ thị CFG của hàm average tiêu chuẩn phủ câu lệnh. ................................................ 14
Hình 3.3. Mã nguồn hàm average ................................................................................................. 15
Hình 3.4. Tổng quan phương pháp sinh đồ thị CFG từ mã nguồn. ............................................... 15
Hình 3.5. Xử lí nút AST đơn giản. ................................................................................................ 20
Hình 3.6. Xử lí nút AST khối. ....................................................................................................... 21
Hình 3.7. Xử lí nút AST lệnh if...else. ........................................................................................... 22
Hình 3.8. Xử lí nút AST câu lệnh for. ........................................................................................... 22
Hình 3.9. Xử lý nút AST câu lệnh while. ...................................................................................... 23
Hình 3.10. Xử lý nút AST câu lệnh do...while. ............................................................................. 24
Hình 3.11. Quy trình ghép nối: beforeStm -> R -> END. ............................................................. 25
Hình 3.12. Câu lệnh continue: beforeStm -> continueStm. ........................................................... 25
Hình 3.13. Câu lệnh break: beforeStm -> breakStm. .................................................................... 25
Hình 3.14. Những loại biểu thức được chuẩn hóa. ........................................................................ 26

Hình 3.15. Quá trình giải hệ ràng buộc bằng kĩ thuật sinh ngẫu nhiên ......................................... 34
Hình 3.16. Quá trình giải hệ ràng buộc bằng công cụ SMT-Lib. .................................................. 35
Hình 3.17. Cây biểu thức của biểu thức trung tố 2*a + b < c ........................................................ 37
Hình 4.1. Sơ đồ kiến trúc của công cụ CFT4Junit......................................................................... 38
Hình 4.2. Giao diện chính của công cụ. ........................................................................................ 39
Hình 4.3. Đồ thị CFG thỏa mãn tiêu chỉ phủ câu lệnh, phủ nhánh và phủ điều kiện con. ............ 40


Hình 4.4. Mã nguồn hàm foo. ........................................................................................................ 40
Hình 4.5. Tập đường đi thỏa mãn phủ nhánh của hàm foo. .......................................................... 41
Hình 4.6. Chi tiết ca kiểm thử ứng với một đường đi trong hàm foo. ........................................... 41
Hình 4.7. Thí dụ về đầu vào và đầu ra của công cụ Z3. ................................................................ 42
Hình 4.8. Minh họa cây AST ứng với mã nguồn return x*3. ........................................................ 43
Hình 4.9. Mã nguồn hàm min ........................................................................................................ 43
Hình 4.10. Mã nguồn hàm SelectionSort....................................................................................... 44
Hình 4.11. Mã nguồn hàm divide. ................................................................................................. 45


DANH SÁCH BẢNG
Bảng 4.1. Kết quả kiểm thử hàm min ............................................................................................ 44
Bảng 4.2. Kết quả kiểm thử hàm SelectionSort. ............................................................................ 44
Bảng 4.3. Kết quả kiểm thử hàm divide ........................................................................................ 45

DANH SÁCH THUẬT TOÁN
Thuật toán 1. CFG_Generation(f, t) .............................................................................................. 12
Thuật toán 2. CFG_Generation(AST, t) ........................................................................................ 19
Thuật toán 3. Path_Generation(CFG) ............................................................................................ 28
Thuật toán 4. Path_Loop_Generation(path, n) .............................................................................. 30
Thuật toán 5. Path_Test_InsideLoop_Generation(path, n) ........................................................... 31
Thuật toán 6. Path_Test_InsideLoop_Generation(path, n) ........................................................... 32

Thuật toán 7. Constraints_Generation(path) ................................................................................. 33
Thuật toán 8. Infix_To_Postfix(infixExp) ..................................................................................... 36


Đặt vấn đề
Ngôn ngữ lập trình Java vẫn luôn là một trong những ngôn ngữ lập trình phổ biến
nhất, có chỗ đứng lâu nhất, bền bỉ và có tầm ảnh hưởng nhất. Nó đã trở thành một nền tảng
thống lĩnh, có mặt tại các ứng dụng trong và ngoài môi trường web, chạy trên tất cả các hệ
điều hành nhờ hỗ trợ của cơ chế ảo hóa Java (Java Virtual Machine) bất chấp sự xuất hiện
của nhiều ngôn ngữ lập trình mới nổi sau này. Java được sử dụng trong khoảng 97% máy
tính để bàn và có khoảng 1 tỷ bản Java tải về mỗi năm. Hơn nữa, Java không đứng yên mà
còn phát triển với một phiên bản Java mới là Java 8 đã được phát hành năm ngoái và phiên
bản Java 9 dự kiến được phát hành vào năm 2016. Vì sự phổ biến và phát triển không ngừng
đó, quá trình kiểm thử trong các dự án Java ngày càng tốn nhiều công sức và chi phí hơn.
Lượng mã nguồn lớn và phức tạp gây rất nhiều khó khăn trong việc sinh các ca kiểm thử,
đặc biệt là trong kĩ thuật kiểm thử hộp trắng. Vì thế, kiểm thử tự động được xem như là một
giải pháp hiệu quả để giải quyết vấn đề này. Việc tự động hóa quá trình kiểm thử giúp giảm
thiểu thời gian, công sức và chi phí trong khi vẫn đảm bảo độ tin cậy cao của phần mềm.
Đồng thời, nó còn giúp kiểm thử viên giảm bớt nhàm chán và áp lực trong công việc. Ngoài
ra, kiểm thử tự động không chỉ có ý nghĩa khi dự án không đủ tài nguyên mà còn trong
kiểm thử hồi quy khi phần mềm cần sửa đổi hoặc nâng cấp.
Kiểm thử hộp trắng cho phép phát hiện các lỗi, khiếm quyết tiềm ẩn bên trong chương
trình phần mềm[1]. Tuy nhiên, để áp dụng các phương pháp kiểm thử hộp trắng, kiểm thử
viên không chỉ cần hiểu rõ giải thuật mà còn cần có các kỹ năng và kiến thức tốt về ngôn
ngữ lập trình viết mã nguồn, nhằm hiểu rõ mã nguồn cần kiểm thử[1]. Hơn nữa, người kiểm
thử và người lập trình thường là hai người khác nhau. Vì vậy, việc áp dụng các kĩ thuật
kiểm thử hộp trắng thường tốn rất nhiều thời gian và công sức, nhất là khi mã nguồn cần
kiểm thử có độ phức tạp cao. Do đó, các kĩ thuật kiểm thử hộp trắng chủ yếu được sử dụng
cho kiểm thử đơn vị.
Kĩ thuật kiểm thử hộp trắng có hai phương pháp phổ biến là kiểm thử dòng điều khiển

và kiểm thử dòng dữ liệu. Kiểm thử dòng dữ liệu (data flow testing) là kĩ thuật được dùng
để phát hiện lỗi liên quan đến việc khai báo và sử dụng các biến trong chương trình. Phương
pháp kiểm thử dòng điều khiển (control flow testing) tập trung kiểm thử tính đúng đắn của

1


các giải thuật sử dụng trong các chương trình/đơn vị phần mềm[1]. Hai kĩ thuật này thường
được sử dụng song song trong quá trình kiểm thử hộp trắng.
Hiện nay, kiểm thử hộp trắng dòng điều khiển có hai kĩ thuật chính đó là theo hướng
tĩnh và hướng động. Nhưng mục đích chung của cả hai kĩ thuật đều là sinh ra các tập ca
kiểm thử để đạt được độ phủ tối đa. Hiện nay, các công cụ sinh ca kiểm thử tự động cho
các chương trình viết bằng ngôn ngữ Java như EXSYS[2], jPET [3], v.v. chủ yếu sử dụng
kĩ thuật kiểm thử theo hướng động. Theo hướng tiếp cận này, mã nguồn sẽ được thực thi
với một bộ giá trị đầu vào ngẫu nhiên để đánh dấu một đường thi hành đầu tiên. Bằng cách
phủ định đường thi hành hiện tại, một đường thi hành mới sẽ được tạo ra. Các ràng buộc
phân tích từ đường thi hành mới sẽ được giải để sinh được ca kiểm thử tiếp theo. Việc kiểm
thử hộp trắng dòng điều khiển theo hướng động này còn có một số hạn chế nhất định. Thứ
nhất, nếu ca kiểm thử đầu tiên không thực thi được thì việc sinh ra các ca kiểm thử tiếp theo
sẽ không thực hiện được. Thứ hai, số lượng bộ giá trị kiểm thử có thể rất lớn do việc các
đường thi hành có thể bị trùng lặp, hoặc do số lượng các ràng buộc lớn từ việc thực thi các
vòng lặp. Thứ ba, thời gian sinh ca kiểm thử lâu hơn do mỗi khi sinh một ca kiểm thử, mã
nguồn lại phải thực thi một lần. Thứ tư, số lượng các ràng buộc sinh ra từ đường thi hành
là rất lớn và phức tạp nên việc giải hệ ràng buộc gặp nhiều khó khăn khi dùng kĩ thuật sinh
ngẫu nhiên.
Khóa luận này đề xuất một phương pháp sinh ca kiểm thử tự động cho các đơn vị
chương trình Java để khắc phục những hạn chế nêu trên. Phương pháp sử dụng kĩ thuật
kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh. Tư tưởng chính của phương pháp là
phân tích mã nguồn để sinh ra đồ thị dòng điều khiển CFG (Control Flow Graph). Các
đường thi hành sẽ được phân tích từ đồ thị CFG. Do đó, số lần thực thi mã nguồn được

giảm bớt rất nhiều giúp giảm thời gian sinh các ca kiểm thử. Hơn nữa, số lượng ca kiểm
thử ít hơn mà vẫn đảm bảo được độ phủ tối đa. Phương pháp không chỉ kết hợp các thế
mạnh của kĩ thuật sinh ngẫu nhiên và công cụ SMT-Solver mà còn đề xuất một kĩ thuật
phân loại các ràng buộc để giải. Vì thế, phương pháp có thể giải được nhiều loại hệ ràng
buộc một cách nhanh hơn.
Phần còn lại của khóa luận được trình bày như sau. Đầu tiên, chương 2 sẽ giới thiệu
tổng quan về kĩ thuật kiểm tự động thử hộp trắng dòng điều khiển. Tiếp theo, phương pháp
đề xuất sẽ được trình bày chi tiết trong chương 3. Sau đó, chương 4 sẽ giới thiệu về công
cụ được cài đặt và phát triển dựa trên phương pháp đề xuất cùng với những kết quả thực
2


nghiệm thu được. Cuối cùng, chương 5 trình bày tóm tắt các kết quả đã đạt được, kết luận,
những hạn chế và hướng nghiên cứu phát triển trong tương lai.

3


Tổng quan kĩ thuật kiểm thử tự động hộp trắng dòng
điều khiển
Ở phần này, khóa luận trình bày các kiến thức tổng quan về kiểm thử hộp trắng dòng
điều khiển và giới thiệu về hai kĩ thuật trong kiểm thử tự động hộp trắng dòng điều khiển
là theo hướng tĩnh và hướng động .
2.1. Tổng quan về kĩ thuật kiểm thử hộp trắng dòng điều khiển
Kiểm thử hộp trắng dòng điều khiển được sử dụng để kiểm tra tính đúng đắn và phát
hiện các lỗi tiềm ẩn trong mã nguồn của dự án phần mềm. Đầu vào là mã nguồn của chương
trình cùng với tiêu chí phủ kiểm thử. Đầu ra sẽ là tập các ca kiểm thử thỏa mãn tiêu chí phủ
kiểm thử.
2.1.1. Đồ thị dòng điều khiển
Trong kĩ thuật kiểm thử hộp trắng dòng điều khiển, đồ thị dòng điều khiển CFG

(Control Flow Graph) là một phần rất quan trọng. Đồ thị này thể hiện một cách tổng quát
và trực quan về các luồng điều khiển trong mã nguồn chương trình. Từ đó, người kiểm thử
có thể dễ dàng sinh các ca kiểm thử cho các tiêu chí phủ cũng như đánh giá độ tốt của các
ca kiểm thử. Đồ thị CFG của một hàm là một đồ thị có hướng được xây dựng từ mã nguồn
của chương trình. Đỉnh đầu vào đỉnh cuối đồ thị lần lượt tượng trưng cho trạng thái bắt đầu
và kết thúc của hàm. Các đỉnh còn lại, mỗi đỉnh tượng trưng cho một hoặc một nhóm câu
lệnh. Nếu câu lệnh tương ứng với đỉnh j được thực hiện ngay sau câu lệnh ứng với đỉnh i
thì sẽ tồn tại một cạnh nối từ đỉnh i đến đỉnh j. Các cạnh tượng trưng cho dòng điều khiển
giữa các câu lệnh hoặc nhóm câu lệnh.
Hình 2.1 mô tả kí hiệu năm loại đỉnh trong đồ thị dòng điều khiển [1]. Trong đó:
-

Đỉnh bắt đầu, đỉnh kết thúc: Là đỉnh tượng trưng cho trạng thái bắt đầu và kết thúc
của hàm.

-

Đỉnh xử lí: Là đỉnh tương ứng với các câu lệnh thực thi như câu lệnh gán, câu lệnh
khai báo, khởi tạo, v.v.
Đỉnh quyết định: Là đỉnh tương ứng với các câu lệnh chữa các điều kiện rẽ nhánh
như câu lệnh if, do…while, while…do, v.v.

-

4


-

Đỉnh nối: Là đỉnh mà có nhiều hơn một đỉnh khác chỉ đến mà không phải là đỉnh

quyết định.

Đỉnh bắt
đầu

Đỉnh xử
lí

Đỉnh quyết
định

Đỉnh nối

Đỉnh kết
thúc

Hình 2.1. Các loại đỉnh cơ bản trong đồ thị CFG.

Hình 2.2 mô tả các cấu trúc điều khiển phổ biến của chương trình: tuần tự, if…else,
do…while, while…do, for trong đồ thị dòng điều khiển [1].

Hình 2.2. Các cấu trúc điều khiển phổ biến của chương trình.

2.1.2. Các tiêu chí phủ kiểm thử
Khi kiểm thử hộp trắng dòng điều khiển, một trong các đầu vào là tiêu chí phủ kiểm
thử. Tiêu chí phủ kiểm thử ở đây là một thước đo để đánh giá độ tốt của bộ ca kiểm thử.
Tập các ca kiểm thử tốt hay không không dựa vào số lượng các ca kiểm thử mà dựa vào độ
phủ mà nó đạt được. Độ phủ càng lớn thì tập các ca kiểm thử đó càng tốt. Độ phủ này được
tính bằng tỉ lệ các thành phần kiểm thử được sau khi thực hiện các ca kiểm thử so với tổng
số các thành phần cần kiểm thử của chương trình. Các thành phần sẽ được phân chia cụ thể

theo từng tiêu chí phủ. Trong khóa luận, ba tiêu chí được sử dụng để đánh giá chất lượng
mã nguồn, bao gồm:
-

Phủ câu lệnh: Mỗi câu lệnh hay mỗi đỉnh trong đồ thị CFG phải được đi qua thi ít
nhất một lần sau khi thực thi các ca kiểm thử.
5


-

Phủ nhánh: Các đỉnh quyết định đều được đi qua cả nhánh đúng và nhánh sai sau

-

khi thực thi các ca kiểm thử.
Phủ điều kiện con: Các đỉnh quyết định đều được đi qua cả nhánh đúng và nhánh
sai, trong đó điểm quyết định có chứa nhiều điều kiện con sẽ được phân tách thành
các câu lệnh điều kiện đơn.

Quy trình kiểm thử đơn vị chương trình dựa trên các tiêu chí phủ kiểm thử được mô tả
như trong Hình 2.3. Đầu tiên, đồ thị dòng điều khiển CFG ứng với mỗi tiêu chí phủ
được xây dựng. Sau đó, đồ thị này được phân tích để thu được một tập các đường thi
hành sao cho sau khi thực hiện chúng tiêu chí phủ kiểm thử được thỏa mãn. Tiếp theo,
mỗi đường thi hành sẽ được sinh ra một ca kiểm thử tương ứng. Cuối cùng, các ca kiểm
thử sẽ được thực thi để thu được kết quả kiểm thử.
Mã nguồn
Tiêu chí
phủ

Xây dựng đồ thị
luồng điều khiển
CFG

Xác định các
đường thi hành

Sinh các ca
kiểm thử

Thực thi các
ca kiểm thử

Hình 2.3. Quy trình kiểm thử đơn vị chương trình dựa trên độ đo.

2.1.3. Tự động hóa quy trình kiểm thử hộp trắng dòng điều khiển
Hiện nay, lượng mã nguồn lớn và phức tạp gây rất nhiều khó khăn trong việc sinh các
ca kiểm thử, đặc biệt là trong kĩ thuật kiểm thử hộp trắng. Vì thế, kiểm thử tự động được
xem như là một giải pháp hiệu quả để giải quyết vấn đề này. Việc tự động hóa quá trình
kiểm thử giúp giảm thiểu thời gian, công sức và chi phí trong khi vẫn đảm bảo độ tin cậy
cao của phần mềm. Đồng thời, nó còn giúp kiểm thử viên giảm bớt nhàm chán và áp lực
trong công việc. Ngoài ra, kiểm thử tự động không chỉ có ý nghĩa khi dự án không đủ tài
nguyên mà còn trong kiểm thử hồi quy khi phần mềm cần sửa đổi hoặc nâng cấp. Nhìn
chung, việc tự động hóa quy trình kiểm thử hộp trắng có ba nguyên nhân chính:
-

Với một lượng mã nguồn lớn và có độ phức tạp cao thì việc kiểm thử hộp trắng bằng
tay khá tốn thời gian, công sức và dễ dẫn đến sai sót. Cũng vì lí do đó mà, kiểm thử
hộp trắng yêu cầu cao về trình độ chuyên môn và khả năng chịu áp lực của kiểm thử
viên.

6


-

Như đã nói ở nguyên nhân trước, kiểm thử hộp trắng yêu cầu kiểm thử viên phải có

-

trình độ chuyên môn sâu rộng về ngôn ngữ cần kiểm thử. Vì thế, chi phí tuyển dụng
và đào tạo nguồn nhân lực khá là tốn kém.
Theo như các thống kê thì chi phí dành cho quá trình kiểm thử trong các dự án phần
mềm thường chiếm từ 40% đến 60% tổng chi phí. Trong khí đó, phần mềm bây giờ
thường đòi hỏi yêu cầu cao về chất lượng. Hơn nữa, quá trình bảo trì và phát triển
phiên bản mới khi được tiến hành sẽ càng làm tăng chi phí kiểm thử.

Nhiều phương pháp và công cụ đã được đề xuất để hỗ trợ kiểm thử tự động hộp trắng
dòng điều khiển. Trong đó, hai phương pháp phổ biến được sử dụng trong kiểm thử tự động
dòng điều khiển là theo hướng động vào hướng tĩnh. Cả hai kĩ thuật này đều có mục tiêu là
sinh các ca kiểm thử để đạt được độ phủ tối đa. Mỗi kĩ thuật đều có những điểm mạnh và
điểm yếu riêng. Kĩ thuật kiểm thử theo hướng tĩnh thích hợp trong việc kiểm thử các mã
nguồn dễ phân tích như hàm đơn vị, hàm được viết theo một chuẩn nào đó v.v. Trong khi
đó, kĩ thuật kiểm thử theo hướng động phù hợp với các mã nguồn chương trình có độ phức
tạp cao, khó phân tích hơn. Trong phần tiếp theo, khóa luận sẽ trình bày quy trình chung
của từng phương pháp.
2.2. Tổng quan về kiểm thử tự động hộp trắng dòng điều khiển theo hướng động
Kĩ thuật kiểm thử tự động hộp trắng dòng điều khiển theo hướng động thường được
sử dụng với những mã nguồn có độ phức tạp cao, khó phân tích. Tư tưởng của kĩ thuật là
tận dụng thế mạnh của trình biên dịch để phân tích mã nguồn chương trình bằng cách chèn

thêm các câu lệnh đánh dấu vào mã nguồn. Hình 2.4 mô tả quy trình chung của kĩ thuật
này. Cụ thể, kĩ thuật gồm các bước sau:
Bước 1. Sinh ngẫu nhiên một bộ giá trị đầu vào hợp lệ.
Bước 2. Thực thi chương trình với bộ đầu vào vừa tìm được và đánh dấu đường thi
hành tương ứng.
Bước 3. Sinh hệ ràng buộc từ việc phân tích đường thi hành hiện tại.
Bước 4. Sinh hệ ràng buộc mới tượng trưng cho đường thi hành tiếp theo bằng cách
phủ định hệ ràng buộc tìm được ở bước 2. Nếu không sinh được hệ ràng buộc
mới thì thuật toán kết thúc.
Bước 5. Giải hệ ràng buộc thu được ở bước 4 để sinh được bộ giá trị đầu vào mới. Nếu
hệ vô nghiệm, quay lại bước 4. Ngược lại, quay lại bước 2.
7


Source code
Tiêu chí phủ

Sinh bộ đầu vào
ngẫu nhiên
Thực thi chương trình
Đánh dấu đường
thi hành
Sinh hệ ràng buộc

True

Tạo đường thi hành mới

Tìm được ca
kiểm thử mới

False
Kết thúc
Hình 2.4. Quy trình chung của kiểm thử hộp trắng dòng điều khiển theo hướng động.

2.3. Tổng quan về kiểm thử tự động hộp trắng dòng điều khiển theo hướng tĩnh
Kĩ thuật kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh phân tích và xử lí trực
tiếp với mã nguồn của chương trình. Một thành phần quan trọng trong phương pháp này là
đồ thị dòng điều khiển (CFG - Control Flow Graph). Đồ thị này biểu diễn các luồng điều khiển
của mã nguồn một cách chi tiết và trực quan nhất. Kĩ thuật này chủ yếu là làm việc trên đồ
thị CFG để sinh ca kiểm thử thay vì phải làm việc với một mã nguồn có cấu trúc phức tạp.
Quy trình kiểm thử tự động hộp trắng theo hướng tĩnh được mô tả như trong Hình 2.5. Đầu
tiên, đồ thị dòng điều khiển CFG được xây dựng ra từ mã nguồn và tiêu chí phủ đầu vào.
Sau đó, một tập các đường thi hành được xác định sao cho sau khi thực hiện chúng thì tiêu
chí phủ kiểm thử được thỏa mãn. Tiếp theo, các ca kiểm thử được sinh ra, mỗi ca kiểm thử
ứng với một đường thi hành. Cuối cùng, các ca kiểm thử được thực thi để thu được kết quả
kiểm thử.

8


Mã nguồn
Tiêu chí phủ

Xây dựng đồ thị
dòng điều khiển
Xây dựng tập
đường kiểm thử
Tìm tập ca kiểm
thử

Thực thi tập ca
kiểm thử
Kết thúc
Hình 2.5. Quy trình chung của kiểm thử tự động hộp trắng dòng điều khiển.

2.4. So sánh kiểm thử tự động hộp trắng dòng điều khiển theo hướng tĩnh và động
Hai kĩ thuật kiểm thử tự động hộp trắng dòng điều khiển theo hướng tĩnh và động đều
có những điểm mạnh vào điểm yếu riêng. Chúng có thể hỗ trợ cho nhau để sinh được những
ca kiểm thử tốt nhất. Sau đây, khóa luận sẽ đưa ra sự so sánh giữa hai kĩ thuật dựa theo
những tiêu chí cụ thể.
-

Về số ca kiểm thử: Kĩ thuật kiểm thử theo hướng động sẽ phải sinh ra nhiều ca kiểm
thử hơn so với theo hướng tính. Trong kĩ thuật kiểm thử theo hướng động, các đường
thi hành sẽ được sinh từng cái một từ đường thi hành trước đó nên khả năng trùng
lặp giữa các đường thi hành là rất cao. Hơn nữa, nếu có sự xuất hiện của vòng lặp,
số lần lặp khi thực thi bộ đầu vào càng nhiều, số lượng các ràng buộc sinh ra từ
đường thi hành sẽ càng lớn, dẫn đến số lượng đường thi hành mới có thể được sinh
ra từ đường thi hành này rất là nhiều. Nhìn chung, kĩ thuật kiểm thử theo hướng tĩnh
có số lượng đường thi hành và các ca kiểm thử để đạt được độ phủ tối đa là xác định

-

được, còn theo hướng động thì là chưa xác định được cụ thể trước khi kết thúc quá
trình kiểm thử.
Về thời gian kiểm thử: Thời gian sinh ca kiểm thử trong kĩ thuật kiểm thử theo hướng
động sẽ lâu hơn so với theo hướng tĩnh. Điều đó là do hai lí do. Thứ nhất, số lượng
ca kiểm thử cấn sinh ra khi sử dụng kĩ thuật kiểm thử theo hướng tĩnh là lớn hơn,
9

trong khi thời gian sinh mỗi ca kiểm thử của cả 2 kĩ thuật là tương đương nhau. Thứ

-

hai, với việc kiểm thử theo hướng động, mỗi lần sinh ra ca kiểm thử mới, chương
trình sẽ lại phải thực thi thêm một lần.
Khả năng kiểm thử vòng lặp: Kĩ thuật kiểm thử theo hướng tĩnh cho phép chúng ta
có thể kiểm thử từng vòng lặp một trong các vòng lặp lồng nhau với số lần lặp có
thể tùy ý. Trong khi đó, kĩ thuật kiểm thử theo hướng động chỉ hỗ trợ kiểm thử các

-

vòng lặp một cách đồng thời thay vì riêng rẽ, và số lần lặp là ngẫu nhiên, không xác
định theo ý muốn của người kiểm thử.
Tính phức tạp mã nguồn: Hiện nay, các mã nguồn ngày càng phức tạp và được viết
với nhiều quy tắc, phong cách lập trình khác nhau. Do đó, việc phân tích mã nguồn
trong kĩ thuật kiểm thử theo hướng tĩnh rất là khó khăn và còn có thể không phân
tích được. Nhưng kĩ thuật kiểm thử theo hướng động hoàn toàn có thể bỏ qua những
sự phức tạp đó. Nguyên nhân chính do kiểm thử theo hướng động tận dụng được thế
mạnh trình biên dịch để sinh ca kiểm thử mới. Kĩ thuật này không làm việc trực tiếp
với mã nguồn mà thông qua trình biên dịch nên nó có thể bỏ qua được độ phức tạp
mã nguồn để sinh các ca kiểm thử.

10


Phương pháp sinh ca kiểm thử tự động dòng điều khiển
cho các đơn vị của chương trình Java
3.1 Tổng quan về phương pháp kiểm thử đề xuất

Khóa luận đề xuất một phương pháp sinh ca kiểm thử tự động cho các đơn vị chương
trình Java. Phương pháp sử dụng kĩ thuật kiểm thử tự động hộp trắng dòng điều khiển theo
hướng tĩnh. Đầu vào bao gồm một hàm Java có chứa các biến số nguyên, số thực, các biến
mảng và tiêu chí phủ kiểm thử, số vòng lặp tối đa. Đầu ra là tập các ca kiểm thử đáp ứng
được tiêu chí phủ kiểm thử và tập các ca kiểm thử cho kiểm thử các vòng lặp.

Hình 3.1. Quy trình kiểm thử một hàm java theo phương pháp đề xuất.

Quy trình kiểm thử một hàm đơn vị Java được mô tả chi tiết trong Hình 3.1. Phương
pháp gồm những bước chính sau:
Bước 1.

Sinh đồ thị dòng điều khiển CFG bằng kĩ thuật phân tích mã nguồn hàm đầu
vào.
11