key differences between black box testing
블랙 박스 테스트와 화이트 박스 테스트의 철저한 연구 :
소프트웨어 테스트에는 여러 유형의 테스트가 포함되며 소프트웨어 테스터로서 각각의 테스트가 어떻게 수행되는지 알아야합니다.
다양한 유형의 테스트 중에서 가장 혼란스러운 주제 중 하나는 블랙 박스 대 화이트 박스 테스트입니다. 많은 소프트웨어 테스터가이 두 가지 유형의 테스트간에 유사점이 있는지 궁금합니다. 둘 다 어떻게 수행됩니까? 둘 다 함께 공연합니까?
이 문서는 모든 질문에 답하고 블랙 박스 테스트와 화이트 박스 테스트가 무엇인지에 대한 기본 아이디어를 제공하고 그 차이점을 간단한 용어로 설명합니다. .
학습 내용 :
블랙 박스 테스트 란?
ISTQB 정의 – 블랙 박스 테스트 : 내부 구조를 참조하지 않고 AUT (Application Under Test)를 테스트하는 것을 블랙 박스 테스트라고합니다. 테스트는 애플리케이션을 블랙 박스로 시각화하여 수행됩니다.
블랙 박스 테스트 기술 : 시스템의 내부 구조를 고려하지 않고 애플리케이션의 기능을 기반으로 테스트 케이스를 도출하는 테스트 기술입니다.
동의어 : 사양 기반 테스트
블랙 박스 테스트는 테스트중인 애플리케이션을 구현하는 데 사용되는 기술에 대한 지식없이 사양 / SRS를 기반으로 AUT의 기능을 테스트하는 데 사용되는 테스트 접근 방식입니다.
블랙 박스 테스트에서 주요 테스트는 가능한 입력 및 예상 출력에 대한 것입니다. 테스터는 유효한 테스트 데이터를 신중하게 선택할 수 있어야합니다. 간단히 말해서 테스터는 AUT의 동작 만 볼 수 있습니다. 테스터는 이러한 작업이 어떻게 수행되는지 알 필요가 없습니다.
예: 블랙 박스 테스트의 간단한 예는 TV (텔레비전)입니다. 사용자로서 우리는 TV를 시청하지만 TV가 어떻게 구성되고 작동하는지 등에 대한 지식이 필요하지 않습니다. 리모컨을 작동하여 켜고 끄고 채널을 변경하는 방법 만 알면됩니다. 볼륨 증가 / 감소 등
이 예에서
그만큼 TV 너의 AUT (Application Under Test).
그만큼 리모콘 테스트에 사용하는 UI (사용자 인터페이스)입니다.
응용 프로그램을 사용하는 방법 만 알면됩니다.
추천 읽기 => 블랙 박스 테스트에 대해 알아야 할 모든 것
화이트 박스 테스트 란?
ISTQB 정의 – 화이트 박스 테스트 : 소프트웨어 구성 요소의 내부 구조를 참조하여 응용 프로그램을 테스트하는 것을 화이트 박스 테스트라고합니다.
화이트 박스 테스트 기술 : 구성 요소 또는 시스템의 내부 구조 분석을 기반으로 테스트 케이스를 도출 및 / 또는 선택하는 절차입니다.
동의어 : Clear-box 테스트, 코드 기반 테스트, Glass-box 테스트, 로직 커버리지 테스트, 로직 기반 테스트, 구조 테스트, 구조 기반 테스트 등
화이트 박스 테스트는 테스트중인 애플리케이션의 구현 부분을 테스트하는 데 사용되는 테스트 접근 방식입니다. 이 테스트를 수행하려면 테스터 / 아마도 개발자는 애플리케이션의 내부 구조와 작동 방식을 알아야합니다.
예: 자동차 정비사는 수리를 위해 자동차 엔진의 내부 구조를 알아야합니다.
이 예에서
차 이다 AUT (Application Under Test).
그만큼 사용자 이다 블랙 박스 테스터.
그만큼 정비공 이다 흰색 상자 테스터.
이것은 화이트 박스와 블랙 박스 테스트의 기본 정의이며 각 테스트 방법에는 따라야 할 다른 기술이 있습니다.
추천 읽기 => 화이트 박스 테스트에 대한 심층 자습서
블랙 박스와 화이트 박스 테스트의 차이점
| S. 아니 | 블랙 박스 테스트 | 화이트 박스 테스트 |
|---|---|---|
| 7 | 테스트 케이스에는 입력 조건, 테스트 단계, 예상 결과 및 테스트 데이터에 대한 자세한 내용이 포함됩니다. | 테스트 케이스는 문장, 코드 커버리지 등과 같은 기술적 개념의 세부 사항으로 간단합니다. |
| 1 | 이 테스트의 주요 목적은 애플리케이션의 기능 / 동작을 테스트하는 것입니다. | 주요 목표는 애플리케이션의 인프라를 테스트하는 것입니다. |
| 두 | 이는 AUT (Application Under Test)에 대한 코딩 지식없이 테스터가 수행 할 수 있습니다. | 테스터는 내부 구조 및 작동 방식에 대한 지식이 있어야합니다. |
| 삼 | GUI를 사용해서 만 테스트를 수행 할 수 있습니다. | GUI가 준비되기 전에 초기 단계에서 테스트를 수행 할 수 있습니다. |
| 4 | 이 테스트는 가능한 모든 입력을 다룰 수는 없습니다. | 이 테스트는 각 경로를 테스트 할 수 있으므로 더 철저합니다. |
| 5 | 일부 테스트 기술에는 경계 값 분석, 등가 분할, 오류 추측 등이 포함됩니다. | 일부 테스트 기술에는 조건부 테스트, 데이터 흐름 테스트, 루프 테스트 등이 포함됩니다. |
| 6 | 테스트 케이스는 요구 사항 사양에 따라 작성되어야합니다. | 테스트 케이스는 세부 설계 문서를 기반으로 작성되어야합니다. |
| 8 | 이것은 전문 소프트웨어 테스터가 수행합니다. | 이것은 소프트웨어 개발자의 책임입니다. |
| 9 | 프로그래밍 및 구현 지식이 필요하지 않습니다. | 프로그래밍 및 구현 지식이 필요합니다. |
| 10 | 주로 수락 테스트, 시스템 테스트 등과 같은 높은 수준의 테스트에 사용됩니다. | 주로 단위 테스트 및 통합 테스트와 같은 낮은 수준의 테스트에 사용됩니다. |
| 열한 | 이것은 시간 소모가 적고 철저합니다. | 이것은 더 많은 시간이 소요되고 철저합니다. |
| 12 | 테스트 데이터는 다양한 가능성을 가지고 있으므로 정확한 데이터를 식별하기가 어려울 것입니다. | 기능의 특정 부분 만 한 번에 집중되므로 테스트 데이터를 쉽게 식별 할 수 있습니다. |
| 13 | 테스터의 주요 초점은 애플리케이션 작동 방식입니다. | 주요 초점은 애플리케이션 구축 방법입니다. |
| 14 | 모든 시나리오에 대한 테스트 데이터를 생성 할 수 없기 때문에 테스트 범위가 적습니다. | 부분적으로 테스트하기 쉽기 때문에 거의 모든 경로 / 애플리케이션 흐름이 포함됩니다. |
| 열 다섯 | 코드 관련 오류를 식별 할 수 없거나 기술 오류를 식별 할 수 없습니다. | 숨겨진 오류를 식별하고 코드를 최적화하는 데 도움이됩니다. |
| 16 | 기본 코드가 개발되면 결함이 식별됩니다. | 조기 결함 감지가 가능합니다. |
| 17 | 이 테스트의 범위가 넓기 때문에 사용자는 누락 된 기능을 식별 할 수 있어야합니다. | 범위가 구현 된 기능으로 만 제한되므로 테스터는 누락 된 기능을 식별 할 수 없습니다. |
| 18 | 코드 액세스가 필요하지 않습니다. | 코드 액세스가 필요합니다. |
| 19 | 테스터가 기술적 측면에 대한 지식이 제한되어 있기 때문에 테스트 범위가 줄어들 것입니다. | 테스터가 기술 개념에 대해 더 많은 지식을 갖기 때문에 테스트 범위는 더 커질 것입니다. |
| 이십 | 전문 테스터는 전체 애플리케이션이 작동하는 방식에 중점을 둡니다. | 테스터 / 개발자 초점은 특정 경로가 작동하는지 여부를 확인하는 것입니다. |
결론
성공적인 소프트웨어 제공을 위해서는 화이트 박스 및 블랙 박스 테스트가 필요하지만 두 경우 모두 100 % 테스트는 불가능합니다.
테스터의 주요 책임은 최대 결함을 찾아 애플리케이션의 효율성을 향상시키는 특정 애플리케이션에 대한 관련 테스트 유형 및 기술을 식별하는 것입니다.
테스터는 애플리케이션이 예상대로 작동하는지 확인하기 위해 블랙 박스 또는 화이트 박스 테스트에서 수행 할 수있는 테스트의 양을 식별 할 수 있어야합니다.
이 튜토리얼이 블랙 박스 대 화이트 박스 테스트에 대한 모든 질문을 명확히했기를 바랍니다 !!
문자를 int C ++로