후보 테스트 스위트 점검
목적:
|
테스트 스위트를 이해하고 구현될 후보를 선택
|
기존의 테스트 스위트 개요를 검토하여 시작하고 어떤 테스트 스위트가 현재 시간에 구현하기에 좋은 후보인지 결정하십시오. 반복 테스트 계획, 테스트 아이디어 목록 및 모든 추가 테스트 정의 중간 산출물을 결정을 위한
기초로 사용하십시오.
|
관련 테스트 테스트 대상 항목 점검
목적:
|
계획된 테스트와 테스트 대상 항목 사이의 관계 이해
|
구현을 위해 선택한 각 테스트 스위트에 대해 테스트 스위트의 범위에 포함시킬 후보가 어떤 테스트 대상 항목 및 연관된 테스트인지 식별하십시오.
|
테스트 종속성 식별
목적:
|
테스트가 다른 테스트의 항목 및 시스템 상태와 관련하여 일반 항목으로 갖는 모든 종속성 식별
|
테스트 환경 구성 및 특정 시스템 시작 상태를 고려하여 시작하십시오. 종속 데이터베이스에 대한 시작 데이터 세트와 같이 특정한 설정 요구사항이 있는지 고려하십시오. 하나의 대상 환경 구성이 다양한 테스트 스위트에
사용되는 경우, 비디오 디스플레이의 화면 해상도 또는 지역적 운영 체제 설정과 같이 각 테스트 스위트에 대해 관리해야 하는 모든 구성 설정을 식별하십시오.
이제 테스트 사이의 모든 특정 관계를 판별하십시오. 테스트 스위트에 포함된 한 테스트를 실행하면 다른 테스트의 전제 조건으로 필요한 시스템 상태 변경이 발생하는 종속성을 찾으십시오.
관련 종속성을 식별한 후에는 종속 테스트에 대한 올바른 실행 순서를 결정하십시오.
|
재사용 기회 식별
목적:
|
기존 자산을 재사용하고 새 자산을 통합하여 테스트 스위트 유지보수 용이성 개선
|
테스트 스위트(특히 자동화된 테스트 스위트) 유지보수의 주된 도전 중 하나는 계속적 변경을 작성하기 쉽도록 하는 것입니다. 가능하고 유용할 경우 여러 곳에서 사용되는 요소에 대한 중앙 수정 위치를 유지보수하는 것이
좋습니다. 특히 동일한 요소들이 변경될 수 있는 경우에 유용합니다.
테스트 자체가 모듈 방식의 자연스런 단위를 형성하는 한편, 테스트를 테스트 스위트로 어셈블하면 종종 통합되는 경우에 훨씬 효율적으로 유지보수할 수 있는 여러 테스트 사이에 중복되는 절차 요소를 식별할 수 있습니다.
계속적 유지보수를 지원하기 위해 잠재적으로 표준 루틴에 다시 포함될 수 있는 테스트의 모든 일반적인 기술을 식별하십시오.
|
필요한 하부 구조 유틸리티 적용
목적:
|
테스트 지원에서 필요한 복잡한 구현 세부사항을 단순화된 유틸리티 기능으로 분리
|
대부분의 테스트 노력에서 테스트 실행 중에 사용되는 정보를 생성, 수집, 진단, 변환 및 비교하는 하나 이상의 "유틸리티"를 사용해야 합니다. 이러한 유틸리티는 대개 수동으로 수행하는 경우 오류를 생성하기 쉬운
복잡하고 어려운 타스크를 단순화합니다. 이 단계는 테스트 스위트 내에서 기존 유틸리티 기능의 적용 및 필요한 새 유틸리티의 식별과 관련됩니다.
가능한 많은 복잡도를 유틸리티의 개인용 구현 안에 포함시켜서 이러한 유틸리티에 대한 인터페이스를 단순화하는 것이 좋습니다. 또한 수동 및 자동화된 테스트 노력 모두에 대해 필요한 경우 다시 사용할 수 있는 방식으로
유틸리티를 개발하는 것이 좋습니다.
이러한 유틸리티 안에 개별 테스트를 특징짓는 정보를 숨기지 않는 것이 좋습니다. 대신 유틸리티를 정보 수집 또는 실제 값을 예상 결과와 비교하는 복잡한 역학으로 제한하지만 가능한 경우 각 개별 테스트의 특정 특성을
제어 테스트 또는 테스트 스위트의 입력으로 전달(및 개별 실제 결과를 출력으로 리턴)하십시오.
|
복구 요구사항 결정
목적:
|
테스트 스위트의 완전한 재실행을 요구하지 않고 테스트 스위트가 복구되도록 함
|
테스트 스위트가 실행 중에 실패하는 경우 테스트 스위트 내에서 복구를 제공할 적당한 위치를 결정하십시오. 이 단계는 테스트 스위트가 많은 수의 테스트를 포함하거나 장시간 동안(때로는 자동으로) 실행하는 경우에
중요합니다. 거의 대부분 자동화된 테스트 스위트에 대한 요구사항으로 식별되지만, 수동으로 실행되는 테스트 스위트에 대한 복구 위치도 고려해야 합니다.
복구 또는 다시 시작 위치 외에, 자동화된 테스트 스위트 복구를 고려할 수 있습니다(자동화된 테스트 스위트의 경우). 자동 복구를 위한 두 가지 접근 방식은 1) 기존 테스트 스위트가 해당 테스트 중 하나에서
발생하는 사소한 오류에서 자체 복구할 수 있는 기본 복구로서, 일반적으로 테스트 스위트의 다음 테스트에서 실행을 복구하며, 2) 필요한 경우 운영 체제 다시 시동 및 데이터 복원을 포함하여 적당한 시스템 상태를
재설정하여 실패한 테스트 후에 정리하는 고급 복구가 있습니다. 첫 번째 접근 방식에서와 같이 테스트 스위트가 실패한 테스트를 판별하고 실행할 다음 테스트를 선택합니다.
|
복구 요구사항 구현
목적:
|
복구 프로세스가 필요한 대로 작동하도록 구현하고 확인
|
필요한 정교함의 레벨에 따라서 복구 처리를 구현하고 안정화하려는 노력이 필요합니다. 복구 처리 작업을 증명하기 위해 발생 가능성이 있는 많은 실패(및 거의 발생 가능성이 없는 몇몇 실패)를 시뮬레이트할 시간을
투자해야 합니다.
자동 복구의 경우, 이전 단계에서 요약된 접근 방식이 둘 다 장단점을 갖고 있습니다. 초기 개발뿐 아니라 계속적 유지보수 노력의 항목으로 정교한 자동 복구의 비용을 주의깊게 고려해야 합니다. 때로는 수동 복구로
충분합니다.
|
테스트 스위트 안정화
목적:
|
시스템 상태 및 테스트 실행 순서의 항목 모두에서 모든 종속성 문제점을 해결
|
가능하면 하나 이상의 시험 테스트 실행으로 테스트 스위트를 안전화하는 시간을 가져야 합니다. 안정성을 달성하지 못하면 테스트 스위트의 복잡도가 비례하여 증가하고, 그 경우 관련되지 않은 테스트 사이에는 과다하게
밀접한 결합이, 관련된 테스트 사이에는 낮은 응집력이 존재합니다.
개별 테스트를 독립적으로 실행할 때는 오류가 발생하지 않지만, 주어진 테스트 스위트 내에서 테스트를 함께 실행할 경우에는 오류가 발생할 수 있습니다. 이러한 오류는 보통 추적하고 진단하기가 가장 어려우며, 특히
자동화된 테스트가 실행되는 기간의 중간에서 발생할 때 아주 어렵습니다. 가능한 경우 추가 테스트를 추가하면서 정기적으로 테스트 스위트를 다시 실행하는 것이 좋은 방법입니다. 그러면 문제점을 식별하기 위해 진단할
소수의 잠재적 후보 테스트를 분리하는 데 도움이 됩니다.
|
추적성 관계 유지보수
목적:
|
추적된 항목에 대한 영향 분석 및 평가 보고를 수행할 수 있게 합니다.
|
테스트 계획에서 요약되는 추적성 요구사항을 사용하여 필요한 대로 추적성 요구사항을 갱신하십시오. 정의된 테스트 케이스 또는 테스트 아이디어까지 테스트 스위트를 추적할 수 있습니다. 선택적으로 유스 케이스,
소프트웨어 스펙 요소, 구현 모델 요소 및 하나 이상의 테스트 적용 범위 척도까지 추적할 수 있습니다.
|
결과 평가 및 확인
목적:
|
타스크가 적절히 완료되었는지 및 그에 따른 중간 산출물이 허용 가능한지 확인합니다.
|
작업을 완료했으므로 작업이 충분한 가치가 있었는지, 방대한 양의 종이만 소비한 것이 아닌지 확인하는 것이 좋습니다. 작업 품질이 적합한지 여부 및 차후에 이를 작업의 입력으로 사용할 해당 팀 구성원에게 유용할
정도로 완전한지를 평가해야 합니다. 가능하면 RUP에 제공된 체크리스트를 사용하여 품질 및 완성도가 "충분"한지 확인하십시오.
다운스트림 타스크 수행 시 해당 작업을 입력으로 사용할 인원들이 중간 작업 검토에 참여하도록 하십시오. 이들의 관심사항을 다루는 조치를 취할 시간 여유가 있으면 이를 수행하십시오. 또한 작업을 주요 입력 중간
산출물과 비교 평가하여 이를 정확하고 충분하게 표시했는지 확인해야 합니다. 입력 중간 산출물 작성자가 이를 기반으로 작업을 검토하도록 하는 것이 유용할 수 있습니다.
RUP는 반복적 전달 프로세스이며 중간 산출물은 시간이 경과하면서 발전하는 경우가 많다는 사실을 기억하십시오. 그러므로 부분적으로만 사용되거나 직후 작업에서 전혀 사용되지 않을 중간 산출물을 완전히 형식화하는 것은
거의 불필요합니다(또한 보통 비생산적임). 이는 중간 산출물이 사용되기 전에 중간 산출물을 둘러싼 상황이 변경되고 중간 산출물이 작성되었을 때의 가정이 잘못되었다고 증명되어 결과적으로 노력이 수포가 되고 비용을
들여 다시 작업해야 하는 가능성이 높기 때문입니다. 또한 프리젠테이션 주기가 너무 많아 컨텐츠 가치가 손상되는 함정에 빠지지 않도록 하십시오. 프리젠테이션이 프로젝트 인도물로서 중요성과 경제적 가치를 지니는
프로젝트 환경에서는 관리 자원을 사용하여 프리젠테이션 타스크를 수행할 수 있습니다.
|
|