TÌM HIỂU CÁC KĨ THUẬT KIỂM THỬ PHẦN MỀM

Ƣ
Ệ

VIỆ

ỀN THÔNG
Ệ

Ồ ÁN

ƢƠ

Ề

CÔNG NGHỆ PH N MỀM

ề tài 04
TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PH N MỀM
Giảng viên hƣớng dẫn: Thầy Lƣơng

ạnh Bá.

Sinh viên thực hiện: Nhóm 01.
1.

han ăng

ƣng.

2.

Nguyễn Thị Thanh Vi.

3.

Nguyễn Trung Hiếu.

4.

Lê ăn

uân.

Lớp: Công nghệ phần mềm K52
Hà Nội, 10/2010


Báo cáo Đại cương Công nghệ phần mềm
Ả
Ngày thay đổi

Ậ

Mô tả thay đổi

Ổ
Người thực hiện

Phiên bản mới

5/10/2010

Bắt đầu viết

Cả nhóm

1.0

27/10/2010

Sửa đổi

Cả nhóm

1.1

Nhóm 01- Lớp công nghệ phần mềm K52

Page 2


Báo cáo Đại cương Công nghệ phần mềm

hần 1:
1.

Các kỹ thuật kiểm thử phần mềm. ........................................................................................... 7
1.1.

Các khái niệm cơ bản. ...................................................................................................... 7

1.1.1.

Mục đích kiểm thử. ................................................................................................... 8

1.1.2.

Nguyên tắc kiểm thử. ................................................................................................ 8

1.1.3.

Khả năng kiểm thử. ................................................................................................... 9

1.2.

Kiểm thử hộp trắng. ....................................................................................................... 11

1.3.

Kiểm thử theo lộ trình cơ sở........................................................................................... 12

1.3.1.

Đồ thị luồng. ........................................................................................................... 12

1.3.2.

Cyclomatic Complexity (độ đo phức tạp vòng). ..................................................... 16

1.3.3.

Kế thừa ca kiểm thử. ............................................................................................... 17

1.3.4.

Ma trận đồ thị. ......................................................................................................... 21

1.4.

Kiểm thử cấu trúc điều khiển. ........................................................................................ 23

1.4.1.

Kiểm thử điều kiện.................................................................................................. 23

1.4.2.

Kiểm thử luồng dữ liệu. .......................................................................................... 25

1.4.3.

Kiểm thử vòng lặp. ................................................................................................. 28

1.5.

Kiểm thử hộp đen. .......................................................................................................... 28

1.5.1.

Kiểm thử dựa vào đồ thị (Graph-Based). ................................................................ 29

1.5.2.

Phương pháp phân đoạn tương đương. ................................................................... 31

1.5.3.

Phương pháp phân tích giá trị biên. ........................................................................ 33

1.5.4.

Kiểm thử so sánh. ................................................................................................... 33

1.5.5.

Kiểm thử mảng trực giao. ....................................................................................... 34

1.6.

Kiểm thử cho các môi trường, kiến trúc và ứng dụng chuyên ngành. ........................... 37

1.6.1.

Kiểm thử giao diện đồ họa người dùng: ..................................................................... 37

1.6.2.

Kiểm thử kiến trúc Client/Server: .............................................................................. 37

1.6.3.

Kiểm thử tài liệu và các thiết bị trợ giúp. ................................................................... 37

1.6.4.

Kiểm thử cho hệ thống thời gian thực: ....................................................................... 38

1.7.
2.

Ụ LỤ
iới thiệu về các kỹ thuật và chiến lƣợc kiểm thử phần mềm ................ 7

Tổng kết.......................................................................................................................... 40

Các chiến lược kiểm thử. ....................................................................................................... 41

Nhóm 01- Lớp công nghệ phần mềm K52

Page 3


Báo cáo Đại cương Công nghệ phần mềm
2.1.

Những đặc điểm cơ bản một chiến lược kiểm thử. ........................................................ 42

2.1.3.

Chiến lược kiểm thử phần mềm. ............................................................................. 44

2.1.4.

Tiêu chuẩn để hoàn thiện kiểm thử. ........................................................................ 46

2.2.

Những vấn đề nảy sinh từ chiến lược. ............................................................................ 48

2.3.

Kiểm thử đơn vị. ............................................................................................................ 48

2.3.1.

Các quy tắc xem xét kiểm thử đơn vị. .................................................................... 48

2.3.2.

Một số thủ tục kiểm thử đơn vị. .............................................................................. 51

2.4.

Kiểm thử tích hợp........................................................................................................... 52

2.4.1.

Tích hợp từ trên xuống............................................................................................ 53

2.4.2.

Tích hợp dưới lên. ................................................................................................... 54

2.4.3.

Kiểm thử hồi quy. ................................................................................................... 55

2.4.4.

Chú thích trên kiểm thử tích hợp. ........................................................................... 56

2.4.5.

Tài liệu kiểm thử tích hợp. ...................................................................................... 56

2.5.

Kiểm thử chấp nhận. ...................................................................................................... 58

2.5.1.

Tiêu chuẩn của kiểm thử chấp nhận. ...................................................................... 58

2.5.2.

Xem xét cấu hình. ................................................................................................... 58

2.5.3.

Kiểm thử Alpha và Beta. ........................................................................................ 58

2.6.

Kiểm thử hệ thống. ......................................................................................................... 59

2.6.1.

Kiểm thử phục hồi. ................................................................................................. 60

2.6.2.

Kiểm thử bảo mật.................................................................................................... 60

2.6.3.

Kiểm thử căng thẳng. .............................................................................................. 60

2.6.4.

Kiểm thử thực hiện. ................................................................................................ 61

2.7.

Nghệ thuật gỡ rối. ........................................................................................................... 61

2.7.2.

Sự nghiên cứu tâm lý .............................................................................................. 63

2.7.3.

Phương pháp tiếp cận gỡ lỗi. .................................................................................. 63

hần 2: iới thiệu về một số công cụ kiểm thử và khảo sát quy trình kiểm thử
tại công ty phần mềm Fsoft. ............................................................................................... 65
3.
3.1.

Giới thiệu một số bộ kiểm thử phổ biến hiện nay. ............................................................. 65
Defect Management system. .......................................................................................... 65

Nhóm 01- Lớp công nghệ phần mềm K52

Page 4


Báo cáo Đại cương Công nghệ phần mềm
3.1.1.
3.2.

Giới thiệu công cụ BugZero.................................................................................... 65

Một số công cụ kiểm thử chức năng. ............................................................................. 65

3.2.1.

Rational Robot tester............................................................................................... 66

3.2.2.

Quick Test Pro. ....................................................................................................... 66

3.2.3.

Công cụ kiểm thử trong Visual Studio 2008. ......................................................... 68

3.3.

Kết luận. ......................................................................................................................... 77
Khảo sát quy trình kiểm thử phần mềm của công ty Fsoft. ............................................... 78

4.
4.1.

Giới thiệu về công ty Fsoft. ............................................................................................ 78

4.2.

Một số nguyên tắc chung trong khâu kiểm thử phần mềm tại Fsoft. ............................. 79

4.2.1.

Lý do để công ty áp dụng kiểm thử. ....................................................................... 79

4.2.2.

Khái niệm về QA-QC. ............................................................................................ 79

4.2.3.

Một số điều kiện được đưa ra khi kiểm thử tại FSoft ............................................. 80

4.2.4.

Những kỹ năng mà một kiểm thử viên (tester) cần phải có. ................................... 80

4.2.5.

Các quy định và ý nghĩa của kiểm thử. ................................................................... 80

4.2.6.

Kiểm thử cần có đầu vào và đầu ra hợp lý. ............................................................. 81

4.2.7.

Quá trình kiểm thử cần được thực hiện theo mô hình vòng lặp. ............................ 83

4.2.8.

Giới thiệu một số công cụ được sử dụng để kiểm thử tại Fsoft. ............................. 83

4.2.9.

Kịch bản lỗi (defect). .............................................................................................. 84

4.2.10. Sự áp dụng của các kỹ thuật kiểm thử tại Fsoft. ..................................................... 85
4.2.11. Xây dựng tài liệu kiểm thử. .................................................................................... 88
4.2.12. Quản lý sự thay đổi và quản lý điều khiển. ............................................................. 88
4.3.

Tổng kết khảo sát. .......................................................................................................... 90

Các tài liệu tham khảo................................................................................................................... 91

Nhóm 01- Lớp công nghệ phần mềm K52

Page 5


Báo cáo Đại cương Công nghệ phần mềm

Lời nói đầu
Hiện nay, kiểm thử phần mềm đang đóng một vai trò rất quan trọng quyết định
thành công của một sản phẩm phần mềm. Có một số phần mềm do không thông qua khâu
kiểm thử hoặc kiểm thử sơ sài nên khi sử dụng họ phải chịu những nguy cơ rất lớn bị
khách hàng kiện do phần mềm bị lỗi mà chưa được phát hiện khi đang thiết kế.
Một câu hỏi luôn được đặt ra cho các nhà quản lý dự án khi xây dựng phần mềm
đó là làm thế nào để quá trình kiểm thử diễn ra hiệu quả nhất, phát hiện ra được những lỗi
nghiêm trọng nhất và kịp thời sửa chữa? Với mong muốn được tìm hiểu những phương
pháp thiết kế một quy trình kiểm thử tốt, nhóm 01 chúng em xin được lựa chọn đề tài
“Những kỹ thuật kiểm thử phần mềm”. Chúng em xin chân thành cảm ơn thầy Lương
Mạnh Bá, thầy đã giúp chúng em có một kiến thức nền tảng để nghiên cứu đề tài này. Do
đây là lần nhóm được làm việc cùng nhau đầu tiên nên chúng em sẽ không tránh khỏi
những sai sót. Chúng em rất mong được thầy và các bạn đọc chia sẻ góp ý để giúp tài liệu
ngày một hoàn thiện hơn. Nhóm chúng em gồm 4 thành viên:
PHÂN CÔNG CÔNG VIỆC
Họ tên
Phan Đăng Hưng

Nguyễn Thị Thanh Vi

MSSV
20071484

20073430

Công việc

Liên hệ

Tìm hiểu một số công cụ kiểm thử và

0983193089

khảo sát quy trình kiểm thử tại công ty

(PDHung3012@g

phần mềm Fsoft

mail.com)

Tìm hiểu về một số công cụ kiểm thử và

01688329541

khảo sát quy trình kiểm thử tại công ty
phần mềm Fsoft
Nguyễn Trung Hiếu

20073653

Tìm hiểu các kỹ thuật và chiến lược kiểm

0936949145

thử phần mềm
Lê Văn Huân

20071295

Tìm hiểu các kỹ thuật và chiến lược kiểm

0168213395

thử phần mềm

Hà Nội, ngày 22-10-2010.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 6


Báo cáo Đại cương Công nghệ phần mềm

hần 1:

iới thiệu về các kỹ thuật và chiến lƣợc kiểm

thử phần mềm
Toàn bộ nội dung phần 1 được nhóm chúng em tìm hiểu và dịch lại từ cuốn sác (A
practical of Software Engineering- PAOSE) của tác giả R.Pressman tái bản lần thứ 5.

1. Các kỹ thuật kiểm thử phần mềm.
Sự phát triển của hệ thống phần mềm bao gồm mỗi chuỗi các qui trình mà khả năng
có sai sót của con người là rất cao. Các lỗi có thể xảy ra ngay từ khi bắt đầu của tiến trình
khi đối tượng được khai báo. Bởi vì không thể đảm bảo được tính hoàn hảo của phần
mềm, phát triển phần mềm được đi kèm với một hoạt động đảm bảo chất lượng.
Kiểm thử phần mềm là một thành phần chủ chốt của bảo đảm chất lượng phần mềm.
Kiểm thử là tiến trình (và là nghệ thuật) nhằm phát hiện lỗi bằng việc xem xét lại đặc tả,
thiết kế và mã hoá. Kiểm thử là mấu chốt của đảm bảo chất lượng phần mềm.
Sự tăng lên trông thấy của phần mềm như là một hệ thống và sự mất mát khi phần
mềm không hoạt động kích thích cho việc phải có sự kiểm thử hoàn hảo, được tổ chức
tốt. Là bất thường khi một tổ chức phát triển phần mềm có thể sử dụng tới 30 đến 40%
của toàn bộ dự án cho kiểm thử. Thực tế, thời gian cho công việc kiểm thử lên tới 3 đến 5
lần của tất cả các bước phát triển phần mềm còn lại!
Trong phần này, chúng tôi thảo luận về các đặc điểm cở bản của kiểm thử phần mềm
và kỹ thuật thiết kế ca kiểm thử (test case – TC). Thiết kế ca kiểm thử tập trung vào một
tập các kỹ thuật cho việc tạo các ca kiểm thử bao trùm lên toàn bộ mục đích cần kiểm
thử. Trong phần 2, chiến lược kiểm thử và debug phần mềm được giới thiệu.

1.1.

ác khái niệm cơ bản.

Kiểm thử là một điều thú vị. Trong suốt các hoạt động phát triển phần mềm từ trước
đó, kỹ sư đã xây dựng phần mềm từ các khái niệm trừu tượng tới một sản phẩm hoàn
thiện. Bây giờ là công việc kiểm thử. Kỹ sư xây dựng một chuỗi các ca kiểm thử nhằm
đánh đổ phần mềm đã được xây dựng. Thực tế, kiểm thử là một bước trong quá trình phát

triển phần mềm mà có thể xem là bước phá hoại hơn là bước tạo dựng.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 7


Báo cáo Đại cương Công nghệ phần mềm
Các kỹ sư phần mềm là những con người muốn xây dựng, không muốn phá hoại.
Kiểm thử đòi hỏi người phát triển loại bỏ các nhận thức trước đó của một phần mềm
chính xác vừa phát triển và cố gắng tìm ra các lỗi một cách khách quan.
1.1.1. ục đích kiểm thử.
Mục đích kiểm thử là để tìm ra một cách có hệ thống các tầng lỗi khác nhau và thực
hiện điều đó với một lượng thời gian và công sức ít nhất có thể.
Nếu kiểm thử được thực hiện thành công, tức là nó sẽ tìm ra được lỗi trong phần
mềm. Lợi ích thứ hai của kiểm thử là nó chỉ ra được các chức năng của phần mềm được
thực hiện ra sao với từng điều kiện cụ thể, các thuộc tính và yêu cầu thực thi xuất hiện thế
nào. Thêm vào đó, dữ liệu thu thập được từ kiểm thử cung cấp ngầm định sự tin cậy của
phần mềm và chất lượng phần mềm. Nhưng kiểm thử không thể chỉ ra lỗi ở đâu, nó chỉ
có thể chi ra rằng phần mềm có lỗi. Đây là một điều cần ghi nhớ về kiểm thử.
1.1.2. guyên tắc kiểm thử.
Trước khi ứng dụng phương pháp để thiết kế ca kiểm thử hiệu quả, một kỹ sư phần
mềm cần hiểu nguyên tắc cơ bản của kiểm thử. Các nguyên tắc đó là:
Mọi kiểm tra nên đƣợc dò vết từ yêu cầu khách hàng. Như ta thấy, mục đích của
kiểm thử là để phát hiện lỗi. Nó kéo theo rằng hầu hết các lỗi nghiêm trọng (từ quan điểm
của khách hàng) là những lỗi làm cho dự án thất bại khi đối chiếu với yếu cầu khách
hàng.

Các kiểm tra cần đƣợc lên kế hoạch chu đáo trƣớc khi bắt đầu. Lên kế
hoạch kiểm thử (Chương 18) có thể bắt đầu ngay khi mô hình yêu cầu được hoàn thành.

Định nghĩa chi tiết của các ca kiểm thử có thể bắt đầu ngay khi thiết kế mô hình hoàn tất.
Do đó, mọi kiểm tra có thể được lên kế hoạch và thiết kế trước khi bắt đầu code.

Nguyên tắc Pareto ứng dụng cho kiểm thử phần mềm. Nói ngắn gọn, nguyên
tắc Pareto cho rằng 80% mọi lỗi bắt được thông qua kiểm thử sẽ có vẻ dò vết được từ
20% mọi thành phần của chương trình. Tất nhiên, vấn đề là tách các thành phần đó ra
riêng biệt và cần kiểm tra chu đáo chúng.

Kiểm thử nên bắt đầu từ các thành phần nhỏ dần tới các thành phần lớn.
Nói chung, các kiểm thử đầu tiên được lên kế hoạch và thực thi trên các thành phần nhỏ
lẻ. Trong quá trình kiểm thử, dần dần tập trung vào kiểm thử tích hợp và kiểm thử toàn
hệ thống.

Kiểm thử thấu đáo là không thể. Số lượng hoán vị tính toán cho thậm chí một
chương trình kích cỡ vừa là cực kì lớn (xem 17.2). Do đó, không thể nào thực thi mọi tổ
hợp trong kiểm tra. Tuy nó, có thể xem xét cấu trúc logic chương trình để đảm bảo rằng

Nhóm 01- Lớp công nghệ phần mềm K52

Page 8


Báo cáo Đại cương Công nghệ phần mềm
mọi điều kiện trong thiết kế các mức thành phần được thỏa mãn.

ể đƣợc kết quả tốt nhất, kiểm thử nên đƣợc chỉ đạo bởi một bên thứ ba
độc lập. Như đã nói, kỹ sư phần mềm làm ra hệ thống không phải là người tốt nhất để
thực hiện việc kiểm thử hệ thống.
1.1.3. hả năng kiểm thử.
Trong hoàn cảnh lý tưởng, kỹ sư phần mềm thiết kế một chương trình, một hệ thống,

hay một sản phẩm với khả năng kiểm thử đi kèm. Điều này cho phép các cá nhân khác
nhau thiết kế các ca kiểm thử dễ dàng. Vậy khả năng kiểm thử là gì? Đó đơn giản là sự dễ
dàng của một chương trình được kiểm thử. Đôi khi các nhà lập trình giúp đỡ cho quá
trình kiểm thử bằng cách đưa ra các danh sách đánh dấu điểm mấu chốt trong thiết kế,
tính năng, …, rất hữu ích cho quá trình kiểm thử.
Danh sách đánh dấu dưới đây cung cấp một tập các tính chất có thể dẫn tới một phần
mềm kiểm thử được.

Khả năng hoạt động.
 Hệ thống có ít lỗi kỹ thuật.
 Không có lỗi kỹ thuật nào làm ngưng sự thực thi của kiểm thử.
 Sản phẩm được phân chia thành các tầng chức năng.

Khả năng quan sát.
 Đầu ra khác nhau được tạo từ mỗi đầu vào
 Các trạng thái hệ thống và các biến được hiển thị hoặc truy vấn được trong quá
