Xây dựng công cụ hỗ trợ sinh ca kiểm thử cặp

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ TỰ

XÂY DỰNG CÔNG CỤ HỖ TRỢ SINH CA KIỂM THỬ CẶP

Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60 48 01 03

LUẬN VĂN THẠC SĨ NGÀNH CÔNG NGHỆ THÔNG TIN

NGƢỜI HƢỚNG DẪN KHOA HỌC: TS.ĐẶNG ĐỨC HẠNH

Hà Nội – 2016


i

LỜI CẢM ƠN
Lời đầu tiên tôi xin gửi lời cảm ơn chân thành và sâu sắc đến TS.Đặng Đức
Hạnh và PGS.TS.Trƣơng Anh Hoàng đã định hƣớng đề tài, liên tục quan tâm, tạo điều
kiện thuận lợi trong suốt quá trình nghiên cứu và hoàn thành luận văn này.
Tôi xin đƣợc gửi lời cảm ơn đến các thầy, cô trong Bộ môn Công nghệ phần
mềm cũng nhƣ Khoa Công nghệ thông tin đã mang lại cho tôi những kiến thức vô
cùng quý giá và bổ ích trong quá trình theo học tại trƣờng.
Tôi cũng xin chân thành cảm ơn đến gia đình tôi, đã tạo điều kiện giúp đỡ để tôi
có thời gian và nghị lực hoàn thành luận văn này.
Cuối cùng, xin gửi lời cảm ơn chân thành nhất đến các bạn, các anh chị trong
trƣờng học và công ty Fpt software đã tạo điều kiện giúp đỡ tôi trong quá trình học tập

và thực hiện luận văn này.
Hà Nội, tháng 06 năm 2016

Học viên: Nguyễn Thị Tự


ii
LỜI CAM ĐOAN
Tôi xin cam đoan luận văn này là công trình nghiên cứu của cá nhân tôi dƣới sự
hƣớng dẫn của thầy TS.Đặng Đức Hạnh, trung thực và không sao chép của tác giả
khác. Trong toàn bộ nội dung nghiên cứu của luận văn, các vấn đề đƣợc trình bày đều
là những tìm hiểu và nghiên cứu của chính cá nhân tôi hoặc là đƣợc trích dẫn từ các
nguồn tài liệu có ghi tham khảo rõ ràng, hợp pháp. Nếu có vấn đề gì tôi xin hoàn toàn
chịu trách nhiệm.
Người viết cam đoan

Nguyễn Thị Tự


iii
MỤC LỤC
LỜI CẢM ƠN .......................................................................................................... i
LỜI CAM ĐOAN ................................................................................................... ii
MỤC LỤC .............................................................................................................iii
DANH SÁCH CÁC BẢNG KÝ HIỆU VÀ CHỮ VIẾT TẮT............................... v
DANH SÁCH CÁC BẢNG .................................................................................. vi
DANH SÁCH CÁC HÌNH ................................................................................... vii
MỞ ĐẦU ................................................................................................................ 1
Đặt vấn đề, định hƣớng nghiên cứu .................................................................... 1
CHƢƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM ................................ 2

1.1 Khái niệm kiểm thử phần mềm (Software Testing) .................................... 2
1.2 Một số thuật ngữ thƣờng dùng trong kiểm thử phần mềm ........................ 2
1.3 Quy trình kiểm thử phần mềm...................................................................... 5
1.3.1 Lập kế hoạch kiểm thử (Test plan) ...................................................... 6
1.3.2 Thiết kế kiểm thử (Test design) ........................................................... 7
1.3.3 Chuẩn bị dữ liệu (Implement test) ....................................................... 7
1.3.4 Thực hiện kiểm thử, ghi nhận kết quả và đánh giá kết quả ................. 8
1.3.5 Tổng hợp và báo cáo ............................................................................ 8
1.4 Các mức kiểm thử phần mềm ....................................................................... 8
1.4.1 Kiểm thử mức đơn vị (Unit Test) ........................................................ 9
1.4.2 Kiểm thử tích hợp (Integration Test) ................................................... 9
1.4.3 Kiểm thử mức hệ thống (System Test) ................................................ 9
1.4.4 Kiểm thử chấp nhận (Acceptance Test) ............................................... 9
1.4.5 Kiểm thử hồi quy (Regression Test) .................................................. 10
1.5 Một số chiến lƣợc kiểm thử ......................................................................... 10
1.5.1 Kiểm thử hộp trắng (White-box Testing) .......................................... 10
1.5.2 Kiểm thử hộp đen (Black-box Testing) ............................................. 11
1.6 Kiểm thử chức năng ..................................................................................... 11
1.6.1 Khái niệm kiểm thử chức năng .......................................................... 11
1.6.2 Phân lớp tƣơng đƣơng (Equivalence class partioning) ...................... 12
1.6.3 Phân tích giá trị biên (Boundary value analysis) ............................... 13
1.6.4 Bảng quyết định (Decision tables) ..................................................... 13
1.6.5 Kiểm thử ngẫu nhiên (Random testing) ............................................. 17
1.6.6 Đoán lỗi (Error guesing) .................................................................... 18
1.6.7 Phƣơng pháp phân vùng (Category partition (CPM)) ....................... 18
1.7 Kiểm thử tổ hợp (Combination testing) ..................................................... 19


iv
1.7.1 Vector kiểm thử (Test vector) ............................................................ 19

1.7.2 Kiểm thử tổ hợp [5] ........................................................................... 19
CHƢƠNG 2: KIỂM THỬ CẶP ĐÔI DỮ LIỆU (PAIRWISE TESTING) .......... 26
2.1 Tổng quan ...................................................................................................... 26
2.2 Kiểm thử cặp đôi dữ liệu (Parirwise testing) ............................................. 26
2.2.1 Mảng trực giao (Orthogonal array (Lrun(Leverfactors))) ....................... 27
2.2.2 Thứ tự tham số (In parameter order) ................................................. 31
2.3 Công cụ PICT (Pairwise Independent Combinatorial Testing) ............... 36
2.3.1 File đầu vào của PICT ....................................................................... 36
2.3.2 Cách thức sinh dữ liệu ca kiểm thử của PICT ................................... 39
2.3.3 Ƣu điểm của PICT ............................................................................. 40
2.3.4 Cài đặt và sử dụng PICT [9] .............................................................. 45
2.4 Ứng dụng của pairwise testing .................................................................... 46
2.5 Đánh giá hiệu quả của kỹ thuật pairwise. .................................................. 47
CHƢƠNG 3: XÂY DỰNG CÔNG CỤ SINH CA KIỂM THỬ TỰ ĐỘNG ...... 48
3.1 Ý tƣởng của bài toán .................................................................................... 48
3.2 Tìm hiểm về công cụ kiểm thử tự động trên nền web Selenium IDE. ..... 48
3.3 Phân tích bài toán ......................................................................................... 50
3.3.1 Vấn đề cần giải quyết......................................................................... 50
3.3.2 Cách thức giải quyết vấn đề. .............................................................. 51
3.3.3 Cách thức sinh ca kiểm thử của công cụ ........................................... 51
3. 4 Xây dựng công cụ sinh ca kiểm thử tự động ............................................. 57
3.5 Kết quả của công cụ: .................................................................................... 58
3.6 Môi trƣờng chạy công cụ sinh ca kiểm thử ................................................ 61
3.7 Ứng dụng công cụ vào thực tế. .................................................................... 62
3.8 Đánh giá ƣu nhƣợc điểm của công cụ ......................................................... 63
Tóm tắt kết quả làm đƣợc: ................................................................................ 65
Hƣớng nghiên cứu tiếp theo: ............................................................................. 65
DANH MỤC TÀI LIỆU THAM KHẢO. ............................................................ 66

v
DANH SÁCH CÁC BẢNG KÝ HIỆU VÀ CHỮ VIẾT TẮT
Requiment
Yêu cầu khách hàng
QTP
QuickTest Professional
Pairwise testing
Kiểm thử cặp đôi
Bug
Lỗi của phần mềm
Testcase
Ca kiểm thử
Test
Kiểm thử
Design
Thiết kế
EC
Lớp tƣơng đƣơng
IPO
Thứ tự tham số
Cover
Phủ
File
Tệp tin


vi
DANH SÁCH CÁC BẢNG
Bảng 1.1 Mẫu ca kiểm thử trong thực tế .............................................................. 2
Bảng 1.2 Ca kiểm thử tự động Selenium IDE dạng bảng .................................... 3

Bảng 1.3 Ca kiểm thử tự động Selenium IDE dạng mã nguồn ............................ 3
Bảng 1.4 Cấu trúc bảng quyết định .................................................................... 14
Bảng 1.5 Các biến trong chức năng privacy setting của skype ......................... 19
Bảng 1.6 Số ca kiểm thử hệ thống S cho kỹ thuật cặp 1 .................................... 21
Bảng 1.7 Số cặp đôi của hệ thống S ................................................................... 21
Bảng 1.8 Số ca kiểm thử hệ thống S cho kỹ thuật cặp đôi ............................... 21
Bảng 1.9 Số cặp 3 của hệ thống S ...................................................................... 22
Bảng 1.10 Số ca kiểm thử hệ thống S cho kỹ thuật cặp 3 .................................. 22
Bảng 1.11 Số ca kiểm thử chức năng setting privacy cho kỹ thuật cặp1 .......... 22
Bảng 1.12 Số ca kiểm thử chức năng setting privacy cho kỹ thuật cặp đôi. ..... 23
Bảng 1.13 Số ca kiểm thử chức năng setting privacy cho kỹ thuật cặp 3 ......... 25
Bảng 2.1 Tổng số ca kiểm thử theo phƣơng pháp N cặp .................................. 26
Bảng 2.2 Tổng số ca kiểm thử theo phƣơng pháp pairwise. .............................. 27
Bảng 2.3 Thành phần file đầu vào của PICT ..................................................... 36
Bảng 3.1Định nghĩa phần tử html trên cột đầu tiên trong Selenium IDE .......... 50
Bảng 3.2Bảng mô tả các thành phần trên biểu mẫu nhập liệu ........................... 50
Bảng 3.3Định nghĩa các phẩn tử trong file sinh ra ca kiểm thử ........................ 59


vii
DANH SÁCH CÁC HÌNH
Hình 1.1 Quy trình kiểm thử phần mềm .............................................................. 5
Hình 1.2 4 mức độ kiểm thử phần mềm cơ bản ................................................... 8
Hình 1.3 Màn hình setting privacy của skype. ................................................... 20
Hình 2.1 Bảng lựa chọn mảng trực giao tùy theo số lƣợng lever và factors. .... 28
Hình 2.2 Mảng trực giao L4(23) ........................................................................ 29
Hình 2.3 Mảng trực giao L9 (34). ...................................................................... 29
Hình 2.4Thuật toán IPO. .................................................................................... 32
Hình 2.5 Thuật toán Horizontal growth ............................................................. 32
Hình 2.6 Thuật toán vertical .............................................................................. 33

Hình 2.7 Thuật toán sinh ca kiểm thử của PICT ................................................ 40
Hình 2.8 Cấu trúc tƣơng tác tham số đƣợc tạo ra của PICT. ............................. 41
Hình 2.9 Tính toán những loại trừ độc lập trong PICT...................................... 43
Hình 2.10 Ràng buộc 3 biến............................................................................... 43
Hình 2.11 File chạy thử nghiệm PICT ............................................................... 45
Hình 2.12 Kết quả PICT hiển thị trên command .............................................. 45
Hình 2.13 Kết quả PICT khi xuất thành file. .................................................... 45
Hình 3.1 Giao diện Selenium IDE ..................................................................... 48
Hình 3.2 Cấu trúc chính của một ca kiểm thử Selenium IDE............................ 49
Hình 3.3 Giao diện công cụ sinh ca kiểm thử tự động....................................... 57
Hình 3.4 Kết quả hiển thị tại listview khi thêm các phần tử html ..................... 59
Hình 3.5 Kết quả chạy file sinh ra bởi công cụ trên Selenium IDE. ................. 60
Hình 3.6 Kết quả hiển thị trên list view ............................................................ 60
Hình 3.7 Kết quả số file sinh ra và nội dung file ............................................... 61
Hình 3.8 Hình ảnh tại listview ........................................................................... 62
Hình 3.9File sinh ra đƣợc chạy thành công trên Selenium IDE ........................ 63
Hình 3.10 Số ca kiểm thử sinh ra với dữ liệu đầu vào. .................................... 63


1

MỞ ĐẦU
Đặt vấn đề, định hƣớng nghiên cứu
Trong những năm gần đây, chúng ta thấy rằng ngành công nghệ phần mềm
phát triển ngày càng vƣợt bậc ở nhiều lĩnh vực.Đặc biệt tính ứng dụng cao bắt
buộc cho phần mềm phải có một chất lƣợng nhất định.Việc phát triển phần mềm
chỉ tập trung vào khâu thiết kế, lập trình là chƣa đủ.Chúng ta cần tập trung cao vào
cả khâu kiểm thử và đặc biệt hơn đó chính là kiểm thử chức năng
(function).Nhƣng kiểm thử nhƣ thế nào để có thể tiết kiệm chi phí, tối ƣu nhất
nguồn lực mà vẫn đảm bảo chất lƣợng.

