상위 질문
타임라인
채팅
관점
테스트 자동화
위키백과, 무료 백과사전
Remove ads
소프트웨어 테스트에서 테스트 자동화(test automation)는 테스트 대상 소프트웨어와는 별개의 소프트웨어를 사용하여 테스트 실행을 제어하고 실제 결과와 예측된 결과를 비교하는 것이다.[1] 테스트 자동화는 이미 진행 중인 공식화된 테스트 프로세스에서 반복적이지만 필요한 일부 작업을 자동화하거나 수동으로 수행하기 어려운 추가 테스트를 수행할 수 있다. 테스트 자동화는 지속적 전달 및 지속적 테스트에 매우 중요하다.[2]
Remove ads
일반적인 접근법
테스트 자동화에는 여러 가지 접근법이 있지만, 다음은 널리 사용되는 일반적인 접근법이다.
- 그래픽 사용자 인터페이스 테스트. 키 입력 및 마우스 클릭과 같은 사용자 인터페이스 이벤트를 생성하고 사용자 인터페이스에서 발생하는 변경 사항을 관찰하여 프로그램의 관찰 가능한 동작이 올바른지 확인하는 테스트 프레임워크.
- API 기반 테스트. 애플리케이션에 대한 프로그래밍 인터페이스를 사용하여 테스트 중인 동작을 확인하는 테스트 프레임워크. 일반적으로 API 기반 테스트는 애플리케이션 사용자 인터페이스를 완전히 건너뛴다. 또한 클래스, 모듈 또는 라이브러리에 대한 (일반적으로) 공용 인터페이스를 다양한 입력 인수로 테스트하여 반환되는 결과가 올바른지 확인할 수도 있다.
기타 접근법
요약
관점
모델 기반 테스트
테스트 케이스를 자동으로 생성하는 한 가지 방법은 테스트 케이스 생성을 위해 시스템 모델을 사용하는 모델 기반 테스트이지만, 이를 위한 다양한 대체 방법론에 대한 연구가 계속되고 있다. 어떤 경우에는 모델 기반 접근 방식을 통해 비기술적 사용자도 일반 영어로 자동화된 비즈니스 테스트 케이스를 만들 수 있으므로 여러 운영 체제, 브라우저 및 스마트 장치에 맞게 구성하는 데 어떤 종류의 프로그래밍도 필요하지 않다.[3]
회귀 테스트
일부 소프트웨어 테스트 작업(예: 광범위한 하위 수준 인터페이스 회귀 테스트)은 수동으로 수행하기에 힘들고 시간이 많이 소요될 수 있다. 또한 수동 접근 방식은 특정 유형의 결함을 찾는 데 항상 효과적이지 않을 수 있다. 테스트 자동화는 이러한 유형의 테스트를 효과적으로 수행할 가능성을 제공한다.
자동화된 테스트가 개발되면 신속하고 반복적으로 여러 번 실행될 수 있다. 이는 유지보수 수명이 긴 소프트웨어 제품의 회귀 테스트를 위한 비용 효율적인 방법이 될 수 있다. 애플리케이션의 수명 주기 동안 사소한 패치조차도 이전에 작동하던 기존 기능이 손상될 수 있다.
API 테스트
이 부분의 본문은 API 테스트입니다.API 테스트는 소프트웨어 테스터들이 GUI 구현과 독립적으로 요구 사항을 검증하고, 일반적으로 개발 초기 단계에서 테스트하며, 테스트 자체도 깔끔한 코드 원칙, 특히 단일 책임 원칙을 준수하는지 확인하는 데 널리 사용되고 있다. 이는 통합 테스트의 일부로 API를 직접 테스트하여 기능성, 신뢰성, 성능 및 보안에 대한 기대치를 충족하는지 확인하는 것을 포함한다.[4] API에는 GUI가 없으므로 API 테스트는 메시지 계층에서 수행된다.[5] API가 애플리케이션 로직의 기본 인터페이스 역할을 할 때 API 테스트는 중요하게 간주된다.[6]
그래픽 사용자 인터페이스 (GUI) 테스트
이 부분의 본문은 그래픽 사용자 인터페이스 테스트입니다.많은 테스트 자동화 도구는 기록 및 재생 기능을 제공하여 사용자가 대화식으로 사용자 작업을 기록하고 원하는 만큼 여러 번 재생하며 실제 결과를 예상 결과와 비교할 수 있도록 한다. 이 접근 방식의 장점은 소프트웨어 개발이 거의 또는 전혀 필요하지 않다는 것이다. 이 접근 방식은 그래픽 사용자 인터페이스를 가진 모든 애플리케이션에 적용할 수 있다. 그러나 이러한 기능에 의존하는 것은 주요 신뢰성 및 유지보수 문제를 야기한다. 버튼의 레이블을 변경하거나 창의 다른 부분으로 이동하면 테스트를 다시 기록해야 할 수 있다. 기록 및 재생은 또한 종종 관련 없는 활동을 추가하거나 일부 활동을 잘못 기록하기도 한다.
이러한 유형의 도구의 변형은 웹 사이트 테스트를 위한 것이다. 여기서 "인터페이스"는 웹 페이지이다. 그러나 이러한 프레임워크는 운영 체제 이벤트 대신 HTML을 렌더링하고 DOM 이벤트를 수신하기 때문에 완전히 다른 기술을 사용한다. 일반적으로 이 목적을 위해 헤드리스 브라우저 또는 셀레늄 웹 드라이버 기반 솔루션이 사용된다.[7][8][9]
이러한 유형의 테스트 자동화 도구의 또 다른 변형은 모바일 애플리케이션 테스트용이다. 모바일 폰에서 사용되는 다양한 크기, 해상도 및 운영 체제를 고려할 때 매우 유용하다. 이 변형의 경우, 모바일 장치에서 작업을 인스턴스화하고 작업 결과를 수집하기 위해 프레임워크가 사용된다.
또 다른 변형은 기록 및 재생을 사용하지 않는 스크립트 없는 테스트 자동화이지만, 대신 애플리케이션 모델을 구축한 다음 테스터가 테스트 매개변수와 조건을 단순히 삽입하여 테스트 케이스를 생성할 수 있도록 하여 스크립팅 기술이 필요하지 않다.
Remove ads
방법론
테스트 주도 개발
주로 유닛 테스트를 사용하는 테스트 자동화는 익스트림 프로그래밍 및 애자일 소프트웨어 개발의 핵심 기능으로, 테스트 주도 개발(TDD) 또는 테스트 우선 개발로 알려져 있다. 유닛 테스트는 코드가 작성되기 전에 기능을 정의하기 위해 작성될 수 있다. 그러나 이러한 유닛 테스트는 코딩이 진행되고, 문제가 발견되고, 코드가 리팩터링될 때 진화하고 확장된다.[10] 요구되는 모든 기능에 대한 모든 테스트가 통과될 때만 코드는 완성된 것으로 간주된다. 옹호자들은 이것이 수동 탐색으로 테스트되는 코드보다 더 안정적이고 비용이 적게 드는 소프트웨어를 생산한다고 주장한다. 코드 커버리지가 더 좋고, 폭포수 모델 개발 주기 끝에 한 번 실행되는 대신 개발 중에 지속적으로 실행되기 때문에 더 신뢰할 수 있는 것으로 간주된다. 개발자는 변경 즉시 결함을 발견하며, 이때 수정하는 것이 가장 저렴하다. 마지막으로, 유닛 테스트를 사용할 때 리팩터링이 더 안전하다. 코드를 코드 중복이 적고 동등한 동작을 가진 더 간단한 형태로 변환하는 것은 리팩터링된 코드가 유닛 테스트로 커버될 때 새로운 결함을 도입할 가능성이 훨씬 적다.
지속적 테스트
이 부분의 본문은 지속적 테스트입니다.지속적 테스트는 소프트웨어 릴리스 후보와 관련된 비즈니스 위험에 대한 즉각적인 피드백을 얻기 위해 소프트웨어 전달 파이프라인의 일부로 자동화된 테스트를 실행하는 프로세스이다.[11][12] 지속적 테스트의 경우 테스트 범위는 상향식 요구 사항 또는 사용자 스토리를 검증하는 것에서부터 전반적인 비즈니스 목표와 관련된 시스템 요구 사항을 평가하는 것까지 확장된다.[13]
고려 사항
테스트 자동화 구현 결정에 고려할 요소
무엇을 자동화할지, 언제 자동화할지, 심지어 자동화가 정말 필요한지 여부는 테스트(또는 개발) 팀이 내려야 하는 중요한 결정이다.[14] 52개의 실무자 출처와 26개의 학술 출처를 대상으로 한 다중음성 문헌 검토 결과, 테스트 자동화 결정에 고려해야 할 다섯 가지 주요 요소는 다음과 같다: 1) 테스트 대상 시스템(SUT), 2) 테스트 유형 및 수, 3) 테스트 도구, 4) 인적 및 조직적 주제, 5) 교차적 요소. 연구에서 가장 자주 식별된 개별 요소는 회귀 테스트의 필요성, 경제적 요인, SUT의 성숙도였다.[15]
고원 효과
자동화된 테스트의 재사용성은 소프트웨어 개발 회사에서 중요하게 여기지만, 이 속성은 단점으로도 볼 수 있다. 이는 반복적으로 실행되는 스크립트가 프레임워크를 넘어선 오류를 감지하지 못하게 되는 이른바 "살충제 역설"을 초래한다. 이러한 경우 수동 테스트가 더 나은 투자가 될 수 있다. 이러한 모호성은 프로젝트 요구사항과 특성을 고려하여 테스트 자동화 결정을 개별적으로 내려야 한다는 결론으로 다시 이어진다.
무엇을 테스트할 것인가
테스트 도구는 제품 설치, 테스트 데이터 생성, GUI 상호 작용, 문제 감지(테스트 오라클을 갖춘 파싱 또는 폴링 에이전트 고려), 결함 로깅 등과 같은 작업을 자동화하는 데 도움이 될 수 있으며, 반드시 종단 간 방식으로 테스트를 자동화할 필요는 없다.
테스트 자동화를 생각할 때 인기 있는 요구 사항을 계속 충족해야 한다.
- 플랫폼 및 OS 독립성
- 데이터 기반 기능(입력 데이터, 출력 데이터, 메타데이터)
- 보고서 사용자 지정(DB 데이터베이스 접근, 크리스탈 리포트)
- 쉬운 디버깅 및 로깅
- 버전 관리 친화적 - 최소한의 이진 파일
- 확장성 및 사용자 지정(다른 도구와 통합할 수 있는 개방형 API)
- 공통 드라이버 (예: 자바 개발 생태계에서는 Ant 또는 Maven 및 인기 있는 IDE를 의미한다.) 이를 통해 개발자 워크플로우와 테스트를 통합할 수 있다.
- 빌드 프로세스 및 배치 실행과의 통합을 위한 무인 테스트 실행 지원. 지속적 통합 서버에서 필요하다.
- 반송 메일과 같은 이메일 알림
- 분산 실행 환경 지원 (분산 테스트베드)
- 분산 애플리케이션 지원 (분산 SUT)
Remove ads
역할
테스트 자동화 도구
테스트 자동화 도구는 비용이 많이 들 수 있으며, 일반적으로 수동 테스트와 함께 사용된다. 테스트 자동화는 장기적으로, 특히 회귀 테스트에서 반복적으로 사용될 때 비용 효율적일 수 있다. 테스트 자동화에 적합한 후보는 애플리케이션의 일반적인 흐름에 대한 테스트 케이스이다. 이는 애플리케이션이 향상될 때마다 (회귀 테스트를 통해) 실행되어야 하기 때문이다. 테스트 자동화는 수동 테스트와 관련된 노력을 줄여준다. 자동화된 검사를 개발하고 유지 관리하며 테스트 결과를 검토하는 데는 수동 노력이 필요하다.
테스트 엔지니어
이 부분의 본문은 테스트 엔지니어입니다.자동화된 테스트에서 테스트 엔지니어 또는 소프트웨어 품질보증 담당자는 소프트웨어 코딩 능력을 갖추어야 한다. 테스트 케이스는 실행될 때 포함된 어설션에 따라 출력을 생성하는 소스 코드 형태로 작성되기 때문이다. 일부 테스트 자동화 도구는 코딩 대신 키워드로 테스트 작성을 허용하여 프로그래밍이 필요하지 않다.
Remove ads
다양한 수준에서의 테스트
테스트 자동화량을 결정하는 전략은 테스트 자동화 피라미드이다. 이 전략은 서로 다른 세분화 수준을 가진 세 가지 유형의 테스트를 작성할 것을 제안한다. 수준이 높을수록 작성할 테스트 양은 줄어든다.[16]
유닛, 서비스, 사용자 인터페이스 수준
- 튼튼한 기반으로서 유닛 테스트는 소프트웨어 제품에 견고성을 제공한다. 코드의 개별 부분을 테스트하면 테스트를 작성하고 실행하기 쉽다. 개발자는 각 스토리의 일부로 유닛 테스트를 작성하고 CI와 통합한다.[17]
- 서비스 계층은 사용자 인터페이스와는 별도로 애플리케이션의 서비스를 테스트하는 것을 의미하며, 이러한 서비스는 입력 또는 일련의 입력에 대한 응답으로 애플리케이션이 수행하는 모든 것을 의미한다.
- 최상위 수준에는 UI 테스트가 있는데, 테스트의 취약성 등 실행을 더 복잡하게 만드는 여러 속성으로 인해 테스트 수가 더 적다. 예를 들어 사용자 인터페이스의 작은 변경은 많은 테스트를 깨뜨리고 유지 보수 노력을 추가할 수 있다.[16][18]
유닛, 통합, 종단 간 수준
테스트 피라미드의 한 가지 개념은 유닛, 통합, 종단 간 유닛 테스트를 포함한다. 구글의 테스트 블로그에 따르면, 유닛 테스트가 테스트 전략의 대부분을 차지해야 하며, 통합 테스트는 더 적게, 종단 간 테스트는 아주 적게 구성해야 한다.[19]
- 유닛 테스트: 코드의 개별 구성 요소 또는 단위를 독립적으로 테스트하는 테스트이다. 빠르고 신뢰할 수 있으며 작은 코드 단위로 오류를 격리한다.
- 통합 테스트: 서로 다른 코드 단위가 어떻게 함께 작동하는지 확인하는 테스트이다. 개별 단위는 자체적으로 제대로 작동할 수 있지만, 통합 테스트는 이들이 일관성 있게 함께 작동하는지 확인한다.
- 종단 간 테스트: 실제 사용 시나리오를 시뮬레이션하여 시스템 전체를 테스트한다. 가장 느리고 복잡한 테스트이다.
Remove ads
자동화에서의 프레임워크 접근법
요약
관점
테스트 자동화 프레임워크는 특정 제품의 자동화 규칙을 설정하는 통합 시스템이다. 이 시스템은 함수 라이브러리, 테스트 데이터 소스, 객체 세부 정보 및 다양한 재사용 가능한 모듈을 통합한다. 이러한 구성 요소는 비즈니스 프로세스를 나타내기 위해 조립해야 하는 작은 빌딩 블록 역할을 한다. 이 프레임워크는 테스트 자동화의 기반을 제공하고 자동화 노력을 단순화한다.
자동화된 소프트웨어 테스트를 지원하는 가정, 개념 및 도구의 프레임워크의 주요 장점은 유지보수 비용이 저렴하다는 것이다. 어떤 테스트 케이스에 변경이 발생하면 테스트 케이스 파일만 업데이트하면 되고 드라이버 스크립트와 시작 스크립트는 동일하게 유지된다. 이상적으로는 애플리케이션 변경 시 스크립트를 업데이트할 필요가 없다.
올바른 프레임워크/스크립팅 기술을 선택하는 것은 비용을 낮게 유지하는 데 도움이 된다. 테스트 스크립팅과 관련된 비용은 개발 및 유지 관리 노력 때문이다. 테스트 자동화에 사용되는 스크립팅 접근 방식은 비용에 영향을 미친다.
일반적으로 다양한 프레임워크/스크립팅 기술이 사용된다:
- 선형 (절차적 코드, 기록 및 재생을 사용하는 도구 등에 의해 생성될 수 있음)
- 구조화 (제어 구조 사용 - 일반적으로 'if-else', 'switch', 'for', 'while' 조건/문)
- 데이터 주도 (데이터는 데이터베이스, 스프레드시트 또는 기타 메커니즘을 통해 테스트 외부에서 지속됨)
- 키워드 주도
- 하이브리드 (위의 패턴 중 두 가지 이상 사용)
- 애자일 자동화 프레임워크
테스트 프레임워크는 다음을 담당한다.[20]
- 기대치를 표현하는 형식 정의
- 테스트 중인 애플리케이션에 연결하거나 구동하는 메커니즘 생성
- 테스트 실행
- 결과 보고
유닛 테스트 프레임워크
소프트웨어 개발에서 증가하는 추세는 유닛 테스트 프레임워크, 예를 들어 xUnit 프레임워크(예: JUnit 및 NUnit)의 사용이다. 이 프레임워크는 유닛 테스트 실행을 허용하여 코드의 다양한 섹션이 다양한 상황에서 예상대로 작동하는지 여부를 결정한다. 테스트 케이스는 프로그램이 예상대로 실행되는지 확인하기 위해 프로그램에서 실행되어야 하는 테스트를 설명한다.
테스트 자동화 인터페이스
테스트 자동화 인터페이스는 테스트 대상 애플리케이션의 시스템/통합 테스트를 위해 여러 테스트 도구와 프레임워크를 통합하기 위한 단일 작업 공간을 제공하는 플랫폼이다. 테스트 자동화 인터페이스의 목표는 코딩이 프로세스를 방해하지 않고 테스트를 비즈니스 기준에 매핑하는 프로세스를 단순화하는 것이다. 테스트 자동화 인터페이스는 테스트 스크립트 유지 관리의 효율성과 유연성을 향상시킬 것으로 기대된다.[21]
테스트 자동화 인터페이스는 다음 핵심 모듈로 구성된다.
- 인터페이스 엔진
- 인터페이스 환경
- 객체 저장소
인터페이스 엔진
인터페이스 엔진은 인터페이스 환경 위에 구축된다. 인터페이스 엔진은 구문 분석기와 테스트 실행기로 구성된다. 구문 분석기는 객체 저장소에서 오는 객체 파일을 테스트별 스크립팅 언어로 구문 분석하기 위해 존재한다. 테스트 실행기는 테스트 하네스를 사용하여 테스트 스크립트를 실행한다.[21]
객체 저장소
객체 저장소는 테스트 도구가 테스트 중인 애플리케이션을 탐색하면서 기록한 UI/애플리케이션 객체 데이터 모음이다.[21]
Remove ads
자동화 프레임워크와 테스트 도구 간의 경계 정의
도구는 Windows 및 웹 자동화 도구 등 특정 테스트 환경을 대상으로 특별히 설계되었다. 도구는 자동화 프로세스의 구동 에이전트 역할을 한다. 그러나 자동화 프레임워크는 특정 작업을 수행하는 도구가 아니라 다른 도구가 통합된 방식으로 작업을 수행할 수 있는 솔루션을 제공하는 인프라이다. 이는 자동화 엔지니어에게 공통 플랫폼을 제공한다.
다양한 유형의 프레임워크가 있다. 이들은 활용하는 자동화 구성 요소에 따라 분류된다.
- 데이터 주도 테스트
- 모듈성 주도 테스트
- 키워드 주도 테스트
- 하이브리드 테스트
- 모델 기반 테스트
- 코드 주도 테스팅
- 행동 주도 개발
같이 보기
각주
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads