Kiểm định phần mềm theo tiếp cận hệ thống

- 73 -

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



Đoàn Văn Trung



KiÓm ®Þnh phÇn mÒm theo
tiÕp cËn hÖ thèng

Luận văn thạc sỹ




Hà Nội - 2007

- 1 -

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



Đoàn Văn Trung

KiÓm ®Þnh phÇn mÒm
theo tiÕp cËn hÖ thèng
Ngành : Công nghệ thông tin
Mã ngành: 1.01.10

Luận văn thạc sỹ

Người hướng dẫn khoa học:
PGS TSKH Nguyễn Xuân Huy


Hà Nội - 2007


- 1 -
CHƢƠNG 1. TỔNG QUAN VỀ KIỂM ĐỊNH PHẦN MỀM
1.1 Giới thiệu chung về kiểm định phần mềm
Các quy trình và kỹ thuật kiểm định phần mềm là các vấn đề hiện nay đang
đƣợc các nhà chuyên môn và quản lý quan tâm, nhằm đáp ứng cho nhu cầu ngày càng
cao về kiểm định chất lƣợng của các ứng dụng công nghệ thông tin nói chung và cụ
thể là các sản phẩm phần mềm trong các lĩnh vực cuộc sống.
Kiểm định phần mềm là một phần quan trọng và quyết định của quá trình phát
triển phần mềm trên chất lƣợng và độ tin cậy của sản phẩm chuyển giao. Kiểm định
không giới hạn để phát hiện lỗi trong phần mềm, mà sự tin cậy tăng lên trong các chức
năng của chúng với sự đánh giá của các thuộc tính chức năng cũng nhƣ các thuộc tính
khác [2].
Kiểm định phần mềm là một hoạt động kiểm tra năng lực, khả năng của phầm
mềm bao gồm nhiều nhiệm vụ đòi hỏi khắt khe khác nhau: trƣớc hết là nhiệm vụ xuất
phát từ một bộ đầy đủ các trƣờng hợp kiểm định thích hợp, theo một kỹ thuật kiểm

định phần mềm đƣợc chọn lựa có lợi và có khả năng thực hiện đƣợc. Tuy nhiên, sự lựa
chọn hình thức kiểm định mới chỉ là một điểm bắt đầu mà còn nhiều nhiệm vụ quyết
định khác thể hiện các mặt về chuyên môn kỹ thuật và các khái niệm phức tạp: chặng
hạn khả năng để chọn lựa các kiểu kiểm định; sự quyết định các kết quả kiểm định có
thể chấp nhận đƣợc hay không; nếu không thì đánh giá sự ảnh hƣởng của sự cố lỗi
chƣơng trình và phát hiện nguyên nhân trực tiếp cũng nhƣ gián tiếp lỗi của chúng,
phân tích các nguyên nhân cơ bản; đánh giá kiểm định là có khả năng và có thể dừng
lại đƣợc, phụ thuộc lần lƣợt việc kiểm tra các tiêu chuẩn đánh giá hiệu lực của kiểm
định.
Trong luận văn này các thuật ngữ kiểm định, kiểm tra và kiểm thử đƣợc sử
dụng với cùng một ý nghĩa.
1.2. Khái niệm kiểm định phần mềm
Kiểm định phần mềm là phần mấu chốt của đảm bảo chất lƣợng phần mềm và
biểu thị cho việc xét duyệt tối hậu về đặc tả, thiết kế và mã hóa.


- 2 -
Theo nghĩa thông thƣờng nhất, kiểm định phần mềm bao gồm việc "chạy thử"
phần mềm hay một chức năng của phần mềm, xem nó chạy đúng nhƣ mong muốn hay
không.
Theo Glen Myers [15] thì kiểm định là một quá trình vận hành chƣơng trình với
ý định tìm ra các lỗi của phần mền. Một (lần) kiểm định tốt là kiểm định có xác suất
cao trong việc tìm ra một lỗi chƣa đƣợc phát hiện. Một (lần) kiểm định thành công là
một kiểm định làm lộ ra đƣợc ít nhất một lỗi còn chƣa đƣợc phát hiện.
1.3 Quy trình kiểm định phần mềm
Việc kiểm định phần mềm có thể thực hiện từng bƣớc, sau mỗi chức năng hoặc
module đƣợc phát triển, hoặc thực hiện sau cùng, khi phần mềm đã đƣợc phát triển
hoàn tất.
Quy trình kiểm định phần mềm có thể bao gồm các mức và bƣớc kiểm tra cơ
bản nhƣ sau:

 Kiểm định đơn vị
 Kiểm định tích hợp
 Kiểm định hệ thống
 Kiểm định chấp nhận

Hình 1.1. Các mức độ cơ bản của kiểm tra phần mềm


- 3 -
1.3.1. Kiểm định đơn vị
Để có thể hiểu rõ về kiểm định đơn vị, khái niệm trƣớc tiên ta cần làm rõ: thế
nào là một đơn vị phần mềm [2]. Một đơn vị là một thành phần phần mềm nhỏ nhất
mà ta có thể kiểm tra đƣợc. Theo định nghĩa này, các hàm, thủ tục, lớp, hoặc các
phƣơng thức đều có thể đƣợc xem là đơn vị.
Vì đơn vị đƣợc chọn để kiểm tra thƣờng có kích thƣớc nhỏ và chức năng hoạt
động đơn giản, sẽ không khó khăn gì trong việc tổ chức, kiểm tra, ghi nhận và phân
tích kết quả kiểm tra. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng
tƣơng đối dễ dàng vì chỉ khoanh vùng trong một đơn thể đơn vị đang kiểm tra. Một
nguyên lý đúc kết từ thực tiễn: thời gian tốn cho kiểm định đơn vị sẽ đƣợc đền bù bằng
việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức
kiểm tra sau đó.
Kiểm định đơn vị thƣờng do lập trình viên thực hiện. Công đoạn này cần đƣợc
thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển
phần mềm. Thông thƣờng, kiểm định đơn vị đòi hỏi kiểm tra viên có kiến thức về thiết
kế và code của chƣơng trình. Mục đích của kiểm định đơn vị là bảo đảm thông tin
đƣợc xử lý và xuất (khỏi đơn vị) là chính xác, trong mối tƣơng quan với dữ liệu nhập
và chức năng của đơn vị. Điều này thƣờng đòi hỏi tất cả các nhánh bên trong đơn vị
đều phải đƣợc kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thƣờng là một
chuỗi các lệnh đƣợc thực thi trong một đơn vị, ví dụ: chuỗi các lệnh sau điều kiện if và
nằm giữa then else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa

việc kiểm tra và quét hết đơn vị đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán
để thực hiện.
Cũng nhƣ các mức kiểm tra khác, kiểm định đơn vị cũng đòi hỏi phải chuẩn bị
trƣớc các ca kiểm định hoặc kịch bản, trong đó chỉ định rõ dữ liệu vào, các bƣớc thực
hiện và dữ liệu mong chờ sẽ xuất ra. Các ca kiểm định và kịch bản này nên đƣợc giữ
lại để tái sử dụng.
Kiểm định đơn vị có thể bao gồm các kỹ thuật kiểm định sau:
 Kiểm định hộp đen (black box)
 Kiểm định hộp trắng (white box)


- 4 -
1.3.2. Kiểm định tích hợp
Kiểm định tích hợp kết hợp các thành phần của một ứng dụng và kiểm tra nhƣ
một ứng dụng đã hoàn thành [15]. Trong khi kiểm định đơn vị kiểm tra các thành phần
và đơn vị riêng lẻ thì kiểm định tích hợp kết hợp chúng lại với nhau và kiểm tra sự
giao tiếp giữa chúng.
Kiểm định tích hợp có 2 mục tiêu chính:
 Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị.
 Tích hợp các đơn vị đơn lẻ thành các hệ thống nhỏ và cuối cùng là nguyên hệ
thống hoàn chỉnh chuẩn bị cho kiểm tra ở mức hệ thống.
Trong kiểm định đơn vị, lập trình viên cố gắng phát hiện lỗi liên quan đến chức
năng và cấu trúc nội tại của đơn vị. Có một số phép kiểm tra đơn giản trên giao tiếp
giữa đơn vị với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến
đơn vị thật sự đƣợc kiểm tra đầy đủ khi các đơn vị tích hợp với nhau trong khi thực
hiện kiểm định tích hợp.
Một chiến lƣợc cần quan tâm trong kiểm định tích hợp là nên tích hợp dần từng
đơn vị. Một đơn vị tại một thời điểm đƣợc tích hợp vào một nhóm các đơn vị khác đã
tích hợp trƣớc đó và đã hoàn tất các đợt kiểm định tích hợp trƣớc đó. Lúc này, ta chỉ
cần kiểm tra giao tiếp của đơn vị mới thêm vào với hệ thống các đơn vị đã tích hợp

trƣớc đó, điều này làm cho số lƣợng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng
kể.
Có 4 loại kiểm tra trong kiểm định tích hợp:
1. Kiểm tra cấu trúc: Tƣơng tự kiểm định hộp trắng (kiểm tra nhằm bảo đảm các
thành phần bên trong của một chƣơng trình chạy đúng), chú trọng đến hoạt
động của các thành phần cấu trúc nội tại của chƣơng trình chẳng hạn các lệnh
và nhánh bên trong.
2. Kiểm tra chức năng: Tƣơng tự kiểm định hộp đen (kiểm tra chỉ chú trọng đến
chức năng của chƣơng trình, không quan tâm đến cấu trúc bên trong), chỉ khảo
sát chức năng của chƣơng trình theo yêu cầu kỹ thuật.
3. Kiểm tra hiệu năng: Kiểm tra việc vận hành của hệ thống.


- 5 -
4. Kiểm tra khả năng chịu tải: Kiểm tra các giới hạn của hệ thống.
1.3.3. Kiểm định hệ thống
Mục đích kiểm định hệ thống là kiểm tra thiết kế và toàn bộ hệ thống (sau khi
tích hợp) có thỏa mãn yêu cầu đặt ra hay không.
Kiểm định hệ thống bắt đầu khi tất cả các bộ phận của phần mềm đã đƣợc tích
hợp thành công. Thông thƣờng loại kiểm tra này tốn rất nhiều công sức và thời gian.
Trong nhiều trƣờng hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc
phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ
thống nhúng. Ở mức độ hệ thống, ngƣời kiểm tra cũng tìm kiếm các lỗi, nhƣng trọng
tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến
chất lƣợng của toàn hệ thống.
Điểm khác nhau then chốt giữa kiểm định tích hợp và kiểm định hệ thống là
kiểm định hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống, còn kiểm định tích
hợp chú trọng sự giao tiếp giữa các đơn thể hoặc đối tƣợng khi chúng làm việc cùng
nhau. Thông thƣờng ta phải thực hiện kiểm định đơn vị và kiểm định tích hợp để bảo
đảm mọi Unit và sự tƣơng tác giữa chúng hoạt động chính xác trƣớc khi thực hiện

