Tổ chức dữ liệu kiểm định phần mềm theo tiếp cận hộp đen

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




NGUYỄN TRỌNG TÂN





TỔ CHỨC DỮ LIỆU KIỂM ĐỊNH PHẦN MỀM
THEO TIẾP CẬN HỘP ĐEN




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






HÀ NỘI, 2014

LỜI CẢM ƠN

Để hoàn thành luận văn này tôi đã nhận được sự giúp đỡ tận tình của
thầy hướng dẫn khoa học, của các thầy cô trường Đại học Sư phạm Hà Nội 2.
Tôi xin chân thành cảm ơn các thầy cô trường Đại học Sư phạm Hà Nội 2 đã
tạo điều kiện học tập và giúp đỡ tôi rất nhiều trong quá trình làm luận văn.
Đặc biệt tôi xin cảm ơn PGS.TSKH Nguyn Xuân Huy đã tận tình hướng dẫn,
chỉ bảo tôi trong suốt quá trình học tập, thực hiện đề tài và giúp tôi hoàn thành
bản luận văn này.

Hà Nội, ngày 12 tháng 12 năm 2014

Học viên



Nguyn Trọng Tân



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




NGUYỄN TRỌNG TÂN

TỔ CHỨC DỮ LIỆU KIỂM ĐỊNH PHẦN MỀM
THEO TIẾP CẬN HỘP ĐEN


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: PGS.TSKH Nguyn Xuân Huy






HÀ NỘI, 2014


LỜI CAM ĐOAN

Tôi xin cam đoan đây là kết quả nghiên cứu của tôi dưới sự hướng dẫn
khoa học của PGS. TSKH Nguyn Xuân Huy.
Các số liệu và kết quả nghiên cứu trong luận văn này là trung thực và
không trùng lặp với các đề tài khác. Tôi cũng xin cam đoan rằng mọi sự giúp
đỡ cho việc thực hiện luận văn này đã được cảm ơn và các thông tin trích dẫn
trong luận văn đã được chỉ rõ nguồn gốc.

Hà Nội, ngày 12 tháng 12 Năm 2014

Học viên



Nguyn Trọng Tân













MỤC LỤC

MỞ ĐẦU 1
1. Lý do chọn đề tài 1
2. Mục đích nghiên cứu 1
3. Nhiệm vụ nghiên cứu 1
4. Đối tượng và phạm vi nghiên cứu 2
5. Phương pháp nghiên cứu 2
6. Giả thuyết khoa học 2
CHƯƠNG 1. TNG QUAN V SN PHM PHẦN MM 3
V CC KHI NIM CƠ SỞ 3

1.1 Sản phm phần mềm 3
1.1.1 Phần mềm máy tính và chương trình máy tính 3
1.1.2 Phân loại phần mềm máy tính 4
1.1.3 Các tiêu chí chất lượng của sản phm phần mềm 8
1.2 Li của sản phm phần mềm 10
1.2.1 Li của sản phm phần mềm là gì 10
1.2.2 Nguyên nhân gây ra li phần mềm 11
1.2.3 Những tác hại của li phần mềm 14
1.3 Kiểm đnh phần mềm 17
1.3.1 Khái niệm chung 17
1.3.2 Quy trình phát triển phần mềm 18
1.3.3 Quy trình kiểm đnh phần mềm 19
CHƯƠNG 2. KIỂM ĐỊNH HỘP ĐEN 23
2.1 Khái niệm chung 23
2.1.1 Kiểm đnh hộp đen 23
2.1.2 Quy trình kiểm đnh hộp đen 25
2.2 Một số kỹ thuật kiểm đnh hộp đen 26
2.2.1 Phân hoạch tương đương 26


2.2.2 Kỹ thuật phân tích giá tr biên 32
2.2.3 Kỹ thuật dùng bảng quyết đnh 36
CHƯƠNG 3. P DNG K THUT KIỂM ĐỊNH HỘP ĐEN 42
3.1 Mô tả yêu cầu bài toán 42
3.2 Giải pháp giải quyết bài toán 42
3.2.1 Đầu vào cho ứng dụng kiểm đnh 43
3.2.2 Kiểm đnh giao diện người s dụng (User Interface Testing) 47
3.2.3 Kiểm đnh luồng nghiệp vụ (Business Flow Testing) 49
3.3 Thực hiện kiểm đnh và kết quả đạt được 51
KẾT LUN 54

DANH MC CC TI LIU THAM KHO 55


1

MỞ ĐẦU

1. Lý do chọn đề tài
Do nhu cầu th trường, các hệ thống phần mềm đang ngày càng lớn hơn
và trở nên phức tạp hơn đòi hỏi hoạt động kiểm đnh phần mềm ngày càng
gánh trách niệm thêm nặng nề và chuyên nghiệp. Đảm bảo cho phần mềm d
dùng và không có li nhằm thỏa mãn và đáp ứng các yêu cầu ngày càng khắt
khe của người s dụng. Chính vì vậy kiểm đnh phần mềm là một phần quan
trọng không thể thiếu trong quy trình phát triển phần mềm.
Hiện nay, có hai phương pháp tiếp cận phổ biến đó là kiểm đnh hộp
trắng (kiểm đnh dựa vào cấu trúc bên trong của hệ thống) và kiểm đnh hộp
đen (kiểm đnh dựa trên chức năng hay kiểm đnh vào/ra). Trong đó kiểm
đnh hộp đen được nhiều nhà phát triển phần mềm lựa chọn bởi vì nó có một
số mặt thuận lợi nhất đnh. Kiểm đnh hộp đen có thể được thực hiện bởi ngay
cả những người không có nhiều kinh nghiệm kỹ thuật chuyên môn. Điều này
là do kiểm đnh hộp đen không cần biết trước cấu trúc nội tại hay mã nguồn
bên trong phần mềm.
2. Mục đích nghiên cứu
Tổng quan về sản phm phần mềm, vấn đề kiểm đnh phần mềm và các
cách tiếp cận trong kiểm đnh phần mềm. Đi sâu vào các phương pháp kiểm
đnh phần mềm theo tiếp cận hộp đen.
Xây dựng, tổ chức quy trình kiểm đnh phần mềm theo phương pháp
hộp đen cho chương trình cụ thể.
3. Nhiệm vụ nghiên cứu
Hệ thống hóa các phương pháp và quy trình kiểm đnh phần mềm.

Tổng quan về phương pháp kiểm đnh hộp đen, quy trình và một số kỹ
thuật của kiểm đnh hộp đen.
2

4. Đối tượng và phạm vi nghiên cứu
Đề tài “Tổ chức dữ liệu kiểm định phần mềm theo tiếp cận hộp đen”
tập trung hệ thống hóa một số vấn đề trong kiểm đnh phần mềm: Các phương
pháp và chiến lược trong quy trình kiểm đnh phần mềm.
Các phương pháp, quy trình và bản chất của kỹ thuật kiểm đnh hộp
đen.
5. Phương pháp nghiên cứu
Tổng hợp, phân tích và đánh giá các kết quả lý thuyết, các ứng dụng,
các nghiên cứu trong nước và thế giới về quy trình phát triển phần mềm. Từ
đó tập trung đi sâu vào các phương pháp kiểm đnh, đặc biệt là phương pháp
kiểm đnh hộp đen.
Tổ chức báo cáo, thảo luận đnh kỳ, trao đổi thường xuyên các thông
tin, kết quả trong quá trình nghiên cứu với giáo viên hướng dẫn cũng như
những người trong ngành có liên quan.
Xây dựng các bộ dữ liệu test và tổ chức thực nghiệm.
6. Giả thuyết khoa học
Khảo sát, phân tích và đề xuất các kỹ thuật kiểm đnh hộp đen, xây
dựng chương trình kiểm đnh. Thiết kế bộ test áp dụng cho chương trình cụ
thể.


3

CHƯƠNG 1. TỔNG QUAN VỀ SẢN PHM PHẦN MỀM
VÀ CÁC KHÁI NIỆM CƠ SỞ

