chuong 4 - nhung phuong phap kiem thu
TRANSCRIPT
CHƯƠNG 4
NHỮNG PHƯƠNG PHÁP KIỂM THỬ
1
Kiểm thử và Đảm Bảo Chất Lượng Phần Mềm
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
Rất cám ơn GS Sommerville và GS Roger S. PressMan đã cung cấp tài liệu cho giáo trình này
PGS.TS Nguyễn Ngọc Bình , FIT –HUT
TổNG QUAN
Kiểm tra hộp đen trên nền dữ liệuSự phân loạiNhững phương thức
Kiểm tra ranh giới giá trị Vùng phân chia tương đương Những bảng quyết định. Kiểm tra ngẫu nhiên, khi đoán lỗi
Ví dụ Kiểm tra hộp trắng trên nền cấu trúc Kiểm tra hộp trắng trên nền dữ liệu, cấu trúc Kiểm tra hộp đen trên nền cấu trúc
2
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM TRA KÍCH THƯớC CủA PHầN MềM
1. Kiểm tra cái gì?a.Những đặc trưng của phần mềm.(thiết kế,nhúng?ngôn
ngữ…)b.Những yêu cầu(thuộc tính/chất lượng mà chúng tôi muốn từ
phần mềm)c.Mục đích(Phát triển cái gì, những lỗi gì,bước tiếp theo là gì).
2. Kiểm tra như thế nào?a.Phương thức(tiêu chuẩn thích hợp: làm sao để phát sinh bao
nhiêu lần kiểm tra)b. Những giả thiết (những giới hạn, những đơn giản hóa,
những kinh nghiệm)c. Tổ chức (tài liệu, sự thi hành, sự thực hiện: nền tảng, tương
tác, lô)d. Ai kiểm tra?(lập trình viên, người sử dụng, hãng thứ ba)
3. Những kết quả được ước lượng như thế nào?3
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
NHữNG KÍCH THƯớC VÀ BảN Đồ KHÁI NIệM
4
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
MụC ĐÍCH KIểM TRA
Pha phát triển phần mềm:
5
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM TRA PHƯƠNG THứC KÍCHTHƯớC
6
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM TRA PHÂN LOạI HộP ĐEN TRÊN NềN Dữ LIệU
Tất cả những yêu cầu: một vài tính lôgíc / quan hệ toán học vào/ra mục đích: kiểm tra đơn vị, những lỗi chức năng phương pháp: hộp đen, CSDL giả thiết: cả hai đơn/đa giả sử lỗi nhiều
kiểm tra giá trị biên Sự cầm cố (male: Đại số Bool, tuổi: interger tiền lương:
integer): integer phương thức: những lỗi tiêu biểu (những ranh giới của những
miền) begin if (male) then equivalence partitioning/decision tables return ((18<=age<35)?(75*salary):(31<=age<40)?(55*salary):
(30*salary)) Phương pháp: hiệu quả 7
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
CHạY VÍ Dụ: Sự CầM Cố Đầu vào:gender [m,f], age [18-55], monthly salary [0-
10000] Đầu ra:Cầm cố cho tổng số một người Những yêu cầu: Cầm cố: tiền lương * hệ số Chương trình Mortgage (male:Boolean, age:Integer, salary:Integer):
Integer begin if (male) then return ((18<=age<35)?(75*salary):(31<=age<40)?(55*salary):
(30*salary)) else /* female */ return ((18<=age<30)?(75*salary):(31<=age<40)?(50*salary):
(35*salary)) end
8
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM TRA Sự CầM Cố CủA CHƯƠNG TRÌNH
mỗi trường hợp điển hình= nhập vào sự kết hợp+ chờ đợi giá trị đầu ra
Kiểm tra đầy đủ yêu cầu tất cả đầu vào những sự kết hợp: không thể làm được
Lự chọn một số kết hợp: Một/nhiều lỗi kiểu được nhập vào: số lượng, đếm được Những lỗi tiêu biểu hiệu quả: những sự kết hợp được nhập vào dư thừa
9
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM TRA GIÁ TRị BIÊN phát hiện ra những lỗi để với miền được nhập
vào nảy bật lên cho số nguyên được nhập vào x với miền
[a,b], kiểm tra đầy đủ yêu cầu tất cả đầu vào những giá trị được nhập vào vòng quanh a và b
#Kiểm tra= cho n đầu vào, 4n+1 được nhập vào lựa chọn một số sự kết hợp
Giả thiết: Số lượng độc lập được nhập vào Giả thiết có 1 lỗi
10
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
Sự LINH HOạT CủA GIÁ TRị BIÊN
Kiểm thử những giá trị bên ngoài miền #kiểm thử=cho n những biến số vào, 6n+1
nhập vào những kết hợp a test: <x_nom, y_max+1, expected output>
11
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
GIÁ TRị BIÊN TRƯờNG HợP XấU NHấT
Giả định nhiều lỗi # Kiểm thử= Cho n những biến số vào, 5n
nhập vào những kết hợp
12
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
BV TRƯờNG HợP LINH HOạT XấU NHấT
Giả định nhiều lỗi,kiểm thử bên ngoài miền # Kiểm thử= Gộp vào những quan hệ cho n biến số
vào, 7n sự kết hợp được nhập vào
13
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
GộP VÀO NHữNG QUAN Hệ
Phương thức A gộp phương thức B Nếu A kiểm thử tối thiểu mà B kiểm thử ( có thể)
Gộp vào những quan hệ cho những phương án những giá trị biên?
(Giả định một giá pháp định cố định cho mỗi đầu vào)
14
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM THử CầM Cố GIÁ TRị BIÊN
Những quan sát Nhập vào giới không có số lượng Những ranh giới không cố định:
Nhập vào giới và tuổi không độc lập! Phương án‘giá trị biên’ có thể không
phát hiện ra lỗi(nếu giải pháp định giới "nam")
nhiều lỗi hơn trong chương trình so với chúng ta có thể chờ đợi bất kỳ phương án giá trị biên nào tới phát hiện được dò
15
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
TÓM LƯợC KIểM THử GIÁ TRị BIÊN
Phạm vi: không tốt #kiểm thử: có mức độ đến rất nhiều Cách dùng: Dễ hiểu, dễ dàng đối với sự
thi hành Khi dùng:
Nhập vào giá trị độc lậpNhững số lượng đếm được,vd như tuổiRõ ràng, khi nghi ngờ những lỗi ranh giới
Thấy những tài liệu:Zhu Jorgensen
16
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
VÙNG PHÂN CHIA TƯƠNG ĐƯƠNG Phát hiện ra những lỗi để tính toán những lỗi đó. Cho số nguyên được nhập vào x với miền [a,b] những
giá trị được nhập vào được phân chia trong những miền s_x, kiểm thử từ mỗi miền con
Giả định: Những biến độc lập Sự dư thừa trong miền con
Phương án yếu hay thay đối: Giả định:- Những biến độc lập- Giả sử lỗi ít
#kiểm thử= giá trị cực đại s_x cho bất kỳ đầu vào x
17
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
VÙNG PHÂN CHIA TƯƠNG ĐƯƠNG
Phương án bình thường mạnh: Giả định:
Giả định lỗi nhiều #tests = s_x for each input x
18
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
VÙNG PHÂN CHIA TƯƠNG ĐƯƠNG
phương án linh hoạt yếu: Kiểm thử bên ngoài miền Giả định:
Những biến độc lập Giả định ít lỗi
#tests =max s_x for any input x+2*(#inputs)
19
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
VÙNG PHÂN CHIA TƯƠNG ĐƯƠNG
phương án linh hoạt mạnh: Kiểm thử bên ngoài miềnGiả định:
Giả định nhiều lỗi #tests = (s_x+2) for each input x
20
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
GộP VÀO NHữNG QUAN Hệ
Gộp vào những quan hệ cho những phương án phân chia tương đương?
(Giả định cùng giá trị chọn cho mỗi đầu vào, cho mỗi miền con)
21
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
TÓM LƯợC PHÂN CHIA VÙNG CON TƯƠNG ĐƯƠNG Phạm vi:vừa phải #Kiểm thử: nhỏ vừa phải Cách dùng:những nghiên cứu nào đó
cần những yêu cầu Khi dùng:
Nhập độc lậpSố đếm được toán những lỗi khi nghi ngờ tínhkhi sự dư thừa có thể được giả địnhcó thể dễ dàng được kết hợp với giá trị
biên22
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
BảNG KIểM THử QUYếT ĐịNH vẽ đồ thị cũng được biết như hiệu ứng tác động
nguyên nhân phát hiện ra những lỗi để làm với những lỗi tính
toán đầu vào được phân chia thông qua những điều
kiện giả định : những biến phụ thuộc #Kiểm thử:phụ thuộc vào độ hạt của những điều
kiện/ những hoạt động
23
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
BảNG KIểM THử QUYếT ĐịNH CầM Cố
24
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
TÓM LƯợC BảNG KIểM THử QUYếT ĐịNH Phạm vi : tốt
#kiểm thử : lớn vừa phải Cách dùng: Những nghiên cứu nào đó cần những
yêu cầu
Khi dùng: Nhập vào sự phụ thuộc tính toán những lỗi khi nghi ngờ có thể kết hợp với kiểm thử ranh giới (khó khăn) Xem những tài liệu:
Zhu Jorgensen
25
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
LỗI PHỏNG ĐOÁN & KIểM THử NGẫU NHIÊN
Lỗi phỏng đoán:Không có phương thức phức tạp, chỉ thí
nghiệm và nhìn thấy nếu cái gì đó trục trặcVài người nào đó có một sở trường để phơi
bày những sự thất bại ( Chẳng hạn. đứa trẻ trẻ!)
Lỗi ngẫu nhiên:Lựa chọn những sự kết hợp được nhập vào
ngẫu nhiênCả hai có thể rất có hiệu quả, nhưng cần phải
được sử dụng ngoài kiểm thử có hệ thống 26
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
NHữNG HƯớNG DẫN KIểM THử HộP ĐEN TRÊN NềN Dữ LIệU
Những đầu vào tùy thuộc vào lẫn nhau? bảng quyết định Nghi ngờ những lỗi tính toán? bảng quyết định hoặc sự phân chia tương đương (nhìn
thấy viên đạn thứ 1) Nghi ngờ những lỗi ranh giới? tiêu chuẩn thích hợp giá trị biên Sự giả định lỗi đơn? phương án trường hợp khác nhau phần xấu nhất Nghi ngờ những lỗi bên ngoài miền? phương án linh hoạt Muốn biết điều gì từ một người sử dụng không trung
bình làm? lỗi dự đoán, kiểm thử ngẫu nhiên Những sự kết hợp có thể và cần phải xây dựng hợp lý!
27
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
PHÁC THảO
Kiểm thử hộp đen dữ liệu nền Kiểm thử hộp trắng có cấu trúc
Sự phân loạiVí dụTiêu chuẩn vừa đủKiểm thử được sinh raChỉ dẫn
Kiểm thử hộp trắng trên nền dữ liệu/ cấu trúc
Kiểm thử hộp đen trên nền cấu trúc28
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
NHữNG KÍCH THƯớC+ MÔ HÌNH KHÁI NIệM
29
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM THử MụC ĐÍCH
Pha phát triển phần mềm:
30
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
PHƯƠNG THứC KIểM THử KÍCH THƯớC
Efficiency coverage :đưa ra những hiệu lực Error seeding: lỗi bắt đầu
31
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM THử PHÂN LOạI NềN CấU TRÚC HộP TRắNG
Tất cả tiêu chuẩn Những yêu cầu:một số lôgíc /toán học
quan hệ vào/ra những đặc trưng phần mềm: sẵn
có,ngôn ngữ lập trình bắt buộc Mục đích:kiểm thử đơn vị, các lỗi chức
năng Phương thức:hộp trắng, nền cấu
trúc,mức độ bao phủ, hiệu lực. Giả định: Hai giả định lỗi cả đơn lẫn đa
32
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
CHạY VÍ Dụ: HÌNH TAM GIÁC
33
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM THử CHƯƠNG TRÌNH TAM GIÁC
34
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM THử CHƯƠNG TRÌNH TAM GIÁC
35
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM THử CHƯƠNG TRÌNH TAM GIÁC
36
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
NHữNG Đồ THị CHƯƠNG TRÌNH & KIểM THử
những đường không thể làm được: không thể xuất hiện những sự kết hợp(những điểm phụ
thuộc) mã chết
Đường khác: có lẽ vô hạn ( thành vòng lặp!)
tiêu chuẩn phạm vi: …
37
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
NHữNG Đồ THị CHƯƠNG TRÌNH & KIểM THử Tiêu chuẩn phạm vi:
mỗi điểm được thực hiện:nhánh/ quyết định: mỗi cạnh được thực
hiện(nhiều) điều kiện:
giả sử p_1, p_2,... nhỏ nhất là những phần trong điều kiên c(thuộc tính nguyên tử)
phạm vi điều kiện: mỗi điều kiện được thực hiện thường đến nỗi mỗi nguyên tử p_i có ước lượng tới cả hai giá trị đúng
nhiều phạm vi điều kiện: mỗi điều kiện được thực hiện thường đến nỗi những nguyên tử có ước lượng tới tất cả các sự kết hợp giá trị đúng có thể xảy ra
Tất cả đường 38
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
GộP VÀO NHữNG QUAN Hệ
A B :Tiêu chuẩn A tiêu chuẩn những tổng B nếu A kiểm thử A kiểm thử tối thiểu những gì B kiểm thử
Ghi chú: nhiều phạm vi điều kiện kiểm tra, nhưng có thể hiển thị ít lỗi hơn nhánh + diều kiên đưa ra(Frankl & Weyuker, Provable Improvements on Branch Testing, IEEE Trans. Softw. Eng.:19(10), 1993)
39
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM THử CHƯƠNG TRÌNH TAM GIÁC
40
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
QUAN SÁT Làm sao để xây dựng những kiểm thử & cho
bao trùm được mọi thứ? Nguyên tắc:
Bắt đầu với sự phát sinh kiểm thử dựa vào phương thức hộp đen
Đo phạm vi hộp trắng cho máy đo kiểm thử hộp đen Công cụ dùng. Tiêu chuẩn phạm vi nào? Bao nhiêu những lỗi có thể ở lại? Một mẩu mạnh hơn phạm vi nhánh thì rất có hiệu
quả, chẳng hạn nhánh+ phạm vi điều kiện Thực hành công nghiệp: thay đổi từ phạm vi phát biểu ( 100%?) tới nhiều
phạm vi (? %) 41
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
CÁI MÀ CHÚNG TA ĐÃ KHÔNG ĐƯợC BÀN LUậN
Vòng lặp:một lần và nhân chữ số khôngnhân tối đa + số cực tiểu…
Giải pháp lập trình những đồ thị:LCSAJ những khối trên điểm
Như bậc thang kiểm thử: sự ngưng tụ đồ thị
Những sự xung khắc giữa đồ thị và những yêu cầu:những đường khả thi không phải được yêu cầuyêu cầu những đường không phải là hiện tại/
khả thi42
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
CÁC ĐIểM CHÍNH
Kiểm thử hộp đen dựa vào dữ liệu Kiểm thử hộp trắng dựa vào cấu trúc Kiểm thử hộp trắng dựa vào dữ liệu/cấu trúc Kiểm thử hộp đen dựa vào cấu trúc
43
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
TIÊU CHUẩN Dữ LIệU/CấU TRÚC
với biến x trong chương trình:xác định biến: x nhận một giá trị (gán giá trị)sử dụng biến: giá trị trong x được sử dụng
có sự tính toán (trong việc gán giá trị cho x) có tính xác định (trong các điều kiện)
tiêu chuẩn:với mỗi sự xác định biến x tại điểm n, cho
mỗi/một số use occurrence that can be reached
from n, each/some path is executed
44
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM THử HộP TRắNG DựA TRÊN CấU TRÚC Tính bao phủ: tốt hơn
nhưng để đảm bảo 100% thì không thể! tests: chỉ một vài trường hợp trong rất nhiều
trường hợp Usage: tạo ra test tổng quát khó, nhưng dễ
hơn nếu chỉ phủ một phạm vi cụ thể Khi nào thì sử dụng:
trong trường hợp kết nối các kiểm thử hộp đen với nhau
các phần quan trọng trong của phần mềm khi có sẵn các công cụ
45
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
CÁC ĐIểM CHÍNH
Kiểm thử hộp đen dựa vào dữ liệu Kiểm thử hộp trắng dựa vào cấu trúc Kiểm thử hộp trắng dựa vào dữ liệu/cấu trúc Kiểm thử hộp đen dựa vào cấu trúc
46
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
XÁC ĐịNH KIểM THử Kiểm thử là gì?
Các thành phần của phần mềm (thiết kế/nhúng?/ngôn ngữ/...)
Các yêu cầu (đặc tính/chất lượng của phần mềm là gì) Mục đích (Các giai đoạn phát triển, các loại lỗi, bước tiếp
theo là gì) Kiểm thử như thế nào?
Phương pháp (tiêu chuẩn đầy đủ: how to generate how many tests)
Giả thiết (các giới hạn, các trường hợp đơn giản, kinh nghiệm)
Tổ chức (tài liệu, thực hiện, môi trường thực thi, tương tác, khối)
Ai kiểm thử? (lập trình viên, người dùng, bên thứ ba) Làm thể nào để lượng giá kết quả kiểm thử?
47
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
LƯợC Đồ KHÁI NIệM + KÍCH THƯớC
48
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
MụC ĐÍCH KIểM THử
49
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
XÁC ĐịNH CÁC PHƯƠNG PHÁP KIểM THử
50
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
PHÂN LOạI KIểM THử HộP ĐEN
tất cả các tiêu chuẩncác yêu cầu: ứng sử, định nghĩa trong FSMcác đặc trưng phần mềm: có thể được mô hình
hoá như trong FSMmục đích: kiểm thử đơn vị, các lỗi chức năngphương pháp: hộp đen, cấu trúc, phủ, khả năng
chịu quá tảiGiả thiết: ...
51
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
VÍ Dụ: PHầN MềM MUSICAL TOYinput:
sự kiện: một nút lệnh được nhấn
output:sự kiện: âm thanh thanh đổi
requirements:FSM (ứng xử)
testing: ...
1.PlayMusic2. inputs pushRhythm, pushSong,pushQuit;3. outputs startRhythm, startSong, Quit;4. state Rhythm, Song: Boolean;5. begin6. while (true) do7. if (pushQuit) then8. Rhythm, Song := false, false;9. if (Rhythm and Song) then outputQuit fi10. elsif (pushRhythm) then11. if (Rhythm) then output Rhythm fi;12. Rhythm := true13. elsif (pushSong) then14. if (Song) then output Song fi;15. Song := true fi16. od;17. end
52
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
CÁC YÊU CầU FSM CủA PHầN MềM
1. PlayMusic2. inputs pushRhythm, pushSong,pushQuit;3. outputs startRhythm, startSong, Quit;4. state Rhythm, Song: Boolean;5. begin6. while (true) do7. if (pushQuit) then8. Rhythm, Song := false, false;9. if (Rhythm and Song) then outputQuit fi10. elsif (pushRhythm) then11. if (Rhythm) then output Rhythm fi;12. Rhythm := true13. elsif (pushSong) then14. if (Song) then output Song fi;15. Song := true fi16. od;17. end
53
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
MộT FSM LÀ GÌ? FSM (Finite State Machine), or
Mealy machine: <S,I,O,δ,λ> máy trạng thái hữu hạn trạng thái S (thường là trạng
thái ban đầu) đầu vào I, đầu ra O hàm biến đổi: δ:S×I→S hàm kết xuất: λ:S×I→O nhãn chỉ không có kết quả: ‘-’ các giả định!
phù hợp cho: các mô hình trừu tượng các giao diện, giao thức, có
tính nhúng software, ...
formal test generation
54
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
NHữNG GIả ĐịNH VớI MÔ HÌNH FSM
FSM phải có tính xác định và có đầu
vào (deterministic + input-enabled): δ và λ là các hàm phù
hợp tính hữu hạn:
I,O,S hữu hạn tính kết nỗi mạnh:
mỗi trạng thái có thể chuyển từ bất cử trạng thái nào đến
tính tối ưu: không có các trạng thái
giống nhau không có trạng thái thừa
55
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
HAI MÔ HÌNH FSM
Đặc tả (Specification) Mô hình FSM yêu cầu satisfies restrictions previous
slide được sử dụng cho kiểm
thử phát sinh
Thực thi (Implementation) Mô hình FSM của phần
mêm để kiểm thử satisfies restrictions except
‘reduced’ không cần thiết nhưng:
chứng minh sự kiểm thử của trạng thái cơ sở FSM
các trạng thái phải được dự đoán trước 56
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
KIểM THử IMPL VS. SPEC:
kiểm thử= trình từ đầu vào: (1) a? b? a? (2) b? c? a? kết quả mong chờ= các kết quả thực
mong đợi: (1) e! e! e! (2) e! - - thực sự: (1) e! e! e! (2) e! e! e!
Impl thực thi Spec nếu paths(Impl) = paths(Spec)
57Kiểm Thử & Đảm Bảo Chất Lượng
KIểM THử IMPL VS. SPEC:
Impl thực thi Spec nếu paths(Impl) = paths(Spec) các lỗi có thể xảy ra:
kết quả sai (lỗi tính toán) thừa/thiếu các trạng thái (thừa/thiếu các đặc tính) chuyển tiếp đến trạng thái sai (lỗi tính toán)
những phần (paths) nào cần kiểm tra??
58Kiểm Thử & Đảm Bảo Chất Lượng
SINH KIểM THử Từ ĐặC Tả kiểm thử mỗi bước chuyển tiếp: <s,i?>
1. đi đến trạng thái s từ một trạng thái bất kỳ(đồng bộ + tuần tự)
2. đầu vào i có được chấp nhận?(kiểm thử bước chuyển tiếp)
3. kiểm tra đầu ra λ(s,i)(kiểm thử bước chuyển tiếp)
4. kiểm tra nếu trong trạng thái δ(s,i)(UIO-sequence/distinguishing sequence/W-set/...)
Có lỗi nếu có một cái gì đó trong bước 3 hay 4 sai.
59
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
SINH KIểM THử Từ ĐặC Tả
Kết quả kiểm thử:
bước chuyển
đồng bộ trình tự đầu ra mong đợi
xác nhận trạng thái
<s0,a>
<s0,b>
...
60Kiểm Thử & Đảm Bảo Chất Lượng
NHữNG GÌ CÒN LạI MÀ CHÚNG TA CHƯA XÉT ĐếN Tại sao nó đúng? Các hệ thống không có tính xác định Các tham số dữ liệu Tài liệu: Lee and Yannakakis, “Principles and
Methods of Testing Finite State machines—A survey”,Proc. of the IEEE:84(8), 1996.
Sự phân biệt đầu vào và ra trong các bước chuyển
Các tiêu chuẩn thực thi khác (subsume rel) Kiểm thử đa-tiến trình/phân phối Tóm tắt 61
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
CÁC GIả ĐịNH FSM = <S,I,O,δ,λ> Đặc tả (Spec) FSM:
có tính xác định,hoàn chỉnh, tối ưu có sự đồng bộ có một trình tự vào ra duy nhất (UIO sequence –
unique input/output) cho mỗi trạng thái Thực thi (Impl) FSM :
xác đinh, hoàn chỉnh không có nhiều trạng thái hơn so với phần đặc tả
(Spec) Khái quát hoá các hàm δ,λ :
δ(s, i_1 i_2 ... i_n) = t (target state of a sequence of inputs)
λ(s, i_1 i_2 ... i_n) = o_1 o_2 ... o_n (trình tự của đầu ra) 62
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
ĐồNG Bộ
Trình tự của đầu vào Đưa FSM vào trong các trạng thái Xác định thông qua sơ đồ khối:
Đỉnh: tập các trạng thái S’={s,t,...} (ban đầu là: S)
Cạnh: từ S’ đến S’’ với i/o ta cóS’’ = { δ(s,i) | sS’ and λ(s,i)=o }
Quá trình đồng bộ σ tất cả các phần của σ từ S tương tự như {s} σ không phải khi nào cũng thoát!! thường thì sẽ có sự xác lập lại nếu có thoát, ta dễ dàng xác định
nó trên sơ đồ khôi 63
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
SƠ Đồ KHốI CủA MUSICAL TOY CÓ THể NHƯ SAU
Synchronising sequence: PushQuit?
64Kiểm Thử & Đảm Bảo Chất Lượng
FSM KHÁC+ SƠ Đồ KHốI
synchronising sequence? no!(see Lee & Yannakakis for proof construction)
65Kiểm Thử & Đảm Bảo Chất Lượng
HOMING VS. SYNCHRONISINGTRả Về VÀ ĐồNG Bộ HÓA
quá trình đồng bộ: không chú ý đến đầu ra luôn đưa FSM về cùng một trạng thái không phải lúc nào cũng thoát
quá trình trả về (homing sequence): kiểm tra đầu ra đầu ra xác định trạng thái cuối luôn thoát (exists) kiểm thử thêm:
kiểm tra đầu ra, xác định trạng thái cuối dịch trạng thái ban đầu (hay trực tiếp để kiểm thử dựa trên trạng thái (state-
under-test))66
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
QUI TRÌNH UIO
qui trình duy nhất vào/ra xác định trạng thái ban đầu
inputs (+trạng thái kết thúc dự đoán)
xác định thông qua sơ đồ khối với các trạng thái ban đầu: đỉnh: tập các trạng thái
S’={s,t,...} (ban đầu là: S) cạnh nối S’ đến S’’ với i1/o1 i2/02 ...
S’’={ sS’ | λ(s,i1 i2...) = o1 o2... } UIO cho s: dẫn tới {s} không phải khi nào cũng thoát!! 67
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
VớI MUSICAL TOY
UIO sequence for any state: PushRhythm? PushSong?
68Kiểm Thử & Đảm Bảo Chất Lượng
MộT Số THể HIệN KHÁC CủA FSM
69
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
UIO VS W-SET UIO:
1 quá trình vào/ra cho mỗi trạng thái không phải khi nào cũng thoát
W-set: tập W(s) của đầu vào (+ output)
cho trạng thái s với mỗi cặp s,s’: W(s) bao gồm một trình tự phân
biệts từ s’
luôn thoát ngoài ra trong quá trình kiểm thử:
số quá trình lớn để thiết lập xác minh trạng thái cho s, phái lặp lại tất
cả các thử nghiêm trong W(s).70
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
Mở RộNG 1
Spec/Impl FSM: các tham số dữ liệu (EFSM):
chỉ kiểm thử cấu trúc điều khiển (phủ tầm thường) tính toán hoàn thiện FSM (cố gắng lớn, rất nhiều
test) kết nối với phương pháp kiểm thử hộp đen
không xác định: kiểm tra thuật toán một cách ngẫu nhiên
hoàn chỉnh: chỉ phần lý thuyết
71
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
Mở RộNG 2
Impl FSM : có nhiều hơn n trạng thái so với Spec:
để phủ hoàn toàn: cần một số giai thừa phép thử |I|nkhông mô hình FSM nào có thể: thay thế mô hình hệ chuyển tiếp (LTS) phương pháp vào ra thích hợp (input/output
conformance (ioco)) xem KUN/UTwente phần kiểm thử:http://www.cs.kun.nl/~tretmans/testtechnieken/
72
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng
TÓM TắT KIểM THử HộP ĐEN CấU TRÚC
Tính phủ (Coverage): Hoàn chỉnh tốt hơn xem phần mở rộng
#kiểm thử (tests): trung bìnhSử dụng (Usage): khó mô hình FSM và
thực hiện kiểm thửKhi nào sử dụng:
khi yêu cầu= (quan trọng) ứng xử (behaviour)
khi tính hoàn chỉnh là cần thiếtkiểm thử đơn vị/hệ thống/chấp nhậncông cụ kiểm thử có sẵn
73
Kiể
m T
hử &
Đảm
Bảo C
hất Lư
ợng