kiểm định hệ thống.
Kiểm định hệ thống kiểm tra cả các hành vi chức năng của phần mềm lẫn các
yêu cầu về chất lƣợng nhƣ độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.
Mức kiểm tra này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm
hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" hoặc chiếm dụng bộ nhớ.
Sau giai đoạn kiểm định hệ thống, phần mềm thƣờng đã sẵn sàng cho khách hàng hoặc
ngƣời dùng cuối cùng kiểm tra để chấp nhận hoặc dùng thử (Alpha/Beta Test).
Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, kiểm định hệ
thống thƣờng đƣợc thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm
phát triển dự án.
Bản thân kiểm định hệ thống lại gồm nhiều loại kiểm tra khác nhau, phổ biến
nhất gồm:
 Kiểm tra chức năng: bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu
thiết kế.


- 6 -
 Kiểm tra khả năng vận hành: bảo đảm tối ƣu việc phân bổ tài nguyên hệ thống
(ví dụ bộ nhớ) nhằm đạt các chỉ tiêu nhƣ thời gian xử lý hay đáp ứng câu truy
vấn,
 Kiểm tra khả năng chịu tải: bảo đảm hệ thống vận hành đúng dƣới áp lực cao
(ví dụ nhiều ngƣời truy xuất cùng lúc). Kiểm tra khả năng chịu tải tập trung vào
các trạng thái tới hạn, các "điểm chết", các tình huống bất thƣờng,
 Kiểm tra cấu hình
 Kiểm tra khả năng bảo mật: bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của
hệ thống.
 Kiểm tra khả năng phục hồi: bảo đảm hệ thống có khả năng khôi phục trạng
thái ổn định trƣớc đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt
quan trọng đối với các hệ thống giao dịch nhƣ ngân hàng trực tuyến.

Hình 1.2. Các loại kiểm tra khác nhau trong Kiểm định hệ thống
Nhìn từ quan điểm ngƣời dùng, các kiểm tra trên rất quan trọng: bảo đảm hệ
thống đủ khả năng làm việc trong môi trƣờng thực. Lƣu ý không nhất thiết phải thực
hiện tất cả các loại kiểm tra nêu trên. Tùy yêu cầu và đặc trƣng của từng hệ thống, tuỳ
khả năng và thời gian cho phép của dự án, khi lập kế hoạch, trƣởng dự án sẽ quyết
định áp dụng những loại kiểm tra nào.


- 7 -
1.3.4. Kiểm định chấp nhận
Thông thƣờng, sau giai đoạn kiểm định hệ thống là kiểm định chấp nhận, đƣợc
khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện) [1]. Mục đích
của kiểm định chấp nhận là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của
khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).
Kiểm định chấp nhận có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi
trƣờng hợp, các phép kiểm tra của kiểm định hệ thống và kiểm định chấp nhận gần
nhƣ tƣơng tự, nhƣng bản chất và cách thức thực hiện lại rất khác biệt.
Đối với những sản phẩm dành bán rộng rãi trên thị trƣờng cho nhiều ngƣời sử
dụng, thông thƣờng sẽ thông qua hai loại kiểm tra gọi là Alpha Test và Beta Test. Với
Alpha Test, ngƣời sử dụng (tiềm năng) kiểm tra phần mềm ngay tại nơi phát triển phần
mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với
Beta Test, phần mềm sẽ đƣợc gửi tới cho ngƣời sử dụng (tiềm năng) để kiểm tra ngay
trong môi trƣờng thực, lỗi hoặc phản hồi cũng sẽ gửi ngƣợc lại cho lập trình viên để
sửa chữa.
Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá
trình phát triển phần mềm thì kết quả kiểm định chấp nhận sẽ sai lệch rất lớn, mặc dù
phần mềm đã trải qua tất cả các kiểm tra trƣớc đó. Sự sai lệch này liên quan đến việc
hiểu sai yêu cầu cũng nhƣ sự mong chờ của khách hàng. Ví dụ, đôi khi một phần mềm
xuất sắc vƣợt qua các phép kiểm tra về chức năng thực hiện bởi nhóm thực hiện dự án,
nhƣng khách hàng khi kiểm tra sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn,

thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng, v.v
Gắn liền với giai đoạn kiểm định chấp nhận thƣờng là một nhóm những dịch vụ
và tài liệu đi kèm, phổ biến nhƣ hƣớng dẫn cài đặt, sử dụng, v.v Mọi tài liệu đi kèm
phải đƣợc cập nhật và kiểm tra chặt chẽ.


- 8 -
CHƢƠNG 2. CÁC KỸ THUẬT KIỂM ĐỊNH PHẦN MỀM
2.1. Kiểm định hộp trắng
2.1.1. Kiểm định hộp đen và kiểm định hộp trắng
Hộp đen và hộp trắng là các phƣơng pháp kiểm định phần mềm: kiểm định hộp
đen (black-box, chức năng) và kiểm định hộp trắng (white-box , cấu trúc) [2].
Kiểm định hộp đen thƣờng đƣợc hiểu theo nghĩa là tập trung vào kiểm tra các
yêu cầu chức năng của ứng dụng phần mềm. Phần mềm đƣợc thực thi đầy đủ đối với
các dải dữ liệu đầu vào và tập dữ liệu đầu ra sẽ đƣợc xem xét xem có đúng đắn không.
Cách thức để đạt đƣợc kết quả đầu ra này hay cái gì bên trong “hộp” thì không cần
quan tâm đến. Kiểm định hộp đen coi hệ thống nhƣ một hộp đen thuần túy, vì vậy nó
không cần biết đến các cấu trúc bên trong.
Mặc dù kiểm định hộp đen có nhiều ƣu điểm nhƣng bản thân nó thì chƣa đủ.
Trƣớc tiên, các hệ thống trong đời thƣờng có rất nhiều loại dữ liệu đầu vào khác nhau,
điều đó dẫn tới sự bùng nổ các ca kiểm định. Ví dụ, đối với một chƣơng trình kiểm tra
số dƣ trong tài khoản ở Ngân hàng (check-balancing) là khoảng 100 dòng lệnh, ta có
thể chạy một tập các ca kiểm định tiêu biểu, nhƣng đối với hệ thống lớn nhƣ hệ thống
mô phỏng để đào tạo phi công lái máy bay 747 thì không thể kiểm tra chặt chẽ các
thông số đầu vào/đầu ra dựa trên kỹ thuật kiểm định hộp đen.
Thêm nữa là không thể biết đƣợc các phần mã lệnh nào của chƣơng trình có
thực hiện bằng kỹ thuật kiểm định hộp đen. Các đoạn mã lệnh mà chƣa thực hiện trong
quá trình kiểm tra đƣợc ví nhƣ một quả bom nổ chậm trong gói phần mềm. Tất nhiên,
những đoạn mã lệnh chƣa thực hiện nghĩa là chƣa đƣợc test.
Một giải pháp cho vấn đề này là sử dụng kiểm tra hộp trắng bổ sung thêm cho

kiểm tra hộp đen. Chiến thuật kiểm tra hộp trắng bao gồm các kiểm tra thiết kế nhƣ
các dòng mã lệnh phải đƣợc thực thi ít nhất một lần hoặc kiểm tra các chức năng một
cách riêng biệt. Kiểm định hộp trắng cho phép ngƣời kiểm tra xem xét bên trong, nó
đặc biệt chú trọng các thông tin bên trong của phần mềm để chọn các dữ liệu kiểm tra
một các hiệu quả.
Kiểm định hộp trắng đòi hỏi phải có các am hiểu bên trong chƣơng trình, trong
khi đó kiểm định hộp đen chỉ dựa trên hiểu biết về các yêu cầu hệ thống nói chung.


- 9 -
2.1.2. Các nguyên tắc kiểm định hộp trắng
Kiểm định hộp trắng liên quan đến logic bên trong và cấu trúc của mã lệnh. Nó
còn đƣợc gọi là ClearBox Testing/OpenBox Testing/Structural Testing/ Glass Testing
[13].
Các bài kiểm tra dựa trên kỹ thuật kiểm định hộp trắng kết hợp chặt chẽ các yếu
tố bao gồm các câu lệnh, các rẽ nhánh, đƣờng đi, biểu thức và logic bên trong của mã
lệnh chƣơng trình.
Để thực hiện kiểm định, kiểm tra viên phải quan tâm, làm việc với mã lệnh và
do đó cần am hiểu, có kiến thức về lập trình và cách thức hoạt động bên trong của mã
lệnh. Kiểm định hộp trắng cũng yêu cầu kiểm tra viên xem xét trong mã lệnh và tìm ra
phần tử/biểu thức/đoạn mã nào hoạt động không chính xác.
Một số quy tắc cơ bản đối với kiểm định hộp trắng:
- Kiểm tra tất cả các đƣờng đi độc lập ít nhất một lần
- Kiểm tra tất cả các quyết định logic (if-then-else) với giá trị TRUE/FALSE .
- Kiểm tra tất cả các vòng lặp (for, while-do) tại các các giá trị biên, các giá trị
bên trong biên.
- Kiểm tra tính đúng đắn của tất các các cấu trúc dữ liệu nội tại trong chƣơng
trình.
2.1.3. Ưu, nhược điểm của kiểm định hộp trắng
Các ƣu điểm của kiểm định hộp trắng:

- Vì ngƣời kiểm tra am hiểu về cấu trúc bên trong của chƣơng trình, do đó rất dễ
để tìm ra các tập dữ liệu đầu vào để kiểm tra chƣơng trình một cách hiệu quả.
- Một ƣu điểm nữa là kiểm tra hộp trắng giúp cho việc tối ƣu các mã lệnh của
chƣơng trình. Nó cũng giúp loại bỏ các dòng mã lệnh thừa mà có thể tiềm ẩn
những sai sót
- Có thể phát hiện, loại bỏ những hiệu ứng phụ của các cấu trúc mã lệnh trong
chƣơng trình.
Tuy vậy, kiểm định hộp trắng cũng tồn tại một số nhƣợc điểm:


- 10 -
- Do yêu cầu phải nắm rõ cấu trúc chƣơng trình và mã lệnh bên trong, các kiểm
tra viên cần có kỹ năng cao hơn dẫn tới tăng chi phí.
- Có thể bỏ sót các tham số kiểm tra thừa lại sau khi can thiệp vào mã lệnh của
chƣơng trình.
- Gần nhƣ không thể xem xét tất cả đến byte/bit của chƣơng trình để tìm các lỗi
ẩn giấu mà có thể làm chƣơng trình xảy ra lỗi khi hoạt động.
2.2. Các chiến lƣợc kiểm tra của kiểm thử hộp trắng
2.2.1. Kiểm định đường cơ sở
Mục tiêu là tìm ra một tập cơ bản các con đƣờng thực hiện độc lập đi qua các
điểm trong chƣơng trình ít nhất một lần.
Cách thức thực hiện gồm các bƣớc sau:
1. Từ một thiết kế hoặc một mã nguồn vẽ đồ thị dòng G tƣơng ứng.
2. Tính toán độ phức tạp chu trình V(G) của chƣơng trình ứng với số con đƣờng
độc lập
3. Tìm tập cơ bản các con đƣờng độc lập ứng với V(G) đã tìm.
4. Thiết kế các ca kiểm định cho tập cơ bản trên
2.2.1.1. Đồ thị dòng
Đồ thị dòng dùng để biểu diễn các dòng điều khiển trong chƣơng trình và giúp
xác định ra tập con đƣờng cơ bản.

Đồ thị dòng (đồ thị chƣơng trình) là một đồ thị mà:
 Mỗi nút (hình tròn) biểu thị một vài câu lệnh thủ tục
 Mỗi cạnh nối hai nút biểu diễn dòng điều khiển,
 Chia mặt phẳng thành nhiều miền.
 Mỗi nút biểu thị sự phân nhánh hoặc hội nhập đƣợc gọi là nút vị từ.


- 11 -

Hình 2.1. Các loại cấu trúc cơ bản

Hình 2.2. Ví dụ về đồ thị dòng
2.2.1.2. Tập các đƣờng cơ bản
Để đảm tất cả các câu lệnh trong chƣơng trình đều đƣợc kiểm định ít nhất một
lần, ta cần tìm đƣợc tất cả các đƣờng độc lập trong các chu trình, tức là mỗi đƣờng
khác với các đƣờng khác ít nhất một lệnh.
Tập cơ bản các đƣờng độc lập là tập:
 Mọi cung của đồ thị dòng đều có mặt trong một đƣờng của tập các con đƣờng
đó.
 Mỗi đƣờng của tập đó đều chứa ít nhất một cung mà mọi đƣờng khác của tập đó
không có.
Số lƣợng các đƣờng của tập này cho ta số đo độ phức tạp chu trình của chƣơng
trình.


- 12 -
Tập đƣờng dẫn độc lập cho đồ thị lƣu trình đƣợc minh hoạ trong hình 4 là:
Đƣờng dẫn 1: 1-11
Đƣờng dẫn 2: 1-2-3-4-5-10-1-11
Đƣờng dẫn 3: 1-2-3-6-8-9-10-1-11

Đƣờng dẫn 4: 1-2-3-6-7-9-10-1-11
Mỗi đƣờng dẫn mới đƣa ra một cung mới. Đƣờng dẫn 1-2-3-4-5-10-1-2-3-6-8-9-
10-1-11 không đƣợc xem là một đƣờng dẫn độc lập vì nó chỉ là một tổ hợp các đƣờng
dẫn đã đƣợc chỉ ra (đƣờng dẫn 2 và 3) và nó sẽ không đi qua một cung mới nào.
Các đƣờng dẫn 1, 2, 3 và 4 tạo thành một tập cơ sở trong hình 2.4b. Nếu các
trƣờng hợp kiểm thử đƣợc thiết kế để thực hiện những đƣờng dẫn này (một tập cơ sở)
thì mọi lệnh trong chƣơng trình sẽ đảm bảo đƣợc thực hiện ít nhất một lần và mọi điều
kiện sẽ đƣợc thực hiện cả hai mặt đúng (true) và mặt sai (false). Tuy nhiên, tập cơ sở
không phải là duy nhất. Trong thực tế, một số các tập cơ sở khác nhau có thể đƣợc suy
diễn cho việc thiết kế một thủ tục đƣợc đƣa ra.
2.2.1.3. Độ phức tạp chu trình
Số các đƣờng độc lập trong tập cơ sở của chƣơng trình là giới hạn trên của số
các kiểm định cần phải tiến hành. Nó đƣợc gọi là độ phức tạp của chu trình.
Độ phức tạp chu trình V(G) của đồ thị G đƣợc tính theo các cách sau:
 V(G) = E - N + 2
 V(G) = số miền phẳng
 V(G) = P + 1
Trong đó: E = số cung; N = số nút; P= số nút vị từ


- 13 -

Hình 2.3. Ví dụ về đồ thị dòng
Công thức 1: V
1
(G) = E – N + 2 = 11 – 9 + 2 = 4
Công thức 2: V
2
(G) = R = 4
Công thức 3: Số nut vị từ P =3. Vì vậy V

3
(G) = P + 1 = 3 + 1 = 4
Nhƣ vậy, độ phức tạp chu trình của đồ thị trong hình 5 là:
V(G)= V
1
(G) = V
2
(G) = V
3
(G) = 4

Ví dụ: cho mã nguồn chƣơng trình giải phƣơng trình bậc 2 nhƣ sau.

Program PTB2;
Var
a,b,c:Integer;
delta,x,x1,x2:Real;
Begin
Write('Nhap he so a,b,c');
Readln(a);Readln(b);Readln(c);
delta:=sqr(b)-4*a*c;
If a<> 0 then
Begin
If delta < 0 then
Writeln('PTB2 vo nghiem')
Else
If delta=0 then
Begin
X:=-b/2*a;
Writeln('PTB2 nghiem X1=X2=',x:6:2);

End
Else
Begin
X1:=-b-Sqrt(delta)/2*a;
X2:=-b+Sqrt(delta)/2*a;
R1
R4
R3
R2


- 14 -
Writeln('Nghiem x1=',x1:6:2);
Writeln('Nghiem x2=',x2:6:2);
End;
End;
Else
Writeln('PTB2 invalid');
Readln;
End.
(1) Phân tích, xác định yêu cầu mức độ kiểm định đường cơ sở
Yêu cầu phân tích mã nguồn, xác định mức độ kiểm định tập các đƣờng cơ sở
độc lập tuyến tính. Mỗi đƣờng sẽ đƣợc tiến hành kiểm định bằng kỹ thuật phân hoạch
tƣơng đƣơng và phân tích giá trị biên.
(2) Vẽ lưu đồ, đồ thị luồng

