통합테스트 시나리오 템플릿 - tonghabteseuteu sinalio tempeullis


Project/06. 테스트 이행

테스트 시나리오 템플릿 및 예제

2009. 11. 26. 11:03

테스트를 수행하기 위한 테스트 시나리오 작성

규칙 :

1. 테스트 시나리오는 전체 시스템의 모든 테스트 항목을 하나의 시나리오에 모두 작성하는 것이 아니라. 다음과 같은 기준으로 분리해서 작성한다.
1.1 시스템 : 테스트 대상이 되는 시스템 (시스템은 큰 시스템이 될수 있고, 경우에 따라 기능분할도에 작성된 대분류가 될 수 있다. )
     예) 고객관리 시스템 (큰 분류), 고객센터, 장바구니 (기능분할의 대분류).....
1.2 모듈 : 이 모듈은 테스트 대상이 되는 부분으로 기능분할도의 대분류가 적합할 것이다. 경우에 따라 시스템이 뎁스가 매우 깊은경우 중분류가 될수 있을 것이다.
     예) 고객센터 (대분류)
1.3 항목 : 각 테스트 할 하나의 그룹을 의미하며, 기능분할도의 중분류가 적합하다.
     예) 장바구니 > 사은품 선택 (중분류)

Tip :

- 상단에 기제된 [시스템].[모듈].[항목] 으로 분리된 내용들은, 단위테스트 역시 작은 단위로 쪼개서 하나의 스텝 개념으로 가져가는것이 테스트 항목 누락이 적고, 테스트의 지루함을 없앨수 있다.
- 또한 이러한 상세 분류를 지정함으로 해서 테스트 결과의 피드백을 보다 명확하게 정의하여, 수정시 빠른 문제지점을 트래킹할 수 있는 지침이 된다.
- 테스트를 수행할때 실제 결과값을 검토할경우, 검토값을 미리 확인하거나, 결과값을 빠르게 인지할 수 있는 스크립트나, 핵심 포인트를 미리 만들어두고 테스트를 하면 빠르고 정확하게 테스트 할수 있다.

(하단의 예에서, 재고수량 검증 부분에서 보면 재고검증을 할수 있는 쿼리를 미리 작성하는것이 그 예이다.)

템플릿 파일  :

샘플 예제 :

통합테스트 시나리오 템플릿 - tonghabteseuteu sinalio tempeullis



사용자 테스트(UAT) 시나리오 템플릿입니다.

각 조직과 프로젝트 성격에 따라 다르게 적용될 수 있지만, 요구사항을 정의, UAT 시나리오 작성 및 UAT 수행은 일반적으로 해당 시스템을 사용하는 사용자가 책임지는 부분입니다.(*V자 이론 참조)

(일부 프로젝트에서는 UAT 시나리오를 프로젝트 수행하는 쪽에서 친절하게 다 만들어주는데...., 역할 구분이 명확하지 못하여 나중에 업무 책임 관련 이슈가 발생하기도 합니다.)

Skip to end of metadata

  • Page restrictions apply
  • Added by admin, last edited by admin on Oct 26, 2017  (view change)

Go to start of metadata

통합테스트시나리오 작성표준산출물 책임자: 테스터

표준 개정일: 2005.01.01

  1. 개요(Overview)

통합 테스트 시나리오는 개발된 시스템의 데이터 및 업무기능이 정상적으로 수행되는지를 테스트하기 위한 시나리오이다.
요구사항 정의중 기능적 요구사항을 정의하는 유스케이스 목록 및 유스케이스 모델(다이어그램/정의서), 요구사항 정의서의 사용자 인터페이스 요구사항, 요구사항 정의서의 기타 요구사항을 바탕으로 통합 테스트 시나리오를 작성한다.

  1. 작성기준
    1. 미작성시 영향
  • 다양한 비지니스 특성을 포함한 신시스템의 업무 처리 흐름에 따라 기능이 구현 되었는지 검증하기 어렵다.
  • 단위업무간 처리흐름을 거친 데이터의 정확성을 검증하기 어렵다.
  • 테스트시나리오가 없으면 테스트를 통해 발견된 에러를 재현하기가 어렵다. 따라서 초기 결함이 발견된 순서대로 테스트를 재수행할 수 없으므로 결함이 수정된 후에도 이를 확신할 수 없다.
  • 기능적 요구사항의 충족여부를 평가하기 어렵다.
    1. 작성이 불필요한 경우

