애플리케이션 테스트의 분류

프로그램 실행 여부에 따른 테스트

애플리케이션을 테스트할 때 프로그램의 실행 여부에 따라 정적 테스트(Static Testing)와 동적 테스트(Dynamic Testing)로 구분됩니다.

테스트 유형	설명	특징
정적 테스트 (Static Testing)	프로그램을 실행하지 않고 명세서, 소스 코드 등을 분석하여 결함을 찾는 테스트	- 개발 초기 단계에서 오류를 발견하여 비용 절감 가능  - 코드 검토(Code Review), 워크스루(Walkthrough), 인스펙션(Inspection) 등을 포함  - 소프트웨어의 논리적 오류나 구조적 문제를 조기에 식별
동적 테스트 (Dynamic Testing)	프로그램을 실제로 실행하여 오류를 찾는 테스트	- 프로그램을 실행하여 입력값과 출력값을 검증  - 소프트웨어 개발의 모든 단계에서 수행 가능  - 블랙박스 테스트(Black-box Testing), 화이트박스 테스트(White-box Testing) 포함

 

• 정적 테스트는 코드 실행 없이 검토 및 분석을 통해 결함을 찾는 방식으로, 코드 품질 유지와 문서화 과정에서 중요한 역할을 합니다.
• 동적 테스트는 실제 실행을 통해 오류를 발견하는 방식으로, 기능적 결함을 탐지하는 데 효과적입니다.
• 정적 테스트는 주로 개발 초기에, 동적 테스트는 개발 후반부와 배포 전에 집중적으로 수행됩니다.

---

테스트 기반(Test Bases)에 따른 테스트

애플리케이션을 테스트할 때 어떤 기준을 기반으로 수행하느냐에 따라 명세 기반 테스트, 구조 기반 테스트, 경험 기반 테스트로 구분됩니다.

테스트 유형	설명	특징	종류
명세 기반 테스트 (Specification-Based Testing, Black-Box Testing)	사용자의 요구사항을 기반으로 테스트 케이스를 작성하여 기능을 검증하는 테스트	- 내부 구조를 고려하지 않고, 입력-출력 중심으로 테스트 수행 - 블랙박스 테스트 방식 사용 - 기능 요구사항이 정확히 구현되었는지 확인	등등 분할, 경계 값 분석
구조 기반 테스트 (Structure-Based Testing, White-Box Testing)	소프트웨어 내부 코드의 논리 흐름에 따라 테스트 케이스를 작성하여 검증하는 테스트	- 코드 커버리지 기준으로 테스트 수행 - 화이트박스 테스트 방식 사용 - 소스 코드와 직접 연결된 테스트	구문 기반, 결정 기반, 조건 기반
경험 기반 테스트 (Experience-Based Testing)	테스터의 경험과 직관을 바탕으로 수행하는 테스트	- 요구사항 문서 없이도 수행 가능 - 과거 유사 프로젝트에서 발견된 결함을 고려하여 테스트 - 탐색적 테스팅(Exploratory Testing)과 오류 추정(Error Guessing) 기법 활용	에러 추정, 체크 리스트, 탐색적 테스팅

 

• 명세 기반 테스트는 사용자의 요구사항을 중심으로 검증하며, "기능이 정상적으로 동작하는가?"에 초점을 맞춥니다.
• 구조 기반 테스트는 프로그램의 내부 로직과 코드의 흐름을 분석하여 "모든 코드가 정상적으로 실행되는가?"를 확인합니다.
• 경험 기반 테스트는 문서화되지 않은 예외 사항이나 예상치 못한 오류를 발견하는 데 유용하며, 베테랑 테스터가 주로 활용합니다.

---

시각에 따른 테스트

애플리케이션을 테스트할 때 누구를 기준으로 테스트를 수행하는가에 따라 검증(Verification) 테스트와 확인(Validation) 테스트로 구분됩니다.

테스트 유형설명특징

테스트 유형	설명	특징
검증 테스트 (Verification)	개발자의 시각에서 제품의 생산 과정을 테스트하는 방식	- 요구사항 명세서 및 설계 문서를 기반으로 테스트 수행 - 제품이 명세서대로 구현되었는지를 확인
확인 테스트 (Validation)	사용자의 시각에서 제품의 결과물을 테스트하는 방식	- 제품이 사용자의 요구사항을 충족하는지 확인 - 최종 제품이 정상적으로 동작하는지 테스트

 

• 검증(Verification): 제품이 **제대로 만들어지고 있는가?**에 초점을 둔 테스트 (개발자의 관점)
• 확인(Validation): 제품이 **사용자가 원하는 대로 동작하는가?**를 테스트 (사용자의 관점)

검증 없이 확인만 수행하면? → 제품의 명세서와 다른 기능이 구현될 수 있음
확인 없이 검증만 수행하면? → 사용자의 요구사항을 충족하지 못할 가능성이 있음

검증과 확인은 함께 수행해야 완성도 높은 소프트웨어를 개발할 수 있습니다

---

목적에 따른 테스트

애플리케이션을 테스트할 때 무엇을 목적으로 수행하는지에 따라 회복(Recovery), 안전(Security), 강도(Stress), 성능(Performance), 구조(Structure), 회귀(Regression), 병행(Parallel) 테스트로 구분됩니다.

테스트 유형	설명	특징
회복 테스트 (Recovery Test)	시스템에 여러 가지 결함을 인위적으로 발생시킨 후 정상적으로 복구되는지를 확인하는 테스트	- 장애 발생 시 자동 복구 기능이 정상적으로 작동하는지 확인 - 시스템의 복원력 및 신뢰성을 평가
안전 테스트 (Security Test)	시스템이 불법적인 접근, 해킹, 악성 코드 등의 보안 위협으로부터 안전한지 검증하는 테스트	- 사용자 인증, 권한 관리, 데이터 암호화 등 보안 요소 평가 - 외부 침입 및 공격 시도의 대응력 테스트
강도 테스트 (Stress Test)	과부하(Heavy Load) 상황에서 시스템의 안정성을 검증하는 테스트	- 과도한 트래픽, 데이터 입력, 메모리 사용 등을 부과하여 한계점 분석 - 시스템이 오작동 없이 정상적으로 동작하는지 확인
성능 테스트 (Performance Test)	소프트웨어의 응답 속도, 처리량, 효율성 등을 평가하는 테스트	- 최대 사용자 수, 응답 시간, 데이터 처리 속도 등을 측정 - 부하 테스트(Load Test), 스파이크 테스트 포함
구조 테스트 (Structure Test)	소프트웨어의 내부 논리적 경로, 코드 복잡도 등을 분석하는 테스트	- 모듈 간 결합도, 응집도 평가하여 최적화 유도 - 화이트박스 테스트 기법과 함께 활용 가능
회귀 테스트 (Regression Test)	기존 기능이 코드 수정 또는 추가 후에도 정상적으로 동작하는지 확인하는 테스트	- 변경된 코드가 기존 기능에 영향을 미치지 않는지 검증 - 지속적인 통합 환경(CI/CD)에서 반복 수행 필수
병행 테스트 (Parallel Test)	변경된 시스템과 기존 시스템을 동시에 실행하여 결과를 비교하는 테스트	- 신규 시스템이 기존 시스템과 동일한 결과를 도출하는지 검증 - 시스템 마이그레이션, 업그레이드 시 필수 수행

 회복 vs. 강도 테스트

• 회복 테스트: 시스템 장애 후 복구 가능 여부를 평가
• 강도 테스트: 과부하를 가하여 안정성을 확인

안전 vs. 성능 테스트

• 안전 테스트: 보안 및 접근 제어 평가
• 성능 테스트: 응답 시간 및 처리 속도 평가

회귀 vs. 병행 테스트

• 회귀 테스트: 기존 기능이 코드 변경 후에도 정상 작동하는지 검증
• 병행 테스트: 신규 시스템과 기존 시스템의 결과가 동일한지 비교

---

 

출저 및 참고

정보처리 산업기사 기본서(시나공)