上篇文章全面深入讲述了基于博客系统项目的功能测试，从测试用例编写筑牢基础，到脚本开发释放效率，再到融入报告沉淀价值，相信小伙伴们已经对自动化测试中的web功能测试掌握的炉火纯青了吧~ 本篇文章将给大家带来软件测试之自动化测试中另一大模块—性能测试。下面我将详细为大家讲述o( ￣▽￣)ブ

性能测试基础知识

性能测试基础知识主要由4大方面组成—性能测试基础概念，常见性能测试指标，性能测试关注点，性能测试分类这四大方面，下面我将逐一为大家介绍~

1 性能测试基础概念

1.1 性能测试概念

性能测试是软件测试的重要类型，聚焦于评估系统在特定负载下的性能表现，如响应时间、吞吐量、资源利用率等。它通过模拟真实或极限场景，检测系统是否满足性能需求，发现潜在瓶颈，确保系统在实际运行中稳定高效。⼀般在真实环境、特定负载条件下，通过⼯具模拟实际软件系统的运⾏及其操作，同时监控性能各项指标，最后对测试结果进⾏分析来确定系统的性能情况。

总结：性能测试是为了发现系统性能问题或获取系统性能相关指标⽽进⾏的测试。

1.2 性能测试目的

性能测试的目的是验证系统在预期负载或极端条件下的性能表现是否符合需求，确保其响应时间、吞吐量等指标达标；同时通过模拟真实场景暴露性能瓶颈，为系统优化提供依据，保障实际运行时的稳定性与效率。最主要目的是能够对个人编写的代码进行性能测试以及性能调优。

总结：web性能测试目标是能够对个人编写的项目进行接口的性能测试。

1.3 常见性能测试问题

常见性能问题有查询数据时间过⻓，⽹速很慢，服务器⽆响应，查询数据很⻓时间才显⽰列表等等。

2 常见性能测试指标

常见性能指标由并发数，吞吐量，响应时间，事务，资源利用率这5方面组成。

2.1 并发数

从业务层⾯看，并发数指的是实际使⽤系统的⽤⼾总数。
从后端服务器层⾯看，并发数指的是web服务器在⼀段时间内处理浏览器请求⽽建⽴的http连接数或⽣成的处理线程数。

总结：并发数就是并发⽤⼾数，指的是实际使⽤系统的⽤⼾总数。

2.2 吞吐量

单位时间内处理的并发数，直接体现软件系统负载承受能⼒。

总结：吞吐量越⾼，系统承受的并发越多，性能越好。

吞吐量分类
1）TPS和QPS
TPS：TPS是指每秒处理事务数，⽤于衡量系统在⼀定时间内能够处理的事务数。
计算公式：总的事务数 / 总的运⾏时间
计算时当没有更详细的数据：根据⼆⼋定律（80%的事务在20%的时间内完成）；如果有详细的数据，实际还要参考往年业务的增⻓。
QPS:QPS是指每秒查询率。若⼀个事务中只有⼀个接⼝且是查询接⼝，则QPS = TPS。
2）网络数据包划分：KB

2.3 响应时间

响应时间是指⽤系统从请求发出开始，到客⼾端接收到最后⼀个字节数据所消耗的时间。对于web系统⽽⾔，系统响应时间包含前端展现时间和系统响应时间。
前端展现时间：⻚⾯渲染时间
系统响应时间：包含服务器、数据库、通讯⽹络等响应时间

总结：响应时间就是验证系统处理速度快不快。

并发⽤⼾、系统吞吐量、系统响应时间之间的关系：

当并发⽤⼾较少，系统吞吐量低，系统响应时间较短，我们认为系统处于空闲区间。随着系统并发⽤⼾增加，系统吞吐量开始呈线性增⻓，系统性能进⼊了线性增⻓区间。吐量在某个点上达到了饱和点，也称之为拐点。统性能的拐点通常是性能测试的主要⽬的。
总结：拐点之后服务器处理请求变缓慢，⽤⼾请求不再被⽴即处理，响应时间随之变⻓，吞吐量也逐渐降低，系统性能进⼊了过饱和区间。因此拐点时系统性能最好。

2.4 事务

一个接⼝可以是⼀个事务，多个接⼝也可以是事务，⼀个流程可以是事务，事务代表⼀个完整的功能。

2.5 资源利用率

通过查看系统占⽤的情况分析资源瓶颈。
服务器：CPU、内存、磁盘、⽹络等。

3 性能测试关注点

不同的⻆⾊看待性能测试的侧重点不同。
从客⼾端发起⼀个请求到客⼾端收到请求的整个过程中，各阶段都可能存在性能问题。后端处理请求的性能问题，服务器硬件资源（CPU、内存、磁盘），中间件、⽹络、数据库、架构设计等是否存在瓶颈。
通过分析不同⻆⾊的侧重点，从⽽促进性能测试更好的开展。软件系统性能相关的⻆⾊主要有四种—终端用户，系统运维人员，软件设计开发人员，性能测试人员。

3.1 终端用户

对于终端⽤⼾来说，表现为⽤⼾进⾏业务操作时的主观响应时间。⽤⼾重点关注从你提交请求到收到响应的时间，包括系统响应时间和前端展现时间。

3.2 系统运维人员

系统运维⼈员除了关注单个请求的响应时间，更关注⼤量⽤⼾并发访问时对系统的影响，以及更⼤负载情况下的系统健康状态。从⽽执⾏系统的整体的策略。
1)关注全局利益最⼤化，对最⼤并发⽤⼾数和系统响应时间进⾏权衡取舍。
2)系统并发处理时间、系统容量、数据库调优，以及⻓时间运⾏稳定性和可扩展性。

3.3 软件设计开发人员

关注算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性等⽅⾯。对于算法，要保证⾼效，⽆内存泄漏；对于架构，要保证系统容量和性能可扩展。

3.4 性能测试人员

⼯作重点在于性能测试场景的设计、脚本的开发和执⾏，以及性能缺陷的排查和定位。测试⼈员除了具有及其宽⼴的知识⾯，如系统架构，存储架构，⽹络架构等全局的知识，还要有⼤量知识积累，⽐如数据库SQL语句的执⾏计划调优、JVM垃圾回收、多线程常⽤问题等。
总结：一般的软件测试人员只做性能测试软件测试（业务测试），偶尔会涉及到性能测试（更多是接口方面），只关注性能测试结果，不对其进行调优。

4 性能测试分类

性能测试分类可分为5大类—基准测试，并发测试，负载测试，压力测试，稳定性测试。

4.1 基准测试

准测试(Benchmark Testing)⼜称单⽤⼾测试，主要⽤于监测被测系统在较低压⼒下的运⾏状况并记录相关数据。当性能测试环境确定以后，通常选取业务模型中的重要业务做基准测试，对被测系统施加⼀定压⼒，从⽽获取被测系统在单⽤⼾运⾏情况下的各项性能指标，为多⽤⼾并发测试和混合场景测试等提供参考依据。

总结：基准测试是在特定的软硬件环境下，通过对系统施加标准负载，建立性能指标的基准参考值（如正常响应时间、吞吐量基线），它为后续性能优化或版本迭代提供对比依据，用于判断系统性能是否发生退化或提升。

4.2 并发测试

并发测试(Concurrency Testing)⽤于评估被测系统的某些特定操作同时发⽣时的性能表现，例如，被测系统被多个⽤⼾同时登录时的响应能⼒，或系统的某⼀功能被多个⽤⼾同时操作时的性能表现。通过并发测试，不仅可以获得被测系统在多⽤⼾并发操作时的性能指标，还可以发现被测系统在并发条件下可能发⽣的问题，如内存泄漏、线程锁、资源争⽤问题。例如，通过模拟多个⽤⼾同时访问某⼀条件数据，或模拟多个⽤⼾同时更新数据，可能会发现被测系统的数据库访问错误、写⼊错误等。

总结：⼏乎所有的性能测试都会涉及⼀些并发测试。但并发测试对并发时间要求⽐较苛刻，通常需借助专⻔的性能测试⼯具，采⽤多线程或多进程的⽅式来模拟多个虚拟⽤⼾的并发性操作。

4.3 负载测试

负载测试(Load Testing)是性能测试的⼀种测试类型，⽤于评估被测系统在预期的不同负载下的⾏为。负载测试关注系统处理不同负载的能⼒，这些负载可通过控制并发⽤⼾或者进程的数量来实现。进⾏负载测试时，通过对系统不断增加并发访问负载，监测系统性能的变化，直到系统的某项或多项性能指标达到安全临界值，最终确定在满⾜该安全临界值的性能指标下，系统所能承受的最⼤负载量。

总结：负载测试是通过逐步加载的⽅式来确定系统的处理能⼒。
通过负载测试可以获取系统能够达到的峰值指标。

4.4 压力测试

压⼒测试(Stress Testing)⽤于评估被测系统在⾼于预期、⾼于指定容量负载需求或低于最少需求资源的条件下的⾏为。压⼒测试关注被测系统处理超出预期或特定峰值负载的能⼒，也可以⽤于评估系统在资源匮乏时的处理能⼒。进⾏压⼒测试时通常采⽤逐步增加系统负载的⽅式，使系统某些资源达到饱和甚⾄失效，从⽽发现那些只有在⾼负载条件下才会出现的缺陷。通过对被测系统进⾏压⼒测试，也能找出被测系统的性能拐点，获得系统所能提供的最⼤服务级别（系统所能承受的最⼤压⼒），评估系统在峰值负载或超出最⼤负载情况下的处理能⼒。

总结：压⼒测试主要⽤于性能诊断、性能调优和容量规划等场景。
压力测试与负载测试不同，负载测试是在保持性能指标要求的前提下测试系统能够承受的最⼤负载，⽽压⼒测试则是测试系统性能达到极限的状态。

4.5 稳定性测试

在负载测试的基础上，执⾏较⻓时间的测试以检查系统的稳定性。通常较⻓时间指3*24⼩时以上。

写在最后：性能测试作为软件质量保障体系的核心构成，从需求拆解到指标量化，从场景模拟到瓶颈分析，贯穿于软件全生命周期。各类测试类型与角色视角的深度融合，构建起精准识别系统性能边界的技术矩阵 。 在技术迭代加速的当下，性能测试需持续适配分布式架构、高并发场景等新挑战，以数据驱动优化，用精准测试护航。期待与同行携手，在实践中深化对性能本质的理解，下篇文章将给小伙伴们带来性能测试实战项目，希望大家认真学习，为以后的就业打下坚实基础(ง •_•)ง