1. 애플리케이션 테스트 케이스 설계

1) 소프트웨어 테스트

정의

• 테스트란 사용자가 요구하는 기능, 성능, 사용성, 안정성 등을 만족하는지 찾아내는 활동
• 응용 애플리케이션이나 시스템의 결함을 찾아내어 문제점을 해결하는 것이 최종 목표

S/W 테스트의 필요성

• 프로그램에 잠재된 오류를 발견하고 이를 수정하여 올바른 프로그램을 개발할 수 있다.
• 프로그램 실행 전에 코드 리뷰, 인스펙션 등을 통해 오류를 사전에 예방할 수 있다.
• 반복적인 테스트를 거쳐 제품의 신뢰도를 향상하여 사용자 기대 수준을 만족시킬 수 있다.

2) 소프트웨어 테스트 기본 원칙

소프트웨어 테스트 원리

• 테스트는 잠재적인 결함을 줄여나가는 활동이지만 모든 결함을 없앨 수는 없다.
• 테스트는 개발 초기부터 SDLC 각 단계의 정황에 적합한 기법을 사용할 수 있어야 한다.
• 효율적인 소프트웨어 테스트 진행을 위한 테스트 원리는 다음과 같다.
  • 결함 집중(Defect Clustering) : 결함의 대부분은 특정 모듈에 집중되어 존재(낚시 법칙, 파레토 법칙)
  • 낚시의 법칙 : 낚시 포인트처럼, 특정 위치에서 많은 결함 발생
  • 파레토(Pareto)의 법칙 : 결함의 80%는 20%의 기능에서 집중적으로 발생
  • 살충제 패러독스(Pesticide Paradox) : 동일한 테스트 케이스로 반복 실행하면 새로운 결함 발견 불가능
  • 오류-부재의 궤변(Absence of Errors Fallalcy) : 결함이 없더라도 요구사항을 만족하지 못한다면 품질 보증 불가능

소프트웨어 테스트 절차

1. 테스트 계획
2. 테스트 분석 및 디자인
3. 테스트 케이스 및 시나리오 작성
4. 테스트 수행
5. 테스트 결과 평가 및 리포팅

소프트웨어 테스트 산출물

• 테스트 계획서
• 테스트 케이스
• 테스트 시나리오
• 테스트 결과서

3) 소프트웨어 테스트 유형

프로그램 실행 여부에 따른 분류

• 정적 테스트

  : 프로그램 실행 없이 소스 코드의 구조 분석(인스펙션, 동료 검토, 워크 스루 등)

• 동적 테스트

  : 프로그램의 실행 화면을 보면서 테스트 수행

화이트박스 : 프로그램의 내부 로직을 중심으로 테스트를 진행한다.

블랙박스 : 프로그램의 기능을 중심으로 테스트를 진행한다.

테스트와 디버깅

• 테스트 : 제품에 대한 검증과 확인을 수행하는 것

  • 검증

    : 제품의 개발 과정에 대한 테스트(개발자 입장)

  • 확인

    : 제품의 개발 결과에 대한 테스트(사용자 입장)

• 디버깅 : 프로그램의 오류를 찾고, 수정하는 것

목적 기반 테스트

• 회복(Recovery) : 실패를 유도하여 정상 복귀가 가능한지 테스트
• 안전(Security) : 소스 코드 내의 보안 결함에 대한 테스트
• 강도(Stress) : 과부하 시에도 시스템이 정상 작동하는지 테스트
• 성능(Performance) : 응답시간, 처리량, 반응속도 등의 테스트
• 구조(Structure) : 시스템 내부 로직, 복잡도 등을 테스트
• 회귀(Regression) : 변경된 코드에 대한 새로운 결함 여부 테스트
• 병행(Parallel) : 변경된 코드에 기존과 동일한 테스트 진행 후 결과 비교

설계 기반 테스트

• 명세 기반 테스트 : 주어진 명세를 기반으로 테스트 케이스를 구현하여 테스트

• 구조 기반 테스트 : 소프트웨어 내부 로직을 기반으로 테스트 케이스를 구현하여 테스트

• 경험 기반 테스트

  : 유사한 테스트를 진행했던 테스트의 경험을 기반으로 테스트

4) 화이트박스 테스트 기법

기초 경로(Basic Path) 테스트

• McCabe가 제안한 것으로 대표적인 화이트박스 테스트 기법

