Kiểm định phần mềm bằng kỹ thuật hộp đen.PDF

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ



Trương Thị Thu Hà



KIỂM ĐỊNH PHẦN MỀM
BẰNG KỸ THUẬT HỘP ĐEN




LUẬN VĂN THẠC SĨ










Hà nội - 2006


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trương Thị Thu Hà



KIỂM ĐỊNH PHẦN MỀM
BẰNG KỸ THUẬT HỘP ĐEN

Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ thông tin
Mã số: 1.01.10

LUẬN VĂN THẠC SĨ

HƯỚNG DẪN KHOA HỌC:
PGS TSKH Nguyễn Xuân Huy






Hà nội - 2006
MỤC LỤC
Trang
Lời cảm ơn
Lời cam đoan
Danh mục các bảng i
Danh mục các hình vẽ - sơ đồ ii

Mở đầu iv
CHƯƠNG 1: TỔNG QUAN KIỂM ĐỊNH PHẦN MỀM
1.1. Các mô hình phát triển phần mềm 1
1.2. Chất lượng phần mềm 6
1.3. Kiểm định phần mềm 12
CHƯƠNG 2: KỸ THUẬT VÀ CHIẾN LƯỢC KIỂM ĐỊNH PHẦN MỀM THEO
TIẾP CẬN HỘP ĐEN
2.1. Kiểm định phần mềm bằng kỹ thuật hộp đen 20
2.2. Thiết kế các giai đoạn kiểm định phần mềm theo tiếp cận hộp đen 38
CHƯƠNG 3: XÂY DỰNG ỨNG DỤNG KIỂM ĐỊNH
3.1. Mục tiêu xây dựng kiểm định…………………………………… 53
3.2. Giới thiệu tổng quan phần mềm………………………………… 55
3.3. Cài đặt và hướng dẫn sử dụng……………………………………….56
3.4. Chương trình dùng để kiểm định………………………………….62
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN…………………………………………. 81
TÀI LIỆU THAM KHẢO …………………………………………………… …83


LỜI CAM ĐOAN

Tôi xin cam đoan :
1. Đây là công trình nghiên cứu của riêng tôi.
2. Kết quả nêu trong luận văn là trung thực và chưa từng được ai công
bố trong bất kỳ công trình nào khác.
Tác giả

Trương Thị Thu Hà


lời cảm ơn

Trong suốt quá trình học tập và thực hiện luận văn, em đã nhận đ-ợc sự
h-ớng dẫn của quý Thầy Cô , cùng sự giúp đỡ động viên của bạn bè và gia đình.
Em xin chân thành cảm ơn quý Thầy khoa Công nghệ thông tin, Tr-ờng
Đại học công nghệ - Đại học Quốc gia Hà nội cùng các Thầy Viện Công nghệ
thông tin - Viện Khoa học và Công nghệ Việt nam đã tận tình giảng dạy và tạo
điều kiện thuận lợi cho em học tập và nghiên cứu trong thời gian học tập tại
tr-ờng.
Lời cảm ơn sâu sắc em xin dành cho Thầy giáo, pgs. tskh Nguyễn Xuân
Huy, Viện Công nghệ thông tin, Viện Khoa học và Công nghệ Việt nam. Trong
thời gian qua, Thầy đã tận tình h-ớng dẫn, chỉ bảo tận tình và truyền đạt những
kiến thức quý báu giúp em thực hiện tốt luận văn này.
Nhân dịp này, em cũng xin gửi lời cảm ơn đến bạn bè đồng nghiệp. Nhất
là những ng-ời thân trong gia đình đã luôn bên cạnh động viên, giúp đỡ em trong
suốt quá trình học tập.
Hà nội ngày 22 tháng 11 năm 2006
Tr-ơng Thị Thu Hà

i
DANH MỤC CÁC BẢNG
Trang
Bảng 1.1. Tỷ lệ công việc các giai đoạn phát triển phần mềm 14
Bảng 2.1. Kiểm định theo các lớp phân hoạch hợp lệ điểm thi 27
Bảng 2.2. Kiểm định theo các lớp phân hoạch hợp lệ điểm thi 28
Bảng 2.3. Kiểm định theo các lớp phân hoạch hợp lệ điểm thi 28
Bảng 2.4. Kiểm định theo các lớp phân hoạch hợp lệ điểm thi 29
Bảng 2.5. Kiểm định theo các lớp phân hoạch hợp lệ điểm thi 29
Bảng 2.6. Kiểm định theo các lớp phân hoạch không hợp lệ điểm thi 30
Bảng 2.7. Kiểm định cho tất cả các lớp phân hoạch điểm thi 30
Bảng 2.8. Kiểm định cho tất cả các lớp phân hoạch điểm thi… 31

Bảng 2.9. Kiểm định cho tất cả các lớp phân hoạch điểm thi 31
Bảng 2.10. Bảng quyết định 35
Bảng 2.11. Quan hệ nhân quả thuế thu nhập 36
Bảng 2.12. Bảng quyết định tính thuế thu nhập 37
Bảng 2.13. Minh họa các testcase chương trình sắp xếp 52
Bảng 3.1. Testcase_Bai1 63
Bảng 3.2. Testcase_Bai2 66
Bảng 3.3. Testcase_Bai3 71
Bảng 3.4. Testcase_Bai4 77

ii
DANH MỤC CÁC HÌNH VẼ - SƠ ĐỒ
Trang
Hình 1.1. Mô hình tuần tự tuyến tính 1
Hình 1.2. Mô hình làm bản mẫu 2
Hình 1.3. Mô hình RAD 3
Hình 1.4. Mô hình tăng dần 4
Hình 1.5. Một phần tử của mô hình tiến trình tương tranh 6
Hình 1.6. Chi phí cho việc sửa lỗi 10
Hình 1.7. Các giai đoạn kiểm định 16
Hình 1.8. Quy trình chi tiết quá trình kiểm định 17
Hình 1.9. Minh họa kiểm định hộp đen 17
Hình 2.1. Phân hoạch các lớp tương đương 22
Hình 2.2. Sơ đồ phân hoạch các lớp tương đương điểm thi 24
Hình 2.3. Sơ đồ phân hoạch các lớp tương đương theo giá trị biên tổng điểm 25
Hình 2.4. Sơ đồ phân tích giá trị biên cho tập số nguyên X, Y 34
Hình 2.5. Đồ thị nhân quả tính thuế thu nhập… 37
Hình 2.6. Chiến lược kiểm định … 39
Hình 2.7. Các bước kiểm định 39
Hình 2.8. Kiểm định đơn vị (a) và mội trường kiểm định đơn vị 43

Hình 2.9. Tích hợp Top - down …44
Hình 2.10. Tích hợp bottom - up 45
Hình 2.11. Sơ đồ tổng quát các giai đoạn kiểm định theo tiếp cận hộp đen …49
Hình 2.12. Chi tiết các giai đoạn kiểm định theo tiếp cận hộp đen …50
Hình 3.1. Cây thư mục lưu bài thi… 55
Hình 3.2. Các lớp chương trình kiểm định 56
Hình 3.3. Giao diện ban đầu 58

iii
Hình 3.4. Giao diện nhập bài thi và Testcase 59
Hình 3.5. Giao diện danh sách thí sinh 59
Hình 3.6. Giao diện kết quả chấm thi 60
Hình 3.7. Giao diện kết quả chi tiết 61
Hình 3.8. Giao diện nhập thêm thí sinh 61
Hình 3.9. Giao diện nhập thêm Testcase 61

iv
MỞ ĐẦU
1. Lý do chọn đề tài
Với việc phát triển nhanh chóng của ngành Công nghệ thông tin nói chung và
Công nghệ phân mềm nói riêng. Hàng triệu phần mềm đã ra đời nhằm đáp ứng nhu cầu
của khách hàng. Hơn thế nữa, các sản phẩm phần mềm còn giúp cho con người tiết
kiệm tối đa công sức, thời gian, chi phí,… giúp cho công việc đạt hiệu quả cao hơn.
Việc phát triển phần mềm cũng ngày càng được hỗ trợ bởi nhiều công cụ tiến
tiến, giúp cho việc xây dựng phần mềm đỡ khó khăn và đáp ứng nhu cầu người dùng
cao hơn. Tuy nhiên, do độ phức tạp của phần mềm, cho nên dù các hoạt động đảm bảo
chất lượng phần mềm nói chung và kiểm định nói riêng ngày càng chặt chẽ và khoa
học, vẫn không đảm bảo được rằng các sản phầm phần mềm đang được ứng dụng
không có lỗi. Lỗi vẫn luôn tiềm ẩn trong mọi sản phẩm phần mềm và nhiều khi gây ra
những thiệt hại nặng nề về tài chính cũng như ảnh hưởng đến công việc.

Vì vậy, kiểm định phần mềm là một bước không thể thiếu của công nghệ phần
mềm bao gồm các bước: phân tích, thiết kế, mã hoá, kiểm định và bảo trì. Kiểm định
phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm để
đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế và các yêu cầu đó đáp ứng các
nhu cầu của người dùng.
Các kỹ thuật kiểm định phần mềm đã, đang được nghiên cứu, và việc kiểm định
phần mềm trở thành qui trình bắt buộc trong các dự án phát triển phần mềm trên thế
giới. Kiểm định phần mềm là một hoạt động rất tốn kém, mất thời gian, và khó phát
hiện được hết lỗi. Vì vậy, việc kiểm định phần mềm đòi hỏi phải có chiến lược phù
hợp, một kế hoạch hợp lý và việc thực hiện được quản lí chặt chẽ.
Ở Việt Nam, trong thời gian qua việc kiểm định phần mềm bị xem nhẹ, với
công cụ lập trình hiện đại, người ta cảm tính cho rằng không kiểm định cũng không
sao, nên chưa có nhiều sự quan tâm, nghiên cứu. Những năm gần đây, một số tổ chức
nghiên cứu và phát triển phần mềm đã bắt đầu có những quan tâm hơn đến vấn đề kiểm

