12丨性能场景：做参数化之前，我们需要考虑什么？

小结一下，在性能测试中，我们关注的参数化数据主要有以下几个方面： 1）参数化数据应该用多少数据量？ 我们需要保证测试时间足够长、满足测试的负载请求需求，根据「目标tps x 持续时间（秒级）」可以计算出参数化数大概的量级。 2）参数化数据从哪里来？ 大概分为两大类型： - 死水数据，即out-of-box（事先创建测试数据），数据存在后台的数据库中； - 活水数据，即On-the-fly（实时创建），数据库不存在这些数据，构造参数化数据需要符合业务特点。 构造测试数据通常有以下两种方法： - 通过 API 调用生成测试数据； - 通过数据库操作生成测试数据。 3）参数多与少的选择对系统压力有什么影响？ 满足测试的负载请求足够多和数据足够多样化，从而最大限度地减少或者掩盖缓存等其他因素的影响。参数取得过多，对系统的压力就会大；参数取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。 4）参数化数据在数据库中的直方图是否均衡？ 参数化数据需要符合真实业务数据分布情况，这样更符合业务真实场景。

1.参数化数据的分析重点是哪些？在不同的场景中为什么参数化数据有如此大的差异？ 分析重点是获知数据量。一是通过业务模型分析计算，获得初步的数据量要求；二是根据限制条件和业务场景，确定数据类型；三是结合上述两点，最终确定参数化数据的数据量。 不同场景中，数据使用对业务的完成是不一样的，比如某一场景中数据可以反复出现，不影响业务，自然能实现预期的场景；而另一场景中，反复出现的数据却不能多次实现同一业务，这种情况下，当时无法实现预期的场景。 2.参数化数据的来源和获取要符合哪些规则？当不符合获取规则时，会产生什么问题？ 参数化时需要确保数据来源以保证数据的有效性，千万不能随便造数据。这类数据应该满足两个条件：要满足生产环境中数据的分布；要满足性能场景中数据量的要求。 产生的问题：1.不合理的数据分布，会干扰测试结果，增加后续分析和测试的工作量；2.数据取得过多，对系统的压力就会大；数据取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。

1、参数化数据的分析重点是哪些？ 在不同的场景中为什么参数化数据有如此大的差异？ 参数化的数据量。 具体还是要结合具体的业务来进行分析，是否可以重复使用数据 如果仅仅是一个查询接口，没有涉及缓存，每次都是走一个DB的查询，那这样的话可以使用重复数据。 如果这个接口设计了读写，并有缓存，就要分开来进行考虑了。 2、参数化数据的来源和获取要符合哪些规则？ 当不符合规则时，会产生什么问题？ a）、数据来源尽可能贴近生产环境的业务逻辑 b）、满足生产的数据分布（分库分表..） 当不符合规则是，会导致性能测试意义变得不大。因为没有模拟生产的用户业务操作。 举个栗子： 一个接口是用来获取用户的VIP的状态的？ 当用户符合条件，需要将用户的状态置为VIP（一次update操作），同时设置缓存。当下次查询的时候，就会直接命中缓存。 如果采用的同一个数据，只有第一个请求，会走到所有的逻辑判断，后续的请求就会直接命中缓存，TPS很高，响应时间很短。给人一种错觉，接口的性能很好，其实并不是符合实际需要的。 这是我们就需要采用参数化的不循环逻辑，构造大量的符合条件的参数化用户来进行测试。

那老师登录的点来说，如果被测系统即使允许同一个用户名反复登录系统，当只用一个用户名去模拟并发需求时数据库始终是对这一条数据进行查询，如果用数据库大量的用户去参数化模拟登录，数据库除了先查询第一个，还会去先查询其它用户名是否存在，这个时候数据库的压力和查询一个用户名的压力是完全不一致的。 带来的测试结果就是这并不符合实际场景的需求 更通俗的来举个例子，外卖小哥长期对一个地址送餐，如果在这一条线上必然已轻车熟路，因为他知道哪里是哪里，如果去一个新地址送餐，压力、时间消耗自然就比以前的多得多了

今日思考题： 参数化数据的分析重点是哪些？在不同的场景中为什么参数化数据有如此大的差异？ 参数化数据分析时的重点是业务逻辑，比如数据量、数据来源、参数的多少以及数据分布是否与生产一致。 参数化数据要根据具体的场景来进行分析，比如有些数据可以重复使用，此场景中的参数化数据量就会少一些；而有些数据只能使用一次，此时就需要根据性能场景要求配置足量的数据。归根结底还是业务逻辑不同。 参数化数据的来源和获取要符合哪些规则？当下不符合获取规则时，会产生什么问题？ 数据的来源和获取要满足生产环境中数据的分布，以及性能场景中数据量的要求。参数过多，会对系统造成过大的压力；参数过少，不符合真实场景，无法测出系统真实的压力。 这节的内容很重要，所谓“磨刀不误砍柴工”，必须要花时间搞清楚业务逻辑，这样才能保证最基本的数据没问题。如果连数据都没弄明白，后面的一切都是徒劳呀！

