반응형
테스트에는 다양한 테스트 종류가 있으며, 각각은 특정 목적과 범위에서 따라서 선택 및 수행되고 소프트웨어를 평가합니다.
종합적으로 모든 종류의 테스트를 조합하여 소프트웨어의 품질을 유지하고 개선하는 것이 일반적인 개발 방법입니다.
테스트 기초 용어
테스트 스위트(Test Suite)
: 여러 테스트 케이스를 하나로 묶어서 실행하거나 구성하는 도구
- 여러 테스트를 그룹화하여 함께 실행하거나, 특정 기능 또는 모듈에 대한 모든 테스트를 한 번에 실행하는 데 사용됩니다.
- 여러 테스트 케이스를 그룹화하고 관리한다.
- 주로 테스트 프레임워크에서 지원되며, 큰 프로젝트에서 여러 모듈 또는 기능에 걸친 테스트를 효과적으로 관리할 수 있도록 도와줍니다.
테스트 케이스(Test Case)
: 특정 입력 상태에서 특정 기능 또는 코드 조각의 동작을 검증하기 위한 테스트 단위
- 각 테스트 케이스는 일반적으로 특정 조건에서 예상 결과와 실제 결과를 비교하는 테스트를 포함합니다.
테스트 대역 (테스트 더블, Test Double)
: 실제 의존성을 대체하여 테스트를 더 효과적으로 수행하기 위한 객체
- 특정 상황에서 테스트를 단순화하거나, 외부 의존성을 제어하거나, 특정 동작을 확인하기 위해 사용됩니다.
- 특히 외부 서비스와의 통합이나 특정 환경에서 테스트하기 어려운 경우에 유용
- 대표적인 테스트 더블 유형 : 테스트 스텁(Test Stub), 테스트 스파이(Test Spy), 테스트 모의 객체(Mock Object), 페이크(Fake) 등이 있다.
- 테스트 스텁 (Test Stub)
- : 실제로 동작하는 객체를 대신하여 호출되면 미리 정의된 결과를 반환하는 특수한 테스트 더블(Test Double)
- 주로 외부 서비스 호출 또는 리소스에 대한 가짜 구현을 만들 때 사용됩니다.
- 테스트 스파이 (Test Spy)
- : 테스트 중에 객체의 상태나 동작을 기록하는 데 사용되는 테스트 더블(Test Double)
- 호출된 메서드나 함수의 정보를 기록하여 나중에 테스트에서 확인하는 데 유용합니다.
- 테스트 모의 객체 (Mock Object)
- : 특정 동작을 모방하여 특정 조건에서 어떻게 동작하는지를 검증하기 위한 테스트 더블(Test Double)
- 주로 인터페이스를 구현하여 특정 메서드 호출이 예상대로 이루어지는지를 확인하는 데 사용됩니다.
- 사람들이 흔히 '테스트 대역'과 '목'을 동의어로 사용하지만, 기술적으로는 그렇지 않다.
- 테스트 대역 => 실행과 관련없는 모든 종류의 가짜 의존성을 설명하는 포괄적인 용어
- 목 => '테스트 대역' 의존성의 한 종류
- 페이크(Fake)
- : 실제로 동작하는 객체를 대신하여 가벼운 구현을 제공하는 테스트 더블(Test Double)
- ex) 메모리 내의 데이터베이스 대신 간단한 데이터 저장소를 사용하는 것 등
테스트 대상 시스템(SUT, System Under Test)
- : 용어 그대로 테스트 대상인 시스템
- 일반적으로 클래스 전체를 가리킴
vs
테스트 대상 메서드(MUT, Method Under Test)
- : 테스트에서 호출한 SUT의 메서드
- 일반적으로 메서드를 가리킴
=> MUT와 SUT는 흔히 동의어로 사용하지만, 일반적으로는 MUT는 메서드를 가리키는 데 반해 SUT는 클래스 전체를 가리킨다.
테스트종류
임의로 테스트를 두 종류로 나누어 보면 동작이나 기능을 검증하는 테스트, 사용자 경험을 모방하거나 시뮬레이션하는 테스트로 보인다.
1. 동작이나 기능을 검증하는 테스트
단위 테스트(Unit Test)
- 실행가능한 소프트웨어의 최소 단위인 함수, 메서드, 또는 모듈과 같은 코드 조각을 개별적으로 검증하는 테스트
- 목적 : 코드의 작은 부분이 의도대로 동작하는지 확인하고, 변경이나 추가된 코드가 기존 기능에 영향을 주지 않도록 하는 것
통합 테스트(Integration Test)
- 여러 개별 컴포넌트가 함께 동작할 때 예상대로 상호작용하는지를 평가하는 테스트
- cf) Unit test와 달리 개발자가 변경할 수 없는 부분 (ex. 외부 라이브러리, db)까지 묶어서 검증할 때 사용된다.
- 컴포넌트 간의 인터페이스 및 상호작용을 검증하여 시스템 전체의 통합된 기능을 평가합니다.
시스템 테스트(System Test)
- 완전한 소프트웨어 시스템의 기능, 성능, 안정성, 보안 등을 평가하는 테스트
- 모든 컴포넌트 및 시스템의 상호작용을 검증하며, 사용자 시나리오를 시뮬레이션하여 전체 시스템이 예상대로 동작하는지 확인합니다.
인수 테스트(Acceptance Test)
- 소프트웨어가 최종 사용자 또는 고객의 요구 사항을 충족하는지 검증하는 테스트
- 사용자 시나리오에 기반하여 시스템이 예상대로 동작하는지 확인하며, 종종 사용자가 직접 수행하는 테스트를 포함합니다.
회귀 테스트(Regression Test):
- 코드 변경, 버그 수정 또는 새로운 기능 추가 후에 기존 기능이 여전히 정상적으로 동작하는지를 검증하는 테스트
- 코드 변경으로 인해 기존 기능에 문제가 발생하지 않도록 하는 것이 목적
스트레스 테스트(Stress Test)
- 시스템이 특정 조건에서 어떻게 동작하는지 확인하는 테스트
- 대량의 데이터나 동시 사용자의 증가 등을 시뮬레이션하여 시스템의 성능 한계를 확인합니다.
2. 사용자 경험을 모방하거나 시뮬레이션하는 테스트
엔드투엔드(E2E) 테스트(End-to-End Test)
- 소프트웨어 시스템 전체를 실제 사용자 환경에서 실행하여 테스트하는 것
- 소프트웨어의 내부 구조 보다는 비즈니스 쪽에 초점을 두어 실제 시나리오대로 잘 동작하는지 테스트
- 시스템의 모든 컴포넌트 및 서비스를 포함하며, 사용자의 시점에서 애플리케이션이 어떻게 동작하는지를 확인합니다.
- 통합된 시스템의 동작을 검증하며, 주로 사용자 플로우를 완전히 시뮬레이션하여 시스템이 예상대로 상호작용하는지를 테스트합니다.
시나리오 테스트(Scenario Test)
- 사용자의 실제 사용 시나리오를 기반으로 소프트웨어를 테스트하는 것
- 특정 사용자 또는 사용자 그룹이 시스템을 어떻게 사용할지를 시뮬레이션하며, 다양한 상황에서 시스템이 예상대로 반응하는지 확인합니다.
- 주로 사용자 행동을 다양한 시나리오로 모델링하고, 각 시나리오에 대한 예상 결과를 검증합니다.
인수 테스트(Acceptance Test)
- 소프트웨어가 최종 사용자 또는 고객의 요구 사항을 충족하는지 검증하는 테스트
- 사용자 시나리오에 기반하여 시스템이 예상대로 동작하는지 확인하며, 종종 사용자가 직접 수행하는 테스트를 포함합니다.
- 앞서 설명한 엔드투엔드 테스트와 시나리오 테스트는 종종 인수 테스트의 일부로 간주될 수 있습니다.
- 일반적으로 사용자의 요구 사항을 기반으로 특정 기능이나 시나리오에 대한 테스트를 수행하며, 전체 소프트웨어 제품이 사용자에게 받아들여질 수 있는지를 평가합니다.
셋이 너무 헷갈려서 비교하자면,
엔드투엔드(E2E) 테스트(End-to-End Test) |
시나리오 테스트(Scenario Test) |
인수 테스트(Acceptance Test) |
|
| 목적 | 특정 사용자 시나리오와 플로우대로 시스템이 예상대로 동작하는지 확인 | 시스템 전체를 테스트하여 사용자의 시점에서 시스템이 예상대로 동작하는지 확인 | 최종 사용자의 요구 사항을 충족하는지를 확인 |
| 범위 | 특정 시나리오나 플로우 중점으로 함 | 전체 시스템을 대상으로 한 사용자의 경험을 시뮬레이션 | 사용자의 요구 사항을 기반으로 한 특정 기능이나 시나리오(이므로 범위가 시스템 전체일 수도 있고, 특정 모듈이나 기능일 수도 있다.) |
| 검증대상 ex | 특정 사용자 시나리오에서 시스템이 예상대로 동작하는지 | 사용자가 웹 애플리케이션에서 로그인, 데이터 입력, 기능 탐색 등을 어떻게 수행하는지 | 사용자가 특정 요구 사항을 충족하는지를 확인하기 위해 특정 기능에 대한 테스트 |
라고 한다.
출처
- https://brunch.co.kr/@boorownie/5
- https://toast1307.tistory.com/11
- https://docs.nhncloud.com/ko/Game/GameAnvil/ko/hammer/hammer-3-scenario-test-guide/
반응형