regression test

반응형

리그레션 테스트, (회귀 테스트)

(regression test)

 

유지보수 단계에서는 소프트웨어 수정 후 변경이 올바르게 이루어졌는지 확인하기 위해 리그레션 테스트를 수행합니다. 이 단계에서 소프트웨어 수정은 다음과 같은 이유로 이루어집니다.

 

• 결함 수정 작업 (Corrective Maintenance)
  소프트웨어 사용 중 발견된 결함을 수정하기 위한 유지보수 활동입니다
• 기능 보강 작업 (Perfective Maintenance)
  소프트웨어에 새로운 기능을 추가하거나 성능을 개선하기 위한 유지보수 활동입니다.
• 적응 작업 (Adaptive Maintenance)
  소프트웨어 시스템을 새로운 운영 환경에 적응시키기 위한 유지보수 활동입니다.
• 예방 작업 (Preventive Maintenance)
  더 나은 유지보수를 위해 기존 소프트웨어 시스템에 대한 문서화를 준비하거나, 유지보수에 용이하도록 시스템 구조를 변경하는 활동입니다.

소프트웨어 유지보수 활동 비율은 다음과 같습니다.

• 기능 보강 작업: 50%
• 적응 작업: 25%
• 결함 수정 작업: 21%
• 예방 작업: 4%

소프트웨어 유지보수 활동 비율이란?

 

소프트웨어 유지보수 활동 비율은 소프트웨어 유지보수 과정에서 각기 다른 유형의 유지보수 작업이 차지하는 비중을 나타내는 지표입니다. 이 비율은 유지보수 활동의 종류와 해당 활동이 전체 유지보수 작업에서 차지하는 비율을 백분율로 표현한 것입니다.

예시로 제시한 비율은 다음과 같습니다

1. 기능 보강 작업 (Perfective Maintenance) - 50%: 소프트웨어에 새로운 기능을 추가하거나 성능을 개선하는 작업이 전체 유지보수 활동의 절반을 차지합니다.
2. 적응 작업 (Adaptive Maintenance) - 25%: 소프트웨어가 새로운 운영 환경에 적응할 수 있도록 조정하는 작업이 25%를 차지합니다.
3. 결함 수정 작업 (Corrective Maintenance) - 21%: 소프트웨어의 결함을 수정하는 작업이 21%를 차지합니다.
4. 예방 작업 (Preventive Maintenance) - 4%: 미래의 문제를 예방하거나 시스템 구조를 유지보수하기 쉽게 만드는 작업이 4%를 차지합니다.

이 비율은 조직의 우선순위, 소프트웨어의 성격, 고객 요구 사항 등에 따라 달라질 수 있습니다. 유지보수 활동 비율을 분석하면, 조직이 소프트웨어 유지보수에 어떤 부분에 주력하고 있는지, 어떤 부분이 더 많은 자원과 노력을 필요로 하는지를 파악할 수 있습니다.

 

이러한 유지보수 활동은 필연적으로 소프트웨어 수정 작업을 수반합니다. 따라서 소프트웨어가 변경될 때, 이러한 변경으로 인해 새로운 결함이 발생했는지 검토해야 합니다.

Regression Test Cycle

리그레션 테스트 사이클(Regression Test Cycle)

소프트웨어가 수정된 후, 기존 기능이 올바르게 작동하는지 확인하기 위해 반복적으로 수행되는 일련의 테스트 과정입니다. 리그레션 테스트는 주로 버그 수정, 기능 추가, 성능 개선 등의 이유로 소프트웨어에 변경이 발생했을 때 수행되며, 새로운 변경 사항이 기존의 다른 기능에 영향을 미치지 않았는지 확인하는 데 중점을 둡니다.

리그레션 테스트 사이클의 주요 단계는 다음과 같습니다:

1. 변경 사항 확인
   • 소프트웨어에서 발생한 변경 사항(버그 수정, 기능 추가 등)을 파악합니다.
   • 변경된 모듈이나 기능, 그리고 이 변경이 영향을 미칠 수 있는 관련 영역을 확인합니다.
2.  테스트 계획 수립
   • 변경 사항과 관련된 테스트 케이스를 식별하고, 우선순위를 정합니다.
   • 전체 리그레션 테스트에서 수행할 테스트 범위와 깊이를 결정합니다.
   • 자동화된 테스트가 필요한 경우 이를 설정합니다.
3.  테스트 케이스 실행
   • 식별된 테스트 케이스를 실행합니다. 이 과정에서 기존의 테스트 케이스와 새로운 테스트 케이스를 사용하여 변경된 소프트웨어의 기능을 검증합니다.
   • 결과를 기록하고, 변경 전과 비교하여 차이가 있는지 확인합니다.
4. 결과 분석 및 버그 보고
   • 테스트 결과를 분석하여 예상과 다른 동작이 있는지 확인합니다.
   • 발견된 문제점이나 결함을 개발 팀에 보고합니다.
5. 결함 수정 및 재테스트
   • 발견된 결함을 수정합니다.
   • 수정된 부분에 대해 재테스트를 실시하고, 리그레션 테스트를 반복합니다.
6. 최종 보고 및 종료
   • 모든 테스트가 완료되고 문제 없이 통과되면, 리그레션 테스트 사이클을 종료합니다.
   • 테스트 결과를 정리하여 관련 팀에게 보고합니다.

리그레션 테스트 사이클은 소프트웨어 릴리스의 품질을 보장하는 중요한 과정입니다. 이 사이클을 통해 변경 사항이 시스템에 미치는 영향을 최소화하고, 기존 기능이 계속해서 올바르게 작동하도록 합니다.

일반적으로 유지보수 단계에서 리그레션 테스트는 개발 단계에서 사용된 테스트 케이스를 이용하여 수행됩니다. 개발 단계에서 사용된 테스트 케이스를 수정된 프로그램에 실행하고, 그 결과를 수정 전 프로그램에서 실행한 결과와 비교합니다. 결과가 다르다면, 이 변화가 의도된 것인지 확인해야 하며, 의도된 결과가 아니라면 프로그램에 결함이 있을 수 있습니다. 현재 시장에 나와 있는 대부분의 테스트 도구와 환경은 이러한 형태의 리그레션 테스트를 지원합니다.

리그레션 테스트에서 중요한 고려 사항은 테스트 케이스의 규모입니다. 시간이 지남에 따라 시스템에 새로운 기능이 추가되면, 리그레션 테스트에 소요되는 비용과 시간도 증가하게 됩니다.

리그레션 테스트에는 다양한 방식이 있으며, 그중 하나는 모든 기존 테스트 케이스를 사용하는 "retest-all" 방식입니다. 이 방식은 단순하지만 시간이 많이 소요되고 자원이 많이 필요합니다.

현실적으로 시간과 예산이 한정되어 있기 때문에, 확보된 테스트 케이스의 일부만 사용하여 리그레션 테스트를 수행하는 방법도 있습니다. 이는 "선택적 리그레션 테스트"로 불리며, 변경 영향 분석(change impact analysis)을 통해 원래 프로그램과 변경된 프로그램이 다른 결과를 출력할 가능성이 있는 테스트 케이스를 선택합니다. 예를 들어, 슬라이싱 기법을 이용하면 테스트 케이스가 실행한 문장들 중에서 변경된 부분과 관련된 부분을 분석하여 해당 테스트 케이스를 리그레션 테스트에 포함할 수 있습니다.

 

slicing technique, data flow analysis technique, change impact analysis

 

또 다른 방법은 "테스트 최소화" 방식으로, 중복된 테스트 케이스를 제거하여 전체 테스트 케이스의 수를 줄이는 것입니다. 예를 들어, 하나의 테스트 케이스 t1이 실행한 문장들이 다른 테스트 케이스 t2가 실행한 문장들을 포함하거나 동일한 함수를 실행했다면, t2를 제거할 수 있습니다. 그러나 이 방법은 중요한 테스트 케이스가 제거될 위험이 있으므로 주의가 필요합니다.

마지막으로 "테스트 우선순위" 방식이 있습니다. 이 방식은 테스트 케이스에 우선순위를 부여하여, 중요한 테스트 케이스를 먼저 실행함으로써 가능한 한 빨리 많은 결함을 검출하는 것을 목표로 합니다. 이 방식의 효과성을 평가하기 위해 APFD(average percentage of faults detected)라는 척도를 사용합니다. APFD는 테스트 케이스의 실행 수 대비 검출된 결함의 비율을 측정하며, 높은 APFD는 많은 결함을 빠르게 발견했다는 것을 의미합니다. 따라서 테스트 케이스 우선순위화는 가능한 한 높은 APFD를 얻기 위해 테스트 케이스에 적절한 우선순위를 부여하는 것입니다.

APFD(Average Percentage of Faults Detected)

 

리그레션 테스트는 컴포넌트 테스트, 통합 테스트, 시스템 테스트를 비롯한 모든 단계에서 수행된다.