Test Types & Test Levels

1. 1
v1.1013109225
BÀI 2
KIỂM THỬ PHẦN MỀM
Giảng viên: ThS. Trần Mạnh Thắng

2. 2
v1.1013109225
TÌNH HUỐNG DẪN NHẬP

Kiểm thử phần mềm là gì? và có những phương pháp, chiến lược, kỹ thuật
và cấp độ kiểm thử nào? Nó được áp dụng như thế nào trong quá trình sản
xuất phần mềm của công ty STT?
• Như trong bài một thì chúng ta đã có những khái niệm về công nghệ phần mềm,
các pha trong tiến trình xây dựng cũng như các mô hình sản xuất các phần mềm…
để công ty STT có thể sử dụng trong quá trình sản xuất các sản phẩm phần mềm
tuỳ theo quy mô và đặc điểm của từng sản phẩm;
• Tuy nhiên, phần mềm do công ty STT sản xuất ra liệu có đạt yêu cầu về chất
lượng và có đáp ứng được đúng theo yêu cầu của khách hàng cũng như việc phát
sinh ra lỗi khi khách hàng đưa vào sử dụng các sản phẩm do công ty này sản xuất.
Chính vì lý do này mà phải tiến hành kiểm thử phần mềm.

3. 3
v1.1013109225
MỤC TIÊU
Trình bày được khái niệm kiểm thử phần mềm;
Mô tả các kỹ thuật thiết kế kiểm thử phần mềm;
Trình bày các phương pháp kiểm thử phần mềm;
Trình bày các chiến lược kiểm thử phần mềm;
Trình bày được các cấp độ kiểm thử phần mềm;
Xây dựng một ứng dụng có sử dụng một trong các phương pháp, kỹ thuật,
chiến lược kiểm thử.

4. 4
v1.1013109225
NỘI DUNG
Khái niệm kiểm thử phần mềm
1
Các phương pháp kiểm thử
2
Các kỹ thuật thiết kế kiểm thử
3
Các chiến lược kiểm thử
4
Các cấp độ của việc kiểm thử phần mềm
5

5. 5
v1.1013109225
1. KHÁI NIỆM KIỂM THỬ PHẦN MỀM
1.1. Khái niệm
1.2. Vòng đời kiểm thử phần mềm
1.3. Phân loại kiểm thử

6. 6
v1.1013109225
1.1. CÁC ĐỊNH NGHĨA
• Kiểm thử (testing) là quá trình thực thi một chương trình với mục đích là tìm ra lỗi
(Glen Myers);
• Việc kiểm thử là nói đến các lỗi, sai sót, hỏng hóc hoặc các hậu quả. Một phép kiểm
thử là cách chạy phần mềm theo các trường hợp kiểm thử với mục tiêu tìm ra sai sót
và giải thích sự hoạt động chính xác (Paul Jorgensen);
• Kiểm thử thành công là phát hiện ra lỗi; kiểm thử không phát hiện ra lỗi là kiểm thử
dở (Sue A.Conger- The New SE);
• Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những
điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó
của hệ thống hay thành phần đó. (Theo Bảng chú giải thuật ngữ chuẩn IEEE của
Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary of Software Engineering
Terminology);
• Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiến trình
hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện
theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không
mong muốn. Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho
người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu
đặt ra hay chưa?

7. 7
v1.1013109225
Lưu ý khi tiến hành kiểm thử:
• Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu, chứ không phải
khâu kiểm thử;
• Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình;
• Người kiểm thử và người phát triển nên khác nhau;
• Dữ liệu thử cho kết quả bình thường thì không có ý nghĩa nhiều, cần có những dữ
liệu kiểm thử mà phát hiện ra lỗi;
• Khi thiết kế trường hợp thử, không chỉ dữ liệu kiểm thử nhập vào, mà phải thiết kế
trước cả dữ liệu kết quả sẽ có;
• Khi phát sinh thêm trường hợp thử thì nên thử lại những trường hợp thử trước đó
để tránh ảnh hưởng lan truyền sóng.
1.1. CÁC ĐỊNH NGHĨA (tiếp theo)

8. 8
v1.1013109225
Tương ứng giữa vòng đời dự án và kiểm thử
1.2. VÒNG ĐỜI CỦA KIỂM THỬ - TESTING LIFE CYCLE
Đối tượng và phạm vi
Đặc tả chức năng/
Thiết kế lô gíc
Thiết kế Vật lý
Cấu trúc chương trình
và đặc tả môđun
Mã hoá
môđun chương trình
Kiểm thử chấp nhận
Kiểm thử hệ thống
Kiểm tích hợp
Kiểm đơn vị
Kiểm
hồi quy

9. 9
v1.1013109225
1.2. VÒNG ĐỜI CỦA KIỂM THỬ - TESTING LIFE CYCLE (tiếp theo)
Mô tả yêu cầu
Thiết kế
Lập trình
Kiểm nghiệm
Phân loại lỗi
Cô lập lỗi
Giải pháp sửa lỗi
Sửa lỗi
Lỗi
Lỗi
Lỗi
Sai sót
Sai sót
Sai sót Hậu quả

10. 10
v1.1013109225
1.3. PHÂN LOẠI KIỂM THỬ
• Theo mức độ chi tiết của các bộ phận hợp thành phần mềm:
 Kiểm thử đơn vị (Unit);
 Kiểm thử hệ thống (System);
 Kiểm thử tích hợp (Integration).
• Theo phương pháp kiểm thử:
 Kiểm thử hộp đen: Kiểm thử chức năng;
 Kiểm thử hộp trắng: Kiểm thử cấu trúc.

11. 11
v1.1013109225
1.3.1. MÔ HÌNH CHỮ V
Các mức kiểm thử
Phân tích
yêu cầu
Đặc tả
phần mềm
Thiết kế
kiến trúc
Thiết kế
chi tiết
Lập trình
Test
chấp nhận
Test
hệ thống
Test
tích hợp
Test đơn vị
Rà soát mã

12. 12
v1.1013109225
1.3.1. MÔ HÌNH CHỮ V
• Mô hình chữ V biểu diễn sự tương quan giữa các công đoạn xây dựng phần mềm và
loại kiểm thử phần mềm. Bên trái chữ V là quá trình phát triển phần mềm và bên phải
là kiểm thử. Tại mỗi một mức trong tiến trình phát triển thì có một pha kiểm thử
tương ứng;
• Các mức kiểm thử có thể được lập kế hoạch và thiết kế song song. Sau đó chúng ta
thực hiện kiểm thử từ đáy tháp chữ V nên tương ứng với từng mức phát triển. Kế
hoạch kiểm thử hệ thống cần phải sớm hơn khi trước khi pha kiểm thử bắt đầu:
 Kế hoạch kiểm thử hệ thống là phải khớp với các yêu cầu phần mềm;
 Các trường hợp kiểm thử cần phải hoàn thành khi các thiết kế chi tiết đã xong;
 Kiểm thử hệ thống bắt đầu từ ngay trước khi lập trình.

13. 13
v1.1013109225
1.3.2. TIẾN TRÌNH KIỂM THỬ
Kiểm thử
đơn vị
Kiểm thử
tích hợp
Kiểm thử
hệ thống
Kiểm thử
chấp nhận
Mỗi module Nhiều module,
hệ con
Phần cứng,
phần mềm,
yêu cầu hệ thống
Yêu cầu
người dùng,
hệ thống

14. 14
v1.1013109225
2. CÁC PHƯƠNG PHÁP KIỂM THỬ
2.1. Kiểm thử tĩnh (Static testing)
2.2. Kiểm thử động (Dynamic testing)

15. 15
v1.1013109225
2.1. KIỂM THỬ TĨNH – KIỂM THỬ TRÊN BÀN
• Khái niệm: Là phương pháp kiểm thử phần mềm đòi hỏi xem xét lại thông
qua việc sử dụng giấy, bút để kiểm tra lần từng chi tiết mà không cần chạy
chương trình.
• Các phương pháp kiểm thử tĩnh:
 Thanh tra (Inspection);
 Đi xuyên suốt (Walkthrough) hay duyệt.

16. 16
v1.1013109225
• Khái niệm: Là phương pháp kiểm tra ngang hàng sản phẩm phần mềm thực hiện bởi
những người nghiên cứu riêng lẻ để tìm ra những lỗi có thể bằng một tiến trình chuẩn
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;  Tác giả phần mềm.
2.1.1. KIỂM THỬ TĨNH BẰNG PHƯƠNG PHÁP THANH TRA
• Tiến trình thanh tra
 Lên kế hoạch;
 Gặp gỡ trước;
 Chuẩn bị;
 Gặp gỡ thanh tra;
 Gia công lại;
 Bám sát.

17. 17
v1.1013109225
• 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.
2.1.2. KIỂM THỬ TĨNH BẰNG PHƯƠNG PHÁP DUYỆT
• Tiến trình duyệt:
 Đánh giá đầu vào;
 Chuẩn bị quản lí;
 Lập kế hoạch;
 Gặp gỡ trước;
 Chuẩn bị riêng;
 Duyệt;
 Gia công/ bám sát;
 Kết thúc, đánh giá.

18. 18
v1.1013109225
• Khái niệm: Phương pháp kiểm thử phần mềm thông qua việc dùng máy chạy
chương trình để điều tra trạng thái tác động của chương trình.
• Các phương pháp kiểm thử động:
 Kiểm thử khuyết tật;
 Kiểm thử thống kê.
2.2. KIỂM THỬ ĐỘNG – KIỂM THỬ TRÊN MÁY
• Đặc điểm của kiểm thử động:
 Các ca kiểm thử xác định bằng sự thực thi của đối tượng kiểm thử hay
chạy các chương trình;
 Kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự
phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian;
 Phần mềm phải thực sự được biên dịch và chạy;
 Làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu
đầu ra có như mong muốn hay không.

19. 19
v1.1013109225
Tiến trình kiểm thử động:
1. Thiết kế trường hợp thử theo thử tĩnh;
2. Trường hợp thử phải có cả kết quả kì vọng sẽ thu được;
3. Dịch chương trình nguồn và tạo modul tải để thử;
4. Xác định miền vào ra của tệp nếu cần thiết;
5. Nhập dữ liệu đã thiết kế cho truờng hợp thử;
6. Điều chỉnh môi trường thực hiện modul tải;
7. Thực hiện modul tải và ghi nhận kết quả;
8. Xác nhận kết quả với kết quả kỳ vọng;
9. Lặp lại thao tác từ 5-8.
2.2. KIỂM THỬ ĐỘNG – KIỂM THỬ TRÊN MÁY (tiếp theo)

20. 20
v1.1013109225
• Khái niệm:
 Phương pháp thử để tìm ra khuyết tật của phần mềm chủ yếu là lỗi lập trình;
 Tiến hành dựa trên phân tích đặc tả chức năng;
 Phân tích mã nguồn.
• Các loại thử nghiệm khuyết tật:
 Thử nghiệm chức năng;
 Thử nghiệm cấu trúc.
2.2.1. KIỂM THỬ ĐỘNG BẰNG THỬ NGHIỆM KHUYẾT TẬT

21. 21
v1.1013109225
Khái niệm:
• Phương pháp thử bằng cách đánh giá tính dùng được của sản phẩm sử dụng dữ liệu
thực dựa trên thống kê của số người truy cập hoặc số thao tác;
• Phương pháp này có bộ cơ sở dữ liệu thống kê rất lớn.
2.2.2. KIỂM THỬ ĐỘNG BẰNG THỬ NGHIỆM THỐNG KÊ

22. 22
v1.1013109225
3. CÁC KỸ THUẬT THIẾT KẾ KIỂM THỬ
3.1. Kiểm thử hộp trắng
3.2. Kiểm thử hộp đen

23. 23
v1.1013109225
3.1. KIỂM THỬ HỘP TRẮNG (WHITE BOX TESTING)
Khái niệm:
• Kiểm thử hộp trắng là kiểm thử dựa vào cấu
trúc/mã lệnh chương trình (trong trường
hợp này yêu cầu người kiểm thử phải biết
ngôn ngữ lập trình);
• Đây là kỹ thuật thiết kế trường hợp thử dựa
trên đặc tả bên trong của chương trình.
Results
Input


 
White Box Data Testing Strategy
Kiểm thử hộp trắng để kiểm thử cái gì?
Các lệnh trong chương trình
Các điều kiện logic
Các chu trình lặp lại
Cấu trúc dữ liệu
Các luồng điều khiển



24. 24
v1.1013109225
3.1.1. YÊU CẦU VÀ CÁC KỸ THUẬT VỚI KIỂM THỬ HỘP TRẮNG
• Yêu cầu đối với kiểm thử hộp trắng:
 Những con đường độc lập trong modul được thực hiện ít nhất một lần;
 Những điều kiện logic được thực hiện với cả hai giá trị “True” và “False”;
 Các chu trình đều phải thực hiện trong nội dung vòng lặp và khi đặt trong hoạt
động của hệ thống;
 Thực thi mọi cấu trúc dữ liệu để đảm bảo hiêu lực thi hàng của nó;
 Thực thi các luồng điều khiển theo một tiến trình từ đầu cho đến khi kết thúc;
 Thực hiện tất cả các vòng lặp ở biên của nó và cả với biên vận hành của nó;
 Áp dụng giai đoạn đầu của vòng kiểm thử.
• Các kỹ thuật sử dụng với kiểm thử hộp trắng:
 Các câu lệnh (Statement);
 Đường dẫn (Path);
 Các điều kiện (Condition);
 Vòng lặp (Loop);
 Ngã rẽ (Branch).

25. 25
v1.1013109225
3.1.2. KIỂM THỬ HỘP TRẮNG VỚI CÁC CÂU LỆNH
• Khái niệm: Là việc thiết kế các trường hợp kiểm thử một chương trình, một phần
chương trình, một hệ thống hay một phần của hệ thống dựa vào cấu trúc/mã lệnh
chương trình xem nó có đáp ứng tốt tất cả các giá trị đầu vào theo yêu cầu của
chương trình;
• Các câu lệnh của chương trình phải được thực hiện ít nhất một lần.

26. 26
v1.1013109225
3.1.3. KIỂM THỬ HỘP TRẮNG THEO ĐƯỜNG DẪN
• Khái niệm: Là phương pháp kiểm tra bao trùm mọi đường dẫn của chương trình và
cần kết hợp với lược đồ tiến trình.
• Đặc điểm:
 Phụ thuộc nhiều vào các biểu thức điều kiện;
 Với những trường hợp có số lượng đường dẫn quá lớn thì không nên sử dụng
phương pháp này để kiểm tra tính đúng đắn của chương trình.

27. 27
v1.1013109225
VÍ DỤ
If (A>B)
{ S1;
S2;
}
else
S3;
S4;
while(A>B)
{
S1;
S2;
}
S3;
A>B
A>B
A>B
A>B
S3;
S1;S2;
S4;
True False

28. 28
v1.1013109225
3.1.4. KIỂM THỬ HỘP TRẮNG THEO ĐIỀU KIỆN
• Khái niệm: Là phương pháp kiểm tra các biểu thức điều kiện trên hai giá trị true
và false;
• Đặc điểm: Cần xem xét kết hợp các điều kiện với nhau;
• Ví dụ:
if (x>0 && y>0)
x = 1;
else
x = 2;
Các bộ kiểm tra { (x>0, y>0), (x<=0, y>0) } sẽ kiểm tra toàn bộ các điều kiện;
Tuy nhiên: Không thỏa mãn với mọi giá trị input, cần kết hợp cả x và y để thực hiện
bước kiểm tra.

29. 29
v1.1013109225
3.1.5. KIỂM THỬ HỘP TRẮNG THEO VÒNG LẶP
• Khái niệm: Là phương pháp tập trung vào tính hợp lệ của các cấu trúc vòng lặp.
• Có các loại kiểm tra vòng lặp:
 Vòng lặp đơn giản;
 Vòng lặp lồng nhau;
 Vòng lặp nối tiếp nhau;
 Vòng lặp không cấu trúc.
