-1-

Phần I: Giới Thiệu Về Kiểm Thử Phần Mềm
1.1Khái niệm kiểm thử phần mềm
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à khâu mấu chốt để đảm bảo chất lượng phần mềm,
là đánh giá cuối cùng về đặc tả thiết kế và mã hóa.
Kiểm thử 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ó có thỏa mãn các yêu cầu đã đặt ra trong quá trình phát triển phần
mềm, những người phát triển phần mềm và các kỹ sư kiểm thử cùng làm việc để
phát hiện lỗi và đảm bảo chất 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.
• Chi phí của kiểm thử chiếm
• 40% tổng công sức phát triển
• >=30% tổng thời gian phát triển
• Kiểm thử tốt sẽ:
• Giảm chi phí phát triển
• Tăng độ tin cậy của sản phẩm phần mềm

Trường hợp
kiểm thử

dữ liệu
kiểm thử

Kết quả


1.2 Mục tiêu của 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.
1.3 Những khó khăn của kiểm thử
•Nâng cao chất lượng phần mềm nhưng không vượt quá chất lượng
thiết kế. chỉ phát hiện các lỗi tiềm tàng và sửa chúng
•Phát hiện lỗi bị hạn chế do thủ công là chính
•Dễ bị ảnh hưởng tâm lý khi kiểm thủ.
•Khó đảm bảo tính đầy đủ của kiểm thử
1.4 Các phương pháp kiểm thử
Người ta phân biệt 2 phương pháp kiểm thử: Kiểm thử trên bàn hay kiểm
thử tĩnh và Kiểm thử trên máy hay kiểm thử động. Kiểm thử tĩnh thường được
tiến hành trước nhằm tạo ra kịch bản cho kiểm thử động.
1.5 Các kỹ thuật thiết kế trường hợp kiểm thử
Kiểm thử hộp đen – Black box testing
Kiểm thử hộp trắng – White box testing
Kiểm thử hộp xám – Gray box testing
1.6 Phương pháp thử các mô đun
Để kiểm thử một phần mềm, người ta tiến hành kiểm thử theo trình tự sau:
• Kiểm thử môđun
• Kiểm thử tích hợp
• Kiểm thử hệ thống
• Kiểm thử chấp nhận (β Testing)



cho trước
Một cuộc thanh tra bao gồm:
Đặc tả phần mềm
Kế hoạch thanh tra
Sản phẩm phần mềm
Điều phối viên
Thanh tra viên


-4-

Tác giả phần mềm
Tiến trình thanh tra:
1. Lên kế hoạch
2. Gặp gỡ trước
3. Chuẩn bị
4. Gặp gỡ thanh tra
5. Gia công lại
6. Bám sát
Chú ý: các khâu 3,4,5 có thể thực hiện lặp lại
* Duyệt
Khái niệm:
Là một phương pháp kiểm tra ngang hàng với một người thiết kế hướng nhóm
phát triển đến các hoạt động chú ý của quá trình sản xuất phần mềm, tham gia
đặt câu hỏi và chú thích cho các lỗi có thể có.
Khác biệt với thanh tra:
Cấu trúc mở
Khả năng gợi ý định hướng thay đổi phần mềm
Tiến trình duyệt:
1. Đánh giá đầu vào

nhiệm vụ mà mô đun phải đảm nhận, đầu vào cho mô đun và kết quả xử lý - đầu
ra.
Kiểm thử hộp đen lại chia nhỏ ra nhiều kỹ thuật:
- Phân đoạn tương đương
- Phân tích giá trị biên
- Đoán lỗi
và một số kỹ thuật khác
Hình 1: Black Box testing
*Phân Đoạn Tương Đương
Đây là kỹ thuật chia vùng thông tin nhập vào của chương trình thành các lớp
thông tin/dữ liệu. Lớp tương đương biểu diễn thành một tập các giá trị hợp lệ và
không hợp lệ. Nhưng lớp dữ liệu tương đương này có thể được xác định theo
những cách sau:
1. Nếu điều kiện đầu vào xác định một khoảng giá trị [a,b], thì phân
hoạch thành một lớp tương đương hợp lệ và một lớp tương đương
không hợp lệ. Chẳng hạn, nếu đầu vào x nằm trong khoảng [0,100], lớp
hợp lệ là 0
tỷ lệ phần trăm cao hơn các ca kiểm thử khác. Các điều kiện biên là những điều
kiện mà các tình huống ngay tại, trên và dưới các cạnh của các lớp tương đương
đầu vào và các lớp tương đương đầu ra. Phân tích các giá trị biên là phương
pháp thiết kế ca kiểm thử bổ sung thêm cho phân lớp tương đương, nhưng khác
với phân lớp tương đương ở 2 khía cạnh:
1. Phân tích giá trị biên không lựa chọn phần tử bất kỳ nào trong 1 lớp
tương đương là điển hình, mà nó yêu cầu là 1 hay nhiều phần tử được
lựa chọn như vậy mà mỗi cạnh của lớp tương đương đó chính là đối
tượng kiểm tra.
2. Ngoài việc chỉ tập trung chú ý vào các trạng thái đầu vào (không gian
đầu vào), các ca kiểm thử cũng nhận được bằng việc xem xét không
gian kết quả (các lớp tương đương đầu ra).
Phân tích giá trị biên yêu cầu óc sáng tạo và lượng chuyên môn hóa nhất định và
nó là một quá trình mang tính kinh nghiệm rất cao. Tuy nhiên, có một số quy tắc
chung như sau:
1. Nếu 1 trạng thái đầu vào định rõ giới hạn của các giá trị, hãy viết các ca
kiểm thử cho các giá trị cuối của giới hạn, và các ca kiểm thử đầu vào
không hợp lệ cho các trường hợp vừa ra ngoài phạm vi.
2. Nếu 1 trạng thái đầu vào định rõ số lượng giá trị, hãy viết các ca kiểm
thử cho con số lớn nhất và nhỏ nhất của các giá trị và một giá trị trên,
một giá trị dưới những giá trị này.
3. Sử dụng quy tắc 1 cho mỗi trạng thái đầu vào. Ví dụ, nếu 1 chương trình
tính toán sự khấu trừ FICA hàng tháng và nếu mức tối thiểu là 0.00$, và
tối đa là 1,165.25$, hãy viết các ca kiểm thử mà khấu trừ 0.00$ và
1,165.25, khấu trừ âm và khấu trừ lớn hơn 1,165.25$. Chú ý là việc xem
xét giới hạn của không gian kết quả là quan trọng vì không phải lúc nào
các biên của miền đầu vào cũng mô tả cùng một tập sự kiện như biên


-8-

quả được gán cho 1 số duy nhất.
3. Xây dựng đồ thị nguyên nhân – kết quả bằng cách phát triển và biến đổi
nội dung ngữ nghĩa của đặc tả thành đồ thị Boolean nối giữa nguyên
nhân và kết quả.
4. Đồ thị được được diễn giải với các ràng buộc mô tả những sự kết hợp
của nguyên nhân và/hoặc kết quả là không thể vì các ràng buộc ngữ
nghĩa và môi trường.
5. Bằng việc dò theo các điều kiện trạng thái trong đồ thị một cách cẩn
thận, bạn chuyển đổi đồ thị thành một bảng quyết định mục vào giới
hạn. Mỗi cột trong bảng mô tả một ca kiểm thử.
6. Các cột trong bảng quyết định được chuyển thành các ca kiểm thử.
Ký hiệu cơ bản cho đồ thị được chỉ ra trong hình 1. Tưởng tượng mỗi nút có giá
trị là 0 hoặc 1; 0 mô tả trạng thái vắng mặt và 1 mô tả trạng thái có mặt. Hàm
đồng nhất nói là nếu a là 1 thì b là 1; ngược lại, b là 0. Hàm not là nói nếu a là
1 thì b là 0; ngược lại thì b là 1. Hàm or khẳng định rằng nếu a hoặc b hoặc c là
1, thì d là 1; ngược lại d là 0. Hàm and khẳng định nếu cả a và b là 1 thì c là 1;
ngược lại c là 0. Hai hàm or và and được phép có số lượng đầu vào bất kỳ.
Hình 1

Các ký hiệu đồ thị nguyên nhân – kết quả cơ bản


- 10 -

