Web管理软件服务器平台测式

前几章已经谈论了测试的一些理论和实际应用。下面开始介绍Web管理软件测试的一些基础知识。本章介绍的主要内容有Web管理软件测试入门，客户端测试，服务端测试。一项工作能否有良好的开端，很大程度上取决于它的前期准备工作。

1．1．1Web管理软件测试概述

1．1Web管理软件测试入门

随着网络技术的迅速发展，尤其是web及其应用程序的普及，各类基于Web的应用程序以其方便、快速、易操作等特点不断成为软件开发的重点。Web以其广泛性、交互性和易用性等特点迅速风靡世界，网页数量正以几何数量级飞速增长。能够吸引尽可能多的用户并对其长时间关注是网站追求的主要目标，也是衡量一个网站是否成功的主要指标，这就对网页功能的正确性、有效性和完善性提出了较高的要求，从而测试就成为应用开发过程中的一个重要环节。

目前可以见到各种Web服务器平台，然而根据Mereur的研究报告，98％的Web服务器都没能达到人们所期望的性能，平均只能发挥人们所期望性能的1／6左右。Web性能测试能够确定影响Web服务器性能的关键因素，从而可以有针对性地进行分析和改进，避免Web服务器研究和优化过程中的盲目行为；同时，它也是选取不同的Web服务器的重要参考。

随着Web应用程序使用越来越广泛，针对其性能测试的要求也越来越多，然而由于Web程序综合了大量的新技术，诸如HTML，Java，JavaSeript，VBScript等，同时它还依赖很多其他的因素，比如Link，Database，Network等，使得web应用程序测试变得非常复杂。例如：Web压力测试是评价一个Web应用程序的主要手段，它的测试就是一个代表性的方面。很多公司应用的架构都以B／S或Web应用为主，新的模式解决方案中以Web为核心的应用也越来越多。由于Web应用与用户直接相关，又通常需要承受长时间的大量操作，因此Web项目的功能和性能都必须经过可靠的验证，即Web项目要经过全面测试。但是，基于Web的测试与传统的软件测试不同，它不仅需要检查和验证软件是否按照设计的要求运行，而且还要检测其在不同用户浏览器端的显示是否合适。最关键的是，要从最终用户的角度进行安全性和可用性等方面的测试。通过测试尽可能多地发现浏览器端和服务器端程序中的错误并及时加以修正，以保证应用的质量。由于Web具有分布、异构、并发和平台无关的特性，因而其测试要比普通程序的测试复杂得多。

1．1．2Web应用体系结构

可以把Web看成是一个使用方便、接受全局访问、具有图形化界面的大的数据库前端，其结构示意图如图1．1所示。由于应用具有多层体系结构。客户、数据通信、硬件以及服务器之间的依赖关系又非常复杂，因而在每层内以及各层间都有可能发生故障。在客户机端，由于浏览器的型号、版本有很大的不同，以及对应的显示技术各不相同，有些信息往往不能正常地显示，从而产生兼容性问题以及显示故障。在服务器端，可能存在超链接不可达或者根本不存在的问题，影响用户的使用和评价服务器；数据库的负载能力有限，在用户访问达到高峰时，响应时间太长甚至不接受用户的访问；并发用户的行为会影响到与站点交互的情况，用户之间也可能相互干扰。Web应用程序采用B／S结构，它是伴随着Internet技术的不断进步，由C／S结构改进和发展起来的新型体系结构。在这种结构下，用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑则在服务器端实现，形成所谓3tier结构。B／S结构利用不断成熟和普及的浏览器技术实现原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。这种结构更成为当今应用软件开发的首选体系结构，目前最流行的microsoft．net也是在这样一种背景下被提出来的架构。

传统的软件一般采用c／s结构，此结构把数据库内容放在远程的服务器上，而在客户机上安装相应软件。c／s软件一般采用两层结构，c／s结构在技术上很成熟，它的主要特点是交互性强、具有安全的存取模式、网络通信量低、响应速度快、利于处理大量数据。但是该结构的程序是针对性开发，变更不够灵活，维护和管理的难度较大。

1．1．3Web管理软件测试指标

在进行Web管理软件测试之前需要一些资料，比如产品功能说明书和性能需求说明书，不一定很完善，但一定要有明确的测试目标，这是Web管理软件测试的前提。

1．通用指标

通用指标是指Web应用服务器、数据库服务器必需测试项，包括：

(1)处理器时间：指服务器CPU占用率，一般平均达到70％时，服务就接近饱和。

(2)可用内存数：如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重。

(3)物理磁盘读写时间。

2．Web服务器指标

(1)平均每秒响应次数为总请求时间与秒数之比。

(2)平均每秒业务脚本的迭代次数。

(3)成功的请求和失败的请求。

(4)成功的点击次数和失败的点击次数。

(5)每秒点击次数、每秒成功的点击次数和每秒失败的点击次数。

(6)尝试连接数。

3．数据库服务器指标

(1)用户连接数，也就是数据库的连接数量。

(2)数据库死锁量。

(3)数据库缓存的命中情况。

以上指标只是一些通用指标，对于不同的应用还需作相应的调整，比如程序使用的是．NET技术，则必须加入一些针对性的测试指标。对于这些指标的详细了解，可以参考Win—dows下面的SystemMonitor的帮助与LoadRunner和ACT的帮助。

1．1．4Web管理软件测试的内容与目的

在很多时候都把测试的目的定位为寻找软件的Bug，而且是尽可能地找出Bug来，而测试人员所做的事情就是找软件的毛病，只要找出毛病就可以了，这样很容易带来一系列的问题。比如测试人员给某网站做测试，并递交了一份简单的测试报告：“当100个用户共同按某提交按钮时，发生大量的提交失败”。对于测试人员来说，他已经完成了他自己的任务，找出了Bug，但是，这样的测试报告对于开发人员和项目管理者却毫无用处。报告中并未提及造成提交失败的原因。

测试的目的是证伪，但不能片面地理解为简单地找Bug就可以了。软件测试应该经历以下4个步骤：

(1)测试人员描述发现的问题(找到Bug)。

(2)测试人员详细阐明是在何种情况下测试发现的问题，包括测试的环境、输入的数据、发现问题的类型、问题的严重程度等情况。

(3)测试人员协同开发人员一起去分析Bug的原因，找出软件的缺陷所在。

(4)测试人员根据解决的情况进行分类汇总，以便日后进行软件设计的时候提供参考，避免以后出现类似软件缺陷。

1．1．5组织工作——矩阵

许多团队用一个矩阵来组织他们的Web应用程序测试工作，这个矩阵列出了使用的平台和浏览器，以及所涉及内容的详细描述，即在各种各样的平台组合中，用于发现问题和解决问题所需的时间和工作量。这个矩阵使得公司能够建议用户如何最好地使用网站或者网站可能在什么地方不受支持。由于目前可用平台和浏览器比较多，所有矩阵是相对庞大的，所以在测试时要合理选择平台和浏览器。

为了表明哪些平台和浏览器的组合可能被支持，可以创建一个矩阵，排除掉那些不存在的配对。这个矩阵可以这么表示：列表示浏览器，行表示操作系统。这样排列能够清晰地显示出所有能够测试的可能情况。表8—1就是一个例子。可能的平台和浏览器版本一旦确定，就可以填写这个矩阵，然后再根据其中的配对公司(或产品和网站)的重要性先后顺序进行处理。由于技术问题或国际化问题，你可能决定只支持一个浏览器或一个平台。例如，NetscapeNavigator3．0不支持框架，假如你的应用程序又依赖于框架，那么你可能提供一个替代的连接．让它指向非框架区，或者通知访问者最低的浏览器要求。在这种情况下，你还需要用你所不支持的主要浏览器对你的Web应用程序进行测试，以保证它们能够查看到你的应用程序使用的浏览器／平台的相关信息。PDA平台正在变得越来越实用化，但是需要特别注意PDA，因为它们的能力仍然有限。表8—2显示的是标明了测试重点的简单测试矩阵。

这种格式能轻易地确定出哪些平台需要测试，同时也显示出应该把精力集中在什么地方。这里可以用到的有符号、数字、颜色或其他适合于公司的鉴别方法。确定支持的不同层有助于确定覆盖范围和优先级。

从这个矩阵可以知道如何依照出现Bug的平台重要性排列Bug等级，并决定如何明智地把时间用在正确的地方。作为测试人员，在填写矩阵时会碰上的另外一个问题是：同一个操作系统下不能安装同一个浏览器的多个版本。较新版本的浏览器的安装会覆盖老版本的浏览器，同时也覆盖掉可能共用库，而这些库却是每个应用程序都可能用到的。这种情形听起来对于测试组是很昂贵的，因为这意味着需要许多机器，用于执行所用适当的测试。但是，如果给每个测试人员定一台主要的机器，再给每人一台装有多操作系统的机器，那么他们就能更容易地测试这个矩阵。此外，通过使用开关盒能够节省办公间并减少所需监视器的数目。要有效地测试Web应用程序，还有许多其他的因素要考虑。为了测试时能节省时间，并将宝贵时间用在正确的地方，测试人员应该在测试开始之前理解设计Web应用程序的一些概念。

