Web测试

Web测试主要分为六个部分:功能测试、性能测试、用户界面测试、兼容性测试、安全测试、接口测试

1. 功能测试

1.1链接测试

链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。

1. 采取措施:采用自动检测网站链接的软件来进行。

2. 推荐软件:

3. Xenu Link Sleuth免费绿色免安装软件

4. 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来统计次数,需要验证次数累计正确。

采取措施:

1采用黑盒测试:采用上面提到的方法进行测试

2采用查看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等也要进行验证。

暂时没有方法测试,可以多参考一点讨论组内的更新信息

1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。

2. 相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。

3. 检查按钮的功能是否正确:如update, cancel, delete, save等功能是否正确。

4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

13. 重复提交表单:一条已经成功提交的纪录,back后再提交,看看系统是否做了处理。

14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

17. 上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。

18. 必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加*

19. 快捷键检查:是否支持常用快捷键,如Ctrl+C Ctrl+V Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。

20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

 

2.性能测试

 1.连接速度测试:测试页面链接的速度,系统需要重新登录的时间

 2.负载测试:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

 3.压力测试:压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。

  压力测试的区域包括表单、登陆和其他信息传输页面等。

3.用户界面测试

1.导航测试:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

页面结构、导航、菜单、连接的风格是否一致
2. 图形测试:

1) 要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

2)验证所有页面字体的风格是否一致。

3)背景颜色应该与字体颜色和前景颜色相搭配。

4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩,

5)最后,需要验证的是文字回绕是否正确。如果说明文字指向右边的图片,应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。

3.内容测试:检验Web应用系统提供信息的正确性、准确性和相关性。

4.表格测试:用户是否需要向右滚动页面才能看见产品的价格?把价格放在左边,而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽,表格里的文字是否都有折行?是否有因为某一格的内容太多,而将整行的内容拉长?

5.整体界面测试:界面测试主要从窗体及窗体中的控件两方面来考虑。

4. 兼容性测试

1.平台测试:在各种操作系统下对Web系统进行兼容性测试。

2.浏览器测试:创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

3.分辨率测试:页面版式在不同的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

4.连接速率:

5.打印机测试:需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

6.组合测试:根据实际情况,采取等价划分的方法,列出兼容性矩阵

5.安全测试

1.目录设置:Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面,这样就不会显示该目录下的所有内容。

2. SSL:如果开发部门使用了SSL,测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器,这些浏览器不支持SSL。当用户进入或离开安全站点的时候,请确认有相应的提示信息。是否有连接时间限制?超过限制时间后出现什么情况?

3.登录:用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3,你在第三次登录的时候输入正确的用户名和口令,能通过验证吗? 口令选择有规则限制吗?  是否可以不登陆而直接浏览某个页面?Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

4.日志文件:日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?

5.脚本语言:测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

6.接口测试

1.服务器接口:浏览器与服务器的接口。测试人员提交事务,然后查看服务器记录,并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库,确认事务数据已正确保存。

2.外部接口: 测试的时候,要使用 web 接口发送一些事务数据,分别对有效信用卡、无效信用卡和被盗信用卡进行验证。

通常,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。这种情况在远程抄表中可能会体现到

3.错误处理:尝试在处理过程中中断事务,看看会发生什么情况?订单是否完成?尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下,系统能否正确处理这些错误?是否已对信用卡进行收费?

采取措施:在理解需求的基础上,充分发挥想象力,尽量比较全面的列出各种异常情况。

1窗体的测试

1          窗体的大小。窗体的大小要合适,使内部控件布局合理,不过于密集,也不过于空旷。

2          窗体的位置。对于主窗体,其正中应该与显示屏正中一致;对于子窗体,一般应在父窗体显示区的中间。

3          移动窗体。快速或慢速移动窗体,背景及窗体本身刷新必须正确。

4          缩放窗体。

4.1         鼠标拖动。

4.1.1    对于固定大小的窗体,鼠标拖动不能缩放其大小。

4.1.2    对于能用鼠标拖动缩放大小的窗体,放大或缩小窗体后其内容也应做相应调整。

4.2         单击‘最大化’按钮。窗体被最大化,内部控件大小或位置也应做相应调整。

4.3         单击‘还原’按钮。应还原到窗体最初默认的大小。

4.4         单击‘最小化’按钮。对于主窗体,应最小化到系统状态栏的左下角,并依次排列;对于窗体中的子窗体,应最小化到父窗体容器的左下角,并依次排列。

5          显示分辨率。通常情况下,计算机的显示分辨率包括800×600、1024×768、1280×1024等等。

【注意】由于程序员在编程时,可能使用了固定的控件大小和位置,不能随分辨率的改变而变化,因此,在分辨率为1024×768下开发的程序在分辨率为800×600时,会出现显示内容被裁切的情况。

6          宽屏和普屏。宽屏和普屏的显示器,界面显示效果可能不一样。

2标题栏的测试

1          标题图标,不同窗体的图标要易于分辨;

1.1         父窗体的标题图标;

1.2         子窗体的标题图标;

1.3         提示信息窗体的标题图标;

1.4         警告信息窗体的标题图标;

1.5         错误信息窗体的标题图标;

2          标题内容,标题的内容要简明扼要,且不能有错别字。

2.1         父窗体的标题内容;

2.2         子窗体的标题内容;

2.3         提示信息窗体的标题内容;

2.4         警告信息窗体的标题内容;

2.5         错误信息窗体的标题内容;

3菜单栏的测试

1          菜单深度最好不超过3层;

2          菜单通常使用5号字体。

3          菜单前的图标不宜太大,与字高保持一致最好。

4          各项菜单是否能完成相应功能?

5          各菜单与其完成的功能是否一致?

6          有无错别字?

7          有无中英文混合?

8          快捷键或热键

8.1         是否有效?

8.2         是否重复?

9          鼠标右键菜单;

10      不可用菜单是否真的不可用?(这在不同权限下会出现。)

4工具栏的测试

1  工具栏中通常使用5号字体,工具栏一般比菜单栏略宽。

2   相近功能的工具栏放在一起。

3    工具栏的按钮要有即时提示信息,图标要能直观的表达要完成的操作。

4    一条工具栏的长度最长不能超过屏幕宽度。

5   系统常用的工具栏设置默认放置位置。

6   工具栏太多时可以考虑使用工具箱,由用户根据自己的需求定制。

5状态栏的测试

1 显示用户切实需要的信息,如:

1.1         目前的操作

1.2         系统的状态

1.3         当前位置

1.4         时间

1.5         用户信息

1.6         提示信息

1.7         错误信息

1.8         如果某一操作需要的时间比较长,还应该显示进度条和进程提示。

2    状态条的高度以放置5号字为宜。

6控件的测试

6.1控件自身的测试

1 控件本身的大小

2 控件本身的位置

3 控件字体

3.1字体的大小(与界面其它控件保持一致性)

3.2 字体半角/全角

3.3 中英文混合(一般情况下不允许中英文混合)

3.4 错别字

6.2控件的功能测试

6.2.1文本框

1 作用:接受用户输入的数据或显示数据。

2状态:可编辑(正在编辑、未编辑)、不可编辑。

3 测试点:

3.1  根据文本框作用:

3.1.1   接受输入数据

 输入数据的内容(如输入空格或与已存在内容相冲突的数据等)

 输入数据的长度(如只能输入8位,分别输入7、8、9位数据进行测试)

 输入数据的类型(如只能输入数字,分别输入汉字、字母、特殊符号等)

 输入数据的格式(如‘yyyy/mm/dd’)

3.1.2   显示数据

 显示内容是否正确?

 内容太长,文本框不能完全显示时,是否有未完全显示的提示?如加‘…’

 显示内容格式是否正确?

3.2  根据文本框状态:

3.2.1   可编辑文本框与不可编辑文本框是否易于区分?(一般将不可编辑文本框置灰)

3.2.2   光标选中的可编辑文本框是否有明显显示?(如文本框底色由白色变为蓝色)

【注意】对于在文本框中输入的错误数据,程序一般有以下3种处理方式:

 不允许输入,没有任何提示。

 输入后立即给出提示要求重新输入。

 单击窗体中的‘确定’或‘保存’或‘提交’按钮以后,程序再检验数据的正确性,不正确就给出提示要求重新输入。

在设计文档中没有特别注明需采用哪种处理方式时,无论哪种方式,只要能正确验证数据就可以。

6.2.2 Up-down控件文本框

1 作用:通过控件的上下箭头,选择不同的值。

2 状态:可用、不可用。

3 测试点:

3.1 直接输入或上下箭头选择;

3.2 边界值

3.3 默认值

3.4 输入非法数据

3.5 若该控件不可用,是否有标识?且是否真的不可用?

6.2.3组合列表框(下拉列表框)

1 作用:下拉列表中显示一组数据,选中某一条数据,该数据就返回到框中。

2 状态:可用、不可用。

3 测试点:

3.1 条目内容是否正确?(根据需求说明书确定其内容)

3.2 条目功能是否实现?(有些程序要求在获得条目内容的同时,获得该条目对应的编号,但是编号在窗体上不显示,此时就要在数据库中查看结果是否正确?)

3.3 是否能输入数据?(一般程序不允许输入数据。)

3.4 若该控件不可用,是否有标识?且是否真的不可用?

6.2.4列表框

1作用:列表框中显示一组数据,选中某一条/或某几条数据,程序进行某种处理。

2 状态:可用、不可用。

3 测试点:

3.1 条目内容是否正确?(根据需求说明书确定其内容)

3.2 条目功能是否实现?

3.3 滚动条是否可以滚动?(针对列表框内容较多时)

3.4 条目内容宽度超过列表框的宽度时,鼠标指针位于该条目时是否可以完整显示?

3.5 是否允许多选?(若允许,要分别检查按Shift选中、按Ctrl选中条目和直接用鼠标选中多项条目时的情况。)

3.6 若该控件不可用,是否有标识?且是否真的不可用?

6.2.5命令按钮

1 作用:实现规定的功能。

2 状态:可用、不可用。

3 测试点:

3.1 可操作按钮功能是否实现?

3.2 对可能造成数据无法恢复的操作是否提供确认信息?(如删除等操作)

3.3 对不符合业务要求的输入数据是否有相应的处理方法?

3.4 对非法的输入或操作是否给出足够的提示说明,让用户明白错误出处?

3.5  若该按钮不可用,是否有标识?且是否真的不可用?

6.2.6单选按钮(单选框)

1 作用:同一组中只能选择一个。

2  状态:可选(被选中、不被选中)、不可选。

3  测试点:

3.1 同一组中,是否只能选中一个?

3.2 各项功能是否能正确完成?

3.3 是否有默认被选中的选项?

3.4 可选和不可选项是否易于区分?(一般将不可选项置灰)

3.5 不可选项是否限制不能被选中?

4  举例说明:

如性别组的单选按钮,可选项包括:男、女、未说明,默认为男。

6.2.7复选框

1 。 作用:可同时选中多项。

2  。 状态:可选(选中、未被选中)、不可选。

3  。 测试点:

3.1 是否可以同时全部选中?

3.2是否可以同时部分选中?

3.3 是否可以都不选中?

3.4 各种选中情况下功能的实现?

3.5 是否有默认被选中的选项?

3.6 可选和不可选项是否易于区分?(一般将不可选项置灰)

3.7 不可选项是否限制不能被选中?

6.2.8滚动条

1 。作用:在较多内容情况下,可以通过拖动显示内容。

2 。测试点:

2.1 是否能被拖动?

2.2 拖动滚动条时,屏幕的刷新情况?(是否能及时刷新?是否有乱码?)

2.3 拖动滚动条时,信息的显示情况?

2.4 滚动条的上下按钮是否可用?

2.5 滚动条的大小是否会根据显示信息的长、宽度及时变换?

2.6 滚动条的位置是否能根据选中内容的位置及时移动?

2.7 是否能用鼠标滚轮控制滚动条?

6.3各种控件混合使用时的测试

1  控件间的相互作用。

2 Tab键的顺序。(一般是从上到下,从左到右。)

3  热键的使用。

4  Enter键和ESC键的使用。

5  控件组合后功能的实现。

【注意】测试过程中,应遵循由简到繁的原则,先进行单个控件功能的测试,确保实现无误后,再进行多个控件的功能组合的测试。