1. Khái niệm

Kiểm thử hộp đen: là một phương pháp kiểm thử phần mềm được thực hiện mà không biết được kết cấu bên trong của phần mềm, là cách mà các tester kiểm tra xem khối hệ thống như một chiếc hộp đen, không có cách nào nhìn thấy bên trong của cái hộp.

Bạn Đang Xem: Kỹ thuật kiểm thử hộp đen – Black box Testing

• Nó còn được gọi là kiểm thử hướng tài liệu hay là kiểm thử hướng in/out.

• Người kiểm thử nên xây dựng các nhóm giá trị nguồn vào mà sẽ thực thi đầy đủ tất cả những yêu cầu chức năng của Khóa học.

• Cách tiếp cận của khá nhiều tester so với khối hệ thống là không dùng bất kỳ một tri thức về cấu trúc lập trình bên trong khối hệ thống, xem khối hệ thống là một cấu trúc hoàn chỉnh, không thể can thiệp vào bên trong.

Black Box Testing chủ yếu là được thực hiện trong Function test và System test.

Phương pháp này được đặt tên như vậy bởi vì các Khóa học phần mềm, trong con mắt của khá nhiều tester, giống như một hộp đen; bên trong mà người ta không thể nhìn thấy. Phương pháp này nỗ lực cố gắng tìm ra các lỗi trong các loại sau:

• Chức năng không xác thực hoặc thiếu.
• Lỗi giao diện.
• Lỗi trong cấu trúc tài liệu hoặc truy cập cơ sở tài liệu phía ngoài.
• Hành vi hoặc hiệu suất lỗi.
• Khởi tạo và chấm hết các lỗi.

Mọi kỹ thuật nào cũng sẽ có ưu điểm và nhược điểm của nó. Các khối hệ thống thường phải được sử dụng nhiều phương pháp kiểm thử khác nhau để đảm bảo được chất lượng sản phẩm của khối hệ thống lúc tới tay người dùng.

2. Ưu điểm của kiểm thử hộp đen

• Các tester được thực hiện từ ý kiến của người dùng và sẽ viện trợ 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à các 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 thiết phải biết tiếng nói 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, được cho phép một chiếc nhìn khách quan và tránh sự phát triển thiên vị.

• Khố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 lúc mà các yêu cầu chức năng được xác định.

3. Nhược điểm của kiểm thử hộp đen

• Tài liệu nguồn 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ả 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.

• Xem Thêm : Cách Làm Cà Phê Muối Ngon Chuẩn Vị

  Khả năng để bản thân kỹ sư lạc lối trong những khi kiểm thử là rất rộng lớn.

• Chỉ có một số nhỏ các nguồn vào có thể được kiểm tra và nhiều đường dẫn Khóa học sẽ tiến hành để lại không đượ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 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.

4. Flow của Black box Testing

Hình 1: Phase test trong giai đoạn test

4.1. Nội dung công việc trong giai đoạn test

• Tiến độ test có tuần tự các phase sau: Kế hoạch test, thiết kế test, tạo testcase, thực hiện test, văn bản báo cáo test.
• Trong số đó: “kế hoạch test” và “thiết kế test” là phase quan trọng để phát hiện ra lỗi và xác nhận chất lượng sản phẩm.

4.2. Nội dung công việc trong giai đoạn test

Kế hoạch test: Chỉ ra rõ ràng mục tiêu và phạm vi của giai đoạn test để kiểm tra xem là test bằng approach thế nào. Kiểm soát và điều chỉnh resource thành viên và quyết định cả schedule.

Thiết kế test: Quyết định xem là sẽ sử dụng cái gì cho mục tiêu và loại test càn được thực hiện trong giai đoạn test đó, chức năng đối tượng người sử dụng test, phương pháp test, import và export test. Ngoài ra cũng quyết định cụ thể hơn vật liệu cấp thiết để thực hiện test hay tiêu chuẩn quyết định thành công/ không thành công.

Tạo testcase: Tạo document ghi trạng thái trước lúc khai mạc test và kết quả mong đợi (kết quả chạy đối tượng người sử dụng test theo xét tuyển và trình tự thao tác khi thực hiện test sẽ thế nào) và cột trạng thái (cột ghi lại kết quả thao tác của đối tượng người sử dụng test).

Thực hiện test: Vừa xem testcase vừa cho chạy phần mềm thực tế để tiến hành test, sau đó lưu lại kết quả bằng dấu pass hoặc fail vào cột trạng thái testcase. Trường hợp có testcase khác với kết quả mong đợi thì ghi dấu fail vào cột trạng thái, rồi tạo bản văn bản báo cáo lỗi. Trong bản văn bản báo cáo lỗi: trình bày nội dung mô tả hiện tượng lạ khác với kết quả mong đợi và hiện tượng lạ đó phát sinh trong trường hợp thế nào (thao tác, giả nhập, xét tuyển,…)

