Xem mẫu
- 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 toá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 hoá đơn, quản lý và
thanh toá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 chuyên 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 hoàn toà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 chuyên
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 toá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 toá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 luôn đượ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, ngoài 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ố, còn có các phép toá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à quá 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.
Ngoà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 quá 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 quá 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 Xảy ra
Sai sót 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 quá 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 toán : lỗi ở các biểu thức tính toá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 yê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 hoàn toà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 hoá 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 hoá 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 chuyên môn hoá. 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 luôn được tuân 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ả
Chương trình được kiểm thử Đúng
Tập dữ liệu thử DT Chương trình tính tổng
DT1={a=1,b=2,c a+b+c
=3} Kết quả
DT2={ Kết quả =6 =6
Kiểm thử viên
Phán xét kiểm thử
Kiểm tra Đúng
Kết quả= a+b+c?
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ố nguyên. 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 quà 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 hoá 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 hoá, đượ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
nguon tai.lieu . vn
