26
테트 지니 교육 - 테트 기본교육 - 테트

사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

Embed Size (px)

Citation preview

Page 1: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

테스트 엔지니어 교육- 테스트 기본교육

- 테스트

Page 2: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

테스트

1. 테스터도 알아야 할 웹 개발 기본

ContentsContentsContentsContents

※ 빌드 실습 - 스프링 프레임워크 어플리케이션

2. 애자일과 애자일 테스트

3. 사용자 스토리 기반의 테스트 설계 가이드

4. 개발 표준의 필요성 및 빈발결함

5. 테스트 자동화 환경(Jenkins) 구축 실습

(별도) 엑셀 검사시트 사용법

Page 3: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

테스트 교육

3. 테스트 설계 가이드(사례)

Page 4: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

� 테스트 설계의 목적

테스트 설계 = 테스트 케이스 도출

- 테스트 케이스의 정의

. 특정 프로그램 경로의 실행, 구체적인 요구사항과의 일치 여부 확인을 위해 디자인된 입력 값의 묶음,

실행 사전조건, 기대 결과(Expected Result)와 실행 사후조건의 집합

. 테스트 실행을 가능하게 하는 관련 정보나 실체(Entity)의 집합

- 테스트 케이스의 목적

. 요구되는 보장성을 갖는 최소한의(최적의) 테스트 케이스로 가능한 많은 결함을 발견할 수 있는 방법

. 테스트 대상을 가능한 범위에서 빠짐없이 테스트(수행)하여 일정수준의 테스트 보장성(Coverage)을

확보

3.1 테스트 설계

Page 5: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

� 테스트 설계 절차

3.1 테스트 설계

테테테테

스스스스

트트트트

설설설설

계계계계

테테테테

스스스스

트트트트

설설설설

계계계계

Test Basis

Test Condition Test Condition

Test Case

Test Case

Test Case

Test Procedure

Test Procedure

고객, 분석/설계자, 개발자 문의

기본/상세설계서

Test Condition?

Test Case?

Test Procedure

다양한 Input

Test Condition

Test Case?

Test Procedure

테스트 절차를기술

이론 실제

Page 6: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

� 상세 절차

3.1 테스트 설계

테스트 대상파악

목록 작성

공통 테스트케이스 도출

추가 테스트케이스 도출

리뷰

상세 스텝 작성

수행 내용 상세 내용

테스트 대상 파악 입력물인 기본(상세)설계서 로부터 해당 스프린트 테스트 대상을 파악한다

목록 작성파악한 테스트 대상 정보를 “유스케이스-화면-스토리” 수준으로정리하여 스프린트 테스트 셋 문서의 목록을 작성한다

공통 테스트케이스 도출

화면 또는 스토리 단위로 “정상”, “UI”, “입력값 유효성 체크” 의 공통 케이스를 도출하고 각각의 테스트 포인트를 간략 기술한다

추가 테스트케이스 도출

입력물로부터 공통 테스트 케이스 외에 추가로 테스트가 필요한 케이스를도출하고 각각에 대한 테스트 포인트를 기술한다

리뷰개발자, 검수자와 해당 내용을 리뷰하여 명확히 하고, 추가로 테스트 케이스를 도출한다

상세 스텝 작성도출한 각 케이스에 대해 상세 스텝(예상결과, 테스트 데이터 등 포함)을 기술한다

Page 7: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

1) 테스트 대상 파악, 2) 목록 작성

- 입력 산출물로부터 해당 스프린트의 테스트 대상을 정의한다

- 유스케이스 – 사용자 스토리 – 화면 정보를 테스트 케이스 셋의 목록 워크시트에 정리한다

제품 백로그

기본(상세) 설계서

유스케이스 – 사용자 스토리 – 화면 정보

테스트 케이스전체 목록

스프린트테스트 케이스 셋

Page 8: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

[ 흐름을 도식으로 표현하여 관련자와 확인 ]

※ 테스트를 위해 분석한 내용은 테스트 설계/수행 전에 개발자, 분석/설계자, 고객과 리뷰하고 피드백

을 최대한 반영한다

※ 분석한 내용을 도식화하는 것은 공유를 잘하기 위한 좋은 수단이 된다

Page 9: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

샘플 - 1) 테스트 대상 파악, 2) 목록 작성

- 3개의 유스 케이스 – 6개의 사용자 스토리로부터 7개 화면 구성으로 목록을 작성 함

상세업무상세업무상세업무상세업무/유스케이스명유스케이스명유스케이스명유스케이스명

사용자스토리사용자스토리사용자스토리사용자스토리ID 화면명화면명화면명화면명

장비이력관리 (기본내역)US-DH-001,US-DH-002

Special Mode History Master

장비정보관리US-DM-001,US-DM-002

장비정보관리 조회

장비정보관리US-DM-001,US-DM-002

Location 조회

장비정보관리US-DM-001,US-DM-002

장비정보관리 추가/수정

장비정보관리US-DM-001,US-DM-002

Location 추가/수정

장비정보관리US-DM-001,US-DM-002

Equipment 추가/수정

모니터링US-MO-001,US-MO-002

장비 모니터링

구분구분구분구분사용자스토리사용자스토리사용자스토리사용자스토리

IDEPIC 사용자사용자사용자사용자 스토리스토리스토리스토리

기능 US-DH-001 장비이력관리 (기본내역)정산센터 운영자는, 장비 정보 이력 현황을 조회 할 수 있다

기능 US-DH-002 장비이력관리 (기본내역)정산센터 운영자는, 장비의 상태별 이력현황을 조회 할 수 있다

기능 US-DM-001 장비정보관리정산센터는, 장비의 상태를 정의하고 관리할 수 있다

기능 US-DM-002 장비정보관리정산센터는, 장비와 관련된 정보를 정의하고 관리할 수 있다

기능 US-MO-001 모니터링

정산센터 운영자는, 실시간으로 아이템에 상태 변화에 대한 모니터링을 할 수

있다

기능 US-MO-002 모니터링

정산센터는, 외부로부터 수신된 데이터를 기반으로 아이템의 상태를 업데이트할 수 있다

Page 10: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

※ (참고) 애자일에서의 테스트 정의 방식 - (Given-When-Then)

애자일

BDD(Behavior Driven Development)

인수 테스트(Acceptance Testing)

사용자 요건 관점 중요시

테스트를 표현(접근)하는 방식

Given : 어떤 컨텍스트에서,

When : 특정 액션이 수행될 때,

Then : 기대되는 결과

Given my bank account is in credit, and I made no withdrawals recently, When I attempt to withdraw an amount less than my card's limit, Then the withdrawal should complete without errors or warnings

http://guide.agilealliance.org/guide/gwt.html

테스트를 고민할 때의 좋은 사고 방식

Page 11: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

샘플 – (참고)

- 여러 개의 스프린트 – 스프린트 통합(클린업 스프린트) 테스트 범위 정의

장비운영/유지보수

Special mode조회

장비정보관리

Service Provider조회

Location 조회

Metro Line조회

Bus Stop 조회

Equipment조회

Service Provider추가/수정

Metro추가/수정

Metro Line추가/수정

Bus Stop 추가/수정

Equipment추가/수정

Location

검색

장비모니터링

Bus추가/수정

[ XXX 스프린트 - 화면간 관계 ]

메뉴

조회조건 구분 : Service Provider인 경우

조회조건 구분 : Location인 경우

조회조건 구분 : Metro Line인 경우

조회조건 구분 : Bus Stop인 경우

조회조건 구분 : Equipment인 경우

조회조건 구분 : 검색 팝업 클릭

추가 / 수정 /탭 이동 추가 / 수정 /탭 이동 추가 / 수정 /탭 이동 추가 / 수정 /탭 이동 추가 / 수정 /탭 이동

Location이전철역인 경우

Location이버스 정류장인 경우

SP4

SP1 SP2 SP3

Page 12: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

기본설계서:: 화면 레이아웃

A 화면- 가 기능 (Major 기능)- 나 기능 (Major 기능)- 다 기능 (Minor 기능)

정상

UI

유효성

가 기능 수행

다 기능 수행

정상 나 기능 수행

TC 1

TC 2

TC 3

TC 4

Step 1

Step 2

Step 1

※ Major 기능 : 해당 화면의 주 의도한 기능, DB와의Transaction이 발생하는 기능 등※ Minor 기능 : 단순 초기화 버튼, 화면 이동 등UI단에서만 이벤트가 발생하며 화면의 주요 의도와는큰 관계가 없는 기능 등

3) 공통 테스트 케이스 도출

- 기본설계서의 [화면 레이아웃] 으로부터 주요/부가 기능을 식별하고 각 화면 또는 스토

리 단위로 일반적인 테스트와 UI를 점검하는 테스트 케이스, 입력값의 유효성을 체크하는

반복되는 테스트 케이스를 도출한다

사례

Page 13: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

샘플 - 3) 공통 테스트 케이스 도출

상세업무/유스케이스명

사용자스토리ID

화면명 테스트케이스셋 명 테스트케이스명

장비정보관리US-DM-001US-DM-002

장비정보관리 조회 장비정보관리 목록조회Service Provider 장비정보관리 목록조회_정상

장비정보관리US-DM-001US-DM-002

장비정보관리 조회 장비정보관리 목록조회Service Provider 장비정보관리 목록조회_UI

장비정보관리US-DM-001US-DM-002

장비정보관리 조회 장비정보관리 목록조회Service Provider 장비정보관리 목록조회_입력값유효성체크

장비정보관리US-DM-001US-DM-002

장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 프린트

장비정보관리US-DM-001US-DM-002

장비정보관리 조회 장비정보관리 목록조회Service Provider 장비정보관리 엑셀Export

단순한 기능, 단순 화면 이동 기능 들은 스텝으로 처리

별도로 처리가가능하며주요 기능인 경우각각 별도 테스트케이스로 처리

정상 가 기능 수행

다 기능 수행

정상 나 기능 수행

TC 1

TC 2

Step 1

Step 2

Step 1

도출

도출

사례

Page 14: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

샘플 - 3) 공통 테스트 케이스 도출

상세업무/유스케이스명

사용자스토리ID

화면명 테스트케이스셋 명 테스트케이스명

장비정보관리US-DM-001US-DM-002

장비정보관리 조회 장비정보관리 목록조회Service Provider 장비정보관리 목록조회_정상

장비정보관리US-DM-001US-DM-002

장비정보관리 조회 장비정보관리 목록조회Service Provider 장비정보관리 목록조회_UI

장비정보관리US-DM-001US-DM-002

장비정보관리 조회 장비정보관리 목록조회Service Provider 장비정보관리 목록조회_입력값유효성체크

장비정보관리US-DM-001US-DM-002

장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 프린트

장비정보관리US-DM-001US-DM-002

장비정보관리 조회 장비정보관리 목록조회Service Provider 장비정보관리 엑셀Export

각 UI 컴포넌트들의 이상유무, 메시지 처리, 사용자의 사용성을 고려한 처리를 체크

UI

입력값 유효성

TC 3

TC 4

필수입력 체크, 각 데이터 형에 대한 유효성 체크코드 값 체크 등이 정상적으로 처리되는지를 확인

도출

도출

사례

Page 15: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

4) 추가 테스트 케이스 도출

- 기본설계서의 [화면 레이아웃, 데이터 구성항목, 처리 이벤트 상세내역] 등으로부터 별

도로 확인해야 하는 사항에 대해 추가 테스트 케이스로 구성한다

기존에 존재하는Service Provider명 등록 시도

TC 5

도출

사례

Page 16: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

4) 추가 테스트 케이스 도출

a) 별도의 분기가 발생하고 이에 따라 예상결과가 다른 경우 별도의 케이스로 작성한다

b) 하나의 화면(사용자 스토리) 안에서 주요 기능을 순차적으로 수행하는 경우 추가 케이

스로 분리

분기정상정상 UI 유효성

스탭1

조건

스탭2 스탭1

스탭1

스탭2

UI 유효성 정상2정상

스탭1

스탭2

스탭1

스탭1

UI 유효성

TC 1 TC 2 TC 3 TC 1 TC 2 TC 3 TC 1 TC 2 TC 3 TC 4TC 4

별도의 분기, 기능이 없는 경우- UI, 입력값 유효성 체크 케이스 작성

a) 분기 흐름이 존재하는 경우- 분기 케이스를 별도로 작성

b) 분리된 기능, 흐름이 존재하는 경우- 명시적으로 케이스를 분리

사례

Page 17: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

샘플 - 4) 추가 테스트 케이스 도출

a) 별도의 분기가 발생하고 이에 따라 예상결과가 다른 경우 별도의 케이스로 작성한다

b) 하나의 화면(or 사용자 스토리) 안에서 주요 기능을 순차적으로 수행하는 경우 추가 케

이스로 분리

화면명 테스트케이스셋 명 테스트케이스명

Service Provider 조회

Service Provider 조회

Service Provider 조회_정상

Service Provider 조회_UI

Service Provider 조회_프린트

Service Provider 조회_엑셀 export

Service Provider 삭제Service Provider 삭제_정상

Service Provider 삭제_하위Location존재건삭제

화면명 테스트케이스셋 명 테스트케이스명

Service Provider 조회 Service Provider 삭제Service Provider 삭제_정상

Service Provider 삭제_하위Location존재건삭제

TC 1) 정상 삭제 테스트 케이스TC 2) 하위 데이터가 존재하는 건의 삭제 시도 케이스

TC 1~4) 조회를 수행하는 테스트 케이스TC 5~6) 조회 수행 후 조회된 건을 삭제하는

테스트 케이스

사례

Page 18: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

테스트 케이스 셋

업무구분 파라미터 관리 정상인

상세업무/유스케이스명

사용자스토리ID

화면명테스트케이스셋

명테스트케이스명 테스트케이스 요약 설계자 SP1 SP1

장비정보관리US-DM-001US-DM-002

Service Provider 조회

Service Provider 조회

Service Provider 조회_정상

Service Provider 조회_UI

Service Provider 조회_프린트

Service Provider 조회_엑셀 export

Service Provider 삭제

Service Provider 삭제_정상

Service Provider 삭제_하위Location존재건삭제

케이스케이스케이스케이스1개개개개 : UI 비교 체크 케이스케이스케이스케이스0개개개개or1개개개개 : 각각각각 기능기능기능기능 수행수행수행수행 시시시시 데이터데이터데이터데이터 항목항목항목항목 을을을을 정의한정의한정의한정의한 후후후후

해당해당해당해당 기능기능기능기능 케이스에서케이스에서케이스에서케이스에서 참조하여참조하여참조하여참조하여 체크하도록체크하도록체크하도록체크하도록 가이드가이드가이드가이드

화면레이아웃

데이터 정의 처리 이벤트상세내역케이스케이스케이스케이스n개개개개 :

- 기본기본기본기본 흐름흐름흐름흐름, - 대안흐름대안흐름대안흐름대안흐름,- 예외예외예외예외 흐름흐름흐름흐름등을등을등을등을 고민하여고민하여고민하여고민하여 도출도출도출도출

입력값입력값입력값입력값 유효성유효성유효성유효성 체크체크체크체크

� 테스트 케이스 도출 전체 설명

- 대상이 화면 인 경우

사례

Page 19: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

테스트 케이스 셋

업무구분 파라미터 관리 정상인

상세업무/유스케이스명

사용자스토리ID

화면명테스트케이스셋

명테스트케이스명 테스트케이스 요약 설계자 SP1 SP1

장비정보관리US-DM-001US-DM-002

Service Provider 조회

사용자 스토리 A

사용자 스토리 A_정상

사용자 스토리 A_UI

사용자 스토리 A_프린트

사용자 스토리 A_엑셀 export

사용자 스토리 B사용자 스토리 B_정상

사용자 스토리 B_하위Location존재건삭제

� 테스트 케이스 도출 전체 설명

- 대상이 스토리인 경우

케이스케이스케이스케이스1개개개개 : UI 비교 체크 케이스케이스케이스케이스0개개개개or1개개개개 : 각각각각 기능기능기능기능 수행수행수행수행 시시시시 데이터데이터데이터데이터 항목항목항목항목 을을을을 정의한정의한정의한정의한 후후후후

해당해당해당해당 기능기능기능기능 케이스에서케이스에서케이스에서케이스에서 참조하여참조하여참조하여참조하여 체크하도록체크하도록체크하도록체크하도록 가이드가이드가이드가이드

화면레이아웃

데이터 정의 처리 이벤트상세내역케이스케이스케이스케이스n개개개개 :

- 기본기본기본기본 흐름흐름흐름흐름, - 대안흐름대안흐름대안흐름대안흐름,- 예외예외예외예외 흐름흐름흐름흐름등을등을등을등을 고민하여고민하여고민하여고민하여 도출도출도출도출

입력값입력값입력값입력값 유효성유효성유효성유효성 체크체크체크체크

사례

Page 20: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

5) 초안 리뷰

- 테스트 케이스만을 미리 도출한 후 내용이 맞는지, 빠뜨린 테스트 케이스는 없는지 이해

관계자와 리뷰를 수행한다

- 테스트 케이스는 가급적 개발 시작 전에 설계하여 요건을 명확히 하고 개발을 시작한다

- 테스트 케이스를 통해 개발이 제대로 되었는지 보장할 수 있다

분석/설계자 SBE 셀 리더개발자

테스트 엔지니어

테스트 설계 초안 작성 리뷰- 각 테스트 케이스 도출- 도출한 케이스 공유 및 확인- 추가 케이스 도출

테스트 설계 초안 제공

테스트 설계보완 후 리뷰

개발자

Page 21: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

사례 - 5) 초안 리뷰

XXX 시스템 스프린트 1 수행 사례

- 수행 방법 : 화면 별로 a)개발자 설명, b) TE 질의, c) 기타 추가 케이스 도출 및 문서 정리를 각 5분씩,

총 15분 이내로 수행

- 수행 내용 : 개발자 3명 화면 8개에 대해 리뷰 수행

- 수행 결과 :

1) 각 화면의 컬럼 영역 클릭시 정렬 기능이 적용되어야 하는 사항 공유

2) 파라미터 목록 화면을 제외한 다른 화면에서의 기본(디폴트) 정렬 조건 확인

(파라미터 상세조회의 내역(최근 등록순?), 카드 블랙 리스트의 항목 등)

3) 메시지/버튼명 등에 대한 통일, 다국어 지원 현재는 미적용 내용 공유

4) 스프린트 1에서 엑셀, 인쇄 기능 미구현 확인 필요

5) 각 화면별 필수입력 필드 표시 미정의, 필수 입력(배포 그룹명 등) 에 대한 Trim 처리 확인 필요

6) [파라미터 조회] 조회 건을 클릭시 기본이 "상세조회 화면" 이나

상태가 '임시저장'인 경우 해당 임시저장 화면으로 이동해야 하는 요건 확인 필요

7) [파라미터 생성] 첨부 파일에 대한 최대 크기, 파일 종류가 정해지 있지 않은지 확인 필요(파일은 1개로 확인)

8) [파라미터 생성] Activate Date, Deactivate Date에 대해 적용 시작일이 오늘, 현재 시간 이후인지 요건 확인 필요

9) [파라미터 배포] 배포중 부분 실패 발생 시 기 성공한 배포 건도 모두 원상 복구 하는지 확인 필요

10) [배포 그룹 생성] 그룹 명에 기존 이름과 동일한 이름으로 등록 가능한지 확인 필요

사례

Page 22: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

6) 상세 스텝 작성

- 확인 된 테스트 케이스에 대해 해당 테스트 케이스 수행을 위한 상세 스텝을 작성한다

- 하나의 기능 수행이 복잡한 절차에 의해 수행되는 경우

- 현재 테스트 케이스가 다른 테스트 케이스에 재사용되는 부분이 있는 경우

- 단순한 기능의 확인

- 기존 테스트 케이스의 스텝을 재사용하여 간단하게 기술이 가능한 경우

※ 여러 개의 스텝으로 하나의 테스트 케이스를 구성하는 경우

※ 한 개의 스텝으로 하나의 테스트 케이스를 구성하는 경우

Page 23: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

테스트케이스 ID 테스트케이스명순번

스텝(step) 예상결과

sptcs_conf_06_01 파라미터 배포_정상 01 배포할 정보를 선택한다[필수입력]1단계: DistributionGroupId 복수선택 가능2단계: ServiceProviderId 복수 선택 가능,3단계: LocatioId 복수 선택 가능[선택입력]Parameter type, parameter status, synchronized

. 필수 입력이 선택되지 않으면 메시지가표시된다. 선택 입력은 디폴트가 "전체" 로 선택되어 있다

sptcs_conf_06_01 파라미터 배포_정상 02 조회를 수행한다 Synch 안 된 건의 경우 "배포" 버튼이 표시되어 조회된다

sptcs_conf_06_01 파라미터 배포_정상 03 [다건 배포]배포 버튼이 활성화된 건을 선택(체크)한다하단 선택 배포 버튼으로 배포 한다[단건 배포]각 건의 배포 버튼을 선택해서 배포한다

샘플 - 6) 상세 스텝 작성

배포 기능정상 수행

테스트 케이스

배포 기능 수행을 위한 정보 입력

배포 기능 수행을 위한 배포 대상 조회

조회된 건에 대한 배포 기능 수행

테스트케이스 ID 테스트케이스명순번

스텝(step) 예상결과

sptcs_conf_06_05

파라미터 배포_일부배포가실패한경우의처리

01 [파라미터 배포_정상] 스텝 01~03 수행에서 다건의 배포 수행시 배포 수행 중 부분 실패가 발생하면 기존 성공한 배포도 모두 원상 복구를 하는지 확인한다

부분 실패가 발생하면 기존 성공한 배포도 모두 원상 복구되고 수동배포 버튼이 다시 표시된다

sptcs_conf_07_02

배포그룹 생성_UI 01 화면정의서와 동일하게 표시되는지 확인한다전체 선택 체크리스트가 각 항목에 존재하는지확인한다최종 생성 여부를 묻는 알림창이 표시되는지 확인한다

※ 여러 개의 스텝으로 하나의 테스트 케이스를 구성하는 경우

※ 한 개의 스텝으로 하나의 테스트 케이스를 구성하는 경우

간단한UI 체크

테스트 케이스

배포 수행 중 일부 건 배포가 실패한 경우예상 결과대로 수행되는지 확인

기존 스텝 재사용한테스트 케이스

UI에 대해 화면 정의서 일치여부,메시지 처리 등을 테스트

사례

Page 24: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

워크시트 항목명 설명 및 네이밍 룰 입력 여부 작성 예

[목록]상세업무/

유스케이스명해당 테스트 시나리오가 속한 상세업무 또는 유스케이스명 필수 “장비정보관리”

[목록] 사용자 스토리 ID “US-DM-001,US-DM-002”

[목록] 화면명 “Service Provider 조회”[목록],

[테스트케이스 셋]테스트케이스셋 ID

대상 유스케이스에 대응하는 테스트 케이스 셋 IDTCS_{상세업무약자 or 유스케이스ID}_숫자 seq

필수 “TCS_EINFOMGM_001”

[목록],[테스트케이스 셋]

테스트케이스셋 명 대상 유스케이스에 대응하는 테스트 케이스 셋 명 필수 “Service Provider 조회”

[목록],[테스트케이스 셋]

테스트케이스 ID 테스트 케이스 ID{테스트시나리오ID}_{세자리seq:테스트 대상}_{두자리seq}

필수 “TCS_EINFOMGM_001_01”

[목록],[테스트케이스 셋] 테스트케이스명 {테스트 대상 기능명} _ {테스트방식(정상,UI,validation,예외 등)} 필수 “Service Provider 조회_정상”

