一、你需要什么样的人

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. 然后把查出来的这一批数据放入执行队列里执行。

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