Vòng lặp đơn giản Vòng lặp lồng nhau Vòng lặp
nối tiếp nhau
Vòng lặp
không cấu trúc

30. 30
v1.1013109225
3.2. KIẾM THỬ HỘP ĐEN – BLACK BOX TESTING
Khái niệm:
• Là hình thức kiểm thử mà kiểm thử viên không cần biết đến cách thức hoạt động, mã
nguồn, xử lý dữ liệu bên trong một thành phần/hệ thống. Công việc cần làm là nhập
dữ liệu đầu vào và kiểm tra kết quả trả về có đúng như mong muốn hay không;
• Còn được gọi là kiểm thử chức năng;
• Là phương pháp tập trung về mặt yêu cầu chức năng của sản phẩm;
• Có thể tạo ra một bộ các điều kiện đầu vào để kiểm thử tất cả.
Black Box
Results
Input
Kiểm thử hộp đen

31. 31
v1.1013109225
3.2.1. MÔ HÌNH KIỂM THỬ HỘP ĐEN
Mô hình kiểm thử hộp đen
Danh
sách
chức
năng
Dữ
liệu
đầu
vào
Đầu ra liên quan

32. 32
v1.1013109225
3.2.2. ĐẶC ĐIỂM VÀ MỤC ĐÍCH CỦA KIỂM THỬ HỘP ĐEN
• Đặc điểm của kiểm thử hộp đen:
 Bổ xung cho phương pháp kiểm thử hộp trắng để phát hiện ra tất cả các lỗi khác
nhau mà kiểm thử hộp trắng không phát hiện ra được;
 Không cần quan tâm đến thiết kế, mã nguồn mà chỉ quan tâm đến chức năng đã
đề ra của chương trình;
 Chỉ dựa vào bản mô tả chức năng của chương trình;
 Hướng vào các đặc tả bên ngoài;
 Chủ yếu là kiểm tra giao diện;
 Áp dụng vào giai đoạn sau của vòng kiểm thử.
• Mục đích của kiểm thử hộp đen: Tìm các loại sai liên quan đến:
 Chức năng: Đủ, đúng đắn;
 Giao diện vào, ra: Đủ, phù hợp đúng và tiện lợi;
 Cấu trúc truy cập dữ liệu: Thông suốt, đúng đắn;
 Thực thi trôi chảy, kịp thời, chịu lỗi phục hồi;
 Khởi đầu, kết thúc mỗi quá trình thông suốt.

33. 33
v1.1013109225
3.2.3. CÁC KỸ THUẬT THƯỜNG DÙNG CHO KIỂM THỬ HỘP ĐEN
• Phân chia tương đương - Equivalence Partition Testing;
• Phân tích giá trị biên - Boundary Value Analysis Testing;
• Đồ thị Cause-Effect - Cause-effect Graphing Testing;
• Kiểm tra hành vi – Behavioural Testing;
• Ước lượng lỗi - Error Guessing Testing;
• Kiểm thử mọi cặp – All-pairs Testing;
• Kiểm thử fuzz – Fuzz Testing;
• Kiểm thử dựa trên mô hình – Model Based Testing;
• Ma trận dấu vết – Traceability Matrix Testing;
• Kiểm thử thăm dò – Exploratory Testing;
• Kiểm thử dựa trên đặc tả – Specification-base Testing.

34. 34
v1.1013109225
KIỂM THỬ HỘP ĐEN THEO PHÂN CHIA TƯƠNG ĐƯƠNG
(EQUIVALENCE PARTITION)
• Là loại kiểm thử chia miền dữ liệu vào của chương trình thành các lớp dữ liệu đầu vào
đại diện để lập ra các ca kiểm thử theo mỗi lớp đó. Phân hoạch tương đương cố gắng
xác định các ca kiểm thử mà không bao phủ các lớp lỗi, do đó giảm tổng số các kiểm
thử sẽ được phát triển.
• Thực hiện:
 Chia dữ liệu vào thành các đoạn có cùng hành vi;
 Mỗi đoạn lấy đại diện một số dữ liệu;
 Kiểm thử chỉ thực hiện trên đại diện đó;
 Nếu giá trị đại diện bị lỗi thì các thành phần còn lại cũng lỗi.
• Ưu điểm: Test theo mức trừu tượng nên giảm số lượng test;
• Nhược điểm: Không thể tiến hành kiểm thử mọi trường hợp nên có thể sót lỗi.

35. 35
v1.1013109225
VÍ DỤ
• Công ty STT viết chương trình trong đó có một hàm tính giá trị tuyệt đối của
một số nguyên. Hãy kiểm thử xem hàm này có thực hiện đúng hay không
bằng phương pháp kiểm thử hộp đen theo phân chia tương đương.
• Thực hiện: Chia các dữ liệu đầu vào thành hai lớp:
 Cách chia 1:
 Lớp hợp lệ là lớp có loại dữ liệu số nguyên đại diện đầu vào và ra
yêu cầu là (2/2);
 Lớp không hợp lệ là lớp có loại dữ liệu số không nguyên: đại diện
đầu vào và ra yêu cầu là (2,5/2,5).
 Cách chia 2:
 Lớp hợp lệ là lớp có loại dữ liệu số dương: Đại diện đầu vào và ra
yêu cầu là (2/2);
 Lớp không hợp lệ là lớp có loại dữ liệu số âm: Đại diện đầu vào và ra
yêu cầu là (-5/-5).

36. 36
v1.1013109225
KIỂM THỬ HỘP ĐEN THEO PHÂN TÍCH GIÁ TRỊ BIÊN - BVA
(BOUNDARY VALUE TESTING)
• BVA là kỹ thuật kiểm thử bổ sung thêm cho phân hoạch tương đương, nó dựa trên
giá trị biên của vùng dữ liệu hợp lệ;
• Thay vì chọn bất cứ phần tử nào của lớp tương đương, BVA chọn các ca kiểm thử
sát với lớp tương đương;
• Thay vì tập trung vào điều kiện vào, BVA còn đưa ra các ca kiểm thử từ miền ra;
• BVA cho rằng số lớn các sai xuất hiện ở biên nhiều hơn là vùng dữ liệu trung tâm.
Không những chú ý đến dữ liệu trong và sát biên mà còn chú ý đến dữ liệu ngoài
và sát biên;
• Thực hiện:
 Phân đoạn tương tương tập các giá trị dữ liệu vào thành các lớp;
 Chọn các giá trị ở biên của mỗi lớp;
 Chọn các giá trị trên và dưới của biên.

37. 37
v1.1013109225
VÍ DỤ
• Một trường dữ liệu có định dạng dữ liệu số nguyên là 3. Tức là chỉ chấp nhận các giá
trị nguyên, lớn hơn hoặc bằng 0, và nhỏ hơn hoặc bằng 999 (0<= x <=999);
• Các giá trị biên là 0 và 999;
• Kiểm thử theo giá trị biên nhằm đảm bảo hệ thống chỉ chấp nhận các giá trị x lớn hơn
hoặc bằng 0 và nhỏ hơn hoặc bằng 999 mà không chấp nhận các giá trị nhỏ hơn 0
hoặc lớn hơn 999.

38. 38
v1.1013109225
3.1.2. KIỂM THỬ HỘP TRẮNG VỚI CÁC CÂU LỆNH (tiếp theo)
Các bước kiểm thử hộp trắng với các câu lệ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ị V(G) 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 độc lập tuyến tính ở trên.

39. 39
v1.1013109225
ĐƯỜNG ĐỘC LẬP TUYẾN TÍNH
• Để đảm bảo các câu lệnh đều được kiểm thử ít nhất một lần, ta cần tìm tất cả các
đường điều khiển độc lập trong chương trình, tức là mỗi đường khác với các đường
khác ít nhất một lệnh;
• Số các của một chương trình là giới hạn trên của số các kiểm thử cần phải tiến hành.
Nó được gọi là độ phức tạp chu trình của chương trình;
• Một tập cơ bản con đường độc lập là tập:
 Mọi cạnh của đồ thị dòng đều có mặt trong một con đường của tập này;
 Mỗi con đường của tập đó đều chứa ít nhất một cung không có mặt trong mọi
con đường khác của nó;
 Số lượng các con đường của tập này cho ta số đo độ phức tạp chu trình của một
chương trình.

40. 40
v1.1013109225
ĐÁNH GIÁ ĐỘ PHỨC TẠP CỦA ĐỒ THỊ DÒNG
Đánh giá độ phức tạp của đồ thị dòng: Độ phức tạp chu trình V(G) đối với 1 đồ thị dòng
G được định nghĩa là:
V(G) = Số miền phẳng;
V(G) = E - N + 2;
V(G) = P + 1.
Trong đó: E là số cạnh;
N là số nút của đồ thị dòng;
P là số nút vị từ.
V(G) cung cấp số các đường đi độc lập trong một chương trình và nó được coi là cận
trên của số lượng kiểm thử phải tiến hành để đảm bảo mỗi lệnh đều được thực hiện ít
nhất một lần.

41. 41
v1.1013109225
CÁC ĐƯỜNG CƠ BẢN CỦA ĐỒ THỊ DÒNG
• Đồ thị dòng (đồ thị chương trình) gần giống dòng điều khiển.
• Nó là một đồ thị cấu trúc gồm:
 Mỗi nút (hình tròn) biểu thị một số (hoặc có thể là 0) câu lệnh thủ tục;
 Mỗi cạnh nối hai nút biểu diễn dòng điều khiển;
 Chia mặt phẳng thành nhiều miền;
 Một nút là vị từ nếu nó biểu thị sự phân nhánh hoặc hội nhập của cung.
• Đồ thị dòng dùng để biểu diễn thiết kế thủ tục.
if case
while
Tuần tự until

42. 42
v1.1013109225
VÍ DỤ 1
1 float foo(int a, int b, int c, int d)
{
2 float e;
3 if (a==0)
4 return 0;
5 int x = 0;
6 if ((a==b) || ((c==d) && bug(a)))
7 x = 1;
8 e = 1/x;
9 return e;
10 }
s1
c1
s2
c2
s3
s4
s5

43. 43
v1.1013109225
VÍ DỤ 2
double average(double value[], double min, double max,
int& tcnt, int& vcnt) {
double sum = 0;
int i = 1;
tcnt = vcnt = 0;
while (value[i] <> -999 && tcnt <100) {
tcnt++;
if (min<=value[i] && value[i] <= max)
sum += value[i];
vcnt ++;
}
i++;
}
if (vcnt > 0) return sum/vcnt;
return -999;
}
9
10
11
12
4 6
7
8
2
1
5
1
2
3
4
5
6
7
8
9
10
11 12

44. 44
v1.1013109225
VÍ DỤ 2 (tiếp theo)
Đồ thị bên có 5 nút quyết định nhị phân nên có độ
phức tạp C = 5 +1 = 6. 6 đường thi hành tuyến tính
độc lập là :
• 1 2 10 11
• 1 2 3 10 11
• 1 2 10 12
• 1 2 3 4 5 8 9
• 1 2 3 4 5 6 8 9
• 1 2 3 4 5 6 7 8 9
1
2
3
4
5
6
7
8
9
10
11 12

45. 45
v1.1013109225
VÍ DỤ 2 (tiếp theo)
• Test case cho đường 1 2 10 11:
 value(k) <>-999, với 1< k < i;
 value(i) = -999 với 2 ≤ i ≤ 100;
 Kết quả kỳ vọng: (1) average = Giá trị trung bình của k giá trị hợp lệ.
(2) tcnt = k. (3) vcnt = k;
 Chú ý: không thể kiểm thử đường 1 này riêng biệt mà phải khiểm thử
chung với đường 4 hay 5 hay 6.
• Test case cho đường 1 2 3 10 11:
 value(k) <>-999, với k < i , i >100;
 Kết quả kỳ vọng: (1) average = Giá trị trung bình của 100 giá trị hợp lệ.
(2) tcnt = 100. (3) vcnt = 100.
• Test case cho đường 1 2 10 12:
 value(1) = -999;
 Kết quả kỳ vọng: (1) average = -999. (2) tcnt = 0. (3) vcnt = 0;

46. 46
v1.1013109225
VÍ DỤ 2 (tiếp theo)
• Test case cho đường 1 2 3 4 5 8 9:
 value(i) <> -999 i <= 100;
 và value(k) < min với k < I;
 Kết quả kỳ vọng: (1) average = Giá trị trung bình của n giá trị hợp lệ.
(2) tcnt = 100. (3) vcnt = n (số lượng giá trị hợp lệ).
• Test case cho đường 1 2 3 4 5 6 8 9:
 value(i) <>-999 với i <= 100
 và value(k) > max với k <= i
 Kết quả kỳ vọng: (1) average = Giá trị trung bình của n giá trị hợp lệ.
(2) tcnt = 100. (3) vcnt = n (số lượng giá trị hợp lệ).
• Test case cho đường 1 2 3 4 5 6 7 8 9:
 value(i) <>-999 và min <= value(i) <= max với i <= 100
 Kết quả kỳ vọng: (1) average = Giá trị trung bình của 100 giá trị
hợp lệ. (2) tcnt = 100. (3) vcnt = 100.

47. 47
v1.1013109225
KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT
(CAUSE-EFFECT GRAPHING)
• Là kỹ thuật kiểm thử phân tích việc kết hợp các điều kiện vào, tạo một đồ thị kết nối
nguyên nhân – kết quả (cause-effect). Trong đó, nguyên nhân (cause) là đầu vào và
kết quả (effect) là đầu ra.
• Các bước tiến hành:
 Lập danh sách các nguyên nhân (điều kiện vào) và kết quả (hành động) cho từng
môđun và gán giá trị định danh cho chúng;
 Phát triển đồ thị nhân quả;
 Chuyển đồ thị đó thành bảng quyết định;
 Sử dụng các quy luật của bảng quyết định để xây dựng các ca kiểm thử.

48. 48
v1.1013109225
KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT
(CAUSE-EFFECT GRAPHING)
a b
a b
c
a b
a b
c
a b
a
b
a b
a b
Các ký hiệu trong đồ thị nhân quả

49. 49
v1.1013109225
KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT (CAUSE-EFFECT
GRAPHING)
yêu cầu
Yêu cầu
7
bao hàm
Bao hàm
6
Nếu đúng, thì sai, hoặc nếu sai,
thì đúng.
Loại trừ
5
Nếu sai, thì đúng.
NOT (phủ định)
4
Nếu đúng hoặc đúng, thì đúng.
OR (hoặc)
3
Nếu đúng và đúng, thì đúng.
AND (và)
2
Nếu đúng thì đúng.
Tương đương
1
Giải thích
Ý nghĩa
Ký hiệu
STT

50. 50
v1.1013109225
VÍ DỤ KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT
Có modun chương trình tính thuế thu nhập, có mô tả sau:
• Người vô gia cư nộp 4% thuế thu nhập;
• Người có nhà ở nộp thuế như sau:
 Tổng thu nhập <= 5.000.000 đồng thì nộp thuế 4%;
 Tổng thu nhập > 5.000.000 đồng thì nộp thuế 6%.
Nộp 4% thuế
Nộp 6% thuế
Người có nhà ở:
Tổng thu nhập <= 5.000.000 đồng
Tổng thu nhập > 5.000.000 đồng
Kết quả
Nguyên nhân
Bảng quan hệ nguyên nhân và kết quả

51. 51
v1.1013109225
VÍ DỤ KIỂM THỬ HỘP ĐEN THEO ĐỒ THỊ CAUSE-EFFECT
Đồ thị nguyên nhân và kết quả
Nộp thuế 6%
Nộp thuế 4%
Có tổng thu nhập > 5.000.000
Có tổng thu nhập <= 5.000.000
Người có nhà ở
X
--
Y
N
Y
1
--
X
N
Y
Y
2
--
--
X
X
Kết
quả
--
--
Y
--
--
N
Nguyên
nhân
4
3
Trường hợp kiểm thử
Nguyên nhân và kết quả

52. 52
v1.1013109225
4. CÁC CHIẾN LƯỢC KIỂM THỬ
4.1. Kiểm thử trên xuống (Top-down Test)
4.2. Kiểm thử từ dưới lên (Bottom-up Test)
4.3. Kiểm thử cột trụ (Big bang Test)
4.5. Kiểm thử kẹp (Sandwich Test)

53. 53
v1.1013109225
4.1. KIỂM THỬ TỪ TRÊN XUỐNG DƯỚI – TOP-DOWN TEST
• Môđun điều khiển chính được dùng như trình điều khiển kiểm thử chính, gắn dần các
mô đun từ trên xuống theo trật tự dòng điều khiển. Bắt đầu từ mô đun điều khiển
chính, sau đó gắn từng mô đun phụ trợ vào mô đun điều khiển thượng cấp. Có thể
theo hai cách:
 Theo chiều sâu trước;
 Theo chiều rông trước.
• Kiểm thử được tiến hành khi từng môđun được tích hợp vào hệ thống. Các nút thử
xong thì thử tiếp nút khác;
• Cần có các cuống kéo theo những khó khăn dành cho cuống, có ngay chức năng điều
khiển hệ thống.

54. 54
v1.1013109225
TIẾN TRÌNH KIỂM THỬ TỪ TRÊN XUỐNG
Tiến trình này gồm 6 bước như sau:
• Mô đun điều khiển chính được dung như bộ lái kiểm thử (Test Driver) và tất cả các
mô đun phụ trợ trực tiếp được thay thế bởi các cuống (Stub);
• Thay thế dần từng cuống bằng các mô đun thực thi tương ứng;
• Sau khi tích hợp mô đun đó, tiến hành kiểm thử tương ứng;
• Khi hoàn thành kiểm thử này thì thay thế một cuống khác bằng mô đun thực
(nghĩa là quay lại bước 2);
• Có thể kiểm thử lại (toàn bộ hoặc 1 phần các kiểm thử trước - kiểm thử hồi quy)
để đảm bảo không có sai mới nào sinh ra;
• Tiếp tục lặp lại bước hai cho đến khi toàn bộ chương trình cấu trúc được xây dựng.
Sơ đồ ví dụ kiểm thử từ trên xuống
Hệ cần kiểm thử
Kết hợp
theo chiều rộng
Kết hợp
theo chiều sâu

55. 55
v1.1013109225
4.2. KIỂM THỬ TỪ DƯỚI LÊN (BOTTOM-UP TEST)
• Bắt đầu xây dựng kiểm thử từ các mô đun nguyên tố;
• Việc xử lý nếu có đòi hỏi các mô đun phụ trợ thì các mô đun chính đã sẵn sàng
(cuống đã bị loại);
• Luôn chưa có chương trình chỉnh thể, thiết kế các ca kiểm thử dễ không cần cuống;
• Thực hiện theo 4 bước:
 Các mô đun mức thấp được tích hợp thành các cụm thực hiện một chức năng
phụ trợ nhất định;
 Một bộ lái được viết để phối hợp đầu vào và đầu ra của các ca kiểm thử;
 Kiểm thử cụm đó;
 Tháo bỏ các Driver và các cụm tổ hợp ngược lên trong cầu trúc chương trình.

56. 56
v1.1013109225
VÍ DỤ
Vòng 1 Vòng 2 Vòng 3

57. 57
v1.1013109225
4.3. KIỂM THỬ CỘT TRỤ (BIG BANG TEST)
• Tích hợp không tăng dần;
• Tất các các môđun đều được tổ hợp trước;
• Toàn bộ chương trình được kiểm thử tổng thể;
• Khó khăn: Khó cô lập lỗi, khi chữa xong lỗi này có thể lỗi mới lại phát sinh.

58. 58
v1.1013109225
4.4. KIỂM THỬ KẸP (SANDWICH TEST)
Phương pháp kiểm thử hỗn hợp (Sandwich) có thể là phương pháp phù hợp nhất:
• Tích hợp trên xuống cho các mức trên cấu trúc chương trình;
• Tích hợp dưới lên cho các mức phụ thuộc.

59. 59
v1.1013109225
5. CÁC CẤP ĐỘ KIỂM THỬ
5.1. Kiểm thử đơn vị
5.2. Kiểm thử tích hợp
5.3. Kiểm thử hệ thống
5.4. Kiểm thử chấp nhận sản phẩm
5.5. Một số cấp độ kiểm thử khác

60. 60
v1.1013109225
5.1. KIỂM THỬ ĐƠN VỊ (UNIT TESTING)
• Unit Testing là việc kiểm thử ở mức độ thấp nhất là các phương thức (Method), hàm
(Function), lớp (Class) trong mã nguồn. Nhằm đảm bảo các thành phần trên hoạt
động đúng như yêu cầu;
• Việc kiểm tra ở mức độ này thường do chính các lập trình viên (Developer) thực hiện
trong quá trình mã hóa (Coding, Implement);
• Một mô hình thường được ứng dụng với Unit Testing là Phát triển theo định hướng
kiểm thử (Test-Driven Development):
 Các Unit Test viết trước dựa theo yêu cầu kết quả trả về ban đầu là sai (False);
 Mã nguồn sẽ được viết sau và được kiểm tra tự động bằng các Unit Test;
 Việc phát triển được hoàn thành khi các Unit Test trả về kết quả đúng (True).
• Trong ISTQB (phiên bản 2007), khái niệm Unit Testing được hiểu là Component
Testing. Lý do là các công việc trên được thực hiện bởi lập trình viên. Các tài liệu trên
phân loại dưới quan điểm của một kiểm thử viên.

