引言

随着互联网技术的发展，以及计算机的普及，社会上各行各业都进入了数字化时代。但随之而来的是与日俱增的用户，以及越来越庞大的数据量。从最初的几万、几十万。到现在各种秒杀活动、开门红活动等等电子商务促销活动带来的上亿级别的压力，这对于现今的系统而言，是一个巨大的挑战。而性能测试，就是模拟这些真实存在的业务场景，考验系统的负载能力，定位相应的问题并给出对应的解决方案，最终让系统满足实际的业务场景。

接下来分享我所理解的性能测试流程，及其注意事项。

一、性能测试接口文档准入

1.系统架构设计文档（系统基础架构图、业务架构图、数据流图）

2.非功能性需求文档（性能测试指标如：PV、用户数、TPS、并发、响应时间、系统峰值CPU、内存消耗......等等）

3.资源动作分解表（申请压测环境，包含硬件配置及数量信息）

4.测试场景（核心业务）

二、准备系统环境：

1.生产环境

• 生产环境衡量的精准度更高，但是需要删除测试生成的日志等测试数据,同时要保证数据删除的完整性，基础数据的构造参考后续数据量部分。

生产环境压测时，尽量挑选低峰期进行，避免对生产业务产生影响

2.测试环境

• 风险可控，但是环境构建比较复杂，规模和生产一致的成本是最高的。理想状态下的比例是测试：生产=1：2或测试测试：生产1：4。

（这里的比例是整体架构的数量或者硬件配置，但基础架构不能改变）

• 但是当现实条件不满足时，也可以在生产部分应用独立部署测试集群、数据库共用进行测试。如若搭建压测环境，在环境搭建完成之后，需要从生产脱敏导入基础数据，一般存量数据为三年、测试用例数据查询类交易至少准备5w条，提交类每条数据应不重复，nas等存储数据需准备三年业务量

（如若业务量的归档时间小于三年，则按照归档时间准备）。

三、测试计划

• 测试计划尽量简洁明了，并将每个任务的具体负责人交代清楚。划分任务时，条理要清晰，按照整个性能测试的流程的进行划分。

一般持续迭代的项目按一周作为项目周期，以一周后为结束时间，向前推。 新项目的时间一般为两到三周，具体时间具体对待。

四、测试方案

• 通过前期的接口文档中得到的信息，编写测试方案，其中包括本次测试的背景、目的、指标、测试范围、系统架构...等等信息。

出测试方案时，不是简单的登记信息就完了，还需要理解系统的整体架构，核心业务流程等等。只有这样，在面对可能出现的性能问题时或其他问题时，才会得心应手，无所畏惧。

五、测试执行

1.测试脚本

• 测试脚本分两种。一种是录制脚本，主要针对业务系统。另一种是接口类脚本，根据研发提供的接口文档编写对应得脚本。

脚本的部分没啥好说的，与研发积极沟通，把脚本调通就完了。

2.场景执行

• 场景分为 基准、单场景、混合场景、极限场景、稳定性场景。

执行时，业务方面关注三个点：事务成功率、TPS、响应时间。
系统方面关注五个点：CPU消耗、内存消耗、网络IO、磁盘IO、Swap
如果某项指标不达标，以链路为线路，由前至后进行跟踪。
以常见的系统架构为例：F5>Nginx集群>F5>微服务集群>Redis>Mysql
首先排查F5是否性能瓶颈，再检查Nginx的配置...等等，逐级排查，确保没有遗漏。

六、测试报告

• 测试完成以后，根据测试结果，整理出相应的测试报告。

测试范围、测试指标、实际指标、资源消耗、性能瓶颈、调优记录等等信息。

下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

最后： 可以在公众号：程序员小濠 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

学习不要孤军奋战，最好是能抱团取暖，相互成就一起成长，群众效应的效果是非常强大的，大家一起学习，一起打卡，会更有学习动力，也更能坚持下去。你可以加入我们的测试技术交流扣扣群：310357728（里面有各种软件测试资源和技术讨论）

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！