(Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng

(Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng (Luận văn thạc sĩ) Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng

ĐẠI HỌC THÁI NGUYÊN

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN & TRUYỀN THÔNG

ĐẠI HỌC THÁI NGUYÊN

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN & TRUYỀN THÔNG

–––––––––––––––––––––––––

NGUYỄN THỊ HỒNG THUỶ

KỸ THUẬT MA TRẬN ĐỒ THỊ TRONG PHƯƠNG PHÁP KIỂM THỬ HỘP TRẮNG

Chuyên ngành: Khoa học máy tính

Mã số : 848 01 01

LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH

Người hướng dẫn khoa học: TS Lê Văn Phùng

Thái nguyên – 2020

LỜI CAM ĐOAN

Tôi xin cam đoan toàn bộ nội dung luận văn này là do tôi tự sưu tầm, tra cứu thông tin trên mạng Internet, trong một số sách tham khảo

để sắp xếp, hoàn thiện cho phù hợp với nội dung yêu cầu của đề tài

Đến nay, nội dung luận văn của tôi chưa từng được công bố hay xuất bản dưới bất kỳ hình thức nào Nếu sai tôi xin chịu hoàn toàn trách nhiệm

Ngày tháng năm 2020

Tác giả

Nguyễn Thị Hồng Thuỷ

LỜI CẢM ƠN

Trong suốt quá trình học tập và thực hiện đề tài, em đã nhận được

sự giúp đỡ tận tình và những chỉ bảo ân cần của các Thầy cô trong viện Công nghệ thông tin – Viện khoa học và công nghệ Việt nam, các Thầy

cô trong trường đại học Công nghệ Thông tin và Truyền thông, cùng các

bạn bè đồng nghiệp Đặc biệt là sự giúp đỡ của TS Lê Văn Phùng,

người thầy trực tiếp hướng dẫn, định hướng, chỉnh sửa các kiến thức chuyên môn và tận tình giúp đỡ em trong suốt quá trình nghiên cứu và thực hiện luận văn

Qua đây cho phép em được bày tỏ lời cảm ơn tới tất cả các thầy cô giáo ở Viện Công nghệ thông tin và Trường Đại học Công nghệ Thông tin và Truyền thông, đã giảng dạy và tạo mọi điều kiện thuận lợi giúp đỡ chúng em trong quá trình học tập, nghiên cứu

Cuối cùng, tôi xin cảm ơn đến gia đình, các bạn bè đồng nghiệp đã chia sẻ động viên giúp đỡ tôi về chuyên môn cũng như về mọi mặt trong cuộc sống, đó là nguồn động viên khích lệ giúp tôi có nghị lực hơn để hoàn thành khoá học

Học viên

Nguyễn Thị Hồng Thuỷ

MỤC LỤC

Trang

LỜI CAM ĐOAN i

LỜI CẢM ƠN ii

MỤC LỤC iii

DANH MỤC CÁC KÝ HIỆU/VIẾT TẮT vi

DANH MỤC CÁC HÌNH vii

DANH MỤC CÁC BẢNG viii

PHẦN MỞ ĐẦU 1

1 Lý do chọn đề tài 1

2 Đối tượng và phạm vi nghiên cứu 1

3 Mục tiêu và nhiệm vụ nghiên cứu 2

4 Phương pháp nghiên cứu 2

5 Ý nghĩa khoa học của đề tài 2

6 Bố cục của luận văn: 2

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ KIỂM THỬ HỘP TRẮNG 3

1.1 Kiểm thử phần mềm 3

1.1.1 Quan niệm về kiểm thử phần mềm 3

1.1.2 Chiến lược kiểm thử phần mềm 3

1.1.3 Các mức kiểm thử [9] 4

1.1.4 Sơ lược về các phương pháp kiểm thử 5

1.2.1 Ý tưởng của kiểm thử hộp trắng 6

1.2.2 Mô tả một số cấu trúc theo lược đồ 7

1.2.3 Một số hướng chính về kiểm thử hộp trắng 8

CHƯƠNG 2 MỘT SỐ KỸ THUẬT HIỆU QUẢ TRONG PHƯƠNG PHÁP KIỂM THỬ HỘP TRẮNG VÀ CA KIỂM THỬ16 2.1 Một số kỹ thuật chính trong phương pháp kiểm thử hộp trắng 16

Có thể tổng hợp một số kỹ thuật hiệu quả trong phương pháp kiểm thử hộp trắng như sau: 16

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

2.1.2 Kỹ thuật kiểm thử dòng dữ liệu 18

2.1.3 Kỹ thuật kiểm thử BRO 19

2.1.4 Kỹ thuật kiểm thử đột biến 20

2.2 Ca kiểm thử 22

2.2.1.Một số quan niệm về ca kiểm thử 22

2.2.2.Nội dung thiết kế ca kiểm thử 22

2.2.3 Một số phương pháp chính để thiết kế ca kiểm thử 23

2.3 Kỹ thuật ma trận đồ thị cho thiết kế ca kiểm thử 27

2.3.1 Ý tưởng và nội dung kỹ thuật ma trận đồ thị [8] 27

2.3.2 Quy trình kiểm thử phần mềm bằng kỹ thuật ma trận đồ thị 36

CHƯƠNG 3 CHƯƠNG TRÌNH THỬ NGHIỆM KIỂM THỬ PHẦN MỀM BẰNG KỸ THUẬT MA TRẬN ĐỒ THỊ 38

3.1 Chọn mô-đun phần mềm thử nghiệm 38

3.2 Thiết kế ca kiểm thử và kiểm thử mô-đun phần mềm 39

3.2.1 Quy trình thiết kế 39

3.2.2 Nội dung thiết kế 39

3.3 Một số giao diện chính của chương trình 49

3.3.1 Giao diện thiết kế ca kiểm thử theo kỹ thuật ma trận đồ thị 49

3.3.2 Quá trình test với Mô-đun 1 54

3.3.3 Quá trình test với Mô-đun 2 57

3.3.4 Quá trình test với Mô-đun 3 60

3.3.5 Quá trình test với Mô-đun 4 62

3.3.6 Kiểm thử vòng lặp While 63

3.4 Đánh giá và so sánh kỹ thuật ma trận đồ thị với một số kỹ thuật thiết kế ca kiểm thử khác 64

3.5 Đánh giá kết quả thử nghiệm và hướng mở rộng 66

KẾT LUẬN VÀ KIẾN NGHỊ 67

1.Kết luận 67

2 Kiến nghị 68

TÀI LIỆU THAM KHẢO 69

DANH MỤC CÁC HÌNH

Hình 1.1 Mô hình chiến lược kiểm thử tổng thể 5

Hình 1.2 Một số cấu trúc lập trình 8

Hình 1.3 Sơ đồ điều khiển chương trình 9

Hình 1.4 Đồ thị của chương trình 10

Hình 1.5 Minh hoạ về độ phức tạp của câu lệnh 10

Hình 1.6 Minh hoạ về các bước kiểm tra 11

Hình1.7 Lược đồ kiểm thử theo đường dẫn 12

Hình1.8 Lược đồ kiểm thử đường dẫn theo biểu thức điều kiện 13

Hình 1.9.Các kiểu vòng lặp 14

Hình 2.1: Các thành phần cơ bản của đồ thị chương trình 17

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

Hình 2.3: Mã nguồn của hàm foo và đồ thị dòng điều khiển của nó 18

Hình 2.4: Sơ đồ điều khiển của chương trình 30

Hình 2.5: Sơ đồ luồng điều khiển 30

Hình 2.6 : Đồ thị dòng dùng để xác định ma trận kiểm thử 31

Hình 2.7: Độ phức tạp chu trình được xác định từ số miền phẳng trong đồ thị dòng 32

Hình 2.8 : Đồ thị dòng dùng để xác định ma trận kiểm thử 33

Hình 3.1 Sơ đồ điều khiển của chương trình 40

Hình 3.2 Sơ đồ luồng điều khiển 41

Hình 3.3 Đồ thị dòng 42

Hình 3.4 Độ phức tạp của chu trình 43

Hình 3.5 Đồ thị dòng 44

Hình 3.6 Giao diện trang chủ 49

Hình 3.7 Giao diện hướng dẫn sử dụng của chương trình 50

Hình 3.8 Giao diện chính chạy chương trình 50

Hình 3.9: Hộp thoại Open để tìm đường dẫn 51

Hình 3.10: Form hiển thị mô-đun cần kiểm thử 51

Hình 3.11 Giao diện xác định tập đường cơ bản 52

Hình 3.12: Giao diện thông báo lỗi khi nhập dữ liệu không hợp lệ 53

Hình 3.13: Giao diện test đơn vị chương trình code_1 53

Hình 3.14: Form xử lý với đơn vị chương trình code_2 59

Hình 3.15: Lỗi tìm thấy trong mô-đun code_2 60

Hình 3.16: Form kiểm thử ứng với code_3 61

Hình 3.17: Form kiểm thử ứng với code_4 63

DANH MỤC CÁC BẢNG

Bảng 2.1 Ví dụ minh họa các đột biến 21

Bảng 2.2 : Những chiến lược kết hợp 23

Bảng 2.3 Tập đường cơ bản 32

Bảng 2.4 : Ma trận kiểm thử A và cách tính độ phức tạp V(G) 34

Bảng 2.5 Bảng ma trận kiểm thử A= (aij) với i,j=1,2,3,4, ,9 được xác định như sau: 34

Bảng 2.6 : Ví dụ ma trận kiểm thử tích A2= 36

Bảng 3.1-Bảng tính độ phức tạp của đồ thị dòng V(G): 45

Bảng 3.2: Bảng ma trận kiểm thử A= (aij) với i,j=1,2,3,4, ,14 45

Bảng 3.3: Các Test path 48

Bảng 3.4: Bảng các ca kiểm thử vòng lặp while 49

Bảng 3.5: Bảng TestData1 55

Bảng 3.6: Bảng TestData2 55

Bảng 3.7: Bảng TestData3 55

Bảng 3.8: Bảng TestData4 56

Bảng 3.9: Bảng TestData5 56

Bảng 3.10: Bảng TestData6 56

Bảng 3.11: Bảng TestData7 57

Bảng 3.12: Bảng TestData với code_2 58

Bảng 3.13: Kết quả bảng TestData với code_2 59

Bảng 3.14: Bảng TestData với code_3 61

Bảng 3.15: Bảng TestData với code_4 62

PHẦN MỞ ĐẦU

1 Lý do chọn đề tài

Quy trình phát triển phần mềm thường trải qua nhiều giai đoạn, trong

đó kiểm thử phần mềm là một trong các hoạt động chủ chốt nhằm phát hiện lỗi và đảm bảo chất lượng phần mềm Trước khi sản phẩm được phát hành, tất

cả các chức năng cũng như giao diện, ứng dụng của sản phẩm đó đều cần qua kiểm thử Kiểm thử hiệu quả sẽ phát hiện ra được các sai sót, tránh các lỗi trước khi phát hành sản phẩm

Để kiểm thử đạt hiệu quả cao, người kiểm thử cần vạch ra chiến lược kiểm thử, đó là sự tích hợp các kỹ thuật thiết kế ca kiểm thử Một trong các kỹ thuật đó, không thể không nhắc đến đó là kỹ thuật ma trận đồ thị Kỹ thuật ma

trận đồ thị là một trong những kỹ thuật của phương pháp kiểm thử hộp trắng

Ma trận kiểm thử được sử dụng như một dữ liệu có cấu trúc để kiểm tra các con đường cơ bản Ma trận kiểm thử là một công cụ mạnh trong việc đánh giá cấu trúc điều khiển chương trình

Qua luận văn này, tôi mong muốn mọi người có những kiến thức cơ bản về kiểm thử phần mềm nói chung, kiểm thử hộp trắng nói riêng Đặc biệt, tôi mong có thể đóng góp vào việc xây dựng quy trình thiết kế ca kiểm thử bằng kỹ thuật ma trận đồ thị

Trên đây là những lí do mà tôi chọn đề tài: “Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng” làm luận văn thạc sĩ của mình

2 Đối tượng và phạm vi nghiên cứu

- Kiểm thử phần mềm nói chung và kiểm thử hộp trắng nói riêng

- Một số kỹ thuật chính về thiết kế ca kiểm thử

- Kỹ thuật ma trận đồ thị để thiết kế ca kiểm thử

- Xây dựng phần mềm thử nghiệm kiểm thử bằng kỹ thuật ma trận đồ thị

- Áp dụng kỹ thuật ma trận đồ thị để kiểm thử phần mềm và so sánh với một

số kỹ thuật thiết kế ca kiểm thử khác

3 Mục tiêu và nhiệm vụ nghiên cứu

- Luận văn tập trung nghiên cứu, tìm hiểu về kiểm thử phần mềm, phương pháp kiểm thử hộp trắng, ca kiểm thử, đặc biệt là kiểm thử phần mềm bằng

kỹ thuật ma trận đồ thị

- Thiết kế chương trình kiểm thử để kiểm thử một số đơn vị chương trình

4 Phương pháp nghiên cứu

- Phương pháp nghiên cứu lý thuyết: Sưu tập tài liệu, tổng hợp các phương

pháp kiểm thử phầm mềm, tập trung vào phương pháp kiểm thử hộp trắng, nghiên cứu chi tiết quy trình thực hiện kỹ thuật ma trận đồ thị

- Phương pháp nghiên cứu thực nghiệm: Cài đặt thử nghiệm chương trình

kiểm thử phần mềm bằng kỹ thuật ma trận đồ thị

- Phương pháp trao đổi khoa học: Trao đổi nội dung nghiên cứu với người

hướng dẫn, các đồng nghiệp để đề xuất và giải quyết các nội dung luận văn đề

ra

5 Ý nghĩa khoa học của đề tài

Kết quả thử nghiệm của đề tài một mặt thể hiện tính đúng về mặt lý thuyết, một mặt vừa mang tính minh hoạ vừa thể hiện khả năng ứng dụng hiệu quả

6 Bố cục của luận văn:

Toàn bộ nội dung của luận văn được chia thành ba chương như sau:

Chương 1: Tổng quan về kiểm thử phần mềm và kiểm thử hộp trắng Chương 2: Một số kỹ thuật hiệu quả trong phương pháp kiểm thử hộp

trắng và ca kiểm thử

Chương 3: Chương trình thử nghiệm kiểm thử phần mềm bằng kỹ thuật

ma trận đồ thị

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ KIỂM THỬ HỘP TRẮNG

1.1 Kiểm thử phần mềm

1.1.1 Quan niệm về kiểm thử phần mềm

Kiểm thử phần mềm (Software Testing) là một yếu tố quan trọng trong vấn

đề xác minh và thẩm định Việc kiểm thử cung cấp một thành luỹ cuối cùng để

có thể thẩm định về mặt chất lượng, chứng thực hơn, phát hiện ra lỗi [7]

Theo Glen Myers, 1979, kiểm thử phần mềm là quá trình vận hành

chương trình để tìm ra lỗi Một ca kiểm thử tốt là ca kiểm thử có xác suất cao

tìm ra một lỗi chưa được phát hiện Một ca kiểm thử thắng lợi là ca kiểm thử làm lộ ra được ít nhất một lỗi còn chưa phát hiện Với cách nhìn này, mục tiêu của chúng ta là thiết kế các ca kiểm thử để có thể phát hiện một cách hệ thống các loại lỗi khác nhau với chi phí thời gian và công sức ít nhất có thể

Phát hiện lỗi là công việc của kiểm thử Nhưng kiểm thử phần mềm không phải là gỡ lỗi

Kiểm thử phần mềm là một trong những yếu tố góp phần bảo đảm chất lượng phần mềm, là khâu điển hình kiểm soát đặc tả, thiết kế, lập mã

Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm ra lỗi, đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng Kiểm thử phần mềm cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm Kiểm thử phần mềm tạo điều kiện tận dụng tối

đa tư duy đánh giá và sáng tạo để có thể phát hiện ra những điểm mà người khác chưa nhìn thấy

1.1.2 Chiến lược kiểm thử phần mềm

Chiến lược kiểm thử là sự tích hợp các kỹ thuật thiết kế “ca kiểm thử” tạo thành một dãy các bước nhằm hướng dẫn quá trình kiểm thử phần mềm thành công [9]

Ca kiểm thử (test case) là một tình huống kiểm thử tương ứng với một mạch hoạt động của chương trình Nó bao gồm một tập các giá trị đầu vào và một danh sách các kết quả đầu ra mong muốn và thực tế

Chiến lược kiểm thử được đặt ra với các mục tiêu nhằm phác thảo lộ trình để:

- Nhà phát triển tổ chức việc bảo đảm chất lượng bằng kiểm thử;

- Khách hàng hiểu được công sức, thời gian và nguồn lực cần cho kiểm thử

Chiến lược kiểm thử cần đạt các yêu cầu sau:

- Tích hợp các khâu như lập kế hoạch, thiết kế ca kiểm thử, tiến hành kiểm thử, thu thập và đánh giá các thông tin kết quả;

- Đủ mềm dẻo để cổ vũ óc sáng tạo, đáp ứng được yêu cầu khách hàng;

Mức 1 Kiểm thử đơn vị (Unit testing);

Mức 2 Kiểm thử tích hợp (Integration testing);

Mức 3 Kiểm thử hệ thống (System testing), bao gồm:

- Kiểm thử chức năng (functional test: system and interface)

- Kiểm thử phục hồi (recovery test)

- Kiểm thử chịu tải (extra: stress and load test)

- Kiểm thử thi hành (performance test)

- Kiểm thử an ninh (security test)

Mức 4 Kiểm thử chấp nhận (acceptance testing)/thẩm định

Có 2 tiến trình thực hiện kiểm thử:

Tiến trình 1 Tiến trình thực hiện kiểm thử tương ứng với tiến trình phát triển (theo từng mô hình)

Tiến trình 2 Tiến trình kiểm thử thường theo mô hình chiến lược kiểm thử tổng thể:

Hình 1.1 Mô hình chiến lược kiểm thử tổng thể

1.1.4 Sơ lược về các phương pháp kiểm thử

Bất kỳ sản phẩm kỹ nghệ nào đều có thể được kiểm thử theo một trong

hai cách [1,2,5,6,15]:

Cách 1 Kiểm thử chức năng/hộp đen: cho dữ liệu đầu vào đúng/sai, kiểm tra đầu ra đúng/sai, tức là kiểm thử xem từng chức năng có vận hành đúng không, không quan tâm đến cấu trúc bên trong của chức năng đó

Cách 2 Kiểm thử cấu trúc/hộp trắng: không những quan tâm đến mối quan hệ giữa đầu vào và đầu ra của chức năng đó mà còn quan tâm, đến cấu trúc bên trong, quan tâm chi tiết đến từng đầu vào, đầu ra của các thành phần cấu thành trong đó và cả sự ăn khớp giữa chúng nữa, tức là bảo đảm rằng sự vận hành bên trong thực hiện đúng theo đặc tả và tất cả các thành phần bên trong đều được quan tâm và được kiểm tra một cách chi tiết

Đối với phần mềm máy tính, kiểm thử hộp đen biểu thị việc kiểm thử được tiến hành tại giao diện phần mềm Mặc dù chúng được thiết kế để phát hiện ra lỗi, kiểm thử hộp đen được dùng để thể hiện rằng các chức năng phần mềm đã vận hành, cái vào được chấp nhận đúng, và cái ra được tạo ta đúng, tính toàn vẹn của thông tin ngoài (như tệp dữ liệu) là được duy trì Phép kiểm

Kiểm thử

đơn vị

Kiểm thử tích hợp

Kiểm thử

hệ thống

Kiểm thử thẩm định

Môđun

đơn vị

Môđun chức năng,

hệ con

Cả phần cứng, phần mềm

Hệ thống thực

thử hộp đen xem xét một số khía cạnh của hệ thống ít để ý tới cấu trúc logic bên trong của phần mềm

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

1.2.1 Ý tưởng của kiểm thử hộp trắng

Kiểm thử hộp trắng (white-box test) không những quan tâm đến mối

quan hệ giữa đầu vào và đầu ra của chức năng đó mà còn quan tâm đến cấu trúc bên trong, quan tâm chi tiết đến từng đầu vào đầu ra của các thành phần cấu thành trong đó và cả sự ăn khớp giữa chúng nữa, tức là bảo đảm rằng sự vận hành bên trong thực hiện đúng theo đặc tả và tất cả các thành phần bên trong đều được quan tâm và được kiểm tra một cách chi tiết [9]

Kiểm thử hộp trắng được hướng tới việc xem xét kỹ về chi tiết thủ tục

Các đường logic đi qua phần mềm được kiểm thử bằng cách đưa ra các trường hợp kiểm thử, vốn thực hiện trên một tập xác định các điều kiện và /hoặc chu trình “Trạng thái của chương trình” có thể được xem xét tại nhiều điểm khác nhau để xác định liệu trạng thái dự kiến hay khẳng định có tương ứng với trạng thái thực tại không [9]

Bản chất của khiếm khuyết phần mềm chính là lý do đầu tiên phải kiểm thử hộp trắng Hơn nữa, việc kiểm thử hộp đen, dù làm kỹ lưỡng đến đâu vẫn

có thể sót nhiều loại lỗi Theo Beizer: “Lỗi ẩn nấp trong các ngóc ngách và tập hợp tại biên giới” Việc kiểm thử hộp trắng có nhiều khả năng phát hiện ra chúng hơn,

Kiểm thử hộp trắng (white box) là việc kiểm tra các đoạn mã chương

trình xem nó có vận hành đúng như thiết kế hay không Kiểm thử hộp trắng dựa trên việc xem xét cấu trúc bên trong của chương trình theo cấu trúc điều khiển và sự hoạt động của chúng Nó có nhiều tên gọi khác như glass testing, structure testing, open box testing, clear box testing [Beizer 1995] Đối tượng của kiểm thử hộp trắng là các mã nguồn ở các mô-đun đơn vị [7,8]

Kiểm thử hộp trắng sử dụng các chiến lược cụ thể và sử dụng mã nguồn của chương trình/đơn vị phần mềm cần kiểm thử nhằm kiểm tra xem chương trình/đơn vị phần mềm có thực hiện đúng so với thiết kế và đặc tả hay không Trong khi các phương pháp kiểm thử hộp đen chỉ cho phép phát hiện các lỗi/khiếm khuyết có thể quan sát được, kiểm thử hộp trắng cho phép phát hiện các lỗi/khiếm khuyết tiềm ẩn bên trong chương trình/đơn vị phần mềm, các lỗi này thường khó phát hiện bởi các phương pháp kiểm thử hộp đen

Kiểm thử hộp đen và kiểm thử hộp trắng không thể thay thế cho nhau mà chúng cần được sử dụng kết hợp với nhau trong một quy trình kiểm thử thống nhất nhằm đảm bảo chất lượng phần mềm Tuy nhiên, để áp dụng các phương pháp kiểm thử hộp trắng, người kiểm thử không chỉ cần hiểu rõ giải thuật mà còn cần có các kỹ năng và kiến thức tốt về ngôn ngữ lập trình được dùng để phát triển phần mềm, nhằm hiểu rõ mã nguồn của chương trình/đơn vị phần mềm cần kiểm thử Do vậy, việc áp dụng phương pháp kiểm thử hộp trắng thường tốn thời gian và công sức nhất là khi chương trình/đơn vị phần mềm

có kích thước lớn Vì lý do này, phương pháp kiểm thử hộp trắng chủ yếu được sử dụng cho kiểm thử đơn vị

1.2.2 Mô tả một số cấu trúc theo lược đồ

Trong các phương pháp kiểm tra tính đúng đắn của chương trình, lược

đồ được dùng để:

- Trừu tượng hóa cú pháp của mã lệnh;

- Làm khuôn mẫu cơ bản cho các nguyên tắc kiểm tra theo trường hợp

- Kiểm tra tính đúng đắn trên toàn bộ lược đồ

Hình 1.2 Một số cấu trúc lập trình

1.2.3 Một số hướng chính về kiểm thử hộp trắng

1.2.3.1 Kiểm thử theo câu lệnh (Statement Testing)

Thiết kế quá trình kiểm thử sao cho mỗi câu lệnh của chương trình được thực hiện ít nhất một lần Phương pháp kiểm thử này xuất phát từ ý tưởng [1]:

- Trừ phi một câu lệnh được thực hiện, nếu không ta không thể biết được

có lỗi xảy ra trong câu lệnh đó hay không

- Việc kiểm thử với một giá trị đầu vào không đảm bảo là sẽ đúng cho mọi trường hợp

Ví dụ: Đoạn chương trình thực hiện tính:

result = 0+1+ +|valuel|,

nếu result <= maxint, báo lỗi trong trường hợp ngược lại

1 PROGRAM maxsum ( maxint, value : INT)

2 INT result :=0;i := 0 ;

3 IF value < 0

4 THEN value := - value;

5 WHILE ( i < value ) AND ( result <= maxint)

CASE WHILE

UNTIL

10 THEN OUTPUT ( result )

11 ELSE OUTPUT (“too large”)

Hình 1.4 Đồ thị của chương trình

Ví dụ: Với các bộ giá trị đầu vào (input): maxint = 10, value = -1 hay:

maxint = 0, value = -1 sẽ kiểm tra được toàn bộ các câu lệnh trong đoạn chương trình trên

Để đánh giá phương pháp này ta xem qua ví dụ sau:

Hình 1.5 Minh hoạ về độ phức tạp của câu lệnh

Start

Value<0 Value:=Value

i:=i+1 result:=result + i (i<value)and

(result<=maxint )

Với câu hỏi đầu tiên “Lược đồ nào phức tạp hơn”, ta có câu trả lời là B Với câu hỏi tiếp theo “Lược đồ nào cần các bước kiểm tra nhiều hơn?”

Ta cũng trả lời là B

Hình 1.6 Minh hoạ về các bước kiểm tra

Tuy nhiên, ta thấy số lần kiểm tra tối thiểu để có thể kiểm tra toàn bộ các câu lệnh như trên cho cả hai hàm đều là 2 Vì vậy, phương pháp này không tương ứng với sự phức tạp của mã lệnh

1.2.3.2 Kiểm thử theo đường dẫn (Path Testing)

Kiểm thử theo đường dẫn là phương pháp kiểm thử bao trùm mọi đường dẫn của chương trình và cần kết hợp với lược đồ tiến trình

Số kiểm tra: 2

Số kiểm tra: 2

Hình dưới đây giải thích đường dẫn của chương trình [1]

Hình1.7 Lược đồ kiểm thử theo đường dẫn

Nhận xét:

Phương pháp kiểm thử theo đường dẫn phụ thuộc nhiều vào các biểu thức điều kiện (Xem hình 1.8) Tuy nhiên, có những trường hợp số lượng đường dẫn quá lớn (trường hợp vòng lặp) Vì vậy chương trình này thường không phải là lựa chọn thực tế để tiến hành việc kiểm tra tính đúng đắn của chương trình

Tuy nhiên, không thỏa mãn với mọi giá trị đầu vào, cần kết hợp cả x và y

để thực hiện bước kiểm thử

Loop < 20

1.2.3.4 Kiểm thử theo vòng lặp (Loop Testing)

Kiểm thử theo vòng lặp là phương pháp tập trung vào tính hợp lệ của các cấu trúc vòng lặp Các loại vòng lặp được thể hiện như sau [1,8]:

Trong đó n là số lần lặp tối đa của vòng lặp

- Các bước cần kiểm thử cho vòng lặp dạng lồng nhau

+ Khởi đầu với vòng lặp nằm bên trong nhất Thiết lập các tham số lặp cho các vòng lặp bên ngoài về giá trị nhỏ nhất

+ Kiểm tra với tham số min+1, một giá trị tiêu biểu, max-1 và max cho vòng lặp bên trong nhất trong khi các tham số lặp của các vòng lặp bên ngoài

là nhỏ nhất

Vòng lặp lồng nhau

Vòng lặp đơn giản Vòng lặp nối tiếp nhau Vòng lặp không cấu trúc

+ Tiếp tục tương tự với các vòng lặp liền ngoài tiếp theo cho đến khi tất

cả vòng lặp bên ngoài được kiểm tra

- Các bước cần kiểm thử cho vòng lặp nối tiếp

+ Nếu các vòng lặp là độc lập với nhau thì kiểm tra như trường hợp các vòng lặp dạng đơn, nếu không thì kiểm thử như trường hợp các vòng lặp lồng nhau

Ví dụ: // LOOP TESTING EXAMPLE PROGRAM

import java.io.*;

class LoopTestExampleApp {

// - FIELDS -

public static BufferedReader keyboardinput =

new BufferedReader(new InputStreamReader(System.in));

private static final int MINIMUM = 1;

private static final int MAXIMUM = 10;

I I - METHODS -

/* Main method */

public static void main(String[] args) throws lOException {

System.out.println("Input an integer value:”);

int input = new Integer(keyboardInput.readLine()).intValue();

int numberOflterations = 0;

CHƯƠNG 2 MỘT SỐ KỸ THUẬT HIỆU QUẢ TRONG PHƯƠNG PHÁP KIỂM

THỬ HỘP TRẮNG VÀ CA KIỂM THỬ

2.1 Một số kỹ thuật chính trong phương pháp kiểm thử hộp trắng

Có thể tổng hợp một số kỹ thuật hiệu quả trong phương pháp kiểm thử hộp trắng như sau:

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

Kỹ thuật 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) Đồ thị này được xây dựng từ mã nguồn của chương trình/đơn vị chương trình Đồ thị dòng điều khiển là một đồ thị có hướng gồm các đỉnh tương ứ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

Xây dựng một đồ thị dòng điều khiển từ một chương trình/đơn vị chương trình khá đơn giản Hình 2.1 mô tả các thành phần cơ bản 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 Các cấu trúc điều khiển phổ biến của chương trình được mô tả trong Hình 2.2 Chúng ta sẽ sử dụng các thành phần cơ bản và các cấu trúc phổ biến này để dễ dàng xây dựng đồ thị dòng điều khiển cho mọi đơn vị chương trình viết bằng mọi ngôn ngữ lập trình

Hình 2.1: Các thành phần cơ bản của đồ thị chương trình

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

Chúng ta thử xem cách dựng đồ thị dòng điều khiển cho đơn vị chương trình có mã nguồn bằng ngôn ngữ C như Hình 2.3 Chúng ta đánh số các dòng lệnh của đơn vị chương trình và lấy số này làm đỉnh của đồ thị Điểm xuất phát của đơn vị chương trình ứng với câu lệnh khai báo hàm foo Đỉnh 1 ứng

với câu lệnh khai báo biến e Các đỉnh 2 và 3 ứng với câu lệnh if Đỉnh 4 ứng với câu lệnh khai báo biến x trong khi các đỉnh 5 và 6 ứng với câu lệnh if

Đỉnh 7,8 đại diện cho hai câu lệnh 7 và 8 Trong trường hợp này, chúng ta không tách riêng thành hai đỉnh vì đây là hai câu lệnh tuần tự nên chúng ta

ghép chúng thành một đỉnh nhằm tối thiểu số đỉnh của đồ thị dòng điều khiển

Điểm quyết định

Hình 2.3: Mã nguồn của hàm foo và đồ thị dòng điều khiển của nó

2.1.2 Kỹ thuật kiểm thử dòng dữ liệu

Đồ thị dòng dữ liệu là một sự mở rộng của đồ thị dòng điều khiển bằng cách bổ sung thêm xử lý dữ liệu trong chương trình Việc xử lý dữ liệu trong chương trình được thực hiện thông qua sự định nghĩa và sử dụng các biến

Định nghĩa, được kí hiệu là def, là vị trí mà giá trị của biến được lưu trữ trong

bộ nhớ Sử dụng, được kí hiệu là use, là vị trí mà biến được truy cập

Lộ trình định nghĩa - sử dụng, được kí hiệu du-path Tiêu chí bao phủ cho đồ thị luồng dữ liệu sẽ được định nghĩa dựa trên khái niệm du-path

Chúng ta chia du-path thành 2 nhóm [1,3,8,10,11]:

- du-path liên quan đến định nghĩa biến, gồm các du-path với 1 biến

được định nghĩa tại 1 đỉnh du(ni,v) là tập các du-path đối với biến v xuất phát

từ đỉnh ni

- path liên quan đến các cặp định nghĩa và sử dụng biến, gồm các

du-path đối với 1 biến được định nghĩa tại một đỉnh và được sử dụng tại một đỉnh

khác du(ni, nj, v) là tập các du-path đối với biến v xuất phát từ đỉnh ni và kết thúc tại đỉnh nj

Float foo (int a, int b, int c, int d) {

2.1.3 Kỹ thuật kiểm thử BRO

Người ta đưa ra chiến lược cho các phép thử nhạy cảm bằng cách

áp dụng kết hợp chiến lược kiểm thử nhánh và kiểm thử miền (quan hệ) có tên

là chiến lược kiểm thử BRO (Branch and Relational Operation) [8]

Chiến lược BRO bao gồm kiểm thử nhánh và toán tử quan hệ

- Chiến lược kiểm thử nhánh bao gồm:

+ Kiểm thử từng điều kiện trong chương trình

+ Kiểm thử điều kiện không chỉ là phát hiện sai trong điều kiện mà còn phát hiện sai khác của chương trình liên quan

Kiểm thử nhánh được thực hiện theo nguyên tắc: với mỗi điều kiện phức hợp C, thì với mỗi nhánh “true” và “false” của C, mỗi điều kiện đơn trong C phải được kiểm thử ít nhất một lần

- Chiến lược kiểm thử miền

Chiến lược kiểm thử miền cần 3 hoặc 4 kiểm thử cho 1 biểu thức quan

hệ bao gồm <, >, = và có thể ≠ nữa

Nếu biểu thức Bool có n biến, mà n nhỏ thì thuận lợi, song n lớn thì khó thực hiện tất cả trường hợp

Điều kiện logic

Điều kiện logic có thể là:

- Điều kiện đơn: 1 biến Bool (cả toán tử phủ định): X

- Biểu thức quan hệ của 2 biểu thức số học C = (A Θ B), với Θ là phép

so sánh: , , , ,  hay  và A, B là biểu thức số học

- Điều kiện phức hợp cấu thành từ hơn một điều kiện đơn nhờ các toán

tử Bool: hoặc (), và (), phủ định (┘)

D = X 1 & X 2 & … X n , trong đó X i là điều kiện đơn & là toán tử Bool

Kiểu sai trong điều kiện logic có thể là:

- Sai biến Bool

- Sai toán tử Bool

- Sai số hạng trong biểu thức toán tử Bool

- Sai toán tử quan hệ

- Sai biểu thức số học

BRO dùng “ràng buộc điều kiện làm điều kiện cần thử” để phát hiện sai

ở nhánh và toán tử khi xảy ra 1 lần và không có biến chung

Giả sử: D = X1&X2 & … Xn,

Xi: điều kiện đơn, &: toán tử Bool

Cần đặc tả ràng buộc đầu ra của mỗi X i tương ứng với điều kiện D đã xác định

Ta nói rằng, ràng buộc X i của điều kiện D được phủ bởi một sự thực thi của C nếu khi đó, đầu ra của mỗi điều kiện đơn X i trong D thỏa mãn các ràng

buộc tương ứng Điều này có nghĩa là: Khi giá trị của D đã cho, ta cần tìm các điều kiện ràng buộc mà mỗi X i (một thành phần của D) cần thỏa mãn để bảo đảm nhận được giá trị của D đã cho

Với 1 biến Bool B, thì ràng buộc đầu ra của B là t (true) hoặc f (false) Với 1 biểu thức quan hệ (A Θ B) thì ràng buộc đầu ra của nó là toán tử quan hệ:

Θ có thể nhận 1 trong 4 giá trị >, <, =, ≠ (lớn hơn, nhỏ hơn, bằng hoặc khác)

2.1.4 Kỹ thuật kiểm thử đột biến

Dick Lipton là người đầu tiên đề xuất ra kỹ thuật kiểm thử đột biến, sau

đó lĩnh vực này được đánh dấu sự ra đời và phổ biến bởi DeMillo và Sayward Kiểm thử đột biến là phương pháp kiểm thử dựa trên lỗi nhằm cung cấp một tiêu chuẩn kiểm thử được gọi là tỷ lệ đột biến Tỷ lệ đột biến được sử dụng để đánh giá khả năng phát hiện lỗi của tập dữ liệu thử [6,12,13,14]

Nguyên lý chung của kiểm thử đột biến là tạo ra các phiên bản của chương trình có chứa các lỗi đơn giản, các lỗi được sử dụng bởi kiểm thử đột biến đại diện cho các lỗi sơ suất do lập trình viên thường tạo ra Các lỗi như thế được gieo một cách thận trọng vào chương trình gốc, bằng cách thay đổi

cú pháp đơn giản, để tạo một tập các chương trình lỗi Mỗi chương trình lỗi được gọi là đột biến, mỗi đột biến mang một thay đổi cú pháp khác nhau Cụ

thể, cho P là một chương trình gốc, P’ là một đột biến của P bằng cách thực

hiện một thay đổi nhỏ về cú pháp trong chương trình

Trong Bảng 2.1, P là chương trình gốc, P’ và P’’là các đột biến của P bằng cách thay đổi cú pháp trong phép toán quan hệ, thay thế x>y bằng x<y đối với P’ ;thay x<y bởi x<=y đối với P’’ Các câu lệnh bị đột biến được đánh dấu bởi ký hiệu gạch chân

Bảng 2.1 Ví dụ minh họa các đột biến

int max(int x, int y)

}

Sau khi tạo ra các đột biến, mỗi đột biến và chương trình gốc được thực thi trên cùng một bộ dữ liệu thử, nếu kết quả của đột biến và chương trình gốc

khác nhau, thì đột biến đó được gọi là đột biến bị diệt Nếu không thể tìm thấy

dữ liệu thử sao cho khi thực thi đột biến và chương trình gốc cho kết quả khác

nhau, thì đột biến đó được gọi là đột biến tương đương

Tỷ số MS=100*D/(N-E) được gọi là tỷ lệ đột biến

Trong đó, MS: tỷ lệ đột biến; D: là đột biến đã bị diệt; N: là tổng số các đột biến; E: là tổng số đột biến tương đương Tỷ lệ đột biến cho phép đánh giá chất lượng bộ dữ liệu thử

2.2 Ca kiểm thử

2.2.1.Một số quan niệm về ca kiểm thử

Kiểm thử là một tiến trình thực hiện một chương trình với ý định tìm ra lỗi Một ca kiểm thử là một trường hợp kiểm thử có xác suất cao để tìm ra lỗi [8] Nói rõ hơn, Ca kiểm thử (test case) là một tình huống kiểm thử tương

ứng với một mạch hoạt động của chương trình Nó bao gồm một tập các giá trị đầu vào và một danh sách các kết quả đầu ra mong muốn và thực tế [9]

2.2.2.Nội dung thiết kế ca kiểm thử

Một trong những lý do quan trọng nhất trong kiểm thử phần mềm là

thiết kế và tạo ra các ca kiểm thử (Test case) có hiệu quả (ca kiểm thử tốt nhất

có khả năng phát hiện ra lỗi, sai sót của phần mềm một cách nhiều nhất) Với những ràng buộc về thời gian và chi phí đã cho, thì vấn đề then chốt của kiểm

thử là phải trả lời câu hỏi: Tập con nào của tất cả ca kiểm thử có thể có khả

năng tìm ra nhiều lỗi nhất? [2,8]

Thông thường, phương pháp kém hiệu quả nhất là kiểm tra tất cả đầu vào ngẫu nhiên - quá trình kiểm thử một chương trình bằng việc chọn ngẫu nhiên một tập con các giá trị đầu vào có thể Về mặt khả năng tìm ra nhiều lỗi nhất, tập hợp các ca kiểm thử được chọn ngẫu nhiên có rất ít cơ hội là tập hợp tối ưu hay gần tối ưu Sau đây là một số phương pháp để chọn ra một tập dữ liệu kiểm thử một cách thông minh

Để kiểm thử hộp đen và kiểm thử hộp trắng một cách thấu đáo là không thể Do đó, một chiến lược kiểm thử hợp lý là chiến lược có thể kết hợp sức mạnh của cả hai phương pháp trên: Phát triển một cuộc kiểm thử nghiêm ngặt vừa bằng việc sử dụng các phương pháp thiết kế ca kiểm thử hướng hộp đen

nào đó và sau đó bổ sung thêm những ca kiểm thử này bằng việc khảo sát tính logic của chương trình, sử dụng phương pháp hộp trắng

Bảng 2.2 : Những chiến lược kết hợp

Phân lớp tương đương

Phân tích giá trị biên

Đồ thị nguyên nhân - kết quả

Đoán lỗi

Bao phủ câu lệnh Bao phủ quyết định Bao phủ điều kiện Bao phủ điều kiện - quyết định Bao phủ đa điều kiện

Mỗi phương pháp có những ưu điểm cũng như khuyết điểm riêng, do

đó để có được tập các ca kiểm thử tối ưu, chúng ta cần kết hợp hầu hết các phương pháp Quy trình thiết kế các ca kiểm thử sẽ bắt đầu bằng việc phát triển các ca kiểm thử sử dụng phương pháp hộp đen và sau đó phát triển bổ sung các ca kiểm thử cần thiết với phương pháp hộp trắng

Kiểm thử hộp trắng có liên quan tới mức độ mà các ca kiểm thử thực hiện hay bao phủ tính logic (mã nguồn) của chương trình Kiểm thử hộp trắng cơ bản là việc thực hiện mọi đường đi trong chương trình, nhưng việc kiểm thử đầy đủ đường đi là một mục đích không thực tế cho một chương trình với các vòng lặp

2.2.3 Một số phương pháp chính để thiết kế ca kiểm thử

2.2.3.1 Thiết kế các ca kiểm thử dựa vào ý tưởng phương pháp bao phủ câu lệnh (Statement Coverage) [2,4,5,8]

Tư tưởng của phương pháp này là thực hiện mọi câu lệnh trong chương trình ít nhất 1 lần Phương pháp này bao gồm:

Dựa vào ý tưởng phương pháp bao phủ quyết định (Decision coverage)

Ý tưởng của phương pháp này là viết đủ các ca kiểm thử mà mỗi quyết định có kết luận đúng hay sai ít nhất 1 lần Nói cách khác, mỗi hướng phân nhánh phải được xem xét kỹ lưỡng ít nhất 1 lần

Bao phủ quyết định thường thỏa mãn bao phủ câu lệnh Vì mỗi câu lệnh

là trên sự bắt nguồn một đường đi phụ nào đó hoặc là từ một câu lệnh rẽ nhánh hoặc là từ điểm vào của chương trình, mỗi câu lệnh phải được thực hiện nếu mỗi quyết định rẽ nhánh được thực hiện

Dựa vào ý tưởng phương pháp bao phủ điều kiện (Condition coverage)

Ý tưởng của phương pháp này là viết đủ các ca kiểm thử để đảm bảo rằng mỗi điều kiện trong một quyết định đảm nhận tất cả các kết quả có thể ít nhất 1 lần

Dựa vào ý tưởng phương pháp bao phủ quyết định/điều kiện

(Decision/condition coverage)

Ý tưởng của phương pháp này là thực hiện đủ các ca kiểm thử mà mỗi điều kiện trong một quyết định thực hiện trên tất cả các kết quả có thể ít nhất

1 lần, và mỗi điểm vào được gọi ít nhất 1 lần

Điểm yếu của bao phủ quyết định/điều kiện là mặc dù xem ra nó có thể

sử dụng tất cả các kết quả của tất cả các điều kiện, nhưng thường không phải vậy vì những điều kiện chắc chắn đã cản các điều kiện khác

Dựa vào ý tưởng phương pháp bao phủ đa điều kiện (Multiple

condition coverage)

Ý tưởng của phương pháp này là viết đủ các ca kiểm thử mà tất cả những sự kết hợp của các kết quả điều kiện có thể trong mỗi quyết định, và tất

cả các điểm vào phải được gọi ít nhất 1 lần

2.2.3.2 Thiết kế các ca kiểm thử dựa vào ý tưởng phương pháp phân lớp tương đương (Equivalence Patitioning) [2,4,5,8]

Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu vào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử Phương pháp này cố gắng xác định ra một ca kiểm thử mà làm lộ ra một lớp lỗi, do đó làm giảm tổng số các trường hợp kiểm thử phải được xây dựng

Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về các lớp tương đương với một điều kiện vào Lớp tương đương biểu thị 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 vào

Các lớp tương đương được xác định bằng cách lấy mỗi trạng thái đầu vào (thường là 1 câu hay 1 cụm từ trong đặc tả) và phân chia nó thành 2 hay nhiều nhóm

Mặc dù việc phân lớp tương đương là rất tốt khi lựa chọn ngẫu nhiên các ca kiểm thử, nhưng nó vẫn có những thiếu sót Chẳn hạn, nó bỏ qua các kiểu ca kiểm thử có lợi nào đó Hai phương pháp tiếp theo, phân tích giá trị biên và đồ thị nguyên nhân - kết quả, bao phủ được nhiều những thiếu sót này

2.2.3.3 Thiết kế các ca kiểm thử dựa vào ý tưởng phương pháp phân tích giá trị biên (Boundary Value Analysis) [2, 4, 5, 8]

Kinh nghiệm cho thấy các ca kiểm thử mà khảo sát kỹ các điều kiện biên có tỷ lệ phần trăm cao hơn các ca kiểm thử khác Các điều kiện biên là những điều kiện mà các tình huống ngay tại, trên và dưới các cạnh của các lớp tương đương đầu vào và các lớp tương đương đầu ra Phân tích các giá trị biên

là phương pháp thiết kế ca kiểm thử bổ sung thêm cho phân lớp tương đương, nhưng khác với phân lớp tương đương ở 2 khía cạnh:

- 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

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

Phân tích giá trị biên yêu cầu óc sáng tạo và lượng chuyên môn hóa nhất định và nó là một quá trình mang tính kinh nghiệm rất cao

2.2.3.4 Thiết kế các ca kiểm thử dựa vào ý tưởng phương pháp đồ thị nguyên nhân - kết quả (Cause - Effect Graphing) [2, 4, 5, 8]

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 phân lớp tương đương các trạng thái đầu vào, thì số lượng kết hợp thường là rất lớn Nếu 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 thì khi 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ả

Đồ thị nguyên nhân - kết quả hỗ trợ trong việc lựa chọn một cách có hệ thống tập các ca kiểm thử có hiệu quả cao Nó có tác động có lợi ảnh hưởng tới việc chỉ ra tình trạng chưa đầy đủ và nhập nhằng trong đặc tả Nó cung cấp

cả cách biểu diễn chính xác cho các điều kiện logic và hành động tương ứng

Vẽ đồ thị nguyên nhân - kết quả là phương pháp tạo các ca kiểm thử có

hệ thống mô tả sự kết hợp của các điều kiện Sự thay đổi sẽ là một sự lựa chọn kết hợp không thể dự tính trước, nhưng khi thực hiện như vậy sẽ bỏ sót nhiều ca kiểm thử “thú vị” được xác định bằng đồ thị nguyên nhân - kết quả

Vì đồ thị nguyên nhân - kết quả làm chúng ta mất thời gian trong việc chọn các giá trị cụ thể cho các toán hạng, nên các điều kiện giới hạn có thể bị pha trộn thành các ca kiểm thử xuất phát từ đồ thị nguyên nhân - kết quả Vì vậy, chúng ta đạt được một tập các ca kiểm thử nhỏ nhưng hiệu quả mà thỏa mãn cả hai mục tiêu

2.2.3.5 Thiết kế các ca kiểm thử dựa vào ý tưởng phương pháp đoán lỗi - Error Guessing[2,4,5,8]

Một kỹ thuật thiết kế ca kiểm thử khác là error guessing – đoán lỗi

Người kiểm thử được đưa cho một chương trình đặc biệt Họ phỏng đoán (cả bằng trực giác và kinh nghiệm) các loại lỗi có thể và sau đó viết các ca kiểm thử để đưa ra các lỗi đó

Thật khó để đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình có tính trực giác cao và không thể dự đoán trước Ý tưởng cơ bản là liệt

kê một danh sách các lỗi có thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca kiểm thử dựa trên danh sách đó Một ý tưởng khác để xác định các ca kiểm thử có liên đới với các giả định mà lập trình viên có thể đã thực hiện khi đọc đặc tả (tức là, những thứ bị bỏ sót khỏi đặc tả, hoặc là do tình cờ, hoặc là vì người viết có cảm giác những đặc tả đó là rõ ràng) Nói cách khác, cần liệt kê những trường hợp đặc biệt đó mà có thể đã bị bỏ sót khi chương trình được thiết kế

2.3 Kỹ thuật ma trận đồ thị cho thiết kế ca kiểm thử

2.3.1 Ý tưởng và nội dung kỹ thuật ma trận đồ thị [8]

2.3.1.1 Kỹ thuật đồ thị dòng

Một kỹ thuật kiểm thử hộp trắng đầu tiên được Tom McCabe đề nghị là

“kiểm thử đường cơ sở” Phương pháp đường cơ sở giúp cho người thiết kế

trường hợp kiểm thử có thể suy dẫn ra một cách đo độ phức tạp logic của thiết

kế thủ tục và dùng cách đo này như một hướng dẫn để xác định một tập cơ sở các đường thực hiện Các trường hợp kiểm thử được suy dẫn ra để thực hiện một tập cơ sở, được đảm bảo để thực hiện mọi câu lệnh trong chương trình ít nhất một lần trong khi kiểm thử

Trong phương pháp đường cơ sở, một hệ thống ký pháp đơn giản được dùng để biểu diễn cho luồng điều khiển, được gọi là đồ thị dòng (hay đồ thị

chương trình) Đồ thị dòng mô tả cho dòng điều khiển logic bao gồm các cấu trúc cơ bản: sequence, if, while, until, case

Đồ thị dòng thực chất là một kỹ thuật dựa trên cấu trúc điều khiển của chương trình Nó gần giống đồ thị luồng điều khiển của chương trình

Đồ thị dòng nhận được từ đồ thị luồng điều khiển bằng cách:

- Gộp các lệnh tuần tự và điều khiển liên tiếp thành một lệnh;

- Thay lệnh rẽ nhánh của các đường điều khiển bằng một nút “vị tự”

- Chia mặt phẳng thành nhiều miền

- Có nút vị tự biểu thị sự phân nhánh của các cung

- Mỗi cung nối từng cặp nút biểu diễn luồng điều khiển

Ví dụ

Xét cấu trúc điều khiển chương trình:

Do while còn bản ghi chưa xử lý

Read bản ghi chưa xử lý

If giá trị trường thứ nhất của bản ghi = 0

then xử lý bản ghi;

Cất vào bộ nhớ;

tăng biến đếm;

Else if giá trị trường thứ hai của bản ghi = 0

then tạo lại bản ghi;

Else xử lý bản ghi;

Cất vào tệp;

Endif Endif

Enddo

Bước 1-Gán nhãn dòng lệnh:

1 Do while còn bản ghi chưa xử lý

2 Read bản ghi chưa xử lý

3 If giá trị trường thứ nhất của bản ghi = 0

4 then xử lý bản ghi;

Cất vào bộ nhớ;

6 Else if giá trị trường thứ hai của bản ghi = 0

7 then tạo lại bản ghi;

Bước 2-Vẽ sơ đồ điều khiển chương trình:

Hình 2.4: Sơ đồ điều khiển của chương trình

Bước 3a- Vẽ sơ đồ luồng điều khiển rút gọn

Hình 2.5: Sơ đồ luồng điều khiển

Bước 3b- Vẽ đồ thị dòng

Từ sơ đồ luồng điều khiển xác định được đồ thị dòng: