노년코딩

들어가기 전 알아둬야 할 2.2 용어, 2.3 용어 설명
: 사전적으로 설명 정리한 건 용어 설명 글 ㄱㄱ, 여기는 이해 쉽게 봐보자.

테스트 레벨 : 테스트 프로세스 중의 특정 예시 단계. 
테스트 유형 : 컴포넌트나 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합.

컴포넌트 : 개별적으로 테스트할 수 있는 시스템의 최소 구성단위.
엔드 투 엔드 테스팅 : 생산 환경과 유사한 환경에서 비즈니스 프로세스를 처음부터 끝까지 테스트하는 테스팅 유형.
테스트 명세 : 특정 테스트 항목에 대한 테스트 설계, 테스트 케이스, 테스트 스크립트를 모두 담고 있는 문서.

< 기능 테스트 & 비기능 테스트의 기능과 비기능 해석 >
기능 : 무엇을 해야 하는지.
비기능 : 얼마나 잘 돌아가는지.

확인 테스팅 : 원래 결함이 성공적으로 수정됐는지 확인.
리그레션 테스팅 : 변경으로 인해 부정적인 영향 있는지 확인. 확인 테스팅 이후에 리그레션 테스팅하는 거임.

운용 환경 : 움직이는 환경으로 이해 ㄱㄱ.

2.2 테스트 레벨과 테스트 유형

- 테스트 레벨은 함께 구성하고 관리하는 테스트 활동 집합이다.
: 각 테스트 레벨은 특정 개발 단계의 소프트웨어와 관련해 수행하는 테스트 프로세스의 인스턴스이다.
단계에 따라 소프트웨어는 개별 컴포넌트부터 완성된 시스템에 이를 수 있으며, 경우에 따라서는 시스템의 시스템일 수 있다.
- 테스트 레벨은 소프트웨어 개발수명주기 내의 다른 활동과 연관성을 가진다.
: 순차적 소프트웨어 개발수명주기 모델은 한 레벨의 완료 조건이 다음 레벨의 시작 조건에 포함되도록 테스트 레벨을 정의하는 경우가 많다.

- 테스트 유형은 특정 품질 특성 관련 테스트 활동의 집합으로, 이런 테스트 활동은 대부분 모든 테스트 레벨에서 수행할 수 있다.

2.2.1 실러버스에서 다루는 테스트 레벨 5가지

• 컴포넌트 테스팅(== 단위 테스팅) : 컴포넌트를 개별적으로 테스트하는 데 중점. 테스트 하네스 또는 단위 테스트 프레임워크와 같은 구체적인 지원 수단이 필요한 경우가 많음. 일반적으로 개발자가 자신의 개발 환경에서 수행함.
• 컴포넌트 통합 테스팅(== 단위 통합 테스팅) : 컴포넌트 간의 인터페이스와 상호 작용을 테스트하는 데 중점. 상향식, 하향식, 빅뱅 등 통합 전략 접근법에 따라 크게 달라진다.
• 시스템 테스팅 : 전체 시스템 또는 제품의 전반적인 동작과 기능에 중점. 엔드 투 엔드 동작에 대한 기능 테스팅과 품질 특성에 대한 비기능 테스팅을 포함하는 경우가 많음. 독립 테스트팀이 수행할 수 있으며, 시스템의 명세와 관련이 있음.
• 시스템 통합 테스팅 : 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는 데 중점. 가급적 운영 환경과 유사한 적절한 테스트 환경을 사용함.
• 인수 테스팅 : 밸리데이션과 배포할 준비, 즉 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는 데 중점. 실제 사용자가 수행하는 것이 이상적. 주요 유형으로 사용자 인수 테스팅, 운영 인수 테스팅, 계약 및 규제 인수 테스팅, 알파 테스팅, 베타 테스팅이 있음.

▶ 테스트 레벨은 테스트 활동의 중복을 피하기 위해 다양한 속성 "테스트 대상, 테스트 목적, 테스트 베이시스, 결함과 장애, 접근법과 역할"들을 고려해 구분한다.

