Bài giảng Kiểm thử phần mềm (Software testing) - Chương 6: Kỹ thuật kiểm thử hộp đen (Tiếp theo)

Chương 6

Kỹ thuật kiểm thử hộp ₫en (tt)

6.1 Kỹ thuật dùng lược ₫ồ chuyển trạng thái

Cũng giống như bảng quyết ₫ịnh, lược ₫ồ chuyển trạng thái là

1 công cụ rất hữu ích ₫ể ₫ặc tả các yêu cầu phần mềm hoặc ₫ể

₫ặc tả bảng thiết kế hệ thống phần mềm.

Thay vì miêu tả các qui tắc nghiệp vụ phức tạp mà phần mềm

phải thực hiện dưới dạng dễ ₫ọc và dễ kiểm soát như bảng quyết

₫ịnh, lược ₫ồ chuyển trạng thái ghi nhận các sự kiện xảy ra, rồi

₫ược hệ thống xử lý cũng như những ₫áp ứng của hệ thống.

Khi hệ thống phải nhớ trạng thái trước ₫ó của mình, hay phải

biết trình tự các hoạt ₫ộng nào là hợp lệ, trình tự nào là không hợp

lệ thì lược ₫ồ chuyển trạng thái là rất thích hợp.

Lược ₫ồ chuyển trạng thái ₫ược cấu thành từ các thành phần

cơ bản sau ₫ây :

Trạng thái ₫ầu

Trạng thái cuối

Trạng thái trung gian

Ta có thể ₫ặt tên nhận dạng cho từng trạng thái trung gian, miêu

tả ₫iều kiện chuyển trạng thái kèm theo từng cung chuyển trạng

thái.

Ta có thể miêu tả hành ₫ộng cần thực hiện kết hợp với việc

chuyển trạng thái.

Lược ₫ồ chuyển trạng thái của TPPM ₫ặt mua vé máy bay :

TPPM ₫ặt mua vé máy bay có 6 trạng thái khác nhau :

1. Made :

à

₫iều kiện chuyển ₫ến : sau khi người dùng ₫ã nhập

thông tin khách hàng.

à Hành ₫ộng cần thực hiện kèm theo : khởi ₫ộng timer

T0 ₫ếm thời gian giữ trạng thái.

2. Cancelled (NonPay) :

à

₫iều kiện chuyển ₫ến : sau khi timer T0 ₫ã hết.

à Hành ₫ộng cần thực hiện kèm theo : null.

3. Paid :

₫iều kiện chuyển ₫ến : sau khi người dùng ₫ã thanh

toán tiền.

à

à Hành ₫ộng cần thực hiện kèm theo : null.

4. Cancelled (ByCustomer) :

à

₫iều kiện chuyển ₫ến : sau khi người dùng ₫ã cancel.

à Hành ₫ộng cần thực hiện kèm theo : null.

5. Ticketed :

₫iều kiện chuyển ₫ến : sau khi in vé xong.

à Kết quả kèm theo : vé máy bay.

6. Used :

₫iều kiện chuyển ₫ến : sau khi người dùng ₫ã dùng vé.

à

à Hành ₫ộng cần thực hiện kèm theo : null.

Trong khi lược ₫ồ chuyển trạng thái là cách thức miêu tả hành

vi của TPPM dễ hiểu và dễ ₫ọc thì 1 dạng khác - bảng chuyển

trạng thái — có thể miêu tả hành vi của TPPM hệ thống hơn và dễ

xử lý tự ₫ộng hơn.

Bảng chuyển trạng thái gồm 4 cột : trạng thái hiện hành, sự

kiện xảy ra, hành ₫ộng cần thực hiện/kết quả thu ₫ược, trạng thái

kế tiếp.

Thí dụ lược ₫ồ chuyển trạng thái ở slide trước có thể chuyển

thành bảng chuyển trạng thái :

Current State

Event

Action

Next State

null

giveInfo

startPayTimer Made

null

payMoney

print

giveTicket