1.1 Sản phm phn mềm
1.1.1 Phn mềm máy tính và chương trnh máy tính
Một hệ thống phần mềm được phát triển chuyên nghiệp thường bao
gồm nhiều phần mềm nhỏ chứ không phải chỉ là một phần mềm đơn nhất. Hệ
thống này thường bao gồm nhiều chương trình riêng biệt và các file dữ liệu
cấu hình được dùng để cài đặt các chương trình này. Các file có thể bao gồm
tài liệu hệ thống (mô tả cấu trúc hệ thống) và tài liệu hướng dẫn s dụng (giải
thích cách d dụng hệ thống) và trang web h trợ người dùng (mô tả các
thông tin chi tiết sản phm hiện hành).
Đnh nghĩa về phần mềm được nêu trong [9] như sau:
Phần mềm bao gồm:
(1) Các chương trình máy tính mà khi được thực hiện, nó mang lại
chức năng và hiệu quả mong muốn.
(2) Các cấu trúc dữ liệu mà theo đó chương trình có thể thao tác được
với các thông tin.
(3) Các tài liệu hướng dẫn cách hoạt động của chương trình và cách sử
dụng của chương trình.
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.
Ở đây ta cũng có thể đưa ra sự phân biệt giữa “sản phm phần mềm”
với “chương trình máy tính”.
4

Theo khoản 1 Điều 22 Luật SHTT 2005: "Chương trình máy tính là tập
hợp các chỉ dẫn được thể hiện dưới dạng các lệnh, các mã, lược đồ hoặc bất
kỳ dạng nào khác, khi gắn vào một phương tiện mà máy tính đọc được, có khả
năng làm cho máy tính thực hiện được một công việc hoặc đạt được một kết

quả cụ thể".
Có thể hiểu chương trình máy tính là chương trình được lập trình để
điều khiển hoạt động của máy điện t, là một chui thông tin chứa các lệnh
điều khiển máy tính thực hiện một hay nhiều nhiệm vụ nhất đnh. Chương
trình máy tính được xây dựng dưới dạng mã nguồn trên cơ sở một ngôn ngữ
lập trình nhất đnh và thường được lưu trữ dưới dạng mã máy. Trong thực tin
thường có sự nhầm lẫn giữa khái niệm chương trình máy tính và khái niệm
phần mềm máy tính. Tuy nhiên, xét dưới góc độ kỹ thuật và pháp lý thì đây là
hai khái niệm khác nhau.
Qua các đnh nghĩa trên, có thể thấy rằng khái niệm phần mềm máy
tính có nội hàm rộng hơn khái niệm "chương trình máy tính" vì tài liệu mô tả
chương trình, tài liệu h trợ, nội dung thông tin số hóa và chương trình máy
tính đều thuộc phần mềm máy tính. Chương trình máy tính là một bộ phận
nằm trong phần mềm máy tính nhưng thật ra không có sự phân đnh rõ ràng
giữa hai khái niệm này.
1.1.2 Phân loại phn mềm máy tính
Đối với các họ máy tính hoạt động theo nguyên lý Von Neumann hiện
nay ta có thể tạm chia các sản phm phần mềm thành 6 nhóm sau đây:
+ Nhóm 1: Các hệ điều hành, bao gồm
1.1 Các Driver (các chương trình điều khiển ổ đĩa)
1.2 Các Monitor
1.3 Các hệ quản lý tệp
1.4 Các hệ thống quản lý thư viện và chương trình dch
5

1.5 Các hệ thống quản lý mạng máy tính
+ Nhóm 2: Các chương trình dch và thông dch như Pascal, C, C++,
Prolog,…
+ Nhóm 3: Các chương trình hệ thống, bao gồm
3.1 Các chương trình điều khiển thiết b ngoại vi

