性能测试成熟模型业务模型

​

作为一个测试从业者只对性能测试的流程了解，还是远远不够。

要达到预期目标的最佳实践效果，往往离不开理论的指导，对性能测试体系建设来说也不例外，性能测试体系理论的核心价值是在项目实践过程中体现的。我们针对具体方案的设计进行抽象和总结，将其归纳为6个性能测试模型。在企业建设性能测试体系的过程中，性能测试模型可作为性能测试项目实施的基础理论，当每个项目开展性能测试时，基于该理论进行具体的性能测试方案的设计，从而保障企业内部性能测试实施过程的标准化、规范化。

性能测试模型是性能测试工程师开展性能测试项目必须掌握的内容，他们只有深度掌握这6个模型，并在不同的项目实施方案设计中灵活运用，才能达到性能测试项目的预期目标，本文主要聊聊性能测试中的业务模型，模型的目的是什么，模型的内容是什么，具体的方法是什么等。

业务模型是一组功能点或接口的集合及其占比情况，用于合理地模拟生产上真实的业务发生场景。通过不同建模策略和建模规则，获取一定量的具有代表性的功能点或接口及其占比，作为性能测试方案实施的依据。目前常用的业务模型分析方法重点关注具体接口提取规则，而本文从分析数据来源开始，制定了一整套建模方法，系统地归纳总结了建模过程的步骤及其关注点。

一、业务模型的目的和内容

业务模型作为性能测试方案实施的重要依据之一，通过对建模方法和建模原则的分析来完成最终模型的建立。

业务模型建立的目的主要在于两个方面。

在实施范围上，业务模型为本项目明确实施范围，涉及的业务系统及其完整链路等。比如，针对“加购”业务场景进行压测，涉及的业务系统包括前置系统、订单管理系统，链路涉及用户从手机App操作到前置系统再到调用订单管理系统的完整路径。

在实施结果价值上，业务模型为性能测试提供更接近于生产实际的业务场景，使测试结果对生产更具有参考性。设计的测试场景与生产用户使用的场景差异越小，其测试结果对生产的参考价值越大。

总的来说，业务模型建立的核心目的是在用户业务场景使用上保障压测时的真实性。

根据业务系统生产运行的情况，业务建模包括以下3种业务场景模型。

1)日常业务场景模型：

是指在正常工作时间内，根据用户访问量曲线较平缓时的业务场景形成的模型。

2)高峰业务场景模型：

是指在高峰业务量的时间内，根据交易量较大或者用户访问集中时的业务场界而形成的模型。

3)异常高峰场景模型：

是指根据交易量爆炸式增长或者用户集中访问系统时的业务场景而形成的模型异常高峰场景一般用来复现生产上的异常问题，或者对系统做破坏性容灾测试。

二、业务建模的方法

业务模型的建模主要由数据分析、功能点/接口选取、占比推算3个部分组成。日常业务场景、高峰业务场景、异常高峰场景的模型的不同主要体现在功能点或接口选取的时间段上。日常业务场景通常会选取平常日或小时的数据;高峰业务场景会选取高峰日、小时、分，或者特殊日、小时、分的数据；而异常高峰场往往会选取异常产生的时间点的数据。仅从业务模型的角度来说，异常高峰场景在没有生产数据做支撑的前提下，可参考高峰业务场景的模型。

1.数据分析

接近实际生产运行的业务模型须建立在合理有效的数据来源基础上。系统的运行数据往往是业务模型分析最有效的参考依据，但有些被测系统因各种原因不能提供有效的生产运行数据，如未投产的新系统。故以下从生产数据分析、类似系统数据分析和规划数据分析3种情况来描述数据分析的过程。

(1)生产数据分析

一般从系统生产环境中提取运行数据，均是在一个大的时间段内提取数据。为了获取业务模型，需细化分析该时间段内的交易量、交易发生时间及变化率等。

生产数据分析的具体步骤如下:

1)根据测试的具体目标选定用于数据分析的时间段，如季度、月、周等;

2)根据选定时段内交易量变化趋势或者系统运行情况，选定平常日、高峰日或者特殊日，一般特殊日为月末日、年末日、节假日等;

3)对于选定的平常日、高峰日或特殊日，按实际需求细化到小时、分进行评估，得到更小时间段内的交易及其交易量，而对于异常情况，一般直接定位到具体几个小时进行分析。

(2)类似系统数据分析

在系统未投产没有运行数据的情况下，可以优先参考功能相似的系统的运行情况，数据分析方法同上。同时，获取的业务模型须兼顾被测系统功能点的变化，根据实际情况对功能点进行合理的拆分、合并以及数量调整。

比如某电商平台需要上线某App系统，由于该系统自身还没有生产用户数量，此时在设置业务模型时可以参考其他类似App系统的业务场景，如设置“首页”功能压力占比50%、“商品详情”功能压力占比10%、”加入购物车”功能压力占比20%、"下单"功能压力占比15%、“查询”功能压力占比5%，将其来作为系统压测的业务模型。

(3)规划数据分析

对于没有任何数据可参考的系统来说，需同业务/产品部门、开发部门、运维部门一同分析未来生产上可能出现的业务场景，获取业务模型。一般在前期系统技术方案中，会明确系统须支撑的相关交易场景及其交易量。

2.功能选取

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

(1)TOP规则

TOP规则要求在备选集合中选取占交易总量较大的交易纳入业务模型。TOP规则通常会采取以下步骤实施:对所有的交易进行占比分析;按占比从高到低进行累加;将占比累加值不小于选取值的交易纳入业务模型范围。该值通常为90%或以上，可根据具体项目情况设定。

(2)特殊交易规则

该规则要求在备选集合中选取那些投产运行后可能对系统有潜在性能风险的功能点或接口纳入业务模这类功能点或接口主要的特点有:

实现逻辑复杂；

与其他功能点或接口采用不同的实现机制，如不同的中间件、通信协议等；

生产上出现过性能问题；

代表对本模块、其他关联模块或外围系统等有潜在性能风险的新增交易。

(3)内外部系统覆盖规则

在被测系统存在内部子系统或者相关联的外围系统的情况下，内外部系统覆盖原则要求在备选集合中选取功能点或接口时，应在原则上覆盖该系统的众多子系统或相关外围系统。

（4）等价类规则

等价类规则是指建立业务模型时根据测试目的，适当地将技术实现相同的交易进行合并，在对服务器造成同等压力的前提下降低业务模型复杂度。如下图所示，为某系统交易等价类合并的示意图。

上图所示，对于部分查询交易，系统采用了3种技术进行实现，在交易选取时对同样采用实现技术2的交易A、C进行合并，并根据交易A、C的交易总量重新计算占比。

3.占比推算

通过上述步骤可得到入选业务模型的待测功能点或接口及其数量列表。重新计算各功能点或接口的占比，保证占比总和为100%，形成最终的业务模型。

性能测试中的业务模型有缺陷有哪些？

性能测试中的业务模型是指在进行性能测试时，基于实际业务流程和用户行为来构建的测试场景。它试图通过模拟真实世界的使用情况来评估软件系统在不同负载条件下的表现。这种类型的性能测试对于确保应用程序能够满足预期的业务需求至关重要。以下是采用业务模型进行性能测试的一些主要优点和缺点：

主要优点有以下几个：

真实性：业务模型基于真实的用户交互和业务逻辑，因此可以更准确地反映生产环境中的系统行为。这有助于识别那些仅在特定业务条件下才会出现的问题。

全面覆盖：通过考虑各种业务操作，可以创建一个全面的测试计划，涵盖多种可能的工作流。这样可以在早期阶段发现潜在的瓶颈，避免在上线后才发现问题。

优化用户体验：专注于关键业务路径的性能可以帮助团队优先解决对终端用户影响最大的问题，从而提高整体满意度。

支持决策制定：通过对不同业务场景下系统性能的了解，管理层可以根据数据做出更加明智的投资决策，比如硬件升级或服务扩展。

促进跨部门合作：构建有效的业务模型通常需要业务分析师、开发人员以及运维团队之间的紧密协作，这有助于打破孤岛效应，增强组织内部沟通。

主要缺点主要有以下几个：

复杂性：要建立一个精确反映所有业务场景的模型是相当复杂的，特别是当涉及到多变且复杂的业务流程时。这不仅耗时，而且需要深厚的专业知识。

维护成本高：随着业务规则的变化和技术更新换代，保持业务模型与当前状态同步是一个持续的过程，这意味着长期来看会有较高的维护成本。

难以完全复制现实：即使是最精心设计的业务模型也可能无法完全捕捉到所有可能出现的情况。例如，在线购物平台上的突发流量高峰等不可预见事件。

资源消耗大：为了充分测试某些极端或边缘案例，可能需要大量的计算资源来进行大规模并发访问或其他压力测试，这对预算有限的小型企业来说可能是个挑战。

依赖于高质量的数据输入：如果用来生成业务模型的数据不够准确或者不具有代表性，那么由此得出的结果可能会误导性的。确保数据的质量和相关性是非常重要的。

综上所述，虽然使用业务模型进行性能测试确实存在一些挑战，但其带来的好处远远超过了这些困难。通过仔细规划并采取适当的方法论，组织可以有效地利用这种方法来改善系统的整体性能和可靠性。同时，不断迭代和完善业务模型也是保证测试结果准确性的重要手段之一。

阅读完成后若有收获，不吝关注，点赞，分享转发等操作我不嫌弃哈！

​