메뉴

회귀 테스트 란 무엇입니까? 정의, 도구, 방법 및 예

what is regression testing

문제를 제거하기 위해 도구를 사용해보십시오

json 파일을 여는 방법

회귀 테스트 란 무엇입니까?

회귀 테스트는 소프트웨어의 코드 변경이 제품의 기존 기능에 영향을 미치지 않는지 확인하기 위해 수행되는 테스트 유형입니다. 이는 제품이 새로운 기능, 버그 수정 또는 기존 기능의 변경 사항으로 제대로 작동하는지 확인하기위한 것입니다. 변경의 영향을 확인하기 위해 이전에 실행 된 테스트 케이스를 다시 실행합니다.

=> 전체 테스트 계획 튜토리얼 시리즈를 보려면 여기를 클릭하십시오.

회귀 테스트 란?

회귀 테스트는 응용 프로그램의 이전 기능이 제대로 작동하고 새로운 변경 사항으로 인해 새로운 버그가 발생하지 않았는지 확인하기 위해 테스트 사례가 다시 실행되는 소프트웨어 테스트 유형입니다.

이 테스트는 단일 버그 수정에서도 원래 기능이 크게 변경된 경우 새 빌드에서 수행 할 수 있습니다.

회귀는 응용 프로그램의 변경되지 않은 부분을 다시 테스트하는 것을 의미합니다.

학습 내용 :

이 시리즈에서 다루는 자습서

튜토리얼 # 1 : 회귀 테스트 란? (이 튜토리얼)
튜토리얼 # 2 : 회귀 테스트 도구
튜토리얼 # 3 : 회귀 테스트 대 재 테스트
튜토리얼 # 4 : Agile의 자동화 된 회귀 테스트

회귀 테스트 개요

회귀 테스트는 확인 방법과 같습니다. 테스트 케이스는 반복해서 실행해야하고 동일한 테스트 케이스를 수동으로 반복해서 실행하는 것은 시간이 많이 걸리고 지루하기 때문에 일반적으로 자동화됩니다.

예를 들어 확인, 수락 및 발송 버튼을 클릭 할 때 확인, 수락 및 발송 된 이메일을 트리거하는 기능 중 하나 인 제품 X를 고려하십시오.

확인 이메일에서 일부 문제가 발생하며 동일한 문제를 해결하기 위해 일부 코드 변경이 수행됩니다. 이 경우 확인 이메일뿐만 아니라 승인 및 발송 된 이메일도 테스트하여 코드 변경이 영향을받지 않았는지 확인해야합니다.

회귀 테스트는 Java, C ++, C # 등과 같은 프로그래밍 언어에 종속되지 않습니다. 제품의 수정 또는 수행중인 업데이트를 테스트하는 데 사용되는 테스트 방법입니다. 제품의 수정이 제품의 기존 모듈에 영향을 미치지 않는지 확인합니다.

버그가 수정되었고 새로 추가 된 기능이 이전 작업 버전의 소프트웨어에서 문제를 일으키지 않았는지 확인합니다.

테스터는 검증을 위해 새 빌드를 사용할 수있을 때 기능 테스트를 수행합니다. 이 테스트의 목적은 기존 기능과 새로 추가 된 기능의 변경 사항을 확인하는 것입니다.

이 테스트가 완료되면 테스터는 기존 기능이 예상대로 작동하는지 그리고 새로운 변경으로 인해이 변경 이전에 작동하던 기능에 결함이 없는지 확인해야합니다.

회귀 테스트는 릴리스주기의 일부 여야하며 테스트 추정에서 고려해야합니다.

이 테스트를 언제 수행해야합니까?

회귀 테스트는 일반적으로 변경 사항이나 새로운 기능을 확인한 후에 수행됩니다. 그러나 항상 그런 것은 아닙니다. 완료하는 데 수개월이 걸리는 릴리스의 경우 회귀 테스트를 일일 테스트주기에 통합해야합니다. 주간 릴리스의 경우 변경 사항에 대한 기능 테스트가 끝나면 회귀 테스트를 수행 할 수 있습니다.