3.2 Các chương trình mở rộng các chức năng quản lý tệp: sắp xếp, sao
chép, cập nhật, …
3.3 Các chương trình đồ họa
3.4 Các giao diện thân thiện giữa người s dụng và hệ điều hành
+ Nhóm 4: Các hệ quản tr cơ sở dữ liệu, tri thức và các chương trình mở rộng
tương ứng
+ Nhóm 5: Các chương trình ứng dụng có tính hệ thống
5.1 Các chương trình x lý dữ liệu đa năng
5.2 Các bộ chương trình phục vụ cho các yêu cầu tính toán cơ sở
5.3 Các chương trình tối ưu hóa
5.4 Các hệ chuyên gia và các hệ tương tự
5.5 Các hệ mô phỏng
5.6 Các lớp ngôn ngữ dữ liệu và tri thức phục vụ cho việc khai thác các
cơ sở dữ liệu tri thức
5.7 Các hệ tự động hóa quản lý chuyên ngành
5.8 Các hệ tự động hóa thiết kế
5.9 Các hệ thống dạy học
5.10 Các hệ thống tự học
5.11 Các hệ thống tự động phát sinh chương trình và kiểm, sa chương
trình
5.12 Các hệ chương trình nhận dạng, phân tích và tổng hợp tiếng nói,
hình ảnh, tín hiệu, …
6

5.13 Các hệ chương trình điều khiển quy trình và các thiết b công
nghiệp
+ Nhóm 6: Các chương trình tiện ích và trò chơi
6.1 Các chương trình soạn thảo văn bản
6.2 Các chương trình x lý bảng tính điện t
6.3 Các chương trình chuyển đổi ngôn ngữ, dch chéo, khôi phục

6.4 Các chương trình chống (và diệt) virus máy tính
6.5 Các chương trình trò chơi, giải trí
v.v
Ngoài ra ta có thể phân loại phần mềm dựa theo một số tiêu chí sau đây:
Dựa theo cơ s yêu cầu v mc đch s dng ta cũng có thể phân loại
phần mềm thành
+ Phần mềm đóng gói (phần mềm làm sn)
Có những phần mềm được thiết kế dựa trên những yêu cầu chung của
nhiều người, không theo yêu cầu đặt hàng của riêng ai. Chúng được viết rất
hoàn chỉnh và thường kèm theo những phương tiện để cài đặt lên máy một
cách tự động. Người s dụng chỉ cần mua về, cài đặt lên máy của mình, thiết
lập các chế độ làm việc phù hợp là có thể s dụng được. Những phần mềm
như thế gọi là phần mềm đóng gói. 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 soạn thảo văn bản như Winword, phần mềm tra
cứu Internet như Internet Explorer, FireFox, Chrome, phần mềm tra cứu kiến
thức, phần mềm thiết kế bản vẽ như Auto Cad, Revit, phần mềm nghe nhạc
hay xem phim trên đĩa CD như Windows Media Player, Jet audio đều là các
phần mềm đóng gói. 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.
+ Phần mềm theo yêu cầu (phần mềm đặt hàng)
7

Có những phần mềm ứng dụng được viết theo yêu cầu riêng có tính đặc
thù của một cá nhân hay tổ chức. Thí dụ 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 dùng để quản lý nhân sự,
quản lý các kho hàng hay phần mềm thiết kế một thí nghiệm, phần mềm điều
khiển một dây chuyền sản xuất. Hay phần mềm kiểm soát hệ thống giao
thông, tài chính ngân hàng. Thường thì 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.

