mcpField
C
compliance-testing

compliance-testing

github.com/petrkindlmann测试与质量2221.1k 次安装6 天前更新
代码仓库

关于 compliance-testing

compliance-testing 是面向 QA 团队的技术合规测试技能,按已批准的地区政策验证同意状态、请求拦截、存储和披露行为。它提供可复现的实现证据,但明确测试通过并不等于法律合规或 CMP 认证。

主要功能

  1. 01验证同意前后存储与请求行为
  2. 02检查同意保存、撤回及 GPC 信号
  3. 03测试 TCF v2 与 Consent Mode 信号
  4. 04检查 EU AI Act 披露要求
  5. 05按清单验证 Cookie 属性与变更
  6. 06依据 Better Ads 标准测试广告体验

适用场景

  1. 01排查拒绝同意后仍发出的追踪请求
  2. 02验证撤回同意后的存储与网络变化
  3. 03检查 Cookie 清单与实际属性是否一致
  4. 04为 AI 生成内容披露建立自动化测试

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/petrkindlmann/qa-skills --skill compliance-testing

安装后在 Claude Code 中输入/compliance-testing确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
better-ads-tests.md
ci-automation.md
cookie-compliance.md
eu-ai-act-tests.md
gdpr-cmp-tests.md

详细介绍

横幅可以显示已拒绝状态,同时在其下方继续进行跟踪。此技能会根据产品已批准的要求,测试同意状态、基于政策的请求拦截、存储、GPC、Consent Mode 信号和披露行为。它提供可复现的技术证据;通过这些检查并不能证明符合相关法律,也不能证明获得了 CMP 认证。

发现问题

首先,检查项目根目录中是否存在 .agents/qa-project-context.md——其中包含适用法规、CMP 详情、广告网络和地理范围。跳过其中已有答案的问题。如果该文件不存在,建议使用 qa-project-context 技能创建。

适用法规
  • 适用哪些隐私和平台法规? 这将决定整个测试矩阵。
    • 欧盟: GDPR、ePrivacy 指令(Cookie)、《数字服务法》(DSA,自 2024 年 2 月 17 日起适用)、《欧盟人工智能法》(禁令 + AI 素养要求自 2025 年 2 月 2 日起生效;GPAI 义务 + 处罚自 2025 年 8 月 2 日起生效;第 50 条透明度要求自 2026 年 8 月 2 日起生效——高风险义务已推迟,见下文)。
    • 美国: CCPA/CPRA 以及适用于受众所在州的法律。在区域政策矩阵中记录具体的选择退出和通用信号要求。
    • 英国: UK GDPR/DPA、PECR(Cookie)、《2023 年在线安全法》、《数据使用与访问法》(DUAA)。
    • 其他: LGPD(巴西)、PIPEDA(加拿大)、POPIA(南非)。
  • 处理数据的法律依据是什么? 同意(主动选择加入)、合法利益或履行合同所必需——这决定了处理前是否必须获得明确同意。
  • 是否设有 DPO 或法律团队? 他们负责定义法律要求;此技能仅验证技术实现是否符合这些要求。
同意管理
  • 正在使用哪些 CMP 和广告产品? CMP 决定存储格式、API 和集成方式。记录具体产品和地区当前的认证及 TCF 要求;不要根据 CMP API 响应或数字版次比较来推断。
  • 有哪些同意类别? 通常包括严格必要(始终启用)、分析/性能、功能/偏好设置、营销/定向投放。
  • 如何向第三方脚本传递同意信号? 使用 IAB TCF v2(__tcfapi)、自定义数据层,还是直接调用 CMP API?
  • Google Consent Mode 是基础模式还是高级模式?区域政策要求哪些默认设置? 基础模式会在获得同意前拦截标签;高级模式可以在存储同意被拒绝时,不使用 Cookie 发送允许的测量数据。这会改变同意前的网络断言。参见 Google 的实施指南。
  • 如何证明每次同意状态变更都已完成? 找出一个包含已安排标签工作的应用/CMP 完成信号。横幅可见或 networkidle 都无法证明之后不会发生跟踪。
广告与无障碍访问
  • 使用了哪些广告网络和格式? Google Ads、Meta、程序化广告;展示广告、视频、插页式广告。Better Ads 标准联盟界定了哪些格式会触发 Chrome 的广告过滤。
  • 是否有无障碍访问义务(ADA、EAA、Section 508)? 这些属于实际合规事项,但应在 accessibility-testing 中制定;此技能仅梳理法律环境,见下文。

核心原则

1. 以已批准的政策作为测试判定标准

记录各地区、各同意状态下预期的存储、请求、信号和 UI 行为。偏离该矩阵即判定为失败。测试可以证明观察到的技术结果;法律适用性、允许的处理行为以及视觉暗黑模式的判断需要另行审查。

2. 自动化技术检查,安排法律审计

自动化检查:政策禁止的 Cookie 和请求、横幅功能、Cookie 属性、同意状态持久化、GPC 和 Consent Mode 信号。隐私政策措辞、横幅醒目程度和跨境传输文档仍需人工审计。不要假装最小按钮尺寸断言就能解决这些问题。

3. 测试不理想的同意状态

合规边界存在于“未交互”“已拒绝”和“已撤回”状态中——违规往往藏在这些状态里。“全部接受”状态是最不值得测试的。

4. 验证行为,而不是 CMP

CMP 也会有漏洞。不要把 CMP 界面当作证据。断言实际结果:是否设置了 Cookie、是否加载了脚本、是否注册了 GPC 选择退出。CMP 是实现细节;合规性要通过行为来衡量。

5. 纵深防御,由配置驱动

在多个层面进行验证——CMP 配置、网络请求、Cookie 状态、客户端信号。基于类型化清单和跟踪域名列表驱动测试,这样新增类别或阈值只需编辑数据,而无需重写测试套件。法规会变化,因此测试套件必须便于更新。

使用 Playwright 测试 GDPR / CMP

同意流程合规性由多个彼此独立、可能分别失败的检查组成。每项检查的完整可运行代码见 references/gdpr-cmp-tests.md。

  • 同意横幅和控件 — 验证首次访问时横幅可见、接受/拒绝控件可用,以及政策链接有效。最小尺寸只是机械阈值;应单独评估醒目程度是否相当,以及是否存在暗黑模式。
  • 同意前后的 Cookie 状态 — 在初始化完成、接受和拒绝后,执行已批准的可选存储政策。维护精确的必要 Cookie 名称及完整清单;前缀不得豁免名称相似的跟踪 Cookie。
  • 同意状态持久化和撤回 — 验证导航后的实际持久化状态,以及撤回后更新的新状态,然后检查存储和网络效果。首次访问应使用 storageState: { cookies: [], origins: [] } 创建全新上下文。
  • 阻止第三方请求 — 在导航前附加 page.on('request');应匹配已配置的主机名和端点,而非 URL 子字符串。基本模式可要求跟踪请求数为零;高级模式则需要断言拒绝状态下允许的流量。应纳入第一方代理和真实的完成里程碑。
  • Global Privacy Control — 分别验证 HTTP 标头路径和 DOM 偏好路径。extraHTTPHeaders: { 'Sec-GPC': '1' } 不会创建 navigator.globalPrivacyControl。应明确标注 DOM 模拟,检查已记录的选择退出和政策禁止的行为,并使用启用了原生 GPC 的浏览器验证浏览器支持情况。参见 GPC 规范。
  • TCF v2 同意状态 — 使用 __tcfapi('addEventListener', 2, callback),等待相关的已完成事件,限制失败等待时间,并移除监听器。getTCData 已弃用。断言已配置的目的和供应商同意状态;政策编号并不能证明 TC 字符串有效、符合 TCF v2.3 时效要求或已获认证。参见 IAB CMP API。
  • Google Consent Mode v2 — 根据区域政策验证全部四个信号,并保持命令顺序。在每项测试中安装观察器,并在每项操作前设置检查点。测试应用自身默认值时,切勿预置拒绝状态的默认值。共享适配器会观察 gtag 参数数组;对象事件和 GTM 同意模板 API 需要使用各自文档说明的适配器。共享辅助工具以及基本/高级模式的区别见 ../analytics-tracking-testing/references/consent-mode.md。

