就拿近期比较火的 skills 做例子吧，就算 llm 已经被大家承认能力很强，也需要各种 skills 进行 token 压缩或者更具体更明确更效率的结果产出。我们用 AI 也只是在现有的流程工具下，增加 agent 角色的引入，它解决了一些显而易见的效率提升质量提升，但是这之后呢？挖掘额外的质量和效率依然是一个大的课题，然后重新回到 agent 角色和流程引入替换。

方案 1 适合已产品状态为基地的测试流。方案二适合以围绕产品配置的测试流。一个是静态数据，一个是动态数据。

AI 改变了问答模式，测试之家本来就是小众社区。像 CSDN,stack overflow 才是真正的寒冬，他们现在也只能靠卖数据为生，当数据被大模型完全消化完才是真的致命

估计是没发 ping pong 导致执行到这个阶段的时候被服务端关闭了。先确定一下单发是有效的那就可以排查长连接的配置问题

重点看一下工具落地环境，上层对测试的目标预期是否能支持你去做落地。人员没到 10 几个人，形成 2 级梯队的情况下，基本都是扁平化管理，2 人和 6 人没多少区别，当然会有更多调度资源，以及测开资源这确实是提升的部分。

本身这是一个循序渐进的过程，先有指标，再把不同数据纳入指标。这也是一个团队不团提升的过程。例如先 2%，但是指标数据是测试介入需求引起，下一个阶段就是需求缺陷，再下一个阶段就是所有需求。有这个过程的团队一般也是正规的公司才会有。

看到这篇分享，不禁让我想起之前看到的一篇文章。我们做自动化的终极目标是什么。如果是为了让不会代码的人通过低代码的方式完成自动化。那完成了之后呢？还是转向 coding 还是停留在这个阶段，如果是 coding 为什么一开始不就这么做。如果是为了让 AI 通过范式进行全自动化流程的设计，那么为什么一开始不这样做。我个人不反对任何形式的自动化模式，但是如果你是想推广它，那设计者应该明白，它最终的生命形态是怎么样的，即便是幻想。

这个行业不是不进则退，而是不进则没

是的，单独一个历史功能大全，然后拆分出一个分组，历史功能组合。你可以给 AI 圈定场景组合的方式。逆向数据使用，重复数据使用等类似的小样本案例。AI 就知道可能要考虑历史功能对当前功能的影响，同理现有功能对历史功能数据的影响。这种一般都是人工补充的，所以再规范格式的时候一定要清晰，起码保证人工审核的时候是高效的。你可以先从无背景的需求下手，再递进到有需求背景的业务。慢慢的你就知道需要设置什么样的 AI 角色了

目前我们是将 prompt 分为一下结构：用例结构（页面、功能、测试点），测试方法分组（提交类、查询类、场景组合等方法论的实际少样本提示）、标签分组、覆盖测试类型分组（兼容、接口、性能等）。针对依赖度不高的需求已经可以较好的应对，对于人工采纳在结构上也较友好。对于持续迭代版本，你说的依靠历史用例上下文检索效果也不是特别好，我们的做法是建立功能背景文档，帮助描述历史需求，专门设计历史依赖组合的类目去进行设计。

mock+ 契约测试组合，基本就可以自动化数据以及数据结构变更的第一时间通知了

你终于发现了华点，对于现有自动化的改造，AI 的参与还是偏向探索以及代码生成更适合。传统的定位模式他是高效稳定的原由的 POM 模式已经大幅度降低维护成本。如果再降低，你可以考虑让 AI 去维护 page 而不是完全代替。再不稳定的界限处可以尝试引入 AI 进行动态定位。完全的 AI 运行，除了不稳定外关键还有 token 的使用。这些都是要考虑的。所以我更偏向与传统 +AI 集成而不是由某某技术完全代替的方案，除非它已经足够成熟稳定。

设置 set_default_timeout 让它把异常抛出来。new_context 先试用默认参数，后面再按需调整。看到异常就知道怎么解决了

单接口压测，只要压单接口就行，前序流程你准备好数据就可以不需要加入到流程。
多场景压测更多是验证相似场景下，资源竞争类的风险排查，例如极端的死锁。
脱离业务的资源竞争，更多的还是看推流业务流量情况下的容量预测，不过在现代的运维环境下，更多的是看限流，降级，扩容等策略的生效情况了。

其实已经有很多落地结果了，而不是没有效果。所以你应该去除固化思维，真的进入这个业态去了解边界在哪里，哪里可以做。停留在原有的测试区域，差距和认知会越拉越开

确实，当初坚持走自动化和测开的，就算没啥实质性的成功，起码技术能力上还是有地方可以施展的。未来也一定是属于 agent 开发和落地的人才的。不过以前吃到过技术升级红利的人，这波除非不可抗力基本也会选择拥抱 AI 的，唯有年龄是真的最大的阻碍。

任何新增流程都需要额外的时间成本，在原有的投入下想提升，只有改变原来的开发模式。既然要改变开发模式就要引入新的工具例如 AI。然后推行下去，到这里你没权限也没能力去做这个事情了，这就是个悖论。你发起不了的

AI 需要边界，现在工作流式的 AI 效果比较好，提效也明显

有点类似我刚刚做管理时面试，想要候选人样样都会，且有一定的系统性学习深度。后来我才渐渐明白，你到底需要怎么样的一个人去完成怎样的一件事，想通这个很重要。而不是他好像无所不能

1. 解决负债，居有定所其实生活成本不高。
2. 主业该拓展的新方向该拓展还是得拓展，保持技术的敏感性即可。
3. 副业侧重学习和轻投资，个人更偏向身体力行的行业，能积累经验，纯投资有那脑子的就搞吧，反正我是不推荐高风险的了。
4. 就算完全毕业，也要有资本能苟活，然后学习实体吧，只有累的脏的在加上自己存的资本和认知赚点工资钱都没啥问题。
5. 体力状态，精力是厚积薄发的必要条件如果加班加废了，就完全的真的废了，有点存款都没用的。

测试用例生成，用例补充，用例 + 接口文档决策优化，用例 + 需求文档行为场景决策优化。
自动化测试，根据接口信息模型生成，基础封装，根据步骤自动编写填入。其他的明年再做咯

在今天 AI 能够生成基础数据模型，封装接口，根据步骤结合工程上下文合理推导测试用例的今天。拥抱未来吧，这些真的是炒冷饭了。

复杂场景，用例规模达 10000+，你最终还是会回头到 pytest 和 junit 这类单元测试框架上的。即使低代码引入关联，模块组件等功能也完全不能达到代码级别继承组合能力。另外小打小闹几百条用例用啥都一样。

locust 是用 gevent 协程实现并发的，但是 requests 是同步库你可以使用 locust 的框架类去实现，上面已经提到了 httpUser。顺便一提你问 AI 的问题应该是也有问题的，你应该问为啥你的脚本在 locust 里面为啥没有实现并发的效果，AI 肯定能指出问题原因的。

root 或者兼容流程，这个是厂商底层的设置你没 root 权限根本关闭掉会再不同的地方给你弹出来或者自动弹出来的