Keyword
verification
7.1 Verifying Automated Test Environment Components
자동화 테스트 환경 구성요소 검증
테스트 자동화 팀은 자동화 테스트 환경이 예상대로 동작하는 지 확인해야한다. 이러한 확인 작업은 자동화 테스트를 시작하기 전에 수행된다.
자동화 테스트 환경의 구성 요소를 검증하기 위해 수행할 수 있는 여러 단계가 있다. 각각의 단계는 아래와 같이 설명할 수 있다.
Test tool installation, setup, configuration, and customization
TAS는 여러 구성 요소로 이루어져있다. 이러한 구성 요소 각각은 신뢰할 수 있고 반복 가능한 성능을 보장하기 위해 고려되어야한다. TAS의 핵심은 실행 가능한 구성 요소, 해당 기능 라이브러리 및 지원 데이터 및 구성 파일이다. TAS 구성 과정은 자동 설치 스크립트 사용부터 수동으로 파일을 해당 폴더에 배치하는 것까지 다양하다. 테스트 도구는 운영 체제 및 기타 애플리케이션과 마찬가지로 서비스 팩이 자주 배포되거나 특정 SUT 환경과의 호환성을 보장하기 위해 선택적 또는 필수 부가 기능이 있을 수 있다.
중앙 레포지토리에서 자동으로 설치 (또는 복사)하는 것은 장점이 있다. 이렇게하면 다양한 SUT에서 동일한 버전의 TAS와 동일한 구성으로 테스트가 수행되었음을 보장할 수 있다. TAS 업그레이드는 레포지토리를 통해 수행될 수 있다. 레포지토리 사용 및 TAS의 새 버전으로 업그레이드하는 프로세스는 표준 개발 도구와 동일해야한다.
Test scripts with known-passes and failures
알려진 성공 테스트 케이스가 실패할 때, 이것은 근본적인 문제가 있음을 즉시 나타내며 가능한 빨리 수정해야한다. 반대로 실패해야할 테스트케이스가 성공할 때는 제대로 동작하지 않은 구성 요소를 식별해야한다. 로그 파이로가 성능 메트릭 생성의 정확성을 확인하는 것이 중요하며, 테스트 케이스/스크립트의 자동 설정 및 해체도 확인해야한다. 다양한 테스트 유형 및 수준의 몇 가지 테스트를 실행해보는 것도 도움이 된다. 이는 프레임워크 수준에서도 수행되어야 한다.
Repeatability in setup/teardown of the test environment
TAS는 다양한 시스템과 서버에 구현된다. 각 환경에서 TAS가 제대로 동작하도록 보장하려면 특정 환경에서 TAS를 로드 및 언로드하는 체계적인 접근 방식이 필요하다. TAS의 빌드 및 재빌드가 여러 환경에서 동일하게 동작하는지 확인이 된다면, 성공적으로 수행된 것이다. TAS의 구성 요소의 구성 관리는 주어진 구성이 신뢰할 수 있게 생성될 수 있도록 보장한다.
Configuration of the test environment and components
TAS를 구성하는 다양한 구성 요소를 이해하고 문서화함으로써 SUT환경이 변경될 때 TAS의 어떤 측면이 영향을 받거나 변경이 필요한지에 대한 필요한 지식을 제공한다.
Connectivity against internal and external systems/interface
TAS가 특정 SUT환경에 설치되고 SUT에 실제로 사용되기 전에 내부 및 외부 시스템, 인터페이스 등에 대한 연결성을 확인하기 위해 일련의 검사 또는 사전 조건을 설정해야한다. 자동화를 위한 사전 조건을 설정하는 것은 TAS가 올바르게 설치되고 구성되었음을 보장하는데에 필수적이다.
Intrusiveness of automated test tools
TAS는 종종 SUT와 밀접하게 연결된다. 이는 특히 GUI 수준의 상호작용과 관련하여 높은 호환성을 갖도록 설계되었기 때문이다. 그러나 이러한 밀접한 통합은 부정적인 영향을 미칠 수 있다. 여기에는 TAS가 SUT환경 내에 있을 때 SUT가 다르게 동작하거나, 수동으로 사용할 때와 다른 동작을 하거나, TAS를 SUT에 대해 실행할 때 SUT 성능이 영향을 받을 수 있다.
자동화 테스트의 접근 방식에 따라 침투 수준이 달라진다. 예를 들어
- 외부 인터페이스에서 SUT와 상호작용할 때 침투 수준은 매우 낮다. 외부 인터페이스는 전자 신호, USB 장치의 USB신호일 수도 있다. 이 접근 방식은 최종 사용자가 가장 잘 시뮬레이션된다. 이 접근 방식에서는 테스트 목적을 위해 SUT의 소프트웨어가 전혀 변경되지 않는다. SUT의 동자고가 타이밍은 테스트 접근 방식에 영향을 받지 않는다. 이러한 방식으로 SUT와 상호작용하는 것은 매우 복잡할 수 있다. 전용 하드웨어가 필요할 수 있으며, SUT와 상호작용하기 위해 하드웨어 설명 언어가 필요할 수 있다. 소프트웨어 전용 시스템의 경우 이러한 접근 방식은 일반적이지 않지만, 임베디드 소프트웨어가 있는 제품의 경우는 일반적이다.
- GUI 수준에서 SUT와 상호작용할 때, SUT환경은 UI명령을 주입하고 테스트케이스에 필요한 정보를 추출하기 위해 조정된다. SUT 동작은 직접적으로 변경되지는 않지만, 타이밍이 영향을 받아 동작에 영향을 미칠 수 있다. 침투 수준은 이전 경우보다 높지만, 이러한 방식으로 SUT와 상호작용하는 것은 덜 복잡하다. 상용 도구를 사용하여 이러한 유형의 자동화를 수행할 수 있다.
- SUT와의 상호작용은 소프트웨어의 테스트 인터페이스를 통해 수행되거나 소프트웨어에서 이미 제공하는 기존 인터페이스를 사용하여 수행될 수 있다. 이러한 인터페이스(API)의 가용성은 테스트 가능성 설계의 중요한 부분이다. 이 경우 침투 수준이 상당히 높을 수 있다. 자동화된 테스트는 최종 사용자가 전혀 사용하지 않을 수 있는 인터페이스를 사용하거나 실제 환경과 다른 컨텍스트에서 인터페이스를 사용할 수 있다. 반면, 인터페이스(API)를 통해 자동화된 테스트를 수행하는 것은 매우 쉽고 저렴하다. 테스트 인터페이스를 통해 SUT를 테스트하는 것은 잠재적인 위험을 이해하는 한 좋은 접근 방식이 될 수 있다.
높은 수준의 침투성은 증거가 없는 실제 사용환경에서의 테스트를 하는 동안 명백하지 않은 실패를 발생시킬 수 있다. 이것이 자동화된 테스트에서 발생한다면, 테스트 자동화 솔루션에 대한 신뢰가 크게 떨어질 수 있다. 개발자는 자동화된 테스트에서 식별된 실패가 가능한 경우 수동으로 먼저 재현되어 분석을 지원할 수 있도록 요구할 수 있다.
Framework Component Testing
일반적인 소프트웨어 개발 프로젝트와 마찬가지로, 자동화된 프레임워크 구성 요소는 개별적으로 테스트 및 검증되어야 한다. 여기에는 기능적 및 비기능적인 테스트 (성능, 자원 활용, 사용성)이 포함될 수 있다. 예를 들어 GUI 시스템의 객체 검증을 제공하는 구성 요소는 객체 검증이 올바르게 동작하는지 확인하기 위해, 광범위한 객체 클래스를 테스트해야한다. 마찬가지로, 오류 로그와 보고서는 자동화 상태와 SUT 동작에 관한 정확한 정보를 제공해야한다. 비기능적 테스트의 예로는 프레임워크 성능 저하, 메모리 누수와 같은 문제를 나타낼 수 있는 시스템 자원 활용 이해 등이 포함될 수 있다. 프레임 워크 내부 및 또는 외부 구성 요소의 상호 운용성도 포함된다.
7.2 Verifying the Automated Test Suite
자동화 테스트 스위스의 검증
자동화 테스트 스위트는 완전성, 일관성, 올바른 동작을 위해 검증되어야한다. 자동화 테스트 스위트가 언제든지 정상적으로 동작하는지 확인하거나 사용 가능성을 판단하기 위해 다양한 검증 검사를 적용할 수 있다.
자동화 테스트 스위트를 검증하기 위해 수행할 수 있는 여러 단계가 있다.
- 알려진 성공 및 실패 테스트 스크립트 실행
- 테스트 스위트 점검
- 프레임워크의 새로운 기능에 중점을 둔 새로운 테스트 검증
- 테스트의 반복성 고려
- 자동화 테스트 스위트에 충분한 검증 포인트가 있는지 확인
Execution test scripts with known passes and failures
알려진 성공 테스트 케이스가 실패할 경우, 근본적인 문제가 있음을 즉시 알 수 있으며 가능한 빨리 수정해야한다. 반대로 테스트 스위트가 실패해야할 때 성공할 경우, 제대로 동작하지 않은 테스트 케이스를 식별해야한다. 로그 파일, 성능 데이터, 테스트 케이스 및 스크립트의 설정 및 해체가 올바르게 생성되는지 확인하는 것이 중요하다. 다양한 테스트 유형 및 수준의 몇가지 테스트를 실행하는 것이 도움이 된다.
Checking the test suite
테스트 스위트의 완전성 (테스트 케이스 모두 예상 결과를 가지고 있고, 테스트 데이터가 존재하는지) 및 프레임워크와 SUT와의 올바른 버전을 확인한다.
Verifying new tests that focus on new feature of the framework
TAS의 새로운 기능이 실제로 테스트 케이스에서 처음 사용될 때, 해당 기능이 올바르게 동작하는지 확인하고 면밀히 모니터링해야한다.
Considering repeatability of tests
테스트를 반복할 때, 테스트 결과/판결이 항상 동일해야한다. 신뢰할 수 없는 결과를 제공하는 테스트 케이스 는 활성 자동화 테스트 스위트에서 제거하고 별도로 분석하여 근본 원인을 찾아야한다. 그렇지 않으면 이러한 테스트 실행을 반복 분석하는 데 시간을 소비하게된다.
간헐적인 실패는 분석이 필요하다. 문제는 테스트 케이스 자체, 프레임 워크 또는 SUT에 있을 수 있다. 로그 파일 분석(테스트 케이스, 프레임 워크, SUT)를 통해 문제의 근본 원인을 식별할 수 있다. 디버깅도 필요할 수 있다. 근본 원인을 찾기 위해 테스트 분석가, 소프트웨어 개발자 및 도메인 전문가의 지원이 필요할 수 있다.
Checking that there are enough verification points in the autmated test suite and/or test cases
자동화 테스트 스위트가 실행되었고 예상 결과를 달성했음을 검증할 수 있어야한다. 테스트 스위트 및 테스트 케이스가 예상대로 실행되었음을 보장하기 위해 증거를 제공해야한다. 이러한 증거는 각 테스트 케이스의 시작과 끝에서 로깅, 완료된 각 테스트 케이스의 실행 상태 기록, 사후 조건 달성 여부 검증 등을 포함할 수 있다.
ref
- ISTQB AL TAE Syllabus
