我啊

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

你这种不好测的，都是 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，容量自动缩容扩容（水位评估），流量回放，用例管理等。

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

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

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

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

当然好啦。

客气了。赛道不同，每个垂直赛道都可以成为优秀的人。加油。

我觉得很厉害了，不知业务复杂度如何，可以尝试挑战一下。

对的。

交易我不敢当，不敢回答你，体系是个很庞大的概念。贯穿整个软件项目的生命周期。
我只能谈谈我做过哪些事情：

1. 常规的需求评审，正向、逆向、履约（我主要是正向）
2. 提测质量的监督。（工具平台支撑，比如发提测单）
3. 全链路监控（接的星环运维）
4. 流量回放做回归（中间件隔离）
5. 全链路压测。
6. 资金红蓝军攻防演练（就是 monky 注入）。
7. 废单演练。
8. 提效工具、造数平台的开发。
9. 发布、回滚监控。

第二个问题，转开发的建议。

1. 工作两三年有机会就转。
2. 30 岁以前想搏一搏，转。
3. 30~35，有 P6+ 开发能力，转。
4. 其他，做好测试，天花板测试总监。

谢谢

客气。

多谢

大佬好，同事好。

客气。生存与挑战。

可以