性能测试简介

概念:通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

Why
评估系统能力、识别体系中的弱点、系统调优、验证稳定性可靠性。
性能不佳的应用通常无法实现企业预期利益，花费了大量时间和金钱，但是却在用户中失去了信誉。
相比功能测试和验收测试(OAT operational acceptance testing)，性能测试容易被忽略，往往在发布之后碰到性能和扩展性问题才意识到重要性。

Who
测试、开发、架构师、用户等。

When
预研、单元、接口、系统、在线监控等。

图片.png

最终用户眼中的性能

性能”是用户最终的感受。性能优异的应用在最终用户执行某项任务时不会产生过度的延迟而引起用户的不满。好的应用不会在登录时显示空屏，不会让用户走神。比如偶然的用户在购物网站上寻找和购买他们所需要的东西时，客户中心不会收到差性能的投诉。

多数应用系统在峰值时性能表现不佳。从高层看，应用由客户端软件和基础设施组成，后者包括了运行软件所需的服务器硬件和网络基础设施。另外有些应用还有第3 方服务。任何一个组成部分中出现问题，整个系统的性能就将面临灾难。您可能会简单地认为，为了保证应用性能，观察应用每个部分在负载压力下的运行状况并且 解决所出现的问题即可。这种做法往往“太少”和“太迟”了，因此只能是治标不治本。

关键业绩指标(KPIs key performance indicators)有服务和效率两种。

基于服务的：衡量应用系统为用户服务的好坏。

• 可用性(Availability): 终端用户可以使用的应用的总时间。可用性很重要，小小的故障也会导致大量的商务上的花费。用户无法有效地使用该应用系统，比如应用不响应或者响应慢到无法接受
• 响应时间(response time)：一般指系统响应时间。即用户发起请求到收到结果的时间。响应有异步和同步两种。

基于效率的：衡量应用对基础设施的利用。

• 吞吐量(Throughput)：应用处理速度，比如一定时间内某个页面的点击数。
• 利用率(Utilization)：理论资源的使用率。当1000个用户同时在线时，应用消耗了多少网络带宽及在服务器内存和cpu等使用情况。

图片.png

性能标准

没有正式的行业标准，但是有许多非正式的标准，试图对系统的性能好坏做出评价，尤其是B/S应用。比如“页面最小刷新时间”从20秒到8秒，现在是2秒最佳。用户和企业都希望系统能够“即时响应”，但现在这样的性能很难达到的。

三种性能测试

• 救火(Firefighting)，发布前很少或从来没有性能测试。所有性能缺陷在生产环境上发现解决。这是最不可取的，却依然比较普遍。
• 性能验证(performance validation)。公司为性能测试在产品的后期安排了时间，生产环境会发现30%左右的性能bug。这个当前绝大多数公司的做法。
• 性能驱动(performance driven),生命周期中的每一阶段都考虑了性能, 生产环境会发现5%左右的性能bug。

图片.png

为什么性能如此糟糕？

• 系统设计阶段缺少性能方面的考虑。

设计的时候考虑性能有望产出好性能的应用，至少也能使应用在出现意想不到的性能问题时灵活地能进行修改或重新配置。设计相关的性能问题后期才发现就很难解决，有时候甚至需要重新开发。

多数的应用基于可独立测试的组件进行开发的，组件在单独执行的时候性能可能都不错，切记必须从整体来考虑。这些组件之间的交互必须高效且扩展性好，集成后才会有好的性能。

• 直到最后一刻才进行性能测试

性能验证模式下，性能测试直到系统发布前才会进行，并且很少考虑到性能测试所需的时间及失败后所造成的后果。可能无法发现一些严重的性能缺陷或发现了性能问题但却没有时间解决。

• 用户考虑。
  有多少终端用户会实际使用？
  用户位于何处？
  多少用户会同时使用？
  用户如何连接到应用？
  后期有多少额外的用户需要访问应用？
  应用的服务器数量及网络拓扑？
  将应用对网络容量产生什么影响？

• 性能测试还不规范
  目前性能调优的书籍很多，但是对医生而言，最重要的是识别病情，识别性能瓶颈比解决问题有时更难。
  不使用自动化的测试工具
  应用程序使用技术的影响

更多详细资料参见： 性能测试艺术

性能测试工具概览

性能测试工具架构

