性能测试：利用工具模拟大量用户操作，验证系统承受的负载情况。
性能测试的目的：找到潜在的性能问题或瓶颈，分析并解决；找出性能变化趋势，为后续扩展系统提供参考。
- 测试监控：基准测试、配置测试、负载测试、稳定性测试，对硬件和中间件进行监控。
1、学习业务：
通过查看文档、手工操作系统对系统功能进行学习。
2、需求分析：
分析系统非功能需求（关注业务量、业务分布、用户规模、性能指标等信息），确定性能测试范围，了解性能指标。
一、系统非功能需求采集
（1）系统架构：物理架构（硬件及部署策略）和逻辑架构（系统的功能与服务），包括中间件产品与配置、数据库配置等，供我们搭建测试环境时进行参考。
（2）业务流程：业务量和业务分布。采集业务（分析出哪些业务纳入性能测试范围）并量化业务、业务扩展趋势（年增长率或者未来的业务量）、业务发生时段（业务高峰的发生时间和高峰业务量）、业务分布（各项业务之间的比例）。
（3）用户信息：在线用户数、活动用户数、业务分布。有些系统用户量特别大，会对系统造成性能瓶颈，可以通过分析活动用户数和业务分布来分析负载情况。
（4）系统是否与第三方系统有关，是否需要做挡板（Mock程序）。
（5）系统是否有归档机制：如果数据库有归档机制？？？，可以把一些无用或者过时的信息移到归档库，这样就减少当前数据库的数据，有利于提高系统性能。
（6）性能指标：吞吐率、响应时间、事务成功率，CPU、内存、磁盘、带宽使用阀值。
二、系统非功能需求分析
确定性能测试范围
- 是否核心业务，是否要求严格的质量
- 是否高频次的业务
- 是否占用系统较多资源、或性能影响大的业务
- 使用人数多还是少
- 在线人数多还是少
- 确定此功能的可测性、可验证性：功能是否可验证（是否牵连到第三方程序，是否需要做挡板Mock程序）。
明确性能指标
业务性能指标
1. 吞吐量（PV）、吞吐率（TPS等）
2. 响应时间（RT）/ 应用响应时间（ART）：3秒以内
3. 事务成功率：99%以上
4. 稳定波动正常范围
响应时间2-5-8原则
当用户在2秒以内得到响应时，会感觉系统的响应很快；
当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；
当用户在5-8秒以内得到响应时，会感觉系统的速度很慢，但是还可以接受；
而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟糕透了，或者认为系统已经失去响应。
硬件性能指标
CPU、内存、磁盘、网络带宽等。
系统硬件指标阀值
这些指标比较抽象，在监控分析时应该进一步细化。比如CPU的性能指标在Linux中分为用户利用率、系统利用率及平均负载等重要指标。以上指标具体数据来源于非功能需求、组织要求（公司运维总结出来的可行性指标）或者行业标准建议。
分析业务量
测试数据的多少对测试结果会有影响。特别是数据成千万上亿条之后，性能影响明显，所以需要做足一定数量的历史数据。除此之外，还得关注业务的增长。如果系统需要满足未来三年的业务增长需求，那么在测试时就需要生成三年的存量业务数据。对于关系型数据库来说，数据最大时对性能的影响还是比较明显的。
估算TPS与并发数
一般我们会从运维那里得到整个系统在一天内按小时进行统计的PV趋势图。根据访问高峰业务量，估算出TPS与并发用户数等性能测试执行依据。一般采用二八原则，即80%的业务在20%的时间内完成。二八原则计算的结果是吞吐量（即TPS），而并发数 = TPS *（ThinkTime+RunTime）。
如果你的系统性能要求更高，也可以选择一九原则或更严格的算法，二八原则比较通用，一般系统性能比较接近这个算法而已，大家应该活用。
分析系统协议
一般性能测试脚本可以通过录制或者手动开发，而录制方式对协议的依赖性相当强。一般我们先分析系统协议（向开发团队咨询，或者截包分析），再评估用什么工具完成。HTTP可以用JMeter或者LoadRunner，Java接口可以用JMeter的JavaRequest元件与JUnit元件测试。
三、性能测试从哪里获取需求？
一般需求文档中会有一部分章节用于描述系统非功能性需求，但是多数需求文档对于性能需求的说明都比较笼统抽象。在需求不明确的情况下，通常需要性能测试工程师主动向需求提供方（BA团队、产品团队等）去征询。
对于升级、优化类的老系统，可考虑是否存有历史测试方案参考，或许可以省事很多。或者我们分析原型系统业务数据即可，最直接的办法就是分析原型系统的数据、统计业务量、业务分布等信息。
3、工作评估：
工作量分解，评估工作量，计划资源投入（即需要多少人力，多少工作日来完成性能测试工作）。
4、设计模型：
圈定测试范围后，把业务模型映射成测试模型。
业务模型：业务流程，系统在某个时间段内运行的业务种类及其业务占比，即哪个业务在什么时段在运行，业务量是多少？
测试模型：从业务模型中分析整理出来的需要进行测试的业务。对业务进行拆分对象，实现这个完整的功能包含哪些流程、环节。比如“购买商品”，具体的流程环节包括“登录->搜索商品->提交订单->支付订单->退出”。接着，明确业务占比，重要程度，目的在于：
（1）明确重点测试对象，安排测试优先级
（2）建模，混合场景中，虚拟用户资源分配，针对不同业务功能施加不同的负载。
（3）明确下“需求分析-指标分析”中相关业务功能所需基础数据及数据量问题，因为那块需求分析时可能只是大致估算下，评估指标是否合理，需要认真再分析下。
有些因为特殊原因无法测试（比如第三方非开源加密程序，测试程序无法模拟）的业务，测试模型中将会去掉这部分业务，或者设计替代等价方案，比如第三方程序可以使用挡板程序实现。
性能测试场景：参照用户使用习惯设计负载场景，比如哪些业务的测试脚本一起运行，哪些业务有先后顺序，运行多少并发用户等。比如WMS系统（仓库管理系统），WMS中都会有盘点功能，此功能就不应该与日常功能混合在一起，因为盘点通常都是一个月一次。所以组织测试场景时尽量要与实际业务情况一致。
5、编写计划
在文档中明确列出测试范围、人力投入、持续时间、工作内容、风险评估、风险应对策略等。
- 系统概述：简述系统使命、系统功能，用于给非专业人士了解系统是做什么的。
- 测试环境：生产环境、测试环境（服务器+负载机）的硬件架构和详细配置信息。
- 需求分析：需要测试的业务模型及其信息采集，性能指标的采集和确定。
- 测试策略：测试目的、测试执行的可行性分析、具体的测试手段及测试监控策略。
- 测试场景：如何组合业务场景进行性能测试。
- 测试准备：包括：测试工具的准备（负载工具、监控工具、文档管理工具）；测试脚本及测试程序准备；测试数据准备；测试环境准备。
- 时间计划：进行需求分析、测试策略后，就可以相对合理的估算测试资源及耗时。
- 测试组织架构：测试相关干系人，明确不同干系人的工作职责。
- 交付物清单：性能测试计划、性能测试脚本、性能缺陷报告、性能测试阶段性报告、性能测试报告（包括且不仅限于事务成功率、TPS、硬件性能指标等）。
- 系统风险：风险预测及风险评估（包括且不仅限于人员风险、软件风险、进度风险、变更风险、系统风险、数据风险、环境风险），并提出应对策略。
6、开发脚本
录制脚本或手动开发，添加固定计时器模拟ThinkTime，增加同步定时器模拟集合点，增加IF条件控制器判断逻辑，添加后置处理器获取参数。脚本注意做断言？？？，验证事务是否成功。
开发挡板程序，开发测试工具等。
事务定义
合理的定义事务，能够方便分析耗时（特别是混合业务功能场景测试），进而方便分析瓶颈。比如，购买商品，我们可以把下订单定义为一个事务，把支付也定义为一个事务。
7、测试环境准备
测试环境包括服务器和负载机。找出这些：
- 请求顺序、请求之间相互调用关系。
- 数据流向，数据是怎么走的，经过哪些组件、服务器等。
- 预测可能存在性能瓶颈的环节（组件、服务器等）。
- 明确应用类型IO型，还是CPU消耗性、内存消耗型->弄清楚重点监控对象。
- 关注应用是否采用多进程、多线程架构->多线程容易造成线程死锁、数据库死锁，数据不一致等。
- 是否使用集群/是否使用负载均衡。
生产环境和测试环境的硬件架构和配置需要进行估算，否则结果会有很大的偏差。了解测试环境部署和生产环境部署差异，是否按1:1的比例部署。通常建议测试时先不考虑集群，采用单机测试，测试通过后再考虑使用集群，这样有个比较，比较能说明问题。
8、测试数据准备：
准备被测系统的主数据（保证系统能够正常运行的数据，比如论坛版块、角色、用户等数据）与业务数据（运行业务产生的数据，比如订单；订单出库需要库存数据，库存数据也是业务数据）。
我们知道数据量变会引起性能的变化。在制作测试数据时，一要注意量，需要准备足够的存量/历史业务数据，二要注意数据的分布。比如我们计算出需要并发100个虚拟用户，我们至少需要准备100个以上账号，并对账号赋予相应的权限（浏览、发帖、删除、查询）。
那么准备多少数据够用呢？
往往性能测试需求会要求我们对系统进行定容定量，所以测试过程会经历如图的曲线变化；我们需要跨过③到达④这个阶段，所以至少需要准备在④这个点所需要的用户账号。
RT&TPS和Thread的趋势图
另外，为了更形象的模拟用户使用情况，我们会希望使用尽可能多的模拟用户（即并发用户数），通过ThinkTime来调节这些模拟用户产生的负载（因为，并发用户数=TPS*(ThinkTime+RunTime)。ThinkTime时间越长，所需要的并发数越大，请求数量越多，TPS也会相应增加）大小，用户越多越好。
数据制作方法
可以使用工具、SQL或者存储过程？？？来完成。建议使用SQL，同时还能够熟悉数据库的物理设计（索引、字段、范式、反范式等）和ER关系？？？
9、测试执行
测试执行是性能测试的关键，同样的脚本不同执行人员得出的结果可能差异较大。这些差异主要体现在场景设计与测试执行上。
场景设计
前面已经确定了测试模型。场景设计是根据测试模型与目标，组织虚拟用户、组合业务种类到一个测试单元。组织测试场景时尽量要与实际业务情况一致。
基准测试
采用单业务场景、单用户的方式执行脚本。用于验证测试环境、测试脚本，以及为后续的测试执行提供性能基准。比如一个登录系统，如果系统登录时间为8秒，那么这个系统也就没必要再进行性能测试，因为它连一般性能都达不到要求。
配置测试
配置测试场景一般为混合场景（多个业务同时执行），用于帮助分析系统软、硬件配置是否满足性能需求指标，优化配置使各项资源达到最优分配原则。测试过程是一个实验过程，先是找出不合理配置，然后进行修改，最后进行验证；周而复始到配置满足需求。
负载测试
负载测试的目的是分析性能变化趋势，找出性能拐点分析性能问题与风险，对系统进行定容定量；为系统优化、性能调整提供数据支撑。负载测试分为单场景与混合场景；单场景有利于分析性能问题，因为排除了其他业务干扰；混合场景更贴近用户实际使用习惯，是一个综合的性能评估。建议先做单场景测试再做混合场景测试。
负载测试的性能变化曲线图见前面的 “RT&TPS和Thread的趋势图”，①可以理解为单业务、单用户时的系统性能，②通常是我们估算的满足性能需求的点，③是性能拐点，之后性能变差，在这个点系统吞吐量达到最大，④这个点已经过载，吞吐量开始减小。负载测试一般需要找到②③④这三个点，通常会因为一些配置、程序问题而受到干扰，所以执行测试也是一个耗时的工作。
稳定性测试
稳定性测试在正常性能阀值下尽量加大负载，长时间运行，确定系统的软、硬件环境是否运行稳定。什么是阀值呢？比如响应时间要求3s以内，3秒就是阀值；比如CPU利用率70%以下，70%就是阀值。假设满足性能要求的负载是B，那么稳定性测试时负载一般是1.5B~2B。执行时采用混合场景，按惯例执行时间不低于8小时。时间上越长越好，有些隐藏较深的诸如内存溢出的问题是需要长时间运行才能反映出来的。
测试监控
测试监控
测试执行
一般第三方性能测试会有一个测试准入条件（Checklist）。如果是项目组内的就没有这么严格了，但基本内容不变。
（1）检查网络环境
确保环境独立，不会对生产系统、外部系统等的使用造成影响。
确保环境可靠，不会因为生产系统、外部系统而影响测试结果。
为了方便分析问题，排除网络IO的影响，测试在局域网中进行。
（2）检查测试数据
确保基础数据完整，能够支持性能测试脚本对业务功能的覆盖。
确保基础数据量，能够支持性能测试脚本的参数化要求。
确保存量数据量，能够尽量真实反映系统数据环境。
确保存量数据分布，能够对结果施加有意义的影响。
（3）检查监控设备
监控工具是否已经准备完毕可用。
（4）脚本检查
确认脚本能够模拟业务场景。
确认脚本无性能风险不影响测试结果。
注：具体的测试执行详细见 场景设计与测试执行
10、缺陷管理
对性能测试过程中发现的缺陷进行管理。
11、性能分析和性能调优
性能测试工程师与开发人员一起来解决性能问题。
13、测试报告
如何由测试环境推算生产环境配置
对于报告人来说，报告的是工作，是对整个测试过程的报告。对于决策层（报告相关干系人）来说关心的是结果，决策层迫切的想知道Yes or No，系统能不能上线，如果不能上线，有什么问题，怎么能够尽快解决？这两方面的需求决定了测试报告需要包含以下内容。
- 性能测试背景：测试原因，性能测试开展的必要性。
- 性能测试目标：对系统进行定容定量、响应时间、配置、稳定性等测试，风险评估。
- 性能测试范围：参考测试计划中的测试范围。
- 名词术语： 涉及专业名词的解释，参考测试计划。
- 测试环境：报告结果基于的测试环境，不同的环境结果可能大相径庭。
- 测试数据：报告测试数据量，参考测试计划。
- 测试进度：报告测试过程，什么时候做什么工作，比如哪一天执行了哪些测试脚本。
- 测试结果：基准测试、配置测试、负载测试、稳定性测试等，全面多方位的报告测试结果，TPS、ART、事务成功率、硬件资源使用率（CPU、内存、网络、IO等）。
- 测试结论：分析给出测试结论，系统能否满足性能要求？存在什么问题？有哪些缺陷？解决了哪些问题？还有哪些问题没有解决？列出仍没有解决的系统缺陷。
- 系统风险：报告系统可能存在的风险，帮助决策层应对风险。
测试报告要非专业人士也能看懂，做好指标对比、用图表表达性能变化趋势。
网友评论