Bài giảng kiểm thử phần mềm đh phạm văn đồng

TRƯỜNG ĐẠI HỌC PHẠM VĂN ĐỒNG
KHOA CÔNG NGHỆ THÔNG TIN

VÕ ĐỨC LÂN

BÀI GIẢNG

KIỂM THỬ PHẦN MỀM
(Dùng cho sinh viên các lớp đại học Công nghệ thông tin)

Quảng Ngãi, 07 - 2020


TRƯỜNG ĐẠI HỌC PHẠM VĂN ĐỒNG
KHOA CÔNG NGHỆ THÔNG TIN

VÕ ĐỨC LÂN

BÀI GIẢNG

KIỂM THỬ PHẦN MỀM
(Dùng cho sinh viên các lớp đại học Công nghệ thông tin)

Lưu hành nội bộ


MỤC LỤC

LỜI NÓI ĐẦU ....................................................................................................................... 1
CHƯƠNG 1 GIỚI THIỆU VỀ KIỂM THỬ ............................................................................ 2
1.1 Khái niệm lỗi ............................................................................................................. 4

1.2 Khái niệm kiểm thử .................................................................................................. 6
1.3. Các bước kiểm thử ................................................................................................ 11
1.4. Kiểm chứng và hợp thức hóa .............................................................................. 13
1.5. Khái niệm hoạt động kiểm thử ............................................................................ 13
1.6. Các nguyên tắc kiểm thử ..................................................................................... 15
1.7. Các khó khăn của kiểm thử ................................................................................. 19
1.7.1 Khó khăn liên quan đến quy trình phát triển phần mềm ........................... 19
1.7.2 Khó khăn về mặt con người ........................................................................... 19
1.7.3 Khó khăn về mặt kĩ thuật ............................................................................... 20
1.8 Kết luận ............................................................................................................... 20
Câu hỏi và bài tập ............................................................................................................ 21
CHƯƠNG 2 KIẾM THỬ TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM ................... 22
2.1. Các kĩ thuật kiểm thử ........................................................................................... 22
2. 1. 1. Phân nhỏm các kĩ thuật kiểm thử.............................................................. 22
2.1.2 Sự hiệu quả của các kĩ thuật kiểm thử ......................................................... 25
2.1.3. Mục tiêu cùa các nhóm kĩ thuật kiểm thử .................................................. 26
2.2. Các quy trình phát triển phần mềm .................................................................... 28
2.2.1 Quy trình thác nước ........................................................................................ 28
2.2.2.Quy trình V ....................................................................................................... 29
2.2.3. Quy trình xoắn ................................................................................................ 30
2.2.4.Quy trình hợp nhất .......................................................................................... 30


2.2.5. Nhận xét .......................................................................................................... 31
2.3 Các hoạt động kiểm thử trong quy trình phát triển phần mềm ........................ 32
2.3.1. kiểm thử đơn vị ............................................................................................... 33
2.3.2. Kiểm thử tích hợp .......................................................................................... 35
2.3.3. Kiểm thử hệ thống ......................................................................................... 38
2.3.4. Kiểm thử hồi quy ............................................................................................ 40
2.3.5. Kiểm thử chấp nhận ....................................................................................... 40

2.4. Kết luân .................................................................................................................. 42
Câu hỏi và bài tập ............................................................................................................ 42
CHƯƠNG 3 KIỂM THỬ CHỨC NĂNG - KIỂM THỬ CẤU TRÚC .................................. 43
3.1. Kiểm thử giá trị biên ............................................................................................. 44
3.2. Kiểm thử giá trị đặc biệt ....................................................................................... 50
3.3. Kiểm thử lớp tương đương ................................................................................... 50
3.4. Kiểm thử dựa trên bảng quyết định .................................................................... 57
3.5. Kiểm thử dựa trên đồ thị luồng điều khiển ........................................................ 65
3.5.1. Khái niệm đồ thì ............................................................................................. 66
3.5.2. Tiêu chí bao phủ định .................................................................................... 70
3.5.3. Tiêu chí bao phủ cung ................................................................................... 72
3.5.4. Tiêu chí bao phủ lộ trình ............................................................................... 75
3.5.5. Tiêu chí bao phủ lộ trình độc lập ................................................................. 76
3.6. Kiềm thử dựa trên đồ thị luồng dữ liệu .............................................................. 82
3.6.1. Đồ thị luồng dữ liệu........................................................................................ 82
3.6.2. Tiêu chí bao phủ định nghĩa ......................................................................... 84
3.6.3. Tiêu chí bao phủ sử dụng ............................................................................. 86
3.6.4. Tiêu chí bao phủ lộ trình định nghĩa sử dụng ............................................ 86
3.7. Kiểm thử đột biến.................................................................................................. 89


3.7.1. Khái niệm kiểm thử đột biến......................................................................... 89
3.7.2. Một số khái niệm cơ bản ............................................................................... 90
3.7.3. Quy trình kiểm thử đột biến .......................................................................... 93
3.7.4. Hạn chế của kiểm thử đột biến ..................................................................... 94
3.7.5. Ứng dụng của kiểm thử đột biến .................................................................. 95
3.8. Kết luận .................................................................................................................. 96
Câu hỏi và bài tập ............................................................................................................ 96
CHƯƠNG 4 THIẾT KẾ CÁC TRƯỜNG HỢP KIỂM THỬ ................................................ 98
4.1. Lập kế hoạch kiểm thử ......................................................................................... 98

4.2. Đặc tả thiết kế kiểm thử, ca kiểm thử và thủ tục kiểm thử ........................... 100
4.2.1 Đặc tả thiết kế kiểm thử .............................................................................. 100
4.2.2 Đặc tả ca kiểm thử ....................................................................................... 101
4.2.3. Đặc tả thủ tục kiểm thử .............................................................................. 102
4.3. Lập báo cáo kiểm thử ........................................................................................ 103
4.3.1. Nhật kí kiểm thử .......................................................................................... 103
4.3.2. Báo cáo lỗi ................................................................................................... 104
4.3.3. Báo cáo kiểm thử ........................................................................................ 105
4.4. Kết luận ............................................................................................................... 105
Câu hỏi và bài tập ......................................................................................................... 107
CHƯƠNG 5 KIỂM THỬ TỰ ĐỘNG VÀ CÔNG CỤ KIỂM THỬ .................................. 108
5.1. Kiểm thử tự động ............................................................................................... 108
5.2. Đặc điểm cơ bản của kiểm thử tự động........................................................... 110
5.2.1. Ưu điểm của kiểm thử tự động .................................................................. 111
5.2.2. Vấn để của kiểm thử tự động ..................................................................... 111
5.2.3. Kiễm thử thủ cơng và kiểm thử tự động................................................... 113
5.3. Quy trình kiểm thử tự động............................................................................... 114


5.4. Công cụ kiểm thử tự động ............................................................................. 114
Câu hỏi và bài tập ......................................................................................................... 119
TÀI LIỆU THAM KHẢO.................................................................................................. 120


LỜI NÓI ĐẦU
Chúng ta đã và đang chứng kiến sự tăng trưởng đáng kinh ngạc của ngành công
nghiệp phần mềm trong vài thập kỷ qua. Nếu như trước đây phần mềm máy tính chỉ
được sử dụng để tính tốn khoa học kỹ thuật và xử lý dữ liệu thì ngày nay nó đã được
ứng dụng vào mọi mặt của của đời sống hàng ngày của con người, từ các ứng dụng
nhỏ để điều khiển các thiết bị dùng trong gia đình như các thiết bị nghe nhìn, điện

thoại, máy giặt, lị vi sóng, nồi cơm điện, đến các ứng dụng lớn hơn như trợ giúp điều
khiển các phương tiện và hệ thống giao thơng, trả tiền cho các hố đơn, quản lý và
thanh tốn về tài chính, vân vân. Vì thế con người ngày càng phụ thuộc chặt chẽ vào
các sản phẩm phần mềm và do vậy đòi hỏi về chất lượng của các sản phẩm phần mềm
ngày càng cao, tức là các phần mềm phải được sản xuất với giá thành hạ, dễ dùng, an
toàn và tin cậy được. Kiểm thử có phương pháp là một hoạt động khơng thể thiếu
trong quy trình sản xuất phần mềm để đảm bảo các yếu tố chất lượng nêu trên của các
sản phẩm phần mềm.
Bài giảng được thiết kế dành cho sinh viên đại học ngành Công nghệ thông tin.
Nội dung được xây dựng đúng chương trình chi tiết của học phần môn Kiểm thử phần
mềm đã được ban hành. Hy vọng bài giảng sẽ là tài liệu bổ ích dành cho sinh viên
ngành Công nghệ thông tin cảu Trường Đại học Phạm Văn Đồng. Tuy nhiên do hạn
chế về thời gian nên bà giảng cịn nhiều thiếu sót. Mong nhận được nhiều ý kiến đóng
góp từ các bạn đọc, đồng nghiệp và Sinh viên.
Tác giả

