测试常用方法及应用场景

1、你在编写测试用例使用哪些方法?

1:等价类划分法(重点)
应用场景:多用于输入框
等价类划分是指分步骤地把海量(无限)的测试用例集减得很小,但过程同样有效。
等价类 :何为等价类,某个输入域的集合,在这个集合中每个输入条件都是等效的。
一般可分为有效等价类和无效等价类

有效等价类:指符合《需求规格说明书》,输入合理的数据集合
无效等价类:指不符合《需求规格说明书》,输入不合理的数据集合

2:边界值法(重点)
一般边界值分析是因为程序开发循环体时的取数可能会因为<,<=搞错。
2.1确定边界值的方法(重点)
选取正好等于、刚刚大于或刚刚小于边界值作为测试数据
注明:边界值不是从每个等价类中挑一个作为代表,而是把每个等价类的边界都进行测试。

3.因果图法(了解)
概念:
因果图法比较适合输条件比较多的情况,测试所有的输入条件的排列组合。所谓的原因就是输入,所谓的结果就是输出

因果图基本图形符号
恒等:若原因出现,则结果出现;若原因不出现,则结果不出现。
非(~):若原因出现,则结果不出现;若原因不出现,则结果出现。
或(∨):若几个原因中有一个出现,则结果出现;若几个原因都不出现,则结果不出现。
与(∧):若几个原因都出现,结果才出现;若其中有一个原因不出现,则结果不出现。

因果图的约束符号
E(互斥):表示两个原因不会同时成立,两个中最多有一个可能成立
I(包含):表示三个原因中至少有一个必须成立
O(惟一):表示两个原因中必须有一个,且仅有一个成立
R(要求):表示两个原因,a出现时,b也必须出现,a出现时,b不可能不出现
M(屏蔽):两个结果,a为1时,b必须是0,当a为0时,b值不定

4:判定表法(了解)

5:场景法(重点)
测试用例设计的思想
现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入 到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。

用例场景是通过描述流经用例的路径来确定的过程,
这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

6:错误推测法(了解)
定义:
错误推测法:根据经验或直觉推测程序中可能存在的各种错误,从而有针对性地编写检查这些错误的测试用例的黑盒测试方法

技巧:
最重要的是要思考和分析测试对象的各个方面,多参考以前发现的bug的相关数据,总结的经验,个人多考虑异常的情况、反面的情况、特殊的输入,以一个攻击者的态度对待程序,就能设计出比较完善的测试用例来。

7:正交表法(知道)
正交表能够在因素变化范围内均衡抽样,使每次试验都具有较强的代表性,由于正交表具备均衡分散的特点,保证了全面实验的某些要求,这些试验往往能够较好或更好的达到实验的目的。正交实验设计包括两部分内容:第一,是怎样安排实验;第二,是怎样分析实验结果。

应用场景:
在一个界面中有多个控件,每个控件有多个取值,控件之间可以相互组合,不可能(也没有必要)为每一种组合编写一条用例,如何使用最少最优的组合进行测试。——正交排列法

正交表测试用例设计方法的特点是什么?
1、用最少的实验覆盖最多的操作,测试用例设计很少,效率高,但是很复杂;
2、对于基本的验证功能,以及二次集成引起的缺陷,一般都能找出来;但是更深的缺陷,更复杂的缺陷,还是无能为力的;
3、体的环境下,正交表一般都很难做的。大多数,只在系统测试的时候使用此方法。

2、测试用例模板/ 测试报告模板 / 测试计划模板

1. 测试用例模板
用例编号、所属模拟、测试模块、用例标题、用例级别、前置条件、测试输入、执行操作、预期结果,实际结果….

2.测试报告模板
测试目标,测试依据,测试范围,测试环境,测试进度,执行结果,缺陷分布,遗留缺陷,测试结论,建议,附录等

3.测试计划模板包含
确定测试范围,制定测试策略,测试资源安排人员的分配,时间安排,风险分析等

3、需求变动应该如何

1.前期需求调研工作没有做到位,在需求调研时没有真正深入了解用户需要什么东西?用户做这个东西的目的是什么?为什么要这么做?

2.项目经理对项目掌控力度够,如果一个项目的需求一定情况向,尽可能避免在短时间里频繁变更,可以采用集中变更或者分阶段变更

3.客户在最开始时自己也没搞清楚要做出什么样子?随着系统的成型上线,提出一些新想法等导致需求变更。

4.客户就是上帝,所以有些变更时必须的

测试人员如何面对变更?

1. 协调制定变更规范,比如说每次需求人员都会发出变更申请书,这样可以作为开发人员和测试人员工作的依据。如果这点也做不到的话,建议把发给开发人员的变更信息同时抄送给测试人员,使测试人员和开发人员保持信息基本一致

