[ISTQB] 제2장 소프트웨어 개발 수명주기와 테스팅 (2)

2.2 테스트 레벨

 

테스트 레벨이란?

함께 분류되고 관리되는 테스트 활동의 집합

​

​

테스트 레벨의 분류

개정전(3.0)

- 컴포넌트 테스팅=단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅

개정판(4.0) 

​- 컴포넌트 테스팅, 컴포넌트 통합 테스팅, 시스템 테스팅, 시스템 통합 테스팅, 인수 테스팅 

 

테스트 레벨 분류 기준 특성

· 구체적인 목적

· TC 도출시 참고하는 테스트 베이시스

· 테스트 대상

· 결함과 장애

· 구체적인 접근법과 역할

​

---

2.2.1 컴포넌트 테스팅

Component Testing

​

-> 단위, 모듈 테스팅이라고도 함

-> 개별 컴포넌트에 초점을 둠

​

1.1 컴포넌트 테스팅의 목적

· 리스크 완화

· 컴포넌트의 기능/비기능 동작이 설계와 일치하는지 판단

· 컴포넌트 품질 수준에 대한 자신감 획득

· 다음 단계로의 결함 전이 방지

​

점진적 반복적 개발 모델에서..

· 수정으로 인해 기존의 컴포넌트가 손상되지 않았다는 확신을 얻는데, 자동 컴포넌트 리그레션 테스트가 중요하다.

💡 리그레션 테스트

· 자동화 테스트

​

컴포넌트 테스팅은..

· 개별적으로 이루어지는 경우가 많음

· 목 오브젝트(mock object), 서비스 가상화(service virtualization), 하네스(harness), 스텁(stub), 드라이버(driver) 등이 필요할 수 있다.

· 기능(연산의 정확도), 비기능 특성(메모리 누수 탐지), 구조적 속성(결정 테스팅) 등을 커버할 수 있다.

​

💡 용어 정리

· 목 오브젝트 : 모의객체, 실제 사용 모듈을 '흉내'내는 '가짜'모듈

· 테스트 하네스 : 테스트를 수행하기 위해 필요한 스텁과 드라이버로 구성된 테스트 환경으로 단위테스트 및 통합테스트에 주로 이용됨

· 스텁 : 하향식 테스트 시 상위 모듈 개발 이후 하위 세부 모듈 제작전 하위 모듈 처럼 기능을 흉내 내는 임시 모듈 = 껍데기/뼈대 

· 드라이버 : 상향식 테스트 시 하위 모듈 개발 이후 하위 프로그램과 통합성을 테스트 하기 위해 임시적으로 만든 메뉴기능의 상위 모듈

​

1.2 컴포넌트 테스팅의 테스트 베이시스

컴포넌트 테스팅의 테스트 베이시스로 사용할 수 있는 작업 산출물

· 상세 설계

· 코드

· 데이터 모델

· 컴포넌트 명세

​

1.3 컴포넌트 테스팅의 테스트 대상

· 컴포넌트, 단위, 모듈

· 코드 및 데이터 구조

· 클래스

· 데이터베이스 모델

​

1.4 컴포넌트 테스팅의 대표적인 결함과 장애

· 잘못된 기능

· 데이터 흐름 문제

· 잘못된 코드 및 논리

​

1.5 컴포넌트 테스팅의 구체적인 접근법과 책임

· 일반적으로 컴포넌트 테스팅은 코드를 작성한 개발자가 수행

· 개발자는 컴포넌트 개발과 결함 발견 및 수정을 번갈아가며 진행

· 컴포넌트 코드 작성 > 테스트 작성 > 실행

· 애자일 개발에서는 컴포넌트 테스트 케이스를 먼저 작성하는 경우도 있다

​

​​

---

2.2.2 통합 테스팅

Integration Testing

​

2.1 통합 테스팅의 목적

· 리스크 완화

· 인터페이스의 기능/비기능 동작이 설계와 일치하는지 판단

· 인터페이스 품질 수준에 대한 자신감 획득

· 결함 발견 및 다음 단계로의 결함 전이 방지

​

2.2 통합 테스팅의 레벨 분류

(1) 컴포넌트 통합 테스팅

· 컴포넌트 간의 상호운용성과 인터페이스에 초점

· 컴포넌트 테스팅 후 수행, 자동화하는 경우가 다수

 

(2) 시스템 통합 테스팅

· 시스템, 패키지, 마이크로 서비스(microservice) 간의 상호운용성과 인터페이스에 초점

· 기존 컴포넌트와의 상호운용 혹은 인터페이스를 커버하기도 함

​

2.3 통합 테스팅의 테스트 베이시스

· 소프트웨어 및 시스템 설계

· 시퀸스 다이어그램(sequence diagram)

· 유스케이스

· 컴포넌트나 시스템 레벨의 아키텍처

· 워크플로우(workflow)

· 외부 인터페이스 정의서

​

2.4 통합 테스팅의 테스트 대상

· 서브 시스템(subsystem)

· 데이터베이스(database)

· 인프라(infrastructure)

· 인터페이스(interfaces)

