最近和很多测试同学交流时，发现大家对性能测试基础的一些知识理论比较欠缺，导致在实际的工作实践中遇到了很多不好理解的难题。因此最近在重写性能测试基础理论知识相关内容，也算重新整理自己的思路。
今天分享一篇老文，略作修改。前面的知识科普系列，写了性能测试最核心的几个术语、测试时采用的测试策略以及压测工具的定位和选型。这篇文章，以一个案例说明，如何分析性能测试需求。
有同学在微信群问了一个问题：为什么800并发压测，服务器还没有报错？当时群里其他同学提了很多观点，比如：
- 并发不够，加并发！
- 要不要考虑首页进来多少人？
- 是不是有限流，流量都被拦截了？
- 我看CPU都打满了，压测要关注硬件指标！
- 是不是你压测机配置比较低，无法发起这么多并发。
林林总总感觉说了很多，又感觉都没说到位。正好之前工作中遇到一个性能需求，说来也蛮有意思的，需求大致是这样：
网关要验证在跨可用区情况下，支撑20W的TPS。就这一句话，我当时有点诧异（以我对公司目前业务及架构的理解，根本不需要20W的TPS）。
那么问题来了：如果是你，听到这样“一句话需求”，你会如何分析，然后制定压测方案呢？
下面我会从十个部分来围绕性能需求分析展开描述。
1、需求评估分析
先来聊聊如何分析这个性能需求，关于性能需求分析，我总结下面几点roadmap：
接下来，按照上述思维导图，我会通过几个不同问题的解答，来描述我的分析思路。
谁提的需求，目的是什么？
研发同学提了一个性能测试需求：网关要验证在跨可用区情况下，支撑20W的TPS。
关键字提取：流量网关、跨可用区、20W的TPS。
2、什么是流量网关？
简单来说，流量网关就是所有请求的流量入口，承载了所有用户请求。如下图所示：
3、如何理解跨可用区？
一般来说，云服务的可用区，可以理解为同一个机房的不同虚拟机集群。
为了避免某个可用区由于网络硬盘等原因损坏导致服务不可用，跨可用区的服务部署是一种常见的容灾手段。
4、流量网关有什么特点？
负载均衡：跨多个服务的动态负载均衡；
身份验证：即用户的身份鉴权，登录态、黑白名单等；
限流限速：基于速率、请求数、并发等维度进行流控；
其他特点：加解密、A/B测试、灰度发布、监控告警、服务治理等功能；
5、压测流量网关有什么难点？
网关是用户请求流量的入口，因此访问压力会很大，即我们常说的QPS很高。那么在压测时，要考虑下面几点：
- 需要能支撑发起很多并发请求的工具；
- 网关服务的应用需要部署集群，来应对高并发；
- 由于只是跨可用区，一般云服务可控制在0.5ms以内；
6、在什么场景下为谁提供服务？
上面介绍了流量网关的特点，这里的场景指的是业务场景或者说测试场景，即：验证网关的哪些功能场景下的性能表现。上述的网关特点中，一般需要压测验证的场景有鉴权、加解密、身份验证。
7、目前系统架构调用关系是怎样的？
做性能测试，最怕的是不了解系统架构就开始无脑高并发！
了解系统架构及服务间的调用关系，才能设计合理的压测场景，准备对应的脚本和数据。
8、如何搭建满足需求的性能测试环境？
根据上面的分析，跨可用区的网关应用集群，在搭建环境时，需要考虑的有下述几点：
- 集群均匀分布在不同可用区；
- 网关应用的单机配置（比如8C16G）；
- 虚拟机型保持一致（内核版本、计算型/IO型）；
- 需要绑定专门的域名，SLB和带宽需要大于预期的指标；
- 压测工具需要尽可能的支撑更高的并发流量发起（比如Wrk）；
- 因为涉及到鉴权和身份验证，需要提前预热相关的auth、token数据到缓存；
9、如何评估性能需求的技术指标是否合理？
上面提到了性能指标是20W的TPS，那这个指标是否合理呢？首先，性能需求的技术指标是否合理，要结合实际的业务场景和目前峰值流量及未来增长趋势来综合评估。
假设流量网关被所有业务接入，业务对RT比较敏感，业务请求RT的目标是10ms；目前的线上峰值QPS是5W-QPS，预计未来半年增长到10W的QPS，那这个时候，如何评估技术指标，或者说设定合理的技术指标呢？我们可以结合实际情况讨论，得到下面这样的一个技术指标：
ART&99RT：≤2ms；
安全水位下的QPS：≥10W；
TPS：统计核心业务的核心链路当前吞吐能力，做聚合计算，保持一定上浮；
当然，上述的指标有个前提：业务不接受有损。
如果业务接受有损，那么性能的技术指标无须这么苛刻（因为可以限流降级）；
10、性能测试方案
说到了性能测试方案，我偶然翻出了19年6月份画的一个性能测试流程职责说明表，见下图：
聊到这里，该如何设计性能测试方案呢？答案已经在上述的需求分析里了。
