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 ở nội dung 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)

Bạn Đang Xem: PHÂN BIỆT BLACK BOX TEST VÀ WHITE BOX TEST, SƠ LƯỢC MỘT SỐ KỸ THUẬT TRONG BLACK BOX TEST

1.1. BACK BOX TEST

1.1.1. Khái niệm 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ó.

1.1.2. Đối tượng người tiêu dùng được kiểm thử Là thành phần phần mền (TPPM) có thể là 1 trong hàm chức năng, 1 modul chức năng, 1 phân hệ chức năng…

1.1.3. 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 ứng dụng hầu như đến mọi Lever của kiểm thử phần mềm:

• Kiểm thử đơn vị (Unit test)
• Kiểm thử tích hợp (Intergration test)
• Kiểm thử mạng lưới hệ thống (System test)
• Kiểm thử gật đầu đồng ý (Acceptance test).

Tuy nhiên, Black box test được sử dụng thích thống nhất trong kiểm thử mạng lưới hệ thống (System test) và Kiểm thử gật đầu đồng ý (Acceptance test)

1.1.4. Đặ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ấp thiết phải có tri 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 ghi nhận 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ù phù hợp với yêu cầu của người dùng hay là không. Các tester nhập số liệu vào phần mềm và chỉ việc 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 lúc test; khi test, đơn giản chỉ việc thực hiện theo những 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 testcase

1.1.5. 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 phía ngoài của lớp học (Không can thiệp vào bên trong code của lớp học)
• Khi thực hiện test: Thực hiện trên giao diện của lớp học (yêu cầu lớp học phải chạy được mới test được, không can thiệp vào code)

1.2. WHITE BOX TEST

Xem Thêm : Truyền hình là gì? Phân loại, đặc trưng, các yếu tố cơ bản

1.2.1. Khái niệm Kiểm thử hộp trắng (While 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 nghe biết

1.2.2. Đối tượng người tiêu dùng kiểm thử Là một trong 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….)

1.2.3. 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 tài 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á to sẽ tốn rất nhiều thời kì và sức lực lao động để 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 làm kiểm thử đơn vị (Unit test)

1.2.4. Đặ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ó tri 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 kèm theo và data để chạy vào đủ tất cả những nhánh trong giải thuật, đảm bảo thực hiện đầy đủ.

1.2.5. 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 lớp học)
• Khi thực hiện test: Thực thi test trong code (không cần thực thi lớp học, vì thực hiện test white box sẽ sử dụng framework nào đó tương trợ (Ví dụ như test kiểu debug)
• Trong kiểm tra này, yên cầu người tester phải có tri thức và kỹ năng nhất định về tiếng nói lập trình được sử dụng, hiểu thuật giải trong thành phần phần mềm, để sở hữu thể hiểu được rõ ràng và cụ thể về đoạn code cần kiểm thử .

1.3. GRAY BOX TEST

Ngoài 2 kỹ thuật đã được nhắc đến: Black box test và white box test, thì có một kỹ thuật, Gray box test là sự việc phối hợp giữa black box test và white box test. 1.3.1. Khái niệm Gray Box Testing là một phương pháp kiểm thử phần mềm được phối 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

1.3.2. Phương pháp thử nghiệm: Dựa vào giải thuật và chức năng

Xem Thêm : Xét nghiệm định lượng HBV-DNA

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)

1.3.3. 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 lớp học)
• Khi thực hiện test: Thực hiện trên giao diện của lớp học (yêu cầu lớp học phải chạy được mới test được, không can thiệp vào code)

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 lớp học – Tách biệt giữa ý kiến 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 – Được chấp nhận 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 tri 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 – Độ lan tỏa 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 – Yên cầu 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 lớp học Tiêu chuẩn Black box test White box test 1. Khái niệm – 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 lớp học. – 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 ghi nhận cấu trúc bên trong của lớp học. 2. Trách nhiệm – Thử nghiệm được thực hiện phía 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. Lever test sử dụng – Thử nghiệm ứng dụng ở Lever cao như: kiểm tra mạng lưới hệ thống (System test), kiểm tra gật đầu đồng ý (Acceptance test) – Thử nghiệm được ứng dụng ở tại 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 lớp học – 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 để dành đượ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 khai mạc dựa trên tài liệu yêu cầu kỹ thuật – Kiểm tra hộp trắng được khai mạc dựa trên các tài liệu thiết kế rõ ràng và cụ thể

4.1. 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 testcase xác định để khái niệm các testcase, gồm 3 thông tin sau: + Giá trị tài liệu để TPPM xử lý (hoặc hợp thức, hoặc không hợp thức) + Trạng thái của TPPM cần có để thực hiện testcase + Giá trị tài liệu xuất mà TPPM phải tạo được
• Kiểm thử các testcase đã khái niệm
• So sánh kết quả thu được với kết quả kỳ vọng trong từ testcase, từ đó lập văn bản báo cáo về kết quả kiểm thử

4.2. Các kỹ thuật phổ quát 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) Trong nội dung bài viết này tôi chỉ nêu sơ lược về một số kỹ thuật kiểm thử trên. Rõ ràng và cụ thể sẽ tiến hành cụ thể trong các nội dung bài viết sau

4.2.1. Kỹ thuật phân lớp tương ₫ương

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

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

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

Khi tạo testcase, 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 một khoảng tầm liên tục nào ₫ó (lớp tương ₫ương). Do ₫ó với Kỹ thuật phân tích giá trị chỉnh sửa trung tạo các testcase ứng với những giá trị ở biên này. Nên thường là có sự phối hợp cả hai kỹ thuật: Phân lớp tương đương và Phân tích giá trị biên để viết các testcase. Ý tưởng của kỹ thuật là chỉ ₫ịnh nghĩa các testcase ứng với những giá trị ngay trên biên hay phụ cận biên của từng lớp tương ₫ương. Do ₫ó kỹ thuật này chỉ thích phù 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 phù 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ó 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 testcase cho từng biên của mỗi lớp tương ₫ương :
• 1 testcase tại giá trị biên.
• 1 testcase ngay dưới biên.
• 1 testcase 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…

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

Bảng quyết ₫ịnh là 1 trong phương tiện 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ế mạng lưới hệ thống phần mềm. Nó miêu tả các qui 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 số đó:

• Condition-1 tới Condition-m miêu tả m ₫iều kiện tài liệu nhập khác nhau có thể có.
• Kích hoạt-1 tới Kích hoạt-n miêu tả n hoạt ₫ộng khác nhau mà mạng lưới hệ thống có thể thực hiện phụ thuộc vào tổng hợp ₫iều kiện tài liệu nhập nào.
• Mỗi cột miêu tả 1 luật cụ thể : tổng 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 trật 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 ₫ó.

Tài liệu tham khảo: http://softwaretestingfundamentals.com/differences-between-black-box-testing-and-white-box-testing/ http://www.softwaretestingclass.com/difference-between-black-box-testing-and-white-box-testing/ https://technologyconversations.com/2013/12/11/black-box-vs-white-box-testing/