trình thực thi.
 Các trạng thái hệ thống cũ và các biến được hiển thị hoặc truy vấn được.
 Mọi nhân tố ảnh hưởng tới đầu ra được hiển thị.
 Các đầu ra sai được phát hiện dễ dàng.
 Các lỗi bên trong được tự động phát hiện thông qua cơ chế tự kiểm tra.

Các lỗi bên trong được tự động báo cáo.
Khả năng kiểm soát.
 Mọi đầu ra có thể được tạo ra thông qua tổ hợp các đầu vào
 Mọi code được thực thi thông qua một số tổ hợp đầu vào

Nhóm 01- Lớp công nghệ phần mềm K52

Page 9

Báo cáo Đại cương Công nghệ phần mềm
 Các trạng thái phần mềm và phần cứng và các biến được điều khiển trực tiếp bởi
kỹ sư kiểm thử.
 Dạng đầu vào và đầu ra là thống nhất.
 Các kiểm thử có thể tự động, tự tái tạo, chuyên môn hóa một cách thuận tiện

Khả năng phân tích đƣợc.
 Hệ thống phần mềm được xây dựng từ các module độc lập.
 Module phần mềm có thể được kiểm thử độc lập

Sự đơn giản.
 Chức năng đơn giản, nghĩa là tập các tính năng phải thỏa mãn yêu cầu tối thiểu
của yêu cầu.
 Cấu trúc đơn giản, nghĩa là kiến trúc được modul hóa để giới hạn sự lan truyền lỗi
 Code đơn giản, nghĩa là một chuẩn code được áp dụng cho sự dễ dàng bảo trì và
kế thừa.

Tính bền vững.





Các thay đổi tới phần mềm là không thường xuyên.
Các thay đổi tới phần mềm được kiểm tra.
Các thay đổi tới phần mềm không được không thỏa mãn các ca kiểm thử đã có.
Phần mềm phục hồi tốt khi bị hỏng.

Khả năng hiểu đƣợc.








Thiết kễ phải dễ hiểu
Sự phụ thuộc giữa bên trong, bên ngoài và các thành phần chung phải dễ hiểu
Các thay đổi tới thiết kế được thông báo.
Tài liệu kỹ thuật có thể truy cập được ngay.
Tài liệu kỹ thuật được tổ chức tốt.
Tài liệu kỹ thuật là rõ ràng và chi tiết.
Tài liệu kỹ thuật là chính xác.

Thế còn về chính các kiểm thử? Các tính chất của một kiểm thử tốt là:
1. Một kiểm thử tốt có khả năng cao tìm ra lỗi. Để đạt được điều này, người kiểm
thử phải hiểu phần mềm và thử phát triển một viễn cảnh rằng phần mềm hỏng như
thế nào. Lý tưởng thì một tập các lớp lỗi được xây dựng. Ví dụ, một lớp lỗi tiềm
tàng trong một GUI là sự thất bại nhận diện vị trí con chuột phù hợp. Một tập các

Nhóm 01- Lớp công nghệ phần mềm K52

Page 10


Báo cáo Đại cương Công nghệ phần mềm
kiểm thử cần được thiết kế để làm việc với con chuột trong sự cố gắng tìm kiếm

lỗi nhận diện ví trí con chuột.
2. Một kiểm thử tốt không dƣ thừa. Thời gian kiểm thử và tài nguyên bị giới hạn.
Không có lý do nào trong việc dựng một kiểm thử có cùng một mục đích như một
kiểm thử khác. Mỗi kiểm thử nên có một mục đích riêng (thậm chí nó chỉ khác
nhau chút ít). Ví dụ, một modulle phần mềm SafeHome (thảo luận ở chương trước
) được thiết kế để nhận diện password người dùng để kích hoạt hay ngừng kích
hoạt hệ thống. Để phát hiện lỗi trong đầu vào password, người kiểm thử thiết kế
một chuỗi các kiểm thử nhập vào một chuỗi các password. Xác thực và không xác
thực passwords được đưa vào từ các kiểm thử riêng rẽ. Tuy nhiên, mỗi đầu vào ấy
nên ở các dạng thất bại khác nhau. Ví dụ như, password sai 1234 không nên được
chấp nhận trong hệ thống mà nhận 8080 làm password đúng. Nếu nó chấp nhận,
kiểm thử phát hiện được lỗi. Một đầu vào kiểm thử khác là 1235, cũng có cùng
mục đích như 1234 và như vậy là trùng lặp. Tuy nhiên, đầu vào 8081 hoặc 8180
có khác nhau một tí so với đầu vào kiểm thử 1234 ở trên, bởi nó có thể ở dạng lỗi
là một password sai gần đúng (phần mềm có thể có cơ chế hỗ trợ lấy lại mật khẩu
với dạng mật khẩu gần đúng chẳng hạn).
3. Một kiểm thử tốt phải là “giống tốt”. Trong một tập các kiểm thử có mục đích
tương tự nhau, thời gian và tài nguyên hạn chế có thể cho phép thực thi một tập
con của tập đó. Trong các trường hợp như vậy, một kiểm thử có khả năng phát
hiện lỗi cao nhất nên được sử dụng.
4. Một kiểm thử tốt nên không quá đơn giản và cũng không quá phức tạp. Mặc
dầu thỉnh thoảng có thể chấp nhận việc nối một chuỗi kiểm thử trong một ca kiểm
thử, các chuỗi kiểm thử thường che mất lỗi (không biết lỗi phát sinh từ đầu, bắt lỗi
sai, …). Tổng quát, mỗi kiểm thử nên được thực thi riêng biệt.

1.2.

iểm thử hộp trắng.

Kiểm thử hộp trắng, đôi khi gọi là kiểm thử hộp-trong-suốt, là một phương pháp thiết

kế ca kiểm thử sử dụng cấu trúc điều khiển của thiết kế thủ tục để thừa kế các ca kiểm
thử. Sử dụng phương pháp kiểm thử hộp trắng, kỹ sư phần mềm có thể thừa kế các ca
kiểm thử mà (1) đảm bảo rằng mọi thành phần độc lập trong một module đều được duyệt
qua ít nhất một lần (2) duyệt qua mọi quyết định logic trên cả 2 hướng đúng và sai, (3)
thực thi mọi vòng lặp và các biên trong biên hoạt động, và (4) duyệt qua các dữ liệu cấu
trúc bên trong để đảm bảo tính xác thực.
Một câu hỏi có lý được đặt ra ở đây: “Tại sao phải tiêu tốn thời gian và năng lượng lo
lắng về các logic nhỏ lẻ khi chúng ta có thể tốt hơn đảm bảo rằng các yêu cầu của chương
trình đã được đảm bảo?” Lý do là:
Lỗi logic và các giả sử sai lệch tỷ lệ nghịch với xác suất một phần chương trình được
thực thi. Các lỗi có thể phát sinh khi chúng ta thiết kế và bổ sung các chức năng, điều

Nhóm 01- Lớp công nghệ phần mềm K52

Page 11


Báo cáo Đại cương Công nghệ phần mềm
kiện, hoặc điều khiển ngoài luồng chính. Có thể mọi tiến trình chính đều hoạt động tốt,
trong khi các tiến trình trong trường hợp đặc biệt lại thất bại.
Chúng ta thường cho răng một phần logic thường ít khi được thực hiện trong khi thực
tế, nó được thực thi thường xuyên. Luồng logic của chương trình đôi khi không theo như
trực giác của ta, nghĩa là các giả sử theo cảm giác của chúng ta về luồng điều khiển và dữ
liệu có thể dẫn ta tới thiết kế lỗi được phát hiện khi phần đó được kiểm tra.
Các lỗi ngữ pháp và ngẫu nhiên. Khi một chương trình được dịch thành mã máy, có
khả năng một vài lỗi xuất hiện. Hầu hết được phát hiện bởi cơ chế phát hiện lỗi cú pháp,
nhưng một số không được phát hiện cho tới khi kiểm thử bắt đầu. Những trường hợp này
thường xảy ra khi tồn tại một phần logic bị che khuất bởi luồng chính.
Mỗi lý do trên đây cung cấp một lý lẽ để thực hiện việc kiểm thử hộp trắng. Kiểm thử
hộp đen, dù có tốt đến thế nào, có thể bỏ sót các loại lỗi ở trên. Kiểm thử hộp trắng có

nhiều khả năng tìm ra chúng.

1.3.

iểm thử lộ trình cơ sở.

Kiểm thử hướng lộ trình cơ sở (basis path testing) là một kỹ thuật kiểm thử hộp trắng
được đề xuất lần đầu bởi Tom McCabe. Phương pháp lộ trình cơ sở cho phép người thiết
kế ca kiểm thử kế thừa cấu trúc logic phức tạp của thiết kế sản phẩm và sử dụng sự đo
lường này như là một hướng dẫn để xác định các tập các đường đi được thực thi. Các ca
kiểm thử nhận được từ việc thực thi tập nền tảng đó và đảm bảo thực thi mọi câu lệnh
trong chương trình ít nhất một lần trong suốt quá trình kiểm thử.
1.3.1. ồ thị luồng.
Trước khi phương pháp lộ trình cơ sở được giới thiệu, một ghi chú đơn giản đại diện
cho luồng điều khiển, gọi là đồ thị luồng( hoặc bản đồ chương trình) được giới thiệu. Đồ
thị luồng miêu tả luồng điều khiển logic sử dụng các ghi chú như ở hình 1.1. Mỗi một cấu
trúc xây dựng (tham khảo chương 16- tài liệu PAOSE của tác giả R.Pressman) có ký hiệu
đồ thị luồng tương ứng.
Để làm rõ cách sử dụng một đồ thị luồng, ta xem xét thiết kế chương trình miêu tả ở
hình 1.2A. Ở đây, một sơ đồ luồng được sử dụng để mô tả cấu trúc điều khiển chương
trình. Hình 1.2B ánh xạ sơ đồ luồng thành một đồ thị luồng tương ứng (giả sử rằng không
có điều kiện phức tạp nào trong các hình thoi điều kiện trong sơ đồ luồng). Mỗi hình tròn
trong hình 1.2B gọi là một nốt đồ thị luồng, tượng trưng cho một hoặc một số câu lệnh
được thực hiện liên tiếp kề nhau. Mỗi chuỗi các hộp tiến trình và một hình tthoi quyết
định có thể ánh xạ tới một nốt. Mũi tên trong đồ thị luồng được gọi là cạnh hay đường
dẫn, tương trưng cho luồng điều khiển và tương tự như mũi tên trong sơ đồ luồng. Một
cạnh phải kết thúc ở một nốt, cho dù nốt đó không đại diện cho bất kì câu lệnh thực thi
nào (vd, xem ký hiệu cho cấu trúc if-then-else). Các khoảng bao bởi các cạnh và nốt được
gọi là các vùng. Khi đếm các vùng, ta coi vùng nằm ngoài đồ thị cũng là một vùng.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 12


Báo cáo Đại cương Công nghệ phần mềm
Khi các điều kiện phức hợp bị bắt gặp trong một thiết kế chương trình, phân tích sơ
đồ luồng trở nên khá phức tạp. Một điều kiện phức hợp xảy ra khi một hoặc nhiều phép
toán boolean (OR, AND, NAND, NOR) hiện diện trong câu lệnh. Trong hình 1.3, đoạn
PDL dịch tới đồ thị luồng như vậy. Chú ý rằng một nốt riêng biết được tạo cho mỗi điều
điện a và b trong mệnh đề IF a OR b. Mỗi nốt chứa một điều kiện được gọi là các
predicate node và được đánh dấu bởi một hoặc nhiều cạnh phát ra từ chúng.

Hình 1.1 ồ thị luồng

Nhóm 01- Lớp công nghệ phần mềm K52

Page 13


Báo cáo Đại cương Công nghệ phần mềm

(A)

Nhóm 01- Lớp công nghệ phần mềm K52

Page 14


Báo cáo Đại cương Công nghệ phần mềm

Hình 1.2 Sơ đồ luồng (trên ( )) và đồ thị luồng (dƣới ( )) tƣơng ứng

Nhóm 01- Lớp công nghệ phần mềm K52

Page 15


Báo cáo Đại cương Công nghệ phần mềm