· APIs(Application Programming Interface)

· 마이크로서비스(microservices)

​

2.5 통합 테스팅의 일반적인 결함과 장애

(1) 컴포넌트 통합 테스팅

· 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩

· 잘못된 인터페이스 콜 순서나 타이밍

· 인터페이스 불일치

· 컴포넌트 간 통신 실패처리 누락 및 오류

· 컴포넌트 간 주고 받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정

· 컴포넌트 간 통신 장애

 

(2) 시스템 통합 테스팅

· 시스템 간 일관적이지 않은 메시지 구조

· 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩

· 인터페이스 불일치

· 시스템 간 통신 장애

· 시스템 간 통신 실패 처리 누락 및 오류

· 시스템 간 주고 받는 데이터의 의미, 단위, 겅계에 대한 잘못된 가정

· 필수 보안 규정 준수 실패

​

2.6 통합 테스팅의 구체적인 접근법과 책임

· 통합 자체에 집중 -> 개별 모듈의 기능에 초점을 맞추면 안됨

​

· 컴포넌트 통합 테스팅은 개발자의 책임

· 시스템 통합 테스팅은 테스터의 책임

· 통합은 한번에 모든 것을 통합하지 않고, 가능한 점진적으로 진행해야한다.

· 통합 범위가 넓으면 장애를 특정 컴포넌트나 시스템으로 격리하기 어려워지고, 이는 개발의 리스크와 문제 해결 시간을 증가시킬 수 있다.

​

💡 시스템 간의 상호작용에 대한 테스트 / 컴포넌트 간의 인터페이스를 테스트 : 통합테스팅

💡 V-모델에서 통합테스팅은 하위 레벨에 속한다. (단위 > 통합 > 시스템 > 인수 )

​​

 

---

​​

2.2.3 시스템 테스팅

 

System Testing

​

3.1 시스템 테스팅의 목적

· 리스크 완화

· 시스템의 기능/비기능 동작이 설계 및 명시대로 이루어지는지 검증

· 전체 시스쳄 품질 수준에 대한 자신감 획득

· 결함 발견 및 다음 단계로의 결함 전이 방지

​

3.2 시스템 테스팅의 테스트 베이시스

· 시스템 및 소프트웨어 요구사항 명제 (기능/비기능)

· 리스크 분석 보고서

· 에픽(epic)과 사용자 스토리

· 시스템 동작 모델

· 상태 다이어그램

· 시스템 및 사용자 매뉴얼

​

스크럼 구성요소 : 에픽 + 스토리 + 태스크

epic : 여러번의 스프린트를 거쳐 완료되는 정도의 작업량을 가진 업무, 개략적인 기능설명만 있음 스토리 : 사용자의 입장에서 필요한 내용이 일상적 언어로 기술됨. 최소 단위의 요구사항

​

3.3 시스템 테스팅의 테스트 대상

· 애플리케이션

· 하드웨어/소프트웨어 시스템

· 운영 시스템

· 테스트 대상 시스템(SUT, System Under Test)

· 시스템 설정과 설정 데이터

​

3.4 시스템 테스팅의 일반적인 결함과 장애

· 잘못된 연산

· 시스템의 잘못되거나 예상치 못한 기능/비기능 동작

· 시스템 내 잘못된 제어 및 데이터 흐름

· 엔드-투-엔드 기능 작업 수행 실패

· 시스템 환경에서 시스템의 정상 동작 실패

· 시스템 및 사용자 매뉴얼대로의 시스템 동작 실패

​

​

3.5 시스템 테스팅의 구체적인 접근법과 책임

· 기능/비기능 모두의 측면에서 엔드-투-엔드 동작에 관심을 가진다.

· 시스템 특성에 가장 잘 맞는 기법을 사용해야함

· 일반적으로 독립적인 테스터가 수행

· 명세 결함은 시스템 동작에 대한 이해 부족이나 의견 불일치를 가져올 수 있다.

ㄴ 거짓 양성이나 거짓음성의 원인이 될 수 있다.

ㄴ 거짓양성 : 실제 음성인데 양성이라 나옴(시간 허비)

ㄴ 거짓음성 : 실제 양성인데 음성이라 나옴(결함발견효과 감소)

​

💡 시스템 테스트 종료 조건 : open되어 있는 심각한 결함이 없음/모든 기능 및 비기능 테스트를 완료함

💡 실제 시스템과 유사하게 구성한 환경에서 수행 : 시스템테스팅

 

---

2.2.4 인수 테스팅

Acceptance Testing

​

4.1 인수 테스팅의 목적

· 전체 시스템에 대한 ‘자신감’ 획득

· 시스템의 기능/비기능 동작이 명세대로 동작하는지 검증

· 결함 발견이 목적이 아닌 경우가 많음

​

4.2 인수 테스팅의 형태

1. 사용자 인수 테스팅

· 실제 또는 시뮬레이견된 운영 환경에서 예정된 사용자가 사용하기에 얼마나 적합한지 확인

​

2. 운영 인수 테스팅

· 운영자 또는 시스템 관리 직원에 의해 수행

​

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

· 계약에 명시된 인수 조건을 가지고 수행

· 사용자나 독립적인 테스터가 수행

​

4. 알파 및 베타 테스팅

· 알파 테스팅 : 개발 조직의 현장에서 개발팀이 아닌 기존 고객이나 운영자, 독립적인 테스트팀이 수행

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

​

​

4.3 인수 테스팅의 테스트 베이시스

· 비즈니스 프로세스

· 사용자 또는 비즈니스 요구사항

· 규제, 법적 계약, 표준

· 유스케이스 및 사용자 스토리

· 시스템 요구사항

· 시스템 또는 사용자 문서

· 설치 절차

· 리스크 분석 보고서

​

​

4.4 인수 테스팅의 테스트 대상

· 테스트 대상 시스템

· 시스템 설정과 설정 데이터

· 완전히 통합된 시스템의 비즈니스 프로세스

​

​

4.5 인수 테스팅의 일반적인 결함과 장애

· 비즈니스나 사용자 요구사항을 충족하지 못하는 시스템 워크플로우

· 잘못 구현된 비즈니스 규칙

· 계약 혹은 규제 요구사항을 충족하지 못하는 시스템

· 보안 취약성, 많은 부하가 걸렸을 때 성능 효율성 저하, 지원 대상 플랫폼상에서의 잘못된 운영 등과 같은 비기능 장애

​

​

4.6 인수 테스팅의 구체적인 접근법과 역할

· 주로 고객, 비즈니스 사용자, 제품 소유자, 시스템 운영자가 담당

· 보통 마지막 테스트 레벨로 여겨지는 경우가 많지만, 항상 그렇지는 않다.

ㄴ 상용 소프트웨어 제품에 대한 인수 테스팅은 그것이 설치되거나 통합될 때 이루어진다.

ㄴ 신규 기능 개선 사항에 대한 인수 테스팅은 시스템 테스팅 전에 이루어질 수 있다.

ㄴ 반복적 개발에서는 인수 테스팅을 각 반복주기 중간 혹은 끝에 편성할 수 있다.

​

 

💡 인수 테스팅

- 키워드 : '확신'

- 예상된 대로 시스템이 동작하는지 확인하고, 요구사항이 맞는지 확신을 얻음. 결함을 발견하는 것이 주 목적은 아님

- 테스트 베이시스가 확보되는 개발 초기단계에서 시작한다. > 테스트 계획과 기초테스트를 수행 가능

- 반드시 '최종' 단계의 테스팅은 아님

- '사업적' 리스크에 집중해 테스트함

- 주로 사용자/고객이 테스트함

- 베이시스 : 사용자 요구사항 + 비즈니스 프로세스 등

​

💡 알파 테스팅

- 공장 인수 테스팅 (factory acceptance testing)

- 개발 조직 내의 잠재 고객이 수행

 

💡 베타 테스팅

- 사이트 인수 테스팅 (site acceptance testing)

- 사용자의 환경에서 고객/사용자가 수행

​

💡 어떤 기업이 시스템을 인수받아 사용하는 경우 필요한 것

- 인수 테스트 : 유지보수에 관련된 인수테스팅 '운영상의 인수 테스팅'

- 시스템 통합 테스트 : 시스템, 패키지 간의 상호운용성과 인터페이스에 초점

​

💡 인수 테스트 종료 조건 : 최종 사용자가 모든 비즈니스 알고리즘, 모든 핵심 경로와 동작을 테스트함

 

 

---

개정판(4.0 정리)

 

- 컴포넌트 테스팅

  - 테스트 하네스 또는 단위 테스트 프레임워크와 같은 구체적인 지원 수단이 필요한 경우가 많다.

  - 개발자가 자신의 개발 환경에서 수행한다.

 

- 컴포넌트 통합 테스팅:

  - 컴포넌트 간의 인터페이스와 상호 작용을 테스트하는 데 중점을 둔다.

  - 컴포넌트 통합 테스팅은 상향식, 하향식, 빅뱅 등 통합 전략 접근법에 따라 크게 달라진다.

 

- 시스템 테스팅

  - 엔드투엔드 (end-to-end) 동작에 대한 기능 테스팅과 품질 특성에 대한 비기능 테스팅을 포함하는 경우가

많다.

  - 실제 환경을 대변하는 테스트 환경에서 완성된 시스템으로 테스트하는 것을 선호하는 비기능 품질 특성도 있다(예: 사용성)

 

- 시스템 통합 테스팅:

   - 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는 데 중점을 둔다.

   - 가급적 운영 환경과 유사한 적절한 테스트 환경을 사용한다.

 

- 인수 테스팅

  - 밸리데이션과 배포할 준비, 즉 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는 데 중점을 둔다.

  - 주요 유형으로 사용자 인수 테스팅(UAT), 운영 인수 테스팅, 계약 및 규제 인수 테스팅, 알파 테스팅, 베타 테스팅 등이 있다.

 

 

 

---

Reference

https://m.blog.naver.com/PostList.naver?blogId=jing_new_&tab=1