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

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

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

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

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

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

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

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

支持~~

可能是行业不太一样吧，我所在行业是制造业的 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+ 的，再多就建议拆分了

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