测试理论：测试用例

目录

测试用例🏴

定义

构成要素

测试用例设计方法🏴

等价类划分法

等价类划分法设计用例步骤

等价类适用场景

编写用例注意事项

边界值分析法🏴

边界范围的确定

边界值分析法设计用例步骤

离点优化

边界值适用场景

判定表法🏴

判定表引入

判定表构成

判定表设计用例步骤

判定表的适用场景

场景法

适用场景🏴

错误推测法

错误推测法介绍

错误推测法适用场景

问题

---

测试用例🏴

---

目的：

• 方便测试验证（将需求大量描述拆分为小的测试点）
• 体现测试人员的思路，测试设计的全面性（后续测试直接可以使用）
• 测试的量化体现，能够反应测试进度

定义

测试用例，也叫 Test Case， 为了特定的 目的 而设计的一组 测试输入 ， 执行条件 和 预期结果 构成的 文档 。

构成要素

规范的测试用例应该包含哪些内容？

注意：实际工作中，如果企业中有自己的用例模板，则用自己公司的即可，核心内容基本一致

测试用例设计方法🏴

---

如何写好测试用例？

等价类划分法

• 等价类定义
  • 在批量的测试数据中，选取具有共同特征的数据子集作为测试的输入
• 等价类的分类
  • 有效等价类：满足需求的测试数据
  • 无效等价类：不满足需求的测试数据

等价类划分法设计用例步骤

案例：如何测试两个两位数整数之和（即-99到99之间数据求和）没有问题？

• 明确需求
  • 测试目的

    eg ： 验证两位数整数是否能够正常求和

  • 测试条件

      eg :

    整数、字母、中文、特殊符号、空格、空

    不超过两位数

    • ​​​​长度
    • 类型（来源于键盘输入）
    • 规则

• 划分等价类
  • 有效等价类：满足需求的所有条件

    eg : -10 , 30

  • 无效等价类：不满足（只要不满其中一个条件即可）需求的所有输入数据

    eg ：包含字母、中文、符号、空格、空

• 提取数据编写用例
  • 通过测试用模板按照要求填写内容

等价类适用场景

• 针对有批量数据输入的测试场景，无法穷举测试时适用
• 常见代表：输入框（下拉框、选择框、下拉列表等）

编写用例注意事项

• 单模块测试中，用例标题具有唯一性
• 必要步骤尽可能清楚
• 预期结果尽量描述测试结论性的语句及现象（如果有具体现象最好描述）
• 用例编号和测试项目简称对应设置

边界值分析法🏴

引入的场景：开发人员常常在边界的位置容易出现问题，此时需要针对边界位置再测试

边界范围的确定

根据需求，将数据类型和边界确定，直接可以获取对应的边界范围值

• 上点：刚好等于边界的值 （取值不考虑开闭区间）
• 离点：刚好小于/大于边界上的值 （取值类型看需求）
• 内点：边界范围内的任何取值 （取中间的值）

边界值分析法设计用例步骤

• 明确需求
  • 测试目的
  • 测试条件
    • 长度
    • 类型
    • 规则
• 划分等价类
  • 有效等价类
  • 无效等价类
• 确认边界范围值

  确定边界范围值之后，结合等价类进行合并补充

  • 上点
  • 离点（可以优化）
  • 内点（可以和有效等价类的取值合并）
• 提取数据编写用例
  • 按照用例模板编写内容即可

离点优化

目的：减少用例数量，由 7 条数据变 5 条数据

注意事项：非必须，可以不用优化

离点优化：离点的选取和上点取值相反的取值点即可

边界值适用场景

对于等价类划分法的完善和补充

• 针对有边界范围的批量数据的输入类测试（重点关注边界）
• 典型代表：输入框（有边界范围区间）

判定表法🏴

判定表引入

• 判定表：是一种以表格形式表达多条件逻辑判断的工具

判定表构成

• 条件桩：列表需求中所有条件，次序无关

  灰色区域

• 动作桩：列出需求中条件可能采取的操作（动作），可能存在多个，次序无所谓

  绿色区域

• 条件项：所有条件对应取值（一般取真假值）的全组合

  黄色区域

• 动作项：上述条件项对用操作结果（通过条件项得到的结果）

  蓝色区域

 

判定表设计用例步骤

• 明确需求
  • 测试目的
  • 测试条件：根据需求列出
• 画出判定表
  • 列出条件桩和动作桩（根据需求来分析提取）
  • 在条件桩前面加判定词，根据条件数量进行组合得到所有取值（条件项）
  • 根据每种条件的组合得到动作项
  • 优化合并相同的条件
• 按照规则编写用例
  • 按照测试用例模板编写即可

判定表的适用场景

• 针对需求中有多个条件，并且条件和条件之间有组合关系，条件和结果之间有制约（因果）关系的场景
• 常见词汇：如果.....那么....；若....则.....
• 局限性：条件个数不易过多（不超过4个）

场景法

也叫流程图法，通过流程图的描述用户的使用场景过程，验证整个产品的业务（用户使用过程）是否正常

• 用户：用户使用更加关注整个系统的应用
• 测试：测试不仅仅要关注单功能测试，还需要关注系统之间组合测试

适用场景🏴

• 一般在测试的后期，对于整个系统的模块功能进行全部的组合测试
• 测试的依据：业务流程图

错误推测法

错误推测法介绍

• 要求：有实际项目测试经验的人使用
• 定义：通过直觉（经验）或者智慧推测系统可能出现问题的地方进行再次测试

错误推测法适用场景

• 1.时间紧迫：通过以往类似项目的经验，提取当前项目中核心模块（出现问题较多）进行验证测试
• 2.时间宽裕：在基础测试的基础上，将原有模块（存在问题较多）进行再次细化测试

问题

上述两种场景是否需要测试用例？

• 场景1：需要提取核心模块（按照用例的优先级）用例进行测试
  • 通过xmind思维导图先整理个大概的测试点
  • 找有相关项目经验的测试人员去测试
  • 通过自动化的技术或者找能够提升测试效率的技术去实现测试
• 场景2：需要将原有用例细化完善后，按照用例依次测试即可