[자격증] 정보처리기사 실기 : 19강 애플리케이션 테스트 관리 (애플리케이션 통합 테스트하기)

 정보

• 업무명     : 정보처리기사 실기 : 19강 애플리케이션 테스트 관리 (애플리케이션 통합 테스트하기)

• 작성자     : 이상호

• 작성일     : 2020-05-11

• 설   명      :

• 수정이력 :

 

 

 내용

[애플리케이션 통합 테스트 수행]

[1] 통합 테스트 수행 방법

• 1. 개요

  • (1) 통합 테스트의 개념 

    • 애플리케이션 통합 테스트는 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함 을 찾아내기 위한 체계적인 테스트 기법이다. 

  • (2) 통합 테스트의 목적 

    • 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인하는 것이다. 

  • (3) 통합 테스트 수행 방법의 분류 

    • 일반적으로 점증적인 방법과 비 점증적인 방식으로 나눌 수 있다. 비 점증적인 빅뱅 방 식은 모든 컴포넌트를 사전에 통합하여 전체 프로그램을 한꺼번에 테스트하는 것을 말하며, 점증적인 방법은 다시 상향식 통합과 하향식 통합 방식으로 구분할 수 있다.

 

• 2. 하향식 통합(Top Down) 

  • (1) 방식 메인 제어 모듈(프로그램)로부터 아래 방향으로 제어의 경로를 따라 이동하면서 하향 식으로 통합하면서 테스트를 진행하며, 메인 제어 모듈에 통합되는 하위 모듈과 최하 위 모듈은 ‘깊이-우선’ 또는 ‘너비-우선’ 방식으로 통합된다.

  • (2) 수행 단계 

    • (가) 메인 제어 모듈은 작성된 프로그램을 사용하고, 아직 작성되지 않은 하위 제어 모듈 및 모든 하위 컴포넌트를 대신하여 더미 모듈인 스텁(Stub)을 개발한다.

    • (나) 깊이-우선 방식 또는 너비-우선 방식에 따라, 하위 모듈인 스텁이 한 번에 하나씩 실제 모듈로 대체된다. 

    • (다) 각 모듈 또는 컴포넌트를 통합하면서 테스트가 수행된다. 

    • (라) 테스트가 완료되면 스텁이 실제 모듈 또는 컴포넌트로 작성된다.

• 3. 상향식 통합(Bottom Up) 

  • (1) 방식 애플리케이션 구조에서 최하위 레벨의 모듈 또는 컴포넌트로부터 위쪽 방향으로 제어 의 경로를 따라 이동하면서 구축과 테스트를 시작한다. 

  • (2) 수행 단계 

    • (가) 최하위 레벨의 모듈 또는 컴포넌트들이 하위 모듈의 기능을 수행하는 클러스터 (Cluster)로 결합된다.

    • (나) 상위의 모듈에서 데이터의 입력과 출력을 확인하기 위한 더미 모듈인 드라이버 (Driver)를 작성한다. 

    • (다) 각 통합된 클러스터 단위를 테스트한다. 

    • (라) 테스트가 완료되면 각 클러스터들은 프로그램의 위쪽으로 결합되며, 드라이버 는 실제 모듈 또는 컴포넌트로 대체된다.

• 4. 회귀 테스팅(Regression Testing) 

  • 통합 테스트가 완료된 후에 변경된 모듈이나 컴포넌트가 있다면 새로운 오류 여부를 확인 하기 위해 회귀 테스트를 수행할 수 있다. 

  • (1) 정의

    • (가) 통합 테스트 과정에서 오류를 제거하거나 수정한 프로그램이 새로운 형태의 오 동작이나 오류를 일으킬 수 있다. 

    • (나) 회귀 테스트는 모듈이나 컴포넌트의 변화로 인해 의도하지 않은 오류가 생기지 않았음을 보증하기 위해 반복 테스트하는 것을 말한다. 

  • (2) 회귀 테스트 케이스 선정 방법 

    • (가) 모든 애플리케이션의 기능을 수행할 테스트 케이스의 대표적인 샘플을 도출한다. 

    • (나) 변경에 의한 영향도가 가장 높은 애플리케이션 기능에 집중한 추가적인 테스트 케이스를 도출한다. 

    • (다) 실제 수정이 발생한 모듈 또는 컴포넌트에서부터 시행하는 테스트 케이스를 도출한다.

 

[2] 테스트 자동화 도구

• 1. 테스트 자동화 

  • (1) 테스트 자동화의 개념

    • 테스트 자동화란 테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현함으로써, 테스트 시간 단축과 인력 투입 비용을 최소화하는 한편, 쉽고 효율적인 테스트를 수행할 수 있는 방법이다. 

  • (2) 테스트 도구의 장점

    • (가) 반복되는 테스트 데이터 재입력 작업의 자동화 

    • (나) 사용자 요구 기능의 일관성 검증에 유리

    • (다) 테스트 결과 값에 대한 객관적인 평가 기준 제공

    • (라) 테스트 결과의 통계 작업과 그래프 등 다양한 표시 형태 제공

    • (마) UI가 없는 서비스의 경우에도 정밀한 테스트 가능 

  • (3) 테스트 도구의 단점 

    • (가) 도구 도입 후 도구 사용 방법에 대한 교육 및 학습이 필요

    • (나) 도구를 프로세스 단계별로 적용하기 위한 시간, 비용, 노력이 필요

    • (다) 상용 도구의 경우 고가, 유지 관리 비용이 높아 추가 투자가 필요

 

• 2. 테스트 자동화 도구 유형 

  • (1) 정적 분석 도구(Static Analysis Tools) 

    • (가) 정적 분석 도구는 만들어진 애플리케이션을 실행하지 않고 분석하는 방법이다. 

    • (나) 대부분의 경우 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함을 발견하기 위하여 사용한다. 

    • (다) 테스트를 수행하는 사람이 작성된 소스 코드에 대한 이해를 바탕으로 도구를 이용해서 분석하는 것을 말한다.

  • (2) 테스트 실행 도구(Test Execution Tools) 이 도구는 테스트를 위해 작성된 스크립트를 실행한다. 작성된 스크립트는 각 스크립 트마다 특정 데이터와 테스트 수행 방법을 포함하고 있으며, 데이터 주도 접근 방식과 키워드 주도 접근 방식으로 나눌 수 있다. 

    • (가) 데이터 주도 접근 방식 테스트 데이터를 스프레드시트에 저장하고, 이 데이터를 읽고 실행할 수 있도록 한 다. 다양한 테스트 데이터를 이용하여 동일한 테스트 케이스를 반복해서 실행할 수 있으며, 스크립트 언어에 익숙지 않은 테스터도 미리 작성된 스크립트에 테스트 데이터만 추가하여 쉽게 테스트를 수행할 수 있게 된다. 

    • (나) 키워드 주도 접근 방식 일반적으로 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 스프레드 시트에 저장한다. 이 방식에서는 키워드를 이용하여 테스트 수행 동작을 정의할 수 있으며, 테스트 대상 애플리케이션의 특성에 맞추어 키워드에 대해 테일러링 (Tailoring)을 수행할 수 있다.

  • (3) 성능 테스트 도구(Performance Test Tools) 성능 테스트 도구는 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트를 수행함으로써 성능 목표를 달성하였는지를 확인하 는 도구이다. 일반적으로 시스템 테스트 단계에 성능 테스트 계획을 설계하고 실행하고 있으며, 테스트 결과를 해석할 수 있는 성능 전문가의 도움이 필요한 경우도 있다. 

  • (4) 테스트 통제 도구(Test Control Tools) 테스트 통제 도구에는 테스트 계획 및 관리를 위한 테스트 관리 도구, 테스트 수행에 필요한 데이터와 도구를 관리하는 형상 관리 도구, 테스트에서 발생한 결함에 대해 관 리하거나 협업을 지원하기 위한 결함 추적/관리 도구 등이 있다. 또한 조직의 요구사 항에 최적화된 형태의 정보를 생성, 관리하기 위하여 스프레드시트 등 다른 도구들과 연계하여 사용할 수도 있다. 

  • (5) 테스트 장치(Test Harness) 

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

    • (나) 구성요소 

      • 1) 테스트 드라이버(Test Driver) 

        • 테스트 대상 하위 모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후 의 결과를 도출하는 등 상향식 테스트에 필요하다. 

      • 2) 테스트 스텁(Test Stub) 

        • 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로 하향식 테스 트에 필요하다. 

      • 3) 테스트 슈트(Test Suites) 

        • 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합을 말한다. 

      • 4) 테스트 케이스(Test Case) 

        • 입력 값, 실행 조건, 기대 결과 등의 집합을 말한다. 

      • 5) 테스트 스크립트(Test Script) 

        • 자동화된 테스트 실행 절차에 대한 명세를 말한다. 

      • 6) 목 오브젝트(Mock Object) 

        • 사용자의 행위를 조건부로 사전에 입력해 두면, 그 상황에 예정된 행위를 수행 하는 객체를 말한다. 

  • (6) 테스트 자동화 도구 

    • 테스트 자동화 도구는 휴먼 에러(Human Error)를 줄이고, 테스트에 소요되는 비용과 시간을 절감하며, 테스트 품질을 향상할 수 있는 도구이다. 테스트 계획, 테스트 분석/설계, 테스트 수행, 테스트 통제 등의 테스트 활동에 따라 각각 요구사항 관리, 테스트 케이스 생성, 커버리지 분석, 정적/동적 테스트 수행, 성능 테스트, 모니터링, 형상 관리, 테스트 관리, 결함 추적/관리 등을 지원하는 테스트 도구가 있다.  

 

[수행-애플리케이션 통합 테스트 수행하기]

[1] 통합 테스트 계획서를 검토

• 통합 테스트에 투입될 인력 및 테스트 일정, 테스트 수행 방안, 테스트 절차, 테스트 환경, 테스트 판정 기준, 테스트 완료 조건에 대해 검토한 후, 실제 테스트를 수행할 인력, 일정, 테스트 방법에 대해 결정한다. 

• 1. 통합 테스트에 투입될 일정 및 인력을 확정한다. 수행 중인 프로젝트 일정 및 통합 테스트 계획에 따라 테스트 인력을 확정한다. 

  • (1) 통합 테스트 수행 일정을 확정한다. 프로그램 배포 또는 진행 중인 프로젝트의 일정 계획에 따라 테스트 수행 기간 및 테 스트 회차 등 통합 테스트 전체 일정을 확정한다. 

  • (2) 테스트 수행 조직을 구성하고 담당자별 업무 분장을 확정한다. 담당자별 통합 테스트에서 수행할 역할과 책임에 대해 결정한다.

• 2. 통합 테스트 수행 방안에 대해 검토 후 테스트 방법을 결정한다. 

  • (1) 통합 테스트 수행 방안에 대해 검토한다. 프로젝트 특성에 맞게 각 테스트 방식(상향식, 하향식, 빅뱅 방식)에 대한 장점과 단점 을 비교하여 적절한 방법을 결정한다. 

    • (가) 상향식 테스트 방안의 장점과 단점에 대해 정리한다. 

    • (나) 하향식 테스트 방안의 장점과 단점에 대해 정리한다. 

    • (다) 빅뱅 테스트 방안의 장점과 단점에 대해 정리한다. 

  • (2) 프로젝트의 특성에 맞는 테스트 수행 방법을 결정한다. 각 단위 기능의 연계 동작이 적정한지를 검토할 테스트 방법을 결정한다.

 

 

[2] 통합 테스트를 수행할 테스트 환경을 준비

• 운영 환경과 동일한 환경에서 테스트를 수행하는 것이 가장 바람직하지만 비용, 일정 등 다양한 프로젝트 진행 상황에 따라 개발 환경에서 진행할 수도 있다. 

• 1. 테스트 서버를 설치한다. 테스트를 진행하는 서버는 별도의 테스트 서버를 설치하여 진행하거나 프로젝트 진행중 인 개발 서버를 대상으로 구축할 수도 있다. 

  • (1) 운영 체제 서버(OS Server)를 설치한다. Windows 서버 또는 Linux 서버 또는 기타 운영 체제를 설치한다. 

  • (2) 웹 서버(Web Server)를 설치한다. IIS(Internet Information Server), Apache, Webtobe 등 운영 환경과 동일한 서버를 설치 한다. 

  • (3) 웹 애플리케이션 서버(WAS : Web Application Server)를 설치한다. Tomcat, Jeus, Web Logic, Web Spere 등 운영 환경과 동일한 서버를 설치한다. 

  • (4) DBMS(DataBase Management System)를 설치한다. Oracle, MS-Sql, MySql, DB2, Informix, Sybase, Derby, SQLite 등 운영 환경과 동일하게 설치한다. 

• 2. 설치한 서버의 시스템 환경을 설정한다. 테스트를 진행할 서버의 시스템 정보, 데이터베이스 정보, 로그인 확인 방법, 테스트 계정 등의 환경을 설정한다.

  • (1) 시스템 정보를 설정한다. IP주소, 접속 방법, WAS 서버의 위치, 첨부파일의 위치, 테스트 URL 등의 정보를 정 한다.

  • (2) 데이터베이스 연결 정보를 설정한다. IP주소, port 번호, 데이터베이스 연결 계정 등 정보를 설정한다. 

  • (3) 각종 로그 확인 방법에 대해 설정한다. Application Log, Error Log, DataBase Sql Log의 확인 방법을 설정한다. 

  • (4) 테스트 담당자가 사용할 계정을 설정한다. 일반 사용자 테스트용 계정과 관리자용 테스트 계정을 설정한다.

 

[3] 통합 테스트 케이스 및 시나리오 검토

• 1. 통합 테스트 케이스를 검토한다. 프로젝트에서 구현해야 하는 기능 요구사항에 대한 올바른 설계 여부를 통합 테스트를 통 해 확인 가능한지 검토한다. 

  • (1) 테스트 ID와 테스트 사양서, 테스트 명, 테스트 내용의 일관성을 검토한다. 테스트 ID별 통합 테스트 명세서 또는 테스트 사양서의 내용과 테스트할 내용이 해당 기능의 정상적인 동작 여부를 확인할 수 있도록 작성되어 있는지 검토한다. 

  • (2) 작성된 테스트 케이스에 대해 동료 검토를 통해 테스트 유효성, 효율성 등을 확인 한다. 

• 2. 통합 테스트 시나리오를 검토한다. 메뉴 기반이 통합 테스트의 경우, 수행할 통합 테스트의 메뉴 경로 및 주요 입력값 등 해당 테스트 시나리오의 유효성에 대해 확인한다. 

  • (1) 통합 테스트 수행을 위한 권한 정의가 적정한지 검토한다. 

  • (2) 테스트 수행을 위한 사이트 접속 정보 등이 적정한지 검토한다. 

  • (3) 작성된 테스트 시나리오에 대해 동료 검토를 통해 확인한다. 

 

[4] 통합 모듈 및 인터페이스가 요구사항을 충족하는지 테스트 수행

• 1. 통합 테스트 계획서에 명시된 일정에 따라 테스트를 수행한다. 검토 완료된 통합 테스트 케이스 및 테스트 시나리오에 따라 테스트를 수행한다. 

• 2. 메뉴 기반 테스트인 경우 메뉴의 정상 흐름 또는 비정상적인 흐름에 대해 테스트를 수 행한다. 테스트 시나리오를 기반으로 작성된 메뉴 흐름에 따라 정상적인 데이터 또는 비정상적인 데이터를 이용하여 테스트를 수행한다. 

• 3. 경험 기반 테스트인 경우 별도의 테스트 케이스 없이 테스트 담당자가 유사 프로젝트의 경험을 토대로 테스트를 수행한다. 경험 기반 테스트 중 탐색적 테스트인 경우, 아래의 구성요소에 대해 작성한다. 

  • (1) 테스트 차터를 작성한다. 

  • (2) 테스트 제한 시간을 결정한다. 

  • (3) 테스트 노트를 작성한다. 

  • (4) 테스트 요약 보고를 작성한다.

• 4. 테스트 자동화 도구를 사용하여 통합 테스트를 수행한다. 각 채널 간 인터페이스의 결합을 통해 기능을 검증하는 경우에는 인터페이스 테스트 자동 화 도구를 사용하여 통합 테스트를 수행한다. 

  • (1) 통합 테스트 환경(서버 내부 로컬 호출, 서버 리모트 호출, 서버 HTTP 호출에 대해 정의한다. 

  • (2) 테스트를 수행할 입력 정보 및 결과 정보를 이용하여 테스트 테이블을 작성한다. 

  • (3) 테스트 케이스를 작성하고, 테스트를 수행한다.

 

[5] 통합 테스트 결과를 기록

• 통합 테스트 수행 후 테스트 ID별로 수행한 통합 테스트 결과에 대해 작성한다. 

• 1. 테스트 결과서에 공통으로 들어갈 항목에 대해 작성한다. 

  • 테스트 ID, 테스트 명, 작성자, 수정자, 작성 일자, 수정 일자 등의 내용을 작성한다. 

• 2. 테스트 결과 판정을 위한 내용을 작성한다. 

  • 요구사항 ID, 테스트 내용, 전제 조건, 순번, 테스트 시나리오, 테스트 데이터, 개발자명, 시험자명, 시험 일자, 테스트 예상 결과, 적합 여부, 심각도, 결함 내용, 수정 예정일, 수정 완료일 등의 내용을 작성한다.

 

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

[1] 테스트 결과 분석

• 1. 소프트웨어 결함 

  • 소프트웨어의 결함을 말할 때 에러(Error), 결함(Defect), 결점(Fault), 버그(Bug), 실패 (Failure)와 같은 용어가 사용되며, 이런 용어들의 정의를 다음과 같이 정리할 수 있다. 

    • (1) 에러(Error)/오류 

      • 에러는 결함(Defect)의 원인이 되는 것으로, 일반적으로 사람(소프트웨어 개발자, 분석 가 등)에 의해 생성된 실수를 말한다. 

    • (2) 결함/결점/버그(Bug) 

      • 에러 또는 오류가 원인이 되어 소프트웨어 제품에 포함되어 있는 결함을 말하며, 이를 제 거하지 않으면 소프트웨어 제품이 실패(Failure)하거나 문제(Problem)가 발생할 수 있다. 

    • (3) 실패/문제 

      • 소프트웨어 제품에 포함된 결함이 실행될 때 발생되는 현상을 말한다. 

• 2. 테스트 완료 

  • 조건 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 등 각 단계별 테스트를 언제 어떤 상황에서 종료할 것인지를 결정하는 것이다. 이러한 완료 조건은 프로젝트 특성에 따라 일정, 비용, 조직 등에 제약이 있으므로, 최적의 완료 조건을 계획하여야 한다. 

• 3. 테스트 리포팅 

  • (1) 테스트 결과 정리

    • 모든 테스트가 완료되면, 테스트 계획과 테스트 케이스 설계부터 단계별 테스트 시나 리오, 테스트 결과까지 모두 포함된 문서를 작성한다. 

  • (2) 테스트 요약

    • 문서 테스트 계획, 소요 비용, 테스트 결과로 판단 가능한 대상 소프트웨어의 품질 상태를 포함한 문서를 작성한다

  • (3) 품질 상태 

    • 품질 상태는 정량화된 품질 지표인 테스트 성공률, 테스트 커버리지, 발생한 결함의 수와 결함의 중요도 등이 포함된다.

  • (4) 테스트 결과서

    • 테스트 결과서는 결함과 관련한 사항을 중점적으로 기록하며, 결함의 내용 및 자원 정보 (CPU, Memory, Network 사용률과 로그 정보 등), 결함의 재현 순서를 상세하게 기록 한다. 

  • (5) 테스트 실행 절차 및 평가 

    • 단계별 테스트 종료 시 테스트 실행 절차를 리뷰하고 결과에 대한 평가를 수행하고, 그 결과에 따라 실행 절차를 최적화하여 다음 테스트에 적용한다.  

 

[2] 결함 관리

• 1. 테스트 결함 관리

  • (1) 개요 

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

  • (2) 결함 추적 관리 활동

    • 단위 테스트, 통합 테스트, 시스템 테스트, 운영 테스트의 단계별 착수 기준과 입력물, 그리고 종료 조건 및 산출물에 대해 다음과 같이 정리할 수 있다. 

 

• 2. 결함 관리 프로세스 

  • (1) 에러 발견 요구사항 분석, 설계, 테스트 실행 중 에러가 발견될 경우, 테스트 전문가와 프로젝트 팀과 논의한다. 

  • (2) 에러 등록 결함 관리 대장에 발견된 에러를 등록한다. 

  • (3) 에러 분석 등록된 에러가 단순 에러인지 아니면 실제 결함인지 분석한다. 

  • (4) 결함 확정 등록된 에러가 실제 결함으로 확정될 경우, 결함 확정 상태로 설정한다. 

  • (5) 결함 할당 결함을 해결할 담당자를 지정하여 결함을 할당하고 결함 할당 상태로 설정한다. 

  • (6) 결함 조치 결함에 대해 수정 활동을 수행하고, 수정이 완료된 경우 결함 조치 상태로 설정한다.

  • (7) 결함 조치 검토 및 승인 수정이 완료된 결함에 대해 확인 테스트를 수행하고, 정상적으로 결함 조치가 완료된 경우 결함 조치 완료 상태로 설정한다. 

 

[3] 결함 추이 분석

• 1. 결함 추이 분석 

  • (1) 개요 

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

  • (2) 분석 유형 

    • 결함 추이 분석에는 결함의 분포 분석, 결함 추세 분석, 결함 에이징 분석 등의 유형이 있다.

 

• 2. 결함 관리 측정 지표 

  • (1) 결함 분포 

    • 각 애플리케이션 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함의 수를 측정하여 결함의 분포를 분석할 수 있다. 

  • (2) 결함 추세 

    • 테스트 진행 시간의 흐름에 따른 결함의 수를 측정하여 결함 추세를 분석할 수 있다. 

  • (3) 결함 에이징 

    • 등록된 결함에 대해 특정한 결함 상태의 지속 시간을 측정하여 분석할 수 있다.

 

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

[1] 테스트 커버리지(Test Coverage)

• 1. 개요 

  • 테스트 커버리지란 주어진 테스트 케이스에 의해 수행되는 소프트웨어의 테스트 범위를 측정하는 테스트 품질 측정 기준이며, 테스트의 정확성과 신뢰성을 향상시키는 역할을 한다. 

• 2. 기능 기반 커버리지 

  • 테스트 대상 애플리케이션의 전체 기능을 모수로 설정하고, 실제 테스트가 수행된 기능의 수를 측정하는 방법이다. 기능 기반 테스트 커버리지는 100% 달성을 목표로 하며, 일반적 으로 UI가 많은 시스템의 경우 화면 수를 모수로 사용할 수도 있다. 

• 3. 라인 커버리지(Line Coverage) 

  • 애플리케이션 전체 소스 코드의 Line 수를 모수로 테스트 시나리오가 수행한 소스 코드의 Line 수를 측정하는 방법이다. 단위 테스트에서는 이 라인 커버리지를 척도로 삼기도 한다. 

• 4. 코드 커버리지(Code Coverage) 

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

    • (1) 구문(Statement) 커버리지 

      • 코드 구조 내의 모든 구문에 대해 한 번 이상 수행하는 테스트 커버리지를 말한다. 

    • (2) 조건(Condition) 커버리지 

      • 결정 포인트 내의 모든 개별 조건식에 대해 수행하는 테스트 커버리지를 말한다. 

    • (3) 결정(Decision) 커버리지 

      • 결정 포인트 내의 모든 분기문에 대해 수행하는 테스트 커버리지를 말한다. 

    • (4) 변형 조건/결정(Modified Condition/Decision) 커버리지 

      • 조건과 결정을 복합적으로 고려한 측정 방법이며, 결정 포인트 내의 다른 개별적인 조 건식 결과에 상관없이 독립적으로 전체 조건식의 결과에 영향을 주는 테스트 커버리 지를 말한다

 

[2] 테스트 결함 식별 및 관리

• 1. 결함의 식별 

  • (1) 단계별 결함 유입 분류 

    • (가) 기획 시 유입되는 결함 

      • 사용자 요구사항의 표준 미준수로 인해 테스트 불가능, 요구사항 불명확/불완전/불 일치, 기타 결함이 발생할 수 있다. 

    • (나) 설계 시 유입되는 결함 

      • 기획 단계에 유입된 결함 또는 설계 표준 미준수로 인해 테스트 불가능, 기능 설계 불명확/불완전/불일치, 기타 결함이 발생할 수 있다. 

    • (다) 코딩 시 유입되는 결함

      • 설계 단계에 유입된 결함 또는 코딩 표준 미준수로 인해 기능의 불일치/불완전, 데이터 결함, 인터페이스 결함, 기타 결함이 발생할 수 있다. 

    • (라) 테스트 부족으로 유입되는 결함

      • 테스트 수행 시 테스트 완료 기준의 미준수, 테스트 팀과 개발 팀의 의사소통 부족, 개발자의 코딩 실수로 인한 결함이 발생할 수 있다.

  • (2) 결함 심각도별 분류 

    • 애플리케이션에 발생한 결함이 어떤 영향을 끼치며, 그 결함이 얼마나 치명적인지를 나타내는 척도이다. 

      • (가) 결함 심각도 분류 사례

        • 치명적(Critical) 결함, 주요(Major) 결함, 보통(Normal) 결함, 경미한(Minor) 결함, 단순(Simple) 결함 등으로 분류할 수 있다. 

      • (나) 결함 심각도 관리 

        • 결함 관리의 정확성과 신뢰성 향상을 위해 결함 심각도의 각 단계별로 표준화된 용어를 사용하여 정의하여야 하며, 프로젝트 및 조직 차원에서 결함 관리 활동을 수행해야 한다. 

  • (3) 결함 우선순위 

    • (가) 결함 심각도와 결함 우선순위 

      • 결함 우선순위는 발생한 결함이 얼마나 빠르게 처리되어야 하는지를 결정하는 척도로, 결함 심각도가 높아도 우선순위가 반드시 높은 것은 아니며, 애플리케이션의 특성에 따라 우선순위가 결정될 수 있다. 

    • (나) 결함 우선순위 

      • 표현 사례 결정적(Critical), 높음(High), 보통(Medium), 낮음(Low) 또는 즉시 해결, 주의 요망, 대기, 개선 권고 등으로 분류할 수 있다. 

 

• 2. 결함 관리 항목 

  • 테스트 수행 후 발견된 결함은 결함 관리 시스템에 등록하여 관리해야 하며, 등록 시 다음 항목들은 필수로 등록한다. 

    • (1) 결함 내용

    • (2) 결함 ID

    • (3) 결함 유형 

    • (4) 발견일 

    • (5) 심각도 

    • (6) 우선순위(결함 수정의 우선순위) 

    • (7) 시정 조치 예정일 

    • (8) 수정 담당자 

    • (9) 재테스트 결과 

    • (10) 종료일

 

[연습문제]

• 테스트 도구의 장점이 아닌 것은? 

  • (1) 반복되는 테스트 데이터 재입력 작업의 자동화 

  • (2) 사용자 요구 기능의 일관성 검증에 유리

  • (3) 테스트 결과 값에 대한 주관적인 평가 기준 제공

  • (4) 테스트 결과의 통계 작업과 그래프 등 다양한 표시 형태 제공

 

• 다음 코드 커버리지 중 결정 포인트 내의 모든 분기문에 대해 수행하는 테스트 는 ?

  • (1) 구문(Statement) 커버리지 

  • (2) 조건(Condition) 커버리지

  • (3) 결정(Decision) 커버리지

  • (4) 변형 조건/결정(Modified Condition/Decision) 커버리지 

 

 참고 문헌

[논문]

• 없음

[보고서]

• 없음

[URL]

• 없음

 

 문의사항

[기상학/프로그래밍 언어]

• sangho.lee.1990@gmail.com

[해양학/천문학/빅데이터]

• saimang0804@gmail.com

 

 

 

 

 

 

 

 

 

 

 

본 블로그는 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음