Luận văn Thạc sĩ Khoa học máy tính: Kỹ thuật ma trận đồ thị trong phương pháp kiểm thử hộp trắng

Nhận xét:

Phương pháp kiểm thử theo đường dẫn phụ thuộc nhiều vào các biểu

thức điều kiện (Xem hình 1.8). Tuy nhiên, có những trường hợp số lượng

đường dẫn quá lớn (trường hợp vòng lặp). Vì vậy chương trình này thường

không phải là lựa chọn thực tế để tiến hành việc kiểm tra tính đúng đắn của

chương trình.

13

Có khoảng 520= 95.367.431.640.625 đường dẫn

Loop < 20

Hình1.8. Lược đồ kiểm thử đường dẫn theo biểu thức điều kiện

1.2.3.3. Kiểm thử theo điều kiện (Condition Testing)

Kiểm thử theo điều kiện là phương pháp kiểm thử các biểu thức điều

kiện trên hai giá trị true và false [1].

Ta xét các ví dụ sau:

if (x > 0 &&y>0) x= 1;

else

x=2;

Các bộ kiểm tra { (x>0, y>0), (x <=0, y>0) } sẽ kiểm thử toàn bộ các

điều kiện.

Tuy nhiên, không thỏa mãn với mọi giá trị đầu vào, cần kết hợp cả x và y

để thực hiện bước kiểm thử.

14

1.2.3.4 Kiểm thử theo vòng lặp (Loop Testing)

Kiểm thử theo vòng lặp là phương pháp tập trung vào tính hợp lệ của

các cấu trúc vòng lặp. Các loại vòng lặp được thể hiện như sau [1,8]:

Vòng lặp nối tiếp nhau

Vòng lặp đơn giản

Vòng lặp không cấu trúc

Vòng lặp lồng nhau

Hình 1.9.Các kiểu vòng lặp

- Các bước cần kiểm thử cho vòng lặp đơn

+ Bỏ qua vòng lặp.

+ Lặp một lần.

+ Lặp hai lần.

+ Lặp m lần (men).

+ Lặp (n-1), n, (n+1) lần.

Trong đó n là số lần lặp tối đa của vòng lặp.

- Các bước cần kiểm thử cho vòng lặp dạng lồng nhau

+ Khởi đầu với vòng lặp nằm bên trong nhất. Thiết lập các tham số lặp

cho các vòng lặp bên ngoài về giá trị nhỏ nhất.

+ Kiểm tra với tham số min+1, một giá trị tiêu biểu, max-1 và max cho

vòng lặp bên trong nhất trong khi các tham số lặp của các vòng lặp bên ngoài

là nhỏ nhất.

15

+ Tiếp tục tương tự với các vòng lặp liền ngoài tiếp theo cho đến khi tất

cả vòng lặp bên ngoài được kiểm tra.

- Các bước cần kiểm thử cho vòng lặp nối tiếp

+ Nếu các vòng lặp là độc lập với nhau thì kiểm tra như trường hợp các

vòng lặp dạng đơn, nếu không thì kiểm thử như trường hợp các vòng lặp lồng

nhau.

Ví dụ: // LOOP TESTING EXAMPLE PROGRAM

import java.io.*;

class LoopTestExampleApp {

// ---------------------------- FIELDS ------------------------

public static BufferedReader keyboardinput =

new BufferedReader(new InputStreamReader(System.in));

private static final int MINIMUM = 1;

private static final int MAXIMUM = 10;

I I --------------------------- METHODS -----------------------

/* Main method */

public static void main(String[] args) throws lOException {

System.out.println("Input an integer value:”);

int input = new Integer(keyboardInput.readLine()).intValue();

int numberOflterations = 0;

16

CHƯƠNG 2

MỘT SỐ KỸ THUẬT HIỆU QUẢ TRONG PHƯƠNG PHÁP KIỂM

THỬ HỘP TRẮNG VÀ CA KIỂM THỬ

2.1. Một số kỹ thuật chính trong phương pháp kiểm thử hộp trắng

Có thể tổng hợp một số kỹ thuật hiệu quả trong phương pháp kiểm thử

hộp trắng như sau:

2.1.1. Kỹ thuật kiểm thử dòng điều khiển

Kỹ thuật kiểm thử dòng điều khiển dựa trên khái niệm đồ thị dòng điều

khiển (control flow graph). Đồ thị này được xây dựng từ mã nguồn của

chương trình/đơn vị chương trình. Đồ thị dòng điều khiển là một đồ thị có

hướng gồm các đỉnh tương ứng với các câu lệnh/nhóm câu lệnh và các cạnh

là các dòng điều khiển giữa các câu lệnh/nhóm câu lệnh. Nếu i và j là các đỉnh

của đồ thị dòng điều khiển thì tồn tại một cạnh từ i đến j nếu lệnh tương ứng

với j có thể được thực hiện ngay sau lệnh tương ứng với i.

Xây dựng một đồ thị dòng điều khiển từ một chương trình/đơn vị

chương trình khá đơn giản. Hình 2.1 mô tả các thành phần cơ bản của đồ thị

dòng điều khiển bao gồm điểm bắt đầu của đơn vị chương trình, khối xử lý

chứa các câu lệnh khai báo hoặc tính toán, điểm quyết định ứng với các câu

lệnh điều kiện trong các khối lệnh rẽ nhánh hoặc lặp, điểm nối ứng với các

câu lệnh ngay sau các lệnh rẽ nhánh, và điểm kết thúc ứng với điểm kết thúc

của đơn vị chương trình. Các cấu trúc điều khiển phổ biến của chương trình

được mô tả trong Hình 2.2. Chúng ta sẽ sử dụng các thành phần cơ bản và các

cấu trúc phổ biến này để dễ dàng xây dựng đồ thị dòng điều khiển cho mọi

đơn vị chương trình viết bằng mọi ngôn ngữ lập trình.

17

Điểm kết thúc

Điểm quyết định

Điểm nối

Điểm xuất phát Khối xử lý

Hình 2.1: Các thành phần cơ bản của đồ thị chương trình.

switch

Tuần tự

Rẽ nhánh

While c do …

do … while c

Hình 2.2: Các cấu trúc điều khiển phổ biến của chương trình.

Chúng ta thử xem cách dựng đồ thị dòng điều khiển cho đơn vị chương

trình có mã nguồn bằng ngôn ngữ C như Hình 2.3. Chúng ta đánh số các dòng

lệnh của đơn vị chương trình và lấy số này làm đỉnh của đồ thị. Điểm xuất

phát của đơn vị chương trình ứng với câu lệnh khai báo hàm foo. Đỉnh 1 ứng

với câu lệnh khai báo biến e. Các đỉnh 2 và 3 ứng với câu lệnh if. Đỉnh 4 ứng

với câu lệnh khai báo biến x trong khi các đỉnh 5 và 6 ứng với câu lệnh if.

Đỉnh 7,8 đại diện cho hai câu lệnh 7 và 8. Trong trường hợp này, chúng ta

không tách riêng thành hai đỉnh vì đây là hai câu lệnh tuần tự nên chúng ta

ghép chúng thành một đỉnh nhằm tối thiểu số đỉnh của đồ thị dòng điều khiển.

18

1

Float foo (int a, int b, int c, int d) {

2

3

1. Float e; 2. If (a==0)

4

3. Return 0;

5

6

7,8

4. Int x = 0; 5. If ((a==b) || (c==d)) 6. x = 1; 7. e = 1/x; 8. return e; }

Hình 2.3: Mã nguồn của hàm foo và đồ thị dòng điều khiển của nó.

2.1.2. Kỹ thuật kiểm thử dòng dữ liệu

Đồ thị dòng dữ liệu là một sự mở rộng của đồ thị dòng điều khiển bằng

cách bổ sung thêm xử lý dữ liệu trong chương trình. Việc xử lý dữ liệu trong

chương trình được thực hiện thông qua sự định nghĩa và sử dụng các biến.

Định nghĩa, được kí hiệu là def, là vị trí mà giá trị của biến được lưu trữ trong

bộ nhớ. Sử dụng, được kí hiệu là use, là vị trí mà biến được truy cập.

Lộ trình định nghĩa - sử dụng, được kí hiệu du-path. Tiêu chí bao phủ

cho đồ thị luồng dữ liệu sẽ được định nghĩa dựa trên khái niệm du-path.

Chúng ta chia du-path thành 2 nhóm [1,3,8,10,11]:

- du-path liên quan đến định nghĩa biến, gồm các du-path với 1 biến

được định nghĩa tại 1 đỉnh. du(ni,v) là tập các du-path đối với biến v xuất phát

từ đỉnh ni.

- du-path liên quan đến các cặp định nghĩa và sử dụng biến, gồm các du-

path đối với 1 biến được định nghĩa tại một đỉnh và được sử dụng tại một đỉnh

khác. du(ni, nj, v) là tập các du-path đối với biến v xuất phát từ đỉnh ni và kết

thúc tại đỉnh nj.

19

2.1.3. Kỹ thuật kiểm thử BRO

Người ta đưa ra chiến lược cho các phép thử nhạy cảm bằng cách

áp dụng kết hợp chiến lược kiểm thử nhánh và kiểm thử miền (quan hệ) có tên

là chiến lược kiểm thử BRO (Branch and Relational Operation) [8].

Chiến lược BRO bao gồm kiểm thử nhánh và toán tử quan hệ.

- Chiến lược kiểm thử nhánh bao gồm:

+ Kiểm thử từng điều kiện trong chương trình.

+ Kiểm thử điều kiện không chỉ là phát hiện sai trong điều kiện mà còn

phát hiện sai khác của chương trình liên quan.

Kiểm thử nhánh được thực hiện theo nguyên tắc: với mỗi điều kiện

phức hợp C, thì với mỗi nhánh “true” và “false” của C, mỗi điều kiện đơn

trong C phải được kiểm thử ít nhất một lần.

- Chiến lược kiểm thử miền

Chiến lược kiểm thử miền cần 3 hoặc 4 kiểm thử cho 1 biểu thức quan

hệ bao gồm <, >, = và có thể ≠ nữa.

Nếu biểu thức Bool có n biến, mà n nhỏ thì thuận lợi, song n lớn thì khó

thực hiện tất cả trường hợp.

Điều kiện logic

Điều kiện logic có thể là:

- Điều kiện đơn: 1 biến Bool (cả toán tử phủ định): X

- Biểu thức quan hệ của 2 biểu thức số học C = (A Θ B), với Θ là phép

so sánh: , , , ,  hay  và A, B là biểu thức số học.

- Điều kiện phức hợp cấu thành từ hơn một điều kiện đơn nhờ các toán

tử Bool: hoặc (), và (), phủ định (┘).

D = X1 & X 2 & … Xn , trong đó Xi là điều kiện đơn & là toán tử Bool.

Kiểu sai trong điều kiện logic có thể là:

- Sai biến Bool.

20

- Sai toán tử Bool.

- Sai số hạng trong biểu thức toán tử Bool.

- Sai toán tử quan hệ.

- Sai biểu thức số học.

BRO dùng “ràng buộc điều kiện làm điều kiện cần thử” để phát hiện sai

ở nhánh và toán tử khi xảy ra 1 lần và không có biến chung.

Giả sử: D = X1&X2 & … Xn,

Xi: điều kiện đơn, &: toán tử Bool

Cần đặc tả ràng buộc đầu ra của mỗi Xi tương ứng với điều kiện D đã

xác định.

Ta nói rằng, ràng buộc Xi của điều kiện D được phủ bởi một sự thực thi

của C nếu khi đó, đầu ra của mỗi điều kiện đơn Xi trong D thỏa mãn các ràng

buộc tương ứng. Điều này có nghĩa là: Khi giá trị của D đã cho, ta cần tìm các

điều kiện ràng buộc mà mỗi Xi (một thành phần của D) cần thỏa mãn để bảo

đảm nhận được giá trị của D đã cho.

Với 1 biến Bool B, thì ràng buộc đầu ra của B là t (true) hoặc f (false).

Với 1 biểu thức quan hệ (A Θ B) thì ràng buộc đầu ra của nó là toán tử

quan hệ:

Θ có thể nhận 1 trong 4 giá trị >, <, =, ≠ (lớn hơn, nhỏ hơn, bằng hoặc

khác).

2.1.4. Kỹ thuật kiểm thử đột biến

Dick Lipton là người đầu tiên đề xuất ra kỹ thuật kiểm thử đột biến, sau

đó lĩnh vực này được đánh dấu sự ra đời và phổ biến bởi DeMillo và

Sayward. Kiểm thử đột biến là phương pháp kiểm thử dựa trên lỗi nhằm cung

cấp một tiêu chuẩn kiểm thử được gọi là tỷ lệ đột biến. Tỷ lệ đột biến được sử

dụng để đánh giá khả năng phát hiện lỗi của tập dữ liệu thử [6,12,13,14].

21

Nguyên lý chung của kiểm thử đột biến là tạo ra các phiên bản của

chương trình có chứa các lỗi đơn giản, các lỗi được sử dụng bởi kiểm thử đột

biến đại diện cho các lỗi sơ suất do lập trình viên thường tạo ra. Các lỗi như

thế được gieo một cách thận trọng vào chương trình gốc, bằng cách thay đổi

cú pháp đơn giản, để tạo một tập các chương trình lỗi. Mỗi chương trình lỗi

được gọi là đột biến, mỗi đột biến mang một thay đổi cú pháp khác nhau. Cụ

thể, cho P là một chương trình gốc, P’ là một đột biến của P bằng cách thực

hiện một thay đổi nhỏ về cú pháp trong chương trình.

Trong Bảng 2.1, P là chương trình gốc, P’ và P’’là các đột biến của P

bằng cách thay đổi cú pháp trong phép toán quan hệ, thay thế x>y bằng x

đối với P’ ;thay x

đánh dấu bởi ký hiệu gạch chân.

Bảng 2.1. Ví dụ minh họa các đột biến

Chương trình gốc P

Đột biến P’

Đột biến P’’

int max(int x, int y) int max(int x,int y) int max(int x,int y)

{ { {

int mx = x int mx=x; int mx=x;

If x y) if (x <= y)

mx = y mx=y mx=y

return mx; return mx; return mx;

} } }

Sau khi tạo ra các đột biến, mỗi đột biến và chương trình gốc được thực

thi trên cùng một bộ dữ liệu thử, nếu kết quả của đột biến và chương trình gốc

khác nhau, thì đột biến đó được gọi là đột biến bị diệt. Nếu không thể tìm thấy

dữ liệu thử sao cho khi thực thi đột biến và chương trình gốc cho kết quả khác

nhau, thì đột biến đó được gọi là đột biến tương đương.

22

Tỷ số MS=100*D/(N-E) được gọi là tỷ lệ đột biến.

Trong đó, MS: tỷ lệ đột biến; D: là đột biến đã bị diệt; N: là tổng số các

đột biến; E: là tổng số đột biến tương đương. Tỷ lệ đột biến cho phép đánh giá

chất lượng bộ dữ liệu thử.

2.2. Ca kiểm thử

2.2.1.Một số quan niệm về ca kiểm thử

Kiểm thử là một tiến trình thực hiện một chương trình với ý định tìm ra

lỗi. Một ca kiểm thử là một trường hợp kiểm thử có xác suất cao để tìm ra lỗi

[8]. Nói rõ hơn, Ca kiểm thử (test case) là một tình huống kiểm thử tương

ứng với một mạch hoạt động của chương trình. Nó bao gồm một tập các giá

trị đầu vào và một danh sách các kết quả đầu ra mong muốn và thực tế [9].

2.2.2.Nội dung thiết kế ca kiểm thử

Một trong những lý do quan trọng nhất trong kiểm thử phần mềm là

thiết kế và tạo ra các ca kiểm thử (Test case) có hiệu quả (ca kiểm thử tốt nhất

có khả năng phát hiện ra lỗi, sai sót của phần mềm một cách nhiều nhất). Với

những ràng buộc về thời gian và chi phí đã cho, thì vấn đề then chốt của kiểm

thử là phải trả lời câu hỏi: Tập con nào của tất cả ca kiểm thử có thể có khả

năng tìm ra nhiều lỗi nhất? [2,8].

Thông thường, phương pháp kém hiệu quả nhất là kiểm tra tất cả đầu

vào ngẫu nhiên - quá trình kiểm thử một chương trình bằng việc chọn ngẫu

nhiên một tập con các giá trị đầu vào có thể. Về mặt khả năng tìm ra nhiều lỗi

nhất, tập hợp các ca kiểm thử được chọn ngẫu nhiên có rất ít cơ hội là tập hợp

tối ưu hay gần tối ưu. Sau đây là một số phương pháp để chọn ra một tập dữ

liệu kiểm thử một cách thông minh.

Để kiểm thử hộp đen và kiểm thử hộp trắng một cách thấu đáo là không

thể. Do đó, một chiến lược kiểm thử hợp lý là chiến lược có thể kết hợp sức

mạnh của cả hai phương pháp trên: Phát triển một cuộc kiểm thử nghiêm ngặt

vừa bằng việc sử dụng các phương pháp thiết kế ca kiểm thử hướng hộp đen

23

nào đó và sau đó bổ sung thêm những ca kiểm thử này bằng việc khảo sát tính

logic của chương trình, sử dụng phương pháp hộp trắng.

Bảng 2.2 : Những chiến lược kết hợp

Hộp đen Hộp trắng

Phân lớp tương đương Bao phủ câu lệnh

Phân tích giá trị biên Bao phủ quyết định

Đồ thị nguyên nhân - kết quả Bao phủ điều kiện

Đoán lỗi Bao phủ điều kiện - quyết định

Bao phủ đa điều kiện.

Mỗi phương pháp có những ưu điểm cũng như khuyết điểm riêng, do

đó để có được tập các ca kiểm thử tối ưu, chúng ta cần kết hợp hầu hết các

phương pháp. Quy trình thiết kế các ca kiểm thử sẽ bắt đầu bằng việc phát

triển các ca kiểm thử sử dụng phương pháp hộp đen và sau đó phát triển bổ

sung các ca kiểm thử cần thiết với phương pháp hộp trắng.

Kiểm thử hộp trắng có liên quan tới mức độ mà các ca kiểm thử

thực hiện hay bao phủ tính logic (mã nguồn) của chương trình. Kiểm thử hộp

trắng cơ bản là việc thực hiện mọi đường đi trong chương trình, nhưng việc

kiểm thử đầy đủ đường đi là một mục đích không thực tế cho một chương

trình với các vòng lặp.

2.2.3. Một số phương pháp chính để thiết kế ca kiểm thử

2.2.3.1. Thiết kế các ca kiểm thử dựa vào ý tưởng phương pháp bao phủ câu

lệnh (Statement Coverage) [2,4,5,8]

Tư tưởng của phương pháp này là thực hiện mọi câu lệnh trong chương

trình ít nhất 1 lần. Phương pháp này bao gồm:

Dựa vào ý tưởng phương pháp bao phủ quyết định (Decision coverage)

24

Ý tưởng của phương pháp này là viết đủ các ca kiểm thử mà mỗi quyết

định có kết luận đúng hay sai ít nhất 1 lần. Nói cách khác, mỗi hướng phân

nhánh phải được xem xét kỹ lưỡng ít nhất 1 lần.

Bao phủ quyết định thường thỏa mãn bao phủ câu lệnh. Vì mỗi câu lệnh

là trên sự bắt nguồn một đường đi phụ nào đó hoặc là từ một câu lệnh rẽ

nhánh hoặc là từ điểm vào của chương trình, mỗi câu lệnh phải được thực

hiện nếu mỗi quyết định rẽ nhánh được thực hiện.

Dựa vào ý tưởng phương pháp bao phủ điều kiện (Condition coverage)

Ý tưởng của phương pháp này là viết đủ các ca kiểm thử để đảm bảo

rằng mỗi điều kiện trong một quyết định đảm nhận tất cả các kết quả có thể ít

nhất 1 lần.

Dựa vào ý tưởng phương pháp bao phủ quyết định/điều kiện

(Decision/condition coverage)

Ý tưởng của phương pháp này là thực hiện đủ các ca kiểm thử mà mỗi

điều kiện trong một quyết định thực hiện trên tất cả các kết quả có thể ít nhất

1 lần, và mỗi điểm vào được gọi ít nhất 1 lần.

Điểm yếu của bao phủ quyết định/điều kiện là mặc dù xem ra nó có thể

sử dụng tất cả các kết quả của tất cả các điều kiện, nhưng thường không phải

vậy vì những điều kiện chắc chắn đã cản các điều kiện khác.

Dựa vào ý tưởng phương pháp bao phủ đa điều kiện (Multiple

condition coverage)

Ý tưởng của phương pháp này là viết đủ các ca kiểm thử mà tất cả

những sự kết hợp của các kết quả điều kiện có thể trong mỗi quyết định, và tất

cả các điểm vào phải được gọi ít nhất 1 lần.

2.2.3.2. Thiết kế các ca kiểm thử dựa vào ý tưởng phương pháp phân lớp

tương đương (Equivalence Patitioning) [2,4,5,8]

25

Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền

đầu vào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca

kiểm thử. Phương pháp này cố gắng xác định ra một ca kiểm thử mà làm lộ ra

một lớp lỗi, do đó làm giảm tổng số các trường hợp kiểm thử phải được xây

dựng.

Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về

các lớp tương đương với một điều kiện vào. Lớp tương đương biểu thị cho tập

các trạng thái hợp lệ hay không hợp lệ đối với điều kiện vào.

Các lớp tương đương được xác định bằng cách lấy mỗi trạng thái đầu

vào (thường là 1 câu hay 1 cụm từ trong đặc tả) và phân chia nó thành 2 hay

nhiều nhóm.

Mặc dù việc phân lớp tương đương là rất tốt khi lựa chọn ngẫu nhiên

các ca kiểm thử, nhưng nó vẫn có những thiếu sót. Chẳn hạn, nó bỏ qua các

kiểu ca kiểm thử có lợi nào đó. Hai phương pháp tiếp theo, phân tích giá trị

biên và đồ thị nguyên nhân - kết quả, bao phủ được nhiều những thiếu sót

này.

2.2.3.3. Thiết kế các ca kiểm thử dựa vào ý tưởng phương pháp phân tích giá

trị biên (Boundary Value Analysis) [2, 4, 5, 8]

Kinh nghiệm cho thấy các ca kiểm thử mà khảo sát kỹ 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:

- 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ớp

tương đương là điển hình, mà nó yêu cầu là 1 hay nhiều phần tử được lựa chọn

như vậy mà mỗi cạnh của lớp tương đương đó chính là đối tượng kiểm tra.

26

- 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ông gian 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.

2.2.3.4. Thiết kế các ca kiểm thử dựa vào ý tưởng phương pháp đồ thị nguyên

nhân - kết quả (Cause - Effect Graphing) [2, 4, 5, 8]

Một yếu điểm của phân tích giá trị biên và phân lớp tương đương là

chúng không khảo sát sự kết hợp của các trường hợp đầu vào. Việc kiểm tra

sự kết hợp đầu vào không phải là một nhiệm vụ đơn giản bởi vì nếu phân lớp

tương đương các trạng thái đầu vào, thì số lượng kết hợp thường là rất lớn.

Nếu không có cách lựa chọn có hệ thống một tập con các trạng thái đầu vào

thì khi chọn ra một tập tùy hứng các điều kiện, điều này có thể dẫn tới việc

kiểm thử không có hiệu quả.

Đồ thị nguyên nhân - kết quả hỗ trợ trong việc lựa chọn một cách có hệ

thống tập các ca kiểm thử có hiệu quả cao. Nó có tác động có lợi ảnh hưởng

tới việc chỉ ra tình trạng chưa đầy đủ và nhập nhằng trong đặc tả. Nó cung cấp

cả cách biểu diễn chính xác cho các điều kiện logic và hành động tương ứng.

Vẽ đồ thị nguyên nhân - kết quả là phương pháp tạo các ca kiểm thử có

hệ thống mô tả sự kết hợp của các điều kiện. Sự thay đổi sẽ là một sự lựa

chọn kết hợp không thể dự tính trước, nhưng khi thực hiện như vậy sẽ bỏ sót

nhiều ca kiểm thử “thú vị” được xác định bằng đồ thị nguyên nhân - kết quả.

Vì đồ thị nguyên nhân - kết quả làm chúng ta mất thời gian trong việc

chọn các giá trị cụ thể cho các toán hạng, nên các điều kiện giới hạn có thể bị

pha trộn thành các ca kiểm thử xuất phát từ đồ thị nguyên nhân - kết quả. Vì

vậy, chúng ta đạt được một tập các ca kiểm thử nhỏ nhưng hiệu quả mà thỏa

mãn cả hai mục tiêu.

27

2.2.3.5. Thiết kế các ca kiểm thử dựa vào ý tưởng phương pháp đoán lỗi -

Error Guessing[2,4,5,8]

Một kỹ thuật thiết kế ca kiểm thử khác là error guessing – đoán lỗi.

Người kiểm thử được đưa cho một 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, cầ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. Kỹ thuật ma trận đồ thị cho thiết kế ca kiểm thử

2.3.1. Ý tưởng và nội dung kỹ thuật ma trận đồ thị [8]

2.3.1.1 Kỹ thuật đồ thị dòng

Một kỹ thuật kiểm thử hộp trắng đầu tiên được Tom McCabe đề nghị là

“kiểm thử đường cơ sở”. Phương pháp đường cơ sở giúp cho người thiết kế

trường hợp kiểm thử có thể suy dẫn ra một cách đo độ phức tạp logic của thiết

kế thủ tục và dùng cách đo này như một hướng dẫn để xác định một tập cơ sở

các đường thực hiện. Các trường hợp kiểm thử được suy dẫn ra để thực hiện

một tập cơ sở, được đảm bảo để thực hiện mọi câu lệnh trong chương trình ít

nhất một lần trong khi kiểm thử

Trong phương pháp đường cơ sở, một hệ thống ký pháp đơn giản được

dùng để biểu diễn cho luồng điều khiển, được gọi là đồ thị dòng (hay đồ thị

28

chương trình). Đồ thị dòng mô tả cho dòng điều khiển logic bao gồm các cấu

trúc cơ bản: sequence, if, while, until, case.

Đồ thị dòng thực chất là một kỹ thuật dựa trên cấu trúc điều khiển của

chương trình. Nó gần giống đồ thị luồng điều khiển của chương trình.

Đồ thị dòng nhận được từ đồ thị luồng điều khiển bằng cách:

- Gộp các lệnh tuần tự và điều khiển liên tiếp thành một lệnh;

- Thay lệnh rẽ nhánh của các đường điều khiển bằng một nút “vị tự”.

Cấu trúc đồ thị dòng gồm:

- Mỗi nút (hình tròn) biểu thị một hay một số lệnh tuần tự và rẽ nhánh

hoặc thay cho điểm phân nhánh hay hội tụ các đường điều khiển.

- Mỗi cạnh nối hai nút biểu diễn dòng điều khiển.

Kết quả đồ thị dòng thể hiện:

- Chia mặt phẳng thành nhiều miền.

- Có nút vị tự biểu thị sự phân nhánh của các cung.

- Mỗi cung nối từng cặp nút biểu diễn luồng điều khiển.

Ví dụ

Xét cấu trúc điều khiển chương trình:

Do while còn bản ghi chưa xử lý

Read bản ghi chưa xử lý

If giá trị trường thứ nhất của bản ghi = 0

then xử lý bản ghi;

Cất vào bộ nhớ;

tăng biến đếm;

Else if giá trị trường thứ hai của bản ghi = 0

then tạo lại bản ghi;

Else xử lý bản ghi;

Cất vào tệp;

29

Endif

Endif

Enddo

Bước 1-Gán nhãn dòng lệnh:

1 Do while còn bản ghi chưa xử lý

Read bản ghi chưa xử lý 2

If giá trị trường thứ nhất của bản ghi = 0 3

then xử lý bản ghi; 4

Cất vào bộ nhớ;

tăng biến đếm; 5

Else if giá trị trường thứ hai của bản ghi = 0 6

then tạo lại bản ghi; 7

Else xử lý bản ghi; 8

Cất vào tệp;

Endif 9

10 Endif

11Enddo

Các dòng lệnh có liên quan đến xử lý dữ liệu đều được đánh số thứ tự

(1,2,…,11), từ đó sẽ được sơ đồ điều khiển của chương trình và sơ đồ luồng

điều khiển

Bước 2-Vẽ sơ đồ điều khiển chương trình:

30

Hình 2.4: Sơ đồ điều khiển của chương trình

Bước 3a- Vẽ sơ đồ luồng điều khiển rút gọn

Hình 2.5: Sơ đồ luồng điều khiển

Bước 3b- Vẽ đồ thị dòng

Từ sơ đồ luồng điều khiển xác định được đồ thị dòng:

31

Hình 2.6 : Đồ thị dòng dùng để xác định ma trận kiểm thử

Các thông số của đồ thị dòng gồm:

E = số cung; N = số nút; P= số nút vị tự

Trong ví dụ có: 9 nút (=N) trong đó 3 nút là vị tự (=P) và 11 cung (=E)

Bước 4- Tính độ phức tạp chu trình:

Để đảm bảo mọi câu lệnh đều được kiểm thử ít nhất một lần, cần tìm

được tất cả các đường điều khiển độc lập trong chương trình (khác nhau ít nhất

một lệnh).

Số các đường độc lập của một chương trình là giới hạn trên số ca kiểm

thử cần tiến hành. Nó được gọi là độ phức tạp chu trình của chương trình.

Tập các đường độc lập/cơ bản (bacsic paths) của một chương trình trùng

với các đường độc lập của đồ thị dòng (tìm đơn giản hơn)

Độ phức tạp chu trình được tính theo công thức:

Với N: Số nút; P: Số nút vị tự; E: Số cung

V(G) = E – N +2 (=11-9+2=4)

Hoặc V(G) = số miền phẳng (=4)

Hoặc V(G) = P + 1 (=3+1=4)

32

Hình 2.7: Độ phức tạp chu trình được xác định từ số miền phẳng trong đồ thị dòng

Với ví dụ về đồ thị dòng ở trên ta có: V(G) = 4 do đồ thị dòng chia mặt

phẳng thành 4 miền: R1, R2, R3, R4. Bước 5- Xác định tập đường cơ bản/các ca kiểm thử:

Xác định các ca kiểm thử bằng cách xác định số miền phẳng trong đồ thị

dòng. Dựa vào hình 2.6 có thể xác định đồ thị trên có 4 miền phẳng tương ứng V(G) = 4.

Như vậy từ đồ thị dòng, do xác định được độ phức tạp chu trình V(G)=4

và suy ra cần thiết kế 4 đường kiểm thử, tạo thành tập đường cơ bản:

Bảng 2.3. Tập đường cơ bản

Tập đường cơ bản

11 1 a

2-3 4-5 10 1 1 b

2-3 6 7 9 10 1 1 c

2-3 6 8 9 10 1 1 d

33

2.3.1.2 Kỹ thuật ma trận kiểm thử

Ma trận kiểm thử là một ma trận vuông có kích thước bằng số các nút

trên đồ thị dòng:

- Mỗi dòng/cột ứng với tên 1 nút;

- Mỗi ô: là tên một cung nối nút dòng đến nút cột.

Nhân liên tiếp k ma trận này ta được ma trận có số ở mỗi ô chỉ số con

đường k cung từ nút dòng tới nút cột.

Ma trận kiểm thử được sử dụng như một dữ liệu có cấu trúc để kiểm tra

các con đường cơ bản: số đường đi qua nút (có thể tính cả trọng số của

chúng).

Ma trận kiểm thử là một công cụ mạnh trong việc đánh giá cấu trúc

điều khiển chương trình. Khi kiểm thử, ta thêm trọng số cho các cung của ma

trận kiểm thử (ma trận kiểm thử có trọng số) như sau:

- Xác suất cung đó được thực thi.

- Thời gian xử lý của tiến trình đi qua cung đó

- Bộ nhớ đòi hỏi của tiến trình đi qua cung đó.

- Nguồn lực đòi hỏi của tiến trình đi qua cung đó.

Ví dụ: Từ đồ thị dòng:

Hình 2.8 : Đồ thị dòng dùng để xác định ma trận kiểm thử

xác định được:

34

Bảng 2.4 : Ma trận kiểm thử A và cách tính độ phức tạp V(G)

Nút 1 23 45 6 7 8 9 1 23 45 6 1 1 1 7 1 8 1 1 1

9 10 11 V(G) = 4 1 1+1-1=1 1+1-1=1 1-1 = 0 1+1-1=1 1-1 = 0 1 1-1 = 0 1 1-1 = 0 1-1 = 0 10 1

11 +1=3+1= 4

(Các số 1 trong ma trận đánh dấu nút dòng đi tới nút cột, ví dụ nút dòng 2,3

xác định chuyển tới nút cột 4,5 nên ô có tọa độ (23,45) được đánh dấu 1).

Bảng 2.5 Bảng ma trận kiểm thử A= (aij) với i,j=1,2,3,4,...,9 được xác

định như sau:

1 1 1 1 1 1 1 1 1 1

1

Độ phức tạp của đồ thị được xác định theo công thức:

V(G) =(Σi(Σjaij)-1)+1)=4 với (i,j=1,...,9)

Để thuận tiện cho việc lập trình, chúng ta xác định cách tính độ phức tạp

theo quy trình sau:

Bước a: tính các tổng theo hàng của ma trận A trừ dòng cuối cùng

T1=a11+ a12+ a13+... +a1,9 = 2

35

T2=a21+ a22+ a23+...+ a2,9 = 2

T3=a31+ a32+ a33+... +a3,9 = 1

T4=a41+ a42+ a43+...+ a4,9 = 2

T5=a51+ a52+ a53+... +a5,9 = 1

T6=a61+ a62+ a33+...+ a6,9= 1

T7=a71+ a72+ a73+... +a7,9 = 1

T8=a81+ a82+ a83+... +a8,9 = 1

Bước b: Tính Ti (i=1,…,14)

T1:=T1-1=1

T2:=T2-1=1

T3:=T3-1=0

T4:=T4-1=1

T5:=T5-1=0

T6:=T6-1 = 0

T7:=T7-1 = 0

T8:=T8-1 = 0

Bước c: Tính V(G)= (T1+T2+...+T8) + 1= 4

Trong đó: (T1+T2+...+T8) cho biết số nút vị tự P là 3 nên

V(G)= P+1= (T1+T2+...+T9) + 1= 3+1 = 4

Như vậy, xác định được số đường phải kiểm thử là 4

Bước d: Xác định được tập đường kiểm thử

Từ đây, chúng ta dễ dàng xác định được tập đường kiểm thử giống

như trên:

Do V(G) = 4 nên xác định được 4 đường kiểm thử giống như phương

pháp xác định V(G) bằng phương pháp tô màu xác định miền phẳng.

36

Tập đường cơ bản

a 1 11

b 1 2-3 4-5 10 1

c 1 2-3 6 7 9 10 1

d 1 2-3 6 8 9 10 1

Ma trận kiểm thử tích A2

Bảng 2.6 : Ví dụ ma trận kiểm thử tích A2=

Nút 1 23 45 6 7 8 9 10 11 1 1 1 23 1 45 1 6 1 7 1 8 1 9 2 10 1 1 1 11 1

(Các số trong ma trận cho biết số con đường có hai cạnh đi qua cung đó).

2.3.2. Quy trình kiểm thử phần mềm bằng kỹ thuật ma trận đồ thị

Kiểm thử phần mềm bằng kỹ thuật ma trận đồ thị cần tuân theo lộ trình sau:

Giai đoạn 1:

- Nhập văn bản mô-đun chương trình cần kiểm thử

- Lập bảng biểu diễn luồng dữ liệu của đồ thị dòng

Giai đoạn 2:

- Lập bảng ma trận đồ thị

- Lập bảng tính độ phức tạp của đồ thị dòng V(G)

37

Giai đoạn 3:

- Xác định số đường kiểm thử

- Lập bảng kết quả xác định tập đường cơ bản

Giai đoạn 4:

- Nhập các inputs cho các test path

-Thực hiện các test cases và cho ra các bảng so sánh kết quả thực và kết

quả mong đợi

Giai đoạn 5:

- Nhập các input cho các ca kiểm thử cho kiểm thử vòng lặp

- Thực hiện các test cases và cho ra các bảng so sánh kết quả thực và kết

quả mong đợi

Giai đoạn 6:

- Đánh giá kết quả thử nghiệm.

38

CHƯƠNG 3

CHƯƠNG TRÌNH THỬ NGHIỆM KIỂM THỬ PHẦN MỀM

BẰNG KỸ THUẬT MA TRẬN ĐỒ THỊ

3.1. Chọn mô-đun phần mềm thử nghiệm

Mô-đun phần mềm thử nghiệm được chọn là mô-đun “Thủ tục tính giá

trị trung bình của 100 số hay ít hơn, nằm giữa các giá trị cận, tính tổng số

phần tử hợp lệ” [15]:

PROCEDURE average;

INTERFACE RETURNS average, total.input, total.valid;

INTERFACE ACCEPT value, minimum,maximum;

TYPE value [1:100] IS SCALAR ARRAY;

TYPE average, total.input, total.valid;

minimum, maximum, sum IS SCALAR;

TYPE i IS INTERGER;

I=1;

total.input= total.valid=0;

sum=0;

DO WHILE value[i] <> -999 AND total.input < 100;

Increment total.input by 1;

IF value[i] >= minimum AND value[i] <= maximum

THEN

Begin

increment total.valid by 1; Sum=sum+ value[i]

end

ENDIF

Increment i by 1;

ENDDO

IF total.valid > 0

THEN average = sum/ total.valid;

ELSE average = -999;

ENDIF

39

END average

3.2. Thiết kế ca kiểm thử và kiểm thử mô-đun phần mềm

3.2.1. Quy trình thiết kế

Bài toán thiết kế ca kiểm thử và kiểm thử mô-đun phần mềm được tuân

theo quy trình thiết kế chuẩn sau đây [15]:

Bước 1- Gán nhãn dòng lệnh

Bước 2- Vẽ sơ đồ điều khiển của chương trình

Bước 3- Vẽ sơ đồ luồng điều khiển rút gọn và đồ thị dòng

Bước 4- Xác định độ phức tạp của chu trình

Bước 5- Xác định tập đường cơ bản

Bước 6- Xác định các Inputs cho các test path

Bước 7- Xác định các ca kiểm thử cho kiểm thử vòng lặp While

3.2.2. Nội dung thiết kế

Trình tự thiết kế bao gồm các bước sau:

Bước 1- Gán nhãn dòng lệnh

PROCEDURE average;

INTERFACE RETURNS average, total.input, total.valid;

INTERFACE ACCEPT value, minimum,maximum;

TYPE value [1:100] IS SCALAR ARRAY;

TYPE average, total.input, total.valid;

minimum, maximum, sum IS SCALAR;

TYPE i IS INTERGER;

i=1;

total.input= total.valid=0; 1

sum=0;

DO WHILE value[i] <> -999 AND total.input < 100 2 3

Increment total.input by 1; 4

IF value[i] >= minimum AND value[i] <= maximum 5 6

40

THEN Begin

7 increment total.valid by 1; Sum=sum+value[i];

End

ENDIF 8

Increment i by 1; 9

ENDDO 10

IF total.valid > 0 11

THEN average = sum/ total.valid; 12

ELSE average = -999; 13

ENDIF 14

END average

1

2

Bước 2- Vẽ sơ đồ điều khiển của chương trình

đ

s

10

3

đ

11

4

s

đ

12

5

s

đ

14

s

6

8

đ

7

9

s 13

Hình 3.1. Sơ đồ điều khiển của chương trình

41

Bước 3a- Vẽ Sơ đồ luồng điều khiển rút gọn

Việc rút gọn đã được thực hiện khi dán nhãn nên ta vẫn có sơ đồ

1

2

luồng điều khiển sau:

s

s

10

3

đ

11

4

đ

12

13

5

s đ

14

s đ

6

8

s

7

9

đ

Hình 3.2. Sơ đồ luồng điều khiển

Bước 3b- Vẽ Đồ thị dòng

Từ sơ đồ luồng điều khiển xác định được đồ thị dòng gồm:

N - số nút = 14

P - số nút vị tự = 5 (nút sẫm màu)

E - số cung = 18

1

2

10

3

11

4

12

13

5

14

6

8

7

9

42

Hình 3.3. Đồ thị dòng

Bước 4- Xác định độ phức tạp của chu trình

Độ phức tạp của chu trình được xác định bằng số miền phẳng trong đồ

thị dòng:

Độ phức tạp của chu trình V(G) của đồ thị được tính theo 3 cách sau:

V(G) = E – N + 2= 18 – 14 + 2= 6, hoặc

V(G)= số miền phẳng= 6, hoặc V(G)= P+1= 5+1=6

1

2

R1

10

3

R6

11

4

12

13

R5

5

14

R4

R2

6

8

R3

7

9

43

Hình 3.4. Độ phức tạp của chu trình

Bước 5- Xác định tập đường cơ bản

Cách 1-Xác định tập đường cơ bản theo số miền phẳng

Do xác định được có 6 miền phẳng nên có được 6 đường kiểm thử.

Tập đường cơ bản xác định được bao gồm:

Path1: 1-2-10-11-12-14 Path2: 1-2-10-11-13-14 Path3: 1-2-3-10-11-12-14 Path4: 1-2-3-4-5-8-9-2-10-11-12-14 Path5: 1-2-3-4-5-6-8-9-2-10-11-12-14 Path6: 1-2-3-4-5-6-7-8-9-2-10-11-12-14

44

Cách 2-Xác định tập đường cơ bản theo ma trận đồ thị

1

2

10

3

11

4

12

113

5

14

6

8

7

9

Theo trên, chúng ta có Đồ thị dòng:

Hình 3.5. Đồ thị dòng

Từ đồ thị dòng, xác định “ma trận kiểm thử”:

Ma trận kiểm thử, ký hiệu là A=(aij) với i,j=1,2,3,...,n, là một ma trận

vuông cấp n, có kích thước bằng số các nút (n=14) trên đồ thị dòng:

- Mỗi dòng/ cột ứng với tên một nút;

- Mỗi ô: là tên một cung nối nút dòng đến nút cột.

Nhân liên tiếp k ma trận này ta được ma trận có số ở mỗi ô chỉ số con

đường k cung từ nút dòng tới nút cột.

Ma trận kiểm thử được sử dụng như một dữ liệu có cấu trúc để kiểm tra

các con đường cơ bản: số đường đi qua nút (có thể tính cả trọng số của

chúng).

- Ma trận kiểm thử là một công cụ mạnh trong việc đánh giá cấu trúc

điều khiển chương trình.

45

3

4

5

6

7

8

9 10 11 12 13 14

V(G)=6

2

1-1=0

1

nút 1

1.

1

1+1-1=1

1

2.

1

1+1-1=1

1

3.

1-1=0

1

4.

1

1+1-1=1

1

5.

1

1+1-1=1

1

6.

1

1-1=0

7.

1

1-1=0

8.

1-1=0

1

9.

1

1-1=0

10.

1

1

1+1-1=1

11.

1

12.

1

13.

V(G)=

14.

theocot+1=

5+1=6

Bảng 3.1-Bảng tính độ phức tạp của đồ thị dòng V(G):

(Các số 1 trong ma trận đánh dấu nút dòng đi tới nút cột, ví dụ nút dòng

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

2 xác định chuyển tới nút cột 3 nên có tọa độ (2,3) được đánh dấu 1). Bảng 3.2: Bảng ma trận kiểm thử A= (aij) với i,j=1,2,3,4,...,14

46

Độ phức tạp của đồ thị được xác định theo công thức:

V(G) = +1 = 6

Để thuận tiện cho việc lập trình, chúng ta xác định cách tính độ phức tạp

theo quy trình sau:

Bước a: tính các tổng theo hàng của ma trận A trừ dòng cuối cùng

T1=a11+ a12+ a13+... +a1,14 = 1

T2=a21+ a22+ a23+...+ a2,14 = 2

T3=a31+ a32+ a33+... +a3,14 = 2

T4=a41+ a42+ a43+...+ a4,14 = 1

T5=a51+ a52+ a53+... +a5,14 = 2

T6=a61+ a62+ a33+...+ a6,14 = 2

T7=a71+ a72+ a73+... +a7,14 = 1

T8=a81+ a82+ a83+... +a8,14 = 1

T9= a91+ a92+ a93+... +a9,14 = 1

T10=a10,1+ a10,2+ a10,3+... +a10,14 = 1

T11=a11,1+ a11,2+ a11,3+... +a11,14 = 2

T12=a12,1+ a12,2+ a12,3+... +a12,14 =1

T13=a13,1+ a13,2+ a13,3+... +a13,14 = 1

T14=a14,1+ a14,2+ a14,3+... +a14,14 = 1

Bước b: Tính Ti (i=1,…,14)

T1:=T1-1=0

T2:=T2-1=1

T3:=T3-1=1

T4:=T4-1=0

T5:=T5-1=1

T6:=T6-1 = 1

T7:=T7-1 = 0

47

T8:=T8-1 = 0

T9 := T9-1 = 0

T10:= T10-1 = 0

T11:= T11-1 =1

T12:= T12-1 = 0

T13:= T13-1 = 0

T14:= T14-1 = 0

Bước c: Tính V(G)= (T1+T2+...+T14) + 1=6

Trong đó: (T1+T2+...+T9) chính là số nút vị tự P

V(G)= P+1= (T1+T2+...+T14) + 1= 5+1 = 6

Như vậy, xác định được số đường phải kiểm thử là 6

Bước d: Xác định được tập đường kiểm thử

Từ đây, chúng ta dễ dàng xác định được tập đường kiểm thử giống như

trên:

Path1: 1-2-10-11-12-14

Path2: 1-2-10-11-13-14

Path3: 1-2-3-10-11-12-14

Path4: 1-2-3-4-5-8-9-2-10-11-12-14

Path5: 1-2-3-4-5-6-8-9-2-10-11-12-14

Path6: 1-2-3-4-5-6-7-8-9-2-10-11-12-14

48

Bước 6- Xác định các Inputs cho các test path:

Bảng 3.3: Các Test path

Dữ liệu vào Kết quả Kết quả mong đợi Ghi chú

Path 1 không thể

Path 1 test case

được kiểm thử

value (k)= dữ value (i)=-999 average là đúng dựa trên

đơn độc mà phải

liệu vào hợp lệ, với 2≤ i ≤100 các giá trị k và các tổng

thử như là một

where k

phần của các