• 설계서나 소스 코드를 기반으로 흐름도를 작성하여 논리적 순환 복잡도(Cyclomatic complexity)를 측정한다.

• 측정된 결과를 기반으로 실행 경로의 복잡도를 판단한다.

복잡도 = 간선수 - 노드수 + 2 * 컴포넌트

해당 공식에 따라 다음 프로그램의 복잡도는 $9 - 5 + 2 * 1 = 6$이다.

제어구조 검사

• 조건 검사 : 논리식을 중심으로 테스트
• 루프 검사 : 반복 구조를 중심으로 테스트
• 데이터 흐름 검사 : 변수의 정의와 사용을 중심으로 테스트

5) 블랙박스 테스트 기법

동등 분할(Equivalence Partitioning) 테스트

입력 조건에 유효한 값과 무효한 값을 균등하게 하여 테스트 케이스를 설계한다.

경계값 분석(Boundary Value Analysis)

입력 조건의 경계에서 오류가 발생할 확률이 높다는 점을 이용하여 입력 조건의 경계값을 테스트 케이스로 설계한다.

원인-효과 그래프(Cause-Effect Graphing) 테스트

입력 데이터 간의 관계와 출력에 미치는 영향을 분석하여 효용성이 높은 테스트 케이스를 설계한다.

오류 예측(Error Guessing)

과거의 경험이나 확인자의 감각에 의존하여 테스트 케이스를 설계한다.

비교(Comparison) 테스트

이려 버전의 프로그램에 동일한 테스트 자료를 제공하여 테스트하는 기법이다.

6) 테스트 케이스

정의

설계 기반 테스트의 산출물로, 요구사항 준수 여부를 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목 또는 이것이 기록된 명세서를 말한다.

작성 절차

정확성, 재사용성, 간결성 보장 목적이다.

1. 테스트 계획 검토 및 자료 확보
2. 위험 평가 및 우선순위 결정
3. 테스트 요구사항 정의
4. 테스트 구조 설계 및 테스트 방법 결정
5. 테스트 케이스 정의
6. 테스트 케이스 타당성 확인 및 유지보수

테스트 오라클

테스트의 결과를 참/거짓으로 판단하기 위해 사전에 정의된 참 값을 입력하여 비교하는 기법

• 참 오라클 : 모든 입력값에 대하여 기대 결과를 생성
• 샘플링 오라클 : 특정 몇 개의 입력값에 대해서만 기대 결과 제공
• 휴리스틱 오라클 : 샘플링 오라클을 개선, 특정 입력값에 대해 기대 결과를 제공하고 나머지 값들에 대해서는 휴리스틱(추정)으로 처리
• 일관성 검사 오라클 : 애플리케이션 변경이 있을 때 수행 전과 후의 결과값이 동일한지 확인

참 오라클은 미션 크리티컬한 업무에 적용 / 샘플링, 휴리스틱 오라클은 일반 업무나 게임 등의 업무에 적용한다.

미션 크리티컬 : 매우 작은 결함으로도 치명적인 결과를 발생할 수 있는 업무 (ex. 원자력 발전소)

2. 테스트 수행 환경 구축

1) 테스트 환경 구축 유형

환경 구축

• S/W가 작동될 환경과 최대한 유사한 하드웨어, 소프트웨어, 네트워크 시설을 구축하여 테스트
• 물리적 테스트 환경 구축이 어려울 경우 가상 머신 기반의 서버 또는 클라우드 환경을 이용하여 테스트 환경을 구축하여 테스트
• 네트워크 또한 논리적 분할(VLAN)을 통하여 구축하여 테스트 할 수 있다.

2) 테스트 데이터

정의

컴퓨터의 동작이나 시스템의 적합성을 시험하기 위해 개발, 생성된 데이터의 집합

테스트 전용 데이터이므로 확실한 조건을 갖춰야 한다.

준비 유형

• 실제 데이터 : 실제 운영 데이터, 연산을 통한 결과
• 가상 데이터 : 스크립트를 통해 인위적으로 생성

테스트 시작과 종료

• 시작 조건 : 계획 수립, 명세 작성, 역할과 책임 정의, 환경 구축 등의 완료
• 종료 조건 : 모든 테스트 수행, 테스트 일정 만료, 테스트 비용 소진 등

테스트를 위한 조건 사항에 너무 얽매일 필요는 없다.