Một số vấn đề về kiểm thử phần mềm

Toàn bộ nội dung Luận văn được chia thành 6 chương như sau:Chương I - Sơ lược về phần mềm và kiếm thử phần mềm Chương này gồm 2 phần: phần 1 giới thiệu về một sỏ' khái niệm cơ sở của kiể

N gu yễn V ăn H anh

NGƯỜI HƯỚNG DẪN KHOA HỌC:

PGS Nguyễn Quốc Toản

Đ Ạ I H Ọ C G U O C G I A H ' 4 0 TRUNG TÁM THÔNGTỈN.T; iư \'iẼ

H à N ội - N ăm 2003 M o Y - LO

M ục lụ c 1

Lời giới th iệ u 5

C hương lược về phần mềm và kiểm thử phần m ềm 9

/ / M ộ t s ố k h á i niệm và vấn đ ề liên q u a n 9

1.1.1 Sản phẩm phần mềm là gì? 9

1.1.2 Thế nào là một lỗi phần mềm? 10

1.1.3 Tại sao xuất hiện lỗi phần mềm? 11

1.1.4 Chi phí cho việc sửa lỗi 12

1.1.5 Kiểm thử phần mềm là g ì? 13

1.2 C á c m ô hình vòng đ ờ i p h á t triển p h ầ n m ềm vói vân đ ề kiểm thử 7 .Ĩ4 1.2.1 Mỏ hình Big-Bang 14

1.2.2 Mỏ hình vừa lập trình, vừa sửa lỗi (Code-and-Fix Model) 16

1.2.3 Mô hình thác nước (Waterfall Model) 16

1.2.4 Mô hình xoắn ốc (Spiral Model) 18

1.2.5 Nhận x ét 20

Chưưng ĩ ^ - £ á c kĩ thuật kiểm thử phần m ềm 21

II ĩ K ĩ th u ậ t kiểm th ủ h ộ p đen (B lack-Box Testing) 21

11.2 K ĩ th u ậ t kiểm th ủ h ộ p trắng (W hite-Box Tesing) 22

II 3 Thiết k ế c á c trưòng hợp kiể m thử 24

11.3.1 Phân hoạch tương đương (Equivalence Partitioning) 25

11.3.2 Phân tích giá trị biên (Boundary-Value Analysis) 29

11.3.3 Kĩ thuật đồ thị nhân quả 31

11.3.4 Đoán lỗi (Error Guessing) 35

11.3.5 Kiểm thử đường dẫn cơ sở (Basic Path Testing) 36

11.3.6 Kiểm thử cấu trúc điều khiến 44

11.3.7 Một ví dụ về thiết kế trường hợp kiểm thử 51

III 3 Phương p h á p tiế p c ậ n kiể m thử p h ẩ n m ề m 57

111.3.1 Xác minh và thẩm định 58

111.3.2 Tổ chức việc kiểm thử 59

111.3.3 Một chiến lược kiểm thử phần mềm 60

111.3.4 Điều kiện đê hoàn thành kiểm thử 63

ỉII 4 Kiểm thử dơn vị (kiểm thử m ô đ u n /th à n h p h ầ n ) 05

111.4.1 Vấn đề kiểm thử đơn vị 65

111.4.2 Các thủ tục kiểm thử đơn vị 67

II 1.5 Kiểm th ủ tích h ợ p 68

111.5.1 Kiểm thử tích họp từ trên xuống (top-down) 69

111.5.2 Kiểm thử tích hợp từ dưới lên (bottom-up) 71

111.5.3 Kiểm thử hồi quy 72

II 1.5.4 Một số ghi chú về kiểm thử tích hợp 73

IILó Kiểm th ủ tính hợ p lệ 75

111.6.1 Điều kiện kiểm thử tính hợp lệ 75

111.6.2 Duyệt lại cấu hình 76

111.6.3 Kiểm thử Alpha và Beta 76

III 7 Kiểm th ủ hệ th ố n g 77

111.7.1 Kiểm thử phục h ồ i 78

111.7.2 Kiểm thử tính bảo m ật 78

111.7.3 Kiểm thử ứng suất 79

111.7.4 Kiểm thử khả năng thực hiện 79

III 8 K ĩ th u ậ t g ỡ rố i 80

111.8.1 Quá trình gỡ rối 80

111.8.2 Phương pháp gỡ rối 81

Chương Jvj-_Kiểm thử hướng đối tượng 83

IV 1 C ắ c k ĩ th u ậ t kiể m th ủ hướng đ ố i tư ợ n g 83

IV 1.3 Khả nàng ứng dụng của các phương pháp kiểm thử tại mức lớp 94

tv.2 Chiến lược kiể m thử hướng đ ố i tượng 96

IV.2.1 Kiểm thử đơn vị trong mô hình hướng đối tượng 96

IV.2.2 Kiểm thử tích hợp trong mô hình hướng đối tượng 97

IV.2.3 Kiểm thử chức năng và hệ thống trong mô hình hướng đối tượng 98

IV.3 Kiểm th ử vó i UML 99

IV.3.1 UML và mô hình kiểm thử 99

IV.3.2 Biểu đồ Use Case 101

IV.3.3 Biểu đồ lớp (Class Diagram) 103

IV.3.4 Biểu đồ tuần tự (Sequence Diagram) 105

IV.3.5 Biểu đồ hoạt động (Activity Diagram) 106

IV.3.6 Biểu đồ trạng thái (Statechart Diagram) 107

IV.3.7 Biểu đồ hợp tác (Collaboration Diagram) 108

IV.3.8 Biểu đồ thành phần (Component Diagram) 109

IV■ 3.9JBiẹ.u^ề-triển khai (Deplovment Diagrain) 110

Chương V - Vấn đề quản lí chất lượng phần mềm và tiêu chuẩn kiểm thử phần mềiB< 111

V ì Vấn đ ề q uản tí c h ấ t lượng p h ầ n m ề m 11 ỉ V 1.1 Chất lượng phần mềm là gì? 111

v.1.2 Các hoạt động quản lí chất lượng 112

V 1.3 Họ tiêu chuẩn ISO 9000 112

V 1.4 Các tiêu chuẩn phần mềm 114

V.2 Vốn đ ề tiêu chuổn kiểm th ủ p h ầ n m ề m 115

v.2.1 Kiểm thử phần mềm trong một số ngữ cánh 116

v.2.2 Mô hình kiểm thử phần mềm 117

v.2.3 Các mức toàn vẹn và kiểm thử dựa vào rủi ro 120

v.2.4 Khung kiểm thử phần mềm 121

C hưưng VI - Vấn đề tài liệu kiểm thử phần m ềm 123

VI ỉ Tổng quan về vấn đ ề tà i liệ u kiể m thử p h ầ n m ề m 123

VI 2 K ế h o ạ c h k iể m thử 126

VI 3 Đ ặ c tá k iể m thủ ĩ 32 VI.3.1 Đặc tả thiết kế kiếm thử 132

VI.3.2 Đặc tả trường hợp kiểm thử 133

VI.3.3 Đặc tả thủ tục kiểm thử 134

VI 4 C á c b á o c á o kiể m thử 135

VI.4.1 Báo cáo chuyển giao các hạng mục kiểm thử 135

VI.4.2 Báo cáo nhật kí kiểm thử 136

VI.4.3 Báo cáo vấn đề kiểm thử bất thường 137

VI.4.4 Báo cáo tổng kết kiểm thử 137

VI 5 M ộ t sô tà i liệ u kiể m th ủ g ia i đ o ạ n 138

VI.5.1 Tài liệu kiểm thử đơn vị (thành phần) 138

VI.5.2 Tài liệu kiểm thử tích hợp 139

VI.5.3 Tài liệu kiểm thử hệ thống 141

VI.5.4 Tài liệu kiểm thử tính hợp lệ 142

Kết lu ậ n 147

Tài liệu tham khảo 148

của đời sống, xã hội, và đóng vai trò quan trọng trong quá trình chuyển dịch cơ cấu kinh tế xã hội, thay đổi phong cách sống và phong cách làm việc của con người Linh hổn của công nghệ thông tin đó chính là phần mềm Phần mềm được phát triển không chì cho những hệ thống đơn giản, đơn lẻ mà còn cho các hệ thống điều khiển phức tạp, các hệ thống tích hợp nhiều loại thiết bị với nhau và phạm vi ứng dụng từ

hệ thống đơn lẻ đến các hệ thống lớn, trong một cơ quan, khu vực, thành phố, quốc gia và toàn thế giới

Với sự phát triển như vũ bão của công nghệ thông tin nói chung và công nghệ phần mềm nói riêng, việc phát triển phần mềm ngày càng được hỗ trợ bởi nhiều công cụ phát triển tiên tiến, giúp cho việc xây dựng phần mềm đỡ mệt nhọc và hiệu quả hơn Tuy nhiên, vì độ phức tạp của phần mềm và những giới hạn về thời gian và chi phí, cho dù các hoạt động đảm bảo chất lượng phần mềm nói chưng và kiểm thử phần mềm nói riêng ngày càng chặt chẽ và khoa học hơn, vẫn không đảm bảo được rằng các sán phẩm phần mềm đang được ứng dụng không còn lỗi Lỗi vẫn luôn tiềm

ẩn trong mọi sản phẩm phần mềm và cũng có thể sẽ gây ra những thiệt hại khôn lường

Kiểm thử phần mềm là một quá trình liên tục xuyên suốt mọi giai đoạn của quá trình phát triển phần mềm để đàm bảo rằng phần mềm thoả mãn các yêu cầu của chúng và các yêu cầu đó thoả mãn các nhu cầu của người dùng Các kĩ thuật kiểm thử phần mềm đã, đang được nghiên cứu và việc kiểm thử phần mềm đã trở thành quy trình bắt buộc trong các dự án phát triển phần mềm trên thế giới Kiểm thử phần mềm là một hoạt động rất tốn kém, mất thời gian và khó phát hiện được hết lỗi Vì vậy, việc kiểm thử phần mềm đòi hỏi phải có một chiến lược phù hợp, một kế hoạch hợp lí và việc thực hiện được quản lí chặt chẽ

ỏ Việt Nam, thời gian qua, kiểm thử phần mềm bị xem nhẹ, với công cụ lập trình hiện đại, người ta cảm tính cho rằng không kiểm thử cũng không sao, nên chưa

có nhiều sự quan tâm, nghiên cứu Những năm gần đày, một số tổ chức nghiên cứu

nhẹ việc kiểm thử phần mềm vì xác suất thất bại sẽ rất lớn, hơn nữa, nếu báo cáo phần mềm không có tài liệu kiểm thử thì không được chấp nhận.

1 M ục đích và phương pháp nghiên cứu của Luận văn

Để góp thêm nhận thức về tầm quan trọng của kiểm thử phần mềm, thông qua việc nghiên cứu, tìm hiểu, đánh giá các kĩ thuật, chiến lược, tổng kết các tiêu chuẩn liên quan đến quản lí chất lượng và kiểm thử phần mềm, tìm ra những chỗ còn chưa có các tiêu chuấn kiểm thử phần mềm Từ đó đề xuất những vấn đề còn thiếu và một khung để xây dựng tiêu chuẩn kiểm thử phẩn mềm, đồng thời đề xuất những vấn đề về xây dựng tài liệu kiểm thử phần mềm Kết quả nghiên cứu có thể làm tài liệu tham khảo trong việc xây dựng một tiêu chuẩn Quốc gia về quy trình phần mềm nói chung và tiêu chuẩn kiểm thử phần mềm nói riêng, đồng thời nó cũng

có thể làm tài liệu tham khảo cho các cơ sớ đang tiến tới đưa quy trình kiểm thử phần mềm thành một quy trình bắt buộc trong dự án phát triển phần mềm của họ

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

- Đề tài nghiên cứu, tìm hiểu và phân tích các kĩ thuật, phương pháp và chiến lược kiểm thử phần mềm đã, đang được áp dụng và nghiên cứu trên thế giới;

- Nghiên cứu, tổng kết các tiêu chuẩn liên quan đến đảm bảo chất lượng phần mềm

và kiểm thử phần mềm;

- Việc nghiên cứu các kĩ thuật và phương pháp kiểm thử đã có nhiều thành quả và được áp dụng trên thế giới Việc nghiên cứu đưa ra các kĩ thuật và phương pháp kiểm thử mới là rất khó với khuôn khổ một luận văn cao học Vì vậy, luận văn giới hạn phạm vi nghiên cứu là phân tích, tìm ra những lỗ hổng còn chưa có tiêu chuẩn

và thiếu quy định về tài liệu của kiểm thử phần mềm, đồng thời đề xuất một khung

về tiêu chuẩn kiểm thử phần mềm và những vần đề xây dựng tài liệu kiểm thử phần mềm

Toàn bộ nội dung Luận văn được chia thành 6 chương như sau:

Chương I - Sơ lược về phần mềm và kiếm thử phần mềm

Chương này gồm 2 phần: phần 1 giới thiệu về một sỏ' khái niệm cơ sở của kiểm thừ phần mềm như: sản phẩm phần mềm là gì, thế nào là một lỗi phần mềm, tại sao có lỗi phần mềm, chi phí để sửa lỗi và khái niệm kiểm thử phần mềm ; phần

2 giới thiệu sơ lược một số mô hình phát triển phần mềm phổ biến trên thế giới và đánh giá vấn đề kiểm thử phần mềm trong các mô hình đó

Chương II - Các kĩ thuật kiểm thử phần mềm

Chương này gồm 3 phần: phần 1 trình bày về kĩ thuật kiểm thử hộp đen; phần

2 trình bày về kĩ thuật kiểm thử hộp trắng; phần 3 trình bày các kĩ thuật thông dụng cho việc thiết kế các trường hợp kiểm thử phần mềm Trong phần này cũng trình bày một số ví dụ thiết kế các trường hợp kiểm thử cho một số bài toán đơn giản

Chương III - Chiến lược kiểm thử phần mềm

Chương này được chia thành 8 phần: phần 1 trình bày một số nguyên lí cần thiết trong việc thiết kế và thực hiện kiểm thử phần mềm; phần 2 - Luồng thông tin kiểm thử, trình bày biểu đồ luồng thông tin và các giai đoạn kiểm thử phần mềm; phần 3 - Phương pháp tiếp cận kiểm thử phần mềm, trình bày cách tiếp cận chiến lược kiểm thử phần mềm, bao gồm những vấn đề về xác minh và thẩm định, tổ chức kiểm thử, điều kiện để hoàn thành kiểm thử; từ phần 3 đến phần 7 trình bày từng giai đoạn kiểm thử: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, và kiểm thứ tính hợp lệ (bao gồm kiểm thử chấp nhận, kiểm thử alpha và kiểm thử beta) và phần 8 trình bày về kĩ thuật gỡ rối

Chương IV - Kiểm thử hướng đối tượng

Chương này gồm có 3 phần: phần 1 - trình bày về các kĩ thuật kiểm thử hướng đối tượng và các trường hợp kiểm thử hướng đối tượng; phần 2 trình bày về chiến lược kiểm thử hướng đối tượng; phần 3 trình bày về vấn đề kiểm thử với UML

4 Kết cấu và nội dung luận văn

Chương V - Vấn đề quản lí chất lượng phần mềm và tiêu chuẩn kiểm thử phần mềm

Chương này trình bày sơ lược về vấn đề quán lí chất lượng phần mềm, các tiêu chuẩn về kiểm thử phần mềm trên thế giới theo một khung tiêu chuẩn phần mềm

Chương VI - Vấn để tài liệu kiểm thử phần mềm

Chương này tác giả đề xuất hình thức và nội dung của các tài liệu chủ yếu của quá trình kiểm thử phần mềm Chương này gồm có: tổng quan về vần đề tài liệu phần mềm, kế hoạch kiểm thử, đặc tả kiểm thử, báo cáo kiểm thử và cuối cùng là những vấn để xây dựng tài liệu cho các giai đoạn kiểm thử cụ thể

Phản hổi từ các Thỏng tinphiôn hàn cũ canh tranh

Sản phẩm cuối cùne

Sclup, Help files Samples and Examples, Readme files, Error Massages, Icons and art User Manuals, Product Support Information, Advertisements, Label and stickers

HÌNH 0.1 — SẢN PHẨM PHAN MEM

