做测试的人大多有个共同感受：平时在TMS测试管理系统里提交用例、执行用例、登记缺陷都很积极，可真到项目复盘要讲“这版本质量到底怎么样”时，往往只能翻出通过率和缺陷数量两个数字，草草应付过去。系统里积累了几个月甚至几年的测试数据，却很少有人能把它们变成能指导决策的结论。
这篇文章不绕弯子，直接讲TMS测试数据分析。我按“数据有哪些、指标怎么定、分析怎么做、坑怎么避”的顺序展开，适合刚接手质量度量工作的测试工程师，也适合想搭质量看板的测试负责人。内容基于我实际跟过的多个迭代版本，不一定适用每个团队，但思路和操作步骤大多能复用。
1. 先摸清楚TMS里到底存了哪些可用数据
很多团队分析不出有价值结论，第一个问题不是不会算，而是不知道自己的TMS里存了什么、哪些能用、哪些是脏数据。我见过不少人拿着一份导出的缺陷清单就开始做饼图，结果维度混乱，连“这个缺陷属于哪个版本”都分不清。所以数据分析的第一步，一定是盘点数据资产。
1.1 五类测试数据资产
TMS里最值得挖的数据，我习惯分成五类。
第一类是测试需求数据。TMS里通常维护了需求列表、版本号、需求状态，以及需求和用例的关联关系。别小看这个关联关系，它是分析需求覆盖率的前提。很多团队用例和需求没有挂勾，等于把最重要的分析入口堵死了。
第二类是测试用例主数据。包括用例编号、所属模块、用例优先级、自动化标记、用例步骤和预期结果。这部分数据更多用于理解“测试资产构成”，比如自动化用例占比、用例分布是否均衡、用例是否长期无人维护。它能回答“我们的测试覆盖从哪里来”这个问题。
第三类是执行记录。每次执行用例都会产生一条记录，里面有执行人、执行时间、执行状态、被执行的用例、测试环境、耗时等。执行记录是分析测试进度、执行效率、通过率的基础。可以说，这是整个TMS里信息密度最高、也最容易出错的一类数据。
第四类是缺陷数据。缺陷的标题、状态、严重程度、优先级、发现阶段、引入阶段、修复时长、被指派人、关闭时间等等，都在这里。缺陷数据直接影响质量结论和发布决策，也是大多数团队分析频率最高的一类数据。
第五类是版本与计划数据。测试计划、测试轮次、里程碑、基线版本等。这类数据提供了“切分窗口”，用来回答“这个版本的质量如何”“这轮回归相比上轮是否有改善”。
1.2 数据埋点质量决定分析上限
盘点数据资产时，还要顺带做一次数据质量体检。我吃过最大的亏，是发现阶段字段。某些同事习惯把“发现阶段”填成“功能测试”，另一些人填“系统测试”，还有人填具体的测试轮次名称，同一张表里十几种写法。等我要分析缺陷集中在哪个阶段时，根本统计不出来。
所以我的建议是：在做复杂分析之前，先把TMS里的关键字段枚举值标准化。发现阶段、严重程度、处理状态、用例执行状态这几类字段，能配置下拉框就不要允许自由填写。同时，尽量把必填字段做硬校验，不允许空值。拿异常数据量来粗略判断，如果一段时间的缺陷记录里，发现阶段为空或乱写的比例超过15%，就不要指望后续分析有多准确。
另外一个经常被忽视的动作，是保留历史基线。TMS里的字段定义和枚举值会随着流程迭代变化，比如后来新加了一个“性能测试”阶段。如果字段变化前不做好数据迁移或映射，历史数据就无法参与对比分析。简单来说，数据埋点质量决定了数据分析的上限。底层数据乱，上面做再好看的报表，本质上也是在制造新的混乱。
2. 指标怎么定：不骗人的度量口径
分析TMS数据，最终要落到指标上。直接堆指标是新手常见问题，今天我整理了4个通过率、明天又加一个缺陷激活率，看起来很多，但彼此没有逻辑关系，看完也不知道该做什么动作。真正有效的指标，必须满足两个条件：统计口径清晰，且对应一个可执行的管理动作。
2.1 质量类核心指标怎么算才对
用例通过率是使用率最高的指标，但很多团队的分母选错了。正确口径是：通过率 = 通过用例数 / 已执行用例数。注意分母是已执行用例，不是用例总数。比如测试包里有120条用例，计划全部执行，实际执行了100条，通过85条。通过率应该是85 / 100 = 85%，而不是85 / 120 = 70.8%。后者把未执行的部分混进来了，会同时惩罚“用例设计数量”“执行完整性”和“产品质量”三个因素，反而无法定位问题。
需求覆盖率这个指标，坑也不少。定义是：至少有一条例相匹配并被执行的用例所覆盖的需求数，除以当前版本的需求总数。经常有团队把“写了用例的需求”当成“被覆盖的需求”，这显然偏乐观。我习惯把覆盖率再分一档：通过需求覆盖率，指关联用例中有至少一条执行通过的需求占比。这样就能发现一种常见假象：覆盖是覆盖了，但执行全失败，需求实际处于不可交付状态。
缺陷密度建议谨慎使用。它通常等于缺陷总数除以代码行数或功能点数。代码行数不少团队统计不准确，所以我更推荐用“每功能点缺陷数”或“每100个测试工时缺陷数”。计算很简单，比如某个版本产生了45个有效缺陷，投入300个测试工时，则缺陷密度为15个/100工时。这个指标适合版本之间或模块之间做横向比较，但不能单独脱离上下文看。
猜缺陷有效率这个词很多人会忽略，它等于有效缺陷数除以提交缺陷总数。有效缺陷指明确被产品人员确认或最终被修复的缺陷，重复的、无法复现的、需求理解不一致的都不能算进去。如果一个团队缺陷有效率长期低于70%，说明需求沟通或测试准备环节出了问题，比纠结缺陷总数量更有诊断价值。
2.2 进度与效率指标：从趋势里读结论
执行进度直接反映测试活动是否按计划推进。口径是：已执行用例数除以计划执行用例数。这里有个细节，阻塞用例和跳过用例到底算什么？我的建议是单列，不要算入已执行，也不要用它去分母。否则团队为了“进度好看”，会故意把阻塞用例标记成通过，或者不停往后延迟计划。单独统计“阻塞数量”反而能暴露风险。
缺陷收敛趋势是衡量“能不能发版”的非常有用的窗口。只需要把每天的新增缺陷数和关闭缺陷数放到同一张图里观察。质量好转有一个典型特征：新增缺陷曲线抬头见顶之后回落，关闭缺陷曲线持续高于新增曲线。如果临近发布，新增和关闭两条曲线还在互相缠绕，发布风险就是高的。
剩余缺陷预测属于稍进阶的用法。你可以先按周统计近N周的新增缺陷，估算平均每日发现量，再乘上剩余测试天数，并按收敛趋势乘一个衰减系数。衰减系数不同团队差异很大，通常我取0.3到0.7，对应前期发现缺陷多、后期明显收敛的情况。需要强调，这只是一个粗略估算，它能用于判断“是否需要延长测试时间”，不建议作为精确承诺数据。
缺陷激活率，也叫重开率，等于重新打开缺陷数除以已修复缺陷总数。如果这个比例长期偏高，比如超过20%，那么修复质量或需求理解大概率存在问题。它是个容易被忽略但很有用的指标，特别是在自动化回归场景中，因为自动化执行里的重开多半意味着脚本判断逻辑有偏差。
2.3 一张看板指标矩阵示例
有了上面这些指标，可以整理成看板指标矩阵。以下是我常用的一套参考口径，注意每个团队的阈值要根据自己的数据和业务特性校准：
| 指标名称 | 统计口径 | 参考阈值 | 主要业务动作 |
|---|---|---|---|
| 用例通过率 | 通过用例数 / 已执行用例数 | ≥ 95% | 低于阈值则重点排查模块回归风险 |
| 需求覆盖率 | 有关联且执行的用例的需求数 / 需求总数 | 100%（准入） | 上线前必须补测未覆盖需求 |
| 缺陷有效率 | 有效缺陷数 / 提交缺陷总数 | ≥ 80% | 低于阈值则检查需求对齐流程 |
| 缺陷密度 | 缺陷总数 / 100测试工时 | ≤ 15 | 高于阈值则评估是否扩大测试范围 |
| 缺陷激活率 | 重新打开缺陷数 / 已修复缺陷总数 | ≤ 15% | 高于阈值则回溯修复质量 |
| 阻塞用例占比 | 阻塞用例数 / 计划执行用例数 | ≤ 5% | 高于阈值则推进资源协调 |
| 执行进度偏差 | 实际完成执行比例 - 计划执行比例 | ± 10%以内 | 偏差过大则调整测试安排 |
3. 从TMS取数到生成图表的完整实操路径
指标定好了，下一步就是把TMS里的原始数据变成可以用、可以复现的分析底表。我推荐的做法是“先取数、再清洗、后建宽表”，也就是说，不要让每个分析都回到TMS界面去手工查，而是把分析所需的字段提前整理成一张表，后续任何指标都能在这张表上快速算。
3.1 导出与清洗：先做一张宽表
如果TMS有开放的数据导出或数据库查询入口，直接查库是最理想的。比如我需要按版本、模块、用例、缺陷四个维度做分析，通常会写这样一段SQL，把执行记录和缺陷记录关联起来：
SELECT r.version, r.req_id, r.module_name, tc.testcase_id, tc.priority, tc.is_automated, e.execute_status, e.executor, e.execute_time, e.env_name, b.bug_id, b.severity, b.current_status FROM tms_execution e LEFT JOIN tms_testcase tc ON e.testcase_id = tc.testcase_id LEFT JOIN tms_requirement r ON tc.req_id = r.req_id LEFT JOIN tms_bug b ON b.testcase_id = tc.testcase_id WHERE e.execute_time >= '2025-01-01' ORDER BY e.execute_time;有几点需要解释。我特意用了LEFT JOIN，因为不是每条执行记录都对应缺陷，缺陷表里可能关联多个用例，结果会出现重复。后续清洗时，需要按主键去重。如果TMS界面没有直接查库能力，至少把用例执行记录、缺陷记录、需求清单分别导出，再用电子表格工具的VLOOKUP或数据模型关联起来。这一步虽然原始，但能把三份孤岛数据打通成分析底表。
数据清洗不能省。我在实践中会按顺序做四件事：第一，统一时间字段格式，比如把“2025/01/10”和“2025-01-10”改成同一格式；第二，状态枚举映射，比如把“已通过”“通过”“PASS”统一成“PASS”；第三，删除明显无意义的记录，比如执行时间在未来或执行人为空的垃圾记录；第四，对重复执行记录做去重，比如同一自动化用例在同一天跑了三次，应保留最后一次或单独说明。
3.2 用脚本做核心统计
有了宽表，用Python会比电子表格工具更高效、也更容易复现。下面这段代码是我常用的一组统计逻辑，读入CSV宽表，然后计算通过率、缺陷严重程度分布和模块缺陷TOP10：
import pandas as pd df = pd.read_csv("tms_execution_wide.csv") df["execute_status"] = df["execute_status"].str.upper() executed = df[df["execute_status"].isin(["PASS", "FAIL", "BLOCKED"])] passed = df[df["execute_status"] == "PASS"] pass_rate = len(passed) / max(len(executed), 1) * 100 print(f"用例执行通过率: {pass_rate:.2f}%") severity_dist = df.drop_duplicates(subset=["bug_id"]).groupby("severity").size() module_bug_top = df.drop_duplicates(subset=["bug_id"]).groupby("module_name").size().nlargest(10) print("缺陷严重程度分布:") print(severity_dist) print("模块缺陷TOP10:") print(module_bug_top)这里的关键细节是去重。一条缺陷可能关联多条执行记录，如果不按bug_id去重，缺陷数量就会虚高。计算缺陷相关指标时，先对缺陷ID去重几乎是强制操作。如果是分析每天的缺陷趋势，可以继续这样处理：
df["execute_time"] = pd.to_datetime(df["execute_time"]) daily_defects = df.drop_duplicates(subset=["bug_id"]).groupby(df["execute_time"].dt.date).size()拿到这些统计结果之后，建议统一输出成CSV，供后续报表使用，而不是每次都重新执行脚本。周报和月报数据源稳定，分析结论才能稳定对比。
3.3 形成可汇报的图表
图表不是越花哨越好。我总结的规律是：不同受众看不同图。给一线测试同学看，重点是缺陷清单、失败用例清单，用表格更直观；给测试负责人看，重点是趋势线、分布图，比如按周查看新增关闭缺陷趋势；给项目管理层看，重点是结论和风险，比如一张通过率、需求覆盖率、阻塞缺陷数的汇总卡片。
画图时，最常见的误区是过度使用饼图。当分类超过五个，饼图就很难读。用柱状图或条形图更清晰。缺陷严重程度分布、模块缺陷TOP10这类离散分类，柱状图是稳妥选择；新增与关闭缺陷随时间的对比，用折线图更直接。电子表格工具自带的数据透视表足够做90%的图，如果想自动刷新，可以接开源BI工具，把之前的宽表作为数据源，做成每次打开自动更新的看板，一劳永逸。
4. 数据分析避坑清单与排查实录
最后分享一些真正踩过的坑。这些坑不解决，分析结果容易被挑战，甚至被管理层一次性否决。
4.1 数据脏乱差的三类高发问题
我遇到过最典型的问题，是执行记录严重重复。特别是自动化任务配置不当的时候，一个用例在一小时内触发多次，导致通过率被干扰。排查思路很简单：先看执行时间和执行人的分布，同一用例同一天出现多次，就要处理。处理方式不是简单删数据，而是明确口径：一个用例在一个版本的一个执行轮次里，只保留最后一次正式执行结果。
第二类高发问题是状态字段混乱。有些团队执行失败后会额外标记“环境异常”“数据问题”“脚本问题”等自定义状态，这本身是好事，但如果你直接拿这些状态算失败，就会把产品缺陷和环境问题混在一起。我的建议是先做一个状态归类映射表：产品真实失败、脚本失败、环境失败、阻塞、跳过，各自对应哪些原始状态，再在统计口径里明确“失败只指产品真实失败”。
第三类问题是缺陷ID不唯一。同一个缺陷，测试人员提交后，产品又关闭再重建，会出现新旧单号指向同一问题。分析时如果不合并同类项，缺陷数量的趋势会突变。排查办法是看缺陷标题、模块和描述，人工合并明显重复的记录，并在后续流程中约定重复缺陷不允许新建单。
4.2 指标解读时的四个陷阱
第一个陷阱是横向乱比较。拿模块A的缺陷总数和模块B比，会觉得A质量差，但A可能功能点数是B的五倍。正确做法是先算缺陷密度，或者至少带上模块规模做对比。
第二个陷阱是混合测试轮次。冒烟测试、功能测试、回归测试、探索性测试的执行结果，本身的通过率基准完全不同。如果在统计时把所有轮次放在一起算整体通过率，会把一次失败的冒烟测试和完整回归测试的影响混在一起。最好按轮次分组，先看每轮内部的通过率，再看总体趋势。
第三个陷阱是忽略严重程度权重。只看缺陷总数，可能会出现100个轻微缺陷掩盖3个致命缺陷的情况。我建议在做发布判断时，把致命和严重缺陷单独统计，并设置硬性门槛。质量看板上，缺陷总数和严重缺陷数量必须同时出现。
第四个陷阱是统计周期的干扰。缺陷发现量在版本前紧、版本后少，是正常现象。如果拿最近两周的新增缺陷数去和上一个完整迭代的月度数据比，结论一定失真。做趋势分析时，请始终保持周期对齐。
4.3 自动化执行数据的特别提醒
自动化用例数据和手工执行数据不能粗暴混在一起算。自动化用例失败时，有一半以上是脚本问题、元素定位失败或环境问题，而不是产品缺陷。如果直接计入失败率，每周线上看板都会“报警”，时间长了团队就会对指标不敏感。
我建议自动化执行结果至少拆成四类：产品失败、脚本失败、环境失败、跳过。产品失败才计入质量口径，脚本失败和环境失败计入自动化维护成本。这个拆法看起来简单，但能避免大量无效分析。另一个容易被忽略的问题是“跳过即通过”，自动化用例因为依赖数据缺失被跳过，很多平台会把状态置为跳过，但统计时有人顺手把它归到通过里，这会直接污染通过率。
4.4 让数据分析真正用起来
避坑之外，更重要的是让数据分析活起来。我见过不少团队辛苦搭了看板，结果两周后没人再看，原因主要是指标没有对应到动作。我的经验是：每次质量看板上的指标变化，都必须跟着一个动作建议。通过率下降，动作是找出TOP失败模块并安排复测；阻塞用例占比偏高，动作是当天协同解决问题，而不是继续等。
另外，建议从小闭环开始。不必一开始就追求大而全的实时大屏，先跑通一份周报，每周固定时间由同一个负责人从TMS导出数据、刷新宽表、更新图表，再用同样的口径连续跑四周。四周之后，团队自然会发现口径漏洞、字段质量问题、指标误读问题，这时候再迭代看板，比一上来铺大工程要稳妥得多。
做数据分析的过程中，我体会最深的一点是：TMS里的数据本身不会说话，但如果度量口径统一、分析方法得当，它就能成为测试团队和项目管理层之间最有效的沟通语言。这比任何漂亮报表都重要。希望这篇基于实测经验的总结，能帮你少走一点我走过的弯路。
