일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 프로시저
- 소프트웨어
- 정처기 실기
- 트리거
- 자바스크립트
- 서버
- 비동기
- EAI
- 정처기
- 인스펙션
- 라디오 버튼
- 정보처리기사 실기
- 동기
- 리눅스
- input
- 델파이 기법
- 워크스루
- 정보처리기사
- esb
- Ajax
- S-HTTP
- rest
- 형상관리
- 인터페이스
- 모듈화
- 키보드 이벤트
- SSL/TLS
- 브레인스토밍
- 모듈
- javascript
- Today
- Total
방구석 상상코딩
27. 애플리케이션 통합 테스트 본문
목(Mock) 객체
객체지향 프로그램에서는 컴포넌트 테스트 수행 시 테스트되는 메서드가 다른 클래스의 객체에 의존하며, 이런 경우 메서드를 고립화하여 테스트하는 것이 불가능하므로 독립적인 컴포넌트 테스트를 위해서는 스텁의 객체지향 버전인 목 객체가 필요함
※ 목 객체 유형
유형 | 설명 |
더미 객체 (Dummy) | 테스트할 때 객체만 필요하고 해당 객체의 기능까지는 필요하지 않은 경우에 사용하며 더미 객체의 메서드가 호출되면 정상 동작은 수행하지 않고 예외 수행 |
테스트 스텁 (Stub) | 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로 더미 객체에서의 단순 기능에 특정 상태를 가정해서 특정한 값을 리턴하거나 특정 메시지 출력 |
테스트 드라이버 (Driver) | 테스트 대상 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출 |
테스트 스파이 (Spy) | 주로 테스트 대상 클래스와 협력하는 클래스로 가는 출력을 검증하는 데 사용 |
가짜 객체 (Fake) | 실제 협력 클래스의 기능을 대체해야 할 경우에 사용하며 실제 협력 클래스의 기능 중 전체나 일부를 훨씬 단순하게 구현 |
통합 테스트
1. 하향식 통합 테스트
메인 제어 모듈(프로그램)로부터 아래 방향으로 제어의 경로를 따라 이동하면서 하향식으로 통합하면서 테스트 진행
* 스텁(Stub) : 모듈 및 모든 하위 컴포넌트를 대신하는 더미 모듈로, 스텁은 하위 모듈의 반환 값만 전달하면 됨
- 깊이 우선 방식 : 주요 제어 모듈을 중심으로 해당 모듈에 종속된 모든 모듈을 통합하고, 다음 모듈의 종속된 모듈까지 통합하는 방법
- 넓이 우선 방식 : 구조의 수평을 중심으로 해당하는 모듈을 통합하는 방법
2. 상향식 통합 테스트
애플리케이션 구조에서 최하위 레벨의 모듈 또는 컴포넌트로부터 위쪽 방향으로 제어의 경로를 따라 이동하면서 구축과 테스트 수행
* 드라이버(Driver) : 상위의 모듈에서 데이터의 입력과 출력을 확인하기 위한 더미 모듈로, 드라이버는 상위 모듈 흐름을 작성해야 하기 때문에 스텁이 개발하기 쉬움.
3. 샌드위치 통합 테스트
상향식 통합 테스트 방식과 하향식 통합 테스트 방식을 결합한 테스트 방식으로 하위 프로젝트가 있는 큰 규모의 통합 테스트에서 사용하는 방식. 병렬 테스트가 가능하고 시간 절역이 가능.
4. 빅뱅 통합 테스트
모든 모듈을 동시에 통합 후 테스트 수행
테스트 자동화 도구 유형
1. 정적 분석 도구 (Static Analysis Tools)
- 만들어진 애플리케이션을 실행하지 않고 분석하는 도구
- 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함을 발견하기 위하여 사용
- 테스트를 수행하는 사람이 작성된 소스 코드에 대한 이해를 바탕으로 도구를 이용해서 분석
2. 테스트 실행 도구 (Test Execution Tools)
테스트를 위해 작성된 스크립트를 실행하고, 작성된 스크립트는 각 스크립트마다 특정 데이터와 테스트 수행 방법을 포함
- 데이터 주도 접근 방식
- 테스트 데이터를 스프레드 시트에 저장
- 다양한 테스트 데이터를 이용하여 동일한 테스트 케이스를 반복해서 실행할 수 있으며, 스크립트 언어에 익숙하지 않은 테스터도 미리 작성된 스크립트에 테스트 데이터만 추가하여 쉽게 테스트를 수행 - 키워드 주도 접근 방식
- 일반적으로 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 스프레드 시트에 저장
- 키워드를 이용하여 테스트 수행 동작을 정의할 수 있으며, 테스트 대상 애플리케이션의 특성에 맞추어 키워드에 대해 테일러링을 수행
소프트웨어 결함
- 에러(Error) / 오류
- 에러는 결함(Defect)의 원인이 되는 것으로, 일반적으로 사람(소프트웨어 개발자, 분석가 등)에 의해 생성된 실수 - 결함/결점/버그(Bug)
- 에러 또는 오류가 원인이 되어 소프트웨어 제품에 포함되어 있는 결함
- 이를 제거하지 않으면 소프트웨어 제품이 실패(Failure)하거나 문제(Problem)가 발생 - 실패/문제
- 소프트웨어 제품에 포함된 결함이 실행될 때 발생하는 현상
결함 분석 방법
- 구체화 (Specification) : 결함의 원인을 찾기 위해 결함을 발생시킨 입력값, 테스트 절차, 테스트 환경을 명확히 파악하는 방법
- 고립화 (Isolation) : 입력값, 테스트 절차, 테스트 환경 중 어떤 요소가 결함 발생에 영향을 미치는지 분석하는 방법
- 일반화 (Generalization) : 결함 발생에 영향을 주는 요소를 최대한 일반화시키는 방법
결함 생명주기별 결함 상태
결함 상태 | 설명 |
결함 등록 (Open) |
테스터가 테스트 절차를 실행하여 발견한 결함을 분석 후 구체화, 고립화, 일반화한 결함으로서 보고된 상태 결함 보고서에 기록되어 결함 추적의 대상이 된 상태 |
결함 검토 (Reviewed) |
Open된 결함의 처리 방안을 검토하는 상태 각 결함은 위험성(발생 가능성, 심각성, 긴급성)을 바탕으로 이번에 수정되거나 다음 릴리즈에서 수정되거나 무시 될 수 있음 |
결함 할당 (Assigned) |
결함을 수정할 개발자가 결정되고, 그 개발자에게 결함 해결이 요구된 상태 |
결함 수정 (Resolved) |
개발자가 자신에게 할당된 수정 사항에 대한 해결을 처리한 상태 |
결함 확인 (Verified) |
개발자의 결함 처리가 합당한지, 정확한지 검증이 완료된 상태 |
결함 종료 (Closed) |
수정된 사항에 대하여 정확한 수정이 이루어졌다고 판단되어 종료된 상태 |
결함 재등록 (Reopen) |
결함이 정확하게 수정되지 않아서 다시 수정을 요구하는 상태 |
결함 조치 보류 (Deferred) |
Open된 결함을 곧바로 수정하지 않고 다음 릴리스에서 해결하기로 연기된 상태 Deferred된 결함은 적절한 시점에 Reopen되어 결함 처리가 시작될 수 있음 |
결함 추이 분석
테스트완료 후 발견된 결함의 결함 관리 측정 지표의 속성 값들을 분석하고, 향후 애플리케이션의 어떤 모듈 또는 컴포넌트에서 결함이 발생할지를 추정하는 작업
※ 결함 추이 분석 유형
유형 | 설명 |
결함 분포 분석 | 각 애플리케이션 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함의 수를 측정하여 결함의 분포를 분석 |
결함 추세 분석 | 테스트 진행 시간의 흐름에 따른 결함의 수를 측정하여 결함 추세를 분석 |
결함 에이징 분석 | 등록된 결함에 대해 특정한 결함 상태의 지속 시간을 측정하여 분석 |
테스트 커버리지
주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준으로, 테스트의 정확성과 신뢰성을 향상시키는 역할을 함
결함 심각도
애플리케이션에 발생한 결함이 어떤 영향을 끼치며, 그 결함이 얼마나 치명적인지를 나타내는 척도
※ 결함 심각도 별 분류
분류 | 설명 | 예시 |
치명적(Critical) 결함 | 기능이나 제품의 테스트를 완전히 방해하거나 못하게 하는 결함 | 데이터 손실, 시스템 충돌 |
주요(Major) 결함 | 기능이 기대와 많이 다르게 동작하거나 그 기능이 해야하는 것을 못하는 결함 | 기능 장애 |
보통(Normal) 결함 | 제품이나 프로그램이 특정 기준을 충족하지 못하거나 전체에 영향을 주지 않는 일부 기능이 부자연스러운 결함 | 사소한 기능 오작동 |
경미한(Minor) 결함 | 사용상의 불편함을 유발하는 결함 | 표준 위반, UI 잘림 |
단순(Simple) 결함 | 사소한 버그라고 하며, 기능에는 영향이 없지만 수정되어야 하는 결함 | 미관상 좋지 않음 |
결함 관리 항목
항목 | 설명 |
결함 내용 | 테스트 중 발생한 결함 내용을 상세히 기재 조치자가 결함내용을 명확히 이해할 수 있을 정도로 상세히 기술 |
결함 ID | 결함 내용별로 부여하는 결함번호를 기재 |
결함 유형 | 결함 내용에 따라 결함이 발생한 유형의 코드를 기재 |
발견일 | 결함을 발견한 일자 |
심각도 | 애플리케이션에 발생한 결함이 어떤 영향을 끼치며, 그 결함이 얼마나 치명적인지를 나타내는 척도 치명적 결함 > 주요 결함 > 보통 결함 > 경미한 결함 > 단순 결함 |
우선순위 | 발생한 결함이 얼마나 빠르게 처리되어야 하는지를 결정하는 척도 결정적 > 높음 > 보통 > 낮음 |
시정 조치 예정일 | 결함에 대한 조치를 완료할 일자 |
수정 담당자 | 결함이 발생한 내용을 보완한 담당자명을 기재 |
재 테스트 결과 | 결함 내용이 정상적으로 수정되었는지 확인하기 위해 테스트한 결과를 작성 |
종료일 | 결함에 대해 모든 조치가 완료된 일자 |
'정보처리기사 실기' 카테고리의 다른 글
29. 운영체제의 특징 (0) | 2022.02.08 |
---|---|
28. 애플리케이션 성능 개선 (0) | 2022.02.06 |
26. 애플리케이션 테스트 케이스 설계 (0) | 2022.02.05 |
25. 소프트웨어 개발 보안 구현 (0) | 2022.02.05 |
24. 소프트웨어 개발 보안 설계 (0) | 2022.02.05 |