自动执行生成过程
自动生成过程会定期、预先确定的时间间隔编译、部署和运行生成验证测试， (BVT) 项目的最新源代码。 然后，向项目利益干系人分发“生成报告”，其中详细说明了生成过程的成功或失败。 分析生成报告以确定项目哪些方面需要注意，以及是否应将项目回滚到早期版本/内部版本。
自动生成过程的强大功能在于，它可以计划为在“非工作时间”运行。 这样，它可以帮助确保项目的稳定性，而不会使周期直接从开发时间中消失。 本主题概述生成过程，描述生成验证测试如何适应生成过程，描述在生成验证测试期间使用的功能测试的各个方面，并提供有关自动化生成过程的重要性的信息。
生成过程概述
在研究测试的具体细节之前，请务必考虑测试如何适应整个生成过程的上下文。 Microsoft 的所有产品组都以生成过程是任何软件项目的检测信号为理念运作。 许多世界顶级咨询公司也使用此方法，这些咨询公司在 Microsoft 软件堆栈之上构建任务关键型解决方案。 如果没有稳定的检测信号和定期检查，就不可能知道项目的运行状况。 为了确保产品组持续了解项目的整体运行状况，生成过程每天运行，通常在午夜运行。 以下步骤总结了典型的自动生成过程：
从源代码存储库获取最新版本的源代码。
编译源代码。
打包二进制文件进行部署 - 通常使用脚本或 Microsoft Windows Installer 文件。
将项目部署到测试服务器。
(BVT) 自动运行一组完整的生成验证测试。
向项目团队成员发布详细的生成报告。
注意
BVT 是功能测试，用于执行解决方案main功能以测试其质量。 你需要确保 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 文件。) 使用良好的测试框架可以灵活可靠地开发完整的功能测试套件，并避免一遍又一遍地“重塑方向盘”。
MSBUILD 支持BizTalk Server项目
BizTalk Server支持Microsoft 生成引擎 (MSBUILD) 平台，该平台可在未安装 Visual Studio 的生成实验室环境中生成托管项目。 MSBUILD 适用于通过命令行和高级功能（包括 MSBUILD 日志记录和批处理）生成项目。 有关 MSBUILD 的详细信息，请参阅 MSBuild 概述。