테스트 자동화

Test automation
"Automated QA"는 여기로 리디렉션됩니다.회사에 대해서는 자동화를 참조하십시오.QA.
시리즈의 일부(on)
소프트웨어 개발
핵심활동
패러다임과 모델
방법론 및 프레임워크
지원분야
관행
도구들
지식의 기준과 내용
용어집
개요

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

일반접근법

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

  • 그래픽 사용자 인터페이스 테스트.키 누름, 마우스 클릭과 같은 사용자 인터페이스 이벤트를 생성하고 사용자 인터페이스의 결과로 나타나는 변화를 관찰하여 프로그램의 관찰 가능한 동작이 올바른지 확인하는 테스트 프레임워크입니다.
  • API 기반 테스트.응용 프로그램에 대한 프로그래밍 인터페이스를 사용하여 테스트 대상 동작의 유효성을 검사하는 테스트 프레임워크입니다.일반적으로 API 기반 테스트는 애플리케이션 사용자 인터페이스를 완전히 무시합니다.또한 클래스, 모듈 또는 라이브러리에 대한 공용 인터페이스를 테스트하여 반환된 결과가 올바른지 확인하는 다양한 입력 인수를 사용하여 테스트할 수도 있습니다.

모델 기반 테스트

주요 기사:모델 기반 테스트

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

테스트 자동화 구현 결정을 위해 고려해야 할 요소

무엇을 자동화할 것인가, 언제 자동화할 것인가, 또는 정말로 자동화가 필요한지 여부까지도 테스트(또는 개발) 팀이 내려야 할 중요한 결정입니다.[4]52명의 실무자와 26명의 학술 자료를 대상으로 한 다성 문헌 고찰 결과, 1) SUT(System Under Test), 2) 테스트 유형 및 수, 3) 테스트 도구, 4) 인적 및 조직 주제, 5) 교차 절단 요소의 다섯 가지 주요 고려 요소가 발견되었습니다.연구에서 확인된 가장 빈번한 개별 요인은 회귀분석의 필요성, 경제적 요인, SUT의 성숙도 등이었습니다.[5]

단위시험틀

소프트웨어 개발에서 증가하는 추세는 다양한 상황에서 코드의 다양한 섹션이 예상대로 작동하는지를 판단하기 위해 단위 테스트를 실행할 수 있는 xUnit 프레임워크(예: JUnit 및 NUnit)와 같은 단위 테스트 프레임워크의 사용입니다.테스트 사례는 프로그램이 예상대로 실행되는지 확인하기 위해 프로그램에서 실행해야 하는 테스트를 설명합니다.

테스트 주도형 개발

테스트 자동화는 장치 테스트를 주로 사용하는 극단적인 프로그래밍 및 민첩한 소프트웨어 개발의 핵심 기능으로, TDD(Test Driven Development) 또는 테스트 우선 개발로 알려져 있습니다.단위 테스트는 코드가 작성되기 전에 기능을 정의하기 위해 작성할 수 있습니다.그러나 이러한 단위 테스트는 코딩이 진행됨에 따라 진화하고 확장되며, 문제가 발견되고 코드가 리팩토링(refactoring)의 대상이 됩니다.[6]요구되는 모든 기능에 대한 모든 테스트를 통과해야만 코드가 완성된 것으로 간주됩니다.지지자들은 그것이 수동 탐색에 의해 테스트되는 코드보다 더 신뢰성이 높고 비용이 적게 드는 소프트웨어를 생산한다고 주장합니다.[citation needed]코드 커버리지가 더 우수하고, 폭포 개발 주기가 끝날 때 한 번이 아니라 개발 중에도 지속적으로 실행되기 때문에 신뢰성이 더 높은 것으로 평가됩니다.개발자는 변경 즉시 결함을 발견합니다. 수정 비용이 가장 적게 듭니다.마지막으로, 코드 리팩토링은 단위 테스트를 사용할 때 더 안전합니다. 코드 중복이 적은 간단한 형태로 코드를 변환하지만, 이와 동등한 동작은 리팩토링된 코드가 단위 테스트에 적용될 때 새로운 결함이 발생할 가능성이 훨씬 낮습니다.

회귀분석

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

자동화된 테스트가 개발되면 여러 번 신속하고 반복적으로 실행할 수 있습니다.이 방법은 유지보수 수명이 긴 소프트웨어 제품의 회귀 테스트에 비용 효율적인 방법이 될 수 있습니다.애플리케이션 수명에 걸쳐 약간의 패치를 적용해도 이전 시점에서 작동하던 기존 기능이 중단될 수 있습니다.

고원효과

자동화된 테스트의 재사용성은 소프트웨어 개발 회사들에 의해 평가되지만, 이 속성은 단점으로 간주될 수도 있습니다.이는 반복적으로 실행되는 스크립트가 자신의 프레임워크를 넘어서는 오류를 감지하는 것을 중단하는 이른바 "농약 역설"로 이어집니다.이러한 경우에는 수동 테스트가 더 나은 투자가 될 수 있습니다.이러한 불명확성은 다시 한번 프로젝트 요건과 특수성을 고려하여 테스트 자동화에 대한 결정을 개별적으로 해야 한다는 결론으로 이어집니다.

테스트 자동화 툴

테스트 자동화 도구는 비용이 많이 들 수 있으며 일반적으로 수동 테스트와 함께 사용됩니다.테스트 자동화는 특히 회귀 테스트에서 반복적으로 사용할 경우 장기적으로 비용 효율적으로 이루어질 수 있습니다.테스트 자동화를 위한 좋은 후보는 애플리케이션의 공통 흐름에 대한 테스트 케이스입니다. 애플리케이션에서 개선이 이루어질 때마다 애플리케이션을 실행(회귀 테스트)해야 하기 때문입니다.테스트 자동화는 수동 테스트와 관련된 노력을 줄여줍니다.자동화된 검사를 개발하고 유지하기 위해서는 수동적인 노력이 필요하며 검사 결과를 검토합니다.

테스트 엔지니어

주요 기사:테스트 엔지니어

자동화 테스트에서 테스트 케이스는 소스 코드 형태로 작성되며, 소스 코드 형태로 작성되어 실행 시 일부에 해당하는 주장에 따라 출력이 발생하기 때문에 테스트 엔지니어 또는 소프트웨어 품질 보증 담당자는 소프트웨어 코딩 능력을 갖추어야 합니다.일부 테스트 자동화 도구에서는 프로그래밍을 필요로 하지 않는 코딩 대신 키워드를 사용하여 테스트 저작을 수행할 수 있습니다.

API 테스팅

주요 기사 : API testing

API 테스트는 소프트웨어 테스터들이 GUI 구현과 독립적인 요구사항을 검증할 수 있게 해 주고 있으며, 개발 초기에 흔히 테스트할 수 있으며, 테스트 자체가 클린 코드 원칙, 특히 단일 책임 원칙을 준수하는지 확인할 수 있게 해 주기 때문에 널리 사용되고 있습니다.통합 테스트의 일환으로 API를 직접 테스트하여 기능성, 신뢰성, 성능 및 보안에 대한 기대를 충족하는지 여부를 확인합니다.[7]API는 GUI가 부족하기 때문에 메시지 계층에서 API 테스트를 수행합니다.[8]API 테스트는 애플리케이션 로직에 대한 주요 인터페이스 역할을 할 때 중요한 것으로 간주됩니다.[9]

연속시험

주요 기사:연속시험

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

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

주요 기사: 그래픽 사용자 인터페이스 테스트

많은 테스트 자동화 도구는 사용자가 대화식으로 사용자 작업을 기록하고 실제 결과를 예상 결과와 비교하여 원하는 횟수만큼 다시 재생할 수 있는 기록 및 재생 기능을 제공합니다.이 접근 방식의 장점은 소프트웨어 개발이 거의 또는 전혀 필요하지 않다는 것입니다.이 접근 방식은 그래픽 사용자 인터페이스가 있는 모든 응용 프로그램에 적용할 수 있습니다.그러나 이러한 기능에 의존할 경우 신뢰성 및 유지보수성에 큰 문제가 발생합니다.버튼을 다시 열거나 윈도우의 다른 부분으로 옮기려면 테스트를 다시 기록해야 할 수도 있습니다.기록 및 재생은 종종 관련 없는 활동을 추가하거나 일부 활동을 잘못 기록합니다.[citation needed]

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

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

또 다른 변형은 스크립트가 없는 테스트 자동화로, 기록과[clarification needed] 재생을 사용하지 않고 애플리케이션의 모델을 구축한 다음 테스트 매개 변수와 조건을 간단히 삽입하여 테스트 케이스를 생성할 수 있으므로 스크립트 기술이 필요하지 않습니다.

다양한 수준의 테스트

테스트 자동화 피라미드는 자동화할 테스트의 양을 결정하는 전략입니다.이 전략은 세 가지 유형의 검사를 서로 다른 세분성으로 작성할 것을 제안합니다.수준이 높을수록 쓰기 검사의 양이 줄어듭니다.[16]

장치, 서비스 및 사용자 인터페이스 수준

Mike Cohn이[16] 제안한 테스트 자동화 피라미드
  • 유닛 테스트는 견고한 기반으로서 소프트웨어 제품에 견고함을 제공합니다.코드의 각 부분을 테스트하면 테스트를 작성하고 실행하기가 쉽습니다.개발자는 각 스토리의 일부로 단위 테스트를 작성하고 CI와 통합합니다.[17]
  • 서비스 계층은 사용자 인터페이스와 별도로 응용 프로그램의 서비스를 테스트하는 것을 말합니다. 이러한 서비스는 응용 프로그램이 일부 입력 또는 일련의 입력에 응답하여 수행하는 모든 것입니다.
  • 최상위 레벨에서는 실행을 더 복잡하게 만드는 특성(예: 테스트의 취약성) 때문에 테스트 수가 적은 UI 테스트가 있습니다. 사용자 인터페이스를 조금만 변경해도 많은 테스트가 중단되고 유지보수 작업이 추가될 수 있습니다.[16][18]

단위, 통합 및 엔드 투 엔드 수준

A triangular diagram depicting Google's "testing pyramid". Progresses from the smallest section "E2E" at the top, to "Integration" in the middle, to the largest section "Unit" at the bottom.
구글의 테스트 피라미드[19]

테스트 피라미드의 하나의 개념에는 단위, 통합 및 종단 간 단위 테스트가 포함됩니다.Google의 테스트 블로그에 따르면, 통합 테스트의 수는 적고 엔드 투 엔드 테스트의 양은 적은 상태로, 단위 테스트가 테스트 전략의 대부분을 차지할 것이라고 합니다.[19]

  • 단위 테스트:이 테스트는 개별 구성 요소 또는 코드 단위를 분리하여 테스트하는 테스트입니다.빠르고 안정적이며 작은 단위의 코드로 장애를 격리합니다.
  • 통합 테스트:이 검정은 서로 다른 단위의 코드가 어떻게 함께 작동하는지 확인합니다.개별 장치가 자체적으로 제대로 작동할 수 있지만 통합 테스트를 통해 장치가 일관성 있게 작동하는지 확인할 수 있습니다.
  • 엔드 투 엔드 테스트:실제 사용 시나리오를 시뮬레이션하면서 시스템 전체를 테스트합니다.가장 느리고 복잡한 테스트입니다.

자동화 프레임워크 접근 방식

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

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

적절한 프레임워크/스크립트 기술을 선택하면 비용을 절감하는 데 도움이 됩니다.테스트 스크립팅과 관련된 비용은 개발 및 유지보수 노력으로 인해 발생합니다.테스트 자동화 중에 사용되는 스크립팅의 접근 방식은 비용에 영향을 미칩니다.

일반적으로 다양한 프레임워크/스크립트 기법이 사용됩니다.

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

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

  1. 기대를 표현할 형식 정의
  2. 테스트 중인 응용프로그램에 연결하거나 구동하는 메커니즘 만들기
  3. 테스트 실행
  4. 보고 결과

테스트 자동화 인터페이스

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

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

테스트 자동화 인터페이스는 다음과 같은 핵심 모듈로 구성됩니다.

  • 인터페이스 엔진
  • 인터페이스 환경
  • 개체 리포지토리

인터페이스 엔진

인터페이스 엔진은 Interface Environment(Interface Environment)인터페이스 엔진은 파서와 테스트 러너로 구성됩니다.구문 분석기가 존재하여 개체 저장소에서 나오는 개체 파일을 테스트별 스크립팅 언어로 구문 분석합니다.테스트 실행자는 테스트 하니스를 사용하여 테스트 스크립트를 실행합니다.[21]

객체 저장소

개체 저장소는 테스트 대상 응용 프로그램을 탐색하는 동안 테스트 도구가 기록한 UI/응용 프로그램 개체 데이터의 모음입니다.[21]

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

도구는 Windows 및 웹 자동화 도구 등과 같은 특정 테스트 환경을 대상으로 하도록 특별히 설계되었습니다.도구는 자동화 프로세스의 추진 주체 역할을 합니다.그러나 자동화 프레임워크는 특정 작업을 수행하는 도구가 아니라 서로 다른 도구가 통합된 방식으로 작업을 수행할 수 있는 솔루션을 제공하는 인프라스트럭처입니다.이것은 자동화 엔지니어를 위한 공통 플랫폼을 제공합니다.

틀에는 다양한 종류가 있습니다.이들은 활용하는 자동화 구성요소를 기준으로 분류됩니다.다음과 같습니다.

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

데이터 중심 테스트

이 단락은 데이터 기반 테스트에서 발췌한 것입니다.[편집]
데이터 기반 테스트(DDT), 테이블 기반 테스트 또는 파라미터화 테스트라고도 함,는 컴퓨터 소프트웨어의 테스트에 사용되는 소프트웨어 테스트 방법론으로, 테스트 환경 설정 및 제어가 하드 코딩되지 않은 프로세스뿐만 아니라 조건표를 직접 테스트 입력 및 검증 가능한 출력으로 사용하여 수행되는 테스트를 설명합니다.[22][23]가장 간단한 형태로 테스터는 표의 한 행에서 입력을 공급하고 같은 행에서 발생하는 출력을 예상합니다.표에는 일반적으로 경계 또는 파티션 입력 공간에 해당하는 값이 들어 있습니다.제어 방법론에서 테스트 구성은 데이터베이스에서 "읽기"됩니다.

모듈 중심 테스트

이 단락은 모듈 중심 테스트에서 발췌한 것입니다.[편집]
모듈화 기반 테스트는 소프트웨어 테스트에 사용되는 용어입니다.테스트 스크립트 모듈화 프레임워크를 사용하려면 테스트 대상 애플리케이션의 모듈, 섹션 및 기능을 나타내는 독립적인 작은 스크립트를 만들어야 합니다.그런 다음 이 작은 스크립트를 계층적 방식으로 사용하여 더 큰 테스트를 구성하여 특정 테스트 사례를 구현합니다.[24]

키워드 중심 테스트

이 단락들은 키워드 기반 테스트에서 발췌한 것입니다.[편집]
키워드 기반 테스트(action word based testing)라고도 하는 키워드 기반 테스트(keyword-driven testing)는 수동 및 자동 테스트 모두에 적합한 소프트웨어 테스트 방법론입니다.이 방법은 테스트 케이스의 문서화(사용할 데이터와 기능을 모두 포함)와 테스트 케이스의 실행 방법에 대한 처방을 분리합니다.따라서 테스트 작성 과정을 설계 및 개발 단계와 실행 단계로 구분하고 있습니다.설계 하위 단계에서는 요구사항 분석 및 평가, 데이터 분석, 정의 및 모집단을 다룹니다.

하이브리드 테스트

이 단락들은 하이브리드 테스트에서 발췌한 것입니다.[편집]
하이브리드 테스트는 대부분의 프레임워크가 시간이 지남에 따라 다양한 프로젝트로 진화/발전하는 것입니다.가장 성공적인 자동화 프레임워크는 일반적으로 정보 입력뿐만 아니라 문법과 철자 모두를 수용합니다.이를 통해 주어진 정보를 기존 정보와 확인된 정보와 교차 확인할 수 있습니다.이를 통해 허위 또는 오해의 소지가 있는 정보가 게시되는 것을 방지할 수 있습니다.그러나 여전히 다른 사람들이 기존 게시물에 새롭고 관련된 정보를 게시할 수 있으므로 사이트의 유용성과 관련성이 높아집니다.즉, 완벽한 시스템은 없으며 모든 과목에서 항상 이 표준을 수행할 수는 없지만 입력이 증가하고 사용이 증가함에 따라 개선될 것입니다.

모델 기반 테스트

이 섹션은 모델 기반 테스트에서 발췌한 내용입니다.[편집]
일반모델기반시험설정
모델 기반 테스트는 소프트웨어 테스트 또는 시스템 테스트를 수행하기 위해 아티팩트를 설계하고 선택적으로 실행하기 위한 모델 기반 설계의 응용 프로그램입니다.모델은 테스트 대상 시스템(SUT)의 원하는 동작을 나타내거나 테스트 전략 및 테스트 환경을 나타내는데 사용될 수 있습니다.오른쪽 그림은 이전 방식을 보여줍니다.

행동중심개발

이 단락은 행동 중심 개발에서 발췌한 것입니다.[편집]
소프트웨어 엔지니어링에서 행동 중심 개발(BDD, Behavior-Driven Development)은 소프트웨어 개발 프로세스로, 소프트웨어 프로젝트에서 개발자, 품질 보증 전문가 및 고객 담당자 간의 협업을 장려하는 민첩한 소프트웨어 개발 프로세스와 잘 맞는 소프트웨어 개발 프로세스입니다.[25][26][27]팀이 대화와 구체적인 예를 사용하여 애플리케이션이 어떻게 작동해야 하는지에 대한 공유된 이해를 공식화하도록 유도합니다.[28]테스트 중심 개발(TDD)에서 비롯되었습니다.[25][26][29][30][vague][31]행동 중심 개발은 TDD의 일반적인 기술과 원칙을 도메인 중심의 설계와 객체 중심의 분석 및 설계에서 나온 아이디어와 결합하여 소프트웨어 개발 및 관리 팀에 공유 도구와 소프트웨어 개발을 위한 공유 프로세스를 제공합니다.[26][31]

테스트할 내용

테스트 도구는 엔드 투 엔드 방식으로 테스트를 자동화하지 않고도 제품 설치, 테스트 데이터 생성, GUI 상호 작용, 문제 탐지(테스트 오라클이 장착된 파싱 또는 폴링 에이전트 고려), 결함 로깅 등의 작업을 자동화할 수 있습니다.

테스트 자동화를 생각할 때는 반드시 대중적인 요구사항을 충족시켜야 합니다.

테스트 자동화에서 AI의 역할

최근 몇 년간 테스트 자동화 분야는 인공지능(AI) 기술의 접목으로 큰 변화를 겪고 있습니다.AI는 테스트 자동화 관행에 상당한 영향을 미쳐 조직이 소프트웨어 테스트를 수행하는 방식에 혁신을 가져왔습니다.인공지능의 급속한 발전으로 소프트웨어 테스트가 더욱 효율적이고 효과적으로 이루어져 고품질의 소프트웨어 제품을 제공할 수 있게 되었습니다.인공지능 기반 솔루션은 지능형 테스트 생성 및 자가 치유 테스트와 같은 테스트 자동화에 몇 가지 주목할 만한 이점을 도입했습니다.이러한 혁신을 통해 테스트 사례를 자동으로 생성하고 테스트 프로세스를 최적화하며 잠재적인 문제를 신속하게 탐지할 수 있습니다.또한 테스트 자동화에서 AI는 테스트 범위를 확장하여 특히 웹 사용자 인터페이스, API, 모바일 애플리케이션 및 성능 테스트에서 테스트 범위를 강화했습니다.

그러나 테스트 자동화에서 AI를 통합하는 데 어려움이 없었던 것은 아닙니다.AI 모델은 정확한 예측과 테스트 사례 생성을 위해 고품질의 훈련 데이터에 광범위하게 의존하기 때문에 훈련 데이터에 대한 의존도는 중요한 고려 사항입니다.부적절하거나 편향된 교육 데이터는 오탐 또는 오탐을 초래하여 UI 테스트 자동화의 효과를 저하시킬 수 있습니다.또한 테스트 자동화에서 AI를 적용하면 SOAP 또는 GraphQL과 같은 복잡한 프로토콜을 처리하는 데 한계가 있을 수 있으며, 특정한 경우에 수동 개입이 필요합니다.[32]

참고 항목

참고문헌

  1. ^ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 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. ^ Brian Marick. "When Should a Test Be Automated?". StickyMinds.com. Retrieved 2009-08-20.
  5. ^ Garousi, Vahid; Mäntylä, Mika V. (2016-08-01). "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.
  6. ^ Vodde, Bas; Koskela, Lasse (2007). "Learning Test-Driven Development by Counting Lines". IEEE Software. 24 (3): 74–79. doi:10.1109/ms.2007.80. S2CID 30671391.
  7. ^ Amy Reichert, Search Software Quality 2015 March에 의한 API 테스트는 애플리케이션과 평판을 보호합니다.
  8. ^ API 테스트 정보: 조나단 쿠퍼와의 인터뷰, 카메론 필립 에드먼즈, 스티키마인드스 2014년 8월 19일
  9. ^ 계층형 테스트 전략을[dead link] 사용하여 더 나은 소프트웨어 제작(Sean Kenfick, Gartner 2014년 1월 7일)
  10. ^ 파이프라인의 일부: Adam Auerbach, 2015년 8월 TechWell Insights의 지속적인 테스트가 필수인 이유
  11. ^ 리스크와 지속적인 테스트의 관계: Wayne Ariola와의 인터뷰, Cameron Philipp-Edmonds, Stickyminds 2015년 12월
  12. ^ DevOps: Wayne Ariola and Cynthia Dunlop, 2015년 10월 PNSQC에 의해 작성된 벅스를 고객에게 더 빠르게 제공하고 있습니까?
  13. ^ 브라우저를 통한 헤드리스 테스트; https://docs.travis-ci.com/user/gui-and-headless-browsers/
  14. ^ 팬텀을 이용한 헤드리스 테스트JS;http://phantomjs.org/headless-testing.html
  15. ^ 자동화된 사용자 인터페이스 테스트; https://www.devbridge.com/articles/automated-user-interface-testing/
  16. ^ a b c Mike Cohn (2010). Succeeding with Agile. Raina Chrobak. ISBN 978-0-321-57936-2.
  17. ^ "Full Stack Testing by Gayathri Mohan". www.thoughtworks.com. Retrieved 2022-09-13.
  18. ^ 실검 피라미드, 함 보케
  19. ^ a b "Just Say No to More End-to-End Tests". Google Testing Blog. Retrieved 2023-02-11.
  20. ^ "Selenium Meet-Up 4/20/2010 Elisabeth Hendrickson on Robot Framework 1of2". Retrieved 2010-09-26.
  21. ^ a b c "Conquest: Interface for Test Automation Design" (PDF). Archived from the original (PDF) on 2012-04-26. Retrieved 2011-12-11.
  22. ^ "golang/go TableDrivenTests". GitHub.
  23. ^ "JUnit 5 User Guide". junit.org.
  24. ^ DESAI, SANDEEP; SRIVASTAVA, ABHISHEK (2016-01-30). SOFTWARE TESTING : A Practical Approach (in Arabic). PHI Learning Pvt. Ltd. ISBN 978-81-203-5226-1.
  25. ^ a b North, Dan (March 2006). "Introducing BDD". Dan North. Retrieved 25 April 2019.
  26. ^ a b c "Behaviour-Driven Development". Archived from the original on 1 September 2015. Retrieved 12 August 2012.
  27. ^ Keogh, Liz (2009-09-07). "Introduction to Behavior-Driven Development". SkillsMatter. Retrieved 1 May 2019.
  28. ^ John Ferguson Smart (2014). BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle. Manning Publications. ISBN 9781617291654.
  29. ^ Haring, Ronald (February 2011). de Ruiter, Robert (ed.). "Behavior Driven development: Beter dan Test Driven Development". Java Magazine (in Dutch). Veen Magazines (1): 14–17. ISSN 1571-6236.
  30. ^ Solis, Carlos; Wang, Xiaofeng (2011). "A Study of the Characteristics of Behaviour Driven Development". 2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications. pp. 383–387. doi:10.1109/SEAA.2011.76. hdl:10344/1256. ISBN 978-1-4577-1027-8. S2CID 3392536.
  31. ^ a b Bellware, Scott (June 2008). "Behavior-Driven Development". Code Magazine. Archived from the original on 12 July 2012. Retrieved 1 May 2019.
  32. ^ "AI In Test Automation: 8 Undeniables Benefits MuukTest". 2023-06-05. Retrieved 2023-09-18.

일반참고문헌