系部网站开发计划书,网站建设策划解决方案,wordpress情感主题,合肥政务新区建设局网站嘿#xff0c;宝子们#xff01;今天咱们就来聊聊 JMeter 里超级厉害的 While 控制器#xff0c;它就像是一把神奇的钥匙#xff0c;能帮我们打开循环测试的大门#xff0c;模拟出各种各样复杂又有趣的场景哦#xff01;
一、While 控制器初印象
想象一下#xff0c;你…嘿宝子们今天咱们就来聊聊 JMeter 里超级厉害的 While 控制器它就像是一把神奇的钥匙能帮我们打开循环测试的大门模拟出各种各样复杂又有趣的场景哦
一、While 控制器初印象
想象一下你在玩一个冒险游戏只要你的角色还有 “生命值”这就好比是 While 控制器里的特定条件你就可以继续挑战下一个关卡也就是循环执行操作。While 控制器在 JMeter 中就是这么一个厉害的角色它允许我们在满足特定条件的情况下不停地循环执行它下面的那些 “小跟班” 元件。比如说我们要测试一个网络应用它有时候连接不太稳定需要不断尝试连接直到成功这时候 While 控制器就能派上大用场啦又或者你想模拟用户不停地查询某个结果直到找到自己满意的为止它也能轻松搞定。
二、把 While 控制器 “请” 进 JMeter
首先打开 JMeter 这个大舞台创建一个全新的测试计划这就像是为我们的测试表演搭建了一个场地。接着在测试计划里添加一个线程组。你可以把线程组想象成一群活力四射的小助手它们会按照我们设定的规则去干活。怎么添加呢很简单右键点击测试计划然后选择 “添加”再找到 “线程组” 就可以啦。最重要的一步来咯在线程组下面再次右键点击选择 “添加”然后找到 “逻辑控制器”里面就有我们心心念念的 While 控制器啦这样While 控制器就成功加入我们的测试计划大家庭准备好发挥它的循环魔法了。
三、调教 While 控制器
一条件表达式 —— 核心魔法咒语 在 While 控制器的配置界面中有一个 “Condition”条件输入框这可是它的 “魔法咒语” 输入区哦我们要在这里输入一个条件表达式这个表达式就像一个聪明的小卫士会判断是让循环继续还是停止。它必须能得出真或假的结果这样 While 控制器才能知道该怎么做。 条件与 JMeter 变量、函数的奇妙结合 变量循环的小助手 假设我们有一个叫count的变量它就像是一个记录循环次数的小秘书。我们一般会在线程组下通过 “用户定义的变量” 元件给它一个初始值比如设为 “0”。然后在循环过程中在 While 控制器的子节点里找一个像 “BeanShell PostProcessor” 这样的元件来帮count变量 “升级”每次循环结束后让它加 1也就是count。这样当条件表达式写成${count} 10时While 控制器就会看着count变量的值来决定要不要继续循环。如果count还没到 10那就继续一旦count达到或超过 10循环就停止啦。函数强大的魔法工具 __groovy函数神奇的脚本魔法 JMeter 里的__groovy函数就像是一个拥有神奇魔法的小精灵能让我们在条件表达式里嵌入 Groovy 脚本代码。比如说${__groovy(vars.get(response_code) 200)}这个表达式就是在检查名为response_code的变量是不是等于 “200”。当我们编写 Groovy 脚本时可得小心语法这个小怪兽哦要是想判断一个字符串变量是不是包含特定的子字符串就可以这样写${__groovy(vars.get(response_body).contains(success))}这里的response_body就像是一个装着响应体内容的魔法盒子。要是遇到复杂的 Groovy 表达式我们还可以偷偷加个println语句来帮忙调试。比如${__groovy(println(vars.get(response_body)); vars.get(response_body).contains(success))}这样在查看 JMeter 的日志启动 JMeter 时加上-j参数指定日志文件路径就能找到它时就能看到response_body这个魔法盒子里到底装了什么方便我们找出问题所在。而且哦要是变量的类型不对也会出乱子。比如说num_variable本来是个字符串类型的数字要在条件表达式里和数字比较大小就得先用Integer.parseInt方法把它变成真正的数字像这样${__groovy(Integer.parseInt(vars.get(num_variable)) 5)}不然就会得到意想不到的结果哦。其他内置函数各显神通 除了__groovy函数JMeter 还有好多其他的内置函数可以用在条件表达式里。比如__javaScript函数就像一个会 JavaScript 魔法的小巫师能让我们用 JavaScript 代码来判断条件像${__javaScript(${VAR}! STOP)}这样通过 JavaScript 函数结合变量来决定循环与否。用这些内置函数的时候一定要遵守它们的语法规则还要注意函数参数可不能传错哦不然魔法就不灵啦 避开常见的魔法陷阱 在写条件表达式的时候运算符就像一个个小陷阱要特别小心。像比较运算符、等和逻辑运算符、||不但要用对还要注意它们的运算顺序。要是不确定就用括号把要先算的部分括起来像${(count 10) (${__groovy(vars.get(response_code) 200)})}这样让运算顺序明明白白。还有哦千万不要把赋值操作当成比较操作写进条件表达式里这可是个很容易犯的错误一旦犯了条件表达式的结果就会乱套While 控制器也会跟着 “晕头转向”不知道该怎么循环了。 语法错误检查 —— 揪出捣蛋鬼 语法错误示例调皮的小错误 假设我们不小心把条件表达式写成了${count 10少了一个右括号这就像是在魔法咒语里写错了一个关键字符While 控制器可就看不懂啦调试和解决方法找到魔法修复术 首先我们可以去看看 JMeter 的日志文件要是启动 JMeter 的时候配置好了日志输出里面可能会有关于这个语法错误的提示信息就像一个小侦探留下的线索。然后呢我们还可以请出 “调试采样器” 这个小助手。在 While 控制器的子节点里加上 “Debug Sampler”在它的 “JMeter Variables to Log” 字段里输入条件表达式里用到的变量名比如count。运行测试后在 “查看结果树” 里看看 “Debug Sampler” 的结果。通过观察变量的值和可能出现的错误信息就能像个聪明的侦探一样找到语法错误藏在哪里啦。比如说如果发现count变量的值没有像我们想的那样显示那就可能是条件表达式在处理这个变量的时候出了问题也许就能发现少了括号之类的语法错误了。
二条件表达式的优化 —— 让魔法更高效
在一些复杂的魔法场景下要是每次循环都重新计算一些结果可能会让我们的测试变慢就像马车拉着太重的东西跑不动一样。所以我们可以想办法优化一下 缓存变量结果把宝藏存起来 比如说条件表达式里要用到一个很复杂的函数来获取系统当前时间戳然后和一个固定值比较。如果每次循环都去调用这个函数拿时间戳那就太浪费魔法力量了。这时候我们可以在循环开始前用 “BeanShell PreProcessor” 这个小工具把时间戳拿到手存到一个变量里就像这样
long timestamp System.currentTimeMillis();
vars.put(startTimestamp, String.valueOf(timestamp));然后在条件表达式里就用这个存好的变量像${__groovy(Long.parseLong(vars.get(startTimestamp)) someValue)}这样就不用每次都重新计算时间戳啦是不是很聪明呢
预计算变量提前准备好魔法材料 有些变量的值我们其实可以提前算好。比如条件表达式里要根据用户的等级和一些固定系数来计算一个权限值而且用户等级在整个测试过程中都不会变。那我们就可以在线程组下的 “用户定义的变量” 元件里把这个权限值先算出来。假设用户等级是userLevel固定系数是factor权限值的计算公式是permission userLevel * factor那就在 “用户定义的变量” 里加上这样的代码
int userLevel 5; // 假设用户等级为 5
int factor 2;
int permission userLevel * factor;
vars.put(calculatedPermission, String.valueOf(permission));然后在条件表达式里就用这个提前算好的变量${calculatedPermission} someValue这样就能让我们的测试跑得更快啦
三其他常用配置选项 —— 给 While 控制器加点装饰
名称和注释给它贴上个性标签 在 While 控制器的配置界面上有 “名称Name” 和 “注释Comment” 两个小格子。我们可以给 While 控制器取一个有趣又能说明它用途的名字比如如果它是用来控制用户登录失败后重新尝试登录的循环操作那就可以叫 “Login Retry Loop Controller”这样一看就知道它是干什么的。注释字段就像是一个小笔记本我们可以在里面详细写下 While 控制器的功能和配置逻辑。比如说“这个 While 控制器可厉害啦当用户登录失败的时候它会根据返回的错误码来决定要不要重新登录一直尝试直到登录成功或者达到最大尝试次数哦。条件表达式是${loginFailed} ${retryCount} 5”这样以后再来看这个测试计划就能很快明白它的作用了。 执行顺序相关选项如果有的话排好队伍有序执行 有些版本的 JMeter 或者一些扩展可能会有和执行顺序有关的配置选项。这就像是在一场表演中要安排好演员的出场顺序一样。比如说我们可以设置 While 控制器在某个特定前置控制器完成它的操作后再开始循环这样就能保证循环里的条件判断所需要的数据是准确无误的。要是有这样的选项我们一定要合理设置让整个测试流程像一场精彩的演出一样有条不紊地进行下去。
四、给 While 控制器找 “小伙伴”添加子节点
在 While 控制器下面我们可以添加各种各样的元件这些就是它的 “小伙伴” 啦它们会在循环中一起完成任务。这些小伙伴可以是 HTTP 请求、Sampler、其他逻辑控制器等等。比如说我们右键点击 While 控制器选择 “添加”再找到 “Sampler”然后选择 “HTTP 请求”这样就给 While 控制器添加了一个 HTTP 请求作为小伙伴。接着我们就可以像打扮一个小玩偶一样配置 HTTP 请求的 URL、方法、参数等信息让它去模拟在循环中要不断执行的特定操作。想象一下我们在测试一个搜索引擎就可以在 While 控制器下添加一个 HTTP 请求让它不停地发送搜索关键词的请求然后根据搜索结果页面的一些特点比如是不是找到了相关结果或者结果数量够不够来决定要不要继续循环搜索。是不是很有趣呢
五、设置变量值 —— 给循环加点 “变数”
变量作用域分清魔法的边界 全局变量大家都能用的魔法棒 全局变量就像是一根大家都可以用的魔法棒在线程组下定义后整个测试计划里的元件都可以访问和修改它除非有特殊的限制。比如说前面提到的count变量如果我们希望它在整个测试过程中都能被各个元件使用和操作就可以在线程组下通过 “用户定义的变量” 元件来定义它。这样无论是哪个逻辑控制器还是 Sampler都可以对count变量进行操作让它的值发生变化从而影响循环的过程。局部变量只属于自己的小魔法 局部变量就像是一个小魔法师自己的秘密武器通常在特定的元件内部定义比如 “BeanShell Sampler” 或者 “JSR223 Sampler”它的作用域就只在这个元件里面。比如说我们在一个 “BeanShell Sampler” 里定义了一个局部变量local_count并且在里面做了一些操作那这个变量在 “BeanShell Sampler” 外面是看不到的就像一个小秘密一样。当我们在条件表达式里使用变量的时候要根据实际情况来选择是用全局变量还是局部变量。如果一个变量只是在某个特定的操作中使用比如在一个特定的 Sampler 里做一些临时的计算那把它定义为局部变量就可以避免和其他变量混淆让测试计划更加清晰整洁。但如果这个变量需要在多个元件之间传递和使用比如记录整个测试过程中的循环次数那就得把它定义为全局变量这样大家才能都找到它并且使用它。变量操作与管理让变量乖乖听话 对于那些在循环过程中需要不断变化的变量比如count变量我们得找对方法来操作它。如果一开始是通过 “用户定义的变量” 元件定义了count那在循环过程中比如在 While 控制器的子节点中的 “BeanShell PostProcessor” 里我们就可以用count这样的操作来让它的值增加。而对于一些从响应数据中提取出来的值比如从网页响应中提取用户的权限级别然后存到user_permission变量里我们可以用 “正则表达式提取器” 这个小工具来实现。总之我们要根据变量的特点和在测试中的用途选择合适的方法来操作和管理它们这样才能让它们在循环中发挥出最大的作用。 在循环过程中我们还可以用其他方法来改变变量的值从而影响循环的条件 用 “正则表达式提取器” 提取宝藏 比如说我们在测试一个网页应用的时候从登录后的页面响应中提取用户的权限级别然后把它存到一个叫user_permission的变量里。这样在 While 控制器的条件表达式中我们就可以用这个变量来判断用户是不是有特定的操作权限比如${user_permission} admin如果是那就可以决定是否继续循环执行某些管理操作相关的请求。这就像是从一个装满宝藏的箱子里找出我们需要的那颗宝石然后用它来开启下一个关卡的大门。用 “BeanShell PostProcessor” 施展编程魔法 再比如在一个循环中每次发送一个 HTTP 请求后我们可以用 “BeanShell PostProcessor” 这个小魔法师来检查响应状态码。如果是 “401 Unauthorized”那就说明可能出现了权限问题我们就可以把一个用来记录错误次数的变量error_count加 1然后根据error_count的值来决定是不是还要继续循环尝试登录比如${error_count} 5。这样我们就可以通过编程的方式来灵活地控制循环的条件让测试更加智能和高效。
六、让测试跑起来运行测试
一切准备就绪我们就可以点击 JMeter 界面上那个绿色的三角形按钮也就是 “启动” 按钮让我们的测试计划像一辆发动的汽车一样跑起来。这时候While 控制器就会根据我们设置的条件表达式结果来决定是不是要让它的小伙伴们子节点循环执行任务。在测试运行的过程中我们可以通过 JMeter 的各种 “小眼睛”监听器来观察测试的执行情况。比如说 “查看结果树” 就像是一个神奇的望远镜能让我们看到每个请求的详细信息包括 While 控制器的子节点在每次循环中的请求和响应数据。还有 “聚合报告” 就像是一个智能的分析师能告诉我们整个测试过程中 While 控制器及其子节点的性能指标比如平均响应时间、吞吐量、错误率等等。通过这些监听器我们就可以清楚地知道测试是不是按照我们的预期在进行如果条件满足子节点就会欢快地循环执行如果条件不满足循环就会停止测试就会继续执行后面的其他元件或者操作就像一场精彩的演出每个环节都有条不紊地进行着。
七、查看结果 —— 验收我们的 “魔法成果”
调试与日志输出找出隐藏的小秘密 JMeter 自带的调试工具神奇的放大镜 JMeter 给我们准备了 “Debug Sampler” 和 “View Results Tree” 这两个厉害的调试工具就像是两个神奇的放大镜。我们在 While 控制器的子节点里加上 “Debug Sampler”然后在它的 “JMeter Variables to Log” 字段里输入我们想要查看的变量名比如count、response_code等。运行测试后在 “查看结果树” 里查看 “Debug Sampler” 的结果就能像用放大镜看东西一样清晰地看到这些变量在每次循环中的值是怎么变化的。这对于我们排查问题可太有用了如果发现变量的值没有按照我们预想的那样变化那就说明可能在某个地方出现了问题我们就可以顺着这个线索去找到问题的根源然后把它解决掉。日志输出与级别选择控制魔法日志的信息量 当我们用__log函数输出调试信息的时候就像是在写一本魔法日记要注意选择合适的日志级别。JMeter 提供了不同的日志级别比如 DEBUG、INFO、WARN、ERROR 等。我们可以在 JMeter 的配置文件jmeter.properties里设置日志级别或者在启动 JMeter 的时候通过-L参数来指定。比如说如果我们只想输出调试信息那就可以把日志级别设置为 DEBUG然后在__log函数里用合适的日志级别参数像${__log(DEBUG, 当前循环次数 count)}这样。这样就能避免输出太多不必要的信息同时又能保证我们能拿到关键的调试信息就像从魔法日记里找到我们最需要的那几页重要内容一样。 同时我们还可以用 “聚合报告” 这个智能的分析师来查看整个测试过程中 While 控制器及其子节点的性能指标比如平均响应时间、吞吐量、错误率等等。通过这些数据我们可以评估我们的测试是不是达到了预期的效果有没有出现性能瓶颈或者其他问题。 性能评估的具体示例与数据解读解读魔法数据的奥秘 性能瓶颈识别案例解开性能之谜 假设我们在测试一个需要不断查询数据库的应用程序用 While 控制器来模拟多次查询操作。通过 “聚合报告” 监听器我们发现随着循环次数的增加平均响应时间越来越长吞吐量越来越低而且错误率也开始上升。这就像是我们的魔法马车在行驶过程中越来越慢还老是出故障这可能就意味着数据库查询操作在高并发循环查询的情况下出现了性能瓶颈。 分析与解决修复性能问题的魔法咒语 首先我们要查看数据库的执行计划看看查询语句是不是可以优化。比如说是不是存在全表扫描这种比较低效的情况或者是不是可以添加合适的索引来提高查询速度。然后我们还要检查服务器的资源使用情况比如 CPU、内存、磁盘 I/O 等。如果 CPU 使用率太高可能就表示数据库服务器的处理能力已经快到极限了这时候我们可能就需要考虑升级硬件或者优化数据库的配置参数比如调整缓存大小、优化数据库连接池的设置等等。同时我们也要检查 JMeter 测试计划中的数据库连接配置看看连接池大小是不是合适。如果连接池太小就可能会导致大量的查询请求在等待连接这样就会增加响应时间和错误率。我们可以尝试调整连接池参数增加连接数然后再观察性能是不是有所改善。就像给我们的魔法马车换一匹更强壮的马或者给它的轮子加点润滑油让它能跑得更快更稳。
八、调试 While 控制器以确保循环逻辑的正确性
使用调试采样器点亮魔法追踪灯 在 While 控制器的子节点中添加 “Debug Sampler” 就像是在黑暗的魔法森林里点亮了一盏追踪灯。比如说如果条件表达式是${count} 10 ${__groovy(vars.get(response_code) 200)}那我们就在 “Debug Sampler” 的 “JMeter Variables to Log” 字段里输入 “count” 和 “response_code”。运行测试后在 “查看结果树” 中查看 “Debug Sampler” 的结果就能清楚地看到这些变量在每次循环中的实际值。这样我们就可以检查变量值是不是按照我们预期的那样变化以及条件表达式是不是能正确地判断循环的继续或停止。如果发现变量值不对或者条件表达式的结果不符合预期那就说明我们的循环逻辑可能存在问题需要进一步排查。 查看日志输出翻阅魔法记录簿 就像前面说的通过在__log函数中选择合适的日志级别输出关键变量的值这就像是在翻阅一本详细的魔法记录簿。比如在条件表达式相关的元件如 “BeanShell PostProcessor”中添加${__log(DEBUG, 当前count值 count)}并且在启动 JMeter 时设置好日志级别为 DEBUG。这样在查看 JMeter 日志时我们就能追踪变量的变化情况确保循环逻辑的正确性。如果发现变量值没有按照预期更新那就可能意味着循环逻辑存在问题比如说变量更新的代码没有正确执行或者条件表达式中的变量引用有误。这时候我们就需要仔细检查相关的代码和表达式找出问题所在并修复它。 逐步分析循环过程拆解魔法步骤 第一轮循环踏上魔法旅程的第一步 在循环开始前我们要像出发前检查行李一样确认所有涉及条件表达式的变量初始值是不是正确。比如说如果有变量count和response_code我们就要检查它们是不是已经通过 “用户定义的变量” 或其他合适的元件进行了正确的初始化。如果count应该初始为 0那就确保它确实是 0如果response_code应该有一个初始的预期值也要检查它是否正确设置。当进入第一轮循环时我们要像一个细心的探险家一样观察 While 控制器是不是按照预期执行了子节点。这时候我们可以结合 “查看结果树” 中的信息查看子节点的请求和响应情况。同时查看调试采样器或日志输出中变量的值验证条件表达式的第一次求值是不是正确。比如说若条件表达式为${count} 10 ${__groovy(vars.get(response_code) 200)}我们就要检查count是不是为初始值如 0response_code的值是不是符合预期以及整个条件表达式是不是得出了正确的布尔值来决定是否执行第一轮循环。如果条件表达式应该为真但实际上没有执行子节点或者条件表达式为假但却执行了子节点那就说明我们的循环逻辑在第一轮就出现了问题需要赶紧查找原因。 中间轮次循环魔法旅程的持续探索 随着循环的进行我们要像一个专注的魔法师关注魔法元素的变化一样重点关注变量值的变化情况。如果在循环中存在对变量进行操作的元件如 “BeanShell PostProcessor” 对count进行自增操作我们就要确保这些操作正确执行。在每一轮循环结束后再次检查条件表达式中的变量值和表达式的求值结果。比如说经过几轮循环后count的值应该按照操作逻辑依次递增如果它没有递增或者递增的数值不对那就说明变量更新的操作可能有问题。同样response_code的值如果会变化也应该符合实际业务逻辑同时条件表达式应该根据这些变量值的变化正确地决定是否继续下一轮循环。如果发现条件表达式在某一轮循环中得出的结果不符合预期那就要仔细检查这一轮循环中变量的变化以及条件表达式的编写是否正确。 最后一轮循环循环结束完成魔法旅程的关键一步 当循环接近结束时无论是因为条件不满足而正常结束还是出现了可能的异常情况导致循环提前或异常结束我们都要像一个严谨的魔法师结束一场重大仪式一样仔细检查最后一轮循环中的变量值和条件表达式的求值结果。如果循环是因为达到最大循环次数或其他限制条件而结束我们要确认这些限制条件是不是按照预期生效。比如说如果条件表达式为${count} 10当count达到 9 并进入最后一轮循环后我们要确认这一轮循环执行完后count的值变为 10导致条件表达式为假从而使 While 控制器停止循环这一过程应该与我们预期的循环逻辑完全相符。同时我们还要检查最后一轮循环的子节点执行结果是不是符合业务逻辑避免出现因循环结束相关操作导致的错误。如果最后一轮循环的子节点执行出现了异常情况或者执行结果不符合预期那就要检查是不是在循环结束的处理过程中出现了问题比如资源释放不当或者数据保存不正确等。
九、While 控制器在不同类型的性能测试场景中的具体应用
一网络连接测试
场景描述跨越网络的魔法桥梁 在测试网络应用程序的连接稳定性时我们就像是要在一条不太稳定的魔法桥梁上反复行走直到安全到达对岸或者尝试了足够多次。常常需要模拟客户端不断尝试连接服务器直到连接成功或者达到最大尝试次数。这就像是一个勇敢的骑士不断冲击城堡的大门直到门打开或者他筋疲力尽。 While 控制器的应用开启连接魔法之门 条件表达式可以设置为基于连接状态的变量。比如说假设存在一个名为isConnected的变量它的初始值为false就像城堡的大门一开始是紧闭的。在每次尝试连接操作通过在 While 控制器下添加的子节点如 TCP Sampler 进行连接尝试后我们要通过合适的后置处理器如 “BeanShell PostProcessor”来更新isConnected变量的值。如果连接成功就把它设置为true如果连接失败就保持false。条件表达式可以写成${!isConnected} ${retryCount} 10这就像是骑士在心里默念的咒语只要城堡的大门还没打开!isConnected并且我还没有尝试太多次retryCount 10我就继续冲击大门循环尝试连接。这样While 控制器就能根据这个条件表达式控制连接尝试的循环过程直到成功连接或者达到最大尝试次数。
二数据查询测试
场景描述寻找数据宝藏的魔法探险 对于数据库或其他数据存储系统的数据查询操作我们就像是在一个神秘的魔法宝库里寻找特定的宝藏可能需要不断地翻找各个角落直到找到我们想要的东西。比如说在测试一个数据仓库的查询接口时我们要不断查询直到获取到最新更新的数据这就像是在宝库里寻找一件刚刚被放进去的珍贵魔法物品。 While 控制器的应用指引数据查询的魔法罗盘 我们可以基于查询结果的相关变量来设置条件表达式。假设通过查询操作会返回一个包含数据时间戳的变量dataTimestamp我们期望获取到的数据时间戳大于某个特定值如lastKnownTimestamp这就像是我们知道要找的魔法物品上有一个特定的标记时间戳只有找到比我们已知标记更新的物品才行。那么条件表达式可以写成${__groovy(vars.get(dataTimestamp) vars.get(lastKnownTimestamp))}这样 While 控制器就会像一个精准的魔法罗盘控制查询操作不断循环执行直到获取到的dataTimestamp大于lastKnownTimestamp也就是我们找到了那个带有更新标记的魔法物品最新数据。
三业务流程测试
场景描述电商购物的魔法流程 在模拟复杂的业务流程时比如在电商系统的下单流程中我们就像是在一个充满魔法规则的购物世界里穿梭。如果支付失败这就像是在魔法商店里付款时遇到了魔法屏障我们需要按照一定规则重新尝试支付就像寻找破解屏障的魔法咒语一样。 While 控制器的应用修复支付魔法的循环咒语 我们根据支付结果相关的变量来设置条件表达式。假设存在一个变量isPaymentSuccess它的初始值为false就像一开始魔法屏障还在那里。在每次支付操作通过在 While 控制器下添加的 HTTP 请求等子节点模拟支付后我们通过相应的后置处理器如根据支付接口返回结果更新isPaymentSuccess变量来更新变量值。如果支付成功就把isPaymentSuccess设置为true如果支付失败就保持false。条件表达式可以写成${!isPaymentSuccess} ${retryPaymentCount} 3这就像是我们在心里不断重复的咒语只要支付还没成功!isPaymentSuccess并且我重新支付的次数还不到 3 次retryPaymentCount 3我就继续尝试支付循环执行支付操作。这样While 控制器就能控制支付操作的循环直到支付成功或者达到最大尝试次数就像我们最终成功破解魔法屏障完成购物一样。
