TESSY代码覆盖率怎么做，TESSY代码覆盖率统计口径如何统一，表面看是在做一次覆盖率统计，实际是在解决两类常见失真：一类是代码覆盖率数字好看但不可复现，同一套代码换台机器就变；另一类是团队各算各的口径，语句覆盖率、分支覆盖率、条件覆盖率混用，最后评审时只能解释不清。要把TESSY代码覆盖率做扎实，必须把覆盖采集的流程跑通，把统计口径在工程配置、过滤规则、报表输出三个层面统一起来。

　　一、TESSY代码覆盖率怎么做

　　TESSY里做代码覆盖率，建议先把覆盖率采集的边界和路径固定下来，再去追覆盖数字。覆盖率不是单独跑出来的报表，它依赖你的构建参数、插桩方式、测试执行入口与结果收集方式，只要其中一环不稳定，代码覆盖率就会出现偶发波动。

　　1、先明确你要统计的代码覆盖率类型与范围

　　(1)在项目层先约定本轮统计关注的覆盖项，常见有语句覆盖率、分支覆盖率、条件相关覆盖率等，避免不同人拿不同指标对比；

　　(2)明确统计范围是单个软件单元、单个模块还是整套组件，把范围写成可执行的清单，例如哪些源文件计入、哪些目录排除；

　　(3)把“测试桩、第三方库、自动生成代码”是否计入范围提前定好，否则覆盖率会被大量非业务代码拉低或拉高。

　　2、用同一套构建参数触发覆盖采集，避免口径漂移

　　(1)覆盖采集必须建立在稳定构建之上，编译器版本、语言标准、优化等级、宏定义开关要与团队约定一致，尤其不要一边开高优化一边要求覆盖率稳定；

　　(2)对条件编译较多的代码，先把关键宏开关固化为工程基线，确保采集的代码路径就是你要统计的那一版逻辑；

　　(3)如果团队有多套目标平台或多套编译链，先选定“覆盖率基线环境”，不要把不同环境的覆盖数据混在同一张统计表里。

　　3、把覆盖采集绑定到测试执行入口，确保每次运行都能收集到数据

　　(1)在TESSY里用固定的测试执行配置来跑测试与代码覆盖率，避免临时改执行选项导致漏采或重复采；

　　(2)执行前先确认测试对象与用例集合是你要统计的那一组，覆盖率统计最常见的错误是跑了A模块的测试却看B模块的覆盖报表；

　　(3)执行后第一时间检查覆盖数据是否生成且与测试结果一一对应，出现覆盖为0或明显异常时优先排查是否执行到目标代码、是否被过滤规则排除了。

　　4、导出覆盖报告前先做一次“覆盖有效性自检”

　　(1)抽查一两个关键函数，确认用例确实触发了关键分支，否则覆盖率高也可能是统计范围选错或过滤过度；

　　(2)对明显“永远到不了”的分支先判断是否死代码或受外部前置条件限制，必要时记录原因并决定是否上移到集成测试验证；

　　(3)在同一构建号下重复执行一次，验证代码覆盖率波动是否在可接受范围内，波动过大通常意味着依赖未隔离、输入不确定或执行路径受环境影响。

　　二、TESSY代码覆盖率统计口径如何统一

　　统一统计口径的目标，是让代码覆盖率成为可比较的数据，而不是每次开会都要解释“为什么我这里比你高”。口径统一要同时管住三件事：算什么、怎么算、算完怎么出报表。只统一其中一项，团队的覆盖率仍然会各说各话。

　　1、统一覆盖指标定义，避免同名不同义

　　(1)明确团队主指标是语句覆盖率还是分支覆盖率，是否需要同时输出多项指标，输出顺序与解释口径固定；

　　(2)对条件相关覆盖率要写清定义边界，例如是否把复合条件按子条件拆分统计，避免不同项目成员用不同理解；

