Kiểm thử hộp đen là xu hướng nghề nghiệp của các tester trái ngành.

1.      Kiểm thử hộp đen là gì?

Trái ngược với kiểm thử hộp trắng, kiểm thử hộp đen (Black box testing) là phương pháp test dựa trên đầu vào và đầu ra của chương trình mà không quan tâm tới code bên trong được viết ra sao. Tester sẽ xem phần mềm như là một hộp đen, chỉ nhìn được lớp vỏ bên ngoài mà không nhìn được cấu trúc bên trong.

Ví dụ: Ta có sản phẩm app thương mại điện tử:

• Kiểm thử hộp trắng sẽ test mã code mà developers đã lập trình tạo nên sản phẩm.
• Kiểm thử hộp đen sẽ test các chức năng như: Mua sắm, đăng sản phẩm, tạo tài khoản… hoặc hiệu suất làm việc của app.

Ưu điểm của kiểm thử hộp đen chính là các tester không cần có nền tảng công nghệ, không cần biết ngôn ngữ lập trình đều có thể thực hiện test được. Người kiểm thử khi vận dụng Black box testing sẽ là một phương diện độc lập, có cái nhìn khách quan về sản phẩm.

Phương pháp kiểm thử hộp đen sẽ cố gắng tìm ra lỗi ở các vấn đề sau: Chức năng không chính xác hoặc thiếu, lỗi giao diện, lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở bên ngoài, lỗi về hiệu suất…

2.      Các loại kiểm thử hộp đen

Kiểm thử hộp đen bao gồm 3 loại: Functional testing (Kiểm thử chức năng), Non-Functional testing (Kiểm thử phi chức năng) và Regression testing (Kiểm thử hồi quy).

• Functional testing kiểm tra chức năng của ứng dụng đó có hoạt động đúng như khách hàng mong đợi không.
• Non-Functional testing xem xét các hành vi bên ngoài của phần mềm dựa trên kinh nghiệm người dùng và mong đợi của khách hàng để kiểm tra phản hồi của hệ thống.
• Regression testing kiểm tra lại tính năng đã hoàn thiện nhằm chắc chắn rằng phần tính năng mới được thêm vào không phá hỏng các phần khác của ứng dụng.

Regression testing là một loại kiểm thử thuộc Black box testing.

3.      Các kỹ thuật kiểm thử hộp đen

4 kỹ thuật kiểm thử hộp đen phổ biến nhất: Phân vùng tương đương (Equivalence partitioning), Phân tích giá trị biên (Boundary value analysis), Bảng quyết định (Decision Tables) và Đoán lỗi (Error guessing)

a.      Phân vùng tương đương (Equivalence partitioning)

Phân vùng tương đương là kỹ thuật chia đầu vào thành những nhóm tương đương nhau. Nếu một giá trị trong nhóm hoạt động đúng thì tất cả các giá trị trong nhóm đó cũng hoạt động đúng và ngược lại. Mục đích của phương pháp này là giúp giảm đáng kể số lượng Test Case cần phải thiết kế vì mỗi lớp tương đương ta chỉ cần test trên các phần tử đại diện.

Thiết kế Test-case bằng phân vùng tương đương tiến hành theo 2 bước: Xác định các lớp tương đương và xác định các ca kiểm thử. Khi thực hiện kỹ thuật Equivalence partitioning, đầu vào sẽ được chia theo nguyên tắc:

• 1 lớp các giá trị lớn hơn.
• 1 lớp các giá trị nhỏ hơn.
• 1 lớp các giá trị hợp lệ.

b.      Phân tích giá trị biên (Boundary value analysis)

Phân tích giá trị biên là phương pháp test tất cả các giá trị ở vùng biên của dữ liệu vào và dữ liệu ra. Các tester sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ liệu. Do đó, thay vì phải kiểm thử toàn bộ dữ liệu vào và ra, ta có thể test từ 4 - 6 case mà vẫn đảm bảo hệ thống hoạt động tốt.

Boundary conditions là các vị trí ở giữa, trên và dưới các biên của lớp tương đương. Khi áp dụng kỹ thuật phân tích giá trị biên, người kiểm thử sẽ chọn các giá trị:

• Giá trị nhỏ nhất
• Giá trị ngay dưới giá trị nhỏ nhất
• Giá trị bình thường
• Giá trị ngay trên giá trị lớn nhất
• Giá trị lớn nhất

Kỹ thuật phân tích giá trị biên sẽ chọn 5 giá trị để kiểm thử.

c.      Bảng quyết định (Decision Tables)

Trong các kỹ thuật viết Test Case, đối với các trường dữ liệu đơn như textbox, các tester thường sử dụng các phương pháp phân vùng tương đương hay phân tích giá trị biên. Đối với kiểm thử hành vi của hệ thống với nhiều trường dữ liệu, Bảng quyết định (Decision table) sẽ giúp chúng ta phân loại và định hình được kịch bản kiểm thử một cách chính xác và rõ ràng hơn.

