JMeter进阶之理解元件执行顺序

lsekfe

在JMeter脚本设计中，搭配使用各类测试元设计接近实际场景的步骤是整个脚本设计环节的关键。各元件组合搭配，在完整的测试交互周期中，发挥了数据抽取转换、分支逻辑控制、响应解析判断等多种功能，将标准交互请求进行包裹、扩充、衔接、串联形成触达不同数据、激活不同逻辑的树形执行结构。　　因此了解JMeter各测试元件在执行线程生命周期内的执行顺序，对复杂场景脚本设计有重要帮助。

　　取样器（Sampler）。作为支持JMeter实现协议交互的核心元件，也是线程执行的主体部分，在实现请求交互的前后阶段为其他元件发挥增强功能提供基础。环绕在取样器元件之外，有“切入式”的增强元件，也有具备全局性质的功能元件。所以脚本设计都是以取样器元件为核心向外不断扩展。
　　逻辑控制器（Logic Controller）。逻辑控制器元件在取样器元件的上一层级部署，在线程组级别下创建，负责控制不同的Sampler逻辑触发，从而实现脚本的多逻辑执行预期。因此逻辑控制器是在其子节点Sampler执行之前就执行的，需要注意的是本元件控制范围仅针对其子节点之内的脚本逻辑。
　　前置处理器（Pre Processor）。前置处理器顾名思义是在协议交互之前进行处理的元件，简单理解在Sampler组件执行前设置了一个交互准备阶段，在此处可为Sampler执行提供一些增强操作，包括参数调整、数据修改等。
　　后置处理器（Post Processor）。类比前置处理器，只是方向相反，后置处理器元件是在Sampler交互完成后执行，简单理解为请求结束后的结果处理增强操作，可自定义实现响应修改、数据提取等功能。
　　断言（Assert）。断言元件是在Sampler交互完成和增强处理完成后运行，用于自定义判断交互是否成功，因此需要注意断言是在同一Sampler逻辑下后置处理之后启动。本元件核心功能是允许用户自定义规则解析测试结果，并实现自主化的请求结果判断。
　　定时器（Timer）。定时器元件主要是为Sampler元件提供执行前的自定义等待时间，常用于模拟真实业务场景的操作等待环节，本元件在Sampler启动前运行，由于确保等待时间紧密关联协议交互的正常启动时点，因此定时器会在前置处理元件后执行。
　　配置元件（Config Element）。配置元件提供了全局性的配置准备功能，提供变量初始化、参数自定义、数据准备等操作，常见的有header设置、包括csv参数化、自定义变量等功能元件，因此本元件在测试中最先执行，为上下文提供全局配置。
　　监听器（Listener）。监听器是和Sampler同级别的元件，主要负责收集响应结果或执行测试数据统计，是交互完成的最后环节。常见的结果树、聚合报告组件，都是用于查看测试结果所用，需要注意的是监听器的结果输入强关联断言组件，因此在执行顺序的最后一步。
　　需要注意的是，在使用各元件中Beanshell自定义逻辑时，要明确当前元件的执行位置，以免出现无效处理或数据为空的情况，影响脚本的场景设计逻辑。下面简单用图展示各元件的执行顺序。
　　以上就是简单对元件执行顺序的介绍，尽管通常测试场景的简单交互中不会应用到上文所有类别的元件，但面对复杂业务场景时明确元件执行顺序会很好的加速脚本设计效率和执行质量，而且能加深对JMeter 运行逻辑的理解。

ytdwhsdy

大佬，请问jmeter老是报no cookies怎么解决？会影响到什么方面？目前我看脚本运行也都正常，就是始终报no cookies，网上看了好几天也没找到解决办法