테스트가 중요한 이유는?
이 항목에서는 테스트 부족으로 이어지는 사고방식에 대한 개요를 제공하고, BizTalk 솔루션 테스트 실패와 관련된 위험을 설명하고, 수동 테스트의 문제를 자동화된 테스트의 이점과 대조합니다.
"오버헤드"로 테스트
안타깝게도 ROI(투자 수익률)에 대한 요구가 계속 증가함에 따라 프로젝트의 테스트 단계는 종종 축소할 수 있는 프로젝트 계획의 첫 번째 측면 중 하나로 간주됩니다.
BizTalk 솔루션 테스트에 대한 한 가지 논쟁은 "Microsoft가 이미 BizTalk Server 철저히 테스트하기 때문에 솔루션을 테스트할 필요가 없습니다."라는 것입니다. Microsoft가 BizTalk Server 철저히 테스트하는 것은 사실이지만, 다양한 사용 시나리오에서는 처리량, 고가용성, 어댑터 사용량, 대기 시간, 추적 요구 사항, 오케스트레이션 사용량 및 사용자 지정 코드에 대한 비즈니스 요구 사항의 거의 수많은 순열 중 하나가 필요합니다. BizTalk Server 매우 유연하고 다양한 사용 시나리오를 수용할 수 있으므로 모든 시나리오를 예측하고 테스트하는 것은 불가능합니다. 또한 각 사용 시나리오를 수용하도록 BizTalk Server 환경에 적용되는 기본 설정을 최적화해야 합니다. 특정 사용 시나리오에 대한 최적의 설정을 결정하는 유일한 방법은 솔루션을 테스트하고, 다양한 매개 변수를 측정하고, 환경을 조정하고, 다시 테스트하는 것입니다. BizTalk Server 솔루션에 대한 샘플 물리적 아키텍처를 보여 주는 다음 다이어그램을 고려합니다.
샘플 물리적 BizTalk 아키텍처
위의 다이어그램에서 BizTalk Server 솔루션에는 BizTalk Server 실행하는 여러 컴퓨터, SQL Server 실행 중인 컴퓨터, 서버 클러스터 노드 및 Active Directory 도메인을 비롯한 많은 이동 부분이 포함되어 있음을 알 수 있습니다. 시스템이 가동되고 실행되면 솔루션의 전체 ROI를 최대화하기 위해 비즈니스 요구 사항에 따라 애플리케이션을 최적화하기 위해 많은 구성 조정이 적용됩니다. 이 단일 시나리오는 많은 변수가 재생 중임을 보여 줍니다. 환경의 물리적 아키텍처 외에도 BizTalk Server 통해 메시지의 흐름을 보여 주는 다음 다이어그램을 고려합니다.
샘플 논리 BizTalk 메시지 흐름을 통한 메시지 흐름
BizTalk Server 통해 흐르는 메시지의 논리적 다이어그램을 살펴보면 사용자 지정 송신 및 수신 파이프라인 구성 요소와 BizTalk 오케스트레이션에서 호출할 수 있는 사용자 지정 클래스를 포함하여 프로젝트별 테스트가 필요한 다른 변수가 표시됩니다. 사용자 지정 구성 요소 및 BizTalk 구성 요소의 형식 복잡성과 사용은 프로젝트마다 다르기 때문에 각 특정 사용 시나리오에 대해 테스트를 수행하는 것이 중요한 이유가 더 분명해집니다.
방법론 및 타임라인 테스트
테스트가 효과적이고 효율적으로 수행되도록 하려면 테스트 하네스를 완전히 자동화하여 쉽게 재현할 수 있고 사람의 오류가 발생할 가능성을 최소화해야 합니다. 또한 프로젝트를 계획할 때 테스트에 적절한 시간을 할당해야 합니다. 테스트에 대한 최소한의 접근 방식은 다음과 유사한 수동 단계로 구성됩니다.
파일 삭제와 같은 수신 엔드포인트에 하나 이상의 메시지를 수동으로 로드하거나 SOAP 클라이언트를 사용하여 웹 서비스를 호출합니다.
메시지의 올바른 콘텐츠 및 구조의 유효성을 수동으로 검사합니다. 여러 스키마가 프로젝트에 있는 경우가 많기 때문에 메시지는 플랫 파일과 XML이 혼합되어 있을 수 있으며 필드 간 종속성도 포함할 수 있습니다.
참고
이 예제는 SWIFT 메시지와 관련된 모든 프로젝트입니다. 교차 필드 종속성이 있는 플랫 파일 메시지입니다. 즉, 한 필드의 값은 다른 필드에 따라 달라집니다. 간단한 XSD 유효성 검사는 여기서 수행되지 않습니다. 따라서 SWIFT 가속기는 메시지 유효성 검사를 위해 BizTalk 규칙 엔진을 사용합니다. SWIFT Accelerator에 대한 자세한 내용을 참조하세요.
오류에 대해 BizTalk Server 컴퓨터에서 이벤트 로그를 수동으로 검사.
BAM 데이터베이스를 수동으로 검사(사용된 경우) 활동 정보가 올바르게 기록되었는지 확인합니다.
위에서 설명한 수동 프로세스를 테스트에 사용하는 것은 주관적이며 오류가 발생하기 쉽습니다. 10개의 다른 테스트 사례에 대해 교차 필드 종속성이 있는 100줄 SWIFT 메시지를 검사해야 합니다. 대부분의 프로젝트 개발자는 이러한 작업을 안정적이고 정확하게 수행할 수 없거나 가능하더라도 이러한 작업에 참여하는 경향이 없습니다. 주관적이고 수동적이고 오류가 발생하기 쉬운 테스트 프로세스를 구현하면 프로젝트에 위험이 추가되고 실패 가능성이 높아질 수 있습니다.
테스트에 충분한 시간을 통합하지 않는 프로젝트 계획 타임라인으로 인해 실패 위험이 증폭되는 경우가 많습니다. 프로젝트 테스트 전략은 라이브 전환 날짜 1주일 정도 전에 예약된 단일 수동 테스트 통과에 달려 있는 경우가 많습니다. 이러한 제한된 테스트는 프로젝트를 위험에 빠뜨릴 수 있습니다. 테스트를 위한 제한된 타임라인 감안할 때 문제가 발견되면 문제를 해결하기 위해 시간이 할당되지 않아 프로젝트가 지연될 수 있습니다. 또한 문제가 발견되고 해결되면 시스템이 라이브 상태가 되기 전에 후속 테스트 통과를 수행할 시간이 부족할 수 있습니다.
"단일 최종 빌드, 단일 테스트 통과, 프로젝트를 라이브로 전환" 테스트의 현실은 프로젝트가 지연되거나, 프로젝트가 예산을 초과하거나, 더 나쁜 경우 프로젝트가 완전히 실패하는 경우가 많다는 것입니다. 중요 업무용 시스템의 경우 이러한 종류의 테스트 방법론은 재해가 발생하기를 기다리는 것입니다.
효과적이고 효율적으로 테스트
적절한 테스트는 종종 필수 요구 사항이 아닌 고가의 사치품으로 간주되기 때문에 프로젝트의 꼬리 끝에서 너무 자주 압정됩니다. 다른 유형의 엔터프라이즈 환경에서 사용되는 소프트웨어 및 하드웨어 스택의 복잡성을 감안할 때 이 접근 방식은 비현실적입니다. 주문형으로 다시 실행할 수 있는 자동화된 테스트 접근 방식을 구현하는 것이 효과적이고 효율적으로 테스트하는 가장 좋은 방법이며 궁극적으로 비즈니스에 우수한 ROI를 제공하는 성공적인 프로젝트의 필수 구성 요소입니다. 프로젝트를 시작할 때 시스템을 통해 각 코드 경로에 대한 전체 엔드투엔드 기능 테스트에 투자하여 테스트 자산을 생성합니다. 이러한 자산은 나중에 테스트 효율성과 효율성을 높이기 위해 투자(즉, 개발 시간)가 필요합니다. 이러한 프레임워크를 파생하기 위해 프로젝트에서 필요한 투자를 최소화하려면 Visual Studio 2010 부하 테스트 프레임워크를 활용하는 것이 좋습니다. Visual Studio 2010에는 성공적인 테스트에 필요한 대부분의 일반적인 테스트 단계가 포함되어 있으며 이 가이드의 뒷부분에 나온 테스트 시나리오에서 사용되는 프레임워크입니다.