■ 테스트의 목적
- 개발된 소프트웨어를 검증하고 fault를 최소화해 사용자에게 높은 품질의 신뢰성 있는 소프트웨어를 제공
■ 테스트의 문제점
- 소프트웨어 기능이 복잡해짐에 따라 모두 케이스의 테스트가 불가.
- 소프트웨어는 요구사항, 스펙, 테스트케이스 사이의 갭으로 테스트되지 않은 부분이 존재
- 개발완료전 운영 환경과 동일한 환경을 만들어 테스트하기 힘들다는 환경적인 제약
- 테스트 결과를 통해 소프트웨어 품질을 확신의 한계
- 테스트를 완벽하게 지원하는 툴이 없어 많은 시간이 소요
- 전문성있는 테스트 인력이 부족.
- 개발 마지막 단계에 집중되어 있어 검증을 위한 충분한 시간이 주어지지 않음.
■ 테스트 검증항목
|
Basic 품질요소(비기능적)
|
Extra 품질요소(기능적)
요구사항의 시나리오대로 잘 동작하고 올바른 결과를 리턴하는지 확인
|
|
Reliability
|
Adaptability
|
|
Functionality
|
Flexibility
|
|
Safety
|
Repairability
|
|
Ease of Use
|
Enhanceability
|
|
Economy
|
Understandability
|
■ 테스트 절차도
■ 테스트 유형
|
테스트 절차
|
내용
|
방법
|
|
Test Plan
|
테스트 계획서 작성
|
요구분석과 설계 결과를 통해 테스트케이스를 작성
품질 확보 방안 및 절차에 대해 계획을 수립
|
|
Unit Test
|
분리된 기능에 대한 검증
|
Unit Test Framework를 이용하여 개발자가 테스트
|
|
Integration Test
|
컴포넌트간의 상호작용 검증
|
테스트 입력 값을 만들어 실행한 후 결과확인
|
|
System Test
|
전체시스템 동작 테스트
|
암복호화 데이터의 처리결과 확인(security)
데이터의 처리시간을 통해 시스템의 속도측정(speed)
정확한 데이터 처리확인(accuracy)
성공률과 실패율 확인(reliability)
|
|
Acceptance Test
|
사용자 요구사항 처리 검증
|
사용자의 요구기능을 입력하고 기능이 정확하게 수행하는지 검증
|
|
Installation Test
|
설치환경과 설치절차 검증
|
설치파일을 이용하여 설치 후 정상적으로 동작하는지 확인
|
|
Performance Test
|
시스템의 성능 검증
|
실행시간,응답시간,처리능력 측정으로 시스템 성능 측정
|
|
Stress Test
|
시스템의 강도 검증
|
시스템에 과부하(비정상적인 양, 빈도,부피)를 주어 시스템의 반응 확인
|
■ 테스트 수행 절차
|
절차
|
수행내용
|
|
Test planning
|
테스트 계획 수립 및 Test Plan 작성
|
|
Test case generation
|
테스트 항목 결정 및 Test case 작성
|
|
Test environment development
|
테스트 환경 구축
|
|
Test module development
|
테스트 툴 설계 및 개발
|
|
Execution
|
테스트 수행
|
|
Test results evaluation
|
테스트 결과 분석
|
|
Problem reporting / Test log
|
문제점 분석 및 테스트 로그 분석
|
|
Defect tracking
|
결함 추적 및 수정
|
■ 단위테스트 상세설명
- 변경된 모듈이 다른 모듈에 주는 영향을 찾아내어 해결하려는 목적
- 개발 단계에서 소스 코드의 특정 모듈이 정상적으로 동작하는지 내부적으로 검증하고
유지보수 단계에서 소스 코드의 변경이 다른 곳에 영향을 주는지 검증
- 단위 테스트는 다양한 방법과 시각으로 계획을 수립하고 진행되어야 함
- 단위테스트 케이스를 만들어 테스트하고 소프트웨어 변경시마다 테스트 케이스를 수행함으로써
변경으로 인해 발생할 수 있는 문제를 검증
▶ 단위테스트 유형
|
테스트 구분
|
테스트 유형
|
|
Block Box Testing
|
소프트웨어를 Black Box로 보고 테스트케이스에 대한 출력 값이 옳은지를 판단
- Program의 모든 부분을 검증하기가 불가능
- Partition Testing,Boundary Testing,Random Testing
|
|
White Box Testing
|
-소프트웨어의 코드 로직을 고려한 다양한 테스트케이스를 통해 소프트웨어를 테스트
-Statement Testing,Branch Testing
|
▶ Partition Testing
- 테스트케이스를 결정할 때 도메인 영역별로 나누고 여러가지 값 중에서 테스트를 위한 입력 값을 선택하여 테스트케이스로 선정하는 방법
▶ Boundary Testing
- Boundary를 기준으로 유효한 값과 유효하지 않은 값을 테스트케이스로 선택.
▶ Random Testing
- 테스트케이스는 입력값을 Random하게 선택하여 테스트
▶ Statement Testing
- 모든 가능한 프로그램 상태에 대해 테스트할 수 있도록 테스트케이스를 선택
- 프로그램의 모든 코드가 한번 이상 실행될 수 있도록 테스트케이스를 선택
▶ Branch Testing
- Statement Testing보다는 제한적이며 소프트웨어 내부 조건 분기에서 모든 부분을 테스트할 수 있도록 테스트케이스를 선택
■ 테스트시 고려사항
- 프로젝트의 성격과 품질 요구사항을 고려하여 테스트 방식을 선택하고 진행
- 테스트를 통해 최대한 많은 결함을 잡아내기 위해서는 반복적으로 다양한 방법을 사용하여 테스트를 진행
- 테스트 비용을 줄이기 위해서는 프로젝트 모든 단계에서 테스트를 진행하여 초기부터 소프트웨어의 리스크를 감소
