목차
애플리케이션 테스트 케이스 설계
소프트웨어 테스트 (Software Test)
개념
노출되지 않은 숨어 있는 결함 (fault)을 찾기 위해 SW를 작동시키는 일련의 행위와 절차. 오류 발견을 목적으로 프로그램을 실행하여 품질을 평가하는 과정
테스트 절차
계획과 통제 (Planning & Control)
- 테스트 베이시스 검토
- 테스트 범위와 위험 결정, 목표의 설정
- 테스트 방법 및 자원 정의
- 테스트 정책/전략 결정, 프로세스 계획
- 종료 기준의 설정
- 산출물 : 테스트 계획서, 테스트 상태보고서
분석과 설계 (Analysis & Design)
- 테스트 상황 / 요구사항 / 데이터 식별
- 테스트 기법 할당
- 테스트 용이성 (Testability) 평가
- 테스트 환경 구축
- 산출물 : 테스트 케이스 설계 명세서
테스트 구현 / 실행 ( Implementaion & Execution)
- 테스트 케이스 명세화, 우선순위 선정, 데이터 생성, 프로시저 작성
- 선행 테스트
- 테스트 실행 (결과 기록)
- 테스트 오라클과 비교
- 산출물 : 테스트 대상물, 테스트 측정 결과
테스트 완료 조건 평가와 리포팅 (Exit Criteria Evaluation & Reporting)
- 계획에 정의된 종료 기준에 비교하여 테스트 로그 확인
- 추가 테스트 여부, 변경 여부에 따른 평가
- 완료 조건 달성 여부 확인
- 최종 테스트 보고서 작성
- 산출물 : 테스트 결과 보고서, 오류 수정 결과 보고서
테스트 마감 활동 (Test Closure Activities)
- 테스트웨어, 테스트 환경, 테스트 기반 구조 정리하고 최종적으로 승인
- 산출물 확인, 테스트웨어 보관
- 테스트 프로세스 평가
- Lessons Learned 분석
- 산출물 : 테스트 완료 보고서
테스트 기본 원리
테스팅은 결함의 존재를 밝히는 활동
- SW의 잠재적인 결함을 줄일 수 있지만, 결함이 발견되지 않아도 결함이 없다고 증명할 수 없음을 나타냄
완벽한 테스팅 (Exhaustive testing)은 불가능
- 무한 경로, 무한 입력 값, 무한 시간이 소요되어 완벽하게 테스트 할 수 없으므로 리스크 분석과 우선 순위를 토대로 테스트에 집중할 것을 의미
테스팅은 개발 초기에 시작해야 함
- 애플리케이션 개발 단계에 테스트를 계획하고 SDLC (Software Development Life Cycle) 각 단계에 맞춰 전략적으로 접근하는 것을 고려하라는 뜻
결함 집중 (Defect Clustering)
- 애플리케이션 결함 대부분은 소수의 특정 모듈에 집중되어 존재한다는 의미
살충제 패러독스 (Pesticide Paradox)
- 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 함
테스팅은 정황 (Context)에 의존
- 정황과 비즈니스 도메인에 따라 다르게 테스트 수행해야 함
오류 - 부재의 궤변 (Absence of Errors Fallacy)
- 요구사항을 충족시켜주지 못한다면, 결함이 없다고 해도 품질이 높다고 볼 수 없는 소프트웨어 테스트 원리
테스트 케이스 (Test Case)
개념
특정 프로그램 일부분 또는 경로에 따라 수행하거나, 특정한 요구사항을 준수하는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과로 구성된 테스트 항목 명세서
테스트 케이스 작성 절차
1. 테스트 계획 검토 및 자료 확보
- 테스트 대상 프로젝트 범위와 접근 방법 이해를 위해 테스트 계획 재검토
- 테스트 대상 시스템 자료와 정보 확보하여, 시스템 요구사항과 기능 명세서 검토
2. 위험 평가 및 우선순위 결정
- 결함 해결에 있어 상대적 중요성을 지니며 테스트 초점 결정
3. 테스트 요구사항 정의
- 시스템 요구사항, 테스트 대상 재검토, 테스트할 특성, 조건, 기능 식별 및 분석
4. 테스트 구조 설계 및 테스트 방법 결정
- 테스트 케이스의 일반적 형식 결정하고, 테스트 케이스 분류 방법 결정
- 테스트 절차, 장비, 도구, 테스트 문서화 방법 결정
5. 테스트 케이스 정의
- 각 요구사항에 대해 테스트 케이스 작성하고, 입력 값, 실행 조건, 예상 결과 기술
6. 테스트 케이스 타당성 확인 및 유지 보수
- 기능 또는 환경 변화에 따라 테스트 케이스 갱신하고, 테스트 케이스 유용성 검토
테스트 오라클 (Test Oracle)
개념
테스트 수행 한 결과가 참인지 거짓인지 판단하기 위해 미리 정의된 참 값을 대입하여 비교하는 기법 및 활동
테스트 오라클 유형
참 오라클 (True Oracle)
- 모든 테스트 케이스 입력 값의 기대한 결과 값에 대한 확인
- 가능한 모든 전수 테스트 가능
샘플링 오라클 (Sampling Oracle)
- 특정 몇몇 입력 값들에 대해서만 원하는 결과를 제공해 주는 오라클
- 전 범위 테스트 불가한 경우 사용
- 경계 값, 구간별 예상 값 결과 작성 사용
휴리스틱 오라클 (Heuristic Oracle)
- 샘플링 오라클 단점을 개선하기 위해 특정 몇몇 입력은 샘플링 오라클처럼 결과 제공
- 나머지 입력은 휴라스틱 (=경험)에 의한 처리
일관성 검사 오라클 (Consistent Oracle)
- 이전 수행 결과와 현재 수행 결과가 동일한지 검증
- 회귀 테스트 시 수정 전후 프로그램 실행 결과 확인 또는 비교 시 사용
- 모든 사용 테스트 자동화 도구에서 사용
테스트 오라클 적용 방안
- 참 오라클은 주로 항공기, 임베디드, 발전소 SW 등 미션 크리티컬한 업무에 적용
- 샘플링/추정 오라클은 일반, 업무용, 게임, 오락 등 일반적인 업무에 적용
테스트 레벨 (Test Level)
항목 | 설명 |
단위 테스트 (단위 검사) |
구현된 단위 모듈 (함수, 서브루틴, 컴포넌트 등) 기능 수행 여부 판정하고 내부에 존재하는 논리적 오류 검출 |
통합 테스트 (통합 검사) |
모듈 간 인터페이스 연계를 검증하고 오류 확인, 모듈 간 상호 작용 및 연계 동작이 제대로 기능하는지 점검 |
시스템 테스트 (시스템 검사) |
단위, 통합 테스트 후 전체 시스템이 정상적으로 작동하는지 판정하는 기능 점검 |
인수 테스트 (인수 검사) |
사용자 요구 분석 명세서에 명시된 사항을 모두 충족하는지 판정하고 시스템이 예상대로 동작하고 있는지 점검
|
테스트 시나리오 (Test Scenario)
개념
테스트 수행을 위한 테스트 케이스 집합. 테스트 케이스 동작 순서를 기술한 문서이며 테스트를 위한 절차 명세한 문서
테스트 시나리오 프로세스
1. 테스트 시나리오 도출
- 업무 기반으로 도출
- 업무 흐름에 따라서 시나리오를 스토리텔링 하듯이 도출
2. 테스트 케이스 도출
- 테스트 시나리오를 짧은 문장으로 나누어서 쉽게 테스트 할 수 있도록 생성
3. 테스트 케이스 검토 및 보완
- 테스트 케이스가 만들어 지면 품질 관리자와 테스트 리더가 검토
4. 테스트 케이스 피어리뷰 (동료 평가)
- 테스트 케이스가 시나리오에 맞게 작성 되었는지 검토
- 사용자 요구사항 테스트할 수 있게 작성 되었는지 점검
5. 테스트 케이스 업로드
- 테스트 케이스가 문제 없이 만들어 졌으면 테스트 관리 시스템에 업로드
테스트 시나리오 작성 시 유의점
- 테스트 항목을 하나의 시나리오에 모두 작성하지 않고, 시스템 별, 모듈 별, 항목 별 테스트 시나리오 분리하여 작성
- 고객 요구사항과 설계 문서 등을 토대로 테스트 시나리오 작성
- 각 테스트 항목은 식별자 번호, 순서 번호, 테스트 데이터, 테스트 케이스, 예상 결과, 확인 등 항목 포함하여 작성
테스트 지식 체계 (ISO 29119)
개념
SW 테스팅의 체계적 프로세스, 원리 및 가이드 지원 목적으로 SW 개발 생명 주기 전 과정에 걸쳐 있는 테스트 프로세스와 관련 산출물에 대한 국제 표준
테스트 지식 체계의 구성
구성 파트 | 구성 표준 | 설명 |
Part 1 (ISO 29119-1) |
개념과 정의 (Concepts & Definitions) |
전체에 대한 가이드 제공하는 부분으로 소프트웨어 테스팅 개념과 용어 정리 |
Part 2 (ISO 29119-2) |
테스트 프로세스 (Test Process) |
테스트 프로세스에 관한 부분으로 조직, 테스트 관리, 동적 테스트 세 가지 수준의 다계층 프로세스 모델 설명 |
Part 3 (ISO 29119-3) |
테스트 문서 (Test Documentation) |
테스트 문서 견본과 예시를 제공해주는 부분으로 테스트 프로세스 단계 별 산출 문서 작성 방법과 포함될 내용 제공 |
Part 4 (ISO 29119-4) |
테스팅 기술 (Testing Techniques) |
소프트웨어 테스팅 기법에 관한 부분으로 테스트 설계 및 구현 단계에서 활용 가능한 명세 기반, 구조 기반, 경험 기반 테스트 설계 기법 제공 |
Part 5 (ISO 29119-5) |
키워드 기반 테스팅 (Keyword-Driven Testing) |
키워드 주도 테스트에 대한 소개와 접근 방법 제공하는 부분으로 키워드 주도 테스팅을 위한 프레임워크, 도구에 대한 요구사항 |
테스트 기법
화이트 박스 / 블랙 박스
화이트 박스 개념
- 모듈 원시코드를 오픈 시킨 상태에서 원시 코드의 논리적인 모든 경로 검사하여 결함 찾는 테스트 기법
블랙 박스 개념
- 사용자 관점에서 원시 코드 보지 않고, 목적 코드 데이터 중심 입출력 기준으로 수행하여 결함 찾는 테스트 기법
- 기능 검사하기 위한 테스트 기법
화이트 박스 테스트 기법
○ 기본 경로 테스팅
- 프로그램 흐름 또는 논리적 경로 기반으로 테스트 케이스를 식별하는 테스팅 기법
- McCabe에 의해 제안된 대표적 화이트 박스 테스트 기법
○ 루프 (Loop) 테스팅
- 프로그램 루프 구조에 국한해서 실시하는 기법
- 루프 유형 : 단순 루프, 중첩 루프, 연결 루프, 비구조적 루프
○ 데이터 흐름 테스팅
- 프로그램 내에서 변수들이 값을 할당 받은 지점이나 사용된 지점에 따라 프로그램 테스트 경로들을 선택하는 방법
320x100
블랙 박스 테스트 기법
○ 동등 분할 테스팅 (Equivalence Partitioning Testing)
- 입력 값 범위를 유사한 특징을 갖는 동등 그룹으로 분리한 후, 대표 값을 선정하여 테스트하는 기법
- 하나의 값으로 분할 내 모든 값을 대표하는 것으로 간주하는 테스트 기법
○ 경계 값 분석 (Boundary Value Analysis)
- 주어진 입력 값 혹은 출력 값의 경계 값을 기준으로 테스트 케이스를 선정하는 기법
- 결함 발견율이 높고, 적용하기 쉬움
○ 의사 결정 테이블 테스팅 (Decision Table Testing)
- 주요한 의사 결정 요소를 표로 생성하고, 요소들 간 결합에 의해 TC(Test Case) 설계
- 요구사항 명세 분석하고, 시스템 조건과 동작에 대해 식별함으로서 테스트 케이스 설계
○ 페어와이즈 테스팅 (Pairwise Testing)
- 대부분 결함이 2개 요소 (Pair) 상호 작용에 기인한다는 것에 착안됨
- 각 값들이 다른 파라미터 값과 최소 한 번 씩은 조합을 이루도록 구성하는 테스트 기법
○ 유즈케이스 테스팅 (Use-Case Testing)
- 유즈케이스나 비즈니스 시나리오 기반으로 테스트 케이스 설계하는 기법
○ 분류 트리 테스팅 (Classification Tree Testing)
- 입력 값과 출력 값을 트리 형태로 만들어서 특정 입력 값에 따라 결정되는 출력 값이 정해지도록 만든 테스트 기법
○ 상태 전이테스팅 (State Transition Testing)
- 상태 전이 다이어그램 (State Machine) 기반으로 상태-이벤트 기반 시스템 동작 확인하는 테스트 기법
320x100
'정보처리기사 > 필기' 카테고리의 다른 글
[정보처리기사] Part02-04-03. 애플리케이션 성능 개선 (1) (5) | 2023.01.16 |
---|---|
[정보처리기사] Part02-04-02. 애플리케이션 통합 테스트 (13) | 2023.01.12 |
[정보처리기사] Part02-03. 데이터조작 프로시저 최적화 (34) | 2023.01.08 |
[정보처리기사] Part02-02. 데이터조작 프로시저 작성 (7) | 2023.01.08 |
[정보처리기사] Part02-01-1. 논리 데이터 저장소 확인 (7) | 2023.01.05 |
댓글