Dựa trên mã nguồn ta có thể phân loại phần mềm thành phần mềm
nguồn m và phần mềm nguồn đóng
Phần mềm nguồn mở là phần mềm máy tính với mã nguồn của nó được
làm thành sn có cho bất kì ai dùng, thay đổi và phân phối. Tương phản lại,
Phần mềm nguồn đóng b hạn chế và người dùng phải trả tiền để truy nhập
vào mã nguồn để dùng nó. Phát triển phần mềm nguồn mở là phổ biến vì nó
cho phép người dùng tạo ra các ứng dụng mới, và các sản phm từ phần mềm
hiện có. Thí dụ các trình duyệt Internet như Firefox hay Chrome cũng được
xây dựng từ phần mềm nguồn mở.
Mục đích của phần mềm nguồn mở là làm cho nó thành sn có cho mọi
người để cho họ có thể phát triển nhiều thứ hữu dụng và có khả năng làm nó
thành đích xác điều họ muốn. Tương phản lại, phần mềm nguồn đóng có
những hạn chế về cách mã có thể được dùng hay thay đổi. Thí dụ PHP là phần
mềm nguồn mở. Bất kì ai muốn dùng PHP đều có thể lên php.net để thu được
việc truy nhập vào mã nguồn, hướng dẫn cách làm, và có thể bắt đầu phát
triển ngay cái gì đó. Nếu có gì giới hạn bạn khỏi việc làm điều bạn muốn thì
bạn có thể đổi mã nguồn để làm bất kì cái gì bạn muốn. Tất nhiên, chúng ta
không thể làm được điều đó với phần mềm nguồn đóng như Java vì không thể
đổi được mã nguồn.
8

Ưu điểm của nguồn mở là không phải trả tiền cho mã nguồn, có thể đổi
nó theo bất kì cách nào chúng ta muốn, cũng có cộng đồng lớn h trợ.
Phần mềm nhng
Ngoài ra cũng có một thuật ngữ mà ta có thể kể đến đó là phần mềm
nhúng. Phần mềm nhúng là phần mềm do nhà sản xuất thiết b cài sn vào sản
phm và chúng được s dụng ngay cùng với đồ điện t đó mà không cần có
sự cài đặt của người s dụng hay người thứ ba.
Ngày nay, các thiết b điện t dân dụng trở nên thông minh hơn nhờ
công nghệ vi x lý. Các phần mềm được cứng hóa trong các thiết b điều

khiển, thí dụ phần mềm gắn trong các thiết b di động như điện thoại, máy
tính bảng. Phần mềm điều khiển ca tự động, kiểm soát vào ra hay đơn giản
hơn trong các thiết b gia dụng hàng ngày được dùng trong gia đình như ti vi,
tủ lạnh, lò vi sóng đều s dụng các hệ vi x lý.
Các lĩnh vực có nhu cầu về "nhúng" cao nhất gồm: công nghiệp ôtô,
thiết b vin thông di động, điện t gia dụng, tự động hóa sản xuất, thiết b y
tế. Phần mềm nhúng chiếm một tỉ trọng rất lớn trong th trường phần mềm nói
chung.
1.1.3 Các tiêu chí chất lượng ca sản phm phn mềm
Các tiêu chí chất lượng của sản phm phần mềm có thể được kể đến:
Tiêu chí 1: 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ụ một hệ thống x lý dữ liệu không chạy được khi file cơ sở dữ
liệu rng.
Tiêu chí 2: 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 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ó
9

thể di chuyển, 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ụ trên ứng dụng bàn phím ảo cho các điện thoại thông minh, cho
phép người dùng có thể tùy chọn màu sắc, giao diện, kích thước phím gõ.
Hay có thể tùy chọn bố cục bàn phím (QWERTY, AZERTY, …) giúp người
dùng thuận tiện trong việc soạn thảo và phù hợp với ngôn ngữ, kiểu gõ của
từng vùng quốc gia.
Tiêu chí 3: 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.
Thí dụ trên các điện thoại di động thông minh hiện nay người dùng có
thể d dàng soạn thảo tin nhắn cũng như văn bản hơn thông qua việc máy có
thể học và nhớ những kí tự hay dùng và đưa ra gợi ý cho người s dụng.
Tiêu chí 4: 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.
Tiêu chí 5: 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.
Tiêu chí 6: Tính vững vàng
10

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 đnh dạng (format) bộ nhớ ngoại vi hoặc khởi động
(setup) lại hệ thống.
Tiêu chí 7: 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
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.
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).
1.2 Li ca sản phm phn mềm
1.2.1 Li ca sản phm phn mềm là g
Li phần mềm, có rất nhiều đnh nghĩa khác nhau về li phần mềm. Li
phần mềm có thể sinh ra do nhiều nguyên nhân ví dụ như yêu cầu phần mềm
b thiếu, yêu cầu không rõ ràng.
Nhưng 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).
Li phần mềm có thể chia theo mức độ nghiêm trọng: Sai, thiếu, thừa.
11

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 đặc tả.
1.2.2 Nguyên nhân gây ra li phn mềm
Li phần mềm có thể sinh ra do nhiều nguyên nhân ví dụ như yêu cầu
phần mềm b thiếu, yêu cầu không rõ ràng. Khác với sự cảm nhận thông
thường, 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 trong các dự án từ rất nhỏ đến các dự án rất lớn và kết quả luôn
giống nhau. Số li do đặc tả gây ra là nhiều nhất, chiếm khoảng 80%. Có một
số nguyên nhân làm cho đặc tả tạo ra nhiều li nhất. 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, nó hay thay đổi, hoặc do chưa 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à nguyên nhân d gây ra li phần mềm.
Khách hàng thay đổi yêu cầu không 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.

Hình 1.1 Các nguyên nhân gây ra li phần mềm
12

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. Ai cũng có thể mắc li khi lập
trình. Thời kì đầu, phát triển phần mềm có nghĩa là 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, cộng
với sự h trợ của nhiều công cụ lập trình cao cấp, 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, nguyên nhân để lập trình tạo ra li 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 tả:
Đặc tả một đối tượng nào đó là mô tả các đặc trưng của cả đối tượng
đó. Yêu cầu đầu tiên cũng là quan trọng nhất của đặc tả chính là tính chính
xác.
Đặc tả được xây dựng ở pha đầu tiên trong quy trình phát triển phần

mềm, đó là khi người thiết kế thu thập, xây dựng và đặc tả yêu cầu đặt ra cho
sản phm phần mềm đó.
Đây cũng là khâu khó nhất trong quy trình phát triển phần mềm, nó trả
lời cho câu hỏi khách hàng cần gì? Đôi khi khách hàng đưa ra yêu cầu nhưng
đó chưa phải là điều mà họ thực sự cần, hoặc điều đó là chưa hoàn toàn đầy
đủ đối với nhu cầu của họ và khách hàng không thể tự đặc tả được hết những
yêu cầu đó. Thí dụ: Khách hàng nói: "Tôi muốn hệ thống phải diệt hết virus
13

trong máy!". Tuy nhiên điều mà họ thực sự cần lại là: "Hệ thống phải ngăn
chặn được mọi sự xâm nhập của virus". Rõ ràng là ngăn chặn virus sẽ tốt hơn
là để virus thâm nhập hệ thống rồi mới tìm và diệt chúng.
Tại pha đầu tiên của quy 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):
14

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ố. 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.
1.2.3 Những tác hại ca li phn mềm
Khi một phần mềm có li, nó không đơn thuần chỉ gây ra sự bất tiện, gây

ra sai sót trong quá trình vận hành phần mềm mà nhiều khi nó còn gây ra thiệt
hại to lớn về kinh tế. Chi phí cho việc sa li phần mềm thường là rất lớn.
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
15

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. 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. Chi phí tăng theo hàm mũ như trong hình:
16

