Giáo trình kiểm định phần mềm

Nguyễn Xuân Huy

Giáo trình
KIỂM ĐỊNH PHẦN MỀM


Mục lục

Lời nói đầu 4
Chương 1 Nhập đề 7
1.1 Sản phẩm phần mềm 7
1.2 Các thành phần của một sản phẩm phần mềm 8
1.3 Các tiêu chí chất lượng của sản phẩm phần mềm 9
1.4 Một số khái niệm khác 13
1.5 Mô hình phát triển phần mềm 14
1.6 Qui trình phát triển phần mềm 15
Chương 2 Lỗi của sản phẩm phần mềm 18
2.1 Thế nào là lỗi phần mềm? 18
2.2 Tại sao lỗi phần mềm xuất hiện? 19
2.3 Chi phí sửa lỗi 22
Chương 3 Kiểm định phần mềm 24
3.1 Khái niệm chung 24
3.2 Hai vấn đề trọng tâm: K&K 27
3.3 Qui trình kiểm định phần mềm 30
3.4 Tính không đầy đủ của kiểm định 36
3.5 Thanh sát (inspection) và kiểm điểm (review) 40
3.6 Test tự động 42
Chương 4 Kiểm định phát triển 47
4.1 Kiểm định đơn vị 48
4.1.1 Định nghĩa 48
2

4.1.2 Các yêu cầu đối với kiểm định đơn vị 49
4.1.3 Sinh các trường hợp test cho kiểm định đơn vị 51
4.2 Kiểm định cấu phần 54
4.3 Kiểm định hệ thống 60
Chương 5 Phát triển theo kiểm định săn đuổi 65
5.1 Qui trình 65
5.2 Lợi ích 66
5.3 Kết luận 68
Chương 6 Kiểm định thực tế 70
6.1 Khái niệm chung 70
6.2 Kiểm định dựa trên yêu cầu 71
6.3 Thiết kế test theo kịch bản 72
6.4 Kiểm định hiệu năng 73
Chương 7 Kiểm định của khách hàng 76
7.1 Khái niệm chung 76
7.2 Kiểm định alpha 80
7.3 Kiểm định beta 80
7.4 Kiểm định chấp thuận 81
Thảo luận 85
TÀI LIỆU THAM KHẢO 179
Phụ lục 1 Ghi nhớ 181
Phụ lục 2 Tổng quan về kĩ nghệ phần mềm 183
Phụ lục 3 Thuật ngữ 209

3


Lời nói đầu

Giáo trình này giới thiệu một số kiến thức cơ bản về kiểm định phần
mềm, một nhánh quan trọng thuộc lĩnh vực công nghệ phần mềm.
Kể từ những năm sáu mươi của thế kỉ 20, công nghệ phần mềm đã được
hình thành như một nguyên lí khoa học và phát triển ngày càng mạnh mẽ. Có
thể hiểu công nghệ phần mềm là lĩnh vực của công nghệ thông tin nhằm
nghiên cứu và đề xuất các nguyên lí, qui trình công nghệ, phương pháp, và
công cụ trợ giúp các quá trình thiết kế, cài đặt và bảo trì sản phẩm phần mềm
đáp ứng được các chỉ tiêu về chất lượng: tính đúng, tính khoa học, tính tin
cậy, tính vững vàng, tính dễ chuyển mang, tính dễ sử dụng, dễ phát triển và
hoàn thiện.
Kiểm định phần mềm chính là một nhánh của công nghệ phần mềm có
nhiệm vụ kiểm tra và xác minh các tiêu chí chất lượng nói trên.
Theo nghĩa hẹp, kiểm định phần mềm tập trung chủ yếu vào việc kiểm
tra tính đúng của phần mềm. Tính đúng của một phần mềm được hiểu là
phần mềm đó thực thi đúng đắn và chính xác các yêu cầu do người thiết kế
mô tả trong bản thiết kế. Các yêu cầu này được hình thành trên cơ sở trao đổi
và thống nhất giữa nhóm phát triển phần mềm với khách hàng.
Khoảng những năm sáu mươi của thế kỉ 20 đã bùng nổ một cuộc tranh
luận về toán tử đầy nghi vấn – toán tử GOTO trong ngôn ngữ lập trình.
Chính cuộc tranh luận này đã làm nảy sinh các ý tưởng và nguyên lí đầu tiên
về công nghệ phần mềm. Điều thú vị là, ngay từ những ngày đầu sơ khởi và
chập chững của công nghệ phần mềm, các phương pháp hình thức đã ra đời
và phát triển nhanh chóng. Hàng loạt công trình nghiên cứu có ý nghĩa của
các nhà tin học đầu đàn như Dijkstra, Dahl, Hoare, Boehm đã nâng kĩ thuật
lập trình lên một tầm cao, mang tính chặt chẽ và hoàn thiện, rất gần với các
ngành khoa học chính xác. (Dijkstra, Dahl, and Hoare, 1972). Dahl và


Lời nói đầu

___________________
Dijkstra đã đề xuất nguyên lý lập trình theo đặc tả hình thức, Hoare xây dựng
hệ tiên đề chứng minh tính đúng của chương trình thông qua các phương
pháp toán học và suy luận logic, Boehm và Dijkstra chứng minh tính đủ của
hai cấu trúc điều khiển tuần tự và lặp while, trên cơ sở đó đề xuất khái niệm
D-cấu trúc với lời khuyên lập trình viên chỉ nên sử dụng ba cấu trúc điều
khiển một cách trong sáng và tao nhã là cấu trúc tuần tự, cấu trúc rẽ nhánh và
cấu trúc lặp điều kiện trước (Boehm, 1979).
Do nhu cầu thị trường, các hệ thống phần mềm phức tạp ngày càng tăng
trưởng. Cùng với nó, hoạt động kiểm định ngày càng gánh trách nhiệm thêm
nặng nề và chuyên nghiệp. Nếu như trước đây, lập trình viên thường đảm
đương luôn nhiệm vụ kiểm định các đoạn mã do chính mình viết ra thì ngày
nay, việc đó là không thể, chưa nói đến khả năng không được khuyến khích.
Các phương pháp kiểm định được hình thành và phát triển rất đa dạng. Có
thể nói, ngày nay, mỗi mô hình phát triển phần mềm quyết định một vài qui
trình sản xuất phần mềm. Đến lượt mình, mỗi qui trình sản xuất phần mềm
lại quyết định một vài qui trình kiểm định hiệu quả tương ứng.
Giáo trình đặt ra hai mục tiêu cơ bản sau đây:
1. Giới thiệu khái quát các qui trình và phương pháp kiểm định phần
mềm, đi sâu vào các phương pháp tiên tiến và có hiệu quả theo nghĩa các
phương pháp này đã được kiểm chứng trong thực tế;
2. Định hướng cho học viên một số kĩ năng trợ giúp tổ chức và chỉ đạo
các nhóm kiểm định phần mềm tại các cơ sở làm phần mềm.
Nội dung của giáo trình tương đương với một học phần khoảng 60 tiết.
Giáo trình được kiến trúc như sau:
Chương đầu tiên giới thiệu một số khái niệm cơ sở về công nghệ phần
mềm với giả định là bạn đọc đã biết ít nhiều về sản phẩm phần mềm và các
tiêu chí đánh giá một sản phẩm phần mềm, về mô hình và các qui trình phát
triển phần mềm.
Nội dung của chương 2 dành cho các thảo luận về lỗi phần mềm, trong

đó phân tích chủ yếu về các dạng lỗi tiềm ẩn trong phần mềm và các nguyên
nhân sinh lỗi.
Chương 3 trình bày qui trình tổ chức và thực thi hoạt động kiểm định
phần mềm.

5


Lời nói đầu
___________________
Các chương tiếp theo của giáo trình, từ chương 4 đến chương 7 lần lượt
giới thiệu các nhóm phương pháp kiểm định phần mềm: kiểm định phát triển,
kiểm định thực tế và kiểm định của người sử dụng.
Trước khi biên soạn giáo trình này, người viết đã tiếp thu được nhiều
kiến thức bổ ích cả về nội dung công nghệ phần mềm và phương pháp luận
truyền thụ từ giáo sư John Vũ, kĩ sư trưởng Công nghệ thông tin hãng
Boeing, giáo sư kiêm nhiệm tại Viện nghiên cứu phần mềm của Đại học
Carnegie Mellon (CMU) và giáo sư Anthony Lattanze, CMU. Tiến sĩ John
Kang, chủ nhiệm Khoa Quốc tế CMU và thày Lê Công Cơ, Q. hiệu trưởng
trường Đại học Duy Tân Đà Nẵng đã cấp kinh phí và tạo nhiều điều kiện
thuận lợi cho người viết được thăm và tham gia các khoá đào tạo công nghệ
phần mềm tại CMU. PGS TS Đoàn Văn Ban, PGS TS Đặng Văn Đức,
Nghiên cứu viên chính Ngô Trung Việt, Viện Công nghệ thông tin, Viện
Khoa học và Công nghệ Việt Nam, TS Hồ Cẩm Hà, trưởng khoa Công nghệ
thông tin Đại học Sư phạm Hà Nội thường xuyên trao đổi và cung cấp thông
tin cho người viết về các vấn đề đương đại của công nghệ phần mềm.
Trong thời gian biên soạn giáo trình này, thạc sĩ Lê Thị Mỹ Hạnh, Khoa
Công nghệ thông tin trường Đại học Bách khoa, Đại học Đà Nẵng đã cung
cấp một số hình vẽ và những trợ giúp trong soạn thảo và trình bày văn bản.
Người viết chân thành cảm ơn những hỗ trợ quí báu và chân tình của

các thày và đồng nghiệp.
Người viết rất mong nhận được các ý kiến bình luận và đánh giá của
bạn đọc gửi về theo địa chỉ sau đây:
Nguyễn Xuân Huy,
Chủ tịch Hội đồng tư vấn Giáo dục Microsoft,
MB: 0903203800, E-mail:
Hà Nội, ngày Giỗ Tổ,
10 tháng Ba năm Nhâm Thìn
N X Huy

6


Chương 1
Nhập đề

Chương này nhắc lại một số khái niệm cơ bản để chuẩn bị cho việc tiếp
thu các khái niệm về kiểm định phần mềm là khái niệm trọng tâm của giáo
trình:
Nội dung
1.1 Sản phẩm phần mềm.
1.2 Các thành phần của một sản phẩm phần mềm.
1.3 Các tiêu chí chất lượng của sản phẩm phần mềm.
1.4 Một số khái niệm khác.
1.5 Mô hình phát triển phần mềm.
1.6 Qui trình phát triển phần mềm.

1.1 Sản phẩm phần mềm
Phần mềm là một (bộ) chương trình được cài đặt trên máy tính thực hiện
một nhiệm vụ tương đối độc lập nhằm phục vụ cho một hoặc nhiều ứng dụng

cụ thể: quản lý họat động của máy tính hoặc áp dụng máy tính trong các họat
động kinh tế, quốc phòng, văn hóa, giáo dục, giải trí,…
Thí dụ
S1. Hệ điều hành Ubutu;
S2. Môi trường lập trình C++ Devcpp;
S3. Hệ thông tin quản lí: CN2;


Chương 1 Nhập đề
_________________________________________

S4. Game: Lines;
…

1.2 Các thành phần của một sản phẩm phần mềm
Theo quan điểm hệ thống, một sản phẩm phần mềm được xem là một hệ
thống bao gồm một hoặc nhiều phân hệ. Mỗi phân hệ lại được xây dựng từ
những cấu phần. Mỗi cấu phần bao gồm các đơn vị nhỏ hơn. Các thành phần
của phần mềm được liên kết với nhau thông qua các mối quan hệ và các
tương tác.
Thí dụ
Một hệ thống thông tin có thể bao gồm các phân hệ sau đây:
Phân hệ quản lí nhân sự, phân hệ quản lí sản phẩm, phân hệ quản lí tài
chính (kế toán – tài vụ), phân hệ quản lí hành chính, phân hệ tiếp thị,…
Các phân hệ trên có thể được xây dựng từ các cấu phần sau:
Cấu phần quản lí dữ liệu, cấu phần quản lí lưu trữ, cấu phần quản lí
mạng,…
Mỗi cấu phần lại được tổ hợp từ các đơn vị, các lớp (class - theo tiếp
cận hướng đối tượng), các thư viện chương trình, hoặc các đơn thể (module),
chẳng hạn:

Lớp các cửa sổ màn hình, lớp các thực đơn, thư viện các hàm số học, …
Trong tài liệu này các thuật ngữ sau đây được hiểu là tương đương về
ngữ nghĩa:
Hệ thống,
Phần mềm,
Hệ thống phần mềm,
Sản phẩm phần mềm;
Chương trình (bộ chương trình).
Các thuật ngữ như cấu phần, đơn thể, đơn vị, chi tiết trong một hệ thống
(phần mềm) được hiểu theo nghĩa tương đối, không có một phân định rõ ràng

8


Chương 1 Nhập đề
_________________________________________
nào. Khi cần thiết, trong những trường hợp cụ thể, ngữ nghĩa của các khái
niệm trên sẽ được làm rõ trong văn cảnh.

Đặc tả
sản phẩm

Duyệt lại
sản phẩm

Phản hồi từ
phiên bản
cũ

Tài liệu

thiết kế

Thông tin
cạnh tranh

Kiến trúc
phần mềm

Tài liệu
kiểm định

Khảo sát
khách hàng

Lịch biểu

Dữ liệu

Mã nguồn

Sản phẩm
cuối

Bộ cài, Module trợ giúp, Hướng
dẫn khử lỗi, Bẫy lỗi, Thực đơn,
Biểu tượng, Âm thanh, Hướng dẫn
sử dụng, Nâng cấp, Cập nhật, Trợ
giúp sản phẩm…
phẩm…ProductSupport
Information, …

Hình 1.1 Sản phẩm phần mềm

Với một số phần mềm đơn giản, thí dụ như một bài tập về lập trình, thì
kiểm định không đặt ra nhiều vấn đề gay cấn. Vì lí do đó, các nguyên lí, mô
hình và kĩ thuật kiểm định sẽ định hướng chủ yếu đến các hệ thống phần
mềm bao gồm nhiều cấu phần có quan hệ hữu cơ với nhau.

1.3 Các tiêu chí chất lượng của
sản phẩm phần mềm
Dưới đây liệt kê và phân tích vắn tắt một số tiêu chí xác định chất lượng của
một sản phẩm phần mềm (Huy, 1996):
9


Chương 1 Nhập đề
_________________________________________
TC1 Tính đúng
Tính đúng của một sản phẩm phần mềm được hiểu là sản phẩm phần
mềm đó thực thi đầy đủ và chính xác những yêu cầu đặc tả trong bản thiết kế.
Thí dụ
Trong bản thiết kế đặc tả rằng phần mềm S có thể sắp xếp một mảng có
tối đa 10000 phần tử thì những tình huống sau đây được coi là sai:
- Phần mềm S không sắp được các mảng rỗng là mảng không chứa
phần tử nào;
- Phần mềm S không sắp được những mảng có đúng 10000 phần tử;
- Phần mềm S chỉ sắp tăng, không sắp giảm;
- Phần mềm S gây lỗi khi ta yêu cầu sắp (lại) một mảng đã sắp;
- Phần mềm S không thực thi được với các mảng có các phần tử giống
nhau.

TC2 Tính khoa học
Giao diện được thiết kế hợp lý, gần với tư duy và kì vọng tự nhiên của
người sử dụng; các chức năng được sắp đặt khoa học, thể hiện logic của hệ
thống; có thể di chuyển vị trí, thay đổi kích thước, màu sắc của các giao diện,
kiểu của văn bản, hình vẽ, đồ thị, bảng biếu…
Thí dụ
1. Phần mềm dạy học P dùng cho học sinh tiểu học chỉ có thể hiển thị
các dòng thông báo, thực đơn và trợ giúp với cỡ chữ 9 được xem là vi phạm
vệ sinh học đường. Phần mềm này đặt màu sắc ngẫu hứng nên gây phản cảm
đối với người sử dụng: họ và tên học sinh thì ghi màu đỏ, điểm – màu vàng,
nhận xét của giáo viên – màu tím.
2. Phần mềm S cung cấp hai lệnh có chức năng tương tự nhau nhưng cú
pháp khác nhau, chẳng hạn:
asc(a, n) – sắp tăng mảng a gồm n phần tử;
dec(n, a) – sắp giảm mảng a gồm n phần tử.

10


Chương 1 Nhập đề
_________________________________________
Hai lệnh trên có thứ tự (vị trí) đặt tham trị khác nhau nên sẽ gây khó
khăn cho người sử dụng.
TC3 Tính dễ sử dụng
Sau một vài lần thực thi phần mềm, người sử dụng có thể nhớ được một
cách logic trình tự làm việc. Phần mềm có tính năng trợ giúp người sử dụng
đúng lúc và đúng chỗ. Các thao tác nhanh chóng, rõ ràng, dễ theo dõi. Làm
việc lâu với phần mềm không gây cảm giác khó chịu.
TC4 Tính tương tác
Phần mềm có thể tương tác với các hệ thống khác, thí dụ:

