타스크: 테스트 용이성 요소 정의
이 타스크는 테스트를 지원하고 사용하는 요소의 식별 방법에 대해 설명합니다.
원칙: 테스트
목적

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

  • 대상 테스트 항목을 지원하는 데 필요한 요소를 식별합니다.
  • 각 테스트 환경 구성에서 테스트를 사용하는 데 필요한 테스트 구현 하부 구조의 실제 요소를 식별합니다.
  • 소프트웨어가 실제적으로 테스트 가능하기 위해서 충족시켜야 할 소프트웨어 디자인 요구사항을 정의합니다.
관계
단계
각 필수 대상 테스트 항목의 경우 테스트 메커니즘을 사용하는 관계 식별
목적:  대상 테스트 항목에 필요한 테스트 메커니즘 지원에 대해 이해합니다.

각 대상 테스트 항목에 대해 테스트 메커니즘 목록을 검토하고 지원을 제공할 수 있는 테스트 메커니즘을 식별하십시오. 그런 다음 완전한 테스트 솔루션을 제공하도록 선택한 테스트 메커니즘을 닫는 방법과 선택한 테스트 메커니즘이 보다 적합해질 수 있도록 조절하는 방법을 분석하십시오. 후보를 찾을 수 없거나 조절 노력이 중요하지 않은 경우 새 테스트 메커니즘을 정의하고 특수성과 재사용성 간의 밸런스를 찾으십시오.

시스템의 동적 요소 및 이벤트 식별
목적:  시스템의 동적 측면과 런타임 측면에 대해 이해합니다.  

사용 가능한 소프트웨어 요구사항과 디자인 정보를 사용하여 동적 요소와 시스템 이벤트를 식별하십시오. 유스 케이스, 디자인, 구현 및 배치 모델을 사용하면 제어 클래스, 프로세스, 스레드 및 이벤트와 같은 관련 항목을 식별할 수 있습니다. 연구를 시작할 수 있는 위치에는 <<control>>로 스테레오타입화된 클래스, 유스 케이스 실현(realization), 프로세스 아키텍처 보기에 설명된 요소, <<process>> 또는 <<thread>>로 스테레오타입화된 구현 모델이 포함됩니다.

테스트 환경의 제한조건과 관련하여 물리적 요구사항을 정의하십시오.

시스템 경계 및 인터페이스 식별
목적:  서비스 제공자로서의 시스템의 권한과 클라이언트로서의 시스템의 종속성에 대해 이해합니다.  

검사할 또 다른 유용한 요소 그룹은 시스템의 인터페이스로서, 시스템 경계 밖에 있는 액터와 관련하여 가장 중요한 요소입니다. 디자인 및 구현 모델을 사용하여 <<interface>> 스테레오타입으로 정의된 요소를 찾으십시오. 또한 이 모델에서 <<boundary>>로 스테레오타입화된 클래스가 있는지도 검사하십시오.

관련 시스템(클라이언트 및 서비스 제공자 모두)의 예상을 이해하기 위해 이러한 시스템 경계를 벗어나서 탐색하는 것이 테스터에게 유용합니다. 그럴 경우 인터페이스 유효성 검증 관점과 이러한 인터페이스를 테스트하고 시뮬레이션(가능한 경우)하는 데 필요한 테스트 하부 구조의 관점에서 필요한 사항이 무엇인지를 보다 철저하게 파악할 수 있습니다.

테스트 하부 구조 요소 식별
목적:  필수 테스트 수행을 가능하게 할 테스트 노력의 필수 요소를 식별합니다.  

반복적인 테스트 노력이 성공하기 위해서는 적합한 하부 구조를 식별하고 유지보수하는 것이 중요합니다. 테스트 노력 유지보수를 지원하는 하부 구조가 없으면 테스트 노력이 단시간 내에 유지보수할 수 없게 되거나 사용 불가능해집니다. 테스트 하부 구조는 자동화된 테스트 노력과 보다 명백하게 관련이 있지만, 수동 테스트 노력의 중요한 사안이기도 합니다.

시스템의 동적 요소와 이벤트를 고려하십시오. 즉, 개별 테스트를 구현할 때 이들이 어떠한 종속성을 배치할지 고려하십시오. 개별 테스트 간의 종속성을 결합 해제하고 간접 계층을 제공하는 공통 제어 지점을 통해 이들을 관리할 수 있는 기회를 찾으십시오. 종속성을 탐색할 수 있는 공통 영역에는 테스트 탐색, 테스트 데이터 사용 및 시스템 상태 변경이 포함됩니다.

수집한 정보를 이용하여 테스트 하부 구조를 제어할 요구사항과 성공적인 테스트 접근 방식을 지원하기 위해 해당 하부 구조에서 제공해야 하는 기능을 고려하십시오.

하위 주제:

공통 테스트 시나리오 촉진 페이지 맨 위로

일부 테스트의 경우 실행될 때 공통된 시나리오 또는 프로시저 구조를 따릅니다. 그러나 여러 테스트 대상 항목과 대조하여 같은 프로시저를 여러 번 수행해야 합니다. 테스트 자동화의 경우에는 여러 컨텍스트에서 재사용할 수 있는 공통 테스트 스크립트나 유틸리티 기능을 작성하여 이러한 공통 테스트 시나리오를 효과적인 방법으로 시작하는 것이 유용할 수 있습니다. 이 방법은 테스트 시나리오를 변경해야 할 경우 중앙 수정 지점을 제공합니다. 인터페이스 요소의 적절한 클래스에서 표준 경계 테스트를 수행하는 경우와 UI 디자인 표준을 준수하는지 UI 요소를 유효성 검증하는 경우가 이에 해당합니다.

테스트 데이터 종속성 촉진 페이지 맨 위로

지정된 테스트 환경 구성에서 테스트를 수행할 경우 사용되는 테스트 데이터 값이 충돌할 수도 있습니다. 여러 테스트 팀 구성원들이 이 환경을 공유하고 있는 경우에는 이 문제점이 더욱 가중됩니다. 테스트 데이터 값을 사용하는 테스트 스크립트에서 테스트 데이터 값을 결합 해제하는 데이터 기반 접근 방식을 고려하십시오. 그리고 테스트 데이터의 수집과 수정을 위한 중앙 지점을 제공하십시오. 이 방법을 사용하면 두 가지 이점을 얻을 수 있습니다. 모든 테스트 팀 구성원이 테스트 데이터를 볼 수 있으므로 테스트 데이터 사용에 따른 잠재적인 충돌을 피할 수 있으며, 테스트 데이터를 갱신해야 할 경우 테스트 데이터에 대한 중앙 수정 지점을 제공합니다.

테스트 상태 종속성 촉진 페이지 맨 위로

대부분의 테스트에서는 테스트가 실행되기 전에 시스템이 지정된 특정 상태에 있어야 하며, 테스트가 완료될 때 시스템이 알려진 특정 상태로 리턴되어야 합니다. 공통 종속성으로는 보안 권한(기능 또는 데이터), 동적 또는 컨텍스트 감지 데이터(예: 시스템 날짜, 순서 번호, 사용자 ID 환경 설정 등), 데이터 만기 사이클(예: 보안 암호, 제품 만기 등)이 있습니다. 몇몇 테스트들은 서로에게 매우 의존적입니다. 예를 들어, 한 테스트는 고유한 주문 번호를 작성하고 이후 테스트는 같은 주문 번호를 디스패치해야 합니다.

공통 솔루션은 올바른 시스템 상태 순서대로 시퀀스 종속 테스트에 대한 테스트 스위트를 사용하는 것입니다. 그러면 적절한 시스템 복구 및 설정 유틸리티를 사용하여 테스트 스위트가 결합될 수 있습니다. 자동화된 테스트 노력의 경우 일부 솔루션에서 동적 시스템 데이터를 중앙 위치에 저장하고 중앙화된 정보를 참조하는 테스트 스크립트 내에서 변수를 사용할 수도 있습니다.

파생된 테스트 데이터 값 촉진 페이지 맨 위로

경우에 따라 테스트는 런타임 시스템 상태의 여러 측면에서 해당 데이터 값을 계산하거나 도출해야 합니다. 이는 입력 및 예상 결과에 대한 테스트 데이터 값에 적용됩니다. 테스트 실행을 단순화하고 사용자의 실수로 발생할 수 있는 부정확성을 방지할 수 있도록 파생 데이터 값을 계산하는 유틸리티 개발을 고려하십시오. 가능한 경우 수동 테스트 노력과 자동화된 테스트 노력 모두에 사용할 수 있는 유틸리티를 개발하십시오.

공통 테스트 탐색 경로 촉진 페이지 맨 위로

테스트 자동화의 경우 공통 탐색 시퀀스를 분리한 후 중앙화된 유틸리티 기능이나 테스트 스크립트를 사용하여 이를 구현하는 것을 고려해야 합니다. 그러면 이러한 공통 탐색 시퀀스를 여러 곳에 재사용할 수 있으므로, 이후에 탐색을 변경할 경우 중앙 수정 지점이 제공됩니다. 이러한 공통 탐색은 단순히 응용프로그램이 한 지점에서 다른 지점으로 이동할 수 있도록 지원하며, 일반적으로 시작 및 종료 상태를 확인할 목적 이외에는 자체적인 테스트를 수행하지 않습니다.

테스트별 디자인 요구사항 식별
목적:  테스트 원칙의 요구사항을 식별하여 이에 따라 소프트웨어 엔지니어링 프로세스, 소프트웨어 아키텍처, 해당 디자인 및 구현에 대해 잠재적인 제한조건을 부과합니다.  

특히 테스트 자동화와 관련하여, 테스트 구현 및 평가 요구 사항에 따라 개발 팀에서 소프트웨어 엔지니어링 프로세스를 규정하는 방식과 소프트웨어의 아키텍처와 디자인에 대한 몇 가지 제한조건이 부과될 수 있습니다. 소프트웨어 개발 팀이 팀의 핵심 개발 작업을 과도하게 방해하지 않는 것과 테스트 팀에서 필요한 테스트 수행 능력을 갖추는 것이 중요합니다. 테스트 팀의 요구사항을 개발 팀에게 제시하는 방법과 모든 원칙의 요구사항을 만족하는 작업 가능한 솔루션을 찾는 방법에 대한 자세한 내용은 타스크: 테스트 용이성 확약 얻기를 참조하십시오.

수집한 정보를 이용하여 테스트 노력이 개발 노력에 대해 어떠한 요구사항을 부과할지 고려하십시오.

하위 주제:

테스트 인터페이스 식별 페이지 맨 위로

인터페이스 식별을 고려하십시오. 소프트웨어 디자인에 포함되었다가 나중에 구현에 노출될 추가 요구 사항이 테스트 노력에 필요합니까? 경우에 따라 특히 테스트 노력을 지원하기 위해 추가 인터페이스가 필요하거나, 기존 인터페이스에 추가 작동 모드나 수정된 메시지 서명(입력 및 리턴 매개변수에 대한 변경사항)이 필요합니다.

대상 배치 환경(테스트 환경 구성에 캡처되어 있음) 및 배치 스케줄 자체와 관련하여 테스트 노력에 부과된 제한조건과 종속성을 식별하십시오. 이러한 종속성에는 사용 가능하지 않는 환경이나 자원이 금지되어 있어서 테스트용으로 설정할 수 없는 환경의 요소를 시뮬레이션하거나, 부분적으로 완료된 시스템의 컴포넌트에 대한 초기 테스트 기회를 제공하기 위한 스텁 규정이 필요합니다.

내장 테스트 기능 식별 페이지 맨 위로

잠재적인 가치는 있지만 진정한 블랙 박스 테스트로 구현하기에 지나치게 많은 비용을 필요로 하는 테스트가 있습니다. 또한 고신뢰성 환경에서는 결함(fault)을 테스트하고 이를 가능한 빨리 분리하여 신속한 해결이 가능하도록 하는 것이 중요합니다. 이 경우 실행 가능한 소프트웨어 자체에 직접 테스트를 빌드하는 것이 유용할 수 있습니다.

이를 위해 취할 수 있는 접근 방식에는 여러 가지가 있습니다. 가장 일반적인 두 가지 방법에는 내장 셀프 테스트와 진단 루틴이 포함되는데, 내장 셀프 테스트는 중복되는 처리 주기를 사용하여 자체 무결성 테스트를 수행하며, 진단 루틴은 소프트웨어에 진단 이벤트 메시지를 보낼 때 또는 진단 루틴이 사용 가능한 상태로 실행되도록 시스템이 구성된 경우에 수행할 수 있습니다.

테스트 디자인 제한조건 식별 페이지 맨 위로

개발 팀의 일부 디자인 및 구현 선택사항은 테스트 노력을 사용하거나 사용하지 않도록 할 수 있습니다. 이러한 선택사항 중 일부는 불가피하게 필요합니다. 반면, 개발 팀에는 최소의 영향을 미치지만 테스트 팀에는 상당한 영향을 미치는 사소한 결정사항이 많이 있습니다(특히 구현 영역에서).

표준 사용, 인식된 통신 프로토콜, 테스트 자동화 도구에 의해 인식될 수 있는 UI 구현 컴포넌트의 사용, UI 요소 이름 지정을 비롯한 UI 디자인 규칙 준수, UI 탐색 규칙의 일관된 사용 영역들을 고려해야 합니다.

소프트웨어 테스트 용이성 요구사항 정의
목적:  테스트의 구현과 실행을 지원하는 데 필요한 소프트웨어 기능에 대한 요구사항을 지정합니다.  

이 타스크에서 수행한 이전 작업을 사용하여 소프트웨어를 디자인하고 구현할 때 고려해야 할 테스트별 요구사항과 제한조건을 정의하십시오.

테스트별 기능을 스프트웨어에 내장해야 하는 이유를 개발 팀에게 명확하게 설명하는 것이 중요합니다. 주요 이유는 일반적으로 다음 영역 중 하나에 해당합니다.

  • 대상 테스트 항목과 수동/자동화된 테스트 간에 인터페이스를 제공하여 자동화된 테스트와 수동 테스트를 구현하기 위해. 이는 테스트 자동화 사안과 가장 많은 관련이 있으며, 정보 입력과 출력 시 소프트웨어 응용프로그램에 액세스할 수 있게 하므로 테스트 자동화 도구의 한계를 극복하는 데 유용합니다.
  • 개발 소프트웨어가 자체적으로 내장 셀프 테스트를 수행할 수 있도록 하기 위해.
  • 대상 테스트 항목을 나머지 개발 시스템과 분리하여 테스트하기 위해.

소프트웨어에 내장된 테스트별 기능은 내장 테스트 기능의 가치와 이 기능을 구현하고 테스트하는 데 필요한 노력을 비교하여 이 둘의 밸런스를 맞춰야 합니다. 내장 테스트 기능의 예로는 생산 감사 로그, 자체 진단 기능 및 내부 변수의 값을 조회하는 인터페이스를 들 수 있습니다.

또한 테스트별 기능은 일반적으로 아직 구현되거나 통합되지 않은 컴포넌트나 서브시스템에 스텁을 제공해야 하는 통합 작업 중에도 사용됩니다. 스텁에 사용되는 두 가지 기본 구현 스타일은 다음과 같습니다.

  • 미리 정의된 특정 값을 입력 값이나 리턴값으로 제공할 수 있는 것 이외에는 다른 기능이 없는 단순한 "더미"인 스텁 및 드라이버
  • 보다 지능적이면서 보다 복잡한 동작을 "시뮬레이션"하거나 이러한 동작에 근접할 수 있는 스텁 및 드라이버

이 두 번째 스텁 스타일은 또한 컴포넌트나 컴포넌트 그룹을 나머지 시스템으로부터 분리하는 강력한 수단을 제공함으로써, 테스트의 구현과 실행에 있어서 융통성을 제공합니다. 앞에서 테스트별 기능에 대한 설명에서 언급한 바와 같이, 복잡한 스텁의 가치와 이 스텁을 구현하고 테스트하는 데 필요한 노력을 비교하여 이 둘의 밸런스를 고려해야 합니다. 이 두 번째 스타일을 사용할 때는 다음 두 가지 이유로 주의해야 합니다. 첫째, 구현하는 데 더 많은 자원을 필요로 합니다. 둘째, 스텁의 존재를 간과하여 나중에 이를 제거하는 것을 잊어 버릴 수 있습니다.

디자인 및 구현 모델에 대한 테스트별 요구사항의 관점에서 결과를 직접 기록하거나, 하나 이상의 테스트 인터페이스 스펙을 사용하십시오.

테스트 하부 구조 정의
목적:  테스트의 구현과 실행을 지원하는 데 필요한 테스트 하부 구조에 대한 요구사항을 지정합니다.  

이 타스크에서 수행한 이전 작업을 사용하여 테스트 구현과 실행을 지원하는 데 필요한 테스트 하부 구조를 정의하십시오.

하부 구조의 구현 기능을 정의하고 있음을 명심하십시오. 주요 목적은 해당 하부 구조를 구현할 솔루션의 다양한 부분을 정의하는 것입니다.

하위 주제:

테스트 자동화 요소 페이지 맨 위로

테스트 자동화 하부 구조의 주요 요구사항이나 기능은 다음과 같습니다.

  • 탐색 모델: 일반적인 접근 방식은 라운드 트립 접근 방식, 세그먼트화된 접근 방식 또는 혼합 접근 방식입니다. 또 다른 방법은 Action-Word 프레임워크나 화면 탐색 표를 사용하는 것입니다.
  • 외부 데이터 액세스: 외부에서 테스트 지침 데이터에 액세스하는 방법입니다.
  • 오류 보고 및 복구: 일반적인 오류 처리 루틴 및 테스트 스위트 복구 실행 랩퍼
  • 보안 및 액세스 프로파일: 자동화된 테스트 실행 사용자 ID
  • 소프트웨어의 셀프 테스트 기능

결정을 테스트 자동화 아키텍처의 구현 섹션에 있는 정의로, 하나 이상의 테스트 가이드라인에 있는 프로세스 안내로, 또는 테스트 스크립트, 테스트 스위트, 테스트 라이브러리 유틸리티 루틴으로 기록하십시오. 추가 제안사항은 중간 산출물: 테스트 자동화 아키텍처를 참조하십시오.

수동 테스트 요소 페이지 맨 위로

수동 테스트 하부 구조의 주요 요구사항이나 기능은 다음과 같습니다.

  • 테스트 데이터 저장소: 테스트 데이터 정의에 대한 일반 저장소입니다.
  • 복원 및 복구: 테스트 환경 구성을 알려진 상태로 복원 또는 복구하는 방법입니다.
  • 대상 테스트 항목을 나머지 개발 시스템과 분리하여 테스트하기 위해.

결정을 하나 이상의 중간 산출물: 프로젝트 가이드라인에 있는 프로세스 안내로 기록하십시오.

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

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

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

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



자세한 정보