[ISTQB CTAL TAE]Syllabus #3장 전반적인 테스트 자동화 아키텍처

키워드

• capture/playback - 캡처/재생
• data-driven testing - 데이터 주도 테스팅
• generic test automation architecture - 일반적인 테스트 자동화 아키텍처
• keyword-driven testing - 키워드 주도 테스팅
• linear scripting - 선형 스크립팅
• model-based testing - 모델 기반 테스팅
• process-driven scripting - 프로세스 주도 스크립팅
• structured scripting - 구조화된 스크립팅
• test adaptation layer - 테스트 적응 계층
• test automation architecture - 테스트 자동화 아키텍처
• test automation framework - 테스트 자동화 프레임워크
• test automation solution - 테스트 자동화 솔루션
• test definition layer - 테스트 정의 계층
• test execution layer - 테스트 실행 계층
• test generation layer - 테스트 생성 계층

Generic Test Automation Architecture 학습목표

• 3.1 gTAA 소개
  • gTAA의 구조를 설명할 수 있다..
• 3.2 TAA 디자인
  • 주어진 프로젝트에 적합한 TAA를 디자인할 수 있다.
  • TAA 내에서 계층이 하는 역할을 설명할 수 있다.
  • TAA의 디자인 고려 사항을 이해한다.
  • 주어진 TAS에 대한 구현, 사용 및 유지 보수 요구 사항 요소를 분석할 수 있다.
• 3.3 TAS 개발
  • 일반적인 gTAA 컴포넌트를 적용하여 목적에 맞는 TAA를 구성할 수 있다.
  • 컴포넌트의 재사용 가능성을 식별할 때 고려해야 할 요소를 설명할 수 있다.

3.1 gTTA 소개

테스트 자동화 엔지니어 (TAE)는 테스트 자동화 솔루션 (TAS)을 디자인, 개발, 구현 및 유지 관리하는 역할을 수행한다. 각 솔루션이 개발될 때 유사한 작업이 수행되어야 하며, 유사한 질문에 답하고 유사한 문제를 해결하고 우선순위를 매겨야 한다. 이러한 반복되는 개념, 단계 및 접근 방식은 테스트 자동화의 기반을 형성하며, 이를 짧게 gTAA라고 한다.

gTAA는 gTAA의 계층, 구성 요소 및 인터페이스를 제시하며, 이를 특정 TAS에 대한 구체적인 TAA로 더 자세히 재정의한다. 이는 구조화되고 모듈식 접근 방식을 통해 테스트 자동화 솔루션을 구축하는데 다음과 같은 방법을 제공한다:

• 내부 및 외부 개발된 구성 요소를 사용하여 TAS를 실현하기 위한 TAS의 개념 공간, 계층, 서비스 및 인터페이스를 정의한다.
• 효과적이고 효율적인 테스트 자동화 개발을 위한 간소화된 구성 요소를 지원한다.
• 소프트웨어 제품 라인 및 패밀리 내에서 다양한 또는 진화하는 TAS에 대해 테스트 자동화 구성 요소를 재사용하며, 소프트웨어 기술 및 도구를 거쳐 교차로 활용한다.
• TAS의 유지 보수 및 진화를 용이하게 한다.
• TAS 사용자의 필수 기능을 정의한다.

TAS는 테스트 환경(및 해당 아티팩트)과 테스트 스위트(테스트 데이터 포함한 테스트 케이스 집합) 모두를 포함한다. 테스트 자동화 프레임워크(TAF)를 사용하여 TAS를 실현할 수 있다. TAF는 테스트 환경을 실현하고 도구, 테스트 하네스 또는 지원 라이브러리를 제공하는데 도움을 준다.

TAS의 TAA는 TAS의 쉬운 개발, 진화 및 유지 관리를 지원하는 다음 원칙을 준수하는 것이 좋다:

• 단일 책임: 각 TAS 구성 요소는 단일 책임을 가져야 하며, 해당 책임은 완전히 해당 구성 요소에 캡슐화되어야 한다. 다시 말해, 각 TAS 구성 요소는 정확히 한 가지 역할을 맡아야 하며, 예를 들어 키워드나 데이터 생성, 테스트 시나리오 생성, 테스트 케이스 실행, 결과 기록, 실행 보고서 생성 등을 맡을 수 있다.
• 확장 (예: B. Myer의 개방/폐쇄 원칙 참조): 각 TAS 구성 요소는 확장을 위해 열려 있어야 하지만 수정을 위해는 닫혀 있어야 한다. 이 원칙은 구성 요소의 동작을 수정하거나 향상시키는 것이 후방 호환 기능을 깨뜨리지 않고 가능해야 함을 의미한다.
• 교체 (예: B. Liskov의 치환 원칙 참조): 각 TAS 구성 요소는 TAS의 전체 동작에 영향을 미치지 않고 교체 가능해야 한다. 이 구성 요소는 하나 이상의 대체 구성 요소로 교체될 수 있지만 표시된 동작은 동일해야 한다.
• 구성 요소 분리 (예: R.C. Martin의 인터페이스 분리 원칙 참조): 일반적인, 다기능의 구성 요소보다는 더 구체적인 구성 요소가 더 좋다. 이렇게 함으로써 불필요한 종속성을 제거하여 교체와 유지 보수를 더 쉽게 할 수 있다.
• 의존성 역전: TAS의 구성 요소는 저수준 세부 정보가 아닌 추상화에 의존해야 한다. 다시 말해, 구성 요소는 특정 자동화된 테스트 시나리오에 의존해서는 안된다.

일반적으로 gTAA를 기반으로 한 TAS는 일련의 도구, 그들의 플러그인 및/또는 구성 요소로 구현된다. 중요한 점은 gTAA가 벤더 중립적이라는 것이다. 즉, TAS를 실현하기 위해 구체적인 방법, 기술 또는 도구를 미리 정의하지 않는다. gTAA는 구조화, 객체지향, 서비스 지향, 모델 기반과 같은 소프트웨어 엔지니어링 접근 방식뿐만 아니라 소프트웨어 기술과 도구로도 구현될 수 있다. 실제로 TAS는 종종 완제품 도구를 사용하여 구현되지만, 일반적으로 추가적인 SUT(시스템 테스트 대상) 특정 추가 및/또는 적응이 필요하다.

TAS와 관련된 다른 지침 및 참조 모델은 선택된 SDLC(소프트웨어 개발 라이프사이클), 프로그래밍 기술, 형식 지침 등에 대한 소프트웨어 엔지니어링 표준이다. 이 교육과정의 범위에서는 일반적인 소프트웨어 엔지니어링을 가르치는 것은 아니지만, TAE는 소프트웨어 엔지니어링에 대한 기술, 경험 및 전문지식을 갖추고 있어야 한다.

또한, TAE는 개발 중에 산업 표준 코딩 및 문서화 기준과 최선의 방법론을 인지하여 이를 활용해야 한다. 이러한 관행은 TAS의 유지 보수성, 신뢰성 및 보안성을 향상시킬 수 있다. 이러한 표준은 일반적으로 도메인별로 다르다. 널리 사용되는 표준에는 다음이 있다:

• C 또는 C++용 MISRA 표준
• C++용 JSF 코딩 표준
• MathWorks Matlab/Simulink®용 AUTOSAR 규칙

3.1.1 gTAA 개요

gTAA는 다음을 위한 수평적인 계층으로 구성된다:

• 테스트 생성
• 테스트 정의
• 테스트 실행
• 테스트 적응

gTAA (그림 1: 일반적인 테스트 자동화 아키텍처 참조)는 다음을 포함한다:

• 테스트 생성 계층: 수동 또는 자동으로 테스트 케이스를 설계하는 데 지원되며, 테스트 케이스를 설계하는 수단을 제공한다.
• 테스트 정의 계층: 테스트 스위트와/또는 테스트 케이스의 정의 및 구현을 지원한다. 이는 테스트 정의를 SUT와/또는 테스트 시스템 기술 및 도구와 분리하며, 테스트 데이터, 테스트 케이스, 테스트 절차 및 테스트 라이브러리 구성 요소 또는 이들의 조합을 정의하는 수단을 포함한다.
• 테스트 실행 계층: 테스트 케이스의 실행과 테스트 로깅을 지원한다. 선택한 테스트를 자동으로 실행하는 테스트 실행 도구와 로깅 및 보고 구성 요소를 제공한다.
• 테스트 적응 계층: 자동화된 테스트를 SUT의 다양한 구성 요소 또는 인터페이스에 적응시키기 위한 필요한 코드를 제공한다. SUT에 API, 프로토콜, 서비스 및 기타를 통해 연결하기 위한 다양한 어댑터를 제공한다.
• 또한 프로젝트 관리, 구성 관리 및 테스트 관리와 관련하여 테스트 자동화와 관련된 인터페이스도 포함한다. 예를 들어, 테스트 관리와 테스트 적응 계층 간의 인터페이스는 선택한 테스트 구성에 관련하여 적절한 어댑터를 선택하고 구성하기 위한 것이다.

gTAA 계층과 그 구성 요소 간의 인터페이스는 일반적으로 구체적이며, 따라서 여기서 자세히 다루지 않는다.

이러한 계층들은 어떤 특정한 TAS에 존재하거나 없을 수 있다는 점을 이해하는 것이 중요하다. 예를 들어:

• 테스트 실행을 자동화하려면 테스트 실행 및 테스트 적응 계층을 활용해야 한다. 이들은 분리되어 있을 필요 없이 함께 구현될 수 있으며, 예를 들어 유닛 테스트 프레임워크에서 구현될 수 있다.
• 테스트 정의를 자동화하려면 테스트 정의 계층이 필요하다.
• 테스트 생성을 자동화하려면 테스트 생성 계층이 필요하다.

대부분의 경우, TAS의 구현은 아래에서 위로 시작하는 것이 일반적이지만, 수동 테스트를 위한 자동화된 테스트 생성과 같은 다른 접근 방식도 유용할 수 있다. 일반적으로 TAS를 점진적인 단계로 구현하는 것이 조언되며 (예: 스프린트 단위로), 가능한 빨리 TAS를 사용하고 추가된 가치를 입증하는 데 활용하는 것이 좋다. 또한, 개념 증명은 테스트 자동화 프로젝트의 일부로 권장되는 접근 방식이다.

어떤 테스트 자동화 프로젝트든 소프트웨어 개발 프로젝트로서 이해되고 설정되며 관리되어야 하며, 전용 프로젝트 관리가 필요하다. TAF (즉, 전사적인 회사, 제품 패밀리 또는 제품 라인에 대한 테스트 자동화 지원) 개발을 위한 프로젝트 관리는 TAS (즉, 구체적인 제품에 대한 테스트 자동화)를 위한 프로젝트 관리와 분리될 수 있다.

3.1.2 테스트 생성 계층

테스트 생성 레이어는 다음을 위한 도구 지원으로 구성된다:

• 수동으로 테스트 케이스를 설계하는 것
• 시스템 언어 또는 환경을 정의하는 모델로부터 자동으로 테스트 케이스를 생성하는 것 (즉, 자동 모델 기반 테스트)
• 테스트 데이터를 개발하거나 캡처하거나 유도하는 것

이 레이어의 구성 요소는 다음을 위해 사용된다:

• 테스트 스위트 구조를 편집하고 탐색하는 것
• 테스트 케이스를 테스트 목적 또는 시스템 어떤 요구 사항과 관련시키는 것
• 테스트 디자인을 문서화하는 것

자동화된 테스트 생성을 위해 다음과 같은 능력도 포함될 수 있다:

• 시스템 언어, 그 환경 또는 테스트 시스템을 모델링할 수 있는 능력
• 테스트 지침을 정의하고 테스트 생성 알고리즘을 구성하거나 매개변수화할 수 있는 능력
• 생성된 테스트를 모델 (요소)로 역추적할 수 있는 능력

3.1.3 테스트 정의 레이어

테스트 정의 레이어는 다음을 위한 도구 지원으로 구성된다:

• 테스트 케이스를 명시하는 것 (고수준 및/또는 저수준에서)
• 저수준 테스트 케이스에 대한 테스트 데이터를 정의하는 것
• 테스트 케이스 또는 일련의 테스트 케이스에 대한 테스트 절차를 명시하는 것
• 테스트 케이스의 실행을 위한 테스트 스크립트를 정의하는 것
• 필요한 경우 테스트 라이브러리에 액세스 제공 (예: 키워드 기반 접근 방식에서)

이 레이어의 구성 요소는 다음을 위해 사용된다:

• 테스트 데이터를 분할하거나 제한하거나 매개변수화하거나 실체화하는 것
• 테스트 시퀀스를 명시하거나 완전한 테스트 동작을 지정하는 것 (제어문 및 표현식을 포함하여), 그리고 매개변수화하거나 그룹화하는 것
• 테스트 데이터, 테스트 케이스 및/또는 테스트 절차를 문서화하는 것

3.1.4 테스트 실행 레이어

테스트 실행 레이어는 다음을 위한 도구 지원으로 구성된다:

• 테스트 케이스를 자동으로 실행하는 것
• 테스트 케이스 실행을 로깅하는 것
• 테스트 결과를 보고하는 것

테스트 실행 레이어는 다음과 같은 능력을 제공하는 구성 요소로 구성될 수 있다:

• 테스트 실행을 위해 SUT를 설정하고 해제하는 것
• 테스트 스위트를 설정하고 해제하는 것 (즉, 테스트 데이터를 포함한 테스트 케이스의 집합)
• 테스트 설정을 구성하고 매개변수화하는 것
• 테스트 데이터와 테스트 케이스를 해석하고 실행 가능한 스크립트로 변환하는 것
• (필터링된) 테스트 실행 로깅 또는 결함 주입을 위해 테스트 시스템 및/또는 SUT를 기기화하는 것
• 테스트 실행 중 SUT 응답을 분석하여 후속 테스트 실행을 조절하는 것
• 자동 테스트 케이스 실행 결과를 위해 SUT 응답을 유효성 검사하는 것 (예상 결과와 실제 결과의 비교)
• 시간 내에서 자동화된 테스트 실행을 제어하는 것

3.1.5 테스트 적응 레이어

테스트 적응 레이어는 다음을 위한 도구 지원으로 구성된다:

• 테스트 하네스를 제어하는 것
• SUT와 상호 작용하는 것
• SUT를 모니터링하는 것
• SUT 환경을 시뮬레이션하거나 에뮬레이션하는 것

테스트 적응 레이어는 다음의 기능을 제공한다:

• 기술 중립적인 테스트 정의와 SUT 및 테스트 장치의 구체적인 기술 요구 사항 간의 중재
• SUT와 상호 작용하기 위해 다양한 기술별 어댑터를 적용
• 테스트 실행을 여러 테스트 장치/테스트 인터페이스에 걸쳐 분배하거나 로컬에서 테스트를 실행하는 것

3.1.6 TAS의 구성 관리

보통 TAS(Test Automation System)는 다양한 반복/버전에서 개발되며 SUT(System Under Test)의 반복/버전과 호환되어야 한다. TAS의 구성 관리에는 일반적으로 다음이 포함될 수 있다:

• 테스트 모델
• 테스트 정의/사양 (테스트 데이터, 테스트 케이스 및 라이브러리 포함)
• 테스트 스크립트
• 테스트 실행 엔진 및 보조 도구 및 구성 요소
• SUT를 위한 테스트 어댑터
• SUT 환경을 위한 시뮬레이터 및 에뮬레이터
• 테스트 결과 및 테스트 보고서

이러한 항목은 테스트웨어를 구성하며 SUT의 버전과 일치하도록 올바른 버전에 있어야 한다. 일부 상황에서는 예를 들어 현장 이슈를 이전 SUT 버전에서 재현해야 하는 경우 TAS의 이전 버전으로 되돌아가야 할 수 있다. 좋은 구성 관리는 이러한 능력을 활성화한다.

3.1.7 TAS의 프로젝트 관리

어떤 테스트 자동화 프로젝트도 소프트웨어 프로젝트이기 때문에, 이는 다른 어떤 소프트웨어 프로젝트와 마찬가지로 동일한 프로젝트 관리를 필요로 한다. 테스트 자동화 엔지니어(TAE)는 TAS를 개발할 때 수립된 SDLC(Software Development Life Cycle) 방법론의 모든 단계에서 작업을 수행해야 한다. 또한, TAE는 TAS의 개발 환경이 TAS의 프로젝트 관리에 쉽게 추출되거나 자동으로 보고될 수 있는 상태 정보(메트릭)를 설계해야 한다.

3.1.8 TAS의 테스트 관리 지원

TAS는 SUT의 테스트 관리를 지원해야 한다. 테스트 보고서, 테스트 로그 및 테스트 결과를 포함한 정보는 쉽게 추출되거나 자동으로 SUT의 테스트 관리(인력 또는 시스템)에 제공되어야 한다.

3.2 TAA 디자인

3.2.1 TAA 디자인 소개

TAA(테스트 자동화 아키텍처)를 디자인하기 위해 필요한 주요 활동이 여러 가지 있다. 이러한 활동은 테스트 자동화 프로젝트나 조직의 요구에 따라 순서를 정할 수 있다. 이러한 활동에 대해 아래 섹션에서 논의한다. TAA의 복잡성에 따라 더 많거나 더 적은 활동이 필요할 수 있다.

적절한 TAA를 정의하기 위해 필요한 요구사항을 정리한다.

테스트 자동화 접근 방식의 요구사항은 다음을 고려해야 한다:

• 어떤 테스트 프로세스의 활동이나 단계를 자동화해야 하는지, 예를 들어 테스트 관리, 테스트 디자인, 테스트 생성 또는 테스트 실행. 테스트 자동화는 테스트 디자인과 테스트 실행 사이에 테스트 생성을 삽입하여 기본 테스트 프로세스를 정제한다.
• 어떤 테스트 레벨을 지원해야 하는지, 예를 들어 컴포넌트 레벨, 통합 레벨, 시스템 레벨
• 어떤 종류의 테스트를 지원해야 하는지, 예를 들어 기능 테스트, 준수 테스트, 상호 운용성 테스트
• 어떤 테스트 역할을 지원해야 하는지, 예를 들어 테스트 실행자, 테스트 분석가, 테스트 아키텍트, 테스트 매니저
• 어떤 소프트웨어 제품, 소프트웨어 제품 라인, 소프트웨어 제품 패밀리를 지원해야 하는지, 예를 들어 구현된 TAS의 범위와 수명을 정의하기 위해
• 어떤 SUT 기술을 지원해야 하는지, 예를 들어 SUT 기술과의 호환성을 고려하여 TAS를 정의하기 위해

다양한 디자인/아키텍처 접근 방식을 비교하고 대조한다.

TAE는 TAA의 선택된 레이어를 디자인할 때 다양한 접근 방식의 장단점을 분석해야 한다. 이는 다음을 포함하나 이에 국한되지 않는다:

테스트 생성 레이어 고려사항:

• 수동 또는 자동 테스트 생성 선택
• 요구 기반, 데이터 기반, 시나리오 기반 또는 동작 기반 테스트 생성 선택
• 테스트 생성 전략 선택 (예: 데이터 기반 접근에서는 분류 트리, 시나리오 기반 접근에서는 Use Case/Exception Case 커버리지, 동작 기반 접근에서는 전이/상태/경로 커버리지 등)
• 테스트 선택 전략 선택. 실제로 모든 조합 테스트 생성은 불가능할 수 있으므로, 테스트 생성 및 이후 테스트 선택을 안내하기 위해 실용적인 커버리지 기준, 가중치, 위험 평가 등을 사용해야 함.

테스트 정의 레이어 고려사항:

• 데이터 주도, 키워드 주도, 패턴 기반 또는 모델 기반 테스트 정의 선택
• 테스트 정의를 위한 표기법 선택 (예: 표, 상태 기반 표기법, 확률적 표기법, 데이터 흐름 표기법, 비즈니스 프로세스 표기법, 시나리오 기반 표기법 등을 사용하여 스프레드시트, 도메인 특화 테스트 언어, TTCN-3, UML 테스팅 프로필 등)
• 고품질 테스트 정의를 위한 스타일 가이드 및 지침 선택
• 테스트 케이스 저장소 선택 (스프레드시트, 데이터베이스, 파일 등)

테스트 실행 레이어 고려사항:

• 테스트 실행 도구 선택
• 테스트 절차를 구현하기 위한 해석 (가상 머신 사용) 또는 컴파일 접근 선택 - 이 선택은 일반적으로 선택된 테스트 실행 도구에 따라 달라진다.

테스트 절차를 구현하기 위한 구현 기술 선택 (명령형인 경우 C; 함수형인 경우 Haskell이나 Erlang; 객체지향인 경우 C++, C#, Java; 스크립팅인 경우 Python이나 Ruby, 또는 도구 특정 기술) - 이 선택은 일반적으로 선택된 테스트 실행 도구에 따라 달라진다.

• 테스트 실행을 용이하게 하기 위한 헬퍼 라이브러리 선택 (예: 테스트 디바이스 라이브러리, 인코딩/디코딩 라이브러리 등)

테스트 적응 레이어 고려사항:

• SUT에 대한 테스트 인터페이스 선택
• 테스트 인터페이스를 자극하고 관찰하기 위한 도구 선택
• 테스트 실행 중에 SUT를 모니터링하기 위한 도구 선택
• 테스트 실행의 추적을 위한 도구 선택 (예: 테스트 실행의 타이밍을 포함하여)

추상화가 이점을 제공할 수 있는 영역을 식별한다.

TAA에서의 추상화는 동일한 테스트 스위트가 다른 테스트 환경 및 대상 기술에서 사용될 수 있도록 하여 기술 독립성을 제공한다. 테스트 아티팩트의 이식성이 향상되며, 업체 중립성이 보장되어 TAS에 대한 잠금 효과를 방지한다. 또한, 추상화는 유지 관리성을 향상시키고 새로운 또는 진화하는 SUT 기술에 대한 적응성을 향상시킨다. 더불어, 추상화는 테스트 스위트를 더 높은 수준에서 문서화하고 설명할 수 있도록 하여 (그래픽 수단을 포함하여) 비기술자들에게 TAA(그리고 TAS에 의한 인스턴스)를 더 쉽게 이해할 수 있게 한다.

TAE는 소프트웨어 개발, 품질 보증 및 테스트와 관련된 이해 관계자들과 논의하여 TAS의 어느 부분에 어떤 수준의 추상화를 사용할지 결정해야 한다. 예를 들어 테스트 적응 또는 테스트 실행 레이어의 어떤 인터페이스가 외부화되어야 하며 공식적으로 정의되고 TAA 수명 동안 안정적으로 유지되어야 하는지 논의해야 한다. 또한, 추상적인 테스트 정의가 사용되고 있는지 또는 TAA가 테스트 스크립트만 사용하는 테스트 실행 레이어를 사용하는지에 대한 이해가 필요하다. 마찬가지로 테스트 생성이 테스트 모델 및 모델 기반 테스트 접근 방식을 사용하여 추상화되고 있는지 여부를 이해해야 한다. TAE는 TAA의 전반적인 기능, 유지 관리성 및 확장성에 관한 정교하고 직접적인 구현 간의 균형을 고려해야 하는 트레이드 오프가 있음을 알아야 한다.

TAA에 대한 추상화가 많이 사용될수록 새로운 접근 방식이나 기술로의 전환 또는 진화에 대한 유연성이 더 높아진다. 이는 초기 투자 비용이 크게 증가함을 의미하며(예: 더 복잡한 테스트 자동화 아키텍처 및 도구, 더 높은 기술 요구 사항, 큰 학습 곡선), 초기 손익 분기점을 늦추지만 장기적으로 이익을 가져올 수 있다. 또한 TAS의 성능이 떨어질 수 있다. 자세한 투자 수익 분석(ROI) 고려는 TAM(Technical Account Manager)의 책임이지만 TAE는 시간, 비용, 노력 및 이점에 관한 기술적인 평가와 다른 테스트 자동화 아키텍처 및 접근 방식 간의 비교를 제공하여 ROI 분석에 대한 입력을 제공해야 한다.

SUT(Software Under Test) 기술을 이해하고 이것이 TAS(Test Automation System)와 어떻게 상호 연결되는지 파악해야 한다.

자동화된 테스트 실행에 있어서 SUT의 테스트 인터페이스에 대한 접근은 중요합니다. 이 접근은 다음 수준에서 가능할 수 있다:

• 소프트웨어 수준: 예를 들어, SUT와 테스트 소프트웨어가 연결된다.
• API 수준: 예를 들어, TAS가 (원격) 응용 프로그래밍 인터페이스에서 제공하는 함수/연산/메서드를 호출한다.
• 프로토콜 수준: 예를 들어, TAS가 HTTP, TCP 등을 통해 SUT와 상호 작용한다.
• 서비스 수준: 예를 들어, TAS가 웹 서비스, RESTful 서비스 등을 통해 SUT 서비스와 상호 작용한다.

이러한 접근 방식을 통해 TAS는 SUT의 다양한 기술적 측면과 통합될 수 있다. 이를 통해 테스트 케이스를 자동으로 실행하고 SUT의 응답을 확인할 수 있다. SUT의 특정 특징 및 요구 사항에 따라 적절한 접근 방식을 선택하고 구현하는 것이 중요하다.

더불어, TAE는 TAS와 SUT 사이에 API, 프로토콜 또는 서비스로 구분될 때, TAS와 SUT 간의 상호 작용에 사용할 TAA의 상호 작용 패러다임에 대한 결정을 내려야 한다. 이러한 패러다임에는 다음이 포함된다:

• 이벤트 기반 패러다임: 이벤트 버스에서 교환되는 이벤트를 통해 상호 작용을 주도한다.
• 클라이언트-서버 패러다임: 서비스 요청자에서 서비스 제공자로의 서비스 호출을 통해 상호 작용을 주도한다.
• 피어 투 피어 패러다임: 양쪽 피어에서의 서비스 호출을 통해 상호 작용을 주도한다.

패러다임 선택은 종종 SUT 아키텍처에 의존하며, SUT 아키텍처에 영향을 미칠 수 있다. SUT와 TAA 간의 상호 연결은 두 시스템 간의 미래 안전한 아키텍처를 선택하기 위해 주의 깊게 분석되고 설계되어야 한다.

SUT(Software Under Test) 환경을 이해한다.

SUT는 독립적인 소프트웨어이거나 다른 소프트웨어와의 관련성에서만 작동하는 소프트웨어일 수 있다(예: 시스템의 시스템), 하드웨어(예: 임베디드 시스템) 또는 환경 구성 요소(예: 사이버-물리 시스템). TAS는 자동화된 테스트 설정의 일부로 SUT 환경을 시뮬레이션하거나 에뮬레이션한다.

테스트 환경과 샘플 사용 사례의 예는 다음과 같다:

• SUT 및 TAS가 모두 포함된 컴퓨터 – 소프트웨어 응용 프로그램을 테스트하는 데 유용
• 각각의 네트워크화된 컴퓨터 – 서버 소프트웨어를 테스트하는 데 유용
• SUT의 기술적 인터페이스를 자극하고 관찰하기 위한 추가 테스트 장치 – 예를 들어 set-top box에서 소프트웨어를 테스트하는 데 유용
• SUT의 운영 환경을 흉내 내기 위한 네트워크화된 테스트 장치 – 네트워크 라우터 소프트웨어를 테스트하는 데 유용
• SUT의 물리적 환경을 모방하기 위한 시뮬레이터 – 임베디드 제어 장치 소프트웨어를 테스트하는 데 유용

주어진 테스트웨어 아키텍처 구현에 대한 시간과 복잡성

TAS 프로젝트의 노력 추정은 TAM(Technical Account Manager)의 책임이지만, TAE는 TAA(Technical Account Advisor) 디자인의 시간과 복잡성에 대한 좋은 추정을 제공하여 TAM을 지원해야 한다. 추정을 위한 방법과 예시에는 다음이 포함된다:

• 함수 포인트, 삼점 추정, 와이드밴드 델파이, 전문가 추정과 같은 유사성 기반 추정
• 관리 소프트웨어나 프로젝트 템플릿에서 찾을 수 있는 작업 분해 구조를 사용한 추정
• Constructive Cost Model (COCOMO)와 같은 매개변수 추정
• 함수 포인트 분석, 스토리 포인트 분석, 또는 유스 케이스 분석과 같은 크기 기반의 추정
• Planning Poker와 같은 그룹 추정

이러한 추정 방법을 사용하여 TAA 디자인의 작업에 대한 예상 소요 시간과 복잡성을 적절히 판단할 수 있다.

*주어진 테스트웨어 아키텍처 구현의 사용 편의성

TAS의 기능뿐만 아니라 SUT과의 호환성, 장기적인 안정성 및 발전성, 노력 요구 사항, ROI 고려사항과 함께, TAE는 TAS의 사용 편의성 문제에 대한 구체적인 책임이 있다. 이는 다음과 같은 내용을 포함하지만 이에 국한되지 않는다:

• 테스터 지향 디자인
• TAS의 사용 편의성
• 소프트웨어 개발, 품질 보증 및 프로젝트 관리의 다른 역할에 대한 TAS 지원
• TAS 내에서의 효과적인 조직, 탐색 및 검색
• TAS를 위한 유용한 문서, 매뉴얼 및 도움말 텍스트
• TAS에 대한 실용적인 보고서
• TAS 피드백 및 경험적인 통찰을 해결하기 위한 반복적인 디자인

이러한 측면들을 고려하여 TAS를 사용하기 쉽고 효과적으로 활용할 수 있도록 디자인 및 구현되어야 한다.

3.2.2 Approaches for Automating Test Cases