Trong kiểm demo phần mềm, có rất nhiều kỹ thuật kiểm test được nói tới. Tuy nhiên ở nội dung bài viết này, tôi chỉ xin nhằm cập mang đến 2 kỹ thuật kia là: nghệ thuật kiểm demo hộp black (Black Box test) cùng Kỹ thuật kiểm thử hộp trắng (White box test)

1. KHÁI NIỆM CỦA black BOX thử nghiệm VÀ white BOX TEST

1.1. BACK BOX TEST

1.1.1. Định nghĩaKiểm tra hộp black (Black box testing) là một phương thức kiểm thử ứng dụng mà việc kiểm tra các tác dụng của một vận dụng không cần quan tâm vào kết cấu nội bộ hoặc hoạt động của nó.

Bạn đang xem: Black box testing là gì

*

1.1.2. Đối tượng được kiểm thửLà nguyên tố phần mền (TPPM) có thể là 1 hàm chức năng, 1 modul chức năng, 1 phân hệ chức năng...

1.1.3. Cách thức thử nghiệm: phụ thuộc chức năngKiểm thử hộp black (Black box test) có thể được áp dụng phần đông đến mọi cấp độ của kiểm demo phần mềm:

Kiểm thử đơn vị chức năng (Unit test)Kiểm thử tích phù hợp (Intergration test)Kiểm thử khối hệ thống (System test)Kiểm thử đồng ý (Acceptance test).

Tuy nhiên, đen box kiểm tra được sử dụng thích hợp nhất trong kiểm thử khối hệ thống (System test) với Kiểm thử đồng ý (Acceptance test)

1.1.4. Đặc điểm

Là kế hoạch kiểm demo TPPM phụ thuộc vào thông tin nhất là những đặc tả về yêu thương cầu tác dụng của TPPM tương ứng.Người kiểm test không quan trọng phải có kỹ năng và kiến thức về việc mã hoá, cấu trúc phía bên trong của TPPM, cũng tương tự không yêu thương cầu phải ghi nhận lâp trình phần mềm.Việc kiểm thử được tiến hành nhờ vào việc kiểm demo TPPM có tác dụng được gì, có cân xứng với yêu mong của người tiêu dùng hay không. Những tester nhập số liệu vào phần mềm và chỉ cần xem công dụng của phần mềm và các phương châm kiểm tra.Mức demo này thường xuyên yêu cầu các tester nên viết test case rất đầy đủ trước khi test; khi test, đơn giản chỉ việc thực hiện theo các bước mô tả trong demo case thao tác làm việc và import dữ liệu vào, tiếp đến xem công dụng trả về hoặc hành vi của phần mềm, rồi đối chiếu với tác dụng mong đọi được viết trong testcase

1.1.5. Tạo test case và thực hiện test case

Khi viết thử nghiệm case: phụ thuộc vào yêu cầu và giao diện bên ngoài của chương trình (Không can thiệp vào bên phía trong code của chương trình)Khi triển khai test: triển khai trên đồ họa của chương trình (yêu mong chương trình đề nghị chạy được new test được, ko can thiệp vào code)

1.2. White BOX TEST

1.2.1. Định nghĩaKiểm thử vỏ hộp trắng (While box test) là phương pháp thử nghiệm phần mềm, trong các số đó các thiết kế, cấu trúc giải thuật bên trong, và việc tiến hành các công việc đều được biết đến

*

1.2.2. Đối tượng kiểm thửLà 1 nguyên tố của ứng dụng (1 chức năng, 1 module chức năng, 1 phân hệ chức năng....)

1.2.3. Phương thức thử nghiệm: nhờ vào thuật giảiKiểm thử hộp trắng phụ thuộc vào thuật giải thay thể, vào cấu tạo dữ liệu phía bên trong của ₫ơn vị ứng dụng cần kiểm thử ₫ể xác ₫ịnh ₫ơn vị ứng dụng ₫ó có tiến hành ₫úng không.

Với rất nhiều TPPM quá lớn sẽ tốn rất nhiều thời gian và sức lực lao động để kiểm thử ví như như dùng kiểm thử tích đúng theo (Integration test) xuất xắc kiểm thử công dụng (Functional test)).Kỹ thuật trắng box kiểm tra thích hợp dùng để làm kiểm thử đơn vị (Unit test)

1.2.4. Đặc điểm

Là chiến lược kiểm demo TPPM nhờ vào giải thuật, cấu trúc phía bên trong chức năng của TPPM tương ứng.Người kiểm thử yêu cầu có kiến thức nhất định về việc mã hoá, cấu trúc bên trong của chức năng, biết lâp trình phần mềm.Việc kiểm test được tiến hành nhờ vào việc kiểm xem giải thuật, mã lệnh đang làm bao gồm đúng không.Mức test này hay yêu cầu các tester buộc phải viết test case không thiếu các nhánh trong code; khi test, vẫn set điều kiện và data nhằm chạy vào đủ toàn bộ các nhánh trong giải thuật, đảm bảo thực hiện đầy đủ.

1.2.5. Sinh sản testcase và triển khai test

Khi viết kiểm tra case: phụ thuộc vào yêu cầu và nội dung Source Code (can thiệp vào phía bên trong Code của chương trình)Khi tiến hành test: xúc tiến test vào code (không cần xúc tiến chương trình, vì thực hiện test trắng box sẽ sử dụng framework làm sao đó hỗ trợ (Ví dụ như test kiểu debug)Trong khám nghiệm này, đòi hỏi người tester cần có kỹ năng và khả năng nhất định về ngôn ngữ lập trình được dùng, đọc thuật giải trong nguyên tố phần mềm, để có thể hiểu được chi tiết về đoạn code nên kiểm demo .

1.3. GRAY BOX TEST

Ngoài 2 kỹ thuật đã có nhắc đến: đen box kiểm tra và trắng box test, thì có một kỹ thuật, Gray box kiểm tra là sự kết hợp giữa đen box test và white box test.1.3.1. Định nghĩaGray Box Testing là một phương pháp kiểm thử phần mềm được phối hợp giữa phương thức Kiểm thử đen Box (hộp đen) với White Box (hộp trắng). Vào Kiểm thử hộp xám, cấu trúc bên phía trong sản phẩm chỉ được biết thêm một phần

*

1.3.2. Phương thức thử nghiệm: dựa vào giải thuật cùng chức năng

Gray box test rất có thể được sử dụng ở các mức kiểm thử khác nhau. Mặc dù nhiên, đa số được vận dụng trong Kiểm thử tích vừa lòng (Intergration test)

1.3.3. Sinh sản testcase và tiến hành test

Khi viết test case: phụ thuộc vào yêu mong và nội dung Source Code (can thiệp vào bên trong Code của chương trình)Khi thực hiện test: triển khai trên đồ họa của lịch trình (yêu cầu chương trình buộc phải chạy được bắt đầu test được, không can thiệp vào code)2. ƯU ĐIỂM, NHƯỢC ĐIỂM CỦA đen BOX demo VÀ white BOX TESTNội dungBlack box testWhite box test
1. Ưu điểm- phù hợp trong việc kiểm tra từng phân đoạn lớn các mã lệnh, chức năng lớn - tín đồ thử nghiệm không nên hiểu biết về mã lệnh được viết trong lịch trình - tách biệt giữa quan điểm của người tiêu dùng và người phát triển phần mềm- phù hợp trong việc tìm và đào bới kiếm lỗi và những vấn đề vào mã lệnh - biết được yêu cầu bên phía trong của phần mềm, kiểm tra sẽ giáp hơn - chất nhận được tìm kiếm các lỗi ẩn bên phía trong - các lập trình viên hoàn toàn có thể tự khám nghiệm - Giúp buổi tối ưu việc mã hoá - vì chưng yêu cầu kỹ năng cấu trúc bên trong của phần mềm, đề xuất việc kiểm soát điều hành lỗi về tối đa nhất
2. Nhược điểm- Độ bao che hạn chế bởi vì chỉ có một phần nhỏ trong những các kịch bản thử nghiệm được triển khai - kiểm tra không kết quả do bạn thử nghiệm không hiểu biết biết gì về cấu trúc phía bên trong phần mềm. - Tester có hạn chế về gọi biết về ứng dụng- thiết yếu tìm thấy tính năng chưa triển khai hoặc vứt bỏ - Đòi hỏi gọi sâu về cấu trúc phía bên trong của ứng dụng được phân tách - Yêu mong truy xuất mã lệnh bên trong chương trình
3. SỰ KHÁC NHAU GIỮA đen BOX thử nghiệm VÀ white BOX TESTTiêu chuẩnBlack box testWhite box test
1. Định nghĩa- khám nghiệm hộp đen là phương pháp thử nghiệm phần mềm được thực hiện để bình chọn các phần mềm mà không quan tâm đến cấu trúc bên trong của chương trình.- đánh giá hộp trắng là phương pháp kiểm test phần mềm, thực hiện để kiểm tra ứng dụng mà yêu thương cầu phải ghi nhận cấu trúc bên trong của chương trình.
2. Trách nhiệm- phân tách được triển khai bên ngoài, không tương quan đến nhà phát triển phần mềm.

Xem thêm: Cách Cài Giao Diện Android 10 Trên Mọi Điện Thoại Android Cực Chất

- Thông thường, các thử nghiệm được tiến hành bởi nhà phát triển phần mềm.
3. Lever test sử dụng- demo nghiệm áp dụng ở cấp độ cao như: kiểm tra hệ thống (System test), kiểm tra đồng ý (Acceptance test)- phân tích được áp dụng ở mức độ thấp hơn hoàn toàn như thử nghiệm đơn vị chức năng (Unit Test), phân tách hội nhập (Integration test)
4. Biết lập trình- không yêu mong hiểu biết về Lập trình- Yêu cầu hiểu biết nhất mực về lập trình.
5. Biết việc tiến hành chương trình- ko yêu mong hiểu về cấu trúc phía bên trong chức năng, với không cẩn hiểu làm chũm nào để sở hữu được tác dụng đó- Yêu cầu hiểu cấu trúc phía bên trong chức năng được tiến hành như nào.
6. đại lý tạo thử nghiệm Cases- khám nghiệm hộp đen được ban đầu dựa trên tư liệu yêu cầu kỹ thuật- soát sổ hộp trắng được bắt đầu dựa trên các tài liệu thiết kế chi tiết
4. SƠ LƯỢC VỀ CÁC KỸ THUẬT KIỂM TRA HỘP ĐEN

4.1. Các bước kiểm thử vỏ hộp đen

Với điểm sáng của Kiểm thử hộp black là chỉ dựa vào tác dụng của phần mềm, vì chưng đó quá trình kiểm demo qua quá trình chính như sau:

Phân tích đặc tả về những yêu cầu chức năng mà TPPM buộc phải thực hiệnDùng 1 chuyên môn đinh nghĩa các testcase xác định để định nghĩa các testcase, bao gồm 3 tin tức sau:+ giá bán trị tài liệu để TPPM cách xử trí (hoặc hợp lệ, hoặc không hợp lệ)+ tâm lý của TPPM cần có để thực hiện testcase+ giá chỉ trị tài liệu xuất mà lại TPPM phải lập đượcKiểm thử những testcase đang định nghĩaSo sánh tác dụng thu được với tác dụng kỳ vọng trong từ testcase, từ kia lập báo cáo về hiệu quả kiểm thử

4.2. Những kỹ thuật thông dụng trong kiểm thử vỏ hộp đen

Kỹ thuật phân lớp tương ₫ương (Equivalence Class Partitioning).Kỹ thuật phân tích các giá trị biên (Boundary value analysis).Kỹ thuật dùng các bảng quyết ₫ịnh (Decision Tables)Kỹ thuật kiểm thử các bộ n kỳ diệu (Pairwise)Kỹ thuật dùng bảng chuyển trạng thái (State Transition)Kỹ thật so sánh vùng miền (domain analysis)Kỹ thuật dựa trên ₫ặc tả Use Case (Use case)Kỹ thuật dùng lược ₫ồ quan hệ nam nữ nhân trái (Cause-Effect Diagram)Trong bài viết này tôi chỉ nêu qua loa về một số kỹ thuật kiểm test trên. Cụ thể sẽ được rõ ràng trong các bài viết sau

4.2.1. Chuyên môn phân lớp tương ₫ương

Ý tưởng của kỹ thuật này là nỗ lực phân những testcase ra thành những nhóm không giống nhau : những testcase trong những nhóm xác định TPPM thực hiện cùng 1 hành vi.Mỗi đội testcase thỏa mãn nhu cầu tiêu chuẩn chỉnh trên ₫ược gọi là 1 lớp tương ₫ương, ta chỉ cần xác ₫ịnh 1 testcase ₫ại diện cho nhóm và cần sử dụng testcase này ₫ể kiểm test TPPM.Như vậy ta ₫ã giảm rất nhiều testcase cần ₫ịnh nghĩa với kiểm thử, nhưng chất lượng kiểm thử không bị giảm sút từng nào so cùng với vét cạn.Điều này là phụ thuộc kỳ vọng:-ƒ nếu 1 testcase vào lớp tương ₫ương làm sao ₫ó khiến lỗi TPPM thì các testcase trong lớp này cũng trở thành gây lỗi như vậy.

Nếu 1 testcase trong lớp tương ₫ương nào ₫ó không khiến lỗi TPPM thì những testcase trong lớp này cũng biến thành không gây lỗi.Với những giá trị không phù hợp lệ: Ta phải tạo 1 lớp tương đương đại diện các testcase chứa các giá trị không phù hợp lệ theo sệt tả giúp xem TPPM phản nghịch ứng như làm sao với các trường thích hợp này

4.2.2. Kỹ thuật phân tích các giá trị ngơi nghỉ biên

Khi chế tạo ra testcase, ta chỉ cần sử dụng Kỹ thuật phân lớp tương tự thì hẳn là chưa đủ.Kinh nghiệm cho biết thêm rằng lỗi thường nằm ở vị trí biên (₫ầu tuyệt cuối) của 1 khoảng thường xuyên nào ₫ó (lớp tương ₫ương). Vì chưng ₫ó cùng với Kỹ thuật đối chiếu giá trị chỉnh sửa trung tạo những testcase ứng với hồ hết giá trị ở biên này. Nên thông thường là gồm sự phối kết hợp cả 2 kỹ thuật: Phân lớp tương đương và Phân tích giá trị biên nhằm viết những testcase.Ý tưởng của chuyên môn là chỉ ₫ịnh nghĩa các testcase ứng với những giá trị tức thì trên biên hay lân cận biên của từng lớp tương ₫ương.Do ₫ó chuyên môn này chỉ thích hợp với các lớp tương ₫ương xác ₫ịnh bởi những giá trị tiếp tục (số nguyên, số thực), chứ nó ko thích hợp với lớp tương ₫ương ₫ược xác ₫ịnh bởi những giá trị liệt kê mà không tồn tại mối quan hệ giới tính lẫn nhau.Quy trình ví dụ ₫ể triển khai kiểm demo dựa trên các giá trị ngơi nghỉ biên:-ƒ dấn dạng các lớp tương ₫ương dựa trên ₫ặc tả về yêu thương cầu tính năng của TPPM.

Nhận dạng 2 biên của từng lớp tương ₫ương.Tạo những testcase cho từng biên của mỗi lớp tương ₫ương :1 testcase tại cực hiếm biên.1 testcase ngay bên dưới biên.1 testcase ngay lập tức trên biên.Ý nghĩa ngay lập tức trên cùng ngay bên dưới biên dựa vào vào ₫ơn vị ₫o lường ví dụ : Số nguyên , số thập phân...

4.2.3. Kỹ thuật cần sử dụng bảng quyết ₫ịnh (decision table)

Bảng quyết ₫ịnh là một trong những công vậy rất hữu dụng ₫ể ₫ặc tả những yêu cầu ứng dụng hoặc ₫ể ₫ặc tả bảng thiết kế khối hệ thống phần mềm. Nó mô tả các qui tắc nghiệp vụ phức tạp mà phần mềm phải thực hiện dưới dạng dễ dàng ₫ọc và dễ kiểm soát và điều hành :

Rule 1Rule 2...Rule p
Conditions
Conditions-1
...
Conditions-m
Actions
Actions-1
...
Actions-n

Trong đó:

Condition-1 tới Condition-m mô tả m ₫iều kiện tài liệu nhập không giống nhau rất có thể có.Action-1 cho tới Action-n biểu đạt n hoạt ₫ộng khác biệt mà hệ thống hoàn toàn có thể thực hiện nhờ vào vào tổng hợp ₫iều kiện tài liệu nhập nào.Mỗi cột mô tả 1 luật rõ ràng : tổng hợp ₫iều kiện nhập cụ thể và những hoạt ₫ộng rõ ràng cần thực hiện.Lưu ý những hoạt ₫ộng cần triển khai không phụ thuộc vào vào máy tự các ₫iều kiện nhập, nó chỉ nhờ vào vào giá bán trị những ₫iều kiện nhập.Tương tự, các hoạt ₫ộng cần thực hiện không phụ thuộc vào vào trạng thái hiện hành của TPPM, chúng cũng không phụ thuộc vào vào các ₫iều khiếu nại nhập ₫ã có trước ₫ó.