前言

 

性能测试方案需包含测试测试需求分析、测试对象分析、测试重点分析、测试环境分析、测试场景构建几个关键点，其中：

 

• 测试需求分析：测试中涉及的性能指标的定义

• 测试对象分析：测试中涉及的业务及系统内部模块的定义

• 测试重点分析：测试执行策略、测试监控策略、测试风险的定义

• 测试环境分析：测试中涉及到的服务器资源、测试软件、测试数据、测试桩定义

• 测试场景构建：从性能负载、接口、疲劳角度定义测试场景

 

定义

 

测试场景构建：从性能负载、接口、疲劳角度定义测试场景

 

项目：

 

我们先定义一个性能测试项目，用户手机连上wifi，然后打开浏览器链接任意一网址，页面被刷新到登录页面，用户输入用户名加密码后点击登录，以此进行下面的性能方案讲解。

 

1、测试需求分析

 

可从需求文档、市场调研去收集性能测试指标

 

 

1.1、需求文档

 

1.1.1、客户明确需求

 

通常情况，客户有明确的需求，定义一些性能测试指标，例：每秒用户登录页面刷新多少、每秒登录用户量多少，用户在线总量多少，我们明确性能测试指标。

 

1.1.2、客户隐形需求

 

基于客户明确指标下，会有一些隐性指标，例：100万在线用户的查询在5秒响应，我们也许纳入性能测试指标内。

 

1.1.3、用户模型确定

 

有了以下的性能测试指标后，我们可以创建我们的用户模型，如下：

 

1. 用户指标：用户登录TPS需达到50、用户登录页面刷新TPS需达到250；

2. 用户总量：总用户量100万；

3. 用户模型：系统每天用户在线量在100万左右，平均在早晨8、11点期间登录，其中登录页面刷新与登录比例为5:1。

 

1.2、市场调研

 

1.2.1、客户无明确需求

 

也有特殊的情况，客户只会提供一些基础数据，例：2000个机构下，500万的用户总量，我们需要根据这些基础数据提炼出我们的性能指标。

 

1.2.2、市场调研需求

 

有了基础数据后，还需要对我们所关心的性能指标做市场调研，最终得出我们的性能指标

 

例：对其中1个机构1个月的用户登录数进行数据采集（每天早晨8-9点是登录高峰期，每天大约是1小时内登录100人次，平均到每秒100÷3600约为0.027次/秒），然后在推算2000个机构下，用户每秒登录0.027*2000约50次，在根据后台日志推算出，登录与登录页面刷新比例为1:5，登录页面刷新TPS为2500。

 

1.2.3、用户模型确定

 

确定性能指标后，我们可以创建我们的用户模型，如下：

 

1. 用户指标：用户登录TPS需达到50、用户登录页面刷新TPS需达到250；

2. 用户总量：根据用户指标推算出用户总量，或者由相关系统推算出用户总量；

3. 用户模型：系统每天用户在线量在100万左右，平均在早晨8、11点期间登录，其中登录页面刷新与登录比例为5:1。

 

02

测试对象分析

 

可从测试对象分析、测试模型分析、测试指标分析、模块耦合性分析考虑。

 

 

 

 

2.1、测试对象分析

 

测试对象分析从业务流程、后台系统模块分析，然后明确测试对象。

 

 

2.1.1、按照业务流程拆解

 

根据业务提炼出用户基础流程：登录页面刷新、登录

 

1.  登录页面刷新：手机连上wifi，浏览器任意访问一地址，请求会被接入层的设备重定向到后台,后台经过逻辑计算，推送给用户一个登录页面；

2. 登录:用户输入用户名加密码，然后点击登录，后台系统进行登录，返回成功或者失败。

 

2.1.2、按照后台系统模块拆解

 

根据业务分析后台的系统模块，登录页面刷新模块、登录模块：

 

1. 登录页面刷新模块：用户的HTTP请求经过系统层面的中间件处理分发到后台系统，然后被推送模块接收，再进行计算，推送出相应的登录页面，这里的计算可能跟用户类型以及所在机构有关系。

2. 用户登录模块：用户输入的用户名加密码请求同样经系统层面中间件处理分发到后台系统，然后登录模块接收，再进行用户名密码的校验（这里可能会到数据库内去进行查询或者更改数据），最后返回结果。

3. 最后提炼出关键系统模块：HTTP、中间件、推送模块、登录模块，最后这些系统模块会在性能瓶颈定位中起到方向作用。

 

2.1.3、明确测试对象

 

根据业务流程分析与后台系统模块分析，明确测试对象的业务、系统模块、指标。

 

1. 业务：用户连接wifi后，浏览器访问网页，被重定向到用户登录页面，然后输入用户名+密码进行登录的一种场景；

2. 模块：整个流程包括HTTP请求、中间件、推送模块、登录模块；

3. 指标：登录页面刷新：TPS250、登录动作：TPS50、在线总量：100万。

 

2.2、测试模型分析

 

2.2.1、用户模型场景分析

 

根据用户模型设计出典型应用场景与可靠性应用场景

 

典型应用测试主要从常规测试指标、测试环境去分析，例：

 

1. 常规测试指标是登录页面刷新250TPS，登录50TPS，用户量100万。

2. 常规测试环境是网络是无限流、无有延迟，测试硬件的CPU、内存、磁盘的正常情况设计场景。

 

可靠性应用场景主要从非常规测试指标、测试环境去分析，例：

 

1. 非常规测试指标是高于指标的20%的情景下验证；

2. 非常规测试环境是网络存在限流、延迟情况很大，测试硬件的CPU、内存、磁盘受限的异常情况下设计场景。

 

2.2.2、用户模型场景设计

 

根据用户模型分析设计出用户模型场景，例：

 

1. 用户典型应用场景：在10MB/秒限流与20ms延迟网络情况，对CPU16核、内存32G、磁盘10K转/秒的服务器进行TPS250的登录页面刷新动作，以及TPS50用户登录动作，持续时间约5.5小时，最终上线用户量达100万左右；

2. 用户可靠性应用场景：在1MB/秒限流与100ms延迟网络情况，对CPU4核、内存16G、磁盘7200转/秒的服务器进行TPS300的登录页面刷新动作，以及TPS60用户登录动作，持续时间约5.5小时，最终上线用户量达100万左右。

 

2.3、测试指标分析

 

2.3.1、提炼出关键指标

 

根据用户模型提炼出用户关键指标，例：

 

 

2.4、模块耦合性分析

 

根据后台系统模块分析出可能会涉及到的模块耦合性，例：

 

 

1. HTTP请求中的cookies贯穿整个业务交互过程，在测试脚本中应该缓存cookies，保证业务正常，同时后台考虑cookies的存取方式，保证大并发下cookies不会出现丢失或者写满的情况；

2. 中间件反向代理将不同请求分发到内部模块：推送模块、登录模块、其他模块，考虑中间件本身会不会存在瓶颈，对业务照常影响。

 

测试重点分析

 

可从测试执行策略、测试监控策略、测试风险与输出方向去考虑。

 

3、测试重点分析

 

可从测试执行策略、测试监控策略、测试风险与输出方向去考虑。

 

 

3.1、测试执行策略分析

 

3.1.1、分析本次性能测试的重点

 

根据咨询研发人员，确认后台系统模块的代码编写情况，可分为重构、继承、新增，不同情况测试策略不同。

 

 

1. 关于继承模块测试：进行回归验证即可，不做探索性的性能测试。

2. 关于关于重构或新增模块测试：进行全面的测试，优先覆盖典型场景，可靠性场景在集成测试后验证。

 

3.1.2、分析本次性能测试测试轮次

 

根据系统性能测试介入时间，来制定测试达标要求。

 

 

1. 集成测试轮次：确保单业务指标达标80%；

2. 阿尔法测试轮次：确保单业务指标达到100%；

3. 系统测试轮次：确保混合业务指标达到100%。

 

3.2、测试监控策略分析

 

主要从系统用到一些资源进行监控，例：数据库、系统CPU、内存、磁盘等。

 

 

1. 数据库可用所在数据库层面自带监控工具，或者第三方层面的监控器；

2. 系统资源监控可用系统层面的一些自带工具：例：nmon工具,Top命令。

 

3.3、测试风险与输出

 

主要从测试硬件、测试人力、测试技术这些方面考虑。

 

 

1. 1、测试硬件风险：找不到合适硬件资源，需测试前期识别出来，并使用相近配置进行验证，后期需在测试风险中提出。

2. 测试人力风险：由于测试周期紧张，需要多名测试人员同时进行测试，但具备性能测试的人员不足，前期提出风险，并考虑延长测试周期，或在前期培训相应人员。

3. 测试技术风险：根据业务与后端系统选取合适的性能测试工具，例：Loadrunner、jemter等。

04

4、测试环境分析

 

主要从测试硬件、测试仪器、测试桩准备、测试数据准备、测试环境准备这些方向考虑。

 

 

4、 测试环境分析

 

4.1、测试硬件

 

 

 

1. 服务器硬件配置：考虑硬件的CPU、内存、磁盘读写、硬盘；

2. 压力机硬件配置：考虑硬件的CPU、内存、磁盘读写、硬盘。

 

4.2、测试仪器

 

 

1. 性能测试模拟器：测试中用于模拟压力端的工具，可以是企业级的工具，例：LR，jmter,AB.也可以是用JAVA、C或python言语写的压力器；

2. 性能测试软件：测试中用于性能调优，内存分析以及数据库方面的辅助工具。

 

4.3、测试桩准备

 

 

• 测试桩作用：用于性能瓶颈定位、用于规避测试中一些非主要流程，通常有研发人员提供。

• 模块之间的测试桩：流程中包含AB模块，性能定位时AB模块性能瓶颈时，需在AB模块之间做桩，让其支持单压A，或者单压B模块。

• 辅助测试桩：测试流程中的一些非主要流程，同时脚本不易实现，例：登录时安全校验输入验证，可适当地让研发人员进行前段安全校验的屏蔽。

 

4.4、测试数据准备

 

根据前面的用户模型里涉及到的数据，测试前期进行准备，例：用户登录场景，登录名是手机号，登录终端是手机，场景下共有2000个机构，即：需500万的手机号、500万的MAC地址、2000个组织机构。

 

4.5、测试环境准备

 

根据性能测试场景，可分为负载场景、混合场景、疲劳场景，所以根据实际情况，可分为负载环境、混合环境、疲劳环境、研发调试环境。

 

 

 

• 负载环境：用于进行单业务负载测试。

• 综合环境：用于进行综合业务负载测试。

• 疲劳环境：用于进行7*24小时疲劳测试。

• 研发调试环境：用于进行性能瓶颈定位分析。

 

为什么需要区分这么多场景，可能有人会问，因为在测试前期负载场景测试时，10项性能指标通过7项，剩余3项还没达标，其实这时可以同步进行综合场景测试，负载环境单独调优剩余3项没过指标，综合场景单独进行综合场景测试，其实就是多环境好处在于可以并行进行测试，不至于让某一个测试因为环节问题卡住我们。

505

5、测试场景构建

 

5.1、负载场景测试

 

负载场景测试主要验证各个单业务是否性能指标需求。

 

• 例：验证登录页面刷新TPS250是否满足

• 例：验证登录TPS50是否满足

 

5.2、接口场景测试

 

接口场景测试主要验证系统中第三方接口验证，例：登录时的第三方短信接口验证。

 

5.3、混合场景测试

 

综合场景测试验证用户的典型场景与可靠性场景是否满足性能指标需求。

 

• 例：在10MB/秒限流与20ms延迟网络情况，对CPU16核、内存32G、磁盘10K转/秒的服务器是否满足TPS250的登录页面刷新、是否满足TPS50用户登录，是否满足持续时间约5.5小时后上线用户量达100万。

• 例：在1MB/秒限流与100ms延迟网络情况，对CPU4核、内存16G、磁盘7200转/秒的服务器是否满足TPS350的登录页面刷新、是否满足TPS60用户登录，是否满足持续时间约5小时后上线用户量达100万。

 

5.4、疲劳场景测试

 

疲劳场景测试主要验证系统在长时间负载下的表现是否正常。

 

通常是按照负载场景指标的60%左右对系统进行7*24小时的长时间负载测试，观察系统长时间运行下，是否满足负载指标的60%，在业务波峰时系统后台资源（CPU、内存、磁盘IO）消耗不高于系统的80%，在业务波谷时系统后台资源恢复到正常的20%到40左右。