빌드 프로세스 자동화
자동화된 빌드 프로세스는 미리 결정된 일정한 간격으로 프로젝트에 대한 최신 소스 코드에 대해 BVT(빌드 확인 테스트)를 컴파일, 배포 및 실행합니다. 그런 다음 빌드 프로세스의 성공 또는 실패를 자세히 설명한 "빌드 보고서"가 프로젝트 관련자에게 배포됩니다. 빌드 보고서를 분석하여 프로젝트의 주의가 필요한 영역과 프로젝트를 이전 버전/빌드로 롤백해야 하는지 여부를 확인합니다.
자동화된 빌드 프로세스의 기능은 "작업 시간 을 벗어나는 시간" 동안 실행되도록 예약할 수 있다는 것입니다. 이렇게 하면 개발 시간에서 직접 순환하지 않고 프로젝트의 안정성을 보장하는 데 도움이 될 수 있습니다. 이 항목에서는 빌드 프로세스에 대한 개요를 제공하고, 빌드 확인 테스트가 빌드 프로세스에 적합한 방법을 설명하고, 빌드 확인 테스트 중에 사용되는 기능 테스트의 측면을 설명하고, 빌드 프로세스 자동화의 중요성에 대한 정보를 제공합니다.
빌드 프로세스 개요
테스트의 세부 사항을 살펴보기 전에 테스트가 전체 빌드 프로세스에 어떻게 적합한지 컨텍스트를 고려하는 것이 중요합니다. Microsoft의 모든 제품 그룹은 빌드 프로세스가 모든 소프트웨어 프로젝트의 하트비트라는 철학에서 작동합니다. 이 접근 방식은 Microsoft 소프트웨어 스택 위에 중요 업무용 솔루션을 빌드하는 세계 최고의 컨설팅 회사에서도 사용됩니다. 꾸준한 하트비트와 정기적인 검사 없으면 프로젝트의 상태를 알 수 없습니다. 제품 그룹이 프로젝트의 전반적인 상태에 대한 지속적인 인사이트를 갖도록 하기 위해 빌드 프로세스는 일반적으로 자정에 매일 실행됩니다. 다음 단계에서는 일반적인 자동화된 빌드 프로세스를 요약합니다.
소스 코드 리포지토리에서 소스 코드의 최신 빌드를 가져옵니다.
소스 코드를 컴파일합니다.
일반적으로 스크립트 또는 Microsoft Windows Installer 파일을 사용하여 배포를 위해 이진 파일을 압축합니다.
테스트 서버에 프로젝트를 배포합니다.
전체 빌드 확인 테스트 집합(BVT)을 자동으로 실행합니다.
프로젝트 팀 구성원에게 자세한 빌드 보고서를 게시합니다.
참고
BVT는 솔루션의 기본 기능을 실행하여 품질을 테스트하는 기능 테스트입니다. BVT가 빌드 품질을 측정할 수 있을 만큼 포괄적이면서도 할당된 일일 빌드 시간 내에 실행될 수 있을 만큼 작아야 합니다.
참고
또한 테스트 목적으로 소프트웨어 프로젝트의 일부로 배포, 배포 취소, 구성 및 설치 스크립트 또는 프로세스를 처리해야 합니다. 프로젝트의 작업과 프로젝트의 배포 및 구성을 모두 테스트해야 합니다.
이 프로세스는 일반적으로 오전 6시경 이른 아침까지 완료되며, 이를 통해 팀의 첫 번째 멤버가 새 날 빌드 작업을 시작할 수 있습니다. 전날 밤에 하나 이상의 BVT가 실패한 경우 가능한 한 빨리 수정하는 것은 팀의 책임입니다.
매일 빌드 프로세스를 수행하면 프로젝트에 많은 이점이 있습니다. 먼저 정기적인 하트비트(일일 빌드와 자동화된 BVT로 구성됨)를 제공합니다. 둘째, BVT를 사용하면 까다로운 작업인 시스템과의 통합이 강제되며, 이 작업을 초기에 수행하면 프로젝트 위험이 줄어듭니다. 완료하는 데 필요한 시간으로 인해 스트레스 및 성능 테스트는 일반적으로 일일 빌드 프로세스 외부에서 수행됩니다. 스트레스 및 성능 테스트는 일반적으로 프로젝트의 마일스톤 빌드에서 수행되도록 예약됩니다.
매일 빌드 프로세스는 BizTalk 솔루션에서 매우 효과적으로 사용될 수 있으며 사용되었습니다. 그러나 일반적으로 프로젝트의 끝에 남아 있는 작업이 처음부터 반복적으로 수행되도록 해야 합니다. 예를 들어 BizTalk Server 배포는 확실히 사소하지 않습니다. 자동화된 배포 스크립트를 미리 개발하는 것이 중요합니다. 이렇게 하지 않으면 프로젝트 전체에서 솔루션을 여러 번 수동으로 배포 및 배포 취소하게 되므로 결국 더 많은 시간이 소요됩니다. 일일 빌드 프로세스를 구동하는 데 사용할 수 있는 도구가 있습니다. Visual Studio Team System 및 Team Foundation Server는 많은 사용자가 가장 선호하는 선택입니다. MSBuild 스크립트는 빌드 프로세스의 단계를 구동하는 데 사용할 수 있습니다.
참고
이 도구의 사용은 Microsoft에서 지원되지 않으며 Microsoft는 이 프로그램의 적합성을 보장하지 않습니다. 이 프로그램을 사용하여 발생하는 모든 위험은 사용자가 책임집니다.
Microsoft Test Manager를 사용하여 테스트를 자동화하는 방법에 대한 자세한 내용은 자동화된 테스트 실행을 참조하세요.
빌드 확인 테스트
빌드 확인 테스트는 일반적으로 다음 요소로 구성됩니다.
단위 테스트 - 단위 테스트는 일반적으로 개발해야 하는 첫 번째 테스트이므로 테스트 기반 개발 방법을 실제로 사용하는 경우 코드가 실제로 작성되기 전에 생성해야 합니다. 프로젝트의 초기 단계에서 BVT에 추가하면 최소한 일부 코드 검사를 즉시 제공합니다. 기능 테스트의 수와 그에 따른 테스트 적용 범위가 증가함에 따라 BVT에서 단위 테스트를 제거하도록 선택할 수 있습니다.
스모크 테스트 - 솔루션의 기본 기능을 테스트하는 엔드 투 엔드 기능 테스트입니다. 이러한 오류가 발생하면 심각한 문제가 발생합니다. 일반적으로 비교적 빠르게 실행할 수 있습니다.
기능 테스트 - 엔드 투 엔드 시나리오도 대상으로 하지만 이 경우 프로젝트의 모든 시나리오를 테스트합니다. 대규모 프로젝트의 경우 기능 테스트를 추가로 분류하는 것이 합리적일 수 있습니다(instance 경우 특정 구성 요소를 빠르고 안정적으로 격리하여 테스트할 수 있도록 설정). 이러한 기능 테스트는 솔루션에서 기능적으로 올바른 것으로 로그오프한 후에 잠가야 합니다.
회귀 확인 테스트 - 솔루션 버그가 발견되고 수정될 때마다 회귀 확인 테스트 사례를 추가하여 버그가 수정되었으며 프로젝트 수명 주기의 뒷부분에서 다시 도입되지 않는지 확인해야 합니다. 이러한 테스트는 일반적으로 기능 테스트 사례에서 다루지 않은 경우입니다. 새 버그가 검색되고 수정된 경우 솔루션이 라이브로 전환된 후에도 회귀 확인 테스트의 수가 증가할 것으로 예상해야 합니다.
매우 큰 프로젝트에서는 BVT를 전체 기능 테스트 도구 모음의 하위 집합으로 만들어야 할 수 있습니다(실행하는 데 걸리는 시간 때문에). 소규모 프로젝트의 경우 BVT는 전체 집합을 구성합니다. 물론 매일 빌드의 일부로 BVT를 통합하려는 경우 전체 프로세스를 자동화해야 합니다. 이 항목의 나머지 섹션에서는 BizUnit 및 기타 도구를 사용하여 이 작업을 수행하는 방법을 중점 설명합니다.
기능 테스트
BizTalk 애플리케이션 기능 테스트의 컨텍스트에서 특정 엔드투엔드 시나리오를 테스트합니다. 이러한 유형의 테스트를 수행할 때 BizTalk Server 외부 관점에서 기능적으로 테스트하는 블랙박스로 상상하는 것이 유용합니다. 예를 들어 테스트에는 수신 위치 엔드포인트(예: URL, FTP 위치, 전송 선택 항목에 관계없이)에 입력 메시지(알려진 값 포함)를 공급하는 작업이 포함될 수 있습니다. 그런 다음 테스트는 송신 쪽에서 생성되는 올바른 출력으로 올바른 메시지 수를 모니터링합니다. 이 작업은 비교적 간단하게 들릴 수 있습니다. 그러나 일부 시나리오에서 특정 순서 및 특정 시간에 입력이 필요하고 이를 다른 솔루션 요구 사항(예: BAM에서 추적 데이터를 기록할 때)과 결합해야 하는 경우 도구와 프레임워크를 사용하여 이를 오케스트레이션할 수 있다는 것이 분명해집니다.
기능 테스트는 솔루션을 통해 가능한 모든 경로를 포함하도록 설계되는 것이 중요합니다. 여기에는 프로덕션에서 예상하는 시나리오뿐만 아니라 구현한 오류 경로 및 예외 처리 경로도 포함되어야 하지만 사용하지 않기를 바랍니다. 이를 설명하는 데 일반적으로 사용되는 한 가지 구는 "나쁜 날 시나리오"에 대한 테스트입니다. 모든 오케스트레이션, 모든 허용 가능한 메시지 유형 및 모든 코드 분기가 기능 테스트 도구 모음에서 실행되도록 해야 합니다. 다음 섹션에서는 모든 코드 경로를 다루는 양수 및 부정 기능 테스트 사례를 개발하는 방법을 설명합니다.
BizTalk Server 솔루션을 프로덕션 환경에 배치하기 전에 구현해야 하는 기능 테스트 및 기타 테스트 범주에 대한 자세한 내용은 검사 목록: 운영 준비 테스트를 참조하세요.
양성 테스트
모든 메시지 흐름이 실행되도록 메시지, 파이프라인, 오케스트레이션 및 엔드포인트의 모든 조합이 솔루션을 통해 전달되도록 긍정적인 테스트를 수행할 때 중요합니다. 모든 코드 경로를 테스트하려면 다른 콘텐츠를 사용하여 다른 메시지를 처리해야 할 수 있습니다.
테스트할 때 프로덕션에서 사용할 전송 유형을 사용합니다. 아쉽게도 일부 다른 전송이 프로덕션에서 사용될 때 파일 어댑터를 사용해야만 기능 테스트가 수행됩니다. 이 접근 방식을 채택하면 나중에 사용자와 전체 프로젝트가 실패할 수 있습니다.
시스템에서 보낸 모든 메시지의 페이로드의 유효성을 검사합니다. 메시지가 XML인 경우 XPath 식을 사용하여 메시지의 스키마 및 키 필드의 유효성을 검사해야 합니다.
BAM에 저장된 추적 데이터의 유효성을 검사합니다(사용되는 경우). 외부 데이터 리포지토리에 남아 있는 다른 모든 데이터를 고려해야 합니다.
솔루션에서 BRE를 사용하는 경우 모든 BRE(비즈니스 규칙 엔진) 정책 및 규칙의 실행을 테스트합니다.
부정 테스트
시스템을 통해 잘못된 메시지 처리를 테스트해야 합니다. 선택한 전략(BizTalk Server 시작하기 전에 거부하거나 일시 중단)이 올바르게 작동하는지 확인해야 합니다.
잘못된 메시지 처리를 테스트할 때 일시 중단된 메시지를 처리하기 위해 수신측 오류 처리 오케스트레이션이 구현되었는지 테스트해야 합니다.
오류 시나리오가 오케스트레이션의 모든 예외 블록을 포함하는지 확인합니다. 이를 적절하게 테스트하지 못하는 것은 일반적인 문제입니다.
보정 동작과 함께 장기 실행 트랜잭션을 사용하는 경우 이러한 시나리오를 매우 신중하게 테스트합니다. 이는 부적절한 테스트가 프로덕션 환경에서 심각한 결과를 초래하는 또 다른 영역입니다.
오류가 적절한 오류 로그에 올바르게 기록되었는지 확인합니다.
자동화가 핵심입니다.
이 모든 작업을 효율적이고 효과적으로 수행하려면 미리 시간을 투자하여 테스트를 자동화합니다. 수동 테스트는 시간이 많이 걸리고 오류가 발생하기 쉬며 비용이 많이 듭니다(시간과 비용 측면에서). 수동 테스트 통과를 수행할 때마다 프로젝트 리소스(팀의 사용자)에서 처리해야 하는 다른 작업 일괄 처리를 추가합니다. 이를 미리 자동화하면 테스트를 실행할 때마다 개발하는 데 필요한 초기 투자 수익을 얻을 수 있습니다. 좋은 기능 테스트는 빠르고 효율적으로 실행되고 반복 가능해야 합니다. 각 테스트도 자율적이어야 합니다(다른 테스트와 독립적이어야 합니다. 이 방법을 채택하면 여러 테스트를 테스트 도구 모음으로 순차적으로 실행할 수 있습니다.) 기능 테스트는 항상 동일한 결과를 생성해야 합니다. 제대로 작성되지 않은 기능 테스트 또는 잘못 작성된 코드는 테스트 실행 간에 다른 테스트 결과를 초래하여 실패의 근본 원인을 조사하는 데 혼동과 시간을 낭비하게 됩니다.
각 기능 테스트를 작성하는 데 필요한 개발 노력을 최소화하는 것이 중요합니다. 일반적으로 개발 시간 측면에서 무언가를 생산하는 것이 더 비쌀수록 결국 테스트 사례가 줄어듭니다. 즉, 코드에 대한 테스트 검사 수준이 낮습니다. 테스트 프레임워크를 사용하면 테스트 사례를 더 빠르고 쉽게 개발할 수 있으므로 전체 코드 검사를 더 쉽게 얻을 수 있습니다. 대부분의 좋은 테스트 프레임워크는 선언적 접근 방식을 사용하여 테스트를 정의합니다. 즉, 테스트 구성은 일반적으로 XML 파일인 구성 파일에 저장됩니다. 좋은 테스트 프레임워크를 사용하면 민첩하고 신뢰할 수 있는 방식으로 전체 기능 테스트 제품군을 개발할 수 있으며 말하기 위해 "휠을 재창조"할 필요가 없습니다.
BizTalk Server 프로젝트에 대한 MSBUILD 지원
BizTalk Server Visual Studio가 설치되지 않은 빌드 랩 환경에서 관리되는 프로젝트 빌드를 수용하는 MSBUILD(Microsoft Build Engine) 플랫폼을 지원합니다. MSBUILD는 명령줄의 빌드 프로젝트와 MSBUILD 로깅 및 일괄 처리를 비롯한 고급 기능을 수용합니다. MSBUILD에 대한 자세한 내용은 MSBuild 개요를 참조하세요.