十二月的时候，项目做db migration，被老大叫去做页面验证。并且比对目标页面和原始页面的数据是否一致。
但是目标页面的请求大部分失败了，导致页面根本无法显示数据。
我想其实页面显示不会有很大的变动，问题其实不大，主要的问题是接口不通。
于是抓取了待测页面的请求，大概300个左右，创建了接口测试。
开始的时候我按照模块创建了线程组，其实就三个页面，等于是执行的时候用三个线程来挨个执行每个线程组里的请求。没有做参数化。执行的时候发现接口脚本耗时特别长，因为有些请求需要20分钟，这个一方面是接口有性能问题，另一方面我得脚本也需要改进，毕竟一个请求不需要等足20分钟才判定它失败，只要在期望的时间里没有返回数据，就可以判定为失败。
于是改了一下，对每个请求的advance 里设置了连接time out 的时间和response time out 的时间。这个时间和开发确认的。
再次执行脚本，运行的时间变短了。
因为一个一个去改脚本，非常慢不说，而且可能会漏改一些请求，所以为了保证脚本都在期望的时间了没反回就判定失败，又加上了sample time out 的时间。
现在对于脚本我又产生了三个想法。
第一，不能直观的在报告里体现访问的地址
第二，还想提高运行效率。
第三，脚本修改太麻烦了，需要改进。
于是我做了一些调整，首先其实所有的请求只有path 不一样，这完全可以用同一个请求传递不同的参数就行了。
于是加入了csv data config
把路径全部写在csv 文件里，sample name就直接用当前运行请求的路径。
改完以后，直接把线程组改成300，结果果然在很短的时间里运行完了。报告里也能直接体现运行的请求的路径了。但是仔细一看，一大片失败，为什么？
原来服务器端设置了同时连接的请求数目上限是15，所以我虽然一次起了300线程，但是都连接失败了，前面提到了我设置了连接timeout 的时间。
最后，折中了运行时间，讲同时运行的线程数分控制在10个。线程组上不设置线程数，而是在线程组里用loop controllers 来控制运行csv 文件数据行数，顺序执行。
网友评论