Hình 1.3 ác điều kiện logic phức tạp
1.3.2. Cyclomatic Complexity (độ phức tạp lặp).
Cyclomatic Complexity là một sự đo lường phần mềm cung cấp các đo lường tính
toán được của logic chương trình. Khi được sử dụng trong ngữ cảnh của phương pháp
kiểm tra tập đường đi, giá trị được tính cho cyclomatic complexity định nghĩa số các
thành phần độc lập trong tập lộ trình của chương trình và cung cấp chúng ta một cận trên
số các kiểm thử cần thực hiện để đảm bảo rằng mọi câu lệnh đều được duyệt qua ít nhất
một lần.
Một hướng độc lập là bất kì hướng nào trong chương trình mà đưa vào ít nhất một tập
mới các câu lệnh hoặc một điều kiện mới. Trong đồ thị luồng, một hướng độc lập phải đi
qua ít nhất một cạnh không trùng lặp trước khi hướng được xác định. Ví dụ, một tập các
hướng độc lập trong đồ thị luồng mô tả ở 1.2B là
hướng 1: 1-11
hướng 2: 1-2-3-4-5-10-1-11
hướng 3: 1-2-3-6-8-9-10-1-11
hướng 4: 1-2-3-6-7-9-10-1-11
Chú ý rằng mỗi hướng mới có thên cạnh mới. Hướng
1-2-3-4-5-10-1-2-3-6-8-9-10-1-11
không được xem là một hướng độc lập vì nó chỉ là sự kết hợp của các hướng riêng lại
và không tìm thêm được bất kì cạnh mới nào.

Các hướng 1, 2, 3, 4 tạo thành một tập nền tảng cho đồ thị luồng trong hình 1.2B. Có
nghĩa là, nếu các kiểm thử được thiết kế để bắt buộc thực thi các hướng này mọi câu lệnh
trong chương trình sẽ được đảm bảo thực thi ít nhất một lần và mọi điều kiện sẽ được

Nhóm 01- Lớp công nghệ phần mềm K52

Page 16


Báo cáo Đại cương Công nghệ phần mềm
thực thi trong cả phần đúng và phần sai. Không nên cho rằng tập nền tảng là duy nhất.
Thưc tế, một số các tập nền tảng khác nhau có thể tồn tại với một thiết kế chương trình.
Làm sao để biết được có bao nhiêu hướng nền tảng? Tính toán cyclomatic complexity
cung cấp cách tính.
Cyclomatix complexity có một cơ sở trong định lý đồ thị cung cấp việc hữu ích cho
đo lường phần mềm. Sự phức tạp được tính toán bằng 3 cách:
1. Số các vùng của đồ thị luồng tương ứng với cyclomatic complexity.
2. Cyclomatic complexity, V(G), cho một đồ thị luồng, G, được xác định là
V(G) = E – N + 2, trong đó E là số các cạnh trong đồ thị luồng, N là số các nốt
trong đồ thị luồng.
3. Cyclomatic complexity, V(G), cho một đồ thị luồng, G, cũng được xác định
bởi V(G) = P + 1, trong đó P là số các predicate node trong đồ thị luồng G.
Trở lại hình 17.2B, cyclomatic complexity có thể được tính toán sử dụng giải thuật ở
trên:
1. Đồ thị luồng có 4 vùng
2. V(G) = 11 cạnh – 9 nốt + 2 = 4.
3. V(G) = 3 predicate nodes + 1 = 4.
Như vậy, cyclomatic của đồ thị luồng trong hình 1.2B là 4.
1.3.3.

ế thừa ca kiểm thử.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 17


Báo cáo Đại cương Công nghệ phần mềm

Hình 1.4.

DL cho thiết kế ca kiểm thử với các nốt đƣợc xác định

Phương pháp kiểm tra phần nền tảng có thể ứng dụng cho môt thiết kế chương trình
hoặc source code. Trong phần này, chúng tôi giới thiệu kiểm thử hướng nền tảng như là
một chuỗi các bước. Thủ tục average, mô tả ở hình 17.4, được sử dụng làm ví dụ để hình
dung mỗi bước trong phương thức thiết kế ca sử dụng. Chú ý rằng average, mặc dầu là
một giải thuật rất đơn giản, chứa nhiều điều kiện và vòng lặp. Các bước sau đây có thể
được ứng dụng để kế thừa tập nền tảng:
1. Sử dụng thiết kế và code như là một cơ sở, vẽ các đồ thị luồng tương ứng. Một đồ
thị luồng được tạo sử dụng ký hiệu và các quy tắc giới thiệu ở chương 16 cuốn
sách PAOSE của tác giả R.Pressman. Quay trở lại PDL cho average trong hình
1.4, một đồ thị luồng được tạo bằng cánh đánh số các câu lệnh PDL ánh xạ tới các
nốt đồ thị luồng tương ứng. Đồ thị luồng tương ứng ở hình 1.5.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 18

Báo cáo Đại cương Công nghệ phần mềm
2. Xác định cyclomatic complexity của đồ thị luồng thu được. Cyclomatic V(G)
được xác định bằng việc ứng dụng giải thuật mô tả ở phần 1.4.2 sau đây. Chú ý
rằng V(G) có thể được xác định khi chưa phát triển đồ thị luồng bằng cách đếm
mọi câu lệnh điều kiện trong PDL (với thủ tục average, các điều kiện là 2) và thêm
1. Ở hình 1.5,
V(G) = 6 vùng
V(G) = 17 cạnh – 13 nốt + 2 = 6
V(G) = 5 predicate node + 1 = 6
3. Xác định một tập nền tảng các hướng độc lập. Giá trị V(G) cung cấp số các hướng
độc lập trong cấu trúc điều khiển của chương trình. Trong trường hợp với thủ tục
average, có 6 hướng:
phần 1: 1-2-10-11-13
phần 2: 1-2-10-12-13
phần 3: 1-2-3-10-11-13
phần 4: 1-2-3-4-5-8-9-2-…
phần 5: 1-2-3-4-5-6-8-9-2-…
phần 6: 1-2-3-4-5-6-7-8-9-2-…
Dấu … ở phần 4,5,6 ngầm định rằng bất kì phần nào còn lại của cấu trúc điều
khiển đều được. Trong trường hợp này, nốt 2,3,5,6 và 10 là predicate nodes.
4. Chuẩn bị các ca kiểm thử để thực thi từng hướng trong tập cơ sở. Dữ liệu cần được
chọn sao cho điều kiện ở các predicate nodes tương đương với số lượng hướng
được kiểm tra. Các ca kiểm thử thỏa mãn tập điều kiện kể trên là:

Nhóm 01- Lớp công nghệ phần mềm K52

Page 19


Báo cáo Đại cương Công nghệ phần mềm

Hình 1.5.

ồ thị luồng cho thủ tục average

Kiểm thử phần 1:
value(k) = giá trị hợp lên, k value(i) = -999 với
Kết quả mong muốn: trùng bình đúng dựa vào k giá trị và tổng.
Chú ý: phần 1 không thể được kiểm thử độc lập nhưng phải được kiểm thử như là một
phần của phần 4,5,6.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 20


