Kiểm Thử Hộp Đen - Black box Testing

Kiểm thử hộp đen là à phương pháp test dựa trên đầu vào và đầu ra của chương trình để 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ư là 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ỳ kiến thức về mã hoặc thuật toán của chương trình. Nó kiểm tra các chức năng của hệ thống tức là những gì 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 đó.

2.1 Ưu điểm

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

2.2 Nhược điểm

• Dữ liệu đầu 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ả các yếu tố đầu vào, và thiếu cả thời gian cho việc tập hợp này.
• Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao

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 bao gồm việc chia các giá trị đầu vào thành các phân vùng hợp lệ và không hợp lệ và chọn các giá trị đại diện từ mỗi phân vùng làm dữ liệu kiểm tra.

• Mục đích : 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ỉ cần test trên các phần tử đại diện.
• 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ị lớn hơn 1 lớp các giá trị nhỏ hơn n lớp các giá trị hợp lệ
• 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ỉ cho phép nhập số ký tự vào trong khi nhập của user nằm [6 - 20] nên ta có tình huống kiểm thử sau:

Nhập vào một trường hợp hợp lệ:nhập 7 ký tự. Nhập vào trường hợp không hợp lệ thứ nhất: nhập 5 ký tự. Nhập vào trường hợp không hợp lệ thứ hai: nhập vào 21 ký tự. Trường hợp đặc biệt: 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à chúng ta sẽ test tất cả các giá trị ở vùng biên của dữ liệu vào và dữ liệu ra. Chúng ta sẽ tập trung vào các giá trị biên chứkhông test toàn bộ dữ liệu. Thay vì chọn nhiều giá trị trong lớp đương tươngđể làm đại diện, 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 điều kiện 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ị bình thường
• Giá trị ngay dưới giá trị lớn nhất
• Giá trị lớn nhất Ví dụ: Cho một mảng [ -3 , 10] ta có thể thiết kế được các test case là: Đáp án: Giá trị nhỏ nhất: -3 Giá trị lớn nhất: 10 Giá trị nhỏ hơn giá trị nhỏ nhất: -4 Giá trị lớn hơn giá trị lớn nhất: 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ự kết hợp của các trường hợp đầu vào. Việc kiểm tra sự kết hợp đầu vào không phải là một nhiệm vụ đơn giản bởi vì nếu bạn phân lớp tương đương các trạng thái đầu vào thì số lượng sự kết 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 biểu diễn như một điềukiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào. Mỗi kết quả được biểu diễn như là một biểu thức Bool biểu 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 điều kiện vào và hành động cho mỗi 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 đă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 còn lại đăng nhập không thành công: Đáp án:

3.4 Đoán lỗi

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 chương trình đã được phát triển - đã code - dựa vào kinh nghiệm trong các lần kiểm thử trước. Phạm vi của các trường hợp kiểm thử thường được dựa vào các kiểm thử viên - tester - có kiến thức liên quan, là những người đã có kinh nghiệm sử dụng và trực giác để 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 điển hình như chia cho không, null pointer, hoặc các biến không hợp lệ. Đ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 khi 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ĩ đến 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 dữ liệu đặc biệt 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/