测试执行统计这事很多团队其实早就在做了但做法基本停留在CI页面里翻一翻昨天跑了多少个、绿灯还是红灯、失败了几条。稍微认真一点的会有人定期导出Excel再手工做透视。可一旦项目跑到几千条用例、CI一天触发几十次这种手工式统计就会彻底失效。你根本说不清楚过去一个月到底是哪批用例在被反复执行又是哪些用例每次一跑就红、靠重试才勉强过关。这个问题恰恰是TestOps最应该先建模的核心度量谁跑得最多谁最稳定。本文就围绕这两个问题把数据口径、统计方法、落地实现和常见坑一次讲清楚。1. 先搞清楚TestOps执行统计到底统计什么1.1 统计的是“事实”不是“数字”我见过不少团队自动化用例数量写得很漂亮几千条、上万条覆盖率报告也做得花里胡哨。但你问他这些用例在过去一个月里真正执行了几次哪些用例每次跑都稳定通过哪些用例失败后靠重试救回来的他答不上来。原因很简单大家平时只关心“全量执行一次的结果”没有人把每一次运行的过程数据沉淀下来。TestOps的执行统计本质上要做的是把“每一次执行”变成可追溯的事实。它回答的不是“我们写了多少用例”而是“这些用例在真实环境里被怎样使用、表现如何”。所以统计对象是“执行事件”不是“用例清单”。一个用例被写出来但没跑或者只跑过一次和另一个用例每天在CI里被跑20轮两者代表的质量意义完全不同。在落地统计之前你要先接受一个理念执行次数、通过率这些指标不是为了给测试团队算KPI的而是用来暴露质量风险的。用例不是越绿越好统计不是越漂亮越好。只有建立在事实之上的数据才值得被讨论。1.2 三个统计维度频率、稳定性、效率围绕“谁跑得最多”和“谁最稳定”我一般把统计拆成三个维度执行频率一个用例或一组用例在统计周期内被纳入执行的次数。注意这里说的是“纳入执行的次数”不是“通过次数”因为失败和重试也算执行。稳定性一段周期内首次执行通过的比例以及失败次数在时间轴上的分布。稳定不是“平均通过率高”而是“波动小、可预测”。执行效率单个用例的平均耗时、最长耗时、超时比例。虽然标题没提但效率会直接影响频率数据的解读一个跑5分钟的慢用例和另一个跑3秒的快用例即使执行次数相同对CI反馈链路的影响完全不同。这三个维度大多数时候要放在一起看。只看频率你会以为高频用例是重点保护对象只看稳定性你会漏掉那些一年只跑两次但一跑就挂的定时任务用例只看效率又容易误伤那些虽然慢但覆盖核心链路的用例。单独拆开任何一个维度结论都可能是错的。1.3 口径先说清“谁”是指用例、模块还是人标题里“谁跑得最多、谁最稳定”这个“谁”如果不确定后面的统计就没有意义。在我见过的实践中“谁”通常有三种口径按测试用例统计最细粒度定位到具体一个方法、一个接口、一条页面流程。按模块或服务统计把同一模块下的用例聚合看整个模块的健康度适合技术管理者看。按执行者统计比如按团队成员分组看每个人负责的用例集执行情况和稳定性这更多用于人力分配。我建议在系统设计初期就把“用例标识”作为最小统计单元同时保留模块归属字段这样三种口径都能做。但要注意用例维度的数据更真实模块维度看趋势人员维度很容易引起不必要的“比较心态”所以我通常不推荐把人员维度的稳定性结果直接公开展示容易变味。2. 数据怎么来、怎么算指标体系的冷门细节2.1 数据源结果XML是整个统计的地基想要统计执行数据先得有数据。绝大多数测试框架最终都会产出标准化的结果文件最通用的就是JUnit XML格式。无论是Java的JUnit、Python的pytest、JavaScript的Jest还是JMeter、Selenium这类工具都有插件或内置能力输出JUnit格式的XML。这是目前兼容性最好、最值得优先依赖的数据源。如果你在用Allure报告也可以从allure-results目录下的result.json里拿结果信息更丰富但解析成本稍高。我个人的习惯是JUnit XML作为基础数据源Allure结果作为补充字段比如步骤截屏、参数、日志两边用相同的用例ID关联。一个容易被忽略的点同一套用例在本地、在CI、在测试平台里执行时XML里记录的suite name、class name可能都不一样尤其是参数化用例。所以需要建立一套统一的用例标识规则而不是直接拿XML里的name当主键。比较稳妥的做法是Java类用包名.类名#方法名Python用文件路径::函数名参数化用例在后面追加参数摘要的hash值。这样可以最大限度保证同一个用例在不同轮回执行中的标识一致。2.2 稳定率的正确打开方式很多人统计通过率直接就是“通过次数 / 执行总次数”。这个公式在大多数时候是错的因为它把重试掩盖的风险平均掉了。一次失败后重试通过最终报告显示通过但是第一次跑的时候它确实暴露了问题。我建议稳定率公式调整为首次执行稳定率 首次执行通过次数 / 首次执行总次数这个指标不考虑重试只统计每个用例在每一轮执行中第一次运行的结果。如果一个用例跑10轮第一轮首次失败、重试通过后面9轮首次就通过那它的首次执行稳定率是90%而不是100%。这样你才看得出哪些用例一直在“靠重试兜底”。对应的数据表设计也需要预留字段。JUnit XML标准里没有“第几次重试”这个属性所以如果你们框架开启了重试解析XML时就要做额外处理。最简单的方案是统计系统自己判断“同一run下同一个用例出现多次”即为重试第一次记为首次执行后续记为重试。另外一种方案是在测试框架里自定义注解或钩子把attempt序号写进XML的properties字段里处理起来更干净。2.3 这几种情况会让统计瞬间失真统计系统上线后最先出现的问题往往不是算法不对而是原始数据就不可靠。根据我踩过的坑有三个典型的失真源头第一重试机制导致执行次数虚高。pytest-rerunfailures、JUnit的RetryTestRunner这类机制会在同一个run内让同一个用例执行多次。如果你直接数XML里的testcase节点数量执行次数会被放大好几倍。极端情况下一个用例失败三次重试三次最终在表格里出现4条记录你就以为它被执行了4次。第二用例标识不稳定导致历史数据断层。只要有人重构了类名、改了函数名、调整了参数化数据同一个用例在解析后的ID就会变化。表现在统计里就是上周的“高频用例”这周突然消失或者出现了两个长得几乎一样但ID不同的记录。第三并发执行和上报时间差导致统计归属混乱。分布式执行时同一批次的测试结果由多台执行机分别上报如果run_id生成得不统一统计系统会把同一轮执行当成多轮数据或者把多轮执行合并成一轮。3. 实操演示搭一个“谁跑得多、谁稳定”的统计视图3.1 方案取舍自研脚本还是测试平台自带能力关于落地方案你面前大概有三条路买现成测试平台的统计模块、用CI的Allure/ReportPortal等开源工具、自研一个轻量统计服务。如果团队规模和用例数都不大优先用现成方案Allure的仪表盘足够你肉眼识别高频和失败趋势。如果用例规模到几千条以上或者要按模块、按人员做交叉分析现成报表往往不够灵活这时候自研一个轻量统计视图的价值就体现出来了。这轮实操我讲自研的轻量路线Python脚本定时扫描CI里生成的结果XML解析后写进SQLite再输出两张榜单。这套逻辑非常轻零依赖跑在任意一台内网机器上就行。不要一上来就上ClickHouse、引入大数据平台先让数据流跑通、口径验证正确后续需要扩展时再换存储也不迟。3.2 一张表和一个解析脚本建表时不用做多复杂的设计先满足核心统计需求。我给出最小可用的三张表结构CREATE TABLE cases ( case_id TEXT PRIMARY KEY, module TEXT, case_name TEXT ); CREATE TABLE runs ( run_id TEXT PRIMARY KEY, started_at TEXT, ci_build TEXT ); CREATE TABLE case_results ( result_id INTEGER PRIMARY KEY AUTOINCREMENT, case_id TEXT, run_id TEXT, status TEXT, is_retry INTEGER DEFAULT 0, duration_ms INTEGER );这里最关键的是run_id的生成规则。我建议在每次构建开始时生成一个UUID通过环境变量注入到所有测试进程测试框架在写结果文件时把run_id带进XML片段。如果你们用的是pytest可以在conftest.py里加一个全局fixture把run_id固化下来。解析脚本的核心逻辑不复杂就是把XML里的testcase节点读出来一组节点算一次执行import glob import os import sqlite3 import xml.etree.ElementTree as ET from collections import defaultdict RESULT_DIR /data/results/xml DB_PATH /data/testops/main.db def parse_xml(file_path): tree ET.parse(file_path) root tree.getroot() run_id root.attrib.get(run_id, os.path.basename(file_path)) started_at root.attrib.get(timestamp, ) cases [] for suite in root.iter(testsuite): for case in suite.iter(testcase): case_id f{case.attrib.get(classname, )}#{case.attrib.get(name, )} status passed if case.find(failure) is not None: status failed if case.find(error) is not None: status error cases.append({ case_id: case_id, status: status, duration_ms: int(float(case.attrib.get(time, 0)) * 1000), }) return run_id, started_at, cases def dedupe_by_run(cases): # 同一run内同一个case_id可能出现多次第一遍算首次其余算重试 occurrences defaultdict(int) deduped [] for case in cases: occurrences[case[case_id]] 1 case[is_retry] 1 if occurrences[case[case_id]] 1 else 0 deduped.append(case) return deduped这段代码的重点在dedupe_by_run它把重试记录保留下来但不直接清掉后续统计时通过is_retry0过滤只保留首次执行结果。这是让稳定率指标成立的关键一步。3.3 直接输出“最高频”和“最不稳定”两张榜单数据入库后统计逻辑就非常直接了。高频用例榜单按run_id去重统计避免同一轮里重试导致次数虚高SELECT c.case_id, COUNT(DISTINCT cr.run_id) AS run_count FROM cases c JOIN case_results cr ON c.case_id cr.case_id GROUP BY c.case_id ORDER BY run_count DESC LIMIT 20;稳定率榜单只统计首次执行结果并且要求执行次数不低于一定门槛比如至少5次否则样本太少没有参考价值SELECT c.case_id, COUNT(*) AS first_run_count, SUM(CASE WHEN cr.status passed THEN 1 ELSE 0 END) * 1.0 / COUNT(*) AS stability_rate FROM cases c JOIN case_results cr ON c.case_id cr.case_id WHERE cr.is_retry 0 GROUP BY c.case_id HAVING COUNT(*) 5 ORDER BY stability_rate ASC LIMIT 20;实际使用中我会把这两张表放到同一个页面左侧高频、右侧低稳。不需要做复杂的图表一个简单的HTML页面加一个刷新定时器就够用。榜单旁边加两个附加字段平均耗时和最近一次失败时间帮助定位问题时快速判断是历史问题还是新引入的问题。4. 统计结果怎么用从排名表变成质量抓手4.1 高频用例暴露核心路径当榜单跑出来后你要先看的是高频执行用例。高频通常意味着这些用例被多条测试链路依赖或者在CI里被多个任务重复执行。这是好事说明核心路径有测试覆盖但也有另一面高频用例往往承担着“底层铺垫”的角色比如登录、创建订单、初始化权限这类前置操作。高频低稳的用例要格外重视。比如一条初始化数据的用例每天被依赖几百次只要它一挂下游用例全军覆没失败扩散面积非常大。如果你只按“模块”聚合看数据可能看到的是多个模块同时失败根本定位不到根因在同一个底层用例。这就是为什么我坚持要从用例维度做统计而不是只做模块维度。在治理上我一般把高频低稳的用例分成两类一类是代码逻辑确实不够健壮需要开发修另一类是测试数据复用导致互相污染需要测试自己解决设计问题。区分方法很简单看失败信息是断言失败还是执行异常。断言失败指向业务逻辑执行异常指向环境、数据、基础设施。4.2 稳定性二维矩阵把用例归类到优先级这是我最推荐的统计消费方式把“执行频率”和“首次执行稳定率”放到同一个二维矩阵里看。横轴是频率高低纵轴是稳定性高低所有用例可以落到四个象限高频高稳核心回归资产要重点保护任何改造都不能让它们变慢或变红。高频低稳紧急治理对象每天给研发团队造成最多噪音优先投入资源修复。低频低稳风险潜伏区虽然出现频率不高但每次出现都不可预测需要记录失败规律。低频高稳价值存疑可能只是在某个特殊场景下才被触发考虑是否合并到更大的用例里或者直接移除。实际操作的时候不需要每个用例都画散点图只要在榜单上把用例标记为四种类型之一。比如“高频低稳”标记为红色这些就是下个迭代要重点投入的对象。“低频高稳”标记为灰色它们可能是被遗忘的测试资产需要确认是否还有保留价值。4.3 测试集瘦身与回归策略调整统计做久了数据会告诉你一些反直觉的结论。比如有些用例高频高稳、几个月没出过问题但它们的价值可能非常低。一个用例如果能稳定通过几百次、但从没抓到过一次真正的缺陷那它大概率只是在证明“代码没变化”这件事。这种用例不是没用而是不需要每次都跑。基于执行统计数据你可以做三个决策第一对稳定且低价值的用例降低执行频率。比如从每个CR触发改成每天全量回归一次减少CI资源消耗。第二对不稳定但高价值的用例优先修复根因而不是加重试。很多团队遇到不稳定用例第一反应是加retry结果就像给病人吃止痛药症状消失但病根还在统计里的“执行次数”还会白白翻倍。第三对稳定率长期低于80%的用例要求提交者给出明确解释。如果没有合理理由考虑从自动回归集里暂时移除避免它反复消耗团队注意力。5. 常见问题排查实录为什么统计结论和直觉不一致5.1 执行次数虚高重试机制在捣鬼现象某条用例的执行次数明显大于同一周期内CI触发的构建次数甚至会超过构建次数的几倍。原因这是重试机制把同一个run里的多次执行都记录进去了。比如pytest-rerunfailures配置了reruns3一个失败用例在同一个构建里最多会产生4次执行记录统计时如果按记录数去数执行次数就会变成构建次数的4倍。解决方法是解析时做“同一run内按case_id去重”保留首次执行的记录把后续重试标记出来。5.2 用例标识漂移历史数据断层现象上周还在高频榜上的用例这周突然消失在列表里或者同一用例在不同模块下出现两个相似但不同的ID。原因用例标识直接用了类名方法名一旦有人重命名方法、调整包结构、改参数化数据标识就变了。更隐蔽的情况是排序问题参数化用例如果参数顺序变了生成ID时拼出来的字符串也会变。解决方法是把稳定业务标识比如接口路径、需求编号、手工用例编号作为统计主键的一部分同时在名单映射表里维护新旧ID的对应关系。5.3 并发执行归因难多台机器同时上报现象失败用例的run_id五花八门有些机器的结果晚到好几个小时导致“今日失败数”在下午和晚上查结果不一致。原因分布式执行时每台执行机各自生成了一个run_id或者统一run_id没有正确传递到所有执行机的结果文件中。解决方法是把run_id作为调度参数下发所有执行机的XML都写入同一个值。如果无法改造框架退而求其次可以按“调度批次开始时间CI构建号”两个字段联合识别同一轮执行。5.4 时间窗口不一致跨时区统计打架现象早上9点查询“昨天执行数据”显示不完整到中午才补全。原因CI服务器默认UTC时间测试结果文件里的timestamp是UTC而统计报表按本地时间比如UTC8做日期分组结果就是自然日数据被切到了两个不同的时间窗口。解决方法是统一在数据入库时把时间字段转成UTC存储报表查询时再显式转换到指定时区不要依赖系统默认时区。最后再聊一个我自己的体会。做这套统计最容易踩的坑是把“稳定”定义为“平均通过率高”。当你把同一个用例的首次执行成功率曲线按周拉出来你会发现很多“稳定”其实是数次失败被重试和平均公式掩盖后的假象。所以我后来给团队定的规矩很简单讨论用例稳定性的时候先回答三个问题——这个用例被纳入执行多少次首次通过率是多少最近一次失败发生在什么时候能回答上来再谈怎么优化。测试执行统计不是给测试用例做排名颁奖它是把测试的每一次呼吸记录下来让质量问题和工程效率问题都无处可藏。