Võ Đức Lân

Trang 1


CHƯƠNG 1
GIỚI THIỆU VỀ KIỂM THỬ
Vào những thập niên 1960 hay 1970, rất ít người sử dụng máy tính, thì ngày nay
những người làm việc trong văn phòng hầu như khơng thể làm việc thiếu máy tính.
Tất nhiên, ngày nay máy tính đã phát triển với tốc độ cao hơn hàng nghìn lần. Phần
mềm được sử dụng sẽ tác động đến công việc của rất nhiều người phần mềm giúp cho
con người thực hiện công việc hiệu qủa hơn. Như thế, việc phát triển phần mềm chất
lượng càng trở nên quan trọng hơn.
Quy trình phát triến phần mềm bao gồm nhiều giai đoạn và nhiều hoạt động

nhằm tạo ra sản phẩm phần mềm. Trong đó, kiểm thử là một trong những hoạt động
đóng vai trị quan trọng nhằm phát hiện lỗi của phần mềm. Kiếm thử phần mềm ngày
càng trở nên khó khăn hơn. bởi vi các ngơn ngừ lập trình, các hệ điêu hành, các
phương pháp phát triển phần mềm cũng như các thiết bị phần cứng ngày càng phong
phú và đa dạng.
Một cách lí tưởng, chúng ta muốn kiểm thử tất cả các trường hợp thực thi có thế
của một chương trình. Tuy nhiên, điều này là khơng thể thực hiện dược. Bởi vì, thậm
chí đối với một chương trình rất đơn giản thi nó cũng có số lượng dữ liệu vào rất lớn
(hàng ngàn, hàng triệu...).
Mặc dù theo các kết quả thống kê, chi phí kiếm thử rất lớn, chiếm khoảng hơn
50% tổng chi phí cho một dự án phát triền phần mềm, tuy nhiên lỗi phần mềm vẫn
luôn tồn tại và gây ra những thiệt hại rất lớn. Chúng ta sẽ xem xét một vài lỗi phần
mềm nghiêm trọng dưới đây.
Năm 1994, Công ty Disney tung ra thị trường phần mềm trò chơi Vua Sư tử
(Lion King) dành cho trẻ con. Lúc bấy giờ, có rất nhiều cơng ti chun sản xuất về
phần mềm trị chơi, còn đối với Disney đây là lần đầu tiên đặt chân vào thị trường
này. Vì thế, chiến dịch quảng cáo phần mềm trò chơi này rất rầm rộ. Phần mềm đã
được bán rất chạy. là món quà quý giá cho trẻ con nhân dịp giáng sinh. Tuy nhiên,
điều không ngờ đã xảy ra. Ngày 26 tháng 12, một ngày sau lề giáng sinh, điện thoại
nhóm hỗ trợ khách hàng của Disney đã đố chuông liên tục. Cha mẹ của những đứa trẻ
đã phàn nàn phần mềm trị chơi khơng thể hoạt động được. Sau đó, rất nhiều bài báo
cũng như tin tức truyền hình đưa tin về vấn đề này. Cuối cùng, Disney phát hiện ra
rằng phần mềm chỉ hoại động được trên một số máy tính mà đội ngũ lập trình đã sử
dụng và khơng hoạt động được trên rất nhiều các máy tính mà đa số khách hàng đang
sử dụng.

Trang 2


Ngày 21 tháng 3 năm 1986, ở bệnh viện ung thư Tyler tại Texas, bệnh nhân

Voyne Ray Cox được thực hiện chiếu tia bức xạ sau một ca phẫu thuật. Khi kĩ thuật
viên thực hiện khởi động máy gia tốc hạt, là máy được điều khiển hoàn toàn bằng một
phần mềm máy tính, bệnh nhân cảm giác khác với những lần trước, có một sự phóng
ra điện rất mạnh làm anh ta đau đớn. Bệnh nhân đề nghị bác sĩ kiểm tra xem việc
chiếu tia bức xạ có bình thường khơng. Bác sĩ xem màn hình máy tính và thấy ghi
nhận rằng việc chiếu tia bức xạ chưa được thực hiện và một thơng điệp lỗi được hiển
thị. Sau đó một vài ngày bệnh nhân có các triệu chứng biếu hiện như bị chiếu các tia
bức xạ cường độ quá cao, bệnh nhân đã chết sau tai nạn đó vài tháng. Một tai nạn thứ
hai đã xảy ra sau đó một thời gian trên một bệnh nhân khác khi được chiếu tia bức xạ
với cùng một kết quả thông điệp lỗi. Bệnh nhân này cũng đã chết sau đó một tháng.
Sau đó, người ta đã thực hiện kiếm tra phần mềm điều khiển máy gia tốc. Kết quả
được ghi nhận là, khi thay đổi một vài tham số của phần mềm thì nhận được cùng một
thơng điệp báo lỗi, và khi đó máy sẽ phát ra tia bức xạ có cường độ mạnh gấp 100 lần
tia bức xạ bình thường. Một thời gian sau, nhà sản xuất chiếc máy đã có báo cáo rằng
phần mềm được xây dựng bởi các lập trình viên của họ, sinh ra lỗi khi có sự thay đối
các tham số. Sau các tai nạn này, trong hồ sơ lưu trữ bệnh án có rất nhiều trường hợp
chiếu tia bức xạ có vấn đề và khơng thể giải thích được đã được phơi bày.
Trong cuộc chiến vùng Vịnh năm 1991, hệ thống phòng chống tên lửa Patriot
của Mỹ đã được sử dụng để chống lại tên lửa Scud của 1-rẳc. Mặc dù có nhiều thành
cơng của hệ thống, tuy nhiên cũng có khơng ít thất bại, kể cả tai nạn đã giết chết 28
lính Mỹ ở Ả-rập Xê-Út. Sau khi kiểm tra lại, người ta phát hiện ra rằng có một lỗi
phần mềm trong hệ thống. Đó là một lỗi nhỏ về thời gian : khi thời gian tích luỹ của
hệ thống vượt quá 14 giờ thì hệ thống dị tìm dấu vết khơng cịn hoạt động chính xác.
Trong trường hợp tai nạn ờ Ả-rập Xê-út, hệ thống đã hoạt động hơn 100 giờ.
Trên đây chỉ là một số ít trường hợp nghiêm trọng do các lỗi phần mềm gây ra.
Chắc hẳn, mỗi một chúng ta đều đã là “nạn nhân” của một phần mềm hoạt động tốt ở
một thời điểm nào đó, nhưng hồn tồn khơng hoạt động ở một thời điểm khác. Nếu
đó chỉ là phần mềm trò chơi hay phần mềm văn phòng thì vấn dề sẽ được giải quyết
rất đơn giản bằng cách tắt máy tính và sau đó khởi động lại. Tuy nhiên, nếu những lỗi
phần mềm xuất hiện trong những tình huống có thể gây thiệt hại lớn về kinh tế hay

tính mạng con người (chăng hạn, các trường hợp vừa nêu ở trên), thì hậu quả của nó
thật khủng khiếp. Như thế, kiểm thử phần mềm khơng cịn chỉ là cơng việc các chun
gia khoa học máy tính, bởi vì phần mềm ngày càng được sử dụng rất rộng rãi trong
dời sổng hằng ngày. Kiểm thử phần mềm trở thành một lĩnh vực khoa học mới mẻ và
đóng vai trị rất quan trọng trong khoa học máy tính.

Trang 3


1.1 Khái niệm lỗi
Trước khi đề cập đến kiếm thử phần mềm, trước hết chúng ta sẽ tìm hiếu một số
khái niệm liên quan đến lỗi.
Trong các ví dụ ở trên, chúng ta đã thấy các phần mềm hoạt động không như
mong muốn. Như thế, thông thường chúng ta sẽ nội ràng phần mêm có lỗi. Tuy nhiên,
cũng có thế dùng nhiều thuật ngữ khác để mô tả như : thất bại, sai sót, có vấn đề, bất
thường, khơng hợp lí, khơng tương thích...
Cần phải định nghĩa rõ ràng hơn khái niệm lỗi phần mềm. Định nghĩa lỗi phần
mềm dưới đây dựa trên khái niệm đặc tả : một đặc tả (specification) là một sự thống
nhất giữa những người phát triển phần mềm hoặc giữa người phát triển phần mềm và
người sử dụng phần mềm.
Lỗi phần mềm xuất hiện khi một hay nhiều điều kiện sau là đúng [2](,):
1. Phần mềm khơng thực hiện đúng những gì mà đặc tả định nghĩa.
2. Phần mềm thực hiện những gì mà đặc tả khuyến cáo không nên thực hiện.
3. Phần mềm thực hiện những gì mà đặc tả khơng đề cập đến
4. Phần mềm khơng thực hiện những gì mà đặc tả không đề cập đến nhưng lẽ ra
nên thực hiện.
5. Phần mềm là khó hiểu hay khó sử dụng
Ví dụ về kiếm thử chương trình tính tốn trên phân số sau sẽ minh hoạ khái niệm
lỗi trên. Chương trình cho phép thực hiện các phép toán trên phân số: rút gọn, cộng,
trừ, nhân và chia.

Đặc tá định nghĩa chương trinh phải thực hiện đúng các phép toán: rút gọn một
phân số, cộng, trừ. nhân và chia hai phân số. Nếu thực hiện phép tốn cộng hai phân
số mà chương trình khơng hiển thị gì cả hoặc hiển thị kết qủa sai, dó là lỗi ứng với
điều kiện 1.
Đặc tả định nghĩa chương trình khơng nên chạy ở chế độ thường trú như một tiến
trình. Tuy nhiên, nếu khi kích hoạt chương trình lại ln được thường trú, làm tốn
kém bộ nhớ. Đó là lỗi ứng với điều kiện 2.
Khi kiểm thừ chúng ta nhận thấy, ngồi các phép tốn rút gọn một phân số. cộng.
trừ. nhân và chia hai phân số, cịn có các phép tốn cộng, trừ, nhân và chia của n (n >
2) phân số. vấn đề này không được đề cập trong đặc tả, đó là lỗi ứng với điều kiện 3.
Sau khi thực hiện các phép toán nhân hai phân số 3/10 * 100/9, kết quả là

Trang 4


300/90. Tuy nhiên, kết quả chúng la mong đợi là 10/3. Mặc dù vấn đề này khơng được
định nghĩa chính xác trong đặc tả, nhưng đó là vấn đề mà chương trình nên thực hiện.
Lỗi này tương ứng với điều kiện 4.
Lỗi ứng với điều kiện 5 khi người sử dụng chạy thử chương trình và nhận thấy
chương trình khơng tốt, cho dù đó là lí do gì. Chẳng hạn, người sừ dụng cho rằng cách
hiển thị phân số với màu sắc khó nhìn hay các nút bấm là q nhỏ. khó sử dụng. Tất
nhiên, mỗi người sử dụng có cách nhìn khác nhau về chương trình, vì thế rất khó dể
đáp ứng tất cả các yêu cầu khác nhau của người sử dụng. Tuy nhiên, khi kiếm thử phải
luôn nghĩ đến các lỗi ứng với điều kiện 5 để có những chọn lựa hợp lí nhất.
Ngồi ra, trong lĩnh vực nghiên cứu về tính khả tin cậy (dependability) [1] của hệ
thống, ba khái niệm - sai sót, lỗi và thất bại - được sử dụng nhằm thể hiện rõ mức độ
ảnh hưởng của lỗi đối với phần mềm.
Một sai sót (fault) là một sự nhầm lẫn hay một sự hiểu sai trong quá trình phát
triển phần mềm của người phát triển. Người phát triển ở đây bao gồm: người phân
tích, người thiết kế, lập trình viên, kiểm thử viên hay nói cách ngắn gọn là tất cả

những người tham gia vào quá trình phát triển phần mềm. Như thế, sai sót xuất hiện
trong q trình phát triển phần mềm. Ví dụ, người thiết kế hiểu nhầm một khái niệm
hay vấn đề nhỏ nào đó hoặc lập trình viên gõ nhầm một câu lệnh, một toán tử...
Một lỗi (error) xuất hiện trong phần mềm như là kết quả của một sai sót. Lồi làm
cho phần mềm có những hoạt động không đúng so với yêu cầu đặt ra. Như thế, chúng
ta dễ nhận thấy rằng sai sót là nguyên nhân gây nên lỗi hay khi sai sót được kích hoạt
thì tạo nên lỗi. Một cách cụ thể, sai sót xuất hiện trong q trinh phân tích, thiết kế,
lập trình thì lồi xuất hiện khi thực thi chương trinh. Ví dụ, khi thực thi một chương
trình thì xuất hiện câu thơng báo lỗi.
Một thất bại (failure) là kết quá của một lỗi xuất hiện làm cho chương trình
khơng hoạt động được hay hoạt động nhưng cho kết quả không như mong đợi. Như
thế, lỗi là nguyên nhân gây nên sự thất bại. Một khi thất bại xáy ra thì chương trình
khơng thề tiếp tục hoạt động được nữa.
Quan hệ giữa các khái niệm trên được minh hoạ trong Hình 1.1
Xảy ra
Sai sót

Xảy ra
Lỗi

Thất bại

Hình 1.1 Quan hệ giữa sai sót, lỗi và thất bại
Các khái niệm này được phân biệt chủ yếu là trong lĩnh vực nghiên cứu về độ tin

Trang 5


cậy của phần mềm. Lĩnh vực này tập trung nghiên cứu trên các phần mềm quan trọng
(critical software), nghĩa là nếu có lỗi xảy ra thì hậu q rất lớn. thậm chí là nguy

hiểm. Chẳng hạn, các phần mềm điều khiển tàu điện ngầm, điều khiển tên lửa...
Mục đích của chúng ta quan tâm đặc biệt tới các lỗi phạm phải nhằm hạn chế tối
thiểu các thất bại có thể xuất hiện. Nhằm tránh sự chặt chẽ nghiêm ngặt có thể làm
ảnh hưởng tính sư phạm của tài liệu, chúng tôi sử dụng một cách không phân biệt các
khái niệm lỗi và sai sót trong tài liệu này.
Tập hợp các lỗi có thế ảnh hưởng đến phần mềm là khơng xác định và như thế
khó có thế có sự phân loại chúng một cách chính xác. Tuy nhiên, chúng ta có thể phân
loại trong tài liệu này sáu lớp lỗi cơ bản trong quá trình lập trình mà người phát triển
có thể phạm phải :
-Lỗi tính tốn : lỗi ở các biểu thức tính tốn. Ví dụ, tồn tại câu lệnh X - X + 10
thay vì X = X + 100.
-Lỗi lô-gic : biểu diễn sai một điều kiện. Ví dụ, biểu thức điều kiện a > b được
sử dụng thay vì viết a < b.
-Lỗi vào/ra : gồm tất cả các lỗi liên quan xử lí dữ liệu vào/ra, như định dạng sai,
chuyển đổi sai kiểu các dữ liệu vào/ra.
-Lỗi xứ lí dữ liệu : truy cập hay thao tác sai trên dữ liệu, như sử dụng sai một
con trỏ, sử dụng vượt quá chì số mảng...
-Lồi giao tiếp : lỗi về giao tiếp giữa các thành phần bên trong của phần mềm,
chẳng hạn như truyền tham số không đúng, gọi hàm không đúng...
-Lỗi định nghĩa dữ liệu : định nghĩa sai dữ liệu. Ví dụ, một dữ liệu được định
nghĩa kiểu số thực mà đúng ra nó nên được định nghĩa kiếu số nguyên.
1.2 Khái niệm kiểm thử
Trong thực tế, khái niệm kiểm thử lại thường được hiểu một cách khơng chính
xác bởi các phát biểu như : “kiểm thử là quy trình nhằm chỉ ra rằng không tồn tại lỗi
trong phần mềm” hay “kiểm thử nhằm mục đích chỉ ra rằng phần mềm thực hiện đúng
các chức năng mong đợi một cách đúng đắn”.
Nếu “kiểm thừ là quy trình nhằm chỉ ra ràng khơng tồn tại lỗi trong phần mềm”
thì mục đích này khơng thể thực hiện được với mọi phần mềm. Bởi vì trên thực tế,
không thể khẳng định được một phần mềm là không chứa lỗi, cho dù đó chỉ là chương
trình đơn giản.

Nếu “kiểm thử nhằm mục đích chỉ ra rằng phần mềm thực hiện đúng các chức
Trang 6


năng mong đợi một cách đúng đắn”, thì vẫn có thể phần mềm cịn chứa lỗi. Chẳng
hạn, lỗi vẫn có thể tồn tại nếu phần mềm thực hiện các chức năng không được đặc tả.
Kiểm thử được định nghĩa bởi nhiều cách khác nhau, như :
-Kiểm thử là quy trình vận hành hệ thống hoặc thành phần dưới những điều kiện
xác định, quan sát hoặc ghi nhận kết quả và đưa ra đánh giá về hệ thống hoặc thành
phần đó [6].
-Kiểm thử dược mô tả là các thủ tục được thực hiện nhằm đánh giá một vài mặt
của phần mềm [4].
-Kiểm thử được mơ tả như là quy trình được sử dụng để phát hiện lỗi phần mềm,
để xác định rằng phần mềm đạt được chất lượng đặt ra [4],
-Kiểm thử là quy trình thực thi chương trình với mục đích tìm thấy lỗi [2].
Tuy có các định nghĩa khác nhau về kiểm thử, nhưng chúng cùng bao trùm hai
nội dung cơ bản là phát hiện lỗi và đánh giá chất lượng của phần mềm. Trong các định
nghĩa trên, thì định nghĩa của Myers “kiểm thử là quy trình thực thi chương trình với
mục đích tìm thấy lỗi” [1] là đơn giản và có tính thực tế cao hơn. Tuy nhiên, trong một
số trường hợp, định nghĩa này lại không thích hợp, bởi vì các kỉ thuật kiểm thử tĩnh có
khả năng phát hiện lỗi cao, nhưng khơng u cầu phải thực thi chương trình, như kĩ
thuật thẩm định, kĩ thuật thanh tra, phân tích tĩnh...
Quan niệm thơng thường cùa lập trình viên là : kiểm thử phát hiện lỗi là không
thành công và ngược lại là thành công. Tuy nhiên, theo định nghĩa của Myers, kiểm
thử mà không phát hiện được lỗi được coi là không thành công, ngược lại nếu kiếm
thử phát hiện được lỗi được coi là thành cơng. 'Thực vậy, mục đích của kiểm thử là
phát hiện lỗi, nếu kiểm thử mà không phát hiện lỗi thi mục đích chưa đạt được. Bởi vi,
trong thực tế phần mềm hầu như không bao giờ không chứa lỗi. Như thế. quan niệm
phát hiện được lỗi là thành công hay thất bại tùy thuộc vào quan điểm của lập trình
viên hay kiểm thử viên.

Chúng ta xem xét trường hợp tương tự: một người đến bệnh viện vì cảm giác
mình bị mắc bệnh. Sau khi bác sĩ khám và thực hiện các xét nghiệm mà khơng phát
hiện được bệnh, thì có thể nói là việc khám và xét nghiệm thất bại, bời vì bệnh khơng
được phát hiện trong khi chi phí phải trả mà người bệnh vẫn cịn ốm. Trong trường
hợp này, người bệnh thậm chí có thể nghi ngờ khá năng của bác sĩ. Ngược lại, nếu
bệnh được phát hiện, thì việc khám và xét nghiệm được coi là thành cơng, sau đó bác
sĩ sẽ tiến hành phương án chữa trị. Một cách tương tự, trong kiếm thử chúng ta cũng
có thể xem phần mềm cần kiểm thử, khi bắt đầu kiểm thử, như là một người bệnh.

Trang 7


Ngoài ra, cũng cần phải phân biệt sự khác nhau giữa hai hoạt động kiểm thử và
gỡ rối (debugging). Kiểm thử nhằm mục đích phát hiện lỗi, trong khi gỡ rối được thực
hiện một khi kiểm thử đã phát hiện được lỗi. Gỡ rối gồm hai bước :
-Xác định bàn chất lỗi và định vị lỗi trong chương trình ;
-Tiến hành sửa lỗi.
Tóm lại, kiểm thử nhằm thực hiện mục đích phát hiện ra lỗi trong phần mềm (với
giả thiết sự tồn tại lỗi trong phần mềm). Kiểm thử phát hiện được lỗi sẽ góp phần nâng
cao chất lượng của phần mềm.
Các khái niệm cơ bản:
Trong mục này, chúng tôi sẽ trình bày một số các khái niệm cơ bản liên quan đến
kiểm thử.
Như đã định nghĩa ở trên, hoạt động kiểm thử nhằm mục đích phát hiện lỗi. Hoạt
động kiểm thử' có thế hoặc tìm các lỗi bằng các phương pháp phân tích tĩnh (khơng
thực thi phần mềm) hoặc phát hiện lỗi bằng cách xác định dữ liệu vào cần cung cấp
cho phần mềm khi thực thi. Các dữ liệu vào này được gọi là các dữ liệu thử (DT - test
data). Chúng ta thường kí hiệu một DT bởi tập hợp. Chẳng hạn, chúng ta kiểm thử
một chương trình tính tổng nhận các biến a, b và c kiểu số nguyên như là dữ liệu vào,
khi đó chúng ta kí hiệu :

DT1 - {a = 3, h = 10, c - 1} có nghĩa là chúng ta khởi gán các giá trị 3, 10
và 1 cho các biến tương ứng a,b và c để tạo ra dữ liệu thử đầu tiên.
Tập hợp các DT được tạo ra để kiểm thử được gọi tập dữ liệu thử (set of test
data). Để có thể đưa tập dữ liệu vào một chương trình, một vài hoạt động hay thao tác
cần phải được thực hiện. Chẳng hạn, để kiểm thử một lựa chọn trên giao diện có đưa
đến việc thực thi một chức năng yêu cầu hay không, cần phải thực thi phần mềm, khởi
gán một vài tệp tin và thực hiện lựa chọn các mục cần thiết để kích hoạt lựa chọn cần
kiểm thử. Dãy các thao tác này được gọi là kịch bản kiểm thử (test scenario)
Khi một kịch bản kiểm thử được thực hiện, phần mềm sẽ cho một kết quả xác
định. Chúng ta giả sử rằng, sự thiếu vắng kết quả bởi một yếu tố không xác định nào
đó (như sự dừng bất thường của chương trình khi thực thi, vòng lặp vĩnh cửu... ) cũng
đều được coi là một kết quà. Kết qủa này sẽ được so sánh với kết qủa mong đợi (được
đặc tả) để kết luận việc kiểm thử. Việc đánh giá kết qủa kiểm thử không nên được
xem nhẹ. Trong thực tế, đôi khi việc đánh giá kết quả kiểm thử cịn khó khăn hơn cả
việc tạo ra dữ liệu thử. Việc đánh giá kết quả kiểm thử có thể được thực hiện mơt cách
tự động bởi công cụ hoặc một cách thủ công bởi con người, chúng ta gọi đó là một

Trang 8


phán xét kiểm thử (test oracle). Chẳng hạn, để xác định xem chương trình tính nghiệm
một phương trình bậc nhất có cho đúng nghiệm hay khơng, chúng ta thay thế nghiệm
(kết quả) vào phương trình đế kiểm tra. Như thế, phán xét kiểm thử là một tài liệu hay
chương trình cho phép kiểm thử viên xác định một phép kiểm thử là thành công hay
thất bại.
Nếu phán xét kiểm thử là một tài liệu, chẳng hạn đặc tả hay thiết kế. thì việc xác
định kết quả của kiểm thử phải thực hiện một cách thủ công, nhờ vào sự quan sát của
con người. Trong thực tế thì phán xét kiểm thử thường chỉ là một tài liệu.
Trường hợp phán xét kiếm thử là một chương trình, thì kết quả kiểm thử có thể
được thực hiện một cách tự động hồn tồn, tức là khơng cần sự can thiệp của con

người. Tuy nhiên, trong thực tế để xây dựng một chương trình phán xét kiểm thử tin
cậy là khơng đơn giản, thậm chí có thể cịn phức tạp hơn việc xây dựng chính chương
trình cần kiểm thử. Xây dựng và sử dụng phán xét kiểm thử là một trong những yếu tố
khó khăn trong quy trình kiểm thử. Thật vậy, một tài liệu phán xét kiểm thử thì xây
dựng dễ dàng bằng cách dựa vào đặc tả và thiết kế, tuy nhiên hiệu quả lại thấp và cản
trở sự tự động hố quy trình kiểm thử vì nó địi hỏi phải có sự can thiệp thủ cơng của
con người. Trong khi chương trình phán xét kiểm thử thì có độ chính xác cao hơn, cho
phép tự động hố quy trình kiểm thử, tuy nhiên xây dựng chương trình phán xét kiểm
thử là rất khó khăn và chi phí cao. Trong tài liệu này chúng ta sẽ không đề cập chi tiết
đến việc xây dựng và sử dụng phán xét kiểm thử.
Trong kiểm thử. chúng ta không thể không đề cập đến vai trị con người, trước
đây cơng việc kiểm thử thường được thực hiện bởi chính các lập trình viên. Tuy
nhiên, gần đây với sự phát triển của công nghiệp phần mềm, kiểm thử là một lĩnh vực
được chun mơn hố. Khi đó. người thực hiện kiểm thử được gọi là kiểm thử viên
(tester) hay kĩ sư kiểm thử (test engineer).
Việc kiếm thử phải được thực hiện bởi các kiểm thử viên độc lập là rất quan
trọng (tuy nhiên, điều này khơng phải ln được tn thủ vì các lí do kinh tế). Lập
trình viên là người làm ra sản phẩm, nếu chính họ cũng là kiểm thử viên thì chắc chắn
việc phát hiện lỗi không đơn giản bởi các yếu tố tâm lí :
-Lập trình viên tạo ra sản phẩm với số lỗi ít nhất có thể, trong khi kiểm thử viên
cố gắng phát hiện số lỗi nhiều nhất có thể ;
-Lập trình viên khơng bao giờ muốn phá huỷ sản phấm đã làm ra, mà luôn mong
muốn kết thúc công việc này để thực hiện các công việc khác ;
-Lập trình viên thường kiểm thử chương trình bằng cách cung cấp các dữ liệu thử

Trang 9


mà cho kết quả như mong đợi.
Chẳng hạn, nếu một người viết một bài văn, sau đó chính người đó đọc và tìm lỗi

thì sẽ khơng tốt bàng một người khác làm việc đó.
Thơng thường, để thực hiện kiểm thử một phần mềm, kiểm thử viên lựa chọn
một tập dữ liệu thử, sau đó cho thực thi phần mềm dưới những điều kiện nào đó
(nghĩa là thực hiện các bước của kịch bản kiểm thử) và cuối cùng quan sát, so sánh kết
quả thu được so với kết quả mong đợi (kết quả được đặc tả). Các thông tin gồm dữ
liệu thử, điều kiện thực thi/các bước thực thi và kết quả mong đợi được gọi là một ca
kiểm thử (test case).
Hình 1.2 sẽ minh hoạ một số các khái niệm vừa trình bày ở trên.
Kết quả mong đợi =6

Đặc tả

Đúng

Chương trình được kiểm thử
Tập dữ liệu thử
DT1={a=1,b=2,c
=3}

DT

Chương trình tính tổng
a+b+c
Kết quả =6

Phán xét kiểm thử

Kiểm tra
Kết quả= a+b+c?

Kết quả
=6
Kiểm thử viên

Đúng

Hình 1.2 Minh họa một số khái niệm về kiểm thử
Để một quy trình kiểm thử - bao gồm chọn dữ liệu thử, kịch bản kiểm thử và
đánh giá kết quả - mang lại độ tin cậy cao, cần phải xây dựng các dữ liệu thử làm sao
đại diện cho được tất cả các dữ liệu vào có thể của phần mềm. Hiển nhiên rằng khi
kiểm thử phần mềm, nếu chúng ta có thể tạo ra tất cả các dữ liệu vào có thể - được gọi
là kiểm thử-Vét—can (exhaustive/complete testing) - thì khi đó bộ dữ liệu thử đại diện
một cách hoàn toàn các dữ liệu vào, độ tin cậy của chúng ta đối với phần mềm đã
được kiểm thử sẽ là tuyệt đối. Tuy nhiên, cần phải hiểu ràng tạo ra tất cả các dữ liệu
vào có thể, thậm chí đối với một chương trình rất đơn giản, là một việc khơng khả thi.
Chúng ta có thế tưởng tượng độ lớn của tập dữ liệu để kiểm thử vét cạn chương trình
tính tổng của ba số ngun. Vì thế, tập dữ liệu thử thơng thường chi là một tập con
của tất cả các dữ liệu vào. Tính đại diện của tập dữ liệu thử đối với tất cả các dữ liệu
vào có thế, có nghĩa là tập dữ liệu phải được chọn lựa sao cho phát hiện được số lỗi
nhiều nhất có thể. Trong trường hợp lí tưởng, bộ dữ liệu thử nhỏ hơn rất nhiều so với

Trang 10


tập tất cả các dữ liệu vào có thế nhưng phát hiện tất cả các lỗi mà tập tất cả các dữ liệu
vào có thế cũng phát hiện được.
Vấn đề đặt ra là làm thế nào để tạo ra tập dử liệu thử có tính đại diện cao ? Thực
tế, thì tính đại diện của tập dữ liệu thử sẽ dẫn đến vấn đề tính đại diện của các lỗi
trong phần mềm. Lưu ý rằng, khi nói đến kiểm thử, chúng ta chỉ quan tâm đến các lỗi
mắc phải bởi người phát triển (phân tích viên, thiết kế viên, lập trình viên), như lỗi

nhầm lẫn, sai sót... chứ khơng phái là các lỗi cấu thả hởi những người phát triển kém
cõi. Từ đó, chúng ta sẽ thấy rằng các kĩ thuật kiểm thử, mà chúng ta sẽ tìm hiểu, tạo
nên những nhóm theo tiêu chuẩn lựa chọn dữ liệu thử và theo đối tượng được kiểm
thử (đặc tà, mã nguồn hay mã thực thi) nhằm đảm bảo một số các loại lỗi được phát
hiện. Chúng ta sẽ xem xét qua các tính chất cơ bản của các nhóm kĩ thuật kiểm thử.
Các kĩ thuật kiểm thử tạo ra các tập dữ liệu thử chi dựa trên kết quả của việc thực
thi phần mềm, mà không quan tâm đến cấu trúc bên trong của phần mềm được gọi các
kĩ thuật kiểm thử chức năng (functional testing). Một thuật ngữ khác được sử dụng
một cách tương đương là kĩ thuật kiểm thử hộp đen (black-box testing), bởi vì chúng
ta xem phần mềm như một hộp đen mà khơng thể nhìn thấy vào bên trong nó được
(nghĩa là mã nguồn).
Ngược lại, các kĩ thuật kiểm thử tạo ra các tập dữ liệu thử bằng cách phân tích
cấu trúc phần mềm được gọi là các kĩ thuật kiểm thử cấu trúc (structural testing), hay
còn được gọi là kĩ thuật kiểm thử hộp trắng (white- box testing). Phần mềm được xem
như một hộp trắng, có thể nhìn xuyên suốt được (thấy cấu trúc bên trong, tức là mã
nguồn hay mơ hình thiết kế).
Các kĩ thuật kiểm thử còn được phân loại dựa theo mã nguồn có được thực thi
khi kiểm thử hay khơng. Các kĩ thuật kiểm thử yêu cầu thực thi mã nguồn của phần
mềm được gọi là các kĩ thuật kiểm thử động (dynamic testing). Ngược lại. các kĩ thuật
kiềm thử chỉ phân tích các dạng lĩnh của phần mềm (đặc tả, mã nguồn) được gọi các
kĩ thuật kiểm thử tĩnh (static testing).
Ngoài ra. các kì thuật kiểm thử trộn lẫn các kỉ thuật kiểm thử chức năng và kiểm
thử cấu trúc được gọi là các kĩ thuật kiểm thử hộp xám (grey- box testing). Các kĩ
thuật kiểm thử hộp xám thường sử dụng các kĩ thuật kiểm thử chức năng trong các
bước đầu. sau đó các phần cịn lại của mã nguồn được kiểm thử bởi các kĩ thuật cấu
trúc.
1.3. Các bước kiểm thử
Để kiểm thử một chương trình, kiểm thử viên phải thực hiện các bước cơ bản

Trang 11

khác nhau. Các bước này được giải thích chi tiết ở dưới đây.
-Lập kế hoạch kiểm thử : Kế hoạch kiểm thử cho phép xác định mục tiêu kiểm
thử, đối tượng kiểm thử. kĩ thuật kiểm thử. nguồn tài nguyên, lịch kiểm thử... Một kế
hoạch kiểm thử tốt sẽ giảm được chi phí, cải thiện được quan hệ với lập trình viên và
nâng cao được chất lượng của kiểm thử.
-Thiết kế ca kiểm thử: Như đã trình bày ở trên, một ca kiểm thử bao gồm dữ liêu
thử, điều kiện thực thi và kết quả mong đợi.
+Thiết kế dữ liệu thử : Tùy theo mục tiêu kiểm thử, kĩ thuật kiểm thử và đối
tượng kiểm thử mà các dữ liệu thử sẽ được thiết kế dựa trên đặc tả yêu cầu, thiết kế
chương trình hay mã nguồn. Thiết kế dữ liệu thử được xem là hoạt động quan trọng
nhất, bởi vi các dữ liệu thử phải có khả năng phát hiện lỗi cao.
+Xát định điều kiện thực thi : Việc xác đinh điều kiện kiểm thử hay các bước
thực thi có thế đơn giản hay phức tạp, tùy theo đối tượng cần được kiểm thử.
+ Xác định kết quả mong đợi : Cần xác định kết quả chúng ta mong đợi khi thực
thi phần mềm với dữ liệu thử được thiết kế.
-Thực thi chương trình : Kiểm thử viên có thể cần phải chuẩn bị môi trường để
thực thi chương trình cần được kiểm thử. Sau đó, kiểm thử viên thực thi chương trình
với các dữ liệu được thiết kế và ghi nhận kết quả thu được.
-Phân tích kết quả kiểm thử và lập báo cáo : Hoạt động cuối cùng là phân tích
kết quả của việc thực hiện ca kiểm thử. Cơng việc chính là so sánh kết q thực thi
chương trinh với kết quả mong đợi. Độ phức tạp của việc so sánh phụ thuộc vào độ
phức tạp của dữ liệu cần được quan sát và phân tích. Sau bước này, phán xét kiểm thử
được gán cho chương trình khi thực hiện ca kiểm thử. Có ba phán xét chính được gán
gồm: thành cơng, thất bại và chưa kết luận.
+ Nếu chương trình tạo ra kết quả khác với kết quả mong đợi thì phán xét thất
bại được gán.
+ Trong một số trường hợp không thể xác định chương trình thành cơng hay thất
bại khi thực hiện ca kiểm thử, nghĩa là cần phải thực hiện thêm các kiểm thử khác để

làm rõ chương trình thành cơng hay thất bại. Khi đó, phán xét chưa kết luận được gán.
Ở bước này, kiểm thử viên cần phải lập báo cáo lỗi cũng như báo cáo kiểm thử.
Báo cáo lỗi (bug report) phải được lập ngay sau khi phân tích mỗi lỗi. Báo cáo lỗi nên
chứa các thông tin về người xác định lỗi. thời gian xác định lỗi, sản phẩm (gồm cả
phiên bản) bị lỗi, mô tả lỗi. cách tái tạo lỗi, độ nghiêm trọng của lỗi. trạng thái lỗi

Trang 12


cũng như các thông tin khác hổ trợ việc sửa lỗi. Báo cáo kiểm thử (test report) tổng
hợp kết quả kiểm thử, nêu rõ những gì đã được kiểm thử, những gì chưa được kiểm
thử, danh sách các lỗi được tìm thấy, lịch và thời gian kiểm thử thực tế.
1.4. Kiểm chứng và hợp thức hóa
Nếu chúng ta muốn bảo đảm rằng một phần mềm được phát triển một cách đúng
đắn và các thành phần cấu tạo nên phần mềm cũng được phát triển một cách đúng
đắn, chúng ta gợi là kiểm chứng (verification). Tuy nhiên, một phần mềm không chỉ
đơn thuần là đáp ứng yêu cầu của nhà sản xuất, mà nó chỉ trở nên hữu ích nếu đáp ứng
được nhu cầu của người sử dụng cuối cùng. Việc báo đảm một phần mềm đáp ứng
nhu cầu của người sử dụng được gọi là hợp thức hoá (validation).
Hợp thức hố một phần mềm phản ánh góc nhìn của người sử dụng, trong khi
kiểm chứng phản ánh góc nhìn của nhà sản xuất. Trong thực tế, một phần mềm đáp
ứng được nhu cầu người sử dụng khơng có nghĩa là nộ được sản xuất một cách đúng
đắn. Ngược lại, phát triển ra một phần mềm tuân thủ tất cả các quy trình sản xuất cũng
khơng bảo đảm rằng phần mềm đó sẽ đáp ứng được nhu cầu của người sử dụng. Vì
vậy, kiểm chứng và hợp thức hố, được kí hiệu là v&v (Verification & Validation),
cùng hồ trợ cho nhau nhằm tạo ra sản phấm phần mềm có chất lượng tốt.
Chúng ta có thể phân biệt hai khái niệm này như sau : kiểm chứng nhằm trả lời
câu hỏi ''Chúng ta đã xây dựng tốt một phần mềm chưa trong khi hợp thức hoá nhằm
trả lời câu hỏi ''Chúng ta đã xây dựng một phần mềm tốt chưa
Hiển nhiên rằng mỗi chiến lược kiểm thử có thể sử dụng các kĩ thuật kiểm thử

khác nhau. Để hợp thức hoá, các kĩ thuật kiểm thử chức năng thường được sử dụng,
bởi vì các chức năng là mối quan tâm hàng đầu đối với người sử dụng. Dể kiểm
chứng, các kĩ thuật kiểm thử chức năng cũng như kiểm thử cấu trúc đều có thể được
sử dụng.
1.5. Khái niệm hoạt động kiểm thử
Một hoạt động kiểm thử (test activity) hay mức kiểm thử (test level) là một kế
hoạch nhằm định nghĩa mục tiêu của các giai đoạn kiểm thử cũng như các kĩ thuật
kiểm thử được sử dụng. Hoạt động kiểm thử thường được quyết định dựa vào :
-Tiêu chuẩn vầ độ tin cậy của phần mềm;
-Chi phí cho việc phát triển phần mềm
Trong bất kì quy trình phát triển phần mềm nào, chúng ta đều có thể nhận thấy
các đơn vị độc lập nhỏ được viết bởi các lập trình viên, sau đó chúng được phát triển

Trang 13


và tích hợp dần dần cho đến khi đạt được sản phẩm cuối cùng theo yêu cầu của khách
hàng. Một chiến lược kiểm thử sẽ phụ thuộc kích thước của đối tượng được kiểm thử
cũng như quan điểm của chúng ta về đối tượng được kiểm thử.
Nếu chúng ta muốn kiểm thử một cách độc lập các thành phần (đơn vị) cấu tạo
nên phần mềm, chúng ta gọi là kiểm thử đơn vị (unit testing). Kiểm thử đơn vị chỉ
quan tâm từng đơn vị phần mềm, như hàm, thủ tục hay lớp. Kiểm thử đơn vị được
thực hiện bởi các lập trình viên. Các kĩ thuật kiểm thử chức năng và kiểm thử cấu trúc
đều có thể được sử dụng cho kiểm thử đơn vị.
Nếu chúng ta muốn kiểm thử sự kết hợp các thành phần cấu tạo nên phần mềm,
chúng ta gọi là kiểm thử tích hợp (integration tesing). Kiểm thử tích hợp hướng đến
phát hiện lỗi giao tiếp giữa các thành phần. Kiểm thử tích hợp thường được thực hiện
bởi các lập trình viên và/hoặc các kiểm thử viên. Thông thường, chỉ các kĩ thuật kiểm
thử chức năng được sử dụng cho kiểm thử tích hợp. Trong các trường hợp cần thiết,
các kĩ thuật kiểm thử cấu trúc cũng có thể được sử dụng, tuy nhiên chi phí kiểm thử sẽ

cao.
Một khi đã kết thúc kiểm thử tích hợp, chúng ta kiểm thử toàn bộ phần : mềm,
chúng ta gọi là kiểm thử hệ thống (System testing). Kiểm thử hệ thống thường là giai
đoạn cuối trong các quy trình phát triển, nhằm đảm bảo hầu hết các lỗi đã được phát
hiện và sửa chữa, phần mềm đáp ứng được yêu cầu đặt ra, có thể chuyền giao để sử
dụng. Kiểm thử hệ thống có thể bao gồm nhiều loại kiểm thử khác nhau, như kiểm thử
chức năng, kiểm thử bảo mật, kiểm thử cấu hình, kiểm thử khả năng chịu tải, kiểm thử
hiệu năng, kiểm thử độ tin cậy, kiểm thử tài liệu... Kiểm thử hệ thống được thực hiện
bởi các kiểm thử viên.
Sau khi hoàn tất kiểm thử hệ thống, phần mềm được chuyển giao cho người sử
dụng. Người sử dụng sẽ thực hiện các kiểm thử phần mềm, được gọi là kiểm thử chấp
nhận (acceptance testing). Mục tiêu của kiểm thử chấp nhận là đánh giá chất lượng
của phần mềm, thay vì tìm lỗi (là mục tiêu của kiểm thử đơn vị, kiểm thử tích hợp và
kiểm thử hệ thống). Khi kiểm thử chấp nhận, người sử dụng có thể định nghĩa các tiêu
chí chấp nhận dựa trên mong đợi của họ về phần mềm Như thế, một phần mềm
thường trải qua bốn giai đoạn kiểm thử trước khi được triển khai để sử dụng. Ba giai
đoạn kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống được thực hiện bởi
người phát triển phần mềm, trong khi kiểm thử chấp nhận được thực hiện bởi khách
hàng. Ngoài ra, một khi kiểm thử phát hiện lỗi, việc sửa lỗi sau đó thường dẫn đến sự
xuất hiện của các lỗi khác. Vì vậy, cần phải thực hiện các kiểm thử khác đế bảo đảm
rằng các lỗi mới khơng xuất hiện, chúng ta gọi đó là kiểm thử hồi quy (regression

Trang 14


testing). Kiểm thử hồi quy có thể được thực hiện trong suốt quy trình phát triển. Kiểm
thử hồi quy được thực hiện khi một thành phần của hệ thống bị thay đổi. Mục tiêu
chính của kiểm thử hồi quy nhằm đảm bảo sự thay đổi không tạo ra các lỗi mới trong
các thành phần không bị chỉnh sửa. Kiểm thử hồi quy không được xem là một hoạt
động kiểm thử khác. Đúng hơn, kiểm thử hồi quy là một giai đoạn con của kiểm thử

đơn vị, kiểm thử tích hợp và kiểm thử hệ thống, như được minh hoạ trong
Kiểm thử hồi quy

Kiểm thử
đơn vị

Kiểm thử
tích hợp

Kiểm thử hệ
thống

Kiểm thử
chấp nhận

Hình 1.3. Kiểm thử hồi quy ở các hoạt động kiểm thử khác nhau
1.6. Các nguyên tắc kiểm thử
Các nguyên tắc ln đóng vai trị quan trọng trong lĩnh vực công nghệ phần
mềm. Các nguyên tắc trong công nghệ phần mềm là các luật hay quy tắc hướng dẫn
làm thế nào để xây dựng (thiết kế, phát triển, kiểm thử và bảo trì) phần mềm. Kiểm
thử là một trong những lĩnh vực của công nghệ phần mềm, kiểm thử cũng có các
nguyên tắc riêng dành cho các kiểm thử viên. Các nguyên tắc này giúp cho kiểm thử
viên xác định cách kiểm thử một phần mềm cũng như thực hiện công việc kiểm thử
một cách chuyên nghiệp. Chúng ta sẽ xem xét một sổ nguyên tắc cơ bản [4] liên quan
đến kiểm thử động, nghĩa là kiểm thử yêu cầu thực thi phần mềm.
Nguyên tắc 1 : Kiểm thử là quy trình thực thi phần mềm và sử dụng các ca kiểm
thử để phát hiện lỗi.
Mặc dù công nghệ phần mềm đã có rất nhiều cài tiến trong các phương pháp
phát triển để hạn chế và loại bỏ lỗi. Tuy nhiên, lỗi vẫn ln xuất hiện và có các ảnh
hưởng xấu đến chất lượng phần mềm. Kiểm thử viên cần phải xác định các lỗi này

trước khi phần mềm được sử dụng.
Định nghĩa kiểm thử phần mềm được hiểu như là một nguyên tắc mà kiểm thử
viên phải luôn luôn tuân theo. Không nên lên một kế hoạch kiểm thử nhằm chứng
minh rằng lỗi không tồn tại.
Nguyên tắc 2 : Với mục đích của kiểm thử nhằm phát hiện lỗi. một ca kiểm thử
tốt là ca kiểm thử có khả năng cao phát hiện những lỗi chưa được tìm thấy.
Nguyên tắc này cung cấp cách để đánh giá sự hiệu quả một ca kiểm thử. Khi
thiết kế, kiểm thử viên phải xác định mục tiêu rõ ràng của mỗi ca kiểm thử, tức là
Trang 15


nhằm phát hiện các loại lỗi gì. Sau đó, kiểm thử viên thực hiện chọn lựa bộ dữ liệu
thử, kịch bản kiểm thử và thực thi phần mềm để kiểm thử. Kết quả kiểm thử sẽ giúp
cho kiểm thử viên khẳng định mục tiêu của ca kiểm thử.
Nguyên tắc 3: Một ca kiểm thử phải định nghĩa kết quả mong đợi
Đối với kiểm thử viên, điều hiển nhiên là một ca kiểm thử phải chứa dữ liệu thử.
Tuy nhiên, một ca kiểm thử sẽ khơng có giá trị nếu chúng ta bỏ quên kết quả mong
đợi tương ứng với dữ liệu thử. Trong trường hợp này vấn đề sẽ trở nên tồi tệ hơn, khi
mà một kết quả sai được cho là kết quả đúng bởi vì tâm lí của người phát triển mong
muốn nhận được kết quả tốt. Định nghĩa kết quả mong đợi sẽ cho phép kiểm thử viên
xác định có hay khơng có lỗi và việc kiểm thử thành công hay thất bại. Việc đặc tả các
dữ liệu thử và kết qủa tương ứng là phải được thực hiện trong quá trình thiết kế các ca
kiểm thử.
Nguyên tắc 4 : Kiểm thử nên được thực hiện bởi một nhóm độc lập với nhóm
phát triển.
Trước hết về mặt tâm lí, rất khó để các lập trình viên chấp nhận rằng phần mềm
do mình làm ra bị lỗi. 'Thật vậy, một khi các lập trình viên xây dựng nên phần mềm,
thật là khó để họ chuyển từ góc nhìn xây dựng sang góc nhìn phá huỷ trong khi kiểm
thử. Nếu các lập trình viên thực hiện kiểm thử phần mềm do chính họ làm ra thì sẽ
khơng mang lại hiệu quả vì họ khơng mong muốn phát hiện lỗi của chính họ. Hơn

nữa, một lập trình viên có thể ln tránh tìm ra lỗi, bởi vì họ ngại sự đánh giá thấp từ
đồng nghiệp hay cấp trên. Ngồi lí do về mặt tâm lí, một vấn đề khác rất thực tế là :
chương trình có thể chứa lỗi do sự hiểu khơng chính xác về đặc tả hay mơ tả bài tốn
của lập trình viên. Trong trường hợp này. dường như rằng lập trình viên sẽ mang ln
cả sự hiểu khơng chính xác đó vào trong kiểm thử chương trình. Như vậy, lỗi sẽ rất
khó được phát hiện. Tuy nhiên, ngun tắc nàv khơng có nghĩa là những lập trình viên
khơng thể kiểm thử chưong trình của chính họ, mà đúng hơn là kiểm thử sẽ hiệu qủa
hơn khi được thực hiện bởi những người khác.
Nguyên tắc 5: Kết quả kiểm thử nên được phân tích một cách cẩn thận
Đây là nguyên tắc rất cơ bản, nhưng thường không được đánh giá đúng dẫn đến
không phát hiện được lỗi hoặc làm xuất hiện các lỗi khác. Chẳng hạn :
-Một lỗi bị bỏ qua hoặc coi nhẹ, khi đó việc kiểm thử sẽ được coi là không phát
hiện được lỗi. tuy nhiên thực tế thì lỗi tồn tại. Kiểm thử sẽ được tiếp tục dựa trên kết
quả khơng chính xác trước đó. có thể trong các bước kiểm thử sau lỗi sẽ được phát
hiện. Trong trường hợp đó việc định vị lỗi và sửa lỗi sẽ trở nên khó khăn hơn.

Trang 16


- Một lỗi có thể bị nghi ngờ là tồn tại, tuy nhiên thực tế thì lỗi khơng tồn tại.
Trong trường hợp đó. chúng ta sẽ có thể mất nhiều thời gian và cơng sức để tìm và xác
định lỗi. Trong khi đó, một sự phân tích tỉ mỉ kết quả kiểm thử sẽ chỉ ra rằng lỗi
không tồn tại.
Nguyên tắc 6 : Các ca kiểm thử nên được thiết kế cho cả những dữ liệu vào
hợp lệ và không hợp lệ.
Kiểm thử một phần mềm thường chỉ chú ý đến các tập dữ liệu vào hợp lệ, tức là
các tập dữ liệu vào đúng như đặc tả. Trong thực tế, dữ liệu vào có thể khơng hợp lệ
bởi nhiều lí do khác nhau. Chẳng hạn, người sử dụng hiểu khơng chính xác hoặc thiếu
thơng tin về dữ liệu vào. Thậm chí khi có được thơng tin đầy đù, người sử dụng cũng
gõ sai dữ liệu vào. Các thiết bị cung cấp dữ liệu vào sai do các tác động hay điều kiện

bất thường.
Sử dụng các ca kiểm thử với các dữ liệu khơng hợp lệ sẽ kích hoạt phần mềm
một cách khơng mong đợi và như thế có thể sẽ xác định được các hành vi bất thường
của phần mềm. Hơn nữa, các dữ liệu khơng hợp lệ cịn cho phép đánh giá được khả
năng bền vững của phần mềm, nghĩa là hoạt động của phần mềm khi có sự kiện khơng
mong đợi xuất hiện.
Ngồi ra, các ca kiểm thử với các dữ liệu vào không hợp lệ thường có khả năng
phát hiện lỗi tốt hơn các ca kiểm thử với các dữ liệu vào hợp lệ.
Nguyên tắc 7: Các ca kiểm thử phải được tái sử dụng.
Các ca kiểm thử nên được lưu giữ sau mỗi kiểm thử. Vì sau khi kiểm thử, phần
mềm chứa lỗi, cần thực hiện sửa lỗi. Phần mềm sau đó sẽ được kiểm thử lại hay kiểm
thử hồi quy. Nếu không lưu giữ lại các ca kiểm thử thì cần phải xây dựng lại. Việc xây
dựng lại các ca kiểm thử luôn yêu cầu nhiều thời gian, nên đôi khi kiểm thử lại bị bỏ
qn. Vì thế, kiểm thử lại thường ít khi được thực hiện nghiêm túc như kiểm thử lần
đầu.
Nguyên tắc 8 : Xác suất tồn tại của các lỗi khác nữa trong một đơn vị phần
mềm tỉ lệ với số các lỗi đã được phát hiện trong đơn vị phần mềm đó.
Khái niệm đơn vị phần mềm ở đây được hiểu là một thành phần cấu tạo nên
phần mềm, có thể là một hàm, thủ tục, phương thức, lớp hay thậm chí lá một phần
mềm. Ngun tắc này nói rằng nếu một đơn vị phần mềm với một số lượng lớn các lỗi
đã được phát hiện, thì khi tiếp tục thực hiện kiểm thử khả năng xác định được nhiều
lỗi hơn nữa là rất cao. Chẳng hạn, giả sử có hai đơn vị phần mềm A và B, khi kiểm
thử phát hiện đơn vị A chứa 20 lỗi trong khi B chỉ chứa 4 lỗi, như thế khả năng tồn tại

Trang 17


lỗi khác nữa trong A cao hơn trong B.
Nguyên tắc này được dựa trên việc quan sát từ thực tế khi kiểm thử phân mềm.
Các lỗi thường xuất hiện trong các đơn vị phần mềm có độ phức cao và được thiết kế

khơng tốt. Khi đó, cần phải tiếp tục thực hiện kiểm thử nhiều hơn nữa đối với các đơn
vị phần mềm có xu hướng lỗi này.
Nguyên tắc 9: Kiểm thử nên được lập kế hoạch.
Kế hoạch kiểm thử nên được mô tả chi tiết từ mỗi giai đoạn kiểm thử. Kế hoạch
kiểm thử với các mục tiêu xác định nhằm đảm bảo phân phối hợp lí về mặt thời gian
cũng như tài nguyên kiểm thử và bảo đảm kiểm thử được giám sát và quản lí. Kế
hoạch kiểm thử cần phải được xây dựng kết hợp với kế hoạch dự án. Thật vậy, kiểm
thử viên không thể thực thi các ca kiểm thử cho một đơn vị phần mềm khi mà nó chưa
được hồn thành bởi lập trình viên.
Nguyên tắc 10 : Các hoạt động kiểm thử nên phải được tích hợp vào quy trình
phát triển phần mềm.
Hoạt động kiểm thử không chỉ được thực hiện sau khi đã có mã nguồn mà cần
phải được thực hiện sớm hơn trong các giai đoạn phát triển, như giai đoạn phân tích,
đặc tả và thiết kế. Các hoạt động kiểm thử được thực hiện xuyên suốt trong quá trinh
phát triển cho đến khi sản phẩm được chuyển giao cho người sử dụng. Bởi vì, việc
phát hiện lỗi càng sớm trong các giai đoạn phát triển thì việc sửa lỗi sẽ càng đơn giản
và ít chi phí.
Nguyên tắc 11: Kiểm thử là một công việc đầy sáng tạo và thách thức.
Đối với các phần mềm phức tạp, yêu cầu sáng tạo trong kiểm thử thậm chỉ còn
vượt cả yêu cầu sáng tạo trong thiết kế. Để hồn thành tốt cơng việc kiểm thử, các
kiểm thử viên cần phải :
- Có kiến thức rộng về lĩnh vực công nghệ phần mềm, đặc biệt là về đặc tả, thiết
kế và phát triển phần mềm
-Hiểu biết các loại lỗi, và các loại lỗi thường xuất hiện ở những cấu trúc lệnh nào
hay ở các đơn vị phần mềm nào;
-Biết lập luận đưa ra những giả thiết liên quan đến sự hiện diện lỗi trong chương
trình ;
-Nắm bắt được mơi trường ứng dụng của phần mềm cần kiểm thử ;
-Lên kế hoạch phân phối tài nguyên kiểm thử hợp lí;

Trang 18


-Nắm bắt và áp dụng các công cụ kiểm thử ;
-Iàm việc và hợp tác không chỉ các thành viên nhóm kiểm thử mà cịn với các
thành viên của nhóm phát triển, cũng như với khách hàng và người sử dụng.
1.7. Các khó khăn của kiểm thử
Theo các nghiên cứu thống kê đã khẳng định, giai đoạn kiểm thử là giai đoạn địi
hỏi nhiều chi phí nguồn tài ngun (theo [3], khoảng 40% tổng chi phí của một dự án
phần mềm). Chúng ta có thể kết luận rằng giảm chi phí các hoạt động kiểm thử sẽ
giảm được tổng chi phí của dự án phần mềm. Trong một số dự án phần mềm, vì lí do
kinh tế các hoạt động kiểm thử được giảm bớt. Hậu qủa nhận được, về mặt kinh tế, chi
phí cho giai đoạn bảo trì sẽ tăng lên rất lớn. Vì vậy, giải pháp là khơng nên giảm các
hoạt động kiểm thử mà quan trọng là kiểm thử một cách tốt hơn, nghĩa là cần phải
chọn chiến lược và kĩ thuật kiểm thử phù hợp để phát hiện ra số lượng lỗi thực tế lớn
nhất có thể. Lỗi thực tế từ đây được hiểu là các lỗi thường sinh ra trong quá trình phát
triển. Bởi vì một kĩ thuật kiểm thử khơng thực sự có ích khi nó chi phát hiện ra những
lỗi ít khi gặp phải hoặc rất ít nghiêm trọng.
Để kiểm thử tốt hơn, cần phải quan tâm đến các yếu tố làm cho việc kiểm thử
khó khăn. Các yếu tố này có thể được chia làm các nhóm sau [3] :
-Khó khăn liên quan đến quy trình phát triển phần mềm,
-Khó khăn về mặt con người,
-Khó khăn về mặt kĩ thuật.
1.7.1 Khó khăn liên quan đến quy trình phát triển phần mềm
Quy trình phát triển phần mềm là một tập hợp các hoạt động từ giai đoạn tìm
hiểu, khảo sát, phân tích, thiết kế và cài đặt cho đến giai đoạn sử dụng và bão trì. Mỗi
giai đoạn này thực ra là một sự chuyển đổi một tập hợp thông tin này sang một tập
hợp thơng tin khác, trong đó, tập hợp thơng tin đầu tiên là mơ hình thế giới thực cần
tin học hố và tập hợp thơng tin cuối cùng chính là phần mềm thực thi được. Quá trình
chuyển đổi này sẽ dẫn đến sự mất mát thơng tin khó tránh khỏi, nghĩa là các lỗi sẽ

xuất hiện. Khó khăn đầu tiên của kiểm thử liên quan đến tính chất trừu tượng của đối
tượng trong quá trình chuyển đổi. Hơn nữa, các giai đoạn chuyển đổi có thể tạo nên
một thất bại tới giai đoạn cuối cùng mà khi phát hiện lập trình viên khó có thể biết
được ngun nhân do giai đoạn nào trước đó.
1.7.2 Khó khăn về mặt con người
Trước hết. kiếm thử là một hoạt động mà mục đích của nó đơi khi được nhìn

Trang 19