⚙️ 단위 테스트 (Unit Test) - Stub, Driver
구현 단계에서 각 모듈의 개발을 완료한 후 개발자가 명세서의 내용대로 정확히 구현되었는지 테스트한다.
테스트 드라이버 (Test Driver)
- 필요 데이터를 인자를 통해 넘겨주고, 테스트 완료 후 그 결과값을 받는 역할을 하는 가상의 모듈
테스트 스텁 (Test Stub)
- 인자를 통해 받은 값으로 수행한 후, 그 결과를 테스트할 모듈에 넘겨주는 역할
발견할 수 있는 오류
- 알고리즘 오류에 따른 원치 않은 결과
- 탈출구 없는 반복문의 사용
- 틀린 계산 수식에 따른 잘못된 결과
⚙️ 통합 테스트 (Integration Test)
시스템을 구성하는 모듈의 인터페이스와 결합을 테스트하는 것 (모듈 간 상호작용)
상향식 통합 테스트
- 하위 모듈 → 상위 모듈 방향으로 통합 (최하위 모듈 먼저 구현하고 테스트)
- 주요 제어 모듈 하나와 관련된 종속 모듈의 그룹인 클러스터 필요
하향식 통합 테스트
- 상위 모듈 → 하위 모듈 방향으로 통합 (최상위 모듈 먼저 구현하고 테스트)
- 깊이 우선, 넓이 우선 통합법
- 빨리 파악하고자 할 때 사용
⚙️ 소프트웨어 테스트 기본 원칙
테스팅은 결함이 존재함을 밝히는 활동
- 테스트는 프로그램의 결함이 없음을 보장하는 활동이 아니라, 결함이 존재함을 밝히기 위한 활동이다.
완벽한 테스팅은 불가능
- 매우 단순한 소프트웨어가 아닌 이상 내부 조건, 입력값, 타이밍에 대한 모든 조합을 확인할 수 없다. 따라서 테스트 대상의 리스크 분석 후에 가장 중요한 부분을 중점으로 테스팅 리소스를 투입하여야 한다.
테스팅은 개발 초기 단계에서부터 시작해야 한다
- 요구 사항 분석 및 설계 단계에서부터 테스트를 진행하는 경우 문서상의 결함을 확인할 수 있다. 이러한 결함은 코딩 작업 이후에 발견되는 결함에 비해 훨씬 간단하게 해결할 수 있다. 또한 조기에 테스트 설계를 마친 경우 코딩이 완료되자마자 테스트 케이스를 레벨별로 실행할 수 있어 전체 테스트 기간을 단축할 수 있다.
결함 집중
- 파레토 법칙이 좌우한다.(오류의 80%는 전체 모듈의 20%에서 발견)
- 애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재한다.
- 결함은 발생한 모듈에서 계속 추가로 발생할 가능성이 높다.
살충제 패러독스(Pesticide Paradox)
- 동일한 테스트 케이스를 반복하면 더 이상 새로운 결함이 발견되지 않는 현상
- 이를 극복하려면 새로운 기법, 다른 시각에서 테스트 케이스를 정기적으로 변경하고 추가해주어야 한다.
테스팅은 정황(Context)에 의존
- 소프트웨어의 종류나 목표 등에 따라 해당 소프트웨어에 맞는 테스트 방식이 적용되어야 한다. 개발 프로젝트인지 운영중인 시스템의 유지보수인지 여부, 사용 가능한 예산, 출시 일정, 리스크, 조직 문화, 사용자의 기대, 테스팅에 필요한 기반 환경의 가용성, 프로젝트의 중요도 등이 고려되어야 한다.
오류 부재의 궤변
- 거의 모든 결함을 확인 후 제거하였다고 해도 사용자의 요구 또는 비즈니스 목적을 충족시키지 못하는 경우 품질이 높다고 할 수 없다.
슬기로운 개발 생활