检测和管理变更
Cypress Accessibility支持三种主要途径来观察和处理项目无障碍报告中的变更：
本指南将讨论这些功能的工作原理以及一些常见的组合使用场景。
分支评审
分支评审通过比较两次Cypress运行的无障碍结果，帮助您快速发现新问题。
- 精确定位问题引入的时间和位置
- 通过完全渲染的页面快照轻松理解和调试
- 分享包含所有上下文信息的特定新问题链接
分支评审使用场景
加速代码审查和部署
在审查其他开发人员提交的拉取请求或自己创建拉取请求前使用分支评审。您可以比较变更分支的报告与主分支的等效报告。这种比较能显示您的变更改善或完全修复的问题，以及新引入的问题和现有失败的新实例。
由于这将被审查的违规数量减少到仅受PR代码变更影响的部分，您无需浪费时间寻找相关内容——如果没有差异，您就知道PR不影响无障碍评分，可以安全合并。
查看主无障碍分支评审文档获取此工作流程的视频演示。
本地开发时比较报告（无需等待CI）
您可能认为每次Cypress Accessibility报告都需要在持续集成(CI)流水线中运行完整的标准Cypress测试。
常见的无障碍工作流程是从本地开发环境创建小型Cypress Cloud记录来预览代码变更的效果。这允许快速分析单个或少量测试，尤其是当您正在积极修复无障碍问题时。
要获得高质量的少量测试比较，请从主分支本地记录测试，然后在变更分支上记录。在Cypress Cloud中，您可以比较这两次运行，知道它们覆盖完全相同的范围。
这完全绕过了您可能习惯的"推送、构建、运行测试、报告"周期，在需要快速反馈时非常有用。
查看计划运行间的变更
许多团队有一些Cypress项目按计划运行并针对QA、预发布或生产环境。这些运行生成Cypress Accessibility报告，但与特定代码变更的拉取请求无关。分支评审在这些情况下同样适用，即使所有运行都在同一分支上。
定期比较报告可以让您查看例如本周与上周之间是否引入了无障碍问题，然后找到变更发生的具体运行。这个"差异报告"可以作为工单基础转发给工程或产品团队。
注意
使用分支评审详细比较两次运行需要对运行本身有很好的理解。如果运行测试相同的页面和工作流，并且每次运行都完全通过所有测试，比较最为有用。这意味着Cypress在两种上下文中看到了应用程序的所有相同状态和变体。您的运行可能永远不会100%完美匹配，但越接近越好。
结果API
Cypress Accessibility的结果API提供与任何Cypress运行的无障碍报告结果相关的丰富数据。它支持在CI中添加步骤以阻止拉取请求或触发其他副作用。要使用结果API，您需要在CI流程中添加步骤。这附带一个辅助函数，将自动匹配您的CI构建与Cypress Cloud中的相关运行。
一旦收到结果，您可以执行任何需要的操作。以下是客户告诉我们的一些常见操作，其中结果与预期进行比较。
结果API使用场景
基于新失败的无障碍规则使构建失败
结果API提供包含所有失败规则的合并报告。这意味着您可以轻松准备已知允许的失败规则列表与任何运行的结果进行比较，并仅在先前通过的规则开始失败时选择使构建失败。这在阻止拉取请求和设置策略指南中有详细描述。
这个概念简单但强大，因为它提供了极高的信心，任何失败的构建都与特定的最近代码、内容或测试变更相关。特别是如果存在大量现有失败，检测到的实际失败元素数量可能在运行间变化，尤其是现有损坏组件以新方式重用时。
完全通过的规则没有这些问题，对于像使流水线失败这样的极端操作，重要的是高度确信问题实际上是新问题，并且可以追溯到特定 构建。有了这种信心，可以逐个解决现有失败规则以达到完全通过。
基于偏离期望分数的构建失败
结果API包括无障碍报告的具体失败元素计数和无障碍百分比分数。这使得设置分数阈值并在分数低于预期时使构建失败变得容易。这在采取监控方法或想要比基于特定规则更广泛、更不具体的标准时特别有用。
百分比分数的变化与运行中检测到的违反无障碍规则的元素数量变化直接相关。当分数下降时发出警报或使流水线失败是了解何时需要进入分支评审以理解分数变化根本原因的好方法。
向负责的特定团队发出失败警报
除了合并的无障碍报告外，结果API中按视图列出无障碍失败。视图始终与特定的URL模式或组件测试相关，这意味着在许多项目中可以将结果API中的无障碍问题与负责解决应用程序该部分问题的团队联系起来。
例如，客户可以使用此功能触发Slack webhook，通知特定频道有关特定区域的问题。结果API提供直接链接到视图和该视图中每个失败规则的链接，便于将有用链接转发到正确位置，或直接从CI输出进入调试。
分析功能
分析功能位于Cypress Cloud的企业报告的无障碍标签页中。这提供了跨项目的无障碍趋势概览，并支持筛选到单个项目和分支以查看分数随时间的变化。
分析功能使用场景
跟踪进展和发现趋势
这种级别的报告非常适合记录进展和发现意外趋势。当您看到项目分数长期下降时，可以通过分支评审进一步探索以了解驱动分数的变更。您可以比较分数变化前后的报告以确定引入了哪些无障碍问题。
设定目标和最低标准
在一个地方查看所有项目可以很好地了解每个项目的相对水平，并帮助确定在使用结果API实施策略时可能想要用于比较的值。
这也提供了有用的规划洞察，因为您可以看到改进的历史速度。如果某些项目比其他项目改进更快，您将能够认识到这一点并了解如何复制这种成功，或基于项目创建现实的OKR。
组合方法
如上所述，有时您可能需要在多个系统之间移动以追踪问题。例如，如果结果API发出信号表明功能分支上的构建未通过您的无障碍标准，您可能会点击进入运行本身，然后在分支评审中将其与主分支进行比较。这可能是旅程的终点，但如果主分支也未通过您的策略，您可以使用高层分析查看分数最初何时变化，并通过比较该时间前后的两次运行找到具体原因。这有助于检测代码被强制合并的位置，或应用程序中提供的内容何时出现与代码变更无关的无障碍回归。
在使用这些工具时，请记住点击"提交反馈"按钮，任何时候看到可以改进的地方以帮助您理解什么是重要的以及发生了什么变化。