Kiểm thử phần mềm

Software Testing

A Perspective on Testing

1/31


Nội dung
 Lý do, định nghĩa kiểm thử
 Các định nghĩa cơ bản:



Error, Fault, Failure, Incident
Test, Testcase

 Trường hợp kiểm thử (Test cases)
 Sơ đồ Venn
 Các trường hợp kiểm thử



Functional Testing
Structural Testing

 Thảo luận: Functional & Structural
 Lỗi & phân loại lỗi
 Level of Testing
2/31

Lý do, định nghĩa kiểm thử
 Có hai lý do chính:



Để đánh giá về chất lượng phần mềm.
Để phát hiện ra các vấn đề.

 Chúng ta thực hiện kiểm thử vì biết
chắc rằng chúng ta có thể làm sai, đặc
biệt là trong lĩnh vực phần mềm
 Định nghĩa kiểm thử:
Kiểm thử là quá trình thực hiện chương trình với mục đích:
 Tìm ra các lỗi có thể.
 Để chỉ ra rằng phần mềm đã thực hiện chức năng của nó một
cách đúng đắn.
3/31


Các định nghĩa cơ bản
 Error (sai lầm):


Là sai lầm do con người mắc phải trong quá trình làm phần mềm, nó
đồng nghĩa với từ “mistake”. Ví dụ khi lập trình viên mắc sai lầm trong
việc coding thì ta gọi đó là bug.

 Fault (lỗi):


Fault là kết quả của error hay nói chính xác là thể hiện của error. Ví
dụ nó có thể là đoạn văn bản khi lấy yêu cầu khách hàng, hoặc có
thể là sơ đồ luồng dữ liệu khi làm thiết kế…

 Failure(thất bại):


Một thất bại xảy ra khi thực thi một fault (thông thường xảy ra trong
mã nguồn).

 Incident (sự kiện):


Là biểu hiện (hoặc một số các biểu hiện) khi xảy ra failure, để thông
báo cho người dùng biết được sự xuất hiện của failure.
4/31


Các định nghĩa cơ bản (2)
 Test (kiểm thử):


Kiểm thử là quá trình tìm ra failure, hoặc chứng tỏ rằng sự thực
hiện chương trình là đúng.

 Testcase (trường hợp kiểm thử):


Một trường hợp kiểm thử tương ứng với thực hiện chương trình
với tập dữ liệu đầu vào, và các dữ liệu đầu ra mong muốn.

5/31


Trường hợp kiểm thử (Test cases)
 Vấn đề cốt lõi của kiểm thử phần mềm là xác định tập
các trường hợp kiểm thử cho nội dung mà ta cần
kiểm thử.
 Các thông tin cần phải có trong trường hợp kiểm
thử: :



Dữ liệu đầu vào, gồm có 2 loại: dữ liệu tiền điều kiện (pre-condition), dữ liệu đầu vào
thực cho testcase.
Dữ liệu đầu ra, gồm 2 loại: dữ liệu hậu điều kiện (postcondition), dữ liệu đầu ra thực tế.

 Các trường hợp kiểm thử nên có một định danh, một
lý do kiểm thử, ngoài ra cũng nên lưu lại lịch sử thực
thi các trường hợp kiểm thử, bao gồm: khi nào và ai
thực hiện, có lỗi hay không có lỗi và phiên bản của
phần mềm kiểm thử.
 Kiểm thử cũng có giá trị như mã nguồn.
6/31


Các thông tin chính của trường hợp kiểm
thử
 Các thông tin của một trường hợp kiểm
thử

Định danh:
Mục đích:
Tiền điều kiện:
Dữ liệu vào:
Dữ liệu ra:
Dữ liệu ra mong muốn:
Lịch sử thực hiện:
Ngày :
kết quả:
Phiên bản:

Người thực hiện

7/31


Vòng đời kiểm thử
Fix

error
Đặc tả yêu cầu

Sửa lỗi
error

Fault

Thiết kế

Cô lập lỗi

error

Fault

Phân loại lỗi

Cài đặt
Fault

Incident

Kiểm thử
8/31


Sơ đồ Venn
 Kiểm thử phần mềm về cơ bản là liên
quan đến hành vi của chương trình.
 Một trong những khó khăn của người
kiểm thử là các tài liệu chủ yếu được
viết bởi hoặc viết cho những người
phát triển phần mềm, do đó nó chú
trọng vào cấu trúc hơn là hành vi
 Chúng ta xem xét một sơ đồ venn để
làm rõ thêm các vấn đề trong kiểm thử.
9/31


Sơ đồ Venn (2)

Program behaviors

S

P

Specification

Program

(expected)

(observed)

10/31


Sơ đồ venn (3)
 Chúng ta thấy rõ là có những hành vi
của đặc tả mà chương trình không có.
 Cũng có những hành vi của chương
trình mà không có trong đặc tả.
 Phần giao nhau của S và P là phần
đúng, những hành vi này có cả trong
đặc tả và trong cài đặt.

11/31


Sơ đồ Venn (4)

Specification

Program

(expected)

(observed)

6

2

5

P

S
1
4

3

T
7

Test case
(Verified)

12/31

Sơ đồ venn (5)
 Chúng ta thấy có những hành vi có trong đặc tả
nhưng không có trường hợp kiểm thử tương
ứng (test case) thì các trường hợp kiểm thử là
chưa đầy đủ.
 Có những trường hợp kiểm thử không có hành
vi tương ứng trong đặc tả, lúc đó xảy ra 2
trường hợp hoặc là các trường hợp kiểm thử là
không đảm bảo hoặc là đặc tả bị thiếu.
 Người kiểm thử cần làm những gì để cho vùng
1 là lớn nhất có thể? Hay làm thế nào để xác
định được các trường hợp kiểm thử trong T.
Điều này phụ thuộc vào phương pháp kiểm thử.
13/31


Xác định các trường hợp kiểm thử

 Có hai cách tiếp cận chính để xác định
các trường hợp kiểm thử đó là:



Kiểm thử theo chức năng (Function testing).
Kiểm thử theo cấu trúc (Structural Testing)

14/31

Kiểm thử theo chức năng
 Kiểm thử theo chức năng là dựa trên việc
nhìn nhận bất kì chương trình nào cũng
gồm các hàm ánh xạ các giá trị từ miền vào
sang miền dữ liệu ra.
 Với cách tiếp cận theo chức năng để xác
định các trường hợp kiểm thử ta chỉ quan
tâm đến tài liệu đặc tả phần mềm.
 Không cần quan tâm đến nội dung cài đặt
chỉ quan tâm đến đầu vào và đầu ra.
Phương pháp này còn gọi là phương pháp
kiểm thử kiểu “hộp đen” (black box)
15/31


Kiểm thử theo chức năng (2)
 Ưu điểm:




Chúng độc lập với cách thức cài đặt phần mềm, vì vậy nếu
chúng ta thay đổi cách thức cài đặt thì vẫn có thể sử dụng được
các trường hợp kiểm thử.
Chúng ta có thể thực hiện kiểm thử song song với quá trình cài
đặt phần mềm, làm giảm thời gian phát triển dự án.

 Nhược điểm:




Có thể gây dư thừa các trường hợp kiểm thử
Các trường hợp kiểm thử theo chức năng vẫn chưa phủ được
hết chương trình và vẫn có thể có những lỗ hổng mà của phần
mềm không được kiểm thử

16/31


Kiểm thử theo cấu trúc (Structural Testing)
 Structural Testing la gi ?



Tương phản với phương pháp Functional Testing, còn gọi là
White Box Testing
“See inside”: cho phép Tester xác đinh TCs dựa vào thực tế
implement source code

 Đối tượng:


Mã nguồn

 Mức độ:


Các module đơn vị (methods)

 Tester:


Những người biết lập trình (thường là Developer)

17/31


Nội dung, Mục tiêu kiểm thử cấu trúc
 Nội dung:





Mọi câu lệnh (phép gán, phép tính logic,…)
Mọi điều kiện Logic có thể (rẽ nhánh)
Mọi flow xử lý trong chương trình (Function A-> FunctionA1>FunctionA2)
Mọi cấu trúc dữ liệu được dùng

 Mục tiêu:





Mọi con đường độc lập trong module cần được thực hiện ít nhất 1 lần
Mọi ràng buộc logic được thực hiện cả 2 phía đúng (true) & phía sai
(false)
Tất cả các vòng lặp ở biên của nó & cả các biên vận hành phải được

thực hiện
Mọi cấu trúc dữ liệu nội tại được dùng để đảm bảo hiệu lực thi hành
của no.
18/31


Kĩ thuật sử dụng, mức độ bao phủ
 Thường sử dụng lý thuyết đồ thị
(Graph theory – Chapter 4) :



Mỗi nút (hình tròn) biểu thị một hay một số lệnh tuần tự , hoặc
thay cho điểm hội tụ các đường điều khiển
Mỗi cạnh nối 2 nút biểu diễn dòng điều khiển

 Mức độ bao phủ



Mong muốn kiểm tra tất cả các lệnh (câu lệnh) có trong chương
trình => rất khó vì khối lượng lớn
Do đó thiết kế phải tính tới sự cân xứng giữa “mức độ bao phủ”
và “năng suất”

19/31


Ví dụ sử dụng lý thuyết đồ thị
buy(dress, bag) {

A

A

if dress already in bag

B

display “already bought it”

else

C

C

B

if bag is full

D

display “bag is full”

D

E

else

E
F
G

F

buy dress
display “buy successful”

end if

end if

G

}
20/31


Mục đích cuối cùng
A

What path coverage is achieved by
ABG, ACDFG, ACEFG?

C

B
D

E
F

G

3 in total.

3 covered

So 3/3 = 100% path coverage
21/31


Lý do thực hiện Structural Testing
$14,000

Percentage of Bugs

85%

% Defects
Introduced in
this phase
% Defects
found in
in this phase

$1000
$25

$130

Coding

Unit
Test

$ Cost to
repair defect
in this phase

$250
Funct
Test

System Post
Test Release

Source: Applied Software Measurement,
Capers Jones, 1996

22/31


Thảo luận: Functional & Structural
 Functional :



Không dựa vào source code
Thường dựa vào đặc tả (SRS,…) để xây dựng TCs. Nếu SRS
ko mô tả, mà source code implement thì ko được phản ánh

 Structural



Dựa vào source code
Code thường dựa vào SDD. Nếu source code được implement
thiếu so với SRS (do SDD làm sơ sài,…) thì nhìn vào source
code ko nhận ra thiếu sót

23/31


Lỗi & phân loại lỗi
 Xoay quanh sự khác biệt giữa Process
& Product:



Process: Chỉ dẫn cách thức, phương pháp làm
Product: Kết quả cuối cùng của 1 process

 Testing and Software Quality
Assurance (SQA)
SQA cố gắng cải tiến product bằng cách cải tiến process
 SQA liên quan nhiều hơn tới cách giảm thiểu lỗi trong quá trình
phát triển, trong khi Testing thì liên quan tới tìm ra lỗi của sản

phẩm
=> Cả 2 đều hưởng lợi từ việc định nghĩa rõ ràng kiểu của lỗi


24/31


Phân loại lỗi
 Lỗi có thể được phân loại theo nhiều
cách:



Lỗi phát sinh trong giai đoạn phát triển (Development)
Lỗi phát sinh khi triên khai,…

25/31