Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
Tags
- Linux
- 자격증공부
- 클라우드
- keyword
- 워게임
- 정보처리기사
- wargame
- 웹해킹
- 공부
- it자격증
- 취약점진단
- IT
- 기록
- reivew
- 리눅스
- 복습
- 자격증
- DreamHack
- 위험관리
- 보안용어
- 리눅스마스터2급
- 드림핵
- 케이쉴드주니어
- Security
- 보안
- study
- Shell
- Review
- webhacking
- 정리
Archives
- Today
- Total
IT Memory Note
[정보처리기사] 애플리케이션 테스트 관리 : 애플리케이션 통합 테스트 본문
1️⃣ 애플리케이션 테스트 수행
☆☆☆
(1) 단위 테스트(Unit Test)
1. 단위 테스트의 개념
- 단위(컴포넌트) 테스트는 개별적인 모듈(또는 컴포넌트)을 테스트함
- 구현 단계에서 각 모듈을 구현한 후 수행함
- 개별적인 모듈에 대해 컴포넌트 테스트를 수행하려면 모듈을 단독으로 실행할 수 있는 테스트 베드(Test Bed)라는 환경이 필요함
2. 단위 테스트 수행 도구
구분 | 설명 |
테스트 드라이버 (Test Driver) |
• 모듈 테스트 수행 후의 결과를 도출하는 시험용 모듈 • 필요 테스트를 인자를 통해 넘겨주고, 테스트 완료 후 그 결과값을 받는 역할을 하는 가상의 모듈 • 하위 모듈을 호출하는 상위 모듈의 역할 |
테스트 스텁 (Test Stub) |
• 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈 • 상위 모듈에 의해 호출되는 하위 모듈의 역할 |
(2) 통합 테스트(Integration Test)
1. 통합 테스트의 개념
- 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법
- 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인하는 테스트
2. 통합 테스트 방식
⓵ 하향식 통합 테스트(Top Down Integration Test) : 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
- 하위 모듈에서 반환 값을 전달하기 위한 더미 모듈인 스텁(Stub)을 사용함
⓶ 상향식 통합 테스트(Bottom Up Integration Test) : 프로그램의 하위 모듈에서 상위 모듈 방향을 통합하면서 테스트하는 기법
- 상위 모듈에서 데이터의 입출력을 확인하기 위한 더미 모듈인 드라이버(Driver)를 사용함
⓷ 빅뱅 통합 테스트(Big Bang Integration Test) : 모든 모듈을 동시에 통합한 후 테스트하는 기법
- 작은 시스템에 유리하고, 드라이버/스텁 없이 실제 모듈로 테스트를 수행함
⓸ 샌드위치 통합 테스트(Sandwich Integration Test) : 상향식 통합 테스트와 하향식 통합 테스트 방식을 결합한 테스트 방식
- 하위 프로젝트가 있는 큰 규모의 통합 테스트에서 사용하는 방식
- 병렬 테스트가 가능하고 시간 절약이 가능하고, 스텁과 드라이버의 필요성이 매우 높은 방식
(3) 테스트 자동화 도구
1. 테스트 자동화의 개념
- 테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현함으로써, 쉽고 효율적인 테스트를 수행할 수 있는 방법
2. 테스트 자동화 도구의 장단점
장점 | 단점 |
• 반복되는 테스트 데이터 재입력 작업의 자동화 • 사용자 요구 기능의 일관성 검증에 유리 • 테스트 결과값에 대한 객관적인 평가 기준 제공 • 테스트 결과의 통계 작업과 그래프 등 다양한 표시 형태 제공 • UI가 없는 서비스의 경우에도 정밀한 테스트 가능 |
• 도구 도입 후 도구 사용 방법에 대한 교육 및 학습 필요 • 도구를 프로세스 단계별로 적용하기 위한 시간, 비용, 노력이 필요 • 상용 도구의 경우 고가, 유지관리 비용이 높아 추가 투자가 필요 |
3. 테스트 자동화 도구의 유형
⓵ 정적 분석 도구(Static Analysis Tools) : 만들어진 애플리케이션을 실행하지 않고 분석하는 도구
- 대부분의 경우 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함을 발견하기 위하여 사용함
- 테스트를 수행하는 사람이 작성된 소스 코드에 대한 이해를 바탕으로 도구를 이용해서 분석하는 것
⓶ 성능 테스트 도구(Performance Test Tools) : 애플리케이션의 처리량, 응답 시간, 결과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트를 수행함으로써 성능 목표를 달성하였는지를 확인하는 도구
4. 테스트 하데스(Test Harness)
⓵ 테스트 하데스의 개념
- 시스템 모듈의 테스트를 위해 테스트를 자동화하거나 제어하기 위한 코드 및 도구의 집합\
⓶ 테스트 하네스 구성요소
구성요소 | 설명 |
테스트 드라이버 (Test Driver) |
상위 모듈에서 데이터의 입출력을 확인하기 위한 더미 모듈 |
테스트 스텁 (Test Stub) |
하위 모듈에서 반환 값을 전달하기 위한 더미 모듈 |
테스트 슈트 (Test Suites) |
테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합 |
테스트 케이스 (Test Case) |
입력 값, 실행 조건, 기대 결과 등의 집합 |
테스트 시나리오 (Test Scenario) |
• 애플리케이션의 테스트되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서 • 하나의 단일 테스트 시나리오가 하나 또는 여러 개의 테스트 케이스들을 포함할 수 있음 |
테스트 스크립트 (Test Script) |
자동화된 테스트 실행 절차에 대한 명세 |
목 오브젝트 (Mock Object) |
사용자의 형위를 조건부로 사전에 입력해 두면, 그 상황에 예정된 행위를 수행하는 객체 |
2️⃣ 애플리케이션 테스트 결함
☆
(1) 결함(Defect)
1. 결함의 개념
- 개발자 오류로 인해 만들어지는 문서 또는 코딩상의 결점으로 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 현상
2. 결함 관련 용어
용어 | 설명 |
오류(Error) | 결함의 원인이 되는 것으로, 일반적으로 사람(소프트웨어 개발자, 분석가 등)에 의해 생성된 실수(Human Mistake) |
결점(Fault) | 소프트웨어 개발 활동을 수행함에 있어서 시스템이 고장(Failure)을 일으키게 하며, 오류가 있는 경우 발생하는 현상 |
버그(Bug) | 프로그램 오류로 인해 예상치 못한 결과가 나는 현상 |
고장(Failure) / 문제(Problem) |
소프트웨어 제품에 포함된 결함이 실행될 때 발생하는 현상 |
(2) 결함 관리
1. 결함 관리의 개념
- 단계별 테스트 수행 후 발생한 결함의 재발 방지와 유사 결함 발견 시 처리 시간 단축을 위해 결함을 추적하고 관리하는 활동
2. 결함 생명주기별 결함 상태
결함 상태 | 설명 |
결함 등록 (Open) |
• 테스터가 테스트 절차를 실행하여 발견한 결함을 분석 후 구체화, 고립화, 일반화한 결함으로서 보고된 상태 • 결함 보고서에 기록되어 결함 추적의 대상이 된 상태 |
결함 검토 (Reviewed) |
• Open된 결함의 처리 방안을 검토하는 상태 • 각 결함은 위험성(발생 가능성, 심각성, 긴급성)을 바탕으로 이번에 수정되거나(Assigned 상태로 이동), 다음 릴리스에서 수정(Defered 상태로 이동)되거나 무시(Closed 상태로 이동)될 수 있음 |
결함 할당 (Assigned) |
결함을 수정할 개발자가 결정되고, 그 개발자에게 결함 해결이 요구된 상태 |
결함 수정 (Resolved) |
개발자가 자신에게 할당된 수정사항에 대한 해결을 처리한 상태 |
결함 확인 (Verified) |
개발자의 결함 처리가 합당한지, 정확한지 검증이 완료된 상태 |
결함 종료 (Closed) |
수정된 사항에 대하여 정확한 수정이 이루어졌다고 판단되어 종료된 상태 |
결함 재등록 (Reopen) |
결함이 정확하게 수정되지 않아서 다시 수정을 요구하는 상태 |
결함 조치 보류 (Deferred) |
• Open된 결함을 곧바로 수정하지 않고 다음 릴리스에서 해결하기로 연기된 상태 • Deferred된 결함은 적절한 시점에 Reopen되어 결함 처리가 시작될 수 있음 |
'자격증 > 정보처리기사' 카테고리의 다른 글
[정보처리기사] 응용 SW 기초 기술 활용 : 운영체제의 특징(1) (0) | 2024.09.01 |
---|---|
[정보처리기사] 애플리케이션 테스트 관리 : 성능 개선 (0) | 2024.09.01 |
[정보처리기사] 애플리케이션 테스트 관리 : 애플리케이션 테스트 케이스 설계(3) (0) | 2024.09.01 |
[정보처리기사] 애플리케이션 테스트 관리 : 애플리케이션 테스트 케이스 설계(2) (2) | 2024.09.01 |
[정보처리기사] 애플리케이션 테스트 관리 : 애플리케이션 테스트 케이스 설계(1) (0) | 2024.08.30 |