性能测试脚本调试流程

主要有下面几点：

1.  录制或编写性能测试脚本

2.  修改测试脚本、使用随机化策略

3.  调试运行脚本，查看log和数据库内容等方式验证脚本正确性

我们可以通过录制的方式来写性能脚本，loadrunner的vuser generator支持录制，jmeter本身也支持录制不过用badboy录制脚本导入到jmeter中貌似配合起来比jmeter本身录制要更好用

录制完成的脚本我们需要进行编辑，录制过的测试朋友都知道，录制会有很多无用的请求，我们编辑脚本的时候可以将这些无用请求删除掉，让性能测试脚本更加简洁，当然有朋友说我不想录制，我想自己写，那也是可以的，通过fiddler抓包接口文档等等方式也是可以自己去编写的。

对于编写好的脚本，我们需要做优化，比如参数化关联、设置检查点或断言、事务，另外对于大型的系统很多都是分布式系统，采用了缓存技术来提高用户访问体验，那么对于分布式系统如果你使用了固定的请求策略，那么你请求的大量数据就会被缓存命中，那么对数据库就不会产生预期的压力，那么这个请求的数据就会违反了性能测试的一个原则：尽可能模拟所有发生的真实极端情况，比如双11活动来自五湖四海的人都通过网站或手机端发起订单请求，而且他们请求的数据都是不一样的，而且差距都是很大的，但是你做性能测试你模拟的数据是固定，总是向服务器发送相同的数据，那么你就违反了尽可能模拟所有发生的真实极端情况这个原则，这样性能测试结果就会有偏差，所以需要做随机化策略。

11

性能测试脚本的执行

主要有下面几点：

1.  设定好特定的性能测试场景

2.  初始的压力线程数

3.  逐步加压的策略

4.  测试执行结束条件

5.  结束时的停止多线程的方式

比如脚本为：登录系统、查看商品、购买商品

一般都是先做单点功能测试，即对登录功能、查看商品功能、购买商品功能分别进行性能测试，确保单个功能点压测没有性能问题，然后在去做场景混合的测试，即把这3个功能做一个不同线程数的组合，进行性能测试大场景的测试，这个场景最后报告出来之后如果各项指标都能满足指定要求，那么就可以认为此次性能测试达标了。

当你不知道加多少压力的时候，可以逐步加压，比如每3分钟加5个线程，不断往上加，看系统性能是什么表现，这样你就能知道在不同线程组合压力的情况下这个系统工作是ok还是不ok的，这样你就能找到性能拐点，找到系统支持的并发数。

测试执行结束条件，一般情况都是设置立即停止，但是如果有时就想看一下压力逐步减轻的时候这个系统是一个什么表现也可以进行逐步减少线程数结束

一般用到最多的测试脚本执行策略都是：

按照时间，使用递增的线程并发数来测试，比如每5分钟加5或10个线程，一直测试1小时，查看系统性能是如何波动的，这样就能基本找到产品的最大极限值即峰值、性能拐点

注意：加压的压力测试机器和被测试对象最好在一个局域网段

这个理由在第五点性能测试环境搭建的网络环境中已经进行了详细的理由说明，可以翻阅查看。

12

如何获取系统合理并发数？

比较简单的获取方法：

每隔5分钟增加一定的并发数，直到达到瓶颈数，即线程数增加了以后tps处理量不在增加了，这个线程数可以算成合理的并发数。

例如：每5分钟增加10个线程，发现系统每秒钟可以处理20个请求20个/s，5分钟在继续增加，发现系统30个/s，在加线程数，发现系统还是30个/s，说明这个线程数差不多就到了合理的并发数了。

13

性能测试数据收集

执行性能测试，会收集很多数据，比如：

1.  测试用例编号

2.  测试时间

3.  并发数

4.  成功请求数

5.  失败请求数

6.  平均每秒处理个数

7.  平均每个处理处理时间

8.  方差

9.  备注

10.  响应时间小于1s、1s到2s、2s到3s、3s到4s、4s到5s、5s以上的的请求个数

测试用例编号：这组性能测试用例跑的是什么，比如登录性能用例，通过编号一目了然知道对应性能脚本的内容

测试时间是反映测试多长时间

方差数据是用来验证系统的波动性，是否在一个均值上下，还是波动很大，方差反映了系统稳定性

响应时间不同时间内请求个数的收集可以得到一个平均值，通过平均响应时间可以知道系统处理请求的响应时间是否满足要求。

另外这个响应时间，可以参考网上这个图：

从用户的角度来看，响应时间=C1+C2+N1+N2+N3+N4+A1+A2+A3

但是从系统的角度来看，响应时间=N1+N2+N3+N4+A1+A2+A3

C1：用户请求发出在客户端需求完成的预处理所需要的时间

C2：客户端收到服务器返回的响应后，对数据进行处理并呈现所需要的时间

A1：Web Server对请求进行处理所需要的时间

A2：DB Server对请求进行处理所需要的时间

A3：Web Server对DB Server返回的结果进行处理所需要的时间

N1：请求由客户端发出并达到Web Server所需要的时间

N2：如果需要进行数据库相关测试，由Web Server将请求发送到DB Server所需要的时间

N3：DB Server完成处理并将结果返回给Web Server所需要的时间

N4：Web Server完成处理并将结果返回给客户端所需的时间

通过这个图以及字段含义的解释，我们就能理解到响应时间的组成，通过我们收集的响应时间数据，就能更好的分析和定位系统的性能瓶颈。

（未完待续）