문서요약 - 마이그레이션 프로젝트 테스팅 by Estes

제목: 마이그레이션 프로젝트 테스팅(Migration Project Testing)

저자: Don Estes, 미국

문서유형: 업체 화이트페이퍼(총 21페이지), 2004년

 

마이그레이션 프로젝트의 테스팅에 대하여 기술한 자료

---

정확성 테스팅(Correctness Testing)과 비교 테스팅(Comparison Testing)

마이그레이션 프로젝트에서 크게 두 가지 테스팅 방법이 가능하다. 소프트웨어 테스팅의 전형적인 접근 방법인 정확성 테스팅(correctness testing)은 ‘마이그레이션된 시스템이 정확한 결과를 내는가?’의 답을 찾는 노력인 반면 비교 테스팅(comparison testing)은 ‘마이그레이션된 시스템이 구 시스템과 동일한 결과를 내는가?’에 중점을 둔다. 비교 테스팅에서는 동일한 입력 데이터가 구 프로그램과 마이그레이션된 신규 프로그램에 각각 주어지고 그 결과를 비교하여 동일한 경우 테스트 통과로 판정한다(동일한 결과가 항상 정확한 결과라는 보장은 없음).

 

마이그레이션 대상 시스템의 문서가 불완전하거나, 업데이트가 안되어 있거나, 애초부터 정확하지 않거나, 아예 존재하지 않을 수도 있기 때문에 정확성 테스트에서 테스트 정의/설계를 위해 시스템을 이해하는데 상당한 노력과 시간이 들 수 있다. 구 시스템의 오퍼레이션을 기준으로 하는 비교 테스팅은 이에 비하여 훨씬 수월하게 테스트 정의를 할 수 있지만 테스트 실행 환경을 준비하고 테스트를 실행하는데 상당한 노력이 든다.

업무 시스템 전문가(Subject Matter Experts)

정확성 테스팅의 경우 시스템 사용에 대한(또한 가능하면 시스템 구현에 대한) 깊은 지식을 가진 전문가가 테스트 정의/설계에 밀접하게 관여할 필요가 있다. 비교 테스팅을 계획한 경우에도 이런 전문가의 관여가 필요하지만 그 정도가 훨씬 덜하며, 많은 경우 깊은 지식을 가진 전문가가 아니어도 일반 시스템 사용자의 도움으로 충분히 테스트 정의/설계가 가능하다. 따라서 업무 시스템 전문가가 테스팅 및 테스팅 평가에 정기적으로 참여 할 수 없는 경우 비교 테스팅 전략이 선호된다.

 

프로젝트의 계획된 일정 및 비용 준수를 위해서는 업무 시스템 전문가가 필요한 시점에 가용해야 하는 것이 필수적이므로 마이그레이션 공급업자는 테스트 정의와 실행에서 요구되는 업무 시스템 전문가의 가용성(availability) 및 참여(responsiveness) 수준을 계약에서 분명하게 해야 한다.

테스트 데이터(Test Data)와 실 업무 데이터(Production Data)

초기 테스트 계획에서 고려할 사항 중 하나는 특별하게 준비된 테스트 데이터를 사용할 것인지 실제 업무/운영 데이터를 사용할 것인지 여부이다. 배치 프로그램(batch programs)은 실행 시간이 장시간이므로 테스트 데이터를 사용하는 것이 바람직하다. 상대적으로 볼륨이 작은 테스트 데이터는 테스트 실행에 걸리는 시간을 줄일 수 있고 또한 실제 업무 데이터에서는 드물게 발생하는 입력 데이터의 조합(combinations of input data)도 테스트를 위해 의도적으로 만들어 테스트 데이터에 포함시킬 수 있다.

 

온라인 프로그램은 대개 필요한 데이터에만 접근하고 나머지 데이터는 무시하므로 테스트에서 업무 데이터를 사용하는 것이 크게 문제가 되지는 않는다(테스트 데이터를 사용하든 업무 데이터를 사용하든 실행 시간에 큰 차이가 없음). 다만 업무 데이터를 사용하는 경우 테스트 셋업 시간이 많이 걸릴 수 있다(예, 데이터 전환 후 데이터베이스 복구 시간 등). 반면 테스트 데이터를 사용하는 경우 실제 업무 데이터에서 나타나는 다양한 상황들을 정확하게 반영하는 데이터를 준비하는 일이 매우 복잡하고 시간이 걸리는 작업이 될 수 있다. 따라서 기술자들의 스킬이나 작업 일정의 촉박한 정도 등을 고려하여 테스트 데이터를 사용할지 업무 데이터를 사용할지를 결정한다.

배치 비교 테스트(Batch Comparison Tests)

배치 프로그램의 테스트를 위해 아래와 같은 절차로 배치 스크립트(batch scripts)를 작성하고 스크립트에 문제가 없는지를 확인한다.

• 테스트 대상 배치 프로그램이 접근하는 모든 파일과 데이터베이스 집합을 명세(해당 프로그램의 내부 알고리즘이나 JCL decks을 참고)
• 테스트 대상 배치 프로그램의 입력이 되는 모든 파일의 이미지를 확보. 이를 사전 이미지(the “before” image)로 부른다.
• 테스트 대상 프로그램의 소스 이미지를 확보하고, 실행 전에 이 소스에 따라 해당 프로그램을 컴파일한다. 이 특정 소스 집합이 마이그레이션 프로세스의 입력이 된다.
• 정확한 실행 패러미터(execution parameters)의 이미지를 확보하고, 해당 프로그램만이 공용 파일 및 데이터베이스(shared files and/or databases)를 업데이트 할 수 있도록 프로그램을 실행시킨다. 일련의 프로그램들이 실행될 때 종종 테스트 노력 최소화를 위해 최종 프로그램의 결과만 비교하지만 중간 단계의 파일들도 보관하여 문제(차이점)가 있는 경우 역추적이 가능하도록 한다.
• 모든 출력 파일/데이터베이스와 실행 중 업데이트된 파일들의 사후 이미지를(the “after” image)를 확보
• 배치 실행 중 사용된 모든 파일과 데이터베이스의 이미지가 확보되었는지 그리고 확보된 이미지(사전 및 사후 이미지)가 정확한지 확인하기 위해 시스템 로그를 사용하여 실행 후 감사(a post execution audit)를 수행하고 문제가 있는 배치 테스트 스크립트는 다시 생성한다.

위 처럼 배치 테스트 스크립트를 작성한 소스가 마이그레이션 된 후에는 아래와 같이 비교 테스트를 수행한다.

• 배치 실행 이전 데이터와 이후 데이터가 새로운 데이터베이스와 시스템 플랫폼으로 전환되어야 한다(전환된 배치 실행 후 데이터는 테스트 실행 후 결과 비교에 사용됨)
• 전환된 배치 실행 전 데이터를 입력으로 하여 기 작성된 배치 테스트 스크립트를 실행 시킨다.
• 테스트 스크립트 실행에 따른 출력 파일, 업데이트된 파일, 데이터베이스 테이블 등을 앞에서 준비한 전환된 배치 실행 후 데이터와 비교한다. 비교 방법으로는 특정 레코드의 일관성, 레코드 개수 등을 확인하는 수작업 검사를 하거나 특수하게 제작된 프로그램(비교 유틸리티)을 사용하여 자동으로 파일을 비교할 수도 있다. 비교 시 타임스탬프 같은 의미 없는 차이점 들은 비교 유틸리티가 무시할 수 있어야 한다.
• 프로그램이 비교 테스트에 실패하면 적절한 수정을 거쳐 다시 테스트가 수행된다.

배치 정확성 테스트(Batch Correctness Tests)

정확성 테스트는 데이터를 두 번 전환하고 비교 프로그램(비교 유틸리티)을 다양한 데이터 저장소에서 실행해야 하는 테스트 준비상의 복잡함은 피하게 해주지만, 결과가 정확한지 아닌지를 어떻게 결정할지 배치 테스트 스크립트에 정의해야만 한다(예, 총계 확인이나 프로그램 실행의 특정 측면 확인). 따라서 테스트의 정확성이 테스트 스크립트를 작성하는 사람의 지식 수준에 의존하게 된다.

온라인 비교 테스트(Online Comparison Tests)

• 배치 테스트 스크립트처럼 온라인 비교 테스트 스크립트도 소스와 데이터 저장소에 대한 사전/사후 이미지를 확보한다. 정확한 화면 입력 및 화면 출력을 하드 카피나 테스트 목적으로 특별하게 설계된 소프트웨어 도구에 보관
• 마이그레이션된 프로그램의 테스팅 수행 시 보관된 입력 이미지와 정확하게 동일한 화면 입력 순서가 주어져야 하며 그 출력물을 보관된 출력 화면 이미지와 비교한다(이 프로세스를 소프트웨어 도구를 이용하여 자동화 가능하지만 이런 온라인 capture/replay 도구는 화면 이미지에만 적용 가능 가능하고 데이터베이스 접근/업데이트나 배치 테스팅은 다루지 못함)

온라인 정확성 테스트(Online Correctness Tests)

• 엄격한 온라인 정확성 테스트에서는 파일/데이터베이스가 예상된 결과 값을 가지는지 확인하기 위해 화면 출력과 알고리즘 모두를 비교하지만, 종종 이 테스트가 저장된 데이터 검증을 무시한 채 단지 화면 출력만을 비교하는 것으로 약소화되는 경향이 있다.
• 엄격한 비교 테스팅에 비해 테스터들이 수행하기에 덜 어려운 테스트로 여겨지지만 정확한 테스트를 위해서는 대상 프로그램에 대한 깊은 지식이 요구된다.

테스팅 단계(Stages of Testing)

마이그레이션 프로젝트에서 테스팅은 일반적으로 5단계로 나누어진다.

①     단위 테스트(Unit tests): 대개 테스트 데이터를 사용한 단일 프로그램 테스트

②     시스템 또는 런 단위 테스트(System or run unit tests): 특정 작업 흐름(a job stream)에서 실행되는 일련의 프로그램들 또는 온라인 환경에서 동시에 실행되는 프로그램들을 함께 테스트한다. 상황에 맞게 이전 단계의 단위 테스트 스크립트(Unit test scripts)를 조합하거나 새로운 런 단위 테스트 스크립트(run unit test scripts)를 생성한다. 테스트 데이터가 가용하면 이를 사용하고 그렇지 않으면 실 업무 데이터(production data)를 사용하여 테스트한다.

③     병행 테스트(Parallel test): 업무 데이터(production data)로 구 시스템와 신규 시스템을 동시에 실행시킨다. 양쪽 시스템에서 동일한 작업을 수행하여 그 결과를 비교한다.

④     승인 테스트(Acceptance test): 시스템의 병행 테스트(parallel test)가 만족스럽게 완료되었다는 공식 완료 신호. 병행 테스트에 직접 관여하지 않았던 이해관계자들에게 폭넓은 시연을 통해 승인을 얻는다. 대개 이 시점을 프로젝트 완료 시점으로 간주

⑤     스트레스 테스트(Stress tests): 튜닝을 요구하는 병목현상이 존재하는지 확인하기 위해서 또한 새로운 환경의 최적 수용량(the effective capacity)을 결정하기 위해서 의도적으로 정상적인 트랜잭션양보다 더 높은 양을 시스템에 준다. 마이그레이션 프로젝트에서는 드물게 수행되는 테스트이다.

마이그레이션 테스팅 자동화(Automation of Migration Testing)

일반 개발 프로젝트가 통상적으로 비지니스 업무 규칙의 변화를 동반하는 반면 마이그레이션 프로젝트는 대개 기존 비즈니스 규칙을 유지하고 플랫폼, 언어 컴파일러, 데이터베이스 등에 변경을 가한다. 따라서 마이그레이션 프로젝트는 테스팅 자동화가 더 용이하다(특히 비교 테스팅).

소스 코드 인스트루멘테이션(Source Code Instrumentation)

• 소프트웨어(대개 파서(parser))가 테스트 대상 프로그램의 소스 코드에 새로운 프로그램 로직을 넣는 프로세스로, 추가되는 새로운 로직은 프로그램의 비즈니스 로직(기능)에 변경을 가하지 않으면서 프로그램 자체의 오퍼레이션을 이해하고 분석하는데 도움을 주는 코드이다.
• 소스 코드 인스트루멘테이션의 대표적인 예로 대상 프로그램의 어떤 로직이 실행되고 어떤 것이 미실행인지 확인하는 커버리지 분석이 있다. 또한 인스트루멘테이션을 통해 프로그램내의 성능 분석도 가능(각 문장, 브랜치 경로, 서브루틴의 시간을 측정하여 어느 부분이 과도한 리소스 소모를 유발하는지 식별)
• 자동화된 마이그레이션 테스팅은 먼저 테스트 데이터를 캡쳐하기 위해 여러 형태의 소스 코드 인스트루멘테이션을 활용하고, 이어서 프로그램의 어떤 부분(예, 비즈니스 규칙, I/O, 데이터 커뮤니케이션 등)이 테스트 되는지에 따라 하나 또는 그 이상의 리플레이 시나리오를 적용한다(아래 그림은 이런 테스팅 프로세스를 나타냄).