揭开性能测试的神秘面纱
前言大家好，我是洋子，相信刚学习软件测试的同学都听说过性能测试、压力测试、负载测试、稳定性测试等等，在日常性能测试工作中，我们不用太关心这四者之间有什么区别，因为压力、负载、以及稳定性测试都是属于性能测试的范畴。
谈到性能测试，大家可能会想到Jmeter。网上有很多关于Jmeter的学习资料，但是请大家注意，学会Jmeter并不等于掌握了性能测试，Jmeter只是一个测试工具，用来辅助我们执行性能测试，除了Jmeter我们也可以选择其他的工具来执行性能测试。本篇文章不是一篇Jmeter的教程，而是带你了解性能测试完整的工作流程。
常见性能指标
在学习性能测试之前，我们需要了解常见的性能相关数据指标。性能测试的对象可以分为服务端和客户端。
对服务端接口进行性能测试，我们通常会关注如下数据指标：
·可用性：系统在面对异常时可以提供正常服务的能力
· QPS（Queries-per-second，每秒查询率）：QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准
· 平响（平均响应时间）：所有请求平均耗费的时间
· 并发数：并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。并发数=QPS*平均响应时间
· PV（Page View）：即页面浏览量或点击量，用户每次对网站的访问均被记录，用户对同一页面的多次访问，访问量累计
· 错误码：接口返回结果的HTTP状态码
· 吞吐率：单位时间内服务器处理的请求数来描述其并发处理能力
· 实例存活度：对多个机房实例同时进行性能测试后，实例正常运作的数量
· 业务关键指标：根据自己业务设定的性能数据指标
而对APP客户端进行性能测试时，关注的指标如下：
· 内存
· CPU
· 网络流量
· 电量
· 启动速度
· 滑动速度、界面切换速度
· 与服务器交互的网络速度
性能测试步骤
在实际工作当中进行性能测试，一般有如下五个步骤：
· 准备
· 执行
· 分析
· 调优
· 验证
下面我以服务端性能测试为例，讲解各阶段该怎么做。
准备阶段
需要深入了解性能问题对象并对性能问题进行粗略评估，还需要了解服务的整体架构、对应的服务器信息，对系统应用的熟悉程度，在很大程度上决定了是否能更快的发现问题，比如需要梳理压测接口及接口的依赖下游，准备压测环境，redis缓存的填充，准备接口入参（线上引流或数据构造），监控指标的配置，熔断方案。
跟产品经理以及开发沟通本次性能测试的方案，包括确定被测系统、要进行压测的接口，确定本次压测的接口的最高QPS，制定应急预案，确保执行测试出现异常时，有人及时跟进处理。
性能测试方案制定完成后，还需要准备监控平台，用于监控当前测试的状态以及各项性能指标。
编写压测脚本用于批量发送压测的接口请求，也可以使用Jmeter 这样的测试工具，在成熟的公司里面，一般会有通用的压测平台，配置压测任务即可进行性能测试。
执行阶段
在执行性能测试时，若某个接口需要压1000 QPS。我们不会让它立马上涨到 1000，而是设置100 QPS为初始值，增长的步长也为100。因为我们一般是直接对线上环境的接口进行压测，这样做能保证线上服务不受影响，否则一下子提到很高的QPS，服务器可能会压崩溃。
分析阶段
达到预期的QPS以后，我们就可以停止压测，进行数据分析。通过分析准备阶段新增的监控进行收集问题信息，包括系统/业务监控报警，关联系统故障追溯；
此时还可以通过通过性能分析工具对问题进行初步定位。
下面几张截图是监控平台上的指标趋势，下图为可用性，可以看到可用性基本是维持在98%-100%。
下图为平均响应时间，基本是在100 ms。
下图为PV，有时候还会采集PV lost数据指标，PV lost是对服务器日志中的status为500状态码的日志做采集。
错误码，正常接口返回错误码是200，下图当中有少量499、404、504的错误码。
调优阶段
当我们在性能测试的指标发现异常后，就需要与开发配合，让开发优化代码修复性能问题。
根据定位到的瓶颈点针对性解决，包括应用性能调优，系统部署优化。
性能测试发现的常见问题有接口读取数据超时，优化方式一般是优化SQL查询语句、修改索引，或者增加 Redis 缓存直接从缓存读取数据等等。
验证阶段
在优化代码完成后，再次进行性能测试，与准备阶段的指标进行对比，观察数据指标是否正常，若已经达到预期效果则可以发送性能测试报告，完成本次压测。
结尾
以上就是一个较简单的，完整的性能测试过程，当然其中很有很多值得分析和探讨的内容，大家可以留言一起探讨，看到一张整理得比较好的思维导图送给大家。
页:
[1]
