目? 录

引? 言

1? 性能测试的基本概念

2? 性能测试的分类

2.1 负载测试

2.2 压力测试

2.3 基准测试

2.4 配单测试

2.5 容量测试

2.6 稳定性测试

2.7 扩展性测试

2.8 负载测试VS压力测试

3? 业务场景与设计要点

3.1 业务场景的划分

3.2 业务设计要点

3.2.1 测试目的

3.2.2 业务组成

3.2.3 数据规格

3.2.4 指标监测

引? 言

“性能”一词对大部分来说并不陌生，在日常生活或工作中我们经常会听到关于性能的描述：

“这台电脑的性能也太差了吧，打开个软件都能卡半天！”

“新发布的小米11pro性能好强大啊！”

“这款处理器的性能真强劲，完全吊打……”

“打开个网页也要加载半天，这个网站的服务器性能也太差了吧……”

“看看我的新车，百米加速xxx秒，性能强的一批！”

虽说如此，但是你真的了解“性能”吗？你知道性能背后深层的意思吗？以软件测试中的服务器性能场景为例：

A：这个网站的服务器性能太差啦！

B：差在哪里？

A：加载网页的速度太慢了！

B：确定是服务器性能差？而不是你的网络不行？不是你的电脑不行？不是你打开的方式不对？？？

打破砂锅问到底，用量化的数据指标来代替直观的感受是我们性能测试需要做的事情。下面我们就来详细学习一下性能测试的基本知识吧！

1? 性能测试的基本概念

性能测试在软件的质量保证过程中起着举足轻重的作用。特别是对于一些并发量大的大型网站来说，做好性能测试，找到性能瓶颈，并根据性能测试结果做出针对性的优化至关重要。比如各大电商平台在双11背后肯定做足了性能测试，否则一旦网站崩溃，带来的损失就不是亿点点了……

中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

2? 性能测试的分类

根据测试的目的和手段来划分，性能测试可以划分为负载测试、压力测试、基准测试、配单测试、容量测试、稳定性测试和扩展性测试。如下图所示：

2.1 负载测试

系统在不同负载下的性能表现，通过负载测试能够测试出系统在各种负载下的性能变化曲线，发现系统的性能拐点，从而找出系统的最佳性能。举例：用户并发测试（递增并发用户数，查看系统性能指标变化）。

2.2 压力测试

系统在高强度负载下的性能表现，通过压力测试可以测试出系统能够承受的最大负载。压测是一种寻求系统介于正常和不正常之间临界值的一种负载测试。压测不仅关注高负载下系统是否正常运行，同时关注负载减小后，系统是否能够恢复。

2.3 基准测试

基准测试（benchmarking）是一种测量和评估软件性能指标的活动。在特定时期（系统稳定时）通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。基准测试可以比较系统在版本迭代过程中，各个性能指标的变化，为系统的版本迭代优化提供参考。

2.4 配单测试

也叫配置项测试，对被测系统的软硬件参数进行配置的测试。通过配单测试可以找出系统各项资源指标的最佳分配比。

2.5 容量测试

通过容量测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。软硬件固定的情况下，对系统进行一定规模的数据量操作，观察系统各项性能指标是否正常。举例：电子商务网站所能承受的、同时进行交易或结算的在线用户数。

2.6 稳定性测试

通过对软件稳定性的测试可以观察在一个运行周期内、一定的压力条件下，软件的出错机率、性能劣化趋势等。进而大大减少软件上线后的崩溃卡死等现象，为软件的逐步优化提供方向及验证。在特定的负载下（正常或略高于正常的负载），在一段运行周期内，对被测系统进行一系列的正常操作，观察各个系统性能指标变化以及系统是否能够长期稳定运行。

2.7 扩展性测试

基础设施不需要经常变更，应用之间较少依赖或耦合，可以对需求变更快速响应。架构设计会考虑到未来功能的可扩展性，所以当系统增加新功能时，不需要对现有系统的结构和代码进行修改。系统集群的扩展性测试，观察系统在集群服务器增加时，整体性能是否稳步提升，集群中的每台服务器性能是否有额外损耗等。

2.8 负载测试VS压力测试

有些童鞋可能对负载测试和压力测试傻傻分不清楚，这边也查阅了一些资料，做了个总结，方便大家参考：

相同点：两种测试都是针对系统承受能力的测试，都是一种量的测试；

不同点：负载测试是观察系统在不同负载下的测试，旨在找出系统的性能拐点或最佳性能；压力测试是观察系统在高负载下的运行情况，旨在找出系统所能承受的最大负载以及系统在高压下再减压后系统恢复正常的能力。

3? 业务场景与设计要点

业务场景顾名思义就是系统真实运行环境的场景，模拟性能测试场景的宗旨是尽可能还原业务现场真实的软硬件环境。在一些入围项目中，就需要尽可能按照入围测试的软硬件配置模拟性能测试场景。

3.1 业务场景的划分

性能测试的业务场景可以按照业务的组成以及测试目的和手段两个维度进行划分。

按照业务场景划分可以划分为单业务场景以及混合业务场景（也可以叫多业务场景）。顾名思义，单业务场景的性能测试就是针对单一业务的性能测试场景，比如交换机的接口带宽测试、网站的用户登陆测试、安防系统的视频取流测试等。混合业务场景的性能测试则是对多个业务进行综合性能测试，主要考察整个系统或者多个模块在真实业务场景下是否能够满足性能要求。

按照测试目的和手段划分性能测试场景，可以划分为：负载测试场景、压力测试场景、基准测试场景、配单测试场景、容量测试场景、稳定性测试场景和扩展性测试场景。与第二节描述类似，不再赘述。

3.2 业务设计要点

3.2.1 测试目的

目的是行动的依据，明确测试目的能够对整个性能测试的执行提供方向，是性能测试的第一步。只有明确了测试目的才能够选择恰当的测试方法进行性能测试，偏离目的的测试做的都是无用功。

明确测试目的需要确定以下几个要素：

• 被测目标：一个接口、一个功能点、一个功能集合、一个模块或整个系统等都可以是被测目标；
• 数据/操作规模：交换机单个接口的满流量、交换机的所有接口满带宽、网站的10w并发、服务器接口调用100w次等数据或操作的量级；
• 预期性能表现：网站稳定运行、服务器不崩溃、系统CPU 80%以内，系统响应时间不超过3s等衡量系统性能的指标。

3.2.2 业务组成

分析业务组成最关键的一点就是抽象出对测试目标有影响的因素或者业务，无关或者没有影响的业务不需要进行设计和叠加。分析业务组成的同时还需要理解业务流程之间的关系，比如测试电商网站是否能够承受1000w用户的并发操作，需要了解整个购物流程包括登陆、浏览商品、加入购物车、下单、付款等环节，并根据业务流配置合理的并发操作量（比如500w登陆、200w浏览商品、100w加入购物车、100w下单、100w付款）。这与每个环节都设计1000w并发量的测试目的是不同的。

3.2.3 数据规格

从3.2.2的分析我们可以知道，数据规格和业务组成是紧密相连的。在性能测试中，说到业务的同时，也会连着提到业务的数据量/数据规模。为了方便理解，此时的业务组成也可以抽象成是数据组成，因此数据规格可以描述为：

数据规格=数据组成+数据量/数据规模

结合上文，我们可以得出电商网站1000w的用户并发数据规格如下：

1000w用户并发=500w登陆+200w浏览商品+100w加入购物车+100w下单+100w付款

当然这个只是一个简要的过程，具体以实际业务为准哦。

3.2.4 指标监测

指标监测是指我们对系统做了一系列操作后，监测/监控系统的表现情况。一般情况，需要对这些指标进行量化，比如系统反应时间3s以内，CPU占用70%以内，网络传输不出现丢包，不出现进程死锁或系统挂死现象等等。切记不要用系统稳定运行这类抽象字眼一句话带过，这也是很多测试新人常犯的错误。

?

?

如果文章对你有帮助，记得点赞，收藏，加关注。会不定期分享一些干货哦......~~~///(^v^)\\\~~~

?

?