테스트 원리와 분류
쉽게 말하면
테스트는 프로그램의 결함을 찾는 일이에요. 그런데 아무리 테스트해도 '결함이 하나도 없다'는 걸 증명할 수는 없어요. 결함은 일부 모듈에 몰려 있고, 같은 테스트만 반복하면 더는 새 결함을 못 찾아요. 이런 원리를 알아 두면 좋아요. 또 만든 대로 잘 만들었는지 보는 검증(Verification)과, 고객이 원한 것을 만들었는지 보는 확인(Validation)을 구분해야 해요.
시험용 정의
애플리케이션 테스트는 결함을 찾아내고 품질을 확인하는 활동이다. 테스트 원리: 테스트는 결함이 있음을 보여 줄 뿐 없음을 증명하지 못한다, 완벽한 테스트는 불가능하다, 초기 집중(일찍 할수록 비용이 적다), 결함 집중(파레토 법칙: 결함의 80%는 20% 모듈에), 살충제 패러독스, 정황 의존(소프트웨어 특징에 맞게), 오류-부재의 궤변(결함을 다 고쳐도 요구를 못 맞추면 품질이 낮다). 프로그램을 실행하지 않는 정적 테스트(리뷰, 워크스루, 인스펙션)와 실행하는 동적 테스트(화이트박스, 블랙박스)가 있다. 검증(Verification)은 개발자 관점에서 명세대로 올바르게 만들었는지, 확인(Validation)은 사용자 관점에서 요구에 맞는 제품을 만들었는지 본다.
비유로 이해하기
건강 검진이다. 검사에서 이상이 안 나왔다고 병이 하나도 없다는 증명은 아니다. 늘 같은 항목만 검사하면 다른 병을 못 찾는다(살충제 패러독스). 아픈 곳은 몇몇 장기에 몰려 있기 쉽다(결함 집중).
자세히
먼저 알아 둘 말
| 말 | 뜻 |
|---|---|
| 결함(버그) | 소프트웨어가 기대와 다르게 동작하게 만드는 잘못 |
| 테스트 케이스 | 입력값, 실행 조건, 기대 결과를 묶은 시험 항목 |
| 테스트 시나리오 | 여러 테스트 케이스를 실행 순서대로 묶은 것 |
| 테스트 오라클 | 결과가 맞는지 판단하는 기준(참 값) |
| 회귀 테스트 | 고친 뒤 다른 곳에 새 결함이 생기지 않았는지 다시 하는 테스트 |
테스트 오라클 종류
| 종류 | 뜻 |
|---|---|
| 참(True) 오라클 | 모든 입력에 대해 기대 결과를 제공. 모든 오류 검출 가능 |
| 샘플링 오라클 | 특정 몇 개 입력에만 기대 결과 제공 |
| 추정(휴리스틱) 오라클 | 특정 입력에는 기대 결과를, 나머지는 추정으로 |
| 일관성 검사 오라클 | 변경 전후 결과가 같은지 확인 |
목적에 따른 테스트
| 테스트 | 확인하는 것 |
|---|---|
| 회복(Recovery) | 고장 후 올바르게 복구되는지 |
| 안전(Security) | 불법 침입으로부터 보호되는지 |
| 강도(Stress) | 과부하에서도 동작하는지 |
| 성능(Performance) | 응답 시간, 처리량 |
| 구조(Structure) | 내부 논리 경로, 소스 복잡도 |
| 회귀(Regression) | 변경 후 새 결함이 없는지 |
| 병행(Parallel) | 변경된 것과 기존 것에 같은 데이터를 넣어 비교 |
검증과 확인
| 구분 | 질문 | 관점 |
|---|---|---|
| 검증 (Verification) | 제품을 올바르게 만들고 있나? (명세대로) | 개발자 |
| 확인 (Validation) | 올바른 제품을 만들고 있나? (요구대로) | 사용자 |
기출에서 더 나온 것
| 말 | 뜻 |
|---|---|
| 오류 (Error) | 사람의 실수로 생긴 잘못 |
| 결함 (Fault, Defect) | 오류 때문에 소프트웨어 안에 생긴 잘못된 부분. 실행되면 고장을 일으킨다 |
| 고장 (Failure) | 결함이 실행되어 소프트웨어가 기대와 다르게 동작하는 것 |
| 테스트 데이터 자동 생성 방법 | 자료 흐름도 이용, 입력 도메인 분석, 랜덤 테스트 (스텁과 드라이버는 통합 테스트 도구) |
| 복구 테스트 | 고의로 실패를 일으킨 뒤 정상으로 돌아오는지 본다 |
시험에 이렇게 나와요
- 오류의 80%가 20% 모듈에 몰림 → 파레토 법칙(결함 집중)
- 테스트 원리 설명 보고 고르기 → 결함 집중·살충제 패러독스·오류-부재의 궤변·완벽한 테스트는 불가능
- 테스트는 오류를 찾고, 디버깅은 오류를 고친다
- 검증(Verification) → 개발 과정이 명세대로인가 / 확인(Validation) → 결과물이 사용자 요구에 맞는가
- 테스트 케이스 구성 → 조건·데이터·예상 결과 (비용은 아님). 목표와 방법을 정한 뒤에 만든다
- 강도(스트레스) 테스트 → 과부하를 줘도 정상 동작하는지 본다
확인 문제
Q1. 같은 테스트 케이스를 반복하면 더 이상 새로운 결함을 찾지 못한다는 테스트 원리는?
- 살충제 패러독스
- 완벽한 테스트 불가능
- 결함 집중
- 오류-부재의 궤변
정답 보기
1번 살충제 패러독스
살충제 패러독스: 같은 살충제를 계속 뿌리면 벌레가 내성이 생기듯, 같은 테스트로는 새 결함을 못 찾는다. 테스트 케이스를 계속 검토하고 바꿔야 한다.
Q2. 결함을 모두 고쳤더라도 사용자 요구를 만족하지 못하면 좋은 소프트웨어가 아니라는 원리는?
- 오류-부재의 궤변
- 정황 의존
- 살충제 패러독스
- 결함 집중
정답 보기
1번 오류-부재의 궤변
오류가 없다는 것만으로 품질이 보장되지 않는다.
Q3. 시스템에 과도한 정보량이나 빈도를 주어 과부하 상태에서도 동작하는지 보는 테스트는?
- 병행 테스트
- 강도 테스트
- 회복 테스트
- 구조 테스트
정답 보기
2번 강도 테스트
강도(Stress) 테스트다. 회복 테스트는 장애 뒤 복구를, 병행 테스트는 새 시스템과 기존 시스템을 같이 돌려 비교한다.
Q4. 특정한 몇몇 입력값에 대해서만 기대 결과를 제공하는 테스트 오라클은?
- 참 오라클
- 샘플링 오라클
- 일관성 검사 오라클
- 추정 오라클
정답 보기
2번 샘플링 오라클
샘플링 오라클이다. 참 오라클은 모든 입력에 기대 결과를 주고, 일관성 검사 오라클은 변경 전후 결과가 같은지 본다.
Q5. '올바른 제품을 만들고 있는가(사용자 요구에 맞는가)'를 확인하는 것은?
- 확인 (Validation)
- 인스펙션
- 디버깅
- 검증 (Verification)
정답 보기
1번 확인 (Validation)
Validation은 사용자 관점.
헷갈리기 쉬운 O·X
충분히 테스트하면 소프트웨어에 결함이 없음을 증명할 수 있다.
정답 보기
X 테스트는 결함이 있음을 보여 줄 뿐 없음을 증명하지 못한다.
결함 집중 원리에 따르면 결함 대부분은 소수의 모듈에 몰려 있다.
정답 보기
O 파레토 법칙.
인스펙션과 워크스루는 프로그램을 실행해서 하는 동적 테스트다.
정답 보기
X 실행하지 않는 정적 테스트다.