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

ĐẠI HỌC QUỐC GIA HÀ NỘI
KHOA CÔNG NGHỆ
Nguyễn Văn Hanh
M Ô T S Ố V Ấ N Đ Ể
V Ể K I Ể M T H Ử P H Ầ N M Ề M
Chuyên ngành: Công nghệ Thông tin
Mã số: 1.01.10
LUẬN VĂN THẠC s ĩ
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 '40
TRUNG TÁM THÔNGTỈN.T; iư \'iẼ
Hà Nội - Năm 2003
M oY - LO
Mục lục
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 n iệ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 (Black-Box Testing) 21
11.2. K ĩ thu ậ t kiểm th ủ hộ p trắng (White-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
Chương Y ß - Chiến lược kiểm thử phần mềm 53
m. 1. M ộ t s ố ngu yê n lí kiể m thử c ầ n th iế t [1 1] 53
III.2. Luồng th ôn g tin kiểm thử 56
III. 3. Phương p h á p tiếp cậ n kiểm thử ph ẩ 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 ôđ un /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 ĩ thu ậ 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.1. Kiểm thử mô hình phân tích hướng đối tượng (OOA) và thiết kê hướng
đối tượng (OOD) 83
IV. 1.2. Các trường hợp kiểm thử cho phần mềm hướng đối tượng

87
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
-4-
Chưư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
Ngày nay, công nghệ thông tin đã được ứng dụng rộng rãi trong mọi lĩnh vực
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
Lời giới thiệu
và phát triển phần mềm đã bắt đầu có nhiều quan tâm hơn đến vấn đề kiểm thử phần
mềm. Tuy nhiên, hầu như vẫn chưa được đầu tư và quan tâm đúng mức. Nước ta
đang trong quá trình xây dụng một ngành công nghiệp phần mềm thì không thế xem
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
-7-
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
-8-
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ể.

Chương I - Sơ lược về phần mềm và kiểm thử phần mềm
/. 1. M ộ t s ố k h á i n iệ m v à vố n đ ề liê n q u a n
1.1.1. Sản phẩm phần mềm là gì?
Nhiều người nghĩ một cách đơn giản rằng phần mềm là một chương trình mà
chúng ta cài đặt từ đĩa mềm hay đĩa CD-ROM và chạy trên máy tính. Đó là một mô
tả rất hay, cũng có phần hợp lí, nhưng trên thực tế, có nhiều phần ẩn sau một sản
phẩm phần mềm và không kém phần quan trọng. Như chúng ta thấy trong Hình 0.1,
còn nhiều yếu tố để tạo nên một sản phẩm phần mềm, trong đó có nhiều yếu tố trừu
tượng không được đưa ra.
Phản hổi từ các
Thỏng tin
phiô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
-10-
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
Lặp trình và
kiêm thừ dơn
vi
Tích hợp và
kiểm thử tích
hợp
Kiếm ỉhừ hé
thông
Hai ihàp ki I960
và 1970
10% 80%
10%
Thập ki 1980
20%
60% 20%
Thập ki 1990
40%
30%
30%
Theo một tài liệu khác 122], chi phí liên quan từng giai đoạn của vòng đời
phần mềm như sau:
BẢNG 0.2 — CHI PHÍ CỦA CÁC GIAI ĐOẠN TRONG VÒNG ĐÒI PHẨN MỀM
Các giai doan phát trien Giai đoan sán pham
Phân tích yêu cầu 3% Vận hành và bảo trì 67%
Đạc tả 3%
Thiết kế 5%
Lập trình 1%
Kiểm thứ 15%
Như chúng ta đã thấy, một sản phẩm phần mềm không chỉ đơn gián là các

đoạn mã chương trinh mà còn rất nhiều phần ẩn đằng sau nó. Vì vậy, việc mắc lỗi
không chỉ xảy ra trong quá trình lập trình mà còn xảy ra cao hơn trong các công
đoạn khác của quá trình phát triển một sản phẩm phần mềm. Việc kiểm thử cũng vì
thế phải được tiến hành trong tất cả các phần tạo nên một sản phẩm 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.
-11-
- 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
-12-
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àng
0.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.
-13-
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.
-14-
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 ình vò n g đ ờ i p h á t triể n p h ầ n m ề m v ó i v á n đ ề k iể m
t h ử
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
-15-
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
-16-
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
chính thức
Lâp trình Sửa lỗi
HÌNH 0.5 — MÔ HÌNH CODE-AND-FIX
-17-
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.
Thời gian
►
HÌNH 0.6 — MÔ HĨNH THÁC NƯỚC
-18-
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
-19-
6. Quyết định phương pháp cho mức tiếp theo
Xác địn h mục tiêu,
sự thay th ế và

ràng
Phát triển và kiểm
thử mức hiện tại
Q u yết định
phương pháp
mức tiếp
Duyệt lạ.
'
Sản phẩm cuối cùng
Chi phí
tích luỹ
N hận biết và
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ề
-20-
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.
-21-
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 o x 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).
Đầu vào Dầu vào
Đầu ra Đầu ra
Kiểm thử hôp đen Kiểm thử hộp trắng
HỈNH II. 1 — KIỂM THỬ HỘP ĐEN VÀ KIÊM THỬ HỘP TRANG
Trong 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
-22-
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 o x 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

-23-
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ÊN
Giả 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 -1
5-1
> 2 0 lần
;o
1014
«10'' = ! tỉ năm!
-24-
(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