cancel

--

null

PayTimerExpires --

Made

giveInfo --

Made

Current State

Made

Event

payMoney

print

giveTicket

cancel

PayTimerExpires --

Action

Next State

--

Paid

Made

Can-Cust

Can-NonPay

Paid

giveInfo

payMoney

print

giveTicket

cancel

--

Paid

Ticketed

Paid

Can-Cust

Paid

Ticket

--

Refund

PayTimerExpires --

Ticketed

giveInfo

payMoney

print

giveTicket

cancel

--

Ticketed

Used

Can-Cust

Ticketed

Refund

PayTimerExpires --

Used

giveInfo

payMoney

print

giveTicket

cancel

--

Used

PayTimerExpires --

Can-NonPay

giveInfo

payMoney

print

giveTicket

cancel

--

Can-NonPay

PayTimerExpires --

Current State

Event

givelnfo

payMoney

print

giveTicket

cancel

PayTimerExpires --

Action

Next State

Can-Cust

--

Dựa vào lược ₫ồ chuyển trạng thái, ta có thể dễ dàng ₫ịnh

nghĩa các testcase.

1. Phủ cấp 1 : tạo các testcase sao cho mỗi trạng thái ₫ều

xảy ra ít nhất 1 lần. Thí dụ 3 tescase sau sẽ kiểm thử ₫ược

TPPM ₫ạt phủ cấp 1 :

2. Phủ cấp 2 : tạo các testcase sao cho mỗi sự kiện ₫ều xảy

ra ít nhất 1 lần. Thí dụ 3 tescase sau sẽ kiểm thử ₫ược

TPPM ₫ạt phủ cấp 2 :

3. Phủ cấp 3 : tạo các testcase sao cho tất cả các path

chuyển ₫ều ₫ược kiểm thử. 1 path chuyển là 1 ₫ường

chuyển trạng thái xác ₫ịnh, bắt ₫ầu từ trạng thái nhập và

kết thúc ở trạng thái kết thúc.

Đây là phủ tốt nhất vì ₫ã vét cạn mọi khả năng hoạt ₫ộng

của TPPM, tuy nhiên không khả thi vì 1 path chuyển có

thể lặp vòng.

4. Phủ cấp 4 : tạo các testcase sao cho mỗi path chuyển

tuyến tính ₫ều xảy ra ít nhất 1 lần. Thí dụ 5 tescase sau sẽ

kiểm thử ₫ược TPPM ₫ạt phủ cấp 4 :

Dựa vào bảng chuyển trạng thái, ta cũng có thể dễ dàng ₫ịnh

nghĩa các testcase.

Current State

Event

Action

Next State

null

giveInfo

startPayTimer Made

payMoney

print

--

null

giveTicket

cancel

PayTimerExpires

Made

giveInfo

--

Made

payMoney

print

Paid

Made

giveTicket

cancel

Made

Can-Cust

Can-NonPay

PayTimerExpires

Paid

giveInfo

--

Paid

Current State

Paid

Event

payMoney

Action

Next State

Paid

--

Paid

print

Ticket

--

Ticketed

Paid

giveTicket

cancel

Paid

Refund

--

Can-Cust

Paid

PayTimerExpires

Ticketed

giveInfo

--

Ticketed

Used

payMoney

print

--

giveTicket

cancel

--

Refund

--

Can-Cust

Ticketed

PayTimerExpires

Used

giveInfo

--

Used

payMoney

print

giveTicket

cancel

PayTimerExpires

Can-NonPay

giveInfo

--

Can-NonPay

payMoney

print

giveTicket

cancel

PayTimerExpires

Can-Cust

givelnfo

payMoney

print

--

Can-Cust

Current State

Can-Cust

Event

giveTicket

Action

Next State

Can-Cust

--

Can-Cust

cancel

Can-Cust

PayTimerExpires

6.2 Kỹ thuật phân tích vùng (Domain Analysis)

Như ta ₫ã biết, 2 kỹ thuật kiểm thử phân lớp tương ₫ương và

phân tích giá trị biên chủ yếu xử lý các biến dữ liệu ₫ộc lập, rời rạc.

Tuy nhiên thường thì các biến dữ liệu có mối quan hệ với nhau, do

₫ó cách tốt nhất là nên tổ hợp chúng ₫ể kiểm thử :

Nếu tạo các testcase cho từng biến dữ liệu ₫ộc lập thì số

lượng testcase sẽ quá nhiều.

Các biến dữ liệu thường tương tác nhau, giá trị của biến

này có thể ràng buộc giá trị của biến kia, do ₫ó nếu kiểm

thử chúng ₫ộc lập thì không thể phát hiện lỗi liên quan ₫ến

sự ràng buộc này.

Kỹ thuật phân tích vùng rất thích hợp trong việc xác ₫ịnh các

testcase hiệu quả khi các biến dữ liệu có sự tương tác lẫn nhau.

Nó ₫ược xây dựng trên 2 kỹ thuật kiểm thử ₫ược ₫ề cập ở trên và

tổng quát hóa chúng ₫ể kiểm thử ₫ồng thời n biến dữ liệu.

Xét trường hợp 2 biến dữ liệu tương tác nhau, ta thấy có 4 loại

lỗi sau :

1. Biên ngang bị dịch lên hay xuống

Đúng

Sai

2. Biên nghiêng sai góc

Đúng

Sai

3. Thiếu biên

Đúng

Sai

4. Thừa biên

Đúng

Sai

Ta ₫ịnh nghĩa 1 số thuật ngữ :

1. Điểm on : là ₫iểm nằm trên biên

2. Điểm off : là ₫iểm không nằm trên biên

3. Điểm in : là ₫iểm thỏa mọi ₫iều kiện biên nhưng không

nằm trên biên.

4. Điểm out : là ₫iểm không thỏa bất kỳ ₫iều kiện biên.

Việc chọn ₫iểm on và off thường phức tạp hơn chúng ta nghĩ :

Nếu biên ₫óng (dùng toán tử so sánh có yếu tố =), thì

₫iểm on nằm trên biên và thuộc vùng xử lý. Trong trường

hợp này, ta chọn ₫iểm off nằm ngoài vùng xử lý.

Nếu biên mở (dùng toán tử so sánh không có yếu tố =), thì

₫iểm on nằm trên biên nhưng không thuộc vùng xử lý.

Trong trường hợp này ta chọn ₫iểm off nằm trong vùng xử

lý.

Thí dụ về các ₫iểm on, off, in và out :

Kỹ thuật phân tích vùng yêu cầu chúng ta chọn các tescase

theo cách thức sau :

1. Ứng với mỗi ₫iều kiện <, >, ≤, ≥, chọn 1 ₫iểm on và 1 ₫iểm

off.

2. Ứng với mỗi ₫iều kiện =, ≠, chọn 1 ₫iểm on, 2 ₫iểm off

ngay trên và ngay dưới ₫iểm on.

Binder ₫ề nghị 1 bảng rất hữu ích — ma trận kiểm thử vùng :

Thí dụ, TPPM xét kết quả ₫ậu ₫ại học theo tiêu chuẩn sau :

10*GPA + ACT >= 71

GPA : ₫iểm trung bình tích lũy của lớp phổ thông (<=4.0)

ACT : ₫iểm thi tuyển vào ₫ại học (<= 36).

6.3 Kỹ thuật dùng thông tin trong use-case

Trong qui trình phát triển phần mềm hợp nhất, ta thực hiện

nhiều workflows khác nhau : nắm bắt yêu cầu phần mềm, phân

tích từng yêu cầu, thiết kế chi tiết ₫ể giải quyết từng yêu cầu, hiện

thực từng phần bảng thiết kế, kiểm thử kết quả.

Mỗi workflows, thậm chí mỗi lần lập thực hiện 1 workflow, ta

phải có kết quả, kết quả này phải ₫ược miêu tả ở dạng dễ ₫ọc, dễ

