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

 정보

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

• 작성자     : 이상호

• 작성일     : 2020-05-10

• 설   명      :

• 수정이력 :

 

 

 내용

[1. 애플리케이션 테스트 케이스 작성]

[1] 응용 소프트웨어의 유형 및 특성 이해

• 응용 소프트웨어는 불특정 일반인에게 필요한 공통의 기능을 제공하는 상용 소프트웨어와 특정 사용자의 요구사항을 구현하기 위한 서비스 제공 소프트웨어로 구분할 수 있다. 

• 1. 상용 소프트웨어의 특성 및 유형 상업적 목적이나 판매를 목적으로 생산되나, 홍보를 위한 무료 소프트웨어도 포함할 수 있으며, 산업의 특성에 따라 산업 범용 소프트웨어와 산업 특화 소프트웨어로 구분된다.

  • (1) 산업 범용 소프트웨어 산업 범용 소프트웨어는 다시 시스템 소프트웨어, 미들웨어, 응용 소프트웨어로 구분 할 수 있으며, 임베디드/리얼타임 운영체제, 웹 애플리케이션 서버, 영상 관련 소프트 웨어 등이 대표적인 유형이다. 

    • (가) 시스템 소프트웨어: 운영체제(임베디드/리얼타임, 모바일, PC/서버 등), DBMS(DataBase Management System), 데이터 통합, 프로그래밍 언어, 스토리지 소프트웨어, 소프트웨어공학 도 구, 가상화 소프트웨어, 시스템 보안 소프트웨어 등이 있다.

    • (나) 미들웨어 :웹 애플리케이션 서버, 실시간 데이터 처리, 연계 통합 솔루션, 분산 병렬 처리, 네 트워크 관리, 시스템 관리, 클라우드 서비스, 접근 제어 소프트웨어 등이 있다.

    • (다) 응용 소프트웨어 :영상 인식/분석, 영상 코덱/스트리밍, 영상 저작/편집/합성, 3D 스캐닝/프린팅, 가상 시뮬레이션, 콘텐츠 보호/관리/유통, 정보검색, 음성 처리, 오피스웨어 소프트웨어 등이 있다.

  • (2) 산업 특화 소프트웨어  특정한 산업 분야에서 요구하는 기능만을 구현하기 위한 목적의 소프트웨어로 자동차, 항공, 조선, 건설, 패션 의류, 농업, 의료, 국방, 공공 분야 등을 지원하는 소프트웨어가 존재한다.

 

• 2. 서비스 제공 소프트웨어의 특성 및 유형 

  • 개발된 소프트웨어의 판매가 아닌 특정한 사용자의 요구사항만을 구현함을 목적으로 생산 되며, 신규 기능 개발, 기존에 개발된 기능 개선, 사용자 요구 기능의 추가 개발, 구현된 시스템의 통합을 위한 소프트웨어의 개발 등으로 유형을 분류할 수 있다. 

    • (1) 신규 개발 소프트웨어 

      • 새로운 서비스 제공을 목적으로 개발되며, 일반적으로 초기 개발 단계, 확장 단계, 기 능 고도화 단계 등으로 진행된다. 

    • (2) 기능 개선 소프트웨어 

      • 기존 서비스 기능에서 사용자 편의성 개선, 응답 속도 개선, 화면 UI(User Interface) 개선, 업무 프로세스 개선 등의 목적으로 개발되는 소프트웨어이다. 

    • (3) 추가 개발 소프트웨어 

      • 기존 서비스 제공 시스템에 업무 환경의 변화, 산업 환경의 변화, 법/제도의 개정 등으로 인해 새로운 기능을 추가로 개발하는 소프트웨어를 말한다. 

    • (4) 시스템 통합 소프트웨어 

      • 각각 별도로 서비스되는 시스템을 원스톱(One-Stop) 서비스 제공을 위해 업무 기능 및 데이터 등을 통합하여 개발하는 소프트웨어이다

 

[2]소프트웨어 테스트의 이해

• 1. 소프트웨어 테스트의 개념 

  • 소프트웨어 테스트란 구현된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능의 동작과 성능, 사용성, 안정성 등을 만족하는지 확인하기 위하여 소프트웨어의 결함을 찾아 내는 활동이다. 

• 2. 소프트웨어 테스트의 필요성 

  • (1) 오류 발견 관점 프로그램에 잠재된 오류를 발견하고 이를 수정하여 올바른 프로그램을 개발하는 활동이다. 

  • (2) 오류 예방 관점 프로그램 실행 전에 코드 리뷰, 동료 검토, 인스펙션 등을 통해 오류를 사전에 발견하 는 예방 차원의 활동이다. 

  • (3) 품질 향상 관점 사용자의 요구사항 및 기대 수준을 만족하도록 반복적인 테스트를 거쳐 제품의 신뢰 도를 향상하는 품질 보증 활동이다.

• 3. 소프트웨어 테스트의 기본 원칙 

  • (1) 소프트웨어 테스트의 원리 

    • (가) 테스팅은 결함이 존재함을 밝히는 활동이다. 테스팅은 소프트웨어의 잠재적인 결함을 줄일 수 있지만, 결함이 발견되지 않아도 결함이 없다고 증명할 수 없음을 나타낸다. 

    • (나) 완벽한 테스팅은 불가능하다. 무한 경로, 무한 입력 값, 무한 시간이 소요되어 완벽하게 테스트할 수 없으므로 리스크 분석과 우선순위를 토대로 테스트에 집중할 것을 의미한다. 

    • (다) 테스팅은 개발 초기에 시작해야 한다. 애플리케이션의 개발 단계에 테스트를 계획하고 SDLC(Software Development Life Cycle)의 각 단계에 맞춰 전략적으로 접근하는 것을 고려하라는 뜻이다.

    • (라) 결함 집중(Defect Clustering) 애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재한다. 

    • (마) 살충제 패러독스(Presticide Paradox)

      • 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 리뷰하고 개선해야 한다. 

    • (바) 테스팅은 정황(Context)에 의존한다. 

      • 정황과 비즈니스 도메인에 따라 테스트를 다르게 수행하여야 한다. 

    • (사) 오류-부재의 궤변(Absence of Errors Fallacy) 

      • 사용자의 요구사항을 만족하지 못하는 오류를 발견하고 그 오류를 제거하였다 해 도, 해당 애플리케이션의 품질이 높다고 말할 수 없다.  

• (2) 소프트웨어 테스트 프로세스 일반적인 테스트 프로세스는 테스트 계획, 테스트 분석, 테스트 디자인, 테스트 케이스 및 시나리오 작성, 테스트 수행, 테스트 결과 평가 및 리포팅의 절차로 이루어진다.

 

 

• (3) 소프트웨어 테스트 산출물 

  • (가) 테스트 계획서 테스트 목적과 범위 정의, 대상 시스템 구조 파악, 테스트 수행 절차, 테스트 일정, 조직의 역할 및 책임 정의, 종료 조건 정의 등 테스트 수행을 계획한 문서 

  • (나) 테스트 케이스 테스트를 위한 설계 산출물로, 응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서 

  • (다) 테스트 시나리오 테스트 수행을 위한 여러 개의 테스트 케이스의 집합으로 테스트 케이스의 동작 순서를 기술한 문서이며, 테스트를 위한 절차를 명세한 문서 

  • (라) 테스트 결과서 테스트 결과를 정리한 문서로 테스트 프로세스를 리뷰하고, 테스트 결과를 평가하고 리포팅하는 문서 
    

 

[3] 소프트웨어 테스트의 유형

• 1. 프로그램 실행 여부 

  • (1) 정적 테스트 프로그램 실행 없이 소스 코드의 구조를 분석하여 논리적으로 검증하는 테스트로 인 스펙션, 코드 검사, 워크스루 등이 있다. 

  • (2) 동적 테스트 프로그램의 실행을 요구하는 테스트로 화이트박스 테스트와 블랙박스 테스트가 있다.

• 2. 테스트 기법 

  • (1) 화이트박스 테스트 프로그램의 내부 로직(수행 경로 구조, 루프 등)을 보면서 테스트를 수행한다. 

  • (2) 블랙박스 테스트 프로그램의 외부 사용자 요구사항 명세를 보면서 테스트, 주로 구현된 기능을 테스트 한다. 

• 3. 테스트에 대한 시각

  • (1) 검증(Verification) 제품의 생산 과정을 테스트한다(Are we building the product right?). 올바른 제품을 생산하고 있는지 검증하는 것을 의미한다. 

  • (2) 확인(Validation) 생산된 제품의 결과를 테스트한다.(Are we building the right product?) 생산된 제품이 정상적으로 동작하는지 확인하는 것을 의미한다.

• 4. 테스트 목적 

  • (1) 회복(Recovery) 테스트 

    • 시스템에 고의로 실패를 유도하고 시스템이 정상적으로 복귀하는지 테스트한다. 

  • (2) 안전(Security) 테스트 

    • 불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스코드 내의 보안적 인 결함을 미리 점검하는 테스트이다. 

  • (3) 강도(Stress) 테스트 

    • 시스템에 과다 정보량을 부과하여 과부하 시에도 시스템이 정상적으로 작동되는지를 검증하는 테스트이다. 

  • (4) 성능(Performance) 테스트 

    • 사용자의 이벤트에 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는 속도 등을 테스트한다. 

  • (5) 구조(Structure) 테스트 

    • 시스템의 내부 논리 경로, 소스코드의 복잡도를 평가하는 테스트이다. 

  • (6) 회귀(Regression) 테스트 

    • 변경 또는 수정된 코드에 대하여 새로운 결함 발견 여부를 평가하는 테스트이다. 

  • (7) 병행(Parallel) 테스트 

    • 변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트이다. 

 

• 5. 테스트 종류 

  • (1) 명세 기반 테스트 

    • 주어진 명세를 빠짐없이 테스트 케이스로 구현하고 있는지 확인하는 테스트를 말하며, 동등 분할, 경계 값 분석, 유한상태 기계기반, 결정 테이블, 정형명세 기반, 유스케이 스, 페어와이즈, 직교배열 테스트 등이 있다. 

  • (2) 구조 기반 테스트

    •  소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트를 말 하며, 구문 기반, 결정 반, 조건 기반, 조건결정 기반, 변경조건 결정 기반, 멀티조건 기반 커버리지 테스트 등이 있다. 

  • (3) 경험 기반 테스트 

    • 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로 한, 직관과 기술 능력 을 기반으로 수행하는 테스트를 말한다. 

 

[4] 테스트 케이스와 테스트 오라클의 이해.

• 1. 테스트 케이스의 개념 

  • 명세 기반 테스트의 설계 산출물로, 특정한 프로그램의 일부분 또는 경로에 따라 수행하 거나, 특정한 요구사항을 준수하는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결 과로 구성된 테스트 항목의 명세서를 말한다.

• 2. 테스트 케이스 작성 

  • 테스트 케이스의 정확성, 재사용성, 간결성 보장을 위해 아래의 절차에 따라 작성한다.  =

    • (1) 테스트 계획 검토 및 자료 확보 테스트 대상 프로젝트 범위와 접근 방법 이해를 위하여 테스트 계획을 재검토한다. 

      • 테스트 대상 시스템 자료와 정보를 확보하여, 시스템 요구사항과 기능 명세서를 검토한다. 

    • (2) 위험 평가 및 우선순위 결정 결함 해결에 있어 상대적 중요성을 지니며 테스트의 초점을 결정한다. 

    • (3) 테스트 요구사항 정의 시스템 요구사항, 테스트 대상 재검토, 테스트할 특성, 조건, 기능을 식별 및 분석한다.

    • (4) 테스트 구조 설계 및 테스트 방법 결정 

      • 테스트 케이스의 일반적 형식을 결정하고, 테스트 케이스 분류 방법을 결정한다. 테스트 절차, 장비, 도구, 테스트 문서화 방법을 결정한다. 

    • (5) 테스트 케이스 정의 

      • 각 요구사항에 대해 테스트 케이스를 작성하고, 입력 값, 실행 조건, 예상 결과를 기술한다. 

    • (6) 테스트 케이스 타당성 확인 및 유지 보수 

      • 기능 또는 환경 변화에 따라 테스트 케이스를 갱신하고, 테스트 케이스의 유용성을 검토한다. 

• 3. 테스트 오라클의 개념

• (1) 테스트 오라클 정의 

  • 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참 값을 입력하여 비교하는 기법 및 활동을 말한다. 

• (2) 테스트 오라클 유형 

  • (가) 참(True) 오라클 : 모든 입력 값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출할 수 있는 오라클이다. 

  • (나) 샘플링(Sampling) 오라클 : 특정한 몇 개의 입력 값에 대해서만 기대하는 결과를 제공해 주는 오라클이다. 

  • (다) 휴리스틱(Heuristic) 오라클 : 샘플링 오라클을 개선한 오라클로, 특정 입력 값에 대해 올바른 결과를 제공하고, 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클이다. 

    (라) 일관성 검사(Consistent) 오라클 : 애플리케이션 변경이 있을 때, 수행 전과 후의 결과 값이 동일한지 확인하는 오라 클이다.

• (3) 오라클 적용 방안 

  • 참 오라클은 주로 항공기, 임베디드, 발전소 소프트웨어 등 미션 크리티컬한 업무에 적용 하고, 샘플링/추정 오라클은 일반, 업무용, 게임, 오락 등의 일반적인 업무에 적용한다

 

[2.수행-애플리케이션 테스트 케이스 작성하기]

[1] 개발하고자 하는 응용 소프트웨어의 유형을 분류하고, 유형별 특성을 정리한다.

• 1. 응용 소프트웨어의 사용 대상과 제공 기능을 조사하여 유형을 분류하고, 유형별 특성을 반영한 테스트 시 중점 사항에 대해 정리한다. 

  • (1) 상용 소프트웨어와 서비스 제공 소프트웨어를 분류한다. 

  • (2) 산업 범용 응용 소프트웨어와 산업 특화 응용 소프트웨어를 분류한다. 

  • (3) 응용 소프트웨어의 개발 환경 및 사용 환경을 분류한다. 

  • (4) 서비스 제공 응용 소프트웨어의 유형별 특성을 정리한다.

 

[2] 응용 소프트웨어의 요구사항을 분석한다. 

• 요구사항 명세서에 반영된 사용자 요구사항, 시스템 요구사항, 애플리케이션의 기능 요구 사항 및 비기능 요구사항에 대해 분석한다.

• 1. 기능 요구사항 명세를 분석하고 분석표를 작성한다. 사용자 요구사항의 기능 구현 여부를 확인할 수 있도록 구현 방안과 검증 방안을 포함한 기능 요구사항 분석표를 작성한다.

  • (1) 요구사항 명세서의 업무 기능에 대한 사용자 요구사항을 확인한다. 

  • (2) 애플리케이션의 기능 구현 방안 및 검증 방안을 확인한다. 

  • (3) 기능 요구사항 명세에 대한 분석표를 작성한다.

• 2. 비기능 요구사항 명세를 분석하고 분석표를 작성한다. 애플리케이션의 비기능 요구사항(보안, 성능, 품질, 테스트 등)에 대해 확인하고, 검증 방 안을 포함한 분석표를 작성한다. 

  • (1) 요구사항 명세서의 비기능 요구사항 확인 및 검증 방안을 분석한다. 

  • (2) 애플리케이션의 비기능 검증 방안을 확인한다. 

  • (3) 비기능 요구사항 명세에 대한 분석표를 작성한다.
    

[3] 분석된 요구사항에 근거한 테스트 방식, 대상과 범위를 결정한다. 

• 개발하고자 하는 응용 소프트웨어의 특성을 반영한 테스트 방식과 테스트 대상과 테스트 범위를 결정한다. 

• 1. 애플리케이션의 기능 구현 여부 및 비기능 검증을 위한 테스트 방식을 결정한다. 개발된 애플리케이션의 코드 실행 여부, 프로그램 내부 로직 검토 여부, 프로그램 외부 명 세 참조 여부, 프로그램 실행 여부 등 다양한 테스트 방식 중 최적의 테스트 방식을 결정 한다. 

  • (1) 테스트 방식을 결정하는 요소를 식별한다. 

    • (가) 진행 중인 프로젝트의 개발 수명 주기와 테스트 단계를 파악한다. 요구사항 분석, 기능 명세 분석, 테스트 설계, 테스트 개발 등의 테스트 계획 및 설 계 단계와, 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트라는 일련의 애 플리케이션 테스트 수행 단계의 관계를 파악한다.

    • (나) 각 테스트의 단계별 기능 검증 사항에 대해 파악한다. 

      • 1) 단위 테스트 단계의 기능 검증 사항을 파악한다. 구현된 모듈(함수, 서브루틴, 컴포넌트 등)의 기능 수행 여부를 판정하고, 내부 에 존재하는 논리적 오류를 검출할 수 있는 방안을 파악한다. 

      • 2) 통합 테스트 단계의 기능 검증 사항을 파악한다. 모듈 간의 인터페이스 연계를 검증하고, 모듈 간의 인터페이스 오류를 확인하 고, 모듈 간의 상호 작용 및 연계 동작 여부를 판정하는 방안을 파악한다. 

      • 3) 시스템 테스트 단계의 기능 검증 사항을 파악한다. 단위, 통합 테스트 후 전체 시스템이 정상적으로 작동하는지 판정하는 기능 명 세를 확인하는 방안을 파악한다. 

      • 4) 인수 테스트 단계의 기능 검증 사항을 파악한다. 사용자가 요구분석 명세서에 명시된 사항을 모두 충족하는지 판정하고, 시스템 이 예상대로 동작하고 있는지를 판정하는 방안을 파악한다. 

    • (다) 작업 분할 구조도(WBS, Work Breakdown Structure)와 현재 프로젝트 진행 상황 을 판단한다. 

    • (라) 테스트 일정과 테스트 투입 인력 등 테스트 비용에 대해 산정한다.

  • (2) 개발 수명 주기별 기능 구현 여부를 검증할 테스트 방식을 결정한다. 프로젝트 초기 단계에 개발된 코드를 수동 또는 자동화된 기법으로 검토하는 정적 테 스트와 프로그램을 실행하며 테스트하는 동적 테스트 중 적절한 방식을 결정한다. 

  • (3) 애플리케이션의 비기능 검증을 위한 테스트 방식을 결정한다. 비기능 요소를 식별하고, 성능 테스트, 보안 테스트, 품질 테스트, 사용성 테스트 등 적절한 테스트 방식을 결정한다.

 

• 2. 테스트 대상과 테스트 범위를 결정한다. 개발된 응용 소프트웨어가 단위 시스템인지, 통합 시스템인지, 연계 시스템인지 여부를 식 별하고, 테스트 대상과 테스트 범위를 결정한다. 

  • (1) 테스트 대상을 결정하는 요소를 식별한다. 

    • (가) 개발된 애플리케이션의 시스템 유형에 따라 테스트 대상을 판단한다. 

    • (나) 단일 시스템 구현과 연계 및 통합 시스템 구현을 판단한다. 

    • (다) 연계 및 통합 시스템의 경우 개발 시스템에서의 테스트 가능 여부를 판단한다. 

  • (2) 테스트 범위를 결정하는 요소를 식별한다. 

    • (가) 개발하고자 하는 애플리케이션의 범위 및 상위 요구사항에 따라 테스트 범위를 판단하다. 

    • (나) 기능을 검증하는 테스트의 경우 추가 사항으로 테스트 횟수를 결정한다. 

    • (다) 비기능 검증을 위한 테스트의 경우 결과 값 산출 방식을 결정한다.

  • (3) 식별된 테스트 결정 요소를 기반으로 테스트 대상과 테스트 범위를 결정한다.

 

