Thiết kế test-case trong kiểm thử phần mềm

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (507.75 KB, 57 trang )

KHOA CÔNG NGHỆ THÔNG TIN
ĐẠI HỌC THÁI NGUYÊN
Đề tài thực tập chuyên ngành:
MỤC LỤC
2
THIẾT KẾ TEST-CASE
TRONG KIỂM THỬ
PHẦN MỀM
Sinh viên thực hiện : Phạm Thị Trang
Lớp : ĐHCQ K4A
Giáo viên hướng dẫn : Nguyễn Hồng Tân
Bộ môn : Công nghệ phần mềm
Thái Nguyên, tháng 9 năm 2009
MỤC LỤC……………………………………………………………………………………………..2
DANH MỤC CÁC HÌNH………………………………………………………………………..4
LỜI NÓI ĐẦU……………………………………………………………………………………….5
TÓM TẮT NỘI DUNG……………………………………………………………………………6
CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM………………………….7
CHƯƠNG 2. THIẾT KẾ TEST – CASE…………………………………………………..21
CHƯƠNG 3. ÁP DỤNG…………………………………………………………………………42
KẾT LUẬN………………………………………………………………………………………….55
TÀI LIỆU THAM KHẢO………………………………………………………………………56
NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN……………………………………….57
3
DANH MỤC CÁC HÌNH
Hình 1.1 Sơ đồ các cấp độ kiểm thử…………………………………………………………12
Hình 2.1 Một chương trình nhỏ để kiểm thử ……………………………………………..23
Hình 2.2 Mã máy cho chương trình trong Hình 2.1…………………………………….27
Hình 2.3 Một mẫu cho việc liệt kê các lớp tương đương……………………………..31
Hình 2.4 Các ký hiệu đồ thị nguyên nhân – kết quả cơ bản………………………….35
Hình 2.5 Các ký hiệu ràng buộc……………………………………………………………….36

Nguyễn Hồng Tân, sự giúp đỡ nhiệt tình của các thầy cô trong bộ môn Công nghệ
5
phần mềm, và tất cả các bạn. Em hi vọng sẽ nhận được sự đóng góp ý kiến của các
thầy cô và các bạn để bản báo cáo được hoàn thiện hơn. Những đóng góp đó sẽ là
kinh nghiệm quý báu cho em. Và từ đó, em có thể tiếp tục phát triển đề tài này cho
đợt thực tập tốt nghiệp và đồ án tốt nghiệp sắp tới, cũng như cho công việc trong
tương lai.
Em xin chân thành cám ơn.
Sinh viên
Phạm Thị Trang
TÓM TẮT NỘI DUNG
Bản báo cáo được chia thành 3 chương với nội dung như sau:
• Chương 1: Tổng quan về kiểm thử phần mềm.
Chương này là cái nhìn tổng quan về kiểm thử phần mềm:
các khái niệm cơ bản về kiểm thử phần mềm, các quy tắc
trong kiểm thử, và các phương pháp kiểm thử phần mềm tiêu
biểu.
• Chương 2: Thiết kế test – case trong kiểm thử phần mềm.
Trong chương này, em đi tìm hiểu các phương pháp thiết kế
test – case có hiệu quả. Từ đó rút ra nhận xét về ưu nhược
điểm của từng phương pháp.
• Chương 3: Áp dụng.
Từ những phương pháp thiết kế test – case đã tìm hiểu trong
Chương 2, em áp dụng để xây dựng tập các test – case cho
một bài toán cụ thể : Thiết kế các test – case cho chương
trình “Tam giác”.
6
CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ
PHẦN MỀM
1.1 Các khái niệm cơ bản về kiểm thử phần mềm

1.1.1 Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới
những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía
cạnh nào đó của hệ thống hay thành phần đó. (Theo Bảng chú giải thuật ngữ
chuẩn IEEE của Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary of Software
Engineering Terminology).
Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm
lỗi. (Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm).
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ
phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung
cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm
hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay
khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm
trong nhiều ngành khác nhau. (Theo Bách khoa toàn thư mở Wikipedia).
Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiến
trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính
thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ
thứ gì không mong muốn. Đây là một pha quan trọng trong quá trình phát triển hệ
thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới
đã đáp ứng yêu cầu đặt ra hay chưa?
7
1.1.2 Các phương pháp kiểm thử
Có 2 phương pháp kiểm thử chính là: Kiểm thử tĩnh và Kiểm thử động.
1.1.2.1 Kiểm thử tĩnh – Static testing
Là phương pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả
bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà
không cần chạy chương trình. Kiểu kiểm thử này thường được sử dụng bởi chuyên
viên thiết kế người mà viết mã lệnh một mình.
Kiểm thử tĩnh cũng có thể được tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộ
bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch mà

xác nhận tính hợp lệ về cú pháp của chương trình.
1.1.2.2 Kiểm thử động – Dynamic testing
Là phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình để
điều tra trạng thái tác động của chương trình. Đó là kiểm thử dựa trên các ca kiểm
thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy các chương trình.
Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự
phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian. Trong kiểm thử
động, phần mềm phải thực sự được biên dịch và chạy. Kiểm thử động thực sự bao
gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có
như mong muốn hay không. Các phương pháp kiểm thử động gồm có kiểm thử Unit
– Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống – System
Tests, và Kiểm thử chấp nhận sản phẩm – Acceptance Tests.
1.1.3 Các chiến lược kiểm thử
Ba TRONG SỐ NHỮNG CHIẾN LƯỢC KIỂM THỬ THÔNG DỤNG NHẤT BAO
GỒM: KIỂM THỬ HỘP ĐEN, KIỂM THỬ HỘP TRẮNG, VÀ KIỂM THỬ HỘP XÁM.
8
1.1.3.1 Kiểm thử hộp đen – BLACK BOX TESTING
Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng
dữ liệu, hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là một “hộp
đen”. MỤC ĐÍCH CỦA BẠN LÀ HOÀN TOÀN KHÔNG QUAN TÂM VỀ CÁCH CƯ XỬ
VÀ CẤU TRÚC BÊN TRONG CỦA CHƯƠNG TRÌNH. THAY VÀO ĐÓ, TẬP TRUNG
VÀO TÌM CÁC TRƯỜNG HỢP MÀ CHƯƠNG TRÌNH KHÔNG THỰC HIỆN THEO CÁC
ĐẶC TẢ CỦA NÓ.
THEO HƯỚNG TIẾP CẬN NÀY, DỮ LIỆU KIỂM TRA ĐƯỢC LẤY CHỈ TỪ CÁC
ĐẶC TẢ.
Các phương pháp kiểm thử HỘP ĐEN
• PHÂN LỚP TƯƠNG ĐƯƠNG – EQUIVALENCE PARTITIONING.
• PHÂN TÍCH GIÁ TRỊ BIÊN – BOUNDARY VALUE ANALYSIS.
• KIỂM THỬ MỌI CẶP – ALL-PAIRS TESTING.
• KIỂM THỬ FUZZ – FUZZ TESTING.

