TDD测试用例设计的最佳实践-敏捷开发训练营系列

/ 北极狐

在用TDD方式开发项目,测试用例的设计至关重要，为了更好的践行TDD本文将对测试用例的设计流程做详细解读。

用户故事

在敏捷开发中我们通常以 ==用户故事== 的方式取代庞大的需求文档。用户故事应该站在客户的角度编写，描述他们希望系统提供的服务。用户故事应该使用三段式编写，应该使用业务的语言编写，而不应带有太多技术术语。

作为……，我想要……，以便……

测试用例的设计就是基于用户故事展开的，评判一个用户故事是否完成的标准就是必须由一个或多个自动化的验收测试来验证。

任务提取

测试用例源于用户故事，是黑盒测试。每一个测试用例都需要在用户指定的场景下，设定输入数据，期望系统输出的结果。

当拿到一个用户故事卡片后,需要和用户当面沟通，获取更详细的故事细节。然后将用户故事分解成开发任务。开发任务应该倾向于用开发者的语言来描述任务。将任务以索引卡片的形式记录下来,如果任务涉及多个工种协同开发，还可以进一步划分子任务，这些就是开发迭代的任务。而测试用例就是针对这些任务设计的。

测试用例设计的考虑范围

  • 正向流程
  • 流程环节丢失
  • 边界值
  • 参数排列组合
  • 错误参数的处理
  • 验证数据准确性
  • HTTP或其他协议的状态码
  • 授权检查
  • 并发/多线程问题
  • 幂等性
  • 安全性
  • 性能/响应时间

测试用例的规范术语

测试用例在设计应遵循
  • 简单一次只测一个需求，
  • 符合Given-When-Then格式(一个上下文，指定测试预设，进行一系列操作，即所要执行的操作，得到一系列可观察的后果)
  • 包含断言，可以重复执行。
  • 函数或变量的命名具有可读性
  • 测试数据尽量简单容易理解
public function a_user_can...(){

    $this->assert...
}
public function a_user_can_not...(){

    $this->assert...
}
public function a_user_can...when...(){

    $this->assert...
}
public function a_user_can_not...when...(){

    $this->assert...
}
public function it_should_...()
{
    $this->assert...
}
public function it_should_not...()
{
    $this->assert...
}
$dataToBeUpdated = ['price'=>19];
$dataHasBeenUpdated = ['price'=>20];

$dataToBeDeleted = ['id'=>19];
$dataHasBeenDeleted = ['id'=>19];

$dataToBeAdded = ['title'=>'title_1'];
$existingData = ['title'=>'title_2'];
用例名称：测试用例的概括，简单的描述用例的出发点，关注点，原则上不能重复
前置条件：执行当前测试用例需要的前提条件，是后续步骤的先决条件。
测试数据：这个好理解，利用等价类和边界值对要测试的数据进行编写就行，如登录测试，既要给出正确的账号密码，也要给出错误的账号密码
预期结果：应该出现的结果，使用错误的账号登录，应填写的结果为提示使用正确的账号密码登录
实际结果：实际出现的结果，上例中如果输出的是登录成功，那么填写登录成功，即使使用的错误的账号

测试用例的设计方法

1. 等价类

场景:输入的集合是无穷的,不能全部都覆盖到

等价类:依据需求将输入划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例测试通过,则认为所代表的整个等价类测试通过,这样就可以通过较少的测试用例达到尽量多的功能覆盖,解决了不能穷举测试的问题

  1. 有效等价类:对于程序的规格说明书是合理的,有意义的输入数据构成的集合,利用有效等价类验证程序是否实现了规格说明书中所规定的功能和性能
  2. 无效等价类:根据需求说明书,不满足需求的集合
2. 边界值

边界值:边界值分析法就是对输入或者输出的边界值进行测试的一种黑盒测试方法,通常边界值分析法是作为对等价类划分方法的补充,这种情况下,其测试用例来自等价类的边界

  1. 输入框长度为1-11,边界值取值:0,1,11,12
  2. 运动员参赛项目为1-3项,边界值取值:0项,1项,3项,4项
  3. 查询面页面有999行,每50行为一页,边界值取值:0行,1行,50行,51行,999行
3. 因果图

因果图:因果图是一种简化了的逻辑图,能直观的表明程序输入条件(原因)和输出动作(结果)之间的相互关系,因果图法是借助图形来设计测试用例的一种系统方法,特别适用于被测试程序具有多种输入条件,程序的输出又依赖于输入条件的各种情况

  • 恒等:如果原因为真,那么结果必为真
  • 与:只有当两个原因都为真的时候结果才为真
  • 或:两个原因中有一个为真,那么结果就为真
  • 非:只有原因为假,结果才为真

因果图设计测试用例的步骤:

  1. 分析所有可能的输入和可能的输出
  2. 找出输入与输出之间的关系
  3. 画出因果图
  4. 把因果图转化成判定表
  5. 把判定表对应到每一个测试用例
4. 场景设计法

通过运用场景来对系统的功能点或业务流程的描述，从而提升测试效果。场景法一般分为基本流和备用流，覆盖所有的场景。

5. 错误猜测法

错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法

基于经验和直觉,找出程序中你认为会出现的错误,有针对性地设计测试用例,经验可能来自于对某项业务的测试较多,也可以来自售后用户的反馈意见,或者从故障管理库中整理出bug,整理出产品越往哪些地方越容易出现问题,问题越多的地方,潜在的bug越多

以注册为例

  1. 校验中特殊字符空格的处理?
  2. 密码校验中的大小写？
  3. 姓名中的特殊字符？
  4. 密码发送是否明文

好用例标准：5C原则

  • Clear：清晰的，用例的描述要清晰易懂，不要有歧义

  • Concise：简洁的，用例描述不要太啰嗦

  • Complete：完整的，用例内容是完整的，不能有缺失

  • Consistant：一致的，用例的格式一致

  • Correct：正确的，用例的内容要正确无误