EU AI Act 合规

该法规分阶段生效,时间表已于 2026 年调整。注意:Digital Omnibus(2025 年 11 月提案;2026 年 5 月 7 日达成临时协议)推迟了高风险义务——请勿依据旧的 2026 年 8 月 2 日高风险义务日期进行测试。

义务适用日期测试内容
禁令 + AI 素养2025 年 2 月 2 日(已生效)不得存在第 5 条禁止的做法(社会评分、实时公共场所生物识别身份识别、操纵性 AI)。记录范围内的 AI 功能;限制使用违禁库。
GPAI 义务 + 处罚2025 年 8 月 2 日(已生效)确认模型卡、训练数据摘要、版权政策和披露页面均已提供。
第 50 条透明度2026 年 8 月 2 日标注 AI 生成的内容;披露深度伪造内容;告知用户其正在与 AI 互动。测试披露标签/水印。此日期仍然有效。
机器可读标记宽限期2026 年 12 月 2 日2026 年 8 月 2 日前已投放市场的系统,可在此日期前添加水印/标记(Omnibus 将宽限期从六个月缩短为三个月)。
高风险(附件 III,按使用场景划分)2027 年 12 月 2 日风险管理、数据治理、人工监督、透明度 UI。Omnibus 已将日期从 2026 年 8 月 2 日推迟。
高风险(附件 I,受产品法规监管)2028 年 8 月 2 日同上,适用于嵌入受监管产品的系统。日期从 2027 年 8 月 2 日推迟。

现在编写第 50 条披露测试;待附件 III 义务生效后,再进行高风险 UI 测试。第 50 条透明度披露测试和第 5 条禁止做法(生物识别库)限制,请参阅 references/eu-ai-act-tests.md。对于大模型专项评估(幻觉、越狱抵抗能力、提示词注入),请使用 ai-system-testing skill。

Better Ads 标准

Coalition for Better Ads 定义了会触发浏览器级广告过滤的广告格式(Chrome 会过滤不合规网站上的广告)。

格式桌面端移动端测试方法
弹出式广告是是检查页面加载后 5 秒内是否在无用户操作的情况下出现模态框/覆盖层
自动播放且带声音的视频是是读取实时的 video.autoplay / video.muted 属性(而非 HTML 属性)
带倒计时的插屏广告是是检查是否有倒计时器阻挡内容
大型固定广告(>30% 视口)是是测量固定元素尺寸与视口的比例
广告密度 >30%否是计算广告总面积与内容面积之比
闪烁动画广告否是监测动画帧率(每秒闪烁 >3 次)

静音视频检查必须读取实时 DOM 属性(el.muted),而不是 getAttribute('muted')——播放器脚本可能会在 JS 中设置 video.muted = true,但从不添加内容属性,因此仅检查属性会将静音广告误判为有声音,并漏掉先静音后取消静音的广告。

注意:CBA 于 2025 年 1 月 14 日新增了两种桌面端和两种移动端广告体验;Chrome 最早将于 2026 年 5 月 14 日开始评估这些广告。 在此日期前,请对照当前的 Better Ads Standards 页面重新检查较新的组合格式。自动播放视频和移动端广告密度检查,请参阅 references/better-ads-tests.md。

Cookie 合规

将带类型的 Cookie 清单作为事实来源,然后从三个方面断言实际 Cookie 与之匹配:

  • 清单 — 一个 CookieDefinition[],记录名称、类别、用途、最长有效期,以及每个 Cookie 必须具备的 Secure / HttpOnly / SameSite 属性。
  • 属性验证 — 每个检测到的 Cookie 都必须符合其定义中的标志,且有效期不得超过声明的最长有效期。比较前,将未设置的 SameSite 规范化为 None——如果服务器未设置该属性,Playwright 可能会将其省略或以不同方式处理,因此未经规范化的检查可能会无故失败或悄然通过。
  • 漂移检测 — 当出现不在清单中的 Cookie 时,直接让测试套件失败(throw,而不是发出警告),以确保随着脚本增加,清单也保持更新。

带类型的清单和两种实现请参见 references/cookie-compliance.md。

无障碍合规——仅作法律概览

无障碍在许多司法管辖区都是法律要求,但实际测试应在 accessibility-testing 中编写(axe-core、键盘、屏幕阅读器)。此表仅概述法律现状,帮助你了解相关义务。

地区法律标准执法情况
EUEuropean Accessibility Act (EAA)EN 301 549 / WCAG 2.1 AA于 2025 年 6 月 28 日生效;成员国已开始实施处罚。预计下一版 EN 301 549 将与 WCAG 2.2 保持一致。
USAADAWCAG 2.1 AA(法院判例)私人诉讼
USA(联邦)Section 508WCAG 2.0 AA联邦采购要求
Canada(Ontario)AODAWCAG 2.0 AA罚款最高可达每天 $100K
UKEquality Act 2010WCAG 2.1 AA(指南)诉讼

定期合规审计

每周运行合规测试(而不仅仅是在 PR 时运行),以发现配置漂移,并将结果作为长期 CI 构建产物留存,供审计追踪。定期运行的 GitHub Actions 工作流及 90 天构建产物保留期,请参见 references/ci-automation.md。

反模式

仅在接受同意后测试

只在“全部接受”状态下运行合规测试。合规的关键边界是“未交互”和“已拒绝”状态——违规往往就藏在这些状态中。测试所有状态:未交互、已接受、已拒绝、部分接受、已撤回。

断言虚构的 CMP 全局变量

检查 window.__cmp.gpcStatus 或类似虚构的全局变量来“证明”已选择退出 GPC。应使用 CMP 文档说明的状态或设置界面,并验证所需的网络/存储结果。GPC HTTP 标头和 DOM 属性是独立的输入;TCF 没有定义 GPC 状态字段。

测试时补上缺失的同意配置

在测试应用默认值时,通过 addInitScript 注入拒绝默认值,可能会掩盖缺陷。每项测试都应观察应用自身发出的命令,保留后续更新,并在观察中断或数据层被替换时失败,而不是代为修复。每个门控检查都应配备一个已知正常的夹具和一个有针对性的故障变体。

仅检查属性的视频验证

将 getAttribute('muted') === null 视为“有声音”。通过程序静音的视频通常没有该内容属性。应读取 el.muted / el.autoplay 实时属性。

会漂移的硬编码 Cookie 列表

没人更新的 Cookie 清单。使用漂移检测测试,在出现任何未知 Cookie 时通过 throw 使测试失败——实际情况与清单会自动保持同步。

仅测试 CMP

信任 CMP,只测试其界面。CMP 也会有错误。应测试实际结果:设置了哪些 Cookie、加载了哪些脚本、传输了哪些数据。

仅进行季度人工审计

每季度手动审计一次。两次审计之间,开发者可能添加一个在同意前触发的分析脚本,而这件事三个月都没人发现。自动化测试会在下一次 CI 运行时发现问题。

忽视地区差异

使用单一的全球同意模型。GDPR 要求选择加入;CCPA 允许通过 GPC 选择退出。面向两个地区提供服务,就要测试两种体验。

将合规视为一次性工作

只构建一次套件,然后便不再更新。法规会不断演变(《ePrivacy 条例》、TCF 版本升级、《人工智能法案》分阶段实施、更新后的 CBA 标准)。应每季度审查。

验证

先进行最小检查——确认合规套件可以运行并执行门禁,再信任其结果:

npx playwright test tests/compliance --project=chromium

将调整后的配方放在 tests/compliance 下,并配置实际的就绪信号和策略清单。先在明确为空的上下文中,用已知正常的测试样本验证它们能通过。然后将其用于受控的异常变体:延迟发起被禁止的请求、缺少默认值、操作后更新不正确或缺失、忽略 GPC,以及永不完成的 CMP 回调。每项对应测试都必须失败。独立验证 HTTP GPC 标头,不要将其与明确模拟或原生启用的 DOM 偏好混为一谈。在全拒绝策略的高级模式下,测量前检查全部四个默认值;对于基本模式,验证在接受同意后初始化标签时的默认值和更新。保留测试场景及观察时长,并与结果一同记录。

完成标准

  • 确认适用于产品和目标地区受众的法规(GDPR、ePrivacy、DSA、《欧盟人工智能法案》、相关的美国州法律子集、UK OSA/DUAA),并记录在 .agents/qa-project-context.md 中。
  • 针对每个入口测试同意流程:首次访问、接受、拒绝、撤回以及跨导航持久化;每项都作为独立测试通过。
  • 全球隐私控制(GPC)的 HTTP 和 DOM 输入用例均通过;验证已记录的退出选择,以及策略禁止的存储和请求。应明确标明 DOM 模拟是模拟。
  • Google Consent Mode 的四项信号和命令顺序与已批准的地区/模式矩阵一致;通过新鲜的操作检查点验证接受、拒绝、部分同意和撤回后的更新。观察器不得提供应用程序同意默认值。
  • 受控的正常和异常测试样本证明每个技术门禁都能区分预期行为;设置有限时超时和完成标记,防止观察结果为空却未被发现。
  • 评估《欧盟人工智能法案》的适用性:测试禁止行为门禁、审查 GPAI 文档(如适用),并测试任何 AI 生成内容是否符合第 50 条透明度披露要求。
  • 完成 Cookie 审计:将所有 Cookie 分类并纳入类型化清单;漂移检测测试通过,未知 Cookie 数量为零。
  • 不得触发隐私政策未披露的未声明跟踪域名或 Cookie(这是可自动化的部分——法律文本审查是单独的人工/法律签核事项,而非测试)。
  • 合规套件在每周 CI 任务中运行通过,结果作为构建产物保存 90 天。

相关技能

  • accessibility-testing — 在此处编写实际的 WCAG/axe-core/键盘/屏幕阅读器测试。本技能仅梳理无障碍法律要求;不会编写无障碍断言。
  • security-testing — 安全合规(OWASP Top 10:2025、依赖项和供应链扫描)与隐私合规相辅相成;两者的威胁模型不同,所用工具也不同。
  • ai-system-testing — 定义 AI 功能的评估层(幻觉、越狱、提示词注入)。本技能仅测试第 50 条的披露要求;该技能则测试 AI 本身的行为。
  • ci-cd-integration — 为定期执行的每周审计和合规质量门禁配置流水线。
  • release-readiness — 合规门禁失败(同意前触发同意信号、缺少《人工智能法案》披露)会阻止发布;应将此套件接入该处的发布/不发布检查清单。

参考文件(位于 references/ 中)

  • gdpr-cmp-tests.md — 用于横幅控件、Cookie 状态、持久化/撤回、基于策略的请求拦截、独立 GPC 输入、有界 TCF 事件读取以及 Google Consent Mode 转换的 Playwright 代码。
  • eu-ai-act-tests.md — 第 50 条透明度披露测试和第 5 条禁用实践(生物识别库)门控,并附有 Omnibus 时间表说明。
  • better-ads-tests.md — Better Ads 联盟检查:检测实时网站上自动播放且未静音的视频,并测量移动端广告密度。
  • cookie-compliance.md — Cookie 类型化清单、属性验证(含 SameSite 规范化)以及清单偏差检测。
  • ci-automation.md — 定期每周合规审计 GitHub Actions 工作流,工件保留 90 天。

评论

支持 Markdown