Ⅶ. 애플리케이션 테스트 관리 - 애플리케이션 통합테스트.

1. 애플리케이션 통합 테스트 수행

1.1 통합테스트란?

• 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법.
• 설계단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지 확인하는 테스트.
  
  

1.2. 통합 테스트 수행 방법의 분류

• 비점증적 방법 : 빅뱅방식 - 모든 컴포넌트를 사전에 통합하여 전체 프로그램을 한번에 테스트하는 방식.
• 점증적 방식 : 상향식 통합 방식 & 하향식 통합 방식

1.3. 하향식 통합

• 메인 제어 모듈로부터 아래 방향으로 제어 경로를 따라 이동하면서 하향식으로 통합하며 테스트 진행
• 방식 : ‘깊이-우선’ 또는 ‘너비-우선’
• 수행단계
  1. 1단계 : 메인 제어 모듈은 작성된 프로그램을 사용하고, 아직 작성되지 않은 하위 모듈을 제어함
  2. 2단계 : 위에서 아래로 내려오기 때문에 검사 초기에 시스템의 구조가 파악 되어야 함
  3. 3단계 : 모듈 및 모든 하위 컴포넌트를 대신하여 더미 모듈인 스텁 개발
  4. 4단계 : 깊이-우선 또는 너비-우선 방식에 따라 하위모듈인 스텁이 한꺼번에 하나씩 실제 모듈로 대체
  5. 5단계 : 각 모듈 또는 컴포넌트를 통합하며 테스트 수행
  6. 6단계 : 테스트가 완료되면 스텁이 실제 모듈 또는 컴포넌트로 작성

✱ 스텁(stub) : 모듈 및 모든 하위 컴포넌트를 대신하는 더미 모듈 / 스텁은 하위 모듈의 반환 값만 전달하면 됨.

1.4. 상향식 통합

• 최하위 레벨의 모듈 또는 컴포넌트부터 위쪽 방향으로 제어의 경로를 따라 이동하면서 구축과 테스트 수행
• 수행단계
  1. 1단계 : 하위레벨의 모듈 또는 컴포넌트들이 하위 모듈의 기능을 수행하는 클러스터로 결합
  2. 2단계 : 상위 모듈에서 데이터의 입력과 출력을 확인하기 위한 더미 모듈인 드라이버 작성
  3. 3단계 : 각 통합된 클러스터 단위 테스트
  4. 4단계 : 테스트 완료되면 각 클러스터들은 프로그램 위쪽에 결합되며, 드라이버는 실제 모듈 또는 컴포넌트로 대체

✱ 드라이버(Driver) : 상위모듈에서 데이터의 입력과 출력을 확인하기 위한 더미 모듈 / 드라이버는 상위 모듈 흐름을 작성해야 해서 스텁이 개발 쉬움.

▷ 상향식 및 하향식 통합 수행 방식 ( Tip. 하스 상드 ) 하향식 스텁
상향식 드라이버

1.5. 통합 테스트 수행 방법간 비교

빅뱅테스트

테스트 수행방법 : 모든 모듈을 동시에 통합 후 테스트 수행
드라이버/스텁 : 드라이버/스텁 없이 실제 모듈로 테스트
장점 : 단시간 테스트 가능, 작은 시스템에 유리
단점 : 장애 위치 파악이 어려움, 모든 모듈이 개발되어야 가능

상향식테스트

테스트 수행방법 : 최하위 모듈부터 점진적으로 상위 모듈과 함께 테스트
드라이버/스텁 : 테스트 드라이버 필요
장점 : 장애위치 파악 쉬움, 모든 모듈 개발시간 낭비 필요 없음
단점 : 중요 모듈들이 마지막 테스트 가능성 높음, 이른 프로토타입 어려움

하향식테스트

테스트 수행방법 : 최상위 모듈부터 하위 모듈들을 통합하면서 테스트
드라이버/스텁 : 테스트 스텁 필요
장점 : 장애 위치 파악 쉬움, 이른 프로토 타입 가능, 중요 모듈의 선 테스트 가능
단점 : 많은 스텁이 필요, 하위 모듈들의 불충분한 테스트 수행

2.1. 테스트 자동화 도구란?

• 반복적인 테스트 작업을 스크립트 형태로 구현함으로써 테스트시간 단축, 인력투입비용 최소화 가능하며 쉽고 효율적인 테스트 수행 가능한 방법.

2.2. 테스트 자동화 도구의 장단점

장점

