Bài giảng Kiểm thử phần mềm - ĐH Phạm Văn Đồng

Chia sẻ: Cuahapbia | Ngày: | Loại File: PDF | Số trang:126

Thêm vào BST

Báo xấu

33
lượt xem 6
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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 gồm có 5 chương, cung cấp cho người học những kiến thức như: Giới thiệu về kiểm thử; Kiểm thử trong quy trình phát triển phần mềm; Kiểm thử chức năng-Kiểm thử cấu trúc; Thiết kế các trường hợp kiểm thử;...Mời các bạn cùng tham khảo!

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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 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