Kiểm thử phần mềm và ứng dụng thiết kế một công cụ kiểm thử tự động

MỤC LỤC
LỜI NÓI ĐẦU ...................................................................................................4
CHƯƠNG 1. GIỚI THIỆU TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM....6
1.1. Khái niệm kiểm thử phần mềm ..............................................................6
1.2. Mục đích của kiểm thử ...........................................................................6
1.3. Các giai đoạn kiểm thử viên nên nghĩ tới trong quá trình kiểm thử ....7
1.4. Các mức kiểm thử phần mềm.................................................................7
1.4.1. Kiểm thử được tiến hành bởi đội ngũ dự án ...................................7
1.4.2. Kiểm thử được tiến hành bởi các cơ quan bên ngoài......................8
1.4.3. Yêu cầu của mỗi mức kiểm thử........................................................8
1.5. Luồng thông tin kiểm thử .......................................................................9
1.6. Thiết kế trường hợp kiểm thử ..............................................................10
CHƯƠNG 2. MỘT SỐ KỸ THUẬT KIỂM THỬ PHẦN MỀM ..................11
2.1. Biểu đồ luồng (Flow Graph) và kiểm thử đường dẫn (Path Testing) .11
2.1.1. Các khái niệm cơ bản của kiểm thử đường dẫn............................11
2.1.1.1. Định nghĩa ................................................................................11
2.1.1.2. Dự đoán lỗi ...............................................................................11
2.1.1.3. Biểu đồ luồng điều khiển..........................................................12
2.1.2. Kiểm thử đường dẫn.......................................................................15
2.1.2.1. Đường dẫn, nút và liên kết.......................................................15
2.1.2.2. Tiêu chuẩn cho sự lựa chọn đường dẫn ..................................16
2.1.2.3. Tiêu chuẩn cho kiểm thử đường dẫn.......................................16
2.1.2.4. Ý nghĩa và các chiến lược chung .............................................17
2.1.2.5. Hiệu quả của kiểm thử đường dẫn ..........................................17
2.2. Kiểm thử luồng giao dịch (Transaction-Flow Testing)........................18
2.2.1. Giới thiệu ........................................................................................18
2.2.2. Luồng giao dịch ..............................................................................18
2.2.2.1. Định nghĩa ................................................................................18
2.2.2.2. Sử dụng.....................................................................................19
2.2.2.3. Thực hiện..................................................................................19
2.2.3.Kỹ thuật kiểm thử luồng giao dịch .................................................20

2.2.3.1. Để có được các luồng giao dịch................................................20
2.2.3.2. Cơ sở dữ liệu kiểm thử .............................................................20
2.2.3.3. Thực hiện..................................................................................20
2.3. Kiểm thử luồng dữ liệu (Data-Flow Testing) .......................................21
2.3.1. Định nghĩa.......................................................................................21
2.3.2. Các mô hình mới – Các cỗ máy luồng dữ liệu ...............................21
2.3.3. Biểu đồ luồng dữ liệu ......................................................................21
2.3.3.1. Trạng thái của đối tượng dữ liệu và sử dụng..........................22

1


2.3.3.2. Các luồng dữ liệu bất thường ..................................................22
2.3.3.3. Biểu đồ trạng thái luồng dữ liệu bất thường...........................23
2.3.4. Mô hình luồng dữ liệu ....................................................................23
2.3.4.1. Các thành phần của mô hình...................................................23
2.3.4.2. Ví dụ: Xét hình 2.10 .................................................................24
2.3.5. Các chiến lược kiểm thử luồng dữ liệu ..........................................25
2.3.5.1. Các thuật ngữ ...........................................................................25
2.3.5.2. Các chiến lược ..........................................................................26
2.4. Kiểm thử miền (Domain Testing).........................................................27
2.4.1. Mô hình ...........................................................................................27
2.4.2. Kích thước miền .............................................................................29
2.4.3. Các miền tốt, miền xấu ...................................................................29
2.4.3.1. Các miền tốt..............................................................................29
2.4.3.2. Các miền xấu ............................................................................31
2.4.4. Dự đoán lỗi......................................................................................31
2.4.5. Chiến lược kiểm thử miền ..............................................................31
2.5. Kiểm thử cú pháp (Syntax Testing)......................................................32
2.5.1. Tổng quan .......................................................................................32

2.5.2. Cú pháp cho các định dạng - Ký hiệu BNF ...................................32
2.5.2.1. Các phần tử ..............................................................................32
2.5.2.2. Các toán tử BNF.......................................................................33
2.5.2.3. Sự lặp lại ...................................................................................33
2.5.2.4. Ví dụ..........................................................................................33
2.5.3. Thiết kế trường hợp kiểm thử........................................................34
2.5.3.1. Chiến lược.................................................................................34
2.5.3.2. Các lỗi cú pháp mức đỉnh, mức trung gian, mức trường .......34
2.5.3.3. Lỗi dấu phân cách....................................................................36
2.5.3.4. Lỗi cú pháp phụ thuộc bối cảnh ..............................................37
2.5.3.5. Lỗi phụ thuộc trạng thái ..........................................................37
2.6. Kiểm thử hộp đen (Black-box Testing) ................................................37
2.6.1. Phân hoạch cân bằng......................................................................39
2.6.2. Phân tích cực biên...........................................................................39
2.6.3. Đoán lỗi ...........................................................................................40
2.6.4. Kỹ thuật biểu đồ nguyên nhân - kết quả .......................................40
2.6.5. Kiểm thử so sánh ............................................................................41
2.7. Kiểm thử hộp trắng (White-box Testing).............................................42
CHƯƠNG 3. CÁC CHIẾN LƯỢC KIỂM THỬ CHO CÁC LẬP TRÌNH
VIÊN VÀ CÁC KIỂM THỬ VIÊN ................................................................43
3.1. Các chiến lược kiểm thử cho các lập trình viên...................................43
3.1.1. Lập trình hợp tác............................................................................43
3.1.2. Sự bảo trì.........................................................................................43
3.1.3. Tự thẩm định ..................................................................................44
3.1.4. Thiết kế trường hợp kiểm thử........................................................44

2


3.1.5. Thứ tự ưu tiên các loại kiểm thử....................................................45

