Вы находитесь на странице: 1из 27

1.

Tại sao phải kiểm thử phần mềm


- Đảm bảo chất lượng phần mềm sau khi đưa ra sử dụng

- Hoàn thiện & nâng cấp khả năng phần mềm

- Tránh rủi ro cho khách hàng và giảm bảo trì, bảo hành cho người viết phần mềm.

- Hạn chế chi phí cho các thất bại do lỗi gây ra sau này.

2. Có mấy loại hoạt động kiểm thử phần mềm, cách thực hiện từng loại.
Kiểm thử phần mềm có thể chia thành 4 hoạt động kiểm thử:

1a Design (Thiết kế) Thiết kế các giá trị test thỏa mãn mục tiêu kỹ thuật
Criteria (tiêu chuẩn) Đòi hỏi kiến thức của toán rời rạc, lập trình và kiểm thử
1b Design Thiết kế các giá trị test từ miền kiến thức và trực giác
Human (con người) Đòi hỏi kiến thức về miền, UI, kiểm thử
2 Automation(tự động) Nhúng (nhập) các giá trị test vào văn bản thực thi
Đòi hỏi kiến thức của các văn bản
3 Execution(thực thi) Thực thi các test trên phần mềm và ghi lại kết quả
Đòi hỏi rất ít kiến thức
4 Evaluation(đánh giá) Đánh giá các kết quả test, báo cáo cho nhà phát triển
Đòi hỏi miền kiến thức
3. Trình bày các tiêu chuẩn phủ có cấu trúc? Cho VD?
3.1 Tiêu chuẩn Node Coverage (NC) - Phủ nút: TR chứa mỗi nút có thể đi qua trong đồ thị G.
VD:

1 20
Node Coverage : TR = { 0, 1, 2 }
Test Path = [ 0, 1, 2 ]

3.2 Tiêu chuẩn Edge Coverage (EC) – Phủ cạnh: TR chứa mỗi đường có thể đi qua với độ dài lên đến
1 trong đồ thị G
VD:

1 20
Edge Coverage : TR = { (0,1), (0, 2), (1, 2) }
Test Paths = [ 0, 1, 2 ]
[ 0, 2 ]
3.3 Tiêu chuẩn Edge – Pair Coverage (EPC) – phủ cặp cạnh: TR chứa mỗi đường có thể đi qua với
độ dài lên đến 2 trong đồ thị G

Edge-Pair Coverage
TR = { [0,1,2], [0,2,3], [0,2,4], [1,2,3], [1,2,4], [2,3,6],
[2,4,5], [2,4,6], [4,5,4], [5,4,5], [5,4,6] }
Test Paths: [ 0, 1, 2, 3, 6 ] [ 0, 1, 2, 4, 6 ] [ 0, 2, 3, 6 ]
[ 0, 2, 4, 5, 4, 5, 4, 6 ]

3.4 Tiêu chuẩn Prime – Path Coverage (PPC) – Phủ tối ưu: TR chứa mỗi đường đi tối ưu trong đồ
thị G

3.5 Simple Round Trip Coverage (SRTC) – Phủ chu trình đơn: TR chứa ít nhất 1 chu trình đường đi
cho mỗi nút có thể đi tới trong đồ thị G mà bắt đầu và kết thúc 1 chu trình đường đi (Chu trình
đường đi là 1 đường đi tối ưu, có độ dài khác 0 và bắt đầu và kết thúc tại cùng 1 nút)
3.6 Complete Round Trip Coverage (CRTC) – Phủ hoàn toàn chu trình: TR chứa tất cả các chu trình
đường đi cho mỗi nút có thể đi tới trong đồ thị G.
3.7 Complete Path Coverage (CPC) – Phủ hoàn toàn đường đi: TR chứa tất cả các đường đi trong đồ
thị G.
3.8 Specified Path Coverage (SPC) – Phủ xác định đường đi: TR chứa 1 tập hợp S các test path,
trong đó S được cung cấp như 1 tham số (không khả thi khi có loop)
4. Trình bày các tiêu chuẩn luồng dữ liệu? Cho VD
4.1 All – Defs Coverage (ADC) – Phủ tất cả các defs : Đối với mỗi def-path lập S = du (n,v). TR
chứa ít nhất 1 đường đi trong S.

Z
X 1 =4
0
= 3 6
2 X
5
4 Z
*2
2 =
X
-
8
All-defs for X
[ 0, 1, 3, 4 ]

4.2 All – Users Coverage (AUC) – Phủ tất cả các uses: Đối với mỗi def-pair (cặp def) lập S = du
(n,v). TR chứa ít nhất 1 đường đi trong S.

Z
X 1 =4
0
= 3 6
2 X
5
4 Z
*2
2 =
X
-
8
All-uses for X
[ 0, 1, 3, 4 ]
[ 0, 1, 3, 5 ]

4.3 All – du – path Coverage (ADUPC) – Phủ tất cả các du – path: Đối với mỗi def-pair lập S = du
(ni,nj,v). TR chứa mọi đường đi d trong S.
Z
X 1 =4
0
= 3 6
2 X
5
4 Z
*2
2 =
X
-
8
All-du-paths for X
[ 0, 1, 3, 4 ]
[ 0, 2, 3, 4 ]
[ 0, 1, 3, 5 ]
[ 0, 2, 3, 5 ]

5. Trình bày các tiêu chuẩn phủ biểu thức logic? Cho VD
5.1 Predicate Coverage (PC) – phủ vị từ: Đối với mỗi p ∈ P, TR chứa 2 yêu cầu: giá trị p đúng và giá
trị p sai.
VD: ((a < b) Ú D) Ù (m >= n*o)
predicate coverage
Predicate = true
a = 5, b = 10, D = true, m = 1, n = 1, o = 1
= (5 < 10) Ú true Ù (1 >= 1*1)
= true Ú true Ù TRUE
= true
Predicate = false
a = 10, b = 5, D = false, m = 1, n = 1, o = 1
= (10 < 5) Ú false Ù (1 >= 1*1)
= false Ú false Ù TRUE
= false

5.2 Clause Coverage (CC) – phủ mệnh đề: Đối với mỗi c ∈ C, TR chứa 2 yêu cầu: giá trị c đúng và
giá trị c sai
VD: ((a < b) Ú D) Ù (m >= n*o)
Clause coverage

(a < b) = true (a < b) = false D = true D = false m >= n*o = true m >= n*o = false

a = 5, b = 10 a = 10, b = 5 D = true D = false m = 1, n = 1, o = 1 m = 1, n = 2, o = 2


Two test:
1) a = 5, b = 10, D = true, m = 1, n = 1, o = 1
2) a = 10, b = 5, D = false, m = 1, n = 2, o = 2

5.3 Combinatorial Coverage (CoC) – phủ kết hợp: Đối với mỗi p ∈ P, TR có những yêu cầu kiểm
thử cho những mệnh đề trong Cp để gán giá trị cho mỗi kết hợp có thể có của các giá trị đúng.

a<b D m >= n*o ((a < b) Ú D) Ù (m >= n*o)

1 T T T T

2 T T F F

3 T F T T

4 T F F F

5 F T T T

6 F T F F

7 F F T F

8 F F F F

6. Trình bày phủ logic dựa trên đặc tả? Cho VD?
6.1 Đặc tả phần mềm:
 Những đặc tả có thể biểu diễn dưới dạng formal hoặc informal:
 Đặc tả formal: thường được biểu diễn dưới dạng toán học
 Đặc tả informal: thường được biểu diễn bằng ngôn ngữ tự nhiên
 Rất nhiều ngôn ngữ formal và kiểu informal thì có sẵn.
 Hầu hết các ngôn ngữ đặc tả bao gồm những biểu thức logic rõ ràng, vì vậy có thể áp dụng các
tiêu chuẩn phủ logic 1 cách dễ dàng.
 Những biểu thức logic ẩn trong những ngôn ngữ đặc tả tự nhiên nên được viết lại như 1 biểu
thức logic rõ ràng, đây là 1 phần của thiết kế kiểm thử (bạn sẽ luôn tìm thấy lỗi)
 Một trong những cách phổ biến nhất là điều kiện tiên quyết.( preconditions)
6.2 Điều kiện tiên quyết:
 Những lập trình viên thường gom những điều kiện tiên quyết như là 1 phần trong các phương
thức của họ.
 Những điều kiện tiên quyết thường được ghi chú ở đầu các phương thức.
 Những điều kiện tiên quyết có thể ở trong javadoc, “những yêu cầu”, “pre”…
