测试模型

1 引言

1.1 编写目的

本文规范在使用性能测试过程中进行测试模型的分析，旨在指导性能测试实施人员进行测试模型的建立，为后续性能实施打好基础。

1.2 适用对象和范围

预期读者为测试管理人员、测试实施人员、技术支持人员、项目质量管理人员、项目管理人员等系统技术质量相关人员。

2 测试模型构建

通过分析系统的交易路径、交易之间关系、数据的处理与流转、典型交易、业务量、交易比例，以及系统的处理能力等内容，完成测试建型的构建。

2.1 业务场景来源与分类

测试模型构建时需要关注的信息主要有：

• 业务场景列表
• 单交易分析调查结果
• 交易路径分析
• 各路径代表交易调查分析
• 被测系统超时流控机制
• 被测异常场景调研结果
• 生产系统问题分析结果

2.2 业务场景来源

通过对以上资料的研究，应获取以下信息：

• 交易日的日均交易量
• 历史峰值交易日的交易量
• 特殊日的交易量
• 不同交易渠道的交易量
• 一般交易日的交易配比
• 历史峰值交易日的交易配比
• 特殊日的交易配比
• 不同交易渠道的交易配比
• 批量处理的流程
• 批量处理的时间窗口要求
• 系统历史数据量

2.3 业务场景分类

业务场景即业务系统在生产运营过程中的不同运营状态。
交易处理型系统通常包括以下几类场景：

业务场景类型	业务场景描述
正常业务日交易场景	反映的是业务系统在大多数工作日的平均业务受理情况
特殊日交易场景	根据不同业务的不同特性，某些业务系统在一些约定的特殊日期内的业务受理情况与一般营业日不同（例如促销、双11等），主要体现在特殊交易种类、交易量、营业时间上的不同
高峰交易场景	反映业务系统运营过程中出现的短期峰值交易状态，该状态的出现可以是由于集中业务操作、自身流程调度或其它系统接口机制等原因引起
交易线与数据线混合场景	部分系统在联机业务处理中包含一些实时的批量交易或数据更新功能，例如批量发红包、批量查询、等。此类业务的特点是用户终端或服务端的交易请求量不大，但系统需联机实时处理，且处理动作多，比较耗费系统资源

对于批量处理系统，通常还包括以下特定场景：

业务场景类型	业务场景描述
批处理场景	包括正常日/特殊日的批处理
文件/数据处理场景	包括大文件加工以及批量数据处理

2.4 业务场景与测试模型转换

根据测试目标的需要，可能存在的测试模型有以下几种：

• 单交易基准测试模型
• 单交易负载测试模型
• 日间混合负载测试模型
• 稳定性测试模型
• 可靠性测试模型
• 系统超时流控测试模型
• 批量处理测试模型

虽然每个业务场景都与一个或多个测试模型相对应，但是由于业务场景并不保证对被测系统的覆盖，因此需要在业务场景变换成为测试模型过程中进行必要的检查。
技术测试中选取典型业务交易的标准：

• 根据业务量大小选取典型交易，一般通过统计生产系统TOP10 、TOP20确定；
• 选取生产系统中消耗资源最多，或者耗时最长的业务交易；
• 选取生产系统中交易路径最长的业务交易；
• 选取生产系统容易发生故障的业务交易；
• 为满足其他特殊测试目标需要选取的业务交易；

应采取如下步骤完成业务场景与测试模型的转换：

• 根据测试目标确定测试模型中的具体业务场景；
• 根据业务场景所对应的交易配比初步确定测试模型中采用的交易；
• 对于初步选择的交易根据单交易分析结果检查交易路径覆盖并检查各路径代表交易与初步选择交易是否存在差异；
• 如果检查中发现初步选择的交易覆盖了各路径代表交易和系统交易路径，则可确定业务场景及相应的交易配比，否则需要对之间不同的交易进行分析，评估缺少部分对测试目标的影响。如果发现影响没有或很小，则可以考虑保持原业务场景和交易配比不变，否则需要增加相应的交易；
• 确定业务场景和交易配比后，根据测试目标确定压力场景的操作方式；

测试模型与业务场景对应关系如下表：

测试模型	测试目标	对应的业务场景	压力场景
单交易基准测试模型	通过测试，检查该交易是否存在性能缺陷，同时为性能测试提供参考数据	无	单支交易在系统无压力情况下重复执行多次
单交易负载测试模型	通过逐步增加并发量进行负载测试，获取单交易业务处理性能峰值，并验证交易是否存在并发性问题	无	逐渐增加并发量
混合负载测试模型	混合负载测试是按照业务模型的约定在一定量的并发情况下进行测试。通过测试，获取模拟实际生产环境中被测系统性能表现数据	该测试模型可能与正常业务日交易场景、特殊日交易场景、高峰交易场景、交易线与数据线混合场景等多个业务场景对应	逐渐增加并发量
稳定性测试模型	检查在持续的压力情况下，系统长期运行时的业务处理能力及系统可能存在的缺陷	正常业务日交易场景	稳定压力
可靠性测试模型	通过模拟系统可能遇到的各种异常情况，如带宽受限、网络连通不好、网络延时、超时、各系统主机宕机、应用异常终止、资源死锁、大并发用户集中爆发访问等情况，检查系统的异常处理能力	正常业务日交易场景,高峰交易场景	稳定压力稳定压力＋突增压力
系统超时流控测试模型	对系统中各个超时流控功能点有效性、可靠性、稳定性等验证在模拟实际生产系统情况下，验证多个超时流控机制并存情况下的正确性	该测试模型可能使用正常业务日交易场景，但在进行有效性和可靠性验证时可以不使用任何业务场景	根据测试目标选择稳定压力、单交易多次重复执行等
日终处理测试模型	验证日终设计操作正确性以及是否满足日终操作时间窗要求	日终批处理场景文件/数据处理场景	按照日终操作要求执行

