性能测试基础（二）

上一篇文章介绍了性能测试流程相关知识，今天介绍一下如何准确的获取性能测试模型，直白点说就是稳定性场景中各接口比例是怎么计算出来的。性能测试模型正确与否直接决定我们的性能测试结论是否有效。

那应该怎么得出准确的性能测试模型呢？首先得知道我们是可以通过日志查看到业务历史请求数据的，这样就能根据业务日志查询出任意时间的请求总数，当然也可以查出任意时间不同请求(接口)的请求数量，从而经过对日志的请求数量分析可以计算出在这个时间段内各请求所占的比例(也就是我们的性能测试模型)。

我们知道了如何得到性能测试模型，接下来就是怎么落地，有2种方法，第1种：直接通过命令分析日志；第2种：使用日志收集工具把日志收集起来存到存储器，再通过可视化工具从存储器中取出数据，然后展示在界面上。第1种的优点是省去了搭环境的过程，缺点是日志量大的时候或者日志文件拆分多的时候分析起来耗时耗力，还不一定统计全。第2种的优点是能在界面上操作，可以把日志信息直观展示给用户，不需要大量计算。缺点是需要搭一套收集日志并可视化展示的集群环境，需要计算服务器成本，比如公司中常用的ELFK日志分析系统。不管选择哪种逻辑都是一样的，下面给大家总结一下落地步骤。

获取性能测试基础模型步骤：

1.统计1个月内每天的总请求数量，找到请求数量最多的1天(这里直接到月，实际工作中根据具体情况可能需要统计1年中峰值的月)。

2.统计这1天中不同请求的总数，这样就可以获取到以天为单位的请求(接口),从而可以得到性能场景内需要包含的接口有哪些。比如 X天的请求数据如下：

  这样我们就可以知道我们的性能测试场景中应该包含接口1-接口8，接口7-8请求较少可以忽略

3.以分钟为单位分别对第2步峰值时间段内的接口进行分组统计，得出每个接口每分钟的请求总数，接着上面的例子如下：‍‍‍‍‍‍‍

4.用这些接口互相对比同一时间内趋势是否一致，如果一致，1个性能测试模型即可覆盖，如果不一致，需要多个性能测试模型来覆盖，上面的例子各接口在同一时间端内趋势一致，所以1个性能测试模型就可以覆盖，实际工作中要根据趋势确是否需要读个模型。

5.去除可忽略的请求，得出需要的性能测试模型框架，梳理业务逻辑，确定请求顺序，这里就按照接口1-6的顺序，实际工作中根据业务修改。上面的例子去掉接口7-8。‍‍

6.因为上面是以分钟为单位统计的，我们把请求总数及各接口的请求总数细化到秒，用总数/某个接口的请求数量就可以计算出这个接口在性能模型中所占的比例，依次类推从而可以计算出准确的性能测试模型，上面的例子计算出TPS如下：‍‍

最后可以得出性能测试基础模型如下：

      通过上面步骤可得出系统的TPS是2669，各接口TPS和占比如上表。

我这里因为目前服务器没有资源在部署ELFK环境啦，所以用假数据列出一下，这样理解起来更容易一点，如果有ELFK日志分析系统，在kibana界面上可以配置出如上过程的数据，后面服务器空闲时候我会把ELFK环境搭建起来，再分享给大家。

7.通过压力工具实现性能测试基础模型，这里用Jmeter给大家看一下结果‍‍‍‍‍‍‍‍‍‍‍‍‍

      通过上面步骤确定了性能测试基础模型，也经过Jmeter实现了性能测试基础模型，通过结果看TPS是不满足我们的预期的，而且还有错误，因为是示例，主要演示性能模型的推演过程。

8.最后用基础模型结合性能需求确定最终性能测试模型中目标TPS。为什么要有这一步呢，大家可以想一想，如果新版本中业务发生变化啦，我们上面的性能模型可能就不适用啦，这种情况就要根据业务变化是否影响了之前的流程，业务是否需要计算增量用户等等来得出目标TPS，如果业务无变化，应用版本有变化，这种情况直接用模型中的TPS当目标TPS就可以。