회귀 테스트
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
회귀 테스트는 소프트웨어의 변경 또는 수정 후, 기존 기능에 새로운 결함이 발생하거나 기존 결함이 다시 나타나는 것을 방지하기 위해 수행하는 테스트이다. 소프트웨어 개발 과정에서 버그 수정 후 해당 버그를 노출하는 테스트를 기록하고, 이후 변경 사항 발생 시 정기적으로 재실행하는 것이 권장된다. 회귀 테스트는 자동화된 테스트 도구를 활용하거나, 익스트림 프로그래밍과 같은 개발 방법론의 일부로 수행될 수 있으며, 기능 테스트, 단위 테스트 등 다양한 형태로 분류된다. 회귀 테스트는 소프트웨어의 정확성을 보장하고 품질을 추적하는 데 기여하지만, 애자일 개발 환경이나 블랙 박스 컴포넌트 사용 환경에서는 오버헤드 발생 및 테스트의 어려움과 같은 한계와 과제가 존재한다.
더 읽어볼만한 페이지
- 익스트림 프로그래밍 - 워드 커닝햄
워드 커닝햄은 미국의 컴퓨터 프로그래머로, 최초의 위키 사이트 WikiWikiWeb을 만들고 기술 부채 개념을 창안했으며, 소프트웨어 개발 방법론 발전에 기여했다. - 익스트림 프로그래밍 - JUnit
JUnit은 자바 환경에서 단위 테스트를 위한 프레임워크로, 반복적인 테스트 실행을 통해 버그 수정에 용이하며, 어노테이션 기반의 간편한 테스트 코드 작성과 IDE 통합을 지원하여 개발 효율성을 높인다. - 소프트웨어 테스트 - 보안 취약점
보안 취약점은 시스템의 설계, 구현, 운영, 관리상 결함이나 약점으로, 위협에 의해 악용되어 시스템 보안 정책을 위반할 수 있는 요소이며, ISO 27005, IETF RFC 4949, NIST SP 800-30, ENISA 등 다양한 기관에서 정의하고 있다. - 소프트웨어 테스트 - A/B 테스트
A/B 테스트는 두 가지 이상의 대안을 비교하여 더 나은 성과를 판단하는 방법으로, 웹사이트, 애플리케이션 등 다양한 분야에서 사용자 인터페이스 등을 테스트하며 통계적 가설 검정을 기반으로 한다.
| 회귀 테스트 | |
|---|---|
| 개요 | |
| 분야 | 소프트웨어 개발 |
| 목적 | 소프트웨어 변경 후 기존 기능 유지 확인 |
| 관련 항목 | 테스트 자동화 테스트 주도 개발 행동 주도 개발 소프트웨어 테스팅 블랙박스 테스팅 화이트박스 테스팅 |
| 설명 | |
| 정의 | 소프트웨어의 변경 사항이 기존 기능에 부정적인 영향을 미치지 않았음을 확인하는 테스트 |
| 목표 | 변경 후에도 소프트웨어가 예상대로 작동하는지 확인 기존 기능이 새로운 변경으로 인해 손상되지 않았는지 확인 |
| 수행 시점 | 새로운 기능 추가 후 버그 수정 후 구성 변경 후 성능 최적화 후 |
| 방법 | 기존 테스트 케이스 재실행 새로운 테스트 케이스 추가 자동화된 테스트 도구 활용 |
| 장점 | 기존 기능의 안정성 보장 예상치 못한 문제 발생 방지 소프트웨어 품질 향상 |
| 고려 사항 | 테스트 범위 설정 테스트 케이스 설계 테스트 환경 구축 테스트 결과 분석 |
| 회귀 테스트 유형 | 전체 회귀 테스트: 전체 시스템을 테스트하는 방법 부분 회귀 테스트: 특정 모듈 또는 기능만 테스트하는 방법 단위 회귀 테스트: 개별 코드 단위(함수, 클래스 등)를 테스트하는 방법 |
| 자동화 | |
| 필요성 | 반복적인 테스트 작업을 효율적으로 수행하고 시간과 비용을 절감하기 위해 자동화된 테스트 도구를 사용하는 것이 중요 |
| 도구 | Selenium JUnit TestNG Mockito Appium |
| 기타 | |
| 주의사항 | 테스트 케이스를 최신 상태로 유지하고, 변경 사항을 반영해야 함 |
2. 배경
소프트웨어가 업데이트, 변경되거나 수정된 대상에서 재사용될 때, 새로운 결함이 발생하거나 기존 결함이 다시 나타나는 것은 매우 흔한 일이다.
때로는 개정 관리의 부실한 관리(또는 개정 관리에서의 단순한 인적 오류)으로 인해 수정 사항이 손실되어 다시 나타나는 경우가 있다. 종종 문제에 대한 수정은 처음에 관찰된 좁은 경우에만 문제를 해결하고 소프트웨어 수명 동안 발생할 수 있는 더 일반적인 경우에는 해결하지 못하는 "취약"한 방식일 수 있다. 또한, 한 영역의 문제에 대한 수정이 의도치 않게 다른 영역에서 소프트웨어 버그를 발생시키는 경우가 많다.
기능을 재설계할 때 해당 기능의 원래 구현에서 발생했던 것과 동일한 실수가 재설계에서도 발생하는 경우가 있다.
2. 1. 회귀 테스트의 필요성
회귀 테스트는 프로그램의 정확성뿐만 아니라 결과물의 품질을 지속적으로 기록하는 데 유용하다. 예를 들어, 컴파일러 설계에서 회귀 테스트는 테스트 스위트의 코드 크기, 시뮬레이션 시간, 컴파일 타임을 지속적으로 기록한다.회귀 테스트는 크게 기능 테스트와 유닛 테스트로 나눌 수 있다. 기능 테스트는 완성된 프로그램에 여러 입력을 넣어 동작을 확인하는 것이고, 유닛 테스트는 개별 함수, 서브루틴, 메소드 등을 동작시켜 보는 것이다. 기능 테스트와 유닛 테스트 도구는 대부분 자동화되어 있으며, 써드파티 제품인 경우가 많다. 기능 테스트는 마우스 포인터 이동이나 클릭까지 표현하는 자동화 메커니즘을 포함하기도 한다. 유닛 테스트는 코드 내 별도 함수이거나, 테스트 대상 코드 변경 없이 별도 드라이버 계층으로 구성되기도 한다.
소프트웨어 업데이트, 변경, 수정 시 새로운 결함이 발생하거나 기존 결함이 다시 나타나는 것은 흔한 일이다. 이는 개정 관리 부실이나 인적 오류로 인해 수정 사항이 손실되어 발생하기도 한다. 때로는 문제에 대한 수정이 좁은 범위에서만 해결되고, 더 일반적인 경우에는 해결되지 않는 "취약"한 경우도 있다. 또한, 한 영역의 수정이 다른 영역에서 소프트웨어 버그를 발생시키기도 한다. 기능을 재설계할 때 원래 구현과 동일한 실수가 반복되기도 한다.
대부분의 소프트웨어 개발 상황에서 버그 발견 및 수정 시 해당 버그를 노출하는 테스트를 기록하고, 후속 변경 후 정기적으로 재실행하는 것이 좋은 코딩 관행으로 간주된다.[5] 이는 수동 테스트로도 가능하지만, 자동화된 테스트 도구를 사용하는 경우가 많다.[6] 이러한 테스트 슈트에는 자동 실행 도구가 포함되며, 많은 프로젝트에서 지속적 통합 시스템을 통해 정기적으로 회귀 테스트를 실행하고 실패를 보고한다.[7] 일반적인 전략은 (작은 프로젝트의 경우) 성공적인 컴파일 후, 매일 밤 또는 일주일에 한 번 실행하는 것이며, 외부 도구로 자동화할 수 있다.
회귀 테스트는 익스트림 프로그래밍의 필수 요소이다. 설계 문서는 각 단계에서 광범위하고 반복 가능하며 자동화된 테스트로 대체된다. 기능 테스트 완료 후 다른 기능 작동 여부 확인을 위해 회귀 테스트를 수행한다.
기업 환경에서 회귀 테스트는 전통적으로 소프트웨어 품질 보증 팀이 수행했지만, 이 단계에서 발견된 결함은 수정 비용이 가장 크다. 단위 테스트의 등장으로 이 문제가 해결되고 있다. 개발자는 항상 테스트 케이스를 작성했지만, 주로 의도된 결과만 확인하는 기능 테스트 또는 단위 테스트였다. 개발자 테스트는 개발자가 단위 테스트에 집중하고 긍정적 및 부정적 테스트 케이스를 모두 포함하도록 한다.[8]
3. 종류 및 기법
회귀 테스트에는 다음과 같은 다양한 기법이 있다.[9]
| 기법 | 설명 |
|---|---|
| 전체 재검사 (Retest All) | 모든 테스트 케이스를 다시 실행하여 코드 변경으로 인한 오류가 없는지 확인한다. 비용이 많이 들지만 가장 확실하다. |
| 테스트 스위트 선택 (Test Suite Selection) | 테스트 스위트의 일부만 실행한다. 전체 재검사보다 비용이 적게 드는 경우에 유용하다. |
| 테스트 케이스 우선순위 지정 (Test Case Prioritization) | 테스트 케이스의 우선순위를 정하여 결함 감지율을 높인다. 우선순위가 높은 테스트 케이스가 먼저 실행된다. |
| 하이브리드 (Hybrid) | 회귀 테스트 선택과 테스트 케이스 우선순위 지정을 결합한다. |
테스트 케이스 우선순위 지정은 일반 우선순위 지정과 버전별 우선순위 지정으로 나뉜다.
- 일반 우선순위 지정: 이후 버전에서도 유용할 가능성이 높은 테스트 케이스에 우선순위를 부여한다.
- 버전별 우선순위 지정: 특정 소프트웨어 버전에 관련된 테스트 케이스에 우선순위를 부여한다.
3. 1. 기능 테스트
기능 테스트는 완성된 프로그램에 여러 가지 입력을 주어 동작시켜 보는 활동이다. 기능 테스트와 유닛 테스트 도구는 모두 써드파티 제품인 경우가 많고, 두 가지 테스트 모두 자동화되어 있는 경우가 많다. 기능 테스트는 프로그램에 대한 연속적인 입력의 형태로 기술될 수 있는데, 마우스 포인터의 이동이나 클릭까지 표현할 수 있는 자동화된 메커니즘을 포함하기도 한다.[5] 익스트림 프로그래밍에서 기능 테스트가 완료된 후 다른 기능이 작동하는지 확인하기 위해 회귀 테스트가 수행된다.3. 2. 유닛 테스트
회귀 테스트는 크게 기능 테스트와 유닛 테스트로 분류할 수 있다. 유닛 테스트는 개별 함수, 서브루틴, 메소드 등을 동작시켜 보는 활동이다. 기능 테스트와 유닛 테스트 도구는 모두 써드파티 제품인 경우가 많고, 두 가지 테스트 모두 자동화되어 있는 경우가 많다. 유닛 테스트는 프로그램 코드 내에 포함되어 있는 별도의 함수들인 경우도 있고, 테스트 대상이 되는 코드의 변경이 전혀 없이 별도의 드라이버 계층으로 구성되는 경우도 있다.[5]기업 환경에서 회귀 테스트는 전통적으로 개발 팀이 작업을 완료한 후 소프트웨어 품질 보증 팀에 의해 수행되었다. 그러나 이 단계에서 발견된 결함은 수정하는 데 가장 많은 비용이 들었다. 이러한 문제는 단위 테스트의 등장으로 해결되고 있다. 개발자는 항상 개발 주기의 일부로 테스트 케이스를 작성했지만, 이러한 테스트 케이스는 일반적으로 의도된 결과만 확인하는 기능 테스트 또는 단위 테스트였다. 개발자 테스트는 개발자가 단위 테스트에 집중하고 긍정적 및 부정적 테스트 케이스를 모두 포함하도록 강제한다.[8]
3. 3. 회귀 테스트 최적화 기법
회귀 테스트를 최적화하는 주요 기법은 다음과 같다.- 테스트 스위트 최소화: 코드 커버리지와 같은 기준을 충족하는 데 필요하지 않은 테스트를 제거한다.
- 테스트 케이스 선택: 이전 버전과 현재 버전을 비교하여 변경된 부분과 관련된 테스트만 선택하여 실행한다.
- 테스트 스위트 우선순위화: 테스트 케이스에 우선순위를 부여하여 회귀 버그를 찾을 가능성이 높은 테스트부터 실행한다. 시간이 부족하여 테스트를 임의의 시점에 종료해야 할 경우에도 최대한 효과적인 테스트를 보장한다.
각 기법은 장단점을 가지며, 소프트웨어 특성과 개발 환경에 따라 적절한 기법을 선택하거나 조합하여 사용한다. 예를 들어, 테스트 스위트 최소화는 테스트 시간을 줄이지만, 중요한 버그를 놓칠 수 있다. 테스트 케이스 선택은 변경된 부분에 집중하여 효율성을 높이지만, 변경되지 않은 부분의 버그는 발견하지 못할 수 있다. 테스트 스위트 우선순위화는 제한된 시간 안에 최대한 많은 버그를 찾도록 돕지만, 우선순위가 낮은 테스트 케이스의 버그는 늦게 발견될 수 있다.
회귀 테스트 기법의 종류는 다음과 같다.
테스트 케이스 우선순위 지정은 일반 우선순위 지정과 버전별 우선순위 지정으로 나뉜다.
- 일반 우선순위 지정: 이후 버전에서도 유용할 가능성이 높은 테스트 케이스에 우선순위를 부여한다.
- 버전별 우선순위 지정: 특정 소프트웨어 버전에 관련된 테스트 케이스에 우선순위를 부여한다.
4. 도구 및 자동화
회귀 테스트는 수동으로 진행할 수도 있지만, 주로 자동화된 테스트 도구를 활용한다.[5] 자동화된 테스트 슈트는 테스트 환경이 모든 회귀 테스트 케이스를 자동으로 실행할 수 있게 해주는 소프트웨어 도구를 포함한다.[6] 많은 프로젝트에서 지정된 간격으로 모든 회귀 테스트를 다시 실행하고, 실패(회귀 또는 오래된 테스트를 의미)를 보고하는 자동화된 지속적 통합 시스템을 사용한다.[7] 소규모 프로젝트에서는 성공적인 컴파일 후, 매일 밤 또는 일주일에 한 번 이러한 시스템을 실행하는 것이 일반적이며, 이러한 전략은 외부 도구로 자동화할 수 있다.
익스트림 프로그래밍에서 회귀 테스트는 필수적이다. 이 방법에서 설계 문서는 전체 소프트웨어 개발 프로세스의 각 단계에서 광범위하고 반복 가능하며 자동화된 테스트로 대체된다. 기능 테스트가 완료된 후 다른 기능이 작동하는지 확인하기 위해 회귀 테스트를 수행한다.
기업 환경에서 회귀 테스트는 전통적으로 개발 팀이 작업을 완료한 후 소프트웨어 품질 보증 팀에 의해 수행되었다. 그러나 이 단계에서 발견된 결함은 수정 비용이 가장 크다. 단위 테스트의 등장으로 개발자는 개발 주기의 일부로 테스트 케이스를 작성하고, 긍정적 및 부정적 테스트 케이스를 모두 포함하는 단위 테스트에 집중하게 되면서 이 문제가 해결되고 있다.[8]
4. 1. 자동화 도구의 장점
회귀 테스트는 프로그램의 정확성뿐만 아니라 그 결과물의 품질을 지속적으로 기록하는 데 유용하다. 컴파일러 디자인의 경우, 회귀 테스트는 테스트 스위트의 코드 크기, 시뮬레이션 시간과 컴파일 타임을 지속적으로 기록해야 한다.Frederick Brooks|프레더릭 브룩스영어는 그의 저서 《맨먼스 미신》에서 다음과 같이 말했다.
> "새로운 버그가 발견될 때마다 프로그램 유지 보수를 위해서 각 상태 별로 더 많은 시스템 테스트가 필요하게 된다. 이론적으로는 예기치 않은 문제의 발생을 방지하기 위해서 각각의 버그 수정 후에는 반드시 이전에 실행했던 전체 배치 테스트를 수행해야한다. 그러나 실제로 이런 ''회귀 테스트''는 이론에나 부합되는 굉장한 아이디어긴 하지만 상당한 비용을 지불해야된다는 것을 깨닫게 된다." (p 122)
회귀 테스트는 크게 기능 테스트와 유닛 테스트로 분류할 수 있다. 기능 테스트는 완성된 프로그램에 여러 가지 입력을 주어 동작시켜 보는 활동이다. 유닛 테스트는 개별 함수, 서브루틴, 메소드 등을 동작시켜 보는 활동이다. 기능 테스트와 유닛 테스트 도구는 모두 써드파티 제품인 경우가 많고, 두 가지 테스트 모두 자동화되어 있는 경우가 많다. 기능 테스트는 프로그램에 대한 연속적인 입력의 형태로 기술될 수 있는데, 마우스 포인터의 이동이나 클릭까지 표현할 수 있는 자동화된 메커니즘을 포함하기도 한다. 유닛 테스트는 프로그램 코드 내에 포함되어 있는 별도의 함수들인 경우도 있고, 테스트 대상이 되는 코드의 변경이 전혀 없이 별도의 드라이버 계층으로 구성되는 경우도 있다.
회귀 테스트를 수행하는 가장 간단한 방법은 이전 버전에 해당하는 모든 회귀 테스트 케이스를 실행하는 것이다. 하지만 이 방법을 따르면 소프트웨어 버전이 올라갈수록 실행해야 하는 회귀 테스트 케이스 개수가 늘어나는 단점이 있다. 심한 경우, 회귀 테스트 스위트의 크기가 너무 커져서 더 이상 정상적인 회귀 테스트를 진행하는 것이 불가능할 수도 있다. 이 문제를 해결하기 위해 테스트 스위트 최소화, 테스트 케이스 선택, 테스트 스위트 우선순위화의 세 가지 최적화 기법이 개발되었다. 테스트 스위트 최소화 기법은 사용하는 테스트 기준(예: 코드 커버리지)을 달성하는 데 불필요한 테스트를 회귀 테스트 스위트에서 제거한다. 테스트 케이스 선택 기법은 이전 버전과 현재 버전을 비교하여 변화가 있는 부분과 연관된 테스트만 선택하여 실행한다. 테스트 스위트 우선순위화는 회귀 테스트에 걸리는 시간이 너무 길어서 임의의 시점에 종료해야 할 경우, 가능한 최선의 테스트가 수행되도록 테스트 케이스에 우선순위를 부여하여 회귀 버그를 인지할 확률이 가장 높은 테스트부터 실행하는 기법이다.
5. 한계 및 과제
회귀 테스트는 소프트웨어의 기존 기능에 변경이 있거나 버그가 수정될 때 수행된다. "모두 테스트" 접근 방식을 사용하면 소프트웨어 변경 사항이 기존 기능에 영향을 미치지 않는다는 확신을 얻을 수 있다.[10]
애자일 소프트웨어 개발은 개발 생명 주기가 짧고 자원이 부족하며 변경이 잦아 회귀 테스트가 불필요한 오버헤드를 유발할 수 있다.[10][24]
블랙 박스 컴포넌트를 외부에서 가져와 사용하는 경우, 해당 컴포넌트의 변경이 시스템의 다른 부분에 영향을 줄 수 있어 회귀 테스트 수행이 까다로울 수 있다. (제3자 컴포넌트에 대한 회귀 테스트는 알 수 없는 개체이므로 어렵다).[10][25]
5. 1. 한계
회귀 테스트를 수행하는 가장 간단한 방법은 이전 버전에 해당하는 회귀 테스트 케이스를 모두 실행하는 것이다. 하지만 이 방법을 따를 경우, 소프트웨어의 버전이 올라갈수록 실행해야 하는 회귀 테스트 케이스 개수가 늘어나는 단점이 있다. 심한 경우, 회귀 테스트 스위트의 크기가 너무 커서 더 이상 정상적인 회귀 테스트를 진행하는 것이 불가능할 수도 있다.[10] 이 문제를 해결하기 위해 크게 세 가지 최적화 기법이 개발되었다.- 테스트 스위트 최소화 기법은 사용하는 테스트 기준(예를 들어 코드 커버리지)을 달성하는 데 불필요한 테스트를 회귀 테스트 스위트에서 제거한다.
- 테스트 케이스 선택 기법은 이전 버전과 현재 버전을 비교하여 변화가 가해진 부분과 연관이 있는 테스트만을 선택하여 실행한다.
- 테스트 스위트 우선순위화는 회귀 테스트에 걸리는 시간이 너무 길어서 임의의 시점에 종료해야 할 경우, 가능한 최선의 테스트가 행해졌음을 보장하기 위해 테스트 케이스에 우선순위를 부여해서 회귀 버그를 인지할 확률이 가장 높은 테스트부터 실행한다.
소프트웨어 개발 생명 주기가 매우 짧고, 자원이 부족하며, 소프트웨어 변경이 매우 빈번한 애자일 소프트웨어 개발에서는 회귀 테스트가 불필요한 많은 오버헤드를 유발할 수 있다.[10][24]
블랙 박스 컴포넌트를 제3자로부터 사용하는 경향이 있는 소프트웨어 개발 환경에서는 회귀 테스트를 수행하는 것이 까다로울 수 있다. 제3자 컴포넌트의 변경 사항이 시스템의 나머지 부분에 간섭할 수 있기 때문이다(제3자 컴포넌트에 대한 회귀 테스트는 알 수 없는 개체이므로 어렵다).[10][25]
5. 2. 과제
회귀 테스트를 수행하는 가장 간단한 방법은 이전 버전에 해당하는 회귀 테스트 케이스를 모두 실행하는 것이다. 하지만 이 방법을 따를 경우, 소프트웨어의 버전이 올라갈수록 실행해야 하는 회귀 테스트 케이스 개수가 늘어나는 단점이 있다. 심한 경우, 회귀 테스트 스위트의 크기가 너무 커서 더 이상 정상적인 회귀 테스트를 진행하는 것이 불가능할 수도 있다. 이 문제를 해결하기 위해 크게 테스트 스위트 최소화, 테스트 케이스 선택, 테스트 스위트 우선순위화의 세 가지 최적화 기법이 개발되었다. 테스트 스위트 최소화 기법은 사용하는 테스트 기준(예를 들어 코드 커버리지)을 달성하는 데 불필요한 테스트를 회귀 테스트 스위트에서 제거하는 것을 기본 골자로 한다. 테스트 케이스 선택 기법은 이전 버전과 현재 버전을 비교하여 변화가 가해진 부분과 연관이 있는 테스트만을 선택하여 실행하는 기술이다. 마지막으로 테스트 스위트 우선순위화는 회귀 테스트에 걸리는 시간이 너무 길어서 임의의 시점에 종료해야 할 경우, 가능한 최선의 테스트가 행해졌음을 보장하기 위해 테스트 케이스에 우선순위를 부여해서 회귀 버그를 인지할 확률이 가장 높은 테스트부터 실행하는 기법이다.6. 한국 소프트웨어 산업과 회귀 테스트
(내용 없음)
참조
[1]
서적
Software testing and analysis: process, principles, and techniques
https://www.google.c[...]
Wiley
2008
[2]
서적
Software Quality Assurance, Testing and Metrics
https://books.google[...]
PHI Learning
[3]
간행물
Aging Avionics in Military Aircraft
https://www.nap.edu/[...]
National Academies Press
2001
[4]
서적
CENELEC 50128 and IEC 62279 Standards
https://books.google[...]
Wiley
2015
[5]
서적
Automated Defect Prevention: Best Practices in Software Management
http://www.wiley.com[...]
Wiley-IEEE Computer Society Press
[6]
웹사이트
Automate Regression Tests When Feasible
http://safari.oreill[...]
[7]
웹사이트
Change Code Without Fear: Utilize a Regression Safety Net
http://www.drdobbs.c[...]
2008-02-06
[8]
웹사이트
Developer Testing Is 'In': An interview with Alberto Savoia and Kent Beck
http://www.sys-con.c[...]
2007-11-29
[9]
conference
Understanding Regression Testing Techniques
2008-03-29
[10]
journal
Regression testing minimization, selection and prioritization: a survey
2010
[11]
웹사이트
Regression Testing, Programmer to Programmer
http://www.wrox.com/[...]
[12]
서적
Software Quality Assurance, Testing and Metrics
https://books.google[...]
PHI Learning
[13]
간행물
Aging Avionics in Military Aircraft
https://www.nap.edu/[...]
National Academies Press
2001
[14]
서적
CENELEC 50128 and IEC 62279 Standards
https://books.google[...]
Wiley
2015
[15]
서적
Automated Defect Prevention: Best Practices in Software Management
http://www.wiley.com[...]
Wiley-IEEE Computer Society Press
[16]
웹사이트
Automate Regression Tests When Feasible
http://safari.oreill[...]
[17]
웹사이트
Change Code Without Fear: Utilize a Regression Safety Net
http://www.drdobbs.c[...]
2020-12-21
[18]
웹사이트
Developer Testing Is 'In': An interview with Alberto Savoia and Kent Beck
http://www.sys-con.c[...]
2007-11-29
[19]
conference
Understanding Regression Testing Techniques
2008-03-29
[20]
conference
Understanding Regression Testing Techniques
2008-03-29
[21]
conference
Understanding Regression Testing Techniques
2008-03-29
[22]
conference
Understanding Regression Testing Techniques
2008-03-29
[23]
journal
Regression testing minimization, selection and prioritization: a survey
2010
[24]
journal
Regression testing minimization, selection and prioritization: a survey
2010
[25]
journal
Regression testing minimization, selection and prioritization: a survey
2010
[26]
웹사이트
Regression Testing, Programmer to Programmer
http://www.wrox.com/[...]
2020-12-21
[27]
서적
Software testing and analysis: process, principles, and techniques
https://www.google.c[...]
Wiley
2008
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com