族望留原籍，家贫走四方。老家不是望族，只能走四方。

目前在深圳，离家 4 小时动车，感觉还好。现在的交通不是以前可比的，活动半径可见的扩大了。

测试充分性包含三个层次的：代码层次的测试充分性、系统（功能/非功能）层次的测试充分性、业务层次的测试充分性，而 “业务层次的测试充分性” 最具决定性的。

代码层次：这一层次在很长一段时间内，是被测试人员忽略的（能力不够）。万丈高楼平地起，测试人员需要花一部分精力去关注代码层的交付质量：代码静态分析、覆盖率验证、全链路测试、契约测试等，可以快速提升测试效率。同时，这个层次也是最适合做自动化的层次。

系统（功能/非功能）层次：大部分测试人员的主要精力都会花在这里（自称点工）。根据现有的需求文档或者 Story 描述，结合业务特点和自己的经验，通过测试用例的设计，验证功能点的正确性。并适当地开展一些非功能性测试。只关注这层，往往会忽略很多上下游业务依赖的错误，或者是底层代码在特定场景下的问题。

业务层：这里指的是需要有端到端的业务视野，从全流程的角度去验证复杂场景。这需要测试人员对业务非常熟悉，同时也熟悉业务关联的上下游系统。这类测试人员其实非常难得（在制造业的某个领域，曾经半年招不到一个，但这类人其实就业面也比较窄，因为对口的业务公司也不会太多，所以专注业务的同学需要慎重选择深入哪个业务）。

在做测试策略和测试设计时，需要针对以上三个层次都有所覆盖，才能提升测试的充分性。

可参考：https://testerhome.com/topics/40827

个人现在很不提倡做弱网测试，
一是现在的网络基本上都能覆盖到，原来的地下停车场、电梯等环境网络也不差。
二是现在大家对于弱网的接受程度都有了比较清晰的认知，网络不好的情况下只会吐槽网络而不是 APP。
三是网络不好的情况下，应用本身也解决不了太多问题。

所以，在弱网的情况下，这个 APP 是非用不可么？

以前要做弱网测试，纯粹是因为当时的网络在哪都不给力，4G 之后，基本上就不做这个了。除非产品本身是网络底层相关的。

省流：掀桌子，尥蹶子，这活儿爱谁干谁干。

​感触：适当的让一些不好的事情发生确实是很好的处理问题的方法，模拟场景——测试时间被压缩到极致后，自己吭哧吭哧把事情抗下来，搞定，结果领导觉得谁上都行，开发觉得，这不是可以搞定么，然后就恶性循环了

基于风险做测试策略就好，为了效率，就不要对质量抱太高的期待。

https://testerhome.com/topics/32121 这里有一部分相关内容

测试技术的迭代更新是很慢的，所以技术型的文章更新的也慢。技术是需要打磨和沉淀的。

简单、重复的技术没必要一直说。

真实落地的技术，在团队中，基本上半年都不会有一次大的变化。

为什么这个套路看着这么熟悉？？跑步打卡群？

日更需要发自内心，而不是囿于规则，否则必不长久。

本人周更，算是坚持下来了。很多时候需要出于热爱。特别是没有获利的情况下。

有几个小问题：

1. 业务流量比例，一般指的是完整业务流的比例，而不是单接口的比例，根据题主的假设，就是业务 1：业务 2：业务 3 的具体比例；

2. 如果在做单接口的时，算 TPS 的话，就应该是算 A 接口在所有业务中的总次数，这样才能保证 A 接口的性能不影响；

有同感，现在慢慢的，自己也想开了。不过份追求上进，多陪陪家人，身体排第一。

能做到这个其实是很好的，但是在实际的过程中，因为业务进度或者时间的关系，还是会有很多问题遗留到端到端测试。

另外，端到端测试还有个很重点要的点在于要验证业务的完整的性和正确性，毕竟在系统开发出来之前，产品也无法确认系统是否能够完全满足业务需求。

解决问题，沉淀流程，把业务和流程梳理好。就是很大的价值体现了。但是解决问题的基本前提是要有对应的业务能力，要能和研发做同频交流。把测试的内核沉淀好。

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

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

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

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

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

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

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

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

支持~~

可能是行业不太一样吧，我所在行业是制造业的 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 同时变多的情况，因为这两个本身就有点互斥的意思。