性能测试之如何提出一个好的性能问题

性能测试之如何提出一个好的性能问题

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

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

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

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

好问题要描述清晰

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

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

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

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

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

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

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

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

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

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

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

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

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

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

……

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

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

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

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

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