[CSTS 요약] 1 테스트 개요

테스트 목적

소프트웨어의 결함 검출, 품질 평가, 프로세스 개선

• 결함의 검출과 품질 개선
• 품질 평가와 의사 결정 지원
• 개발 프로세스 개선 지원

 

오류, 결함, 장애

오류, 결함, 장애의 개념

• 장애: 요구사항과 다르게 동작하는 소프트웨어
• 결함: 장애를 유발할 수 있는 소프트웨어 내의 문제
  결함 때문에 장애가 발생하나, 결함이 있다하여 반드시 장애가 발생하는 것은 아님
• 오류: 결함을 발생시킨 개발자의 행위

 

결함 유형

• 누락: 요구 명세의 요구사항이 시스템에 구현되지 않은 결함
• 부정확한 구현: 요구 명세의 요구사항이 소프트웨어에 부정확하게 반영된 결함
• 비관련 결함: 요구 명세와 관련되지 않은 구현

 

개발 단계별 결함

결함은 최종적으로 소프트웨어 동작의 장애를 유발할 수 있는 모든 개발 산출물에 존재할 수 있음

결함 발생 단계

 

각 개발 단계에서 결함을 검출하여 제거하지 않으면 이후 단계에서 장애를 유발하게 되며, 결함 발생 단계 이후에는 더 많은 비용이 소요됨

결함 해결 비용

 

테스팅, 디버깅, 재테스팅

테스팅과 디버깅의 차이점

 

• 테스팅
  소프트웨어의 실제 동작과 요구사항의 차이 확인
  테스팅 결과: 결함을 검출한 테스트 케이스와 테스트 환경
• 디버깅
  결함의 존재를 확인한 테스팅 이후 결함의 위치를 파악하고 제거
• 재테스팅
  디버깅 이후 결함을 검출한 테스트 케이스를 이용하여 실제로 제거되었는지 확인

 

테스트의 현실/실제

완벽한 테스트의 비현실성

주어진 인력과 시간을 바탕으로 최대한 효율적이고 효율적인 테스트 수행

소프트웨어 실행 방식으로 수행되는 동적 테스트는 너무 많은 경우의 수가 존재함

 

테스트의 진화 과정

• 레벨 1 (Debugging-oriented, ~1956년) 테스트와 디버깅의 구분 없음
  프로그램의 결함 발견 위한 별도의 노력 없음
• 레벨 2 (Demonstration-oriented, 1957~1978년) 프로그램 정상 동작 위한 테스트 수행
  시스템 정상 작동 증명 위한 테스트 케이스 설계
• 레벨 3 (Destruction-oriented, 1979~1982년) 프로그램 결함 존재 위한 테스트 수행
  레벨 4 (Evaluation-oriented, 1983~1987년) 소프트웨어 개발 전 단계에서 발생하는 결함 발견
  개발 초기 단계부터 지속적인 리뷰를 통해 시스템 평가 작업 수행
• 레벨 5 (Prevention-oriented, 1988~) 프로그램의 결함 사후 발견이 아닌 결함 발생 사전 방지
  프로그램 개발시 테스트가 용이하도록 시스템 설계해야 한다는 개념 추구
  테스트 주도 개발(Test-Driven Development, TDD): 테스트 케이스를 미리 설계하고 코딩하는 시스템

 

테스트 원칙

• 개발팀과 무관한 그룹이 수행
• 결함 발견 의도로 테스트 계획 수립
• 타당하지 않고 예상하지 못한 경우에 대해서도 테스트 수행
• 어떤 부분에서의 결함 존재 확률은 그 부분에서 이미 발견된 결함 수에 비례
• 체계적인 테스트 케이스 관리
• 각 테스트 결과 철저한 점검

 

테스트와 품질

테스트와 품질 평가

주특성	설명
기능 적합성	요구되는 기능을 만족시키는 능력
성능 효율성	적절한 자원의 사용 및 적정한 반응시간 정도
호환성	다른 시스템과의 상호 연동 능력
사용성	사용자가 이해하고 배우기 쉬운 정도
신뢰성	규정된 조건에서 규정된 기간 동안 오동작 없이 의도된 기능을 수행하는 소프트웨어의 능력
보안성	정보 및 데이터를 보호하는 능력
유지보수성	소프트웨어 유지보수의 용이성
이식성	다양한 플랫폼에서 운영될 수 있는 소프트웨어의 능력

ISO 25010의 품질 특성 분류

 

테스트와 품질 보증

품질 보증, V&V, 테스트 개념

 

• V&V(Verification and Validation): 소프트웨어 품질 보증을 위한 핵심 개념
  요구 분석 단계의 결과물인 요구사항 명세서가 결과물에 적절하게 반영되었는지를 조사하는 추적성 확인(검증)
  동작하는 소프트웨어가 주어진 요구사항을 충족하는지 확인(확인)
• 품질보증: 의도한 목적에 적합한 품질의 소프트웨어 제품을 개발하였는지, 그러한 소프트웨어 프로세스가 적합한지에 대한 확신을 주기 위하여 수행되는 다양한 활동
  소프트웨어의 품질뿐만 아니라 프로세스의 품질을 포함하므로 V&V보다 광범위

 

테스트 기본 용어

테스트 대상과 테스트 레벨

• 테스트 대상: 결함을 검출하려는 대상 소프트웨어
  시스템 자체인 전체 소프트웨어일 수도, 전체 소프트웨어의 일부분이 대상이 될 수도 있음
• 시스템 테스트: 전체 소프트웨어 대상 테스트
• 컴포넌트 테스트 또는 단위 테스트: 부분을 대상으로 한 테스트
• 통합 테스트: 시스템을 구성하는 각 부분의 연결에 초점을 둔 테스트
• 레벨 테스트: 컴포넌트 테스트, 통합 테스트, 시스템 테스트 등 통칭

피처와 테스트 유형

• 피처: 테스트 대상의 특성 중에서 테스트하고자 하는 측면·관점
• 테스트 유형: 다양한 측면·관점의 소프트웨어에 대한 기대와 요구에 따라 나뉘어질 수 있음
• 테스트 계획을 수립할 때 피처가 식별되어 테스트 범위로 기술되며, 테스트 설계 활동을 통해 구체화된 피처를 기준으로 테스트 케이스 및 테스트 절차 개발됨

테스트 설계 기법

테스트 대상의 결함을 효과적이고 효율적으로 검출하기 위한 것으로, 정적 테스트와 동적 테스트 기법으로 분류

• 정적 테스트: 테스트 대상을 실행하지 않고 테스트 수행 방식
  리뷰와 정적 분석이 해당
  테스트 대상을 실행하지 않기 때문에 테스트 대상에 대한 실행 환경 필요하지 않음
  코딩 이전의 개발 단계인 요구 분석, 구조 설계, 상세 설계 단계 등에서 산출물에 대한 테스트 수행 가능
  자동화 도구를 활용하여 테스트 자동 수행 가능
  
  • 리뷰: 산출물을 실행하지 않고 검사
  • 정적 분석: 소스 코드 대상. 결함으로 판단할 수 있는 특정한 패턴 존재 분석
• 동적 테스트: 소프트웨어 실행하는 방식으로 테스트 수행·결함 검출
  명세 기반 방법, 구조 기반 방법, 경험 기반 방법 해당
  실행 가능한 소프트웨어가 필요하며 소스 코드는 사용되지 않음
  소프트웨어 실행을 위한 환경 요구됨
  소프트웨어 품질 요구사항인 가용성, 확장성, 신뢰성 등 확인 가능
  • 명세 기반 방법: 사용자 요구 명세나 설계 정보 등을 이용하여 테스트 케이스 개발
    컴포넌트, 통합, 시스템, 인수 테스트 등 전 과정에 사용 가능
  • 구조 기반 방법: 프로그램의 제어 흐름이나 흐름 정보를 이용하여 테스트 케이스 개발
    구조적 테스트, 화이트박스 테스트, 글래스 박스 테스트라고도 함
  • 경험 기반 방법: 테스트 케이스 설계 바탕이 아닌, 도메인에 대한 테스터의 경험, 기존 테스트 결과, 테스터의 직관을 주로 활용하여 테스트 수행
    오류 추정과 탐색적 테스트 해당

테스트 케이스

입력과 대응되는 예상 결과를 의미

입력값, 입력값을 테스트 대상에 제공하는 방법, 예상 결과와 실제 결과를 비교하는 방법 포함

 

테스트 절차

테스트의 준비, 실행, 결과, 기록 절차 정의

결함 발견 이후 디버깅과 재테스팅을 위해 동일한 결함이 나오는 상황을 재현할 때 사용됨

자동화 도구가 테스트 절차를 해석하고 실행하는 언어로 작성한 것을 테스트 스크립트라고 함

 

테스트 환경

테스트 대상을 실행하는 모든 환경으로 하드웨어, 운영 체제를 포함한 시스템 소프트웨어, 외부 연동 시스템, 공존하는 응용 소프트웨어, 테스트 도구 등 포함

ex) 테스트 대상인 소프트웨어의 일부분(컴포넌트 또는 모듈)이 독립적으로 실행될 수 없는 컴포넌트·단위 테스트의 경우  대상 컴포넌트에 입력을 전달하기 위한 다른 모듈이 필요할 수 있고, 테스트 대상 컴포넌트가 다른 컴포넌트를 이용하거나 호출한다면 피호출 컴포넌트가 필요하므로 드라이버와 스텁이 사용되는데, 이 또한 테스트 환경에 해당됨

 

테스트 기본 용어 요약

테스트 용어 간의 관계

 

• 하나의 테스트 대상에 복수 개의 피처가 있을 수 있고, 각 피처에 대한 테스트 수행됨
  기능 피처와 성능, 보안 등을 다루는 비기능 피처가 있으며
  피처에 초점을 둔 테스트를 유형 테스트라고 함
• 각 유형 테스트에는 그에 적합한 테스트 설계 기법을 적용하여 테스트를 수행함
  테스트 설계 기법에는 정적 테스트와 동적 테스트가 있으며,
  정적 테스트 방법으로는 리뷰와 정적 분석,
  동적 테스트 방법으로는 명세 기반 테스트, 구조 기반 테스트, 경험 기반 테스트가 있음
• 동적 테스트 방법에는 복수 개의 테스트 케이스가 설계됨
  테스트 케이스는 피처(테스트 대상의 특성 중 테스트하고자 하는 측면·관점)에 따라 결정됨
  복수 개의 테스트 케이스가 특정 테스트 환경에서 수행될 수 있도록 순서를 정하면 테스트 절차가 되며,
  하나의 테스트 케이스는 여러 테스트 절차에서 사용될 수 있음