회귀 테스트는 블랙박스 테스트 기술입니다. 이는 소프트웨어의 코드 변경을 인증하는 데 사용되며 제품의 기존 기능에는 영향을 주지 않습니다. 회귀 테스트는 새로운 기능, 버그 수정 또는 기존 기능의 변경 사항이 적용되어 제품이 제대로 작동하는지 확인하는 것입니다.

회귀 테스트는 일종의 소프트웨어 테스팅 . 테스트 사례를 다시 실행하여 애플리케이션의 이전 기능이 제대로 작동하는지 확인하고 새로운 변경 사항으로 인해 버그가 발생하지 않았는지 확인합니다.

원래 기능에 중요한 변경 사항이 있는 경우 새 빌드에서 회귀 테스트를 수행할 수 있습니다. 변경이 발생하더라도 코드가 계속 작동하도록 보장합니다. 회귀는 변경되지 않은 애플리케이션 부분을 다시 테스트하는 것을 의미합니다.

회귀 테스트는 검증 방법이라고도 합니다. 테스트 케이스는 자동화되는 경우가 많습니다. 테스트 케이스는 여러 번 실행해야 하며 동일한 테스트 케이스를 수동으로 계속해서 실행하는 것은 시간이 많이 걸리고 지루합니다.

회귀 테스트의 예

여기서는 회귀 테스트를 효율적으로 정의하는 사례를 살펴보겠습니다.

기능 중 하나가 확인, 수락 및 이메일 발송을 트리거하는 제품 Y를 생각해 보세요. 또한 코드 변경이 영향을 미치지 않는지 확인하기 위해 테스트해야 합니다. 회귀 테스트는 다음과 같은 프로그래밍 언어에 의존하지 않습니다. 자바 , C++ , 씨# 등. 이 방법은 제품의 수정이나 업데이트를 테스트하는 데 사용됩니다. 이는 제품의 변경 사항이 제품의 기존 모듈에 영향을 미치지 않도록 보장합니다. 수정된 버그와 새로 추가된 기능으로 인해 이전 작업 버전의 소프트웨어에서 문제가 발생하지 않았는지 확인하십시오.

회귀 테스트는 언제 수행할 수 있나요?

우리는 프로덕션 코드가 수정될 때마다 회귀 테스트를 수행합니다.

다음 시나리오에서 회귀 테스트를 수행할 수 있습니다.

1. 애플리케이션에 새로운 기능이 추가된 경우.

예:

웹사이트에는 사용자가 이메일로만 로그인할 수 있는 로그인 기능이 있습니다. 이제 Facebook을 사용하여 로그인할 수 있는 새로운 기능을 제공합니다.

2. 변경요구사항이 있는 경우

예:

이전에 적용되었던 로그인 페이지에서 제거된 비밀번호를 기억하십시오.

3. 하자가 수정된 경우

예:

로그인 버튼이 로그인 페이지에서 작동하지 않고 테스터가 로그인 버튼이 손상되었다는 버그를 보고했다고 가정합니다. 개발자가 버그를 수정하면 테스터는 이를 테스트하여 로그인 버튼이 예상 결과에 따라 작동하는지 확인합니다. 동시에 테스터는 로그인 버튼과 관련된 다른 기능을 테스트합니다.

4. 성능상의 문제가 있는 경우 수정

배열과 배열리스트의 차이점

예:

홈페이지 로딩 시간은 5초로, 로딩 시간이 2초로 단축됩니다.

5. 환경의 변화가 있는 경우

예:

MySql에서 Oracle로 데이터베이스를 업데이트할 때.

회귀 테스트를 수행하는 방법은 무엇입니까?

회귀 테스트의 필요성은 소프트웨어 유지 관리에 개선, 오류 수정, 최적화 및 기존 기능 삭제가 포함될 때 발생합니다. 이러한 수정 사항은 시스템 기능에 영향을 미칠 수 있습니다. 이 경우 회귀 테스트가 필요합니다.

회귀 테스트는 다음 기술을 사용하여 수행할 수 있습니다.

1. 모두 다시 테스트하십시오.

재테스트(Re-Test)는 회귀 테스트를 수행하는 방법 중 하나입니다. 이 접근 방식에서는 모든 테스트 케이스를 다시 실행해야 합니다. 여기서는 테스트가 실패할 때 재테스트를 정의할 수 있으며 실패의 원인은 소프트웨어 오류라고 판단할 수 있습니다. 결함이 보고되면 결함이 수정된 새 버전의 소프트웨어가 나올 것으로 예상됩니다. 이 경우에는 테스트를 다시 실행하여 오류가 수정되었는지 확인해야 합니다. 이를 재테스트라고 합니다. 어떤 사람들은 이것을 확인 테스트라고 부릅니다.

재시험에는 막대한 시간과 자원이 필요하기 때문에 비용이 매우 많이 듭니다.

2. 회귀 테스트 선택:

• 이 기술에서는 전체 테스트 케이스 슈트가 아닌 선택된 테스트 케이스 슈트가 실행됩니다.
• 선택된 테스트 케이스 슈트는 두 가지 케이스로 나누어진다
  1. 재사용 가능한 테스트 케이스.
  2. 더 이상 사용되지 않는 테스트 케이스.
• 재사용 가능한 테스트 케이스는 후속 회귀 주기에 사용할 수 있습니다.
• 더 이상 사용되지 않는 테스트 사례는 후속 회귀 주기에서 사용할 수 없습니다.

3. 테스트 케이스의 우선순위 지정:

비즈니스 영향, 중요하고 자주 사용되는 기능에 따라 테스트 사례의 우선순위를 지정합니다. 테스트 케이스를 선택하면 회귀 테스트 스위트가 줄어듭니다.

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

회귀 테스트는 QA 프로세스의 중요한 부분입니다. 회귀를 수행하는 동안 다음과 같은 문제에 직면할 수 있습니다.

시간이 많이 소요됨
회귀 테스트를 완료하는 데 많은 시간이 소요됩니다. 회귀 테스트에는 기존 테스트가 다시 포함되므로 테스터는 테스트를 다시 실행하는 것을 좋아하지 않습니다.복잡한
회귀 테스트는 제품을 업데이트해야 하는 경우에도 복잡합니다. 시험 목록도 늘어나고 있습니다.비즈니스 규칙 전달
회귀 테스트는 기존 제품 기능이 여전히 작동하는지 확인합니다. 기술 담당자가 아닌 사람과 회귀 테스트에 관해 의사소통하는 것은 어려운 작업일 수 있습니다. 경영진은 제품이 발전하는 모습을 확인하고 기존 기능이 제대로 작동하는지 확인하기 위해 회귀 테스트에 상당한 시간을 투자하기를 원합니다.영향 영역 식별 테스트 케이스는 릴리스별로 릴리스를 증가시킵니다. 더 적은 자원 정확도 없음 반복적인 작업 단조로운 직업

회귀 테스트 프로세스

회귀 테스트 프로세스는 전체에서 수행될 수 있습니다. 빌드 그리고 릴리스 .

빌드 전반에 걸친 회귀 테스트

버그가 수정될 때마다 버그를 다시 테스트하고, 종속 모듈이 있으면 회귀 테스트를 진행합니다.

예를 들어 , 다음과 같이 다른 빌드가 있는 경우 회귀 테스트를 수행하는 방법 빌드 1, 빌드 2, 빌드 3 , 다양한 시나리오가 있습니다.

빌드1

• 먼저 클라이언트는 비즈니스 요구 사항을 제공합니다.
• 그런 다음 개발팀은 기능 개발을 시작합니다.
• 그 후, 테스트 팀은 테스트 케이스 작성을 시작합니다. 예를 들어 제품 릴리스#1에 대해 900개의 테스트 사례를 작성합니다.
• 그런 다음 테스트 사례 구현을 시작합니다.
• 제품이 출시되면 고객은 한 차례의 승인 테스트를 수행합니다.
• 그리고 결국 제품은 프로덕션 서버로 이동됩니다.

빌드2

• 이제 고객은 3~4개의 추가(새) 기능을 추가하도록 요청하고 새 기능에 대한 요구 사항도 제공합니다.
• 개발팀은 새로운 기능 개발을 시작합니다.
• 그 후, 테스트 팀은 새로운 기능에 대한 테스트 케이스 작성을 시작하고 약 150개의 새로운 테스트 케이스를 작성합니다. 따라서 작성된 테스트 케이스의 총 개수는 두 릴리스 모두 1050개입니다.
• 이제 테스트 팀은 150개의 새로운 테스트 사례를 사용하여 새로운 기능을 테스트하기 시작합니다.
• 작업이 완료되면 900개의 테스트 사례를 통해 기존 기능 테스트를 시작하여 새 기능 추가로 인해 기존 기능이 손상되었는지 여부를 확인합니다.
• 여기서는 이전 기능을 테스트하는 것을 다음과 같이 알려져 있습니다. 회귀 테스트 .
• 모든 기능(신규 및 기존)이 테스트되면 제품이 고객에게 전달되고 고객은 승인 테스트를 수행합니다.
• 승인 테스트가 완료되면 제품이 프로덕션 서버로 이동됩니다.

빌드3

• 두 번째 릴리스 이후 고객은 판매와 같은 기능 중 하나를 제거하려고 합니다.
• 그런 다음 판매 모듈에 속한 모든 테스트 케이스(약 120개 테스트 케이스)를 삭제합니다.
• 그리고 판매 모듈 테스트 케이스를 제거한 후 다른 기능이 모두 잘 작동하는지 확인하기 위해 다른 기능을 테스트하는데, 이 과정은 회귀 테스트로 진행됩니다.

메모:

• 변경으로 인해 안정적인 기능이 손상되었는지 확인하기 위해 안정적인 기능을 테스트합니다. 여기서 변경 사항은 다음을 의미합니다. 수정, 추가, 버그 수정 또는 삭제 .
• 다른 빌드 또는 릴리스에서 동일한 테스트 사례를 다시 실행하는 것은 변경 사항(수정, 추가, 버그 수정 또는 삭제)으로 인해 안정적인 기능에 버그가 발생하지 않도록 하기 위한 것입니다.

릴리스 전반에 걸친 회귀 테스트

새로운 기능이 이전 릴리스의 이전 요소에 영향을 미칠 수 있으므로 동일한 프로젝트에 대한 새 릴리스가 있을 때마다 회귀 테스트 프로세스가 시작됩니다.

회귀 테스트 프로세스를 이해하기 위해 다음 단계를 따르십시오.

1 단계

회귀 테스트가 없습니다. 릴리스#1 릴리스 자체가 새 릴리스이기 때문에 릴리스#1에서는 수정이 발생하지 않기 때문입니다.

2 단계

회귀 테스트의 개념은 다음에서 시작됩니다. 릴리스#2 고객이 뭔가를 줄 때 새로운 요구 사항 .

3단계

새로운 요구 사항(기능 수정)을 먼저 얻은 후 개발자와 테스트 엔지니어는 다음 단계로 넘어가기 전에 요구 사항을 이해하게 됩니다. 영향 분석 .

4단계

새로운 요구 사항을 이해한 후, 우리는 한 라운드의 작업을 수행합니다. 영향 분석 큰 위험을 피하기 위해, 그러나 여기서 누가 영향 분석을 수행할 것인지에 대한 질문이 생깁니다.

5단계

영향 분석은 다음에서 수행됩니다. 고객 그들의 기준으로 비즈니스 지식 , 개발자 그들의 기준으로 코딩 지식 그리고 가장 중요한 것은 이 작업이 다음에서 수행된다는 것입니다. 테스트 엔지니어 왜냐면 그들은 제품 지식 .

참고: 한 사람이 수행할 경우 모든 영향 영역을 다루지 못할 수 있으므로 최대 영향 영역을 다룰 수 있도록 모든 사람을 포함하고 릴리스 초기 단계에서 영향 분석을 수행해야 합니다.

6단계

일단 우리는 충격 지역 , 그러면 개발자가 영향 영역(문서) , 그리고 고객 또한 준비할 것이다 영향 영역 문서 우리가 목표를 달성할 수 있도록 영향 분석의 최대 범위 .

7단계

영향 분석이 완료된 후 개발자, 고객 및 테스트 엔지니어는 보고서# 영향 지역 문서의 테스트 리드 . 그 동안 테스트 엔지니어와 개발자는 새로운 테스트 사례를 작업하느라 바쁩니다.

8단계

테스트 리드가 보고서#를 받으면 다음을 수행합니다. 통합하다 보고서를 작성하고 테스트 케이스 요구 사항 저장소 릴리스 # 1의 경우.

참고: 테스트 케이스 저장소: 여기에는 릴리스의 모든 테스트 케이스가 저장됩니다.

9단계

그 후 테스트 리드는 RTM의 도움을 받아 필요한 것을 선택합니다. 회귀 테스트 케이스 ~로부터 테스트 케이스 저장소 , 해당 파일은 회귀 테스트 스위트 .

메모:

• 테스트 리드는 더 이상의 혼란을 피하기 위해 회귀 테스트 도구 모음에 회귀 테스트 사례를 저장합니다.
회귀 테스트 스위트: 여기에는 모든 충격 영역 테스트 문서가 저장됩니다.회귀 테스트 사례: 아래 이미지에서 볼 수 있듯이 다시 실행해야 하는 이전 릴리스 텍스트 문서의 테스트 사례입니다.

10단계

그 후, 테스트 엔지니어가 새로운 테스트 사례 작업을 완료하면 테스트 리드는 회귀 테스트 케이스 할당 테스트 엔지니어에게.

11단계

모든 회귀 테스트 사례와 새로운 기능이 완료되면 안정적이고 통과 , 그런 다음 테스트 케이스를 사용한 충격 영역 이전 기능과 새로운 기능을 모두 수용할 수 있을 때까지 고객에게 전달됩니다.

회귀 테스트 유형

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

1. 단위 회귀 테스트 [URT]
2. 지역 회귀 테스트[RRT]
3. 전체 또는 전체 회귀 테스트 [FRT]

1) 단위 회귀 테스트 [URT]

여기서는 동일한 모듈의 구성요소에 영향을 줄 수 있으므로 영향 영역이 아닌 변경된 유닛만 테스트하겠습니다.

실시예 1

아래 애플리케이션과 첫 번째 빌드에서 개발자는 찾다 수락하는 버튼 1~15자 . 그런 다음 테스트 엔지니어는 다음 기능을 사용하여 검색 버튼을 테스트합니다. 테스트 케이스 설계 기법 .

이제 클라이언트는 요구 사항을 일부 수정하고 다음을 요청합니다. 검색 버튼 받아들일 수 있다 1~35자 . 테스트 엔지니어는 검색 버튼만 테스트하여 검색 버튼이 1~35자인지 확인하고 첫 번째 빌드의 추가 기능은 확인하지 않습니다.

실시예2

여기, 우리는 빌드 B001 , 결함이 식별되고 보고서가 개발자에게 전달됩니다. 개발자는 버그를 수정하고 두 번째 버전에서 개발된 몇 가지 새로운 기능과 함께 보낼 것입니다. 빌드 B002 . 그 후 테스트 엔지니어는 결함이 수정된 후에만 테스트를 진행합니다.

• 테스트 엔지니어는 제출하다 버튼은 빈 페이지로 이동합니다.
• 그리고 그것은 결함이며, 그것을 고치기 위해 개발자에게 보내집니다.
• 새 빌드가 버그 수정과 함께 제공되면 테스트 엔지니어는 제출 버튼만 테스트합니다.
• 그리고 여기서는 첫 번째 빌드의 다른 기능을 확인하지 않고 새로운 기능을 테스트하고 두 번째 빌드로 보냅니다.
• 우리는 문제를 해결한다고 확신합니다. 제출하다 버튼은 다른 기능에 영향을 미치지 않으므로 수정된 버그만 테스트합니다.

따라서 변경된 기능만을 테스트함으로써 단위 회귀 테스트 .

2) 지역 회귀 테스트 [RRT]

여기서는 영향 영역 또는 지역과 함께 수정 사항을 테스트할 예정입니다. 지역 회귀 테스트 . 여기서는 신뢰할 수 있는 모듈이 있으면 다른 모듈에도 영향을 미치기 때문에 영향 영역을 테스트하고 있습니다.

예를 들어:

아래 이미지에서는 다음과 같은 네 가지 모듈이 있음을 알 수 있습니다. 모듈 A, 모듈 B, 모듈 C 및 모듈 D , 첫 번째 빌드 중 테스트를 위해 개발자가 제공하는 것입니다. 이제 테스트 엔지니어는 다음에서 버그를 식별합니다. 모듈 D . 버그 보고서는 개발자에게 전송되고, 개발팀은 해당 결함을 수정하고 두 번째 빌드를 보냅니다.

두 번째 빌드에서는 이전 결함이 수정되었습니다. 이제 테스트 엔지니어는 모듈 D의 버그 수정이 모듈의 일부 기능에 영향을 미쳤다는 것을 이해합니다. 모듈 A와 모듈 C . 따라서 테스트 엔지니어는 버그가 수정된 모듈 D를 먼저 테스트한 다음, 버그가 수정된 모듈 D에서 영향 영역을 확인합니다. 모듈 A와 모듈 C . 따라서 이 테스트는 다음과 같이 알려져 있습니다. 지역 회귀 테스트.

지역 회귀 테스트를 수행하는 동안 다음과 같은 문제에 직면할 수 있습니다.

문제:

첫 번째 빌드에서 클라이언트는 요구 사항에 대한 일부 수정 사항을 보내고 제품에 새로운 기능을 추가하려고 합니다. 요구사항은 개발팀과 테스트팀 모두에 전달됩니다.

요구 사항을 얻은 후 개발 팀은 수정 작업을 시작하고 필요에 따라 새로운 기능을 개발합니다.

이제 테스트 리드는 클라이언트에게 메일을 보내고 필요한 수정이 완료된 후 영향을 받을 모든 영역이 무엇인지 묻습니다. 따라서 고객은 모든 기능을 다시 테스트해야 한다는 아이디어를 얻게 됩니다. 또한 새로운 기능의 변경 및 추가로 인해 응용 프로그램의 모든 영역이 영향을 받게 될지 확인하기 위해 개발 팀에 메일을 보낼 것입니다.

마찬가지로 고객은 영향 영역 목록을 요청하기 위해 테스트 팀에 메일을 보냅니다. 따라서 테스트 리드는 클라이언트, 개발 팀 및 테스트 팀으로부터 영향 목록을 수집합니다.

jdbc

이것 영향 목록 목록을 보고 기능이 수정되었는지 확인하고 수정된 경우 수정하는 모든 테스트 엔지니어에게 전송됩니다. 지역 회귀 테스트 . 충격 영역과 수정 영역은 모두 해당 엔지니어가 테스트합니다. 모든 테스트 엔지니어는 수정으로 인해 영향을 받을 수 있는 기능만 테스트합니다.

위 접근 방식의 문제점은 개발 팀과 클라이언트가 메일을 되돌릴 시간이 많지 않기 때문에 테스트 리드가 영향 영역에 대한 전체 아이디어를 얻지 못할 수 있다는 것입니다.

해결책

위의 문제를 해결하기 위해 아래 프로세스를 따르겠습니다.

최신 기능과 버그 수정이 포함된 새 빌드가 출시되면 테스트 팀은 위 수정 사항으로 인해 해당 기능이 영향을 받는지 논의할 회의를 주선합니다. 그러므로 그들은 한 라운드를 할 것이다. 영향 분석 그리고 생성 영향 목록 . 이 특정 목록에서 테스트 엔지니어는 최대 예상 영향 영역을 포함하려고 시도하며 이로 인해 결함이 발생할 가능성도 줄어듭니다.

새 빌드가 출시되면 테스트 팀은 다음 절차를 따릅니다.

• 그들은 애플리케이션의 기본 기능을 확인하기 위해 스모크 테스트를 수행합니다.
• 그런 다음 새로운 기능을 테스트합니다.
• 그 후, 변경된 기능을 확인하게 됩니다.
• 변경된 기능 확인이 완료되면 테스트 엔지니어는 버그를 다시 테스트합니다.
• 그런 다음 지역 회귀 테스트를 수행하여 영향 영역을 확인합니다.

단위 및 지역 회귀 테스트 사용의 단점

다음은 단위 및 지역 회귀 테스트를 사용할 때의 몇 가지 단점입니다.

