Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wordpress-seo domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/vinascript/html/wp-includes/functions.php on line 6114
Kiểm thử hộp đen dành cho Manual Tester - VinaScript

Latest Post

Triển khai dự án PHP, Mysql với Nginx trên Docker Tìm hiểu về HTML – Ưu điểm, nhược điểm và cách hoạt động của HTML

Trong quá trình kiểm thử phần mềm, Manual Tester đóng một vai trò quan trọng trong việc đảm bảo chất lượng sản phẩm. Trong số các phương pháp kiểm thử, kiểm thử hộp đen là một trong những phương pháp phổ biến được áp dụng rộng rãi. Trong đó, Manual Tester đóng vai trò chính yếu trong việc thiết kế và thực thi các bộ kiểm thử dựa trên các yêu cầu và chức năng của phần mềm mà không cần biết đến cấu trúc hoặc mã nguồn bên trong.

Trong phần giới thiệu này, chúng ta sẽ khám phá cách Manual Tester áp dụng kiểm thử hộp đen để đảm bảo tính đúng đắn và hiệu suất của sản phẩm phần mềm. Chúng ta sẽ tìm hiểu về cách Manual Tester áp dụng các kỹ thuật và phương pháp kiểm thử hộp đen để tạo ra các bộ kiểm thử hiệu quả và phù hợp với yêu cầu cụ thể của dự án.

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

Kiểm thử hộp đen (Black box testing) là một phương pháp kiểm thử phần mềm tập trung vào đầu vào và đầu ra của chương trình mà không yêu cầu kiến thức về cấu trúc bên trong của mã nguồn.

Trong kiểm thử hộp đen, tester coi phần mềm như một “hộp đen” và chỉ kiểm tra các chức năng hoặc tính năng mà phần mềm cung cấp, mà không quan tâm đến cách thức cài đặt bên trong. Cụ thể, tester sẽ tập trung vào việc kiểm tra các chức năng như mua sắm, đăng sản phẩm, tạo tài khoản, và đánh giá hiệu suất làm việc của ứng dụng.

Ưu điểm của kiểm thử hộp đen là các tester không cần phải có kiến thức sâu về công nghệ và không cần biết về mã nguồn. Họ có thể tập trung vào việc kiểm tra các chức năng và tính năng của ứng dụng một cách độc lập và khách quan.

Phương pháp này giúp phát hiện các lỗi như chức năng không chính xác, lỗi giao diện, lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu bên ngoài, lỗi về hiệu suất và các vấn đề khác mà không cần phải xem xét cách thức triển khai bên trong phần mềm.

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.

 kiểm thử hộp đen - ảnh 2

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

kiểm thử hộp đen - ảnh 3

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)

Việc sử dụng bảng quyết định là một phương pháp hiệu quả để tổ chức và quản lý các kịch bản kiểm thử, đặc biệt là trong trường hợp có nhiều điều kiện và trạng thái phức tạp cần được kiểm tra. Qua bốn bước đó bạn đã nêu, người kiểm thử có thể tạo ra các bảng quyết định để phân loại và định hình kịch bản kiểm thử một cách chi tiết và có tổ chức.

Bằng cách này, người kiểm thử có thể đảm bảo rằng tất cả các trường hợp quan trọng được kiểm tra và phủ sóng một cách toàn diện, đồng thời giảm thiểu số lượng các ca kiểm thử cần thiết để đạt được mức độ kiểm thử mong muốn. Điều này giúp tiết kiệm thời gian và nguồn lực, đồng thời tăng tính hiệu quả của quá trình kiểm thử.

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?

kiểm thử hộp đen - ảnh 4

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

Kiểm thử hộp đen không yêu cầu các tester phải có kiến thức sâu về công nghệ thông tin, cho phép họ tập trung vào việc kiểm tra các chức năng và tính năng của phần mềm một cách độc lập và khách quan. Điều này làm cho kiểm thử hộp đen trở thành một lựa chọn phù hợp cho nhiều tester, bao gồm cả những người không có kinh nghiệm lập trình.

Đồng thời, việc sử dụng các kỹ thuật kiểm thử hộp đen, như kiểm thử hộp đen tĩnh, kiểm thử hộp đen hướng sự kiện, kiểm thử hộp đen phi chức năng, và kiểm thử hộp đen chuyên sâu, giúp manual tester xử lý các bộ test case một cách hiệu quả và chất lượng, đảm bảo rằng phần mềm được kiểm tra một cách toàn diện và chính xác.

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *