본문으로 이동

테스트 자동화

위키백과, 우리 모두의 백과사전.
소프트웨어 개발 프로세스
활동과 단계
요구사항 분석 · 기능 명세
구조 · 설계
구현 · 테스팅
배치 · 유지보수
개발 모형
애자일 소프트웨어 개발 · 클린룸
DSDM · 순차점증적 개발 · 반복형 개발
RAD · RUP · 나선 모형
폭포수 모델 · 익스트림 프로그래밍
스크럼 · V 모델 · TDD
지원 활동
구성 관리 · 문서화
품질보증 · 프로젝트 관리
사용자 경험 설계
도구
컴파일러 · 디버거 · 프로파일러
GUI 디자이너 · 통합 개발 환경

소프트웨어 테스트에서 테스트 자동화(test automation)는 테스트 대상 소프트웨어와는 별개의 소프트웨어를 사용하여 테스트 실행을 제어하고 실제 결과와 예측된 결과를 비교하는 것이다.[1] 테스트 자동화는 이미 진행 중인 공식화된 테스트 프로세스에서 반복적이지만 필요한 일부 작업을 자동화하거나 수동으로 수행하기 어려운 추가 테스트를 수행할 수 있다. 테스트 자동화는 지속적 전달 및 지속적 테스트에 매우 중요하다.[2]

일반적인 접근법

[편집]

테스트 자동화에는 여러 가지 접근법이 있지만, 다음은 널리 사용되는 일반적인 접근법이다.

  • 그래픽 사용자 인터페이스 테스트. 키 입력 및 마우스 클릭과 같은 사용자 인터페이스 이벤트를 생성하고 사용자 인터페이스에서 발생하는 변경 사항을 관찰하여 프로그램의 관찰 가능한 동작이 올바른지 확인하는 테스트 프레임워크.
  • API 기반 테스트. 애플리케이션에 대한 프로그래밍 인터페이스를 사용하여 테스트 중인 동작을 확인하는 테스트 프레임워크. 일반적으로 API 기반 테스트는 애플리케이션 사용자 인터페이스를 완전히 건너뛴다. 또한 클래스, 모듈 또는 라이브러리에 대한 (일반적으로) 공용 인터페이스를 다양한 입력 인수로 테스트하여 반환되는 결과가 올바른지 확인할 수도 있다.

기타 접근법

[편집]

모델 기반 테스트

[편집]
 이 부분의 본문은 모델 기반 테스트입니다.

테스트 케이스를 자동으로 생성하는 한 가지 방법은 테스트 케이스 생성을 위해 시스템 모델을 사용하는 모델 기반 테스트이지만, 이를 위한 다양한 대체 방법론에 대한 연구가 계속되고 있다. 어떤 경우에는 모델 기반 접근 방식을 통해 비기술적 사용자도 일반 영어로 자동화된 비즈니스 테스트 케이스를 만들 수 있으므로 여러 운영 체제, 브라우저 및 스마트 장치에 맞게 구성하는 데 어떤 종류의 프로그래밍도 필요하지 않다.[3]

회귀 테스트

[편집]

일부 소프트웨어 테스트 작업(예: 광범위한 하위 수준 인터페이스 회귀 테스트)은 수동으로 수행하기에 힘들고 시간이 많이 소요될 수 있다. 또한 수동 접근 방식은 특정 유형의 결함을 찾는 데 항상 효과적이지 않을 수 있다. 테스트 자동화는 이러한 유형의 테스트를 효과적으로 수행할 가능성을 제공한다.

자동화된 테스트가 개발되면 신속하고 반복적으로 여러 번 실행될 수 있다. 이는 유지보수 수명이 긴 소프트웨어 제품의 회귀 테스트를 위한 비용 효율적인 방법이 될 수 있다. 애플리케이션의 수명 주기 동안 사소한 패치조차도 이전에 작동하던 기존 기능이 손상될 수 있다.

API 테스트

[편집]
 이 부분의 본문은 API 테스트입니다.

API 테스트는 소프트웨어 테스터들이 GUI 구현과 독립적으로 요구 사항을 검증하고, 일반적으로 개발 초기 단계에서 테스트하며, 테스트 자체도 깔끔한 코드 원칙, 특히 단일 책임 원칙을 준수하는지 확인하는 데 널리 사용되고 있다. 이는 통합 테스트의 일부로 API를 직접 테스트하여 기능성, 신뢰성, 성능 및 보안에 대한 기대치를 충족하는지 확인하는 것을 포함한다.[4] API에는 GUI가 없으므로 API 테스트는 메시지 계층에서 수행된다.[5] API가 애플리케이션 로직의 기본 인터페이스 역할을 할 때 API 테스트는 중요하게 간주된다.[6]

그래픽 사용자 인터페이스 (GUI) 테스트

[편집]
 이 부분의 본문은 그래픽 사용자 인터페이스 테스트입니다.

많은 테스트 자동화 도구는 기록 및 재생 기능을 제공하여 사용자가 대화식으로 사용자 작업을 기록하고 원하는 만큼 여러 번 재생하며 실제 결과를 예상 결과와 비교할 수 있도록 한다. 이 접근 방식의 장점은 소프트웨어 개발이 거의 또는 전혀 필요하지 않다는 것이다. 이 접근 방식은 그래픽 사용자 인터페이스를 가진 모든 애플리케이션에 적용할 수 있다. 그러나 이러한 기능에 의존하는 것은 주요 신뢰성 및 유지보수 문제를 야기한다. 버튼의 레이블을 변경하거나 창의 다른 부분으로 이동하면 테스트를 다시 기록해야 할 수 있다. 기록 및 재생은 또한 종종 관련 없는 활동을 추가하거나 일부 활동을 잘못 기록하기도 한다.

이러한 유형의 도구의 변형은 웹 사이트 테스트를 위한 것이다. 여기서 "인터페이스"는 웹 페이지이다. 그러나 이러한 프레임워크는 운영 체제 이벤트 대신 HTML을 렌더링하고 DOM 이벤트를 수신하기 때문에 완전히 다른 기술을 사용한다. 일반적으로 이 목적을 위해 헤드리스 브라우저 또는 셀레늄 웹 드라이버 기반 솔루션이 사용된다.[7][8][9]

이러한 유형의 테스트 자동화 도구의 또 다른 변형은 모바일 애플리케이션 테스트용이다. 모바일 폰에서 사용되는 다양한 크기, 해상도 및 운영 체제를 고려할 때 매우 유용하다. 이 변형의 경우, 모바일 장치에서 작업을 인스턴스화하고 작업 결과를 수집하기 위해 프레임워크가 사용된다.

또 다른 변형은 기록 및 재생을 사용하지 않는 스크립트 없는 테스트 자동화이지만, 대신 애플리케이션 모델을 구축한 다음 테스터가 테스트 매개변수와 조건을 단순히 삽입하여 테스트 케이스를 생성할 수 있도록 하여 스크립팅 기술이 필요하지 않다.

방법론

[편집]

테스트 주도 개발

[편집]

주로 유닛 테스트를 사용하는 테스트 자동화는 익스트림 프로그래밍 및 애자일 소프트웨어 개발의 핵심 기능으로, 테스트 주도 개발(TDD) 또는 테스트 우선 개발로 알려져 있다. 유닛 테스트는 코드가 작성되기 전에 기능을 정의하기 위해 작성될 수 있다. 그러나 이러한 유닛 테스트는 코딩이 진행되고, 문제가 발견되고, 코드가 리팩터링될 때 진화하고 확장된다.[10] 요구되는 모든 기능에 대한 모든 테스트가 통과될 때만 코드는 완성된 것으로 간주된다. 옹호자들은 이것이 수동 탐색으로 테스트되는 코드보다 더 안정적이고 비용이 적게 드는 소프트웨어를 생산한다고 주장한다. 코드 커버리지가 더 좋고, 폭포수 모델 개발 주기 끝에 한 번 실행되는 대신 개발 중에 지속적으로 실행되기 때문에 더 신뢰할 수 있는 것으로 간주된다. 개발자는 변경 즉시 결함을 발견하며, 이때 수정하는 것이 가장 저렴하다. 마지막으로, 유닛 테스트를 사용할 때 리팩터링이 더 안전하다. 코드를 코드 중복이 적고 동등한 동작을 가진 더 간단한 형태로 변환하는 것은 리팩터링된 코드가 유닛 테스트로 커버될 때 새로운 결함을 도입할 가능성이 훨씬 적다.

지속적 테스트

[편집]
 이 부분의 본문은 지속적 테스트입니다.

지속적 테스트는 소프트웨어 릴리스 후보와 관련된 비즈니스 위험에 대한 즉각적인 피드백을 얻기 위해 소프트웨어 전달 파이프라인의 일부로 자동화된 테스트를 실행하는 프로세스이다.[11][12] 지속적 테스트의 경우 테스트 범위는 상향식 요구 사항 또는 사용자 스토리를 검증하는 것에서부터 전반적인 비즈니스 목표와 관련된 시스템 요구 사항을 평가하는 것까지 확장된다.[13]

고려 사항

[편집]

테스트 자동화 구현 결정에 고려할 요소

[편집]

무엇을 자동화할지, 언제 자동화할지, 심지어 자동화가 정말 필요한지 여부는 테스트(또는 개발) 팀이 내려야 하는 중요한 결정이다.[14] 52개의 실무자 출처와 26개의 학술 출처를 대상으로 한 다중음성 문헌 검토 결과, 테스트 자동화 결정에 고려해야 할 다섯 가지 주요 요소는 다음과 같다: 1) 테스트 대상 시스템(SUT), 2) 테스트 유형 및 수, 3) 테스트 도구, 4) 인적 및 조직적 주제, 5) 교차적 요소. 연구에서 가장 자주 식별된 개별 요소는 회귀 테스트의 필요성, 경제적 요인, SUT의 성숙도였다.[15]

고원 효과

[편집]

자동화된 테스트의 재사용성은 소프트웨어 개발 회사에서 중요하게 여기지만, 이 속성은 단점으로도 볼 수 있다. 이는 반복적으로 실행되는 스크립트가 프레임워크를 넘어선 오류를 감지하지 못하게 되는 이른바 "살충제 역설"을 초래한다. 이러한 경우 수동 테스트가 더 나은 투자가 될 수 있다. 이러한 모호성은 프로젝트 요구사항과 특성을 고려하여 테스트 자동화 결정을 개별적으로 내려야 한다는 결론으로 다시 이어진다.

무엇을 테스트할 것인가

[편집]

테스트 도구는 제품 설치, 테스트 데이터 생성, GUI 상호 작용, 문제 감지(테스트 오라클을 갖춘 파싱 또는 폴링 에이전트 고려), 결함 로깅 등과 같은 작업을 자동화하는 데 도움이 될 수 있으며, 반드시 종단 간 방식으로 테스트를 자동화할 필요는 없다.

테스트 자동화를 생각할 때 인기 있는 요구 사항을 계속 충족해야 한다.

  • 플랫폼 및 OS 독립성
  • 데이터 기반 기능(입력 데이터, 출력 데이터, 메타데이터)
  • 보고서 사용자 지정(DB 데이터베이스 접근, 크리스탈 리포트)
  • 쉬운 디버깅 및 로깅
  • 버전 관리 친화적 - 최소한의 이진 파일
  • 확장성 및 사용자 지정(다른 도구와 통합할 수 있는 개방형 API)
  • 공통 드라이버 (예: 자바 개발 생태계에서는 Ant 또는 Maven 및 인기 있는 IDE를 의미한다.) 이를 통해 개발자 워크플로우와 테스트를 통합할 수 있다.
  • 빌드 프로세스 및 배치 실행과의 통합을 위한 무인 테스트 실행 지원. 지속적 통합 서버에서 필요하다.
  • 반송 메일과 같은 이메일 알림
  • 분산 실행 환경 지원 (분산 테스트베드)
  • 분산 애플리케이션 지원 (분산 SUT)

역할

[편집]

테스트 자동화 도구

[편집]

테스트 자동화 도구는 비용이 많이 들 수 있으며, 일반적으로 수동 테스트와 함께 사용된다. 테스트 자동화는 장기적으로, 특히 회귀 테스트에서 반복적으로 사용될 때 비용 효율적일 수 있다. 테스트 자동화에 적합한 후보는 애플리케이션의 일반적인 흐름에 대한 테스트 케이스이다. 이는 애플리케이션이 향상될 때마다 (회귀 테스트를 통해) 실행되어야 하기 때문이다. 테스트 자동화는 수동 테스트와 관련된 노력을 줄여준다. 자동화된 검사를 개발하고 유지 관리하며 테스트 결과를 검토하는 데는 수동 노력이 필요하다.

테스트 엔지니어

[편집]
 이 부분의 본문은 테스트 엔지니어입니다.

자동화된 테스트에서 테스트 엔지니어 또는 소프트웨어 품질보증 담당자는 소프트웨어 코딩 능력을 갖추어야 한다. 테스트 케이스는 실행될 때 포함된 어설션에 따라 출력을 생성하는 소스 코드 형태로 작성되기 때문이다. 일부 테스트 자동화 도구는 코딩 대신 키워드로 테스트 작성을 허용하여 프로그래밍이 필요하지 않다.

다양한 수준에서의 테스트

[편집]

테스트 자동화량을 결정하는 전략은 테스트 자동화 피라미드이다. 이 전략은 서로 다른 세분화 수준을 가진 세 가지 유형의 테스트를 작성할 것을 제안한다. 수준이 높을수록 작성할 테스트 양은 줄어든다.[16]

유닛, 서비스, 사용자 인터페이스 수준

[편집]
마이크 콘이 제안한 테스트 자동화 피라미드[16]
  • 튼튼한 기반으로서 유닛 테스트는 소프트웨어 제품에 견고성을 제공한다. 코드의 개별 부분을 테스트하면 테스트를 작성하고 실행하기 쉽다. 개발자는 각 스토리의 일부로 유닛 테스트를 작성하고 CI와 통합한다.[17]
  • 서비스 계층은 사용자 인터페이스와는 별도로 애플리케이션의 서비스를 테스트하는 것을 의미하며, 이러한 서비스는 입력 또는 일련의 입력에 대한 응답으로 애플리케이션이 수행하는 모든 것을 의미한다.
  • 최상위 수준에는 UI 테스트가 있는데, 테스트의 취약성 등 실행을 더 복잡하게 만드는 여러 속성으로 인해 테스트 수가 더 적다. 예를 들어 사용자 인터페이스의 작은 변경은 많은 테스트를 깨뜨리고 유지 보수 노력을 추가할 수 있다.[16][18]

유닛, 통합, 종단 간 수준

[편집]
구글의 "테스팅 피라미드"를 묘사한 삼각형 다이어그램. 맨 위 가장 작은 "E2E" 섹션부터 가운데 "통합", 맨 아래 가장 큰 "유닛" 섹션으로 진행된다.
구글의 테스팅 피라미드[19]

테스트 피라미드의 한 가지 개념은 유닛, 통합, 종단 간 유닛 테스트를 포함한다. 구글의 테스트 블로그에 따르면, 유닛 테스트가 테스트 전략의 대부분을 차지해야 하며, 통합 테스트는 더 적게, 종단 간 테스트는 아주 적게 구성해야 한다.[19]

  • 유닛 테스트: 코드의 개별 구성 요소 또는 단위를 독립적으로 테스트하는 테스트이다. 빠르고 신뢰할 수 있으며 작은 코드 단위로 오류를 격리한다.
  • 통합 테스트: 서로 다른 코드 단위가 어떻게 함께 작동하는지 확인하는 테스트이다. 개별 단위는 자체적으로 제대로 작동할 수 있지만, 통합 테스트는 이들이 일관성 있게 함께 작동하는지 확인한다.
  • 종단 간 테스트: 실제 사용 시나리오를 시뮬레이션하여 시스템 전체를 테스트한다. 가장 느리고 복잡한 테스트이다.

자동화에서의 프레임워크 접근법

[편집]

테스트 자동화 프레임워크는 특정 제품의 자동화 규칙을 설정하는 통합 시스템이다. 이 시스템은 함수 라이브러리, 테스트 데이터 소스, 객체 세부 정보 및 다양한 재사용 가능한 모듈을 통합한다. 이러한 구성 요소는 비즈니스 프로세스를 나타내기 위해 조립해야 하는 작은 빌딩 블록 역할을 한다. 이 프레임워크는 테스트 자동화의 기반을 제공하고 자동화 노력을 단순화한다.

자동화된 소프트웨어 테스트를 지원하는 가정, 개념 및 도구의 프레임워크의 주요 장점은 유지보수 비용이 저렴하다는 것이다. 어떤 테스트 케이스에 변경이 발생하면 테스트 케이스 파일만 업데이트하면 되고 드라이버 스크립트와 시작 스크립트는 동일하게 유지된다. 이상적으로는 애플리케이션 변경 시 스크립트를 업데이트할 필요가 없다.

올바른 프레임워크/스크립팅 기술을 선택하는 것은 비용을 낮게 유지하는 데 도움이 된다. 테스트 스크립팅과 관련된 비용은 개발 및 유지 관리 노력 때문이다. 테스트 자동화에 사용되는 스크립팅 접근 방식은 비용에 영향을 미친다.

일반적으로 다양한 프레임워크/스크립팅 기술이 사용된다:

  1. 선형 (절차적 코드, 기록 및 재생을 사용하는 도구 등에 의해 생성될 수 있음)
  2. 구조화 (제어 구조 사용 - 일반적으로 'if-else', 'switch', 'for', 'while' 조건/문)
  3. 데이터 주도 (데이터는 데이터베이스, 스프레드시트 또는 기타 메커니즘을 통해 테스트 외부에서 지속됨)
  4. 키워드 주도
  5. 하이브리드 (위의 패턴 중 두 가지 이상 사용)
  6. 애자일 자동화 프레임워크

테스트 프레임워크는 다음을 담당한다.[20]

  1. 기대치를 표현하는 형식 정의
  2. 테스트 중인 애플리케이션에 연결하거나 구동하는 메커니즘 생성
  3. 테스트 실행
  4. 결과 보고

유닛 테스트 프레임워크

[편집]

소프트웨어 개발에서 증가하는 추세는 유닛 테스트 프레임워크, 예를 들어 xUnit 프레임워크(예: JUnit 및 NUnit)의 사용이다. 이 프레임워크는 유닛 테스트 실행을 허용하여 코드의 다양한 섹션이 다양한 상황에서 예상대로 작동하는지 여부를 결정한다. 테스트 케이스는 프로그램이 예상대로 실행되는지 확인하기 위해 프로그램에서 실행되어야 하는 테스트를 설명한다.

테스트 자동화 인터페이스

[편집]

테스트 자동화 인터페이스는 테스트 대상 애플리케이션의 시스템/통합 테스트를 위해 여러 테스트 도구와 프레임워크를 통합하기 위한 단일 작업 공간을 제공하는 플랫폼이다. 테스트 자동화 인터페이스의 목표는 코딩이 프로세스를 방해하지 않고 테스트를 비즈니스 기준에 매핑하는 프로세스를 단순화하는 것이다. 테스트 자동화 인터페이스는 테스트 스크립트 유지 관리의 효율성과 유연성을 향상시킬 것으로 기대된다.[21]

테스트 자동화 인터페이스 모델

테스트 자동화 인터페이스는 다음 핵심 모듈로 구성된다.

  • 인터페이스 엔진
  • 인터페이스 환경
  • 객체 저장소

인터페이스 엔진

[편집]

인터페이스 엔진은 인터페이스 환경 위에 구축된다. 인터페이스 엔진은 구문 분석기와 테스트 실행기로 구성된다. 구문 분석기는 객체 저장소에서 오는 객체 파일을 테스트별 스크립팅 언어로 구문 분석하기 위해 존재한다. 테스트 실행기는 테스트 하네스를 사용하여 테스트 스크립트를 실행한다.[21]

객체 저장소

[편집]

객체 저장소는 테스트 도구가 테스트 중인 애플리케이션을 탐색하면서 기록한 UI/애플리케이션 객체 데이터 모음이다.[21]

자동화 프레임워크와 테스트 도구 간의 경계 정의

[편집]

도구는 Windows 및 웹 자동화 도구 등 특정 테스트 환경을 대상으로 특별히 설계되었다. 도구는 자동화 프로세스의 구동 에이전트 역할을 한다. 그러나 자동화 프레임워크는 특정 작업을 수행하는 도구가 아니라 다른 도구가 통합된 방식으로 작업을 수행할 수 있는 솔루션을 제공하는 인프라이다. 이는 자동화 엔지니어에게 공통 플랫폼을 제공한다.

다양한 유형의 프레임워크가 있다. 이들은 활용하는 자동화 구성 요소에 따라 분류된다.

  1. 데이터 주도 테스트
  2. 모듈성 주도 테스트
  3. 키워드 주도 테스트
  4. 하이브리드 테스트
  5. 모델 기반 테스트
  6. 코드 주도 테스팅
  7. 행동 주도 개발

같이 보기

[편집]

각주

[편집]
  1. ↑ Kolawa, Adam; Huizinga, Dorota (2007). 《Automated Defect Prevention: Best Practices in Software Management》. Wiley-IEEE Computer Society Press. 74쪽. ISBN 978-0-470-04212-0. 
  2. ↑ O’Connor, Rory V.; Akkaya, Mariye Umay; Kemaneci, Kerem; Yilmaz, Murat; Poth, Alexander; Messnarz, Richard (2015년 10월 15일). 《Systems, Software and Services Process Improvement: 22nd European Conference, EuroSPI 2015, Ankara, Turkey, September 30 -- October 2, 2015. Proceedings》 (영어). Springer. ISBN 978-3-319-24647-5. 
  3. ↑ 《Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. "Test Design: Lessons Learned and Practical Implications.》. doi:10.1109/IEEESTD.2008.4578383. ISBN 978-0-7381-5746-7. 
  4. ↑ Testing APIs protects applications and reputations, by Amy Reichert, SearchSoftwareQuality March 2015
  5. ↑ All About API Testing: An Interview with Jonathan Cooper, by Cameron Philipp-Edmonds, Stickyminds August 19, 2014
  6. ↑ Produce Better Software by Using a Layered Testing Strategy, by Sean Kenefick, 가트너 January 7, 2014
  7. ↑ Headless Testing with Browsers; https://docs.travis-ci.com/user/gui-and-headless-browsers/
  8. ↑ Headless Testing with PhantomJS;http://phantomjs.org/headless-testing.html
  9. ↑ Automated User Interface Testing; https://www.devbridge.com/articles/automated-user-interface-testing/
  10. ↑ Vodde, Bas; Koskela, Lasse (2007). 《Learning Test-Driven Development by Counting Lines》. 《IEEE Software》 24. 74–79쪽. doi:10.1109/ms.2007.80. S2CID 30671391. 
  11. ↑ Part of the Pipeline: Why Continuous Testing Is Essential, by Adam Auerbach, TechWell Insights August 2015
  12. ↑ The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola, by Cameron Philipp-Edmonds, Stickyminds December 2015
  13. ↑ DevOps: Are You Pushing Bugs to Clients Faster, by Wayne Ariola and Cynthia Dunlop, PNSQC October 2015
  14. ↑ Brian Marick. “When Should a Test Be Automated?”. StickyMinds.com. 2009년 8월 20일에 확인함. 
  15. ↑ Garousi, Vahid; Mäntylä, Mika V. (2016년 8월 1일). 《When and what to automate in software testing? A multi-vocal literature review》. 《Information and Software Technology》 76. 92–117쪽. doi:10.1016/j.infsof.2016.04.015. 
  16. ↑ 가 나 다 Mike Cohn (2010). 《Succeeding with Agile》. Raina Chrobak. ISBN 978-0-321-57936-2. 
  17. ↑ “Full Stack Testing by Gayathri Mohan” (미국 영어). 《www.thoughtworks.com》. 2022년 9월 13일에 확인함. 
  18. ↑ The Practical Test Pyramid, by Ham Vocke
  19. ↑ 가 나 “Just Say No to More End-to-End Tests” (영어). 《Google Testing Blog》. 2023년 2월 11일에 확인함. 
  20. ↑ “Selenium Meet-Up 4/20/2010 Elisabeth Hendrickson on Robot Framework 1of2”. 《유튜브》. 2010년 4월 28일. 2010년 9월 26일에 확인함. 
  21. ↑ 가 나 다 “Conquest: Interface for Test Automation Design” (PDF). 2012년 4월 26일에 원본 문서 (PDF)에서 보존된 문서. 2011년 12월 11일에 확인함. 

일반 참고 자료

[편집]
  • Elfriede Dustin 외 (1999). 《Automated Software Testing》. Addison Wesley. ISBN 978-0-201-43287-9. 
  • Elfriede Dustin 외 (2009). 《Implementing Automated Software Testing》. Addison Wesley. ISBN 978-0-321-58051-1. 
  • Mark Fewster & Dorothy Graham (1999). 《Software Test Automation》. ACM Press/Addison-Wesley. ISBN 978-0-201-33140-0. 
  • Roman Savenkov: How to Become a Software Tester. Roman Savenkov Consulting, 2008, ISBN 978-0-615-23372-7
  • Hong Zhu 외 (2008). 《AST '08: Proceedings of the 3rd International Workshop on Automation of Software Test》. ACM Press. doi:10.1145/1370042. ISBN 978-1-60558-030-2. 
  • Mosley, Daniel J.; Posey, Bruce (2002). 《Just Enough Software Test Automation》. Prentice Hall Professional. ISBN 978-0130084682. 
  • Hayes, Linda G., "Automated Testing Handbook", Software Testing Institute, 2nd Edition, March 2004
  • Kaner, Cem, "Architectures of Test Automation 보관됨 2021-01-26 - 웨이백 머신", August 2000
원본 주소 "https://ko.wikipedia.org/w/index.php?title=테스트_자동화&oldid=40309912"