脚本单次回放正常，改成多次迭代后却跳回登录页，这种问题经常与脚本分段、会话设置有关。登录放在初始化段，意味着它不会跟着每轮业务重复；登录放在动作段，又会改变认证请求的数量。安排脚本前，需要明确模拟的是同一用户连续操作，还是每轮重新登录。以下以VuGen中的Web HTTP/HTML协议C脚本为例，说明分段方式及检查方法。

　　一、LoadRunner脚本初始化和迭代有什么区别

　　初始化属于虚拟用户开始执行时的准备阶段，迭代则是运行段按配置重复执行。两者的执行次数不同，不能把增加迭代次数理解成整个脚本从头再来。

　　1、从执行顺序区分三个脚本段

　　①在VuGen中打开目标脚本，分别查看【vuser_init】、【Action】和【vuser_end】中的请求。

　　②将只需执行一次的准备操作放入【vuser_init】，将需要重复的业务操作放入【Action】。

　　③在【vuser_end】中安排退出登录、释放资源等收尾操作，保存脚本。

　　在正常完整执行中，每个虚拟用户初始化一次，随后重复运行段，结束时执行收尾段。例如设置三次迭代，业务动作执行三轮，初始化不会因此执行三次。多个虚拟用户各有自己的初始化过程，并非整个场景共用一次。

　　2、通过运行逻辑确认重复范围

　　运行段可以包含多个动作，也可以按动作块组织。判断某个请求执行几次，要结合运行逻辑，不能只看它所在文件的名称。

　　①按【F4】打开【运行时设置】，进入【常规】→【运行逻辑】。

　　②将【迭代次数】设为【3】，检查运行段内各个【动作】和【动作块】的排列顺序。

　　③核对动作块是否另设重复次数，确认设置并保存。

　　④回放脚本，在【回放日志】中对照初始化、迭代开始和动作执行记录。

　　迭代次数与并发用户数也有区别。一个用户连续执行三轮，不能等同于三个用户同时操作。若动作块内部还有循环，其请求次数可能超过外层迭代次数。

　　二、LoadRunner登录操作应该放在哪个脚本段

　　登录位置应跟着用户使用方式安排。持续使用同一会话，可以在初始化时登录；每轮需要完整登录流程，则应把登录纳入运行段。

　　1、一次登录后连续操作

　　①在【vuser_init】中保留登录前置请求、动态值提取及登录提交。

　　②在【Action】中保留查询、浏览或提交等业务请求，将退出操作放入【vuser_end】。

　　③打开【运行时设置】→【浏览器模拟】，取消勾选【每次迭代模拟新用户】，确认设置。

　　④连续回放多轮，在【回放日志】中检查后续业务是否仍使用有效登录身份。

　　这种安排适合用户登录后连续处理业务的场景。它依赖会话在测试期间持续有效，不能保证服务端会话一直不过期。脚本中主动清理Cookie、退出登录或覆盖认证参数，也可能破坏后续迭代的登录状态。

　　2、每轮都重新登录

　　登录接口本身需要承受持续负载，或者每轮业务代表一次独立访问时，登录应进入重复执行的流程。

　　①在【Action】中按顺序安排登录前置请求、登录提交、业务操作和退出请求。

　　②检查【vuser_init】，移除与每轮登录重复的认证请求，保留必要的一次性准备。

　　③在【运行时设置】→【浏览器模拟】中，按独立会话需求启用【每次迭代模拟新用户】。

　　④回放三轮，在【回放日志】中核对每轮登录提交及业务校验结果。

　　3、长时间运行中处理会话续期

　　①在脚本中定位使用认证信息的【业务请求】，核对其依赖的Cookie或令牌参数。

　　②将系统要求重复执行的续期流程放入【Action】对应位置，更新后续请求使用的【认证参数】。

　　③在【回放日志】中检查续期响应和后续业务结果，确认失效时的处理分支。

　　令牌更新与重新登录不一定是同一个接口。业务系统提供续期机制时，应按实际流程实现，不能一遇到请求失败就再次登录，否则会掩盖业务错误，还会增加原计划之外的认证流量。

　　三、LoadRunner登录分段后怎样验证脚本

　　分段调整完成后，需要验证身份是否延续、动态数据是否正确，以及事务统计是否符合测试目标。仅凭请求没有报错，还不足以确认登录成功。

　　1、检查多轮回放中的认证信息

　　①在登录相关响应中定位需要提取的动态值，将【web_reg_save_param_ex】等关联注册函数放在返回该值的请求之前。

　　②在后续【登录请求】或【业务请求】中使用对应参数，移除录制时留下的固定动态值。

　　③连续回放多轮，对照【回放日志】中的响应内容，检查是否出现登录页、会话失效或权限不足提示。

　　④在业务请求前使用【web_reg_find】注册成功标识检查，并在后续代码中处理检查结果。

　　HTTP状态正常，也可能返回登录页面或业务失败信息。校验内容应选择能代表本次操作成功的稳定标识，避免只匹配页面上一直存在的通用文字。调试日志也应避免输出密码和完整令牌。

　　2、让事务边界对应测试目标

　　初始化登录与迭代登录会产生不同数量的登录请求。报告中的登录事务和业务事务，需要分别解释，不能用业务循环次数推算登录吞吐量。

　　①在登录流程前后分别加入【lr_start_transaction】和【lr_end_transaction】，使用相同的登录事务名称。

　　②为需要统计的【业务请求】单独设置事务边界，检查开始与结束函数是否成对。

　　③依据业务校验结果设置【LR_PASS】或【LR_FAIL】，避免只用请求是否发送成功判断事务结果。

　　④短时运行场景，对照【事务统计】与【回放日志】，核对登录次数、业务次数及失败原因。

　　例如十个虚拟用户各登录一次、各执行二十轮业务，正常完整执行时会有十次登录和二百轮业务。初始化阶段提前完成登录，还会影响认证流量出现的时间。若测试目标包含登录高峰，应同时检查场景初始化和启动安排。异常停止时，收尾操作也不能作为服务端资源清理的全部保障。

　　总结

　　LoadRunner脚本分段体现的是用户会话与业务重复之间的关系。登录一次后持续操作，与每轮重新认证，都会形成不同的请求组合和服务端负载。明确测试目标，再让会话设置、动态关联和事务统计与之对应，结果才便于解释。希望这些方法能帮助大家处理多轮回放中的登录问题，也欢迎交流具体场景中的脚本安排。