- Có thể đọc các file định dạng khác nhau;
- Có thể chuyển, nhận và dĩ nhiên là hiểu được các thông điệp, dữ
liệu trao đổi qua lại với các hệ thống khác hiện đang tồn tại trên
thị trường.
TC5 Tính dễ chuyển mang (tính độc lập)
Phần mềm có thể làm việc bình thường trong các môi trường khác nhau,
với các hệ điều hành và chủng loại máy khác nhau. Tính dễ chuyển mang
hiểu theo nghĩa đen là có thể cài phần mềm trên các chủng loại máy tính và
môi trường khác nhau.
TC6 Tính vững vàng
Khi xảy ra các sự cố khách quan hoặc chủ quan phần mềm vẫn đủ “tỉnh
táo” để nhận biết và xử lí, không bị treo, bị liệt hoặc gây ra các hậu quả
nghiêm trọng.
Các sự cố có thể là:
Người sử dụng chưa có đủ kĩ năng điều khiển phần mềm nên nạp sai dữ
liệu, thay vì cần nạp một dãy số họ nạp dãy kí tự khác số, bấm nhầm lệnh.
Thí dụ, nạp sai tên file, xóa nhầm các file của hệ điều hành, không hiểu rõ
các cảnh báo khi format bộ nhớ ngoại vi hoặc khởi động (setup) lại hệ thống.
TC7 Tính dễ phát triển và hoàn thiện
Khi công nghệ phát triển, nhiều phần mềm phải thiết kế lại từ đầu, kể cả
việc phải chọn môi trường và công cụ phát triển mới. Nhiều phần mềm
không thể tái sử dụng bất kì chi tiết nào. Một phần mềm được xem là dễ phát
11


Chương 1 Nhập đề
_________________________________________
triển và hoàn thiện nếu nó thích ứng được với những thay đổi trong yêu cầu
của khách hàng cũng như nền tảng kĩ thuật.
Thí dụ

1. Theo những qui định mới chẳng hạn, người ta có thể thay đổi các
phương thức tính thuế suất, tính điểm trung bình trong nhà trường, thay đổi
các trình tự, thủ tục và hồ sơ cấp phép… Trong những tình huống đó ta
không phải xây dựng lại hệ thống mà chỉ cần khai báo lại các tùy biến.
Chẳng hạn, trước kia người ta qui định tính điểm trung bình của ba môn
thi theo hệ số toán: 4, văn: 4, ngoại ngữ: 2. Công thức tính khi đó sẽ là:
[(Điểm thi toán  4) + (Điểm thi văn  4) + (Điểm thi ngoại ngữ  2)] / 10
Nay người ta qui định lại như sau: toán: 4, văn: 3, ngoại ngữ: 3. Công
thức tính mới sẽ là:
[(Điểm thi toán  4) + (Điểm thi văn  3) + (Điểm thi ngoại ngữ  3)] / 10
Nếu sửa một số mã lệnh trong chương trình thì chắc chắn sẽ gây nhiều
phiền toái trong việc phổ biến và cập nhật cho hàng loạt khách hàng tại nhiều
điểm ứng dụng khác nhau. Các phần mềm tinh tế thường cho phép người sử
dụng đặt lại các tùy biến khi cần thiết.
2. Khi chuyển từ môi trường lập trình đơn lẻ trên một máy tính sang
nguyên lý mới như lập trình mạng hoặc điện toán đám mây, có thể xảy ra rất
nhiều thay đổi, trong số đó có những thay đổi căn bản về quan niệm hệ
thống, về cấu trúc dữ liệu và về thuật toán… Có thể phải thêm hoặc mở rộng
một số trường trong cấu trúc file, chẳng hạn, trước kia ta dành ra 1 byte để
ghi nhận định dạng file, nay các chủng loại phương tiện (media) phát triển
quá nhiều thì 1 byte dành cho việc ghi nhãn phương tiện sẽ là không đủ,
chẳng hạn, người ta thay bằng 2 byte. Khi đó toàn bộ các thủ tục liên quan
đến xử lí file của hệ thống sẽ phải thay đổi.
3. Cũng là một lệnh mở file. Khi phần mềm chạy trên máy đơn thì việc
kiểm tra file có tồn tại hay không, có thể đọc được hay không là đơn giản.
Nay, trên môi trường mạng, số sự cố sẽ thay đổi về lượng và chất. Ngoài các
sự cố “truyền thống” như file không tồn tại, file thuộc loại chỉ đọc… còn có
thể có nhiều sự cố mới như: đường truyền chưa thông, file đang bị hệ thống
khác chiếm giữ…
Một phần mềm được xem là dễ phát triển và hoàn thiện nếu gặp các

tình huống trên ta không phải thiết kế lại mà chỉ cần sửa đổi chút ít hoặc viết
thêm một giao diện bổ sung định dạng mới cho hệ thống.
12


Chương 1 Nhập đề
_________________________________________
Chất lượng phần mềm là một khái niệm đa chiều, khó có thể đơn giản
hóa. Ta tạm thừa nhận một sản phẩm phần mềm được xem là có chất lượng
nếu “sản phẩm đó phù hợp với đặc tả của nó.” (Kaner, 2003; Somerville,
2011).
Tồn tại một số khó khăn trong thu thập và đặc tả yêu cầu của khách
hàng:
Đặc tả phải định hướng theo những đòi hỏi về chất lượng của khách
hàng (như tính hiệu quả, độ tin cậy, tính dễ sử dụng, tính bảo mật,…) và
những yêu cầu của chính tổ chức phát triển phần mềm vốn không có trong
đặc tả (như các yêu cầu về chuẩn hóa, về khả năng bảo trì, tính tái sử
dụng,…)
Một số yêu cầu về chất lượng cũng rất khó chỉ ra một cách rõ ràng như
tính bảo trì, tính khoa học.
Bản đặc tả phần mềm thường không đầy đủ và hay mâu thuẫn.
Vì thế phải có sự thỏa hiệp về chất lượng. Hai kinh nghiệm sau đây
thường được định hướng trong pha thu thập và đặc tả yêu cầu:
1. Chúng ta không thể đợi các đặc tả hoàn thiện trước khi tập trung chú
ý đến quản lý chất lượng;
2. Chúng ta phải xây dựng một qui trình nghiêm ngặt và đủ thông thái
phục vụ cho hoạt động hoàn thiện chất lượng sản phẩm phần mềm mặc dù
đặc tả chưa hoàn thiện.
Quản lý chất lượng không chỉ quan tâm đến việc làm hạn chế tối thiểu
những khiếm khuyết của sản phẩm và đảm bảo sao cho sản phẩm đáp ứng

được các yêu cầu thể hiện trong bản đặc tả, mà còn phải quan tâm đến những
thuộc tính chất lượng khác của sản phẩm.

1.4 Một số khái niệm khác
Phần mềm đặt hàng (may đo) và phần mềm làm sẵn
Một cơ sở có thể đặt hàng cho một công ty phần mềm xây dựng một hệ
thống thông tin K dùng để quản lí các kho hàng. Khi đó phần mềm K được
gọi là phần mềm đặt hàng hay phần mềm may đo, theo nghĩa phần mềm này
định hướng đến một ứng dụng cụ thể cho một khách hàng cụ thể. Thường thì

13


Chương 1 Nhập đề
_________________________________________
với các phần mềm đặt hàng, số lượng khách hàng và phạm vi ứng dụng
không lớn, mang tính chuyên biệt, định hướng khá cụ thể, tường minh.
Một số phần mềm trên thị trường được sản xuất để phục vụ đại trà, thí
dụ như các hệ điều hành, các phần mềm trò chơi, các phần mềm tiện ích như
nén dữ liệu, mã hóa, diệt virus, tổ chức hội thảo từ xa,… Đó là các phần mềm
làm sẵn. Các phần mềm làm sẵn thường có phạm vi và lượng khách hàng
lớn, đôi khi trải rộng toàn cầu.
Người (nhóm) làm phần mềm
Theo nghĩa rộng, nhóm làm phần mềm bao gồm mọi thành viên tham
gia phát triển phần mềm, có thể kể cả mọi nhân viên của công ty, những
người dùng thử (alpha/beta test), tình nguyện viên.
Theo nghĩa hẹp, nhóm làm phần mềm chỉ bao gồm những người trực
tiếp và thường xuyên chịu trách nhiệm phát triển phần mềm, cụ thể là những
người thuộc biên chế trong dự án phần mềm đó: trưởng dự án, người thiết kế,
lập trình viên, kiểm định viên, người bán sản phẩm.

Người có thẩm quyền (stakeholder)
Những người quyết định đến sự sống còn của phần mềm. Người có
thẩm quyền bao gồm:
Người làm phần mềm, người sử dụng, người chi tài chính, lãnh đạo bên
A (bên đặt hàng), lãnh đạo của chính xí nghiệp sản xuất phần mềm đó, công
ty phần mềm khác (có thể mua sản phẩm và sau đó "diệt" sản phẩm đó,
không đưa vào sử dụng) …
Trong giáo trình này ta chỉ giới hạn quan niệm người có thẩm quyền
bao gồm:
- Người sử dụng,
- Người chi tài chính, lãnh đạo bên A (bên đặt hàng),
- Lãnh đạo của chính xí nghiệp sản xuất phần mềm đó (B).

1.5 Mô hình phát triển phần mềm
Là một hệ thống các quan niệm, phương pháp, qui trình, kỹ thuật vận
dụng trong phát triển phần mềm. Tên gọi mô hình thường trùng với tên của
qui trình phát triển phần mềm.
14


Chương 1 Nhập đề
_________________________________________
Thí dụ
(Sommerville, 2011):
 Mô hinh tuyến tính,
 Mô hình thác nước,
 Mô hình tăng trưởng,
 Mô hình xoắn ốc,
 Mô hình bậc thang.
Các mô hình nói chung có những thành phần tương tự nhau, chúng

khác nhau ở trình tự tổ hợp, lắp ghép các thành phần. Điểm khác biệt nổi trội
hơn cả giữa các mô hình là các vòng lặp thể hiện qui trình làm mịn tại các
pha của qui trình.

1.6 Qui trình phát triển phần mềm
Để tạo ra một sản phẩm phần mềm phải trải qua nhiều giai đoạn, người
ta gọi là qui trình phát triển phần mềm. Theo nghĩa rộng, qui trình phát triển
phần mềm được khởi động từ khi bắt đầu có ý tưởng và bao gồm nhiều vòng
đời dưới dạng đường xoắn ốc thể hiện sự hoàn thiện dần của dòng sản phẩm
theo thời gian. Vòng đời sau cao hơn vòng đời trước. Mỗi vòng đời thường
bắt đầu từ công đoạn thiết kế, đặc tả các yêu cầu từ phía khách hàng đối với
hệ thống và kết thúc sau công đoạn kiểm định chấp nhận một phiên bản của
sản phẩm. Vòng đời tiếp theo là một bước phát triển để tạo ra một phiên bản
mới của dòng sản phẩm do công ty phần mềm đang bảo trì. Khối lượng công
việc trong từng giai đoạn của quá trình sản xuất phần mềm cũng thay đổi
theo thời gian.
Qui trình phát triển phần mềm được xác định theo mô hình phát triển
phần mềm.
Ta tạm đơn giản hóa qui trình phát triển phần mềm gồm các công việc
sau đây:
- Phân tích yêu cầu;
- Thiết kế sơ bộ;
- Thiết kế chi tiết;
- Lập trình và kiểm định đơn vị;
- Tích hợp và kiểm định tích hợp;
15


Chương 1 Nhập đề
_________________________________________

