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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有几个小问题：

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

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

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

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

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