Các phương pháp ca kiểm thử và ứng dụng

1

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC SƯ PHẠM HÀ NỘI 2

TRẦN HÙNG CƯỜNG

CÁC PHƯƠNG PHÁP THIẾT KẾ CA KIỂM THỬ
VÀ ỨNG DỤNG
Chuyên ngành: KHOA HỌC MÁY TÍNH
Mã số: 60 48 01 01

Tóm tắt luận văn thạc sĩ máy tính

HÀ NỘI, 2015


2

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC SƯ PHẠM HÀ NỘI 2

TRẦN HÙNG CƯỜNG

CÁC PHƯƠNG PHÁP THIẾT KẾ CA KIỂM THỬ
VÀ ỨNG DỤNG
Chuyên ngành:

KHOA HỌC MÁY TÍNH
Mã số: 60 48 01 01

LUẬN VĂN THẠC SĨ MÁY TÍNH

Người hướng dẫn khoa học: TS. Lê Văn Phùng

Hà nội, năm 2015


1

LỜI CẢM ƠN
Đầu tiên tôi xin gửi lời cảm ơn chân thành đến thầy TS. Lê Văn Phùng Viện Công nghệ thông tin - Viện khoa học và công nghệ Việt Nam đã tận tình
hướng dẫn, chỉ bảo cho tôi trong suốt quá trình tôi làm luận văn.
Tôi cũng xin gửi lời cảm ơn đến các thầy cô trường Đại học sư phạm Hà
Nội 2, các thầy cô Viện Công nghệ thông tin - Viện khoa học và công nghệ
Việt Nam đã truyền đạt những kiến thức và giúp đỡ tôi trong suốt quá trình
học của mình.
Tôi cũng xin gửi lời cảm ơn tới các đồng nghiệp, gia đình và bạn bè những
người đã động viên tạo mọi điều kiện giúp đỡ tôi trong suốt hai năm học vừa
qua.


2

LỜI CAM ĐOAN
Tôi xin cam đoan toàn bộ nội dung trong luận văn này do tôi tự nghiên cứu,
đọc, dịch tài liệu, tổng hợp và thực hiện, đây là công trình nghiên cứu của tôi
dưới sự hướng dẫn khoa học của thầy TS. Lê Văn Phùng. Các số liệu, kết
quả trong luận văn là trung thực, rõ ràng. Trong luận văn tôi có sử dụng một
số tài liệu tham khảo như đã trình bày trong phần tài liệu tham khảo. Tôi xin
chịu trách nhiệm với những nội dung được viết trong luận văn này.

Hà nội, ngày 05 tháng 05 năm 2015
Người viết luận văn

Trần Hùng Cường


3

MỤC LỤC
LỜI CẢM ƠN.................................................................................................... 1
LỜI CAM ĐOAN .............................................................................................. 2
DANH MỤC CÁC HÌNH VẼ ........................................................................... 6
DANH MỤC CÁC BẢNG................................................................................. 7
MỞ ĐẦU............................................................................................................ 8
1. Lý do chọn đề tài ............................................................................................. 8
2. Mục đích nghiên cứu ....................................................................................... 8
3. Nhiệm vụ nghiên cứu ...................................................................................... 8
4. Đối tượng và phạm vi nghiên cứu.................................................................... 9
5. Giả thuyết khoa học......................................................................................... 9
6. Phương pháp nghiên cứu ................................................................................. 9
Chương 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM ............................ 10
1.1. Tổng quan về kỹ nghệ phần mềm ............................................................... 10
1.2. Khái niệm về kiểm thử phần mềm ............................................................ 112
1.3. Chiến lược kiểm thử ................................................................................... 17
1.3.1. Khái niệm chiến lược kiểm thử ............................................................ 17
1.3.2. Mô hình chiến lược tổng thể ................................................................ 21
1.3.3. Một số chiến lược kiểm thử khác ......................................................... 22
1.4. Các phương pháp kiểm thử ......................................................................... 27
1.5. Các kỹ thuật kiểm thử................................................................................. 31

1.5.1. Các kỹ thuật kiểm thử hộp trắng .......................................................... 31
1.5.2. Các kỹ thuật kiểm thử hộp đen............................................................. 32
1.5.3. So sánh kiểm thử chức năng (hộp đen) và kiểm thử cấu trúc (hộp trắng)
.............................................................................................................................. 33
Chương 2: CÁC PHƯƠNG PHÁP THIẾT KẾ CA KIỂM THỬ ................. 35
2.1. Phương pháp bao phủ câu lệnh (Statement Coverge) .................................. 37
2.1.1. Phương pháp bao phủ quyết định (Decision coverage)........................ 38
2.1.2. Phương pháp bao phủ điều kiện (Condition Coverage) ....................... 39
2.1.3. Phương pháp bao phủ quyết định/ điều kiện (Decision/ Condition
coverage) .................................................................................................... ..41
2.1.4. Phương pháp bao phủ đa điều kiện (Multiple Condition Coverage) .... 43
2.2. Phương pháp phân lớp tương đương (Equivalence Patitioning) .................. 48
2.3. Phương pháp phân tích giá trị biên (Boundary Value Analysis) .................. 50


4

2.4. Phương pháp đồ thị nguyên nhân – kết quả (Cause – Effect Graphing)....... 52
2.5 Phương pháp đoán lỗi (Error Guessing) ....................................................... 60
Chương 3: PHẦN MỀM THỬ NGHIỆM THIẾT KẾ CA KIỂM THỬ ...... 62
3.1. Phương pháp và kỹ thuật áp dụng thử nghiệm ............................................ 62
3.2. Một số giao diện chính của chương trình .................................................... 73
3.3. Form chính ................................................................................................. 73
3.3.1. Form chọn dường dẫn tới dữ liệu ............................................................ 73
3.3.2. Hiển thị dữ liệu ........................................................................................ 74
3.3.3. Tính toán độ phức tạp .............................................................................. 74
3.3.4. Xuất ra các phương án kiểm thử .............................................................. 74
3.4. Đánh giá kết quả thử nghiệm và hướng phát triển ...................................... 75
3.4.1. Đánh giá.................................................................................................. 75
3.4.2. Hướng phát triển .................................................................................... 75

KẾT LUẬN ..................................................................................................... 75
Kết quả thu được .............................................................................................. 76
Hướng nghiên cứu tiếp theo ............................................................................. 76
TÀI LIỆU THAM KHẢO............................................................................... 76
Tiếng Việt .......................................................................................................
777
Tiếng Anh ....................................................................................................... 77


5

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ử


6

DANH MỤC CÁC HÌNH VẼ
Hình 1.1. Sơ đồ luồng thông tin kiểm thử
Hình 1.2. Tiến trình kiểm thử
Hình 1.3. Sơ đồ các thành phần hỗ trợ phần mềm đạt chất lượng
Hình 1.4. Mô hình chiến lược kiểm thử tổng thể
Hình 1.5. Mô hình kiểm thử thời gian thực
Hình 1.6. Kiểm thử so sánh/ kiểm thử dựa vào nhau
Hình 1.7. Các vấn đề với kiểm thử vét cạn
Hình 1.8. Mô hình hộp đen
Hình 2.1. Chương trình kiểm thử
Hình 2.2. Mã máy cho chương trình trong Hình 2.1

Hình 2.3. Xác định các ca kiểm thử bằng đường cơ bản và điều kiện
Hình 2.4. Một mẫu cho việc liệt kê các lớp tương đương
Hình 2.5. Mô hình phân hoạch và phân tích giá trị biên
Hình 2.6. Các bước tiến hành theo kỹ thuật đồ thị nhân- quả
Hình 2.7. Xây dựng đồ thị nhân -quả bằng đồ thị
Hình 2.8. Các phương án lựa chọn ca kiểm thử
Hình 2.9. Các ký hiệu đồ thị nguyên nhân – kết quả cơ bản
Hình 2.10. Các ký hiệu ràng buộc
Hình 2.11. Những xem xét được sử dụng khi dò theo đồ thị
Hình 3.1. Các cấu trúc cơ bản của đồ thị dòng (sequence,if, while,
until, case)
Hình 3.2. Sơ đồ điều khiển của chương trình
Hình 3.3. Sơ đồ luồng điều khiển
Hình 3.4. Đồ thị dòng
Hình 3.5. Độ phức tạp chu trình xác định từ đồ thị dòng
Hình 3.6. Sơ đồ điều khiển của chương trình
Hình 3.7. Sơ đồ luồng điều khiển gộp
Hình 3.8. Đồ thị dòng
Hình 3.9. Đồ thị dòng dùng để xác định ma trận kiểm thử
Hình 4.0. Form chính của chương trình
Hình 4.1. Form chọn dường dẫn tới dữ liệu
Hình 4.2. Form hiển thị dữ liệu
Hình 4.3. Form tính toán độ phức tạp
Hình 4.4. Form các phương án kiểm thử

