Web测试方法.docx
《Web测试方法.docx》由会员分享，可在线阅读，更多相关《Web测试方法.docx（10页珍藏版）》请在冰豆网上搜索。
Web测试方法
Web测试方法
在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。
基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。
重要的是，还要从最终用户的角度进行安全性和可用性测试。
然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。
因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
本文将web测试分为6个部分：
1. 功能测试
2. 性能测试（包括负载/压力测试）
3. 用户界面测试
4. 兼容性测试
5. 安全测试
6. 接口测试
1功能测试
1.1链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。
链接测试可分为三个方面。
首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
避免死链接情况，执行完相应操作应有返回按钮，返回到相应页面；例如：
操作成功后，进入成功提示信息页面，但页面没有返回按钮，无法及时进入操作之前的页面。
1.2表单测试
当用户通过表单提交信息的时候，都希望表单能正常工作。
如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。
如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让客户收到包裹。
要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。
当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。
例如：
用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。
如果使用了默认值，还要检验默认值的正确性。
如果表单只能接受指定的某些值，则也要进行测试。
例如：
只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
1.3数据校验
如果系统根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。
例如，省份的字段可以用一个有效列表进行校验。
在这种情况下，需要验证列表完整而且程序正确调用了该列表（例如在列表中添加一个测试值，确定系统能够接受这个测试值）。
在测试表单时，该项测试和表单测试可能会有一些重复。
1.2和1.3的采取措施：
第一个完整的版本采用手动检查，同时形成录制脚本；回归测试以及升级版本主要靠自动回放测试。
1.4cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。
测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
如果在cookies中保存了注册信息，请确认该cookie能够正常工作而且已对这些信息已经加密。
如果使用cookie来统计次数，需要验证次数累计正确。
1.5数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。
在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。
数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
1.6应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。
尝试用户可能进行的所有操作：
下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。
这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。
1.7设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。
当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。
除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、ActiveX、VBScript或Perl等也要进行验证。
1.8功能测试边界测试\越界测试技术详述
1.8.1边界条件
边界条件是指软件计划的操作界限所在的边缘条件.
如果软件测试问题包含确定的边界,那么数据类型可能是:
数值速度字符地址位置尺寸数量
同时,考虑这些类型的下述特征:
第一个/最后一个最小值/最大值
开始/完成超过/在内
空/满最短/最长
最慢/最快最早/最迟
最大/最小最高/最低
相邻/最远
1.8.2越界测试
通常是简单加1或者很小的数（对于最大值）和减少1或者很小的数（对于最小值）,例如:
第一个减1/最后一个加1
开始减1/完成加1
空了再减/满了再加
慢上加慢/快上加快
最大数加1/最小数减1
最小值减1/最大值加1
刚好超过/刚好在内
短了再短/长了再长
早了更早/晚了更晚
最高加1/最低减1
另一些该注意的输入:
默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据.
1.8.3状态测试技术
软件可能进入的每一种独立状态;
从一种状态转入另一种状态所需的输入和条件;
进入或退出某种状态时的设置条件及输入结果.
具体测试方法可以参考如下:
每种状态至少访问一次;
测试看起来最常见最普遍的状态转换;
测试状态之间最不常用的分支
测试所有错误状态及其返回值
测试随机状态转换
2性能测试
正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间,在可以接受范围内.,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了.如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。
因此在产品开发的开始阶段，就要考虑到软件的性能问题。
2.1连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。
当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。
如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。
而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.2负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。
负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。
例如：
Web应用系统能允许多少个用户同时在线？
如果超过了这个数量，会出现什么现象？
Web应用系统能否处理大量用户对同一个页面的请求？
2.3压力测试
压力测试（Stress）多用户情况可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行.如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息.如果有必要的话必须进行性能优化（软硬件都可以）.这里的压力测试针对的是某几项功能。
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。
因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。
压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。
黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。
负载/压力测试应该关注什么
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。
可访问性对用户来说是极其重要的。
如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。
系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。
出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。
瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。
负载测试工具能够模拟X个用户同时访问测试站点。
每个用户传送大量数据
网上书店的多数用户可能只订购1-5书，但是大学书店可能会订购5000本有关心理学介绍的课本?
或者一个祖母为她的50个儿孙购买圣诞礼物（当然每个孩子都有自己的邮件地址）系统能处理单个用户的大量数据吗?
长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。
如果站点提供基于web的email服务，那么点最好能持续运行几个月，甚至几年。
可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。
你可以想象组织100个人同时点击某个站点。
但是同时组织100000个人呢。
通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。
而且，测试工具安装完成之后，再次使用的时候，只要点击几下。
微软定义的通过准则是通过72小时测试的程序一般不会出现稳定性的问题。
2.4竞争条件测试技术
竞争条件典型情形参考如下:
两个不同的程序同时保存或打开同一个文档
共享同一台打印机,通信端口或者其他外围设备
当软件处于读取或者修改状态时按键或者单击鼠标
同时关闭或者启动软件的多个实例
同时使用不同的程序访问一个共同数据库
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应用系统提供信息的正确性、准确性和相关性。
3.4表格测试
需要验证表格是否设置正确。
用户是否需要向右滚动页面才能看见产品的价格？
把价格放在左边，而把产品细节放在右边是否更有效?
每一栏的宽度是否足够宽，表格里的文字是否都有折行？
是否有因为某一格的内容太多，而将整行的内容拉长?
3.5整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。
例如：
当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？
整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。
一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
对所有的用户界面测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
3.5.1文字
内容一致性：
公司要求文字的一致性，例如各种宣传文字、注册的协议条款、版权信息等；
各处相同含义文字的一致性，例如标题栏文字、页面主题文字、弹出窗口文字、菜单名称、功能键文字等。
样式一致性：
（通常分类包括）各类文字字体、字号、样式、颜色、文字间距、对齐方式
按钮的文字间距，按钮长度一定前提下，2个字的按钮，需要中间空一格（或者其它约定，需要统一）；
链接文字，同一类，菜单、小标题、页角文字链接，在点击时颜色变化要相同；
对齐方式，页面上文字的对齐，例如表单、菜单列、下拉列表中文字的对齐方式（左、右、居中等要统一）
语言习惯
中文：
文字简单，含义明确，无歧异，无重复，无别字，正确运用标点符号。
英文：
日文：
3.5.2按钮
1）button的样式整体要统一，例如突出、扁平、3D效果等只能选其一；
2）采用的图片表述相同功能，要采用单一图标。
3.5.3文本框
1）录入长度限制，根据数据库的设计，页面直接限定录入长度（特殊处屏蔽复制、粘贴）；
2）文本框自身的长度限制，主要考虑页面样式。
3.5.4单选框
1）默认情况要统一，已选择，还是未选。
3.5.5日期控件
1）图标、控件颜色、样式统一；
2）点击控件、文本框均应弹出日期选择框。
3.5.6下拉选择框
1）默认是第一个选项，还是提示请选择一个。
3.5.7提示信息
1）静态文字与它的提示信息一致性，例如静态文字为‘ID’，出错信息显示‘用户ID’；
2）空值时，出错信息需要统一，例如可以采用“静态文字”+不能为空；
3）出现录入错误时，例如可以统一采用“静态文字”+格式不符合要求；
4）提示信息标点符号是否标识；点击上一步，返回的页面上不应残留出错信息；
5）静态提示信息，在录入框右侧，应有录入信息的相应要求的提示文字，达到方便操作的目的；
6）必输项提示信息，必输项提示信息采用统一的标志。
3.5.8IE的后退
退出系统，无论直接关闭浏览器或点击后退键，退出都不应再返回系统；
3.5.9重复提交问题
功能操作完成后，鼠标右键点击所在页面，选择弹出菜单的刷新功能，容易出现重复提交问题。
功能操作完成后，通过IE的后退键进行重复操作，容易出现重复提交问题。
某功能键反应时间延迟时（限制客户端网络带宽等方式来模拟实现），在短时间内重复点击该功能键，容易出现重复提交问题；
3.5.10用户非授权页面访问
1）每个页面都需要安全验证，防止用户通过直接拷贝具体页面地址等方式，访问系统；
2）页面过期的时间设定，用户在设定时间内未进行任何操作，不允许访问系统。
4兼容性测试
4.1平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。
Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。
这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
4.2浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、ActiveX、plug-ins或不同的HTML规格有不同的支持。
例如，ActiveX是Microsoft的产品，是为InternetExplorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。
另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。
不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。
在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
4.3分辨率测试
页面版式在640x400、600x800或1024x768的分辨率模式下是否显示正常?
字体是否太小以至于无法浏览?
或者是太大?
文本和图片是否对齐?
4.4Modem/连接速率
是否有这种情况，用户使用28.8modem下载一个页面需要10分钟，但测试人员在测试的时候使用的是T1专线?
用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。
最后，需要确认图片不会太大。
4.5打印机
用户可能会将网页打印下来。
因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。
有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。
有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。
测试人员至少需要验证订单确认页面打印是正常的。
4.6组合测试
最后需要进行组合测试。
600x800的分辨率在MAC机上可能不错，但是在IBM兼容机上却很难看。
在IBM机器上使用Netscape能正常显示，但却无法使用Lynx来浏览。
如果是内部使用的web站点，测试可能会轻松一些。
如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。
如果所有的人都使用T1专线，可能不需要测试下载施加。
（但需要注意的是，可能会有员工从家里拨号进入系统）有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。
但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。
4.7软件配置（Configuration）如IE浏览器的不用选项-安全设定最高,禁用脚本程序,等等,你们的程序在各种不用的设置下表现如何.
5安全测试
即使站点不接受信用卡支付，安全问题也是非常重要的。
Web站点收集的用户资料只能在公司内部使用。
如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
5.1目录设置
Web安全的第一步就是正确设置目录。
每个目录下应该有index.html或main.html页面，这样就不会显示该目录下的所有内容。
我服务的一个公司没有执行这条规则。
我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。
然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。
这可能没什么关系。
我进入下一级目录"…com/objects"，点击jackpot。
在该目录下有很多资料，其中引起我注意的是已过期页面。
该公司每个月都要更改产品价格，并且保存过期页面。
我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。
如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。
5.2SSL
很多站点使用SSL进行安全传送。
你知道你进入一个SSL站点是因为浏览器出现了警告消息，而且在地址栏中的HTTP变成HTTPS。
如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面（适用于3.0以下版本的浏览器，这些浏览器不支持SSL。
当用户进入或离开安全站点的时候，请确认有相应的提示信息。
是否有连接时间限制？
超过限制时间后出现什么情况？
5.3登录
有些站点需要用户进行登录，以验证他们的身份。
这样对用户是方便的，他们不需要每次都输入个人资料。
你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。
用户登录是否有次数限制?
是否限制从某些IP地址登录?
如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗?
口令选择有规则限制吗?
是否可以不登陆而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
5.4日志文件
在后台，要注意验证服务器日志工作正常。
日志是否记所有的事务处理?
是否记录失败的注册企图?
是否记录被盗信用卡的使用?
是否在每次事务完成的时候都进行保存?
记录IP地址吗?
记录用户名吗?
5.5脚本语言
脚本语言是常见的安全隐患。
每种语言的细节有所不同。
有些脚本允许访问根目录。
其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。
找出站点使用了哪些脚本语言，并研究该语言的缺陷。
还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
5.6防止SQL注入式攻击
不允许任何直接在页面调用SQL语句，这种情况常发生在系统的后期修改中。
6接口测试
在很多情况下，web站点不是孤立。
Web站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
6.1服务器接口
第一个需要测试的接口是浏览器与服务器的接口。
测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。
测试人员还可以查询数据库，确认事务数据已正确保存。
这种测试可以归到功能测试中的表单测试和数据校验测试中
6.2外部接口
有些web系统有外部接口。
例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。
测试的时候，要使用web接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。
如果商店只使用Visa卡和Mastercard卡，可以尝试使用Discover卡的数据。
（简单的客户端脚本能够在提交事务之前对代码进行识别，例如3表示AmericanExpress，4表示Visa，5表示Mastercard，6代表Discover。
）通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
这种情况在远程抄表中可能会体现到
6.3错误处理
错误处理，页面数据验证,包括突然间断电,输入脏数据等
最容易被测试人员忽略的地方是接口错误处理。
通常我们试图确认系统能够处理所有
升级会员 