회귀 검사는 재 테스트의 변형입니다 (단순히 테스트를 반복하는 것임). 다시 테스트 할 때 이유는 무엇이든 될 수 있습니다. 특정 기능을 테스트 중이 었는데 하루가 끝났다고 가정 해 보겠습니다. 테스트를 완료 할 수 없었고 테스트의 통과 / 실패 여부를 결정하지 않고 프로세스를 중지해야했습니다.

다음날 돌아 오면 다시 한 번 테스트를 수행합니다. 즉, 이전에 수행 한 테스트를 반복한다는 의미입니다. 테스트를 반복하는 간단한 행위는 재 테스트입니다.

회귀 테스트의 핵심은 일종의 재 테스트입니다. 응용 프로그램 / 코드의 내용이 변경된 특별한 경우에만 해당됩니다. 코드, 디자인 또는 시스템의 전체 프레임 워크를 결정하는 모든 것이 될 수 있습니다.

이러한 변경 사항이 이전에 이미 작동하던 항목에 영향을주지 않았는지 확인하기 위해이 상황에서 수행되는 재 테스트를 회귀 테스트라고합니다. 이것이 수행되는 가장 일반적인 이유는 코드의 새 버전이 생성되었거나 (범위 / 요구 사항 증가) 버그가 수정 되었기 때문입니다.

회귀 테스트를 수동으로 수행 할 수 있습니까?

저는 최근 수업 중 어느 날을 가르치고 있었는데 '회귀를 수동으로 수행 할 수 있습니까?'라는 질문이 나왔습니다.

나는 질문에 답했고 우리는 수업을 계속했다. 모든 것이 괜찮아 보였지만 어떻게 든이 질문은 잠시 후 나를 괴롭 혔습니다.

여러 배치에서이 질문은 다양한 방식으로 여러 번 발생합니다. 그들 중 일부는 다음과 같습니다.

  • 테스트 실행을 수행하려면 도구가 필요합니까?
  • 회귀 테스트는 어떻게 수행됩니까?
  • 전체 테스트를 마친 후에도 신규 이민자들은 회귀 테스트가 정확히 무엇인지 식별하기가 어렵습니까?

그리고 물론 원래 질문 :

  • 이 테스트를 수동으로 수행 할 수 있습니까?

우선 첫째로, 테스트 실행 테스트 케이스를 사용하고 AUT에서 해당 단계를 수행하고 테스트 데이터를 제공하고 AUT에서 얻은 결과를 테스트 케이스에 언급 된 예상 결과와 비교하는 간단한 작업입니다.

비교 결과에 따라 테스트 케이스 합격 / 불합격 상태를 설정합니다. 테스트 실행은 간단합니다.이 프로세스에 필요한 특별한 도구는 없습니다.

자동화 된 회귀 테스트 도구

Automated Regression Test는 대부분의 테스트 작업을 자동화 할 수있는 테스트 영역입니다. 이전에 실행 한 모든 테스트 케이스를 새 빌드에서 실행합니다.

즉, 테스트 케이스 세트를 사용할 수 있으며 이러한 테스트 케이스를 수동으로 실행하려면 시간이 많이 걸립니다. 예상 결과를 알고 있으므로 이러한 테스트 사례를 자동화하면 시간이 절약되고 효율적인 회귀 테스트 방법입니다. 자동화의 범위는 초과 근무에 적용 할 수있는 테스트 사례의 수에 따라 다릅니다.

테스트 케이스가 수시로 변하는 경우 애플리케이션 범위가 계속 증가하고 회귀 절차의 자동화는 시간 낭비가 될 것입니다.

대부분의 회귀 테스트 도구는 기록 및 재생 유형입니다. AUT (테스트중인 애플리케이션)를 탐색하여 테스트 케이스를 기록하고 예상 결과가 나오는지 여부를 확인합니다.

도구

이들 중 대부분은 기능 및 회귀 테스트 도구입니다.

추천 자료 => 여기에서 상위 회귀 도구 목록을 확인하십시오.

자동화 테스트 스위트에서 회귀 테스트 케이스를 추가하고 업데이트하는 것은 번거로운 작업입니다. 회귀 테스트 용 자동화 도구를 선택하는 동안 도구를 사용하여 테스트 케이스를 쉽게 추가하거나 업데이트 할 수 있는지 확인해야합니다.

대부분의 경우 시스템의 빈번한 변경으로 인해 자동화 된 회귀 테스트 케이스를 자주 업데이트해야합니다.

비디오보기

예제와 함께 정의에 대한 자세한 설명은 다음을 확인하십시오.회귀 테스트 동영상:

왜 회귀 테스트인가?

회귀는 프로그래머가 버그를 수정하거나 시스템에 새로운 기능을위한 새 코드를 추가 할 때 시작됩니다.

회귀 테스트

새로 추가 된 기능과 기존 기능에 많은 종속성이있을 수 있습니다.

수정되지 않은 코드가 영향을받지 않도록 새 코드가 이전 코드를 준수하는지 확인하는 것은 품질 측정입니다. 대부분의 경우 테스트 팀은 시스템의 마지막 순간 변경 사항을 확인해야합니다.

이러한 상황에서 모든 주요 시스템 측면을 포함하여 테스트 프로세스를 적시에 완료하려면 영향을받는 애플리케이션 영역 만 테스트해야합니다.

이 테스트는 애플리케이션에 지속적인 변경 / 개선이 추가 될 때 매우 중요합니다. 새로운 기능은 기존 테스트 코드에 부정적인 영향을주지 않아야합니다.

코드 변경으로 인해 발생한 버그를 찾으려면 회귀 분석이 필요합니다. 이 테스트가 수행되지 않으면 제품이 실제 환경에서 심각한 문제를 겪을 수 있으며 실제로 고객을 문제로 이끌 수 있습니다.

온라인 웹 사이트를 테스트하는 동안 테스터는 제품 가격이 올바르게 표시되지 않는다는 문제를보고합니다. 즉, 제품의 실제 가격보다 가격이 낮아서 곧 수정해야합니다.

개발자가 문제를 수정하면 다시 테스트해야하며보고 된 페이지의 가격이 수정되었는지 확인하는 회귀 테스트도 필요하지만 총액이 함께 표시되는 요약 페이지에 잘못된 가격이 표시 될 수 있습니다. 다른 요금이나 고객에게 보낸 메일에는 여전히 잘못된 가격이 있습니다.

이제이 경우 사이트에서 잘못된 가격으로 총 비용을 계산하고 동일한 가격이 이메일로 고객에게 전달되므로이 테스트를 수행하지 않으면 고객이 손실을 감수해야합니다. 고객이 수락하면 제품이 더 낮은 가격에 온라인으로 판매되며 고객에게 손실이됩니다.

따라서이 테스트는 큰 역할을하며 매우 필요하고 중요합니다.

회귀 테스트 유형

다음은 다양한 유형의 회귀입니다.

  • 단위 회귀
  • 부분 회귀
  • 완전한 회귀

# 1) 단위 회귀

단위 회귀는 단위 테스트 단계 및 코드는 격리되어 테스트됩니다. 즉, 테스트 할 장치에 대한 모든 종속성이 차단되어 불일치없이 장치를 개별적으로 테스트 할 수 있습니다.

# 2) 부분 회귀

부분 회귀는 코드에서 변경이 수행되고 해당 단위가 변경되지 않았거나 이미 존재하는 코드와 통합 된 경우에도 코드가 제대로 작동하는지 확인하기 위해 수행됩니다.

# 3) 완전한 회귀

완전한 회귀는 여러 모듈에서 코드 변경이 수행되고 다른 모듈의 변경으로 인한 변경 영향이 불확실 할 때 수행됩니다. 변경된 코드로 인한 변경 사항을 확인하기 위해 제품 전체가 회귀됩니다.

