因为只有这些是比较通用的，可移植性强。其实公司内部还是有很多业务讨论、用例设计的讨论。但是这些讨论如果不是在一个领域内，或者不在一个公司内，上下文的信息不对齐，是无法被广泛讨论的。

其次，也有很多人对测试本身做了很多探索，比如海盗派测试、探索性测试等，都是针对业务层的用例设计方法论。

刚好手上有两个测试专利，申请的原因是前公司的要求，只提供实现的文案，其它有专人负责，所以申请还算顺利。

对跳槽基本上没什么帮助，因为原则上现公司是不能直接用的。

只是你能力的一个体现，不过这种专利也比较水，至少我申请了也不会刻意去说。

赞成文章的观点，其实这也是行业进步的必然性。测试行业在往前走，对技能的要求在提高是必然的。任何行业都一样。哪怕是工厂里的人，会操作大型机器的，也比只会手工的高很多。

行业在发展，技术能力在不断改进、提升，对于行业内的人员能力要求对应的也在提高，这个和卷不卷没关系，只是必然的发展规律。不要和规律对抗。

向前看吧，走自己的路。尊重市场规律，获取能力范围内的薪酬。安心即可。

支持~~

可能是行业不太一样吧，我所在行业是制造业的 IT 部门，所以没有那么紧迫的本成压力，所以自动化的目标并不是以减少人员为目标来展来的。聊下自己的观点，仅供参考：

1. 关于自动化平台的建设周期，在很早的文章里有提到过，是围绕能用 -- 好用 -- 优化使用 来构建的，每个阶段都会有具体的产出和收益，个人也比较反对一上来就规划太多的功能，把平台做的太大，周期太长。

2. 快速反馈的能力是提效的表现，但也不太可能因此就把 2 个人做的事缩减成 1 人，因数快速反馈的能力构建本身也是有成本的，无非就是看把成本花在哪，是花在人力验证上，还是花在维护自动化上。可能成本是一样的，但是带来的效果是不一样的。

3. 你提到的案例我也经历过，不同阶段的产品形态对质量的要求是不一样的，对团队的组织结构也是不一样的。这个是肯定的，所以测试人员也需要学会识别业务对质量的要求，并不一定非要开展自动化。

我之前给老板打过一个比喻，可能不是很正确：就像你平时公交上班，今年买了个车。是提效了，不管去哪里都方便，也能省出点时间做别的。但是，成本肯定是增加了。和自动化一样，它能提效，能在更多的地方发挥作用，但肯定是无法降本的。

如果是出于降本的考虑，有其它更多更快速的办法，不是么？都懂的。

1. 双周迭代
2. 为什么要算通过率呢？这并不是个很有用的指标，通过率的高低并不能说明什么，我们没关注这个指标；如果执行失败，我们的要求是 2 天内必须解决。
3. 执行频率是分等级的，对于 P0 的级别的，集成到流水线上，每次 Merge 到保护分支都会触发，其它级别的每天至少运行一次；
4. 会考虑异常场景，验证是否做了足够友好的提示，我们原则上不允许直接抛出代码异常。

嗯，本身是要验证的，这个没问题，也确实是需要的，我们团队也会要求前后端都做必要的校验。只是纯粹好奇下这个 bug,的原始逻辑，因为这种情况不太能想明白是怎么个情况

我比较好奇的是，这是个什么的代码逻辑，会现出这种结果？非法的 ID 最多就也不删除，是怎么会引发整个表被删除的？不是很能想明白

1. 自动化脚本的编写在一个迭代内基本上一天搞定，会有基本的用例设计，再动手写脚本；

2. 通过率不好算，基本上有问题就马上排查解决，如果是误报或者数据错误，需要及时修复脚本。我们对于自动化用例有降级机制，连续失败 5 次后，就会被踢出用例集，进入修复库，这个修复库会邮件通报的。所以解决问题的速率还行。

3.对于报错，人工分析是什么原因，不自动上报，是 BUG,就是 BUG,是误报，就按 2 处理；

1. 肯定发现过缺陷，特别是接口变动没有通知上下游的，导致关联业务报错。但不会很多，因为也不是自动化的主要目标；

2. 接口场景的接口数在 15~20 之间吧，长的也有 40+ 的，再多就建议拆分了

以上，不知道对你是否有帮助。可以加微信细聊

1. 为什么会跟不上版本进度呢？没有时间写脚本？在我的团队，迭代周期中的测试内容就会包含自动化测试的时间，而且通过工程能力的建设，所需要花费的时间也不会很长，基本上都是要求在迭代内完成对应新版本的接口自动化设计；

2. 需要做对应的断言，具体的断言要求可参考 ：https://testerhome.com/topics/36216

3. 我辅导过多家公司的自动化测试落地，规模基本在 30~50 人的测试团队之间。效果还行吧，至少现在大家都还在坚持着做。通过率不好评估，具体问题具体分析吧。主要还是脚本和数据的问题。环境的问题通过技术手段基本上不太出现了

以上测试结论的前提是架构没有变，持续压测试的情况，如果架构变了，比如你增加了节点，那当然是另外说了。通常情况下，性能测试的时候，环境是不会变的，先确认问题，再调整环境，再复测验证调整是否有效。

不会出现响应时间和 TPS 同时变多的情况，因为这两个本身就有点互斥的意思。

后续专门写一篇吧

并没有，敏捷和加班不冲突。
虽然敏捷不提倡加班，但现实就是还是要加班，敏不敏捷都一样；
但是敏捷可以让团队更有目标的加班，做好了也可以不加的，
主要是工作透明化。

不恰饭，诚心推荐

新年快乐～

竟然是个 QQ 群~~好多年没用 QQ 了。

在朋友圈看到了 震撼、神奇、折服等词来形容这个工具。然后就去下载玩了下。和恒温的感觉差不多，离落地应用还远着。每个项目的 prompt 还得自己改，慢慢适应。

我们的团队基本上都是这么做的，当然每个团队的实际情况不一样，只是一种参考。相对于拍脑袋，分成三部分还是好点的。

感谢你对灌水文还如此在意~

从技术的角度没毛病~~但是组内人要是怎么玩，是要挨骂的

Jmeter 也支持的啊，非 GUI 模式。这种方式严重依赖工具提供的功能，文章也说了很多 sample 还不支持。所以没想明白真实的应用场景是什么

没想明白什么场景下会用到这个工具。一般都是生成好 JMX，然后丢给 Jmeter 去跑就好了呀

没想到这个帖子得到大家这么多的讨论，其实就像文章里说的，这只是个人的选择，没有对不对；
只在于自己的选择，每个人有不同的选择，世界才会多彩；
只要你能平衡，不做过多的抱怨即可。
大家都过的很不容易，不是么。