[CSTS] 2장 테스트 분류와 테스팅 방법

2장 테스트 분류와 테스팅 방법

---

 

2.1 개요

---

• 다양한 테스트 관련 개념을 테스트 분류와 테스팅 방법으로 구분하여 설명한다.

 

 

2.2 테스트 분류

---

2.2.1 개요

• 소프트웨어 테스트는 테스트 레벨, 테스트 유형, 테스트 설계 기법에 따라서 분류할 수 있다.
• 3가지 기준은 각각 독립적인 기준이다.

[그림 1] 테스트 분류

분류	테스트 종류		설명
테스트 레벨	컴포넌트/단위 테스트		각각의 컴포넌트를 테스트한다.
	통합 테스트		컴포넌트 간의 인터페이스를 테스트한다.
	시스템 테스트		전체 시스템이 목적을 만족시키는지 테스트한다.
	인수 테스트		사용자의 요구사항을 만족하는지 확인한다.
테스트 설계	동적 테스트	명세 기반 테스트	명세를 바탕으로 테스트 케이스를 생성한다.
		구조 기반 테스트	프로그램 코드를 바탕으로 테스트 케이스를 생성한다.
		경험 기반 테스트	테스터의 경험을 기반으로 테스트 케이스를 생성한다.
	정적 테스트	리뷰	산출물에 존재하는 결함을 검출하거나 프로젝트의 진행 상황을 점검한다.
		정적 분석	자동화된 조구를 이용하여 산출물의 결함을 검출하거나 복잡도를 측정한다.
테스트 유형	기능 테스트		기능적 요구사항 측면의 결함 검출 및 충족 여부를 확인한다.
	비기능 테스트	기능 적합성 테스트	사용자의 요구사항을 만족하는 기능이 제공되는 정도를 테스트한다.
		성능 효율성 테스트	시스템의 응답시간이나 처리량을 테스트한다.
		호환성 테스트	다른 시스템과의 상호 연동 능력이나 공존성을 테스트한다.
		사용성 테스트	사용자가 이해하고 배우기 쉬운 정도를 테스트한다.
		신뢰성 테스트	규정된 조건/기간에 오동작 없이 수행하는 능력을 테스트한다.
		보안성 테스트	시스템의 정보 및 데이터를 보호하는 능력을 테스트한다.
		유지보수성 테스트	소프트웨어 유지보수의 용이성을 테스트한다.
		이식성 테스트	다양한 플랫폼에서 운영될 수 있는 능력을 테스트한다.

 

2.2.2 테스트 레벨에 의한 분류

테스트의 레벨에 따라서 컴토넌트(또는 단위) 테스트, 통합 테스트, 시스템 테스트 그리고 인수 테스트로 분류된다.

테스트 기법	설명
컴포넌트(Component)/ 단위(Unit) 테스트	단위 모듈을 독립적으로 테스트한다.
통합(Integration) 테스트	구조 설계 명세서를 바탕으로 단위 모듈들이 정확하게 통합되었는지 테스트한다.
시스템(System) 테스트	요구사항 명세서에 명시된대로 시스템이 동작하는지 테스트한다.
인수(Acceptance) 테스트	고객/사용자가 기대하는 방식으로 시스템이 동작하는지 테스트한다.

4개 레벨의 테스트는 일반적인 소프트웨어의 개발 단계와 밀접한 연관이 있다. 소프트웨어 개발 각 단계는 그에 상응하는 테스트 레벨이 있다. [그림 2]는 소프트웨어 개발 각 단계와 그에 상응하는 테스트 레벨을 표현한 것이다. 좌측의 개발 단계와 우측의 테스트 수준이 알파벳 'V' 형태를 이루므로 이를 V 모델이라고 부른다.

[그림 2] V 모델

 

2.2.3 테스트 유형에 의한 분류

기능 테스트와 각각의 비기능 테스트를 유형 테스트(Type test)라고 부른다.

• 기능(Functional) 테스트
  • 기능 요구사항에 중점을 둔 테스트
  • 모든 테스트 수준(컴포넌트·통합·시스템·인수 테스트)에서 진행
• 비기능(Non-functional) 테스트
  • 품질 요구사항에 중점을 둔 테스트
  • 시스템 테스트와 인수 테스트 수준에서 진행

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

 

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

테스트는 테스트 설계 기법에 따라서 정적 테스트와 동적 테스트로 분류된다.

• 정적 테스트
  • 리뷰
    소프웨어의 다양한 산출물에 존재하는 결함을 검출하거나 프로젝트의 진행 상황을 점검하기 위한 활동이다.
    
    

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

  • 정적 분석
    산출물(주로 소스 코드)의 구조적 속성을 이용하여 자동화된 방식으로 도구에 의해서 수행된다.
    

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

• 동적 테스트
  • 명세 기반 방법
    프로그램의 내부 논리 구조를 참조하지 않고 사용자의 요구 명세나 설계 정보 등을 이용하여 테스트 케이스를 개발한다.
  • 구조 기반 방법
    프로그램의 제어 흐름이나 자료 흐름 정보 등 프로그램의 내부 구조 정보를 기반으로 테스트 케이스를 설계하는 방법이다.
    구조적 테스트(Structural test), 화이트박스 테스트(White box test) 또는 글래스 박스 테스트(Glass-box test)라고도 한다.
    

    명세 기반 테스트	구조 기반 테스트
    동등 분할 분류 트리 기법 경곗값 분석 신택스 테스트 조합 테스트 상태 전이 테스트 인과 그래핑 결정표 테스트 시나리오 테스트	문장 테스트 결정 테스트 조건 테스트 결정/조건 테스트 다중 조건 테스트 변형 조건/결정 테스트(MCDC) 기본 경로 테스트

  • 경험 기반 방법
    테스트 케이스 설계를 바탕으로 테스트를 수행하지 않고 도메인에 대한 테스터의 경험, 기존 테스트 결과, 테스터의 직관을 주로 활용하여 테스트를 수행한다.
    
    • 오류 추정
      개발자가 범할 수 있는 실수를 추정하고 이에 따른 결함이 검출되도록 테스트 케이스를 설계하는 방법이다.
      기본 아이디어는 발생할 수 있는 오류 상황을 나열하는 것에서 시작된다.
      

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

    • 탐색적 테스트
      테스트 대상에 대한 이해, 테스트 케이스 설계, 테스트 실행을 병행하는 방식이다.
      테스트 명세서, 테스트 계획서 등 문서화 없이 즉석에서 테스트 케이스를 결정한 후, 해당 테스트를 수행한다. 테스트해야 하는 세부 피처를 명확하게 식별 하고 의사소통하기 위한 테스터 차터(Charter)를 간략하게 작성할 수 있다.
      애자일 방법을 사용하는 웹 응용 시스템의 테스트에 적합한 방법이다.

 

 

2.3 테스팅 방법

---

2.3.1 개요

• 프로젝트의 다양한 현실적 상황을 고려하여 실제 적용할 수 있는 대표적인 테스트 수행 방법

 

2.3.2 리그레션 테스트

• 리그레션 테스트(Regression Test)는 소프트웨어 변경 후에 수행되는 테스트로, 소프트웨어에 가해진 변경이 의도하지 않게 결함을 만들지 않았는지, 시스템이 기존의 요구사항을 충족하는지 검증하기 위하여 수행한다.
• 리그레션 테스트 전략으로 Retest-all 전략, 선택적 리그레션 테스트 전략, 테스트 최소화 전략, 테스트 우선순위화 전략이 있다.
• 소프트웨어가 변경되면 각 레벨 테스트 순서대로 리그레션 테스트를 수행한다.
  (컴포넌트 테스트 → 통합 테스트 → 시스템 테스트)

 

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

소프트웨어 생명 주기는 소프트웨어 개발 체계의 추상적 표현이며 순차적 또는 병렬적인 일련의 단계로 구성된다.

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

• 폭포수 모델
  • 구현이 완료된 후에 테스트가 시작된다.
• V-모델
  • 개발 시작과 함께 테스트도 시작된다.
  • 각 개발 단계에서 발생하는 결함을 검출할 수 있는 테스트 레벨이 존재한다.
• 진화적 개발 모델
  • 수행하는 각 이터레이션마다 테스트 수행 계획을 작성하며 이에 따라 테스트를 수행한다.
• 애자일 개발 방법론
  • 테스트 주도 개발(Test-Driven Development, TDD)을 적용한다.
    TDD는 프로그램에 대한 테스트 케이스를 먼저 작성하고, 이 테스트 케이스를 통과하는 실제 프로그램 코드를 나중에 작성하는 방식이다.
  • 지속적 통합(CI, Continuous Integration)을 수행한다.

 

2.3.4 위험 기반 테스트

• 주어진 자원 내에서 테스트 목적을 달성하기 위해 테스트 접근 방법, 테스트 범위를 결정해야 한다.
• 테스트 제외에 따른 위험 수준이 높은 것은 테스트 대상에서 반드시 포함해야 한다.
• 피처에 대한 위험 분석을 바탕으로 테스트에 대한 계획과 설계 그리고 실행 들의 활동을 수행하는 것을 위험 기반 테스트라고 한다.

 

2.3.5 모델 기반 테스트

• 모든 명세 기반 테스트는 테스트 대상에 대한 기대 동작을 표현하는 일종의 모델을 이용한다.
  ex) 자연어로 된 표현 형식, 시각적인 표현방식(상태 전이도, UML 다이어그램), 표 형태(의사결정표)
• 모델 기반 테스트는 테스트 절차를 수행할 수 있는 정보가 자동으로 추출될 수 있을 정도로 정형화되고 상세한 모델을 바탕으로 한다.