吞吐量，做为性能测试的重要专注指标，和并发用户数之间存在一定的联系

F=N*R/T                          （1）

测试中F表示吞吐量，N表示VU（虚拟用户）的个数，R表示每个VU发出的请求（单击）数量，T表示性能测试所用的时间

在时间的测试中，为了更真实的模拟使用环境，还要设置思考时间

 R=T/Ts                           （2）

Ts代表思考时间

1，2两个公式结合在一起，哪么吞吐量与虚拟用户数成正比，与Ts成反比

但是，一个合理的思考时间在具体的测试实践中不好确定，下面给出一个计算思考实践的一般步骤：

1.首先计算出系统的并发用户数统计出系统平均的吞吐量

3.统计出平均每个用户发出的请求数量

4.根据公式（2）计算出思考时间

但是为了让测试场景更加符合实际情况，可以让思考时间在一定幅度内随机变动

最近看了点资料,自己总结了一点,如果有什么错误或建议希望提出,我们共同探讨.

 

录制脚本为空

LR录制是客户端与服务器的数据交互,只有在有交互的时候才可以录制到脚本

1.       交互方式不一样,通过客户端的server进行交互,在scrīpt中选择最后一个track processes created as COM local servers  [选择scrīpt里的最后一个选项]

2.       非客户端与服务器的交互的一种操作,在页面上点前进或后退,如果页面是从缓存中取出来的,那么也就没有和服务器数据交互,所以也录制的为空脚本.   [windows注册表中禁用缓存]

3.       协议选择错误,b/s不一定走http协议,还可能是https(http+ssl).   [最基础的错误]

 

录制出错

1.       选择internet里选项里的连接里的局域网设置的代理不能选,因为LR在录制的时候会动态选择

2.       网页里的恶意代码,检测的时候响应LR录制脚本[用工具检测恶意代码,然后卸载恶意代码,eg:Ad_Aweare]

3.       防病毒软件和防火墙,在录制时暂时关闭

4.       因为LR自身原因报错或者有些脚本不能录制下来[录制是最好选用scrīpt view,此时会报错,但能写下脚本,是因为LR无法解析,可以手工修改,而tree view 就直接停止了]

 

Vugen根本无法打开首页

1.       录制时打开一个空页面,无法显示正确网址,代表vugen有问题,可以在LR安装路径下bin /register_vugen.bat,重新注册,如果还不可以,那就要重新安装了

性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。这时相关开发人员、数据库管理员、系统管理员、网络管理员等就需要根据性能测试分析人员提出的意见同性能分析人员共同分析确定更细节的内容，相关人员对系统进行调整以后，性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。有一点需要提醒大家，就是在进行性能调整的时候，最好一次只调整一项内容或者一类内容，避免一次调整多项内容而引起性能提高却不知道是由于调整那项关键指标而改善性能的。那么在进行系统的调优过程中是否有什么好的策略来知道我们工作呢？经过多年的工作，作者的经验是按照由易到难的顺序对系统性能进行调优。
系统调优由易到难的先后顺序如下：
1.        硬件问题
2.        网络问题
3.        应用服务器、数据库等配置问题
4.        源代码、数据库脚本问题
5.        系统构架问题

硬件发生问题是最显而易见的，如果CPU不能满足复杂的数学逻辑运算，可以考虑更换CPU，如果硬盘容量很小，承受不了很多的数据可以考虑更换高速、大容量硬盘等。如果网络带宽不够，可以考虑对网络进行升级和改造，将网络更换成高速网络；还可以将系统应用与平时公司日常应用进行隔离等方式，达到提高网络传输速率的目的。很多情况下，系统性能不是十分理想的一个重要原因就是没有对应用服务器、数据库等软件进行调优和设置引起来的，如：Tomcat调整堆内存和扩展内存的大小，数据库引入连接池技术等。源代码、数据库脚本在上述调整无效的情况下，您可以选择的一种调优方式，但是由于设计到对源代码的改变有可能会引入缺陷，所以在调优以后，不仅需要对性能的测试还要对功能进行验证，是否正确。这种方式需要通过对数据库建立适当的索引，以及运用简单的语句替代复杂的语句，从而达到提高SQL语句运行效率的作用，还可以在编码过程中选择好的算法，减少响应时间，引入缓存等技术。最后，在上述尝试都不见效的情况下，您就需要考虑现行的构架是否合适，选择效率高的构架，但由于构架的改动比较大，所以您应该慎重对待。

评价测试结果准则：
       测试覆盖率：评价测试的完备性
       需求覆盖率
       代码覆盖率
       质量评测
       缺陷报告
          缺陷密度
          缺陷龄期
          缺陷趋势
       性能评测
          动态监测
          响应时间/吞吐量
          百分位报告
          比较报告
          追踪和配置文件报告

请求提交：客户机浏览器为了与网站进行连接并传输用户提供的数据所需的时间。
处理时间：请求被一台或多台服务器处理以执行用户所需功能的时间。
响应时间：处理请求后，将页面或者数据返回给用户，传输这些页面或数据所需的时间即为响应时间。
延迟时间：一个动作发出到第一个响应回应之间的时间。
用户感知延迟：用户动作发出到内容最初显示之间的时间。
带宽：每单位时间内可传输的流量。
工作负载：一段时间内，web组件接收的输入量。

在Internet大众化及Web技术飞速演变的今天，在线安全所面临的挑战日益严峻。伴随着在线信息和服务的可用性的提升，以及基子Web的攻击和破坏的增长，安全风险达到了前所未有的高度。由于众多安全工作集中在网络本身上面，Web应用程序几乎被遗忘了。也许这是因为应用程序过去常常是在一台计算机上运行的独立程序，如果这台计算机安全的话，那么应用程序就是安全的。如今，情况大不一样了，Web应用程序在多种不同的机器上运行：客户端、Web服务器、数据库服务器和应用服务器。而且，因为他们一般可以让所有的人使用，所以这些应用程序成为了众多攻击活动的后台旁路。
　　由于Web服务器提供了几种不同的方式将请求转发给应用服务器，并将修改过的或新的网页发回给最终用户，这使得非法闯入网络变得更加容易。

　　而且，许多程序员不知道如何开发安全的应用程序。他们的经验也许是开发独立应用程序或Intranet Web应用程序，这些应用程序没有考虑到在安全缺陷被利用时可能会出现灾难性后果。

　　其次，许多Web应用程序容易受到通过服务器、应用程序和内部已开发的代码进行的攻击。这些攻击行动直接通过了周边防火墙安全措施，因为端口80或443（SSL，安全套接字协议层）必须开放，以便让应用程序正常运行。Web应用程序攻击包括对应用程序本身的DoS（拒绝服务）攻击、改变网页内容以及盗走企业的关键信息或用户信息等。

　　总之，Web应用攻击之所以与其他攻击不同，是因为它们很难被发现，而且可能来自任何在线用户，甚至是经过验证的用户。迄今为止，该方面尚未受到重视，因为企业用户主要使用防火墙和入侵检测解决方案来保护其网络的安全，而防火墙和入侵检测解决方案发现不了Web攻击行动。

　　常见的Web应用安全漏洞

　　下面将列出一系列通常会出现的安全漏洞并且简单解释一下这些漏洞是如何产生的。

　　已知弱点和错误配置

　　已知弱点包括Web应用使用的操作系统和第三方应用程序中的所有程序错误或者可以被利用的漏洞。这个问题也涉及到错误配置，包含有不安全的默认设置或管理员没有进行安全配置的应用程序。一个很好的例子就是你的Web服务器被配置成可以让任何用户从系统上的任何目录路径通过，这样可能会导致泄露存储在Web服务器上的一些敏感信息，如口令、源代码或客户信息等。

　　隐藏字段

　　在许多应用中，隐藏的HTML格式字段被用来保存系统口令或商品价格。尽管其名称如此，但这些字段并不是很隐蔽的，任何在网页上执行“查看源代码”的人都能看见。许多Web应用允许恶意的用户修改HTML源文件中的这些字段，为他们提供了以极小成本或无需成本购买商品的机会。这些攻击行动之所以成功，是因为大多数应用没有对返回网页进行验证；相反，它们认为输入数据和输出数据是一样的。

后门和调试漏洞


　　开发人员常常建立一些后门并依靠调试来排除应用程序的故障。在开发过程中这样做可以，但这些安全漏洞经常被留在一些放在Internet上的最终应用中。一些常见的后门使用户不用口令就可以登录或者访问允许直接进行应用配置的特殊URL。 

　　跨站点脚本编写

　　一般来说，跨站点编写脚本是将代码插入由另一个源发送的网页之中的过程。利用跨站点编写脚本的一种方式是通过HTML格式，将信息帖到公告牌上就是跨站点脚本编写的一个很好范例。恶意的用户会在公告牌上帖上包含有恶意的Javascrīpt代码的信息。当用户查看这个公告牌时，服务器就会发送HTML与这个恶意的用户代码一起显示。客户端的浏览器会执行该代码，因为它认为这是来自Web服务器的有效代码。

　　参数篡改

　　参数篡改包括操纵URL字符串，以检索用户以其他方式得不到的信息。访问Web应用的后端数据库是通过常常包含在URL中的SQL调用来进行的。恶意的用户可以操纵SQL代码，以便将来有可能检索一份包含所有用户、口令、信用卡号的清单或者储存在数据库中的任何其他数据。

　　更改cookie

　　更改cookie指的是修改存储在cookie中的数据。网站常常将一些包括用户ID、口令、帐号等的cookie存储到用户系统上。通过改变这些值，恶意的用户就可以访问不属于他们的帐户。攻击者也可以窃取用户的cookie并访问用户的帐户，而不必输入ID和口令或进行其他验证。

　　输入信息控制

　　输入信息检查包括能够通过控制由CGI脚本处理的HTML格式中的输入信息来运行系统命令。例如，使用CGI脚本向另一个用户发送信息的形式可以被攻击者控制来将服务器的口令文件邮寄给恶意的用户或者删除系统上的所有文件。

缓冲区溢出

　　缓冲区溢出是恶意的用户向服务器发送大量数据以使系统瘫痪的典型攻击手段。该系统包括存储这些数据的预置缓冲区。如果所收到的数据量大于缓冲区，则部分数据就会溢出到堆栈中。如果这些数据是代码，系统随后就会执行溢出到堆栈上的任何代码。Web应用缓冲区溢出攻击的典型例子也涉及到HTML文件。如果HTML文件上的一个字段中的数据足够的大，它就能创造一个缓冲器溢出条件。

　　直接访问浏览

　　直接访问浏览指直接访问应该需要验证的网页。没有正确配置的Web应用程序可以让恶意的用户直接访问包括有敏感信息的URL或者使提供收费网页的公司丧失收入。

　　Web应用安全两步走

　　Web应用攻击能够给企业的财产、资源和声誉造成重大破坏。虽然Web应用增加了企业受攻击的危险，但有许多方法可以帮助减轻这一危险。首先，必须教育开发人员了解安全编码方法。仅此项步骤就会消除大部分Web应用的安全问题。其次，坚持跟上所有厂商的最新安全补丁程序。如果不对已知的缺陷进行修补，和特洛伊木马一样，攻击者就能很容易地利用你的Web应用程序穿过防火墙访问Web服务器、数据库服务器、应用服务器等等。将这两项步骤结合起来，就会大大减少Web应用受到攻击的风险。同时管理人员必须采取严格措施，以保证不让任何东西从这些中溜过去

 

对于企业应用程序，有许多进行性能测试的方法，其中一些方法实行起来要比其他方法困难。所要进行的性能测试的类型取决于想要达到的结果。例如，对于可再现性，基准测试是最好的方法。而要从当前用户负载的角度测试系统的上限，则应该使用容量规划测试。本文将介绍几种设置和运行性能测试的方法，并讨论这些方法的区别。 目录 简介... 1 基准测试... 2 testceo.com.. 4 性能规划测试... 8 渗入测试... 11 峰谷测试... 11 结束语... 12   简介 　　如果不进行合理的规划，对J2EE应用程序进行性能测试将会是一项令人望而生畏且有些混乱的任务。因为对于任何的软件开发流程，都必须收集需求、理解业务需要，并在进行实际测试之前设计出正式的进度表。性能测试的需求由业务需要驱动，并由一组用例阐明。这些用例可以基于历史数据（例如，服务器一周的负载模式）或预测的近似值。弄清楚需要测试的内容之后，就需要知道如何进行测试了。 　　在开发阶段前期，应该使用基准测试来确定应用程序中是否出现性能倒退。基准测试可以在一个相对短的时间内收集可重复的结果。进行基准测试的最好方法是，每次测试改变一个且只改变一个参数。例如，如果想知道增加JVM内存是否会影响应用程序的性能，就逐次递增JVM内存（例如，从1024 MB增至1224 MB，然后是1524 MB，最后是2024 MB），在每个阶段收集结果和环境数据，记录信息，然后转到下一阶段。这样在分析测试结果时就有迹可循。下一小节我将介绍什么是基准测试，以及运行基准测试的最佳参数。 　　开发阶段后期，在应用程序中的bug已经被解决，应用程序达到一种稳定状态之后，可以运行更为复杂的测试，确定系统在不同的负载模式下的表现。这些测试被称为容量规划测试、渗入测试(soak test)、峰谷测试(peak-rest test)，它们旨在通过测试应用程序的可靠性、健壮性和可伸缩性来测试接近于现实世界的场景。对于下面的描述应该从抽象的意义上理解，因为每个应用程序的使用模式都是不同的。例如，容量规划测试通常都使用较缓慢的ramp-up（下文有定义），但是如果应用程序在一天之中的某个时段中有快速突发的流量，那么自然应该修改测试以反映这种情况。但是，要记住，因为更改了测试参数（比如ramp-up周期或用户的考虑时间(think-time)），测试的结果肯定也会改变。一个不错的方法是，运行一系列的基准测试，确立一个已知的可控环境，然后再对变化进行比较。 基准测试 　　基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处：减少重新运行测试的次数；对测试的产品和产生的数字更为确信。使用的性能测试工具可能会对测试结果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量，它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响：同时与服务器通信的连接（或虚拟用户）的数目，以及每个虚拟用户请求之间的考虑时间的长短。很明显，与服务器通信的用户越多，负载就越大。同样，请求之间的考虑时间越短，负载也越大。这两个因素的不同组合会产生不同的服务器负载等级。记住，随着服务器上负载的增加，吞吐量会不断攀升，直到到达一个点。 图1.随着负载的增加，系统吞吐量的曲线（单位：页面/秒） 　　注意，吞吐量以稳定的速度增长，然后在某一个点上稳定下来。 　　在某一点上，执行队列开始增长，因为服务器上所有的线程都已投入使用，传入的请求不再被立即处理，而是放入队列中，当线程空闲时再处理。 图2. 随着负载的增加，系统执行队列长度的曲线 　　注意，最初的一段时间，执行队列的长度为零，然后就开始以稳定的速度增长。这是因为系统中的负载在稳定增长，虽然最初系统有足够的空闲线程去处理增加的负载，最终它还是不能承受，而必须将其排入队列。

testceo.com

 

　　当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。但是，随着服务器负载的继续增长，系统的响应时间也随之延长，虽然吞吐量保持稳定。

图3. 随着负载的增加，系统中两个事务的响应时间曲线

　　注意，在执行队列（图2）开始增长的同时，响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。

　　为了获得真正可再现的结果，应该将系统置于相同的高负载下。为此，与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚拟用户）数保持一致，基准测试的结果应该会非常精确，完全可以再现。

　　您可能要问的一个问题是：“如何度量结果？”对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。这称为“flat”测试。

图4. flat测试的情况（所有的用户都是同时加载的）

　　与此相对应的是“ramp-up”测试。

图5. ramp-up测试的情况（在测试期间，用户以稳定速度（每秒x个）增加）

　　ramp-up测试中的用户是交错上升的（每几秒增加一些新用户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。因此，flat运行是获得基准测试数据的理想模式。

　　这不是在贬低ramp-up测试的价值。实际上，ramp-up测试对找出以后要运行的flat测试的范围非常有用。ramp-up测试的优点是，可以看出随着系统负载的改变，测量值是如何改变的。然后可以据此选择以后要运行的flat测试的范围。

　　Flat测试的问题是系统会遇到“波动”效果。

图6. 一次flat测试中所测得的系统吞吐量的曲线（单位：页面/秒）

　　注意波动的出现，吞吐量不再是平滑的。

　　这在系统的各个方面都有所体现，包括CPU的使用量。

图7. 一次flat测试中所测得的系统CPU使用量随时间变化的曲线

　　注意，每隔一段时间就会出现一个波形。CPU使用量不再是平滑的，而是有了像吞吐量图那样的尖峰。

　　此外，执行队列也承受着不稳定的负载，因此可以看到，随着系统负载的增加和减少，执行队列也在增长和缩减。

图8. 一次flat测试中所测得的系统执行队列的曲线

　　注意，每隔一段时间就会出现一个波形。执行队列曲线与上面的CPU使用量图非常相似。

　　最后，系统中事务的响应时间也遵循着这个波动模式。

 

图9. 一次flat测试中所测得的系统事务的响应时间

　　注意，每隔一段时间就会出现一个波形。事务的响应时间也与上面的图类似，只不过其效果随着时间的推移逐渐减弱。

　　当测试中所有的用户都同时执行几乎相同的操作时，就会发生这种现象。这将会产生非常不可靠和不精确的结果，所以必须采取一些措施防止这种情况的出现。有两种方法可以从这种类型的结果中获得精确的测量值。如果测试可以运行相当长的时间（有时是几个小时，取决于用户的操作持续的时间），最后由于随机事件的本性使然，服务器的吞吐量会被“拉平”。或者，可以只选取波形中两个平息点之间的测量值。该方法的缺点是可以捕获数据的时间非常短。

性能规划测试

　　对于性能规划类型的测试来说，其目标是找出，在特定的环境下，给定应用程序的性能可以达到何种程度。此时可重现性就不如在基准测试中那么重要了，因为测试中通常都会有随机因子。引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。通常，具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。例如，您可能想知道：如果要以 查看(909) 评论(0) 收藏 分享 管理

流媒体服务器作为为用户提供服务的基本功能单元，其性能的高低直接影响到流媒体系统的服务能力。在衡量流媒体服务器时，最关键的指标是流输出能力和能同时支持的并发请求数量，下面我们以本地硬盘作为存储介质的流媒体服务器为例，首先对其工作过程进行简单的分析：

（1）从硬盘盘碟中分段读取流媒体文件内容，经过硬盘接口电路（SCSI、IDE）、PCI总线和系统内部总线存储到内存中（途中经过硬盘控制卡和PCI控制器两个转换接口）。

（2）在流媒体文件被发送到网络上之前，CPU需要对内存中的流媒体文件片段进行一些处理，例如，复制、切分、按协议打包等。

（3）打包之后的文件内容在内存中通过系统内部总线、PCI控制器、PCI总线到达网卡。

（4）网卡将文件内容再一次包装后发送到外部网络。

通过以上的分析可以看出，在硬件方面有四个影响到流媒体服务器性能的关键因素：CPU处理能力、内存、磁盘读取能力和网络吞吐率。（1）CPU处理能力

流媒体服务器的CPU主要进行内容文件的复制、切分和按协议打包等工作，并对用户发起的各种服务请求（如快进、快退、搜索等）进行响应和处理以及服务器列表信息的维护和检索等。

对CPU处理能力的要求，随着需要支持用户并发访问和服务数量的增长而提高，当并发用户数越多，点播的节目越分散，对CPU的处理要求越高。当进行直播或用户点播单一文件时，服务器为用户提供的内容都是相同的，只需要读取一份源内容，然后进行内容的复制、分发操作；而当用户点播不同的节目时，不仅要进行内容的分发操作，还需要从多个节目源中取内容，进行更多的磁盘读取和内容读写操作，需要启动更多的进程，每个进程分配的时间片变小，并需要增加更多的进程切换操作。因此同样配置的服务器，用于直播服务的可以同时为几千个用户服务，但用于点播服务时，则只能为几百个用户提供服务。

另外，在流媒体服务的不同阶段，CPU的负荷也是不同的。在流媒体连接建立初始阶段，除正常的文件复制、切分和协议打包工作外，会有更多的交互请求需要处理，而且为减少用户等待缓存的时间，有些系统会在短时间内提高文件传输速度，这就导致更多的文件读取和处理工作，要比平稳连接阶段更耗费资源。

（2）对原始数据的读取能力

原始流媒体文件的存放方式主要有本地硬盘、NAS或SAN存储设备几种。不论那种数据存储方式，原始数据文件的读取能力都将直接影响到服务器的性能。对读取能力的要求，与业务类型和用户请求的数量有很大的关系。直播对于数据读取速率的要求最低，不过它需要为多少用户提供服务，只需从数据源取一份数据，然后进行复制；但是，点播则需要为每个用户读取不同的数据源，对数据源的读取压力大得多。

原始数据的读取能力是流媒体服务器最大的性能瓶颈，主要是受到存储设备的速度限制。目前主要采用两种解决方法：一是采用Raid技术和磁盘阵列，提高硬件速度，不过价格较高；另一种方法是采用文件缓存技术，如果几个用户点播同一个节目，就可以从缓存中而不是存储设备中读取数据，减少存储设备压力。不过这种方法效果有限，随着点播用户请求数的增长，用户点播的节目会越来越分散，在缓存中命中的比例就会逐步降低，当命中率降低到一定程度，起不到减轻存储设备读取压力的作用。

（3）内存

在流媒体服务器中，内存可以按其用途分为两大部分。一部分是为处理每个用户的流媒体请求和服务使用的内存，用户的平均内存使用率取决于流媒体内容的发布类型和编码设置，如比特率、包大小、音频流和视频流的数目等。根据用户行为、服务的目标用户数、用户请求连接流的分散率和发布点类型，可以估算出一个流媒体服务器需要使用多大的内存。

另一部分是用于缓存数据文件。当服务器处理、发送和从存储设备读取数据时，都需要通过内存进行内容缓存。当内存不足时，会出现内存分页现象。内存分页可能会造成无法预料的延迟。大物理内存可以将因内存分页而产生的延迟最小化，更多的内存可以提供更多的文件缓存，减少存储设备读取能力瓶颈造成的影响，提高服务器性能。

（4）网络吞吐率

服务器网络接口的服务能力影响到数据的传输，当网络带宽不足时，会导致数据收发延迟，导致用户服务中断。服务器的网络吞吐率只与用户数量和点播节目的编码率有关。

对于一个流媒体服务器来说，以上几个因素中的任何一个都会造成服务器无法正常工作。另外，各个性能因素和处理环节是相互联系、相互影响的。例如当内存不足时，会产生大量的内存分页操作，同时也会造成CPU的使用率很快上升到100%；增大内存，提高服务器内存缓存能力，还可以降低硬盘读取操作。因此，在进行服务器配置时，要尽量做到各方面的性能协调和匹配，各性能指标均衡，同时应考虑到不同组件的价格不同，比如存储设备价格较高，可相应配置较低的CPU和较大的内存，以提高设备的性价比。

软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合。正确认识和设计软件测试用例可以提高软件测试的有效性，便于测试质量的度量，增强测试过程的可管理性。

1、 性能测试的目的：通过测试确认软件是否满足产品的性能需求，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

　　2、 性能测试指标的来源：测试的依据是产品的需求规格说明书；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。

　　3、 性能测试的指标：服务器的各项指标（CPU使用率、内存占用率、硬盘占用率等）、后台数据库的各项指标和软件的响应时间：

　　　（1） 操作系统有关的指标：CPU平均利用率、内存平均占用率、硬盘占用率、I/O数量、网络时延

　　　（2） 数据库有关的指标：I/Owait、Mem平均使用率、cpu平均使用率、在一次I/O操作中所读的最大BLOCKS数、Log的增长情况、数据库的访问速度、数据库能支持的最大用户数、数据库CACHE命中率、不同数据库参数下的性能情况、锁的处理

　　　（3） 软件有关的指标：交易的平均响应时间（从接收请求到回复响应的时间）、每秒交易数量（单位时间里的执行次数）、对中间件功能的调用、远程处理延迟

　　4、 查看性能指标的命令和方法：

　　　vmstat：虚拟内存的统计（cpu/io）

　　　iostat：设备的IO统计

　　　netstat：网络活动信息统计

　　　top：内存统计

　　　cat /proc/meninfo：查看系统的总men大小

　　　cat /proc/cpuinfo：查看系统总CPU大小

　　　df –k：查看系统硬盘大小

　　　举例说明：

　　　（1）查看CPU使用情况的命令
　　每5秒刷新一次，最右侧有CPU的占用率的数据：$ vmstat 5
      top 然后按Shift+P，按照进程处理器占用率排序：$ top

　　　（2）查看内存使用情况的命令
　　用free命令查看内存占用情况：$ free
　　top 然后按Shift+M, 按照进程内存占用率排序：$ top

　　　（3）查看网络流量
　　可以用工具iptraf工具：$ iptraf -g
     针对某个Interface的网络流量可以通过比较两个时间网络接口的RX和TX数据来获得：$ date; ifconfig eth1或$ date; ifconfig eth1

　　（4）查看磁盘i/o
　　用iostat查看磁盘/dev/sdc3的磁盘i/o情况，每两秒刷新一次： iostat -d -x /dev/sdc3 2
　　用vmstat查看io部分的信息： vmstat 2

　　5、 常用的性能测试工具：
　　MI:Loadrunner,
　　Compuware:Qaload
　　Rational: Rational PerformanceStudio

　　6、 性能测试开始与结束时间：

　　开始：系统功能测试完成之后，如果某个功能修改比较大或增加新的功能，也应该重新进行性能测试。
　　结束：系统满足各项性能要求、能满足实际使用情况并提供测试报告。

　　7、 性能测试、压力测试、负载测试与容量测试：性能测试包括负载测试、压力测试和容量测试三种主要测试类型。

　　（1） 性能测试：在正常的负载和配置下程序的响应时间和吞吐率。性能数据的提取通常是通过不断调整压力来获得的。

　　（2） 压力测试：通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变，考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在，模拟巨大的工作负荷以查看应用程序在峰值使用情况下的处理能力和承受能力。通常是通过不断调整压力来提取系统的最优性能数据的。

　　（3） 负载测试：长时间在超负荷环境中运行，程序是否能够承担。这其实是长时间的大压力测试，主要检查系统的稳定性（比如程序在负载的时候是否会coredump）以及系统的资源占用情况是否合理（是否出现内容泄露或CPU爆涨或某资源使用之后不释放）或者是否会出现异常（比如系统不能正常运行）。

　　（4） 容量测试：使程序经受大容量数据处理的检验，一般地说针对数据库而言，是在数据库中有较大数量的数据记录情况下对系统进行的测试。

　　8、 性能测试方案的要素：

　　（1） 确定性能指标

　　（2） 设计测试场景

　　（3） 确定需要测试收集的数据

　　（4） 确定测试方法

　　（5） 确定测试步骤

　　9、性能调优工作的准备

　　（1）收集系统信息

　　A、 主要的服务或者应用
　　B、 用户数及使用方式
　　C、 系统有哪些进程，都在干什么，使用了多少cpu、mem
　　D、 系统配置情况：cpu、mem、disk(连接方式RAID)及其占用情况
　　E、 最近所做的改动（硬件、软件、内核）

　　（2）判别性能瓶颈

在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
本文将 web 测试分为 6 个部分：
1.       功能测试 
2.       性能测试（包括负载/压力测试）
3.       用户界面测试
4.       兼容性测试
5.       安全测试
6.       接口测试 
本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。
1 功能测试
1.1 链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。 
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
采取措施：采用自动检测网站链接的软件来进行。
推荐软件：
Xenu Link Sleuth 免费 绿色免安装软件
HTML Link Validator 共享（30天试用）
1.2 表单测试 
当用户通过表单提交信息的时候，都希望表单能正常工作。
如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。
当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
1.3 数据校验
如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。
在测试表单时，该项测试和表单测试可能会有一些重复。
1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。
1.4 cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。 
　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。
采取措施：
     1 采用黑盒测试：采用上面提到的方法进行测试
2 采用查看cookies的软件进行（初步的想法）
可以选择采用的软件
IECookiesView v1.50 
Cookies Manager v1.1
1.5 数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
采取措施：暂时没有更好的测试方法
     考虑结合到1.2和1.3的测试中
1.6 应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。
采取措施：深刻理解需求说明文档
1.7 设计语言测试 
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。
暂时没有方法测试，可以多参考一点讨论组内的更新信息
 
2 性能测试 
2.1 连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。 
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。 
2.2 负载测试 
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？ 
2.3 压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。 
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
负载/压力测试应该关注什么
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。
瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。
每个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?
长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。
采取措施：采用测试工具WAS、ACT协助进行测试
 
3 用户界面测试 
3.1 导航测试 
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。 
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。 
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。 
3.2 图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有： 
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到 30k 以下
（5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。
3.3内容测试 
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。
对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。
3.4 表格测试 
需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长?
3.5 整体界面测试 
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？ 
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的用户界面测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
采取措施：手动测试，参与人员最好有外部人员
 
4 兼容性测试 
4.1 平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。 
4.2 浏览器测试 
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，Javascrīpt是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。 
4.3 分辨率测试
页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?
4.4 Modem/连接速率
是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。
4.5 打印机
用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。
4.6 组合测试
最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。
采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵
 
5 安全测试
即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
5.1 目录设置
Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。
5.2 SSL
很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？
5.3 登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗?  是否可以不登陆而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
5.4 日志文件
在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?
5.5 脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。　
 
6 接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
6.1服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
这种测试可以归到功能测试中的表单测试和数据校验测试中
6.2 外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
这种情况在远程抄表中可能会体现到
6.3 错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。
 
7 结论
　  无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。

性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

　　应用在客户端性能的测试

　　应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。

　　◆ 并发性能测试是重点

　　并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

　　并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

　　当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候,尤其是以后在生产环境中实际使用起来,用户往往会产生疑问,这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。

　　◆ 举例说明：电信计费软件

　　众所周知,每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步,首先要根据用户提出的电话号码来查询出其当月产生费用,然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤,但当成百上千的终端，同时执行这样的操作时，情况就大不一样了,如此众多的交易同时发生,对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力, 预见软件的并发承受力, 这是在软件测试阶段就应该解决的问题。

　　目前，大多数公司企业需要支持成百上千名用户，各类应用环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。

　　如何模拟实际情况呢? 找若干台电脑和同样数目的操作人员在同一时刻进行操作,然后拿秒表记录下反应时间？ 这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况,这样就需要压力测试工具的辅助。

　　测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。

　　◆ 并发性能测试前的准备工作

　　测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

　　一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。

　　测试工具：并发性能测试是在客户端执行的黑盒测试，一般不采用手工方式，而是利用工具采用自动化方式进行。目前，成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。

　　测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。

　　在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。

　　模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。

　　◆ 并发性能测试的种类与指标

　　并发性能测试的种类取决于并发性能测试工具监控的对象，以QALoad自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java scrīpt等不同的监控对象，支持Windows和UNIX测试环境。

　　最关键的仍然是测试过程中对监控对象的灵活应用，例如目前三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都采用了国产中间件，选择Java scrīpt监控对象，手工编写脚本，可以达到测试目的。

　　采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。

　　并发性能测试监控的对象不同，测试的主要指标也不相同，主要的测试指标包括交易处理性能指标和UNIX资源监控。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最小服务器响应时间；Mean：平均服务器响应时间；Max：最大服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大，偏差越大；Median：中值响应时间；90％：90％事务处理的服务器响应时间）、虚拟并发用户数。

　　应用实例：“新华社多媒体数据库 V1.0”性能测试

　　中国软件评测中心（CSTC）根据新华社技术局提出的《多媒体数据库（一期）性能测试需求》和GB/T 17544《软件包质量要求和测试》的国家标准，使用工业标准级负载测试工具对新华社使用的“新华社多媒体数据库 V1.0”进行了性能测试。

　　性能测试的目的是模拟多用户并发访问新华社多媒体数据库，执行关键检索业务，分析系统性能。

　　性能测试的重点是针对系统并发压力负载较大的主要检索业务，进行并发测试和疲劳测试，系统采用B/S运行模式。并发测试设计了特定时间段内分别在中文库、英文库、图片库中进行单检索词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳测试案例为在中文库中并发用户数200，进行测试周期约8小时的单检索词检索。在进行并发和疲劳测试的同时，监测的测试指标包括交易处理性能以及UNIX（Linux）、Oracle、Apache资源等。

　　测试结论：在新华社机房测试环境和内网测试环境中，100M带宽情况下，针对规定的各并发测试案例，系统能够承受并发用户数为200的负载压力，最大交易数/分钟达到78.73，运行基本稳定，但随着负载压力增大，系统性能有所衰减。

　　系统能够承受200并发用户数持续周期约8小时的疲劳压力，基本能够稳定运行。

　　通过对系统UNIX（Linux）、Oracle和Apache资源的监控，系统资源能够满足上述并发和疲劳性能需求，且系统硬件资源尚有较大利用余地。

　　当并发用户数超过200时，监控到HTTP 500、connect和超时错误，且Web服务器报内存溢出错误，系统应进一步提高性能，以支持更大并发用户数。

　　建议进一步优化软件系统，充分利用硬件资源，缩短交易响应时间。

　　◆ 疲劳强度与大数据量测试

　　疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。

　　疲劳强度测试可以采用工具自动化的方式进行测试，也可以手工编写程序测试，其中后者占的比例较大。

　　一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。

　　大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。

　　速度测试目前主要是针对关键有速度要求的业务进行手工测速度，可以在多次测试的基础上求平均值，可以和工具测得的响应时间等指标做对比分析。

　　应用在网络上性能的测试

　　应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。

　　◆ 网络应用性能分析

　　网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，例如Application Expert，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间；利用Application Expert调整应用在广域网上的性能；Application Expert能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。

　　◆ 网络应用性能监控

　　在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是Network Vantage。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。

　　◆ 网络预测

　　考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。

　　从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可人工生成流量数据），这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。 PREDICTOR提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。

　　应用在服务器上性能的测试

　　对于应用在服务器上性能的测试，可以采用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控，测试原理如下图。

　　(暂时略）

　　图：应用在服务器上的性能测试原理图

　　UNIX资源监控指标和描述

　　监控指标 描述

　　平均负载 系统正常状态下，最后60秒同步进程的

　　平均个数

　　冲突率 在以太网上监测到的每秒冲突数

　　进程/线程交换率 进程和线程之间每秒交换次数

　　CPU利用率 CPU占用率（％）

　　磁盘交换率 磁盘交换速率

　　接收包错误率 接收以太网数据包时每秒错误数

　　包输入率 每秒输入的以太网数据包数目

　　中断速率 CPU每秒处理的中断数

　　输出包错误率 发送以太网数据包时每秒错误数

　　包输入率 每秒输出的以太网数据包数目

　　读入内存页速率 物理内存中每秒读入内存页的数目

　　写出内存页速率 每秒从物理内存中写到页文件中的内存页数

　　目或者从物理内存中删掉的内存页数目

　　内存页交换速率 每秒写入内存页和从物理内存中读出页的个数

　　进程入交换率 交换区输入的进程数目

　　进程出交换率 交换区输出的进程数目

　　系统CPU利用率 系统的CPU占用率（％）

　　用户CPU利用率 用户模式下的CPU占用率（％）

　　磁盘阻塞 磁盘每秒阻塞的字节数

性能测试就是用来测试软件在系统中的运行性能的。 性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起之后，才能检查一个系统的真正性能。

     性能测试经常和压力测试一起进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要的在一种苛刻的环境中衡量资源的使用（比如，处理器周期）。外部的测试设备可以监测测试执行，当出现情况（如中断）时记录下来。通过对系统的检测，测试者可以发现导致效率降低和系统故障的原因。


    压力测试：对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。 

     性能测试：在交替进行负荷和强迫测试时常用的术语。 性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该于性能测试一同进行。
    举例说明：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。

     性能测试(Performance) 正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间,在可以接受范围内.J2EE技术实现的系统在性能方面更是需要照顾的,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了. 如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题

    压力测试 (Stress) 多用户情况可以考虑使用压力测试工具,建议将压力和 性能测试结合起来进行.如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况, 如果有必要可以模拟大量数据输入,对硬盘的影响等等信息.如果有必要的话必须进行性能优化(软硬件都可以).

    压力测试和性能的测试的区别是在于他们不同的测试目的

    压力测试是为了发现系统能支持的最大负载，他的前提是要求系统性能处在可以接受的范围内，比如经常规定的叶面3秒钟内响应；
所以一句话概括就是：在性能可以接受的前提下，测试系统可以支持的最大负载。

     性能测试是为了检查系统的反映，运行速度等性能指标，他的前提是要求在一定负载下，如检查一个网站在100人同时在线的情况下的性能指标，每个用户是否都还可以正常的完成操作等。
概括就是：在不同负载下（负载一定）时，通过一些系统参数（如反应时间等）检查系统的运行情况；
比如我们说某个网站的性能差，严格上应该说‘在N人同时在线情况下，这个站点性能很差）

    总之，就像一个方程式：综合性能=压力数*性能指数，
    综合性能是固定的：
    压力测试是为了得到性能指数最小时候（可以接受的最小指数）最大的压力数
     性能测试是为了得到压力数确定下的性能指数

通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认在实际运行时，它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患。为此，对完成开发的软件必须经过规范的系统测试。换个角度说，开发完成的软件仅仅是实际投入使用系统的一个组成部分，需要测试它与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能正常工作。　　

    系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考OOA分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全“再现”问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。

    这里说的系统测试是对测试步骤的抽象描述。它体现的具体测试内容包括：

    ·功能测试：测试是否满足开发要求，是否能够提供设计所描述的功能，是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试，通常还会以正式的软件说明书为测试标准。

    ·强度测试：测试系统的能力最高实际限度，即软件在一些超负荷的情况，功能实现情况。如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库大量复杂的查询等。

    ·性能测试：测试软件的运行性能。这种测试常常与强度测试结合进行，需要事先对被测软件提出性能指标，如传输连接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。

    ·安全测试：验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。安全测试时需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。

    ·恢复测试：采用人工的干扰使软件出错，中断使用，检测系统的恢复能力，特别是通讯系统。恢复测试时，应该参考性能测试的相关测试指标。

    ·可用性测试：测试用户是否能够满意使用。具体体现为操作是否方便，用户界面是否友好等。

    ·安装/卸载测试（install/uninstall test）等等。

    系统测试需要对被测的软件结合需求分析做仔细的测试分析，建立测试用例。

创建和使用随机测试用例数据是一项基本的软件测试技能。尽管多数测试用例数据由所测试系统的特定输入数据以及特定预期值/状态组成，但您几乎始终都想让系统也受到随机测试用例输入数据的测试。通常，您这样做是为了了解向应用程序发送大量不同的输入数据是否会导致系统崩溃或引发异常。

在本月的专栏中，我将阐述在 Microsoft? .NET Framework 环境中处理随机测试用例数据时的四个常见任务：

生成伪随机数字（Knuth 算法）

分析模式随机性（Wald-Wolfowitz 检验）

混排项目列表（Fisher-Yates 算法）

生成高斯数字（Box-Muller 算法）

让我们看一下图 1 中的示例。输出的第一部分显示了使用 .NET Framework 的 Random 对象生成基本随机数字的结果。尽管您可能很熟悉此方法，但我还是要指出如何避免常见缺陷。输出的第二部分体现了一个非常实用但却鲜为人知的方法，该方法用来分析由任意符号组成的模式是否具备随机性。通常，该方法广泛应用于软件开发中，而不只是应用于测试方面。图 1 的第三部分表明了混排项目列表的结果，该结果异常错综复杂。

我将详细说明为什么许多混排实现方法表面上似乎正确，而事实上却完全错误。图 1 中输出的最后一部分表明了生成按正态钟形曲线分布的一组数字的结果。除了是一种非常实用的方法之外，该算法的实现细节凭其自身的性能而得以关注，将成为您个人编码工具箱的一个有价值的补充部分。

生成统一的随机数字

随机测试用例生成中的最基本任务是生成一个某特定值域内的随机数字（整数或浮点数）。这通常通过 System.Random 类来实现。假定有以下代码：

Random ōbjRan = new Random(5);

int n = objRan.Next(7);

Console.WriteLine("[0,6] 值域中的随机整数是 " + n);

n = objRan.Next(3, 13);

Console.WriteLine("[3,12] 值域中的随机整数是 " + n);

以 Random 对象为例，传入一个种子值（在本例中为 5）。该种子值用于为表现出真正随机数字许多特性的某个数字序列设置起点。序列是确定的（这些数字是从输入种子值或序列中前几个数字时所用的数学公式而生成），因此由 System.Random 生成的数字从技术角度来讲是伪随机数字，但在非正式使用情况下或上下文明确时，通常将其称为随机数字（如此例所示）。我选择的种子值具有任意性。如果我使用不接受种子值的重载 Random 构造函数，则将使用从系统时钟派生的值。如果在随后测试运行时，您需要重新创建随机数字序列（通常情况是这样），则应提供一个种子值。有关伪随机数字生成器种子值的讨论是一个重要且复杂的主题，抱歉的是，它不在本专栏的讨论范围内。

生成随机整数的最简单方法是调用 Random.Next 方法，传入单个整数参数。返回值是伪随机列表中的下一个整数，此值大于或等于 0 且绝对小于该参数。因此，以下调用将返回一个介于 0 和 9 之间（包括 0 和 9）而不是介于 0 和 10 之间（包括 0 和 10）的数字：

int n = objRan.Next(10);

Random.Next 方法的重载将接受两个整数参数并返回一个大于或等于第一个参数且绝对小于第二个参数的整数。如果您要模拟的测试用例数据类似于滚动的普通六面骰子，要得到一个介于 1 和 6 之间（包括 1 和 6）的随机数字，则调用可能如下所示：

int roll = objRan.Next(1, 7);

这很容易从某数组生成一个随机选取项：

string[] items = new string[] { "alpha", "beta", "gamma", "delta" };

Console.WriteLine("{ 'alpha', 'beta', 'gamma', 'delta' } 的" +

    "随机成员是 " +

    items[objRan.Next(items.Length)] );

如果数组大小为 N，则调用 objRan.Next(N) 所生成的返回值将是值域 [0, N-1] 内的一个整数（该值域完全对应于数组的索引值）。请注意，该方法也可用于 ArrayList 对象，而且事实上也可用于任何以 0 为基数的索引化集合。