精华内容
下载资源
问答
  • 功能测试用例设计思路
    2020-12-25 16:30:47

    1、输入框中输入最大允许值造成页面跳转溢出 2的32次幂

    验证点:边界值、特殊字符、0、null、负值、超长字符、空字符串、英文字符、中文字符、全角符号

    2、搜索框探索性测试:

    探索性测试:“电 视”、“电@视”、“电#视”、乱码-》“电视”、超长字符、空字符串、英文字符、其他字符、全角符号,、“"电视"”、占位符不消失的异常情况、特殊字符

    3、json字符串

    如果数据本身包含“,”、“[”、“]”、“{”、“}”等分割数据的符号,是否会破坏json格式

    4、多次快速点击按钮

    5、cookie过长

    6、没有添加时间戳的缓存,使用户看到过期的数据

    7、页面字段依赖

    8、数据迁移:测试对遗留数据的处理和兼容情况

    9、特性开关

    10、同一功能不同入口

    11、特殊符号:!@#%^&()_+{}|:"<>?"

     

     

    文本输入框测试点:
    1、重复
    2、空 也就是不填写是否支持
    2、长度:例如支持100字符, 那需要测试100字符、101字符、100字符后输入一个汉字的情况, 最大长度的显示是否正常
    3、哪些是支持的字符类型:数字、字母、汉字、字符!@!#、特殊字符(tab 回车键是否支持)
    4、是否支持多行,保存是否成功,显示是否按输入的多行显示
    5、字符中带有HTML标记对时,显示是否正常 例如::<br> <br> &nbsp;
    6、字符串前后中带空格,前后的空格是否过滤, 中间的空格是否保留
    7、最大长度显示是否正常
    8、全角半角的字母、数字
    9、字符串中带JS标记对, 比如<script>alert('aa');</script> 
    10、复制功能是否可用
    11、粘贴功能是否可用、粘贴超过最大长度的字符串怎么显示?
    12、多浏览器的兼容性
    13 、权限校验


    数值型的输入框测试点:
    1、重复
    2、空 不填写是否支持
    2、数值类型:
       a: 小数 支持的位数、不够支持的位数时,后面是否自动补零,超过支持的位数时,是四舍五入还是直接舍去
       b: 整数 
    3、0 是否支持、是否符合业务逻辑
    4、负数是否支持
    5、数值的范围:例如 -5<X<5
       a: 小数类型时且为4位小数时:-5.0000 -4.9999  0.0000 4.9999 5.0000
       b:整数类型时:-5 -4 0 4 5
    6、非数字类型是否支持输入
    7、半角的数字、全角的数字
    8、空格+数字
    9、多浏览器的兼容性

    10、权限校验

    更多相关内容
  • 测试用例常见思路和测试方法

    目录

    1.新增功能

        1.1功能类

        1.2事务处理测试

        1.3界面初始加载数据测试

        1.4后台文件处理测试

    2.修改测试

        2.1功能测试

        2.2事务处理测试

        2.3界面初始加载数据测试

        2.4后台文件处理测试

        2.5级联更新测试

    3.删除测试

        3.1功能测试

        3.2删除界面测试

        3.3事务处理测试

        3.4后台文件处理测试

    4.查询测试

        4.1功能测试

        4.2查询结果的测试

        4.3查询效率

    5.测试用例设计方法

    1.新增功能

    1.1功能类

    测试点细化
    全部正确
    全部必输正确
    全部必输加部分可选正确
    只有一个错误其他正确类型错误
    长度错误
    主键约束错误(不能重复、不能为空)
    外键约束错误(外键值只能是已经存在的某个主键值)
    非空约束错误(不允许)
    唯一性约束错误(不允许重复)
    检查约束错误(不满足规定的条件:年龄0-200)
    多个错误输入检查是否只弹出一个错误提示框

    1.2事务处理测试

    一个功能按钮对应多条SQL命令(前提)
    使用select命令逐一检查每一条SQL命令是否都正确执行
    事务并发测试同时多人进行相同操作
    事务异常测试(可靠性测试)服务异常
    网络异常
    服务器异常(断电、关机、重启)
    客户端异常(浏览器关闭,客户端程序退出)
    事务性能测试(效率测试)同时进行大量相同操作时,响应时间和资源占用率

    1.3界面初始加载数据测试

    界面打开后,是否存在默认显示数据(前提)
    默认值是否存在
    默认值是否正确不同的权限、不同的用户打开相同窗体,加载内容是否有不同
    默认值是否完整

    1.4后台文件处理测试

    在处理过程中存在文件操作(创建、修改、删除、传输[上传、下载])
    文件操作是否正确进行
    文件位置是否正确
    文件名及类型是否正确
    文件内容是否正确
    对应的硬盘空间是否足够
    文件处理过程中发生异常(处理还没有完成时,异常发生)
    同时多人进行相同的操作(是否产生冲突)
    若要对文件进行删除操作(文件当前是否被占用或打开)
    文件处理的时间和资源占用

    2.修改测试

    2.1功能测试

    全部数据进行修改
    全部必输数据进行修改
    全部必输加部分可选数据进行修改
    将其中一个数据修改为错误其他正确类型错误
    长度错误
    主键约束错误(不能重复、不能为空)
    外键约束错误(外键值只能是已经存在的某个主键值)
    非空约束错误(不允许)
    唯一性约束错误(不允许重复)
    检查约束错误(不满足规定的条件:年龄0-200)
    多个数据修改为错误检查是否只弹出一个错误提示框
    所有数据保持不变,直接点击修改按钮

    2.2事务处理测试

    一个功能按钮对应多条SQL命令(前提)
    使用select命令逐一检查每一条SQL命令是否都正确执行
    事务并发测试同时多人进行相同操作
    事务异常测试(可靠性测试)服务异常
    网络异常
    服务器异常(断电、关机、重启)
    客户端异常(浏览器关闭,客户端程序退出)
    事务性能测试(效率测试)同时进行大量相同操作时,响应时间和资源占用率

    2.3界面初始加载数据测试

    界面打开后,是否存在默认显示数据(前提)
    默认值是否存在
    默认值是否正确不同的权限、不同的用户打开相同窗体,加载内容是否有不同
    默认值是否完整
    检查界面上显示的内容是否与数据库中存储完全一致

    2.4后台文件处理测试

    在处理过程中存在文件操作(创建、修改、删除、传输[上传、下载])
    文件操作是否正确进行
    文件位置是否正确
    文件名及类型是否正确
    文件内容是否正确
    对应的硬盘空间是否足够
    文件处理过程中发生异常(处理还没有完成时,异常发生)
    同时多人进行相同的操作(是否产生冲突)
    若要对文件进行删除操作(文件当前是否被占用或打开)
    文件处理的时间和资源占用

    2.5级联更新测试

    界面能看到主键字段对应的值,且主键值可以允许用户修改(前提)
    修改该主键值后,一定要逐一检查该主键对应的所有外键值是否同时被修改

    3.删除测试

    3.1功能测试

    真删除功能测试该表是否有关联的从表独立表直接删除
    该表是一个主表存在关联的从表记录不允许删除
    允许删除(要把所有的从表记录一并删除)
    删除学生信息,连同学生的所有成绩记录一并删除
    该表是一个从表直接删除
    假删除功能测试该表是否有关联的从表独立表直接假删除
    该表是一个主表存在关联的从表记录允许假删除(所有从表的记录一并被假删除)
    允许假删除(所有从表的记录保持不变)
    该表是一个从表直接假删除
    假删除存在的后续问题被假删除的记录是否参与去重判断
    被假删除的记录是否参与统计

    3.2删除界面测试

    选择一条记录进行删除
    选择多条记录进行删除
    不选择任何记录进行删除
    删除按钮点击后,一定有错误提示
    当前记录正被占用,不允许删除

    3.3事务处理测试

    一个功能按钮对应多条SQL命令(前提)
    使用select命令逐一检查每一条SQL命令是否都正确执行
    事务并发测试同时多人进行相同操作
    事务异常测试(可靠性测试)服务异常
    网络异常
    服务器异常(断电、关机、重启)
    客户端异常(浏览器关闭,客户端程序退出)
    事务性能测试(效率测试)同时进行大量相同操作时,响应时间和资源占用率

    3.4后台文件处理测试

    在处理过程中存在文件操作(创建、修改、删除、传输[上传、下载])
    文件操作是否正确进行
    文件位置是否正确
    文件名及类型是否正确
    文件内容是否正确
    对应的硬盘空间是否足够
    文件处理过程中发生异常(处理还没有完成时,异常发生)
    同时多人进行相同的操作(是否产生冲突)
    若要对文件进行删除操作(文件当前是否被占用或打开)
    文件处理的时间和资源占用

    4查询测试

    4.1功能测试

    查询条件都为空时进行查询
    一次只输入一个查询条件进行查询
    输入全部查询条件进行查询
    将其中一个查询条件构造为错误,检查程序是否对参数进行了校验类型错误
    长度错误
    主键约束错误(不能重复、不能为空)
    外键约束错误(外键值只能是已经存在的某个主键值)
    非空约束错误(不允许)
    唯一性约束错误(不允许重复)
    检查约束错误(不满足规定的条件:年龄0-200)

    4.2查询结果的测试

    根据各种不同的查询条件,构造充分的查询数据支持模糊查询(通配符的选择是否正确)
    例如 姓张  张X、张XX、 张XXXXX 、X张X 、XX张、X张、 张X张XXX张
    支持多个条件的逻辑查询(and,or, not)
    构造有多条数据满足查询条件(子查询返回的值为多个)
    构造数据精度(统计平均值)

    4.3查询效率

    构造大量数据进行查询创建存储过程
    输入全部查询条件进行查询性能测试

    5测试用例设计方法

    5.1等价类法

    设计步骤
    1、SRS—>对应了哪些输入参数,并分析输入参数的规则要求
    2、针对每一个输入参数—>等价类表
    3、针对每一个等价类(有效、无效)—>给定相关测试数据
    4、设计用例(一个用例包含尽量多的有效等价类,一个用例只能包含一个无效等价类)

    优点缺点
    简单、高效1、数据是任意选取,不一定能发现缺陷
    2、不考虑数据之间的组合

    适用范围典型例证分析对象
    任何存在独立输入参数126邮箱注册独立的输入参数---文本输入框

    5.2边界值法

    1、在等价类表的基础上
    2、SRS—>增加相应的边界数据(上点、离点),放入对应的有效或无效等价类中
    3、构造用例的方法与等价类相同
    边界上更容易发现缺陷必须存在边界
    任何存在边界的输入参数任何存在边界的数据独立输入参数的边界

    5.3正交试验法

    1、SRS—>因子(输入参数)
    2、SRS—>每个因子对应的多个状态
    3、工具:画出因子状态表
    4、将该excel表格拷贝到txt文档中
    5、将txt文档保存到allpairs路径下
    6、执行allpairs命令:allpairs.exe a.txt -> b.txt
    7、生成测试用例
    保证所有输入参数的两两全组合都被覆盖到只适合于因子之间是完全独立的没有约束关系
    只适合于因子之间是完全独立的没有约束关系
    且由于选择不同的状态值,会有不同的处理路径
    1、多个复选框
    2、多个条件的并列组合
    输入参数取值的组合

    5.4输入域覆盖法

    1、SRS分析对应的输入参数是否存在特殊值
    2、若存在特殊值,补充特殊值测试数据
    3、补充输入参数的类型边界数据,检查是否会出现内存溢出

    不一定存在
    存在特殊值和类型边界手机号码、电话号码、邮箱输入参数

    5.5判定表法

    1、SRS—>条件桩:输入条件的组合,条件表达式,判定框
    2、SRS—>动作桩:输出结果
    3、组合所有的条件项
    4、SRS—>分析每一组条件项对应的动作项
    5、每一列对应一条测试用例(2的n次方)
    达到了所有条件的全组合覆盖1、条件桩过多时,用例呈2的指数倍增长
    2、判定表合并会造成漏测风险
    多个独立并且无关联的条件组合(条件无顺序和约束)1、a+b>c&&a+c>b&&b+c>a
    2、满足条件1时,a=b||b=c||c=a
    3、满足条件1时,a=b=c
    4、满足条件1时,a2+b2=C2
    条件(逻辑条件)和结果之间关系

    5.6因果图法

    1、SRS—>原因—>编号
    2、SRS—>结果—>编号
    3、画原因结果表
    4、SRS—>画因果图
    5、依据因果图—>去除判定表中不存在的组合

    6、判定表每一列对应一条测试用例
    可以去除不存在的条件组合因果图难构造
    多个条件有相互制约关系自动售货机、游戏规则条件(有约束的关系的逻辑条件)和结果之间的关系

    5.7流程分析法

    1、SRS—>判定条件(如果,假如,当)
    2、注意:挖掘SRS中没有提到的隐性判定条件
    3、依据分析出的判定条件,画出业务处理流程图(或借用判定表的思想,绘制条件组合)
    4、每一个处理路径对应一条测试用例(判定条件+1)
    即覆盖了输入有考虑和处理过程和输出结果1、无效数据的测试不充分
    2、只考虑基本路径的覆盖,不是全路径覆盖
    任何场合
    (先有功能处理流程图)
    流程操作处理过程(安装测试)输入、处理、输出的覆盖分析

    5.8状态迁移图法

    1、SRS—>状态名称
    2、SRS—>状态矩阵
    3、状态矩阵—>状态树
    4、从状态树的根到叶子节点的每一条路径对应一条测试用例
    保证每一个状态的所有可达状态都覆盖到不能保证所有状态的组合
    存在状态变化的功能用户状态变化,mp3播放器,订单状态变化状态变化规律

    5.9输出域覆盖法

    1、通过与开发的沟通,明确对应功能所有可能的输出结果有哪些
    2、逐一罗列
    3、检查对照现有测试用例是否已经覆盖了所有的输出
    4、若没有完全覆盖,则根据输出结果要求,倒推补充测试用例
    能保证所有的输出结果都的得被覆盖到对业务、设计和代码要熟悉
    任何场合(存在输出结果)非界面输出(数据库、文件、环境参数变化)输出结果的分析

    5.10异常分析法

    1、SRS—>构造环境异常(网络、电源、服务、客户端、程序关闭)
    2、补充异常测试用例
    可靠性测试异常不容易构造
    可靠性要求较高的系统断网
    断电
    程序退出
    中断服务
    环境异常

    5.11错误猜测法  经验法

    展开全文
  • 测试用例设计思路参考

    千次阅读 2022-01-17 17:54:22
    测试用例设计思路参考 一、业务层面 需求点是新增,还是优化; 需求点对老业务是否有影响; 需求点修改点,对业务方下游应用的影响; 需求点修改点,是否涉及核心链路逻辑,如激活配网,设备,产品等核心...

    测试用例设计思路参考

    一、业务层面

    • 需求点是新增,还是优化;

    • 需求点对老业务是否有影响;

    • 需求点修改点,对业务方下游应用的影响;

    • 需求点修改点,是否涉及核心链路逻辑,如激活配网,设备,产品等核心服务。

    • 是否受角色权限影响,影响点包含:操作权限,角色:超级管理员,普通管理员等

    • 是否受账号影响,影响点包含:操作权限、隔离,账号属性:子账号,企业账号

    • 是否受多少企业协同逻辑影响,影响点包含:协同后操作权限,信息安全等。

    • 需求点在产品,子产品,子型号,定制机逻辑是否有影响

    • 更新、删除逻辑约束,如产品量产了,就不能删除了。

    • 需求点涉及是产品级、设备级、还是用户级,影响面需要评估。

    • 需求点是否涉及到diamond或switch配置变更,变更影响需求点发布时,是否有灰度或风控开关

    • 需求点是否涉及到交易、是否存在资损,资损点验证

    • 需求点是否涉及数据迁移,是否需要数据订正才能兼容老逻辑

    • 需求点涉及涉及安全影响,如越权。

    • 需求点修改的逻辑,是否是公共逻辑,修改是否对老业务存在影响。

    • 需求点修改的逻辑,是否涉及特殊的通过switch或diamond配置的逻辑。

    二、接口测试

    遵循BCDE设计原则

    • B:border,边界测试,包含参数校验。

    • C:correct,正确输入,正确预期输出;

    • D:design,按需求与设计文档编写测试逻辑,测试结果match需求功能效果。

    • E:error,错误输入,预期错误输出

    • 接口是否涉及缓存,缓存失效,是否存在缓存穿透与击穿。

    • 接口是否涉及DB数据变更(增删改),评估增加数据验证。

    • 了解上下游业务调用场景,评估是否需要增加场景用例。

    • 接口修改是否对前端逻辑有影响,测试时,需要覆盖前端调用点。

    • 接口实际调用量,是否涉及性能测试,老接口优化是否影响接口性能,性能包含:RT,QPS等

    • 接口异步还是同步,异步逻辑有哪些,是否补充验证点

    • 接口涉及到消息发送与接收时,处理逻辑是否覆盖接口上游容错处理,依赖上游服务异常时,接口工作可靠性与稳定性。

    • 接口下游兼容处理,兼容多个业务方下游要求,修改优化时,考虑兼容性,用例也要评估。

    • 异常场景影响,断网异常、token失效等影响用例。

    • 接口入参与DB字段有关联时,确认DB非NULL与入参非NULL关系验证。

    • 代码review,日常打印是否规范,不能打印堆栈。

    展开全文
  • 测试用例设计思路

    2021-08-27 22:34:50
    测试用例编写思路: 首先是明确测试范围: 功能测试 界面测试(界面友好性、易用性、一致性) 兼容性测试(不同类型、型号手机、系统(手机系统、桌面系统)、分辨率、浏览器及其版本) 性能测试(页面加载时间...

    测试用例编写思路:

    首先是明确测试范围:

    接口测试

    功能测试

    界面测试(界面友好性、易用性、一致性)

    兼容性测试(不同类型、型号手机、系统(手机系统、桌面系统)、分辨率、浏览器及其版本)

    性能测试(页面加载时间(1万条记录)、响应时间、内存占用)

    安全测试(漏洞扫描、链接安全等)

    稳定性测试(长时间给予压力:80%内存占用)

    可靠性测试(断电、断网、高内存、低网速)

    功能模块中明确测试范围::

    1、划分功能模块

    2、正向功能验证:正常功能是否实现

    3、单个功能项验证:正向+异常

    4、功能之间交互验证:模块之间的数据传递

    5、隐形需求:熟悉业务

    如:

    2.1 web登录页面的测试

             分析:首先我们可以分析一下,该界面都有哪些哪些元素,每个元素又具备哪些规则要求,是否有其他特殊化要求,比如缓存,加密等;分析完毕后,我们就可以根据了解到的去选择合适的测试用例设计方法,对这个页面进行用例的编写。

    2.1.0 UI界面测试

           首先对于用户来说,对一个系统的评价,首先从界面视觉方面去判断,就好比男女之间的第一次见面,嗯,你想的没错,就是相亲,第一印象基本上是从个人长相,精神面貌来的,我们都知道第一印象很重要,尤其是在如今这个快节奏的社会;

           对于一个用户来说,界面的风格,人机交互性,易理解性,易操作性等将直接印象用户的第一使用体验,假如第一使用体验都不好了的话,假如该产品不是不可替代性的产品的话,用户很有可能就此流失掉,假如该系统是用户已经付费了的,虽然不好看的页面,难于操作的页面,难于理解的页面不会马上导致客户退货,但起码会使该用户产生一种一点都不专业的感觉,接下来用户很可能带着一种不愉快的心情去操作了,这就很有可能导致各种各样的刁难挑刺,最终导致彻底对该产品失去兴趣,要不就是打回要求重新调整,要不就是退回退款。

          大部分产品开发过程中,在前期需求确定及评审过程中就会这方面进行一定讨论研究,所以建议测试同学在需求阶段就要介入进去,从界面风格,人机交互性,易理解性,易操作性等几方面去进行审视,给出比较不错的建议。

           根据一般的测试套路,我们先是进行基本的功能测试,只有基本的功能实现了,我们才有意义去进行其他方面的测试。

    备注:扫一扫登录页面由于过于简单就不在此进行阐释了

    2.1.1功能测试

            结合我们所掌握到该页面的相关需求知识以及我们后期拓展到的隐性需求(最好在需求阶段就提出来),提炼出我们所需要的测试点,然后再结合我们所掌握的测试用例设计方法进行测试用例的编写。

    以下就是提炼出的测试点:

                       1.输入框的空值登录

                       2.输入框的空格测试

                               a.账号密码输入框前后中间有空格是否有过滤处理处理

                       3.有效账号密码等信息登录

                       4.无效账号密码信息登录

                                     a.正确账号,错误密码

                                     b.不存在的账号,A账号的密码

                                     c. A账号,B账号的密码

                      5.密码特殊要求测试 

                                    a.在输入框内是否密文展示

                                    b.是否可从外部复制到输入框

                                    c.是否可从密码输入框复制密码出去

                                    d.密码防破解机制验证

                                    e.密码在传输过程中及日志信息中是否做了加密处理

                                    f.密码在数据库表中是否以加密形式保存

                                    g.密码信息是否会被浏览器所记住并保存  

                        6.验证码测试

                                    a.输入正确的验证码登录

                                    b.验证码输入框置空登录

                                    c.输入错误的验证码登录

                                    e.输入过时的验证码登录

                                    f.图片刷新机制是否合理

                         7.账号密码记忆保存测试

                                    a.正确账号密码登录成功后记忆保存

                                    b.正确账号错误密码登录失败后是否只保存账号信息

                                    c. 错误账号登录错误密码登录失败是否会保存

                                    d. 正确账号,密码置空登录,是否会保存账号信息

                                    f. 记忆保存有效时间验证

                                    g. 手动清除缓存是是否仍然保留登录信息

                        8.同时登录测试

                                    a.一个账号能否在同一浏览器上同时登录

                                    b.一个账号能否在同一台机器上不同浏览器同时登录

                                    c.一个账号能否在不同机器上同时登录

                                    d.一个账号能否在web端和移动app端同时登录

                                   e.二个账号能否在同一浏览器上同时登录

                                   f.二个账号能否在同一台机器上不同浏览器同时登录

                       9.默认语言的记忆测试

                                  a.修改界面语言选项,成功登陆后,下次登录是否会记忆上次保存的语言

                                  b.修改界面语言选项,登录失败后,当前页面是否会保存修改的语言

                                  c.修改界面语言选项,登录失败后,关闭浏览器,下次打开登录是否保存上次的语言选项

                       10.输入框长度限制测试

                       11.输入框可输入类型测试

                       12.输入框的大小写是否敏感

    2.1.2 友好及易操作性测试

         1.在输入框内能否使用windows常用快捷键,比如复制粘贴,tab切换,回车等

         2.在输入框内能否切换大小写,输入法,且切换后是否有相应提示

         3.网络异常时,是否有友好加载页面提示

         4.各种登录失败情况下的提示是否友好,清晰,易懂。

    2.1.3 健壮性测试

          1.对浏览器程序进程杀死,重新打开浏览器,已输入的登录信息是否还在

          2.登录页面与其他页面页签之间的切换以及缩小到后台,已输入的登录信息是否还在

          3.假如快速多次点击登录按钮界面是否仍然正常显示及提示

          4.假如快速进行多次刷新操作,界面是否仍然显

    2.1.4 安全测试

          1.账号密码框是否屏蔽SQL注入攻击

          2.账号密码输入框是否禁止脚本输入(避免XSS攻击)

          3.登录是否有防破解机制

          4.密码的缓存信息是保存在cookies中还是session中

          5.密码在任何场所是否都是加密形式展示的

          6.密码是否具有有效期,有效期到快到或者到期后,是否需要提示修改密码

          7.不登录的情况下,直接输入登陆后的url访问,重定向到用户登录页面

          8.密码输入框是否支持复制粘贴

          9.密码输入框输入的密码是否可以在页面源码模式下被查看

         10.同一用户在同一终端的多种浏览器上登录,验证登录功能的互斥性是否符合设计预期

         11.同一用户先后在多台终端的浏览器上登录,验证登录是否具有互斥性

    2.1.5 性能测试

          1.单用户打开登录页面及登录所花的时间是否满足要求

          2.点击登录按钮进入到登录成功后的页面所花时间是否满足要求

          3.支持多少人同时正常打开,同时正常登录操作

          4.单用户登录时,后台请求数量是否过多

          5.高并发场景下用户登录的响应时间是否小于规定值

          6.高并发场景下服务端的监控指标是否符合预期

          7.高集合点并发场景下,是否存在资源死锁和不合理的资源等待

          8.长时间大量用户连续登录和登出,服务器端是否存在内存泄漏。

    2.1.6 兼容性测试

          1.主流的浏览器及各版本,是否很好的兼容该页面

          2.不同的操作平台及各版本是否正常使用

          3.不同屏幕分配率是否合理的显示该页面

         4.放大缩小状态下界面显示是否正常

    2.2 一个水杯的测试(以喝水的杯子为准)

            以此例子来说明,一般我们的测试思路可以怎么展开,其实和上个例子一样的思路,再举例说下这个例子,是用来说明作为测试同学来说,具备很强的逻辑归纳能力,很强的发散思维能力,及很强的产品用户思维能力是很重要的。

    2.2.1 UI界面测试

          1.整体形状外观是否符合用户审美观

          2.杯身图案是否符合用户需求,是否涉及到民族,伦理道德,商业侵权等会引起纠纷的标识

    2.2.2功能测试

          1.能否正常装水

          2.能否正常喝水

    2.2.3 易用性测试

          1.杯子是否容易装水

          2.杯子是否容易出水

          3.杯子是否很方便的拿放(体积质量是否合理)

    2.2.4 健壮性测试

          1.当水装过满的时候,是否有预防水漫出的机制

         2.当水喝的几乎没有的时候,剩下的一点点水是否能够顺利的喝到

         3.当水杯不小心打翻时候,是否很好的避免水流出

         4.当用户手湿滑时候,是否也能够顺利拿起放下杯子

    2.2.5 安全测试

          1. 制作杯子的材料是否会对用户造成损害

          2. 当杯子不小心打碎的时候,碎片是否会伤害到用户

          3. 当装的水过热或者过冷的时候,是否会对用户造成伤害

          4. 当杯子由于外部原因被加热过或者被冰冻过,是否会对用户造成伤害

          5. 当杯子长时间装水状态下,是否会滋生细菌或产生危害到用户的事务

          6. 当杯口以及杯身出现裂痕的时候,是否会对用户造成割伤

          7. 当杯子放进微波炉时,杯子是否会发生爆炸或融化

    2.2.6 性能测试

          1. 杯子在长时间震动下是否会破碎

          2. 杯子在长时间装水状态下是否发生漏水

          3. 当用户使用杯子时用力过猛情况下,杯子是否会破碎

          4. 当杯子不小心摔下的时候,是否会发生破碎变形现象

          5. 当杯子装入过热或过冷的水时,杯子是否会发生破裂等事故

          7. 当杯子用久了,杯身是否会掉色,杯体是否会发生变形,褪色等

    2.2.7 兼容性测试

          1. 杯子除了装水外,是否还能装其他液体。

          2. 杯子除了装液体外,是否还能装固体

          3. 杯子是否能液体和固定的混合物

          4. 杯子是否可以在一些特殊场合使用

    参考自:https://www.cnblogs.com/Aaron-007/p/10697277.html

    展开全文
  • 【接口测试用例设计思路

    千次阅读 2022-03-11 10:11:08
    接口测试用例设计 2.1、接口参数基本校验 2.2、正常功能逻辑校验 2.2.1、入参处理 2.2.2、常用变量类型注意点 2.2.3、实际业务校验点 2.3、异常处理逻辑 2.4、日志检查 2.5、数据一致性 2.6、写接口相关 ...
  • APP测试用例设计思路

    2017-10-16 11:25:25
    APP测试用例设计思路,用于各种移动开发软件的测试用例设计所需。
  • 一四年我在YX公司带测试团队,一个用例评审的会议上,一不小心超常发挥,结果卡在了一个用例设计方法上,印象非常深刻,当时的业务场景是支付方式的选择和优惠方案。在后来的工作中,也曾几次遇到需要选择合理的设计...
  • 非常详细的测试用例,反正我是感觉项目中写用例的时间非常短),总结自己的一些经验,不单单是用例设计,还涉及到一些其他方面。简单7个步骤:1、理清模块需求:----由于项目需求说明书不详细,而且没有进行需求评审...
  • 在日常工作中,我们主要测试的都是功能板块,如果你想真正了解接口测试,那么这篇文章或许能给你一定帮助。1、为什么我们要做接口测试?首先,我们先来看看测试金字塔(接口测试是在中间部分,底层是单元测试,最顶....
  • 设计一系列测试用例用以测试这个Web页面。 有经验的测试人员可能会问面试官,字母a区分大小写吗?只统计英文字母的a吗?最长输入字符是多少,最少输入字符是多少?对输入的字符类型是否有限制,是否会自动清除...
  • 针对于游戏测试,大多更偏向于功能方面的测试,根据功能测试用例逐项测试,检查产品是否达到了策划的需求。功能测试主要采用黑盒测试策略设计测试用例,进行测试。主要功能模块测试的测试用例设计方法包括:等价类...
  • 功能测试用例设计方法》完整版 概述 功能测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。 等价类划分法 概念 等价类划分法是...
  • 测试用例编写思路

    2022-08-16 14:52:26
    测试用例编写思路
  • 测试用例设计思路

    千次阅读 2020-12-17 11:46:36
    第1步需要设计体现业务流程的测试用例,大概有几个用例来主要测试流程,同时这部分也可作为冒烟测试用例,通过这几个用例,大概能够清楚这个迭代的主要功能,业务逻辑是否正确 比如:以一个业务的流程为例:新增...
  • 【测试】编写测试用例思路和方法

    千次阅读 多人点赞 2021-05-15 15:36:53
    文章目录1)什么是测试用例?1.1 测试用例的定义测试用例的内容:*为什么需要测试用例?...*如果没有需求文档,怎么设计测试用例?2.2 提取测试点【举例】对PC端QQ账号的登录模块,提取测试点:【举例】对
  • 查询功能测试用例

    千次阅读 2021-03-17 15:48:48
    查询功能测试点非常丰富,主要测试功能是否能正常使用,功能正常的情况可以参考成熟度高的产品,设计更多易用性操作。 一、查询功能验证 (1)验证精确查询,输入完整标题查询 (2)验证模糊查询,输入关键字查询,...
  • 思路:输入的集合是无穷的,不能全部都覆盖到等价类:依据需求将输入划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例测试通过,则认为所代表的整个等价类测试通过,这样就可以通过较少的测试用例达到...
  • (当然什么时候测)测什么的问题由接口清单来解决,而怎么测的问题由测试用例设计和用工具执行测试用例来解决。有关于接口清单和用工具执行测试用例,我们已经在下面的这篇文章中介绍过了,这篇文章来介绍一下测试...
  • 测试用例设计思路与步骤

    千次阅读 2020-09-17 09:35:38
    测试用例设计的几个准则 1、用例设计=思路。 强调测试的场景,测试方法。 2、测试步骤化。 此处说的测试步骤,不是说每条测试用例都要写明测试步骤,而是指那些通过测试步骤的调整会出现缺陷的地方需要重点关注测试...
  • 基于网络摄像机和终端的一些功能测试点的思路
  • 功能测试用例设计方法分享

    千次阅读 热门讨论 2020-12-15 16:32:45
    针对于游戏测试,大多更偏向于功能方面的测试,根据功能测试用例逐项测试,检查产品是否达到了策划的需求。功能测试主要采用黑盒测试策略设计测试用例,进行测试。主要功能模块测试的测试用例设计方法包括:等价类...
  • 测试用例设计方法详解

    千次阅读 2022-04-02 14:09:54
    一、测试用例编写前需要进行需求分析 1.测试分析的必要性 (防止漏测,确定测试需求等) 2.测试分析的简要流程(获取测试需求--...二、测试用例设计方法 用例设计方法的作用:测试无法做到穷尽测试,开拓思路需...
  • 今天给大家分享在做软件测试时,最容易忽略但却重要的知识点,那就是测试用例设计。用例设计就是软件测试工程师的灵魂,体现了你的测试思维,以及对业务需求的熟悉程度。有时侯出现线上事故,可能就是测试用例没有...
  • 测试用例设计与管理思路整理 软件测试 简单7个步骤: 1、理清模块需求: ----由于项目需求说明书不详细,而且没有进行需求评审的情况下,在拿到上级lead给的测试任务后,一拿到先别着急去写测试用例,首先你应该...
  • 接口测试简介以及接口测试用例设计思路

    万次阅读 多人点赞 2018-09-07 11:50:27
    接口测试简介 1.什么是接口 接口就是内部模块对模块,外部系统对其他服务提供的...开发所谓的接口是模块模块之间的一种连接,而测试眼中的接口是一种协议(对接口的功能的一种定义) 2.接口的种类和分类 外部接...
  • 大转盘活动测试用例设计 题目:2019年双11公司内部员可参与抽奖,每人每天可参与一次抽奖,好友助力,最多额外获得3次机会。 思路: 一、功能验证,所有的功能点是否符合需求设计,比如 1)身份验证:未登录时点击...
  • app测试用例设计

    千次阅读 2022-05-31 20:58:04
    app测试用例设计思路
  • 一、如下接口用例设计思路供你参考 1、先看接口文档,弄懂业务逻辑; 2、保证接口功能正常运行,输入正确的参数是否能得到正确的输出参数; 3、考虑输入参数的异常情况(必填项、长度、类型、空值、增减...
  • 测试用例设计步骤

    2022-06-27 20:48:37
    软件测试入门

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 28,167
精华内容 11,266
关键字:

功能测试用例设计思路