• 반복되는 테스트 데이터 재입력 작업의 자동화
• 사용자 요구 기능의 일관성 검증에 유리
• 테스트 결과값에 대한 객관적인 평가 기준 제공
• 테스트 결과의 통계 작업과 그래프 등 다양한 표시 형태 제공
• UI가 없는 서비스의 경우에도 정밀한 테스트 가능

단점

• 도구 도입 후 도구 사용 방법에 대한 교육 및 학습 필요
• 도구를 프로세스 단계별로 적용하기 위한 시간, 비용, 노력 필요
• 상용 도구의 경우 고가, 유지 관리 비용이 높아 추가 투자 필요

2.3. 테스트 자동화 도구 유형 ( Tip. 정 실 성 통 )

• 정적 분석 도구
• 테스트 실행 도구
• 성능 테스트 도구
• 테스트 통제 도구

정적분석도구

만들어진 애플리케이션을 실행하지 않고 분석하는 도구
소스코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 결함 발견하기 위하여 사용

테스트 실행 도구

테스트를 위한 스크립트를 실행하고, 작성된 스크립트는 각 스크립트마다 특정 데이터와 테스트 수행 방법을 포함한다.

테스트 실행 도구 유형

• 데이터 주도 접근 방식
• 키워드 주도 접근 방식

성능 테스트 도구

애플리케이션의 처리량, 응답시간, 경과시간, 자원사용률에 대해 가상의 사용자를 생성하고 테스트를 수행함으로써 성능목표를 달성하였는지 확인하는 도구

테스트 통제 도구

테스트 관리도구, 형상관리도구, 결함 추적/관리 도구 등…

2.4 테스트 하네스

테스트 하네스(Test Harness) 란?

애플리케이션 컴포넌트 및 모듈을 테스트하는 환경의 일부분으로 테스트를 지원하기 위한 코드와 데이터
단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성

테스트 하네스 구성요소 ( Tip. 드 스슈케 스목 )

• 테스트 드라이버[Test Driver] : 상향식 테스트에 필요.
• 테스트 스텁[Test Stub] : 하향식 테스트에 필요.
• 테스트 슈트[Test Suites] : 테스트 케이스의 집합.
• 테스트 케이스[Test Case] : 입력값, 실행조건, 기대 결과 등의 집합.
• 테스트 스크립트[Test Script] : 자동화된 테스트 실행 절차에 대한 명세.
• 목 오브젝트[Mock Object] : 사용자의 행위를 조건부로 사전에 입력해두면 그 상황에 예정된 행위를 수행하는 객체.

2.5 테스트 단계별 테스트 자동화 도구

1. 테스트 계획 - 요구사항 관리 도구
2. 테스트 분석/설계 - 테스트 케이스 생성 도구
3. 테스트 수행 - 테스트 자동화 도구, 정적분석 도구, 동적분석 도구, 성능 테스트 도구, 모니터링 도구
4. 테스트 관리 - 커버리지 측정 도구, 형상관리 도구, 결함 추적/관리 도구

2. 애플리케이션 테스트 결과 분석

1.1. 소프트웨어 결함

• 에러(Error)/ 오류 : 에러는 결함(Defect)의 원인이 되는것으로, 일반적으로 사람에 의해 생성된 실수.
• 결함/결점/버그(Bug) : 에러 또는 오류가 원인이 되어 소프트웨어 제품에 포함되어 있는 결함 / 제품이 실패(Failure)하거나 문제(Problem)가 발생.
• 실패/문제 : 소프트웨어 제품에 포함된 결함이 실행될 때 발생되는 현상.

1.2. 테스트 완료 조건

단위테스트, 통합테스트, 시스템 테스트, 인수 테스트 등 각 단계별 테스트를 언제 어떤 상황에서 종료할 것인지 결정하는 기준.

1.3. 테스트 리포팅 ( Tip. 정요품 결실 )

• 테스트 결과 정리 : 테스트 계회가 / 케이스 설계 / 시나리오 / 결과까지 모두 포함된 문서.
• 테스트 요약문서 : 테스트 계획, 소요 비용, 테스트 결과로 소프트웨어의 품질상태를 포함한 문서.
• 품질 상태 : 테스트 성공률, 테스트 커버리지, 결함 수와 결함의 중요도 등 포함.
• 테스트 결과서 : 결함과 관련한 사항을 중점적으로 기록 / 결함의 재현 순서를 상세하게 기록.
• 테스트 실행 절차 및 평가
  
  

2.1. 결함관리란?

각 단계별 테스트 수행 후 발생한 결함의 재발 방지와 유사 결함 발견 시 처리 시간 단축을 위해 결함을 추적하고 관리하는 활동.

2.2. 결함관리 프로세스 ( Tip. 발등 분확할 조검 )

1. 에러 발견
2. 에러 등록
3. 에러 분석
4. 결함 확정
5. 결함 할당
6. 결함 조치
7. 결함 조치 검토 및 승인

3.1. 결함 추이 분석 이란?

테스트 완료 후 발견된 결함의 결함 관리 측정 지표의 속성값들을 분석하고, 향후 어떤 모듈 또는 컴포넌트에서 결함이 발생할지를 추정하는 작업.

3.2 결함 추이 분석 유형

• 결함 분포 분석 : 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함의 수를 측정하여 결함 분포 분석.
• 결함 추세 분석 : 테스트 진행시간의 흐름에 따른 결함수를 측정하여 결함 추세를 분석.
• 결함 에이징 분석 : 등록된 결함에 대해 특정한 결함 상태의 지속 시간을 측정하여 분석.

3. 애플리케이션 개선 조치사항 작성

1.1. 테스트 커버리지(Test Coverage)란?

소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준이며, 테스트의 정확성과 신뢰성을 향상시키는 역할을 함.

1.2. 테스트 커버리지 유형 ( Tip. 기라코 )

기능기반 커버리지

• 전체 기능을 모수로 설정하고 실제 테스트가 수행된 기능의 수를 측정하는 방법
• 100% 달성을 목표로 하며, 일반적으로 UI 가 많은 시스템의 경우 화면 수를 모수로 사용

라인 커버리지

• 전체 소스 코드의 라인 수를 모수로 테스트 시나리오가 수행한 소스 코드의 라인수를 측정하는 방법
• 단위테스트에서는 라인 커버리지를 척도로 삼음

코드 커버리지

• 소프트웨어 테스트 충분성 지표 중 하나
• 소스 코드의 구문, 조건, 결정 등의 구조 코드 자체가 얼마나 테스트 되었는지를 측정하는 방법
  
  

1.3. 코드커버리지 유형 ( Tip. 구결조 조결변다 )

• 구문 커버리지 : 프로그램내 모든 명령문을 적어도한번 수행하는 커버리지.
• 결정 커버리지 : 프로그램내 전체 결정문이 적어도 한번은 참과 거짓의 결과를 수행.
• 조건 커버리지 : 결정 명령문 내의 각 조건이 적어도 한번은 참과 거짓의 결과가 되도록 수행.
• 조건/결정 커버리지 : 전체 조건식뿐만 아니라 개별 조건식도 참한번, 거짓한번 결과가 되도록 수행하는 커버리지
• 변경 조건/결정 커버리지 : 조건/결정 커버리지를 향상시킨 커버리지 / 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않음.
• 다중 조건 커버리지 : 결정 조건 내 모든 개발 조건식의 모든 가능한 조합을 100% 보장하는 커버리지

2.1. 단계별 결함 유입의 종류

• 기획시 유입되는 결함
• 설계시 유입되는 결함
• 코딩시 유입되는 결함
• 테스트 부족으로 유입되는 결함
  

2.2 결함 심각도별 분류 ( Tip. 치주 보경단 )

• 치명적(Critical) 결함 : 테스트를 완전히 방해하거나 못하게 하는 결함.
• 주요(Major) 결함 : 기능이 기대와 다르게 동작 또는 기능이 해야할일을 못함.
• 보통(Normal) 결함 : 프로그램이 특정 기준을 충족 못하거나 전체에 영향을 주지 않는 일부 기능이 부자연 스러운 결함.
• 경미한(Minor) 결함 : 사용상의 불편함을 유발하는 결함.
• 단순(Simple) 결함 : 사소한 버그 / 기능에 영향없지만 수정되어야 하는 경함
  

2.3. 결함 우선순위

1. 결정적(Critical) : 24시간안에 즉시 수정 / 이슈 발생시 전체 기능 동작X, 테스트 진행 불가.
2. 높음(High) : 결함으로 인해 다른 기능을 사용 할 수 없을때.
3. 보통(Medium) : 실패 발생시 올바른 메시지 출력되지 않는것과 같은 에러..
4. 낮음(Low)
   

2.4. 결함 관리 항목

• 결함내용
• 결함ID
• 결함 유형
• 발견일
• 심각도
• 우선순위
• 시정 조치 예정일
• 수정 담당자
• 재 테스트 결과
• 종료일

• 정보처리기사 필기 합격 후 실기대비 정리 및 책없이 간단히 보기위해 작성하였습니다.
• 2020년 수제비 정보처리기사 책 기반으로 정리 하였습니다.
• 저작권 관련 문제가 있다면 hojunbbaek@gmail.com 으로 메일 주시면 바로 삭제 조치 하도록 하겠습니다.