落地实践可参考：https://testerhome.com/topics/36475

是的，本质还是团队规范的问题，或者说研发负责人的质量意识，决定了团队的质量意识。

优秀~

接口自动化测试的意义在于以下几点：

1. 实现分层测试：这个才是核心重点，测试是需要分层的，而不是一股脑的丢给 UI 或者 E2E 测试，这样会给问题定位带来更大的麻烦，而且修复成本也高。就如文中的例子，你可以很直观的判断出来是 UI 调用错误，而不是接口本身的问题，如果没有接口测试，你需要做更多的排查。

2、提高测试覆盖：有些场景并不是简单的通过页面操作就可以覆盖到的，比如异步类请求，比如第三方的依赖，比如多层接口的套用调用

1. 适应持续集成和交付：可以有流水线有效的结合在一起，做为基本的质量门禁

至于节省的成本，这个要从更大的时间维度来看，如果只是某个迭代，那接口测试一定是降效的，因为它意味着更多 的时间投入和维护成本，但是从半年或者 1 年的时间来看，它是能够提效的，提效的程度取决于你执行的次数。

我只想知道这么扯蛋的性能需求是谁提出来。

行业总归要发展的，这个并不以个人的意志为转移。那就自己跑快点，没什么不好的。不给自己的借口。

这个帖子这么多人点赞我是没想到的~感谢大家支持

此处有掌声👏

1. 指标的意义就是引导团队做出有意义的改进即可。公式没有太多的固定式

2. 度量和 OKR 挂钩，都是不太靠谱的。会为了指标而指标。造数还是比较容易的。

测试就像品菜师，会在厨师精进的道路上提供必要的帮助。二者相辅相承。才能让整个研发过程更加流畅。也能体现测试的价值。

测试并不比开发低一级。

很多数据都是可以量化的呀，比如说验收标准数量、用例数量、缺陷跟踪、风险评估、专项测试等。

如果你的老板都是这样的，那就没什么好说的，至少我经历过的和我听说过的，大部分 Leader，还是愿意了解测试的工作内容和价值的。

表达也是件很重要的事。文中也说了，适当的时候，刷刷存在感，多多汇报。

现在酒香也怕巷子深。你不说，没人会替你考虑的。

不应该是有了好的测试。才能让开发优秀起来？

如果是企微回调你们的接口主动上传数据，那实时性要求不高的话，如 10 楼所说，直接用 MQ 会好点，性能压力会极大缓解。
至于模拟加密麻烦。。。这个应该不算什么问题吧，没难度。

一般会有两种办法：

1. Mock 数据，然后只验证自己处理回调接口的性能，默认企微的接口是没有问题的。
2. 看看企微有没有类似沙箱的环境，让你们压。

有个小疑问，你们获取成员聊天记录是想干什么。。。

我也是自己在反思，有时候也会犯错，哈哈。

没那么严格的界线，相对而言，研发过程还是比较透明的，不认论是测试人员还是测试组长，都能看的见。可以适当的去尝试推进。或者找一些 “帮手”，或者和开发维护下感情，都是可取的。不要被自己的限制了。

两条腿走路，极端了都不行。技术辅助，业务主为。

其实天梯也是可以刷分的，本质上都一样。谁还没带过妹子不是。

我在团队的实践思路是：重点关注生产缺陷、流程改进建议数、效能提升项，这三个是考核的重点内容（60%）。其它的，根据团队反馈来估计，占比 40% 左右。想要出成绩，要么保质量（线上不出问题，过程你们自己定，不管你是点点还是自动化，线上不出问题，怎么都可以。出了问题，有没改进项，是否落地了，是否重复出现等），要么改进过程，提升效能。

绩效本来就不会有绝对的公平。这个世界也没有绝对的公平。这也不是我们要去追求的。平衡才是常态。毕竟软件研发过程，还是没办法直观量化的。和工厂的拧螺丝还是有质的区别。

https://testerhome.com/topics/35129#reply2

同名公众号：CKL 的思考空间

其实吧，录制的脚本更麻烦。因为你还是要手动去修改数据，比如参数化，比如登录信息。还不如先熟悉接口，然后再处理。不了解接口你也无法有效的设计用例啊。

严格意义上来说，你这都不算测试开发工程师。。。

解决业务测试的痛点，研发各类小工具，搭建平台等，才能算是测开。

优秀~

提两个小建议：

1. 是否可以根据业务接口来造数据，从上面的介绍看，主要还是依赖于手写数据，这就对测试人需要对对应的表结构或者 MQ 的报文结构非常熟悉才可以做到，特别是上下文依赖。比较容易出错，通过接口调用会好些。

2. 造出来的数据，如何与测试脚本关联起来？需要使用人员再去查询一次么？

造数确实是测试活动中非常重要的痛点，希望看到更多优秀的解决方案。

这个适合纯数学计算的公式，因为可以在不知道入参的情况下做推导或者公式变形。但是对来有业务逻辑的函数或者接口而言，要如何做落地呢？比如测试对像是根据不同的用户 ID 返回不同的用户信息。这个在不知道用户 ID 的情况下，如何做断言呢？好像没办法推导