Trong hầu hết các chương trình, sự kết hợp nào đó của một số nguyên nhân là
không thể bởi vì lý do ngữ nghĩa và môi trường (ví dụ, một ký tự không thể
đồng thời vừa là “A” vừa là “B”). khi đó, ta sử dụng ký hiệu trong Hình 2
Ràng buộc E (Exclude – loại trừ) khẳng định rằng tối đa, chỉ có hoặc a hoặc b có
thể là 1 (a và b không thể đồng thời là 1). Ràng buộc I (Include – bao hàm)
khẳng định ít nhất một trong a, b hoặc c phải luôn luôn là 1 (a, b hoặc c không


- 12 -

nếu bạn đang khảo sát trạng thái mà 1 đầu ra là 0 và một hay nhiều đầu
ra khác là 1, thì không nhất thiết phải liệt kê tất cả các điều kiện mà
dưới điều kiện đó các đầu vào khác có thể là 1.
3. Khi lần ngược trở lại qua một nút and mà đầu ra của nó là là 0, chỉ cần
liệt kê 1 điều kiện trong đó tất cả đầu vào bằng 0. (Nếu nút and ở chính
giữa của đồ thị như vậy thì tất cả các đầu vào của nó xuất phát từ các
nút trung gian khác, có thể có quá nhiều trạng thái mà trong trạng thái
đó tất cả các đầu vào của nó bằng 0.)
Hình 3

Những xem xét được sử dụng khi dò theo đồ thị
• Nếu x=1, không quan tâm về
trường hợp a=b=1 (sự xem xét
thứ 1)
• Nếu x=0, liệt kê tất cả các
trường hợp trong đó a=b=0.
• Nếu x =1, liệt kê tất cả các
trường hợp trong đó a=b=c=1.
• Nếu x=0, bao gồm chỉ 1 trường
hợp mà a=b=c=0 (sự xem xét
3). Đối với các trạng thái mà
abc là 001, 010, 100, 011, 101
và 110 , bao gồm chỉ 1 trường
hợp mỗi trạng thái (sự xem xét

2).
Những sự xem xét này có thể xuất hiện thất thường, nhưng chúng có một mục


- 14 -

* Kiểm thử đường diễn tiến của chương trình
Khái niêm: Là việc thiết kế các trường hợp kiểm thử trên từng câu lệnh trong
chương trình được sẽ được thực hiện ít nhất 1 lần không quan tâm đến ảnh
hưởng lên các đường quyết định.
Mỗi nút của đồ thị được
biểu diễn một lệnh hay
một dãy lệnh liên tiếp của
chương trình.
Các bước tiến hành:
Dùng tài liệu thiết kế hay
mã nguồn để vẽ thuật toán
của chương trình hay hàm
Xác định đồ thị V(G)
Từ đồ thị xác định tập đường độc lập tuyến tính lẫn nhau
Xây dựng trường hợp kiểm thử dựa trên tập đường xác định ở trên
*Kiểm Định Cấu Trúc Điều Kiển
a. Kiểm thử các biểu thức điều kiện
Kiểm thử biểu thức điều kiện là phương pháp kiểm thử trên những điều kiện
logic của hàm hay module. Một điều kiện đơn giản là một biến boolean hoặc là
một biểu thức quan hệ:
• X hay Not X một điều kiện logic đơn giản.
• Biểu thức quan hệ thường có dạng : E1 E2


- 15 -

E1, E2 là các biểu thức số học và phép toán quan hệ là một trong các phép toán

nó và biến toàn cục.
DEF(S) = { X | lệnh S chứa định nghĩa X }
USE(S) = { X | lệnh S chứa một lệnh/biểu thức sủ dụng X }
Nếu S là câu lệnh if hay loop, thì tập DEF của S là rỗng và USE là tập dựa trên
điều kiện của câu lệnh S.
Định nghĩa 1 biến X tại câu lênh S được cho là vẫn còn sống tại câu lênh S’ nếu
như tồn tại một đường từ câu lệnh S đến câu lệnh S’ không chứa bất kỳ định
nghĩa nào của X.
Định nghĩa 2 Một chuỗi dùng của biến X ( gọi là DU của X) ký hiệu [X, S, S’]
là định nghĩa của X trong câu lệnh S vẫn sống trong câu lênh S’.
Phương pháp kiểm thử luồng dữ liệu yêu cầu rằng tất cả các chuỗi DU đều được
kiểm thử ít nhất một lần. Có thể thấy rằng bộ kiểm thử cho luồng dữ liệu có thể
không bao trùm tất cả các nhánh của chương trình. Tuy nhiên nêu môt nhánh
đảm bảo được sẽ được phát hiện bỏi phương pháp kiểm thử này. Trong một số
hiếm trường hợp như là cấu trúc lệnh if-then trong phần then không có định
nghĩa thêm một biến nào và phần else không tồn tại. Trong tình huông này thì
nhánh else của câu lênh ì trên không cần thiết phải bảo hộ bởi phương pháp này.
DFT rất hũư ích cho các loài kiểm thử một chương trình có nhiều lệnh if và lệnh
lặp lồng nhau nhiều cấp.


- 17 -

Ví Dụ Hình 1 Một Thủ Tục Với Lệnh Điều Kiện Và Lệnh Lặp Phức Tạp
proc x
B1;
do while C1
if C2
then
if C4

- 18 -

Hình 2 Các Cấu Trúc Lặp

vòng lặp đơn
giản

vòng lặp tạo
thành tổ

vòng lặp móc nối

vòng lặp không
cầu trúc

Vòng Lặp Đơn

Tập hợp tiếp theo là các trường hợp kiểm thử cho vòng lặp đơn, với n là
maximum số lần lặp.
• Bỏ tính toàn vẹn của vòng lặp
• Chỉ cần một lần duyệt xuyên qua cả vòng lặp
• Hai lần duyệt xuyên qua cả vòng lặp
• m lần duyệt xuyên qua cả vòng lặp
• n-1, n, n+1 lần duyệt xuyên qua cả vòng lặp
Vòng Lặp Tạo Tổ
Nếu như chúng ta mở rộng phương pháp kiểm thử cho vòng lặp đơn thì số lượng
trường hợp kiểm thử sẽ tăng rất nhiều. Sau đây là một cách là giảm sồ lượng
trường hợp kiểm thử :




- 20 -

• V(G) = E – N +2, với E là số cung, N là số nút của G
• V(G) = số vùng (region)
• V(G) = P +1, với P là số lượng nút Predicat (nút giả định, không có thật
2.3.3 Kiểm thử hộp xám – Gray box testing
Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật
bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở
mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định
dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì
đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ
thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử
tích hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên
viên thiết kế khác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm
thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá
trị biên hay thông báo lỗi.
2.4 Phương pháp thử các mô đun
2.4.1 Kiểm thử mô đun
Được tiến hành một cách độc lập từng mô đun theo các kỹ thuật trên. Khi các
mô đun được kiểm thử xong, kiểm thử tích hợp được tiến hành.
2.4.2 Kiểm thử tích hợp – Intergration Test

Kiểm thử tích hợp với mục đích là kiểm tra giao diện và sự liên tác giữa
các mô đun. Do vậy, các mô đun đã được kiểm thử xong coi như không có lỗi ở


- 21 -

mức mô đun. Việc truy nhập ở đây là ở mức mô đun và nhằm phát hiện lỗi giao

- 22 -

* Kiểm tra bottom-up
Nguyên tắc của bottom-up là kiểm tra mọi thay đổi tại module có thể
ảnh hưởng tới chức năng của nó. Trong kiểm tra bottom-up, toàn bộ khối là
đơn vị để đánh giá. Tất cả các module được mã hoá và kiểm tra riêng rẽ.
Mức 4

Mức 3

Mức 2

Mức 1

Các trường hợp kiểm tra: các trường hợp kiểm tra là dữ liệu vào được
tạo để thể hiện từng khối và toàn bộ hệ thống thoả mãn tất cả các yêu cầu
thiết kế.
Mỗi trường hợp kiểm tra nên được phát triển để kiểm tra nghiệm các
đòi hỏi thiết kế đặc trưng, thiết kế chức năng, hoặc mã đã được thoả mãn.
Hơn nữa các trường hợp kiểm tra cần dự đoán các output.
Mỗi đơn nguyên của ứng dụng (Ví dụ: module, subroutine, program,
utility,...) phải được kiểm tra với ít nhất hai trường hợp kiểm tra: một trường
hợp chạy tốt và một trường hợp không chạy. Trong trường hợp chạy sai hệ
phải đưa được thông báo, quay lại (rollback) được trạng thái ban đầu của
giao dịch.
Để chắc chắn rằng các trường hợp được toàn diện nhất, người ta
thường dùng ma trận. Chúng được dùng cho:


- 23 -



- 24 -

Điểm khác nhau then chốt giữa Integration Test và System Test là System Test
chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự
giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông
thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và
sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.
Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình thành
cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình
viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn
chỉnh. Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và
phân tích các yêu cầu.
System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu
về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.
Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần
mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc
chiếm dụng bộ nhớ. Sau giai đoạn System Test, phần mềm thường đã sẵn sàng
cho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm
(Acceptance Test) hoặc dùng thử (Alpha/Beta Test).
Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test
thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm
phát triển dự án. Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau,
phổ biến nhất gồm:
•

Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ
thống thỏa mãn đúng yêu cầu thiết kế.


nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như
ngân hàng trực tuyến...

Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng
bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.
Lưu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy
yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của
dự án, khi lập kế hoạch, người Quản lý dự án sẽ quyết định áp dụng những loại
kiểm thử nào.
* Kiểm thử chấp nhận sản phẩm – Acceptance Test
Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng
thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của
Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách
hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).
Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường
hợp, các phép kiểm thử của System Test và Acceptance Test gần như tương tự,
nhưng bản chất và cách thức thực hiện lại rất khác biệt.
Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử
dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha –
Alpha Test và kiểm thử Beta – Beta Test. Với Alpha Test, người dùng kiểm thử
phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi
hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, phần mềm sẽ được gửi
tới cho người dùng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi
cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.