Example – Saving addresses VD: Lưu những địa chỉ
// tên (name) không được trống
// nước (state) phải hợp lệ
// mã bưu điện (zip) phải 5 ký tự
// đường (street) không được trống
// tỉnh thành (city) không được trống
Viết lại thành biểu thức logic
name != “” Ù state in stateList Ù zip >= 00000 Ù zip <= 99999 Ù street != “” Ù city != “”
6.3 Shortcut cho những vị từ trong form kết nối bình thường
 Những mệnh đề được nối với nhau bằng toán tử “and”
AÙBÙCÙ…
 Mỗi mệnh đề chính được thực hiện bằng cách làm cho tất cả các mệnh đề khác đúng.
 Những kiểm tra được tạo: “tất cả đều đúng” và 1 “đường chéo” mang giá trị sai.

6.4 Shortcut cho những vị từ trong form riêng biệt


 Những mệnh đề được nối với nhau bằng toán tử “or”
AÚBÚCÚ…
 Mỗi mệnh đề chính được thực hiện bằng cách làm cho tất cả các mệnh đề khác sai.
 Những kiểm tra được tạo: “tất cả đều sai” và 1 “đường chéo” mang giá trị đúng.

7. Trình bày tiêu chuẩn các chiến lược kết hợp trong không gian dữ liệu đầu vào? Cho VD?
7.1 All Combinations Coverage (ACoC): Tất cả các kết hợp của các blocks từ tất cả các
characteristics phải được sử dụng.
VD: Nếu chúng ta có 3 phân vùng với những blocks [A,B],[1,2,3], và[x,y], thì ACoC sẽ có 12 test
sau:
(A, 1, x) (B, 1, x)
(A, 1, y) (B, 1, y)
(A, 2, x) (B, 2, x)
(A, 2, y) (B, 2, y)
(A, 3, x) (B, 3, x)
(A, 3, y) (B, 3, y)
7.2 Each Choice Coverage (ECC): 1 giá trị từ mỗi block cho mỗi characteristic phải được sử dụng ít
nhất trong 1 test case.
VD cho TriTyp: 2, 2, 2
1, 1, 1
0, 0, 0
-1, -1, -1

7.3 Pair – Wise Coverage (PWC): Một giá trị từ mỗi blocks cho mỗi characteristic phải được kết hợp
với một giá trị từ mỗi blocks cho mỗi characteristic khác.
VD: Cho TriTyp: 2, 2, 2 2, 1, 1 2, 0, 0 2, -1, -1
1, 2, 1 1, 1, 0 1, 0, -1 1, -1, 2
0, 2, 0 0, 1, -1 0, 0, 2 0, -1, 1
-1, 2, -1 -1, 1, 2 -1, 0, 1 -1, -1, 0

7.4 T – Wise Coverage (TWC): ): Một giá trị từ mỗi block đối với từng group của characteristic t
phải được kết hợp.
VD: Cho TriTyp: với t = 2
2, 2, 2 2, 1, 1 2, 0, 0 2, -1, -1
1, 2, 1 1, 1, 0 1, 0, -1 1, -1, 2
0, 2, 0 0, 1, -1 0, 0, 2 0, -1, 1
-1, 2, -1 -1, 1, 2 -1, 0, 1 -1, -1, 0

7.5 Base Choice Coverage (BCC): Mỗi base choice được chọn cho mỗi characteristic, 1 base test
được hình thành bằng cách sử dụng base choice cho mỗi characteristic. Những subsequent test
(những test sau đó) được chọn bằng cách giữ lại tất cả nhưng 1 base choice là không đổi cho mỗi
base test và sử dụng mỗi non – base choice cho từng characteristic khác nhau.
VD: Cho TriTyp:
Base 2, 2, 2 2, 2, 1 2, 1, 2 1, 2, 2
2, 2, 0 2, 0, 2 0, 2, 2
2, 2, -1 2, -1, 2 -1, 2, 2

7.6 Multiple Base Choice Coverage (MBCC): Có ít nhất một, và có thể nhiều hơn, những base choice
blocks được lựa chọn cho mỗi characteristic, và các base test được hình thành bằng cách sử dụng
mỗi base choice cho mỗi characteristic ít nhất một lần. Những subsequent test (những test sau đó)
được chọn bằng cách giữ tất cả, nhưng 1 base test là không đổi cho mỗi base test, sử dụng mỗi
non – base choice cho từng characteristic khác nhau.
VD: Cho TriTyp:
Base 2, 2, 2 2, 2, 0 2, 0, 2 0, 2, 2
2, 2, -1 2, -1, 2 -1, 2, 2
1, 1, 1 1, 1, 0 1, 0, 1 0, 1, 1
1, 1, -1 1, -1, 1 -1, 1, 1