Một giải pháp hợp lý cho các vấn đề đặt ra ở trên đó là áp dụng các kỹ thuật
kiểm thử tối ƣu và các công cụ kiểm thử tự động cho các phần mềm.Trong thực tế
đã có rất nhiều công cụ kiểm thử tự động ví dụ nhƣ Selenium IDE, QTP, nhƣng
nhìn trung chúng lại khá gò bó và mang nhiều nhƣợc điểm.
Luận văn đƣợc thực hiện dựa trên ý tƣởng từ nhu cầu thực tế trong công việc
và kiến thức đƣợc học để từ đó đƣa ra cách thực hiện.
Luận văn gồm 3 chƣơng có các nội dung nhƣ sau:
Chƣơng 1: Tổng quan về kiểm thử phần mềm.
Chƣơng này nêu hệ thống cơ sở lý thuyết về kiểm thử nhƣ khái niệm về kiểm
thử, quy trình kiểm thử, các mức kiểm thử, các chiến lƣợc kiểm thử và đặc biệt là
các kỹ thuật trong kiểm thử chức năng và kiểm thử tổ hợp.
Chƣơng 2: Kỹ thuật kiểm thử cặp đôi dữ liệu (Pairwise testing).
Trong chƣơng này, tôi sẽ giới thiệu về kiểm thử cặp dữ liệu.Đây là một kỹ
thuật trong kiểm thử chức năng.Trong đó luận văn sẽ nghiên cứu 2 kỹ thuật chính là
mảng trực giao (OA) và thứ tự tham số (IPO). Ngoài ra phần này sẽ giới thiệu về
công cụ sinh ra bộ dữ liệu kiểm thử theo phƣơng pháp cặp đôi dữ liệu là PICT.
Chƣơng 3: Xây dựng công cụ hỗ trợ sinh ca kiểm thử theo kỹ thuật cặp.
Trong chƣơng này, tôi sẽ xây dựng một công cụ cho phép sinh ca kiểm thử
dạng Selenium IDE và kết hợp kỹ thuật cặp dữ liệu trong đó.Nó cho phép sinh một
lúc nhiêu ca kiểm thử.


2
CHƢƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1 Khái niệm kiểm thử phần mềm (Software Testing)
Kiểm thử phần mềm là quá trình thực thi một chƣơng trình hay là một đơn vị
(Module) của chƣơng trình nhằm đánh giá chất lƣợng của sản phẩm phần mềm.
Kiểm thử là một khâu mấu chốt và là bƣớc phát triển cuối cùng để đảm bảo chất
lƣợng phần mềm. Có thể nói đơn giản là kiểm thử là kiểm tra xem phần mềm có
chạy đúng thiết kế (design) và đặc tả (specification) của nó hay không.

Mục đích của kiểm thử phần mềm là: Tìm lỗi sai (bug), giải quyết bug và
đƣa ra những đánh giá, chứng nhận về chất lƣợng phần mềm.
1.2 Một số thuật ngữ thƣờng dùng trong kiểm thử phần mềm
Bug: Là một khiếm khuyết trong một thành phần hoặc hệ thống mà nó có
thể làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng yêu cầu
của nó, có thể là lỗi giao diện, lỗi chức năng, lỗi nghiệm vụ. Ví dụ nhƣ thông báo
sai hoặc định nghĩa dữ liệu không đúng, hoặc là một nghiệm vụ bị sai so với yêu
cầu…
Các mức độ của bug: Đơn giản (Cosmetic), bình thƣờng (Medium), nguy
hiểm (Serious), gây chết hệ thống (Fatal).
Testcase: Đƣợc dịch ra trong tiếng việt là ca kiểm thử. Nó mô tả dữ liệu dầu
vào, một số hành động hoặc sự kiện, và một kết quả mong đợi để xác định chức
năng của một ứng dụng phần mềm hoạt động đúng hay không. Một testcase có thể
có các phần đặc thù khác nhƣ mã, mục đích, điều kiện kiểm tra (conditon), các yêu
cầu dữ liệu đầu vào, các bƣớc thực hiện, và các kết quả mong đợi.
Có thể nóirằng testcase là một tình huống kiểm tra, đƣợc thiết kế để kiểm tra
một đối tƣợng có thỏa mãn yêu cầu đặt ra hay không. Testcase có thể có một số
dạng nhƣ bảng 1.1, bảng 1.2, bảng 1.3...
Ví dụ một mẫu testcase:
Stt
10

Kiểm thử
Điều kiện
Bƣớc thực hiện
Mong muốn Kết quả viên
Ngày test
Ghi chú
Tại màn hình 1. Click vào tab 4.
OK

Tunt3
2014/02/26 Versio
ternant
[Menu]
n: 5.5
．Display
2.
Click
vào
[Data
．[Report
message:[設
settings]
option]
定が保存さ
3. Tại màn hình [Data
=Enable
れました。/S
settings]
．[Call
etting was
．Tại
recording
saved.]
[レポート保存日数]
option]
．Đăng ký
=Enable
chọn
value

=3
thành công
．Tại
[保存日数]
chọn
value
=3
4. Click button [ OK]
để đăng ký

Bảng 1.1Mẫu ca kiểm thử trong thực tế
.


3
Ví dụ testcase tự động với công cụ là Selenium IDE:
Testcase1
open

/

type

id=email



type

id=pass

minhanh2929

clickAndWait

id=u_0_w

Bảng 1.2Ca kiểm thử tự động Selenium IDE dạng bảng

<html><head>
<link rel="selenium.base" href=" />
<title>New Test</title>
</head>
<body><table cellpadding="1" cellspacing="1" border="1">
<thead>
<tr><td rowspan="1" colspan="3">New Test</td></tr>
</thead><tbody>
<tr>
<td>open</td>
<td></td>
<td></td>
</tr>
<tr>
<td>type</td>
<td>id=email</td>
<td></td>
</tr>
<tr>
<td>type</td>
<td>id=pass</td>

<td>minhanh2929</td>
</tr><tr>
<td>clickAndWait</td>
<td>id=u_0_m</td>
<td></td>
</tr>
</tbody></table>
</body>
</html>
Bảng 1.3Ca kiểm thử tự động Selenium IDE dạng mã nguồn html


4
OK/NG/NA: OK/NG là những kết quả của testcase, còn NA là không thể
thực hiện đƣợc.
Build và Release Version:Build và Release Version đều đƣợc dùng để chỉ
một phiên bản của phần mềm. Tuy nhiên, ý nghĩa và trƣờng hợp sử dụng thì khác
nhau.
Build: Thƣờng đƣợc dùng để chỉ 1 version phần mềm trong quá trình phát triển tại
dự án. Các bản build liên tiếp nhau thƣờng có một khác biệt nhỏ. Nó có thể giải
quyết thêm một bug, thay đổi một yêu cầu nhỏ.
Release Version: Đƣợc dùng để chỉ một bản build. Tuy nhiên, bản build này sẽ
đƣợc gởi đến cho khách hàng kiểm thử chấp nhận. Những thay đổi giữa các Release
Version liên tiếp nhau thƣờng là khá lớn. Phải có nhiều build đƣợc viết và kiểm thử
tại nhóm dự án thì mới có một Release Version.
Fix bug: Là quá trình giải quyết một bug, đƣợc thực hiện bởi lập trình viên.
Việc đầu tiên của fix bug là tìm hiểu đƣa ra đƣợc nguyên nhân gây lỗi, rồi đến xác
định lỗi và thực hiện vá lỗi.

