1. 功能测试用例

1.1 设计用例容易出现的问题

1. 基础功能点用例覆盖不全/描述不清

• 描述不清
  什么是正常内容，仅看用例能否知道该输入什么？
  什么时候可以这么写，非主要测试点，但是必须要填完才能完成这个动作。如测模型仓库的名称，其他字段可写成按要求填写，然后点击确定…

• 反向用例，每条用例只能违反一条规则，否则会出现校验不到的情况
  需要写清楚字符数量，特别是对于下限不为0的情况。

• 将 UE 稿内容简单复制，没有加对业务的理解
  例：选择图像分类标注集，选择模型仓库，模型下拉框仅展示仓库中图像分类的模型

2. 预期校验不到位

• 校验不全，预期结果里不能用等

• 校验不到位，需要校验列表/页面中是否生效，需要粘贴看是否和复制的内容一致，不能仅看 toast 提示

3. 用例拆分粒度不合理

• 像是一条用例里的一个步骤，而不是一个完整的用例

4. 复杂场景/关联场景/异常情况考虑不到，仅停留在交互层面

• 校验都只停留在表面，添加、编辑、删除之后的影响没有考虑到
  如创建模型高级参数的校验，参数是否生效
  如删除标注图片后进度的展示
  如标注集页面和数据标注页面均能创建数据集，两边限制是否一致
• 复杂场景覆盖不全，不能找到所有情况
  如标签 ID 或名称重复的分情况校验（模型标签不存在标注集标签中；模型标签与标注集标签完全一致；模型标签与标注集标签 ID 相同名称不同；模型标签与标注集标签名称相同，ID 不同；既有相同名称又有相同 ID，但是不能完全对应）
• 缺少对异常情况的校验
  如搜索% _ 数据库通配符
  如删除最后一页的数据
  如同时提交数据相同的数据表单等
  如正在运行的模型，所属的模型仓库是否可以被删除

5. case分级、自测标记
   缺少标准，标的比较随意，不能起到应有的作用

2. 如何写用例

2.1 什么是好的用例

• 来源需求、覆盖需求
• 步骤、预期结果清楚
• 易于维护、复用
• 能够发现尽可能多的 bug, 能够发现之前没发现的 bug

2.2 测试用例设计常见方法

1. 等价类划分(掌握)

• 规定了输入值的范围，可以划分为一个有效等价类（在指定范围内）和两个无效等价类（分别小于和大于指定范围）。
• 规定了输入数据个数，类似地也可以划分一个有效等价类和两个无效等价类
• 规定了输入数据的一组值，程序对不同输入值做不同处理，则每个值为一个有效等价类，还有一个无效等价类（不属于这组值里的任意值）
• 规定了输入数据必须遵守的原则，则可以划分一个有效等价类和若干无效等价类（从不同角度违反规则）
• 如果规定定输入数据为整数，则可以划分负整数、正整数、0 三个有效等价类

2. 边界值分析(掌握）

• 刚好等于
• 刚好小于
• 刚好大于

不仅要考虑输入的边界值，还要考虑输出的边界值

3. 场景法(掌握)
   

场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程。
测试不能只关注某个控件的边界值、等价类是否满足要求，也要关注它的主要功能和业务流程是否正确实现，这时就需要使用场景法来完成。

场景法用例设计步骤

• 设计场景用例首先需要根据需求规格说明得出功能模块流程图，描述出程序的基本流及备选流，
  • 基本流：按照正确的业务流程来实现的一条操作路径即模拟正确的操作流程。
  • 备选流：导致程序出现错误的操作流程即模拟错误的操作流程。
• 其次根据基本流和备选流生成不同的场景，构造场景列表，
• 最后对每一个场景生成相应的测试用例，对所有的测试用例重新复审，去掉多余的测试用例。
• 确定测试用例之后，为每一个测试用例确定测试的数据值即可完成场景用例的设计。

4. 错误推测(掌握）
   直觉、经验 发现 组合错误、逻辑错误

• 忘记需求、忘记 UE、不要有任何参考（包括界面的一些提示性文字），随便输入，不要担心产品崩溃等
• 根据之前测试出问题的一些经验，去输入

5. 判定表、判定树
   复杂的条件组合与应做动作之间的关系
   左上部列出所有条件，左下部是所有可能的动作
   右上部是条件组合矩阵，右下部是每种条件组合相对应的动作
   

6. 因果图
   https://blog.csdn.net/tingxuan_qhm/article/details/22512209

7. 正交设计
   https://zhuanlan.zhihu.com/p/157883678

8. 功能图法

https://blog.csdn.net/catch_dreamer/article/details/109283792

不同方法的适用场景

• 等价类划分、边界值分析，用得最多，特别适合写输入框的测试用例
• 场景法、功能图法适合流程、逻辑
• 判定表、判定树、因果图，正交适合条件组合的情况

3. 用例分级

参考 bug 分级标准

• P0 级 bug：系统崩溃，功能主流程不通，block 测试的 bug，明显的性能问题，有钱的损失等；
• P1 级 bug：功能主流程上的 bug、严重体验问题； 主流程上的严重 UI 问题，高概率偶现问题，常见异常问题（如常规参数异常）。
• P2 级 bug：非主流程上的 bug，异常问题，兼容性 UI 问题，个别机型问题
• P3 级 bug ：不影响使用的瑕疵、更好的实现方式。