Phương pháp sinh dữ liệu kiểm thử tự động cho các ứng dụng java

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

PHAN THỊ THU HÀ

PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG
CHO CÁC ỨNG DỤNG JAVA

LUẬN VĂN THẠC SĨ
Ngành: Công nghệ thông tin

Hà Nội -2015


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

PHAN THỊ THU HÀ

PHƯƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG
CHO CÁC ỨNG DỤNG JAVA

Ngành: Công nghệ thông tin
Chuyên ngành: Kỹthuật phần mềm
Mã Số:60.48.01.03

LUẬN VĂN THẠC SĨ
NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. PHẠM NGỌC HÙNG

Hà Nội -2015

2


MỤC LỤC
MỤC LỤC ............................................................................................................................. i
LỜI CẢM ƠN ..................................................................................................................... iii
TÓM TẮT............................................................................................................................ iv
ABSTRACT ......................................................................................................................... v
LỜI CAM ĐOAN ................................................................................................................ vi
DANH MỤC THUẬT NGỮ VIẾT TẮT ...........................................................................vii
DANH MỤC HÌNH VẼ ................................................................................................... viii
DANH MỤC BẢNG ............................................................................................................ x
CHƯƠNG 1: GIỚI THIỆU .................................................................................................. 1
CHƯƠNG 2: CÁC KỸ THUẬT KIỂM THỬ DÒNG ĐIỀU KHIỂN ................................. 4
2.1. Tổng quan về kiểm thử hộp trắng ............................................................................. 4
2.2. Kỹ thuật kiểm thử dòng điều khiển ......................................................................... 10
2.2.1. Kiểm thử hộp trắng dòng điều khiển theo hướng động ................................... 10
2.2.2. Kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh ..................................... 12
2.3. Quy trình kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh .............................. 7
2.3.1. Đồ thị dòng điều khiển ...................................................................................... 7
2.3.2. Các tiêu chí phủ kiểm thử .................................................................................. 9
2.3.3. Đường kiểm thử ............................................................................................... 10
2.4. So sánh kĩ thuật kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh và động .... 10

2.5. Tầm quan trọng của tự động hóa quy trình kiểm thử hộp trắng dòng điều khiểnError! Book
CHƯƠNG 3: PHƯƠNG PHÁP KIỂM THỬ DÒNG ĐIỀU KHIỂN HƯỚNG TĨNH
CHO CÁC HÀM JAVA ..................................................................................................... 15
3.1. Ý tưởng.................................................................................................................... 15
3.2. Xây dựng đồ thị dòng điều khiển từ mã nguồn....................................................... 16
3.3. Xây dựng tập đường kiểm thử ................................................................................ 20

3.3.1. Xây dựng tập đường đi độc lập........................................................................ 20
3.3.2. Xây dựng đường kiểm thử vòng lặp ................................................................ 22
i


3.4. Xây dựng hệ ràng buộc ........................................................................................... 25
3.5. Sinh tập dữ liệu kiểm thử dựa trên giải nghiệm hệ ràng buộc ................................ 27
3.5.1. Giải hệ sử dụng kỹ thuật sinh ngẫu nhiên........................................................ 27
3.5.2. Giải hệ sử dụng SMT-Solver ........................................................................... 27
CHƯƠNG 4: GIỚI THIỆU CÔNG CỤ ............................................................................. 32
4.1. Kiến trúc công cụ .................................................................................................... 32
4.2. Nền tảng chương trình............................................................................................. 33
4.2.1. Thư viện JDT ................................................................................................... 33
4.2.2. Bộ giải hệ Z3 Prover ........................................................................................ 34
4.3. Cài đặt công cụ ........................................................................................................ 36
4.3.1. Tổng quan ........................................................................................................ 36
4.2.2. Đầu vào công cụ JavaUnitCFT ........................................................................ 36
4.2.3. Đầu ra công cụ ................................................................................................. 37
CHƯƠNG 5: THỰC NGHIỆM.......................................................................................... 42
5.1. Sinh bộ dữ liệu kiểm thử cho hàm đầu vào chứa biến số nguyên ........................... 42
5.1.1. Input ................................................................................................................. 42
5.1.2. Output: ............................................................................................................. 43
5.2. Sinh bộ dữ liệu kiểm thử cho hàm đầu vào chứa biến số thực ............................... 44
5.2.1. Input ................................................................................................................. 44
5.2.2. Output .............................................................................................................. 44
5.3. Sinh bộ dữ liệu kiểm thử cho hàm đầu vào chứa vòng lặp ..................................... 47
5.3.1. Input ................................................................................................................. 47
5.3.2. Output .............................................................................................................. 47
CHƯƠNG 6: KẾT LUẬN .................................................................................................. 49
TÀI LIỆU THAM KHẢO .................................................................................................. 50

ii


LỜI CẢM ƠN
Trước tiên tôi xin gửi lời cảm ơn chân thành và sâu sắc đến thầy giáo, TS. Phạm
Ngọc Hùng - người đã trực tiếp hướng dẫn, chỉ bảo, động viên, luôn tạo cho tôi những
điều kiện tốt nhấtvà truyền cho tôi cảm hứng nghiên cứu khoa học từ khi tôi bắt đầu
lựa chọn đề tài, trong suốt quá trình nghiên cứu, và cho đến bây giờ - khi tôiđã hoàn
thành luận văn này.
Tôi xin chân thành cảm ơn các thầy, cô giáo khoa Công Nghệ Thông Tin,
Trường Đại học Công nghệ, Đại học Quốc Gia Hà Nội - những người đầy tâm huyết,
đã tận tình đào tạo,cung cấp cho tôi những kiến thức chuyên môn vô cùng quý
giá.Những kiến thức ấy không chỉ tạo cho tôi một nền tảng tốt trong quá trình học tập,
nghiên cứu tại trường, mà sẽ còn là những bài học bổ ích, những kỹ năng và kinh
nghiệm đáng quý cho tôi trong suốt quá trình làm việc và nghiên cứu chuyên môn sau
này.
Cuối cùng, tôi xin chân thành cảm ơn những người thân trong gia đình và bạn bè,
đồng nghiệp đã luôn giúp đỡ, động viên tôi đặc biệt là những khi tôi gặp phải khó khăn
trong việc học tập và nghiên cứu, đã tiếp thêm động lực để tôi vững tâm hoàn thành
luận văn này.

iii


TÓM TẮT
Kiểm thử đơn vị là bước đầu tiên trong quy trình kiểm thử phần mềm. Hiện nay,
trong các công ty phần mềm, kiểm thử đơn vị thường được thực hiện bởi các lập trình
viên sau khi hoàn thành việc phát triễn mã nguồn sản phẩm, và trước khi bàn giao cho
bộ phận kiểm thử để tiến hành kiểm thử tích hợp. Do hạn chế về mặt thời gian, chi phí

và nguồn nhân lực, các lập trình viên thường chỉ sử dụng kỹ thuật kiểm thử hộp đen
mà không áp dụng các kỹ thuật kiểm thử hộp trắng khi tiến hành kiểm thử đơn vị. Kết
quả là các lỗi tiềm tàng trong mã nguồn sản phẩm hầu như không được phát hiện trước
khi việc kiểm thử tích hợp được thực hiện.
Luận văn này tập trung nghiên cứu phương pháp sinh dữ liệu kiểm thử tự động
cho các ứng dụng Java dựa trên kỹ thuật kiểm thử hộp trắng dòng điều khiển hướng
tĩnh, đồng thời cài đặt một công cụ(JavaUnitCFT)hỗ trợ cho phương pháp này.
Phương pháp được mô tả thành một quy trình với các bước chính như sau: Bước đầu
tiên, từ mã nguồn được cung cấp, ta sẽ phân tích để sinh đồ thị dòng điều khiển thỏa
mãn tiêu chí phủ kiểm thử. Sau đó, đồ thị dòng điều khiển được phân tích để xây dựng
tập đường kiểm thử. Bước tiếp theo, các đường kiểm thử chứa vòng lặp được cấu trúc
lại để sinh thêm các đường kiểm thử mới dùng kiểm thử tính đúng đắn vòng lặp. Dựa
trên tập các đường kiểm thử, ta xây dựng các hệ ràng buộc tương ứng. Cuối cùng, ta
thực hiện giải hệ ràng buộc thu được để sinh tập dữ liệu cho bộ cácca kiểm thử bằng
cách sử dụng thế mạnh của các công cụ SMT-Solver.
Một công cụ hỗ trợ phương pháp này cũng được cài đặt bằng ngôn ngữ lập trình
Java để chứng minh tính đúng đắn và khả năng ứng dụng trong thực tế của phương
pháp. Kết quả thực nghiệm cho thấy, tậpdữ liệu cho bộ ca kiểm thử sinh ra một cách tự
động với số lượng tối thiểu nhưng vẫn đảm bảo đạt độ bao phủ cao, đạt độ tin cậy cao
trong kiểm chứng tính đúng đắn của mã nguồn.
Từ khóa:Kiểm thử tự động, kiểm thử hộp trắng dòng điều khiển, đồ thị dòng điều
khiển,kiểm thử vòng lặp, độ phủ,ca kiểm thử

iv


ABSTRACT
Testingphase has lot of significance in Software Development Life Cycle
(SDLC) due to it is the most important part in executing and fault rectification.
Because of high demand in quality, testing phase is performed quite thoroughly and

strictly. As a result, the cost of the testing phase can be up to 40% - 60% the total cost
of application development process.
To reduce the cost of the testing phase, not only the testing execution phase but
also the test case generation process should be automated as much as possible.
However, some automation testing tools just focus on executing test cases and return
the testing report instead of generating test cases automatically.
The Thesis researches a method of generating a set of test cases automatically for
Java applications based on the static white-box technique. Input by source code of the
application under test and coverage criteria, the output of this method is a minimal set
of test cases which can satisfy the provided criteria and reach the maximum coverage
level. The proposed method processes as following: Firstly, the source code is required
to be analysed in order to generate corresponding Control Flow Graph (CFG). Based
on the CFG, independent paths will be built. After that, paths containing loop is reconstructed to generatesome new paths used to test the loop. Then, each path is
analysed by using symbolic execution technique to create corresponding constraints.
Finally, the constraints aresolved to find solutions by SMT-Solver tools. A set of test
data for the test cases is generated automatically. The experimental result shows the
effectiveness of the approach with the set of test data for the minimum number of test
cases but ensures the high quality of source code.
Keywords:Automated testing, white-box testing technique, control flow testing,
test case, coverage criteria

v


LỜI CAM ĐOAN
Tôi xin cam đoan rằng luận văn thạc sĩ công nghệ thông tin “Phương pháp sinh
dữ liệu kiểm thử tự động cho các ứng dụng Java” là nghiên cứu của riêng tôi,
không sao chép lại của người khác. Trong toàn bộ nội dung của luận văn, những điều
đã được trình bày hoặc là của chính cá nhân tôi hoặc là được tổng hợp từ nhiều nguồn
tài liệu. Tất cả các nguồn tài liệu tham khảo đều có xuất xứ rõ ràng và hợp pháp.

Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định
cho lời cam đoan này.
Hà Nội, ngàythángnăm 2015

Phan Thị Thu Hà

vi


DANH MỤC THUẬT NGỮ VIẾT TẮT
STT

Từ viết tắt

Từ đầy đủ

Ý nghĩa

1

AST

Abstract Syntax Tree

Cây cú pháp trừu tượng

2

CFG

Control Flow Graph

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

3

JDT

Java Development Tools

Bộ công cụ lập trình của
ngôn ngữ lập trình Java

4

CVC

Cooperating Validity Checker

5

DIMACS

Center for Discrete Mathematics
and Theoretical Computer Science

6

SMT-Solver Satisfiability
Solver

Modulo

vii

Theories


DANH MỤC HÌNH VẼ
Hình 1.1. Top 10 ngôn ngữ lập trình phổ biến giai đoạn 2002-2015 .............................. 3
Hình 2.1. Đảm bảo chất lượng phần mềm theo từng pha ................................................6
Hình 2.2. Chi phí cho việc tìm và sửa lỗi ........................................................................7
Hình 2.3. Các thành phần cơ bản của đồ thị dòng điều khiển .........................................8
Hình 2.4. Các cấu trúc điều khiển phổ biến ....................................................................9
Hình 2.5. Kiểm thử hộp trắng dòng điều khiển theo hướng động................................. 11
Hình 2.6. Ví dụ một luật chèn mã nguồn trong DMS/SRT ...........................................12
Hình 2.7. Mã nguồn hàm triangle sau khi thêm khối mã nguồn mới ............................ 12
Hình 2.8. Kiểm thử hộp trắngdòng điều khiển theo hướng tĩnh ...................................13
Hình 3.1. Quy trình kiểm thử một hàm Java theo phương pháp nghiên cứu ................15
Hình 3.2. Thuật toán sinh CFG từ mã nguồn. ............................................................... 17
Hình 3.3. Mã nguồn hàm kiemTraNamNhuan. ............................................................. 18
Hình 3.4. CFG hàm kiemTraNamNhuan tiêu chuẩn phủ câu lệnh, phủ nhánh ............18
Hình 3.5. CFG hàm kiemTraNamNhuan tiêu chuẩn phủ điều kiện con ....................... 19
Hình 3.6. CFG điều kiện kép (a>=0 || ((b>=0 && c>=0) || b+c>=0) || a+b+c>=0) ......20
Hình 3.7. Thuật toán sinh tập đường đi độc lập từ CFG ...............................................21
Hình 3.8. Thuật toán sinh đường kiểm thử vòng lặp. ....................................................23
Hình 3.9. Thuật toán sinh đường kiểm thử vòng lặp trong. ..........................................24
Hình 3.10. Thuật toán sinh đường kiểm thử vòng lặp ngoài. ........................................25
Hình 3.11. Ví dụ một hệ ràng buộc. ..............................................................................25
Hình 3.12. Thuật toán sinh hệ ràng buộc từ đường kiểm thử........................................26

Hình 3.13. Quá trình rút gọn câu lệnh. ..........................................................................27
Hình 3.14. Mô tả đầu vào, đầu ra SMT-Solver. ............................................................ 29
Hình 3.15. Ví dụ hệ ràng buộc tuân theo chuẩn SMT-Lib. ...........................................30
Hình 3.16. Quá trình chuyển một biểu thức trung tố về chuẩn SMT-Lib. ....................31
Hình 4.1. Kiến trúc chương trình JavaUnitCFT ............................................................ 32
Hình 4.2. Ví dụ minh họa AST...................................................................................... 33
Hình 4.3. Sử dụng ASTView trong Eclipse trên đoạn mã nguồn “test” ....................... 34
Hình 4.4. Cây AST của mã nguồn class “test” .............................................................. 35
viii


Hình 4.5. Minh họa cho Z3 Solver ................................................................................35
Hình 4.6. Giao diện công cụ JavaUnitCFT. ..................................................................36
Hình 4.7. Ví dụ đầu vào công cụ JavaUnitCFT. ........................................................... 37
Hình 4.8. Đồ thị CFG thỏa mãn tiêu chí phủ câu lệnh và phủ nhánh trên công cụ.......37
Hình 4.9. Chi tiết đồ thị CFG thỏa mãn tiêu chí phủ câu lệnh và phủ nhánh ...............38
Hình 4.10. Đồ thị CFG thỏa mãn tiêu chí phủ điều kiện con trên công cụ ...................38
Hình 4.11. Chi tiết đồ thị CFG thỏa mãn tiêu chí phủ điều kiện con ............................ 39
Hình 4.12. Đường đi tương ứng với một đường kiểm thử trên CFG trên công cụ .......39
Hình 4.13. Đường đi tương ứng với một đường kiểm thử trên CFG ............................ 40
Hình 4.14. Tập đường kiểm thử thỏa mãn phủ câu lệnh hàm KiemTraNamNhuan .....40
Hình 4.15. Tập đường kiểm thử thỏa mãn phủ nhánh hàm KiemTraNamNhuan .........41
Hình 4.16. Tập đường kiểm thử thỏa mãn phủ điều kiện con hàm KiemTraNamNhuan
.......................................................................................................................................41
Hình 4.17. Tập tất cả các đường đi độc lập. ..................................................................41
Hình 4.18. Ca kiểm thử thỏa mãn độ phủ nhánh của hàm KiemTraNamNhuan ..........41
Hình 5.1. CFG thỏa mãn điều kiện phủ cấp 1,2,3 hàm UocChungLonNhat.................43
Hình 5.2. Tập dữ liệu liệu kiểm thử cho bộ ca kiểm thử thỏa mãn độ phủ cấp 1,2,3 hàm
UocChungLonNhat........................................................................................................43
Hình 5.3. CFG thỏa mãn phủ cấp 1, 2 của hàm PhanLoaiDiemHocTap .....................45

Hình 5.4. Tập dữ liệu liệu kiểm thử cho bộ ca kiểm thử thỏa mãn độ phủ cấp 1,2 hàm
PhanLoaiDiemHocTap ..................................................................................................45
Hình 5.5. CFG thỏa mãn phủ cấp 3 của hàm PhanLoaiDiemHocTap ......................... 46
Hình 5.6. Tập dữ liệu liệu kiểm thử cho bộ ca kiểm thử thỏa mãn độ phủ cấp 3 hàm
PhanLoaiDiemHocTap ..................................................................................................46
Hình 5.7. CFG thỏa mãn phủ cấp 1 của hàm loopDoWhile ..........................................48
Hình 5.8. Kiểm thử vòng lặp cho hàm loopDoWhile với số lần lặp tối đa n=6............48
Hình 5.9. Tập dữ liệu liệu kiểm thử cho bộ ca kiểm thử vòng lặp cho hàm
loopDoWhile với số lần lặp tối đa n=6 .........................................................................48

ix


DANH MỤC BẢNG
Bảng 5.1. Môi trường thử nghiệm công cụ sinh ca kiểm thử từ thiết kế....................... 42
Bảng 5.2. Đầu vào hàm UocChungLonNhat chứa biến số nguyên ............................... 43
Bảng 5.3. Đầu vào hàm PhanLoaiDiemHocTap chứa biến số thực .............................. 44
Bảng 5.4. Đầu vào hàm loopDoWhile chứa vòng lặp ...................................................47

x


CHƯƠNG1: GIỚI THIỆU
Trong bối cảnh ngành công nghiệp phần mềm hiện nay, kiểm thử là một quá trình
rất tốn thời gian, công sức và chi phí có thể chiếm 40% – 60% tổng chi phí trong toàn
bộ quá trình phát triển phần mềm [3].Thêm vào đó, độ phức tạp mã nguồn của các
phần mềm ngày càng tăng khiến khối lượng mã nguồn cần kiểm thử không chỉ tăng
lên mà còn khó phân tích hơn rất nhiều. Tiến hành kiểm thử sản phẩm càng sớm càng
tốt, tăng năng suất kiểm thử càng nhiều càng tốt đang thực sự là một nhu cầu thiết yếu
để tăng chất lượng phần mềm.

Bản thântôi - hiện đang công tác trong lĩnh vực đảm bảo chất lượng phần mềm nhận thấy rằng quy trình phát triển phần mềm ngày càng trở nên linh hoạt hơn, kiểm
thử phần mềm dần được tiến hành sớm ngay từ những pha đầu tiên khi dự án được
khởi tạo. Không chỉ kiểm thử thủ công (manual test) mà kiểm thử tự động (automation
test) cũng đang được áp dụng rất rộng rãi trong nhiều công ty, đặc biệt là các công ty
lớn trong thị trường phần mềm của Việt Nam (FPT Software, Vietel, HaveyNash,
eXoPlatform, Niteco, v.v.). Việc này giúp các doanh nghiệp vừa đảm bảo được việc
duy trì, cải tiến chất lượng của phần mềm để đáp ứng nhu cầu ngày càng cao hơn từ
phía khách hàng, vừa đảm bảo giải quyết được bài toán về chi phí phát triển phần mềm
một cách hiệu quả.
Một số lợi ích có thể kể đến của kiểm thử tự động như: cải thiện hiệu quả công
việc, cải thiện độ chính xác của việc kiểm thử, cải thiện chất lượng kiểm thử và chất
lượng sản phẩm phần mềm, v.v. Về cải thiện hiệu quả, dễ dàng nhận thấy rằng ta có
thể thực hiện được việc kiểm thử tại mọi thời điểm (bất kể ngày hay đêm, có người
hay không có người). Sự cải thiện về độ chính xác của kiểm thử thể hiện ở việc các ca
kiểm thử tự động luôn luôn được thực hiện một cách chính xác từng bước một theo
đúng trình tự đã định nghĩa, dù ta có tiến hành việc kiểm thử lặp đi lặp lại bao nhiêu
lần đi chăng nữa. Việc này rất có ý nghĩa trong việc tái tạo lại lỗi phần mềm. Khi một
lỗi được tìm thấy bằng kiểm thử tự động, nó có thể được tái tạo dễ dàng bằng cách đơn
giản là thực hiện lại đúng ca kiểm thử đã được định nghĩa.Sau cùng, kiểm thử không
bao giờ là đủ. Không thể thực hiện toàn bộ các ca kiểm thử bằng kiểm thử thủ công.
Kiểm thử tự động giúp ta thực hiện được một khối lượng các ca kiểm thử lớn hơn rất
nhiều trong một khoảng thời gian ngắn so với kiểm thử thủ công.Lượng ca kiểm thử
được thực hiện tăng lên sẽ giúp giảm thiểu các lỗi tiềm ẩn của sản phẩm mà nếu chỉ
thực hiện kiểm thử thủ công ta không thể kiểm soát được hết, giúp tăng chất lượng
kiểm thử, đồng thời tăng chất lượng sản phẩm phần mềm.
Tại FPT Software, việc kiểm thử phần mềm được tiến hành từ rất sớm trong quy
trình phát triển phần mềm. Ngay khi người lập trình viên hoàn thành từng đơn vị phần
mềm (unit) họ sẽ tiến hành kiểm thử đơn vị (unit test) cho đơn vị phần mềm đó. Khi
kiểm thử đơn vị hoàn thành cho từng đơn vị phần mềm, lập trình viên hoặc quản lý dự
1

án sẽ tiến hành đóng gói từng phần (module) phần mềm và chuyển cho bộ phận đảm
bảo chất lượng phần mềm để tiến hành các bước tiếp theo của quy trình kiểm thử:
kiểm thử tích hợp (intergration test), kiểm thử hệ thống (system test), và kiểm thử chấp
nhận (acceptance test).
Tuy nhiên, việc kiểm soát thực hiện kiểm thử đơn vịcòn một số hạn chế như
sau:Thứ nhất, kiểm thử đơn vị phần lớn thường được thực hiện bởi các lập trình viên
sau khi hoàn thành mã nguồn sản phẩm nên tính khách quan chưa cao. Thứ hai, họ
thường chỉ áp dụng kỹ thuật kiểm thử hộp đen mà không áp dụng các kỹ thuật kiểm
thử hộp trắng để thực hiện kiểm thử đơn vị do không có đủ chi phí về thời gian, nhân
lực.Kết quả là các lỗi tiềm tàng trong mã nguồn sản phẩm hầu như không được phát
hiện trước khi việc kiểm thử tích hợp được thực hiện. Cuối cùng, tuy có áp dụng các
kỹ thuật kiểm thử tự động trong quy trình kiểm thử đơn vị nhưng việc tự động hóa này
chỉ diễn ra trong khâu thực thi ca kiểm thử nên chi phí về thời gian và nguồn nhân lực
chưa thực sự được cải thiện đáng kể.
Trong các dự án hiện tại tôi đang tham gia (thuộc đơn vị chiến lược phần mềm
FSOFT-FSU.Z8 - khách hàng DirecTV - Công ty truyền hình vệ tinh hàng đầu của
Mỹ), ngôn ngữ lập trình được sử dụng chủ yếu ngôn ngữ Java.Ngoài ra,Java là ngôn
ngữ lập trìnhthuộc top 3 các ngôn ngữ lập trình phổ biến trong suốt 13 năm trở lại đây
(2002-2015) theo thống kê của TIOBE1 (hình 1.1), và hiện đang giữ vị trí ngôn ngữ
lập trình số mộtcủa năm (2015)theo báo cáo mới nhất của tổ chức này vào tháng 12
năm 2015.
Đây chính là lý do tại sao tôi lựa chọn đề tài “Phương pháp sinh dữ liệu kiểm
thử tự động cho các ứng dụng Java” cho nghiên cứu của mình. Tư tưởng của
phương pháp được kế thừa từ nghiên cứu về “Xây dựng công cụ kiểm thử tự động cho
các chương trình C” của Nguyễn Đức Anh, khóa luận tốt nghiệp Trường Đại học Công
Nghệ, Đại học Quốc Gia Hà Nội, 2015 [2].
Trong nghiên cứu của mình, Đức Anh đề xuất một phương pháp sinh ca kiểm thử
tự động cho một hàm C chứa các biến số nguyên, số thực và biến mảng sử dụng kĩ

thuật kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh và cài đặt một công cụ hỗ
trợ cho phương pháp được đề xuất. Đầu vào gồm một hàm C và tiêu chí phủ kiểm thử.
Đầu ra là một tập các ca kiểm thử thỏa mãn tiêu chí phủ kiểm thử và tập ca kiểm thử
để kiểm thử vòng lặp (nếu hàm C có vòng lặp).

1

Tiêu chí đánh giá tính phổ biến ngôn ngữ lập trình dựa trên số kết quả tìm kiếm trả về khi truy vấn tên
ngôn ngữ lập trình trên các trên mạng nổi tiếng gồm Google, Google Blogs, MSN, Yahoo, Baidu, Wikipedia và
Youtube: />
2


Hình 1.1. Top 10 ngôn ngữ lập trình phổ biến giai đoạn 2002-2015
Kế thừa kết quả đó, tôi đã thực hiện nghiên cứu của mình trên các chương trình
Java, nhằm tìm ra phương pháp phân tích mã nguồn của các hàm Java, sinh đồ thị
dòng điều khiển, từ đó sinh tập các đường kiểm thử. Khi đã có được tập các đường
kiểm thử, tôi áp dụng kết quả trong nghiên cứu của Đức Anh – sử dụng kỹ thuật thực
thi tượng trưng (SE) để sinh hệ ràng buộc, sau đó giải hệ ràng buộc bằng Z3 - một
công cụ SMT-Solver để thu được tập các dữ liệu kiểm thử thỏa mãn tiêu chí phủ kiểm
thử một cách tự động. Đồng thời,tôi đã xây dựng một công cụ dựa theo phương pháp
đã nghiên cứu để chứng minh tính đúng đắn và khả năng áp dụng trong thực tiễn của
phương pháp này.
Phần còn lại của luận văn này được trình bày theo cấu trúc sau. Các kỹ thuật kiểm
thử hộp trắng được trình bày tại chương 2. Tiếp theo, ở chương 3, luận văn trình bày
phương pháp kiểm thử tự động hàm Java sử dụng kỹ thuật kiểm thử hộp trắng dòng
điều khiển hướng tĩnh. Kiến trúc của công cụ xây dựng nhằm chứng minh tính đúng
đắn của phương pháp nghiên cứu được trình bày trong chương 4. Quá trình và kết quả
thực nghiệm sẽ được trình bày trong chương 5. Cuối cùng, chương 6 trình bày kết luận
về phương pháp đã nghiên cứu, ưu nhược điểmvà hướng nghiên cứu tiếp theo.

3


CHƯƠNG 2: CÁC KỸ THUẬT KIỂM THỬ DÒNG
ĐIỀU KHIỂN
Có rất nhiều kỹ thuật để sinh các ca kiểm thử cho một ứng dụng hoặc chương
trình. Trong số đó, bằng việc phân loại theo đầu vào của từng kỹ thuật, người ta định
nghĩa ba loại kỹ thuật như sau [4]: Kỹ thuật kiểm thử dựa trên đặc tả (Specificationbased, hay còn gọi là kiểm thử hàm, kiểm thử hộp đen), Kỹ thuật kiểm thử dựa trên mã
nguồn và cấu trúc chương trình (Structure-based, hay còn gọi là kiểm thử hộp trắng),
và Kỹ thuật kiểm thử dựa trên kinh nghiệm của người kiểm thử viên (Experiencebased).
Kỹ thuật dựa trên đặc tả hay còn gọi là kiểm thửhàm (kiểm thử hộp đen) coi phần
mềm như một hộp đen. Kiểm thử viên hoàn toàn không quan tâm đến cấu trúc, hành vi
bên trong phần mềm mà chỉ quan tâm đến việc tìm ra các lỗi mà phần mềm không
thực hiện đúng như đặc tả. Vì thế việc tạo các dữ liệu kiểm thử sẽ xuất phát từ đặc tả.
Kỹ thuật dựa trên mã nguồn và cấu trúc chương trình hay còn gọi là kiểm thử
hộp trắng cho phép ta kiểm tra cấu trúc bên trong chương trình với mục đích đảm bảo
rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần. Trong kỹ thuật
kiểm thử hộp trắng, dữ liệu kiểm thử xuất phát từ việcphân tích mã nguồn chương
trình.
Trong kỹ thuật kiểm thử dựa trên kinh nghiệm của người kiểm thử viên, nền tảng
kỹ năng và kiến thức chuyên môn nghiệp vụ của người kiểm thử là điều quan trọng
nhất. Điều này giúp người kiểm thử có cái nhìn tổng quát về ứng dụng mà đội dự án
đang phát triển, so sánh được với một số các ứng dụng tương tự trên thị trường, từ đó
mang lại nhiều quan điểm khác nhau trong việc phân tích và đảm bảo chất lượng cho
quá trình thiết kế cũng như quá trình cài đặt thiết kế đó. Do đã có kinh nghiệm với một
số các hệ thống tương tự khác mà họ đã từng tham gia, họ có thể dự doán được một số
lỗi hay mắc phải, hoặc những lỗi tiềm ẩn khác mà một người ít kinh nghiệm có thể
không dự đoán được.
Ở chương này, luận văn sẽ trình bày tổng quan về kỹ thuật kiểm thử hộp trắng,

cụ thể là kỹ thuật kiểm thử hộp trắng dòng diều khiển (gọi tắt là kiểm thử dòng điều
khiển). Đồng thời, chương này cũng sẽ trình bày 2 kỹ thuật chính của kiểm thửdòng
điều khiển là kỹ thuật tĩnh và kỹ thuật động, và đưa ra ưu, nhược điểm của 2 kỹ thuật
này.

2.1.Tổng quan về kiểm thử hộp trắng
Như trên đã trình bày, kiểm thử hộp trắng là kỹ thuật kiểm thử với đầu vào là mã
nguồn và cấu trúc chương trình. Kiểm thử hộp trắng sẽ dựa vào thuật giải cụ thể, các

4


cấu trúc dữ liệu bên trong của đơn vị phần mềm cần kiểm thử để xác định đơn vị phần
mềm đó có thực hiện đúng các tính năng được mô tả trong đặc tả hay không [1].
Khác với kỹ thuật kiểm thử hộp đen - chỉ cho phép phát hiện các lỗi (khiếm
khuyết) có thể quan sát được của phần mềm, kiểm thử hộp trắng giúp ta phát hiện
được các lỗi tiềm ẩn bên trong từng đơn vị của chương trình phần mềm. Để thực hiện
kỹ thuật hộp trắng, người kiểm thử viên phải có kỹ năng, kiến thức nhất định về ngôn
ngữ lập trình, về cấu trúc dữ liệu và thuật giải, để có thể thông hiểu chi tiết về từng
đơn vị mã nguồn của chương trình, hay ứng dụng cần kiểm thử. Chính vì vậy, trong
thực tế của ngành công nghiệp phần mềm hiện nay - các chương trình, ứng dụng đều
có kích thước rất lớn, phương pháp kiểm thử hộp trắng tốn rất nhiều công sức để thực
hiện - nên kiểm thử hộp trắng chủ yếu được sử dụng trong kiểm thử đơn vị.Trong lập
trình hướng đối tượng, kiểm thử đơn vị là chính là kiểm thử từng tác vụ của mộtlớp
(class) chức năng nào đó.
Hai phương pháp được sử dụng trong kiểm thử hộp trắng là kiểm thử dòng điều
khiển (Control Flow Testing - CFT) và kiểm thử dòng dữ liệu (Data Flow Testing DFT). Trong khi phương pháp kiểm thử dòng điều khiển tập trung kiểm thử tính đúng
đắn của các giải thuật sử dụng trong các đơn vị, hoặc chương trình phần mềm, thì
phương pháp kiểm thử dòng dữ liệu tập trung kiểm thử tính đúng đắn của việc sử dụng
các biến dữ liệu trong đơn vị, chương trình phần mềm.

Trong khuôn khổ của luận văn này, chương này tôi sẽ trình bày chi tiết về
phương pháp kiểm thử hộp trắng dòng điều khiển (kiểm thử dòng điều khiển) mà tôi
đã nghiên cứu được.

2.2. Tầm quan trọng của tự động hóa quy trình kiểm thử
hộp trắng
Đảm bảo chất lượng phần mềm luôn luôn là vấn đề rất được quan tâm trong
ngành công nghiệp phần mềm. Đây không phải là nhiệm vụ của riêng mỗi pha kiểm
thử, chỉ cần được tiến hành ở pha kiểm thử, mà nên được tiến hành càng sớm càng tốt
ngay từ những pha đầu tiên của quy trình phát triển phần mềm.
Hình 2.1 cho ta một sự so sánh tương quan về việc đảm bảo chất lượng phần
mềm phụ thuộc vào việc đảm bảo chất lượng của từng pha trong toàn bộ quy trình phát
triển phần mềm như thế nào. Từ việc đảm bảo đặc tả đúng, đảm bảo thiết kế đúng và
hợp lý, ta hoàn toàn có thể tin tưởng rằng sẽ bàn giao một phần mềm với các yêu cầu
chức năng và phi chức năng đúng theo đặc tả và nhu cầu của khách hàng nếu ta đảm
bảo mã nguồn được thực thi đúng theo thiết kế. Ngược lại, bất kì một pha nào có chất
lượng không tốt đều sẽ dẫn đến việc chất lượng phần mềm không tốt, chưa kể có thể sẽ
phải làm lại toàn bộ phần mềm từ pha định nghĩa, phân tích đặc tả (như trong trường
hợp cuối cùng).
5


Chất lượng Đặc Tả
được đảm bảo

Chất lượng Đặc Tả
được đảm bảo

Chất lượng Đặc Tả
được đảm bảo

Chất lượng Đặc
Tả không được
đảm bảo

Chất lượng Thiết
Kế được đảm bảo
đúng và hợp lý dựa
trên đặc tả

Chất lượng Thiết
Kế được đảm bảo
đúng và hợp lý dựa
trên đặc tả

Chất lượng
Thiết Kế
không được
đảm bảo

Chất lượng Thiết
Kế không được
đảm bảo

Chất lượng
của mã
nguồn không
đảm bảo

Chất lượng

của mã nguồn
không đảm bảo

Chất
lượng
Phần Mềm
không được
đảm bảo

Chất lượng
Phần Mềm
không được
đảm bảo

Chất lượng
Phần Mềm không
được đảm bảo

Phải viết lại một
phần hoặc toàn bộ
mã nguồn để đảm
bảo chất lượng phần
mềm đúng như đặc tả

Phải thiết kế và viết
lại toàn bộ mã
nguồn để đảm bảo
chất lượng phần mềm
đúng như đặc tả

Phải phân tích lại đặc tả,
làm lại thiết kế và viết lại
toàn bộ mã nguồn để đảm
bảo chất lượng phần mềm
đúng như nhu cầu của
khách hàng

Chất lượng Mã
Nguồn sản phẩm
được đảm bảo đúng
theo thiết kế

Chất lượng Phần
Mềm bàn giao cho
khách hàng được
đảm bảo đúng như
đặc tả
Các thuộc tính
năng và phi
năng được thể
đúng trong
mềm

chức
chức
hiện
phần

Chất
lượng

của mã
nguồn không
đảm bảo

Hình 2.1. Đảm bảo chất lượng phần mềm theo từng pha
Các nghiên cứu đã chỉ ra rằng chi phí để tìm vàsửa lỗi tăng lên đáng kể trong
suốt vòng đời của chu trình phát triển phần mềm. Biểu đồ trong hình 2.2 mô tả về mối
liên hệ giữa chi phí tìm và sửa lỗi và pha tìm ra lỗi đó. Lỗi tìm ra càng muộn, chi phí
để sửa lỗi càng cao, chất lượng sản phẩm càng có nguy cơ không được đảm bảo đúng
như đặc tả hoặc thiết kế.
Các thống kê cho thấy chi phí pha kiểm thử có thể chiếm tới 40%-60% tổng chi
phí phát triển dự án phần mềm [3]. Các phần mềm hệ thống, phần mềm doanh nghiệp,
v.v. đều đòi hỏi chất lượng cao nên pha kiểm thử luôn được chú trọng và không thể bỏ
qua. Hơn nữa, mỗi khi phần mềm được nâng cấp thì quá trình kiểm thử được tiến hành
lại dẫn đến chi phí đã cao nay càng cao hơn.

6


CHI PHÍ TÌM VÀ
SỬA LỖI

Để giảm thiểu chi phí này, kiểm thử cần được áp dụng càng sớm càng tốt trong
quy trình phát triển phần mềm. Đó là việc kiểm chứng tính đúng đắn của đặc tả, kiểm
chứng tính đúng đắn của thiết kế, v.v. Một cách hiệu quả khác đó là áp dụng kiểm thử
tự động vào quy trình kiểm thử, mà ở đây là kiểm thử hộp trắng dòng điều khiển như
trong khuôn khổ nghiên cứu của luận văn này.

Chi phí tìm và sửa lỗi tăng đáng kể
trong suốt quy trình phát triển phần

mềm

THỜI GIAN
Đặc tả

Thiết kế Viết mã nguồn Kiểm thử Sử dụng

Hình 2.2. Chi phí cho việc tìm và sửa lỗi
Ý nghĩa của việc tự động hóa quy trình kiểm thử hộp trắng dòng điều khiển gồm
hai ý chính:
 Thời gian sinh ca kiểm thử tự động nhanh, đảm bảo chất lượng ca kiểm
thử và đảm bảo độ phủ cao.
Thời gian sinh ca kiểm thử bằng tay khá lâu và dễ dẫn đến sai sót. Nguyên nhân
chính phụ thuộc vào trình độ chuyên môn của kiểm thử viên, độ phức tạp mã
nguồn và chịu áp lực bởi môi trường làm việc.
 Giảm chi phí về thời gian và nhân lực cho nhà sản xuất.
Chi phí về nguồn nhân lực cho pha kiểm thử khá tốn kém. Muốn đảm bảo chất
lượng phần mềm (đặc biệt với dự án lớn) thì chi phí nguồn nhân lực càng cao. Do đó,
vấn đề quản lí khối lượng nguồn nhân lực trở nên phức tạp và rắc rối.

2.3.Các thuật ngữ sử dụng trong kiểm thử hộp trắng dòng
điều khiển
2.3.1.Đồ thị dòng điều khiển
Phương pháp kiểm thử dòng điều khiển dựa trên khái niệm đồ thị dòng điều
khiển (Control Flow Graph - CFG). Đồ thị này được xây dựng từ mã nguồn của
chương trình/đơn vị chương trình. CFG là một đồ thị có hướng gồm các đỉnh tương
7


ứng với các câu lệnh/nhóm câu lệnh và các cạnh là các dòng điều khiển giữa các câu

