단위 테스트, 통합 테스트, 연기 테스트 및 회귀 테스트 란 무엇입니까?

단위 테스트, 통합 테스트, 연기 테스트 및 회귀 테스트 란 무엇입니까? 그들 사이의 차이점과 각 도구에 사용할 수있는 도구는 무엇입니까?

예를 들어, 단위 테스트 및 통합 테스트에 JUnit 및 NUnit 을 사용 합니다. 마지막 두 가지, 연기 테스트 또는 회귀 테스트를 위한 도구가 있습니까?

• 단위 테스트 : 클래스의 단일 방법 계약의 한 지점을 지정하고 테스트합니다. 이것은 매우 좁고 잘 정의 된 범위를 가져야합니다. 외부 세계와의 복잡한 의존성과 상호 작용은 스터 빙되거나 조롱 됩니다.

• 통합 테스트 : 여러 하위 시스템의 올바른 상호 운용성을 테스트합니다. 두 클래스 간의 통합 테스트에서 프로덕션 환경과의 통합 테스트에 이르기까지 전체 스펙트럼이 있습니다.

• 스모크 테스트 (일명 위생 검사) : 테스트중인 시스템이 호출 될 때 정상적으로 돌아가고 터지지 않는지 확인하는 간단한 통합 테스트입니다.

  • 연기 테스트는 전자 장치와 유사하며 회로를 켤 때 첫 번째 테스트가 발생합니다 (흡연하면 나쁩니다!) ...
  • ... 그리고 명백하게 와 배관 파이프 시스템이 그대로 연기에 의해 채워진 후 육안된다. 연기가 나면 시스템이 누출 된 것입니다.

• 회귀 테스트 : 버그가 수정되었을 때 작성된 테스트입니다. 이 특정 버그가 다시 발생하지 않도록합니다. 전체 이름은 "비 회귀 테스트"입니다. 응용 프로그램을 변경하기 전에 응용 프로그램이 동일한 결과를 제공하는지 확인하기위한 테스트 일 수도 있습니다.

여기에 다음을 추가합니다.

• 승인 테스트 : 기능 또는 사용 사례가 올바르게 구현되었는지 테스트합니다. 통합 테스트와 비슷하지만 관련된 구성 요소가 아닌 제공 사례에 중점을 둡니다.

• 시스템 테스트 : 시스템을 블랙 박스로 테스트합니다. 다른 시스템에 대한 종속성은 종종 테스트 중에 모의되거나 스터 빙됩니다 (그렇지 않으면 통합 테스트에 가깝습니다).

• 비행 전 점검 : 프로덕션 환경에서 반복되는 테스트로 '내 기계의 빌드'증후군을 완화합니다. 이것은 종종 환경과 같은 프로덕션에서 수락 또는 연기 테스트를 수행하여 실현됩니다.

• 단위 테스트 : 수업의 내부 작업을 테스트하는 자동 테스트. 다른 리소스와 관련이없는 독립형 테스트 여야합니다.
• 통합 테스트 : 환경에서 수행되는 자동 테스트로 단위 테스트와 유사하지만 외부 리소스 (db, 디스크 액세스)
• 회귀 테스트 : 새로운 기능이나 버그 수정을 구현 한 후 과거에 작동했던 시나리오를 다시 테스트합니다. 여기에서는 새로운 기능이 기존 기능을 손상시킬 가능성을 다룹니다.
• 연기 테스트 : 테스터가 테스트를 계속할 것인지 결론을 내릴 수있는 첫 번째 테스트.

모든 사람은 약간 다른 정의를 갖게되며 종종 회색 영역이 있습니다. 하나:

• 단위 테스트 :이 작은 부분 (가능한 한 고립 된)이 작동합니까?
• 통합 테스트 :이 두 개 이상의 구성 요소가 함께 작동합니까?
• 연기 테스트 :이 전체 시스템 (가능한 한 생산 시스템에 가깝습니다)이 합리적으로 잘 연결되어 있습니까? (즉, 블랙홀을 만들지 않을 것이라고 확신합니까?)
• 회귀 테스트 : 이전에 수정 한 버그를 실수로 다시 도입 했습니까?

내가 방금 알게 된 새로운 테스트 범주는 카나리아 테스트 입니다. 카나리아 테스트는 실제 환경 에서 정기적으로 실행 되는 자동화 된 비파괴 테스트로 , 실패하면 실제로 나쁜 일이 발생했습니다.

예를 들면 다음과 같습니다.

• 출연 오직 개발 / 퉁명스러운에서 사용할 수 있어야 데이터를 가지고 라이브를 ?
• 백그라운드 프로세스가 실행되지 않았습니까?
• 사용자가 로그온 할 수 있습니까?

소프트웨어 테스트 기술을위한 최고의 웹 사이트 중 하나에서 답변하십시오.

소프트웨어 테스트의 종류 – 전체 목록 여기를 클릭하십시오

꽤 긴 설명이며 여기에 붙여 넣지 않을 것입니다. 그러나 모든 테스트 기술을 알고 싶은 사람에게는 도움이 될 수 있습니다.

단위 테스트 : 특정 구성 요소 (예 : 클래스)가 설계된대로 기능을 작성 또는 수정했는지 확인 이 테스트는 수동 또는 자동화가 가능하지만 구성 요소의 경계를 넘어서는 것은 아닙니다.

통합 테스트 : 특정 구성 요소의 상호 작용이 설계된대로 작동하는지 확인 통합 테스트는 단위 레벨 또는 시스템 레벨에서 수행 할 수 있습니다. 이러한 테스트는 수동 또는 자동화 될 수 있습니다.

회귀 테스트 : 기존 코드에 새로운 결함이 없는지 확인합니다. 이러한 테스트는 수동 또는 자동화 될 수 있습니다.

당신에 따라 SDLC ( 폭포 , RUP , 민첩 등) 특히 테스트 '단계'에서 수행 될 수있다 또는 모두 수행 할 수있다, 더 많거나 적은, 같은 시간에. 예를 들어, 단위 테스트는 통합 및 회귀 테스트를 위해 코드를 테스터에게 넘기는 개발자로 제한 될 수 있습니다. 그러나 다른 접근 방식에는 개발자가 단위 테스트 및 일정 수준의 통합 및 회귀 테스트를 수행 할 수 있습니다 ( 연속 통합 및 자동화 된 단위 및 회귀 테스트와 함께 TDD 접근 방법 사용 ).

툴 세트는 코드베이스에 크게 의존하지만 단위 테스트 (JUnit)를위한 많은 오픈 소스 툴이 있습니다. HP의 (Mercury) QTP 또는 Borland의 Silk Test 는 모두 자동 통합 및 회귀 테스트를위한 도구입니다.

단위 테스트 : 응용 프로그램에서 개별 모듈 또는 독립 구성 요소의 테스트는 단위 테스트 로 알려져 있습니다. 단위 테스트는 개발자가 수행합니다.

통합 테스트 : 모든 모듈을 결합하고 응용 프로그램을 테스트하여 모듈 간의 통신 및 데이터 흐름이 올바르게 작동하는지 확인합니다. 이 테스트는 개발자도 수행했습니다.

연기 테스트 연기 테스트 에서 응용 프로그램을 얕고 넓은 방식으로 확인합니다. 연기 테스트에서 응용 프로그램의 주요 기능을 확인합니다. 응용 프로그램에 차단 문제가있는 경우 개발자 팀에보고하고 개발 팀에서이를 해결하고 결함을 수정 한 후 테스트 팀에 다시 제공합니다. 이제 테스트 팀은 모든 모듈을 검사하여 한 모듈에서 변경 한 내용이 다른 모듈에 영향을 미치는지 확인합니다. 연기 테스트 에서는 테스트 사례가 스크립팅됩니다.