[4]결정된 테스트 방식, 대상과 범위를 고려하여 테스트 케이스를 작성한다.

• 1. 테스트 케이스 작성에 필요한 항목을 결정한다. 

  • (1) 테스트 케이스 항목 중 공통 작성 항목 요소를 식별한다. 

    • (가) 테스트 단계 명, 작성자, 승인자, 작성 일자, 문서 버전을 식별한다. 단위/통합/시스템/인수 테스트 등의 테스트 단계와, 테스트 케이스 작성자, 승인자, 작성 일자, 버전 등을 작성한다. 

    • (나) 대상 시스템을 식별한다. 애플리케이션 개발 서버 또는 개발 시스템 명 등을 작성한다. 

    • (다) 변경 여부를 식별한다. 테스트 케이스 변경 여부 및 변경 사유 등을 작성한다. 

    • (라) 테스트 범위를 식별한다. 테스트 대상 애플리케이션의 기능별 테스트 범위 및 업무별 테스트 범위를 식별한다. 

    • (마) 테스트 조직을 식별한다. 테스트 케이스 작성 및 테스트 수행을 담당할 조직을 식별한다

  • (2) 개별 테스트 케이스 항목 요소를 식별한다. 

    • (가) 테스트 ID를 작성한다. 

      • 테스트 케이스를 고유하게 식별하기 위한 ID를 작성한다. 

    • (나) 테스트 목적을 작성한다. 

      • 테스트 시 고려해야 할 중점 사항이나 테스트 케이스의 목적을 작성한다. 

    • (다) 테스트할 기능을 요약한다. 

      • 애플리케이션의 테스트할 기능을 간략하게 작성한다. 

    • (라) 입력 데이터를 작성한다. 

      • 테스트 실행 시 입력할 테이터(입력 값, 선택 버튼, 체크리스트 값 등)를 작성한다. 

    • (마) 기대 결과를 작성한다.

      • 테스트 실행 후 기대되는 결과 데이터(출력 데이터, 결과 화면, 기대 동작 등)를 작성한다.

    • (바) 테스트 환경을 설정한다.

      • 테스트 시 사용할 물리적, 논리적 테스트 환경, 사용할 데이터, 결과 기록 서버 등 의 내용을 작성한다. 

    • (사) 전제 조건을 설정한다. 

      • 테스트 간의 종속성, 테스트 수행 전 실행되어야 할 고려 사항 등을 작성한다. 

    • (아) 성공/실패 기준을 설정한다. 

      • 테스트를 거친 애플리케이션 기능의 성공과 실패를 판단하는 조건을 명확하게 작성한다. 

    • (자) 기타 요소를 식별하여 설정한다. 

    • 사용자의 테스트 요구사항 중 특별히 고려해야 할 내용을 간략하게 기술한다.

• 2. 식별된 항목 요소를 반영한 테스트 케이스를 작성한다. 

  • 공통 항목 요소와 개별 항목 요소를 적용하여 테스트 케이스 명세를 작성한다. 

 

[3. 애플리케이션 테스트 시나리오 작성]  

[1] 테스트 시나리오의 이해

• 1. 테스트 시나리오의 개념 

  • (1) 테스트 시나리오의 정의 

    • 테스트 수행을 위한 여러 테스트 케이스의 집합으로서, 테스트 케이스의 동작 순서를 기술한 문서이며 테스트를 위한 절차를 명세한 문서이다. 

  • (2) 테스트 시나리오의 필요성  테스트 수행 절차를 미리 정함으로써 설계 단계에서 중요시되던 요구사항이나 대안 흐름과 같은 테스트 항목을 빠짐없이 테스트하기 위함이다.

• 2. 테스트 시나리오 작성 시 유의점 

  • (1) 테스트 시나리오 분리 작성 

    • 테스트 항목을 하나의 시나리오에 모두 작성하지 않고, 시스템별, 모듈별, 항목별 테스트 시나리오를 분리하여 작성한다. 

  • (2) 고객의 요구사항과 설계 문서 등을 토대로 테스트 시나리오를 작성한다. 

  • (3) 각 테스트 항목은 식별자 번호, 순서 번호, 테스트 데이터, 테스트 케이스, 예상 결 과, 확인 등의 항목을 포함하여 작성한다. 

[2] 테스트 환경 구축의 이해

• 1. 테스트 환경 구축의 개념 

  • 개발된 응용 소프트웨어가 실제 운영 시스템에서 정상적으로 작동하는지 테스트할 수 있도록 하기 위하여 실제 운영 시스템과 동일 또는 유사한 사양의 하드웨어, 소프트웨어, 네트워크 등의 시설을 구축하는 활동이다.

• 2. 테스트 환경 구축의 유형 

  • (1) 하드웨어 기반의 테스트 환경 구축 서버 장비(WAS 서버, DBMS 서버), 클라이언트 장비(노트북 또는 PC), 네트워크(내부 LAN 또는 공용 인터넷 라인) 장비 등의 장비를 설치하는 작업이다. 

  • (2) 소프트웨어 기반의 테스트 환경 구축 구축된 하드웨어 환경에 테스트할 응용 소프트웨어를 설치하고 필요한 데이터를 구축 하는 작업이다. 

  • (3) 가상 시스템 기반의 테스트 환경 구축 물리적으로 개발 환경 및 운영 환경과 별개로 독립된 테스트 환경을 구축하기 힘든 경우에는, 가상 머신(Virtual Machine) 기반의 서버 또는 클라우드 환경을 이용하여 테 스트 환경을 구축하고, 네트워크는 VLAN과 같은 기법을 이용하여 논리적 분할 환경을 구축할 수 있다.

[3] 테스트 데이터 및 테스트 조건의 이해

• 1. 테스트 데이터의 개념 컴퓨터의 동작이나 시스템의 적합성을 시험하기 위해 특별히 개발된 데이터 집합으로서 프로그램의 기능을 하나씩 순번에 따라 확실하게 테스트할 수 있도록 조건을 갖춘 데이터를 말한다. 

  • (1) 테스트 데이터의 필요성 

    • 테스트 수행 시 잘못된 데이터를 사용하면 잘못된 결과가 도출되어 시간을 낭비하고 비용만 소진하는 결과가 나온다. 따라서 테스트를 효율적으로 운용하고 데이터의 기밀 을 유지하며 신뢰 및 예측 가능한 테스트를 위해 테스트 데이터의 준비가 필요하다. 

  • (2) 테스트 데이터의 유형 

    • 선행된 연산에 의해 얻어진 실제 데이터와 인위적으로 만들어진 가상의 데이터로 구분된다. 

  • (3) 테스트 데이터 준비 

    • 실제 데이터는 연산에 의해 준비하거나 실제 운영 데이터를 복제하여 준비할 수 있으 며, 가상의 데이터는 스크립트를 통해서 생성할 수 있다.
      

• 2. 테스트 조건의 개념 
  

  • (1) 테스트 시작 조건 

    • 테스트 계획의 수립, 사용자 요구사항에 대한 테스트 명세의 작성, 투입 조직 및 참여 인력의 역할과 책임의 정의, 테스트 일정의 확정, 테스트 환경의 구축 등이 완료되었을 때 테스트를 시작하도록 조건을 정의할 수 있으며, 단계별 또는 회차별 테스트 수 행을 위해 모든 조건을 만족하지 않아도 테스트를 시작할 수 있다. 

  • (2) 테스트 종료 조건 

    • 테스트의 종료는 정상적인 테스트를 모두 수행한 경우, 차기 일정의 도래로 테스트 일 정이 만료되었을 경우, 테스트에 소요되는 비용을 모두 소진한 경우 등 업무 기능의 중요도에 따라 조건을 달리 정할 수 있다. 

  • (3) 테스트 성공과 실패의 판단 기준  기능 및 비 기능 테스트 시나리오에 기술된 예상 결과를 만족하면 성공으로 아니라면 실패로 판단할 수 있으며, 또는 동일한 데이터 또는 이벤트를 중복하여 테스트하여도 여전히 이전 테스트와 같은 결과가 나올 때 성공으로 판단할 수도 있다.

 

[1] 기존에 수립된 테스트 계획을 검토한다.

• 1. 테스트 목적, 범위 설정 및 테스트 전략을 수립한다. 

  • (1) 해당 단계에서의 테스트 목적을 설정한다. 

  • (2) 테스트 대상 시스템의 범위를 설정한다. 

  • (3) 테스트 대상 애플리케이션 기능의 범위를 설정한다. 

  • (4) 수행할 테스트 방법을 결정한다. 

  • (5) 대상 시스템에 대한 소프트웨어 및 하드웨어 구조를 파악하여 정리한다. 

• 2. 테스트 일정 계획을 검토한다. 

  • (1) 테스트 활동의 주요 일정을 정의한다. 

  • (2) 단계별 테스트 투입 인력을 검토한다.
    

[2] 테스트 조직 및 역할을 정의한다.

• 1. 각 테스트 참가 조직별 역할 및 책임을 정의한다. 개발자, 테스트 책임자(PL), 프로젝트 책임자(PM), 인수 책임자(사용자 또는 주관 기관)별 책임과 역할을 정의한다.

