Bai Giang KTKTPM CaoDang 2021

Bài giảng
Kỹ thuật kiểm thử phần mềm

(Dành cho trình độ Cao đẳng)
GV: TS. Nguyễn Quang Vũ

E-mail: nqvu@vku.udn.vn
Một cách tiếp cận “thực”!
Một cách tiếp cận vui!
Một cách tiếp cận “không vui”!
The way to remove defects
$59.5 billion/year in
USA
HIGH COST OF
SOFTWARE DEFECTS
(The Economic Impacts of
Research by CISQ found that, in 2018, poor
Inadequate Infrastructure
for Software Testing" quality software cost organizations $2.8
report for National trillion in the US alone. On average,
Institute of Standards & software developers make 100 to 150 errors
Technology, US for every thousand lines of code !!
Department of Commerce,
2002)
*CISQ: Consortium for Information & Software Quality

Ảnh hưởng của “phần mềm lỗi”
 3C
 Customers (Khách hàng)
 Company (Công ty)
 (Your) Career (Sự nghiệp)
KIỂM THỬ PHẦN MỀM
NỘI DUNG CHÍNH

1 PHẦN MỀM VÀ LỖI PHẦN MỀM
2 KỸ THUẬT KIỂM THỬ PHẦN MỀM
3 CHIẾN LƯỢC KIỂM THỬ PHẦN MỀM
4 XÂY DỰNG ỨNG DỤNG KIỂM THỬ ĐƠN VỊ
5 MỘT SỐ PHẦN MỀM KIỂM THỬ THÔNG DỤNG

Chương 1. Phần mềm và lỗi phần mềm
Công nghệ phần mềm (CNPM) ?

Các tác vụ chủ yếu của CNPM:
 Đặc tả yêu cầu – Phân tích - Thiết kế
 Cài đặt
 Kiểm thử
 Triển khai - Bảo trì
Mục tiêu của CNPM:
 Tạo ra phần mềm tốt
 Giảm thiểu sai sót trong quá trình vận hành
 Thuận lợi trong bảo trì và nâng cấp
Phần mềm ?
 là một tập các đoạn mã hoặc câu lệnh viết ra để cài đặt
trên máy tính nhằm thực hiện một hoặc một nhóm chức
năng nào đó và tất cả các hồ sơ kèm theo!
Các công việc trong vòng đời một phần mềm:
 Phân tích, đặc tả yêu cầu
 Phân tích, thiết kế hệ thống
 Lập trình/Cài đặt
 Kiểm thử
 Viết tài liệu
 Triển khai - Bảo trì
Phân loại phần mềm: Cách 1

Phân loại phần mềm: Cách 2
SOFTWARE
Application System
Software is Software
designed as a “work is designed to
environment” operate the
between end-user computer hardware,
and computer. to provide basic
functionality, and to
provide a platform
for running
application software.
Cách 3: Có thể phân loại PM theo sự định hướng

công việc:
 Ứng dụng hướng giao dịch
 Ứng dụng CSDL
 Ứng dụng hỗ trợ quyết định
 Hệ chuyên gia
 Hệ thống nhúng
Lỗi phần mềm
Thế nào là phần mềm được gọi là đúng ?

Để đánh giá CẤP ĐỘ ĐÚNG của phần mềm, phải
kiểm tra CHẤT LƯỢNG PHẦN MỀM
 Chất lượng phần mềm là “mức độ phù hợp của phần
mềm so với dự định hoặc đặc tả”! (Đủ và đúng!)
 Có nhiều tiêu chí để đánh giá:
• Đầy đủ chức năng và hữu dụng;
• Tính hiệu quả (Chi phí; Thời gian; Không gian);
• An toàn; Tin cậy: “Mạnh mẽ”; Chịu lỗi:
• Khả năng sử dụng và bảo trì;
• Và quan trọng nhất: Tính chính xác ! (Không có lỗi????)
Lỗi phần mềm
Định nghĩa LỖI PHẦN MỀM?

 Lỗi phần mềm là sự không khớp giữa chương
trình và đặc tả của nó.
Chất lượng phần mềm
Về cơ bản, một phần mềm chất lượng là “phần

mềm cung cấp ĐỦ và ĐÚNG (theo đặc tả) các
chức năng và hiệu năng cần thiết cho người dùng
và đảm bảo độ tin cậy, bảo trì và hiệu quả sử dụng!
Phân biệt các khái niệm “Lỗi”:
 Error/Mistake
 Fault (Defect/Bug)
 Failure
Failure is an event; fault is a state of
the software, caused by an error
Chất lượng phần mềm
Error -> Fault -> Failure

Một
“error” của con
người ....
… từ đó, tạo ra
một/nhiều
“fault” trong phần
mềm ...
… dẫn đến phần mềm

bị “failure”
trong quá trình vận
hành!
Vậy, lỗi phần mềm xảy ra ở công đoạn nào?

Lỗi phần mềm
Lỗi phần mềm xảy

ra ở tất cả các
công đoạn
Lỗi phần mềm
Lỗi phần mềm xuất hiện nhiều nhất ở công đoạn:

 Đặc tả: ~ 70%
Nguyên nhân khác
Lập trình
Thiết kế
Đặc tả
Lỗi phần mềm
Nguyên nhân làm đặc tả nhiều lỗi ?

 Đặc tả không được viết ra;
 Đặc tả không đủ cẩn thận;
 Sự thay đổi yêu cầu không được cập nhật trong đặc tả;
 Đặc tả thay đổi sau khi đã thực hiện các công đoạn sau;
 Chưa phối hợp tốt trong nhóm;
 ...
Lỗi phần mềm
Ví dụ: Bài toán phân số

 Đặc tả phi hình thức: phân số là một cặp t/m, trong đó t là
một số nguyên, m là một số tự nhiên lớn hơn 0; t được
gọi là tử số, m được gọi là mẫu số của phân số
 Đặc tả hình thức: là đặc tả trong đó sử dụng các ký hiệu
toán học để mô tả.
Phân số = {(t,m) | t  Z, m  N+} (*)
Trong đó: N = {0, 1, 2, 3, …}
N+ = {1, 2, 3, …}
Z = {0, 1, 2, 3, …}
Lỗi phần mềm
Ví dụ (tt): Xét đặc tả phép chia hai phân số

 (t1,m1):(t2,m2) = Reduce(t1 m2, t2  m1), trong đó
Reduce(t, m) = (t/d, m/d) với d = gcd(t, m)
 Hàm gcd là hàm tìm ước số chung lớn nhất của hai số tự
nhiên.
 Bây giờ, hãy thực hiện chia hai phân số:
(1,3):(-2,5)?
Các lỗi phần mềm thường gặp
Sản phẩm phần mềm được được xây dựng thiếu,

sai, thừa so với đặc tả được xem là có lỗi.
Thậm chí, một phần mềm khó hiểu, khó sử dụng,
thực thi chậm, … cũng được xem là lỗi.
Lỗi phần mềm (tt)
Ví dụ: chương trình tính tiền lương được đặc

tả cho từng nhân viên theo qui định làm tròn
đến hàng đơn vị, với công thức (1.1)
Lươngi = round(hsli*lcb(1- 0.06),0 ) (1.1)
Nhưng khi lập trình:
Lươngi = round(hsli *lcb(1- 0.06),-2 ) (1.2)
Các lỗi phần mềm thường gặp (tt)
Ví dụ: Như vậy dẫn đến sai số như sau
Chênh lệnh
Stt Học và tên hsl CT(1.1) CT(1.2) tiền
lương
1 Lê Ngọc Anh 3,99 1.312.710 1.312.700 -10
2 Trần Thị Bình 2,34 769.860 769.900 +40
3 Nguyễn Văn Nam 4,32 1.421.280 1.421.300 +20

4 Bùi Anh Vũ 2,67 878.430 878.400 -30
Tổng cộng 4.382.280 4.382.300 +20
Lỗi phần mềm (tt)
Đặc tả thiếu: Một yêu cầu đã được đặc tả

nhưng lại không có trong sản phẩm được xây
dựng.
Ví dụ: Chương trình quản lý tính vốn vay, khi ngân hàng cho
vay vốn thì việc tính lãi được qui định theo hai phương thức là
tính lãi đơn và tính lãi kép. Nhưng khi thiết kế thì chương trình
chỉ tính lãi đơn không tính lãi kép. Do vậy, chương trình không
đưa vào ứng dụng ngay được mà phải sửa chữa cập nhật lại.
Các lỗi phần mềm thường gặp (tt)
Đặc tả thừa:
Một yêu cầu được đưa vào sản phẩm mà
không có trong đặc tả. Cũng có trường hợp
yêu cầu này có thể là một thuộc tính sẽ được
người dùng chấp nhận nhưng khác với đặc tả
nên vẫn coi là có lỗi.
Ví dụ: ????
Chi phí cho việc sửa lỗi phần mềm
Kiểm thử và sửa lỗi có thể được thực hiện tại bất
kỳ giai đoạn nào của vòng đời phần mềm
Chi phí cho việc tìm và sửa lỗi tăng một cách đáng
kể theo quá trình phát triển:
 Không đáng kể khi thay đổi yêu cầu ở lần duyệt yêu cầu
đầu tiên
 Tăng lên gấp bội khi thay đổi yêu cầu lúc đã lập trình
 Không đáng kể nếu lập trình viên tự phát hiện lỗi của
mình
“Sửa một lỗi trước khi phát hành một phần

mềm sẽ tốn chi phí ít hơn rất nhiều so với
việc khắc phục nó sau khi đã phát hành. ”
Lỗi được phát hiện càng muộn thì chi phí cho
việc sữa lỗi càng lớn
Chi
phí
để
sữa
lỗi
Đặc tả Thiết kế lập trình Kiểm thử Phát hành

(~25 USD/lỗi) (~16.000 USD/lỗi)
* Nghiên cứu của Casper Jones

Đảm bảo chất lượng phần mềm
Mục đích của nhóm phát triển PM là có PM chất

lượng cao
Hạn chế thấp nhất việc phát sinh lỗi
Đảm bảo chất lượng phần mềm là một hoạt động
có hệ thống và kế hoạch
Đảm bảo chất lượng phần mềm gồm nhiều nhiệm

vụ liên kết và các hoạt động chính sau:
 Áp dụng các phương pháp kỹ thuật,
 Tiến hành các cuộc xét duyệt kỹ thuật chính thức,
 Kiểm thử phần mềm,
 Buộc tôn trọng các chuẩn,
 Kiểm soát thay đổi,
 Đo chất lượng,
 Báo cáo, lưu giữ kết quả.
Đảm bảo chất lượng phần mềm là một hoạt động

BẢN CHẤT cho bất kỳ nhóm phát triển PM nào.
Có hai kỹ thuật để tăng độ tin cậy của phần mềm:
 Tránh lỗi
 Thứ lỗi
Tránh lỗi
 Đặc tả hệ thống chính xác
 Tăng cường duyệt và thẩm định
 Chấp nhận triết lý chất lượng tổ chức: chất lượng là bánh
lái của quá trình phát triển phần mềm.
 Lập kế hoạch cẩn thẩn cho việc thử nghiệm hệ thống
Thứ lỗi
 Một hệ vô lỗi thì vẫn cần một tiện ích thứ lỗi: đó là vì có
thể có các lỗi đặc tả
 Một tiện ích thứ lỗi là cần thiết cho một hệ thống đáng tin
cậy
4 hoạt động cần tiến hành để THỨ LỖI

 Phát hiện lỗi;
 Định ra mức độ thiệt hại;
 Hồi phục sau khi gặp lỗi:
 Chữa lỗi;
Xác minh và Thẩm định
V&V – Verification and Validation ;

Là một quá trình liên tục xuyên suốt mọi giai đoạn
của tiến trình phát triển phần mềm;
Là từ chung cho các quá trình kiểm thử ;
Có hai mục tiêu:
 Phát hiện các “khuyết tật” trong hệ thống.
 Đánh giá xem hệ thống liệu có dùng được hay không?
Sự khác nhau giữa xác minh và thẩm định:

 Xác minh (Verification):
• Are we building the product right?
 Thẩm định (Validation):
• Are we building the right product ?
WHO?
Software End
Developers
testing users
Testers Project
manager
ww
w.t
he
Chương 2.
Kiểm thử phần mềm
Chương 2. Kiểm thử phần mềm
Kiểm thử là gì ?
 KTPM bao gồm việc "chạy thử" phần mềm (PM)
hay một chức năng của PM, xem nó "chạy" đúng
như mong muốn hay không;
 Kiểm thử phần mềm là cho thực thi chương trình
để tìm lỗi;
Đóng vai trò tối quan trọng, quyết định đến

việc đánh giá chất lượng phần mềm;
Là quá trình tìm lỗi (nếu có);
Mục đích của kiểm thử là đảm bảo rằng tất
cả các thành phần của phần mềm ăn khớp,
vận hành như mong đợi và phù hợp các tiêu
chuẩn thiết kế.
Kiểm thử phát triển (Development Test)?

Kiểm thử chấp nhận (Quality Assurance
/Acceptance Test)?
Đầu vào của kiểm thử ?

Sản phẩm của kiểm thử ?
SOFTWARE TESTING REQUIREMENTS

SOFTWARE
“detect the differences” SPECIFICATION
(IEEE Std 829-1983)
“show the presence of errors”

(Dijkstra’s law)
Quy trình kiểm thử

 Lập kế hoạch:
• Phạm vi – Phương pháp – Nguồn lực – Lịch trình;
 Bố trí nhân viên

 Thiết kế ca kiểm thử (test case)
 Thực hiện kiểm thử
 Đánh giá phần mềm
Các nguyên lý cơ bản của kiểm thử

 Khách quan
 Ngẫu nhiên
 “Người sử dụng kém”
 “Kẻ phá hoại”
 Nghịch lý thuốc trừ sâu
 Chứng minh sự hiện diện của lỗi
 Cho rằng phần mềm không có lỗi là một sai lầm
 Kiểm thử càng sơm càng tốt
 Kiểm thử toàn diện là không thể
 Kiểm thử phụ thuộc vào ngữ cảnh
 Lỗi thường được phân bố tập trung (Pareto: 80/20)
“Phá vỡ thay vì xây dựng”

Có hai loại kiểm thử cơ bản
 Kiểm thử tĩnh (Static Testing): Kiểm thử KHÔNG
thực thi mã nguồn
• Rà soát, đánh giá (Review): Informal Review – Technical Review
– Walkthrough – Inspection;
 Kiểm thử động (Dynamic): Kiểm thử CÓ thực thi

mã nguồn
Kiểm thử tĩnh
“Formal Review” tuân theo một quy trình

 Lên kế hoạch – Planning
 Bắt đầu - Kick-off
 Chuẩn bị - Preparation
 Họp đánh giá - Review meeting
 Làm lại – Rework
 Theo dõi - Follow-up.
* Lưu ý phần xác định Entry Check/Exit Criteaia
trong pha Planning!
Kiểm thử động
 Thiết kế các ca kiểm thử và dữ liệu thử là

điều quan trọng nhất!
Có hai nhóm kỹ thuật thiết kế cơ bản
 Kỹ thuật kiểm thử chức năng (Kỹ thuật kiểm thử
hộp đen)
 Kỹ thuật kiểm thử cấu trúc (Kỹ thuật kiểm thử
hộp trắng/hộp gương)
Và Kỹ thuật kiểm thử hộp xám!
 Nhắc lại về “V&V”

Verification (Xác minh)
. "Are we building the product right”.
Validation (Thẩm định)
. "Are we building the right product”.
 Kỹ thuật kiểm thử nào thường được sử dụng

trong Xác minh và Thẩm định?
Thiết kế các ca kiểm thử
KỸ THUẬT KIỂM THỬ CHỨC NĂNG
Kỹ thuật kiểm thử chức năng
 Kiểm thử viên xem phần mềm như là một

hộp đen:
 Không quan tâm đến cấu trúc và hành vi bên
trong phần mềm
 Chỉ quan tâm đến các “hoạt động bề ngoài” của
phần mềm
 Kiểm thử chức năng nhằm cố gắng tìm ra

các LỖI sau:
 Chức năng THIẾU hoặc KHÔNG ĐÚNG
 Lỗi giao diện
 Lỗi cấu trúc dữ liệu
 Lỗi truy cập CSDL bên ngoài
 Lỗi thi hành
 Lỗi khởi tạo/kết thúc
…
 Đoán lỗi
 Phân hoạch tương đương
 Kiểm thử giá trị biên
 Kỹ thuật đồ thị nhân quả
 Kỹ thuật phân tích trạng thái
 Kỹ thuật phân tích tổ hợp
Kỹ thuật đoán lỗi
 Không có quy tắc chung;

 Dựa vào kỹ năng và trực giác;
 Dựa vào tài liệu đặc tả chức năng và phi
