Kiểm tra độ phủ trong kiểm thử đơn vị

Kiểm tra độ phủ trong kiểm thử đơn vị

Bạn đang xem bản đúc kết của ebook. Xem & tải ngay bản đầy đủ của ebook tại đây (2.18 MB, 68 trang )

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

LÊ THỊ THU HIỀN

KIỂM TRA ĐỘ PHỦ
TRONG KIỂM THỬ ĐƠN VỊ

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

Hà Nội, 2014

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

LÊ THỊ THU HIỀN

KIỂM TRA ĐỘ PHỦ
TRONG KIỂM THỬ ĐƠN VỊ

Nghề: CNTT
Chuyên nghề: Kỹ thuật software
Mã số: 60480103

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

NGƢỜI HƢỚNG DẪN KHOA HỌC: PGS.TS NGUYỄN VIỆT HÀ

Hà Nội, 2014

ι

LỜI CẢM ƠN!

Trước nhất tôi xin gửi lời cảm ơn đặc biệt nhất tới PGS.TS. Nguyễn Việt
Hà, Bộ môn Công nghệ software, Khoa CNTT, Trường Đại học
Công nghệ, Đại học Quốc Gia Hà Nội, người đã định hướng chủ đề & tận tình
chỉ dẫn chỉ bảo tôi trong suốt công cuộc thực hiện luận văn cao học này.
Tôi xin được gửi lời cảm ơn sâu sắc tới các thầy gia sư khoa Công nghệ
thông tin, Đại học Công nghệ, Đại học Quốc Gia Hà Nội đã tận tình giảng dạy
& truyền đạt những tri thức, những kinh nghiệm quý báu trong suốt hai năm
học Cao học.
Cuối cùng tôi xin dành thiện cảm tri ân tới Bố, Mẹ, Chồng & gia đình,

những người đã luôn luôn ở bên cạnh tôi, khuyến khích, chia sẻ cùng tôi trong suốt
thời gian học cao học cũng như công cuộc thực hiện luận văn cao học.

Hà Nội, tháng 06 năm 2014

Lê Thị Thu Hiền

ii

LỜI CAM ĐOAN

Tôi xin khẳng định đây là công trình tìm hiểu của riêng tôi. Các kết quả
nêu trong bản luận văn đó là trung thực & chưa từng được ai thông báo trong bất
cứ công trình nào khác.
Hà Nội, tháng 06 năm 2014

Lê Thị Thu Hiền

iii

TÓM TẮT
Kiểm thử software có một vai trò trọng yếu trong việc bảo đảm tính đúng
đắn của hệ thống software trong suốt công cuộc thực thi. Kiểm thử cần được
tiến hành ở nhiều mức & kết hợp nhiều kỹ thuật khác nhau. Kiểm thử đơn vị
dù rằng không còn quá độc đáo bên cạnh đó nó vẫn là một trong những bước kiểm
thử trọng yếu khi viết chương trình. Bài viết xuyên suốt của luận văn là
tìm hiểu kỹ thuật kiểm thử hộp trắng đi sâu vào kiểm thử luồng điều khiển để
nghiên cứu các đường đi trong chương trình. Độ phủ là một trong các tiêu chuẩn khi
kiểm thử luồng điều khiển, độ phủ càng lớn thì độ tin cậy của bộ dữ liệu kiểm
thử càng cao. Khi chương trình tồn tại các nhánh chưa được phủ thì lỗi rất có thể
xảy ra tại các nhánh này. Luận văn đề nghị mẹo kiểm tra độ phủ của bộ
dữ liệu kiểm thử đạt đúng chuẩn bao phủ nhánh dựa theo dụng cụ kiểm thử Java
PathFinder (JPF). Cách thức đã sử dụng các tính năng lưu vết khi thực thi

chương trình của JPF để xây dựng một dụng cụ auto bổ trợ kiểm tra độ phủ
trong kiểm thử đơn vị. Dụng cụ xây dựng đã bổ trợ lập trình viên kiểm tra độ
phủ của bộ dữ liệu kiểm thử cũng như giúp lập trình viên nhận xét lại mã nguồn
đã viết.

iv

MỤC LỤC

DANH MỤC CÁC THUẬT NGỮ, KÝ HIỆU VÀ CHỮ VIẾT TẮT vi
DANH MỤC CÁC BẢNG vii
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ viii
CHƢƠNG 1- MỞ ĐẦU 1
1.1. Hoàn cảnh tìm hiểu 1
1.2. Bài viết tìm hiểu 2
1.3 Kết cấu luận văn 3
CHƢƠNG 2- CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ 4
2.1 Định nghĩa kiểm thử software 4

2.2. Quy trình kiểm thử software 4
2.3 Kiểm thử đơn vị 5
2.3.1 Kiểm thử đơn vị trong vòng đời tiến triển software 5
2.3.2 Một số loại kiểm thử đơn vị 6
2.4 Các kỹ thuật kiểm thử software 7
2.4.1 Kỹ thuật kiểm thử hộp đen 7
2.4.2 Kỹ thuật kiểm thử hộp trắng 9
CHƢƠNG 3 – CÔNG CỤ KIỂM CHỨNG JAVA PATHFINDER 16
3.1 Lịch sử của Java PathFinder 16
3.2 Những gì có thể được kiểm chứng bởi Java PathFinder 16
3.3 Thiết kế của Java PathFinder 17
3.4 Một số phần mở rộng của Java PathFinder 19
3.4.1 Bộ tạo chỉ thị (Bytecode Factory) 19
3.4.2 Listeners 20
3.4.3 Hệ thống giải trình (The Report) 23
3.5 Đo độ phủ trong kiểm thử đơn vị sử dụng JPF CoverageAnalyzer 24
3.6 Tổng kết 28
CHƢƠNG 4 – PHƢƠNG PHÁP KIỂM TRA ĐỘ PHỦ TRONG KIỂM
THỬ ĐƠN VỊ SỬ DỤNG JAVA PATHFINDER 29
?

4.1 Bài toán 29
4.2 Cách thức xây dựng dụng cụ kiểm tra độ phủ sử dụng JPF 29
4.2.1 Bài viết mẹo 29
4.2.2 Chẳng hạn minh họa cho mẹo 33
4.3 Tổng kết 35
CHƢƠNG 5 – THỰC NGHIỆM 36
5.1 Giới thiệu về dụng cụ kiểm tra độ phủ 36
5.2 Seting dụng cụ sử dụng lập trình 36
5.3 Xây dựng dụng cụ kiểm tra độ phủ 37

5.3.1 Nghiên cứu dữ liệu log 38
5.3.2 Nghiên cứu mã nguồn 41
5.3.3 So sánh dữ liệu log & mã nguồn giải trình kết quả 43
5.3.4 Các bước thực thi chương trình 43
5.4 Thí nghiệm kiểm tra độ phủ 44
KẾT LUẬN 52
TÀI LIỆU THAM KHẢO 53
PHỤ LỤC 55

vi

DANH MỤC CÁC THUẬT NGỮ, KÝ HIỆU VÀ CHỮ VIẾT TẮT

Từ viết tắt/thuật ngữ
Diễn đạt
CFG
Control Flow Graph
JPF
Java PathFinder
Tc

Check case
EO
Expected output(Kết quả đợi mong)
Statement coverage
Bao phủ câu lệnh
Branch coverage
Bao phủ nhánh, bao phủ quyết định
Condition coverage
Bao phủ điều kiện
Check case
Ca kiểm thử
Check suite
Bộ các ca kiểm thử, bộ dữ liệu kiểm thử
Valication
Giám định
Verification
Kiểm chứng
File
Tệp
Log
Vết chương trình

vii

DANH MỤC CÁC BẢNG

Bảng 2.1: Các tiêu chí kiến trúc ca kiểm thử 10
Bảng 3.1: Bộ check theo tiêu chí bao phủ điều kiện của hàm exam 25
Bảng 3.2: Bộ check theo tiêu chí bao phủ câu lệnh của hàm exam 26
Bảng 3.3: Bộ check theo tiêu chí bao phủ nhánh của hàm exam 27
Bảng 5.1: Bộ check theo tiêu chí bao phủ câu lệnh của hàm foo 44
Bảng 5.2: Bộ check theo tiêu chí phủ nhánh của hàm foo 45
Bảng 5.3: Bộ check theo tiêu chí bao phủ nhánh của hàm getAverage 47
Bảng 5.4: Bộ check kiểm thử vòng lặp while trong hàm getAverage 49
Bảng 5.5: Kết quả thí nghiệm nhận xét độ phủ của bộ dữ liệu 50
Bảng 5.6: Kết quả thí nghiệm kiểm thử vòng lặp 50

viii

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

Hình 2.1: Mô hình kiểm thử chữ ? 5
Hình 2.2: Sơ đồ vòng lặp while , do while 13
Hình 2.3: Sơ đồ miêu tả vòng lặp lồng nhau 14
Hình 3.1: Thiết kế JPF 17
Hình 3.2: Bộ tạo chỉ thị Bytecode Factory 19
Hình 3.3: JPF Listeners 20
Hình 3.4: Các loại Listener 21
Hình 3.5: Hệ thống giải trình Report 24
Hình 3.6: Quy trình kiểm tra độ phủ hàm sử dụng JPF CoverageAnalyzer 25
Hình 3.7: Đồ thị luồng điều khiển của hàm exam 25
Hình 3.8: Minh họa kết quả đo độ phủ sử dụng JPF CoverageAnalyzer 26
Hình 3.9: Kết quả kiểm tra độ phủ câu lệnh của hàm exam 27
Hình 3.10: Kết quả kiểm tra độ phủ nhánh của hàm exam 28
Hình 4.1: Quy trình khái quát xây dựng dụng cụ kiểm tra độ phủ 30
Hình 4.2: Vết ngăn xếp chương trình 32
Hình 4.3: Minh họa kết quả đạt được của mẹo đề nghị 34
Hình 5.1: Kết quả biên dịch thành công chương trình JPF trên eclipse 37
Hình 5.2: Màn hình console hiển thị chạy thành công JPF 37
Hình 5.3: Biểu đồ tuần tự giữa các lớp trong chương trình 38
Hình 5.4: Biểu đồ tuần tự công cuộc nghiên cứu dữ liệu vết(log) 39
Hình 5.5: Biểu đồ lớp nghiên cứu dữ liệu vết 40
Hình 5.6: Biểu đồ tuần tự công cuộc nghiên cứu mã nguồn. 42
Hình 5.7: Biểu đồ lớp các lớp lưu trữ thông tin đọc từ mã nguồn 42

Hình 5.8: Màn hình console thực thi chương trình 43
Hình 5.9: Minh họa kết quả kiểm tra với dụng cụ 43
Hình 5.10: Đồ thị luồng điều khiển cho hàm foo 44
Hình 5.11: Kết quả kiểm tra độ phủ của hàm foo thực thi bộ check ở bảng 5.2 45
Hình 5.12: Kết quả nhắc nhở lỗi khi thực thi hàm foo với bộ check tại bảng 5.2 46
Hình 5.13: Kết quả kiểm tra độ phủ của hàm getAverage thực thi với bộ check
case tại bảng 5.3 48
Hình 5.14: Kết quả kiểm thử vòng lặp while trong hàm getAverage 49

1

CHƢƠNG 1- MỞ ĐẦU

1.1. Hoàn cảnh tìm hiểu
Trong những năm gần đây, khi CNTT càng ngày càng phát
triển, software thực sự trở thành một phần chẳng thể thiếu trong các doanh
nghiệp. Mỗi phòng ban trong mỗi công ty đều lệ thuộc vào software để
bổ trợ việc tiến triển, sản xuất, marketing & quảng cáo các sản phẩm & dịch vụ
của họ. Trong các công đoạn tiến triển software, công đoạn phát hiện, xác nhận
& sửa các lỗi software là công đoạn chẳng thể thiếu nhằm bảo đảm chất lượng
của các sản phẩm software. Trong một tổ chức tiến triển thương mại điển
hình, ngân sách giành cho các công việc gỡ lỗi (debugging), kiểm thử (testing) &
các hoạt động kiểm chứng software (verification activities) chiếm từ 50 đến
70% tổng ngân sách tiến triển [7].
Với tốc độ tiến triển đến chóng mặt của ngành nghề CNTT &
truyền thông trên cả các hệ thống Hartware & software, khả năng xảy ra
nhiều lỗi, nhất là các lỗi cầu kỳ là rất cao. Những lỗi này có thể gây ra
những hậu quả cực kỳ nghiêm trọng về tiền nong, thời gian, thậm chí sinh mạng của con
người. Nhìn chung, một lỗi càng sớm được phát hiện sẽ càng mất ít công sức để
fix lỗi, thậm chí có thể phải xây dựng lại toàn thể hệ thống từ đầu.

