软件测试梳理 第七节 软件测试用例和设计方法（二）

测试用例和设计方法（二 ）

因果图法

• 什么是因果图

  • 因果图法

    • 因果图法是一种适用于描述对于多种输入条件组合的测试方法

    • 根据输入条件的组合、约束关系和输入条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法

    • 它适用于检查程序输入条件涉及的各种组合情况

    • 第一步：根据功能说明书中规定的原因和结果之间的关系画出因果图
      

    • 第二步：根据功能说明在因果图中加上约束条件

      

      • 其中互斥、包含、唯一、要求是对原因的约束，屏蔽是对结果的约束。含义如下
      • 互斥（exclusive）：表示不同时为1，即a，b，c中至多有一个1。解释：假如原因成立用1表示，不成立用0表示，也就是A+B+C≤1。
      • 包含（include）：表示至少有一个1，即a，b，c中不同时为0。解释：3≥A+B+C≥1。
      • 唯一（only）：表示a，b，c中有且仅有一个1。解释：A+B+C==1。
      • 要求（request）：表示若是a=1，则b必须为1。即不可能a=1且b=0。解释：原因A成立，要求B一定先成立。
      • 屏蔽（mask）：表示若a=1，则b必须为0。

• 因果图使用实例

  • 阅读和分析功能说明书，识别出“原因”和“结果”，并加以编号

  • 案例：有一个饮料自动售货机（处理单价为5角钱）的控制处理软件，它的软件规格说明如下：

    • 若投入5角钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就送出来。
    • 若投入1元钱的硬币，同样也是按“橙汁”或“啤酒”的按钮，则自动售货机在送出相应的饮料，同时退回5角钱的硬币。

  • 因果图实例分析（需求分析阶段）

    因果约束

    

  • 因果图使用的局限性：原因和结果很多的时候，他们关系连线会很多，导致可读性变差。因此用作局部小功能。

  • 列出所有的原因和结果的列表，设计初步的测试用例步骤：

    		C1	C2	C3	C4	C5
    投币	五角	1	1
    	一元			1	1
    按钮	橙汁	1				1
    	啤酒		1
    结果	出橙汁	1		1		1
    	出啤酒		1		1
    	找零五角			1	1

    C5：这是一种bug，不能做设计。

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

    经过分析发现：

    1.只选择饮料，没有投币的时候，软件没有任何结果

    2.只投币，没有选择饮料的时候，软件也没有任何结果

    3.我们不能把软件的bug，设计成测试用例。

    测试用例编号	测试项	依赖用例	测试步骤	输入数据	预期结果	测试结果	测试人	备注
    Test_Case_ZZSHJ_XS_0001	购买果汁		1、投币五角 2、选橙汁		出橙汁

判定表法

• 什么是判定表法

  • 判定表驱动法：

    • 是分析和表达多逻辑条件下执行不同操作的情况下的工具。它由以下几个内容组成：

      • 条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
      • 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
      • 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
      • 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

    • 应用场合：主要适用于多条件的内容组合与结果分析

    • 使用条件：所有的条件桩在表中的位置和顺序互不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同。

    • 建立判定表的步骤

      • 第一步：识别出操作条件（原因），和对应的动作（结果）

      • 第二步：分析条件的条件项（组合数量）：如果有n个条件，每个条件有成立和不成立两种情况，那么最后一次会有2^n个数量

      • 第三步：简化优化结果。排除一些不可能存在的情况

• 判定表使用实例

  • 需求：订购单的检查

    • 如果金额超过500元，有未过期，则发出批准单和提货单
    • 如果金额超过500元，但过期了，则不发批准单
    • 如果金额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单

  • 分析条件和动作

    条件1	条件2	动作
    金额>500	未过期	发出批准单和提货单
    金额>500	过期	不发批准单，提货单
    金额≤500	未过期	发出批准单和提货单
    金额≤500	过期	发出批准单、提货单、通知单

  • 写入条件桩、动作桩、条件项、动作项

    

  • 对判定表进行简化和优化。（对其中不合理或者重复的进行取舍）

    不管金额的高低，只要未过期，就会发送批准单和提货单。（在测试时间不充足的情况下，可以选择二者中的一个情况进行测试）

    

  • 讲判定表中的每一列（条件项和对应的动作项）作为测试用例的数据和操作以及对应的预期结果

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

  • 规格说明以判定表的形式给出，或者很容易转换成判定表
  • 条件的排列顺序不影响执行哪些操作
  • 动作的排列顺序不影响执行哪些操作
  • 当某一规则的条件已经满足，并且确定要执行的操作后，不必检验别的规则
  • 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要

• 测试用例的设计方法：没有哪一种方式是单独使用的。

  • 所有软件都是因为某种操作才会导致一定的结果。——考虑使用因果图
  • 所有软件都有文本框。——考虑使用等价类、边界值。

• 判定表面试题

  该判定表为一个杂志的阅读指南判定，指导读者能够两性阅读。

  

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

  1、合并1、2、3、4为一项。在疲倦的情况下，一律休息即可。

  2、合并7、8为一项。在都不疲倦的情况下，不感兴趣就跳下一章。

  

场景法

• 场景法基本原理

  

  重点：

  基本流（软件功能正确实现的流程）

  备选流（基本功能流程之外的过程）

  注意：

  1、场景必须有基本流

  2、场景中必须有内容从用力的开始，到用例的结束

• 场景法设计实例

  

  • 程序的基本流和备选流整理整理：

    

    基本流：即正常情况下的场景，本题应该为插卡，输入正确密码，成功取款并打印凭条，取卡。
    备选流：则是一些非正常情况下的情景，如密码不正确，卡无效等。
    简单来说，基本流可以达到目的，备选流达不到最终目的。

    

  • 根据基本流和备选流生成场景

  

  • 生成测试用例对应场景