Created
Aug 20, 2024 12:26 AM
Favorite
Favorite
Priority
备注
推荐
🌟🌟🌟🌟🌟
类型
模型测试
来源｜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.能拿到不同分支代码的变化，就能收集到另一部分的热点代码。
然后还有最重要的一点，收集的异常信息和热点代码的映射如何建立呢？如果手动去建立 异常->依赖 的映射始终会滞后，出一次问题加一次不利于可持续发展，而且只有当在出问题时才能知道抛出的异常长什么样，难以完成该项目。
所以引入了大模型去帮我完成 异常->依赖 的建立。
三、实践过程
架构概述
实践过程采用了以下架构：
1.数据源层：项目组件运行在大环境下，利用大环境提供的基本数据源。
2.代码变更获取层：从 Git 仓库中获取代码变更信息，包括同分支增量对比和不同分支全量对比。
3.日志处理层：通过日志收集模块处理组件日志，提取异常信息。
4.AI 大模型交互层：向 AI 大模型提出针对性问题，并解析其回答。
5.结果处理与输出层：根据 AI 大模型的回答在缓存中寻找热点代码，记录日志，并发送邮件通知对应处理人。
针对pom.xml的实践步骤
1.获取大环境数据源：项目组件运行在大环境下，利用大环境提供的数据源进行后续操作。
2.获取代码变更：
- 从 Git 中获取 XX 项目 XX 分支的 XX 个提交记录。
- 遍历每个提交记录，获取修改的文件列表。
- 过滤出 maven 依赖类型的文件（如 pom.xml）。
3.解析修改文件：
- 对修改的文件进行分类处理，包括只增、只减、修改三种类型。
- 解析出代码修改内容，并将其缓存起来，作为热点代码。
4.日志处理：
- 通过日志收集模块下载组件实例的日志文件（包括.log 和.gz 格式）。
- 解压 gz 格式的日志文件，并将不同实例的日志进行汇总。
- 将日志按照级别（info, warn, error）进行分类。
- 提取 warn 和 error 级别日志中的异常堆栈信息。
- 对堆栈信息进行去重处理，减少后续处理的冗余数据。
5.与 AI 大模型交互：
- 根据提取的异常信息，向 AI 大模型提出针对性问题。
- 解析 AI 大模型的回答，获取可能的故障原因或解决建议
6.热点代码匹配与记录：
- 使用 AI 大模型的回答在缓存的热点代码中寻找相关匹配项。
- 如果找到匹配项，记录相关日志信息，包括匹配的热点代码和异常信息。
7.发送邮件通知：
- 将记录的日志信息整理成邮件格式。
- 发送邮件到对应处理人的邮箱，通知其关注并解决相关问题。
针对java文件的实践步骤
1.获取大环境数据源：同样利用大环境提供的数据源。
2.获取指定需求编号的代码变更：
- 从 Git 中获取指定需求编号的提交记录。
- 遍历每个提交记录，获取修改的文件列表。
- 过滤出.java 文件。
3.解析修改文件：
- 对修改的.java 文件进行类似 pom.xml 的解析操作。
- 分类处理只增、只减、修改的代码，并缓存热点代码。
4.与AI大模型交互：
- 根据需求背景和修改内容，向 AI 大模型提出针对性问题。
- 解析 AI 大模型的回答，获取可能的代码风险或优化建议。
5.结果输出：
将AI大模型的回答或解析结果输出到文件中，便于后续查看和分析。
通过上述实践过程，可以有效结合 AI 大模型与自动化测试技术，提升故障发现和产品质量的能力。同时，减少了人工审查和测试的工作量，提高了工作效率和准确性。
效果评价
针对pom.xml如下：
1.运行自动化测试用例，测试用例会从 git 库中获取指定项目指定分支的代码提交记录，进行解析和缓存。
- 在代码配置每个标签中的子标签，如需解析其他的标签，则新增一个标签类并重写查找该标签的正则表达式
- 按照新增或删除的配置和修改的配置（修改可能只会改一个结构体的一部分，需要找到对应完整的结构体）进行解析
- 缓存解析结果
2.收集环境上日志，拿到原始日志后进行分类
- 先把容器内的日志拷贝到节点上，通过 SSH 协议把日志下载到运行环境。组件可能有多个实例，获取所有实例日志。
- 把 GZ 日志包进行解压，对日志内容进行分类（info, warn, error），按照配置文件配置的异常类型在 warn 和 error 日志中进行查找
- 可能某些异常日志会很多（几个 G 日志），不方便查看，所以下面进行去重。
3.通过一些对字符串的算法，把 java 异常堆栈进行去重，同种类型的异常只保留一个，方便人工查看和邮件推送
4.把解析好异常堆栈向大模型提问，自定义模板的大模型提问见下：
出现以下异常是缺少什么 maven 依赖: java.lang.ClassCastException: XXXXXX
大模型回答：
这个问题可能是由于你的项目缺少了 CGLIB 库引起的。你可以尝试在你的 pom.xml 文件中添加以下依赖：
然后运行 mvn clean install 以重新构建你的项目并下载所需的依赖:
解析出答案中的依赖 groupId 和 artifactId 等关键字段，把解析出的依赖在热点代码中查找，找到了说明大概率引出故障！
针对java文件的自动化大模型CodeReview
实践过程
1. 运行自动化测试用例
测试用例会从 git 库中获取指定项目指定需求编号的代码提交记录，进行解析和缓存。
- 把每个 java 文件拿到后，把代码解析成抽象语法树（AST）。
- 依次解析各个节点，如 Class, Package, Import, Implement, Constructors, Field, Method 等。
- 对解析结果进行缓存，以便后续快速访问。
2. 并发请求 AI 大模型进行 CodeReview
获取需要使用的 Method 信息，以最大并发 20 的限制去请求 AI 大模型。以下是 prompt 模版的示例：
3. 写入评审结果
把 AI 大模型返回的 CodeReview 结果写入文件，方便后续查看和分析。
评审结果
这段代码线程泄露的问题当时没有测试到，从而在春节的时候泄露到外场去了 ，导致开发在春节还在排查问题。
还有一个问题是在修改后，通过大模型评审发现的，就是方法中 new 了个非线程安全的 List，并且线程池提交的多个线程都传入了这个 List，在处理逻辑中又进行了 add 的操作，所以可能会导致数据最后 add 少了或者直接抛出异常。
这些问题虽然很基础，但是如果没有进行代码走查，其实通过黑盒测试很难发现这两个问题，还是体现了该工具产生的价值！
4. 推送邮件
把评审风险为中或者高的结果推送到相关人员进行进一步的人工评审。
优势与效果
通过自动化进行大模型 CodeReview，可以显著减少人工审查的时间和成本，提高代码质量和安全性。在分钟级的时间内就能完成需求或故障修改的大模型 CodeReview，极大地提升了开发效率和代码稳定性。同时，通过并发请求AI大模型，可以充分利用计算资源，进一步提高审查速度。
点击文末“阅读原文”，可进入TesterHome社区帖子，与作者交流～
将于2024年7月20日在上海举办的MTSC2024第十三届中国互联网测试开发大会，7折优惠购票限期发售中！