얼마나 많은 회귀가 필요합니까?

이것은 새로 추가 된 기능의 범위에 따라 다릅니다.

수정 또는 기능의 범위가 너무 크면 영향을받는 응용 프로그램 영역도 상당히 크므로 모든 응용 프로그램 테스트 사례를 포함하여 철저하게 테스트를 수행해야합니다. 그러나 이것은 테스터가 개발자로부터 범위, 성격 및 변경 정도에 대한 정보를 얻을 때 효과적으로 결정할 수 있습니다.

반복적 인 테스트이므로 테스트 케이스를 자동화하여 테스트 케이스 세트 만 새 빌드에서 쉽게 실행할 수 있습니다.

회귀 테스트 케이스는 최소한의 테스트 케이스 세트에서 최대 기능을 다룰 수 있도록 매우 신중하게 선택해야합니다. 이러한 테스트 케이스 세트는 새로 추가 된 기능에 대한 지속적인 개선이 필요합니다.

애플리케이션 범위가 매우 크고 시스템에 지속적으로 증분 또는 패치가있을 때 매우 어려워집니다. 이러한 경우 테스트 비용과 시간을 절약하기 위해 선택적 테스트를 실행해야합니다. 이러한 선택적 테스트 사례는 시스템에 수행 된 개선 사항과 가장 영향을 미칠 수있는 부분을 기반으로 선택됩니다.

회귀 검사에서 우리는 무엇을합니까?

  • 이전에 수행 한 테스트를 다시 실행하십시오.
  • 현재 결과를 이전에 실행 한 테스트 결과와 비교

이는 소프트웨어 테스트 라이프 사이클 전반에 걸쳐 다양한 단계에서 수행되는 지속적인 프로세스입니다.

가장 좋은 방법은 회귀 테스트를 수행하는 것입니다. 위생 또는 연기 테스트 그리고 짧은 릴리스에 대한 기능 테스트가 끝날 때.

효과적인 테스트를 수행하기 위해 회귀 테스트 계획 생성되어야합니다. 이 계획은 회귀 테스트 전략과 종료 기준을 요약해야합니다. 성능 테스트는 또한 시스템 구성 요소의 변경으로 인해 시스템 성능이 영향을받지 않는지 확인하기위한이 테스트의 일부입니다.

모범 사례 : 매일 저녁에 자동화 된 테스트 케이스를 실행하여 다음날 빌드에서 회귀 부작용을 수정할 수 있습니다. 이렇게하면 릴리스주기가 끝날 때이를 찾아 수정하는 대신 초기 단계에서 거의 모든 회귀 결함을 처리하여 릴리스 위험을 줄입니다.

회귀 테스트 기법

다음은 다양한 기술입니다.

  • 모두 다시 테스트
  • 회귀 테스트 선택
  • 테스트 케이스 우선 순위
  • 잡종

회귀 테스트 기술

# 1) 모두 다시 테스트

이름 자체에서 알 수 있듯이 코드 변경으로 인해 발생한 버그가 없는지 확인하기 위해 테스트 스위트의 전체 테스트 케이스가 다시 실행됩니다. 다른 기술과 비교할 때 더 많은 시간과 리소스가 필요하기 때문에 비용이 많이 드는 방법입니다.

# 2) 회귀 테스트 선택

이 방법에서는 다시 실행할 테스트 스위트에서 테스트 케이스를 선택합니다. 전체 제품군이 다시 실행되는 것은 아닙니다. 테스트 케이스의 선택은 모듈의 코드 변경을 기반으로 수행됩니다.

테스트 케이스는 재사용 가능한 테스트 케이스이고 다른 하나는 사용되지 않는 테스트 케이스의 두 범주로 나뉩니다. 재사용 가능한 테스트 케이스는 향후 회귀주기에서 사용할 수있는 반면 오래된 테스트 케이스는 향후 회귀주기에서 사용되지 않습니다.

# 3) 테스트 케이스 우선 순위

