BlogJava-自由,平等,开源,分享-文章分类-用软http://www.blogjava.net/shisanfeng/category/31954.html闻道有先后，术业有专攻，如是而已zh-cnWed, 04 Jun 2008 17:27:52 GMTWed, 04 Jun 2008 17:27:52 GMT60基于 Windows 下的 Web 服务器测试http://www.blogjava.net/shisanfeng/articles/205877.html龙震龙震Wed, 04 Jun 2008 09:19:00 GMThttp://www.blogjava.net/shisanfeng/articles/205877.htmlhttp://www.blogjava.net/shisanfeng/comments/205877.htmlhttp://www.blogjava.net/shisanfeng/articles/205877.html#Feedback0http://www.blogjava.net/shisanfeng/comments/commentRss/205877.htmlhttp://www.blogjava.net/shisanfeng/services/trackbacks/205877.html
　　随着 Internet 的日益普及，现在基于 B/S 结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我 B/S 的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对 Web 的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型 Web 应用是如何来进行测试的。

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

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

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

　　通用指标（指 Web 应用服务器、数据库服务器必需测试项）：

　　　　Processor Time：指服务器 CPU 占用率，一般平均达到 70% 时，服务就接近饱和；
　　　　Memory Available Mbyte：可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
　　　　Physicsdisk Time：物理磁盘读写时间情况。

　　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：尝试链接数。

　　数据库服务器指标：

　　　　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 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。

　　我们先说性能优化与异常的处理，性能优化有一个原则，即用时间比例最大的进行优化，效果才最明显。比如有个函数它的执行时间为 30 秒，如果你优化了一百倍则执行时间为 0.3 秒，提升了 29.7 秒；而如果它的执行时间为 0.3 秒，优化后为 0.003 秒，实际提升了 0.297 秒，提升的效果并不明显但写过程序的人都知道，后者性能优化的代价更大。

　　在性能优化的过程中，一般是先数据库，后程序。因为数据库的优化不需要修改程序，修改的风险很小。但如何才能确定是数据库的问题，这就需要技巧，在使用 Quantity 时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么 SqlCmd.ExecuteNoQuery 等等数据库执行函数，这时你就需要分析数据库。

　　数据库的分析原则是先索引，后存储过程，最后表结构视图的优化。索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。在这里我要给大家简单的介绍一下我的最爱：SQLProfile、SQL 查询分析器。

　　Precise SQLProfile 是一个 SQL 语句跟踪器，可以跟踪程序流程使用的 SQL 语句与存储过程，结合查询分析器对 SQL 的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。同时针对用户使用频度最高的 SQL 进行优化也是最行之有效的，这时我则需要 Precise，它可以观测某一个较长时间内的 SQL 语句的执行情况。

　　数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事。测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是 DCOM 调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情哦。

　　内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集，或是借助内存分析工具观察内存对象情况，初步定位问题，再用 Purify 进行运行时分析，通常 C++ 内存问题比较多， Java 与 .NET 比较少，一般由 GC 不合理引起。C++ 的内存错误就比较多了，主要常见的有：

　　　　Array Bounds Read（ABR）：数组越界读
　　　　Array Bounds Write（ABW）：数组越界写
　　　　Beyond stack Read（BSR）：堆栈越界读
　　　　Free Memory Read（FMR）：空闲内存读
　　　　Invalid pointer Read（IPR）：非法指针阅读
　　　　Null Pointer Read（NPR）： 空指针阅读
　　　　Uninitialized Memory Read（UMR）：未初始化内存读写
　　　　Memory Leak：内存泄漏

　　　　注：如果需要更多的信息，可以参见 Purify 的帮助信息。

　　顺便提一句，为什么我要说做单元测试时做内存分析比较好，由于单元测试针对的是单一功能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具 PureCoverage 来做就更完美了。

　　注：本篇只是对 B/S 应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍，你也可使用你比较熟悉的工具达到相同的目标。



龙震 2008-06-04 17:19 发表评论
]]>使用 Microsoft Web Application Stress Tool 对 Web 服务器进行压力测试 http://www.blogjava.net/shisanfeng/articles/205820.html龙震龙震Wed, 04 Jun 2008 07:09:00 GMThttp://www.blogjava.net/shisanfeng/articles/205820.htmlhttp://www.blogjava.net/shisanfeng/comments/205820.htmlhttp://www.blogjava.net/shisanfeng/articles/205820.html#Feedback0http://www.blogjava.net/shisanfeng/comments/commentRss/205820.htmlhttp://www.blogjava.net/shisanfeng/services/trackbacks/205820.html
　　Web 压力测试是目前比较流行的话题，利用 Web 压力测试可以有效地测试一些 Web 服务器的运行状态和响应时间等等，对于 Web 服务器的承受力测试是个非常好的手法。Web 压力测试通常是利用一些工具，例如微软的 Web Application Stress、Linux 下的 Siege、功能全面的 Web-CT 等等，这些都是非常优秀的 Web 压力测试工具。

　　虽然这些工具给我们测试服务器承受能力带来方便，但是它们的危害却更是惊人，甚至于利用随便一种比较全面的测试工具就可以对一台小型的 Web 服务器发动灾难性的拒绝式攻击。下面我就带大家利用微软的 Web Application Stress 进行一次 Web 压力测试，其目的是为了让大家看到它的巨大危害。

一、工具简单介绍

　　Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的客户端计算机仿真大量用户上线对网站服务所可能造成的影响，在网站实际上线之前先对您所设计的网站进行如同真实环境下的测试，以找出系统潜在的问题，对系统进行进一步的调整、设置工作。就是因为这些特性，才使它具备了 D.O.S 轰炸的功能。

　　小提示：D.O.S（拒绝服务攻击）通过使你的服务计算机崩溃或把它压跨来阻止你提供服务。简单来说，就是让你的计算机提供可能多的服务从而使你的计算机陷入崩溃的边缘或崩溃。

二、工具简单设置

　　打开 Web Application Stress Tool，很简洁的一个页面，上面是工具栏，左下方是功能选项，右下方是详细设置选项。在对目标 Web 服务器进行压力测试之前，先对它进行一些必要的设置。


　　1. 在“Settings”的功能设置中，一个是 Stress level （threads）这里是指定程序在后台用多少线程进行请求，也就是相当于模拟多少个客户机的连接，更加形象的就是说设置多少轰炸的线程数。一般填写 500～1000，因为这个线程数是根据本机的承受力来设置的，如果你对自己的机器配置有足够信心的话，那么设置的越高，轰炸的效果越好。


　　2. 在“Test Run Time”中来指定一次压力测试需要持续的时间，分为天、小时、分、秒几个单位级别，你根据实际情况来设置吧！

　　3. 其余的选项不太重要，这里就不再浪费笔墨，朋友们可以自己尝试一下设置。

三、压力测试

　　工具介绍完了，下面来准备条件：这里与一个朋友商量好进行测试，他是单机上网，机器配置是 CPU Athlon XP2500+、内存 512MB、硬盘 80GB 等，机器配置还不错。他在机器上安装了 IIS，架设了一台对外的 Web 服务器，Web 服务中的程序是动网 7.0。我就利用压力测试工具对这台服务器进行测试。

　　步骤 1：在工具中点右键，选择 Add 命令，增加了一个新的测试项目：New Script，对它进行设置，在主选项中的 Server 中填写要测试的服务器的 IP 地址。在下方选择测试的 Web 连接方式，这里的方式 Verb 选择 Get，Path 选择要测试的 Web 页面路径，这里填写 /Index.asp，即动网的首页文件。


　　步骤 2：在“Settings”的功能设置中将 Stress level （threads）线程数设置为 1000。完毕后，点工具中的灰色三角按钮即可进行测试。测试完毕，等待朋友把任务管理器以及连接查看的截图发过来！


　　攻击开始后，朋友从任务管理器中可以看到 CPU 使用率已经达到 100%，损耗率达到最大。在 CMD 窗口中使用命令 netstat -an，可以看到我的 IP 地址在朋友服务器上的80端口进行了非常多的连接。而且它的 Web 网站已经打不开了，提示过多用户连接，达到了跟 D.O.S 攻击一样的目的。



　　试想，如果利用多台肉鸡对一台服务器进行 Web 压力测试，那么对这台服务器来说将是灭顶之灾，所以朋友们在使用它之前一定要慎重考虑。



龙震 2008-06-04 15:09 发表评论
]]>