WEB测试工作作业流程.doc

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键使用；
在测试中，应遵照由简入繁标准，优异行单个控件功效测试，确保实现无误后，再进行多个控件功效组合测试。