Văn bản báo cáo test: Tóm tắt kết quả để văn bản báo cáo. Địa thế căn cứ vào các loại tài liệu (mục thực hiện, hiệu quả của việc test, công số thực hiện,…) và tài liệu lỗi (số lỗi được tìm ra, số lỗi theo mức độ quan trọng,…) để xếp loại xem có thỏa mãn tiêu chuẩn pass/ fail của test không? Ngoài ra cũng đề xuất thêm risk có thể sinh ra sau khoản thời gian release và mục cần bổ sung trong dự án cho thời đoạn tiếp theo.

4.2. Flow của Test plan và thiết kế test

Hình 2: Flow kế hoạch test và thiết kế test

(1) Xác nhận mục tiêu của test

• Xem bản kế hoạch tổng thể test để xác nhận mục tiêu của test(đặc tính chất lượng sản phẩm, những điểm quan trọng …).
• Quyết định phạm vi của test, nội dung của test, phương pháp test.

(2) Tạo list chức năng

• Đưa ra toàn bộ chức năng làm đối tượng người sử dụng test.
• Cần hiểu trước về phần lớn những hoạt động sinh hoạt của chức năng.
• Không suy đoán đối tượng người sử dụng hoặc phi đối tượng người sử dụng của test.

(3) Đưa ra qua điểm test

• Ý kiến test là ” cánh cửa của Test “.
• Ví dụ: Xác nhận sự xác thực của kết quả tính toán được hiển thị trên màn hình hiển thị, xác nhận chức năng check mục nhập, xác nhận thời kì xử lý ==> ý kiến test.
• Ý kiến test đã đáp ứng được đúng mục tiêu test?

(4) Phân chia chức năng cho từng ý kiến test

• Ứng dụng ý kiến test cho từng chức năng để tránh bị quên.
• Có thể hình dung việc test một cách cụ thể.
• Có thể nắm bắt được quy mô test và mức độ quan trọng của khá nhiều ý kiến test.

(5) Kiểm tra vận dụng phương pháp và kỹ thuật test

• Tiến hành thiết kế test dối với tuần tự từng phối hợp.
• Lựa chọn và quyết định phương pháp test có thể phát hiện ra lỗi một cách hiệu quả nhất từ một trong số các phương pháp test.

Các mục kiểm tra khác

• Resouce cấp thiết.
• Schedule.
• Cơ cấu tổ chức & tổ chức, vai trò khi thực hiện test.
• Thiết bị, môi trường xung quanh, địa điểm thao tác cần để thực hiện test.

5. Phương pháp truy xuất và tính cấp thiết của ý kiến Test

5.1. List ý kiến test

Khái niệm: List ý kiến test là list tóm tắt ý kiến test theo như hình thức có thể tái sử dụng.

• Có thể thực hiện test khối hệ thống, mà không phải test nhờ vào kinh nghiệm thành viên.
• Có thể giảm nhẹ được sự chênh lệch kỹ năng thành viên. (chênh lệch giữa người mới và Chuyên Viên,…).
• Có thể tránh trùng, hoặc thiếu sót ý kiến phải test.
• Suy đoán mức độ quan trọng trong dự án dễ dàng.

5.2. Phương pháp tạo list ý kiến Test

• Tạo list ý kiến test, phân ý kiến test thành các thời đoạn, tiếp tục phân ý kiến test lớn thành các ý kiến test nhỏ hơn.
• Nếu có tiêu chuẩn phân loại, thì công việc trở thành dễ dàng hơn.
• Ví dụ: Lấy các tiêu chí ở đây làm tiêu chuẩn phân loại.

• Ví dụ phân loại ý kiến test

• Ví dụ list ý kiến Test

6. Phương pháp kiểm thử hộp đen

Sau đây tôi xin giới thiệu chung một vài kỹ thuật trong kiểm thử hộp đen, chi tiết cụ thể hơn sẽ tiến hành nghiên cứu trong những nội dung bài viết sau.

Đoán lỗi: là một kỹ năng quan trọng của tester, thậm chí là có thể gọi là thẩm mỹ và làm đẹp. Một tuyệt bút của trực quan. Phương pháp này đặc biệt quan trọng dựa vào kinh nghiệm và tri thức của tester. Nhiều tester nỗ lực cố gắng đoán xem phần nào của khối hệ thống mà có khả năng ẩn chứa lỗi. Với phương pháp này, họ không cần một dụng cụ hay một kịch bản kiểm thử nào khi khai mạc vào việc.