• 脚本：描述用户的活动，支持不同协议。
• 测试管理模块: 创建并执行性能测试会话或场景。
• 负载生成器: 生成负载。
• 分析模块: 分析数据，有些还有自动分析的专家模式。
• 其他模块: 监控服务器和网络性能的同时，与其他软件集成。

选择性能测试工具

• 协议支持
• 授权：比如最大虚拟用户数；能支持的额外协议；附加插件集成和特定的技术栈监控，比如Oracle, Python等，)可以与APM(application performance monitoring)与CI(continuous integration)集成。
• 脚本支持：稍微复杂一点的测试就需要深入脚本。考虑脚本修改的难度；考虑测试团队的技术水平。
• 解决方案与负载测试工具: 有些厂商只提供个负载测试工具，而有些提供性能测试解决方案。解决方案产花费更多，但通常功能更强大，可能包括自动需求管理，自动数据创建和管理，预性能 测试的应用程序调试和优化，响应时间预测和容量建模，APM提供类和方法层面的分析，集成用户体验（EYE）监控，管理测试结果和测试资产等。
• 外包：可以免去工具选型等。但是次数太多的成本太高。
• 其他：基于云平台的测试。节约硬件成本。缺点：次数太多的成本太高，性能指标监控未必方便。程序不稳定时代价很高。

图片.png

• 自行开发工具
  多进程、多线程、异步、multi-mechanize boom locustio等
• 协议
  FTP、IMAP、HTTP 、SNMP等
• 其他工具
  Fiddler MITMProxy Wireshark tcpdump postman等

工具选择概念验证(POC)

 POC至少要有两个用例：读数据和写数据。目的如下：

• 对性能测试工具是否适合目标应用进行技术评估。
• 识别脚本数据要求
• 评估脚本需要的编写和修改时间
• 展示测试工具的容量。

图片.png

有效的性能测试

考虑的因素

• 项目计划
• 应用够稳定
• 足够的时间
• 代码冻结
• 基本的非功能需求
• 设计合适的性能测试环境
• 设置现实合适的性能目标
• 确定并脚本化的关键use case
• 测试数据
• 负荷模型
• 精确的性能测试设计
• KPI(Key Performance Indicator)

应用够稳定
功能要运行稳定，不能10次运行，2次失败。避免性能测试成为频繁的bug修改实践。功能等问题会掩盖性能问题。要有严格的单元和功能测试保证。

衡量标准如下：

• 简洁的数据表示：没有比如大量图片和冗余会话，尤其是移动互联网场景。
• 高效的SQL：关系数据库基于索引，很少有慢查询；noSQL尽量少使用连接等。
• 没有不必要的网络请求
• 功能稳定：比如HTTP 404，500等错误较少。

图片.png

足够的时间

• 准备测试环境
• 配置负载注射器
• 识别user case(数天到数周)和脚本化
• 确定和创建测试数据(数天到数周)
• 测试环境安装配置
• 问题解决

环境

• 理论上要与生产环境完全一致，但是很多原因导致不太可能，下面列出部分原因：
• 服务器的数量和规格: 服务器内容和架构难以复制，尽量保持规格一致，以方便提供基准。
• 带宽和网络基础设施：地理位置难以复制。
• 部署层次：建议完全一致。
• 数据库大小：建议完全一致。

也有公司直接在生产环境同时部署测试环境或者直接拿生产环境做性能测试，后者注意不要影响用户，包含数据和服务等。

图片.png

环境
性能测试的环境类型有

• 生产环境非常接近的副本：通常不太现实。
• 生产环境的子集，层次一致，服务器规格一致，但是数量有所减少：建议达到的方案。
• 生产环境的子集，层次有缩减，服务器规格一致，但是数量有所减少：最常见的方案。

虚拟机

• 虚拟机管理程序层有管理开销
• 总线和网络的通信方式不同。前者没有带宽和延迟限制。在网络跨地理位置的情况尤其需要注意。建议虚拟化与生产环境一致。特别注意不要跨层虚拟化在同一机器。
• 物理与虚拟NIC：后者的开销更大。

云主机

• 可以简单理解云计算为商品化的虚拟主机，容易部署。
• 可以生成大量负载注射器。
• 使用次数不多便宜
• 快速
• 可扩展
• 易部署

缺点

• 不及时关闭很贵
• 有时不可靠，比如配置的机器无法启动，IP被墙等。

负载注入容量
单机能模拟的虚拟用户是有限的，特别注意测试机的CPU和内存等使用率不要过载，尽量使用多的机器机进行测试。注意以下几点：

