② 窗口期要卡死。一个 commit 上线后，到底观察多久没出事才算负样本？我们试下来，双周迭代下，观察 10 个自然日比较稳。有些模块上线后三天才因为定时任务暴露问题，窗口太短会把大量“还在路上”的 Bug 标成负样本，污染训练集。③ 别做“一视同仁”的随机采样。业务代码里，不出事的变更占了 95% 以上。如果你直接全量丢进去，模型会学到一招绝技：永远预测低风险，准确率贼高，屁用没有。我们后来做了下采样，让正负样本比例控制在 1:5 左右，同时给正样本加高权重，模型才学会认真对待那些危险信号。三、真正值钱的不是算法，是这一把特征抖音的代码库极其庞大，业务线几十条，语言主要是 Java/Kotlin/Go/C++。我们设计特征的时候只有一个原则：让不懂模型的人看了也觉得“有道理”。否则你推不动，研发老大会觉得你在搞玄学。我们最终沉淀出五类特征，每一条都是跟开发、测试反复扯皮磨出来的：1. 变更规模 —— 越大越容易出事，但有个例外新增行数、删除行数、总修改行数涉及文件数、涉及目录数是否改了底层库（如网络层、存储层）：单独的布尔特征，改了直接 +20% 风险分起步例外是什么？纯 import 整理和格式化代码。这种变更动辄几百行，但几乎零风险。我们后来用正则扫 diff 内容，如果 90% 以上的改动行只是空白/缩进/import 替换，就直接压权重。2. 代码复杂度 —— 你写的圈复杂度，最后都变成锅改动代码块的最大圈复杂度是否新增了嵌套超过 3 层的 if/for是否修改了已有高复杂度函数（圈复杂度 > 15 的老代码）这个特征抓“屎山上的新包”非常准。有一回直播推荐模块一个小 MR，只改了 5 行，但扎在一个 1200 行、圈复杂度 38 的老函数里。模型直接给了高危。开发不信，结果上线当晚缓存击穿，故障单编号我到现在都记得。3. 历史债 —— 这文件/这模块以前老出事，现在大概率还有事该文件过去 90 天线上故障触发次数该模块（目录粒度）最近 3 次迭代的 Bug 密度上次该模块出故障距今的天数（越近越危险，因为可能修了又引入新问题）本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
发布于 辽宁
9
评论
3
未登录
友善发言
评论
加载中