통합테스트시나리오는 반드시 작성하도록 한다.

    1. 제출시 고려사항

N/A

  1. 작성항목
    1. 업무명
  • 업무명을 입력한다. 프로젝트 내의 공통과 관련된 부분에는 "공통"이라고 지정한다.
    1. 작성자/작성일
  • 작성내용이 명확하지 않은 경우 작성자에게 작성내용의 의미를 확인하고, 작성내용에 대한 작성일을 확인하기 위한 목적으로 작성자와 작성일을 기재한다.
    1. 테스트수행자(완료일자)
  • 테스트수행자의 성명을 입력하고 결함수정, 재테스트를 포함하는 테스트 완료일을 입력한다.
    1. 테스트 프로세스 – 테스트 케이스명
  • 테스트 대상이 되는 유스케이스명을 입력한다.
  • 테스트 케이스가 여러 유스케이스를 모아 테스트set으로 만들어 질 경우에는 프로젝트 별 프로젝트 표준의 테스트 케이스ID 부여방법을 마련하여 테스트 케이스 ID를 지정하도록 한다.
  • 만약 유스케이스별로 테스트 케이스를 만들지 않고 테스트 set만을 작성할 경우에는, 테스트케이스 ID의 하단에 요구사항 ID 혹은 유스케이스 ID를 차례로 입력하도록 한다.
    1. 테스트 프로세스 – 단계별 작업수행 내용
  • 해당 시나리오를 테스트할 수 있도록, 단계별로 작업을 수행하는 내용을 상세하게 입력하도록 한다.
  • 입력되는 내용은 유스케이스 정의서의 Flow of event를 참조하여 작성하도록 하며, 만약 시나리오가 작성 되어 있을 경우 시나리오의 내용을 사용하도록 한다.

여러 Test case를 테스트set으로 Test case를 만들 경우에는 "요구사항 ID"만 입력한다.

  • Use case별 Test case를 만들지 않고, 여러 Use case의 테스트Set 만으로 Test case를 만든 경우에는 수행 내용을 상세하게 작성하도록 한다.
    1. 테스트 프로세스 – 테스트 데이터
  • 테스트를 수행하기 위한 입력값을 지정한다. 각 필드에 입력 범위를 지정하거나, 특정 값을 지정하도록 한다.
    1. 예상결과
  • 예상되는 테스트 결과를 입력한다.

정상적인(Positive) 처리에 대한 결과와 비 정상적인(Negative) 처리에 대한 결과를 "V" 표시로check하며, check만으로 표시가 불가능할 경우에는 "기타 수행결과"에 값을 입력하도록 한다.
프로젝트 내에서 공통적으로 필요한 check 내용이 있을 경우 내용을 정의하여 사용하도록 한다.
시나리오를 작성할 경우에는 예상 결과까지만 작성하도록 한다.

    1. 테스트결과, 결과상세설명, 보완여부 및 비고
  • 테스트 수행 후 작성한다.
  1. 작성시 고려사항
  • 액티비티 다이어그램(TO-BE)의 업무흐름 참조한다.
  • 유스케이스 정의서의 시나리오흐름을 참조한다.
  • 요구사항정의서의 모든 기능을 테스트 시나리오로 작성한다.
  • 사용자 인터페이스와 관련된 부분이 포함 되었는지 확인한다.
  1. 관련기법(Related Technique)

테스트 기법(OO/CBD)