+2

KIỂM THỬ HỘP ĐEN

1. Black box testing là gì?

  • Black box testing tập trung mô tả hệ thống làm gì chứ không phải hệ thống làm việc như thế nào.
  • Mô tả các khả năng hoạt động của hệ thống.
  • Nó còn được biết đến như là kiểm thử chức năng.
  • Kĩ thuật Black box testing :
    • Phân vùng tương đương (Equivalent Partitioning).
    • Giá trị biên (Boundary Value).
    • Bảng quyết định/ Kiểm thử các cặp (Decision Table/Pairwise testing).
    • Kiểm thử biến đổi trạng thái (State Transition).
  • Black box testing có thể được sử dụng ở bất kì mức độ kiểm thử nào và để thiết kế test case.

2. Các kỹ thuật quan trọng trong black box testing:

  • Phân vùng tương đương (Equivalent Partitioning):
    • Được thiết kế nhằm giảm thiểu số lượng các trường hợp phải kiểm thử bằng cách chia các điều kiện đầu vào thành những vùng tương đương nhau. Đầu vào mỗi lớp sẽ được lựa chọn từ một phân vùng để kiểm thử. Bằng cách này cùng 1 lúc người ta có thể kiểm thử cho một phân vùng.
    • Cách thực hiện:
      • Bước 1: Xác định các lớp tương đương của đầu vào hay đầu ra. Lấy điều kiện được chấp nhận của đầu vào hay đầu ra đã được mô tả từ trước và rút ra ít nhất 2 lớp cho điều kiện đó: lớp hợp lệ và không hợp lệ.
      • Bước 2: Thiết kế test case dựa trên các lớp tương đương
  • Giá trị biên (Boundary Value):
    • Là quá trình lựa chọn các trường hợp kiểm thử hoặc dữ liệu kiểm thử bằng việc biết trước các giá trị được chấp nhận (hợp lệ) và không được chấp nhận (không hợp lệ). Các bài kiểm thử được thực hiện để kiểm tra các giá trị bên trong và bên ngoài quanh các cạnh ranh giới (biên).
    • Các giá trị được lựa chọn để kiểm tra:
      • Giá trị nhỏ nhất.
      • Ngay trên giá trị nhỏ nhất.
      • Một giá trị bình thường.
      • Ngay dưới giá trị lớn nhất.
      • Giá trị lớn nhất.
  • Bảng quyết định/ Kiểm thử các cặp (Decision Table/Pairwise testing)
    • Bảng quyết định sử dụng mô hình luận lý phức tạp để người dùng dễ dàng thấy các kết hợp có thể có của các điều kiện đang xem xét và các hành động tương ứng với tập hợp giá trị của chuỗi điều kiện.
    • Các bước tạo bảng:
      • Bước 1: Phân tích các điều kiện và hành động của hệ thống Ví dụ máy ATM: Điều kiện được rút tiền: Số tiền trong tài khoản lớn hơn số tiền định rút hoặc đã được cấp tín dụng.
      • Bước 2: Thêm các cột trường hợp giá trị của điều kiện.
      • Bước 3: Cố gắng giảm số lượng các cột điều kiện: Vì chỉ cần số tiền lớn hơn trong tài khoản là khách có thể rút được nên không cần quan tâm xem khách được cấp tín dụng chưa.
      • Bước 4: Xác định hành động tương ứng của hệ thống
      • Bước 5: Viết các kịch bản kiểm thử: Viết chi tiết các bước và thiết lập dữ liệu kiểm thử cho kịch bản kiểm thử.
  • Kiểm thử biến đổi trạng thái:
    • Kiểm thử chuyển đổi trạng thái tập trung vào việc kiểm tra quá trình chuyển đổi từ một trạng thái của một đối tượng (ví dụ, một tài khoản) sang trạng thái khác.
    • Sử dụng một biểu đồ chuyển trạng thái để xác định quá trình chuyển đổi trạng thái đó có thể xảy ra và chuyển tiếp trạng thái đó không thể xảy ra.
    • Chuyển đổi trạng thái có 4 phần cơ bản: * Các trạng thái mà phần mềm có thể thực hiện. * Các chuyển đổi từ 1 trạng thái sang 1 trạng thái khác ( không phải các quá trình chuyển đổi đều được cho phép). * Các sự kiện có thể gây ra chuyển đổi trạng thái ( đóng tài khoản hay rút tiền). * Những hành động là kết quả của 1 sự chuyển đổi ( thông báo lỗi hoặc đưa tiền ra khỏi máy).

3. Ưu điểm/ khuyết điểm kiểm thử hộp đen:

  • Ưu điểm:
    • Các tester được thực hiện từ quan điểm của người dùng và sẽ giúp đỡ trong việc sáng tỏ sự chênh lệch về thông số kỹ thuật.
    • Các tester theo phương pháp black box không có “mối ràng buộc” nào với code, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi. Sử dụng nguyên tắc, "Hỏi và bạn sẽ nhận" các tester black box tìm được nhiều bug ở nơi mà các DEV không tìm thấy.
    • Tester có thể không phải IT chuyên nghiệp, không cần phải biết ngôn ngữ lập trình hoặc làm thế nào các phần mềm đã được thực hiện.
    • Các tester có thể được thực hiện bởi một cơ quan độc lập từ các developer, cho phép một cái nhìn khách quan và tránh sự phát triển thiên vị.
    • 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.
  • 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.
    • Nhiều dự án không có thông số rõ ràng thì việc thiết kế test case rất khó và do đó 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.
    • Chỉ có một số nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn chương trình sẽ được để lại chưa được kiểm tra.
    • Kiểm thử black box được xem như "là bước đi trong mê cung tối đen mà không mang đèn pin” bởi vì tester không biết phần mềm đang test đã được xây dựng như thế nào. Có nhiều trường hợp khi một tester viết rất nhiều trường hợp test để kiểm tra một số thứ có thể chỉ được test bằng một trường hợp test và/hoặc một vài phần cuối cùng không được test hết.

All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí