高级性能测试——01 正确理解以及开展性能测试

一、性能测试的目的及误区

1、什么是性能测试

性能测试：属于软件测试范畴，旨在测试处于特定环境和配置下是系统在一定的负荷下，系统的正确性、响应时间、速度、成功率、稳定性、可恢复性等特性是否满足特定干系人需求的能力。系统性能关乎用户的体验，性能属于产品的非功能质量特征。
不符合需求情况下:结合系统的业务模型、环境配置、设计、实现细节等识别出问题，并最终确保该问题得到妥善解决的过程。

2、性能测试的目的

（1）基本目的
验证是否达到用户的性能指标
发现软件中存在的性能瓶颈并优化

（2）评估系统能力
测试中得到的负荷和响应时间数据，用于验证所计划的能力
帮助做出决策

（3）识别体系中的弱点
受控的负荷可以被增加到一个极端的水平，并突破它
恢复体系的瓶颈或薄弱的地方

（4）系统调优
重复运行测试，验证调整系统的活动是否得到了预期的结果
改进性能，如：长时间的测试执行可导致内存泄漏

（5）验证稳定性
在一定生产负荷下执行测试一定的时间评估系统稳定性和可靠性是否满足要求

3、性能误区

性能测试=性能测试工具的使用（目标不明确、缺乏规划）
性能测试=功能测试+并发量（测试所有场景）
性能测试=GUI界面性能测试（app、web、小程序多管齐下）
解释：一般都是采用http/https 协议来与服务器进行连接的，所有只要有接口就可以模拟测试就行
性能测试=性能脚本运行（缺乏数据收集、分析、调优过程）
实验室下性能指标=实际环境下性能指标（忽视环境的差异）
采用功能测试的思维开展性能测试（性能测试通常采用实验的形式，迭代地进行以支持系统分析、设计和实施）

4、哪些质量特性与性能密切相关

【解答】：功能、安全、可靠

二、性能测试方法以及流程

1、性能测试相关知识体系

系统业务
系统架构（数据库和web服务器是否在同一台电脑，怎么对接的，操作系统是什么）
测试方法
测试策略
支撑系统
监控工具
负载工具
分析工具

2、性能测试方法

验收性能测试（这个是有指标的）
负载测试
压力测试
并发测试
配置测试
可靠性测试（时间上的可靠性）
恢复性测试

3、性能测试的流程（如何展开性能测试）

需求分析：分析业务场景，分析用户需求，分析要测试的点
测试准备：测试计划的编写、搭建性能测试环境（硬件软件环境的准备）、测试工具、配置的选定、准备脚本、编写性能测试用例
测试执行
结果分析（问题的定位）与调优
报告与总结

4、性能测试的应用领域

能力验证/性能验收（有指标、有需求）
能力评估/性能评估（没有指标–>探索）
发现缺陷
性能调优
性能基准比较（多套环境的时候需要比较:硬件配置对比、软件配置对比）

案例分析如下：
boss：小小，主干功能已经测试通过，你来做性能测试？
小小：性能测试应用领域是什么？
性能验收（有指标、有需求），发现问题，性能调优

A系统白天高峰期每秒钟要有1000个用户同时发请求，要求每个请求响应时间小于1s，成功率100%，cpu小于80%,内存使用率低于90%，磁盘空间：使用率低于70%，网路宽带：基于Dell服务器小型机24内核、96G内存、磁盘16TB、宽带5M.
方法：负载测试法（TPS=1000）
性能评估（探索），发现问题，性能调优

（1）能力验证
概念：某系统能否在A条件下具备B能力
特点：1）需求在已明确的环境下运行；2）需求根据典型场景设计测试用例和方案
使用方法：负载测试、可靠性测试、压力测试、失效恢复测试
强调：当前能力

（2）验收性能测试
1)概念：模拟生产上线业务环境，测试是否满足性能要求
2)特点：
确定用户的环境
用户要求的性能指标
执行、分析结果
验收性质
一定要有客观性结果
3)案例：A系统用户登录功能要求同时支持100TPS，成功率为100%，平均响应时间小于2s，系统各项资源使用率（cpu、内存、宽带、磁盘空间）低于80%，运行持续时间12小时

