每当听到这种需求时，我都会发出这样的疑问。
系统服务级别需要达到千万级用户量在线访问的要求不仅对整个研发团队或是运维团队带来了巨大的挑战，测试团队也不能独善其身，你真得可以证明系统服务具备这样的能力吗？
这样的需求听起来就十分地吓人，当你深入其中真正开始着手实施这项测试任务的时候，才会真正意识到它不仅仅是听上去吓人，而实际上也的确如此，这就是一项难于完成的任务。
你将面临的不仅仅是技术层面的难题，测试环境、模拟数据、资源监控等方面带来的棘手问题也将如期而至，你会深陷其中，一次又一次地调整当初所制定的测试计划和策略，以应对呼啸而来的各种“麻烦”。
本文为了破局，以测试需求为根本，试图从测试策略入题，结合你手头可能具备的测试条件，为你出谋划策。并列举3种策略规划以供参考，从而希望帮助你最终一步一步地完成这项艰巨的任务。
进一步挖掘需求
一切的根本是明确性能测试需求，这个应该大家都非常清楚。单独给出“达到千万级用户量在线访问的要求”显然是意义不大的，如果未得到明确的对于执行关键业务上的性能指标要求（建议你尽量叫负责人交代清楚这些需求，而不是依靠自己去挖掘和分析），你需要进一步挖掘更加细节层面的真实需求。
在如此巨大的用户规模场景下，找寻执行关键业务时在事务概念上的性能需求尤为重要！
比如高峰时段下对于事务的响应时间、并发用户数、TPS、WIPS（the number of web interactions processed per second）、成功率等基本指标要求，这些都需要明确，只有这些指标明确了，你才明确了终结本次测试的必要条件（不然，这将是一个吞没你的无底洞）。
如果有过往的相似业务交易历史数据经验，你需要尽量参考，处理这些收集到的原始数据（日志），从而分析出高峰时段，以及该时段下的交易行为，交易规模等，得到你想要看清楚的需求细节。当然，如果是生产系统已经服务过一段时间，建议你首先去和运维团队进行交涉，他们手中应该掌握了充足的数据供你参考 。
但在有些情况下，可能没有那么幸运，无法获取到数据层面的佐证，于是，你需要采用经验方法来分析这些需求，比如可以参考一些类似行业的比较成熟的业务交易模型（比如银行业的日常交易活动或交通行业售检票交易活动）或者干脆遵循“2/8”原则和“3/5/8”原则来直接下手实践。
另外，在估算响应时间、并发用户数、TPS、成功率这些关键指标的同时，你仍需要关心具体的业务功能维度上的需求，记住不要过于苛刻的设计这些指标，每个业务功能都有各自的特点，有些业务功能甚至通过返回“系统忙，请等待！”这样暴力的姿态来回应用户以避免过大的处理流量所导致的大规模瘫痪，因此，学会平衡这些指标之间的关系是必要的，记住在大多数情况下最好为这些指标做一个优先级排序，并且尽量只考察几个优先级高的指标要求。
应对策略
在明确需求的前提下，你必须知道自己的家底儿，并顺藤摸瓜慢慢了解清楚整个项目的全貌。
1.首先，要问自己一个问题，你所掌控的资源能否支撑得起这样的测试需求？
你当然可以从自己手中的资源情况换算出可以模拟出的最大在线用户量。压力生成器物理机的配置和数量、测试网络的带宽和伸缩性、测试工具的性能和分布式施压特点，这些基本情况一定要掌握到心中有数，但你是否试过通过更加合理的资源组合设计和游说来增加这个在线用户量的最大值：
（1）你想过混合使用测试工具来完成这项任务吗？
你需要尽可能多得了解所有相关测试工具的使用知识，LoadRunner是你最佳的选择（QALoad、IBM Rational Performance Tester可能现在已经不流行了），但不是所有公司都有其正版授权，因此，你不得不退而求其次，开源的JMeter是你的又一个不错的选择，但免费使用的代价是其自身性能表现较之LoadRunner差之甚远，你需要通过一些技巧来弥补这些劣势。
通常情况下在线访问量概念下的用户行为是有迹可循的，除非是群体性有明确的目的（比如秒杀系统）会产生绝对当量级的并发行为，不然，你可以简单得把来自用户的流量拆分为在关键业务场景上产生并发行为的并发模拟用户和在全站范围内产生随机行为的背景模拟用户，背景用户不会产生有效的TPS贡献量，他们只是流量背景（产生一定的WIPS贡献），但这非常重要，因为这些行为依然会造成一定的资源损耗，占用带宽、CPU，以及数据库的IO和锁竞争，系统甚至会为他们开辟单独的Session。
于是，你有理由通过一些具备绝佳性能的工具Apache ab、wrk、WCAT等来实现背景用户的模拟，只需要根据背景用户行为指定测试场景，通常情况下你可以设计一个事务混合比来完成背景压力的同时，使用LoadRunner或JMeter等具备高级功能的测试工具实现并发模拟用户施压。
（2）你试过通过沟通来调用公司所有的设备资源吗？
全家大小齐上阵不是不可以实现，但你首先要说服相关负责人，在负责人首肯的情况下来游说相关干系人来使用他们的设备，在网络条件允许的情况下，你可以充分利用这些资源产生压力。
其次就是在一个合适的时间使用它们（通常是夜深人静的时候），你可以利用一些具备定时任务和良好集成性的框架（LoadRunner的话使用QC、JMeter的话试试Jenkins）完成无人值守测试，这将极大的解放你的生产力。
2.其次，你要问架构和运维一些问题，是什么样的架构设计和软硬件资源支撑起这样的需求，测试环境是否与其保持一致？
不要对服务端一无所知就盲目开始实施测试，记住性能测试的最终目标是找到性能瓶颈，并根据其表现结合相关数据提出优化方案。在条件允许的情况下，尽可能的了解和逐渐掌握整个系统的全貌，你才能在测试中达到事半功倍的效果。
（1）你想过只需要计算一下就可能算出最大服务级别吗？
是的，你很可能只需要一直笔就可以完成任务，通常最可能出现瓶颈的地方是网络出口带宽，你可以使用浏览器的调试模式完成关键业务场景下的流量采集，并结合一些可能的背景流量和高峰期用户行为模型，换算出单用户模式下大致的吞吐量，然后通过初等数学就可以计算出对基本网络带宽的需求量，往回比较一下测试环境的带宽情况就可以基本判断能够满足WIPS需求，进而估算其他需求能否满足。
但是，有些情况网络带宽可能是被估计压缩的，这样做的目的很明确，牺牲一些用户体验从而保障服务的稳定，所以有时候还是具体情况具体分析。
（2）你需要通过了解一些细节，设计你的测试场景和配置
了解架构和运维的细节是必要的，随着技术和应用场景的发展和不断变化，架构设计和运维方案也在不断的升级中，试着思考一下可能发生在你身边的变化：
数据层的架构已经从传统的共享存储的关系型数据库架构转变到了读写分离、非共享存储的NoSQL架构下；运维方案已经从物理主机环境发展到了容器配合分布式文件系统的虚拟化环境。
面对这些技术变革，作为测试工程师需要如何入手？
我的建议是不需要精通，你关注的是在这些新兴技术背景下可能存在的一些问题，抓住这些问题进行研究。比如读写分离或NoSQL在保障事务完整性（ACID）时的一些实现方案，你们的系统采用的是哪一套实现，读写分离的数据同步是采用的实时复制还是发布订阅方式，或者是其他方式，这里面是不是在提升性能的同时会损失一定的完整性约束？
这些弄清楚了，对你设计测试场景有巨大的帮助，所谓“打蛇打七寸”就是这个道理，你甚至可以预判出一些系统实现上的技术风险，并围绕着它展开测试，一切有目的性的实施测试，才能最有效的发现问题。
另外，对实际运维中的环境和配置细节，你也需要不遗余力的弄清楚。应对如此大的用户访问量，服务端的集群方案是使用了类似于反向代理的Web服务器的软件负载均衡方案，还是使用了F5这样纯硬件负载均衡方案，负载均衡策略是如何制定的，是基于IP地址导向流量？还是基于压力分布的纯动态分配流量？这些细节都与你后期比如进行IP欺骗或分配测试压力息息相关。
最终还要求你需要尽可能的了解被测试系统环境与真实生产环境所存在的差异性， 应对这些差异，提出合理的解决方案。
3.最后，你要问开发和功能测试兄弟一些问题，这里面会不会有你不知道的坑？
你可能是一名专职的性能测试工程师，这就造成了一个盲点，你无法面面俱到的了解到系统的整个需求，不要漠视功能上的一些细节需求，这些可能都是你将来在设计测试场景、开发测试脚本、准备测试数据、进行测试实施时要面对的坑。
（1）拿到接口文档，了解数据规范，有利于你构造测试数据或生成一些背景数据；
（2）弄清各种安全策略，协议层采用SSL会话？客户端硬件加密狗？敏感信息采用对称加密或是protobuf协议文件序列化方式？应用界面采用验证码，验证码的复杂度如何？对于来自相同用户名或网络地址的用户是否有访问控制限制？面对这些策略，你是否有能力独自应对，必要时，试着找开发共同解决；
（3）了解交互信息反馈方式，面对服务器产生错误，是否进行了友好的页面反馈，比如500状态码依旧返回200状态码的错误页面，或是服务器完全规避了一些错误反馈信息，有利于你有效的开展检查点和断言校验，避免由工具自己校验的错误；
（4）熟悉一些特殊的功能需求，系统是否对用户在业务操作上有所限定，比如在某段时间范围或面对某些特殊场景在数量或频率上有一些限制等，使得你能够正确的设计脚本的事务场景。
推荐3种策略规划
全效达标策略
当你经过大量评估，确信你可以做到模拟千万级用户量执行测试的时候，恭喜你，你将可以以最为接近真实世界的方式来开展本次测试。
现在可能唯一困扰你的问题就是如何对服务端环境进行监控以在测试进行中获取足够的数据来支撑你将来的性能瓶颈分析。在小规模服务场景下，这完全不成问题，你甚至驾轻就熟，但当面对上百台集群规模的服务单元时，你可能就没有那么容易轻松的完成这项工作，一种好的解决方案是你可以利用一些成熟的ssh客户端程序框架（比如ganymed-ssh-2）自己编写一些自动化程序，利用多线程方法完成对上百个服务单元下的Linux操作系统安装监控程序（nmon、sysstat相信都是不错的选择）、同时间启动监控、同时间停止监控，自动收集结果日志等功能，相信我，代码可以简洁到不超过100行。
全效达标策略总是最理想的测试策略，你在最初选择策略时要尽量追求可以实现它，虽然在实施上你需要通过调动大量的资源来完成它，但它会给你最稳妥和离真相最近的测试结论（而不是测试结果）。
TPS达标策略
很不幸，你的资源可能达不到实施全效达标策略的条件，而且距离给你的deadline已经为时不远了，你可以试试TPS达标策略。
在满足响应时间和成功率需求的前提下，你首先要进行一个TPS的换算，根据全效达标策略中的（真实的）TPS指标计算出高峰时段或全天需完成的总事务数，之后将完成这些事务总数的时间进行缩短，比如在高峰时段4小时时间内需完成1000个事务能够满足原TPS指标，那么就将这个时间缩短为1小时，计算出新的TPS指标，并以此指标为导向开展测试活动。这种策略就像是一场赌博，你需要全面优化你手头的全部测试资源，调整测试场景，尽量短小精悍，使用性能最卓越的测试工具，放弃资源监控让出资源，以达到新的TPS目标，使用能够支撑的最大并发用户数量，以期待在更短的时间内全面完成这一事务总数，从侧面证明被测试系统可以在脱离真实场景的苛刻条件下也能够完成既定目标（在更短、压力更大的情况下都可以完成事务总数的要求）。
结果达标皆大欢喜，在这种情况下系统很可能能够承载千万级用户量；但如果结果无法达到满意，你可能就需要结合换算达标策略的结果进行共同分析。
换算达标策略
有时候你不得不一小步一小步地精心的开展这项千万级用户量在线访问的测试，以弥补你测试资源不足带来的无法使用全效达标策略带来的负面影响，还好你时间充裕，于是开始换算达标策略，顾名思义，你从测试一个服务单元提供的服务级别性能开始，按策略递增，慢慢的你会找出一个可能的趋势，一个趋势函数从大量数据中被推导出来，你几乎可以用它来计算出最大服务单元下的服务级别性能。
基准测试
合理的基准测试是准确估算的一个必要条件，尤其基础设施所能提供的最大网络和I/O性能，得到这些结果至关重要，这是一个推理的重要依据。
对于网络TCP协议性能，你可能手头无法拿到SmartBits或是IXIA这样专业的硬件测试仪表，但你可以试着使用netperf或iperf这样的软件，试着得到一个最大网络吞吐量测试结果，其次是丢包率或时延指标；
对于I/O性能，你需要使用IOMeter，建议对磁盘阵列（虚拟环境下你不必过多的考虑其物理实物）在裸设备和文件卷情况下开展IOPS和最大吞吐量的测试，拿到这些指标。
相信有了这些数据，你可以在不断递增服务单元的测试过程中，通过收集和观察到的网络和I/O数据，进行推算，发现何时可到达出口带宽或是数据库I/O读写的瓶颈。
性能加速比
性能加速比是衡量集群环境性能的一个重要指标，它代表这一个集群在不断扩展服务单元下的一个性能损耗趋势。测试单个服务单元的TPS，逐渐增加到2个、3个、4个……，理想情况下当你测出单个服务单元的服务级别性能时，你可以按线性方程计算出最大服务单元下的TPS，但大家都知道，不断扩大集群实际上是一个增益逐渐衰减的过程，如下图：
性能加速比示意图
正向性能加速比计算公式参考（用户数、TPS等）：
性能加速比=n服务单元值/（n服务单元数 * 单服务单元值）
反向性能加速比计算公式参考（响应时间）：
性能加速比=（单服务单元值/n服务单元数）/n服务单元值
推导加速比的趋势函数，从而预测最大服务级别性能。
结合全部数据进行推理
结合加速比、监控数据与基准性能测试结果大胆推理出一个合理的可预见的服务级别性能，说服你的组织可以相信这一结果，毕竟它是有理有据的。
最后，在生产环境下密切关注实际情况的变化，从而根据实际数据得出新的推理，及时通知组织作出应对。