Hình 1.2 Chi phí sa li theo các pha
Ta có thể kể đến một số sự cố liên quan đến li phần mềm đã xảy ra
trước đây.
Thí dụ như sự cố Y2K (year two kilo) nghĩa là năm 2000. Sự cố Y2K
(sự cố năm 2000) là sự cố kỹ thuật trong các bộ nhớ máy tính. Trước thế kỉ
20, do bộ nhớ của máy tính hạn hẹp nên người ta đã viết tắt các năm. Ví dụ
như năm 1940 thì chỉ viết là "40", năm 1978 thì chỉ viết "78". Nhưng khoảng
năm 1997-1998, một số công ty phải lập kế hoạch cho những năm 2000 và họ
đã vấp phải hai số "00". Khi họ nhập năm 2000, máy tính không hiểu được
hai số "00" nên mọi dữ liệu có trùng số đó b tính toán nhầm lẫn, gây rối loạn
hết các dữ liệu. Toàn thế giới đã được báo động về nguy cơ này. Và theo ước
tính thế giới đã phải chi ra hàng nghìn tỷ USD để lập trình lại hệ thống, thay
thế các phần cứng cũ, cài đặt những phần mềm mềm mới s dụng cơ chế đọc
số năm theo dạng đầy đủ (4 chữ số).
Intel đã phải bỏ ra trên 400 triệu dollar để chi trả cho quá trình thay thế
các chip b li chia dấu phy động của bộ vi x lý Intel Pentium (Intel
Pentium Floating – Point Division Bug), 1994; Hay như những năm gần đây,
li bảo mật trên phần mềm đã khiến tin tặc đánh cắp thông tin người dùng và
gây ra những thiệt hại không nhỏ cho các công ty trên thế giới; …
17

Theo nghiên cứu của Watt Humphrey tại Đại học Carnegie Mellon, cho
rằng tỉ lệ mắc li đối với người phát triển phần mềm là 1/10. Điều này có
nghĩa là trong 10 dòng lệnh được viết ra thì thường có 1 li. Nhiều người phát
triển phần mềm tin rằng trình biên dch sẽ tìm ra mọi li. Tuy vậy có nhiều li
gõ vào mà trình biên dch lại không tìm ra. Thí dụ một li cú pháp trong C, gõ
“=“ thay cho “= =“ có thể tạo ra phép gán thay vì phép so sánh.
Mặc dù trình biên dch có thể tìm ra 90% li nhưng còn 10% kia thì
sao? Nhiều người tin rằng 10% kia có thể được thực hiện bằng kiểm đnh.

Tuy nhiên, nhiều chương trình sẽ chạy ngay cả khi chúng có li. Thực tế,
chúng có thể có nhiều li và vẫn qua được nhiều kiểm đnh. Ngay cả để tìm ra
số phần trăm li lớn trong một chương trình, chúng ta vẫn phải kiểm đnh gần
như tất cả các con đường và điều kiện logic. Và để tìm ra tất cả các li trong
ngay cả chương trình nhỏ, chúng ta sẽ phải cho chạy kiểm đnh vét cạn mà có
thể tốn kém và yêu cầu nhiều n lực.
Vì vậy kiểm đnh phần mềm đang ngày một trở nên vô cùng quan trọng
và đóng một vai trò không thể thiếu trong quy trình phát triển phần mềm.
1.3 Kim đnh phn mềm
1.3.1 Khái niệm chung
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 đó có hoạt động đáp ứng đúng
với các yêu cầu của đặc tả không và thể hiện hành vi đúng như kì vọng của
người s dụng hay không?
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,
tìm một cách sớm nhất và đảm bảo rằng li đã được sa, mà kiểm đnh phần
mềm không làm công việc chn đoán nguyên nhân gây ra li đã được phát
hiện và sa li.
18

Mục tiêu của kiểm đnh phần mềm là thiết kế tài liệu kiểm đnh một
cách có hệ thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được
thời gian, công sức và chi phí.
Kiểm đnh phần mềm không đơn thuần chỉ là việc duyệt lại mã nguồn
của chương trình viết cho hệ thống đó. Nhiều người nghĩ kiểm đnh phần
mềm sẽ là khâu cuối cùng trong quy trình phát triển phần mềm nhưng không
chỉ vậy mà nó là một quá trình xuyên suốt thậm chí ngay từ khi bắt đầu xây
dựng hệ thống phần mềm.
1.3.2 Quy trnh phát trin phn mềm
Vòng đời phần mềm

Được hiểu là thời kì tính từ khi phần mềm sinh (tạo) ra cho đến khi chết
đi (Từ lúc hình thành đáp ứng yêu cầu, vận hành, bảo dưỡng cho đến khi loại
bỏ không đâu dùng).
Một trong những quy trình được lấy làm nền tảng là quy trình Thác đổ
“Waterfall”. Tuy có nhiều quy trình phát triển phần mềm khác nhưng chúng
đều là phát triển của quy trình này theo thời gian.
c nh yêu u
(n m ?)
t 
(c n o?)
i t, m nh
(c n)
ch p
(m )
Khai c o 
(ng)

Hình 1.3 Mô hình thác đổ đơn giản
19

Mô hình thác đổ là quy trình phát triển phần mềm tuần tự nơi mọi hoạt
động phát triển đều phải tuân theo những pha nào đó như yêu cầu, thiết kế,
viết mã, kiểm đnh và bảo trì. Phải hoàn thành một pha trước khi chuyển sang
pha tiếp, cũng như nước chảy từ trên đỉnh xuống đáy trong một thác nước.
Theo mô hình thác đổ ta có thể tạm thời đơn giản hóa quy trình phát triển
phần mềm bao gồm các công việc sau đây:
1) Phân tích yêu cầu
2) Thiết kế sơ bộ
3) Thiết kế chi tiết
4) Lập trình và kiểm đnh đơn v

5) Tích hợp và kiểm đnh tích hợp
6) Kiểm đnh hệ thống
7) Khai thác và bảo trì hệ thống
1.3.3 Quy trnh kim đnh phn mềm
Mục đích của kiểm đnh là thiết kế một chui các trường hợp kiểm
đnh, gọi là các bộ test, có khả năng phát hiện li cao. Để cho việc kiểm đnh
đạt được kết quả tốt cần có sự chun b về kế hoạch kiểm đnh, thiết kế các
trường hợp kiểm đnh và các dữ liệu kiểm đnh cho từng trường hợp. Đây
chính là đầu vào cho giai đoạn kiểm đnh. Và sản phm (đầu ra) của giai đoạn
kiểm đnh chính là “báo cáo kiểm đnh” trong đó mô tả chi tiết kết quả của tất
cả các trường hợp kiểm đnh đã thực thi: mục đích kiểm đnh, dữ liệu vào, kết
quả dự kiến, kết quả thực tế, kết luận (đúng/sai)…

Hình 1.4 Kiểm đnh trong quy trình phát triển phần mềm
20

Cũng giống như phát triển phần mềm thì kiểm đnh phần mềm cũng có
vòng đời của nó. Có thểm tạm chia thành các giai đoạn sau đây.
Giai đoạn 1: Lập kế hoạch kiểm đnh.
Bước đầu tiên là lập kế hoạch cho tất cả các hoạt động kiểm đnh sẽ
được thực hiện và các phương pháp kiểm đnh sẽ s dụng. Bản kế hoạch bao
gồm cả thông tin về người lập kế hoạch, các thành viên tham gia kiểm đnh và
các bảng kiểm mục. Dưới đây là liệt kê một số nhận đnh về kiểm đnh phần
mềm của các chuyên gia công nghệ phần mềm (Sommerville, 2011):
1. 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 nhằm đảm bảo rằng phần mềm đáp ứng đầy
đủ các yêu cầu của bản thiết kế và các yêu cầu đó đáp ứng đúng những
gì mà người s dụng mong đợi;
2. Kiểm đnh phần mềm là quy trình bắt buộc trong các dự án phát triển
phần mềm;

3. Kiểm đnh phần mềm là một hoạt động tốn kém, mất thời gian, và
khó phát hiện được hết li;
4. 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à được quản lí chặt chẽ;
5. Mã hóa chương trình chỉ là giai đoạn cuối trong quy trình làm phần
mềm.
6. Làm phần mềm gồm nhiều pha với nhiều vòng lặp, mi pha, mi
vòng lặp đều có thể sinh li;
7. Li ở pha sớm là li nặng nhưng không khó sa;
8. Bắt li sớm sẽ d sa;
9. Li sinh li một cách liên hoàn.
Giai đoạn 2: Bố trí nhân viên kiểm đnh.
Việc kiểm đnh thường phải được tiến hành một cách độc lập. Mi