[목록] 테스트케이스 요약 해당 테스트 케이스가 테스트하려는 바를 간략하게 설명한다 필수[목록] 관련 요구사항ID 테스트 케이스, 시나리오의 추적성 확보를 위한 요구사항 ID 필수 아님 삭제 예정[목록] 관련 요구사항명 관련 요구사항 명 필수 아님 삭제 예정[목록] 시나리오 설계자 테스트 시나리오 작성자 필수 “A 테스트 엔지니어”

[테스트케이스 셋] 상세업무 테스트 대상이 속한 상세업무명 필수 아님 “장비 관리”[테스트케이스 셋] 서브메뉴 테스트 대상을 찾을 수 있는 메뉴 또는 자바 패키지 정보 필수 아님 “장비운영/유지보수”[테스트케이스 셋] 대상프로그램ID 테스트 대상의 물리 ID 필수 아님[테스트케이스 셋] 대상프로그램명 테스트 대상의 이름 필수 아님[테스트케이스 셋] 순번 해당 테스트 케이스 내에서 수행되는 스텝의 seq(두자리) 필수[테스트케이스 셋] 스텝 해당 테스트 케이스 내에서 수행되는 스텝 기술 필수[테스트케이스 셋] 예상결과 각 테스트 스텝의 예상결과 필수

[테스트케이스 셋] 테스트데이터 각 테스트 스텝에 사용되는 테스트 데이터특정 테스트 데이터, 요건이 있는 경우

필수로 입력

[테스트케이스 셋] 선행조건 및 시나리오 각 테스트 스텝, 케이스에 필요한 선행조건 명시특정 사전 단계, 요건이 있는 경우 필

수로 입력[테스트케이스 셋] 수행스프린트 테스트 결과를 입력할 때 수행한 테스트 스프린트 또는 차수 필수[테스트케이스 셋] 일시 테스트 수행 일시 필수[테스트케이스 셋] 테스터 테스트 수행한 테스터 필수[테스트케이스 셋] 결과 테스트 결과 (Pass, Fail, Block) 필수[테스트케이스 셋] 비고 테스트 결과에 따른 결함ID 또는 Block 사유 등 기록 필수

작성 항목별 설명

사례

Page 25: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

※ (참조) 테스트 케이스 재사용

- 각 흐름 별로 ‘기본’ 케이스 등을 명시하고 다른 테스트 케이스에서 참조하거나,

통합 테스트와 같은 상위레벨 시나리오에서 참조한다

스텝 2

배포형태

스텝 3

스텝 1

스텝 1

스탭2

스탭1

테스트케이스명 순번 스텝(step)

파라미터 생성_기본

01 . 화면이 표시되면 배포 그룹(Distribution group)을 선택한다. 파라미터 타입에 SW 파라미터 타입 5자리 중 첫째자리가 1로 시작하고 2,3째 자리가 02인 파라미터가 표시되고 선택한다

파라미터 생성_기본

02 . Version number를 입력한다. 적용 시작 일자를 입력한다

파라미터 생성_기본

03 . 필수 입력인 파일 첨부를 선택한다. 신규 생성한다

테스트케이스명 순번 스텝(step)

파라미터 생성_배포형태가Instant인경우

01 . [파라미터 생성_기본]의 스텝 01~02를 수행한다.적용 해제 일자를 입력한다

. [파라미터 생성_기본]의 스텝 03을 수행한다

TC 1:배포 형태가일반(Normal)인 경우

TC 2:배포 형태가Instant인 경우

스탭2

Normal

재사용

재사용

Page 26: 사용자 스토리 대상 테스트 설계 사례(테스트기본교육 3장 3절)

3.1 테스트 설계

※ (참조) 테스트 데이터 참조 값 사용

- 특정 테스트 데이터가 여러 곳에서 반복 사용되고, 잦은 변경이 예상되거나,

상세 항목이 많은 경우 별도 ‘테스트 데이터’ 워크시트에서 테스트 데이터를 정의하고

이를 ID 형태로 참조하여 테스트 케이스에 표시한다

TC 1:

TC 2:

TC 5:

[ 테스트 데이터 ](사용자정보_기본_001). 이름 : ~. 아이디 : ~ . 나이 : ~성별 : ~

변경되어도 한군데만 현행화