v
định phần mềm. Tuy nhiên, vấn đề kiểm định phần mềm hầu như vẫn chưa được đầu tư
và quan tâm đúng mức. Nước ta đang trong quá trình xây dựng một ngành công nghiệp
phần mềm thì không thể xem nhẹ việc kiểm định phần mềm vì xác suất thất bại sẽ rất
cao, hơn nữa, hầu hết các công ty phần mềm có uy tín đều đặt ra yêu cầu nghiêm ngặt
là nếu một phần mềm không có tài liệu kiểm định đi kèm thì sẽ không được chấp nhận.
2. Đối tượng và phạm vi nghiên cứu
- Luận văn tập trung nghiên cứu, tìm hiểu, đánh giá các nguyên lý, chiến lược và
kỹ thuật kiểm định phần mềm bằng kỹ thuật hộp đen.
- Áp dụng kỹ thuật kiểm định hộp đen để xây dựng chương trình chấm thi học
sinh giỏi Tin học.
3. Phương pháp nghiên cứu
- Nghiên cứu, tìm hiểu các kỹ thuật, chiến lược kiểm định phần mềm theo kỹ
thuật hộp đen.
- Sử dụng phương pháp kiểm định hộp đen đã nghiên cứu để thiết kế bộ test cho

chương trình cụ thể. Đưa ra tài liệu kế hoạch kiểm định và đặc tả kiểm định;
Xây dựng chương trình thực thi kiểm định.
4. Kết quả nghiên cứu
- Thiết kế các trường hợp kiểm định theo kỹ thuật hộp đen cho một số chương
trình cụ thể.
- Tạo các tài liệu kiểm định (đặc tả trường hợp kiểm định và kết quả kiểm định.)
- Xây dựng chương trình kiểm định chấm bài thi học sinh giỏi Tin học.
5. Ý nghĩa khoa học và thực tiễn của Luận văn
Việc thiết kế các giai đoạn kiểm định phần mềm theo tiếp cận hộp đen có thể
được dùng làm tài liệu tham khảo cho việc kiểm định phần mềm tại một số công ty, cơ
quan, trường học tại Việt nam.

vi
Định hướng người dùng hiểu tầm quan trọng của việc kiểm định phần mềm, để
khái niệm này không còn mang tính lý thuyết mà sẽ là một phần không thể thiếu trong
quá trình xây dựng và phát triển phần mềm.
6. Chọn tên đề tài: “Kiểm định Phần Mềm Theo Kỹ Thuật Hộp Đen”
7. Bố cục của Luận văn: Nội dung của Luận văn chia thành 4 chương :
Chương 1: Tổng quan kiểm định phần mềm
Đề cập sơ lược các mô hình phát triển phần mềm, vấn đề chất lượng phần mềm
và tầm quan trọng của việc kiểm định phần mềm, các kỹ thuật kiểm định phần mềm
hay sử dụng.
Chương 2: Kỹ thuật và chiến lược kiểm định phần mềm theo tiếp cận hộp đen
Chương này trình bày các kỹ thuật cơ bản kiểm định phần mềm theo tiếp cận
hộp đen như: xây dựng lớp phân hoạch tương đương, phân tích giá trị biên, kỹ thuật đồ
thị nhân quả, kiểm định so sánh. Để từ đó người đọc có những khái niệm cơ bản nhất
về kiểm định phần mềm theo kỹ thuật hộp đen.
Phần tiếp theo của chương giới thiệu các chiến lược kiểm định phần mềm : kiểm
định đơn vị, kiểm định tích hợp, kiểm định hợp lệ và kiểm định hệ thống.
Nội dung chính của chương này là giúp người đọc có cái nhìn tổng quan khi xây

dựng kiểm định phần mềm bằng kỹ thuật hộp đen theo các giai đoạn: thiết kế các
trường hợp kiểm định, thiết kế giao diện và lập trình các trường hợp kiểm định, thực
hiện các trường hợp kiểm định, kiểm tra và đánh giá kết quả.
Chương 3: Xây Dựng Ứng Dụng Kiểm định
Để minh hoạ cho phần lý thuyết ở trên, chương 3 sẽ trình bày một chương trình
áp dụng kỹ thuật hộp đen để kiểm định bài thi của học sinh trong các kỳ thi học sinh
giỏi Tin học:
- Xây dựng các test case cho từng bài thi.

vii
- Xây dựng chương trình và giao diện để: đọc vào bài thi của học sinh, thực hiện
các bài thi đó với các testcase đã xây dựng, sau đó so sánh kết quả của bài thi và
kết quả dự kiến của testcase. Đưa ra đánh giá và cho điểm.
- Tổng hợp điểm của từng bài thi để cho kết quả cuối cùng.
Các nội dung chính trong chương 1 và 2 chủ yếu được trình bày lại qua quá
trình đọc và nghiên cứu tài liệu của tác giả với những kiến thức đã được nhiều nhà
khoa học công bố. Trong đó phần đóng góp của tác giả là:
- Hệ thống hóa lại kiến thức theo cách tiếp cận kỹ thuật hộp đen.
- Từ các chiến lược kiểm định phần mềm nói chung. Tác giả áp dụng để
xây dựng các giai đoạn thiết kế kiểm định phần mềm theo kỹ thuật hộp
đen.
Toàn bộ nội dung chương 3 là kết quả của riêng tác giả với việc xây dựng phần
mềm kiểm thử theo kỹ thuật hộp đen bằng cách thiết kế bộ testcase chấm thi học sinh
giỏi Tin học Toàn quốc.

