一、脚本调试
1、回放调试脚本慢，可进行如下设置：
2、bbs回帖脚本调试心得：
思路
①练习先进行tid的关联。回帖需要关联用户id,模块id(fid),帖子(tid)id,但是就登录回帖这个需求，可以在同一个帖子下进行回帖，而不会影响压测的结果，所以，fid和tid都无需进行关联，写死即可；
②在关联上tid后，访问回帖请求，报登录连接不上，先将问题放置。
③对回帖请求中的参数formhash进行关联。在tree视图中，查找产生formhash的请求，进行关联。注意在进行右键关联时，找左右边界相同多的那个值进行关联，这样比较容易命中，而且要注意有特殊需要转义的字符，需要进行转义，也可以用其它的值来进行关联，从而避开转义。
④调试过程中，在找关联关系时，在tree视图中的录制请求视图(display recorded snapshot)查看，回放错误时，结合tress视图中的回放请求视图(show replay snapshot)查看，此处可以查看发送请求的状态是否成功。
⑤脚本回放报错后，除了查看报错信息之外，关注报错信息附近的warning信息或许会对调试有帮助。
⑥脚本调试是个循序渐进的过程，一定不能急躁，相信自己，关联的调试，无外乎就是左右边界值的调整和请求响应值的对应关系，其它业务流程的依赖关系则要具体情况具体分析。
3、一些名词：
①事务：是自己定义的，其设置尽可能的精确，测什么就放什么(OA工作流之类的例外)；
②思考时间：
加在事务的外边
为什么要加思考时间 → 实质是缓解服务器压力，减少单位时间段内向发送到服务器请求数
一般压力测试不加思考时间，有的时候为了测试报告好看，不加思考时间，并发量达不到，因单位时间内的请求量过大，服务器处理不过来，这时候，会产生阻塞和错误。虽然还是100个并发，但是加了思考时间，服务器的压力就会减小了。并发量达不到要求，又要上线的时候，加上(哈哈，没节操！)
加了思考时间，tps会降低，前提是服务器的tps没有达到极限，如果服务器的tps达到了极限，加思考时间和不加思考时间没有区别(木桶原理)
设置思考时间是否生效：
什么影响服务器的处理能力呢？cup，一个cpu单核的，一次只能处理一件事(线程)
pacing也是思考时间，作用于迭代和迭代之间，相对来说think_time比较灵活
③检查点：从请求的返回结果集中取值
检查点是否一定要加：
理论上来说，检查点函数是一定要加的(性能测试的前提条件是请求成功，符合业务规则)
加检查点会影响性能：
A、对于写操作来说不加检查点，只需要在场景运行结束后，比对数据库中的数据和通过的事务数(通过的事务数可以在在controller中通过的事务数选项查看)
B、对于查操作来说需要加检查点
④集合点：
集合点策略百分比，模拟瞬时并发
什么时候用：秒杀项目、抢购项目(有些抢购就是一个静态页面，汗颜！！！)
目的：更加真实的模拟用户的瞬时并发概率
4、关于脚本精简
①性能测试的服务对象是开发，在脚本开发中，可以不考虑图片、css、js等样式；
②搞清楚关联和依赖关系，哪些是必须的，哪些是依赖的，必须+依赖的请求，其他的请求都可以精简掉；
③实际测试中，建议一个action里只放一个事务，即只放一个请求。
二、脚本开发
1、http脚本的开发
接口说明文档
①http接口测试一般用postman；
②所有走https的协议在lr上，都可以用火狐进行录制；
③api脚本回放报错时，如果报安全协议(SSL)错误，在请求前加上：
web_set_sockets_option("SSL_VERSION","TLS"); //走https协议
web_custom_request
web_submit_data
手写豆瓣api请求：
A、使用web_custom_request函数
B、使用web_submit_data函数
如下图这么写时，报错：
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
