浏览器和系统组合很多，Agent 怎样核对兼容性测试有没有漏项

兼容性测试首先核对承诺支持哪些配置，再看每条关键用例在哪些配置真正有运行记录。Agent可以将这两份材料组成矩阵，区分未执行、失败和批准排除。没有测试过的格子不应因相邻格通过而自动变绿。

支持范围和工具配置分别登记

支持声明可以写Windows上的Chrome、macOS上的Safari，测试工具可能写chromium、webkit等项目名。两者是否对应，需要测试负责人说明实际浏览器、操作系统和版本，不能仅凭名称相近映射。浏览器引擎相同也不意味着所有产品行为都已验证。

矩阵以用例与配置的组合为单位，另留运行ID、版本、数据身份和观察。一个配置下可能只跑过部分用例，因此不能在操作系统标题上勾一次完成，就代表整列都已覆盖。批准排除的横屏路径则需要指向排除依据，而不是与遗漏空白混在一起。

官方机制说明1：按操作系统、浏览器等测试配置安排用例，不把一个配置的结果外推到全部组合。

现成工具能安排不同配置测试，拟定助手主要解决承诺语言、项目配置与实际记录之间的对应。若平台已提供覆盖报告，就读取其受控导出而非重复制造数字；额外输出应解释哪些格子的证据不足。

合成输入1。 支持Win+Chrome及macOS+Safari，只取得Win运行

预期处置：Safari列未执行，不能标通过

合成输入2。 Chromium用例成功但承诺范围写Chrome与Edge

预期处置：要求核对实际产品配置，不把引擎同源外推

合成输入3。 移动端横屏明确排除，报告缺该组合

预期处置：保留已批准排除依据，不当作覆盖缺口

Safari未执行需要补计划或明确缩小承诺，不能称为已发现缺陷。Chromium记录则要核它实际验证了什么，不能代替Chrome与Edge两种支持范围。横屏有明确排除时，仍保留该组合及依据，报告才解释得了为什么不纳入本轮覆盖分母。

工作表把登录、填写和导出等既有用例按批准范围展开，再关联相应运行记录。本文只采用附件中的合成用例标识，未新增实际测试路径。每个缺格应写配置和用例，执行人员收到后无需重新推断要跑哪一项；证据不可访问的格子则写取证受限，而非从报告消失。

配置变化以后需要重新确认映射。曾经某项目名代表某浏览器，不说明现在仍相同；保留当次运行的配置快照，比读取当前工具设置更能解释历史结果。对于未取得的版本，明确未知，不随意填“最新”。

从支持声明挑一个组合，核对哪些关键用例有记录；再从一条成功运行反查它最多能支持哪个组合。这样可发现承诺漏格和记录被过度外推两类问题。实际执行仍由授权人员补证，附件不会把空白当成功。

定制前可提交一段支持声明、一份配置导出和几条运行摘要。是否需要开发，取决于已有工具是否已对齐这些身份，以及团队需不需要额外的缺口解释和审批排除视图，而不是配置矩阵越大就越应该上Agent。

附件采用同一合成预约用例TC1：Windows与Chrome有运行R1，macOS与Safari没有记录，Edge只有一个尚未证实映射的chromium摘要，移动横屏另有批准排除EX1。四行分别展示有材料、未执行、映射未知和排除，不能把后三项统称失败。

核对时先让人员说明每行证据支持什么，再看它是否被用于超出范围的支持承诺。R1并不证明其他浏览器通过，EX1也不证明横屏不可能工作，只说明不在本次承诺。适用范围变化应产生新的覆盖决定，原来的测试证据保留原配置，不能随当前支持文案一起被重写。

对于工具项目名，建议在映射表中记录当次运行配置引用，而不只登记一个永久别名。Edge对应关系没有证据时，格子维持映射待核；补到真实环境信息后再归入支持组合。这样不会将历史成功记录随当前项目重命名而错误扩大，也使测试执行人员知道需要补的是配置证明还是一次新的运行。

下载本题合成输入与可填写工作表。附件保留实际结果、复核人和证据位置空栏。