训练过程：让AI学会闻代码的“味道”说回模型本身。它的目标不是理解业务逻辑，而是学习“缺陷倾向模式”。我把这个模式拆成了三个维度。第一个维度是代码结构复杂度。圈复杂度、嵌套深度、函数长度这些硬指标是基础，但更关键的是“修改频次与缺陷的关联”。一个函数如果改 10 次有 7 次伴随缺陷修复，那它的结构大概率有问题。第二个维度是代码克隆率。如果一段代码是通过复制粘贴产生的，并且在不同模块里有轻微变体，它的缺陷概率会显著上升。因为当初的 bug 很可能也被复制了，只是还没暴露。第三个维度是注释与代码的一致性。我用了一个小模型来比对函数注释和实际实现。注释说“计算退款金额”，实际代码里却有扣减积分的逻辑，这种不一致是高危信号。训练数据是过去五年里 4300 多个缺陷修复的 commit，提取出每次修复前的“坏代码”和修复后的“好代码”，做成成对样本。模型结构就是 CodeBERT 做 backbone，后面接一个二分类头，输入是函数的 AST 序列化表示，输出是 0 到 1 的风险分。验证集上做到 0.79 的 precision 和 0.83 的 recall。不算惊艳，但作为辅助筛查工具足够了。模型发现的不止一个Bug，是一类反模式CTO 那坨代码被标出来之后，我顺着模型的高分结果继续排查，发现它不止找出一个具体问题。它实际上标记出了一类反复出现的反模式：“带误差容忍的浮点金额计算”。全仓库一共扫出 14 处类似模式，分布在对账、结算、优惠券分摊、运费计算四个模块里。其中 3 处已经暴过线上问题并被修复，剩下的 11 处里，有 5 处在特定条件下可以重现计算偏差。虽然大部分偏差在 1 分钱以内，但叠加高频业务场景后，部分月份的对账差异能累积到几百元。这类问题靠人工 review 几乎不可能全揪出来。因为它分散在多个模块，每个单独看都像是正常的容错处理，只有拉通全局才知道这是一个系统性的设计缺陷。一个缺陷是事故，一组同模式缺陷就是架构负债。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
发布于 辽宁
分享
评论
1
未登录
友善发言
评论
加载中