lệnh/nhóm câu lệnh. Nếu i và j là các đỉnh của đồ thị dòng điều khiển thì tồn tại một
cạnh từ i đến j nếu lệnh tương ứng với j có thể được thực hiện ngay sau lệnh tương
ứng với i.
Các thành phần cơ bản của của đồ thị dòng điều khiển bao gồm:điểm bắt đầu
của đơn vị chương trình, khối xử lý chứa các câu lệnh khai báo hoặc tính toán, điểm
quyết định ứng với các câu lệnh điều kiện trong các khối lệnh rẽ nhánh hoặc lặp,
điểm nối ứng với các câu lệnh ngay sau các lệnh rẽ nhánh, và điểm kết thúc ứng với
điểm kết thúc của đơn vị chương trình. Hình 2.3 mô tả các thành phần cơ bản của một
đồ thị dòng điều khiển.

Điểm bắt đầu

Khối xứ lý

Điểm quyết định Điểm nối Điểm kết thúc

Hình 2.3. Các thành phần cơ bản của đồ thị dòng điều khiển
Các cấu trúc điều khiển trong một CFG thường gồm tuần tự, rẽ nhánh (if …
else),lặp (while...do,do...while,for). Hình 2.4 minh họa các cấu trúc điều khiển nêu
trên. Trong đó đỉnh có nhãn c tượng trưng cho câu lệnh điều kiện. Các đỉnh còn lại
tượng trưng câu lệnh gán, khai báo, v.v. Các thành phần cơ bản của đồ thị dòng điều
khiển gồm đỉnh xuất phát, đỉnh xử lí, đỉnh quyết định, đỉnh kết nối và đỉnh kết thúc.
 Đỉnh xuất phát và đỉnh kết thúc: Hai đỉnh này là duy nhất, trong đó đỉnh xuất
phát đại diện cho tên hàm.
 Đỉnh quyết định: Là đỉnh tương ứng với câu lệnh điều kiện trong khối lệnh điều
khiển rẽ nhánh, do...while, while..do. Ví dụ cụ thể, với khối lệnh điều khiển “if
(a > b) { ... }” thì đỉnh quyết định tương ứng với “a > b”.
 Đỉnh kết nối: Là đỉnh có nhiều hơn hai đỉnh khác trỏ đến mà không phải đỉnh
quyết định.
 Đỉnh xử lí: Là đỉnh tương ứng với câu lệnh gán, câu lệnh khởi tạo hoặc câu lệnh

khai báo và không phải đỉnh kết nối. Các khối lệnh điều khiển cũng chứa các
loại câu lệnh này. Ví dụ, khối lệnh “for (i = 0; i < 10; i++)” chứa hai đỉnh xử lí
gồm câu lệnh gán “i = 0” và câu lệnh tăng giá trị biến i là “i++”.

8


2.3.2. Các tiêu chí phủ kiểm thử
Một trong những nhược điểm của kiểm thử dựa trên đặc tả (kiểm thử hộp đen)
là chúng ta không biết số lượng ca kiểm thử có thừa hay thiếu so với chương
trình cài đặt hay không, và thiếu thừa ở mức độ nào. Ngược lại, trong kiểm thử
hộp trắng, độ đ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. Tập ca kiểm thử khiến mã nguồn có độ
phủ cao được đánh giá là tốt hơn so với tập ca kiểm thử khác khiến mã nguồn
có độ phủ thấp hơn. Chất lượng mã nguồn được đánh giá tỉ lệ thuận với độ phủ.

Hình 2.4. Các cấu trúc điều khiển phổ biến
Độ phủ được đánh giá dựa trên hai thông số gồm tiêu chí phủ kiểm thử và tập
ca kiểm thử. Công thức tính độ phủ là tỉ lệ các thành phần được kiểm thử trên tổng số
các thành phần cần kiểm thử sau khi đã thực hiện tập ca kiểm thử. Thành phần có thể
là câu lệnh, điểm quyết định, điều kiện con, đường thi hành hoặc là sự kết hợp của
chúng.
Tiêu chí phủ kiểm thử được giới thiệu lần đầu tiên vào năm 1963 trong tạp chí
hàng tháng “Communications of the ACM”. Cho tới nay, nhiều tiêu chí phủ kiểm thử
được đưa ra. Trong khuôn khổ luận văn này,tôi sử dụng ba tiêu chí phủ kiểm thử phổ
biến để đánh giá chất lượng mã nguồn gồm:
 Phủ câu lệnh: Mỗi một câu lệnh được thực thi ít nhất một lần sau khi chạy tập
ca kiểm thử.
 Phủ nhánh: Mỗi một nhánh đều được đi qua ít nhất một lần sau khi chạy tập ca
kiểm thử.

 Phủ điều kiện con: Mọi nhánh đúng-sai đều được đi qua với một tập ca kiểm
thử nào đó, trong đó các câu lệnh điều kiện kép được phân tách thành các câu
lệnh điều kiện đơn.

9


2.3.3.Đường kiểm thử
Với một bộ giá trị đầu vào, một tập các câu lệnh gán, câu lệnh khai báo và câu
lệnh điều kiện được đi qua. Danh sách các câu lệnh này được sắp theo thứ tự thực hiện
chính là một đường đi. Trong số tất cả các đường đi có thể, một tập đường đi được
chọn sao cho thỏa mãn tiêu chí phủ kiểm thử được gọi là tập đường kiểm thử.
Đường kiểm thử là một đường đi từ đỉnh đầu tiên đến đỉnh cuối cùng của CFG
được biểu diễn dưới một tập các đỉnh từ đỉnh v1 đến đỉnh vn, trong đó hai đỉnh liền kề
có cạnh nối với nhau. Nếu cạnh (vi ,vj) (i≠j) là nhánh false, câu lệnh lưu ở đỉnh viđược
viết phủ định. Tập đường đi độc lập gồm k đường đi PATH1, PATH2, …, PATHk thỏa
mãn: giữa mọi cặp đường đi độc lập PATHi và PATHj (i≠j) không chung ít nhất một
cạnh trở lên.
Tìm kiếm tập đường kiểm thử là bước trung gian trong quá trình sinh dữ liệu
chotập ca kiểm thử. Hai vấn đề liên quan đến tập đường kiểm thử rất quan trọng gồm:
 Vấn đề thực thi được hay không thực thi được.Một đường kiểm thử gọi là thực
thi được nếu tìm kiếm được một ca kiểm thử sao cho khi thực thi trong môi
trường thật thì đường kiểm thử nêu trên được đi qua. Ngược lại, đường kiểm
thử gọi là không thực thi được.
 Tính phức tạp mã nguồn. Một mã nguồn gọi là phức tạp nếu chứa nhiều vòng
lặp như nhiều vòng lặp lồng nhau hoặc nhiều vòng lặp nối tiếp nhau, kích thước
lớn hoặc thuật toán phức tạp. Mã nguồn càng phức tạp càng khiến quá trình tìm
kiếm đường kiểm thử trở nên khó khăn hơn và mất thời gian hơn.

2.4. Kỹ thuật kiểm thử dòng điều khiển

