测试网络稳定性_从测试分类、业务场景、测试数据、监控指标看性能测试场景设计...

本文将围绕性能测试常见分类、业务场景建模、测试数据准备、监控指标确认介绍性能测试场景的设计。

性能测试常见分类

我们知道，软件总是运行在一定的环境下 ，这种环境包括支撑软件运行的软硬件环境和影响软件运行的外部条件。为了让客户使用软件系统感到满意，必须确保系统运行良好，达到高安全、高可靠和高性能。

其中，系统是否具有高性能的运行特征，不仅取决于系统本身的设计和程序算法，而且取决于系统的运行环境(硬件环境)。一般系统的运行环境会受以下因素影响:

• 系统架构：如分布式服务器集群还是集中式主机系统等。
• 硬件配置：如服务器的CPU、内存、硬盘等配置。
• 网络：如网络带宽，跨网段、隔离等。
• 支撑软件的选定 ：如选定不同的数据库管理系统( Oracle、MySQL等 )和WEB应用服务器( Tomcat Glassish、Jboss、WebLogic等 )，对应用系统的性能都有影响。
• 外部负载：同时有多少个用户连接、用户上载文件大小、数据库中的记录数等都会对系统的性能有影响。一般来说 ，系统负载变大，系统的性能会降低。

从上面可以看出，使系统的性能达到一个最好的状态，不仅通过对处在特定环境下的系统进行测试以完成相关的验证，而且往往要根据测试的结果，对系统的设计、代码和配置等进行调整，提高系统的性能。 许多时候，系统性能的改善是测试调整、再测试再调整、一个持续改进的过程，这就是我们经常说的性能调优。

在了解了这样一个背景之后 ，就比较容易理解性能测试中常见的分类。从测试的目的出发、从用户的需求出发，就比较容易区分性能测试、负载测试、稳定性测试、压力测试。

性能测试、负载测试、稳定性测试、压力测试的测试目的不同，但其手段和方法在一定程度上比较相似，通常会使用相同的测试环境和测试工具，而且都会监控系统所占用资源的情况以及其它相应的性能指标，这也是造成我们容易产生概念混淆的主要原因。

---

性能测试类型

广义上，性能测试指的是以下几种性能测试类型：

• 性能测试
• 负载测试
• 稳定性测试
• 压力测试

---

一般系统的性能指标

• 响应时间：指系统对请求作出响应的时间，即系统为其服务所耗费的时间。
• 吞吐率(TPS/RPS)：指系统在单位时间内处理请求的数量，简单讲就是系统在每单位时间内能处理多少个事务/请求/单位数据等，吞吐率也指单位时间内网络上传输的数据量。当压力加大时，点击率/每秒通过事务数(TPS)曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器出现瓶颈。
• 吞吐量：指在一次性能测试过程中网络上传输的数据量的总和，也指在单次业务中，客户端与服务器端进行的数据交互总量。
• 资源使用率：常见的资源包括，CPU占用率、内存使用率、磁盘I/O、网络I/O。
• 点击率：指在单位时间内，用户向Web服务器提交的HTTP请求数。通过它可以评估虚拟用户产生的负载量，将其与“平均响应时间”图比较，可以查看点击次数对事务性能产生的影响，可以判断系统是否稳定。
• 并发用户数：并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量，并发用户数用来度量服务器并发容量和同步协调能力。

---

我们取其中某几个性能指标，举一个例子。我们先假设一个场景：XX查询系统，其中一项产品规格(性能指标)为300用户并发查询，页面首屏结果请求响应时间不超过3秒。

图中 A、B、C、D四点表示：

• A： 产品规格(性能指标)
• B ：高于性能指标，接近系统资源临界点
• C ：高于性能指标，达到最大，出现性能拐点(可理解为最大并发用户数)
• D ：远高于性能指标，系统崩溃

---

性能测试(狭义)

测试A点的系统性能。

性能测试是为了获得系统在某种特定的条件下(包括特定的负载条件下)的性能指标数据，实现对系统某项性能指标进行定量、对比测试，主要目的是检验系统性能与相关性能标准的符合程度。

---

负载测试

测试 A点以上到C点系统性能。

负载测试的目标是测试在一定负载情况下系统性能(不关注稳定性，也就是说不关注长时间运行)，实际中我们常从比较小的负载开始，逐渐增加模拟用户的数量(增加负载)， 观察不同负载下应用程序响应时间、数据吞吐量、系统资源使用率(如CPU、内存)等，直到到系统的某项或多项性能指标达到安全临界值(如，系统内存已饱和)，以发现系统可能存在的性能瓶预、内存泄漏、FGC、不能实时同步等问题(不关注稳定性，也就是说不关注长时间运行。它是测试系统的不同负载情况下的性能指标。)

---

稳定性测试

测试 A点以上 到 B 点之间

稳定性测试是一般在低于性能值的前提下进行测试的，一般稳定性测试时间持续为 n*24 小时。测试时，我们需要结合用户实际情况控制测试中的负载量 ，使测试结果更具准确性和可靠性。

---

压力测试

测试B 点到D 点之间系统性能。

一种破坏性测试，尝试探测应用或者基础设施的极限能力。压力测试是在高于性能指标负载的前提下(超负载)对系统持续施加压力进行测试的，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐惠、系统是否具有良好的容错能力和可恢复能力。压力测试能发现仅在高负载条件下出现的同步问题、竞争条件、内存泄漏等。通过压力测试我们还可以确定应用服务在什么条件下会变得不可用。

压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试 和 极限负载情况下导致系统崩溃的破坏性压力测试。

• 稳定性压力测试：在选定的压力值下，长时间持续运行。通过这类压力测试,可以考察各项性能指标是否在指定范围内，有无内存泄漏、有无功能性故障等。
• 破坏性压力测试：在稳定性压力测试中可能会出现些问题 ，如系统性能明显降低，但很难察露出其真实的原因。通过破坏性不断加压的手段(极限负载情况下导致系统崩溃)，往往能快速造成系统的崩溃。

压力测试的几点注意：

• 测试时，我们需要注意并不是负载超过了系统的最大处理能力， 系统功能都会失效。例如，OA签到最多支持500用户井发登录，但某时550用户同时进行登录时，系统应保证550个用户中，500用户是可以正常登录，而不是所有用户都无法登录。
• 用户的业务负载并不是平均的，可能在极短时间内，出现超过负载的情况，如某宝双十一。因此不建议用持续超过系统负载的测试方法进行压力测试，只要负载足够多，系统总会被搞挂，建议使用突发形态的负载模型。

---

另外，性能测试的需要注意以下几点：

• 性能测试场景一定要基于真实环境来模拟，仿真的性能压测环境，是执行有效性能压测的前提。
• 性能测试场景一定要基于具体清晰的指标来设计。
• 性能测试，性能过程的监控分析是核心，包含硬件资源监控、应用服务监控、全链路监控。

---

性能测试场景的设计

在了解了相关背景之后，我们来了解一下性能测试场景的设计。性能场景的设计主要包括以下三个步骤：

• 业务场景建模
• 测试数据准备
• 监控指标确认

业务场景建模

首先明确压测场景范围。一般情况下我们需要关注的以下性能场景：

• 核心的业务场景
• 高频的业务场景
• 高耗的业务场景
• 曾出现过问题的业务场景

通常通过需求优先级来确认核心的业务场景，通过对用户使用日志分析获取高频的业务场景，通过历史问题明确高耗或者出现过问题的业务场景，这些业务场景是我们需要重点关注的。

然后，分析业务场景的操作轨迹。业务场景的操作轨迹可以用户日志分析和埋点，分析用户使用习惯和用户操作轨迹，进而得出业务场景的操作轨迹，同时获取不用场景的用户负载。对于新上线的应用，一般通过用户需求和虚拟用户(测试人员模拟)使用情况来确认业务场景的操作轨迹。

关于业务场景的操作轨迹还需要考虑思考时间、集合点、施压模式。

关于思考时间的设置，思考时间模拟的是用户在等待响应、浏览页面、提交表单等延迟操作的场景。正是因为不用用户的阅读速度、输入速度都存在较大的差异，也就决定了每个用户的思考时间不一样。性能思考时间常见的的设置思路如下：

• 固定时间：设置一个固定的思考时间。
• 随机分布：在一定范围内随机获取思考时间。
• 正态分布：在特定条件下，大量统计独立的随机变量的平均值的分布趋于正态分布，这就是中心极限定理。中心极限定理的重要意义在于，根据这一定理的结论，其他概率分布可以用正态分布作为近似。

一般，我们可以通过以下方式两个途径获取思考时间设置依据：

• 若系统上线，则直接分析用户使用日志获取思考时间。
• 若系统未上线，通过虚拟用户(测试人员)模拟使用系统，然后评估虚拟用户的思考时间。

关于集合点，集合点模拟的是指定用户在同一时刻一起做同样的操作(如，双十一零点支付订单)，一般集合点通过达到指定 时间或 数量的形式触发。

关于性能测试的 施压模式，常见的施压模式有以下两种， 并发模式与 RPS 模式：

• 并发模式(虚拟用户模式)：并发是指虚拟并发用户数，从业务角度，也可以理解为同时在线的用户数。
• RPS 模式(吞吐量模式)：RPS是指每秒请求数，通过设置每秒发出的请求数，从服务端的角度出发，直接衡量系统的吞吐能力。

---

测试数据准备

高质量的测试数据应当能真实的反映用户的使用场景。我们一般会引流线上真实数据，经过采用、过滤、脱敏作为性能测试的测试数据。低质量的测试数据也许能够测试出一些问题，但是更大的可能性是无效的测试结果。

同时需要注意，测试数据不仅数据的分布、数据的质量要模拟真实数据，数据量级也需要尽可能的真实情况，至少不能像功能测试那样，仅使用少量的数据进行测试。

---

确认监控指标

在性能测试执行过程中，往往需要实时观察各项指标是否正常，包括客户端指标、应用服务器、数据库、中间件、网络入口等各方面的指标。我们通常需要关注的监控指标包括：

• 业务接口指标：响应时间、RPS、成功率、失败率等。
• 网络指标：数据吞吐量、数据错误率等。
• 服务器指标：CPU、内存、I/O、磁盘、连接数等。