本文主要介绍在我司完成过的性能测试（性能优化），分为理论篇和实战篇。之前在组内进行过评审，意在将性能测试日常化和规范化，但结合实际情况，其实性能测试做得不多（哪怕有些接口已违背258原则）。

又好长时间没有更文了，分享一下最近遇到的几件比较有意思的事。

三八妇女节的康乃馨

中国水利博物馆的登塔鸟瞰

好吃的牛肉和鸭肉

好啦，接下来开启正文。

理论篇

性能测试目的

可能遇到的问题

在测试或者系统试点试运行阶段我们的系统一直表现得很好，但产品正式上线后，在用户实际环境下，总是会出现这样那样莫名其妙的问题，例如系统运行一段时间后变慢，导致用户对我们的产品不满意，这些问题是否能避免，提早发现？
系统刚上线，正处在试运行阶段，能支持多少用户量访问？
我们的系统已经运行了一段时间，为了保证系统在运行过程中一直能够提供给用户良好的体验，我们该怎么办？
明年这个系统的用户数将会大幅度增加，到时我们的系统是否还能支持这么多的用户访问？
未来使用这个系统的人会越来越多，到底能支持多少用户量访问？
随着存储信息越来越多，数据库查询越来越慢。

能解决的问题

验证系统稳定性
新的业务上线，验证新系统能够满足系统的上线指标
评估系统性能
验证系统的架构是否存在瓶颈
对系统的未来容量作出预测和规划
验证改进性能效果，做对比分析的性能测试，为性能调优提供依据和建议

基本流程

涉及人员

人员角色	角色职责
软件测试工程师	负责整个性能测试的计划及方案的编写、环境搭建、测试用例、脚本编写、测试数据准备、实施测试、测试数据分析、获取测试结果、编写测试报告，保证性能测试工作的顺利完成。
业务系统开发工程师	提供性能测试指标、性能测试影响点、协助性能环境部署，根据性能测试结果跟踪、调优性能或解决程序问题。
产品经理	提供性能测试指标

测试策略

策略	概念	目的	关注点
容量测试	通过负载测试验证反映系统的某种应用特征的极限值，如最大用户并发量、数据库最大记录等。	1.获取系统在拐点时的性能数据；2.获取性能下降点的性能数据。	1.在资源占用以及其他应用方面都设定指标，比如CPU、内存、磁盘等；2.指标设定一般采用80/20原则。
调优测试	系统或应用在建立了性能基线后，关注性能是否得到提高。通过改变系统的配置，如DB连接池、JVM配置，或应用中处理的并发线程数，改变程序中算法逻辑等。	系统优化是否能够改善性能。	关注系统在应用或配置变化后性能是否能够得到提高。
负载测试	通过模拟系统所承载的并发用户或请求流量的负载，进行不断加压的方式来观察系统在不同压力下的性能变化，如响应时间、数据吞吐量和系统占用资源等，以检查系统的性能和特性，发现系统可能的性能瓶颈，内存泄漏等问题。	1.得出系统的最优的qps以及最优qps时的资源利用率；2.得出系统是否能够满足性能需求；3.得出系统的基线并发数。	关注不同压力下的性能变化以及资源利用率。
压力测试	负载测试的一种，判断被测系统在强压力的情况下，是否会出现不可恢复的崩溃现象，如卡死、异常现象等，也属于破坏性测试的一种。	1.得出系统崩溃点的qps以及资源利用率；2.得出系统基线并发数。	关关注功能测试不能发现的非功能性缺陷。

对应使用场景

适用业务场景	采用测试策略	选用目的	出现频次	举例
性能调优验证	负载&配置	验证性能优化结果，寻求平衡点。	高	员工花名册-导入
秒杀抢购促销	浪涌&高并发	验证高并发下的处理能力	高	考拉618大促
寻找性能瓶颈	负载&容量&极限	寻求不同压力下的性能表现、比对	高
建立性能基线	负载&容量	寻求系统的性能拐点	中	员工花名册-导入
批处理能力验证	批处理&高并发	针对定时&批处理业务，验证是否满足需求	低
高可用容灾恢复	高并发&浪涌	验证系统的恢复能力和异常情况下系统存活时间	低	考拉618大促-联系客服、商品评论等降级（限流3w、商评不展示）
服务上线前验证	并发&负载&容量&稳定性	性能摸底、告警阈值验证	中	社保系统上线
系统稳定性验证	负载&稳定性	验证系统长期运行的稳定性	中	亿企代账
短时峰值流量涌入	浪涌&高并发	针对特定的社交媒体论坛类业务的特殊需求	低	发布会、直播

准入准出

性能测试进入标准

已经产出评审后的性能测试指标，且有开发提供的影响点等；
服务器代码版本稳定，且开发内部测试后无严重阻碍测试进行的问题；
测试环境相关资源已到位，包括软件和硬件资源等；
测试计划编写完成且评审通过；
测试用例完备且评审通过；
功能测试进入冻结期。

性能测试通过标准

一般会从TPS、响应时间、或者跟历史版本/数据对比提升了多少、用户体验等多个纬度界定，使通过标准更科学、更贴近实际业务场景；
如果业务方给的标准比较笼统，可以参照以下几点：
- 按测试计划完成所有测试内容。
- 被测产品满足预期性能指标。
- 被测产品不存在性能瓶颈等。
如果以上3点未满足，可以继续参照以下几点：
- 部分计划内容因某些原因未完成，需说明原因，且经过三方确认，一致通过后方可结束。
- 被测产品不满足预期性能指标，但性能指标在可接受的范围内，且经过三方确认，一致通过后方可结束。
- 被测产品存在性能瓶颈，但影响较小，暂时没有调优空间，且经过三方确认，一致通过后方可结束。

注意事项

构造测试数据的注意项

先简单场景，再复杂场景，测试业务上可能出现的各种情况。
- 性能测试如同功能测试，也需要用于覆盖业务可能出现的各种情况的测试用例；
- 设计用例/场景时，可由简单到复杂，逐步覆盖更多条件；这两种反映了不同级别的性能，都不可少；
- 简单场景可能是先详细测下某个功能点、或者某个接口、或者某个业务的“单点”性能，有利于小范围内确认性能瓶颈，优化代码；
- 在简单场景之后，会加入更多条件、或者按照一定的业务流程、复杂情况对组合场景进行测试，测试整个应用、或者整个系统的总体性能。

执行性能测试的注意项

关闭redis、manggo等相关缓存，测试最坏的情况。
- 缓存是性能优化的方法之一，对于不频繁变动的数据，为了加快访问速度，提高读的性能，同时减轻数据库压力，可以将数据在缓存中，但是缓存必须在数据被访问后加入缓存之后才会生效，同时，缓存也需要刷新机制，用于更新数据；
- 为了避免缓存数据失效或者系统刚上线或重启后，缓存还未生效的情况，此时系统访问压力及数据库压力比较大，在性能测试中就需要模拟没有缓存的情况。
脚本本地调通之后需要上传到性能平台执行（JMeter本地调通后脚本上传到性能测试平台执行）。
性能测试平台执行通过率100%（登录接口→业务接口），错误率0.00%;
执行多次，尽量减小偶然性带来的偏差。

实战篇

首先了解下性能测试的具体流程

如何进行性能测试

明确性能测试的指标
性能测试指标一定要清晰，这个指标是需要开发人员或者产品提供的，不清楚的情况下，一定要找他们讨论并敲定最终结果。
目标清晰了，性能测试就成功一半！不然做完了没有意义，就是白做。

性能测试评审
结合业务场景，评审性能测试的指标。
评审性能测试的计划或者用例。