1. 요구사항/표준 준수 검증, 소프트웨어 테스트의 개요
(1) 소프트웨어 테스트 (Software Test)의 개념 및 목적
| 개념 | 목적 |
|---|---|
| 시스템의 요구사항 만족 여부 및 표준 준수 여부를 검증하기 위해 수행하는 결함 검출, 품질 평가, 프로세스 개선 과정 | – 결함의 검출과 제품 품질 개선 – 품질 평가와 의사 결정 지원 – 개발 프로세스 개선 지원 |
(2) 오류, 결함, 장애의 개념
| 오류 (Error) | – 결함이 발생하도록 만든 개발자의 행위로, 요구사항을 잘못 파악, 오해하여 발생 – 오타나 프로그램 명령어를 잘못 이해하여 코딩하는 경우 등 |
|---|---|
| 결함 (Defect) | – S/W에 장애를 유발할 수 있는 문제로, 부정확한 구현, 필요 기능 미포함 등으로 발생 – 결함이 있다고 반드시 장애가 발생하는 것은 아님 |
| 장애 (Failure) | – 소프트웨어가 요구사항과 다르게 동작하여 발생한 문제 – 프로그램의 실행 결과와 요구사항에 명시된 결과에 차이가 있음을 의미 |
(3) 테스트의 진화 과정과 원칙
| 테스트 진화 과정 | ||
|---|---|---|
| 테스트 원칙 | 개발자나 개발팀과 무관한 그룹이 수행 | – 자신이 개발한 소프트웨어에 대해 방어적 경향 존재 – 담당한 부분의 요구사항을 해석하지 못했을 가능성 존재 |
| 결함 미발견 가정하에 테스트 계획 수립 불가 | – 테스트는 프로그램이 올바르게 동작함을 보여주는 것이 아니고 결함을 발견하려는 의도로 수행하는 과정 | |
| 예상하지 못한 경우에 대해서도 테스트 수행 | – 예상하지 못한 방식으로 프로그램이 사용되는 경우 많은 결함이 발생 | |
| 파레토(Pareto)의 원칙 | – 프로그램 결함의 80%는 20%의 모듈에서 발생 – 결함이 다수 발생한 부분에 테스트 노력 집중이 효과적 | |
| 테스트 케이스를 체계적으로 관리 | – 테스트 케이스 설계는 시간과 노력이 다수 발생 – 기존에 만든 테스트 케이스를 재사용하여 테스트 | |
| 각 테스트 결과를 철저히 점검 | – 이전 수행 테스트 케이스에서 결함 발견 누락 존재 – 주의 깊게 테스트 결과 점검 시 결함 발견 확률 향상 | |
- 결함 검출 시 다수의 테스트 케이스가 필요하며 테스트 원리에 따라 현실적으로 완벽한 테스트 불가
- 가용한 인력과 시간으로 최대한 효율적인 테스트를 수행하기 위해 테스트 프로세스 적용 등 체계적인 테스트 수행 필요
2. 체계적인 테스트 수행 위한 소프트웨어 테스트의 분류
| 분류 | 테스트 종류 | 테스트 방법 | |
|---|---|---|---|
| 테스트 레벨 | 컴포넌트/단위 테스트 | 개별 모듈(컴포넌트)에 대해 정상 동작 여부 확인 | |
| 통합 테스트 | 컴포넌트 간 인터페이스 정상 동작 여부 확인 | ||
| 시스템 테스트 | 전체 시스템의 목적 만족 여부 확인 | ||
| 인수 테스트 | 사용자의 요구사항 만족 여부 확인 | ||
| 테스트 설계 | 동적 테스트 | 명세 기반 테스트 | 명세를 바탕으로 테스트 케이스 생성 |
| 구조 기반 테스트 | 프로그램 코드 정보를 통해 테스트 케이스 생성 | ||
| 경험 기반 테스트 | 테스터의 경험을 통해 테스트 케이스 생성 | ||
| 정적 테스트 | 리뷰 | 산출물 내 결함 검출, 프로젝트 진행 상황 점검 | |
| 정적 분석 | 자동화 도구 통해 산출물 결함 검출, 복잡도 측정 | ||
| 테스트 유형 | 기능 테스트 | 기능 요구사항에 대한 결함 검출, 충족 여부 확인 | |
| 비기능 테스트 | 기능 적합성 테스트 | 사용자 요구사항을 만족하는 정도 테스트 | |
| 성능 효율성 테스트 | 시스템의 응답시간이나 처리량 테스트 | ||
| 호환성 테스트 | 다른 시스템과의 상호 연동이나 공존성 테스트 | ||
| 사용성 테스트 | 사용자가 이해하고 배우기 쉬운 정도 테스트 | ||
| 신뢰성 테스트 | 규정된 조건/기간 오동작 없이 수행 여부 테스트 | ||
| 보안성 테스트 | 시스템의 정보 및 데이터 보호 능력 테스트 | ||
| 유지보수성 테스트 | 소프트웨어 유지보수의 용이성 테스트 | ||
| 이식성 테스트 | 다양한 플랫폼에서 운영 능력 테스트 | ||
- 소프트웨어 개발 단계(요구분석, 설계, 구현 등)에 상응하는 테스트 레벨을 표현한 것이 V 모델이며, ISO 29119에서는 테스트 유형의 기능/비기능 테스트를 유형 테스트라고 하고, ISO 25010의 소프트웨어 품질 모델의 특성에 따라 비기능 테스트 수행
- 단위 테스트는 화이트박스 테스트, 시스템/인수 테스트는 블랙박스 테스트로 수행
- 소프트웨어 테스트 성숙도 점검 및 향상을 위해 TMMi(Test Maturity Model Integration) 적용 검토
3. 소프트웨어 테스트와 V&V 및 품질 보증 관계
- 소프트웨어 테스트는 품질 보증을 위한 핵심 개념인 V&V (검증(Verification) & 확인(Validation)) 활동에서 수행하는 과정
- V&V에서 검증은 개발 과정에서 수행한 활동의 적합성에 초점, 확인은 결과물의 적합성에 초점
- 예를 들어, 검증(Verification)은 요구사항 명세서가 설계 결과물에 적절하게 반영되었는지 조사하는 추적성에 초점을 두며, 확인(Validation)은 동작하는 소프트웨어가 주어진 요구사항을 충족하는지 여부에 초점을 둠
[참고]
- 한국정보통신기술협회(TTA), 소프트웨어테스트 전문가(CSTS) 가이드