Chuong 4 - Nhung Phuong Phap Kiem Thu

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


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


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ệ 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


35

Kiể

m T

hử &

Đảm

Bảo C

hất Lư

ợng


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


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


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??


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>

...


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?


FSM KHÁC+ SƠ Đồ KHốI

synchronising sequence? no!(see Lee & Yannakakis for proof construction)


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?


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

Documents

Chuong 4 - Nhung Phuong Phap Kiem Thu