你真的要测试千万级用户量在线访问？

每当听到这种需求时，我都会发出这样的疑问。

系统服务级别需要达到千万级用户量在线访问的要求不仅对整个研发团队或是运维团队带来了巨大的挑战，测试团队也不能独善其身，你真得可以证明系统服务具备这样的能力吗？

这样的需求听起来就十分地吓人，当你深入其中真正开始着手实施这项测试任务的时候，才会真正意识到它不仅仅是听上去吓人，而实际上也的确如此，这就是一项难于完成的任务。

你将面临的不仅仅是技术层面的难题，测试环境、模拟数据、资源监控等方面带来的棘手问题也将如期而至，你会深陷其中，一次又一次地调整当初所制定的测试计划和策略，以应对呼啸而来的各种“麻烦”。

本文为了破局，以测试需求为根本，试图从测试策略入题，结合你手头可能具备的测试条件，为你出谋划策。并列举3种策略规划以供参考，从而希望帮助你最终一步一步地完成这项艰巨的任务。

进一步挖掘需求

一切的根本是明确性能测试需求，这个应该大家都非常清楚。单独给出“达到千万级用户量在线访问的要求”显然是意义不大的，如果未得到明确的对于执行关键业务上的性能指标要求（建议你尽量叫负责人交代清楚这些需求，而不是依靠自己去挖掘和分析），你需要进一步挖掘更加细节层面的真实需求。

在如此巨大的用户规模场景下，找寻执行关键业务时在事务概念上的性能需求尤为重要！

比如高峰时段下对于事务的响应时间、并发用户数、TPS、WIPS（the number of web interactions processed per second）、成功率等基本指标要求，这些都需要明确，只有这些指标明确了，你才明确了终结本次测试的必要条件（不然，这将是一个吞没你的无底洞）。

如果有过往的相似业务交易历史数据经验，你需要尽量参考，处理这些收集到的原始数据（日志），从而分析出高峰时段，以及该时段下的交易行为，交易规模等，得到你想要看清楚的需求细节。当然，如果是生产系统已经服务过一段时间，建议你首先去和运维团队进行交涉，他们手中应该掌握了充足的数据供你参考。

但在有些情况下，可能没有那么幸运，无法获取到数据层面的佐证，于是，你需要采用经验方法来分析这些需求，比如可以参考一些类似行业的比较成熟的业务交易模型（比如银行业的日常交易活动或交通行业售检票交易活动）或者干脆遵循“2/8”原则和“3/5/8”原则来直接下手实践。

另外，在估算响应时间、并发用户数、TPS、成功率这些关键指标的同时，你仍需要关心具体的业务功能维度上的需求，记住不要过于苛刻的设计这些指标，每个业务功能都有各自的特点，有些业务功能甚至通过返回“系统忙，请等待！”这样暴力的姿态来回应用户以避免过大的处理流量所导致的大规模瘫痪，因此，学会平衡这些指标之间的关系是必要的，记住在大多数情况下最好为这些指标做一个优先级排序，并且