• KIỂM THỬ DỰA TRÊN MÔ HÌNH – MODEL-BASED TESTING.
• Ma TRẬN DẤU VẾT – TRACEABILITY MATRIX.
• KIỂM THỬ THĂM DÒ – EXPLORATORY TESTING.
• KIỂM THỬ DỰA TRÊN ĐẶC TẢ – SPECIFICATION-BASE TESTING.
Kiểm thử dựa trên đặc tả TẬP TRUNG VÀO KIỂM TRA TÍNH THIẾT THỰC
CỦA PHẦN MỀM THEO NHỮNG YÊU CẦU THÍCH HỢP. DO ĐÓ, KIỂM THỬ VIÊN
NHẬP DỮ LIỆU VÀO, VÀ CHỈ THẤY DỮ LIỆU RA TỪ ĐỐI TƯỢNG KIỂM THỬ.
MỨC KIỂM THỬ NÀY THƯỜNG YÊU CẦU CÁC CA KIỂM THỬ TRIỆT ĐỂ ĐƯỢC
CUNG CẤP CHO KIỂM THỬ VIÊN MÀ KHI ĐÓ CÓ THỂ XÁC MINH LÀ ĐỐI VỚI DỮ
LIỆU ĐẦU VÀO ĐÃ CHO, GIÁ TRỊ ĐẦU RA (HAY CÁCH THỨC HOẠT ĐỘNG) CÓ
GIỐNG VỚI GIÁ TRỊ MONG MUỐN ĐÃ ĐƯỢC XÁC ĐỊNH TRONG CA KIỂM THỬ ĐÓ
9
HAY KHÔNG. KIỂM THỬ DỰA TRÊN ĐẶC TẢ LÀ CẦN THIẾT, NHƯNG KHÔNG ĐỦ
ĐỂ ĐỂ NGĂN CHẶN NHỮNG RỦI RO CHẮC CHẮN.
Ưu, nhược ĐIỂM
Kiểm thử HỘP ĐEN KHÔNG CÓ MỐI LIÊN QUAN NÀO TỚI MÃ LỆNH, VÀ
KIỂM THỬ VIÊN CHỈ RẤT ĐƠN GIẢN TÂM NIỆM LÀ: MỘT MÃ LỆNH PHẢI CÓ
LỖI. SỬ DỤNG NGUYÊN TẮC “ HÃY ĐÒI HỎI VÀ BẠN SẼ ĐƯỢC NHẬN”, NHỮNG
KIỂM THỬ VIÊN HỘP ĐEN TÌM RA LỖI MÀ NHỮNG LẬP TRÌNH VIÊN ĐÃ KHÔNG
TÌM RA. NHƯNG, MẶT KHÁC, NGƯỜI TA CŨNG NÓI KIỂM THỬ HỘP ĐEN
“GIỐNG NHƯ LÀ ĐI TRONG BÓNG TỐI MÀ KHÔNG CÓ ĐÈN VẬY”, BỞI VÌ KIỂM
THỬ VIÊN KHÔNG BIẾT CÁC PHẦN MỀM ĐƯỢC KIỂM TRA THỰC SỰ ĐƯỢC XÂY
DỰNG NHƯ THẾ NÀO. ĐÓ LÀ LÝ DO MÀ CÓ NHIỀU TRƯỜNG HỢP MÀ MỘT KIỂM
THỬ VIÊN HỘP ĐEN VIẾT RẤT NHIỀU CA KIỂM THỬ ĐỂ KIỂM TRA MỘT THỨ GÌ
ĐÓ MÀ ĐÁNG LẼ CÓ THỂ CHỈ CẦN KIỂM TRA BẰNG 1 CA KIỂM THỬ DUY NHẤT,
VÀ/HOẶC MỘT SỐ PHẦN CỦA CHƯƠNG TRÌNH KHÔNG ĐƯỢC KIỂM TRA CHÚT
NÀO.
Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá KHÁCH QUAN”,
MẶT KHÁC NÓ LẠI CÓ NHƯỢC ĐIỂM CỦA “THĂM DÒ MÙ”.
1.1.3.2 Kiểm thử hộp trắng – White box testing

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen,
kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên
trong của chương trình. Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm
thử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và
giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng).
Các phương pháp kiểm thử hộp trắng
10
• Kiểm thử giao diện lập trình ứng dụng – API testing (application
programming interface): là phương pháp kiểm thử của ứng dụng sử
dụng các API công khai và riêng tư.
• Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số
tiêu chuẩn về bao phủ mã lệnh.
• Các phương pháp gán lỗi – Fault injection.
• Các phương pháp kiểm thử hoán chuyển – Mutation testing methods.
• Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm
thử tĩnh.
Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn
thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen.
Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ thống ít khi được
kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra.
1.1.3.3 Kiểm thử hộp xám – Gray box testing
Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật
bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức
người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ
liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu
ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra.
Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartion
testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong
đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm
cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.

1.1.4 Các cấp độ kiểm thử phần mềm
Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp,
Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm.
11
Hình 1.1 Sơ đồ các cấp độ kiểm thử
1.1.4.1 Kiểm thử đơn vị – Unit test
Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được.
Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức
(Method) đều có thể được xem là Unit.
Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt
động đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và
phân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc
phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm
tra. Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bù
bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các
mức kiểm thử sau đó.
12
Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện
càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần
mềm. Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và code
của chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất
(khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của
Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra
để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực
thi trong một Unit. Ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then … else là
một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quét
hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.
Cùng với các mục kiểm thử khác, Unit Test cũng đòi hỏi phải chuẩn bị trước
các ca kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định rõ
dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn. Các Test case và

Test script này nên được giữ lại để tái sử dụng.
1.1.4.2 Kiểm thử tích hợp – Intergration Test
Integration test kết hợp các thành phần của một ứng dụng và kiểm thử như một
ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ
thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.
Hai mục tiêu chính của Integration Test:
• Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
• Tích hợp các 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 thử ở
mức hệ thống (System Test).
Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và
cấu trúc nội tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp giữa Unit
với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật
13
sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện
Integration Test.
Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã
được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được
sửa chữa. Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các
giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích
hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.
Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit.
Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp
trước đó và đã hoàn tất các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm
thử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều
này sẽ làm cho số lượng can kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể.
Có 4 loại kiểm thử trong Integration Test:
• Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test, kiểm thử
cấu trúc nhằm bảo đảm các thành phần bên trong của một chương trình
chạy đúng và chú trọng đến hoạt động của các thành phần cấu trúc nội

tại của chương trình chẳng hạn các câu lệnh và nhánh bên trong.
• Kiểm thử chức năng (Functional Test): Tương tự Black Box Test, kiểm
thử chức năng chỉ chú trọng đến chức năng của chương trình, mà không
quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương
trình theo yêu cầu kỹ thuật.
• Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của
hệ thống.
• Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ
thống.
14
1.1.4.3 Kiểm thử hệ thống – System Test
Mục đích System Test là kiểm thử thiết kế và 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 thử này tốn rất nhiều công sức và thời gian.
Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm
hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố,
hoặc hệ thống nhúng. Ở mức độ hệ thống, người 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.
Điểm khác nhau then chốt giữa Integration Test và System Test là System Test
chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao
tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta
phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác
giữa chúng hoạt động chính xác trước khi thực hiện System Test.
Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình
thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình
viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh.
Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích
các yêu cầu.

System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu
về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức
kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc
phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ
nhớ. Sau giai đoạn System Test, phần mềm thường đã sẵn sàng cho khách hàng hoặc
người dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử
(Alpha/Beta Test).
15
Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test
thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát
triển dự án. Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biến
nhất gồm:
• Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ
thống thỏa mãn đúng yêu cầu thiết kế.
• Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ưu việc phân bổ
tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian
xử lý hay đáp ứng câu truy vấn…
• Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ
thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng
lúc). Stress Test tập trung vào các trạng thái tới hạn, các “điểm chết”, các
tình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện
nhiều trong kiểm tra thiết bị như POS, ATM…)…
• Kiểm thử cấu hình (Configuration Test).
• Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật của
dữ liệu và của hệ thống.
• Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có
khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài
nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch
như ngân hàng trực tuyến…
Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng

bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.
Lưu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy
yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự
án, khi lập kế hoạch, người Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử
nào.
16
1.1.4.4 Kiểm thử chấp nhận sản phẩm – Acceptance Test
Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng
thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance
Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách
hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).
Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi
trường hợp, các phép kiểm thử của System Test và Acceptance Test gần như tương
tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.
Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử
dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha
Test và kiểm thử Beta – Beta Test. Với Alpha Test, người dùng kiểm thử phần mềm
ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và
lên kế hoạch sửa chữa. Với Beta Test, phần mềm sẽ được gửi tới cho người dùng để
kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập
trình viên để sửa chữa.
Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá
trình phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù
phần mềm đã trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan đến việc
hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một phần mềm
xuất sắc vượt qua các phép kiểm thử về chức năng thực hiện bởi nhóm thực hiện dự
án, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo
nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v…
Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và
tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v… Tất cả tài liệu đi kèm