1．1．6制定Web管理软件测试计划

当明确了测试的目的之后，真正开始针对一个Web应用程序进行测试的时候，需要制定一套详细的测试计划，这样才能顺利地完成所有的测试内容。计划的内容归纳为以下几步：

(1)首先对被测的Web应用程序进行需求分析，即对所做的测试作一个简要的介绍，包括描述测试的目标和范围，所测试的目标要实现一个什么样的功能，总结基本文档、主要活动。

(2)写出测试策略和方法，这里包括测试开始的条件、测试的类型、测试开始的标准以及所测试的功能、测试通过或失败的标准、结束测试的条件、测试过程中遇到什么样的情况终止和怎么处理后恢复等。

(3)确定测试环境的要求(包括软件和硬件方面)，选择合适的测试工具。

(4)主要针对测试的行为，描述测试的细节，包括测试用例表、进度表、错误等级分析、对测试计划的总结，以及在测试过程中会出现的风险分析等。

1．1．7Web管理软件测试类型

Web管理软件测试的类型包括内容测试、界面测试、功能测试、性能测试、兼容性测试、安全性测试等。内容测试、界面测试和兼容性测试都比较简单，在此不再细谈。Web的功能测试与传统的软件测试区别不大，主要是在连接测试方面有点区别，数据的传递方面会稍微复杂点。由于Web软件都是采用B／S结构，客户端所需的服务都是由服务器提供的，所以主要是测试服务器上软件运行的性能。Web应用程序的测试包括客户端连接服务器速度方面的测试和压力测试这两方面。性能测试的基本步骤如下：

(1)分析产品结构，明确性能测试的需求，包括并发、极限、配置和指标等方面的性能要求，必要时基于I。OAD测试的相同测试需同时考虑稳定性测试的需求。

(2)分析应用场景和用户数据，细分用户行为和相关的数据流，确定测试点或测试接口，列出系统接口的可能瓶颈，一般是先主干接口再支线接口，并完成初步的测试用例设计。

(3)依据性能测试需求和确定的测试点进行测试组网设计，并明确不同组网方案的重要程度或优先级作为取舍评估的依据，必要时在前期产品设计中提出支持性能测试的可测试性设计方案和对测试工具的需求。

(4)完成性能测试用例设计、分类选择和依据用户行为分析设计测试规程，并准备好测试用例将用到的测试数据。

(5)确定采用的测试工具。

(6)进行初验测试，以主干接口的可用性为主，根据测试结果分析性能瓶颈，通过迭代保证基本的指标等测试的环境。

(7)迭代进行全面的性能测试，完成计划中的性能测试用例的执行。

(8)完成性能测试评估报告。

1．功能测试

(1)链接测试。链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些未知地址的页面的主要手段。链接测试可分为3个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，亦即在整个Web应用系统的所有页面开发完成之后进行链接测试。

(2)表单测试。当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让用户收到信息。要测试这些程序，需要验证服务器是否能正确保存这些数据，而且后台运行的程序能否正确解释和使用这些信息。当用户使用表单进行用户注册、登录、信息提交等操作时，必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如，用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如，表单只能接受某些字符，测试时可采用的方法是先跳过这些字符，看系统是否会报错，从而完成验证。

(3)Cookie测试。Cookie通常用来存储用户信息和用户在某些应用系统的操作，当一个用户使用Cookie访问了某一个应用系统时，web服务器将发送关于用户的信息，把该信息以Cookie的形式存储在用户端计算机上，这可用来创建动态和自定义页面或者存储登录等信息。如果web应用系统使用了Cookie，就必须检查Cookie是否能正常工作。测试的内容可包括Cookie是否起作用、是否按预定的时间进行保存、刷新对Cookie有什么影响等。如果在Cookie中保存了注册信息，应确认该Cookie能够正常工作而且已对这些信息加密。如果使用Cookie来统计次数，需要验证次数累计是否正确。

(4)数据库测试。在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。在使用了数据库的Web应用系统中，一般情况下可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

2．性能测试

(1)连接速度测试。用户连接到web应用系统的速度根据上网方式的变化而变化，或许是电话拨号，或许是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5s)，用户就会因没有耐心等待而离开。另外，有些页面有超时的限制，如果响应速度太慢，用户可能还来不及浏览内容，就需要重新登录了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

(2)负载测试。负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如，Web应用系统能允许多少个用户同时在线?如果超过了这个数量，会出现什么现象?Web应用系统能否同时处理大量用户对同一个页面的请求?等等。负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为对于一个企业，其内部员工数量总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

(3)压力测试。压力测试的区域包括表单、登录和其他信息传输页面等。进行压力测试是指实际破坏一个Web应用系统，测试系统的反应。压力测试是测试系统的限制和故障恢复能力，也就是测试web应用系统会不会崩溃，在什么情况下会崩溃。在Internet上黑客攻击常采用的方式是：提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。因此，对应用系统的压力测试很有必要。

3．用户界面测试

(1)导航测试。导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题可以决定一个Web应用系统是否易于导航：导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致，确保用户能快速了解Web应用系统中是否还有内容以及内容的位置。Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

(2)图形测试。在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框颜色、字体、背景、按钮等。图形测试的内容有：

1)确保图形有明确的用途，图片或动画必须排列有序以节约传输时间。Web应用系统的图片尺寸要尽量小，并且能清楚地说明某件事情，一般都链接到某个具体的页面。

2)验证所有页面字体的风格是否一致。

3)背景颜色应该与字体颜色和前景颜色相搭配。

4)图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到30KB以下。

5)需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。

(3)内容测试。内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的，例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷。信息的准确性是指是否有语法或拼写错误，这种测试通常使用一些文字处理软件来进行，例如使用MicrosoftWord的“拼音与语法检查”功能。信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或人口，也就是一般Web站点中的所谓“相关文章列表”。

(4)整体界面测试。整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如，当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。对所有的用户界面测试来说，都需要有外部人员的参与，最好是让最终用户参与。

4．兼容性测试
(1)平台测试。市场上有很多不同的操作系统类型，最常见的有Windows，UNIX，Macin—tosh，Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。因此，在Web系统发布前，需要在各种操作系统下对Web系统进行兼容性测试。

(2)浏览器测试。浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，JavaScript，ActiveX，plug—ins或不同的HTML规格有不同的支持。例如。ActiveX是Mi—crosoft的产品，是为InternetExplorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品，等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不同。测试浏览器兼容性的一个方法是创建兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

(3)组合测试。最后需要进行组合测试。600像素×800像素的分辨率在MAC机上可能不错，但是在IBM兼容机上却很难看。在IBM机器上使用Netscape能正常显示，但却无法使用Lynx来浏览。如果是内部使用的Web站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用T1专线，可能不需要测试施加的下载。有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。

5．安全测试

安全测试是检验在系统中已存在的系统安全性、保密性措施是否发挥作用。它主要包括以下几个方面：

(1)目录设置：正确设置目录。

(2)SSL：使用SSL进行安全传送，确定是否有相应的替代页面。

(3)登录：验证系统阻止非法的用户名／口令登录。

(4)日志文件：注意验证服务器日志是否正常。

(5)脚本语言：脚本语言是常见的安全隐患。

6．接口测试

(1)服务器接口。第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

(2)外部接口。有些Web系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用Web接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用Visa卡和MasterCard卡，可以尝试使用Discover卡的数据(简单的客户端脚本能够在提交事务之前对代码进行识别，例如3表示AmericanExpress，4表示Visa，5表示MasterCard，6代表Discover)。通常，测试人员需要确认软件能够处理外部服务器返回的所有可能消息。

(3)错误处理。最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。可以尝试在处理过程中突然中断事务，看看会发生什么情况，看订单是否完成；或是尝试中断用户到服务器的网络连接，或者尝试中断web服务器到信用卡验证服务器的连接，在这些情况下，系统能否正确处理这些错误，是否已对信用卡进行收费。如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由服务提供商致电用户进行订单确认。

1．1．8Web应用程序测试技巧

有关Web管理软件测试的一件非常重要的事是，除非传输被加了密，否则，客户端与服务端之间的通信就可以像谈话被窃听一样被完全查看到。有许多工具可帮你做到这一点。微软有一个与SMS(SystemsManagementServer，系统管理服务器)一起发布的工具叫做NetworkMonitor(网络监视器)。它不但能查看本机的通信，而且能查看同一子网下所有机器的通信。任何种类的网络监视器或包嗅探器的真正用途不仅仅是查看数据流，而且还能够记录客户端的请求和服务器的响应，并将这些记录保存为文件，作为将来的参考。这些文件对于发现Web应用程序问题的根本原因和调试程序是至关重要的。包嗅探器是很神奇的工具，不但能让你对自己的应用程序有深入的了解，对于问题的调试也很有用。

1．包含支持文档

这些网络跟踪信息是能够被包含进Bug报告的支持文档中最有用的一部分。当发现Bug时，就应该把看到的错误用文本描述出来。有些情况下会有足够信息来诊断问题，但有时可能没有。在问题报告中加入合适的支持文档能节省大量的时间和精力。在看完你对所发现问题的描述之后，测试管理人员或开发人员打开支持文档，并迅速找出问题。清楚明了的跟踪报告可向开发人员迅速地指出问题所在。要注意只显示有用的信息，不要把不必要的信息也混进来。

2．处理缓存问题

对于Web管理软件测试，你面临的一个问题涉及缓存。浏览器将最近的信息放在缓存中。如果浏览器能判断Web服务器中相应的内容并没改变，它就使用缓存中的信息。对于用户来说，缓存使得浏览器速度更快，因为他们没必要每次都下载所有的东西。但是，对于测试人员来说，他希望从服务器中获取绝对最新的信息。如果缓存的内容可用并被取回，那么真正需要测试的信息并没有通过网络传输得到。
下面的步骤将引导你如何将缓存纳入考虑，并找出Web应用程序的问题。

(1)如果碰到脚本错误，要做的第一件事是看一下是否能重现脚本错误。

(2)要判断错误是否可以重新生成，关闭该类型浏览器的所有会话(如果运行的是IE，那就必须结束所有的IE会话)。

(3)打开一个浏览器窗口，删除所有缓存中的内容和本机备份(如果cookie可用的话，它也得删除)，然后再关闭浏览器。

(4)打开一个(且只能有一个)浏览器窗口，试着重现错误。

(5)如果成功的话，那就继续下一步。应该特别注意的是用于重现错误的步骤。要辨别出哪些动作与Bug有关，哪些动作与Bug无关是困难的。

(6)一旦确定重现错误的步骤，接着就要找出产生Bug的其他条件。至少至关重要的。如，错误是否只出现于Windows，或者只出现于Netscape，还是只出现于Windows2000之上的Netscape6．007

(7)一旦收集到理解问题的足够信息，下一步所要做的是查Bug数据库。仔细地找出与

所发现问题相匹配的Bug。

(8)如果找不到与问题相关的Bug，就自己输入。收集支持文档如屏幕截图、网络跟踪信息或其他信息有助于重现错误或调试。

(9)在保存Bug报告之前，对最近半个小时内输入的所有Bug作一下迅速查找，以防其他人与你输入一样的内容。许多测试人员都碰到过自己仔细记录的Bug在几分钟前刚被人输入的情况。只要做一下这样的检查就能够防止出现相同Bug的现象。

本章所介绍的这种处理方法只是通用的指导。要知道，所有的测试小组都有他们自己处理Bug的方法。要确保自己在开始处理错误之前就理解这些方法，否则，你就有可能会破坏了其他测试者、开发者或管理者的努力。

不能因为Bug无法重现就说它不是Bug。你和其他用户执行的一系列特定交互操作可以测试服务器出现期望之外的状态或罕见竞争条件。

虚假Bug的最大来源之一就是测试者没有清除缓存。缓存是一个与许多小组都相关的问题，然而，许多人并没意识到，他们正在受到缓存的影响。通常大家都知道浏览器的缓存可以手工清空。如果你正在测试一个因特网应用程序，那么就应该考虑到应用程序和用户之间的代理或防火墙问题。许多代理服务器是非常有用的，它能够缓存数据，有助于将网络通信流量减到最少。但是，它只是对用户有利，对于测试来说却并非如此。测试人员不会希望只是由于有代理服务器而导致取得版本不匹配的文件。如果代理服务器确实缓存数据，那么就要配置浏览器，使它在访问测试服务器时绕过代理。虽然如此，有关代理服务器和防火墙是如何影响用户的讨论还是应该在配置浏览器之前。

3．配置浏览器以用于Web应用程序设置

不可重现的Bug的另外一个来源是存在不支持的配置，如脚本选项关闭。默认情况下，IE禁止脚本调试，并且不向用户显示脚本错误。现在，由于这些错误是想要观察的，所以必须确认这些选项已经打开，并已经安装了脚本调试器。理想情况下，你所拥有的调试器和开发小组使用的一样。测试web应用程序不仅仅是验证所有活动链接和所有可显示图片。正如本节前面所说的，要进行测试验证的内容有许多，现在只是刚刚开始而已。应用程序的易用性、内容与设计、性能、安全性和国际化问题在本书的后续内容中都会陆续提到。本节只是对Web应用程序的手工测试验证过程作介绍性的讨论。有许多工具使得这些测试验证工作更容易、更迅速，让测试人员感觉他们是真正在测试而不仅是验证。然而，只有学会手工进行相应的测试，才能真正有效地利用工具来完成同样的测试工作。但是，一定记住，工具和检查清单最终还是无法代替知识丰富的测试人员。

1．1．9测试工具

Web管理软件测试工具很多，其中E—Test功能很强大，其采用的方式不是PostURL，因此可以支持多内码的测试数据，基本可以测试大部分的web站点。MicrosoftWebApplicationStressTool利用脚本回放来代替手工劳动，验证页面表单对各种输入的响应结果，同时也能够提供一定的性能测试结果。

PureLoad是一个很好的性能测试工具，完全用Java写成，可以测试各种c／s程序，如SMTPServer等。它和MicrosoftWebA．pplicationStressTool都使用PostURI。的方法测试Web项目，对大量使用JavaScript的页面不太适合。MI公司的winrunner，Compuware公司的qarun，Rational公司的SQArobot等可以用来做客户端的功能测试和服务器端的压力性能测试。也有一些工具是用来做测试流程管理的，比如TestPlanControl，testmanager等。

1．2-29．P，端测试

1．2．1测试HTML——静态Web上的设计

过去，人们常常在发现一个很酷或流行的站点后，只是复制一下该网站的格式或者代码。然而，如果一家公司正在设计一个在线零售业务并复制了一个流行的新闻站点，那么这个站点很可能不会很好地适用于这一目的。问题是，在这个例子中，设计和布局是与信息架构掺杂在一起的。第一个需要区别的是页面设计和内容组织，既然新闻站点内容的组织形式与电子商务的截然不同，再加上顾客的目的不同，因此不能只是把一个站点的设计强加到另一个来期望成功。为了更清楚地认识它们的不同之处，可以考虑以下内容：颜色选择、图片类型、元素在页面上的设置以及数据的基本布局，还有内容的组织和站点的信息架构。

信息架构是导航特性和内容的组合。但在顾客要求时，如果没能正确提供相应信息那就意味着Web表现的失败。进行设计的最好方法是收集内容，或者至少是关于内容的想法，然后首先组织这些信息。这一阶段可能需要与用户组进行交流，以便测试一些想法或者纸面上的设计原型，但这一阶段应该获得反馈信息，说明用户想要如何找出信息以及哪些信息对他们来说是最重要的。有了这一信息后，成功的设计就浮出水面了，或者至少受到一些影响。此外，也认识到它所受的一些限制。应该为内容牺牲图片设计。不管怎样，一定要获得好的内容。内容是使消费者再次光临站点的原因，而不是漂亮的色彩。应该避免用插件进行设计。迫使用户下载插件只会惹恼他们，从而阻止他们完成任务——很可能是为你出售的东西付钱。那为什么还要为这种购买设置障碍呢?只是让用户很容易完成这项任务就可以了。如果你提供的内容必须使用插件，就应该将该内容用多种形式表示出来。很多站点不仅陷入了设计陷阱，也陷入了动画陷阱。广告商引用这样的事实：用动画制作的广告拥有两倍于非动画广告的点击率。如果用户只是在网上无目的地冲浪。那么这个统计数字也站不住脚。如果站点主要用来提供信息，那么这个统计数字就站不住脚了。如果站点主要用来提供信息，在调查中我们看到很多用户故意阻止任何动画，甚至于把手放在屏幕上盖住动画部分，以便在阅读内容时不被打扰。Flash是一种web站点技术，它可能使得站点不可访问。在少数情况下，不同间隔出现的Flash可能会与资源占用联系在一起。屏幕上Flash的频率应该设为与光标闪烁速率相同，但为了保证绝对安全，应该避免使用Flash。

换句话说，就是要知道你在设计什么，并避免触怒用户。如果用户可以从其他地方得到相同质量的内容，而不会不断地被弹出的广告、动画或其他干扰因素干扰，那么他们就很可能会到这些地方查找所需的内容。在通读设计建议时，应该知道你的产品将要使用的画布尺寸和偏移量。在做进一步设计之前知道这些，可以保证一些重要的按钮和链接。比如Help链接和BuyNow链接不会在最低支持设置下离开用户的即时可视区域。不考虑分辨率与画布尺寸之间的不同会破坏多个产品，况且这在开发周期早期是很容易纠正的一个问题。

1．整洁是最重要的

在设计中，整洁包括对这样问题的考虑：图标尺寸、颜色方案以及页面布局等。例如，很多书的观点是必须在单个页面上留有很多的空白区(whitespace)——页面中没有放置文本和图片的区域。然而，随着越来越多只使用很少的空白区的站点成功，这一流行的名言很快就受到质疑。这种成功的原因在于好的信息架构和整洁的设计。如果用户看到他们所需要的信息，那么他们是可以容忍没有空白区的。可能需要大量页面才能显示一个既包含文本又包含少量图片的新闻故事，此时可能只留下极少的空白区，但用户此时的交互在阅读故事，用户已经找到了自己想要的信息。不要低估正确使用空白区的作用，但在使用时一定要明智。如果你留下空白区仅仅因为你还没有在页面上留下任何空白区的话，那么这不是使用这一技术的足够好的理由。

一致性是规划整洁的Web站点时需要记住的另一个设计原则。如果所有连接到该站点内部的链接都在同一个窗口打开，而所有到该站点外部的链接在新窗口打开，那么用户就会对该站点如何工作有一定的期望。他们呆在这个站点的时间也会越长。然而，如果有时链接会打开一个新的窗口，有时工具条变了或者有时页面布局不同了。用户会开始怀疑自己是不是已经离开了这个站点并且奇怪现在浏览的站点是谁的。一致性是保证精美设计的最重要的工具之一。即使是粗劣的设计，如果具有内部一致性，那么它就是有用的。只要你的产品具有内部一致性，就很可能会一直为用户工作下去。这种内部一致性包括整个产品中鼠标的一致使用、一致交互以及一致的UI。其中最为重要的是，作为用户观点的代言人，你应该努力使设计整洁。

2．测试其他设计方面的问题

还有其他一些方面的考虑可能有助于表述作为一名测试人员对Web站点的设计提出的几个问题，其中包括：

(1)用户能够进行打印吗?很多用户想要获得信息的硬拷贝并能打印几页新闻故事、商品目录或其他一些他们觉得有意义的信息。如果你的站点或应用的设计不允许灵活地打印拷贝，那么可以考虑在大家感兴趣的信息上加一个超链接，导航到打印机友好版本或只读文本版本。

(2)有Help(帮助)页面吗?Web站点上应该有完整的帮助信息，还是只提供一个电话号码，让用户与公司联系?Help页面应不应该打开新页面，以便让用户在参考Help部分的同时继续在应用中的工作?

(3)应用中会用到热键吗?热键的使用在很多平台本地应用中相当普遍，但还没有在Web应用中得到广泛应用。用户实际上想要使用它们吗?或者，他们能发现热键吗?如果所设计的站点是信息网站，拥有各种类型的用户，那么答案很可能是否定的。然而，如果该站点是一个内部站点，供员工平时使用，那么他们很快就会熟悉站点的界面并希望使用一些方法加速他们对应用的使用。这时，使用热键就很合适了。这些键可以用ACCESSKEY的属性加到元素上。该产品需要本地化吗?如果是的话，就需要重新看一下每个本地化版本的热键选择，因为使用的标记字符串可能已经变了。此外，在一个页面上你不能有重复的热键。正如用户通常想象的那样，首字母相同的两个字符串不能有相同的热键，因此其中的一个字符串必须选用另一个字母来表示它的热键。这种情况和时间与资源密集型的情况一样，很容易出现问题。

3．测试设计时考虑图片

设计的内容不仅仅包括布局，还包括站点的图像元素。在任何Web应用开始检查时。你应该检查所有图片能显示并确保没有断掉的图像标记符。在处理图像时，很容易出现错误，给用户造成极大不便。图像对于站点或应用来说是很重要的，然而如果使用不当，对于低宽带的用户来说是很大的累赘。应该尽可能减小图像——不是图像在屏幕上显示的物理系数，而是图像的文件大小。总的规则是单个图像的大小不能超过24KB(最好使用更小的图像)，并且如果是站点的主页的话，这个页面的大小不能超过50KB。当然如果用户深入站点并寻求艺术品的扫描图片，就会理解这些图片比较大，需要一定时间才能完全下载。你的用户对应用程序的某些部分可能会有类似的期望。

你希望用户能以尽可能快的速度收到所有信息。大多数显示器大约每英寸只能显示72点(dpi)，基于这一原因，只想在显示器上浏览的图片没有必要做成更高的质量，因为它们在显示时会被降低清晰度。如果你的站点出售艺术复制品，那么用户在购买之前可能会打印出样本查看一下。这种情况下，一些图片需要保存为更高的分辨率。

降低颜色深度也有助于减少图片的文件大小。如果你显示的图像是数学公式，就没必要把公式用成百万种颜色的格式表示出来，因为简单的黑白图像就足够了。市场有一些工具可以用来减小图像尺寸以对其进行优化，供web使用。在测试应用时，还应考虑下面一些有关图像的额外问题，这些问题有：
(1)用户不想在web上等待。为了使页面的加载时间最短，应该避免使用图片作为主导航元素。

(2)把重要信息放在图片中一般不是个好的做法。

(3)可用于图像的一种类似于颜色块(colorblock)的像素块称为素片(pixelshim)。

(4)减少通过网络传输的图像数目和大小能够提高客户端和服务器的性能。在同一页面甚至整个站点重用相同的图片有助于改善每个页面和整个站点的性能并减少加载时间。

4．测试设计的易用性

使某个东西可用的意思是使它更易于理解。然而，易于使用并不一定意味着更少的点击。将所有Web页的链接放到主页上不会使站点的易用性更强，因为每个网页只点一下就离开了。一个系统没有必要一定要比另一个好，但每个系统都是拥有自己的拥护者和用途的一种方案。知道你的目标用户可以帮助你把产品做得易用。

一旦信息架构和站点设计已经确定，就需要检查易用性。易用性涉及的范围很广，这是很多Web失败案例的罪魁祸首。你的站点很酷、很流行、很时髦而且做得很圆滑，但如果用户不知道如何购买东西，你就挣不到钱。飞机的驾驶舱功能丰富，提供了大量信息而且看起来很酷，但一般人不能坐进去并执行太多的动作。此外，大街上的普通人不是飞机驾驶舱的目标用户。(1)使用原型(Prototype)测试易用性。易用性测试是开发中很不被看重的部分。在开发周期中的很多时间点都可以进行易用性测试。一旦信息架构已经确定，易用性专家就可以据此在草稿上创建模型并与顾客或可能的用户一起工作，在编码还没开始之前就指出哪些地方很好，哪些地方应该进行修改。纸上原型(paperprototype)从字面上讲是一组页面，上面画有建议的站点设计的草稿、鼠标的一个很小的剪贴图指针以及各种下拉列表框的剪贴图等等。这一技术是进行研究的一种非常原始的办法，但通过专家和用户之间的交互以及找出整个应用中的不一致因素，它能够给出一些很宝贵的反馈信息。而且，这种方法所需的成本少，能够在开发周期刚开始，还没投入多少时间进行开发时就可以进行。

易用性测试的其他方法可能包括更实际的模型，虽然仍没有什么功能，但已经初具软件的形状以便使人知道该软件是如何工作的。在生成这些模型时，几乎可以使用任何应用，使用无格式HTML既快又简单，而且可以通过手工编码，也可以使用很多可用的授权环境中的任何一种进行编码。根据可用的工具和工作人员的专长，可以使用Excel，PowerPoint，Visio，甚至可以是VisualBasic。

(2)编写有效链接。一些站点试图使站点上的所有信息更详细，把整个句子做成超链接。如果你看到了如图1．3所示的两组链接，哪一组使用起来更简单呢?对于第一组链接，你必须阅读整句话才能理解链接的导向。虽然第二个例子中的链接指向的位置与第一组相同，但更容易理解点击它们的结果，而且用户理解起来会更快。当用户在进行查找时，他们跳读而不是细读。想一下你自己的网络行为。你不会为了知道美国链接通往哪里，而读取一整段文字。你想要的是链接通往何处的简短、精炼并且正确的细节。

(3)测试Web站点的搜索能力。很多Web站点提供了从整个站点查找信息的方法。但是，很多这样的站点返回的数据对用户帮助不大。用户几乎不用返回的文件名，而标题和描述则可以帮助他们更快地对信息进行筛选。相反，一些站点则过于热心于提供帮助，它们通过各种搜索引擎提供多种搜索方式。这样为用户提供了多种搜索UI(界面)，这只会使用户迷惑。你应该选用一种搜索引擎并提供给用户就可以了。

(4)开发有效的错误消息。对于用户来说，错误消息这个问题由来已久了。引用代码或太笼统的错误消息都不会使用户知道为什么会出错，从而使用户无助地处理问题或理解出现问题的原因。另一方面，太具体、特殊的错误可能会令用户感到迷惑，或者引起潜在的安全问题。一些研究发现在web站点的所有技术支持电话中，多达33％的帮助呼叫与错误信息有关——用户看到错误消息，不确定该如何处理。错误消息在开发时的确需要一些精力——它们必须计划到产品中并由开发人员实现，必须测试它们被激活的条件。同时，错误消息还需要本地化处理。然而，权衡一下产品支持电话所需要的费用、损失的销售额、用户的不满以及远程诊断问题中增加的难度，从长远看来，开发错误信息会节省开发并使企业向更专业的阶段迈进。

5．实现可访问性

人们很少提到可访问性(accessibility)，除非大的用户群体使用这些站点。直到最近，可访问性还只被认为是过量的开销。在美国，软件的可访问性不是强制设定的。然而，如果你的公司计划向政府出售软件或软件服务，那么你的软件就必须尽力达到议会指定的可访问性准则。你可以用几种方法对可访问性进行测试，比如：

(1)你可以编写自己的软件包，然后用一些插件工具测试软件在哪些地方工作得不是很流畅。这种方法是需要成本的，现在市面上有很多第三方辅助技术软件。

(2)你可以把你的软件交给已签约的第三方测试代理，他们已经有辅助技术，并且知道如何与Web应用进行交互。这种方法不仅贵，而且耗费时间。此外，前面提到的两种方式把重点集中在后端，而不是从一开始就设置可访问性标准。

(3)一个比前两种方法都好的方式是从一开始就计划可访问性需求。从一开始就制定可访问性需求提供了开发软件时的开发目标并确保你能达到可访问性要求，而不用管其他软件中可能存在的Bug。

6．设计用尸交互

用户可以使用很多方法与软件进行交互并增长他们的经历。其中最简单、最安全的方法是站点指定可能的交互方式，用户只是通过点击链接或其他一些对象进行选择。考虑一下下面的输入类型：

(1)最简单的输入方式是单选按钮。

(2)菜单的内容在用户选择之前已经给定了，同时一次也只能选择一项。

(3)按钮是INPUT标记符的另一个简单类型属性，具有TYPE一“button”格式。下拉框只允许用户选择一项，要么点击按钮，要么没有。

(4)复位(Reset)类型只是把所有表单选项恢复到它们的默认状态。

(5)复选框相比起来稍微复杂一些，因为可能有很多种组合并且由此可能会有更多的代码路径。

但这些“安全”输入页有它们的问题。如果软件遇到没预计到的状态，仍有可能在运行时出现错误。不选择选项或让它们保持默认值会产生脚本错误。对于只含有这种事先定义选项的站点来说，简单的验证测试、可访问性、易用性和服务端的考虑(性能和安全性等)可能是需要进行的所有工作。

用户在能够键入他们自己的数据时，交互才真正开始，而这时软件才真正打开了。不仔细的编码可能会使不小心的用户或怀有恶意的那些用户严重破坏他们的账号或你的系统。如果你的系统允许这类用户输入，你就把泄洪水闸打开了。大部分应用都有文本输入框、文本区域，甚至是只能完成此项功能的内容可编辑的DIV。在这里我们必须要检查文本的输入，考虑一下测试这些类型的文本输入框需要询问的问题；当然还得考虑文本输入区的边界问题，文本输入区输入内容都是有大小限定的。

7．性能测试

性能是在HTML测试中需要考虑的另一个问题。虽然使用HTML不能进行严格控制，但的确有一些东西能够对性能产生影响。在HTML中使用太多的标记符，即使最简单的代码也会变得臃肿，迫使服务器存储和发送较大的文件，并因为传输率的原因延缓了客户端的输出。多余的标记符在表面上听起来可能没什么大不了的，但是当100万用户使用时，而且用户的数目不断增长，那么这些标记符的影响也随之扩大。

1．2．2测试动态Web

1．检查应用程序架构

因为需要提供迅速的响应和可缩放的服务器，很多Web应用在开发时都将数据库和必须处理的数据分开。既然数据库服务器存在访问硬盘来获取数据的瓶颈，因此对数据库服务器增加额外的负载只会减慢用户会话速度。把数据从处理或显示中分离出来可以使服务升级，提供新的用户界面，而无须改动用户数据。这种架构的典型三层模型如图1．4所示。三层架构模型是由处理提交的客户端、处理业务逻辑和表示的前端服务器和处理数据存储的后端服务器组成的。具有浏览器的客户端发送请求，该请求通过因特网路由到目的服务器。此时，服务器应用理解请求并对其作出响应。前端服务器对请求进行解释并用数据库能够理解的方式对其进行格式化。然后，数据库返回前端服务器请求的信息并将它发送给前端服务器。前端服务器接收数据并添加表示信息。随后，整组数据和表示信息就被传送到客户端机器。也可以使用四层架构，对前端服务器进行分割，从而将业务逻辑层和表示层分开。如果软件编写正确，那么把工作分到几个服务器上也会改善性能。它还提供冗余——如果一个服务器出现故障，系统性能可能会受到影响，但整个应用对用户来说仍然是可用的。你的Web应用使用的架构可能在某些地方与这个模型符合。所有这些大的组件都有特定的属性，并且需要特定的技术进行测试。这里讨论的目的是取出Web应用的黑匣子并取出它的每一个组件、标注它们以及讨论它们的属性，以便使你成为一个更加有效的测试人员。

2．脚本

(1)引用脚本。在加载网页时，主要有两种方式可以用来引用脚本，分别是：

1)引用内嵌(inline)脚本。

2)引用需要下载并解释的脚本文件。

每一种方法都有各自的特性，测试人员需要熟悉它们。

(2)JavaScript。JavaScript在因特网上名声很响，然而，它被很多人误解了。JavaScript与Java或JavaBean没有任何关系。Java是Sun创建的一种编程语言。JavaScript是Netscape开发的一种脚本语言，最初被称为LiveScript。Netscape之所以冠之以Java是因为因特网的大肆宣传并把Java用到它们的语言中。与HTML不同，JavaScript是区分大小写的。因为该语言的不同版本都对标准有自己的解释，因此对于同一个脚本，它们的表现也会不同。正因为如此，需要确定代码符合标准，然后在所支持的每一个平台上对其进行测试。

(3)VBScript。准确地说，VBScript应该是VisualBasicScriptingEdition，但更随意地被称为VBScript或VBS。VBScript是微软为了回击Netscape的JavaScript开发的。它非常类似于VisualBasic(VB)和VisualBasicforApplications(VBA)，从而使它很快获得了至少有些知名度的编程基础。微软的InternetExplorer有一个内置的VBScript脚本解释器。然而。NetscapeNavigator(Netscape的确支持几种能够解释VBSeript的插件)没有，从而立刻给打算使用VBS的web开发项目蒙上了阴影，也就阻止了把VBScript作为客户端的脚本解决方案。与JavaSeript不同的是，VBScript是不区分大小写的。

(4)认识脚本问题。脚本问题主要分为3类，分别是：

1)编译时出现的错误。

2)运行时出现的错误。

3)逻辑错误。

在编译期间发生的错误在页面请求时就表现出来了。图8．5展示的就是这一类型的错误。图中指出的问题是：网页完全被这个编译错误挡住了，所以还没有被加载。同时还注意到浏览器窗口左下角有一个小警告，告知在加载页面时出现错误。当看到这样的警告时，可以双击这个图标，它就会显示遇到的确切错误。运行时错误(runtimeerror)与编译错误非常类似。网页在加载时没有错误，引擎解释脚本时也没有任何语法错误，但其中有一个函数有问题并在程序进入该函数时或出现错误。例如，如图8．6所示，如果用户点击其中的按钮，就会收到运行时错误。逻辑错误在脚本引擎调用函数时发生，多是由于用户输入了不曾预料的数值或因为变量没有被正确处理。有问题的函数会使浏览器在该函数停住，从而使连接超时，或者产生其他一些逻辑错误。逻辑错误的结果可能不会是错误信息，但不管怎样，都不是我们期望的行为。

(5)测试脚本。在对Web应用中的脚本进行测试时，可以遵循以下几条建议：

1)检查缓存问题。由于可以在客户端的浏览器缓存中存储副本，因此在遇到问题时，可能不是应用本身的问题，而只是测试人员遇到的问题。缓存中的版本可能与正在从服务器获取的其他数据不兼容，从而产生错误。当遇到问题时，可以尝试以下操作，看能不能找出问题的所在：

①不论遇到哪一种错误，最好马上把该错误的屏幕截图取下来并标注上如何遇到该错误的注释，然后保存下来。

②如果使用相同的步骤，错误重复出现，就关掉该浏览器的所有实例。

③只打开该浏览器的一个实例，清空缓存，然后重新关闭浏览器。

④打开该浏览器的一个实例并再尝试一次前面的错误。如果没有遇到这个错误，则说明很可能是因为你的浏览器已经缓存了数据，正是这些数据产生的问题。

跟踪整个开发过程有助于找出确切的问题，但很可能清除缓存即可以解决问题了，此时说明在服务器上的文件存在缓存版本冲突。代理服务器也存在同样的问题，因为它在缓存内容时的方式与浏览器方式非常类似。如果在客户端机器和正被测试的服务器之间有代理服务器，就要确保所做的设置使客户端机器能够在获得帮助的情况下，不经过代理服务器。如果客户端机器经过代理服务器，则容易产生很多Bug或者浪费大量时间。

2)为错误处理进行数据确认。数据确认(datavalidation)是可以使用的一个客户端脚本功能。脚本可以利用的数据验证主要有3种类型，分别是：

①表单级(From—level)确认，可以由onClick事件处理，也可以由onSubmit事件处理。它返回一个弹出消息，通知用户不合法数据。这种类型的确认多于表单上的两个输入框内容不匹配的情况，比如某一地区的地址和邮政编码不一致。一般情况下，这种确认是最容易实现的，只是通常起作用的时候太晚了，从而不能以后效地给用户提出警告——当对他们发出警告时。他们的注意力已经转向表单的其他位置了。

②输入框级(filed—level)确认，是Web应用中使用的另一个最小型的数据确认。与表单级确认相比，这种类型的确认用到更多处理程序，并且可以在焦点离开输入框或表单状态发生变化时警告用户。输入框处理程序发出警告，并给用户弹出警告，让他们知道信息不合法。

③键级(key—level)确认，用来阻止用户点击某个键。这样的一个例子是用户输入文本框，它只允许输入字符和数字，而不能输入符号。要对这些类型的确认进行测试，需要参考规范中的定义，以便知道哪些是可接受的输入，哪些不是，以及可以接受多少输入等。这些字符和边界条件需要通过测试进行验证，以确保用户不会输入它们，也就不会发生意料之外的行为。此外，还需要进行一些相关测试，验证收到合适的内容并测试表单处理某一内容的能力。

3)查找后f-1(backdoor)。很多应用容易出现问题的地方是通过后门。用户创建的输入框可能不允许输入某些带下画线的字符并只允许输入10个字符，但如果有一个用户轮廓编辑表单，而且该组件的程序员不知道有这样的限制，用户就可能在这里输入一些不能接受的输入，从而产生预料不到的结果。在测试时，应该总是试图用另一种方法变换数据，看能否把它置于不期望的状态。

4)查看性能。脚本的性能是很难进行评判的，服务器收到要求返回某一项的请求，例如含有内置脚本的HTML网页。浏览器自己处理HTML部分，但不得不将脚本送给解释器。解释器随后必须启动、接收脚本、对它进行解释，然后执行。如果脚本非常复杂，服务器可能已经把所有数据传送到客户浏览器，但此时解释器可能还没有执行完代码，也就没有准备好进行交互或接收输人。如果网络跟踪表明页面很快就下载完了，但它真正能接收输入之前，得过20多秒，此时对于用户来说，就存在性能问题了。分析应用的网络通信量有助于找出性能问题。现在考虑下面的问题：

①某些文件太大或者没有必要下载吗?

②可不可以把插入到脚本中的那些函数固化为一个函数，以便改善可维护性和性能?

③代码中还有没有一些函数，我们曾经使用它们，但以后不再需要了?

5)与显示尺寸有关的错误。浏览器的显示尺寸可能会对脚本产生影响。

①试着改变浏览器窗口的大小，使它的高度很高，却很窄，可能只能显示画布区域的一个像素宽。此时，尝试执行一个动作。此时出错了吗?对每一个框架(frame)都作这样的调整，只允许显示框架的一个像素。

②尝试相反的做法——将窗口变得很宽，但很矮，只能显示一个像素的高度，此时可以是整个窗口，也可以是将要重新加载的一个框架。在这种显示的情况下，脚本会出现错误吗?

③改变浏览器的大小，一旦脚本运行时使感兴趣的框架大小变为零。此时会出现脚本错误码?

④当你要进入某个感兴趣的页面时，调整浏览器窗口的大小，然后按F5重新加载。

虽然这些很可能不是用户使用时的情形，但用户也不是完全不可能这样做的，而且这样可以测试系统的健壮性。

3．测试ASP

ASP(ActiveServerPages，动态服务器主页)是用来创建、部署和运行Web应用的平台。ASP只是含有脚本命令的文本文件，使用．ASP作为文件扩展名，并通过ISAPI(Internet服务器应用程序接口)挂接在微软的IIS(Internet信息服务器)。在这些文件中通常也有HTML代码用来控制网页的格式。要测试ASP，可以首先做一些简单的校对。通读一遍代码，检查一下可能会导致变量和函数名错误的拼写错误。在多种不同的浏览器中对ASP进行验证。如果会话状态不是web站点或Web应用中框架的核心功能，那么就应该把它关掉。ASP是顺序执行的，意思是它只能在完全完成一个任务后才能开始另一个。这可能会使我们感觉存在性能问题。对服务器上ASP的性能进行测试是非常重要的，就像ASP服务器的压力测试一样重要。考虑下面一些问题：

(1)在测试时，看一下记录的各种事件日志。服务器可能不曾瘫痪过，但可能会有很多不曾想到的事件发生。可以使用微软的WebApplicationStressTool或IIS异常监控器帮助跟踪这些问题。

(2)ASP还提供服务器端缓存。如果有很多静态内容的话，这一特性就是很有用的，因为此时可以从内存中提取这些内容，而不需要访问磁盘并对数据进行处理。但是如果应用的核心内容是动态的，那么这种缓存就可能引起性能问题。

(3)在响应中可能出现的问题是响应超时。很多应用在使用Response．Expires属性时，将属性值置为零。在这里使用负数迫使内容超时，而因为0是永不超时，所以这里最好使用负数。

(4)为了测试与．ASP应用相关的所有内容，可以将文件名从*．ASP改为*．ASTM。这将使你看到包括#include和数据尺寸的所有内容。对这些出错的地方和性能进行的所有这些测试是测试ASP中最重要的部分。应该从这些组件中看一下是否有内存泄漏。

4．测试CGI

CGI(通用网关接口)是一种服务器端技术，允许自定义的用户体验。实际上，CGI是一种协议，规定了服务器上的编译程序如何与Web服务器(典型情况下是其他文件或数据库)进行交互。它实际上更像是客户端和服务器之间通信的标准变量集合。它所标准化的接口是服务器的HTTP服务器应用中来为客户浏览器和服务器上的其他应用或文件提供数据的。它基本上提供了一种标准方法，以便使信息可以在HTTP服务器和脚本之间传送。CGI程序是服务器经过编译的程序，可以使用允许直接访问Web服务器上的STDIN和STDOUT函数的任何编程语言来编写。这样的语言可以是AppletScript，Perl，TCL，VC++，VisualBasic以及其他一些语言。存放CGI并与之交互的服务器可以是微软IISWeb服务器、NetscapeWeb服务器、OracleWeb应用服务器或其他类型的服务器。当你把CGI与微软的ASP进行比较时，你会发现ASP只能工作在微软的IIS服务器，而支持CGI的平台则更多。因此，需要像对ASP应用那样，对CGI应用进行细心的性能和压力测试。

5．测试ActiveX控件

ActiveX控件是客户端技术，实际上就是类似于任何win32程序中的那些OCX控件。对于ActiveX控件来说，它们都有其内在的限制、需要考虑的因素和优点。在对ActiveX控件进行测试时，要记住下面的几点：

(1)ActiveX控件只能用于Windows客户端。虽然Netscape本身不支持ActiveX控件，但你可以使用相应的插件。因此在确定技术方向时，你应该考虑到这种限制用户量的因素。

(2)因为ActiveX应用是编译后的应用，需要下载到客户端运行，因此需要一些安全方面的考虑。ActiveX应用需要进行签名和验证。很多用户越来越意识到安全风险，可能会拒绝下载ActiveX或其他组件。除非绝对需要，否则不要为了编辑脚本把你的空间标记为安全的．以防一些恶意用户利用你的控件中的潜在问题。

(3)控件下载和安装的事实说明已经很长时间没有检测旧版本的控件了，自己还没有意识到你的控件已经过期了。与HTML网页、图片和脚本文件不同，它们被缓存起来并在需要时检查更新，ActiveX组件是需要安装的。它们需要卸载，重新安装以前测试每个新的版本。在测试之前，要查看一下版本号。

(4)既然ActiveX控件是自动安装的，因此还需要查看一下硬编码安装路径。很多用户现在有多个驱动器，因此硬编码安装路径和其他类似的假设可能会与它们的系统不兼容。

(5)在“脏”(dirty)系统(有过期版本的系统)和干净的系统上测试下载和安装，以帮助验证两种方法都可以正常工作。

(6)一定要对卸载过程进行测试——需要删除的所有文件以及需要清除注册表中引用该控件的所有项目。

(7)在安装控件时，验证控件的注册。

(8)在安装控件和没有安装控件的两种情况下验证Web站点或应用中所有网页易用性。因为许多用户可能不想下载或者无法安装控件。为了防止失去部分用户基础，必须有某种解决方案可以使他们在不安装ActiveX控件的情况下，即使不能获得丰富体验，至少也可以获得应用的完整经历。

(9)遍布在ActiveX技术中的一个问题是病毒。需要不断查看控件中是否存在病毒。将病毒传播给你的用户不是好的业务操作，不会为你赢得更多用户。

(10)还要保证为你的控件签名。签名可以保证较为安全的下载，并使在用户在下载控件时感觉舒服些。签名还可以使你的应用更加专业。测试ActiveX控件的其他一些简单用例包括在控件处于活动状态下点击浏览器的“Re—fresh”按钮，或者点击浏览器的“Back”，“Stop”或“Print”按钮。可以尝试的另一种测试是在控件还处于活动状态时断掉与网络缓存或与调制解调器的连接。如果控件间歇轮询或正在从服务器下载数据，那么这种断开连接就会产生不可预料的行为。

进行客户端测试时除了前面提到的测试，还应该测试字符集、代码页和字形。了解字符并能够对它们进行操作不仅有助于开发那种需要本地化到各种市场的软件，还可以帮助你测试只用于一种语言，不需要工作在其他语言环境下的软件。了解了目标语言或将要使用该软件的用户可能输入的容易出问题的字符和字符组合，可以帮助你创建更好的测试用例，而不用像随机点击键盘那样费力。与凭空猜测如何很好地训练你的产品相比，创建针对软件的灵活测试用例能够更快地找出更多Bug。

大多数Web应用尽力提供丰富的特性，为用户提供多种多样的功能。用来或通过组合提供这一功能的技术在不断变动，每一种技术都有自己特定的一些缺点和测试用例。与其他软件一样，详细说明各种特性的行为和交互以及用户将如何使用软件有助于创建按期工作的无缝软件。

1．3服务器端测试

1．3．1性能测试

性能是用户经常感到困惑和提高成本的问题之一。肯定曾有过因为性能太差而拒绝使用某一应用程序的经历。然而，应该记住与这一问题有关的几个方面，体验只是其中一个。可以把性能定义为特定功能占用的时间，它可以是功能的开销或意味着可以同步运行的功能数目。这些定义可以用来解释这些例子：

(1)功能所需的时间可以在代码层或用户的感知层次上进行度量——用户觉得完成某一功能需要多长时间。

(2)功能的开销可以在代码层，以CPU周期为单位进行测量；或者从用户角度，看任何用户定义的功能在CPU、内存、带宽或其他任何测量单位上的消耗。

(3)可以同时运行的功能数可以在代码这一微量尺度上，通过测试CPU达到某一利用率可以同时运行的功能总数或者多数用户可以同时执行某种动作进行度量。

1．制定基于性能的测试计划

性能是所有用户对任何软件产品感到满意与否的一个至关重要的方面。性能调整是进行折中的一种尝试。为折中做出的决定越好，系统的性能也就越好。但决策再好也不能完全弥补糟糕的架构或软件底层的其他一些问题对性能造成的影响。性能测试的目标是找出问题并纠正需要纠正的问题。

对软件进行测试没有成功的一个最常见原因是测试了错误的场景。在每个构建版本上，并不是需要把每一行代码或可能的交互作为基准。找出至关重要的部分、最经常通过的代码路径、开销最大的地方、对用户最重要的部分，然后把前面的测试时间都放在这里就行了。如果还剩下很多时间，可以把它花在从上次发行以后增加的代码路径。对不适当的部分进行测试不是好传统，如果这样，就不得不从底层开始才能找出问题的所在。使用规格说明书或者找出存在性能问题的系统或应用的实际部分是制定能测试计划的两种方法，有助于避免测试错误的地方。

(1)使用规格说明书指导性能测试。在软件开发设计阶段，需要定义性能和稳定性。如果没有明确的定义作为目标来决定通过和失败，那么测试只能找出故障点、哪里的负载使服务器瘫痪或者性能如此之差，以至于客户端连接超时。规格说明书精确地列出系统期望的行为是关键的。否则，测试是不能做出客观的声明的，从而不得不对软件满足顾客需求的能力做出一些主观判断。规格说明书还需要根据应用的设计提出一些可能会引起注意的部分。指出这样的区域可以使测试甚至在编码开始之前就关注这些地方并使整个开发组都意识到他们面临的风险。如果他们忽略这些用户需求，公司就会有损失。如果没有详细列出标准的规格说明书，可收集数据并且可以保证数据绝对正确，但不能确定数据是否是可以接受的，因为没有可以用来判断数据的标准。如果没有定义可以接受的、理想韵或不可接受的范围，那么测试就不能识别通过或者失败的比例，而只能看出服务器何时停止响应或者变得不可用。

(2)找出性能问题。你的整个应用可能看起来非常复杂，所以很难看出从哪里开始。经历一些基本的客户／llli务器交互是比较合适的第一步。

1)客户端向服务器发送请求。

2)服务器必须处理这个请求并形成响应。

3)必须把响应送给客户端。

4)随后，客户端必须对响应进行分析，然后显示或执行。

看完这些交互后，你将会发现客户端请求几乎不可能是性能瓶颈。可能会从客户端请求中发现的唯一瓶颈现象是当用户发送大量数据，比如很大的表单或文件给服务器时。此时，很值得调查一下客户端是否应该发送这么多数据。服务端用来构造输出时间可能会是瓶颈，这里需要考虑一下服务器硬件。将响应发送给客户端机器可能是造成瓶颈现象的另一点。在另一方面，更可能是服务器CPU或带宽是限制因素。通过初步调查以找出性能限制因素是很必要的。否则，改善性能的各种措施可能已经就位了，但如果用的地方不对，它们也不能减轻瓶颈现象。在某些情况下，性能有多好是有理论限制的。如果所有服务器的响应都是瞬间完成的、带宽也是无限的并且响应时间可以忽略，那就太好了，但事实并非如此。到了一定程度后，你回去重新调查，会发现继续优化软件可能是不值得的，并且不会有明显的改善。此时，就应该把你的测试资源用到其他地方。

2．性能测试综述

基本上可以通过3种方法进行性能测试。这3种方法分别是：

·随机(Adhoc)性能测试：这是每个测试人员对应用进行测试时应该做的。测试人员与应用交互的过程中，他需要知道应用的响应是否缓慢。应该将Bug以用户可以看懂的方式记录，并附上开发者调查结果。这些Bug是基于常识性知识的，在本质上是非常普通的。Adhoc测试不指出问题所在，而只是警告问题所在。

·观察(observational)测试：这种方法使用某些工具给出确切的数字。甚至简单地使用秒表并记录用户在可以与网页交互之前花费的时间，以便给出应用性能的更为清晰的概念。

·测量(measured)钡4试：这种方法的目标是找出客观的测量法。这可能意味着让开发者插入一些性能标记，查看网络包和通信，或者用客观的方法监控性能。在Web应用中，线路和网络通信中的字节流很可能是性能限制因素。性能监控器、网络监控器或其他一些工具可以用来测试应用的性能以及用户与它的交互。这样可以给出特定功能的性能的绝对数值，从而有助于找出开销大的功能。

即使有了以上3种方法，在性能测试中还可以把测试时间和工作放在很多方面上。一些团队考察整个版本的细节，以便使它们的努力有所回报。然而，对于大多数测试组来说，每个区域只有很少一部分检测是有效利用可用的时间和金钱，也只有很少一部分能有助于涵盖80％的用户场景——这已经大大超出很多公司所做的了。应该把时间用到理解各个时间段的构建版本的性能上，并以此作为基本的起点。然而，并不是每个版本都需要剖析，或者完整的剖析。同样，还是要把时间用到对你公司来说最重要的地方。最后还需要提到的一点是不应该只是对调试版本进行性能测试。调试版本的速度比发行版本更慢，因为它们需要断言，并且如果有的话，可能还需要处理编译时留下来的代码。在即将发布时做压力测试或平均失效时间测试，可能会发现非常罕见的断言或其他问题，因此如果测试小组有时间在这方面做测试是很值得的。

(1)选择用于性能测试的机器。在选择用来测试性能的机器时要仔细考虑。有几种不同方法可以将设备列出来。排在首位的是能够完全匹配应用需要的硬件。该方法的缺点是太贵了，需要为测试购买很多更昂贵的设备。构造测试环境的第二种方法是购买专用于性能测试的高端工作站。只要坚持从机器的同一种配置收集测量，那么机器的实际模型就没有太大关系。在发布之前，应该买一台实际机器，它具有应用运行所需的配置，并在上面做一些测试以确保对应用性能的假设是成立的。

当软件进入能够运行全部场景阶段时，机器的实际配置可能需要调整。这一过程可能需要很长时间，但从长远来看，这是值得的。如果调整了正确的注册键和其他配置，可能就只需要更少的机器或者每个服务器能够支持更多用户。

(2)在性能测试之前检查配置。在测试服务端的开始阶段，采用下面的配置步骤：

1)需要对服务器的配置进行调整，以确保它的性能处于巅峰状态。记下遇到的所有资源死锁。

2)在进行任何测试之间，需要多次对硬件进行配置，以找出最优配置。尝试的次数要多于两次，同时将各种尝试和数据以及最成功的解决方案编入文档。

3)当确认内存或网络是瓶颈所在时，这立即告诉需要为服务器安装更多内存，同时网络速度也需要升级。CPU应该是你看到的唯一瓶颈，除非找到的瓶颈大大超出了预期的用户负载，从而使风险减小了。

4)在进一步测试拓扑之前，把一台机器配置成性能拓扑机器，并在上面运行脚本和测试。这个过程可以提供一个可供参考的基线，从而可以断定当这些单个机器组合到拓扑中时，应用能不能像期望那样缩放。

探究性能问题的第一步是证实代码的确是产生性能瓶颈的根本所在。如果不关心拓扑配置、注册键、服务和其他对服务器产生影响的设置，那么在解决性能问题时就找错地方了。在继续性能测试之前，应该排除系统和拓扑配置成为性能问题的潜在根源。

(3)开始性能测试。万事开头难。你在刚开始进行性能测试工作之前，这些工作看上去如此繁重以至于似乎永远不能控制它们，而且投入其中的努力从来不会得到回报。这些没有必要成为项目的命运。如果对测试工作做了极好的计划并在适当的时间开始，那么所做的努力是很值得的。

1)构思应用的轮廓。这里的第一件工作是要找出哪些需要给出轮廓。肯定希望建立健康应用的轮廓。对于轮廓，需要决定两件事：所关心的是哪些动作，这些动作应该具有哪些度量。既然应用还没有成熟，因此很多感兴趣的行为还不能执行。从一开始就找出感兴趣的所有行为，同时要知道它们并不是都能运行的，而且在趋于成熟的后期，可能会有Bug阻塞代码路径。
2)获取测量。对于应用轮廓中确认的每一个动作，都应该测量，了解这些动作要多少开销。一些常见的性能测量可能有：
①兆周(Megacycle，MC)：兆周用来度量完成动作消耗的兆周数。这个数在动作只被请求1次和请求1000次是不同的。设计这一消耗的基本公式为
CPU消耗一CPU利用率×CPU个数×CPU速度(MHz)／每秒的事物请求次数
②内存足印(Memoryfootprint)：内存足印是应用在运行时消耗的内存峰值。
③BoW(BytesovertheWire，线路上的字节)：BoW是在服务器和客户端之间传输的字节数。主要有两种方法测量该值：首次动作和缓存场景。
首次动作说明因为对服务器请求是一个新请求，用户在他们的机器上没有缓存图像、脚本或网页。因而，这个请求很可能更加昂贵。缓存模式指图像和网页已经缓存到客户端，只需要为随后的动作传输动态信息即可。因而，该请求就比首次动作所需的开销更少，这取决于你的应用。
④TTLB(TimetoLastByte，收到最后字节的时间)：TTLB度量的是请求离开客户端机器与服务器发出响应的最后一个字节之间的时间。这个时间不考虑浏览器中必须运行的脚本引擎、绘制和可能造成用户感觉性能低下的其他功能。
⑤用户感觉到的响应时间：用户感觉到的响应时间指的是页面完全显示并准备进行交互所花费的时间。这个时间包括所有图像加载和脚本执行时间。
所有这些测量的目的是改善用户的体验并节省运行应用所需要的开销。所有这些测试都可以通过编写正确的自动化代码并协调客户端和服务端同时完成，以便使服务端在客户端执行相关动作并记下收到的字节数以及最后字节到达的时间时，记录这些测量。强烈建议测试小组手动执行所有这些测试，以便熟悉这些工具以及测试这个领域的基础知识。
(4)继续性能测试。到现在为止，你的机器已经配置好了，有了展示软件行为的一些基准数字；你有了自己的用户场景和一些自动化测试软件。测试开始了!现在你需要收集数据——大量的数据。随着你不断优化代码并预测对性能产生的影响，你需要采集数据，看一下真正的效果。
1)不仅仅是性能问题。服务器的性能测试与其他领域紧密联系在一起。单纯考虑性能是没有意义的。你可能会想创建若干个场景，需要分析的典型性度量有：

①性能与用户数量的关系。
②性能与时间的关系。
③每秒的点击数(每秒的事物或请求)。
④每个用户交互中的错误数目。
⑤单位时间中发生的错误数目。
⑥每秒的千字节数目。
⑦每个用户下载的平均数据量。
测量这些数据中的任何一个都会让人感到沮丧，但这些测量可以按照组织希望进行检查的任意方式被分开测试。你应该从规格说明中看出服务器上期望的负载，对于期望的负载，最小的性能要求是什么以及最大的错误率。性能从来不会存在于真空状态下——它依赖于很多因素。这些因素最终可能确定为非常重要，但不是你能控制的，从而没有包括在测试中。可能会选择调整其他因素以便隔离出适当的变量。当给出相应的数字后，需要对这些因素做一下规定以便正确表示应用的状态。

2)优化带宽。到目前为止，工作还只是集中于找出并纠正服务器上的问题。然而，你还需要关心数据是如何达到服务器以及如何返回给客户端的，因为这可能是另一个主要的瓶颈。虽然不可能，但用户还是希望应用能够接近于瞬间响应。同时，你仍然需要尽可能地使你的应用接近理想状态。
①优化图片的使用。在对带宽的使用进行优化时，第一个应该检查的就是图片的尺寸和使用图片的数目。有很多工具可以用来压缩图片。你可以用Photoshop把图片保存为适合Web应用的文件。这里的压缩可能高达90％，取决于颜色深度。把你的应用中使用的所有图片放到一个网页上，看是否有重复。
②优化代码。查看所有HTML文件、脚本和控件存在服务器上的目录并找出其中最大的文件。现在有一些工具不仅仅可以去除空格，而且可以删除重复的或不需要的标记符。有时，能够纠正的唯一好办法是花时间手工删除。这里，应该将可读性、可维护性以及正确的编码实践与可能获得的潜在性能收益进行权衡。
③通过压缩进行优化。作为一种附加方式，IIS和其他工具允许将需要通过线路发送的内容在离开服务器时进行压缩。与下载臃肿的文件所需的开销相比．客户端的解压开销是很少的。我们在这种压缩和有损传输上的时间投资可能是很值得的。在有些应用中，每月操作的开销大部分都包装在带宽中，并且可能的78％的压缩率是很吸引人的，足够令我们进行优化。
④优化用户场景。当你想要对带宽进行优化时，处理用户场景是非常方便的。用户场景勾勒出最常见的用户动作。对这些动作作网络跟踪，然后对它们进行仔细的分析。
3)阅读度量。度量可能是骗人的。它们可以为你骗人或者骗你。如果你从一开始就正确处理它们，那么它们应该是对的，但只要有一处假设错误，那么所有的测量结果都无效。
一旦确定了硬件配置，测试活动的第一个阶段就可以开始了。在硬件配置期间，小组的一部分成员可能对硬件进行操作，而另一部分则编写自动化脚本并把它们调试正确。如果这些脚本过于复杂或编写不好，它们就有可能使数据失真。这时，需要对服务器端的一些主要数据进行观察。在跟踪性能参数时，当作用到应用上的压力增强时，这个参数应该是线性增长的。你还需要观察网络通信量，以找出线路传输的BoW、响应时间和允许的并发连接数。到这里为止，性能测试已经很全面、很详细了。既然很多因素不是你能控制的，因此你还必须使用一些常识性知识。

1．3．2其他测试

现在对Web进行的性能测试已经很全面了，还可以考虑以下一些测试：

1．负载测试争压力测试

负载测试有时也被称为压力测试，与稳定性测试类似。但持续时间不是负载测试的一个因素。相反，负载测试会使用越来越重的负载，以使应用失败。负载测试可能包括平衡测试床(testbed)几个服务器之间的负载。施加负载测试的最有效方法是通过使用客户端工具。

2．可靠性和稳定性测试

可靠性和稳定性标志的通常是同一个东西——系统在某种条件下能够正常工作多长时间?这类测试回答的一类问题是：

(1)在实践的负载作用下，系统的正常运行时间是多少?

(2)应用能在1S时间内处理1000个用户请求吗?

(3)正常情况下，它能处理多少用户?

3．可伸缩性测试

可伸缩性测试实际上展开了本章的另一个主题，它是发生在整个系统上的，而不是只针对单个服务器。系统有两种缩放形式——扩大和扩充。

(1)如果系统可以扩大，则说明对当前机器作改动以生成更大的机器会缓解问题。这样的变化可以是把CPU换成更好的、增加更多处理器或其他一些配置。与扩大有关的问题是它没有为系统增加任何冗余。

(2)扩充的意思是向拓扑中添加更多机器，以减轻处理的负载，这样的增加可能会使问题复杂，因为在多个机器之间共享状态是很难管理的，再现和解决Bug会更加困难。

1．3．3关键的性能测试技巧

(1)从一开始就定义期望的结果。

(2)在进度安排上要实现。

(3)不要在服务器上安装浏览器并在服务器上运行性能测试、负载测试或压力测试。

(4)在早期建立一个独立的性能实验室。

(5)在部署之前需要找出的稳定性问题。

(6)创建大量从最常见、最密集的用户动作派生出来的用户场景。

(7)虽然安全性一直都是需要考虑的问题并且也需要如此，但尽量减少SSL和任何加密的使用可以节省成本。

(8)在性能测试完成后，分析性能数字。

1．4改善应用性能

测试的整个目标就是找出伺题并予以解决。你的软件遇到的大部分问题可能都是针对你的软件所特有的。然而，本节给出几种常见问题，你可能很快会发现自己的应用中也存在这种潜在问题。能从别人学到教训可以节省测试小组的时间和金钱。这样的问题有：

(1)尽量减少往返通信和数据流数量。

(2)使用分布式和冗余架构。

(3)考虑使用冗余的电源供应和发电机。

(4)部署之后监控软件。

(5)保持简单的软件设计。

做这些测量的唯一目的就是要指出代码中的问题并找出需要改善的地方。它们只是用来给出软件最终执行的大概印象以及对于预期的用户量，需要多少台服务器。这里的测试工作越好，测量的结果就越可能反映出真实用户的部署场景。性能测试是很值得嘉奖的。当问题修复后，其结果是很直接、很显然并且是可以测量的，只要关键的反馈表明做了正确的决定。