소프트웨어 테스팅 (Software Testing)
V&V, 블랙박스, 화이트박스
V&V (Verification & Validation)
| 구분 |
정의 |
질문 |
| Verification |
주어진 단계에서 이전 단계 문서에 부합하는지 확인 |
"제품을 올바르게 만들고 있는가?" |
| Validation |
최종 제품이 사용자 요구를 만족하는지 확인 |
"올바른 제품을 만들고 있는가?" |
테스팅 레벨
| 레벨 |
설명 |
| 단위 테스트(Unit) |
개별 모듈/함수 테스트 |
| 통합 테스트(Integration) |
모듈 간 인터페이스 테스트 |
| 시스템 테스트(System) |
전체 시스템 요구사항 검증 |
| 인수 테스트(Acceptance) |
사용자 요구사항 충족 여부 확인 |
블랙박스 테스팅 (Black-box Testing)
- 내부 구조 무시, 입출력만 검증
- 요구사항 명세 기반으로 테스트 케이스 설계
- 예: 보험료 계산 시스템 → 다양한 입력값으로 예상 결과와 비교
기법
- 동등 분할(Equivalence Partitioning): 유사한 동작을 하는 입력 그룹으로 분류
- 경계값 분석(Boundary Value Analysis): 경계 근처 값 집중 테스트
화이트박스 테스팅 (White-box Testing)
- 내부 구조(코드)를 보고 테스트 케이스 설계
- 모든 경로, 분기, 조건을 커버
Inspection vs Testing
| 구분 |
Inspection |
Testing |
| 코드 실행 |
X |
O |
| 오류 발견 시점 |
조기 |
후반 |
| 비용 |
낮음 |
높음 |
| 대상 |
모든 산출물 |
실행 가능한 코드 |
Inspection 절차
코드를 실행하지 않고 산출물을 단계별로 검토하여 오류를 발견하는 체계적 활동
7단계 프로세스
- Pre-planning — 검토 범위/목적 정의, 인스펙터 선정
- Overview (선택) — 새 기술 도입, 조직 내 첫 Inspection 등 특수한 경우에만 수행
- Preparation — 가장 중요한 단계. 각 인스펙터가 개별적으로 산출물 검토, 체크리스트로 결함 기록 → Preparation Log 작성 후 모더레이터에게 제출
- Inspection Meeting — 로그 종합, 오류 심각도 평가 및 유형 분류, 수정 방법 논의. 미해결 사항은 Open Issue로 남김
- Side Hour — Open Issue 처리. 외부 전문가 참여 가능
- Rework & Follow-up — Major Defect 수정 필수 / Minor Defect는 비용 고려. 수정 중 Secondary Defect 발생 여부 확인
- Inspection Evaluation — 발견 오류 수·유형, 프로세스 효율성 평가 → 향후 프로젝트에 활용
결함 유형
- Clarity — 명확성 결여
- Accuracy — 정확성 문제
- Consistency — 일관성 부족
결과물
- Preparation Log: 발견 결함 목록 + 검토 소요 시간
- 오류 리스트: 최종 확정 결함 목록 + 심각도
JavaScript 테스트 프레임워크
Jest vs Mocha
| 구분 |
Jest |
Mocha |
| 특징 |
배터리 포함 (all-in-one) |
테스트 러너에 집중, 유연한 조합 |
| assertion |
내장 (expect) |
외부 라이브러리 필요 (Chai 등) |
| mocking |
내장 (jest.fn()) |
Sinon.js 등 별도 설치 |
| 설정 |
Zero-configuration |
직접 구성 필요 |
| 스냅샷 테스팅 |
지원 |
미지원 |
| 속도 |
병렬 실행, watch mode |
상대적으로 가벼움 |
| 주요 사용처 |
React/Vue 등 현대 프론트엔드 |
세밀한 환경 제어가 필요한 경우 |
// Jest 예시
test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});
관련 개념