关联原理说明

关联的问题

客户端和服务器之间的通讯,有一部分是数据是动态的,每次通讯都不一样。 Proxy 录制器在录制的时候是无法区分哪些是静态的信息,哪些是动态的信息,所有的信息都以 hard-coded 的方式记录下来。但是在回放的时候,如果有些信息不改变,那么脚本是不能执行成功的。考虑如下情形:

如上图所示,用户 jojo 以 jojo/bean 的账号 / 口令登录某一 web 服务器,查询某产品的信息,由 Vugen 录制交易的全部通讯包。 web 服务器返回给 jojo 一个动态的会话 ID: [email protected] ,作为这次登录的会话标识。由于 Vugen 无法知道哪些信息是动态的,它会照单全收的方式,把所有的数据就记录下来。接着 jojo 根据 Web 服务器告诉他的 SessionID 去查询产品列表,交易可以正常执行下去。

我们会观察到,当 Vugen 根据捕获的通讯包生成 http 脚本的时候, SessionID 是 Hard-coded 的,即 “ 写死 ” 在程序里面的。当我们不加修改的回放该脚本的时候,会出现什么问题呢?如下图所示:

按照录制时候的脚本, jojo 以 jojo/bean 登录后, Web 服务器返回给 jojo 一个动态会话 ID: [email protected] ,这个值已经不是录制时候产生的 [email protected] 了,而是新的值: [email protected] 。那么脚本根据记录的 SessionID 的值,仍然会使用 [email protected] 去执行下面的查询交易。由于会话 ID 是有时效性的,用户退出系统后,其 SessionID 会失效,那么,服务器会给出一个 “SessionID 失效 ” 的错误,从而导致脚本无法正常执行下去。

对于上面的问题的通用解决方法如下图所示:

在第一次从服务器得到 SessionID 的时候把其放在一个变量 <session_id> 里面,在后面脚本访问服务器的语句里面,把所有的 ”[email protected]” 替换为变量 <session_id> 就可以圆满解决这个问题。

这种问题在任何系统都是非常常见对外问题。其通用的模式是: “服务器返回给客户端一些动态变化的值,客户端使用这些值去访问服务器的时候,不能把这些值写死在脚本里面,而应该存放在一个变量里面。” 这就是关联的概念。

关联的工作往往占据开发脚本的大部分时间,因为我们必需针对每一个具体的系统进行细致的分析,确定其需要关联的动态信息。

时间: 2024-10-26 22:13:36

关联原理说明的相关文章

left join 多表关联原理

这个是我再别人那里拿的数据,还有他的问题 现在有 A,B,C,D四张表,A为主表,B.C.D都是子表,与A属于一对多关系.查询后出现大量重复数据 表A ----------------------------------------------- cID Name 1 张三 2 李四 表B ----------------------------------------------- cID Car 1 本田飞度 1 POLO 表C -------------------------------

《Entity Framework 6 Recipes》中文翻译系列 (37) ------ 第六章 继承与建模高级应用之独立关联与外键关联

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 6-13  在基类中应用条件 问题 你想从一个已存在的模型中的实体派生一个新的实体,允许基类被实例化. 解决方案 假设你有如图6-20所示的模型. 图6-20 包含Invoice实体的模型 这个模型只包含一个单独的实体Invoice(发货单).我们想从Invoice派生一个新的实体,它表示删除掉的发货单.这将允许我们以更清晰的业务逻辑来分别对有效的发货单和已删除掉的发货进行不同的操作.按下面

性能测试-JMeter关联之正则表达式介绍

为什么要关联??? 在客户端与服务器通信过程中,多个请求/响应间的数据会有相互依赖的关系.比如上一个请求返回的某些响应数据在后续的请求中需要用到. 下面是一些典型的例子: 1)比如第一次访问网站获取的session id在后续的请求都会将其传给网站; 2)服务器生成token返回给用户,在后续的请求中要带上token; 3)根据条件查询某记录,在查询结果集中选择记录进行操作(比如删除) ... 但是有些通信协议是无状态的,不存在上下文相关性.多个请求/响应之间的数据不能直接进行传递; 并且每次服

读《影响力》总结

一直没有想到,原来生活中得心理学可以这么奇妙,日常生活中比我们厉害的人或多或少地利用了心理学的知识,而<影响力>这本书全面地总结了这方面的内容,生活中一些奇怪的现象几乎总是可以从这本书中找到理论依据. 该书从互惠.承诺与一致.社会认同.喜好.权威.稀缺六个方面描述生活中心理学的方方面面,下面简单地总结概括一下这本书的精华部分. 互惠 互惠的心理基础是<负债感和知恩图报>,它让你产生一种必须得做一些什么来报答帮助你的人的感觉,否则你心理上会觉得自己像个卑鄙无耻与社会格格不入的小人.比

loadrunner提高篇-插入检查点与关联函数

插入检查点   靠LR自动生成的脚本是不够的,很难达到业务要求,因此需要对录制完的脚本进行完善,使其能达到业务模拟的要求 ,这样尽可能地使虚拟用户模拟时更接近用户的实际使用. 在进行压力测试时,经常会有页面间数据传递的操作.如果在测试过程中传递数据的次数逐渐增多,页面就有可能发生传递混乱,或者客户端与服务器端数据传输被中断.传输过程中产生了错误的数据等情况.为了判断数据传递的正确性,LR提供了插入检查点的方法.之前在入门篇的博客中有提到插入检查点的原因,这里就不再细说了,大概提一下,是因为当事务

《Entity Framework 6 Recipes》翻译系列 (5) -----第二章 实体数据建模基础之有载荷和无载荷的多对多关系建模 (转)

2-3 无载荷(with NO Payload)的多对多关系建模 问题 在数据库中,存在通过一张链接表来关联两张表的情况.链接表仅包含连接两张表形成多对多关系的外键,你需要把这两张多对多关系的表导入到实体框架模型中. 解决方案 我们设想,你数据库中的表与图2-10一样. 图2-10 艺术家和专辑多对多关系 按下面的步骤将这些表和关系导入到模型中: 1.右键你的项目,选择Add(增加) ?New Item(新建项),然后选择Visual C#条目下的Data模板下的ADO.NET Entity D

hive笔记(自学整理的)

第一部分:用户管理 创建用户:CREATE DATABASE XXX 查看用户:SHOW DATABASES; 关键查看用户:show databases like 'de.*' 讲解:创建一个用户就等于在物理目录下创建了一个文件,该文件是以.db结尾的, 默认的路径是:/user/hive/warehouse/zqx.db 创建用户时可以指定路径: create database XXX location '/my/preferred/directory' 讲解:为后期维护方便,可以创建用户时

loadrunner提高篇-结果分析实践

分析图合并 一.分析图合并原理 选择view->merge graphs,弹出如图1所示对话框 图1(设置合并图) 1.选择要合并的图.选择一个要与当前活动图合并的图,注意这里只能选择X轴度量单位相同的图. 2.选择合并类型. 1)叠加:查看共用同一X轴的两个图的内容.合并图左侧的Y轴显示当前图的Y轴值,右边的Y轴显示合并进来的图的Y轴值,如图2所示 图2(叠加合并分析图) 2)平铺:在平铺布局查看,共用同一个X轴,合并进来的图显示在当前图的上方,如图3所示 图3(平铺合并分析图) 3)关联:合

SSM-mybatis-spring容器 复杂和简化方法

回顾 ------------- 1.JVM runtime data area. a.method area 方法区,永久区,metaspace , 共享 b.heap 堆区,共享 heap = young代 + old代理 young = 伊甸区 + 幸存区 幸存区 = 幸存一区(from) + 幸存二区(to),内存碎片整理 所有对象诞生于伊甸区. heap //堆 non-heap //非堆 , metaspace off-heap //离堆 , os - jvm //ByteBuffe