[정보처리기사 실기] 10장 애플리케이션 테스트 관리 - 애플리케이션 통합 테스트

애플리케이션 통합 테스트

단위 테스트

(1) 개념 : 개별적인 모듈을 테스트, 구현 단계에서 각 모듈을 구현한 후 수행, 컴포넌트 테스트 수행하려면 모듈을 단독으로 실행 할 수 있는 테스트 베드라는 환경이 필요

 

(2) Mock 객체 생성 프레임워크

- 객체 지향에서는 단위 테스트 수행 시 테스트 되는 메소드는 다른 클래스의 객체에 의존, 이런 경우 고립화하여 테스트하는 것이 불가능하므로 독립적인 테스트를 위해 스텁의 객체 지향 버전인 목 객체 필요

- 목 객체는 수작업으로 만들거나 목 객체 생성 프레임워크를 활용하여 생성 가능

 

유형

• 더미 객체 : 객체 기능까지 필요하지 않은 경우에 사용, 메소드가 호출되면 정상 동작은 수행하지 않고 예외 수행
• 테스트 스텁 : 타 모듈의 기능을 단순히 수행하는 도구로 더미 객체에의 단순 기능에 특정 상태를 가정해서 특정한 값을 리턴하거나 특정 메시지 출력
• 테스트 드라이버 : 하위 모듈 호출하고, 파라미터 전달하고, 모듈 테스트 수행 후의 결과 도출
• 테스트 스파이 : 테스트 대상 클래스와 협력하는 클래스로 가는 출력을 검증하는데 사용
• 가짜 객체 : 협력 클래스의 기능을 대체해야 할 경우 사용, 일부를 훨씬 단순하게 구현

(3) 원칙 : 단위 테스트는 빠르게 수행, 컴포넌트에 의존하지 않도록 한다, 몇 번 실행해도 동일한 결과가 나와야 하고, 개입 없이 통과되는지 알 수 있도록 작성

 

통합 테스트 

(1) 개념 : 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법, 끝난 모듈 또는 컴포넌트 단위의 프로그램이 제시한 앱과 동일한 구조와 기능으로 구현된 것인지 확인

 

(2) 수행 방법의 분류 : 점증적인 방법과 비점증적인 방법, 비점증적인 빅뱅 방식을 컴포넌트를 사전에 통합하여 전체 프로그램을 한꺼번에 테스트 하는 것을 말한다, 점증적인 방법은 상향과 하향으로 나눔

 

(3) 하향식 통합

• 개념 : 아래 방향으로 제어의 경로 따라 이동해 통합, 메인 제어 모듈에 통합되는 하위 모듈과 최하위 모듈은 깊이-우선 또는 너비-우선 방식으로 통합
• 수행 단계 : 메인은 작성된 프로그램을 사용하고, 아직 작성되지 않은 하위 모듈을 제어 -> 위에서 아래로 검사 초기에 시스템 구조 파악 -> 모듈 및 모든 하위 컴포넌트 대신해 더미 모듈인 스텁 개발 -> 깊이-우선 방식 또는 너비-우선 방식에 따라, 하위 모듈인 스텁이 한 번에 하나씩 실제 모듈로 대체 -> 각 모듈 또는 컴포넌트 통합하면서 테스트 수행 -> 테스트 완료시 스텁이 실제 모듈 또는 컴포넌트로 작성

(4) 상향식 통합

• 개념 : 최하위 레벨의 모듈 또는 컴포넌트로부터 위쪽 방향으로 제어의 경로 따라 이동하면서 구축과 테스트
• 수행 단계 : 클러스터로 결합 -> 입출력 위한 더미 드라이버 작성 -> 통합된 클러스터 단위 테스트 -> 완료시 프로그램의 위쪽으로 결합되며, 드라이버는 실제 모듈 또는 컴포넌트로 대체

(5) 샌드위치 통합

• 상향식과 하향식 결합, 하위 프로젝트가 있는 큰 규모의 통합 테스트에서 사용, 병렬 테스트가 가능하고 시간 절약이 가능, 스텁과 드라이버의 필요성이 매우 높은 방식이고, 비용이 많이 소요

테스트 자동화 도구

(1) 개념 : 반복적인 테스트 작업을 스크립트 형태로 구현, 시간과 입력 감소, 효율적인 테스트 수행

 

(2) 자동화 도구 장단점

• 장점 : 데이터 재입력 작업의 자동화, 사용자 기능 일관성 검증에 유리, 객관적인 평가 기준 제공, 결과의 통계 작업과 그래프 다양한 표시 형태 제공, UI가 없는 서비스 경우 정밀한 테스트 가능
• 단점 : 도구 도입 후 사용법에 대한 교육 및 학습 필요, 프로세스 단계별로 적용하기 위한 시간 비용 노력 필요, 상용 도구의 경우 고가 유지 관리 비용이 높아 추가 투자가 필요

(3) 자동화 도구 유형

• 정적 분석 도구 : 애플리케이션 실행하지 않고 분석하는 도구, 코딩 표준 스타일 복잡도 및 남은 결함을 발견, 이해를 바탕으로 도구 이용해 분석
• 테스트 실행 도구 : 스크립트 실행하고, 각 스크립트마다 특정 데이터와 수행 방법 포함, 데이터 주도 접근 방식과 키워드 주도 접근 방식 존재
  • 데이터 주도 접근 방식 : 테스트 데이터를 스프레드시트에 저장, 테스트 케이스 반복해, 실행, 스ㅡ립트 언어에 익숙지 않은 테스터도 쉽게 테스트 수행
  • 키워드 주도 접근 방식 : 테스트 수행할 동작을 나타내는 키워드와 테스트 데이터를 스프레드시트에 저장, 수행 동작을 정의할 수 있으며 특서에 맞춰 키워드에 대해 테일러링 수행
• 성능 테스트 도구 : 처리량, 응답 시간, 경과 시간, 자원 사용률에 대래 가상의 사용자 생성 테스트 수행 성능 목표를 달성 확인
• 테스트 통제 도구 : 테스트 계획 관리 위한 도구, 수행에 필요한 데이터와 도구 관리하는 형상 관리 도구

(4) 테스트 하네스

• 개념 : 테스트 환경의 일부분, 테스트 지원하기 위한 코드와 데이터를 칭함, 단위 또는 모듈 테스트에 사용하기 위해 코드 개발자가 작성한다
• 구성요소
  • 테스트 드라이버 : 하위 모듈 호출, 파라미터 전달, 모듈 테스트 수행 후의 결과를 도출 상향식에 필요
  • 테스트 스텁 : 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구 하향식에 필요
  • 테스트 슈트 : 대상 컨포넌트나 모듈 시스템에 사용되는 테스트 케이스 집합
  • 테스트 케이스 : 입력값, 실행 조건, 기대 결과 등의 집합
  • 테스트 시나리오 : 하나 또는 여러 개의 테스트 케이스들을 포함 가능
  • 테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세
  • 목 오브젝트 : 행위를 조건부로 사전에 입력해 두면, 그 상황에 예정된 행위 수행

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

테스트 결과 분석

(1) 소프트웨어 결함 : 개발자 오류로 인해 만든 문서나 코딩상의 결점으로 설계한 것과 다르게 동작하거나 결과 발생

• 오류 : 결함의 원인이 되는 것, 일반적 실수
• 결점 : 고장을 일으키게 하는 오류 있는 경우 
• 버그 : 예상치 못한 결과
• 고장 / 문제 : 제품에 포함된 결함이 실행될 때 발생

(2) 완료 조건 : 각 단계별 테스트를 언제 어떤 상황에서 종료할지 결정 기준, 일정 비용 조직 등에 제약이 있으므로, 최적의 완료 조건 계획

 

(3) 테스트 리포팅 : 결과 정리, 요약 문서, 품질 상태, 결과서, 절차 및 평가 포함

결함 관리

(1) 개념 : 테스트 후 발생한 결함의 재발 방지와 유사 결함 발견 시 처리 시간 단축을 위해 결함을 추적하고 관리

 

(2) 프로세스 : 결함 관리 계획, 결함 기록, 결함 검토, 결함 수정, 결함 재확인, 결함 상태 추적 및 모니터링 활동, 최종 결함 분석 및 보고서 작성

 

(3) 결함 분석

• 개념 : 발견된 결함 분석해 보고서 작성, 구체적으로 명확히 정의 효율적으로 수정 가능
• 분석 방법 
  • 구체화 : 결함을 발생 시킨 입력값, 테스트 절차, 테스트 환경을 명확히 파악
  • 고립화 : 입력값, 테스트 절차, 테스트 환경 중 어떤 요소가 결함 발생에 영향 미치는지 분석
  • 일반화 : 영향 주는 요소를 최대한 일반화 시키는 법

(4) 결함 생명 주기

• 결함 등록  open : 분 석 후 구체화, 고립화, 일반화한 결함으로 보고된 상태, 기록되어 결함 추적의 대상이 된 상태
• 결함 검토 reviewed : 오픈 된 결함의 처리 방안을 검토, 위험성을 바탕으로 수정되거나 다음 릴리스에 수정되거나 무시될 수 있음
• 결함 할당 assigned : 수정할 개발자가 결정되고, 결함 해결이 요구된 상태
• 결함 수정 resolved : 할당된 수정 사항에 대한 해결을 처리한 상태
• 결함 확인 verified : 처리가 합당한지, 정확한지 검증이 완료된 상태
• 결함 종료 closed : 정확한 수정이 이뤄졌다고 판단되어 종료 상태
• 결함 재등록  reopend : 정확하게 수정되지 않아서 다시 수정을 요구
• 결함 조치 보류 deferred : 오픈된 결함을 곧바로 수정하지 않고 다음 릴리스에 해결로 연기, 디펄드 된 결함은 적절한 시점에 리오픈 되 결함 처리가 시작 될 수 있음
• 결함 처리 유형
  • Fixed : 수정완료 처리한 경우
  • Duplicated : 결함과 중독 되는 경우
  • Won't fix : 수정이 필요할 정도로 중요하거나 긴급한 것이 아니므로 수정 안함
  • invalid : 케이스에 문제가 있는 경우

결함 추이 분석

(1) 개념 : 결함 관리 측정 지표의 속성값들을 분석하고, 향후 앱의 어떤 모듈 또는 컴포넌트에서 결함이 발생할지 추정

 

(2 추이 분석 유형

• 결함 분포 분석 : 특정 속성에 해당하는 결함의 수를 측정항 결함의 분포 분석
• 결함 추세 분석 : 진행 시간의 흐름에 따른 결함의 수를 측정해 결함 추세 분석
• 결함 에이징 분석 : 결함 상태의 지속시간 측정해 분석

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

테스트 커버리지 

(1) 개념 : 주어진 케이스에 의해 수행되는 소프트웨어 테스트 범위를 측정하는 테스트 품질 측정 기준, 정확성과 신뢰성 향상

 

(2) 유형

• 기능 기반 커버리지 : 대상 앱의 전체 기능 모수로 설정, 실제 수행된 기능의 수를 측정, 100퍼 달성을 목표, 일반적으로 UI 많은 시스템의 경우 화면 수 모수로 사용
• 라인 커버리지 : 전체 소스 코드의 라인 수를 모수로 측정, 단위 테스트에서는 라인 커버리지 척도로 삼음
• 코드 커버리지 : 충분석 지표 중 하나, 구문 조건 결정 등 구조 코드 자체가 얼마나 테스트 되었나 측정, 테스트 커버리지하면 코드 커버리지 일 컫음
  • 대표적으로 구문, 결정, 조건, 조건/결정, 변결 조건/결정, 다중 조건 커버리지가 존재

결함의 식별 및 관리

(1) 심각도별 분류 : 얼마나 치명적인지 나타내는 척도

• 치명적 결함 : 완전히 방해하거나 못하게 하는 결함
• 주요 결함 : 기대와 다르거나 그 기능이 해야하는 것을 못하는 결함
• 보통 결함 : 특정 기준 충족 못하거나 전체에 영향 주지 않는 일부 기능이 부자연스러운 결함
• 경미한 결함 : 불편함 유발
• 단순 결함 : 사소한 버그, 기능 영향 없지만 수정해야 함

(2) 결함 우선 순위 : 발생한 결함이 얼마나 빠르게 처리되나 결정 척도, 결함 심각도가 높아도 우선순위가 반드시 높은 것은 아니며, 앱의 특성에 따라 우선순위 결정

• 결정적 : 24시간안에 수정
• 높음 : 우선순위의 결함은 종료 기준, 수정되어야 하는 다음 후보, 다른 기능 사용할 수 없을 때 우선순위로 분류
• 보통 : 올바른 에러 메시지가 출력되지 않는 것과 같은 에러가 이 우선순위로 분류
• 낮음 : 경험 향상 시키기 위한 작은 기능 구현에 대한 요청이 우선 순위로 분류

(3) 결함 관리 항목 : 수행 후 발견된 결함은 결함 관리 시스템에 등록해 관리, 아래 필수 등록

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