Kiểm thử đơn vị cho hệ thống

Thông thường, số lượng lỗi tìm ra ở giai đoạn kiểm thử mức đơn vị có thể chiếm hơn 25% tổng số lượng lỗi của toàn bộ dự án.Kiểm thử tích hợp được thực hiện bởi các kỹ sư lập trình và kỹ

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

LUYỆN THỊ LAN HƯƠNG

KIỂM THỬ ĐƠN VỊ CHO HỆ THỐNG

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Hà Nội - 2014

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

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

LUYỆN THỊ LAN HƯƠNG

KIỂM THỬ ĐƠN VỊ CHO HỆ THỐNG

Ngành: Công nghệ thông tin

Chuyên ngành: Kỹ thuật phần mềm

Mã số: 60480103

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS TRẦN THỊ MINH CHÂU

Hà Nội – 2014

Lời cam đoan

Tôi xin cam đoan rằng luận văn cao học này do chính tôi thực hiện Những kết quả được tổng hợp và nghiên cứu từ các tài liệu tham khảo sử dụng trong luận văn này được thu thập từ các nguồn thông tin được công bố trên các sách báo, tạp chí khoa học chuyên ngành đáng tin cậy và kiến thức, kinh nghiệm của bản thân Tôi hoàn toàn chịu trách nhiệm trước nhà trường về sự cam đoan này

Hà Nội, ngày 31 tháng 10 năm 2014

Luyện thị Lan Hương

Lời cảm ơn

Em xin gửi lời cảm ơn chân thành tới các thầy cô giảng viên trong bộ môn Kỹ thuật phần mềm, khoa Công nghệ thông tin, trường Đại học Công nghệ đã tận tình giảng dạy và truyền đạt kiến thức, kinh nghiệm cho em trong suốt thời gian em học tập tại trường

Em xin được gửi lời cảm ơn sâu sắc nhất tới cô giáo TS Trần Thị Minh Châu, cô

đã luôn giúp đỡ, hướng dẫn và chỉ bảo cho em trong suốt quá trình học tập và thực hiện đề tài luận văn

Bên cạnh những kết quả em đạt được vẫn còn những vấn đề mà em cũng không tránh khỏi những thiếu sót trong quá trình thực hiện luận văn, em kính mong các thầy

cô thông cảm cho em Em mong nhận được sự góp ý, chia sẻ, đánh giá của các thầy

cô Đó là những kinh nghiệm quý báu cho quá trình học tập và làm việc của em sau này

Em xin cảm ơn chân thành cảm ơn

Hà Nội, ngày 31 tháng 10 năm 2014

Luyện Thị Lan Hương

Mục lục

Lời cam đoan 2

Lời cảm ơn 3

Mục lục 4

Bảng các từ viết tắt 6

Danh mục hình vẽ 7

Danh mục bảng biểu 8

Chương 1 Giới thiệu 10

1.1 Đặt vấn đề 10

1.2 Nội dung nghiên cứu 10

1.3 Cấu trúc luận văn 11

Chương 2.Tổng quan về kiểm thử phần mềm 12

2.1 Chất lượng phần mềm 12

2.2 Kiểm thử và vai trò của kiểm thử 12

2.3 Các mục tiêu của kiểm thử 13

2.4 Các hoạt động kiểm thử 14

2.5 Các mức độ kiểm thử 14

Kiểm thử đơn vị 15

Kiểm thử tích hợp, 17

Kiểm thử hệ thống 18

Kiểm thử chấp nhận 20

Kiểm thử hồi quy 20

Chương 3.Các kỹ thuật kiểm thử phần mềm 22

3.1 Kiểm thử hộp đen 22

3.1.1 Kỹ thuật phân lớp tương đương(Equivalence Class Testing) 22

3.1.2 Kỹ thuật phân tích giá trị biên (Boundary Value Testing) 25

3.1.3 Kỹ thuật bảng quyết định (Descision Table Testing) 29

3.2 Kiểm thử hộp trắng 31

3.2.1 Kỹ thuật dòng điều khiển (Control Flow Testing) 31

3.2.2 Kỹ thuật dòng dữ liệu (Data Flow Testing) 34

Chương 4.Bài toán áp dụng 37

4.1 Bài toán 1 37

4.1.1 Áp dụng kỹ thuật phân lớp tương đương 38

4.1.2 Áp dụng kỹ thuật Bảng quyết định 38

4.1.3 Áp dụng kỹ thuật kiểm thử dòng điều khiển 39

4.1.4 Áp dụng kỹ thuật kiểm thử dòng dữ liệu 45

4.1.5 Kết luận 48

4.2 Bài toán 2 51

4.2.1 Áp dụng kỹ thuật phân lớp tương đương 52

4.2.2 Áp dụng kỹ thuật bảng quyết định 54

4.2.3 Áp dụng kỹ thuật dòng điều khiển 54

4.2.4 Áp dụng kỹ thuật dòng dữ liệu 61

4.2.5 Kết luận 66

4.3 Bài toán 3 68

4.3.1 Áp dụng kỹ thuật Domain testing 69

4.3.2 Áp dụng kỹ thuật Bảng quyết định 69

4.3.3 Áp dụng kỹ thuật dòng điều khiển 74

4.3.4 Áp dụng kỹ thuật dòng dữ liệu 79

4.3.5 Kết luận 80

Chương 5.Kết luận 83

5.1 Kết quả của luận văn 83

5.2 Hướng nghiên cứu tiếp theo 83

Tài liệu tham khảo 84

Bảng các từ viết tắt

EP Equivalence partitioning Phân lớp tương đương

Danh mục hình vẽ

Hình 2.1 Mô hình phát triền phầm mềm chữ V 15

Hình 2.2 Kỹ thuật bộ cuống và bộ lái trong chiến lươc tích hợp dần 18

Hình 3.1 Trực quan mô tả phân lớp tương đương 22

Hình 3.2 Kỹ thuật kiểm thử biên mở rộng 26

Hình 3.3 Các biên kiểm thử trong trường hợp xấu nhất 27

Hình 3.4 Kết hợp kiểm thử biên rường hợp xấu nhẩt & kiểm thử biên mở rộng 28

Hình 3.6 So sánh các kỹ thuật kiểm thử biên 28

Hình 3.7 Sơ đồ dòng điều khiển 32

Hình 3.8 Các ký hiệu sử dụng trong đồ thị 32

Hình 3.9 Mối quan hệ giữa các độ đo kiểm thử dòng dữ liệu 36

Hình 4.1Sơ đồ dòng điều khiền cho bài toán 1 – mã nguồn 1 42

Hình 4.2 Sơ đồ dòng điều khiền cho bài toán 1 – mã nguồn 2 44

Hình 4.3 Sơ đồ dòng dữ liệu cho bài toán 1 – mã nguồn 1 46

Hình 4.4 Sơ đồ dòng dữ liệu cho bài toán 1 – mã nguồn 2 48

Hình 4.5 Sơ đồ dòng điều khiển cho bài toán 2 – mã nguồn 1 58

Hình 4.6 Sơ đồ dòng điều khiển cho bài toán 2 – mã nguồn 2 60

Hình 4.7 Sơ đồ dòng dữ liệu cho bài toán 2 – mã nguồn 1 63

Hình 4.8 Sơ đồ dòng dữ liệu cho bài toán 2 – mã nguồn 2 65

Hình 4.9 Sơ đồ dòng điều khiển cho bài toán 3 76

Hình 4.10 Sơ đồ dòng dữ liệu cho bài toán 3 79

Danh mục bảng biểu

Bảng 3.1 Cấu trúc bảng quyết định 29

Bảng 4.2 Các ca kiểm thử sinh ra theo kỹ thuật phân lớp tương đương 38

Bảng 4.3 Bảng quyết định cho bài toán 1 39

Bảng 4.4 Các ca kiểm thử sinh ra theo kỹ thuật bảng quyết định 39

Bảng 4.5 Quy ước các điều kiện, hành động trong sơ đồ CFG của bài toán 1 41

Bảng 4.6 Các ca kiểm thử sinh ra theo kỹ thuật dòng điều khiển với mã nguồn 1 43

Bảng 4.7 Các ca kiểm thử sinh ra theo kỹ thuật dòng điều khiển với mã nguồn 2 45

Bảng 4.8 Quy ước ký hiệu của các điều kiện trong sơ đồ DFG của bài toán 1 45

Bảng 4.9 Các ca kiểm thử sinh ra theo kỹ thuật dòng dữ liệu với mã nguồn 1 47

Bảng 4.10 Các ca kiểm thử sinh ra theo kỹ thuật dòng dữ liệu với mã nguồn 2 48

Bảng 4.11 So sánh độ bao phủ của các kỹ thuật kiểm thử với mã nguồn 1 48

Bảng 4.12 So sánh độ bao phủ của các kỹ thuật kiểm thử với mã nguồn 2 49

Bảng 4.13 Thống kê số lỗi phát hiện được khi thực thi hai mã nguồn – bài toán 1 49

Bảng 4.14 Bảng hệ số tỷ lệ free float của chỉ số HNX 52

Bảng 4.15 Các ca kiểm thử sinh ra theo kỹ thuật phân lớp tương đương 53

Bảng 4.16 Các ca kiểm thử sinh ra theo kỹ thuật bảng quyết định 54

Bảng 4.17 Quy ước các điều kiện, hành động trong sơ đồ CFG của bài toán 2 – mã nguồn 1 57

Bảng 4.18 Các ca kiểm thử sinh ra bởi kỹ thuật dòng điều khiển – mã nguồn 1 59

Bảng 4.19 Quy ước các điều kiện, hành động trong sơ đồ CFG của bài toán 2 – mã nguồn 2 59

Bảng 4.20 Các ca kiểm thử sinh ra bởi kỹ thuật dòng điều khiển – mã nguồn 2 61

Bảng 4.21 Quy ước, ký hiệu các điều kiện của sơ đồ DFG của bài toán 2 – mã nguồn 1 61

Bảng 4.22 Quy ước, ký hiệu các điều kiện của sơ đồ DFG của bài toán 2 – mã nguồn 1 62

Bảng 4.23 Các ca kiểm thử sinh ra bởi kỹ thuật dòng dữ liệu – mã nguồn 1 63