61. 61
v1.1013109225
ĐẶC ĐIỂM CỦA KIỂM THỬ ĐƠN VỊ (UNIT TEST)
• Người tiến hành kiểm thử thông thường là người lập trình mô đun đó hoặc
lập trình viên cùng nhóm;
• Kiểm thử riêng biệt từng đơn vị phần mềm;
• Số lượng nhiều nhưng đơn giản;
• Xuyên suốt thời gian lập trình và cả chu kỳ phần mềm;
• Kiểm thử Unit là mức thấp nhất trong tiến trình kiểm thử, thường là áp dụng
phương pháp kiểm thử hộp trắng;
• Thường là được thực hiện bới nhà phát triển trước khi các môđun được tích
hợp với các mô đun khác;
• Kết quả của kiểm thử Unit thường tìm ra khoảng 20% lỗi trong tất cả cá lỗi
của dự án.

62. 62
v1.1013109225
PHƯƠNG PHÁP GÌ ĐƯỢC ÁP DỤNG CHO KIỂM THỬ ĐƠN VỊ
• Nó kiểm thử các phần sau:
 Thử nghiệm giao diện;
 Khám nghiện cấu trúc dữ liệu cục bộ;
 Thử nghiệm với các điều kiện biên;
 Các đường độc lập;
 Các đường xử lý sai.
• Kiểm thử đơn vị sử dụng các kỹ thuật:
 Kiểm thử đường cơ sở;
 Kiểm thử vòng lặp;
 Kiểm thử biên.

63. 63
v1.1013109225
5.2. KIỂM THỬ TÍCH HỢP
• Kiểm thử Tích hợp (Intergration Testing): Là một kỹ thuật có tính hệ thống để
xây dựng cấu trúc chương trình ngay khi đang tiến hành kiểm thử để phát hiện
sai liên kết với giao diện.
• Phải kiểm thử tích hợp vì:
 Dữ liệu có thể bị mất khi đi qua một giao diện;
 Một mođun có thehẻ có một hiệu ứng bất lợi vô tình lên các môđun khác;
 Các chức năng phụ khi kết hợp lại có thể không sinh ra chức năng chính
mong muốn;
 Các điều không chính xác riêng rẽ có thể bị phóng đại đến mức không chấp
nhận được;
 Các cấu trúc dữ liệu toàn cục có thể để lộ ra các vấn đề…
• Phương pháp được áp dụng cho kiểm thử tích hợp
 Phương pháp “big-bang”;
 Phương pháp trên xuống;
 Phương pháp dưới lên.

64. 64
v1.1013109225
5.3. KIỂM THỬ HỆ THỐNG
Kiểm thử hệ thống (System Testing):
• Là mức độ kiểm thử toàn bộ các chức năng của hệ thống phần mềm. Bao gồm tất cả
các thành phần tương tác với nhau, và hoạt động trong môi trường giống như môi
trường thực tế như hệ điều hành, cơ sở dữ liệu, kết nối mạng, khả năng tương thích
với các phần mềm khác, …
• Kiểm thử hệ thống cũng chú ý đến vấn đề bảo mật, thân thiện, khả năng đáp ứng,
tốc độ thực hiện của hệ thống phần mềm.

65. 65
v1.1013109225
5.4. KIỂM THỬ CHẤP NHẬN SẢN PHẨM
Kiểm thử chấp nhận (Acceptance Testing, User Acceptance Testing):
• Mức độ này được thực hiện bởi phía người dùng với một nhóm độc lập với nhóm
phát triển. Mục đích của giai đoạn này là kiểm tra, đánh giá phần mềm có đáp ứng
được các yêu cầu của người dùng đã đề ra hay không? Có thể triển khai cho công
việc thực tế của người dùng hay không;
• Việc được người dùng chấp nhận sẽ đánh dấu cho sự kết thúc của giai đoạn phát
triển, mở ra giai đoạn triển khai, bảo trì và nâng cấp phần mềm.
• Các loại kiểm thử chấp nhận sản phẩm:
 Kiểm thử Alpha (Alpha Testing):
 Do người dùng thực hiện;
 Trong môi trường được quản lý.
 Kiểm thử Beta (Beta Testing):
 Do người dùng thực hiện;
 Trong môi trường thực.

66. 66
v1.1013109225
5.5. MỘT SỐ CẤP ĐỘ KIỂM THỬ KHÁC
• Kiểm thử hộp xám (Gray-box Testing): Là hình thức “lai” giữa kiểm thử hộp đen và
kiểm thử hộp trắng;
• Kiểm thử bằng tay (Manual Testing): Là kỹ thuật kiểm thử mà các công đoạn được
làm hoàn toàn bằng sức người;
• Kiểm thử tự động (Automation Testing): Là kỹ thuật kiểm thử với các công đoạn được
tự động hóa bởi máy tính thông qua các “đoạn mã kiểm thử” (Test Script)…

67. 67
v1.1013109225
TÓM LƯỢC CUỐI BÀI
• Đã trình bày các khái niệm về kiểm thử, vòng đời của kiểm thử và mối
tương quan giữa quá trình xấy dựng phần mềm và các giai đoạn kiểm thử
phần mềm;
• Đã trình bày được các phương pháp kiểm thử và một số ví dụ tương ứng;
• Đã trình bày được các kỹ thuật kiểm thử và một số vì dụ tương ứng;
• Đã trình bày được các mức độ kiểm thử và một số ví dụ tương ứng