经常会见到新人提出这样的性能问题：
"100用户时，A操作响应时间达到了XX秒，请修改"
"场景运行2个小时后，系统没有响应了"
面对这样的问题，开发人员一定会觉得很无助，他们甚至不知道问题是什么。
即使从测试人员的角度来看，这也算不上是一个合格的问题。甚至是不是真正的问题，都要暂时打上问号。
那么一个合格的性能问题应该是什么样呢？
首先要证明这是一个问题
开发人员面对测试提出的问题时，第一反应很容易是"我的程序没有问题，是你的使用不正确"，想必大多数测试人员都有过这种感受吧。手工功能测试尚是如此，更不用说性能测试了，因为性能测试的核心在于"模拟"二字，模拟大量用户、模拟大数据量......这必然要引入很多测试工具、测试代码。那么工具使用的是否正确、代码编写是否可靠、模拟的用户和数据是否真实，都可能直接影响到测试结果。由于测试而引入的问题，有经验的性能测试人员一定有所经历，一些可能会留下很深的印象。因为这种问题的后果往好了说是耗时耗力、最后证明测试不当，往坏了说可能会误认为系统存在问题、做出了不该有的改变。
那么如何才能证明测试过程没有问题，有问题的是被测系统呢？简单的说，是要把测试过程公开化，把测试的方法、测试的具体场景、测试代码的实现、测试环境等等拿出来让开发人员、业务人员等评审和确认，让相关人理解具体的测试过程，让大家知道你到底在做什么。这是一个说起来容易，实际中很难做好的工作，只有靠制订测试过程的详细规范才能从源头去主动的改善这一过程。否则，靠你的嘴皮子去和开发人员理论吧。
好问题要描述清晰
100个用户，是指绝对并发操作么？还是什么样的场景？
是只测这一个A操作？还是有多个操作在同时进行？
如果有多个操作，是只有这一个操作变慢？还是普遍变慢？
测试环境是什么样的？测试数据量是多少？
这又回到了上面那个"测试过程公开化"的范畴了。也许开发人员理解了详细的测试场景后，会告诉你，这个场景在业务中是不可能的，或者测试数据量是不合理的。
好问题要有尽量深入的定位
只是描述清晰还不够，要明白什么是表面现象，什么才是问题。
问题是需要定位才能发现的。
"100个用户操作时，A事务的响应时间过长"，这只是一个场景的运行结果，只是一个现象，问题是什么呢？
响应慢是慢在哪？是中间件还是数据库？这是最基本的分层定位。
是服务器达到了硬件瓶颈么？如果硬件或操作系统上没有瓶颈，那么瓶颈在哪？
是不是由于一些基本配置问题导致了排队呢？比如中间件的HTTP线程数和数据库的连接数。
如果基本配置没有问题，那么再深入一些，是内部的哪些资源产生了争用和等待么？
是哪些SQL引起了数据库内部资源的争用呢？应用程序上又是哪个方法在占用资源呢？
......
定位的越深入，需要的技术能力也就越高。
好问题应该用最简单的手段复现
比如上面的100个用户，导致了数据库的一张表的争用，因此产生了大量锁等待现象，最终导致了外部的A响应时间过长。但是通过之前的分析和定位，我们发现也许引发问题的那些SQL语句，只来自100用户中的10个特殊类型的用户。那么这个问题就完全可以简化成用10个用户去复现，其他90个用户都是干扰。这样问题被简化了，开发人员也就更容易理解问题，对于测试的复测也更加方便。
不过还是要记住，最终的用户场景模拟才是决定性的验证。
最后再总结一下，性能问题到底应该如何提呢？其实只有一个标准，那就是能让开发理解问题、找到根本原因并进行修正的就够了（假设开发人员无所不能）。再进一步深入的分析，可能是为了减轻开发的一些负担，也可能是为了锻炼自己的能力，这就不是每个测试人员都会去做的了。
【性能测试】终于有一套全面的性能测试教程啦！真实企业性能测试全流程项目实战!