애플리케이션 테스트 관리

2022. 5. 31. 15:03정처기(필기)/소프트웨어개발

(1) 테스트 케이스

1. 테스트 케이스란

- 테스트 케이스는 특정 요구사항에 준수하는지를 확인하기 위해 개발된 입력값, 실행 조건, 예상된 결과의 집합이다.

 

2. 테스트 케이스 구성요소

  • 식별자(Identifier) : 테스트 케이스를 고유하게 식별하기 위한 항목 식별자
  • 테스트 항목 : 테스트할 모듈 또는 기능에 대한 간략한 내용
  • 입력명세(Input Specification) : 테스트 실행 시 입력할 데이터 및 조건
  • 출력명세 : 테스트 케이스 실행 시 기대되는 결과 데이터
  • 환경설정 : 테스트 수행 시 필요한 하드웨어나 소프트웨어 환경 
  • 특수절차요구 : 테스트 케이스 수행 시 특별히 요구되는 절차
  • 의존성 기술 : 테스트 케이스 간의 의존성 및 종속성

3. 테스트 오라클

- 테스트 오라클은 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참값을 입력하여 비교하는 기법이다.

 

▼ 테스트 오라클 종류

종류 설명
참(True)
오라클
모든 입력값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클
샘플링
오라클
특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해주는 오라클
휴리스틱
오라클
샘플링 오라클을 개선한 오라클로, 특정 입력값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클
일관성 검사
오라클
애플리케이션 변경이 있을 때, 수행 전과 후의 결과값이 동일한지 확인하는 오라클

 

(2) 테스트 레벨

- 테스트 레벨은 함께 편성되고 관리되는 테스트 활동의 그룹이다. 

- 각각의 테스트 레벨은 서로 독립적이다.

 

테스트 레벨 종류

  • 단위 테스트 : 사용자 요구사항에 대한 단위 모듈, 서브루틴 등을 테스트하는 단계(인터페이스, 자료구조, 실행경로, 오류처리)
  • 통합 테스트 : 단위 테스트를 통과한 컴포넌트 간의 인터페이스를 테스트하는 단계(빅뱅, 상향식/하향식 테스트)
  • 시스템 테스트 : 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트하는 단계(기능/비기능)
  • 인수 테스트 : 계약상의 요구사항이 만족되었는지 확인하기 위한 테스트 단계(알파/베타 테스트)

-> 시스템 테스트는 기능적 요구사항 테스트(요구사항 명세서, 비즈니스 절차, 유스케이스 등)과 비기능적 요구사항 테스트(성능 테스트, 회복 테스트, 보안 테스트, 화이트 박스 테스트 등)으로 나뉜다. 

 

(3) 테스트 시나리오

- 테스트 시나리오는 애플리케이션의 테스트되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서이다. 

 

(4) 테스트 지식 체계

1. 소프트웨어 테스트 종류

- 프로그램 실행 여부, 테스트 상세 기법, 테스트에 대한 시각, 테스트의 목적, 테스트의 종류에 따라 분류할 수 있다. 

- 동적 테스트 : 소프트웨어를 실행하는 방식으로 결함 검출(명세 기반 테스트(블랙박스 테스트), 구조기반 테스트(화이트박스 테스트), 경험기반테스트(탐색적 테스트, 오류추정 테스트))

- 정적 테스트 : 테스트 대상을 실행하지 않고 구조를 분석하여 논리성을 검증(리뷰, 정적 분석)

 

!!여기서 잠깐!!

블랙박스 테스트와 화이트박스 테스트란?

- 블랙박스 테스트는 프로그램 외부 사용자의 요구사항 명세를 보면서 수행하는 테스트(기능 테스트)다. 

 

블랙박스 테스트 유형

  • 동등 분할 테스트 : 입력 데이터의 영역을 유사한 도메인별로 유효 값/무효값을 그룹핑하여 대표값으로 테스트케이스를 도출하는 법
  • 경계값 분석 테스트 : 등가분할 후 경계값 부분에서 오류 발생 확률이 높아서 경계값을 포함하여 테스트하는 법
  • 결정 테이블 테스트 : 요구사항의 논리와 발생조건을 테이블 형태로 나열하여 모두 조합하여 테스트하는 법
  • 상태전이 테스트 : 테스트 대상/시스템이나 객체의 상태를 구분하고 이벤트가 일어나면 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 법
  • 유스케이스 테스트 : 시스템이 실제 사용되는 유스케이스로 모델링 되어있을때 프로세스 흐름을 기반으로 테스트 케이스를 명세화하여 수행하는 테스트 법
  • 분류 트리 테스트 : SW의 일부 또는 전체를 트리 구조로 분석하여 테스트하는 기법
  • 페어와이즈 테스트 : 테스트 데이터 간에 최소한 한 번씩을 조합하는 방식. 
  • 원인-결과 그래프 테스트 : 입력 데이터 간의 관계 및 출력에 미치는 영향을 분석하는 테스트 기법
  • 비교 테스트 : 여러 버전의 프로그램에 같은 입력 값을 넣어서 동일한 결과 데이터간 나오는지 비교 

 

- 화이트박스 테스트는 각 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트다.

- 구조기반 테스트, 코드기반테스트, 로직 기반 테스트, 글래스 테스트라고도 부른다. 

 

화이트박스 테스트 유형

  • 구문 커버리지 : 프로그램 내의 모든 명령문을 적어도 한번 수행하는 커버리지
  • 결정 커버리지 : 결정 포인트 내의 전체 조건식이 적어도 한 번은 참과 거짓의 결과를 수행
  • 조건 커버리지 : 결정 포인트 내의 각 개별 조건식이 적어도 한 번은 참과 거짓의 결과가 되도록 수행
  • 조건/결정 커버리지 : 전체 뿐만 아니라 개별 조건식도 참 한번, 거짓 한번 결과가 되도록 수행
  • 변경 조건/결정 커버리지 : 개별 조건식이 다른 개별 조건식에 영향을 받지 않도록 향상시킨 커버리지
  • 다중 조건 커버리지 : 결정 조건 내 모든 개별 조건식의 모든 가능한 조합을 100% 보장하는 커버리지
  • 기본 경로 커버리지 : 수행 가능한 모든 경로를 테스트
  • 제어 흐름 테스트 : 프로그램 제어구조를 그래프 형태로 나타내어 내부 로직을 테스트하는 기법
  • 데이터 흐름 테스트 : 제어 흐름 그래프에 데이터 사용현황을 추가한 그래프를 통해 테스트

2. 테스트 시각에 따른 분류

검증 : 소프트웨어 개발 과정을 테스트

확인 : 소프트웨어 결과를 테스트

 

3. 테스트 목적에 따른 분류

분류 설명
회복 테스트 고의로 시스템 실패를 유도, 시스템의 정상적 복귀 여부를 테스트
안전 테스트 불법적인 소프트웨어가 시스템을 파괴 하지 못하도록 보안적인 결함을 테스트
성능 테스트 사용자의 이벤트에 시스템이 응답하는 시간 등을 처리하는 업무량, 속도 등을 측정
강도 테스트 시스템 처리 능력 이상의 부하 임계점 이상의 부하를 가하여 비정상적인 상황에서 테스트
구조 테스트 시스템의 내부 논리 경로, 소스 코드의 복잡도를 평가하는 테스트 기법
회귀 테스트 오류를 제거하거나 수정한 시스템에서 새로 유입된 오류가 없는지를 확인
병행 테스트 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교

 

4. 소프트웨어 테스트의 원리

  1. 결함 존재 증명 
  2. 완벽 테스팅은 불가능
  3. 초기 집중
  4. 결함 집중
  5. 살충제 패러독스(동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못한다는 원리)
  6. 정황 의존성 : 소프트웨어의 성격에 맞게 테스트를 수행할 것
  7. 오류-부재의 궤변 : 요구사항을 충족시켜주지 못하면 결함이 없다고 해도 품질이 높다고 볼 수 없음

(3) 결함 관리 도구

1. 결함 관리 도구란

- 결함 관리 도구는 단계별 테스트 수행 후 발생한 결함의 재발 방지를 위해, 유사 결함 발견 시 처리 시간 단축을 위해 결함을 추적하고 관리하는 도구다. 

 

2. 결함 추이 분석

- 테스트 완료 후 발견된 결함의 결함 관리 측정 지표의 속성 값들을분석하고, 향후 애플리케이션의 어떤 모듈 또는 컴포넌트에서 결함이 발생할지를 추정하는 자겅빙다. 

- 결함 분포 분석(컴포넌트의 특정 속성에 해당하는 결함의 수를 측정하여 결함의 분포 분석), 결함 추세 분석(테스트 진행 시간의 흐름에 따른 결함의 수를 측정하여 결함 추세를 분석), 결함 에이징 분석(등록된 결함에 대해 특정한 결함 상태의 지속 시간을 측정)

 

3. 결함의 식별

- 결함은 개발자 오류로 인해 만들어지는 문서 또는 코딩 상의 결점

- 오류 : 결함의 원인이 되는 것, 사람에 의한 실수

- 결점 : 소프트웨어 개발 활동을 수행할 때 시스템이 고장을 일으키게 하며, 오류가 있는 경우 발생하는 현상

- 버그 : 프로그램 오류로 인해 예상치 못한 결과가 나는 현상

고장/문제 : 소프트웨어 제품에 포함된 결함이 실행될 때 발생하는 현상

 

(4) 테스트 자동화 도구

1. 테스트 자동화 도구란

- 테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현함으로써 테스트 시간 단축과 인력 투입 비용을 최소화하며, 쉽고 효율적인 테스트를 수행할 수 있는 방법이다. 

- 테스트 자동화 도구를 사용하면 반복되는 테스트 데이터 재입력 작업을 자동화할 수 있으며 사용자 요구 기능의 일관성 검증에 유리, 테스트 결과값에 대한 객관적인 평가 기준을 제공하고 그래프 등 다양한 표시 형태를 제공하여 UI가 없는 서비스의 경우에도 정밀한 테스트를 가능하게 한다.

- 도구 도입 후 도구 사용 방법에 대한 따로 교육이 필요하며 시간 비용, 노력이 많이 들며 유지 관리 비용이 높다는 단점이 있다. 

 

2. 테스트 자동화 요구 유형

  • 정적 분석 도구 : 만들어진 애플리케이션을 실행하지 않고 분석하는 유형
  • 테스트 실행 도구 : 테스트를 위해 작성된 스크립트를 실행하는 도구(데이터 주도 접근 방식 - 테스트 데이터를 스프레드시트에 저장하고 이 데이터를 읽고 실행, 키워드 주도 접근 방식 - 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 스프레드시트에 저장)
  • 성능 테스트 도구 : 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트를 수행함으로써 성능 목표를 달성하였는지를 확인하는 도구
  • 테스트 통제 도구 : 테스트 계획 및 관리를 위한 테스트 관리 도구 등이 있음

 

3. 테스트 장치

- 애플리케이션 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로, 테스트를 지원하기 위한 코드와 데이터를 말함

 

테스트 장치 구성요소

  • 테스트 드라이버 : 상향식 통합시험을 위해 모듈 테스트 수행 후의 결과를 도출하는 시험용 모듈
  • 테스트 스텁 : 하향식 통합시험을 위해 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈
  • 테스트 슈트 : 테스트 케이스를 실행환경에 따라 구분해 놓은 테스트 케이스의 집합
  • 테스트 케이스 : 입력값, 실행 조건, 기대 결과 등의 집합
  • 테스트 시나리오 : 애플리케이션의 테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서
  • 테스트 스크립트 : 테스트 케이스의 실행 절차를 작성한 문서
  • 목 오브젝트 : 사용자의 행위를 조건부로 사전에 입력해 두면, 그 상황에 예정된 행위를 수행하는 객체

(5) 통합 테스트

- 통합 테스트는 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 테스트다. 

- 일반적으로 점증적 방식과 비점증적 방식으로 나뉘는데, 점증적인 방법에서 다시 상향식 통합과 하향식 통합 방식으로 구분된다. 

 

1. 하향식 통합 테스트

- 메인 프로그램으로부터 아래 방향으로 제어의 경로를 따라 이동하면서 하향식으로 통합하는 테스트

- 하위 모듈과 최하위 모듈은 '깊이-우선' 또는 '너비-우선' 방식으로 통합된다.

 

2. 상향식 통합 테스트

- 애플리케이션 구조에서 최하위 레벨의 모듈 또는 컴포넌트로부터 점진적으로 상위 모듈과 함께 테스트하는 기법