3.2. Các chiến lược cho các kiểm thử viên độc lập .....................................45
3.2.1. Tổng quát ........................................................................................45
3.2.2. Sự thay đổi ngữ nghĩa.....................................................................45
3.2.3. Các thay đổi kiểu ............................................................................47
3.2.4. Các thay đổi về sự biểu diễn...........................................................47
3.2.5. Những sự kết hợp và nạp chồng.....................................................47
3.2.6. Các phương pháp truy xuất khác nhau .........................................48
3.2.7. Các tài nguyên động .......................................................................48
3.2.8. Thay đổi phiên bản .........................................................................49
3.2.9. Đọc mã và các tài liệu thiết kế khác...............................................49
CHƯƠNG 4. ỨNG DỤNG THIẾT KẾ MỘT CÔNG CỤ KIỂM THỬ TỰ
ĐỘNG ..............................................................................................................50
4.1. Giới thiệu ...............................................................................................50
4.2. Thiết kế mô hình tổng thể.....................................................................50
4.3. Xây dựng công cụ..................................................................................53
4.3.1. Không gian tên (Namespace)..........................................................53
4.3.2. .NET Reflection...............................................................................55
4.3.3. Bảng tính (Spreadsheet) và XML ..................................................55
4.3.4. Không gian tên .NET CodeDOM...................................................58
4.3.5. Thiết kế các form ............................................................................60
4.3.5.1. Giao diện chính của công cụ ....................................................60
4.3.5.2. Form Kiểu kiểm thử.................................................................61
4.3.5.3. Form Quyết định kiểm thử tự động/bằng tay .........................61
4.4. Kết quả chạy thử nghiệm......................................................................62
4.4.1. Kiểm thử một assembly – Kiểm thử đơn vị ...................................62
4.4.2. Kiểm thử các tham số được truyền là đối tượng - Kiểm thử tích
hợp ............................................................................................................71
4.4.3. Kiểm thử với nhiều tập dữ liệu kiểm thử ......................................76
4.4.4. Kiểm thử các phương thức nạp chồng...........................................77
4.4.5. Kiểm thử các tham số được truyền là các mảng ...........................79

4.5. Nhận xét, đánh giá kết quả thu được ...................................................80
4.5.1. Cải tiến kiểm thử đơn vị.................................................................80
4.5.2. Tự động tạo dữ liệu kiểm thử.........................................................81
4.5.3. Cách tiếp cận duy nhất cho kiểm thử tích hợp..............................81
4.5.4. Có khả năng cập nhật với những khả năng kiểm thử mới ...........81
4.5.5. Viết test script dựa vào dữ liệu........................................................81
KẾT LUẬN......................................................................................................83
TÀI LIỆU THAM KHẢO...............................................................................84
PHỤ LỤC.........................................................................................................85

3


LỜI NÓI ĐẦU
Công nghệ phần mềm (Software Engineering) là sự áp dụng một cách có
hệ thống, có kỷ luật và định lượng được cho việc phát triển, hoạt động và bảo trì
phần mềm. Ngành học kỹ nghệ phần mềm bao gồm các kiến thức, các công cụ và
các phương pháp cho việc định nghĩa yêu cầu phần mềm, thực hiện các tác vụ
thiết kế phần mềm, xây dựng phần mềm, kiểm thử phần mềm (Software testing)
và bảo trì phần mềm. Kiểm thử phần mềm là một trong những giai đoạn của kỹ
nghệ phần mềm, là giai đoạn mấu chốt trong quy trình phát triển phần mềm nhằm
đảm bảo chất lượng của phần mềm. Trong thời đại ngày nay, khi mà ngành công
nghiệp phần mềm phát triển như vũ bão thì những yêu cầu về chất lượng phần
mềm ngày càng trở nên nghiêm ngặt hơn.
Tuy nhiên thực tế ở Việt Nam và nhiều nước khác, kiểm thử phần mềm
chưa được coi trọng như đúng vai trò của nó. Việc thiết kế kiểm thử và kiểm thử
chưa được tiến hành một cách có hệ thống, có phương pháp. Để có thể nắm vững
và phần nào triển khai ứng dụng về lĩnh vực này, em đã chọn đề tài “Kiểm thử
phần mềm và ứng dụng thiết kế một công cụ kiểm thử tự động” làm đồ án tốt
nghiệp của mình.

Mục đích của đồ án là tìm hiểu, hệ thống các khái niệm cơ bản, các chiến
lược, kỹ thuật kiểm thử phần mềm, trên cơ sở đó xây dựng thử nghiệm một hệ
thống kiểm thử phần mềm đơn giản.
Đồ án gồm 4 nội dung chính như sau:
 Chương 1. Giới thiệu tổng quan về kiểm thử phần mềm.
 Chương 2. Một số kỹ thuật kiểm thử phần mềm.
 Chương 3. Các chiến lược kiểm thử cho các lập trình viên và các kiểm
thử viên.
 Chương 4. Ứng dụng phát triển một công cụ kiểm thử tự động
Hiện nay ở Việt Nam các công cụ, các phần mềm ứng dụng còn chưa được
sử dụng một cách rộng rãi, mỗi phần mềm ứng dụng đểu nhằm đạt được một mục
tiêu là giải quyết một bài toán cụ thể nào đó chứ chưa phải là phần mềm có tính

4


chất thương mại, được sử dụng cho một lớp rộng rãi các lĩnh vực gần nhau, cũng
chưa xuất hiện nhiều việc có các phần mềm cũng nhằm một lớp bài toán nào đó
cạnh tranh với nhau. Trong bối cảnh đó, việc xây dựng các phần mềm kiểm thử
để đánh giá hiệu năng của phần mềm chưa phải là vấn đề cấp bách, song với xu
thế phát triển trong nước cũng như trên thế giới về công nghệ phần mềm, việc
xây dựng các bộ phần mềm kiểm thử, đánh giá tính đúng đắn cũng như hiệu năng
của phần mềm ứng dụng là một việc làm tất yếu sẽ đến. Song trước mắt việc thực
hiện đề tài này còn gặp nhiều khó khăn, vì vậy kết quả nghiên cứu và thực
nghiệm còn có nhiều hạn chế. Em hy vọng rằng trong tương lai có thể tiếp tục
phát triển ý tưởng cũng như xây dựng được sản phẩm kiểm thử đáp ứng được yêu
cầu thực tiễn và hữu ích cho người sử dụng.

5

