测试用例设计与评审

测试用例设计与评审

1、设计方法的选择

2、测试用例编写步骤

3、需求分析

4、测试用例编写

5、测试用例的粒度

6、测试用例评审

  • 设计方法的选择

任何情况下,都需要采用等价类划分法,将无限测试变成有限测试

在规定了数据范围的情况下,必须采用边界值分析法

如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现,考虑使用场景法

如果含有输入条件的组合情况,考虑选用因果图和判定表法

采用错误推断法再追加测试用例

  • 测试用例编写步骤

划分功能模块

正向功能验证

单个功能项验证

功能之间交互验证

隐性需求

  • 需求分析

帐号是手机号

手机号仅限制为国内常用的号段

密码必须为 数字+英文 的形式,字段为 8-12 个字符

账号密码都为空时,登录按钮置灰不可点击

点击登录按钮,发起登录请求

请求成功,跳转到首页

点击忘记密码跳转到找回密码页

  • 测试用例编写
  • 登录功能

** 正向功能验证

** 界面验证

** 单个功能验证

*** 手机号输入框

**** 长度:等价类结合边界值分析测试数据

**** 类型:等价类分析测试数据

**** 是否必填:等价类分析测试数据

**** 数据约束:是否符合真实手机号的规则

*** 密码输入框

**** 长度:等价类结合边界值分析测试数据

**** 类型:等价类分析测试数据

**** 是否必填:等价类分析测试数据

**** 匹配性:等价类分析测试数据

*** 登录按钮

**** 不同的网络

**** 异常操作

*** 忘记密码按钮

**** 点击忘记密码跳转忘记密码页

left side

** 功能之间交互验证(场景分析)

*** 使用判定表分析手机号与密码填写组合场景是否覆盖完全

**** 手机号与密码都为空

*** 从登录业务逻辑角度,使用场景法补充场景

**** 手机号未注册

** 隐性需求

*** 密码密文展示

*** 账号互踢

*** 登录有效时间

*** 退出登录

*** 不同设备登录数据是否同步

@endmindmap

  • 测试用例的粒度

测试用例可以写的很简单,也可以写的很复杂

最简单的测试用例是测试的纲要,仅仅指出要测试的内容

测试用例写的过于简单,则可能失去了测试用例的意义

测试用例写得过于复杂或详细,会带来两个问题:

效率问题

维护成本问题

  • 测试用例评审

测试用例的本身的描述是否清晰,是否存在二义性

测试用例内容是否正确,是否与需求目标相一致

测试用例的期望结果是否确定、唯一

测试用例是否覆盖了所有的需求

测试用例是否具有可执行性

是否从用户层面来设计用户使用场景和业务流程的测试用例

场景测试用例是否覆盖最复杂的业务流程

用例设计是否包含了正面、反面的用例