2. 소프트웨어 개발
2.4 애플리케이션테스트 관리
2.4.3 애플리케이션 통합 테스트
1. 결함관리 도구
1.1 테스트 결함 관리란?
각 단계별 테스트 수행 후 발생한 결함의 재발 방지를 위해, 유사 결함 발견시 처리 시간 단축을 위해 결함을 추적하고 관리하는 활동이다.
테스트 결함 관리 도구는 이러한 결함관리를 자동화하는 도구이다.
1.2 결함 관리 도구 도입시 고려사항
웹 클라이언트 지원을 하는지 확인이 필요하다.
윈도우, 유닉스 환경 등 이기종 플랫폼의 웹 서버를 지원하는지 확인
프로세스 및 워크플로우 변경이 가능해야 한다.
결함 간에 연관관계 정보를 제공해야 한다.
예를들면 중복, 관계,부모관계 등
결함 등록 및 상태 변경 시 담당자에게 이벤트 통보기능이 되어야한다.
각종 레포트, 차트, 쿼리 구성 및 저장이 가능해야 한다.
결함 상태 변경에 대한 추적 기능이 되어야 한다.
다국어 지원이 가능해야 한다.
다중 프로젝트 지원이 가능해야 한다.
2. 테스트 자동화 도구
2.1 소프트웨어 테스트 자동화 란?
소프트웨어 개발 시 포함되는 다양한 테스트 과정을 하드웨어 혹은 소프트웨어적으로 자동화 도구를 사용하여 반복성, 일관성 및 생산성을 향상시키는 테스트 기법이다
테스트 자동화 도구는 테스트에 포함되는 다양한 과정을 자동적으로 지원하는 도구이다.
2.2 소프트웨엉 테스팅 도구 분류
소프트웨어 개발 사이클(SDLC) 전반에 걸쳐 테스트 자동화 도구가 존재한다.
소프트웨어 설꼐 단계에는 테스트 케이스 설계 자동화 도구가 사용되고, 구현 및 테스트 실행 단계에서는 정적/동적 분석도구, 커버리지 측정 도구 및 성능/부하/기능 테스트 도구가 사용된다.
2.3 소프트웨어 테스팅 자동화 도구 기능 및 역할
테스트 관리, 설계, 실행 단계별 테스트 자동화 도구의 기능 및 역할이 각각 다르다.
2.4 소프트웨어 테스트 관리 지원 도구
실행된 테스트와 테스트 활동 관리를 지원한다. 테스트 실행 도구나 결함 추적 도구, 요구사항 관리 도구와의 인터페이스 역할을 한다.
결함이 발견, 분배, 수정, 확인, 종료되는 결함의 수명주기를 관리한다.
테스트 진행 상황에 대한 리포트 생성, 발견도니 결함의 정량적인 분석을 지원한다.
2.5 소프트웨어 정적 분석 지원 도구
리뷰 프로세스에 관한 정보를 저장, 리뷰 코멘트를 저장한다.
정적 분석 도구는 동적 테스트를 하기 전에 결함을 발견할 수 있도록 지원한다.
특히, 코딩 표준을 지킬 것을 강제하고, 구조와 의존관계를 분석한다.
소스 코드의 복잡도를 측정한다.
2.6 소프트웨어 테스트 실행 및 로깅 지원 도구
스크립트언어의 도움으로 저장된 입력값과 예상 결과를 이용하여 테스트를 실행하고 실제 결과와 비교한다.
Capture and playback 도구라고도 한다.
테스트 대상이 실행되는 환경을 시뮬레이션 한다. 테스트 하네스 도구라고도 한다.
측정하고자 하는 특정 유형의 코드구조가 몇퍼센트 수행되었는가를 측정한다. 커버리지 측정 도구라고도 한다.
2.7 소프트웨어 성능 및 모니터링 도구
소프트웨어가 실행도중에만 발생하는 시간 의존성과 메모리 누수와 같은 결함 발견에 활용한다.
소프트웨어의 성능/부하/스트레스를 테스트한다.
특정 시스템 리소스의 사용량을 지속적으로 분석하고 확인한다.
3. 통합테스트
3.1 애플리케이션 통합 테스트 개요
1. 애플리케이션 통합 테스트란?
소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법이다.
단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인한다.
2. 애플리케이션 통합 테스트 수행 방법
점증적인 방법과 빅뱅 방식으로 나누어 진다.
점증적인 방식은 개발된 컴포넌트 중 일부를 테스트하고 점차적으로 컴포넌트를 늘려가면서 테스트하는 방식이다. 점증적인 방법은 다시 상향식 통합과 하향식 통합으로 나누어 진다.
빅뱅 방식은 모든 컴포넌트를 사전에 통합하여 한꺼번에 테스트하는 방식이다.
3.2 애플리케이션 통합 테스트 접근 전략
1. 하향식 통합
메인 제어 컴포넌트부터 아래 방향으로 제어의 경로를 따라 이동하면서 하향식으로 통합하면서 테스트를 진행한다.
메인 제어 컴포넌트는 작성된 프로그램을 사용하고, 아직 작성되지 않은 하위 제어 컴포넌트 및 모든 하위 컴포넌트를 대신하여 더미 컴포넌트인 스텁을 개발한다.
깊이-우선 방식 또는 너비-우선 방식에 따라, 하위 컴포넌트인 스텁이 한 번에 하나씩 실제 컴포넌트로 대체된다.
2. 상향식 통합
애플리케이션 구조에서 최하위 레벨의 컴포넌트로부터 위쪽방향으로 제어 경로를 따라 이동하면서 테스트를 시작한다.
최하위 레벨의 컴포넌트들이 하위 컴포넌트의 기능을 수행하는 클러스터로 결합된다.
상위 컴포넌트 개발이 안되었을 경우 더미 컴포넌트인 드라이버를 작성한다.
각 통합된 클러스터 단위를 테스트한다.
테스트가 완료되면 각 클러스터들은 프로그램의 위쪽으로 결합되며, 드라이버는 실제 컴포넌트로 대체된다.
3.3 애플리케이션 통합 테스트 유형
1. 회귀 테스트
통합 테스트 과정에서 오류를 제거하거나 수정한 프로그램이 새로운 형태의 오동작이나 오류를 일으킬 수 있다.
회귀 테스트는 이미 통합 테스트를 완료한 컴포넌트가 어떠한 변화로 인해 의도하지 않은 오류가 생기지 않았음을 보증하기 위해 반복 테스트하는 것을 말한다.
2. 애플리케이션 회귀 테스트 선정 기준
실제 수정이 발생한 컴포넌트와 관련된 테스트 케이스를 도출한다. 이를 위하여 변경 관리 도구를 사요하여 애플리케이션 변경 영향도 분석을 한다.
변경 영향도가 가장 높은 컴포넌트 기능에 집중한 회구 테스트 케이스를 도출한다.
3. 사용 기반 vs 스레드 기반 테스트
사용 기반 테스트는 사용자 중심의 시나리오 기반 테스트이다.
스레드 기반 테스트는 주요 기능의 모듈부터 점차 범위를 넓혀 나가는 통합 테스트 기법이다.
4. 빅뱅 vs 점증적 테스트
빅뱅 테스트는 모든 모듈을 한꺼번에 테스트하는 기법이다.
점증적 테스트는 주요 기능을 먼저 테스트 후 점차 범위를 넓혀가는 테스트이다.
3.4 애플리케이션 통합 테스트 수행 절차
1. 통합 테스트 케이스 설계
단위 테스트 케이스를 비즈니스 시나리오에 따라 여러 개를 묶고 이어서 통합 테스트 케이스를 만든다.
통합 테스트 케이스는 사용자 요구사항을 기준으로 작성한다.
2. 통합 테스트 데이터 준비
통합 테스트 데이터는 운영 데이터베이스에서 일부를 추출하여 테스트 데이터를 만든다.
예를들면, 운영.DB에서 1개우러 전까지의 데이터를 추출하여 테스트 DB에 전달한다.
보안을 위하여 테스트 데이터에서 개인정보는 스크램블링 한다.
3. 통합테스트 수행 및 결과 확인
테스트 수행 시 1개월 전부터 현재까지의 데이터를 애플리케이션에 그대로 입력하여 레거시와 비교검사를 한다.
테스트 케이스에 따라 데이터를 입력하고 예상 결과와 비교하낟.
4. 결함등록
테스트 결과가 예상 결과와 다를 경우 결함 등록을 한다.
이때, 결함 화면을 캡처하여 붙인다.
5. 테스트 결과 보고 및 종료
모든 통합 테스트 수행이 완료되면 결과 집계하여 보고하고, 종료한다.
3.5 애플리케이션 통합 테스트 시작 및 종료 기준
1. 통합 테스트 시작 기준
통합 테스트를 시작할 수 있는 기준을 정한다.
2. 통합 테스트 종료 기준
통합 테스트를 종료할 수 있는 기준 수립이 필요하다.
'자격증 > 정보처리기사' 카테고리의 다른 글
| 정보처리기사 23일차 (0) | 2021.02.02 |
|---|---|
| 정보처리기사 22일차 (0) | 2021.02.02 |
| 정보처리기사 20일차 (0) | 2021.01.30 |
| 정보처리기사 19일차 (0) | 2021.01.30 |
| 정보처리기사 18일차 (0) | 2021.01.28 |