Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,583 views

Published on

상업적 이용 및 출처를 밝히지 않는 무단 전재를 금합니다.
테스트 케이스 설계에 대한 부분

Published in: Software
  • Be the first to comment

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

  1. 1. 테스트 엔지니어 교육 - 테스트 기본교육 - 테스트
  2. 2. 테스트 1. 테스터도 알아야 할 웹 개발 기본 ContentsContentsContentsContents ※ 빌드 실습 - 스프링 프레임워크 어플리케이션 2. 애자일과 애자일 테스트 3. 사용자 스토리 기반의 테스트 설계 가이드 4. 개발 표준의 필요성 및 빈발결함 5. 테스트 자동화 환경(Jenkins) 구축 실습 (별도) 엑셀 검사시트 사용법
  3. 3. 테스트 교육 3. 테스트 설계 가이드(사례)
  4. 4. 테스트 설계의 목적 테스트 설계 = 테스트 케이스 도출 - 테스트 케이스의 정의 . 특정 프로그램 경로의 실행, 구체적인 요구사항과의 일치 여부 확인을 위해 디자인된 입력 값의 묶음, 실행 사전조건, 기대 결과(Expected Result)와 실행 사후조건의 집합 . 테스트 실행을 가능하게 하는 관련 정보나 실체(Entity)의 집합 - 테스트 케이스의 목적 . 요구되는 보장성을 갖는 최소한의(최적의) 테스트 케이스로 가능한 많은 결함을 발견할 수 있는 방법 . 테스트 대상을 가능한 범위에서 빠짐없이 테스트(수행)하여 일정수준의 테스트 보장성(Coverage)을 확보 3.1 테스트 설계
  5. 5. 테스트 설계 절차 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 테스트 절차를 기술 이론 실제
  6. 6. 상세 절차 3.1 테스트 설계 테스트 대상 파악 목록 작성 공통 테스트 케이스 도출 추가 테스트 케이스 도출 리뷰 상세 스텝 작성 수행 내용 상세 내용 테스트 대상 파악 입력물인 기본(상세)설계서 로부터 해당 스프린트 테스트 대상을 파악한다 목록 작성 파악한 테스트 대상 정보를 “유스케이스-화면-스토리” 수준으로 정리하여 스프린트 테스트 셋 문서의 목록을 작성한다 공통 테스트 케이스 도출 화면 또는 스토리 단위로 “정상”, “UI”, “입력값 유효성 체크” 의 공통 케이스 를 도출하고 각각의 테스트 포인트를 간략 기술한다 추가 테스트 케이스 도출 입력물로부터 공통 테스트 케이스 외에 추가로 테스트가 필요한 케이스를 도출하고 각각에 대한 테스트 포인트를 기술한다 리뷰 개발자, 검수자와 해당 내용을 리뷰하여 명확히 하고, 추가로 테스트 케이스 를 도출한다 상세 스텝 작성 도출한 각 케이스에 대해 상세 스텝(예상결과, 테스트 데이터 등 포함)을 기 술한다
  7. 7. 3.1 테스트 설계 1) 테스트 대상 파악, 2) 목록 작성 - 입력 산출물로부터 해당 스프린트의 테스트 대상을 정의한다 - 유스케이스 – 사용자 스토리 – 화면 정보를 테스트 케이스 셋의 목록 워크시트에 정리한다 제품 백로그 기본(상세) 설계서 유스케이스 – 사용자 스토리 – 화면 정보 테스트 케이스 전체 목록 스프린트 테스트 케이스 셋
  8. 8. 3.1 테스트 설계 [ 흐름을 도식으로 표현하여 관련자와 확인 ] ※ 테스트를 위해 분석한 내용은 테스트 설계/수행 전에 개발자, 분석/설계자, 고객과 리뷰하고 피드백 을 최대한 반영한다 ※ 분석한 내용을 도식화하는 것은 공유를 잘하기 위한 좋은 수단이 된다
  9. 9. 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 장비 모니터링 구분구분구분구분 사용자스토리사용자스토리사용자스토리사용자스토리 ID EPIC 사용자사용자사용자사용자 스토리스토리스토리스토리 기능 US-DH-001 장비이력관리 (기본내역) 정산센터 운영자는, 장비 정보 이력 현황 을 조회 할 수 있다 기능 US-DH-002 장비이력관리 (기본내역) 정산센터 운영자는, 장비의 상태별 이력 현황을 조회 할 수 있다 기능 US-DM-001 장비정보관리 정산센터는, 장비의 상태를 정의하고 관 리할 수 있다 기능 US-DM-002 장비정보관리 정산센터는, 장비와 관련된 정보를 정의 하고 관리할 수 있다 기능 US-MO-001 모니터링 정산센터 운영자는, 실시간으로 아이템 에 상태 변화에 대한 모니터링을 할 수 있다 기능 US-MO-002 모니터링 정산센터는, 외부로부터 수신된 데이터 를 기반으로 아이템의 상태를 업데이트 할 수 있다
  10. 10. 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 테스트를 고민할 때의 좋은 사고 방식
  11. 11. 3.1 테스트 설계 샘플 – (참고) - 여러 개의 스프린트 – 스프린트 통합(클린업 스프린트) 테스트 범위 정의 장비운영/유지보수 Special mode 조회 장비정보 관리 Service Provider 조회 Location 조회 Metro Line 조회 Bus Stop 조회 Equipment 조회 Service Provider 추가/수정 Metro 추가/수정 Metro Line 추가/수정 Bus Stop 추가/수정 Equipment 추가/수정 Locatio n 검색 장비 모니터링 Bus 추가/수정 [ XXX 스프린트 - 화면간 관계 ] 메뉴 조회조건 구분 : Service Provider인 경우 조회조건 구분 : Location인 경우 조회조건 구분 : Metro Line인 경우 조회조건 구분 : Bus Stop인 경우 조회조건 구분 : Equipment인 경우 조회조건 구분 : 검색 팝업 클릭 추가 / 수정 /탭 이동 추가 / 수정 /탭 이동 추가 / 수정 /탭 이동 추가 / 수정 /탭 이동 추가 / 수정 /탭 이동 Location이 전철역인 경우 Location이 버스 정류장인 경우 SP4 SP1 SP2 SP3
  12. 12. 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를 점검하는 테스트 케이스, 입력값의 유효성을 체크하는 반복되는 테스트 케이스를 도출한다 사례
  13. 13. 3.1 테스트 설계 샘플 - 3) 공통 테스트 케이스 도출 상세업무/ 유스케이스명 사용자스토리 ID 화면명 테스트케이스셋 명 테스트케이스명 장비정보관리 US-DM-001 US-DM-002 장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 목록조 회_정상 장비정보관리 US-DM-001 US-DM-002 장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 목록조 회_UI 장비정보관리 US-DM-001 US-DM-002 장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 목록조 회_입력값유효성체크 장비정보관리 US-DM-001 US-DM-002 장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 프린트 장비정보관리 US-DM-001 US-DM-002 장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 엑셀 Export 단순한 기능, 단순 화면 이동 기능 들은 스텝으로 처리 별도로 처리가 가능하며 주요 기능인 경우 각각 별도 테스트 케이스로 처리 정상 가 기능 수행 다 기능 수행 정상 나 기능 수행 TC 1 TC 2 Step 1 Step 2 Step 1 도출 도출 사례
  14. 14. 3.1 테스트 설계 샘플 - 3) 공통 테스트 케이스 도출 상세업무/ 유스케이스명 사용자스토리 ID 화면명 테스트케이스셋 명 테스트케이스명 장비정보관리 US-DM-001 US-DM-002 장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 목록조 회_정상 장비정보관리 US-DM-001 US-DM-002 장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 목록조 회_UI 장비정보관리 US-DM-001 US-DM-002 장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 목록조 회_입력값유효성체크 장비정보관리 US-DM-001 US-DM-002 장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 프린트 장비정보관리 US-DM-001 US-DM-002 장비정보관리 조회 장비정보관리 목록조회 Service Provider 장비정보관리 엑셀 Export 각 UI 컴포넌트들의 이상유무, 메시지 처리, 사용자의 사용성을 고려한 처리를 체크 UI 입력값 유효성 TC 3 TC 4 필수입력 체크, 각 데이터 형에 대한 유효성 체크 코드 값 체크 등이 정상적으로 처리되는지를 확인 도출 도출 사례
  15. 15. 3.1 테스트 설계 4) 추가 테스트 케이스 도출 - 기본설계서의 [화면 레이아웃, 데이터 구성항목, 처리 이벤트 상세내역] 등으로부터 별 도로 확인해야 하는 사항에 대해 추가 테스트 케이스로 구성한다 기존에 존재하는 Service Provider명 등록 시도 TC 5 도출 사례
  16. 16. 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) 분리된 기능, 흐름이 존재하는 경우 - 명시적으로 케이스를 분리 사례
  17. 17. 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) 조회 수행 후 조회된 건을 삭제하는 테스트 케이스 사례
  18. 18. 3.1 테스트 설계 테스트 케이스 셋 업무구분 파라미터 관리 정상인 상세업무/ 유스케이스명 사용자스토 리 ID 화면명 테스트케이스셋 명 테스트케이스명 테스트케이스 요약 설계자 SP1 SP1 장비정보관리 US-DM-001 US-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개개개개 : - 기본기본기본기본 흐름흐름흐름흐름, - 대안흐름대안흐름대안흐름대안흐름, - 예외예외예외예외 흐름흐름흐름흐름 등을등을등을등을 고민하여고민하여고민하여고민하여 도출도출도출도출 입력값입력값입력값입력값 유효성유효성유효성유효성 체크체크체크체크 테스트 케이스 도출 전체 설명 - 대상이 화면 인 경우 사례
  19. 19. 3.1 테스트 설계 테스트 케이스 셋 업무구분 파라미터 관리 정상인 상세업무/ 유스케이스명 사용자스토 리 ID 화면명 테스트케이스셋 명 테스트케이스명 테스트케이스 요약 설계자 SP1 SP1 장비정보관리 US-DM-001 US-DM-002 Service Provider 조회 사용자 스토리 A 사용자 스토리 A_정상 사용자 스토리 A_UI 사용자 스토리 A_프린트 사용자 스토리 A_엑셀 export 사용자 스토리 B 사용자 스토리 B_정상 사용자 스토리 B_하위Location존재건삭 제 테스트 케이스 도출 전체 설명 - 대상이 스토리인 경우 케이스케이스케이스케이스1개개개개 : UI 비교 체크 케이스케이스케이스케이스0개개개개or1개개개개 : 각각각각 기능기능기능기능 수행수행수행수행 시시시시 데이터데이터데이터데이터 항목항목항목항목 을을을을 정의한정의한정의한정의한 후후후후 해당해당해당해당 기능기능기능기능 케이스에서케이스에서케이스에서케이스에서 참조하여참조하여참조하여참조하여 체크하도록체크하도록체크하도록체크하도록 가이드가이드가이드가이드 화면 레이아웃 데이터 정의 처리 이벤트 상세내역케이스케이스케이스케이스n개개개개 : - 기본기본기본기본 흐름흐름흐름흐름, - 대안흐름대안흐름대안흐름대안흐름, - 예외예외예외예외 흐름흐름흐름흐름 등을등을등을등을 고민하여고민하여고민하여고민하여 도출도출도출도출 입력값입력값입력값입력값 유효성유효성유효성유효성 체크체크체크체크 사례
  20. 20. 3.1 테스트 설계 5) 초안 리뷰 - 테스트 케이스만을 미리 도출한 후 내용이 맞는지, 빠뜨린 테스트 케이스는 없는지 이해 관계자와 리뷰를 수행한다 - 테스트 케이스는 가급적 개발 시작 전에 설계하여 요건을 명확히 하고 개발을 시작한다 - 테스트 케이스를 통해 개발이 제대로 되었는지 보장할 수 있다 분석/설계자 SBE 셀 리더 개발자 테스트 엔지니어 테스트 설계 초안 작성 리뷰 - 각 테스트 케이스 도출 - 도출한 케이스 공유 및 확인 - 추가 케이스 도출 테스트 설계 초안 제공 테스트 설계 보완 후 리뷰 개발자
  21. 21. 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) [배포 그룹 생성] 그룹 명에 기존 이름과 동일한 이름으로 등록 가능한지 확인 필요 사례
  22. 22. 3.1 테스트 설계 6) 상세 스텝 작성 - 확인 된 테스트 케이스에 대해 해당 테스트 케이스 수행을 위한 상세 스텝을 작성한다 - 하나의 기능 수행이 복잡한 절차에 의해 수행되는 경우 - 현재 테스트 케이스가 다른 테스트 케이스에 재사용되는 부분이 있는 경우 - 단순한 기능의 확인 - 기존 테스트 케이스의 스텝을 재사용하여 간단하게 기술이 가능한 경우 ※ 여러 개의 스텝으로 하나의 테스트 케이스를 구성하는 경우 ※ 한 개의 스텝으로 하나의 테스트 케이스를 구성하는 경우
  23. 23. 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_0 5 파라미터 배포_일부배 포가실패한경우의처리 01 [파라미터 배포_정상] 스텝 01~03 수행에서 다 건의 배포 수행시 배포 수행 중 부분 실패가 발 생하면 기존 성공한 배포도 모두 원상 복구를 하 는지 확인한다 부분 실패가 발생하면 기존 성공 한 배포도 모두 원상 복구되고 수 동배포 버튼이 다시 표시된다 sptcs_conf_07_0 2 배포그룹 생성_UI 01 화면정의서와 동일하게 표시되는지 확인한다 전체 선택 체크리스트가 각 항목에 존재하는지 확인한다 최종 생성 여부를 묻는 알림창이 표시되는지 확 인한다 ※ 여러 개의 스텝으로 하나의 테스트 케이스를 구성하는 경우 ※ 한 개의 스텝으로 하나의 테스트 케이스를 구성하는 경우 간단한 UI 체크 테스트 케이스 배포 수행 중 일부 건 배포가 실패한 경우 예상 결과대로 수행되는지 확인 기존 스텝 재사용한 테스트 케이스 UI에 대해 화면 정의서 일치여부, 메시지 처리 등을 테스트 사례
  24. 24. 3.1 테스트 설계 워크시트 항목명 설명 및 네이밍 룰 입력 여부 작성 예 [목록] 상세업무/ 유스케이스명 해당 테스트 시나리오가 속한 상세업무 또는 유스케이스명 필수 “장비정보관리” [목록] 사용자 스토리 ID “US-DM-001, US-DM-002” [목록] 화면명 “Service Provider 조회” [목록], [테스트케이스 셋] 테스트케이스셋 ID 대상 유스케이스에 대응하는 테스트 케이스 셋 ID TCS_{상세업무약자 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 사유 등 기록 필수 작성 항목별 설명 사례
  25. 25. 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 재사용 재사용
  26. 26. 3.1 테스트 설계 ※ (참조) 테스트 데이터 참조 값 사용 - 특정 테스트 데이터가 여러 곳에서 반복 사용되고, 잦은 변경이 예상되거나, 상세 항목이 많은 경우 별도 ‘테스트 데이터’ 워크시트에서 테스트 데이터를 정의하고 이를 ID 형태로 참조하여 테스트 케이스에 표시한다 TC 1: TC 2: TC 5: [ 테스트 데이터 ] (사용자정보_기본 _001) . 이름 : ~ . 아이디 : ~ . 나이 : ~ 성별 : ~ 변경되어도 한군데만 현행화

×