Bài giảng Công nghệ phần mềm - Huỳnh Xuân Hiệp - Bài 5: Kiểm thử

Huỳnh Xuân Hiệp - CNPM 
57
5 kiểm thử(TESTING)
Nội dung: 
ƒ Khái quát chung 
ƒ Vấn đề chất l−ợng 
ƒ Kiểm thử không dựa trên thực thi 
ƒ Kiểm thử dựa trên thực thi 
ƒ Một số dạng kiểm thử khác 
Huỳnh Xuân Hiệp - CNPM 
58
5.1 Khái quát chung
(overview)
ƒ [IEEE 610.12, 1990] 
‰ lỗi (fault) : thiếu sót về mặt kỹ thuật (bug) 
‰ hỏng hóc (failure): hỏng hóc của sản phẩm bắt nguồn từ lỗi 
ƒ Lỗi (error): tạo ra bởi ng−ời lập trình 
ƒ Thẩm tra (verification) 
ƒ Công nhận hợp lệ (validation) 
Huỳnh Xuân Hiệp - CNPM 
59
5.2 Vấn đề chất l−ợng
(quality issue)
ƒ Chất l−ợng (quality): sản phẩm đáp ứng chính xác đặc tả của nó 
ƒ Đảm bảo chất l−ợng phần mềm (software quality assurance-SQA) 
‰ thành lập nhóm SQA 
‰ nhóm SQA đảm bảo sản phẩm hoạt động đúng chức năng và kiểm 
tra mỗi khi các nhà phát triển hoàn thành một giai đoạn nào đó 
‰ nhóm SQA đảm bảo chất l−ợng của tiến trình phần mềm 
ƒ Độc lập về quản lý (managerial independance): nhóm SQA và nhóm phát 
triển phải đ−ợc quản lý độc lập với nhau, không can thiệp vào công việc 
của nhau 
Huỳnh Xuân Hiệp - CNPM 
60
5.3 Kiểm thử không dựa trên thực thi
(nonexecution-based testing)
5.3.1 walkthroughs 
ƒ Nhóm walkthrough khoảng 4-6 ng−ời 
‰ có ít nhất một đại diện thuộc nhóm đặc tả 
‰ nhà quản lý chịu trách nhiệm về nhóm đặc tả 
‰ một đại diện khách hàng 
‰ một đại diện của nhóm thực hiện giai đoạn kế tiếp [Daun, 1984] 
‰ một đại diện của nhóm SQA, làm tr−ởng nhóm walkthrough 
ƒ Nên chọn những ng−ời già dặn kinh nghiệm kỹ thuật [New, 1992] 
ƒ Quản lý nhóm walkthrough, có 2 cách thực hiện: 
‰ h−ớng theo thành viên: mỗi thành viên trong nhóm đ−a ra danh sách 
chất vấn có các mục không rõ ràng hoặc không chính xác theo quan 
điểm của mình, đại diện nhóm đặc tả giải trình. 
‰ h−ớng theo tài liệu: ng−ời có trách nhiệm về tài liệu giải trình từng 
phần trong tài liệu cho nhóm đ−a ra ý kiến. [IEEE 1028, 1988] 
Huỳnh Xuân Hiệp - CNPM 
61
5.3.2 Thanh tra (inspection) 
ƒ Thành lập nhóm thanh tra 
‰ khoảng 4 ng−ời: nhóm tr−ởng(moderator), ng−ời thiết kế(designer), 
ng−ời cài đặt(implementer) và ng−ời kiểm thử (tester) thuộc nhóm 
SQA 
‰ khoảng 3-6 ng−ời [IEEE 1028, 1986]: một số vai trò đặc biệt nh− nhóm 
tr−ởng(moderator), ng−ời dẫn dắt nhóm phần thiết kế (reader), ng−ời 
viết báo cáo lỗi (recorder) 
ƒ Thanh tra với nhóm thanh tra, do Fagan đề xuất [Fagan, 1976] nhằm kiểm 
thử các thiết kế và mã lệnh, gồm 5 b−ớc: 
‰ b−ớc 1: xem xét khái quát (overview), các tài liệu sẽ đ−ợc thanh tra 
nh− đặc tả, thiết kế, mã lệnh, kế hoạch; đ−ợc đ−a ra bởi chính ng−ời 
viết tài liệu đó; tất cả các thành viên trong nhóm sẽ nhận đầy đủ các 
tài liệu 
‰ b−ớc 2: chuẩn bị (preparation), các thành viên tìm hiểu các tài liệu 
một cách chi tiết; danh sách các lỗi trong các lần thanh tra gần nhất 
Huỳnh Xuân Hiệp - CNPM 
62
‰ b−ớc 3: thanh tra (inspection), một thành viên duyệt qua tất cả các 
mục và các nhánh trong tài liệu; phát hiện các lỗi; lãnh đạo nhóm 
thanh tra viết báo cáo về lỗi 
‰ b−ớc 4: làm lại (rework), các cá nhân phụ trách các tài liệu sẽ sửa 
các lỗi đ−ợc mô tả trong báo cáo về lỗi ở b−ớc 3 
‰ b−ớc 5: tiếp tục (follow-up), nhóm tr−ởng đảm bảo rằng toàn bộ các 
tài liệu đã đ−ợc điều chỉnh; giới thiệu lỗi. [Fagan, 1986] 
ƒ Thiết lập danh sách các lỗi tiềm tàng 
5.3.3 Điểm mạnh và điểm yếu (strengths and weaknesses of reviews) 
ƒ Điểm mạnh 
‰ rất hiệu quả trong việc tìm kiếm lỗi 
‰ lỗi đ−ợc phát hiện sớm do đó sẽ giảm chi phí bảo trì 
ƒ Điểm yếu 
‰ không hiệu quả đối với phần mềm lớn, trừ khi nó đ−ợc chia thành 
nhỏ hơn và t−ơng đối độc lập 
‰ phải xem xét các tài liệu liên quan của phiên bản hiện hành, sẽ 
không tốt nếu nh− tài liệu không đ−ợc cập nhật đầy đủ và chính xác 
Huỳnh Xuân Hiệp - CNPM 
63
5.4 Đánh giá công tác thanh tra
(metrics for inspections)
ƒ Ph−ơng pháp tính mật độ lỗi (fault density) 
‰ số lỗi trên một trang đặc tả hay thiết kế 
‰ số lỗi trên 1000LOC 
ƒ Ph−ơng pháp tính tỷ lệ phát hiện lỗi (fault detection rate) 
‰ số l−ợng lỗi quan trọng/không quan trọng trên một giờ 
ƒ Ph−ơng pháp tính hiệu suất dò tìm lỗi (fault detection efficiency) 
‰ số l−ợng lỗi quan trọng/không quan trọng trên ng−ời-giờ 
Huỳnh Xuân Hiệp - CNPM 
64
5.5 Kiểm thử dựa trên thực thi
(execution-based testing)
ƒ Định nghĩa của Goodenough [Goodenough, 1979]: là tiến trình suy xét dựa 
vào cách thức xử lý của sản phẩm trên cơ sở thực thi sản phẩm trong một 
môi tr−ờng đã biết với các đầu vào chọn lọc. 
ƒ Hệ mô phỏng (simulator): là một mô hình hoạt động của môi tr−ờng sản 
phẩm 
ƒ Một số khái niệm 
‰ tiện ích (utility) 
‰ độ tin cậy (reliability) 
‰ sự mạnh mẽ (robustness) 
‰ hiệu suất (performance) 
‰ sự đúng đắn (correctness): một sản phẩm đ−ợc xem là đúng nếu 
nh− nó đáp ứng đ−ợc những đặc tả đầu ra của nó, độc lập với tài 
nguyên máy tính và vận hành d−ới những điều kiện cho phép 
[Goodenough, 1979] 
Huỳnh Xuân Hiệp - CNPM 
65
VD: 
Đặc tả đầu vμo: p: mảng n số nguyên, n>0 
Đặc tả đầu ra: q: mảng n số nguyên với q[0] ≤ q[1] ≤...≤ q[n-1]
Hình 5.1 Đặc tả đúng cho sắp xếp 
void trickSort (int p[], int q[]) 
{ 
int i; 
for (i= 0; i < n; i++) q[i] = 0; 
} 
Hình 5.2 Ph−ơng thức trickSort đáp ứng đặc tả Hình 5.1 
Đặc tả đầu vμo: p: mảng n số nguyên, n>0 
Đặc tả đầu ra: q: mảng n số nguyên với q[0] ≤ q[1] ≤...≤ q[n-1]
 Các phần tử trong mảng q là hoán vị của các 
phần tử trong mảng p với giá trị không thay đổi 
Hình 5.3 Đặc tả đúng cho sắp xếp 
Huỳnh Xuân Hiệp - CNPM 
66
5.6 Một số dạng kiểm thử khác
(other types of testing software)
ƒ Kiểm thử phần mềm phân tán (testing distributed software) 
‰ trên nhiều phần khác nhau của phần cứng 
‰ trên mạng 
‰ trao đổi bằng các thông báo 
‰ sử dụng các công cụ đặc biệt để xác định lỗi, lần vết [Wahl và Schach, 
1988] 
‰ sử dụng tập tin lịch sử (historical file) 
ƒ Kiểm thử phần mềm thời gian thực (testing real-time software) 
‰ phụ thuộc vào thời điểm xuất hiện đầu vào và thứ tự của nó 
‰ khó khăn khi ứng dụng các tr−ờng hợp kiểm thử (test cases) 
‰ có 5 dạng tiếp cận: phân tích cấu trúc, chứng minh tính đúng đắn, 
kiểm thử theo hệ thống, kiểm thử thống kê và mô phỏng [Quirk, 1985]