우선 순위가 높은 테스트 케이스가 중간 및 낮은 우선 순위의 테스트 케이스보다 먼저 실행됩니다. 테스트 케이스의 우선 순위는 중요도와 제품에 대한 영향, 그리고 더 자주 사용되는 제품의 기능에 따라 다릅니다.

# 4) 하이브리드

하이브리드 기술은 회귀 테스트 선택과 테스트 케이스 우선 순위의 조합입니다. 전체 테스트 스위트를 선택하는 대신 우선 순위에 따라 재실행되는 테스트 케이스 만 선택하십시오.

회귀 테스트 스위트를 선택하는 방법?

프로덕션 환경에서 발견 된 대부분의 버그는 변경 사항 또는 11 시간에 수정 된 버그, 즉 이후 단계에서 수행 된 변경으로 인해 발생합니다. 마지막 단계의 버그 수정으로 인해 제품에 다른 문제 / 버그가 발생할 수 있습니다. 그렇기 때문에 제품을 출시하기 전에 회귀 검사가 매우 중요합니다.

다음은이 테스트를 수행하는 동안 사용할 수있는 테스트 케이스 목록입니다.

  • 자주 사용되는 기능.
  • 변경이 완료된 모듈을 다루는 테스트 케이스.
  • 복잡한 테스트 케이스.
  • 모든 주요 구성 요소를 포함하는 통합 테스트 케이스.
  • 제품의 핵심 기능 또는 기능에 대한 테스트 사례.
  • 우선 순위 1 및 우선 순위 2 테스트 케이스가 포함되어야합니다.
  • 자주 실패하는 테스트 케이스 또는 최근 테스트 결함이 동일하게 발견되었습니다.

회귀 테스트를 수행하는 방법?

회귀가 의미하는 바를 확인 했으므로 이제 테스트 중임이 분명합니다. 특정 이유 때문에 특정 상황에서 단순히 반복합니다. 따라서 우리는 처음에 동일한 방법이 테스트에 적용된다는 것을 안전하게 유도 할 수 있습니다.

따라서 테스트를 수동으로 수행 할 수 있다면 회귀 테스트도 수행 할 수 있습니다. 도구를 사용할 필요가 없습니다. 그러나 시간이 지남에 따라 응용 프로그램은 점점 더 많은 기능으로 쌓여 회귀 범위를 계속 증가시킵니다. 시간을 최대한 활용하기 위해이 테스트는 가장 자주 자동화 됨 .

이 테스트를 수행하는 데 관련된 다양한 단계는 다음과 같습니다.

  • 다음에 언급 된 점을 고려하여 회귀 테스트 스위트를 준비하십시오. '회귀 테스트 스위트를 선택하는 방법'?
  • 테스트 스위트의 모든 테스트 케이스를 자동화하십시오.
  • 테스트 케이스에서 다루지 않은 새로운 결함이 발견되는 경우와 같이 필요할 때마다 회귀 스위트를 업데이트하고, 다음 번에 같은 테스트가 누락되지 않도록 동일한 테스트 케이스를 테스트 스위트에서 업데이트해야합니다. . 회귀 테스트 스위트는 테스트 케이스를 지속적으로 업데이트하여 적절하게 관리해야합니다.
  • 코드 변경, 버그 수정, 새로운 기능 추가, 기존 기능 개선 등이있을 때마다 회귀 테스트 케이스를 실행합니다.
  • 실행 된 테스트 케이스의 통과 / 실패 상태를 포함하는 테스트 실행 보고서를 생성합니다.

예를 들어:

예를 들어 설명하겠습니다. 아래 상황을 검토하십시오.

