테스트 설계 및 구현 프로세스(Test design & implementation process) - 테스트 설계 진행 방식은 테스트 조직 구성, 테스팅과 개발 프로세스의 성숙도, 시간적 제약, 참여 인원등 테스팅 정황에 따라 달라짐 1. 테스트 조건(Test Condition) - 테스트 분석 과정에서 무엇을 테스트할지 결정하기 위해(테스트 조건을 식별하기 위해) 테스트 베이시스를 분석함 - 테스트 조건은 하나 이상의 테스트 케이스로 확인 가능한 항목 또는 이벤트 - 예: 기능, 트랜잭션, 품질 특성, 구조적 요소 등 2. 테스트 설계 과정 - 테스트 설계 기법을 이용하여 테스트 케이스와 테스트 데이터를 설계하고 명세화 함 1) 테스트 케이스 설계 - 테스트 케이스 목적: 목표하는 보장성을 만족하는 최소한의(최적의) 테스트 케이스로 가능한 많은 결함을 발견하는 것 - 테스트 대상을 가능함 빠짐없이 테스트하여 원하는 수준의 테스트 보장성(Coverage)을 확보할 수 있도록 테스트 케이스를 설계 - 테스트 케이스 구성요소: 입력값의 묶음, 실행 사전 조건, 수행 절차, 기대 결과, 실행 사후 조건으로 구성 (이외에도 테스트 케이스 ID, 테스트 케이스 명, 추적성, 중요도, 결과(합격/불합격) 등 다양한 내용이 포함될 수 있음) ID(식별번호)
테스트 케이스명
사전 조건(Pre-conditions)
테스트 수행 절차(Test Step)
기대 결과(필수 항목)
결과(합격/불합격)
추적성
중요도
비고
- 소프트웨어 테스트 문서 표준(IEEE 829)은 테스트 설계 명세(테스트 조건 포함)와 테스트 케이스 표준 양식 제시 3. 테스트 구현 단계 1) 우선순위 선정, 배치 - 테스트 프로시저 명세서(Test procedure specification)를 만듦 - 테스트 프로시저(또는 수동 테스트 스크립트): 효율적인 테스트를 위한 테스트 케이스 실행 순서 - 테스트 실행 도구를 사용하여 테스트를 수행한다면 테스트 프로시저는 테스트 스크립트(또는 자동화된 테스트 프로시저)로 기술 2) 테스트 실행 스케줄 구성 - 작성된 테스트 프로시저와 자동화된 테스트 스크립트를 언제 누가 수행할 것인지에 대해 구성 - 리그레션 테스트 여부, 우선순위, 기술적/논리적 종속 관계 등을 고려하여 결정 3) 테스트 케이스 작성 - 테스트 수행 절차를 얼마나 상세하게 작성할지를 결정해야 함 - 테스트 케이스를 실행할 테스터의 스킬, 능력, 해당 시스템에 대한 이해 등을 고려하여 테스트 케이스의 상세함 정도를 조정함 - 공식적인 기법으로 먼저 작성 후 경험 기반의 비공식적인 기법으로 보완함(두 기법이 발견할 수 있는 결함의 종류가 다르기 때문) 테스트 전략 - 소프트웨어가 요구사항을 기반으로 구현되었는지 여부에 따라 테스트 전략이 달라짐 1. 요구사항에 명시되어 있으나 구현되지 않은 경우 - 요구사항을 기반으로 테스트 케이스를 작성해 실행해야 함 2. 요구사항대로 구현되었으나 때에 따라 정상동작하지 않는 경우 - 요구사항을 기반으로 테스트 케이스를 작성해 실행하고 추가적인 테스트 케이스를 수행(네거티브 테스트 포함) 3. 요구사항에 명시되어 있지 않지만 구현된 경우 - 요구사항 기반의 테스트로 해당 결함을 발견하기 어려우므로 비공식적인 테스트(탐색적 테스팅을 사용할 수 있음)를 추가적으로 실행 - 결함을 발견하기 위해 실제 구현된 부분을 반영하여 요구사항을 변경해야 함 4. 요구사항에 명시되어 있지 않지만 구현되었으며, 정상동작하지 않는 경우 - 요구사항 기반의 테스트로 결함을 발견하기 어려우므로 비공식적인 테스트(탐색적 테스팅을 사용할 수 있음)를 추가적으로 실행 - 기대결과를 알기 어려우므로 요구사항을 기반으로 보다 체계적이고 강도 높게 비공식적인 테스트를 설계, 실행함 목 차 1. 테스트 프로세스 2. 테스트 케이스 작성절차 3. 테스트 케이스 구성요소 4. 테스트 케이스 작성 시 장점/주의점 5. 테스트 케이스 정렬 방법 1. 테스트 프로세스 테스트 프로세스는 테스팅과 관련된 다양한 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 테스팅의 모든 구성 요소를 엮어주는 역할을 한다. 1) 테스트 프로세스 5단계 테스트 프로세스는 계획/제어, 분석/설계, 구현/실행, 완료/리포팅과 마감의 5단계로 구성.
 1-1) 계획과 제어 테스트 계획 수립은 테스트 목표와 임무를 달성하기 위해 이를 확인하고 필요한 활동을 정의하며, 테스트 제어는 게획 대비 실제 진행 상활을 비교하는 지속적인 활동 1-2) 분석과 설계 테스트 분석과 설계는 일반적이고 추상적인 테스트 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동. 1-3) 구현과 실행 테스트 구현과 실행은 가장 효율적이고 효과적으로 테스트를 실행하기 위하여 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시저를 명세화하는 활동 1-4) 완료조건과 리포팅 초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가하는 활동 1-5) 테스트 마감 완료된 테스트 활동에서 데이트를 수집하여, 테스트에서 발견된 사실 및 데이터, 경험을 종합하고 축적하는 활동 어떠한 프로젝트 수행시 대부분 테스트 프로세스 3단계 ‘구현/실행’, 과 4단계 ‘완료/리포팅’ 단계를 집중적으로 반복 수행하게 된다. 3, 4 단계에서는 테스트 케이스 실행, 개선, 결과 검토 등을 수행한다. 2. 테스트 케이스 작성절차
2-1) 참조 문서 수집 테스트 계획서에 명시된 테스트 케이스 작성지침과 수준을 고려하여 테스트 설계에 필요 한 분석 및 설계문서를 수집한다. 2-2) 테스트 케이스 작성 테스트 설계 기법을 이용하여 테스트케이스 작성한다. 2-3) 내부 검토 PM, 아키텍처, 디자이너, 기획자, 개발자와 테스트 담당자가 작성된 테스트케이스의 적정성을 검토한다.(상황에 따라 내부 검토자는 변경될 수 있음) 2-4) 요구사항 대비 커버리지 분석 테스트 케이스가 어느 정도 요구사항을 반영하는가에 대한 분석. 기본적으로 테스트 가능한 요구사항은 모두 테스트케이스에 반영이 되었는지 확인한다. 2-5) 승인 작성된 테스트 케이스를 고객(현업), 기획자 및 PM에게 승인을 획득한다. 3. 테스트 케이스 구성요소
테스트 케이스는 조직에 따라 변경되거나 추가/삭제 될 수 있다. 4. 테스트 케이스 작성 시 장점/주의점 4-1 테스트 케이스 작성시 실수 테스트 구성요소가 있어도 테스트 케이스 작성시 아래와 같은 실수를 많이 하게 된다. ▶ 절차의 누락 급하게 테스트케이스 작성 시 테스트 절차를 정확하게 입력하지 않아서 테스트를 수행하 는데 어려움이 생김 ▶ 너무 장황한 설명 테스트 케이스 작성 시 상세하고 충분한 정보를 제공하여야 하지만, 너무 많은 단어와 불필요한 설명으로 인하여 테스트를 수행하는데 어려움이 생길 수 있음 ▶ 많은 전문용어 사용 테스트 케이스 작성 시 약어나, 코드이름, 줄임말 등을 많이 사용하면, 다른 사람이 수행 을 하는데 어려움이 있을 수 있음 ▶ 분명하지 않은 Pass/Fail 기준 테스트 수행 후 테스트 결과가 통과인지 실패인지 예상결과에 정확히 기입하지 않아, Pass/Fail을 기입 할 수 없음. 4-2 테스트 케이스 작성시 장점 ▶ 이력참조 테스트 케이스는 웹 애플리케이션 런칭 후에도 사용, 유지보수 팀과 나중에 웹 애플리케 이션 버전을 담당하는 담당자가 무슨 내용의 테스트를 어떻게 수행 했는지 확인 가능 ▶ 테스트 진행 상황 추적 테스트 케이스를 문서화 하면 수행한 테스트 케이스 수, 통과와 실패 테스트 케이스 수, 특정 범위 별 테스트 케이스 수, 수행한 테스트 커버리지 등의 추가적인 정보를 추적 및 확인 가능 ▶ 반복성 잘 작성된 테스트 케이스는 누구나 반복적으로 수행할 수 있음 4-3 테스트 케이스 작성시 단점 ▶ 작성기간 테스트 케이스 작성 시간이 수행시간 보다 오래 걸릴 수 있음, 하나의 환경에서 몇 번만 수행되고 말 테스트라면 테스트 케이스를 문서화할 필요가 없을 수도 있음, 그러나 외부 업체 경우에는 작성 시간이 오래 걸리더라도 꼭 작성해야 함. ▶ 기능 변경에 따른 테스트 케이스 변경 기능을 자주 변경한다면 테스트 케이스를 작성하는 시간이 점점 늘어나서 나중에는 통제 할 수 없게 됨, 웹 애플리케이션에서 자주 일어나는 상황이며, 기능 변경이 자주 되는 경 우에는 PM, 기획자 등과 협의가 필요함. ▶ 배경 지식 판단의 어려움 테스트 케이스를 작성하는 사람은 테스트하는 기능을 잘 알고 있으므로 전문용어를 사용 하지만, 실제 수행자는 전문 용어를 이해하지 못해, 테스트 수행 시간이 길어지거나 수행 에 어려움이 있을 수 있음. 5. 테스트 케이스 정렬 방법 5-1 흐름이 이어지는 테스트케이스 정렬 테스트 케이스를 기능과 스펙 위주로 구현 하는 것에만 치중 하다 보면 놓치는 것 중의 하나가 테스트의 흐름이 없이 기능 테스트의 나열에 그치기 쉽다는 것이다. 하지만 간단한 테스트 케이스 정렬 만으로도 테스트 케이스에 뚜렷한 흐름이 생겨서 테스트의 진행을 쉽게 할 수 있다.
▶ SRS나 기획 문서, 디자인 문서가 TCL의 기초가 되는데 이러한 기본 문서의 내용을 하나 하나 구현한 것이 왼쪽의 리스트이며, 흐름에 맞도록 정렬한 것이 오른쪽의 리스트이다. 실행 – 동작 – 기능 – 결과의 흐름으로 테스트가 이어지도록한다. ▶ 흐름이 이어지는 케이스 정렬의 효과는 테스트가 자연스럽게 이어지며 테스트 세팅을 바꾸거나 이것 했다가 저것 했다가 하지 않고 일관적인 페이스로 나갈 수 있어서 테스트 가 수월 하게 진행 됨. 하지만 상황에 따라서는 이전 테스트의 환경을 이어받는지 이어받지 않는지 확실하게 구분 해야 함 5-2 테스트 환경이 비슷한 것끼리 정렬 테스트를 할 때 고유의 환경이 필요한 경우가 있다. SRS의 구현 위주로 테스트 케이스를 작성 하다 보면 이 세팅으로 테스트 하다가 다른 세팅으로 바꿔서 테스트 하는 테스트 환 경 세팅의 변경이 잦을 수 있는데 테스트 환경이 비슷한 것을 모을 경우 테스트 환경세팅 변경의 시간이 줄어들므로 전체적인 테스트 완료시간이 줄어든다.
▶ 위에서 보면 왼쪽의 테스트 케이스를 테스트 하려면 관리자(Root)유저로 테스트 했다가 사용자(User)계정으로 테스트하고 로그아웃 후 로그인 등의 쓸모 없이 낭비되는 환경 설 정 변경의 시간이 소모된다. 이러한 잘못된 설정의 변경 상태는 기능 위주로 스펙을 테 스트 케이스로 옮길 때 자주 발생 하며, 환경위주로 테스트 케이스을 조절 하면 테스트 진행에 많은 시간을 감소 할 수 있다. ▶ 테스트를 위해서 테스트 세팅이 오래 걸리는 제품일수록 테스트 환경이 비슷한 것끼리 의 정렬은 매우 중요함. 테스트를 진행 하는 것 보다 테스트 세팅에 시간이 매우 오래 걸린다면 테스터가 집중하기 힘들고 시간의 소모가 많기 때문이다. ▶ 단, 경우에 따라 왼쪽 리스트 자체가 로그인, 로그아웃 반복 테스트가 될 수 있음 이론적인 부분만 작성하여 딱딱했으리라 생각이 듭니다. 차후 리포트에서는 실제 SDET에서 작성하고 있는 TestCase 토대로 리포트 작성하도록 하겠습니다. 인용 자료 및 참고 문헌 - Test Basic Knowledge Book. - TCL 재조정으로 인한 테스트 속도향상 기법(최철호) - 개발자도 알아야할 소프트웨어 테스팅 실무
|
테스트 시나리오 ID - teseuteu sinalio ID
관련 게시물
저작권 © 2024 moicapnhap Inc.
