web测试_web测试流程 - CSDN
web测试 订阅
Web测试是软件测试的一部分,是针对Web应用的一类测试。由于Web应用与用户直接相关,又通常需要承受长时间的大量操作,因此Web项目的功能和性能都必须经过可靠的验证。通过测试可以尽可能地多发现浏览器端和服务器端程序中的错误并及时加以修正,以保证应用的质量。由于Web具有分布、异构、并发和平台无关的特性,因而它的测试要比普通程序复杂的多。 展开全文
Web测试是软件测试的一部分,是针对Web应用的一类测试。由于Web应用与用户直接相关,又通常需要承受长时间的大量操作,因此Web项目的功能和性能都必须经过可靠的验证。通过测试可以尽可能地多发现浏览器端和服务器端程序中的错误并及时加以修正,以保证应用的质量。由于Web具有分布、异构、并发和平台无关的特性,因而它的测试要比普通程序复杂的多。
信息
所属学科
软件工程
外文名
web test
测试工具
Selenium等
测试类型
内容测试、界面测试等
中文名
web测试
目    的
评价web应用性能
Web测试简介
随着网络技术的迅速发展,尤其是Web及其应用程序的普及,各类基于Web的应用程序以其方便、快速、易操作等特点不断成为软件开发的重点。Web以其广泛性、交互性和易用性等特点迅速风靡世界,网页数量正以几何数量级飞速增长。能够吸引尽可能多的用户并对其长时间关注是网站追求的主要目标,也是衡量一个网站是否成功的主要指标,这就对网页功能的正确性、有效性和完善性提出了较高的要求,从而测试就成为应用开发过程中的一个重要环节。目前可以见到各种Web服务器平台,然而根据Mereur的研究报告,98%的Web服务器都没能达到人们所期望的性能,平均只能发挥人们所期望性能的1/6左右。Web性能测试能够确定影响Web服务器性能的关键因素,从而可以有针对性地进行分析和改进,避免Web服务器研究和优化过程中的盲目行为;同时,它也是选取不同的Web服务器的重要参考。随着Web应用程序使用越来越广泛,针对其性能测试的要求也越来越多,然而由于Web程序综合了大量的新技术,诸如HTML,Java,JavaScript,VBScript等,同时它还依赖很多其他的因素,比如Link,Database,Network等,使得Web应用程序测试变得非常复杂 [1]  。
收起全文
精华内容
参与话题
  • Web测试六大类型

    千次阅读 多人点赞 2018-10-11 17:34:33
    Web测试主要分为六个部分: 功能测试、性能测试、用户界面测试、兼容性测试、安全测试、接口测试 1、功能测试 1.1链接测试  链接是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.21.3的采取措施:第一个完整的版本采用手动检查,同时形成WinRunnerQTP)脚本;回归测试以及升级版本主要靠WinRunnerQTP)自动回放测试

    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.21.3的测试中

    1.6应用程序特定的功能需求

    最重要的是,测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作:下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因,一定要确认网站能像广告宣传的那样神奇。

    采取措施:深刻理解需求说明文档

    1.7设计语言测试

    Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如JavaJavascrīptActiveXVBscrīptPerl等也要进行验证。

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

    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系统是否需要站点地图、搜索引擎或其他的导航帮助?51Testing软件测试网)cvpd+V W8A

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

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

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

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

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

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

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

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

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

    4、 兼容性测试

    参考:http://www.cnblogs.com/haining1993/p/5193137.html

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

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

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

    4.连接速率:

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

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

    5、安全测试

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

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

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

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

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

    6.接口测试

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

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

    通常,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

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

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

    展开全文
  • web测试要点及基本方法

    万次阅读 多人点赞 2018-04-09 22:53:34
    一、 序言在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的...


    一、 序言
    在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。然而,Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
    二、 WEB测试要点及测试方法
    本文的目的是覆盖 web 测试的各个方面,未就某一主题进行深入说明,本文将WEB测试分为 6 个部分:
    1.  功能测试
    2.  性能测试(包括负载/压力测试)
    3.  用户界面测试
    4.  兼容性测试
    5.  安全测试
    6.  接口测试
    1. 功能测试
    链接测试
      链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。
    链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。
    采取措施:采用自动检测网站链接的软件来进行
      推荐软件:
      Xenu Link Sleuth 免费 绿色免安装软件
      HTML Link Validator 共享(30天试用)
    表单测试
    当用户通过表单提交信息的时候,都希望表单能正常工作。
    如果使用表单来进行在线注册,要确保提交按钮能正常工作,当注册完成后应返回注册成功的消息。如果使用表单收集配送信息,应确保程序能够正确处理这些数据,最后能让顾客能让客户收到包裹。要测试这些程序,需要验证服务器能正确保存这些数据,而且后台运行的程序能正确解释和使用这些信息。
    当用户使用表单进行用户注册、登陆、信息提交等操作时,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错;如系统只接受限定以内的数字,测试时可以测试内外边界值,看系统是否可正确反应。
    表单测试还有重要的一点:测试html语言的特殊标记,如<>、<td>、’等,在表单中输入这些字符进行各种操作后看系统是否会报错。
    表单中的数据会经过两次校验:一是脚本校验,在输入时脚本会自动进行初步的判断,判断数据是否合法、二是程序提交时也会对数据的准确性进行校验。此时,测试时注意测试这两次数据校验标准是否一致。
    数据校验
    如果系根据业务规则需要对用户输入进行校验,需要保证这些校验功能正常工作。例如,省份的字段可以用一个有效列表进行校验。在这种情况下,需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值,确定系统能够接受这个测试值)。
    在测试表单时,该项测试和表单测试可能会有一些重复。
    1.2和1.3的采取措施:第一个完整的版本采用手动检查,同时形成QTP脚本;回归测试以及升级版本主要靠QTP自动回放测试。
    cookies测试
    Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。  如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息,请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数,需要验证次数累计正确。
    采取措施:
      1 采用黑盒测试:采用上面提到的方法进行测试
      2 采用查看cookies的软件进行(初步的想法)
      可以选择采用的软件
      IECookiesView v1.50
      Cookies Manager v1.1
    数据库测试 
    在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。 
    在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。 
    采取措施:暂时没有更好的测试方法 
    考虑结合到1.2和1.3的测试中 
    应用程序特定的功能需求 
    最重要的是,测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作:如下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因,一定要确认网站能像广告宣传的那样神奇。 
    采取措施:深刻理解需求说明文档
    设计语言测试 
    Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。
    2. 性能测试 
    连接速度测试 
    用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。 
    另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。 
    负载测试
    负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求? 
    压力测试
    负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。 
    进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。 
    压力测试的区域包括表单、登陆和其他信息传输页面等。 
    负载/压力测试应该关注什么 
    测试需要验证系统能否在同一时间响应大量的用户,在用户传送大量数据的时候能否响应,系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息,他们可能放弃,并转向竞争对手。系统检测不仅要使用户能够正常访问站点,在很多情况下,可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因,测试人员应该知道当系统过载时,需要采取哪些措施,而不是简单地提升系统性能。 
    瞬间访问高峰 
    如果您的站点用于公布彩票的抽奖结果,最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。 
    每个用户传送大量数据 
    网上书店的多数用户可能只订购 1-5 书,但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗? 
    长时间的使用 
    如果站点用于处理鲜花订单,那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务,那么点最好能持续运行几个月,甚至几年。可能需要使用自动测试工具来完成这种类型的测试,因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常,测试工具在第二次使用的时候,它创造的效益,就足以支付成本。而且,测试工具安装完成之后,再次使用的时候,只要点击几下。 
    采取措施:采用测试工具WAS、ACT协助进行测试
    3. 用户界面测试 
    导航测试
    导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?
    在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。
    导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。
    Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。
    图形测试
    在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:
    (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
    (2)验证所有页面字体的风格是否一致。
    (3)背景颜色应该与字体颜色和前景颜色相搭配。
    (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩,最好能使图片的大小减小到 30k 以下
    (5)最后,需要验证的是文字回绕是否正确。如果说明文字指向右边的图片,应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
    通常来说,使用少许或尽量不使用背景是个不错的选择。如果您想用背景,那么最好使用单色的,和导航条一起放在页面的左边。另外,图案和图片可能会转移用户的注意力。
    内容测试
    内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
    信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"。
    对于开发人员来说,可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能,然后开始开发,在开发的时候,开发人员可能不注重文字表达,他们添加文字可能只是为了对齐页面。不幸的是,这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则,公司可能陷入麻烦之中,也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时,最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章,所以相信您也希望自己的站点能更专业一些。最后,需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址,或者从某个站点下载浏览器。但是如果用户无法点击这些地址,他们可能会觉得很迷惑。
    表格测试
    需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格?把价格放在左边,而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽,表格里的文字是否都有折行?是否有因为某一格的内容太多,而将整行的内容拉长
    整体界面测试
    整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?
    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。
    对所有的用户界面测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。
    采取措施:手动测试,参与人员最好有外部人员
    4. 兼容性测试
    平台测试
    市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。
    因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。
    浏览器测试
    浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,Javascrīpt是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
    测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
    分辨率测试
    页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?
    Modem/连接速率
    是否有这种情况,用户使用 28.8 modem下载一个页面需要 10 分钟,但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候,可能会等待比较长的时间,但却不会耐心等待首页的出现。最后,需要确认图片不会太大。
    打印机测试
    用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题,注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕,因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。
    组合测试
    最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错,但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示,但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点,测试可能会轻松一些。如果公司指定使用某个类型的浏览器,那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线,可能不需要测试下载施加。(但需要注意的是,可能会有员工从家里拨号进入系统) 有些内部应用程序,开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是,理想的情况是,系统能在所有机器上运行,这样就不会限制将来的发展和变动。
    采取措施:根据实际情况,采取等价划分的方法,列出兼容性矩阵
    5. 安全测试
      即使站点不接受信用卡支付,安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露,客户在进行交易时,就不会有安全感。
    目录设置
    Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面,这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片,单击鼠标右键,找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径,发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ,点击 jackpot。在该目录下有很多资料,其中引起我注意的是已过期页面。该公司每个月都要更改产品价格,并且保存过期页面。我翻看了一下这些记录,就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息,他们在谈判桌上肯定处于上风。
    SSL
    很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息,而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL,测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器,这些浏览器不支持SSL。当用户进入或离开安全站点的时候,请确认有相应的提示信息。是否有连接时间限制?超过限制时间后出现什么情况?
    登录
    有些站点需要用户进行登录,以验证他们的身份。这样对用户是方便的,他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录,而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3,你在第三次登录的时候输入正确的用户名和口令,能通过验证吗? 口令选择有规则限制吗?  是否可以不登陆而直接浏览某个页面?
    Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
    日志文件
    在后台,要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?
    脚本语言
      脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器,但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言,并研究该语言的缺陷。还要需要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。 
    6. 接口测试
    在很多情况下,web 站点不是孤立。Web 站点可能会与外部服务器通讯,请求数据、验证数据或提交订单。
    服务器接口
    第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务,然后查看服务器记录,并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库,确认事务数据已正确保存。
    这种测试可以归到功能测试中的表单测试和数据校验测试中
    外部接口
          有些 web 系统有外部接口。例如,网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候,要使用 web 接口发送一些事务数据,分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡, 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别,例如 3 表示 American Express,4 表示 Visa,5 表示 Mastercard,6 代表Discover。)通常,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
    这种情况在远程抄表中可能会体现到
    错误处理
          最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误,但却无法预期系统所有可能的错误。尝试在处理过程中中断事务,看看会发生什么情况?订单是否完成?尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下,系统能否正确处理这些错误?是否已对信用卡进行收费?如果用户自己中断事务处理,在订单已保存而用户没有返回网站确认的时候,需要由客户代表致电用户进行订单确认。
    采取措施:在理解需求的基础上,充分发挥想象力,尽量比较全面的列出各种异常情况。
    三、 结论
       无论你在测试 internet、intranet 或者是 extranet 应用程序,web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下,就像业务功能一样,页面用于维护和发展公共关系,所以第一印象非常重要。
    展开全文
  • web网页测试用例(非常实用)

    万次阅读 多人点赞 2018-02-06 15:21:14
    Web测试中,各类web控件测试点总结 一 、界面检查  进入一个页面测试,首先是检查title,页面排版,字段等,而不是马上进入文本框校验  1、页面名称title是否正确  2、当前位置是否可见 您的位置:xxx>xxxx ...
    Web测试中,各类web控件测试点总结
    一 、界面检查
      进入一个页面测试,首先是检查title,页面排版,字段等,而不是马上进入文本框校验
      1、页面名称title是否正确
      2、当前位置是否可见  您的位置:xxx>xxxx
      3、文字格式统一性
      4、排版是否整齐
      5、列表项显示字段是否齐全,列表项字段名称是否跟表单统一
      6、同一页面,是否出现 字段名称相同、值取不同的问题。
      7、数据加载情况:除了文本框的值,还要注意:
      复选框,是否保存打√,或者保存不打√
      下拉框,是否保存选择的值
      多文本框,值是否都被保存,空格,换行是否保存
    二、单文本框(type=text)
      边界:字段长度
      判空:是否可以为空
      唯一性:是否唯一        (小归结:边界、判空、唯一性、特殊字符、正确性)
      考虑语言,操作环境
      特殊符号测试输入:
      ' or 1<>'1   ' or '1'='1  ' or '1'<>'2  "|?><
      where a='xxx'   下划线是否允许  输入全部空格  输入 单引号
      ><script>alert(“123”);</script>>
      特殊字段输入限定:
      框内容是否合法(tel,ip,url,email)序号等,直接限制输入数字,其他过滤掉
      输入金额文本框,整数首位为0,过滤掉,小数点后面,一般保留两个有效数字。
      正确性测试:(必不可少的步骤)
      1)、(字段长度输入最大允许长度时)数据允许长度的测试:
      a、页面是否被挤出的测试(都输入长英文字符串,是否断行);
      b、数据库是否允许最大字符(都输入汉字、都输入英文、混合……);
      c、最短长度的正确流程,最大长度的正确流程覆盖。
      2)、对于允许为空的字段,不填入,再次数据传递后,看是否报500错误。
      3)、未规定字段长度(或者数值大小),不按死板输入,输入非常多字符(或者非常大的数值)时,做允许动作的正确性校验,看是否报错。(要达到的结果:不管有没有长度限制(没有给最长、最大限制让你去测?),最终页面不能抛数据库异常。)monkeytest
      说明:通过不断输入长字符串,看是否有长度校验;
      最终都会出现以下两种情况的一种:
      A、页面(前台)有校验长度、大小;   或者
      B、无校验,数据库报错。
      所以: 所有字段都要做长度、大小限制(不管需求有没有给出明确要求,不管测试颗粒度,都要限制长度,不允许报数据库错误,都要测!!!)。最大长度限制可限定方法:1、不允许再输入;2、自动截断处理,并且给用户提示。
    关于长度概念:
      1、 数据库规定的字节长度A
      2、 页面上可以输入的字符数B
      控制方法:
      1)、页面上,不管输入什么字符(全角如汉字、半角如字母),统一规定不能超过B个字符,此种限制,
      测试点:全部输入全角B个,测试(B*3字节)会不会超过数据库字节长度
      全部输入半角B个,测试(B*1字节)会不会超过数据库字节长度
      混合输入全角X半角Y,测试(X*3+Y字节)会不会超过数据库长度
      2)、页面上,不以字符统计,以总的输入字节数统计,比如,全部输入全角字符,允许可以输入A/3个字符,全部输入半角字符,允许输入A个字符( 民生网的设计)
      测试点:全部输入全角,看是否允许输入A/3个字符
      全部输入半角,看是否允许输入A个字符
      混合输入全角X,半角Y,看是否允许X*3+Y=A
      (5个:判空、唯一、边界值、特殊字符、正确流程(多种数据、多种分支))
      +测试校验位置:ajax鼠标事件校验、前台提交按钮js校验,服务器拿到数据后再次验证
      三、多文本框(type=textarea)
      1)、空格和换行的问题,看需求,是否需要做支持HTML Encoding
      输入全部空格时,是否判空处理?””空格,   。
      输入折行,是否也显示折行?
      比如:列点说明原因,就需要支持。
      2)、字母截断的问题
      对于一串字母,开发人员往往会忘掉做截断,这样如果展示在我们的平台上的话,这一串字母就会把我们的UI撑开
      3)、长度控制格式, 您还可以输入***个字符
      四、添加按钮
      添加动作检查范围:
      失败:是否提示
      提示内容是否正确
      失败时:保存用户已输入的内容,避免重新再输入
      成功:对话框消失
      记录是否可直接查看(还需要刷新?)
      列表记录顺序
      重复提交情况,点击一次后,是否变成disable
      上传附件的添加:
      A. 文件名称:文件名称很长;文件名称字符多样化(汉字,英文,符号);文件名称重复。
      B. 判空?
      C. 附件格式类型支持?
      D. 附件个数?
      E. 附件空间大小。
    五、移除按钮
      1.一般都要在前台先给出一个提示操作“确定移除该……”
      2.相关联的东西,是否需要限制移除“该类型下存在应用,无法移除”有到后台比较
      3.确定后,真正执行移除操作。
      结果:
      移除后,列表数据是否立即消失。
      必须有确认删除的提示信息
      六、列表
      1)、列表记录顺序
      2)、是否需要翻页、有没有翻页功能
      3)、字段名称是否与表单一致


      七、搜索-文本框
      1、功能点、需求点考虑:
      是否提供模糊查询、输入数值有种类有限定时,是否考虑换成下拉框搜索;
      2、检查点:
      文本框值是否消失(是否回填条件值),再次点击“查询”可查看所有记录;
      考虑搜索结果:是否存在分页,分页是否正常;是否有序;
      注意:分页是否仍保存查询条件,检查后面的记录是否符合条件
      3、查询数据多样性:
      输入不存在的字段值测试、包括特殊字符查询测试例如:' or '1'='1;
      输入类似程序语句的条件时是否执行查询,如:XXXX”、XXX and ;
      4、操作类型:
      1) 不输入的查询
      2) 输入全部空格的查询
      3) 模糊查询(输入部分字段,或者说,输入英文字母,查询到相关中文数据)
      4) 输入不存在的查询
      5) 输入存在的查询
      6) 单个查询和多个条件复合查询。
      八、搜索-下拉框
      检查点:
      a) 搜索结果是否有序;
      b) 下拉框值是否齐全;(下拉框值本身也是一个动态查询的结果)
      c) 下拉框值是否自动消失,再次点击“查询”可查看所有记录(是否要回填条件值);
      d) 分页时,是否保存搜索条件。
      (从UI、开发、业务逻辑、用户使用等角度测试)
      PS:
      以上总结的, 是比较纯粹的从页面控件角度测试点出发, 对于完整测试一个整体页面,需要各类测试有机结合起来:
      1)UI测试:
      页面布局; 页面样式检查;控件长度是否够长;显示时,是否会被截断;支持的快捷键,Tab键切换焦点顺序正确性等。
      2)功能测试:页面上各类控件的测试范围,测试点,可参考上方
      结合控件的实际作用来补充检查点: 比如, 密码框是否*显示, 输入是否做trim处理等
      3)安全测试:输入特殊字符,sql注入,脚本注入测试
      后台验证测试,对于较重要的表单 ,绕过js检验后台是否验证
      数据传输是否加密处理,比如, 直接请求转发,地址栏直接显示发送字符串?
      数据库存储,特别密码等,是否加密形式存储
      4)兼容性测试
      5)性能测试




    二.常见功能点测试思路
    根据经验,总结常见的功能点的测试思路:
      1. 新增 或 创建(Add or Create)
      .1 操作后的页面指向
      .2 操作后所有绑定此数据源的控件数据更新,常见的排列顺序为栈Stack类型,后进先出
      .3 取消操作是否成功
      2.编辑 或 更新 (Edit or Update)
      .1 操作后的页面指向
      .2 操作后所有绑定此数据源的控件数据更新
      .3 取消操作是否成功
      .4 编辑界面是否读取出正确、全部的数据源
      .5 记录在工作流中的编辑功能可用性
      .6 操作成功的生效时刻及生效范围
      3.删除 或 移除 (Delete or Remove)
      .1 操作后的页面指向
      .2 操作后所有绑定此数据源的控件数据更新 (如下就是删除后,Tab数据没有立即刷新的bug)
    3 取消操作是否成功
      .4 记录在工作流中的编辑功能可用性
      .5 操作成功的生效时刻及生效范围(比如:购物网站,店家商品下架后,并没有同时删除买家的购买记录)
      4.选中 或 全选 (Check or Check all)
      .1 多页面中,全选对所有页面是否有效
      .2 支持多页面的个别选中,且返回查看时保留选中状态
      .3 界面上的按钮的操作范围是否均受选中功能控制
      .4 前一页选中状态,在翻页后,应保留原来状态
      .5 先全选-》移除某个单选-》全选按钮是否移除选中状态


    谈谈性能测试分类
    性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
      验收性能测试(狭义)   性能测试方法是通过模拟生产运行的业务压力量和使用场景组合,测试系统的性能是否满足生产性能要求。通俗地说,这种方法就是要在特定的运行条件下验证系统的能力状态。
      特点: 1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。 2、这种方法要事先了解被测试系统经典场景,并具有确定的性能目标。 3、这种方法要求在已经确定的环境下运行。 也就是说,这种方法是对系统性能已经有了解的前提,并对需求有明确的目标,并在已经确定的环境下进行的。
      负载测试(Load Test)通过在被测系统上不断加压,直到性能指标达到极限(例如“响应时间”)超过预定指标或都某种资源已经达到饱和状态。
      特点: 1、这种性能测试方法的主要目的是找到系统处理能力的极限。 2、这种性能测试方法需要在给定的测试环境下进行,通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。 3、这种性能测试方法一般用来了解系统的性能容量,或是配合性能调优来使用。 也就是说,这种方法是对一个系统持续不段的加压,看你在什么时候已经超出“我的要求”或系统崩溃。


      压力测试(强度测试)(Stress Test)压力测试方法测试系统在一定饱和状态下,例如cpu、内存在饱和使用情况下,系统能够处理的会话能力,以及系统是否会出现错误
      特点: 1、这种性能测试方法的主要目的是检查系统处于压力性能下时应用的表现。 2、这种性能测试一般通过模拟负载等方法,使得系统的资源使用达到较高的水平。 3、这种性能测试方法一般用于测试系统的稳定性。 也就是说,这种测试是让系统处在很大强度的压力之下,看系统是否稳定,哪里会出问题。
      并发测试(Concurrency Testing)并发测试方法通过模拟用户并发访问,测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。
      特点: 1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。 2、这种性能测试方法主要关注系统可能存在的并发问题,例如系统中的内存泄漏、线程锁和资源争用方面的问题。 3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。 也就是说,这种测试关注点是多个用户同时(并发)对一个模块或操作进行加压。
      配置测试(Configuration Testing)配置测试方法通过对被测系统的软\硬件环境的调整,了解各种不同对系统的性能影响的程度,从而找到系统各项资源的最优分配原则。
      特点: 1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度,从而判断出最值得进行的调优操作。 2、这种性能测试方法一般在对系统性能状况有初步了解后进行。 3、这种性能测试方法一般用于性能调优和规划能力。 也就是说,这种测试关注点是“微调”,通过对软硬件的不段调整,找出这他们的最佳状态,使系统达到一个最强的状态。
      可靠性测试通过给系统加载一定业务压力(例如资源在70%-90%的使用率),使系统运行一段时间,以此检测系统是否稳定运行。
      特点: 1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。 2、这种性能测试方法需要在压力下持续一段时间的运行。(2~3天) 3、测试过程中需要关注系统的运行状况。 如果测试过程中发现,随着时间的推移,响应时间有明显的变化,或是系统资源使用率有明显波动,都可能是系统不稳定的征兆。 也就是说,这种测试的关注点是“稳定”,不需要给系统太大的压力,只要系统能够长期处于一个稳定的状态。
      失效恢复测试如果系统局部发生故障,用户是否能够继续使用系统,以及如果这种情况发生,用户将受到多大程度的影响。
      特点: 1.这种性能测试方法的主要目的是验证在局部故障情况下,系统能否继续使用。 2.这种性能测试方法还需要指出,当问题发生时,“能支持多少用户访问”的结论和“采取何种应急措施”的方案。 3.一般来说,只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。
      大数据量测试针对某些系统存储、传输、统计查询等业务进行大数据量的测试。
      疲劳强度测试主要特点是长时间对目标测试系统加压,目的是测试系统的稳定性,持续时间一般在1小时以上;感觉等同于可靠性测试。
      注意:在做性能测试时请忘掉分类.例如,运行8个小时来测试系统是否可靠,而这个测试极有可能包含了可靠性能测、强度测试、并发测试、负载测试,等等。因此,在实施性能测试时决不能割裂它们的内部联系去进行,而应该分析它们之间的关系,以一种高效率的方式来设计性能测试。


    Web测试中的几个case
    一、页面上对引起 大量数据提交的 按钮/链接 点击一次后,  disable
      需求:
      对于重要的表单、数量庞大/响应慢的系统,在做提交时, 又有页面还在loading状态, 此时连续做两次点击, 经常引起各种报错,这种情况下, 需要提出 对 按钮/链接 点击一次后, 做 disable
      测试:
      1)、查看页面源代码是否有脚本控制,例如:
    <a href="javascript: $('#next').val('true'); buttonDisable();headerFormSubmit();" type="submit" class="btn" id="nextButton"> Next </a>
    function buttonDisable(){
    $("#nextButton").attr("disabled", "disabled");
    }
    2)、对脚本进行调试,
      可以借助firebug工具,在Script Tab上,在$("#nextButton").attr("disabled", "disabled");这行脚本设置disable, 点击nextButton,检查运行到断点处停止,按钮无法再次点击。运行断点后, disable解除。
      二、新增数据库字段测试需要考虑的几个点
      1)、从数据库检查起, 检查相关表: 原表、历史表、与其同步库的表 有没有都添上该字段,并且注意在每个表中, 字段类型是否统一
      2)、校验:考虑字段本身类型,   判空、边界、唯一性、特殊字符、正确性允许的data
      特别, 在做判空时,若字段不允许为空时,考虑: 需要提交脚本初始化历史数据set dafault value
      3)、流程覆盖:考虑该字段覆盖到哪几个相关页面, 测试到整个流程, 每个页面校验要一致;
      三、查log测试的几个操作
      一般情况下, 项目都部署在linux环境上, 测试时, 有些需要查log, 或者有些服务需要自己去重启, 此时就需要一些基本的linux操作命令:
      1)、首先连接到linux系统的机器上,可以使用putty软件, 要有 服务器地址+端口+协议  loginName+password,就可以登录
      2)、cd到脚本或者log放置的文件夹位置去重启服务或查看log,还有一些常用的命令
      less 文件名(W向上翻页、F向下翻页,Shift+F自动翻页,Ctrl+C停止自动翻页);
      grep "findString" 文件名;
      执行脚本:   ../脚本名   或者   sh./脚本名




    web常见安全问题以及测试方法
    Web安全是我们测试组一直以来作为和性能测试并驾齐驱的两个重点。开发的过程中还需要着重注意,该转义的地方转义;该屏蔽的地方屏蔽,该过滤的地方过滤等等。年底又到了,势必又有大批的发号抽奖之类的活动开发、上线,在这个过程中,安全问题是我们每个人应该紧绷的神经,对于我们测试人员来说,每个活动需要做到手动安全测试加自动化安全测试相结合。
      常见的web安全问题有:
      SQL注入、跨站点脚本攻击、跨站点伪造请求、目录遍历、邮件表头注入、页面错误信息等。
      对于手动安全测试来说,一般常用的有三点:
      1、URL有参数的,手动修改参数,看是否得到其他用户的信息和相关页面;
      2、在登录输入框的地方输入‘ or 1=1--或 “ or 1=1--等看是否有SQL注入;
      3、在注重SQL注入的同时,一般在有输入框的地方输入
      对于自动化安全测试来说:
      测试组目前使用的安全测试工具为IBM的AppScan(当然,是破解版,34上已经放过该工具的安装包)
      1、在使用之前务必确认自己绑定的Host;
      2、配置URL、开发环境、错误显示类型;
      3、结果保存后可根据提示的问题类型和解决建议进行分析。
      Web安全测试通常要考虑的测试点:
      1、输入的数据没有进行有效的控制和验证
      2、用户名和密码
      3、直接输入需要权限的网页地址可以访问
      4、认证和会话数据作为GET的一部分来发送
      5、隐藏域与CGI参数
      6、上传文件没有限制
      7、把数据验证寄希望于客户端的验证
      8、跨站脚本(XSS)
      9、注入式漏洞(SQL注入)
      10、不恰当的异常处理
      11、不安全的存储
      12、不安全的配置管理
      13、传输中的密码没有加密
      14、弱密码,默认密码
      15、缓冲区溢出
      16、拒绝服务
    SQL注入:
    所谓SQL注入,就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令,比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的,这类表单特别容易受到SQL注入式攻击.(
    (select * form 表 where id=1 or 1
    1 or 1是输入框输入的
    这样会导致满足 id=1 或 1 的数据都查出来
    而所有的数据都满足 1 
    这样就查出来了很多不该被查出来的数据

    这就是sql注入)


    本文转载自:http://blog.csdn.net/yuki_ying/article/details/54946541

    展开全文
  • web项目测试方法总结

    千次阅读 2019-02-22 17:24:05
    Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的...

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

    1.       功能测试

    2.       性能测试(包括负载/压力测试)

    3.       用户界面测试

    4.       兼容性测试

    5.       安全测试

    6.       接口测试

    本文的目的是覆盖 web 测试的各个方面,未就某一主题进行深入说明。

    1 功能测试

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

    采取措施:

         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、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。

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

    2 性能测试

    2.1 连接速度测试

    用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。

    另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

    2.2 负载测试

    负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

    2.3 压力测试

    负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。

    进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。

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

    负载/压力测试应该关注什么

    测试需要验证系统能否在同一时间响应大量的用户,在用户传送大量数据的时候能否响应,系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息,他们可能放弃,并转向竞争对手。系统检测不仅要使用户能够正常访问站点,在很多情况下,可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因,测试人员应该知道当系统过载时,需要采取哪些措施,而不是简单地提升系统性能。

    瞬间访问高峰

    如果您的站点用于公布彩票的抽奖结果,最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。

    每个用户传送大量数据

    网上书店的多数用户可能只订购 1-5 书,但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?

    长时间的使用

    如果站点用于处理鲜花订单,那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务,那么点最好能持续运行几个月,甚至几年。可能需要使用自动测试工具来完成这种类型的测试,因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常,测试工具在第二次使用的时候,它创造的效益,就足以支付成本。而且,测试工具安装完成之后,再次使用的时候,只要点击几下。

    采取措施:采用测试工具WAS、ACT协助进行测试

    3 用户界面测试

    3.1 导航测试

    导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

    在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。

    导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。

    Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

    3.2 图形测试

    在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

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

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

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

    (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩,最好能使图片的大小减小到 30k 以下

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

    通常来说,使用少许或尽量不使用背景是个不错的选择。如果您想用背景,那么最好使用单色的,和导航条一起放在页面的左边。另外,图案和图片可能会转移用户的注意力。

    3.3内容测试

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

    信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"。

    对于开发人员来说,可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能,然后开始开发,在开发的时候,开发人员可能不注重文字表达,他们添加文字可能只是为了对齐页面。不幸的是,这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则,公司可能陷入麻烦之中,也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时,最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章,所以相信您也希望自己的站点能更专业一些。最后,需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址,或者从某个站点下载浏览器。但是如果用户无法点击这些地址,他们可能会觉得很迷惑。

    3.4 表格测试

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

    3.5 整体界面测试

    整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?

    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

    对所有的用户界面测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

    采取措施:手动测试,参与人员最好有外部人员

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

    4.4 Modem/连接速率

    是否有这种情况,用户使用 28.8 modem下载一个页面需要 10 分钟,但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候,可能会等待比较长的时间,但却不会耐心等待首页的出现。最后,需要确认图片不会太大。

    4.5 打印机

    用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题,注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕,因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

    4.6 组合测试

    最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错,但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示,但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点,测试可能会轻松一些。如果公司指定使用某个类型的浏览器,那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线,可能不需要测试下载施加。(但需要注意的是,可能会有员工从家里拨号进入系统) 有些内部应用程序,开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是,理想的情况是,系统能在所有机器上运行,这样就不会限制将来的发展和变动。

    采取措施:根据实际情况,采取等价划分的方法,列出兼容性矩阵

    5 安全测试

    即使站点不接受信用卡支付,安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露,客户在进行交易时,就不会有安全感。

    5.1 目录设置

    Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面,这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片,单击鼠标右键,找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径,发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ,点击 jackpot。在该目录下有很多资料,其中引起我注意的是已过期页面。该公司每个月都要更改产品价格,并且保存过期页面。我翻看了一下这些记录,就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息,他们在谈判桌上肯定处于上风。

    5.2 SSL

    很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息,而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL,测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器,这些浏览器不支持SSL。当用户进入或离开安全站点的时候,请确认有相应的提示信息。是否有连接时间限制?超过限制时间后出现什么情况?

    5.3 登录

    有些站点需要用户进行登录,以验证他们的身份。这样对用户是方便的,他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录,而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3,你在第三次登录的时候输入正确的用户名和口令,能通过验证吗? 口令选择有规则限制吗?  是否可以不登陆而直接浏览某个页面?

    Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

    5.4 日志文件

    在后台,要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?

    5.5 脚本语言

    脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器,但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言,并研究该语言的缺陷。还要需要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。 

    6 接口测试

    在很多情况下,web 站点不是孤立。Web 站点可能会与外部服务器通讯,请求数据、验证数据或提交订单。

    6.1服务器接口

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

    这种测试可以归到功能测试中的表单测试和数据校验测试中

    6.2 外部接口

    有些 web 系统有外部接口。例如,网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候,要使用 web 接口发送一些事务数据,分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡, 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别,例如 3 表示 American Express,4 表示 Visa,5 表示 Mastercard,6 代表Discover。)通常,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

    这种情况在远程抄表中可能会体现到

    6.3 错误处理

    最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误,但却无法预期系统所有可能的错误。尝试在处理过程中中断事务,看看会发生什么情况?订单是否完成?尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下,系统能否正确处理这些错误?是否已对信用卡进行收费?如果用户自己中断事务处理,在订单已保存而用户没有返回网站确认的时候,需要由客户代表致电用户进行订单确认。

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

    7 结论

       无论你在测试 internet、intranet 或者是 extranet 应用程序,web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下,就像业务功能一样,页面用于维护和发展公共关系,所以第一印象非常重要。

    展开全文
  • Web测试流程

    千次阅读 2018-08-28 16:44:14
    Web项目测试流程大致包含的几个阶段:立项、需求评审、用例评审、测试执行、测试报告文档 立项后测试需要拿到的文档 1.需求说明书 2.原型图(及UI图) 3.接口文档 4.数据库字典(表的数量、缓存机制) 需求...
  • Web测试方法

    千次阅读 2018-09-21 11:10:28
    最近做某项目,项目要求采用B/S架构进行系统总体构建,此次测试为面向Web的测试,现整理出面向web测试设计测试用例时需要考虑的因素。 一、功能测试 首先需要将系统和需求说明书中的功能需求进行对比,查看是否有...
  • Web测试需要注意的点

    万次阅读 多人点赞 2019-04-16 16:35:24
    测试用例是测试的核心,测试用例的设计是一种思维方式的体现,在用例的设计中,用的比较多的方法是边界值分析法和等价类划分法,下面主要从输入框,搜索功能,添加、修改功能,删除功能,注册、登录功能以及上传图片...
  • Web界面应用的测试内容

    千次阅读 2018-12-19 15:25:18
    Web界面应用常用的测试方法: 一、输入框: 1、字符型输入框: (1)字符型输入框:英文全角、英文半角、数字、空或者空格、特殊字符“~!@#¥%……&amp;*?[]{}”特别要注意单引号和&amp;符号。禁止直接...
  • Web测试和App测试区别

    万次阅读 多人点赞 2018-10-27 14:14:40
    WEB测试和应用测试从流程上来说,没有区别。都需要经历测试计划方案,用例设计,测试执行,缺陷管理,测试报告等相关活动。从技术上来说,WEB测试和APP测试其测试类型也基本相似,都需要进行功能测试,性能测试,...
  • Web测试与App测试的区别

    万次阅读 多人点赞 2018-10-09 14:48:15
    前几天一个测试妹纸问我,web测试与app测试到底有啥区别呢,这个问题尤其是很多初入行的测试经常会问的。 其实,不管是什么类型的测试,测试方法都是类似的,这里说到的web与app之间的测试区别,主要在于应用场景的...
  • 软件测试之Web测试

    千次阅读 多人点赞 2015-03-04 17:36:03
    1、Web测试中相关的设置与查看方法  2、Web测试中截屏与录制屏幕操作过程  3、界面测试、功能测试、表单测试的验证要点 一、Web测试的特点  基于Web应用测试的特点是用户通过计算机中安装的浏览器就可以访问...
  • 一文搞懂Web测试与App测试的区别

    千次阅读 多人点赞 2019-11-23 12:50:54
    一文搞懂Web测试与App测试的区别 接下来,需要完成年前最后一个项目的测试,该项目需要结合Web测试和App测试,经过整理,总结分享一些工作经验给大家。 从功能测试方面讲,Web测试与App测试在测试用例设计和测试...
  • web测试之功能测试总结

    万次阅读 多人点赞 2018-01-16 19:41:17
    经常碰到有人问我: 一个界面很多搜索条件怎么写用例? 这个下拉框测试考虑这些够吗?我怕覆盖不完整?...所以今天主要是给大家整理下功能...web测试就是基于BS架构的软件产品的测试,通俗点来说就是web网站的测试
  • Web测试关注点

    千次阅读 2017-05-09 14:51:47
    Web测试关注点输入框1、字符型输入框: 字符型输入框:英文全角、英文半角、数字、空或者空格、特殊字符“~!@#¥%……&*?[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时,使用“粘贴、拷贝”功能尝试输入...
  • web测试的基本流程

    千次阅读 2018-05-01 13:21:33
    今天主要讲讲web测试的基本流程,同时也算是为大家慢慢普及这方面的知识和内容。1、web测试流程:(1)web测试 1)参与一个web新项目的测试前,先搜集测试相关的资料,包括原型图、各种需求文档、业务相关等需求...
  • APP测试和web测试的区别

    万次阅读 多人点赞 2018-01-13 23:54:40
    单纯从功能测试的层面上来讲的话,APP 测试、web ...web测试只要更新了服务器端,客户端就会同步会更新。App项目则需要客户端和服务器都更新。性能方面: web页面主要会关注响应时间 而app则还需要关心流量、电量、CPU
  • web测试点和app测试点

    千次阅读 多人点赞 2018-06-04 10:30:12
    web测试点:一、输入框1、字符型输入框:(1)字符型输入框:英文全角、英文半角、数字、空或者空格、特殊字“~!@#¥%……&amp;*?[]{}”特别要注意单引号和&amp;符号。禁止直接输入特殊字符时,使用“粘贴...
  • APP测试与WEB测试的区别

    万次阅读 多人点赞 2018-04-26 16:48:23
    web测试只要更新了服务器端,客户端就会同步会更新。 app项目,c/s结构的,必须要有客户端;app 修改了服务端,则客户端用户所有核心版本都需要进行回归测试一遍。 性能方面 web项目 需监...
  • 1.用户及权限管理功能常规测试方法   1) 赋予一个人员相应的权限后,在界面上看此人员是否具有此权限,并以此人员身份登陆,验证权限设置是否正确(能否超出所给予的权限);   2) 删除或修改已经登陆系统并...
  • Web测试常用测试点

    千次阅读 2018-06-26 16:42:51
    1.兼容性测试:浏览器(PC端)(注意浏览器的兼容模式和疾速模式):IE浏览器,Chrome,Firefox,360安全浏览器,360疾速浏览器,搜狗浏览器,QQ浏览器,百度浏览器,猎豹浏览器浏览器(移动端):是否兼容移动端...
1 2 3 4 5 ... 20
收藏数 1,123,337
精华内容 449,334
关键字:

web测试