- Kiểm định hệ thống;
- Khai thác và bảo trì hệ thống.
Trong tài liệu này và nhiều tài liệu khác, các thuật ngữ sau được xem là
tương đương:
- Xây dựng phần mềm,
- Làm phần mềm,
- Sản xuất phần mềm,
- Phát triển phần mềm.
Thuật ngữ phát triển phần mềm thường được dùng hơn cả vì nó thể hiện
được động thái, tức là qui trình xây dựng phần mềm từ mức đơn giản nhất,
mức khởi thủy, đến khi nhận được một hệ thống phần mềm hoàn chỉnh.
Công nghệ phần mềm được phát triển theo thời gian. Trong vài thập
niên gần đây người ta quan sát thấy sự xuất hiện nhiều mô hình tiên tiến cùng
những môi trường và công cụ trợ giúp làm phần mềm. Các ngôn ngữ lập
trình cũng tiến bộ đáng kể, ngày càng trở nên tâm lí hơn, dễ sử dụng hơn, các
từ khóa, từ dành riêng được hiển thị với màu và font phân biệt, công cụ bẫy
lỗi tự động cũng được phát triển theo kịp sự tăng trưởng của môi trường sản
xuất phần mềm…

16


Chương 1 Nhập đề
_________________________________________

Xác định
yêu cầu

Thiết kế

Cài đặt,
kiểm định

Tích hợp

Khai thác
và bảo trì

Hình 1.2 Mô hình thác nước đơn giản

17


Chương 2
Lỗi của sản phẩm phần mềm

Nội dung
2.1 Thế nào là lỗi phần mềm?
2.2 Tại sao lỗi phần mềm xuất hiện?
2.3 Chi phí sửa lỗi

2.1 Thế nào là lỗi phần mềm?
Có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng tựu chung,
có thể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không khớp giữa
chương trình và đặc tả của nó.” (Bezier, 1990).
Dựa vào nhận định trên, chúng ta có thể thấy lỗi phần mềm xuất hiện
theo ba dạng sau:
1. Sai: Sản phẩm được xây dựng khác với đặc tả;
2. Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản
phẩm đã xây dựng;

3. Thừa: Một yêu cầu được thể hiện trong sản phẩm nhưng lại không
xuất hiện trong bản đặc tả. Cũng có trường hợp yêu cầu này có thể là một
thuộc tính sẽ được người dùng chấp nhận nhưng khác với đặc tả nên vẫn coi
là có lỗi.
Một hình thức khác nữa liên quan đến các khía cạnh tâm lí khách hàng
cũng được xem là lỗi, đó là phần mềm khó hiểu, khó sử dụng, chậm hoặc dễ
gây cảm nhận rằng phần mềm họat động không đúng.


Chương 2 Lỗi của sản phẩm phần mềm
_________________________________________

2.2 Tại sao lỗi phần mềm xuất hiện?
Lỗi xuất hiện nhiều nhất không phải do lập trình.
Số lỗi do đặc tả gây ra là nhiều nhất, chiếm khoảng 80%.
Tại pha đầu tiên của qui trình phát triển phần mềm, pha thu thập và đặc
tả yêu cầu, người thiết kế trao đổi với khách hàng để thu nhận các yêu cầu
đặt ra đối với sản phẩm phần mềm. Các yêu cầu này sau đó được đặc tả, tức
là được phát biểu dưới dạng chặt chẽ, hoàn chỉnh, không thể gây nhập nhằng
trong cách hiểu.
Người ta thường sử dụng hai công cụ - ngôn ngữ trong đặc tả yêu cầu:
1. Ngôn ngữ hình thức: chủ yếu là các ngôn ngữ toán học và logic với
một hệ thống kí hiệu và cú pháp chặt chẽ, không nhập nhằng về ngữ nghĩa.
Đặc tả dưới dạng này thường ngắn gọn, súc tích, nhưng thường khó hiểu, đặc
biệt là khi cần trao đổi, thống nhất với các khách hàng không có thiên hướng
về toán học;
2. Ngôn ngữ tự nhiên: Dễ đọc, dễ hiểu nhưng thường gây nhập nhằng,
khó phát hiện mâu thuẫn.
Nguyên nhân sinh lỗi tại pha đặc tả
 Đặc tả không hình thức (hoặc phi hình thức): Ngôn ngữ tự nhiên

dễ hiểu nhưng rườm rà, nhập nhằng.
 Đặc tả hình thức: Đơn giản, chính xác nhưng khó hiểu, khó cài
đặt.
 Quên đặc tả một yêu cầu nào đó.
 Đặc tả không hết.
 Yêu cầu đã thay đổi nhưng đặc tả không thay đổi.
 Đặc tả khác nhau cho cùng một yêu cầu xuất hiện trong các cấu
phần khác nhau của hệ thống.
Thí dụ
Trong đặc tả bài toán phân số (Huy, 1996):
1. Đặc tả phi hình thức: Phân số là một cặp t/m, trong đó t là một số
nguyên, m là một số nguyên dương; t được gọi là tử số, m được gọi là mẫu số
của phân số.
19


Chương 2 Lỗi của sản phẩm phần mềm
_________________________________________

Nguyên nhân khác

Hình 2.1 – Các nguyên
nhân gây ra lỗi phần mềm

Lập trình
Đặc tả
Thiết kế

Phép chia hai phân số: Thương của hai phân số là phân số được rút gọn
từ phân số có tử số là tích của tử số của phân số thứ nhất và mẫu số của phân

số thứ hai; mẫu số là tích của mẫu số của phân số thứ nhất và tử số của phân
số thứ hai.
2. Đặc tả hình thức:
Phân số = {(t,m) | t  Z, m  Z+}

(*)

