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

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.


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.


Đượ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

Đá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

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

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

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

 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

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

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

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

đượ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,