很多人关心LR在C/S架构上如何实施性能测试，我想根本原因在于两个方面，一是很多时候脚本无法录制，即LR无法成功调用被测的应用程序，二是测试脚本即使录制下来，可读性不强，往往不能运行通过，调试时无从下手，像音视频、电子地图类的测试差不多也是这个问题。
根据我以往的项目经验，LR是可以做到的，因为它提供了Windows Sockets协议，解决方案实施起来简单但需要足够的细心以及一定的判断力、想象力，可参考如下步骤进行：
1、通过抓包工具捕捉客户端与服务器之间的所有通讯。
关键点：IP过滤，端口过滤，报文类型过滤
目的：弄清楚业务操作过程中，客户端向服务器提交的请求原型，以及服务器对我们请求所做的正确响应
2、将过滤后的报文整理成测试脚本。
关键点：Socket的建立与关闭，send buf的整理，receive buf的整理
目的：将抓包获得的报文转成LR测试脚本(提示：选取合适的抓包工具，使得报文能被保存成文档格式;开发小工具，通过报文中的各个关键字抽取报文中 Data Area中的部分作为buf 区的内容，根据IP字段，端口号等特征完成lrs_send,lrs_receive语句的填写。这部分看上去挺难，但只要对报文做好分析，把握规律，编程的事随便拉个开发都可以轻松搞定)
3、调试脚本
关键点：定位错误，添加校验点
目的：使脚本真正可以拿来进行压力测试
这是最难的一个环节，耐心、细心、判断力都体现在此处。每个人处理问题的方式的不同，我只能提供自己的一点经验。
将脚本RUN-TIME SETTINGS中的扩展日志全部打上钩，并且将脚本拿到controller中单用户执行，注意设置好日志路径。
脚本出错后，用EDIT PLUS或其他的文本工具打开log,找到出错行，然后向上逐一对比服务器返回的数据与录制过程中抓包获得的报文。
在这里，我用了一个小技巧，生成buf内容时，使buf的编号与该buf在抓包获得的报文中编号保持一致，比较起来很方便。
如果服务器返回的buf与抓包时的原始数据一致，自然表示该步骤回放成功，如果不一样，则需要具体情况具体对待。就我的经验来说，往往是因为数据唯一性问题或者是关联的问题造成某一步骤返回的BUF为0或-1，从而导致最终脚本失败。
找到第一个出错的地方后，参数化，关联等手段都可以用上了，这里可能需要重复两次抓包过程，先行比较自己发送的报文是否有区别。
以上内容为大家介绍了C/S架构的性能测试，本文由多测师亲自撰写，希望对大家有所帮助。
标签：脚本,架构,报文,LR,测试,buf,软件测试 From： https://www.cnblogs.com/lfc666/p/16986716.html