작성 맥락
이 글은 직접 학습하거나 구현하며 남긴 개인 기술 기록입니다. 참고 자료가 있는 경우 본문에 출처를 남기고, 틀린 부분을 발견하면 수정합니다.
애플리케이션 테스트 🧪
출제 빈도: 상
빈출 태그: 테스트 원리, 정적/동적 테스트, 화이트박스/블랙박스 테스트, 테스트 오라클
테스트는 “다 돌려봤는데 문제없었다”는 말이 가장 위험한 분야다. 아래 파레토 법칙에서 보듯 결함은 특정 모듈에 몰려 있는 경우가 대부분이라, 무작정 전체를 반복 테스트하기보다 원리를 알고 결함이 몰릴 만한 지점을 겨냥하는 편이 효율적이다.
1. 소프트웨어 테스트 개요
테스트의 목적
- 기능, 성능, 사용성, 안정성 검증
- 결함 발견 및 문제점 해결
테스트의 필요성
- 오류 발견
- 사전 예방
- 신뢰도 향상
2. 테스트 원리 ⭐
- 결함 집중: 특정 모듈에 결함이 집중적으로 존재
- 낚시의 법칙: 낚시 포인트처럼 특정 위치에 많은 결함 발생
- 파레토(Pareto)의 법칙: 결함의 80%는 20%의 기능에서 발생
- 살충제 패러독스: 동일한 테스트 케이스 반복 실행은 한계가 있어 지속적 개선 필요
- 오류 부재 궤변: 사용자 요구사항을 완전히 만족하지 못하면 품질 보증 불가능
3. 소프트웨어 테스트 산출물
- 테스트 계획서
- 테스트 케이스: 입력값, 실행 조건, 기대 결과
- 시나리오: 테스트 케이스의 동작 순서
- 테스트 결과서
4. 테스트 유형
기본 분류
- 정적 테스트: 실행 없이 구조 분석
- 동적 테스트: 실행화면을 보며 테스트 수행
- 화이트박스: 내부로직 검증
- 블랙박스: 기능 검증
목적 기반 테스트
- 회복: 실패 유도 후 정상 복귀 가능성 테스트
- 안전: 보안 결함 테스트
- 강도: 과부하 시 정상작동 여부
- 성능
- 구조
- 회귀: 변경된 코드의 새로운 결함 여부
- 병행
설계 기반 테스트
- 명세 기반: 주어진 명세 기반
- 구조 기반: 내부 로직 기반
- 경험 기반
5. 화이트박스/블랙박스 테스트
화이트박스 테스트 기법
- 기초 경로 테스트
- 설계서/소스 코드 기반 흐름도 작성
- 논리적 순환 복잡도 측정 (복잡도 = 간선수 - 노드수 + 2)
- 제어 구조 검사
- 조건 검사(논리식, 조건 중심)
- 루프 검사(반복 구조 중심)
- 데이터 흐름 검사(변수의 정의와 사용 중심)
블랙박스 테스트 기법
- 동등 분할: 유효/무효값 균등 분배
- 경계값 분석: 경계에서 오류 발생 확률이 높음
- 원인-효과 그래프: 입력 데이터의 출력 영향 분석
- 오류 예측: 감각과 경험 의존
- 비교 테스트: 여러 버전에 동일 테스트 자료 제공
6. 테스트 오라클
- 참 오라클: 모든 입력값 기대결과 생성 (미션 크리티컬 업무)
- 샘플링 오라클: 특정 입력값만 기대결과 제공 (일반/게임 업무)
- 휴리스틱 오라클: 특정 입력값 기대결과 제공, 나머지는 추정
- 일관성 검사 오라클: 애플리케이션 변경 전후 결과값 동일성 확인
미션 크리티컬
- 항공기, 발전소 등 작은 결함도 치명적인 업무
7. 테스트 환경 및 수행
테스트 수행 환경 구축
- 실제 작동 환경과 최대한 유사하게 구성
- 가상환경 활용 가능
테스트 성공 기준
- 기대 결과와 실제 테스트 결과의 일치 여부
핵심 정리
- 화이트박스 테스트는 “코드가 어떻게 동작하는지”를, 블랙박스 테스트는 “입력에 대해 올바른 출력이 나오는지”를 검증한다는 점에서 관점 자체가 다르다 — 예를 들어 나이 입력 필드에 경계값 분석(블랙박스)을 적용한다면 0, 1, 150, 151처럼 유효 범위의 경계 바로 안팎을 집중적으로 테스트한다.
- 테스트 오라클은 “정답을 어디까지 미리 알고 있는가”의 스펙트럼이다 — 참 오라클(모든 입력의 정답을 앎, 항공기 등)에서 휴리스틱 오라클(일부만 알고 나머지는 추정, 일반 서비스)로 갈수록 비용은 낮아지지만 놓치는 결함의 위험은 커진다.
댓글이 보이지 않으면 GitHub에 로그인한 뒤 새로고침해 주세요. 공개 댓글은 로그인 상태에서 더 안정적으로 표시됩니다.