- 项目成果
- 项目已成功落地并取得收益，全程由本人独立开发完成
- 基于真实业务场景验证，AI编码技术使团队效率提升400%
- 沟通邀请
如需了解技术细节或合作探讨，欢迎加微信进一步交流。下文为项目核心思路与效果展示- 技术验证
- 下文中复杂场景案例均来自实际工作，包含完整解决方案
背景
这里剥离出一些项目的特性问题仅讨论一些在测试上共性的问题
在日常的需求测试中,一般的测试开发人员都是将功能测试和自动化测试剥离开来的,大部分自动化手段其实都是需求测试后补充,这就暴露出了以下几个问题:
- 能力门槛与效率失衡
自动化测试脚本的编写要求测试人员具备编程能力和框架使用经验，但团队中此类复合型人才占比有限，导致自动化覆盖率难以快速提升。 - 迭代速度与回归压力
在敏捷开发模式下，频繁的版本更新（如每周发布）迫使测试人员优先执行手工回归测试，而自动化脚本的维护与新增Case因时间成本被滞后。这种“手工补位”的恶性循环，使得回归测试工作量不断增加，最终可能引发版本发布质量风险。
那么我们如何解决上面的这些痛点,将测试的劳动力释放出来,让测试人员有时间完成更重要的事情呢?
在AI agent 能力得到大大提高的当下,我们可以试试AI驱动下的测试赋能:
- AI帮助测试人员做一个能力的拔高和能力的打平(更快理解项目工程和上手case编写)
- 让测试开发人员在进行需求测试的同时,就可以直接将需求转化为自动化case(AI编程)
具体实现请看我下面的介绍
技术架构图
现在实践下来,使用terminal agent + cli command + MCP的技术架构,生成case准确率最高,下面的效果展示也以该方式作为主,(ps:Trae + MCP的方式我会在文档最后展示效果图,仅做展示,就不详细说明了,设计思路是一样的)
测试开发上述工程的过程中主要遇到了以下几个问题:
-
如何让AI能够准确识别用户的意图,如果不准又应该如何修正?如果不全又应该如何补齐?(这块会不会反而降低我们的效率) -
生成的case如何让用户更容易理解及调试起来(能力打平和易上手) -
如何符合当前测试工程的开发规范,让代码不乱生成(方便后期维护) -
用户上手难度如何降低,让他们想用爱用和易用
下面只说一下大致的方向和思路:
-
编码工程:项目工程逻辑清晰,模块解耦,实践中证明,如果想提高AI开发效率,简单且清晰的项目才是王道(下面链路图中) -
工作流规划及编排:不同的场景对应不同的工作流,做特定的事加载特性的工作流:现在虽然模型的上下虽然支持到了200k,但数据表明,上下文内容越多,LLM识别用户意图越不准确,因此最好的方式就是优化上下文,我做了一件事就是,拆分场景指定任务,每次只完成一个小事情,最后将事情汇总起来 -
开发规范和模版化:我们可以将通用的事情抽象出方法论来,有一个小样本,AI出错的概率会大大降低
当然AI开发的过程中还会遇到各种各样的问题,这里就不一一列举了(AI本来就是概率,但我们要做的事情就是提高它做对事情的概率)
链路图和交互
下图以postman文本转pytest测试脚本为例
如何度量
LLM的度量还是挺主观的,尤其是这种本来就是给人用的,到底是真正的提高了测试效率,还是说我们把开发脚本的时间最后浪费到了和AI对话的时间上,最后反而降效了呢?
后面,我和团队一起定下了下面几个方向:
团队内部做过评估和调研:不同的自动化用例编写的难度和耗时是不同的,我们划分为了场景化case,异常case(又分为单接口和场景异常case)
编写场景化case: 准备测试数据,编写case到完成,一条case大概 3小时左右
异常case中,场景化,相当于在正常测试场景下,完成一些异常场景编写,编写case到完成一条case大概1.5小时左右
单接口异常case,主要做的是参数的校验工作,编写case到完成,大概一条case10分钟左右
我们根据上述数据总结我们提效了多少
-
过程上:
生成case的准确率:这个指标反映了AI的能力
生成case实际耗时: 这个反映了提效的程度
-
结果上:
当前业务线的总体代码覆盖率是否有提升: 这个反应了质量上是否得到了优化(代码覆盖率也分为总代码覆盖率和当前需求的代码行覆盖率)
这个指标上,我们统计了,自动化case完成后和AI补齐自动化case后的差值,来判断AI生成的代码是否有价值
实际的产出:
这里场景化代码,也有复杂和简单的crud类型的,只取平均值进行衡量
|
|
数量 |
代码行数 |
提效(人工编写/(AI编写case+修复)) 单条case |
正常场景化测试代码 |
24 |
200+ * 24 |
3小时 -> 30分钟 |
异常场景测试代码 |
28 |
500+ *28 |
1.5小时 -> 30分钟 |
单接口测试代码 |
246 |
500+ * 246 |
10分钟 -> 1分钟 |
使用方式
- 双效验证
- 用户体验：通过终端CLI+Agent架构实现零门槛交互
- 提效实证：AI编码技术经实际验证可提升测试编码效率400%
- 交互设计
- 功能调用：用户输入
/即可查看所有支持功能，支持自然语言交互与命令行参数两种模式 - 智能引导：AI通过对话式交互逐步指导操作
- 高效场景：命令行模式适合熟练用户快速生成案例
如下为当前已经开发完成的功能
下面简单的展示一下用法及效果,更多的详细内容看后续章节的效果展示:
获取帮助
该命令会展示当前自定义的所有命令及使用方式,适用于我们第一次上手项目,不知道如何操作的场景
# 获取使用方式
/project:help
postman转化为pytest脚本
用户只需要输入postman的文件及相关背景信息即可将文件转化为测试代码
接口详情查询
/project:apihup-interface 
异常用例生成
/project:exception-plan
异常代码生成
/project:exception-codegen 
代码提交到仓库
直接帮助用户将当前生成的测试代码提交到代码仓库,并且上报到数据库中,记录本次的生成内容,方便做数据统计
/project:git-manager效果展示说明
上一部分已经展示了基础命令都能完成什么场景的开发,在真实的工作中,其实更为复杂,我都抽象成了上述的几个命名,内部的MCP会进行意图识别,指导任务编排及规划
简单说下哪里复杂了:
-
最简单的场景其实就是crud的接口自动化用例生成 -
但是复杂的业务下,我们会有各种中间的过程要确认,比如生成了case,那么状态是否正确,是否需要等待 -
更加复杂的场景就是多个模块要组合起来,外加各种额外的需求
这对AI来说是一个考验,因此我使用command+ 场景模板 + MCP ,让AI更加精确的识别用户意图及优化上下文,这大大的提高了AI生成代码的准确率,如下是效果展示
案例：复杂场景下的case生成
如下是一个多模块测试接口生成的case,正常情况下,需要8小时+完成自动化用例的编写(可以看后文的代码生成量就可以大致评估出来)
本次使用AI coding,从准备环境到生成case,case分为场景化,异常场景及单接口异常case用例生成,总体大概耗时不到2小时(生成完全可用于日常回归的测试case),效率提高400%
注:这不是噱头,本人也不喜欢营销,真实工作中实践下来,就是如此,AI coding让团队的效率直接翻倍,我的github上开源了相关的技术实践,欢迎和大家交流
postman转pytest代码
输入/后直接同tab键补齐,如下:
指定工作流,生成用例过程
需求文本为一段postman的文本
接到请求后开始做任务规划及工作流的编排
每完成一步工作就在task.md中进行记录,后续当异常情况任务中断,也可以保证AI从中断处继续处理任务
自动执行case,修复其中问题
完成后总结(失败case显示出来,待用户给出建议修复)
生成代码概览
按照约定好的模版,生成的具体的测试代码(不能泄漏公司内部的信息,因此这部分只能截图概述)
具体case生成如下:
生成README.md文档概览
自动对生成的用例进行总结,给出执行的命令及参数的介绍
本地运行调试
查看具体代码,这里其实是因为我们没有告诉LLM ,需要等待网关的状态为Available,因此LLM没有做特殊处理,我们此时不需要手动修改case,只需要让LLM修复即可,告诉他失败的原因,如何修复
LLM修复case
执行 pytest tests/vpc_nat_gateway_crud/test_vpc_nat_gateway_crud.py -v
报错:
```
FAILED tests/vpc_nat_gateway_crud/test_vpc_nat_gateway_crud.py::TestVpcNatGatewayCrud::test_vpc_nat_gateway_crud - AssertionError: NAT网关状态异常: Creating
assert 'Creating' == 'Available'
- Available
+ Creating
```
原因是:
步骤5: 查询NAT网关列表,初始状态为Creating,但是我们需要完成一个轮询函数,等待状态为`Available`
而不是直接查询,修复该问题
可以看到AI完成了相应的修改及脚本编写
最后terminal agent 自测通过
本地自测
如下代码为AI根据提示自动修复的代码
最终测试通过,一次性就把问题修复
异常用例生成
查询用例详情
我们先查询刚才测试代码生成涉及的这些接口,根据接口及用例的场景进行case设计
/project:apihup-interface 查询tests/vpc_nat_gateway_crud/test_vpc_nat_gateway_crud.py中涉及接口的详情
最后会给出相关接口的使用建议
生成异常测试用例
/project:exception-plan tests/vpc_nat_gateway_crud/test_vpc_nat_gateway_crud.py 根据command制定工作流,之后调用mcp工具查询接口详情
完成用例的生成
我们看下实际的用例，生成的场景化异常用例
生成的单接口异常用例
给出的下一阶段建议
异常用例代码生成
我们根据上一阶段生成的异常用例开始生成当前阶段的代码
/project:exception-codegen --plan-file tests/vpc_nat_gateway_crud/EXCEPTION_PLAN.md --test-file tests/vpc_nat_gateway_crud/test_vpc_nat_gateway_crud.py代码生成过程
自动制定工作流
最终完成用例生成
我们看一下实际代码生成的如何
具体的某一条用例,我们可以看一下,对接口的响应结果做了细致的断言
在README.md文档中,异常用例的执行方法也已经给出,我们直接复制粘贴就可以使用
运行异常case并修复
第一次运行,发现失败的case有点多,先让LLM自己进行一次修复,如果这次修复还有问题,我们手动check,在让LLM修复
pytest tests/vpc_nat_gateway_crud/test_vpc_nat_gateway_exceptions.py -v 运行后有四个case异常,制定计划,每次运行一个错误用例,修正一个用例,而不是把所有的用例都一次性修复 
最终case修复完成
让我们再次运行一下:
十条case均修复成功,这里你可能会好奇,场景化case出现问题都是先人工check,为什么异常case就直接让AI修复呢?
这里我做一个解释,一般场景化的case,失败的点大多是一些业务场景我们没有考虑周全,但是异常case,大部分就是断言的失败,而对于业务场景的失败,我们如果不提供给LLM一些可能的原因,那么大概率会朝着错误的方向发展,而异常断言的失败,对于这种结构化的数据,LLM会比我们修复的更快更准确
欢迎交流讨论
