正是如此

因为有些场景，后续请求的地址不能事先获知，而是基于前序响应的，所以没法在编辑测试场景的时候，直接把后续请求的地址填好

比如之前说过的，典型的5G SBA里面的事件订阅/更新/取消订阅的过程，以及鉴权过程，都是consumer发起请求，producer处理请求之后，返回给consumer的响应里面携带了某个header，其中包含一个新的地址，下一步的交互基于这个地址。

所以，基于这个出发点，工具内置了对基于某个特定header的跟踪规则。

当然，实际测试面对不同的系统，有不同的需求，目前能想到的是：

1. 后续请求地址已知，这是很直接的情况，直接在编辑JSON测试场景的时候填就行

2. 后续地址未知，但是跟上一条请求一致，比如订阅之后，更新订阅，删除订阅，则删除动作和更新动作是一致的。这个情况，工具也能够处理，根据设定的规则，自动把前序的请求地址复制到后续请求

3. 后续地址未知，来源规则知道。比如来源于特定的header，这个工具已经内置支持，header名字也是可以配置的。
但是还有别的来源规则，比如来自响应消息的HTML或者XML消息体内的某个XPath，或者来源于响应JSON消息的某个Json pointer
甚至更复杂的逻辑，需要根据响应消息，结合特定模板，而推导出后续请求

为了应对这些更加广泛复杂的场景，h2loadrunner内置了lua脚本的支持。
对于测试场景中的每一个请求，都可以配置一个lua脚本。同一个测试场景中的请求会被顺序执行，每一个请求的lua脚本都会有四个输入：前序应答的所有header列表，前序应答的消息体，本次请求配置的所有header列表，本次请求配置的消息体。
所以lua脚本就可以根据前序响应，和本次请求的配置（模板），动态更新本次请求，无非是header列表和消息体，然后把更新后的header列表和消息体返回，h2loadrunner会把更新后的请求发出。



【 在 lambdai 的大作中提到: 】
: 感谢回复！
: 感觉这是个根据规则或者响应去生成后续load？ 感觉应该挺有用的
: 确实有时候多变的场景，不值得用原始代码去写规则引擎
--
修改:wallyz FROM 113.120.108.*
FROM 113.120.108.*