17
18
20
23
25

28
31
34
39
43
48
49
53
54
54
55
58
59
60
63
65
66
66
67
68
69
69
70
73
74
74
74
75

7

DANH MỤC CÁC BẢNG
Bảng 3.0. Bảng quyết định của đồ thị nhân -quả ..................................... 55
Bảng 3.1. Tập đường cơ bản ................................................................... 68
Bảng 3.2. Bảng tính độ phức tạp của đồ thị dòng V(G) .......................... 71
Bảng 3.3. Bảng ma trận kiểm thử A = (aij) .............................................. 71
Bảng 3.4. Tập đường kiểm thử ................................................................. 73


8

MỞ ĐẦU
1. Lý do chọn đề tài
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 vào áp dụng 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 của người dùng. Vì
vậy, kiểm thử là việc hết sức cần thiết, cần nghiên cứu về kiểm thử để tìm ra
phương pháp kiểm thử hiệu quả phù hợp với ứng dụng sản phẩm.
Vì vậy tôi chọn đề tài cho luận văn thạc sĩ của mình là: “Các phương pháp
ca kiểm thử và ứng dụng”.
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 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ế.
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.


9

- Ứ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ử và
ứng dụng sản phẩm.
5. Đóng góp mới của luận văn
- 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à ứng dụng.
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

10

Chương 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
1.1.Tổng quan về kỹ nghệ phần mềm
Kỹ nghệ phần mềm (Software Engineering) là việc thiết lập và sử dụng các
nguyên lý công nghệ đúng đắn để thu được phần mềm một cách kinh tế vừa
tin cậy vừa làm việc hiệu quả trên các máy thực [Naur P.1969].
Nhiều định nghĩa khác về sau đều nhấn mạnh vào các yêu cầu về một kỹ
thuật công nghệ trong việc phát triển. Parnas (1987) định nghĩa kỹ nghệ phần
mềm là việc xây dựng phần mềm nhiều phiên bản bởi nhiều người. Ghezzi
(1991) định nghĩa kỹ nghệ phần mềm là một lĩnh vực của khoa học máy tính,
liên quan đến xây dựng các hệ thống phần mềm vừa lớn vừa phức tạp bởi một
hay một số nhóm kỹ sư. Sommerville (2001) định nghĩa kỹ nghệ phần mềm là
lĩnh vực liên quan đến lý thuyết, phương pháp và công cụ dùng cho phát triển
phần mềm. Pressman (2001) định nghĩa kỹ nghệ phần mềm là bộ môn tích
hợp cả qui trình, các phương pháp, các công cụ để phát triển phần mềm máy
tính.
Với sự phát triển mạnh mẽ của công nghệ thông tin (CNTT), ngày nay,
người ta đã đi đến thống nhất về việc hình thành một bộ môn mới là kỹ nghệ
phần mềm (software engineering) với những đặc trưng của một nghề chuyên
nghiệp. Kỹ nghệ phần mềm được hiểu là các tiến trình có kỷ luật và định
lượng để phát triển, vận hành và bảo trì các hệ thống sử dụng nhiều tới phần
mềm. Kỹ nghệ phần mềm tập trung vào công nghệ phần mềm, các tiến trình,
cách đo, hiệu suất, tính đúng hạn và chất lượng của phần mềm. Kỹ nghệ phần
mềm gồm tri thức nền tảng, tức là công nghệ phần mềm, và phần tri thức thực
hành, tức là tri thức nhằm vào các khía cạnh quản lý, đảm bảo chất lượng...
Chú ý rằng, khái niệm kỹ nghệ phần mềm bao trùm khái niệm công nghệ
phần mềm. Công nghệ phần mềm (Software technology) chỉ là tập hợp các
công nghệ (bao gồm nhiều kỹ thuật) để tạo ra phần mềm, mỗi công nghệ có

11

thể có nhiều kỹ thuật tạo chương trình khác nhau. Chẳng hạn như Công nghệ
hướng sự vật: một giải pháp để thiết kế và lập trình phần mềm hiệu quả nhờ
sử dụng các sự vật được xây dựng từ trước. Công nghệ Java: một giải pháp
tạo ra phần mềm có thể hoạt động trên các môi trường khác nhau trên mạng
máy tính. Nói rõ hơn, công nghệ phần mềm là tập hợp các phương pháp, quy
trình, kỹ năng, bí quyết, công cụ, phương tiện để làm ra sản phẩm là phần
mềm. Công nghệ phần mềm là một chuyên ngành khoa học nghiên cứu tìm ra
cách tốt nhất để làm ra các phần mềm đáp ứng các bài toán xử lý tin lớn và
phức tạp sao cho chương trình nhận được phải đúng, đáng tin và hiệu quả lại
dễ sử dụng.
Ngày nay, chúng ta quan tâm đến cách tiếp cận tới việc phát triển phần
mềm nhấn mạnh vào kỹ thuật và phương pháp đã được xác định rõ - một cách
tiếp cận quen gọi là kỹ nghệ phần mềm.
Người ta có thể chia việc phát triển phần mềm thành nhiều giai đoạn. Khi
đó vòng đời phần mềm được biểu diễn theo một số giai đoạn như sau:
1. Giai đoạn lập kế hoạch dự án
2. Giai đoạn phân tích và xác định yêu cầu
3. Giai đoạn thiết kế hệ thống và thiết kế phần mềm
4. Giai đoạn xây dựng phần mềm; kiểm thử phần mềm và kiểm thử hệ
thống
5. Giai đoạn cài đặt và chuyển đổi hệ thống
6. Giai đoạn vận hành và bảo trì.
Trong đó, giai đoạn 4 mang sắc thái công nghệ rõ nét và kiểm thử phần
mềm đã giữ một vai trò cực kỳ quan trọng trong quá trình hoạt động bảo đảm
chất lượng phần mềm.
1.2. Khái niệm về kiểm thử phần mềm

12

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 của người dùng.
Chính vì lẽ đó, kiểm thử là việc hết sức cần thiết, cần nghiên cứu về kiểm thử
để tìm ra phương pháp kiểm thử hiệu quả phù hợp với ứng dụng sản phẩ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 (software quality assurance - SQA), là khâu
điển hình kiểm soát đặc tả, thiết kế, lập mã.
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 được đặt ra với những lý do sau:
- Muốn nhận diện phần mềm như một phần tử của hệ thống hoạt động (xem
xét sản phẩm).
- 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:

13

+ 40% tổng 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ó thể ảnh hưởng đến 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.
Như vậy, kiểm thử tốt sẽ:
+ Giảm chi phí phát triển;
+ Tăng độ tin cậy của sản phẩm phầm mềm
Vấn đề cần đặt ra là cần vận hành phần mềm như thế nào để:
+ Hiệu suất tìm ra lỗi cao nhất?
+ Chi phí ( thời gian, công sức ) ít nhất?
Công việc trước mắt của kiểm thử phần mềm là tạo ra các ca kiểm thử
(mạch thực hiện trong chương trình) để 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ó 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ử:
1. 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.
2. 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.
3. Việc kiểm thử thành công là việc kiểm thử làm lộ ra một số lỗi 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 ta
đ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 phép
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.

14

Nếu kiểm thử được tiến hành thành công (theo mục tiêu được phát biểu
trên), 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ử được tiến hành đưa ra
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 (Điều quan trọng là cần nhớ điều này trong
tâm người thực hiện kiểm thử).
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.
- Ca kiểm thử thắng lợi là ca kiểm thử làm lộ ra ít nhất 1 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 không? 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 với 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ó khiếm khuyết.
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


15

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?
Luồng thông tin kiểm thử tuân theo hình mẫu được mô tả ở sơ đồ luồng
thông tin kiểm thử xem hình 1.1 trên ta thấy hai lớp vào được cung cấp cho
tiến trình kiểm thử:
1. Cấu hình phần mềm có bao hàm bản đặc tả yêu cầu phần mềm bản đặc
tả thiết kế, và chương trình gốc.
2. Cấu hình kiểm thử, bao gồm kế hoạch và thủ tục kiểm thử, bất kỳ công
cụ kiểm thử nào được dự định dùng, và các trường hợp kiểm thử cùng kết quả
dự kiến. Trong thực tế, cấu hình kiểm thử là tập con của cấu hình phần mềm.
Kiểm thử được tiến hành và tất cả các kết quả đều được đánh giá . Tức là
kết quả kiểm thử được so sánh với kết quả dự kiến. Khi lỗi được phát hiện thì
việc gỡ lỗi bắt đầu. Tiến trình gỡ lỗi là phần không thể dự kiến được. Mỗi lỗi
chỉ ra sự sai lệch biên độ 0,01% giữa các kết quả trông đợi và thực tại có thể
mất 1 giờ, 1 ngày hay 1 tháng để chuẩn đoán và sửa chữa. Đó là phần cố hữu
không chắc chắn trong việc gỡ lỗi làm cho việc kiểm thử thành khó khăn khi
lập lịch độ tin cậy.
Sau khi các kết quả kiểm thử được thu thập và đánh giá thì cần một chỉ dẫn

