회귀 테스트
이 문서의 내용은 출처가 분명하지 않습니다. (2012년 6월) |
회귀 버그를 찾는 모든 소프트웨어 테스트 방식은 회귀 테스트(regression testing, non-regression testing[1])라 할 수 있다. 회귀 버그는 이전에 제대로 작동하던 소프트웨어 기능에 문제가 생기는 것을 가리킨다. 일반적으로 회귀 버그는 프로그램 변경 중 뜻하지 않게 발생한다.
| 소프트웨어 개발 프로세스 | |
|---|---|
| 활동과 단계 | |
| 요구사항 분석 · 기능 명세 구조 · 설계 구현 · 테스팅 배치 · 유지보수 | |
| 개발 모형 | |
| 애자일 소프트웨어 개발 · 클린룸 DSDM · 순차점증적 개발 · 반복형 개발 RAD · RUP · 나선 모형 폭포수 모델 · 익스트림 프로그래밍 스크럼 · V 모델 · TDD | |
| 지원 활동 | |
| 구성 관리 · 문서화 품질보증 · 프로젝트 관리 사용자 경험 설계 | |
| 도구 | |
| 컴파일러 · 디버거 · 프로파일러 GUI 디자이너 · 통합 개발 환경 | |
회귀 테스트로는 이전의 실행 테스트를 재 실행하며 이전에 고쳐졌던 오류가 재현되는지 검사하는 방법이 많이 사용된다.
경험적으로 이러한 오류 재현 방법은 꽤 효과적이다. 왜냐하면 부실한 버전 관리로 인해 이전의 버그 수정분을 유실하고 이로 인해 버그가 재발하는 경우가 종종 있으며, 또한 그저 자주 수정하는 방법은 프로그램을 지저분하게 하는 임시 방편일뿐 근본적인 해결은 되지 못하기 때문이다. 임시적인 수정분들은 프로그램의 다른 부분을 변경할 경우 무용지물이 되는 경우가 많다. 즉, 리팩토링을 통해서 몇몇 기능을 재디자인할 경우 동일한 문제가 이전에 고쳐진 부분에서 다시 발생하는 경우가 많다.
그러므로 버그가 발생했을 경우 이를 수정하면서 해당 버그를 발견할 수 있는 테스트 케이스를 작성하고 이를 이용해 프로그램을 변경할 때마다 테스트를 다시 수행하는 것이 좋다. 수동으로 할 수도 있지만, 보통은 테스트 자동화 툴을 사용한다. 일반적으로 '테스트 스위트'들은 회귀 테스트 케이스들을 자동으로 처리해주는 테스트 환경을 제공한다. 어떤 테스트 스위트들은 자동으로 전체 회귀 테스트를 정해진 시각에 수행하고 그 결과를 보고해주는 기능도 제공한다. 일반적으로 (작은 규모의 프로젝트일 경우는) 컴파일이 이뤄졌을 때에, (덩치가 좀 되는 프로젝트일 경우는) 매일 밤 또는 매주 전체 테스트를 실행한다.
회귀 테스트는 익스트림 프로그래밍의 중요한 부분이다. 이 방법론에 따르면 디자인 문서는 처음 작성된 후에도 소프트웨어 개발 주기 상의 모든 단계마다 업데이트된다. 그러한 업데이트는 전체 소프트웨어 패키지에 대한 확산적이며 반복적인 자동화 테스트를 통해 이뤄진다.
사용
편집회귀 테스트는 프로그램의 정확성뿐만 아니라 그 결과물의 품질을 지속적으로 기록하기에도 유용하다. 컴파일러 디자인 상의 인스턴스를 위해 회귀 테스트는 테스트 스위트의 코드 크기, 시뮬레이션 시간과 컴파일 타임을 지속적으로 기록해야 한다.
"새로운 버그가 발견될 때마다 프로그램 유지 보수를 위해서 각 상태 별로 더 많은 시스템 테스트가 필요하게 된다. 이론적으로는 예기치 않은 문제의 발생을 방지하기 위해서 각각의 버그 수정 후에는 반드시 이전에 실행했던 전체 배치 테스트를 수행해야한다. 그러나 실제로 이런 회귀 테스트는 이론에나 부합되는 굉장한 아이디어긴 하지만 상당한 비용을 지불해야된다는 것을 깨닫게 된다." -- 프레더릭 브룩스, 《맨먼스 미신》 (p 122)
회귀 테스트는 크게 기능 테스트와 유닛 테스트로 분류할 수 있다. 기능 테스트는 완성된 프로그램에 여러 가지 입력을 주어 동작시켜 보는 활동이다. 유닛 테스트는 개별 함수, 서브루틴, 메소드 등을 동작시켜 보는 활동이다. 기능 테스트와 유닛 테스트 도구는 모두 써드파티 제품인 경우가 많고, 또한 두 가지 테스트 모두 자동화되어 있는 경우가 많다. 기능 테스트는 프로그램에 대한 연속적인 입력의 형태로 기술될 수 있는데, 마우스 포인터의 이동이나 클릭까지 표현할 수 있는 자동화된 메커니즘을 포함하기도 한다. 유닛 테스트는 프로그램 코드 내에 포함되어 있는 별도의 함수들인 경우도 있고, 테스트 대상이 되는 코드의 변경이 전혀 없이 별도의 드라이버 계층으로 구성되는 경우도 있다.
회귀 테스팅 문제와 최적화 기법
편집회귀 테스트를 수행하는 가장 간단한 방법은 이전 버전에 해당하는 회귀 테스트 케이스를 모두 실행하는 것이다. 하지만 이 방법을 따를 경우, 소프트웨어의 버전이 올라갈수록 실행해야 하는 회귀 테스트 케이스 개수가 늘어나는 단점이 있다. 심한 경우, 회귀 테스트 스위트의 크기가 너무 커서 더 이상 정상적인 회귀 테스트를 진행하는 것이 불가능할 수도 있다. 이 문제를 해결하기 위해 크게 테스트 스위트 최소화, 테스트 케이스 선택, 테스트 스위트 우선순위화 세 가지의 최적화 기법이 개발되었다. 테스트 스위트 최소화 기법은 사용하는 테스트 기준(예를 들어 코드 커버리지)을 달성하는 데 불필요한테스트를 회귀 테스트 스위트에서 제거하는 것을 기본 골자로 한다. 테스트 케이스 선택 기법은 이전 버전과 현재 버전을 비교하여 변화가 가해진 부분과 연관이 있는 테스트만을 선택하여 실행하는 기술이다. 마지막으로 테스트 스위트 우선순위화는 회귀 테스트에 걸리는 시간이 너무 길어서 임의의 시점에 종료해야 할 경우, 가능한 최선의 테스트가 행해졌음을 보장하기 위해 테스트 케이스에 우선순위를 부여해서 회귀 버그를 인지할 확률이 가장 높은 테스트부터 실행하는 기법이다.
같이 보기
편집각주
편집- ↑ 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