Bảng quyết định là một kỹ thuật tốt để áp dụng cho những trường hợp cần nhiều sự kết hợp. Kỹ thuật này hỗ trợ việc lựa chọn Test Case tối thiểu một cách có hệ thống kỹ thuật với độ bao phủ tối đa.

Có 4 bước để người kiểm thử tạo được Decision Tables:

• Liệt kê tất cả Conditions/Inputs.
• Tính số lượng kết hợp có thể (Rules).
• Đặt tất cả các kết hợp trong bảng. 
• Giảm thiểu các case kết hợp và quyết định Test Case.

d.      Đoán lỗi (Error guessing)

Đoán lỗi là kỹ thuật mô tả hành động phỏng đoán lỗi thường gặp của hệ thống dựa trên trực giác và kinh nghiệm của các tester. Người kiểm thử sẽ liệt kê các loại lỗi có thể xảy ra và cho vào Test Case để kiểm tra xác minh vấn đề.

Phương pháp này đặc biệt dựa vào kinh nghiệm và kiến thức của tester. Kỹ thuật đoán lỗi không tuân theo bất kỳ quy tắc cụ thể nào, Test Case có thể được thiết kế tùy thuộc vào nhiều yếu tố như: Đặc trưng hoạt động của phần mềm, lỗi đã xuất hiện ở các dự án tương tự khác…

Các yếu tố mà người kiểm thử hay sử dụng để đoán lỗi:

• Trực giác kiểm thử.
• Có kiến thức liên quan, hiểu rõ về hệ thống.
• Bài học rút ra từ các lần kiểm thử phần mềm trước, các lỗi thường gặp…
• Tập trung test theo từng phần, từng chức năng sẽ giúp tester chú trọng và lý giải những vấn đề xảy ra ở vùng nào.

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

Quy trình kiểm thử hộp đen có thể áp dụng theo 4 bước: Lập kế hoạch kiểm thử, thiết kế Test Case, thực hiện test và báo cáo kiểm thử.

a.      Lập kế hoạch test

Tester tiến hành phân tích yêu cầu và lập tài liệu tổng quan về việc kiểm thử dự án bao gồm những thông tin sau: 

• Phạm vi kiểm thử, hướng tiếp cận, quy trình kiểm thử, tài nguyên và nhân lực test.
• Các chức năng/module cần được kiểm tra; các công cụ và môi trường kiểm thử cần có.
• Ai test chức năng nào? - Khi nào bắt đầu thực hiện viết và hoàn thành test case? - Khi nào bắt đầu thực hiện và hoàn thành test?

Lập kế hoạch test là bước đầu của kiểm thử hộp đen

b.      Thiết kế Test case

Sau khi có được Test Plan, Tester bắt đầu xây dựng bộ Test Case dựa trên yêu cầu của phần mềm. Test Case cần mô tả được chi tiết dữ liệu đầu vào, hành động, kết quả mong đợi để xác định một chức năng của ứng dụng phần mềm có hoạt động đúng hay không. 

Template của Test Case có nhiều trường hợp nhưng bắt buộc phải có 5 mục chính: ID, mục đích kiểm thử, các bước thực hiện, kết quả mong đợi & kết quả thực tế.

c.      Thực hiện kiểm thử

Khi developers đã code và đưa sản phẩm lên môi trường kiểm thử, tester sẽ thực thi dựa trên Test Case đã viết. Trong quá trình test, nếu phát hiện ra bug (lỗi) thì tester sẽ log (viết) lên các tool quản lý lỗi. Bug của lập trình viên nào sẽ giao lại cho người đấy xử lý. Khi nào developers fix bug xong, tester sẽ nhận lại và tiến hành kiểm thử. 

d.      Báo cáo kiểm thử

Ở giai đoạn này, tester chuẩn bị báo cáo kết thúc kiểm thử, tổng hợp lại các chỉ số trong quá trình test. Cả team phát triển sẽ ngồi họp để đánh giá toàn bộ các tiêu chí xác định có thể kết thúc quy trình kiểm thử hay chưa. Những tiêu chí này khác nhau tùy theo từng dự án, thông thường bao gồm:

• Số lượng test case tối đa được thực thi Passed.
• Tỷ lệ lỗi giảm xuống dưới mức nhất định.
• Deadline được chốt từ giai đoạn làm kế hoạch kiểm thử.

Kết luận

Qua các thông tin chia sẻ trên, các tester cũng đã hiểu rõ hơn về kiểm thử hộp đen để lựa chọn cho mình hướng đi trong tương lai. Ưu điểm của kiểm thử hộp đen chính là các tester không cần có nền tảng công nghệ thông tin đều có thể thực hiện test được. Đặc biệt, 4 kỹ thuật kiểm thử  hộp đen giúp Manual tester xử lý được các bộ Test Case chất lượng.

Mở rộng ngay cơ hội việc làm Tester tại ITNavi - Nền tảng kết nối việc làm IT với hơn 1000++ jobs cập nhật mỗi ngày.

Xem thêm:

1000 việc làm IT tại Nền tảng kết nối việc làm ITNavi

6 giai đoạn của quy trình kiểm thử phần mềm

Từ A-Z về kiểm thử hộp trắng