【互联网行业】网站测试-某公司网站压力测试手册.docx

文 档 号：WPTP0001 版 本 号： 1.0 保密级别： 研发部RealmeShow1.0压力测试手册影元设计苏州工业园区2005年9月11日研发部RealmeShow压力测试报告 2005年9月11日 修改历史日期动作人物版本号2006-3-10创立 V1.目 录压力测试报告I1简介1目的1工程信息1测试范围12测试资源1人力资源1测试环境1测试工具2测试方案21 简介1.1 目的为了跟踪工程压力测试情况，让开发人员和测试人员查看工程的测试结果，更好的对后期工作进行安排。1.2 工程信息工程名称：RealmeShow基线号：RealmeShow09111.3 测试范围主要是测试效劳器的性能，在多个客户端同时连接时系统的性能指标，以及客户端的运行情况。2 测试资源2.1 人力资源下表列出了此工程在测试中的方案人员安排：人员具体职责或注释部署和执行测试2.2 测试环境下表列出了测试的系统环境： 测试环境相关硬件、软件、操作系统等网络设备：Cisco Catelyst 3550 L3 Switch效劳器：秀效劳器：Dell 1425 SC P4 Xeon(TM) 2.8 G ,1G RAM ,双千兆网卡商城效劳器：Dell 1425 SC P4 Xeon(TM) 2.8 G ,1G RAM ,双千兆网卡数据库效劳器：DELL 1850 2P4 Xeon(TM) G ,2G RAM ,双千兆网卡操作系统： Windows 2003 Enterprise Server SP1数据库： MYSQL 5Web效劳器：IIS 6.0 + PHP 5.1.2 SP1，VS.NET 2003 SP1客户端：操作系统： Microsoft Windows XP Professional SP2浏览器：以上其他必要软件：Office 20032.3 测试工具下表列出了测试要使用到的工具：表2-1 测试工具工具用途生产厂商/自产版本Bugzilla缺陷跟踪开源ApplicationCenterTest 压力测试工具微软性能监视器监视效劳器的性能参数微软2.4 测试方案压力测试使用5台客户端，分别在不同的网口，每台客户端模拟120，100，80，60个连接，运行时间为30分钟，分别运行了5个用户场景首页、论坛页面、等几个主要页面。观察不同连接时效劳器的响应情况，效劳器性能指标、网络带宽消耗指标等，并作统计，找出潜在的问题，以便下一轮系统优化。 Web网站压力测试教程详解2021年07月06日09:29文本Tag： 软件测试 性能测试 Web测试 压力测试 【IT168技术文档】Web 效劳处于分布式计算的核心位置，它们之间的交互通常很难测试。分布式开发、大型的开发者团队以及对代码日益组件化的期望都有可能使 Web 效劳的开发变得越来越容易隐藏错误。这些类型的错误极难检测出来。压力测试是检测这类代码错误的一种有效方法，但是只有在压力系统设计得比拟有效的情况下才能发挥作用。本文将让您深入了解一下这种压力系统的根本要求。测试方法传统的测试方法包括某种形式的简单单元测试，通常由开发人员执行。设计这些测试需要了解软件的内部知识，并且这些测试几乎总是针对产品的非常小的、特定的局部。这些类型的测试非常适合与其他代码组件极少交互，甚至没有交互的简单 Web 效劳。功能验证(Functional Verification) 也是一种测试过程，在这个过程中，对产品源代码了解有限的设计者进行测试以确认产品或效劳的核心功能。设计这种测试是为了证明这个核心功能符合某个标准。举个例子，我的在线拍卖显示的是输入的正确出价吗? 我的保险经纪人系统找到最廉价的报价了吗?如果这些测试失败，通常就意味着检测到了产品的一个根本问题(这个问题通常是可以直接修复)。这种测试也是适合简单的 Web 效劳，使您可以检查效劳是否能够正确执行它的各个功能。系统测试(System Test) 通常是在功能验证阶段完成，验证了核心功能后进行。它倾向于把整个系统作为一个整体来查找问题 弄清 Web 效劳作为系统的一局部怎样运作，以及 Web 效劳相互之间如何交互。由于系统测试是在开发生命周期快结束时才进行，所以通常不能给它分配足够的时间来完成。又因为紧张的发行日程安排以及开发的各个重要阶段的后移，系统测试阶段经常被忽略，并且一些通常都可以发现的、少见的错误都不能被检测到。即使发现了这种错误，这时也来不及确定错误的原因并设法修复它们了。因此，在查找代码错误时，必需把系统测试应用设计得尽可能高效。系统测试通常由三局部组成，它们是：性能(Performance)： 这涉及到确定相关的产品统计数据的过程。例如：每秒有多少条消息?一个效劳可同时接受多少个用户?案例(Scenario)： 这是重新创立客户所需确实切配置的过程。因此在案例中发现的任何问题都可以在客户使用该产品之前被检测出来。压力(或称工作负载平衡)： 它与另两个局部不同，因为它被设计为通过应用很大的工作负载来使软件超负荷运转。如果压力测试通过对产品保持高强度的使用(但不超过性能统计数字确定的限制)能有效地执行，那么它就经常能够发现许多隐蔽的错误，而这些错误用上面提到的任何其他技术都是发现不了的(这些错误也经常是最难修复的)。从检测代码错误这方面来说，可以证明这三个系统测试组件中效率最高的是压力测试局部。但由于这个过程经常跟系统的其他要素或功能测试混淆在一起，所以这个过程涉及到的方法还没有被正确着手处理或实现。压力下的错误使用压力测试，您有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是：内存泄漏(Memory leak)： 一种极难检测的现象。内存泄漏经常发生在已发行的产品中，原因很简单，很难设计测试用例来检测它们。使用简单的功能测试，几乎发现不了内存泄漏问题，因为在产品完成之前测试没对产品进行足够多的使用。内存泄漏通常要求操作作要重复非常多的次数以使内存消耗到达能引起注意的程度。尽管与其它编程语言(如 C/C+)相比，Java 程序更难引入内存泄漏错误，但只要程序仍保持着对对象的引用，该对象仍有可能被实例化并且它占用的内存永远不会被释放。并发与同步(Concurrency and Synchronization)： 压力测试在查找并发性问题上非常出众，这是因为在任何一个测试生命周期中，它都应用了许多不同的代码路径和定时条件。一般的规那么是，压力测试运行的时间越长，涉及并应用的代码路径组合和定时条件就越多。当然，这也确实使得这些问题很难再现(错误可以在 5 分钟或 5 天后发生)。死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测出来。这些类型的问题很难通过执行单元测试来发现。开发人员不会一直考虑他或她的代码将与其他地方的代码(在执行单元测试时这些代码可能还没写出来)进行交互。现有的压力测试工具有许多声称能够对产品进行压力测试的可用工具目前正在开发中。被广泛应用的是针对 Web 效劳的那些工具。然而，这些工具中有许多只是简单的 HTML/SOAP 生成器，它们模拟许多客户机连接，并因此对 Web 效劳器生成高负载(这对于查找 Web 效劳器的问题很有用，但对于查找 Web 效劳的问题就没那么有用了)。这些工具对根本的压力测试比拟有用，但它们经常是仅仅扩展功能验证阶段来重复地执行相同的功能任务。如果足够的时间和资源可用，就可以通过创立定制构建的压力测试系统来实现更有效的测试。由于压力系统的设计者通常对要测试的产品和 Web 效劳有更多的了解，所以他们将能够确保压力系统可以用于哪些具体的代码区域。设计压力应用设计试图对 Web 效劳进行压力测试的压力测试系统时，要让它们以某种特定的方式运行代码。这些风格超越了功能验证，目的是要弄清楚被测试的 Web 效劳是不是不仅能做我们认为它能做的事，而且在被施加了某些高强度压力的情况下仍然继续正常运行。压力测试必须对 Web 效劳应用四个根本条件。许多已建立的压力系统应用了这些条件。有效的压力测试系统将应用以下这些关键条件：重复 (Repetition)： 或许最明显的且最容易理解的压力条件就是测试的重复。换句话说，测试的重复就是一遍又一遍地执行某个操作作或功能，比方重复调用一个 Web 效劳。功能验证测试可以用来被弄清楚一个操作作能否正常执行。而压力测试将确定一个操作作能否正常执行，并且能否继续在每次执行时都正常。这对于推断一个产品是否适用于某种生产情况至关重要。客户通常会重复使用产品，因此压力测试应该在客户之前发现代码错误。许多最简单的压力系统只实现这一个条件，但简单地扩展功能验证测试来屡次重复并不能构成一个有效的压力测试。当与下面的一些原那么结合起来使用时，重复就可以发现许多隐蔽的代码错误。并发(Concurrency)： 并发是同时执行多个操作作的行为。换句话说，就是在同一时间执行多个测试，例如在同一个效劳器上同时调用许多 Web 效劳。这个原那么不一定适用于所有的产品(比方无状态效劳)，但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码例如才能测出来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须超越功能测试，要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一个 Web 效劳压力测试需要一次模拟多个客户机。Web 效劳(或者任何多线程代码)通常会访问多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引入并发性意味着一个线程中的代码有可能被其他线程中的代码中断，所以错误只在一个指令集以特定的顺序(例如以特定的定时条件)执行时才会被发现。把这个原那么与重复原那么结合在一起，您可以应用许多代码路径和定时条件。量级(Magnitude)： 压力系统应该应用于产品的另一个条件考虑到了每个操作作中的负载量。压力测试可以重复执行一个操作作，但是操作作自身也要尽量给产品增加负担。例如，一个 Web 效劳允许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作作进行高强度的使用。换句话说就是，您增加了这个操作作的量级。这个量级总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它。例如，数据的大小、延迟的长度、资金数量的转移、输入速度以及输入的变化等等。单独的高强度操作作自身可能发现不了代码错误(或者仅能发现功能上的缺陷)，但与其他压力原那么结合在一起时，您将可以增加发现问题的时机。随机变化： 最后一点，任何压力系统都多多少少具有一些随机性。如果您随机使用前面的压力原那么中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在测试生命周期内改变测试的例如。使用重复时，在重新启动或重新连接效劳之前，您可以改变重复操作作间的时间间隔、重复的次数，或者也可以改变被重复的 Web 效劳的顺序。使用并发，您可以改变一起执行的 Web 效劳、同一时间运行的 Web 效劳数目，或者也可以改变关于是运行许多不同的效劳还是运行许多同样的实例的决定。量级或许是最容易更改的 每次重复测试时都可以更改应用程序中出现的变量(例如，发送各种大小的消息或数字输入值)。如果测试完全随机的话，因为很难一致地重现压力下的错误，所以一些系统使用基于一个固定随机种子的随机变化。这样，用同一个种子，重现错误的时机就会更大。一个压力测试通常会结合上述的所有原那么，并且在允许的范围内尽可能长时间地运行。测试被允许的执行时间越长，就可以遍历越多的代码路径，并且发现的错误也越多。当然，一旦找到错误就必须诊断并修复它。由于一个代码错误可以在压力测试运行多日以后自己显示出来，所以系统必须保证当出现错误时所有可用的调试信息都被生成，否那么可能就必须花费同样多的时间来重现这个错误。结束语测试是软件开发过程中至关重要的局部，并且一个重要的、经常被曲解或忽略的局部是压力测试。遵循上面详细说明的原那么，您就可以设计并实现有效的压力测试系统，用来查找一些与您的代码相关的、比拟隐蔽的问题。无论是利用预先写好的工具，还是创立一个完全专用的压力系统，压力测试都是用于查找 Web 效劳(或其他任何程序)问题的本质方法。 网站压力测试工具的介绍(想知道你的网站稳定么？)Microsoft Web Application Stress Tool Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站效劳所可能造成的影响，在网站实际上线之前先对您所设计的网站进行如同真实环境下的测试，以找出系统潜在的问题，对系统进行进一步的调整、设置工作。Microsoft Web Application Stress具有以下几个特性：* 可以数种不同的方式建立测试指令：包含以手动、录制浏览器操作步骤、或直接录入IIS的记录文件、录入网站的内容及录入其它测试程序的指令等方式。* 支持多种客户端接口：标准的网站应用程序C+的客户端，使用Active Server Page 客户端，或是使用Web Application Stress对象模型建立您自定的接口。.* 支持多用户利用多种不同的认证方式仿真实际的情况，包含了DPA, NTLM 及 SSL等。* 支持使用动态的cookie仿真定制网站实际运作场景及对话session的支持。* 在客户端的计算机以NT 效劳的方式执行仿真的工作，可在不中断测试的情况下将某些客户端的测试计算机删除。* 透过集中式的Microsoft Web Application Stress 管理员，您可以使用任意数目的客户端计算机同时进行测式的工作。* 具有Bandwidth throttling 带宽遏流的功能以仿真用户使用调制解调器上线的效果。* 内建的query-string 编辑器可帮助您建立name-value pair组合的模板，并可在不同的场景测试中重复使用。* 可程序化的对象模式让您可以建立您自己的测试客户端。* 汇总的测试报告及丰富的性能测试资料。* 支持域名系统(DNS)让您可以测试整个群集Cluster的机器。* 使用Page group的方式来控制文件的组及测试指令的执行程序。* 可自定的header让您可以仿真各种不同种类的浏览器。* 可自定的指令延迟让您以更接近真实环境的方式进行测试。网站测试概述为了正确使用WAS进行网站的压力测试，您需要对于网站测试的方法有一初步的了解。以下的讨论将包含一些根本的概念以供参考。网站的测试可大概分成三个主要的类别：* 网站性能测试 (Performance testing)* 压力测试下的网站稳定性 (Stability or stress testing)* 网站承受能力评估 (Capacity planning)网站性能测试的第一件工作就是使用测试工具对网站加压以测量网站效劳器每秒可以承受的请求(Request Per Second) 的最大值。第二件工作就是找出系统性能限制的原因所在，举例来说，CPU、内存、或是后端系统所造成的反响延迟等。在许多状况下，网站效劳器的CPU是主要的性能瓶颈。测试时您可以持续加压直到性能表现开始下降，再慢慢的降低压力的程度。此时您所测试出来的最大性能即为该网站所能到达的最高值。在实际测试时，您可以通过增加压力线程(thread)，或是增加执行WAS测试程序的客户端来加压。在网站效劳器端，您可以使用性能监视工具如Performance Monitor来监视如 System: % Total Processor Time 及 Web Service: Connection Attempts/sec 或 Active Server Pages: Requests Queued等指针。如果CPU的资源指针已到达80%到85%，那么CPU的处理能力最有可能就是整个系统的瓶颈所在。假设是在压力测试的过程中CPU所被使用的比例不高而Requests Queued的指针一直居高不下，可能是程序正在调用效劳器上的COM组件而这个组件无法有效的执行完所有的命令，因而造成了系统性能的降低。在这种情形下，效劳器上的COM组件才是真正的瓶颈。目前市场上最热门的定制网站应用程序也会对网站的性能表现有重大的影响。WAS包含了数种特性可有效的帮助您测试定制的网站应用程序。例如，您可以建立用户，让WAS可以设置并储存每一个用户的cookie。您也可以使用QueryString 编辑器帮助您建立并储存数个不同的name-value pair以便在每一次执行request时进行测试。一般的网站测试问题* 错误的测试平台，和实际上线的 production server生产环境效劳器不同，无法测出实际的问题。* 错误的测试指令，无法正确的仿真出实际上线系统真正的反响。* 线程平安性问题以及不稳定的效劳器COM组件。* Active Server Page 的错误及GLOBAL.ASA 设置的问题。