릴리스 1 통계
테스터 수삼
응용 프로그램 이름XYZ
버전 / 릴리스 번호1
요구 사항 수 (범위)10
테스트 케이스 / 테스트 수100
개발에 걸리는 일수5
테스트에 걸리는 일수5
릴리스 2 통계
테스터 수삼
응용 프로그램 이름XYZ
버전 / 릴리스 번호두
요구 사항 수 (범위)10+ 5 개의 새로운 요구 사항
테스트 케이스 / 테스트 수100+ 50 새로운
개발에 걸리는 일수2.5 (이전보다 작업량이 절반이기 때문에)
테스트에 걸리는 일수5 (기존 100 명의 TC) + 2.5 (새 요구 사항의 경우)
릴리스 3 통계
테스터 수삼
응용 프로그램 이름XYZ
버전 / 릴리스 번호삼
요구 사항 수 (범위)10+ 5 + 5 새로운 요구 사항
테스트 케이스 / 테스트 수100+ 50+ 50 새로운
개발에 걸리는 일수2.5 (이전보다 작업량이 절반이기 때문에)
테스트에 걸리는 일수7.5 (기존 150 TC의 경우) + 2.5 (새 요구 사항의 경우)

위의 상황에서 관찰 할 수있는 내용은 다음과 같습니다.

  • 릴리스가 증가함에 따라 기능도 증가합니다.
  • 개발 시간은 릴리스와 함께 반드시 증가하지는 않지만 테스트 시간은 증가합니다.
  • 어떤 회사 / 경영진도 테스트에 더 많은 시간을 투자하고 개발에 더 적게 투자 할 준비가되어 있지 않습니다.
  • 더 많은 사람들은 더 많은 돈을 의미하고 새로운 사람들은 많은 훈련을 의미하고 새로운 사람들이 필요한 지식과 동등하지 않을 수 있기 때문에 품질이 타협되기 때문에 테스트 팀 규모를 늘려서 테스트하는 데 걸리는 시간을 줄일 수도 없습니다. 즉시 수준.
  • 또 다른 대안은 회귀의 양을 줄이는 것입니다. 그러나 소프트웨어 제품에는 위험 할 수 있습니다.

이러한 모든 이유로 회귀 테스트는 자동화 테스트를위한 좋은 후보이지만 그 방법으로 만 수행 할 필요는 없습니다.

회귀 테스트를 수행하는 기본 단계

소프트웨어가 변경되고 새 버전 / 릴리스가 나올 때마다 이러한 유형의 테스트를 수행하기 위해 취할 수있는 단계는 다음과 같습니다.

회귀 테스트 프로세스

  • 소프트웨어에 적용된 변경 사항 이해
  • 소프트웨어의 어떤 모듈 / 부분이 영향을받을 수 있는지 분석하고 결정합니다. 개발 및 BA 팀은이 정보를 제공하는 데 도움이 될 수 있습니다
  • 테스트 케이스를 살펴보고 전체, 부분 또는 단위 회귀를 수행해야하는지 결정하십시오. 귀하의 상황에 맞는 것을 식별하십시오
  • 시간을 정하고 시험을 치르십시오!

애자일의 회귀

기민한 반복적이고 점진적인 방법을 따르는 적응 형 접근 방식입니다. 이 제품은 2 ~ 4 주 동안 지속되는 스프린트라는 짧은 반복으로 개발됩니다. 애자일에는 여러 번의 반복이 있으므로이 테스트는 반복에서 새로운 기능이나 코드 변경이 수행됨에 따라 중요한 역할을합니다.

회귀 테스트 스위트는 초기 단계부터 준비해야하며 각 스프린트로 업데이트해야합니다.

Agile에서 회귀 검사는 두 가지 범주로 나뉩니다.

  • 스프린트 레벨 회귀
  • 종단 간 회귀

# 1) 스프린트 레벨 회귀

스프린트 레벨 회귀는 주로 최신 스프린트에서 수행되는 새로운 기능 또는 개선 사항에 대해 수행됩니다. 테스트 스위트의 테스트 케이스는 새로 추가 된 기능 또는 수행 된 개선 사항에 따라 선택됩니다.

# 2) 종단 간 회귀

End-to-End Regression에는 제품의 모든 핵심 기능을 포함하여 전체 제품을 테스트하기 위해 다시 실행해야하는 모든 테스트 사례가 포함됩니다.

Agile은 스프린트가 짧고 계속 진행되기 때문에 테스트 스위트를 자동화하는 것이 매우 필요하고 테스트 케이스가 다시 실행되며 짧은 시간 내에 완료되어야합니다. 테스트 케이스를 자동화하면 실행 시간과 결함 미끄러짐이 줄어 듭니다.

해답이있는 숙련 된 전문가를위한 인터뷰 질문 테스트

장점

회귀 테스트의 다양한 장점은 다음과 같습니다.

  • 제품의 품질을 향상시킵니다.
  • 수행 된 버그 수정 또는 개선이 제품의 기존 기능에 영향을 미치지 않도록합니다.
  • 이 테스트에는 자동화 도구를 사용할 수 있습니다.
  • 이미 수정 된 문제가 다시 발생하지 않도록합니다.

단점

몇 가지 장점이 있지만 몇 가지 단점도 있습니다. 그들은:

  • 코드를 조금만 변경해도 기존 기능에 문제가 발생할 수 있으므로 코드를 약간만 변경해야합니다.
  • 이 테스트를 위해 프로젝트에서 자동화가 사용되지 않는 경우 테스트 케이스를 반복해서 실행하는 것은 시간이 많이 걸리고 지루한 작업입니다.

GUI 애플리케이션의 회귀

GUI (Graphical User Interface) 회귀 테스트를 수행하기 어려운 경우 GUI 구조 수정됩니다. 이전 GUI에 작성된 테스트 케이스는 더 이상 사용되지 않거나 수정해야합니다.

회귀 테스트 케이스를 재사용한다는 것은 GUI 테스트 케이스가 새 GUI에 따라 수정된다는 것을 의미합니다. 그러나이 작업은 GUI 테스트 케이스가 많은 경우 번거로운 작업이됩니다.

회귀와 재 테스트의 차이점

실행 중에 실패한 테스트 케이스에 대해 재 테스트가 수행되고 동일한 버그가 수정되었지만 회귀 검사는 다른 테스트 케이스도 포함하므로 버그 수정에 국한되지 않습니다. 제품의 다른 기능에 영향을 미쳤습니다.

회귀 테스트 계획 템플릿 (TOC)

1. 문서 기록

2. 참고 문헌

3. 회귀 테스트 계획

3.1. 소개

3.2. 목적

3.3. 테스트 전략

3.4. 테스트 할 기능

3.5. 자원 요구 사항

3.5.1. 하드웨어 요구 사항

3.5.2. 소프트웨어 요구 사항

3.6. 시험 일정

3.7. 변경 요청

3.8. 입출국 기준

3.8.1. 이 테스트에 대한 입력 기준

3.8.2. 이 테스트에 대한 종료 기준

3.9. 가정 / 제약

3.10. 테스트 케이스

3.11. 위험 / 가정

3.12. 도구

4. 승인 / 수락

각각에 대해 자세히 살펴 보겠습니다.

# 1) 문서 기록

문서 기록은 첫 번째 초안의 기록과 아래에 제공된 형식의 모든 업데이트 된 기록으로 구성됩니다.

버전데이트저자논평
1DD / MM / YY알파벳승인 됨
두DD / MM / YY알파벳추가 된 기능 업데이트

# 2) 참고 문헌

참조 열은 테스트 계획을 만드는 동안 프로젝트에 사용되거나 필요한 모든 참조 문서를 추적합니다.

하지 마라문서위치
1SRS 문서공유 드라이브

# 3) 회귀 테스트 계획

3.1. 소개

이 문서는 테스트 할 제품의 변경 / 업데이트 / 향상과이 테스트에 사용되는 접근 방식을 설명합니다. 모든 코드 변경, 개선 사항, 업데이트, 추가 된 기능은 테스트를 위해 요약되어 있습니다. 단위 테스트 및 통합 테스트에 사용되는 테스트 케이스를 사용하여 회귀 테스트 모음을 만들 수 있습니다.

3.2. 목적

회귀 테스트 계획의 목적은 결과를 달성하기 위해 테스트가 정확히 무엇과 어떻게 수행되는지 설명하는 것입니다. 회귀 검사는 코드 변경으로 인해 제품의 다른 기능이 방해받지 않도록하기 위해 수행됩니다.

3.3. 테스트 전략

테스트 전략은이 테스트를 수행하는 데 사용될 접근 방식을 설명하며 사용할 기술, 완료 기준은 무엇이며, 누가 어떤 활동을 수행할지, 누가 테스트 스크립트를 작성하고, 어떤 회귀 도구를 사용할 것인지를 설명합니다. , 자원 경색, 생산 지연 등과 같은 위험을 커버하는 단계

3.4. 테스트 할 기능

테스트 할 제품의 기능 / 구성 요소가 여기에 나열됩니다. 회귀에서는 모든 테스트 케이스가 다시 실행되거나 수행 된 수정 / 업데이트 또는 개선 사항에 따라 기존 기능에 영향을 미치는 테스트 케이스가 선택됩니다.

3.5. 자원 요구 사항

3.5.1. 하드웨어 요구 사항 :

하드웨어 요구 사항은 여기에서 컴퓨터, 랩톱, 모뎀, Mac 북, 스마트 폰 등과 같이 식별됩니다.

3.5.2. 소프트웨어 요구 사항 :

소프트웨어 요구 사항은 어떤 운영 체제와 브라우저가 필요한지와 같이 식별됩니다.

3.6. 시험 일정

테스트 일정은 테스트 활동을 수행하기위한 예상 시간을 정의합니다.

예를 들어 얼마나 많은 리소스가 테스트 활동을 수행 할 것이며 얼마나 많은 시간에 그렇게 될까요?

3.7. 변경 요청

회귀가 수행 될 CR 세부 사항이 언급됩니다.

S. 아니CR 설명회귀 테스트 스위트
1
두

3.8. 입출국 기준

3.8.1. 이 테스트에 대한 입력 기준 :

회귀 검사를 시작할 제품의 입력 기준이 정의됩니다.

예를 들면 :

  • 코딩 변경 / 향상 / 새 기능 추가가 완료되어야합니다.
  • 회귀 테스트 계획이 승인되어야합니다.

3.8.2. 이 테스트의 종료 기준 :

여기서 회귀에 대한 종료 기준이 정의됩니다.

예를 들면 :

  • 회귀 테스트를 완료해야합니다.
  • 이 테스트 중에 발견 된 새로운 중요한 버그는 모두 닫아야합니다.
  • 테스트 보고서가 준비되어야합니다.

3.9. 테스트 케이스

회귀 테스트 사례가 여기에 정의됩니다.

3.10. 위험 / 가정

모든 위험 및 가정이 식별되고 이에 대한 비상 계획이 준비됩니다.

3.11. 도구

프로젝트에서 사용할 도구가 식별됩니다. 예 :

  • 자동화 도구
  • 버그보고 도구

# 4) 승인 / 수락

사람들의 이름과 지정이 여기에 나열됩니다.

이름승인 / 거부 됨서명데이트

결론

회귀 테스트는 코드의 크기에 관계없이 코드의 변경 사항이 기존 기능이나 이전 기능에 영향을주지 않도록하여 양질의 제품을 제공하는 데 도움이되는 중요한 측면 중 하나입니다.

회귀 테스트 사례를 자동화하기 위해 많은 자동화 도구를 사용할 수 있지만 프로젝트 요구 사항에 따라 도구를 선택해야합니다. 회귀 테스트 스위트를 자주 업데이트해야하므로 도구에 테스트 스위트를 업데이트 할 수있는 기능이 있어야합니다.

이것으로 우리는이 주제를 마무리하고 앞으로 주제에 대해 훨씬 더 명확 해지기를 바랍니다.

회귀 관련 질문과 의견을 알려주십시오. 회귀 테스트 작업을 어떻게 처리 했습니까?

=> 전체 테스트 계획 자습서 시리즈를 보려면 여기를 방문하십시오.

추천 도서

^