MỞ ĐẦU
1. Lý do chọn đề tài

Làm luận văn thạc sỹ đó là một cơ hội để học viên hệ thống lại những
kiến thức thu được trong quá trình học, muốn được tìm hiểu sâu hơn về một
số kỹ thuật kiểm định phần mềm, trong đó có hai kỹ thuật kiểm định cơ bản là
kỹ thuật kiểm định hộp đen (black box testing) và kỹ thuật kiểm định hộp
trắng (while box testing).
Ngày nay, tất cả các nước phát triển đều phụ thuộc chủ yếu vào các hệ
thống phần mềm. Và càng ngày càng có nhiều hệ thống được điều khiển bởi
phần mềm. Do đó, việc xây dựng, bảo trì và đặc biệt là kiểm định chất lượng
hệ thống phần mềm là yêu cầu cần thiết đối với nền kinh tế toàn cầu và của
mỗi quốc gia.
Hiện nay, lỗi của phần mềm cực kỳ nguy hiểm, gây ra những thiệt hại
không nhỏ về vật chất. Trong bối cảnh hầu hết những ngành kinh tế quan
trọng đều đang sử dụng rộng rãi các phần mềm. Chất lượng phần mềm là một
trong những mục tiêu chung mà mọi đối tượng liên quan trong việc sử dụng
(người dùng), quản lý và phát triển (người xây dựng, lập trình) đều đặt lên vị
trí hàng đầu khi đưa ra một vấn đề phát triển phần mềm. Chất lượng của phần
mềm không phải là một khái niệm mang tính chất mơ hồ, ước lượng; với sự
phát triển của ngành công nghệ thông tin trong vài thập kỷ, và kết quả nghiên
cứu để đạt đến sự hoàn thiện trong việc phát triển cũng gặt hái được nhiều kết
quả, đó chính là sự chuẩn hoá các tiêu chuẩn phát triển phần mềm như các
tiêu chuẩn ISO9000, ISO9001... ISO9004, SEI-CMM (Software Engineering
Instistute - Capability Maturily Model). Trong các mô hình phát triển dù với
quy mô bé hay lớn, đơn giản hay phức tạp... vấn đề kiểm định phần mềm luôn
được đặt lên hàng đầu, có tầm quan trọng không kém so với các vị trí phân
tích và phát triển, và được thực hiện song song, xuyên suốt quá trình phát
triển một hệ thống phần mềm.

Hiện nay, việc áp dụng các quy trình quản lý trong quá trình sản xuất
phần mềm được thực hiện hết sức chặt chẽ. Tuy nhiên, bên cạnh các vị trí
thiết kế và lập trình, thì vị trí quản lý, điều khiển, kiểm tra chất lượng và thực
hiện kiểm tra chất lượng phần mềm còn chưa được quan tâm đúng mức do nội
dung học tập chủ yếu tập trung vào việc tìm hiểu và xây dựng phần mềm,
riêng về nội dung kiểm định lại chỉ được giới thiệu sơ lược về chức năng
nhiệm vụ là chính, hầu hết các kỹ thuật kiểm định lại do chính từng cá nhân
tìm hiểu và tham khảo thêm khi làm việc.
Đề tài nhằm mục đích tìm hiểu về kỹ thuật kiểm định hộp trắng và khả
năng áp dụng trong việc kiểm định chất lượng phần mềm, giúp nâng cao hiệu
quả sử dụng phầm mềm trong sản xuất và góp phần nhỏ bé vào sự phát triển
của nền kinh tế đất nước.
2. Mục tiêu và nhiệm vụ nghiên cứu
-

Mục tiêu chính của luận văn là tập trung nghiên cứu, tìm hiểu, đánh giá
các nguyên lý, kế hoạch và kỹ thuật kiểm định phần mềm.

-

Thiết kế các trường hợp kiểm định áp dụng cho một số chương trình cụ
thể viết bằng ngôn ngữ lập trình C.

3. Đối tượng và phạm vi nghiên cứu
 Qui trình và bản chất của các kỹ thuật kiểm định hộp đen và kiểm định

hộp trắng.
 Kế hoạch kiểm định phần mềm.
 Đặc tả việc thiết kế kiểm định, xây dựng chương trình kiểm định


4. Phương pháp nghiên cứu


-

Nghiên cứu, tìm hiểu các kỹ thuật, kế hoạch kiểm định phần mềm.

-

Sử dụng các phương pháp kiểm định theo kỹ thuật hộp trắng đã nghiên
cứu, thiết kế bộ kiểm định cho chương trình cụ thể, xây dựng chương
trình kiểm định.

5. Dự kiến kết quả
-

Thiết kế bộ kiểm tra sử dụng kỹ thuật hộp trắng cho chương trình cụ
thể viết bằng ngôn ngữ lập trình C.

-

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.)

6. Ý nghĩa khoa học và thực tiễn của Luận văn

Kết quả nghiên cứu có thể góp phần làm tài liệu tham khảo cho các đối
tượng là sinh viên, các nhà khoa học nghiên cứu về kiểm định, các công ty
sản xuất phần mềm và dần tiến tới việc đưa qui trình kiểm định phần mềm
thành một qui trình bắt buộc trong các dự án phát triển phần mềm.

7. Tên đề tài

“Kiểm định chương trình ngôn ngữ C bằng kỹ thuật hộp trắng.”
8. Bố cục của Luận văn

Toàn bộ nội dung của Luận văn được chia thành 4 chương như sau:
Chương 1: Vị trí và vai trò của kiểm định phần mềm.
Chương 2: Một số kỹ thuật kiểm định phần mềm
Chương 3: Chiến lược kiểm định phần mềm
Chương 4: Áp dụng kỹ thuật kiểm tra hộp trắng


CHƯƠNG 1

VỊ TRÍ VÀ VAI TRÒ CỦA KIỂM ĐỊNH PHẦN MỀM
1.1. Quy trình phát triển và kiểm định phần mềm
1.1.1. Quy trình phát triển phần mềm

Phần mềm là một (hệ thống) bao gồm nhiều chương trình con đượ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 phục vụ
cho một ứng dụng cụ thể chạy trên máy tính áp dụng thực hiện trong các họat
động kinh tế, quốc phòng, văn hóa, giáo dục và giải trí,…
Trong kỹ nghệ phát triển phần mềm, tạo được một phần mềm có ứng
dụng rộng rãi, để phục vụ xã hội và có thể thu được lợi nhuận là mục tiêu
hàng đầu của các doanh nghiệp phần mềm. Tuy nhiên, khi phát triển dự án
công nghệ thông tin, người quản lý dự án phải đặt ra mục tiêu là: “làm sao để
có thể hoàn thành dự án đúng thời hạn, đáp ứng đúng yêu cầu đặt ra của
người sử dụng và quan trọng nhất là không vượt quá phần kinh phí dành
để phát triển dụ án này.”
Mục tiêu trên từ lâu đã trở thành một đề tài nóng bỏng trong kỹ nghệ

phần mềm, và cho đến bây giờ vẫn còn là một câu hỏi lớn đặt ra cho các nhà
quản lý dự án phần mềm. Khó mà biết được một dự án sẽ thành công hay thất
bại? Đó thực sự là một bài toán không đáp số. Không có gì đảm bảo được sự
thành công của công trình được tiến hành. Vậy có thể có giải pháp nào giúp
chúng ta tránh được những yếu tố có thể dẫn đến sự thất bại trong việc phát
triển các dự án không? Đi tìm đáp số cho câu hỏi này đã dẫn đến việc ra đời
của khái niệm về chu kỳ phát triển dự án đặc biệt trong kỹ nghệ phần mềm và
cách quản lý các giai đoạn phát triển trong chu kỳ này. Một mô hình phát triển
phần mềm thường trải qua các giai đoạn sau.


Giai đoạn quy hoạch
Trong giai đoạn này dự án được nghiên cứu và học hỏi qua việc thu
thập thông tin (phỏng vấn người sử dụng hoặc nhân viên bảo quản các
chương trình, nghiên cứu tài liệu và quan sát hiện trường) để thu thập yêu cầu
đặt ra cho chương trình. Điều quan trọng cần rút ra khi giai đoạn này kết thúc
đó là:
-

Tính khả thi của công trình gồm: Khả thi về mặt kỹ thuật , tác vụ và
kinh tế. Liệu công trình có thể thực hiện được không và có phải giải
pháp kỹ thuật là giải pháp duy nhất cho công trình này hay không?

-

Một hồ sơ hoạch định yêu cầu và phạm vi của công trình.

Giai đoạn xác định
Khi hoàn thành giai đoạn này phải có: một hồ sơ nêu rõ ràng công trình
sẽ làm những gì, khi nào làm, làm cho ai và sẽ làm như thế nào. Sự bổ nhiệm

của các giám đốc dự án, chuyên gia kỹ thuật bao gồm kiến trúc, thiết kế phần
mềm, cơ sở dữ liệu và vai trò cũng như trách nhiệm của họ trong sự phát triển
của dự án. Đối tượng tham gia ở giai đoạn này gồm: những người chịu trách
nhiệm triển khai dự án (phía khách hàng), nhóm quản lý dự án (phía công ty
phát triển), nhân viên nghiệp vụ (người sử dụng), chuyên viên tin học (người
khảo sát)
Giai đoạn phân tích
Việc hiểu biết đầy đủ về các yêu cầu của phần mềm là điều chủ chốt
cho sự thành công của nỗ lực phát triển phần mềm. Nhiệm vụ của người phân
tích là một tiến trình khám phá làm mịn, mô hình hoá và đặc tả. Giai đoạn này
có sự tham gia của cả người phát triển và khách hàng (người sử dụng). Kết
quả của giai đoạn này là một danh sách chi tiết các yêu cầu của người sử
dụng. Đồng thời liệt kê chi tiết những dữ liệu liên quan trong các chương
trình.


Giai đoạn thiết kế
Trong khi giai đoạn phân tích dùng để trả lời cho các câu hỏi dự án sẽ
làm gì, khi nào làm, và làm cho ai thì giai đoạn thiết kế dùng để chỉ ra phương
hướng và cách phát triển của dự án. Giai đoạn này sẽ nêu ra những đòi hỏi kỹ
thuật về thiết kế và những công cụ để xây dựng phần mềm chẳng hạn như.
Net, C#, C++, Windows hay Unix cho hệ điều hành, Oracle hay MS SQL
Server cho cơ sở dữ liệu. Giai đoạn này rất quan trọng vì nó có ảnh hưởng
đến những giai đoạn sau như xây dựng (lập trình) và cài đặt phần mềm. Đối
tượng tham gia giai đoạn này: nhóm quản lý dự án, chuyên viên tin học.
Giai đoạn xây dựng
Giai đoạn này là lúc các kỹ sư thiết kế và lập trình viên dựa trên các
bản thảo từ giai đoạn thiết kế cùng nhau thảo các chương trình phần mềm cần
thiết cho sự hoàn thành của dự án qua đó thoả mãn yêu cầu của người sử
dụng. Ngoài ra cũng sẽ có sự tham gia của các chuyên viên kiểm tra và duyệt

xét (Quality Assurance) phần mềm trong giai đoạn này nhằm đảm bảo chất
lượng của sản phẩm phần mềm.
Giai đoạn kiểm định
Tiến trình kiểm định bao gồm việc
+ Phát hiện và sửa lỗi phần logic bên trong chương trình hay còn gọi là
lỗi lập trình.
+ Kiểm tra xem phần mềm có hoạt động như mong muốn không, tức là
phát hiện và sửa lỗi về chức năng như thiếu hụt, sai sót về chức năng; và kiểm
tra xem phần mềm có đảm bảo tính hiệu quả trong thực hiện hay không.
Giai đoạn bảo trì
Bao gồm các công việc sửa các lỗi phát sinh khi áp dụng chương trình
hoặc thích ứng nó với thay đổi trong môi trường bên ngoài (hệ điều hành mới,
thiết bị ngoại vi mới, yêu cầu người dùng) hoặc yêu cầu bổ sung chức năng
hay nâng cao hiệu năng cần có.


Giai đoạn cài đặt
Đây là giai đoạn cuối cùng trong chu kỳ phát triển dự án phần mềm. Giai
đoạn này đỏi hỏi các quy hoạch trong việc chuyển giao sản phẩm tới người sử
dụng và việc cài đặt các sản phẩm này trong môi trường làm việc của người sử
dụng. Trong giai đoạn này hệ thống được sử dụng chính thức. Người sử dụng
có nhiệm vụ ghi nhận và phản ánh tất cả những vấn đề khó khăn trở ngại trong
quá trình sử dụng phần mềm tới nhóm quản lý dự án để khắc phục kịp thời và
sẽ cho biết quyết định chấp nhận hay từ chối sản phẩm làm ra qua các khâu
kiểm tra và duyệt xét xem chương trình có thoả mãn các đòi hỏi theo các hồ sơ
lập ra từ các giai đoạn xác định và phân tích. Đối tượng tham gia giai đoạn
này: Nhóm quản lý dự án, người sử dụng, chuyên viên tin học.

Xác định


Hình 1.1: Quy trình phát triển phần mềm


1.1.2. Lỗi phần mềm

Có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng nhìn chung như
sau: “Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó.”
Dựa vào định nghĩa, chúng ta có thể thấy lỗi phần mềm xuất hiện theo ba
dạng chính như 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 được xây dựng.
 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 này có thể là một thuộc tính sẽ được
người dùng chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi.
Lỗi có thể xảy ra trong tất cả các công đoạn từ “Mô tả yêu cầu”, “Thiết
kế” đến “Lập trình”.
Từ công đoạn này chuyển sang công đoạn khác thường nảy sinh các sai
sót (do dư thừa hoặc thiếu theo mô tả yêu cầu).
Đến công đoạn kiểm định chúng ta sẽ phát hiện ra các hậu quả (các kết
quả không mong muốn).
Quá trình sửa lỗi bao gồm “phân loại lỗi”, “cô lập lỗi” (tìm ra nguyên
nhân và nơi gây lỗi), đề ra “giải pháp sửa lỗi” và cuối cùng là khắc phục lỗi.


1.1.3. Tại sao phần mềm có lỗi

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. Nếu không giữ được vết thay
đổi rất dễ phát sinh ra lỗi.
Ví dụ: Trong đặc tả bài toán phân số:
1. 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ố.
2. Đặ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 đặc tả như sau:
+ Phân số = {(t,m) | t Z, m N+}