8. Thế nào là ràng buộc giữa các phân vùng dữ liệu đầu vào?
 Ràng buộc là mối quan hệ giữa các khối(block) từ những đặc trưng (characteristic) khác nhau.
 Một số blocks kết hợp lại thì không khả thi.
 Xuất hiện 2 loại ràng buộc:
 1 loại là 1 block từ 1 characteristic không thể kết nối với 1 block của 1 characteristic khác.
 Loại ngược lại, 1 block từ 1 characteristic phải được kết nối với 1 block đặc biệt của 1
characteristic khác.
VD: Trong TriTyp ở chương 3, “nhỏ hơn không” và “cạnh không đều” thì không thể cùng tồn tại.
 Xử lý ràng buộc dựa vào những tiêu chuẩn:
ACoC, PWC, TWC: loại bỏ những cặp không khả thi.
BCC, MBCC: thay đổi giá trị 1 non-base choice để tìm 1 kết hợp khả thi.
 Xử lý ràng buộc dựa vào những tiêu chuẩn:
 ACoC, PWC, TWC: loại bỏ những cặp không khả thi.
 BCC, MBCC: thay đổi giá trị 1 non-base choice để tìm 1 kết hợp khả thi.

9. Trình bày các tiêu chuẩn phủ dựa trên cú pháp? Cho VD?
9.1 BNF Coverage Criteria
VD:

Start
symbol
9.1.1 Terminal Symbol Coverage (TSC) – phủ những ký hiệu kết thúc: TR chứa mỗi ký hiệu
kết thúc t trong grammar G
9.1.2 Production Coverage (PDC) – phủ kết quả: TR chứa mỗi production p trong grammar G
9.1.3 Derivation Coverage (DC) – phủ đạo hàm: TR chứa mọi chuỗi có thể có (possible string)
mà có thể suy ra từ grammar G
9.2 Mutation Testing

Định nghĩa 5.45Ground string (Chuỗi nền): một chuỗi trong cú pháp.

Định nghĩa 5.46Mutation operator (Toán tử thay đổi): một nguyên tắc xác định các biến đổi cú
pháp của những chuỗi string được tổng hợp từ 1 grammar
Định nghĩa 5.47Mutant (Thay đổi): kết quả của một ứng dụng của 1 mutation operator.
Killing mutant: Given a mutant m Î M for a derivation D and a test t, t is said to kill m if and only
if the output of t on D is different from the output of t on m: Cho 1 mutant m Î M của 1
derivation D và 1 test t, t được gọi là kill m nếu và chỉ nếu output của t trên D khác với output
của t trên m.
9.2.1 Mutation Coverage (MC): Đối với mỗi mutant m ∈ M, TR chứa chính xác 1 yêu cầu để
kill m
9.2.2 Mutation Operator Coverage (MOC): Đối với mỗi mutation operator (Mutation
Operator : A rule that specifies syntactic variations of strings generated from a grammar),
TR chứa chính xác 1 yêu cầu, để tại ra 1 mutant string m được lấy từ việc sử dụng
mutation operator.
9.2.3 Mutation Production Coverage (MPC): Đối với mỗi mutation operator, và mỗi
production có toán tử được cung cấp, TR chứa yêu cầu để tạo ra 1 mutated string (chuỗi
thay đổi) từ production đó.

Stream ::= action*


action ::= actG | actB Gra
actG ::= “G” s n mma
actB ::= “B” t n r
s ::= digit1-3
t ::= digit1-3
n ::= digit2 “.” digit2 “.”
digit2
digit ::= “0” | “1” | “2” | “3” |
VD:
“4” | “5” | “6” | “7” | “8” | “9”
10. Trình bày ngữ pháp dựa trên chương trình? Cho VD?
 Syntax-based criteria originated with programs and have been used most with programs: tiêu chuẩn
dựa trên cú pháp bắt nguồn với 1 chương trình (programs) và được sử dụng với rất nhiều chương
trình.
 BNF criteria are most commonly used to test compilers: Tiêu chuẩn BNF thường được sử dụng cho
việc biên dịch test
 Mutation testing criteria are most commonly used for unit testing and integration testing of classes:
Tiêu chuẩn mutation testing thường được dùng cho kiểm thử đơn vị và kiểm thử tích hợp của class.

5.2


10.1 BNF testing cho trình biên dịch
 Testing compilers is very complicated :những trình biên dịch test thì rất phức tạp. Millions of
correct programs ! Hàng triệu chương trình đúng.
Compilers must recognize and reject incorrect programs: trình biên dịch phải nhận ra và từ chỗi
những chương trình sai.
 BNF criteria can be used to generate programs to test all language features that compilers must
process: tiêu chuẩn BNF có thể được sử dụng để tổng hợp những chương trình cần test thành những
ngôn ngữ chức năng mà trình biên dịch phải tiến hành.
 This is a very specialized application and not discussed in detail: Đây là 1 ứng dụng đặc biệt và không
được đi sâu vào chi tiết.
10.2 Ngữ pháp dựa trên chương trình:
 The original and most widely known application of syntax-based testing is to modify programs:
Ứng dụng đầu tiên và phổ biến nhất của kiểm thử dựa trên cú pháp là để thay đổi những chương
trình
 Operators modify a ground string (program under test) to create mutant programs những toán tử
bổ nghĩa cho 1 ground string (chương trình được kiểm thử) để tạo ra những mutant programs.
 Mutant programs must compile correctly (valid strings): những mutant program phải biên dịch
đúng (những chuỗi hợp lệ).
 Mutants are not tests, but used to find tests những mutants không phải là những test mà được sử
dụng để tìm những test.
 Once mutants are defined, tests must be found to cause mutants to fail when executed: khi những
mutants được xác định, những tests phải được tìm thấy vì những mutants sai khi thực thi.
 This is called “killing mutants”: điều này gọi là killing mutants.
 Killing mutant: Given a mutant m Î M for a ground string program P and a test t, t is said to kill
m if and only if the output of t on P is different from the output of t on m. Cho 1 mutant m Î M
của 1 ground string chương trình P và 1 test t, t được gọi là kill m nếu và chỉ nếu output của t trên
P khác với output của t trên m.
VD:

Immediate
runtime failure
if B==0 else
does nothing
10.3 Program-Based Mutation
 Strongly killing mutants: Cho 1 mutant m ∈ M của 1 program P và 1 test t, t được gọi là strongly
kill m nếu và chỉ nếu kết quả output của t trên P khác với kết quả output của t trên m.
 Weakly killing mutants: Cho 1 mutant m ∈ M mà thay đổi 1 vùng l trong 1 program P và 1 test t,
t được gọi là weakly kill m nếu và chỉ nếu trạng thái của việc thực thi của P trên t khác với nếu
trạng thái của việc thực thi của m ngay sau l.
 Strong Mutation Coverage (SMC): Đối với mỗi m ∈ M, TR chứa chính xác 1 yêu cầu, để
strongly kill m.
 Weak Mutation Coverage (WMC): Đối với mỗi m ∈ M, TR chứa chính xác 1 yêu cầu, để weakly
kill m.

VD:
Mutant 1 in the Min( )
example is:

VD2:

The infection condition is


“(B < A) != (B < minVal)”

However, the previous


statement was “minVal =
A”
Substituing, we get: “(B < A) !=
VD3:

(B < A)”

Thus no input can kill this


mutant
Propagation :
((float) ((0-X)/2) ==
((float) 0-X) / 2.0)
!= ((float) (0/2) ==
((float) 0) / 2.0)
That is, X is not even

Thus (X = -6) does n
ot
kill the mutant unde
r
strong mutation

11. Thế nào là kiểm thử hướng đối tượng và tích hợp? Cho VD?
 Integration Testing: Testing connections among separate program units
 Kiểm thử tích hợp: Là việc kết nối kiểm thử giữa những đơn vị chương trình riêng biệt.
 In Java, testing the way classes, packages and components are connected, “Component” is used as a
generic term: Trong Java, kiểm thử cách mà những lớp, những gói và những thành phần được kết nối
 This tests features that are unique to object-oriented programming languages : Tính năng kiểm thử
này chỉ dùng cho ngôn ngữ lập trình hướng đối tượng.như: inheritance, polymorphism and dynamic
binding,
 Integration testing is often based on couplings – the explicit and implicit relationships among
software components: Kiểm thử tích hợp thường dựa trên những cặp – những mối quan hệ rõ ràng và
không rõ ràng giữa những thành phần của phần mềm.
11.1 BNF Integration Testing ( Grammar Integration Testing): Không sử dụng Grammar testing ở cấp
độ integration.
11.2 Integration Mutations: (tích hợp sự thay đổi):
 Faults related to component integration often depend on a mismatch of assumptions: Những
lỗi liên quan đến tích hợp thành phần thường phụ thuộc vào việc không khớp nhau giữa các
giả thiết.
 VD: Callee thought a list was sorted, caller did not: phương thức được gọi nghĩ rằng list đã
được sắp xếp còn phương thức gọi thì không.Callee thought all fields were initialized, caller
only initialized some of the fields: Phương thức được gọi nghĩ rằng các fields đều được định
nghĩa, phương thức gọi chỉ định nghĩa 1 vài fields.Caller sent values in kilometers, callee
thought they were miles: Caller gửi giá trị kilometers, callee nghĩ rằng là miles.
 Integration mutation focuses on mutating the connections between components: Integration
mutation tập trung vào thay đổi sự kết nối giữa các thành phần.
Sometimes called “interface mutation”: Đôi khi được gọi là thay đổi giao diện
Both caller and callee methods are considered: Cả hai phương thức gọi và được gọi đều giống
nhau
 4 loại của mutation Operators (4 loại của toán tử thay đổi)
 Change a calling method by modifying values that are sent to a called method: Thay đổi phương
thức đang gọi bởi thay đổi những giá trị được gửi đến phương phức đã gọi.
 Change a calling method by modifying the call: Thay đổi phương thức đang gọi bằng cách thay đổi
việc gọi đến.
 Change a called method by modifying values that enter and leave a method: Thay đổi phương
thức được gọi bằng cách thay đổi những giá trị đầu ra và đầu vào của 1 phương thức.
 Change a called method by modifying return statements from the method : Thay đổi phương thức
được gọi bằng cách thay đổi trạng thái trả về của phương thức.
 Five Integration Mutation Operators (5 toán tử thay đổi tích hợp )
1. IPVR –– Integration Parameter Variable Replacement : Tích hợp các giá trị thay thế tham số
Each parameter in a method call is replaced by each other variable in the scope of the method call
that is of compatible type.Mỗi tham số trong 1 phương thức gọi được thay thế bởi mỗi giá trị khác
trong phạm vi của phương thức gọi hay những loại tương thích
 This operator replaces primitive type variables as well as objects. Toán tử này thay thế loại
giá trị gốc giống như những đối tượng.
2. IUOI –– Integration Unary Operator Insertion : Tích hợp sự chèn toán tử nguyên phân.
Each expression in a method call is modified by inserting all possible unary operators in front and
behind it. Mỗi biểu thức trong 1 phương thức gọi được thay đổi bằng cách chèn tất cả các nguyên
phân có thể.
 The unary operators vary by language and type: những toán tử nguyên phân khác nhau bởi
ngôn ngữ và loại
3. IPEX –– Integration Parameter Exchange: Tích hợp trao đổi tham số
Each parameter in a method call is exchanged with each parameter of compatible types in that
method call. Mỗi tham số trong 1 phương thức gọi được trao đổi với mỗi loại phương thức thích
hợp trong phương thức gọi đó
 max (a, b) is mutated to max (b, a)
4. IMCD –– Integration Method Call Deletion: Tích hợp xóa phương thức gọi
Each method call is deleted. If the method returns a value and it is used in an expression, the
method call is replaced with an appropriate constant value. Mỗi Phương thức gọi sẽ được xóa.
Nếu phương thức trả về 1 giá trị và nó được sử dụng trong 1 biểu thức, phương thức gọi sẽ được
thay thế với 1 giá trị hằng số gần giống.
 Method calls that return objects are replaced with calls to “new ()” : Phương thức gọi trả về
những đối tượng được thay thế với việc gọi new().
5. IREM –– Integration Return Expression Modification: Tích hợp thay đổi biểu thức trả về:
Each expression in each return statement in a method is modified by applying the UOI and AOR
operators. Mỗi biểu thức trong mỗi trạng thái trả về của 1 phương thức được thay đổi bằng cách
áp dụng toán tử AOR và UOI.
VD:

2. IUOI – Integration Unary Operator


Insertion

callMethod (a);
 callMethod (a++);
int myMethod ()
{
return a;
return ++a;
}
 Object-Oriented Mutation

s
integration mutation operator
•These five operators can be applied to non-OO languages: 5 toán tử này có thể áp dụng cho ngôn
ngữ ko hướng đối tượng (hướng cấu trúc)
– C, Pascal, Ada, Fortran, …
• They do not support object oriented features: Chúng không hỗ trợ đặc tính hướng đối tượng
– Inheritance, polymorphism, dynamic binding
• Two other language features that are often lumped with OO features are information hiding
(encapsulation) and overloading: 2 đặc tính ngôn ngữ khác thường gom với đặc tính hướng đối
tượng là tính đóng gói và nạp chồng.
• Even experienced programmers often get encapsulation and access control wrong: Kinh nghiệm
của những nhà lập trình thường kết hợp sai tính đóng gói và điều kiển nhập liệu.
 OO Language Feature Terms: Những thuật ngữ đặc trưng ngôn ngữ OO
 Polymorphic attribute: (thuộc tính)
o An object reference that can take on various types: 1 đối tượng tham chiếu chó thể có nhiều loại
khác nhau
o Type the object reference takes on during execution can change: loại đối tượng tham chiếu trong
suốt quá trình thực thi có thể thay đổi
 Polymorphic method
o Can accept parameters of different types because it has a parameter that is declared of type Object
. Có thể nhận những tham số khác nhau bởi vì có 1 tham số khai báo loại đối tượng
 Overloading
o Using the same name for different constructors or methods in the same class: sử dụng tên giống
nhau cho những khởi dựng khác nhau hoặc những phương thức trong cùng 1 lớp
 Overriding
o A child class declares an object or method with a name that is already declared in an ancestor
class: Lớp con khai báo 1 đối tượng hay 1 phương thức với 1 tên đã được khai báo ở lớp cha.
o Easily confused with overloading because the two mechanisms have similar names and
semantics. Dễ dàng từ chối với overloading bởi vì 2 kỹ thuật giống tên và ngữ nghĩa.
o Overloading is in the same class, overriding is between a class and a descendant: Overloading ở
trong cùng 1 lớp, overriding ở giữa 1 lớp và 1 lớp con
- Class Mutation Operators for Java

TKD, SMC, VID, DCD

1. AMC –– Access Modifier Change:Thay đổi access modifier


point

privat
e int
x;
1
public
int x;
2
prote
cted
int x;
3
int x;
VD:
2. HVD –– Hiding Variable Deletion: Xóa những biến ẩn
3. HVI –– Hiding Variable Insertion: Chèn vào những biến ẩn
4. OMD –– Overriding Method Deletion: Xóa phương thức overriding
5. OMM –– Overridden Method Moving: Di chuyển phương thức Override
6. OMR –– Overridden Method Rename: Đổi tên 1 phương thức override
7. SKD –– Super Keyword Deletion: Xóa những từ khóa super
8. PCD ––Parent Constructor Deletion: Xóa khởi dựng của lớp cha
9. ATC –– Actual Type Change: Thay đổi kiểu hiện thời
10. DTC ––Declared Type Change: Thay đổi loại khai báo
11. PTC –– Parameter Type Change: Thay đổi loại tham số:
12. RTC –– Reference Type Change: Thay đổi loại tham chiếu
13. OMC –– Overloading Method Change: Thay đổi phương thức overload
14. OMD –– Overloading Method Deletion: Xóa phương thức overload
15. AOC –– Argument Order Change: Thay đổi thứ tự tham số.
16. ANC –– Argument Number Change: Thay đổi số lượng tham số
17. TKD –– this Keyword Deletion: xóa từ khóa this
18. SMC –– Static Modifier Change: Thay đổi từ khóa static
19. VID ––Variable Initialization Deletion: xóa biến khởi tạo
20. DCD ––Default Constructor Delete: xóa khởi dựng mặc định

VD:

2. HVD – Hiding Variable Deletion


point
int x;
colorpoint
int
inty;
x;
1 // int x;
int y;
2 // int y;
point
int getX()
colorpoint
int getX ()
{
return
super.x;
return x;
}
8. PCD –
Parent
point
Construct
pointor (int
colorpoint
x,Deletion
int y)
colorpoint

(int x, int
y, int
color)
{
super
(x, y);
// super
(x, y);

}

10. DTC – Declared Type


Change
point

colorpoint
point p;
 colorpoint p;
p = new
colorpoint ();
12. RTC – Reference
Type Change
point

colorp point3
oint D
point p;
colorpoint cp = new
colorpoint (0, 0);
point3D p3d = new
point3D (0, 0, 0);
p = cp;
 p = p3d;
14. OMD

Overload
point
ing
Method
point3D
Deletion
void set
(int x, int y)
{ …}
 // void set
(int x, int y)
{ …}

void set (int


x, int y, int
z) { … }
15. AOC – Argument Order
Change
point
point3D
void set (int x, int y,
char c);point3D p;
void setp.set (1,a,
(char 2, int x,
int y);‘t’);
 p.set (‘t’, 1,
2);
18. JSD – Static
Modifier Change
point

public static
int x = 0;
1 public int x =
0;
public int Y =
0;
2 public static
int y = 0;


20. DCD –
Default
point
Constructor
Delete

point()
{…}
 //
point()
{…}

12. Trình bày ngữ pháp dựa trên đặc tả? Cho VD?
- Những ngôn ngữ mô tả phần mềm trong những thuật ngữ trừu tượng như: Những ngôn ngữ đặc tả
thông thường,Z, SMV, OCL, …
- Informal specification languages: Ngôn ngữ đặc tả không thông dụng.
- Design notations . Những chú thích thiết kế
- Statecharts, FSMs, UML notations
- Model-based languages are becoming more widely used. Đang được sử dụng rộng rãi
12.1 BNF Grammar Testing
- Terminal symbol coverage and production coverage have only been applied to algebraic
specifications. Phủ ký kiệu kết thúc và phủ production chỉ được áp dụng cho những đặc tả đại số,
- Algebraic specifications are not widely used. Những đặc tả đại số không được sử dụng rộng rãi
12.2 Specification-based Mutation
 A finite state machine is essentially a graph G (cơ chế trạng thái hữu hạn là chủ yếu trong đồ thị
G)
- Nodes are states: trạng thái nút
- Edges are transitions: chuyển trạng thái cạnh
 A formalization of an FSM is: chính thức hóa 1 FSM là:
- States are implicitly defined by declaring variables with limited range: những trạng thái được
định nghĩa hoàn toàn bằng cách khai báo biến trong 1 phạm vi giới hạn.
- The state space is then the Cartesian product of the ranges of the variables: Không gian trạng
thái là Cartesian product của giới hạn của các biến.
MODULE main
#define false 0
#define trueare1defined by limiting the ranges of some or all of the variables. Trạng thái khởi
- Initial states
tạo được định nghĩa bằng cách hạn chế giới hạn của 1 vài hay tất cả các biến.
VAR
- Transitions are defined by rules that characterize the source and target of each transition. Sự
chuyểnx,đổiyđược
: boolean;
định nghĩa bằng các rule, những đặc trưng nguồn và đích của mỗi sự chuyển
đổi
ASSIGN
init (x) := false;
init (y) := false;
next (x) := case
!x & y : true;
!y : true;
x : false;
true : x;
esac;
next (y) := case
x & !y : false;
FS
x & y : y;
M
FF !xTT& y : false;
ver
true : true;
TF sioFT
esac;
n
• Converting from SMV to FSM is mechanical and easy to automate: Chuyển đổi từ SMV sang
FSM một cách máy móc và tự động dễ dàng.
• SMV notation is smaller than graphs for large finite state machines: Chú thích SMV thì nhỏ hơn
đồ thị cho cơ chế trạng thái hữu hạn
 Using SMV Descriptions: sử dụng mô tả SMV
- Finite state descriptions can capture system behavior at a very high level – suitable for
communicating with end users: Mô tả trạng thái hữu hạn có thể giành system behavior ở 1 mức
độ rất cao – phù hợp cho việc giao tiếp với người dùng cuối
- The verification community has built powerful analysis tools for finite state machines expressed
in SMV: Xác định các giao tiếp được xây dựng những công cụ phân tích mạnh mẽ cho cơ chế
trạng thái hữu hạn
- These tools produce explicit evidence for properties that are not true Những tool tạo ra những
bằng chứng rõ ràng cho những thuộc tính không đúng.
- This “evidence” is presented as sequences of states, called “counterexamples” Bằng chứng này
đại diện như là 1 chuỗi trạng thái, được gọi là “counterexamples”
- Counterexamples are paths through the FSM that can be used as test cases : là những paths trong
FSM có thể được sử dụng như những test cases.

mutated FSM
 Summary
o Phát triển chậm
o Finite state machines can be encoded into model checkers. Cơ chế trạng thái hữu hạn có thể được mã
hóa thành model checkers.
o Properties can be defined on FSMs and model checking used to find paths that violate the properties
Những thuộc tính có thể dược xác định trên FSMs và model checking được dùng để tìm paths mà vi
phạm đến các thuộc tính
o No equivalent mutants Không có những mutants tương đương.
o Everything is finite: Mọi thứ đều hữu hạn

Вам также может понравиться