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

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

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

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

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

　　好问题要描述清晰

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　……

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

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

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

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

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