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

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

Trờng đại học hùng vơng

Khoa toán - công nghệ -d d d -

ĐỀ TÀI TèM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM

Giỏo viờn hướng dẫn:

Lương Mạnh Bỏ Sinh Viờn Thực Hiện:

1 Nguyễn Ngọc Hải (Trưởng Nhúm)

2 Nguyễn Xuõn Chiến

3 Hạ Ngọc XuõnSinh Viờn Lớp K6 Tin

Phỳ Thọ 2011

Mục lục

Phần I: Giới Thiệu Về Kiểm Thử Phần Mềm 3

1.1Khái niệm kiểm thử phần mềm 3

1.2 Mục tiêu của kiểm thử 4

1.3 Những khó khăn của kiểm thử 4

1.4 Các phương pháp kiểm thử 4

1.5 Các kỹ thuật thiết kế trường hợp kiểm thử 4

1.6 Phương pháp thử các mô đun 5

PHẦN II GIỚI THIỆU CHI TIẾT VỀ KIỂM THỬ 5

2.1 Nguyên tắc cơ bản kiểm thử phần mềm 5

2.2 Các phương pháp kiểm thử 5

2.3 Các kỹ thuật thiết kế trường hợp kiểm thử 7

2.3.1 Kiểm thử hộp đen – Black box testing 7

*Phân Đoạn Tương Đương 8

*Phân tích giá trị biên – Boundary Value Analysis 9

* Kỹ Thuật Cause-Effect Graphing 11

* Đoán lỗi 15

2.3.2 Kiểm thử hộp trắng – White box testing 15

* Kiểm thử đường diễn tiến của chương trình 16

*Kiểm Định Cấu Trúc Điều Kiển 16

* Độ phức tạp lặp (Cyclomatic Complexity) 21

2.3.3 Kiểm thử hộp xám – Gray box testing 22

2.4 Phương pháp thử các mô đun 22

2.4.1 Kiểm thử mô đun 22

2.4.2 Kiểm thử tích hợp – Intergration Test 22

* Kiểm tra top-down 23

* Kiểm tra bottom-up 24

* Kiểm thử hệ thống – System Test 25

* Kiểm thử chấp nhận sản phẩm – Acceptance Test 27

*Kiểm thử big bang Kiểm thử big bang (big bang testing) là một chiến lược kiểm thử hệ thống tiến hành một lần duy nhất khi đã phát triển toàn bộ các mô đun và tích hợp thành một phần mềm hoàn chỉnh Phương pháp này vẫn thường được tiến hành khi phát triển các phần mềm có kích thước nhỏ 28

*Kiểm thử sandwich 28

2.5 Một số kiểm thử khác 28

PHẦN III MỘT SỐ ỨNG DỤNG CỦA KỸ THUẬT KIỂM THỬ 29

Áp dụng kỹ thuật kiểm thử hộp đen: 29

Vẽ đồ thị nguyên nhân – kết quả 29

Xét các trạng thái đầu vào 32

Xét các trạng thái đầu vào thu được các ca kiểm thử như sau: 32

Áp dụng kỹ thuật kiểm thử hộp trắng vào kiểm thử một chương trình .33

PHẦN VI TỔNG KẾT 38

TÀI LIỆU THAM KHẢO 39

Phần I: Giới Thiệu Về Kiểm Thử Phần Mềm1.1Khái niệm kiểm thử phần mềm

Kiểm thử phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn

phát triển phần mềm để đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết

kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng Các kỹ thuật kiểm

thử phần mềm đã, đang được nghiên cứu, và việc kiểm thử phần mềm đã trở

thành qui trình bắt buộc trong các dự án phát triển phần mềm trên thế giới

là đánh giá cuối cùng về đặc tả thiết kế và mã hóa

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ó thỏa mãn các yêu cầu đã đặt ra trong quá trình phát triển phầnmề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 đượcphâ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ứngcủa khách hàng

• Chi phí của kiểm thử chiếm

• 40% tổng công sức phát triển

• >=30% tổng thời gian phát triển

• Kiểm thử tốt sẽ:

• Giảm chi phí phát triển

• Tăng độ tin cậy của sản phẩm phần mềm

Thiết kế trường

hợp kiểm thử

Chuẩn bị dữ liệu kiểm thử

