精华内容
下载资源
问答
  • web网页测试用例(非常实用)web网页测试用例(非常实用)Web测试中,各类web控件测试点总结一 、界面检查 进入一个页面测试,首先是检查title,页面排版,字段等,而不是马上进入文本框校验 1、页面名称title是否正确...

    web网页测试用例(非常实用)

    web网页测试用例(非常实用)Web测试中,各类web控件测试点总结一 、界面检查  进入一个页面测试,首先是检查title,页面排版,字段等,而不是马上进入文本框校验  1、页面名称title是否正确  2、当前位置是否可见 您的位置:xxx>xxxx  3、文字格式统一性  4、排版是否整齐  5、列表项显示字段是否齐全,列表项字段名称是否跟表单统一  6、同一页面,是否出现 字段名称相同、值取不同的问题。  7、数据加载情况:除了文本框的值,还要注意:  复选框,是否保存打√,或者保存不打√  下拉框,是否保存选择的值  多文本框,值是否都被保存,空格,换行是否保存二、单文本框(type=text)  边界:字段长度  判空:是否可以为空  唯一性:是否唯一 (小归结:边界、判空、唯一性、特殊字符、正确性)  考虑语言,操作环境  特殊符号测试输入:  ' or 1<>'1   ' or '1'='1  ' or '1'<>'2  "|?>alert(“123”);>  特殊字段输入限定:  框内容是否合法(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.相关联的东西

    展开全文
  • 自用网页测试>> zip
  • web网页测试用例(非常实用)

    万次阅读 多人点赞 2018-02-06 15:21:19
    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

    展开全文
  • 网页界面测试用例.pdf

    2021-10-09 02:50:38
    网页界面测试用例.pdf
  • 测试用例设计

    2014-08-18 14:49:23
    网页测试用例技巧大放送快来学习一下软件测试用例
  • 测试用例之性能测试用例

    万次阅读 多人点赞 2016-06-22 21:55:14
    测试用例之性能测试用例 性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试… …,这么多眼花缭乱的测试类型名称,估计很少有人能准确的区分并说出定义来,至于对应的测试用例...

    测试用例之性能测试用例

    性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试… …,这么多眼花缭乱的测试类型名称,估计很少有人能准确的区分并说出定义来,至于对应的测试用例如何编写和执行,就更不用说了。

    如果问测试工程师测试用例如何编写,就象是问程序员如何编写代码得到的答案一样,每个人都会给出不同的编写方法,但实用的测试用例却象优秀的程序一样难以编写。

    目前国内,测试工程师却时常要面对“已经延期几倍计划时间的项目”,测试用例如何发挥更大的作用,是一个迫切需要解决的问题。事实上,完全可以把测试用例看成是测试工程师编写的程序:这个“程序”是为了辅助测试工作的进行而开发的,目的是为了发现软件问题,同时“顺便”证明软件功能是否符合要求。

    本文针对上面的问题,以设计性能测试用例为示范,讲解在企业实际工作中,如何有效划分测试种类和编写对应的测试用例,使测试工作更加合理、高效率的开展。

    1测试种类和阶段

    1.1 测试种类

    对于测试种类的说法多种多样,最多的能达到30多种测试类型。而实际工作中很多测试是互相包含的。按照企业中实际工作需要,通常主要进行下面几种类型的测试:功能测试、健壮性测试、接口测试、强度测试、压力测试、性能测试、用户界面测试、可靠性测试、安装/反安装测试、文档测试。

    下面介绍几种重要的测试种类及其测试的内容:

    功能测试:功能测试主要针对产品需求说明书的测试,是验证功能是否否合需求,包括原定功能的检验、是否有冗余功能、遗漏功能。这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作,他们也需要进行基本功能的测试。

    接口测试:程序员对各个模块进行系统联调的测试,包含程序内接口和程序外接口测试。这个测试,在单元测试阶段进行了一部分工作,而大部分都是在集成测试阶段完成的。由开发人员进行。

    性能测试:在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该与性能测试一同进行。

    用户界面测试:对系统的界面进行测试,测试用户界面是否友好、是否方便易用、设计是否合理、位置是否正确等一系列界面问题

    安装/反安装测试:安装测试主要检验软件是否可以正确安装,安装文件的各项设置是否有效,安装后能否影响原系统;反安装是逆过程,测试是否删除干净,是否给影响原系统等。

    文档测试:主要测试开发过程中针对用户的文档,以需求、用户手册、安装手册等为主,检验文档是否和实际应用存在差别。文档测试不需要编写测试用例。

    测试种类的划分不要拘泥于上面的形式,总体来说应该服从于测试策略,可以根据具体工作的特点进行安排,为了工作更容易开展,完全可以把一些测试合在一起进行。在后面的性能测试用例的编写上,充分体现了这一思想。

    1.2 测试阶段

    和开发过程相对应,测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段。对应关系如图1所示:

    需求开发

     

    高层设计

    详细设计

    编程

    单元测试

    集成测试

    系统测试

    验收测试

     

     


    开发与测试的“V”型关系

    单元测试:单元测试是针对软件设计的最小单位——程序模块甚至代码段进行正确性检验的测试工作,通常由开发人员进行。

    集成测试:集成测试是将模块按照设计要求组装起来进行测试,主要目的是发现与接口有关的问题。由于在产品提交到测试部门前,产品开发小组都要进行联合调试,因此在大部分企业中集成测试是由开发人员来完成的。。

    系统测试:系统测试是在集成测试通过后进行的,目的是充分运行系统,验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行,是测试部门最大最重要的一个测试,对产品的质量有重大的影响。

    验收测试:验收测试以需求阶段的《需求规格说明书》为验收标准,测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行,对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试,尤其要进行文档测试。

    尽管测试阶段的划分十分明确,但是在具体的项目和产品的测试中,尤其在执行测试时,会根据实际需要来开展。

    1.3 测试种类、阶段和用例的关系

    为了便于在实际工作中提高效率,同时方便测试用例的编写和执行,可以把上面提到的各个测试类型与对应的测试用例合并。合并后的测试用例主要有以下几种:

    1. 功能测试用例:包含功能测试、健壮性测试、可靠性测试

    2. 性能测试用例:包含性能测试、压力测试、强度测试

    3. 集成测试用例:包含接口测试、健壮性测试、可靠性测试

    4. 安全测试用例:安全测试用例

    5. 用户界面测试用例:包含用户界面测试用例、少量功能测试用例

    6. 安装/反安装测试用例:安装/反安装测试用例

    综合上面的分析,测试种类、测试阶段以及执行人员具体的关系如表1所示。

    测试阶段

           测试类型

    执行者

    单元测试

    模块功能测试,包含部分接口测试、路径测试

    开发工程师

    集成测试

    接口测试、路径测试,含部分功能测试

    开发工程师(如果测试人员水平较高,可以由测试人员执行)

    系统测试

    功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试

    测试工程师

    验收测试

    对于实际项目来说基本同上,并包含文档测试;对于软件产品,主要测试相关的技术文档。

    测试工程师(根据实际需要,可能包含用户)

    测试的种类、阶段和执行人员的关系

    总之,测试的种类应该尽量的少,这样每次都可以执行更多的测试内容。例如在进行功能测试的同时,完全可以进行健壮性的测试。(当然如果产品健壮性方面要求较高,就可以把健壮性测试作为独立的测试。)

    2性能用例编写方案

    性能测试在软件测试中占有重要的地位,而性能测试又关联很多内容。例如压力和强度测试就与性能测试密切相关:针对一个网站进行测试,模拟10到50个用户就是在进行常规性能测试,用户增加到1000乃至上万就变成了压力/负载测试,如果同时对系统进行大量的数据查询操作,就包含了强度测试。

    为了便于性能测试工作的实施,这里的性能测试综合了性能、强度、压力、负载等多方面的测试内容,主要包含的内容有:预期性能指标测试、用户并发性能测试、疲劳强度测试、大数据量测试和速度测试、网络、服务器等方面的内容。

    性能测试不同的系统有不同的要求,编写方法要根据实际要求进行编写,本文提出一个常见的参考方案,在实际工作中,可以根据需要加入其它例如内存泄露等和性能相关的测试用例。

    下面介绍各个部分性能测试用例包含的内容:

    2.1预期性能指标测试用例

    通常系统在设计前都会提出一些性能指标,这些指标是性能测试要完成的首要工作之一。针对每个指标都要编写多个测试用例来验证是否达到要求,并根据测试结果来改进系统的性能。

    这类通常以单用户为主,如果遇到并发用户的情况,可以归到并发用户测试用例中。这类用例通常都是可以通过手工来执行的用例,例如示例中的上传一份文件,期望的性能为2M/S,完全可以手动上传文件,同时用秒表计时。这些内容通常在需求说明书中可以显而易见的查到。不过当看到如支持并发用户300人,就应该放到后面进行。测试结果也是直接记录是否达到要求,如果系统没有达到要求则进行改善。

    2.2用户并发性能测试用例

    用户并发测试是性能测试的最主要部分,包含了负载测试和压力测试的过程。主要是逐渐增加用户数量来加重系统负担,直到出现不能接收的性能点或者瓶颈。一般要测试正常数量的用户并发和极限数量下用户并发的情况。

    并发用户测试主要是对系统的核心功能和重要业务进行测试,要以真实的业务数据作为输入,选择有代表性和关键的业务操作来设计测试用例。主要编写以下两个方面的用例:

    核心模块的测试(可以理解为“单元性能测试”):对核心功能模块进行并发用户测试,测试系统是否能够稳定运行。例如对于互联网的公用邮件系统,每天早上9点左右可能是收发邮件的高峰,这时候上千的用户都要在上班后进入邮件系统,系统这个时候需要接收和发送大量的邮件。所以邮件系统这一功能模块要进行并发测试。通过测试可以知道数据库服务器、操作系统、网络设备等是否能够承受住考验,同时可以对瓶颈进行分析。

    表2列出来一些常见的参数(表格中的数据为示例的测试用例和测试结果),可以根据实际需要进行增加和删除,其中磁盘I/O、数据库相关测试参数要根据实际情况进行选择,因此没有列出。

    功能

    在线用户达到高峰时,发送和接收普通邮件正常,保证200个以内用户可以同时访问邮件系统,能够正常发送和接收邮件。

    目的

    测试系统200个以内的用户同时在线能否正常发送邮件。

    方法

    采用LoadRunner的录制工具录制一个邮件发送过程,然后利用其完成测试,要监视数据库服务器和web服务器的性能。其中发送的邮件为普通的邮件,附件大小不超过1M.

    并发用户数与事务执行情况

    并发用户数

    事务平均响应时间

    事务最大响应时间

    平均每秒处理事务数

    事务成功率

    每秒点击率

    平均流量(字节/秒)

    100

    1.344

    2.078

    5

    100%

    102

    5177

    并发用户数与数据库主机

    并发用户数

    CPU利用率

    MEM利用率

    磁盘I/O参数

    DB参数1

    其它参数

    100

    23%

    11%

    并发用户数与应用服务器的关系表

    并发用户数

    CPU利用率

    MEM利用率

    磁盘I/O参数

    100

    32%

    27%

    核心模块的性能测试用例

    在编写这类用例时,要进行综合分析,选出系统中的各个核心模块,分别设计每个模块的测试用例:把模块划分成小的“事务”进行测试,这样在测试分析中便于定位问题究竟出现在哪里。例如邮件系统可以划分成:接收邮件、发送邮件、打开邮件等小的事务进行测试用例的编写,每个操作做为一个用例来执行。

    业务组合性能测试(可以理解为“集成性能测试”):所有的用户不会只使用核心模块,通常每个功能都可能被使用到,所有既要模拟多用户的“相同”操作,又要模拟多用户的不同操作,对多个业务进行组合性能测试。

    业务组合测试是更接近用户实际操作系统的测试,因此用例编写要充分考虑实际情况,选择最接近实际的场景进行设计。这里的业务组成单位以不同模块中的“子操作事务”为单位,进行各个模块的不同业务的组合。例如在办公自动化系统中就可以选择“公文模块中的发送公文、电子公告模块中的查看公告信息、网上论坛模块中的上传文件”等事务作为一组组合业务进行测试,用例设计信息如下:

    功能:在线用户达到高峰时,用户可以正常使用系统,保证500个以内用户可以同时在线使用系统。

    目的:测试系统500个以内的用户同时在线能否使用比较常见的模块:公文系统、电子公告、网上论坛。

    方法:采用LoadRunner的录制工具录制三个业务:

    业务1——在公文系统内,进行打开、修改等操作;

    业务2——在电子公告系统内,查看、发布公告;

    业务3——在网上论坛系统内发布帖子,查看文章。每个业务分配一定数目的用户,利用LoadRunner来完成相关参数的测试。

    其它部分设计可以参考表2。执行时要分别记录各个事务的执行情况。

    多用户并发性能测试是性能测试的核心内容,包含了全部与多用户相关的测试。因此设计时要全面考虑,不要有遗漏。在测试执行时,本部分通常是采用性能测试工具例如LoadRunner来进行测试的,因此更容易执行和提高效率。

    2.3疲劳强度与大数据量测试

    疲劳强度测试是在系统稳定运行下模拟最大用户数量、并长时间运行系统,通过综合分析执行指标和资源监控来确定系统处理最大业务量时的性能。

    疲劳强度测试的目的就是检验系统长时间运行后的性能,因此设计用例时,需要编写不同参数或者负载条件下的多个测试用例,对服务器、软件、网络进行不同条件下的综合测试分析,测试时要记录系统发生故障的信息作为测试结果。疲劳强度测试也是采用测试工具进行的。

    大数据量测试分为两种:一个是针对某些系统存储、传输、统计查询等业务进行大数据量的测试;另一个是与前面并发测试相结合的综合数据测试。编写用例时主要编写前一部分,后一部分尽量放在并发测试中。

    大数据量测试一般是针对那些对数据库有特殊要求的系统进行测试,例如电信业务系统的手机短信息表,由于有的用户关机或者不在服务区,每秒钟需要有大量的短信息保存,同时在用户联机后还要及时发送,因此对数据库性能有极高的要求,需要专门测试。

    本部分用例设计表格可以参考用户并发性能测试部分。

    2.4网络性能测试

        网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。在实际的软件项目中,主要是测试用户数目与网络带宽的关系。

    编写用例的格式如表3 (表格中的数据为示例数据):

    目的

    测试系统运行网络在不同并发用户条件下的使用情况

    方法

    在不同的广域网带宽下(例如256K)使用LoadRunner录制邮件系统的相关事务操作脚本,以不同的并发用户数进行测试,记录各种用户连接数下,不同并发请求的性能变化;同时记录路由器端口的流量和其他数据。

    运行时间

    10小时

    用户并发数

    事务平均响应时间

    服务器端口流量

    丢报率

    100

    2.816

    50.2M/S

    0.001%

    500

    3.876

    98.2M/S

    0.002%

    网络性能测试

    本部分可以独立测试,也可以和用户并发性能测试、疲劳强度与大数据量性能测试结合起来,在原有的基础上采用工具来调整网络设置,从而达到监视网络性能的目的。通常网络性能都是采用工具进行性能评估,由系统集成工程师来进行。

    2.5服务器性能测试

    本部分的测试用例不必独立编写,或者根据实际需要编写少量的测试用例,建议这部分的用例编写和前两部分结合起来,在用户并发性能测试、疲劳强度与大数据量性能测试时完成对服务器性能的监控,完成对服务器性能的评估。

    2.6性能分析基本策略

    在上面的用例执行完成后,接下来要进行性能分析。性能分析是性能测试的最终目的,否则测试出的指标就不会有实际意义,这里主要介绍一下性能分析的基本思路。性能分析通常要围绕三个方面进行:软件、服务器、网络。

    软件主要是分析具体事务执行时间,尤其并发用户部分,根据测试工具测试出的结果分析那些事务执行的慢,然后可以分析执行较慢的代码,针对网页可以分析具体的页面元素执行情况。

    服务器的分析要结合软件的运行情况进行分析,着重分析硬件的执行参数,CPU、硬盘、内存、中断、内存等情况,分析尤其要注意对这些参数进行综合分析,往往各个参数之间会互相影响,最后在调查、分析整体系统的基础上,找出影响服务器整体性能的瓶颈,确定相应的升级需求:

    1. 服务器硬盘负载较重,需增加硬盘。

    2. CPU整体性能偏低,需增加或更新CPU。

    3. 网卡性能偏低,需更换光纤网卡。

    4. 硬盘I/O负载任务繁重,需使用高转速硬盘或采用RAID卡。

    5. 内存资源短缺,需增大内存。

    6. 其他方面,需要升级软件系统、合理进行子网划分、加强管理等。

    网络性能分析要结合结合服务器和测试目标软件,通常网络传输慢会有软件和服务器方面的原因,甚至有时候会有客户端方面的原因。不过目前网络的环境普遍可以,不管是局域网还是广域网,网络的环境越来越好。

    3用例管理

    测试用例的管理我们可以借鉴开发过程中对程序的管理方法,我们可以把测试用例看成程序——测试工程师编写的程序,这个程序也要经过“设计”、“开发”、“测试”、“版本管理”、“发布”、“维护”等一系列操作,然后按照管理软件程序的方法来管理测试用例。

    用例管理主要包含评审、修改、执行用例、用例版本维护、用例升级方面的内容。

    3.1 用例评审

    测试用例评审是测试用例不可缺少的一个环节,这是对“测试部门开发出的产品”进行的“测试”。基本思路是对测试准备阶段的成果进行分期评审,依次评审系统/验收测试用例、集成测试用例、单元测试用例。

    评审用例在比较正规的公司更容易实施,要求相应的软件开发团队必须在实际工作中对测试给予足够的重视,才可以把这项工作做好,否则只是走走形式。有效的用例评审通常由下面两种形式组成:

    测试部门外部评审——主要是由开发部、项目实施部、甚至销售人员参加的评审,目的主要是查找测试工程师编写的用例是否缺少内容。建议采用非正式评审的形式进行,因为我们很难把开发人员组织在一起,一般来说他们的开发进度压力很大,能够抽出时间看文档已经是“很给面子了”。当然不统一进行评审会耽误工程的进度,所以在实际工作中如果时间紧迫,可以提前启动测试实施工作,待评审完成后进行用例的修改工作。通常测试工作进行一段时间评审就会结束,这个时候测试执行人员可以在工作中对测试用例的内容进行动态的调整,再次执行被修改过的部分用例(如果能够采用正式评审,效果肯定会更好。)。

    外部评审主要工作方式是用文档直接记录评审结果,测试人员根据评审结果对用例进行升级修改。

    测试部门内部评审——部门内部同行对测试策略的评审,评审的核心内容是测试策略和用例编制思路是否正确,以此来保证测试用例的有效性。可以组织正式的评审,由用例的设计人员进行讲解,然后大家共同评审;也可以把文档发给部门的同事进行评审。内部评审有些象开发人员在单元测试中的交叉测试。

    内部评审的主要工作方式是项目会议,大家可以进行激烈的讨论,共同探讨用例编写、交流经验,这样用例的编写水平才能提高,同时可以进行一些创新。

    评审方式中的外部评审最为重要。因为开发人员很容易发现用例中遗漏了什么内容,同时还可以发现错误的用例——因为存在对需求理解的偏差。用例外部评审可以理解为开发人员在查找测试人员编写的“程序”缺陷。

    通常情况下先执行内部评审,然后执行外部评审。很多时候,内部评审会被忽略,建议要进行内部评审。这样至少有两个好处:集思广益和提高测试小组输出文档的质量。

    3.2 管理方案

    国内大多数IT公司在测试用例的发展经历了以下几个阶段:

    Ø         无用例而执行测试:测试的初级阶段,完全手工测试,测试执行工程中没有测试用例作为执行依据,可能会按照需求进行测试;

    Ø         有用例而不使用用例执行测试:已经编写测试用例,但是受各种环境的影响,例如需求变动频繁、编写的用例过于简单等,测试用例编写后在实际工作中不能使用;

    Ø         按照部分用例执行测试:随着用例编写水平的提高,部分测试用例可以在测试中发挥作用;

    Ø         完全按照用例执行测试:组织建立了规范的项目管理过程,对测试用例进行规范的管理,执行测试用例以用例为准则来执行测试。

    完全按照测试用例执行测试是一个公司测试水平的体现,测试用例管理成为这一阶段的主要内容。测试用例管理的核心内容是版本管理。如果测试用例是采用文字编辑软件例如word编写,建议采用工具(例如Visual SourceSafe)对用例进行控制。可以参照图2进行。

    编写用例

     

    用例评审

    进入版本控制库

    用例修改

    使用用例&维护&升级

     

     


    测试用例管理示意图

    1、 编写用例:测试工程师根据需求分析、概要设计、详细设计等文档编写测试用例。

    2、 用例评审:3.1小结说明了用例的评审。原则上用例像程序一样,要经过多次的修改才可以通过,而实际工作中只进行一到两次。

    3、 用例修改:评审结束后,需要根据评审意见进行修改,修改后通常不再进行评审。建议在时间和人力资源比较充裕的情况下,对用例的评审要像测试开发部门的产品一样,经过反复的评审和修改,然后正式投入使用,因为每次评审可能都有新的发现。

    4、 使用用例:在执行任务时,从版本控制库取出用例,执行时建议直接在用例上记录测试结果。这样做会带来两个好处:首先是下次测试时可以看见上次测试的结果记录,可以起一个提醒的作用;其次可以一次性的把发现的缺陷输入到缺陷跟踪数据库中,在输入时可以进行综合统计,避免输入重复的缺陷。每次使用后送入版本控制库中,进行版本的管理。

    5、 用例升级/维护:随着软件产品的不断修改、升级,对应的用例也需要升级和维护。针对同一个项目,可以根据需求的变更不断进行维护;如果是产品,用例的维护则更加重要,要达到用例和产品的版本一一对应。

    测试用例的管理还可以采用专门的测试软件例如TestDirector等来进行管理,测试工具通常会具备上面的功能。如果有条件,建议采用集成华的测试工具,这样更容易对测试执行全程进行监控,可以把测试需求、测试用例、缺陷管理统一起来,大大提高测试效率。

    在测试用例管理规范化并成为测试的执行准则后,管理测试用例带来的巨大好处开始逐渐显现出来,测试用例成为评估测试和改进测试工作的主要依据,可以给工具带来巨大的方便。例如可以通过测试用例的执行情况来统计分析执行结果,编写测试报告,判断软件测试是否完成,通过统计测试覆盖率、测试合格率、重要测试对象的合格率是多少来完成对软件质量的评估;尤其是新员工到岗后,可以更容易介入工作。

    总之,不管是性能测试还是其它测试都要本着“一切从实际出发”的原则,根据不同产品的特性进行用例编写,最后按照要求完成测试,达到提高产品质量的目的。在测试用例的编写过程中,尤其要记得“创新”,如果长期依靠某一测试用例编写模式、采用某些固定的模板,测试用例编写工作肯定会停滞在某一层次上不再发展,一定要跟着测试对象的不断变化来调整策略,在具体的工作中改进和提高,才能“开发”出优秀的测试用例!


    出处: http://blog.csdn.net/chenshaoying/archive/2006/07/03/869865.aspx

    Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=869865

    展开全文
  • 一个网页通用的测试用例,内容详尽,可供参考。
  • 一个网页测试用例

    千次阅读 2018-06-22 16:03:27
    今天在看51testing的博客时,看到这么一个网页登录的测试用例,想到自己之前写的那个关于登录页面的简单的功能测试用例真的是太弱了,感觉很多都没有考虑进去。特此在这里记录下来,参考。具体需求: 有一个登陆页面...

    今天在看51testing的博客时,看到这么一个网页登录的测试用例,想到自己之前写的那个关于登录页面的简单的功能测试用例真的是太弱了,感觉很多都没有考虑进去。特此在这里记录下来,参考。具体需求: 有一个登陆页面, (假如上面有2个textbox, 一个提交按钮。 请针对这个页面设计30个以上的TestCase.)

    此题的考察目的:面试者是否熟悉各种测试方法,是否有丰富的web测试经验, 是否了解Web开发,以及设计Test case的能力
    首先,你要了解用户的需求,比如这个登录界面应该是弹出窗口式的,还是直接在网页里面。对用户名的长度,和密码的强度(就是是不是必须多少位,大小写,特殊字符混搭)等。还有比如用户对界面的美观是不是有特殊的要求?(即是否要进行UI测试)。剩下的就是设计用例了 ,等价类,边界值等等。
      请你记住一点,任何测试,不管测什么都是从了解需求开始的。
     
    功能测试(Function test)
      0. 什么都不输入,点击提交按钮,看提示信息。(非空检查)
      1.输入正确的用户名和密码,点击提交按钮,验证是否能正确登录。(正常输入)
      2.输入错误的用户名或者密码, 验证登录会失败,并且提示相应的错误信息。(错误校验)
      3.登录成功后能否能否跳转到正确的页面(低)
      4.用户名和密码,如果太短或者太长,应该怎么处理(安全性,密码太短时是否有提示)
      5.用户名和密码,中有特殊字符(比如空格),和其他非英文的情况(是否做了过滤)
      6.记住用户名的功能
      7.登陆失败后,不能记录密码的功能
      8.用户名和密码前后有空格的处理
      9.密码是否加密显示(星号圆点等)
      10.牵扯到验证码的,还要考虑文字是否扭曲过度导致辨认难度大,考虑颜色(色盲使用者),刷新或换一个按钮是否好用
      11.登录页面中的注册、忘记密码,登出用另一帐号登陆等链接是否正确
      12.输入密码的时候,大写键盘开启的时候要有提示信息。
     
    界面测试(UI Test)
      1.布局是否合理,2个testbox 和一个按钮是否对齐
      2.testbox和按钮的长度,高度是否复合要求
      3. 界面的设计风格是否与UI的设计风格统一
      4. 界面中的文字简洁易懂,没有错别字。
     
    性能测试(performance test)
      1.打开登录页面,需要几秒
      2.输入正确的用户名和密码后,登录成功跳转到新页面,不超过5秒
     
    安全性测试(Security test)
      1.登录成功后生成的Cookie,是否是httponly (否则容易被脚本盗取)
      2.用户名和密码是否通过加密的方式,发送给Web服务器
      3.用户名和密码的验证,应该是用服务器端验证, 而不能单单是在客户端用javascript验证
      4.用户名和密码的输入框,应该屏蔽SQL注入攻击
      5.用户名和密码的的输入框,应该禁止输入脚本 (防止XSS攻击)
      6.错误登陆的次数限制(防止暴力破解)
      7. 考虑是否支持多用户在同一机器上登录;
      8. 考虑一用户在多台机器上登录
     
    可用性测试(Usability Test)
      1. 是否可以全用键盘操作,是否有快捷键
      2. 输入用户名,密码后按回车,是否可以登陆
      3. 输入框能否可以以Tab键切换
     
    兼容性测试(Compatibility Test)
      1.主流的浏览器下能否显示正常已经功能正常(IE,6,7,8,9, Firefox, Chrome, Safari,等)
      2.不同的平台是否能正常工作,比如Windows, Mac
      3.移动设备上是否正常工作,比如Iphone, Andriod
      4.不同的分辨率
     
    本地化测试(Localization test)
      1. 不同语言环境下,页面的显示是否正确。
      软件辅助性测试 (Accessibility test)
      软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
      2. 高对比度下能否显示正常 (视力不好的人使用)
    展开全文
  • 自动化测试用例的编写是实现项目自动化的核心,合理的用例设计是保证自动化效益和实用性的关键,也直接决定了自动化脚本是否具备可扩展和可维护性。由此,本篇文章主要为大家介绍了测试用例编写的规范和注意事项。一...
  • WEB测试用例

    2018-11-21 18:58:29
    包含了WEB网页测试的常用测试用例书写模板,非常实用。
  • 网页通用的测试用例

    千次阅读 2017-02-07 18:40:27
    今天正在熟悉新项目需求,编写测试用例,正好顺便整理测试用例相关内容,偶然翻看到之前收集到的一个关于网页端通用的测试用例,自己根据登录页面编写了用例对比都发现还是有遗漏的地方,在此作记录转载一下,已找不...
  • 测试计划和测试用例

    2020-11-22 22:57:46
    1.1.2. 测试用例的特征:1.3. 编写测试用例的好处:1.1.3. 测试用例的作用:1.4. 测试用例的4个特性1.5. 测试用例通常包括以下几个组成元素:1.6. 测试用例示例2.1. 等价类划分法1.1.4. 概念1.1.5. 示例1.1.6. 练习...
  • 关于测试用例,可能测试人员会思考很多问题,例如:测试周期紧张,能否不写用例直接开始测试?测试用例是否需要按照一定的模板编写?测试场景太多,是否每个流程都需要设计测试用例测试用例是否有excel或者其他...
  • WEB端测试用例模板

    2018-10-08 17:03:06
    WEB端测试用例模板,用于模块测试用例,集成测试用例,系统测试用例的编写模板
  • 测试用例(注册,登录和修改密码)》由会员分享,可在线阅读,更多相关《测试用例(注册,登录和修改密码)(3页珍藏版)》请在人人文库网上搜索。1、注册、登录和修改密码的测试用例一、测试用例注册序列号:1控件名称:...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 22,132
精华内容 8,852
关键字:

网页测试用例