Phương pháp kiểm thử hộp trắng (white box testing)

Nội dung trình bày  Các khái niệm của phương phương pháp kiểm thử hộp trắng  Các kỹ thuật được sử dụng khi xây dựng các ca kiểm thử theo phương pháp kiểm thử hộp trắng  Ưu, nhược đi

Nội dung trình bày

 Các khái niệm của phương phương

pháp kiểm thử hộp trắng

 Các kỹ thuật được sử dụng khi xây

dựng các ca kiểm thử theo phương pháp kiểm thử hộp trắng

 Ưu, nhược điểm của phương pháp

 Giải pháp

Đặt vấn đề

 Bài toán về chất lượng phần mềm luôn được đặt ra trong mọi dự án phần mềm với mong muốn là ngày càng sản suất ra được những phần mềm có chất

lượng tốt hơn với chi phí thấp hơn

 Việc đảm bảo chất lượng phần mềm mềm liên

quan đến rất nhiều yếu tố như: chuẩn và quy trình quản lý của công ty, môi trường và công cụ phát

triển, mô hình phát triển phần mềm được lựa chọn,

kĩ năng của nhân viên,…

 Xác minh và thẩm định là tên gọi chung của các

hoạt động đảm bảo chất lượng phần mềm

 Công việc mã hóa một chương trình theo đúng

thiết kế là một trong những giai đoạn quan trọng trong quá trình sản xuất phần mềm

 Đề tài: “Phương pháp kiểm thử hộp trắng” là một trong những phương pháp dùng để thiết kế các ca kiểm thử nhằm kiểm tra xem các đoạn mã chương trình có vận hành đúng như thiết kế hay không

Đặt vấn đề

Nội dung chính của tiểu luận:

 Tìm hiểu về phương pháp kiểm thử hộp trắng

đang rất phổ biến hiện nay trong ngành công nghệ phần mềm

 Trên cơ sở kiến thức kiểm thử tiếp thu được sẽ

giúp cho bản thân tạo ra những sản phẩm phần mềm có chất lượng cao hơn trong tương lai.

đúng như thiết kế hay không

 Kiểm thử hộp trắng dựa trên việc xem xét cấu trúc bên trong của chương trình theo cấu trúc điều khiển và hoạt động của chúng

Các khái niệm (tiếp)

 Các tên gọi khác: kiểm thử cấu trúc (structural testing),

kiểm thử hộp kính (glass box), kiểm thử rõ ràng (clear box testing).

 Đối tượng chính của kiểm thử hộp trắng là tập trung vào

cấu trúc bên trong chương trình và tìm ra tất cả những lỗi bên trong chương trình

 Việc kiểm tra tập trung chủ yếu vào:

 Cấu trúc chương trình: Những câu lệnh và các nhánh,

các loại đường dẫn chương trình.

 Logic bên trong chương trình và cấu trúc dữ liệu.

 Những hành động và trạng thái bên trong chương

trình

 Tất cả các vòng lặp ở biên của nó và biên vận hành

phải được thực hiện

 Mọi cấu trúc dữ liệu nội tại được dùng để đảm bảo

tính hiệu lực của nó

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

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

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

1 Đồ thị luồng

a) Cấu trúc của đồ thị luồng

- Đồ thị luồng (flow graph) là một kỹ thuật kiểm

thử hộp trắng được Tom McCabe đề xuất năm

1976

- Đồ thị luồng được xây dựng từ đồ thị luồng điều

khiển của chương trình bằng cách gộp các lệnh tuần tự liên tiếp và lệnh rẽ nhánh sau nó thành một nút, thay các lệnh rẽ nhánh (độc lập) hay điểm hợp nhất của các đường rẽ nhánh bằng một nút.

a) Cấu trúc của đồ thị luồng (tiếp)

− cấu trúc của một đồ thị luồng bao

gồm:

− Mỗi nút (hình tròn) biểu thị một vài

(có thể là 0) câu lệnh thủ tục.

− Mỗi cạnh biểu diễn dòng điều khiển

nối hai nút với nhau.

− Miền là phần mặt phẳng giới hạn bởi

các cung và nút của đồ thị.

− Những nút biểu thị sự phân nhánh

hoặc hội nhập của các cung được gọi

là nút vị từ.

a) Cấu trúc của đồ thị luồng (tiếp)

− Các cấu trúc lệnh cơ bản của chương trình tương ứng với các cấu trúc trong đồ thị luồng:

− Là số đo sự phức tạp logic của chương

trình

− Là số các đường đi độc lập cơ bản trong

tập các con đường độc lập của một chương trình.

− Là số đường độc lập nhỏ nhất phủ hết các

cạnh của đồ thị luồng

− Số đo này là giới hạn trên của số ca kiểm

thử cần phải tiến hành để đảm bảo rằng, tất cả các câu lệnh trong chương trình đều được thực hiện ít nhất một lần

b) Độ phức tạp chu trình

− Độ phức tạp chu trình của đồ thị luồng G được

kí hiệu là V(G) và có thể tính theo bốn cách sau:

Từ đồ thị luồng điều khiển ta xây dựng được đồ thị luồng tương ứng như sau:

− Độ phức tạp chu trình V(G) của đồ thị này bằng 4, là số miền phẳng của nó, hay có thể tính theo các công thức khác dưới đây:

V(G) = E – N + 2 = 10 – 8 + 2 = 4 V(G) = P – 1 = 5 – 1 = 4

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

− 4 đường độc lập cơ bản tìm được (để lập

các ca kiểm thử) từ đồ thị luồng là: đường 1: 1 – 2 – 3 – 4 – 1; đường 2: 1 – 2 – 4 – 1; đường 3: 1 – 5 – 6 – 8; đường 4: 1 – 5 – 7 –

8

Kết luận: Để thiết lập các ca kiểm thử khi

sử dụng kỹ thuật đồ thị luồng, cần tiến

hành theo 5 bước sau:

1) Từ thiết kế hoặc mã nguồn của môdun, ta lập

đồ thị luồng điều khiển

2) Xây dựng đồ thị luồng tương ứng với đồ thị

luồng điều khiển

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

+ Mỗi ô được ghi số 1 nếu có một cung nối nút dòng đến nút cột

− Dùng để tính độ phức tạp chu trình: cộng số 1

trên mỗi dòng rồi trừ đi 1, sau đó lấy tổng các

dòng cộng thêm 1 ta được kết quả

− Ma trận Ak: giá trị ghi trong mỗi ô cho số các con

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

− Để ma trận kiểm thử trở thành một công cụ mạnh,

người ta xác định thêm các trọng số sau đây cho các cung cua ma trận kiểm thử:

+ Xác xuất cung đó được tiến hành

+ Thời gian xử lý của đường đi qua cung đó + Bộ nhớ yêu cầu của đường đi qua cung đó + Nguồn lực đòi hỏi của đường đi qua cung đó

 Với những tham số này, các ma trận kiểm thử

giúp ta lựa chọn những đường đi cơ bản có trọng số quan trọng để thiết lập các ca kiểm thử

2 Ma trận kiểm thử (tiếp)

2 Ma trận kiểm thử (tiếp)

Sau đây là 2 ma trận A và A4 đồ thị kiểm thử của

đồ thị luồng xét trong phần (1):

22

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

Người ta đã đề xuất ra 2 chiến lược kiểm thử điều kiện:

 Kiểm thử rẽ nhánh (Branch testing)

 Kiểm thử miền (Domain testing)

a) Kiểm thử rẽ nhánh

− Là chiến lược tập trung vào kiểm thử từng điều

kiện rẽ nhánh có trong chương trình.

− Đảm bảo kiểm tra mỗi nhánh ít nhất một lần.

− Xác nhận tính đúng đắn của tất cả các rẽ nhánh

trong mã lệnh và khẳng định không có nhánh nào dẫn tới một hành vi bất thường của ứng dụng

a) Kiểm thử rẽ nhánh (tiếp)

− Ví dụ: kiểm thử đoạn mã sau:

1: function hello($sDate, $sTime) { 2: echo “Hello World!<br>”;

3: if ($sDate == "01-01-2010" &&

$sTime == "00:00:00") { 4: echo "Happy New Year<br>"; 5: }

6: echo “The date is: $sDate >”; 7: echo “The time is: $sTime<br>”; 8: }

b) Chiến lược kiểm thử BRO

Nhận xét: Khi một biểu thức điều kiện phức hợp

gồm n điều kiện đơn mà số n đủ lớn, thì việc tiến hành đầy đủ 2n ca kiểm thử là rất khó thực hiện

− Là một kỹ thuật làm giảm số ca kiểm thử cần

tiến hành trong kiểm thử điều kiện

− BRO dùng đến “ràng buộc điều kiện cho điều

kiện kiểm thử”

− Tư tưởng kiểm thử của chiến lược BRO là cho

phép thử nhạy cảm sai của biểu thức bool.

1) Xét điều kiện C là một biến bool, khi đó ràng buộc đầu

ra của C là một cặp giá trị t hoặc f.

bool Chiến lược kiểm thử BRO đòi hỏi rằng, tập ba ràng buộc đầu ra {(t, t), (t, f), (f, t)} đều được phủ bởi các thi hành của C, còn (f, f) là thừa