hiểu bởi nhiều người và phải cố gắng ₫ơn nghĩa ₫ể tránh nhặp

nhằng.

Ta dùng khái niệm mô hình ₫ể miêu tả hệ thống phần mềm

theo một góc nhìn nào ₫ó.

UML diagrams provide

views into each model

Requirements

Use Case

Model

Analysis

Model

Analysis

Design

Model

Depl.

Model

Impl.

Model

Implementation

Test

Each workflow is

associated with one or

more models.

Test

Model

Về nguyên tắc, khi kiểm thử 1 thành phần phần mềm, ta có thể

tận dụng bất kỳ thông tin nào trong bất kỳ mô hình nào. Kỹ thuật

kiểm thử dùng thông tin trong use-case là kỹ thuật ₫ịnh nghĩa các

testcase dựa vào các kịch bản thực hiện usecase.

Như chúng ta biết, mô hình usecase miêu tả hệ thống phần

mềm theo góc nhìn bên ngoài : nó cung cấp các chức năng nào

cho những “user” nào. Thành phần thiết yếu nhất của mô hình

usecase là các lược ₫ồ usecase.

Mỗi lược ₫ồ usecsae thể hiện 1 bộ phận nhỏ của phần mềm :

nó bao gồm nhiều chức năng và các chức năng này tương tác với

các actor nào.

Thí dụ lược ₫ồ usecase liên quan ₫ến bộ phận chức năng

quản lý khách hàng trong hệ thống thương mại ₫iện tử.

<<include>>

User Maintenance

POS Login

Store Manager

<<extend>>

<<exten...

Edit User Information

Add New User

Remove User

Trong lược ₫ồ usecase, mỗi usecase thể hiện 1 chức năng mà

bên ngoài có thể truy xuất, tuy nhiên mỗi usecase chỉ ₫ược miêu

tả ở dạng tối giản : gồm 1 hình ellipse và tên gợi nhớ sơ bộ về

chức năng của usecase.

Để hiểu ₫ầy ₫ủ hơn về usecase, người ta cần ₫ặc tả usecase

ở 1 dạng chi tiết nào ₫ó. Rất tiết là hiện nay, mỗi nơi mỗi khác,

chưa có 1 chuẩn nào ₫ược mọi người chấp thuận.

Ở ₫ây, ta hãy dùng khuôn mẫu chi tiết ₫ể ₫ặc tả usecase do

Alistair Cockburn ₫ề nghị trong sách “Writing Effective Use

Cases”.

Use Case Component

Description

A unique identifier for this use case

Use Case Number or Identifier

The name should be the goal stated as a short

active verb phrase

Use Case Name

Goal in Context

A more detailed statement of the goal if

necessary

Corporate | System | Subsystem

Scope

Level

Summary | Primary task | Subfunction

Use Case Component

Primary Actor

Description

Role name or description of the primary actor

The required state of the system before the use

case is triggered

Preconditions

The state of the system upon successful

completion of this use case

Success End Conditions

Failed End Conditions

The state of the system if the use case cannot

execute to completion

The action that initiates the execution of the use

case

Trigger

Main Success Scenario

Step

1

Action

2

...

Conditions under which the main success

scenario will vary and a description of those

variations

Extensions

Variations that do not affect the main flow but

that must be considered

Sub-Variations

Criticality

Priority

Time available to execute this use case

How often this use case is executed

Interactive | File | Database | ...

Response Time

Frequency

Channels to Primary Actor

Other actors needed to accomplish this use

case

Secondary Actors

Interactive | File | Database | ...

Schedule information

Channels to Secondary Actors

Date Due

Use Case identified (0.1)| Main scenario

defined (0.5) | All extensions defined (0.8) | All

fields complete (1.0)

Completeness Level

Open Issues

Unresolved issues awaiting decisions

Thí dụ bảng ₫ặc tả usecase “₫ăng ký môn học” trong phần

mềm quản lý học vụ có nội dung chi tiết như sau :

Use Case Component

Description

SURS1138

Use Case Number or

Identifier

Register for a course (a class taught by a faculty

member)

Use Case Name

Goal in Context

Scope

System

Primary task

Student

None

Level

Primary Actor

Preconditions

The student is registered for the course–the course

has been added to the student's course list

Success End Conditions

The student's course list is unchanged

Student selects a course and "Registers"

Step Action

Failed End Conditions

Trigger

1

2

3

4

5

6

A: Selects "Register for a course"

A: Selects course (e.g. Math 1060)

S: Displays course description

A: Selects section (Mon & Wed 9:00am)

S: Displays section days and times

A: Accepts

Main Success Scenario

A: Actor

S: System

S: Adds course/section to student's course

list

7

Course does not exist

S: Display message and exit

2a

Section does not exist

S: Display message and exit

4a

4b

6a

Extensions

Section is full

S: Display message and exit

Student does not accept

S: Display message and exit

Use Case Component

Sub-Variations

Description

Student may use

• Web

• Phone

Critical

Priority

10 seconds or less

Response Time

Approximately 5 courses x 10,000 students over a

4-week period

Frequency

Interactive

None

Channels to Primary Actor

Secondary Actors

N/A

Channels to Secondary

Actors

1 Feb

0.5

Date Due

Completeness Level

Open Issues

None

Dựa vào ₫ặc tả về kịch bản chính và về các nới rộng của kịch

bản, ta sẽ thiết kế các testcase theo ý tưởng như sau :

Ít nhất 1 testcase ₫ể kiểm thử kịch bản chính.

Ít nhất 1 testcase cho từng nới rộng có thể có.

Nếu kịch bản chính hay 1 nới rộng nào ₫ó bị loop thì

không cần thiết phải kiểm thử phần loop lại.

6.4 Kỹ thuật dùng ₫ồ thị nhân quả (Cause-Effect Diagram)

Đồ thị nhân quả là 1 dạng khác của mạng luận lý tổ hợp mà

phần cứng thường dùng. Các phần tử cấu thành ₫ồ thị nhân quả là

:

các nút : mỗi nút miêu tả 1 hậu quả (1 hay nhiều hoạt

₫ộng + 1 hay nhiều kết quả).

các ₫oạn thẳng : mỗi ₫oạn thẳng miêu tả 1 nguyên nhân

(1 ₫iều kiện dữ liệu nhập ở dạng nhị phân)

các ký hiệu : mỗi ký hiệu miêu tả 1 phép toán luận lý.

các phần tử ràng buộc, mỗi phần tử miêu tả 1 ràng buộc

xác ₫ịnh nào ₫ó.

Identify

Not

b

a

b

a

b

a

b

Z

a

Z

Ident

Not

a

b

a

And

Or

c

∩

b

c

d

∪

a

b

a

c

d

b

c

Giả sử ₫ặc tả 1 TPPM như sau : dữ liệu ₫ầu vào là tên file gồm

2 ký tự, ký tự ₫ầu là A hay B, ký tự còn lại là ký số, TPPM sẽ cập

nhật file, nếu ký tự ₫ầu không phải là A hay B thì TPPM báo lỗi X1,

nếu ký tự thứ 2 không phải là số thì báo lỗi X2.

Duyệt ₫ọc ₫ặc tả và phân tích ₫ặc tả, ta tìm ₫ược các ₫iều

kiện ₫ầu vào là :

1 : Ký tự ₫ầu là A.

2 : Ký tự ₫ầu là B.

3 : Ký tự thứ hai là ký số.

Và các hậu quả ở ₫ầu ra là :

101 : cập nhật file.

102 : báo lỗi X1.

103 : báo lỗi X2.

Đồ thị nhân quả của TPPM ở silde trước là :

Bài giảng Kiểm thử phần mềm (Software testing) - Chương 6: Kỹ thuật kiểm thử hộp đen (Tiếp theo) - Nguyễn Văn Hiệp