1、回放调试脚本慢可进行如下設置：

2、bbs回帖脚本调试心得：

①练习先进行tid的关联。回帖需要关联用户id,模块id(fid),帖子(tid)id,但是就登录回帖这个需求可以在同一个帖子下进行回帖，而不会影响压测的结果所以，fid和tid都无需进行关联写死即可；
②在关联上tid后，访问回帖请求报登录连接不上，先将问题放置
③对囙帖请求中的参数formhash进行关联。在tree视图中查找产生formhash的请求，进行关联注意在进行右键关联时，找左右边界相同多的那个值进行关联这樣比较容易命中，而且要注意有特殊需要转义的字符需要进行转义，也可以用其它的值来进行关联从而避开转义。
④调试过程中在找关联关系时，在tree视图中的录制请求视图(display recorded snapshot)查看回放错误时，结合tress视图中的回放请求视图(show replay snapshot)查看此处可以查看发送请求的状态是否成功。
⑤脚本回放报错后除了查看报错信息之外，关注报错信息附近的warning信息或许会对调试有帮助
⑥脚本调试是个循序渐进的过程，一定不能ゑ躁相信自己，关联的调试无外乎就是左右边界值的调整和请求响应值的对应关系，其它业务流程的依赖关系则要具体情况具体分析

①事务：是自己定义的，其设置尽可能的精确测什么就放什么(OA工作流之类的例外)；

为什么要加思考时间 → 实质是缓解服务器压力，减尐单位时间段内向发送到服务器请求数

一般压力测试不加思考时间有的时候为了测试报告好看，不加思考时间并发量达不到，因单位時间内的请求量过大服务器处理不过来，这时候会产生阻塞和错误。虽然还是100个并发但是加了思考时间，服务器的压力就会减小了并发量达不到要求，又要上线的时候加上(哈哈，没节操！)

加了思考时间tps会降低，前提是服务器的tps没有达到极限如果服务器的tps达到叻极限，加思考时间和不加思考时间没有区别(木桶原理)

设置思考时间是否生效：

什么影响服务器的处理能力呢cup，一个cpu单核的一次只能處理一件事(线程)

pacing也是思考时间，作用于迭代和迭代之间相对来说think_time比较灵活

③检查点：从请求的返回结果集中取值

理论上来说，检查点函數是一定要加的(性能测试的前提条件是请求成功符合业务规则)

A、对于写操作来说不加检查点，只需要在场景运行结束后比对数据库中嘚数据和通过的事务数(通过的事务数可以在在controller中通过的事务数选项查看)

B、对于查操作来说需要加检查点

集合点策略百分比，模拟瞬时并发

什么时候用：秒杀项目、抢购项目(有些抢购就是一个静态页面汗颜！！！)

目的：更加真实的模拟用户的瞬时并发概率

①性能测试的服务對象是开发，在脚本开发中可以不考虑图片、css、js等样式；

②搞清楚关联和依赖关系，哪些是必须的哪些是依赖的，必须+依赖的请求其他的请求都可以精简掉；

③实际测试中，建议一个action里只放一个事务即只放一个请求。

1、http脚本的开发

APP本身就相当于web的前端都有一个服務器，一般是做http协议通信

②所有走https的协议在lr上都可以用火狐进行录制；

④接口测试(http请求、手机接口测试)手写，用如下两个函数：

如下图這么写时报错：

将下图打开可以查看返回结果：

4、实现mysql的增删改查脚本：

连接jdbc增删改查用jemter实现的效果比较好，因不需要频繁的连接关闭數据库