회귀 테스트

Regression testing
이 기사는 소프트웨어 개발에 관한 것입니다.통계 분석 프로세스는 회귀 분석을 참조하십시오.
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

회귀 테스트(비회귀 테스트[1])는 기능 테스트와 비기능 테스트를 다시 실행하여 이전에 개발 및 테스트한 소프트웨어가 변경 후에도 [2]계속 실행되도록 합니다.만약 그렇지 않다면, 그것은 퇴행이라고 불릴 것이다.

회귀 테스트가 필요한 변경에는 버그 수정, 소프트웨어 확장, 구성 변경 및 전자 컴포넌트 [3]교체 등이 포함됩니다.회귀 테스트 스위트는 결함이 발견될 때마다 증가하는 경향이 있으므로 테스트 자동화가 자주 수반됩니다.때로는 변경 영향 분석을 수행하여 적절한 테스트 하위 집합(비회귀[4] 분석)을 결정합니다.

배경

소프트웨어가 업데이트, 변경 또는 변경된 타깃에서 재사용되면 새로운 장애의 발생 및/또는 오래된 장애의 재발이 매우 일반적입니다.

잘못된 리비전 제어 관행(또는 리비전 제어의 단순한 인위적 오류)으로 인해 수정이 손실되어 다시 발생할 수 있습니다.대부분의 경우 문제의 수정은 문제가 처음 발견된 좁은 경우에는 문제를 수정하지만 소프트웨어의 수명 동안 발생할 수 있는 더 일반적인 경우에는 수정하지 않는다는 점에서 "취약"합니다.어떤 영역에서 발생한 문제의 수정으로 인해 실수로 다른 영역에서 소프트웨어 버그가 발생하는 경우가 많습니다.

마지막으로, 일부 기능을 재설계할 때, 기능의 최초 구현에서와 동일한 실수가 재설계에서 발생할 수 있습니다.따라서 대부분의 소프트웨어 개발 상황에서는 버그가 발견되어 수정되었을 때 버그를 노출하는 테스트를 기록하고 [5]이후 프로그램을 변경한 후 정기적으로 테스트를 다시 실행하는 것이 좋은 코딩 관행으로 간주됩니다.

프로그래밍 기술을 사용한 수동 테스트 절차를 통해 수행될 수 있지만, 대부분의 경우 자동화된 테스트 [6]도구를 사용하여 수행됩니다.이러한 테스트 스위트에는 테스트 환경에서 모든 회귀 테스트 케이스를 자동으로 실행할 수 있는 소프트웨어 도구가 포함되어 있습니다.일부 프로젝트에서는 모든 회귀 테스트를 지정된 간격으로 재실행하고 오류를 보고하도록 자동화 시스템을 설정하기도 합니다(회귀 테스트 또는 오래된 테스트를 [7]의미할 수 있습니다).

일반적인 전략은 컴파일이 성공할 때마다(작은 프로젝트의 경우), 매일 밤 또는 일주일에 한 번씩 이러한 시스템을 실행하는 것입니다.이러한 전략은 외부 도구를 통해 자동화할 수 있습니다.

회귀 테스트는 Extreme 프로그래밍 소프트웨어 개발 방법의 필수적인 부분입니다.이 방법에서는 설계 문서는 소프트웨어 개발 프로세스의 각 단계에서 전체 소프트웨어 패키지에 대한 광범위하고 반복 가능한 자동 테스트로 대체됩니다.회귀 테스트는 기능 테스트가 완료된 후 다른 기능이 작동하는지 확인하기 위해 수행됩니다.

기업 세계에서는 전통적으로 소프트웨어 품질보증팀이 개발팀의 작업 완료 후 회귀 테스트를 실시해 왔습니다.그러나 이 단계에서 발견된 결함은 수리하는 데 가장 많은 비용이 듭니다.이 문제는 유닛 테스트의 증가로 해결되고 있습니다.개발자들은 항상 개발 주기의 일부로 테스트 케이스를 작성했지만, 이러한 테스트 케이스는 일반적으로 의도된 결과만을 검증하는 기능 테스트 또는 단위 테스트였다.개발자 테스트는 개발자가 유닛 테스트에 초점을 맞추고 양성과 음성의 테스트 [8]케이스를 모두 포함하도록 강요합니다.

기술

다양한 회귀 테스트 기술은 다음과 같습니다.

모두 다시 테스트

이 기술은 현재 프로그램의 모든 테스트 케이스를 검사하여 무결성을 검사합니다.모든 케이스를 재실행해야 하기 때문에 비용이 많이 들지만 변경된 [9]코드로 인한 오류가 발생하지 않도록 합니다.

회귀 검사 선택

모두 다시 테스트와 달리, 이 기술은 테스트 스위트의 부품 선택 비용이 모두 다시 테스트 [9]기술보다 적은 경우 테스트 스위트의 일부를 실행합니다(모두 다시 테스트 비용 발생).

테스트 케이스의 우선순위 부여

테스트 스위트의 장애 검출 속도를 높이기 위해 테스트 케이스의 우선순위를 부여합니다.테스트 케이스 우선순위 부여 기법은 우선순위가 높은 테스트 케이스가 [9]우선순위가 낮은 테스트 케이스보다 먼저 실행되도록 테스트 케이스를 스케줄 한다.

테스트 케이스 우선순위 부여 유형

  • 일반적인 우선순위 부여– 후속 버전에 도움이 되는 테스트 케이스의 우선순위를 부여합니다.
  • 버전 고유의 우선순위 부여– 특정 버전의 소프트웨어에 대한 테스트 케이스의 우선순위를 부여합니다.

하이브리드

이 기술은 회귀 테스트 선택과 테스트 케이스 우선순위 [9]부여를 혼합한 것입니다.

장점과 단점

회귀 테스트는 소프트웨어의 기존 기능이 변경되었을 때 또는 소프트웨어에 버그가 수정되었을 때 실행됩니다.회귀 테스트는 여러 접근방식을 통해 달성할 수 있습니다.전체 테스트 접근방식을 따를 경우 소프트웨어에 대한 변경이 [10]기존 기능에 영향을 미치지 않고 변경되지 않았다는 확신을 제공합니다.

소프트웨어 개발 라이프 사이클이 매우 짧고 리소스가 부족하며 소프트웨어 변경이 빈번한 신속한 변화를 위한 소프트웨어 개발에서는 회귀 테스트로 불필요한 [10]오버헤드가 많이 발생할 수 있습니다.

서드파티제의 블랙박스 컴포넌트를 사용하는 경향이 있는 소프트웨어 개발 환경에서는 서드파티제의 컴포넌트가 변경되면 시스템의 나머지 부분이 방해될 수 있기 때문에 회귀 테스트를 실행하는 것이 까다로울 수 있습니다(또한 서드파티제의 컴포넌트는 불분명한 [10]엔티티이기 때문에 회귀 테스트를 실행하는 것은 어렵습니다.

사용하다

회귀 테스트는 프로그램의 정확성을 테스트하는 데뿐만 아니라 종종 [11]출력 품질을 추적하는 데도 사용할 수 있습니다.예를 들어 컴파일러 설계에서 회귀 테스트는 코드 크기와 테스트 스위트 케이스를 컴파일하고 실행하는 데 걸리는 시간을 추적할 수 있습니다.

또한 새로운 버그가 도입되었기 때문에 프로그램 유지보수는 다른 어떤 프로그래밍보다 기술문당 훨씬 더 많은 시스템 테스트를 필요로 합니다.이론적으로 각 수정 후 시스템에 대해 이전에 실행한 테스트 케이스 전체를 실행하여 시스템이 불명확하게 손상되지 않았는지 확인해야 합니다.실제로 이러한 회귀 테스트는 실제로 이 이론적인 아이디어에 근접해야 하며 비용이 많이 듭니다.

--

회귀 검정은 크게 기능 검정 또는 단위 검정으로 분류할 수 있습니다.기능 테스트는 다양한 입력으로 전체 프로그램을 연습합니다.유닛 테스트는 개별 함수, 서브루틴 또는 객체 메서드를 연습합니다.기능 테스트 도구와 유닛 테스트 도구 모두 자동화되는 경향이 있으며, 대부분의 경우 컴파일러 스위트에 포함되지 않은 서드파티 제품입니다.기능 테스트는 일련의 프로그램 입력 스크립트로 작성된 것일 수 있으며, 마우스 이동 및 클릭을 제어하는 자동화된 메커니즘이 포함될 수도 있습니다.유닛 테스트는 코드 자체 내의 개별 기능 세트이거나 테스트 대상 코드를 변경하지 않고 코드에 링크하는 드라이버 계층일 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Pezzè, Mauro; Young, Michal (2008). Software testing and analysis: process, principles, and techniques. Wiley. Testing activities that focus on regression problems are called (non) regression testing. Usually "non" is omitted
  2. ^ Basu, Anirban (2015). Software Quality Assurance, Testing and Metrics. PHI Learning. ISBN 978-81-203-5068-7.
  3. ^ 군용기의 노후 항전학 연구 위원회: 군용기의 노후 항전학.National Academy Press, 2001, 2페이지: 【각 테크놀로지 갱신 사이클에는 회귀 테스트가 필요합니다.″
  4. ^ Boulanger, Jean-Louis (2015). CENELEC 50128 and IEC 62279 Standards. Wiley. ISBN 978-1119122487.
  5. ^ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 73. ISBN 978-0-470-04212-0.
  6. ^ 실행 가능한 경우 회귀 테스트 자동화, 자동 테스트: 선택된 베스트 프랙티스, Elfride Dustin, Safari Books 온라인
  7. ^ daVeiga, Nada (2008-02-06). "Change Code Without Fear: Utilize a Regression Safety Net". Dr. Dobb's Journal.
  8. ^ Dudney, Bill (2004-12-08). "Developer Testing Is 'In': An interview with Alberto Savoia and Kent Beck". Retrieved 2007-11-29.
  9. ^ a b c d Duggal, Gaurav; Suri, Bharti (2008-03-29). Understanding Regression Testing Techniques. National Conference on Challenges and Opportunities. Mandi Gobindgarh, Punjab, India. CiteSeerX 10.1.1.460.5875.
  10. ^ a b c Yoo, S.; Harman, M. (2010). "Regression testing minimization, selection and prioritization: a survey". Software Testing, Verification and Reliability. 22 (2): 67–120. doi:10.1002/stvr.430.
  11. ^ Kolawa, Adam. "Regression Testing, Programmer to Programmer". Wrox.

외부 링크