[ISTQB CTAL TAE]Syllabus #2장 테스트 자동화 준비

키워드

• 테스트 가능성
• 드라이버
• 침투 수준
• 스텁
• 테스트 실행 도구
• 테스트 훅
• 테스트 자동화 관리자
  
  

테스트 자동화 준비를 위한 학습 목표

• 2.1 테스트 자동화에 영향을 주는 SUT 요소
  • ALTA-E-2.1.1 (K4) 시스템 테스트를 분석하여 적절한 자동화 솔루션을 결정한다..
    
    
• 2.2 도구 평가 및 선택
  • ALTA-E-2.2.1 (K4) 주어진 프로젝트에 대해 테스트 자동화 도구를 분석하고 기술적인 결과와 권장 사항을 보고한다.
    
    
• 2.3 테스트 가능성과 자동화를 위한 설계
  • ALTA-E-2.3.1 (K2) SUT에 적용 가능한 "테스트 가능성에 대한 설계"와 "테스트 자동화에 대한 설계" 방법을 이해 한다.

 

2.1 테스트 자동화에 영향을 주는 SUT 요소

SUT와 그 환경을 평가할 때, 테스트 자동화에 영향을 주는 요인을 식별하여 적절한 솔루션을 결정해야 한다. 다음과 같은 요소가 포함될 수 있다.

 

• SUT 인터페이스
  자동화된 테스트 케이스는 SUT에 대한 동작을 수행한다. 이를 위해 SUT는 SUT를 제어할 수 있는 인터페이스를 제공해야 한다. 이는 UI 컨트롤을 통해 이루어질 수도 있고, 더 낮은 수준의 소프트웨어 인터페이스를 통해 이루어질 수도 있다. 또한, 일부 테스트 케이스는 통신 수준에서 인터페이스를 통합할 수도 있다. (예: TCP/IP, USB 또는 독자적인 메시징 인터페이스 사용)
  
  SUT의 분해 테스트 자동화는 SUT와 다른 테스트 수준에서 인터페이스를 통합할 수 있도록 한다. 특정 수준에서 (예: 컴포넌트 및 시스템 수준) 테스트를 자동화할 수 있지만, 이를 위해서는 SUT가 이를 적절히 지원해야 한다. 예를 들어, 컴포넌트 수준에서는 테스트에 사용할 수 있는 사용자 인터페이스가 없을 수 있으므로, 다른, 사용자 정의된 소프트웨어 인터페이스(테스트 후크라고도 함)가 필요할 수 있다.
  
  
• 제3자 소프트웨어: SUT는 종종 집단 내에서 작성된 소프트웨어뿐만 아니라 제3자가 제공하는 소프트웨어도 포함될 수 있다. 어떤 상황에서는 이러한 제3자 소프트웨어도 테스트가 필요할 수 있으며, 테스트 자동화가 정당화되면 API를 사용한 다른 테스트 자동화 솔루션이 필요할 수 있다.
  
  
• 침투 수준: 서로 다른 테스트 자동화 접근 방식(다른 도구 사용)은 다른 침투 수준을 가지고 있다. 자동화된 테스트를 위해 특히 SUT에 대한 변경이 필요한 경우, 침투 수준이 높아진다. 전용 소프트웨어 인터페이스 사용은 높은 침투 수준을 필요로 하며, 기존 UI 요소를 사용하는 경우 침투 수준이 낮아진다. 키보드, 핸드 스위치, 터치스크린, 통신 인터페이스와 같은 SUT의 하드웨어 요소를 사용하는 경우에는 더 높은 침투 수준이 필요하다.
  
  높은 침투 수준의 문제는 잘못된 알림의 위험이 있다. 테스트에 의해 가해지는 침투 수준 때문에 TAS에서 결함이 발생할 수 있지만, 이러한 문제는 실제 운영 환경에서 소프트웨어 시스템을 사용할 때는 발생하지 않을 가능성이 크다. 높은 침투 수준으로 테스트하는 것은 일반적으로 테스트 자동화 접근 방식에 대한 더 간단한 해결책이다.
  
  
• 다른 SUT 아키텍처: 다른 SUT 아키텍처는 다른 테스트 자동화 솔루션을 필요로 할 수 있습니다. C++과 COM 기술을 사용하여 작성된 SUT와 Python으로 작성된 SUT를 위해서는 서로 다른 접근 방식이 필요할 수 있습니다. 이러한 다른 아키텍처를 동일한 테스트 자동화 전략으로 처리할 수 있지만, 그들을 지원할 수 있는 하이브리드 전략이 필요합니다.
  
  
• SUT의 크기와 복잡성: 현재 SUT의 크기와 복잡성 및 향후 개발 계획을 고려해야 합니다. 작고 간단한 SUT의 경우 복잡하고 초연결성 있는 테스트 자동화 접근 방식이 필요하지 않을 수 있습니다. 간단한 접근 방식이 더 적합할 수 있습니다. 반대로 매우 크고 복잡한 SUT에 대해 작고 간단한 접근 방식을 구현하는 것은 현명하지 않을 수 있습니다. 그러나 때로는 복잡한 SUT에 대해서도 작고 간단한 접근 방식으로 시작하는 것이 적절할 수 있지만, 이는 일시적인 접근 방식이어야 합니다 (자세한 내용은 제3장을 참조하세요).
  
  
• 여기에 설명된 여러 요소(예:크기와 복잡성, 사용 가능한 소프트웨어 인터페이스)는 SUT가 이미 사용 가능한 경우에 알려져 있다. 그러나 대부분의 경우 테스트 자동화의 개발은 SUT가 사용 가능하기 전에 시작되어야 한다. 이런 경우에는 여러가지를 추정하거나 TAE가 필요한 소프트웨어 인터페이스를 지정할 수 있다.
  
  
• SUT가 아직 존재하지 않는 겨우엥도 테스트 자동화 계획을 시작할 수 있다. 예를 들어 다음과 같다.
  • 요구사항(기능적 또는 비기능적인)이 알려져 있다면, 해당 요구 사항에서 자동화 대상을 선정하고 테스트 방법을 확인할 수 있다. 이러한 대상에 대한 자동화를 위한 계획을 수립할 수 있으며, 자동화 요구 사항을 확인하고 테스트 자동화 전략을 결정할 수 있다.
  • 아키텍처와 기술적인 설계가 개발 중일 때, 테스트를 지원하기 위한 스포트웨어 잍너페이스의 설계를 수행할 수 있다.

 

2.2 도구 평가 및 선택

도구 선택 및 평가 프로세스의 주요 책임은 테스트 자동화 관리자(TAM)에게 있다. 그러나 TAE(테스트 자동화 엔지니어)는 TAM에게 정보를 제공하고 평가 및 선택 활동을 많이 수행하는데 참여한다. 도구 평가 및 선택 프로세스의 개념은 Foundation Level에서 소개되었으며, 이 프로세스의 자세한 내용은 Advanced Level - Test Manager Syllabus [ISTQB-AL-TM]에서 설명되어 있다.

 

TAE는 도구 평가 및 선택 프로세스 전체에 참여하지만, 특히 다음과 같은 활동에 특별한 기여를 할 것이다:

• 조직적 성숙도 평가 및 테스트 도구 지원 기회 식별
• 테스트 도구 지원을 위한 적절한 목표 평가
• 잠재적으로 적합한 도구에 대한 정보 식별 및 수집
• 목표와 프로젝트 제약 조건에 대한 도구 정보 분석
• 견고한 사업 케이스를 기반으로 비용 대비 이점 비율 추정
• 적절한 도구에 대한 권장 사항 제시
• 도구의 SUT 구성 요소와의 호환성 식별

기능적인 테스트 자동화 도구는 종종 자동화 프로젝트에서 마주치는 모든 기대치나 상황을 충족시킬 수 없다. 다음은 이러한 유형의 문제의 몇 가지 예시입니다(완전한 목록은 아닙니다):

찾기	예시	가능한 해결책
- 도구의 인터페이스는 이미 존재하는 다른 도구와 작동하지 않는다.	- 테스트 관리 도구가 업데이트되어 연결 인터페이스가 변경되었다. - 사전 판매 지원에서 제공된 정보가 잘못되어 모든 데이터를 보고 도구로 전송할 수 없다.	- 업데이트 전에 릴리스 노트를 주의깊게 확인하고, 대규모 마이그레이션 전에 프로덕션으로의 마이그레이션 전에 테스트를 진행한다. - 실제 시스템 사용 사례를 활용한 도구의 현장 데모를 얻는다. - 도구 제공 업체 및/또는 사용자 커뮤니티 포럼에서 지원을 요청한다.
- 일부 시스템 테스트 대상(SUT)의 종속성이 테스트 도구에서 지원하지 않는 다른 종속성으로 변경될 경우, 테스팅 과정에서 다양한 도전과 문제가 발생할 수 있다.	- 개발 부서는 최신 버전의 Java로 업데이트했다.	- 개발 및 테스트 환경의 업그레이드와 테스트 자동화 도구의 동기화를 맞추는것이 좋다.
- GUI의 객체가 캡처되지 않는다.	- 객체는 보이지만 테스트 자동화 도구가 상호 작용할 수 없다.	- 개발 시 잘 알려진 기술이나 객체만 사용하도록 노력한다. - 테스트 자동화 도구를 구매하기 전에 시제 프로젝트를 진행한다. - 개발자들이 객체에 대한 표준을 정의하도록 한다.
- 도구가 매우 복잡하다.	- 해당 도구는 많은 기능을 가지고 있지만 그 중 일부만 사용될 것이다.	- 도구 바에서 원치 않는 기능을 제거하여 기능 세트를 제한하는 방법을 찾으세요. - 필요에 맞는 라이선스를 선택하세요. - 필요한 기능에 더 집중된 대체 도구를 찾아보세요.
- 다른 시스템과 충돌	- 다른 소프트웨어를 설치한 후에는 테스트 자동화 도구가 더 이상 작동하지 않거나 그 반대의 경우가 발생한다.	- 설치하기 전에 릴리스 노트나 기술적 요구 사항을 확인한다. - 공급업체로부터 다른 도구에 영향을 미치지 않을 것이라는 확인을 받는다. - 사용자 커뮤니티 포럼에서 의견을 확인한다.
- SUT(SUT: 시스템 테스트 대상)에 영향을 미친다.	- 테스트 자동화 도구 사용 중 또는 사용 후에 SUT가 다르게 반응하는 경우가 발생한다 (예: 응답 시간이 더 오래 걸림).	- SUT를 변경하지 않아도 되는 도구를 사용한다 (예: 라이브러리 설치 등).
- 소스 코드에 대한 접근	- 테스트 자동화 도구가 소스 코드의 일부를 변경할 수 있다.	- 소스 코드를 변경하지 않아도 되는 도구를 사용한다. (예: 라이브러리 설치 등).
- 자원 제한 (주로 임베디드 환경)	- 테스트 환경에는 한정된 자원이나 리소스가 있거나 (예: 메모리 등) 자원이 부족할 수 있다.	- 릴리스 노트를 확인하고 도구 제공업체와 환경에 대해 이야기하여 이로 인한 문제가 발생하지 않도록 확인한다. - 사용자 커뮤니티 포럼에서 의견을 확인한다.
- 업데이트	- 업데이트가 모든 데이터를 이전하지 않거나 기존 자동화된 테스트 스크립트, 데이터 또는 구성을 손상시킬 수 있습니다. - 업그레이드를 위해 다른(더 나은) 환경이 필요하다.	- 업데이트를 테스트 환경에서 시도하고, 공급업체로부터 마이그레이션이 잘 작동할 것임을 확인한다. - 업데이트 사전 요구사항을 읽고, 해당 업데이트가 수고를 할만한 가치가 있는지 판단한다. - 사용자 커뮤니티 포럼에서 지원을 요청한다.
- 보안	- 테스트 자동화 도구가 테스트 자동화 엔지니어에게 이용 불가능한 정보를 요구한다.	- 테스트 자동화 엔지니어가 접근할 수 있도록 권한을 부여해야 한다.
- 다른 환경과 플랫폼 간의 비호환성	- 테스트 자동화가 모든 환경/플랫폼에서 작동하지 않는다.	- 도구 독립성을 극대화하기 위해 자동화된 테스트를 구현하여 여러 도구를 사용하는 비용을 최소화한다.

 

2.3 테스트 가능성과 자동화를 위한 설계

시스템 테스트 가능성(SUT testability)은 SUT(Software Under Test)의 다른 기능들의 설계 및 구현과 병렬적으로 디자인되고 구현되어야 한다. 이는 소프트웨어 아키텍트에 의해 수행될 수 있다(테스트 가능성은 시스템의 비기능적 요구사항 중 하나일 뿐이기 때문이다). 그러나 종종 이는 테스트 자동화 엔지니어(TAE)와 함께 혹은 그들의 참여를 통해 수행된다.

 

테스트 가능성을 위한 디자인은 여러 부분으로 구성된다:

• 관찰성(Observability): SUT는 시스템에 대한 통찰력을 제공하는 인터페이스를 제공해야 한다. 테스트 케이스는 이러한 인터페이스를 사용하여 예상 동작과 실제 동작이 일치하는지 확인할 수 있다.
• 제어 가능성(Controlability): SUT는 SUT에 대해 동작을 수행하는 데 사용할 수 있는 인터페이스를 제공해야 한다. 이는 UI 요소, 함수 호출, 통신 요소(예: TCP/IP 또는 USB 프로토콜), 물리적 스위치의 경우 전자 신호 등이 될 수 있다.
• 명확하게 정의된 아키텍처: 테스트 가능성을 위한 디자인의 세 번째 중요한 부분은 모든 테스트 레벨에서 제어와 가시성을 제공하는 명확하고 이해하기 쉬운 인터페이스를 제공하는 아키텍처이다.

 

테스트 자동화 엔지니어(TAE)는 SUT가 효과적이고(올바른 영역을 테스트하고 중요한 버그를 발견하는) 효율적인(너무 많은 노력을 들이지 않는) 방식으로 테스트될 수 있는 방법을 고려한다. 특정 소프트웨어 인터페이스가 필요한 경우, 이를 TAE가 명시하고 개발자가 구현해야 한다. 테스트 가능성을 정의하고 필요한 경우 추가 소프트웨어 인터페이스를 프로젝트 초기에 정의하는 것이 중요하다. 이렇게 하면 개발 작업을 계획하고 예산을 산정할 수 있다.

 

테스트를 지원하는 몇 가지 소프트웨어 인터페이스 예시는 다음과 같다:

• 현대 스프레드시트의 강력한 스크립팅 기능.
• 스텁(Stub) 또는 목(Mock)을 적용하여 아직 사용할 수 없거나 구매 비용이 너무 높은 소프트웨어나 하드웨어(예: 전자 금융 거래, 소프트웨어 서비스, 전용 서버, 전자 보드, 기계 부품 등)를 모사하여 해당 특정 인터페이스가 없는 상태에서 소프트웨어를 테스트할 수 있다.
• 소프트웨어 인터페이스(또는 스텁과 드라이버)를 사용하여 오류 조건을 테스트할 수 있다. 예를 들어 내부 하드 디스크 드라이브(HDD)를 갖춘 장치를 고려해볼때 이 HDD를 제어하는 소프트웨어(드라이버)는 HDD의 고장이나 소모를 테스트해야 한다. 하지만 실제 HDD의 고장을 기다리는 것은 매우 효율적이지 않다(또는 신뢰성이 떨어집니다). 결함이 있는 또는 느린 HDD를 시뮬레이션하는 소프트웨어 인터페이스를 구현하여 드라이버 소프트웨어가 올바르게 작동하는지 확인할 수 있다(예: 오류 메시지 제공, 재시도).
• UI가 아직 준비되지 않은 경우에도 SUT를 테스트하기 위해 대체 소프트웨어 인터페이스를 사용할 수 있다(실제로 이 접근 방식이 더 나은 방법으로 간주된다). 기술 시스템의 임베디드 소프트웨어는 종종 장치 내의 온도를 모니터링하고 온도가 특정 수준을 초과할 때 냉각 기능을 시작해야 할 필요가 있다. 하지만 하드웨어를 사용하지 않고도 소프트웨어 인터페이스를 통해 온도를 지정하여 이를 테스트할 수 있다.
• 상태 전이 테스트는 SUT의 상태 동작을 평가하는 데 사용된다. SUT가 올바른 상태에 있는지 확인하는 방법 중 하나는 해당 목적으로 설계된 사용자 정의 소프트웨어 인터페이스를 통해 쿼리하는 것이다(하지만 이 방법에는 위험이 따를 수 있으며, 섹션 2.1의 침입 수준을 참고).

 

자동화를 위한 디자인은 다음과 같은 사항을 고려해야 한다:

• 기존 테스트 도구와의 호환성을 초기에 확립해야 한다.
• 테스트 도구의 호환성 문제는 중요하며, 중요한 기능의 테스트를 자동화하는 능력에 영향을 미칠 수 있다(예: 그리드 컨트롤과의 호환성이 없으면 해당 컨트롤을 사용하는 모든 테스트를 방지할 수 있다).
• 솔루션은 프로그램 코드 개발과 API 호출을 필요로 할 수 있다.

 

테스트 가능성에 대한 디자인은 좋은 테스트 자동화 접근 방식에 있어서 극히 중요합다. 또한 수동 테스트 실행에도 이로운 효과를 가져올 수 있다.