inpa: SW유지보수 기간 중 신뢰성 보장을 위한 회귀테스트(Regression Test)의 적용

<출처> 

http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000038320&currPage=&searchPrefaceId=&titOrder=&writeOrder=®DtOrder=&searchCondition=TOT&searchKeyword=

운영 중인 소프트웨어는 기능 수정 및 오류 조치를 위해 유지보수를 하게 된다.

최종 개발 서비스 운영 중인 소프트웨어라고 할지라도 요구사항의 변경 및 사용자 만족도를 높이기 위해서는  SW 프로그램의 수정이 불가피하다.

그러나 이 수정에 따라 정상적으로 작동하던 서비스가 수정 패치 이후 정상 작동하지 않는 경우가 발생할 수 있는데, 이를 예방하기 위해 회귀테스트를 사용하게 된다. 또한, 대형 소프트웨어에 대해 전체 테스트를 반복하는 것은 시간과 금전적인 측면에서 상당한 부담일 수 밖에 없다. 이 경우에 있어서도 회귀 테스트는 수정이 의도하지 않은 결과를 초래하지 않는다는 것을 검증하기 위해 사용되게 되는데, 이는 SW프로그램의 유지보수에 있어서 매우 중요한 역할을 하게 된다.

1. 회귀테스트란? 2. 회귀테스트 진행 상의 애로사항 3. 효과적인 회귀테스트가 되기 위해 고려할 점

Q.  ‘회귀테스트’란 구체적으로 어떤 테스트 방식인가요?

 회귀 테스트는 “수정(Modification)이 기대하지 않은 결과를 발생시키지 않는다는 것을 증명하기 위한 시스템이나 컴포넌트에 대한 선택적 재테스트” [IEEE610.12-90] 라고 정의되어있습니다.

즉, SW의 수정된 모듈에 의해 정상적인 기능들이 문제가 있어서는 안된다는 겁니다.

저도 금융 전산 시스템을 관리하면서 수많은 현업의 요구사항의 변화와 지속적으로 발견되는 개선사항들로 인해 프로그램을 수시로 변경하고 있는데요. 신속한 요구사항을 반영을 원하는 환경에서 소수의 프로그램을 수정하고 retest All 하기는 사실상 어렵습니다. 관련성 있는 모듈과 이전 테스트 케이스를 활용하여 검증을 해야 하죠. 이럴 때 필요한 테스트 기법이 ‘회귀테스트’입니다.

Q.   회귀테스트는 어떤 방식으로 하는건가요?

간단히 말해서 오류를 발견하여 수정하고, 다시 원래 문제를 일으켰던 것을 테스트 확인하고, 수정한 부분이 계획했던 대로 수정되었는지 확인, 그리고 수정된 부분이 다른 부분에 영향을 주어 예상하지 않은 오류를 발생시키지 않는지 확인하는 절차를 거치게 됩니다.

<그림 1> 회귀테스트 진행 방식

첫째, 테스트 수행 전 확인 사항을 먼저 체크 합니다. (Smoke test를 함께 진행할 수도 있습니다.) 프로그램 변경 후 단위 기능 테스트의 수행이 완료 되어야 하고, 변경된 각 모듈의 통합 , 배포 수정까지 빌드를 실시합니다.

두 번째로, Test Case Library 같은 도구로 회귀 테스트를 진행합니다.

단위 기능 중심의 이전 기능과 통합 기능의 시나리오 기반의 테스트를 실시하고, 반복 및 제약 부하 환경에서의 성능 테스트를 실시합니다.

마지막으로, 결과 기록 및 사후 검증을 진행합니다.

테스트 수행 결과를 기록하고 성공 여부를 점검한 뒤, 테스트 성공 이후 기존 단위 테스트의 회귀 테스트를 Repository 에 저장합니다. 그리고 변경된 기능 및 시나리오를 감안한 테스트 절차를 최신화 실시(재사용) 합니다.

Q.  회귀테스트를 진행하기 어려운 이유가 있을까요?

회귀 테스트(Regression Test)는 소프트웨어의 기능이 추가될 때마다 전 범위에 대한 테스트를 실시하는 것을 가리킵니다.  처음 시스템 범위가 아래 [그림 2]와 같다면 테스트 범위는 붉은 화살표 만큼이 됩니다.

하지만 시스템이 2번 화살표와 같이 증가하게 되면 테스트 범위는 2번 붉은 화살표 만큼 훨씬 커집니다. 3번만큼 증가하게 되면 그 범위가 더더욱 커집니다. 그러므로 회귀 테스트를 하려면 자동화된 테스트가 필수적입니다.

‘얼마나 정확히 연관된 테스트케이스를 사용하여 테스트 하느냐’가 관건이라고 할 수 있습니다.

<그림 2> 시스템 범위와 회귀테스트 범위

자료 : http://pragmaticstory.tistory.com/585

Q.   그럼 효과적인 회귀테스트가 되기 위해 고려해야 할 점은 무엇인가요?

먼저,  ‘테스트 케이스 관리’ 입니다.

비기능, 기능 요구사항을 토대로 작성되었던 초기 테스트케이스를 기반으로 회귀테스트를 하되, 테스트케이스는 테스트 후 반영된 결과를 토대로 지속적으로 갱신되고 관리되어야 합니다.

둘째, ‘추가적 테스팅 기법 활용’입니다.  ‘지각테스팅 기법’과 ‘스모크 테스트기법’이 대표적인 예인데요. 지각테스팅(Perceptual Testing)은 UI 측면의 노동집약적인 수동 회귀테스팅의 효율성 문제를 해결하기 위한 자동화 테스트 기법을 말하는데, 빠른 반복 스크린샷 이미지를 비교하여 검증하는 기법입니다.

<그림 3> 지각테스팅을 이용한 회귀테스트

최근 Web Service를 통한 SW 개발이 많은데, 이 테스트 기법을 사용하면 유용할 뿐 아니라,

별도의 상용 솔루션들도 있습니다.

또한, 사전 환경을 검증하는 스모크테스팅(Smoke Testing)도 이용할 수 있습니다. 본격적인 테스트의 수행에 앞서, 시스템, 컴포넌트, 소프트웨어 프로그램 등 테스트 대상이나 제품의 빌드(제품 설치 패키지)가 구축된 테스트 환경에서 테스트가 가능한지 여부를 확인하는 기법인데요. 스모크테스트 기법은 개발팀이 제작한 주요 단위 모듈이나 시스템 모듈을 제3자 테스트팀 또는 개발팀 내의 테스트팀이 주체가 되어 테스트케이스 없이 시행하는 기법입니다. 이것은 환경적인 부분을 사전에 체크하여 회귀테스트를 진행할 수 있도록 해줍니다.

마지막으로, Stub과 Driver를 재사용할 수 있는 점을 이용하면 됩니다. 초기 개발 모듈로 사용하였던 Stub 와 Driver 를 재활용함으로써 회귀테스트 시간을 줄일 수 있습니다.

실제 현업에 계시는 분들은 개발 또는 수정 작업을 수행하면서 굳이 ‘회귀테스트’라는 말을 사용하고 있지 않더라도, 비정형적인 방법으로 나름대로의 테스트들을 진행하고 있을 것입니다. 하지만 회귀테스트라는 정식적인 절차와 기법을 도입하고 적용한다면, 좀 더 안정적인 SW 서비스운영과 신속한 서비스 런칭할 수 있다고 생각합니다.