性能测试新手误区（二）：为什么我模拟的百万测试数据是无效的？
经常会见到新人提出这样的性能问题：
“100用户时，A操作响应时间达到了XX秒，请修改。”
面对这样的问题，开发人员一定会觉得很无助，他们甚至不知道问题是什么。
即使从测试人员的角度来看，这也算不上是一个合格的问题。
那么一个好的性能问题应该是什么样呢？
好问题要描述清晰
100个用户，是指绝对并发操作么？还是什么样的场景？
是只测这一个A操作？还是有多个操作在同时进行？
如果有多个操作，是只有这一个操作变慢？还是普遍变慢？
测试环境是什么样的？测试数据量是多少？
也许开发人员理解了详细的测试场景后，会告诉你，这个场景在业务中是不可能的，或者测试数据量是不合理的。
好问题要有尽量准确的定位
只是描述清晰还不够，要明白什么是表面现象，什么才是问题。
问题是需要定位才能发现的。
“100个用户操作时，A事务的响应时间过长”，这只是一个现象，问题是什么呢？
响应慢是慢在哪？是中间件还是数据库？这是最基本的分层定位。
是服务器达到了硬件瓶颈么？如果硬件或操作系统上没有瓶颈，那么瓶颈在哪？
是不是由于一些基本配置问题导致了排队呢？比如中间件的HTTP线程数和数据库的连接数。
如果基本配置没有问题，那么再深入一些，是内部的哪些资源产生了争用和等待么？
是哪些SQL引起了数据库内部资源的争用呢？应用程序上又是哪个方法在占用资源呢？
……
定位的越深入，需要的技术能力也就越高。
好问题应该用最简单的手段复现
比如上面的100个用户，导致了数据库的一张表的争用，因此产生了大量锁等待现象，最终导致了外部的A响应时间过长。但是通过之前的分析和定位，我们发现也许引发问题的那些SQL语句，只来自100用户中的10个特殊类型的用户。那么这个问题就完全可以简化成用10个用户去复现，其他90个用户都是干扰。这样问题被简化了，开发人员也就更容易理解问题，对于测试的复测也更加方便。
不过还是要记住，最终的用户场景模拟才是决定性的验证。
最后再总结一下，性能问题到底应该如何提呢？其实只有一个标准，那就是能让开发理解问题、找到根本原因并进行修正的就够了（假设开发人员无所不能）。再进一步深入的分析，可能是为了减轻开发的一些负担，也可能是为了锻炼自己的能力，这就不是每个测试人员都会去做的了。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/
