메뉴

예를 사용한 재 테스트와 회귀 테스트의 차이점

difference between retesting

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

재 테스트와 회귀 테스트의 차이점은 무엇입니까?

모두 비교 및 ​​대조 테마 기사를 좋아하지 않습니까? 알아요. 생각, 의견, 심지어는 강한 의견 차이를 불러 일으킬 수있는 좋은 방법입니다.

오늘의 주제는 Retesting Vs Regression Testing입니다.

=> 완전한 회귀 테스트 시리즈를 보려면 여기를 클릭하십시오.

재 테스트부터 시작하겠습니다.

학습 내용 :

재시험

다시 테스트는 다시 테스트하는 것을 의미합니다. 이유는 중요하지 않습니다. 테스트를 반복하면 다시 테스트합니다. 현재 버전 기능을 다시 테스트 할 수 있습니다. 또는 버그 수정, 이전 버전 기능, 방금 실행 한 테스트 케이스 등.

재 테스트 및 회귀 테스트

여전히 생각하고 있다면-이유-다음은 그 어떤 것도 좋은 이유입니다.

  • 어제 테스트를 실행했는데 결함이 발생했습니다. 단계와 결함의 재현성을 확인하려고합니다. 그래서 다시 테스트합니다.
  • 테스트를 실행했습니다. 관심이 없었습니다 (전화가 울렸거나 동료와 통화 중일 수 있음). 한 번 더 확인하고 싶으므로 다시 테스트하십시오.

나는 당신이 그것을 확신합니다.

재검사는 어떤 이유로 든 검사를 반복하는 것입니다. 그 정의에 충실한 용어 중 하나입니다.

회귀 테스트

소프트웨어가 진화합니다. 기존 버전보다 새로운 버전이있을 것입니다. 새로운 기능, 확장 기능 등이 쌓여 있습니다. 그러나 시간이 지남에 따라 응용 프로그램이 불안정해질 수 있습니다.

한 블록을 다른 블록 위에 추가하여 블록 타워를 만든다고 상상해보십시오. 기지를 강화하거나 강화하는 데 시간이 걸리지 않습니다. 타워가 무너지기까지 그리 오래 걸리지 않겠죠?

mp4로 무료 유튜브 비디오 변환기

이와 마찬가지로 소프트웨어 기반의 강도와 안정성을 테스트해야합니다.

그렇게하려면 소프트웨어를 다시 테스트해야합니다. 그것이 유일한 방법입니다.

추천 읽기 => 회귀 테스트 란 무엇입니까? 도구 및 모범 사례

회귀는 Retest의 한 형태입니다. '왜'와 '언제'의 세부 사항은 전자와 구별됩니다.

1) 언제 다시 테스트하고 있습니까? 소프트웨어가 변경 될 때

두) 왜 다시 테스트하고 있습니까? 새로운 추가 / 변경으로 인해 작동 전 기능이 불안정하지 않도록합니다. 회귀는 일반적이며 다음과 같은 경우에 권장됩니다.

  • 새 버전을 사용할 수 있습니다. (전체 또는 적어도 이전 버전 기능의 중요한 기능을 회귀)
  • 버그 수정

참고 사항 : 철저한 회귀 테스트는 바람직하지만 불가능합니다.

그래서 회귀 분석 테스트를 시작하기 전에 이 단계에는 내 응용 프로그램에 대해 수행해야하는 회귀의 양을 결정하는 작업이 포함됩니다.

회귀의 정도는 무엇에 달려 있습니까?

  • 변화의 성격
  • 현재 시스템 / 기능에 대한 변경의 관계 / 영향
  • 사용 가능한 시간 및 자원

테스터는 회귀 정도를 어떻게 결정할 수 있습니까?

1) 응용 프로그램에 대한 경험과 친숙 함을 통해

두) 개발자와 논의

삼) 변경된 장소입니다.예를 들면 :홈 페이지에있는 경우 액세스가 적은 페이지 중 하나에있는 것보다 더 많은주의가 필요합니다.

플레이 요소에 따라 테스트 팀은 다음 중 하나를 선택할 수 있습니다.

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

단위 회귀 응용 프로그램의 변경된 모듈 / 영역 만 다시 테스트한다는 의미입니다.

부분 회귀 평균 변경된 모듈을 다시 테스트합니다. 또한 그것과 상호 작용하는 사람들을 포함하십시오.

완전 회귀 변경 위치에 관계없이 전체 애플리케이션을 테스트하는 것입니다.

