Home » PHÂN BIỆT BLACK BOX TEST VÀ WHITE BOX TEST

PHÂN BIỆT BLACK BOX TEST VÀ WHITE BOX TEST

by Hoàng Tú
17 minutes read

Trong kiểm thử phần mềm, có rất nhiều kỹ thuật kiểm thử được nhắc tới. Tuy nhiên ở bài viết này, tôi chỉ xin đề cập đến 2 kỹ thuật đó là: Kỹ thuật kiểm thử hộp đen (Black box test) và Kỹ thuật kiểm thử hộp trắng (White box test).

BLACK BOX TEST

Định nghĩa

Kiểm tra hộp đen (Black box testing) là một phương pháp kiểm thử phần mềm mà việc kiểm tra các chức năng của một ứng dụng không cần quan tâm vào cấu trúc nội bộ hoặc hoạt động của nó.

black box test

Đối tượng được kiểm thử

Là thành phần phần mền (viết tắt 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…

Phương pháp thử nghiệm

Dựa vào chức năng Kiểm thử hộp đen (Black box test) có thể được áp dụng hầu như đến mọi cấp độ của kiểm thử phần mềm:

  • Kiểm thử đơn vị (Unit test).
  • Kiểm thử tích hợp (Integration test).
  • Kiểm thử hệ thống (System test).
  • Kiểm thử chấp nhận (Acceptance test).

Tuy nhiên, Black box test được sử dụng thích hợp nhất trong kiểm thử hệ thống (System test) và Kiểm thử chấp nhận (Acceptance test).

Đặc điểm

  • Là chiến lược kiểm thử TPPM dựa vào thông tin duy nhất là các đặc tả về yêu cầu chức năng của TPPM tương ứng.
  • Người kiểm thử không cần thiết phải có kiến thức về việc mã hoá, cấu trúc bên trong của TPPM, cũng như không yêu cầu phải biết lâp trình phần mềm.
  • Việc kiểm thử được tiến hành dựa vào việc kiểm thử TPPM làm được gì, có phù hợp với yêu cầu của người dùng hay không. Các tester nhập số liệu vào phần mềm và chỉ cần xem kết quả của phần mềm và các mục tiêu kiểm tra.
  • Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test; khi test, đơn giản chỉ cần thực hiện theo các bước mô tả trong test case thao tác và nhập data vào, sau đó xem kết quả trả về hoặc hành vi của phần mềm, rồi so sánh với kết quả mong đọi được viết trong test case.

Tạo test case và thực hiện test case

  • Khi viết test case: Dựa vào yêu cầu và giao diện bên ngoài của chương trình (Không can thiệp vào bên trong code của chương trình).
  • Khi thực hiện test: Thực hiện trên giao diện của chương trình (yêu cầu chương trình phải chạy được mới test được, không can thiệp vào code).

WHITE BOX TEST

Định nghĩa

Kiểm thử hộp trắng (White box test) là phương pháp thử nghiệm phần mềm, trong đó các thiết kế, cấu trúc giải thuật bên trong, và việc thực hiện các công việc đều được biết đến.
white box test

Đối tượng kiểm thử

Là 1 thành phần của phần mềm (1 chức năng, 1 module chức năng, 1 phân hệ chức năng….).

Phương pháp thử nghiệm

Dựa vào thuật giải 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.

  • Với những TPPM quá lớn sẽ tốn rất nhiều thời gian và công sức để kiểm thử nếu như dùng kiểm thử tích hợp (Integration test) hay kiểm thử chức năng (Functional test).
  • Kỹ thuật white box test thích hợp dùng để kiểm thử đơn vị (Unit test).

Đặc điểm

  • Là chiến lược kiểm thử TPPM dựa vào giải thuật, cấu trúc bên trong chức năng của TPPM tương ứng.
  • Người kiểm thử phải có kiến thức nhất định về việc mã hoá, cấu trúc bên trong của chức năng, biết lâp trình phần mềm.
  • Việc kiểm thử được tiến hành dựa vào việc kiểm xem giải thuật, mã lệnh đã làm có đúng không.
  • Mức test này thường yêu cầu các tester phải viết test case đầy đủ các nhánh trong code;  khi test, sẽ set điều kiện và data để chạy vào đủ tất cả các nhánh trong giải thuật, đảm bảo thực hiện đầy đủ.

Tạo testcase và thực hiện test

  • Khi viết test case: Dựa vào yêu cầu và nội dung Source Code (can thiệp vào bên trong Code của chương trình).
  • Khi thực hiện test: Thực thi test trong code (không cần thực thi chương trình, vì thực hiện test white box sẽ sử dụng framework nào đó hỗ trợ (Ví dụ như test kiểu debug).
  • Trong kiểm tra này, đòi hỏi người tester phải có kiến thức và kỹ năng nhất định về ngôn ngữ lập trình được dùng, hiểu thuật giải trong thành phần phần mềm, để có thể hiểu được chi tiết về đoạn code cần kiểm thử.

GRAY BOX TEST

Ngoài 2 kỹ thuật đã được nhắc đến: Black box test và White box test. Có 1 kỹ thuật Gray box test (Kiểm thử hộp xám), đây là sự kết hợp giữa Black box test và White box test.

Định nghĩa

Gray Box Testing là một phương pháp kiểm thử phần mềm được kết hợp giữa Phương pháp Kiểm thử Black Box (hộp đen) và White Box (hộp trắng). Trong Kiểm thử Hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần.
gray box test

Phương pháp thử nghiệm

Dựa vào giải thuật và chức năng. Gray box test có thể được sử dụng ở nhiều mức kiểm thử khác nhau. Tuy nhiên, chủ yếu được ứng dụng trong Kiểm thử tích hợp (Intergration test).

Tạo testcase và thực hiện test

  • Khi viết test case: Dựa vào yêu cầu và nội dung Source Code (can thiệp vào bên trong Code của chương trình).
  • Khi thực hiện test: Thực hiện trên giao diện của chương trình (yêu cầu chương trình phải chạy được mới test được, không can thiệp vào code).

ƯU ĐIỂM, NHƯỢC ĐIỂM CỦA BLACK BOX TEST VÀ WHITE BOX TEST

Nội dung Black box test White box test
1. Ưu điểm – Thích hợp trong việc kiểm tra từng phân đoạn lớn các mã lệnh, chức năng lớn
– Người thử nghiệm không cần hiểu biết về mã lệnh được viết trong chương trình
– Tách biệt giữa quan điểm của người sử dụng và người phát triển phần mềm
– Thích hợp trong việc tìm kiếm lỗi và các vấn đề trong mã lệnh
– Biết được yêu cầu bên trong của phần mềm, kiểm tra sẽ sát hơn
– Cho phép tìm kiếm các lỗi ẩn bên trong
– Các lập trình viên có thể tự kiểm tra
– Giúp tối ưu việc mã hoá
– Do yêu cầu kiến thức cấu trúc bên trong của phần mềm, nên việc kiểm soát lỗi tối đa nhất
2. Nhược điểm – Độ bao phủ hạn chế vì chỉ có một phần nhỏ trong số các kịch bản thử nghiệm được thực hiện
– Kiểm tra không hiệu quả do người thử nghiệm không hiểu biết gì về cấu trúc bên trong phần mềm.
– Tester có hạn chế về hiểu biết về ứng dụng
– Không thể tìm thấy tính năng chưa thực hiện hoặc bỏ sót
– Đòi hỏi hiểu sâu về cấu trúc bên trong của phần mềm được thử nghiệm
– Yêu cầu truy xuất mã lệnh bên trong chương trình

SỰ KHÁC NHAU GIỮA BLACK BOX TEST VÀ WHITE BOX TEST

Tiêu chuẩn Black box test White box test
1. Định nghĩa – Kiểm tra hộp đen là phương pháp thử nghiệm phần mềm được sử dụng để kiểm tra các phần mềm mà không quan tâm đến cấu trúc bên trong của chương trình. – Kiểm tra hộp trắng là phương pháp kiểm thử phần mềm, sử dụng để kiểm tra phần mềm mà yê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 độ test sử dụng – Thử nghiệm áp dụng ở cấp độ cao như: kiểm tra hệ thống (System test), kiểm tra chấp nhận (Acceptance test) – Thử nghiệm được áp dụng ở mức độ thấp hơn như thử nghiệm đơn vị (Unit Test), thử nghiệm hội nhập (Integration test)
4. Biết lập trình – Không yêu cầu hiểu biết về Lập trình – Yêu cầu hiểu biết nhất định về lập trình.
5. Biết việc thực hiện chương trình – Không yêu cầu hiểu về cấu trúc bên trong chức năng, và 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ơ sở tạo Test Cases – Kiểm tra hộp đen được bắt đầu dựa trên tài liệu yê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

SƠ LƯỢC VỀ CÁC KỸ THUẬT KIỂM TRA HỘP ĐEN

Quy trình kiểm thử hộp đen

Với đặc điểm của Kiểm thử hộp đen là chỉ dựa vào chức năng của phần mềm, do đó quy trình kiểm thử qua các bước chính như sau:

  • Phân tích đặc tả về các yêu cầu chức năng mà TPPM cần thực hiện.
  • Dùng 1 kỹ thuật đinh nghĩa các test case xác định để định nghĩa các test case, gồm 3 thông tin sau: + Giá trị dữ liệu để TPPM xử lý (hoặc hợp lệ, hoặc không hợp lệ) + Trạng thái của TPPM cần có để thực hiện test case + Giá trị dữ liệu xuất mà TPPM phải tạo được.
  • Kiểm thử các test case đã định nghĩa.
  • So sánh kết quả thu được với kết quả kỳ vọng trong từ test case, từ đó lập báo cáo về kết quả kiểm thử.

Các kỹ thuật phổ biến trong kiểm thử hộp đen

  • Kỹ thuật phân lớp tương đương (Equivalence Class Partitioning).
  • Kỹ thuật phân tích các giá trị biên (Boundary value analysis).
  • Kỹ thuật dùng các bảng quyết định (Decision Tables).
  • Kỹ thuật kiểm thử các bộ n thần kỳ (Pairwise).
  • Kỹ thuật dùng bảng chuyển trạng thái (State Transition).
  • Kỹ thật phân tích vùng miền (domain analysis).
  • Kỹ thuật dựa trên đặc tả Use Case (Use case).
  • Kỹ thuật dùng lược đồ quan hệ nhân quả (Cause-Effect Diagram).

Kỹ thuật phân lớp tương đương

Ý tưởng của kỹ thuật này là cố gắng phân các test case ra thành nhiều nhóm khác nhau : các test case trong mỗi nhóm xác định TPPM thực hiện cùng 1 hành vi. Mỗi nhóm test case thỏa mãn tiêu chuẩn trên được gọi là 1 lớp tương đương, ta chỉ cần xác định 1 test case đại diện cho nhóm và dùng test case này để kiểm thử TPPM. Như vậy ta đã giảm rất nhiều test case cần định nghĩa và kiểm thử, nhưng chất lượng kiểm thử không bị giảm sút bao nhiêu so với vét cạn. Điều này là dựa vào kỳ vọng:

  • Nếu 1 test case trong lớp tương đương nào đó gây lỗi TPPM thì các test case trong lớp này cũng sẽ gây lỗi như vậy.
  • Nếu 1 test case trong lớp tương ₫ương nào đó không gây lỗi TPPM thì các test case trong lớp này cũng sẽ không gây lỗi.
  • Với các giá trị không hợp lệ: Ta nên tạo 1 lớp tương đương đại diện các test case chứa các giá trị không hợp lệ theo đặc tả để xem TPPM phản ứng như nào với những trường hợp này.

Kỹ thuật phân tích các giá trị ở biên

Khi tạo test case, ta chỉ dùng Kỹ thuật phân lớp tương đương thì hẳn là chưa đủ. Kinh nghiệm cho thấy rằng lỗi thường nằm ở biên (đầu hay cuối) của 1 khoảng liên tục nào ₫ó (lớp tương đương). Do đó với Kỹ thuật phân tích giá trị biên tập trung tạo các test case ứng với những giá trị ở biên này. Nên thông thường là có sự kết hợp cả 2 kỹ thuật: Phân lớp tương đương và Phân tích giá trị biên để viết các test case. Ý tưởng của kỹ thuật là chỉ định nghĩa các test case ứng với các giá trị ngay trên biên hay lân cận biên của từng lớp tương ₫ương. Do đó kỹ thuật này chỉ thích hợp với các lớp tương đương xác định bởi các giá trị liên tục (số nguyên, số thực), chứ nó không thích hợp với lớp tương đương được xác định bởi các giá trị liệt kê mà không có mối quan hệ lẫn nhau. Quy trình cụ thể để thực hiện kiểm thử dựa trên các giá trị ở biên:

  • Nhận dạng các lớp tương đương dựa trên đặc tả về yêu cầu chức năng của TPPM.
  • Nhận dạng 2 biên của mỗi lớp tương đương. Tạo các test case cho mỗi biên của mỗi lớp tương đương :
  • 1 test case tại giá trị biên.
  • 1 test case ngay dưới biên.
  • 1 test case ngay trên biên. Ý nghĩa ngay trên và ngay dưới biên phụ thuộc vào ₫ơn vị đo lường cụ thể : Số nguyên, số thập phân…

Kỹ thuật dùng bảng quyết định (decision table)

Bảng quyết định là 1 công cụ rất hữu ích để đặc tả các yêu cầu phần mềm hoặc để đặc tả bảng thiết kế hệ thống phần mềm. Nó miêu tả các quy tắc nghiệp vụ phức tạp mà phần mềm phải thực hiện dưới dạng dễ đọc và dễ kiểm soát :

Rule 1 Rule 2 Rule p
Conditions
Conditions-1
Conditions-m
Actions
Actions-1
Actions-n

Trong đó:

  • Condition-1 tới Condition-m miêu tả m điều kiện dữ liệu nhập khác nhau có thể có.
  • Action-1 tới Action-n miêu tả n hoạt động khác nhau mà hệ thống có thể thực hiện phụ thuộc vào tổ hợp điều kiện dữ liệu nhập nào.
  • Mỗi cột miêu tả 1 luật cụ thể : tổ hợp điều kiện nhập cụ thể và các hoạt động cụ thể cần thực hiện. Lưu ý các hoạt động cần thực hiện không phụ thuộc vào thứ tự các điều kiện nhập, nó chỉ phụ thuộc vào giá trị các điều kiện nhập. Tương tự, các hoạt động cần thực hiện không phụ thuộc vào trạng thái hiện hành của TPPM, chúng cũng không phụ thuộc vào các điều kiện nhập đã có trước đó.

Xem thêm:

via viblo source softwaretestingfundamentals, softwaretestingclass & technologyconversations

Nếu các bạn cảm thấy Website TanHongIT.Com thật sự hữu ích mình mong các bạn có thể chia sẻ những bài viết đến cho cộng đồng cùng thao khảo nhé. Cảm ơn các bạn !!!

Các bạn có bất kì thắc mắc cần được hỗ trợ hay yêu cầu các phần mềm, thủ thuật, khoá học,… thì cứ để lại comment bên dưới bài viết hoặc liên hệ qua fanpage của TanHongIT để được hỗ trợ nhé! Mình sẽ cố gắng chia sẻ cho các bạn mọi thứ cần thiết nhất!

5/5 - (1 vote)

Related Posts

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More

0
Would love your thoughts, please comment.x
()
x