Bảng 4.24 Quy ước, ký hiệu các điều kiện của sơ đồ DFG của bài toán 2 – mã nguồn 2 64

Bảng 4.254 Các ca kiểm thử sinh ra bởi kỹ thuật dòng dữ liệu – mã nguồn 2 66

Bảng 4.265 So sánh độ bao phủ của các kỹ thuật kiểm thử với mã nguồn 1 66

Bảng 4.27 So sánh độ bao phủ của các kỹ thuật kiểm thử với mã nguồn 2 67

Bảng 4.28 Thống kê số lỗi phát hiện được khi thực thi hai mã nguồn – bài toán 2 67

Bảng 4.29 Quy ước các điều kiện, hành động trong sơ đồ CFG của bài toán 3 75

Bảng 4.30 So sánh độ phủ của các kỹ thuật kiểm thử 80 Bảng 4.31 Thống kê số lỗi phát hiện được khi thực thi hai mã nguồn – bài toán 3 81

Chương 1 Giới thiệu

Chương 1 đặt vấn đề đưa ra nội dung cần nghiên cứu, cấu trúc của luận văn

1.1 Đặt vấn đề

Hiện nay, khi các sản phẩm phần mềm ngày càng mang lại những lợi ích quan trọng cho cuộc sống, thì việc đánh giá, kiểm thử để chứng minh giá trị của các sản phẩm phần mềm ngày càng trở nên quan trọng Hầu hết các dự án phát triển phần mềm hiện nay đều sử dụng mô hình phát triển chữ V đế tiến hành xây dựng và phát triển dự

án phần mềm Ở mô hình này, ta có thể dễ nhận thấy vai trò quan trọng của kiểm thử, cũng như việc xác định các chiến lược kiểm thử tương ứng với từng mức độ phát triển trong từng giai đoạn triển khai dự án

Trong ngành phần mềm, việc tiến hành kiểm thử đơn vị là phương pháp xác định tính đúng đắn của một đơn vị mã nguồn đã ngày càng trở nên quan trọng Tuy nhiên, hầu hết các lập trình viên hiện nay đều không sử dụng một công cụ sinh ca kiểm thử tự động nào mà vẫn viết ca kiểm thử thủ công, sau đó tiến hành chạy ca kiểm thử trong môi trường lập trình

Mặt khác, có rất nhiều kỹ thuật, phương pháp kiểm thử có thể áp dụng để tiến hành kiểm thử cho đơn vị/chương trình như:

Đối với chiến lược kiểm thử dựa trên đặc tả bài toán (black box): Ta có kỹ thuật kiểm thử sử dụng phân lớp tương đương (Equivalence class partitioning), kỹ thuật phân tích giá trị biên (Boundary value analysis), kỹ thuật kiểm thử cặp (Pairwise Tesing), kỹ thuật sử dụng bảng quyết định (Decision tables)

Đối với chiến lược kiểm thử cấu trúc (white box): Ta có kỹ thuật kiểm thử dòng điều khiển (Control flow testing), kỹ thuật kiểm thử dòng dữ liệu (Data flow testing) Vấn đề đặt ra là: Lập trình viên nên xây dựng chiến lược kiểm thử như thế nào

để việc kiểm thử đơn vị đạt được hiệu quả tốt nhất, số lượng ca kiểm thử sinh ra không quá nhiều, mà việc hạn chế lỗi phát sinh là tốt nhất

Từ vấn đề đặt ra đó, luận văn đã tiến hành thử nghiệm các kỹ thuật kiểm thử khác nhau áp dụng cho bài toán thực tế trong dự án phần mềm để sinh ra các ca kiểm thử

Từ đó, phân tích và đưa ra kết luận về chiến lược kiểm thử phù hợp sẽ áp dụng cho bài toán/ hàm thuộc chương trình

1.2 Nội dung nghiên cứu

Luận văn tập trung nghiên cứu và khảo sát tổng quan về kiểm thử phần mềm và các kỹ thuật kiểm thử phần mềm Trong đó, tìm hiểu và phân tích các kỹ thuật kiểm thử áp dụng cho mức độ kiểm thử đơn vị, các ưu, nhược điểm của từng kỹ thuật và các bài toán sẽ áp dụng cho từng kỹ thuật kiểm thử

Từ những tìm hiều về các kỹ thuật kiểm thử, tiến hành áp dụng thử nghiệm các

kỹ thuật kiểm thử để sinh ca kiểm thử cho bài toán thực tế Dựa trên các kết quả đó, tiến hành tổng hợp phân tích để đưa ra chiến lược kiểm thử sẽ áp dụng cho hàm/ đơn

vị cần tiến hành kiểm thử đơn vị nhằm đảm bảo số ca kiểm thử ít nhưng độ bao phủ là cao nhất Đưa ra kết luận về các chiến lược kiểm thử sẽ áp dụng khi lập trình viên xây dựng kiểm thử cho mức độ kiểm thử đơn vị

1.3 Cấu trúc luận văn

Luận văn có cấu trúc gồm năm phần như sau:

Chương 1: Đưa ra vấn đế nghiên cứu của luận văn Từ đó, mô tả khái quát nội dụng nghiên cứu của luận văn

Chương 2: Trình bày kiến thức tổng quan về kiểm thử phần mềm

Chương 3: Trình bày các kỹ thuật kiểm thử phần mềm áp dụng cho mức độ kiểm thử đơn vị

Chương 4: Đưa bài toán thực tế, tiến hành phân tích, đánh giá, nhận xét và đưa ra chiến lược kiểm thử áp dụng cho bài toán

Chương 5: Kết luận đưa ra kết quả đạt được của luận văn và hướng nghiên cứu tiếp theo của luận văn

Chương 2.Tổng quan về kiểm thử phần mềm

Chương 2 trình bày tổng quan về kiểm thử phần mềm

2.1 Chất lượng phần mềm

Chất lượng của phần mềm được nhìn theo những hướng khách nhau, khi đứng ở những vai trò khác nhau Theo [2] thì chất lượng phần mềm được đánh giá theo năm góc nhìn như sau:

1 Góc nhìn tiên nhiệm (Transcendental View): Chất lượng là một thứ gì đó dễ dàng thừa nhận qua kinh nghiệm, nhưng khó được định nghĩa Góc nhìn tiên nhiệm không đặc tả riêng rẽ được chất lượng phần mềm, nhờ vào kinh nghiệm người ta có thể đưa ra chất lượng phần mềm là tốt và dễ được công nhận

2 Góc nhìn người dùng (User View): Chất lượng liên quan đến mức độ mà sản phẩm đáp ứng được nhu cầu, kỳ vọng của người dung, phù hợp cho việc sử dụng Quan điểm này đánh giá cao cá nhân Một sản phẩm được coi là chất lượng tốt nếu có đủ một số lượng lớn người dùng Quan điểm này rất hữu ích để xác định các thuộc tính sản phẩm mà người dùng cho là quan trọng bao gồm nhiều yêu tố như khả năng sử dụng, độ tin cậy và hiệu quả

3 Góc nhìn sản xuất (Manufacturing View): Ý tưởng chính của quan điểm này là

sự đáp ứng được đặc tả yêu cầu Chất lượng ở mức độ sản phẩm được xác định bởi việc là sản phẩm có gặp được đặc tả của nó hay không Bất kỳ một sai lệch nào với yêu cầu đặc tả cũng làm giảm chất lượng sản phẩm Việc phù hợp với yêu cầu dẫn đến sự thống nhất của sản phẩm

4 Góc nhìn sản phẩm (Product View): Giả thuyết đặt ra là:”Nếu một sản phẩm được sản xuất với tính chất nội bộ tốt, thì nó sẽ có các thuộc tính bên ngoài tốt” Người ta có thể khám phá những mối quan hệ nhân quả giữa các thuộc tính nội

bộ và chất lượng bên ngoài Trong trường hợp này, chất lượng được xem như là một đặc tính vốn có của sản phẩm

5 Góc nhìn dựa vào giá trị (Value-Based View): Chất lượng, theo góc nhìn này phụ thuộc vào tổng giá trị mà khách hàng vui lòng trả cho nó Chất lượng là vô nghĩa nếu một sản phẩm không có ý nghĩa kinh tế

Trong tài liệu về tiêu chuẩn ISO 9126 thì chất lượng phần mềm được định nghĩa trên sáu thuộc tính là: tính năng, tính đáp ứng, tính dễ dùng, tính hiệu quả, tính có thể bảo trì được và tính khả chuyển

2.2 Kiểm thử và vai trò của kiểm thử

Kiểm thử phần mềm đóng một vai trò quan trọng trong việc đảm bảo sự thành công của một sản phẩm phần mềm Theo tài liệu [2], đảm bảo chất lượng của một sản phẩm phần mềm là cả quá trình cải tiến phầm mềm thông qua việc lặp đi lặp lại quá trình kiểm thử - tìm lỗi – sửa lỗi trong suốt quá trình phát triển phần mềm Ứng với từng giai đoạn khác nhau trong quá trình phát triển phần mềm, phải có sự đánh giá

hoạt động cách hệ thống có thể hoạt động đúng khi thực hiện kiểm thử ở mức hệ thống trước khi bàn giao sản phẩm Theo Friedman và Voas đã mô tả thì kiểm thử phần mềm

là một quá trình thẩm định cho việc đánh giá và cải thiện chất lượng phần mềm

Thông thường, các hoạt động đánh giá phần mềm được chia làm hai loại:

 Phân tích tĩnh (static analysis): Là việc đánh giá chương trình mà không cần

thực thi trên các mã lệnh của chương trình, nó có thể là các hoạt động xem xét

(review) lại các tài liệu đặc tả, tài liệu thiết kế, tài liệu ca kiểm thử, hoặc là thanh tra mã nguồn (code inspection), v.v

 Phân tích động (dynamic analysis): Là việc đánh giá chương trình mà cần thực

thi trên các mã lệnh của chương trình, trong đó có kỹ thuật kiểm thử hộp đen và hộp trắng

Bằng việc thực hiện phân tích tĩnh và phân tích động thì người kiểm thử viên mong muốn tìm được nhiều lỗi nhất có thể, và đảm bảo các lỗi phát hiện sẽ được sửa trong các giai đoạn sớm của quy trình phát triển phần mềm

Xác minh (Verification) và thẩm định (Validation) là hai công việc xuyên suốt

