1. 功能测试用例
1.1 设计用例容易出现的问题
- 基础功能点用例覆盖不全/描述不清
-
描述不清
什么是正常内容，仅看用例能否知道该输入什么？
什么时候可以这么写，非主要测试点，但是必须要填完才能完成这个动作。如测模型仓库的名称，其他字段可写成按要求填写，然后点击确定… -
反向用例，每条用例只能违反一条规则，否则会出现校验不到的情况
需要写清楚字符数量，特别是对于下限不为0的情况。 -
将 UE 稿内容简单复制，没有加对业务的理解
例：选择图像分类标注集，选择模型仓库，模型下拉框仅展示仓库中图像分类的模型
- 预期校验不到位
-
校验不全，预期结果里不能用等
-
校验不到位，需要校验列表/页面中是否生效，需要粘贴看是否和复制的内容一致，不能仅看 toast 提示
- 用例拆分粒度不合理
- 像是一条用例里的一个步骤，而不是一个完整的用例
- 复杂场景/关联场景/异常情况考虑不到，仅停留在交互层面
- 校验都只停留在表面，添加、编辑、删除之后的影响没有考虑到
如创建模型高级参数的校验，参数是否生效
如删除标注图片后进度的展示
如标注集页面和数据标注页面均能创建数据集，两边限制是否一致 - 复杂场景覆盖不全，不能找到所有情况
如标签 ID 或名称重复的分情况校验（模型标签不存在标注集标签中；模型标签与标注集标签完全一致；模型标签与标注集标签 ID 相同名称不同；模型标签与标注集标签名称相同，ID 不同；既有相同名称又有相同 ID，但是不能完全对应） - 缺少对异常情况的校验
如搜索% _ 数据库通配符
如删除最后一页的数据
如同时提交数据相同的数据表单等
如正在运行的模型，所属的模型仓库是否可以被删除
- case分级、自测标记
缺少标准，标的比较随意，不能起到应有的作用
2. 如何写用例
2.1 什么是好的用例
- 来源需求、覆盖需求
- 步骤、预期结果清楚
- 易于维护、复用
- 能够发现尽可能多的 bug, 能够发现之前没发现的 bug
2.2 测试用例设计常见方法
- 等价类划分(掌握)
- 规定了输入值的范围，可以划分为一个有效等价类（在指定范围内）和两个无效等价类（分别小于和大于指定范围）。
- 规定了输入数据个数，类似地也可以划分一个有效等价类和两个无效等价类
- 规定了输入数据的一组值，程序对不同输入值做不同处理，则每个值为一个有效等价类，还有一个无效等价类（不属于这组值里的任意值）
- 规定了输入数据必须遵守的原则，则可以划分一个有效等价类和若干无效等价类（从不同角度违反规则）
- 如果规定定输入数据为整数，则可以划分负整数、正整数、0 三个有效等价类
- 边界值分析(掌握）
- 刚好等于
- 刚好小于
- 刚好大于
不仅要考虑输入的边界值，还要考虑输出的边界值
- 场景法(掌握)
场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程。
测试不能只关注某个控件的边界值、等价类是否满足要求，也要关注它的主要功能和业务流程是否正确实现，这时就需要使用场景法来完成。
场景法用例设计步骤
- 设计场景用例首先需要根据需求规格说明得出功能模块流程图，描述出程序的基本流及备选流，
- 基本流：按照正确的业务流程来实现的一条操作路径即模拟正确的操作流程。
- 备选流：导致程序出现错误的操作流程即模拟错误的操作流程。
- 其次根据基本流和备选流生成不同的场景，构造场景列表，
- 最后对每一个场景生成相应的测试用例，对所有的测试用例重新复审，去掉多余的测试用例。
- 确定测试用例之后，为每一个测试用例确定测试的数据值即可完成场景用例的设计。
- 错误推测(掌握）
直觉、经验 发现 组合错误、逻辑错误
- 忘记需求、忘记 UE、不要有任何参考（包括界面的一些提示性文字），随便输入，不要担心产品崩溃等
- 根据之前测试出问题的一些经验，去输入
-
判定表、判定树
复杂的条件组合与应做动作之间的关系
左上部列出所有条件，左下部是所有可能的动作
右上部是条件组合矩阵，右下部是每种条件组合相对应的动作
-
因果图
https://blog.csdn.net/tingxuan_qhm/article/details/22512209 -
功能图法
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 ：不影响使用的瑕疵、更好的实现方式。
