问题衍生:测试组同事工作中发现,测试用例总是写不全面.在测试中功能与需求不一致,功能分支未考虑到.如何全面设计测试用例?
分析问题:是什么造成了用例不全面
需求变更
对需求理解偏差
需求不清晰
对功能,业务不了解
测试设计理论缺少
'好的'测试用例具备的特性
1. 整体完备性：“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
2. 等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
3. 等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。
是不是有点概念性了.那我们从另一方面在来拆分一下
1.第一层，表单测试为最底层（最基础的）.通过页面从上到下,从左到右,对输入框,按钮功能,的最基本测试.这时候考虑的就是特殊字符,超长,空;不提交退出,提交取消,按钮释放.这层测试对新项目,新功能很重要,必须执行.当项目进入维护阶段,这些case的优先级就置为低.时间不充裕就可以不去执行了.
2.第二层，逻辑判断层。根据需求的设计，各功能之间的简单逻辑联系。以登录,账号和密码必须对应才能登录，否则登录失败,那我们从这个逻辑判断来设计case:账号为空;密码为空;账号密码不一致;账号密码一致,这里其实就是等价类了.那这类case的话,也是最常规部分,有相关联功能修改了,就需要执行.
3.第三层，业务流程层. 这部分不关心软件的本身的基本功能，而是关心这个软件的业务有没有实现，不同的需求就有不同的业务需求. 还是登录,需求为,停用的账户,不能登录系统.那这层的case就可以设计为:停用账号是否能登录?超级管理员是否能停用?停用后是否可以启用?删除后是否能登录? 这里的需求可能就会是一句话,那这些用例就需要我们在需求评审的时候就去发散思考.
这3层组合起来才能逐步形成完整的测试用例,这里还有没列举到的 比如 数据库的数据校验,接口传输数据校验.
那我们听完了这些理论,试试看用到实战当中吧
实战
1.城市电话号码由三部分组成。它们的名称和内容分别是：地区码：空白或三位数字；前缀：首位非‘0’或‘1’的三位数字；后缀：4位数字。
假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的电话号码。根据该程序的规格说明，作等价类的划分，并设计测试方案。能有几条测试用例?
A:5 B:13 C:8 D:15
2.、交通一卡通自动充值软件系统需求系统只接收50元或100元纸币，一次充值只能使用一张纸币，一次充值金额只能为50元或100元。用因果图的设计方式,能有几条测试用例
A:4 B:5 C:6 D:7
答案:
1.B:13
分析 有效等价类 ,无效等价类
2.C:6
