테스트 자동화를 위한 준비
Keywords
testability, driver, level of intrusion, stub, test execution tool, test hook, test automation manager
2.1 SUT Factors influencing Test Automation
테스트 자동화에 영향을 미치는 SUT 요인들.
SUT와 그 환경의 맥락에 대해 평가를 할 때, 적절한 해결책을 식별하기 위해 테스트 자동화에 영향을 미치는 요인을 식별해야한다. 그것들에는 아래와 같은 내용들이 포함될 수 있다.
SUT interfaces
자동화된 테스트케이스는 SUT의 액션을 호출합니다. 이것을 위해서는 SUT는 SUT를 컨트롤할 수 있는 어떠한 인터페이스를 제공해야한다. 이것은 UI를 조작하는 것으로도 가능하지만, low-level 소프트웨어 인터페이스로도 가능하다. 게다가, 몇가지 케이스는 TCP/IP 혹은 USB나 어떠한 Messaging interface와 같은 커뮤니케이션 레벨의 인터페이스로도 가능해야한다.
SUT의 분해는 테스트 자동화가 여러가지 테스트 레벨에서 테스트가 가능하도록 한다. 어떤 특정 레벨에서의 테스트를 자동화하게 하는 것도 가능하지만, (컴포넌트 테스트, 시스템 테스트 등) 이것은 SUT가 그러한 방법을 적절하게 지원하는 경우에만 가능하다. 예를 들어 컴포넌트 레벨에서는 테스트에서 사용해야할 UI가 존재하지 않을 수 있다. 이 경우에는 다른 적절한 interface가 존재해야한다. (어떠한 테스트훅 같은 것)
Third party software
SUT는 종종 조직 내에서만 작성된 소프트웨어로 구성되어있지 않고 외부로부터 제공받는 소프트웨어도 포함되어있는 경우가 있다. 이러한 경우에는 이런 서드파티 소프트웨어 또한 테스트가 필요할 수 있다. 이렇게 된다면 API를 이용하는 등의 다른 테스트 자동화 도구가 필요할 수도 있다.
Level of Intrusion
여러 다른 테스트 자동화 방식은 여러가지의 침투(변경) 수준을 가지고 있다. 테스트 자동화를 위해 SUT를 많이 변경하는 경우에는 이러한 Level of intrusion이 높아진다. 테스트 자동화를 위한 전용 소프트웨어 인터페이스를 사용하면, 높은 수준의 변화가 필요한데, 기존의 UI 요소를 이용하면 낮은 수준의 변화가 필요한다. SUT의 하드웨어 요소(키보드, 마우스, 통신 인터페이스와 같은 것들) 을 이용하면 훨씬 더 높은 수준의 침입이 발생한다.
이러한 높은 수준의 변경사항은 에러(오류)를 발생시킬 리스크를 발생시킨다. TAS는 이러한 높은 수준의 변경으로 인하여 실패가 발생할 수는 있지만, 실제 시스템은 프로덕션환경에서 사용할 때 그러한 이슈가 발생할 가능성은 낮다. 높은 수준의 변경(침투) 상태로 테스트하는 것은, 일반적으로 테스트 자동화를 수행할 때 훨씬 더 간단한 해결책이 될 수 있다.
Different SUT Architectures
여러가지 SUT 아키텍쳐는 여러가지 테스트 자동화 솔루션이 필요할 수 있다. C++로 작성되고 COM 기술이 사용된 SUT와 파이썬으로 작성된 SUT에 대해서는 서로 다른 접근방법이 필요할 수 있다. 이렇게 다른 구조를 가진 SUT에 대해 같은 테스트 자동화 전략으로 핸들링할 수도 있겠지만, 이런 경우에 대해 각각의 전략으로 대응해야할 수도 있다.
Size and complexity of the SUT
현재 SUT의 규모와 복잡도를 고려하고 미래의 개발에 대해 계획을 세워야한다. 간단하고 작은 SUT에 복잡하고 매우 큰 테스트 자동화 접근방법은 적절하지 않을 수 있다. 간단한 접근 방법이 더 좋을 수 있다. 반대로 매우 크고 복잡한 SUT에 대해 작고 가벼운 테스트 자동화 방법 또한 적절하지 않을 수 있다. 물론 간혹 복잡한 SUT에 대해 간단한 방법이 통하는 경우도 있지만 그것은 일시적인 경우일 수 있다.
SUT를 조작가능할 때, 위 설명한 요소들을 이용해 테스트 자동화를 수행할 수 있긴 하지만, 대부분의 경우 SUT를 조작할 수 있기 전에 테스트 자동화에 대한 개발이 시작되어야 한다. 테스트 자동화가 일찍 개발이 시작되어야 자동화에 필요한 어떠한 Interface에 대해 테스트 자동화 엔지니어가 평가하고 요구할 수 있다.
심지어 SUT가 아직 존재하기 전이라도 테스트 자동화를 계획할 수 있다. 예를 들면,
- 기능 / 비기능 요구사항이 정해져있다면, 해당 요구사항에서 자동화 대상을 추려내고 이것을 테스트하는 방법에 대해 선택할 수 있다. 자동화 계획은 자동화 요구 사항을 식별해내고 테스트 자동화 전략을 결정하는 것을 포함한다.
- 아키텍쳐와 기술적 검토가 진행중이라면, 테스트를 위한 interface의 설계를 진행할 수 있다.
2.2 Tool Evaluation and Selection
어떠한 도구를 선택하고, 그것을 평가하는 프로세스는 전적으로 Test Automation Manager에게 권한이 있다. 그러나 TAE 또한 TAM에게 정보를 제공하고 평가와 선택하는 활동을 많이 수행하게 될 것이다. 도구 평가 및 선택 프로세스의 개념은 Foundation level에서 소개하고 있으며, 좀 더 자세한 사항은 AL-TM 과정에서 설명하고 있다.
TAE는 도구 평가 및 선정 프로세스에 전반적으로 참여하게 되지만, 그 중에서도 특히 다음의 작업에 참여하게 될 것이다.
- 조직의 성숙도 평가 및 테스트 도구 지원 기회 식별
- 테스트 도구의 적절한 목적 평가
- 잠재적으로 적합한 도구에 대한 정보 수집 및 식별
- 프로젝트의 목표와 제약사항에 대해 도구 분석
- 비즈니스 케이스에 기반한 비용 대비 이익 분석
- 적절한 툴에 대한 권장사항 제시
- SUT의 구성 요소와 호환되는지 식별
기능 테스트 자동화 도구는 종종 모든 기대치와 자동화 프로젝트에서 마주하게 되는 어떠한 상황들에 대해 충족시켜줄 수는 없다. 아래는 그러한 상황들의 예시이다.
| Finding | Examples | Possible Solutions |
|---|---|---|
| 이미 사용하고 있는 다른 툴과 같이 혼용할 수 없을 때. | - 테스트 매니지먼트 툴이 업데이트 되고 interface가 바뀌었을 때. - 기존에 확인한 정보가 잘못되었고, 리포팅 툴에 모든 데이터를 넣을 수 없을 때 | - 업데이트하기 전에 릴리즈 노트를 확인하고 프로덕션에 마이그레이션 하기 전에 마이그레이션 테스트에 주의를 기울인다. - 실제 SUT를 이용한 도구 시연회의 기회를 요구해라. - 벤더나 유저 커뮤니티로부터의 서포트를 찾아봐라 |
| 일부 SUT의 종속성이 테스트 도구가 지원하지 않는 것으로 변경되었을 때. | - 개발팀에서 신규 자바버전으로 올린 경우 | - 개발/테스트환경에 대해 업그레이드하고, 테스트 도구도 마찬가지로 동기화해라. |
| GUI상에서의 어떠한 요소에 대해 핸들링할 수 없을 때. | - 요소는 보이지만 테스트 자동화 툴이 해당 요소를 조작하지 못할 때. | - 잘 알려진 기술이나 객체를 사용한다. - 테스트 자동화 도구를 구매하기전에 체험판을 이용해라. - 개발자들에게 요소의 기준(혹은 식별자)을 정의하도록 해라. |
| 도구가 매우 복잡할 때. | - 도구가 매우 큰 기능을 가지고 있지만 그중 매우 부분만 사용될 때. | - 해당 도구에서 원하는 기능만 선택하고 나머지는 삭제하는 방법을 찾아라. - 요구사항에 부합하는 라이센스를 선택해라. - 좀 더 필요한 기능을 가진 다른 대체 도구를 찾아라. |
| 다른 시스템과 충돌할 때 | - 다른 소프트웨어를 설치한 후에, 테스트 자동화 도구가 더이상 동작하지 않거나 반대인 경우. | - 설치 전에 기술문서나 릴리즈 노트를 확인해라. - 업자로부터 다른 도구와 영향이 없을 것이라는 확인을 받아라. - 유저 커뮤니티에 질문해라 |
| SUT에 영향이 있을 때. | - 테스트 자동화 도구를 사용중이거나 사용 후에 SUT의 동작이 달라지는 경우 | - SUT의 변경이 필요하지 않은 도구를 사용해 라 |
| 코드로의 접근 | - 테스트 자동화 도구가 소스코드의 일부를 변경하려할 때. | - 소스코드를 변경시키지 않는 도구를 사용해라. |
| 제한적인 리소스 | - 테스트 환경이 어떠한 리소스가 부족하거나 리소스를 다 사용해버린 경우 | - 릴리즈 노트를 읽고 도구제공업자와 사용환경 문제가 없을지에 대해 논의해라. - 유저 커뮤니티에 질문해라. |
| 업데이트 | - 업데이트가 제대로 되지 않고 다른 모든 데이터나 스크립트, 설정값과 충돌나는 경우 - 업그레이드할 때 더 좋은 환경이 필요할 경우 | - 업자에게 마이그레이션이 제대로 될 것이랑 보장을 받고, 테스트환경에서 업그레이드를 시험해봐라. - 업데이트 전제사항을 확인하고 업데이트할만한 가치가 있을 지 결정해라. - 유저 커뮤니티로부터 서포트를 찾아라. |
| 보안 | - 테스트 자동화 도구가 테스트 자동화 엔지니어가 접근할 수 없는 정보를 요구할 때. | - 테스트 자동화 엔지니어에게 해당 권한을 부여해라. |
| 다른 환경과 플랫폼 간의 비호환성 | - 모든 환경과 플랫폼에서 테스트 자동화가 동작하지 않을 때 | - 자동화된 테스트를 직접 구현하고 다른 여러가지 도구로부터 독립적인 툴을 만들고 비용을 최소화해라. |
2.3 Design for Testability and Automation
SUT의 테스트 가능성 (SUT를 제어하고 모니터링할 수 있도록 테스트를 지원하는 소프트웨어 인터페이스의 가용성)은 SUT의 다른 기능의 설계 및 구현과 병행하여 설계되어야한다. 이것은 소프트웨어 설계자가 수행할 수 있지만 테스트 자동화 엔지니어가 함께 참여하여 수행할 수도 있다.
테스트 가능성을 위한 설계는 다음과 같이 구성된다.
- 관찰 가능성 : SUT는 시스템 내부를 확인할 수 있는 인터페이스를 제공해야한다. 테스트 케이스는 이러한 인터페이스를 이용하여 실제 동작결과가 기대한 결과와 동일한지 체크할 수 있어야 한다.
- 제어 가능성 : SUT는 SUT가 직접 작업을 수행할 수 있도록 하는 인터페이스를 제공해야한다. 그것은 UI요소가 될 수도 있고, 어떠한 함수를 호출할 수 있고, 통신 프로토콜이나 전자적 신호가 될 수도 있다.
- 명확히 정의된 아키텍처 : 모든 테스트 수준에서 제어 및 가시성을 제공하는 매우 명확하고 알기쉬운 인터페이스를 가진 아키텍쳐를 가지고 있어야 한다.
TAE는 SUT를 효과적(올바른 영역을 테스트하고 중요한 버그를 찾는)이고 효율적(너무 많은 노력을 들이지 않고)으로 테스트할 수 있는 방법을 고려해야한다. 특정 소프트웨어 인터페이스가 필요한 경우, 그것들은 TAE에 의해 명시되어야 하며, 개발자에 의해 구현되어야한다. 프로젝트 초기에 테스트 가능성을 정의하고 필요한 경우 추가적인 소프트웨어 인터페이스를 정의하는 것이 중요하다. 이렇게 함으로써 개발 작업을 계획하고 예산을 산정할 수 있다.
테스트를 도와주는 몇가지 소프트웨어 인터페이스의 예시는 아래와 같다.
- 현대적인 스프레드시트의 강력한 스크립팅 기능
- 사용할 수 없거나 구매하기에 너무 비싼 소프트웨어 및/또는 하드웨어(예: 전자 금융 거래, 소프트웨어 서비스, 전용 서버, 전자 보드, 기계 부품)를 흉내내기 위해 스텁 또는 목 객체를 적용하면 해당 특정 인터페이스가 없어도 소프트웨어를 테스트할 수 있다.
- 소프트웨어 인터페이스(또는 스텁 및 드라이버)를 사용하여 오류 조건을 테스트할 수 있다. 내부 하드 디스크 드라이브(HDD)가 있는 장치를 고려해봐라. 이 HDD를 제어하는 소프트웨어(드라이버라고 함)는 HDD의 고장 또는 마모를 테스트해야 합니다. 이를 HDD가 고장날 때까지 기다리는 것은 매우 효율적(또는 신뢰할 수 있)이지 않다. 결함이나 느린 HDD를 모사하는 소프트웨어 인터페이스를 구현함으로써 드라이버 소프트웨어가 올바르게 작동하는지 확인할 수 있다(예: 오류 메시지 제공, 다시 시도).
- 아직 UI가 없는 SUT를 테스트할 때 대안적인 소프트웨어 인터페이스를 사용할 수 있다. (이는 종종 더 나은 접근 방식으로 간주된다). 임베디드 소프트웨어는 종종 장치의 온도를 모니터링하고 온도가 특정 수준을 초과할 때 냉각 기능을 시작해야 할 수 있습니다. 이를 하드웨어 없이 소프트웨어 인터페이스를 사용하여 테스트할 수 있다.
- 상태 전이 테스트는 SUT의 상태 동작을 평가하는 데 사용된다. SUT가 올바른 상태에 있는지 확인하는 한 가지 방법은 이를 위해 특별히 설계된 사용자 정의 소프트웨어 interface를 통해 상태를 죄해홉는 것이다. (이것은 리스크를 야기할 수 있다.)
자동화를 위한 설계는 다음을 고려해야 한다.
- 기존 테스트 도구와의 호환성을 초기에 확립해야 한다.
- 테스트 도구 호환성 문제는 중요하다. 중요한 기능의 테스트 자동화 능력에 영향을 줄 수 있다. (예: 그리드 컨트롤과의 호환성 문제로 인해 해당 컨트롤을 사용하는 모든 테스트가 영향을 받을 수 있다.).
- 솔루션에는 프로그램 코드 개발 및 API 호출이 필요할 수 있습니다.
테스트 가능성에 대한 설계는 우수한 테스트 자동화 접근 방식을 위해 극히 중요하며, 수동 테스트 실행에도 도움이 될 수 있다.
ref.
- ISTQB CTAL TAE Syllabus
