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

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

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

2

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

i

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! Bookmark not defined. 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

ii

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

iii

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

iv

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ử

v

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 constructed 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

re-Keywords:Automated testing, white-box testing technique, control flow testing,

test case, coverage criteria

vi

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à

vii

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

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 Modulo Theories

Solver

viii

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

ix

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

x

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

1

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ự

2

á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ử

3

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

và Kỹ thuật kiểm thử dựa trên kinh nghiệm của người kiểm thử viên based)

(Experience-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

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)

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 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 Phần Mềm

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 Phần Mềm không

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

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

7

Để 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

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

8

ứ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++”

9

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

10

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 v 1 đến đỉnh v n, trong đó hai đỉnh liền kề

có cạnh nối với nhau Nếu cạnh (v i ,v j ) (i≠j) là nhánh false, câu lệnh lưu ở đỉnh v iđược

viết phủ định Tập đường đi độc lập gồm k đường đi PATH 1 , PATH 2 , …, PATH k thỏa

mãn: giữa mọi cặp đường đi độc lập PATH i và PATH j (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

11

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

Chèn thêm khối lệnh mới

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 http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html

12

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ử

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

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

Mã nguồ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

14

 Về số ca kiểm thử Nhìn chung, với mã nguồn chỉ chứa các câu lệnh rẽ nhánh và

không chứa vòng lặp, hai kĩ thuật kiểm thử nêu trên cho số bộ ca kiểm thử như nhau Tuy nhiên, trong trường hợp có vòng lặp thì kĩ thuật kiểm thử tĩnh đưa ra

số ca kiểm thử ít hơn so với kiểm thử động Theo hướng tĩnh, các đường đi chứa vòng lặp lặp lại một lần sẽ được cấu trúc lại để lặp nhiều hơn một lần Nói

cụ thể hơn, từ một đường kiểm thử chứa vòng lặp ban đầu sẽ sinh ra một tập các đường kiểm thử mới dùng để kiểm thử tính đúng đắn vòng lặp Nếu vòng lặp trong đường kiểm thử xác định được số lần lặp tối đa thì số đường đi mới sinh ra là bảy Ngược lại, nếu vòng lặp không xác định số lần lặp tối đa thì số đường đi mới sinh ra là bốn

Với mã nguồn chứa vòng lặp, kiểm thử động sử dụng kĩ thuật phủ định hệ

để sinh ca kiểm thử kế tiếp nên số ca kiểm thử có thể rất lớn hoặc không xác định Cụ thể, trường hợp số ca kiểm thử rất lớn xảy ra khi vòng lặp có cận lặp

lớn, ví dụ, khối lệnh điều khiển “for (int i = 0; i< 1000; i++)” có số lần lặp tối

đa là 1000 lần Trường hợp số ca kiểm thử không xác định xảy ra khi số lần lặp

không được biết trước như “while (m!=n){ }”, trong đó m và n là hai tham số

kiểu nguyên truyền vào hàm Để giải quyết hai vấn đề này, một vài công cụ kiểm thử như đã chèn thêm mã nguồn xác định số lần lặp tối đa của mỗi vòng lặp hoặc thêm yêu cầu thời gian chạy Tuy nhiên, nhìn chung số ca kiểm thử vẫn khá lớn gây khó khăn cho quản lí

 Về thời gian sinh ca kiểm thử.Một cách tổng quan, kiểm thử động thực thi ca

kiểm thử lặp lại nhiều lần nên thời gian sinh ca kiểm thử lâu hơn

 Về khả năng kiểm thử vòng lặp Kiểm thử tĩnh hướng đến chỉ kiểm thử một

vòng lặp duy nhất tại một thời điểm Do đó, trong trường hợp có nhiều vòng lặp, chẳng hạn như đường kiểm thử đi qua hai vòng lặp lồng nhau thì quy trình kiểm thử tiến hành với từng vòng lặp riêng và tìm cách phá vỡ cấu trúc lặp các vòng lặp còn lại Ngược lại, kiểm thử động hướng đến kiểm thử tính đúng đắn của các vòng lặp một cách đồng thời thay vì riêng rẽ Tư tưởng này mô phỏng quá trình thực thi trong thực tế

 Tính phức tạp mã nguồn.Hiện nay, quy tắc viết mã nguồn rất đa dạng và các

quy tắc mới có thể được đưa ra trong các phiên bản trình biên dịch mới Kiểm thử tĩnh bị hạn chế bởi tính phức tạp mã nguồn Ví dụ, trường hợp mã nguồn chứa các hàm biến đổi xâu thì kĩ thuật kiểm thử này yêu cầu cần phải xây dựng lại các hàm đó một cách thủ công Ngược lại, kiểm thử động không bị ảnh hưởng lớn bởi những sự thay đổi này và bởi tính phức tạp mã nguồn Nguyên nhân chính do kiểm thử động tận dụng thế mạnh trình biên dịch để sinh ca kiểm thử mới

15

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

Chương này nghiên cứu phương pháp kiểm thử tự động hàm Java sử dụng kỹ thuật kiểm thử kiểm thử hộp trắng dòng điều khiển theo hướng tĩnh Phương pháp nghiên cứu cách xây dựng đồ thị dòng điều khiển CFG, sinh tập đường đi độc lập, kỹ thuật kiểm thử tính đúng đắn với hàm đầu vào chứa vòng lặp đơn hoặc hai vòng lặp lồng nhau Ngoài ra, kỹ thuật thực thi tượng trưng được mô tả một cách chi tiết nêu cách xây dựng hệ ràng buộc từ một đường thi hành bất kì Tổng quan về SMT-Solver

và kỹ thuật sinh ngẫu nhiên được trình bày để giải hệ ràng buộc sinh dữ liệu cho tập ca kiểm thử

3.1 Ý tưởng

Luận văn nghiên cứu phương pháp kiểm thử hàm Java sử dụng kỹ thuật kiểm thử hộp trắngdò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 này

Sinh CFG

Sinh tập đường đi độc lập

Sinh tập đường kiểm thử

Sinh đường kiểm thử vòng lặp

Sinh hệ ràng buộc

Sinh dữ liệu cho các

ca kiểm thử

Thực thi ca kiểm thửHàm Java

Độ phủ

Hình 3.1 Quy trình kiểm thử một hàm Java theo phương pháp nghiên cứu

hệ ràng buộc sẽ được chuyển đổi về dạng chuẩn SMT-Lib Sau khi có được tập ca kiểm thử và tập dữ liệu, quá trình thực thi ca kiểm thử được tiến hành để lấy giá trị trả

về của mã nguồn (nếu có) và đảm bảo ca kiểm thử thực thi không lỗi

3.2.Xây dựng đồ thị dòng điều khiển từ mã nguồn

Chi tiết thuật toán sinh đồ thị dòng điều khiển của hàm Java thỏa mãn một tiêu chuẩn phủ kiểm thử cho trước được trình bày ở hình 3.2 Đầu vào thuật toán gồm hàm

Java được lưu trong biến f và tiêu chí phủ kiểm thử lưu trong biến t Đầu ra thuật toán

là đồ thị dòng điều khiển(CFG) lưu trong biến graph Đầu vào cùng một hàm Java,

CFG ứng với tiêu chí phủ câu lệnh và phủ nhánh giống nhau và đơn giản hơn so với tiêu chí phủ điều kiện con

Bước đầu tiên thuật toán, ta gán CFG chính là hàm đầu vào f Ta sẽ kiểm tra xem

CFG có thỏa mãn độ phủ t hay không Nếu CFG chưa thỏa mãn độ phủ t, ta tiến hành

phân tách f thành một tập các khối mã nguồn con và lưu trong biến B Tiếp theo, ta xây dựng đồ thị G(V,A) thỏa mãn mỗi đỉnh đồ thị G(trong tập đỉnh V) lưu một khối mã nguồn con, các cạnh mô tả thứ tự thực hiện của các khối mã nguồn con trongf (được lưu trong tập các cạnh A) Sau đó, đỉnh của graph lưu f được thay thế thành đồ thị G Nếu đồ thị G tồn tại các đỉnh lưu câu lệnh break, continue và return thì con trỏ mà các đỉnh này trỏ tới đỉnh khác sẽ trỏ lại đến đúng đỉnh khác trong graph Cuối cùng, những

khối mã nguồn con còn khả năng phân tích tiếp ra các khối mã nguồn con khác, hàm

đệ quy được gọi

Một khối mã nguồn con không cần phân tích tiếp chỉ khi đã thỏa mãn tiêu chuẩn phủ kiểm thử Cụ thể, với tiêu chuẩn phủ câu lệnh và phủ nhánh, các đỉnh trong CFG lưu câu lệnh đơn và điều kiện trong các khối lệnh điều khiển Tuy nhiên, điều kiện của khối lệnh điều khiển có thể do một điều kiện hoặc nhiều điều kiện đơn hợp thành Nếu phân tách tiếp các điều kiện khối lệnh điều khiển thành đồ thị mà các đỉnh là điều kiện

Hình 3.2 Thuật toán sinh CFG từ mã nguồn

Ví dụ cụ thể, hình 3.3 mô tả hàm kiemTraNamNhuan Hình 3.4đưa ra đồ thị CFG tương ứng với hàm kiemTraNamNhuantrình bày ở hình 3.3 thỏa mãn tiêu chí phủ câu lệnh và phủ nhánh Phân tích hàm kiemTraNamNhuanthu được tập khối mã nguồn con

gồm 3 khối: khối if, lệnh return và câu lệnh khai báo dòng 2 Ba khối này đượcliên kết

với nhau theo dạng danh sách liên kết

Tiếp tục, khối if được phân tích tiếp thu được ba khối mã nguồn con khác: câu lệnh gán giá trị leaped=true, khối con ifvới điều kiện đơn (year%4==0) và một khối con ifkhác với điều kiện kép (year%100==0 &&year%400!=0 ) Lệnh return, câu lệnh

khai báo và điều kiện kép không cần phân tích tiếp

18

Hình 3.3 Mã nguồn hàm kiemTraNamNhuan

Bắt đầu

boolean leaped=falseint year

19

Để sinh ra CFG thỏa mãn tiêu chuẩn phủ điều kiện con cho hàm

kiemTraNamNhuan, ta tiếp tục phân tích tiếp khối con if với điều kiện kép

( year%100==0 &&year%400!=0 )để thu được hai khối con if đơn (year%100==0) và (year%400!=0 ) Hình 3.5 mô tả CFG hàm kiemTraNamNhuan thỏa mãn tiêu chuẩn phủ

điều kiện con

Bắt đầu

boolean leaped=falseint year

Hình 3.5 CFG hàm kiemTraNamNhuan tiêu chuẩn phủ điều kiện con

Ví dụ tiếp theo, trường hợp phủ điều kiện con, điều kiện kép (a>=0 || ((b>=0

&& c>=0) || b+c>=0) || a+b+c>=0) phân tích thành đồ thị tương ứng mô tả ở hình

3.6 Điều kiện kép nêu trên do ba điều kiện con hợp thành là a>=0, (b>=0 && c>=0)