Kiểm Thử Hộp Trắng Là Gì ? (What Is White-box Testing ?)

Rate this post

Bất kỳ 1 sản phẩm phần mềm nào cũng chắc chắn có lỗi, vì sản phẩm phầm mềm do con người xây dựng nên, dù có cẩn trọng, có giỏi đến mức nào thì cũng không thể bảo đảm sản phẩm mình tạo ra là không có lỗi. Do đó, sẽ cần 1 người, nhóm hoặc tổ chức độc lập kiểm thử xem sản phẩm đó có vấn đề hay có lỗi gì hay không.

Để kiểm thử phần mềm thì chúng ta cần phải có kế hoạch, chiến lược kiểm thử cũng như các kỹ thuật các phương pháp kỹ thuật hiệu quả cho mỗi mức độ kiểm thử. Kiểm thử phần mềm gồm hai phần việc đòi hỏi những kỹ năng khác nhau đó là kiểm thử hộp trắng (white-box testing) và kiểm thử hộp đen (black-box testing).

Trong đề tài này, tôi sẽ đi sâu vào tìm hiểu kiểm thử hộp trắng. Để hiểu rõ hơn về kỹ thuật kiểm thử hộp trắng (White-box testing) thì chúng ta lần lượt tìm hiểu các nội dung dưới đây:

Nội Dung

I. Kiểm Thử Hộp Trắng Là Gì

Kiểm thử Hộp Trắng (còn gọi là Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing hoặc Structural Testing) là 1 phương pháp kiểm thử phần mềm trong đó tester biết về cấu trúc nội bộ / thiết kế. Người kiểm tra chọn đầu vào để thực hiện các đường dẫn thông qua mã và xác định đầu ra thích hợp. Kiến thức lập trình và kiến thức thực hiện là rất cần thiết trong kiểm thử hộp trắng.

Kiểm thử hộp trắng bao gồm phân tích dòng dữ liệu, điều khiển dòng, dòng thông tin, mã thực hành, ngoại lệ và những lỗi trình bày trong hệ thống để đánh giá những hành động của phần mềm không được định hướng trước.

II. Các Phương Pháp Kiểm Thử Hộp Trắng

+ Kiểm thử đường cơ bản – Đồ thị dòng

Là một kỹ thuật dùng trong kiểm thử hộp trắng được Tom McCabe đưa ra đầu tiên. Đồ thị dòng gần giống đồ thị luồng điều khiển của chương trình.
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.
Kỹ thuật đường cơ bản – đồ thị dòng có thể giúp những người thiết kế ca kiểm thử nhận được một độ phức tạp của 1 logic thủ tục.
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.
Các loại nút trong đồ thị dòng điều khiển :

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

Các kiểu cấu trúc thành phần đồ thị dòng :

Các kiểu cấu trúc thành phần đồ thị dòng

Thí dụ :

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.

Độ phức tạp Cyclomatic C Độ phức tạp Cyclomatic C = V(G) của ₫ồ thị dòng ₫iều khiển ₫ược tính bởi 1 trong các công thức sau : 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ử.

+ Kiểm thử dựa trên 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ụctiê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++) for (j=1; j<=1000; j++) for (k=1; k<=1000; k++) doSomethingWith(i,j,k); chỉ có 1 đường thi hành, nhưng rất dài : dài 100010001000 = 1 tỉ lệnh gọi hàm doSomething(i,j,k) khác nhau.
Còn đoạn code gồm 32 lệnh if else độc lập sau : if (c1) s11 else s12; if (c2) s21 else s22; if (c3) s31 else s32; … if (c32) s321 else s322; 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) { return a/b; } khi kiểm tra, ta chọn b <> 0 thì chạy đúng, nhưng khi dùng thật trong trường hợp b = 0 thì hàm phân số bị lỗi.

III. Những Kỹ Thuật Kiểm Thử Hộp Trắng

Khi thực hiện kiểm thử bằng whitebox testing thì ta phải có một bộ test cho chương trình đó. Tuy nhiên làm sao để biết chắc chắn được là bộ test của chúng ta đã đầy đủ cho tất cả các trường hợp hay chưa? Lúc này ta sẽ áp dụng các kiến thức của coverage tesing để đo đạc kết quả của chương trình khi thực hiện bộ kiểm thử.

Coverage testing có thể hiểu nôm na là tỉ lệ (tính theo %) test case đã được thực hiện trên tổng số test case cần thiết cho ứng dụng. Nếu tỉ lệ này càng cao thì ứng dụng càng được test kỹ. Mặc dù việc đảm bảo ứng dụng có test coverage là 100% trong một số trường hợp là bất khả thi, nhưng ta vẫn sẽ luôn cố gắng để đạt được kết quả gần với con số đó nhất.

Có 3 kĩ thuật

Bao phủ câu lệnh(Statement Coverage): Kiểm thử sao cho mỗi câu lệnh được thực thi ít nhất 1 lần. Ví dụ đọan mã:

Public int foo(int x, int y) Int z = 0; If (x > 0 && y > 0) { z = x; } Return z; }

Nếu ta gọi foo(1,1) thì dòng z = x sẽ được thực hiện, còn nếu gọi foo(0,1) thì dòng z = x sẽ không được thực hiện, lúc đó test case của ta sẽ không thỏa điều kiện bao phủ câu lệnh.

Bao phủ điều kiện(Branch Coverage, Decision coverage): Kiểm thử đòi hỏi phải đủ trường hợp thử nghiệm như vậy mà mỗi điều kiện trong một quyết định có trên tất cả các kết quả có thể ít nhất một lần. Đó là các nhánh (quyết định) lấy cả 2 trường hợp đúng và sai. Nó giúp trong việc chứng thực tất cả các ngành có mã đảm bảo rằng đó không có chi nhánh dẫn đến hành vi bất thường của ứng dụng. Ví dụ đoạn mã:

Ta có thể sinh các test case bao phủ các điều kiện của nhánh:

Bao phủ nhánh(Path Coverage): Trong các trường hợp kiểm thử được thực hiện trong một cách mà mọi con đường được thực hiện ít nhất một lần. Tất cả các con đường kiểm soát có thể được thực hiện, bao gồm tất cả những con đường vòng lấy bằng không, một lần, và nhiều (lý tưởng là tối đa) các trường hợp thử nghiệm được chuẩn bị dựa trên các biện pháp phức tạp logic của một thiết kế thủ tục. Để hoàn thiện bao phủ nhánh, chúng ta phải xét thêm 2 trường hợp bug(a) khi đúng và khi sai.

IV. Khác Nhau Giữa Kiểm Thử Hộp Trắng Và Hộp Đen

1. Định nghĩa	– Kiểm tra hộp đen là cách thử nghiệm phần mềm được ѕử dụng để đánh giá những phần mềm mà không quan tâm tới cấu trúc bên trong của chương trình.	– Kiểm tra hộp trắng là cách kiểm thử phần mềm, ѕử dụng để kiểm tra phần mềm mà уêu cầu phải biết cấu trúc bên trong của chương trình.
2. Trách nhiệm	– Thử nghiệm được thực hiện bên ngoài, không liên quan đến nhà phát triển phần mềm.	– Thông thường, các thử nghiệm được thực hiện bởi nhà phát triển phần mềm.
3. Cấp độ teѕt ѕử dụng	– Thử nghiệm áp dụng ở cấp độ cao như: kiểm tra hệ thống (Sуѕtem teѕt), kiểm tra chấp nhận (Acceptance teѕt)	– Thử nghiệm được áp dụng ở mức độ thấp hơn như thử nghiệm đơn ᴠị (Unit Teѕt), thử nghiệm hội nhập (Integration teѕt)
4. Biết lập trình	– Không уêu cầu hiểu biết ᴠề Lập trình	– Yêu cầu hiểu biết nhất định ᴠề lập trình.
5. Biết ᴠiệc thực hiện chương trình	– Không уêu cầu hiểu ᴠề cấu trúc bên trong chức năng, ᴠà không cẩn hiểu làm thế nào để có được chức năng đó	– Yêu cầu hiểu cấu trúc bên trong chức năng được thực hiện như nào.
6. Cơ ѕở tạo Teѕt Caѕeѕ	– Kiểm tra hộp đen được bắt đầu dựa trên tài liệu уêu cầu kỹ thuật	– Kiểm tra hộp trắng được bắt đầu dựa trên các tài liệu thiết kế chi tiết