性能测试学习笔记(四)

一、关联和断言

满足如下条件的数据都是需要关联的：1. 数据是由服务器端生成的；2. 数据在每一次请求时都是动态变化的；3. 数据在后续的请求中需要再发送出去。

JMeter中常用于数据关联的组件：1、JSON提取器(提取JSON格式的响应数据) 2、Xpath提取器(提取HTML格式的响应数据) 3、正则表达式提取器(提取任意格式的响应数据) 4、跨线程组关联使用JMeter属性(__setProperty函数保存成JMeter属性，__property函数读取JMeter属性，函数执行需求使用BeanShell取样器)

断言就是判断服务端的返回是不是正确的。JMeter中常用断言的组件：1、响应断言(对任意格式的响应数据进行断言) 2、JSON断言(对JSON格式的响应数据进行断言) 3、持续时间断言(对响应时间进行断言) 【JMeter在请求的返回层面有个自动判断机制，通过响应状态码】

二、参数化

1、参数化数据应该用多少数据量？

参数化数据要用到多少取决于场景，例如有时候做脚本时考虑的是，有多少线程（Thread）就配置多少用户，让每个线程在同一个用户上循环执行。这样的用户参数化配置，只能满足一些比较特定的场景。比如说，用户在早上登录系统之后，一直在系统中带着登录session做业务操作，并且不会退出，只有在下班时才退出系统。但在有些场景中，这是完全错误的配置方式。比如说电商系统，用同一个用户账号不停循环购买商品，就是不符合真实场景的。

2、参数化数据从哪里来？

• 用户输入的数据在后台数据库中已存在，这类数据必须查询数据库之后再参数化到工具中
  • 存在后台数据库中
    
  • 需要用户主动输入
  • 用户输入的数据会和后台数据库中的数据做比对
• 用户输入的数据在后台数据库中不存在。在业务流中，这些数据会 Insert 或 Update 到数据库中，这类数据必须通过压力工具做参数化，同时也必须满足业务规则
  
• 数据库中原本不存在这些数据
  
• 在脚本执行成功后会将这些数据 insert 或 update 到数据库中
• 每个用户输入的数据可能相同，也可能不同，这取决于业务特点

3、参数多与少的选择对系统压力有什么影响？

如果测试的系统使用了不同的缓存系统，在参数化时要考虑缓存系统的容量，如果参数取得过多，对系统的压力就会大；参数取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。

4、参数化数据在数据库中的直方图是否均衡？

对于参数化数据来说，如果数据取自于数据库，通常要检查一下数据库中的数据直方图。 对于直接从生产上拿的数据来说，数据的分布更为精准。但是对于一些在测试环境中造的数据，则一定要在造数据之后，检查下数据分布是否与生产一致。

5、JMeter参数化实现方式

• 定义变量(基础)
  • 用户自定义变量(全局参数)
  • 用户参数(针对每个用户取不同的值，但是不能针对同一个用户的不同循环取不同的值)
• 文件定义的方式(测试数据都是固定的情况)
  • CSV数据文件(针对每个用户的每次循环取不同的值)
• 数据库的方式(灵活)
• 函数的方式(灵活)
  • counter函数

三、场景设计

在这个场景设计中，首先，要列出自己要测试的业务比例、业务目标 TPS 和响应时间指标。

在做项目的时候，经常会这样制定一个统一的响应时间指标，这样做也不是完全因为懒，更多的是根本不知道如何定每个业务的时间。但我们性能测试人员要知道，这显然是不对的，因为业务不同，响应时间指标也应该不同，合理的做法是给出每个业务的响应时间指标。

1、基准性能场景

首先，我们要知道，每个业务在系统中的最大容量是多少。分别对单业务进行测试，统计出最大TPS与最大TPS时对应的响应时间。

2、容量性能场景

根据业务比例的不同，设计不同的线程进行测试。重点是：1.场景不断 2.控制比例

可以从上面的数据中看到，业务目标 TPS 已经达到，响应时间也没有超过指标， 如果业务要扩展的话，有两个业务将会先受到影响，那就是业务 4 和业务 5，因为它们的测试 TPS 和最大 TPS 最为接近。这是在我们推算业务扩展之后，再做架构分析时要重点考虑的内容。如果是在实际的项目中，这里会标记一个业务扩展风险。

3、稳定性性能场景

在资料中看到，稳定性测试应该用最大TPS的 80% 来跑。这似乎又是一个由28原则导致的惯性思维，在具体的项目实施过程中，完全没有必要遵守这些看似有道理，实则对具体项目没什么用的原则。系统用最大 TPS 能跑下来，业务一直很正常，稳定性目标能达到，为什么不能用最大 TPS 来跑呢？至于用多大的 TPS 来运行，又有什么关系？只要系统在正常处理，资源没有出现问题，也没有报错，那这个场景就是有效的，目标也是能达到的。

4、异常性能场景

异常性能场景的目标是为了判断所要执行的操作对系统产生的影响，如果 TPS 不稳定，怎么能看出来异常点？当然是稳定无抖动的 TPS 是最容易做出异常动作产生的影响。

三、监控设计

监控是性能分析承上启下的关键点。监控设计应考虑如下几点：1、分析系统的架构。在知道架构中使用的组件之后，再针对每个组件进行监控。2、要有层次，要有步骤。应该是先全局，后定向定量分析 3、通过分析全局、定向、分层的监控数据做分析，再根据分析的结果决定下一步要收集 什么信息，然后找到完整的证据链。

通过全局监控项逐步学习了解定向监控项。