Kiểm thử hộp đen là à phương pháp test dựa trên nguồn vào và đầu ra của lớp học để test mà không quan tâm tới code bên trong được viết ra sao. Tester xem phần mềm như thể một hộp đen. Kiểm thử hộp đen không yêu cầu kỹ sư kiểm thử cần phải có bất kỳ tri thức về mã hoặc thuật toán của lớp học. Nó kiểm tra các chức năng của mạng lưới hệ thống tức là những gì mạng lưới hệ thống được cho là cần phải làm dựa trên các Đặc tả yêu cầu. Các trường hợp kiểm thử thường được xây dựng xung quanh đó.

Bạn Đang Xem: Kiểm Thử Hộp Đen – Black box Testing

2.1 Ưu điểm

• Kỹ sư kiểm thử có thể không phải IT chuyên nghiệp
• Mạng lưới hệ thống thật sự với toàn bộ yêu cầu của nó được kiểm thử xác thực
• Thiết kế kịch bản kiểm thử khá nhanh, ngay trong khi mà các yêu cầu chức năng được xác định

2.2 Nhược điểm

• Tài liệu nguồn vào yêu cầu một khối lượng mẫu (sample) khá lớn
• Khó viết kịch bản kiểm thử do cần xác định tất cả những yếu tố nguồn vào, và thiếu cả thời kì cho việc tập hợp này.
• Khả năng để bản thân kỹ sư lạc lối trong những lúc kiểm thử là rất lớn

3.1 Phân vùng tương đương

Đây là một kỹ thuật thiết kế kiểm thử phần mềm gồm có việc chia các giá trị nguồn vào thành các phân vùng hợp thức và không hợp thức và chọn các giá trị đại diện thay mặt từ mỗi phân vùng làm tài liệu kiểm tra.

• Mục tiêu : Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi lớp tương đương ta chỉ việc test trên các thành phần đại diện thay mặt.
• Thiết kế Test-case bằng phân lớp tương đương tiến hành theo 2 bước: (1). Xác định các lớp tương đương (2). Xác định các ca kiểm thử
• Nguyên tắc: 1 lớp các giá trị to ra hơn 1 lớp các giá trị nhỏ hơn n lớp các giá trị hợp thức
• Ví dụ minh họa: Thiết kế test case sao cho khi người dùng nhập user vào ô text thì chỉ cho nhập số ký tự [6 – 20 ]. Đáp án: Do yêu cầu của bài toán chỉ được chấp nhận nhập số ký tự vào trong những lúc nhập của user nằm [6 – 20] nên ta có tình huống kiểm thử sau:

Xem Thêm : Các thứ trong tiếng Anh: Cách đọc, viết và ý nghĩa của các thứ

Nhập vào một trong những trường hợp hợp thức:nhập 7 ký tự. Nhập vào trường hợp không hợp thức thứ nhất: nhập 5 ký tự. Nhập vào trường hợp không hợp thức thứ hai: nhập vào 21 ký tự. Trường hợp đặc biệt quan trọng: không nhập gì vào ô text đó (để trống).

3.2 Phân tích giá trị biên

Đây là phương pháp test mà tất cả chúng ta sẽ test tất cả những giá trị ở vùng biên của tài liệu vào và tài liệu ra. Tất cả chúng ta sẽ tập trung vào các giá trị biên chứkhông test toàn bộ tài liệu. Thay vì chọn nhiều giá trị trong lớp đương tươngđể làm đại diện thay mặt, phân tích giá trị biên yêu cầu chọn một hoặc vài giá trị là các cạnh của lớp tương đương để làm ĐK test. Phân tích giá trị biên là kỹ thuật thiết kế test case và hoàn thành phân vùng tương đương. Mục tiêu là lựa chọn các test case để thực thi giá trị biên. Phân tích giá trị biên sẽ chọn các giá trị:

• Giá trị nhỏ nhất
• Giá trị ngay trên giá trị nhỏ nhất
• Giá trị thông thường
• Giá trị ngay dưới giá trị lớn số 1
• Giá trị lớn số 1 Ví dụ: Cho một mảng [ -3 , 10] ta có thể thiết kế được những test case là: Đáp án: Giá trị nhỏ nhất: -3 Giá trị lớn số 1: 10 Giá trị nhỏ hơn giá trị nhỏ nhất: -4 Giá trị to ra hơn giá trị lớn số 1: 11 Giá trị nằm trong -3 và 10: 0

3.3 Sử dụng bảng quyết định

Một điểm yếu của hai phương pháp trên là chúng không khảo sát sự phối hợp của khá nhiều trường hợp nguồn vào. Việc kiểm tra sự phối hợp nguồn vào không phải là một nhiệm vụ đơn giản bởi vì nếu khách hàng phân lớp tương đương các trạng thái nguồn vào thì số lượng sự phối hợp thường là rất lớn. Bảng quyết định sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thành phần phần mềm. Mỗi nguyên nhân được trình diễn như một điềukiện (đúng hoặc sai) của một nguồn vào, hoặc phối hợp các nguồn vào. Mỗi kết quả được trình diễn như thể một biểu thức Bool trình diễn một kết quả tương ứng cho những thành phần vừa thực hiện. Kỹ thuật gồm có 4 bước:

• Xác định ĐK vào và hành động cho từng module cần kiểm định.
• Xác định đồ thị nguyên nhân – kết quả.
• Đồ thị được chuyển thành bảng quyết định.
• Những phần trong bảng quyết định được chuyển thành test case. Ví dụ: Trên màn hình hiển thị đăng nhập, có 2 thông tin cần đưa vào là Tên đăng nhập và mật khẩu, chỉ thực hiện đăng nhập thành công nếu nhập đúng cả Tên đăng nhập và mật khẩu. Các trường hợp sót lại đăng nhập không thành công: Đáp án:

3.4 Đoán lỗi

Xem Thêm : Con mẻ là gì? Cách nuôi mẻ đúng chuẩn thơm ngon

Trong kiểm thử phần mềm, đoán lỗi – error guessing – là một phương pháp kiểm thử, trong đó các trường hợp kiểm thử – test case – được sử dụng để tìm lỗi trong các lớp học đã được phát triển – đã code – dựa vào kinh nghiệm trong mỗi lần kiểm thử trước. Phạm vi của khá nhiều trường hợp kiểm thử thường được dựa vào các kiểm thử viên – tester – có tri thức liên quan, là những người dân đã có kinh nghiệm sử dụng và trực quan để xác định những tình huống thường gây ra lỗi trong phần mềm. Các lỗi tiêu biểu như chia cho không, null pointer, hoặc các biến không hợp thức. Đoán Lỗi không có quy tắc rõ ràng để kiểm thử, test case có thể được thiết kế tùy thuộc vào tình hình, hoặc hoặc luồng công việc trong các tài liệu mô tả chức năng hoặc khi một lỗi không mong muốn / không được mô tả trong tài liệu được tìm thấy trong những lúc hoạt động kiểm thử. Đoán Lỗi không có quy tắc, nó chỉ sử dụng các kỹ năng kiểm thử trước đó.

Trong kiểm thử phần mềm, đoán lỗi có thể nghĩ tới các tình huống nơi mà phần mềm sẽ thất bại. Ví dụ: Chia cho không Nhấn nút gửi trên mẫu đơn mà không cần điền vào bất kỳ mục. Nhập các tài liệu đặc biệt quan trọng vào các ô nhập liệu và sau đó kiểm tra hành vi của phần mềm.

[1] https://vntesters.com/kiem-thu-hop-den/ [2] http://softwaretestingfundamentals.com/black-box-testing/