目录
测试用例:
测试工作
测试用例的基本构成
也称为功能测试或数据驱动测试。通过软件的外部表现来发现其缺陷和错误。在测试时,把被测程序视为一个不能打开的盒子,在完全不考虑程序内部逻辑结构和内部特性的情况下进行。它是在已知产品所应具有的功能前提下,通过测试来检测每个功能是否都能正常使用,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能够适当地接收输入数据而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。
第一步:分析需求
第二步:划分等价类【找到有效/无效的数据】
案例:找6-10位长度自然数
第三步:结合等价类设计测试用例
有几条等价类,就根据等价类设测试用例。
在日常的测试工作,经常发现,在数据的 临界值位置 是经常出现 bug 的,因此这种位置就应该作为我们重点的测试对象。
边界值:
边界值的三个概念:
确认输入、输出的边界,然后取刚好等于、大于、小于边界的参数作为测试用例测试。 等价类划分法属于确认有效区间,边界值分析法属于确认边界,它们两个的联系就是等价类划分和边界值要一起考虑,边界值分析法属于等价类划分法的补充,任何等价区间都有边界,有边界就有等价区间。
考虑输入与输出变量取值之间的关系,比较复杂,需要更多的规则 在一些数据处理问题中,某些操作是否实施依赖于多个逻辑条件的取值,在这些逻辑条件取值的组合构成的多种情况下,分别执行不同的操作。处理这类问题的一个非常有力的分析和表达工具是判定表(决策表)。决策表能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用决策表能够设计出完整的测试用例集合。在所有的功能测试方法中,基于决策表的测试方法是最严格的决策表通常由四个部分组成。
桩 | 规则 |
---|---|
条件桩 | 条件项 |
动作桩 | 动作项 |
条件桩(Condition Stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要 动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束 条件项(Condition Entry):列出了针对它左列条件的取值。在所有可能的情况下,给出真假值。 动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作
设计测试用例的步骤
等价类划分和边界值分析方法都只是孤立地考虑各个输入数据的测试功能,而没有考虑多个输入条件的各种组合和输入条件之间的相互制约关系引起的错误。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来设计测试用例,这就需要利用因果图(逻辑模型),因果图方法最终生成的就是判定表,它适合于检查程序输入条件的各种组合情况
因果图常用符号:
符号 | |
---|---|
~ | 相当于 NOT ,也就是逻辑非,表示当条件成立的时候,结果不成立 ; 当条件不成立的时候,结果成立 |
– | 恒等,表示当条件成立的时候,结果成立 ; 当条件不成立的时候,结果不成立 |
v | 相当于 OR ,也就是逻辑或,表示当多个条件中,有至少一个条件成立的时候,结果成立 ; 当全部条件都不成立的时候,结果不成立 |
^ | 相当于 AND ,也就是逻辑与,表示多个条必须都成立,结果成立 ; 当有任意一个条件不成立的时候,结果不成立 |
因果图法基本步骤:
能够使用最小的测试过程集合获得最大的测试覆盖率,从全面试验中挑选出有代表性的点进行测试。 适用于配置类软件,组合比较多的情况。
概念:
因素【k 】:表示的是输入的条件,每列是一个因素
水平【 m 】:表示的是输入的条件所得到的结果,表格中的每个小格是一个结果
特点:均匀分散、整齐可比、高效、快速、经济
L4(23):3因素2水平
列号 | 1 | 2 | 3 |
---|---|---|---|
试验号 | |||
1 | 1 | 1 | 1 |
2 | 1 | 2 | 2 |
3 | 2 | 1 | 2 |
4 | 2 | 2 | 1 |
L8(27):7因素2水平
列号 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
---|---|---|---|---|---|---|---|
试验号 | |||||||
1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
2 | 1 | 1 | 1 | 2 | 2 | 2 | 2 |
3 | 1 | 2 | 2 | 1 | 1 | 2 | 2 |
4 | 1 | 2 | 2 | 2 | 2 | 1 | 1 |
5 | 2 | 1 | 2 | 1 | 2 | 1 | 2 |
6 | 2 | 1 | 2 | 2 | 1 | 2 | 1 |
7 | 2 | 2 | 1 | 1 | 2 | 2 | 1 |
8 | 2 | 2 | 1 | 2 | 1 | 1 | 2 |
其它的如果需要可以自行下载word文档。
链接:https://pan.baidu.com/s/1u8Nre8ot35xdl6IH-VkvAg 提取码:aulf
现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计用例场景用来描述流经用例的路径,从用例开始到结束遍历这条路径上所有基本流和备选流。
流程图中的符号
案例:电商平台购物流程
流程图:
流程图中的一条线就是一个测试用例
在软件测试活动中,人们可以依靠经验和直觉推测系统中可能存在的各种错误,从而有针对性地编写检查这些错误的例子,这就是错误推测法。
基本思想:根据以往的测试经验和对系统内部知识的了解,列出系统中各种可能有的错误和容易发生错误的特殊情况,再根据它们来设计测试用例,
随着在产品测试的实践中对产品的了解的加深和测试经验的丰富,使用错误推测法设计的测试用例往往非常有效,
可以作为测试设计的一种补充手段,并且积累的经验越丰富,方法使用效率越高。
使用场景:
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/184030.html原文链接:https://javaforall.cn