测试用例设计与评审
1、设计方法的选择
2、测试用例编写步骤
3、需求分析
4、测试用例编写
5、测试用例的粒度
6、测试用例评审
- 设计方法的选择
任何情况下，都需要采用等价类划分法，将无限测试变成有限测试
在规定了数据范围的情况下，必须采用边界值分析法
如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法
如果含有输入条件的组合情况，考虑选用因果图和判定表法
采用错误推断法再追加测试用例
- 测试用例编写步骤
划分功能模块
正向功能验证
单个功能项验证
功能之间交互验证
隐性需求
- 需求分析
帐号是手机号
手机号仅限制为国内常用的号段
密码必须为 数字+英文 的形式，字段为 8-12 个字符
账号密码都为空时，登录按钮置灰不可点击
点击登录按钮，发起登录请求
请求成功，跳转到首页
点击忘记密码跳转到找回密码页
- 测试用例编写
- 登录功能
** 正向功能验证
** 界面验证
** 单个功能验证
*** 手机号输入框
**** 长度：等价类结合边界值分析测试数据
**** 类型：等价类分析测试数据
**** 是否必填：等价类分析测试数据
**** 数据约束：是否符合真实手机号的规则
*** 密码输入框
**** 长度：等价类结合边界值分析测试数据
**** 类型：等价类分析测试数据
**** 是否必填：等价类分析测试数据
**** 匹配性：等价类分析测试数据
*** 登录按钮
**** 不同的网络
**** 异常操作
*** 忘记密码按钮
**** 点击忘记密码跳转忘记密码页
left side
** 功能之间交互验证（场景分析）
*** 使用判定表分析手机号与密码填写组合场景是否覆盖完全
**** 手机号与密码都为空
*** 从登录业务逻辑角度，使用场景法补充场景
**** 手机号未注册
** 隐性需求
*** 密码密文展示
*** 账号互踢
*** 登录有效时间
*** 退出登录
*** 不同设备登录数据是否同步
@endmindmap
- 测试用例的粒度
测试用例可以写的很简单，也可以写的很复杂
最简单的测试用例是测试的纲要，仅仅指出要测试的内容
测试用例写的过于简单，则可能失去了测试用例的意义
测试用例写得过于复杂或详细，会带来两个问题：
效率问题
维护成本问题
- 测试用例评审
测试用例的本身的描述是否清晰，是否存在二义性
测试用例内容是否正确，是否与需求目标相一致
测试用例的期望结果是否确定、唯一
测试用例是否覆盖了所有的需求
测试用例是否具有可执行性
是否从用户层面来设计用户使用场景和业务流程的测试用例
场景测试用例是否覆盖最复杂的业务流程
用例设计是否包含了正面、反面的用例