Nếu C không đúng đắn do “ít nhất một phép toán

bool sai”, thì trong 3 cặp trên có ít nhất một cặp

làm C thất bại.

b) Chiến lược kiểm thử BRO (tiếp)

2) Xét điều kiện đơn C = (A = B) với A và B là

biểu thức số học Khi đó ràng buộc của C là một trong ba quan hệ: <, >, =

2) Xét điều kiện C là hội của hai biểu thức bool C

= (A and (B = E))

Khi đó các ràng buộc của C là các cặp (t, t), (t, f)

và (f, t) ; với (B = E), ta có giá trị t tương ứng

với “=”, và giá trị f tương ứng với “<” hoặc “>” Tương tự như trường hợp ở trên đã xét đối với điều kiện hai biến bool có ràng buộc đầu ra là

{(t, t), (t, f), (f, t)}, khi đó ta có tập các ràng

buộc của C trong trường hợp này phải gồm 4

phần tử: {(t, =), (t, <), (t, >), (f, =)}

có hai thuận lợi:

điều kiện là đơn giản

trong một chương trình cho ta các

hướng dẫn để tạo ra các ca kiểm thử

đầy đủ cho chương trình.

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

− Là kiểm thử tuyển chọn các đoạn đường của

chương trình tương ứng với việc định vị các biến được xác định (định nghĩa) và sử dụng trong

chương trình

− Các khái niệm liên quan:

 Vị trí xác định biến: là nơi mà nó được gán một giá trị cụ thể

 Vị trí sử dụng biến là vị trí mà giá trị của biến được sử dụng trong chương trình

 Vị trí sử dụng biến để tính toán

 Biến được sử dụng như một vị từ để xác định đường đi thực thi tiếp tục chương trình

4 Kiểm thử luồng dữ liệu (tiếp)

 Cặp xác định và sử dụng biến (DEF – USE) là một cặp vị trí mà tại đó biến được xác định và được sử dụng, mà có thể liên kết với nhau bằng một đường đi thỏa mãn điều kiện là biến được xét không được định nghĩa lại.

− Mục đích của phương pháp này là nhằm kiểm tra tất cả các cặp DEF – USE xuất hiện trong chương trình.

DEF(S) = {X | câu lệnh S chứa định nghĩa của X

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

4 Kiểm thử luồng dữ liệu (tiếp)

− Một dây chuyền sử dụng X được kí hiệu là DU = [X, S, S’], với X trong DEF(S) và trong USE(S), đồng thời định nghĩa X trong S vẫn còn đúng

trong S’

− Yêu cầu của phương pháp kiểm thử luồng dữ liệu

là tất cả các dây chuyền DU đều được kiểm thử ít nhất một lần

− Phương pháp này thực hiện nhằm phát hiện ra các lỗi tiềm năng như: dk, ~u, ~k, ku, dd, kk, d~, … trong đó: k (killed) là biến đã bi hủy, ~u: data

được sử dụng mà không định nghĩa, ~k: data bị hủy trước khi định nghĩa, d~: được định nghĩa sau cùng

5 Kiểm thử vòng lặp (tiếp)

− Vòng lặp lồng: ta kiểm thử từ trong ra, theo

phương pháp sau:

− Bắt đầu từ vòng lặp bên trong nhất và đặt tất cả

các vòng lặp khác vào giá trị tối thiểu.

− Tiến hành kiểm thử vòng lặp đơn cho vòng lặp

bên trong nhất Bổ sung các ca kiểm thử khác về việc vượt cận hay giá trị bị loại ra.

− Tiến dần ra ngoài, thực hiện phép kiểm thử cho

các vòng lặp tiếp, nhưng giữ tất cả các vòng lặp bên ngoài hơn ở giá trị tối thiểu và các vòng lặp bên trong ở giá trị “điển hình”.

− Tiếp tục cho tới khi mọi vòng lặp đã được kiểm

thử hết.

Ưu, nhược điểm của phương

pháp kiểm thử hộp trắng

− Ưu điểm:

− Phương pháp kiểm thử hộp trắng cho

ta số lượng ca kiểm thử là hữu hạn.

− Phương pháp kiểm thử hộp trắng có khả năng tìm và phát hiện ra lỗi là rất cao.

− Nhược điểm:

− Sử dụng phương pháp này rất dễ rơi vào “bẫy” của người mã hóa

− Kiểm thử hộp đen thường được thực hiện

sau khi kiểm thử hộp trắng hoàn thành

Một số tài liệu tham khảo

1. Nguyễn Văn Vỵ - Nguyễn Việt Hà, Giáo trình kỹ nghệ

phần mềm, NXB Giáo dục Việt nam, 2009

Xin chân thành cảm ơn