4. 人的因素 —— 有些哥们儿写的代码就是自带“气场”关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集我们给每个提交者算了一个开发者缺陷注入率：此人过去半年提交中，引入过线上故障的比例。这个值不是固定不变的，会按时间衰减，最近一次闯祸加权最高另外还加上提交者入职时长（新人前 3 个月是故障高发期）这次改动是否他首次接触该模块（首次触达 + 高复杂度，基本等于点炮）当时组里有个实习生，能力很强但业务不熟，模型给他的 MR 几乎每次都标高。头两个月他很不爽，后来真出过两次 P1 故障，他主动请我们吃饭，说“这玩意儿比我 Code Review 靠谱”5. 过程质量 —— 代码评审时就已经露出马脚了CR 评论总数、提出问题的评论数是否有“需要修改”的 CR 意见被作者忽略直接合入（这个极狠，一旦出现，风险分至少拉高 30%）关联需求变更次数（提测期间需求还在变的，Bug 率明显更高）这些特征从 GitLab/Jira 的 API 里都能抓到。我们把它们拼成一张宽表，一条 commit 一行，大概 60 多个特征，最后模型训练全用这个四、模型选型：别整花活，树模型能打十年我们也试过把 code diff 扔进 TextCNN、CodeBERT 里学语义，效果一言难尽——有时候它会给“修了个文案”的 MR 打高分，因为训练语料里很多故障 commit 也改了文案。纯粹捣乱最后老老实实用 LightGBM。快、稳、可解释性好，几千个 commit 几分钟训完，AUC 能做到 0.82~0.85（看业务线），已经完全够用了随手贴一段我们核心训练的骨架，脱敏后的伪代码五、怎么让开发信你？SHAP 可解释性是你唯一的武器光报个“高风险”三个字，研发迟早会骂你是算命先生。我们一开始吃过亏，被人在周会上当面质疑：“凭什么说我的 MR 有风险”后来我们上了 SHAP，给每一个预测结果附上归因。MR 详情页里会显示：“本次变更风险评估为 高，主要因为：【修改文件历史故障密度高】、【开发者当前迭代首次接触该模块】、【圈复杂度增量达 12】”这玩意儿一上，风向立马变了。研发看完不是甩锅，而是主动去优化那坨高复杂度代码。有个客户端大佬看到 SHAP 归因里“圈复杂度”排第一，直接重构了播放器模块，后面三个迭代该模块故障清零。这个结果比任何模型指标都有说服力
发布于 辽宁
2
评论
赞
未登录
友善发言
评论
加载中
