소프트웨어 개발 4. 애플리케이션 테스트 관리

1. 시각에 따른 테스트

• 애플리케이션 테스트 시 누구를 기준으로 하는지에 따라 분류
  - 검증(Verification) 테스트: 개발자 시각으로 생산 과정과 제품이 명세서대로 완성됐는지 테스트
  - 확인(Validation) 테스트: 사용자 시각으로 요구대로 완성되고 정상적 동작하는지 결과를 테스트

2. 화이트박스 테스트

• White Box Test
  - 소프트웨어 내부 구조를 참조하여 논리적 모든 경로 테스트(구조 기반 테스트)
  - 모듈의 원시 코드 오픈
  - 프로시저 설계의 제어 구조(선택/반복 등 분기점 수행)로 테스트 케이스 설계
  - 테스트 초기 적용
  - 모듈 내 작동 직접 관찰
• 종류
  - 문장 검증 기준(Statement Coverage): 구문
  - 분기 검증 기준(Branch Coverage): 조건문
  - 조건 검증 기준(Condition Coverage): 조건문의 True와 False 한 번 이상 수행
  - 분기/조건 기준(Branch/Condition Coverage): 모든 조건문과 True/False 수행

3. 블랙박스 테스트

• Black Box Test
  - 입력 데이터 출력 시 결과물이 정확한지 검사(명세 기반 테스트, 경험 기반 테스트)
  - 구현된 기능 위주로 테스트
  - 소프트웨어 인터페이스에서 실시
  - 테스트 후반 적용
  - 부정확/누락 기능, 인터페이스 오류, 자료 구조/외부 데이터베이스 접근 오류, 행위/성능 오류, 초기화/종료 오류 등 발견
• 종류
  - 동치 분할 검사(Equivalence Partitioning Testing): 조건에 맞는 입력 자료와 맞지 않은 자료를 균등하게
  - 경계값 분석(Boundary Value Analysis): 중간값이 아닌 경계값을 테스트 케이스로 선정
  - 원인-효과 그래프 검사(Cause-Effect Graphing Testing): 입력 데이터 간 관계와 출력에 영향 미치는 상황을 체계적 분석 후 효용성 높은 테스트 케이스 선정
  - 오류 예측 검사(Error Guessing): 테스터의 경험과 감각으로 보충적 데이터 확인
  - 비교 검사(Comparison Testing): 여러 버전에 동일 자료 넣어 결과 출력 확인

4. 단위 테스트

• Unit Test
  - 개발 단계에 따른 테스트 중 검증(Verification) 테스트
  - 소프트웨어 설계의 최소 단위인 모듈 개발 후 실시
  - 인터페이스, 외부 I/O, 자료 구조, 독립 기초 경로, 오류 처리, 경계 조건 등 검사
  - 주로 제어 흐름과 조건 결정을 목적으로 하는 구조 기반 테스트(White Box) 시행
  

5. 통합 테스트

• Integration Test
  - 모듈 결합하여 시스템 완성시키는 과정에서 테스트
  - 모듈 간 혹은 통합된 컴포넌트 간 상호 작용 오류 및 결함 검사
  • 비점진적 통합 방식
    • 모든 모듈이 결합된 프로그램 전체 대상(빅뱅 통합 테스트)
    • 규모 작은 소프트웨어
    • 오류 발견/장애 위치 파악 또는 수정 어려움
  • 점진적 통합 방식
    • 단계적 통합하며 테스트
    • 오류 수정 쉽고 인터페이스 관련 오류 완전 테스트

6. 하향식 통합 테스트

• Top Down Integration Test
  - 상위 모듈에서 하위 모듈로 통합하며 테스트(깊이 우선 통합법 / 넓이 우선 통합법)
  - 초기부터 시스템 구조 보여줌
  - 상위 모듈에서 테스트 케이스 사용 어려움
• 절차
  1. 작성된 프로그램으로 주요 제어 모델 쓰고 종속 모듈은 스텁(Stub)으로 대체
  2. 스텁을 순차적으로 실제 모듈로 교체
  3. 모듈 통합될 때마다 테스트
  4. 회귀 테스트(테스팅 반복)로 새로운 오류 없음을 보증

7. 상향식 통합 테스트

• Bottom Up Integration Test
  - 하위 모듈에서 상위 모듈로 통합하며 테스트
  - 최하위 모듈 단계부터 통합과 테스트 수행돼서 일시적으로 필요한 조건만 가지는 시험용 모듈(Stub) 불요
  - 제어 모듈의 관련 종속 모듈 그룹인 클러스터(Cluster) 필요
• 절차
  1. 하위 모듈을 클러스터로 그룹화
  2. 데이터 입/출력 확인 위한 더미 모듈(드라이버) 작성
  3. 클러스트 단위로 테스트
  4. 완료 후 클러스트를 상위로 이동하여 통합하고 드라이버(Driver)는 실제 모듈로 대체

8. 테스트 케이스

• Test Case
  - 사용자의 요구사항 준수 여부를 확인하기 위해 입력값, 실행 조건, 기대 결과 등의 테스트 항목 명세서
  • 명세 기반 테스트의 설계 산출물
  • 미리 설계 시 오류 방지하고 테스팅에 필요한 인력/시간 등의 낭비 줄임
• 순서
  1. 테스트 계획 검토 / 자료 확보
  2. 위험 평가 / 우선순위 결정
  3. 요구사항 정의
  4. 테스트 구조 설계 / 방법 결정
  5. 작성
  6. 타당성 확인 / 유지 보수

9. 테스트 시나리오

• Test Scenario
  - 적용 순서에 따라 테스트 케이스를 묶어 구체적 절차를 명세한 문서
  • 사전 조건, 입력 데이터 등 설정
  • 미리 정해서 테스트 항목을 빠짐없이 수행 가능
• 작성 시 유의 사항
  - 여러 시나리오(시스템별, 모듈별, 항목별 등)로 분리 작성
  - 요구사항 및 설계 문서 등 토대
  - 테스트 항목에 식별자 번호, 순서 번호, 데이터, 케이스, 예상 결과, 확인 등 포함
  - 유스케이스(Use Case) 간의 정상적인 업무 흐름 테스팅
  - 모듈 혹은 프로그램 간의 정상적인 동작 테스팅
  

10. 테스트 오라클

• Test Oracle
  - 테스트 케이스의 적용 결과가 참인지 판단하기 위해 값을 대입하여 비교하는 기법
• 특징
  - 제한된 검증
  - 수학적 기법
  - 자공화 기능
• 종류
  - 참(True): 미션 크리티컬(Mission Critical)한 업무에 사용
  - 샘플링(Sampling): 몇몇 테스트 케이스의 입력 값에 대해서만
  - 추정(Heuristic)
  - 일관성(Consistent) 등