MỤC LỤC
MỤC LỤC .................................................................................................... 1
LỜI MỞ ĐẦU............................................................................................... 3
CHƯƠNG I:TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM ................... 5
1.1 Công Nghệ Phần Mềm là gì?..................................................................5
1.2. Các lĩnh vực của Công Nghệ Phần Mềm...............................................5
1.2.1. Các yêu cầu phần mềm (Software requirements) .................................6
1.2.2. Thiết kế phần mềm (Software design) .................................................7
1.2.3. Xây dựng phần mềm (software construction) ......................................8
1.2.4. Kiểm Thử Phần Mềm (software testing) ..............................................8
1.2.5. Bảo trì phần mềm (Software maintenance) ..........................................8
1.2.6. Quản lí cấu hình phần mềm (Software Configuration Management –
SCM): 9
1.2.7. Quản lí Công Nghệ Phần Mềm (Software Engineering Management). 9
1.2.8. Quy trình Công Nghệ Phần Mềm (Software engineering process) .....10
1.2.9. Các phương thức và công cụ trong Công Nghệ Phần Mềm................10
1.2.10. Chất lượng phần mềm .....................................................................10

CHƯƠNG 2: VẤN ĐỀ CHẤT LƯỢNG PHẦN MỀM VÀ KIỂM THỬ
PHẦN MỀM ............................................................................................... 12
2.1

Sản phẩm phần mềm và vấn đề kiểm thử phần mềm ....................12

2.1.1

Sản phẩm phần mềm là gì?...........................................................12

2.1.2

Thế nào là lỗi phần mềm? ............................................................13

3.1.2

Luồng thông tin kiểm thử .............................................................23

1


3.1.3
3.2

Thiết kế trường hợp kiểm thử .......................................................24

Kỹ thuật kiểm thử hộp trắng (White-Box Testing) ........................26

3.2.1

Kiểm thử đường dẫn cơ sở (Basic Path Testing)...........................28

3.2.2

Kiểm thử cấu trúc điều khiển........................................................31

3.3

Kỹ thuật kiểm thử hộp đen (Black-Box Testing)............................38

3.3.1

Phân hoạch tương đương..............................................................39


Chiến lược kiểm thử từ dưới lên (Bottom-Up Testing) .................51

3.5.3

Kiểm thử hồi qui ..........................................................................52

3.5.4

Các ghi chú trên kiểm thử tích hợp...............................................53

3.6

Kiểm thử tính hợp lệ........................................................................55

3.6.1

Điều kiện kiểm thử tính hợp lệ .....................................................55

3.6.2

Duyệt lại cấu hình ........................................................................56

3.6.3

Kiểm thử Alpha và Beta ...............................................................56

3.7

Kiểm thử hệ thống ...........................................................................57


số thẻ tín dụng. Tại sao những sự cố này xảy ra? Phải chăng những người lập
trình viên không thể tạo ra được các chương trình làm việc rõ ràng và không lỗi?
Ngày nay cùng với sự phát triển như vũ bão của Công nghệ thông tin nói chung
và Công Nghệ Phần Mềm nói riêng, việc phát triển phần mềm ngày càng được hỗ
trợ bởi các công cụ tiên tiến, yêu cầu của khách hàng về chức năng của chương
trình nhiều, sự liên kết, trao đổi, xử lí thông tin chéo giữa các chương trình ngày
càng cao, cộng với những giới hạn về thời gian và chi phí khiến cho các chương
trình ngày càng phức tạp và việc đảm bảo một chương trình chạy không bị lỗi
dường như là điều không thể. Đó cũng là lí do chính để “Kiểm Thử Phần Mềm”
(Software Testing) ra đời.
Kiểm Thử Phần Mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn
phát triển phần mềm để đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế
và các yêu cầu đó đáp ứng các nhu cầu của người dùng. Các kỹ thuật Kiểm Thử
Phần Mềm đã, đang được nghiên cứu, và việc Kiểm Thử Phần Mềm đã trở thành
qui trình bắt buộc trong các dự án phát triển phần mềm trên thế giới. Kiểm Thử
Phần Mềm là một hoạt động rất tốn kém, mất thời gian và khó phát hiện được hết
lỗi. Vì vậy, việc Kiểm Thử Phần Mềm đòi hỏi phải có chiến lược phù hợp, một
kế hoạch hợp lý và việc thực hiện được quản lí chặt chẽ.
Đề tài tập trung nghiên cứu, tìm hiểu, đánh giá các kỹ thuật dùng trong
Kiểm Thử Phần Mềm, vị trí của Kiểm Thử Phần Mềm trong Công Nghệ Phần
Mềm và thiết kế một chương trình tự động kiểm tra các liên kết của một website.

3


Đề tài được chia làm 4 chương:
Chương 1 là tổng quan về Công Nghệ Phần Mềm
Chương 2 là vấn đề chất lượng phần mềm và kiểm thử phần mềm.
Chương 3 là phần chính của đề tài, tập trung vào phân tích đánh giá các
kỹ thuật kiểm định phần mềm.

Với các mục đích: đưa ra một cái nhìn tổng quan về Công Nghệ Phần
Mềm thống nhất trên toàn thế giới; Tạo ranh giới để phân biệt Công Nghệ Phần
Mềm với các lĩnh vực khác trong ngành Công nghệ thông tin như Khoa học máy
tính, Quản lí dự án, Công nghệ máy tính hay Toán học; Miêu tả các vấn đề cơ
bản của Công Nghệ Phần Mềm; phạm vi của Công Nghệ Phần Mềm; Cung cấp
5


nền tảng đại cương cho các chương trình phát triển, hệ thống chứng chỉ và bản
quyền. Viện Kỹ thuật Điện và Điện Tử (IEEE) đã chia Công Nghệ Phần Mềm
thành 10 lĩnh vực [7] theo hình 1.1

Hình 1.1: Các lĩnh vực trong Công Nghệ Phần Mềm

Trong phần tiếp theo đề tài trình bày khái quát về chức năng, vai trò và phạm vi
của những lĩnh vực con của Công Nghệ Phần Mềm.
1.2.1. Các yêu cầu phần mềm (Software requirements)
Một yêu cầu phần mềm [7] là một thuộc tính được thể hiện đúng khi phần
mềm được tạo ra để giải quyết một vấn đề nào đó. Ví như tự động hóa một khâu
nào đó của người sử dụng, hỗ trợ doanh nghiệp ra quyết định hay điều khiển thiết
bị. Cũng có thể xem yêu cầu như một chức năng phải tồn tại trên hệ thống. Chức
năng của con người, các quy trình của doanh nghiệp và các thiết bị trong mỗi hệ
thống là khác nhau vì thế nên các yêu cầu phần mềm có thể được định nghĩa là
tổng hợp các yêu cầu của người sử dụng tại mỗi bộ phận khác nhau của tổ chức
và từ môi trường nơi phần mềm sẽ được sử dụng. Cần phân biệt một số loại yêu
cầu:

6



7


1.2.3. Xây dựng phần mềm (software construction)
Xây dựng phần mềm [7] là những việc làm trực tiếp để tạo ra sản phẩm
phần mềm bao gồm các hoạt động như viết mã chương trình, kiểm tra, kiểm thử
đơn vị, kiểm thử tích hợp và gỡ lỗi. Xây dựng phần mềm bao gồm 3 lĩnh vực
nhỏ:
Cơ bản về xây dựng phần mềm: 4 nguyên lí cơ bản trong xây dựng phần
mềm đó là: Giảm tới mức tối thiểu độ phức tạp; Dự đoán trước sự thay đổi; Tạo
các đầu mối để kiểm tra và cuối cùng là tuân thủ theo các chuẩn.
Quản lí xây dựng phần mềm: Quản lí xây dựng phần mềm bao gồm các
chủ đề nhỏ là các mô hình xây dựng, kế hoạch xây dựng và đo lường xây dựng.
Các khía cạnh thực hành trong xây dựng phần mềm: đó là thiết kế xây
dựng, các ngôn ngữ xây dựng, lập trình, kiểm thử, tái sử dụng, chất lượng xây
dựng và tích hợp.

1.2.4. Kiểm Thử Phần Mềm (software testing)
Các khái niệm, vai trò và các kỹ thuật Kiểm Thử Phần Mềm sẽ được trình
này chi tiết trong Chương II của đề tài.

1.2.5. Bảo trì phần mềm (Software maintenance)
Trong quá trình hoạt động một số khuyết điểm bộc lộ, môi trường hoạt
động thay đổi và những yêu cầu mới của người dùng phát sinh do đó đòi hỏi phải
có một quá trình bảo trì phần mềm [7]. Quá trình bảo trì phần mềm bắt đầu khi
thời gian bảo hành phần mềm kết thúc hay các hỗ trợ sau cài đặt được chuyển
giao, nhưng các hoạt động bảo trì phần mềm thực sự thì xuất hiện sớm hơn. Bảo
trì phần mềm được định nghĩa như là các hoạt động để đảm bảo hỗ trợ sản phẩm
phần mềm hoạt động tốt nhất. Các hoạt động được thực hiện cả trước và sau khi
chuyển giao phần mềm, bao gồm: Lập kế hoạch cho các hoạt động sau khi

Lập kế hoạch dự án phần mềm: Bao gồm việc tạo các quy trình, xác định
khả năng chuyển giao, ảnh hưởng, lên kế hoạch và ước lượng chi phí, cấp phát
tài nguyên, quản lí rủi ro, quản lí chất lượng…

9


Công bố dự án phần mềm: Đó là sự thực thi các kế hoạch, quản lí hợp
đồng cung cấp, thực thi các quy trình đo lường, quy trình quản lí, quy trình điều
khiển và thông báo.
Kiểm tra và đánh giá: Xác định mức độ thỏa mãn các yêu cầu, kiểm tra và
đánh giá hiệu năng.
Kết thúc: Xác đinh thời điểm kết thúc và các hành động kết thúc.
Đánh giá Công Nghệ Phần Mềm: Bao gồm việc khởi tạo và giữ vững
những cam kết đánh giá, lập kế hoạch đánh giá, thực hiện kế hoạch và đanh giá.

1.2.8. Quy trình Công Nghệ Phần Mềm (Software engineering process)
Quy trình Công Nghệ Phần Mềm [7] phân thành hai mức, mức thứ nhất
bao gồm các kĩ thuật và hành động của người quản trị được sử dụng và thực hiện
trong các quy trình vòng đời phần mềm, trong các quá trình phát triển, bảo trì và
thu hồi. Mức thứ hai tập trung vào việc định nghĩa, cài đặt, quản lí, đánh giá, thay
đổi và cải tiến của các quy trình vòng đời phần mềm

1.2.9. Các phương thức và công cụ trong Công Nghệ Phần Mềm.
Các công cụ phát triển phần mềm [7] là các sản phẩm, công cụ được sử
dụng để trợ giúp các quy trình vòng đời phần mềm, hệ thống hóa Công Nghệ
Phần Mềm.
Các phương thức Công Nghệ Phần Mềm [7] đảm bảo các hoạt động được
thực hiện đúng và thực hiện một cách có hệ thống, đảm bảo sự thành công


11


CHƯƠNG 2: VẤN ĐỀ CHẤT LƯỢNG PHẦN MỀM
VÀ KIỂM THỬ PHẦN MỀM
2.1

Sản phẩm phần mềm và vấn đề kiểm thử phần mềm

2.1.1 Sản phẩm phần mềm là gì?
Phần mềm là một (bộ) chương trình được cài đặt trên máy tính nhằm thực
hiện một nhiệm vụ tương đối độc lập nhằm phục vụ cho một ứng dụng cụ thể
việc quản lý họat động của máy tính hoặc áp dụng máy tính trong các họat động
kinh tế, quốc phòng, văn hóa, giáo dục, giải trí,…
Việc tạo ra một sản phẩm phần mềm phải trải qua nhiều giai đoạn, người ta
gọi là qui trình phát triển phần mềm, bắt đầu từ khi bắt đầu có ý tưởng cho đến
khi đưa ra sản phẩm phần mềm thực thi. Khối lượng công việc trong từng giai
đoạn của quá trình sản xuất phần mềm cũng thay đổi theo thời gian. Bảng 2.1
minh họa cụ thể hơn về điều này.
Bảng 2.1 - Tỉ lệ công việc của các giai đoạn phát triển phần mềm
Giai đoạn

Phân tích Thiết kế
yêu cầu
sơ bộ

Hai thập kỉ 1960 - 1970

10%


Đặc tả

3%

Thiết kế

5%

Lập trình

7%

Kiểm thử

15%

Vận hành và bảo trì

67%

Như vậy, một sản phẩm phần mềm không chỉ đơn giản là các đoạn mã
chương trình mà còn rất nhiều phần ẩn đằng sau nó (Hình 2.1). Vì vậy, việc mắc
12


lỗi không chỉ xảy ra trong khi lập trình mà còn xảy ra cao hơn trong các công
đoạn khác của qui trình phát triển một sản phẩm phần mềm. Việc kiểm thử cũng
vì thế phải được tiến hành trong tất cả các phần tạo nên một sản phẩm phần mềm.
Đặc tả
sản phẩm

Sản phẩm
cuối cùng

Setup, Help Files, Samples asn
Examples, Readme files, Error
Messages, Icons and Arts, User
Manuals, Product Support
Information, …

Hình 2.1 – Sản phẩm phần mềm

2.1.2 Thế nào là lỗi phần mềm?
Có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng tựu chung, có
thể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không khớp giữa chương
trình và đặc tả của nó.” [7]
Dựa vào định nghĩa, chúng ta có thể thấy lỗi phần mềm xuất hiện theo ba
dạng sau:
 Sai: Sản phẩm được xây dựng khác với đặc tả.

13


 Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm
được xây dựng.
 Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả. Cũng
có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng
chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi.
Một hình thức khác nữa cũng được xem là lỗi, đó là phần mềm khó hiểu,
khó sử dụng, chậm hoặc dễ gây cảm nhận rằng phần mềm họat động không đúng.
2.1.3 Tại sao lỗi phần mềm xuất hiện?

trình chỉ là một phần việc của quá trình phát triển phần mềm, cộng với sự hỗ trợ
của nhiều công cụ lập trình cao cấp, việc lập trình trở nên nhẹ 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 nhiều hơn. Dó 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”. Một điều cũng hiển nhiên là nhiều lỗi
xuất hiện trên bề mặt lập trình nhưng thực ra lại do lỗi của đặc tả hoặc thiết kế.
Một nguyên nhân khác tạo ra lỗi là do bản thân các công cụ phát triển phần
mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch,…
2.1.4 Chi phí cho việc sữa lỗi
Theo tài liệu trích dẫn của Martin và McCable [12], bảo trì là phần chi phí
chính của phần mềm và kiểm thử là hoạt động chi phí đắt thứ hai, ước tính
khoảng 40% (15/33) chi phí trong quá trình phát triển ban đầu của 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
người dùng.
Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng
đời phần mềm. Tuy nhiên chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể
trong quá trình phát triển.
Sự thay đổi một tài liệu yêu cầu khi duyệt lại lần đầu tiên là không đắt nếu
không nói là không đáng kể. Chi phí sẽ tăng lên nhiều hơn nếu các yêu cầu thay
đổi sau khi đã lập trình. Thay đổi yêu cầu lúc đó đồng nghĩa với việc viết lại
chương trình.

15


Việc sửa lỗi sẽ không còn đáng kể nếu người lập trình tự phát hiện lỗi của
mình. 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. 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

mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm đó

16


có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay
không.
Trên thực tế, hệ thống đang thực hiện khác biệt với việc duyệt lại mã
nguồn. Thông thường, người phát triển thực hiện việc đọc lại và phân tích mã
nguồn. Nói cách khác, kiểm thử đòi hỏi một hệ thống chạy được. Đặc tả là căn cứ
chủ yếu hỗ trợ cho việc kiểm thử. Nó xác định những hành vi đúng và làm cho dễ
dàng hơn trong việc xác định những hành vi không đúng. Mỗi hành vi không
đúng chính là một lỗi phần mềm. Nói chung, người phát triển phải tự chẩn đoán
nguyên nhân sinh lỗi trong mã nguồn.
Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm
một cách sớm nhất có thể và đảm bảo rằng lỗi đã được sửa, mà kiểm thử phần
mềm không làm công việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện
và sửa lỗi. Chúng ta sẽ nghiên cứu kĩ hơn vấn đề này ở những phần tiếp theo.
Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có
hệ thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thời gian,
công sức và chi phí.

2.2

Chất lượng phần mềm

Chất lượng phần mềm là một khái niệm đa chiều, không dễ định nghĩa đơn
giản theo cách chung cho các sản phẩm là: “Sản phẩm được phát triển phù hợp
với đặc tả của nó.” (Ian. Samerville [13] trích dẫn định nghĩa của Crosby). Có
một số vấn đề khó trong hệ thống phần mềm, đó là:


Xác minh và thẩm định
phần mềm

Kiểm thử phần mềm

Kiểm thử phần mềm

(a) Ngữ cảnh quy trình

(b) Ngữ cảnh chất lượng

Hình 2.4 - Kiểm thử phần mềm trong một số ngữ cảnh

Trên quan điểm qui trình, kiểm thử phần mềm là một phần của xác minh và
thẩm định phần mềm. Xác minh và thẩm định nằm trong công nghệ phần mềm,
công nghệ phần mềm lại là một phần của công nghệ hệ thống (Hình 2.4a). Nhìn
từ ngữ cảnh chất lượng (Hình 2.4b), kiểm thử phần mềm cũng là một phần phần
của xác minh và thẩm định phần mềm, nên cũng có thể xem như là một phần của
đảm bảo chất lượng phần mềm. Nếu phần mềm là thành phần của hệ thống lớn
hơn thì kiểm thử phần mềm cũng được xem như là một phần của quản lý và đảm

18


bảo chất lượng. Và để đạt phần mềm chất lượng cao, thì kiểm thử có thể coi là
một thành phần chủ yếu của hoạt động đảm bảo chất lượng phần mềm.

2.3


1012-1986 bao gồm các thông tin về tác giả chuẩn bị kế hoạch, danh sách
liệt kê của kế hoạch kiểm thử. Vấn đề quan trọng nhất đối với kế hoạch
kiểm thử[IEEE86]:
+ Mục đích: Qui định về phạm vi, phương pháp, tài nguuyên và lịch

biểu của các hoạt động kiểm thử.
+ Các tài liệu tham khảo.
+ Các định nghĩa.

19


+ Khái quát về xác minh và thẩm định (V&V): tổ chức, tài nguyên, trách

nhiệm, các công cụ, kỹ thuật và các phương pháp luận.
+ Vòng đời của V&V: các nhiệm vụ, các dữ liệu vào và các kết quả ra
trên một giai đoạn vòng đời.
+ Báo cáo xác minh và thẩm định(V&V) phần mềm: mô tả nội dung,
định dạng và thời gian cho tất cả các báo cáo V&V.
+ Các thủ tục quản lý V&V bao gồm các chính sách, thủ tục, các chuẩn,
thực nghiệm và các qui ước.
 Giai đoạn bố trí nhân viên kiểm thử. Việc kiểm thử thường phải tiến hành
một cách độc lập và các nhóm độc lập có trách nhiệm tiến hành các họat
động kiểm thử, gọi là các nhóm kiểm thử.
 Thiết kế các trường hợp kiểm thử. Các trường hợp kiểm thử là các đặc tả
đầu vào cho kiểm thử và đầu ra mong đợi của hệ thống cùng với các câu
lệnh được kiểm thử. Có một vài phương pháp thiết kế trường hợp kiểm thử
và các qui tắc từ các nhà thiết kế kiểm thử có kinh nghiệm. Tuy nhiên, có
hai chiến lược kiểm thử cơ bản
 Các phương pháp hộp đen để kiểm thử dựa trên chức năng.

hợp
kiểm thử

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ử

Hình 2.6 – Qui trình kiểm thử phần mềm

21

Kết quả
kiểm thử


CHƯƠNG 3: CÁC KỸ THUẬT KIỂM THỬ PHẦN
MỀM
Có thể sử dụng một số kỹ thuật trong quá trình kiểm thử nhằm tăng hiệu
quả của họat động này. Mc Gregor (2001) mô tả các kỹ thuật kiểm thử như
những công cụ được thiết kế để đảm bảo rằng tất cả các khía cạnh của sản phẩm
đều được khảo sát. Mặt khác, các kỹ thuật kiểm thử là những công cụ để dễ dàng