Báo cáo Đại cương Công nghệ phần mềm
Kiểm thử phần 2:
value(1) = -999
Kết quả mong muốn: average = -999; các biến khác ở giá trị mặc định
Kiểm thử phần 3:
Thử xử lý 101 hoặc nhiều giá trị hơn.
100 giá trị cần được xác thực.
Kết quả mong muốn: như ca kiểm thử 1
Kiểm thử phần 4:
value(i) = đầu vào hợp lệ với
value(k) < giá trị nhỏ nhất với
Kết quả mong muốn: trung bình đúng dựa trên k giá trị và tổng.
Kiểm thử phần 5:

value(i) = đầu vào hợp lệ với i
value(k) > giá trị lớn nhất với
Kết quả mong muốn: giá trị trung bình đúng dựa vào n giá trị và tổng.
Kiểm thử phần 6:
value(i) = giá trị hợp lệ với
Kết quả mong muốn: giá trị trung bình đúng dựa vào n giá trị và tổng.
Mỗi ca kiểm thử được thực thi và so sánh với kết quả mong muốn. Một khi mọi ca
kiểm thử được hoàn thành, người kiểm thử có thể chắc chắn rằng mọi câu lệnh trong
chương trình được thực thi ít nhất một lần.
Cần chú ý rằng vài hướng độc lập (vd, phần 1 trong ví dụ trên) không thể được kiểm
tra riêng rẽ. Bởi vì, sự kết hợp dữ liệu đòi hỏi đi qua hướng không thể có được từ luồng
bình thường của chương trình. Trong các trường hợp này, những hướng này được kiểm
tra như là một phần của kiểm thử phần khác.
1.3.4. a trận đồ thị.
Thủ tục để lấy ra từ đồ thị luồng và thậm chị từ một tập các đường đi cơ sở được xác
định phải tuân theo một cơ chế. Để phát triển một công cụ phần mềm trong kiểm thử
hướng nền tảng, một cấu trúc dữ liệu, gọi là ma trận đồ thị, có thể rất hữu ích.
Một ma trận đồ thị là một ma trận vuông mà kích thước của nó bằng số các nốt trong
đồ thị luồng. Mỗi hàng và cột tương ứng với một nốt được xác định, và mỗi ô trong ma
trận chỉ sự kết nối (cạnh) giữa các nốt. Một ví dụ đơn giản của đồ thị luồng và ma trận đồ
thị tương ứng của nó được cho ở hình 1.6.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 21


Báo cáo Đại cương Công nghệ phần mềm

Hình 1.6

a trận đồ thị tƣơng ứng với một đò thị luồng

Ở hình này, mỗi nốt trong đồ thị luồng được xác định với các chữ số, trong khi mỗi
cạnh được định danh bởi chữ cái. Một chữ cái được đặt vào mỗi ô của ma trận tương ứng
với sự kết nối giữa 2 nốt. Ví dụ, nốt 3 được nối với nốt 4 bởi cạnh b.
Tới thời điểm này, đồ thị ma trận không gì hơn là một bảng chỉ dẫn cho đồ thị luồng.
Tuy nhiên, bằng cách thêm vào trong số cho mỗi ô ma trận, ma trận luồng có thể trở
thành một công cụ hữu hiệu cho việc đánh giá cấu trúc điều khiển chương trình trong
suốt quá trình kiểm thử. Trọng số cung cấp thông tin thêm về luồng điều khiển. Ở dạng
đơn giản nhất, trong số là 1 (nếu một kết nối tồn tại) và 0(nếu không tồn tại). Nhưng
trọng số có thể được gán bằng một số cách hữu ích hơn:





Xác xuất một cạnh được thực thi
Thời gian thực hiện khi đi qua cạnh đó
Bộ nhớ cần thiết khi đi qua cạnh đó.
Tài nguyên cần sử dụng khi đi qua cạnh đó.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 22


Báo cáo Đại cương Công nghệ phần mềm

Hình 1.7

a trận kết nối

Để hình dung, ta sử dụng dạng đơn giản nhất để ngầm định kết nối (0 hoặc 1). Ma
trận đồ thị ở hình 1.6 được vẽ lại như ở hình 1.7. Mỗi chữ cái được thay thế bởi 1, ngầm
định rằng kết nối tồn tại. Các kết nối có trọng số là 0 được loại bỏ khỏi hình vẽ cho dễ
nhìn. Khi này, ma trận đồ thị có tên khác là ma trận kết nối. Mỗi hàng với 2 hoặc nhiều ô
chứa số 1 đại diện cho một predicate node.
Beizer cung cấp cái nhìn hoàn chỉnh về các giải thuật có thể được ứng dụng trong ma
trận đồ thị. Với các kỹ thuật đó, phân tích cần thiết cho thiết kế kiểm thử có thể từng phần
hoặc hoàn toàn tự động.

1.4.

iểm thử cấu trúc điều khiển.

Nói chung, cách tạo các bộ giá trị kiểm thử để kiểm thử được 100% các trường hợp có
thể xảy ra với một chương trình gọi là kỹ thuật kiểm thử theo luồng điều khiển. Kỹ thuật
kiểm thử theo lộ trình cơ sở mô tả ở phần 1.3 là một trong số các kỹ thuật kiểm thử cấu
trúc điều khiển. Mặc dù kiểm thử phần nền tảng là đơn giản và hiệu quả cao, nhưng nó
không đầy đủ. Trong phần này, các kỹ thuật khác của kiểm thử cấu trúc điều khiển được
thảo luận. Các kiểm thử bổ sung này tăng cường chất lượng cho kiểm thử hộp trắng.
1.4.1. iểm thử điều kiện.
Kiểm thử điều kiện là một phương pháp thiết kế ca kiểm thử thực thi các điều kiện
logic chứa trong một module chương trình. Một điều kiện đơn giản là một giá trị boolean
hoặc một mệnh đề quan hệ, có thể đến với toán tử NOT. Một mệnh đề quan hệ có dạng

Nhóm 01- Lớp công nghệ phần mềm K52

Page 23

Báo cáo Đại cương Công nghệ phần mềm
E1 <relational-operator> E2
<,

trong đó E1, E2 là các biểu thức đại số và <relational-operator> là một trong các ký tự:
, =, , > hoặc . Một điều kiện phức hợp là sự kết hợp của hai hoặc nhiều điều kiện

đơn giản, toán tử boolean, và dấu ngoặc. Ta giả sử răng toán tử boolean được chấp nhận
trong điều kiện phức hợp bao gồm OR(|), AND(&) và NOT. Một điều kiện không có
mệnh đề quan hệ được xem là một mệnh đề boolean.
Nếu một điều kiện là sai, khi đó ít nhất một hướng trong điều kiện là sai. Cho nên, các
loại lỗi trong một điều kiện bao gồm:

khác).





Toán từ boolean sai (không chính xác, thiếu hoặc thêm các toán tử boolean
Lỗi biến boolean
Lỗi sử dụng ngoặc
Lỗi toán tử quan hệ
Lỗi biểu thức đại số

Phương pháp kiểm thử điều kiện tập trung vào kiểm tra mỗi điều kiện trong chương
trình. Chiến lược kiểm thử điều kiện (bàn đến sau) có 2 ưu điểm. Một, đo lường sự bao
quát của việc kiểm thử một điều kiện là đơn giản. Thứ hai, kiểm thử điều kiện trong một

chương trình cung cấp sự định hướng cho các kiểm thử khác trong chương trình.
Mục đích của kiểm thử điều kiện là để phát hiện không chỉ các lỗi trong các điều kiện
của một chương trình mà còn các lỗi khác trong chương trình. Nếu một tập kiểm thử cho
một chương trình P là hiệu quả cho việc phát hiện lỗi trong các điều kiện chứa trong P, nó
có nghĩa gần với việc tập kiểm thử này cũng hiệu quả cho việc phát hiện các lỗi khác
trong P. Thêm nữa, nếu một chiến lược kiểm thử là hiệu quả cho việc phát hiện lỗi trong
một điều kiện, nó cũng có nghĩa gần như là chiến lược này cũng hiệu quả cho việc phát
hiện lỗi trong chương trình.
Một số lượng các chiến lược kiểm thử điều kiện đã được đề xuất. Kiểm thử theo
nhánh có lẽ là chiến lượng kiểm thử điều kiện đơn giản nhất. Với một điều kiện phức hợp
C, nhánh true và false của C và mỗi điều kiện đơn giản trog C cần thết được thực thi ít
nhất một lần.
Kiểm thử theo miền đòi hỏi ba tới bốn kiểm thử để theo sát một mệnh đề quan hệ. Với
một mệnh đề quan hệ có dạng
E1 <relational-operator> E2
ba kiểm thử cần thiết để làm cho giá trị E1 lớn hơn, bằng, hoặc bé hơn E2. Nếu
<relational-operator> là sai và E1 và E2 đúng, ba kiểm tra này đảm bảo rằng việc phát

Nhóm 01- Lớp công nghệ phần mềm K52

Page 24


Báo cáo Đại cương Công nghệ phần mềm
hiện được toán tử sai. Để phát hiện lỗi trong E1, E2, một kiểm thử làm cho giá trị của E1
lớn hơn hoặc bé hơn E2 cần được phân biệt giữa 2 giá trị này càng nhỏ càng tốt.
Cho một mệnh đề boolean với n biến, mọi kiểm thử 2n có thể là cần thiết (n > 0).
Chiến lược này có thể phát hiện lỗi toán tử boolean, biến, và ngoặc, nhưng nó chỉ dễ thưc
hiện với n nhỏ.
Kiểm thử cho mệnh đề boolean cũng được kế thừa. Với một mệnh đề boolean đơn

giản (một mệnh đề boolean mà trong đó mỗi biến boolean xuất hiện chỉ một lần) với n
biến boolean (n > 0), ta có thể dễ dạng tạo một tập kiểm thử với nhỏ hơn 2n kiểm thử sao
cho tập kiểm thử này đảm bảo việc phát hiện các lỗi toán tử boolean và cũng hiệu quả
cho việc phát hiện các lỗi khác.
Tai[TAI89] đề nghị một chiến lược kiểm thử điều kiện xây dựng dựa vào kỹ thuật
trên. Được gọi là kiểm thử BRO (branch and relational operator), kỹ thuật đảm bảo việc
phát hiện nhánh và toán tử lỗi trong một điều kiện cung cấp rằng mọi biến boolean và
toán tử quan hệ trong điều kiện xuất hiện chỉ một lần và không có biến chung.
Chiến lược BRO sử dụng ràng buộc điều kiện cho một điều kiện C. Một ràng buộc
điều kiện của C với n điều kiện đơn giản được định nghĩa là (D1, D2,…, Dn) trong đó
Di (
) là một ký tự chỉ ra một ràng buộc trong đầu ra của điều kiện đơn giản thứ I
trong điều kiện C. Một ràng buộc điều kiện D cho điều kiện C được gọi là che đậy bởi
một thực thi của C nếu trong quá trình thực thi C, đầu ra của mỗi điều kiện đơn giản
trong C thỏa mãn ràng buộc tương ứng trong D.
Với một biến boolean, B, ta chỉ ra một ràng buộc trong đầu ra của B mà chỉ ra rằng B
phải là hoặc đúng hoặc sai. Tương tự, với một mệnh đề quan hệ, ký hiệu >, =, < được sử
dụng đẻ chỉ ra ràng buộc trong đầu ra của mệnh đề.
Ví dụ, xem xét điều kiện
C1: B1 & B2
trong đó B1 và B2 là các biến boolean. Ràng buộc điều kiện cho C1 là ở dạng (D1, D2),
trong đó mỗi D1 và D2 là đúng hoặc sai (t or f). Giá trị (t,f) là ràng buộc điều khiển cho C1
và được bao phủ bởi kiểm thử làm cho giá trị B1 là đúng hoặc giá trị B2 là sai. Chiến lược
kiểm thử BRO đòi hỏi rằng tập ràng buộc {(t, t), (f,t), (t,f)} được bao phủ bới các thực thi
của C1. Nếu C1 là sai dựa vào một hoặc nhiều toán tử boolean lỗi, ít nhất một trong tập
điều kiện ràng buộc làm cho C1 sai.
1.4.2. iểm thử luồng dữ liệu.
Phương pháp kiểm thử luồng dữ liệu chọn một phần kiểm thử của một chương trình
dựa vào vị trí của các định nghĩa và sử dụng các biến trong chương trình. Một số các
chiến lược kiểm thử luồng dữ liệu được nghiên cứu và so sánh.

Nhóm 01- Lớp công nghệ phần mềm K52

Page 25