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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有几个小问题：

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

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

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