타스크: 테스트 구현 구조화
이 타스크는 테스트 스위트 구현의 전체 구조 정의 방법을 설명합니다.
목적

이 타스크의 목적은 다음과 같습니다.

  • 테스트 스위트 구현이 상주하는 구조 작성
  • 테스트 스위트 구현 영역 및 해당 컨텐츠에 책임 지정
  • 필수 테스트 스위트 아웃라인
관계
단계
테스트 접근 방식, 테스트 대상 항목 및 평가 요구 점검
목적:  테스트가 평가되는 방법과 특정 테스트 스위트가 테스트 대상 항목을 평가하기 위해 구현하는 방법 이해 

테스트 계획 평가 필요 여부 검토를 시작으로 명시된 테스트 접근 방식을 사용하여 테스트 연장 및 소프트웨어 품질 평가 결정 방법을 고려하십시오. 특정 테스트 대상 항목과 연관되어 처리해야 하는 모든 특수한 요구도 고려하십시오.

테스트 용이성 메커니즘 및 지원 요소 점검
목적:  사용 가능한 테스트 용이성 요소 이해 및 지원되는 메커니즘 및 이점 이해 

이런 환경에서 테스트를 사용하는데 유용한 메커니즘을 검토하고 해당 메커니즘을 구현하는 특정 테스트 용이성 요소를 식별하십시오. 여기에는 테스트 팀에서 개발하느 모든 기능 라이브러리 및 개발 팀에서 구현하는 스텁 또는 하니스와 같은 자원 검토가 포함됩니다.

테스트 용이성은 테스트 가능한 소프트웨어 개발과 테스트를 올바로 지원하는 테스트 접근 방식 정의를 조합하여 달성합니다. 이와 같이 테스트 용이성은 소프트웨어 개발 노력의 중요한 파트이기 때문에 테스트 팀 자산 개발의 중요한 요소입니다. 테스트 용이성의 달성은(소프트웨어 제품을 효율적으로 테스트하는 기능) 일반적으로 다음 조합에 연관됩니다.

  • 테스트 자동화 도구에서 제공되는 테스트 용이성 인에이블러
  • 컴포넌트 테스트 스크립트를 작성하는 특정 기법
  • 테스트 스크립트의 기본 테스트 절차 정의의 복잡도를 분리하고 캡슐화하는 기능 라이브러리로 제어 및 수정의 중앙 제어점을 제공합니다.

분배 요구사항 분석

현재 테스트 스위트에 분배할 요구사항이 있습니까? 있는 경우 분배를 지원하는 테스트 용이성 요소를 사용하십시오. 이 요소는 일반적으로 테스트 스위트를 분배하고 원격으로 실행하며 중앙 집중식 결과 판별을 위해 테스트 로그 및 기타 산출물을 작성하는 특정 자동 지원 도구로 수행됩니다.

동시성 요구사항 분석

현재 테스트 스위트에 기타 테스트 스위트와 동시에 수행되는 요구사항이 있습니까? 있는 경우 동시성을 지원하는 테스트 용이성 요소를 사용하십시오. 이 요소는 일반적으로 특정 지원 도구 및 다른 실제 시스템에서 동시에 실행되는 여러 테스트 스위트를 사용하도록 지원하는 유틸리티 기능의 조합입니다. 동시성에는 두 개의 동시 테스트로 동일한 데이터 레코드가 갱신되는 것과 같이 예상치 못하거나 계획하지 않은 부수적인 효과가 없도록 테스트 데이터 디자인 및 관리에 주의를 기울여야 합니다.

초기 테스트 스위트 구조 작성
목적:  구현할 테스트 스위트 아웃라인 

실행했을 때 테스트 팀에 완전하고 의미있는 결과를 제공하는 하나 이상의 테스트 스위트를 전개하여 이해 당사자(stakeholder)에게 후속 보고를 사용 가능하게 합니다. 프로젝트 팀에게 특정 정보에 대한 세부사항을 충분히 제공하되, 압도되어 관리할 수 없을 정도로 너무 세부적인 정보를 제공하지는 마십시오.

테스트 스크립트가 이미 있는 경우 테스트 스위트와 해당 구성 파트를 어셈블하고 테스트 스위트의 안정 작업을 테스트 스위트 구현자에게 전달하여 완료하도록 하십시오.

새 테스트 스크립트 작성이 필요한 테스트 스위트에 대해서 해당 테스트 스위트에서 참조될 수 있는 테스트 스크립트 또는 기타 테스트 스위트를 알려주어야 합니다. 열거하기 쉬운 경우에는 열거하십시오. 쉽지 않은 경우 기본 테스트 스위트의 예상 컨텐츠 적용 범위 개요를 보여주는 간단한 설명을 제공하고 테스트 스위트 구현자가 테스트 스크립트에 포함시킬 실제 내용을 결정하도록 하십시오.

테스트 스위트 구조를 수용하고 팀 조직 및 도구 제한조건을 반영하십시오.
목적:  테스트 스위트 구조를 정제하여 팀 책임 지정 작업을 수행 

팀에서 작업 중인 작업분류체계(WBS)를 수용하도록 식별한 테스트 스위트를 더 자세히 분류하거나 재구성하는 작업이 필요할 수도 있습니다. 이는 테스트 스위트 개발 중에 발생 가능한 액세스 충돌 위험성을 줄이는 데 도움이 됩니다. 어떤 경우에 테스트 자동화 도구는 자동화 자산에서 개별적으로 수행하는 작업 방법에 제한조건을 제시하여 필요에 따라 이를 수용하도록 테스트 스위트를 재구성합니다.

테스트 스크립트 간 통신 메커니즘 식별
목적:  테스트 스크립트에서 공유 또는 전달되는 테스트 데이터 및 시스템 상태를 식별 

대부분의 경우 테스트 스위트는 특정 순서로 단순히 테스트 스크립트를 호출합니다. 대부분의 경우 올바른 시스템 상태가 하나의 테스트 스크립트에서 다음으로 전달되었는지 이를 통해 확인할 수 있습니다.

그러나 특정 시스템 클래스에서 동적 런타임 데이터는 시스템에서 생성되거나 또는 시스템에서 수행된 트랜잭션 결과로 파생됩니다. 예를 들어 주문 입력 및 배송 시스템에서 주문이 입력될 때마다 고유 주문 번호가 시스템에서 생성됩니다. 자동화된 테스트 스크립트가 주문을 배송하도록 하려면 선행하는 주문 입력 테스트 스크립트는 시스템에서 생성된 고유 주문 번호를 캡처하고 이를 주문 배송 테스트 스크립트로 전달해야 합니다.

이런 경우 올바른 테스트 스크립트 간 통신 메커니즘을 고려해야 합니다. 일반적인 대안에는 전달된 매개변수, 디스크 파일의 읽기 및 쓰기 값과 글로벌 런타임 변수가 포함됩니다. 각 전략에는 각각의 특별한 상황에 적합한 장단점이 있습니다.

테스트 스위트 요소의 초기 종속성 정의
목적:  테스트 스위트 요소의 런타임 종속성 식별 및 정의 

이는 주로 테스트 스크립트의 시퀀스에 연관되고 또는 런타임으로 실행되는 테스트 스위트와도 연관될 수 있습니다. 작성 중인 올바른 종속성이 없이 실행되는 테스트는 실패하거나 예외적인 테이터를 보고하는 위험이 초래됩니다.

테스트 구현 아키텍처를 가시적으로 모델
목적:  테스트 구현이 실현되는 방법을 문서화 및 설명하기 위해 다이어그램 사용 

UML 모델링 또는 그림 도구에 액세스하는 경우 자동화된 테스트 소프트웨어의 주요 요소를 보여주는 테스트 구현 모델의 다이어그램을 작성할 수 있습니다. 비슷한 방식으로 테스트 자동화 아키텍처의 몇몇 주요 기능을 다이어그램으로 작성할 수 있습니다.

다른 접근 방식은 테스트 팀이 보기 쉽도록 화이트보드에 해당 다이어그램을 그리는 것입니다.

테스트 스위트 구조 정제
목적:  필요한 조정을 수행하여 테스트 구현의 무결성 유지 

프로젝트가 진행됨에 따라 테스트 스위트를 변경해야 할 수도 있습니다. 새 테스트 스크립트가 추가되고 기존의 테스트 스크립트는 갱신, 다시 정렬 또는 삭제됩니다. 이런 변경은 테스트 스위트 유지보수에 일반적인 부분으로 이를 적극 활용하는 것이 좋습니다.

테스트 스위트를 적극적으로 유지보수하지 않는 경우 잘못된 수행을 초래할 수 있습니다. 빌드가 적을 경우 테스트 스위트를 재생시키는 데는 막대한 노력이 들 수 있으므로 기존 테스트 스위트를 파기하고 새로 처음부터 작성하는 것이 좋습니다. 자동화된 테스트 스위트 유지보수에 대한 자세한 가이드라인은 이 페이지의 헤더 표에 있는 자세한 정보 섹션을 참조하십시오.

추적성 관계 유지보수
목적:  추적된 항목에 대한 영향 분석 및 평가 보고를 수행할 수 있게 합니다. 

테스트 계획에서 요약되는 추적성 요구사항을 사용하여 필요한 대로 추적성 요구사항을 갱신하십시오.

결과 평가 및 확인
목적:  타스크가 적절히 완료되었는지 및 그에 따른 중간 산출물이 허용 가능한지 확인 

작업을 완료했으므로 작업이 충분한 가치가 있었는지, 방대한 양의 종이만 소비한 것이 아닌지 확인하는 것이 좋습니다. 작업 품질이 적합한지 여부 및 차후에 이를 작업의 입력으로 사용할 해당 팀 구성원에게 유용할 정도로 완전한지를 평가해야 합니다. 가능하면 RUP에 제공된 체크리스트를 사용하여 품질 및 완성도가 "충분"한지 확인하십시오.

다운스트림 타스크 수행 시 해당 작업을 입력으로 사용할 인원들이 중간 작업 검토에 참여하도록 하십시오. 이들의 관심사항을 다루는 조치를 취할 시간 여유가 있으면 이를 수행하십시오. 또한 작업을 주요 입력 중간 산출물과 비교 평가하여 이를 정확하고 충분하게 표시했는지 확인해야 합니다. 입력 중간 산출물 작성자가 이를 기반으로 작업을 검토하도록 하는 것이 유용할 수 있습니다.

RUP는 반복적 전달 프로세스이며 중간 산출물은 시간이 경과하면서 발전하는 경우가 많다는 사실을 기억하십시오. 그러므로 부분적으로만 사용되거나 직후 작업에서 전혀 사용되지 않을 중간 산출물을 완전히 형식화하는 것은 거의 불필요합니다(또한 보통 비생산적임). 이는 중간 산출물이 사용되기 전에 중간 산출물을 둘러싼 상황이 변경되고 중간 산출물이 작성되었을 때의 가정이 잘못되었다고 증명되어 결과적으로 노력이 수포가 되고 비용을 들여 다시 작업해야 하는 가능성이 높기 때문입니다. 또한 프리젠테이션 주기가 너무 많아 컨텐츠 가치가 손상되는 함정에 빠지지 않도록 하십시오. 프리젠테이션이 프로젝트 인도물로서 중요성과 경제적 가치를 지니는 프로젝트 환경에서는 관리 자원을 사용하여 프리젠테이션 타스크를 수행할 수 있습니다.



특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보