답변.

질문 역사:

소프트웨어 대량 출시가 발전하면서 내부 구현에 접근하지 않고도 제품의 기능성을 빠르고 품질적으로 검증할 필요성이 생겼습니다. 그래서 테스트 담당자가 애플리케이션의 공개 인터페이스와만 작업하는 블랙 박스 방법이 등장했습니다.

문제:

코드를 이해하지 못하면 내부 오류를 놓치거나 특정 실행 경로를 테스트하지 못할 수 있습니다. 그럼에도 불구하고 블랙 박스는 사용자 관점에서 테스트를 가능하게 하여 사용자 관점의 문제를 식별할 수 있습니다.

해결책:

블랙 박스 방법은 다음을 포함합니다:

• 테스터는 사양에 따라 인터페이스 요소와 프로그램의 동작을 평가합니다.
• 코드나 시스템의 구조에 대한 지식이 필요하지 않습니다.
• 입력 데이터와 출력 결과를 확인하며, 이들 사이의 계산 과정은 확인하지 않습니다.

주요 특징:

• 최종 사용자 관점에서 독립적인 평가를 제공합니다.
• 시스템의 외부 행동만 커버합니다.
• 구현의 내부 오류를 확인할 수 없습니다.

트릭 질문들.

블랙 박스 테스트를 위해 프로그래밍 지식이 필요한가요?

아니요, 이 방법을 적용하기 위해 코드를 알 필요는 없으며, 주요한 것은 기능 요구 사항을 이해하는 것입니다.

블랙 박스 방법이 모든 오류를 완벽하게 커버하는가요?

아니요, 모든 오류를 외부 인터페이스를 통해 발견할 수 없으므로 일부 결함은 내부 로직에 접근하지 않으면 숨겨져 있습니다.

복잡한 기업 서비스 테스트에만 블랙 박스를 적용할 수 있나요?

아니요, 최대한의 커버리지를 달성하기 위해 다른 방법(화이트 박스 등)과 결합하는 것이 바람직합니다.

일반적인 오류 및 안티 패턴

• API를 확인하지 않고 UI만 테스트하기
• 문서(사양)를 완전히 무시하기
• 창의적인 부정적 시나리오의 결여

실제 사례

부정적인 케이스

테스터는 블랙 박스만으로 은행 애플리케이션을 테스트하며 UI를 통해 표준 데이터를 입력하고 내부 잔액(테스트되지 않은 API)에 대한 작업에는 주의를 기울이지 않았습니다.

장점:

• 사용자 시나리오에 따른 빠른 테스트

단점:

• 운영을 반복했을 때 내부 버그로 인해 초과 자금이 차감되는 사실이 발견되었습니다 (UI에서 명시적으로 나타나지 않은 내부 버그).

긍정적인 케이스

테스터는 블랙 박스 테스트로 사용자 시나리오를 설명한 후, 개발자와 함께 API와 데이터베이스의 데이터도 검토하는 테스트를 결합했습니다.

장점:

• 사용자 오류뿐만 아니라 은행 거래와 관련된 비즈니스 로직의 중요한 오류도 발견되었습니다.

단점:

• 다른 전문가들과의 협업을 조율하고 API 구조를 학습하기 위해 추가 시간이 필요했습니다.