Hình 2.4. Đồ thị dòng của phƣơng trình bậc 2
(3) Xác định V(G)
Cách 1: V (G) =P+1 =3+1=4 (Với P số nút tân từ có trong đồ thị luồng G)
Cách 2: V(G) = 4 (Số vùng của đồ thị G).
Cách 3: V (G) = E-N+2= 11-9+2 =4 (Với E là số cạnh, N là số nút).
(4)Xác định tập các đường cơ sở độc lập tuyến tính
a=0
delta<
0
delta=
0
x=-b/2*a
x1=(-b-
sqrt(delta))/2*a
x1=(-
b+sqrt(delta))/2*a

PTB2
vo nghiem
PTB2
invalid

Nhập a,b,c;
Delta:=sqr(b)-4*a*c;

1
2
3
4
8
7
6
5
9
T
F
T
F
T
F
5
1
2
3
4
6
9
7
8
R1
R2
R3
R4

- 15 -
Đƣờng độc lập tuyến tính 1: 1 - 2 - 8 - 9.
Đƣờng độc lập tuyến tính 2: 1 - 2 - 3 - 7 - 9.
Đƣờng độc lập tuyến tính 3: 1 - 2 -3 - 4- 5 - 9.
Đƣờng độc lập tuyến tính 4: 1 - 2 - 3 - 4 - 6 - 9.
(5) Thiết kế các trường hợp kiểm định
Trường hợp
kiểm định
Nội dung
Kết quả dự kiến
Kết quả thực
delta =0
{a,b,c}={2,-4,2}
x1=x2= 1

delta >0
{a,b,c}={1,3,2}
x1=-1, x2= -2

delta <0
{a,b,c}={1,1,1}
thông báo 'PTB2
VN'

a=0
{a,b,c}={0,1,1}
thông báo 'PTB2
invalid'

2.2.1.4 Ma trận kiểm định
Ma trân kiểm định là một ma trận vuông có kích thƣớc bằng số các nút trong đồ
thị dòng:
 Mỗi dòng/cột ứng với tên một nút
 Mỗi ô: là tên một cung nối nút dòng đến nút cột.
Nhân liên tiếp k ma trận này đƣợc ma trận chỉ các con đƣờng k cung từ nút
dòng tới nút cột.
Các ma trận kiểm định đƣợc sử dụng nhƣ một dữ liệu có cấu trúc để kiểm tra
các đƣờng cơ bản.
Để ma trận kiểm định - một công cụ mạnh trong việc đánh giá cấu trúc điều
khiển chƣơng trình khi kiểm định, ta thêm trọng số cho các cung của ma trận kiểm
định nhƣ sau:
 Xác suất cung đó đƣợc tiến hành.
 Thời gian xử lý của quá trình đi qua cung đó.


- 16 -
 Bộ nhớ đòi hỏi của quá trình đi qua cung đó.
 Nguồn lực đòi hỏi của quá trình đi qua cung đó.
2.2.2. Kiểm định điều kiện
Điều kiện có thể là một trong các dạng sau:
 Điều kiện đơn: là một biến boolean hoặc một biểu thức quan hệ , có thể có toán
tử phủ định đứng đầu.
 Biểu thức quan hệ: là một biểu thức boolean chỉ một quan hệ giữa hai biểu thức
số học và quan hệ với nhau bởi các quan hệ so sánh (<, <=, >, >=, = =, !=)
 Điều kiện kết hợp: là điều kiện cấu thành từ hơn một điều kiện đơn nhờ các toán
tử boolean: hoặc, và, phủ định (OR, AND, NOT)
Các kiểu sai trong điều kiện kiểm định có thể là:
 Sai biến boolean (ví dụ: sử dụng sai biến).
 Sai toán tử boolean (ví dụ: AND thay cho OR).

 Sai số hạng trong biểu thức toán tử boolean
 Sai toán tử quan hệ (ví dụ: >= thay cho >)
 Sai biểu thức số học (ví dụ: j + k thay cho j - k).
Kiểm định điều kiện dựa trên các điều kiện để kiểm định, và bao gồm các kỹ thuật sau:
 Kiểm định phân nhánh
 Kiểm định miền
 Kiểm định BRO.
2.2.2.1. Kiểm định phân nhánh
Hầu nhƣ không phần mềm ứng dụng nào có thể viết theo mô hình mã lệnh tiếp
diễn liên tục, mà thƣờng tại một số điểm chúng cần phải rẽ nhánh để thực hiện một
chức năng lựa chọn nào đó. Việc kiểm tra bao gồm chạy các dữ liệu kiểm tra mỗi
nhánh ít nhất một lần. Kiểm tra theo dõi rẽ nhánh giúp xác nhận tính đúng đắn tất cả
các rẽ nhánh trong mã lệnh và khẳng định không có nhánh nào dẫn tới hành xử bất
thƣờng của ứng dụng.


- 17 -

Hình 2.5. Lưu đồ của một chương trình với các rẽ nhánh
Việc kiểm định tiến hành một cách đơn giản theo nguyên tắc sau:
 Kiểm định từng điều kiện trong chƣơng trình.
 Mục tiêu của kiểm định điều kiện không chỉ là phát hiện sai trong điều kiện đó
mà còn là phát hiện các lỗi khác của chƣơng trình.
 Kiểm định nhánh: với mỗi điều kiện kết hợp C, thì các nhánh “true” và “false”
của C và mỗi một điều kiện đơn trong C phải đƣợc kiểm định ít nhất một lần.
2.2.2.2. Kiểm định theo miền
 Chiến lƣợc kiểm định theo miền đòi hỏi 3 hoặc 4 kiểm định cho một biểu thức
quan hệ: Các trƣờng hợp <, >, =, <=, >= và .
Ví dụ: Điều kiện (x > 5)
Dẫn tới 3 kiểm định là: x = 5, x = 3 < 5, x = 8 > 5

 Nếu biểu thức boolean có n biến thì cần tới 2
n
kiểm định
Ví dụ: C = (b1 && b2) || (b3 && b4) sẽ cần 16 kiểm định tất cả.
Nên n nhỏ thì thuận lợi, song nếu n lớn thì điều này là khó khả thi.


- 18 -
2.2.2.3. Kiểm định BRO
Kiểm định theo miền với 2
n
ca kiểm định là rất khó thực hiện trong trƣờng hợp
n lớn. BRO là kỹ thuật làm giảm số ca kiểm định xuống [9].
BRO = kiểm định nhánh & toán tử quan hệ.
 BRO dùng “ràng buộc điều kiện cho điều kiện cần thử”.
 Giả sử trong điều kiện C cần thử có n-1 điều kiện đơn, các ràng buộc của C (có
n điều kiện đơn) là (D
1
, D
2
,…, D
n
), trong đó D
i
là một đặc tả ràng buộc đầu ra
của điều kiện đơn tƣơng ứng của C.
 Ta nói rằng ràng buộc D của điều kiện C là đƣợc phủ bởi một thi hành của C
nếu nhƣ trong quá trình thi hành đó, đầu ra (“outcome”) của mỗi điều kiện đơn
trong C thoả mãn các ràng buộc tƣơng ứng.
Với một biến Boolean B, thì ràng buộc đầu ra của B là t (true) hoặc f (false).

Với một biểu thức quan hệ B thì ràng buộc đầu ra của B là: >, <, =,  (lớn hơn,
nhỏ hơn, bằng hoặc khác).
Xét điều kiện C là kết hợp của hai biến Boolean A và B (C = A Π B). Khi đó
ràng buộc đầu ra của C là một cặp giá trị t hoặc f.
Ví dụ, xét điều kiện (C = A AND B). Chiến lƣợc kiểm định BRO đòi hỏi rằng
tập ba ràng buộc {(t, t), (t, f), (f, t)} đều đƣợc phủ bởi các thi hành của C, còn {f, f} là
thừa. Biểu thức logic C không đúng khi “ít nhất một đối sai” (hoặc A hoặc B sai), do
vậy trong 3 cặp trên có ít nhất một cặp làm C sai.
Xét điều kiện đơn C : (B = E). Khi đó ràng buộc của C là một trong ba : < , > ,
=.
Ví dụ xét điều kiện C là hội của hai biến Boolean: A và B = E. Khi đó các ràng
buộc của C là các cặp (t, t), (t, f) và (f, t); với (B = E) có giá trị t tƣơng ứng với “=“, và
giá trị f tƣơng ứng với “<“ hoặc “>”. Xét tƣơng tự trên đối với điều kiện hai biến
Boolean {(t, t), (t, f), (f, t)} ta có tập các ràng buộc của C phải gồm 4 phần tử: (t, =), (t,
<), (t, >) và (f, =).
Phủ của ràng buộc này bảo đảm đã phát hiện đƣợc sai biên Boolean hoặc toán
tử quan hệ trong C.


- 19 -
2.2.3 Kiểm định dòng dữ liệu
Phƣơng pháp kiểm định dòng dữ liệu tuyển chọn các đƣờng của chƣơng trình
tƣơng ứng với việc định vị các xác định biến và sử dụng biến trong chƣơng trình. Đã
có một số chiến lƣợc kiểm định dòng dữ liệu và so sánh chúng.
Giả sử rằng mỗi câu lệnh của chƣơng trình đƣợc gán với số câu lệnh duy nhất
và mỗi hàm không đƣợc cải biên các tham số của nó và các biến toàn cục.
Với mỗi câu lệnh S ta định nghĩa:
 DEF(S) = {X | câu lệnh S chứa định nghĩa của X}: tập các biến đƣợc định nghĩa
trong S
 USE(S) = {X | câu lệnh S chứa một sử dụng X}: tập các biến đƣợc sử dụng

trong S
 Nếu S là câu lệnh if hoặc câu lệnh lặp thì DEF của nó là rỗng (đối với ngôn ngữ
Pascal), còn USE của nó là đƣợc xác định dựa theo điều kiện trong S.
Giả thiết: định nghĩa biến X ở câu lệnh S vẫn còn sống tại câu lệnh S’ nếu có
một con đƣờng từ S tới S’ mà trên con đƣờng đó không chứa một định nghĩa nào khác
của X.
Một chuỗi khai báo - sử dụng (DU) của biến X là có dạng [X, S, S’] trong đó S,
S’ là các số hiệu lệnh, X có trong tập DEF(S) và tập USE(S’), và khai báo của X trong
câu lệnh S trú trong lệnh S’.
Chiến lƣợc kiểm định dòng dữ liệu đòi hỏi rằng mọi DU đều phải đƣợc phủ ít
nhất một lần.
Kiểm định DU không bảo đảm phủ tất cả các nhánh của chƣơng trình, tuy nhiên
một nhánh không đƣợc phủ bởi DU kiểm định là rất hiếm.
Kiểm định dòng dữ liệu là hữu ích để chọn các đƣờng của chƣơng trình có chứa
lồng các câu lệnh rẽ nhánh if hoặc vòng lặp (for, while, do-while).
2.2.4. Kiểm định vòng lặp
Có bốn loại vòng lặp cần xem xét nhƣ sau:
 Vòng lặp đơn (Simple Loop)


- 20 -
 Vòng lặp lồng (Nested Loop)
 Vòng lặp nối tiếp (Concatenated Loop)
 Vòng lặp phi cấu trúc (Unstructured Loop)

Hình 2.6. Các vòng lặp cơ bản
2.2.4.1 Vòng lặp đơn
Các trƣờng hợp sau nên đƣợc áp dụng đối với các bài kiểm tra vòng lặp đơn.
Giả sử n là cận trên cho phép số lần thực hiện vòng lặp:
1. Bỏ qua vòng lặp

2. Qua vòng lặp một lần
3. Qua vòng lặp m lần, với m < n
4. Qua vòng lặp n - 1, n, n + 1 lần.
Tóm lại ta sẽ kiểm tra các trƣờng hợp qua vòng lặp là 0, 1, giá trị thông thƣờng m
nào đó, n - 1, n và n + 1.
2.2.4.2 Vòng lặp lồng
Phƣơng thức kiểm tra vòng lặp lồng không thể đơn giản mở rộng cách thức của
kiểm tra vòng lặp đơn, bởi vì nó sẽ tốn rất nhiều ca kiểm định. Có thể dùng phƣơng
pháp sau đây:


- 21 -
1. Bắt đầu từ vòng lặp trong cùng. Thiết lập các vòng lặp khác giá trị nhỏ nhất.
2. Thực hiện các kiểm tra vòng lặp đơn (giá trị 1, m, n-1, n) đối với vòng lặp trong
cùng trong khi vẫn giữ các giá trị vòng lặp bên ngoài là nhỏ nhất.
3. Xét tiếp vòng lặp bên ngoài, thực hiện kiểm tra với các giá trị vòng lặp ngoài nó
nhận giá trị nhỏ nhất, vòng lặp bên trong thì nhận giá trị thông thƣờng m nào
đó.
4. Tiếp tục cho đến khi tất cả các vòng lặp đƣợc kiểm tra.
2.2.4.3 Vòng lặp nối tiếp
Có thể đƣợc kiểm tra nhƣ vòng lặp đơn nếu các vòng lặp là độc lập với nhau.
Nếu chúng không độc lập thì có thể áp dụng nhƣ phƣơng thức kiểm tra vòng lặp lồng.

Hình 2.7. Vòng lặp nối tiếp
2.2.4.4 Vòng lặp phi cấu trúc
Loại vòng lặp này không thể hiện phong cách lập trình cấu trúc, nói chung là
nên thiết kế lại mã lệnh để loại bỏ.


- 22 -

Hình 2.8. Vòng lặp phi cấu trúc


2.3 Kiểm định hộp đen
2.3.1 Các kỹ thuật kiểm định hộp đen
Kiểm định hộp đen là một kỹ thuật kiểm định phần mềm chỉ quan tâm cách hoạt
động của hệ thống dựa trên các dữ liệu vào và dữ liệu ra mà không quan tâm cấu trúc
bên trong của hệ thống. Ngƣời kiểm định không có thông tin về cấu trúc chƣơng trình.
Theo phƣơng pháp này ngƣời kiểm định hệ thống dựa trên sự đặc tả các chức năng để
tiến hành kiểm định tính thực thi của chúng có đúng với đặc tả không. Với lý do này
kiểm định hộp đen đƣợc xét bằng kiểm định chức năng. Kỹ thuật kiểm định này cũng
đƣợc gọi là kiểm định cách hoạt động hay kỹ thuật kiểm định hộp mờ đục hoặc hộp
đóng hoàn toàn. Nhƣ vậy kiểm định hộp đen là một kiểm định cách hoạt động và theo
đó việc thiết kế kiểm định cách hoạt động không khác là bao nhiêu từ thiết kế kiểm
định hộp đen và đây là lý do để ta đƣa ra việc thiết kế xây dựng kiểm định hộp đen.




- 23 -
Hình 2.9 dƣới đây cho thấy kiểm định hộp đen không quan tâm đến cấu trúc bên trong
của chƣơng trình mà chỉ quan tâm đến dữ liệu vào (input) và dữ liệu ra (output).





Hình 2.9 Một sự đặc tả đơn giản về kiểm định hộp đen.
Kiểm định hộp đen về cơ bản là dựa vào sự đặc tả của hệ thống, các thiết kế chi

tiết để xây dựng các giá trị đầu vào theo tất cả các yêu cầu chức năng của chƣơng trình
hay còn gọi là thiết kế các trƣờng hợp kiểm định theo đặc tả. Xét về mặt lý thuyết để
tìm hết tất cả các lỗi trong chƣơng trình cần kiểm định thì chúng ta phải kiểm định tất
cả các giá trị đầu vào trong miền giá trị. Nhƣng trong thực tế điều này không thể thực
hiện đƣợc bởi vì chi phí quá cao và tốn nhiều thời gian. Việc xét các trƣờng hợp kiểm
định với một số lƣợng tƣơng đối theo ngẫu nhiên và đa dạng các giá trị dữ liệu vào là
điều có thể "Chấp nhận". Tuy nhiên, theo đó vẫn sẽ gặp phải nhiều hạn chế trong việc
phát hiện lỗi, vấn đề đặt ra cần phải có các giải pháp kỹ thuật thích hợp và thực hiện
theo một quy trình nào đó nhằm kiểm tra phát hiện một cách tốt nhất các lỗi dữ liệu ra
không đúng với đặc tả hay các lỗi dị thƣờng với chi phí và thời gian tiêu tốn ít nhất có
thể cho phép.
Sau khi chuẩn bị các trƣờng hợp kiểm định một cách hợp lý, công việc tiếp theo
là xây dựng chƣơng trình kiểm định để tiến hành kiểm định cho các trƣờng hợp với dự
kiến kết quả dữ liệu ra, cuối cùng là so sánh các kết quả của chƣơng trình cần kiểm
định với đặc tả để đánh giá kết quả kiểm định.