qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

性能测试新手误区(五):如何提出一个好的性能问题

  性能测试新手误区(一):找不到测试点,不知为何而测

  性能测试新手误区(二):为什么我模拟的百万测试数据是无效的?

  性能测试新手误区(三):用户数与压力

  性能测试新手误区(四):一切来自录制

  经常会见到新人提出这样的性能问题:

  “100用户时,A操作响应时间达到了XX秒,请修改。”

  面对这样的问题,开发人员一定会觉得很无助,他们甚至不知道问题是什么。

  即使从测试人员的角度来看,这也算不上是一个合格的问题。

  那么一个好的性能问题应该是什么样呢?

  好问题要描述清晰

  100个用户,是指绝对并发操作么?还是什么样的场景?

  是只测这一个A操作?还是有多个操作在同时进行?

  如果有多个操作,是只有这一个操作变慢?还是普遍变慢?

  测试环境是什么样的?测试数据量是多少?

  也许开发人员理解了详细的测试场景后,会告诉你,这个场景在业务中是不可能的,或者测试数据量是不合理的。

  好问题要有尽量准确的定位

  只是描述清晰还不够,要明白什么是表面现象,什么才是问题。

  问题是需要定位才能发现的。

  “100个用户操作时,A事务的响应时间过长”,这只是一个现象,问题是什么呢?

  响应慢是慢在哪?是中间件还是数据库?这是最基本的分层定位。

  是服务器达到了硬件瓶颈么?如果硬件或操作系统上没有瓶颈,那么瓶颈在哪?

  是不是由于一些基本配置问题导致了排队呢?比如中间件的HTTP线程数和数据库的连接数。

  如果基本配置没有问题,那么再深入一些,是内部的哪些资源产生了争用和等待么?

  是哪些SQL引起了数据库内部资源的争用呢?应用程序上又是哪个方法在占用资源呢?

  ……

  定位的越深入,需要的技术能力也就越高。

  好问题应该用最简单的手段复现

  比如上面的100个用户,导致了数据库的一张表的争用,因此产生了大量锁等待现象,最终导致了外部的A响应时间过长。但是通过之前的分析和定位,我们发现也许引发问题的那些SQL语句,只来自100用户中的10个特殊类型的用户。那么这个问题就完全可以简化成用10个用户去复现,其他90个用户都是干扰。这样问题被简化了,开发人员也就更容易理解问题,对于测试的复测也更加方便。

  不过还是要记住,最终的用户场景模拟才是决定性的验证。

  最后再总结一下,性能问题到底应该如何提呢?其实只有一个标准,那就是能让开发理解问题、找到根本原因并进行修正的就够了(假设开发人员无所不能)。再进一步深入的分析,可能是为了减轻开发的一些负担,也可能是为了锻炼自己的能力,这就不是每个测试人员都会去做的了。

posted on 2012-10-11 10:02 顺其自然EVO 阅读(210) 评论(0)  编辑  收藏 所属分类: 性能测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2012年10月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