性能测试 —— 性能测试流程！，走进软件测试架构

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

（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中分为用户利用率、系统利用率及平均负载等重要指标。以上指标具体数据来源于非功能需求、组织要求（公司运维总结出来的可行性指标）或者行业标准建议。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：691998057【暗号：csdn999】

分析业务量

测试数据的多少对测试结果会有影响。特别是数据成千万上亿条之后，性能影响明显，所以需要做足一定数量的历史数据。除此之外，还得关注业务的增长。如果系统需要满足未来三年的业务增长需求，那么在测试时就需要生成三年的存量业务数据。对于关系型数据库来说，数据最大时对性能的影响还是比较明显的。

估算TPS与并发数

一般我们会从运维那里得到整个系统在一天内按小时进行统计的PV趋势图。根据访问高峰业务量，估算出TPS与并发用户数等性能测试执行依据。一般采用二八原则，即80%的业务在20%的时间内完成。二八原则计算的结果是吞吐量（即TPS），而并发数 = TPS *（ThinkTime+RunTime）。

如果你的系统性能要求更高，也可以选择一九原则或更严格的算法，二八原则比较通用，一般系统性能比较接近这个算法而已，大家应该活用。

分析系统协议

一般性能测试脚本可以通过录制或者手动开发，而录制方式对协议的依赖性相当强。一般我们先分析系统协议（向开发团队咨询，或者截包分析），再评估用什么工具完成。HTTP可以用JMeter或者LoadRunner，Java接口可以用JMeter的JavaRequest元件与JUnit元件测试。

三、性能测试从哪里获取需求？

一般需求文档中会有一部分章节用于描述系统非功能性需求，但是多数需求文档对于性能需求的说明都比较笼统抽象。在需求不明确的情况下，通常需要性能测试工程师主动向需求提供方（BA团队、产品团队等）去征询。

对于升级、优化类的老系统，可考虑是否存有历史测试方案参考，或许可以省事很多。或者我们分析原型系统业务数据即可，最直接的办法就是分析原型系统的数据、统计业务量、业务分布等信息。

1、学习业务：

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

2、需求分析：

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

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、测试执行

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
等）和ER关系？？？

9、测试执行

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-LzhoGQIZ-1713550395683)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！