Trong đó:
Z = {0, 1, 2, 3, …}
Z+ = {1, 2, 3, …}
Phép chia hai phân số:
(t1,m1)/(t2,m2) = Reduce(t1m2, t2m1),
trong đó Reduce(t, m) = (t/d, m/d) với d = gcd(t, m).
Hàm gcd là hàm tìm ước chung lớn nhất của hai số tự nhiên.
Đặc tả phép chia như trên, kể cả trường hợp phi hình thức và hình thức,
là sai với đặc tả phân số. Chẳng hạn, khi ta thực hiện chia hai phân số
(1,3)/(2,5) = (5,6), thì mẫu số trong trường hợp này lại là một số âm,
không phù hợp với đặc tả phân số.
Đây là một ví dụ đơn giản về việc đặc tả sai do không đủ cẩn thận. Với
các bài toán lớn thì việc đặc tả sẽ rất khó và dễ nhầm lẫn, sai sót.
Bài tập 2.1
Bạn hãy phân tích đề toán sau để phát hiện tính nhập nhằng trong phát
biểu:
“Liệt kê các số tự nhiên lẻ có ba chữ số lập thành một cấp cộng.”

20


Chương 2 Lỗi của sản phẩm phần mềm
_________________________________________

Gợi ý
1. Dễ hiểu là các số sau đây thỏa yêu cầu của đầu bài:
123, 147, 567, 369,…
2. Các số sau đây cũng thỏa yêu cầu của đầu bài:
321, 741, 765, 963, …
3. Theo ý bạn các số sau đây có thỏa yêu cầu của đầu bài hay không?
16241, 3002001, 1030209, …
Nếu ta hiểu đầu bài như sau:
- Số tự nhiên có chữ số hàng đơn vị là một chữ số lẻ;
- Trong số tự nhiên đó có thể chọn ra ba chữ số để sắp chúng thành
một cấp cộng.
thì các số liệt kê trong dẫn chứng thứ 3 là đúng đắn.
Bài tập 2.2
Bạn thử gắng tìm 6 nghĩa khác nhau của câu nói dưới đây:
"Ông cụ già đi nhanh quá"
Nhận xét
Các chuyên gia ngôn ngữ cho biết rằng: mặc dầu ngôn ngữ tự nhiên là
nhập nhằng nhưng nó đủ tinh tế để diễn tả chính xác mọi tình huống. Nhập
nhằng hay không là do người sử dụng.
Chúng ta thử sửa lại đề toán nói trên như sau:
“Liệt kê các số tự nhiên lẻ có đúng ba chữ số. Ba chữ số này, theo trật
tự xuất hiện từ trái qua phải, lập thành một cấp cộng.”
Nguồn gây ra lỗi lớn thứ hai là thiết kế. Đó là nền tảng mà lập trình viên
dựa vào để nỗ lực thực hiện kế hoạch cho phần mềm.
Lỗi do lập trình gây ra cũng khá dễ hiểu. Khi lập trình ai cũng có thể
mắc lỗi. Thời kì đầu, phát triển phần mềm thường đồng nghĩa với lập trình.
Công việc lập trình thì nặng nhọc, do đó lỗi do lập trình gây ra là chủ yếu.
Ngày nay, công việc lập trình chỉ là một phần việc của quá trình phát triển
phần mềm. Với sự hỗ trợ của nhiều công cụ và môi trường lập trình cao cấp
và tiện dụng, việc lập trình trở nên nhẹ nhàng hơn, mặc dù độ phức tạp phần

mềm lớn hơn rất nhiều. Do đó, lỗi do lập trình gây ra cũng ít hơn. Tuy nhiên,
21


Chương 2 Lỗi của sản phẩm phần mềm
_________________________________________
nguyên nhân sinh lỗi trong lập trình ngày nay lại nhiều hơn. Đó là do độ
phức tạp của phần mềm, do tài liệu nghèo nàn, do sức ép thời gian hoặc chỉ
đơn giản là những lỗi “không nói lên được”. Một điều cũng hiển nhiên là
nhiều lỗi xuất hiện trên bề mặt lập trình nhưng thực ra lại do lỗi của đặc tả
hoặc thiết kế.
Một nguyên nhân khác tạo ra lỗi là do bản thân các công cụ phát triển
phần mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch, các
mẫu có xu hướng tổng quát hóa…

2.3 Chi phí sửa lỗi
Bảo trì là phần chi phí chính của phần mềm và kiểm định là hoạt động
chi phí đắt thứ hai, ước tính khoảng 40% chi phí trong quá trình phát triển
ban đầu của sản phẩm phần mềm. Kiểm định cũng chiếm phần chi phí quan
trọng của giai đoạn bảo trì, do phải tiến hành kiểm định lại những thay đổi
trong quá trình sửa lỗi và đáp ứng yêu cầu người dùng (Martin, 2007).
Kiểm định và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của
vòng đời phần mềm. Tuy nhiên chi phí cho việc tìm và sửa lỗi tăng một cách
đáng kể trong quá trình phát triển phần mềm.
Sự thay đổi về một yêu cầu của khách hàng tại pha đầu tiên, pha thu
thập và đặc tả yêu cầu thường không đòi hỏi chi phí lớn, nếu không nói là
không đáng kể. Chi phí sẽ tăng nhiều hơn nếu các yêu cầu bị thay đổi sau khi
đã lập trình. Thay đổi yêu cầu lúc đó đồng nghĩa với việc viết lại chương
trình, đôi khi là kiến trúc lại hệ thống.
Việc sửa lỗi sẽ không còn đáng kể nếu lập trình viên tự phát hiện lỗi của

mình. Đương nhiên, trường hợp này không kéo theo bất kì chi phí phụ trội
nào ngoài thời gian tự sửa lỗi của lập trình viên. Họ không phải giải thích lỗi
cho bất kỳ người nào. Họ cũng không phải nhập lại lỗi đó vào cơ sở dữ liệu
lỗi và lưu vết lỗi. Người kiểm định và người quản lý không phải phải duyệt
lại tình trạng lỗi. Và lỗi đó không ảnh hưởng đến công việc của người khác
trong nhóm dự án.
Sửa một lỗi trước khi phát hành một phần mềm rẻ hơn rất nhiều so với
việc khắc phục nó sau khi đã phát hành.

22


Chương 2 Lỗi của sản phẩm phần mềm
_________________________________________

Chi phí để sữa lỗi

Theo kết quả nghiên cứu của IBM, GTE và TRW lỗi được phát hiện
càng muộn thì chi phí cho việc sữa lỗi càng lớn (Boehm, 1979). Chi phí tăng
theo hàm mũ như trong hình 2.1.

Đặc tả

Thiết kế

lập trình

Kiểm định

Phát hành

Hình 2.1 – Chi phí sửa lỗi theo các pha
Chúng ta đã từng chứng kiến sự cố máy tính năm 2000 (Y2K). Từ một
giải pháp tiết kiệm bộ nhớ, chỉ dùng hai chữ số cuối để biểu diễn năm thay
cho bốn chữ số vào đầu những năm 70 của thế kỷ trước dẫn đến việc 25 năm
sau làm cả thế giới lo sợ và phải bỏ ra nhiều tỉ dollars để khắc phục sự cố
này.

23


Chương 3
Kiểm định phần mềm

Nội dung
3.1 Khái niệm chung
3.2 Hai vấn đề trọng tâm: K&K
3.3 Qui trình kiểm định phần mềm
3.4 Tính không đầy đủ của kiểm định
3.5 Thanh sát (inspection) và kiểm điểm (review)
3.6 Test tự động

3.1 Khái niệm chung
Kiểm định phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được
phát hiện. Tuy nhiên, trong nhiều bối cảnh, hoạt động của chương trình có
thể chưa bộc lộ lỗi. Kiểm định phần mềm là quá trình khảo sát, kiểm tra, thực
thi một hệ thống phần mềm để xác định xem phần mềm đó hoạt động có
đúng với đặc tả không và thể hiện hành vi có đúng như kì vọng của người sử
dụng hay không.
Trên thực tế, quan sát một hệ thống đang thực thi là khác biệt so với

việc duyệt mã nguồn của chương trình viết cho hệ thống đó. Thông thường,
người phát triển phần mềm luôn luôn đọc lại và phân tích mã nguồn. Nhưng
điều đó không có nghĩa là họ đã phát hiện hết lỗi. Có những lỗi nằm ngay
trong đầu, trong quan niệm của họ. Như vậy, nhiệm vụ quan trọng của kiểm
định hệ thống phần mềm là xác định xem hệ thống đó có phục vụ tốt hay
không. Một hệ thống được xem là phục vụ tốt nếu như hệ thống đó đáp ứng
đầy đủ và chính xác các yêu cầu đặt ra trong bản thiết kế. Tại thời điểm này,
ta tạm giả thiết rằng các yêu cầu được đặc tả đúng như phát biểu của khách


Chương 3 Kiểm định phần mềm
_________________________________________
hàng. Phục vụ tốt được hiểu là hệ thống thể hiện đúng như kì vọng của người
sử dụng. Đặc tả là căn cứ chủ yếu hỗ trợ cho việc kiểm định. Đó là một bản
mô tả tường minh các hành vi được gọi là đúng và được dùng làm căn cứ cho
hoạt động thiết kế, mã hóa và kiểm tra chương trình.
Khi phần mềm được thực thi, mỗi hành vi thể hiện không đúng như đặc
tả sẽ được coi là một lỗi phần mềm. Nói chung, người phát triển hệ thống
phải tự chẩn đoán nguyên nhân sinh lỗi ngay trong mã nguồn.
Mục đích của kiểm định phần mềm là tìm ra lỗi chưa được phát hiện ở
thời điểm sớm nhất có thể và đảm bảo rằng lỗi đó đã được sửa, được khắc
phục. Chúng ta sẽ nghiên cứu kĩ hơn vấn đề này ở những phần tiếp theo.
Mục tiêu của kiểm định phần mềm là thiết kế tài liệu, qui trình kiểm
định một cách có hệ thống và thực thi qui trình này sao cho có hiệu quả, tiết
kiệm được thời gian, công sức và chi phí.
Trên quan điểm qui trình, kiểm định phần mềm là một phần của kiểm
tra và kiểm dụng phần mềm. Kiểm tra và kiểm dụng là hai khái niệm thuộc
phạm vi của công nghệ phần mềm và sẽ được giới thiệu chi tiết trong các
mục tiếp theo. Công nghệ phần mềm lại là một phần của công nghệ hệ thống.
Nhìn từ ngữ cảnh chất lượng, kiểm định phần mềm cũng là một phần phần

của kiểm tra và kiểm dụng phần mềm, nên cũng có thể xem như là một phần
của hoạt động quản lí chất lượng phần mềm.
Mục tiêu kiểm định
1. Phát hiện lỗi sớm
2. Giảm thiểu thời gian
3. Giảm thiểu chi phí
Hình 3.1 - Kiểm định phần mềm trong một số ngữ cảnh
Tỉ lệ chi phí về nhân lực và kinh phí cho kiểm định nói chung vẫn lớn.
Ngày nay, hoạt động kiểm định có thể không tách thành một pha riêng biệt
mà được chia nhỏ và nhúng trong mọi công đoạn của qui trình phát triển
phần mềm. Thí dụ, ngay tại pha thu thập và đặc tả yêu cầu người ta đã thực
hiện kiểm định theo tiếp cận hình thức để phát hiện ra các lỗi logic của hệ
thống.
Ta minh họa nhận định trên qua khái niệm kĩ nghệ phòng sạch do IBM
đề xuất. Tư tưởng chủ đạo của kĩ nghệ này là: giữ cho sản phẩm (trong
25