测试用例设计与评审
测试用例设计与评审
简介
前面已经学过了很多种黑盒测试的方法，比如等价类、边界值、因果图、判定表、场景法等等。
那么这么多的测试方法，在设计测试用例的时候，需要进行综合的考虑和选择。
设计方法的选择
- 任何情况下，都需要采用等价类划分法，将无限测试变成有限测试
- 在规定了数据范围的情况下，必须采用边界值分析法
- 如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法
- 如果含有输入条件的组合情况，考虑选用因果图和判定表法
- 采用错误推断法再追加测试用例
测试用例编写步骤
- 划分功能模块：先用思维导图把大功能里的小功能点都拆分出来。
- 正向功能验证：先把这个大功能的正向的操作先走通，其实就相当于是一个简单的冒烟。
- 单个功能项验证：把每一个拆分出来的小的功能点再去单独的验证。
- 功能之间交互验证：验证一些场景的用例。
- 隐形需求：产品特性验证，特殊业务场景验证。
需求分析
- 帐号是手机号
- 手机号仅限制为国内常用的号段
- 密码必须为 数字+英文 的形式，字段为 8-12 个字符
- 账号密码都为空时，登录按钮置灰不可点击
- 点击登录按钮，发起登录请求
- 请求成功，跳转到首页
- 点击忘记密码跳转到找回密码页
测试用例编写
- 划分模块
- 正向功能验证
- 界面展示验证
- 单个功能验证
- 隐性需求
测试用例的粒度
测试用例可以写的很简单，也可以写的很复杂。
最简单的测试用例是测试的纲要，仅仅指出要测试的内容。
测试用例写的过于简单，就可能失去了测试用例的意义。比如有的用例，只把需求中的正向的功能覆盖到了，其他的异常场景都没有考虑，这样的用例是不能起到知道测试的作用的。它保证不了我们产品的健壮性，发现问题的能力也非常的差。
而测试用例写得过于复杂或详细，也会带来问题：一个是效率问题，写用例费时间，执行用例也费时间。另一个是测试用例维护成本的问题，用例条数多了维护起来就更加的复杂。
另外，测试用例设计的过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
所以呢，我们的测试用例设计的粒度第一个要遵守公司的规则，第二个就是要在场景覆盖完整的情况下尽量的精简，这样才能够平衡投入产出比。
测试用例评审
- 测试用例的本身的描述是否清晰，是否存在二义性
- 测试用例内容是否正确，是否与需求目标相一致
- 测试用例的期望结果是否确定、唯一
- 测试用例是否覆盖了所有的需求
- 测试用例是否具有可执行性
- 是否从用户层面来设计用户使用场景和业务流程的测试用例
- 场景测试用例是否覆盖最复杂的业务流程
- 用例设计是否包含了正面、反面的用例
总结
- 测试用例设计
- 测试用例评审