来源｜TesterHome社区
作者（ID）｜AMEAME
如何基于AI大模型进行精准测试，本文由 AMEAME 同学在TesterHome社区网站的分享。
一、问题提出
1.如何使用大模型解决日常工作中难以解决的问题？
2.大模型在自动化测试领域可以发挥什么作用？
3.如何利用大模型提前发现故障，并提升产品质量？
4.如何发现日常工作中难以察觉的故障？
团队现状：
A. 经常性的泄露一些修改 java 依赖引发的故障，在 maven 的 pom.xml 文件中修改一个依赖的版本号都可能引出故障
此类型的问题难以发现的原因：
-
方案层面：评估此类版本依赖修改成本较高，因为一项依赖的修改可能牵扯很多代码；
-
开发层面：因修改 pom.xml 文件依赖版本号操作小，无代码逻辑修改，开发自测场景不完整；
-
测试层面：QA 不了解具体代码和波及影响，很难确定测试范围，不知道哪些功能需要使用这些依赖；
-
自动化层面：通过自动化扫描异常日志，日志中存在大量干扰，导致自动化异常扫描精度不高；
-
成本高：即使评估出测试功能点，方案评估，开发实现，测试验证整个流程成本较高。
B. 没办法对所有的新增代码进行 CodeReview，Review 的效果一般，容易泄露在功能测试阶段无法发现的问题。
因此，针对上述原因，将大模型与当前自动化测试相结合，通过大模型自动化来防护此类问题就是本实践的目标。
二、解决思路
虽然该类问题难以发现，但也并不是毫无办法。
该类问题有个共同点：在 JVM 运行时，找不到某个依赖，会抛出：ClassNotFoundException，NoClassDefFoundError，IllegalAccessException，InstantiationException，NoSuchMethodError 等异常。
那我们收集到组件日志后是否就能规避这种问题呢？
答案肯定是不行的。举个例子：
例如团队内组件热部署探针运行在框架中，在热部署探针启停阶段，因探针在框架中提交的线程还在轮询，探针实例已经被销毁后，依旧会出现很多上面的异常来干扰判断，无法得出精确的结果，所以需要从提升精度的方向去优化。
以下是思考方向：
1.故障多出现于代码修改前后。
2.不同分支代码的差别可能导致新故障的出现。
如何去解决呢，想了以下几点：
1.如果能获取到 git 上面的代码提交记录，就能收集到热点代码。
2.能拿到不同分支代码的变化，就能收集到另一部分的热点代码。