LoadRunner测试 系统体会总结（一）

广州劳社局OA系统多次被进行性能调优，在此期间参与过几次压力测试，从遇到问题到解决问题，不断的探索和学习，期间对LR和OA系统有了更多认识和了解。记得，在第一次用LR测试OA系统时就从张洁菁的一篇发表中得到很多启发和帮助，在此我也将自己LR测试OA系统的体会和经验总结出来和大家分享。

这次详细阐述的是如何实现用LR模拟不同组织机构用户在桌面的待办公文列表打开不同类型公文场景。

之前在对劳社局OA系统打开公文场景进行压力测试时，都必须先制造业务数据：将一份来文办阅公文发送给办理情况环节的全部用户，然后让开发人员用sql语句查找出收到办理情况环节这份文的所有用户帐号、用户组织机构id，以及对应的workid、workitemID。然后开始录制脚本：登陆系统，我的桌面显示完毕->打开刚才那份来文办阅公文，表单加载完毕，脚本录制完成。参数化用户帐号、用户组织机构id、参数化脚本的workid、workitemID。脚本成功实现了打开公文。

但是，脚本这样设置，压力测试实现的是：不同的用户打开同一环节的同一份公文。而现实中，用户使用系统时不太可能出现这种情况，用户在日常处理公文时，可能都在打开各种不同公文，尽可能的模拟用户现场使用系统的场景，压力测试才能更加接近用户实际情况。

那么如何实现不同的用户各自打开不同的公文呢？

首先，得先了解OA系统，从登陆系统到在我的桌面打开一份公文完成，客户端和服务器都进行了哪些通讯信息。1、 录制脚本：登陆系统，我的桌面显示完毕->打开一份发文公文，公文表单加载完成，完成录制。2、开启LR的所有扩展日志，回放脚本。3、按ctrcl+F8，只看到一个值workid需要关联，设置workid关联时，回放脚本后并未能实现打开公文。

查看replay log日志中发现，客户端请求加载桌面的待办公文列表时，对每一条公文服务器responsed返回了很多信息。现实中用户点击我的桌面的公文标题就能准确的打开所要的公文，而不是点击标题1的公文会打开标题2的公文。那么在加载公文列表时，服务器肯定responsed了当前用户的每份公文唯一标识信息，这些标识信息会使得每份公文的链接地址都是唯一的。获得公文的链接地址，就意味着能打开公文表单。那么如何找到打开公文时，每份文的唯一标志信息呢？之前张洁菁已经在文章提到新增公文场景时的workid、formInstanceID、appInstanceID、workitemID。大家都应知道这几个id都会存在每一份公文里面，但是这几个id关联后，无论放在脚本中哪个位置，都无法实现在桌面打开不同的公文。LR的ctrcl+F8也无法找到需要关联的值，录制两份一样操作的脚本对比也不行。

刚才已提到打开公文的链接地址，没错，需要从链接地址下手。打开一份发文公文，右击，点击属性，把该份公文的url地址拷贝下来。同理，打开一份来文办阅公文，找到该份文url地址。对比两份公文的url地址，发现有六个值不同：appUniqueCode、formID、workid、formInstanceID、appInstanceID、workitemID。除此外两份公文链接地址的其他信息是一样的。查看replay log日志，发现加载公文列表时，服务器会对每一份公文都会responsed回appUniqueCode、formID、workid、formInstanceID、appInstanceID、workitemID。经与开发人员沟通后，了解到这几个值在公文系统中作用。

appUniqueCode：应用标识码，区分流程应用。同一公文流程该标识码是一样的并是固定的，不同的公文流程，该标识码不一样，如劳社局OA系统的发文流程appUniqueCode=PTsend，来文办阅的appUniqueCode= lwreceive。

formID：表单标识码，是针对表单模板的，用来区分表单模版,不同公文表单，该值不一样，同一表单该值一样。

appInstanceID：应用实例标识，在公文流转时，用来区分同一个应用下的不同公文。

formInstanceID：表单实例标识，跑公文时，会针对具体公文产生对应的表单。不同公文该值不一样。

workitemID：工作流任务对象id，工作流运转过程中，会流转多个活动，每个活动下会有多个任务。workitemid就是区分同个活动下的不同任务。任一公文在每个用户那里该值都不一样。

workID：待办任务id，区分待办任务用的。同workitemID。

了解了这几个id的作用后，我们来设置关联函数，关联函数是一个注册函数，必须放在加载内容的前面，才能获取到值，在tree快照中找到公文列表界面，在公文列表界面的web_url点击右键选择inserbeforeàservice下的关联函数即可插入关联，或者在replay log日志中搜寻这几个id，如果这几个id出现在responsed body部分且后面跟着id值，双击日志里面的代码行，就对应到了脚本行位置，在这个脚本行前写入关联的代码函数就可以了。关联函数如下：

        web_reg_save_param("appUniqueCode1",

              "LB/IC=appUniqueCode%3D",

              "RB/IC=%26",

              "Search=Body",

              LAST);

       web_reg_save_param("appInstanceID2",

              "LB/IC=appInstanceID%3D",

              "RB/IC=%26",

              "Search=Body",

              LAST);

       web_reg_save_param("formInstanceID3",

              "LB/IC=formInstanceID%3D",

              "RB/IC=%26",

              "Search=Body",

              LAST);

       web_reg_save_param("workID4",

              "LB/IC=workID%3D ",

              "RB/IC=%26",

              "Search=Body",

              LAST);

       web_reg_save_param("workitemID5",

              "LB/IC=workitemID%3D",

              "RB/IC=%26",

              "Search=Body",

              LAST);

       web_reg_save_param("formID6",

              "LB/IC=formID%3D",

              "RB/IC=%26",

              "Search=Body",

              LAST);

在tree中看到插入的位置如图：

 

 

关联设置全部完成后，开启回放脚本的快照页面，设置脚本迭代次数为多次，回放脚本，这时在快照可看到不同的用户登陆系统后，成功实现各自打开自己的待办公文，这些待办公文可能各不相同。

在摸索关联这几个id时，发现一个现象：桌面公文列表加载前关联workid，公文表单页面加载前关联formInstanceID、appInstanceID、workitemID。回放脚本在日志中发现workid取的是当前用户的第一份公文的workid值，formInstanceID、appInstanceID、workitemID却依然是录制脚本时的值。快照看到可以实现打开公文，但是打开的公文表单页面为录制脚本时的公文表单，并非是当前用户第一份公文的表单页面。但是当前用户的第一份公文new标志消失了呀，业务上，我们看到新公文被打开后new标志才消失的，怎么回事呢，是快照有问题吗？跟开发人员沟通后，做了个实验：将一份发文公文的workid，放到另一份来文办阅公文的url链接中取代其中的workid,在ie浏览器中回车，发现打开的是来文办阅公文表单，表单的数据有点紊乱，而刚才那份发文的new标志确实消失了。与快照看到的一样，不是LR快照的问题。原来表单的所有数据和内容放在表单下，只有appUniqueCode、formID、workid、formInstanceID、appInstanceID、workitemID这六个值正确了，才能正确无误的打开一份表单且获得正确的数据内容。看到用户第一份公文new消失，因为客户端和服务器确实进行了第一份公文的一些数据传输。

此次体会和总结到此，欢迎大家拍砖。感谢那些百忙中回答我问题的开发人员（其中陈超解答我问题时还叫我排队等候，呵呵），以及和我一起交流、学习的测试部同事。

下次会继续推出第二篇LR体会总结。