Professional Documents
Culture Documents
Bai 6 - Ky Thuat Thiet Ke Kiem Thu - Kiem Thu Hop Trang
Bai 6 - Ky Thuat Thiet Ke Kiem Thu - Kiem Thu Hop Trang
Bai 6 - Ky Thuat Thiet Ke Kiem Thu - Kiem Thu Hop Trang
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
8
Đồ thị dòng và cách xác định
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ụ
12
Ví dụ
13
Độ phức tạp Cyclomatic C
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:
19
Kiểm thử luồng điều khiển
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ụ:
21
Phủ kiểm thử
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
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
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
30
White box testing
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
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
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%)
41
Kiểm thử vòng lặp
42
Kiểm thử vòng lặp đơn giản
43
Kiểm thử vòng lặp lồng nhau
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