性能测试：利用工具模拟大量用户操作，验证系统承受的负载情况。
性能测试的目的：找到潜在的性能问题或瓶颈，分析并解决；找出性能变化趋势，为后续扩展系统提供参考。

• 测试监控：基准测试、配置测试、负载测试、稳定性测试，对硬件和中间件进行监控。

1、学习业务：

通过查看文档、手工操作系统对系统功能进行学习。

2、需求分析：

分析系统非功能需求（关注业务量、业务分布、用户规模、性能指标等信息），确定性能测试范围，了解性能指标。

一、系统非功能需求采集

（1）系统架构：物理架构（硬件及部署策略）和逻辑架构（系统的功能与服务），包括中间件产品与配置、数据库配置等，供我们搭建测试环境时进行参考。

（2）业务流程：业务量和业务分布。采集业务（分析出哪些业务纳入性能测试范围）并量化业务、业务扩展趋势（年增长率或者未来的业务量）、业务发生时段（业务高峰的发生时间和高峰业务量）、业务分布（各项业务之间的比例）。

（3）用户信息：在线用户数、活动用户数、业务分布。有些系统用户量特别大，会对系统造成性能瓶颈，可以通过分析活动用户数和业务分布来分析负载情况。

（4）系统是否与第三方系统有关，是否需要做挡板（Mock程序）。

（5）系统是否有归档机制：如果数据库有归档机制？？？，可以把一些无用或者过时的信息移到归档库，这样就减少当前数据库的数据，有利于提高系统性能。

（6）性能指标：吞吐率、响应时间、事务成功率，CPU、内存、磁盘、带宽使用阀值。

二、系统非功能需求分析

确定性能测试范围

1. 是否核心业务，是否要求严格的质量
2. 是否高频次的业务
3. 是否占用系统较多资源、或性能影响大的业务
4. 使用人数多还是少
5. 在线人数多还是少
6. 确定此功能的可测性、可验证性：功能是否可验证（是否牵连到第三方程序，是否需要做挡板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等）。
• 测试结论：分析给出测试结论，系统能否满足性能要求？存在什么问题？有哪些缺陷？解决了哪些问题？还有哪些问题没有解决？列出仍没有解决的系统缺陷。
• 系统风险：报告系统可能存在的风险，帮助决策层应对风险。

测试报告要非专业人士也能看懂，做好指标对比、用图表表达性能变化趋势。

14、评审

性能需求分析

概述

首先对2003年和2004年的全年税收业务量进行了统计，总结出税收业务量的增长趋势，对2005至2009年的全年税收业务量进行了估算。以此为依据，同时结合税收业务量分布特点，按照省集中和全国集中两种模式，对用户访问量、系统处理能力、存储容量、网络流量等4个主要方面进行初步分析估算。

有必要指出的是，网络流量的估算与联网机构的接入方式密切相关，但是哪些联网机构可以集中接入，集中接入的层次，及集中接入机构的业务量在总业务量的占比各地差异很大；从地域上考虑，各联网机构在各省的集中程度也不尽相同，比如说，国税在部分省做到了省集中、而在另一部分省尚未做到省集中，至于地税、财政和部分城市商业银行的情况就更为复杂。

另外，在进行后续的估算中，考虑到税票业务量是本系统处理的主要业务，其他业务与税票相比，业务量相对较小。因此，我们暂以税票业务量作为估算的基础。

业务量统计

通过对国库局综合业务报表系统提供的全国各省税票业务量进行分析统计，得出如下结论，2003年全国税票业务总量大约有2.1亿笔，2004年全国税票业务总量大约有2.4亿笔；全国税票业务年增长率大约在15%左右。同时对各地上横向联网后，税票业务量变化趋势进一步考察发现，上横向联网后的第一年，某些地区税票业务量有突发性增长因素(如浙江，在上横向联网后的第一年,税票业务量增长了100%)，所以我们假设税票业务量每年增长趋势在20%左右。

税票业务量的大小直接影响到对系统处理能力、存储容量、网络流量等性能指标的高端要求，由于各省经济发达程度和税收体制的差异，造成各省的税票业务量存在很大差异。为了做到按需投资，合理配备资源，避免浪费，我们将各省根据2004年税票业务量大小分为4类：

1．按分库级分类

(1) 特大型，税票年业务量达到3500万及以上

包括上海、广州、南京、北京4个分库。

(2) 大型，税票年业务量达到1500万及以上，3500万以下

包括石家庄、沈阳、杭州、福州、济南、武汉、成都、大连、宁波、重庆、天津11个分库或营管部管辖分库。

(3) 中型，税票年业务量达到1000万及以上，1500万以下

包括太原、呼和浩特、长春、哈尔滨、合肥、南昌、郑州、长沙、南宁、西安、兰州、贵阳、昆明、乌鲁木齐、青岛、海口、深圳、厦门18个分库或营管部管辖分库。

(4) 小型，年业务量在1000 万以下

包括银川、西宁、拉萨3个分库。

2．按中心支库级分类

(1) 特大型，税票年业务量达到1000万及以上

如：佛山市中心支库。

(2) 大型，税票年业务量达到500万及以上，1000万以下

如：苏州市中心支库。

(3) 中型，税票年业务量达到100万及以上，500万以下

如：常熟市中心支库。

(4) 小型，年业务量在100万以下

如：安顺市中心支库。