xây dựng và việc kiểm thử yêu cầu họ vượt qua các khái niệm cho trước về độ
chính xác và giải quyết mâu thuẫn khi các lỗi được xác định.
3.1.1 Mục tiêu kiểm thử
Các nguyên tắc được xem như mục tiêu kiểm thử là:
 Kiểm thử là một quá trình thực thi chương trình với mục đích tìm lỗi.
 Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả năng cao
việc tìm thấy các lỗi chưa từng được phát hiện.
 Một kiểm thử thành công là kiểm thử mà phát hiện lỗi chưa từng được
phát hiện.
3.1.2 Luồng thông tin kiểm thử
Luồng thông tin cho kiểm thử được biểu diễn bởi mô hình trong hình 3.1.
Hai kiểu của đầu vào được truyền cho quá trình kiểm thử:
 Cấu hình phần mềm: gồm các đặc tả yêu cầu, đặc tả thiết kế, và mã
nguồn.
 Cấu hình kiểm thử: gồm có kế hoạch kiểm thử, các thủ tục, trường hợp
kiểm thử, và các công cụ kiểm thử.
Kiểm thử được thực hiện và tất cả các kết quả được xem xét, kết quả kiểm
thử được so sánh với kết quả mong đợi. Khi dữ liệu không đúng được nhận biết,
lỗi được bao hàm và việc gỡ rối bắt đầu. Thủ tục gỡ rối là thành phần khó dự
đoán nhất của thủ tục kiểm thử. Một “lỗi” với sự khác nhau 0.01% giữa các kết
quả ra thực tế và kết quả mong đợi có thế mất hàng giờ, ngày, tháng để nhận biết
23


và hiệu chỉnh. Sự không chắc trong gỡ rối mà kiểm thử gây nên sẽ là khó lập lịch
biểu độ tin cậy.

Gỡ rối

Cấu hình phần mềm

phát triển, cung cấp cho đội ngũ phát triển cách tiếp cận có hệ thống cho việc
kiểm thử. Các phương pháp thường cung cấp một cách tiếp cận đảm bảo tính đầy
đủ của kiểm thử và cung cấp khả năng cao nhất để phát hiện các lỗi của phần
mềm.
Như vậy, vấn đề quan trọng nhất trong kiểm thử phần mềm là thiết kế và
tạo ra các trường hợp kiểm thử có hiệu quả. Lý do về tầm quan trọng của việc
thiết kế các trường hợp kiểm thử xuất phát từ thực tế: Kiểm thử “vét cạn” là điều
không thể, và như vậy, kiểm thử một chương trình phải luôn xác định là không

24


thể vét cạn (tức kiểm thử không thể đảm bảo rằng chương trình không còn lỗi
nào). Vấn đề quan trọng là cố gắng làm giảm sự “không thể vét cạn” nhiều nhất
có thể.
Kiểm thử phần mềm còn có các ràng buộc về thời gian, chi phí, … Chìa
khoá của kiểm thử là trả lời của câu hỏi: “Tập con của tất cả các trường hợp
kiểm thử có thể có xác suất phát hiện lỗi cao nhất là gì?”. Việc nghiên cứu các
phương pháp thiết kế trường hợp kiểm thử sẽ cung cấp câu trả lời cho câu hỏi
này.
Bất kỳ sản phẩm công nghệ nào có thể được kiểm thử trong hai cách:
 Biết về các chức năng cụ thể mà sản phẩm đã được thiết kế để thực hiện,
các kiểm thử có thể được thực hiện để chứng tỏ mỗi chức năng được thực
hiện đầy đủ, tại một thời điểm nào đó tìm kiếm các lỗi trong mỗi chức năng;
 Biết cách hoạt động bên trong của sản phẩm, kiểm thử có thể được thực
hiện để đảm bảo rằng “tất cả các thành phần ăn khớp nhau”, tức là, hoạt
động bên trong thực hiện theo đặc tả và tất cả các thành phần bên trong đã
được thực hiện một cách thoả đáng.
Cách tiếp cận kiểm thử đầu tiên được gọi là kiểm thử hộp đen và cách thứ
hai là kiểm thử hộp trắng.