CHƯƠNG 1. GIỚI THIỆU TỔNG QUAN VỀ KIỂM THỬ
PHẦN MỀM
Mục đích của chương này là đưa ra một cái nhìn tổng thể về kiểm thử phần
mềm: kiểm thử phần mềm là gì, có những loại kiểm thử phần mềm nào, mục đích
của kiểm thử phần mềm là gì và tiến trình kiểm thử phần mềm được tiến hành
như thế nào?
1.1. Khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là khâu mấu chốt để đảm bảo chất lượng phần mềm,
là đánh giá cuối cùng về các đặc tả, thiết kế và mã hoá.
Kiểm thử phần mềm là quá trình chạy thử một ứng dụng để phát hiện lỗi
và xem nó có thoả mãn các yêu cầu đã đặt ra. Trong quá trình phát triển phần
mềm, những người phát triển phần mềm và các kỹ sư kiểm thử cùng làm việc để
phát hiện lỗi và đảm bảo chất lượng sản phẩm. Một sản phẩm phần mềm được
phân phối phải có đầy đủ các chức năng yêu cầu và tương thích với phần cứng
của khách hàng.
Hoạt động kiểm thử ít được các nhà quản lý chú ý vì nó tốn kém, mất thời
gian và hiếm khi phát hiện được lỗi. Hơn nữa, một tổ chức phát triển phần mềm
không chấp nhận chi đến 40% tổng năng lực dự án cho kiểm thử. Trong một số
trường hợp, kiểm thử phần mềm liên quan đến con người (như kiểm soát chuyến
bay, điều khiển lò phản ứng hạt nhân) có thể tốn kém gấp ba đến năm lần tất cả
các bước kỹ nghệ phần mềm khác cộng lại. Kết quả là phần lớn các ứng dụng
không được kiểm thử đầy đủ và được phân phối mà vẫn tiềm ẩn lỗi.
1.2. Mục đích của kiểm thử
Ít lập trình viên thích công việc kiểm thử, thậm chí với thiết kế kiểm thử
còn ít hơn, đặc biệt thiết kế kiểm thử và kiểm thử mất nhiều thời gian hơn là thiết
kế và viết mã.
Những số liệu cho thấy nếu lập trình tốt thì vẫn sẽ có 1-3 lỗi trên 100 câu
lệnh. Vấn đề là phải làm gì để ngăn ngừa và phát hiện lỗi càng sớm càng tốt.

6


Thiết kế kiểm thử và kiểm thử nên tập trung vào ngăn ngừa lỗi. Với khu
vực thiết kế kiểm thử và kiểm thử không ngăn ngừa được lỗi thì chúng cũng nên
phát hiện ra dấu hiệu của lỗi. Các lần kiểm thử nên cung cấp những chuẩn đoán
dễ hiểu để lỗi có thể dễ dàng được sửa. Ngăn ngừa lỗi là mục tiêu đầu tiên của
kiểm thử, ngăn ngừa được một lỗi sẽ tốt hơn là phát hiện rồi sửa lỗi vì khi ngăn
ngừa được lỗi thì sẽ không phải sửa mã. Hơn nữa, không cần phải kiểm tra lại
xem việc sửa lỗi là đúng đắn, không tiêu tốn bộ nhớ, không phá vỡ kế hoạch làm
việc. Có vai trò lớn hơn, thiết kế kiểm thử là một trong những công cụ ngăn chặn
lỗi tốt nhất được biết đến. Mục đích là tạo ra sự kiểm thử có ích để có thể phát
hiện và loại bỏ lỗi trước khi chúng được viết mã. Trên thực tế thiết kế kiểm thử
có thể phát hiện và loại bỏ lỗi tại mọi giai đoạn của quá trình thiết kế phần mềm,
từ ý tưởng đến đặc tả, thiết kế, viết mã và phần còn lại.
1.3. Các giai đoạn kiểm thử viên nên nghĩ tới trong quá trình kiểm thử
Tại sao phải kiểm thử? Mục đích của việc kiểm thử là gì? Tiến trình được
mô tả bởi năm giai đoạn sau:
 Giai đoạn 0: Không có sự khác biệt nào giữa kiểm thử và gỡ lỗi, kiểm
thử để hỗ trợ cho gỡ lỗi.
 Giai đoạn 1: Kiểm thử để cho thấy phần mềm làm việc.
 Giai đoạn 2: Kiểm thử để cho thấy phần mềm không làm việc.
 Giai đoạn 3: Mục đích của kiểm thử là làm giảm những rủi ro nhận
thấy khi phần mềm không làm việc tới mức có thể chấp nhận được.
 Giai đoạn 4: Kiểm thử không phải là quy luật mà là hoạt động trí óc để
thu được phần mềm với rủi ro thấp mà không mất quá nhiều công sức.
1.4. Các mức kiểm thử phần mềm
Các phép kiểm thử có mặt tại các mức khác nhau và được tiến hành bởi
các cá nhân khác nhau trong quá trình phát triển ứng dụng.
1.4.1. Kiểm thử được tiến hành bởi đội ngũ dự án

Được gọi là kiểm thử phát triển (Development tesingt) bao gồm:

7


 Kiểm thử đơn vị (Unit testing): được tiến hành cho mỗi đơn vị mã nhỏ
nhất như hàm, module.
 Kiểm thử tích hợp (Integration testing): kiểm thử mặt logic và xử lý
của các khối, kiểm thử việc truyền tin giữa chúng. Kiểm thử viên sẽ
tiến hành kiểm thử giao diện, sự tương tác giữa các thành phần,
module, cửa sổ.
 Kiểm thử chức năng (Functional testing): kiểm thử ở bất kỳ mức độ
nào (lớp, module, giao diện hay hệ thống) để kiểm tra xem nó có đúng
với các đặc tả hay không?
 Kiểm thử hệ thống (System testing): kiểm thử hệ thống một cách toàn
diện để đánh giá các đặc tả chức năng có được đáp ứng, các thao tác
giao diện có giống thiết kế không?
 Kiểm thử tích hợp hệ thống (System integration testing): kiểm tra hệ
thống có tích hợp đúng với các phần mềm của hãng thứ ba hay các
giao diện của hệ thống khác hay không?
 Kiểm thử sự thực thi (Performance testing): Để kiểm tra hiệu suất của
chương trình có đáp ứng được như mong đợi hay không?
1.4.2. Kiểm thử được tiến hành bởi các cơ quan bên ngoài
Được gọi là đảm bảo chất lượng (Quality Assurance - QA) và kiểm thử
chấp nhận (Acceptance testing). Người ngoài có thể là người sử dụng hay đại
diện người dùng nằm ngoài sự điều khiển và quản lý của người quản lý dự án.
QA testing tương tự system testing về mặt mục đích và cách tiến hành.
Các báo cáo kiểm thử QA được gửi thường xuyên tới người quản lý dự án. Các
QA lập kế hoạch và kiểm tra để đảm bảo các ứng dụng thực hiện tất cả các chức
năng cần thiết. Kiểm thử QA là bước cuối cùng trước khi ứng dụng được sản

xuất đại trà.
1.4.3. Yêu cầu của mỗi mức kiểm thử
Mỗi mức kiểm thử đòi hỏi phải xác định chiến lược kiểm thử. Đó là:
Black box testing hay White box testing:

8


 Black box testing: kiểm tra về mặt chức năng hoặc phi chức năng mà
không tham khảo cấu trúc bên trong của thành phần hay hệ thống. Kết
quả được dự đoán và so sánh với kết quả thực tế để đánh giá mức độ
thành công.
 White box testing: việc kiểm tra dựa trên sự phân tích cấu trúc bên
trong của thành phần hoặc hệ thống đó.
Top-down hay bottom-up:
 Top-down: phương thức kiểm tra sự tích hợp mà các thành phần ở trên
hệ thông cấp bậc được kiểm tra trước, với các thành phần cấp thấp hơn
được xem là phần gốc.
 Bottom-up: việc kiểm tra tích hợp trong đó các thành phần thuộc lớp
thấp nhất được kiểm tra trước, và sau đó được dùng để làm cho việc
kiểm tra các thành phần thuộc lớp cao hơn được dễ dàng. Qui trình này
được lặp lại cho đến khi thành phần ở đầu của cấu trúc được kiểm tra.
Các chiến lược kiểm thử không loại trừ lẫn nhau, sử dụng riêng rẽ hay
đồng thời. Với một ứng dụng phải sử dụng nhiều chiến lược để phát hiện được
hết lỗi. Các chiến lược sau khi được xác định sẽ được áp dụng để tạo các trường
hợp kiểm thử cụ thể.
1.5. Luồng thông tin kiểm thử
Cấu hình
phần mềm

Đánh
giá

Kết quả
kiểm thử

Dữ liệu
tỷ lệ lỗi

Kiểm
thử
Cấu hình
kiểm thử

Lỗi
Gỡ lỗi
Sửa chữa

Kết quả
trông đợi

Mô hình
tin cậy

Hình 1.1.Luồng thông tin kiểm thử

9

Độ tin cậy
dự kiến

Hai lớp vào được cung cấp cho tiến trình kiểm thử:
 Cấu hình phần mềm, bao gồm: bản đặc tả yêu cầu phần mềm, bản đặc
tả thiết kế và chương trình gốc.
 Cấu hình kiểm thử, bao gồm: kế hoạch và thủ tục kiểm thử.
Kiểm thử được tiến hành và tất cả các kết quả đều được đánh giá. Khi dữ
liệu lỗi được phát hiện thì việc gỡ lỗi bắt đầu. Quá trình gỡ lỗi là phần khó được
dự kiến trước của tiến trình kiểm thử, một lỗi chỉ ra sự sai biệt độ 0.01% giữa các
kết quả mong đợi và thực tế có thể mất 1 giờ, 1 ngày, 1 tháng để chuẩn đoán và
sửa chữa.
Sau khi các kết quả kiểm thử được thu thập và đánh giá, cần có một chỉ
dẫn định lượng về chất lượng và độ tin cậy phần mềm. Nếu hay gặp phải những
lỗi nghiêm trọng yêu cầu sửa đổi thiết kế thì chất lượng và độ tin cậy phần mềm
là đáng ngờ, cần phải có thêm các kiểm thử. Còn nếu các chức năng phần mềm
làm việc đúng, lỗi gặp phải dễ sửa thì có thể rút ra một trong hai kết luận:
 Chất lượng và độ tin cậy phần mềm là chấp nhận được.
 Kiểm thử chưa thấy được những lỗi nghiêm trọng. Nếu kiểm thử
không phát hiện được lỗi nào thì có thể cấu hình kiểm thử chưa được
cân nhắc đúng mức và lỗi vẫn còn tiềm ẩn trong phần mềm.
1.6. Thiết kế trường hợp kiểm thử
Thiết kế kiểm thử cho phần mềm và các sản phẩm kĩ nghệ khác có thể khó
khăn như việc thiết kế ban đầu cho chính sản phẩm. Các kỹ sư phần mềm thường
xem kiểm thử như việc giải quyết về sau, xây dựng các trường hợp kiểm thử có
thể “cảm thấy đúng” nhưng hầu như không đảm bảo được tính đầy đủ.

10


CHƯƠNG 2. MỘT SỐ KỸ THUẬT KIỂM THỬ PHẦN

MỀM
Toàn bộ chương này được sử dụng để trình bày các kỹ thuật kiểm thử
thường được sử dụng trong các dự án phần mềm. Còn có rất nhiều kỹ thuật kiểm
thử khác được sử dụng trong quá trình phát triển phần mềm. Tuy nhiên, các kỹ
thuật được trình bày dưới đây là các kỹ thuật cơ bản nhất đối với các kiểm thử
viên hay thậm chí với cả các lập trình viên.
2.1. Biểu đồ luồng (Flow Graph) và kiểm thử đường dẫn (Path Testing)
2.1.1. Các khái niệm cơ bản của kiểm thử đường dẫn
2.1.1.1. Định nghĩa
Path testing là lớp các kỹ thuật kiểm thử dựa trên sự lựa chọn chính xác
tập khả năng kiểm thử trong cả chương trình. Tiêu chuẩn kiểm thử là hoàn hảo
khi tập khả năng được chọn chính xác. Ví dụ: chọn đường dẫn đầy đủ để mỗi câu
lệnh trong mã nguồn được thực hiện ít nhất một lần.
Các kỹ thuật kiểm thử đường dẫn là cổ nhất trong số các kỹ thuật kiểm thử
có cấu trúc được sử dụng tại IBM hơn hai thập niên. Ý tưởng thực hiện mỗi câu
lệnh và mỗi nhánh ít nhất một lần sau vài lần kiểm thử là của những người
nghiên cứu sâu về kiểm thử phần mềm. Chúng cũng là các kỹ thuật đầu tiên được
nghiên cứu tỉ mỉ về lý thuyết. Có nhiều bằng chứng chứng tỏ kiểm thử đường dẫn
được phát hiện và sử dụng một cách độc lập ở rất nhiều nơi khác nhau.
Kiểm thử đường dẫn có thể ứng dụng để kiểm thử đơn vị với phần mềm
mới, yêu cầu kiểm thử viên phải có hiểu biết đầy đủ về cấu trúc của chương trình
và thường được sử dụng bởi những lập trình viên để kiểm tra từng phần trong mã
nguồn. Tác dụng của nó giảm khi kích thước của phần mềm tăng sau mỗi lần
kiểm thử và ít khi được sử dụng cho kiểm thử hệ thống.
2.1.1.2. Dự đoán lỗi
Dự đoán lỗi để nhằm đưa ra sự sai khác khiến phần mềm đi theo một
hướng khác so với những gì được mong đợi. Chẳng hạn, “GO TO X” trong khi
“GO TO Y” là kết quả mong đợi, hay “Nếu A đúng làm việc X, nếu không làm

11

việc Y” thay vì “Nếu A sai …”. Kiểm thử đường dẫn thừa nhận các đặc tả là
đúng và có thể thực hiện được, do đó sẽ không có lỗi xử lý nào khác ảnh hưởng
đến luồng điều khiển, dữ liệu được định nghĩa và truy nhập đúng cách. Các ngôn
ngữ lập trình có cấu trúc ngăn ngừa được nhiều lỗi do đó tác dụng của kiểm thử
đường dẫn với các ngôn ngữ này bị giảm bớt. Ngược lại, mã được viết bằng các
ngôn ngữ bậc thấp như COBOL, FORTRAN và BASIC có tỉ lệ lỗi luồng điều
khiển cao hơn nên không thể thiếu được kiểm thử đường dẫn.
2.1.1.3. Biểu đồ luồng điều khiển
Biểu đồ luồng điều khiển là biểu đồ biểu diễn cấu trúc điều khiển của một
chương trình, sử dụng các thành phần: khối xử lý, quyết định, điểm nối (hình
2.1). Biểu đồ luồng điều khiển cũng tương tự như biểu đồ tiến trình.

Hình 2.2.Các thành phần trong biểu đồ luồng điều khiển
a) Khối xử lý
Một khối xử lý (tiến trình) là một chuỗi các câu lệnh không bị ngắt quãng
bởi các quyết định hay điểm nối. Về mặt hình thức nó là một chuỗi câu lệnh mà
nếu bất kỳ một câu lệnh nào được thực hiện thì tất cả các câu lệnh từ đó cũng
được thực hiện. Một khối xử lý có thể chỉ là một câu lệnh cũng có thể là hàng
trăm câu lệnh.
b) Quyết định và lựa chọn
Một quyết định là một điểm trong chương trình tại đó luồng điều khiển có
thể rẽ nhánh. Ví dụ: lệnh If trong FORTRAN, If-then-else trong PASCAL. Trong
luồng điều khiển hầu hết các quyết định là hai hướng, còn lại một số là ba hướng.
Thiết kế trường hợp kiểm thử với nhánh hai hướng nói chung dễ hơn ba hướng.

12

Một khai báo lựa chọn là một nhánh nhiều đường đi hay nhiều quyết định.
Ví dụ: lệnh nhảy trong Assembly, GOTO trong Fortran hay CASE trong Pascal.
Theo quan điểm từ việc thiết kế kiểm thử thì không có sự khác biệt cơ bản nào
giữa khai báo quyết định và khai báo lựa chọn.
c) Điểm nối
Một điểm nối là một điểm trong chương trình tại đó luồng điều khiển có
thể hợp nhất. Ví dụ: đích của một lệnh nhảy hay bỏ qua trong Assembly, câu lệnh
End-If và Continue trong Fortran, End và Until và các nhãn trong Pascal.
d) Biểu đồ luồng điều khiển và biểu đồ tiến trình
Biểu đồ tiến trình của một chương trình tương tự như biểu đồ luồng nhưng
khác nhau ở một điểm quan trọng: biểu đồ luồng điều khiển không đưa ra chi tiết
của một khối xử lý và không quan tâm có bao nhiêu câu lệnh trong khối khi được
xem như là một tiến trình đơn lẻ, ngược lại, mọi phần của khối xử lý đều được vẽ
ra trong biểu đồ tiến trình, nếu một khối xử lý có 100 bước thì biểu đồ tiến trình
có thể có tới 100 hộp.
Biểu đồ tiến trình là bước đầu tiên để xây dựng biểu đồ luồng điều khiển.
e) Sự phát triển các ký hiệu
Biểu đồ luồng điều khiển chỉ đơn giản để biểu diễn cho cấu trúc của
chương trình. Để hiểu được cách tạo và sử dụng biểu đồ luồng điều khiển, xét ví
dụ sau:
Chương trình viết bằng FORTRAN-ngôn ngữ thiết kế chương trình (PDL):
INPUT X,Y

Z:=Z-1

Z:=X+Y

IF Z=0 GOTO ELL

V:=X-Y

U:=U+1

IF Z>=0 GOTO SAM

NEXT U

JOE: Z:=Z-1

V(U-1):=V(U+1)+U(V-1)

SAM: Z:=Z+V

ELL: V(U+U(V)):=U+V

FOR U=0 TO Z

IF U=V GOTO JOE

V(U),U(V):=(Z+V)*U

IF U>V THEN U:=Z

IF V(U)=0 GOTO JOE

Z:=U
END

Hình 2.3.Chương trình ví dụ

13


Đầu tiên, chuyển chương trình này sang biểu đồ như hình 2.3 - biểu đồ
trình tự cổ điển 1-1.

Hình 2.4. Biểu đồ trình tự 1-1
Vì độ phức tạp tăng lên nên phải thêm các nhãn phụ: LOOP, XX, YY.
Gộp các bước xử lý lại và thay thế chúng bằng một hộp xử lý để thu được
biểu đồ luồng điều khiển.

Hình 2.5. Biểu đồ luồng điều khiển
Hình 2.5 biểu diễn biểu đồ luồng đơn giản hơn:

Hình 2.6. Ký hiệu biểu đồ luồng điều khiển đơn giản

14


Có hai thành phần trong biểu đồ rút gọn là các hình tròn và mũi tên. Một
hình tròn với một hay nhiều mũi tên đi ra là một quyết định, với một hay nhiều
mũi tên đi vào là một điểm nối. Gọi các hình tròn là các nút còn các mũi tên là
các liên kết. Nút thường được đánh số hay gán nhãn bằng nhãn của chương trình.
Tên của các liên kết được tạo nên từ tên của các nút được nối bởi nó. Chẳng hạn
liên kết từ nút 7 đến nút 4 được gọi là liên kết (7,4), trong khi liên kết từ nút 4
đến nút 7 được gọi là liên kết (4,7). Đối với các liên kết song song giữa các cặp
nút ta có thể biểu diễn như sau: (12,13, upper) hoặc (12,13 lower).
Biến đổi cuối cùng được biểu diễn như hình 2.6:

Hình 2.7. Ký hiệu biểu đồ luồng điều khiển đơn giản hơn

Những biểu diễn trên vẫn rất bất tiện, có thể sử dụng biểu diễn bằng danh
sách liên kết như hình 2.7:

Hình 2.8. Ký hiệu biểu đồ luồng điều khiển bằng danh sách liên kết
Mỗi nút đều có tên và có một lối vào trong danh sách cho mỗi liên kết
trong biểu đồ.
2.1.2. Kiểm thử đường dẫn
2.1.2.1. Đường dẫn, nút và liên kết
Một đường dẫn trong chương trình là một chuỗi các câu lệnh hoặc các khai
báo bắt đầu một đầu vào, một điểm nối hay một quyết định và kết thúc ở một

15


điểm khác có thể là một điểm nối, một quyết định hay đầu ra. Một đường dẫn có
thể đi qua nhiều điểm nối, khối xử lý, quyết định một hay nhiều lần.
Đường dẫn lại chứa nhiều đoạn, đoạn nhỏ nhất là một liên kết, nó là một
tiến trình nằm giữa hai nút (như điểm nối-tiến trình-điểm nối, điểm nối-tiến trìnhquyết định, quyết định-tiến trình-quyết định). Một đoạn đường dẫn là một chuỗi
liên tục các liên kết của một đường dẫn nào đó.
2.1.2.2. Tiêu chuẩn cho sự lựa chọn đường dẫn
Có rất nhiều đường giữa đầu vào và đầu ra của một thủ tục thông thường.
Mỗi quyết định làm gấp đối số đường, mỗi vòng lặp nhân số đường lên nhiều lần,
thậm chí một thủ tục nhỏ cũng có thể có rất nhiều đường dẫn. Phương pháp kiểm
thử là kiểm tra tất cả các đường dẫn, nhưng đó vẫn chưa phải là phương pháp
kiểm thử toàn diện bởi vì một lỗi có thể tạo nên các đường dẫn không mong
muốn hay tạo nên các đường không thực hiện được. Và khi tất cả các đường đều
đúng cũng không có nghĩa thủ tục đáp ứng được yêu cầu xử lý. Vậy như thế nào
là kiểm thử đầy đủ?
 Sử dụng tất cả các đường từ đầu vào đến đầu ra.
 Sử dụng mỗi khai báo hay câu lệnh ít nhất một lần.

 Sử dụng tất cả các nhánh và lựa chọn theo mỗi hướng ít nhất một lần.
2.1.2.3. Tiêu chuẩn cho kiểm thử đường dẫn
Bất kỳ một chiến lược kiểm thử đường dẫn nào cũng ít nhất phải thực hiện
mọi câu lệnh và qua các nhánh theo tất cả các hướng. Ba chiến lược (tiêu chuẩn)
trong một lớp các chiến lược có khả năng:
1. Kiểm thử đường dẫn (P∞) - thực hiện tất cả các đường dẫn luồng điều
khiển có thể trong chương trình (hoàn thành kiểm thử 100% đường dẫn). Đây là
tiêu chuẩn mạnh nhất trong lớp các chiến lược kiểm thử đường dẫn, nhưng rất
khó đạt được.
2. Kiểm thử câu lệnh (P1) - Sau vài lần kiểm thử phải thực hiện tất cả các
câu lệnh ít nhất một lần (hoàn thành kiểm thử 100% câu lệnh hay 100% nút). Ký
hiệu tiêu chuẩn này là C1. Đây là tiểu chuẩn yếu nhất trong lớp các chiến lược
kiểm thử.

16


3. Kiểm thử nhánh (P2) - thực hiện một số lần kiểm thử để đảm bảo tất cả
các nhánh khác đều được thực hiện ít nhất một lần (hoàn thành kiểm thử 100%
nhánh hay 100% liên kết). Ký hiệu tiêu chuẩn này là C2.
2.1.2.4. Ý nghĩa và các chiến lược chung
Phạm vi nhánh và câu lệnh ngày nay được xem như là yêu cầu kiểm thử
tối thiểu. Phạm vi câu lệnh được thiết lập như là yêu cầu kiểm thử tối thiểu trong
chuẩn kiểm thử đơn vị của IEEE. Phạm vi nhánh và câu lệnh cũng được sử dụng
hơn hai thập niên như là những yêu cầu kiểm thử tối thiểu tại IBM và nhiều công
ty máy tính và phần mềm khác. Kinh nghiệm chung cho thấy những điểm sau:
 Không kiểm thử một đoạn mã sẽ để lại một phần lỗi trong chương
trình tương đương với kích thước của đoạn mã không được kiểm thử.
 Các đường dẫn có khả năng cao thường được kiểm thử kỹ lưỡng trừ
khi hệ thống làm việc đúng đắn. Các đường dẫn có khả năng cao chưa

kiểm thử được ở mức đơn vị sẽ còn được kiểm thử trong kiểm thử tích
hợp hay kiểm thử hệ thống.
 Các lỗi logic và suy nghĩ mập mờ tỉ lệ nghịch với khả năng thực hiện
đường dẫn.
 Người thiết kế thủ tục có thể thấy khả năng thực hiện của một đường
dẫn theo chủ quan nhưng thực tế chỉ có người phân tích mới thấy.
 Ước lượng chủ quan tầm quan trọng của một đoạn mã của lập trình
viên phụ thuộc vào kinh nghiệm, óc thẩm mỹ, sự hiểu biết của anh ta.
2.1.2.5. Hiệu quả của kiểm thử đường dẫn
Khoảng 65% lỗi có thể được phát hiện trong kiểm thử đơn vị khi thực hiện
theo các phương pháp kiểm thử đường dẫn. Khi kết hợp với các phương pháp
khác như giới hạn kiểm tra trong các vòng lặp thì tỉ lệ lỗi bắt được là từ 50% đến
60%. Kiểm thử đường dẫn có hiệu quả đối với phần mềm không có cấu trúc hơn
phần mềm có cấu trúc. Các thống kê cũng cho thấy hạn chế khi dùng kiểm thử
đường dẫn như là kỹ thuật duy nhất.

17


2.2. Kiểm thử luồng giao dịch (Transaction-Flow Testing)
2.2.1. Giới thiệu
Biểu đồ luồng điều khiển thảo luận ở trên là mô hình thường được sử dụng
nhất trong thiết kế kiểm thử. Sử dụng khái niệm tương tự về các thành phần và
phương pháp ở trên cho một loại biểu đồ luồng khác, biểu đồ luồng giao dịch, để
tạo nên mô hình hoạt động của chương trình đưa đến kiểm thử chức năng. Biểu
đồ luồng giao dịch là mô hình cấu trúc hoạt động của chương trình.
2.2.2. Luồng giao dịch
2.2.2.1. Định nghĩa
Một phiên giao dịch theo quan điểm của người sử dụng là một đơn vị công
việc, bao gồm một dãy các thao tác được tạo nên bởi hệ thống, con người, hay

các thiết bị bên ngoài hệ thống. Các phiên giao dịch được tạo ra như là kết quả
của một số hoạt động bên ngoài, khi kết thúc nó không còn trong hệ thống ngoại
trừ ở dạng lược sử bản ghi. Một phiên giao dịch của hệ thống thông tin trực tuyến
có thể bao gồm các bước (nhiệm vụ) sau:
1. Chấp nhận đầu vào
2. Xác nhận đầu vào
3. Gửi tín hiệu xác nhận tới nơi yêu cầu
4. Xử lý đầu vào
5. Tìm kiếm tệp tin
6. Yêu cầu các điều hướng từ người sử dụng
7. Chấp nhận đầu vào
8. Xác nhận đầu vào
9. Xử lý yêu cầu
10. Cập nhật tệp tin
11. Truyền thông tin đầu ra
12. Ghi lại phiên giao dịch vào nhật ký và huỷ giao dịch
Người sử dụng chỉ nhìn thấy kịch bản này như một phiên giao dịch đơn.
Hầu hết các hệ thống trực tuyến xử lý rất nhiều loại giao dịch, ví dụ: một
máy thu ngân tự động có thể được sử dụng để rút, gửi, thanh toán hoá đơn, hay

18


chuyển tiền. Hơn thế, các thao tác khác có thể được thực hiện như kiểm tra tài
khoản, ghi tài khoản, bỏ tài khoản… Mặc dù các thao tác có thể khác nhau giữa
các giao dịch, nhưng hầu hết các giao dịch đều có các thao tác chung, chẳng hạn
máy thu ngân tự động bắt đầu các giao dịch bằng thao tác xác nhận thẻ của người
sử dụng và mã số của tài khoản.
2.2.2.2. Sử dụng
Các luồng giao dịch không thể thiếu để xác định yêu cầu của các hệ thống

phức tạp, đặc biệt là các hệ thống trực tuyến. Một hệ thống lớn như điều khiển
không lưu hay hệ thống đường bay có tới hàng nghìn luồng giao dịch, chúng
được biểu diễn bởi các biểu đồ luồng khá đơn giản, rất nhiều trong số chúng có
một đường dẫn đơn thẳng. Các vòng lặp được sử dụng để yêu cầu làm lại sau khi
người sử dụng nhập sai. Chẳng hạn, hệ thống ATM cho phép người sử dụng làm
lại ba lần và sẽ thu hồi thẻ ở lần thứ tư.
2.2.2.3. Thực hiện
Sự thực hiện của một luồng giao dịch thường ẩn chứa trong bản thiết kế
cấu trúc điều khiển của hệ thống hay được kết hợp với cơ sở dữ liệu.
Hình 2.8 biểu diễn một luồng giao dịch và sự thực hiện tương ứng của
chương trình tạo nên nó.

Hình 2.9. Luồng giao dịch và sự thực hiện

19


2.2.3.Kỹ thuật kiểm thử luồng giao dịch
2.2.3.1. Để có được các luồng giao dịch
Các hệ thống phức tạp xử lý nhiều giao dịch phức tạp khác nhau cần có
các luồng giao dịch được biểu diễn rõ ràng hay được viết thành tài liệu. Có
những cách biểu diễn khác như dùng các biểu đồ HIPO và các lưới Petri, các
luồng giao dịch cũng có thể ánh xạ vào chương trình nên chúng cũng có thể được
biểu diễn bằng PDL. Nếu sử dụng các cách biểu diễn này và việc biểu diễn là
đúng thì sẽ dễ dàng tạo nên các luồng giao dịch. Mục đích là có được phác thảo
những gì xảy ra với các giao dịch - phác thảo sự phát triển của các hành động.
2.2.3.2. Cơ sở dữ liệu kiểm thử
Khoảng 30%-40% công sức thiết kế kiểm thử luồng giao dịch là việc thiết
kế và bảo trì cơ sở dữ liệu kiểm thử. Có hai lỗi chính trong thiết kế cơ sở dữ liệu.
Đầu tiên, do không biết có một kiểm thử cơ sở dữ liệu sẽ được thiết kế nên các

lập trình viên và kiểm thử viên tự thiết kế cơ sở dữ liệu của mình nhưng lại
không thích hợp. Kết quả là mỗi kiểm thử viên cần tới sự trợ giúp của toàn bộ hệ
thống. Thông thường thì những kiểm thử viên độc lập cần nhiều thiết kế kiểm thử
tỉ mỉ hơn các lập trình viên, vì vậy yêu cầu phải thành lập các nhóm kiểm thử.
Lúc này lỗi thứ hai xảy ra. Để tránh lặp lại sự lộn xộn trên, sẽ có một cơ sở dữ
liệu toàn diện thoả mãn tất cả yêu cầu kiểm thử. Một hệ thống thông thường với
khoảng nửa triệu dòng mã nguồn có thể cần tới bốn hoặc năm cơ sở dữ liệu
không tương thích hỗ trợ cho kiểm thử. Việc thiết kế các cơ sở dữ liệu này quan
trọng không kém việc thiết kế các cấu trúc dữ liệu của hệ thống, yêu cầu những
nhà thiết kế phải có kinh nghiệm, năng lực, khéo léo, tỉ mỉ - kinh nghiệm trong cả
thiết kế hệ thống và thiết kế kiểm thử.
2.2.3.3. Thực hiện
Cố gắng thực hiện từ đầu và đừng lo lắng nếu cần đến hàng trăm lần kiểm
thử để đạt được phạm vi luồng giao dịch C1 + C2. Làm đi làm lại các giao dịch
không chỉ một lần mà hàng trăm lần trong khi thực hiện dự án. Kiểm thử luồng
giao dịch với mục tiêu đạt được C1 + C2 thường mang lại một số lượng lớn các
trường hợp kiểm thử.

20


2.3. Kiểm thử luồng dữ liệu (Data-Flow Testing)
2.3.1. Định nghĩa
Data-Flow Testing là lớp các chiến lược kiểm thử dựa trên sự lựa chọn
các đường dẫn qua luồng điều khiển của chương trình để khảo sát dãy các sự
kiện liên quan tới trạng thái của các đối tượng dữ liệu.
2.3.2. Các mô hình mới – Các cỗ máy luồng dữ liệu
Các máy tính ngày nay hầu hết đều là các cỗ máy Von Neumann, kiến trúc
đặc trưng cho khả năng hoán đổi việc lưu trữ các lệnh và dữ liệu trong cùng các
đơn vị bộ nhớ. Kiến trúc Von Neumann thông thường thực thi một lệnh tại một

thời điểm theo dãy vi lệnh sau:
1. Lấy lệnh từ bộ nhớ
2. Thông dịch lệnh
3. Lấy các toán hạng
4. Xử lý
5. Lưu kết quả (có thể là trong các thanh ghi)
6. Tăng bộ đếm của chương trình (con trỏ nhảy tới lệnh tiếp theo)
7. GOTO 1
Cỗ máy Von Neumann thuần tuý chỉ có một tập vòng điều khiển để thông
dịch lệnh, một tập các thanh ghi để xử lý dữ liệu, một đơn vị thực thi. Thiết kế
này hướng đến sự thực thi tuần tự từng lệnh một.
Trái lại, các cỗ máy song song đồ sộ có nhiều cơ cấu để thực hiện các
bước từ 1-7 ở trên và do đó có thể lấy một vài lệnh và/hoặc đối tượng một cách
song song. Nó cũng có thể thực hiện đồng thời các phép toán số học và lôgic trên
các đối tượng dữ liệu khác nhau.
2.3.3. Biểu đồ luồng dữ liệu
Biểu đồ luồng dữ liệu là biểu đồ chứa các nút và các liên kết có hướng.
Mặc dù đang thực hiện kiểm thử luồng dữ liệu nhưng không nhất thiết phải sử
dụng chúng mà có thể sử dụng biểu đồ luồng điều khiển được chú thích để diễn
tả những gì đang xảy ra với các đối tượng dữ liệu.

21


2.3.3.1. Trạng thái của đối tượng dữ liệu và sử dụng
Các đối tượng dữ liệu có thể được tạo ra, sử dụng, và huỷ bỏ, chúng có thể
được sử dụng theo hai cách khác nhau: trong một phép tính hay như một phần
của một quyết định. Các ký tự sau chỉ ra các khả năng này:
d - được định nghĩa, được tạo, được thiết lập, v.v
k - bị huỷ, không xác định, được giải phóng

