MỞ ĐẦU
!"#$%&'
()*$%%+$#$&,
++/#!01"
2$3+ !45+/
657&89:;<=>?"
+&@ *3+/!
3AB6+/
+!C3AD!D"E
6F#&
G+H:;#I(3
893539!J.:K+H!L!F5-
:$*M@N5:;;+ O
M2!&8(.*'3893539!J.:
K+HCD#6!
$2;PBQ5'.3DP6R
;+&
8+*K'
45893539J.:K+H+8939 &
N#'D8939$893539.S
5&@(.'.SR;
+3A36!<
8939$893539*CD6F
3A/+$893539T&@(.435B5
#'!T6C5'$8935392U
#I(!UD2'3;K5Q5
939*6FQ5893539&
VTT35<
Mở đầu:W!&
Chương 1:X3M)(&
Chương 2:8R5393539!&
Chương 3:X#I(393539
!&
Chương 4:Y555Z+9F&
Chương 5: Một số ví dụ thực thi tượng trưng với jpf.
Kết luận: Trình bày kết quả và nêu nhận xét.
1
2
CHƯƠNG 1: CƠ SỞ LÝ LUẬN
1.1. Tổng quan kiểm thử phần mềm.
#5!F$!
62::5'6FQ53D
[+\ !F#&C6
+55!*!(
!J!C]!6!F/Q
#5&
8#I(##'O4M
;+ !"!%
^25T%$3C_0:
[P."`;+ `3D
[U<
• V;!F7.:+a#$#$
&
• 8'!B#b7&
• XC#5!F/!"&
• @!;!F7Q52::5&
8H.J*#C!F
26;B&89
.%#!F$35#.:
!FP!\(!F6c9
^(F4+5
:!45E\_#!F$
: 3P +&N(.*
%#2\9.
6!\&
Vì vậy tích hợp với quá trình phát triển phần mềm, có một số
lợi ích:
• d5%C.53*C
K5!D+
35/54K!";K4
&V F$"Q5#;&
• X6'D): +6
F$%&
• X6K3+ P95E
E*!!O3&
• V3D[+5.:&
1.2. Khái niệm Test Case
3
8+*'K
.#C22D35<(#$4*$
#$893*933*93!<
Hình 1: Một quy trình kiểm tra cơ bản.
8!C893539!F$2$#$93&G !"
Q5$#$93$O!\8935392
#5$%:2D&W5!4$#$
93$3;57*C2D!D6D#
5e]e$6D.:#5&
@(.'45893539D!25
7!!D2D6F&V!F!C*
$D893539f
G893539C#*!F$
#$!#!FC15L.:!55.
#'&G893539K25Tg2D<
• G'D<!D!#C!$#&
• V<!D!F5.+/$*!F3
+ !!#&
• $D<#$DDJ!F#
*;1!F!L15L.:&
893539C)h5'H57* !"!55
KF93U5%6C*!
6F+!F&
1.3. Các nhóm kiểm định phần mềm
8h#!\6F5.:
$*C#I(C-9
25C"<d-"LTh^35+955.33_*#
+/!^+.5+5593_#I(;+5
4
:'^+9i2539+9Z5_&j5C!(
-56F4;LT*#
CHP)4;JF5k'
&
Phân tích mã nguồn tĩnh #I(%
#'.:4.!C&'#I
(kiểm thử dữ liệu động!01D4.+/
!(*#I(-"LThOP9P]L
TQ5&
Kỹ thuật kiểm thử phần mềm dựa trên mô hình<#
5CM:M!!F!F#'!F
JFC5J!FP9P]&lJFC5
F21/$Q5#O/4
/'`#"5457!F-&I(
JFC5!DC5!FP9P]+!CD
#'5#$K5-"!
3B'-"!C:LT&
P +P*B5D3+
93539^KF#_#&X6FQ5
# 6(F93539B
53+ &j5:""Q5!6F#
!CD6F!F#!Q
+0 D. ^ mn 959_ ! Q +/ ^+55
959_&8:";6(#6D
!!#:^"+ <A#D!4
6Bk955293_&8#:"
;5((+/#;%!!
#6B&
oU#I(-"+5:'35#
JFC5LTQ5!F#*-
"6BQ5(+/;%!
!#3A+p+&l5!C*
35(935393A5C"P*!D2D
:"mn+559593$
(M;LT.&j/5*$.!F
!3AD'3;
.:5#&@$((.*
C!F#!2U.*!94#$
5
D[*P]!FKF*!2%
*$#"3DP6&
Đánh giá tập dữ liệu kiểm thử: N4J/
!D*3A#'$$#;:
(6D+/!C&N5.D#O"RFQ5
+/!RFQ5*3F!3
F4S&C2*
+/!*!53A!F4!9+q4&8
##'C' !45$#$[*
Orr##-#'
$!C!!F6F&@$K5
D7!F(+/1C#
54!F!(.5%&
VQ5.;!!.!Q2U5!!F
45.;!#&N$##'!.!Q!F$
7#"54Q5!Th5B5213C
%&X636Q5KFS#'5&
5#!D#;4
!554!Q5&XB5C45
5#!!4!F4C2U!5
2$!2*4!!#&
1.4. Vấn đề sinh Test case từ yêu cầu phần mềm
8+*K'
45893539J.:K+H+8939 &
N#'D8939$893539.S
5&@(.'.SR;
+3A36!<8939$
893539*CD6F3A
/+C8939$893539T^CKF
93H5_&@(.B5D[C5!T2C5
!3545893539DC[6
F&V!.*B5D:;
#I(!!45893539&@45893539
!SD2'3;K5Q5
939*BD2"&
lB5458935393AB9395
6!-a5qQ5.:&
6
N$2.!F3*6!C!F4213*
$#K5T&
@(.:;' 3893
539!J.:K+H6/"
$+&l.
U !"45893539CD*C6
F&WBD2'3;K5Q5939*D
2"6F!F-
5&
7
CHƯƠNG 2: TỔNG QUAN VỀ QUÁ TRÌNH SINH TEST CASE
TỰ ĐỘNG
2.1. Giới thiệu
@93'657
0!KQ5&VrD"Q593
2U5.E!(.Q5B5!5
r!C5C&G/'5
7'K9345893539!'
D;93*%6!\!F
$(9;!(&X.2.
R5#I(4893539!&
XR;3+ -3!#
Q5!':5!$93&G
933A!F#;2M#
#6(*15L.:Q5#&8"D
Q5B5P(#;. 3F
%!FO35#'2&V.
F 6FQ5893539!F45&
X#535893539!L!F
!P6&G8935393:D;93*%
6!\!F$(9;!
(&893539C!F$5$J.:K+H*J
.:*J39539&G/F$
Q545893539J!D$#$!CBC
!F3530!K3s3!3
+ #!F45&8:!C*#
893539!F3525!#I353
#'6(K!D.:
$#$&V.3Arr3AD"Q5P
+#%!F42130
!KQ53D[&
2.2. Tổng quan về các phương pháp sinh Test case
G$(!F!5545893539*
35"a:*C !"*!\3
6'&I(a:P!\893539+5:
D!\&I(!\!K+a3+ T
'#3!P!\(F!K+a!!F
8
2545893539HF!K+a.&
N/#I(.C!F-5h!&I
(hK!F+5:#)'D*F4
#I(!!4!FJ+/$2U4.
#93&I(!\ :P!\
89353925T :!L!F57t4
--&X#I('Q5
893539!F35!";4
!P!\893539&
u6:;35893539+5
:!D*.:#'!4v>>?893539&
N'/'!F3+ !C!F!D35
893539&J#wGx^wZ9+G+9x559_'/
!F3+ L6:;3+ F!T
wGx 359i5 +553* 39i539 +553* 3999
+553*y!35893539+a!$35893
539+5:'&
2.2.1. Sinh Test case dựa trên đặc tả
z893539+5:!D3893539
194!FP!\+5:!D!4
5893539J2!T4wGx&@#!Q
"*.$O35-#I(
!F!55Xg&X#I(!L3+ 2!T
4wGxM3M!352(!
#93933!P(#93&X
$(a*O5!D2!T4
;Q5!C*!\qP4!552U3#$
FL!D&z5!C9397:[!O
35&8C4*%!F53#'6/5
!D2!T4!F!552MK3+ &
G :!P!\!D!FD$!F+5:
:[O35"F!#I
(452!#93"65Q5
K&
2.2.2. Sinh Test case dựa trên mô hình
wGx!L(!F35-J'!T
$#$*'!5!F
9
!EKM"EQ5C&8.:*
!T93!L#'5-D(
wGx*3$ #:['C5!F&
V 6!5-*2MR;
*"Q593C${>?R"
&V55$.!
5#DE3+ wGx93&
V5'93+5:'Q5(
3+ Q52!T4&X2
!TO(*5+3*
5Q5B&X2!T42+p+0!#
J4.!$4#*C64+0!
#J4!.!$4!#PD.52:
.4&wGxC'!C!F
2$!$#I('!F^|2}9G+9899_
!L:';ES!F3+
93&
2.2.3. Sinh Test case hướng đường dẫn
G#[3+ $F#$\.:R
$35893539!K+a!L!F!55&
8!F!P6C!F(4$(
!K+a&d.!L:6!Q5$
(35893539!!L6D(
35893539+5:;#$\.:&
VK+a!F25!FP9P]J2J2
89353935!C!F:;!B&d
;#$\.:!F3+ !P!\893539*
!01D!\6!\]35893539
D&XF$Q5.!CC#'!0126;
3!O53#'26;#I(
!45+/93&
2.3. Kiểm thử phần mềm và UML
XC5!493T!\*
;E**T*93D&oD3575
/3#2/55!4*S2!TwGx
E3+ 5!4&
10
Test Type
(Loại test)
Coverage
Criteria
Fault Model
(mô hình lỗi)
UML Diagram
(biều đồ UML)
Unit Code
Correctness, error handling
pre/post conditions, invariants
Class and state
diagrams
Function Functional
Functional and API behavior,
intergration issuses
Interaction and class
diagrams
System
Operationa
l scenarios
Workload, contention,
synchron, recovery
Use case, activity,
and interaction
diagrams
Regresstio
n
Functional
Unexpected behavior from
new/changed function
SAME AS
FUNCTION
Solution
Inter-
System
commun
Interop. Problems
Use case and
deployment
diagrams
Bảng 1: Phân biệt các biểu đồ UML và các mức độ test
8.:*6!Q53+ wGx#'#$B2U
3B)!932!TC!F
3+ /"5!4#5Q5.&
G6!D!FD.$#wGxC!F
+ D93&
XC~6!35<@6!!:5-6!:
5!$3+ 'wGx93&8939
!F357Q5P +O352D
'!!F3+ 93&8;5*'
J$!$"E!H
!F.:!893539&
11
CHƯƠNG 3: CÁC KỸ THUẬT VÀ PHƯƠNG PHÁP SINH TEST
CASE TỰ ĐỘNG
3.1. Kỹ thuật sinh Test case dựa trên đặc tả
+5:!D6.!F'93J!
DQ5#93&8.:*#!F
#'[J!D[*!DC!C
50Q.$932U]B
5!F!93#$D!FJ!
.&XC550"!DC!C50
93&V:6'$!#
5!5Q5C!B5.#'&8;5
6'!57893539!!3H
FQ593&
+5:!D!55!93
&VD[Q53DC!F3
+ 3+a$#$93;E
3D[&VDP!\"P#"542DQ5
*#'6B$2\421&•C!C*939
C'$.$"EQ53D[#'D
$P6C5J$$.$&
+5:!DJ!D[!55
$([*!F6B!D3
Q593;E#I(93#'+5:!
D&G54A/5!D93B5
%C!DT.&VD2D'D
[.Q5C!F3+ !6.
!F#$D+/93&XF"#
Q5#+5:!DT93HB
$#$*3+ 93!L6.!F!:[
!D*#!\!L!F!DQ593&VD
CS!F-";#DE93R!\&
XC25$("!D;E
[<^v_!D+5:'*^~_!D!\
!$"t4!D(C'
/*^g_!D+5:4&
X'/!D+5:'*r!C!F
!D[Q5+5:'Q5!F
$&N'/!D('D2U!5
12
5-[*535
;EC+ :B&X!D+5:4
'D!#Q5.$4&
X!D!F+5:4:2P!\!#
:.$*\2$P(
DC.$C!F]*5.!R
2$!R#$.$!F+p5&
3.1.1. Các phương thức đặc tả trạng thái SCR
XC!P!\4
2D&d.P!\:[93+5:!
D*!L'3893539!DzXu&
VDz€n59X3u9+5^zXu_P +2D!
P!\.:'!Fr
K5$&GF"Q5zXu!C6
B!FP!\]-"6B!F3+
!#53!T6*"OQ5!D&o:4!C*
;+ zXu6#DE+6$J.:
LT&N4Q5-"!L!F
+ !DzXu&
8!DzXu*+9533.4
4Q5C!F73.39+93+93&j
Q5X9P3.39C!FP!\2M+9533
4!33&G%+9533'D#"54Q5
Q5*25HQ52!FP
!\2MQ5+9533Q5&G'K
Q5!F!552M(FQ5!#'
Ko95& G99P6#\Q5!
#5.!RJ89•539F4&•!C*99
P!\K!*#!#P!\#DK
5&8'K*+59999P6
#!#6!\$ &
X+9+9533P!\"Q5
//!#6!\&G+955D
89#55+9*D+.89#
M+9!C*C89•539#
#'0M+9!C&z#'5.!RQ5+9
"262$Q5+9&N$!#
6!\$ 35!CM+9
13
*!#6!\C\262$&X
!DzXuP!\;E&z26
2$Q5q!'#q!FP!\
!D&G!DzXuCT2Q52$#'
!R53#t!\*2$#'
!R.#'D2:Q5!F.:
*B#'!F"*O :.:
!F2.+42D!F!F!5!$&
8:!C*$2$262$.#'!F#:q*
35!CB5C:6.BJ!D&X2$#'!R
C!FC!F332$q#'!Rq
:[P!\&
3.1.2. Kỹ thuật sinh ra Test case dựa theo đặc tính của
SCR
;!$!L
!FJ-!F+5:-"#'[
Q5.:&V.+a!$#$D#'
6*6! !"#$DQ5
#*$"D#&@
P!\!B.:q!#2M
B'D"P!C50$
FB6aC!!
#&I(3893539+59!DzXu$(:
[D.$355#;!J
P(`.:;E&N/:[.
6[*!!K#
*D!C545
5#&
Mô hình kiểm thử:
815L"3+ !#!*2$*
''!B!45#$D*35!C35893539!
15L.::2#$DP(&X'
.:5A!$:;345#
!!F+5:LC5!C&G!F!55M!
:)M!C315L#$D
P(93&
14
85.O25!#356
57!3+ #!:A!
#35&@#U !"5%*
25TDH+/!5&d.!55"+ 3+
z€n59X3u9+z9Z53^zXu_&
8'.*#!F453D
[!5;!*2&N
Ch589353935&X\!
\!Q5893539*/\.!F
15L$.:&X#6
\%F*T#$D!5!F!F*+/
!$!C4HF&N2Ch5
#3532J!";E2M
P)&X!";E!F7!"
#*35!C!F7(&V5;!C
h5#45!#M3;
!JFC5&
G'.!\h589353942;!<^v_;!
O35#$$*^~_;!O35!.!Q"*^g_
;!O35J#$$*^{_;!;&
X!\h5J;!!F!\h5M+&V+
/;!.*!"`.:!F+5:4
!F(!T\$*!F7!T\!D&
G%B6.4!"`.:*4
!55/3.$C&
XC+ 6D;!.*57;
!!F+5:3-2UF""&j5;!!:
C:5!$5*;!O35#$$!01
893539"3;!O35!.!Q
"*$;!O35!.!Q"!F3
+ *#3A15L!F;!O35#$$&•
(.O5;!:!F3+ &j5;!35C
)h5!(*O35.$!$!#
5+/54‚##$D
!$#2U
'5TP)O&NC!L+p5*O
35.$3.$*B
!F$(!#6#
5&
15
(1) Mức độ chỉnh sửa kế tiếp
G;!.:[O35
#6B&ƒ:M! %3.$!T\
!D!F"6&V.#Q5
!01U%!#25!!D!F15
L"6&
8C4*;!O35#$$!01%3.$
!T\!D!F"6&
(2) Mức độ chỉnh sửa đầy đủ các thuộc tính
G-1##!C"!
DC!F(';"P5.#'&N/35PC1
!DC+ar#3D[
&G;!O35!.!Q"50
#-*"6B5:6+/!
!#%!&G;!.!01U%!
%":%3.$!F#
!(*+!Cr!:q-1!
$C!L!F(';"P5.5&
• G!2;o95#'25
T/o95&@"+ *2;:
52$3o95!&
• G" 2 ; o95C T
!#'o95&G
"#'Co95S!&
N$!P6
"*%3P6!:2&
l5!O35"!.!Q!F+5:
:[#6BQ535.$!\`!#*
!017.$!\6!#.$!\!L
+a!$%#$D"6*%!#!L6.
DM!(!.$!\Q5C&z5!.!Q
"!F!\h535<
z5!.!Q"<G%!F6.\
!B35#6D!#"!
FC\*\Q5"3A''
!!F#&
z!\h5.2D!DU%!!F#
#'2\DM2M/!#&NU$O
35!.!Q"!F*3O35#$$3A
16
!F&V15L!01!C#5!#
3\Q5"*!#D!B35&
N$"^,„ƒ_*!#,*ƒD!B&
8(.*$"^,ƒ_*ƒD35&
X!D!15L!.!Q"3+
2;J&G 2;J
\-C\-4
B2*2$U34B&X
\-:5c+^„_*|^_*:5
…†*‡*ˆ*‰*Š*‹Œ‚N&
@"+ * 2;J^co_„X<
V55 J*3O35!.!Q"
2U!: &V:*!#!F7&
z5!C J!F!J!#*35!C
J!%!&N$•Q5C@*5\9Q5C
DC\•539*$5•Q5C„*5\9Q5CD
C\89&N$B*B•!F\
FQ5B&V.4%B/5!#
!&
G#!!L!4!F*\C!F3
FM43+ +. !&N$B„C
\89*D5DC\89*$B„C\
•539^P9{_*5SDC\•539
^S!F_&N$B@C\•539*D5
DC\•539‚$B@C\89*5
DC\•539^S!F_&N$B
N*B•\FQ5B&
17
Hình 4: Xây dựng các yêu cầu Test case từ cây biểu thức cú
pháp
j3{752;2::*O5D
oXQ5!#&8J:*o!#
^!FO5C'!F4_&8 ~*Q5
C*c!F\•539* g*X!F\
89&8JH*X!#&8 ~*
Q5XB@*!F\89&8 g*
c!Fr\89&WU g*coC
!F\89‚H.357&
Ga893539!.!Q"JD3+\.HF
#'HF*O3.$HF%&
8:!C*#I3#:C7/3#$F!.
!Q)h5Q5!#&/+/!
#'HFCB5%#S
32.qQ5!D&u6
UC425!*C
Q5K3+ !2D!DU!#25
!!C!L!F!;&V.Ch5U#'
!F#+/!!L4!
#!:&'D.$#"54Q56!.*'
!F'DM! 6$
+!#'HF‚BC!F3+
#'#/K#(6.HF&
18
N"+ q*P9P]';Q5 -!4
!F!(M:*^co_„X&oD\!B35! 6
\!#<
Vrr.:!#D#3
#$DH*2D!BJD!F5
35^5H*coC89*D
5!F\89_<
Một số ngôn ngữ đặc thù, chẳng hạn như SCR, xem xét các biến khởi động sự
kiện khác biệt so với các biến khác trong thuộc tính chuyển tiếp. Khi ở trong trường
hợp này, mệnh đề mà tương đương với các biến khởi động sự kiện nên đưa ra giá trị
khác nhau, nhưng nên duy trì các biến đó. Nếu nó không còn là một biến khởi động
nữa, tương đương với việc không Test case. Thêm vào đó, một biến khởi động sự kiện
thực tế xác định hai giá trị, một giá trị trước và một giá trị sau. Để kiểm thử đầy đủ
các thuộc tính với các biến khởi động sự kiện, cả giá trị trước và sau nên được kiểm
thử. Điều này được thực hiện bằng việc giả định hai phiên bản của biến khởi động sự
kiện, A và A’, ở đó A đưa ra giá trị trước và A’ cho ra giá trị sau của nó.
(3) Mức chỉnh sửa các cặp chuyển tiếp
Các mức độ kiểm thử trước đó là kiểm thử việc chuyển tiếp độc lập, nhưng
không kiểm thử trình tự của các chuyển tiếp trạng thái. Mức độ này đòi hỏi các cặp
chuyển tiếp đó thực hiện.
19
Mức chỉnh sửa cặp chuyển tiếp: Cho mỗi trạng thái S, tạo nên các yêu cầu kiểm
thử chẳng hạn đó cho mỗi chuyển tiếp đến và đi, cả hai sự chuyển tiếp phải được thực
hiện tuần tự.
Xem trạng thái sau:
Để kiểm thử trạng thái S ở mức độ cặp chuyển tiếp, phải kiểm thử sáu lần: (1)
từ 1 đến i, (2) 2 tới i, (3) 1 tới ii, (4) 2 tới ii, (5) 1 tới iii, và (6) 2 tới iii. Việc kiểm thử
này đòi hỏi các đầu vào phải thỏa mãn các thuộc tính: P1:Pi,:P1:Pii, P1:Piii, P2:Pi,
P2:Pii và P2:Piii.
(4) Mức độ tuần tự hoàn chỉnh
Không thể chắc chắn rằng bất kỳ kiểm thử thành công nào cũng có thể dựa trên
các phương pháp thông thường, đôi khi kinh nghiệm và sự hiểu biết của các kỹ sư
kiểm thử phải được sử dụng. Đặc biệt ở mức độ hệ thống, việc kiểm thử hiệu quả có
thể đòi hỏi một kiến thức chi tiết về lĩnh vực đó. Một mức độ trình tự hoàn chỉnh là
một tuần tự của các chuyển tiếp trạng thái mà tạo ra một sự sử dụng thực tiễn hoàn
chỉnh của hệ thống. Trong hầu hết các ứng dụng thực tế, số lượng các tuần tự có thể là
quá lớn để chọn tất cả các tuần tự hoàn chỉnh. Trong nhiều trường hợp, số các tuần tự
hoàn chỉnh là được xác định.
Mức độ tuần tự hoàn chỉnh: Các kỹ sư kiểm thử phải xác định các tuần tự đầy
đủ của các chuyển tiếp trên đồ thị đặc tả bằng việc chọn các tuần tự trạng thái nên
được đưa vào.
Đôi khi việc chọn các tuần tự nào chỉ có thể được quyết định bởi kỹ sư kiểm
thử với việc sử dụng kiến thức và kinh nghiệm của mình. Đây là một mức độ tự động
hóa ít nhất của quá trình kiểm thử.
3.1.3 Kỹ thuật tạo Test case cho đặc tả UML
Phần này trình bày một cách chi tiết về làm thế nào để có thể sử dụng đặc tả
UML để tạo ra Test case, và qui trình làm như thế nào.
Mô hình kiểm thử:
UML có thể được sử dụng để xác định một vùng rộng các khía cạnh của một hệ
thống. Các biểu đồ trạng thái là một nơi rõ ràng nhất để bất đầu với việc tạo ra dữ liệu
kiểm thử. Các biểu đồ UML được dựa trên các máy trạng thái hạn chế sử dụng một ký
hiệu biểu đồ trạng thái được mở rộng, và được sử dụng để đưa hành vi của một đối
20
tượng. Hành vi gắn kết cấu trúc của một đối tượng tới các thuộc tính của nó và các
mối quan hệ để đối tượng có thể đáp ứng được những trách nhiệm của nó. Các
phương pháp của một đối tượng thực hiện hành vi của nó. Bằng việc test mỗi phương
pháp, chúng ta có thể kiểm thử một vài mục của hành vi của một đối tượng, nhưng
không phải là toàn bộ các hành vi. Các máy trạng thái mô tả toàn bộ hành vi của một
đối tượng, do vậy Test case được tạo ra từ các máy trạng thái kiểm thử toàn bộ hành
vi của một đối tượng. Lợi thế khác của biểu đồ UML đó là chúng có cùng ngữ nghĩa
như các đặc tả được dựa trên trạng thái khác. Điều này làm cho nó có thể sinh ra mô
hình thế hệ Test case được miêu tả ở các biểu đồ UML. Để sửa mô hình tới các biểu
đồ UML, chúng ta giải thích cùng ngữ nghĩa và cú pháp của biểu đồ trạng thái trong
các đặc tả UML.
Trạng thái của một đối tượng là sự kết hợp của tất cả các giá trị của thuộc tính
và các đối tượng mà đối tượng có; một trạng thái là tĩnh, tại một thời điểm, không
phải là động. Trạng thái động của đối tượng được mô hình hóa thông qua sự chuyển
tiếp, đó là một sự chuyển động từ một trạng thái này sang một trạng thái khác. Khi
một đối tượng ở trong một trạng thái nhất định, một sự kiện xuất hiện dẫn đến làm nó
chuyển động sang một trạng thái khác (hoặc trở lại trạng thái cũ). Trong khi chuyển
tiếp từ trạng thái này tới trạng thái khác, một hành động xuất hiện. Sự chuyển tiếp
trong UML có cú pháp như sau:
Event (arguments) [condition] ’ target.sendEvent (argments)/operation (arguments)
Mỗi trong số các trường này là một tùy chọn-thậm chí tên có thể được bỏ đi
nếu nó rõ ràng khi sự việc chuyển tiếp xảy ra.
Sự kiện là tên của việc chuyển tiếp. Thông thường đây chỉ là một thứ được xác
định cho chuyển tiếp. Chuyển tiếp có một danh sách đối số tùy chọn để chỉ ra khi nào
dữ liệu được đưa ra trong chuyển tiếp, chẳng hạn một mã bị lỗi hoặc một giá trị được
giám sát. Danh sách đối số này được đưa vào trong ngoặc đơn giống như việc gọi
chức năng chuẩn. Điều kiện bảo đảm được đưa ra trong dấu ngoặc vuông. Một bảo
đảm là một điều kiện mà phải được thỏa mãn trước khi việc chuyển tiếp được thực
hiện. Danh sách sendEvent là một danh sách được ngăn cách bởi dấu phẩy. Mỗi sự
kiện được hướng tới một đối tượng mục tiêu, và có thể có các đối số. Những sự kiện
như vậy sẽ được phổ biến bên ngoài của các đối tượng đi kèm như một kết quả của sự
chuyển tiếp này. Đây là một cách mà các trạng thái đang xảy ra liên lạc với nhau, cho
phép một sự chuyển tiếp trong một máy trạng thái ảnh hưởng tới các máy trạng thái
đang tồn tại khác. Cuối cùng, danh sách toán tử xác nhận danh sách được ngăn cách
bởi dấu hai chấm của các chức năng (mỗi cái đi với một đối số) mà sẽ được gọi là một
kết quả của sự chuyển tiếp được thực hiện.
Trong các trạng thái, cả các hành động vào và ra, cũng như các hành động sắp
diễn ra, có thể được chỉ rõ. Một hành động vào là một chức năng mà được gọi khi
21
trạng thái được đưa vào (thậm chí khi sự chuyển tiếp được tự định hướng). Một hành
động thoát là một chức năng mà được thực hiện khi trạng thái được thoát (thậm chí
việc chuyển tiếp được tự định hướng). Các hành động chứng tỏ việc xử lý đang tiếp
tục được hoàn thành, hoặc cho đến khi được ngăn chặn bởi một sự chuyển tiếp (thậm
chí khi sự chuyển tiếp bản thân nó được tự định hướng).
Các đối tượng kiểm thử cho mô hình chuyển tiếp trạng thái là các đường dẫn
chuyển tiếp, các đường dẫn thông qua biểu đồ đưa ra một chu kỳ sống toàn bộ của đối
tượng từ lúc sinh ra đến lúc bị phá hủy. Đó là, mỗi đối tượng kiểm thử đưa ra một
trình tự có thể của các trạng thái giữa việc sinh ra và mất đi của một đối tượng. Chúng
ta không thể kiểm thử một mô hình chu kỳ sống của đối tượng với mô hình hiện có,
mà chỉ là một phần của nó thôi.
UML phân loại các chuyển trạng thái vào trong năm loại sau: chuyển trạng thái
ở mức cao, chuyển trạng thái phức hợp, chuyển trạng thái bên trong, chuyển trạng thái
hoàn thành, chuyển trạng thái khả năng. Sự chuyển trạng thái ở mức cao có nguồn gốc
từ đường biên của các trạng thái ghép lại. Một trạng thái ghép lại là một trạng thái
gồm có hoặc là các trạng thái phụ xảy ra cùng một thời điểm hoặc các trạng thái phụ
tách rời. Nếu được khởi động, nó thoát tất cả các trạng thái phụ của trạng thái ghép bắt
đầu việc thoát với các trạng thái ở tận trong cùng ở trong cấu hình trạng thái hoạt
động. Sự chuyển trạng thái phức hợp bắt nguồn từ một tập hợp các trạng thái và
hướng đến một tập hợp của các trạng thái. Một sự chuyển trạng thái bên trong thực
hiện mà không thoát hoặc vào lại trạng thái mà nó đã xác định. Một sự chuyển trạng
thái hoàn thành là một sự chuyển tiếp không có khởi động rõ ràng, mặc dầu nó có thể
có một sự bảo đảm được xác định. Khi tất cả chuyển tiếp và các thao tác đưa vào và
các hành động đưa vào trong trạng thái hành động hiện có được hoàn thành. Một sự
chuyển trạng thái khả năng được cho phép bởi một sự kiện, và nó bắt nguồn từ một
trạng thái hoạt động. Một sự chuyển trạng thái khả năng được khởi động khi ở đó tồn
tại ít nhất một đường dẫn hoàn chỉnh từ trạng thái gốc tới trạng thái mục tiêu.
Phần này chỉ quan tâm đến sự chuyển trạng thái khả năng. Mô hình trước đó đã
được dựa chủ yếu trên sự thỏa mãn thuộc tính. Trong UML, các sự chuyển trạng thái
khả năng là tương tự các chuyển tiếp mà được dựa trên khái niệm về sự thỏa mãn
thuộc tính.Vì mục đích sinh ra mô hình, các loại khác của chuyển tiếp là không được
xem xét.
Bốn loại sự kiện có thể được xác định trong UML: sự kiện gọi (call event), sự
kiện báo hiệu (signal event), sự kiện thời gian (time event), và sự kiện thay đổi
(change event). Một sự kiện gọi đưa ra sự tiếp nhận của một yêu cầu để thực hiện một
hoạt động nhất định. Kết quả mong đợi là một sự thực hiện của một trình tự các hành
động mà tiêu biểu là hành vi tại một trạng thái cụ thể. Sự tạo và phá hủy đối tượng là
hai trường hợp đặc biệt của một sự kiện gọi. Hình 6 minh họa một sự kiện gọi.
22
Hình 6: Sự kiện gọi (call events)
Hình 7: Sự kiện báo hiệu (signal events)
Một sự kiện báo hiệu đưa ra sự chấp nhận của một dấu hiệu đồng bộ cụ thể.
Một ví dụ sự kiện báo hiệu không nên được nhầm lẫn với hành động (ví dụ hành động
Send) mà đã tạo ra nó. Các ngoại lệ là các ví dụ của các sự kiện báo hiệu. Các sự kiện
báo hiệu được mô hinh hóa như các loại được dập khuôn, được đưa ra trong hình 7.
Sự phụ thuộc của sự kiện send chỉ ra rằng một thao tác đưa một dấu hiệu cụ thể.
Một sự kiện thời gian đưa ra sự chuyển qua của một khoảng thời gian được chỉ
định sau một sự kiện được chỉ định (thường là đầu vào của một trạng thái hiện tại)
hoặc sự kiện của một thời gian nhất định. Trong UML, sự kiện thời gian được mô
hình hóa bằng sử dụng các từ khóa after được theo sau bởi một vài biểu thức mà đánh
giá tới một khoảng thời gian. Hình 8 minh họa một sự kiện thời gian.
23
Hình 8: Sự kiện thời gian (time Events)
Một sự kiện thay đổi xuất hiện khi một biểu thức boolean rõ ràng trở thành
đúng như một kết quả của một sự thay đổi trong giá trị của một hoặc nhiều các thuộc
tính hoặc các kết hợp. Một sự kiện thay đổi được đưa rõ ràng và không là kết quả của
một hành động thay đổi sự kiện. Sự kiện thay đổi thì khác với một sự bảo vệ. Một sự
bảo vệ không chỉ được đánh giá tại thời điểm một sự kiện được gửi đi, ngược lại, dựa
trên các khái niệm biểu thức Boolean kết hợp với một sự kiện thay đổi được đánh giá
liên tục cho tới khi nó trở thành đúng. Sự kiện mà được tạo ra vẫn còn cho tới khi nó
được sử dụng thậm chí nếu biểu thức Boolean biến thành sai. Trong UML, sự kiện
thay đổi được mô hình hóa bởi việc sử dụng từ khóa when được theo sau bởi một vài
biểu thức Boolean. Hình 9 minh họa một sự kiện thay đổi.
Hình 9: Sự kiện thay đổi (Change Events)
Trong số bốn loại sự kiện, sự kiện thay đổi có thể diễn đạt như một thuộc tính.
Sau đây, chúng ta áp dụng mô hình tạo Test case đặc tả dựa trên trạng thái tới sự
chuyển trạng thái khả năng với sự kiện thay đổi.
(1) Mức độ chỉnh sửa chuyển tiếp
Chỉnh sửa chuyển tiếp: Mỗi chuyển tiếp được phép trong biểu đồ trạng thái
được thực hiện ít nhất một lần.
(2) Mức chỉnh sửa thuộc tính đầy đủ
Chỉnh sửa thuộc tính đầy đủ: Mỗi mệnh đề lần lượt lấy giá trị đúng và sai trong
khi tất cả các mệnh đề khác trong thuộc tính có các giá trị chẳng hạn giá trị của thuộc
tính sẽ luôn như là giá trị mệnh đề được kiểm thử.
(3) Mức chỉnh sửa cặp chuyển tiếp
Mức độ chỉnh sửa cặp chuyển tiếp: Với mỗi trạng thái S, tạo thành các yêu cầu
kiểm thử chẳng hạn cho mỗi chuyển tiếp tiếp theo và mỗi chuyển tiếp trong tương lai,
cả hai chuyển tiếp phải được thực hiện tuần tự.
Chú ý: Tiêu chuẩn chỉnh sửa cặp chuyển tiếp có thể không khả thi trong biểu
đồ trạng thái mà có các loại được pha trộn của các chuyển tiếp. Kỹ thuật tạo ra dữ liệu
kiểm thử chỉ cho các chuyển tiếp khả năng.
24
3.1.4. Các thuận toán sinh Test case dựa trên đặc tả.
Trong phần này, đầu tiên chúng ta mô tả cấu trúc của các giả định và các file đặc
tả SCR và UML mà ta sẽ thực hiện trong thiết kế. Sau đó chúng ta đưa ra thiết kế cấu
trúc, cuối cùng là các thuật toán mà phân tích các file đặc tả và sinh ra các Test case
cho việc chỉnh sửa đầy đủ thuộc tính và tiêu chuẩn chỉnh sửa cặp chuyển tiếp được
đưa ra.
3.1.4.1. Các files đặc tả UML và SCR
Các file đặc tả được lưu giữ như các file văn bản ASCII. Đầu tiên, chúng ta
phân tách cú pháp file đặc tả để có được ý nghĩa của nó. Việc phân tách các file text
đặc tả phụ thuộc rất nhiều vào cấu trúc của chúng. Trong phần này, chúng ta sẽ đưa ra
một cái nhìn tổng quan tương đối chi tiết về việc làm thế nào các file text đặc tả được
tạo ra.
(1) Cấu trúc của các file đặc tả SCR
File đặc tả có các mục riêng biệt sau đây:
• Từ điển loại ( Type Dictionary)
• Từ điển lớp trạng thái (Mode Class Dictionary)
• Từ điển hằng số (Constant Dictionary)
• Từ điển biến (Variable Dictionary)
• Từ điển xác nhận đặc tả (Specification Assertion Dictionary)
• Từ điển xác nhận môi trường (Environmental Assertion Dictionary)
• Từ điển biến giám sát liệt kê (Enumerated Monitored Variable Dictionary)
• Từ điển biến điều khiển (Controlled Class Table)
• Các bảng loại trạng thái (Mode Class Table)
• Các bảng biến điều kiện (Term Variable Table)
Các đặc tả cho tất cả các mục này được lưu giữ như các ASCII text file trong
trật tự bên trên. Không có sự hạn chế trong tên file, hoặc phần đuôi file mở rộng. Cấu
trúc của file text được chỉ ra ở bên dưới.
- Các giả định cho các đặc tả SCR
Các giả định sau đây được thực hiện trong khi phân tách đặc tả SCR trong file
text.
• @T, @F biểu thị cho các sự kiện khởi động
• AND biểu thị cho sự logic và
• Chỉ có một loại lớp
• Các biến Boolean
• Thay đổi biến đơn trong sự kiện
• Không có biến nào hoặc các biến đơn hoặc đa biến trong điều kiện
• Những sự chuyển tiếp trạng thái được xác định.
Type Dictionary
TYPE Type Name
25