[CSTS] 1장 테스트 개요

1장 테스트 개요

---

 

1.1 테스트 목적

---

• 시스템이 요구사항을 만족하는지 확인, 표준을 준수하는지 검증
• 결함의 검출과 제품 품질 개선
• 품질 평가와 의사 결정 지원
• 개발 프로세스 개선 지원

 

 

1.2 오류, 결함, 장애

---

1.2.1 오류, 결함, 장애의 개념

• 소프트웨어 요구사항: 소프트웨어를 개발할 때 기대·약속된 소프트웨어의 동작에 대한 기준을 정의한 것
• 장애(Failure): 프로그램의 실행 결과와 요구사항에 명시된 결과의 차이
• 결함(Defect): 소프트웨어 내에 장애를 유발할 수 있는 문제
  ex) 부정확한 구현, 누락
• 오류(Error): 결함이 생기게 한 개발자의 행위
  ex) 요구사항 미숙지, 오타
  

 

1.2.2 결함 유형

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

 

1.2.3 개발 단계별 결함

• 결함은 모든 개발 산출물에 존재할 수 있다.
  (결함 발생 단계: 요구분석-설계-코딩-문서화-결함해결오류)
• 결함 해결에 소요되는 비용을 최소화하기 위해서 각 개발 단계의 결과물에 존재하는 결함을 최대한 빨리 검출하고 제거해야 한다.

 

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

• 테스팅
  • 소프트웨어의 실제 동작과 요구사항과의 차이를 확인
  • 장애 발생을 확인하여 소프트웨어에 결함이 있음을 간접적으로 판단
  • 테스팅 결과: 결함을 검출한 테스트 케이스와 테스트 환경
• 디버깅
  • 결함의 위치를 파악하고 이를 제거하는 것이 목적
• 재테스팅
  • 개발자가 결함을 제거하기 위해 코드 수정한 이후, 실제로 결함이 제거되었는지 확인
  • 초기에 결함을 검출한 테스트 케이스를 이용하여 테스팅을 다시 수행

 

 

1.3 테스트의 현실/실제

---

1.3.1 완벽한 테스트의 비현실성

Program testing can be used to show the presence of bugs, but never their absence.
-Dijkstra-

• 프로그램 테스트는 결함이 있음을 보일 수는 있지만, 결함이 없음을 보일 수는 없다.
• 주어진 인력과 시간을 바탕으로 최대한 효과적이고 효율적인 테스트를 수행할 수 있도록 체계적인 테스트가 수행되어야 한다.

 

1.3.2 테스트의 진화과정

레벨 1 (Debugging-oriented)	테스트와 디버깅에 차이가 없다. 우연히 발견된 결함을 디버깅한다.
레벨 2 (Demonstration-oriented)	프로그램이 올바르게 동작한다는 사실을 입증하기 위해 테스트를 수행한다. 정상 작동을 증명하도록 테스트 케이스를 설계한다.
레벨 3 (Destruction-oriented)	프로그램에 결함이 존재함을 보여주기 위해 테스트를 수행한다. 프로그램의 결함을 발견하도록 테스트 케이스를 설계한다.
레벨 4 (Evaluation-oriented)	소프트웨어 개발 전 단계에서 발생하는 결함을 발견하기 위해 테스트를 수행한다. 개발 초기 단계부터 지속적으로 리뷰등을 통해 시스템을 평가한다.
레벨 5 (Prevention-oriented)	결함이 발생하지 않도록 사전에 방지하기 위해 테스트를 수행한다. 결함을 미연에 방지하기 위한 방법은 테스트 케이스를 미리 설계하는 것이다.

 

1.3.3 테스트 원칙

• 테스트는 반드시 프로그램을 개발한 프로그래머나 팀과 무관한 그룹이 수행해야 한다.
• 결함이 발견되지 않으리라는 가정하에 테스트 계획을 수립해서는 안 된다.
• 타당한 경우뿐만 아니라 타당하지 않고 예상하지 못한 경우에 대해서도 테스트를 수행하라.
• 프로그램의 어떤 부분에 결함이 남아있을 확률은 그 부분에서 이미 발견된 결함의 수에 비례한다.
• 테스트 케이스를 체계적으로 관리하라.
• 각각의 테스트 결과를 철저하게 점검하라.

 

 

1.4 테스트와 품질

---

1.4.1 테스트와 품질 평가

• 기능(Functional) 테스트
  • 기능 요구사항에 중점을 둔 테스트
• 비기능(Non-functional) 테스트
  • 품질 요구사항에 중점을 둔 테스트
  • 각 품질 특성 별로 수행되는 테스트를 유형 테스트라고 한다.
    ex) 성능 테스트, 보안 테스트, 신뢰성 테스트

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

 

1.4.2 테스트와 품질 보증

• V&V(Verification and Validation)
  • 검증(Verification): 소프트웨어 개발 과정에서 수행한 활동의 적합성 검사에 초점
  • 확인(Validation): 결과물의 적합성에 초점
• 품질 보증
  • 의도한 목적에 적합한 품질의 소프트웨어 제품을 개발하였는지, 그리고 그러한 소프트웨어 프로세스가 적합한지에 대한 확신을 주기 위하여 수행되는 다양한 활동
  • 소프트웨어 제품의 품질뿐만 아니라 프로세스의 품질을 포함한다는 측면에서 V&V보다 광범위하다.

 

 

1.5 테스트 기본 용어

---

1.5.1 테스트 대상과 테스트 레벨

• 테스트 대상(Test item)
  • 테스트를 통해 결함을 검출하려는 대상 소프트웨어
  • 전체 소프트웨어 또는 전체 소프트웨어의 일부분이 테스트 대상이 된다.
• 테스트 레벨
  • 시스템 테스트: 전체 소프트웨어를 대상으로 한 테스트
  • 컴포넌트(Component) 테스트 또는 단위(Unit) 테스트: 부분을 대상으로 한 테스트
  • 통합 테스트: 시스템을 구성하는 각 부분의 연결에 초점을 준 테스트, 테스트 대상은 전체 소프트웨어이다.

 

1.5.2 피처와 테스트 유형

• 피처(Feature)
  • 테스트 대상의 특성 중에서 테스트하고자 하는 측면·관점
  • 피처는 테스트  계획을 수립할 때 식별되어 테스트 범위로 기술된다.
• 테스트 유형
  • 테스트 설계 활동을 통해 피처가 구체화되며 이를 기준으로 테스트 케이스 및 테스트 절차가 개발된다.

 

1.5.3 테스트 설계 기법

• 정적 테스트
  • 테스트 대상을 실행하지 않고 테스트를 수행하는 방식
  • 리뷰(Review)와 정적 분석(Static analysis)이 있다.
    • 리뷰: 각 개발 단계별로 해당 단계의 산출물이 품질 목표에 부합하는지 점검하거나 산출물에 존재하는 결함을 검출한다.
    • 정적 분석: 소스 코드를 대상으로 결함으로 판단할 수 있는 특정한 패턴이 소스 코드에 있는지 분석한다.
  • 장점
    • 테스트 대상에 대한 실행 환경이 필요 없다.
    • 소스 코드를 작성하기 전에 요구사항이나 설계 수준에서 테스트가 가능하여 경제적이다.
    • 자동화 도구를 활용함으로써 테스트를 자동으로 수행할 수 있다.
  • 단점
    • 자동화 도구는 결함이 아닌 문제를 결함으로 보고할 수 있다.(False positive)
• 동적 테스트
  • 테스트 대상을 실행하여 테스트를 수행하는 방식
  • 명세 기반 방법, 구조 기반 방법, 경험 기반 방법이 있다.
    • 명세 기반 방법
      프로그램의 내부 논리 구조를 참조하지 않고 사용자의 요구 명세나 설계 정보 등을 이용하여 테스트 케이스를 개발한다.
    • 구조 기반 방법
      프로그램의 제어 흐름이나 자료 흐름 정보 등 프로그램의 내부 구조 정보를 기반으로 테스트 케이스를 설계하는 방법이다.
      구조적 테스트(Structural test), 화이트박스 테스트(White box test) 또는 글래스 박스 테스트(Glass-box test)라고도 한다.
    • 경험 기반 방법
      테스트 케이스 설계를 바탕으로 테스트를 수행하지 않고 도메인에 대한 테스터의 경험, 기존 테스트 결과, 테스터의 직관을 주로 활용하여 테스트를 수행한다.
      오류 추정(Error guessing)과 탐색적 테스트(Exploratory test)가 있다.
  • 장점
    • 실행 가능한 소프트웨어가 필요하며 소스 코드가 사용되지 않으므로 소스 코드가 없는 경우에도 수행할 수 있다.
    • 코드 분석으로 확인하기 어려운 성능 요구사항과 가용성, 확장성, 신뢰성 등의 품질 요구사항은 동적 테스트를 통해서 확인 가능하다.
  • 단점
    • 소프트웨어를 실행시키기 위한 환경이 요구된다.

 

1.5.4 테스트 케이스

• 입력과 대응되는 예상 결과
• 입력값을 테스트 대상에 제공하는 방법, 그리고 예상 결과와 실제 결과를 비교하는 방법도 포함한다.

 

1.5.5 테스트 절차

• 테스트를 준비하고, 실행하고, 결과를 관찰하고 기록하는 절차
• 테스트 실행, 검출된 결함을 재연할 때 사용된다.
• 결함의 재연이 가능하도록 테스트 절차를 구체적이고 명확하게 기술해야 한다.
• 테스트 스크립트(Script): 테스트 절차를 자동화 도구가 해석하고 실행하는 언어로 작성한 것

 

1.5.6 테스트 환경

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

 

1.5.7 테스트 기본 용어 요약

 

[그림 1] 테스트 용어 간의 관계

 

• 하나의 테스트 대상에 대하여 복수 개의 피처가 있을 수 있다.
• 피처는 적합한 테스트 설계 기법을 적용하여 테스트 수행해야 한다.
• 동적 테스트 방법을 적용할 때 복수 개의 테스트 케이스가 설계된다.
• 테스트 케이스는 피처에 따라 결정된다.
• 복수 개의 테스트 케이스가 특정 테스트 환경에서 수행될 수 있도록 순서를 정하면 테스트 절차가 된다.
• 하나의 테스트 케이스는 여러 테스트 절차에서 사용될 수 있다.