2.2.2 실러버스에서 다루는 테스트 유형 4가지

• 기능 테스팅 : 컴포넌트 또는 시스템이 수행해야 하는 기능을 평가. 기능은 테스트 대상이 "무엇을" 해야 하는지를 의미. 주요 목적 - 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성)을 확인하는 것.
• 비기능 테스팅 : 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가. "시스템이 얼마나 잘 동작하는지" 테스트하는 것. 주요 목적 - 비기능 소프트웨어 품질 특성을 확인하는 것.

ISO/IEC 25010 표준은 비기능 소프트웨어 품질 특성을 다음과 같이 분류함.
- 수행 효율성.
- 호환성.
- 유용성.
- 신뢰도.
- 보안.
- 유지 가능성.
- 이동성.

수명 주기 초기에 비기능 테스팅을 시작하는 것이 바람직할 때가 있다.
기능 테스트에서 비기능 테스트를 도출하는 경우도 많다. 이때 기능 테스트에서 기능이 수행되는 동안 비기능 제약 조건의 충족 여부를 확인하게 된다. 비기능 결함을 늦게 발견하면 프로젝트의 성공에 심각한 위협이 될 수 있다.

• 블랙박스 테스팅 : 명세를 기반으로 하며, 테스트 대상 외부에 있는 문서에서 테스트를 도출. 주요 목적 - 명세와 비교해 시스템의 동작을 확인하는 것.
• 화이트박스 테스팅 : 구조 기반이며, 시스템의 구현 또는 내부 구조에서 테스트를 도출. 주요 목적 - 테스트를 통해 내부 구조를 인수에 필요한 수준까지 충분히 커버하는 것.

2.2.3 확인 테스팅 및 리그레션 테스팅

일반적으로 컴포넌트나 시스템을 변경하는 이유는 새로운 기능을 추가해 개선하거나 결함을 제거해 수정하기 위함이다. 이때는 테스팅에 확인 테스팅과 리그레션 테스팅을 추가할 필요가 있다.

▶ 어떤 테스트 레벨이라도 해당 레벨에서 결함을 수정하거나 변경을 적용한 경우, 테스트 대상에 대한 확인 테스팅과 리그레션 테스팅이 필요하다.

2.3 유지보수 테스팅

유지보수에는 여러 범주가 있다. 문제를 수정하기 위한 유지보수, 환경 변화에 적응, 성능 또는 유지보수성을 개선하기 위한 것도 있기 때문에 유지보수는 계획된 릴리스/배포 또는 계획되지 않은 릴리스/배포 모두와 연관돼 있다.
운용환경에서 시스템의 변경사항을 테스트하는 것에는 변경 구현의 성공을 검증하는 것과, 변경되지 않은 시스템 영역(보통은 시스템 대부분)에서 발생할 수 있는 리그레션을 확인하는 작업이 모두 포함된다.

▶ 유지보수 테스팅의 범위는 일반적으로 "변경의 리스크 수준, 기존 시스템의 크기, 변경사항의 크기"에 따라 달라진다.

< 유지보수와 유지보수 테스팅의 계기 >

• 계획된 개선사항, 수정을 위한 변경, 핫픽스와 같은 수정사항.
• 운영 환경의 업그레이드나 마이그레이션 하는 경우, 변경된 소프트웨어뿐만 아니라 새로운 환경 관련 테스트가 필요할 수 있으며, 다른 애플리케이션의 데이터를 유지보수 중인 시스템으로 마이그레이션 할 때, 데이터 변환 테스트가 필요할 수 있다.
• 애플리케이션의 수명이 다하는 등의 단종. 시스템을 단종할 때 데이터 보존 기간이 길면 데이터 보관 테스팅이 필요할 수 있다. 보관기간 중 데이터가 필요한 경우를 대비해, 보관 이후 복원 및 복구 절차 테스팅이 필요할 수 있다.