Kỹ thuật kiểm thử hộp đen - Black box Testing

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 cấu tạo bên trong của phần mềm, là cách mà các tester kiểm tra xem 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.

• Nó còn được gọi là kiểm thử hướng dữ 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ị đầu vào mà sẽ thực thi đầy đủ tất cả các yêu cầu chức năng của chương trình.

• Cách tiếp cận của các tester đối với hệ thống là không dùng bất kỳ một kiến thức về cấu trúc lập trình bên trong hệ thống, xem 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 chương trình phần mềm, trong con mắt của các 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 cố gắng tìm ra các lỗi trong các loại sau:

• Chức năng không chính xác hoặc thiếu.
• 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.
• Hành vi hoặc hiệu suất lỗi.
• Khởi tạo và chấm dứt các lỗi.

Mọi kỹ thuật nào cũng có ưu điểm và nhược điểm của nó. Các 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 của hệ thống khi đến 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ừ 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.

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

• 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.

4. Flow của Black box Testing

Hình 1: Phase test trong công đoạn test

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

• Công đoạn test có lần lượt các phase sau: Kế hoạch test, thiết kế test, tạo testcase, thực hiện test, báo cáo test.
• Trong đó: "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.

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

Kế hoạch test: Chỉ ra rõ ràng mục đích và phạm vi của công đoạn test để kiểm tra xem là test bằng approach như thế nào. Đ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 đích và loại test càn được thực hiện trong công đoạn test đó, chức năng đối tượng test, phương pháp test, import và export test. Ngoài ra cũng quyết định cụ thể hơn nguyên liệu cần 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 khi bắt đầu test và kết quả mong đợi (kết quả chạy đối tượng test theo điều kiện và trình tự thao tác khi thực hiện test sẽ như 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 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 đó đánh dấu 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 báo cáo lỗi. Trong bản báo cáo lỗi: trình bày nội dung mô tả hiện tượng khác với kết quả mong đợi và hiện tượng đó phát sinh trong trường hợp như thế nào (thao tác, giả nhập, điều kiện,...)

Báo cáo test: Tóm tắt kết quả để báo cáo. Căn cứ vào các loại dữ liệu (mục thực hiện, hiệu quả của việc test, công số thực hiện,...) và dữ liệu lỗi (số lỗi được tìm ra, số lỗi theo mức độ quan trọng,...) để đánh giá 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 khi release và mục cần bổ sung trong dự án cho giai đ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 đích của test

• Xem bản kế hoạch tổng thể test để xác nhận mục đích của test(đặc tính chất lượng, 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 danh sách chức năng

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

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

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

(4) Phân chia chức năng cho từng quan điểm test

• Áp dụng quan điểm 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 các quan điểm 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 lần lượt từng kết 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ần thiết.
• Schedule.
• Cơ cấu & tổ chức, vai trò khi thực hiện test.
• Thiết bị, môi trường, địa điểm làm việc cần để thực hiện test.

5. Phương pháp truy xuất và tính cần thiết của quan điểm Test

5.1. Danh sách quan điểm test

Khái niệm: Danh sách quan điểm test là danh sách tóm tắt quan điểm test theo hình thức có thể tái sử dụng.

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

5.2. Phương pháp tạo danh sách quan điểm Test

• Tạo danh sách quan điểm test, phân quan điểm test thành các giai đoạn, tiếp tục phân quan điểm test lớn thành các quan điểm test bé hơn.
• Nếu có tiêu chuẩn phân loại, thì công việc trở nên dễ dàng hơn.
• Ví dụ: Lấy các tiêu chí dưới đây làm tiêu chuẩn phân loại.

• Ví dụ phân loại quan điểm test

• Ví dụ danh sách quan điểm 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 hơn sẽ được nghiên cứu trong những bài viết sau.

Đoán lỗi: là một kỹ năng quan trọng của tester, thậm chí có thể gọi là nghệ thuật. Một kiệt tác của trực giác. Phương pháp này đặc biệt dựa vào kinh nghiệm và kiến thức của tester. Nhiều tester cố gắng đoán xem phần nào của 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 công cụ hay một kịch bản kiểm thử nào khi bắt đầu 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 (điều kiện đầu vào) và các hiệu ứng (điều kiện đầu ra). Vì các hệ thống hiện nay đều được phát triển trên nền tảng OOP, do đó, chúng ta có thể có được một đồ thị các đối tượng mà hệ thống định nghĩa và kết nối. Từ đồ thị này, chúng ta dễ dàng biết các mối quan hệ của những đối tượng mà hệ thống xử lý, từ đó sẽ cho 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ị đầu vào thành các phân vùng hợp lệ và không hợp lệ, sau đó 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ị đại diện từ mỗi phân vùng làm dữ 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 điều kiệ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 gian 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 đí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.
• Chọn tối thiểu một giá trị đại diện từ các class đồng giá trị để tiến hành test.

--> Nếu có lỗi xảy ra thì các giá trị khác trong class đồng giá trị cũng sẽ 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 báo hoàn thành Setting và một giá trị phần thông báo 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 điều kiện mô tả cho các giá trị đầu vào và chọn giá trị ở biên và bên cạnh giá trị biên làm dữ 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, bao gồm loại dữ liệu, giá trị lỗi, bên trong, bên ngoài biên giá trị, lớn nhất và nhỏ nhất.

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

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

1. Tìm ra đường biên
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ị danh sách các thao tác phần mềm được quyết định trên các điều kiện khác nhau.
• Decision table testing chú trọng vào nhiều điều kiện để thực hiện test.

Ngoài ra, kiểm thử hộp đen còn có 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ả các cặp), ...

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

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

http://softwaretestingfundamentals.com/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ử