5.2黑盒测试用例方法

测试步骤选择

因果图法

 适合检查程序多种输入条件组合的测试方法(输入条件组合、约束关系(同意条款)、输出条件、输入条件)

 原因和结果的关系：

  恒等，原因A成立，结果B一定成立
  非，原因A出现，结果B一定不成立
  或，原因A、B、C三者只要有一个成立，结果D一定成立
  与，原因A、B、C都成立，结果D才会出现

 因果图中的约束

 原因之间的约束
  原因成立1，不成立0
  互斥、包含、唯一、要求是对原因的约束；屏蔽是对结果的约束
  互斥(eclusive)，a,b,c中至多只有一个1;a+b+c<=1
  包含(include)，a,b,c中至多只少一个1;3>=a+b+c>=1
  唯一(only)，a,b,c有且只有一个;a+b+c=1
  要求(request)，若a=1,必须b=1。a成立，要求b一定先成立(手机号a和验证码b)
 结果之间的约束
  屏蔽(mask)。结果之间A结果出现，B结果一定不出现(注册成功/错误提示二选一)
 案例
  自助售卖机卖啤酒和橙汁，单价5角，投5角，出饮料；投一元，出饮料，找5角

     按照需求描述原因、结果间的约束(部分关系)
 因果图使用的局限性，当原因和结果很多的时候，它们之间的关系练练就会很多，导致因果图的可读性变差。因此用作局部的小功能(原因和结果不是很多的时候)分析
 列出所有的原因和结果的列表，设计初步的测试用例

 优势在于能够发现设计中的不足。
 经分析发现：只选择饮料，没有投币的时候，软件没有任何结果；只投币，没有选择饮料，软件也没有任何结果；我们不能把软件缺陷，设计成测试用例。

判定表法

 主要适用于多条件组合与结果分析
 所有的条件桩在表中的位置和顺序互不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同
 判定表驱动法：多逻辑条件下执行不同操作的情况
  条件桩，列出问题所有条件(需求)
  动作桩，列出问题规定可能采取的操作
  条件项，条件分析，结果成立或不成立
  动作项，条件项各种取值下应该采取的动作
 实现步骤
  1.识别出条件(原因)和对应动作(结果)
  2.分析条件项(组合数量)，一个条件成立或不成立两种情况。则有2^n结果
  3.简化和优化结果，排除不可能情况.(对其不合理或者重复的进行取舍)
 适合判定表测试用例的条件
  规格说明以判定表给出，或可轻易转化为判定表
  条件/规则执行不影响执行哪些操作
  某一规则的条件已经满足、确定执行的操作后、不必要检验别的规则
  某个规则执行多个操作，动作顺序不影响
 案例，局部业务测试

 不管金额的高低，只要未过期，就会发送批准单和提货单(测试时间不充足时，可选二者中的一个进行测试)所以优化之后条件项减少为3个

 将判定表中的每一列(条件项和对应的动作项)作为测试用例的数据和操作以及对应的预期结果。

测试用例设计

 没有哪一种方法是单独使用的
  所有软件，某种操作导致一定结果。——考虑使用因果图
  所有软件都有文本框——考虑必须使用等价类、边界值

场景法

 适用于解决业务流程清晰的系统或功能

 基本原理

  模拟(丰富)事件触发场景，有利于设计测试用例，更容易理解和执行
  基本流：软件能正确实现的流程。一个业务一个基本流，基本流仅有一个起点和一个终点。
  备选流：除基本流之外的各支流，包含很多不同情况

 注意事项

  场景中必须有基本流
  场景中必须有内容，从用例开始，到用例结束

案例：ATM机取款

  基本流：插卡—输入密码—选择服务—选择取款金额—等待出钞—退卡
  备选流：1）卡片不是银行卡/银联卡；2）密码输错两次，三次正确；3）密码三次错误，卡冻结；4）存款、查询、转账、修改密码服务；5）取款金额；6）其他金额；7）账户金额不足；8）ATM没钱；9）取款上限(取款机当日上限\账户取款交易上限);10）取款机掉线；
 场景设计：场景1：基本流；场景2：基本流、备选流1；场景3：基本流、备选流5；……
 设计测试用例步骤
  根据基本流和各项备选流(测试目的)生成不同场景
  每一个场景，都是一个测试用例。其他因素使用假设