5
1.3 Quy trình kiểm thử phần mềm
Đây là quy trình kiểm thử phần mềm đƣợc áp dụng nhiều công ty hiện nay
trong đó có fpt software.

Hình 1.1Quy trình kiểm thử phần mềm


6
Sau đây chúng ta sẽ đi mô tả các bƣớc quan trọng trong quy trình này:
1.3.1 Lập kế hoạch kiểm thử (Test plan)
a. Mục đích: Xác định nguồn nhân lực tham gia, lập lịch biểu, phạm vikiểm thử,
chiến lƣợc kiểm thử, quy trình và công cụ sử dụng
b. Bƣớc thực hiện:
 Xác định các yêu cầu (requirement) cho việc kiêm thử gồm:
 Nghiên cứu tài liệu yêu cầu (requirements) của khách hàng, tiêu chí
chấp nhận, tài liệu đặc tả, tài liệu thiết kế (design) và những ràng
buộc của khác hàng đối với sản phẩm.
 Xác định xem là những cái gì sẽ đƣợc kiểm thử, hay chính xác là
phạm vikiểm thử, ví dụ nhƣ kiểm thử ở giai đoạn nào, các kiểu kiểm
thử, các module phải kiểm thử.
 Xác định phạm vikiểm thử (Hạn chế của công việc, effort, lịch trình
công việc, thời gian kiểm thử hồi quy).
 Xem xét và thống nhất các yêu cầu cho việc kiểm thử.
 Đánh giá rủi ro và mức độ ƣu tiên
 Đánh giá rủi ro đối với vấn đề liên quan
 Xác định và thiết lập mức độ ƣu tiên cho các các chức năng cơ bản
dựa trên mức độ nghiêm trọng của vấn đề, mong muốn của ngƣời
dùng, mức độ quan trọng, tần xuất sử dụng đối với từng chức năng.
 Xây dựng chiến lƣợc kiểm thử:

 Phƣơng pháp kiểm thử, giai đoạn kiểm thử (kiểm thử đơn vị, kiểm
thử tích hợp, kiểm thử hệ thống, kiểm thử chấp thuận).
 Tiêu chí chấp thuận, và đánh giá việc kiểm thử. Tiêu chí này dựa trên
một số tài liêu nhƣ thiết kế, báo cáo kiểm thử…
 Xem xét các trƣờng hợp đặc biệt, nguồn nhân lực và điều kiện cơ sở
vật chất để thực hiện kiểm thử.
 Xác định nguồn nhân lực và môi trƣờng bao gồm:
 Con ngƣời: Số lƣợng và năng lực, kinh nghiệm.
 Môi trƣờng kiểm thử: Bao gồm phần cứng và phần mềm.
 Công cụ sử dụng.
 Tất cả các loại dữ liệu kiểm thử(test data).
 Xác định lịch trình kiểm thử.
 Dự đoán đƣợc thời gian cho kiểm thử (effort test).
 Tạo lịch trình kiểm thử và những mốc (milestones) quan trọng.
 Tạo kế hoạch kiểm thử.
 Xem xét và thống nhất lập kế hoạch kiểm thử.


7
1.3.2 Thiết kế kiểm thử(Test design)
a. Mục đích Thiết kế cho việc kiểm thử.
b. Bƣớc thực hiện:
 Nghiên cứu tài liệu đặc tả, tài liệu kế hoạch.
 Xác định Pass/Fail cho các trƣờng hợp trong tài liệu thiết kế kiểm thử…
 Xác định môi trƣờng cho mỗi chức năng.
.
 Liệt kê điểm cần kiểm thử, kịch bản kiểm thử(test viewpoint, test
suile)mỗi chức năng dựa trên tài liệu yêu câu.., quy trình kinh doanh,
những hiểu biết và các câu hỏi, trả lời giữa các thành viên trong dự án và
khách hàng...

 Xem lạitài liệu thiết kế, các điểm cần thực hiện (TestDesign/Test
viewpoint), đánh giá độ bao phủ (coverage) của thiết kế kiểm thử.
 Chấp thuận và hoàn thành thiết kế kiểm thử.
1.3.3 Chuẩn bị dữ liệu(Implement test)
a. Mục đích: Chuẩn bị cho việc test
b. Bƣớc thực hiện
 Tạo ca kiểm thử:
 Phân tích quy trình doanh nghiệp (business process).
 Phân tích sơ đồ use case, tài liệu thiết kế, tài liệu yêu cầu, tài liệu đặc
tả, kế hoạch kiểm thử...
 Xác định ca kiểm thử: Điều kiện, bƣớc (kịch bản), kết quả mong
muốn.
 Xác định dữ liêu kiểm thử.
 Xác định cấu trúc thủ tục kiểm thử
 Phân tích ca kiểm thử.
 Xác định thủ tục
 Cấu trúc thủ tục kiểm thử: Xác định mỗi quan hệ và trình tự thực
hiện của thủ tục kiểm thử, điều kiện bắt đầu và kết thúc, mối quan hệ
của thủ tục kiểm thửvà ca kiểm thử.
 Xác định thủ tục: Hƣớng dẫn cách thực hiện, giá trị dữ liệu nhập vào, kết
quả mong đợi.
Tạo test script cho việc thực hiện ca kiểm thử.
 Chuẩn bị dữ liệu kiểm thử gồm cả dữ liệu cũ và mới.
 Chuẩn bị môi trƣờng bao gồm cơ sở vật chất, thiết bị, công cụ và các điều
kiện yêu cầu khác.
 Xem xét lại ca kiểm thử và kiểm tra lại các công cụ.
 Xem xét lại môi trƣờng kiểm thử, các điều kiện tiền đề và dữ liệu.


8

1.3.4 Thực hiện kiểm thử, ghi nhận kết quả và đánh giá kết quả
a.Mục đích:Thực thi kiểm thử và đánh giá kết quả kiểm thử.
b. Bƣớc thực hiện.
 Tiếp nhận sản phẩm nhƣ tài liệu, gói phần mềm.
 Cài đặt môi trƣờng và chƣơng trình cần kiểm thử.
 Thực hiện kiểm thử dựa trên thiết kế hoặc các kịch bản kiểm thử, ca kiểm
thử. Ghi lại các dữ liệu thực tế liên quan đến môi trƣờng, dữ liệu, hoạt
động và kết quả.
 Thực hiện phân tích nguyên nhân khi kết quả khác với mong muốn. Phối
