思考题：
思考题
你可以思考一下下面几个问题：
为什么参数化数据要符合生产环境的数据分布？
为什么参数化数据要关注组合逻辑关系，而不是随意设置组合？
读者：
JMeter 的 CSV Data Set Config 功能用来从文件中读取数据行，并将它们拆分后存储到变量中。
个人理解，Recycle on EOF的优先级高于Stop thread on EOF，也就是说，需要先判断Recycle on EOF，如果是Flase，直接在文件结束时就停止了线程，根本不考虑Stop thread on EOF参数值；
如果是True，就要根据Stop thread on EOF参数值来确定线程是否停止运行。在明白组合逻辑关系后，可以更高效的设置参数、更准确的达到测试目的。
各种测试工具有各种测试功能，可能其中就会存在有关联的参数配置，这也需要我们特别关注。
如果查阅资料还不能清晰认识，就按老师的做法，通过对不同组合进行实验，最终弄清楚组合关系，归纳总结出优先顺序，从而在平时测试中帮助我们快速有效地找到最优的组合。
读者：
第一个问题：为什么参数化数据要符合生产环境的数据分布？
在「01丨性能综述：性能测试的概念到底是什么」中已经讲过，性能模型中的业务模型是真实场景的抽象，即需要的数据通常都是从生产环境中的数据中统计来的，其关键就是「数据必须保证仿真」。
那么性能测试的时候我们需要特别注意压测流量以及相关的数据，必须保证它们的多样化和代表性，否则会导致测试结果会严重失真。比如，当使用相同的测试数据进行重复测试时，如果压测请求不够大，那么各种缓存可能会严重影响测试结果。
第二个问题：为什么参数化数据要关注组合逻辑关系，而不是随意设置组合？
因为参数化数据要组合逻辑关系会直接影响参数化数据的分布情况，即数据是否均匀？数据是否稳定？是保否证测试时间足够长？满足测试的负载请求足够多和数据足够多样化，从而最大限度地减少或者掩盖缓存等其他因素的影响。
读者：
1、为什么参数化数据要符合生产环境的数据分布？
因为压测本身就是服务于生产环境，为使项目满足真实用户的需要，所以做压测的宗旨都是以实际业务逻辑出发满足用户需要，所以参数化也依赖业务逻辑，故在参数化之前，需要分析真实业务逻辑中如何使用数据，再在工具中选择相对应的组合参数的方式去实现。
2、为什么参数化数据要关注组合逻辑关系，而不是随意设置组合？
因为不关注组合的逻辑关系而随意设置组合，有些组合会存在没有意义且不符合逻辑关系的情况。影响参数化设置的有效性，也侧面反映压测人员的技术专业性。
读者：
1、为什么参数化数据要符合生产环境的数据分布？
尽可能少的数据应用覆盖到尽可能多的测试场景中。
2、为什么参数化数据要关注组合逻辑关系，而不是随意设置组合？关注组合逻辑关系，可以理解为了解数据生成规则，换句话说也就是有效的数据是有哪些实际业务场景产生的。
无论是问题1还是问题2，都是以实际业务场景为基础进行展开测试与规划的
读者：
1、罗列出需要参数化的数据及相对应的关系；2、将参数化数据从数据库中取出或设计对应的生成规则；3、合理地将参数化数据保存在不同的文件中；4、在压力工具中设置相应的参数组合关系，以便实模拟真实场景
之前做行测不太去理解：Recycle on EOF? ：这里有三个选择，False、True 和 Edit。Stop thread on EOF?：这里有三个选择，False、True 和 Edit。含义和上面一致。Sharing mode : 这里有四个选择，All threads、Current thread group、Current thread、Edit。这几个用户，经过老师这样一步一步分析，收获很大，谢谢老师分享
第一个问题：为什么参数化数据要符合生产环境的数据分布？1、减少数据命中率；2、减少缓存命中率；3、符合性能压测价值,测试结果更真实；
第二个：为什么参数化数据要关注组合逻辑关系，而不是随意设置组合？1、业务规则决定参数文件不能随便组合；2、如果随意组合参数，会影响事务成功率；
思考题：
思考题
你能说一下为什么压力机不模拟前端吗？
读者：
目前的压力工具大部分是针对服务端，即模拟「网络 API 请求」，而前端程序基本上是由一系列的「用户交互事件」所驱动，其业务状态是一颗 DOM 树。
通常来讲，前端性能关注的是浏览器端的页面渲染时间、资源加载顺序、请求数量、前端缓存使用情况、资源压缩等内容，希望借此找到页面加载过程中比较耗时的操作和资源，然后进行有针对性的优化，最终达到优化终端用户在浏览器端使用体验的目的。
目前获取和衡量一个页面的性能，主要可以通过以下几个方面：Performance Timing API、Prpfile 工具、页面埋点计时、资源加载时序图分析；
- Performance Timing API 是一个支持 Internet Explorer 9 以上版本及 WebKit；
内核浏览器中用于记录页面加载和解析过程中关键时间点的机制，它可以详细记录每个页面资源从开始加载到解析完成这一过程中具体操作发生的时间点，这样根据开始和结束时间戳就可以计算出这个过程所花的时间了；
- Profile 是 Chrome 和 Firefox 等标准浏览器提供的一种用于测试页面脚本运行时系统内存和 CPU 资源占用情况的 API；
- 通过脚本埋点计时的方式来统计没部分代码的运行时间；
- 借助浏览器或其他工具的资源加载时序图来帮助分析页面资源加载过程中的性能问题。这种方法可以粗粒度地宏观分析浏览器的所有资源文件请求耗时和文件加载顺序情况。
读者：
1、听完这样一节才知道http协议在交互过程中，数据经过了 Frame、Ethernet、IP、TCP、HTTP 这些层面，还会再每一次传输都会增加自己的信息头，而且还了解了应答模式；
2、之前一直没有思考【客户端接收到所有的内容之后，还要展示。而这个展示的动作，也就是前端的动作。在当前主流的性能测试工具中，都是不模拟前端时间的，比如说 JMeter。我们在运行结束后只能看到结果，但是不会有响应的信息。你也可以选择保存响应信息，但这会导致压力机工作负载高，压力基本上也上不去。也正是因为不存这些内容，才让一台机器模拟成千上百的客户端有了可能】 听完这一次后，明白了很多细节；
3、明白Nginx【压缩级别【1-9】值越大，压缩率就越高】之前只知道有压缩，但不知道再什么地方压测，今天看了老师写 Ngix 配置才明白再这里配置；
4、明白各个浏览器厂商在处理并发限制不一样，之前一直不知道，今天增加自己知识积累。
5、之前不知道https也是影响性能的，听完了这一篇增加了知识；
6、感谢老师总结【性能分析中，主要关心的部分就是传输字节的大小、超时的设置以及压缩等内容。在编写脚本的时候，要注意 HTTP 头部，至于 Body 的内容，只要能让业务跑起来即可。】
为什么压力机不模拟前端
1、客户端接收到所有的内容之后会在前端浏览器渲染，如果在本地渲染会增加压力机性能消耗，当消耗过大会影响压力发压能力，如果下载资源保存到本地，会增加IO操作压力机性能。
2、前端js/css/img等静态资源都走CDN.
读者：
你能说一下为什么压力机不模拟前端吗：因为模拟前端消耗的计算资源太大，相比之下意义可能并不大。
计算消耗大，是说去Parse这个前端的HTML，需要一些计算量；如果需要把这些内容给render出来，需要更多的内存。
一个HTML页面，Load之后会load更多的一些API，这些API可以通过估算，进行混合测试；而那些固态资源，通常会被 浏览器Cache / 网络中的一些路由器给cache，且是从一个静态资源的server单独serve，不用太担心。
需要测的是产生的压力，前端产生无意义。
读者：
性能测试的目的是获得系统性能指标，利用断言判断业务是否成功即可，并不关注前端页面显示内容，所以无需保存响应信息。
测试工具时，必须多了解参数，知其然并要知其所依然，才能更高效地更自如地配置参数，准确地满足测试要求。
读者：
你能说一下为什么压力机不模拟前端吗？
在当前主流的性能测试工具中，都是不模拟前端时间的，比如说 JMeter。我们在运行结束后只能看到结果，但是不会有响应的信息。你也可以选择保存响应信息，但这会导致压力机工作负载高，压力基本上也上不去。也正是因为不存这些内容，才让一台机器模拟成千上百的客户端有了可能。
另外前端页面展示还有部分是静态的图片或文字等，这些可以列在性能测试范围内也可以列在性能测试范围外。
思考题：
思考题
如果你吸收了这篇文章的内容，不妨思考一下下面这两道题：
参数化数据的分析重点是哪些？
在不同的场景中为什么参数化数据有如此大的差异？参数化数据的来源和获取要符合哪些规则？
当不符合获取规则时，会产生什么问题？
读者：
小结一下，在性能测试中，我们关注的参数化数据主要有以下几个方面：
1）参数化数据应该用多少数据量？
我们需要保证测试时间足够长、满足测试的负载请求需求，根据「目标tps x 持续时间（秒级）」可以计算出参数化数大概的量级。
2）参数化数据从哪里来？
大概分为两大类型：
- 死水数据，即out-of-box（事先创建测试数据），数据存在后台的数据库中；
- 活水数据，即On-the-fly（实时创建），数据库不存在这些数据，构造参数化数据需要符合业务特点。
构造测试数据通常有以下两种方法：
- 通过 API 调用生成测试数据；
- 通过数据库操作生成测试数据。
3）参数多与少的选择对系统压力有什么影响？
满足测试的负载请求足够多和数据足够多样化，从而最大限度地减少或者掩盖缓存等其他因素的影响。参数取得过多，对系统的压力就会大；参数取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。
4）参数化数据在数据库中的直方图是否均衡？
参数化数据需要符合真实业务数据分布情况，这样更符合业务真实场景。
读者：
参数化数据应该用多少数据量？
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、影响压测判断；
读者：
1.参数化数据的分析重点是哪些？在不同的场景中为什么参数化数据有如此大的差异？
分析重点是获知数据量。一是通过业务模型分析计算，获得初步的数据量要求；二是根据限制条件和业务场景，确定数据类型；三是结合上述两点，最终确定参数化数据的数据量。
不同场景中，数据使用对业务的完成是不一样的，比如某一场景中数据可以反复出现，不影响业务，自然能实现预期的场景；而另一场景中，反复出现的数据却不能多次实现同一业务，这种情况下，当时无法实现预期的场景。
2.参数化数据的来源和获取要符合哪些规则？当不符合获取规则时，会产生什么问题？
参数化时需要确保数据来源以保证数据的有效性，千万不能随便造数据。这类数据应该满足两个条件：要满足生产环境中数据的分布；要满足性能场景中数据量的要求。
产生的问题：
1.不合理的数据分布，会干扰测试结果，增加后续分析和测试的工作量；
2.数据取得过多，对系统的压力就会大；数据取得过少，不符合真实场景中的数据量，则无法测试出系统真实的压力。
读者：
老师，首先，参数化数据要用到多少取决于场景，举例来说，对一个压力工具线程数为 100，TPS 有 1000 的系统，如果要运行 30 分钟，则应该取得的参数化数据是下面这样的。
我想咨询下，系统的TPS=1000，这个数值最初是怎么得来的？
读者：
思考题
- 参数化数据的分析重点是哪些：看具体的业务逻辑，决定数据的具体分布情况
- 在不同的场景中为什么参数化数据有如此大的差异：因为业务逻辑不通，使得数据分布对应的不同
- 参数化数据的来源和获取要符合哪些规则：要满足生产环境中数据的分布；要满足性能场景中数据量的要求。
当不符合获取规则时，会产生什么问题：性能测试出来的结果，不能代表真实场景
读者：
请问在性能测试过程中对验证码如何处理？开发屏蔽调还是写成固定值？
读者：
怎么去测量一个接口的tps是多少？比如登录接口 我要知道这个接口的tps是多少才知道要使用多少参数化数据吗？老师
