i
LỜI CAM ĐOAN
Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi, số liệu và kết
quả nghiên cứu trong luận văn này là trung thực và không trùng lặp với các đề tài
khác. Tôi cũng xin cam đoan rằng mọi sự giúp đỡ cho việc thực hiện luận văn này
đã được cảm ơn và các thông tin trích dẫn trong luận văn đã được chỉ rõ nguồn gốc.
Học viên

Nguyễn Thị Tính


ii
MỤC LỤC
LỜI CAM ĐOAN .....................................................................................................i
MỤC LỤC ..............................................................................................................ii
MỤC LỤC HÌNH ẢNH ......................................................................................... iv
DANH MỤC BẢNG BIỂU ..................................................................................... v
ĐẶT VẤN ĐỀ........................................................................................................ vi
I.TÍNH CẤP THIẾT CỦA ĐỀ TÀI ..................................................................... vi
II.MỤC TIÊU CỦA ĐỀ TÀI LUẬN VĂN .........................................................vii
III.ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU ...............................................vii
IV.PHƯƠNG PHÁP NGHIÊN CỨU .................................................................vii
V.KẾT QUẢ DỰ KIẾN ĐẠT ĐƯỢC ................................................................vii
VI.CẤU TRÚC LUẬN VĂN ............................................................................viii
CHƯƠNG 1 QUI TRÌNH VÀ CHẤT LƯỢNG PHẦN MỀM ................................. 1
1.1 SẢN PHẨM VÀ CHẤT LƯỢNG PHẦN MỀM............................................. 1
1.1.1 Khái niệm về sản phẩm phần mềm ........................................................... 1
1.1.2 Khái niệm lỗi phần mềm .......................................................................... 3
1.1.3 Chi phí sửa lỗi .......................................................................................... 5
1.1.4 Khái niệm kiểm thử phần mềm................................................................. 6
1.1.5 Những khó khăn của kiểm thử phần mềm ................................................ 7

3.2.1 Phát biểu bài toán ...................................................................................... 52
3.2.2 Phạm vi giải quyết.................................................................................. 52
3.2.3 Thiết kế trường hợp kiểm thử. ................................................................ 52
3.2.4 Kết quả kiểm thử .................................................................................... 60
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN.............................................................. 61
TÀI LIỆU THAM KHẢO ..................................................................................... 62


iv
MỤC LỤC HÌNH ẢNH
Hình 1. 1 - Sản phẩm phần mềm. Nguồn: [13] ......................................................... 3
Hình 1. 2 – Các nguyên nhân gây ra lỗi phần mềm [5] ............................................ 4
Hình 1. 3 - Chi phí cho việc sửa lỗi. Nguồn: [6], [8] ................................................ 6
Hình 1. 4 - Quy trình kiểm thử............................................................................... 13
Hình 1. 5 -Quy trình chi tiết quá trình kiểm thử ..................................................... 14
Hình 2. 1 - Mô hình luồng thông tin kiểm thử........................................................ 19
Hình 2. 2 - Ví dụ đồ thị nhân quả........................................................................... 32
Hình 2. 3 – Quy trình tạo ca kiểm thử dựa trên đồ thị luồng điều khiển ................. 34
Hình 2. 4 – Đồ thị luồng điều khiển biểu diễn chương trình sum ........................... 35
Hình 2. 5 - Ví dụ tiêu chí bao phủ cung ................................................................. 35
Hình 2. 6 - Đồ thị biểu diễn chương trình tính tổng nghịch đảo ............................. 37
Hình 2. 7 - Đồ thị luồng điều khiển biểu diễn hàm abc .......................................... 39
Hình 2. 8 - Đồ thị luồng điều khiển biểu diễn hàm foo .......................................... 42
Hình 3. 1 - Giao diện kiểm thử bài toán NC........................................................... 51
Hình 3. 2 - Minh họa thuật toán sắp xếp MergeSort ............................................... 53
Hình 3. 3 - Đồ thị lưu trình cho hàm Merge ........................................................... 54
Hình 3. 4 - Kết quả được ghi ra file log ................................................................. 60
Hình 3. 5 - Giao diện điều khiển kiểm thử các thuật toán sắp xếp .......................... 60



nhiệm vụ kiểm tra và xác minh các tiêu chí phần mềm: tính đúng, tính khoa học,
tính tin cậy, tính vững vàng, tính dễ chuyển mang, tính dễ sử dụng, dễ phát triển và
hoàn thiện. Đây là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần
mềm nhằm đảm bảo phần mềm đáp ứng các yêu cầu thiết kế và nhu cầu của người
dùng. Các kỹ thuật đánh giá chất lượng phần mềm đã và đang được nghiên cứu cả
về chiều rộng lẫn chiều sâu, và việc đánh giá này đã trở thành quy trình bắt buộc
trong các dự án phát triển phần mềm [1]. Trong qui trình này, kiểm thử phần mềm
là giai đoạn quan trọng nhằm đảm bảo chất lượng phần mềm, là quá trình chạy thử
một ứng dụng để phát hiện lỗi và xem nó đã thỏa mãn yêu cầu đặt ra trong giai đoạn
phát triển phần mềm [3]. Một sản phẩm phần mềm được phân phối phải có đầy đủ
các chức năng yêu cầu và tương thích với phần cứng của khách hàng [4], [2].
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 [5]. Đánh giá chất lượng
phần mềm ngày càng khó khăn hơn, bởi vì các ngôn ngữ lập trình, các hệ điều hành
và các phương pháp, công cụ phát triển phần mềm cũng như các thiết bị phần cứng


vii
ngày càng phong phú và đa dạng.Vì vậy, học viên chọn đề tài “Các phương pháp
đánh giá chất lượng phần mềm” làm hướng nghiên cứu cho luận văn.
II. MỤC TIÊU CỦA ĐỀ TÀI LUẬN VĂN
Mục đích chính của luận văn là:
 Nghiên cứu, tìm hiểu về nguyên lý, phương pháp và các kỹ thuật quản lý
và đánh giá chất lượng phần mềm.
 Thiết kế các trường hợp kiểm thử và xây dựng vài kịch bản kiểm thử cụ
thể.
III. ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU
 Luận tập trung tìm hiểu, phân tích và khảo sát các đổi tượng sau đây:
 Quy trình và bản chất của các kỹ thuật đánh giá chất lượng phần mềm.

 Kiểm thử hộp đen: xây dựng lớp phân hoạch tương đương, phân tích giá
trị biên, kỹ thuật đồ thị nhân quả, kiểm thử giá trị đặc biệt.
 Kiểm thử hộp trắng: kiểm thử dựa trên đồ thị luồng điều khiển, kiểm thử
dựa trên luồng dữ liệu, kiểm thử điều kiện.
Trên cơ sở các nội dung nói trên, luận văn phân tích, làm nổi bật những yếu
tố quan trọng trong đảm bảo chất lượng phần mềm.
Chương 3: Một số ứng dụng cụ thể của quy trình kiểm thử.
Để minh hoạ cho phần lý thuyết ở trên, chương 3 sẽ trình bày một vài kịch
bản kiểm thử áp dụng kỹ thuật hộp đen và kỹ thuật hộp trắng để kiểm thử.
Xây dựng các trường hợp kiểm thử (test cases) cho từng kịch bản kiểm thử.
Xây dựng chương trình và giao diện: thực hiện với các trường hợp kiểm thử
đã đề xuất, đối sánh kết quả của chương trình và kết quả dự kiến của các trường hợp
kiểm thử.
Kết luận và hướng phát triển
Tài liệu tham khảo


1

CHƯƠNG 1
QUI TRÌNH VÀ CHẤT LƯỢNG PHẦN MỀM
1.1 SẢN PHẨM VÀ CHẤT LƯỢNG PHẦN MỀM
1.1.1 Khái niệm về sản phẩm phần mềm
Phần mềm là một (bộ) chương trình đươc cài đặt trên máy tính thực hiện một
nhiệm vụ tương đối độc lập nhằm phục vụ cho một hoặc nhiều ứng dụng cụ thể:
quản lý hoạt động của máy tính hoặc áp dụng máy tính trong các hoạt động kinh tế,
quốc phòng, văn hóa, giáo dục, giải trí…[4], [5]
Ví dụ:
S1. Hệ điều hành Ubutu;
S2. Môi trường lập trình C++ Devcpp;


Kiểm

và kiểm

kiểm thử

thử hệ

thử đơn vị

tích hợp

thống

Thập kỉ 19601970

10%

Thập kỉ 1980

20%

Thập kỉ 1990

40%

80%
60%
30%

muốn thì ta nói
rằng phần mềm đó có lỗi.
i. Tuy nhiên, cũng có thể dùng nhiều thuậtt ngữ
ng khác để mô
tả hiện tượng này như: thất
th bại, sai sót, có vấn đề, bất thường
ng không hhợp lý, không
tương thích,…
Định nghĩa lỗii phần
ph mềm dưới đây dựa trên khái niệm đặcc ttả: một đặc tảlà
một sự thống nhất về đặặc tính, quan hệ, chức năng và hành vi củaa sản
s phẩm giữa
những người phát triển
n ph
phần mềm hoặc giữa người phát triển phần
nm
mềm và người
đặt hàng hoặc sử dụng
ng phần
ph mềmthông qua một ngôn ngữ nào đó [5], [8], [10].
Lỗi phần mềm xuấất hiện khi xảy ra một hay nhiều điều kiện
n sau [13]
[13], [14], [15]:
 Phần
ần mềm không thực hiện đúng những g
gì mà đặc
ặc tả định nghĩa.
 Phần
ần mềm thực hiện những gì
g mà đặc

trở nên nhẹ nhàng hơn, mặc dù độ phức tạp phần mềm lớn hơn rất nhiều. Do đó, lỗi
do lập trình gây ra cũng ít hơn. Tuy nhiên, nguyên nhân để lập trình tạo ra lỗi lại


5

nhiều hơn. Đó là do độ phức tạp của phần mềm, do tài liệu nghèo nàn, do sức ép
thời gian hoặc chỉ đơn giản là những lỗi “không nói lên được” [11]. Một điều cũng
khá hiển nhiên là nhiều lỗi xuất hiện trên văn bản chương trình, nhưng khi tìm hiểu
kỹ thì thực ra lại do lỗi của đặc tả hoặc thiết kế [10].
Một nguyên nhân khác tạo ra lỗi là do bản thân của công cụ phát triển phần
mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch, các mẫu thường
được thiết kế theo xu hướng tổng quát hóa quá cao …
1.1.3 Chi phí sửa lỗi
Người ta ước tính, bảo trì là phần chi phí chính của phần mềm và kiểm thử là
hoạt động có chi phí đắt thứ hai, ước tính khoảng 40% của chi phí trong quá trình
phát triển ban đầu của sản phẩm phần mềm. Kiểm thử cũng là phần chi phí chính
của giai đoạn bảo trì do phải tiến hành kiểm thử lại những thay đổi trong quá trình
sửa lỗi và đáp ứng yêu cầu của người dùng [1], [6]
Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng
đời phần mềm. Tuy nhiên, chi phí cho việc tìm và sửa lỗi sẽ tăng đáng kể theo thời
gian trong quá trình phát triển [8].
Sự thay đổi một tài liệu hoặc yêu cầu (thí dụ, của khách hàng) khi đang
trong pha thiết kế là không đắt nếu không nói là không đáng kể. Chi phí sẽ tăng lên
nhiều hơn nếu các yêu cầu thay đổi được đưa ra sau khi đã lập trình. Thay đổi lúc
này đồng nghĩa với việc phải viết lại chương trình [9].
Việc sửa lỗi sẽ không đáng kể nếu người lập trình tự phát hiện lỗi của mình,
và không có sự liên quan đến chi phí khác. Họ không phải giải thích lỗi cho bất kỳ
người nào trong nhóm. Họ cũng không phải nhập lại lỗi đó vào cơ sở dữ liệu lỗi và
lưu vết lỗi. Người kiểm thử và người quản lý không phải duyệt lại tình trạng lỗi. Và


lượng sản phẩm. Một sản phẩm phần mềm được phân phối phải có đầy đủ các chức
năng yêu cầu và tương thích với phần cứng của khách hàng.
1.1.5 Những khó khăn của kiểm thử phần mềm
Để 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 hơn.
 Khó khăn liên quan đến quy trình phát triển phần mềm
Quá 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 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. 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. Hơn nữa, các giai đoạn chuyển đổi có thể tạo nên
một thất bạ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 nguyên nhân do giai đoạn nào trước đó [10].
 Khó khăn về nhân sự
Thông thường, kiểm thử thường chỉ được coi là giai đoạn đơn giản cuối cùng
được dùng để hợp thức hóa sản phẩm. Vì thế, nhiều lỗi nghiêm trọng mắc phải ngay
từ các giai đoạn đầu của quy trình phát triển (đặc tả và thiết kế). Trong khi đó, nhiều
thống kê cho thấy: các lỗi mắc phải càng sớm trong quy trình phát triển, thì các lỗi
đó càng khó phát hiện và khó khắc phục. Vì vậy, việc nghiên cứu các phương pháp
và công cụ phát triển thích ứng sẽ góp phần rất lớn vào việc giảm bớt các lỗi ngay
từ các giai đoạn đầu của quy trình phát triển [9].
1.1.6 Kiểm thử trong quy trình phát triển phần mềm
Để kiểm thử một sản phẩm phần mềm, chúng ta không chỉ kiểm thử một lần,
khi mà nó đã được hoàn thành. Các thành phần của phần mềm đều phải được kiểm
thử trước, sau đó trong suốt quá trình tích hợp các thành phần cũng phải được kiểm
thử cho đến khi đạt được sản phẩm cuối cùng.
Có nhiều quy trình phát triển phần mềm được sử dụng. Chúng khác nhau về
bản chất, cách tiến hành, số giai đoạn phát triển, tuy nhiên chúng có những điểm
chung sau trong hoạt động kiểm thử.

Kiểm thử đơn vị được đơn giản hóa khi module có sự liên kết cao được thiết
kế. Khi chỉ một chức năng được gọi bởi một module, số các trường hợp kiểm thử
được giảm xuống và các lỗi có thể dự đoán và phát hiện sớm hơn.


9

Kiểm thử đơn vị thường do lập trình viên thực hiện. Kiểm thử đơn vị đòi hỏi
kiểm thử viên có kiến thức về thiết kế và code của chương trình. Mục đích của kiểm
thử đơn vị là đảm bảo thông tin được xử lý và xuất là chính xác, trong mối quan hệ
với dữ liệu nhập và chức năng của đơn vị [3], [4].
 Kiểm thử tích hợp
Mục tiêu của kiểm thử tích hợp nhằm thực hiện các lỗi tương tác giữa các
đơn vị, tích hợp các đơn vị thành các hệ thống con vận hành tốt và cuối cùng hệ
thống hoàn toàn sẵn sàng cho kiểm thử hệ thống.
Trong quá trình tích hợp, có thể có khả năng không chỉ tích hợp các đơn vị
được phát triển trong dự án phần mềm, mà còn tích hợp các đơn vị hoặc thành phần
được cung cấp bởi các thư viện hay thậm chí là các thành phần được cung cấp bởi
hệ điều hành.
Kiểm thử tích hợp nên chỉ thực hiện với các đơn vị đã được thẩm định và đã
được kiểm thử đơn vị thành công. Sự tương tác và chức năng của đơn vị mới được
tích hợp và tập các đơn vị đã được tích hợp trước đó sẽ được kiểm thử.
Hai chiến lược kiểm thử tích hợp cơ bản thường được áp dụng gồm:
 Tích hợp từ trên xuống : thực hiện kiểm thử các module chính trước, sau đó
tích hợp thêm vào các module được gọi trực tiếp bởi các module vừa được kiểm thử.
 Tích hợp từ dưới lên: tích hợp các thành phần cơ sở cung cấp các dịch vụ
chung như mạng, truy cập cơ sở dữ liệu, sau đó các thành phần chức năng được
thêm vào.
Trong thực tế, với rất nhiều hệ thống, chiến lược tích hợp là sự pha trộn các
phương pháp trên [11].

Sau khi phân tích sự ảnh hưởng, chúng ta có thể thực hiện lại một số kiểm thử
như kiểm thử đơn vị các thành phần bị sửa đổi, kiểm thử tích hợp có kích hoạt các
thành phần bị sửa đổi, kiểm thử hệ thống có kích hoạt các chức năng bị sửa đổi…
Như vậy, kiểm thử hồi quy có thể áp dụng ở kiểm thử đơn vị, kiểm thử tích
hợp và kiểm thử hệ thống. Để dễ dàng kiểm thử hồi quy chúng ta nên lưu trữ lại
môi trường kiểm thử, các trình điều khiển và các bộ dữ liệu thử…để tái sử dụng.


11

 Kiểm thử chấp nhận
Kiểm thử chấp nhận không nhằm mục đích phát hiện lỗi mà nhằm giúp cho
người sử dụng đánh giá phần mềm so với mong đợi và mục tiêu của họ.
Khi phát triển phần mềm cho một khách hàng cụ thể, kiểm thử chấp nhận
cần phải được thực hiện sau kiểm thử hệ thống. Phần mềm phải được thực thi trong
môi trường thực. Kiểm thử chấp nhận là một mốc quan trọng đối với người phát
triển. Tại thời điểm này, khách hàng sẽ quyết định phần mềm có đạt yêu cầu không.
Nếu khách hàng hài lòng về phần mềm, họ sẽ chấp nhận sản phẩm và bước tiếp theo
là cài đặt phần mềm tại môi trường của khách hàng.
Nếu phần mềm được phát triển cho thị trường rộng lớn, thì kiểm thử cho mỗi
khách hàng là không thực tế. Trong trường hợp này, kiểm thử chấp nhận thường
được chia làm hai giai đoạn:
 Kiểm thử alpha
Kiểm thử alphađược thực hiện trong môi trường phát triển. Một nhóm những
người sử dụng tiềm năng và thành viên nhóm phát triển được mời sử dụng phần
mềm. Các lập trình viên sẽ quan sát và ghi nhận các vấn đề xảy ra.
 Kiểm thử beta
Kiểm thử beta gửi phần mềm đến những người sử dụng, họ cài đặt và sử
dụng phần mềm trong môi trường làm việc thực tế. Người sử dụng sẽ gửi các vấn
đề cho tổ chức phát triển và nhóm phát triển chịu trách nhiệm sửa các lỗi.

với các hệ thống khác hiện đang tồn tại trên thị trường.
 Tính độc lập: Phần mềm có thể làm việc bình thường trong các môi trường
khác nhau, với các hệ điều hành và chủng loại máy khác nhau.
 Tính vững vàng: Khi xảy ra các sự cố khách quan hoặc chủ quan phần
mềm nhận biết và xử lý, không bị treo, bị liệt hoặc gây ra các hiệu quả nghiêm trọng.
 Tính dễ phát triển và hoàn thiện: Khi công nghệ phát triển, nhiều phần
mềm phải thiết kế lại từ đầu, kể cả việc phải chọn môi trường và công cụ phát triển
mới. Một phần mềm được coi là dễ phát triển và hoàn thiện nếu nó thích ứng được
với những thay đổi trong yêu cầu của khách hàng cũng như nền tảng kĩ thuật.


13

1.3 QUY TRÌNH KIỂM THỬ PHẦN MỀM
Mục đích của cuộc kiểm thử chính là thiết kế được một chuỗi các trường hợp
kiểm thử mà có khả năng phát hiện lỗi cao. Chuỗi các trường hợp kiểm thử đó sẽ rà
soát hết tất cả các trường hợp có thể xử lý của chương trình so với đặc tả ban đầu.
Báo cáo kiểm thử sẽ thống kê hết tất cả các trường hợp kiểm thử đã chạy, những lỗi
đã phát hiện trong kiểm thử, chi tiết các dữ liệu đầu vào, các luồng dữ liệu, đầu ra
mong đợi của chương trình (đây chính là kết quả đúng của chương trình), kết quả
thực tế cho ra của chương trình và mục đích kiểm thử…Muốn có được các dữ liệu
đầu vào hợp lý và có khả năng phát hiện lỗi cao như vậy thì cần phải thông qua một
kế hoạch và giai đoạn chuẩn bị hợp lý nhằm thiết kế các Testcase, các dữ liệu cho
các trường hợp kiểm thử. Các giai đoạn kiểm thử này có thể được mô tả qua hình vẽ sau:
Phân tích

Thiết kế

Mã
hóa

liệu kiểm thử

Các trường
hợp kiểm thử

Chạy chương
trình với dữ
liệu kiểm thử

Dữ liệu kiểm
thử

So sánh các kết
quả với các
trường hợp
kiểm thử

Kết quả kiểm
thử

Báo cáo kết
quả cuối cùng

Bàn giao SP

Hình 1. 5 -Quy trình chi tiết quá trình kiểm thử
1.4 TỰ ĐỘNG HÓA KIỂM THỬ
Kiểm thử phần mềm tốn nhiều chi phí nhân công, thời gian. Trong một số dự
án, chi phí kiểm thử phần mềm chiếm 50% tổng giá trị của dự án. Nếu cần ứng
dụng quan trọng hơn, chi phí kiểm thử còn cao hơn nữa.


CHƯƠNG 2
CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
2.1.NGUYÊN TẮC CƠ BẢN CỦA KIỂM THỬ PHẦN MỀM
Các nguyên tắc luôn đó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 các 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 khó kiểm soát của đảm bảo chất lượng 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 xem xét một
số nguyên tắc cơ bản [11], [12] 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.
2.1.1.Các đặc trưng của kiểm thử phần mềm
 Đặc trưng 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 luôn 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 xác định các lỗi này trước
khi phần mềm được sử dụng. 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.
 Đặc trưng2: 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 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à
nhằm phát hiện các loại lỗi gì. Sau đó kiểm thử viên thực hiện lựa chọn 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ẽ cho
kiểm thử viên khẳng định mục tiêu của ca kiểm thử.