　　(3)把指标定义写进测试规范或质量门槛说明，后续版本评审只按这份定义判定，不再临时改口径。

　　2、统一构建与插桩基线，覆盖率才会稳定可复现

　　(1)编译器版本、优化等级、宏定义集合、链接方式要形成基线配置，覆盖率统计必须使用该基线，否则不同编译输出会导致覆盖点数量变化；

　　(2)对同一模块的不同分支，先确认是否存在宏开关差异导致代码结构变化，结构变化会让覆盖率对比失去意义；

　　(3)把基线配置做成模板工程或公共配置包，新模块直接复用模板，减少“每人一套配置”的漂移。

　　3、统一计入与排除规则，避免被非业务代码干扰

　　(1)明确哪些目录或文件类型默认排除，例如第三方库、工具生成文件、仅用于测试的桩代码，排除规则写成团队统一清单；

　　(2)对需要保留但会影响覆盖的代码类型给出处理方式，例如只统计接口层还是也统计底层驱动层，避免统计范围每次换；

　　(3)对确实无法覆盖的代码段要有可审核的记录方式，写清原因、影响范围与替代验证手段，避免用“先排除掉”掩盖真实缺口。

　　4、统一报表结构与命名，方便纵向对比与审计追溯

　　(1)报表必须包含模块范围、构建号或提交号、编译链信息、覆盖指标汇总与明细入口，保证拿到报表就能定位上下文；

　　(2)报表输出路径与文件命名规则固定，例如按模块名与构建号归档，避免覆盖率报表散落在个人电脑；

　　(3)汇总表与明细表字段固定，覆盖率统计口径一旦定下，后续版本只更新数据不改字段，否则历史对比会断层。

　　三、TESSY代码覆盖率结果怎么做版本对比

　　把代码覆盖率做出来只是第一步，能不能用覆盖率推动质量提升，取决于你是否能把不同版本的覆盖结果稳定对比，快速定位“覆盖跌了是哪里跌、为什么跌、要补什么测试”。版本对比做不好，覆盖率就会变成一次性的数字展示。

　　1、先建立覆盖率基线版本，后续对比才有参照

　　(1)选定一个通过门槛与用例集合完整的构建作为基线版本，基线版本的覆盖报表与配置快照要一起归档；

　　(2)基线的统计范围与排除规则固定，后续版本沿用同一套规则，否则对比结果会被口径变化污染；

　　(3)基线版本最好对应一次明确的里程碑交付，便于评审时解释覆盖率提升或下降的背景。

　　2、用同一套用例集合跑回归，区分覆盖下降的真实原因

　　(1)先用基础回归集跑覆盖率，确保版本之间对比的是同一组测试驱动的执行路径；

　　(2)覆盖下降时优先判断是代码新增导致分母变大，还是关键分支未被触发导致分子变小，两类问题的补测策略不同；

　　(3)对改动点模块增加变更回归集，用例只围绕改动接口与新增分支补齐，避免为了追数字盲目堆用例。

　　3、把门槛与对比规则固化到交付节奏里

　　(1)定义最低覆盖率门槛与允许波动区间，并规定触发补测的条件，避免每次评审临时定标准；

　　(2)对覆盖缺口形成清单，清单至少包含文件、函数或分支点位与对应补测计划，让行动项可落地；

　　(3)将覆盖率报表与测试结果一起作为版本产物归档，保证后续审计能复核同一次测试与同一次代码覆盖率来源一致。

　　总结

　　TESSY代码覆盖率怎么做，TESSY代码覆盖率统计口径如何统一，落地要点可以收敛为三句话：先用稳定的构建基线与固定的测试执行入口把代码覆盖率采集跑通；再把覆盖指标定义、构建插桩基线、计入排除规则与报表结构统一起来；最后以基线版本为参照做版本对比，把覆盖下降定位到具体改动与具体分支，用补测清单推动测试与单元测试持续完善，覆盖率才会真正为质量服务。