业务模型

1 引言

1.1 编写目的

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

1.2 适用对象和范围

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

2 业务模型分析准则

2.1 分析目标

通过对调研收集到的相关资料与信息，结合测试目标和内容，针对性地从不同角度与层面对信息进行分析梳理，并重点分析系统的交易路径、交易关联关系、数据的处理与流转、业务量、交易比例、典型交易，以及系统的处理能力等性能点。

2.2 已上线系统

2.2.1 交易量分析

进行系统交易量分析主要考虑以下几个方面：

• 历史峰值交易日的交易量
  分析系统在历史最高交易日系统的交易情况，主要分析最高交易日业务的构成、占比、系统资源等消耗情况，比如峰值期间CPU、内存、I/O等资源的消耗情况，以及交易响应时间、交易吞吐量、交易成功率等应用方面的性能指标，通过分析这些信息的目的在于分析系统可能承受的最大交易量是怎样，在测试环境可以按照预期进行实际的测试，并尽早的发现在峰值运行时间系统可能会出现的一些异常情况，为实际生产系统的性能做参考。
• 特殊交易日的交易量
  某些系统可能在一些特定的日期，比如促销、双11、证券系统在基金申购日、国债发行日等特殊日期其业务量与普通交易日的业务类型或者业务量占比是不同的，此外不同的系统在节假日或工作日内其业务量和占比也有可能是不同的。
• 不同交易渠道发起的交易量
  针对同一系统可能会有不同的发起终端，进行交易量分析时要考虑到从不同交易渠道发起的交易量情况，以便在测试环境能进行同样比例地模拟。比如电子购物网站，购物发起端主要有PC端和手机端、支付的时候主要有各大银行、支付宝、快钱等；再比如对证券系统，发起的途径有若干种：网点柜台、自助设备、电话委托、网上银行、手机银行等渠道，进行业务量分析要分别统计出从不同渠道发起的交易量的占比情况。

2.2.2 交易占比分析

交易占比的分析主要为了对系统的业务规模进行定量的分析，得出在特定条件下系统各业务的占比关系如何。交易比例同交易量的分析类似，也要区分不同的场景下，系统业务的构成：

• 历史峰值交易日的交易配比
  根据之前的分析我们得出系统在历史峰值交易日的交易量，同时要分析此期间内主要的业务构成是怎样的，可以考察交易量top10位或者20位的交易主要是些什么样的交易，这些交易占总交易量的百分比，进而换算统计这些业务之间的比例关系是怎样的。依据同样的比例关系可以在测试环境进行同比例的模拟测试，以保证测试的准确性和有效性。
• 特殊交易日的交易配比
  同样的，在特殊交易日的业务构成和各业务占比也采用上面的方法进行统计。
• 不同交易渠道发起的交易配比
  这主要是进行对各交易发起方式进行量化的分析，在进行容量测试或性能测试时测试人员可以比较直观的了解到如何对系统进行加压。

2.2.3 单支交易分析

单支交易分析是指针对具体一支交易进行深入的调研与分析，目的在于清楚地理解特定交易在不同系统之间的调用关系和实际处理过程。 结合测试的环境及时间要求，在业务分析过程中，可能无法短期内完成所有交易的分析，但必须进行对关键交易、代表性交易的分析，特别是不同路径的代表性交易的分析，以便于后续相关测试模型的建立。 单支交易调查内容主要包括：

• 交易功能描述 描述交易的基本业务功能
• 交易交换处理流程 对于跨系统交易，应描述其关联系统以及在不同系统间的交换过程，对应的交易码/交易名称、主要处理逻辑，以及流转顺序
• 交易操作说明 描述交易的发起方，发起方式、具体操作及步骤
• 交易数据说明 描述交易的输入/输出，涉及到的系统数据、业务参数等

2.2.4 典型交易分析

典型交易是指具有一定代表性的重要交易，包括几个方面的代表性：
业务功能代表性或交易类型的代表性

• 交易量的代表性
• 交易路径的代表性
• 处理逻辑的代表性
• 开发人员挑选的交易
• 有业务发展趋势的交易
• 资源消耗高的交易
  另外还可以包括一些关键交易或重点交易，例如高服务级别、关键数据处理类的交易。这些交易也是对系统业务掌握以及在性能测试中需要重点了解的内容。通过分析这些典型交易，能快速全面的理解系统的处理环节和处理过程，以及通过从不同渠道发起的交易，要经过各不同的交易系统。

2.2.5 批量交易分析

日终批量分析主要考虑以下几方面的内容：

• 日终批量处理的基本流程
  首要分析日终批量处理的业务流程。可以从日终批处理任务的基本步骤着手，逐一进行分析出每一步进行的业务功能，需要处理的交易量，可能的耗费时间等。在这个过程中可以建立一个日终批处理的表格类详细统计一些关键的业务或技术信息。
  以下是一个简单的样例：

步骤	任务名称	业务量	预计耗时
BT1	批量发红包	总记录3000万，共35省市	20分钟以内
BT2	批量推送	总记录3000万，共35省市	30分钟以内
……	……	……	……

• 日终批量处理的时间窗口
  这是统计总的日终批量处理的消耗时间。日终批处理的实际耗时如果大于设定的时间窗口必然会影响到日间业务的正常运转。

• 日终批量处理失败后的异常处理
  这一点是在系统架构设计时考虑的问题，在这里列出来是为了在测试环境能对这些异常情况进行相关的模拟，验证对应的解决方案是否正确、完善。也为生产运维部门提供一些回归测试，对生产环境的一些现象进行复测，查找原因。

2.2.6 批量数据分析

批量数据处理分析包含系统历史数据量、日交易流水数据量。考虑处理过程中是否包含数据转换等其他涉及数据处理的问题。

• 系统历史数据量 主要是分析系统目前沉积的历史数据量的规模，分析系统业务处理是运行在怎样的一个数据量级上，包含数据记录总数和数据存储占用的磁盘空间大小等。这对于在测试环境准备的基础数据量是有很大指导意义的，如果测试环境的数据量级和生产系统相差很远，可想而知其测试的结果的真实性和准确性是要大大折扣的。
• 日交易记录数据量
  主要分析系统的日交易处理生成多少笔记录，以及这些记录占用的磁盘空间，这样在测试环境进行测试数据准备时，就有一个数量级的概念，准备需要花费的时间和空间就有一个初步估算。
• 数据转换规则
  分析各系统之间的数据转换规则，采用何种技术实现，不同数据级的耗时情况，处理中是否需要人为手工干预，处理过程能否监控。

2.2.7 生产问题分析

对生产问题的分析主要是调查系统在生产运营过程中，是否曾发生过严重的性能事故，如宕机、资源耗尽、交易阻塞、业务不能受理等影响自身业务及关联系统业务处理能力的情况。
生产问题是多种多样的，可能是系统的资源不够、配置不合理、功能不完善、网络异常、非法操作、应用程序例外处理错误或者一些特殊情况的出现等等原因引起。而且往往许多生产问题与特定环境及时间有关，问题也不好模拟重现，因此在测试中，并不能保证准确定位到问题的症结所在。
在性能测试分析时，可通过生产问题现象、现场分析意见、生产中的处理方式等信息，与项目组、运维进行基本判断，并制订相应的验证策略，在性能测试过程中进行模拟验证，找到引发问题的原因，从而协助项目组进行问题的定位和解决。

操作过程：

主要的分析点：

• 问题发生前是否有征兆
• 问题是否发生在特殊日期
• 受影响的业务主要有哪些
• 事故点与前端系统及后端系统接口的状况
• 网络状况
• 操作系统、中间件、数据库等系统软件是否有升级、补丁，应用系统是否有功能改造
• 是否正进行系统维护或有异常操作
• 业务受理场景是否有异常或特殊情况

2.2.8 样例

通过分析某系统历史业务高峰时候业务量，发现某4天高峰时段10分钟的交易量是不同的，其中有2天高峰时段DGZZ的业务量占比在50%左右，而另外两天高峰时段DGZZ的业务量占比在20%左右，业务占比差距很大，因此在测试的时候，需要建立两个不同的业务模型。

2.3 未上线系统

2.3.1 风险分析

已上线系统相关分析的方法完全适用于未上线系统，由于未上线系统没有具体的业务量作为参考，业务类型和占比只能依靠业务部分预估。预估毕竟有很大的误差，也无法很精确的模拟现实中的场景，因此对于未上线系统，尽量减少风险。

2.3.2 风险预防

对于未上线的系统，选取业务模型的时候，应遵循如下准则：

• 尽可能的多选取典型业务
• 至少做5个梯度单交易负载，看服务器资源消耗情况
• 重新评估业务模型，对于资源消耗比较高的业务，如果业务模型中此业务占比很低的话，业务一旦爆发，会存在很大的性能风险，因此混合交易的时候，需要提高此业务占比。

3. 业务模型分析过程

请参照：流程体系——生产系统历史交易量分析方法

访问性能测试控制台

转载于:https://www.cnblogs.com/AmilyWilly/p/8603131.html