2. 소프트웨어 개발(어플리케이션 테스트 관리)

테스트케이스

특정 요구사항에 준수하는지 확인하기 위해 개발된 입력→실행조건→출력의 집합

• 정확성, 재사용성, 간결성을 보장해야함.

작성 절차

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

구성 요소

• 식별자(id)
• 테스트 항목
• 입력 명세: 테스트 실행 시 입력할 데이터 및 조건
• 출력 명세: 테스트 실행 시 기대값
• 환경 설정: 테스트 수행 시 필요한 하드웨어, 소프트웨어 환경
• 특수절차요구: 특별히 요구되는 절차
• 의존성 기술

테스트 오라클

결과가 참인지 거짓인지 판단하기 위한 사전 정의된 참값을 입력해 비교하는 기법

• 참 오라클: 모든 입력값에 대해 기대값을 생성해 오류 검출
• 샘플링 오라클: 샘플 입력값에 대해 기대값을 제공
• 휴리스틱 오라클: 샘플링 오라클 개선, 샘플링 이외 나머지를 추정
• 일관성 검사 오라클: 애플리케이션 변경 시, 수행 전, 후의 결과값이 동일한지 확인

테스트 레벨

함께 편성되고, 관리되는 독립적인 테스트 활동 그룹

종류

• 단위테스트: 사용자 요구사항에 대한 단위 모듈, 서브루틴등을 테스트
  • 명세기반(블랙박스)테스트와 구조기반(화이트박스)테스트로 나뉘지만 주로 구조기반
  • 인터페이스 테스트, 자료구조 테스트, 실행 경로 테스트, 오류 처리 테스트
• 통합 테스트: 단위 테스트 통과 후 컴포넌트 간의 인터페이스 테스트
  • 설계에서 제시한 어플리케이션과 동일한 구조, 기능인지 확인
  • 빅뱅 테스트, 상향식/하향식 테스트
• 시스템 테스트: 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트
  • 목적, 성능 목표를 가지고 텧스트
  • 기능/비기능 요구사항 테스트
    • 기능: 요구사항 명세, 비즈니스 절차, 유스케이스 등 명세서 기반 블랙박스 테스트
    • 비기능: 성능, 회복, 보안, 내부의 메뉴구조, 웹페이지의 내비게이션등 구조적 요소기반 화이트박스 테스트
• 인수 테스트: 계약상 요구사항이 만족되었나 테스트
  • 일부, 특정 비기능적 특성을 테스트
  • 알파/베타 테스트
    • 알파: 선택된 사용자가 개발자 환경에서 통제된 채 개발자와 수행
    • 베타: 실제 환경에서 일정 사용자에게 사용하게 하고 피드백을 받음(필드 테스팅)

소프트웨어 생명주기의 V모델

테스트 시나리오

애플리케이션의 테스트 되어야 할 기능, 특징, 테스트가 필요한 상황을 작성한 문서

• 테스트 수행 절차를 미리 정해 중요시되던 요구사항, 대안 흐름등의 테스트 항목을 빠짐없이 테스트.

유의점

• 시나리오 분리 작성: 하나의 시나리오에 모두 작성하지 않고, 시스템, 모듈, 항목별로 분리 작성
• 고객의 요구사항 설계 문서를 토대로 테스트 시나리오 작성
• 식별자 번호, 순서 번호, 테스트 데이터, 테스트 케이스, 예상 결과, 확인 등의 항목을 포함

테스트 지식 체계

소프트웨어 테스트 종류

• 프로그램 실행 여부, 테스트 상세 기법, 테스트에 대한 시각, 테스트 목적, 테스트 종류

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

• 정적 : 프로그램을 실행하지 않고 테스트
• 동적: 프로그램을 실행해보는 테스트

기법에 따른 분류

• 블랙박스: 요구사항 명세를 보며 수행(소프트웨어 특징, 요구사항, 설계 명세서)
  • 기능, 동작 위주 테스트이므로 내부 구조, 작동원리 없이 테스트 가능
  • 동등 분할 테스트: 입력 데이터의 영역을 도메인별로 그룹화 후 대푯값으로 테스트케이스 도출
  • 경곗값 분석 테스트: 등가분할 후 경곗값 부분을 포함해 테스트 케이스 도출(경곗값에 오류 많음)
  • 결정 테이블 테스트: 요구사항 논리, 발생 조건을 테이블로 나열, 조건 행위를 모두 조합 테스트
  • 상태 전이 테스트: 테스트 대상/시스템/객체의 상태가 이벤트로 전이되는 경우의 수를 테스트
  • 유스케이스 테스트: 유스케이스를 이용해 테스트
  • 분류 트리 테스트: SW의 일부, 전체를 트리 구조로 분석, 표현해 테스트케이스 설계
  • 페어와이즈 테스트: 테스트데이터간에 최소한 한번씩 조합하는 방식
  • 원인-결과 테스트: 그래프 활용해 데이터간에 관계, 출력에 미치는 영향 분석
  • 비교 테스트: 여러 버전의 프로그램에 같은 값을 넣어 동일한 데이터가 나오는지 비교
  • 오류 추정 테스트: 개발자가 범할 수 있는 실수를 추정, 이에 따른 결함이 검출되도록 테스트 케이스 설계
• 화이트박스: 코드 분석, 프로그램 구조의 지식으로 모듈 내부를 직접 관찰 테스트
  • 구문 커버리지: 프로그램 내의 구문을 모두 수행해보기
  • 결정 커버리지: 조건식의 참, 거짓 모두 수행해보기(최종결과)
  • 조건 커버리지: 조건식 내 개별 조건 하나하나의 참, 거짓 모두 수행
  • 조건-결정 커버리지: 조건 커버리지 + 결정 커버리지
  • 변경 조건-결정 커버리지: 개별 조건이 다른 조건들과 독립적으로 전체 결과에 영향을 미치는지 검증
  • 다중 조건 커버리지: 모든 개별 조건식의 조합을 100%보장하는 커버리지
  • 기본경로커버리지: 수행가능한 모든 경로를 테스트
  • 제어 흐름 커버리지: 프로그램 제어 구조를 그래프형태로 나타내어 테스트
  • 데이터 흐름 테스트: 제어 흐름 그래프에 데이터 사용 현황을 추가한 그래프를 통해 테스트
  • 루프 테스트: 프로그램의 반복 구조에 초점을 맞춰 실시

테스트 시각에 따른 분류

• 검증: 프로그램 개발 과정, 이전 단계서 설정한 요구조건 충족 여부, 명세화된 기능 수행
• 확인: 소프트웨어 결과 테스트, 만들어진 제품 동작 테스트, 최종 요구 테스트

목적에 따른 분류

• 회복 테스트: 고의로 실패 유도 후 시스템의 복귀 여부 판단
• 안전 테스트: 불법적 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 보안적 결함 테스트
• 성능 테스트: 사용자 이벤트에 시스템이 응답하는 시간업무량, 반응 속도를 측정
• 강도 테스트: 시스템 처리능력 이상의 부하를 걸어 처리를 테스트
• 구조 테스트: 논리 경로, 복잡도를 평가
• 회귀 테스트: 오류를 제거, 수정한 시스템에서 오류 제거, 수정에 의해 새로 유입된 오류를 테스트
• 병행 테스트: 변경된 시스템과 동일한 데이터 입력후 결과 확인

테스트 원리

• 결함 존재 증명, 완벽테스팅 불가
• 초기 집중: 개발 초기의 체계적 분석, 설계로 테스팅 기간, 재작업을 줄여 개발기간 단축
• 결함 집중: 적은 수의 모듈에서 대다수의 결함이 나옴(파레토의 법칙)
• 살충제 패러독스: 동일 테스트케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함.
• 정황의존성: 소프트웨어 성격에 맞게 테스트
• 오류-부재의 궤변: 요구사항을 충족하지 못하면 결함이 없어도 품질이 높은게 아니다.