Embed Size (px)
Citation preview
1CNPM/NN
CÔNG NGHỆ PHẦN MỀM
Chương 8
Kiểm thử phần mềm
MÔN HỌC
TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM
2CNPM/NN
Nội dung1. Kiểm thử (Testing)?2. Chiến lược kiểm thử (Testing Strategy)
1. Kiểm thử đơn vị (unit test)2. Kiểm thử tích hợp (intergration test)3. Kiểm thử thẩm tra – chức năng (validation test)4. Kiểm thử hệ thống (system test)5. Một số loại kiểm thử khác
3. Kỹ Kiểm thử hộp trắng (White Box)1. Thiết kế test case2. Kiểm thử hộp trắng (white-box)3. Kiểm thử các đường cơ bản4. Kiểm thử cấu trúc lặp5. Phủ trong kiểm thử6. Kiểm thử luồng dữ liệuthuật kiểm thử phần mềm
3CNPM/NN
Nội dung3. Kiểm thử hộp đen (Black Box)
3. Kiểm thử hộp đen?4. Kiểm thử giá trị biên (Boundary Value Analysis)5. Kiểm thử lớp tương đương (Equivalence Class
Testing)6. Kiểm thử dựa vào bảng quyết định (Decision Table
Base Testing)7. Kiểm thử giá trị đặc biệt
4. Các vấn đề khác1. Kiểm thử hướng đối tượng (OOT)2. Tự động kiểm thử3. Gỡ lỗi (Debugging)
4
CNPM/NN
Các hoạt động
5CNPM/NN
6CNPM/NN
1. Kiểm thử phần mềm
Testing is the process of exercising aprogram with the specific intent of finding errors prior to (trước khi) delivery to the end user.
7
What is...
Kiểm thử (Testing): Bằng kinh nghiệm find errors in software (Myers, 1979) establish quality of software (Hetzel, 1988)
Một test thành công: finds at least one error passes (software works correctly)
test-to-fail
test-to-pass
CNPM/NN
8CNPM/NN
Kiểm chứng và thẩm định bao gồm kiểm thử phần mềm
Kiểm chứng (Verification): “Chúng ta đang xây dựng sản phẩm theo đúng cách" Phần mềm phải phù hợp với đặc tả của nó
Thẩm định (Validation): “Chúng ta đang xây dựng sản phẩm đúng" Phần mềm phải thực hiện những gì người dùng thật sự cần
Kiểm chứng và thẩm định (V&V) ???
Kiểm chứng và thẩm định
9CNPM/NN
10CNPM/NN
Ai kiểm thử phần mềm?
developer independent testerUnderstands the system but, will test "gently"and, is driven by "delivery"
Must learn about the system,but, will attempt to break itand, is driven by quality
11CNPM/NN
2. Chiến lược kiểm thử (Testing Strategy)
1. Kiểm thử đơn vị (unit test)2. Kiểm thử tích hợp (intergration test)3. Kiểm thử hệ thống (system test)4. Các thuật ngữ kiểm thử.
3 mức kiểm thử
12CNPM/NN
13CNPM/NN
2.1 Kiểm thử đơn vị
moduleto be
tested
test cases
results
softwareengineer
14CNPM/NN
Các mục cần kiểm tra
interface local data structuresboundary conditionsindependent pathserror handling paths
moduleto be
tested
test cases
15CNPM/NN
2.2 kiểm thử tích hợp
Chọn lựa chiến luợc:• Hướng tiếp cận “big bang”• Chiến lược xây dựng gia tăng
16CNPM/NN
Kiểm thử top down
Module
stub stub
driver
RESULTS
interface
local data structures
boundary conditions
independent paths
error handling paths
test cases
Driver
17CNPM/NN
18CNPM/NN
Tích hợp Top Down
top module is tested with stubs (nhánh)
stubs are replaced one at a time, "depth first"
as new modules are integrated, some subset of tests is re-run
A
B
C
D E
F G
Sử dụng stub
Stub: calender() có gọi đến module tính ngàycalc_day() chưa được phát triển
String calc_day (Date d){
return "Sunday";
} Driver là một chương trình chính có nhiệm vụ nhận
dữ liệu kiểm thử, chuyển dữ liệu đó xuống cho các module bên dười rồi nhận kết quả và xuất ra
19CNPM/NN
Test drive
void calc_day_test_drive(){
Date d;String s;
while (1) {cout << ”Enter date: ”;cin >> d;s = calc_day(d);cout << s << endl;
}}
20CNPM/NN
21CNPM/NN
Tích hợp Bottom-Up
drivers are replaced one at a time, "depth first"
worker modules are grouped into builds and integrated
A
B
C
D E
F G
cluster
22CNPM/NN
Kiểm thử Sandwich
Top modules aretested with stubs (nhánh)
Worker modules are grouped into builds and integrated
A
B
C
D E
F G
cluster
23CNPM/NN
2.3. Kiểm thử hệ thống (System testing)…
24CNPM/NN
…Kiểm thử hệ thống.
2.4 Các thuật ngữ kiểm thử
Kiểm thử tính năng. Kiểm thử chấp nhận, Kiểm thử thẩm tra: Kiểm thử Anpha,
Beta... Kiểm thử hồi quy (regression). Kiểm thử kiến trúc, môi trường và ứng dụng đặc trưng. Mô hình chữ V. Kiểm thử Smoke. Kiểm thử so sánh. Kiểm thử phục hồi (Recovery testing). Kiểm thử an ninh (Security testing. Kiểm thử áp lực (Stress testing)…
25CNPM/NN
Kiểm thử tính năng
Kiểm tra đúng với đặc tả yêu cầu. Hướng dẫn.
Dùng nhóm kiểm thử độc lập. Biết những hoạt động mong đợi và output. Kiểm thử cả valid và invalid. Không được biến đổi hệ thống. Có một tiêu chuẩn dừng.
26CNPM/NN
Kiểm thử chấp nhận (Acceptance testing)
Nhằm kiểm tra sự chấp nhận của người dùng. Kiểm thử chấp nhận có thể dựa vào hợp đồng. Nếu không có hợp đồng thì có thể dùng kiểm thử Alpha
hay Beta.
27CNPM/NN
Kiểm thử thẩm tra
Kiểm thử Alpha: Được tiến hành ngay tại nơi sản xuất phần mềm. Nhà phát triển phần mềm sẽ quan sát người sử dụng dùng
sản phẩm và ghi nhận lại những lỗi phát sinh để sửa chữa. Kiểm thử Beta:
Phần mềm được kiểm tra bên ngoài phạm vi của đơn vị sản xuất.
Khách hành trực tiếp sử dụng và ghi nhận lỗi để báo lại cho nhà phát triển sửa chữa.
28CNPM/NN
29CNPM/NN
Kiểm thử hồi quy (regression)
1. Việc kết hợp các module lại với nhau có thể ảnh hưởng đến vòng lặp điều khiển, cấu trúc dữ liệu hay I/O chia sẻ trong một số module
2. Điều đó làm lộ ra một số lỗi không thể phát hiện được khi tiến hành kiểm nghiệm theo đơn vị
3. Kiểm nghiệm hồi quy có thể được tiến hành thủ công bằng cách thực hiện lại các test-case đã tạo ra. Hoặc có thể dùng một công cụ capture-playback để thực hiện tự động
30CNPM/NN
Kiểm thử kiến trúc, môi trườngvà ứng dụng đặc trưng
Kiểm thử GUI: thường dùng công cụ kiểm thử tự động Kiểm thử client/server:
Kiểm thử chức năng ứng dụng Kiểm thử server Kiểm thử cơ sở dữ liệu Kiểm thử truyền thông mạng
Kiểm thử tài liệu và trợ giúp Kiểm thử hệ thống thời gian thực
Kiểm thử công việc (task) Kiểm thử hành vi Kiểm thử liên tác vụ (inter task) Kiểm thử hệ thống: interrupt với độ ưu tiên, xử lý interrrupt, số
lượng interrrupt xuất hiện trong một khoảng thời gian…
Kiểm thử giao diện
31CNPM/NN
32CNPM/NN
Mô hình kiểm thử V
Hệ thống Kiểm thử toàn bộ hệ thống
Yêu cầu
Thiết kế
Mã hóa Kiểm Thử đơn vị (module)
Kiểm thử tích hợp
Kiểm thử tính năng
33CNPM/NN
Phương pháp kiểm thử
Methods
Strategies
white-boxmethods
black-boxmethods
34CNPM/NN
2. Kiểm thử hộp trắng (White Box)
1. Thiết kế test case.2. Kiểm thử hộp trắng (white-box).3. Kiểm thử các đường cơ bản.4. Kiểm thử cấu trúc lặp.5. Phủ trong kiểm thử.6. Kiểm thử luồng dữ liệu.
35CNPM/NN
Một test “tốt”?
Có khả năng tìm lỗi cao Không dư thừa và tốn quá nhiều công sức
để thực hiện Phải tinh chế để là test tốt nhất Không quá đơn giản và quá phức tạp
36CNPM/NN
3.1 Thiết kế Test Case
"Bugs lurk in corners and congregate at boundaries ..."
Boris Beizer
Mục tiêu
Tiêu chuẩn
Ràng buộc
Khám phá lỗi
Toàn diện
Ít tốn công sức và thời gian
Test case
37CNPM/NN
38CNPM/NN
Hướng dẫn thiết kế Test case
Kiểm tra cẩn thận những kết quả từ test case trước đó Test case phải viết cho giá trị hợp lệ (valid) và không hợp lệ
cũng như điều kiện, input, kết quả mong đợi, không mong đợi (tìm thấy và không tìm thấy…)
Phải kiểm thử từ nhỏ tới lớn, không thể kiểm thử tất cả các trường hợp
Khi một phần có nhiều lỗi được tìm nó có khả năng có nhiều lỗi hơn
39
Ví dụ về định hướng kiểm thử
Lựa chọn các đầu vào sao cho hệ thống có thể đưa ra tất cả các thông báo lỗi.
Thiết kế đầu vào sao cho vùng nhớ đệm bị tràn. Lặp lại nhiều lần cùng một đầu vào hoặc một chuỗi
các đầu vào. Ép hệ thống tạo ra những kết quả không hợp lệ. Buộc cho các kết quả tính phải quá lớn hoặc quá
nhỏ.
CNPM/NN
40CNPM/NN
Kiểm thử vét cạn (Exhaustive)
loop < 20 X
There are 10 possible paths! If we execute onetest per millisecond, it would take 3,170 years totest this program!!
14
41CNPM/NN
2.2 Kiểm thử White-Box
... our goal is to ensure that all statements and conditions have been executed at least once ...
Kiểm thử dựa vào cấu trúc?
Dựa vào mã nguồn. Kiểm tra cấu trúc nội của chương trình. Test case được đưa từ việc kiểm tra cấu trúc chương
trình. Xác định số test case để đảm bảo mức phủ đòi hỏi.
42CNPM/NN
43CNPM/NN
2.3 Kiểm thử đường cơ bản
Path 1: 1,2,3,6,7,8Path 2: 1,2,3,5,7,8Path 3: 1,2,4,7,8Path 4: 1,2,4,7,2,4,...7,8
1
2
34
5 6
7
8
Biểu đồ luồng cơ bản
44CNPM/NN
45CNPM/NN
Kiểm thử các đường cơ bản
Kiểm thử các đường cơ bản là một trong những phương cách kiểm nghiệm white-box
Bảo đảm số phép thử là ít nhất đủ để phát hiện các lỗi Tất cả các đường cơ bản được thử qua ít nhất một lần Thử các điều kiện rẽ nhánh ở cả 2 nhánh true và false Thử qua vòng lặp tại biên cũng như bên trong Thử qua cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nó Kiểm thử đường cơ bản áp dụng cho những module có
tính nghiêm ngặt
46CNPM/NN
Độ phức tạp lộ trình Cyclomatic Complexity V(G)
Complexity V(G):
Số rẽ nhánh đơn + 1
V(G) = 4
V(G) = E - N + 2, trong đó 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 luận lý (chỉ có 2 cung
47CNPM/NN
Đưa ra đường cơ bản
Since V(G) = 4,
Path 1: 1,2,3,6,7,8Path 2: 1,2,3,5,7,8Path 3: 1,2,4,7,8Path 4: 1,2,4,7,2,4,...7,8
1
2
34
5 6
7
8
Quy trình xác định các đường cơ bản
1. Xác định đường cơ bản, đường này nên là đường thi hành phổ biến nhất.
2. Để chọn đường thứ 2, thay đổi cung xuất của nút quyết định đầu tiên và cố gắng giữ lại maximum phần còn lại.
3. Để chọn đường thứ 3, dùng đường cơ bản nhưng thay đổi cung xuất của nút quyết định thứ 2 và cố gắng giữ lại maximum phần còn lại.
4. Tiếp tục thay đổi cung xuất cho từng nút quyết định trên đường cơ bản để xác định đường thứ 4, 5,... cho đến khi không còn nút quyết định nào trong đường cơ bản nữa.
5. Lặp dùng tuần tự các đường tìm được làm đường cơ bản để xác định các đường mới xung quanh nó y như các bước 2, 3, 4 cho đến khi không tìm được đường tuyến tính độc lập nào nữa (khi đủ số C).
Tom McCabe48CNPM/NN
49CNPM/NN
50CNPM/NN
51CNPM/NN
Ví dụ với AnalyzeTriangle
Đối với chương trình con AnalyzeTriangle
Tổng số đường:V = 6 + 1 = 7
Đường 1: 1-3-12 Đường 2: 1-2-3-12 Đường 3: 1-2-4-5-12 Đường 4: 1-2-4-6-7-12 Đường 5: 1-2-4-6-8-7-12 Đường 6: 1-2-4-6-8-9-10-12 Đường 7: 1-2-4-6-8-9-11-12
1
2
3
4
6
5
7
8
9
c > 0
a<b+c
a = c
a = b
b = ca2=b2
+c2
11
1012
52CNPM/NN
Sample Test CasesAssuming Integer Greater than 0 and less than or equal to 200
Test Case X Y Z Expected Output
1 100 100 1 Isosceles 2 100 100 2 Isosceles3 100 100 200 Not a triangle4 100 1 100 Isosceles5 1 1 1 Equilateral 6 1 2 100 Not a triangle 7 2 199 200 Scalene 8 100 199 200 Scalene9 100 200 2 Not a triangle
10 100 200 200 Isosceles11 100 2 200 Scalene12 199 100 100 Isosceles
53CNPM/NN
2.4 Kiểm thử cấu trúc lặp (Loop)
Nested Loops
ConcatenatedLoops Unstructured
Loops
Simple loop
54CNPM/NN
Vòng lặp đơn
1. Bỏ qua vòng lặp2. Qua vòng lặp 1 lần3. Qua vòng lặp 2 lần4. loop m < n5. (n-1), n, and (n+1)
where n is the maximum number of allowable passes
Simple loop
55CNPM/NN
Vòng lặp lồng nhau
Nested Loops
1. Bắt đầu ở vòng lặp trong cùng, thiết lập tất cả các vòng lặp ngoài có giá trị tham số lặp nhỏ nhất (giá trị bộ đếm)
2. Test vòng lặp trong cùng (test vòng lặp đơn)3. Di chuyển ra vòng lặp ngoài rồi thực hiện với
bước 2 với giá trị của vòng lặp bên trong ở giá trị tùy ý
4. Tiếp tục cho hết vòng lặp
56CNPM/NN
Vòng lặp nối tiếp
ConcatenatedLoops
• Nếu phụ thuộc, chẳng hạn giá trị biến đếm của vòng lặp 1 dùng để khởi động vòng lặp 2 thì xem như 2 vòng lặp lồng nhau
2.5 Phủ trong kiểm thử 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.
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 }
Với hàm foo bệnh cạnh, ta chỉ cần 2 test case sau đây là đạt 100% phủ cấp 1 :1. foo(0,0,0,0), trả về 02. foo(1,1,1,1), trả về 1nhưng không phát hiện lỗi chia 0 ở hàng lệnh 8
57CNPM/NN
Phủ cấp 2 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.
Line Predicate True False3 (a == 0) Test Case 1
foo(0, 0, 0, 0)return 0
Test Case 2foo(1, 1, 1, 1)return 1
6 ((a==b) OR ((c == d) AND bug(a) ))
Test Case 2foo(1, 1, 1, 1)return 1
Test Case 3foo(1, 2, 1, 2)return 1
Với 2 test case xác định trong slide trước, ta chỉ đạt được 3/4 x 75% phủ các nhánh. Nếu thêm test case 3 :3. foo(1,2,1,2), thì mới đạt 100% phủ các nhánh.
Phủ cấp 3 Phủ cấp 3: kiểm thử sao cho mỗi điều kiện luận lý con
(subcondition) của từng đ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 đ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.
Predicate True Falsea ==0 Test Case 1
foo(0, 0, 0, 0)return 0
Test Case 2foo(1, 1, 1, 1)return 1
(a==b) Test Case 2foo(1, 1, 1, 1)return value 0
Test Case 3foo(1, 2, 1, 2)division by zero!
(c==d) Test Case 3foo(1, 2, 1, 2)division by zero!
bug(a)
Phủ cấp 4
Phủ cấp 4: kiểm thử sao cho mỗi điều kiện luận lý con (subcondition) của từng đ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 & đ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).
60CNPM/NN
61CNPM/NN
2.6. Kiểm thử luồng dữ liệu
62CNPM/NN
3. Kiểm thử Black-Box
Kiểm thử hộp đen. Kiểm thử giá trị biên (Boundary Value Analysis). Kiểm thử lớp tương đương (Equivalence Class Testing). Kiểm thử dựa vào bảng quyết định (Decision Table Base
Testing). Kiểm thử giá trị đặc biệt.
63CNPM/NN
64CNPM/NN
Kiểm thử Black-Box
requirements
eventsinput
output
65
Kiểm thử Black-Box
CNPM/NN
66CNPM/NN
Kiểm thử Black-Box
Hệ thống xem như một hộp kín không cần biết bên trong chỉ cần tạo ra output đúng với chức năng từ input
Cần quan tâm về dữ liệu của test case Những lớp input nào sẽ tạo ra những test case tốt? Hệ thống thường nhạy cảm với những giá trị input xác định
nào? Biên của những lớp dữ liệu được cô lập như thế nào? Tỷ lệ và độ lớn của dữ liệu mà hệ thống có thể chịu đựng? Các dữ liệu đặc biệt sẽ ảnh hưởng gì đến hệ thống?
3.2. Kiểm thử giá trị biên
Boundary Value Testing
{-1, 0, 1}, {15, 16, 17}, {17, 18, 19}, {54, 55, 56}, and {98, 99, 100}.
Person’s Age
Rule
0 - 16 Don’t hire16 – 18 Can hire on a part-time basis only18 – 55 Can hire as a full-time employee55 – 99 Don’t hire
67CNPM/NN
Xác định giá trị biên
68CNPM/NN
Monthly Income Number of Dwellings Result Description
$1,000 1 Valid Min income, min dwellings
$83,333 1 Valid Max income, min dwellings
$1,000 5 Valid Min income, max dwellings
$83,333 5 Valid Max income, max dwellings
$1,000 0 Invalid Min income, below min dwellings
$1,000 6 Invalid Min income, above max dwellings
$83,333 0 Invalid Max income, below min dwellings
$83,333 6 Invalid Max income, above max dwellings
$999 1 Invalid Below min income, min dwellings
$83,334 1 Invalid Above max income, min dwellings
$999 5 Invalid Below min income, max dwellings
$83,334 5 Invalid Above max income, max dwellings
TestCase
69CNPM/NN
70CNPM/NN
Kiểm thử lớp tương đương
Equivalence partitions
• Phân hoạch tương đương (Equivalence partitions) Nhằm giảm các test case
Ví dụ
Input trong khoảng [a..b] Chọn một mẫu nhỏ hơn a một mẫu giữa a và b và một mẫu
lớn hơn b Input là một tập hợp V
Chọn một mẫu trong V và một mẫu ngoài V
71CNPM/NN
72CNPM/NN
Cách phân hoạch theo input Nếu input là một dãy giá trị, chia thành 1 lớp valid và
2 lớp invalid Nếu input là một giá trị đặc biệt, chia thành 1 lớp
valid và 2 lớp invalid Nếu input là một thành viên của tập hợp, chia thành
1 lớp valid và 1 lớp invalid Nếu input là một giá trị boolean, chia thành 1 lớp
valid và 1 lớp invalid
73CNPM/NN
Phân hoạch tương đương
Testcase cho tìm kiếm nhị phân
Số phần tử của mảng: 0, 1 Lớn hơn 1
Khóa tìm kiếm: Không có trong mảng
Nhỏ hơn, lớn hơn Xen kẽ
Có trong mảng Phần tử đầu tiên, cuối cùng Phần tử ở vị trí bất kỳ
74CNPM/NN
75CNPM/NN
Testcase
3.4. Kiểm thử dựa vào bảng quyết định
76CNPM/NN
Vd: Chương trình xác định tam giác
77CNPM/NN
3.5. Kiểm thử giá trị đặc biệt (Ad Hoc Testing)
Người kiểm tra dựa vào trực giác, kinh nghiệm và kỹnăng để đưa ra test case.
Phụ thuộc vào khả năng của người kiểm thử. Thuật ngữ khác: “hacking”, “out-of-box testing”.
78CNPM/NN
Loại kiểm thử và kỹ thuật áp dụng
Testing type Techniques UsedUnit Testing White BoxIntegration Testing White Box
Black BoxSystem Testing Black Box
Accceptance Testing Black Box 79CNPM/NN
80CNPM/NN
4. Các vấn đề khác
1. Kiểm thử hướng đối tượng (OOT)2. Tự động kiểm thử3. Gỡ lỗi (Debugging)
81CNPM/NN
4.1 Kiểm thử hướng đối tượng
Bắt đầu bằng cách đánh giá sự đúng đắn và toàn vẹn của mô hình OOA và OOD
Những khác biệt Khái niệm lớp ‘unit’ Việc tích hợp tập trung vào tích hợp các lớp và dựa vào kịch bản Việc thẩm định sử dụng phương pháp blackbox
Thiết kế test case theo phương pháp cũ nhưng phải bao gồm thêm những đặc trưng mới của hướng đối tượng
Kiểm thử dựa theo mô hình CRC (lớp-nhiệm vụ-công tác)
82CNPM/NN
Chiến lược trong OOT
Kiểm thử lớp (unit testing) Kiểm thử tác vụ Kiểm tra hành vi, trạng thái của lớp
Kiểm thử tích hợp thread-based testing (kiểm thử dựa vào dữ liệu
vào) — dựa vào đáp ứng của sự kiện hay input use-based testing (kiểm thử dựa vào chức năng)
— dựa vào chức năng (use case) cluster testing (kiểm thử dựa vào cộng tác) —
dưa vào sự cộng tác giữa các lớp
83CNPM/NN
Các loại OOT … Kiểm thử hướng lỗi (Fault-based testing)
Thiết kế test case dựa vào dự đoán những lỗi có khả năng xảy ra
Kiểm thử lớp và phân cấp của lớp (Class Testing and the Class Hierarchy)
Thiết kế test dựa vào kịch bản (Scenario - Based Test Design) Dựa vào những gì người dùng làm (use-case)
Kiểm thử tương tác (Inter-class)
84CNPM/NN
…Kiểm thử OOT
Kiểm thử hành vi (Behavior)Test được thiết kế để duyệt qua tất cả các trạng thái và dịch chuyển trạng thái
Kiểm thử dịch chuyển trạng thái
85CNPM/NN
86CNPM/NN
4.2 Tự động kiểm thử
Kiểm thử là công việc tốn nhiều công sức. Những hệ thống kiểm thử cung cấp những công cụ cho phép giảm thời gian và chi phí
Phần lớn hệ thống kiểm thử là những hệ thống mở Có thể dùng kịch bản để tạo dữ liệu test Output có thể dùng để so sánh một cách thủ công. Có
thể phát triển những hệ thống so sánh file
87CNPM/NN
4.3 Gỡ lỗi (Debugging)
88CNPM/NN
Quy trình gỡ lỗitest cases
results
Debugging
suspectedcauses
identifiedcauses
corrections
regressiontests
new testcases
89CNPM/NN
Dấu hiệu và nguyên nhân
symptomcause
Dấu hiệu và nguyên nhân có thể khác biệt về nơi
Dấu hiệu có thể biến mất khi một vấn để khác đã được sửa
Nguyên nhân có thể do sự kết hợp của yếu tố không thực sự là lỗi
Nguyên nhân có thể là do lỗi của hệ thống hay của bộ biên dịch
Nguyên nhân có thể là những giả địnhmà mọi người tin tưởng
Dấu hiệu có thể lúc có lúc không
90CNPM/NN
Kỹ thuật gỡ lỗi
Brute force
Backtracking
Loại trừ nguyên nhân (cause elimination)Kiểm thử
91CNPM/NN
BRUTE FORCE Áp dụng phương pháp này khi tất cả các phương pháp
khác đều thất bại.
Là phương pháp phổ biến nhất nhưng lại ít hiệu quả
nhất cho việc phát hiện nguyên nhân gây lỗi phần mềm.
Triết lý của phương pháp này là: “Hãy để máy tính tìm ra
lỗi”.
Cách thực hiện:
Lấy dữ liệu trong bộ nhớ để xem xét.
Dùng run-time trace để tìm lỗi.
Dùng lệnh WRITE để xuất dữ liệu cần kiểm tra ra
màn hình….
92CNPM/NN
LẦN VẾT NGƯỢC (Backtracking)
Cách thực hiện: bắt đầu tại dòng mã nguồn có triệu
chứng lỗi thực hiện lần ngược trở lại từng dòng mã
nguồn cho đến khi tìm thấy dòng gây ra lỗi.
Là một phương pháp gỡ lỗi khá phổ biến có thể dùng
thành công trong các chương trình nhỏ nhưng khó áp
dụng cho đối với các chương trình rất lớn.
93CNPM/NN
LOẠI TRỪ NGUYÊN NHÂN
Cách thực hiện: Khi một lỗi được phát hiện, cố gắng đưa ra một danh sách
các nguyên nhân có thể gây ra lỗi (các giả thiết) Danh sách này được xem xét lại để loại bỏ dần các
nguyên nhân không đúng cho đến khi tìm thấy một nguyên nhân khả nghi nhất (dùng dữ liệu liên quan)
Khi đó dữ liệu kiểm thử sẽ được tinh chế lại để tiếp tục tìm lỗi.
Gỡ lỗi bằng kiểm thử
Dùng Test case. Dùng cùng với phương pháp quy nạp.
94CNPM/NN
95CNPM/NN
Các lưu ý
Đừng vội vã hãy suy xét đến những dấu hiệumà bạn thấy
Dùng công cụ hỗ trợ (dynamic debugger…)
Khi bế tắc nên nhờ người khác trợ giúp
Khi gỡ lỗi cần phải thực hiện kiểm thử hồi qui (regression tests)
1.
2.
3.
4.
