程序员吐槽写完代码还要写测试，让AI来干这事靠谱吗？
代码写完了居然还要写测试，难道就不能叫 AI 直接顺手就把这些活都给干了吗？这恐怕是过去一年当中啊，程序员群里出现的频率最高的那种吐槽了。那么我们是为了能够给出真实存在的那个答案，所以才特意去拉来了两个不同的项目，就是一个已经上线三年时间的 Boot 订单系统，它的代码量呢总计有 8 万行之多，还有另外一个刚刚才开始起步的C# 金融计算库，它的代码量是 5 千行。之后呢我们还分别采用了 、 Cover 以及 Lynx 自带的测试生成功能，把这两个项目都跑了一遍呐，最后还专门去算了一笔关于人力方面的账 。
先去看老的系统，在传统的做法之下，四位资深的工程师去补单元测试，两周的时间写完了2100条用例，行覆盖率达到了71%，然而分支覆盖率仅仅只有52%，边界异常场景大量存在缺失，随后我们将Cover打开，让AI在同样的代码上面跑一整个通宵，第二天得到了4300条用例，行覆盖率为89%，分支覆盖率为78%，直接将漏网的分支补上了一大半 。最为关键重要的是，AI所生成的用例当中，涵盖包含着大量诸如“空订单” “负金额” “并发改价”此类这般人类极易容易被忽视忽略的异常场景情况，从而省却省略节省掉了大量的脑力消耗风暴时间， 。
再瞧一瞧新系统，小团队起初是规划派三位人员以人员工作日来手写三百条用例，然而却运用Lynx，仅仅花费一杯咖啡的时长就生成了二百七十条，其中直接能够使用的有二百三十条，剩下的四十条由于业务规则存在特殊性故而需要进行细微调整，实际测试运行一通，代码覆盖率从百分之零径直飙升至百分之九十五，和人工方案保持一致，不过时间却从三人日被压缩至零点二人日，差不多把成本削减为原来的十分之一 。
是不是就此 AI 封神，我们将测试报告拿去给测试经理老周，他一眼便挑出了两个误报呢：AI 把“永远不会出现的日期格式”当作边界值处理，并且还把一条已废弃的接口仍旧写进断言之中，换而言之，AI 的“准确率”在语法层面上接近 100%，然而在语义层面仅能算作 80%左右呀，尤其是在复杂依赖以及多线程环境之下，AI 常常会把 Mock 对象配错，会导致测试得以通过但生产环境却出现状况哦。所以，行业内通常的做法是，“AI 承担粗筛工作，人类进行精修”，恰似通过洗衣机先去除 80% 的灰尘，而后手动搓洗领口袖口。
在报告里给出的数字也证实了这一点 ：AI 可以提升单元测试效率，使得平均提高百分之八十 ，还推动了覆盖率，使之升高二十到三十个百分点 ，然而“断言正确性”依然需要人工来完成 。也就是说 ，AI 最了得的是将“不实施测试”转变为“开展些许测试”，而非是“构建全然完善的测试” 。
最终，我们将两套方案同时上线去跑CI，接着发现，AI生成的用例在回归阶段展现出亮眼表现，具体是，代码一旦改动，AI能够在30秒内进行增量补测，然而人类通常需要花费半天时间来重新梳理逻辑，随后老周发出感叹，他说 AI并不是用于替代大家，而是促使大伙把精力从“编写100条平凡测试”转换为“密切关注10条核心业务路径”，最后，测试工作的金字塔并未倒塌，只是AI把塔基垫高了，进而使得人类能够站在更高地方来盯着塔尖
因此，要是你询问由AI生成的单元测试，其覆盖率可达到多少呢，答案是超过90%；那准确率又能达到多少呢，起步是80%，经过人工兜底之后会逼近100%。节省下来的时间，足够你再去编写一段真正具备趣味性的代码，或者，能够早点下班。
欢迎 你 发表评论: