08.测试用例设计与评审

• 任何情况下，都需要采用等价类划分法，将无限测试变成有限测试
• 在规定了数据范围的情况下，必须采用边界值分析法
• 如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法
• 如果含有输入条件的组合情况，考虑选用因果图和判定表法
• 采用错误推断法再追加测试用例

1. 划分功能模块
2. 正向功能验证
3. 单个功能项验证
4. 功能之间交互验证
5. 隐形需求

• 帐号是手机号
• 手机号仅限制为国内常用的号段
• 密码必须为 数字+英文 的形式，字段为 8-12 个字符
• 账号密码都为空时，登录按钮置灰不可点击
• 点击登录按钮，发起登录请求
• 请求成功，跳转到首页
• 点击忘记密码跳转到找回密码页

@startmindmap
* 登录功能
** 正向功能验证
** 界面验证
** 单个功能验证
*** 手机号输入框
**** 长度：等价类结合边界值分析测试数据
**** 类型：等价类分析测试数据
**** 是否必填：等价类分析测试数据
**** 数据约束：是否符合真实手机号的规则
*** 密码输入框
**** 长度：等价类结合边界值分析测试数据
**** 类型：等价类分析测试数据
**** 是否必填：等价类分析测试数据
**** 匹配性：等价类分析测试数据
*** 登录按钮
**** 不同的网络
**** 异常操作
*** 忘记密码按钮
**** 点击忘记密码跳转忘记密码页

left side

** 功能之间交互验证（场景分析）
*** 使用判定表分析手机号与密码填写组合场景是否覆盖完全
**** 手机号与密码都为空
*** 从登录业务逻辑角度，使用场景法补充场景
**** 手机号未注册
** 隐性需求
*** 密码密文展示
*** 账号互踢
*** 登录有效时间
*** 退出登录
*** 不同设备登录数据是否同步
@endmindmap

• 测试用例可以写的很简单，也可以写的很复杂
• 最简单的测试用例是测试的纲要，仅仅指出要测试的内容
• 测试用例写的过于简单，则可能失去了测试用例的意义
• 测试用例写得过于复杂或详细，会带来两个问题：
  • 效率问题
  • 维护成本问题

• 测试用例的本身的描述是否清晰，是否存在二义性
• 测试用例内容是否正确，是否与需求目标相一致
• 测试用例的期望结果是否确定、唯一
• 测试用例是否覆盖了所有的需求
• 测试用例是否具有可执行性
• 是否从用户层面来设计用户使用场景和业务流程的测试用例
• 场景测试用例是否覆盖最复杂的业务流程
• 用例设计是否包含了正面、反面的用例