你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 登陆区域的测试驱动开发
测试驱动开发 (TDD) 是一种软件开发和 DevOps 过程，可提高基于代码的解决方案的新功能的质量及改进效果。 TDD 在开发实际代码之前创建单元测试用例，并根据测试用例测试代码。 此方法与先开发代码，然后再创建测试用例相反。
登陆区域是一个环境，用于托管通过代码提前预配的工作负载。 登陆区域包括使用一组定义的云服务和最佳做法的基础功能。 本文介绍的方法使用 TDD 来部署成功的登陆区域，同时满足质量、安全、运营和治理要求。
云基础结构是代码执行的输出。 结构良好、经过测试和验证的代码将生成可运行的登陆区域。 基于云的基础结构及其基础源代码可以使用此方法来确保登陆区域的高质量并满足核心要求。
使用这种方法可以在早期开发过程中满足简单的功能要求。 在云采用生命周期的后期，可以使用此过程来满足安全、运营、治理或合规性要求。 该过程对于在并行开发工作中开发和重构登陆区域特别有用。
测试驱动开发周期
下图显示了 Azure 登陆区域的测试驱动开发周期：
创建测试。 定义测试以验证是否满足功能的验收条件。 在开发时自动执行测试，以减少手动测试工作量，尤其是对于企业级部署。
测试登陆区域。 运行新测试和任何现有测试。 如果所需功能未包含在云提供商的产品/服务中，并且之前的开发工作未提供该功能，则测试应会失败。 运行现有测试有助于验证新功能，或测试不会降低现有登陆区域功能的可靠性。
扩展和重构登陆区域。 添加或修改源代码以实现所请求的增值功能并提高代码库的总体质量。
为了满足 TDD 标准，云平台团队仅添加代码来满足请求的功能。 但是，代码质量和维护是共同的努力。 在满足新功能请求时，云平台团队应尝试通过消除重复并明确代码来改进代码。 强烈建议在新代码创建和源代码重构之间运行测试。
部署登陆区域。 源代码满足功能请求后，将修改后的登陆区域部署到受控测试或沙盒环境中的云提供商。
测试登陆区域。 重新测试登陆区域以验证新的代码是否符合所请求功能的验收条件。 通过所有测试后，则认定该功能完成且符合验收条件。
TDD 周期重复前面的基本步骤，直到它们满足完整的“完成的定义”。 若所有增值功能和验收条件都通过了相关测试，则登陆区域已能够支持下一波云采用计划。
使 TDD 生效的周期通常称为红/绿测试。 在这种方法中，云平台团队会先基于完成的定义和定义的验收条件进行测试（或红色测试），且测试会失败。 对于每个功能或验收条件，云平台团队将完成开发任务，直到测试通过或具有绿色测试。
TDD 的目标是实现更好的设计，而不是创建一套测试。 测试是完成该过程的有用项目。
完成的定义
成功可以是一种主观衡量标准，它在登陆区域开发或重构期间为云平台团队提供很少的可操作信息。 缺乏明确性可能导致云环境中缺少期望和存在缺陷。 在云平台团队重构或扩展任何登陆区域之前，他们应为每个登陆区域明确定义“完成”(DoD)。
DoD 是云平台团队和其他受影响团队之间的简单协议，用于定义登陆区域开发工作中包含的预期增值功能。 DoD 通常是与短期云采用计划相一致的清单内容。
随着团队采用更多的工作负载和云功能，DoD 和验收条件将变得更复杂。 在成熟的流程中，每个预期功能都有自己的验收条件，以提供更清晰的信息。 当所有增值功能都满足验收条件时，登陆区域的配置就足以成功完成当前波次或发布的采用。
简单 DoD 示例
对于初始迁移工作，DoD 可能过于简单。 以下示例是一个简单的 DoD：
初始登陆区域将托管 10 个工作负载，用于初始学习目的。 这些工作负载对业务并不关键，也无法访问敏感数据。 将来，这些工作负载可能会发布到生产环境中，但其重要性和敏感性预期不会改变。
为支持这些工作负载，云采用团队需要满足以下条件：
- 进行网络分段，与提议的网络设计保持一致。 此环境应是可访问公共 Internet 的外围网络。
- 能够访问计算、存储和网络资源以托管与数字资产发现一致的工作负载。
- 命名和标记架构，以方便使用。
- 在采用期间，云采用团队可以临时进行访问以更改服务配置。
- 在生产发布之前，与企业标识提供者集成以治理持续的标识和访问，从而进行运营管理。 届时云采用团队的访问权限应被撤销。
最后一点不是功能或验收条件，而是需要更多扩展并且应该尽早与其他团队一起探索的指标。
较复杂的 DoD 示例
云采用框架中的治理方法提供了一个随治理团队的自然成熟而完成的叙述性的过程。 该旅程中以策略语句的形式加入了几个 DoD 和验收条件的示例。
初始策略语句。 基于治理早期采用要求的企业策略的初始 DoD 示例。
用于扩展标识管理的增量改进。 用于治理 DoD 以满足扩展登陆区域标识管理要求的企业策略示例。
用于扩展安全要求的增量改进。 用于治理 DoD 以满足与参考云采用计划一致的安全要求的企业策略示例。
用于扩展运营管理的增量改进。 用于治理 DoD 以满足基本运营管理要求的企业策略示例。
用于扩展成本管理的增量改进。 用于治理 DoD 以满足成本管理要求的企业策略示例。
以上示例是帮助你为登陆区域开发 DoD 的基本示例。 你可以获取云治理的五项准则中每项准则的示例策略。
支持登陆区域 TDD 的 Azure 工具和功能
下图显示了 Azure 中可用的测试驱动开发工具：
可以轻松将这些 Azure 工具和功能集成到 TDD 中以创建登陆区域。 这些工具有特定的用途，可以更轻松地根据 TDD 周期开发、测试和部署登陆区域。
Azure 资源管理器为生成和部署过程提供一致的平台。 资源管理器平台可以根据源代码定义部署登陆区域。
Azure 资源管理器 (ARM) 模板为部署在 Azure 中的环境提供主要源代码。 某些第三方工具（例如 Terraform）提供自己的 ARM 模板以提交到 Azure 资源管理器。
Azure 快速入门模板提供了源代码模板，有助于加速登陆区域和工作负载部署。
Azure Policy 提供用于测试 DoD 中的验收条件的主要机制。 Azure Policy 还可以在部署偏离治理策略时提供自动检测、保护和解决方案。
在 TDD 周期中，可以创建策略定义来测试单个验收条件。 Azure Policy 包含内置策略定义，可以满足 DoD 中的各个验收条件。 此方法提供了一种在修改登陆区域前进行红色测试的机制。
Azure Policy 还包含内置策略计划，你可以使用这些计划来为登陆区域测试和强制实施完整的 DoD。 可将所有验收条件添加到分配给整个订阅的策略计划。 登陆区域满足 DoD 后，Azure Policy 可以强制实施测试条件，以避免代码更改导致将来版本中的测试失败。
设计 Azure Policy 即代码工作流作为 TDD 方法的一部分并对其进行评审。
Azure 蓝图将策略和其他部署工具分组到可重复的包中，该包可分配给多个登陆区域。 蓝图对于共享通用 DoD 的多项采用工作很有用，建议不断对其进行更新。 Azure 蓝图还可以在后续扩展和重构登陆区域的工作中帮助进行部署。
Azure 蓝图提供各种蓝图示例，包括用于测试的策略和用于部署的模板。 这些蓝图示例可以加速 TDD 周期中的开发、部署和测试工作。
Azure Resource Graph 提供一种查询语言，用于根据登陆区域中部署的资产的相关信息创建数据驱动的测试。 在采用计划的后期，此工具还可以根据工作负载资产和基础云环境之间的交互来定义复杂的测试。
Resource Graph 包含高级查询示例，可用于了解如何在登陆区域内部署工作负载以实现高级测试方案。
根据首选方法，还可使用以下工具：
- 使用 Terraform 部署登陆区域。
- 使用 Bicep 部署登陆区域。
- 使用 AzOps 管理登陆区域。AzOps 是一个 PowerShell 模块，可在所有 Azure 范围级别推送资源模板和 Bicep 文件，以及拉取和导出 Azure 资源层次结构。