chức năng;
Kỹ thuật đoán lỗi
Tập trung vào những lỗi điển hình:

 Thiếu/Thừa chức năng;
 Chia cho 0;
 Nhấn nút “Thực hiện” mà không cần bất cứ thao tác nào?
 Nhập liệu sai cấu trúc;
 Sửa/Xóa dữ liệu mà không có xác nhận lại;
 Ô nhập mật khẩu không được mã hóa;
 ......
Phân hoạch tương đương
Việc kiểm thử tất các đầu vào của PM là KHÔNG
THỂ
Avr. 4 menus
3 options / menu
system has Average: 10 fields / screen

20 screens 2 types input / field
(date as Jan 3 or 3/1)
(number as integer or decimal)
Around 100 possible values
Total for 'exhaustive' testing:
20 x 4 x 3 x 10 x 2 x 100 = 480,000 tests
If 1 second per test, 8000 mins, 133 hrs, 17.7 days
(not counting finger trouble, faults or retest)
10 secs = 34 wks, 1 min = 4 yrs, 10 min = 40 yrs
Do đó, nên giới hạn một tập con tất cả các trường
hợp đầu vào có thể có
Mục đích: lựa chọn một tập con đúng
 Có xác suất cao nhất phát hiện hầu hết các lỗi
 Tập con được chọn cần thỏa mãn 2 tính

chất:
 Mỗi trường hợp kiểm thử nên gồm nhiều điều
kiện đầu vào khác nhau có thể để giảm thiểu
tổng số các trường hợp cần thiết.
 Các miền đầu vào của một chương trình thành
được phân hoạch thành một số xác định các
lớp tương đương, sao cho có thể giả định hợp
lý rằng việc kiểm thử một giá trị đại diện của
mỗi lớp là tương đương với việc kiểm thử một
giá trị bất kỳ trong cùng lớp đó
 Thiết kế DL thử bằng phân hoạch tương

đương theo 2 bước như sau:
 Phân hoạch các miền đầu vào/ra thành các lớp
tương đương;
 Phân tích các điều kiện kiểm thử tương ứng
mỗi lớp;
 Thiết kế các trường hợp kiểm thử đại diện cho
mỗi lớp.
 Phương pháp phân hoạch:

 Trường hợp các biến (tham số) có ràng buộc
miền giá trị cụ thể?
• Có một biến?
• Có 2 biến?
• Có n>2 biến ?
 Trường hợp các biến (tham số) không có ràng
buộc miền giá trị cụ thể?
 Thiết kế DL thử bằng phân hoạch tương

đương
Valid Invalid
 Ví dụ 1: Xét chương trình đọc số nguyên có

giá trị hợp lệ trong đoạn 0..1000
Trong trường hợp này chúng ta có 3 phân
hoạch đầu vào:
 Phân hoạch hợp lệ (PHHL)
 Phân hoạch không hợp lệ DƯỚI PHHL
 Phân hoạch không hợp lệ TRÊN PHHL
 Ví dụ 1 (tt): Như vậy dữ liệu thử nào sau

đây có khả năng phát hiện lỗi cao hơn:
 -7, 396, 1800
 140, 1680, 360
 Ví dụ 2: Cho “Bài toán Tam giác” được đặc tả như

sau:
 Nhập vào 3 số nguyên từ bàn phím (chương trình đã kiểm
tra và đảm bảo đó là các số nguyên);
 Kiểm tra 3 số đó có phải là ba cạnh của một tam giác hay
không?
• Nếu không phải, thông báo ra màn hình “Không phải tam giác”!
• Nếu đúng: Kiểm tra và thông báo đó là
– “Tam giác thường”; hoặc
– Tam giác cân”; hoặc
– “Tam giác đều”.
Hãy sử dụng kỹ thuật PHTĐ để xây dựng tập các trường

hợp kiểm thử?
 Ví dụ 2: “Bài toán Tam giác”

 Phân hoạch tương đương cho Inputs:
Invalid Input Valid Input
(a,b,c đều là số nguyên dương)
+ Nhập lỗi (a|b|c + Không phải là 3 cạnh của 1 tam giác
không phải là số + Là 3 cạnh của tam giác thường
nguyên dương) + Là 3 cạnh của tam giác cân
+ Là 3 cạnh của tam giác đều
 Phân hoạch tương đương cho Outputs:

Invalid Output Valid Output
+ Thông báo lỗi … Thông báo:
+ “Không phải tam giác”
+ “Tam giác thường”
+ “Tam giác cân”
+ “Tam giác đều”

 Bước 2: Phân tích điều kiện kiểm thử
• Thông báo lỗi…:
a <= 0 || b <=0 || c <=0
• “Không phải tam giác”

a + b <= c || b + c <= a || a + c <= b
• “Tam giác đều”

a == b && b == c
“Tam giác cân”
(a == b && b != c) || (b == c && c != a) || (a == c && a != b)
• “Tam giác thường”

a != b && b != c && a != c

 Bước 2 (tt): Có thể chia nhỏ điều kiện kiểm thử tiếp
được hay không?
 Bước 3: Thiết kế các ca kiểm thử!
Bài tập (28/8/2020)
 Cho đặc tả bài toán Nextday như sau:

“Chương trình nhận vào 3 số nguyên lần lượt là Tháng (x/xx);Ngày
(y/yy); Năm (zzzz)” đại diện cho một ngày bất kỳ từ 1/1/1582 đến
12/31/3000 ; Đầu ra của chương trình là NGÀY KẾ TIẾP của ngày nói
trên.” Giả sử rằng các số nguyên nhập vào đã được kiểm tra tính hợp
lệ!
 YÊU CẦU:
1. Liệt kê các lớp tương đương cho đầu vào (Inputs) và đầu ra (Outputs);
2. Liệt kê các điều kiện kiểm thử cho
mỗi lớp tương đương;
3. Xây dựng tập các ca kiểm thử (TCs)
bằng kỹ thuật phân hoạch tương đương!
SINH VIÊN LÀM VÀ NỘP BÀI LÊN HỆ THỐNG
LMS.VKU.UDN.VN TRƯỚC KHI KẾT THÚC
BUỔI HỌC!
KỸ THUẬT KIỂM THỬ GIÁ TRỊ BIÊN
2. Kiểm thử giá trị biên
 Các điều kiện

biên là tình
trạng trực
tiếp ở phía
trên và dưới
của các lớp
tương đương
đầu vào và
lớp tương
đương đầu ra.
Kiểm thử giá trị biên
 Việc phân tích các giá trị biên khác với phân
hoạch tương đương theo hai điểm:
 Từ mỗi lớp tương đương, phân hoạch tương
đương sẽ chọn phần tử bất kỳ làm phần tử đại
diện, trong khi việc phân tích giá trị biên sử
dụng một hoặc một số phần tử
 Không chỉ chú ý tập trung vào những điều kiện
đầu vào, các trường hợp kiểm thử cũng được
suy ra từ việc xem xét các kết quả ra
 Các THKT tốt nhất là tại các biên của các lớp
 Kiểm thử giá trị biên mở rộng phân hoạch
tương đương trên cơ sở tập trung vào các
biên của miền đầu vào hơn là các giá trị tiêu
biểu của nó;
 Chú ý cả trường hợp giá trị biên cho các kết
quả đầu ra!
max
max
Y
min X
min
 Ví dụ 1: Chức năng điều khiển một số bản

ghi bất kỳ trong khoảng từ 1 đến 16383 bản
ghi, sẽ có ba lớp tương đương:
 Lớp hợp lệ
 Lớp không hợp lệ DƯỚI
 Lớp không hợp lệ TRÊN
 Ví dụ(tt): Khi đó, các THKT có thể là:

 Trường hợp kiểm thử 1: 0 bản ghi, là thành viên của lớp
tương đương 2 và kề sát giá trị biên.
 Trường hợp kiểm thử 2: 1 bản ghi, là giá trị biên.
 Trường hợp kiểm thử 3: 2 bản ghi, kề sát giá trị biên.
 Trường hợp kiểm thử 4: 723 bản ghi, là thành phần của
lớp tương đương 1.
 Trường hợp kiểm thử 5: 16382 bản ghi, kề sát giá trị
biên.
 Trường hợp kiểm thử 6: 16383 bản ghi, chính là giá trị
biên.
 Trường hợp kiểm thử 7: 16384 bản ghi, thành phần của
lớp tương đương 3, kề sát giá trị biên.
 Ví dụ 4: Cho đặc tả bài toán Nextday như sau: “Chương

