设计自动化测试结果看板，先回答它要支持哪些决策：发布能否放行、失败集中在哪、稳定性是否在改善。围绕这些问题选指标、定口径、划角色、排刷新节奏，再跑通一轮评审后扩展。本文给出决策问题对照表、指标定义表、数据来源清单、三层页面结构、角色责任表和上线检查清单，覆盖从设计到最小可用版本落地的完整过程，不涉及测试脚本编写与具体商业看板产品选型。
要点总览（TL;DR）
- 看板设计从决策问题出发：先明确发布放行、失败定位、稳定性趋势三类判断，再倒推指标，避免把测试报告数字全部堆上页面。
- 每个指标都要写成定义表，明确公式、数据来源、统计粒度和排除规则；跳过、阻塞、环境失败单独归类，口径变更留记录。
- 数据链路先做字段对齐，同一用例多次执行按“用例+版本+环境”取最新状态，环境失败在采集阶段标记，刷新频率与评审时点匹配。
- 页面按总览、分析、明细三层组织，筛选维度保持一致，保证任一总览数字能在三次点击内到达失败用例清单。
- 先做最小可用版本，只放会触发动作的指标，跑通一轮评审后再补趋势类和修复效率类指标。
先定决策问题：看板要回答哪几件事
看板设计的第一步是列出使用者要做的判断，再倒推需要哪些数字。把自动化测试结果看板要回答的问题归为三类，每类对应一组指标族和主要查看角色，可以避免把测试报告里的所有数字搬上页面。
| 决策问题 | 典型判断 | 对应指标族 | 主要查看角色 |
|---|---|---|---|
| 发布放行 | 本次版本能否进入下一环节 | 用例通过率、阻塞用例数、关键模块失败数、环境可用状态 | 测试负责人、项目经理、发布评审人 |
| 失败定位 | 失败集中在哪些模块、哪类原因 | 失败分布（按模块/分支/环境）、失败原因分类、新增失败用例 | 自动化工程师、开发 |
| 稳定性趋势 | 自动化资产是否在变好 | 执行成功率趋势、波动率、平均修复时长、跳过与阻塞占比 | 测试负责人、技术负责人 |
裁剪的原则是：一个指标如果无法对应到某个角色的具体动作，就不放进首期看板。例如“累计用例总数”通常只反映资产规模，不触发任何决策，可以放到明细层备查，不占总览位置。反过来，同一个指标可能服务两类问题，比如关键模块失败数既用于放行判断，也用于失败定位，此时应明确它在总览层以“结论”形式出现，在分析层以“分布”形式展开。
填写这张对照表时，建议每个决策问题只保留三到五个指标，并写明“看到什么值、谁、做什么”。这张表是后续指标定义和页面设计的输入，完成标志是每个指标都能追溯到至少一个决策问题和一位查看角色。
核心指标与计算口径怎么定
口径分歧是看板失效最常见的原因：两个人说“通过率”，一个按用例数算，一个按执行次数算，数字对不上，看板就失去信任。解决办法是在建设期把每个指标写成定义表，明确公式、数据来源、统计粒度和排除规则。
| 指标名 | 公式 | 数据来源 | 统计粒度 | 排除规则 |
|---|---|---|---|---|
| 用例通过率 | 通过用例数 ÷ 已执行用例数 | 测试执行记录、用例库 | 按用例，按版本或按天汇总 | 排除跳过、阻塞用例；未执行不计入分母 |
| 执行成功率 | 成功执行次数 ÷ 总执行次数 | 测试执行记录、流水线记录 | 按执行次数 | 排除环境失败与主动取消的执行 |
| 失败分布 | 各维度失败数 ÷ 失败总数 | 测试执行记录、缺陷系统 | 按模块、分支、环境分组 | 环境失败单列，不混入脚本失败 |
| 平均修复时长 | 失败关闭时间与首次失败时间之差的平均值 | 缺陷系统、测试执行记录 | 按缺陷，按周或按版本汇总 | 排除未关闭缺陷与重复缺陷 |
| 稳定性/波动率 | 同一用例在统计周期内结果翻转次数 ÷ 执行次数 | 测试执行记录 | 按用例，按周汇总 | 排除环境变更窗口内的执行 |
分子分母的差异要写清楚。按用例统计适合回答“这个版本覆盖得怎么样”，按执行次数统计适合回答“流水线稳不稳”，按天统计适合看趋势。三种口径可以并存，但同一张卡片只能使用一种，并在卡片标题或说明中标注。
跳过、阻塞、环境失败三类结果需要单独归类，不能简单算作失败或成功。建议的规则是：跳过不计入分母；阻塞计入分母但不计入通过；环境失败从脚本失败中剥离，单独统计并在总览层提示，因为它指向的是基础设施问题而非代码问题。口径一旦确定，任何调整都要记录变更时间、变更内容和影响范围，并在看板说明区保留历史版本，避免前后数据不可比。
数据从哪来：采集、清洗与刷新节奏
看板的数据链路通常涉及四个来源：测试执行记录、用例库、缺陷系统和流水线记录。设计时先做字段对齐，确认每个指标需要的字段在来源系统中都存在，并约定统一的标识，例如用例 ID、版本号、分支、环境、执行批次。
- 测试执行记录：提供每次执行的结果、开始与结束时间、执行批次，是计算通过率和成功率的主数据。
- 用例库：提供用例所属模块、优先级、负责人，用于失败分布和关键用例筛选。
- 缺陷系统：提供失败关联的缺陷状态与关闭时间，用于计算平均修复时长。
- 流水线记录：提供构建号、触发方式、环境信息，用于把执行结果挂到正确的版本和分支上。
同一用例在一个版本内可能执行多次，去重策略要事先约定。常用做法是按“用例 + 版本 + 环境”取最新一次执行结果作为该用例的当前状态，历史执行保留用于趋势和波动率计算。这样总览层看到的是最新状态，趋势图看到的是完整历史，两者不冲突。
环境失败与脚本失败的标记方式需要在采集阶段完成，不能留到看板层再猜。可行的做法是在执行记录中增加失败类型字段，由自动化框架或执行人在结果回传时标注；无法自动判断的，进入待归类队列，由自动化工程师在约定时限内处理。
刷新频率与查看时点匹配即可，不必追求实时。发布评审前需要最新结果，可以设为每次流水线执行后刷新；稳定性趋势按天或按周更新足够；明细层可以按需查询。刷新过频会增加维护成本，也会让使用者对数字变化失去敏感度。
当测试执行、用例与缺陷数据分散在不同工具中时，看板建设会先遇到字段对不齐的问题。ONES DevOps 解决方案整合 DevOps 工具链，集中可视化展现 CI/CD 全过程，其功能模块组合包含项目管理、测试管理、效能管理和流水线集成，可以把测试执行记录与工作项、缺陷关联在同一处，减少跨系统手工对齐字段的工作量；具体字段与刷新机制需按实际集成配置确认。
看板页面结构与分层设计
页面按总览、分析、明细三层组织，每层服务不同的查看深度，配合统一的筛选维度形成下钻路径。
| 层级 | 放什么 | 给谁看 | 典型字段 |
|---|---|---|---|
| 总览层 | 放行结论、关键指标卡片、趋势线 | 测试负责人、项目经理、发布评审人 | 通过率、阻塞数、环境状态、成功率趋势、波动率 |
| 分析层 | 失败分布、模块热区、原因分类 | 自动化工程师、开发 | 按模块/分支/环境的失败数、新增失败用例、失败类型占比 |
| 明细层 | 单次执行记录、失败用例清单 | 执行人与定位问题的开发 | 用例 ID、执行时间、失败信息、关联缺陷、负责人 |
总览层的第一屏应给出放行结论相关的数字，而不是所有指标的平铺。趋势线用于回答稳定性问题，放在结论旁边便于对照。分析层承担定位任务，模块热区和失败类型占比是主要入口，点击后进入明细层。明细层保留完整记录，支持按用例、执行批次、负责人检索。
筛选维度在三个层级保持一致：模块、分支、环境、时间。一致性让下钻路径可预测，使用者从总览点进分析层时，筛选条件自动带入，不需要重新选择。完成标志是任意一个总览数字都能在三次点击内到达对应的失败用例清单。
角色分工与交付物
看板从建设到日常使用涉及多个角色，每个角色的动作和交付物要写清楚，否则会出现“数字有人看、没人管”的情况。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 测试负责人 | 确定决策问题与指标清单，维护口径文档，做放行判断 | 指标定义表、口径变更记录、放行结论 |
| 自动化工程师 | 保障执行记录完整回传，处理失败归类，维护环境标记 | 失败类型标注、待归类队列处理记录 |
| 开发 | 根据失败清单定位并修复脚本或产品问题，更新缺陷状态 | 缺陷修复记录、失败原因反馈 |
| 项目经理 | 在评审会上使用看板结论，跟踪阻塞项关闭 | 评审纪要、阻塞项跟踪清单 |
| 质量评审会 | 对照看板做放行决策，确认口径无争议 | 放行决议、口径问题清单 |
口径由测试负责人维护，失败归类由自动化工程师负责，放行判断由测试负责人与评审会共同完成。评审会的输入是总览层结论与分析层失败分布，输出是放行决议和需要跟进的问题清单；会上提出的口径疑问应进入口径变更记录，而不是当场口头解释后遗忘。
ONES 的测试管理与项目管理、效能管理在同一方案中组合，评审会所需的执行结果、缺陷状态和版本信息可以在同一工作项体系内关联查看，减少会前手工汇总；实际可用范围以团队部署的模块为准。
一个最小可用看板的落地示例
以下为演示情景，用于说明取舍过程，不代表特定团队的真实数据。
背景：一个约二十人的研发团队，自动化用例覆盖核心回归，每周两次发布评审，此前的测试报告以邮件附件形式发送，数字口径不统一。首期目标只回答两个问题：本次版本能否放行、失败集中在哪。
首期指标选择四个：用例通过率（按用例）、阻塞用例数、按模块的失败分布、环境失败数。暂不纳入平均修复时长和波动率，因为缺陷关闭流程尚未规范，数据不完整，纳入后反而会产生误导。页面只做总览层和分析层，明细层先以失败用例清单表格代替。
上线后第一轮评审发现两个问题：一是部分执行记录缺少环境字段，导致环境失败无法单独统计；二是开发反馈失败清单没有关联缺陷，定位后需要另开系统查状态。调整方式是补全执行回传的环境字段，并在失败清单中增加缺陷关联列；同时把波动率推迟到缺陷流程规范后再纳入。这一轮调整后，看板才进入稳定使用。
上线前的完成检查
用下面这张清单逐项核对，全部通过再宣布看板可用。
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 指标口径书面化 | 每个指标有公式、粒度、排除规则，且指定维护人 | 测试负责人 |
| 数据链路可追溯 | 任一数字可回溯到来源记录，缺失字段有提示 | 自动化工程师 |
| 指标对应角色与动作 | 每个指标写明查看角色和触发动作 | 测试负责人 |
| 刷新节奏匹配评审节奏 | 评审前数据为最新，刷新时间与会议时间对齐 | 自动化工程师 |
| 口径变更与维护机制 | 有变更记录模板和定期复核安排 | 测试负责人 |
五项全部满足，说明看板具备了基本可信度；任何一项缺失，都应先补齐再扩大指标范围。最小可用版本跑通一轮评审后，再按决策问题的优先级逐步加入趋势类和修复效率类指标。
常见问题
团队刚开始做自动化测试，执行记录很少，看板还有必要建吗？
有必要，但首期范围要收窄。执行记录少时，趋势类和波动率指标没有统计意义，可以先只做两类内容：本次执行的通过率与阻塞用例数，以及按模块的失败分布。等执行次数积累到能看出趋势，再加入成功率和波动率。看板的价值在于让失败有人跟进、放行有依据，这个作用在数据量小时同样成立。
看板上的通过率和测试报告里的数字对不上，怎么处理？
先确认两边的统计口径是否一致：一个按用例数算，一个按执行次数算，或者对跳过、阻塞用例的处理不同，都会导致差异。处理方式是回到指标定义表，核对分子分母和排除规则，确认哪一边的口径是书面约定的。如果确实需要两种口径并存，就在卡片标题或说明中标注清楚，并在口径变更记录中写明差异原因，避免使用者反复质疑数字。
环境失败很多，看板上一片红，应该先修环境还是先改看板？
先修数据标记，再谈页面。环境失败和脚本失败混在一起统计时，看板无法反映真实质量状况，此时调整页面只是掩盖问题。可行的顺序是：在执行记录中补上失败类型字段，把环境失败单独统计并在总览层提示；同时由自动化工程师处理待归类队列，明确哪些失败指向基础设施。环境问题本身需要单独跟进，看板负责让它可见、可追踪。
看板需要实时刷新吗？每次流水线执行后都更新会不会太重？
按查看时点决定即可，不必追求实时。发布评审前需要最新结果，可以设为每次流水线执行后刷新；稳定性趋势按天或按周更新足够；明细层按需查询。刷新过频会增加维护成本，也会让使用者对数字变化失去敏感度。关键是刷新时间与评审节奏对齐，保证开会时看到的是最新数据。
看板上线后指标一直没人看，问题出在哪？
常见原因是指标没有对应到具体动作。检查每个指标是否写明了查看角色和触发动作：看到阻塞用例数超标，谁在什么时限内处理；看到某模块失败集中，谁去定位。如果指标只反映资产规模、不触发任何决策，就移到明细层备查。另外要确认评审会是否真的以看板结论作为输入，会上提出的口径疑问是否进入变更记录，否则看板会逐渐退回到邮件报告的附属位置。
