⚫ Web测试是指对基于BS架构的软件产品的测试,通俗点来说就是Web网站的测试。
⚫ 因特网网页是由文字、图形、声音、视频和超级链接等组成的文档。Web测试就是用于验证Web页面是否正常工作的测试。
⚫ 针对Web网站这一特定类型软件的测试,包含了许多测试种类,如功能测试、压力/负载测试、配置测试、兼容性测试、安全性测试等。黑盒测试、白盒测试、静态测试和动态测试都有可能被采用。
⚫ WEB功能性测试是指对产品的各功能进行验证。测试时需要根据功能测试用例,逐项测试、检查产品是否达到用户要求的功能;
⚫ 只需要考虑它的功能点,不需要考虑软件的内部结构及代码;对于Web网站测试,每个独立的功能模块都需要设计单独的测试用例;
⚫ 测试的主要依据为需求规格介绍说明书、详细设计介绍说明书,对于应用模块需要设计者提供基本路径测试方法和测试用例;
⚫ 功能测试是测试中的重点,在实际的测试工作中,由于功能在每一个系统中具有不确定性,所以我们不能采用穷举的方法进行测试。测试工作的重点在于Web站点的功能是否符合需求分析的各项要求。
页面内容测试用于检测Web应用系统提供的以下方面的内容:
⚫ 正确性
⚫ 准确性
⚫ 相关性
-------------页面内容测试是一个对页面细节把控的一个重要环节
链接是Web 网站的一个主要特征,它页面之间切换和引导用户去一些未知地址页面的主要手段。
⚫ 测试所有链接是否按指示的那样确实链接到了应该链接的页面;
⚫ 测试所链接的页面是否存在;
⚫ 保证Web 网站上没有孤立的页面;
⚫ 链接测试可以手动进行,也可以使用工具自动进行。
⚫ 链接测试必须在集成测试阶段完成,也就是说,在整个Web 网站的所有页面开发完成之后就需要进行链接测试。
⚫ Xenu的link sleuth
⚫ W3C的link checker(http://validator.w3.org/checklink)
⚫ 当用户向Web应用系统提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。
⚫ 表单测试主要是模拟表单提交过程,检测其准确性,确保每一个字段在工作中正确。
⚫ 表单就是一些需要在线填写和显示的表格
⚫ 表单有一些标准操作,如确认、保存、提交等
⚫ 表单提交应当模拟用户提交,验证是否完成功能
⚫ 要测试提交操作的完整性,以校验提交给服务器的信息的正确性
⚫ 使用表单收集配送信息时,应确保程序能够正确处理这些数据
⚫ 要验证数据的正确性和异常情况的处理能力等,注意是否符合易用性要求
⚫ 在测试表单时,会涉及到数据校验问题
⚫⚫ 例1:
⚫如果使用表单来进行在线注册,要确保提交按钮能正常工作,当注册完成后应返回注册成功的消息。
⚫⚫例2:
⚫ 如果使用表单收集配送信息,应确保系统能够正确处理这些数据,最后能让顾客收到数据包。
⚫ 需要验证服务器能正确保存这些数据;
⚫ 后台运行的程序能正确解释和使用这些信息。
⚫⚫例3:
⚫ 当用户使用表单进行用户注册、登录、信息提交等
操作时,必须测试提交操作的完整性。
⚫ 用户填写的出生日期与职业是否恰当;
⚫ 填写的所属省份与所在城市是否匹配;
⚫ 如果使用了默认值,还要检验默认值的正确性;
⚫ 如果表单某个字段只能接受指定的某些值,则对这个字段也要进行测试。
⚫ Cookie是由网页服务器放在用户端的小的文本文件. 它本质上就像用户的身份证明一样,并且不能像代码那样被执行。
⚫ 查看某个网站颁发的Cookie很简单。在浏览器地址栏手动输入javascript:alert (document. cookie)就可以了(需要有网才能查看)。JavaScript脚本会弹出一个对话框显示本网站颁发的所有Cookie的内容,如图所示:
• Cookies是否能正常工作;
• Cookies是否按预定的时间进行保存;
• 刷新对Cookies 有什么影响等。
⚫ 如果在cookies 中保存了注册信息,应确认该cookie 能够正常工作而且已对这些信息进行加密。
⚫ 如果使用cookie 来统计次数,需要验证次数累计正确。
⚫ 在使用数据库Web应用系统中,一般情况下可能发生两种情况,分别是数据错误和输出错误,数据错误主要是由于用户提交表单信息不正确而造成,而输出主要是由于网络速度或设计问题等引起的,针对这两种情况可分别进行测试。
⚫ 数据库测试的主要考虑因素:数据完整性、数据有效性和数据操作和更新。
⚫ 数据库的设计概念;
⚫ 数据库的风险评估;
⚫ 了解设计中的安全控制机制;
⚫ 了解哪些特定用户对数据库有访问权限;
⚫ 了解数据的维护更新和升级过程;
⚫ 当多个用户同时访问数据库处理同一个问题,或者并发查询时,确保可操作性。
⚫ 确保数据库操作能够有足够的空间处理全部数据,当超出空间和内存容量时能够启动系统扩展部分。
⚫ 导航描述了用户在页面内的操作方式,在不同用户接口控制之间例如按钮、对话框、列表和窗口等; 或者在不同的连接页面之间通过考虑下
列问题可以决定Web应用系统是否易于导航:
a) 导航是否直观?
b) Web系统主要部分是否可通过主页存取?
c) Web系统是否需要站点地图、搜索引擎或其他导航帮助?
⚫ 在单个页面上放太多信息往往起到和预期相反效果,Web应用系统用户趋向于很快地扫描每个Web应用系统,看是否有满足自己需要的信
息,如果没有就会很快地离开,很少有用户愿意花时间去熟悉Web应用系统结构,因此,Web应用系统导航帮助要尽可能地准确。
⚫ 导航的另外一个重要方面是Web应用系统的页面结构、导航、菜单、连接风格是否一致,确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方?
⚫ Web应用系统的层次一旦决定,就要着手测试用户导航功能,越早让最终用户参与这种测试,效果将更加明显。
⚫ 在Web应用系统中,适当的图片和动画既能起到广告宣传作用,又能起到美化页面功能,一个Web应用系统的图形可以包括图片、动画、
边框、颜色、字体、背景、按钮等。图形测试一般的内容有:
1)所有页面字体的风格是否一致
2)背景颜色、字体颜色、前景颜色是否搭配
3)每个页面的提示字体的颜色、格式是否统一准确 。
4)图片尺寸要尽量地小,并且要能清楚地说明某件事情、链接到某个具体页面
⚫ 内容测试用来检验Web 网站提供信息的正确性、准确性和相关性。信息正确性是指信息是可靠还是误传,例如在商品价格列表中,价格
可能引起财政问题甚至导致法律纠纷;
⚫ 信息准确性是指是否有语法或拼写,这种测试通常使用一些文字处理软件来进行例如使用Microsoft Word“拼音和语法检查”功能;
⚫ 信息相关性是指是否在当前页面可以找到和当前浏览信息相关信息列表或入口,也就是Web站点中所谓“相关文章列表”。
⚫ 整体界面是指整个Web应用系统的页面结构设计,是否给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适?是否凭直觉就知道要找信息在什么地方?整个Web应用系统设计风格是否一致?
⚫ 对整体界面测试过程其实是对最终用户进行调查的过程,一般Web应用系统可以采取在主页上做个调查问卷形式来得到最终用户反馈信息。
⚫ 对所有可用性测试来说都需要有外部人员(和Web应用系统开发没有联系或联系很少的人员)参与,最好是最终用户参与。
⚫ 市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web 网站的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。
⚫ 同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。
⚫ 在Web 系统发布之前,需要在各种操作系统下对Web 系统进行兼容性测试。
⚫ 浏览器是Web系统客户端最核心的软件,来自不同厂商的浏览器对Java、JavaScript、ActiveX、plug-ins 或不同的HTML 有不同的支持。
⚫ 另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不能显示。不同的浏览器对安全性和Java 的设置也不一样。
⚫ 测试浏览器兼容性的方法是创建一个兼容性矩阵,并在这个矩阵中测试不同厂商、版本浏览器对某些构件和设置适应性
⚫ 页面版式在 640x400、600x800 或1024x768 分辨率模式下是否显示正常?
⚫ 字体是否太小以至于无法浏览? 或者是太大?
⚫ 文本和图片是否对齐?
⚫ 某些数据需要进行信息加密和过滤后才能进行数据传输,例如用户信用卡信息、用户登陆密码信息等。
⚫ 目前的加密算法越来越多,越来越复杂,但一般数据加密的过程时可逆的,也就是说能进行加密,同时需要能进行解密。
⚫ WEB应用系统需要有是否超时的限制,当用户长时间不作任何操作的时候, 需要重新登录才能使用其功能。
⚫ 在服务器上,要验证服务器的日志是否正常工作。
⚫⚫例如:
⚫ CPU的占用率是否很高?
⚫ 是否有例外的进程占用?
⚫ 所有的事务处理是否被记录等
⚫ WEB的目录安全是不容忽视的一个因素。
⚫ 如果WEB程序或WEB服务器的处理不适当,通过简单的URL替换和推测,会将整个WEB目录完全暴露给用户,这样会造成很大的风险和安全性隐患。
⚫ 我们可以使用一定的解决方式,如在每个目录访问时有index.htm,或者严格设定WEB服务器的目录访问权限,将这种隐患降低到最小程度。通过对目录进行安全测试,确保目录不可以被越权访问。
性能测试主要包括以下内容:
⚫ Web 服务处于分布式计算的核心位置,它们之间的交互通常很难测试。
⚫ 分布式开发可能使 Web 服务的开发变得越来越容易隐藏错误。
⚫ 压力测试是检测这类代码错误的一种有效方法
⚫压力测试目的是要弄清楚被测试的Web 服务是不是不仅能做我们认为它能做的事,而且在被施加了某些高强度压力的情况下仍然继续正常运行
设计对Web 服务进行压力测试的测试系统时,要让它们以某种特定的方式运行代码,这种做法超越了功能验证。
压力测试必须对 Web 服务应用以下四个基本条件进行有效的压力测试。
测试的重复就是一遍又一遍地执行某个操作或功能。比如重复调用一个 Web 服务,确定每次操作能否正常执行。
并发是同时执行多个操作的行为。换句话说,就是在同一时间执行多个测试,例如在同一个服务器上同时调用许多 Web 服务。
压力测试系统应该应用于产品的另一个条件,需要考虑每个操作中的负载量,即要尽量给产品增加负担。
例如,改变数据的大小、改变时间延迟的长度、资金数量的转移、输入速度以及输入的变化等。
任何压力系统都多多少少具有一些随机性。随机使用前面的压力原则中介绍的变化形式,就能够在每次测试运行时应用许多不同的代码路径。
用户连接方式的不同:
⚫ 电话拨号上网
⚫ 宽带上网
⚫ 局域网
⚫ 有线电视网
⚫ 光纤网
规范:
⚫ 不管用户使用哪种方式连接,系统都不能让用户过长的等待。
⚫ 连接速度测试的目的,就是要保证Web系统能够在许可的时间内响应用户的请求。
⚫ 如果访问一个页面Web 系统响应时间太长(例如超过5 秒钟),用户就会因失去耐心而离开。
⚫ 有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登录了。
⚫ 如果连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。
负载测试是为了测量Web 系统在某一负载级别上的性能,以保证Web 系统在需求范围内能正常工作。
⚫ 某个时刻同时访问Web 系统的用户数量;
⚫ 在线数据处理的数量。
⚫⚫例如:
⚫ 系统最多能允许多少个用户同时在线?
⚫ 如果超过了这个数量,会出现什么现象?
⚫ 系统能否处理大量用户同时对同一个页面的请求?
关于添加功能主要测试以下几方面:
⚫ 只填写界面上标识的必填数据项(即标识号的数据项)。*
⚫对于必填项在页面上是否有提示信息(例如必填项加注释,且在页面上是否存在的含义)。
⚫ 各个必填项分别为空,进行保存。
⚫ 各个必填项分别为空格,进行保存。
⚫ 所有允许重复的数据项分别输入或选择系统中已经存在的信息,其它数据为合法数据,进行保存。
⚫ 所有不允许重复的数据项分别输入系统中已经存在的数据,进行保存。
⚫ 所有不允许重复的数据项分别将重复的内容加上前、后空格,进行保存。
⚫ 所有不允许重复的数据项是否区分大小写
⚫ 各个数据项分别输入超出需求中最大有效长度的内容,其它数据项为合法数据,进行保存。
⚫ 各个数据项分别输入等于需求中最大有效长度的内容,其它数据项为合法数据,进行保存。
⚫ 各个数据项分别输入小于需求中最小有效的长度的内容,其它数据项为合法数据,进行保存。
⚫ 各个数据项分别输入小于需求中最小有效的长度的内容,其它数据项为合法数据,进行保存。
⚫ 各个数据项分别输入在长度范围内的内容,其它数据项为合法数据,进行保存。
⚫⚫ 注意:测试大于、小于边界时尽量采用刚刚小于、刚刚大于的数据进行测试。
⚫ 各数据项分别输入非法字符。
⚫ 各数据项分别输入特殊字符(例如:通配符、HTML代码等特殊字符)。
⚫ 对于允许输入汉字的数据项分别输入汉字(验证是否显示正确)。
⚫ 若当输入非法数据时不允许输入,则需要验证粘贴的方式是否可以通过。
⚫ 各个数据项分别输入各种符合要求的数据,进行保存。
⚫⚫ 例如:系统中允许输入“数字、字母、下划线”,则测试添加时应该对数字、字母、下划线是否允许保存均进行判断。
⚫⚫ 目的:验证需求中允许输入的字符与系统实际限制是否一致
1)添加完数据将其删除后又重新添加。
2)添加的数据为非法数据时点击【Enter】键。
3)输入一些提交失败的数据,验证是否给出相应的提示并且界面上添加的数据是否仍保留。
4)成功提交后,进行back然后再提交。
5)成功添加数据后相关联模块是否同步更新。
6)若页面存在【重置】按钮:
a、进入页面直接点击【重置】按钮。
b、所有字段都输入数据,点击【重置】按钮。
c、单选按钮、下拉列表、复选框等都变成非默认的状态,点击【重置】按钮。
7)若页面存在【取消】或【返回】按钮:输入数据后,点击此按钮。
8)验证保存时是否会给予相应的提示?
若存在提示信息是否按照所选项执行?即:
a、点击【确定】按钮是否执行保存操作。
b、点击【取消】按钮是否撤销保存操作且界面上添 加的数据是否仍保留。
测试修改功能与添加功能的要点有一部分相同。
此外还需要对以下的内容进行测试:
1、检查添加和修改信息的限制是否一致。
1)添加中规定必填的数据项,修改时是否也为必填。
2)添加中规定输入的数据类型,修改时是否也为此类型。
3)添加中规定不允许重复的数据项,修改时是否 也不允许重复。
4)添加时规定输入的长度范围,修改时是否也为此范围。
2、进入修改页面,页面数据显示的是否正确,是否为添加时的数据?
3、不允许重复的数据项是否允许重复,允许重复的数据是否允许重复?
⚫⚫ 特别需要注意是否允许与自己重复。
4、需求中不允许修改的数据项是否允许修改?
5、成功修改数据后相关联的模块是否同步更新?
6、进入修改页面,若页面存在【重置】按钮。则需要验证修改数据后,点击【重置】按钮,数据是重置为空还是重置成进入页面时的数据?
⚫⚫ 特别需要注意下拉列表、单选按钮、复选框等数据显示是否正确。
删除功能常用的测试方法:
1、不选择数据,进行删除。
2、删除一个已经被删除的数据。
方法:在浏览器中同时打开2个相同的页面,在其中的一个页面将数据删除,删除成功后,在另一个页面不刷新的情况下也删除此条数据。
3、在末页将所有的数据删除,查看页面跳转是否正确?
4、若同时存在批量删除和单条删除的功能,则需要验证选择多条数据后,点击单条删除功能的按钮,系统是删除一条数据还是删除多条数据?
5、删除时是否会给予相应的提示? 若存在提示信息是否按所选项执行?即:
1)点击【确定】按钮是否执行删除操作?
2)点击【取消】按钮是否撤销删除操作?
6、删除存在关联关系的数据,是否允许删除?
1)若不允许删除:提示信息是否正确并且是否说明删除失败的原因?
2)若允许删除:相关联的数据如何处理?是否给予明确的提示信息让用户了解删除后的后果?
7、删除正在被使用的数据查看系统如何处理?
⚫ 查询功能常用的测试方法:
1、不输入查询条件,进行查询。
2、是否能按照系统默认的查询条件进行查询。
3、单独遍历各个查询条件:
1) 输入的查询条件为系统中不存在的。
2)执行精确查询。
3)执行模糊查询。
4)查询条件中加上前、后空格。
5)输入特殊字符进行查询(通配符、双引号等)。
6)对于在系统中大小写没有区分的数据项,查询条件分别输入大写和小写进行查询。
4、各种查询条件随机进行组合查询。
5、以不同的权限登录时,统计、查询是否正确。
6、验证执行查询后,查询条件是否保留?(尤其注意下拉列表数据显示是否正确)
7、设置条件查询出记录后,翻到最后一页,再更改查询条件进行查询(但第一个查询条件查询出来的记录页数必须多于第二个查询条件查询出来的记录页数)。
8、系统存在多个查询条件时,是否存在【重置】按钮?若存在【重置】按钮,重置按钮是否完成其功能?
9、输入查询条件后,点击【回车】键,验证系统如何处理?
10、在查询或统计大数据量时,系统是否允许终止该操作?
翻页功能一般测试以下几个方面:
1)有、无数据时控件的显示情况是否正确?
2)在非首页和非末页时,四个按钮功能是否正确?
3)当页面位置为首页时,点击【上一页】、【首页】按钮。
4)当页面位置为末页时,点击【下一页】、【末页】按钮。
1)页码为空,进行跳转。
2)页码为空格,进行跳转。
3)页码为负数,进行跳转。
4)页码输入小数,进行跳转。
5)页码输入的为非数字(字母、汉字、特殊字符等)。
6)页码输入0进行跳转。
7)页码输入的为刚刚大于总页数的数字。
8)页码输入超长数字。
1)总页数是否等于总的记录数/指定每页条数?
2)当前页数、总页数显示是否正确?
1)是否有默认的指定每页显示条数?
2)指定每页的条数后,列表显示的记录数、总页数是否正确?
3)每页记录数若允许手动输入,输入非法字符系统如何处理?
⚫ 翻页后,列表中的记录是否仍按照指定的排序列进行了排序?
1)上传一个0K的文件。
2)总大小稍小于限制大小的文件。
3)总大小等于限制大小的文件。
4)总大小稍大于限制的文件。
1)文件名称中包含特殊字符
2)文件名称全为汉字
3)文件名称全为字母
4)文件名称全为数字
5)文件名称为汉字、字母、数字混合
6)文件名称过长
1)上传格式符合要求的文件
2)上传格式不符合要求的文件
1)不选择文件进行上传。
2)上传一个正在打开的文件。
3)文件重复上传(即上传多次相同的文件)。
4)上传文件时若存在多个上传框:
a. 多个框中上传相同的文件
b. 文件间隔着上传(即第一个框上传文件,第二个框不上传文件,第三个框上传文件…)。
5)上传文件的路径若允许手动输入:
a. 手动输入正确的文件路径进行上传
b. 手动输入错误的文件路径进行上传
⚫ 测试导入功能时与上传文件方法有一部分相同。
此外还需要对以下的内容进行测试:
1、文件内的数据都符合要求。
2、文件内的数据部分符合要求,部分不符合要求。
3、文件内的数据全部不符合要求。
4、文件内的数据的若干条完全相同。
5、文件内容的个别行为空行(例如:首行、中间行等)。
6、导入存在大量数据的文件,验证系统如何处理:是否允许导入?若允许导入是否存在关于等待的提示信息?是否可以取消此操作?
7、若导入的文件为excel类型,则将工作表名称Sheet1修改为其它名称。
8、导入的文件内容与系统实际限制是否一致:
1)在系统中不允许重复的数据项录入系统中已经存在的数据进行导入。
2)在系统中必填的数据项为空进行导入。
3)在系统中存在长度限制的数据项输入大于、等于系统要求最大长度的数据进行导入。
4)在系统中存在长度限制的数据项输入小于、等于系统要求最小长度的数据进行导入。
5)在系统中对输入内容存在限制的数据项输入非法字符进行导入。
1、导出时是否允许选择路径?
2、列表为空时进行导出操作。
3、列表中的数据为多页时进行导出操作。
4、导出时选择直接打开文件,查看导出结果是否正确?
5、导出时选择保存文件,查看文件格式和导出内容是否正确?
6、若存在导出查询结果功能,则需要验证执行查询后导出的结果是否正确?
7、若存在选择导出的功能,则需要验证:
1)选择数据后进行导出的结果是否正确?
2)不选择数据进行导出,系统如何处理?
8、导出大量的数据,验证时间是否在合理时
间范围内。
9、导出时选择存放位置的磁盘空间已满,验证系统如何处理?
10、导出时选择存放位置的文件夹为只读文件夹,验证导出时系统如何处理?
⚫⚫ 界面测试是从最终的使用者用户的角度来看软件,软件难以理解,不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面:
⚫ 验证软件是否易于理解、是否方便使用。
⚫ 检查页面上的表单、按钮、窗体、提示信息、文字拼写等是否正确以及是否存在错别字
1)系统页面的风格是否一致,如字的大小、颜色、字体要相同。
2)提示信息的表达方式是否一致。
3)按钮排列顺序是否一致。
4)back, cancel等按钮跳转页面处理是否一致。
5)相同字段的名称、长度、类型在不同位置是否一致。
1)提示信息是否友好。
2)执行风险操作时系统是否给出提示信息让用户确认是否继续操作。
3)页面分辨率检查,在各种分辨率浏览系统检查系统界面友好性。
4)页面进行最大化、最小化还原时是否做了相应的处理。
进行添加、修改、删除、返回等操作后,查看信息回到的页面是否合理?