KIỂM THỬ PHẦN MỀM - SOFTWARE TESTING

KỸ THUẬT THIẾT KẾ TEST

Đỗ Thị Thu Trang - FIT.UTEHY

1
CÁC PHƯƠNG PHÁP KIỂM THỬ

2
Static testing

 Static testing (kiểm thử tĩnh): là một hình thức của kiểm
thử phần mềm mà không thực hiện phần mềm. Thông
thường nó không kiểm thử chi tiết mà chủ yếu kiểm tra
tính đúng đắn của code (mã lệnh), thuật toán hay tài
liệu.
 Chủ yếu kiểm tra cú pháp của code và/hoặc review code (kiểm
tra xem code có được viết theo đúng tiêu chuẩn code.
 Ví dụ cách đặt tên hàm tên biến, cách sử dụng hàm chung đã đưa ra
hay chưa) hoặc tài liệu để tìm lỗi bằng cách thủ công (thường LTV
làm).
 Lỗi được phát hiện ở giai đoạn này sửa sẽ ít tốn kém hơn so với
lỗi phát hiện được ở các giai đoạn sau trong các quy trình PTPM.

3
Static testing

4
Static testing

 Informal reviews:
 Các tài liệu được xem xét, nhận xét một cách không chính thức,
nghĩa là không dựa trên một quy định chính thức nào(có tài liệu).
 Walkthough:
 Là phương pháp review giữa những đồng nghiệp với nhau sẽ
phát hiện ra vấn đề và năng lực của từng người để giao nhiệm
vụ (task) phù hợp với từng người.

5
Static testing

 Technical reviews:
 Thực hiện kiểm tra về mặt kỹ thuật. Việc này tiến hành để kiểm
tra xem code được thực hiện theo đúng các thông số kỹ thuật và
tiêu chuẩn hay không.
 Các kế hoạch kiểm tra, chiến lược kiểm thử và các tập lệnh kiểm
tra được xem xét.
 Inspacetion:
 Là phương pháp tìm lỗi ở mã nguồn
 Đảm bảo thực hiện theo bản đặc tả yêu cầu, bản đặc tả hệ thống
 Đảm bảo tính đúng đắn và xử lý logic
 Người thực hiện: Bộ phận phát triển, người có trách nhiệm
(Moderator) và bộ phận QA.

6
Phương pháp kiểm thử luồng điều khiển
- Control Flow
 Các bước thực hiện:
 B1: Từ code của chương trình hoặc từ mô tả thuật toán, xây
dựng đồ thị dòng điều khiển tương ứng.
 B2: Tính độ phức tạp Cyclomatic của đồ thị (=C).
 B3: Xác định C đường thi hành độc lập cơ bản cần kiểm thử.
 B4: Tạo test case tương(Test
ứngtích
chohợp
từng đường thi hành ở trên.
 B5: Thực hiện kiểm thử các test case.
 B6: So sánh kết quả thực tế với kết quả mong đợi.

7
Đồ thị dòng điều khiển

 Các thành phần cơ bản:

 Các cấu trúc điều khiển phổ biến:

8
Đồ thị dòng và cách xác định

 Đồ thị dòng là một kỹ thuật dựa trên cấu trúc điều

khiển của chương trình.
 Nó khá giống đồ thị luồng điều khiển của chương
trình.
 Chúng ta xây dựng đồ thị luồng điều khiển của chương
trình từ việc phân tích mã nguồn.

9
Ví dụ
 Từ đồ thị luồng điều
khiển, ta thu được đồ thị
dòng bằng cách:
 Gộp các lệnh tuần tự, có
nghĩa là gộp các nút mà từ
nút này luôn đi qua nút kia.
 Thay lệnh rẽ
nhánh và điểm kết
thúc của các đường điều
khiển bằng 1 nút vị tự.
 Nút vị tự: là nút rẽ Ví dụ: đồ thị luồng điều khiển
nhánh hoặc nút kết thúc rẽ
nhánh)

10
Ví dụ

11
Ví dụ

 Sau khi biến đổi từ đồ thị

luồng điều khiển, đồ thị
dòng có cấu trúc:
 Mỗi nút (hình tròn) biểu thị
một hay một số lệnh tuần
tự, hoặc thay cho điểm hội
tụ các đường điều khiển.
 Mỗi cạnh nối hai nút biểu
diễn dòng điều khiển.

12
Ví dụ

 Sau khi biến đổi từ đồ thị

luồng điều khiển, đồ thị
dòng có cấu trúc:
 Mỗi nút (hình tròn) biểu thị
một hay một số lệnh tuần
tự, hoặc thay cho điểm hội
tụ các đường điều khiển.
 Mỗi cạnh (cung) nối hai nút
biểu diễn dòng điều khiển.
  9 nút (trong đó 5 nút là vị
tự (mầu đỏ), 11 cung. Chia
mặt phẳng thành 4 miền
(phần đánh số màu xanh)

13
Độ phức tạp Cyclomatic C

 Độ phức tạp Cyclomatic C = V(G) của đồ thị dòng điều

khiển được tính bởi 1 trong 2 công thức sau :
 V(G) = E -N + 2
 E là số cung, N là số nút của đồ thị
 V(G) = P - 1
 Nếu đồ thị chỉ chứa các nút quyết định nhị phân (chỉ có 2 đầu
ra True/False), P số nút quyết định.
 Độ phức tạp Cyclomatic C chính là số đường thực thi
độc lập cơ bản của đoạn CT cần kiểm thử.

14
Độ phức tạp Cyclomatic C

 Ví dụ trên:
 V(G) = E - N + 2 = 11-9+2
=4
 V(G) = P - 1 = 5-1 =4
 V(G) = số miền phẳng = 4

15
Xác định đường cơ sở

 Số đường cơ sở chính là
độ phức tạp đồ thị:
1. 1 > 11
2. 1 > 2,3 > 6 > 7 > 9 > 10 > 1
3. 1 > 2,3 > 6 > 8 > 9 > 10 > 1
4. 1 > 2,3 > 4,5 > 10 > 1

16
Kiểm thử luồng điều khiển

 Trong thực tế, công sức và thời gian để đạt mục tiêu
trên đây là rất lớn, ngay cả trên những đơn vị phần mềm
nhỏ.
 Ví dụ 1:

 Có 1 đường thi hành dài 1000*1000*1000 = 1 tỉ lệnh gọi

doSomethingWith(i,j,k) khác nhau.

19
Kiểm thử luồng điều khiển

 Ví dụ 2: đoạn mã lệnh gồm 32 lệnh if else sau:

 Có 2^32 = 4 tỉ đường thi hành khác nhau.

20
Kiểm thử luồng điều khiển

 TH kiểm thử hết các đường thực thi thì vẫn không thể
phát hiện những đường thực thi cần có nhưng không
được thực hiện.
 Ví dụ:

 TH đường thực thi đã kiểm tra là đúng nhưng vẫn có thể

bị lỗi trong 1 vài TH đặc biệt:

trường hợp b = 0 thì hàm blech bị lỗi.

21
Phủ kiểm thử

 Do đó nên kiểm thử số test case tối thiểu mà kết quả độ

tin cậy tối đa. Nhưng làm sao xác định được số test
case tối thiểu nào có thể đem lại kết quả có độ tin cậy tối
đa ?
Khái niệm Phủ kiểm thử:
 Phủ kiểm thử (Coverage): là tỉ lệ các thành phần thực sự
được kiểm thử so với tổng thể sau khi đã kiểm thử các
test case được chọn. Phủ càng lớn thì độ tin cậy càng
cao.
 Thành phần liên quan có thể là lệnh, điểm quyết định,
điều kiện con, đường thực thi hay sự kết hợp giữa
chúng.
22
Phủ các cấp

 Phủ cấp 0: kiểm thử những gì có thể kiểm thử được,

phần còn lại để người dùng phát hiện và báo lại sau.
Đây là mức độ kiểm thử không thực sự có trách nhiệm.
 Phủ cấp 1: kiểm thử sao cho mỗi lệnh được thực thi ít
nhất 1 lần.
 Phủ cấp 2: kiểm thử sao cho mỗi điểm quyết định đều
được thực hiện ít nhất 1 lần cho trường hợp TRUE lẫn
FALSE. Ta gọi mức kiểm thử này là phủ các nhánh
(Branch coverage). Phủ các nhánh đảm bảo phủ các
lệnh.

23
Phủ các cấp

 Phủ cấp 3: kiểm thử sao cho mỗi điều kiện con
(subcondition) của từng điểm quyết định đều được thực
hiện ít nhất 1 lần cho cả TH TRUE & FALSE. Ta gọi mức
kiểm thử này là phủ các điều kiện con (subcondition
coverage). Phủ các điều kiện con chưa chắc đảm bảo
phủ các nhánh.
 Phủ cấp 4: kiểm thử sao cho mỗi điều kiện con
(subcondition) của từng điểm quyết định đều được thực
hiện ít nhất 1 lần cho TH TRUE và FALSE & điểm quyết
định cũng được kiểm thử cho cả 2 nhánh. Ta gọi
mức kiểm thử này là phủ các nhánh & điều kiện con
(branch & subcondition coverage).

24
Dynamic testing

 Dynamic testing (kiểm thử động): là phương pháp kiểm

thử thông qua việc chạy chương trình để kiểm tra trạng
thái từng hành động của chương trình.
 Kiểm thử kiểm thử hộp trắng (White box testing)
 Kỹ thuật kiểm thử hộp đen (Black-Box Testing)
 Kỹ thuật kiểm thử dựa trên kinh nghiệm (Experience-based
Testing)

25
White box testing

 Kiểm thử hộp trắng dựa vào thuật toán, cấu trúc mã lệnh (code)
bên trong của chương trình với mục đích đảm bảo rằng tất cả
các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần.
 KTV phải có kỹ năng, kiến thức về lập trình và ngôn ngữ lập
trình.
 Còn gọi là Clear Box Testing, Open Box Testing, Glass Box
Testing, Transparent Box Testing, Code-Based Testing hoặc
Structural Testing.

26
White box testing

 Đối tượng áp dụng:

 1 thành phần phần mềm (TPPM)
 TPPM có thể là 1 hàm chức năng, 1 module chức năng, 1
phân hệ chức năng…
 Mức độ áp dụng:
 Kiểm thử đơn vị (Unit Testing): Để kiểm tra đường dẫn
trong một đơn vị.
 Kiểm thử tích hợp (Integration Testing): Để kiểm tra
đường dẫn giữa các đơn vị.
 Kiểm thử hệ thống (System Testing): Để kiểm tra các
đường dẫn giữa các hệ thống con.
 Chủ yếu áp dụng cho các kiểm thử mức đơn vị.

27
White box testing - Ưu điểm

 Kiểm thử có thể bắt đầu ở giai đoạn sớm, không cần
phải chờ có GUI mới có thể kiểm thử;
 Kiểm thử kỹ hơn, có thể bao phủ hầu hết các đường
dẫn;
 Thích hợp trong việc tìm kiếm lỗi và các vấn đề tồn tại
trong mã lệnh;
 Cho phép tìm kiếm các lỗi ẩn bên trong TPPM;
 Các LTV có thể tự kiểm tra mã lệnh chương trình của
mình;
 Giúp tối ưu việc mã hoá và việc kiểm soát lỗi tối đa
nhất.

28
White box testing - Nhược điểm

 Việc thực hiện kiểm thử rất phức tạp, đòi hỏi người thực
hiện phải có tay nghề cao, với kiến thức sâu rộng về lập
trình.
 Việc bảo trì kịch bản kiểm thử mất nhiều công sức nếu
chương trình thay đổi thường xuyên.
 PP kiểm thử này liên quan chặt chẽ với ngôn ngữ lập
trình ứng dụng, đôi khi các công cụ hỗ trợ kiểm thử
không sẵn có.

29
White box testing - Tools

 Top các công cụ hỗ trợ kiểm thử hộp trắng:

 TestNG
 JUnit
 NUnit
 PyUnit
 PHPUnit
 CppUnit

30
White box testing

 White box testing = Structure Testing Types:

 Statement coverage: kiểm thử bao phủ câu lệnh. Thực
thi tất cả các câu lệnh ít nhất một lần.
 Decision (Branch) coverage: kiểm thử bao phủ đường rẽ
nhánh. Thực thi mỗi đường rẽ nhánh ít nhất một lần.
 Condition coverage: kiểm thử bao phủ điều kiện. Kiểm
tra tất cả các điều kiện kết hợp có thể.
 Path coverage: kiểm thử bao phủ đường dẫn. Kiểm thử
tất cả các đường có thể đi của đoạn chương trình.

31
Ví dụ
1
1. READ A
2. READ B, C=0 2

3. IF A>B THEN 3

4. C =A -B 4

5
5. ENDIF
6. IF C=D THEN 6

7. PRINT “Error” 7

8
8. ENDIF

32
Statement Coverage
1
READ A,B
1.
• 100% statement
2. READ D, C=0 2
coverage:
3. IF A>B THEN 3 • TC: 12345678
4. C =A -B 4 • Test data: A = 25,
5. ENDIF 5 B = 20, D=5
6. IF C=D THEN 6

7. PRINT “Error” 7
8
8. ENDIF

33
Decision/Branch Coverage

1. READ A
1
• 100%
2. READ B, C=0 2 decision/branch
3. IF A>B THEN
coverage:
3
• TC1: 123568, test
4. C =A -B 4
data: A = 20, B =
5. ENDIF 5 25, D=3
6. IF C=D THEN 6 • TC2: 12345678,
7. PRINT “Error” test data: A = 25, B
7
= 20, D=5
8. ENDIF 8
• What else?

34
Condition Coverage

 Kiểm tra tất cả các điều kiện kết hợp có thể. Các quyết
định có thể phức tạp tùy ý.
 if (a > b) then…
 if (A || B) && (C == D) || (!E) && (F) then…
 Yêu cầu mỗi điều kiện nhỏ nhất phải được đánh giá
đúng và sai.
 if (a AND b) then
(a = F, b = T F)
(a = T, b = T T)

35
Condition Coverage
A>B
1. READ A 1 No. A>B A>C and
A>C
2. READ B, C=0 2
1 T T T
3. IF (A>B AND A>C) 3
2 T F F
THEN 4
3 F T F
4. C =A -B 5
4 F F F
5. ENDIF
4 test cases:
• TC1: A=3, B=2
• TC2: A=-2, B=-3
• TC3: A=2, B=3
• TC4: A=-3, B=-2
36
Decision & Condition Coverage

 Sự kết hợp giữa điều kiện và quyết định:

 Mỗi điều kiện nhỏ nhất phải được đánh giá bằng cả 2
cách AND hoặc OR
 Phải bao phủ cả điều kiện và quyết định
 Ví dụ:
if (a AND b) then
(a = F, b = T → F)
(a = T, b = F → F)
(a = F, b = F → F)
(a = T, b = T → T)
 Ví dụ: Nhập vào 3 số a,b,c và kiểm tra 3 số có phải là 3
cạnh của một tam giác hay không

37
Path Coverage

 Mục tiêu:
 Đảm bảo mọi đường thực thi của đơn vị phần mềm cần
kiểm thử đều chạy đúng.
 Có thể dựa trên nguyên lý của kiểm thử luồng điều khiển -
Control Flow.

38
Path Testing

1. READ A 1 • 100% path coverage:

2. READ B, C=0 2 • TC1: 12345678
3. IF A>B THEN 3
• TC2: 123568
4. C =A -B 4
• TC3: 1234568
• TC4: 1235678
5. ENDIF 5

6. IF C=D THEN 6

7. PRINT “Error” 7
8
8. ENDIF

39
Comparisonbox test: Comparison
Example:
o Test cases covering ABDEG and
ACDFG cover 4/4 branches
(100%) and 7/7 statements
(100%)

o They, however, only cover 2/4

paths (50%).

o 2 more tests are required to

achieve 100% path coverage
 ABDFG
 ACDEG

41
Kiểm thử vòng lặp

 Các lệnh lặp chia thành 4 loại :

 lệnh lặp đơn giản: thân của nó chỉ chứa các lệnh khác.
 lệnh lặp lồng nhau: thân của nó chứa lệnh lặp khác...
 lệnh lặp liền kề: 2 hay nhiều lệnh lặp kế tiếp nhau
 lệnh lặp giao nhau: 2 hay nhiều lệnh lặp giao nhau.

42
Kiểm thử vòng lặp đơn giản

 Nên chọn các test case

sau đây để kiểm thử lệnh
lặp n lần :
1. chạy 0 lần.
2. chạy 1 lần.
3. chạy 2 lần.
4. chạy k lần, k là giá trị
nào đó thỏa 2 < k < n-1.
5. chạy n-1 lần
6. chạy n lần
7. chạy n+1 lần.


43
Kiểm thử vòng lặp lồng nhau

 Kiểm thử tuần tự từng vòng lặp từ

trong ra ngoài theo các bước sau:
 1. Kiểm thử vòng lặp trong cùng: cho
các vòng ngoài chạy với giá trị min,
kiểm thử vòng lặp trong cùng bằng 7
test case ở slide trên.
 2. Kiểm thử vòng lặp còn lại: cho các
vòng ngoài nó chạy với giá trị min, các
vòng bên trong nó chạy với giá trị điển
hình, kiểm thử nó bằng 7 test case đã
giới thiệu.


44
Kiểm thử vòng lặp liền kề

 Kiểm thử tuần tự từng vòng lặp từ trên xuống, mỗi vòng
thực hiện kiểm thử bằng 7 test case đã giới thiệu.
 Riêng các vòng lặp giao nhau thường do việc viết code
chưa tốt tạo ra
nên cấu trúc lại đoạn code sao cho không chứa dạng
giao nhau này.

45
Template unit test case

46
Exercise 1
 Statement testing?
 Decision/ Brach testing?
 Path testing?

47
Exercise 2
 Statement testing?
 Decision/ Brach testing?
 Path testing?

48
Exercise 3
 Statement testing?
 Decision/ Brach testing?
 Path testing?

50
Structure Testing Types Comparison

52
 Tài liệu tham khảo

 Bộ môn CNPM - Khoa CNTT, Đề cương Kiểm thử phần mềm, Đại
học Sư phạm Kỹ Thuật Hưng Yên.

 https://viblo.asia/p/tim-hieu-ve-cac-loai-kiem-thu-phan-mem-
wznVGL20RZOe

 https://www.guru99.com/white-box-testing.html

 https://www.guru99.com/code-coverage.html

53
 TỔNG KẾT

QUESTION/ ANSWER

54