Microsoft AZ-400: 测试策略与质量工程 — 学习指南

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

属于 Microsoft DevOps Engineer Expert AZ-400 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure DevOps 中的测试策略与质量工程旨在通过在整个交付生命周期中提供快速、确定性的反馈来建立对软件的信心，同时利用平台原生功能来实施质量门禁和可追溯性。高效的策略结合了均衡的测试金字塔、早期和持续的验证 (TDD/BDD)、管道中稳健的自动化、规范的测试数据管理，以及负载测试、混沌工程、可访问性检查和覆盖率强制部署等高级技术。Azure Test Plans、Azure Pipelines、Azure Load Testing 和 Azure Chaos Studio 为您提供了大规模实施这些实践的工具。

测试策略基础

一个务实的测试金字塔通过在底层进行快速、低成本的测试，并在顶层进行少量高保真度的测试来降低风险：

单元测试验证隔离的逻辑，并应在测试套件中占主导地位。目标是快速执行和高确定性。对于大多数产品，为关键服务设定 70-90% 范围的单元测试覆盖率目标，同时要认识到覆盖率只是一个代理指标，并不能保证质量。
集成测试使用真实的边界和临时的依赖项来验证组件间的契约（例如，数据库、消息传递、外部服务）。尽可能在容器化或沙盒化的环境中并行运行它们，并以通过集成级别场景执行的 30-60% 的关键代码路径为目标。
端到端 (E2E) 测试验证跨越整个技术栈的用户旅程。应保持其数量最少，并专注于最高价值的路径（通常占测试套件的 5-15%），以避免脆弱、缓慢的反馈。

测试左移实践可以更早地减少缺陷：

测试驱动开发 (TDD) 强制执行红-绿-重构循环，为设计提供信息，并增强单元级别的信心。通过为工程师提供快速的本地测试运行器，并保持测试的封闭性和确定性，使 TDD 变得切实可行。
行为驱动开发 (BDD) 使用 Gherkin 以共享词汇捕获意图。.NET 团队可以使用 SpecFlow；Java 和 JavaScript 团队通常使用 Cucumber。将 BDD 场景与 Azure Boards 的验收标准关联起来，并将其结果发布到 Azure Test Plans 以实现可追溯性。

测试数据管理消除不确定性：

合成数据为单元测试和集成测试提供确定性的、保护隐私的数据集。使用特定语言的 faker 库和种子值生成，以实现可复现性。
数据脱敏可以在不暴露个人或敏感信息的情况下创建真实的测试数据集。使用数据库脱敏工具或应用不可逆转换的数据管道。对于 Azure SQL Database，可将快照导出到过渡订阅，并在测试使用前应用脱敏。
环境对等可确保测试结果有意义。使用基础设施即代码 (ARM/Bicep/Terraform) 来配置测试环境，使系统组件、配置和网络拓扑尽可能与生产环境匹配。保持各环境间的模式迁移同步。

不稳定测试的检测和管理可保护反馈循环：

原因包括时序竞争、外部依赖、测试顺序耦合和资源争用。使用 Azure Pipelines 的 Visual Studio Test 任务并启用 rerunFailedTests，以便在调查期间减少瞬时干扰。
隔离不确定性的测试以保持管道常绿，将其标记并隔离到一个单独的套件中，该套件会运行和报告，但不会导致构建失败。使用 Azure Boards 工作项来跟踪隔离的测试债务。
根本原因分析需要埋点检测。在运行期间捕获日志、计时指标和环境详细信息；使用相同的种子和依赖项在本地复现问题；消除对未模拟的系统时钟、网络和文件系统的依赖；并从源头上修复不确定性。

Azure DevOps 与 Azure 测试能力

Azure Test Plans 提供一流的手动和探索性测试，并具备可追溯性：

测试用例定义了步骤、预期结果和参数；共享步骤和参数化测试用例可减少重复工作。基于需求的套件将用例与产品待办事项或用户故事对齐，而静态套件和基于查询的套件则将测试分组以便执行。
测试运行将套件和配置分配给测试人员，记录结果和持续时间，并捕获诊断信息。丰富的 Bug 归档功能包括屏幕截图、视频、环境数据和操作日志。
探索性测试使用 Test & Feedback 浏览器扩展，在临时的探索过程中捕获章程、会话笔记和工件。可将发现的问题链接到工作项，并分析需求和测试会话的覆盖情况。

自动化测试直接集成到管道中：

使用 Visual Studio Test 任务 (VsTest) 运行 MSTest、NUnit 和 xUnit 测试并发布 TRX 结果。对于 .NET，通常使用带有相应日志记录器（trx、junit）的 dotnet test 命令。
对于 Java，通过 Maven 或 Gradle 运行 JUnit，并使用 Publish Test Results 任务发布 JUnit XML。对于 JavaScript，配置运行器（Jest、Mocha）以生成 JUnit XML。
Publish Test Results 任务会整合多次运行的结果和趋势。标准化结果格式（TRX 或 JUnit XML）可以统一报告并支持不问题测试分析。
通过将测试用例映射到自动化测试方法，将自动化测试运行与 Azure Test Plans 关联起来，确保从需求到执行再到缺陷的端到端可追溯性。

代码覆盖率是一个可衡量的质量护栏：

使用 Coverlet（用于 .NET）、JaCoCo（用于 Java）或 Cobertura/lcov（用于 JavaScript）收集覆盖率数据。将其转换为 Azure DevOps 可理解的格式，并通过 Publish Code Coverage Results 任务发布，以揭示趋势和差异。
在构建时强制执行最低阈值。对于 .NET，使用 Coverlet 的阈值开关，在行覆盖率或分支覆盖率低于策略时使构建失败。或者，使用 Build Quality Checks 扩展来强制执行覆盖率和基于趋势的策略。
基于覆盖率的门控部署可在质量下降时阻止流程继续。在 YAML 中，如果覆盖率低于目标，则使质量阶段失败；对于经典发布，使用门控调用 Azure Function 或 REST 检查，在提升（promotion）前验证测得的覆盖率。

性能、混沌与弹性

负载和性能测试可以尽早并持续地验证非功能性需求：

Azure Load Testing 可大规模编排基于 JMeter 的负载，同时关联来自 Application Insights 的后端遥测数据。可以导入 JMX 测试计划，设置通过/失败标准（例如，p95 延迟、错误率），并将结果呈现到管道中。当未达到基线时，使用 Azure Monitor 门控或环境检查来阻止流程继续。
对于协议级负载测试，Apache JMeter 仍然是一个多功能的选择。保持线程组和断言参数化以便于 CI。将 JMX 和 CSV 数据集与代码一起存储，并与场景一起进行版本控制。
k6 实现了对开发者友好的“代码即负载测试”。通过容器或 Node 运行时在 Azure Pipelines 中运行 k6，捕获结果，并导出为 JUnit 或 JSON 格式进行发布。在 k6 脚本中使用阈值表达式来确定性地使运行失败。
基线管理至关重要。跟踪每个环境的延迟、吞吐量和资源利用率趋势。建立 SLO，并确保测试在具有代表性的数据量和配置下运行。

混沌工程验证系统在故障下的弹性：

Azure Chaos Studio 通过受控的爆炸半径和安全措施，向 Azure 资源注入故障。实验类型包括对 VM 施加 CPU/内存压力、网络延迟/黑洞、进程终止和服务节流。
首先在预生产环境中运行实验，并使用 Application Insights 和 Azure Monitor 进行检测，以捕获故障模式、错误预算和自动恢复行为。
弹性验证将混沌工程与健康探针和综合事务相结合，以确保用户关键路径保持可用或实现优雅降级。只有当弹性假设得到证实且警报按设计运行时，才可将变更提升到下一阶段。

可访问性、合规性与治理

可访问性和合规性是质量的基础：

对于面向公众的体验，至少要符合 WCAG 2.1 AA 标准。在 Azure Boards 和 Azure Test Plans 中，将需求转化为验收标准，并配备专门的可访问性测试用例。
通过将 axe-core 集成到 Playwright、Cypress 或 Selenium 等 UI 测试框架中来自动化检查。当检测到严重违规时，使构建失败，并将可访问性报告作为流水线工件发布。
通过手动审计（键盘导航、屏幕阅读器支持、动态环境中的颜色对比度）来补充自动化，并使用 Test & Feedback 扩展在探索性会话中捕获发现。
Azure Pipelines 中的合规性和质量治理使用环境检查和门禁。对于性能和可用性，在部署前查询 Azure Monitor 或 Azure Load Testing 以获取基线。对于覆盖率或可访问性门禁，调用一个函数或 REST 检查，该检查会解析已发布的报告并返回通过/失败。这将非功能性质量强制作为发布的先决条件，而不是事后弥补。

