애플리케이션 통합 테스트
애플리케이션 통합 테스트
결함 관리 도구
개념
각 단계 별 테스트 수행 후 발생한 결함 재발 방지를 위해 유사 결함 발견 시 처리 시간 단축을 위해 결함 추적 및 관리하는 활동인 테스트 결함 관리를 자동화 하는 도구
결함 관리 도구 유형
| 구분 | 도구 | 설명 |
| 상용도구 | QC (Quality Center) |
HP에서 만든 결함관리 도구 |
| Clear Quest | IBM에서 제작한 결함관리 도구 | |
| JIRA | 아틀래시안에서 만든 결함 상태관리 도구 | |
| PHP로 개발됨 | ||
| 오픈소스 도구 |
Bugzilla | 설치가 다소 까다로우며, 개발 언어는 Perl 사용 |
| 서버는 MySQL과 PostgreSQL 지원 | ||
| 다양한 플러그인 기능 제공 (eclipse, SVN, 프로젝트 관리 도구 등) | ||
| Trac | 버그 관리, 개발 Task용 이슈 관리, 소스 코드 형상 관리 및 위키 기반 문서 관리 | |
| Python으로 작성되어 있고, DB는 SQLite 사용 | ||
| 웹에서 게시판 형태로 사용 용이하며 티켓 발행으로 팀원 간 원할한 의사소통 제공 | ||
| Mantis | 버그 관리에 최적화되어 있고, 설치와 사용법이 매우 쉬우며 결함만 관리한다면 권장하는 도구 | |
| OS에 관계없이 PHP와 MySQL, Apache(IIS)만 있으면 사용 가능 |
결함 관리 도구 고려사항
- 웹 클라이언트 지원을 하는지 확인 필요
- Window, Unix 환경 등 이기종 플랫폼 웹 서버 지원하는지 확인 필요
- 프로세스 및 워크플로우 변경 가능해야 함
- 결함 간 연관 관계 정보 제공해야 함
- 중복 (duplicate), 관계 (related), 부모 관계 (mother/daughter) 등의 정보
- 결함 등록 및 상태 변경 시 담당자에게 이벤트 통보 되어야 함
- 각종 레포트, 차트, 쿼리 구성 및 저장 가능해야 함
- 결함 상태 변경에 대한 추적 기능 있어야 함
- 다국어 지원 가능해야 함
- 다중 프로젝트 지원 가능해야 함
테스트 자동화 도구
개념
소프트웨어 테스트 자동화란 소프트웨어 개발 시 포함되는 다양한 테스트 과정을 HW 또는 SW 적으로 자동화 도구 사용하여 반복성, 일관성, 및 생산성 향상시키는 테스트 기법.
테스트 자동화 도구란 테스트에 포함되는 다양한 과정 (테스트 관리, 소스코드 리뷰 및 인스펙션, 테스트 설계 및 개발, 테스트 수행 등)을 자동적으로 지원하는 도구
소프트웨어 테스트 자동화 도구 분류
소프트웨어 개발 라이프 사이클 (SDLC, Software Development Life Cycle) 전반에 걸쳐 테스트 자동화 도구가 존재
| 단계 | 도구 유형 | 설명 |
| 설계 단계 | 명세 기반 테스트 설계 도구 | 소프트웨어 명세로부터 테스트 절차, 데이터, 드라이버 등 생성 |
| 코드 기반 테스트 설계 도구 | 소스 코드로부터 테스트 절차, 데이터, 드라이버 등 생성 | |
| 테스트 관리 도구 | 테스트 계획 수립, 프로세스 관리, 요구사항 및 결함 추적 관리 | |
| 구현/테스트 단계 |
정적 분석 도구 | 프로그램 수행하지 않고 분석하는 도구, 복잡도 측정 등 |
| 리뷰 및 인스펙션 도구 | 소스 코드/설계 문서 분석하여 가이드 라인 및 규칙 준수 검사 | |
| 커버리지 측정 도구 | 주어진 테스트 케이스에 의해 얼마나 테스트 되었는가를 측정 | |
| 동적 분석 도구 | 프로그램 수행되는 동안 이벤트 상태 파악 위해 특정 변수나 조건의 스냅샷 (snapshot) 생성 및 활용 | |
| 성능/부하/시뮬레이션 도구 | 시스템 부하 생성 및 반응시간, 메모리 사용량 평가 | |
| 기능 테스트 수행 도구 | 주어진 테스트 케이스 자동 수행 및 예상 결과와 비교. 단위, 통합, 시스템, 인수 모든 단계에서 수행 |
※ V 모델은 폭포수 모델에 시스템 검증과 테스트 작업을 강조한 모델로, 11개의 소프트웨어 테스팅 프로세스로 구성된 효과적인 SW 테스팅 방법
소프트웨어 테스트 자동화 도구 기능 및 역할
| 테스트 | 도구 | 자동화 도구 주요 기능 및 역할 |
| 테스트 관리 | 테스트 관리 도구 | 테스트 관리 협업 환경 지원 |
| 인시던트 관리 도구 | 인시던트 (결함) 할당 및 모니터링 지원 | |
| 요구사항 관리 도구 | 요구사항 작성 및 추적성 모니터링 지원 | |
| 형상 관리 도구 | 각종 소프트웨어 버전 관리 | |
| 테스트 설계 | 테스트 설계 도구 | 테스트 케이스 설계 지원 |
| 테스트 케이스 생성 | 자료 흐름도 : 테스트 경로 관리 | |
| 입력 도메인 분석 : 테스트 데이터 산출 | ||
| 랜덤 테스트 : 무작위 입력 값, 신뢰성 검사 | ||
| 정적 테스팅 | 코드 분석 도구 | 룰 메트릭 제공 |
| 원시 코드 문법적 정합성, 위반 사례 검출 | ||
| 구조 검사 도구 | 논리 그래프, 결함 체크 | |
| 데이터 분석 | 데이터 선언, 컴포넌트 인터페이스 | |
| 정의 / 링크 충돌 발견 | ||
| 순서 검사 도구 | 이벤트 순서, 오류 순서 지적 | |
| 동적 테스팅 | 단위 테스트 도구 | 단위 함수 기능 검증 |
| 테스트 실행 도구 | 반복 테스트 자동 수행, 캡쳐 및 리플레이 기능 | |
| 성능 테스팅 도구 | 가상 부하 (load) 발생 통한 성능 / 부하 / 스트레스 테스트 실행 | |
| 커버리지 측정 도구 | 코드 레벨 커버리지 측정 지원 | |
| 동적 분석 도구 | 테스트 수행 시 런타임 결함 검출 | |
| 모니터링 도구 | 시스템 특정 항목 (메모리 사용량, 수행 경로, 동시 접속자 등) 모니터링 지원 |
소프트웨어 테스트 관리 지원 도구
- 실행된 테스트와 테스트 활동 관리 지원
- 테스트 실행 도구나 결함 추적 도구, 요구사항 관리 도구와의 인터페이스 역할
- 결함 발견, 분배, 수정, 확인, 종료되는 결함의 수명주기 (Defect life Cycle) 관리
- 테스트 진행 상황에 대한 리포트 생성, 발견된 결함의 정량적 분석 지원
| 구분 | 역할 | 종류 |
| 오픈 소스 | 결함 관리 도구 | Mantis(GPL), Bugzilla |
| 테스트 케이스 관리 도구 | Testlink | |
| 형상 (버전) 관리 도구 | CVS, SVN, Git, Bazaar | |
| 커뮤니케이션 도구 | MediaWiki, Dokuwiki | |
| 통합 프로젝트 지원 도구 | Trac, nForge, Gforge | |
| 상용 소스 | 버그 추적 | JIRA (Atlassian), TPMS (STA), Test Director (HP), Clear Quest (IBM) |
| 형상 관리 | Visual Sourcesafe, IBM Rational Clear Case | |
| 커뮤니케이션 | Confluence |
소프트웨어 정적 분석 지원 도구
- 리뷰 프로세스에 관한 정보 저장, 리뷰 코멘트 저장
- 동적 테스트 하기 전 결함 발견할 수 있도록 지원
- 코딩 표준을 지킬 것을 강제하고 구조와 의존 관계 분석
- 소스 코드 복잡도 측정
| 구분 | 도구 설명 |
| 오픈 소스 | PMD, Valgrind, Find, Checkstyle, CPPCheck, Corbetura 등 |
| 상용 소스 | Coverity, IBM Rational Software, PloySpace 등 |
소프트웨어 테스트 실행 및 로깅 지원 도구
- 스크립트 언어 도움으로 저장된 입력 값과 예상 결과 이용하여 테스트 실행하고 실제 결과와 비교 (Capture and playback 도구)
- 테스트 대상이 실행되는 환경 시뮬레이션 함 (Test Harness 도구)
- 측정하고자 하는 특정 유형 코드 구조 (구문, 분기 등) 가 몇 퍼센트 수행되었는가 측정 (커버리지 측정 도구)
| 구분 | 역할 | 종류 |
| 오픈소스 | 테스트 프레임워크 | XUnit, TestNG, FIT/FitNess, Jmock, Easymock, Googlemock 등 |
| 지속적 통합 | CruiseControl, hudson, jenkinson | |
| 빌드 자동화 | Ant, Maven, Make | |
| 실행 자동화 | Selenium 등 | |
| 상용 소스 | HP의 WinRunner, Parasoft의 Jtest, 슈어소프트의 CodeScroll |
소프트웨어 성능 및 모니터링 도구
- 소프트웨어가 실행 도중에만 발생하는 시간 의존성과 메모리 누수 (Memory Leaks) 와 같은 결함 발견에 활용
- 소프트웨어 성능 / 부하 / 스트레스 테스트
- 특정 시스템 리소스 사용량을 지속적으로 분석 및 확인
| 구분 | 도구 설명 |
| 오픈 소스 | Jmeter, OpenSTA, allmon, Eclipse TPTP(Test & Performance Tools Platform) 등 |
| 상용 소스 | Oracle의 E-load, HP의 LoadRunner, radview의 Webload, IBM의 Robot |
애플리케이션 통합 테스트
개념
소프트웨어 각 모듈 간 인터페이스 관련 오류 및 결함 발견하기 위한 체계적 테스트 기법. 단위 테스트가 끝난 모듈 또는 컴포넌트 단위 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인
애플리케이션 통합 테스트 접근 전략
- 점증적인 방법 : 개발된 컴포넌트 중 일부를 테스트하고 점차적으로 컴포넌트를 늘려가면서 테스트하는 방식. 상향식 통합과 하향식 통합으로 나뉨
- 빅뱅 방식 : 모든 컴포넌트를 사전에 통합하여 한꺼번에 테스트하는 방식
하향식 통합 (Top Down)
- 메인 제어 컴포넌트부터 아래 방향으로 제어 경로를 따라 이동하면서 하향식으로 통합하며 테스트 진행
- 메인 제어 컴포넌트는 작성된 프로그램 사용하고, 아직 작성되지 않은 하위 제어 컴포넌트 및 모든 하위 컴포넌트 대신하여 더미 컴포넌트 스텁 (Stub) 개발
- 깊이-우선 방식 또는 너비-우선 방식에 따라 하위 컴포넌트 스텁이 한 번에 하나씩 실제 컴포넌트로 대체됨
※ 스텁 : 임시 제공되는 가짜 모듈
상향식 통합 (Bottom Up)
- 애플리케이션 구조에서 최하위 레벨 컴포넌트로부터 위쪽 방향으로 제어 경로 따라 이동하며 테스트 시작
- 최하위 레벨 컴포넌트들이 하위 컴포넌트 기능을 수행하는 클러스터로 결합됨
- 상위 컴포넌트 개발이 안됐을 경우 더미 컴포넌트인 드라이버 (Driver) 작성
- 각 통합된 클러스터 단위 테스트
- 테스트 완료되면 각 클러스터들은 프로그램의 위쪽으로 결합되며, 드라이버는 실제 컴포넌트로 대체됨
※ 클러스터 : 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹
※ 드라이버 : 검사 자료 입출력 제어 프로그램
애플리케이션 통합 테스트 유형
| 유형 | 설명 |
| 회귀 테스트 (Regression Test) |
이미 통합 테스트 완료한 컴포넌트가 어떠한 변화로 인해 의도하지 않은 오류가 생기지 않았음을 보증하기 위해 반복 테스트 하는 것 |
| 테스트 시 변경 영향도 분석하여 영향 받는 컴포넌트 중심으로 재 테스트 수행 | |
| 사용 기반 테스트 (Use Based Test) |
사용자 중심 시나리오 기반 테스트 |
| 스레드 기반 테스트 (Thread Base Test) |
주요 기능 모듈부터 점차 범위를 넓혀 나가는 통합 테스트 기법 |
| 빅뱅 테스트 (Bigbang Test) |
모든 모듈을 한꺼번에 테스트하는 기법 |
| 점증적 테스트 (Incremental Test) |
주요 기능을 먼저 테스트 후 점차 범위 넓혀나가는 테스트 |
애플리케이션 회귀 테스트 케이스 선정 기준
- 실제 수정이 발생한 컴포넌트와 관련된 테스트 케이스 도출. 이를 위해 변경 관리 도구 사용하여 애플리케이션 변경 영향도 분석
- 변경 영향도가 가장 높은 컴포넌트 기능에 집중한 회귀 테스트 케이스 도출
애플리케이션 통합 테스트 수행 절차
① 통합 테스트 케이스 설계
- 단위 테스트 케이스를 비즈니스 시나리오에 따라 여러 개를 묶고 이어서 통합 테스트 케이스 생성
- 통합 테스트 케이스는 사용자 요구사항을 기준으로 작성
② 통합 테스트 데이터 준비
- 통합 테스트 데이터는 운영 데이터베이스에서 일부 추출하여 테스트 데이터 생성
- ex. 운영 데이터베이스에서 1개월 전 까지의 데이터 추출하여 테스트 데이터베이스에 전달
- 보안 위해 테스트 데이터에서 개인 정보는 스크램블링 (Scrambling) 함.
③ 통합 테스트 수행 및 결과 확인
- 테스트 수행 시 1개월 전부터 현재까지의 데이터를 애플리케이션에 그대로 입력하여 레거시와 비교 검사 (재연 테스트)
- 테스트 케이스에 따라 데이터 입력하고 예상 결과와 비교
④ 결함 관리
- 테스트 결과가 예상 결과와 다를 경우 결함 화면 캡쳐하여 붙인 후 결함 등록
- 조치된 결함을 재 테스트 프로세스 수행
⑤ 테스트 결과 보고 및 종료
- 모든 통합 테스트 수행 완료되면 결과 집계하여 보고 및 종료
애플리케이션 통합 테스트 시작 및 종료 기준
통합 테스트 시작 기준
| 점검 포인트 | Pass 기준 | 점검 방법 |
| 통합 테스트 계획서 작성 | 승인 | 작성된 통합 테스트 계획서에 대해 승인 |
| 통합 테스트 케이스 작성 | 100% 완료 | 통합 테스트 대상 범위에 대해 모두 작성 |
| 통합 테스트 데이터 준비 | 100% 완료 | 테스트 수행자의 테스트 데이터 요구사항에 따른 데이터 생성 여부 |
| 통합 테스트 환경 셋업 | 100% 완료 | 스모크 테스트 통과 |
통합 테스트 종료 기준
| 점검 포인트 | Pass 기준 | 점검 방법 |
| 통합 테스트 수행률 | 100% 완료 | 테스트 관리 도구에서 통합 테스트 수행율 확인 |
| 테스트 합격률 | 95% 완료 | X = (A / B) * 100 - A : 테스트 시 Pass된 테스트 케이스 수 - B : 계획된 테스트 케이스 총 건수 |
| 결함 조치율 | 95% 완료 | X = (A / B) * 100 - A : 시정 조치가 완료된 건수 - B : 결함 기준 시정 조치 대상 총 건수 |
| 요구사항 추적률 | 97% | 요구사항 ID와 통합 테스트 케이스 목록 비교 |
320x100
'정보처리기사 > 필기' 카테고리의 다른 글
| [정보처리기사] Part02-04-03. 애플리케이션 성능 개선 (2) (5) | 2023.01.16 |
|---|---|
| [정보처리기사] Part02-04-03. 애플리케이션 성능 개선 (1) (5) | 2023.01.16 |
| [정보처리기사] Part02-04-01. 애플리케이션 테스트케이스 설계 (33) | 2023.01.11 |
| [정보처리기사] Part02-03. 데이터조작 프로시저 최적화 (34) | 2023.01.08 |
| [정보처리기사] Part02-02. 데이터조작 프로시저 작성 (7) | 2023.01.08 |
댓글