애플리케이션 테스트 케이스 설계
애플리케이션 테스트 케이스 작성
소프트웨어 테스트의 이해
1. 소프트웨어 테스트의 개념
구현된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능의 동작과 성능, 사용성, 안정성 등을 만족하는지 확인하기 위하여 소프트웨어의 결함을 찾아내는 활동
2. 소프트웨어 테스트의 필요성
(1) 오류 발생 관점
프로그램에 잠재된 오류를 발견하고 이를 수정하여 올바른 프로그램을 개발하는 활동
(2) 오류 예방 관점
프로그램 실행 전에 코드 리뷰, 동료 검토, 인스펙션 등을 통해 오류를 사전에 발견하는 예방 차원의 활동
(3) 품질 향상 관점
사용자의 요구사항 및 기대 수준을 만족하도록 반복적인 테스트를 거쳐 제품의 신뢰도를 향상하는 품질 보증 활동
3. 소프트웨어 테스트의 기본 원칙
(1) 소프트웨어 테스트의 원리
(가) 테스팅은 결함이 존재함을 밝하는 활동
: 결함이 발견되지 않아도 결함이 없다고 중명할 수 없음.
(나) 완벽한 테스팅은 불가능함. 리스크 분석와 우선순위를 토대로 테스트에 집중할 것.
(다) 테스팅은 개발 초기에 시작해야 함.
: SDLC(Software Development Life Cycle)의 각 단계에 맞춰 전략적으로 접근하는 것을 고려하는 것.
(라) 결함 집중(Defect Clustering)
: 애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재함.
(마) 살충제 패로독스(Presticide Paradox)
: 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 함.
(바) 테스팅은 정황(Context)에 의존
: 정황과 비지니스 도메인에 따라 테스트를 다르게 수행하여야 함.
(사) 오류-부재의 궤변(Absence of Errors Fallacy)
: 오류를 제거하였다 해도, 해당 애플리케이션의 품질이 높다고 말할 수도 없음.
(2) 소프트웨어 테스트 프로세스
(3) 소프트웨어 테스트 산출물
| 산출물 | 내용 |
| 테스트 계획서 | 테스트 목적과 범위 정의, 대상 시스템 구조 파익, 테스트 수행 절차, 테스트 일정, 조직의 역할 및 책임 정의, 종료 조건 정의 등 테스트 수행을 계획한 문서 |
| 테스트 케이스 | 테스트를 위한 설계 산출물로, 응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서 |
| 테스트 시나리오 | 테스트 수행을 위한 여러 개의 테스트 케이스의 집합으로 테스트 케이스의 동적 순서를 기술한 문서이며, 테스트를 위한 절차를 명세한 문서 |
| 테스트 결과서 | 테스트 결과를 정리한 문서로, 테스트 프로세스를 리뷰하고, 테스트 결과를 평가하고 리포팅하는 문서 |
4. 소프트웨어 테스트의 유형
1) 프로그램 실행 여부
(1) 정적 테스트
프로그램 실행 없이 소스 코드의 구조를 분석하여 논리적으로 검증하는 테스트
인스펙션, 코드 검사, 워크스루
(2) 동적 테스트
프로그램의 실행을 요구하는 테스트
화이트박스 테스트, 블랙박스 테스트
2) 테스트 기법
(1) 화이트박스 테스트
프로그램의 내부 로직(수행 경로 구조, 루프 등)을 보면서 테스트를 수행
기초 경로 검사
제어 구조 검사(조건검사, 루프검사, 데이터 흐름 검사)
(2) 블랙박스 테스트
프로그램의 외부 사용자 요구사항 명세를 보면서 테스트, 주로 구현된 기능을 테스트 함.
동치 분할 검사 : 타당한 입력자료와 타당하지 않은 입력자료의 개수를 같게 테스트케이스 작성
경계값 분석 : 입력조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용
결정 테이블, 상태전이, 유스케이스, 분류트리, 페어와이즈
3) 테스트에 대한 시각
(1) 검증(Verification)
제품의 생산 과정을 테스트(Are we building the product right?)
올바른 제품을 생산하고 있는지 검증하는 것을 의미
(2) 확인(Validation)
생산된 제품의 결과를 테스트(Are we building the right product?)
생선된 제품이 정상적으로 동작하는지 확인하는 것을 의미
4) 테스트 목적
| 회복(Recovery) 테스트 | 시스템에 고의로 실패를 유도하고 시스템이 정상적으로 복귀하는지 테스트 |
| 안전(Security) 테스트 | 불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스코드 내의 보안적인 결함을 미리 점검하는 테스트 |
| 강도(Stress) 테스트 | 시스템에 과다 정보량을 보과하여 과부하시에도 시스템이 정상적으로 작동되는지를 검증하는 테스트 |
| 성능(Performance) 테스트 | 사용자의 이벤트에 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는 속도 등을 테스트 |
| 구조(Structure) 테스트 | 시스템의 내부 논리 경로, 소스 코드의 복잡도를 평가하는 테스트 |
| 회귀(Regression) 테스트 | 변경 또는 수정된 코드에 대하여 새로운 결함 발견 여부를 평가하는 테스트 |
| 병행(Parallel) 테스트 | 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트 |
5. 테스트 종류
(1) 명세 기반 테스트
주어진 명세를 빠짐없이 테스트 케이스로 구현하고 있는지 확인하는 테스트
동치 분할, 경계 값 분석, 결정 테이블, 유스케이스, 분류트리, 페어와이즈, 직교분할 테스트
(2) 구조 기반 테스트
소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스
구문 기반, 결정 기반, 조건 기반, 조건결정 기반, 변경조건 결정 기반, 멀티조건 기반, 커버리지 테스트
(3) 경험 기반 테스트
유사 소프트웨어나 유사 기술 평가에서 테스트의 경험을 토대로 한, 직관과 가술 능력을 기반으로 수행하는 테스트
페어와이즈
테스트 케이스와 테스트 오라클의 이해
1. 테스트 케이스
특정한 프로그램의 일부분 또는 경로에 따라 수행하거나, 특정한 요구사항을 준수하는지 확인하기 위해 설계된 입력 값, 실행 조건,
기대 결과로 구성된 테스트 항목의 명세서
2. 테스트 케이스 작성절차
(1) 테스트 계획 점토 및 자료 확보 - 시스템 요구사항과 기능 명세서를 검토
(2) 위험 평가 및 우선순위 결정 - 테스트의 초점을 결정
(3) 테스트 요구사항 정의 - 테스트 대상 재검토, 테스트할 특성, 조건, 기능을 식별 및 분석
(4) 테스트 구조 설계 및 테스트 방법 결정
(5) 테스트 케이스 정의 - 입력 값, 실행 조건, 예상 결과를 기술
(6) 테스트 케이스 타당성 확인 및 유지 보수
3. 테스트 오라클의 개념
(1) 테스트 오라클 정의
테스트의 결과가 참인지 거짓인지 판단하기 위해서
사전에 정의된 참 값을 입력하여 비교하는 기법 및 활동
(2) 테스트 오라클 유형
(가) 참(True) 오라클
모든 입력에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클
(나) 샘플링(Sampling) 오라클
특정한 몇 개의 입력 값에 대해서만 기대하는 결과를 제공해 주는 오라클.
(다) 휴리스틱(Heuristic) 오라클
샘플링 오라클을 개선한 오라클로, 특정 입력 값에 대해 올바른 굘과를 제공하고, 나머지 값들에 대해서는 휴리스텍(추정)으로 처리
하는 오라클
(라) 일관성 검사(Consistent) 오라클
애플리케이션 변경이 있을 때, 수행 전과 후의 결과 값이 동일하지 확인하는 오라클.
V-모델과 테스트 단계
테스트 레벨 종류
| 종류 | 설명 |
| 단위 테스트 | 구현된 모듈(함수, 서브루틴, 컴포넌트 등)의 기능 수행 여부를 판정 내부에 존재하는 논리적 오류를 검출할 방안을 파악 |
| 통합 테스트 | 모듈 간의 인터페이스 연계를 검증하고, 모듈 간의 인터페이스 오류를 확인 모듈 간의 상호 작용 및 연계 동작 여부를 판정하는 방안을 파악 상향식, 햐향식 테스트 |
| 시스템 테스트 | 단위, 통합 테스트 후 전체 시스템이 정상적으로 작동하는지 판정하는 기능 명세를 확인하는 방안을 파악 기능, 비기능 요구사항 테스트 |
| 인수 테스트 | 사용자가 요구분석 명세서에 명시된 사항을 모두 충족하는지 판정 시스템이 예상대로 동작하고 있는지를 판정하는 파악을 파악 알파, 베타 테스트 |
인수 테스트
| 종류 | 설명 |
| 알파 검사 | 개발자의 장소에 사용자가 개발자 앞에서 행하는 검사 기법 통제한 환경에 오류, 문제점 등을 사용자와 개발자가 함께 확인 |
| 베타 검사 | 선정된 최종 사용자가 여러명의 사용자 앞에서 행하는 검사 기법 실제 업무룰 가지고 사용자가 직접 테스트하며 제어되지 않은 상태에서 검사 |
테스트 시나리오의 이해
1. 테스트 시나리오의 개념
(1) 테스트 시나리오의 정의
: 테스트 수행을 위한 여러 테스트 케이스의 집합으로서, 테스트 케이스의 동작 순서를 기술한 문서이며 테스트를 위한 절차를 명세
한 문서
(2) 테스트 시나리오의 필요성
: 테스트 수행 절차를 미리 정함으로써 설계 단계에서 중요시되던 요구사항이나 대안 흐름과 같은 테스트 항목을 빠짐없이 테스트하
기 위함
2. 테스트 시나리오 작성 시 유의점
(1) 테스트 시나리오 분리 작성
테스트 항목울 하나의 시나리오에 모두 작성하지 않고, 시스템별, 모듈별, 항목별 테스트 시나리오를 분리하여 작성
(2) 고객의 요구사항과 설계 문서 등을 토대로 테스트 시나리오를 작성
(3) 각 테스트 항목은 식별자 번호, 순서 번호, 테스트 케이스, 예상 결과, 확인 등의 항목을 포함하여 작성
테스트 환경 구축의 이해
1. 테스트 환경 구축의 개념
개발된 응용 소프트웨어기 실제 운영 시스템에서 정상적으로 작동하는지 테스트할 수 있도록 하기 위하여 실제 운영 시스템과 동일 또는 유사한 사양의 하드웨어, 소프트웨어, 네트워크 등의 시설을 구축하는 활동
2. 테스트 환경 구축의 유형
(1) 하드웨어 기반의 테스트 환경 구축
서버 장비(WAS 서버, DBSMS 서버), 클라이언트 장비(노트북 또는 PC), 네트워크(내부 LAN 또는 공용 인터넷 라인) 장비 등의 장비
를 설치하는 작업
(2) 소프트웨어 기반의 테스트 환경 구축
구축된 하드웨어 환경에 테스트할 응용 소프트웨어를 설치하고 필요한 데이터를 구축하는 작업
(3) 가상 시스템 기반의 테스트 환경 구축
물리적으로 개발 환경 및 운영 환경과 별대로 독립된 테스트 환경을 구축하기 힘든 경우에는,
가상 머신(Virtual Machine) 기반의 서버 또는 클라우드 환경을 이용하여 테스트 환경을 구축하고,
네트워크 VLAN과 같은 기법을 이용하여 논리적 분할 환경을 구축할 수 있음
테스트 데이터 및 테스트 조건의 이해
1. 테스트 데이터의 개념
: 컴퓨터의 동작이나 시스템의 적합성을 시험하기 위해 특별히 개발된 데이터 집합으로서 프로그램의 기능을 하나씩 순번에 따라 확
실하게 테스트할 수 있도록 조건을 갖춘 데이터를 말함
(1) 테스트 데이터 필요성
테스트 수행 시 잘못된 데이터를 사용면 잘못된 결과가 도출되어 시간을 낭비하고 비용만 소진하는 결과가 나옴. 따라서 테스트를 효
율적으로 운용하고 데이터의 기밀을 유지하며 신뢰 및 예측 가능한 테스트를 위해 테스트 데이터의 준비가 필요
(2) 테스트 데이터의 유형
선행된 연산에 의해 얻어진 실제 데이터와 인위적으로 만들어진 가상의 데이터로 구분
(3) 테스트 데이터 준비
실제 데이터는 연산에 의해 준비하거나 실제 운영 데이터를 복제하여 준비할 수 있으며, 가상의 데이터는 스크립트를 톨해서 생성할
수 있음
2. 테스트 시작 조건
(1) 테스트 시작 조건
테스트 계획의 수립, 사용자 요구사항에 대한 테스트 명세의 작성, 투입 조직 및 참여 인력의 역할과 책임의 정의, 테스트 환경의
구축 등이 완료되었을 때 테스트를 시작하도록 조건을 정의할 수 있으며, 단계별로 또는 회차별 테스트 수행을 위해 모든 조건을 만
족하지 않아도 테스트를 시작할 수 있음
(2) 테스트 종료 조건
테스트의 종료는 정상적인 테스트를 모두 수행한 경우, 차기 일정의 도래를 테스트 일정이 만료되었을 경우, 테스트에 소요되는 비
용을 모두 소진한 경우 등 업무 기능의 중요도에 따라 조건을 달리 정할 수 있음
(3) 테스트 성공과 실패의 판단 기준
기능 및 비기능 테스트 시나리오에 기술된 예상 결과를 만족하면 성공으로 아니라면 실패로 판단할 수 있으며, 또는 동일한 데이터
또는 이벤트를 중복하여 테스트하여도 여전히 이전 테스트와 같은 결과가 나올 때 성공으로 판단할 수도 있음