WEB测试方法

WEB测试方法

 

在Web工程过程当中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工做。基于Web的系统测试与传统的软件测试不一样，它不但须要检查和验证是否按照设计的要求运行，并且还要测试系统在不一样用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。所以，咱们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
本文将 web 测试分为 6 个部分：

功能测试

性能测试（包括负载/压力测试）

用户界面测试

兼容性测试

安全测试

接口测试
1
功能测试
1.1
连接测试
连接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。连接测试可分为三个方面。首先，测试全部连接是否按指示的那样确实连接到了该连接的页面；其次，测试所连接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有连接指向该页面，只有知道正确的URL地址才能访问。
1.2
表单测试
当用户经过表单提交信息的时候，都但愿表单能正常工做。
若是使用表单来进行在线注册，要确保提交按钮能正常工做，当注册完成后应返回注册成功的消息。若是使用表单收集配送信息，应确保程序可以正确处理这些数据，最后能让顾客收到包裹。要测试这些程序，须要验证服务器能正确保存这些数据，并且后台运行的程序能正确解释和使用这些信息。
当用户使用表单进行用户注册、登录、信息提交等操做时，咱们必须测试提交操做的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。若是使用了默认值，还要检验默认值的正确性。若是表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时能够跳过这些字符，看系统是否会报错。
1.3
数据校验
若是系根据业务规则须要对用户输入进行校验，须要保证这些校验功能正常工做。例如，省份的字段能够用一个有效列表进行校验。在这种状况下，须要验证列表完整并且程序正确调用了该列表(例如在列表中添加一个测试值，肯定系统可以接受这个测试值)。
在测试表单时，该项测试和表单测试可能会有一些重复。
1.4
cookies测试
Cookies一般用来存储用户信息和用户在某应用系统的操做，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来建立动态和自定义页面或者存储登录等信息。
　若是Web应用系统使用了Cookies，就必须检查Cookies是否能正常工做。测试的内容可包括Cookies是否起做用，是否按预约的时间进行保存，刷新对Cookies有什么影响等。若是在 cookies 中保存了注册信息，请确认该 cookie可以正常工做并且已对这些信息已经加密。若是使用 cookie 来统计次数，须要验证次数累计正确。
1.5
数据库测试
在Web应用技术中，数据库起着重要的做用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最经常使用的数据库类型是关系型数据库，可使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，通常状况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是因为用户提交的表单信息不正确而形成的，而输出错误主要是因为网络速度或程序设计问题等引发的，针对这两种状况，可分别进行测试。
1.6
应用程序特定的功能需求
最重要的是，测试人员须要对应用程序特定的功能需求进行验证。尝试用户可能进行的全部操做：新增、修改、删除、查询等等。这是用户之因此使用网站的缘由，必定要确认网站能像广告宣传的那样神奇。
2
性能测试
2.1
链接速度测试
用户链接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户能够等较长的时间，但若是仅仅访问一个页面就不会这样。若是Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，若是响应速度太慢，用户可能还没来得及浏览内容，就须要从新登录了。并且，链接速度太慢，还可能引发数据丢失，使用户得不到真实的页面。
2.2
负载压力测试
在这里的负载\压力和功能测试中的不一样,他是系统测试的内容,是基本功能已经经过后进行的.能够在集成测试阶段,亦能够在系统测试阶段进行。

使用负载测试工具进行,虚拟必定数量的用户看一看系统的表现,是否知足定义中的指标。负载测试通常使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的内容都是编写出测试脚本，脚本中通常包括用户通常经常使用的功能，而后运行，得出报告。负载测试技术在各类极限状况下对产品进行测试 (如不少人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。例如，使用压力测试工具对web服务器进行压力测试. 本项测试能够帮助找到一些大型的问题，如死机、崩损、内存泄漏等，由于有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，可是若是运行了成千上万次，内存泄漏得愈来愈多，就会致使系统崩滑。
3
用户界面测试

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。并且设计良好的界面可以引导用户本身完成相应的操做，起到向导的做用。同时界面如同人的面孔，具备吸引用户的直接优点。设计合理的界面能给用户带来轻松愉悦的感觉和成功的感受，相反因为界面设计的失败，让用户有挫败感，再实用强大的功能均可能在用户的畏惧与放弃中付诸东流。目前界面的设计引发软件设计人员的重视的程度还远远不够，直到最近网页制做的兴起，才受到专家的青睐。并且设计良好的界面因为须要具备艺术美的天赋而遭拒绝。
3.1
窗口：


窗口是否基于相关的输入和菜单命令适当地打开？

窗口可否改变大小、移动和滚动？
窗口中的数据内容可否用鼠标、功能键、方向键和键盘访问？

当被覆盖并从新调用后，窗口可否正确地再生？
须要时可否使用全部窗口相关的功能？
全部窗口相关的功能是可操做的吗？
是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其余控制可为窗口使用，并适当地显示？
显示多个窗口时，窗口的名称是否被适当地表示？
活动窗口是否被适当地加亮？
若是使用多任务，是否全部的窗口被实时更新？
屡次或不正确按鼠标是否会致使没法预料的反作用？
窗口的声音和颜色提示和窗口的操做顺序是否符合需求？
窗口是否正确地被关闭？
3.2

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 的分辨率模式下是否显示正常? 字体是否过小以致于没法浏览? 或者是太大? 文本和图片是否对齐?
5

安全测试
主要是测试系统在没有受权的状况下，内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据的安全。测试人员能够学习一些黑客技术，来对系统进行攻击。
5.1
登陆
有些站点须要用户进行登陆，以验证他们的身份。这样对用户是方便的，他们不须要每次都输入我的资料。你须要验证系统阻止非法的用户名/口令登陆，而可以经过有效登陆。用户登陆是否有次数限制? 是否限制从某些 IP 地址登陆? 若是容许登陆失败的次数为3，你在第三次登陆的时候输入正确的用户名和口令，能经过验证吗? 口令选择有规则限制吗?
是否能够不登录而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登录后在必定时间内（例如15分钟）没有点击任何页面，是否须要从新登录才能正常使用。
6
接口测试
数据通常经过接口输入和输出，因此接口测试是白盒测试的第一步。每一个接口可能有多个输入参数，每一个参数有“典型值”、“边界值”、“异常值”之分，因此输入的组合数可能并很多。根据接口的定义，能够推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。若是实际输出与指望的输出不一致，那么说明程序有错误。
6.1
服务器接口
第一个须要测试的接口是浏览器与服务器的接口。测试人员提交事务，而后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还能够查询数据库，确认事务数据已正确保存。
6.2
外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减小欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。
6.3
错误处理
最容易被测试人员忽略的地方是接口错误处理。一般咱们试图确认系统可以处理全部错误，但却没法预期系统全部可能的错误。尝试在处理过程当中中断事务，看看会发生什么状况？订单是否完成？尝试中断用户到服务器的网络链接。尝试中断 web 服务器到信用卡验证服务器的链接。在这些状况下，系统可否正确处理这些错误？是否已对信用卡进行收费？若是用户本身中断事务处理，在订单已保存而用户没有返回网站确认的时候，须要由客户表明致电用户进行订单确认。
7
测试点
7.1
文本框的测试
测试方法：
　a,输入正常的字母或数字。
　b,输入已存在的文件的名称；
　c,输入超长字符。例如在“名称”框中输入超过容许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序可否正确处理；
　d,输入默认值，空白，空格；
　e,若只容许输入字母，尝试输入数字；反之；尝试输入字母；
　f,利用复制，粘贴等操做强制输入程序不容许的输入数据；
　g,输入特殊字符集，例如，NUL及\n等；
　h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
　i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示
7.2
命令按钮测试

 

测试方法：

 

   a,点击按钮正确响应操做。如，单击肯定，正确执行操做；单击取消，退出窗口；

　b,对非法的输入或操做给出足够的提示说明，如，输入月工做天数为32时，单击“肯定”后系统应提示:天数不能大于31；
　c,对可能形成数据没法恢复的操做必须给出确认信息，给用户放弃选择的机会；

 

7.3
单选按钮的测试

 

测试方法：

 

a,一组单选按钮不能同时选中，只能选中一个。

　
b,逐一执行每一个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
　
c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；

 

7.4
组合列表框的测试

 

测试方法：

 

a,条目内容正确，其详细条目内容能够根据需求说明肯定；

　
b,逐一执行列表框中每一个条目的功能；
　
c,检查可否向组合列表框输入数据；

 

7.5
复选框的测试

 

测试方法：

    a,多个复选框能够被同时选中；

　b,多个复选框能够被部分选中；
　c,多个复选框能够都不被选中；
　d,逐一执行每一个复选框的功能；

 

7.6
列表框控件的测试

 

测试方法：

   a,条目内容正确；同组合列表框相似，根据需求说明书肯定列表的各项内容正确，没有丢失或错误；

　b,列表框的内容较多时要使用滚动条；
　c,列表框容许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的状况；

 

7.7
滚动条控件的测试

 

要注意一下几点：

    a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；

　b,拖动滚动条，检查屏幕刷新状况，并查看是否有乱码；
　c,单击滚动条；
　d,用滚轮控制滚动条；
　e,滚动条的上下按钮。

 

7.8
各类控件在窗体中混和使用时的测试

 

　a,控件间的相互做用；
　b,tab键的顺序，通常是从上到下，从左到右；
　c,热键的使用，逐一测试；
　d,enter键和esc键的使用；

 

 

在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的功能组合的测试。