định lượng về chất lượng và độ tin cậy phần mềm. Nếu hay gặp phải những
lỗi nghiêm trọng thì yêu cầu sửa đổi thiết kế. Chất lượng và độ tin cậy phần


16

mềm là thấp thì phải kiểm thử thêm. Mặt khác nếu các chức năng phần mềm
dường như làm việc đúng và lỗi gặp phải là dễ sửa thì có thể rút ra một trong
hai kết luận:
Chất lượng và độ tin cậy phần mềm là chấp nhận được.
Kiểm thử là không tương xứng để làm lộ ra những lỗi nghiêm trọng.
Cuối cùng, nếu việc kiểm thử không là lộ ra lỗi nào thì hoặc cấu hình kiểm
thử chưa được cân nhắc đúng, hoặc lỗi vẫn còn ẩn nấp bên trong phần mềm.
Những khiếm khuyết này cuối cùng sẽ bị phát hiện bởi người dùng và được
phát triển sửa chữa trong giai đoạn bảo trì (Chi phí cho việc định lỗi lúc này
có thể lớn gấp từ 60 đến 100 lần chi phí định lỗi trong giai đoạn phát triển).
Những kết quả được tích lũy trong khi kiểm thử cũng có thể được đánh giá
theo một cách hình thức hơn. Các mô hình độ tin cậy phần mềm dùng dữ liệu
tỷ lệ lỗi để dự đoán sự xuất hiện tương lai của lỗi và do đó có thể dự đoán độ
tin cậy.
Mỗi hình tròn trong Sơ đồ luồng thông tin kiểm thử biểu thị cho một phép
biến đổi cực kỳ phức tạp. Chúng ta sẽ xem xét các khái niệm và tiến trình
phục vụ cho luồng thông tin kiểm thử và các phép biến đổi kiểm thử.
Cấu hình phầm mềm (Input)

Các kết quả Kiểm thử

Đánh giá

Lỗi

Gỡ lỗi

Kiểm thử

Dữ liệu tỷ lệ lỗi

Sửa chữa

Các kết quả dự kiến
Cấu hình kiểm thử (Input)

Mô hình
tin cậy

Độ tin cậy tiên đoán (dự kiến)

Hình 1.1. Sơ đồ luồng thông tin kiểm thử


17

Kiểm thử thường được thực hiện theo tiến trình sau:
Lập kế hoạch kiểm thử

Thiết kế ca kiểm thử

Chuẩn bị dữ liệu, điều kiện kiểm thử

Tiến hành kiểm thử

So sánh đánh giá kết quả kiểm thử

Hình 1.2. Tiến trình kiểm thử
Ở đây, Ca kiểm thử (test case) là một tình huống kiểm thử tương ứng với
một mạch hoạt động của chương trình. Nó bao gồm một tập các giá trị đầu
vào và một danh sách các kết quả đầu ra mong muốn và thực tế. Việc thiết kế
ca kiểm thử là rất quan trọng trong các hoạt động bảo đảm chất lượng phần
mềm và đó cũng là phần trọng tâm được nghiên cứu sâu trong luận văn này.
1.3.Chiến lược kiểm thử
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 lộ trình để:


18

- 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 thông tin kết quả.
-

Đủ mềm dẻo để cổ vũ óc sáng tạo, đáp ứng được yêu 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 gọi là một tiêu bản (template). Một tiêu bản để kiểm thử có những
đặc trưng mang tính “khuôn mẫu”:
-

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ử:
1. Kiểm thử mức thấp: thẩm định từng khúc mã nguồn xem có tương ứng
và thực thi đúng đắn không?


19

2. 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 không ?
Mỗi chiến lược đáp ứng được yêu cầu người 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ử.

Chúng ta nhớ rằng kiểm thử phần mềm là một phần của hoạt động “thẩm
định và xác minh”, trong đó, thẩm định là một tập các hoạt động để bảo đảm
rằng sản phẩm hoạt động đúng, còn xác minh là một tập hợp các hoạt động để
bảo đảm rằng phần mềm đã đáp ứng đúng yêu cầu của khách hàng, tức là
đúng sản phẩm mà khách hàng mong đợi.
Việc kiểm thử cung cấp một thành luỹ cuối cùng để có thể thẩm định về
chất lượng và có thể phát hiện ra lỗi.
Xét duyệt kỹ thuật
Các phương pháp

chính thức

Đo đạc

kỹ nghệ phần mềm

Chất lượng

Các chuẩn và các
thủ tục

Quản lý cấu hình

Kiểm thử

phần mềm và SQA

Hình 1.3. Sơ đồ các thành phần hỗ trợ phần mềm đạt chất lượng
Trên sơ đồ:


20

- Việc xét duyệt kỹ thuật chính thức: bảo đảm chất lượng của sản phẩm
được tạo ra;
- Các phương pháp kỹ nghệ phần mềm: cung cấp nền tảng xây dựng nên
chất lượng;
- Các chuẩn và thủ tục: giúp bảo đảm tính thống nhất;
- Quản lý cấu hình phần mềm: bảo đảm chất lượng toàn thể;
- Kiểm thử: thẩm định về chất lượng, phát hiện ra lỗi;
- Đo đạc: cùng với kiểm thử áp dụng cho mọi phần tử của cấu hình phần
mềm.
Điều quan trọng cần lưu ý rằng việc thẩm định và xác minh bao gồm một
phạm vi rộng các hoạt động bảo đảm chất lượng phần mềm (SQA) có chứa cả
họp xét duyệt chính thức, kiểm toán chất lượng và cấu hình, điều phối hiệu
năng, mô phỏng, nghiên cứu khả thi, xét duyệt tài liệu, xét duyệt CSDL, phân
tích thuật toán, kiểm thử phát triển, kiểm thử chất lượng và kiểm thử cài đặt.
Người phát triển phần mềm bao giờ cũng có trách nhiệm kiểm thử độc lập
từng đơn vị (mô-đun) chương trình, để bảo đảm rằng mỗi mô-đun thực hiện
đúng chức năng mà nó đã được thiết kế. Trong nhiều trường hợp, người phát
triển cũng tiến hành cả kiểm thử tích hợp, từng bước kiểm thử dẫn tới việc
xây dựng (và kiểm thử) toàn bộ cấu trúc chương trình. Chỉ sau khi kiến trúc
phần mềm hoàn tất thì nhóm kiểm thử độc lập mới tham gia vào.
Vai trò của nhóm kiểm thử độc lập là để loại bỏ vấn đề cố hữu liên quan tới
việc để người xây dựng phải kiểm thử những cái đã xây dựng ra. Việc kiểm
thử độc lập sẽ loại bỏ xung khắc lợi ích. Tất nhiên, người phát triển phần
mềm không để nhóm kiểm thử thực hiện công việc một mình. Trong khi tiến

hành kiểm thử, người phát triển phải sẵn sàng sửa lỗi khi được phát hiện.
Câu hỏi thường đặt ra là: Ai làm? Làm cái gì? Khi nào? Và mối quan hệ
giữa họ?


21

Trước hết, chúng ta khẳng định các kỹ sư phần mềm làm ra phần mềm. Họ
cần tiến hành các kiểm thử ban đầu. Về nguyên tắc, người làm sản phẩm,
kiểm tra sản phẩm là không hợp lý.
Có một số quan niệ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 tàn nhẫn.

-

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 kiểm thử:
-

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 đúng theo thiết kế (yêu cầu xác minh), 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 (bảo đảm việc kiểm
thử được tiến hành triệt để).
-

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.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 rằng
nó vận 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 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.


22

Việc kiểm thử tích hợp có liên quan tới 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ầu 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 tích hợp (được
xây dựng), một tậ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 đủ tất
cả 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ử 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.
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ó 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.
Mô hình chiến lược kiểm thử tổng thể được thế giới đề xuất theo hình chữ
V như sau:

Hình 1.4. Mô hình chiến lược kiểm thử tổng thể
1.3.3 Một số chiến lược kiểm thử khác


23

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.3.3.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 và 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ử phần
mềm phải xem xét tác dộ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ử (hành vi).
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.