hợp với bên phát triển để điều tra bug nhƣ lấy log.Đánh dấu phần thay đổi
để thay đổi thiết kế, yêu cầu, tài liệu đặc tả, tài liệu yêu cầu hoặc môi
trƣờng.
 Theo dõi việc khắc phục lỗi.
1.3.5 Tổng hợp và báo cáo
a. Mục đích: Tóm tắt lại kết quả và đánh giá hoạt động kiểm thử
b. Bƣớc thực hiện
 Tổng hợp các ca kiểm thửlỗi, xác định mong muốn trong từng trƣờng hợp.
 Tạo báo cáo kiểm thử.
 Kiểm tra báo cáo kiểm thử.
 Tinh chỉnh và bảo trì tài liệu.
 Xác định sơ bộ hệ thống sau khi tích hợp có thỏa mãn yêu cầu đặt ra không.
1.4 Các mức kiểm thử phần mềm
Kiểm thử phần mềm không hoạt động một cách gò bó mà đƣợc thực hiện
một cách linh hoạt.Điều đó phụ thuộc vào phần mềm đó phất triển theo mô hình nào
và giai đoạn phát triển trong dự án phần mềm[3].Ngoài ra nó còn phụ thuộc rất lớn
vào yêu cầu trong hợp đồng đặt hàng sản phẩm.

Hình 1.24 mức độ kiểm thử phần mềm cơ bản

9
1.4.1 Kiểm thử mức đơn vị (Unit Test)
Unit test là công đoạn thực thi kiểm thử sớm nhất trong chu trình kiểm thử
phần mềm. Đối tƣợng của unit test là những đơn vị có kích thƣớc nhỏ. Hoạt động
trong một chu trình đơn giản. Đôi khi nó cũng chỉ là một hàm, hoặc một chức năng.
Đặc điểm của unit test:
 Dễ tổ chức, kiểm tra, ghi nhận và phân tích kết quả.
 Thƣờng do lập trình viên thực hiện.
 Nếu phát hiện lỗi thì dễ dàng phát hiện nguyên nhân, và dễ sửa chữa.
Kỹ thuật đƣợc đặc biệt hay dùng với unit test là đồ tị dòng điều khiển (CFG) và đồ
thị dòng dữ liệu (DFG). Và công cụ đƣợc sử dụng nhiều nhất cho Unit test là Junit
và Nunit.
1.4.2 Kiểm thử tích hợp (Integration Test)
Integration Test là kiểm thử các thành phần của một ứng dụng khi tích hợp
vào hệ thống.Chúng đƣợc coi nhƣ một ứng dụng đã hoàn thành.Integration Test kết
hợp các đơn vị riêng lẻ lại với nhau và kiểm tra sự giao tiếp giữa chúng.Và đƣợc
thực hiện bởi nhân viên kiểm thử phần mềm.
Integration Test có hai mục tiêu chính:
 Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị Unit.
 Tích hợp các đơn vị Unit đơ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 tra ở mức hệ thống (System Test).
Một số loại kiểm thử quan trọng trong Integration Test: Kiểm thử cấu trúc, kiểm thử
chức năng, kiểm tra hiệu năng.
1.4.3 Kiểm thử mức hệ thống (System Test)
System Test là kiểm thử toàn bộ hệ thống sau khi tích hợp có thỏa mãn yêu
cầu đặt ra hay không.System Test bắt đầu khi tất cả các bộ phận của phần mềm đã
đƣợc tích hợp thành công.Thông thƣờng loại kiểm tra này tốn rất nhiều công sức và
thời gian.Ở mức độ độ này, nhân viên kiểm thử cũng tìm kiếm các lỗi nhƣng trọng
tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến

chất lƣợng của toàn hệ thống.
Thƣờng đƣợc thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm
phát triển dự án.
Một số loại kiểm thử trong System Test gồm: Kiểm thử chức năng, kiểm thử hiệu
năng, kiểm thử bảo mật và kiểm thử khả năng phục hồi.
1.4.4 Kiểm thử chấp nhận (Acceptance Test)
Acceptance Test thƣờng có ý nghĩa là ngƣời dùng cuối kiểm thử chƣơng
trình xem sản phẩm phần mềm có đáp ứng đầy đủ những chức năng mà họ cần hoặc
có đúng với quy trình công việc mà họ vẫn làm hay không? Tính dễ sử dụng, chức
năng, khả năng chịu tải.... Đây là mức quyết định xem sản phẩm đã thực sự hoàn


10
thiện để chuyển tới ngƣời sử dụng hay không.Chính là bƣớc kiểm thử sau giai đoạn
realease.
Gắn liền với giai đoạn Acceptance Test thƣờng là tài liệu đi kèm, phổ biến
nhƣ hƣớng dẫn cài đặt, tài liệu hƣớng dẫn sử dụng, mã nguồn, báo cáo kết quả,
…Tất cả phải đƣợc cập nhật và kiểm tra chặt chẽ.
1.4.5 Kiểm thử hồi quy (Regression Test)
Kiểm thử hồi quy là kiểm tra lại phần mềm sau khi có một sự thay đổi xảy ra,
để đảm bảo phiên bản phần mềm mới thực hiện tốt các chức năng nhƣ phiên bản cũ
và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã làm việc
tốt.Regression Test có thể thực hiện tại mọi mức kiểm thử khác.
1.5 Một số chiến lƣợc kiểm thử
1.5.1 Kiểm thử hộp trắng (White-box Testing)
Kiểm thử hộp trắng là chiến lƣợc kiểm thử dựa vào các cấu trúc, thuật toán
bên trong của chƣơng trình.Tức là dựa vào mã nguồn.
Kỹ thuật này thƣờng dùng tại mức kiểm thử đơn vị. Và do lập trình viên thực hiện.
Nó giúp tối ƣu hóa mã nguồn.
Kiểm thử hộp trắng có 3 kỹ thuật cơ bản là rà soát (review code) và các kỹ thuật

kiểm thử động là đồ thị dòng điều khiển (control flow graph) và đồ thị dòng dữ liệu
(data flow graph).
a. Kỹ thuật rà soát: Các kỹ thuật rà soát có thể chia ra làm các bƣớc sau:
 Rà soát không chính thức (informal review): Thực hiện bằng cách đọc các
tài liệu liên quan và đƣa ra các ghi chú, chƣa cần phải phát hiện lỗi.
 Phản biện chéo (peer review): Việc rà soát đƣợc thực hiện bởi đội ngũ lập
trình dự án phần mềm, mọi ngƣời cùng tham gia thảo luận để đƣa ra thống
nhất chung về vấn đề kỹ thuật cho phù hợp với dự án. Cả đội sẽ cùng nhau
rà soát mã nguồn, tìm lỗi và đƣa ra cách giải quyết.
 Thông qua (walkthrough): Ngƣời viết các mã nguồn, tài liệu đặc tả, thiết
