Huúnh Xu©n HiÖp - CNPM
57
5
5
k
k
i
i
Ó
Ó
m
m
t
t
h
h
ö
ö
(
(
T
T
E
E
S
S
T
T
I
I
N
N
G
G
)
)
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
5
5
.
.
.
1
1
1
K
K
K
h
h
h
á
á
á
i
i
i
q
q
q
u
u
u
á
á
á
t
t
t
c
c
c
h
h
h
u
u
u
n
n
n
g
g
g
(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
5
5
.
.
.
2
2
2
V
V
V
ấ
ấ
ấ
n
n
n
đ
đ
đ
ề
ề
ề
c
c
c
h
h
h
ấ
ấ
ấ
t
t
t
l
l
l
ợ
ợ
ợ
n
n
n
g
g
g
(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
5
5
.
.
.
3
3
3
K
K
K
i
i
i
ể
ể
ể
m
m
m
t
t
t
h
h
h
ử
ử
ử
k
k
k
h
h
h
ô
ô
ô
n
n
n
g
g
g
d
d
d
ự
ự
ự
a
a
a
t
t
t
r
r
r
ê
ê
ê
n
n
n
t
t
t
h
h
h
ự
ự
ự
c
c
c
t
t
t
h
h
h
i
i
i
(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
5
5
.
.
.
4
4
4
Đ
Đ
Đ
á
á
á
n
n
n
h
h
h
g
g
g
i
i
i
á
á
á
c
c
c
ô
ô
ô
n
n
n
g
g
g
t
t
t
á
á
á
c
c
c
t
t
t
h
h
h
a
a
a
n
n
n
h
h
h
t
t
t
r
r
r
a
a
a
(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
5
.
.
.
5
5
5
K
K
K
i
i
i
ể
ể
ể
m
m
m
t
t
t
h
h
h
ử
ử
ử
d
d
d
ự
ự
ự
a
a
a
t
t
t
r
r
r
ê
ê
ê
n
n
n
t
t
t
h
h
h
ự
ự
ự
c
c
c
t
t
t
h
h
h
i
i
i
(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 vo:
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 vo:
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
5
5
.
.
.
6
6
6
M
M
M
ộ
ộ
ộ
t
t
t
s
s
s
ố
ố
ố
d
d
d
ạ
ạ
ạ
n
n
n
g
g
g
k
k
k
i
i
i
ể
ể
ể
m
m
m
t
t
t
h
h
h
ử
ử
ử
k
k
k
h
h
h
á
á
á
c
c
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]