• 负载均衡：一些基于IP分配服务器。
• 用户会话限制：比如一个IP只能一个会话。必要的时候需要使用IP欺骗。

网络
如果需要需要从广域网测试，考虑：1，从WAN进行性能测试；2，测试工具模拟；3，网络模拟(比如linux的iptables和tc命令等)。

环境检查表

• 服务器数：物理或虚拟服务器的数量。
• 负载均衡策略：负载均衡机制的类型。
• 硬件清单：CPU的类型和数目，内存，网卡的类型和数量。
• 软件清单：标准版本的软件清单(不包括中间件)。
• 中间件清单。
• 内部和外部链接

另外还需要考虑软件安装约束，比如安全考虑。

图片.png

一致且尽早介入。需要多个部门的通力合作。

C级管理负责预算和策略决定：
•首席信息官（CIO Chief information officer）
•首席技术官（CTO Chief technology officer）
•首席财务官（CFO Chief financial officer (CFO)）
•部门负责人

操作人员
•开发人员
•测试
•架构团队
•服务提供者（内部和外部）
•终端用户
•IT或运维

性能目标主要包含可用性、响应时间、吞吐量、并发、网络利用率和服务器利用率。

在性能测试中并发是同时在线的用户。要注意并发虚拟用户和并发实际用户不一定是同一回事。估算时需要基于二八原理和峰值等。

图片.png

务实的性能目标

吞吐量通常更适合衡量无状态的行为。比如浏览购物时通常不会登录，看中之后才会登录，浏览购物可以认为是无状态的。

响应时间不要随着并发的增加而大幅度增加，可以基于单个用户做基准测试。

网络利用率需要关注数据量、数据吞吐量(可能会导致吞吐量突然下降是容量问题)和数据错误率。

服务器利用率主要关注CPU、内存和I/O(磁盘和网络等)

确定和脚本化关键业务user case
关键的user case一般不会超过10个， Use-Case检查表如下：
•记录每个步骤
•输入数据和期望的响应
•用户类型：新的或老用户，超级用户，客户，客服等类型。
•网络：LAN或WAN
•主动还是被动

确定和脚本化关键业务user case

脚本验证：基于文档或抓包工具或录制工具书写脚本，然后单用户到多用户调通。注意脚本不要影响到并发的执行，尽量使用不同的用户等。

检查点：业务较复杂时尤其重要。

是否需要登入登出：尽量符合实际情况。

共存：注意共存的应用和网络共享

测试数据

输入数据

• 用户凭据：比如用户名和密码。
• 查找规则：通过客户的姓名和详细地址，发票号和产品码甚至是通配符进行查询。
• 相关文件：比如图片。

目标数据：需要考虑数据容量是否符合规格的大小，数据回滚等。

会话数据：比如token。

数据安全：数据要保密，同时性能测试工具要实现与服务器端通信的加密方式。

图片.png

性能测试的类型
1.pipe-clean测试。
2.容量测试(volume)。尽量接近用户实际使用。
3.隔离测试。
4.压力测试(stress )。退出标准：没有更多的用户可以登录，响应时间难以接受，或应用程序变得不可用。包含弹力和冲击测试等。
5.浸泡测试(soak)，又叫稳定测试。发现内存泄漏等问题。
6.冒烟测试，只测试修改的部分。
7.基准测试

pipe-clean, volume, stress和soak test通常都需要进行。

负载模型
负载模型定义了user case的负载分布及并发和吞吐量的目标。通常先基于容量测试，再扩展到其他类型。注意测试数据、思考时间和步长的影响。比如搜索数据分类：

• 小数据模型：具体的产品名称或ID。
• 中数据模型：局部产品名称。
• 大数据模型: 通配符或最小的产品名称的内容。

图片.png

需要模拟真实情况下各种user case的分布。

吞吐量模型对于已有应用可参考Google Analytics或WebTrends，新应用的需要估计。

思考时间代表着延迟和暂停。步长是循环之间的间隔。

负载注入：Big Bang、Ramp-up、Ramp-up (with step)、Ramp up (with step), ramp down (with step)、Delayed start。注意"with step"主要是为了方便观察。

KPI参考初级的介绍。

图片.png

参考资料

• 讨论qq群144081101 591302926 567351477 钉钉免费群21745728
• 本文最新版本地址
• 本文涉及的python测试开发库 谢谢点赞！
• 本文相关海量书籍下载
• 本文源码地址