[ISTQB] 테스트 레벨 비교

다시 자격증의 늪에 빠져 버린 나.. 황금연휴에 자격증 공부라니!!!! ㅠㅠ

ISTQB를 공부 하던 도중 실버러스에는 글로만 나열이 되어 있어 비교하기가 어려워 표로 정리해봄.

 

테스트 레벨이란 함꼐 분류되고 관리되는 테스트 활동의 집합을 지칭.

 

 

	컴포넌트 테스팅	통합테스팅	시스템 테스팅	인수 테스팅
목적	1. 리스크완화 2. 컴포넌트의 기능,비기능 동작이 설계 및 명세와 일치하는지 여부 판단 3. 컴포넌트에 대한 자신감 획득 4. 컴포넌트에 존재하는 결함 발견 5. 결함 전이 방지	1. 리스크 완화 2. IF 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단 3. IF품질에 대한 자신감 획득 4. 결함 발견 5. 결함 전이 방지	1. 리스크 완화 2. 시스템의 기능 ,비기능 동작이 설계 및 명시된 대로 이루어지는지 검증 3. 완성된 시스템이 기대한 대로 동작하는지 확인 4. 전체 시스템 품질에 대한 자신감 획득 5. 결함 발견 6. 전이 방지	1.전체전체 시스템  품질에 대한 자신감 획득 2. 완성된 시스템이 기대한 대로 동작하는지 확인 3. 시스템의 기능 , 비기능 동작이 명시된 대로 동작하는지  검증
베이시스	1.상세 설계 2. 코드 3. 데이터 모델 4. 컴포넌트 명세	1. sw 및 시스템 설계 2. 시퀀스 다이어 그램 3. IF 및 통신 프로토콜 명세 4. 유스케이스 5. 컴포넌트나 시스템 레벨의 아키텍처 6.워크 플로우 7. 외부 IF 정의서	1.sw 및 시스템 요구사항 명세 2. 리스크 분석 보고서 3. 유스케이스 5. 에픽과 사용자 스토리 6. 상태 다이어그램 7. 시스템 및 사용자 메뉴얼	1. 비즈니스 프로세스 2. 사용자 또는 비즈니스 요구사항 3. 규제,법적 계약, 표준 4. 유스케이스 및 사용자 스토리 5. 시스템 요구사항 6. 시스템 또는 사용자 문서 7. 설치 절차 8. 리스크 분석 보고서 9. 백업 및 복원 절차 10. 긴급 복구 절차 11. 비기능 요구사항 12. 운영 문서 13. 배포 및 설치 지침 14. 성능 목표 15. 데이터베이스 패키지 16. 보안 표준 또는 규정
테스트 대상	1.컴포넌트,단위,모듈 2. 코드 및 데이터 구조 3. 클래스 4. 데이터 베이스 모듈	1. 서브시스템 2. 데이터베이스 3. 인프라 4. 인터페이스 5.APIs 6. 마이크로 서비스	1. 애플리케이션 2. 하드웨어/sw 시스템 3. 운영 시스템 4. 테스트 대상 시스템 5. 시스템 설정과 설정 데이터	1. 테스트 대상 시스템 2. 시스템 설정과 설정 데이터 3. 완전히 통합된 시스템의 비즈니스 프로세스 4. 복원 시스템이나 비즈니스 연속성 및 복구 테스팅을 위한 핫 사이트 5. 운영 및 유지보수 프로세스 6. 양식 7. 보고서 8. 기존 및 전환된 생산 데이터
결함 장애	1. 잘못된 기능 2. 데이터 흐름 문제 3. 잘못된 코드 및 논리	- 컴포넌트 통합 테스팅 일경우   1. 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩 2. 잘못된IF 콜순서나 타이밍 3. IF불일치 4. 컴포넌트 간의 통신장애 5. 컴포넌트 간의 통신 실패처리 누락 및 오류 6. 컴포넌트 간 주고 받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정   -시스템 통합 테스팅 1. 시스템 간의 일관적이지 않은 메시지 구조 2. 잘못된 데이터 ,누락된 데이터, 잘못된 데이터 인코딩 3. 시스템 간의 통신 장애 4. 시스템 간의 통신 실패 처리 누락 및 오류 5. 시스템 간 주고 받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정 6. 필수 보안 규정 준수 실패	1. 잘못된 연산 2. 시스템의 잘못되거나 예상치 못한 기능/비기능 동작 3. 시스템 내 잘못된 제어 및 데이터 흐름 4. 엔드 투 엔드 기능 작업 수행 실패 5. 시스템 환경에서 시스템의 정상 동작 실패 6. 시스템 및 사용자 메뉴얼대로의 시스템 동작 실패	1. 비즈니스나 사용자 요구사항을 충족하지 못하는 시스템 워크플로우 2. 잘못 구현된 비즈니스 규칙 3. 계약 혹은 규제 요구사항을 충족하지 못하는 시스템 4.보안 취약성, 성능 효율성 저하, 지원 대상 플랫폼상 잘못된 운영과 같은 비기능 장애
구체적 접근법과 역할	코드를 작성한 개발자가 일반적으로 수행	컴포넌트 통합 테스팅은 개발자의 책임인 경우가 많고, 시스템 통합 테스팅은 일반적으로 테스터의 책임 .	독립적인 테스터가 수행	고객, 비즈니스 사용자, 제품 소유자, 시스템 운영자가 담당하며 기타 이해관계자가 참여 하는 경우도 있다.

 

* 모든 테스트 레벨은 기능,비기능 특성, 구조적 속성을 커버 할 수 있다.

 

* 인수 테스팅의 형태

  1. 사용자 인수 테스팅

     - 일반적으로 실제 환경에서 예정된 사용자가 사용하기에 얼마나 적합한지 확인하는데 관심을 둔다.

       가장 중요한 목적은 품질의 자신감 획득

  2. 운영 인수 테스팅

     - 운영자 또는 시스템 관리자가 시스템을 정상적으로 유지 할 수 있다는 자신감을 획득 하는데 목적을 둔다,

     - 포함되는 것? 백업 및 복원 테스팅, 설치,삭제,업그레이드, 긴급 복구, 사용자 관리, 유지보수 작업 데이터 로딩 및

                         이관 작업, 보안 취약점 확인, 성능 테스트

  3. 계약 및 규제 인수 테스팅

     - 계약이나 규제 준수에 대한 자신감의 획득이 목적

     - 사용자나 독립적인 테스터가 수행 하는 경우가 많다.

  4. 알파 및 베타 테스팅

     - 기존 혹은 신규 사용자, 고객, 운영자 등으로 부터 피드백을 받기 원하는 상용 sw 개발자가 사용하는 경우가 많다.

     - 알파 테스팅은 신규 혹은 기존 고객이나 운영자, 독립적 테스트팀이 수행 

     - 베타 테스팅은 신규 혹은 기존 고객이나 운영자가 자신의 환경에서 수행

     - 일반적인 조건과 운영 환경에서 사용해 자신의 목적을 완수 할 수 있다는 자신감을 획득

     - 시스템을 사용할 조건 및 환경에 관련된 결함의 발견