• Không có kết quả nào được tìm thấy

Kỹ thuật đồ thị nguyên nhân – kết quả (Cause – Effect Graphing)

CHƯƠNG 2. CÁC KỸ THUẬT THIẾT KẾ CA KIỂM THỬ

2.4. Kỹ thuật đồ thị nguyên nhân – kết quả (Cause – Effect Graphing)

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

Quá trình dưới đây được sử dụng để xây dựng được các ca kiểm thử:

1. Đặc tả được chia thành các phần có thể thực hiện được. Điều này là cần thiế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ên

khảo sát thỏa đáng các điều kiện giới hạn. Dĩ nhiên, có thể cố gắng bao phủ các điều kiện giới hạn trong suốt quá trình.

Tuy nhiên, vấn đề trong việc thực hiện điều này là nó làm cho đồ thị rất phức tạp và dẫn tới số lượng rất lớn các ca kiểm thử. Vì thế, tốt nhất là xét một sự phân tích giá trị giới hạn tách rời nhau.

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.

Chú ý là việc vẽ đồ thị nguyên nhân – kết quả phù hợp với một số quy tắc nhất định. Việc xác định đầu ra mong đợi cho mỗi ca kiểm thử là một phần cố hữu của kỹ thuật (mỗi cột trong bảng quyết định biểu thị các kết quả được mong đợi). Cũng chú ý là nó khuyến khích chúng ta tìm kiếm các kết quả có tác dụng không mong muốn.

Khía cạnh khó nhất của kỹ thuật này là quá trình chuyển đổi đồ thị thành bảng quyết định. Quá trình này có tính thuật toán, tức là bạn có thể tự động hóa nó bằng việc viết một chương trình. Trên thị trường đã có một vài chương trình thương mại tồn tại giúp cho quá trình chuyển đổi này.

Kỹ thuật đồ thị nhân- quả là một kỹ thuật để thiết kế ca kiểm thử. Nó cung cấp một biểu diễn chính xác giữa các điều kiện logic (đầu vào) và các hành động tương ứng (đầu ra- kết quả).

Kỹ thuật đồ thị nhân- quả được xây dựng dựa trên các mô-đun chức năng, lôgíc tiến trình và đặc tả hệ thống.

Hình 2.7. Các bước tiến hành theo kỹ thuật đồ thị nhân- quả

Ví dụ:

Bảng 2.7. Danh sách nhân- quả theo mô-đun

Mô-đun Nguyên nhân Kết quả Định danh

nhân - quả

A Số > a đúng A1

Số ≥ a nghi ngờ A2

Số = a nghi ngờ A3

Số < a sai A4

B Số nguyên đúng B

Có nhiều công cụ để xây dựng đồ thị nhân- quả. Đồ thị có hướng hay được dùng hơn cả.

Hình 2.8. Xây dựng đồ thị nhân -quả bằng đồ thị

Bảng 2.8. Bảng quyết định của đồ thị nhân - quả

Định danh Điều kiện Đúng Nghi ngờ Sai

A1 Số > a X

A2,A3 Số ≥ a X

A4 Số < a X

B Số nguyên X

.. .. ..

Chọn 2 ca kiểm thử

Hình 2.9. Các phương án lựa chọn ca kiểm thử 2.5. Kỹ thuật đoán lỗi (Error Guessing)

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

chất của chương trình), hãy thêm vào các ca kiểm thử có khả năng

1. Cầu thang đang đứng tại tầng được chọn. Khi đó cầu thang bắt đầu hoạt động, cửa được mở:

2. Nếu cầu thang đang đứng ở một tầng khác: tầng trên hay dưới tầng được chọn, cầu thang cần di chuyển xuống (lên) đến tầng được chọn thì dừng lại và mở cửa.

3. Cầu thang đang di chuyển (đã mô tả ở trên).

Hãy thiết kế các ca kiểm thử để kiểm thử hệ thống này ?

Mô hình hóa hệ thống bằng sơ đồ trạng thái có 4 trạng thái và có 12 đường mũi tên chuyển từ 1 trạng thái (tầng) đến 3 trạng thái (các tầng) còn lại. Kết quả ta được đồ thị có hướng (4 nút và 12 cung):

Hình 2.10. Sơ đồ trang thái hệ thống thang máy

- Cần thiết kế các ca kiểm thử để kiểm thử cầu thang thực hiện các chức năng:

- Ở 4 vị trí 4 tầng (phủ mọi trạng thái).

- Từ một tầng thang máy có thể đến mọi tầng khác, (phủ mọi chuyển trạng thái).

- Việc chuyển đến một trạng thái khác (tầng) được quyết định bằng phím được chọn (điều kiện).

- khi bắt đầu chọn hướng di chuyển ở tầng, cầu thang đang ở vị trí khác (tầng trên/dưới), cần thực hiện chuyển trạng thái từ tầng đang đứng về trạng thái tầng được chọn.

Ca kiểm thử 1: kế hoạch sử dụng đường đi: 1-2-3-4 sẽ phủ được 4 trạng thái của hệ thống

Bảng 2.9. Bảng dữ liệu phục vụ cho ca kiểm thử 1

Dữ liệu vào Kết quả ra

Trạng thái xuất phát

Sự kiện chon tầng

Trạng thái Chuyển trạng thái Dự kiến Thực tế Dự kiến Thực tế

1 2, 3, 4 2 1,2

3 2,3

4 3,4

Để bao phủ mọi chuyển trạng thái, tìm một chu trình ơle chứa đoạn đầu tiên 1-2-3-4 (Điều này có thể thực hiện được, vì mỗi đỉnh của đồ thị đều có số cung vào bằng số cung ra).

Chu trình ơle là đường đi qua mọi cạnh của đồ thị và đi qua đúng 1 lần.

Nó là cơ sở thiết kế ca kiểm thử 2 (bao gồm cả ca kiểm thử 1).

Ca kiểm thử 2: 1-2-3-4-2-1-4-3-2-4-1-3-1

Trạng thái cầu thang

Trạng thái tầng, nút chọn

Trạng thái đến Chuyển trạng thái Dự kiến Thực tế Dự kiến Thực tế

1 T3, nút lên 3 1,3

3 T2, nút xuống 2 3,2

CHƯƠNG 3

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

4 then process record;

store in buffer;

5 increment counter;

6 Else if record field2 = 0 7 then reset record;

8 Else process record;

store in file;

9 Endif 10 Endif 11 Enddo

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

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

Trong lập trình, nếu vẽ được đồ thị thì tốt, nhưng cần xác định tổng số các nút và tổng số các cung.

Bước 3: vẽ Sơ đồ luồng điều khiển

Trong chương trình : rút gọn số nút và cung

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

Bước 4: tính các thông số của đồ thị dòng theo cả 2 công thức (1) và (3) Các thông số của đồ thị dòng trong ví dụ gồm:

9 nút (=N), trong đó:

3 nút là vị tự (= P) 11cung (= E)

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

Đồ thị dòng chia mặt phẳng thành 4 miền: R1, R2, R3, R4

Hình 3.5. Độ phức tạp chu trình xác định từ đồ thị dòng

Để bảo đảm mọi câu lệnh đều được kiểm thử ít nhất 1 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 1 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 (basic 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).

Bước 5: Tính độ phức tạp chu trình để xác định số đường (ca) kiểm thử Tính toán độ phức tạp chu trình:

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

(1) V(G) = E - N + 2 (= 11-9+2 = 4) (2) V(G) = số miền phẳng (= 4)

(3) V(G) = P + 1 (= 3+ 1 =4)

Trong đó: E = số cung; N = số nút; P= số nút vị tự Với ví dụ về đồ thị dòng ở trên ta có: V(G) = 4 Xác định các ca kiểm thử:

R1

R2

R3 R4

Từ đồ thị dòng, 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 trong bảng 3.1.

Bước 6: xác định tập đường cơ bản

Bảng 3.1. Tập đường cơ bản 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

Bước 7: Phương pháp Ma trận kiểm thử để xác định tập đường kiểm thử Ví dụ:

Xét một cấu trúc điều khiển chương trình 1 Do while còn bản ghi chưa xử lý 2 Read bản ghi chưa xử lý

3 if giá trị trường thứ nhất của bản ghi = 0 4 then xử lý bản ghi;

Cất vào bộ nhớ;

5 tăng biến đếm;

6 else if giá trị trường thứ hai của bản ghi = 0 7 then tạo lại bản ghi;

8 else xử lý bản ghi;

Cất vào tệp;

9 end if

10 end if 11 end do

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

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

Trên cơ sở gộp các lệnh thực hiện tuần tự liền kề với nhau hoặc lệnh thực hiện liền kề rẽ nhánh, ta có sơ đồ luồng điều khiển (hình 3.7)

Hình 3.7. Sơ đồ luồng điều khiển gộp

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

Từ sơ đồ luồng điều khiển gộp xác định được đồ thị dòng (hình 3.8). Các thông số của đồ thị dòng gồm:

9 nút (= N), trong đó:

3 nút là vị tự (= P) (nút được đánh dấu tô màu sẫm).

11 cung (= E).

Cho đơn giản, chúng ta đánh số lại đồ thị dòng sẽ được đồ thị dòng mới

Hình 3.9. Đồ thị dòng dùng để xác định ma trận kiểm thử Từ đồ thị dòng này, 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) 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. 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 đó.

Bảng 3.2 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 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).

Do đó ta có bảng ma trận kiểm thử A= (aij) với i,j=1,2,3,4,...9:

1 1

1 1

1

1 1

1 1

1 1

Bảng 3.3 Bảng ma trận kiểm thử A = (aij)

Từ ma trận A, xác định độ phức tạp của đồ thị trong ví dụ bằng công thức:

V(G) = +1 = 4

Để 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 1: 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+... +a19=2

T2=a21+ a22+ a23+...+ a29 =2 T3=a31+ a32+ a33+... +a39 =1 T4=a41+ a42+ a43+...+ a49 =2 T5=a51+ a52+ a53+... +a59 =1 T6=a61+ a62+ a33+...+ a69 =1 T7=a71+ a72+ a73+... +a79 =1 T8=a81+ a82+ a83+... +a89 = 1 T9= a91+ a92+ a93+... +a99 = 0 Bước 2: Tính

T1:=T1-1=1

T3:=T3-1=0

gồm:

1-Viết chương trình tính tổng S = 1+2+...+N bằng cách dùng vòng lặp WHILE;

2-Viết chương trình giải phương trình bậc nhất ax+b=0;

3-Viết chương trình giải phương trình bậc hai: ax2 + bx + c = 0, a0.

2.Write('Nhap vao gia tri cua N :');

3.Readln(N);

4.S:=0;

5.i:=1;

6.While i<=N Do Begin

7.S:=S+i;

8.i:=i+1;

End;

9.Writeln('Ket qua la ',S);

10.Readln;

End.

Bước 2: Sơ đồ điều khiển

Bước 3: Đồ thị dòng để xác định ma trận kiểm thử

Bước 4: Ma trận kiểm thử và Độ phức tạp V(G)

Nút 1,2,3,4,5 6 7,8 9,10 V(G)=2

1,2,3,4,5 1 1-1=0

6 1 1 1+1-1=1

7,8 1 1-1=0

9,10 ∑+1=1+1=2

Bước 5: Tập đường kiểm thử

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

A 12345 6 9,10

B 12345 6 7,8 6

Bài tập 2 (trung bình)

Viết chương trình giải phương trình bậc nhất ax+b=0:

9. readln;

End.

Bước 2: Sơ đồ điều khiển

Bước 3: Đồ thị dòng để xác định ma trận kiểm thử

Bước 4: Ma trận kiểm thử và Độ phức tạp V(G)

Nút 1 2 3 4 5 6 7 8 9 V(G)=3

1. 1 1-1=0

2. 1 1 1+1-1=1

3. 1 1 1+1-1=1

4. 1 1-1=0

5. 1 1-1=0

6. 1 1-1=0

7. 1 1-1=0

8. 1 1-1=0

9. ∑+1=2+1=3

Bước 5: Tập đường kiểm thử

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

A 1 2 3 4 6 8 9

B 1 2 3 5 6 8 9

Bước 1: Gán nhãn

Bước 3: Đồ thị dòng để xác định ma trận kiểm thử

Bước 4: Ma trận kiểm thử và Độ phức tạp V(G)

Nút 1 2 3 4 5 6 7 8 9 10 11 12 13 14 V(G)=5

1. 1 1-1=0

2. 1 1 1+1-1=1

3. 1 1-1=0

4. 1 1-1=0

5. 1 1 1+1-1=1

6. 1 1-1=0

7. 1 1 1+1-1=1

8. 1 1-1=0

9. 1 1-1=0

10. 1 1-1=0

11. 1 1-1=0

12. 1 1-1=0

13. 1 1 1+1-1=1

14. ∑+1=4+1=5

Bước 5: Tập đường kiểm thử

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

a 1 2 4 5 6 11 12 13 2

b 1 2 4 5 6 11 12 13 14

c 1 2 3 4 5 6 11 12 13 14

d 1 2 4 5 7 9 10 11 12 13 14

e 1 2 4 5 7 8 10 11 12 13 14

3.3. Một số giao diện chính của chương trình 3.3.1. Form chính

Hình 3.1. Form chính của chương trình 3.3.2. Form chọn dường dẫn tới dữ liệu

Nhấn nút “OPEN” để chọn đường dẫn.

Hình 3.2. Form chọn dường dẫn tới dữ liệu 3.3.3. Hiển thị dữ liệu

Sau khi chọn file dữ liệu, Form main hiển thị:

Hình 3.3. Form hiển thị dữ liệu 3.3.4. Tính toán độ phức tạp

Nhấn vào nút “Tính độ phức tạp”

3.3.5. Xuất ra các phương án kiểm thử Nhấn nút “Tập kiểm thử”

3.4. Đánh giá kết quả thử nghiệm và hướng phát triển 3.4.1. Đánh giá

- Kết quả thử nghiệm cho ra một tập các đường cơ bản đúng như ví dụ trên.

- Chương trình thực hiện cho kết quả đúng theo thuật toán trên.

3.4.2. Hướng phát triển

- Phát triển chương trình có thể xử lý được với giải thuật với ngôn ngữ C, C++, ...

- Phát triển chương trình có thể tìm ra các tập kiểm thử với các số liệu cụ thể.

KẾT LUẬN

Ở Việt Nam ngành Công Nghệ Phần Mềm vẫn được coi là khá non trẻ, chưa có nhiều thành tựu lớn. Kiểm Thử Phần Mềm vẫn còn là một vấn đề khá mới mẻ.

Việc nghiên cứu lựa chọn các kỹ thuật và chiến lược Kiểm Thử Phần Mềm phù hợp giúp cho việc kiểm thử có hiệu quả, giảm chi phí và thời gian.

Việc xây dựng tài liệu Kiểm Thử Phần Mềm hợp lý sẽ giúp cho việc tổ chức, quản lý và thực hiện kiểm thử có hiệu quả.

Trong khuôn khổ một luận văn thạc sĩ, tác giả nghiên cứu các kĩ thuật xác định các ca kiểm thử và dữ liệu kiểm thử dựa trên ma trận kiểm thử và ứng dụng kiểm thử các bài toán Pascal trong chương trình THCS tại trường THCS Thủy Sơn.

Do thời gian giới hạn nên chương trình mới chỉ dừng lại ở kiểm thử các bài bài toán cơ bản trong chương trình Pascal THCS, trong thời gian tới tác giả sẽ tiếp tục phát triển chương trình để trở thành một ứng kiểm thử được tất cả các bài toán Pascal và các bài của các ứng dụng khác, hoàn chỉnh, bổ sung thêm các chức năng kiểm thử cú pháp, kiểm thử các java scripts, kiểm thử khuôn dạng dữ liệu và kiểm thử các giao dịch web.

Hiện nay vấn đề Kiểm Thử Phần Mềm hầu như vẫn chưa được đầu tư và quan tâm đúng mức. Việt Nam ta đang trong quá trình xây dựng một ngành công nghiệp phần mềm thì không thể xem nhẹ việc Kiểm Thử Phần Mềm vì xác suất thất bại sẽ rất cao, hơn nữa, hầu hết các công ty phần mềm có uy tín đều đặt ra yêu cầu nghiêm ngặt là nếu một phần mềm không có tài liệu kiểm thử đi kèm thì sẽ không được chấp nhận.

TÀI LIỆU THAM KHẢO 1. Tiếng việt

[1]. Thạc Bình Cường, Nguyễn Đức Mận (2011), Kiểm thử và đảm bảo chất lượng phần mềm. NXB Bách Khoa Hà Nội.

[2]. Lê Văn Phùng (2010), Kỹ nghệ phần mềm. Nhà xuất bản thông tin và truyền thông.

[3]. Lê Văn Phùng (2013), Kỹ nghệ phần mềm nâng cao. Nhà xuất bản thông tin và truyền thông.

[4]. Ngô Trung Việt (2000), Kỹ nghệ phần mềm (bản dịch tiếng việt:

Roger S.Pressman. Software Engineering, a Practitioner’s Approach. 3th Edition, McGraw-Hill,1992), 3 tập, Nhà xuất bản Giáo dục.

[5]. Nguyễn Văn Vỵ, Nguyễn Việt Hà (2009), Giáo trình kỹ nghệ phần mềm. Nhà xuất bản Giáo dục Việt Nam.

2. Tiếng Anh

[6]. Berard M. (2001), Systems and software verification.Model-Checking techniques and tools. Springer.

[7]. Boehm B. (1981), Software Engineering Economics, Prentice Hall.

[8]. John C.Munson, ph.D. (2005), Software specification and design. An Engineering Approach, Taylor & Francis.

[9]. John C.Munson, ph.D. (2003), Software Engineering measurement, Taylor & Francis.

[10]. Roger S.Pressman (1992). Software Engineering, a Practitioner’s Approach. 3th Edition, McGraw-Hill, Inc.

[11]. Sommerville Ian (2004), Software Engineering, Addison-Wesley, 4th,1992, 6th, 2001, 7th Editor Chapter 19.