상황 (시간 및 리소스 가용성), 변경의 심각성 (영향), 개발자의 입력 등에 따라 달라집니다. 모든 테스트보다 올바른 테스트 세트를 선택하면 더 효율적입니다.

C ++에서 char를 int로 변환

회귀 분석은 핵심 성공 요인입니다. 노력보다는 현명한 작업이 필요합니다.

회귀 테스트에 대한 오해

회귀 테스트에 대한 많은 오해가 있습니다.

# 1) 회귀는 항상 자동화를 통해 수행됩니다. 아니요. 회귀도 수동으로 수행됩니다. 우리는 이것에 대한 전체 기사가 있습니다 => 회귀 테스트는 어떻게 수행됩니까? 수동으로 할 수 있습니까?

회귀는 자동화를위한 완벽한 후보입니다. 반복의 정도는 시간이 많이 걸리고 지루함을 유발할 수 있습니다. 또한 중요한 유효성 검사를 놓칠 수 있습니다. 자동화는 안정적이고 빠르고 효율적인 대안입니다.

또한 읽기 => 자동화 된 회귀 테스트 과제

# 2) 회귀는 완전하지 않습니다 : 진실. 그러나 완전히는 아닙니다.

내 말은 철저한 회귀 테스트가 불가능할 수도 있다는 것입니다. 그러나 철저한 회귀 테스트도 불필요 할 수 있습니다.

홈페이지에서 맞춤법 오류를 변경했다고 가정 해 보겠습니다. 이 수정은 사소한 것입니다. 또한 응용 프로그램의 다른 영역과도 분리되어 있습니다. 따라서 기능을 간단히 다시 테스트하면됩니다. 홈페이지 주변의 이전 기능을 회귀 할 필요가 없습니다.

# 3) 불필요 시간이 부족할 때 : 사실이 아니다. 회귀가 충분하지 않으면 제품에 대한 확신이 부족합니다. 다른 최종 사용자 시나리오에 대한 반응에서 무엇을 기대할 수 있는지 결코 알 수 없습니다.

# 4) 이전 릴리스의 모든 단일 테스트 케이스를 실행합니다. 다시 한 번 모든 테스트 케이스를 선택하는 것은이를 수행하는 올바른 방법이 아닙니다. 테스트 케이스의 전략적 선택이 핵심입니다. 변경 사항을 이해하고 적합한 테스트 사례를 선택하십시오.

좋습니다, 그것은 세부적으로 Retesting and Regression Test입니다.

자, 비교.

회귀 테스트 대 재 테스트

그들에 대해 똑같은 것은 무엇입니까?

  • 둘 다 반복 기반입니다.
  • 검증 및 블랙 박스 테스트 기술
  • 자동화 또는 수동 테스트 케이스 모두 재 테스트 또는 회귀
  • '사람은 그의 의심을 확인하거나 추방하고이를 Yes 또는 No- Thomas Carlyle의 확실성으로 전환해야합니다.' 둘 다 이렇게합니다.

그들에 대한 차이점은 무엇입니까?

  • 재 테스트는 현재 또는 이전 버전 기능을 대상으로하는 모든 테스트에 적용됩니다. 회귀는 이전 버전의 기능 중심입니다.
  • 재 테스트는 적용 가능한 변경 사항에 의존하지 않습니다. 회귀는 변화 지향적입니다.

마지막으로,이 개념을 집으로 돌리려면 :

ID가 120 인 결함이 발생한 테스트 케이스 XYZ가 있다고 가정 해 보겠습니다.이 결함은 다음 릴리스에서 수정됩니다. XYZ 테스트 케이스를 다시 테스트하고 그 주변의 기능을 회귀합니다. 회귀는 120 초 후에 모든 것이 그대로 작동하는지 확인하는 것입니다. 재 테스트는 결함이 수정되었는지 확인하는 것입니다.

그래서 그것은 하나도 다른 것도 아니지만 동적 듀오를 형성하는 회귀와 재 테스트의 조합 .

이제 끝났습니다. 여기에 제공된 정의 및 분석에 동의하십니까?

저자 정보 : 이 기사는 STH 팀원 Swati S가 작성했습니다.

youtube to mp4 변환기 for android

이에 대한 귀하의 생각, 의견 및 질문은 무엇입니까? 공유 해주세요. 우리는 여러분 모두와 연결하고 싶습니다.

=> 완전한 회귀 테스트 시리즈를 보려면 여기를 방문하십시오.

추천 도서

^