Kiểm thử dựa vào đồ thị nguyên nhân – kết quả (Cause Effect Graphing): là một kỹ thuật thiết kế kiểm thử phần mềm liên quan đến việc xác định các trường hợp (xét tuyển nguồn vào) và các hiệu ứng (xét tuyển đầu ra). Vì các khối hệ thống hiện nay đều được phát triển trên nền tảng OOP, do đó, tất cả chúng ta có thể đã sở hữu một đồ thị các đối tượng người sử dụng mà khối hệ thống khái niệm và kết nối. Từ đồ thị này, tất cả chúng ta dễ dàng biết các quan hệ của những đối tượng người sử dụng mà khối hệ thống xử lý, từ này sẽ cho tất cả chúng ta các kịch bản kiểm thử phù hợp.

Phân vùng tương đương (Equivalence Class): là một kỹ thuật kiểm thử phần mềm có liên quan đến phân 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, sau đó tất cả chúng ta sẽ viết ra các kịch bản kiểm thử cho từng phần, chọn giá trị thay mặt từ mỗi phân vùng làm tài liệu thử nghiệm.

• Phân vùng tương đương: là kỹ thuật thực hiện test theo từng class đồng giá trị (tập hợp xét tuyển cùng một thao tác).
• Tập hợp giá trị input có cùng một kết quả xử lý, tập hợp thời kì có cùng một kết quả xử lý, tập hợp kết quả export được xử lý cùng một giá trị nhập.
• 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ỉ có test trên các thành phần thay mặt.
• Chọn tối thiểu một giá trị thay mặt từ các class đồng giá trị để tiến hành test.

Xem Thêm : Cocos2dx là gì? Phát triển game trên đa nền tảng Cocos2dx

-> Nếu có lỗi xẩy ra thì những giá trị khác trong class đồng giá trị cũng sẽ có được lỗi giống nhau.

Ví dụ

Spec yêu cầu nhập 4 <= password <= 15

1. Nhập đúng đưa ra mess hoàn thành thiết lập.

2. Nhập sai: mess yêu cầu nhập lại.

Như vậy ta sẽ thực hiện 2 testcase: một giá trị cho phần thông tin hoàn thành Setting và một giá trị phần thông tin lỗi.

Phân tích giá trị biên (Boundary Value Analysis): là một kỹ thuật kiểm thử phần mềm có liên quan đến việc xác định biên (ranh giới) của xét tuyển mô tả cho những giá trị nguồn vào và chọn giá trị ở biên và bên cạnh giá trị biên làm tài liệu kiểm thử. Phương pháp phân tích giá trị biên sẽ đưa ra các giá trị đặc biệt quan trọng, gồm có loại tài liệu, giá trị lỗi, bên trong, phía ngoài biên giá trị, lớn số 1 và nhỏ nhất.

Những kỹ sư nhiều kinh nghiệm kiên cố đã từng gặp phải các lỗi của khối hệ thống ngay tại giá trị biên. Đó là lý do vì sao phân tích giá trị biên lại quan trọng khi kiểm thử khối hệ thống.

• Test giá trị biên được thực hiện theo trình tự ở đây:

1. Tìm ra đường giáp ranh biên giới
2. Quyết định giá trị biên
3. Quyết định giá trị để test

• Giá trị biên.
• Dưới giá trị biên. (Nếu là class đồng giá trị)
• Trên 1 giá trị biên. (Nếu là class đồng giá trị)

Ví dụ

Spec yêu cầu nhập 4 <= password <= 15 Giá trị được test sẽ như sau:

Sử dụng bảng quyết định (Decision Tables)

• Là dùng bảng để hiển thị list các thao tác phần mềm được quyết định trên các xét tuyển khác nhau.
• Decision table testing chú trọng vào nhiều xét tuyển để thực hiện test.

Ngoài ra, kiểm thử hộp đen còn tồn tại một số kỹ thuật như: Domain Tests, Orthogonal Arrays, State Models, Exploratory Testing (kiểm thử chủ yếu dựa vào kinh nghiệm và khả năng focus vào việc test các chức năng của tester), All-pairs testing (kiểm thử tất cả những cặp), …

7. Tài liệu tham khảo

http://www.tutorialspoint.com/software_testing_dictionary/black_box_testing.htm

Black Box Testing

https://vntesters.com/kiem-thu-hop-den/

http://www.testingvn.com/viewtopic.php?t=4

https://www.wattpad.com/1982587-thế-nào-là-kiểm-thử-hộp-đen-có-những-loại-kiểm-thử