2.4　确保在性能测试过程中应用程序足够稳定

在提供了一个测试环境，并设定了性能指标之后，您需要确认应用程序对于性能测试来说是足够稳定的。这项要求乎显而易见，然而随着项目时间的逐渐减少，性能测试却经常沦为一场令人沮丧的修复缺陷练习；系统不稳定，性能测试过程中经常发现功能等系统测试过程中留下来的缺陷。

系统稳定性是对于应用程序能够正确提供服务的信心。假如您要下一个购买订单，应该保证每次都是成功的，而不是10次只有2次成功。如果在应用程序的功能上有一个明显的问题，那么性能测试过程就毫无意义，因为这些问题会掩盖那些由于负载和压力而产生的后果。

性能测试之前，代码的质量对于性能的好坏是至关重要的。您需要一个有效而适当的单元测试和功能测试策略，在进行性能测试之前，保证系统的稳定性。

我还记得在为位于爱尔兰的都柏林的一个客户做保险系统性能测试的那个项目。那个客户坚持说系统已经顺利地通过单元和回归测试，并且开始准备做性能测试。但是在对数据库进行了一个快速检查后，就发现一个存储过程的执行时间仅仅在一次循环里就达到了60分钟。

我不敢相信应用程序中用到这个存储过程的地方确实经过了功能方面的充分测试。显然，在任何情况下，60分钟都不会是一个可以接受的执行时间。这是一个极端的例子，但它可以证明我的观点。

有很多工具可以（参见附录C）通过评估应用程序是否适合进行性能测试。重点看看以下可能隐藏的问题。

大数据量展现

您的应用程序的功能也许已经稳定，但是由于编码或设计上的效率低下，导致在网络上有大量的数据展现。如果您的系统预期的用户受到带宽限制，那么这些行为将对性能产生负面的影响。大数据量可能是由于在一个Web页面上的大量图像文件，或在客户端和服务器之间大量冗余通信引起的。

执行效率不佳的SQL语句

如果您的应用程序使用了SQL数据库，那么就可能存在一些写得不好的或是错误设置的SQL语句或存储过程。在查明和解决这些问题之前就需要进行性能测试；否则它们对于性能的影响将随着负载的增长而被放大。

大量的网络数据交互

另一个性能表现不佳的应用设计是有大量的通信或应用层之间的数据“交互”。大量的交互使得应用程序的访问延迟增大，带宽限制和网络拥塞的影响，其后果就是在这样的网络条件下导致了性能问题。

应用程序的未知错误

尽管应用程序从功能的角度上看可以很好地工作，但仍然可能存在一些对用户（或开发人员）来说不太明显的错误。这些错误可能导致效率低下，从而影响性能和可扩展性。例如，一个提示Web页面不存在或找不到的HTTP 404错误，在单一事务中可能问题不大，但是当每分钟有几千个事务时，对性能的影响就相当严重了。如图2-2所示。

图　2-2　不好的SQL性能实例