trong quá trình phát triển phần mềm ngay từ giai đoạn phân tích thiết kế phần mềm Xác minh là việc kiểm tra xem phần mềm có gặp được yêu cầu đặc tả của hệ thống không? Nó trả lời cho câu hỏi “Hệ thống đã được xây dựng đúng theo tài liệu đặc tả hay chưa?”, mục tiêu của viêc xác minh là phát hiện các lỗi lập trình

Thẩm định là sự kiểm tra xem phần mềm có thỏa mãn yêu cầu của người sử dụng không? Việc thẩm định chú trọng vào sản phẩm cuối cùng khi bàn giao cho khách hàng, mục tiêu là phát hiện các lỗi về thiết kế, về đặc tả Một hệ thống xây dựng đúng đặc tả, nhưng chưa chắc đã đáp ứng được yêu cầu của khách hàng, vì đặc tả có thể sai, thiết kế có thể thiếu chi tiết, và quá trình sử dụng không thuận tiện cho khách hàng

2.3 Các mục tiêu của kiểm thử

Theo tài liệu [6], các bên liên quan trong quy trình phát triển phần mềm sẽ bao gồm: lập trình viên, kiểm thử viên, quản trị dự án và khách hàng Mỗi đối tượng này đều có những cái nhìn khác nhau về mục tiêu của kiểm thử như sau:

 Chương trình hoạt động được: Các lập trình viên thường chỉ quan tâm đến

việc làm thế nào để chương trình hoạt động được trong các điều kiện thông thường

 Chương trình không hoạt động được: Lập trình viên ít khi quan tâm đến

vấn đề khác của chương trình là khi nào thì chương trình không hoạt động được, làm thế nào khi chương trình bị lỗi

 Giảm rủi ro của lỗi:Nhà quản trị phần mềm thường quan tâm đến khía cạnh

là giảm rủi ro của lỗi gây ra Hầu hết các hệ thống phần mềm phức tạp đều chứa lỗi - là nguyên nhân hệ thống thất bại Bởi vậy nếu các lỗi được phát

hiện và sửa trong khi thực hiện kiểm thử, tỷ lệ hệ thống gặp rủi ro sẽ giảm

 Giảm chi phí của việc kiểm thử: Chi phí cho việc kiểm thử bao gồm chi phí

thiết kế, bảo trì và thực thi các ca kiểm thử; chi phí phần tích kết quả thực hiện của mỗi ca kiểm thử; chi phí tài liệu hóa các ca kiểm thử và chi phí cho

hệ thống hoạt động và tài liệu hóa các hoạt động đó Khách hàng thường mong muốn là giảm các chi phí của việc kiểm thử nhưng vẫn đảm bảo chất

đó Một đối tượng rõ ràng sẽ kết nối tới một ca kiểm thử

 Lựa chọn các giá trị đầu vào: Việc lựa chọn này dựa vào đặc tả yêu cầu, mã nguồn hoặc mong muốn của chúng ta

 Tính toán giá trị đầu ra mong muốn: Tức là ứng với các giái trị đầu vào, cần tính toán giá trị đầu ra mong muốn của chương trình

 Thiết lập môi trường kiểm thử của chương trình: Chuẩn bị môi trường kiểm thử của chương trình, ở bước này tất cả các giả định ngoài của chương trình phải được thỏa mãn Ví dụ: các hệ thống mạng, các cơ sở dữ liệu cần được thiết lập một cách đúng đắn, máy tương tác

 Tiến hành kiểm thử chương trình: Kỹ sư kiểm thử thực hiện chương trình với các tập giá trị đầu vào và quan sát giá trị đầu ra thực tế của chương trình Để thực hiện một ca kiểm thử, các giá trị đầu vào phải được cung cấp cho chương trình ở các thời điểm khác nhau

 Phân tích kết quả kiểm thử: Phân tích các kết quả kiểm thử để so sánh kết quả đầu ra thực tế với kết quả đầu ra mong muốn Độ phức tạp của phép so sánh này phụ thuộc vào độ phức tạp của dữ liệu quan sát Cuối cùng là đưa ra quyết định về kết quả hoạt động của chương trình là thỏa mãn (pass), không thoải mãn (fail) yêu cầu của người dùng hay không đưa ra được quyết định

2.5 Các mức độ kiểm thử

Theo mô hình phát triền phần mềm chữ V thì kiểm thử phần mềm là một chuỗi

các hoạt động tiến hình song song cùng hoạt động phát triển phần mềm, từ lập kế hoạch và kiểm soát quá trình kiểm thử, phân tích yêu cầu và thiết kế ca kiểm thử, viết

ca kiểm thử,tiến hành kiểm thử phần mềm, đánh giá các kết quả kiểm thử, báo cáo và tổng hợp các hoạt động kết thúc quá trình kiểm thử Chúng ta có thể nhìn thấy rõ mối

liên hệ giữa hoạt động phát triền phần mềm (lập trình) và hoạt động kiểm thử phần mềm (kiểm thử) theo hình 2.1

Kiểm thử đơn vị hay còn gọi là unit testing (UT), là cấp độ kiểm thử cho phép kiểm tra, tìm kiếm lỗi bên trong chức năng của chương trình phần mềm (ví dụ module, đối tượng, lớp ) Việc kiểm thử module ở mức đơn vị thường sẽ do lập trình viên thực hiện trước khi nó được chuyển giao sang giai đoạn tích hợp với các module khác Công đoạn này cần được thực hiện sớm nhất trong giai đoạn viết mã nguồn và xuyên suốt chu kỳ phát triển phần mềm

Trước khi thực hiện UT, kiểm thử viên nên xác định các tiêu chí cũng như các đối tượng sẽ được kiểm thử trong giai đoạn này một cách rõ ràng Trong thực tế, UT nên kiểm tra được các đối tượng sau

 Kiểm tra, xác minh hoạt động của các tham số với giá trị bình thường (norm)

 Kiểm tra, xác minh hoạt động của các tham số với giá trị biên

 Kiểm tra, xác minh hoạt động của các tham số với giá trị không nằm trong miền giới hạn (abnormal)

 Kiểm tra sự hoạt động của các vòng lặp

 Kiểm tra sự hoạt động của các hàm đệ quy

 Kiểm tra sự truy cập cấu trúc dữ liệu/truy cập file

 Đảm bảo rằng tất các các câu lệnh, các nhánh lệnh được thực thi đúng

Vì đơn vị được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiểm thử Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể đang được kiểm tra Thực tế cho thấy thời gian tốn cho hoạt động kiểm thử đơn vị sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó

Thông thường, kiểm thử đơn vị đòi hỏi kiểm thử viên có kiến thức về thiết kế và

mã nguồn của chương trình Mục đích của UT là đảm bảo thông tin được xử lý và xuất khỏi đơn vị là chính xác trong mối tương quan với dữ liệu nhập và chức năng của đơn

vị đó Điều này thường đòi hỏi tất cả các nhánh bên trong thành phần đơn vị đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi Một nhánh thường là một chuỗi các lệnh được thực thi trong một đơn vị Thực tế, việc chọn lựa các nhánh để đơn giản hóa quá trình kiểm thử và quét hết thành phần đòi hỏi kiểm thử viên phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa

Cùng với các mức độ kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị trước các ca kiểm thử hoặc kịch bản kiểm thử, trong đó chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn Các ca kiểm thử và kịch bản kiểm thử này nên được giữ lại để tái sử dụng

Thực tế đã chứng minh rằng, với kiểm thử mức đơn vị, chúng ta có thể thực thi việc kiểm thử với sự hỗ trợ của các công cụ phát triển như framework hoặc công cụ

gỡ lỗi (debugging tool) [8] Thông thường, số lượng lỗi tìm ra ở giai đoạn kiểm thử mức đơn vị có thể chiếm hơn 25% tổng số lượng lỗi của toàn bộ dự án.Kiểm thử tích hợp được thực hiện bởi các kỹ sư lập trình và kỹ sư kiểm thử phần mềm nhằm đảm bảo rằng chương trình có thể hoạt động đúng khi tích hợp các đơn vị lại với nhau Kiểm thử tích hợp tương đương với việc kiểm tra thiết kế chi tiết, xem chương trình có thoả mãn thiết kế chi tiết hay không

2.5.2 Kiểm thử tích hợp,

Kiểm thử tích hợp - intergration test là việc kết hợp các thành phần của một ứng dụng lại với nhau như một ứng dụng hoàn chỉnh và tiến hành kiểm thử chúng Nếu như kiểm thử đơn vị kiểm tra các thành phần và đơn vị riêng lẻ thì kiểm thử tích hợp lại kết hợp chúng lại với nhau và kiểm tra sự giao tiếp và tương tác giữa chúng Kiểm thử tích hợp là giai đoạn tiếp theo của kiểm thử đơn vị được thực hiện bởi nhóm kiểm thử viên và tập trung vào việc tích hợp các thành phần đơn vị của hệ thống [2] Trước khi thực thi kiểm thử tích hợp chúng ta phải đảm bảo rằng các thành phần đơn vị đã thực hiện UT thành công

Mục tiêu chính của kiểm thử tích hợp là phát hiện lỗi giao tiếp xảy ra giữa các đơn vị, tích hợp các thành phần đơn vị đơn lẻ thành các hệ thống nhỏ và cuối cùng là tích hợp thành một hệ thống hoàn chỉnh chuẩn bị cho kiểm thử ở mức hệ thống Có một số phép kiểm thử đơn giản trên giao tiếp giữa đơn vị với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến thành phần đơn vị chỉ thật sự được kiểm tra đầy đủ khi các đơn vị này được tích hợp với nhau trong khi thực hiện kiểm thử tích hợp

Trừ một số ít trường hợp ngoại lệ, còn lại kiểm thử tích hợp chỉ nên thực hiện trên những đơn vị đã được kiểm tra cẩn thận trước đó bằng kiểm thử đơn vị trước đó

và được đảm bảo rằng tất cả các lỗi mức đơn vị đã được sửa chữa Trên thực tế việc tích hợp giữa các đơn vị dẫn đến những tình huống hoàn toàn khác do đó việc kiểm thử từng đơn vị là chưa đủ Một chiến lược cần quan tâm trong kiểm thử tích hợp là nên tích hợp dần từng đơn vị Một thành phần đơn vị tại một thời điểm được tích hợp vào một nhóm các đơn vị khác đã tích hợp trước đó và đã hoàn tất các đợt kiểm thử tích hợp trước đó Lúc này, ta chỉ cần kiểm thử giao tiếp của đơn vị mới thêm vào với

hệ thống các đơn vị đã tích hợp trước đó, điều này sẽ làm cho số lượng ca kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể Trong kiểm thử ở mức tích hợp, có hai chiến lược cơ bản là kiểm thử từ dưới lên và kiểm thử từ trên xuống

1 Kiểm thử từ dưới lên (bottom up testing) là quá trình tích hợp và kiểm thử

các module ở mức thấp trước Thông thường người ta không thuần túy kiểm thử tất cả các module ở tầng dưới cùng mà nhóm các module này thành các nhóm chức năng, tích hợp và kiểm thử chúng theo từng nhóm

Ưu điểm: Chiến lược kiểm thử từ dưới lên sẽ giúp cho kiểm thử viên tránh được việc phải tạo ra các bộ giả lập đầu vào phức tạp hay tạo các kết quả nhân tạo để thực hiện kiểm thử và thuận tiện cho việc phát triển các module thứ cấp dùng lại được Nhược điểm: Phát hiện chậm các lỗi thiết kế và chậm trễ trong việc có được phiên bản thực thi của hệ thống

2 Kiểm thử từ trên xuống (top down testing) là quá trình tiến hành kiểm

thử các module ở mức cao trước, các module ở mức thấp được tạm thời phát triển với các chức năng hạn chế Thông thường để sớm có một phiên bản phần mềm để thực

hiện người ta thường tiến hành tích hợp theo một nhánh cho đến các module cấp thấp nhất

Ưu điểm: Giúp cho người phát triển phát hiện sớm các lỗi thiết kế và có phiên bản thực thi hoạt động sớm

Nhược điểm: Phương pháp này tồn tại hạn chế là khó có thể mô phỏng được các chức năng của module cấp thấp phức tạp Ngoài ra, chúng ta không kiểm thử được đầy

đủ các chức năng của hệ thống

Hai phương pháp được sử dụng trong kiểm thử tích hợp là kiểm thử hộp trắng (để kiểm thử cấu trúc) và kiểm thử hộp đen (kiểm thử chức năng) Ngoài ra, khi tiến hành hành tích hợp cần phải sử dụng kỹ thuật bộ cuống và bộ lái để thay thế cho những mô đun còn thiếu mà cần thiết cho phần hệ thống được kiểm thử (xem hình 2.2)

Hình 2.2 Kỹ thuật bộ cuống và bộ lái trong chiến lươc tích hợp dần

Một yêu cầu đặt ra không thể bỏ qua khi kiểm thử tích hợp là phải tiến hành kiểm thử hồi quy mỗi khi tích hợp thêm mô đun mới hay sửa đổi một mô đun trong số các ô đun đã kiểm thử

2.5.3 Kiểm thử hệ thống

Kiểm thử hệ thống (ST) là cấp độ thực hiện việc kiểm thử toàn bộ các chức năng của hệ thống có phù hợp với yêu cầu đặc tả hay không Kiểm thử hệ thống được thực hiện sau khi giai đoạn kiểm thử đơn vị và kiểm thử tích hợp đã được thực hiện thành công cho tất cả các module Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị hỗ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân

bố, hoặc hệ thống nhúng

Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn bộ hệ thống

Điểm khác nhau giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống, còn kiểm thử tích hợp chú trọng

sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để đảm bảo mọi thành phần đơn vị và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện kiểm thử hệ thống Sau khi hoàn thành giai đoạn kiểm thử tích hợp thì một hệ thống phần mềm được hình thành cùng với các thành phần đã được kiểm tra đầy đủ Tại thời điểm này, lập trình viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh

Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu Kiểm thử hệ thống làm nhiệm vụ kiểm tra các hành vi chức năng của phần mềm và các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ Sau giai đoạn ST, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance test) hoặc dùng thử ( Alpha/Beta Test)

Kiểm thử hệ thống đòi hỏi nhiều công sức, thời gian, tính chính xác và khách quan nên cấp độ kiểm thử này thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án Mặt khác kiểm thử hệ thống lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm kiểm thử chức năng (Function test), kiểm thử hiệu năng (Performance test), kiểm thử khả năng chịu tải (Stress test hay Load test), kiểm thử bảo mật (Security test), kiểm thử khả năng phục hồi (Recovery test) và kiểm thử cấu hình (Configuration test)

− Kiểm thử chức năng: Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế

− Kiểm thử khả năng vận hành: Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn

− Kiểm thử khả năng chịu tải: Bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví

dụ nhiều người truy xuất cùng lúc) Kiểm thử khả năng chịu tải tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường

− Kiểm thử cấu hình: Kiểm tra sự cấu thành của hệ thống từ các thành phần dự kiến

− Kiểm thử khả năng an toàn và bảo mật: Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và chương trình của hệ thống khi có sự xâm nhập và tấn công từ bên ngoài

− Kiểm thử khả năng phục hồi: Bảo đảm hệ thống có khả năng khôi phục trạng thái

ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến

Trên thực tế không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên mà tùy vào yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm thử nào

Các ca kiểm thử trong kiểm thử hệ thống được xây dựng để xác minh các ứng dụng có phù hợp với yêu cầu được đưa ra trong tài liệu đặc tả hệ thống hay không Các

ca kiểm thử cần phải được viết đủ chi tiết cho các hành vi hoặc chức năng được kiểm thử, các thông tin bắt buộc cần có trong ca kiểm thử bao gồm: mục đích của ca kiểm thử, môi trường thực thi kiểm thử, các bước chi tiết để tiến hành kiểm thử, dữ liệu đầu vào, dữ liệu đầu ra mong đợi

2.5.4 Kiểm thử chấp nhận

Thông thường sau giai đoạn kiểm thử hệ thống là giai đoạn kiểm thử chấp nhận sản phẩm - acceptance test (AT), được khách hàng thực hiện hoặc ủy quyền cho một nhóm thứ ba kiểm thử Mục đích của AT là để chứng minh phần mềm thỏa mãn tất cả các yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm

Đối với những sản phẩm bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha test và kiểm thử Beta – Beta test

Với Alpha test, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần

mềm và trong môi trường được quản lý, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi của khách hàng và lên kế hoạch sửa chữa

Với Beta test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong

môi trường thực, lỗi hoặc phản hồi cũng sẽ được gửi ngược lại cho lập trình viên để sửa chữa

Nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả AT sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm thử trước đó Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong đợi của khách hàng Ví dụ, một phần mềm xuất sắc vượt qua các phép kiểm thử về chức năng được thực hiện bởi nhóm phát triển dự án, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng, của người sử dụng thì phần mềm đó cũng không được coi là hoàn hảo

Gắn liền với giai đoạn kiểm thử chấp nhận thường là một nhóm những dịch vụ

và tài liệu đi kèm như tài liệu hướng dẫn cài đặt, tài liệu hướng dẫn sử dụng, Tất cả tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ

2.5.5 Kiểm thử hồi quy

Kiểm thử hồi quy không phải là một mức kiểm thử thuộc mô hình, như các mức

độ kiểm thử đã nêu ở trên mà là kiểm thử lại phần mềm sau khi có một sự thay đổi nào

đó xảy ra, để bảo đảm phiên bản phần mềm sau thay đổi thực hiện tốt các chức năng

như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã làm việc tốt Kiểm thử hồi quy có thể thực hiện tại mọi mức kiểm tra, đặc biệt trong kiểm thử tích hợp

Mặc dù không phải là một mức kiểm thử nhưng kiểm thử hồi quy là một trong những loại kiểm thử tốn nhiều thời gian và công sức nhất Do đó, việc bỏ qua kiểm thử hồi quy là "không nên" vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta "tưởng rằng" những lỗi đó hoặc không có hoặc đã được kiểm thử và sửa chữa

Chương 3.Các kỹ thuật kiểm thử phần mềm

Chương 3 trình bày các kỹ thuật kiểm thử phần mềm được áp dụng cho mức độ kiểm thử đơn vị

Trong kiểm thử phần mềm, chúng ta thường dùng hai phương pháp chính là kiểm thử tĩnh (static testing) và kiểm thử động (dynamic testing) Kiểm thử động bao gồm các chiến lược: kiểm thử hộp đen (black box testing) và kiểm thử hộp trắng (white box testing)

3.1 Kiểm thử hộp đen

Kiểm thử hộp đen là một chiến lược kiểm thử quan trọng trong hoạt động kiểm thử phần mềm, khái niệm “hộp đen” ở đây là chỉ việc kiểm thử viên không biết chương trình bên trong được cài đặt như thế nào, họ chỉ biết rằng nó phải làm gì, và làm như thế nào để thỏa mãn các yêu cầu đặc tả - đã được cụ thể hóa thành các ca kiểm thử Một số kỹ thuật được áp dụng trong chiến lược kiểm thử hộp đen: Kỹ thuật phân lớp tương đương (Equivalence partitioning), kỹ thuật phân tích giá trị biên (Boundary value analysis), kỹ thuật dùng bảng quyết định (Decision table), kỹ thuật dùng bảng chuyển trạng thái (State transition) và kỹ thuật kiểm thử ca sử dụng (Use case testing)

3.1.1 Kỹ thuật phân lớp tương đương(Equivalence Class Testing)

Phân lớp tương đương là một kỹ thuật kiểm thử hộp đen dựa trên tài liệu đặc tả của hệ thống Kỹ thuật phân lớp tương đương chia miền dữ liệu vào thành các lớp dữ liệu con thỏa mãn điều kiện các giá trị thuộc một miền sẽ có sự tương tác là như nhau, tức là cùng một kết quả trả ra từ đó suy dẫn ra các ca kiểm thử Kỹ thuật này nhằm xác định ra một ca kiểm thử mà làm phát hiện ra một lớp lỗi, do đó giảm tổng số các ca kiểm thử phải được xây dựng [4]

Hình 3.1 Trực quan mô tả phân lớp tương đương

Thiết kế các ca kiểm thử cho phân lớp tương đương dựa trên việc đánh giá của các lớp tương đương cho một điều kiện đầu vào Lớp tương đương đại diện cho tập các

trạng thái hợp lệ hay không hợp lệ đối với điều kiện đầu vào Trong phân lớp tương đương dữ liệu được phân thành một trong hai lớp sau: Lớp tương đương hợp lệ (là lớp chứa dữ liệu nằm trong miền giá trị hợp lệ) và lớp tương đương không hợp lệ (là lớp chứa dữ liệu nằm trong miền giá trị không hợp lệ)

Thiết kế Test-case bằng phân lớp tương đương tiến hành theo hai bước:

(1) Xác định các lớp tương đương và

(2) Xác định các ca kiểm thử

(1)Xác định các lớp tương đương

Theo [9], lớp tương đương có thể được xác định dựa theo các yếu tố sau:

 Nếu điều kiện đầu vào xác định một miền giới hạn [a,b] thì một lớp tương đương hợp lệ (lớp này bao gồm các giá trị a < X <b) và hai lớp tương đương không hợp lệ (một lớp chứa các giá trị X < a và một lớp chứa các giá trị X>b) được xác định

 Nếu điều kiện đầu vào yêu cầu những giá trị xác định {M1}, {M2}, {M3}, {M4}, …{Mn} thì một lớp tương đương hợp lệ (lớp này chứa các giá trị xác định {M1, M2, M3, M4, …, Mn}) và một lớp tương đương không hợp lệ( lớp này chứa các giá trị nằm ngoài {M1, M2, M3, M4, …, Mn}) được xác định

 Nếu điều kiện đầu vào xác định cho từng giá trị riêng lẻ thì xác định một lớp cho từng giá trị đầu vào hợp lệ

 Nếu điều kiện đầu vào xác định số lượng của giá trị hợp lệ (Ví dụ là n) thì

xác định một lớp tương đương cho số lượng giá trị hợp lệ và hai lớp tương

đương cho giá trị không hợp lệ - một là 0, một là nhiều hơn n giá trị

 Nếu một điều kiện đầu vào phải là một giá trị thì một lớp tương đương hợp lệ (là giá trị đó) và một lớp tương đương (không là giá trị đó) không hợp lệ được xác định

(2) Xác định các ca kiểm thử

Với các lớp tương đương xác định được ở bước trên, bước thứ hai là sử dụng các lớp tương đương đó để xác định các ca kiểm thử Quá trình này như sau [2]:

1 Gán một số duy nhất cho mỗi lớp tương đương

2 Với mỗi lớp tương đương bao gồm các giá trị hợp lệ chưa được bao phủ bởi các ca kiểm thử trên thì viết một ca kiểm thử mới bao phủ được nhiều nhất có thể các lớp tương đương

3 Với mỗi lớp tương đương bao gồm các giá trị không hợp được bao phủ hết bởi các ca kiểm thử trên thì ta viết một ca kiểm thử mà bao phủ một và chỉ một trong các lớp tương đương chưa được bao phủ

Kỹ thuật theo kiểm thử phân lớp tương đương bao gồm ba kỹ thuật: Phân lớp tương đương yếu, phân lớp tương đương mạnh và phân lớp tương đương truyền thống Phân lớp tương đương yếu là kỹ thuật dựa trên nguyên tắc chung của phân lớp tương đương tức là chia miền dữ liệu đầu vào thành các lớp con tương đương Việc sinh ca kiểm thử trong phân lớp tương đương yếu phải đảm bảo mỗi lớp con được kiểm tra ít nhất một lần Do đó, số trường hợp kiểm thử trong kỹ thuậtphân lớp tương đương yếu bằng giá trị lớn nhấy của số phân hoạch biến đầu vào hay chính là lực lượng lớn nhất của phân hoạch

Phân lớp tương đương mạnh được tiến hành sau khi phân hoạch miền giá trị của các biến đầu vào thành các lớp tương đương, ta sẽ sinh trường hợp kiểm thử theo nguyên tắc mỗi ca kiểm thử là một phần tử tích đề các của các phân hoạch con đó Vì vậy, số ca kiểm thử sinh ra chính là số phần từ của tích đề các này

Phân lớp tương đương truyền thống là kỹ thuật đơn giản nhất trong các kỹ thuật kiểm thử theo phân lớp tương đương Với kỹ thuật này thì việc phân lớp tương đương cho các biến giá trị đầu vào chỉ cần quan tâm hai lớp sau:

 Lớp tương đương hợp lệ: Chứa dữ liệu của biến đầu vào nằm trong miền hợp lệ

 Lớp tương đương không hợp lệ: Chứa dữ liệu của biến đầu vào nằm trong miền không hợp lê

Ý tưởng của việc sinh ca kiểm thử cho kỹ thuật này thực hiện theo nguyên tắc: Khi chúng ta xây dựng ca kiểm thử cho trường hợp đúng thì chỉ cần lấy các giá trị biến đầu vào nằm trong miền hợp lệ Tức là ca kiểm thử sinh ra với điều kiện giá trị đầu vào của tất cả các biến đều nằm trong miền hợp lệ Khi tạo ca kiểm thử cho trường hợp sai thì chỉ cần lấy một trong các biến đầu vào có giá trị không nằm trong miền hợp lệ Tức là với các biến đầu vào không hợp lệ, mỗi ca kiểm thử sẽ bao gồm một biến đầu vào có giá trị nằm trong miền không hợp lệ và các biến còn lại có giá trị nằm trong miền hợp lệ

Nhận xét:

Ƣu điểm: Phân lớp tương đương (EP) phù hợp với hầu hết các hệ thống có miền

giá trị đầu vào của các biến cần được chia thành nhiều phân vùng, tập con EP có thể

áp dụng tương tự cho các cấp độ kiểm thử mức đơn vị, kiểm thử tích hợp và kiểm thử

hệ thống Hơn nữa việc phân chia miền dữ liệu đầu vào thành các lớp tương đương con

và thực hiện kiểm thử đại diện trên các lớp đó sẽ làm giảm chi phí cho việc kiểm thử

vì số lượng trường hợp kiểm thử bị giảm đi rất nhiều [6] Đối với kỹ thuật phân lớp tương đương mạnh thì khả năng phát hiện lỗi rất tốt vì kỹ thuật này hầu như vét cạn mọi miền giá trị và mọi khả năng kết hợp của các biến đầu vào khi thực hiện việc sinh

ca kiểm thử theo tích đề các của các lớp tương đương con

Nhƣợc điểm: Chúng ta khó có thể phủ nhận những ưu điểm rõ rệt của kỹ thuật

kiểm thử theo phân lớp tương đương Tuy nhiên kỹ thuật này vẫn có một số nhược điểm như: Tốn nhiều thời gian và chi phí cho việc sinh ca kiểm thử Hạn chế cuối cùng

là kỹ thuật này không thể hiện được các ca kiểm thử khi biến đầu vào có mối quan hệ logic phụ thuộc lẫn nhau

Các bài toán áp dụng kỹ thuật kiểm thử tương đương:

 Kiểm thử tương đương phù hợp với dữ liệu đầu vào có miền giá trị là khoảng

và hữu hạn

 Kiểm thử tương đương kết hợp với kiểm thử giá trị biên sẽ tốt hơn

 Nên dùng kiểm thử tương đương với các chương trình phức tạp

 Nên dùng kiểm thử tương đương nếu các biến là độc lập

3.1.2 Kỹ thuật phân tích giá trị biên (Boundary Value Testing)

Ý tưởng của kỹ thuật này là lập ra các ca kiểm thử tại các giá trị biên và cận biên của các khoảng dữ liệu đầu vào Thực tế đã chứng minh rằng, các giá trị ở vùng biên, vùng tới hạn là những giá trị thường gây ra lỗi cao nhất, những nơi diễn ra tính toán cơ học hoặc tại các vị trí dữ liệu được thao tác phải thay đổi cho hợp lý để chương trình xuất ra kết quả chính xác Các ca kiểm thử sẽ được lập ra để phân tích kết quả tại các điểm giá trị biên dưới, cận trên của biên dưới, cận dưới của biên trên,

biên trên của các biến đầu vào, tức là các điểm min, min+, max- và max Các trường

hợp cần kiểm tra sẽ chính là các ca kiểm thử lần lượt tương ứng với các giá trị đầu vào

là các điểm đặc biệt trên Kết quả mong đợi là khi chương trình làm việc chính xác với các giá trị đặc biệt này thì nó sẽ làm việc chính xác với các giá trị thông thường bên trong miền giá trị

Phân tích giá trị biên là một kỹ thuật mở rộng và cải tiến của kỹ thuật phân lớp tương đương [5] Kiểm thử giá trị biên giúp tạo ra các ca kiểm thử bổ sung thêm cho phân lớp tương đương, nó cho phép tìm lỗi trong mỗi miền là độc lập và khách quan như nhau, nhưng khác với phân lớp tương đương ở hai khía cạnh:

1 Phân tích giá trị biên không lựa chọn phần tử bất kỳ nào trong 1 lớp tương đương là điển hình, mà nó yêu cầu là 1 hay nhiều phần tử được lựa chọn như vậy mà mỗi cạnh của lớp tương đương đó chính là đối tượng kiểm tra

2 Ngoài việc chỉ tập trung chú ý vào các trạng thái đầu vào (không gian đầu vào), các ca kiểm thử cũng nhận được bằng việc xem xét không gian kết quả (các lớp tương đương đầu ra)

Thiết lập các ca kiểm thử được chỉ ra bởi phân tích giá trị biên phụ thuộc vào cả

sự yêu cầu về tính tin cậy của phần mềm và cả những giả thuyết có thể xảy ra trong quá trình kiểm soát lỗi

Giá trị biên có thể được xác định như sau [2]:

 Nếu lớp tương đương là một miền giới hạn dữ liệu vào hợp lệ thì xác định được các điểm biên ở trong miền và các điểm biên ở ngoài miền

 Nếu lớp tương đương xác định một số lượng các giá trị thì điểm biên xác định

là số nhỏ nhất và số lớn nhất của số lượng các giá trị hợp lệ

 Nếu lớp tương đương xác định một tập hợp thì giá trị biên chỉ tập trung tới điểm đầu và điểm cuối của tập hợp

Số lượng các ca kiểm thử sinh ra theo kỹ thuật này phụ thuộc vào số biến đầu

vào, nếu hàm có n biến thì sẽ có 4n+1 ca kiểm thử Ngoài ra, việc sinh ca kiểm thử

còn phụ thuộc và loại dữ liệu đầu vào có tính phụ thuộc phức tạp hay không và phụ thuộc bản chất dữ liệu

Kiểm thử biên mở rộng [1]: Là sự mở rộng của kỹ thuật phân tích giá trị biên có bản bằng cách thêm vào tập giá trị biên cơ bản các giá trị vượt ra ngoài biên, nằm ngoài tập giá trị đang xét Nếu hệ thống được cài đặt đúng thì với các giá trị đầu vào nằm ngoài biên sẽ không dẫn tới lỗi chương trình, hệ thống bị treo

Hình 3.2 Kỹ thuật kiểm thử biên mở rộng

Kỹ thuật này đòi hỏi việc kiểm tra tính đáp ứng của hệ thống với trường hợp cận

dưới của biên dưới (min- ) và cận trên của biên trên (max+) Với n biến đầu vào sẽ có 6n+1 ca kiểm thử sinh ra

Kiểm thử trường hợp xấu nhất là kỹ thuật giúp loại bỏ giá thiết “lỗi đơn” cho rằng hiếm khi xảy ra trường hợp lỗi đồng thời, nghĩa là ta cần kiểm tra các tình huống

có hơn một biến đầu vào là giá trị không hợp lệ

Với kỹ thuật này, ta sẽ tiến hành sinh các ca kiểm thử bằng cách kiểm tra các giá trị tại điểm nút giao nhayu, điểm chốt phân hoạch các tập giá trị Tập giá trị vẫn là

min, min+, nom, max-, max nhưng cả hai biến đều nhận giá trị này chứ không phải

chỉ một biến nhận giá trị này theo kỹ thuật phân tích giá trị biên cơ bản Kỹ thuật này

cho số lượng ca kiểm thử tính theo hàm mũ, nếu có n biến thì sẽ có 5 n trường hợp kiểm thử

Hình 3.3 Các biên kiểm thử trong trường hợp xấu nhất

Để đảm bảo việc kiểm thử sẽ phát hiện được nhiều lỗi nhất có thể, người ta sẽ sử dụng kết hợp các kỹ thuật biên với nhau như kết hợp kỹ thuật biên mở rộng với kỹ thuật biên trong trường hợp xấu nhất Khi đó, chung ta cần kiểm thử cả những giá trị

ngoài biên gồm : min-, min, min+, nom, max-, max, max+ Kỹ thuật này sẽ sinh ra số lượng lớn các ca kiểm thử, nếu có n biến đầu vào sẽ có 7 n ca kiểm thử được sinh

ra

Hình 3.4 Kết hợp kiểm thử biên rường hợp xấu nhẩt và kiểm thử biên mở rộng

Để dễ phân biệt các kỹ thuật kiểm thử biên ra xem hình dưới đây là sự so sánh các kỹ thuật biên ở trên Sự kết hợp các kỹ thuật khác nhau trong kiểm thử giá trị biên được coi là kỹ thuật kiểm thử giá trị đặc biệt và là kỹ thuật kiểm thử chức năng được

sử dụng rỗng rãi nhất Trong kỹ thuật này, kiểm thử viên dựa vào hiểu biết về kỹ thuật

và kinh nghiệm của họ với các chương trình tương tự, các thông tin để có phân hoạch miền giá trị đầu vào từ đó sinh ra các ca kiểm thử

Hình 3.5 So sánh các kỹ thuật kiểm thử biên

Nhận xét:

Ưu điểm: Kiểm thử giá trị biên là kỹ thuật có tính trực quan, dễ hiểu, dễ áp dụng

Vì việc sinh ca kiểm thử chỉ tập trung tại các biên của miền dữ liệu đầu vào nên khi sử dụng kỹ thuật này sẽ làm giảm đáng kể số lượng ca kiểm thử cần tạo và thực thi Kỹ thuật này phù hợp với hầu hết các hệ thống có miền giá trị đầu vào của các biến được chia thành nhiều phân vùng con Hơn nữa, ưu điểm lớn nhất của kỹ thuật này là xác suất tìm ra lỗi cao vì một tỉ lệ lớn các lỗi xảy ra tại vị trí biên và cận biên

Nhược điểm: Tuy có khá nhiều ưu điểm nhưng kiểm thử giá trị biên vẫn tồn tại

một vài hạn chế nhất định như: Để áp dụng được kỹ thuật này cần yêu cầu các biến đầu vào là các đại lượng vật lý và thực sự độc lập với nhau về mặt logic

Các bài toán áp dụng kỹ thuật kiểm thử biên: Kỹ thuật này nên áp dụng cho các hàm có biến đầu vào độc lập, không phụ thuộc nhau Khi chúng ta có giả định một khiếm khuyết trong chương trình sẽ gây ra lỗi ngay khi chúng ta sử dụng kiểm thử biên thông thường Trái lại khi lỗi thường xuất hiện khi có hơn một khiếm khuyết trong chương trình thì chúng ta cần sử dụng kiểm thử giá trị biên mạnh Các kỹ thuật này đều đơn giản, dễ dàng tự động hóa việc sinh và chạy các ca kiểm thử

3.1.3 Kỹ thuật bảng quyết định (Descision Table Testing)

Một yếu điểm của phân tích giá trị biên và phân lớp tương đương là chúng không khảo sát sự kết hợp của các trường hợp đầu vào Việc kiểm tra sự kết hợp đầu vào không phải là một nhiệm vụ đơn giản bởi vì nếu bạn phân lớp tương đương các trạng thái đầu vào, thì số lượng sự kết hợp thường là rất lớn Nếu bạn không có cách lựa chọn có hệ thống một tập con các trạng thái đầu vào, có lẽ bạn sẽ chọn ra một tập tùy hứng các điều kiện, điều này có thể dẫn tới việc kiểm thử không có hiệu quả

Bảng quyết định – Decision Table [4] là một công cụ được sử dụng để biểu diễn

và phân tích các quan hệ logic phức tạp Đó là một ý tưởng để mô tả các hành động xảy ra tương ứng với tập điều kiện của các biến đầu vào

Theo [2], ta có các bước để xây dựng ca kiểm thử dựa vào kỹ thuật bảng quyết định như sau:

(1) Xác định các nguyên nhân và kết quả dựa vào mỗi đặc tả:

(2) Liệt kê tất cả nguyên nhân và kết quả vào bảng quyết định Viết xuống các giá trị mà điều kiện có thể trả về (Y, N, -)

(3) Tính số lượng kết hợp có thể có Nó bằng số lượng giá trị khác nhau tăng lên

số lượng của điều kiện Ví dụ: Nếu điều kiện nhận 2 giá trị khác nhau(Y,N)

và có 4 điều kiện xảy ra thì số lượng kết hợp có thể có là 24

(4) Điền vào tất cả các cột tất cả các kết hợp có thể có Mỗi cột sẽ tương ứng với một kết hợp của các giá trị Còn với mỗi dòng (điều kiện) thì ta thực hiện như sau:

 Xác định tần số lặp (RF) bằng cách: chia số lượng còn lại của kết hợp cho

số lượng giá trị khác nhau của điều kiện

 Viết RF lần các giá trị đầu tiên, sau đó RF lần tiếp theo và vân vân, cho tới khi hàng đã được điền đủ

(5) Giảm thiểu các kết hợp (các nguyên tắc) Tìm các kết hợp không có ảnh hưởng, thay thế bằng dấu (-), và các kết hợp các cột giống nhau làm một Lưu

ý, trong suốt quá trình này phải đảm bảo rằng các kết quả là không bị thay đổi

(6) Kiểm tra độ bao phủ của các kết hợp (các nguyên tắc) Với mỗi cột tính số kết hợp mà nó đại diện Một (-) đại diện cho nhiều kết hợp như điều kiện đã có Nhân cho mỗi (-) xuống cột Thêm vào tổng số và so sánh với bước 3 Nó phải bằng nhau

(7) Thêm các kết quả vào cột trên bảng quyết định Đọc cột theo cột và xác định kết quả Nếu có nhiều hơn một kết quả xảy ra trong một sự kết hợp duy nhất, thì gán số thứ tự cho kết quả, từ đó xác định được thứ tự mà các kết quả sẽ được thực hiện Kiểm tra sự phù hợp của bảng quyết định

(8) Chuyển các cột trong bảng quyết định thành các ca kiểm thử

Sau khi xây dựng xong bảng quyết định, chúng ta sẽ tiến hành tạo các ca kiểm thử dựa trên cấu trúc bảng quyết định Thông thường tương ứng với mỗi luật sẽ có ít nhất một ca kiểm thử được sinh ta Nếu điều kiện của các luật là giá trị nhị phân (True/False), cần xây dựng ca kiểm thử cho từng điều kiện Nếu điều kiện của luật là một vùng, phạm vi giá trị, chúng ta cần phải chú ý xem xét và viết ca kiểm thử cho cả trường hợp biến đầu vào nhận giá trị thấp nhất (min) và cao nhất (max) tương ứng với vùng giá trị đó Ở bước này, kiểm thử viên cần kết hợp cả kỹ thuật kiểm thử giá trị biên và bảng quyết định để tạo ra bộ kiểm thử đầy đủ và chính xác (theo [3])

Để phân biệt các trường hợp kiểm thử với bảng quyết định, chúng ta cần làm sáng tỏ các điều kiện đầu vào và các hành động đầu ra Đôi khi các điều kiện cuối

cùng lại đề cập đến các lớp tương đương của các yếu tố đầu vào, và các hành động ám chỉ các phần xử lý chức năng chủ yếu của các mục được kiểm thử Các luật được hiểu như là các trường hợp được kiểm thử Bởi vì bảng quyết định có thể được thực hiện một cách máy móc cho đầy đủ, nên chúng ta thường xây dựng được một tập toàn vẹn các trường hợp kiểm thử

 Kỹ thuật này phù hợp cho các bài toán có sử dụng logic if – then-else

 Kiểm thử dựa trên bảng quyết định xử lý hiệu quả các bài toán có chứa quan hệ nguyên nhân và kết quả giữa đầu vào và đầu ra

3.2 Kiểm thử hộp trắng

Kỹ thuật kiểm thử hộp trắng hay còn gọi là kiểm thử hướng cấu trúc thường được

áp dụng để kiểm tra tính đúng đắn của mã nguồn (được lập trình) Đầu vào của kỹ thuật này là các mã nguồn, mã lệnh chứ không phải là chương trình đã được thực thi

Do đó, kỹ thuật này được áp dụng để kiểm thử cấu trúc chương trình, dòng điều khiển

và dòng xử lý dữ liệu của chương trình

Kỹ thuật này thường tốn thời gian, công sức để thực hiện, nên thường chỉ áp dụng ở mức độ kiểm thử đơn vị (hàm, lớp thành phần) của chương trình chứ không thực hiện ở các mức độ cao hơn

Các kỹ thuật kiểm thử hộp trắng là: Kiểm thử dòng điều khiển, kiểm thử dòng dữ liệu và kiểm thử miền

3.2.1 Kỹ thuật dòng điều khiển (Control Flow Testing)

Kỹ thuật dòng điều khiển là kỹ thuật là các testcase được sinh ra dựa việc mô hình hóa các luồng xử lý (hành vi của hệ thống) theo khái niệm đồ thị dòng điều khiển (control flow graph) Để tiến hành xác định kiểm thử, ta sẽ mô hình hóa các dòng lệnh

từ mã nguồn bằng đồ thị dòng điều khiển Từ đồ thị đó, mỗi rẽ nhánh trong luồng xử

lý sẽ sinh ra một đường đi Dựa trên các đường đi ta sẽ sinh được các testcase tương ứng

Kỹ thuật này là kỹ thuật kiểm thử căn bản và được áp dụng hiệu quả cho nhiều hệ thống, nhiều giai đoạn test khác nhau

Các bộ giá trị kiềm thử sinh ra từ kỹ thuật này có thể kiểm tra được tính đúng đắn với các thành phần của chương trình gồm: Các phương thức ( Method ), các câu lệnh

(Statement ), các nhánh (branch), các điều kiện (if, switch…)

Hình 3.6 Sơ đồ dòng điều khiển

Các ký hiệu sử dụng trong đồ thị CFG:

Hình 3.7 Các ký hiệu sử dụng trong đồ thị

Để xác định mức độ bao phủ của chương trình của một tập ca kiểm thử cho trước

ta sử dụng khái niệm độ đo kiểm thử Theo [1]: Mức độ bao phủ của một tập kiểm thử được đo bằng tỷ lệ các thành phần thực sự được kiểm thử so với tổng thể sau khi thực hiện ca kiểm thử Độ bao phủ càng lớn thì độ tin cậy của bộ kiểm thử ngày càng cao

Có ba độ đo kiểm thử đang được sử dụng phổ biến [3]:

Độ đo kiểm thử cấp 1 (C 1 ) : mỗi câu lệnh được thực hiện ít nhất 1 lần sau khi

chạy hết các ca kiểm thử

Độ đo kiểm thử cấp 2 (C 2 ) : các điểm quyết định trong đồ thị đều được thực hiện

ít nhất một lần cả hai nhánh đúng và sai

Độ đo kiểm thử cấp 3 (C 3 ) : Với các điều kiện phức tạp (chứa nhiều điều kiện

con cơ bản), việc chỉ quan tâm đến giá trị đúng sai là không đủ để kiểm tra tính đúng đắn của chương trình ứng với điều kiện phức tạp này Do đó, điều kiện để đảm bảo độ

đo này là các điều kiện con thuộc các điều kiện phức tạp tương ứng với các điểm quyết định trong đồ thị dòng điều khiển của đơn vị cần kiểm thử đều được thực hiện ít nhất một lần cả hai nhánh đúng và sai

Từ các định nghĩa về độ đo, ta có thể áp dụng kiểm thử độ đo để xác định số ca kiểm thử sao cho các ca kiểm thử bao phủ một độ đo nào đó Theo [1], ta có số đường

đi ứng với đồ thị dòng điều khiển sẽ được tính bằng một trong hai cách như sau:

1 Số cạnh – số đỉnh + 2

2 Số đỉnh quyết định + 1

Ứng với mỗi đường đi ta sẽ sinh ra được một ca kiểm thử tương ứng

Bên cạnh việc tiến hành xây dựng kiểm thử dựa trên độ đo, ta nhận thấy vẫn chưa kiểm tra được các lỗi phát sinh do xuất hiện vòng lặp trong chương trình Mặt khác, trong quá trình viết mã nguồn cho các đơn vị/hàm, các lỗi gây ra do sử dụng vòng lặp

là khá nhiều và gây ảnh hưởng lớn đến chương trình Theo [1], với chương trình có vòng lặp ta cần quan tâm đến loại vòng lặp là:

Lệnh lặp đơn giản: Tức là đơn vị chương trình chỉ có chứa một lệnh lặp

Lệnh lặp liền kề: Tức là đơn vị chương trình chứa lệnh lặp liền kề nhau

Lệnh lặp lồng nhau: Tức là đơn vị chương trình chứa lệnh lặp mà trong nó còn chứa lênh lặp khác

Để tiến hành kiểm thử với vòng lặp, ta sẽ xây dựng các ca kiểm thử dựa trên số lần thực hiện của vòng lặp trong chương trình gồm:

xác định được lệnh lặp thực hiện n+1 lần, ta chỉ áp dụng sinh kiểm thử với 6 trường hợp trước đó

Kết luận:

Kỹ thuật kiểm thử dòng điều khiển là kỹ thuật phát hiện các lỗi tiềm ẩn của chương trình bằng các xác định các đường đi tương ứng với dòng điều khiển của chương trình từ đồ thị dòng điều khiển Với mỗi một đường đi của đồ thị, ta sẽ xây dựng một ca kiểm thử và đảm bảo đường đi là thực thi được

Trên thực tế, có không nhiều các công ty phần mềm áp dụng kỹ thuật kiểm thử này do việc áo dụng là khó, tốn kém hơn các kỹ thuật kiểm thử hộp đen [1] Tuy nhiên, có một số công cụ đã hỗ trợ việc thực hiện kỹ thuật này bằng việc thực thi các

ca kiểm thử trên một đơn vị hàm, đề xác định tính đúng đắn của hàm dựa trên kết quả chạy ca kiểm thử

3.2.2 Kỹ thuật dòng dữ liệu (Data Flow Testing)

Kỹ thuật kiểm thử dòng dữ liệu là kỹ thuật mà việc sinh ca kiểm thử được dựa trên các đường đi sinh ra từ đồ thị dòng dữ liệu Khi đó, các đường dẫn kiểm thử của chương trình sẽ được lựa chọn dựa vào vị trí khai báo và sử dụng các biến trong chương trình

Trong quá trình lập trình, mỗi lập trình viên đều có thể sinh ra các câu lệnh “bất thường” hoặc không tuân theo chuẩn lập trình Những câu lệnh bất thường đó có thể là việc khai báo biến, dữ liệu không đúng, khởi tạo giá trị biến không đúng hoặc sử dụng biến, gán giá trị…Những vấn đề đó là những vấn đề về dòng dữ liệu của đơn vị chương trình Theo [1], các vấn đề này được chia thành ba loại như sau:

 Gán giá trị rồi gán tiếp giá trị (loại 1)

 Chưa gán giá trị nhưng được sử dụng (loại 2)

 Đã được khai báo và gán giá trị nhưng không được sử dụng (loại 3)

Huang [7] đã giới thiệu một phương pháp để xác định những bất thường trong việc sử dụng các biến dữ liệu bằng cách sử dụng sơ đồ chuyển trạng thái ứng với mỗi biến dữ liệu của chương trình

Để áp dụng kỹ thuật kiểm thử dòng dữ liệu động, chúng ta phải xác định các đường dẫn chương trình có một điểm đầu vào và một điểm đầu ra sao cho nó bao phủ việc gán giá trị và sử dụng mỗi biến của chương trình/đơn vị chương trình cần kiểm thử Các bước thực hiện như sau [1]:

 Xây dựng đồ thị dòng dữ liệu của chương trình/đơn vị chương trình

 Chọn một hoặc một số tiêu chí kiểm thử dòng dữ liệu

 Xác định các đường dẫn chương trình phù hợp với tiêu chí kiểm thử đã chọn

 Lấy ra các biểu thức điều kiện từ tập các đường đi, thực hiện giải các biểu thức điều kiện để có được các giá trị đầu vào cho các ca kiểm thử tương

ứng với các đường đi này và tính toán giá trị đầu ra mong đợi của mỗi ca kiểm thử

 Thực hiện các ca kiểm thử để xác định các lỗi (có thể có) của chương trình

 Sửa các lỗi (nếu có) và thực hiện lại tất cả các ca kiểm thử trong trường hợp bước trên phát hiện ra lỗi

Sau khi xây dựng đồ thị dòng dữ liệu của đơn vị chương trình, chúng ta cần xác định các đường đi của đơn vị chương trình của mỗi biến dữ liệu ứng với các độ đo kiểm thử Trong mỗi đường dẫn này, biến dữ liệu được định nghĩa tại một đỉnh nào đó

và được sử dụng tại các câu lệnh tiếp theo ứng với các đỉnh hoặc các cạnh của đường

đi này

Theo [1] ta có một số khái niệm cơ bản về dòng dữ liệu gồm:

Định nghĩa Global c-use: Giả sử biến x được sử dụng để tính toán (c-use) tại

đỉnh i của đồ thị dòng dữ liệu Việc sử dụng biến x tại đỉnh i được gọi là Global c-use nếu x đã được định nghĩa ở các đỉnh trước đó

Định nghĩa Def -clear path: Giả sử biến x được định nghĩa (def ) tại đỉnh i và

được sử dụng tại đỉnh j Một đường đi từ i đến j ký hiệu là (i- n1- – nm - j ) với m ≥

0 được gọi là Def -clear path ứng với biến x nếu biến này không được định nghĩa tại các đỉnh từ n1 đến nm

Định nghĩa Global def: Một đỉnh i được gọi là Global def của biến x nếu đỉnh

này định nghĩa biến x (def ) và có một Def -clear path của x từ đỉnh i tới đỉnh chứa một Global c-use hoặc cạnh chứa một p-use của biến này

