测试步骤选择
因果图法
适合检查程序多种输入条件组合的测试方法(输入条件组合、约束关系(同意条款)、输出条件、输入条件)
原因和结果的关系:
恒等,原因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;……
设计测试用例步骤
根据基本流和各项备选流(测试目的)生成不同场景
每一个场景,都是一个测试用例。其他因素使用假设