Kiểm thử hộp trắng, áp dụng trên công cụ NUnit

Tuy nhiên ở Việt Nam hiện nay, việc kiểm thử phần mềm vẫn chưa thực sự được nhìn nhận đúng với tầm quan trọng của nó.. Điều này thể hiện ở tỷ lệ kỹ sư kiểm thử phần mềm ở Việt Nam còn kh

LỜI NÓI ĐẦU

Trong giai đoạn phát triển của công nghệ thông tin, ngành công nghệ phần mềm đang ngày một chiếm vị trí quan trọng trong xu hướng phát triển kinh tế công nghiệp hóa, hiện đại hóa của đất nước ta Cùng với sự phát triển của công nghệ phần mềm, lỗi phần mềm và chất lượng phần mềm luôn là thách thức lớn với bản thân ngành phần mềm khi thực tế đã chứng minh, kiểm thử phần mềm là giai đoạn chiếm đến hơn 40% thời gian, kinh phí và nguồn nhân lực phát triển dự án phần mềm Tuy nhiên ở Việt Nam hiện nay, việc kiểm thử phần mềm vẫn chưa thực sự được nhìn nhận đúng với tầm quan trọng của nó Điều này thể hiện ở tỷ lệ kỹ sư kiểm thử phần mềm ở Việt Nam còn khá thấp, cứ 5 lập trình viên thì mới có 1 kỹ

sư kiểm thử (số liệu thống kê năm 2011 của công ty LogiGear), trong khi tỷ lệ này theo chuẩn quốc tế là 3:1 Thêm vào đó, mức độ đáp ứng của kỹ sư kiểm thử phần mềm ở Việt Nam chưa cao Nguyên nhân của việc này đến từ sự thiếu hụt các đơn

vị đào tạo chuyên sâu về kiểm thử và nguyên nhân sâu xa vẫn là vấn đề kiểm thử phần mềm ở Việt Nam vẫn chưa được chuyên nghiệp hóa và đầu tư đúng mức

Ngày nay, tự động hóa đang được nghiên cứu và ứng dụng trong nhiều lĩnh vực trong đó công nghệ phần mềm nói chung và kiểm thử phần mềm nói riêng cũng không ngoại lệ Khi mà kiểm thử phần mềm vẫn tiêu tốn một lượng lớn thời gian, kinh phí và nhân lực trong một dự án phần mềm thì song song với kiểm thử truyền thống thủ công, sự ra đời của các công cụ hỗ trợ kiểm thử tự động như Quick Test Professional, Nunit, Junit, Load Runner (thường dùng trong kiểm thử hiệu năng) là tất yếu

Với mong muốn có cái nhìn xác thực, rõ ràng hơn về kiểm thử phần mềm và tiếp cận được với công cụ kiểm thử tự động NUnit để làm nền tảng cho công việc

sau này.Nhóm chúng em đã cùng tìm hiểu về đề tài Kiểm thử hộp trắng, áp dụng

trên công cụ NUnit Xin chân thành cảm ơn Cô Lê Thị Thu Hương đã nhiệt tình giúp đỡ chúng em trong quá trình thực hiện đề tài Trong khuôn khổ đồ án môn học, do thời gian và kinh nghiệm thực tế còn hạn chế nên có những phần thực hiện chưa được tốt, chúng em rất mong nhận được sự góp ý của quý thầy cô và các bạn

I. Tổng quan về kiểm thử hộp trắng

- Đối tượng được kiểm thử là 1 thành phần phần mềm (TPPM) TPPM

có thể là 1 hàm chức năng, 1 module chức năng, 1 phân hệ chức năng…

- Kiểm thử hộp trắng dựa vào thuật giải cụ thể, vào cấu trúc dữ liệu bên trong của đơn vị phần mềm cần kiểm thử để xác định đơn vị phần mềm

đó có thực hiện đúng không

- Do đó người kiểm thử hộp trắng phải có kỹ năng, kiến thức nhất định

về ngôn ngữ lập trình được dùng, về thuật giải được dùng trong TPPM để có thể thông hiểu chi tiết về đoạn code cần kiểm thử

- Thường tốn rất nhiều thời gian và công sức nếu TPPM quá lớn

(thí dụ trong kiểm thử tích hợp hay kiểm thử chức năng)

- Do đó kỹ thuật này chủ yếu được dùng để kiểm thử đơn vị Trong lập trình hướng đối tượng, kiểm thử đơn vị là kiểm thử từng tác vụ của 1 class chức năng nào đó

- Kiểm thử hộp trắng là một thiết kế kiểm thử sử dụng cấu trúc của thiết kế chi tiết, dựa vào cấu trúc/mã lệnh chương trình