测试结果的发布和分析形成闭环：

标准化结果格式和覆盖率报告，以填充测试分析（Test Analytics）、追踪通过率趋势并自动发现不稳定测试。
使用构建策略和分支保护，要求在合并前必须通过测试并达到足够的覆盖率。保持快速反馈；并行化测试阶段、分片大型测试套件并缓存依赖项以减少周期时间。

实际问题场景

Adobe 正在将其文档处理平台现代化，改造为 Azure 上的微服务。工程领导层要求在没有回归、具备可验证的性能基线、对区域网络故障具有弹性以及符合 WCAG 2.1 AA 标准的前提下，加快发布节奏。当前的流水线受到不稳定的 E2E 测试和不一致的测试数据的困扰。

建立测试金字塔并推行左移实践

对核心库和服务采用 TDD，以创建大量、确定性的单元测试基础，其中 .NET 组件使用 NUnit 和 xUnit，Java 组件使用 JUnit。通过 SpecFlow 和 Cucumber 进行 BDD，将跨团队的验收标准捕获为可执行规范。这确保了快速反馈和共同的理解。

在 Azure Pipelines 中自动化测试并发布结果

使用 VsTest 运行 .NET 测试，使用 Maven/Gradle 运行 Java 测试，以执行单元和集成测试。使用 Publish Test Results 发布测试结果，使用 Publish Code Coverage Results 发布代码覆盖率，以集中报告并启用不稳定测试分析。内置任务提供了与 Azure DevOps 的紧密集成，减少了自定义工具。

强制执行代码覆盖率阈值并设置部署门禁

配置 Coverlet 和 JaCoCo 阈值，如果关键服务的行覆盖率低于 80% 和分支覆盖率低于 60%，则构建失败。添加一个发布检查，该检查调用一个 Azure Function 来读取最新的覆盖率工件并返回通过/失败，从而在覆盖率低于策略时阻止部署。这在无需人工干预的情况下正式化了质量门。

为保证确定性而实施测试数据管理

使用 faker 库为单元和集成测试生成合成数据集。对于系统测试，通过一个使用 Data Factory 的自动化流水线克隆 Azure SQL 数据库的脱敏副本，以应用不可逆脱敏。使用 Bicep 部署环境以确保一致性。这消除了隐私风险和与数据相关的不稳定性。

控制并消除不稳定测试

在 VsTest 中启用 rerunFailedTests 以缓解瞬时故障，并用一个隔离标记来标记不稳定的规范，该标记会将它们从阻塞性测试套件中排除，但仍会运行和报告。为每个被隔离的测试创建 Azure Boards 工作项。通过收集计时和网络日志并移除不确定性等待来进行根本原因分析。这在推动永久性修复的同时，保持了流水线的可靠性。

使用 Azure Load Testing 和 k6 验证性能

将关键用户旅程建模为 JMeter 计划，并在部署到预演（staging）环境后在 Azure Load Testing 中运行它们，通过/失败标准基于 p95 延迟和错误率。对于 API 级别的开发者测试，在 CI 中使用内置阈值运行 k6 脚本。添加一个 Azure Monitor 门禁，如果预演环境的基线未达到，则阻止向生产环境部署。这些工具提供了与问答环节中门禁概念一致的可扩展、可衡量的性能强制执行。

使用 Azure Chaos Studio 证明弹性

设计实验，在预演环境中对选定的微服务注入网络延迟和 CPU 压力，同时由 Application Insights 跟踪错误预算和恢复情况。要求所有弹性实验在提升到生产环境前都必须满足 SLO。Chaos Studio 的治理控制与 Adobe 对受控爆炸半径和可审计实验的需求相一致。

确保可访问性和合规性

将 axe-core 集成到 Playwright UI 测试中，以自动检测核心屏幕上的 WCAG 2.1 AA 违规。将违规报告作为构建工件发布，并在出现严重问题时使构建失败。使用 Azure Test Plans 和 Test & Feedback 扩展安排探索性可访问性会话，以进行手动验证。这将自动化覆盖与以人为本的检查相结合。