trình nhận vào 3 số nguyên lần lượt là Tháng (x/xx);Ngày
(y/yy); Năm (zzzz)” đại diện cho một ngày bất kỳ từ
1/1/1582 đến 12/31/3000 ; Đầu ra của chương trình là
NGÀY KẾ TIẾP của ngày nói trên.”
 Hãy xây dựng tập TCs bằng kỹ thuật kiểm thử giá trị biên! Giả sử
rằng các số nguyên nhập vào hợp lệ!
Kỹ thuật kiểm thử chức năng!
 Nhắc lại phương pháp phân hoạch tương đương và phân

tích giá trị biên!
PHƯƠNG PHÁP ĐỒ THỊ NHÂN QUẢ
3. Đồ thị nhân – quả
 Là một phương pháp thiết kế trường hợp kiểm thử

trên cơ sở đưa ra một sự mô tả súc tích các điều
kiện logic và các hành vi kèm theo
 Sử dụng mô hình quan hệ logic giữa nguyên nhân
và kết quả:
 Nguyên nhân: điều kiện (đúng hoặc sai) của một đầu
vào, hoặc kết hợp các đầu vào
 Kết quả: một biểu thức Bool biểu diễn một kết quả
tương ứng cho những thành phần vừa thực hiện
Đồ thị nhân – quả
 Các bước tạo đồ thị nhân – quả

 Tất cả các nguyên nhân (các đầu vào) và các kết quả
(các hoạt động hoặc các đầu ra) được liệt kê dựa trên
đặc tả và được định danh cho mỗi nhân - quả.
 Các quan hệ giữa các nguyên nhân (các đầu vào) và
các kết quả (các đầu ra) được biểu diễn trong đồ thị
làm rõ ràng các quan hệ logic.
 Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ
giữa nguyên nhân và kết quả. Dữ liệu kiểm thử được
sinh ra dựa trên các qui tắc trong các bảng này.
 Các ký hiệu quy ước:
 Các ký hiệu quy ước:
 Ví dụ 1: để tính thuế thu nhập, người ta có

mô tả sau:
- Người vô gia cư nộp 4% thuế thu nhập
- Người có nhà ở nộp thuế theo bảng sau:
Tổng thu nhập Thuế
<= 5.000.000 đồng 4%
> 5.000.000 đồng 6%
 Ví dụ 1(tt): Quan hệ giữa nguyên nhân (đầu

vào) và kết quả (đầu ra) như sau:
 Ví dụ 1(tt): Đồ thị biểu diễn quan hệ logic

rõ ràng giữa nguyên nhân-kết quả :
 Ví dụ 1(tt): Bảng quyết định:
 Từ đây xây dựng được các trường hợp kiểm thử:

Với ví dụ này có một trường hợp cho việc nộp thuế
6% và ba trường hợp kiểm thử cần cho việc nộp
thuế 4%.
 Tập các trường hợp kiểm thử ???????
 Ví dụ 2: Hãy sử dụng phương pháp đồ thị

nhân quả để xây dựng tập các trường hợp
kiểm thử cho “Bài toán tam giác”!
 Ví dụ 2:
 Ví dụ 2:
Loại
những
trường
hợp không
có trong
thực tế!
Đồ thị nhân quả
 Ví dụ 3: Cho đặc tả bài toán Nextday như sau: “Chương

trình nhận vào 3 số nguyên lần lượt là Tháng (x/xx);Ngày
(y/yy); Năm (zzzz)” đại diện cho một ngày bất kỳ từ
1/1/1582 đến 12/31/3000 ; Đầu ra của chương trình là
NGÀY KẾ TIẾP của ngày nói trên.”
 Hãy xây dựng tập TCs bằng kỹ thuật Bảng quyết định!
 Ví dụ 3:
Phân tích các nhóm tương đương
Months Days Year

• M1 – 31 day • D1 – 1 – 27 • Y1 – leap years
months • D2 – 28 • Y2 – non-leap
(except • D3 – 29 years
December)
• D4 – 30
• M2 – 30 day
• D5 - 31
months
• M3 – February
• M4 - December
 Ví dụ 3:
 Bài tập:
 Cho đặc tả như sau: Trường Đại học A xét học bổng cho sinh viên theo quy định
như sau:
 - Sinh viên có học lực Khá và:
 + Hạnh kiểm Khá: Đạt học bổng loại C
 + Hạnh kiểm Tốt: Đạt học bổng loại C
 - Sinh viên có học lực Giỏi và:
 + Hạnh kiểm Khá: Đạt học bổng loại B
 + Hạnh kiểm Tốt: Đạt học bổng loại A
 - Sinh viên có học lực Xuất sắc và:
 + Hạnh kiểm Khá: Đạt học bổng loại A
 + Hạnh kiểm Tốt: Đạt học bổng loại A*

 - Các trường hợp còn lại không được nhận học bổng.
 Hãy thiết kế các trường hợp kiểm thử cho đặc tả trên bằng phương pháp Bảng
quyết định: Liệt kê Nguyên nhân – Kết quả; Lập Bảng quyết định – Thiết kê các ca
kiểm thử.
PHƯƠNG PHÁP KIỂM THỬ TỔ HỢP
4. Phương pháp kiểm thử tổ hợp
 Kỹ thuật kiểm thử hộp đen

 Dựa vào phân tích tập hợp các tham số đầu vào;
 Dùng để xác định lỗi được gây ra bởi sự kết hợp
của các biến đầu vào (n-wise);
 Hiệu quả/Mức độ phát hiện lỗi cao;
Systematic analysis of
combinations
Test 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Bold yes yes yes yes no no no yes no no yes yes no yes no no
Italic no yes yes yes yes yes yes yes no no no no no no yes no
Underline no no yes yes no yes yes no yes yes yes yes no no no no
Strikethrough no no no yes no no yes yes no yes no yes yes yes yes no
Phương pháp kiểm thử tổ hợp
 Các bước thực hiện

 Phân vùng tương đương cho từng tham số đầu
vào;
 Xây dựng ma trận tham số;
 Điền và kiểm tra “giá trị” của từng tham số;
 Kiểm tra để đảm bảo từng n-”giá trị” đều được
bao phủ;
 Xây dựng tập các TCs;
 Ví dụ 1: Xây dựng tập các TCs cho đặc tả

sau
 Xây dựng một Form gồm có Checkbox, Radio Button,
Text Box và OK Button. Các ràng buộc được cho như
sau:
 List Box: Chứa các giá trị: - “”Hãy chọn
số”,1,2,3,4,5,6,7,8,9;
 Check Box : Checked hoặc Unchecked;
 Radio Button : ON hoặc OFF;
 Text Box - Bất kỳ giá trị số nguyên dương từ 1 đến 100;

“Ứng dụng đặt xe ô tô”
 Phần mềm cho phép chọn Mua hoặc Bán xe:
 Địa điểm giao dịch ở Đà Nẵng hoặc Quảng Nam;
 Số lượng đăng ký cho phép từ 1 đến 100;
 Có 03 loại xe để lựa chọn: BMW; Lexus; Audi;
 Thanh toán có thể bằng Chuyển khoản hoặc Tiền mặt;
 Có thể Không chọn hoặc Chọn 1 trong 4 gói bảo hiểm
BH1; BH2;BH3 và BHCC;

“Ứng dụng đặt xe ô tô”
GIAO DỊCH XE Ô TÔ Mua Bán

ĐỊA ĐIỂM Đà Nẵng Quảng Nam
SỐ LƯỢNG
LOẠI XE BMW LEXUS AUDI

THANH TOÁN Tiền mặt Chuyển khoản
BẢO HIỂM
OK
PHƯƠNG PHÁP DỰA VÀO CHUYỂN ĐỔI
TRẠNG THÁI
5. Chuyển đổi trạng thái
 State Transition Testing

 Phân tích các trạng thái/sự kiện của bài toán;
 Phân tích các điều kiện để kích hoạt các trạng thái/sự
kiện đó;
 Sử dụng khi bài toán có các trạng thái/sự kiện xuất hiện
có thứ tự và có các mối liên hệ với nhau; Và có một tập
hữu hạn các đầu vào (điều kiện kích hoạt trạng thái).
5. Chuyển đổi trạng thái
 State Transition Testing

 Thực hiện theo 5 bước:
• Liệt kê trạng thái và các điều kiện kích hoạt trạng thái;
• Vẽ Biểu đồ chuyển đổi trạng thái
• Lập Bảng chuyển đổi trạng thái;
• Lập kịch bản kiểm thử;
• Thiết kế các ca kiểm thử theo kịch bản;
“name” “name”
Điều kiện
Trạng thái
Chuyển đổi trạng thái
 Ví dụ: Cho đặc tả chương trình mô phỏng hoạt động

của một máy ATM với các chức năng chính sau:
 CN1: Hoạt động được bắt đầu khi user cho thẻ vào máy và nhập
đúng mã PIN để được cấp quyền truy cập; Việc nhập mã PIN cho
phép tối đa 3 lần; Nếu nhập sai mã PIN ở cả 3 lần, thẻ sẽ bị thu hồi
vào máy ATM và kết thúc hoạt động;
 CN2: Sau khi truy cập, user nhập số tiền cần rút; Hệ thống sẽ lần
lượt kiểm tra và xác nhận số tiền này có.nhỏ hơn tổng tiền còn lại
trong ATM và tổng tiền trong tài khoản hay không; Nếu không, ATM
yêu cầu nhập lại số tiền. Nếu đáp ứng, ATM sẽ hỏi user có muốn
nhận hóa đơn hay không? Nếu CÓ thì in hóa đơn, sau đó xuất tiền
và trả thẻ - Hoạt động kết thúc; Nếu KHÔNG thì xuất tiền và trả thẻ -
Hoạt động kế tthúc;
 Ví dụ: Thiết kê các ca kiểm thử cho CN1

 Bước 1:
 Trạng thái (States/Events/Actions):
• Start – Wait for PIN – 1st try – 2nd try – 3rd try - Access to
Account – Eat Card;
 Điều kiện (Conditions/Transitions):

• Insert card – Enter PIN – PIN not OK – PIN OK;

 Bước 2:

 Bước 3:
STATE/CONDITIONS CORRECT PIN INCORRECT PIN
S1- START – CARD - -
INSERTED – WAIT FOR
PIN
S2- 1st Enter the PIN S5 S3
S3- 2nd Enter the PIN S5 S4
S4- 3rd Enter the PIN S5 S6
S5 – Access Granted - -
S6 – Account Blocked - -

 Bước 4:
Number Description Expected Result
1 Enter the correct PIN for 1st time. Access Granted.
2 Enter the incorrect PIN for all 3 Card Eaten.

times.
3 Enter the incorrect PIN for 1st Access Granted.
time and correct PIN for 2nd time.
4 Enter the incorrect PIN for 1st Access Granted.

and 2nd time and correct PIN for
3rd time.

 Bước 5: Thiết kế các ca kiểm thử !!??
 Bài tập: Cho đặc tả chương trình mô phỏng hoạt

động của một máy ATM với các chức năng chính sau:
 Thiết kế các ca kiểm thử bằng phương pháp
chuyển đổi trạng thái cho chức năng CN2!
Thiết kế các ca kiểm thử
KỸ THUẬT KIỂM THỬ CẤU TRÚC
Kỹ thuật kiểm thử cấu trúc
 Kỹ thuật kiểm thử hộp trắng

 Kỹ thuật này dựa trên sự phân tích mã chương
trình hoặc một mô hình của mã chương trình để
xây dựng các phép thử theo các tiêu chuẩn bao
phủ.
 Kiểm thử cấu trúc bên trong của phần mềm, với
mục đích kiểm tra tất cả các câu lệnh và điều
kiện tồn tại trong phần mềm đó
Kỹ thuật kiểm thử cấu trúc
 Kỹ thuật kiểm thử hộp trắng (tt)

 Trong kỹ thuật này kiểm thử viên lấy dữ liệu thử
xuất phát từ việc kiểm tra logic của chương trình.
 Dựa vào phân tích “Đồ thị luồng điều khiển”!
Đồ thị luồng điều khiển (Control Flow Graph – CFG)
 là một đồ thị có hướng biểu diễn một chương trình,

trong đó:
 Mỗi nút (đỉnh): biểu diễn một lệnh tuần tự hoặc khối lệnh
tuần tự.
 Các cung: tương ứng với các quyết định luồng điều khiển
đi ra từ một đỉnh, một nút cấu trúc lựa chọn hay lệnh rẽ
nhánh. Một cung cần phải kết thúc tại một đỉnh, cho dù
đỉnh đó không biểu diễn cho một lệnh thủ tục nào.
 Một đỉnh vào và một đỉnh ra được thêm vào đồ thị để
biểu diễn cho điểm vào ra tương ứng của chương trình
Biểu thức các lộ trình
 Có 3 dạng đồ thị luồng điều khiển và biểu

thức lộ trình:
a
a
a
b c b
b
d
d c
Dạng tuần tự: ab Dạng tuần rẽ nhánh: a(c+b)d Dạng lặp: a(bc)*d
Đồ thị luồng điều khiển
 Ví dụ 1: Đồ thị luồng điều kiểm của đoạn

chương trình giải phương trình bậc nhất
if(a == 0) n0
if(b == 0)
cout<<”Vo so nghiem”; a =0
a
a !=0
else
b e
cout<<”Vo nghiem”; b =0 b !=0
nghiệm
else Vô số nghiệm c d Vô nghiệm
cout<<”x =”,-b/a;
ne
Đồ thị luồng điều khiển
 Ví dụ 2: Đồ thị luồng điều kiểm của đoạn

chương trình giải phương trình bậc hai biện
luận theo Delta ?
Lộ trình/đường đi (Path) trong CFG
 là đường đi xuất phát từ đỉnh vào đi qua các

đỉnh và cung khác và kết thúc tại đỉnh ra.
 Trong ví dụ đồ thị luồng điều khiển của ví dụ
1, có:
 [n0, a, b, c ,ne] : là một lộ trình
 [a, b, c, ne] : không phải là lộ trình.
Vậy trong đồ thị luồng điều khiển của ví dụ 2 trên
có tất cả bao nhiêu lộ trình ?
Biểu thức các lộ trình
 Đồ thị luồng điều khiển của ví dụ 1, có thể

được biểu diễn dưới dạng biểu thức sau
G1 = n0 a b c ne + n0 a b d ne + n0 a e ne
(Dấu ”+” đại diện toán tử ”hoặc”.)
 Đơn giản hóa biểu thức đường đi như sau:
G1 = n0 (a b c + a b d + a e) ne
Thiết kế các ca kiểm thử dựa vào CFGs
 Ví dụ tổng quát:
1
s:=0;
d:=0;
2
while (x<y) {
x:=x+3; 3
y:=y+2;
if (x+y < 100)
4
s:=s+x+y;
else 5 6
d:=d+x-y;
7
}
8
 Các tiêu chuẩn bao phủ dựa trên đồ thị luồng điều
khiển:
 Phủ tất cả các hàm (Function Covarage)
 Phủ tất cả các lệnh/đỉnh (Statement Coverage).
 Phủ tất cả các cung/quyết định (Branch/Decision
Coverage).
 Phủ tất cả các điều kiện (Condition Coverage ).
 Phủ tất cả các lộ trình (Path Coverage)
 Phủ tất cả các lộ trình cơ sở (Basic-Path Coverage)
 Ví dụ MỞ ĐẦU: THIẾT KẾ DỮ LIỆU THỬ

Giả sử có đoạn chương
THEO CÁC TIÊU CHUẨN
trình sau, hãy vẽ CFG: BAO PHỦ !!!
• Phủ tất cả các hàm: Gọi hàm
int foo (int x, int y) ‘foo’ ít nhất một lần!
{ • Phủ tất cả các đỉnh: foo(1,1);
int z = 0;
• Phủ tất cả các cung: foo(1,1)
if ((x > 0) && (y > 0))
và foo(0,1);
{
z = x; • Phủ tất cả các điều kiện:
} foo(1,1); foo(1,0) và foo(0,1).
return z;
}
Phủ tất cả các lệnh (đỉnh)
 Là phép thử cho phép thực thi tất cả các

lệnh.
 Mục đích của phủ tất cả các đỉnh là mỗi
lệnh phải được thực thi ít nhất một lần.
 Tiêu chuẩn này không phải khi nào cũng
thực hiện được.
 Ví dụ 2: Cho đoạn chương trình sau

cout<<”nhap gia tri: ”;
cin>>x;
if(x==0) x++;
g=1/x;
Hãy vẽ đồ thị luồng điều khiển ?

Ví dụ 2: Vậy lộ trình và dữ liệu thử tương

ứng nào phủ tất cả các đỉnh ?
n0
x=0 x!=0
x++ b c g=1/x
ne
Như vậy: Tiêu chuẩn phủ tất cả các đỉnh

thì không phủ các cung.
Phủ tất cả các cung
 Là phép thử cho phép phủ tất cả các cung

của đồ thị luồng điều khiển ít nhất một lần.
 Việc phủ tất cả các cung tương đương với
việc phủ tất các giá trị logic của mỗi đỉnh
quyết định.
 Phủ tất cả các cung sẽ kéo theo phủ tất cả
các đỉnh.
Phủ tất cả các cung
 Ví dụ 3:
n0
----
a
if(a < 2 && a==b)
a ≥ 2 hoặc b≠a a<2 và a=b
x= 2- a;
else b c x=2-a
x = a-2
x= a-2;
----- ne
 Nếu ta chọn tập giá trị thử của cặp (a, b) là: {(1,1) và
(3,3)} thì sẽ thỏa mãn tất cả các cung. Tuy nhiên, tập
dữ liệu không phủ tất cả các điều kiện.
Như vậy: Tiêu chuẩn phủ tất cả các cung

có thể không phủ tất cả các điều kiện.
Phủ tất cả các điều kiện
 Tiêu chuẩn phủ tất các điều kiện được

thỏa mãn khi và chỉ khi tiêu chuẩn phủ tất
cả các cung được thỏa mãn và mỗi biểu
thức điều kiện được thử với tất cả các giá
trị có thể.
 Ví dụ 4: Đồ thị luồng điều khiển ở ví dụ 3

được trình bày lại để phủ tất cả các điều
kiện như sau: n0
a a≥2
a<2
c
b
b≠a b=a
b=a b≠a
x=2-a d e x = a-2
ne
 Tập dữ liệu thử nào của cặp (a,b) phủ tất

cả các điều kiện ?
 VD: {(1, 1), (1, 0), (3, 0), (3,3)}.
 Lưu ý rằng, trong trường hợp biểu thức
điều kiện phức tạp sẽ dẫn đến sự “bùng
nổ” sự kết hợp.
 Ví dụ 5: Cho đoạn chương trình sau

cout<<”Nhap n: “;
cin>>n; n0
cout<<”Nhap m: “;
cin>>m;
i=n; s=0
a n>m
s=0;
while(n<=m){ n≤m
1/s
i=n; s=s+a[i]
b e
i++
s=s+a[i]; n++;
}
ne
cout<<1/s;
 Ví dụ 5: Lúc này, Tập dữ liệu thử bao phủ

các cung của đồ thị luồng điều khiển là:
a[1]=2, a[2]=3, n =1, m=2.
Tuy nhiên lỗi sẽ không được phát hiện

trong trường hợp n>m nghĩa là s= 0, =>
1/s (1/0) => lỗi.
Tiêu chuẩn phủ tất các cung và tiêu

chuẩn phủ tất cả các điều kiện không
thể dò tìm được lỗi trong trường hợp
vòng lặp không thực thi!
BÀI TẬP
 Vẽ CFG và thiết kế dữ liệu thử theo tiêu chuẩn phủ tất cả các điều kiện
internal static decial GetCommission(int locks, int stocks, int barrels)
{
decimal sales = GetTotalSales(locks, stocks, barrels);
decimal commission = 100;
if (CommissonIsDue(locks, stocks, barrels))
{
if (sales > 1800)
{
commission += (800 * Bonus15);
commission += ((sales - 1800m) * Bonus20);
}
else if (sales > 1000)
{
commission += ((sales - 1000m) * Bonus15);
}
else {
commission = (sales * standardCommission);
}
}
return commission.ToString();
}
Bài tập 2
 Cho đoạn chương trình sau: n0
if(n<=0)
n=1-n; n≤0
a
if(n%2==0) b
n>0
n=1-n
n=n/2;
else n=3*n +1;
c
n chẵn n lẻ
Hãy vẽ đồ thị luồng điều khiển. d e

n=n/2
Xác định các tập dữ liệu
thử theo tiêu chuẩn: f
- Phủ tất cả các đỉnh;

- Phủ tất cả các cung; ne
- Phủ tất cả các lộ trình.

Phủ tất cả các lộ trình
 Phủ tất cả lộ trình kéo theo phủ tất cả các

cung và phủ tất cả các đỉnh
Tiêu chuẩn phủ tất cả các lộ trình có thể
gặp những khó khăn khi số lộ trình là vô
hạn hoặc các lộ trình không thực thi
 Trong trường hợp, chương trình có số lần
lặp quá lớn thì chúng ta qui định rằng chỉ
thực hiện i lần lặp hữu hạn nào đó mà thôi.
Phủ tất cả các lộ trình
 Nhìn chung chúng ta thường quan tâm

đến hai lộ trình đó là:
 Lộ trình qua vòng lặp.
 Lộ trình không qua vòng lặp.
a
Lộ trình không qua vòng lặp: abd

b
Lộ trình qua vòng lặp: a(bc)*d
d c
Lộ trình cơ sở (Lộ trình độc lập)
 Là một lộ trình bất kỳ đưa ra ít nhất một

tập lệnh xử lý hoặc điều kiện mới ( tức là
phải đi qua một cung mới chưa từng được
một lộ trình nào trước đó đi qua).
Độ phức tạp Cyclomat
 Độ phức tạp Cyclomat cung cấp phép đo

định lượng độ phức tạp của chương trình .
 Độ phức tạp Cyclomat cho biết số lượng lộ
trình cơ sở -> giới hạn ít nhất số lộ trình
kiểm thử bắt buộc.
Các công thức tính độ phức tạp Cyclomat
 Công thức 1: V(G) = R, trong đó R là số

vùng của đồ thị luồng điều khiển G.
Công thức 2: V(G) = P + 1, trong đó P là
số đỉnh điều kiện có trong đồ thị luồng điều
khiển G.
Công thức 3: V(G) = E – N + 2, trong đó E
là số cung, N là số đỉnh của đồ thị luồng
điều khiển G.
Ví dụ
Cho lưu đồ thuật toán sau, hãy vẽ đồ thị

luồng điều khiển.
1
4
6
7 8 5
9
10
11
Ví dụ (tt): Có bao nhiêu lộ trình cơ sở ?
ĐỘ PHỨC TẠP CYCLOMAT: 1
- Công thức 1: V(G) = R = 4

2
- Công thức 2: V(G) = P +1 = 3 + 1 = 4

3
- Công thức 3: V(G) = E – N + 2
= 12 – 10 + 2 = 4
6 4,5
Sẽ có 4 lộ trình cơ sở:
 - Lộ trình 1: R2
R1
1-11
7
 - Lộ trình 2: 8
R3
(1-2-3-4-5-10)*-11
 - Lộ trình 3: 9
(1-2-3-6-8-9-10)*-11 10
 - Lộ trình 4:
R4
(1-2-3-6-7-9-10)*-11 11
Lộ trình (1-2-3-4-5-10)*
-(1-2-3-6-8-9-10)*-11 thì sao ?
Thiết kế các trường hợp kiểm thử theo LTCS
 Theo 4 bước:
- Bước 1: Vẽ đồ thị luồng điều khiển từ mã
nguồn hoặc mô hình của mã nguồn.
- Bước 2: Xác định độ phức tạp Cyclomat của
đồ thị luồng điều khiển
- Bước 3: Xác định các lộ trình cơ sở
- Bước 4: Phát sinh các trường hợp kiểm thử
có khả năng thực hiện trên mỗi lộ trình cơ
sở.
Phát sinh các trường hợp kiểm thử theo LTCS
 Chú ý:
- Dữ liệu kiểm thử được chọn sao cho các
điều kiện tại các nút điều kiện phải được
kiểm thử
- Mỗi trường hợp kiểm thử được thực thi và
được đối chiếu với kết quả mong đợi
Phát sinh các trường hợp kiểm thử theo LTCS
 Bài tập: Thiết kế các trường hợp kiểm thử

theo tiêu chuẩn phủ các lộ trình cơ sở cho
hàm tính trung bình cộng n số nguyên
(hàm có tên là average, được viết bằng
ngôn ngữ C), với n <= 100. Các số, là các
giá trị của mảng Arr, có giá trị thỏa mãn
min <= Arr[i] <= max. Đầu vào cho các số
được kết thúc bằng giá trị -999.
Hàm tính trung bình cộng các số
 Double average (int [] Arr, int min, int max)

 {
 HÃY XÁC
 int sum =0, count = 0, i=0; ĐỊNH
 double avg = 0.0; CÁC ĐIỂM
 while (Arr[i] != -999 && i <100) NÚT
 {
???
 if (Arr[i] >= min && Arr[i] <= max)
 {
 sum += Arr[i];
 count++;
 }
 i++;
 }
 if (count>0) avg = (double) sum/count;
 else avg = -999;
 return avg;
 }
