[雪峰磁针石博客]性能测试艺术

为什么要进行性能测试h2>

什么是好的与坏的性能么性能测试在软件开发生命周期(SDLC software development life cycle)中很重要p>

性能不佳的应用通常无法实现企业预期利益，花费了大量时间和金钱，但是却在用户中失去了信誉。

相比功能测试和验收测试(OAT operational acceptance testing)，性能测试容易被忽略，往往在发布之后碰到性能和扩展性问题才意识到重要性。

最终用户眼中的性能

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

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

性能度量

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

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

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

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

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

性能标准

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

(Martin et al.,1988)的研究表明：

• 超过15 秒：基本上不适合交互。某些特定的应用，一些用户可能坐在终端等待超过15秒的时间去等待查询结果的返回, 比如公安局的 上预约系统。然而繁忙的呼叫中心运营商或期货交易商，超过15 秒无法容忍的。如果真的发系统就应该设计成可以让用户转向其他的操作，后面异步响应。
• 超过4秒：对于要求用户保存短暂记忆里的会话来说太长，当然交易完成之后，4-15秒的延迟是可以忍受的。
• 2-4 秒：超过2秒很难引起用户的高度关注。买家在输入了她的地址和信用卡 码后等待2-4秒的时间可以接受。然而如果是在早先的阶段，当她正在比较不同产品的差异时，却又是不可容忍的。
• 低于2 秒: 用户需要记住几个响应信息时，响应时间必须很短，如果要记住更为详细的信息，则要求就更高了。
• 亚秒: 思想密集型的工作来说（比如写一本书），尤其是一个图形应用程序，响应时间要非常短才能够保持用户的兴趣和长时间的关注。当艺术家将图片拖曳到另一个位置时，程序必须能够立即响应。
• 马上响应：按键并在屏幕上出现相应的字符，或者用鼠标点击，这种响应必须几乎是瞬时的。比如游戏。
• 由此可见，响应时间临界点是2秒。

参考资料

• 紧张整理更新中，讨论 钉钉免费群21745728 qq群144081101 567351477

• 更多python性能测试工具参考

  • 2018最佳12个开源或免费web服务器和客户端性能测试工具

糟糕的性能：为何如此普遍h3>

IT 商业价值曲线

Forrester在 2006年对典型应用系统上线后发现的性能缺陷进行了调查：

图中定义了三种性能测试。

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

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

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

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

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

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

扩展性

可能忽略了用户的地理分布和规模等。需要考虑如下问题：

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

了解流行度

很多公司低估其应用的人气，人是好奇的，系统发布的第一天，你估计1万次点击，结果却是100万次点击，您的应用系统就这样崩溃了！需要考虑高峰访问。

令人震惊的失败：一个真实的例子

很多希望了解家族历史,24小时之后 站崩溃了。在之后的几个星期里始终无法访问，直到最后重新发布。

性能测试还不规范

目前性能调优的书籍很多，但是对医生而言，最重要的是识别病情，识别性能瓶颈比解决问题有时更难。

不使用自动化的测试工具

不使用自动化的测试工具和自动化：单单使用手工是很难完成性能测试的。

应用程序使用技术的影响

应用程序使用技术的影响：某些新技术不太方便进行测试。

如何选择性能测试工具h2>

web方面的测试工具比较多。但是非web的，尤其是涉及到加密和压缩的，就很少了，甚至是https，很多工具都处理不好。

性能测试工具架构

常见的性能测试工具架构：

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

• 大量应用的 络来回：容易导致延迟、带宽限制和 络拥塞等。
• 应用错误：比如HTTP 404，500等。

足够的时间

以下工作需要时间：

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

代码冻结

设计性能测试环境

理论上要与生产环境完全一致，但是很多原因导致不太可能，下面列出部分原因：

• 服务器的数量和规格: 服务器内容和架构难以复制，尽量保持规格一致，以方便提供基准。
• 带宽和 络基础设施：地理位置难以复制。
• 部署层次：建议完全一致。

• 数据库大小：建议完全一致。

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

虚拟化

虚拟化的概念请参考：https://en.wikipedia.org/wiki/Virtualization 和 https://en.wikipedia.org/wiki/Docker_(software) 等。 注意：

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

云计算

可以简单理解云计算为商品化的虚拟主机，它便宜，容易部署。相关概念介绍参见：https://en.wikipedia.org/wiki/Cloud_computing 。

优点：

• 可以生成大量负载注射器。
• 便宜
• 快速
• 可扩展
• 易部署

缺点

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

负载注入容量

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

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

其他问题：

• 有些中间件不能用脚本表示。解决办法，从表示层入手；改用瘦客户端；自行开发工具。
• 衡量表示层性能：性能测试通常工作在中间件层。比如想计算用户点击复选框的时间，建议使用前端测试工具。

络部署模式

广域 的速度通常只有256 Kb左右， 络延迟也比较大。延迟的产生基于光速：1ms/130公里以及交换机、路由器等 络设备和服务器的时延。

如果有必要，可以：1，从WAN进行性能测试；2，测试工具模拟；3， 络模拟。

环境检查表

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

软件安装约束

比如安全考虑。

务实的性能目标

目标部分来自服务级别协议(SLA service-level agreement)。无论如何目标必须明确。

一致

一致且尽早介入。

业务

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

IT

?开发人员
?测试
?架构团队
?服务提供者（内部和外部）
?终端用户

?IT或运维

性能目标定义

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

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

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

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

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

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

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

关键的user case一般不会超过10个。

Use-Case检查表

• 记录每个步骤
• 输入数据和期望的响应
• 用户类型：新的或老用户，超级用户，客户，客服等类型。
• 络：LAN或WAN
• 主动还是被动

脚本验证

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

检查点

业务较复杂时尤其重要。

是否需要登入登出

尽量符合实际情况。

共存

注意共存的应用和 络共享

测试数据

输入数据

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

目标数据

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

会话数据

比如token。

数据安全

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

性能测试设计

性能测试的类型

1.pipe-clean测试。
2.容量测试。尽量接近用户实际使用。
3.隔离测试。
4.压力测试。退出标准：没有更多的用户可以登录，响应时间难以接受，或应用程序变得不可用。

5.浸泡测试，又叫稳定测试。发现内存泄漏等问题。

6.冒烟测试，只测试修改的部分。注意和其他地方的概念不一样。

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

负载模型

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

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

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

KPI

服务器KPI

Windows 性能工具。Linux有monitor、top,、vmstat、sar等工具。监控分为业务层、中间件层和系统层等。

通用模板如下：

? Total processor utilization %
? Processor queue length
? Context switches/second
? Available memory in bytes
? Memory pages faults/second
? Memory cache faults/second
? Memory page reads/second
? Page file usage %
? Top 10 processes in terms of the previous counters
? Free disk space %

? Physical disk: average disk queue length
? Physical disk: % disk time
? Network interface: Packets Received errors
? Network interface: Packets Outbound errors

Web和应用服务器层：比如nginx、WebLogic、WebSphere、Apache、JBOSS等。
数据库层：比如MYSQL、Oracle等。MongoDB, Cassandra和DynamoDB可以视为应用设计的一部分。
大型主机层：比如Strobe、Candle
主机层：比如亚马逊的CloudWatch。
络层： 络错误、延迟、带宽。

基于上述信息，可以输出：
1.制定包括资源，时间线和里程碑的高层计划
2.包括所有的依赖、相关时间线、详细的场景和use case，负荷模型和环境信息的性能测试计划。
3.风险评估。

另外还需要注意迭代。

性能测试环境准备

步骤如下：

1.足够的时间来采购设备，配置和构建环境。
2.考所有部署模型要在LAN和WAN环境实验。
3.考虑外部链接。
4.提供足够的负荷注入容量。比如云主机。
5.确保应用正确部署到测试环境。
6.软件授权。
7.部署和配置性能测试工具。
8.部署和配置KPI监控。

Use-Case脚本

针对每个user case：

?确定会话数据的要求。其中一些可能来自概念验证(POC)。
?确认并应用输入数据的要求。
?检查点。
?修改脚本
?脚本单用户和多用户都可以执行。

性能测试场景构建

? 测试类型是什么(pipe-clean, volume, soak, or stress通常是针对user case进行单个用户(pipe-clean)测试，产生基线数据。然后加大并发和吞吐量。之后进行混合user case的容量测试。然后可能有soak和stress测试，最后还可能结合负载均衡和容灾等测试。
?思考时间和步长(尤其是压力测试)。
?负载注射器和虚拟用户的数量。
?注入方式：Big Bang, ramp-up, ramp-up/ramp-down with step, or delayed start。注意这几种方式可能是连接的。比如下图：

标准偏差和正态分布: 高标准偏差表示用户体验不好。

百分比

响应时间分布

远 程监控：Windows注册表、Web-Based Enterprise Management (WBEM)、Simple Network Monitoring Protocol (SNMP)、Java Monitoring Interface (JMX)、Rstatd（传统的基于RPC的监控工具）

客户端需要关注：CPU百分比、内存使用、页利用率、磁盘时间、磁盘空间。

好的扩展性与响应时间：

• 混合移动应用
• 1. site: 很少用，IOS中用来避免Apple App Store，像移动应用，但是实质是移动 站。

终端用户体验监控与性能

主动监控

测试需要考虑：

参考 络图如下：

主动监控主要关注：可用性和响应时间。

文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览213140 人正在系统学习中 相关资源：点石排名软件-快速提升关键字排名-电子商务工具类资源-CSDN文库