[PT_03] 性能测试-测试模型构建 & 用例设计

目录结构

一、测试模型构建
    1.登录业务-操作流程
    2.商品浏览购买-操作流程
二、测试场景用例设计
    1.常用测试场景的类型
        1）单业务基准测试
        2）单业务压力测试
        3）单业务负载测试
        4）综合业务基准测试
        5）综合业务压力测试
        6）综合业务负载测试
        7）综合业务稳定性测试
    2.业务量线程数的确定
        1）登录业务-线程数确定
        2）商品随机浏览购买业务-线程数确定
    3.测试场景用例设计
        1）登录并发-场景用例
        2）登录业务量-场景用例
        3）随机购买并发-场景用例
        4）随机购买业务量-场景用例
三、测试脚本用例设计
        1）登录-脚本用例
        2）随机购买-脚本用例

一、测试模型构建

从上一篇 性能测试-性能指标的分析 & 定义 确定了性能测试的需求及对应的指标后，即可分析被测业务的业务模型，作为后续步骤中设计测试场景、测试脚本的基础。
其前所确定选取的测试业务为：登录业务、商品随机浏览购买的业务。此两项业务对应的操作流程，如下：

1.登录业务-操作流程：

1）访问打开首页
2）点击【请登录】，跳转到登录页面
3）输入：用户名+密码，点击【立即登录】，跳转到首页
4）点击【退出】，跳转到首页

2.商品浏览购买-操作流程：

1）访问打开首页
2）点击【请登录】，跳转到登录页面
3）输入：用户名+密码，点击【立即登录】，跳转到首页
4）随机选择商品，购买
5）设置收货地址
6）设置配送方式、支付方式，提交订单
7）点击【退出】，跳转到首页

二、测试场景用例设计

性能测试过程中，首先应该设计测试场景，模拟真实业务发生的情境，然后是针对场景设计脚本。为了相对真实反映被测对象可能存在的性能问题，需要尽可能模拟出被测对象可能发生瓶颈的业务场景。

测试需求分析过程中已经确定了需要测试的业务类型，此时则需要设计针对每种业务or综合业务的测试场景。

1.常用测试场景的类型

性能测试通常有7种常用测试场景：单业务基准测试、单业务压力测试、单业务负载测试、综合业务基准测试、综合业务压力测试、综合业务负载测试、综合业务稳定性测试。
归属为4种测试类型：基准测试、压力测试、负载测试、稳定性测试。

1）单业务基准测试

测试某个具体业务是否满足系统设计or用户期望的性能指标。

如用户期望系统支付接口支持50个用户并发支付，满足则认为基准测试完成，否则失败。基准测试过程中，性能指标的任何一项均需成功，才认为基准测试完成。基准测试可分为并发基准、业务量基准两种，其目的都在于验证是否满足预期目标设定。

2）单业务压力测试

测试某个具体业务在最大负载下，持续服务的时长，以此验证被测业务的稳定性。

压力测试过程中所设计的负载，是以系统基准负载为标准，如系统基准负载为50个并发用户，则压力测试的负载设为50个。通过运行时长的变化，验证服务器在系统预设负载下持续服务的能力。具体的时长从需求分析、运行日志、系统设计规划等来源获取。

3）单业务负载测试

测试某个具体业务能够承受的最大负载，验证被测业务能够承受的最大负载数。

如系统基准负载为50个，则通过多次测试，逐步加大负载，最终获得被测业务的最佳负载。在最佳负载下，系统仍需满足各项性能指标。

4）综合业务基准测试

测试多个业务综合使用的性能是否满足系统设计or用户期望的性能指标。与单业务基准测试类似，但综合业务需考虑业务与业务之间的联系，如果相互之间存在资源争用，则需单独组合测试。

假设系统需测试的业务有三个：A、B、C，综合业务基准测试是将ABC一起运行，加上A、B、C三个基准测试，共计4个基准测试场景（ABC、A、B、C）。若A与C存在资源争用（交互作用，非彼此独立），则需将A与C组合，构成一个单独的测试场景，此时一共为5个基准测试场景（ABC、A、B、C、AC）。
综合业务测试中的数据分配，根据实际业务、用户需求、运行日志、运营规划等分析确定。

以上设计非绝对，需要根据具体业务关联性来设计测试场景
假设某银行柜员交易系统，1h内有4个柜员进行存款操作，6个柜员进行开户操作，8个柜员进行取款操作，2个柜员进行查询操作，则综合业务的负载比例设置为：

1h内的总业务量：4+6+8+2 = 20
存款业务占比：4/20 = 20%
开户业务占比：6/20 = 30%
取款业务占比：8/20 = 40%
查询业务占比：2/20 = 10%

5）综合业务压力测试

测试多个业务在最大负载下一起运行，持续服务的时长，以此验证综合业务的稳定性。

6）综合业务负载测试

测试多个业务一起运行，整体能够承受的最大负载，以此验证综合业务能够承受的最大负载数。

7）综合业务稳定性测试

通常为核心业务在基准负载的基础上运行相对长的时间，验证服务器持续提供稳定服务的能力（稳定性场景测试的时间由需求方设定，一般为7*24h不间断执行）。

通过上述分析，根据ECShop平台业务模型，可确定本次性能测试的场景主要有4个场景，如下：
①登录并发基准测试
②登录业务量基准测试
③商品随机浏览购买并发基准测试
④商品随机浏览购买业务量基准测试

2.业务量线程数的确定

场景设计中需设置线程数，以本次测试为例，要求在2h内支持5w次用户登录。线程数计算方式如下：

Total_Thread = BC/(T*60*60/t) = BC*[t/(3600*T)]
T：  考察的时间段，本例 T=2h
t：  单用户单次业务消耗时间，尽可能模拟用户的真实行为
BC： 业务量，本例 BC=5w

利用JMeter测试单次业务消耗时间，代入以上公式即可获得执行2h时间、5w用户登录所需的线程数。

1）登录业务-线程数确定

利用Badboy录制 "登录，而后退出ECShop" 的脚本login_logout_ECShop.jmx，导入JMeter中（Thread=1；添加Aggregate Report检测响应数据）。运行Thread Group完成之后，收集聚合报告（Aggregate Report）的数据，如下：

由上图数据结果可知，若采用90%采样，ECShop用户登录系统，单次消耗时间为：1599+1298=2897ms。
实际情况下，还需要考虑模拟用户输入用户名及密码、登录成功后等待返回主页、退出后等待返回主页等操作的思考时间。作如下计时假定：

模拟用户输入用户名及密码：5s
登录成功后等待返回主页：3s
退出后等待返回主页：3s

则单用户访问ECShop登录所消耗时间为：2.897+5+3+3=13.897s。
计算模拟2h时间、5w用户登录所需的线程数为：.
Total_Thread = 50000×[13.897/(3600×2)] = 96.5，取整为97

2）商品随机浏览购买业务-线程数确定

同样利用Badboy录制 "用户登录后随机选择商品浏览、购买完成" 的脚本purchase_ECShop.jmx，导入JMeter配置运行，并收集Aggregate Report报告数据，如下：

若采用90%采样，ECShop用户登录后随机购买商品单次消耗时间为：
1441+1269+1440+2485 = 6635ms
实际情况，还需要考虑以下情形的思考时间，作如下假定：

模拟用户输入用户名、密码：5s
成功登录等待返回主页：3s
加入购物车：5s
编写收货信息：5s
选择配送方式、支付方式：5s
退出等待返回主页：3s

==> 单用户访问ECShop登录后随机购买商品的时间为：6.635+5+3
+5+5+5+3=32.635s
计算模拟2h时间、5w用户登录随机浏览购买商品所需的线程数为：
Total_Thread = 50000×[32.635/(3600×2)] = 226.6，取整227
此时计算出的线程数已经超过该业务要求的100线程并发的基准，故以100个线程为基准，执行业务量测试。

3.测试场景用例设计

根据上述分析数据，设计本次测试的四个场景：
①登录并发基准测试
②登录业务量基准测试
③随机购买并发基准测试
④随机购买业务量基准测试

1）登录并发-场景用例

2）登录业务量-场景用例

3）随机购买并发-场景用例

4）随机购买业务量-场景用例

三、测试脚本用例设计

性能测试过程中，因测试目的不同，可能存在多个不同的场景，但往往只需设计一个脚本。如针对某个业务进行基准测试、压力测试和负载测试，虽然涉及3个场景，但脚本可能只需要1个。因此，测试工程师需要根据场景设计，分析并开发所需的测试脚本。
一般可根据被测业务可能存在的约束进行分析，确定脚本优化及增强方案。以本次测试要求、利用JMeter开发脚本为例，登录、随机购买商品业务的脚本用例如下：

1）登录-脚本用例

2）随机购买-脚本用例

PS：以上POST请求中的传递参数项可通过Fiddler工具抓包获取