Xác định các điểm nút
 Double average (int [] Arr, int min, int max)

 {
 /*1*/
 int sum =0, count = 0, i=0;
 double avg = 0.0;
 while (/*2*/Arr[i] != -999 && /*3*/i <100)
 {
 if (/*4*/Arr[i] >= min && /*5*/Arr[i] <= max)
 {
 /*6*/
 sum += Arr[i];
 count++;
 }
 /*7*/i++;
 }
 if (/*8*/count>0) /*9*/avg = (double) sum/count;
 else /*10*/avg = -999;
 /*11*/return avg;
 }
Bước 1: Vẽ đồ thị luồng điều khiển
R6 R4
3
R1
4
8
R2
9 10 5
R5
R3
7
6
11
Bước 2: Tính độ phức tạp Cyclomat
Công thức 1: V(G) = R = 6

Công thức 2: V(G) = P + 1 = 5 + 1 = 6
Công thức 3: V(G) = E – N + 2 = 17 –
13 + 2 = 6
Bước 3: Tìm tập các lộ trình cơ sở
Lộ trình 1:
Lộ trình 2: ?
Lộ trình 3: ?
Lộ trình 4: ?
Lộ trình 5: ?
Lộ trình 6: ?
Lưu ý
Các dấu (…) phía sau các lộ trình

4,5,6 có nghĩa là một lộ trình (hợp lệ)
bất kỳ đi qua các phần còn lại của cấu
trúc điều khiển đều có thể chấp nhận.
Quan trọng là việc chỉ ra các đỉnh điều
kiện
Trong ví dụ này, các đỉnh điều kiện là
2,3,4,5,8.
Bước 4: Thiết kế các trường hợp kiểm thử
Lộ trình 1: ???????

Lộ trình 2: ???????
Lộ trình 3: ???????
Lộ trình 4: ???????
Lộ trình 5: ???????
Lộ trình 6: ???????
VẤN ĐỀ ĐƯỢC ĐẶT RA
 Các trường hợp kiểm thử trên ĐỦ để

phát hiện các lỗi ngữ nghĩa chưa ?
Bài tập số 1
FindMean(float Mean, FILE ScoreFile)
{ SumOfScores = 0.0; NumberOfScores = 0; Mean = 0;
Read(ScoreFile, Score); /*Read in and sum the scores*/
while (! EOF(ScoreFile) {
if ( Score > 0.0 ) {
SumOfScores = SumOfScores + Score;
NumberOfScores++;
}
Read(ScoreFile, Score);
}
/* Compute the mean and print the result */
if (NumberOfScores > 0 ) {
Mean = SumOfScores/NumberOfScores;
printf("The mean score is %f \n", Mean);
} else
printf("No scores found in file\n");
}
Hãy thiết kế các ca kiểm thử phú lộ trình cơ sở dựa vào đặc tả thuật toán trên!
Chú ý đến các lộ trình “bất hợp lý”!
BÀI TẬP SỐ 2
void In_phantu(float A[],int gh)

{
int i,j,dem,dem_tong=0;
cout<<"\nCac phan tu khac nhau la";
for(i=0;i<gh-1;i++)
{
dem=0;
for(j=i+1;j<gh;j++)
if(A[i]==A[j]) dem++;
if(dem==0)
{
cout<<" "<<A[i];
dem_tong++;
}
}
if(dem_tong==0) cout<<"\nKhong co so nao ca";
else cout<<" "<<A[i];//vi i khong chay den cuoi cung nen ta phai in ra
phan tu cuoi cung //
return;
}
Hãy thiết kế các ca kiểm thử phủ các lộ trình cơ sở dựa vào đặc tả thuật toán trên!
CHƯƠNG 3.
CHIẾN LƯỢC KIỂM THỬ PHẦN MỀM
CHƯƠNG 3. CHIẾN LƯỢC KTPM
 Tổng quan về chiến lược kiểm thử phần

mềm
 Lập kế hoạch: Mục tiêu – Đối tượng – Kỹ thuật –
Tài nguyên – Lịch biểu; …
 Thiết kế ca kiểm thử: Tên – Mục đích – Dữ liệu
thử - Điều kiện – Đầu ra mong đợi;
 Thực thi chương trình;
 Phân tích kết quả và lập báo cáo (Thành công –
Thất bại – Chưa kết luận): Báo cáo lỗi – Báo cáo
kiểm thử;
Nguyên lý thiết kế và kiểm thử phần mềm

 Phải theo yêu cầu khách hàng
 Phải được lập kế hoạch trước
 Phải từ phạm vi nhỏ đến phạm vi rộng
 Không thể có kiểm thử toàn diện
 Độc lập
 Phải thiết kế cho “đầu vào” hợp lệ và không hợp
lệ
 Phải xác định “đầu ra” mong muốn
Nguyên lý thiết kế và kiểm thử phần mềm (tt)

 Phải kiểm tra kỹ kết quả kiểm thử
 Chương trình được kiểm thử có thực hiện Đủ và
Đúng?
 Tránh “bỏ qua”
 Không nên cho rằng “không có lỗi”
 Chú trọng tư duy và sáng tạo
 Phương pháp tiếp cận:

- Tại sao phải cần phải có chiến lược
KTPM ?
- Chiến lược là một “khuôn mẫu” cho
kiểm thử viên.
 Các đặc điểm của chiến lược KTPM:

- Bắt đầu tại mức module và phát triển
theo hướng tích hợp toàn bộ hệ thống
- Các kỹ thuật kiểm thử khác nhau có
thể được phối hợp với nhau.
- Kiểm thử và gỡ rối là các hoạt động
hoàn toàn khác nhau, nhưng gỡ rối phải
có mặt trong mọi chiến lược kiểm thử.
 Chiến lược KTPM phải đưa ra kiểm

thử:
- Ở mức “thấp nhất”
- Và ở mức “cao nhất”
 Các chiến lược không loại trừ lẫn
nhau
 Được lặp lại cho đến khi không còn
lỗi hoặc đến một mức độ chấp nhận
được.
 Kiểm thử và vòng đời phát triển PM

Các giai đoạn phát triển ứng dụng Kiểm thử
Phạm vi và mục tiêu QA/Kiểm thử chấp thuận
Yêu cầu chức năng/Thiết kế logic Kiểm thử hệ thống
Thiết kế vật lý Kiểm thử tích hợp
Đặc tả mô hình cấu trúc chương trình Kiểm thử đơn vị
Mã hoá module/chương trình

 Các mức kiểm thử:

- Đơn vị
- Tích hợp
- Hệ thống
- Chấp nhận
- Cài đặt
- Hồi quy
 Kiểm thử đơn vị:

- Một đơn vị là một thành phần PM nhỏ
nhất mà ta có thể kiểm thử được;
- Sử dụng thiên về kỹ thuật kiểm thử
hộp trắng;
- Thực hiện các đường dẫn độc lập (cơ
sở) trong cấu trúc điều khiển của module
để đảm bảo phủ hoàn toàn và phát hiện
lỗi tối đa;
 Kiểm thử đơn vị (tt):

- Hãy lý giải vì sao: “thời gian tốn cho
kiểm thử đơn vị sẽ được đền bù bằng việc
tiết kiệm rất nhiều thời gian và chi phí cho
việc kiểm thử ở các mức kiểm thử tiếp
theo” ?

- Mục đích của kiểm thử đơn vị là bảo
đảm thông tin được xử lý và xuất (khỏi
đơn vị) là chính xác;
- Tất cả các nhánh bên trong đơn vị
đều phải được kiểm thử để phát hiện
nhánh phát sinh lỗi.
Module
Giao diện module
Cấu trúc dữ liệu cục bộ
Điều kiện biên
Đường dẫn độc lập
Đường dẫn xử lý lỗi
Các trường hợp

kiểm thử
 Kiểm thử đơn vị

(tt):
- Vì mỗi module
không phải là một
chương trình độc
lập, nên phần mềm
điều khiển và/hoặc
nhánh cụt cần được
phát triển cho mỗi
kiểm thử đơn vị.
 Kiểm thử tích hợp (tt):

- Một kết hợp chúng lại với nhau và kiểm
thử sự giao tiếp giữa chúng.
- Nên tích hợp dần từng đơn vị.
- Kiểm thử tích hợp có 2 mục tiêu chính:
- Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị.
- Tích hợp các đơn vị đơn lẻ thành các hệ thống nhỏ (subsystem)
và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị
cho kiểm thử ở mức hệ thống (kiểm thử hệ thống).
 Kiểm thử tích hợp (tt):

- Có 2 chiến lược tích hợp thông dụng:
- Top-Down
- Bottom-Up
Ngoài ra có: Big-bang; Functional;
- Có 4 loại kiểm thử trong kiểm thử tích
hợp:
- Kiểm thử cấu trúc
- Kiểm thử chức năng
- Kiểm thử hiệu năng
- Kiểm thử khả năng chịu tải
Tích hợp từ trên xuống (Top-Down)
Trình tự:
 Bước 0: mô-đun a
 Bước 1: a + b
a
 Bước 2: a + b + c
 Bước 3: a + b + c + d b c
 etc.
d e f g
 Cần xây dựng/giả lập
các chức năng ở mức h i j k l m
dưới có liên quan trực tiếp
mà chưa được tích hợp (Stubs)!
n o
Tích hợp từ dưới lên (Bottom-Up)
Trình tự:
 Bước 0: mô-đun n
a
 Bước 1: n + i
 Bước 2: n + i + o b c
 Bước 3: n + i + o + d d e f g
 etc.
 Cần xây dựng/giả lập h i j k l m
các chức năng ở mức
Tên (Driver ) và dưới (Stubs) n o
có liên quan trực tiếp
mà chưa được tích hợp!
Ngoài ra, có thể tích hợp như sau
a a
b c b c
d e f g d e f g
h i j k l m h i j k l m
n o n o
 Kiểm thử hệ thống:

- Chú trọng các hành vi và lỗi trên toàn hệ
thống;
- Kiểm tra cả các hành vi chức năng của
phần mềm lẫn các yêu cầu về chất lượng
như độ tin cậy, tính tiện lợi khi sử dụng,
hiệu năng và bảo mật;
- Phát hiện lỗi giao tiếp với PM hoặc phần
cứng bên ngoài, chẳng hạn các lỗi "tắc
nghẽn" hoặc chiếm dụng bộ nhớ;
 Kiểm thử hệ thống (tt):

- Có nhiều loại kiểm thử khác nhau trong
khi kiểm thử hệ thống:
- Kiểm thử chức năng
- Kiểm thử hiệu năng
- Kiểm thử khả năng chịu tải
- Kiểm thử khả năng bảo mật
- Kiểm thử khả năng phục hồi
 Kiểm thử chấp nhận:

- Do khách hàng hoặc một bộ phận độc lập
thực hiện
- Các phép kiểm thử của kiểm thử hệ thống
và kiểm thử chấp nhận gần như tương tự,
nhưng bản chất và cách thức thực hiện lại
rất khác biệt;
- Kiểm thử Alpha và Kiểm thử Beta;
 Kiểm thử hồi quy:

- Kiểm thử hồi qui không phải là một chiến
lược kiểm thử !!!!
- Đơn thuần là kiểm thử lại PM sau khi có
một sự thay đổi xảy ra (sửa lỗi, hiệu
chỉnh, cải tiến,…);
- Kiểm thử hồi qui có thể thực hiện ở mọi
mức kiểm thử.
 HẾT CHƯƠNG 3
Chương 4. Xây dựng ứng dụng KTĐV
 Giới thiệu và hướng dẫn sử dụng

Junit !
Quy trình:
- Xác định chiến lược
- Phát sinh trường hợp kiểm thử
- Điều khiển kiểm thử
 Các loại giao diện cho bộ điều khiển

kiểm thử:
- KT hướng lô
- KT dựa trên luồng
- Kiểm thử GUI
- Kiểm thử nhúng
Chương 4. Xây dựng ứng dụng kiểm thử
 Phát biểu bài toán:

Giả sử có đặc tả bài toán sắp xếp như sau:
- P được gọi là chương trình sắp xếp.
- P nhận đầu vào là một số nguyên N (N >0) và
một mảng gồm K phần tử là các số nguyên, với
0 < K <= N
- Chương trình P sắp xếp mảng theo thứ tự tăng
dần và xuất ra mảng đã sắp xếp.
- P được xem là đúng với đặc tả nếu và chỉ nếu: với
mỗi đầu vào hợp lệ, đầu ra của P tương ứng như
đặc tả (xuất ra mảng đúng được sắp xếp theo thứ
tự tăng dần).
 Phát biểu bài toán (tt):

Một lập trình viên đã áp dụng thuật toán MergeSort để viết
chương trình giải bài toán trên. Đặc tả chi tiết thuật toán
MergeSort gồm các module như sau:
- Module Merge: Module này làm nhiệm vụ nối hai mảng
thành một mảng được sắp xếp.
- Module Split: Module này làm nhiệm vụ nhận vào một mảng
và chia thành 2 nữa, sau đó được gọi đệ quy cho mỗi nữa
nếu nó còn chứa hơn 1 phần tử. Sau đó, gọi module Merge
nối hai nữa kề sát.
- Module MergeSort: là module nhận các tham số khởi tạo từ
giao diện người dùng cuối cho chức năng sắp xếp, sau đó
gọi module Split với các tham số khởi tạo đó.
 Hãy thực hiện kiểm thử cho thuật

toán MergeSort trên:
- Chiến lược kiểm thử
- Phát sinh trường hợp kiểm thử
- Thiết kế TCs và thực hiện kiểm thử
-

Bai Giang KTKTPM CaoDang 2021

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bai Giang KTKTPM CaoDang 2021

Uploaded by

Copyright:

Available Formats

Bài giảng

Kỹ thuật kiểm thử phần mềm

GV: TS. Nguyễn Quang Vũ

The way to remove defects

*CISQ: Consortium for Information & Software Quality

NỘI DUNG CHÍNH

2 KỸ THUẬT KIỂM THỬ PHẦN MỀM

3 CHIẾN LƯỢC KIỂM THỬ PHẦN MỀM

4 XÂY DỰNG ỨNG DỤNG KIỂM THỬ ĐƠN VỊ

5 MỘT SỐ PHẦN MỀM KIỂM THỬ THÔNG DỤNG

Công nghệ phần mềm (CNPM) ?

Phân loại phần mềm: Cách 1

Phân loại phần mềm: Cách 2

Cách 3: Có thể phân loại PM theo sự định hướng

Thế nào là phần mềm được gọi là đúng ?

Định nghĩa LỖI PHẦN MỀM?

Về cơ bản, một phần mềm chất lượng là “phần

Error -> Fault -> Failure

… dẫn đến phần mềm

Vậy, lỗi phần mềm xảy ra ở công đoạn nào?

Lỗi phần mềm xảy

Lỗi phần mềm xuất hiện nhiều nhất ở công đoạn:

Nguyên nhân làm đặc tả nhiều lỗi ?

Ví dụ: Bài toán phân số

Ví dụ (tt): Xét đặc tả phép chia hai phân số

Sản phẩm phần mềm được được xây dựng thiếu,

Ví dụ: chương trình tính tiền lương được đặc

1 Lê Ngọc Anh 3,99 1.312.710 1.312.700 -10

2 Trần Thị Bình 2,34 769.860 769.900 +40

3 Nguyễn Văn Nam 4,32 1.421.280 1.421.300 +20

Đặc tả thiếu: Một yêu cầu đã được đặc tả

“Sửa một lỗi trước khi phát hành một phần

Đặc tả Thiết kế lập trình Kiểm thử Phát hành

* Nghiên cứu của Casper Jones

Mục đích của nhóm phát triển PM là có PM chất

Đảm bảo chất lượng phần mềm gồm nhiều nhiệm

Đảm bảo chất lượng phần mềm là một hoạt động

4 hoạt động cần tiến hành để THỨ LỖI

V&V – Verification and Validation ;

Sự khác nhau giữa xác minh và thẩm định:

Đóng vai trò tối quan trọng, quyết định đến

Kiểm thử phát triển (Development Test)?

Đầu vào của kiểm thử ?

SOFTWARE TESTING REQUIREMENTS

“show the presence of errors”

Quy trình kiểm thử

 Bố trí nhân viên

Các nguyên lý cơ bản của kiểm thử

“Phá vỡ thay vì xây dựng”

 Kiểm thử động (Dynamic): Kiểm thử CÓ thực thi

“Formal Review” tuân theo một quy trình

 Thiết kế các ca kiểm thử và dữ liệu thử là

 Nhắc lại về “V&V”

 Kỹ thuật kiểm thử nào thường được sử dụng

 Kiểm thử viên xem phần mềm như là một

 Kiểm thử chức năng nhằm cố gắng tìm ra

 Không có quy tắc chung;

Tập trung vào những lỗi điển hình:

system has Average: 10 fields / screen

 Tập con được chọn cần thỏa mãn 2 tính

 Thiết kế DL thử bằng phân hoạch tương

 Phương pháp phân hoạch:

 Thiết kế DL thử bằng phân hoạch tương