前段时间做了一个压测项目，对压测过程中学到的知识进行了总结，在此和大家分享下：
一、确定压测的目的
1. 通过不断加压，得到服务器峰值，找出系统瓶颈。
2. 验证系统的稳定性。
3. 确定系统各项指标是否满足上线预估目标。
4. 为后期性能优化提供参考依据。
二、解决环境问题
压测时，要隔离线上环境，以免影响线上其他业务，主要关注以下三点：
1. 如果有测试环境，首选测试环境。
2. 如果只有线上环境，要确保线上环境没有其他业务。
3. 要压测的环境所接入的第三方接口也要确定做到隔离线上环境。
三、压测环境要求
1. 稳定性。由于压测时会持续打压并保持一段时间，所以测试环境的稳定性尤为重要。测试环境的稳定性决定了测试结果的准确性。
2. 独立性。在搭建环境时，要尽量保证测试环境的独立性，最好是测试环境不与其他系统共用，减少不确定的因素可能对测试过程的影响，导致测试结果不准确，以及避免压测对其他服务的影响。
3. 可控性。在进行压测时，测试环境中的所有设备和资源应该是可以监测和控制的。以免出现异常而未察觉，造成不可挽回的失误。
四、确定预期目标
压测前，要与产品、运营、开发一起预估各项预期数据目标。
预估之前，需要先考虑如下情况：
1. 产品所依附的平台的用户数，访问量是多少？
2. 产品是否会大力宣传推广？
3. 产品是否会先灰度上线进行观察和监控？
4. 该产品的目标用户数、访问量是多少？
5. 用户对该产品的关注度怎么样？
6. 会不会有其他产品影响到该产品的QPS？
7. 产品是否存在使用高峰期？
8. 产品上线的准备数据是否充足，操作方便，满足需求，能够吸引大量用户上线后瞬间频繁使用该产品或持续增加用户使用量（预估产品峰值是发生在刚上线的时候，还是通过用户的逐渐增加而产生）？
五、预估方法
1. 根据经验预估。
一个做过多次性能测试的测试人员，基本清楚一个产品的QPS大概能达到多少，需要留有多少的容错空间。这是一种简单快速的预估方法。
2. 参考同类产品或相似产品。
如果有同类或相似产品，可以根据同类或相似产品的QPS进行预估，比如社区类的微博、电商类的淘宝等等。
3. 灰度上线试行。
灰度是指该产品只对某些用户可见及使用或抽出核心功能快速上线供用户使用，以此来统计及预估产品的各项数据。如果可以灰度上线试行进行预估，那就尽量用这种方式进行。这是最真实可靠的数据。
4. 根据上一版本的QPS进行预估。
如果是版本迭代的产品，可以根据上一版本的QPS及版本优化后预估增加或减少的QPS预估出新版本上线后的QPS。
5. 如果以上方式都不适用，可采用8/2原则。
8/2原则是指80%的请求访问在20%的时间内到达。是通用的预估方式。可根据系统pv测算出QPS值。峰值QPS=（总pv * 80%）/（60*60*24*20%）。
六、制定压测方案
根据压测目的和预期目标制定测试计划，包括压测时间和压测分组，其中压测分组又包括系统配置、数据来源、压测时长、压测步骤、测试结果。
七、数据准备，脚本准备
有了压测方案，接下来就要准备压测需要的数据及脚本。其中压测数据尽量模拟线上真实用户的数据，得出的结果更加准确。
八、执行压测
1. 根据测试方案里的分组分别进行测试。
2. 首先通过向服务器不断加压，得到服务器峰值QPS（通过不断加压，平均响应时间及QPS趋于稳定，即为峰值QPS）。
3. 对峰值QPS持续压测2个小时（视情况而定，一般是2个小时，如果预估系统会长时间处在高峰期，或者系统性能不是很稳定，可加长压测时间至24小时）来验证系统的稳定性。
4. 通过向服务器不断加压，到达一定QPS，响应时间明显变慢或报错，这个拐点即是服务器的瓶颈。
5. 压测结束后，分析压测结果，得到TP99和TP95。
6. 根据压测结果，衡量性能是否符合预期，编写测试报告。
九、测试报告
测试报告一般包括如下几点：
① 测试结论。测试结论包含两部分：第一部分是将测试结果精简成一句话，并附上是否可以上线。例如“测试结果符合预期，可以上线。”第二部分是评估方法等一些支撑结论的数据。
② 风险备忘。根据测试结果，分析可能存在的风险，经与产品运营沟通，不影响上线，可列为风险备忘。
③ 优化建议。根据压测得到的系统瓶颈给出优化建议。
④ 测试结果。指每组测试的详细曲线图及结论。
⑤ 测试数据。指压测时传的参数来源，参数尽量用线上的真实数据，模拟线上真实用户的请求。
⑥ 测试分组。与压测方案里的测试分组是相同的概念，这里不再赘诉。
