Web应用程序的整体测试

　　随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型Web应用是如何来进行测试的。

　　B/S下的功能测试比较简单，关键是如何做好性能测试。目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。

　　首先我们从两个方面分析如何进行WEB测试，从技术实现上来讲一般的B/S结构，无论是.NET还是J2EE，都是多层构架，有界面层、业务逻辑层、数据层。而从测试的流程上来说，首先是发现问题、分析问题、定位问题，再由开发人员解决问题。那么B/S的结构的测试如何来做?

　　如何发现问题是我首先要介绍的，在做WEB测试之前你需要一些资料，比如产品功能说明书，性能需求说明书，不一定很完善，但一定要有，明确测试目标，这是基本的常识，可是我往往看到的是已经开始动手测了，但还不知自己的系统要达到的性能指标是什么。这里我简单讲一下测试的性能指标：

　　1、通用指标(指Web应用服务器、数据库服务器必需测试项):

　　* ProcessorTime: 指服务器CPU占用率，一般平均达到70%时，服务就接近饱和;

　　* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重;

　　* Physicsdisk Time : 物理磁盘读写时间情况;

　　2、Web服务器指标：

　　* Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数;

　　* Avg time to last byte per terstion (mstes):平均每秒业务角本的迭代次数，有人会把这两者混淆;

　　* Successful Rounds：成功的请求;

　　* Failed Rounds ：失败的请求;

　　* Successful Hits ：成功的点击次数;

　　* Failed Hits ：失败的点击次数;

　　* Hits Per Second ：每秒点击次数;

　　* Successful Hits Per Second ：每秒成功的点击次数;

　　* Failed Hits Per Second ：每秒失败的点击次数;

　　* Attempted Connections ：尝试链接数;

　　3、数据库服务器指标：

　　* User 0 Connections ：用户连接数，也就是数据库的连接数量;

　　* Number of deadlocks：数据库死锁;

　　* Butter Cache hit ：数据库Cache的命中情况;

　　上面的指标只是一些通用的指标,起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。对于这些指标的详细了解，你可以参考Windows 下面的 SystemMonitor的帮助与LoadRunner、ACT的帮助。对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner、ACT、WAS、WebLoad，各个工具有它的使用范围，其中我各个认为LoadRunner最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任，WAS与ACT则对微软的技术支持的比较好，其中WAS支持分布式机群测试,ACT则是与.NET集成比较好，支持ViewState (.NET 下控件缓存的支持) 的测试，当时我用时，其它测试工具还不支持，现在应该支持了吧。

　　在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阀值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阀值的与一些通用参数有问题的子系统进行深入分析。比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。

　　这个我们要对子系统进行详细测试，由于B/S 结构下，图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行：一、非程序部分，即图片等等;二、应用程序本身。通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。

　　对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常、死锁、网络流量等等前面没有注意到的情况的增加，同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个，刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行测试，这样才有更高的可信度。

　　上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种：

　　一、性能达不到目标;

　　二、性能达到目标，但有一些其它的问题，比如异常，死锁，缓存命中过低，网络流量较大;

　　三、服务器稳定性的问题，比如内存泄漏……。

　　要发现这些问题起码的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的Purify与Quantify，主要是他对.net与java、C++都有支持，而且分析效果特别专业，我们先了解一下Rational Purify， Rational Purify能自动找出Visual C/C++ 和Java 代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的Visual C/C++ 程序中的传统内存访问错误，以及Java，C# 代码中与垃圾内存收集相关的错误方面;Rational Quantity 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。

原文转自：http://www.ltesting.net