Trong đó: N = {0, 1, 2, 3, …}
N+ = {1, 2, 3, …}
Z = {0, 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 số chung lớn nhất của hai số tự nhiên.
Đặc tả phép chia như trên là sai với đặc tả phân số (*). Chẳng hạn, 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ả.
Đâ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 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. Dó 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,…
1.1.4. Chi phí cho việc sửa lỗi

Bảo trì phần mềm thường là phần chi phí chính 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 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.
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 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.
Việc sửa lỗi sẽ không còn đáng kể nếu người lập trình tự phát hiện lỗi
của mình. 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. 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.
Trong tài liệu Boehm [2], có trích dẫn kết quả nghiên cứu của IBM, GTE
và TRW, tổng kết rằng 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ư hình sau.


1.1.5. Kiểm định phần mềm.

Theo Glen Myers: Kiểm định là quá trình vận hành chương trình để tìm
ra lỗi.
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. 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ần mềm đó có đúng với đặc tả không và thực hiện trong môi trường như
mong đợi hay không.
Trên thực tế, hệ thống đang thực hiện khác biệt với việc duyệt lại mã

nguồn. Thông thường, người phát triển thực hiện việc đọc lại và phân tích mã
nguồn. Nói cách khác, kiểm định đòi hỏi một hệ thống chạy được. Đặc tả là
căn cứ chủ yếu hỗ trợ cho việc kiểm định. Nó 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 chính là một lỗi phần mềm. Nói chung, người phát triển
phải tự chẩn đoán nguyên nhân sinh lỗi trong mã nguồn.
Mục đích của kiểm định phần mềm là tìm ra lỗi chưa được phát hiện, tìm
một cách sớm nhất có thể 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. 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í.
1.2. 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
mà 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 các trường hợp. Đây chính là đầu vào cho giai
đoạn kiểm định. Và sản phẩm công việc của giai đoạn kiểm định chính là


“báo cáo kiểm định” mà tài liệu hóa tất cả các trường hợp kiểm định dã chạy,
dữ liệu đầu vào, đầu ra mong đợi, đầu ra thực tế và mục đích của kiểm định,
… (như Hình 1.3)

Hình 1.3: Kiểm định trong xử lý phần mềm
Qui trình kiểm định bao gồm một số 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 sẽ được thực hiện và các phương pháp được sử dụng. Các chuẩn

IEEE 1012-1986 bao gồm các thông tin về tác giả chuẩn bị kế hoạch, danh
sách liệt kê của kế hoạch kiểm định.
Mục đích: Qui định về phạm vi, phương pháp, tài nguyên và lịch biểu
của các hoạt động kiểm định.
2. Giai đoạn bố trí nhân viên kiểm định. Việc kiểm định thường phải tiến
hành một cách độc lập và các nhóm độc lập có trá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.
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
câu lệnh được kiểm định. Có một vài phương pháp thiết kế trường hợp kiểm
định và các qui tắc từ các nhà thiết kế kiểm định có kinh nghiệm. Tuy nhiên,
có hai chiến lược kiểm định cơ bản đó là:
+ Các phương pháp hộp đen để kiểm định dựa trên chức năng.
+ Các phương pháp hộp trắng để kiểm định dựa vào cấu trúc bên trong.


4. Xử lý đo lường kiểm định bằng cách thu thập dữ liệu. Ở đây, người
kiểm định 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 để xác nhận sản phẩm có thể sẵn sàng phát
hành được chưa? Mô hình của qui trình kiểm định phần mềm được thể hiện
trong hình 1.4.

Hình 1.4 – Qui trình kiểm định phần mềm
1.3. Lợi ích kinh tế của kiểm định phần mềm

Trong phát triển phần mềm, có nhiều chi phí tương ứng với sự kiểm định
các chương trình của chúng ta. Chúng ta cần lập kế hoạch cho các ca kiểm
định, cần viết các ca kiểm định, cần thiết lập các thiết bị thích hợp, cần thực
hiện các ca kiểm định một cách có hệ thống, tiếp tục các vấn đề đã xác định,
cần loại bỏ hầu hết các sai sót tìm được (thực tế, đôi khi chúng ta có thể tìm

thấy các sai sót có mức ưu tiên thấp trong mã nguồn và quyết định việc sửa
sai sót là quá đắt vì cần phải thiết kế lại, lập trình lại... Những sai sót này có
thể tồn tại trong sản phẩm sau khi phát hành). Khi chúng ta không tìm ra và
việc loại bỏ trước các sai sót thì tốn nhiều chi phí ứng với việc chuyển các sai
sót phần mềm tới khách hàng. Khi điều này xảy ra, khách hàng có thể mất
lòng tin vào công ty chúng ta và có thể rất tức giận. Họ cũng có thể mất rất
nhiều tiền nếu hệ thống của họ hỏng vì những sai sót của chúng ta. Và, các tổ
chức phát triển phần mềm phải sử dụng một lượng rất lớn tiền của để thu


được các thông tin cụ thể về những vấn đề của khách hàng và để tìm, sửa các
lỗi đó. Chúng ta cũng cần cân nhắc tiềm năng bị mất của mỗi dự án. Chất
lượng quan trong hơn nhiều đối với phần mềm rất cần sự an toàn như phần
mềm hàng không. Vì vậy, khi chúng ta cân bằng chi phí kiểm định so sánh
với chi phí lỗi phần mềm, chúng ta sẽ kiểm định phần mềm hàng không
chứ không kiểm định phần mềm trò chơi. Thực tế là các phần mềm cần ưu
tiên sự an toàn có thể sử dụng gấp 3-5 lần số kiểm định so với các phần
mềm khác. Để tối thiểu hóa chí phí kiểm định và chi phí lỗi phần mềm,
phải đề ra mục đích kiểm định là phát hiện càng nhiều sai sót với càng ít
kiểm định càng tốt. Kiểm định mọi tổ hợp đầu vào-đầu ra của hệ thống là
điều không thể; có quá nhiều hoán vị và tổ hợp. Là kiể m định viên, cần cân
nhắc lợi ích kinh tế của việc kiểm định và cố gắng viết các ca kiểm định mà
sẽ phát hiện ra càng nhiều sai sót trong phần mềm càng ít ca kiểm định
càng tốt.


CHƯƠNG 2

CÁC KỸ THUẬT KIỂM ĐỊNH PHẦN MỀM
Có thể chia các kỹ thuật kiểm định phần mềm thành hai loại: các kỹ

thuật kiểm định hộp đen (black-box testing) và kỹ thuật kiểm định hộp trắng
(white-box testing). Các kỹ thuật kiểm định hộp đen nhận được các kiểm định
từ đặc tả thiết kế chức năng không cần quan tâm cấu trúc chương trình bên
trong. Người kiểm định đưa ra các đầu vào cho thành phần hoặc hệ thống và
xem xét đầu ra tương ứng. Nếu các đầu ra thực tế phù hợp với các đầu ra
mong muốn thì kiểm định xác nhận rằng chức năng được kiểm định như
mong muốn. Nếu các đầu ra là không đúng các dự đoán của chúng thì kiểm
định đã thành công trong việc phát hiện được lỗi phần mềm. Kiểm định sử
dụng kỹ thuật hộp đen thường tìm ra các lỗi như thiếu các chức năng, khả
năng sử dụng và các yêu cầu phi chức năng.
Các kỹ thuật kiểm định hộp trắng (white-box) yêu cầu hiểu biết về cấu
trúc chương trình bên trong và các kiểm định nhận được từ đặc tả thiết kế bên
trong hoặc từ mã. Kỹ thuật kiểm định hộp trắng phát hiện những phần nào của
mã sẽ được thực hiện trong khi kiểm định. Thực hiện kiểm định hộp trắng có
thể làm sáng tỏ các lỗi tìm thấy trong kiểm định hộp đen bởi vì chúng xem xét
phần mềm thông qua việc nghiên cứu cấu trúc của nó.
2.1. Nguyên tắc cơ bản kiểm định phần mềm

Trong lúc kiểm định, công nghệ phần mềm phát sinh một chuỗi các
trường hợp kiểm định được sử dụng để “tách từng phần” phần mềm. Kiểm
định là một bước trong qui trình phần mềm mà có thể được xem xét bởi đội
ngũ phát triển bằng cách phá vỡ thay vì xây dựng. Các kỹ sư phần mềm chính
là những người xây dựng và việc kiểm định yêu cầu họ vượt qua các khái
niệm cho trước về độ chính xác và giải quyết mâu thuẫn khi các lỗi được xác
định.


2.1.1. Mục tiêu kiểm định

Các nguyên tắc được xem như mục tiêu kiểm định là:

- Kiểm định là một quá trình thực thi chương trình với mục đích tìm
lỗi.
- Một trường hợp kiểm định tốt là trường hợp kiểm định mà có khả
năng cao việc tìm thấy các lỗi chưa từng được phát hiện.
- Một kiểm định thành công là kiểm định mà phát hiện lỗi chưa từng
được phát hiện.
2.1.2. Kiểm định luồng thông tin

Luồng thông tin cho kiểm định được biểu diễn bởi mô hình trong hình 2.1.
Hai kiểu của đầu vào được truyền cho quá trình kiểm định:
- Cấu hình phần mềm: gồm các đặc tả yêu cầu, đặc tả thiết kế, và mã
nguồn.
- Cấu hình kiểm định: gồm có kế hoạch kiểm định, các thủ tục, trường
hợp kiểm định, và các công cụ kiểm định.
Hình 2.1: Luồng thông tin kiểm định

Kiểm định được thực hiện và tất cả các kết quả được xem xét, kết quả
kiểm định được so sánh với kết quả mong đợi. Khi dữ liệu không đúng được
nhận biết, lỗi được bao hàm và việc gỡ rối bắt đầu. Thủ tục gỡ rối là thành
phần khó dự đoán nhất của thủ tục kiểm định. Một “lỗi” với sự khác nhau
0.01% giữa các kết quả ra thực tế và kết quả mong đợi có thế mất hàng giờ,
ngày, tháng để nhận biết và hiệu chỉnh. Sự không chắc trong gỡ rối mà kiểm
định gây nên sẽ là khó lập lịch biểu độ tin cậy.
2.1.3. Thiết kế trường hợp kiểm định

Thiết kế kiểm định phần mềm có thể là một quá trình thu thập, phân tích
và thực hiện yêu cầu. Tuy nhiên, các kỹ sư phần mềm thường xem kiểm định


như một giai đoạn cuối cùng, sau giai đoạn lập trình. Các trường hợp kiểm

định được hoạch định có thể tạo ra cảm giác đúng nhưng ít được đảm bảo là
chúng sẽ hoàn thành. Mục tiêu của kiểm định là phải thiết kế các trường hợp
kiểm định có khả năng cao nhất trong việc phát hiện nhiều lỗi nhất với thời
gian và công sức tối thiểu. Một số lượng lớn các phương pháp thiết kế trường
hợp kiểm định đã được phát triển, cung cấp cho đội ngũ phát triển cách tiếp
cận có hệ thống cho việc kiểm định. Các phương pháp thường cung cấp một
cách tiếp cận đảm bảo tính đầy đủ của kiểm định và cung cấp khả năng cao
nhất để phát hiện các lỗi của phần mềm.
Như vậy, vấn đề quan trọng nhất trong kiểm định phần mềm là thiết kế
và tạo ra các trường hợp kiểm định có hiệu quả. Lý do về tầm quan trọng của
việc thiết kế các trường hợp kiểm định xuất phát từ thực tế: Kiểm định “vét
cạn” là điều không thể, và như vậy, kiểm định một chương trình phải luôn xác
định là không thể vét cạn (tức kiểm định không thể đảm bảo rằng chương
trình không còn lỗi nào). Vấn đề quan trọng là cố gắng làm giảm lỗi chương
trình nhiều nhất có thể.
Kiểm định phần mềm còn có các ràng buộc về thời gian, chi phí, … Chìa
khoá của kiểm định là trả lời của câu hỏi: “Tập con của tất cả các trường hợp
kiểm định có thể có xác suất phát hiện lỗi cao nhất là gì?”. Việc nghiên cứu
các phương pháp thiết kế trường hợp kiểm định sẽ cung cấp câu trả lời cho
câu hỏi này.
Bất kỳ sản phẩm công nghệ nào có thể được kiểm định trong hai cách:
1/ Biết về các chức năng cụ thể mà sản phẩm đã được thiết kế để thực
hiện, các kiểm định có thể được thực hiện để chứng tỏ mỗi chức năng được
thực hiện đầy đủ, tại một thời điểm nào đó tìm kiếm các lỗi trong mỗi chức
năng;


2/ Biết cách hoạt động bên trong của sản phẩm, kiểm định có thể được
thực hiện để đảm bảo rằng “tất cả các thành phần ăn khớp nhau”, tức là, hoạt
động bên trong thực hiện theo đặc tả và tất cả các thành phần bên trong đã

được thực hiện một cách thoả đáng.
Cách tiếp cận kiểm định đầu tiên được gọi là kiểm định hộp đen và cách
thứ hai là kiểm định hộp trắng.
2.2. Kỹ thuật kiểm định hộp đen (Black-Box Testing)
Khi phần mềm máy tính được xem xét, kiểm định hộp đen ám chỉ các
kiểm định mà được thực hiện trên giao diện phần mềm. Mặc dù chúng được
thiết kế để phát hiện các lỗi, các kiểm định hộp đen được sử dụng để chứng tỏ
các chức năng phần mềm là hoạt động; rằng đầu vào được chấp nhận một
cách hợp lý và đầu ra được sinh ra phù hợp; và duy trì tính toàn vẹn của thông
tin bên ngoài (chẳng hạn, các tập tin dữ liệu). Kiểm định hộp đen xem xét một
vài khía cạnh cơ bản của hệ thống với sự quan sát cấu trúc logic bên trong của
phần mềm.
Kỹ thuật kiểm định hộp đen còn được gọi là kiểm định hướng dữ liệu
(data-driven) hay là kiểm định hướng vào/ra (input/output driven).

Trong kỹ thuật này, người kiểm định xem phần mềm như là một hộp
đen. Người kiểm định hoàn toàn không quan tâm cấu trúc và hành vi bên
trong của phần mềm (không thể nhìn thấy những gì bên trong hộp đen).
Người kiểm định chỉ cần quan tâm đến việc tìm các hiện tượng mà phần mềm


không hành xử theo đúng đặc tả của nó (người kiểm định chỉ biết những gì
phần mềm dự kiến thực hiện và những gì dự kiến không thực hiện, mà không
thể nhìn vào bên trong xem nó hoạt động như thế nào). Và vì thế, dữ liệu
kiểm định sẽ xuất phát từ đặc tả.
Như vậy, cách tiếp cận kiểm định hộp đen tập trung vào các yêu cầu
chức năng của phần mềm. Kiểm định hộp đen cho phép các kỹ sư kiểm định
xây dựng các nhóm giá trị đầu vào mà sẽ thực thi đầy đủ tất cả các yêu cầu
chức năng của chương trình. Kiểm định hộp đen không thay thế kỹ thuật hộp
trắng, nhưng nó bổ sung khả năng phát hiện các lớp lỗi khác với các phương

pháp hộp trắng.
Kiểm định hộp đen cố gắng tìm các loại lỗi sau:
- Các chức năng thiếu hoặc không đúng.
- Các lỗi giao diện.
- Các lỗi cấu trúc dữ liệu trong truy cập cơ sở dữ liệu bên ngoài.
- Các lỗi thi hành.
- Các lỗi khởi tạo hoặc kết thúc.
Và các lỗi khác…
Kiểm định hộp đen nhắm đến áp dụng trong các giai đoạn sau của kiểm
định. Vì kiểm định hộp đen không để ý có chủ đích cấu trúc điều khiển, sự
quan tâm tập trung trên miền thông tin. Nếu người ta mong muốn sử dụng
phương pháp này để tìm tất cả các lỗi trong chương trình thì điều kiện bắt
buộc là phải kiểm định tất cả các đầu vào, tức là mỗi một điều kiện đầu vào
có thể có là một trường hợp kiểm định. Bởi vì nếu chỉ kiểm định một số điều
kiện đầu vào thì không đảm bảo được chương trình đã hết lỗi. Tuy nhiên, điều
này thực tế không thể thực hiện được.
2.2.1. Phân hoạch tương đương


Thông thường các kiểm định viên (Tester) không thể kiểm định được
mọi trường hợp đầu vào của dữ liệu, vì vậy cần chia dữ liệu thành các miền
có cùng hành vi và tạo ra các test case cho từng miền. Phân hoạch tương
đương là một phương pháp kiểm định hộp đen, phân chia miền đầu vào của
một chương trình thành các lớp dữ liệu, từ đó các trường hợp kiểm định được
tạo ra. Phân hoạch tương đương xây dựng một trường hợp kiểm định làm lộ
ra một lớp lỗi, do đó sẽ làm giảm tổng số các trường hợp kiểm định cần được
xây dựng.
Phân hoạch tương đương dựa trên một đánh giá về các lớp tương
đương với một điều kiện vào. Lớp tương đương biểu thị cho một tập các trạng
thái hợp lệ hay không hợp lệ.


Hình 2.2: Mô hình các bước thực hiện phân hoạch tương đương
Các lớp tương đương có thể được xây dựng theo các hướng sau:
-

Nếu một điều kiện vào xác định một miền thì một lớp hợp lệ và hai lớp
không hợp lệ được xác định.

-

Nếu một điều kiện vào đòi hỏi một giá trị xác định thì một lớp hợp lệ
và hai lớp không hợp lệ được xác định.

-

Nếu một điều kiện vào xác định thành biên của một tập thì một lớp
hợp lệ và một lớp không hợp lệ được xác định.

-

Nếu một điều kiện vào là boole thì một lớp hợp lệ và một lớp không
hợp lệ được xác định.


2.2.2. Phân tích giá trị biên (BVA - Boundary Value Analysis)

Có một số lớn các lỗi có khuynh hướng xuất hiện ở biên của miền đầu
vào hơn là tại trung tâm. Chính bởi lý do này mà việc phân tích giá trị biên
cũng được phát triển như một kỹ thuật kiểm định. Việc phân tích giá trị biên
dẫn tới việc lựa chọn các trường hợp kiểm định thực hiện tại các giá trị cận.

Phân tích giá trị biên cũng có thể coi là một kỹ thuật bổ sung thêm cho
phân hoạch tương đương. Thay vì chọn bất kỳ một phần tử nào của một lớp
tương đương. Phân tích giá trị biên dẫn tới chọn các trường hợp kiểm định tại
cạnh của lớp. Thay vì tập trung chủ yếu vào các điều kiện đầu vào. Phân tích
giá trị biên dẫn ra các trường hợp kiểm định từ miền đầu ra.

Hình 2.3: Mô hình phương pháp giá trị biên
Khi sử dụng phân tích giá trị biên cần lưu ý:
Nếu một điều kiện đầu vào xác định ra một miền được giới hạn bởi các giá trị
a và b, thì các trường hợp kiểm định nên được thiết
kế với các giá trị a và b, ngay ở trên và ngay ở dưới a và b, tương ứng
Nếu một điều kiện đầu vào xác định ra một số các giá trị, thì các trường
hợp kiểm định nên được xây dựng, để thử cho các giá trị cực tiểu và cực đại.
2.2.3. Kỹ thuật đồ thị nhân-quả (Cause-Effect Graph)

Trong nhiều trường hợp, việc cố gắng chuyển một chính sách hoặc một
thủ tục trong ngôn ngữ tự nhiên vào phần mềm dẫn đến sự thất bại và các vấn
đề khó hiểu. Đồ thị nhân - quả là một phương pháp thiết kế trường hợp kiểm


định trên cơ sở đưa ra một sự mô tả súc tích các điều kiện logic và các hành vi
kèm theo.
Đồ thị nhân - quả sử dụng mô hình các quan hệ logic giữa nguyên nhân
và kết quả cho thành phần phần mềm. Mỗi nguyên nhân được biểu diễn như
một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào.
Mỗi kết quả được biểu diễn như là một biểu thức Bool biểu diễn một kết quả
tương ứng cho những thành phần vừa thực hiện. Đồ thị nhân - quả được tạo
như sau:
- Tất cả các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được
liệt kê dựa trên đặc tả và được định danh cho mỗi nhân - quả.

- Các quan hệ giữa các nguyên nhân (các đầu vào) và các kết quả (các
đầu ra) được biểu diễn trong đồ thị làm rõ ràng các quan hệ logic.
- Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyên
nhân và kết quả. Dữ liệu kiểm định được sinh ra dựa trên các qui tắc trong các
bảng này.
Các ký hiệu trong đồ thị nhân quả
ST

Ký hiệu

Ý nghĩa

T
1

Tương đương

2

AND (và)

3

OR (hoặc)

4

NOT (phủ định)

5


Loại trừ

6

Bao hàm

Giải thích
Nếu đúng thì đúng.
Nếu đúng và đúng, thì
Nếu

đúng
đúng hoặc đúng, thì

đúng
Nếu
Nếu

sai, thì
đúng
đúng, thì sai, hoặc nếu

sai thì

đúng.

bao hàm



7

Yêu cầu

Tên bảng
Điều kiện 1
Điều kiện 2
Điều kiện 3
…
Điều kiện n
Hành động 1
Hành động 2
Hành động 3
…
Hành động n

yêu cầu

Qui tắc
Tên bảng: cho biết tên logic
1 2 …n
Y Y
Y
Y -Y --

Y Qui tắc: đánh số để phân biệt các qui tắc quyết
N định logic.

… …


… Các dòng điều kiện: Mỗi dòng bao gồm các

-- --

Y điều kiện để tạo quyết định cho chương trình.

X X

X

-- X

X

X --

X

… …

…

-- --

X

Y: “true”
N: “false”
-- : Không có quyết định được tạo ra.
Các hành động: Mỗi dòng chỉ định có các xử lý

được thực hiện hoặc không.
X: Xử lý được thực hiện.

Các qui tắc trong bảng quyết định được mô tả như sau:
2.2.4. Kiểm định so sánh

Có một số trường hợp (như điện tử máy bay, điều khiển thiết bị năng
lượng hạt nhân) trong đó độ tin cậy của phần mềm là tuyệt đối quan trọng,
người ta thường gọi là phần mềm tuyệt đối đúng. Trong các ứng dụng như
vậy phần cứng và phần mềm không cần thiết thường được sử dụng để tối
thiểu khả năng lỗi. Khi phần mềm không cần thiết được phát triển, các nhóm
công nghệ phần mềm riêng biệt phát triển các phiên bản độc lập của ứng dụng
sử dụng cùng một đặc tả. Trong các trường hợp như vậy, mỗi phiên bản có thể
được kiểm định với cùng dữ liệu kiểm định để đảm bảo rằng tất cả cung cấp
đầu ra y như nhau. Sau đó tất cả các phiên bản được thực thi song song với so
sánh thời gian thực các kết quả để đảm bảo tính chắc chắn. Các phiên bản độc
lập là cơ sở của kỹ thuật kiểm định hộp đen được gọi là kiểm định so sánh hay
kiểm định back-to-back.


Khi nhiều cài đặt của cùng một đặc tả được đưa ra, các trường hợp kiểm
định được thiết kế sử dụng các kỹ thụât hộp đen khác (ví dụ phân hoạch cân
bằng) được cung cấp như đầu vào cho mỗi phiên bản của phần mềm. Nếu đầu
ra của mỗi phiên bản là như nhau, sẽ cho rằng tất cả các cài đặt là đúng. Nếu
đầu ra là khác nhau, mỗi ứng dụng được nghiên cứu để xác định có sai sót nào
trong một hoặc nhiều phiên bản là nguyên nhân gây ra lỗi. Trong nhiều trường
hợp, so sánh các đầu ra có thể được thực hiện bởi các công cụ tự động.
Kiểm định so sánh là không rõ ràng. Nếu đặc tả mà tất cả các phiên bản
được phát triển trên đó là có lỗi, thì tất cả các phiên bản sẽ có khả năng dẫn
đến lỗi. Hơn nữa, nếu mỗi phiên bản độc lập tạo ra giống nhau, nhưng không

đúng, các kết qủa, kiểm định điều kiện sẽ thất bại trong việc phát hiện lỗi.
2.3. Kỹ thuật kiểm định hộp trắng (White-Box Testing)
Còn gọi là kiểm định cấu trúc. Kiểm định theo cách này là loại kiểm
định chương trình sử dụng các thông tin về cấu trúc bên trong của ứng dụng.
Việc kiểm định này dựa trên quá trình thực hiện xây dựng phần mềm.
2.3.1. Tiêu chuẩn của kiểm định hộp trắng

- Bao phủ dòng lệnh: Kiểm định hộp trắng hay còn gọi là kiểm định
hướng logic, cho phép kiểm tra cấu trúc bên trong của phần mềm với mục
đích đảm bảo rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất
một lần. Trong kỹ thuật này người kiểm định lấy dữ liệu xuất phát từ việc
kiểm tra logic của chương trình (bỏ qua đặc tả).
- Bao phủ đường: tất cả các đường (path) từ điểm khởi tạo đến điểm cuối
cùng trong sơ đồ dòng điều khiển phải được đi qua. Tương tự như vấn đề
kiểm định đầu vào trong kỹ thuật kiểm định hộp đen, đó là vấn đề kiểm
định các đường dẫn lệnh trong kỹ thuật hộp trắng. Nếu phải thực hiện tất cả
các đường dẫn của lưu trình điều khiển trong chương trình thông qua việc
chạy tất cả các trường hợp kiểm định thì có thể nói rằng chương trình đã