phải được cập nhật và kiểm thử chặt chẽ.
17
1.1.4.5 Một số cấp độ kiểm thử khác
Ngoài các cấp độ trên, còn một số cấp độ kiểm thử khác như:
Kiểm thử hồi quy – Regression Testing:
Theo chuẩn IEEE610.12-90, kiểm thử hồi quy là “sự kiểm tra lại có lựa chọn
của một hệ thống hay thành phần để xác minh là những sự thay đổi không gây ra
những hậu quả không mong muốn…”. Trên thực tế, quan niệm này là chỉ ra rằng
phần mềm mà đã qua được các kiểm tra trước đó vẫn có thể được kiểm tra lại. Beizer
định nghĩa đó là sự lặp lại các kiểm tra để chỉ ra rằng cách hoạt động của phần mềm
không bị thay đổi, ngoại trừ tới mức như yêu cầu. Hiển nhiên là sự thỏa hiệp phải
được thực hiện giữa sự đảm bảo được đưa ra bởi kiểm thử hồi quy mỗi lần thực hiện
một sự thay đổi và những tài nguyên được yêu cầu thực hiện điều đó.
Kiểm thử tính đúng – Correctness testing:
Tính đúng đắn là yêu cầu tối thiểu của phần mềm, là mục đích chủ yếu của
kiểm thử. Kiểm thử tính đúng sẽ cần một kiểu người đáng tin nào đó, để chỉ ra cách
hoạt động đúng đắn từ cách hoạt động sai lầm. Kiểm thử viên có thể biết hoặc không
biết các chi tiết bên trong của các modun phần mềm được kiểm thử, ví dụ luồng điều
khiển, luông dữ liệu, v.v …. Do đó, hoặc là quan điểm hộp trắng, hoặc là quan điểm
hộp đen có thể được thực hiện trong kiểm thử phần mềm.
1.1.5 Các phương pháp kiểm thử con người
Hai phương pháp kiểm thử con người chủ yếu là Code Inspections và
Walkthroughs. Hai phương pháp này bao gồm một nhóm người đọc và kiểm tra theo
mã lệnh của chương trình. Mục tiêu của chúng là để tìm ra lỗi mà không gỡ lỗi.
Một Inspection hay Walkthrough là 1 sự cải tiến của phương pháp kiểm tra mà
lập trình viên đọc chương trình của họ trước khi kiểm thử nó. Inspections và
18
Walkthroughs hiệu quả hơn là bởi vì những người khác sẽ kiểm thử chương trình tốt
hơn chính tác giả của chương trình đó.
Inspections/Walkthroughs và kiểm thử bằng máy tính bổ sung cho nhau. Hiệu

quả tìm lỗi sẽ kém đi nếu thiếu đi 1 trong 2 phương pháp. Và đối với việc sửa đổi
chương trình cũng nên sử dụng các phương pháp kiểm thử này cũng như các kỹ thuật
kiểm thử hồi quy.
1.1.5.1 Tổng duyệt – Walkthrough
Walkthrough là một thuật ngữ mô tả sự xem xét kỹ lưỡng của một quá trình ở
mức trừu tượng trong đó nhà thiết kế hay lập trình viên lãnh đạo các thành viên trong
nhóm và những người có quan tâm khác thông qua một sản phẩm phần mềm, và
những người tham gia đặt câu hỏi, và ghi chú những lỗi có thể có, sự vi phạm các
chuẩn phát triển và các vấn đề khác. Walkthrough mã lệnh là 1 tập các thủ tục và các
công nghệ dò lỗi cho việc đọc nhóm mã lệnh. Trong một Walkthrough, nhóm các nhà
phát triển – với 3 hoặc 4 thành viên là tốt nhất – thực hiện xét duyệt lại. Chỉ 1 trong
các thành viên là tác giả của chương trình.
Một ưu điểm khác của walkthroughs, hiệu quả trong chi phí gỡ lỗi, là 1 thực tế
mà khi một lỗi được tìm thấy, nó thường được định vị chính xác trong mã lệnh. Thêm
vào đó, phương pháp này thường tìm ra 1 tập các lỗi, cho phép sau đó các lỗi đó được
sửa tất cả với nhau. Mặt khác, kiểm thử dựa trên máy tính,chỉ tìm ra triệu chứng của
lỗi (chương trình không kết thúc hoặc đưa ra kết quả vô nghĩa), và các lỗi thường
được tìm ra và sửa lần lượt từng lỗi một.
1.1.5.2 Thanh tra mã nguồn – Code Inspection
Thanh tra mã nguồn là 1 tập hợp các thủ tục và các kỹ thuật dò lỗi cho việc đọc
các nhóm mã lệnh. Một nhóm kiểm duyệt thường gồm 4 người. Một trong số đó
đóng vai trò là người điều tiết – một lập trình viên lão luyện và không được là tác giả
của chương trình và phải không quen với các chi tiết của chương trình. Người điều
19
tiết có nhiệm vụ: phân phối nguyên liệu và lập lịch cho các buổi kiểm duyệt, chỉ đạo
phiên làm việc, ghi lại tất cả các lỗi được tìm thấy và đảm bảo là các lỗi sau đó được
sửa. Thành viên thứ hai là một lập trình viên. Các thành viên còn lại trong nhóm
thường là nhà thiết kế của chương trình ( nếu nhà thiết kế khác lập trình viên) và một
chuyên viên kiểm thử.
1.2 Nguyên tắc kiểm thử phần mềm

Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuân
thủ một số quy tắc sau:
Quy tắc 1: Một phần quan trọng của 1 ca kiểm thử là định nghĩa của đầu ra hay
kết quả mong muốn.
Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình.
Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính họ.
Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra.
Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào không hợp
lệ và không mong muốn, cũng như cho các đầu vào hợp lệ và mong
muốn.
Quy tắc 6: Khảo sát 1 chương trình để xem liệu chương trình có thực hiện cái mà
nó cần thực hiện chỉ là 1 phần, phần còn lại là xem liệu chương trình
có thực hiện cái mà nó không cần phải thực hiện hay không.
Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chương trình thực sự là 1
chương trình bâng quơ.
Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không tìm
thấy lỗi.
Quy tắc 9: Xác suất tồn tại lỗi trong 1 đoạn chương trình là tương ứng với số lỗi
đã tìm thấy trong đoạn đó.
Quy tắc 10: Kiểm thử là 1 nhiệm vụ cực kỳ sáng tạo và có tính thử thách trí tuệ.
20
CHƯƠNG 2. THIẾT KẾ TEST – CASE
2.1 Khái niệm
Thiết kế test – case trong kiểm thử phần mềm là quá trình xây dựng các phương
pháp kiểm thử có thể phát hiện lỗi, sai sót, khuyết điểm của phần mềm để xây dựng
phần mềm đạt tiêu chuẩn.
2.2 Vai trò của thiết kế test – case
• Tạo ra các ca kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót của
phần mềm một cách nhiều nhất.
• Tạo ra các ca kiểm thử có chi phí rẻ nhất, đồng thời tốn ít thời gian và

công sức nhất.
2.3 Quy trình thiết kế test – case
Một trong những lý do quan trọng nhất trong kiểm thử chương trình là thiết kế
và tạo ra các ca kiểm thử – các Test case có hiệu quả. Với những ràng buộc về thời
gian và chi phí đã cho, thì vấn đề then chốt của kiểm thử trở thành:
Tập con nào của tất cả ca kiểm thử có thể có khả năng tìm ra nhiều lỗi nhất?
Thông thường, phương pháp kém hiệu quả nhất là kiểm tra tất cả đầu vào ngẫu
nhiên – quá trình kiểm thử một chương trình bằng việc chọn ngẫu nhiên một tập con
các giá trị đầu vào có thể. Về mặt khả năng tìm ra nhiều lỗi nhất, tập hợp các ca kiểm
thử được chọn ngẫu nhiên có rất ít cơ hội là tập hợp tối ưu hay gần tối ưu. Sau đây là
một số phương pháp để chọn ra một tập dữ liệu kiểm thử một cách thông minh.
21
Để kiểm thử hộp đen và kiểm thử hộp trắng một cách thấu đáo là không thể. Do
đó, một chiến lược kiểm thử hợp lý là chiến lược có thể kết hợp sức mạnh của cả hai
phương pháp trên: Phát triển 1 cuộc kiểm thử nghiêm ngặt vừa bằng việc sử dụng các
phương pháp thiết kế ca kiểm thử hướng hộp đen nào đó và sau đó bổ sung thêm
những ca kiểm thử này bằng việc khảo sát tính logic của chương trình, sử dụng
phương pháp hộp trắng.
Những chiến lược kết hợp đó bao gồm:
Hộp đen Hộp trắng
1. Phân lớp tương đương
2. Phân tích giá trị biên
3. Đồ thị nguyên nhân – kết quả
4. Đoán lỗi
1. Bao phủ câu lệnh
2. Bao phủ quyết định
3. Bao phủ điều kiện
4. Bao phủ điều kiện – quyết định
5. Bao phủ đa điều kiện.
Mỗi phương pháp có những ưu điểm cũng như khuyết điểm riêng, do đó để có

được tập các ca kiểm thử tối ưu, chúng ta cần kết hợp hầu hết các phương pháp. Quy
trình thiết kế các ca kiểm thử sẽ bắt đầu bằng việc phát triển các ca kiểm thử sử dụng
phương pháp hộp đen và sau đó phát triển bổ sung các ca kiểm thử cần thiết với
phương pháp hộp trắng.
2.3.1 Kiểm thử hộp trắng – Kiểm thử bao phủ logic
Kiểm thử hộp trắng có liên quan tới mức độ mà các ca kiểm thử thực hiện hay
bao phủ tính logic (mã nguồn) của chương trình. Kiểm thử hộp trắng cơ bản là việc
thực hiện mọi đường đi trong chương trình, nhưng việc kiểm thử đầy đủ đường đi là
một mục đích không thực tế cho một chương trình với các vòng lặp. Các tiêu chuẩn
trong kiểm thử bao phủ logic gồm có:
2.3.1.1 Bao phủ câu lệnh – Statement Coverage
Tư tưởng: Thực hiện mọi câu lệnh trong chương trình ít nhất 1 lần.
22
Xét ví dụ với đoạn mã lệnh JAVA sau:
public void foo (int a, int b, int x){
if (a>1 && b==0) {
x=x/a;}
if (a==2||x>1){
x=x+1;
}
}
Hình 2.1 Một chương trình nhỏ để kiểm thử
Bạn có thể thực hiện mọi câu lệnh bằng việc viết 1 ca kiểm thử đơn đi qua
đường ace. Tức là, bằng việc đặt A=2, B=0 và X=3 tại điểm a, mỗi câu lệnh sẽ được
thực hiện 1 lần (thực tế, X có thể được gán bất kỳ giá trị nào).
23
Thường tiêu chuẩn này khá kém. Ví dụ, có lẽ nếu quyết định đầu tiên là phép or
chứ không phải phép and thì lỗi này sẽ không được phát hiện. Hay nếu quyết định
thứ hai mà bắt đầu với x>0, lỗi này cũng sẽ không được tìm ra. Cũng vậy, có 1
đường đi qua chương trình mà ở đó x không thay đổi (đường đi abd). Nếu đây là 1

lỗi, thì lỗi này có thể không tìm ra. Hay nói cách khác, tiêu chuẩn bao phủ câu lệnh
quá yếu đến nỗi mà nó thường là vô ích.
2.3.1.2 Bao phủ quyết định – Decision coverage
Tư tưởng: Viết đủ các ca kiểm thử mà mỗi quyết định có kết luận đúng hay sai
ít nhất 1 lần. Nói cách khác, mỗi hướng phân nhánh phải được xem xét kỹ lưỡng ít
nhất 1 lần.
Các ví dụ về câu lệnh rẽ nhánh hay quyết định là các câu lệnh switch, do-while,
và if-else. Các câu lệnh đa đường GOTO thường sử dụng trong một số ngôn ngữ lập
trình như FORTRAN.
Bao phủ quyết định thường thỏa mãn bao phủ câu lệnh. Vì mỗi câu lệnh là trên
sự bắt nguồn một đường đi phụ nào đó hoặc là từ 1 câu lệnh rẽ nhánh hoặc là từ điểm
vào của chương trình, mỗi câu lệnh phải được thực hiện nếu mỗi quyết định rẽ nhánh
được thực hiện. Tuy nhiên, có ít nhất 3 ngoại lệ:
• Những chương trình không có quyết định.
• Những chương trình hay thường trình con/phương thức với nhiều điểm
vào. Một câu lệnh đã cho có thể được thực hiện nếu và chỉ nếu chương
trình được nhập vào tại 1 điểm đầu vào riêng.
• Các câu lệnh bên trong các ON-unit. Việc đi qua mỗi hướng rẽ nhánh sẽ
là không nhất thiết làm cho tất cả các ON-unit được thực thi.
Vì chúng ta đã thấy rằng bao phủ câu lệnh là điều kiện cần thiết, nên một chiến
lược tốt hơn là bao phủ quyết định nên được định nghĩa bao hàm cả bao phủ câu
lệnh. Do đó, bao phủ quyết định yêu cầu mỗi quyết định phải có kết luận đúng hoặc
sai, và mỗi câu lệnh đó phải được thực hiện ít nhất 1 lần.
24
Phương pháp này chỉ xem xét những quyết định hay những sự phân nhánh 2
đường và phải được sửa đổi cho những chương trình có chứa những quyết định đa
đường. Ví dụ, các chương trình JAVA có chứa các lệnh select (case), các chương
trình FORTRAN chứa các lệnh số học (ba đường) if hoặc các lệnh tính toán hay số
học GOTO, và các chương trình COBOL chứa các lệnh GOTO biến đổi hay các lệnh
GO-TO-DEPENDING-ON (các lệnh goto phụ thuộc). Với những chương trình như

vậy, tiêu chuẩn này đang sử dụng mỗi kết luận có thể của tất cả các quyết định ít nhất
1 lần và gọi mỗi điểm vào tới chương trình hay thường trình con ít nhất 1 lần.
Trong hình 2.1, bao phủ quyết định có thể đạt được bởi ít nhất 2 ca kiểm thử
bao phủ các đường ace và abd hoặc acd và abe. Nếu chúng ta chọn khả năng thứ hai,
thì 2 đầu vào test-case là A=3, B=0, X=3 và A=2, B=1, X=1.
Bao phủ quyết định là 1 tiêu chuẩn mạnh hơn bao phủ câu lệnh, nhưng vẫn khá
yếu. Ví dụ, chỉ có 50% cơ hội là chúng ta sẽ tìm ra con đường trong đó x không bị
thay đổi (ví dụ, chỉ khi bạn chọn khả năng thứ nhất). Nếu quyết định thứ hai bị lỗi
(nếu như đáng lẽ phải nói là x<1 thay vì x>1), lỗi này sẽ không được phát hiện bằng
2 ca kiểm thử trong ví dụ trước.
2.3.1.3 Bao phủ điều kiện – Condition coverage
Tư tưởng: Viết đủ các ca kiểm thử để đảm bảo rằng mỗi điều kiện trong một
quyết định đảm nhận tất cả các kết quả có thể ít nhất một lần.
Vì vậy, như với bao phủ quyết định, thì bao phủ điều kiện không phải luôn luôn
dẫn tới việc thực thi mỗi câu lệnh. Thêm vào đó, trong tiêu chuẩn bao phủ điều kiện,
mỗi điểm vào chương trình hay thường trình con, cũng như các ON-unit, được gọi ít
nhất 1 lần. Ví dụ, câu lệnh rẽ nhánh do k=0 to 50 while (j+k<quest) có chứa 2 điều
kiện là k<=50, và j+k<quest. Do đó, các ca kiểm thử sẽ được yêu cầu cho những tình
huống k<=50, k>50 (để đến lần lặp cuối cùng của vòng lặp), j+k<quest, và
j+k>=quest.
25

