业务模型

业务模型是一组功能点或接口的集合及其占比情况，用于合理地模拟生产上真实的业务发生场景
在实施范围上，业务模型为本项目明确实施范围，梳理涉及的业务系统及其完整链路等
在实施结果价值上，业务模型为性能测试提供更接近于生产实际的业务场景，使测试结果对生产更具有参考性。
业务模型建立的核心目的是在用户业务场景使用上保障压测时的真实性。

业务建模包括以下3种业务场景模型。
1)日常业务场景模型：是指在正常工作时间内，根据用户访问量曲线较平缓时的业务场景而形成的模型。
2)高峰业务场景模型：是指在高峰业务量的时间内，根据交易量较大或者用户访问集中时的业务场景而形成的模型。
3)异常高峰场景模型：是指根据交易量爆炸式增长或者用户集中访问系统时的业务场景而形成的模型。异常高峰场景一般用来复现生产上的异常问题，或者对系统做破坏性容灾测试
业务模型的建模主要由数据分析、功能点/接口选取、占比推算3个部分组成

数据分析

(1)生产数据分析一般从系统生产环境中提取运行数据，均是在一个大的时间段内提取数据。为了获取业务模型，需细化分析该时间段内的交易量、交易发生时间及变化率等。
生产数据分析的具体步骤如下：
1)根据测试的具体目标选定用于数据分析的时间段，如季度、月、周等；
2)根据选定时段内交易量变化趋势或者系统运行情况，选定平常日、高峰日或者特殊日，一般特殊日为月末日、年末日、节假日等；
3)对于选定的平常日、高峰日或特殊日，按实际需求细化到小时、分进行评估，得到更小时间段内的交易及其交易量，而对于异常情况，一般直接定位到具体几个小时进行分析。图为银行核心业务系统高峰日的交易情况统计图。
在这里插入图片描述
其中15时～17时的交易量约为50000，若以小时为单位进行建模，则可选取当日交易高峰时段15时～17时为分析基准。
(2)类似系统数据分析在系统未投产没有运行数据的情况下，可以优先参考功能相似的系统的运行情况，数据分析方法同上
比如某电商平台需要上线某App系统，由于该系统自身还没有生产用户数量，此时在设置业务模型时可以参考其他类似App系统的业务场景，如设置“首页”功能压力占比50％、“商品详情”功能压力占比10％、“加入购物车”功能压力占比20％、“下单”功能压力占比15％、“查询”功能压力占比5％，将其来作为系统压测的业务模型。
(3)规划数据分析对于没有任何数据可参考的系统来说，需同业务/产品部门、开发部门、运维部门一同分析未来生产上可能出现的业务场景，获取业务模型。一般在前期系统技术方案中，会明确系统须支撑的相关交易场景及其交易量。

功能选取

通过前期数据分析，可得到某个时间段内的功能点或接口及其请求量，作为备选集合供后续进一步筛选。这些功能点或接口往往数量繁多。因此，基于测试目的和效率等方面的考虑，在业务模型的建立时通常需要遵循4个规则：TOP规则、特殊交易规则、内外部系统覆盖规则和等价类规则。一次建模过程可以同时使用一个或多个规则，从而更准确地获取业务模型。

TOP规则

TOP规则要求在备选集合中选取占交易总量较大的交易纳入业务模型。TOP规则通常会采取以下步骤实施：对所有的交易进行占比分析；按占比从高到低进行累加；将占比累加值不小于选取阈值的交易纳入业务模型范围。该阈值通常为90％或以上
在这里插入图片描述
这是一个交易选取阈值设定为90％的业务模型的分析过程，其中占比累加值大于90％的交易B、C、A、D被选入业务模型

特殊交易规则

(2)特殊交易规则该规则要求在备选集合中选取那些投产运行后可能对系统有潜在性能风险的功能点或接口纳入业务模型。这类功能点或接口主要的特点有：❑实现逻辑复杂；❑与其他功能点或接口采用不同的实现机制，如不同的中间件、通信协议等；❑生产上出现过性能问题；❑代表对本模块、其他关联模块或外围系统等有潜在性能风险的新增交易。
在这里插入图片描述
某系统的实际业务交易占比。在仅占1％的“其他交易”中，“信贷业务”为新增交易，采用了一个公用功能模块，投产后可能对别的交易产生性能风险。此外，“大小额业务”的处理逻辑复杂且执行时间过长。因此将二者纳入业务模型。