2. 在每次测试前,一个比较详细的测试测试任务列表单,同时注明本次测试的侧重点【变更哪些需求、新增了哪些需求】,找相关人员确认【可以抄送多人】

3. 良好的团队合作。对新的改动及时通知对方,短时间内开展最有效的团队协作及时沟通,需求相关人员和开发人员、测试人员做好即时沟通,第一时间知道需求的变更,及时做好测试策略更新。知道的越早对我们的影响越小,需要的测试成本也越低。

4. 及时整理并记录测试需求变更,在每次不论通过何种方式得到需求变更信息,都要及时记录,以便以后测试

5. 每天保持记录测试工作日志,主要包括【1.测试中遇到的问题及其解决方式(可以形成测试知识库)、2.记录测试任务及其工作成果(主要是记录今天做了什么?成果是什么?以便以后总结)、3.记录测试进度(记录个人或者团队的工作进度情况;这样时间长了就基本可以评估测试那个模块,那个流程,哪一类问题需要多长时间,以便对日后工作做一个计划)、4。记录测试问题总结等(对问题归类总结,时间长知识库、日后需要加强学习和注意的地方)】

6. 测试人员应该把需求变化当作是一种项目常态,平常心应对。任何项目要想安装预期规划发展那几基本上是做不到的,所以变更将是我们工作中的一个常态。

4、举出测试用例方法及其应用场景

测试方法以及应用场景
方法:等价类划分法,边界值法,场景法,因果图法,正交表法。

常用的场景:
等价类划分法
多用输入框:注册?登入

边界值
多和等价类划分法结合使用,有便捷限制的:注册的密码长度

场景法
从基本流开始,再将基本流和备选流结合起来,可以确定用例场景

正交表法
用于多个下拉框中间的组合,可以通过正交助手生成测试用例

错误推测法
错误猜测发是测试经验丰富的人喜欢使用的一种测试用例设计方法
一般这种方法是基于经验和直觉推迟程序中可能发送的各种错误,有针对性地设计,

因果图法
因果图法比较适合输条件比较多的情况,测试所以的输入条件的排列组合,所谓的原因就是输入,所谓的结果就是输出

  • 2
    点赞
  • 28
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
测试阶段 3 测试用例的分类 3 文本框需求 4 字段为特殊代码校验: 4 文本框为数值型 4 文本框为日期型 5 文本框为时间型 6 密码框 返回目录 6 单选按钮 7 组合列表框/下拉列表 7 数码框(up-down)控件 8 搜索框填充域测试 8 复选框 9 滚动条 9 通过测试: 返回目录 9 失败测试: 10 登陆 10 添加 10 删除 10 查询 返回目录 11 翻页控件 12 树控件的测试外观操作返回目录 12 命令按钮 返回目录 13 一、各种控件在窗体中混和使用时的测试 13 选项卡 返回目录 14 默认焦点 14 TAB顺序 14 快捷键/热键 14 上传文件的测试 14 下载文件的测试 15 【安全性测试】 16 功能测试 v返回目录 16 兼容性测试 17 【性能测试】 17 邮箱输入框字段校验测试 18 验证码输入框字段校验测试 18 替换测试大体相同. 返回目录 19 插入文件 19 链接文件 19 插入对象 19 编辑操作 19 界面测试【UI】 20 窗体 20 标题栏 21 文字 21 控件 21 图片 22 窗口在任务栏上的系统菜单 22 提示对话框测试要点: 23 菜单 23 特殊属性 24 其他 24 新增功能 24 修改功能 24 删除功能 25 查询功能 25 权限检查 26 提示功能检查 26 并发功能 27 导出功能 28 导入功能 28 多币别测试 29 打印功能 29 日志检查 29 导航相关检查 30 返回功能检查 30 重置检查 30 PDF测试 30 发送邮件 31 扫描枪 31 安装测试 31 卸载测试 32 更新 33 键盘操作 33 快捷键支持 34 测试驱动程序设计 34 【易用性测试】 35 导航 功能导航 主要功能的导航是否在明显位置 35 菜单 采用“常用--主要--次要--工具--帮助”的位置排列 35 工具栏 相同或相近功能的工具栏放在一起 36 索引 索引的排列顺序要主次有分 36 按钮 按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置 36 快捷键 常用功能要支持快捷键 36 帮助和支持 获取帮助 操作时要提供及时调用系统帮助的功能 36 通用类 系统业务流程需要易于用户理解 37 错误处理 错误规避 37 错误提示 37 一致性 37 与Windows等标准一致 37 内部操作一致 38 反馈信息 38 工作提示 38 功能提示 38 功能性 38 完备性 38 便捷功能 39 控制 可控性 39 视觉清晰 39 布局 39 资源 39 字体 39 颜色 40 语言 文字表达 40 专项测试角度:push测试(推送测试)、交互模式: 40

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值