• 2. 각 단계별 테스트 조직 및 역할을 정의한다. 

  • (1) 단위 테스트 조직을 구성한다. 

    • 응용 시스템 개발 팀에서 SW 준비, 테스트 데이터 준비 등의 테스트 환경을 준비하고 결함을 수정하는 역할을, 프로젝트 테스트 팀에서 단위 테스트를 수행하고 결함 수정 여부를 재검사하는 역할을 한다. 

  • (2) 통합 테스트 조직을 구성한다. 

    • 응용 시스템 개발 팀에서 통합 테스트 환경을 준비하는 한편 결함 수정을 하고, 본사 에서 지원하는 본사 테스트 팀에서 통합 테스트를 수행할 수 있다. 

  • (3) 시스템 테스트 조직을 구성한다. 

    • 프로젝트 테스트 팀에서 시스템 테스트를 계획, 설계, 수행 및 보완 등의 역할을 수행한다. 

  • (4) 인수 테스트 조직을 구성한다.  응용 시스템 개발 팀, 프로젝트 테스트 팀, 고객 등으로 조직을 구성하고, 인수 테스트 계획, 설계, 수행 및 결과 보고의 역할을 수행할 수 있다.

[3] 통합 테스트를 위한 테스트 데이터, 시작 및 종료 조건을 준비한다

• 1. 테스트 수행을 위한 테스트 데이터를 준비한다. 
  

  • (1) 기존 시스템에서 운영되는 실제 데이터를 사용하여 준비한다. 

    • 현재 운영 중인 시스템 또는 서버의 데이터를 복사하여 준비하고, 필요 시 데이터 프라이버시 규제를 준수하기 위하여 연산을 통해 개인정보를 마스킹처리한다. 

  • (2) 가상의 데이터를 생성하고 준비한다.

    •  데이터 생성 프로그램 또는 DBMS의 SQL을 이용하여 데이터를 생성하고, 보안을 준수 할 수 있도록 데이터 프로파일링 처리를 한다. 

• 2. 테스트 수행을 위한 시작 조건 및 종료 조건을 준비한다. 

  • (1) 테스트 수행을 위한 시작 조건을 정의한다. 

  • (2) 테스트 완료를 위한 종료 조건을 정의한다.

 

[4] 테스트 방식, 대상과 범위를 반영한 테스트 시나리오를 정의한다.

• 개발하고자 하는 응용 소프트웨어의 특성을 반영하여 통합 테스트를 위한 테스트 시나리오를 정의한다. 

  • 1. 테스트 시나리오 작성 방법을 결정한다. 개발된 애플리케이션의 테스트 대상, 업무 기능, 테스트 방법에 따라 테스트 시나리오를 정의한다. 

    • (1) 각 업무 단위별 테스트 시나리오를 정의한다. 

      • (가) 진행 중인 프로젝트의 개발 수명 주기를 판단한다. 

      • (나) 작업 분할 구조도와 현재 프로젝트 진행 상황을 판단한다. 

      • (다) 테스트 일정과 테스트 투입 인력 등 테스트 비용을 산정한다. 

    • (2) 대상 시스템별 테스트 시나리오를 정의한다. 

      • 테스트 대상이 되는 시스템을 분류하여 각 시스템별(고객 관리 시스템, 고객센터, 인사 /급여 관리 시스템 등), 기능 분할 모듈별, 테스트 항목별 테스트 시나리오를 정의한다. 

    • (3) 테스트 방법에 따른 테스트 시나리오를 정의한다. 
      사용자 요구사항에 맞는 기능 테스트, 성능 테스트, 보안 테스트, 품질 테스트, 사용성 테스트 등 적절한 테스트 방법에 따른 테스트 시나리오를 정의한다
      

• 2. 통합 테스트 수행을 위한 테스트 시나리오를 작성한다. 

  • (1) 구현된 기능의 업무 흐름에 따른 테스트 시나리오를 작성한다. 

    • (가) 기본 흐름을 검증할 수 있는 테스트 시나리오를 작성한다. 

    • (나) 대체 흐름을 검증할 수 있는 테스트 시나리오를 작성한다. 

    • (다) 예외 발생 시 검증 가능한 테스트 시나리오를 작성한다. 

  • (2) 단순 요구 기능의 구현 여부를 검증하는 테스트 시나리오를 작성한다. 

    • (가) 체크리스트 형태의 테스트 시나리오를 작성한다. 

    • (나) 화면 정의를 포함하는 형태의 테스트 시나리오를 작성한다. 

  • (3) 입력 데이터에 따른 기능 검증을 위한 테스트 시나리오를 작성한다. 

    • (가) 정상 데이터 범위를 가정한 테스트 시나리오를 작성한다. 

    • (나) 비정상 데이터 범위를 가정한 테스트 시나리오를 작성한다.
      

