1. 构建提示词模板
2. 构建循环提示
3. 构建大模型自己思维连 COT
4. 让大模型自己提升自己
5. 构建自动化评测，通过提示词评测模型准确度，好，中，差。

有两种情况：

1. 只是表单提交不涉及业务逻辑。
2. 表单存在不同的业务逻辑。

如果是第一个：

1. 按优先级：P0->必填项；P1->非必填项；P2->异常；P3->UI/UE
2. 测试方法：表单多字段，正交；表单单字段，等价类，边界值，判定表；

如果是第二个：

1. 优先业务逻辑：P0->各主流程全部 cover（业务逻辑覆盖率 100%）
2. 次要字段验证：P1->必填字段；P2->非必填字段 + 异常容错；P3->UI/UE
3. 测试方法：业务逻辑跑通；其他同上

通用的测试右移：

1. 接口线上巡检。
2. 监控告警。
3. 灰度策略。
4. 回滚策略。
5. 应急响应。
6. 降级方案。

实施（结合具体项目实际情况）：

1. 至少 P0+P1 用例全部执行完毕。
2. 根据测试用例数量评估测试时间，与团队协调测试资源，全量用例测试环境 (daily)，P0+P1 预发，P0 部分用例生产。

说个我过去的一个 O 吧，都达标了，供参考：(服务端/客户端一样，测试环境，预发环境未纳入）

1. 核心接口覆盖率>=90%
2. 核心接口通过率>=95%
3. 自动化发问题拦截率>=10%
4. 核心场景覆盖率>=80%

下一个目标：

1. 原来数值上再提高
2. 预发环境指标定义
3. 线上巡检定义
4. 全量用例占比扩展定义

没有人带么？

测试分析，任务拆解，测试设计（等价类，边界值, etc），测试方案我都没说。
先把需求理清，拆分明白了。

测试设计是基本功（自己努力吧），日后在考虑测试方案（风险识别，可测性识别，测试工具，脚本，测试计划，测试方法，测试类型）

说句扎心的话，尤其测试，现在入 IT，相当于 49 年入国军，1911 年进宫当太监。

一个可行的方案，去一线城市或新一线城市工作，努力攒钱，回家花。

补充一下，换个思路（玩个文字游戏，改成需求返工）。

需求返工与打回的区别在于：

1. 打回是某一项不符合提测标准，基本卡主了需求评审，技术方案评审，单测，静扫，cr，自测，产品走查。
2. 返工是质量太差，需要要重做，重新走一遍流程，“拉着大家一起下水”，这样才会拉拢有缘人帮你说话、配合你提升质量。

需求返工，从意义上更具有震慑作用，更能引起领导层的重视。

感谢回复，[:鞠躬]。此外我还有公众号，抖音号。

1. 已经不在了阿里系了。
2. 红利算赶上了，也算没赶上，目前还是负债前行。
3. 2015 年生过一场大病，几乎断送职业生涯，第一次体会能活着就行。
4. 转开发的同时，蚂蚁也转岗成功了，支付宝测开专家（现在因该是蚂蚁金融）虚线 Leader 带两个正编两个外包做理财产品的测试。后因零售老板 +HR 挽留加之人员团队不稳定，最终选择留在了开发团队。（也不藏着掖着，直白一点，就是感觉有大腿可以抱，日后走研发管理之路。但是，大腿不粗不行，大腿的大腿不粗也不行，集团来了个高级副总裁，大腿和大腿的大腿说换就换。）
5. 市场环境误判，开了个公司，创业 4 个月，除了帮 testerhome 带货卖了两张门票是最大的收入，几乎无收入。
6. 24 年转回测试，举家北漂，去了一家中等公司做测试开发 TL，带 7 个人。没别的，就是因为测试总监是我很早以前的同事，以前摸鱼的时候经常在休息区打台球。（所以我说广结善缘，说不哪天谁会拉你一把）
7. 25 年回上海，原因 1）天天 11、12 点，甚至 3 点左右常态，怕猝死；2）孩子 1 岁半，北漂生活准备不齐全，带娃不方便；3）没时间带孩子，全落在孩子他妈身上，家庭矛盾加深。
8. 回之前，朋友推荐先拿了一个 offer 过渡，薪资降半，这也是我说的多与人为善、学好英语，因为面的是一家外企，做 AI 测试，没错是测试 AI 产品及算法。（干了一个星期就走了，这也是我说的为什么降薪后入职背刺，很多企业不愿意招大龄工程师的可能原因）
9. 现在一家传统企业子公司做测试，目前就我一个软件测试，薪资不高。

35 以后的职业生涯确实艰难，但还是能找到工作；40 岁夹缝生存，能找到工作就好好珍惜把。我现在风雨飘摇，家里老婆全职带娃（预产期公司老板捐款跑路漂亮国，公司倒闭），失业对整个家庭来说是灾难性的。所以我说攒钱是为了预防风险；对自己好一点，是真的说不定明天和意外哪个会先来。

另外，我是认真在回答题主的问题，回答的过程中保持结构化的方式，是希望帮助题主及感兴趣的朋友更容易理解。

我说的都是结合我过往的经历，形形色色的人、形形色色的项目以及形形色色的奇葩见的太多了。当然，不代表大多数。
有不对的地方，请随时指正，认真听取，虚心接受。

40 岁了，人生过半了。

这是我之前梳理的 AI Agent 学习，可以参考一下。

35 以后就不仅仅是能力的问题了，是人脉 + 能力 + 运气的多维组合，是续命。
任何人，无论现在多牛，到了一定时刻都会被淘汰，或早或晚。

一、为什么会失业（这个就不展开说了）

二、为什么失业后很难再找到工作？

答案可能不是你能力不行，以我个人的亲身经历（也是我带团队时遇到的境况）帮你拆下局：

1. 团队需求。只需要一个能干活、听话、踏实的人；或者就只需要一个点点的测试。
2. 竞争激烈。35 岁左右能力都差不多，一个岗位放出去就有几百上千个投递，竞争激烈。前段时间青浦工业园区的一家小微企业刚放出一个产品运营岗，就收到了好多份简历，而且薪资只有 6500 元。
3. 紧迫程度。岗位确实再招人，但是没有那么急切，现有人力硬抗也行。
4. 高新背刺。一些能力不错的人，降低薪资来了，但是遇到高薪的机会，立刻走了，也是妥妥的增加企业招聘成本。

三、如何破局

答案可能也很简单，但也可能很残酷，因为很多情况不是因为你没坚持努力。（普通人永远都是资本的棋子）
那么为了续命，续测试工作的命，下面也是我个人的一些经历和感触：

1. 个人能力。技术能力是基本功，是吃饭的家伙，且要持续不断地精进和打磨。
2. 人际关系。处理好周围的人际关系，不要瞧不起任何人，看似不起眼的同事，未来说不定哪天就能帮助到你。
3. 社会贡献。扩大自己的圈子，多参加论坛、开源组织、社区活动做些利他的贡献，这是结实行业大佬的机会，且能多方面的展示、锻炼自己的才能，让他们发现你、看见你、认可你。
4. 步进成长。小公司->中型公司->二线->一线大厂步进式成长。
5. 同学资源。维护好同学关系，毕了业，同学可能是你唯一能直接袒露需求的人。
6. 扩展技能。别死磕测试，测试过程中把开发技能也掌握（说不定能转开发），架构思维，设计思维，这些是你能在开发设计阶段的优势。
7. 向下兼容。正式干不了，降低薪资干外包，但是外包的生存境遇也非常难受。
8. 学好英语。时刻练习英语，工作中熟练交流，大部分村里的程序员英语都不好，你只要坚持，就打败 80% 的工程师了。
9. 时刻谦虚。时刻保持谦虚，认真聆听，做一个让团队喜爱的人，比如 @ 恒温，思涵，禹哥。太高调容易让人反感，除非你强大到无人能替代的程度。当年 Monkey 手撕朱少民，对喷思涵，实在令人惋惜。再看恒温，亲眼见证从口碑 P6 到蚂蚁 P8，一步一个脚印；再看禹哥，之前在易果生鲜，努力在论坛坚持写文章，钻研新技术，成功进入阿里，大文娱的视频检测平台获得天猫爱迪生奖第一名，也从来都保持低调。
10. 以后再说。
11. 不得不说，攒钱，攒钱，攒钱。

附赠：

我们来到这个世界，为了什么？

1. 为了一日三餐？
2. 为了有车有房？
3. 为了哪个姑娘？
4. 为了养家糊口？
5. 为了上有老下有小？

自己过得幸福么，开心么，快乐么，上海平均寿命 80 岁，很多人大概只能活到 70 多岁，35~40 岁的人生基本过半了，对自己好一点。

一、你需要什么样的人

1. 团队的组成是丰富的，有全栈工程师，有业务专家，有热爱测试的，有热衷效能的。
2. 你对这个人的需求是什么，我不觉得这个人有问题，反而是你招聘的需求要写清楚且明确告知我要业务测试。
3. 技术是必须的，只能做黑盒的测试帮我解决不了什么团队的技术问题。

二、技术无用论的误区

1. 测试左移及测试工程师左移，需要对软件架构、设计有足够认知，才能在早期规避风险。
2. 提效也不能指望他人，当你需要其他人的时候我为什么需要你。
3. 技术方案听不懂或一知半解，测试充分性会打折扣，场景遗漏。
4. 测试需求来源测试本身及产品，可测性、异常、mock、造数等，没有比自己开发更贴合自身的需求。
5. 全链路的问题排查，浏览器、域名、网关、vipserver、hsf，mq 等。

三、当前组织的形态

1. 组织发展到一定规模，堆人会加大成本。
2. 研测比之间的权衡。
3. 裁员重灾区。
4. 产品复杂性提升后，测试复杂性也在提升，不靠技术手段，你解决不了。如果不需要，去大厂锻炼锻炼，开阔一下视野。没吃过猪肉，至少也得见过猪跑。

附赠
作为测试工程师/测试开发工程师，不懂测试是肯定不行，但不懂技术也不行，至少在我团队必须懂技术。

一、通常都是针对提测，打回也是不符合提测标准，比如：

1. 单元测试未通过。
2. 静态代码扫描未通过。
3. 自测用例未通过。
4. 产品验收未通过。 （1 和 2 因修 bug 引起的，不算，但是测试准出要卡住）

二、一旦进入测试阶段，那都按 bug 处理，因为涉及的因素很多，比如

1. 团队能力成熟度。
2. 项目性质。
3. 核心/非核心业务。
4. 组织意志。

三、比打回更重要的是带领整个团队提升质量意识，形成质量文化。

1. 线下质量提报。
2. 线上质量运营。
3. 过程质量跟踪。
4. 质量可视化分析。
5. 代码质量减少低级问题。

四、质量体系的重要性

1. 流程上可以持续进行过程改进和缺陷分析。
2. 测试左移、右移标准建立。
3. 质量通晒，周报/双周报体现各团队的差异。
4. 共性问题分析及治理。
5. 专项/横向或某些疑难杂症/技术攻坚。（我很讨厌专项和横向这两个词，听了 7、8 年了）
6. 有空再说。

五、总结
这个范围太大，一时半会儿说不完。打回只是其中的一个手段，如何逐步提升团队质量意识是一套体系的思考。否则，会陷入无休止的扯皮。可以从一个点突破，一步一步完善，提升自己的影响力，做好质量守门员，从救火到防火。

附赠
情商也得在线，村里还是人情世故的社交，思考一下如何做一个让团队即不讨厌又能解决问题的优秀工程师。

我啊

没有捷径，找上游和合作方一起解决。

你这种不好测的，都是 sql。
建议直接从底表读数据即可，再往上游追投放没必要了。
每个功能就用最简单的 sql 做验证，用你自己写的，别用开发的应为开发的 sql 是通用的肯定有问题。
你就把每项拆开，自己一层一层统计。先完成这第一步吧

这体验真的太差了，没有风控机制啊。

1. 增加监控预警。
2. 高频回复和发帖的，及时告警。
3. 超过阈值可自动或配置控制发帖频率和次数。
4. 判定为违规账号，直接进黑名单。

格局、视野不够啊

1、这个工具可以标识大家有没有阅读用例，两个开发同时执行时，能看到哪个人执行了哪部分必免重复
2、用例可以看标明前置条件，步骤，结果
3、用例评审方便

直接 xmind 就行了，搞那么复杂，要么一键导入 xmind。
一个一个的用例，还不如思维导图清晰。
看问题：1. 整体；2. 局部；3. 微观；4. 细节；

1. 开发分工问题。即便同时操作一个，也势必有强依赖。
2. 给他自测用例。
3. 脑图评审更清晰，功能模块归类更容易让人懂。

这个逻辑比较简单，对于一个开发来说最多不超过两天就能干完，剩下的体力活是往数据库里填数据。

不需要高并发，不需要稳定性，不需要大数据，也不需要实时数仓，也不需要缓存，mq，各种逻辑复杂的设计，实现起来就三层架构和实体关系设计就行。

首先要思考你这个东西怎么用，就像产品一样先得有个初略的 PRD。
自己随便在纸上画画或写写提纲，这个是指导你写任何代码（产品，框架，工具和测试代码）的出发点。
当然，在往左移就是业务需求（测试需求）。
想清楚怎么用，比如有个界面：

1. 可根据筛选条件查询接口列表
2. 根据筛选条件和选中的接口执行用例。
3. 查看用例执行结果。

这样就可以抽象出来几个实体：

1. 接口：你也可以拆的再细一点，接口是一个实体，接口实例是另一个实体（包含属性环境，端，url，地区等）
2. 环境：包含（类型线上/线下/预发/预发多套/项目，机器，分组等）
3. 终端：终端类型，名称等
4. 地区：城市，区域等。
5. 结果：接口，接口实例 ID，关联用例，用例执行结果（成功/失败）

然后识别出实体之间的关系：

1. 接口环境多对多。
2. 接口终端多对多。
3. 接口地区多对多。
4. 接口和结果多对多。

然后设计你的表结构：
（可能还需要配置也，配置接口在不同条件下的具体参数）

然后根据筛选项去设计你的逻辑：

1. 比如一个接口实例包含：环境，端，url，地区.
2. 根据前端筛选（环境，端，地区）很容就从数据库查出数据了。
3. 然后把查出来的这一批数据放入执行队列里执行。

嗯。回答一下题主的问题。也舍不得 @ 恒温（张老板）。

应该不行

1. 测试代码和业务代码分开，解耦。
2. 你的需求会影响接口性能。
3. 你的需求属于两个执行环境，一个在 spring 容器，一个是 junit 类加载器加载，不在一个容器。

如果要做一些拦截（你自己的验证逻辑）

spring 5.x 之后版本

1. 实现 AsyncHandlerInterceptor，写自己的业务逻辑.
2. 重写 preHandle/postHandle/afterCompletion 任意一个或某几个或全部方法。可以试试（我没试过）new JUnitCore().run(Request.method(ATest.class, "测试功能1"));。
3. 实现 WebMvConfigure。
4. 重写 addInterceptors 并注册你写的拦截器。

spring 5.x 之前版本

1. 继承 HandlerInterceptorAdaptor。
2. 继承 WebMvcConfigureAdaptor。

spring 5.x 为例

@Component
public class CommonInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // TODO 你的验证逻辑
        System.out.println(request.getRequestURI());
        HandlerMethod handlerMethod = (HandlerMethod)handler;
        System.out.println(handlerMethod.getMethod().getName());
        return false;
    }
}

@Configuration
public class CommonWebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        WebMvcConfigurer.super.addInterceptors(registry);
        registry.addInterceptor(new CommonInterceptor());
    }
}

基础建设都可以理解为基建。
大点说，国家的电网，铁路，交通，水利这些基础累的满足人民生活基本需求的。
业务来说，帮助商户提升店铺建设，商品完善，价值提升等。
测试来说支持测试日常工作的基本工具/框架/平台/工程等，接口自动化，抓包，压测，CI/CD，容量自动缩容扩容（水位评估），流量回放，用例管理等。

需要有一定积累和产出，先在自己的组内得到大家的认可，组织内部还是有一定认可度的。但是转了之后竞争升维，调整好心态。

测试天花板是比较局限，不过看机会。
纯业务测试生存空间会被进一步压缩。
测试研发比也会压缩。
测试根据风险进行投入，比如交易链路投，其他非关键链路不投测试资源，有问题再打补丁。

自己过得舒服就好。这也是一种生活，工作在人生中才占多少？还有那么旅游，看书，购物，娱乐呢。

尽最大努力，其他交给天意吧。加油。