如何建立软件性能测试模型

如何建立软件性能测试模型 

今天和大家分享的是一个相对宽泛的设计思路，有兴趣的朋友可以再补充和细化。在以往的模型设计中，我一般会遵循这个设计步骤：信息调研—场景分析—模型设计。

• 信息调研

按照上线情况将应用系统分为未上线和已上线两类。

对于未上线的系统的信息调研比较困难（由于各类系统差异较大，今天对于未上线系统的调研与分析就不作深入探讨了）。在没有参考案例的情况下，更多的是与系统的最终用户和系统设计人员进行沟通。沟通的范围一般包括：

• 应用系统的类型，如：交易型系统、管理型系统、数据处理型系统等；
• 应用系统的操作人群，以及他们经常操作的哪些功能，也就是依靠系统处理的业务；
• 固定人群的操作习惯，如：哪些人会在哪个时间段集中处理哪些业务；
• 固定操作人群的用户量有多少；
• 系统设计的最大并发用户数、最大在线用户数等信息
• 初步预计，系统上线后日处理业务量有多少
• 对于后台系统，需要关注系统的前端渠道，以及各个渠道的交易请求规律和交易量

对于已经上线的系统，可以方便的从运维部门获取相关数据信息。生产环境下的交易场景复杂多变（取决于市场表现），不能够仅对一个特定时期的业务量信息进行调研。如果你对这个系统还不够了解，我建议采样一个周期较长的时间段的交易量信息，有条件的情况下，可以把全年的交易量信息收集一份。

无论是已上线和未上线的系统调研工作，建议大家事先准备好调研表，很多刚刚接触这方面工作的朋友或许准备起来比较困难，我这里有一份整理过的供大家参考。各位在自己定制调研表时，要记得不断更新不断增加调研的内容，从而使得调研工作更加充分。

• 场景分析

所谓场景分析，就是对不同交易场景进行分类，大多数情况下，每一个应用系统都存在多个典型场景。这些典型场景或许不全是交易量的峰值情况，它们具体体现为交易的类别与交易比例上的差异。之所以需要分析多个场景，是因为在不同的交易类别、比例情况下，系统的处理能力存在着较大的差别，有可能在一个交易量不大的特定场景下，应用系统已经趋于资源占用的最大负荷，或者会产生未知的影响，比如大量报错等。针对典型场景的选取，请大家参考如下：

如上图所示，我们可以看出有4～5个交易量较高的交易日，就可以尝试从这个几个日期入手进行分析，对具体某一天的分析如下：

通过对场景的分析，我们已经初步得到每个交易日的特定场景发生的具体时间，要知道，每个场景的背后一定有一个刺激因素在支持，我们需要根据当日的相关信息进行判断其发生的原因以及未来再次发生的几率性。

• 模型分析

在圈定特点场景后，就可以对业务（交易）的模型模型进行分析了。很多人分析到这个步骤时，往往采用“小时交易量（笔）/3600（秒）”来计算TPS，然后进行一个加权算法。个人认为这种非常不精确，当然，如果基础信息数据无法再精确，很多时候也只能采用这个算法。在有条件的情况下，尽量获得更详细的调研数据，如：每10分钟（5分钟）的交易量汇总统计数据。我在以往的工作中会调研到这个微粒度：

然后，采用该“10分钟的交易量/（10分钟*60秒）”，然后再根据情况进行适当的加权计算，从而得到TPS值。剩下的工作就是分析业务（交易）占比了，根据以往的经验，典型交易的选取一般遵循如下原则：

• 采用TOP 10或TOP 20依次筛选占比较高的交易，直至筛选总量超过基础数据总量的80%；
• 重要的交易不按照TOP方式选取，可直接选入典型交易范围；什么是重要的交易呢，一般认为交易的优先级较高，交易在历史过程中易发生错误，或是一支新交易，我们对他了解甚少，需要纳入测试范围。

这里给出一个选取的样例，请大家参考：

基于上述的样例，共筛选了12支交易作为初步的典型交易，共计占比81%。如下：

接下来的工作就是反推出测试模型的各支交易占比了，反推结果如下：

到了这个步骤，测试模型的分析工作基本就结束了，需要特别说明的是，在选取典型交易过程中，你会发现有部分典型交易不具备可测试性，当然，原因就很多了，比如：数据不具备重复利用性、或者这支交易本身存在问题。对于这种情况，我们需要对模型进行适当的调整，调整的方法很多，如：

• 放弃这支交易，增加一支性质相同的交易的比重；
• 放弃这支交易，重新选择一支新的交易来替代。

对已模型调整，应当采取谨慎、科学的方式，在不了解各支交易特点的情况下，不建议随便进行调整。这份模型分析，仅作为一份指南，希望对大家有所帮助，在很多性能测试个案中，这份指南也有很多不适应性，希望大家酌情参考，也希望各位多多给意见，我们一同提高。（

原文转自：http://www.ltesting.net