u - sử dụng cho cái gì đó
c - sử dụng trong một phép tính
p - sử dụng trong một quyết định
2.3.3.2. Các luồng dữ liệu bất thường
Một sự bất thường được chỉ ra bởi hai chữ cái thể hiện thứ tự các hành
động. Có 9 kết hợp có thể của 3 chữ cái k, d, u:
dd – có thể không có hại nhưng mập mờ - định nghĩa đối tượng hai lần mà
không xen vào sử dụng.
dk – có thể là lỗi. Tại sao định nghĩa một đối tượng mà không sử dụng nó.
du - trường hợp bình thường. Đối tượng được tạo ra và được sử dụng
kd – tình huống thông thường. Đối tượng bị huỷ rồi được định nghĩa lại.
kk – không có hại nhưng có thể có lỗi. Có chắc đối tượng đã bị huỷ.
ku – lỗi. Đối tượng không tồn tại - giá trị không xác định hay vô hạn.
ud – thông thường không phải là một lỗi.
uk – tình huống thông thường.
uu – tình huống thông thường.
Ngoài các trường hợp trên còn có 6 trường hợp ký tự đơn lẻ:
-k: huỷ một biến không tồn tại.
-d: đây chỉ là định nghĩa đầu tiên trong đường dẫn.
-u: có thể bất thường.
k-: không bất thường. Việc làm cuối cùng của đường dẫn là để huỷ biến.
d-: có thể bất thường. Biến được định nghĩa nhưng không được sử dụng;
nhưng đây có thể là một định nghĩa toàn cục hay bên trong một thủ tục có định
nghĩa các biến cho các thủ tục khác.

22


u-: không bất thường. Biến được sử dụng nhưng chưa bị huỷ.
Dấu gạch ngang ở trước để chỉ ra không có gì đáng chú ý xảy ra trước

hành động dọc theo đầu vào – ra của đường dẫn quan tâm, dấu gạch ngang theo
sau để chỉ không có gì xảy ra từ điểm quan sát tới đầu ra.
2.3.3.3. Biểu đồ trạng thái luồng dữ liệu bất thường
Mô hình luồng dữ liệu bất thường quy định mỗi đối tượng có thể ở 1 trong
4 trạng thái sau:
K – không xác định, bị huỷ trước đó, không tồn tại.
D - được định nghĩa nhưng không được sử dụng cho bất cứ cái gì.
U – đã được sử dụng trong phép tính hay trong quyết định.
A - bất thường.
Hình 2.9 là các ví dụ về biểu đồ trạng thái luồng dữ liệu bất thường:

Hình 2.10. Biểu đồ luồng dữ liệu bất thường
2.3.4. Mô hình luồng dữ liệu
2.3.4.1. Các thành phần của mô hình
Quy tắc tạo nên mô hình:
1. Mỗi khai báo có một nút với tên duy nhất. Mỗi nút có ít nhất một liên
kết ngoài và một liến kết trong ngoại trừ các nút ra không có liên kết ngoài và các
nút vào không có các liên kết trong.

23


2. Các nút ra là các nút tượng trưng đặt tại đầu các mũi tên đi ra của các
khai báo kết thúc (END, RETURN) để hoàn tất biểu đồ. Tương tự, các nút vào
được đặt tại các khai báo bắt đầu (BEGIN).
3. Liên kết ngoài của các khai báo đơn được đánh trọng số bởi một dãy
thích hợp các hành động của luồng dữ liệu cho khai báo đó. Ví dụ, với lệnh gán
A:= A + B trong hầu hết các ngôn ngữ được đánh trọng số cd hay ckd cho biến
A. Dãy chữ cái phải có thứ tự thích hợp để mã sẽ được thực hiện cho biến đó.
4. Các nút quyết định (ví dụ: IF – THEN – ELSE, DO WHILE, CASE)

được đánh chữ cái p trên mọi liên kết ngoài thích hợp với liên kết ngoài đó.
5. Mọi dãy các khai báo đơn (ví dụ một dãy các nút với một liên kết
trong và một liên kết ngoài) có thể được thay thế bởi một cặp nút có các trọng số
liên kết kết hợp.
6. Nếu có một vài luồng dữ liệu hoạt động trên một liên kết với một biến
chỉ ra thì trọng số của liên kết được ký hiệu bởi một chuỗi các hành động trên
liên kết đó.
7. Ngược lại, một liên kết với một vài luồng dữ liệu hoạt động trên nó có
thể được thay thế bởi một dãy các liên kết tương đương, mỗi liên kết có nhiều
nhất một luồng dữ liệu hoạt động cho một biến bất kỳ.
2.3.4.2. Ví dụ: Xét hình 2.10
Hình a là biểu đồ luồng điều khiển đã biết.
Hình b biểu diễn cho luồng điều khiển này để chú giải các luồng dữ liệu
của các biến X và Y.
Hình c biểu diễn biểu đồ luồng điều khiển tương tự để chú giải cho biến Z.
Z được định nghĩa lần đầu tiên bằng lệnh gán ở liên kết đầu tiên. Z được sử dụng
trong một quyết định (Z>=0) tại nút 3, vì thế cả hai liên kết ngoài đều được đánh
là p. Có thêm hai thể hiện nữa của quyết định sử dụng ở nút 8 và 9.
Luồng dữ liệu chú giải cho biến V được biểu diễn bởi hình d. Phép gán
V(U),U(V):=(Z+V)*U được viết gộp. Nó được mô hình hoá thành hai khai báo
riêng biệt và kết quả có tổng cộng 3 chữ c cho biến này tại liên kết (6,7).

24


Hình 2.11. Các biểu đồ luồng điều khiển
2.3.5. Các chiến lược kiểm thử luồng dữ liệu
2.3.5.1. Các thuật ngữ
 Một đoạn đường dẫn định nghĩa rõ ràng (đối với biến X) là một dãy
liên kết được nối với nhau mà X được định nghĩa trên liên kết đầu tiên,

không được định nghĩa lại hay huỷ bỏ ở bất kỳ một dãy liên kết con
nào của đoạn đường dẫn đó.
 Một đoạn đường dẫn vòng lặp tự do là một đoạn đường dẫn có mỗi nút
được đi qua không quá một lần.
 Một đoạn đường dẫn đơn giản là một đoạn đường dẫn có nhiều nhất
một nút được đi qua hai lần.
 Một đường dẫn du từ nút i đến nút k là một đoạn đường dẫn nếu liên
kết cuối cùng có một phép tính sử dụng biến X thì đường dẫn là đơn
giản và định nghĩa rõ ràng, nếu nút áp chót là j thì đường dẫn là (i, p,
q, … , r, s, t, j, k) và liên kết (j, k) có một quyết định, đường dẫn từ i
tới j vừa là vòng lặp tự do vừa là định nghĩa rõ ràng.

25