AI测试｜基于AI大模型的精准测试分享-优快云博客

如何基于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 文件中添加以下依赖：

<dependency>
<groupId>cglib</groupId>
<artifactId>cglib</artifactId>
<version>3.3.0</version>
</dependency>

然后运行 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 模版的示例：

## 角色：代码评审专家
## 背景: 你是一位java语言专家级工程师，具备出色的代码审查能力，能够从多个方面评审代码。
## 任务: - 对指定代码进行系统化地审查。
## 任务细节: 对代码能够从以下方面进行逐一审查：
- 逻辑漏洞：评审代码逻辑是否有缺陷。遵守要求:排除因为没有判空而导致的空指针异常等，不评审因没有判空等而导致的漏洞，不进行入参为空的校验。
- 代码结构：评审代码结构是否清晰、易于理解，变量和函数的命名是否规范。
- 函数实现：评审函数实现是否正确、高效、安全，是否存在潜在的内存泄漏。
- 异常处理：评审异常处理机制是否完善，是否存在可能引发异常或崩溃的代码。
- 数据结构：评审代码中使用的数据结构是否合理，是否能满足实际需求。
- 性能优化：评审代码中是否存在性能瓶颈，是否有不必要的计算和调用等问题，是否可以进行优化。
- 资源泄露：评审代码中是否存在资源泄露，是否有文件流、线程池等未关闭情况。
- 安全性：评审代码中是否存在安全漏洞，是否有防止SQL注入、XSS攻击等安全机制。
- 可读性：评审代码是否清晰易于读懂，注释是否充分、准确、规范。
## 任务输出: 评审代码存在的问题，并输出代码风险等级
## 待评审代码
[这里插入待评审的Java方法代码]

3. 写入评审结果

把 AI 大模型返回的 CodeReview 结果写入文件，方便后续查看和分析。

评审结果

代码走查报告
一、逻辑漏洞
在XXX方法中，XXXList values = new XXXList();被初始化为一个单例，然后在多线程环境下被多个线程共享。这可能导致线程安全问题，因为多个线程可能同时修改values的内容。根据方法内的使用情况来看，每个线程应该处理自己的XXXList实例，而不是共享一个。
countDownLatch.await();在调用时未设置超时时间，如果某个线程因为异常或其他原因未能执行countDown，那么主线程将永远等待下去，造成程序阻塞。
二、代码结构
代码结构基本清晰，但是使用了裸线程池和CountDownLatch，使得代码在并发控制上稍显复杂。建议使用更高级的并发工具，如CompletableFuture，以简化代码。
变量命名较为规范，但XXX方法作为lambda表达式中的匿名内部类调用，其参数列表过长，可以考虑封装成对象来传递。
三、函数实现
executor.submit中捕获了所有异常，但只是打印了日志，没有重新抛出或者对异常进行处理，这可能会导致调用者无法得知操作是否成功。
使用了CopyOnWriteArrayList来作为结果集合，这个数据结构适合读多写少的场景。然而，在本例中，写操作（添加元素）频繁发生，这可能会导致性能问题，因为每次写操作都会复制底层数组。如果并发写操作不多，可以考虑使用其他并发集合，如ConcurrentLinkedQueue。
四、异常处理
异常处理机制不完善，如上所述，捕获异常后只是打印了日志，并没有合适的错误处理逻辑。
五、数据结构
CopyOnWriteArrayList的选择可能不是最佳的数据结构，如上所述，它可能不适合写操作频繁的场景。
六、性能优化
由于使用了CopyOnWriteArrayList，且写操作频繁，可能会导致性能问题。建议考虑其他数据结构或并发控制策略。
线程池中的核心线程数设置为1，可能无法充分利用多核CPU资源，如果处理逻辑不是IO密集型的，考虑增加核心线程数。
七、资源泄露
代码中创建了线程池，但未在方法结束时关闭线程池。这可能导致资源泄露，因为线程池会一直存在，即使方法执行完毕。建议在方法结束时关闭线程池，或者使用try-with-resources语句（如果线程池实现了AutoCloseable接口）。
八、安全性
代码中未看到明显的安全漏洞，如SQL注入或XSS攻击，但需要注意XXX和XXX方法内部是否有可能引入安全问题。
九、可读性
代码整体可读性较好，但并发控制和异常处理部分可以进一步简化，以提高可读性。
代码风险等级
综合上述评审，代码存在逻辑漏洞、资源泄露等问题，风险等级评定为中等偏高。建议对上述问题进行修复，以提高代码的健壮性和性能。

这段代码线程泄露的问题当时没有测试到，从而在春节的时候泄露到外场去了，导致开发在春节还在排查问题。

还有一个问题是在修改后，通过大模型评审发现的，就是方法中 new 了个非线程安全的 List，并且线程池提交的多个线程都传入了这个 List，在处理逻辑中又进行了 add 的操作，所以可能会导致数据最后 add 少了或者直接抛出异常。

这些问题虽然很基础，但是如果没有进行代码走查，其实通过黑盒测试很难发现这两个问题，还是体现了该工具产生的价值！

4. 推送邮件

把评审风险为中或者高的结果推送到相关人员进行进一步的人工评审。

优势与效果

通过自动化进行大模型 CodeReview，可以显著减少人工审查的时间和成本，提高代码质量和安全性。在分钟级的时间内就能完成需求或故障修改的大模型 CodeReview，极大地提升了开发效率和代码稳定性。同时，通过并发请求AI大模型，可以充分利用计算资源，进一步提高审查速度。

这两年，IT行业面临经济周期波动与AI产业结构调整的双重压力，确实有很多运维与网络工程师因企业缩编或技术迭代而暂时失业。

很多人都在提运维网工失业后就只能去跑滴滴送外卖了，但我想分享的是，对于运维人员来说，即便失业以后仍然有很多副业可以尝试。

网工/运维/测试副业方向

运维网工，千万不要再错过这些副业机会！

第一个是知识付费类副业：输出经验打造个人IP

在线教育平台讲师

操作路径：在慕课网、极客时间等平台开设《CCNA实战》《Linux运维从入门到精通》等课程，或与培训机构合作录制专题课。
收益模式：课程销售分成、企业内训。

技术博客与公众号运营

操作路径：撰写网络协议解析、故障排查案例、设备评测等深度文章，通过公众号广告、付费专栏及企业合作变现。
收益关键：每周更新2-3篇原创，结合SEO优化与社群运营。

第二个是技术类副业：深耕专业领域变现

企业网络设备配置与优化服务

操作路径：为中小型企业提供路由器、交换机、防火墙等设备的配置调试、性能优化及故障排查服务。可通过本地IT服务公司合作或自建线上接单平台获客。
收益模式：按项目收费或签订年度维护合同。

远程IT基础设施代维

操作路径：通过承接服务器监控、日志分析、备份恢复等远程代维任务。适合熟悉Zabbix、ELK等技术栈的工程师。
收益模式：按工时计费或包月服务。

网络安全顾问与渗透测试

操作路径：利用OWASP Top 10漏洞分析、Nmap/BurpSuite等工具，为企业提供漏洞扫描、渗透测试及安全加固方案。需考取CISP等认证提升资质。
收益模式：单次渗透测试报告收费；长期安全顾问年费。

比如不久前跟我一起聊天的一个粉丝，他自己之前是大四实习的时候做的运维，发现运维7*24小时待命受不了，就准备转网安，学了差不多2个月，然后开始挖漏洞，光是补天的漏洞奖励也有个四五千，他说自己每个月的房租和饭钱就够了。

为什么我会推荐你网安是运维和网工测试人员的绝佳副业&转型方向?

1.你的经验是巨大优势: 你比任何人都懂系统、网络和架构。漏洞挖掘、内网渗透、应急响应，这些核心安全能力本质上是“攻击视角下的运维”。你的运维背景不是从零开始，而是降维打击。

2.越老越吃香，规避年龄危机: 安全行业极度依赖经验。你的排查思路、风险意识和对复杂系统的理解能力，会随着项目积累而愈发珍贵，真正做到“姜还是老的辣”。

3.职业选择极其灵活: 你可以加入企业成为安全专家，可以兼职“挖洞“获取丰厚奖金，甚至可以成为自由顾问。这种多样性为你提供了前所未有的抗风险能力。

4.市场需求爆发，前景广阔: 在国家级政策的推动下，从一线城市到二三线地区，安全人才缺口正在急剧扩大。现在布局，正是抢占未来先机的黄金时刻。

网工运维测试转行学习网络安全路线

在这里插入图片描述

（一）第一阶段：网络安全筑基

1. 阶段目标

你已经有运维经验了，所以操作系统、网络协议这些你不是零基础。但要学安全，得重新过一遍——只不过这次我们是带着“安全视角”去学。

2. 学习内容

**操作系统强化：**你需要重点学习 Windows、Linux 操作系统安全配置，对比运维工作中常规配置与安全配置的差异，深化系统安全认知（比如说日志审计配置，为应急响应日志分析打基础）。

**网络协议深化：**结合过往网络协议应用经验，聚焦 TCP/IP 协议簇中的安全漏洞及防护机制，如 ARP 欺骗、TCP 三次握手漏洞等（为 SRC 漏扫中协议层漏洞识别铺垫）。

**Web 与数据库基础：**补充 Web 架构、HTTP 协议及 MySQL、SQL Server 等数据库安全相关知识，了解 Web 应用与数据库在网安中的作用。

**编程语言入门：**学习 Python 基础语法，掌握简单脚本编写，为后续 SRC 漏扫自动化脚本开发及应急响应工具使用打基础。

**工具实战：**集中训练抓包工具（Wireshark）、渗透测试工具（Nmap）、漏洞扫描工具（Nessus 基础版）的使用，结合模拟场景练习工具应用（掌握基础扫描逻辑，为 SRC 漏扫工具进阶做准备）。

（二）第二阶段：漏洞挖掘与 SRC 漏扫实战

1. 阶段目标

这阶段是真正开始“动手”了。信息收集、漏洞分析、工具联动，一样不能少。

熟练运用漏洞挖掘及 SRC 漏扫工具，具备独立挖掘常见漏洞及 SRC 平台漏扫实战能力，尝试通过 SRC 挖洞搞钱，不管是低危漏洞还是高危漏洞，先挖到一个。

2. 学习内容

信息收集实战：结合运维中对网络拓扑、设备信息的了解，强化基本信息收集、网络空间搜索引擎（Shodan、ZoomEye）、域名及端口信息收集技巧，针对企业级网络场景开展信息收集练习（为 SRC 漏扫目标筛选提供支撑）。

漏洞原理与分析：深入学习 SQL 注入、CSRF、文件上传等常见漏洞的原理、危害及利用方法，结合运维工作中遇到的类似问题进行关联分析（明确 SRC 漏扫重点漏洞类型）。

工具进阶与 SRC 漏扫应用：

系统学习 SQLMap、BurpSuite、AWVS 等工具的高级功能，开展工具联用实战训练；
专项学习 SRC 漏扫流程：包括 SRC 平台规则解读（如漏洞提交规范、奖励机制）、漏扫目标范围界定、漏扫策略制定（全量扫描 vs 定向扫描）、漏扫结果验证与复现；
实战训练：使用 AWVS+BurpSuite 组合开展 SRC 平台目标漏扫，练习 “扫描 - 验证 - 漏洞报告撰写 - 平台提交” 全流程。
SRC 实战演练：选择合适的 SRC 平台（如补天、CNVD）进行漏洞挖掘与漏扫实战，积累实战经验，尝试获取挖洞收益。

恭喜你，如果学到这里，你基本可以下班搞搞副业创收了，并且具备渗透测试工程师必备的「渗透技巧」、「溯源能力」，让你在黑客盛行的年代别背锅，工作实现升职加薪的同时也能开创副业创收！

如果你想要入坑黑客&网络安全，笔者给大家准备了一份：全网最全的网络安全资料包需要保存下方图片，微信扫码即可前往获取!

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

（三）第三阶段：渗透测试技能学习

1. 阶段目标

全面掌握渗透测试理论与实战技能，能够独立完成渗透测试项目，编写规范的渗透测试报告，具备渗透测试工程师岗位能力，为护网红蓝对抗及应急响应提供技术支撑。

2. 学习内容

渗透测试核心理论：系统学习渗透测试流程、方法论及法律法规知识，明确渗透测试边界与规范（与红蓝对抗攻击边界要求一致）。

实战技能训练：开展漏洞扫描、漏洞利用、电商系统渗透测试、内网渗透、权限提升（Windows、Linux）、代码审计等实战训练，结合运维中熟悉的系统环境设计测试场景（强化红蓝对抗攻击端技术能力）。

工具开发实践：基于 Python 编程基础，学习渗透测试工具开发技巧，开发简单的自动化测试脚本（可拓展用于 SRC 漏扫自动化及应急响应辅助工具）。

报告编写指导：学习渗透测试报告的结构与编写规范，完成多个不同场景的渗透测试报告撰写练习（与 SRC 漏洞报告、应急响应报告撰写逻辑互通）。

（四）第四阶段：企业级安全攻防（含红蓝对抗）、应急响应

1. 阶段目标

掌握企业级安全攻防、护网红蓝对抗及应急响应核心技能，考取网安行业相关证书。

2. 学习内容

护网红蓝对抗专项：

红蓝对抗基础：学习护网行动背景、红蓝对抗规则（攻击范围、禁止行为）、红蓝双方角色职责（红队：模拟攻击；蓝队：防御检测与应急处置）；
红队实战技能：强化内网渗透、横向移动、权限维持、免杀攻击等高级技巧，模拟护网中常见攻击场景；
蓝队实战技能：学习安全设备（防火墙、IDS/IPS、WAF）联动防御配置、安全监控平台（SOC）使用、攻击行为研判与溯源方法；
模拟护网演练：参与团队式红蓝对抗演练，完整体验 “攻击 - 检测 - 防御 - 处置” 全流程。
应急响应专项：
应急响应流程：学习应急响应 6 步流程（准备 - 检测 - 遏制 - 根除 - 恢复 - 总结），掌握各环节核心任务；
实战技能：开展操作系统入侵响应（如病毒木马清除、异常进程终止）、数据泄露应急处置、漏洞应急修补等实战训练；
工具应用：学习应急响应工具（如 Autoruns、Process Monitor、病毒分析工具）的使用，提升处置效率；
案例复盘：分析真实网络安全事件应急响应案例（如勒索病毒事件），总结处置经验。
其他企业级攻防技能：学习社工与钓鱼、CTF 夺旗赛解析等内容，结合运维中企业安全防护需求深化理解。