本文将深入探讨性能测试的重要性，介绍不同类型的性能测试，并解释如何通过性能测试来优化系统性能。从产品经理的视角出发，我们将学习如何关注关键性能指标，以及如何阅读和理解性能测试报告。
小A接到个网站设计需求，由于是感兴趣的领域，拿到手可开心了。哼哧哼哧画了好几天原型，又拿着菜刀架在开发脖子上猛干了几天，终于在一个月黑风高的晚上上线了这个网站。
然而过了不久，客服电话被打爆，所有投诉都是一句话“你xxx还让不让人用了！一直在加载是什么鬼？”于是，在第一百个投诉打来的时候，小A已经骑着电驴去送外卖了。而导致小A捡瓶盖的罪魁祸首浏览人数过多，系统直接崩了。
至今，被采访的小A都表示“现在就是后悔，非常后悔，怎么就没盯下性能测试呢？”为了避免过早和小A合伙送外卖，我们一起来学习下性能测试吧。
01 什么是性能测试？
性能测试是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。
在产品上线前，我们无法知道用户数量，而且用户场景也存在不确定性，一旦用户多了就可能整出各种幺蛾子，所以需要进行系统性能测试。
性能测试可以告诉我们用户数量增加、系统负载增加时，系统能承受的并发用户数量，以及带宽是否够用、cpu是否够用、内存是否够用、硬盘速度是否跟得上等问题。
02 性能测试测什么？
性能测试的类型和划分网上有很多定义，我这取比较常见的几个
- 负载测试（Load Testing）：负载测试主要测试软件系统在不同负载下，性能指标是否符合预定指标，譬如在一定负载时，系统最大支持多少并发用户数，软件请求出错率等。
- 压力测试（Stress Testing）：压力测试是指在被测系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力。说人话就是看看在极端情况下系统还能不能转得起来。
- 容量测试（Volume Testing）：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。
03 作为产品需要关注的性能点有哪些？
为了安稳端好产品经理的饭碗，我们需要关注这些性能点：
- 系统处理一个请求或一个任务耗时多少？
- 系统最多支持多少用户访问、系统最大业务处理量是多少？
- 系统性能可能存在的瓶颈在哪里？
- 系统能否支持7×24小时的业务访问？
04 性能测试的常见指标有哪些？
上面叨叨了这么多，大家对性能测试和需要关注的内容应该有所了解了，那么作为产品，我们怎么对性能测试进行验收呢？为了防止被忽悠，这里我们需要了解一些性能的关键指标：
1. 外部指标- 吞吐量：每秒钟系统能够处理的请求数、任务数。
- 响应时间：服务处理一个请求或一个任务的耗时。
- 错误率：一批请求中结果出错的请求所占比例。
- 从服务器的角度看，性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等。
由于我们是只用指手画脚，不用自己操刀的产品经理，我们只需要重点关注外部指标就可以了。接下来我们学习这些外部指标。
对于响应时间，我们比较关注的是它的均值、中位值、P95值、P99值等。平均值和中位值比较好理解，P分位值是什么意思呢？以P95为例，将响应时间从小到大排列，顺序处于95%位置的值就是P95值。
系统吞吐量则有几个重要参数：QPS（TPS）、并发数、响应时间：
- QPS（TPS）：每秒钟request/事务数
- 并发数：系统同时处理的request/事务数
- 响应时间：一般取平均响应时间
QPS（TPS）=并发数/平均响应时间
可以看出一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降。
在低吞吐量下的响应时间的均值、分布比较稳定，不会产生太大的波动。而在高吞吐量下，响应时间会随着吞吐量的增长而增长，增长的趋势可能是线性的，也可能接近指数的。当吞吐量接近系统的峰值时，响应时间会出现激增。
上图便是吞吐量、响应时长、并发数几者的关系图。横坐标是并发数，绿线是CPU使用率，紫线是吞吐量，即QPS，蓝线是响应时间。
05 测试报告长啥样？
理论终归于实践，能看懂测试报告，那读这篇文章的目的才算达到了。
1. 测试概述1.1 测试目标
本次测试的目的在于探查XXX项目二期重构环境的系统业务处理性能，以及在高负载情况下的系统表现。
1.2 指标和术语
描述本次测试中涉及到的性能指标术语
2. 环境、工具2.1 测试环境
服务器：
客户机：
2.2 测试工具
3. 测试方案3.1 测试类型
本次性能测试将主要采用以下几种测试类型：
- 基准测试：在小并发条件下，探测系统各性能指标表现，作为后续比对基础。
- 压力测试：由于无法准确预估用户访问量，因此考虑使用压力测试方法。压力测试旨在通过不断 增加系统并发处理事务数，增加系统负载，直到系统到达性能瓶颈。以此推算出系统可承载用户和事务请求数。稳定性测试：
- 将系统置于较长时间高负载场景下，探测系统是否出现稳定性缺陷。
3.2 业务模型
针对系统接口，究竟哪些需要被纳入压测范畴？不同事务应该以何种比例被调用，这是需要建模设计的，也是性能测试的难点之一。
通过对于项目架构和业务场景分析，设计以下业务模型进行模拟和测试：
场景1：简单业务场景
场景2：混合业务场景
3.3 加密验签处理
由于系统对于所有事务请求都进行了加密验签处理，因此在本次性能测试中，需要对请求报文进行一致的加密和签名。处理逻辑如下：
- 使用APP同样的加密签名代码，导出jar包做为加密工具类
- 使用jmeter前置处理器-beanshell处理器调用上述jar包方法实现请求参数加密
- 将加密签名后的请求参数存储为变量，后续接口调用时使用
3.4 压力梯度
对于3.2所述场景，分别进行梯度加压，从100并发开始，每次递增100并发数，直至到达系统瓶颈。
4. 测试结果4.1 聚合报告
场景1-10并发-循环5次
场景1-500并发-循环1次
场景1-550并发-循环1次
4.2 系统吞吐量
场景1-550并发-循环1次
场景2-450并发-循环10次
4.3 资源占用率
最优负载条件下：CPU使用率
内存占用率
磁盘使用率
5. 分析和建议5.1 测试结论分析
经过多次测试和数据报表分析，可以得出如下结论：
- 当总体并发用户数为450-500时，系统具有最优性能表现；当事务并发数超过500时，事务失败率整体上升，系统到达性能拐点。
- 多事务混合条件下，系统巅峰TPS在90左右，平均吞吐量在13-18/s。
- 在小压力条件下（10并发），最大事务响应时间为查询用户信息事务的2042毫秒，平均在600毫秒左右系统。整体事务微观响应速度较优。
- 满负载条件下，登录具有最佳的性能表现，平均响应时间为7000-12000毫秒；查询用户信息事务性能较差，平均响应时间在30000-40000区间。满负载条件下系统整体微观响应时间较差。查询用户接口由于其使用极为频繁，建议进行SQL效率调优
- 系统资源方面，内存占用率始终处于高位水平（90%以上），磁盘空间由于日志写入而不断被占用。
5.2 问题
测试过程中发现了如下显著问题：
- 加密验签功能并未生效-现阶段任何签名均可通过验签。属于功能性问题，不影响性能表现。
- 日志文件由于不断写入导致磁盘占满，建议调低系统日志级别，并做好定期日志备份。
- 内存占用处于高位水平，需要进一步探查原因。
作者：阿宅的产品笔记；公众号：阿宅的产品笔记
本文由 @阿宅的产品笔记 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
友情提示
本站部分转载文章，皆来自互联网，仅供参考及分享，并不用于任何商业用途；版权归原作者所有，如涉及作品内容、版权和其他问题，请与本网联系，我们将在第一时间删除内容！
联系邮箱：1042463605@qq.com