Kiểm thử hộp trắng dòng điều khiển chia ra gồm kiểm thử hướng tĩnh và kiểm
thử hướng động. Đầu vào của hai kỹ thuật này đều là mã nguồn và tiêu chí phủ kiểm
thử. Sau một loạt quá trình phân tích, đầu ra tương ứng là tập các ca kiểm thử. Mỗi
một kỹ thuật đều có những ưu điểm và hạn chế riêng. Mục tiêu của kiểm thử hộp trắng
dòng điều khiển là tìm tập ca kiểm thử tối thiểu nhưng đạt được độ phủ tối đa.

2.4.1. Kiểm thử hộp trắng dòng điều khiển theo hướng động
Theo kỹ thuật này, mã nguồn sẽ được thêm các đoạn chương trình con trước khi
thực thi trong môi trường chạy. Hình 2.5 trình bày quy trình chung của kỹ thuật kiểm
thử hộp trắng theo hướng động.Nhìn chung, kỹ thuật này gồm các bước cơ bản được
diễn giải theo thứ tự dưới đây:
Bước 1. Chèn thêm các đoạn mã nguồn mới vào mã nguồn cần kiểm thử.
Bước 2. Chọn ngẫu nhiên một tập giá trị đầu vào hợp lệ làm ca kiểm thử đầu tiên.

10


Bước 3. Thực thi chương trình với bộ giá trị vừa tìm được. Nếu không thực thi
được, quay lại bước 2 để sinh bộ giá trị khác.
Bước 4. Tìm tập các câu lệnh đã được đi qua với bộ giá trị ở bước 3 để xây dựng
được hệ ràng buộc tương ứng.
Bước 5. Phủ định hệ ràng buộc thu được ở bước 4 để sinh các hệ ràng buộc mới
có tác dụng sinh các ca kiểm thử kế tiếp. Nếu không thể sinh hệ phủ định
nào khác, thuật toán kết thúc.
Giải hệ ràng buộc thu được ở bước 5 để sinh ca kiểm thử kế tiếp. Nếu không có
ca kiểm thử nào thỏa mãn, quay về bước 5 để tìm hệ ràng buộc phủ định mới sao cho
khác hệ ràng buộc hiện tại. Ngược lại, quay lại bước 3 để sinh ca kiểm thử kế tiếp.
Mã nguồn
Chèn thêm khối lệnh mới
Tiêu chí phủ

Tìm ca kiểm thử khởi đầu
ngẫu nhiên
Thực thi ca kiểm thử vừa
tìm được
Tái tạo đường thực thi

Tạo đường thực thi mới

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

Kết thúc

Hình 2.5. Kiểm thử hộp trắng dòng điều khiển theo hướng động.
Ở kỹ thuật này, trong bước 1, quá trình chèn thêm khối mã nguồn mới vào mã
nguồn cần kiểm thử được tiến hành một cách tự động. Công cụ DMS/SRT2 được đánh
giá khá mạnh mẽ để thực hiện pha này. Đoạn mã nguồn thêm vào có chức năng đánh
2

/>
11


dấu, thoát chương trình hoặc ghi thông tin về quá trình thực thi ra tệp, v.v. Để làm
được điều này, chúng ta cần xây dựng các luật chèn thêm mã nguồn mới vào mã
nguồn cần kiểm thử.
Với công cụ DMS/SRT, mỗi một luật bắt đầu với từ khóa rulevà theo sau là tên
đặt cho luật. Từ khóa rewrite to nêu cách biến đổi đoạn mã nguồn gốc về đoạn mã
nguồn mới. Kiểu dữ liệu có thể là expression (ứng với biểu thức), statement (ứng với

câu lệnh gán hoặc khởi tạo), type (ứng với kiểu dữ liệu), identifier (ứng với định danh
như tên biến, tên hàm), v.v.Hình 2.6 mô tả một luật chèn thêm câu lệnh đánh dấu vào
khối lệnh điều khiển rẽ nhánh. Cụ thể, biến mảng visited đánh dấu vị trí câu lệnh đi
qua được bổ sung vào mã nguồn ban đầu ngay sau mỗi khối lệnh điều khiển rẽ nhánh.
Hình 2.7 đưa ra mã nguồn triangle sau khi áp dụng luật.

Hình 2.6. Ví dụ một luật chèn mã nguồn trong DMS/SRT

Hình 2.7. Mã nguồn hàm triangle sau khi thêm khối mã nguồn mới

2.4.2. Kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh
Trong kiểm thử tĩnh, mã nguồn không được thực thi trong môi trường chạy để
sinh ca kiểm thử. Trong kiểm thử tĩnh, quá trình chạy ca kiểm thử chỉ thực hiện duy
nhất một lần với từng ca kiểm thử để tính toán giá trị trả về và đảm bảo ca kiểm thử
12


thực thi không có vấn đề. Các bước tổng quát trong kỹ thuật này được trình bày như
dưới đây:
Bước 1.Xây dựng đồ thị dòng điều khiển từ mã nguồn và tiêu chí phủ kiểm thử.
Bước 2. Xây dựng tập đường kiểm thử.
Bước 3.Tìm tập ca kiểm thử dựa trên tập đường kiểm thử.
Bước 4. Xây dựng hệ ràng buộc và giải hệ ràng buộc để sinh ca kiểm thử và dữ
liệu kiểm thử.
Bước 5.Thực thi ca kiểm thử. Thuật toán kết thúc.
Hình 2.8 mô tả chi tiết kỹ thuật này. Đầu tiên, đồ thị dòng điều khiển được xây
dựng dựa trên mã nguồn và tiêu chí phủ kiểm thử. Bước tiếp theo, từ đồ thị dòng điều
khiểnchúng tôi xây dựng được tập đường kiểm thử. Mỗi một đường kiểm thử trong tập
đường kiểm thử mô tả hành vi chương trình với một miền bộ đầu vào nào đó. Sau
đó,pha tìm ca kiểm thử thỏa mãn đường kiểm thử được tiến hành. Cuối cùng, ca kiểm

thử được thực thi trong môi trường chạy.
Mã nguồn
Xây dựng đồ thị dòng
điều khiển
Tiêu chí phủ
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.8.Kiểm thử hộp trắngdòng điều khiển theo hướng tĩnh

2.5. So sánh kĩ thuật kiểm thử hộp trắng dòng điều khiển
theo hướng tĩnh và động
Mỗi một kĩ thuật kiểm thử đều có những ưu điểm và hạn chế riêng. Để có cái
nhìn tổng quan về hai kĩ thuật, chúng tôi đưa ra sự so sánh về số ca kiểm thử, thời gian
sinh ca kiểm thử, khả năng kiểm thử vòng lặp, ảnh hưởng bởi phức tạp mã nguồn đối
với hai kĩ thuật.
13