Định nghĩa Simple path: Một đường đi trong đồ thị dòng dữ liệu được gọi là một

Simple path nếu các đỉnh chỉ xuất hiện đúng một lần trừ đỉnh đầu và đỉnh cuối

Định nghĩa Loop-free path: Một đường đi trong đồ thị dòng dữ liệu được gọi là

một Loop-free path nếu các đỉnh chỉ xuất hiện đúng một lần

Định nghĩa Complete-path: Một đường đi được gọi là một Complete-path nếu nó

có điểm bắt đầu và điểm kết thúc chính là điểm bắt đầu và điểm kết thúc của đồ thị dòng dữ liệu

Định nghĩa Du-path Một đường đi (n1- n2- – nj – nk) được gọi là một Du-path (definition-use path) ứng với biến x nếu đỉnh n1 là Global def của biến x và:

đỉnh nk có một Global c-use với biến x và (n1- n2- – nj – nk) là một Def -clear simple path với biến x, hoặc

cạnh (nj, nk) có p-use với biến x và (n1- n2- – nj) là Def –clear loop-free path với biến này

Các độ đo hay các tiêu chí kiểm thử dòng dữ liệu là đầu vào cùng với đồ thị dòng

dữ liệu nhằm xác định các đường đi cho mục đích kiểm thử tương ứng Các độ đo phổ

biến đang được sử dụng trong kiểm thử dòng dữ liệu gồm ba độ đo đơn giản là

All-defs, All-c-uses, và All-p-uses tương ứng với tất cả các đường đi, đường đi qua tất cả

các đỉnh, và đường đi qua tất cả các cạnh

Hình 3.8 Mối quan hệ giữa các độ đo kiểm thử dòng dữ liệu

Để tiến hành sinh ca kiểm thử dựa trên kỹ thuật kiểm thử dòng dữ liệu, chúng ta phải sinh đồ thị dòng dữ liệu từ đơn vị chương trình Sau đó, từ đồ thị áp dụng từng độ

đo kiểm thử, chúng ta sẽ xác định tất cả các đường đi đầy đủ (Complete-paths) thỏa mãn độ đo này Từ đường đi được xác định, ta sẽ tiến hành sinh bộ dữ liệu đầu vào Không phải bất cứ đường đi nào cũng có thể tìm được một bộ dữ liệu đầu vào để nó được thực thi được khi chạy đơn vị chương trình Nếu tồn tại một bộ dữ liệu đầu vào như vậy thì đường đi tương ứng được gọi là đường đi thực thi được [1]

Nhận xét:

Các trường hợp nên sử dụng kỹ thuật kiểm thử dòng dữ liệu khi đơn vị chương trình thuộc [1]:

 Khi chương trình có nhiều tính toán

 Khi chương trình có nhiều lệnh rẽ nhánh và biến của biểu thức điều kiện này cũng được tính toán (p-use)

Theo [1], so với kỹ thuật kiểm thử dòng điều khiển, kỹ thuật kiểm thử dòng dữ liệu khó áp dụng hơn và có độ khó hơn Đối với những chương trình có kích thước lớn thì việc áp dụng kỹ thuật này khá phức tạp

Chương 4.Bài toán áp dụng

Chương 4 trình bày nội dung phân tích, đánh giá, nhận xét, kết luận sau khi áp dụng các kỹ thuật kiểm thử cho các hàm tính toán chỉ số thuộc nghiệp vụ chứng khoán

Chương 4 sẽ trình bày ba bài toán tương ứng với ba hàm tính toán chỉ số thuộc nghiệp vụ chứng khoán Với mỗi bài toán, các yêu cầu đặc tả sẽ được mình họa bởi hai hàm tương ứng với hai đoạn mã nguồn (code) khác biệt bao gồm một mã nguồn đúng

và một mã nguồn lỗi Mỗi bài toán sẽ áp dụng bốn kỹ thuật kiểm thử được trình bày ở chương 3 gồm:

1 Kỹ thuật phân lớp tương đương

4.1 Bài toán 1

Phát biểu bài toán: Xác định ngày thực hiện giao dịch theo ngày đăng ký cuối

Bài toán được mô tả như sau:

Ngày thực hiện giao dịch của chỉ số sẽ tính theo giá trị của ngày đăng ký cuối cùng của chỉ số, phụ thuộc vào từng hình thức thực hiện quyền đã quy định

Nếu hình thức thực hiện quyền là hình thức trả cổ tức bằng tiền mặt thì ngày thực hiện giao dịch sẽ bằng ngày đăng ký cuối cùng lùi lại 2 ngày

Nếu hình thức thực hiện quyền là hình thức niêm yết bổ sung thì ngày thực hiện giao dịch sẽ bằng ngày đăng ký cuối cùng lùi lại 1 ngày

Nếu hình thức thực hiện quyền là hình thức thay đổi tỷ lệ Free float thì ngày thực hiện giao dịch sẽ chính là ngày đăng ký cuối cùng

Ngoài ra, ngày thực hiện giao dịch phải là ngày làm việc trong tuần, không tính ngày thứ bảy, chủ nhật và ngày nghỉ lễ tết trong năm

Xác định dữ liệu như sau:

Dữ liệu đầu vào:

 Ngày đăng ký cuối cùng kiểu Datetime

 Hình thức thực hiện quyền kiểu Int được quy định như sau:

 Hình thức trả cổ tức bằng tiền mặt là 1

 Hình thức niêm yết bổ sung là 2

 Hình thức thay đổi tỷ lệ Free float là 3

Dữ liệu đầu ra: Ngày thực hiện giao dịch kiểu Datetime

Từ phân tích bài toán theo đặc tả yêu cầu ta áp dụng các kỹ thuật kiểm thử để xây dựng ca kiểm thử như sau:

4.1.1 Áp dụng kỹ thuật phân lớp tương đương

Đối với biến thứ nhất là ngày đăng ký cuối cùng ta sẽ phân hoạch tương đương dựa vào sự kết quả trả ra khi truyển dữ liệu đầu vào khác nhau như sau:

Miền 1 là các dữ liệu đầu vào là ngày thường mà khi áp dụng theo từng hình thức thì ngày thực hiện quyền vẫn là ngày thường

Miền 2 là các dữ liệu đầu vào là ngày nghỉ, ngày lễ tết Trong miền 2 ta lại chia thành hai miền con như sau:

o Miền con 1: các ngày nghỉ, ngày lễ tết mà ngày thực hiện quyền chỉ tính lại 1 ngày là thỏa mãn điều kiện không phải là ngày nghỉ

o Miền con 2: các ngày nghỉ, ngày lễ tết mà ngày thực hiện quyền chỉ tính lại nhiều hơn 1 ngày là thỏa mãn điều kiện không phải là ngày nghỉ

Do đó số miền tương đương sinh ra là 3 miền, hai giá trị biên là giá trị tại đó là ngày thứ 7 và giá trị tại đó là ngày chủ nhật

Đối với dữ liệu đầu vào biến thứ hai là hình thức thực hiện quyền (kiểu int) Ta sẽ

có các miền dữ liệu gồm miền các dữ liệu không là hình thức thực hiện quyền tức là các giá trị < 1 hoặc > 3; giá trị =1, giá trị =2, giá trị =3 Do đó, sẽ sinh ra 3 miền tương đương

Ta có các ca kiểm thử được sinh ra gồm 7 testcase như sau:

Bảng 4.2 Các ca kiểm thử sinh ra theo kỹ thuật phân lớp tương đương

TC1 27/11/2014 Không là hình thức nào Không có giá trị trả ra do không thuộc hình

thức nào

4.1.2 Áp dụng kỹ thuật Bảng quyết định

Ta sẽ xây dựng ca kiểm thử dựa trên các mô tả về yêu cầu như sau:

Mô tả 1:(C1) Nếu hình thức thực hiện quyền trả cổ tức bằng tiền thì (E1) ngày thực hiện là ngày đăng ký cuối cùng -2

Mô tả 2: (C2) Nếu hình thức thực hiện quyền niêm yết bổ sung thì (E2) ngày thực hiện là ngày đăng ký cuối cùng -1

Mô tả 3: (C3) Nếu hình thức thực hiện quyền thay đổi tỷ lệ free float thì (E3) ngày thực hiện là ngày đăng ký cuối cùng

Mô tả 4: (C4) Nếu ngày thực hiện quyền là ngày nghỉ lễ tết thì (E4) ngày thực hiện phải tính lùi lại 1 ngày cho đến khi ngày thực hiện không là ngày nghỉ lễ

Từ bốn mô tả trên ta sẽ có bảng quyết định như sau:

Bảng 4.3 Bảng quyết định cho bài toán 1

Nhìn vào bảng quyết định, ta có các trường hợp điều kiện C1, C2, C3 chỉ có thể nhận giá trị Y,N là duy nhất Do theo mô ta bài toán, ta sẽ có với 1 cặp giá trị đầu vào thì chỉ có thể xảy ra trường hợp hoặc C1, hoặc C2, hoặc C3 là true, không thể xảy ra đồng thời giá trị true Từ bảng quyết định ra có 16 trường hợp, tuy nhiên sau khi loại trừ các trường hợp không khả thi, ta sẽ còn lại 6 trường hợp cần kiểm thử Ứng với trường hợp 6, khi ngày thực hiện chính là ngày đăng ký cuối cùng, ta nhận thấy sẽ không xảy ra trường hợp thỏa mãn cả điều kiện là hình thức thực hiện Thay đổi tỷ lệ FreeFloat và là ngày đăng ký cuối cùng là ngày nghỉ lễ Do ngày thực hiện sẽ không là ngày nghỉ lễ Từ đó trong 16 trường hợp sinh ra từ bảng quyết định chỉ có 5 trường hợp là thực thi được

Từ bảng quyết định trên, ta có số testcase được sinh ra gồm:

Bảng 4.4 Các ca kiểm thử sinh ra theo kỹ thuật bảng quyết định

4.1.3 Áp dụng kỹ thuật kiểm thử dòng điều khiển

Áp dụng kỹ thuật kiểm thử dòng điều khiển ta sẽ phân tích bài toán theo mã nguồn và theo tiêu chí phủ rẽ nhánh để kiểm thử dựa vào độ đo kiểm thử cấp 2 tức là