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

Bô GIÁO DUC VÀ ĐÀO TAO
• • • 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
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
HÀ NỘI,
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,
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 ttong 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. 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
ữọ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.
4. Đổi tượng và phạm vỉ 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 ”
5
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ể.
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:
6
(1) Các chương trình máy tỉnh mà khỉ đượ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”.
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 ừê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 ừê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
7
ữong 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
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++,
Prolog,
+ Nhóm 3: Các chương trình hệ thống, bao gồm
3.1Các chương trình điều khiển thiết bị ngoại vi
3.2Cá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.3Các chương trình đồ họa
3.4Cá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 tri 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.1Các chương trình xử lý dữ liệu đa năng
5.2Các bộ chương trình phục vụ cho các yêu cầu tính toán cơ sở
5.3Các chương trình tối ưu hóa
5.4Các hệ chuyên gia và các hệ tương tự
5.5Các hệ mô phỏng
5.6Cá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.7Các hệ tự động hóa quản lý chuyên ngành
8
5.8Các hệ tự động hóa thiết kế
5.9Cá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,
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.1Các chương trình soạn thảo văn bản
6.2Các chương trình xử lý bảng tính điện tử
6.3Các chương trình chuyển đổi ngôn ngữ, dịch chéo, khôi phục
6.4Các chương trình chống (và diệt) virus máy tính
6.5Các chương trình ừò 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 ừò 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
9
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)
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ư Fừefox 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.
1

Ư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 ữong 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 ừong 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ả ưong 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ó
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.
1

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 ữê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
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.

1
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 #10.” (Kaner, 2003; Somerville, 2011).
1.2Lỗ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 YÍ 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.
1
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ả nhung 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 ưong 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ứa đã được thực
hiện ừong 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 khỉ 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 đểỉ.
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
1
Hình 1.1 Các nguyên nhân gây ra lỗi phần mềm
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 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ế ừao đổ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à
1
Hình 1.1 Các nguyên nhân gây ra lỗi phần mềm
đượ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ữ ừong đặ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 ữong 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 ưm, ừong đó 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) 11 G z, m G z+} (*)
Trong đó:
1
Hình 1.1 Các nguyên nhân gây ra lỗi phần mềm
z={0, +1, +2, ±3, }
Z + = { 1 , 2 , 3, }
Phép chia hai phân số:
(tl,ml)/(t2,m2) = Reduce(tl X m2, t2 X ml), 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ố (l,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í ữong 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.
1
Hình 1.1 Các nguyên nhân gây ra lỗi phần mềm
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:

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ế
1
Hình 1.1 Các nguyên nhân gây ra lỗi phần mềm
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;
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 YÌ 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 YÔ cùng quan trọng
và đóng một vai ưò 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
1
Hình 1.1 Các nguyên nhân gây ra lỗi phần mềm
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.
2
Hình 1.1 Các nguyên nhân gây ra lỗi phần mềm
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ỉ yậ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.
2
Hình 1.3 Mô hình thác đổ đơn giản
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
2
Hình 1.3 Mô hình thác đổ đơn giản
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” ừong đó 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)
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
Hình 1.3 Mô hình thác đổ đơn giản
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 ữong 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
2
Hình 1.3 Mô hình thác đổ đơn giản
nhóm độc lập có ưách nhiệm tiến hành các họat động kiểm định, gọi là các
nhóm kiểm định.
Giai đoạn 3: Thiết kế các trường họp kiểm định.
Các trường họp kiểm định là các đặc tả đầu vào cho kiểm định và đàu ra
mong đợi của hệ thống cùng với các chức năng, câu lệnh cần kiểm định. Các
chuyên gia kiểm định đã đề xuất một vài phương pháp trợ giúp thiết kế trường
hợp kiểm định và các quy tắc kiểm định. Trước mắt ta phân biệt hai tiếp cận
kiểm định cơ bản:
- Các phương pháp hộp đen: kiểm định dựa trên chức năng hay kiểm
định vào/ra.
- Các phương pháp hộp trắng: kiểm định dựa vào cấu trúc bên ưong của
hệ thống.
Giai đoạn 4: Xử lý đo lường kiểm định.
Được thực hiện bằng cách thu thập dữ liệu. Chú ý rằng kiểm định viên
không thể trực tiếp cải tiến chương trình mà họ chỉ có thể đánh giá nó. Đánh
giá sản phẩm phần mềm nhằm để xác nhận sản phẩm có vượt qua được kiểm
định hoặc/và có thể sẵn sàng phát hành được chưa?
Mô hình chung của quy trình kiểm định phần mềm:
ì
Phân
tích
|=>
Thiết
kế
Mã

hóa
<=>
KIẺM
THỪ
Thiết kế
các
Chuẩn
bi dữ
Thưc thi So
sánh
trường
hợp
kiểm
định
liệu
kiêm
định
1=>
chương
trình với
dữ liệu
kiểm
kết quả
kiểm
định
Các
trường
hợp
kiềm
đinh^,

Dữ liệu
kiểm
định
Kết quả
kiểm
định
C'
Kết quả
kiềm
định
2
Hình 1.5 Quy trình kiểm định phần mềm