3．按县支库级分类

(1) 特大型，税票年业务量达到500万及以上

如：广东佛山顺德。

(2) 大型，税票年业务量达到100万及以上，500万以下

如：江苏苏州吴江。

(3) 中型，税票年业务量达到30万及以上，100万以下

如：山东淄博淄川。

(4) 小型，税票年业务量在30万以下

如：陕西咸阳长武县。

3.2.3. 省集中模式性能需求

3.2.3.1. 税票业务量分省估算

表3-1 2004—2009年税票业务量统计及增长情况估算表

3.2.3.2. 用户访问量估算

表3-2 用户访问量计算

3.2.3.3. 系统处理能力计算

省集中模式数据中心处理能力计算

根据以上税票业务量统计及增长情况估算表，同时考虑到扣税业务的发生在时间上分布存在不规则性的特点，作如下假设：

高峰交易日业务量假定

假设全年税票业务量集中在11个月处理，每月处理全年业务量的1/11，每月的业务量平均分布在三旬当中，每旬业务量的80%集中发生在每旬的后三天。在最不理想的情况下，假定后三天的业务量的80%集中在每旬的最后一天处理。则高峰交易日业务量计算公式为：

高峰日交易量 = 年业务量/11/3*80%*80%（笔/天）

平均交易日业务量假定

假设每年的正常工作日为200天，则平均交易日业务量计算公式为：

平均日交易量 =年业务量/200（笔/天）

系统处理能力TPM-C值计算公式为：TPM-C = M*M0/T/M1 M为日交易量，包括对数据库更新、查询、增加、删除等操作。

计算TPM-C的目的是为了确定机器的处理能力，由于在每天的业务处理过程中，业务发生的频度不尽相同，一般情况下是按照8/2原则，具体来说，在20%的工作时间内业务人员要处理80%的业务。

M0为一个应用交易所对应的标准交易个数，推荐值为8-20，由于系统体系结构的不同、应用服务器的结构不同，各个厂商的推荐值也不同，如：HP公司推荐为10。

T为交易的高峰时间，使用2/8原则，如：每日工作时间为8小时，那么交易的高峰时间T=8*20%=1.6小时。

M1为机器实际为系统提供的处理能力，机器需要预留一部分处理能力，这一部分的处理能力是为了分配给操作系统、中间件应用服务器及数据库服务器的。M1一般来说为80%。

说明：

M0=10，参考目前厂商与TPC组织推荐的标准8~20，及借鉴相关类似系统（主要是中国现代化支付系统和中国银联交换系统）的取值情况，同时考虑到国库信息处理系统的单笔交易需要实时转发以及销号审核等信息整理，处理环节较多，自身交易有一定的复杂性。经估算，我们认为TIPS的交易复杂度系数M0取值10为宜。

T=96分钟，按照每天工作8个小时计算，同时根据2/8原则，即8*20%=1.6小时=96分钟内完成每天的工作量。

数据中心TPM-C = M*（M0/T/M1=10/96/0.8）=0.13 * M（其中M1=80%）。

关于业务量M的计算，按照日最大交易量来进行计算，同时按照8/2原则，即在日高峰期要处理全天80%的业务。

表3-3 不同级别数据中心税票处理能力表

3.2.3.4. 存储容量分析

其中税票的数据格式如下表所示，长度约为2k。 表3-5税票信息表

收入退还书的格式同税票格式也为2k；更正通知书格式同税票格式业务2k；会计凭证的格式为500字节；财政支出凭证的格式为1k；额度为1k；报表为1k*1000=1M；其他按照1k计算。

表3-6 数据中心存储容量表

3.2.3.5. 网络流量分析

根据业务量统计表，下表给出了每分钟交易数量。说明其中高峰交易量是根据2/8原则，即在工作时间内，80%的业务是在整个工作日的20%时间内完成，其中业务量按照每天可能发生的最大交易量乘80%来计算，其中工作时间按照正常工作时间8小时的20%来进行计算。

表3-7 单位时间内业务量统计表

在执行每笔业务时，大约占用2K，假定不考虑网络带宽在传输过程中的效率损失，下表给出了对网络带宽的需求。

表3-8 单位时间内各级机构网络汇总流量估算表

按照每笔业务处理需要2K，考虑到并发情况及网络利用效率等问题（效率损失为60%），实际所需要的网络带宽为下表所示。

表3-9 网络传输带宽估算表

3.3. 业务处理和系统响应时间

业务处理时间

在不考虑财政、征收机关、商业银行内部系统的处理时间的情况下，信息在TIPS内部的处理时间最长不超过3秒。

系统响应时间

系统登录时间最长3秒；

从报文或文件进入系统到接收回执时间不超过5秒； 报文或文件传输不成功时，在3－5秒时间内通知发送者； 因某种原因，报文或文件滞留在系统中时，应在30秒时间内向发送者发出提示信息。

为此要求：实时联网交易在不通过小额支付系统进行时，系统响应时间应该

在5秒以内：其中税务、TIPS、金融机构之间整个网络延迟在3秒以内；数据处理中心处理时间和网间互联平台处理时间之和在2秒以内。

实时联网交易在通过小额支付系统进行时，应该在5秒加上小额支付系统和TBS的处理时间（包括中间的传输时间）。

另外参考：《服务器性能计算需求分析》https://www.doc88.com/p-6631994605753.html?r=1