• Theo đo đạc của Standish Group, Mỹ (2000) [8]: Trên 350 công ty du học
với hơn 8000 dự án software có: 31% dự án software bị bãi bỏ trước khi
được giải quyết. Với các công ty du học lớn, chỉ có khoảng 9% tổng số các dự án hoàn
thành đúng tiến độ & trong chi phí dự án (với các công ty du học nhỏ, tỷ lệ này vào
khoảng 16%).
• Theo tìm hiểu của NIST, Mỹ (2002) [10]: Ngân sách hàng năm dành
cho việc phát hiện các lỗi software lên đến 59.5 tỉ $ chiếm từ 0.2 đến 0.6%
GDP kinh tế nước Mỹ.
• Theo đo đạc của NASA IVvàamp;? Center (2000) [10]: Nghề công
nghiệp không gian vũ trụ mất đến hàng tỉ $ & hàng trăm sinh mạng con
người trong những năm cuối thập niên 1990 vì các vấn đề liên quan đến phần
mềm.
Tiến trình tiến triển software bao gồm rất là nhiều công đoạn: Thu thập yêu
cầu, nghiên cứu, kiến trúc, xây dựng, kiểm tra, triển khai & bảo dưỡng software.
Trong các công đoạn đó công đoạn kiểm tra, phát hiện, xác nhận & sửa các lỗi
software là rất trọng yếu để bảo đảm chất lượng của một software. Để phát
xuất hiện các lỗi software, software cần được kiểm chứng (Verification) &
2

giám định (Validation) [9, 11]. Giám định cần phải có sự gia nhập của người sử dụng
nhằm kiểm tra xem software có thực sự thỏa mãn các yêu cầu của người sử dụng
hay không. Kiểm chứng là kiểm tra software có được kiến trúc & thực thi đúng
như đặc tả hay không. Mục tiêu chính của tiến triển software là phải làm sao
tạo thành được những sản phầm software có chất lượng đảm bảo nhất. Để giúp làm
được điều đó kiểm chứng software là phần chẳng thể thiếu. Kiểm chứng phần
mềm giúp làm giảm bớt lỗi software tới mức có thể chấp thuận được. Chính
chính vì vậy, nó có vai trò đặc biệt quan trọng trong toàn thể quy trình tiến triển phần
mềm & trong nghề công nghệ software hiện tại. Chính vì vậy, trong công
nghệ software, kiểm chứng software luôn lôi kéo được mối quan tâm của rất
nhiều nhà tìm hiểu. Việc viết tập hợp các ca kiểm thử (check cases) là một phần

trọng yếu chẳng thể thiếu trong mẹo kiểm thử software. Tập hợp các
ca kiểm thử chính xác giúp giảm bớt tối đa các lỗi, giảm thời gian tìm kiếm lỗi,
tạo thành được các software tốt, tính ổn định cao.
1.2. Bài viết tìm hiểu
Kiểm thử là công đoạn trọng yếu trong công cuộc tiến triển software. Có rất
nhiều lý do gây ra lỗi trong software, nó nằm ở toàn bộ các công đoạn
trong quy trình tiến triển software, & lập trình cũng là một trong số các giai
đoạn đó. Lỗi hiện ra do lập trình gây ra là hoàn toàn dễ hiểu, trong giai đoạn đầu
của nghề công nghiệp software, tiến triển software cũng có nghĩa là lập
trình, việc lập trình được thực hiện hoàn toàn thủ công, chính vì như thế lỗi gây ra do
lập trình là cốt yếu. Ngày nay, lập trình chỉ là một giai đoạn trong công cuộc
tiến triển software, được bổ trợ bởi nhiều dụng cụ lập trình thời thượng, thành ra việc
lập trình đã trở nên nhẹ nhõm hơn, bên cạnh đó không phải chính vì vậy mà lỗi lập trình
lại mất đi. Người ta vận dụng rất là nhiều kỹ thuật trong kiểm thử nhằm mục tiêu
kiến trúc ra các ca kiểm thử có khả năng phát xuất hiện nhiều lỗi nhất trong chương
trình. Không những thế, trên thực tiễn vẫn có thể tồn tại các nhánh không được chạy qua
khi hàm hoặc một phương pháp được thực thi. Những nhánh đó có thể là vô
nghĩa nhưng cũng có thể là nơi tiềm tàng rất là nhiều lý do gây ra lỗi. Chính vì như vậy,
tất cả chúng ta cần phải có mẹo xác nhận có hay không tồn tại các nhánh chưa
duyệt qua trong chương trình, nếu có thì nhắc nhở cho người tiến triển kiểm tra
& giải quyết. Trong bài viết luận văn sẽ tìm tòi các tiêu chí bao phủ [6] mã
nguồn của bộ check căn bản nhưng rất mạnh khỏe như tiêu chí bao phủ lệnh
(statement coverage), bao phủ nhánh (branch coverage), bao phủ điều kiện
(condition coverage) nhằm giúp xây dựng các ca kiểm thử tốt phát hiện nhánh
chưa được phủ trong mã nguồn đang xét. Không những thế trong luận văn cũng đề
3

xuất xây dựng một dụng cụ auto kiểm tra độ phủ của bộ dữ liệu kiểm thử
đáp ứng một tiêu chí dựa theo dụng cụ kiểm chứng Java Pathfinder. Đầu vào
của dụng cụ là một hàm hay một phương pháp cần kiểm tra, xây dựng đồ thị

luồng điều khiển, tiến hành xây dựng các ca kiểm thử. Sử dụng dụng cụ Java
Pathfinder bổ trợ ghi lại từng dòng lệnh được chạy trong công cuộc kiểm thử với
bộ các ca kiểm thử đã xây dựng. Sau đó dụng cụ so sánh dữ liệu ghi được với
các nhánh trong đồ thị luồng điều khiển, xác nhận được những nhánh nào trong
hàm, trong phương pháp chưa được phủ, hiển thị kết quả nhắc nhở cho lập trình
viên. Dụng cụ sẽ giúp công cuộc kiểm tra độ phủ trong kiểm thử đơn vị thực hiện
mau lẹ, kết quả hiển thị trực quan hơn nhằm nhận xét các ca kiểm thử &
hàm đang xét.
1.3 Kết cấu luận văn
Phần còn sót lại của luận văn có cấu tạo như sau:
Chƣơng 2: Trình bày tri thức về kiểm thử software, kế sách kiểm thử
đơn vị với kỹ thuật rõ ràng và cụ thể là kiểm thử luồng điều khiển trong kiểm thử hộp
trắng.
Chƣơng 3: Giới thiệu về dụng cụ kiểm chứng JavaPathfinder, các thiết kế
chung về JPF, thành phần mở rộng của JPF & cách kiểm tra độ phủ của bộ dữ
liệu kiểm thử thông qua chức năng trong lớp CoverageAnalyzer.
Chƣơng 4: Đề nghị mẹo kiểm tra độ phủ của bộ dữ liệu kiểm thử dựa
trên dụng cụ Java Pathfinder. Bài viết của mẹo là xây dựng dụng cụ đo
độ phủ ở mức kiểm thử đơn vị sử dụng khả năng lưu vết chương trình của JPF.
Chƣơng 5: Thí nghiệm & nhận xét kết quả đạt được. Trong chương này
http://phptravels.vn/ nêu rõ cách seting dụng cụ JPF, ứng dụng chức năng của JPF & seting
thêm mã nguồn để xây dưng dụng cụ kiểm tra độ phủ. Không những thế http://phptravels.vn/ sử
dụng dụng cụ đã xây dụng để kiểm tra độ phủ của bộ check thông qua các chẳng hạn từ
đó rút ra đánh giá nhận xét về mã nguồn cũng như các ca kiểm thử đã viết.

4

CHƢƠNG 2- CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ
2.1 Định nghĩa kiểm thử software
Kiểm thử software là công cuộc thực thi hệ thống hoặc chương trình để kiểm
tra xem hệ thống có đúng với đặc tả, kiến trúc hay không. Kiểm thử software
đồng nghĩa với việc tìm thấy những lỗi tiềm tàng chưa được phát hiện, một cách sớm
nhất & bảo đảm rằng những lỗi đó đã được sửa, chứ không làm công việc chuẩn
đoán lý do gây ra lỗi hay fix lỗi đã phát hiện được[4].
Mục đích của kiểm thử software là kiến trúc một hoặc chuỗi các ca kiểm thử
có khả năng phát hiện được lỗi cao. Để nhận được kết quả tốt, hoạt động kiểm thử
cần được chuẩn bị tốt về sách lược, kiến trúc & dữ liệu cho mỗi ca kiểm thử. Đây
chính là đầu vào cho việc kiểm thử, còn đầu ra chính là ebook giải trình kiểm
thử, đặt ra được các thông tin về mục đích của kiểm thử, dữ liệu đầu vào, dữ
liệu đầu ra đợi mong, dữ liệu đầu vào thực tiễn…
2.2. Quy trình kiểm thử software
Quy trình kiểm thử software bao gồm các bước như lập sách lược kiểm
thử, thiết kê các trường hợp kiểm thử, sắp xếp nhân công kiểm thử, đo đạc, đánh
giá sản phẩm để xác định sản phẩm có thể được đặt ra sử dụng hay chưa. Trong
đó:
 Công đoạn lập sách lược kiểm thử [2,3] bao gồm các bước như xác nhận
hoạt động cần thực hiện, mẹo thực hiện, mục đích kiểm thử dựa trên
đặc tả yêu cầu, đặc tả tính năng…, phạm vi kiểm thử, mẹo kiểm thử,
nguồn tài nguyên thiết yếu, thời gian biểu cho hoạt động kiểm thử, ebook tham
khảo.
 Công đoạn kiến trúc các ca kiểm thử là công đoạn trọng yếu nhất, bao gồm
các bước xác nhận dữ liệu đầu vào & đầu ra cho hoạt động kiểm thử cùng các
câu lệnh cần thực hiện. Trong suốt công cuộc kiến trúc ca kiểm thử, yêu cầu hệ

thống phải được tìm hiểu một cách cẩn trọng, các chức năng của hệ thống
phải được xác nhận một cách cụ thể & các hành vi của ca kiểm thử cũng nên
được khái niệm cụ thể.
 Sắp đặt nhân công kiểm thử: việc kiểm thử cần được tiến hành một cách độc
lập giữa các nhóm kiểm thử sau đó thu thập kết quả của từng nhóm, so sánh với
nhau & đặt ra tổng kết cuối cùng. Việc kiểm thử thường được tiến hành ở nhiều
cấp độ khác nhau như kiểm thử đơn vị, kiểm thử tích hợp hay kiểm thử hệ
thống…, xuyên suốt trong vòng đời tiến triển của software. Ở mỗi cấp độ
kiểm thử nên có từng nhóm biệt lập chẳng hạn ở cấp độ kiểm thử đơn vị thì chính
5

người lập trình lại đóng vai trò của người kiểm thử, ở cấp độ kiểm thử tích hợp
được thực hiện với các kỹ sư kiểm thử tích hợp hệ thống, họ là những người có
tri thức về chính sách xây dựng, tích hợp những hệ thống lớn…
2.3 Kiểm thử đơn vị
2.3.1 Kiểm thử đơn vị trong vòng đời tiến triển software
Quy trình kiểm thử được thực hiện ở nhiều cấp độ khác nhau trong vòng đời
tiến triển software, bao gồm kiểm thử hoàn toàn hoặc kiểm thử một phần hệ
thống. Mỗi hệ thống software thường trải qua bốn cấp độ kiểm thử là kiểm thử
đơn vị ( unit testing), kiểm thử tích hợp ( integration testing), kiểm thử hệ thống
( system testing) & kiểm thử chấp thuận ( acceptance testing) trước khi được mang
vào triển khai thực tiễn. Trong số đó chỉ có kiểm thử chấp thuận được thực hiện bởi
KH, còn ba loại kiểm thử trước hết đều được thực hiện bởi các nhóm phát
triển trong đơn vị sản xuất software. Bốn loại kiểm thử trên kết phù hợp với nhau
tạo ra mô hình chữ ?.

Hình 2.1: Mô hình kiểm thử chữ ?
Trong kiểm thử đơn vị, người lập trình đóng luôn vai trò của người kiểm
thử, họ sẽ kiểm tra từng bộ chương trình riêng rẽ như hàm, thủ tục, lớp, chức

năng một cách độc lập. Sau thời điểm bảo đảm rằng các bộ chương trình đó làm việc
tốt trong phạm vị cho phép thì các mô đun sẽ được phối hợp lại thành các hệ
thống con to hơn. Có hai nguyên nhân chính cho việc tiến hành kiểm thử đơn vị một
cách độc lập:
Trước nhất, khi tiến hành kiểm thử đơn vị một cách biệt lập, nếu lỗi được tìm
thấy thì nó có thể sửa một cách đơn giản, do chúng có thể được xác nhận cụ thể
trong bộ chương trình nào & dữ liệu đầu vào cho từng bộ chương trình cũng là
Yêu cầu nghiệp vụ
Kiến trúc cấp độ
cao
Kiến trúc cấp độ thấp
ռ
Mã nguồn
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
6

đơn giản. Nếu nhiều bộ chương trình được phối hợp lại với nhau để kiểm thử, thì
người kiểm thử sẽ phải tạo thành dữ liệu kiểm thử không những cho từng bộ chương
trình, mà còn phải cho cả mối quan hệ giữa các bộ chương khác với nhau.
Thứ hai, trong suốt công cuộc thực thi kiểm thử đơn vị, việc thực thi từng bộ
chương trình một cách riêng rẽ có thể bảo đảm việc thực thi từng đường dẫn
riêng rẽ nhiều nhất có thể. Điều đó dẫn đến việc nhiều đường đi độc lập nhất có
thể được kiểm tra. Khi thực hiện kiểm thử đơn vị, người kiểm thử phải bảo đảm
được một số phép tắc như thực thi mọi dòng lệnh, biểu thức điều kiện, vòng
lặp…& bảo đảm rằng nó không chứa các lỗi có thể tìm ra được trước khi