• 3. 비기능 테스트 수행을 위한 테스트 시나리오를 작성한다. 

  • 비기능 요소를 식별하고, 성능, 보안, 품질, 사용성 요구사항을 검증할 수 있는 테스트 시나리오를 작성한다. 

    • (1) 성능 요구사항 검증을 위한 테스트 시나리오를 작성한다. 

    • (2) 품질 요구사항 검증을 위한 테스트 시나리오를 작성한다. 

    • (3) 보안 요구사항 검증을 위한 테스트 시나리오를 작성한다. 

    • (4) 사용성 요구사항 검증을 위한 테스트 시나리오를 작성한다.
      

• 4. 테스트 시나리오 작성 시 고려할 사항을 정의한다. 

  • (1) 유스케이스(Use Case)간 업무 흐름이 정상 동작되는지 테스트할 수 있는 시나리오 를 정의한다. 

  • (2) 개발된 각 모듈 또는 프로그램의 연계가 정상적으로 이루어지는지 테스트할 수 있 는 시나리오를 정의한다. 

  • (3) 서브시스템이 존재할 경우 각 시스템의 연계가 정상적으로 이루어지는지 테스트할 수 있는 시나리오를 정의한다.
    

 

[5] 작성된 테스트 시나리오를 수행하기 위한 테스트 환경을 준비한다.

• 1. 테스트 수행을 위한 하드웨어 환경을 준비한다. 

  • (1) 테스트 환경 구현을 위한 서버를 구축한다. 

    • (가) 운영 환경과 동일한 사양의 테스트 서버를 설치한다. 

    • (나) 해당 DBMS 설치 및 사용자 권한을 설정한다. 

  • (2) 기존 시스템을 이관한다. 

    • 현재 운영되고 있는 시스템의 일부를 테스트 환경으로 옮겨서 구축한다.
      

• 2. 테스트 수행을 위한 소프트웨어 환경을 준비한다. 

  • (1) 테스트 환경 구현을 위한 애플리케이션을 설치한다. 

    • (가) 응용 프로그램 통합 및 환경을 구축한다. 

      • 개발 서버에서 완성된 프로그램을 테스트 서버에 설치하고, 사용자 권한 설정 등 테스트 시 WAS(Web Application Server) 또는 DBMS(Database Management System) 서버에 접근 가능한 환경을 구축한다. 

    • (나) 기타 프로그램을 설치한다. 

      • 사용자의 테스트 요구사항 중 특별한 내용을 중점적으로 테스트할 수 있는 프로그램 등을 설치한다.
        

  • (2) 가상 환경에서의 테스트를 위한 테스트 환경을 구축한다. 

    • (가) 가상 머신 테스트 환경을 구축한다. 

      • 기존 개발 서버 또는 운영 서버에 가상 머신 프로그램을 설치하고, 라우터 또는 스 위치 등 네트워크 장비에 VLAN을 설정한다. 

    • (나) 클라우드 기반의 테스트를 위한 환경을 구축한다. 

      • 클라우드 테스트 환경을 이용하기 위한 계정 설정 및 각종 옵션 기능을 설정한다.

 

[연습문제]

• 서비스 제공 소프트웨어의 특성 및 유형 에 대한 설명이 잘못된 것은?

  • (1) 신규 개발 소프트웨어 
    새로운 서비스 제공을 목적으로 개발되며, 일반적으로 초기 개발 단계, 확장 단계, 기 능 고도화 단계 등으로 진행된다. 

  • (2) 기능 개선 소프트웨어 
    기존 서비스 기능에서 사용자 편의성 개선, 응답 속도 개선, 화면 UI(User Interface) 개선, 업무 프로세스 개선 등의 목적으로 개발되는 소프트웨어이다. 

  • (3) 응용 개발 소프트웨어 
    기존 서비스 제공 시스템에 업무 환경의 변화, 산업 환경의 변화, 법/제도의 개정 등으로 인해 새로운 기능을 추가로 개발하는 소프트웨어를 말한다. 

  • (4) 시스템 통합 소프트웨어 
    각각 별도로 서비스되는 시스템을 원스톱(One-Stop) 서비스 제공을 위해 업무 기능 및 데이터 등을 통합하여 개발하는 소프트웨어이다.

 

• 테스트의 목적이 잘못된 것은?

  • (1) 회복(Recovery) 테스트 
    시스템에 고의로 실패를 유도하고 시스템이 정상적으로 복귀하는지 테스트한다. 

  • (2) 안전(Security) 테스트 
    불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스코드 내의 보안적 인 결함을 미리 점검하는 테스트이다. 

  • (3) 과부하테스트 
    시스템에 과다 정보량을 부과하여 과부하 시에도 시스템이 정상적으로 작동되는지를 검증하는 테스트이다. 

  • (4) 성능(Performance) 테스트 
    사용자의 이벤트에 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는 속도 등을 테스트한다.

 

 참고 문헌

[논문]

• 없음

[보고서]

• 없음

[URL]

• 없음

 

 문의사항

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

• sangho.lee.1990@gmail.com

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

• saimang0804@gmail.com

 

 

 

 

 

 

 

 

 

 

 

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