변경되지 않은 모듈이 결함을 일으키지 않도록 동일한 테스트 케이스를 반복적으로 실행하는 회귀 테스트 . 회귀 테스트 기능 테스트 수행

등록 테스트

"회귀 테스트는 현재 소프트웨어의 변경 사항이 기존 소프트웨어의 기능에 영향을 미치지 않도록 변경된 소프트웨어에 대해 이전 테스트를 다시 실행합니다."

방금 우리가 왜 이러한 테스트 레벨을 가지고 있는지, 예제에서 실제로 의미하는 바에 대해 더 많이 설명하고 싶었습니다.

Mike Cohn은 자신의 저서 "성공으로 성공"에서 프로젝트의 자동화 된 테스트에 접근하는 방법으로 "Testing Pyramid"를 제시했습니다. 이 모델에 대한 다양한 해석이 있습니다. 이 모델에서는 어떤 종류의 자동 테스트를 작성해야하는지, 테스트중인 애플리케이션에 대한 피드백을 얼마나 빨리 제공 할 수 있으며 누가이 테스트를 작성하는지 설명합니다. 기본적으로 모든 프로젝트에 필요한 3 가지 수준의 자동 테스트가 있으며 다음과 같습니다.

단위 테스트-소프트웨어 응용 프로그램의 가장 작은 구성 요소를 테스트합니다. 이것은 문자 그대로 일부 입력을 기반으로 값을 계산하는 코드의 함수 일 수 있습니다. 이 기능은 응용 프로그램을 구성하는 하드웨어 / 소프트웨어 코드베이스의 다른 여러 기능 중 일부입니다.

예를 들어-웹 기반 계산기 응용 프로그램을 보자. 단위 테스트가 필요한이 애플리케이션의 가장 작은 구성 요소는 더하기를 수행하는 함수일 수도 있고 빼기 등을 수행하는 함수일 수도 있습니다. 이 모든 작은 기능들이 합쳐져서 계산기 응용 프로그램을 구성합니다.

역사적으로 개발자는 일반적으로 소프트웨어 응용 프로그램과 동일한 프로그래밍 언어로 작성된 테스트를 작성합니다. JUnit 및 NUnit (java의 경우), MSTest (C # 및 .NET의 경우) 및 Jasmine / Mocha (JavaScript의 경우)와 같은 단위 테스트 프레임 워크가이 목적으로 사용됩니다.

단위 테스트의 가장 큰 장점은 UI 아래에서 실제로 빠르게 실행되며 응용 프로그램에 대한 빠른 피드백을 얻을 수 있다는 것입니다. 이는 자동화 된 테스트의 50 % 이상을 구성해야합니다.

API / 통합 테스트-소프트웨어 시스템의 다양한 구성 요소를 함께 테스트합니다. 구성 요소에는 테스트 데이터베이스, API (Application Programming Interface), 타사 도구 및 서비스와 응용 프로그램이 포함될 수 있습니다.

예를 들어-위의 계산기 예에서 웹 응용 프로그램은 데이터베이스를 사용하여 값을 저장하고 API를 사용하여 일부 서버 측 유효성 검사를 수행하며 타사 도구 / 서비스를 사용하여 결과를 클라우드에 게시하여 다른 곳에서 사용할 수 있도록 할 수 있습니다 플랫폼.

역사적으로 개발자 또는 기술 QA는 Postman, SoapUI, JMeter와 같은 다양한 도구 및 Testim과 같은 다른 도구를 사용하여 이러한 테스트를 작성했습니다.

이것들은 여전히 ​​후드 아래에서 실행되기 때문에 UI 테스트보다 훨씬 빠르게 실행되지만 시스템의 다양한 독립 구성 요소 간의 통신을 확인하고 완벽하게 통합되도록 보장해야하기 때문에 단위 테스트보다 약간 더 많은 시간이 소요될 수 있습니다. 이는 자동화 된 테스트의 30 % 이상을 구성해야합니다.

UI 테스트- 마지막으로 애플리케이션의 UI를 검증하는 테스트가 있습니다. 이러한 테스트는 일반적으로 애플리케이션을 통한 엔드 투 엔드 흐름을 테스트하기 위해 작성됩니다.

예를 들어-계산기 애플리케이션에서 브라우저를 열고 엔드 투 엔드 플로우를 사용할 수 있습니다.-> 계산기 애플리케이션 URL 입력-> 사용자 이름 / 비밀번호로 로그인-> 계산기 애플리케이션 열기-> 계산기에서 일부 조작 수행 -> UI에서 결과 확인-> 응용 프로그램에서 로그 아웃 이것은 UI 자동화에 적합한 엔드 투 엔드 흐름 일 수 있습니다.

역사적으로 기술 QA 또는 수동 테스터는 UI 테스트를 작성합니다. 이들은 Selenium과 같은 오픈 소스 프레임 워크 또는 Testim과 같은 UI 테스트 플랫폼을 사용하여 테스트를 작성, 실행 및 유지합니다. 이러한 테스트는 테스트 실행 방법, 스크린 샷, 로그, 테스트 보고서를 통한 예상 결과와 실제 결과의 차이를 확인할 수있는 시각적 인 피드백을 제공합니다.

UI 테스트의 가장 큰 한계는 단위 및 API 레벨 테스트에 비해 상대적으로 느립니다. 따라서 전체 자동화 테스트의 10-20 % 만 구성해야합니다.

다음 두 가지 유형의 테스트는 프로젝트에 따라 달라질 수 있지만 아이디어는

연기 테스트

이것은 위의 3 가지 레벨의 테스트 조합 일 수 있습니다. 아이디어는 모든 코드 체크인 중에이를 실행하고 시스템의 중요한 기능이 여전히 예상대로 작동하는지 확인하는 것입니다. 새 코드 변경 사항이 병합 된 후 장애에 대한 빠른 피드백을 얻으려면 일반적으로 5-10 분 동안 실행해야합니다.

회귀 테스트

보통 하루에 한 번 실행되며 시스템의 다양한 기능을 포함합니다. 응용 프로그램이 여전히 예상대로 작동하는지 확인합니다. 연기 테스트보다 자세한 내용이며 중요하지 않은 테스트를 포함하여 더 많은 응용 프로그램 시나리오를 다룹니다.

단위 테스트 는 구현의 가장 작은 부분을 대상으로합니다. Java에서 이것은 단일 클래스를 테스트하고 있음을 의미합니다. 클래스가 다른 클래스에 의존하는 경우 위조됩니다.

테스트에서 둘 이상의 클래스를 호출하면 통합 테스트 입니다.

전체 테스트 스위트를 실행하는 데 시간이 오래 걸릴 수 있으므로 변경 후 많은 팀이 빠른 테스트를 실행하여 심각한 손상을 감지합니다. 예를 들어, URI를 필수 자원으로 분리했습니다. 이것들은 연기 테스트 입니다.

회귀 테스트 는 모든 빌드에서 실행되며 중단 된 부분을 파악하여 효과적으로 리팩토링 할 수 있습니다. 모든 종류의 테스트는 회귀 테스트 일 수 있지만, 단위 테스트가 결함의 원인을 찾는 데 가장 도움이된다는 것을 알았습니다.

• 통합 테스트 : 통합 테스트는 다른 요소를 통합합니다.
• 연기 테스트 : 연기 테스트는 빌드 버전 테스트라고도합니다. 연기 테스트는 테스트중인 소프트웨어가 추가 테스트를 위해 준비 / 안정되어 있는지 확인하기 위해 수행되는 초기 테스트 프로세스입니다.
• 회귀 테스트 : 회귀 테스트는 반복 테스트입니다. 새 소프트웨어가 다른 모듈에서 적용되는지 여부
• 단위 테스트 : 화이트 박스 테스트입니다. 개발자 만이 참여

단위 테스트 : 특정 구성 요소 (예 : 클래스)가 설계된대로 기능을 작성 또는 수정했는지 확인 이 테스트는 수동 또는 자동화가 가능하지만 구성 요소의 경계를 벗어나지 않습니다.

통합 테스트 : 특정 구성 요소의 상호 작용이 설계된대로 작동하는지 확인 통합 테스트는 단위 레벨 또는 시스템 레벨에서 수행 할 수 있습니다. 이러한 테스트는 수동 또는 자동화 될 수 있습니다.

회귀 테스트 : 기존 코드에 새로운 결함이 없는지 확인합니다. 이러한 테스트는 수동 또는 자동화 될 수 있습니다.

SDLC (폭포, rup, agile 등)에 따라 특정 테스트는 '단계'에서 수행되거나 모두 다소 동시에 수행 될 수 있습니다. 예를 들어, 단위 테스트는 통합 및 회귀 테스트를 위해 코드를 테스터에게 넘기는 개발자로 제한 될 수 있습니다. 그러나 다른 접근 방식은 개발자가 단위 테스트 및 일정 수준의 통합 및 회귀 테스트를 수행 할 수 있습니다 (연속 통합 및 자동화 된 단위 및 회귀 테스트와 함께 TDD 접근 방법 사용).

단위 테스트 단위 테스트는 응용 프로그램의 소스와 가까운 수준으로 매우 낮은 수준입니다. 소프트웨어에서 사용하는 클래스, 구성 요소 또는 모듈의 개별 방법 및 기능을 테스트하는 과정으로 구성됩니다. 단위 테스트는 일반적으로 자동화하기에 상당히 저렴하며 지속적인 통합 서버를 통해 매우 빠르게 실행할 수 있습니다.

통합 테스트 통합 테스트는 응용 프로그램에서 사용하는 다양한 모듈 또는 서비스가 함께 작동하는지 확인합니다. 예를 들어 데이터베이스와의 상호 작용을 테스트하거나 마이크로 서비스가 예상대로 작동하는지 확인할 수 있습니다. 이러한 유형의 테스트는 여러 부분의 응용 프로그램을 시작하고 실행해야하므로 실행 비용이 더 많이 듭니다.

기능 테스트 기능 테스트는 응용 프로그램의 비즈니스 요구 사항에 중점을 둡니다. 작업의 출력 만 확인하고 해당 작업을 수행 할 때 시스템의 중간 상태를 확인하지 않습니다.

통합 테스트와 기능 테스트는 서로 상호 작용하기 위해 여러 구성 요소가 필요하기 때문에 때로는 혼동이 있습니다. 차이점은 통합 테스트는 단순히 데이터베이스를 쿼리 할 수 ​​있는지 확인하는 반면 기능 테스트는 제품 요구 사항에 정의 된대로 데이터베이스에서 특정 값을 얻을 것으로 예상한다는 것입니다.

엔드 투 엔드 테스트 엔드 투 엔드 테스트는 완전한 응용 프로그램 환경에서 소프트웨어로 사용자 동작을 복제합니다. 다양한 사용자 흐름이 예상대로 작동하는지 확인하고 웹 페이지를로드하거나 전자 메일 알림, 온라인 지불 등을 확인하는 훨씬 복잡한 시나리오에 로그인하는 것처럼 간단 할 수 있습니다 ...

엔드-투-엔드 테스트는 매우 유용하지만 수행 비용이 많이 들고 자동화 될 때 유지하기가 어려울 수 있습니다. 주요 엔드 투 엔드 테스트를 몇 개 실시하고 하위 수준의 테스트 유형 (단위 및 통합 테스트)에 더 의존하여 주요 변경 사항을 신속하게 식별 할 수 있습니다.

승인 테스트 승인 테스트는 시스템이 비즈니스 요구 사항을 충족하는지 확인하기 위해 실행되는 공식 테스트입니다. 전체 응용 프로그램이 시작되어 실행 중이어야하며 사용자 동작 복제에 중점을 둡니다. 그러나 더 나아가서 시스템 성능을 측정하고 특정 목표가 충족되지 않으면 변경 사항을 거부 할 수 있습니다.

성능 테스트 성능 테스트는 시스템의 부하가 클 때 시스템의 동작을 확인합니다. 이러한 테스트는 작동하지 않으며 플랫폼의 안정성, 안정성 및 가용성을 이해하기 위해 다양한 형태를 가질 수 있습니다. 예를 들어, 많은 수의 요청을 실행할 때 응답 시간을 관찰하거나 시스템이 중요한 데이터로 작동하는 방식을 볼 수 있습니다.

성능 테스트는 본질적으로 구현 및 실행 비용이 많이 들지만 새로운 변경 사항으로 인해 시스템 성능이 저하되는지 이해하는 데 도움이됩니다.

연기 테스트 연기 테스트는 응용 프로그램의 기본 기능을 확인하는 기본 테스트입니다. 빠른 실행을 목표로하며 시스템의 주요 기능이 예상대로 작동하고 있음을 보증하는 것이 목표입니다.

Smoke 테스트는 새로운 빌드가 이루어진 직후에 더 비싼 테스트를 실행할 수 있는지 여부를 결정하거나 배포 직후에 새로 배포 된 환경에서 응용 프로그램이 제대로 실행되고 있는지 확인하는 데 유용 할 수 있습니다.

출처 : https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

단위 테스트 : QA 준비가되기 전에 테스트 측에서 문제를 찾기 위해 개발 후 개발자가 항상 수행합니다.

통합 테스트 : 일부 데이터 / 기능 출력이 한 모듈에서 다른 모듈로 구동 될 때 테스터가 모듈 대 서브 모듈 확인을 확인해야 함을 의미합니다. 또는 시스템 데이터를 통합하는 타사 도구를 사용하는 경우 시스템에서.

연기 테스트 : 테스터는 높은 수준의 테스트를 위해 시스템을 확인하고 변경 또는 코드가 실행되기 전에 쇼 스토퍼 버그를 찾으려고 수행했습니다.

회귀 테스트 : 테스터는 시스템의 새로운 향상 또는 변경을 위해 시스템에서 구현 된 변경으로 인해 기존 기능의 검증을 위해 회귀를 수행했습니다.

단위 테스트

단위 테스트는 일반적으로 개발자가 수행하는 반면 테스터는 테스트가 단위로 수행되는 이러한 유형의 테스트에서 부분적으로 발전합니다. Java JUnit 테스트 케이스에서는 작성된 코드가 완벽하게 설계되었는지 여부를 테스트 할 수도 있습니다.

통합 테스트 :

이 유형의 테스트는 모든 / 일부 구성 요소가 통합 된 경우 장치 테스트 후에 가능합니다. 이러한 유형의 테스트는 구성 요소가 통합 될 때 서로의 작업 기능에 영향을 미치는지 확인합니다.

연기 테스트

이 유형의 테스트는 시스템이 성공적으로 통합되고 프로덕션 서버로 이동할 준비가되었을 때 마지막에 수행됩니다.

이러한 유형의 테스트를 통해 처음부터 끝까지 모든 중요한 기능이 제대로 작동하고 시스템을 프로덕션 서버에 배포 할 수 있습니다.

회귀 테스트

이 유형의 테스트는 개발자가 일부 문제를 해결했을 때 시스템에 의도하지 않은 / 원치 않는 결함이 없는지 테스트하는 데 중요합니다. 이 테스트는 또한 모든 버그가 성공적으로 해결되었으며 다른 문제가 발생하지 않았는지 확인합니다.

연기 및 위생 테스트는 소프트웨어 빌드 후에 테스트 시작 여부를 식별하기 위해 수행됩니다. 연기 테스트 후 위생은 실행되거나 실행되지 않을 수 있습니다. 그것들은 별도로 또는 동시에 실행될 수 있습니다-연기 직후에 정신이 나옵니다.

온 전성 테스트는보다 심층적이고 시간이 더 걸리기 때문에 대부분의 경우 자동화하는 것이 좋습니다.

연기 테스트는 일반적으로 실행에 5 ~ 30 분이 소요됩니다. 더 일반적입니다. 소프트웨어의 안정성이 추가 테스트에 충분하고 문제가 없는지 계획된 테스트 사례의 실행을 차단하기 위해 전체 시스템의 소수의 핵심 기능을 검사합니다.

위생 테스트는 연기보다 더 상세하며 새로운 빌드의 규모에 따라 15 분에서 하루까지 걸릴 수 있습니다. 진행 또는 재시험 후 수행되는보다 특수한 유형의 합격 시험입니다. 회귀 테스트가 더 큰 규모로 실행되기 전에 필요한 새로운 기능 및 / 또는 버그 수정과 함께 해당 기능과 밀접하게 관련된 일부 기능을 확인하여 필요한 작동 논리에 대해 작동하는지 확인합니다.

이미 좋은 답변이 있지만 더 세분화하고 싶습니다.

여기서 단위 테스트는 화이트 박스 테스트의 유일한 형태입니다. 다른 것은 블랙 박스 테스트입니다. 화이트 박스 테스트는 입력 내용을 알고 있음을 의미합니다. 메커니즘의 내부 작동을 알고이를 검사 할 수 있으며 출력을 알고 있습니다. 블랙 박스 테스트를 통해 입력 내용과 출력 내용 만 알 수 있습니다.

따라서 단위 테스트는 여기서 유일한 화이트 박스 테스트입니다.

• 단위 테스트는 특정 코드 조각을 테스트합니다. 일반적으로 방법.
• 통합 테스트는 새로운 기능의 소프트웨어가 다른 모든 것과 통합 될 수 있는지 테스트합니다.
• 회귀 테스트. 이것은 당신이 아무것도 부러지지 않았는지 확인하기 위해 수행되는 테스트입니다. 작동하던 모든 것이 여전히 작동합니다.
• 연기 테스트는보다 강력한 테스트에 참여하기 전에 모든 것이 정상인지 확인하기위한 빠른 테스트로 수행됩니다.

연기 테스트는 이미 여기에서 설명되었으며 간단합니다. 회귀 테스트는 통합 테스트를받습니다.

자동 테스트는 두 가지로 나눌 수 있습니다.

단위 테스트 및 통합 테스트 (이것이 전부입니다)

통합 테스트, 기능 테스트, 회귀 테스트, UI 테스트 등과 같은 모든 테스트에 대해 "긴 테스트"(LT)라는 문구를 사용하고 단위 테스트는 "짧은 테스트"라고합니다.

LT의 예로는 자동으로 웹 페이지를로드하고 계정에 로그인하여 책을 구입할 수 있습니다. 테스트가 통과되면 라이브 사이트에서 동일한 방식으로 실행될 가능성이 높습니다 (따라서 '더 나은 절전'참조). Long = 웹 페이지 (시작)와 데이터베이스 (끝) 사이의 거리입니다.

그리고 이것은 단위 테스트에 비해 통합 테스트 (긴 테스트) 의 이점을 논의하는 훌륭한 기사 입니다.

회귀 테스트-버그 수정 을 다루거나 확인하려고하는 소프트웨어 테스트 유형입니다 . 제공된 수정 사항으로 인해 버그 수정 주위의 기능이 변경되거나 변경되지 않아야합니다. 이러한 과정에서 발견 된 문제를 회귀 문제 라고 합니다. .

연기 테스트 : 추가 QA 테스트를 위해 빌드 / 소프트웨어를 수락할지 여부를 결정하기 위해 수행되는 테스트입니다.