你真的会使用Jmeter吗（五）性能测试中的有效数据

       用Jmeter做性能测试时，我们是用不同的执行策略（多少线程循环多少次既模拟不同的场景）执行同意脚本，相当于我们控制了执行策略这唯一变量，那把这些脚本的测试结果放在一张表格中，我们就可以轻易的分析出其他数据和这一变量的关系。举几个栗子，举例的过程中我们来谈谈什么是有效数据。

先说明下各列参数的含义：
Scene：测试场景，如10* 1* 5min指 并发数为10，1秒内启动执行5min。
Sum：脚本执行的总量
TPS：系统吞吐量，若脚本中只有单个请求，脚本的吞吐量（Throughout per second）即为系统吞吐量（Transaction per second）
RET：这里是我自己给平均响应时间定义的名称
CPU：服务器CPU使用率
MEM：服务器内存使用率
ST：执行脚本时间，出现问题是，可以根据此时间查询各环节日志，排查问题。
ERROR%:错误率
REC：平均接收字节速度（Kb/s）
SNT：平均发送字节速度（Kb/s）

例1

       表一中 Scene为 10并发的三行数据，同一场景数据并不一致，样本数不一致，吞吐率不一致，而且CPU的使用率也不稳定，这是为什么呢？我们可以看到这三行最后两列数据（网络收发速度）差别特别大，这也恰恰呼应了，前面所提到的网络带宽影响测试数据。因为我们不能预测或者保证本地网络什么时间网络最稳定或者速度最快，所以如果想要测试到有效的数据，也可以说有参考价值的数据，在云服务其上还是很有必要的。
                                                                                            表一 本地测试机 问卷访问

Scene	Sum	TPS	RET	CPU	MEM	ST	Error%	REC	SNT
10* 1* 5min	12034	40.1	0.24	66%	52%	20:32	2.83%	3050	8
10* 1* 5min	4180	13.9	0.71	53%	50%	9:36	0.24%	1081	2.8
20* 1* 5min	6255	20.8	0.95	56%	51%	9:43	0.00%	1625	4.17
40* 1* 5min	6593	21.9	1.81	61%	52%	9:54	2.24%	1678	4.39
80* 1* 5min	6717	21.7	3.62	75%	51%	10:02	13.21%	1503	4.35
120* 1* 5min	8580	27.8	4.24	78%	52%	10:11	16.85%	1856	5.57
200* 1* 5min	9977	31.4	6.30	86%	53%	10:19	19.87%	2021	6.27
10* 1* 5min	11650	38.2	0.26	85%	52%	10:28	4.06%	2878	7.65

例2

       表二中 我们可以看到，不同场景下服务器CPU、MEM的使用率等基本差不多，唯一有差别的就是平均响应时间。在选取有效数据是，响应时间也是我们该关注的点。我们先了解下什么是2-5-8原则。

2-5-8原则：一次有效的测试结果，不只用户都运行成功，同时需要保证访问一个页面或一次交易的响应时间在合理范围。“2-5-8原则”，简单说，就是当用户访问一个页面或一次交易能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。
所以即使在访问未出错的情况下，平均相应时间超过一定值时，在往后面测就没有必要了。

       如表二中500并发时，平均响应时间将近5秒钟，因为是平均值，所以此时已经有很大一部分用户访问已经超过5秒了，所以之后的大于500并发数的脚本也不用多测了。
       表二中将问卷的访问和提交当成一个事务处理了。我们可以假设有一个活动是回答问卷送好礼，规定前多少位可以获得这个资格，如果访问的吞吐量是100而提交的吞吐是10，那提交的吞吐必然会限制访问，和木桶定理差不多。而且真实情况下，用户访问和提交也肯定是穿插着进行，所以将访问和提交作为一个事务更符合这个场景 。
                                                                      表三二云测试机（2核4G 网络8M） 问卷访问及提交

Scene	Sum	TPS	RET	CPU	MEM	ST	Error%
100*3min	14528	80.5	1.23	95%	60%	16:44	0.02%
200*3min	14355	79.4	2.45	95%	60%	16:48	0.00%
300*3min	15820	87.3	3.41	96%	61%	17:28	0.00%
400*3min	15440	85.0	4.66	95%	62%	17:38	0.00%
500*3min	15055	82.8	4.24	98%	61%	17:50	0.09%
600*3min	14802	74.1	7.33	98%	62%	18:13	0.03%
500*30min	149663	83.1	5.98	98%	62%	18:40	0.04%

例3

       在表三中 最后两行我们可能以看到同一场景下的两次执行，一个错误率15.85%，一个为0.75%，这两条也都不是有效数据，因为在需求下，我们不可能允许有怎么高的错误率发生，你想果每有5个人访问就要一个人失败，那用户体验也太不好了。我认为错误率在千分之一和万分之一间还是可以能叫人接受的，所以在记录数据时，如果错误率过高，我们就应该放弃该条数据，并且找到原因改正后从新测试。

                                                                                           表三 本地测试机 问卷提交

Scene	Sum	TPS	RET	CPU	MEM	ST	Error%	REC	SNT
10* 1* 5min	4975	16.5	0.5	50%	54%	11:47	0.00%	10.1	20.9
20* 1* 5min	6783	22.6	0.88	61%	50%	11:57	0.00%	13.9	28.6
40* 1* 5min	9821	32.6	1.21	75%	51%	12:05	0.00%	20	41.2
80* 1* 5min	4750	15.6	5.08	51%	51%	12:16	0.00%	9.58	19.7
120* 1* 5min	12200	40.0	2.93	94%	53%	12:41	0.11%	22.9	50.9
160* 1* 5min	11124	36.9	4.3	95%	55%	13:00	0.00%	19.7	46.8
200* 1* 5min	8212	23.8	6.95	76%	53%	12:31	15.85%	15.2	30.1
200* 1* 5min	13413	44.6	4.47	97%	56%	13:06	0.75%	22.8	56.4

例4

       在表四中 我们发现吞吐量比表三中高了一倍，这是因为我们服务器性能拓展的原因。但是CPU却没有占满，这是因为什么呢？通过之前的分析，我们应该很容易知道，这是因为我们带宽有限，每秒只能发送出某个数量的请求。如果想要测试出更高CPU使用率下的吞吐量，我们可以考虑分布式测试或者用更高的带宽。
                                                                      表四 云测试机 服务器扩展资源后 问卷访问及提交

Scene	Sum	TPS	RET	CPU	MEM	ST	Error%
100*3min	32453	178.3	0.55	49%	45%	10:48	0.04%
500*3min	32357	178.2	1.58	59%	46%	10:30	0.00%
800*3min	31607	173.1	4.55	48%	45%	10:38	0.04%
1000*3min	32325	175.8	5.58	50%	46%	10:52	0.5%

       其实一整个系列都在围绕有效数据展开讨论的，如何获得有效数据，测试出的数据那些是有效的。这样我们通过测试数据分析出的结论才能站的住脚，有理有据。而不是我们随便测试出一些数据，停留在数据表面去得出一些结论。题外话，我们不应该是为了谁而工作，也不是为了什么而工作，我们是为自己而工作的，也是为了我们自己的明天而工作的，如果我们停止了自我价值的实现，那必然是会焦虑和难过的。不论大家是否未来以测试为目标去发展，都希望大家做好眼前的事。希望本节内容对你有所帮助，如有疑问请评论留言，谢谢。