Web测试主要分为六个部分:
功能测试、性能测试、用户界面测试、兼容性测试、安全测试、接口测试
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来统计次数,需要验证次数累计正确。
采取措施:
采用黑盒测试:采用上面提到的方法进行测试;
采用查看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、Javascrīpt、ActiveX、VBscrīpt或Perl等也要进行验证。
暂时没有方法测试,可以多参考一点讨论组内的更新信息
页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。
相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。
检查按钮的功能是否正确:如update, cancel, delete, save等功能是否正确。
字符串长度检查:?输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
中文字符处理:?在可以输入中文的系统输入中文,看会否出现乱码或出错.
检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致
信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
重复提交表单:一条已经成功提交的纪录,back后再提交,看看系统是否做了处理。
检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.
search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。
必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加*
快捷键检查:是否支持常用快捷键,如Ctrl+C Ctrl+V Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。
回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.
连接速度测试:测试页面链接的速度,系统需要重新登录的时间;
负载测试:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?
压力测试:压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。
压力测试的区域包括表单、登陆和其他信息传输页面等。
1. 导航测试:
导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?51Testing软件测试网)cvpd+V W8A
页面结构、导航、菜单、连接的风格是否一致
2. 图形测试:
要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
验证所有页面字体的风格是否一致。
背景颜色应该与字体颜色和前景颜色相搭配。
图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩,
最后,需要验证的是文字回绕是否正确。如果说明文字指向右边的图片,应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
3. 内容测试:
检验Web应用系统提供信息的正确性、准确性和相关性。
4. 表格测试:
用户是否需要向右滚动页面才能看见产品的价格?把价格放在左边,而把产品细节放在右边是否更有效??每一栏的宽度是否足够宽,表格里的文字是否都有折行?是否有因为某一格的内容太多,而将整行的内容拉长?
5. 整体界面测试:
界面测试主要从窗体及窗体中的控件两方面来考虑。
参考:http://www.cnblogs.com/haining1993/p/5193137.html
平台测试:在各种操作系统下对Web系统进行兼容性测试。
浏览器测试:创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
分辨率测试:页面版式在不同的分辨率模式下是否显示正常?字体是否太小以至于无法浏览??或者是太大?文本和图片是否对齐?
连接速率:
打印机测试:需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。
组合测试:根据实际情况,采取等价划分的方法,列出兼容性矩阵
目录设置:Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面,这样就不会显示该目录下的所有内容。
SSL:如果开发部门使用了SSL,测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器,这些浏览器不支持SSL。当用户进入或离开安全站点的时候,请确认有相应的提示信息。是否有连接时间限制?超过限制时间后出现什么情况?
登录:用户登录是否有次数限制 是否限制从某些 IP 地址登录 如果允许登录失败的次数为3,你在第三次登录的时候输入正确的用户名和口令,能通过验证吗?口令选择有规则限制吗?是否可以不登陆而直接浏览某个页面?
HuK ]D2 1G-L }8n*N352621Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
日志文件:日志是否记所有的事务处理??是否记录失败的注册企图??是否记录被盗信用卡的使用??是否在每次事务完成的时候都进行保存 记录IP 地址吗?记录用户名吗?
脚本语言:测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。
服务器接口:浏览器与服务器的接口。测试人员提交事务,然后查看服务器记录,并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库,确认事务数据已正确保存。
外部接口: 测试的时候,要使用?web?接口发送一些事务数据,分别对有效信用卡、无效信用卡和被盗信用卡进行验证。
通常,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
错误处理:尝试在处理过程中中断事务,看看会发生什么情况?订单是否完成?尝试中断用户到服务器的网络连接。尝试中断?web?服务器到信用卡验证服务器的连接。在这些情况下,系统能否正确处理这些错误?是否已对信用卡进行收费?
采取措施:在理解需求的基础上,充分发挥想象力,尽量比较全面的列出各种异常情况。
作者:沫沫1890S
原文链接:https://blog.csdn.net/weixin_37600187/article/details/83014741