参数化数据应该用多少数据量？ 1、之前做性能测试，不会计算使用多少数据，反正找几千条数据做性能测试，如果可以重复使用，就用几个用户做压测。经过老师这样讲解，1、循环场景使用【用户数据=线程个数】2、不可循环使用的数据Tps * 持续时间如【100（pts）x30*60(时间)=180000（条用户数据】 ；明白（配置参数之前，我们需要先判断这个参数是什么类型的数据） 参数化数据从哪里来？ 1、后台数据库中； 2、在脚本执行成功后会将这些数据 insert 或 update 到数据库中； 3、通过模拟业务接口把数据跑进去； 明白：参数化时需要确保数据来源以保证数据的有效性。 参数多与少的选择对系统压力有什么影响？ 1、明白：如果压力工具使用的数据量少，那么应用服务器、缓存服务器、数据库服务器，都将使用少量的缓存来处理，相应消耗资源比较少，测不实际效果； 2、如果压力工具使用的数据量少，那么应用服务器、缓存服务器、数据库服务器，都将使用少量的缓存来处理，导致命中率高，响应实际块； 3、参数取得过多，对系统的压力就会大； 4、参数取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力 感谢老师总结：对一个系统来说，获取的参数化数据是否合理，会直接影响压力测试的结果有没有意义。 参数化数据在数据库中的直方图是否均衡，这一层学到【如果数据取自于数据图，我们通常要检查一下数据库中的数据直方图。 对于直接从生产上拿的数据来说，数据的分布更为精准。】性能测试，性能测试数据之间影响测试结果。 感谢老师总结的【参数化数据的合理性对性能场景有着举足轻重的作用。通常，我们在做参数化数据之前，需要先分析实际业务的逻辑】 参数化数据的分析重点是哪些？ 1、参数化数据的分析重点是业务逻辑,只有符合逻辑的参数化，对性能测试结果会之间影响。 在不同的场景中为什么参数化数据有如此大的差异？ 1、电商下单压测，如果用重复数据，完全不符合实际业务情况，会导致大量缓存，结果不真实； 2、如果是登录后操作其他业务，就可以用几个用户登录后，进行其重复业务操作压测 参数化数据的来源和获取要符合哪些规则？ 1、通过数据库之间查出来做参数文件 2、通过接口把数据跑出来这样不会破坏表，更真实 当不符合获取规则时，会产生什么问题？ 1、压测结果不真实； 2、影响压测判断；

当不知道tps情况下，如何确定参数化的数据量以及设定线程数啊

老师，怎么看数据库中数据分布直方图？

1、参数化数据的分析重点是哪些？在不同的场景中为什么参数化数据有如此大的差异？ 重点有三个方面：业务逻辑、数据量、数据分布（数据质量） 理解业务逻辑，确定所需数据的类型、数据的数量。在参数化时，数据类型决定了哪些数据可以重复使用，哪些不可以，要根据业务逻辑尽量的接近现实情况，这样才会测试出上线后真实的情况。根据数据类型、TPS、运行时间，才能算出一个至少要准备的数据量。在准备数据时，也要考虑数据分布的直方图，这也需要对业务逻辑进行分析。比如一个搜索引擎的测试，我们需要考虑在多大的数据池中搜索，比如在全国范围内搜索和在一个城市范围内搜索这个数据的直方图不是一个级别的。同样在一个城市范围内搜索，在北京、上海搜索与在地广人稀的城市搜索也是不同的。这就说明了业务逻辑分析的重要性，业务逻辑分析的结果决定了数据量、数据分布的质量。 场景不同，数据量也不同、TPS也不同；比如，设置一个搜索范围为北京的场景，基础数据池为百万级别，TPS假设在500/秒，如果我们要运行场景10分钟，搜索关键词不能重复，我们至少需要准备500*10*60=300000个关键词，多了不限。设置一个搜索范围的基础数据为10万级别的城市，TPS假设在1000/秒，如果我们运行场景10分钟，搜索关键词不能重复，我们至少需要准备1000*10*60=600000个关键词。这仅仅是数据量的说明，还需要考虑关键词的命中率。 2、参数化数据的来源和获取要符合哪些规则？当不符合获取规则时，会产生什么问题？ 个人觉得最主要的规则是尽量靠近上线系统真实情况。不无限靠近系统的真实情况时，可能会造成两种情况，一是上线后宕机，引起经济损失；二是花了重金保证了不宕机，但性价比太悬殊。其实这又回到了测试的价值上，我们是要找到一个性价比的平衡点，还是要找出所有的bug？我觉得可能在工作中，我会出于安全考虑，设置一个业务逻辑上更接近真实情况的场景、一个在接近真实情况场景上再加一定百分比的压力（最后上线的应该是这个）。【我感觉这个问题回答的有点跑偏了，但是确实是想到了这些。】

10万参数化数据都放在文件里，可能的风险是，参数化文件过大、压测工具加载文件性能差，设置无法成功读取文件，这个问题有同学留言过，老师回答是“放在放数据库或者放redis里”，但是又有一个问题，跑脚本时候怎么读取到里面的数据呢？