Chạy trương trình với dữ kiệu kiểm thử

Trường hợp kiểm thử

dữ liệu kiểm thử

Kết quả

So sánh kết quả với các trường hợp kiểm thử

Sơ đồ kiểm thử

1.2 Mục tiêu của kiểm thử

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

năng cao việc tìm thấy các lỗi chưa từng được phát hiện

được phát hiện

1.3 Những khó khăn của kiểm thử

•Nâng cao chất lượng phần mềm nhưng không vượt quá chất lượng

thiết kế chỉ phát hiện các lỗi tiềm tàng và sửa chúng

•Phát hiện lỗi bị hạn chế do thủ công là chính

•Dễ bị ảnh hưởng tâm lý khi kiểm thủ

•Khó đảm bảo tính đầy đủ của kiểm thử

1.4 Các phương pháp kiểm thử

Người ta phân biệt 2 phương pháp kiểm thử: Kiểm thử trên bàn hay kiểmthử tĩnh và Kiểm thử trên máy hay kiểm thử động Kiểm thử tĩnh thường đượctiến hành trước nhằm tạo ra kịch bản cho kiểm thử động

1.5 Các kỹ thuật thiết kế trường hợp kiểm thử

Kiểm thử hộp đen – Black box testing

Kiểm thử hộp trắng – White box testing

Kiểm thử hộp xám – Gray box testing

1.6 Phương pháp thử các mô đun

Để kiểm thử một phần mềm, người ta tiến hành kiểm thử theo trình tự sau:

• Kiểm thử môđun

• Kiểm thử tích hợp

• Kiểm thử hệ thống

• Kiểm thử chấp nhận ( Testing)

PHẦN II GIỚI THIỆU CHI TIẾT VỀ KIỂM THỬ

Có thể sử dụng một số kỹ thuật trong quá trình kiểm thử nhằm tăng

hiệu quả của họat động này Mc Gregor mô tả các kỹ thuật kiểm thử

như những công cụ được thiết kế để đảm bảo rằng tất cả các khía cạnh

của sản phẩm đều được khảo sát Mặt khác, các kỹ thuật kiểm thử là

những công cụ để dễ dàng đạt được hiệu quả kiểm thử

2.1 Nguyên tắc cơ bản kiểm thử phần mềm.

Trong lúc kiểm thử, công nghệ phần mềm phát sinh một chuỗi các trường

hợp kiểm thử được sử dụng để “tách từng phần” phần mềm Kiểm thử là

một bước trong qui trình phần mềm mà có thể được xem xét bởi đội ngũ

phát triển bằng cách phá vỡ thay vì xây dựng Các kỹ sư phần mềm

chính là những người xây dựng và việc kiểm thử yêu cầu họ vượt qua các

khái niệm cho trước về độ chính xác và giải quyết mâu thuẫn khi các lỗi

Một cuộc thanh tra bao gồm:

Đặc tả phần mềm

Kế hoạch thanh tra

Sản phẩm phần mềm

Điều phối viên

Thanh tra viên

Khác biệt với thanh tra:

2.2.2 Kiểm thử động – Dynamic testing

Dùng máy chạy chương trình để điều tra trạng thái từng động tác của chươngtrình

9 bước của trình tự kiểm thử bằng máy:

(1) Thiết kế trường hợp thử theo thử trên bàn

(2) Trường hợp thử phải có cả kết quả kỳ vọng sẽ thu được

(3) Dịch chương trình nguồn và tạo môđun tải để thực hiện

(4) Khi trường hợp thử có xử lý tệp vào-ra, phải làm trước trên bàn việc xác định miền của các tệp

(5) Nhập dữ liệu đã thiết kế cho trường hợp kiểm thử

(6) Điều chỉnh môi trường thực hiện môđun tải (tạo thủ tục đưa các tệp truy cập tệp vào chương trình)

(7) Thực hiện môđun tải và ghi nhận kết quả

(8) Xác nhận kết quả với kết quả kỳ vọng

(9) Lặp lại thao tác (5)-(8)

2.3 Các kỹ thuật thiết kế trường hợp kiểm thử

2.3.1 Kiểm thử hộp đen – Black box testing

Kiểm thử hộp đen (Black Box testing) là kỹ thuật thiết kế trường hợp thử