Khối lượng công việc của từng giai đoạn trong quá trình sản xuất phần mềm cũng thay đổi theo thời gian Bảng dưới đây [J_0| minh hoạ cụ thể hơn về điều này.

BẢNG 0.1 — TỈ LỆ CÔNG VIỆC CỦA CÁC GIAI ĐOẠN PHÁT TRIÊN phẩn MEM

Giai doan Phan tích

yêu cầu Thiết kế sơ bộ Thiết kè chi tiết kiêm thừ dơn Lặp trình và

vi

Tích hợp và kiểm thử tích hợp

Kiếm ỉhừ hé thôngHai ihàp ki I960

BẢNG 0.2 — CHI PHÍ CỦA CÁC GIAI ĐOẠN TRONG VÒNG ĐÒI PHẨN MỀM

1.1.2 Thẻ nào là một lỗi phần mềm?

Có rất nhiều định nghĩa khác nhau, tựu chung, nêu một cách tổng quát là

"Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó” [7]

Dựa vào định nghĩa, chúng ta có thể thấy lỗi phần mềm xuất hiện theo ba dạng sau:

- Sai: Sản phẩm được xây dựng khác với đặc tả

- Thỉếu: Một yêu cầu đã được đặc tả không có trong sản phẩm được xây dựng

- Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng ưng thuận nhưng vì khác với đặc tả nên vẫn coi là lỗi.

Một hình thức khác nữa cũng được xem là lỗi, đó là phần mềm khó hiểu, khó

sử dụng, chậm, hoặc dễ gây cảm nhận rằng phần mềm hoạt động không đúng

1.1.3 Tại sao xuất hiện lỗi phần mềm?

Khác với sự cảm nhận thông thường, lỗi xuất hiện nhiều nhất không phải là

do lập trình Nhiều nghiên cứu đã được thực hiện trong các dự án rất nhỏ đến các dự

án rất lớn và kết quả luôn giống nhau Số lỗi do đặc tả gây ra là nhiều nhất (Hình 0.2 [251) Có một số nguyên nhân làm cho đặc tả tạo ra nhiều lỗi nhất Trong nhiều trường hợp, đặc tả không được viết ra Các nguyên nhân khác có thể là do đặc tả không đủ cẩn thận, nó hay thay đổi, hoặc do chưa phối hợp tốt trong toàn nhóm phát triển Sự thay đổi yêu cầu của khách hàng cũng là nguyên nhân dễ gây ra lỗi Khách hàng thay đổi yêu cầu không cần quan tâm đến những tác động sau khi thay đổi yêu cầu: phải thiết kế lại, lập lại kế hoạch, làm lại những việc đã hoàn thành Nếu có nhiều sự thay đổi, rất khó khăn để biết hết được phần nào của dự án phụ thuộc và phần nào không phụ thuộc vào sự thay đổi Nếu không giữ được vết thay đổi rất dễ phát sinh lỗi

Nguyên

HÌNH 0.2 - CÁC NGUYÊN NHÂN GÂY Lỗl PHẨN MỀM

Nguồn lỗi gây ra lớn thứ hai là thiết kế Đó là nền tảng mà lập trình viên dựa vào để nỗ lực thực hiện kế hoạch cho phần mềm Đúng như cổ nhân đã nói ”Nếu không nói ra được thì không thể làm được”.

Lỗi do lập trinh gây ra cũng là điều dễ hiểu Ai cũng có thê mắc lỗi Thời kì đầu, phát triển phần mềm có nghĩa là lập trình, công việc lập trình thì rất nặng nhọc, lỗi do lập trình gây ra là chủ yếu Ngày nay, công việc lập trình chỉ là một phần việc của quá trình phát triển phần mềm, cộng với sự hỗ trợ của nhiều công cụ lập trình cao cấp, việc lập trình trở nên nhẹ hơn nhiều, mặc dù độ phức tạp của phần mềm lớn hơn rất nhiều Do đó, lỗi do lập trình gây ra cũng ít hơn Tuy nhiên, nguyên nhân để lập trình tạo ra lỗi lại nhiều hơn Đó là do độ phức tạp của phần mềm, do tài liệu nghèo, do sức ép thời gian, hoặc chỉ đơn giản là những lỗi ’’không nói lên được” Một điều cũng hiển nhiên là nhiều lỗi xuất hiện trên bề mặt lập trình nhưng thực ra

là do lỗi của đặc tả hay thiết kế

Một nguyên nhân khác tạo ra lỗi đó là bản thân các công cụ phát triển phần mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch v.v

1.1.4 Chi phí cho việc sửa lỗi

Theo tài liệu được trích dẫn của Martin và McClure [22], bảo trì là phần chi phí chính của phần mềm Kiểm thử là hoạt động chi phí đắt thứ hai, ước tính khoảng 40% (15/33) chi phí trong quá trình phát triển ban đầu của một sản phẩm (xem Bàng0.2 trang 10) Kiểm thử cũng là một phần chi phí của giai đoạn bảo trì do phải tiến hành kiểm thử lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu người dùng

Kiểm thử và sửa lỗi có thể được thực hiện tại bất kì giai đoạn nào của vòng đời phần mềm Tuy nhiên, chi phí cho việc tìm và sửa lỗi tăng một cách ghê gớm theo quá trình phát triển

Sự thay đổi một tài liệu yêu cầu khi duyệt lại lần đầu tiên là không đắt nếu không nói là không đáng kể Chi phí tãng lên nhiều hơn nếu các yêu cầu thay đổi sau khi đã được lập trình Thay đổi yêu cầu lúc đó đồng nghĩa với việc viết lại chương trình

Sửa lỗi còn không đáng kể khi người lập trình tự phát hiện lỗi của chính minh Không có sự liên quan đến chi phí khác Họ không phải giải thích một lỗi cho bất kì người nào Họ không phải nhập lỗi đó vào cơ sở dữ liệu lưu vết lỗi Người kiểm thử và người quản lí không phải duyệt lại tình trạng của lỗi Và lỗi đó không ảnh hưởng đến công việc của người khác trong nhóm dự án.

Sửa một lỗi trước khi phát hành một phần mềm rẻ hơn rất rất nhiều so với việc khắc phục nó sau khi đã phát hành

Trong tài liệu Boehm [4], trích dẫn kết quả nghiên cứu của IBM, GTE và TRW, tổng kết rằng lỗi được phát hiện càng muộn thì chi phí đê sửa lỗi càng lớn Chi phí tãng theo hàm mũ như trong Hỉnh 0.3

Thời gian khi phát hiện ra lỗi HÌNH 0.3 — CHI PHÍ SỬA Lỗl THEO THÒI GIAN PHÁT HIỆN Lỗl

Chúng ta cũng đã từng chứng kiến sự cố máy tính năm 2000 Từ một giải pháp tiết kiệm bộ nhớ: biểu diễn năm bốn chữ số thành năm có hai số cuối vào đầu những năm 70 của thế kỉ trước đã dẫn đến việc 25 năm sau nhân loại phải bỏ ra hàng trăm tỉ đô la để khắc phục và làm cả thế giới phải lo sợ

1.1.5 Kiểin thử phần mềin là gì?

Kiểm thử phần mềm thông thường đồng nghĩa với việc tìm ra lỗi chưa được phát hiện Tuy nhiên, có nhiều bối cảnh kiểm thử không bộc lộ ra lỗi Kiểm thử phần mềm là quá trình thực hiện một hệ thống phần mềm để xác định xem nó có đúng với đặc tả không và thực hiện được trong một môi trường như mong đợi không

Trên thực tế, hệ thống đang thực hiện khác biệt với việc duyệt lại mã nguồn Thông thường, người phát triển thực hiện việc đọc và phân tích mã nguồn Nói cách khác, kiểm thử đòi hỏi một hệ thống có thể chạy được Đặc tả là căn cứ chủ yếu hỗ trợ cho việc kiểm thử Nó xác định những hành vi đúng và làm cho dễ dàng hơn trong việc xác định những hành vi không đúng Mỗi hành vi không đúng là một lỗi phần mềm Nói chung, người phát triển tự chuẩn đoán nguyên nhân sinh lỗi trong mã nguồn.

Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm một cách sớm nhất có thể và đảm bảo rằng lỗi đã được sửa, chứ kiểm thử phần mềm không làm công việc như chuẩn đoán nguyên nhân gây ra lỗi đã được phát hiện và sửa lỗi Chúng ta sẽ nghiên cứu kĩ hon về vấn đề này ở những phần tiếp theo

Mục tiêu của kiểm thử là thiết kế tài liệu kiểm thử một cách hệ thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm thời gian, công sức và chi phí

1.2 C á c m ô h ìn h v ò n g đ ờ i p h á t triể n p h ầ n m ề m v ó i vá n đ ề k iể m

th ử

Quá trình tạo ra một sản phẩm phần mềm từ khái niệm ban đầu đến khi phát hành được gọi là mô hình vòng đời phát triển phần mềm Có rất nhiều phương pháp được sử dụng để phát triển phần mềm, trong đó có 4 mô hình hay được nhắc tới, đó

là:

- Mô hình vụ nổ lớn (Big-Bang Model)

- Mô hình vừa lập trình vừa sửa lồi (Code-and-Fix Model)

- Mô hình thác nước (Waterfall Model)

- Mô hình xoắn ốc (Spriral Model)

Mỗi mô hình đều có ưu điểm và nhược điểm Đối với người kiểm thử cần phải quan tâm hết và lựa chọn mô hình thích hợp vào từng trường hợp cụ thể

1.2.1 Mô hình Big-Bang

Một lí thuyết hiện đại về việc hình thành vũ trụ là Thuyết vụ nổ lớn Nó cho rằng hàng tỉ năm trước, vũ trụ được hình thành bắt đầu từ một vụ nổ cực lớn với

năng lượng rất lớn không thể xác định Mọi thứ đang tồn tại là kết quả của năng lượng và vật chất tạo thành sau vụ nổ đó.

Mỏ hình vòng đời phát triển phần mềm big-bang áp dụng nguyên lí này (Hình 0.4) Một khối lượng lớn vật chất (con người và tiền bạc) được huy động, một nguồn năng lượng lớn được tạo ra một cách trái ngược, hoặc là một sản phẩm hoàn thiện hoặc là không gì cả

Mô hình big-bang là một mô hình đơn giản Việc lập kế hoạch, lập lịch biểu hoặc một quy trình phát triển chính thức là hầu như không có Tất cả công sức cho việc phát triển phần mềm là viết chương trình Nếu yêu cầu sản phẩm phần mềm không được hiểu đúng thì thời hạn cho việc phát hành sản phẩm cuối cùng là mềm dẻo Điều quan trọng là cũng cần phải có một khách hàng mềm dẻo, bởi vì họ không biết được chắc chắn họ sẽ có cái gì đến khi gần kết thúc

Hầu như không có kiểm thử phần mềm trong mô hình này Nếu có thì cũng rất hiếm, chỉ tiến hành khi sản phẩm phần mềm đã hoàn thành trước khi phát hành Hoạt động kiểm thử chi nhằm một mục đích đó là ghi lại những lỗi được tìm thấy và nói cho khách hàng biết vấn đề đó, chứ không quay lại sửa lỗi Vì vậy, dưới con mắt của người quản lí dự án, việc kiểm thử chỉ làm trễ quá trinh bàn giao sản phẩm với khách hàng mà thôi

HÌNH 0.4 — MÔ HÌNH BIG-BANG

1.2.2 Mô hình vừa lập trình, vừa sửa lỗi (Code-and-Fix Model)

Mô hình này tiến bộ hơn mô hình big-bang, ý tưởng về yêu cầu sản phẩm (đặc tả sản phẩm) đã được hình thành một cách không chính thức Đây vẫn chưa phải là một mô hình đầy đủ

Khi sử dụng phương pháp này, người ta bắt đầu với ý tưởng thỏ về những gì

mà họ muốn, thực hiện một số thiết kế đơn giản, và rồi xử lí một vòng lặp dài gồm lập trình, kiểm thử và sửa lỗi Lặp đến khi nào người ta thấy rằng đã đủ đế phát hành sản phẩm Mô hình này làm việc tốt cho các dự án nhỏ, dự định làm nhanh và vứt bỏ ngay sau khi hoàn thành sản phẩm mẫu và giới thiệu

Kiểm thử không phải là công việc riêng biệt trong mô hình này, nhưng nó đóng vai trò ở giữa việc lập trinh và sửa lỗi Công việc kiểm thử đang tiến hành với một phiên bản trước thì có một sản phẩm mới cập nhật với những đặc tính đã thay đổi và lặp lại cho đến khi sản phẩm phát hành

1.2.3 Mô hình thác nước (Waterfall Model)

Vào năm 1968, mô hình này được đề xuất đầu tiên tại một hội thảo quốc tế

do NATO tổ chức tại Garmish, Đức Mô hình thác nước do B.w Boehm đề xướng

và Royce đặt tên vào năm 1970 Mô hình thác nước đã trở thành một mô hình phát triển hệ thống hiệu quả và được áp dụng rộng rãi Tuy nhiên, hệ thống ngày càng lớn hơn và chức năng phức tạp hơn thì mô hình thác nước kéo quá dài

Mô hình thác nước là mô hình phát triển phần mềm thực sự đầu tiên Mô hình này bao gồm một tập tuyến tính các giai đoạn, giai đoạn sau sẽ được tiến hành khi giai đoạn trước hoàn thành Các giai đoạn là rời rạc nhau, không đè lên nhau Tại

Sản phẩm cuốiĐặc tả không

HÌNH 0.5 — MÔ HÌNH CODE-AND-FIX

phần cuối của mỗi giai đoạn, nhóm dự án sẽ duyệt lại để xác định xem họ đã sẵn sàng chuyên sang giai đoạn tiếp theo chưa Nếu dự án vẫn chưa sẵn sàng, họ vẫn dừng ở giai đoạn này và tiếp tục cho đến khi sẵn sàng Ví dụ, trong giai đoạn Phân tích yêu cầu, dự án tạo ra đặc tả yêu cầu phần mềm Phần cuối của giai đoạn này, nhóm dự án duyệt lại đặc tá yêu cầu phần mềm và xác định xem đặc tả yêu cầu có thể chấp nhận được hay không để chuyển sang giai đoạn tiếp theo - Giai đoạn Thiết

kế sơ bộ

Đặc trưng của mô hình này là hướng tài liệu Trong mô hình này, giai đoạn lập trình chỉ là một khối công việc trong dự án Trong khi đó, sản phẩm và công việc chính là tài liệu, đó là: Đặc tả yêu cầu phần mềm, đặc tả thiết kế sơ bộ, đặc tả thiết

kế chi tiết, tài liệu kiểm thử v.v Công việc này được tiến hành từ giai đoạn này sang giai đoạn khác

HÌNH 0.6 — MÔ HĨNH THÁC NƯỚC

Nếu thay đổi yêu cầu, chúng ta phải quay lại các giai đoạn trước để thực hiện, tuy nhiên việc này sẽ cực kì tốn kém.

Mô hình này làm việc tốt khi các yêu cầu và các nhân tố khác (chẳng hạn như công nghệ) được hiểu rõ, nhưng cũng sẽ tồi tệ nếu ngược lại Chính vì vậy, tất cả các vấn đề phải được hiểu tường tận trước khi những dòng lệnh đầu tiên được viết ra Trong mô hình này, mọi thứ được chỉ ra một cách cẩn thận và chi tiết Chính vì vậy, công việc kiểm thử trong mô hình này cũng có lợi thế lớn so với các mô hình khác, dựa vào những tài liệu được đặc tả chi tiết, nhóm kiểm thử có thể tạo kế hoạch và thời gian biểu kiểm thử một cách chính xác Họ biết chính xác những gì họ sẽ kiểm thử Tuy nhiên, lợi thế này cũng là một nhược điểm lớn, bởi vì kiểm thử chi tiến hành ở cuối, nên những lỗi tiềm tàng vẫn không được phát hiện đến khi trước thời gian phát hành sản phẩm Chính vì thế, việc tiến hành sửa lỗi là cực kì tốn kém Cần

có một mô hình mà có thê phát hiện lỗi sớm nhất trước khi nó trở thành quá đắt để sửa

1.2.4 Mô hình xoán ốc (Spiral Model)

Mô hình xoắn ốc do Barry Boehm giới thiệu vào năm 1986 trên tạp chí Hiệp hội máy tính (Association for Computing Machinary) của ông Phương pháp này được sử dụng khá thường xuyên và được hoàn thiện trở thành một phương pháp hiệu quả trong phát triển phần mềm

Một ý tưởng đằng sau mô hình xoắn ốc đó là không nên xác định mọi thứ chi tiết ngay từ khi mới bắt đầu Chúng ta phải bắt đầu từ nhỏ, xác định các đặc tính quan trọng, nhận phản hồi từ phía khách hàng, rồi chuyển đến mức tiếp theo Chúng

ta lặp cho đến khi có được sản phẩm cuối cùng

Mỗi một vòng thời gian xung quanh mô hình xoắn ốc, gồm có 6 bước:

1 Xác định mục tiêu, sự thay thế và ràng buộc

2 Nhận biết và giải quyết rủi ro

3 Đánh giá sự thay thế

4 Phát triển và kiểm thử mức hiện tại

5 Lập kế hoạch cho mức tiếp theo

6 Quyết định phương pháp cho mức tiếp theo

Xác định m ục tiêu,

sự thay thế và ràng

Phát triển và kiểm thử mức hiện tại

giái quvẽt rủi ro

Đ ánh giá sự thav thé

L ặ p kê hoạch cho

mức tiếp theo

HỈNH 0.7 - MÔ HÌNH XOAN Ố c

Bên trong mô hình xoắn ốc có một phần mô hình thác nước (các bước phán tích, thiết kế, phát triển và kiểm thử), một phần mô hình vừa lập trình và sửa lỗi (mỗi vòng thời gian xung quanh mô hình xoắn ốc), và một phần mô hình big-bang (nhìn

nó từ phía ngoài) Kết hợp với chi phí thấp do việc phát hiện lỗi sớm hơn, mô hình này trở thành một mô hình phát triển rất tốt

Đây là một mô hình vòng đời phần mềm hướng rủi ro Dự án được chia thành nhiều dự án nhỏ Mỗi dự án nhỏ nhận biết ra một hoặc nhiều rủi ro cho đến khi tất

cả những rủi ro chính được nhận biết

Ưu điểm của mô hình này là hướng rủi ro, cho phép giảm rủi ro đến mức có thể chấp nhận được Nhược điểm của mô hình này là phức tạp và yêu cầu cao về

quản lí; rất khó khăn để xác định khi nào thì việc nhận biết rủi ro đến mức có thể chấp nhận được.

1.2.5 Nhận xét

Bốn mô hình vừa trình bày là những mô hình phổ biến được biết tới Tuy nhiên, những mô hình đó cũng chỉ là một số ví dụ Có rất nhiều biến thể khác của các mô hình này, ví dụ như: V-Model (một biến thể của mô hình thác nước), the Incremental Model, the Concurrent Development Model Mỗi tổ chức, mỗi dự án

và mỗi nhóm sẽ phải chọn một phương pháp nào đó phù hợp Đối với người kiểm thử phần mềm, cần phải biết rõ mô hình anh ta đang làm việc

Chương II - Các kĩ thuật kiểm thử phần m ềm

II 1 K ĩ th u ậ t k iể m th ử h ộ p đ e n (B la c k -B ox Testing)

Kĩ thuật kiểm thử hộp đen được gọi là kiểm thử hướng dữ liệu (data-driven) hay là kiểm thử hướng đầu vào/ra (input/output driven)

HỈNH II 1 — KIỂM THỬ HỘP ĐEN VÀ KIÊM THỬ HỘP TRANGTrong kĩ thuật này, người kiểm thử xem phần mềm như là một hộp đen Người kiểm thử hoàn toàn không phải quan tâm đến cấu trúc và hành vi bên trong của phần mềm (không thể nhìn thấy gì bên trong hộp đen) Người kiếm thử chí cần quan tâm đến việc tìm các hiện tượng mà phần mềm không hành xử theo đặc tả của

nó (người kiểm thử chỉ biết những gì phần mềm dự kiến thực hiện và những gì phần mềm dự kiến không thực hiện, người dùng không thể nhìn vào bên trong xem nó hoat động như thế nào) Dữ liệu kiểm thử xuất phát từ đặc tả (tức là không cần để ý đến cấu trúc bên trong của phần mềm)

Nếu người ta mong muốn sử dụng phương pháp này đê tìm tất cả các lỗi trong chương trình, thì điều kiện bắt buộc là phải kiểm thử tất cả các đầu vào, tức là mỗi một điều kiện đầu vào có thể có là một trường hợp kiểm thử Bởi vì nếu chi kiểm thừ một số điều kiện đầu vào thì không đảm bảo được chương trình đã hết lỗi Tuv nhiên, điều này thực tế không thực hiện được Một chương trình đơn gián là kiểm tra một tam giác có phải là một tam giác đều không? Nếu chúng ta chí thử 3

trường hợp kiểm thử cho chương trình thì không thể có căn cứ gì đám bảo rằng đã kiểm tra đúng hết các trường hợp tam giác đều Vì thế chương trinh là một hộp đen, chi có một cách đê phát hiện ra hết lỗi là thử mọi điều kiện đầu vào.

Để có thể kiểm thử hết các điều kiện đầu vào, chúng ta phải tạo ra tất cả các trường hợp kiểm thử cho tất cả các tam giác hợp lệ cho đến khi đạt tới con số cực đại biểu diễn số nguyên Đây là một số quá lớn các trường hợp kiểm thử Ngoài các điều kiện đầu vào hợp lệ, chúng ta cũng phải kiểm thử hết các trường hợp không hợp lệ ví

dụ như :3,-2,4; 3,b,4 Như thế thì để thử hết các cả các điều kiện đầu vào hợp lệ và không hợp lệ thì số các trường hợp kiểm thử là vô cùng, không xác định được

Đó mới chỉ là một chương trình đơn giản Trong thực tế, chương trình còn phức tạp hơn rất nhiều Vì thế, không thể kiểm thử được hết đầu vào Điều đó cũng đồng nghĩa là không thể đảm bảo rằng chương trình đã hết lỗi Như vậy, vấn đề đặt

ra là vấn đề tối ưu giữa chi phí và số hữu hạn các trường hợp kiểm thử Chúng ta sẽ nghiên cứu rõ horn trong phần thiết kế các trường hợp kiểm thử

II 2 K ĩ th u ậ t k iể m th ử h ộ p trắ n g (W h ite -B ox Tesing)

Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tra cấu trúc bên trong của phần mềm Trong kĩ thuật này, người kiểm thử lấy dữ liệu xuất phát từ việc kiểm tra logic của chương trinh (tức là bỏ qua đặc tả)

Hộp trắng đúng nghĩa phải gọi là hộp trong suốt Chính vì vậy, nó cũng còn một số tên khác như kiểm thử hộp thuỷ tinh (Glass-Box Testing), hay kiểm thử hộp trong suốt (Clear-Box Testing) Người kiểm thử truy nhập vào mã nguồn của chương trình và có thẻ kiểm tra nó, lấy đó làm đầu mối đê hỗ trợ anh ta trong việc kiểm thử (có nghĩa là anh ta có thể nhìn thấy những gì bên trong hộp) Dựa vào những gì thấy được, người kiểm thử có thể xác định được các con số cụ thể và có thể hướng việc kiểm thử của anh ta theo những thông tin đó

Tương tự như vấn đề kiểm thử đầu vào trong kĩ thuật kiểm thử hộp đen, đó là vấn đề kiểm thử các đường dẫn lệnh trong kĩ thuật hộp trắng Nếu người ta thực hiện tất cả các đường dẫn của lưu trình điều khiển trong chương trình, thông qua việc

chạy tất cả các trường hợp kiểm thử thì có thế nói rằng chương trình đã được kiểm thử triệt để Tuy nhiên, điều đó không thể thực hiện được do những lí do dưới đây:

Số đường dẫn lôgic khác nhau trong một chương trình là cực kì lớn Ví dụ như trong HỈNH 11.2, biểu đồ là một đồ thị chu trình điều khiển Mỗi nút (hình tròn) biểu diễn một đoạn lệnh thực hiện tuần tự, có thể kết thúc bằng một lệnh rẽ nhánh Mỗi cung là một hướng chuyển điều khiển giữa các đoạn lệnh Biểu đồ biểu diễn một chương trình gồm có 10 đoạn lệnh, có chứa một vòng lặp lặp 20 lần Trong thân của vòng lặp có một tập các lệnh điểu kiện rẽ nhánh lồng nhau Việc xác định số đường dẫn logic khác nhau giống như việc xác định số đường đi từ điểm A đến điểm

B như trong hình vẽ (giả sử rằng tất cả các quyết định trong chương trình là độc lập với nhau) Số đường đi trong thân vòng lặp là 5 Như vậy, số đường đi có thể từ điểm

A đến điểm B là: 520 + 5l9 + + 5‘ +5° = i — 1 = 95.367.431.640.624,75 = 1014

HỈNH 11.2 — Vỉ DỤ CHU TRĨNH ĐIẼU KHIÊNGiả sử rằng, một người có thể viết, thực hiện và kiểm tra một trường hợp kiểm thử mất 5 phút Như vậy, để một người có thể thực hiện hết 1014 trường hợp kiểm thử cho bài toán trên thì thời gian để anh ta thực hiện là:

520 -15-1

> 20 lần

;o

1014 «10'' = ! tỉ năm!

(Ghi chú: I năm = 365 ngày X 24 tiếng X 60 phút = 525.600 phút)

Tất nhiên, trong thực tế, mọi quyết định của một chương trinh là không độc lập với quyết định khác, có nghĩa là sô' đường dẫn thực hiện có thể bé hơn Tuy vậy, các chương trinh trong thực tế lớn hơn rất nhiều ví dụ vừa trình bày Vì vậy, không thể kiểm thử được hết các đường dẫn

Ngoài điều bất khả thi như chúng ta vừa thấy, chương trình cũng có thể còn nhiều lỗi do những nguyên nhân khác Đây chính là nhược điểm của kĩ thuật kiểm thứ bằng kĩ thuật kiểm thử hộp trắng

+ Việc kiểm thử bằng kĩ thuật hộp trắng vẫn không thể đảm báo được rằng chương trình đã tuân theo đặc tả Chẳng hạn như việc một lập trình viên được yêu cầu viết một thủ tục sắp xếp chữ Tiếng Việt theo thứ tự từ điển với mã chuẩn Unicode, kí tự dựng sẵn (TCVN 6909:2001), nhưng do nhầm lẫn anh

ta lại viết một thủ tục sắp xếp theo chuẩn TCVN3 (hoặc Unicode kí tự tổ hợp) Đây là một chương trình sai

•!- Một chương trình sai do thiếu đường dẫn Việc kiểm thử hộp trắng không thể biết được sự thiếu sót này

+ Việc kiểm thử bằng kĩ thuật hộp trắng cũng không thể phát hiện được lỗi do

dữ liệu Trong thực tế, rất nhiều lỗi do dữ liệu

Như vậy, việc chì dùng kĩ thuật kiểm thử hộp trắng là bất khả thi Chính vì vậy, chúng ta sẽ nghiên cứu phương pháp kết họp cả hai kĩ thuật kiếm thử hộp đen

và kiểm thử hộp trắng trong phần sau

II 3 Thiết k ế c á c trư ờ n g h ợ p k iể m th ử

Vấn đề quan trọng nhất trong kiểm thử phần mềm là thiết kế và tạo ra các trường hợp kiểm thử hiệu quả Lí do về tầm quan trọng của việc thiết kế các trường hợp kiểm thử xuất phát từ thực tế: Kiểm thử “triệt để hoàn toàn” là điều không thể,

và như vậy, kiểm thử một chương trình phải luôn xác định là không thể triệt để hoàn

toàn (tức là kiểm thử không thể đảm bảo rằng chương trình không còn lỗi nào) Vấn

đề quan trọng là cố gắng làm giảm sự “không triệt đế hoàn toàn” nhiều nhất có thể

Kiểm thử phần mềm còn có các ràng buộc về thời gian, chi phí, thời gian chạy trên máy tính v.v Chìa khoá của kiểm thử là trả lời của câu hỏi “Tập con của tất cả các trường hợp kiểm thử có thể có xác suất phát hiện lỗi cao nhất lù gì?

Việc nghiên cứu các phương pháp thiết kế các trường hợp kiểm thử sẽ cung cấp trả lời cho câu hỏi này

Phương pháp khiêm tốn nhất là kiểm thử đầu vào ngẫu nhiên Đó là quá trình kiểm thử một chương trình bằng việc lựa chọn ngẫu nhiên một tập con của tất cả các giá trị đầu vào có thể Xét về mặt khả năng phát hiện lỗi, một tập hợp các lựa chọn ngẫu nhiên của các trường hợp kiểm thử rất ít có khả năng là một tập con tối ưu hay gần tối ưu Vấn đề chúng ta sẽ nghiên cứu là một tập các quá trình tư duy cho phép lựa chọn một tập dữ liệu kiểm thử thông minh hơn Chúng ta sẽ nghiên cứu các phương pháp được sử dụng phổ biến của hai kĩ thuật kiểm thử bổ trợ cho nhau:

K ĩ thuật kiểm thử hộp đen K ĩ thuật kiểm thử hộp trắng K ĩ thuật khác

- Phân hoạch tương dưưng

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

- Kĩ thuật đồ thị nhân quả

- Kiểm thử đường dẫn cơ sở

- Kiểm thử cấu trúc điều khiển

- Đoán lỗi

Người ta thường sử dụng các phương pháp của kĩ thuật hộp đen để thiết kế các trường hợp kiểm thử trước và sau đó phát triển bổ sung các trường hợp kiểm thử bằng các phương pháp của kĩ thuật hộp trắng

II.3.1 Phân hoạch tương đương (Equivalence Partitioning)

Như đã trình bày trong phần kiểm thử kĩ thuật hộp đen mục II 1 , việc kiểm thử tất cả các đầu vào của một chương trinh là không thể Vì thế, khi kiểm thử một chương trình, nên giới hạn một tập con của tất cả các trường hợp đầu vào có thể Tất nhiên, người ta mong muốn lựa chọn một tập con đúng (tức là, một tập con có xác suất cao nhất phát hiện hầu hết các lỗi)

1 Mỗi trường hợp kiểm thử nên gồm nhiều loại điều kiện đầu vào khác nhau có thể

đê giảm thiểu tổng số các trường hợp cần thiết

2 Nên cố gắng phàn hoạch các miền đầu vào của một chương trình thành một số xác định các lóp tương đương, sao cho có thể giả định hợp lí rằng việc kiểm thử một giá trị đại diện của mỗi lớp là tương đương với việc kiểm thử một giá trị bất

kì khác trong cùng lớp đó (tuy nhiên, điều này là không đảm bảo tuyệt đối) Có nghĩa là, nếu một trường hợp kiểm thử trong một lớp tương đương phát hiện ra một lỗi, thì tất cả các trường hợp khác trong lớp tương đương đó sẽ phát hiện ra cùng một lỗi đó Ngược lại, nếu một trường hợp kiểm thử không phát hiện ra một lỗi, thì không có một trường hợp kiểm thử nào khác trong lớp tương đương đó phát hiện ra lỗi (trừ khi một tập con của lớp tươriR đương nằm trong một lớp tương đương khác, vì các lớp tương đương có thể gối lên nhau)

Hai vấn đề xem xét ở trên tạo thành một phương pháp của kĩ thuật hộp đen và gọi là phân hoạch tương đương Vấn đề thứ hai được sử dụng để phát triển một tập các điều kiện cần quan tâm phải được kiểm thử Vấn đề thứ nhất được sử dụng để phát triển một tập cực tiểu các trường hợp kiểm thử phủ các điều trên

Thiết kế trường hợp kiểm thử bằng phàn hoạch tương đương được xử lí theo hai bước: xác định các lớp tương đương, và xác định các trường hợp kiểm thử

II.3.1.1 Xác định các lớp tương đương

Các lớp tương đương được nhận dạng bằng cách lấy mỗi điều kiện đầu vào (thông thường là một câu hoặc một cụm từ trong đặc tả) và phân hoạch nó thành hai hoặc nhiều nhóm Để làm điều này, chúng ta sử dụng bảng liệt kê các lớp tương đương

Chú ý rằng hai kiểu của các lớp tương đương được nhận dạng là: các lớp tương đương hợp lệ biểu diễn những đầu vào hợp lệ cho chương trình, và các lớp tương đương không hợp lệ biểu diễn tất cả các trạng thái điều kiện đầu vào có thể khác (tức là các điều kiện đầu vào bị lỗi)

Một tập con như vậy cần có hai tính chất:

BẢNG II 1 — BẢNG LIỆT KÊ CÁC LÓP TƯƠNG ĐƯƠNG

Theo cách đó, chúng ta sẽ bám vào những nguyên lí kiểm thử thứ 5 sẽ trình bày trong mục III 1 phát biểu là ” Các trường hợp kiểm thử phải được viết cho các điều kiện đầu vào không hợp lệ (invalid) và không mong đợi (unexpected), cũng như những điều kiện hợp lệ (valid) và được mong đợi (expected)”.

Một điểu kiện vào/ra được đưa ra thì việc xác định các lớp tương đương là một quá trình kinh nghiệm, với 5 nguyên tắc như dưới đây:

1 Nếu một điều kiện vào đưa ra là một khoảng giá trị (a range of values) (ví

3 Nếu điểu kiện đầu vào chỉ ra một tập các giá trị và có lí do để tin rằng chương trình sẽ xử lí khác nhau cho mỗi giá trị (ví dụ, các loại xe cộ phải

là xe buýt, xe tải, xe taxi, xe ca, xe khách, hoặc mô tô), thì hãy chí ra một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ (ví dụ, xe moóc).

4 Nếu một điều kiện đầu vào đưa ra một tình trạng bắt buộc (kí tự đầu tiên của một tên phải là một chữ cái), thì hãy chỉ ra một lớp tương đương hợp

lệ (đó là 1 chữ cái), và một lớp tương đương không hợp lộ (đó không phải

là chữ cái)

5 Nếu có một lí do để tin rằng các phần tử trong một lớp tương đương mà chương trình không thể xử lí được theo cách thức giống nhau thì phải phân chia lớp tương đương đó thành những lớp tương đương nhỏ hơn

II.3.1.2 Xác định các trường hợp kiểm thử

Bước thứ hai là việc sử dụng lớp tương đương để xác định các trường hợp kiểm thử Tiến trình đó là:

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

2 Đến khi tất cả các lớp tương đương hợp lệ được phủ bởi các trường hợp kiểm thử thì viết một trường hợp kiểm thử mới phủ lìhiều nhất có thê các lớp tương dương hợp lệ chưa được phủ

3 Đến khi tất cả các lớp tương đương không hợp lệ được phủ bởi các trường hợp kiểm thử, hãy viết các trường hợp kiểm thử mới sao cho mỗi trường hợp kiểm thử mới chỉ phủ duv nhất một lớp tương đương không hợp lệ chưa được phủ

Các trường hợp không hựp lệ được phủ bởi các trường hợp kiểm thử riêng biệt là do việc kiểm tra đầu vào có lỗi này sẽ bị che hoặc bỏ sót việc kiểm tra đầu vào có lỗi khác Ví dụ, một đặc tả phát biểu ’’Hãy nhập vào loại máy tính cá nhân (Máy tính để bàn, Máy tính sách tay, Máy tính bò túi) và tổng số (1-9999)”, một trường hợp kiểm thử là

ABC 0

biểu diễn hai điều kiện lỗi (lỗi loại máy tính và số lượng không hợp lệ) có thể sẽ không thực hiện việc kiểm tra cho trường hợp số lượng không hợp lệ, bởi vì chương trình kiểm tra điều kiện đầu vào không hợp lệ của loại máy tính cá nhân trước và thông báo lỗi cho trường hợp này (chẳng hạn như: ’’Không có loại máy tính nào là ABC”)

= 1

=99Một biểu thức sinh ra một

số không hợp lệ, ví dụ 4-5, hoặc 5-5

Chữ cái và các kí tự không phải là số, ví dụ ’a \

II.3.2 Phân tích giá trị biên (Boundary-Value Analysis)

Cái nhìn đơn giản nhất về phần mềm là chia thế giới của nó thành 2 phần: dữ liệu (hay miền xác định của nó) và chương trinh Dữ liệu là đầu vào từ bàn phím, kích chuột, tệp tin trên đĩa, bản in ra v.v

Khi chúng ta thực hiện việc kiểm thử phần mềm theo dữ liệu, chúng ta kiểm tra xem đầu vào của người dùng, kết quả mà họ nhận được, và kết quả tạm thời bên trong phần mềm được xử lí một cách chính xác hay không

Các điều kiện biên là tình trạng trực tiếp ở phía trên và phía dưới của các lớp tương đương đầu vào và các lớp tương đương đầu ra Việc phân tích các giá trị biên khác với phân hoạch tương đương theo hai đặc điểm

1 Từ mỗi lớp tương đương, phân hoạch tương đương thì lựa chọn phần tử bất kì làm phần tử đại diện, việc phân tích giá trị biên sử dụng chí một hay nhiều phần

tử Như vậy, mỗi biên của lớp tương đương là chủ đề của kiểm thử

2 Không chỉ chú ý tập trung vào những điều kiện vào (không gian vào), các trường hợp kiểm thử cũng được suy từ việc xem xét không gian kết quả (tức là các lớp tương đương đương đầu ra).

Các trường hợp kiểm thử tốt nhất là tại biên của lớp Những giá trị biên là những phần tử cực tiểu/cực đại, ngắn nhất/dài nhất, chậm nhất/nhanh nhất, xấu nhất/đẹp nhất, đầu/cuối, bắt đầu/kết thúc, rỗng/đầy, sớm nhất/muộn nhất, to nhất/bé nhất, tức là, những giá trị cận nhất Rất khó có thể liệt kê hết những hướng dẫn cụ thể cho các trường hợp Tuy nhiên, cũng có một số nguyên tắc như sau:

1 Nếu điều kiện đầu vào đưa ra một khoảng giá trị thi viết những trường hợp kiếmthử tại hai điểm đầu cuối của khoảng, và những trường hợp kiểm thử đầu vào không hợp lệ, chỉ những trạng thái ngay sát bên ngoài của hai điểm đầu cuối Ví

dụ, miền giá trị của một giá trị đầu vào là [-1,0; 1,0] thì hãy viết những trườnghợp kiểm thử cho những trạng thái -1,0; 1,0; -1,001; và 1,001

2 Nếu một điều kiện đầu vào đưa ra một số các giá trị thì hãy viết các trường hợp kiểm thử cho các giá trị cực đại và cực tiểu, và một giá trị trên, một giá trị dưới

Ví dụ, nếu một tệp tin đầu vào có chứa 1-255 bản ghi thì hãy viết những trường hợp kiểm thử cho 0, 1, 255, và 256 bán ghi

3 Sử dụng nguyên tắc 1 cho mỗi điều kiện đầu ra

4 Sử dụng nguyên tắc 2 cho mỗi điều kiện đầu ra

5 Nếu đầu vào hoặc đầu ra của một chương trình là tập có thứ tự (chẳng hạn tệp tin tuần, danh sách tuyến tính, bảng), hãy tập trung chú ý vào phần tử đầu và cuối của tập đó

6 Hơn nữa, người kiểm thử có thể sử dụng sự sáng tạo và xét đoán của mình để tìm các điều kiện biên

Nói một cách ngắn gọn, chúng ta phải kiểm thử mỗi biên của một lớp tương đương về tất cả các phía Một chương trình nếu vượt qua những trường hợp kiếm thử

đó có thể vượt qua những kiểm thử khác từ lớp đó

- Cho một khoảng giá trị [a,b] của một giá trị đầu vào, chúng ta phải kiểm thử các trường họp (a-1), a, (a+1), (b-1), b, (b+1).

- Nếu điều kiện đầu vào đưa ra một số có giá trị n, chúng ta phải kiểm thử với

cả (n-1), và (n+1) cho các giá trị đầu vào

- Nếu một chương trình muốn một chữ hoa (từ ’A’ đến ’Z’), chúng ta phải thử

’(§)’ vì mã ASCII là mã sát dưới của ’A’ và ’[’ là kí tự sát trên của ’Z \ Và tất nhiên, chúng ta cũng nên thử ’a’ và ’z \

- Nếu một chương trình in những đường thẳng dài từ 1 điểm đến lOcm, chúng

ta phải thử vẽ đường thẳng dài 1 điểm, lOcm, 0 điểm, và 1 lcm

Nếu chương trình cần một số xác định các đầu vào, nhưng chúng ta cũng nên thử với nhiều hơn 1, và ít hơn 1

- Thử gửi tệp ra máy in ngay trước và sau khi người khác gửi

II.3.3 Kĩ thuật đồ thị nhàn quả

Đây là một kĩ thuật kiểm thử hộp đen Đồ thị nhân quả sử dụng một mô hình các quan hệ lôgic giữa nguyên nhân và kết quả cho thành phần phần mềm Mỗi nguyên nhân biểu diễn như là một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào Mỗi kết quả được biểu diễn như là một biểu thức bool biểu diễn một kết quả hoặc các kết quả kết họp cho những thành phần vừa thực hiện

Mô hình biểu diễn đặc trung như là một đồ thị bool liên quan đến đầu vào và các biểu thức bool đầu ra sử dựng các toán tử AND, OR, NAND, NOR, NOT Từ đồ thị này, chúng ta tạo ra một bảng quyết định biểu diễn các quan hệ logic giữa nguyên nhân và kết quả

Tất cả các trường hợp kiểm thử sẽ được thiết kế để thực hiện các quy tắc xác định quan hệ giữa các đầu vào và những đầu ra của các thành phần Mỗi quy tắc tương ứng với một kết hợp duy nhất có thể của các đầu biểu diễn theo giá trị bool Các trường hợp kiểm thử được xác định như sau:

- Trạng thái bool (tức là đúng hoặc sai) cho mỗi nguyên nhân;

M ột sô ví dụ:

Các kí hiệu được đơn giản hoá được sử dụng trong đồ thị nhân quả, gồm có các phần tử như trong hình II.3.

Đồ thị nhân quả biểu diễn ngắn gọn các kết hợp lôgic và những hành động tương ứng Sử dụng những xử lí dưới đày để đưa ra các trường hợp kiểm thử:

1 Liệt kê các nhân (đầu vào) và quả (các hành động hoặc đầu ra) cho một môđul và định danh cho nó

2 Phát triển đồ thị nhân quả

3 Chuyển đồ thị thành một bảng quyết định

4 Các quy tắc của bảng quyết định sẽ trở thành các trường hợp kiểm thử

- Trạng thái bool cho mỗi kết quả

VÍ du:

Thực hiện chức năng ghi nợ séc, với các đầu vào là: tổng số nợ, loại tài khoản

và cân đối hiện thời và các đầu ra là: cân bằng men và mã hành động Loại tài khoản

có thể là bưu điện (’b’) hoặc quầy thanh toán (’q’) Mã hành động có thể là ’N&G\

’N’, ’T&G’ hoặc ’G \ tương ứng với ’xử lí ghi nợ và gửi thư đi’, ’chỉ xử lí ghi nợ’,

’treo tài khoán và gửi thư’ hoặc ’chí gửi thư’ Chức năng trên có nhũng đặc tả dưới đây:

Nếu có đủ tiền trong tài khoản hoặc cân đối mới không quá giới hạn được phép rút thì nợ được xử lí Nếu cân đôi mới vượt quá giới hạn được phép rút thì nợ không được xử lí và nếu đó là tài khoản bưu điện thì nó sẽ tạm bị khoá Thư sẽ được gửi cho tất cả các giao dịch trên tài khoản bưu điện và cho những tài khoản không phải bưu diện nếu tài khoản không còn tiền.

Các điểu kiện là:

c 1 : Cân bằng mới còn tiền

C2: Cân bằng mới đã rút quá số tiền có trong tài khoản, nhưng trong giới

hạn cho phcp

C3: Tài khoản bưu điện

Những hành động sẽ là:

A 1 : Xử lí nợ

A2: Tạm khoá tài khoản

A3: Gửi thư đi

Đặc tả được mô hình bằng đồ thị đưa ra trong hình II.4

Đồ thị sẽ được viết lại dưới dạng một bảng quyết định Mỗi cột của bảng quyết định là một quy tắc Bảng bao gồm 2 phần Trong phần thứ nhất, mỗi quy tắc ứng với các điều kiện T ’ chỉ ra rằng điều kiện sẽ là đúng khi quy tắc được áp dụng

và ’F’ chỉ ra rằng điều kiện là sai khi quy tắc được áp dụng Trong phần thứ hai, mỗi quv tắc trong bảng ứng với các hành động T ’ chỉ ra rằng hành động sẽ được thực

hiện; ’F’ chi ran rằng hành động sẽ không được thực hiện; dấu hoa thị ’*’ chí ra rằng sự kết hợp các điểu kiện là bất khả thi và không hành động nào được áp dụng cho quy tắc.

Trường hợp

kiểm thử

Loại tài khoản

Giới hạn được rút

(quá sô tiền có

trong tài khoản)

Cân bằng hiện thời

Tổng s ố

nợ

Cân bằng mới

M ã hành động

I I.3 4 Đ o á n lỗi (E r ro r Guessing)

K hông cần m ột phương pháp đặc biệt nào, m ột số chuyên gia có thế kiểm tra các điều kiện lỗi bằng cách đoán lỗi dễ xảy ra Trên cơ sở trực giác và kinh nghiệm , với những chương trình cụ thể, các chuyên gia ước đoán những loại lỗi có thể, rồi viết các trường hợp kiểm thử để phơi ra những lỗi này.

K hó đưa ra được một thủ tục cho việc đoán lỗi vì đó là m ột quá trình của trực giác và tự học Ý tương cơ bản là liệt kê m ột danh sách các lỗi có thể hoặc những tình huống dễ m ắc lỗi, rồi viết các trường hợp kiểm thử dựa trên danh sách Chảng hạn như sự xuất hiện giá trị 0 trong đầu vào hoặc đầu ra của một chương trình là tinh

h uống dễ có lỗi Vì vậy, người ta viết những trường hợp kiểm thử cho những giá trị đầu vào có giá trị 0 và những giá trị ra là 0 V à cũng như vậy đối với trường hợp số biến vào và ra có thể biễu diễn (chẳng hạn số đầu vào trong m ột danh sách được tìm kiếm ), các trường hợp danh sách rỗng hoặc chỉ chứa m ột phần tử là những tình

h uống dễ gây lỗi.

M ột ý tướng khác là chi ra các trường hợp kiểm thử liên quan đến giả định rằng lập trình viên đã m ắc phải khi đọc đặc tả (tức là những thứ bị bỏ sót từ đặc tả có thê do tình cờ).

Có thể nói m ột cách tổng quát là người ta liệt kê các trường hợp đặc biệt có thể bị bỏ sót trong khi chương trình được thiết kế.

Đ oán lỗi vì dựa trên trực giác nên kĩ thuật này chỉ là kĩ thuật bổ sung.

K iểm thử đường dẫn cơ sở là m ột k ĩ thuật kiểm thử hộp trắng do M cCache đề xuất Phương pháp đường dẫn cơ sở cho phép người thiết k ế các trường họp kiểm thử thực hiện m ột phép đo phức tạp logic của m ột thiết k ế thủ tục và sử dụng phép đo này như là m ột chỉ dẫn cho việc thiết k ế m ột tập cơ sở các đường dẫn thực hiện Những trường hợp kiểm thử được suy diễn để thực hiện tập cơ sở Các trường hợp kiểm thử đó được đám bảo đế thực hiện mọi lệnh trong một chương trình ít nhất một lần trong qu á trình kiểm thử.

I I 3 5 1 K í h iệ u đ ồ th ị lư u tr ìn h

T rong thực tế, phương pháp đường dẫn cơ sở có thể được dùng không cần sử dụng đồ thị lưu trình Tuy nhiên, đồ thị lưu trình là m ột công cụ hữu ích để hiểu lưu trình điều khiển và m inh hoạ phương pháp tiếp cận Phần này sẽ trình bày m ột số kí hiệu đơn giản của lưu trình điều khiển, được gọi là m ột đồ thị lưu trình (hay còn gọi

là đồ thị chương trình) Đ ồ thị lưu trình vẽ lun trình điều khiển logic sử dụng m ột sô'

kí hiệu được m inh hoạ như hình II.5 Mổi cấu trúc điều khiển có m ột kí hiệu đồ thị lưu trình tương ứng.

Các kí hiệu trên đồ thị:

- Con trỏ gọi là cung, biểu diễn lưu trình điều khiển.

- H ình tròn được gọi là đỉnh, biểu diễn m ột hoặc nhiều lệnh.

Phần được bao bởi các cung và các đỉnh được gọi là vùng.

- Đ ính có chứa m ột điều kiện gọi là đỉnh điều kiện

Bat c u mot thiet ke thu tuc nao d£u co the chuy6n dugc sang do thi liru trinh Cac bieu thurc bool to hop trong cac kiem thu co the’ tao ra it nha't 2 dinh dieu kien va cac cung b6 sung.

HiNH 11.5 - Kl HIEU DO THj LUU TRINH

(a)

sẽ xác định số đường dẫn độc lập trong m ột tập cơ sở của một chương trình và cung

cấp cho chúng ta giới hạn trên cho số lượng kiểm thử bắt buộc để đ ảm bảo rằng tất

cả các lệnh được thực hiện ít nhất m ột lần.

M ột đường dẫn độc lập là m ột đường dẫn bất kì trong chương trình đưa ra ít nhất m ột tập lệnh xử lí mới hoặc m ột điều kiện mới (tức là một cu n ? mới) Phát biểu dưới đổ thị lun trình, m ột đường dẫn độc lập phải được chuyển theo ít nhất m ột cung

m à nó chưa đi qua trước khi đường dẫn được xác định.

V í dụ, m ột tập các đường dẫn độc lập cho đồ thị lưu trình được m inh họa trong hình Il.ỏ.b là:

- Đ ư ờng dẫn 2: 1-2-3-4-5-10-1-11

- Đ ư ờng dẫn 3: 1-2-3-6-8-9-10-1-11

M ỏi đường dẫn mới đưa ra m ột cung mới Đ ường dãn 1-2-3-4-5-10-1-2-3-6- 8-9-10-1-11 không được xem là m ột đường dẫn độc lặp vì nó chì là m ột tổ hợp các đường d ẫn đã được chỉ ra (đường dẫn 2 và 3) và nó sẽ không đi qua m ột cung mới nào.

Đ ường dẫn 1, 2, 3 và 4 tạo thành một tập cơ sở trong hình Il.ó.b N ếu các trường hợp kiếm thử được thiết k ế đê’ thực hiện những đường dẫn này (m ột tập cơ sở) thì m ọi lệnh trong chương trình sẽ đảm bảo được thực hiện ít nhất m ột lần và mọi điều kiện sẽ được thực hiện cả hai phía đúng (true) và phía sai (false) Tuy nhiên, tập cơ sở không phải là duy nhất Trong thực tế, m ột số các tập cơ sở khác nhau có thể được suy diễn cho việc thiết k ế m ột thủ tục được đưa ra.

V iệc tính toán độ đo cyclom at sẽ cho chúng ta biết có bao nhiêu dường dẫn cần tìm Đ ộ phức tạp cyclom at là m ột khám phá trong lí thuyết đồ thị và nó cung cấp cho chúng ta m ột thước đo phần m ềm rất hữu ích Đ ộ phức tạp được tính toán theo ba cách:

1 Số vùng của đồ thị lưu trình tương ứng với độ phức tạp cyclom at.

2 Đ ộ phức tạp cyclom at, V (G ) của đồ thị lưu trình G được xác định như sau: V (G ) = E - N + 2.

ở đây E là số cạnh của đồ thị lưu trình, N là số đính của đồ thị lưu trình.

3 Đ ộ phức tạp cyclom at, V (G ) của đồ thị lưu trình G được xác định như sau: V (G ) = p + 1.

ở đây p là số đinh điều kiện có trong đồ thị lun trình G.

Đ ối chiếu với hình II.6.b, độ phức tạp cyclom at được tính theo 3 thuật toán trên như sau:

1 Đồ thị lưu trình có 4 vùng.

2 V ( G ) = 11 cung - 9 đỉnh + 2 = 4.

3 V (G ) = 3 đỉnh điều kiện + 1 = 4

- Đường dẫn 4: 1-2-3-6-7-9-10-1-11