1
BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC DÂN LẬP HẢI PHÒNG
PHẠM THỊ HÙY
KỸ THUẬT XÁC ĐỊNH CÁC CA KIỂM THỬ VÀ DỮ LIỆU
KIỂM THỬ NHỜ MA TRẬN KIỂM THỬ
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
CHUYÊN NGÀNH:
HỆ THỐNG THÔNG TIN
MÃ SỐ:
60480104
NGƯỜI HƯỚNG DẪN KHOA HỌC:
TS. LÊ VĂN PHÙNG
Hải Phòng, 2017
2
LỜI CẢM ƠN
Trân trọng cảm ơn tất cả các Giáo sư, Phó giáo sư, tiến sĩ, các thầy
giáo, cô giáo của khoa CNTT trường Đại học Dân lập Hải Phòng đã nhiệt tình
giảng dạy, tạo điều kiện thuận lợi cho tác giả trong quá trình học tập, nghiên
cứu, hoàn thành chương trình học tập của khóa học.
Tác giả xin trân trân trọng cảm ơn thầy TS. Lê Văn Phùng – Viện Công
nghệ thông tin – Viện Hàn Lâm khoa học và công nghệ Việt Nam đã giành
thời gian chỉ bảo tận tình giúp em hoàn thành luận văn.
Tác giả xin chân thành cảm ơn Ban giám hiệu trường THCS Thủy Sơn
đã quan tâm giúp đỡ, tạo mọi điều kiện thuận lợi cho tác giả trong suốt quá
trình học tập, nghiên cứu và hoàn thiện luận văn.
Tác giả xin cảm ơn gia đình, bạn bè, đồng nghiệp đã động viên tiếp
thêm nghị lực để tác giả hoàn thành khóa học và luận văn.
Mặc dù đã có nhiều cố gắng, song luận văn khó tránh khỏi những thiếu
sót. Tác giả rất mong sự chỉ bảo, góp ý của các nhà khoa học, các thầy cô giáo
và các bạn đồng nghiệp.
Xin trân trọng cảm ơn!
Hải Phòng, ngày 12 tháng 11 năm 2017
Tác giả
Phạm Thị Hùy
3
LỜI CAM ĐOAN
Tôi xin cam đoan rằng, đây là công trình nghiên cứu của tôi trong đó
có sự giúp đỡ rất lớn của thầy TS. Lê Văn Phùng. Các nội dung nghiên cứu và
kết quả trong đề tài này là hoàn toàn trung thực.
Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả
đã được liệt kê tại phần Tài liệu tham khảo ở cuối luận văn.
Hải Phòng, ngày 12 tháng 11 năm 2017
Tác giả
Phạm Thị Hùy
4
MỤC LỤC
LỜI CẢM ƠN ……………………………………………………………………………………… 1
MỤC LỤC
…………………………………………………………………………………………… 4
DANH MỤC CÁC KÍ HIỆU, CHỮ CÁI VIẾT TẮT ……………………………….. 7
DANH MỤC CÁC HÌNH VẼ ……………………………………………………………….. 8
DANH MỤC CÁC BẢNG…………………………………………………………………….. 8
PHẦN MỞ ĐẦU
………………………………………………………………………………… 10
1. Lý do chọn đề tài
…………………………………………………………………………….. 10
2. Mục đích nghiên cứu
……………………………………………………………………….. 11
3. Nhiệm vụ nghiên cứu ………………………………………………………………………. 12
4. Đối tượng và phạm vi nghiên cứu
……………………………………………………… 12
5. Đóng góp mới của luận văn ……………………………………………………………… 12
6. Phương pháp nghiên cứu
………………………………………………………………….. 13
CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ CA KIỂM
THỬ………………………………………………………………………………………………….. 14
1.1.Tổng quan về kiểm thử phần mềm
…………………………………………………… 14
1.1.1.Khái niệm về kiểm thử phần mềm ………………………………………………… 14
1.1.2. Mục đích của kiểm thử phần mềm
……………………………………………….. 16
1.1.3.Chiến lược kiểm thử phần mềm
……………………………………………………. 17
1.1.3.1.Khái niệm chiến lược kiểm thử
………………………………………………….. 17
1.1.3.2.Mô hình chiến lược tổng thể ……………………………………………………… 19
1.1.3.3. Một số chiến lược kiểm thử khác
………………………………………………. 21
1.1.4. Các phương pháp và kỹ thuật kiểm thử ………………………………………… 26
1.1.4.1.Một số phương pháp kiểm thử …………………………………………………… 26
1.1.4.2.Các kỹ thuật kiểm thử ………………………………………………………………. 27
1.2. Những nét chung nhất về ca kiểm thử …………………………………………….. 31
1.2.1.Khái niệm ca kiểm thử ………………………………………………………………… 31
1.2.2.Vấn đề thiết kế ca kiểm thử
………………………………………………………….. 32
5
CHƯƠNG 2. CÁC KỸ THUẬT THIẾT KẾ CA KIỂM THỬ …………………. 36
2.1. Kỹ thuật bao phủ câu lệnh (Statement Coverge) ………………………………. 37
2.1.1. Kỹ thuật bao phủ quyết định ……………………………………………………….. 37
2.1.2. Kỹ thuật bao phủ điều kiện (Condition Coverage) …………………………. 38
2.1.3. Kỹ thuật bao phủ quyết định/ điều kiện (Decision/Condition coverage) …..
38
2.1.4. Kỹ thuật bao phủ đa điều kiện (Multiple Condition Coverage) ……….. 39
2.1.5. Kiểm thử vòng lặp
……………………………………………………………………… 39
2.1.6. Kỹ thuật Điều kiện logic …………………………………………………………….. 41
2.1.7. Kỹ thuật ma trận kiểm thử ………………………………………………………….. 48
2.1.8. Ma trận kiểm thử có trọng số: ……………………………………………………… 48
2.2. Kỹ thuật phân lớp tương đương (Equivalence Patitioning)
………………… 50
2.3. Kỹ thuật phân tích giá trị biên (Boundary Value Analysis) ……………….. 53
2.4. Kỹ thuật đồ thị nguyên nhân – kết quả (Cause – Effect Graphing)
……… 55
2.5. Kỹ thuật đoán lỗi (Error Guessing)
…………………………………………………. 60
2.6. Kỹ thuật mô hình hóa
……………………………………………………………………. 62
CHƯƠNG 3. PHẦN MỀM THỬ NGHIỆM THIẾT KẾ CA KIỂM THỬ …. 67
3.1 Phương pháp và kỹ thuật áp dụng thử nghiệm ………………………………….. 67
3.2. Áp dụng thiết kế tự động ca kiểm thử cho một số mô-đun chương trình
trong bài giảng về câu lệnh có cấu trúc tại Trường THCS Thủy Sơn Hải
Phòng.
……………………………………………………………………………………………….. 77
3.2.1. Chọn lọc một số bài tập lập trình về câu lệnh có cấu trúc tại trường
THCS Thủy Sơn Hải Phòng.
………………………………………………………………… 77
3.2.2. Đặc tả các mô-đun chương trình theo các bài toán đã chọn (input) theo
3 cấp độ dễ, trung bình, khó
…………………………………………………………………. 78
3.3. Một số giao diện chính của chương trình
…………………………………………. 88
3.3.1. Form chính ……………………………………………………………………………….. 88
3.3.2. Form chọn dường dẫn tới dữ liệu
…………………………………………………. 88
3.3.3. Hiển thị dữ liệu
………………………………………………………………………….. 88
3.3.4. Tính toán độ phức tạp ………………………………………………………………… 89
6
3.3.5. Xuất ra các phương án kiểm thử ………………………………………………….. 89
3.4. Đánh giá kết quả thử nghiệm và hướng phát triển
…………………………….. 90
3.4.1. Đánh giá …………………………………………………………………………………… 90
KẾT LUẬN ……………………………………………………………………………………….. 91
TÀI LIỆU THAM KHẢO
……………………………………………………………………. 92
1. Tiếng việt
……………………………………………………………………………………… 92
2. Tiếng Anh
……………………………………………………………………………………… 92
7
DANH MỤC CÁC KÍ HIỆU, CHỮ CÁI VIẾT TẮT
CNTT
Công nghệ thông tin
CSDL
Cơ sở dữ liệu
Software technology
Công nghệ phần mềm
Software Engineering
Kỹ nghệ phần mềm
Software testing
Kiểm thử phần mềm
Software quality assurance (SQA)
Bảo đảm chất lượng phần mềm
Template
Tiêu bản
Test case
Ca kiểm thử
Comparision testing
Kiểm thử so sánh
Dynamic testing
Kiểm thử động
Acceptance testing
Kiểm thử chấp thuận
Statement Coverge
Bao phủ câu lệnh
Decision coverage
Bao phủ quyết định
Decision/ Condition coverage
Bao phủ quyết định/ điều kiện
Equivalence Patitioning
Phân lớp tương đương
Branch and Relational Operation
Chiến lược kiểm thử
8
DANH MỤC CÁC HÌNH VẼ
Hình 1.1.Mô hình chiến lược kiểm thử tổng thể
……………………………………… 20
Hình 2.1. Xác định các ca kiểm thử bằng đường cơ bản và điều kiện ……….. 45
Hình 2.2. Đồ thị dòng để xác định tập đường cơ bản nhỏ nhất phủ các lệnh
. 46
Hình 2.4. Xác định điều kiện cho đường cơ bản …………………………………….. 47
Hình 2.5. Phân chia lớp tương đương ……………………………………………………. 53
Hình 2.6. Mô hình phân hoạch và phân tích giá trị biên
…………………………… 55
Hình 2.7. Các bước tiến hành theo kỹ thuật đồ thị nhân- quả …………………… 58
Hình 2.8. Xây dựng đồ thị nhân -quả bằng đồ thị
……………………………………. 59
Hình 2.9. Các phương án lựa chọn ca kiểm thử
………………………………………. 60
Hình 2.10. Sơ đồ trang thái hệ thống thang máy …………………………………….. 63
Hình 3.1. Các cấu trúc cơ bản của đồ thị dòng (sequence,if, while, until, case) .67
Hình 3.2. Sơ đồ điều khiển của chương trình …………………………………………. 69
Hình 3.3. Sơ đồ luồng điều khiển …………………………………………………………. 70
Hình 3.4. Đồ thị dòng
………………………………………………………………………….. 70
Hình 3.5. Độ phức tạp chu trình xác định từ đồ thị dòng …………………………. 71
Hình 3.6. Sơ đồ điều khiển của chương trình …………………………………………. 73
Hình 3.7. Sơ đồ luồng điều khiển gộp …………………………………………………… 73
Hình 3.8. Đồ thị dòng
………………………………………………………………………….. 74
Hình 3.9. Đồ thị dòng dùng để xác định ma trận kiểm thử ………………………. 74
DANH MỤC CÁC BẢNG
9
Bảng 2.1. Bảng kiểm thử kết quả ra
………………………………………………………. 43
Bảng 2.2. Bảng kiểm thử có ràng buộc
………………………………………………….. 43
Bảng 2.3. Tập các giá trị bảo đảm các ràng buộc đầu ra ………………………….. 43
Bảng 2.4. Tập các giá trị bảo đảm các ràng buộc đầu ra của C …………………. 44
Bảng 2.5. Xác định các đầu ra để kiểm thử ……………………………………………. 44
Bảng 2.6. Tập đường cơ bản nhỏ nhất phủ các lệnh
………………………………… 47
Bảng 2.6. Dữ liệu kiểm thử theo tập đường cơ bản …………………………………. 47
Bảng 2.7. Danh sách nhân- quả theo mô-đun ………………………………………… 59
Bảng 2.8. Bảng quyết định của đồ thị nhân – quả ……………………………………. 60
Bảng 2.9. Bảng dữ liệu phục vụ cho ca kiểm thử 1 …………………………………. 64
Bảng 2.10. Bảng dữ liệu phục vụ cho ca kiểm thử 2:
………………………………. 65
Bảng 2.11. Kế hoạch kiểm thử hai trạng thái tầng (lên, xuống) và đồng bộ:
. 65
Bảng 3.1. Tập đường cơ bản ……………………………………………………………….. 72
Bảng 3.2 Bảng tính độ phức tạp của đồ thị dòng V(G): …………………………… 75
Bảng 3.3 Bảng ma trận kiểm thử A = (aij) …………………………………………….. 76
Bảng 3.4 Tập đường kiểm thử ……………………………………………………………… 77
10
PHẦN MỞ ĐẦU
1. Lý do chọn đề tài
Khoa học kỹ thuật ngày càng phát triển với tốc độ cao, hàng loạt các
sản phẩn phần mềm được đưa ra phục vụ cho con người. Mỗi ngày chúng ta
nghe đâu đó tin tức về vấn đề an toàn, bảo mật thông tin, một ngân hàng báo
cáo số dư tài khản không chín xác, một đoàn tầu bị va chạm, một máy bay bị
mất trong không gian hoặc một hacker truy cập đến hàng triệu thẻ tín dụng.
Tại sao điều này xẩy ra? Có thể do lập trình viên máy tính không tìm ra cách
để làm cho phần mềm đơn giản?
Phần mềm ngày càng trở nên phức tạp hơn, có được nhiều tính năng
hơn, được thiết kế nối với nhau nhiều hơn và cũng có nhiều trục trặc hơn từ
chương trình. Việc xây dựng và phát triển phần mềm ngày càng được nâng
cao hơn bằng các công cụ hỗ trợ tiên tiến. Nhờ vào đó mà các chuyên gia phát
triển thực hiện hiệu quả và đem lại nhiều lợi nhuận hơn trước. Tuy nhiên với
công nghệ ngày càng cao thì đòi hỏi mức độ ứng dụng lớn và phát sinh ra sự
phức tạp cùng với chi phí, thời gian tăng lên. Do đó phương pháp để cải thiện
điều này chính là thực hiện kết hợp giữa xây dựng và quá trình kiểm thử. Hầu
hết các công ty phần mềm lớn đều cam kết về chất lượng phần mềm do họ tạo
ra, đó là một trong những nhiệm vụ khó khăn nhất hiện nay. Có nhiều lí do
cho việc này:
Một sản phẩn phần mềm không phải là một đối tượng hữu hình có thể
do được, cơ thể cảm thấy hoặc lấy mẫu vì vậy rất khó khăn để thử nghiệm
một sản phẩm phần mềm.
Kiểm thử phần mềm vẫn không được coi là một trao đổi thương mại
được công nhận, do đó việc tìm kiếm được những người chuyên nghiệp đủ
điều kiện cho các công việc thử nghiệm là khó khăn.
Không giống như quá trình sản xuất đã được xác định và tiêu chuẩn
hóa thiết kế sản phẩn trong quá trình, kiểm soát chất lượng, quy trình tương tự
như tiêu chuẩn hóa vẫn chưa được xác định để thử nghiệm phần mềm.
11
Các công cụ tự động hóa hoạt động kiểm thử phần mềm vẫn còn trong
giai đoạn mới bắt đầu, còn phải mất nhiều thời gian để có các công cụ tự động
hóa tinh vi có sẵn cho các hoạt động kiểm thử phần mềm.
Nỗ lực tìm kỹ thuật mới cho các hoạt động thử nghiệm phần mềm vẫn
đang được phát triển…
Tầm quan trọng của kiểm thử phần mềm là quá bao la bất cứ thất bại
của sản phẩm phần mềm hoặc ứng dụng đều có thể gây thiệt hại hàng tỷ đồng
cho công ty. Thậm chí nếu các lỗi phần mềm không phải là quá lớn, chi phí
hỗ trợ để có thể chạy thử cũng mất cả chục tới trăm triệu trong vòng đời của
sản phẩm phần mềm.
Một khiếm khuyết trong sản phẩn là gì? làm thế nào nó ảnh hưởng đến
người sử dụng, những gì người dùng cảm thấy khi tìm thấy một khiếm khuyết
trong sản phẩn sau khi mua và sử dụng nó, làm thế nào để ngăn ngừa nó, và
cuối cùng là làm thế nào để xác định và loại bỏ các khuyết điểm đó.
Các phương pháp thiết kế ca kiểm thử và ứng dụng có vai trò cực kỳ
quan trọng trong việc đưa một ứng dụng bảo đảm chất lượng vào thực tế.
Kiểm thử là một trong những giai đoạn của quá trình phát triển, hoàn
thành sản phẩm. Trước khi sản phẩm được phát hành tất cả các chức năng
cũng như giao diện, ứng dụng của sản phẩm đó đều cần qua kiểm thử. Một
sản phẩm tuy được thiết kế tốt nhưng cũng không thể tránh khỏi các sai sót.
Kiểm thử hiệu quả sẽ phát hiện ra được các sai sót này, tránh các lỗi trước khi
phát hành sản phẩm. Kiểm thử đứng dưới vai trò của người sử dụng, sẽ giúp
cho sản phẩm có sự thích ứng phù hợp hơn với thị hiếu và nhu cầu ngày càng
cao của người dùng. Vì vậy, cần nghiên cứu về cách thiết kế ca kiểm thử để
kiểm thử hiệu quả, đặc biệt là cách thiết kế có khả năng số hóa. Đó cũng là lý
do mà tôi chọn đề tài “Kỹ thuật xác định các ca kiểm thử và dữ liệu kiểm
thử nhờ ma trận kiểm thử” làm luận văn thạc sĩ của mình.
2. Mục đích nghiên cứu
Xác định vai trò của phương pháp ca kiểm thử và ứng dụng trong
nghiên cứu khoa học và chế tạo sản phẩm. Trên cơ sở nghiên cứu và phân tích
12
các giải pháp an toàn trong việc kiểm thử sản phẩm, phân phối, trao đổi, cũng
như các phương thức quản lý nhằm mang lại hiệu quả cao nhất trong quá trình
đưa một sản phẩm nào đó vào ứng dụng thực tế.
Kiểm thử giúp rút ngắn thời gian và giảm chi phí cho sản phẩm phần
mềm. Nó giúp cho các chuyên gia kiểm thử tìm ra lỗi trong quá trình tạo ra
phần mềm và đảm bảo hơn về chất lượng. Kiểm thử thực hiện chặt chẽ sẽ hạn
chế lỗi, tuy nhiên trong phần mềm vẫn còn tiềm ẩn các lỗi và có thể phát sinh
bất cứ lúc nào dẫn đến khả năng gây thiệt hại cho nhà sản xuất vì vậy cần
thực hiện quá trình kiểm thử liên tục, xuyên suốt trong các giai đoạn phát
triển của phần mềm. Đó là phương pháp tốt nhất để đảm bảo cho các yêu cầu
của người dùng về thiết kế và ứng dụng phần mềm được đáp ứng đầy đủ.
3. Nhiệm vụ nghiên cứu
Nghiên cứu các lý thuyết tổng quan về phương pháp ca kiểm thử và
ứng dụng: Các khái niệm cơ bản, tiến trình kiểm thử, các phương pháp, kỹ
thuật kiểm thử và ứng dụng.
Nghiên cứu về phương pháp thiết kế ca kiểm thử và ứng dụng, các vấn
đề cần lưu ý khi thiết kế, kiểm thử và ứng dụng sản phẩm.
Ứng dụng thử nghiệm đối với phương pháp ca kiểm thử và ứng dụng,
nêu các kết quả đạt được, chưa đạt được và hướng giải quyết các vấn đề khi
kiểm thử và ứng dụng sản phẩm.
4. Đối tượng và phạm vi nghiên cứu
Đối tượng nghiên cứu của đề tài tập trung vào các phương pháp ca
kiểm thử và ứng dụng phần mềm và phần cứng.
Phạm vi nghiên cứu của đề tài được giới hạn trong vấn đề kiểm thử
hộp trắng và ma trận kiểm thử.
Để kiểm thử không mất nhiều thời gian và chi phí, người ta bắt đầu đưa nó
vào trong các ứng dụng xây dựng phần mềm để có thể kết hợp chúng lại với nhau.
Việc làm này biến quy trình kiểm thử thành quy trình bắt buộc thực hiện trong
mỗi dự án phần mềm. Nhưng để có hiệu quả cao nhất người kiểm thử cần có
phương án, kế hoạch hay chiến lược riêng cho từng ứng dụng phần mềm.
5. Đóng góp mới của luận văn
13
Xác định được các tiêu chuẩn thích hợp cho việc chọn phương pháp
thiết kế ca kiểm thử và dữ liệu kiểm thử nhờ ma trân kiểm thử.
6. Phương pháp nghiên cứu
– Phương pháp tổng hợp phân tích các vấn đề liên quan đến đề tài.
– Phương pháp thống kê kết hợp với phương pháp chuyên gia.
– Phương pháp kết hợp lý thuyết với thực nghiệm trên máy tính.
7. Những nội dung chính của luận văn:
Bố cục của luận văn gồm 3 chương:
Chương 1: Tổng quan về kiểm thử phần mềm và ca kiểm thử: Khái
niệm về kiểm thử phần mềm, chiến lược kiểm thử phần mềm, các phương
pháp và kỹ thuật kiểm thử. Những nét chung nhất về ca kiểm thử: Khái niệm
ca kiểm thử, vấn đề thiết kế ca kiểm thử.
Chương 2: Các kỹ thật thiết kế ca kiểm thử gồm: Kỹ thuật bao phủ
câu lệnh, kỹ thuật phân lớp tương đương, kỹ thuật phân tích giá trị biên, kỹ
thuật đồ thị nguyên nhân – kết quả, kỹ thuật đoán lỗi.
Chương 3: Phần mềm thử nghiệm thiết kế ca kiểm thử: Kỹ thuật bao
phủ câu lệnh dựa vào ma trận kiểm thử để thiết kế ca kiểm thử và dữ liệu
kiểm thử, áp dụng thiết kế tự động ca kiểm thử cho một số mô-đun chương
trình trong bài giảng về câu lệnh có cấu trúc tại Trường THCS Thủy Sơn Hải
Phòng.
14
CHƯƠNG 1
TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ CA KIỂM THỬ
1.1.Tổng quan về kiểm thử phần mềm
1.1.1.Khái niệm về kiểm thử phần mềm
Kiểm thử phần mềm (software testing) là một trong những yếu tố góp
phần bảo đảm chất lượng phần mềm (SQA), là khâu điển hình kiểm soát đặc
tả, thiết lập, lập mã.
Theo Glen Myers: “Kiểm thử phần mềm là quá trình vận hành chương
trình để tìm ra lỗi”.
Cần vận hành như thế nào để:
– Hiệu suất tìm ra lỗi là cao nhất.
– Chi phí (thời gian, công sức) ít nhất.
(Giáo trình kỹ nghệ phần mềm. Nguyễn Văn Vỵ, Nguyễn Việt Hà. Nhà
xuất bản Giáo dục Việt Nam năm 2009)
Kiểm thử phần mềm được đặt ra với những lý do:
– Muốn nhận diện phần mềm như một phần tử của hệ thống hoạt
động.
– Hạn chế chi phí cho các thất bại do lỗi gây ra sau này (hiệu quả)
– Có kế hoạch tốt nâng cao chất lượng suốt quá trình phất triển (giải
pháp).
Kiểm thử giữ vai trò lớn trong quá trình phát triển phần mềm. Xét theo
tiêu chí về chi phí thì kiểm thử chiếm:
– 40% công sức phát triển;
– ≥ 30% tổng thời gian phát triển;
– Với các phần mềm có ảnh hưởng tới sinh mạng, chi phí có thể gấp
từ 3 đến 5 lần tổng các chi phí khác cộng lại.
– Giảm chi phí phát triển;
– Tăng độ tin cậy của sản phẩm phần mềm.
Vấn đề đặt ra là cần vận hành phần mềm như thế nào để:
15
– Hiệu suất tìm ra lỗi là cao nhất?
– Chi phí (thời gian, công sức) ít nhất?
Mục tiêu trước mắt của kiểm thử phần mềm là tạo ra các ca kiểm thử để
tìm ra lỗi của phần mềm.
Mục đích cuối cùng của kiểm thử phần mềm nhằm có một chương trình
tốt, chi phí ít.
Glen Myers phát biểu một số quy tắc giống như mục đích kiểm thử:
Kiểm thử là một tiến trình thực hiện một chương trình với ý định tìm
ra lỗi.
Một ca kiểm thử là một trường hợp kiểm thử có xác suất cao để tìm
ra lỗi.
Việc kiểm thử thành công là việc kiểm thử làm lộ ra một lỗi còn chưa
được phát hiện.
Các mục đích trên dẫn đến một sự thay đổi lớn trong quan điểm.Chúng
đi ngược lại quan điểm thông thường là một phép kiểm thử thành công là
kiểm thử không tìm ra lỗi nào. Mục đích của chúng ta là thiết kế các ca kiểm
thử để làm lộ ra một cách có hệ thống những lớp lỗi khác nhau và làm như
vậy với một số lượng thời gian và công sức ít nhất.
Nếu kiểm thử được tiến hành thành công, thì nó sẽ làm lộ ra những lỗi
trong phần mềm. Việc kiểm thử phần mềm làm việc theo đặc tả nên các yêu
cầu hiệu năng dường như là được đáp ứng. Bên cạnh đó, dữ liệu thu thập
được khi việc kiểm thử tiến hành đưa ra một chỉ dẫn tốt về độ tin cậy phần
mềm và một chỉ dẫn nào đó về phẩm chất phần mềm với tư cách toàn cục.
Có một điều mà kiểm thử không thể làm được: Kiểm thử không thể
chứng minh được việc không có khiếm khuyết, nó chỉ có thể chứng minh
được khiếm khuyết phần mềm hiện hữu.
Khi kiểm thử, người ta đưa ra những khái niệm về ca kiểm thử “tốt” và
“thắng lợi”:
– Ca kiểm thử tốt là ca kiểm thử có xác suất cao tìm ra 1 lỗi.
16
– Ca kiểm thử thắng lợi là ca kiểm thử làm lộ ra ít nhất một lỗi.
Vấn đề đặt ra ở chỗ nếu không tìm được lỗi nào thì có thể kết luận phần
mềm hoàn hảo? Câu trả lời chung là chưa hẳn như vậy.
Kiểm thử có nhiều lợi ích, trong đó phải kể đến các lợi ích quan trọng:
– Ca kiểm thử thắng lợi làm lộ ra khiếm khuyết
– Kiểm thử mang lại các lợi ích phụ là thuyết minh:
+ Chức năng tương ứng với đặc tả,
+ Thực thi phù hợp yêu cầu và đặc tả,
+ Cung cấp các chỉ số tin cậy và chất lượng.
Tuy kiểm thử có nhiều lợi ích như trên nhưng chưa thể khẳng định
phần mềm không còn khiếm khuyết.
1.1.2. Mục đích của kiểm thử phần mềm
Cũng giống như các sản phẩm máy móc và các hệ thống vật lý, mục
đích của kiểm thử phần mềm là để đảm bảo hệ thống phần mềm có thể làm
việc tốt như mong muốn khi chúng được đem ra thị trường tới tay khách hàng
và người sử dụng. Cách thường dùng để đưa ra những kiểm chứng về chất
lượng cho sản phẩm là đưa sản phẩm vào “chạy thử” hay được kiểm tra trong
phòng thí nghiệm trước khi phân phối sản phẩm ra thị trường. Trong ngành
Công Nghệ Phần Mềm, các sản phẩm phần mềm được kiểm tra, chạy thử
được gọi chung là kiểm thử phần mềm.
Mục đích của việc kiểm thử phần mềm là gì? Kiểm thử phần mềm
nhằm vào hai mục đích chính là: Đưa ra những chứng nhận về chất lượng và
phát hiện sửa lỗi phần mềm.
Quy trình kiểm thử phần mềm
Những hành động chính của kiểm thử phần mềm là:
+ Chuẩn bị và lập kế hoạch kiểm thử: Đặt ra các mục tiêu cụ thể cho
việc kiểm thử, chọn chiến lược kiểm thử, chuẩn bị các trường hợp kiểm thử
cụ thể và các thủ tục kiểm thử.
17
+ Thực thi: Tiến hành kiểm thử theo kế hoạch, quan sát và thu thập các
kết quả.
+ Phân tích và theo dõi: Trên những kết quả thu được, phân tích để tìm
lỗi. Nếu một lỗi nào đó xuất hiện thì đưa ra giải pháp sửa đổi, sửa đổi và tiếp
tục theo dõi tới khi lỗi đó được sửa.
Điểm quan trọng trong thực thi kiểm thử đó là tránh để lỗi từ một
trường hợp kiểm thử ảnh hưởng đến các trường hợp kiểm thử khác.
1.1.3.Chiến lược kiểm thử phần mềm
1.1.3.1.Khái niệm chiến lược kiểm thử
Chiến lược kiểm thử là sự tích hợp các kỹ thuật thiết kế ca kiểm thử
tạo thành một dãy các bước nhằm hướng dẫn quá trình kiểm thử phần mềm
thành công.
Chiến lược kiểm thử được đặt ra với mục tiêu nhằm phác thảo một lộ
trình để:
– Nhà phát triển tổ chức việc bảo đảm chất lượng bằng kiểm thử,
– Khách hàng hiểu được công sức, thời gian và nguồn lực cần cho
kiểm thử.
Chiến lược kiểm thử cần phải đạt những yếu cầu sau:
– Tích hợp được các khâu như lập kế hoạch, thiết kế ca kiểm thử, tiến
hành kiểm thử, thu thập và đánh giá các thong tin kết quả.
– Đủ mềm dẻo để cổ vũ óc sáng tạo, đáp ứng được nhu cầu khách
hàng
– Thích ứng với mức kiểm thử cụ thể
– Đáp ứng các đối tượng quan tâm khác nhau.
Kiểm thử là một tập hợp những hoạt động mà có thể được lập kế hoạch
trước và tiến hành một cách có hệ thống. Một tập các bước mà trong đó chúng
ta có thể vận dụng những kỹ thuật thiết kế ca kiểm thử và phương pháp kiểm
thử có những đặc trưng mang tính “khuôn mẫu”:
18
– Bắt đầu ở mức mô-đun và tiếp tục cho đến khi tích hợp ở mức hệ
thống trọn vẹn.
– Các kỹ thuật kiểm thử khác nhau là thích hợp cho những thời điểm
khác nhau.
– Được cả người phát triển và nhóm kiểm thử độc lập cùng tiến hành.
– Kiểm thử đi trước gỡ lỗi, song việc gỡ lỗi phải thích ứng với từng
chiến lược kiểm thử.
Chiến lược cần thích ứng với từng mức kiểm thử và phải đưa ra hướng
dẫn cho người thực hành và một tập các cột mốc cho người quản lý. Có hai
mức kiểm thử:
– Kiểm thử mức thấp: thẩm định từng đoạn mã nguồn xem có tương
ứng và thực thi đúng đắn hay không?
– Kiểm thử mức cao: thẩm định và xác minh các chức năng hệ thống
chủ yếu có đúng đặc tả và đáp ứng yêu cầu của khách hàng hay
không?
Mỗi chiến lược đáp ứng được yêu cầu cần quan tâm:
– Có các hướng dẫn cho người thực hiện tiến hành kiểm thử.
– Có các cột mốc cho các nhà quản lý kiểm soát hoạt động bảo đảm
chất lượng.
– Có thước đo để đo và nhận ra các vấn đề càng sớm càng tốt.
– Khách hàng có thể nhận biết được quá trình kiểm thử.
Việc kiểm thử cung cấp một thành lũy cuối cùng để có thể thẩm định
về chất lượng và có thể phát hiện ra lỗi.
Có một số quan điểm sai lầm:
– Người phát triển không nên tham gia kiểm thử.
– Cho phép người lạ kiểm thử một cách thô bạo.
– Người kiểm thử chỉ quan tâm khi kiểm thử bắt đầu.
Nên xuất phát từ thực tiễn mà phân công trách nhiệm thử:
19
– Người phát triển chịu trách nhiệm kiểm thử đơn vị do mình phát
triển để bảo đảm thực hiện theo đúng thiết kế, có thể tham gia kiểm
thử tích hợp; không khoán trắng chương trình cho người kiểm thử mà
phải cùng làm việc với người kiểm thử xuyên suốt dự án.
– Nhóm kiểm thử độc lập bắt đầu làm việc khi các khoản mục cấu trúc
phần mềm đã đầy đủ, giúp gỡ bỏ những thành kiến: “người xây dựng
không thể kiểm thử tốt sản phẩm”, gỡ bỏ mâu thuẫn giữa những người
tham gia; đánh giá công sức người phát triển bỏ ra tìm lỗi; tạo ra báo
cáo đầy đủ cho tổ chức bảo đảm chất lượng phần mềm.
1.1.3.2.Mô hình chiến lược tổng thể
Về mặt kỹ nghệ, việc kiểm thử gồm một số bước được thực hiện tuần
tự. Ban đầu, việc kiểm thử tập trung vào từng mô-đun riêng biệt bảo đảm nó
ban hành đúng đắn như một đơn vị. Do đó mới có tên kiểm thử đơn vị. Kiểm
thử đơn vị dùng rất nhiều các kỹ thuật kiểm thử hộp trắng, kiểm soát các
đường đặc biệt trong cấu trúc điều khiển của một lớp mô-đun nhằm phát hiện
tối đa các lỗi. Mặt khác, các mô-đun phải được lắp ghép hay tích hợp lại để
tạo nên phần mềm hoàn chỉnh.
Việc kiểm thử tích hợp có liên quan đến thẩm định và xây dựng chương
trình. Các kỹ thuật thiết kế kiểm thử hộp đen được dùng trong hầu hết quá
trình tích hợp, mặc dù các kiểm thử hộp trắng cũng có thể được dùng để bao
quát đa số các đường điều khiển. Sau khi phần mềm đã được dùng tích hợp
(được xây dựng), một tập hợp các phép kiểm thử sẽ được tiến hành. Các tiêu
chuẩn hợp lệ (được thiết lập trong phân tích yêu cầu) cũng phải được kiểm
thử.Việc kiểm thử hợp lệ được tiến hành nhằm bảo đảm phần mềm đáp ứng
đầy đủ các yêu cầu chức năng. Các kỹ thuật kiểm thử hộp đen được dùng chủ
yếu trong kiểm thử hợp lệ.
Kiểm thử hệ thống nằm trong khung cảnh rộng hơn của kỹ nghệ hệ
thống máy tính. Khi làm hợp lệ, phần mềm phải được tổ hợp với các phần tử
20
hệ thống khác (như phần cứng, con người, CSDL).Vì vậy, kiểm thử hệ thống
là rất quan trọng.
(Trích trang 46. Kỹ thuật phần mềm – Lê Văn Phùng – Nhà xuất bản
thông tin truyền thông năm 2010)
Cuối cùng, kiểm thử chấp nhận sẽ thẩm định lại rằng tất cả các thành
phần có phối khớp với nhau không, cũng như chức năng hay độ hoàn thiện
của hệ thống có đạt được không.
Hình 1.1.Mô hình chiến lược kiểm thử tổng thể
Phân tích
yêu cầu
Kế hoạch kiểm
thử chấp nhận
Đặc tả hệ
thống
Kế hoạch
kiểm thử hệ
thống
Thiết kế
kiến trúc
Kế hoạch
kiểm thử tích
hợp
Thiết kế
chi tiết
Lập trình
Test chấp nhận
Test hệ thống
Test tích hợp
Test đơn vị
Rà soát mã
Xác minh
Thẩm định
Thẩm định
21
Hình 1.2. Mô hình tiến trình thực hiện kiểm thử
1.1.3.3. Một số chiến lược kiểm thử khác
Ngoài chiến lược kiểm thử tổng thể, người ta còn tiến hành một loạt
các chiến lược kiểm thử bổ trợ khác như:
– Kiểm thử hệ thời gian thực
– Kiểm thử Alpha và Beta
– Kiểm thử so sánh.
1. Chiến lược kiểm thử hệ thời gian thực
Hệ thời gian thực là hệ thống đáp ứng đúng, chính xác các sự kiện của
môi trường.
Kiểm thử hệ thống thời gian thực là rất khó. Những người thiết kế ca
kiểm thử không chỉ phải xem xét các trường hợp kiểm thử hộp đen và hộp
trắng mà còn phải xem xét cả việc chia thời gian cho dữ liệu cà cơ chế song
song cho các nhiệm vụ (tiến trình) giải quyết dữ liệu đó.Trong nhiều tình
huống, trạng thái của hệ thống cũng có thể dẫn tới lỗi.
Mối quan hệ mật thiết giữa phần mềm thời gian thực và môi trường
phần cứng của nó cũng có thể gây ra các vấn đề cho kiểm thử.Việc kiểm thử
22
phần mềm phải xem xét tác động của các lỗi phần cứng đến xử lý phần
mềm.những lỗi như thế rất khó mô phỏng sát thực tế.
Để khắc phục khó khăn trên, chiến lược kiểm thử được vạch ra theo 4
bước thực hiện:
Bước 1: Kiểm thử tác vụ
Kiểm thử từng tác vụ một cách độc lập với nhau (bằng kiểm thử hộp
trắng và hộp đen).
Kiểm thử tác vụ cho phép phát hiện sai về logic và chức năng nhưng
không phát hiện sai về thời gian và ứng xử.
Bước 2: Kiểm thử ứng xử
Trước hết sử dụng công cụ CASE tạo mô hình hệ thống để mô phỏng
ứng xử, xem ứng xử như hậu quả của sự kiện tác động từ ngoài vào.
Sau đó dựng kết quả hoạt động phân tích này để thiết kế các ca kiểm
thử (tương tự kỹ thuật đồ thị nhân quả).
Tiếp theo, phân lớp sự kiện (phân hoạch tương đương). Kiểm thử từng
lớp sự kiện và nhận ứng xử của hệ thi hành để phát hiện các sai do xử lý đáp
ứng các sự kiện đó.
Cuối cùng, kiểm thử mọi lớp sự kiện. Các sự kiện được đưa vào trong
hệ thống theo thứ tự ngẫu nhiên và với tần xuất ngẫu nhiên nhằm phát hiện
các lỗi ứng xử.
Bước 3: Kiểm thử liên tác
Kiểm thử liên tác là kiểm thử để tìm các sai liên quan đến thời gian đáp
ứng do không đồng bộ:
– Các tác vụ không đồng bộ khi liên tác với các tác vụ khác. Vì thế cần
kiểm thử với nhịp điệu dữ liệu và mức tải với các xử lý khác nhau.
– Các tác vụ không đồng bộ do giao tiếp phụ thuộc hàng đợi thông điệp
hoặc truy nhập kho dữ liệu cũng được thử để bộc lộ các lỗi về quy mô dữ liệu.
23
Bước 4: Kiểm thử toàn hệ thống
Tích hợp phần cứng và phần mềm nhằm tìm lỗi trên các phương diện:
– Giao diện (giữa phần cứng và phần mềm)
– Môi trường (tác động từ môi trường, các sự kiện).
– Các ngắt (các loại ngắt và các xử lý xảy ra như hậu quả của ngắt).
2. Kiểm thử Alpha và Beta
Kiểm thử alpha (alpha testing) và kiểm thử beta (beta testing) đều do
người dùng thực hiện và đều được thực hiện trong môi trường thực.
Người phát triển không thể nào lường hết được khách hàng sẽ dùng
chương trình như thế nào. Các hướng dẫn sử dụng có thể bị hiểu sai, việc tổ
hợp dữ liệu lạ lại có thể hay được dùng, cái ra dường như rõ ràng với người
kiểm thử, nhưng có thể lại khó hiểu đối với người dùng.
+ Kiểm thử Alpha
Kiểm thử Alpha được khách hàng tiến hành tại cơ quan của người phát
triển. Phần mềm được dùng theo sự sắp đặt tự nhiên với người phát triển
(nhìn qua vai) người dùng và ghi lại các lỗi khi sử dụng. Kiểm thử Alpha còn
có tên khác là kiểm thử “sau lưng” và được tiến hành trong một môi trường
có kiểm soát.
Dữ liệu cho kiểm thử Alpha là dữ liệu mô phỏng.
+ Kiểm thử Beta
Kiểm thử Beta được người dùng cuối tiến hành tại một hay nhiều cơ
quan khách hàng. Không giống kiểm thử Alpha, người phát triển thường
không có mặt. Do đókiểm thử Beta là việc áp dụng “sống” của phần mềm
trong một môi trường mà người phát triển không thể nào kiểm soát được.
Khách hàng ghi lại tất cả các vấn đề (thực hay tưởng tượng) gặp phải trong
khi kiểm thử Beta và báo cáo lại những vấn đề đó cho người phát triển trong
những khoảng thời gian đều đặn. Xem như một kết quả của vấn đề được báo
cáo trong kiểm thử Beta, người phát triển tiến hành sửa đổi rồi chuẩn bị đưa
ra sản phẩm phần mềm cho toàn bộ khách hàng.
24
Trường hợp kiểm thử Alpha và Beta cho 1 khách:
– Khi các phần mềm dành cho một người đặt hàng, thì hoạt động kiểm
thử chỉ cần một khách hàng tiến hành thẩm định mọi yêu cầu.
– Kiểm thử này do người sử dụng cuối cùng thực hiện, không phải là
người đặt hàng.
– Kiểm thử chấp nhận có thể tiến hành vài tuần hoặc vài tháng một lần,
nhờ đó mà bộc lộ được các lỗi tích lũy làm suy giảm hệ thống theo thời gian.
Trường hợp kiểm thử Alpha và Beta cho n khách:
Với phần mềm dành cho nhiều khách hàng, thì kiểm thử chấp nhận
bằng một khách hàng là không thực tế.Quá trình kiểm thử Alpha và Beta cho
nhiều người tiến hành là bắt buộc.
3. Kiểm thử so sánh
Có một số tình huống (như điều khiển máy bay, điều khiển nhà máy
năng lượng hạt nhân) mà trong đó độ tin cậy của phần mềm là yếu tố hàng
đầu.Trong những ứng dụng như vậy, phần cứng và phần mềm thường được
yêu cầu tối thiểu hóa khả năng lỗi. Khi phần mềm được phát triển, nhóm kỹ
nghệ phần mềm tách biệt sẽ phát triển những bản độc lập ứng dụng bằng cách
dùng cùng đặc tả.Trong những tình huống như thế, mỗi bản có thể được kiểm
thử với cùng dữ liệu để đảm bảo rằng tất cả đều cho kết quả giống nhau.
Các nhà nghiên cứu đã gợi ý rằng các bản phần mềm độc lập được phát
triển. Những bản độc lập này tạo nền cho kỹ thuật kiểm thử hộp đen được gọi
là kiểm thử so sánh (comparision testing) hay kiểm thử dựa vào nhau (back-
to-back testing).
Khi tạo ra nhiều cài đặt cho cùng một đặc tả, các ca kiểm thử được thiết
kế để dùng những kỹ thuật hộp đen khác (như phân hoạch tương đương) được
xem như từng bản đầu vào của phần mềm. Nếu kết quả ra của mỗi bản là
giống nhau thì người ta giả thiết rằng tất cả các cài đặt đều đúng. Nếu kết quả
ra là khác nhau thì từng ứng dụng sẽ được nghiên cứu lại để xác định liệu một
khiếm khuyết trong một hay nhiều bản có phải là nguyên nhân sinh ra sự khác
25
biệt hay không.Trong phần lớn các trường hợp, việc so sánh các kết quả ra có
thể được thực hiện tự động.
Việc kiểm thử so sánh không đơn giản. Nếu đặc tả mà từ đó tất cả các
phiên bản đã được xây dựng ra bị lỗi thì mọi bản đều có thể phản ánh lỗi
đó.Mặt khác, nếu từng bản độc lập lại tạo ra kết quả giống nhau, nhưng không
đúng, thì việc kiểm thử điều kiện sẽ không phát hiện được lỗi.
Trong quá trình kiểm thử so sánh, cần chú ý:
– Khi triển khai nhiều phiên bản phần mềm từ cùng một đặc tả, kiểm thử
hộp đen cho các sản phẩm này được thực hiện với cùng ca kiểm thử và cùng
các dữ liệu vào.
– Khi so sánh các kết quả thu được, nếu có khác biệt nghĩa là có sai trong
một sản phẩm nào đó.
Hình 1.3. Sơ đồ thông tin toàn bộ tiến trình kiểm thử
(Trang 75. sách Kiểm thử và đảm bảo chất lượng phần mềm. của Thạc
Bình Cường -NXB Bách khoa Hà Nội 2011)
