测试运用AI定位隐性bug，落地难点在哪
前一段时间我们组上线了一个AI辅助bug定位的工具，用了两周我把它关了。我做测试开发六年，功能测试自动化测试性能测试全干过。隐性bug这个东西，说实话，一直是测试人的噩梦。你功能测试跑一百个用例全过，上线之后用户一操作，Corner case炸了。自动化测试覆盖了90%的路径，剩下10%就是那10%出事。所以我们引入了AI，想让它帮我们从日志和代码里挖隐性bug。理想很美好。喂进去报错日志和代码上下文，模型吐出来一堆可疑点。我一看，前三个全是误报。第四个倒是对了，但它推荐的修复方案把一段正常逻辑给标成了bug。跑了一周，准确率不到30%。我后来分析了一下，问题出在上下文。我们业务后端系统几十万行代码，跨了十几个微服务，一个请求链路七八跳。模型只看得到你喂的那一段，上下游全靠猜。就像让一个医生看病，只给你一张验血单，病历不给，影像不给，病史不给。你能看出个啥。后来我换了个思路，不让它直接定位bug，让它帮我分析自动化测试的覆盖盲区。就是把跑过的用例路径喂进去，让它找哪些分支组合没被覆盖到。这个稍微靠谱一点，能挖出一些遗漏的边界条件。但也就是一些边界条件，离"定位隐性bug"差得远。性能测试这边我也试了，把压测的火焰图丢给AI分析，它倒是能指出热点函数，但这些热点函数我本来就知道。落地最大的难点就一个字，context。你给它的上下文不够，它就是个瞎子摸象。你给它全量上下文，token费用直接爆炸，还超长上下文里它又容易丢信息。我们组现在还在摸索，用AI辅助生成测试用例可以，辅助定位隐性bug，目前还是个伪命题。可能模型再迭代两代吧。
发布于 山东
分享
评论
赞
未登录
友善发言
评论
加载中
