[Study] CSTS 2장 - 테스트 분류 및 테스팅 방법

테스트 분류

소프트웨어 테스트

테스트 레벨, 테스트 유형, 테스트 설계 기법에 따라 다양하게 분류된다.

위 3가지의 테스트는 각각의 독립적인 기준이 있다.

---

비기능 테스트

테스트 유형에서 기능 테스트를 제외한 성능, 신뢰성, 보안 테스트 등을 말한다.

---

테스트 레벨에 의한 분류

테스트 레벨에 따라 컴포넌트, 통합, 시스템, 인수 테스트로 분류된다.

 
테스트 레벨

테스트 기법	설명
컴포넌트 / 단위 테스트	시스템을 구성하는 단위 모듈을 테스트 대상으로개별 단위 모듈을 독립적으로 테스트한다.
통합 테스트	시스템을 구성하는 단위 모듈들이 정확히 통합되었는지에 대한 초점과 시스템 내부 구성 모듈과의 관계를 정의한 구조설계 명세서를 바탕으로 테스트가 진행된다.
시스템 테스트	전체 시스템을 테스트 대상으로 테스트가 진행된다. 요구사항 명세서에 명시된 방식 대로 시스템이 작동하는지 확인하는데 초점을 둔다.
인수 테스트	전체 시스템을 하나의 단위로 본다. 고객/사용자의 관점에서 고객이 기대하는 방식으로 소프트웨어가 동작하는지 확인한다.

 
테스트는 컴포넌트 → 통합 → 시스템 → 인수 테스트 순대로 진행된다.
각 테스트는 개발의 각 단계를 기준으로 진행된다.

예시)

컴포넌트 테스트

단위 구성 요소 (함수, 클래스, 컴포넌트 등)에 대한 상세 설계를 기준으로 구현된 단위를 테스트한다.

 

통합 테스트

아키텍처 설계를 통해 결정된 단위 간의 관계(호출 등)를 기준으로 통합된 단위를 테스트한다.

 

시스템 테스트 및 인수 테스트

각각 요구 분석과 고객, 사용자의 필요, 기대를 기준으로 테스트를 수행한다.

---

테스트 유형에 의한 분류

테스트를 통한 소프트웨어의 동작 및 특성에 대한 기준은 요구사항 명세서에 정의된다.
요구사항 명세는 기능 요구사항과 품질 요구사항을 포함한다.

 
유형 테스트

기능 테스트와 각각의 비기능 테스트를 통칭한다.

---

테스트 유형

테스트 유형	설명
기능 테스트	기능 요구사항 측면의 결함 검출 및 충족 여부 확인을 목적으로 한다. 모든 테스트 수준(컴포넌트, 통합, 시스템, 인수 테스트)에서 진행된다.
비기능 테스트	성능, 보안성, 신뢰성 등 품질 요구사항 측면의 결함 검출 및 충족 여부 확인을 목적으로 한다. 일반적으로 시스템 테스트와 인수 테스트 수준에서 진행된다.

 
ISO 25010 품질 모델

주특성	부특성
기능 적합성	완전성, 정확성, 타당성
사용성	타당성 식별력, 학습성, 운영 용이성, 사용자 오류 보호, 사용자 인터페이스 미학, 접근성
성능 효율성	시간 행동, 자원 활용성, 수용성
호환성	공존성, 상호운영성
신뢰성	성숙성, 가용성, 장애 허용성, 회복 가능성
보안성	기밀성, 무결성, 부인방지, 책임성, 진본성
유지보수성	모듈성, 재사용성, 분석성, 변경 용이성, 테스트 용이성
이식성	적응성, 설치 용이성, 대치 용이성

---

테스트 설계 기법에 따른 분류

정적 테스트

테스트 대상을 실행하지 않는 방식이다.

대표적으로 리뷰, 정적분석이 있다.

리뷰

다양한 산출물에 존재하는 결함을
검출 및 프로젝트 진행 상황을 점검하기 위한 활동으로
전문가 그룹이 수행한다.
 

순서

1) 경영진 준비
↓
2) 리뷰 계획
↓
3) 리뷰 절차 개요 설명 
↓
4) 작업
↓
5) 작업물 개요 설명
↓
6) 개별 준비
↓
7) 그룹검토
↓
8) 재작업
↓
9) 후속 작업
 

목적 및 구체적인 수행 방법에 따라

"관리 리뷰, 기술 리뷰, 인스펙션, 워크쓰루, 감사"로 구분된다.

 
정적 테스트 - 리뷰 유형

리뷰유형	설명
관리 리뷰	프로젝트 진행 상황에 대한 검토를 바탕으로 일정, 인력, 범위 등에 대한 통제 및 의사 결정을 지원한다.
기술 리뷰	정의된 계획 및 명세를 준수하고 있는지에 대한 검토를 수행한다.
인스펙션	문제를 식별하고 문제에 대한 올바른해결을 검증한다.
워크쓰루	문제를 식별하고 더 나아가서 대안 조사, 개선 활동, 학습 기회 제공을 수행한다.
감사	객관적 표준과 규제에 대한 준수를 독립적으로 평가한다.

---

정적분석

산출물(ex. 소스 코드)의 구조적 속성을 이용해
자동화된 방식으로 도구에 의해 수행된다.

리뷰 유형	설명
코딩표준	MISRA-C, MISRA-C++ 등의 코딩 표준에 대한 준수 여부 검사
복잡도 측정	사이클로매틱 복잡도 등, 프로그램의 복잡도 측정
자료 흐름 분석	프로그램 자료 흐름에 이상 존재 여부 분석

---

동적 테스트

테스트 대상을 실행해서 결함을 검출하는 방법이다.
적절한 입력값, 테스트 케이스를 결정해야 한다.

테스트를 통해서 확인하고자 하는 상황을 어떤 방법으로 결정하냐에 따라
명세 기반 테스트, 구조 기반 테스트, 경험 기반 테스트로 분류된다.

---

명세 기반 테스트와 구조 기반 테스트

명세 기반 테스트

소스코드를 참고하지 않고 테스트 케이스를 결정한다.
동등 분할, 분류 트리 기법, 경곗값 분석, 신택스 테스트, 조합 테스트,
상태 전이 테스트, 인과 그래핑, 결정표 테스트, 시나리오 테스트

ex)

임의 입력 값 생성 후 테스트 하는 임의 테스트 방법도

소스 코드를 이용하지 않기 때문에 명세 기반 테스트라고 볼 수 있다.

구조 기반 테스트

구현된 소스 코드를 참고해서 테스트 케이스를 결정한다.
문장, 결정, 조건 테스트, 결정/조건 테스트,
다중 조건 테스트, 변형조건/결정 테스트(MCDC), 기본 경로 테스트

ex)

소스 코드의 특정 문장 또는 특정 경로를 실행하기 위한 입력값을 결정한다면,

이 테스트는 구조 기반 테스트라고 볼 수 있다.

경험 기반 테스트

기존의 테스트 경험, 테스트 대상이 되는 시스템 및 해당 도메인에 대한
경험 등을 바탕으로 수행하는 테스트 방법을 일컫는다.

---

오류 추정

개발자가 범할 수 있는 실수를 추정하고

이에 따른 결함이 검출되도록 테스트 케이스를 설계하는 방법이다.

특정 테스트 대상이 주어진다면, 테스터의 경험과 직관을 바탕으로

개발자가 범 할 수 있는 실수들을 나열하고,
해당 실수에 따른 경함을 노출하는 테스트를 수행하는 것이다.

 

동등 분할 및 경곗값 분석 같은 명세 기반 테스트 방법과 함께 사용될 수 있다.

 

일반적으로 예상되지 않는 상황이 사용자 입력값으로

적절히 처리되고 있는지 확인할 때 유용하게 사용될 수 있다.

오류 추정은 매우 직관적이다.
상황에 따라 적합한 방식으로 수행된다.
일반화된 기법과 절차를 정의하기에는 어렵다.
 
기본 아이디어

발생할 수 있는 오류 상황을 나열하는 것에서 시작된다.

ex)

일반적으로 특별히 처리해야 하는 0 값을 미처리 한 오류 사황이 발생할 수 있는데

가변적인 크기의 입력에서 특정 값을 검색하는 함수가 있을 때.

'입력 크기가 0인 경우'와 '일치하는 값을 발견하지 못한 경우'에 대한 오류 상황을 추정하고 이를 테스트할 수 있다.

오류 추정의 가장 효과적인 방법

오류가 검출된 대표적인 사례를 이용하는 것이다.

ex)

입력 목록의 크기가 0일 때

입력 목록이 오직 하나의 데이터만 가지고 있는 경우

입력 목록이 모두 동일한 데이터를 가지고 있는 경우

 입력 목록이 모두 정렬이 되어 있는 경우 

오류 추정 기법 예시

상황	설명
필수 입력	필수 입력 항목인 경우 값이 입력되지 않는 상황을 테스트한다.
입력 항목의 길이	입력 항목의 길이에 제약이 있는 경우, 더 작거나 긴 항목이 입력되는 상황을 테스트한다. ex) 주빈번호 앞자리는 6자리가 되어야 한다....
입력 항목의 형식	입력 항목에 대한 형식을 위반하는 상황을 테스트한다. ex) 생년월일 형식 : YY/MM/DD
입력값의 명시적 제약사항	입력 항목의 값에 대해 명시적 범위를 위반하는 상황을 테스트한다. ex) YY: 00- 99 ~~
입력값의 묵시적 제약사항	입력 항목의 값이 명시되지 않았는데 상식적으로 가정되는 범위를 위반하는 상황을 테스트한다. ex) YY: 19 이하의 값....

 

---

탐색적 테스트

사전에 구체적으로 테스트 케이스를 설계해서 기록하고

이를 바탕으로 테스트를 수행하는 방식이 아닌,
테스트 대상에 대한 이해, 테스트 케이스 설계,

테스트 실행을 병행하는 방식이다.

이 테스트의 결과를 바탕으로

다음 테스트를 결정한다.

쉽게 이야기해서.. 테스트 대상에 대한 이해를 바탕으로 즉석에서 테스트 케이스를 결정한 후, 문서화 없이 해당 테스트를 바로 수행한다.

 

테스트를 위한 문서 작성 (X)

테스트 계획서 작성 (선택)
체계적인 이론과 방법을 바탕으로 테스트 설계를 수행해 

사전에 테스트 명세서(테스트 설계 명세서, 테스트 케이스 명세서, 테스트 절차 명세서)를 작성하는 대신,
테스터의 경험과 직관을 바탕으로 즉석에서 테스트 케이스를 결정하고 바로 수행한다.

 

테스터는 자신이 원하는 방식으로 테스트를 수행하면서

테스트 대상이 어떻게 동작하는지
어떠한 기능이 동작하는지 파악해 나아간다.
따라서
탐색적 테스트의 효과는 테스터의 지식에 의존한다.

ex)

테스트를 수행하는 과정에서 파악하게 되는 테스트 대상에 대한 이해의 정도,

테스트 대상에 대한 사전 경험, 방생할 가능성이 있는 결함과 테스트 대상에 대한

위험 요소에 대한 이해 등이 중요한 영향을 미치게 된다.

테스트에 사용하는 자동화 도구를 통해 테스트 로그 및 테스트 결과 등이 자동으로 생성될 수 있다.
테스트해야 하는 세부 피처를 명확히 식별하고 의사소통하기 위한 테스트 차터를 간략히 작성할 수 있다.

차터에는 테스트하고자 하는 세부 피처를 비혹해 검출된 결함과 관련하여 추후 해결이 필요한 이슈 등을 기록한다.

애자일 방법을 사용하는 웹 응용 시스템의 테스트에 적합한 방법이다.
이런 유형의 시스템은 개발 주기가 매우 짧기 때문에
세부적인 테스트 명세서를 개발하고 관리할 시간이 충분치 않다

탐색적 테스트의 가이드라인이 없다면... 

 

단점

초기에 시스템에 대한 정보 및 이해가 부족해서
시스템 이곳저곳 탐색하는데 과도한 시간을 사용할 위험이 있다.
여러 명 또는 팀이 이 테스트에 참여할 경우에 동일한 기능을 중복해서 테스트할 위험이 있다.

---

테스팅 방법

리그레션 테스트

변경 후에 수행되는 테스트이며, 
소프트웨어에 가해진 변경이 의도하지 않게 결함을 만들지 않았는지,
시스템이 기존의 요구 사항을 충족하는지 검증하기 위해 수행된다.
 

리그레션 테스트의 다양한 전략

전략, 선택적 리그레션 테스트 전략, 테스트 최소화 전략,

테스트 우선 순위화 전략이 대표적인 예이다.
소프트웨어가 변경된다면,

각 레벨 테스트 순대로 컴포넌트, 통합, 시스템 테스트

각 레벨마다 리그레션 테스트를 수행한다.

---

소프트웨어 생명 주기 모델과 테스트

소프트웨어 생명 주기

소프트웨어 개발 체계의 추상적 표현이다.
순차적, 병렬적 일련의 단계로 구성된다.

ex) 소프트웨어 생명주기

요구 사항을 수집 및 문제 이해, 분석 단계부터 시작해서 설계단계 및 시스템을 구성하는 모듈을 구현하는 단계를 거친다.

 

테스트는 이런 소프웨어 생명 주기 모델의 특성을 고려해 수행되어야 한다.

 

ex) 소프트웨어 생명주기 모델의 특성을 고려한 수행 예시

순차적 생명 주기 모델의 경우 테스트는 구현이 완료된 시점에 1회만 수행된다.

진화형 모델과 애자일 모델과 같이 반복적이고 점직적인 모델에서는 테스트도 반복, 점진적으로 수행된다.

순차적 생명 주기 모델

구현이 완료된 후 테스트가 시작된다.
테스트를 수행할 때 요구 사항 명세부터 구조 설계 및 상세 설계 산출물을 비롯해
소스 코드에 이르기까지 필요한 모든 자료가 존재한다는 이점이 있다.
이때,
검출된 결함을 해결하는 데 많은 비용과 시간이 소요될 가능성이 크다.

 

V-모델

폭포수 모델과 달리 개발 시작과 함께 테스트도 시작된다.
각 개발 단계에서 발생하는 결함을 검출할 수 있는 테스트 레벨이 존재한다.
 
요구 분석 단계에서 시스템 테스트를 위한

테스트 계획 설계 및 테스트 케이스와 절차를 도출하고,
구조 설계 단계에서 통합테스트 테스트 계획 수립 및 테스트 케이스를 도출한다.
 
동적 테스트와 더불어 개발 산출물에 대한 정적 테스트도 수행한다.
요구사항 명세서, 구조 설계 명세서, 상세 설계 명세서,

소스 코드 등에 대한 리뷰, 정적 분석을 수행해 결함을 검출한다.
 

진화적 개발 모델

이터레이션, 점진적인 방식으로 개발을 진행한다.
시스템의 구성요소 중 핵심 부분을 개발 후 각 구성 요소와 추가 요구사항을
여러 이터레이션을 통해 개선하고 발전시켜 최종 완성품을 개발한다.
 
수행하는 각 이터레이션마다 테스트 수행 계획을 작성하며 이에 따라 테스트를 수행한다.
각 이터레이션은 순차적 모델처럼 요구사항 분석, 설계, 구현, 테스트와 같은 단계로 구성되고,
각 개발 단계에서 테스트 관련 프로세스가 수행된다.
 

애자일 개발 방법론

진화적 개발 모델처럼 반복적, 점진적 개발 접근 방식을 따른다.
애자일 방법론은 일반적으로 테스트 주도개발을 적용한다.
TDD 프로그램에 대한 테스트 케이스를 먼저 작성 후
이 테스트 케이스를 통과하는 실제 프로그램의 코드를 나중에 작성하는 방식이다.
 
TTD와 더불어 애자일 개발에서 중요한 실천 규칙인 지속적 통합이 있다.
이는 어느 한 시점에서 이루어지는 것이 아닌 계속해서 통합을 수행하는 것을 말한다.

---

위험 기반 테스트

피처에 대한 위험 분석을 바탕으로 테스트에 대한 계획과 설계,
실행 등의 활동을 수행하는 것을 위험 기반 테스트라고 한다.

 

테스트 접근방법 뿐 아닌 범위를 결정할 때도 주어진 비용 및 일정을 고려해야 한다.
테스트 비용의 범위 내에서 단위테스트, 통합 테스트 및 시스템 테스트의 수행 수준이 결정된다.
단위 테스트가 수행될 대상이 되는 모듈을 결정하고, 시스템 테스트를 수행할 때

테스트 될 기능 및 비기능적 특성, 피처도 한정할 수 있다.

테스트 대상을 결정하고 선택된 테스트 대상에 대한 테스트 범위를 

전체 시스템의 일부로 한정시키는 것은 테스트 비용을 줄일 수 있지만, 

테스트되지 않은 부분에서 결함이 발생할 가능성이 커지고
소프트웨어 품질에 악영향을 미칠 수 있다.. 

테스트 대상 및 범위를 결정할 때
테스트 미수행에 따른 위험을 고려해야 한다.
테스트가 수행되지 않았다고 해도 그에 따른 위험 수준이 높은 것은
테스트 대상에 반드시 포함해야 한다..

---

모델 기반 테스트

모든 명세 기반 테스트는 테스트 대상에 대한

기대 동작을 표현하는 모델을 이용한다.

이런 모델은 자연어로 표현된 형식이거나 상태 전이도 또는 UML 다이어그램과 같은 시각적인 표현 방식이 될 수 있다.
의사 결정표와 같은 표 형태도 가능하다.

 

기존의 테스트는 모델을 이용해도 보통 수작업으로

테스트 입력/출력을 결정하는 방식만 제공했는데,
모델 기반 테스트는 테스트 절차를 수행하는 정보가

자동으로 추출될 수 있을 정도로 정형화되고

상세한 모델을 바탕으로 한다.
 
모델을 바탕으로 테스트 계획을 수립하고, 테스트 케이스,

테스트 절차, 테스트 입력 및 예상 결과등을 결정한다.
 
테스트 계획에서 테스트 종료까지

대부분의 활동을 자동화할 수 있다는 이점이 있다.
모델 자체에 존재할 수 있는 다양한 유형의 문제를

이른 시점에 식별하는 방법으로 개발 단계 산출물의 결함을

검출할 수 있다는 이점도 있다.
 
장애가 발생했을 때 많은 비용이 유발되는

자동차, 의료 등 안전 필수 소프트웨어를 대상으로 수행되고 있다.
 
모델이 구축된 후에는 자동화를 통해

효율적인 테스트를 수행할 수 있다는 이점이 있다.
 
모델 기반 테스트의 근간이 되는 모델, 정형적,

상세한 테스트 모델을 구축하는 비용이 추가되는 단점이 있다.
 
테스트 대상의 동작에 대한 상세한 모델링에는 의사결정표,
UML 상태 다이어그램, UML 액티비티 다이어그램을 비롯한

정형적 표현법을 사용할 수 있다.