dựa trên đặc tả bề ngoài của chương trình Người kiểm thử chỉ quan tâm đếnnhiệm vụ mà mô đun phải đảm nhận, đầu vào cho mô đun và kết quả xử lý - đầura

Kiểm thử hộp đen lại chia nhỏ ra nhiều kỹ thuật:

- Phân đoạn tương đương

- Phân tích giá trị biên

- Đoán lỗi

và một số kỹ thuật khác

Hình 1: Black Box testing

*Phân Đoạn Tương Đương

Đây là kỹ thuật chia vùng thông tin nhập vào của chương trình thành các lớpthông tin/dữ liệu Lớp tương đương biểu diễn thành một tập các giá trị hợp lệ vàkhông hợp lệ Nhưng lớp dữ liệu tương đương này có thể được xác định theonhững cách sau:

1 Nếu điều kiện đầu vào xác định một khoảng giá trị [a,b], thì phân

hoạch thành một lớp tương đương hợp lệ và một lớp tương đương

không hợp lệ Chẳng hạn, nếu đầu vào x nằm trong khoảng [0,100], lớp

hợp lệ là 0 <= x <= 100, các lớp không hợp lệ là x < 0 và x > 100

Black Box

Results Input

2 Nếu điều kiện đầu vào yêu cầu một giá trị xác định, phân hoạch

thành một lớp tương đương hợp lệ và hai lớp tương đương không hợp

lệ Chẳng hạn, nếu đầu vào x=5, thì lớp hợp lệ là x= 5, các lớp không

hợp lệ là x <5 và x >5

3 Nếu điều kiện đầu vào xác định một phần tử của tập hợp, thì phân

hoạch thành một lớp tương đương hợp lệ và một lớp tương đương không

hợp lệ

4 Nếu điều kiện đầu vào là Boolean, thì phân hoạch thành một lớp

tương đương hợp lệ và một lớp tương đương không hợp lệ tương ứng với

hai trạng thái true và false

Một mẫu cho việc liệt kê các lớp tương đương

Điều kiện bên ngoài Các lớp tương đương hợp

lệ Các lớp tương đươngkhông hợp lệ

Ngoài ra, một nguyên tắc thứ năm được bổ sung là sử dụng khả năng

phán đoán, kinh nghiệm và trực giác của người kiểm thử

Các trường hợp kiểm thử

Bước thứ hai trong phương pháp phân đoạn tương đương là thiết kế

các trường hợp kiểm thử dựa trên sự ước lượng của các lớp tương đương

cho miền đầu vào Tiến trình này được thực hiện như sau:

1 Gán một giá trị duy nhất cho mỗi lớp tương đương

2 Đến khi tất cả các lớp tương đương hợp lệ được phủ bởi các trường

hợp kiểm thử thì viết một trường hợp kiểm thử mới phủ nhiều nhất có

thể các lớp tương đương hợp lệ chưa được phủ

3 Đến khi tất cả các lớp tương đương không hợp lệ được phủ bởi các

trường hợp kiểm thử thì hãy viết các trường hợp kiểm thử mới sao cho

mỗi trường hợp kiểm thử mới chỉ phủ duy nhất một lớp tương đương

không hợp lệ chưa được phủ

*Phân tích giá trị biên – Boundary Value Analysis

Kinh nghiệm cho thấy các ca kiểm thử mà khảo sát tỷ mỷ các điều kiện biên có

tỷ lệ phần trăm cao hơn các ca kiểm thử khác Các điều kiện biên là những điều kiện mà các tình huống ngay tại, trên và dưới các cạnh của các lớp tương đương đầu vào và các lớp tương đương đầu ra Phân tích các giá trị biên là phương pháp thiết kế ca kiểm thử bổ sung thêm cho phân lớp tương đương, nhưng khác với phân lớp tương đương ở 2 khía cạnh:

1 Phân tích giá trị biên không lựa chọn phần tử bất kỳ nào trong 1 lớptương đương là điển hình, mà nó yêu cầu là 1 hay nhiều phần tử đượclựa chọn như vậy mà mỗi cạnh của lớp tương đương đó chính là đốitượng kiểm tra

2 Ngoài việc chỉ tập trung chú ý vào các trạng thái đầu vào (không gianđầu vào), các ca kiểm thử cũng nhận được bằng việc xem xét khônggian kết quả (các lớp tương đương đầu ra)

