为什么压力测试会耗费我们如此多的时间

　　我遇到很多客户做过压力测试–有大规模的，也有小规模的– 有用开源工具的，也有用商业软件的。压力测试本身变得越来越容易，越来越可以支付的起——因为出现了很多很好用的压力测试工具。还有一些公司提供在线压力测试服务。尽管做压力测试越来越容易、越来越有效率、而能花很小的代价产生很大的压强，但是我的所有客户都遇到了同样一个问题：压力测试并不会报告是什么导致了问题。它只会报告这有了问题，例如：查询页面在并发50个用户使用时变慢下来，但它不会显示什么导致了变慢。捕获到的性能统计数据例如CPU和内存使用量只是强调了潜在的问题区域，但并不会指出实际的根源在应用程序的什么地方。

　　标准的压力测试报告只提供黑盒视图（Black-Box View）

　　当分析下面的压力测试报告时我们只能发现在我们的应用程序的压力达到某个“点击数/秒”临界点时问题出现了。

压力测试结果

　　我们会发现服务器的CPU很可能跟问题有关，因为它的使用率随着我们产生压强的增多迅速升高，但我们停下来分析问题时，它的使用率也下来了。如果你把这个报告呈给你们的工程师，他们很可能会惊讶他们的应用程序为什么如此的不经压，但他们也没法告诉你是否是应用程序出了什么问题（以及问题在哪）或者是当前版本的应用程序根本就承受不起这么大的压力。

　　过多的测试迭代在拖累我们

　　所以可以看出来，我们从压力测试工具上获得的标准测试报告并不能帮助我们分析出问题的根源在哪里。那通常我们是怎么最终找出问题的呢？下面的图例显示的就是我从我的客户那里看到的典型的测试周期。

需要反复迭代测试才能定位产生效能问题的根源

　　每次测试之后他们都和工程师一起坐下来讨论测试的结果。工程师们试图重现报告中被重点显示的问题。通常这些问题只有在有相当压力的情况下才会出现，根本就没法在工程师的本地安装了debugger工具或profiling工具的机器上重现。可行的办法就是要改进在测试中捕获到的各种数据详细程度。对捕捉信息的改进可以包括收集额外的有用的性能数据，例如CPU，内存，I/O，内存回收事件，数据库统计，…报告应用程序特殊数据，例如n号订单被处理了，处理队列的长度，处于活动状态的用户会话的数量，…或者扩展应用程序输出的日志，让它跟踪记录性能信息，例如函数的调用次数，执行了哪些SQL语句，…

　　当改进完成了之后，测试会再进行一次。如果你很幸运，你会在第一次改进后获得你想要的数据结果。但据我所观察的结果是通常要好几轮改进之后你才能得到能够让你分析出问题出在哪里并且能够用来修正程序的报告信息。这些额外的测试迭代会耗费测试者以及开发人员的大量时间。如果你有独立的测试团队或者你外包了测试，那你或需要额外的开销来应付这些迭代测试。

　　目标：花最少的时间做更多的测试

　　理想的目标是去除所有的额外开销，就现状来讲包括在压力测试中改进和分析捕获到的数据的工作量。美国Novell公司就有一个精彩的例子来展示在他们的分布式敏捷开发团队里改进压力测试过程的。你可以在公布的学习案例中了解更详细的信息。

　　测试中的应用性能管理可以让你去使压力测试的功效发挥到极致。下图展示了一个真实的压力测试过程是怎样的：

通过应用性能管理避免测试迭代

　　Yes we can!让压力测试充分发挥其能力

　　这篇博客只是简单的谈到了我在客户哪里遇到的问题的皮毛–请查看 Case Studywe did with Novell ，其中讲到了Novell公司如何让他们的测试吞吐量提高2-3倍的。过多的测试迭代和对应用的黑盒测试视图妨碍了我们让压力测试发挥更大的功效，应用性能管理可以帮助我们使这个过程更高效。

　　有兴趣的话你可以下载完整版的How to Transform the Load Testing Process ，它里面讨论了更详细的我们所说的问题，同时向我们展示了如何花最少的时间做更多的测试。关键的要素就是让我们对应用程序内部可视化，能够自动的捕捉数据和分析数据。