web网站测试方法

在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、JavaScript、ActiveX、VBScript或Perl等也要进行验证

4兼容性测试

4.1平台测试

市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

4.2浏览器测试

浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、ActiveX、plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是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服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。