首页 > 编程知识 正文

通过画因果图来写测试用例的步骤为,软件测试的方法 图解

时间:2023-05-04 17:55:52 阅读:60635 作者:1064

因果图法是因果图法,是适合于描述多个输入条件组合的测试方法

一种基于输入条件组合、约束关系、输出条件因果关系分析输入条件各种组合情况设计测试用例的方法

适用于检查程序输入条件设计的各种组合

步骤:

步骤1 :根据需求说明书规定的原因与结果的关系绘制结果图

恒等、非、和(原因与结果的关系) ) ) )。

(恒等)原因a成立,结果b一定成立

非:原因a成立时,结果b一定不成立

或者,只要原因a、b、c中一个成立,结果b就一定成立

与:原因a、b、c成立时,出现结果d

步骤2 :根据功能说明对因果图施加约束

其中有互斥、包含、唯一对请求时原因的制约,屏蔽是对结果的制约,他们的含义如下。

(原因之间的约束)

独占e(eclusive )表示不同时为“真”。 也就是说,a、b、c中至多只有一个“真”。

包括I(include ) :表示至少一个"真",即a、b、c中不同时为0;

唯一的o(only )表示a、b、c中有“真”,只有一个。

请求r (请求)表示a=1,b必须为1。 即,不是a=1且b=0

(结果之间的约束)

出现掩模m(mask )结果彼此相互屏蔽的现象,出现a结果,不出现b结果的现象。

如果qfdxd收到注册成功的消息,则一定不会收到数据填写失败的消息。

限制事项:

原因和结果多的情况下,他们之间的关系联系多,因果图的可读性差,用于局部小功能的分析(原因和结果不多的情况)。

给出所有原因和结果的列表,设计初步的测试用例步骤。

因果图符号因果图采用实例判断表法判断表驱动法:是分析和表达多逻辑条件下不同操作情况的工具。 她由以下内容构成。

条件桩:列出了问题的所有条件。 通常,列举条件的顺序被认为不重要。

动作桩:列举了问题规定可以采取的操作。 这些操作的排列顺序没有限制。

条件项:列出左列中条件的可能值。 所有可能情况下的真伪值。

措施项:列出为条件项指定不同值时应采取的措施。

应用场合:主要应用于多条件内容组合和结果分析;

使用判定表设计测试用例的合适条件:

规格说明以判定表的形式给出,或容易转换为判定表;

条件排列顺序不影响执行哪个操作;

规则的排列顺序不影响要执行的操作

一旦满足了一个规则的条件并确定了要执行的操作,就不需要检查其他规范

如果规则执行多个操作,则这些操作的执行顺序无关

组成:由条件项、动作项、条件桩、动作桩四部分组成

使用条件:所有条件桩在表中的位置和顺序互不影响。 所有动作桩内顺序不因条件顺序的变化而异;

实现步骤: 1、首先识别条件(原因)和对应动作)结果);

2、分析条件组合数; 如果有n个条件,各个条件可能成立,也可能不成立,最后会得出2的n次幂个结果;

3、简化结果优化,排除可能出现的动作。

说明:测试用例的设计方法无法单独使用;

所有软件都会因某种操作而导致一定的结果; ---考虑使用因果图

所有软件都有文本框。 ---考虑使用等价类、边界值

场景法场景法的基本原理:

p>现在的软件几乎都是用事件触发来控制流程的。测试时。可以生动地描述出事件触发时的场景,有利于设计测试用例。同事使测试用例更容易理解和执行。

基本流:软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流,且基本流仅有一个起点和一个终点

备选流:出了基本流之外的各支流,包含多种不同的情况。

场景列表

场景1:基本流

场景2:基本流 备选流1

场景3:基本流 备选流1 备选流2

场景4:基本流 备选流3

场景法设计实例

步骤:

根据说明,描述出程序的基本流以及各项备选流

根据基本流和各项备选流生出不同的场景

对每个场景生成不同的测试用例

多所有生成的测试用例进行诚信复审,去掉多余的测试用例

测试用例确定后,对每个测试用例确定测试数据

适用场合:

场景法适应于解决业务流程清晰的系统或者功能

因果图案例分析:

自助售货机卖啤酒和橙子,处理单价5角,投入5角硬币,摁下饮料,会出饮料;投一元,摁下按钮,出饮料然后找零。

先分析原因和结果

 

 

Case1

Case2

Case3

Case4

 

 

投币

5角

1

1

 

 

 

 

1元

 

 

1

1

 

 

选饮料

橙汁

1

 

1

 

 

 

可乐

 

1

 

1

 

 

 

 

 

 

 

 

 

 

结果

出橙汁

1

 

1

 

 

 

出啤酒

 

1

 

1

 

 

找零5角

 

 

1

1

 

 

因果图中,不能存在因果性的bug。因果图的优势在于能够发现设计中的不足。

经过分析发现:

1、只选择饮料,没有投币的时候,软件没有结果;

2、只投币,没有选择饮料时,软件也没有任何结果;

3、我们不能把软件的缺陷设计成测试用例;

需求:订购单的检查

如果金额超过500元,又未过期,则发出批准单和提货单;

如果金额超过500元,但过期了,则不发批准单;

如果金额低于500元,则不论是否过期都发出批准单和提货单,在过期情况下还需要发出通知单;

条件1

条件2

动作

金额>500

未过期

发出批准单和提货单

金额>500

过期

不发批准单,发提货单

金额≤500

未过期

发出批准单和提货单

金额≤500

过期

发出批准单、提货单和通知单

判定表的面试题

该判定表为一个杂志的阅读指南判定,知道读者能够良性阅读

读完表格后,请对表格内容进行优化。将重复的内容去掉。并且说明原因

1)合并1、2、3、4位一项。在不疲倦的情况下,一律休息即可;

2)合并7、8位一项,在不疲倦,不感兴趣的情况下,就跳下一章;

场景法分析案例说明:

重点:要有基本流,软件功能正确实现的流程;

备选流:软件基本功能流程之外的分支

注意:

一个场景中,必须有基本流

场景中,必须有内容从用例的开始到用例的结束

 

案例:ATM机的取款流程

基本流:插卡--输入密码--选择金额--出钞--取卡

备选流:

1.卡片不是银行卡

2.卡片不是对应银行的卡

3.密码输错1次

4.密码输错2次,第三次正确

5.密码输入错误3次,冻结账号或者吞卡

6.选择存款服务

7.选择查询服务

8.选择转账服务

9.选择修改密码服务

10.选择取款金额

11.选择其他金额

12.账户金额不足

13.ATM机没钱

14.账户取款金额达到取款机当日上线

15.账户取款金额达到个人账户取款上线

16.取款机掉线了

17.取款机停电了

18........

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。