Bài giảng Software Testing and Quality Assurance: Test Cas

1Software Testing and Quality Assurance
Test Case 
Dr. Dao Nam Anh
Faculty of Information Technology
University of Technology and Management
2Resources
► Pressman, Software Engineering, McGraw Hill (chapter 18 
& 19)
► Sommerville, Software Engineering, Addison-Wesley 
(chapter 22 & 23)
► Software Testing and QA Theory and Practics, Chapter 7, 
WILEY Publish
► Foundations Of Software Testing, Istqb Certification, 
Dorothy Graham, Erik Van Veenendaal, Isabel Evans, Rex 
Black
► Jovanović, Irena, Software Testing Methods and 
Techniques
► Lâm Quang Vũ, 
3Nội dung
► Failure, Error, Fault 
► Tài liệu kiểm thử
► Ca kiểm thử (test case)
► Nội dung của test case
► Các tính chất của Test case
► Bốn giai đoạn thường có trong kiểm thử
► Quy trình kiểm thử phần mềm
► Test Cycle 
► AUT, Test case 
► QC vs QA 
► Ba chủ đề phổ biến
► Black Box vs White Box Testing 
► Problem Report 
► Document Testing 
4Tổng Quan
Failure, Error, Fault 
►Fault là thể hiện của lỗi. 
►Error là có gì sai sót trong phần mềm. 
►Failure là có gì sai trong hành vi của phần 
mềm (sai lệch yêu cầu). 
►Không có fix failure. Error và fault còn gọi 
là Bug. Có fix bug. Tỉ lệ lỗi ở phần đã kiểm 
tra thường tương tự phần chưa kiểm tra.
5Tổng Quan
Tài liệu kiểm thử: 
► Test plan: phương thức tổng quát để kiểm tra sản phẩm 
qua mục tiêu chất lượng, nhu cầu tài nguyên, lịch trình, 
nhiệm vụ, phương pháp. Test plan có thể là sản phẩm 
hoặc là công cụ. 
► Test case: các mục sẽ được kiểm tra và chi tiết từng 
bước, thường phải bao gồm luôn kết quả mong đợi. Test 
case phải được viết cho cả trường hợp hợp lệ và không 
hợp lệ. 
► Bug report: mô tả các lỗi tìm thấy và gợi ý cách sửa lỗi. 
► Công cụ kiểm tra hay kỹ thuật tự động. 
► Các ma trận, thống kê và bản tóm tắt quy trình kiểm 
thử. 
6Tổng Quan
Ca kiểm thử (Test Case)
Ca kiểm thử: dữ liệu để kiểm tra hoạt động của chương trình
Ca kiểm thử tốt
− được thiết kế để phát hiện một lỗi của chương trình
Kiểm thử thành công: phát hiện ra lỗi
Mục đích:
− Chứng minh được sự tồn tại của lỗi
− Không chứng minh được sự không có lỗi
7Tổng Quan
Nội dung của Test case
Tên mô đun/chức năng muốn kiểm thử dữ liệu vào
− dữ liệu thông thường: số, xâu kí tự, file,...
− môi trường thử nghiệm: phần cứng, OS,...
− thứ tự thao tác (khi kiểm thử giao diện)
Kết quả mong muốn
− thông thường: số, xâu kí tự, file,...
− màn hình, thời gian phản hồi
Kết quả thực tế
8Tổng Quan
Các tính chất của Test case 
Test case tốt: chính xác, tiết kiệm, có thể dùng lại, có thể
truy vết, phù hợp (với môi trường kiểm tra, tester), độc lập 
với người viết, dễ hiểu. 
Khung của test case: 
+ Phát biểu mục đích, cái gì được kiểm thử. 
+ Phương thức, cách sẽ được kiểm thử. 
+ Cơ cấu, môi trường dữ liệu. 
+ Các bước, hành động và kết quả mong đợi (trong bảng 
hoặc ma trận). 
+ Chứng cứ, tập tin, bản in, báo cáo, chụp màn hình. 
9Tổng Quan
Các tính chất của Test case 
Bảy lỗi phổ biến: 
+ Làm test case quá dài (step-by-step chỉ cần 10-15 bước). 
+ Setup khó hiểu, không chính xác hoặc không hoàn chỉnh. 
+ Bỏ mất 1 bước. 
+ Đặt tên field đã thay đổi hoặc không tồn tại. 
+ Không rõ hành động của tester hoặc hệ thống. 
+ Không rõ kết quả là pass hay fail. 
+ Không clean-up được. 
10
Tổng Quan
Các tính chất của Test case 
3 dạng test case thường dùng: step-by-step, matrix, 
automated script. 
Lợi ích của test case ngắn: 
+ Tốn ít thời gian để kiểm thử mỗi bước. 
+ Tester ít khi mắc lỗi hay cần trợ giúp. 
+ Test manager có thể ước lượng chính xác thời 
gian cần test. 
+ Kết quả dễ theo dõi. 
11
Tổng Quan
Bốn giai đoạn thường có trong kiểm thử
1. Mô hình hóa môi trường phần mềm
2. Chọn kịch bản test
3. Chạy và đánh giá kịch bản test
4. Đánh giá tiến trình kiểm thử
12
Tổng Quan
Quy trình kiểm thử phần mềm
Test 
case
Test 
data
Test 
results
Test 
reports
Design test 
cases
Prepare test 
data
Run program 
with test data
Compare 
results to test 
cases
13
Tổng Quan
Test Cycle 
1. Nhận sản phẩm
2. Clean-up hệ thống
3. Kiểm tra khả năng test
4. Xem xét các thay đổi và các phần mới
5. Xem xét những gì đã được sửa
6. Kiểm tra các phần đã được sửa
7. Kiểm tra các phần thay đổi hay các phần mới
8. Thực hiện kiểm tra hồi quy
9. Báo cáo kết quả
14
Tổng Quan
AUT, Test case 
Khi có vấn đề: 
►Lỗi ở AUT & bug
►Lỗi ở test case
►Lỗi trong quá trình thực thi
15
Tổng Quan
QC vs QA 
► Những hoạt động, những 
kỹ thuật nhằm đảm bảo 
chất lượng sản phẩm. 
► Xác định vấn đề, phân tích 
vấn đề, sửa lỗi vấn đế, 
phản hồi cho QA. 
► Sản phẩm -> phản ứng -> 
tìm lỗi 
► Kiểm duyệt, kiểm thử, 
thanh tra, kiểm tra lại. 
► Những kế hoạch, những hoạt 
động mang tính hệ thống nhằm 
đảm bảo quá trình sản xuất sẽ
tạo ra những sản phẩm có chất 
lượng. 
► Thu thập dữ liệu, phân tích 
hướng vấn đề, xác định vấn đề, 
phân tích vấn đề, cải tiến quy 
trình. 
► Tiến trình -> ước tính -> ngăn 
ngừa 
► Đảm bảo chất lượng, định nghĩa 
tiến trình, chọn lựa công cụ, 
huấn luyện. 
16
Tổng Quan
Ba chủ đề phổ biến: 
1. Đánh giá chất lượng 
2. Quản lý rủi ro 
3. Cải tiến quy trình kiểm thử
17
Tổng Quan
Black Box vs White Box Testing 
►Black Box Testing: xem phần mềm như hộp 
đen, không thể kiểm tra chính xác hoàn 
toàn, đưa ra giả định về phần cài đặt, 
thường dùng khi test tính tương thích giữa 
các thành phần, có thể test giao diện và
hành vi. 
18
Tổng Quan
Black Box vs White Box Testing 
19
Tổng Quan
Black Box vs White Box Testing 
►White Box Testing: kiểm tra cấu trúc nội tại 
của chương trình, cũng không đảm bảo 
chính xác hoàn toàn, cần bản đặc tả, cần 
kiến thức tốt về phần cài đặt, thường dùng 
để kiểm tra từng chức năng, có thể kiểm tra 
phần cài đặt và thiết kế.
20
Tổng Quan
Các cấp độ test 
►Unit test 
►Module test 
► Function test 
► System test 
+ Facility test 
+ Volume test 
+ Usability test 
+ Security test 
+ Performance test 
21
Tổng Quan
Problem Report 
Ngay khi gặp vấn đề trong phần mềm cần điền vào bản báo cáo vấn đề ngay. 
Nội dung của bản báo cáo vấn đề: 
+ Mã số, tên chương trình, mã số phiên bản. 
+ loại báo cáo: coding error, design issue, suggestion, documentation, hardware, query. 
+ Mức độ nghiêm trọng: minor, serious, fatal. 
+ Tài liệu đính kèm, tổng quát vấn đề. 
+ Khả năng tái hiện lỗi: có, không hoặc thỉnh thoảng. 
+ Giải thích lỗi và cách tái hiện lỗi (nếu có). 
+ Đề xuất cách sửa (nếu có), người lập báo cáo, ngày tháng, phần chức năng. 
+ Nhóm hoặc người quản lý phụ trách vấn đề. 
+ Người nhận, ghi chú. 
+ Trạng thái: mở, được sửa, đóng. 
+ Độ ưu tiên: sửa ngay, sửa càng sớm càng tốt, sửa trước giai đoạn kế, sửa trước khi kết 
thúc, sửa nếu có thể, không bắt buộc sửa. 
+ Trạng thái hiện tại của vấn đề: chưa quyết định, đã sửa, không thể tái hiện, hoãn lại, 
không phải lỗi, người viết lấy lại, cần thêm thông tin, không đồng ý với đề xuất, bản sao. 
+ Phiên bản phần mềm chứa thay đổi. 
+ Ký tên, được xem xét hay hoãn lại. 
22
Tổng Quan
Problem Report 
Đặc điểm: đơn giản, dễ hiểu, có thể tái sử dụng, rõ 
ràng, không mang tính phán quyết. 
Mục tiêu: 
+ Tìm hậu quả nghiêm trọng nhất. 
+ Tìm các điều kiện đơn giản nhất và tổng quát nhất. 
+ Tìm hướng phụ cho cùng vấn đề. 
+ Tìm vấn đề liên quan. 
23
Tổng Quan
Document Testing 
Bao gồm: đóng gói, tập tin readme, thẻ tham 
khảo nhanh, trợ giúp trực tuyến. 
Mục đích: cải thiện tính tiện dụng, tính tin 
cậy, tăng khả năng kinh doanh, hạ chi phí
hỗ trợ khách hàng, giảm bớt trách nhiệm 
pháp lý. 
Lợi ích: tìm nhiều lỗi hơn, test case thực tế 
hơn, lỗi tìm thấy dễ sửa hơn 
24
Q & A