你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
测试驱动开发（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 策略即可强制执行测试标准，以避免因代码更改导致测试在将来版本中失败。
在 TDD 方法中设计和查看 Azure Policy 作为代码工作流 。
Azure Resource Graph 提供了一种查询语言，用于基于有关在登陆区域中部署的资产的信息创建数据驱动测试。 稍后在采用计划中，此工具还可以根据工作负荷资产与基础云环境之间的交互来定义复杂的测试。
Resource Graph 包括高级 查询示例，您可以使用这些示例来了解如何在登陆区域中为高级测试场景部署工作负载。
根据首选方法，还可以使用以下工具：
- 使用 Terraform 部署登陆区域。
- 使用 Bicep 部署落地专区。
- 使用 AzOps 管理登陆区域，这是一个 PowerShell 模块，用于在所有 Azure 范围级别推送资源模板和 Bicep 文件，并拉取和导出 Azure 资源层次结构。