728x90
반응형
키워드
- API 테스팅
- CLI 테스팅
- GUI 테스팅
- 시스템 언더 테스트
- 테스트 자동화 아키텍처
- 테스트 자동화 프레임워크
- 테스트 자동화 전략
- 테스트 자동화
- 테스트 스크립트
- 테스트웨어
테스트 자동화 소개 및 목적에 대한 학습 목표
- 1.1 테스트 자동화의 목적
- ALTA-E-1.1.1 (K2) 테스트 자동화의 목적, 장단점 및 한계를 설며할 수 있다.
- 1.2 테스트 자동화의 성공 요인
- ALTA-E-1.2.1 (K2) 테스트 자동화 프로젝트의 기술적 성공 요인을 식별할 수 있다.
1.1 테스트 자동화의 목적
- 소프트웨어 테스트에서 테스트 자동화(자동화된 테스트 실행을 포함)는 다음 중 하나 이상의 작업을 수행한다.
- 목적에 맞는 소프트웨어 도구를 사용하여 테스트 사전 조건을 제어 및 설정한다.
- 테스트 실행
- 예측 결과와 실제 결과를 비교한다.
- 좋은 실천 방법은 테스트에 사용되는 소프트웨어를 SUT(System Under Test) 자체와 분리하여 간섭을 최소화하는 것이다. 예외적인 경우로는, 테스트 소프트웨어를 SUT에 배포해야하는 임베디드 시스템과 같은 예외도 있다.
- 테스트 자동화는 SUT 및 환경의 다른 버전에서 많은 테스트 케이스를 일관되고 반복적으로 실행하는데 도움이 될것으로 예상된다. 그러나 테스트 자동화는 인간과 상호작용 없이 테스트 스위트를 실행하는 메커니즘 이상이다. 이것은 테스트웨어를 디자인하는 프로세스를 포함한다.
- 소프트웨어
- 문서
- 테스트 케이스
- 테스트 환경
- 테스트 데이터
- 테스트 웨어는 다음과 같은 테스트 활동에 필요하다.
- 자동화된 테스트 케이스 구현
- 자동화된 테스트 실행 모니터링 및 제어
- 자동화된 테스트 결과 해석, 보고 및 기록
- 테스트 자동화는 SUT와 상호작용하는 다양한 벙법이 있다.
- SUT의 클래스, 모듈 또는 라이브러리의 공개 인터페이스를 통해 테스트(API 테스트)
- SUT의 사용자 인터페이스를 통해 테스트(예: GUI 테스트 또는 CLI 테스트)
- 서비스 또는 프로토콜을 통한 테스트
- 테스트 자동화의 목표는 다음과 같다.
- 테스트 효율성 향상
- 더 넓은 기능 커버리지 제공
- 총 테스트 비용 감소
- 수동 테스터가 수행할 수 없는 테스트 수행
- 테스트 실행 기간 단축
- 테스트 빈도 증가/테스트 사이클에 필요한 시간 감소
- 테스트 자동화의 장점은 다음과 같다.
- 더 많은 테스트를 빌드 당 실행할 수 있음
- 수동으로 수행할 수 없는 테스트(실시간, 원격, 병력 테스트)를 만들 수 있음
- 테스트가 더 복잡해질 수 있음
- 테스트 실행 속도가 빨라짐
- 테스트 운영자의 실수에 영향을 덜 받음
- 테스팅 리소스를 더 효율적으로 사용할 수 있음
- 소프트웨어 품질에 대한 빠른 피드백 제공
- 시스템 신뢰성 향상(반복성, 일관성)
- 일관성 향상
- 테스트 자동화의 단점은 다음과 같다.
- 추가적인 비용이 발생함
- TAS를 설정하는 초기 투자가 필요함
- 추가 기술이 필요함
- 팀은 개발 및 자동화 기술을 갖추어야 함
- 지속적인 TAS 유지 보수가 필요함
- 테스트 대상을 실행하는 것보다 테스트 케이스를 자동화하는데 중점을 두어 테스팅 목표에 집중하지 못할 수 있음
- 테스트가 더 복잡해질 수 있음
- 자동화에 의해 추가적인 오류가 발생할 수 있음
- 테스트 자동화의 한계는 다음과 같다.
- 모든 수동 테스트를 자동화할 수 없음
- 자동화는 기계가 해석 가능한 결과만 확인할 수 있음
- 자동화는 자동화된 테스트 오라클에서 검증 가능한 실제 결과만 확인할 수 있음
- 탐색적 테스트의 대체로 사용할 수 없음
1.2 테스트 자동화에서의 성공 요인
- 다음의 성공 요인들은 이미 진행 중인 테스트 자동화 프로젝트에 적용되며, 따라서 프로젝트의 장기적인 성공에 영향을 미치는 인자에 초점이 맞춰져 있다. 테스트 자동화 프로젝트의 기초 단계에서 영향을 미치는 성공 요인은 고려되지 않는다.
- 테스트 자동화의 주요 성공 요인은 다음과 같다.
- 테스트 자동화 아키텍처(Test Automation Architecture, TAA)
테스트 자동화 아키텍처(TAA)는 소프트웨어 제품의 아키텍처와 매우 밀접하게 관련되어 있다. 아키텍처가 지원해야 할 기능 및 비기능 요구 사항이 명확해야 한다. 일반적으로 이러한 요구사항이 가장 중요한 것이다.
TAA는 일반적으로 유지 관리성, 성능, 학습 용이성을 고려하여 설계된다. (ISO/IEC 25000:2014에서 이와 다른 비기능적 특성에 대한 자세항 내용을 볼 수 잇따.) SUT(Software Under Test)의 아키텍처를 이해하는 소프트웨어 엔지니어를 참여시키는 것이 도움이 된다.
- SUT 테스트성(SUT Testability)
자동화된 테스트를 지원하는 테스트성을 갖춘 SUT(Software Under Test)을 설계해야 한다. GUI 테스트의 경우, SUT는 그래픽 인터페이스의 모양과 데이터를 가능한 분리해야 한다. API테스트의 경우, 더 많은 클래스, 모듈 또는 명령 줄 인터페이스가 테스트될 수 있도록 공개되어야 한다.
테스트할 수 있는 SUT의 부분을 우선적으로 대상으로 해야 한다. 일반적으로 테스트 자동화의 성공 요소는 자동화된 테스트 스크립트를 구현하기 쉬운 정도에 달려있다. 이러한 목표를 이루고 성공적인 프로포즈 오브 콘셉트를 제공하기 위해, 테스트 자동화 엔지니어(TAE)는 자동화로 쉽게 테스트할 수 있는 SUT 모듈 또는 구성 요소를 식별하고 이를 시작점으로 삼아야 한다.
- 테스트 자동화 아키텍처(Test Automation Architecture, TAA)
728x90
반응형
'[ISTQB]' 카테고리의 다른 글
[ISTQB CTAL TAE]Syllabus #3장 전반적인 테스트 자동화 아키텍처 (0) | 2023.08.24 |
---|---|
[ISTQB CTAL TAE]Syllabus #2장 테스트 자동화 준비 (0) | 2023.07.21 |
[ISTQB CTAL TAE]Syllabus #용어 (0) | 2023.02.24 |
[ISTQB CTFL]Syllabus #3장 오답노트 (0) | 2022.11.22 |
[ISTQB CTFL]Syllabus #2장 오답노트 (0) | 2022.11.22 |