Phân tích giá trị biên yêu cầu óc sáng tạo và lượng chuyên môn hóa nhất định và

nó là một quá trình mang tính kinh nghiệm rất cao Tuy nhiên, có một số quy tắcchung như sau:

1 Nếu 1 trạng thái đầu vào định rõ giới hạn của các giá trị, hãy viết các cakiểm thử cho các giá trị cuối của giới hạn, và các ca kiểm thử đầu vàokhông hợp lệ cho các trường hợp vừa ra ngoài phạm vi

2 Nếu 1 trạng thái đầu vào định rõ số lượng giá trị, hãy viết các ca kiểmthử cho con số lớn nhất và nhỏ nhất của các giá trị và một giá trị trên,một giá trị dưới những giá trị này

3 Sử dụng quy tắc 1 cho mỗi trạng thái đầu vào Ví dụ, nếu 1 chương trìnhtính toán sự khấu trừ FICA hàng tháng và nếu mức tối thiểu là 0.00$, vàtối đa là 1,165.25$, hãy viết các ca kiểm thử mà khấu trừ 0.00$ và1,165.25, khấu trừ âm và khấu trừ lớn hơn 1,165.25$ Chú ý là việc xemxét giới hạn của không gian kết quả là quan trọng vì không phải lúc nàocác biên của miền đầu vào cũng mô tả cùng một tập sự kiện như biên

của giới hạn đầu ra (ví dụ, xét chương trình con tính SIN) Ngoài ra,không phải lúc nào cũng có thể tạo ra 1 kết quả bên ngoài giới hạn đầu

ra, nhưng tuy nhiên rất đáng để xem xét tiềm ẩn đó

4 Sử dụng nguyên tắc 2 cho mỗi trạng thái đầu ra

5 Nếu đầu vào hay đầu ra của 1 chương trình là tập được sắp thứ tự ( vídụ,1 file tuần tự hay 1 danh sách định tuyến hay 1 bảng) tập trung chú ývào các phần tử đầu tiên và cuối cùng của tập hợp

6 Sử dụng sự khéo léo của bạn để tìm các điều kiện biên

* Kỹ Thuật Cause-Effect Graphing

Ta thấy rằng 2 kỹ thuật trên dữ liệu đầu vào đã được phân loại để phân tích Tuynhiên kỹ thuật sắp trình bày dưới đây cho phép xác định ra các trường hợp kiểm thử hiểu quả nhất ngay cả trong lúc dữ liệu đầu vào là khó phân loài thành các lớp như trong 2 kỹ thuật trên

Kỹ thuật này gồm có 4 bước như sau :

1 Đặc tả được chia thành các phần có thể thực hiện được Điều này là cầnthiết bởi vì đồ thị nguyên nhân – kết quả trở nên khó sử dụng khi được

sử dụng trên những đặc tả lớn

2 Nguyên nhân và kết quả trong các đặc tả được nhận biết Một nguyênnhân là một trạng thái đầu vào nhất định hay một lớp tương đương củacác trạng thái đầu vào Một kết quả là một trạng thái đầu ra hay 1 sự

biến đổi hệ thống (kết quả còn lại mà 1 đầu vào có trạng thái của 1chương trình hay hệ thống) Bạn nhận biết nguyên nhân và kết quả bằngviệc đọc từng từ của đặc tả và gạch chân các từ hoặc cụm từ mô tảnguyên nhân và kết quả Khi được nhận biết, mỗi nguyên nhân và kếtquả được gán cho 1 số duy nhất.

3 Xây dựng đồ thị nguyên nhân – kết quả bằng cách phát triển và biến đổinội dung ngữ nghĩa của đặc tả thành đồ thị Boolean nối giữa nguyênnhân và kết quả

4 Đồ thị được được diễn giải với các ràng buộc mô tả những sự kết hợpcủa nguyên nhân và/hoặc kết quả là không thể vì các ràng buộc ngữnghĩa và môi trường

5 Bằng việc dò theo các điều kiện trạng thái trong đồ thị một cách cẩnthận, bạn chuyển đổi đồ thị thành một bảng quyết định mục vào giớihạn Mỗi cột trong bảng mô tả một ca kiểm thử

6 Các cột trong bảng quyết định được chuyển thành các ca kiểm thử

Ký hiệu cơ bản cho đồ thị được chỉ ra trong hình 1 Tưởng tượng mỗi nút có giá trị là 0 hoặc 1; 0 mô tả trạng thái vắng mặt và 1 mô tả trạng thái có mặt Hàm

đồng nhất nói là nếu a là 1 thì b là 1; ngược lại, b là 0 Hàm not là nói nếu a là

1 thì b là 0; ngược lại thì b là 1 Hàm or khẳng định rằng nếu a hoặc b hoặc c là

1, thì d là 1; ngược lại d là 0 Hàm and khẳng định nếu cả a và b là 1 thì c là 1; ngược lại c là 0 Hai hàm or và and được phép có số lượng đầu vào bất kỳ.

Trong hầu hết các chương trình, sự kết hợp nào đó của một số nguyên nhân là không thể bởi vì lý do ngữ nghĩa và môi trường (ví dụ, một ký tự không thể đồng thời vừa là “A” vừa là “B”) khi đó, ta sử dụng ký hiệu trong Hình 2

Ràng buộc E (Exclude – loại trừ) khẳng định rằng tối đa, chỉ có hoặc a hoặc b

có thể là 1 (a và b không thể đồng thời là 1) Ràng buộc I (Include – bao hàm) khẳng định ít nhất một trong a, b hoặc c phải luôn luôn là 1 (a, b hoặc c không

thể đồng thời là 0) Ràng buộc O (Only – chỉ một) khẳng định một và chỉ một

hoặc a hoặc b phải là 1 Ràng buộc R (Request – yêu cầu) khẳng định rằng khi a

là 1, thì b phải là 1 (ví dụ, không thể có trường hợp a là 1, còn b là 0) Ràng buộc M (Mask – mặt nạ) khẳng định là nếu kết quả a là 1, kết quả b sẽ bắt buộc

phải là 0

Bước tiếp theo là tạo bảng quyết định mục vào giới hạn – limited-entry decision table Tương tự với các bảng quyết định, thì nguyên nhân chính là các điều kiện

và kết quả chính là các hành động Quy trình được sử dụng là như sau:

1 Chọn một kết quả để là trạng thái có mặt (1)

2 Lần ngược trở lại đồ thị, tìm tất cả những sự kết hợp của các nguyênnhân (đối tượng cho các rằng buộc) mà sẽ thiết lập kết quả này thành 1

3 Tạo một cột trong bảng quyết định cho mỗi sự kết hợp nguyên nhân

4 Với mỗi sự kết hợp, hãy quy định trạng thái của tất cả các kết quả khác

và đặt chúng vào mỗi cột

Trong khi biểu diễn bước 2, cần quan tâm các vấn đề sau:

1 Khi lần ngược trở lại qua một nút or mà đầu ra của nó là 1, không bao giờ thiết lập nhiều hơn 1 đầu vào cho nút or là 1 một cách đồng thời Điều này được gọi là path sensitizing – làm nhạy đường đi Mục tiêu

của nó là để ngăn chặn dò lỗi thất bại vì một nguyên nhân che đi mộtnguyên nhân khác

2 Khi lần ngược trở lại qua một nút and mà đầu ra của nó là 0, dĩ nhiên,

phải liệt kê tất cả các sự kết hợp đầu vào dẫn tới đầu ra 0 Tuy nhiên,

nếu bạn đang khảo sát trạng thái mà 1 đầu ra là 0 và một hay nhiều đầu

ra khác là 1, thì không nhất thiết phải liệt kê tất cả các điều kiện màdưới điều kiện đó các đầu vào khác có thể là 1

3 Khi lần ngược trở lại qua một nút and mà đầu ra của nó là là 0, chỉ cần liệt kê 1 điều kiện trong đó tất cả đầu vào bằng 0 (Nếu nút and ở chính

giữa của đồ thị như vậy thì tất cả các đầu vào của nó xuất phát từ cácnút trung gian khác, có thể có quá nhiều trạng thái mà trong trạng thái

đó tất cả các đầu vào của nó bằng 0.)

trường hợp a=b=1 (sự xem xétthứ 1)

 Nếu x=0, liệt kê tất cả cáctrường hợp trong đó a=b=0

 Nếu x =1, liệt kê tất cả các trường hợp trong đó a=b=c=1.