kế, .. sẽ giải thích từng bƣớc trƣớc toàn đội dự án nhằm đạt đƣợc sự hiểu
rõ, đồng thuận, sau đó nhận các phản hồi góp ý của thành viên trong đội
dự án và đƣa ra thay đổi hợp lý.
 Thanh tra (inspection): Các thành viên quan trọng trong đội dự án sẽ tham
gia họp, một danh sách các vấn đề cần rà soát sẽ đƣợc lập và đƣa ra để
phát hiện lỗi và sữa chữa. Thanh tra khác thông qua ở chỗ ngƣời trình bày
mã nguồn, tài liệu đặc tả, thiết kế không phải là ngƣời trực tiếp viết mà là
một ngƣời khác, điều này khiến ngƣời trình bày phải thật sự hiểu về những
gì sẽ giải thích.
b. Đồ thì dòng điều khiển (Control flow graph)[1]:
Ý tƣởng của kiểm thử dòng điều khiển chính là việc xây dựng một đồ thị
dòng điều khiển và thiết kế các ca kiểm thử dựa trên các đƣờng đi của đồ thị đó.


11
Đồ thị dòng điều khiển là một đồ thị có hƣớng gồm các đỉnh tƣơng ứng với
các câu lệnh/nhóm câu lệnh và các cạnh là các dòng điều khiển giữa các câu
lệnh/nhóm câu lệnh.Nếu i và j là các đỉnh của đồ thị dòng điều khiển thì tồn tại một
cạnh từ i đến j nếu lệnh tƣơng ứng với j có thể đƣợc thực hiện ngay sau lệnh tƣơng
ứng với i.

c. Đồ thị dòng dữ liệu (Data flow graph)[1]:
Ý tƣởng của kiểm thử dòng dữ liệu chính là xây dựng một đồ thị dòng dữ
liệu và thiết kế các ca kiểm thử dựa trên đƣờng đi của đồ thị đó.
Đồ thị dòng dữ liệu xem một đơn vị chƣơng trình gồm các đƣờng đi tƣơng
ứng với các dòng dữ liệu nơi mà các biến đƣợc khai báo, đƣợc gán giá trị, đƣợc sử
dụng để tính toán và trả lại kết quả mong muốn của đơn vị chƣơng trình ứng với
đƣờng đi này. Với mỗi đƣờng đi, chúng ta sẽ sinh một ca kiểm thử để kiểm tra tính
đúng đắn của nó.
1.5.2 Kiểm thử hộp đen (Black-box Testing)
Kỹ thuật kiểm thử hộp đen xem chƣơng trình nhƣ là một hộp đen . Đƣợc thực
hiện bằng cách cho chạy chƣơng trình và quan sát để tìm ra những hành vi, những
hoạt động mong muốn và không mong muốn.
Phƣơng pháp kiểm thử hộp đen tập trung nhiều nhất vào các yêu cầu chức
năng của phần mềm.Ngoài ra có thể có các yêu cầu khác nhƣ khả năng chịu tải, load
test.
Về đặc điểm kiểm thử chức năng của chƣơng trình, luận văn đƣa ra riêng một
phần trong mục (1.6)dƣới đây.
1.6Kiểm thử chức năng
1.6.1 Khái niệm kiểm thử chức năng
Khái niệm chức năng:Theo Howden, một chức năng đƣợc xác định là một
tập của cặp (Xi, Yi), trong đó Xi là một vector của biến nhập, và Yi là một vector
của biến xuất. Trong kiểm thử chức năng, một chƣơng tình P đƣợc xem nhƣ là một
chức năng khi truyền vector nhập Xi vào một vector xuất Yi, giả sử Yi = P(Xi)
Ví dụ1: Cho Y1 = sqrt(X1)
Ở đây P là là chức năng tính căn bậc 2, căn bậc 2 (Y1)của số nguyên không âm(X1),
kết quả đƣợc gán cho (Y1).
=>Tóm lại ta có thể thấy: Một chức năng gồm 3 phần tử chính là đầu vào, đầu ra và
thành phần biến đổi thông tin của đầu vào cho đầu ra. Trong 2 phần tử đầu vào và
đầu ra ta chú ý tới 4 điểm chính nhƣ sau:
 Nhận dạng: Nhận dạng biến đầu vào và đầu ra của chƣơng trình và miền

dữ liệu của chúng
 Tính toán: Kết quả mong muốn cho mỗi sự lựa chọn giá trị đầu vào.
 Xác định giá trị đầu vào, giá trị là nguyên nhân cho chƣơng trình để đƣa ra
đƣợc sự lựa chọn cho đầu ra.


12
Khái niệm kiểm thử chức năng: Kiểm thử chức năng là hoạt động kiểm tra
chƣơng trình dựa trên những tài liệu đặc tả, yêu cầu của sản phầm.Xem hệ thống
phần mềm có hoạt động đúng với những yêu cầu, tài liệu đặc tả hay không.Thực
chất những tài liệu nhƣ đặc tả, yêu cầu chính là những file mô tả đầu vào, đầu ra của
nhiều chức năng.Kiểm thử chức năng bao gồm một tập hợp các kỹ thuật giúp cho
việc kiểm thử chức năng của hệ thống phần mềm.
Trong phần này tôi xin giới thiệu mốt số kỹ thuật đƣợc áp dụng phổ biến nhƣ phân
lớp tƣơng đƣơng, phân tích giá trị biên, bảng quyết đinh[7, pp.222-259]…
1.6.2Phân lớp tƣơng đƣơng (Equivalence class partioning)
a. Giới thiệu:
Một miền đầu vào (input domain) có thể quá lớn để tất cả các phần tử có thể
đƣợc sử dụng khi kiểm thử. Tuy nhiên miền này có thể đƣợc phân chia thành những
miền con hữu hạn để lựa chọn. Mỗi miền con này đƣợc gọi là 1 lớp tƣơng đƣơng
(EC) và đóng vai trò nhƣ là một tài nguyên chứa ít nhất một giá trị để kiểm tra.
Đây là phƣơng pháp điển hình để giảm bớt tổng số lƣợng ca kiểm thử, để hạn
chếtập của các ca kiểm thử có thể kiểm tra đƣợc, mà vẫn có thể cover đƣợc số
lƣợng lớn requirements.
EC là một tập hợp(nhóm) của các đầu vào đƣợc xử lý tƣơng tự nhƣ nhau, hành vi
tƣơng tự và cùng có kết quả mong muốn (expected result).
b. Nguyên tắc phân vùng tƣơng đƣơng cho một số trƣờng hợp
 Điều kiện đầu vào (input conditon)chỉ rõ là một dẫy [a,b].
 Xác định 1 lớp tƣơng đƣơng hợp lệ(valid) cho a<=x<=b;
 Và 2 lớp tƣơng đƣơng không hợp lệ(invalid) là x<a và X>b;

 Điều kiện đầu vào xác định là tập của các giá trị.
 Tạo lớp tƣơng đƣơng (EC) cho mỗi phần tử của tập. Và một lớp
tƣơng đƣơng (EC) cho một thành phầnkhông hợp lệ.
 Điều kiện đầu vào xác đinh cho mỗi giá trị riêng lẻ.
 Tạo lớp tƣơng đƣơng cho mỗi đầu vào đúng.
Ví dụ: Nếu input từ một menu, thì tạo ra một EC cho mỗi menu item.
 Điều kiện đầu vào xác định số của nhiều giá trị hợp lệ(say N).
 Tạo ra 1 lớp tƣơng đƣơng cho số đúng, và 2 lớp tƣơng đƣơngkhông
hợp lệ là giá trị 0 và giá trị lớn hơn N.
Ví dụ: Nếu một chƣơng trình nhận 100 số tự nhiên để sắp xếp, thì tạo ra
3 lớp tƣơng đƣơng là EC valid nhập 100 số.EC invalid: Là không
nhập số nào, và nhập lớn hơn 100 số.
 Điều kiện đầu vào xác định là một giá trị ―must-be‖.
Ký tự đầu tiên của password phải là một ký số.Thì chúng ta sẽ yêu cầu
tạo ra 2 lớp tƣơng đƣơng.Một là giá trị đúng ký tự đầu tiên của
password phải là ký tự số.Một giá trị sai là ký tự đầu tiên không là một
số.


13
 Phân chia lớp tƣơng đƣơng, nếu những phần tử trong phân vùng đã đƣợc
chia của lớp tƣơng đƣơng đƣợc xử lý một cách khác nhau thì chia cắt lớp
tƣơng đƣơng đó thành các lớp tƣơng đƣơng nhỏ hơn.
Sau khi xác định phân lớp tƣơng đƣơng thì chúng ta sẽ xác định các ca kiểm thử.
c. Các bƣớc xác định ca kiểm thử:
Bƣớc 1: Gán một số duy nhất cho mỗi lớp tƣơng đƣơng.
Bƣớc 2: Đối với mỗi lớp tƣơng đƣơnghợp lệ (EC valid), chƣa cover bởi 1 ca
kiểm thử, viết ca kiểm thử mới cover càng nhiều lớp tƣơng đƣơng càng tốt.
Bƣớc 3: Đối với mỗi lớp tƣơng đƣơng không hợp lệ (ECinvalid) chƣa cover
bởi 1 ca kiểm thử, viết 1 ca kiểm thử mới cover một và chỉ một lớp tƣơng

đƣơng đó.
Ví dụ: Xem xét phần mềm tính toán thuế dựa theo AGI(Adjusted Gross Income):
If AGI is between $1 and $29,500, the tax due is 22% of AGI.
If AGI is between $29,501 and $58,500, the tax due is 27% of AGI.
If AGI is between $58,501 and $100 billion, the tax due is 36% of AGI
EC1 valid AGI = [$1; $29,500] TC=20000$
EC2 invalid: AGI <$1;- TC= -10000$
EC3 valid: AGI =[$29,501; $58,500] TC= 30000$
EC4 valid AGI [$58,501;$100 billion]  TC= 60000$
EC5 invalid AGI>$100 billion  TC= 150bilion$
1.6.3Phân tích giá trị biên (Boundary value analysis)
a. Giới thiệu: Phân tích giá trị biên là là kỹ thuật phân tích điều kiện biên cho mỗi
lớp tƣơng đƣơng để tạo ra ca kiểm thử.
Điều kiện biên là giá trị trực tiếp ở phía trên, dƣới của các lơp tƣơng đƣơng đầu vào
và đầu ra.
b. Một số quy tắc áp dụng cho phân tích giá trị biên:
 Nếu điều kiện đầu vào xác định là một khoảng giá trị giữa a và b, thì biên
sẽ là a,b và các giá trị sát trên và dƣới của a và b.
 Nếu một điều kiện đầu vào xác định một số giá trị, các ca kiểm thử sẽ
đƣợc tạo để kiểm thử giá trị cực đại, cực tiểu, các giá trị sát trên, sát dƣới
giá trị cực đại, cực tiểu.
 Áp dụng cả đối với điều kiện đầu ra.
 Nếu cấu trúc dữ liệu chƣơng trình bên trong quy định các biên, thì tạo ca
kiểm thử từ các biên của nó.
1.6.4Bảng quyết định (Decision tables)
a. Khái niệm:
Là một kỹ thuật đơn giản nhƣng mạnh để mô tả một hệ thống phức tạp. Nó
kiểm tra đƣợc sự phối hợp giữa các điều kiện đầu vào.

14
Bảng quyết định bao gồm một tập các điều kiện conditions, và một tập các hệ
quả effects(result) đƣợc sắp xếp vào một cột bên trái của bảng, theo nhƣ biểu mẫu
bảng 1.4:
Conditions

Values

C1
C2
C3
Effects
E1
E2
E3
Checksum

Y, N,Y, N,Y, N,-

R1
Y
Y
Y

R2
Y
Y
N

Rules or Combinations

R3
R4
R5
R6
Y
Y
N
N
N
N
Y
Y
Y
N
Y
N

R8
N
N
N

1

8

2
1
2
1

2
11
3
1
1
1
1
1
Bảng 1.4Cấu trúc bảng quyết định

R7
N
N
Y

2
1
1

1
1

1

Ở cột thứ hai, bên cạnh các condition, chúng ta có một số giá trị có thể có
của nó làYes(Y), No(N) và gạch ngang--. Ở bên phải của cột values, chúng ta có
một tập của các luật(rules). Mỗi sự tổ hợp của 3 condition tồn tại một số rule từ
tập{R1,R2,R3, ...,R8}
Trong mỗi một rules, các giá trị của condition có thể là yes, no, hoặc là gạch
ngang và bao gồm một số danh sách effects liên quan{E1,E2,E3. Mỗi một rule trong

bảng quyết định đƣợc thể hiện thành một ca kiểm thử.
b. Các bƣớc để triển khai ca kiểm thửkhi áp dụng kỹ thuật bảng quyết định:
 Bƣớc 1: Xác định các condition và các effects cho mỗi đơn vị riêng biệt.
 Một condition là một trạng thái đầu vào riêng biệt hay là một lớp tƣơng
đƣơng EC của điều kiện đầu vào. Một effect là một trạng thái đầu ra. Xác
định mối quan hệ logic giữa những condition và effect.ết,
 Bƣớc 2:Liệt kê tât cả các condition và effects vào trong biểu mẫu (form)
của bảng quyết định. Viết xuống những giá trị cho các condition có thể
mang. Đặt condition quan trọng nhất ở trên, và condition mang nhiều giá
trị ở cuối cùng.
 nguyêvà kết quả đƣ
 Bƣớc 3: Tính toán số lƣợng có thể kết hợp. Nó bằng với số lƣợng của các
giá trị khác biệt làm tăng thêm nguồn lực của số lƣợng các conditions.
Nếu tất cả condition chỉ đơn giản là Y va N thì ta sẽ có 2number of condition.
Nếu 1 condition có 3 giá trị và 3 condition còn lại có 2 giá trị thì ta sẽ có
31 x 23 = 24.
 Bƣớc 4: Hãy điền vào các columns với tất cả sự kết hợp có thể. Mỗi
columns tƣơng ứng với một sự kết hợp của các value. Mỗi một
row(condition) làm nhƣ sau:


15
Xác định rõ những yếu tố lặp lại(RF): Chia số còn lại của kết hợp bằng số
của các giá trị có thể cho mỗi condition đó.
Viết số lần RF giá trị đầu tiên, rồi số lần RF tiếp… cho đến khi row
không trống.
Tiếp đến các dòng sau, …
 Bƣớc 5: Giảm sự kết hợp(rules). Tìm kiếm sự phối hợp không khác biệt
và thay bằng ‗—‗, vị trí dấu gạch ngang và nối column nơi mà những
column giống hệt nhau. Trong khi làm điều này, hãy đảm bảo rằng mọi

ảnh hƣởng là nhƣ nhau.
 Bƣớc 6: Kiểm tra sự bao phủ của điều kiện đầu vào sự kết hợp các rules.
Cho mỗi một column tính sự kết hợp mà nó đại điện. Một dấu gạch ngang
đại diện cho nhiều sự kết hợp của nhiều điền kiện. Làm tăng lên nhiều lần
cho mỗi dấu gạch ngang xuống một column. Thêm vào tổng số và so sánh
với bƣớc 3. Nó có thể giống nhau.
 Bƣớc 7: Thêm những effects vào column của bảng quyết định. Đọc những
column bằng mỗi column và xác định ảnh hƣởng. Nếu nhiều hơn một
effect có thể xẩy ra sự kết hợp duy nhât, sau đó chỉ định một số thứ tự các
effect. Do đó xác định thứ tự mà những tác động cần đƣợc thực hiện.
Kiểm tra sự thống nhất của bảng quyết định.
 Bƣớc 8: Những column trong bảng quyết định sẽ đƣợc chuyển đổi thành
những ca kiểm thử.
c. Một số trƣờng hợp nên áp dụng bảng quyết định để mang lại hiệu quả:
 Requirements đƣợc dễ dàng ánh xạ (mapped) tới bảng quyết định.
 Kết quả bảng quyết định không phải quá lớn.Ta có thể tách một bảng
quyết định lớn thành nhiều bảng quyết định nhỏ hơn.
 Mỗi cột trong bảng quyết định không phụ thuộc vào các column
khác.
d. Ví dụ áp dụng:
Bài toán áp dụng:Xem xét thủ tục trả lƣơng. Nhà tƣ vấn làm việc hơn 40h một
tuần đƣợc trả lƣơng theo tỷ lệ số giờ làm việc của họ cho 40h đầu tiên và gấp 2 lần
tỷ lệ số giờ làm việc cho những giờ thiếp theo. Nhà tƣ vấn làm việc làm việc ít hơn
40h mỗi tuần, đƣợc trả lƣơng cho giờ họ đã làm ở mức tỷ lệ số giờ của họ và đƣa ra
báo cáo vắng mặt. Nhân viên lâu dài làm việc ít hơn 40h một tuần đƣợc trả theo
mức lƣơng của họ và đƣa ra báo cáo vắng mặt. Nhân viên lâu năm làm việc hơn 40h
mỗi tuần đƣợc trả lƣơng theo mức lƣơng của họ.
Giải quyết bài toán:Chúng ta cần mô tả thủ tục trả lƣơng trên sử dụng kỹ thuật
bảng quyết định để tạo ra ca kiểm thử.
 Bƣớc 1: Xác định các condition và effects:

 C1: lao động thƣờng xuyên
 C2: làm việc <40h


16
 C3: làm việc =40h
 C4: Làm việc >40h
 E1: Trả lƣơng.
 E2: Đƣa ra báo cáo vắng mặt
 E3: Trả lƣơng theo giờ
 E4: Trả lƣơng gấp 2 lần theo giờ
 Bƣớc 2: Tạo ra bảng quyết định

 Bƣớc 3 Tổng số của sự kết hợp là 16: 24.
 Bƣớc 4: Xác định RF (repeating factors)
 RF của row1: 16/2 = 8;
 RF của row2: 8/2 = 4;
 RF của row1: 4/2 = 2;
 RF của row1: 2/2 = 1;
 Vì vậy dòng đầu tiên sẽ đƣợc điền với 8Y, 8N.
 Dòng thứ 2 sẽ đƣợc điền là 4Y,4N.
 Dòng thứ 3 sẽ điền là 2Y,2N
 Dòng thứ 4 sẽ điền là 1Y,1N…
 Bƣớc 5: Giảm các rules.
 Nếu là lao động cố định và làm viêc nhỏ hơn 40h thì C3 và C4 không
cần quan tâm.
Thay vì vậy, ta sẽ giảm rule 1,2,3,4 thành các rules đơn mà không
ảnh hƣởng đến effects.
 Nếu là lao động cố định và làm việc < 40h là N, thì C3 và C4 không
phải là vấn đề, thay vì dó rules 5,6,7,8 có thể giảm bớt thành rule đơn

– Không chú ý tới.
 Nếu C1 là N và C2 là Y thì C3 và C4 không quan trọng. Thay vì đó,
9,10,11,12 sẽ đƣợc giảm thành rule đơn mà không ảnh hƣởng đến
effect.


17
 Nếu C1 và C2 là N, nhƣng C3 là Y thì rule 13,14 có thể đƣợc giảm
thành rule đơn.
 Rules 15 và 16 thì vẫn vây.
Sau khi giảm ta có bảng sau:

Checksum cho columns 1,2,3,4,5, 6 là 4,4,2,1,1. Tổng của checksum là16,
giống với giá trị đƣợc tính ở bƣớc 3.

 Bƣớc 7: Trong bƣớc này, những effect đƣợc thêm vào cho mỗi
column(rule). Column đầu tiên, nếu C1 và C2 đƣợc thỏa mãn, thì nhân viên
phải đƣợc trả lƣơng vàcó báo cáo vắng mặt đƣa ra. Thay vì đó E1 và E2
đƣợc đánh dấu. Nhƣ là 1 và 2 của bảng quyết định.
Ví dụ áp dụng thực tế: Chức năng 002 tại Cphone…
1.6.5 Kiểm thử ngẫu nhiên (Random testing)
Là kỹ thuật đầu vào ca kiểm thử đƣợc lựa chọn một cách ngẫu nhiên từ tập
miền đầu vào của hệ thống.
 Bƣớc 1: Xác định miền đầu vào.
 Bƣớc 2: Đầu vào đƣợc lựa chọn một cách độc lập từ miền đầu vào.