Hình 2.6 Những xem xét được sử dụng khi dò theo đồ thị…………………………..38Hình 3.1 Đồ thị nguyên nhân – kết quả:…………………………………………………….45Hình 3.2 Bảng quyết định………………………………………………………………………..46LỜI NÓI ĐẦUTrong ngành kỹ nghệ phần mềm, năm 1979, có một quy tắc nổi tiếng là: “Trongmột dự án lập trình điển hình, thì xấp xỉ 50% thời gian và hơn 50% tổng chi phí đượcsử dụng trong kiểm thử các chương trình hay hệ thống đã được phát triển”. Và chođến nay, sau gần một phần 3 thế kỷ, quy tắc đó vẫn còn đúng. Đã có rất nhiều ngônngữ, hệ thống phát triển mới với các công cụ tích hợp cho các lập trình viên sử dụngphát triển ngày càng linh động. Nhưng kiểm thử vẫn đóng vai trò hết sức quan trọngtrong bất kỳ dự án phát triển phần mềm nào.Rất nhiều các giáo sư, giảng viên đã từng than phiền rằng: “ Sinh viên củachúng ta tốt nghiệp và đi làm mà không có được những kiến thực thực tế cần thiết vềcách để kiểm thử một chương trình. Hơn nữa, chúng ta hiếm khi có được những lờikhuyên bổ ích để cung cấp trong các khóa học mở đầu về cách một sinh viên nên làmvề kiểm thử và gỡ lỗi các bài tập của họ”.Các tác giả của cuốn sách nổi tiếng “The Art of Software Testing” – Nghệ thuậtkiểm thử phần mềm, Glenford J. Myers, Tom Badgett, Todd M. Thomas, CoreySandler đã khẳng định trong cuốn sách của mình rằng: “ Hầu hết các thành phần quantrọng trong các thủ thuật của một nhà kiểm thử chương trình là kiến thức về cách đểviết các ca kiểm thử có hiệu quả”. Việc xây dựng các test – case là một nhiệm vụ rấtkhó khăn. Để có thể xây dựng được tập các test – case hữu ích cho kiểm thử, chúngta cần rất nhiều kiến thức và kinh nghiệm.Đó là những lý do thúc đẩy em thực hiện đề tài này. Mục đích của đề tài là tìmhiểu những kiến thức tổng quan nhất về kiểm thử, và cách thiết kế test – case trongkiểm thử phần mềm. Việc thực hiện đề tài sẽ giúp em tìm hiểu sâu hơn và lĩnh vựcrất hấp dẫn này, vận dụng được các kiến thức đã học để có thể thiết kế được các test– case một cách có hiệu quả và áp dụng vào những bài toán thực tế.Bản báo cáo được hoàn thành dưới sự chỉ bảo tận tình của thầy giáo, ThSNguyễn Hồng Tân, sự giúp đỡ nhiệt tình của các thầy cô trong bộ môn Công nghệphần mềm, và tất cả các bạn. Em hi vọng sẽ nhận được sự đóng góp ý kiến của cácthầy cô và các bạn để bản báo cáo được hoàn thiện hơn. Những đóng góp đó sẽ làkinh nghiệm quý báu cho em. Và từ đó, em có thể tiếp tục phát triển đề tài này chođợt thực tập tốt nghiệp và đồ án tốt nghiệp sắp tới, cũng như cho công việc trongtương lai.Em xin chân thành cám ơn.Sinh viênPhạm Thị TrangTÓM TẮT NỘI DUNGBản báo cáo được chia thành 3 chương với nội dung như sau:• Chương 1: Tổng quan về kiểm thử phần mềm.Chương này là cái nhìn tổng quan về kiểm thử phần mềm:các khái niệm cơ bản về kiểm thử phần mềm, các quy tắctrong kiểm thử, và các phương pháp kiểm thử phần mềm tiêubiểu.• Chương 2: Thiết kế test – case trong kiểm thử phần mềm.Trong chương này, em đi tìm hiểu các phương pháp thiết kếtest – case có hiệu quả. Từ đó rút ra nhận xét về ưu nhượcđiểm của từng phương pháp.• Chương 3: Áp dụng.Từ những phương pháp thiết kế test – case đã tìm hiểu trongChương 2, em áp dụng để xây dựng tập các test – case chomột bài toán cụ thể : Thiết kế các test – case cho chươngtrình “Tam giác”.CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬPHẦN MỀM1.1 Các khái niệm cơ bản về kiểm thử phần mềm1.1.1 Kiểm thử phần mềm là gì?Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dướinhững điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khíacạnh nào đó của hệ thống hay thành phần đó. (Theo Bảng chú giải thuật ngữchuẩn IEEE của Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary of SoftwareEngineering Terminology).Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìmlỗi. (Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm).Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụphần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cungcấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩmhay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi haykhiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềmtrong nhiều ngành khác nhau. (Theo Bách khoa toàn thư mở Wikipedia).Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiếntrình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tínhthực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứthứ gì không mong muốn. Đây là một pha quan trọng trong quá trình phát triển hệthống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mớiđã đáp ứng yêu cầu đặt ra hay chưa?1.1.2 Các phương pháp kiểm thửCó 2 phương pháp kiểm thử chính là: Kiểm thử tĩnh và Kiểm thử động.1.1.2.1 Kiểm thử tĩnh – Static testingLà phương pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tảbằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết màkhông cần chạy chương trình. Kiểu kiểm thử này thường được sử dụng bởi chuyênviên thiết kế người mà viết mã lệnh một mình.Kiểm thử tĩnh cũng có thể được tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộbao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch màxác nhận tính hợp lệ về cú pháp của chương trình.1.1.2.2 Kiểm thử động – Dynamic testingLà phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình đểđiều tra trạng thái tác động của chương trình. Đó là kiểm thử dựa trên các ca kiểmthử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy các chương trình.Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sựphản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian. Trong kiểm thửđộng, phần mềm phải thực sự được biên dịch và chạy. Kiểm thử động thực sự baogồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra cónhư mong muốn hay không. Các phương pháp kiểm thử động gồm có kiểm thử Unit– Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống – SystemTests, và Kiểm thử chấp nhận sản phẩm – Acceptance Tests.1.1.3 Các chiến lược kiểm thửBa TRONG SỐ NHỮNG CHIẾN LƯỢC KIỂM THỬ THÔNG DỤNG NHẤT BAOGỒM: KIỂM THỬ HỘP ĐEN, KIỂM THỬ HỘP TRẮNG, VÀ KIỂM THỬ HỘP XÁM.1.1.3.1 Kiểm thử hộp đen – BLACK BOX TESTINGMột trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướngdữ liệu, hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là một “hộpđen”. MỤC ĐÍCH CỦA BẠN LÀ HOÀN TOÀN KHÔNG QUAN TÂM VỀ CÁCH CƯ XỬVÀ CẤU TRÚC BÊN TRONG CỦA CHƯƠNG TRÌNH. THAY VÀO ĐÓ, TẬP TRUNGVÀO TÌM CÁC TRƯỜNG HỢP MÀ CHƯƠNG TRÌNH KHÔNG THỰC HIỆN THEO CÁCĐẶC TẢ CỦA NÓ.THEO HƯỚNG TIẾP CẬN NÀY, DỮ LIỆU KIỂM TRA ĐƯỢC LẤY CHỈ TỪ CÁCĐẶC TẢ.Các phương pháp kiểm thử HỘP ĐEN• PHÂN LỚP TƯƠNG ĐƯƠNG – EQUIVALENCE PARTITIONING.• PHÂN TÍCH GIÁ TRỊ BIÊN – BOUNDARY VALUE ANALYSIS.• KIỂM THỬ MỌI CẶP – ALL-PAIRS TESTING.• KIỂM THỬ FUZZ – FUZZ TESTING.• KIỂM THỬ DỰA TRÊN MÔ HÌNH – MODEL-BASED TESTING.• Ma TRẬN DẤU VẾT – TRACEABILITY MATRIX.• KIỂM THỬ THĂM DÒ – EXPLORATORY TESTING.• KIỂM THỬ DỰA TRÊN ĐẶC TẢ – SPECIFICATION-BASE TESTING.Kiểm thử dựa trên đặc tả TẬP TRUNG VÀO KIỂM TRA TÍNH THIẾT THỰCCỦA PHẦN MỀM THEO NHỮNG YÊU CẦU THÍCH HỢP. DO ĐÓ, KIỂM THỬ VIÊNNHẬP DỮ LIỆU VÀO, VÀ CHỈ THẤY DỮ LIỆU RA TỪ ĐỐI TƯỢNG KIỂM THỬ.MỨC KIỂM THỬ NÀY THƯỜNG YÊU CẦU CÁC CA KIỂM THỬ TRIỆT ĐỂ ĐƯỢCCUNG CẤP CHO KIỂM THỬ VIÊN MÀ KHI ĐÓ CÓ THỂ XÁC MINH LÀ ĐỐI VỚI DỮLIỆU ĐẦU VÀO ĐÃ CHO, GIÁ TRỊ ĐẦU RA (HAY CÁCH THỨC HOẠT ĐỘNG) CÓGIỐNG VỚI GIÁ TRỊ MONG MUỐN ĐÃ ĐƯỢC XÁC ĐỊNH TRONG CA KIỂM THỬ ĐÓHAY KHÔNG. KIỂM THỬ DỰA TRÊN ĐẶC TẢ LÀ CẦN THIẾT, NHƯNG KHÔNG ĐỦĐỂ ĐỂ NGĂN CHẶN NHỮNG RỦI RO CHẮC CHẮN.Ưu, nhược ĐIỂMKiểm thử HỘP ĐEN KHÔNG CÓ MỐI LIÊN QUAN NÀO TỚI MÃ LỆNH, VÀKIỂM THỬ VIÊN CHỈ RẤT ĐƠN GIẢN TÂM NIỆM LÀ: MỘT MÃ LỆNH PHẢI CÓLỖI. SỬ DỤNG NGUYÊN TẮC “ HÃY ĐÒI HỎI VÀ BẠN SẼ ĐƯỢC NHẬN”, NHỮNGKIỂM THỬ VIÊN HỘP ĐEN TÌM RA LỖI MÀ NHỮNG LẬP TRÌNH VIÊN ĐÃ KHÔNGTÌM RA. NHƯNG, MẶT KHÁC, NGƯỜI TA CŨNG NÓI KIỂM THỬ HỘP ĐEN“GIỐNG NHƯ LÀ ĐI TRONG BÓNG TỐI MÀ KHÔNG CÓ ĐÈN VẬY”, BỞI VÌ KIỂMTHỬ VIÊN KHÔNG BIẾT CÁC PHẦN MỀM ĐƯỢC KIỂM TRA THỰC SỰ ĐƯỢC XÂYDỰNG NHƯ THẾ NÀO. ĐÓ LÀ LÝ DO MÀ CÓ NHIỀU TRƯỜNG HỢP MÀ MỘT KIỂMTHỬ VIÊN HỘP ĐEN VIẾT RẤT NHIỀU CA KIỂM THỬ ĐỂ KIỂM TRA MỘT THỨ GÌĐÓ MÀ ĐÁNG LẼ CÓ THỂ CHỈ CẦN KIỂM TRA BẰNG 1 CA KIỂM THỬ DUY NHẤT,VÀ/HOẶC MỘT SỐ PHẦN CỦA CHƯƠNG TRÌNH KHÔNG ĐƯỢC KIỂM TRA CHÚTNÀO.Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá KHÁCH QUAN”,MẶT KHÁC NÓ LẠI CÓ NHƯỢC ĐIỂM CỦA “THĂM DÒ MÙ”.1.1.3.2 Kiểm thử hộp trắng – White box testingLà một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen,kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bêntrong của chương trình. Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểmthử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu vàgiải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng).Các phương pháp kiểm thử hộp trắng10• Kiểm thử giao diện lập trình ứng dụng – API testing (applicationprogramming interface): là phương pháp kiểm thử của ứng dụng sửdụng các API công khai và riêng tư.• Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một sốtiêu chuẩn về bao phủ mã lệnh.• Các phương pháp gán lỗi – Fault injection.• Các phương pháp kiểm thử hoán chuyển – Mutation testing methods.• Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểmthử tĩnh.Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoànthành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen.Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ thống ít khi đượckiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra.1.1.3.3 Kiểm thử hộp xám – Gray box testingKiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuậtbên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mứcngười sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữliệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầura rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra.Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartiontesting giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trongđó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồmcả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.1.1.4 Các cấp độ kiểm thử phần mềmKiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp,Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm.11Hình 1.1 Sơ đồ các cấp độ kiểm thử1.1.4.1 Kiểm thử đơn vị – Unit testMột đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được.Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức(Method) đều có thể được xem là Unit.Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạtđộng đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận vàphân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắcphục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểmtra. Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bùbằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở cácmức kiểm thử sau đó.12Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiệncàng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phầnmềm. Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và codecủa chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất(khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng củaUnit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm trađể phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thựcthi trong một Unit. Ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then … else làmột nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quéthết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.Cùng với các mục kiểm thử khác, Unit Test cũng đòi hỏi phải chuẩn bị trướccác ca kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định rõdữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn. Các Test case vàTest script này nên được giữ lại để tái sử dụng.1.1.4.2 Kiểm thử tích hợp – Intergration TestIntegration test kết hợp các thành phần của một ứng dụng và kiểm thử như mộtứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻthì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.Hai mục tiêu chính của Integration Test:• Phát hiện lỗi giao tiếp xảy ra giữa các Unit.• Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuốicùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ởmức hệ thống (System Test).Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng vàcấu trúc nội tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp giữa Unitvới các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật13sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiệnIntegration Test.Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đãđược kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã đượcsửa chữa. Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với cácgiao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tíchhợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit.Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợptrước đó và đã hoàn tất các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểmthử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điềunày sẽ làm cho số lượng can kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể.Có 4 loại kiểm thử trong Integration Test:• Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test, kiểm thửcấu trúc nhằm bảo đảm các thành phần bên trong của một chương trìnhchạy đúng và chú trọng đến hoạt động của các thành phần cấu trúc nộitại của chương trình chẳng hạn các câu lệnh và nhánh bên trong.• Kiểm thử chức năng (Functional Test): Tương tự Black Box Test, kiểmthử chức năng chỉ chú trọng đến chức năng của chương trình, mà khôngquan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chươngtrình theo yêu cầu kỹ thuật.• Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành củahệ thống.• Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệthống.141.1.4.3 Kiểm thử hệ thống – System TestMục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tíchhợ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ợpthành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian.Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềmhoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố,hoặc hệ thống nhúng. Ở mức độ hệ thống, người 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ácliên quan đến chất lượng của toàn hệ thống.Điểm khác nhau then chốt giữa Integration Test và System Test là System Testchú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giaotiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường taphải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tácgiữa chúng hoạt động chính xác trước khi thực hiện System Test.Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hìnhthành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trìnhviên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh.Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tíchcác yêu cầu.System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầuvề chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mứckiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặcphần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộnhớ. Sau giai đoạn System Test, phần mềm thường đã sẵn sàng cho khách hàng hoặcngười dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử(Alpha/Beta Test).15Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Testthường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm pháttriển dự án. Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biếnnhất gồm:• Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệthống thỏa mãn đúng yêu cầu thiết kế.• Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ưu việc phân bổtài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gianxử lý hay đáp ứng câu truy vấn…• Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệthống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùnglúc). Stress Test tập trung vào các trạng thái tới hạn, các “điểm chết”, cáctình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiệnnhiều trong kiểm tra thiết bị như POS, ATM…)…• Kiểm thử cấu hình (Configuration Test).• Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật củadữ liệu và của hệ thống.• Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống cókhả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tàinguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịchnhư ngân hàng trực tuyến…Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: Chúngbảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.Lưu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùyyêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dựán, khi lập kế hoạch, người Quản lý dự án sẽ quyết định áp dụng những loại kiểm thửnào.161.1.4.4 Kiểm thử chấp nhận sản phẩm – Acceptance TestThông thường, sau giai đoạn System Test là Acceptance Test, được khách hàngthực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của AcceptanceTest là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và kháchhàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọitrường hợp, các phép kiểm thử của System Test và Acceptance Test gần như tươngtự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sửdụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – AlphaTest và kiểm thử Beta – Beta Test. Với Alpha Test, người dùng kiểm thử phần mềmngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, vàlên kế hoạch sửa chữa. Với Beta Test, phần mềm sẽ được gửi tới cho người dùng đểkiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lậptrình viên để sửa chữa.Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quátrình phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dùphần mềm đã trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan đến việchiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một phần mềmxuất sắc vượt qua các phép kiểm thử về chức năng thực hiện bởi nhóm thực hiện dựán, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèonàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v…Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ vàtài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v… Tất cả tài liệu đi kèmphải được cập nhật và kiểm thử chặt chẽ.171.1.4.5 Một số cấp độ kiểm thử khácNgoài các cấp độ trên, còn một số cấp độ kiểm thử khác như:Kiểm thử hồi quy – Regression Testing:Theo chuẩn IEEE610.12-90, kiểm thử hồi quy là “sự kiểm tra lại có lựa chọncủa một hệ thống hay thành phần để xác minh là những sự thay đổi không gây ranhững hậu quả không mong muốn…”. Trên thực tế, quan niệm này là chỉ ra rằngphần mềm mà đã qua được các kiểm tra trước đó vẫn có thể được kiểm tra lại. Beizerđịnh nghĩa đó là sự lặp lại các kiểm tra để chỉ ra rằng cách hoạt động của phần mềmkhông bị thay đổi, ngoại trừ tới mức như yêu cầu. Hiển nhiên là sự thỏa hiệp phảiđược thực hiện giữa sự đảm bảo được đưa ra bởi kiểm thử hồi quy mỗi lần thực hiệnmột sự thay đổi và những tài nguyên được yêu cầu thực hiện điều đó.Kiểm thử tính đúng – Correctness testing:Tính đúng đắn là yêu cầu tối thiểu của phần mềm, là mục đích chủ yếu củakiểm thử. Kiểm thử tính đúng sẽ cần một kiểu người đáng tin nào đó, để chỉ ra cáchhoạt động đúng đắn từ cách hoạt động sai lầm. Kiểm thử viên có thể biết hoặc khôngbiết các chi tiết bên trong của các modun phần mềm được kiểm thử, ví dụ luồng điềukhiển, luông dữ liệu, v.v …. Do đó, hoặc là quan điểm hộp trắng, hoặc là quan điểmhộp đen có thể được thực hiện trong kiểm thử phần mềm.1.1.5 Các phương pháp kiểm thử con ngườiHai phương pháp kiểm thử con người chủ yếu là Code Inspections vàWalkthroughs. Hai phương pháp này bao gồm một nhóm người đọc và kiểm tra theomã lệnh của chương trình. Mục tiêu của chúng là để tìm ra lỗi mà không gỡ lỗi.Một Inspection hay Walkthrough là 1 sự cải tiến của phương pháp kiểm tra màlập trình viên đọc chương trình của họ trước khi kiểm thử nó. Inspections và18Walkthroughs hiệu quả hơn là bởi vì những người khác sẽ kiểm thử chương trình tốthơn chính tác giả của chương trình đó.Inspections/Walkthroughs và kiểm thử bằng máy tính bổ sung cho nhau. Hiệuquả tìm lỗi sẽ kém đi nếu thiếu đi 1 trong 2 phương pháp. Và đối với việc sửa đổichương trình cũng nên sử dụng các phương pháp kiểm thử này cũng như các kỹ thuậtkiểm thử hồi quy.1.1.5.1 Tổng duyệt – WalkthroughWalkthrough là một thuật ngữ mô tả sự xem xét kỹ lưỡng của một quá trình ởmức trừu tượng trong đó nhà thiết kế hay lập trình viên lãnh đạo các thành viên trongnhóm và những người có quan tâm khác thông qua một sản phẩm phần mềm, vànhững người tham gia đặt câu hỏi, và ghi chú những lỗi có thể có, sự vi phạm cácchuẩn phát triển và các vấn đề khác. Walkthrough mã lệnh là 1 tập các thủ tục và cáccông nghệ dò lỗi cho việc đọc nhóm mã lệnh. Trong một Walkthrough, nhóm các nhàphát triển – với 3 hoặc 4 thành viên là tốt nhất – thực hiện xét duyệt lại. Chỉ 1 trongcác thành viên là tác giả của chương trình.Một ưu điểm khác của walkthroughs, hiệu quả trong chi phí gỡ lỗi, là 1 thực tếmà khi một lỗi được tìm thấy, nó thường được định vị chính xác trong mã lệnh. Thêmvào đó, phương pháp này thường tìm ra 1 tập các lỗi, cho phép sau đó các lỗi đó đượcsửa tất cả với nhau. Mặt khác, kiểm thử dựa trên máy tính,chỉ tìm ra triệu chứng củalỗi (chương trình không kết thúc hoặc đưa ra kết quả vô nghĩa), và các lỗi thườngđược tìm ra và sửa lần lượt từng lỗi một.1.1.5.2 Thanh tra mã nguồn – Code InspectionThanh tra mã nguồn là 1 tập hợp các thủ tục và các kỹ thuật dò lỗi cho việc đọccác nhóm mã lệnh. Một nhóm kiểm duyệt thường gồm 4 người. Một trong số đóđóng vai trò là người điều tiết – một lập trình viên lão luyện và không được là tác giảcủa chương trình và phải không quen với các chi tiết của chương trình. Người điều19tiết có nhiệm vụ: phân phối nguyên liệu và lập lịch cho các buổi kiểm duyệt, chỉ đạophiên làm việc, ghi lại tất cả các lỗi được tìm thấy và đảm bảo là các lỗi sau đó đượcsửa. Thành viên thứ hai là một lập trình viên. Các thành viên còn lại trong nhómthường là nhà thiết kế của chương trình ( nếu nhà thiết kế khác lập trình viên) và mộtchuyên viên kiểm thử.1.2 Nguyên tắc kiểm thử phần mềmĐể kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuânthủ một số quy tắc sau:Quy tắc 1: Một phần quan trọng của 1 ca kiểm thử là định nghĩa của đầu ra haykết quả mong muốn.Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình.Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính họ.Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra.Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào không hợplệ và không mong muốn, cũng như cho các đầu vào hợp lệ và mongmuốn.Quy tắc 6: Khảo sát 1 chương trình để xem liệu chương trình có thực hiện cái mànó cần thực hiện chỉ là 1 phần, phần còn lại là xem liệu chương trìnhcó thực hiện cái mà nó không cần phải thực hiện hay không.Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chương trình thực sự là 1chương trình bâng quơ.Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không tìmthấy lỗi.Quy tắc 9: Xác suất tồn tại lỗi trong 1 đoạn chương trình là tương ứng với số lỗiđã tìm thấy trong đoạn đó.Quy tắc 10: Kiểm thử là 1 nhiệm vụ cực kỳ sáng tạo và có tính thử thách trí tuệ.20CHƯƠNG 2. THIẾT KẾ TEST – CASE2.1 Khái niệmThiết kế test – case trong kiểm thử phần mềm là quá trình xây dựng các phươngpháp kiểm thử có thể phát hiện lỗi, sai sót, khuyết điểm của phần mềm để xây dựngphần mềm đạt tiêu chuẩn.2.2 Vai trò của thiết kế test – case• Tạo ra các ca kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót củaphần mềm một cách nhiều nhất.• Tạo ra các ca kiểm thử có chi phí rẻ nhất, đồng thời tốn ít thời gian vàcông sức nhất.2.3 Quy trình thiết kế test – caseMột trong những lý do quan trọng nhất trong kiểm thử chương trình là thiết kếvà tạo ra các ca kiểm thử – các Test case có hiệu quả. Với những ràng buộc về thờigian và chi phí đã cho, thì vấn đề then chốt của kiểm thử trở thành:Tập con nào của tất cả ca kiểm thử có thể có khả năng tìm ra nhiều lỗi nhất?Thông thường, phương pháp kém hiệu quả nhất là kiểm tra tất cả đầu vào ngẫunhiên – quá trình kiểm thử một chương trình bằng việc chọn ngẫu nhiên một tập concác giá trị đầu vào có thể. Về mặt khả năng tìm ra nhiều lỗi nhất, tập hợp các ca kiểmthử được chọn ngẫu nhiên có rất ít cơ hội là tập hợp tối ưu hay gần tối ưu. Sau đây làmột số phương pháp để chọn ra một tập dữ liệu kiểm thử một cách thông minh.21Để kiểm thử hộp đen và kiểm thử hộp trắng một cách thấu đáo là không thể. Dođó, một chiến lược kiểm thử hợp lý là chiến lược có thể kết hợp sức mạnh của cả haiphương pháp trên: Phát triển 1 cuộc kiểm thử nghiêm ngặt vừa bằng việc sử dụng cácphương pháp thiết kế ca kiểm thử hướng hộp đen nào đó và sau đó bổ sung thêmnhững ca kiểm thử này bằng việc khảo sát tính logic của chương trình, sử dụngphương pháp hộp trắng.Những chiến lược kết hợp đó bao gồm:Hộp đen Hộp trắng1. Phân lớp tương đương2. Phân tích giá trị biên3. Đồ thị nguyên nhân – kết quả4. Đoán lỗi1. Bao phủ câu lệnh2. Bao phủ quyết định3. Bao phủ điều kiện4. Bao phủ điều kiện – quyết định5. Bao phủ đa điều kiện.Mỗi phương pháp có những ưu điểm cũng như khuyết điểm riêng, do đó để cóđược tập các ca kiểm thử tối ưu, chúng ta cần kết hợp hầu hết các phương pháp. Quytrình thiết kế các ca kiểm thử sẽ bắt đầu bằng việc phát triển các ca kiểm thử sử dụngphương pháp hộp đen và sau đó phát triển bổ sung các ca kiểm thử cần thiết vớiphương pháp hộp trắng.2.3.1 Kiểm thử hộp trắng – Kiểm thử bao phủ logicKiểm thử hộp trắng có liên quan tới mức độ mà các ca kiểm thử thực hiện haybao phủ tính logic (mã nguồn) của chương trình. Kiểm thử hộp trắng cơ bản là việcthực hiện mọi đường đi trong chương trình, nhưng việc kiểm thử đầy đủ đường đi làmột mục đích không thực tế cho một chương trình với các vòng lặp. Các tiêu chuẩntrong kiểm thử bao phủ logic gồm có:2.3.1.1 Bao phủ câu lệnh – Statement CoverageTư tưởng: Thực hiện mọi câu lệnh trong chương trình ít nhất 1 lần.22Xét ví dụ với đoạn mã lệnh JAVA sau:public void foo (int a, int b, int x){if (a>1 && b==0) {x=x/a;}if (a==2||x>1){x=x+1;Hình 2.1 Một chương trình nhỏ để kiểm thửBạn có thể thực hiện mọi câu lệnh bằng việc viết 1 ca kiểm thử đơn đi quađường ace. Tức là, bằng việc đặt A=2, B=0 và X=3 tại điểm a, mỗi câu lệnh sẽ đượcthực hiện 1 lần (thực tế, X có thể được gán bất kỳ giá trị nào).23Thường tiêu chuẩn này khá kém. Ví dụ, có lẽ nếu quyết định đầu tiên là phép orchứ không phải phép and thì lỗi này sẽ không được phát hiện. Hay nếu quyết địnhthứ hai mà bắt đầu với x>0, lỗi này cũng sẽ không được tìm ra. Cũng vậy, có 1đường đi qua chương trình mà ở đó x không thay đổi (đường đi abd). Nếu đây là 1lỗi, thì lỗi này có thể không tìm ra. Hay nói cách khác, tiêu chuẩn bao phủ câu lệnhquá yếu đến nỗi mà nó thường là vô ích.2.3.1.2 Bao phủ quyết định – Decision coverageTư tưởng: Viết đủ các ca kiểm thử mà mỗi quyết định có kết luận đúng hay saiít nhất 1 lần. Nói cách khác, mỗi hướng phân nhánh phải được xem xét kỹ lưỡng ítnhất 1 lần.Các ví dụ về câu lệnh rẽ nhánh hay quyết định là các câu lệnh switch, do-while,và if-else. Các câu lệnh đa đường GOTO thường sử dụng trong một số ngôn ngữ lậptrình như FORTRAN.Bao phủ quyết định thường thỏa mãn bao phủ câu lệnh. Vì mỗi câu lệnh là trênsự bắt nguồn một đường đi phụ nào đó hoặc là từ 1 câu lệnh rẽ nhánh hoặc là từ điểmvào của chương trình, mỗi câu lệnh phải được thực hiện nếu mỗi quyết định rẽ nhánhđược thực hiện. Tuy nhiên, có ít nhất 3 ngoại lệ:• Những chương trình không có quyết định.• Những chương trình hay thường trình con/phương thức với nhiều điểmvào. Một câu lệnh đã cho có thể được thực hiện nếu và chỉ nếu chươngtrình được nhập vào tại 1 điểm đầu vào riêng.• Các câu lệnh bên trong các ON-unit. Việc đi qua mỗi hướng rẽ nhánh sẽlà không nhất thiết làm cho tất cả các ON-unit được thực thi.Vì chúng ta đã thấy rằng bao phủ câu lệnh là điều kiện cần thiết, nên một chiếnlược tốt hơn là bao phủ quyết định nên được định nghĩa bao hàm cả bao phủ câulệnh. Do đó, bao phủ quyết định yêu cầu mỗi quyết định phải có kết luận đúng hoặcsai, và mỗi câu lệnh đó phải được thực hiện ít nhất 1 lần.24Phương pháp này chỉ xem xét những quyết định hay những sự phân nhánh 2đường và phải được sửa đổi cho những chương trình có chứa những quyết định đađường. Ví dụ, các chương trình JAVA có chứa các lệnh select (case), các chươngtrình FORTRAN chứa các lệnh số học (ba đường) if hoặc các lệnh tính toán hay sốhọc GOTO, và các chương trình COBOL chứa các lệnh GOTO biến đổi hay các lệnhGO-TO-DEPENDING-ON (các lệnh goto phụ thuộc). Với những chương trình nhưvậy, tiêu chuẩn này đang sử dụng mỗi kết luận có thể của tất cả các quyết định ít nhất1 lần và gọi mỗi điểm vào tới chương trình hay thường trình con ít nhất 1 lần.Trong hình 2.1, bao phủ quyết định có thể đạt được bởi ít nhất 2 ca kiểm thửbao phủ các đường ace và abd hoặc acd và abe. Nếu chúng ta chọn khả năng thứ hai,thì 2 đầu vào test-case là A=3, B=0, X=3 và A=2, B=1, X=1.Bao phủ quyết định là 1 tiêu chuẩn mạnh hơn bao phủ câu lệnh, nhưng vẫn kháyếu. Ví dụ, chỉ có 50% cơ hội là chúng ta sẽ tìm ra con đường trong đó x không bịthay đổi (ví dụ, chỉ khi bạn chọn khả năng thứ nhất). Nếu quyết định thứ hai bị lỗi(nếu như đáng lẽ phải nói là x<1 thay vì x>1), lỗi này sẽ không được phát hiện bằng2 ca kiểm thử trong ví dụ trước.2.3.1.3 Bao phủ điều kiện – Condition coverageTư tưởng: Viết đủ các ca kiểm thử để đảm bảo rằng mỗi điều kiện trong mộtquyết định đảm nhận tất cả các kết quả có thể ít nhất một lần.Vì vậy, như với bao phủ quyết định, thì bao phủ điều kiện không phải luôn luôndẫn tới việc thực thi mỗi câu lệnh. Thêm vào đó, trong tiêu chuẩn bao phủ điều kiện,mỗi điểm vào chương trình hay thường trình con, cũng như các ON-unit, được gọi ítnhất 1 lần. Ví dụ, câu lệnh rẽ nhánh do k=0 to 50 while (j+k50 (để đến lần lặp cuối cùng của vòng lặp), j+k=quest.25

Thiết kế test-case trong kiểm thử phần mềm – Tài liệu text

Thiết kế test-case trong kiểm thử phần mềm

mtoplist