2.5 测试模型调整

2.5.1 调整前提

对于一个已经构建好的测试模型，当出现以下情况造成原有测试模型不再适用的时候，必须要对原测试模型进行相应的调整形成新的测试模型：

• 测试目标发生变更
• 业务需求/范围发生变更
• 实际的业务场景发生变化
• 由于系统架构变更或测试环境与实际环境差异
• 被测系统进行重大功能改造
• 某种业务无法模拟或者由于安全因素不能模拟

2.5.2 调整原则

模型调整的一般原则：

• 测试模型的调整必须以测试目标进行驱动
• 当测试目标改变的时候，必须要确定一个新的可行的测试目标，再进行测试模型的调整。也就是说测试模型的调整会依照新的可行的测试目标进行，而不是任意调整
• 测试模型的调整是一项复杂的、动态的迭代过程。测试模型各个前提中任何一个的变化都可能影响到测试模型。因此需要通过多次分析和调整才可能得到一个适合测试目标的测试模型
• 测试模型调整的一个重要原则是，分析测试模型与测试目标偏差的幅度是否超过了可允许的范围。当目标偏离在控制范围内的时候一般不要进行测试模型的调整，但超出了范围就需要考虑进行测试模型调整
• 测试范围变化势必导致测试模型调整，要依据测试范围对测试模型进行适当的调整
• 测试环境变化时也将导致测试模型调整，要根据测试环境的限制对测试模型进行适当的调整

2.5.3 调整方法

进行测试模型调整时，必须考虑两个问题，其一是数据流的清晰完整，其次是测试模型调整的合理性。实际的测试模型调整是一个需要根据实际情况进行权衡的过程。通常进行测试模型的调整一般有两种方法：调整和重构。
调整的方法是，在原有测试模型不变的前提下，对交易之间的占比关系进行适当的调整以符合实际测试目标的需要，通过删减合并的方式对测试模型进行修改。
重构的方法是，对新的测试目标或测试环境进行分析，确定适合的测试模型和相应的业务场景，使之能够和测试目标相匹配。

调整原因	调整方法	调整策略	影响分析
由于业务场景变化使得原测试模型不合理	调整	采用之前的测试模型作为基础，并对当前系统业务结构和规模重新进行评估，得出差异点，对原测试模型进行调整	之前的测试模型可能因为业务结构的发展已经完全不适用了，但此时重构测试模型可能需要花费相同或者更多的工作量
业务需求/范围变更	调整或重构	对变更的业务需求和范围进行梳理，调研评估其业务结构，并对原测试模型进行评估。如果变更只是使得业务场景发生变化，则找出差异点，对原测试模型进行调整；如果变更使原测试模型不可用，则需重新分析业务场景，重构测试模型，以满足或符合测试目标的需要	某些业务需求的变更对业务模型影响并不大，例如业务需求仅是用户操作方式的变更，业务路径和交易量并没有发生改变，则此时不需要对业务模型进行调整。当业务路径或交易量有明显变化时，要考虑调整模型
测试目标变更	调整或重构	分析变更前、后测试目标的差异，是否需要采用不同的测试模型进行测试，围绕测试目标对测试模型进行调整	测试目标的不同对测试模型的要求也会有所差异
系统架构部署变更、测试环境限制	调整或重构	当出现系统的架构进行修改或因测试环境无法和实际生产环境一致使得某些业务无法在测试环境模拟情况时，要分析对业务路径及交易量的影响，并依据此影响对测试模型进行调整	架构调整通常是因性能或商业战略的需要，而测试环境无法和实际生产环境一致在测试实施过程中也是经常发生的
重大的功能改造	调整或重构	分析改造对业务路径和业务量的影响，依据此影响对测试模型进行调整	系统某些功能进行重大的改造，可能会到导致业务路径或业务量的变更
其他因素（时间因素）	调整或重构	根据实际遇到的问题针对性的进行分析，找到影响点，分析影响程度，得出模型调整比例差值，对测试模型进行适当调整	其他影响因素，比如测试时间很紧迫，测试资源受限，无法完全按照业务模型进行实施执行，需要对模型进行裁剪或一定比例缩放以便能在一定程度上即满足测试目标又充分利用现有资源

访问性能测试控制台