• 일부 임팩트 영역을 놓칠 수도 있습니다.
• 잘못된 영향 영역을 식별할 수도 있습니다.

참고: 지역 회귀 테스트에서 수행하는 주요 작업으로 인해 더 많은 결함이 발생하게 될 것이라고 말할 수 있습니다. 그러나 전체 회귀 테스트를 위해 동일한 헌신을 수행한다면 결함 수가 줄어들 것입니다. 따라서 테스트 노력을 강화해도 더 많은 결함을 얻는 데 도움이 되지 않는다는 것을 여기서 확인할 수 있습니다.

3) 전체 회귀 테스트 [FRT]

제품의 두 번째, 세 번째 릴리스에서 고객은 3~4개의 새로운 기능을 추가해 줄 것을 요청하고 이전 릴리스에서 일부 결함을 수정해야 합니다. 그런 다음 테스트 팀은 영향 분석을 수행하고 위의 수정으로 인해 전체 제품을 테스트하게 될지 확인합니다.

그러므로 우리는 다음을 테스트한다고 말할 수 있습니다. 수정된 기능 그리고 나머지 (이전) 기능 모두 이라고 불린다 전체 회귀 테스트 .

전체 회귀 테스트를 수행하는 경우는 언제입니까?

다음 조건이 충족될 때 FRT를 수행합니다.

• 제품의 소스 파일에 수정이 일어나는 경우. 예를 들어 , JVM은 JAVA 애플리케이션의 루트 파일이며 JVM에 변경 사항이 발생하면 전체 JAVA 프로그램이 테스트됩니다.
• n개의 변경을 수행해야 하는 경우.

메모:

지역 회귀 테스트는 회귀 테스트의 이상적인 접근 방식이지만 문제는 지역 회귀 테스트를 수행하는 동안 많은 결함을 놓칠 수 있다는 것입니다.

여기서는 다음 접근 방식을 사용하여 이 문제를 해결해 보겠습니다.

• 테스트 신청서가 제출되면 테스트 엔지니어는 첫 번째 10-14주기를 테스트하고 다음을 수행합니다. RRT .
• 그런 다음 15번째 주기에는 FRT를 수행합니다. 그리고 다시, 다음 10-15주기 동안 우리는 지역 회귀 테스트 그리고 31번째 사이클에서는 다음을 수행합니다. 전체 회귀 테스트 , 그리고 우리는 이렇게 계속할 것입니다.
• 하지만 출시의 마지막 10주기 동안 우리는 오직 완전한 회귀 테스트 .

따라서 위의 접근 방식을 따르면 더 많은 결함이 발생할 수 있습니다.

회귀 테스트를 수동으로 반복적으로 수행할 때의 단점은 다음과 같습니다.

• 생산성이 감소합니다.
• 그것은 하기 어려운 일이다.
• 테스트 실행에는 일관성이 없습니다.
• 그리고 테스트 실행 시간도 늘어납니다.

따라서 우리는 이러한 문제를 해결하기 위해 자동화를 진행할 것입니다. 회귀 테스트 주기가 n개일 때 우리는 자동화 회귀 테스트 프로세스 .

자동화된 회귀 테스트 프로세스

일반적으로 우리는 여러 릴리스나 여러 회귀 주기가 있거나 반복적인 작업이 있을 때마다 자동화를 선택합니다.

자동화 회귀 테스트 프로세스는 다음 단계로 수행할 수 있습니다.

참고 1:

일부 도구를 사용하여 애플리케이션을 테스트하는 프로세스를 자동화 테스트라고 합니다.

예를 하나 들어보자. 로그인 모듈 , 회귀 테스트를 수행하는 방법.

여기서 로그인은 다음과 같은 두 가지 방법으로 수행할 수 있습니다.

수동으로: 여기서는 회귀를 1번과 2번만 수행하겠습니다.

오토메이션: 여기서는 테스트 스크립트를 작성하고 실행해야 하므로 자동화를 여러 번 수행합니다.

참고 2: 실시간으로 다음과 같은 문제가 발생한 경우:

1 단계

새 릴리스가 시작되면 위 프로세스에서 이해한 것처럼 회귀 테스트 및 회귀 테스트 사례에 대한 개념이 없기 때문에 자동화를 진행하지 않습니다.

2 단계

새 릴리스와 개선이 시작되면 수동 팀과 자동화 팀이라는 두 팀이 있습니다.

3단계

수동 팀은 요구 사항을 검토하고 영향 영역을 식별한 후 해당 사항을 전달합니다. 요구사항 테스트 스위트 자동화 팀에.

4단계

이제 수동 팀은 새로운 기능 작업을 시작하고 자동화 팀은 테스트 스크립트 개발을 시작하고 테스트 케이스 자동화도 시작합니다. 이는 회귀 테스트 케이스가 테스트 스크립트로 변환된다는 의미입니다.

5단계

자동화 팀은 테스트 케이스 자동화를 시작하기 전에 어떤 케이스가 자동화될 수 있는지 여부도 분석합니다.

6단계

분석을 기반으로 자동화를 시작합니다. 즉, 모든 회귀 테스트 사례를 테스트 스크립트로 변환합니다.

7단계

이 과정에서 그들은 다음의 도움을 받을 것이다. 회귀 사례 제품에 대한 지식도 없고, 제품에 대한 지식도 없기 때문에 도구 그리고 애플리케이션 .

8단계

테스트 스크립트가 준비되면 새 애플리케이션[이전 기능]에서 이러한 스크립트의 실행을 시작합니다. 이후 테스트 스크립트는 회귀 기능이나 이전 기능을 사용하여 작성되었습니다.

9단계

실행이 완료되면 다음과 같은 다른 상태가 표시됩니다. 통과 실패 .

10단계

상태가 실패인 경우, 즉 수동으로 다시 확인해야 함을 의미하며, 버그가 존재하는 경우 관련 개발자에게 보고됩니다. 개발자가 해당 버그를 수정하면 매뉴얼 테스트 엔지니어가 해당 버그를 Impact 영역과 함께 다시 테스트해야 하고, 자동화 테스트 엔지니어가 스크립트를 다시 실행해야 합니다.

11단계

이 프로세스는 모든 새로운 기능이 완료될 때까지 계속되며 회귀 기능이 전달됩니다.

자동화 테스트를 통한 회귀 테스트의 이점:

정확성작업은 도구에 의해 수행되기 때문에 항상 존재하며 도구는 결코 지루하거나 피곤하지 않습니다.
• 테스트 스크립트는 여러 릴리스에서 재사용될 수 있습니다.
일괄 실행자동화를 사용하여 가능합니다. 작성된 모든 테스트 스크립트는 병렬 또는 동시에 실행될 수 있습니다.
• 회귀 테스트 케이스 수가 릴리스마다 증가하더라도 일부 회귀 케이스는 이전 릴리스에서 이미 자동화되어 있으므로 자동화 리소스를 늘릴 필요가 없습니다.
• 이것은 시간을 절약하는 프로세스 수동 방법보다 실행이 항상 빠르기 때문입니다.

회귀 테스트를 위한 테스트 사례를 선택하는 방법은 무엇입니까?

업계 조사를 통해 밝혀졌습니다. 고객이 보고한 여러 가지 결함은 마지막 버그 수정으로 인한 것입니다. 이러한 부작용을 생성하고 그에 따라 회귀 테스트를 위한 테스트 케이스를 선택하는 것은 쉬운 작업이 아니라 예술입니다.

회귀 테스트는 다음과 같이 수행할 수 있습니다.

• 결함이 자주 발생하는 테스트 케이스
• 사용자에게 더 잘 보이는 기능.
• 테스트 케이스는 제품의 핵심 기능을 검증합니다.
• 모든 통합 테스트 사례
• 모든 복잡한 테스트 케이스
• 경계값 테스트 사례
• 성공적인 테스트 사례 샘플
• 테스트 케이스의 실패

회귀 테스트 도구

소프트웨어가 자주 변경되면 회귀 테스트 비용도 증가합니다. 이러한 경우 테스트 사례를 수동으로 실행하면 테스트 실행 시간과 비용이 늘어납니다. 이 경우 자동화 테스트가 최선의 선택입니다. 자동화 기간은 연속적인 회귀 주기 동안 재사용 가능한 테스트 케이스의 수에 따라 달라집니다.

회귀 테스트에 사용되는 필수 도구는 다음과 같습니다.

셀렌

Selenium은 오픈 소스 도구입니다. 웹 애플리케이션의 자동화된 테스트에 사용되는 도구입니다. 브라우저 기반 회귀 테스트에는 셀레늄이 사용되었습니다. 웹 기반 애플리케이션의 UI 수준 회귀 테스트에 사용되는 Selenium입니다.

라노렉스 스튜디오

Selenium 웹 드라이버가 내장되어 데스크탑, 웹, 모바일 앱을 위한 올인원 회귀 테스트 자동화입니다. Ranorex Studio에는 코드 없는 자동화를 위한 전체 IDE와 도구가 포함되어 있습니다.

빠른 테스트 전문가(QTP)

자바 날짜를 문자열로

QTP는 회귀 및 기능 테스트에 사용되는 자동화된 테스트 도구입니다. 데이터 기반의 키워드 기반 도구입니다. 자동화를 위해 VBScript 언어를 사용했습니다. QTP 도구를 열면 세 개의 버튼이 표시됩니다. 녹음, 재생 및 중지 . 이 버튼은 컴퓨터 시스템에서 수행되는 모든 클릭과 작업을 기록하는 데 도움이 됩니다. 동작을 기록하고 재생합니다.

RTF(합리적 기능 테스터)

Rational Functional Tester는 소프트웨어 애플리케이션의 테스트 케이스를 자동화하는 데 사용되는 Java 도구입니다. 회귀 테스트 케이스 자동화에 사용되는 RTF이며 합리적인 기능 테스터와도 통합됩니다.

회귀 및 자동화 테스트 도구에 대한 자세한 내용은 아래 링크를 참조하세요.

https://www.javatpoint.com/automation-testing-tool

회귀 테스트 및 구성 관리

코드가 지속적으로 수정되는 Agile 환경에서는 회귀 테스트의 구성 관리가 필수적입니다. 유효한 회귀 테스트를 보장하려면 다음 단계를 따라야 합니다.

• 회귀 테스트 단계에서는 코드 변경이 허용되지 않습니다.
• 회귀 테스트 사례는 개발자 변경 사항에 영향을 받지 않아야 합니다.
• 회귀 테스트에 사용되는 데이터베이스는 격리되어야 합니다. 데이터베이스에서는 변경이 허용되지 않습니다.

재테스트와 회귀 테스트의 차이점

재테스트 테스트 코드가 수정되었는지 확인하기 위해 기능이나 버그를 다시 테스트하는 것을 의미합니다. 설정하지 않으면 결함을 다시 열 필요가 없습니다. 수정된 경우 결함이 종료됩니다.

재테스트(Re-testing)는 최종 실행에서 실패한 테스트 케이스가 결함이 수정된 후 성공적으로 통과되었는지 확인하기 위해 수행하는 테스트 유형입니다.

회귀 테스트 새로운 코드가 소프트웨어의 다른 부분에 영향을 미치지 않았는지 확인하기 위해 코드가 변경될 때 소프트웨어 응용 프로그램을 테스트하는 것을 의미합니다.

회귀 테스트는 코드가 애플리케이션의 기존 기능을 변경하지 않았는지 확인하기 위해 실행되는 테스트 유형입니다.

재테스트와 회귀 테스트의 차이점은 다음과 같습니다.

회귀 테스트의 장점

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

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

회귀 테스트의 단점

회귀 테스트에는 몇 가지 장점이 있지만 단점도 있습니다.

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

결론

회귀 테스트는 조직의 시간과 비용을 절약하는 고품질 제품을 제공하는 데 도움이 되는 필수적인 측면 중 하나입니다. 코드 변경이 기존 기능에 영향을 미치지 않도록 함으로써 고품질 제품을 제공하는 데 도움이 됩니다.

회귀 테스트 사례를 자동화하기 위해 사용할 수 있는 여러 자동화 도구가 있습니다. 도구에는 업데이트할 수 있는 기능이 있어야 합니다. 테스트 스위트 회귀 테스트 슈트는 자주 업데이트되어야 하기 때문입니다.