举个例子，比如微信，可以聊天、朋友圈当做两个功能，拆分开。确实依赖于 app 的业务形式，有些比较适合，拆分相对来说是个低频操作，可以结合构建系统实现自动打包拆分包。

说一个思路：既然 app 太复杂，覆盖不完全，可以降低 app 的复杂度。在某些 app 功能相对独立的场景适用，把不同的功能模块分开打包测试，比较容易能完全覆盖。

如果是要这个功能，那基本上网关产品都有这个功能。
如果是面试题，高性能、高可用这要求不低呀。

歪个楼，正常人的发量在十万这个级别。

1. 如果后台代码对外部请求没有做配置化，直接改代码为 mock 地址，mock 服务可以分情况 mock 或者 proxy 到正常服务。
2. 如果配置化了，比如配置文件，就修改配置文件。
3. 更好一点的，现在服务框架可以根据请求 header 动态路由，这样就可以从前端控制请求是不是走 mock。

感谢社区，慷慨大气～

的确目前网络上还没有相关的资料。

指出一个问题：

性能测试工具功能对比：

这部分显示 Jmeter 不支持测试过程调整压力，其实是可以的，我们内部的性能测试平台就实现了这个功能，思路是压力设置的地方使用变量，Jmeter 开启 BeanShell 支持，beanshell 支持远程修改变量的值（当然能力远不止如此），就可以动态修改变量的值，实现灵活的压力控制策略。

locust 也是支持的，它自带了的 web 界面就提供了这个功能。

典型的 XY 提问法，建议看看提问的智慧手册。
回到你的问题，把参数放一起作为一个 dict，你原来的参数名字对应 dict 的 key。不管调用还是函数中使用都很方便。

也经历过新人阶段，认真回答一下：

1. 从软件工程理论的角度看测试是很重要的一环，因此不存在天花板低的情况。即使是现实世界中大部分人的职业生涯触还碰不到天花板。之所以有这种说法，那是因为质量对于大部分软件产品都不那么重要，所以对测试的资源投入不足。例如通信类、航天类质量至关重要的领域，测试就很重要，也很有技术含量。对于大部分从事的互联网行业，测试确实知识面比较杂，一个人精力有限，进一步的会感觉什么都不精。如果现在不知道从何下手，其实可以学习一些计算机专业基础知识，这些知识很长时间都不会过时，对你日后的工作、跳槽面试都很有帮助。
2. 自动化会涉及到投入产出比，工作中的事情其实都要考虑投入产出比，有些产品、或者有些产品的阶段就是不适合做自动化测试，不必强求。
3. 不要过分关注绩效，这个东西很大程度你是控制不了的，你的领导是什么样子的人，你在的团队，公司的成长阶段可能都比你的付出重要。至于领导给你解释的绩效理由，你听听就行，其实没什么意义，是先有结果再有解释。你的长期价值会在招聘市场中公允的体现出来。
4. 适合不适合自己，自己喜欢什么，这永远是你要问你自己的问题，也只有自己能探寻答案。不要太在意别人的肯定与否定。