**용어 설명**
테스트 레벨: 테스트 프로세스 중의 특정 예시 단계
테스트 유형: 컴포넌트나 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합
컴포넌트: 개별적으로 테스트할 수 있는 시스템의 최소 구성단위
엔드 투 엔드 테스팅: 생산 환경과 유사한 환경에서 비즈니스 프로세스를 처음부터 끝까지 테스트하는 테스팅 유형
테스트 명세: 특정 테스트 항목에 대한 테스트 설계, 테스트 케이스, 테스트 스크립트를 모두 담고 있는 문서
<기능&비기능 테스트의 기능과 비기능 해석>
기능: 무엇을 해야 하는지
비기능: 얼마나 잘 돌아가는지
확인 테스팅: 원래 결함이 성공적으로 수정됐는지 확인
리그레션 테스팅: 변경으로 인해 부정적인 영향 있는지 확인(확인 테스팅 -> 리그레션 테스팅 순)2.2 테스트 레벨과 테스트 유형
테스트 레벨은 함께 구성하고 관리하는 테스트 활동 집합이다.
각 테스트 레벨은 특정 개발 단계의 소프트웨어와 관련해 수행하는 테스트 프로세스의 인스턴스이다.
단계에 따라 소프트웨어는 개별 컴포넌트부터 완성된 시스템에 이를 수 있으며, 경우에 따라서는 시스템의 시스템일 수도 있다.
테스트 레벨은 SDLC 내의 다른 활동과 연관성을 가진다.
순차적 SDLC 모델은 한 레벨의 완료 조건이 다음 레벨의 시작 조건에 포함되도록 테스트 레벨을 정의하는 경우가 많다.
테스트 유형은 특정 품질 특성 관련 테스트 활동의 집합으로, 이런 테스트 활동은 대부분 모든 테스트 레벨에서 수행할 수 있다.
2.2.1 테스트 레벨
1. 컴포넌트 테스팅(== 단위 테스팅)
컴포넌트를 개별적으로 테스트하는데 중점.
테스트 하네스 또는 단위 테스트 프레임워크와 같은 구체적인 지원 수단이 필요한 경우가 많다.
일반적으로 개발자가 자신의 개발 환경에서 수행한다.
2. 컴포넌트 통합 테스팅(==단위 통합 테스팅)
컴포넌트 간의 인터페이스와 상호 작용을 테스트하는데 중점.
컴포넌트 통합 테스팅은 상향식, 하향식, 빅뱅 등 통합 전략 접근법에 따라 크게 달라진다.
3. 시스템 테스팅
전체 시스템 또는 제품의 전반적인 동작과 기능에 중점.
엔드투엔드(end-to-end) 동작에 대한 기능 테스팅과 품질 특성에 대한 비기능 테스팅을 포함하는 경우가 많다.
독립된 테스트팀이 수행할 수 있으며, 시스템의 명세와 관련이 있다.
4. 시스템 통합 테스팅
다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는데 중점.
가급적 운영 환경과 유사한 적절한 테스트 환경을 사용한다.
5. 인수 테스팅
벨리데이션과 배포할 준비, 즉 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는데 중점.
실제 사용자가 수행하는 것이 이상적이다.
주요 유형으로 사용자 인수 테스팅(UAT), 운영 인수 테스팅, 계약 및 규제 인수 테스팅, 알파 테스팅, 베타 테스팅 등이 있다.
테스트 레벨은 테스트 활동의 중복을 피하기 위해 다음과 같은 다양한 속성을 고려해 구분한다.
- 테스트 대상
- 테스트 목적
- 테스트 베이시스
- 결함과 장애
- 접근법과 역할
2.2.2 테스트 유형
1. 기능 테스팅
컴포넌트 또는 시스템이 수행해야 하는 기능을 평가한다.
기능은 테스트 대상이 '무엇을' 해야 하는지를 의미한다. 주요 목적은 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성)을 확인하는 것이다.
2. 비기능 테스팅
컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가한다.
비기능 테스팅은 '시스템이 얼마나 잘 동작하는지' 테스트하는 것이다. 주요 목적은 비기능 소프트웨어 품질 특성을 확인하는 것이다.
ISO/IEC 25010 표준은 비기능 소프트웨어 품질 특성을 다음과 같이 분류한다.
- 수행 효율성
- 호환성
- 유용성
- 신뢰도
- 보안
- 유지 가능성
- 이동성
수명주기 초기에 비기능 테스팅을 시작하는 것이 바람직할 때가 있다.
기능 테스트에서 비기능 테스트를 도출하는 경우도 많다. 이때 기능 테스트에서 기능이 수행되는 동안 비기능 제약 조건의 충족 여부를 확인하게 된다. 비기능 결함을 늦게 발견하면 프로젝트의 성공에 심각한 위협이 될 수 있다.
3. 블랙박스 테스팅
명세를 기반으로 하며, 테스트 대상 외부에 있는 문서에서 테스트를 도출한다.
주요 목적은 명세와 비교해 시스템의 동작을 확인하는 것이다.
4. 화이트박스 테스팅
구조 기반이며, 시스템의 구현 또는 내부 구조에서 테스트를 도출한다.
주요 목적은 테스트를 통해 내부 구조를 인수에 필요한 수준까지 충분이 커버하는 것이다.
2.2.3 확인 테스팅 및 리그레션 테스팅
일반적으로 컴포넌트나 시스템을 변경하는 이유는 새로운 기능을 추가해 개선하거나, 결함을 제거해 수정하기 위함이다. 이때는 테스팅에 확인 테스팅과 리그레션 테스팅을 추가할 필요가 있다.
확인 테스팅
원래 결함이 성공적으로 수정됐는지 확인한다.
리스크에 따라 다음과 같은 여러 가지 방법으로 수정된 소프트웨어 버전을 테스트할 수 있다.
- 결함으로 인해 이전에 실패했던 모든 테스트 케이스를 실행한다.
- 결함을 수정하기 위해 변경한 사항을 확인하는 새로운 테스트를 추가한다.
그러나 결함을 수정하는데 시간이나 비용이 부족한 경우, 결함으로 생긴 장애를 재현하기 위한 절차를 거쳐 장애가 발생하지 않는지 확인하는 것만으로 확인 테스팅이 끝날 수도 있다.
리그레션 테스팅
변경으로 인해 부정적인 영향이 없었는지 확인하는 것이다.
이미 확인 테스팅이 끝난 수정 사항도 여기서 말하는 변경에 포함된다.
리그레션 테스팅은 테스트 대상 자체에만 국한되지 않고, 환경과도 관련이 있을 수 있다.
리그레션 테스팅의 범위를 최적화 하기 위해 영향도 분석을 먼저 수행하는 것이 좋다.
영향도 분석은 소프트웨어의 어느 부분이 영향을 받을 수 있는지 보여준다.
리그레션 테스트 스위트는 반복적으로 실행되며, 자동화히기 매우 적합한 대상이 된다.
이런 테스트 자동화는 프로젝트 초기에 시작해야 한다. 데브옵스와 같이 지속적 통합을 사용하는 경우, 자동 리그레션 테스트를 포함하는 것이 좋은 프랙티스이다.
어떤 테스트 레벨이라도 해당 레벨에서 결함을 수정하거나 변경을 적용한 경우, 테스트 대상에 대한 확인 테스팅과 리그레션 테스팅이 필요하다.
2.3 유지보수 테스팅
유지보수에는 여러 범주가 있다. 문제를 수정하기 위한 유지보수, 환경 변화에 적응, 성능 또는 유지보수성을 개선하기 위한 것도 있기 때문에, 유지보수는 계획된 릴리스/배포 또는 계획되지 않은 릴리스/배포(핫픽스) 모두와 연관돼 있다.
운용 환경에서 시스템의 변경사항을 테스트하는 것에는 변경 구현의 성공을 검증하는 것과, 변경되지 않은 시스템 영역에서 발생할 수 있는 리그레션을 확인하는 작업이 모두 포함된다.
유지보수 테스팅의 범위는 일반적으로 다음에 따라 달라진다.
- 변경의 리스크 수준
- 기존 시스템의 크기
- 변경사항의 크기
유지보수와 유지보수 테스팅의 계기
- 계획된 개선사항, 수정을 위한 변경, 핫픽스와 같은 수정사항
- 운영 환경의 업그레이드나 마이그레이션.
변경된 소프트웨어뿐만 아니라 새로운 환경 관련 테스트가 필요할 수 있으며, 다른 애플리케이션의 데이터를 유지보수 중인 시스템으로 마이그레이션할 때, 데이터 변환 테스트가 필요할 수 있다. - 애플리케이션의 수명이 다하는 등의 단종
단종할 때 데이터 보존 기간이 길면 데이터 보관 테스팅이 필요할 수 있다.
보관 기간 중 데이터가 필요한 경우를 대비해, 보관 이후 복원 및 복구 절차 테스팅이 필요할 수 있다.
