728x90
아래는 일반적인 프로젝트 테스트 방법론들에 대해 정리한 자료이다.
기본적으로 수행하는 테스트는 다음과 같다.
| Description | 계획시기 | 수행시기 | 계획/수행 주체 | |
| 단위테스트 |
• 구축의 각 단위별 완성도를 테스트
• 단위를 구성하는 각 구성요소의 완성을 전제로 단위레벨에서의 기능완성도, 기본적인 구성과 성능 및 Error Handling 등을 사전 정의된 데이터를 이용하여 테스트함
• NGM 의 경우, 단위의 레벨을 1 화면 레벨로 정의함
구성하는 UI Logic, Business Logic, Data Manipulation Logic, Rule 등을 포함함 |
구현단계 | 구현단계 | 각 개발팀 |
| 통합테스트 |
• 어플리케이션 시스템 간 연계되는 영역을 포함하여 기능 및 운영, 성능 전반에 대한 총괄적인 테스트 수행
• 단위로부터 범위를 확장해온 bottom-up approach 보다, 분석단계에서 정의한 바를 top-down로 approach 하며, 모든 종류의 Interface를 포괄하여 테스트 수행
• 하위 레벨 테스트 시에 수행된 모든 case 와 scenario를 포함하여 재 테스트함
|
설계단계 | 테스트단계 | 테스트 TF |
| 부하테스트 |
• 실 업무 규모의 부하테스트를 통해 시스템 처리 능력을 테스트 함
• 온라인 환경에서의 Stress Test 및 다량 데이터를 대상을 하는 High Volume 테스트 등을 수행함
|
설계단계 | 테스트단계 | 테스트 TF |
| 인수테스트 |
• 인수테스트 레벨에서는 단위àStringà시스템à통합 과 같은 영역의 확대 관점이 아닌 테스트의 목적상 차이를 갖음
• 인수테스트 (Acceptance Test) 레벨에서는 수행의 주체를 실 사용자/운영자로 하여 관점을 요구사항에 대한 Validation 로 전환하여 테스트를 수행하며 테스트의 목적은 오류가 존재하지 않음을 증명하는 것이 아니라 구현된 시스템으로 실제 업무를 수행할 수 있는지를 검증하는 데 있음
• 테스트 과정에는 실제 상황을 simulate 하는 리허설 방식의 수행 및 이행과정에 대한 테스트 등을 포함
|
분석단계 | 테스트단계 | 인수 TF (현업 사용자와 실 운영자로 구성) |
상세설명
단위테스트
| 테스트 명 | 단위테스트 | 비고 |
| 수행목적 및 개요 |
•프로그램의 각 부분을 고립 시켜서 각각의 부분이 정확하게 동작하는지 확인하는 것이다. 즉, 프로그램을 작은 단위로 쪼개서 각 단위가 정확하게 동작하는지 검사하는 것이다.
•White Box 중심 : 개발자 주도의 프로그램 소스 코드를 활용하여 테스트를 설계
•모듈 명세화 : 코드의 가시성, 단위 모듈의 반응에 주시
•테스트 관점 : 인터페이스, 자료구조, 수행경로, 오류처리, 경계 중심의 테스트 수행
|
•
|
| 적용분야 |
•인터페이스 테스트 : 파일 속성, 입력/출력 매개변수, 입출력 I/O(Input Output) 테스트
•자료구조 테스트 : 자료형태, 변수 초기화, 자료 형태의 일관성 테스트
•실행경로 테스트 : 다른 자료형태간 비교, 잘못된 루프 문 테스트
•오류처리 테스트 : 오류 메시지 이해 용이도, 오류 메세지 상세여부 테스트
|
•
|
| 프로세스 | 테스트 계획 수립 - 시험일정 계획 수립 .시험순서, 일정표,시험케이스 작성
.범위, 담당자, 성공/실패 기준 결정
※ 테스트 케이스 설계 . Risk 기반 우선순위 따른 모듈별 테스트 입력값, 결과 예측값 결정 . 테스트케이스 . 테스트 오라클 → 단위테스트 계획서 시험데이터 준비 - 사전준비사항 . 시험용DB구축, 속성목록 . 프로시저 및 실제 유형 메트릭스 - 시험데이터 구축 . 온라인 화면에서 입력 . 이행 프로시저 활용 테스트 수행 - 설계된 테스트 케이스 및 정책 기반으로 테스트 수행 - 단위시험 점검표에 의거 실시(설걔서 변경시 단위시험 점검표 수정) - 오류 발생시 단위시험 오류목록에 기록 - 뮤테이션 및 탐색적 테스트로 품질향상 결과 보고 - 결함내용, 심각도, 영향도, 수정여부 - 테스트 결과 보고서 - 오류사항 수정 요청서 |
•
|
통합테스트
| 테스트 명 | 통합테스트 | 비고 |
| 수행목적 및 개요 |
•단위 테스트가 끝난 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는 테스트
•실제 업무에서는 단위 모듈이 개별적으로 존재하는 것이 아니고 여러 모듈이 유기적 관계를 맺고 있으므로 이러한 모듈들을 결합한 형태로 테스트를 수행해봐야 한다. 이때 주로 확인하는 것은 '모듈 간의 상호작용이 정상적으로 수행되는가'이다.
•즉 모듈 사이의 인터페이스 오류는 없는지, 모듈이 올바르게 연계되어 동작하고 있는지를 체크한다.
|
•
|
| 기법 |
1. 점진적 모듈 통합 방법 : 하향식 기법
하향식(top-down) 기법은 시스템을 구성하는 모듈의 계층 구조에서 맨 상위의 모듈부터 시작하여 점차 하위 모듈 방향으로 통합하는 방법이다. - 장점 : . 오류 지역화가 더 쉽습니다. . 초기 프로토타입을 얻을 수 있는 가능성 . 중요한 모듈은 우선 순위에 따라 테스트 됩니다. 주요 디자인 결함이 발견되고 수정될 수 있습니다. -단점 : . 많은 스텁이 필요합니다. . 낮은 수준의 모듈은 부적절하게 테스트 됩니다. 2. 점진적 모듈 통합 방법 : 상향식 기법
상향식(bottom-up) 기법은 하향식 기법과는 반대로 가장 말단에 있는 최하위 모듈부터 테스트를 시작한다. 하향식에서 스텁이 필요했다면, 상향식에서는 상위 모듈의 역할을 하는 테스트 드라이버가 필요하다. 이 드라이버는 하위 모듈을 순서에 맞게 호출하고, 호출할 때 필요한 매개 변수를 제공하며, 반환 값을 전달하는 역할을 한다. - 장점 : . 오류 위치를 쉽게 파악할 수 있습니다. - 단점 : 응용 프로그램의 흐름을 제어하는 중요모듈(소프트웨어 아키텍처의 최상위 레벨에 있음)은 마지막에 테스트되며 결함이 발생할 수 있습니다. 초기 프로토 타입은 불가능합니다. 3. 빅뱅접근법 모든 구성요소가 한꺼번에 통합되어 테스트 됩니다. - 장점 : 소형 시스템에 편리합니다. - 단점 : . 오류 지역화는 어렵습니다. . 이 접근법에서 테스트해야 하는 수많은 인터페이스가 주어지면 테스트 할 인터페이스 링크가 쉽게 누락될 수 있습니다. . 통합 테스트는 모듈이 모두 설계된 후에 만 시작될 수 있으므로 테스트 팀은 테스트 단계에서 실행시간이 단축됩니다. . 모든 모듈이 한번에 테스트되므로 위험도가 높은 중요 모듈은 우선적으로 격리 및 테스트 되지 않습니다. 사용자 인터페이스를 처리하는 주변 모듈도 격리되지 않고 우선순위에 따라 테스트 됩니다. |
•
|
| 프로세스 | 테스트 계획 테스트 계획 단계에서는 프로젝트 계획서 , 요구 명세서 등을 기반으로 테스트 목표를 정의하고 테스트 대상 및 범위를 결정한다. 테스트 대상 시스템의 구조를 파악한다. 테스트에 투입되는 조직 및 비용을 산정한다. 테스트 시작 및 종료 조건을 정의한다. *테스트 시작 조건 : 테스트 게획, 일정 , 환경 구축 , 사용자 요구사항에 대한 테스트 명세서,투입 조직 및 참여 인력의 역할과 책임등이 완료되면 테스트가 시작되도록 조건을 정의 할 수 있으며, 모든 조건을 만족하지 않아도 테스트를 시작하도록 지정할 수 있다. 테스트 종료 조건 : 정상적으로 테스트를 완ㄹ한 경우 테스트 일정이 만료된 경우 테스트 비용이 모두 소진된 경우 등 업무 기능의 중요도에 따라 테스트 종료 조건을 다르게 지정할 수 있다. 테스트 계획서를 작성한다. 테스트 분석 및 디자인 테스트 분석 및 디자인 단계에서는 테스트의 목적과 원칙을 검토하고 사용자의 요구 사항을 분석한다. +테스트에 대한 리스크 분석 및 우선 순위를 정한다. +테스트 테이터 ,테스트 환경, 테스트 도구 등을 준비한다. 테스트 데이터 테스트 데이터는 시스템의 기능이나 적합성 등을 테스트 하기 위해 만든 테이터 집합으로 소프트웨어의 기능을 차례대로 테스트 할 수 있도록 만든 데이터 입니다. *잘못된 데이터는 잘못된 결과를 도출하기 때문에 효율적인 테스트를 위해서는 올바룬 테스트데이터를 준비해야 합니다. 테스트 데이터 종류 -실제 데이터- 선행된 연산에 의해 만들거나 실제 운영되는 데이터를 복제한 데이터 -가상데이터 - 스크립트를 통해 인위적으로 만든 데이터 테스트 케이스 및 시나리오 작성 -테스트 케이스 및 시나리오 작성 단계에서 테스트 케이스의 설계 기법에 따라 테스트 케이스를 작성하고 검토 및 확인한 후 테스트 시나리오를 작성한다. *테스트용 스크립트를 작성한다 - 테스트 스크립트는 테스트 실행 절차나 수행 방법등을 스크립트 언어로 작성한 파일입니다. 테스트 수행 테스트 수행 단계에서는 테스트 환경을 구축한 후 테스트를 수행한다. *테스트의 실행 결과를 측정하여 기록한다. 테스트 결과 평가 및 리포팅 *테스트 결과 평가 및 리포팅 단계에서는 테스트 결과를 비교 분석하여 테스트 결과서를 작성한다. *테스트 결과서는 결함 내용 및 결함 재현 순서등 결함을 중점적으로 기록한다. *테스트가 종료되면 테스트 실행 절타의 리뷰 및 결과에 대한 평가를 수행하고 그 결과에 따라 실행 절차를 최적화하여 다음 테스트에 적용한다. 결함 추적 및 관리 결함 추적 및 관리 단계에서는 테스트를 수행한 후 결함이 어디에서 발생했는지 어떤 종류의 결함인지 등 결함을 추적하고 관리한다. 결함 추적 및 관리를 통해 동일한 결함 발견시 처리 시간 단축 및 결함의 재발등을 방지 할 수 있다 |
•
|
MassData 테스트
| 테스트 명 | 단위테스트 |
| 수행목적 및 개요 | 기존 시스템에서 사용하는 실데이터를 추출하여 To-Be 기준으로 변환 후 시스템에서 테스트를 수행함으로써 실제 운영환경에서의 안정성, 데이터 품질 등을 동시에 점검함 |
| 검증항목 | - 대량처리 : 실제 운영 상 발생 가능한 수준의 대량 데이터를 이상없이 처리하는지 검증 ※ 테스트 목적에 부합하는 Volume 선정 필요 - 예외검증 : 기존 시스템에서 추출한 실 데이터에 포함된 예외 케이스를 테스트하여 프로세스 및 시스템 보완 - 인터페이스 : 대량 데이터 인터페이스 테스트를 통해 연계시스템 간 처리능력을 검증 - 결산 Activity : 실제 데이터로 결산 Activity를 진행하면서 단계별 처리능력 검증 및 기존 시스템과 결과데이터 비교하여 신뢰성 확보 - 기타 : 보안, 호환성, 신뢰성, 복구, 유지보수 용이성 등 검증 |
| 프로세스 | 통합테스트 시 대량데이터 유발 시나리오 추가하여 진행하는 경우가 많음 |
부하테스트
| 테스트 명 | 부하테스트 | 비고 |
| 수행목적 및 개요 |
•적절한 부하를 발생시켜 통계적으로 의미있는 수치를 측정하는 테스트
•성능테스트(Performance Test) 관점에서의 부하(Load)는 최소레벨(0 tps)에서부터, 리소스 고갈 상황이나 기형적인 응답시간의 극심한 저하 혹은 트렌젝션 실패 등과 같은 상황이 발생하기 직전까지의 최대 레벨(Maximum tps)까지 다양한 부하적용으로 신뢰성 검증
•테스트 대상 어플리케이션에 현재 또는 예상되는 수준의 Peak시 부하를 발생시켜 성능목표(응답시간/Throughput)의 만족 여부를 확인하는 테스트
•실 운영 시 예상되는 총 부하 수준의 트랜잭션 재현을 통한 시스템 전반의 최적화 •운영시스템의 규모의 적정성을 평가하고 시스템의 비정상 요소를 도출하여 제거한 뒤 시스템 전반의 규모 및 Flow가 고객의 요구수준에 부합할 수 있도록 하기 위함 |
•
|
| 프로세스 | 1. 요구사항 분석 1) 시스템의 종류(신규,기존,개편) 2) 신규업무(설계 당시 산정한 사용자수와 TPS등) 3) 기존업무(향후 기대치, 예상 TPS 측정 등) 4) 개편업무(개편전, 개편후 측정, 원하는 항목 폭표치 부응 등) 5) 개념적인 목표정의(전체 TPS 또는 개별 TPS) 2. 운영 및 신규 시스템 분석 1) SYSTEM Configuration 2) Architecture(H/W, S/W) 3) Logical Architecture 4) Application Flow 3. 부하테스트 계획 수립 1) 테스트 대상 선정 2) 테스트 입/출력 데이터 준비 3) 테스트 시나리오 선정 4) 테스트 계획서(DTP:Detail Test Plan) 5) 테스트 케이스 문서 작성 6) 부하 수행 장비 준비 4. 성능 목표 수립 1) 기본성능 목표 수립 2) 임계성능 목표 수립 3) 현생 시스템 성능(기존업무 또는 개편업무 일 경우 대비) 5. 담당자 구분 및 절차 구성 1) 모니터링 담당자 R&R 구분 2) 해당 담당자별 성능 모니터링 항목 설정 3) Logical Architecture 4) Application Flow 6. Virtual User 생성(VuGen, LoadRunner 기준) 1) 테스트 스크립트 생성(레코딩 등) 2) 스크립트 테스트 파라미터 설정 7. Senarios 작성(Controller, LoadRunner 기준) 1) 가상 사용자 실행기 정의 2) Test script 정의 3) Vuser 정의 (Vuser 수, Test scripts, Host, Run Schedule 등) 4) 모니터링 설정 8. Controller 지시에 따른 부하발생 1) 부하 생성
2) Scenario 리허설
3) Vusers 수행로그에서 오류 여부 조사
4) transactions별 응답시간 검토
5) 부하 Scenario 실제 수행
|
※ LoadRunner 관련
LoadRunner는 웹 서비스, 데이터베이스, 원격 터미널 에뮬레이터 등 폭넓은 애플리케이션 환경과 프로토콜에 대한 성능 및 부하 테스트를 지원. 스튜디오를 활용하여 스크립트 작성에 소요되는 시간 단축
특징 :
•LoadRunner가 제공하는 직관적이고 편리한 IDE를 통해 개발 환경과 통합하여 LoadRunner 엔진으로 테스트를 실행
•실제 사용자 동작을 에뮬레이션하도록 스크립트를 손쉽게 수정
•다양한 프로토콜을 지원하고, 설치 및 사용이 용이하며, 대규모 워크로드를 처리
•제작사 : MicroFocus/Hewlett-Packard
부하유발 작동 프로세스 :
• VuGen
[VuGen(Virtual User Generator)로 스크립트 생성]
[VuGen의 Runtime 설정]
↓
[부하 컨트롤러 서버에 Agent 설치]
[부하 컨트롤러 서버에 Script Import 및 실행]
유용한 부하측정 지표 :
| 항 목 | 내 용 |
| Maximum Running Vusers | 최대 실행 가상 사용자 수(최대 부하 발생 유저) |
| Total Throughput (bytes) | 가상 사용자가 서버로부터 받은 데이터의 전체 처리량 Byte |
| Average Throughput (bytes/Seconds) | 가상 사용자가 서버로부터 받은 데이터에대한 초당 평균 처리량 Byte |
| Total Hits | Web Server에 가상 사용자에 의해 만들어진 전체 HTTP Request 수 |
| Average Hit per Second | Web Server에 가상 사용자에 의해 만들어진 초당 평균 HTTP Request 수 |
| Transaction Name | 스크립 작성시 실사용자 관점에서 업무 처리에 대한 Event로 구분한 트랜잭션 이름. |
| Minimum | 트랜잭션 응답시간의 측정 결과에 대한 최소 응답 시간(전체 수집 데이터 중 최소값) |
| Average | 트랜잭션 응답시간의 측정 결과에 대한 평균 응답 시간(전체 수집 데이터의 평균값) |
| Maximum | 트랜잭션 응답시간의 측정 결과에 대한 최고 응답 시간(전체 수집 데이터의 최고값) |
| Std | 평균 응답 시간 기준에 대한 변량이 흩어져 있는 정도(표준편차) |
| 90 Percent | 측정한 트랜잭션 응답시간으로 부터 정렬된 전체 데이터 중 90% 지점에 해당 되는 값 (응답시간에 대한 최고값을 보정하기 위한 값) |
| Pass | 스크립상에 구분한 각 트랜잭션에 대하여 처리되어 통과한 수 |
| Fail | 스크립상에 구분한 각 트랜잭션에 대하여 처리되지 못하여 실패한 수 |
| Stop | 스크립상에 구분한 각 트랜잭션에 대하여 중지된 수 |
UAT
| 테스트 명 | UserAcceptanceTest | 비고 |
| 수행목적 및 개요 |
•공급자와 사용자 간의 계약한 결과물의 기준과 사양을 기준하여 사용자는 소프트웨어가 합의된 기준을 충족하는지 검증한다.
•고객 조직은 직원 교육, 소프트웨어 유지보수 및 오류를 처리하는 방법과 같은 기준을 측정하여 소프트웨어 사용 준비를 결정한다.
•소프트웨어가 사용자의 규제 또는 컴플라이언스 요구를 충족하는지 검증한다.
|
•통합테스트 이후
|
| 프로세스 |
사용자 시험 계획 수립
- 시험케이스 분류 . 시험그룹은 업무영역 단위
. 시험케이스는 단위처리, 시스템간 인터페이스, 성능평가
- 시험계획서. 시험목적 및 범위, 시험방법, 시험케이스분류, 시험점검표, 시험일정계획
. 품질보증팀의 검토
. 테스트 사례 설계 : 테스트 사례는 실제 사용시 소프트웨어의 모든 기능 시나리오를 포괄하도록 설계되었습니다. 테스터가 테스트 프로세스를 쉽게 수행 할 수 있도록 간단한 언어와 방식으로 설계되었습니다.
. 테스트 팀 선택 : 테스트 팀은 실제 최종 사용자로 구성됩니다.
※계획 : UAT 전략은 계획 단계에서 설계합니다
시험실시 - 사전준비사항 . 시험용 DB구축, 속성목록
. 프로시저 및 실제유형 매트릭스 시험실시 . 테스트 케이스 실행 및 문서화 : 테스트 팀은 지정된 테스트 케이스를 실행합니다. 때로는 관련 무작위 테스트를 수행하기도합니다. 모든 버그는 관련 설명과 함께 테스트 문서에 기록됩니다.
평가 - 기능/성능 시험 결과 사용자시험 완료 - 버그 수정 : 테스트 팀이 발견 한 버그에 대응하여 소프트웨어 개발 팀은 코드를 최종 조정하여 소프트웨어에 버그가 없도록합니다. - 사인 오프 : 모든 버그가 수정되면 테스트 팀은 소프트웨어 응용 프로그램의 승인을 나타냅니다. 이는 응용 프로그램이 사용자 요구 사항을 충족하고 시장에 출시 될 준비가되었음을 나타냅니다.
|
•
|