- Với kiểm thử hộp trắng người kiểm thử phải biết ngôn ngữ lập trình Phương pháp này kiểm tra trạng thái chương trình tại nhiều điểm

- Bao gồm hai kỹ thuật:

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

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

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

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

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

1 Dùng tài liệu thiết kế hay mã nguồn để vẽ thuật toán của chương trình hay hàm

2 Xác định đồ thị V(G)

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

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

Mô tả một số cấu trúc theo lược đồ

4 THEN value := - value ;

5 WHILE ( i < value ) AND ( result <= maxint )

6 BEGIN i := i + 1 ;

7 result := result + i ;

8 END;

9 IF result <= maxint

10 THEN OUTPUT ( result )

11 ELSE OUTPUT ( “Error” )

12 END

Thuật toán

Ví dụ thuật toán

Đồ thị:

- Đ7: 1-2-3-5-6-7-5-9-10-12

- Đ8: 1-2-3-5-6-7-5-9-11-12

Ta có một số mẫu kiểm thử sau:

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

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

Là phương pháp kiểm thử dựa trên những điều kiện logic của hàm hay module Bao gồm:

- Điều kiện đơn: Một biến X kiểu logic-boolean (hoặc not X)

- Biểu thức quan hệ: A op B, trong đó: op={<, >, ≤ , ≥, =, <>}, A và B

là các biểu thức

- Điều kiện phức hợp: Kết hợp hơn một điều kiện đơn, biểu thức quan

hệ , cùng với các toán tử logic: and, or, not

Những lỗi phát hiện được:

- Lỗi do giá trị của biến

- Lỗi do dấu ngoặc

- Lỗi do phép toán quan hệ

- Lỗi trong biểu thức quan hệ

Tuy nhiên: Không thỏa mãn với mọi giá trị input, cần kết hợp cả x và

y để thực hiện bước kiểm tra

Ví dụ 2:

while (x > 0 || y > 0) {

x ; y ;

z += x*y;

} Với bộ kiểm tra { (x>0) } sẽ kiểm tra bao trùm được các điều kiện Tuy nhiên: Không kiểm tra được giá trị y

B.2 Kiểm thử luồng dữ liệu (DTF)

Là lựa chọn một số đường diễn tiến của chương trình dựa trên việc cấp phát, định nghĩa, và sử dụng những biến trong chương trình

Phương pháp này phù hợp cho việc kiểm thử một chương trình có nhiều lệnh if và vòng lặp nhiều cấp 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 được kiểm thử ít nhất một lần Tuy nhiên, phương pháp này không đảm bảo kiểm thử tất cả các nhánh của chương trình

Ở đâ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 không được thay đổi thông số của nó và biến toàn cục

Định nghĩa X:

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

Có hai kiểu định nghĩa:

- I-def (Khai báo hay truyền vào/nhập vào X): int X

- A-def (Gán giá trị cho X): X=5

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

DU pair (Definition-Use pair): Một cặp định nghĩa – sử dụng (DU pair) đối với biến X, ký hiệu DU=[X, S, S’] với X trong DEF(S), USE(S’),

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

DU path: Là một chuỗi các lệnh S→S’, trong đó DEF(S)=USE(S’)={X}

DC path (Definition-Clear path): Là một chuỗi DU path, và chỉ duy nhất S có DES(S)={X}

Edge: Cạnh Node: Nút

Chiến lược xây dựng TC trong DTF

Các bước thực hiện DTF:

- Đánh số dòng

- Lập danh sách các biến

- Lập danh mục các định nghĩa, các trường hợp sử dụng với mỗi biến

- Xác định DU path với các biến

- Xây dựng test case, nguyên tắc: bao phủ tất cả các DU path

Ví dụ:

1 Public int gcd (int // DEF(1)={x,y}

• Bảng 1.2 Danh mục các trường hợp sử dụng biến (DTF)

Bảng 1.3 DU path với các biến (DTF)

Bảng 1.4 Ca kiểm thử (DTF)

• B.3 Kiểm thử 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ó 4 loại vòng lặp: vòng lặp đơn, vòng lặp lồng nhau, vòng lặp nối tiếp, vòng lặp không cấu trúc

Các bước cần kiểm tra cho vòng lặp đơ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 tra 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, 1 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

- 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 tra 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 các vòng lặp dạng đơn, nếu không thì kiểm tra như trường hợp các vòng lặp lồng nhau

Đối với vòng lặp không cấu trúc độ phức tạp là rất lớn, vì thế nên

thiết kế lại

IV. Một số thuật ngữ về kiểm thử luồng điều khiển

- Đường thi hành (Execution path) : là 1 kịch bản thi hành đơn vị

phần mềm tương ứng, cụ thể nó là danh sách có thứ tự các lệnh được thi hành ứng với 1 lần chạy cụ thể của đơn vị phần mềm, bắt đầu từ điểm nhập của đơn vị phần mềm đến điểm kết thúc của đơn vị phần mềm.

- Mỗi TPPM có từ 1 đến n (có thể rất lớn) đường thi hành khác nhau Mục tiêu của phương pháp kiểm thử luồng điều khiển là đảm bảo mọi đường thi hành của đơn vị phần mềm cần kiểm thử đều chạy đúng Rất tiếc trong thực tế, công sức và thời gian để đạt mục tiêu trên đây là rất lớn, ngay cả trên những đơn vị phần mềm nhỏ

- Thí dụ đoạn code sau :

for (i=1; i<=1000; i++)

có 2^32 = 4 tỉ đường thi hành khác nhau

- Mà cho dù có kiểm thử hết được toàn bộ các đường thi hành thì vẫn không thể phát hiện những đường thi hành cần có nhưng không (chưa) được hiện thực :

if (a>0) doIsGreater();

if (a==0) dolsEqual();

// thiếu việc xử lý trường hợp a < 0 - if (a<0) dolsLess();

- Một đường thi hành đã kiểm tra là đúng nhưng vẫn có thể bị lỗi khi dùng thật (trong 1 vài trường hợp đặc biệt) :

int phanso (int a, int b) {

tối đa Nhưng làm sao xác định được số test case tối thiểu nào có thể đem lại kết quả có độ tin cậy tối đa?

- Phủ kiểm thử (Coverage) : là tỉ lệ các thành phần thực sự được kiểm thử

so với tổng thể sau khi đã kiểm thử các test case được chọn Phủ càng lớn thì độ tin cậy càng cao

- Thành phần liên quan có thể là lệnh thực thi, điểm quyết định, điều kiện con hay là sự kết hợp của chúng

- Phủ cấp 0 : kiểm thử những gì có thể kiểm thử được, phần còn lại để người dùng phát hiện và báo lại sau Đây là mức độ kiểm thử không thực sự có trách nhiệm

- Phủ cấp 1 : kiểm thử sao cho mỗi lệnh được thực thi ít nhất 1 lần

Phân tích hàm foo sau đây :

1 float foo(int a, int b, int c, int d) {

nhưng không phát hiện lỗi chia 0 ở hàng lệnh 8

- Phủ cấp 2 : kiểm thử sao cho mỗi điểm quyết định luận lý đều được thực hiện ít nhất 1 lần cho trường hợp TRUE lẫn FALSE Ta gọi mức kiểm thử này là phủ các nhánh (Branch coverage) Phủ các nhánh đảm bảo phủ các lệnh

3 (a == 0) Test Case 1

foo(0, 0, 0, 0)

Test Case 2 foo(1, 1, 1, 1)

6 ((a==b) OR ((c == d) AND

bug(a) ))

Test Case 2 foo(1, 1, 1, 1)

Test Case 3 foo(1, 2, 1, 2)

- Phủ cấp 3: kiểm thử sao cho mỗi điều kiện luận lý con (subcondition) của từng điểm quyết định đều được thực hiện ít nhất 1 lần cho trường hợp TRUE lẫn FALSE Ta gọi mức kiểm thử này là phủ các điều kiện con (subcondition coverage) Phủ các điều kiện con chưa chắc đảm bảo phủ các nhánh & ngược lại

- Phủ cấp 4: kiểm thử sao cho mỗi điều kiện luận lý con (subcondition) của từng điểm quyết định đều được thực hiện ít nhất 1 lần cho trường hợp TRUE lẫn FALSE & điểm quyết định cũng được kiểm thử cho cả 2 nhánh TRUE lẫn FALSE Ta gọi mức kiểm thử này

là phủ các nhánh & các điều kiện con ( branch & subcondition coverage) Đây là mức độ phủ kiểm thử tốt nhất trong thực tế

VI. Đồ thị dòng điều khiển

- Là một trong nhiều phương pháp miêu tả thuật giải Đây là phương pháp trực quan cho chúng ta thấy dễ dàng các thành phần của thuật giải

và mối quan hệ trong việc thực hiện các thành phần này

- Gồm 2 loại thành phần : các nút và các cung nối kết giữa chúng

Predicate True False

a ==0

TC 1 : foo(0, 0, 0, 0)

return 0

Các loại nút trong đồ thị dòng điều khiển :

điểm xuất phát khối xử lý điểm quyết định điểm nối điểm kết thúc

Miêu tả các cấu trúc điều khiển phổ dụng :

Tuần tự If Switch

while c do

do while cThí dụ :

s1

1 float foo(int a, int b, int c, int d) {

2 float e;

Nếu đồ thị dòng điều khiển chỉ chứa các nút quyết định nhị phân thì ta gọi nó là đồ thị dòng điều khiển nhị phân

Ta luôn có thể chi tiết hóa 1 đồ thị dòng điều khiển bất kỳ thành đồ thị dòng điều khiển nhị phân

1 int ProcessOp (int opcode) {

V(G) = E - N + 2, trong đó E là số cung, N là số nút của đồ thị.

V(G) = P + 1, nếu là đồ thị dòng điều khiển nhị phân (chỉ chứa các nút quyết định luận lý - chỉ có 2 cung xuất True/False) và P số nút quyết định

Độ phức tạp Cyclomatic C chính là số đường thi hành tuyến tính độc lập của TPPM cần kiểm thử

VII. Quy trình kiểm thử hộp trắng

1 Từ TPPM cần kiểm thử, xây dựng đồ thị dòng điều khiển tương ứng, rồi chuyển thành đồ thị dòng điều khiển nhị phân, rồi chuyển thành đồ thị dòng điều khiển cơ bản

5 Thực hiện kiểm thử trên từng test case

6 So sánh kết quả có được với kết quả được kỳ vọng

7 Lập báo cáo kết quả để phản hồi cho những người có liên quan

VIII. Kiểm thử hộp trắng áp dụng trên công cụ Nunit

1. Cài đặt công cụ

Để download và sử dụng công cụ, truy cập website:

http://www.nunit.org/index.php?p=download

Hình 1: Website download công cụ miễn phíPhiên bản hiện tại (23/02/2013): Nunit 2.6.2

Chọn định dạng file tương ứng để tải

Bước 1: Sau khi download công cụ về ta được file thực thi có tên:

NUnit-2.6.2.msi Chạy file này, xuất hiện màn hình, chọn “Next” (1) để tiếp

tục

Hình 2: Tiến trình cài đặt chương trình

Bước 2: Chọn vào checkbox “I accept the terms in the License Agreement” (2)

để chấp nhận các điều khoản khi sử dụng và tiếp tục chọn “Next” (3).

Hình 3: Tiến trình cài đặt chương trình (tiếp theo)

Bước 3: Tại đây bạn có thể chọn một trong ba kiểu cài đặt.

- Typical: Cài đặt những ứng dụng phổ biến.

- Custom: Người dùng tùy chọn các ứng dụng muốn cài đặt.

- Complete: Cài đặt tất cả các ứng dụng liên quan.

Khuyến cáo chọn Typical (4)

Hình 4: Tiến trình cài đặt chương trình (tiếp theo)

Bước 4: Chọn “Install” (5) để tiến hành cài đặt.

Hình 5: Tiến trình cài đặt chương trình (tiếp theo)

Quá trình này diễn ra trong một thời gian ngắn, sau đó chọn “Finish” (6) để kết thúc quá trình cài đặt.

Hình 6: Kết thúc quá trình cài đặt NUnit

Giao diện chương trình sau khi cài đặt thành công

Hình 7: Giao diện chương trình sau khi cài đặt thành công

2. Bài toán ứng dụng

2.1.Tổng quan về chương trình

Chương trình kiểm tra tam giác được xây dựng nhằm phục vụ cho việc sử dụng công cụ NUnit để tiến hành kiểm thử Yêu cầu đặt ra cho bài toán là khi người dùng nhập vào thông số ba cạnh của tam giác thì chương trình phải xử lý và đưa ra kết quả là ba thông số đó có tạo thành một tam giác hay không và nếu là một tam giác thì phân loại tam giác đó thành tam giác gì?

2.2.Yêu cầu hệ thống

-Đã cài đặt phần mềm kiểm thử NUnit, công cụ lập trình NET Visual Studio các phiên bản cài đặt trên hệ điều hành Windown XP hoặc cao hơn.

-NET Framework 2.0 hoặc cao hơn.

2.3.Yêu cầu chức năng

Kiểm tra ba thông số của người dùng nhập vào nó có đủ điều kiện để tạo thành một tam giác hay không?

a + b > c And a + c > b And c + b > a

Nếu là tam giác thì xét đến tính chất của tam giác đó:

- Là tam giác cân nếu thỏa mãn điều kiện trong tam giác có một cặp cạnh bằng nhau Cụ thể:

KiemTraTamGiac Tạo mới Class TamGiac với nội dung bên dưới:

Tại form chính, tạo mới các label: cạnh a, cạnh b, cạnh c Các textbox: txtCanha, txtCanhb, txtCanhc, txtkq Một button “Kiểm tra” (btKt) Viết mã lệnh cho btKt với nội dung bên dưới: