自动化构建过程会编译、部署，然后针对项目的最新源代码运行构建验证测试（BVT），并在固定的预定时间间隔内执行。 然后，向项目利益干系人传播“生成报告”，详细说明生成过程的成功或失败。 分析构建报告以确定项目中哪些部分需要注意，以及项目是否应回滚到早期版本/构建版本。
自动化生成过程的强大功能是，它可以计划在“休息时间”内运行。 这样，它可以帮助确保项目的稳定性，而无需直接从开发时间中获取周期。 本主题概述了生成过程，介绍了生成验证测试如何适应生成过程，介绍了在生成验证测试期间使用的功能测试的各个方面，并提供有关自动执行生成过程的重要性的信息。
生成过程概述
在了解测试的具体内容之前，重要的是要考虑测试如何融入整个构建过程的上下文。 所有微软的产品组都基于这样的理念，即构建过程是任何软件项目的核心。 世界上许多顶级咨询公司也使用这种方法，这些咨询公司在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测试管理器自动测试的详细信息，请转到 “运行自动测试”。
生成验证测试
构建验证测试通常包含以下元素：
单元测试 - 由于单元测试通常是要开发的第一个测试，理想情况下，应在实际编写代码之前创建它们，如果你确实使用测试驱动开发方法。 通过在项目的早期阶段将它们添加到 BVT 中，可以立即提供至少一些代码覆盖率。 随着功能测试的数量增加，因此测试覆盖率增加，可以选择从 BVT 中删除单元测试。
冒烟测试 - 端到端功能测试，用于测试解决方案的基本功能。 如果这些失败，则存在严重错误。 这些通常可以相对较快地运行。
功能测试 - 这些测试还面向端到端方案，但在这种情况下，它们会测试项目中的所有方案。 对于大型项目，进一步对功能测试进行分类可能有意义（例如，使特定组件能够快速、可靠和隔离地进行测试）。 签署确认解决方案功能正确后，应锁定这些功能测试。
回归验证测试 - 每次找到并修复解决方案 bug 时，都应添加回归验证测试用例，以验证该 bug 是否已修复，并且该项目生命周期稍后不会重新引入。 这些测试通常是功能测试用例中未涵盖的情况。 您应该预期，即使解决方案已上线，回归验证测试的数量也会增加，如果发现并修复了新的 bug。
在非常大的项目中，可能需要将 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 为Microsoft生成引擎（MSBUILD）平台提供支持，该平台适用于在未安装 Visual Studio 的生成实验室环境中生成托管项目。 MSBUILD 可以通过命令行构建项目，并支持包括 MSBUILD 日志记录和批处理在内的高级功能。 有关 MSBUILD 的详细信息，请参阅 MSBuild 概述。