Black-Box Testing

Scenario Testing vs. Use Case Testing Scenario Testing과 Use Case Testing은 소프트웨어 테스팅 기법으로, 사용자 관점에서 시스템의 기능과 동작을 검증하는 데 사용된다. 두 기법은 유사한 점이 있지만, 접근 방식과 세부 사항에서 차이가 있다. 비교 항목 Scenario Testing Use Case Testing 정의 실제 사용자의 행동과 상황을 기반으로 한 현실적인 시나리오를 통해 시스템을 테스트하는 방법 사용자와 시스템 간의 상호작용을 구조화된 형식으로 정의하고 테스트하는 방법 테스트 관점 사용자 중심적이며, 실제 업무 상황과 맥락을 중요시함 시스템 중심적이며, 기능적 정확성과 완전성을 중요시함 목적 실제 사용 환경에서의 시스템 동작을 검증 시스템의 기능적 요구사항을 검증 구조화 정도 자유로운 형식으로, 스토리텔링 방식의 서술적 구조 체계적이고 형식적인 구조 (기본 흐름, 대체 흐름, 예외 흐름) 테스트 범위 여러 기능이나 프로세스를 걸쳐 있는 end-to-end 시나리오 주로 단일 기능이나 프로세스에 초점 테스트 설계 자유로운 형식으로 다양한 “가정” 상황을 포함 유스케이스 문서의 기본 흐름과 대체 흐름을 따름 테스트 케이스 도출 다양한 소스(사용자 피드백, 시장 조사 등)에서 시나리오 개발 유스케이스 문서에서 직접 테스트 케이스를 도출 상황 맥락 사용자의 동기, 감정, 환경 등 풍부한 맥락 정보 포함 객관적이고 기술적인 상호작용 위주의 맥락 문서화 방식 서술적이고 이야기 형식의 문서화 구조화되고 단계별로 정형화된 문서화 적합한 상황 사용자 경험이 중요한 애플리케이션, 복잡한 업무 프로세스 명확한 기능 요구사항이 있는 시스템, 트랜잭션 기반 애플리케이션 테스트 설계 난이도 실제 사용자 경험에 대한 이해가 필요하며, 창의적인 시나리오 도출이 중요 체계적인 분석과 문서화 능력이 필요하며, 기술적 이해가 중요 유지보수성 시나리오 수정이 비교적 자유롭고 유연함 구조화된 형식으로 인해 변경 관리가 체계적 재사용성 특정 상황에 특화된 시나리오로 재사용이 제한적 표준화된 형식으로 인해 재사용이 용이 커버리지 측정 시나리오 기반의 정성적 측정이 주로 이루어짐 흐름 기반의 정량적 측정이 가능 테스트 자동화 복잡한 시나리오로 인해 자동화가 어려울 수 있음 구조화된 형식으로 인해 자동화가 비교적 용이 장점 예상치 못한 오류 발견에 효과적, 사용자 경험 개선에 도움 요구사항 검증에 효과적, 체계적인 테스트 가능 단점 모든 가능한 시나리오를 고려하기 어려움 유스케이스 문서의 품질에 의존적 실제 프로젝트에서는 이 두 방법을 상호 보완적으로 사용하는 것이 효과적이다. 예를 들어, Use Case Testing으로 기본적인 기능 정확성을 검증하고, Scenario Testing으로 실제 사용 환경에서의 사용성과 통합성을 검증하는 방식으로 활용할 수 있다. ...

유즈케이스 테스팅 (Use Case Testing)) 유즈케이스 테스팅은 유즈케이스나 비즈니스 시나리오를 기반으로 테스트를 명세화하는 블랙박스 테스트 설계 기법이다. 이 방법은 액터와 시스템 간의 상호작용을 표현하고, 그 결과를 사용자에게 전달하는 과정을 테스트한다. 실제 예시를 통해 구체적으로 살펴보자. 온라인 쇼핑몰의 상품 주문 기능에 대한 유즈케이스 테스팅을 설계한다고 가정해보면: 기본 흐름(Basic Flow): 사용자가 상품을 장바구니에 추가한다 시스템이 장바구니 내용을 표시한다 사용자가 주문하기 버튼을 클릭한다 시스템이 배송 정보 입력 폼을 표시한다 사용자가 배송 정보를 입력한다 시스템이 결제 수단 선택 화면을 표시한다 사용자가 결제 수단을 선택하고 결제한다 시스템이 주문 완료 화면을 표시한다 대체 흐름(Alternative Flows): ...

요구사항 기반 테스팅 (Requirements-based Testing) 요구사항 기반 테스팅은 소프트웨어 요구사항 명세서(SRS)에 명시된 기능적, 비기능적 요구사항을 검증하는 테스트 기법이다. 이 방법은 개발된 소프트웨어가 사용자와 개발 조직 간의 공식 합의에 따른 기능을 정확히 수행하는지 확인하는 것을 목표로 한다. 실제 예시를 통해 더 구체적으로 살펴보자. 온라인 쇼핑몰의 로그인 기능에 대한 요구사항이 있다고 가정해보자: "사용자는 이메일과 비밀번호로 로그인할 수 있어야 한다. 이메일은 올바른 형식이어야 하며, 비밀번호는 최소 8자 이상이어야 한다. 로그인 실패 시 적절한 오류 메시지를 표시해야 한다." ...

메타모픽 테스팅 (Metamorphic Testing, MT) 소프트웨어 테스트에서 “오라클 문제”(테스트 결과의 정확성을 판단하기 어려운 상황)를 해결하기 위해 개발된 방법으로, 메타모픽 테스팅은 소프트웨어의 의도된 기능에 대한 필수적인 속성인 메타모픽 관계(Metamorphic Relations, MRs)를 활용하여 테스트를 수행한다. 이 방법은 정확한 출력값을 알지 못해도 테스트가 가능하다는 점에서 특징적이다. 메타모픽 테스팅의 핵심 원리는 입력값들 사이의 관계와 그에 따른 출력값들 사이의 관계를 활용하는 것이다. 예를 들어, 어떤 숫자에 2를 곱한 값과 원래 숫자의 제곱을 비교한다고 생각해보자. 입력값이 3일 때, 3 × 2 = 6이고 3² = 9이다. 여기서 우리는 “어떤 숫자에 2를 곱한 값은 항상 그 숫자의 제곱보다 작다"라는 메타모픽 관계를 발견할 수 있다. ...

경계값 분석 (Boundary Value Analysis, BVA) 경계값 분석은 입력 또는 출력 범위의 경계 근처에서 결함이 발생할 가능성이 높다는 경험적 관찰에 기반한 테스트 기법. 프로그래머들이 흔히 “off-by-one” 오류를 범하거나 경계 조건을 잘못 처리하는 경향이 있기 때문에, 이러한 경계값을 집중적으로 테스트하는 것이 효과적이다. 예를 들어, 어떤 시스템이 1에서 100 사이의 숫자만 받아들인다고 가정해보자. 이때 0, 1, 2와 99, 100, 101 같은 경계값들을 테스트하는 것이 중요하다. 왜냐하면 이러한 값들에서 시스템이 올바르게 작동하지 않을 가능성이 높기 때문이다. ...

원인-결과 그래프 검사(Cause-Effect Graph Testing) 원인-결과 그래프 검사(Cause-Effect Graph Testing)는 블랙박스 테스트 기법 중 하나로, 입력 조건(원인)과 출력 결과(결과) 사이의 관계를 체계적으로 분석하고 모델링하여 효과적인 테스트 케이스를 도출하는 방법. 원인-결과 그래프 검사는 입력 데이터 간의 관계와 출력에 미치는 영향을 그래프로 표현하여 분석하는 기법. 이 방법은 여러 입력 조건을 결합해서 하나 이상의 결과를 얻는 것으로, 복잡한 입력 환경을 고려할 수 있는 장점이 있다. 원인-결과 그래프 검사의 목적 복잡한 입력 값들 간의 관계를 체계적으로 분석 입력 조건에 따른 출력의 적절성 확인 효율성이 높은 테스트 케이스 선정 원인-결과 그래프 검사의 절차 원인과 결과 식별: 요구사항 명세서, 설계서, 프로그램에서 원인(입력 조건)과 결과(출력 조건)를 찾아 식별한다. 그래프 작성: 원인과 결과를 연결하는 boolean 그래프를 작성한다. 이 그래프는 AND, OR, NOT 같은 boolean 연산자를 사용하여 원인과 결과 간의 논리적 관계를 표현한다. 제약 조건 표시: 불가능한 원인 조합 또는 결과 조합을 나타내는 제약(constraints)을 그래프에 표시한다. 의사결정 테이블 작성: 원인-결과 그래프를 의사결정 테이블(decision table)로 변환한다. 테스트 케이스 도출: 의사결정 테이블의 각 열을 테스트 케이스로 변환한다. 그래프의 구성 요소 원인-결과 그래프는 다음과 같은 기본 요소들로 구성된다: ...

결정 테이블 테스팅 (Decision Table Testing) 결정 테이블 테스팅은 복잡한 비즈니스 로직이나 시스템의 동작을 테스트하기 위한 체계적인 방법. 여러 조건(conditions)과 그에 따른 행동(actions)의 모든 가능한 조합을 표 형태로 정리하여 테스트 케이스를 도출하는 기법. 예를 들어, 온라인 쇼핑몰의 할인 정책을 테스트한다고 생각해보자. 회원 등급(일반/VIP), 구매 금액(5만원 이상/미만), 프로모션 코드 사용 여부에 따라 다른 할인율이 적용된다면, 이러한 여러 조건의 조합을 결정 테이블로 정리하여 체계적으로 테스트할 수 있다. 결정 테이블의 구성 요소 결정 테이블은 네 가지 주요 부분으로 구성된다: ...

상태 전이 테스팅(State Transition Testing) 상태 전이 테스트는 시스템이나 객체의 상태 변화를 모델링하고, 이벤트에 따른 상태 전이와 그 결과를 검증하는 기법이다. 이 방법은 시스템의 현재 상황(Conditions)과 이전 이력(History)을 반영하는 상태(States) 및 그 변화(Transition)에 따라 시스템이 어떻게 동작하는지를 테스트한다. 상태 전이 테스트의 목적 시스템의 모든 가능한 상태와 전이를 식별하고 테스트 유효한 상태 전이뿐만 아니라 유효하지 않은 전이도 테스트 상태 변화에 따른 시스템의 반응과 출력을 검증 상태 전이 테스트의 주요 구성 요소 시스템의 상태 전이를 테스트하기 위해서는 다음 요소들을 이해하고 정의해야 한다: ...

분류 트리 방법 (Classification Tree Method, CTM) CTM은 1993년 Grimm과 Grochtmann에 의해 개발된 테스트 설계 방법으로, 소프트웨어의 테스트 관련 측면을 체계적으로 분류하고 조합하여 테스트 케이스를 생성한다. 분류 트리 방법은 테스트 대상 시스템의 입력 도메인을 여러 분류(Classifications)로 나누고, 각 분류 아래에 클래스(Classes)들을 정의하는 방식으로 작동한다. 여기서 분류는 테스트할 특성이나 매개변수를 의미하고, 클래스는 그 특성이 가질 수 있는 구체적인 값들을 의미한다. 예를 들어, 온라인 쇼핑몰의 주문 시스템을 테스트한다고 가정해보자: 분류: 결제 방법 ...

동등 분할(Equivalence Partitioning) 동등 분할은 입력 또는 출력 데이터를 의미 있는 그룹으로 나누어 테스트하는 기법. 이 방법의 핵심 아이디어는 같은 그룹에 속한 데이터는 프로그램에서 동일한 방식으로 처리될 것이라는 가정에 기반한다. 따라서 각 그룹에서 대표값만 테스트함으로써 효율적으로 테스트를 수행할 수 있다. 예를 들어, 학생의 시험 점수(0-100점)를 등급(A, B, C, D, F)으로 변환하는 프로그램을 생각해보자. 이 경우 점수 범위를 다음과 같이 분할할 수 있다: 유효 분할: 90-100점: A등급 80-89점: B등급 70-79점: C등급 60-69점: D등급 0-59점: F등급 무효 분할: ...