• LoadRunner 参数化多用户“唯一”取值规则测试


    转载:https://www.sohu.com/a/138141159_680421

    在 LoadRunner 里面 参数化取值依赖两个基本维度:

    1 取值顺序 要分成 [顺序][随机]和[唯一]

    2 更新时刻 要分成 [每次迭代][每次出现]和[仅一次]

    还有一个附加维度:

    3 当参数不够用时的补救策略 分成[从头再来][凑合使用最后一个][放弃部分用户]

    按照基本维度排列组合一下 会产生九种组合 而无法一眼看穿的 则只有[唯一]这个选项

    所以我就单独说一下[唯一]这个取值规则

    part1 测试脚本

    测试中使用的脚本如下:

    Action()

    {

    inti =0;

    for(i=0;i<3;i++){

    lr_eval_string("{paramtemp}");

    }

    lr_eval_string("{paramtemp}");

    return0;

    }

    以上代码 运行一次叫做一个迭代 每个用户每个迭代中 参数 paramtemp 会出现 4 次

    本次测试设置 3 次迭代 所以每个用户的参数 paramtemp 就会出现 12 次

    下面我把该脚本的实际运行结果展示出来

    part2 单用户运行

    2.1 唯一 + 每次迭代(4 次出现 3 次迭代)

    这个组合在单用户的情况下 并看不出效果

    2.2 唯一 + 每次出现(4 次出现 3 次迭代)

    这个组合在单用户的情况下 也看不出效果

    2.3 唯一 + 仅一次(4 次出现 3 次迭代)

    这个组合在单用户的情况下 也看不出效果

    part3 多用户运行

    在多用户的情况下来解释“唯一”

    “唯一”的意思是 针对每一个参数而言 它只能属于唯一的用户

    比方说 如果某个参数给 user1 使用了 那么它就不可以被 user2 取用

    而实现这个规则的途径 就是参数分段

    本次测试设置 5 个用户 每个用户的参数 paramtemp 会出现 12 次

    每个用户都独立存活在自己的世界里 它们并不知道其它人在干什么

    下面我把该脚本的实际运行结果展示出来

    3.1 唯一 + 每次迭代(5 个用户 4 次出现 3 次迭代)

    脚本迭代 3 次 更新发生在每次启动一个新迭代的时候 所以每个用户需要 3 个参数

    将第 1 - 第 3 个参数分给 user1 使用

    将第 4 - 第 6 个参数分给 user2 使用 后面的以此类推

    所以参数按 3 来分段 就可以保证实现“唯一”规则了

    那么就有人要问了 如果 5 个用户 每个用户分段分到了 20 个参数 (取用 3 个 闲置 17 个)

    一共需要 100 个参数 参数表里面只准备了 60 个参数 不够用 怎么办?

    我选择了在参数不够用的情况下 放弃部分用户

    也就是说 参数表里面的 60 个参数 按 20 分段 只能支持 3 个用户 需要放弃 2 个用户

    运行结果如下:

    3.2 唯一 + 每次出现(5 个用户 4 次出现 3 次迭代)

    脚本迭代 3 次 每次迭代中参数出现 4 次

    更新发生在每次参数出现的时候 所以每个用户要用到 12 个参数

    所以参数按 12 来分段 5 个用户 总共准备 60 个参数

    就可以保证实现“唯一”规则了

    那么又有人要问了 每个用户需要 12 个参数才够用

    如果按照 8 来分段 那就不够用了 不够用怎么办呢?

    我选择了在参数不够用的情况下 取用最后一个参数

    也就是说 每个用户只能取到 8 个值 剩下 4 个就“凑合”使用最后那个值

    运行结果如下:

    3.3 唯一 + 仅一次(5 个用户 4 次出现 3 次迭代)

    在这种组合下 与分段相关的选项是置灰的:

    这个组合的意思是:

    每个值只能给一个用户取用 用户取好值之后打死也不再更新了

    这样子运行起来 要么是参数的数量比用户的数量多 正常取值就行了

    要么是参数的数量比用户的数量少 参数不够用的话 直接报错就行了

    因此 无论参数够不够用 都不需要给参数分段

    part4 关于自动分段

    在讨论[唯一]这个规则的时候 你会发现一个问题:

    这是为什么呢?我想了半天。。。

    后来我发现 之所以想晕了 是因为问题的描述有问题。。。

    这个问题应该这么来想:

    这样就能分析了:

    如果是[唯一 每次迭代] 迭代次数是设置好的 所以自动分段可以按照迭代次数来实施

    比方说 脚本迭代 5 次 那么自动分段就默认按照 5 来分就可以了

    如果参数够用 则不会闲置 如果参数不够用 允许你选择不够用时的补救策略

    当然你也可以手动分段 假如按照 8 来分段的话 无非就是每段里面闲置 3 个参数而已

    假如按照 3 来分段的话 后面 2 次迭代没有合适的参数 你也要选择不够用时的补救策略

    如果是[唯一 每次出现] 脚本里面参数出现了多少次 是 LoadRunner 无法获知的

    比方说上面那段测试脚本 你循环变量高兴写几就写几 你没有办法通知到 LoadRunner

    LoadRunner 不知道参数会出现多少次 所以它也就不知道参数应该如何分段才够用

    这样子你就必须手动分段

    PS:图文并茂的原创文章写得很累,所以最接推一些学生的原创文章。

  • 相关阅读:
    如何用nodejs创建一个proxy 服务
    企业包分发-应用内安装时碰到的问题
    React-Native与Weex的比较
    前端炫酷动画展示利器(lottie)
    记录一个web开发工具集网页
    git 和 远程分支关联
    reference to 'X' is ambiguous 解决
    mac 下解压 .bin文件
    fabric 集成trello
    ES6 对象的创建及操作
  • 原文地址:https://www.cnblogs.com/qiaoli0726/p/10535898.html
Copyright © 2020-2023  润新知