hợp mà a=b=c=0 (sự xem xét

3) Đối với các trạng thái màabc là 001, 010, 100, 011, 101

và 110 , bao gồm chỉ 1 trườnghợp mỗi trạng thái (sự xem xét2)

Những sự xem xét này có thể xuất hiện thất thường, nhưng chúng có một mục đích rất quan trọng: để giảm bớt các kết quả được kết hợp của đồ thị Chúng liệt

kê các trường hợp mà hướng về các ca kiểm thử ít có lợi Nếu các ca kiểm thử ít

có lợi không được liệt kê, một đồ thị nguyên nhân – kết quả lớn sẽ tạo ra một số lượng ca kiểm thử cực kỳ lớn Nếu số lượng các ca kiểm thử trên thực tế là quá lớn, bạn sẽ chọn ra 1 tập con nào đó, nhưng không đảm bảo là các ca kiểm thử ít

có lợi sẽ là những ca kiểm thử được liệt kê Do đó, tốt hơn hết là liệt kê chúng trong suốt quá trình phân tích của đồ thị.

* Đoán lỗi

Một kỹ thuật thiết kế trường hợp kiểm thử khác là error guessing – đoán lỗi

Tester được đưa cho 1 chương trình đặc biệt, họ phỏng đoán, cả bằng trực giác

và kinh nghiệm, các loại lỗi có thể và sau đó viết các ca kiểm thử để đưa ra các lỗi đó

Thật khó để đưa ra một quy trình cho kỹ thuật đoán lỗi vì nó là một quy trình có tính trực giác cao và không thể dự đoán trước Ý tưởng cơ bản là liệt kê một danh sách các lỗi có thể hay các trường hợp dễ xảy ra lỗi và sau đó viết các ca kiểm thử dựa trên danh sách đó Một ý tưởng khác để xác định các ca kiểm thử

có liên đới với các giả định mà lập trình viên có thể đã thực hiện khi đọc đặc tả (tức là, những thứ bị bỏ sót khỏi đặc tả, hoặc là do tình cờ, hoặc là vì người viết

có cảm giác những đặc tả đó là rõ ràng) Nói cách khác, bạn liệt kê những

trường hợp đặc biệt đó mà có thể đã bị bỏ sót khi chương trình được thiết kế

2.3.2 Kiểm thử hộp trắng – White box testing

tiêu(Trong trường hợp này yêu cầu người kiểm thử phải biết ngôn ngữ lậptrình)

* Kiểm thử đường diễn tiến của chương trình

Khái niêm: Là việc thiết kế các trường hợp kiểm thử trên từng câu lệnh trong chương trình được sẽ được thực hiện ít nhất 1 lần không quan tâm đến ảnh

hưởng lên các đường quyết định.

Mỗi nút của đồ thị được biểu diễn một lệnh hay một dãy lệnh liên tiếp của chương trình

Các bước tiến hành:

Dùng tài liệu thiết kế hay

mã nguồn để vẽ thuật toáncủa chương trình hay hàmXác định đồ thị V(G)

Từ đồ thị xác định tập đường độc lập tuyến tính lẫn nhau

Xây dựng trường hợp kiểm thử dựa trên tập đường xác định ở trên

*Kiểm Định Cấu Trúc Điều Kiển

a Kiểm thử các biểu thức điều kiện

Kiểm thử biểu thức điều kiện là phương pháp kiểm thử trên những điều kiện logic của hàm hay module Một điều kiện đơn giản là một biến boolean hoặc là một biểu thức quan hệ:

E1, E2 là các biểu thức số học và phép toán quan hệ là một trong các phép toán sau : <, <=, ==, != , > hay >= Một điều kiện kết hợp của 2 hay nhiều điều kiện đơn giản, các phép toán boolean : OR ( | |, AND (&) and NOT (!)

Các loại lỗi của điều kiện bao gồm

Lỗi trong các thao tác luận lý ( lỗi tồn tại một biểu thức không đúng, thiếu hoặc thừa các thao tác luận lý

Mục đích của kiểm thử cấu trúc điều kiển là phát hiện không chỉ lỗi trong điều kiện mà còn những 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 điều kiện của P,thì bộ kiểm thử đò cũng có thể phát hiện các lỗi khác trong P

E1 <phép toán quan hệ> E2

Ba trường hợp kiểm thử được yêu cầu để kiểm tra là giá trị E1 lớn hơn, nhỏ hơn

và bằng giá trị của E2 Nếu <phép toán quan hệ> là không đúng và E1, E2 là đúng thì 3 loại kiểm thử trên có đảm bảo có thể xác định được lỗi trong phép toán quan hệ Để phát hiện lỗi trong E1và E2 thì các trường hợp kiểm thử E1 lớnhơn, nhỏ hơn E2 có thể phát hiện ra được lỗi

b Kiểm Thử luồng Dữ liệu (DFT)

Phương pháp kiểm thử luồng dữ liệu chọn lựa một số đường diễn tiến của

chương trình dựa vào việc cấp phát, định nghĩa, và sư dụng những biến trong chương trình

Để hình dung ra cách tiếp cận này ta giả sử rằng mỗi câu lệnh của chương trình được gán một số duy nhất và rằng mỗi hàm khong được thay đổi thông số của

nó và biến toàn cục

DEF(S) = { X | lệnh S chứa định nghĩa X }

USE(S) = { X | lệnh S chứa một lệnh/biểu thức sủ dụng X }

Nếu S là câu lệnh if hay loop, thì tập DEF của S là rỗng và USE là tập dựa trên điều kiện của câu lệnh S

Định nghĩa 1 biến X tại câu lênh S được cho là vẫn còn sống tại câu lênh S’ nếu như tồn tại một đường từ câu lệnh S đến câu lệnh S’ không chứa bất kỳ định nghĩa nào của X

Định nghĩa 2 Một chuỗi dùng của biến X ( gọi là DU của X) ký hiệu [X, S, S’]

là định nghĩa của X trong câu lệnh S vẫn sống trong câu lênh S’

Phương pháp kiểm thử luồng dữ liệu yêu cầu rằng tất cả các chuỗi DU đều đượckiểm thử ít nhất một lần Có thể thấy rằng bộ kiểm thử cho luồng dữ liệu có thể không bao trùm tất cả các nhánh của chương trình Tuy nhiên nêu môt nhánh đảm bảo được sẽ được phát hiện bỏi phương pháp kiểm thử này Trong một số hiếm trường hợp như là cấu trúc lệnh if-then trong phần then không có định nghĩa thêm một biến nào và phần else không tồn tại Trong tình huông này thì nhánh else của câu lênh ì trên không cần thiết phải bảo hộ bởi phương pháp này.DFT rất hũư ích cho các loài kiểm thử một chương trình có nhiều lệnh if và lệnhlặp lồng nhau nhiều cấp

Ví Dụ Hình 1 Một Thủ Tục Với Lệnh Điều Kiện Và Lệnh Lặp Phức Tạp

Để xây dựng các trường hợp kiểmthử DFT cho thủ tục trên, chúng ta cần phải biết định nghĩa và sử dụng biến ở mỗi điều kiện hoặc một khối trong thủ tục này Giả sử biến X được định nghĩa trong câu lệnh cuối của khối lệnh B2, B3, B4 và B5 và biến X được sử dụng ở đầu của các khối B2, B3, B4, B5 và B6 Kiểm thử DU yêu cầu đường thực thi ngắn nhất từ Bi, 0< i <= 5 đến Bj 1<j<=6.(thật sự thì trong trường hợp này các trường hợp kiểm thử cũng có khả năng phát hiện bất kỳ việc dùng biến X trong các điều kiện C1, C2, C3 và C4) mặc dù có đến 25 chuổi DU nhưng chỉ cần 5 là đủ để bao hàm các trường hợp khác

* Kiểm Thử Vòng Lặp

Vòng lặp là một trong những nền tảng cho rất nhiều các thuật toán được cài đặc trong các phần mềm tuy nhiên cho đến lúc này chúng ta vẫn còn ít chú ý đến việc xây dựng các trương hợp để kiểm thử

Kiểm thử vòng lặp tập trung vào tính chất của cấu trúc vòng lặp Có 4 cầu trúc vòng lặp như sau: vòng lặp đơn giản, vòng lặp móc nối, vòng lặp tạo thành tổ,

if C4 then B4;

else B5 endif;

else

if C3 then B2 else B3 endif;

endif enddo B6 End proc