（3）性能评估(能力规划)
有指标我们就验证指标，没有指标我们就评估来获得指标
概念：在某种可能发生的条件下，系统具有如何的性能能力
特点：1）探索性性质；2）考虑软件系统的拓展性
使用方法：负载测试、配置测试、压力测试

（4）高并发下的业务缺陷发现
目的：通过性能测试手段来发现系统中存在的缺陷，通常经历如下过程：
单用户—>低并发—>高并发-压力测试—>极限测试—>系统失效

（5）性能分析与调优
1）调优方向
软件架构
硬件环境
代码
tomcat参数
2）使用方法：压力测试、负载测试、配置测试、失效恢复测试
3）案例：比如线上课堂签到业务–响应时间是5s，学生提出响应时间慢–需要优化–提速

（6）稳定性（时间+负载）测试
目的：测试系统在一定负载下运行长时间后是否会发生问题。
常见案例：这种问题一般是程序占用资源却不能及时释放而引起的。比如，内存泄漏问题就是经过一段时间积累才会慢慢变得显著，在运行初期却很难检测出来。
针对有冗余备份和负载均衡的系统设计。用来检验如果系统局部发生故障，用户是否能够继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响
关注系统对突然爆发的峰值负载做出正确反应并随后恢复到稳定状态的能力
测试系统能否快速地从错误状态中恢复到正常状态

（7）变更环境下的性能测试（基准对照）
当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。
按照基准测试的方法，需要打开/关闭新模块至少各做一次。
关闭模块之前的系统各个性能指标记下来作为基准，然后与打开模块状态下的系统性能指标做比较，以判断模块对系统性能的影响。
关注系统满足未来效率需求的能力，这可能超过了现在的需求。测试的目标是在不违反当前的性能需求也不产生实效的前提下，确定系统的增长能力。一旦确定了可扩展的极限，就可以在生产中设置和监控，在可能出现问题时发出警告。

三、什么时候需要做性能测试

业务系统对性能有明确的要求–性能验收
需要评估业务系统的性能效率–性能评估
验证在高并发下，系统业务是否有问题–功能缺陷发现
验证高并发下，技术架构是否有问题–技术缺陷发现/性能调优
验证在高并发下，系统是否可靠运行–稳定性缺陷发现
验证在系统变更后，系统性能表现变化情况–基准对照
所以：在公司需要开展性能测试的时候，首先要弄明白现状的需求，为什么要做？
是性能评估、还是发现功能未能发现缺陷、还是技术问题、稳定性的问题、还是基准对照

1、性能测试中用到的测试技术(类型)

1）静态测试
关注性能及性能风险的需求评审
数据库架构、数据库设计、存储过程、语句执行效率的评审
系统和网络架构评审
系统关键部位的代码评审
2）动态测试
单元测试：分析关键节点性能效率与资源使用情况
集成测试：关注跨组件模块接口调用的性能
系统测试：在不同负载条件下检查总体端到端表现
验收测试：建立用户、客户、操作员对系统性能的信心，以及在真实条件下对系统进行调优

2、性能测试（负载生成的方法）

使用用户界面生成负载：适用于少量的用户量，并且可以使用所需数量的软件客户端来执行所需的输入（ui测试对于端到端的测试很适合，但对于性能测试不是很适用）
使用众测生成负载：依靠于大量的测试人员，代表真正的用户（不好重复操作，精确性不佳）
使用API生成负载：调用应用程序的API来模拟用户与系统的交互，该方法对用户界面中的更改不敏感
使用捕获的通信协议生成负载：通过工具和脚本来模拟用户端发出的通信协议与系统进行交互、具有复用性高、并发量大、可靠性高等优势。（我们大部分用这种方法来做性能测试）

3、PDCA-戴明环

Plan（计划）—Do（执行）—Check（检查）—Action（纠正）