được kết phù hợp với các bộ khác.
2.3.2 Một số loại kiểm thử đơn vị
Kiểm thử đơn vị gồm hai loại căn bản là kiểm thử đơn vị tĩnh( static unit
testing) & kiểm thử đơn vị động (dynamic unit testing)
 Kiểm thử đơn vị tĩnh
Với kiểm thử đơn vị tĩnh, mã nguồn được nhìn nhận nhờ hai kỹ thuật chính là
walkthrough & inspection. Trong số đó, theo Edward Yourdon [5] thì kỹ thuật
walkthrough được thực hiện theo cách Author của chương trình sẽ chỉ dẫn
nhóm kiểm thử thông qua việc thực thi chương trình một cách rõ ràng và cụ thể với những
cốt chuyện đã được giàn dựng từ trước. Theo Michael Fagan [5] thì kỹ thuật
inspection có nghĩa là trong mỗi bước kiểm tra, từng nhóm sẽ nhận xét sản phẩm
bằng cách so sánh với cốt chuyện kiểm thử đã được chuẩn bị từ trước. Cả hai kỹ
thuật trên đều là nhận xét mã nguồn theo hướng ngữ nghĩa & không nhận xét
người tạo thành mã nguồn.
Quy trình kiểm thử đơn vị tĩnh được thực hiện lần lượt qua các bước: chuẩn
bị cốt chuyện, nhân công -> chuẩn bị thắc mắc, yêu cầu biến đổi -> kiểm tra, nhận xét
mã nguồn -> Author mã nguồn sửa những vấn đề biến đổi -> kiểm tra lại -> kết
thúc.
 Kiểm thử đơn vị động
Kiểm thử đợn vị động là kỹ thuật kiểm thử dựa trên việc thực thi từng bộ
chương trình một cách độc lập trong môi trường thực thi được mô phỏng. Nó
gồm có hai thành phần chính là check driver & stubs.
 Check driver là một chương trình gọi tới các bộ để kiểm thử. Các bộ đó sẽ
thực thi với dữ liệu đầu vào được ra đời từ driver & trả lại giá trị cho driver.
Driver sẽ so sánh đầu ra thực tiễn với đầu ra đợi mong rồi báo kết cáo lại kết quả
kiểm thử. Driver không những giữ vai trò biên dịch chương trình mà nó còn cung
cấp cả dữ liệu đầu vào cho kiểm thử theo định dạng mong chờ.
7

Xem Thêm  Tải Dynasty Warriors 8 Xtreme Legends Full Cho PC [Link Fshare] - cách khắc phục lỗi 0xc00007b

 Stubs là chương trình con mô phỏng, thay thế cho mỗi bộ chương trình

nào đó được gọi đến từ bộ chương trình đang được kiểm tra. Mỗi stub tiếp nhận
hai trách nhiệm, trước hết nó nêu ra vai trò của chính nó làm trách nhiệm bằng cách in
ra các thông điệp. Thứ hai, nó trả lại giá trị mong chờ cho bộ chương trình gọi
tới nó, giúp cho bộ đó có thể tiếp tục thực thi.
Trong kiểm thử đơn vị động, có một số kỹ thuật giúp cho việc lựa chọn dữ
liệu đầu vào kiểm thử đạt hiệu quả cao như kiểm thử luồng điều khiển (control
flow testing-), kiểm thử luồng dữ liệu (data flow testing), kiểm thử miền giá trị
(tên miền testing)…
 Kiểm thử luồng điều khiển được thực hiện thông qua một số bước như vẽ
đồ thị luồng điều khiển từ bộ chương trình, lựa chọn một vài cốt chuyện kiểm thử
luồng điều khiển, xác nhận đường đi trong đồ thị luồng điều khiển đáp ứng điều
kiện của cốt chuyện kiểm thử, xác nhận biểu thức từ các đường đi được lựa chọn
rồi ra đời dữ liệu phục vụ cho việc kiểm thử.
 Kiểm thử luồng dữ liệu: trong kiểm thử luồng dữ liệu trước hết cũng cần phải
vẽ được đồ thị luồng dữ liệu, sau đó đến việc lựa chọn các cốt chuyện kiểm thử
luồng dữ liệu, xác nhận đường đi trong đồ thị luồng dữ liệu đáp ứng cốt chuyện
kiểm thử, xác nhận biểu thức từ các đường đi được lựa chọn rồi ra đời dữ liệu
kiểm thử.
 Kiểm thử miền giá trị: trong cả hai kỹ thuật kiểm thử luồng điều khiển &
kiểm thử luồng dữ liệu đề không có chính sách phát hiện được lỗi, điều này có thể
được khắc phục trong kỹ thuật kiểm thử miền giá trị(domail testing). Trong các
tiếp cận này, mục lục các lỗi miền giá trị sẽ được liệt kê, sau đó dữ liệu kiểm
thử sẽ được lựa chọn trong mục lục đó để phát hiện lỗi. Cách thức này sẽ
phải lệ thuộc rất là nhiều vào kinh nghiệm của người kiểm thử.
2.4 Các kỹ thuật kiểm thử software
Theo John ?. Mc Gregor[13] thì các kỹ thuật kiểm thử cũng tương tự với
những dụng cụ được kiến trúc nhằm bảo đảm rằng toàn bộ các góc cạnh của hệ
thống đều được thăm dò qua. Những kỹ thuật đó chính là dụng cụ đem lại hiệu
quả, bảo đảm chất lượng cho hệ thống. Có hai loại kỹ thuật kiểm thử software
chính là kỹ thuật kiểm thử hộp đen (kiểm thử tính năng) & kỹ thuật kiểm thử

hộp trắng( kiểm thử cấu tạo).
2.4.1 Kỹ thuật kiểm thử hộp đen
Kỹ thuật kiểm thử hộp đen (Black- box testing) có cách gọi khác là kiểm thử
hướng dữ liệu (data – driven) hay là kiểm thử hướng về phía ra (input/output driven)
nhằm mục tiêu tìm thấy các lỗi về tính năng, khả năng sử dụng, các lỗi về giao
8

diện, lỗi truy cập dữ liệu bên ngoài, lỗi khởi tạo, hay chấm dứt & lỗi liên quan tới
các yêu cầu phi tính năng khác. Với kỹ thuật kiểm thử hộp đen, người kiểm thử
xem hệ thống như là hộp đen, hoàn toàn không quan tâm tới cấu tạo dữ liệu &
hành vi bên trong hệ thống, họ chỉ cần quan tâm đến việc phát xuất hiện những
hành vi không đúng với đặc tả của hệ thống, chính vì thế dữ liệu đầu vào cho kiểm thử
hộp đen chính là ebook đặc tả yêu cầu của software. Kiểm thử hộp đen
thường được vận dụng trong các công đoạn sau của kiểm thử hệ thống do nó
không cần quan tâm tới cấu tạo, mã nguồn của hệ thống, chính vì thế tất cả chúng ta không
thể đợi mong khả năng kiểm tra hết toàn bộ các lỗi trong hệ thống nhờ vận dụng kỹ
thuật này. Một số kỹ thuật thường được vận dụng trong kiểm thử hộp đen như:
 Phân hoạch tương tự: là kỹ thuật phân tách miền giá trị đầu
vào(input tên miền) thành lập các miền con dùng cho việc lựa chọn dữ liệu kiểm
thử. Mỗi miền con được gọi là phân hoạch, dữ kiệu trong cùng một phân hoạch
thì có tác động tới hệ thống như nhau khi kiểm thử, có thể là cùng hợp lệ hoặc
cùng không hợp lệ, chính vì thế, ta thường lựa chọn tối thiểu một tài nguyên điển hình
trong từng phân hoạch để làm dữ liệu đầu vào cho việc kiểm thử. Ưu thế của
mẹo phân hoạch tương tự chính là giảm bớt số lượng dữ liệu cần
kiểm tra so với hệ thống mà vẫn bao phủ được một miền dữ liệu đầu vào khổng
lồ, nó không hạn chế điều kiện vào, chính vì như thế ta cũng có thể sử dụng kỹ thuật
này cho miền giá tri đầu ra.
 Nghiên cứu giá trị biên: là kỹ thuật lấy sáng kiến dựa theo phân hoạch tương
đương, sau thời điểm phân hoạch miền dữ liệu đầu vào thành các miền con, ta lựa chọn
những dữ liệu ở gần biên (cả trong & ngoài lớp tương tự) làm dữ liệu kiểm

thử. Từ những dữ liệu kiểm thử đó ta có thể tìm ta được những lỗi gây ra bởi
việc thực thi biên chưa đúng đắn. Trên thực tiễn, các nhà kiến trúc cũng như người
lập trình thường có khuynh hướng bỏ qua các điều kiện biên, chính vì thế khả năng lỗi xuất
hiện ở gần biên là rất lớn.
 Bảng quyết định: do điểm yếu chính của kiểm thử dựa trên các lớp
tương tự là nó chỉ có khả năng kiểm tra được từng dữ liệu đầu vào riêng rẽ
mà không kiểm tra được các một tổ hợp các điều kiện cầu kỳ. Chính vì như thế, ta có thể
sử dụng bảng quyết định để giải quyết nhiều dữ liệu đầu vào của nhiều lớp tương
đương khác nhau đồng thời. Kết cấu chung của bảng quyết định thường bao gồm
tập các điều kiện (lý do), tập các tác động (hệ lụy) & tập các nguyên tắc.
Dữ liệu kiểm thử sẽ được lựa chọn theo từng điều kiện của bảng & kết quả thực
tế sẽ được đối chiếu với kết quả mong chờ. Chính vì vậy mà mỗi nguyên tắc trong
bảng quyết định sẽ tương ứng với một dữ liệu đầu vào cho kiểm thử.
9

 Kiểm thử hốt nhiên: là mẹo lựa chọn hốt nhiên dữ liệu đầu
vào cho kiểm thử từ miền giá trị. Do dữ liệu đầu vào cho kiểm thử được lựa
chọn hốt nhiên nên ta sẽ không xác nhận được dữ liệu đầu ra mong chờ,
chính vì như thế kỹ thuật này đòi hỏi những kế sách kiểm thử tốt để có thể đánh
giá được độ đúng đắn của kết quả kiểm thử thông qua việc so sánh với đặc tả hệ
thống. Ưu thế của kiểm thử hốt nhiên chính là khả năng đơn giản ước đoán
được độ tin cậy của software dựa trên đầu ra của kiểm thử.
 Đoán lỗi: là kỹ thuật cốt yếu dựa trên kinh nghiệm của người kiểm thử để
phán đoán loại, vị trí có thể xảy ra lỗi trong hệ thống. Kỹ thuật này rất hiệu quả đối
với những loại lỗi chẳng thể bao phủ được.
2.4.2 Kỹ thuật kiểm thử hộp trắng
Kỹ thuật kiểm thử hộp trắng (white-box testing) nói một cách khác là kiểm thử hộp
thủy tinh (glass-box testing) hay nói một cách khác là kiểm thử hộp trong suốt (clear-box
testing) cho phép kiểm tra cấu tạo bên trong của hệ thống, bảo đảm toàn bộ các
câu lệnh, các biểu thức điều kiện được kiểm tra tối thiểu một lần. Cũng tương tự với

việc kiểm tra dữ liệu đầu vào trong kiểm thử hộp đen, việc kiểm tra các đường
dẫn trong kiểm thử hộp trắng cũng cần phải được tiến hành một cách triệt để. Tuy
nhiên, điều này là hoàn toàn không khả thi, do số lượng đường dẫn logic bên
trong mỗi chương trình nếu chứa vòng lặp có thể là vô cùng lớn.
Việc tiến hành kỹ thuật kiểm thử hộp trắng phải bảo đảm được một số
phép tắc như mọi đường dẫn độc lập phải được thử hiện tối thiểu một lần, tại
mỗi biểu thức điều kiện, các giá trị true, false cũng cần phải được trổ tài tối thiểu
một lần, các vòng lặp cùng cần được kiểm tra tại các giá trị biên & các giá trị
trung gian, trong phạm vị hoạt động của chúng & cuối cùng là mọi cấu tạo dữ
liệu bên trong phải bảo đảm tính chính xác, đúng đắn.
Kiểm thử hộp trắng thường chăm chú vào hai góc cạnh chính là kiểm thử
luồng điều khiển & kiểm thử luồng dữ liệu. Kiểm thử luồng điều khiển hướng
đến việc thực thi chương trình, đi từ lời hướng dẫn này cho tới lời hướng dẫn khác.
Luồng dữ liệu liên quan tới sự biến đổi giá trị của các biến hay các hằng số. Quá
trình tiến hành kiểm thử hộp trắng thường được thực hiện ngay tại mỗi bộ
chương trình biệt lập mà người lập trình viết ra.
2.5 Ca kiểm thử & kiến trúc ca kiểm thử
2.5.1 Khái niệm ca kiểm thử
Có nhiều định nghĩa về ca kiểm thử khác nhau dựa trên quy mô, tổ chức. Tuy
nhiên, chúng đều có đặc điểm giống nhau như là bao gồm đầu vào, đầu ra mong
mong muốn & các điều kiện thực thi. Theo ebook thuật ngữ của ISTQB về kiểm thử
thì ca kiểm thử là một tập hợp các giá trị đầu vào, các điều kiện tiên quyết, điều
10

kiện thực thi, kết quả đợi mong, các điều kiện chấm dứt. Nó được xây dựng cho
mục đích kiểm thử biệt lập chẳng hạn như thực hiện một đường dẫn chương trình
biệt lập hoặc để kiểm tra lại đúng với yêu cầu của đặc tả yêu cầu hay chưa.
Dữ liệu đầu ra mong chờ sau thời điểm thực thi chương trình là một thực thể
cầu kỳ, nó có thể bao gồm các giá trị như: giá trị được ra đời từ chương trình,
các hiện trạng biến đổi của chương trình, các hiện trạng biến đổi của nền tảng dữ

liệu… & được xác nhận trong công cuộc kiến trúc ca kiểm thử nhờ việc hiểu đặc tả
yêu cầu của chương trình.
2.5.2 Tiêu chí kiến trúc ca kiểm thử
Trong kiểm thử software, một trong những vấn đề mấu chốt nhất chính
là việc kiến trúc ra các ca kiểm thử có khả năng tìm thấy được nhiều lỗi nhất mà chi
phí rẻ nhất. Thông thường, mẹo có khả năng tìm thấy nhiều lỗi nhất có thể
chính là kiểm tra toàn bộ các đầu vào của chương trình, bên cạnh đó này là điều không
thể do những ràng buộc về mặt thời gian, ngân sách & nhân công. Có một vài tiêu
chuẩn kiến trúc ca kiểm thử thường được vận dụng trong kiểm thử software:
Bảng 2.1: Các tiêu chí kiến trúc ca kiểm thử
Kiểm thử hộp đen
Kiểm thử hộp trắng
Phân lớp tương tự
Bao phủ lệnh
Nghiên cứu giá trị biên
Bao phủ nhánh(quyết định)
Bảng quyết định
Bao phủ điều kiện
Đoán lỗi
Bao phủ đa điều kiện
Trong kỹ thuật kiểm thử hộp trắng, tiêu chí kiến trúc ca kiểm thử bao
phủ câu lệnh phải bảo đảm mọi câu lệnh trong chương trình được thực hiện ít
nhất một lần. Bao phủ lệnh hoàn toàn là tiêu chí bao phủ yếu nhất trong kiểm
thử chương trình. Việc lựa chọn đường đi trong tiêu chí này có thể tuân theo
một số nguyên tắc như lựa chọn đường đi ngắn nhất, lựa chọn đường đi có bề dài
tăng dần, có thể duyệt qua vòng lắp một vài lần nếu thiết yếu. Tiêu chí bao
phủ điều kiện phải bảo đảm rằng mỗi điều kiện trong một quyết định phải được
duyệt qua tối thiểu một lần. Còn trong tiêu chí bao phủ đa điều kiện, toàn bộ
những sự phối hợp của các kết quả điều kiện có thể có tại mỗi quyết định & các
điểm vào phải được duyệt qua tối thiểu một lần.

2.5.3 Kiến trúc ca kiểm thử trong kiểm thử luồng điều khiển
Đồ thị luồng điều khiển( Control flow graph-CFG)
Đồ thị luồng điều khiển là sự diễn đạt đồ họa của một bộ chương trình. Có ba
ký kiệu chính hay được sử dụng trong đồ thị luồn điều khiển là hình chữ nhật
11

miêu ra các biểu thức toán học, mỗi biểu thức tính toán được gán nhãn bằng một
số nguyên, hình thoi diễn đạt các quyết định với hai nhánh tương ứng các quyết
định đúng, sai, hình tròn diễn đạt điểm thống nhất của các quyết định. Đồ thị luồng
điều khiển có thể xây dựng một cách thủ công hoặc trình biên dịch đã được thiết
lập để auto ra đời từ bộ chương trình.
 Đƣờng đi trong đồ thị luồng điều khiển
Đường đi (Execution path) trong đồ thị luồng điều khiển là một chuỗi các
biểu thức tính toán, các điểm quyết định từ điểm đầu vào cho đến điểm đầu ra.
Theo Ƭ. Ĵ. McCabe [13], số đường đi ứng với đồ thị luồng điều khiển được tính
bằng một trong các mẹo sau:
– Số cạnh – số đỉnh + 2
– Số đỉnh quyết định + 1
Sau thời điểm có được các đường đi của đơn vị chương trình cần kiểm thử, với mỗi
đường đi, tất cả chúng ta sẽ sinh một ca kiểm thử tương ứng.
Mục tiêu của mẹo kiểm thử luồng điều khiển là bảo đảm mọi đường
đi trong đồ thị luồng điều khiển của đơn vị software cần kiểm thử đều chạy
đúng. Không những thế để đạt được mục tiêu này thì công sức & thời gian bỏ ra rất
lớn. Chính vì như vậy, nên chắt lọc & kiểm thử số check case ít nhất mà kết quả độ tin cậy
tối đa. Nhưng làm sao xác nhận được số check case ít nhất nào có thể đem đến kết
quả có độ tin cậy tối đa. Phủ kiểm thử là một định nghĩa liên quan chặt chẽ đến
vấn đề trên. Phủ kiểm thử (Coverage) : là tỉ lệ các thành phần thực sự được kiểm
thử đối với tổng thể sau thời điểm đã kiểm thử các check case được chọn. Phủ càng lớn thì
độ tin cậy càng cao[1]. Bộ check case cần đáp ứng một số tiêu chí lựa chọn
đường đi để đạt mức phủ thiết yếu.

 Tiêu chí lựa chọn đƣờng đi
Trong mỗi đồ thị luồng điều khiển, có thể có rất là nhiều đường đi khác nhau
chính vì thế người kiểm thử phải có mẹo lựa chọn một số ít các đường đi
trong chương trình mà vẫn phát hiện lỗi trong mã nguồn một cách hiệu quả. Một
nguyên tắc thường được vận dụng trong việc tiến hành kiểm thử dựa trên đồ thị luồng
điều khiển như toàn bộ lời khởi tạo trong chương trình đều được thực hiện tối thiểu
một lần, không tạo thành nhiều dữ liệu đầu vào kiểm thử cho những đường đi được
thực hiện nhiều lần. Không những thế, nếu mỗi lần thực thi đường đi của chương trình
lại update lại hiện trạng của hệ thống chẳng hạn như hiện trạng DataBase của hệ
thống thì tất cả chúng ta nên tạo thành nhiều dữ liệu đầu vào kiểm thử cho những lần thực
thi đó. Có một số tiêu chí lựa chọn đường đi như:
 Tiêu chí bao phủ các câu lệnh
12

Bộ check case kiểm thử bảo đảm sao cho mỗi lệnh được thực thi tối thiểu một
lần. Trong kiến trúc check case ta luôn nỗ lực bao phủ tối đa câu lệnh trong mã
nguồn với số check case tối thiểu có thể. Bao phủ câu lệnh sẽ nhận thấy các câu lệnh
trong một phương pháp hay trong một lớp đã được thực thi. Đây là một phương
pháp đo đơn giản để tìm thấy số câu lệnh đã được thực thi trong tổng số các câu
lệnh mã nguồn. Cho nên lợi nhuận của bao phủ câu lệnh là khả năng tìm thấy các dòng
code không được thực thi
 Tiêu chí cả bao phủ nhánh
Tiêu chí bao phủ nhánh là kiểm thử sao cho mỗi điểm quyết định được
thực hiện tối thiểu một lần trong cả hai trường hợp true & false. Điều kiện không
cần chia nhỏ nếu là điều kiện cầu kỳ gồm nhiều điều kiện con. Một nhánh là
một tổng kết logic của một điều kiện, thành ra bao phủ nhánh đơn giản là đo kết
luận logic nào đã được kiểm tra. Cách thức bao phủ này suy xét mã nguồn
sâu sắc hơn là mẹo bao phủ câu lệnh. Xác nhận số nhánh có trong một
phương pháp là một việc dễ làm. Tổng kết kiểu boolean dĩ nhiên có hai kết
luận logic là “true” hoặc “false” thành ra chương trình có ռ điều kiện sẽ có 2

ռ

nhánh. Cách thức bao phủ nhánh vẫn bao hàm cả bao phủ câu lệnh bên cạnh đó
nó đã loại bỏ được một số giới hạn có ở bao phủ câu lệnh.
 Tiêu chí bao phủ điều kiện
Giống như bao phủ nhánh, kiểm tra bao phủ điều kiện cài đặt bảo đảm
kiểm tra từng điều kiện. Không những thế không giống như bao phủ nhánh, bao phủ
điều kiện bảo đảm kiểm tra toàn bộ các điều kiện con của từng điểm quyết định
đều được thực hiện tối thiểu một lần trong cả trường hợp true & false. Với các
điều kiện cầu kỳ (chứa nhiều điều kiện con căn bản), việc chỉ quan tâm đến giá
trị đúng sai là không đủ để kiểm tra tính chính xác của chương trình ứng với điều
kiện cầu kỳ này. Chẳng hạn, nếu một điều kiện cầu kỳ gồm hai điều kiện con cơ
bản, tất cả chúng ta có bốn trường hợp cần kiểm thử chứ không phải hai trường hợp
đúng sai như trong mẹo bao phủ nhánh. Với các hàm hay phương pháp
có yêu cầu cao về tính chính xác, việc tuân thủ bao phủ điều kiện là hết sức cần
thiết. Điều kiện để bảo đảm tính phủ đó là các điều kiện con thuộc các điều
kiện cầu kỳ tương ứng với các điểm quyết định trong đồ thị luồng điều khiển
của phương pháp cần kiểm thử đều được thực hiện tối thiểu một lần cả hai nhánh
đúng & sai.
 Lựa chọn đường đi kiểm thử vòng lặp
Vòng lặp là nền móng cho đa phần các thuật toán được seting trong phần
mềm. Không những thế, tất cả chúng ta thường ít quan tâm đến nó khi thực hiện việc kiểm
thử software. Kiểm thử vòng lặp là một kỹ thuật kiểm thử hộp trắng mà tập
13

trung trên tính hợp lệ của các cấu tạo lặp. Khi tiến hành kiểm thử các đơn vị
chương trình với bao phủ điều kiện thì mẹo kiểm thử luồng điều khiển
chẳng thể kiểm thử các vòng lặp hiện ra trong các đơn vị chương trình. Nguyên nhân
là các đường đi ra đời từ đồ thị luồng điều khiển không chứa các vòng lặp[1].
Trong thực tiễn, lỗi hay xảy ra ở các vòng lặp. Vì nguyên nhân này, tất cả chúng ta cần sinh

thêm các ca kiểm thử cho các vòng lặp nhằm giảm tỷ lệ lỗi của các chương
trình. Việc xây dựng các trường hợp kiểm thử cho mỗi loại vòng lặp cần thực
hiện như sau:
 Vòng lặp đơn
Vòng lặp mà trong thân không hiện ra thêm vòng lặp nào khác gọi là
vòng lặp đơn. Với vòng lặp đơn trong đó И là số lần lặp tối đa, các trường hợp
kiểm thử sau được sử dụng để kiểm tra mỗi điều kiện sau:
– Bỏ qua vòng lặp hay số lần lặp bằng 0
– Lặp 1
– Lặp 2
– Lặp ʍ lần trong đó ʍ < И
– Lặp И-1 lần
– Lặp И lần
– Lặp И+1 lần

Hình 2.2: Sơ đồ vòng lặp while , do while
 Vòng lặp lồng nhau
Vòng lặp mà trong thân của nó chứa vòng lặp khác gọi là vòng lặp lồng
nhau. Nếu tất cả chúng ta mở rộng mẹo kiểm thử vòng lặp đơn cho vòng lặp
lồng nhau thì các kiểm thử có thể sẽ tăng theo mức tiến triển vòng lặp. Điều này
có thể tạo thành một số không thực tiễn các trường hợp kiểm thử.

14

Hình 2.3: Sơ đồ miêu tả vòng lặp lồng nhau
Vì vậy, một cách tiếp cận đệ qui như sau sẽ cắt giảm số trường hợp
kiểm thử:
– Khởi đầu tại vòng lặp trong cùng.
– Xây dựng các kiểm thử vòng lặp đơn cho vòng lặp trong cùng, trong khi
đó giữ vòng lặp ngoài cùng tại các giá trị tham số lặp nhỏ nhất của chúng.
– Lớn mạnh ra phía ngoài, xây dựng các kiểm thử cho vòng lặp kế tiếp,
nhưng giữ toàn bộ các vòng lặp bên ngoài với giá trị nhỏ nhất & các vòng lặp lồng
nhau khác giá trị “đặc biệt”. Tiếp tục cho đến khi toàn bộ các vòng lặp được kiểm
thử.
 Vòng lặp liền kề
Nếu các vòng lặp liền kề nhau là độc lập thì chúng có thể được coi như
hai vòng lặp đơn biệt lập, sử dụng mẹo kiểm thử vòng lặp đơn. Nếu

Xem Thêm  Cách tìm kiếm giá trị ngày và giờ - SQLServerCentral - tìm kiếm ngày trong sql

vòng lặp thứ hai lệ thuộc vào vòng lặp trước(chẳng hạn, biến đếm của vòng lặp 1 là
giá trị khởi tạo của vòng lặp 2), thì xem chúng như các vòng lặp lồng nhau & sử
dụng cách tiếp cận kiểm thử vòng lặp lồng nhau.
 Các bƣớc sinh dữ liệu kiểm thử
Sau thời điểm xác nhận được đường đi dựa trên đồ thị luồng điều khiển, ta tiến
hành sinh dữ liệu đầu vào cho hoạt động kiểm thử. Với bộ dữ liệu đầu vào,
chương trình sẽ thực thi theo đường đi đã lựa chọn. Trong công cuộc sinh dữ liệu
kiểm thử, ta cần xác nhận một số tham số như:
15

– Vector đầu vào là một tập dữ liệu đầu vào cho thủ tục, bao gồm các tham
số đầu vào cho thủ tục, giá trị các biến toàn cục, hằng số, các file, connect
mạng,…
– Predicate: biểu thức điều kiện tại các điểm quyết định
– Xác nhận đường đi- path predicate expression: chứa tập các biểu thức
điều kiện cùng với giá trị của biểu thức đó & thứ tự các biểu thức điều
kiện gắn với một đường đi xác nhận nào đó.
Sau thời điểm xác nhận được biểu thức chỉ định đường đi, tuyệt đối có thể ra đời dữ
liệu đầu vào cho kiểm thử thông qua chuỗi biểu thức đã xây dựng.

LÊ THỊ THU HIỀNKIỂM TRA ĐỘ PHỦTRONG KIỂM THỬ ĐƠN VỊLUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TINHà Nội, 2014ĐẠI HỌC QUỐC GIA HÀ NỘITRƢỜNG ĐẠI HỌC CÔNG NGHỆLÊ THỊ THU HIỀNKIỂM TRA ĐỘ PHỦTRONG KIỂM THỬ ĐƠN VỊNgành: Công nghệ thông tinChuyên nghề: Kỹ thuật phần mềmMã số: 60480103LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TINNGƢỜI HƢỚNG DẪN KHOA HỌC: PGS.TS NGUYỄN VIỆT HÀHà Nội, 2014LỜI CẢM ƠN!Trước nhất tôi xin gửi lời cảm ơn đặc biệt nhất tới PGS.TS. Nguyễn ViệtHà, Bộ môn Công nghệ software, Khoa CNTT, Trường Đại họcCông nghệ, Đại học Quốc Gia Hà Nội, người đã định hướng chủ đề & tận tìnhhướng dẫn chỉ bảo tôi trong suốt công cuộc thực hiện luận văn cao học này.Tôi xin được gửi lời cảm ơn sâu sắc tới các thầy gia sư khoa Công nghệthông tin, Đại học Công nghệ, Đại học Quốc Gia Hà Nội đã tận tình giảng dạyvà truyền đạt những tri thức, những kinh nghiệm quý báu trong suốt hai nămhọc Cao học.Cuối cùng tôi xin dành thiện cảm tri ân tới Bố, Mẹ, Chồng & gia đình,những người đã luôn luôn ở bên cạnh tôi, khuyến khích, chia sẻ cùng tôi trong suốtthời gian học cao học cũng như công cuộc thực hiện luận văn cao học.Hà Nội, tháng 06 năm 2014Lê Thị Thu HiềniiLỜI CAM ĐOANTôi xin khẳng định đây là công trình tìm hiểu của riêng tôi. Các kết quảnêu trong bản luận văn đó là trung thực & chưa từng được ai thông báo trong bấtcứ công trình nào khác.Hà Nội, tháng 06 năm 2014Lê Thị Thu HiềniiiTÓM TẮTKiểm thử software có một vai trò trọng yếu trong việc bảo đảm tính đúngđắn của hệ thống software trong suốt công cuộc thực thi. Kiểm thử cần đượctiến hành ở nhiều mức & kết hợp nhiều kỹ thuật khác nhau. Kiểm thử đơn vịmặc dù không còn quá độc đáo bên cạnh đó nó vẫn là một trong những bước kiểmthử trọng yếu khi viết chương trình. Bài viết xuyên suốt của luận văn lànghiên cứu kỹ thuật kiểm thử hộp trắng đi sâu vào kiểm thử luồng điều khiển đểphân tích các đường đi trong chương trình. Độ phủ là một trong các tiêu chuẩn khikiểm thử luồng điều khiển, độ phủ càng lớn thì độ tin cậy của bộ dữ liệu kiểmthử càng cao. Khi chương trình tồn tại các nhánh chưa được phủ thì lỗi rất có thểxảy ra tại các nhánh này. Luận văn đề nghị mẹo kiểm tra độ phủ của bộdữ liệu kiểm thử đạt đúng chuẩn bao phủ nhánh dựa theo dụng cụ kiểm thử JavaPathFinder (JPF). Cách thức đã sử dụng các tính năng lưu vết khi thực thichương trình của JPF để xây dựng một dụng cụ auto bổ trợ kiểm tra độ phủtrong kiểm thử đơn vị. Dụng cụ xây dựng đã bổ trợ lập trình viên kiểm tra độphủ của bộ dữ liệu kiểm thử cũng như giúp lập trình viên nhận xét lại mã nguồnđã viết.ivMỤC LỤCDANH MỤC CÁC THUẬT NGỮ, KÝ HIỆU VÀ CHỮ VIẾT TẮT viDANH MỤC CÁC BẢNG viiDANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ viiiCHƢƠNG 1- MỞ ĐẦU 11.1. Hoàn cảnh tìm hiểu 11.2. Bài viết tìm hiểu 21.3 Kết cấu luận văn 3CHƢƠNG 2- CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ 42.1 Định nghĩa kiểm thử software 42.2. Quy trình kiểm thử software 42.3 Kiểm thử đơn vị 52.3.1 Kiểm thử đơn vị trong vòng đời tiến triển software 52.3.2 Một số loại kiểm thử đơn vị 62.4 Các kỹ thuật kiểm thử software 72.4.1 Kỹ thuật kiểm thử hộp đen 72.4.2 Kỹ thuật kiểm thử hộp trắng 9CHƢƠNG 3 – CÔNG CỤ KIỂM CHỨNG JAVA PATHFINDER 163.1 Lịch sử của Java PathFinder 163.2 Những gì có thể được kiểm chứng bởi Java PathFinder 163.3 Thiết kế của Java PathFinder 173.4 Một số phần mở rộng của Java PathFinder 193.4.1 Bộ tạo chỉ thị (Bytecode Factory) 193.4.2 Listeners 203.4.3 Hệ thống giải trình (The Report) 233.5 Đo độ phủ trong kiểm thử đơn vị sử dụng JPF CoverageAnalyzer 243.6 Tổng kết 28CHƢƠNG 4 – PHƢƠNG PHÁP KIỂM TRA ĐỘ PHỦ TRONG KIỂMTHỬ ĐƠN VỊ SỬ DỤNG JAVA PATHFINDER 294.1 Bài toán 294.2 Cách thức xây dựng dụng cụ kiểm tra độ phủ sử dụng JPF 294.2.1 Bài viết mẹo 294.2.2 Chẳng hạn minh họa cho mẹo 334.3 Tổng kết 35CHƢƠNG 5 – THỰC NGHIỆM 365.1 Giới thiệu về dụng cụ kiểm tra độ phủ 365.2 Seting dụng cụ sử dụng lập trình 365.3 Xây dựng dụng cụ kiểm tra độ phủ 375.3.1 Nghiên cứu dữ liệu log 385.3.2 Nghiên cứu mã nguồn 415.3.3 So sánh dữ liệu log & mã nguồn giải trình kết quả 435.3.4 Các bước thực thi chương trình 435.4 Thí nghiệm kiểm tra độ phủ 44KẾT LUẬN 52TÀI LIỆU THAM KHẢO 53PHỤ LỤC 55viDANH MỤC CÁC THUẬT NGỮ, KÝ HIỆU VÀ CHỮ VIẾT TẮTTừ viết tắt/thuật ngữDiễn giảiCFGControl Flow GraphJPFJava PathFinderTcTest caseEOExpected output(Kết quả đợi mong)Statement coverageBao phủ câu lệnhBranch coverageBao phủ nhánh, bao phủ quyết địnhCondition coverageBao phủ điều kiệnTest caseCa kiểm thửTest suiteBộ các ca kiểm thử, bộ dữ liệu kiểm thửValicationThẩm địnhVerificationKiểm chứngFileTệpLogVết chương trìnhviiDANH MỤC CÁC BẢNGBảng 2.1: Các tiêu chí kiến trúc ca kiểm thử 10Bảng 3.1: Bộ check theo tiêu chí bao phủ điều kiện của hàm exam 25Bảng 3.2: Bộ check theo tiêu chí bao phủ câu lệnh của hàm exam 26Bảng 3.3: Bộ check theo tiêu chí bao phủ nhánh của hàm exam 27Bảng 5.1: Bộ check theo tiêu chí bao phủ câu lệnh của hàm foo 44Bảng 5.2: Bộ check theo tiêu chí phủ nhánh của hàm foo 45Bảng 5.3: Bộ check theo tiêu chí bao phủ nhánh của hàm getAverage 47Bảng 5.4: Bộ check kiểm thử vòng lặp while trong hàm getAverage 49Bảng 5.5: Kết quả thí nghiệm nhận xét độ phủ của bộ dữ liệu 50Bảng 5.6: Kết quả thí nghiệm kiểm thử vòng lặp 50viiiDANH MỤC CÁC HÌNH VẼ, ĐỒ THỊHình 2.1: Mô hình kiểm thử chữ ? 5Hình 2.2: Sơ đồ vòng lặp while , do while 13Hình 2.3: Sơ đồ miêu tả vòng lặp lồng nhau 14Hình 3.1: Thiết kế JPF 17Hình 3.2: Bộ tạo chỉ thị Bytecode Factory 19Hình 3.3: JPF Listeners 20Hình 3.4: Các loại Listener 21Hình 3.5: Hệ thống giải trình Report 24Hình 3.6: Quy trình kiểm tra độ phủ hàm sử dụng JPF CoverageAnalyzer 25Hình 3.7: Đồ thị luồng điều khiển của hàm exam 25Hình 3.8: Minh họa kết quả đo độ phủ sử dụng JPF CoverageAnalyzer 26Hình 3.9: Kết quả kiểm tra độ phủ câu lệnh của hàm exam 27Hình 3.10: Kết quả kiểm tra độ phủ nhánh của hàm exam 28Hình 4.1: Quy trình khái quát xây dựng dụng cụ kiểm tra độ phủ 30Hình 4.2: Vết ngăn xếp chương trình 32Hình 4.3: Minh họa kết quả đạt được của mẹo đề nghị 34Hình 5.1: Kết quả biên dịch thành công chương trình JPF trên eclipse 37Hình 5.2: Màn hình console hiển thị chạy thành công JPF 37Hình 5.3: Biểu đồ tuần tự giữa các lớp trong chương trình 38Hình 5.4: Biểu đồ tuần tự công cuộc nghiên cứu dữ liệu vết(log) 39Hình 5.5: Biểu đồ lớp nghiên cứu dữ liệu vết 40Hình 5.6: Biểu đồ tuần tự công cuộc nghiên cứu mã nguồn. 42Hình 5.7: Biểu đồ lớp các lớp lưu trữ thông tin đọc từ mã nguồn 42Hình 5.8: Màn hình console thực thi chương trình 43Hình 5.9: Minh họa kết quả kiểm tra với dụng cụ 43Hình 5.10: Đồ thị luồng điều khiển cho hàm foo 44Hình 5.11: Kết quả kiểm tra độ phủ của hàm foo thực thi bộ check ở bảng 5.2 45Hình 5.12: Kết quả nhắc nhở lỗi khi thực thi hàm foo với bộ check tại bảng 5.2 46Hình 5.13: Kết quả kiểm tra độ phủ của hàm getAverage thực thi với bộ testcase tại bảng 5.3 48Hình 5.14: Kết quả kiểm thử vòng lặp while trong hàm getAverage 49CHƢƠNG 1- MỞ ĐẦU1.1. Hoàn cảnh nghiên cứuTrong những năm gần đây, khi CNTT càng ngày càng pháttriển, software thực sự trở thành một phần chẳng thể thiếu trong các doanhnghiệp. Mỗi phòng ban trong mỗi công ty đều lệ thuộc vào software đểhỗ trợ việc tiến triển, sản xuất, marketing & quảng cáo các sản phẩm & dịch vụcủa họ. Trong các công đoạn tiến triển software, công đoạn phát hiện, xác địnhvà sửa các lỗi software là công đoạn chẳng thể thiếu nhằm bảo đảm chất lượngcủa các sản phẩm software. Trong một tổ chức tiến triển thương mại điểnhình, ngân sách giành cho các công việc gỡ lỗi (debugging), kiểm thử (testing) vàcác hoạt động kiểm chứng software (verification activities) chiếm từ 50 đến70% tổng ngân sách tiến triển [7].Với tốc độ tiến triển đến chóng mặt của ngành nghề CNTT vàtruyền thông trên cả các hệ thống Hartware & software, khả năng xảy ranhiều lỗi, nhất là các lỗi cầu kỳ là rất cao. Những lỗi này có thể gây ranhững hậu quả cực kỳ nghiêm trọng về tiền nong, thời gian, thậm chí sinh mạng của conngười. Nhìn chung, một lỗi càng sớm được phát hiện sẽ càng mất ít công sức đểsửa lỗi, thậm chí có thể phải xây dựng lại toàn thể hệ thống từ đầu.• Theo đo đạc của Standish Group, Mỹ (2000) [8]: Trên 350 công tyvới hơn 8000 dự án software có: 31% dự án software bị bãi bỏ trước khiđược giải quyết. Với các công ty du học lớn, chỉ có khoảng 9% tổng số các dự án hoànthành đúng tiến độ & trong chi phí dự án (với các công ty du học nhỏ, tỷ lệ này vàokhoảng 16%).• Theo tìm hiểu của NIST, Mỹ (2002) [10]: Ngân sách hàng năm dànhcho việc phát hiện các lỗi software lên đến 59.5 tỉ $ chiếm từ 0.2 đến 0.6phần trămGDP kinh tế nước Mỹ.• Theo đo đạc của NASA IVvàamp;? Center (2000) [10]: Nghề côngnghiệp không gian vũ trụ mất đến hàng tỉ $ & hàng trăm sinh mạng conngười trong những năm cuối thập niên 1990 vì các vấn đề liên quan đến phầnmềm.Tiến trình tiến triển software bao gồm rất là nhiều công đoạn: Thu thập yêucầu, nghiên cứu, kiến trúc, xây dựng, kiểm tra, triển khai & bảo dưỡng software.Trong các công đoạn đó công đoạn kiểm tra, phát hiện, xác nhận & sửa các lỗiphần mềm là rất trọng yếu để bảo đảm chất lượng của một software. Để pháthiện ra các lỗi software, software cần được kiểm chứng (Verification) vàthẩm định (Validation) [9, 11]. Giám định cần phải có sự gia nhập của khách hàngnhằm kiểm tra xem software có thực sự thỏa mãn các yêu cầu của khách hànghay không. Kiểm chứng là kiểm tra software có được kiến trúc & thực thi đúngnhư đặc tả hay không. Mục tiêu chính của tiến triển software là phải làm saotạo ra được những sản phầm software có chất lượng đảm bảo nhất. Để giúp làmđược điều đó kiểm chứng software là phần chẳng thể thiếu. Kiểm chứng phầnmềm giúp làm giảm bớt lỗi software tới mức có thể chấp thuận được. Chínhvì vậy, nó có vai trò đặc biệt quan trọng trong toàn thể quy trình tiến triển phầnmềm & trong nghề công nghệ software hiện tại. Chính vì vậy, trong côngnghệ software, kiểm chứng software luôn lôi kéo được mối quan tâm của rấtnhiều nhà tìm hiểu. Việc viết tập hợp các ca kiểm thử (check cases) là một phầnquan trọng chẳng thể thiếu trong mẹo kiểm thử software. Tập hợp cácca kiểm thử chính xác giúp giảm bớt tối đa các lỗi, giảm thời gian tìm kiếm lỗi,tạo thành được các software tốt, tính ổn định cao.1.2. Bài viết nghiên cứuKiểm thử là công đoạn trọng yếu trong công cuộc tiến triển software. Có rấtnhiều lý do gây ra lỗi trong software, nó nằm ở toàn bộ các giai đoạntrong quy trình tiến triển software, & lập trình cũng là một trong số các giaiđoạn đó. Lỗi hiện ra do lập trình gây ra là hoàn toàn dễ hiểu, trong giai đoạn đầucủa nghề công nghiệp software, tiến triển software cũng có nghĩa là lậptrình, việc lập trình được thực hiện hoàn toàn thủ công, chính vì như thế lỗi gây ra dolập trình là cốt yếu. Ngày nay, lập trình chỉ là một giai đoạn trong quá trìnhphát triển software, được bổ trợ bởi nhiều dụng cụ lập trình thời thượng, thành ra việclập trình đã trở nên nhẹ nhõm hơn, bên cạnh đó không phải chính vì vậy mà lỗi lập trìnhlại mất đi. Người ta vận dụng rất là nhiều kỹ thuật trong kiểm thử nhằm mục tiêuthiết kế ra các ca kiểm thử có khả năng phát xuất hiện nhiều lỗi nhất trong chươngtrình. Không những thế, trên thực tiễn vẫn có thể tồn tại các nhánh không được chạy quakhi hàm hoặc một phương pháp được thực thi. Những nhánh đó có thể là vônghĩa nhưng cũng có thể là nơi tiềm tàng rất là nhiều lý do gây ra lỗi. Chính vì như vậy,tất cả chúng ta cần phải có mẹo xác nhận có hay không tồn tại các nhánh chưaduyệt qua trong chương trình, nếu có thì nhắc nhở cho người tiến triển kiểm travà giải quyết. Trong bài viết luận văn sẽ tìm tòi các tiêu chí bao phủ [6] mãnguồn của bộ check căn bản nhưng rất mạnh khỏe như tiêu chí bao phủ lệnh(statement coverage), bao phủ nhánh (branch coverage), bao phủ điều kiện(condition coverage) nhằm giúp xây dựng các ca kiểm thử tốt phát hiện nhánhchưa được phủ trong mã nguồn đang xét. Không những thế trong luận văn cũng đềxuất xây dựng một dụng cụ auto kiểm tra độ phủ của bộ dữ liệu kiểm thửthỏa mãn một tiêu chí dựa theo dụng cụ kiểm chứng Java Pathfinder. Đầu vàocủa dụng cụ là một hàm hay một phương pháp cần kiểm tra, xây dựng đồ thịluồng điều khiển, tiến hành xây dựng các ca kiểm thử. Sử dụng dụng cụ JavaPathfinder bổ trợ ghi lại từng dòng lệnh được chạy trong công cuộc kiểm thử vớibộ các ca kiểm thử đã xây dựng. Sau đó dụng cụ so sánh dữ liệu ghi được vớicác nhánh trong đồ thị luồng điều khiển, xác nhận được những nhánh nào tronghàm, trong phương pháp chưa được phủ, hiển thị kết quả nhắc nhở cho lập trìnhviên. Dụng cụ sẽ giúp công cuộc kiểm tra độ phủ trong kiểm thử đơn vị thực hiệnnhanh chóng, kết quả hiển thị trực quan hơn nhằm nhận xét các ca kiểm thử vàhàm đang xét.1.3 Kết cấu luận vănPhần còn sót lại của luận văn có cấu tạo như sau:Chƣơng 2: Trình bày tri thức về kiểm thử software, kế sách kiểm thửđơn vị với kỹ thuật rõ ràng và cụ thể là kiểm thử luồng điều khiển trong kiểm thử hộptrắng.Chƣơng 3: Giới thiệu về dụng cụ kiểm chứng JavaPathfinder, các kiến trúcchung về JPF, thành phần mở rộng của JPF & cách kiểm tra độ phủ của bộ dữliệu kiểm thử thông qua chức năng trong lớp CoverageAnalyzer.Chƣơng 4: Đề nghị mẹo kiểm tra độ phủ của bộ dữ liệu kiểm thử dựatrên dụng cụ Java Pathfinder. Bài viết của mẹo là xây dựng dụng cụ đođộ phủ ở mức kiểm thử đơn vị sử dụng khả năng lưu vết chương trình của JPF.Chƣơng 5: Thí nghiệm & nhận xét kết quả đạt được. Trong chương nàychúng tôi nêu rõ cách seting dụng cụ JPF, ứng dụng chức năng của JPF & cài đặtthêm mã nguồn để xây dưng dụng cụ kiểm tra độ phủ. Không những thế http://phptravels.vn/ sửdụng dụng cụ đã xây dụng để kiểm tra độ phủ của bộ check thông qua các chẳng hạn từđó rút ra đánh giá nhận xét về mã nguồn cũng như các ca kiểm thử đã viết.CHƢƠNG 2- CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ2.1 Định nghĩa kiểm thử phần mềmKiểm thử software là công cuộc thực thi hệ thống hoặc chương trình để kiểmtra xem hệ thống có đúng với đặc tả, kiến trúc hay không. Kiểm thử phần mềmđồng nghĩa với việc tìm thấy những lỗi tiềm tàng chưa được phát hiện, một cách sớmnhất & bảo đảm rằng những lỗi đó đã được sửa, chứ không làm công việc chuẩnđoán lý do gây ra lỗi hay fix lỗi đã phát hiện được[4].Mục đích của kiểm thử software là kiến trúc một hoặc chuỗi các ca kiểm thửcó khả năng phát hiện được lỗi cao. Để nhận được kết quả tốt, hoạt động kiểm thửcần được chuẩn bị tốt về sách lược, kiến trúc & dữ liệu cho mỗi ca kiểm thử. Đâychính là đầu vào cho việc kiểm thử, còn đầu ra chính là ebook giải trình kiểmthử, đặt ra được các thông tin về mục đích của kiểm thử, dữ liệu đầu vào, dữliệu đầu ra đợi mong, dữ liệu đầu vào thực tiễn…2.2. Quy trình kiểm thử phần mềmQuy trình kiểm thử software bao gồm các bước như lập sách lược kiểmthử, thiết kê các trường hợp kiểm thử, sắp xếp nhân công kiểm thử, đo đạc, đánhgiá sản phẩm để xác định sản phẩm có thể được đặt ra sử dụng hay chưa. Trongđó: Công đoạn lập sách lược kiểm thử [2,3] bao gồm các bước như xác địnhhoạt động cần thực hiện, mẹo thực hiện, mục đích kiểm thử dựa vàođặc tả yêu cầu, đặc tả tính năng…, phạm vi kiểm thử, mẹo kiểm thử,nguồn tài nguyên thiết yếu, thời gian biểu cho hoạt động kiểm thử, ebook thamkhảo. Công đoạn kiến trúc các ca kiểm thử là công đoạn trọng yếu nhất, bao gồmcác bước xác nhận dữ liệu đầu vào & đầu ra cho hoạt động kiểm thử cùng cáccâu lệnh cần thực hiện. Trong suốt công cuộc kiến trúc ca kiểm thử, yêu cầu hệthống phải được tìm hiểu một cách cẩn trọng, các chức năng của hệ thốngphải được xác nhận một cách cụ thể & các hành vi của ca kiểm thử cũng cầnđược khái niệm cụ thể. Sắp đặt nhân công kiểm thử: việc kiểm thử cần được tiến hành một cách độclập giữa các nhóm kiểm thử sau đó thu thập kết quả của từng nhóm, so sánh vớinhau & đặt ra tổng kết cuối cùng. Việc kiểm thử thường được tiến hành ở nhiềucấp độ khác nhau như kiểm thử đơn vị, kiểm thử tích hợp hay kiểm thử hệthống…, xuyên suốt trong vòng đời tiến triển của software. Ở mỗi cấp độkiểm thử nên có từng nhóm biệt lập chẳng hạn ở cấp độ kiểm thử đơn vị thì chínhngười lập trình lại đóng vai trò của người kiểm thử, ở cấp độ kiểm thử tích hợpđược thực hiện với các kỹ sư kiểm thử tích hợp hệ thống, họ là những người cókiến thức về chính sách xây dựng, tích hợp những hệ thống lớn…2.3 Kiểm thử đơn vị2.3.1 Kiểm thử đơn vị trong vòng đời tiến triển phần mềmQuy trình kiểm thử được thực hiện ở nhiều cấp độ khác nhau trong vòng đờiphát triển software, bao gồm kiểm thử hoàn toàn hoặc kiểm thử một phần hệthống. Mỗi hệ thống software thường trải qua bốn cấp độ kiểm thử là kiểm thửđơn vị ( unit testing), kiểm thử tích hợp ( integration testing), kiểm thử hệ thống( system testing) & kiểm thử chấp thuận ( acceptance testing) trước khi được đưavào triển khai thực tiễn. Trong số đó chỉ có kiểm thử chấp thuận được thực hiện bởikhách hàng, còn ba loại kiểm thử trước hết đều được thực hiện bởi các nhóm pháttriển trong đơn vị sản xuất software. Bốn loại kiểm thử trên kết phù hợp với nhautạo thành mô hình chữ ?.Hình 2.1: Mô hình kiểm thử chữ VTrong kiểm thử đơn vị, người lập trình đóng luôn vai trò của người kiểmthử, họ sẽ kiểm tra từng bộ chương trình riêng rẽ như hàm, thủ tục, lớp, chứcnăng một cách độc lập. Sau thời điểm bảo đảm rằng các bộ chương trình đó làm việctốt trong phạm vị cho phép thì các mô đun sẽ được phối hợp lại thành các hệthống con to hơn. Có hai nguyên nhân chính cho việc tiến hành kiểm thử đơn vị mộtcách độc lập:Trước nhất, khi tiến hành kiểm thử đơn vị một cách biệt lập, nếu lỗi được tìmthấy thì nó có thể sửa một cách đơn giản, do chúng có thể được xác nhận rõ ràngtrong bộ chương trình nào & dữ liệu đầu vào cho từng bộ chương trình cũng làYêu cầu nghiệp vụThiết kế cấp độcaoThiết kế cấp độ thấpMã nguồnKiểm thử đơn vịKiểm thử tích hợpKiểm thử hệ thốngKiểm thử chấp nhậnđơn giản. Nếu nhiều bộ chương trình được phối hợp lại với nhau để kiểm thử, thìngười kiểm thử sẽ phải tạo thành dữ liệu kiểm thử không những cho từng bộ chươngtrình, mà còn phải cho cả mối quan hệ giữa các bộ chương khác với nhau.Thứ hai, trong suốt công cuộc thực thi kiểm thử đơn vị, việc thực thi từng bộchương trình một cách riêng rẽ có thể bảo đảm việc thực thi từng đường dẫnriêng lẻ nhiều nhất có thể. Điều đó dẫn đến việc nhiều đường đi độc lập nhất cóthể được kiểm tra. Khi thực hiện kiểm thử đơn vị, người kiểm thử phải đảm bảođược một số phép tắc như thực thi mọi dòng lệnh, biểu thức điều kiện, vònglặp…& bảo đảm rằng nó không chứa các lỗi có thể tìm ra được trước khiđược kết phù hợp với các bộ khác.2.3.2 Một số loại kiểm thử đơn vịKiểm thử đơn vị gồm hai loại căn bản là kiểm thử đơn vị tĩnh( static unittesting) & kiểm thử đơn vị động (dynamic unit testing) Kiểm thử đơn vị tĩnhVới kiểm thử đơn vị tĩnh, mã nguồn được nhìn nhận nhờ hai kỹ thuật chính làwalkthrough & inspection. Trong số đó, theo Edward Yourdon [5] thì kỹ thuậtwalkthrough được thực hiện theo cách Author của chương trình sẽ hướng dẫnnhóm kiểm thử thông qua việc thực thi chương trình một cách rõ ràng và cụ thể với nhữngkịch bản đã được giàn dựng từ trước. Theo Michael Fagan [5] thì kỹ thuậtinspection có nghĩa là trong mỗi bước kiểm tra, từng nhóm sẽ nhận xét sản phẩmbằng cách so sánh với cốt chuyện kiểm thử đã được chuẩn bị từ trước. Cả hai kỹthuật trên đều là nhận xét mã nguồn theo hướng ngữ nghĩa & không đánh giángười tạo thành mã nguồn.Quy trình kiểm thử đơn vị tĩnh được thực hiện lần lượt qua các bước: chuẩnbị cốt chuyện, nhân công -> chuẩn bị thắc mắc, yêu cầu biến đổi -> kiểm tra, đánh giámã nguồn -> Author mã nguồn sửa những vấn đề biến đổi -> kiểm tra lại -> kếtthúc. Kiểm thử đơn vị độngKiểm thử đợn vị động là kỹ thuật kiểm thử dựa trên việc thực thi từng bộchương trình một cách độc lập trong môi trường thực thi được mô phỏng. Nógồm có hai thành phần chính là check driver & stubs. Check driver là một chương trình gọi tới các bộ để kiểm thử. Các bộ đó sẽthực thi với dữ liệu đầu vào được ra đời từ driver & trả lại giá trị cho driver.Driver sẽ so sánh đầu ra thực tiễn với đầu ra đợi mong rồi báo kết cáo lại kết quảkiểm thử. Driver không những giữ vai trò biên dịch chương trình mà nó còn cungcấp cả dữ liệu đầu vào cho kiểm thử theo định dạng mong chờ. Stubs là chương trình con mô phỏng, thay thế cho mỗi bộ chương trìnhnào đó được gọi đến từ bộ chương trình đang được kiểm tra. Mỗi stub đảm nhiệmhai trách nhiệm, trước hết nó nêu ra vai trò của chính nó làm trách nhiệm bằng cách inra các thông điệp. Thứ hai, nó trả lại giá trị mong chờ cho bộ chương trình gọitới nó, giúp cho bộ đó có thể tiếp tục thực thi.Trong kiểm thử đơn vị động, có một số kỹ thuật giúp cho việc lựa chọn dữliệu đầu vào kiểm thử đạt hiệu quả cao như kiểm thử luồng điều khiển (controlflow testing-), kiểm thử luồng dữ liệu (data flow testing), kiểm thử miền giá trị(tên miền testing)… Kiểm thử luồng điều khiển được thực hiện thông qua một số bước như vẽđồ thị luồng điều khiển từ bộ chương trình, lựa chọn một vài cốt chuyện kiểm thửluồng điều khiển, xác nhận đường đi trong đồ thị luồng điều khiển đáp ứng điềukiện của cốt chuyện kiểm thử, xác nhận biểu thức từ các đường đi được lựa chọnrồi ra đời dữ liệu phục vụ cho việc kiểm thử. Kiểm thử luồng dữ liệu: trong kiểm thử luồng dữ liệu trước hết cũng phảivẽ được đồ thị luồng dữ liệu, sau đó đến việc lựa chọn các cốt chuyện kiểm thửluồng dữ liệu, xác nhận đường đi trong đồ thị luồng dữ liệu đáp ứng kịch bảnkiểm thử, xác nhận biểu thức từ các đường đi được lựa chọn rồi ra đời dữ liệukiểm thử. Kiểm thử miền giá trị: trong cả hai kỹ thuật kiểm thử luồng điều khiển vàkiểm thử luồng dữ liệu đề không có chính sách phát hiện được lỗi, điều này có thểđược khắc phục trong kỹ thuật kiểm thử miền giá trị(domail testing). Trong cáctiếp cận này, mục lục các lỗi miền giá trị sẽ được liệt kê, sau đó dữ liệu kiểmthử sẽ được lựa chọn trong mục lục đó để phát hiện lỗi. Cách thức này sẽphải lệ thuộc rất là nhiều vào kinh nghiệm của người kiểm thử.2.4 Các kỹ thuật kiểm thử phần mềmTheo John ?. Mc Gregor[13] thì các kỹ thuật kiểm thử cũng giống nhưnhững dụng cụ được kiến trúc nhằm bảo đảm rằng toàn bộ các góc cạnh của hệthống đều được thăm dò qua. Những kỹ thuật đó chính là dụng cụ đem lại hiệuquả, bảo đảm chất lượng cho hệ thống. Có hai loại kỹ thuật kiểm thử phần mềmchính là kỹ thuật kiểm thử hộp đen (kiểm thử tính năng) & kỹ thuật kiểm thửhộp trắng( kiểm thử cấu tạo).2.4.1 Kỹ thuật kiểm thử hộp đenKỹ thuật kiểm thử hộp đen (Black- box testing) có cách gọi khác là kiểm thửhướng dữ liệu (data – driven) hay là kiểm thử hướng về phía ra (input/output driven)nhằm mục tiêu tìm thấy các lỗi về tính năng, khả năng sử dụng, các lỗi về giaodiện, lỗi truy cập dữ liệu bên ngoài, lỗi khởi tạo, hay chấm dứt & lỗi liên quan tớicác yêu cầu phi tính năng khác. Với kỹ thuật kiểm thử hộp đen, người kiểm thửxem hệ thống như là hộp đen, hoàn toàn không quan tâm tới cấu tạo dữ liệu vàhành vi bên trong hệ thống, họ chỉ cần quan tâm đến việc phát xuất hiện nhữnghành vi không đúng với đặc tả của hệ thống, chính vì thế dữ liệu đầu vào cho kiểm thửhộp đen chính là ebook đặc tả yêu cầu của software. Kiểm thử hộp đenthường được vận dụng trong các công đoạn sau của kiểm thử hệ thống do nókhông cần quan tâm tới cấu tạo, mã nguồn của hệ thống, chính vì thế tất cả chúng ta khôngthể đợi mong khả năng kiểm tra hết toàn bộ các lỗi trong hệ thống nhờ vận dụng kỹthuật này. Một số kỹ thuật thường được vận dụng trong kiểm thử hộp đen như: Phân hoạch tương tự: là kỹ thuật phân tách miền giá trị đầuvào(input tên miền) thành lập các miền con dùng cho việc lựa chọn dữ liệu kiểmthử. Mỗi miền con được gọi là phân hoạch, dữ kiệu trong cùng một phân hoạchthì có tác động tới hệ thống như nhau khi kiểm thử, có thể là cùng hợp lệ hoặccùng không hợp lệ, chính vì thế, ta thường lựa chọn tối thiểu một tài nguyên điển hìnhtrong từng phân hoạch để làm dữ liệu đầu vào cho việc kiểm thử. Ưu thế củaphương pháp phân hoạch tương tự chính là giảm bớt số lượng dữ liệu cầnkiểm tra so với hệ thống mà vẫn bao phủ được một miền dữ liệu đầu vào khổnglồ, nó không hạn chế điều kiện vào, chính vì như thế ta cũng có thể sử dụng kỹ thuậtnày cho miền giá tri đầu ra. Nghiên cứu giá trị biên: là kỹ thuật lấy sáng kiến dựa theo phân hoạch tươngđương, sau thời điểm phân hoạch miền dữ liệu đầu vào thành các miền con, ta lựa chọnnhững dữ liệu ở gần biên (cả trong & ngoài lớp tương tự) làm dữ liệu kiểmthử. Từ những dữ liệu kiểm thử đó ta có thể tìm ta được những lỗi gây ra bởiviệc thực thi biên chưa đúng đắn. Trên thực tiễn, các nhà kiến trúc cũng như ngườilập trình thường có khuynh hướng bỏ qua các điều kiện biên, chính vì thế khả năng lỗi xuấthiện ở gần biên là rất lớn. Bảng quyết định: do điểm yếu chính của kiểm thử dựa trên các lớptương đương là nó chỉ có khả năng kiểm tra được từng dữ liệu đầu vào riêng lẻmà không kiểm tra được các một tổ hợp các điều kiện cầu kỳ. Chính vì như thế, ta có thểsử dụng bảng quyết định để giải quyết nhiều dữ liệu đầu vào của nhiều lớp tươngđương khác nhau đồng thời. Kết cấu chung của bảng quyết định thường bao gồmtập các điều kiện (lý do), tập các tác động (hệ lụy) & tập các nguyên tắc.Dữ liệu kiểm thử sẽ được lựa chọn theo từng điều kiện của bảng & kết quả thựctế sẽ được đối chiếu với kết quả mong chờ. Chính vì vậy mà mỗi nguyên tắc trongbảng quyết định sẽ tương ứng với một dữ liệu đầu vào cho kiểm thử. Kiểm thử hốt nhiên: là mẹo lựa chọn hốt nhiên dữ liệu đầuvào cho kiểm thử từ miền giá trị. Do dữ liệu đầu vào cho kiểm thử được lựachọn hốt nhiên nên ta sẽ không xác nhận được dữ liệu đầu ra mong chờ,chính vì như thế kỹ thuật này đòi hỏi những kế sách kiểm thử tốt để có thể đánhgiá được độ đúng đắn của kết quả kiểm thử thông qua việc so sánh với đặc tả hệthống. Ưu thế của kiểm thử hốt nhiên chính là khả năng đơn giản ước đoánđược độ tin cậy của software dựa trên đầu ra của kiểm thử. Đoán lỗi: là kỹ thuật cốt yếu dựa trên kinh nghiệm của người kiểm thử đểdự đoán loại, vị trí có thể xảy ra lỗi trong hệ thống. Kỹ thuật này rất hiệu quả đốivới những loại lỗi chẳng thể bao phủ được.2.4.2 Kỹ thuật kiểm thử hộp trắngKỹ thuật kiểm thử hộp trắng (white-box testing) nói một cách khác là kiểm thử hộpthủy tinh (glass-box testing) hay nói một cách khác là kiểm thử hộp trong suốt (clear-boxtesting) cho phép kiểm tra cấu tạo bên trong của hệ thống, bảo đảm toàn bộ cáccâu lệnh, các biểu thức điều kiện được kiểm tra tối thiểu một lần. Cũng giống nhưviệc kiểm tra dữ liệu đầu vào trong kiểm thử hộp đen, việc kiểm tra các đườngdẫn trong kiểm thử hộp trắng cũng cần phải được tiến hành một cách triệt để. Tuynhiên, điều này là hoàn toàn không khả thi, do số lượng đường dẫn logic bêntrong mỗi chương trình nếu chứa vòng lặp có thể là vô cùng lớn.Việc tiến hành kỹ thuật kiểm thử hộp trắng phải bảo đảm được một sốnguyên tắc như mọi đường dẫn độc lập phải được thử hiện tối thiểu một lần, tạimỗi biểu thức điều kiện, các giá trị true, false cũng cần phải được trổ tài ít nhấtmột lần, các vòng lặp cùng cần được kiểm tra tại các giá trị biên & các giá trịtrung gian, trong phạm vị hoạt động của chúng & cuối cùng là mọi cấu tạo dữliệu bên trong phải bảo đảm tính chính xác, đúng đắn.Kiểm thử hộp trắng thường chăm chú vào hai góc cạnh chính là kiểm thửluồng điều khiển & kiểm thử luồng dữ liệu. Kiểm thử luồng điều khiển hướngtới việc thực thi chương trình, đi từ lời hướng dẫn này cho tới lời hướng dẫn khác.Luồng dữ liệu liên quan tới sự biến đổi giá trị của các biến hay các hằng số. Quátrình tiến hành kiểm thử hộp trắng thường được thực hiện ngay tại mỗi bộchương trình biệt lập mà người lập trình viết ra.2.5 Ca kiểm thử & kiến trúc ca kiểm thử2.5.1 Khái niệm ca kiểm thửCó nhiều định nghĩa về ca kiểm thử khác nhau dựa trên quy mô, tổ chức. Tuynhiên, chúng đều có đặc điểm giống nhau như là bao gồm đầu vào, đầu ra mongmuốn & các điều kiện thực thi. Theo ebook thuật ngữ của ISTQB về kiểm thửthì ca kiểm thử là một tập hợp các giá trị đầu vào, các điều kiện tiên quyết, điều10kiện thực thi, kết quả đợi mong, các điều kiện chấm dứt. Nó được xây dựng chomục đích kiểm thử biệt lập chẳng hạn như thực hiện một đường dẫn chương trìnhriêng biệt hoặc để kiểm tra lại đúng với yêu cầu của đặc tả yêu cầu hay chưa.Dữ liệu đầu ra mong chờ sau thời điểm thực thi chương trình là một thực thểphức tạp, nó có thể bao gồm các giá trị như: giá trị được ra đời từ chương trình,các hiện trạng biến đổi của chương trình, các hiện trạng biến đổi của nền tảng dữliệu… & được xác nhận trong công cuộc kiến trúc ca kiểm thử nhờ việc hiểu đặc tảyêu cầu của chương trình.2.5.2 Tiêu chí kiến trúc ca kiểm thửTrong kiểm thử software, một trong những vấn đề mấu chốt nhất chínhlà việc kiến trúc ra các ca kiểm thử có khả năng tìm thấy được nhiều lỗi nhất mà chiphí rẻ nhất. Thông thường, mẹo có khả năng tìm thấy nhiều lỗi nhất có thểchính là kiểm tra toàn bộ các đầu vào của chương trình, bên cạnh đó này là điều khôngthể do những ràng buộc về mặt thời gian, ngân sách & nhân công. Có một vài tiêuchuẩn kiến trúc ca kiểm thử thường được vận dụng trong kiểm thử software:Bảng 2.1: Các tiêu chí kiến trúc ca kiểm thửKiểm thử hộp đenKiểm thử hộp trắngPhân lớp tương đươngBao phủ lệnhPhân tích giá trị biênBao phủ nhánh(quyết định)Bảng quyết địnhBao phủ điều kiệnĐoán lỗiBao phủ đa điều kiệnTrong kỹ thuật kiểm thử hộp trắng, tiêu chí kiến trúc ca kiểm thử baophủ câu lệnh phải bảo đảm mọi câu lệnh trong chương trình được thực hiện ítnhất một lần. Bao phủ lệnh hoàn toàn là tiêu chí bao phủ yếu nhất trong kiểmthử chương trình. Việc lựa chọn đường đi trong tiêu chí này có thể tuân theomột số nguyên tắc như lựa chọn đường đi ngắn nhất, lựa chọn đường đi có chiều dàităng dần, có thể duyệt qua vòng lắp một vài lần nếu thiết yếu. Tiêu chí baophủ điều kiện phải bảo đảm rằng mỗi điều kiện trong một quyết định phải đượcduyệt qua tối thiểu một lần. Còn trong tiêu chí bao phủ đa điều kiện, tất cảnhững sự phối hợp của các kết quả điều kiện có thể có tại mỗi quyết định & cácđiểm vào phải được duyệt qua tối thiểu một lần.2.5.3 Kiến trúc ca kiểm thử trong kiểm thử luồng điều khiểnĐồ thị luồng điều khiển( Control flow graph-CFG)Đồ thị luồng điều khiển là sự diễn đạt đồ họa của một bộ chương trình. Có baký kiệu chính hay được sử dụng trong đồ thị luồn điều khiển là hình chữ nhật11miêu ra các biểu thức toán học, mỗi biểu thức tính toán được gán nhãn bằng mộtsố nguyên, hình thoi diễn đạt các quyết định với hai nhánh tương ứng các quyếtđịnh đúng, sai, hình tròn diễn đạt điểm thống nhất của các quyết định. Đồ thị luồngđiều khiển có thể xây dựng một cách thủ công hoặc trình biên dịch đã được thiếtlập để auto ra đời từ bộ chương trình. Đƣờng đi trong đồ thị luồng điều khiểnĐường đi (Execution path) trong đồ thị luồng điều khiển là một chuỗi cácbiểu thức tính toán, các điểm quyết định từ điểm đầu vào cho đến điểm đầu ra.Theo Ƭ. Ĵ. McCabe [13], số đường đi ứng với đồ thị luồng điều khiển được tínhbằng một trong các mẹo sau:- Số cạnh – số đỉnh + 2- Số đỉnh quyết định + 1Sau khi có được các đường đi của đơn vị chương trình cần kiểm thử, với mỗiđường đi, tất cả chúng ta sẽ sinh một ca kiểm thử tương ứng.Mục tiêu của mẹo kiểm thử luồng điều khiển là bảo đảm mọi đườngđi trong đồ thị luồng điều khiển của đơn vị software cần kiểm thử đều chạyđúng. Không những thế để đạt được mục tiêu này thì công sức & thời gian bỏ ra rấtlớn. Chính vì như vậy, nên chắt lọc & kiểm thử số check case ít nhất mà kết quả độ tin cậytối đa. Nhưng làm sao xác nhận được số check case ít nhất nào có thể đem đến kếtquả có độ tin cậy tối đa. Phủ kiểm thử là một định nghĩa liên quan chặt chẽ đếnvấn đề trên. Phủ kiểm thử (Coverage) : là tỉ lệ các thành phần thực sự được kiểmthử đối với tổng thể sau thời điểm đã kiểm thử các check case được chọn. Phủ càng lớn thìđộ tin cậy càng cao[1]. Bộ check case cần đáp ứng một số tiêu chí lựa chọnđường đi để đạt mức phủ thiết yếu. Tiêu chí lựa chọn đƣờng điTrong mỗi đồ thị luồng điều khiển, có thể có rất là nhiều đường đi khác nhauvì thế người kiểm thử phải có mẹo lựa chọn một số ít các đường đitrong chương trình mà vẫn phát hiện lỗi trong mã nguồn một cách hiệu quả. Mộtquy tắc thường được vận dụng trong việc tiến hành kiểm thử dựa trên đồ thị luồngđiều khiển như toàn bộ lời khởi tạo trong chương trình đều được thực hiện ít nhấtmột lần, không tạo thành nhiều dữ liệu đầu vào kiểm thử cho những đường đi đượcthực hiện nhiều lần. Không những thế, nếu mỗi lần thực thi đường đi của chương trìnhlại update lại hiện trạng của hệ thống chẳng hạn như hiện trạng DataBase của hệthống thì tất cả chúng ta nên tạo thành nhiều dữ liệu đầu vào kiểm thử cho những lần thựcthi đó. Có một số tiêu chí lựa chọn đường đi như: Tiêu chí bao phủ các câu lệnh12Bộ check case kiểm thử bảo đảm sao cho mỗi lệnh được thực thi tối thiểu mộtlần. Trong kiến trúc check case ta luôn nỗ lực bao phủ tối đa câu lệnh trong mãnguồn với số check case tối thiểu có thể. Bao phủ câu lệnh sẽ nhận thấy các câu lệnhtrong một phương pháp hay trong một lớp đã được thực thi. Đây là một phươngpháp đo đơn giản để tìm thấy số câu lệnh đã được thực thi trong tổng số các câulệnh mã nguồn. Cho nên lợi nhuận của bao phủ câu lệnh là khả năng tìm thấy các dòngcode không được thực thi Tiêu chí cả bao phủ nhánhTiêu chuẩn bao phủ nhánh là kiểm thử sao cho mỗi điểm quyết định đượcthực hiện tối thiểu một lần trong cả hai trường hợp true & false. Điều kiện khôngcần chia nhỏ nếu là điều kiện cầu kỳ gồm nhiều điều kiện con. Một nhánh làmột tổng kết logic của một điều kiện, thành ra bao phủ nhánh đơn giản là đo kếtluận logic nào đã được kiểm tra. Cách thức bao phủ này suy xét mã nguồnsâu sắc hơn là mẹo bao phủ câu lệnh. Xác nhận số nhánh có trong mộtphương thức là một việc dễ làm. Tổng kết kiểu boolean dĩ nhiên có hai kếtluận logic là “true” hoặc “false” thành ra chương trình có ռ điều kiện sẽ có 2nhánh. Cách thức bao phủ nhánh vẫn bao hàm cả bao phủ câu lệnh tuy nhiênnó đã loại bỏ được một số giới hạn có ở bao phủ câu lệnh. Tiêu chí bao phủ điều kiệnGiống như bao phủ nhánh, kiểm tra bao phủ điều kiện cài đặt đảm bảokiểm tra từng điều kiện. Không những thế không giống như bao phủ nhánh, bao phủđiều kiện bảo đảm kiểm tra toàn bộ các điều kiện con của từng điểm quyết địnhđều được thực hiện tối thiểu một lần trong cả trường hợp true & false. Với cácđiều kiện cầu kỳ (chứa nhiều điều kiện con căn bản), việc chỉ quan tâm đến giátrị đúng sai là không đủ để kiểm tra tính chính xác của chương trình ứng với điềukiện cầu kỳ này. Chẳng hạn, nếu một điều kiện cầu kỳ gồm hai điều kiện con cơbản, tất cả chúng ta có bốn trường hợp cần kiểm thử chứ không phải hai trường hợpđúng sai như trong mẹo bao phủ nhánh. Với các hàm hay phương thứccó yêu cầu cao về tính chính xác, việc tuân thủ bao phủ điều kiện là hết sức cầnthiết. Điều kiện để bảo đảm tính phủ đó là các điều kiện con thuộc các điềukiện cầu kỳ tương ứng với các điểm quyết định trong đồ thị luồng điều khiểncủa phương pháp cần kiểm thử đều được thực hiện tối thiểu một lần cả hai nhánhđúng & sai. Lựa chọn đường đi kiểm thử vòng lặpVòng lặp là nền móng cho đa phần các thuật toán được seting trong phầnmềm. Không những thế, tất cả chúng ta thường ít quan tâm đến nó khi thực hiện việc kiểmthử software. Kiểm thử vòng lặp là một kỹ thuật kiểm thử hộp trắng mà tập13trung trên tính hợp lệ của các cấu tạo lặp. Khi tiến hành kiểm thử các đơn vịchương trình với bao phủ điều kiện thì mẹo kiểm thử luồng điều khiểnkhông thể kiểm thử các vòng lặp hiện ra trong các đơn vị chương trình. Lý dolà các đường đi ra đời từ đồ thị luồng điều khiển không chứa các vòng lặp[1].Trong thực tiễn, lỗi hay xảy ra ở các vòng lặp. Vì nguyên nhân này, tất cả chúng ta cần sinhthêm các ca kiểm thử cho các vòng lặp nhằm giảm tỷ lệ lỗi của các chươngtrình. Việc xây dựng các trường hợp kiểm thử cho mỗi loại vòng lặp cần thựchiện như sau: Vòng lặp đơnVòng lặp mà trong thân không hiện ra thêm vòng lặp nào khác gọi làvòng lặp đơn. Với vòng lặp đơn trong đó И là số lần lặp tối đa, các trường hợpkiểm thử sau được sử dụng để kiểm tra mỗi điều kiện sau:- Bỏ qua vòng lặp hay số lần lặp bằng 0- Lặp 1- Lặp 2- Lặp ʍ lần trong đó ʍ < И- Lặp И-1 lần- Lặp И lần- Lặp И+1 lầnHình 2.2: Sơ đồ vòng lặp while , do while Vòng lặp lồng nhauVòng lặp mà trong thân của nó chứa vòng lặp khác gọi là vòng lặp lồngnhau. Nếu tất cả chúng ta mở rộng mẹo kiểm thử vòng lặp đơn cho vòng lặplồng nhau thì các kiểm thử có thể sẽ tăng theo mức tiến triển vòng lặp. Điều nàycó thể tạo thành một số không thực tiễn các trường hợp kiểm thử.14Hình 2.3: Sơ đồ miêu tả vòng lặp lồng nhauChính chính vì vậy, một cách tiếp cận đệ qui như sau sẽ cắt giảm số trường hợpkiểm thử:- Khởi đầu tại vòng lặp trong cùng.- Xây dựng các kiểm thử vòng lặp đơn cho vòng lặp trong cùng, trong khiđó giữ vòng lặp ngoài cùng tại các giá trị tham số lặp nhỏ nhất của chúng.- Lớn mạnh ra phía ngoài, xây dựng các kiểm thử cho vòng lặp kế tiếp,nhưng giữ toàn bộ các vòng lặp bên ngoài với giá trị nhỏ nhất & các vòng lặp lồngnhau khác giá trị “đặc biệt”. Tiếp tục cho đến khi toàn bộ các vòng lặp được kiểmthử. Vòng lặp liền kềNếu các vòng lặp liền kề nhau là độc lập thì chúng có thể được xem nhưhai vòng lặp đơn biệt lập, sử dụng mẹo kiểm thử vòng lặp đơn. Nếuvòng lặp thứ hai lệ thuộc vào vòng lặp trước(chẳng hạn, biến đếm của vòng lặp 1 làgiá trị khởi tạo của vòng lặp 2), thì xem chúng như các vòng lặp lồng nhau & sửdụng cách tiếp cận kiểm thử vòng lặp lồng nhau. Các bƣớc sinh dữ liệu kiểm thửSau khi xác nhận được đường đi dựa trên đồ thị luồng điều khiển, ta tiếnhành sinh dữ liệu đầu vào cho hoạt động kiểm thử. Với bộ dữ liệu đầu vào,chương trình sẽ thực thi theo đường đi đã lựa chọn. Trong công cuộc sinh dữ liệukiểm thử, ta cần xác nhận một số tham số như:15- Vector đầu vào là một tập dữ liệu đầu vào cho thủ tục, bao gồm các thamsố đầu vào cho thủ tục, giá trị các biến toàn cục, hằng số, các file, kết nốimạng,…- Predicate: biểu thức điều kiện tại các điểm quyết định- Xác nhận đường đi- path predicate expression: chứa tập các biểu thứcđiều kiện cùng với giá trị của biểu thức đó & thứ tự các biểu thức điềukiện gắn với một đường đi xác nhận nào đó.Sau thời điểm xác nhận được biểu thức chỉ định đường đi, tuyệt đối có thể ra đời dữliệu đầu vào cho kiểm thử thông qua chuỗi biểu thức đã xây dựng.

Xem Thêm  Liên kết HTML - Cách Chèn Liên kết đến Trang web bằng Mã HREF - liên kết đến mã html

Viết một bình luận