- 1 -
CHƢƠNG 1
TỔNG QUAN KIỂM ĐỊNH PHẦN MỀM

Phần đầu của chương giới thiệu sơ lược một số mô hình cơ bản theo các quy

trình phát triển phần mềm.
Phần tiếp theo đánh giá chất lượng phần mềm qua một số tiêu chí có sẵn. Từ đó
phân tích lý do tại sao phải kiểm định phần mềm, và nhấn mạnh tầm quan trọng của
kiểm định phần mềm trong quy trình phát triển của mỗi phần mềm nói riêng và nhận
thức của những người làm phần mềm nói chung.
1.1. CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM
1.1.1. Phần mềm là gì?
Phần mềm là một (bộ) chương trình được cài đặt trên máy tính nhằm thực hiện
một nhiệm vụ tương đối độc lập và phục vụ cho một ứng dụng cụ thể như việc quản lí
hoạt động của máy tính hoặc áp dụng máy tính trong các hoạt động kinh tế, quốc
phòng, văn hóa, giáo dục,
Việc 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, bắt đầu từ khi có ý tưởng đến khi đưa ra sản phẩm
phần mềm thực thi. 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.
1.1.2. Các mô hình phát triển phần mềm [5]
a. Mô hình tuần tự tuyến tính
Mô hình tuần tự tuyến tính còn gọi là vòng đời cổ điển hay mô hình thác nước.


Kỹ nghệ hệ
thống/ thông tin
Phân
tích
Thiết
kế
Lập
trình
Kiểm
định

Vận
hành
Hình 1.1. Mô hình tuần tự tuyến tính

- 2 -
Mô hình tuần tự tuyến tính bao gồm các hoạt động:
- Kỹ nghệ và mô hình hoá hệ thống thông tin: thiết lập yêu cầu cho mọi phần tử hệ
thống và phân bổ một tập con các yêu cầu đó cho phần mềm.
- Phân tích yêu cầu phần mềm: tiến trình thu thập yêu cầu phần mềm như chức
năng, hiệu năng, giao diện,…lập tư liệu thông qua việc thăm dò khách hàng.
- Thiết kế: là một tiến trình tập trung vào bốn bước chính: cấu trúc dữ liệu, kiến
trúc phần mềm, biểu diễn giao diện và chi tiết thuật toán. Tiến trình thiết kế mô tả các
yêu cầu thành một biểu diễn phần mềm.
- Sinh mã: Thiết kế phải được biên dịch sang ngôn ngữ máy.
- Kiểm định: Việc kiểm định được thực hiện sau khi mã hoá, tiến hành kiểm định
phần mềm để xem xét các chức năng có đúng đặc tả hay không? hoặc để làm lộ ra các
lỗi và đảm bảo dữ liệu vào có cung cấp đúng dữ liệu ra muốn có?
- Hỗ trợ: Trong quá trình sử dụng phần mềm có thể có những thay đổi do khách
quan hoặc chủ quan. Vì vậy, việc bảo trì phần mềm phải áp dụng lại các bước vòng đời
nói trên.
b. Mô hình bản mẫu
Mô hình làm bản mẫu bắt đầu với việc thu thập yêu cầu. Người phát triển phần
mềm xác định các mục tiêu tổng thể cho phần mềm thông qua khách hàng. Sau đó thiết
kế nhanh để đưa ra một bản mẫu với những yêu cầu cơ bản, người dùng đánh giá và bổ
sung để làm mịn các yêu cầu và tiếp tục quá trình xây dựng và điều chỉnh bản mẫu để
đạt được phần mềm đúng theo yêu cầu của khách hàng.

Lắng nghe
khách hàng
Xây dựng/điều
chỉnh bản mẫu
Khách hàng sử
dụng bản mẫu
Hình 1.2. Mô hình làm bản mẫu

- 3 -
c. Mô hình RAD
RAD là mô hình tiến trình phát triển phần mềm tăng dần nhấn mạnh vào chu kỳ
phát triển cực ngắn. Cách tiếp cận RAD bao gồm các pha sau đây:












- Mô hình hoá nghiệp vụ: luồng thông tin giữa các chức năng nghiệp vụ được mô hình
hoá theo cách trả lời câu hỏi như: thông tin nào được sinh ra? ai sinh ra nó? Ai xử lý
nó?
- Mô hình hoá dữ liệu: các thông tin được làm mịn thành tập các dữ liệu, các đặc trưng
của từng sự vật được nhận diện và mối quan hệ giữa chúng được xác định.
- Mô hình hoá xử lý: dữ liệu được biến đổi để đạt tới luồng thông tin cần cho việc thực

hiện chức năng nghiệp vụ. Các mô tả xử lý được tạo ra để bổ sung, sửa đổi, xoá bỏ hay
tìm kiếm sự vật dữ liệu.
Tổ #3
Mô hình
hoá
nghiệp vụ
Mô hình
dữ liệu
Mô hình
xử lý
Sinh ứng
dụng
Kiểm định
và quay
vòng
Tổ #1
Mô hình
hoá
nghiệp vụ
Mô hình
dữ liệu
Mô hình
xử lý
Sinh ứng
dụng
Kiểm định
và quay
vòng
Tổ #2
Mô hình

hoá
nghiệp vụ
Mô hình
dữ liệu
Mô hình
xử lý
Sinh ứng
dụng
Kiểm định
và quay
vòng
60 – 90 ngày
Hình 1.3. Mô hình RAD

- 4 -
- Sinh ứng dụng: RAD làm việc để dùng lại các cấu phần chương trình hiện có hay tạo
ra các cấu phần chương trình dùng lại được.
- Kiểm định và quay vòng.
d. Mô hình tiến trình phần mềm tiến hoá
Phần mềm, giống như mọi hệ thống phức tạp khác, tiến hoá theo từng thời kỳ
thời gian. Các yêu cầu nghiệp vụ và sản phẩm thường thay đổi khi sự phát triển tiến
hoá. Vì vậy, người phát triển phần mềm cần một mô hình tiến trình đã được thiết kế
tường minh để phù hợp với sản phẩm tiến hoá theo thời gian.
Các mô hình tiến hoá mang tính lặp. Chúng được đặc trưng theo cách thức tạo
khả năng cho người phát triển phần mềm phát triển các phiên bản ngày một hoàn thiện
và phù hợp với thời gian.
e. Mô hình tăng dần
Mô hình tăng dần là tổ hợp các yếu tố của mô hình tuần tự tuyến tính và bản
chất lặp của mô hình bản mẫu.
Mô hình tăng dần áp dụng các trình tự tuyến tính theo kiểu so le khi thời gian

lịch tiếp diễn. Mỗi trình tự tuyến tính lại tạo ra một “việc tăng” chuyển giao được của
phần mềm.








Kỹ nghệ hệ
thống/ thông tin
Chuyển
giao
tăng 4
Tăng 2
Chuyển giao
tăng 1
Hình 1.4. Mô hình tăng dần
Phân
tích
Thiết
kế
Lập trình
Kiểm định
Vận hành
Phân
tích
Thiết kế
Lập trình

Kiểm định
Vận hành
Phân
tích
Thiết kế
Lập trình
Kiểm định
Vận hành
Phân
tích
Thiết kế
Lập trình
Kiểm định
Vận hành
Chuyển giao
tăng 2
Chuyển giao
tăng 3
Tăng 3
Tăng 4

- 5 -
Sử dụng mô hình tăng dần: lần tăng đầu thường là sản phẩm lõi (các yêu cầu cơ
bản). Sản phẩm lõi được khách hàng dùng và đánh giá và lập bản kế hoạch cho lần
tăng tiếp theo. Tiếp tục sửa đổi sản phẩm lõi dựa vào bản kế hoạch và chuyển giao các
tính năng và chức năng phụ. Tiến trình được lặp lại với việc chuyển giao từng phần cho
đến khi sản phẩm hoàn chỉnh được tạo ra.
f. Mô hình xoáy ốc
Là mô hình tiến hoá cặp đôi bản chất lặp của mô hình bản mẫu với các khía
cạnh hệ thống của mô hình trình tự tuyến tính. Cung cấp tiềm năng cho việc phát triển

nhanh các phiên bản tăng dần của phần mềm. Trong mô hình xoáy ốc, phần mềm được
phát triển thành từng chuỗi các lần đưa ra tăng dần.
Mô hình xoáy ốc được chia thành sáu vùng nhiệm vụ sau đây:
- Trao đổi với khách hàng.
- Lập kế hoạch.
- Phân tích rủi ro.
- Chế tạo.
- Xây dựng và đưa ra.
- Đánh giá của khách hàng.
Khi tiến trình tiến hoá bắt đầu, tổ kỹ nghệ phần mềm đi vòng xoáy ốc bắt đầu từ
trung tâm. Mạch đầu tiên quanh xoáy ốc có thể làm phát sinh việc phát triển đặc tả sản
phẩm. Các bước tiếp theo quanh xoáy ốc được dùng để phát triển bản mẫu và phát triển
các phiên bản phức tạp dần thêm. Mỗi bước qua vùng lập kế hoạch lại làm nảy sinh
việc điều chỉnh kế hoạch dự án. Chi phí và lịch biểu được điều chỉnh dựa trên phản hồi
được suy ra từ đánh giá của khách hàng.
g. Mô hình phát triển tương tranh
Mô hình tiến trình tương tranh có thể được biểu diễn như một chuỗi các hoạt
động kỹ thuật chính, các nhiệm vụ và trạng thái liên kết của chúng.


- 6 -

Mô hình tiến trình tương tranh định nghĩa ra một loạt các biến cố làm nảy sinh
việc chuyển trạng thái nọ sang trạng thái kia của hoạt động kỹ nghệ phần mềm. Chẳng
hạn, trong các giai đoạn đầu của thiết kế, sự không nhất quán trong mô hình phân tích
được làm lộ ra. Điều này sinh ra biến cố sửa mô hình phân tích chuyển hoạt động phân
tích từ trạng thái đã làm sang trạng thái đợi thay đổi.
1.2. CHẤT LƢỢNG PHẦN MỀM
1.2.1. Chất lƣợng phần mềm là gì?
Chất lượng trong phần mềm máy tính hiện vẫn còn là một vấn đề còn nhiều
tranh luận. Trong một số trường hợp, nói tới chất lượng phần mềm là nói tới tính thực
tiễn và tính thẩm mỹ của phần mềm. Ở đây, khái niệm này trả lời cho câu hỏi một
chương trình máy tính thực thi một nhiệm vụ nào đó hiệu quả và có tính thẩm mỹ tới
mức nào. Trong một ngữ cảnh khác, chất lượng phần mềm được hiểu là sự đáp ứng đến
mức tối đa các yêu cầu đặt ra và không chứa lỗi. Trong cả hai trường hợp trên, có một
loạt các vấn đề đặt ra cần giải quyết để đi đến một kết quả cuối cùng là phần mềm có
chất lượng.
1.2.2. Lỗi phần mềm
Đã phát triển
Đợi thay đổi
Đã xét duyệt
Đã xét duyệt
Vạch ranh giới
Xong
Không
Hình 1.5.
Một phần tử của mô
hình tiến trình
tương tranh

- 7 -
Hiện nay, có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng tóm lại có

thể phát biểu một cách tổng quát như sau: “Lỗi phần mềm là sự không khớp nhau giữa
chương trình và đặc tả của nó”.
Như vậy, chúng ta có thể thấy lỗi phần mềm xuất hiện dưới ba hình thức sau:
- Sai: Sản phẩm được xây dựng khác với đặc tả.
- Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm.
- Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả.
Cũng có trường hợp yêu cầu 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 được coi là có lỗi.
Một hình thức khác cũng được coi là một dạng lỗi, đó là phần mềm khó hiểu,
khó sử dụng, chậm chễ hoặc dễ gây cảm nhận rằng phần mềm hoạt động không đúng.
Nguyên nhân xuất hiện lỗi phần mềm
Suy nghĩ chung của nhiều người lỗi phần mềm là do lập trình. Thực tế, lỗi xuất
hiện nhiều nhất không phải do lập trình. Nhiều nghiên cứu đã được thực hiện trên các
dự án từ rất nhỏ tới rất lớn đều cho kết quả giống nhau. Đó là số lỗi gây ra do đặc tả
chiếm phần lớn nhất, khoảng 80%. Trong nhiều trường hợp, đặc tả không được viết ra.
Các nguyên nhân khác có thể do đặc tả không đủ cẩn thận, hay thay đổi hoặc do chưa
có sự phối hợp tốt trong toàn nhóm phát triển. Sự thay đổi yêu cầu của khách hàng
cũng là một nguyên nhân dễ gây ra lỗi phần mềm. Khách hàng thường thay đổi yêu cầu
không mà cần quan tâm đến những tác động sau khi thay đổi yêu cầu như phải thiết kế
lại, lập lại kế hoạch, làm lại những việc đã hoàn thành. Nếu có nhiều sự thay đổi, rất
khó nhận biết hết được phần nào của dự án phụ thuộc và phần nào không phụ thuộc
vào sự thay đổi. Vì vậy, lỗi thường rất dễ phát sinh.
Ta xét một ví dụ nhỏ về sự không cẩn thận trong đặc tả của bài toán phân số:
- Với việc đặ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ố tự nhiên lớn hơn 0; t được gọi là tử số, m được gọi là mẫu số của phân số.

- 8 -
- Đặc tả hình thức là đặc tả trong đó sử dụng các ký hiệu toán học để mô tả. Một phân
số có thể được mô tả như sau:
+ Phân số = {(t,m) | t


Z, m

N
+
} (*)
Trong đó: N = {0, 1, 2, 3, 4, }
N
+
= {1, 2, 3, 4, }
Z = { ±1, ±2, ±3, ±4, }
+ 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 gdc là hàm tìm ước số chung lớn
nhất của hai số tự nhiên.
Như vậy, đặc tả phép chia trên mâu thuẫn với đặc tả phân số (*). Chẳng hạn, khi
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 đúng đặc tả.
Trên đâ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.
Nguồn gây lỗi lớn thứ hai sau đặc tả là thiết kế. Đây là cơ sở để lập trình viên
dựa vào để thực hiện lập trình. Những thiết kế không hiệu quả hoặc quá phức tạp sẽ
gây rất nhiều khó khăn cho việc lập trình và dẫn đến lỗi. Bản thân các thiết kế nhiều
khi cũng mang lỗi.
Tiếp theo là lỗi do lập trình. Ai cũng có thể mắc lỗi khi lập trình dù đó có là
người giỏi hay kinh nghiệm tới mức nào. Thời kỳ đầu của quá trình phát triển của
ngành phần mềm, công việc lập trình còn rất nặng nhọc, do vậy lỗi do lập trình là chủ

yếu. Ngày nay, 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, cộng
với sự hỗ trợ của nhiều công cụ lập trình cao cấp nên việc lập trình trở nên nhẹ nhàng
hơn dù độ phức tạp của 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.

- 9 -
Tuy vậy, các yếu tố khiến lập trình tạo ra lỗi lại nhiều hơn. Đó là độ phức tạp
của phần mềm, tài liệu nghèo nàn, do đặc tả, thiết kế không hợp lý, sức ép thời gian, bộ
biên dịch phần mềm có lỗi hoặc chỉ đơn giản là những lỗi “không rõ nguyên nhân”.
Chi phí cho việc sửa lỗi
Người ta ước tính, bảo trì là phần chi phí chính của phần mềm và kiểm định là
hoạt động có chi phí đắt thứ hai, ước tính khoảng 40% của 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 là phần chi phí chính 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 của người dùng.
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 sẽ tăng đáng kể theo thời
gian trong quá trình phát triển.
Sự thay đổi một tài liệu yêu cầu khi duyệt lại lần đầu tiên là không đắt nếu
không nói là không đáng kể. Chi phí sẽ tăng lên nhiều hơn nếu các yêu cầu thay đổi
được đưa ra sau khi đã lập trình. Thay đổi lúc này đồng nghĩa với việc phải viết lại
chương trình.
Việc sửa lỗi sẽ không đáng kể nếu người lập trình tự phát hiện lỗi của mình, và
không có sự liên quan đến chi phí khác. Họ không phải giải thích lỗi cho bất kỳ người
nào trong nhóm. 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 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.
Nói chung, 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.
Theo các nghiên cứu của IBM, GTE cho biết, 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. Chi phí tăng theo hàm mũ như sau:


- 10 -






Chúng ta từng chứng kiến sự cố máy tính Y2K năm 2000. Nguyên nhân là do
việc tiết kiệm bộ nhớ bằng cách biểu diễn năm có 4 chữ số bằng 2 chữ số cuối của năm
mà không dự tính được lỗi tiềm ẩn có thể xảy ra mà mấy chục năm sau, thế giới đã
phải lo sợ và tốn nhiều tỉ đô la để khắc phục do dữ liệu ngày tháng có thể bị thay đổi
khi máy tính coi năm 1900 như năm 2000.
1.2.3. Đánh giá chất lƣợng phần mềm
Chất lượng phần mềm có thể được đánh giá theo một số tiêu chí [6] sau:
 Tính dễ hiểu: Phần mềm có tính dễ hiểu phải có mục đích rõ ràng. Mục
đích ở đây không đơn thuần chỉ là mục tiêu phần mềm cần đạt được mà hơn thế nữa,
tất cả các thiết kế, các tài liệu hướng dẫn sử dụng phải được trình bày rõ ràng, dễ hiểu.
Một vấn đề đặt ra là cần trả lời câu hỏi rằng phần mềm được đặt trong ngữ cảnh người
dùng nào, chẳng hạn như phần mềm dành cho người dùng bình thường thì cần dễ hiểu
hơn phần mềm dành cho người sử dụng là các kỹ sư phần mềm.
Ví dụ, đối với người dùng, sản phẩm phải có những yếu tố sau:
- Dễ thao tác.
- Dễ học và dễ sử dụng.
- Giao diện phải rõ ràng, dễ hiểu, dễ nhớ.
 Tính hoàn chỉnh: Được đánh giá qua tập các chức năng của sản phẩm. Tập các
chức năng nên thoả mãn các tính chất sau:
Đặc tả Thiết kế Lập trình Kiểm định Phát hành

Chi phí để sửa lỗi
Hình 1.6.
Chi phí cho việc sửa lỗi.


- 11 -
- Tính đối xứng: Nếu có thao tác phát sinh thì cũng có thao tác huỷ bỏ và ngược lại.
- Tính tiêu chuẩn: Sản phẩm cần đạt một số tiêu chuẩn được thừa nhận trên thị
trường hoặc trong khoa học.
 Tính khúc chiết: Yêu cầu đặt ra là không có các thông tin dư thừa. Điều này
đặc biệt quan trọng khi bộ nhớ của hệ thống có giới hạn. Vì vậy, việc giảm các dòng
lệnh đến mức tối đa là cần thiết. Tính khúc chiết có thể được nâng lên nhờ việc dùng
chương trình con thay cho các chức năng được xử lí lặp đi lặp lại.
 Tính tƣơng thích: Phần mềm phải có khả năng hoạt động trơn tru, dễ dàng trên
nhiều nền tảng cấu hình máy tính khác nhau.
 Tính nhất quán: Tất cả các ký hiệu, biểu tượng hay thuật ngữ trong chương
trình phải thống nhất.
 Tính dễ bảo trì: Dễ dàng trong việc cập nhật để đáp ứng những yêu cầu mới.
Vì vậy, để có được đặc tính này, phần mềm phải có những tài liệu hỗ trợ kỹ thuật đầy
đủ chi tiết mà không phức tạp. Có thể thay đổi trong cấu trúc dữ liệu? Nếu một thiết kế
dựa trên chức năng được sửa lại thì có yêu cầu cấu trúc lại cả chương trình chính hay
chỉ một vài module.
 Tính khả kiểm: Phần mềm cho phép dễ dàng xây dựng các tiêu chuẩn và
trường hợp đánh giá hoạt động của nó. Đây là đặc tính gắn liền với giai đoạn thiết kế,
cho phép việc kiểm định có dễ dàng không. Một thiết kế quá phức tạp sẽ dẫn đến việc
rất khó khăn trong kiểm tra, đánh giá phần mềm.
 Tính tiện dụng: Điều này được thể hiện rất nhiều qua giao diện Người – Máy.
Thành tố có ảnh hưởng lớn nhất đến đặc tính này của phần mềm chính là giao diện đồ
họa người dùng (Graphical User Interface)
 Tính tin cậy: Phần mềm thực hiện được những chức năng, nhiệm vụ như

mong đợi. Yếu tố thời gian trong đặc tính này rất quan trọng, tức là phần mềm phải
thực thi tốt các yêu cầu đặt ra trong một giới hạn thời gian nhất định nào đó. Hơn nữa,

- 12 -
chương trình có tránh được các lỗi lặp vô hạn, kiểm tra lỗi dữ liệu đầu vào hay cung
cấp các điều khiển ngoại lệ khi xảy ra xung đột không?
Ngoài ra, sản phẩm có cơ chế bảo mật và bảo vệ các đối tượng do nó quản lý
hoặc phát sinh và bản thân sản phẩm cũng được đặt trong một cơ chế bảo mật nhằm
chống lại sự sao chép trộm hoặc làm biến dạng sản phẩm.
 Tính khoa học: được thể hiện qua các mặt sau:
- Cấu trúc: Sản phẩm được chia thành các đơn vị cân đối, không trùng lặp về mặt
chức năng, các chức năng quan hệ với nhau và tổ hợp để có thể tạo thành chức năng
mới.
- Nội dung: Các thuật toán dựa trên những thành tựu khoa học, có cơ sở và chặt chẽ
về tính khoa học.
- Hình thức và thao tác: Tên của các lệnh phải hợp lý, thể hiện tính logic và phù hợp
với tư duy tự nhiên của con người.
 Tính hiệu quả: Thể hiện qua các tiêu chuẩn sau:
- Hiệu quả kinh tế, giá trị thu được khi áp dụng sản phẩm.
- Tốc độ xử lý của sản phẩm được tính bằng tỉ lệ giữa số lượng đối tượng xử lý và
tổng số đơn vị thời gian cần thiết để xử lý đối tượng trên.
- Giới hạn tối đa của sản phẩm hoặc miền xác định của chương trình được xác
định thông qua đối tượng mà sản phẩm đó quản lý.
- Dung lượng tối đa của miền nhớ trong mà chương trình sử dụng.
Phần mềm thỏa mãn được mục đích đặt ra mà không làm lãng phí tài nguyên,
tức là tận dụng tối đa bộ nhớ và tốc độ của hệ thống.
1.3. KIỂM ĐỊNH PHẦN MỀM
1.3.1. Kiểm định phần mềm là gì?

- 13 -

Như đã trình bày ở phần trước. Một phần mềm dù lớn hay nhỏ đều có thể xuất
hiện những lỗi nếu không được kiểm tra và giám sát chặt chẽ các quy trình, có các biện
pháp sửa chữa khắc phục kịp thời tại các khâu đoạn.
Với các lỗi xảy ra với phầm mềm, để phát hiện ra được thì chúng ta phải tổ chức
kiểm định chúng. Do đó, 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, có nhiều bối cảnh kiểm định không bộc lộ ra lỗi. Như
vậy, có thể khái quát rằng: kiểm định phần mềm là quá trình thực thi một hệ thống
phần mềm để xác định xem phầm mềm đó có đúng với đặc tả hay không và thực
hiện trong môi trường như mong đợi hay không?[6]
Có rất nhiều phương pháp kiểm định phần mềm. Có những phương pháp tập
trung vào phân tích mã nguồn, như kỹ thuật kiểm định hộp trắng. Có những phương
pháp đi sâu vào các dữ liệu vào và kết quả đầu ra của chương trình như mong muốn,
điển hình là kỹ thuật kiểm định hộp đen.
Tuy nhiên trên thực tế, hệ thống đang thực hiện sẽ khác biệt so với việc duyệt
lại mã nguồn. Thông thường, người thực hiện sẽ thực hiện việc đọc lại và phân tích mã
nguồn, xem xét mã nguồn và tạo các lưu đồ của chương trình với các nhánh mà mã
nguồn có. Chương trình với mã nguồn đó sẽ phải thực hiện được hay nói cách khác nó
là một hệ thống chạy được, bởi hệ thống không chạy được thì việc kiểm định sẽ rất mất
thời gian và tiền bạc.
Ngoài việc phân tích mã nguồn của chương trình ra, người thực hiện sẽ căn cứ
vào các đặc tả , đặc tả chính là căn cứ chủ yếu cho việc kiểm định. Các phần đặc tả chỉ
quan tâm chủ yếu đến yếu tố vào ra chứ không tìm hiểu về cấu trúc và nội dung các
thao tác cần thực hiện. Mỗi chương trình được xem như một hộp đen – một bộ biến đổi
có cấu trúc thao tác bị che khuất. Các đặc tả sẽ xác định những hành vi đúng và làm
cho dễ dàng hơn trong việc xác định những hành vi không đúng. Mỗi hành vi không
đúng đó được hiểu chính là một lỗi phần mềm. Từ những lỗi phần mềm phát hiện đó,
người thực hiện sẽ căn cứ trên những hiểu biết của mình và mã nguồn của chương trình
để chẩn đoán nguyên nhân phát sinh lỗi, tìm ra các lỗi do lập trình hay mã nguồn xử lý