测试用例的设计思路

接到提测单后要做的事情：

• 测试准备阶段
  1. 确认提测单内包含的文件、URL地址可以访问
  2. 确认需求 (迭代目标、用户故事、用户愿望、问题反馈等)
  3. 确认回归测试范围、更新测试范围、新增测试范围
  4. 编写测试点思维导图，过程中有问题及时进行沟通
  5. 与迭代相关人员约一个时间, 开内部的测试点评审会
  6. 根据评审通过的测试点, 编写测试用例 (如果迭代已提测, 可以写用例和执行同步进行, 以提升测试效率)
  7. 通过冒烟用例集给开发, 让开发完成提测冒烟
• 测试执行阶段
  1. 第一轮测试执行
  2. 第二轮测试执行 (回归第一轮发现的问题)
  3. 输出测试报告
  4. 第三轮测试执行 (迭代版本发布时的验证)
• 测试结束阶段
  1. 编写迭代总结内容 (做到好的、做的不好的、需要保持的)
     • 工时是否存在偏差
     • 被关闭的缺陷是否有合理的关闭原因
  2. 测试用例入库 (迭代库 -> 全量库)

常规的八个用例设计方向：

• UI界面 : 界面布局、排版是否符合UI设计师或产品需求, 文字, 图标大小。比如: 点赞按钮的位置, 点赞人的名称文字显示, 点赞红星图标, 点赞个数。
• 易用性 : 操作简单, 操作是否有友好提示, 如果是输入框 (是否支持Tab、Enter等快捷键)。 比如: 点赞后有提示, 点赞流程简单, 点赞入口。
• 兼容性 : 不同手机、浏览器、操作系统版本, 软件版本, 分辨率, 显示正常且功能正常。比如: 平板, 小米, 华为, 微信客户端。
• 功能测试 : 场景+流程 (用户可能执行的操作, 业务流程) + 新增改查删除+排序。比如: 点赞别人的朋友圈 (朋友点赞我的朋友圈), 点赞成功, 取消点赞, 点赞是否看到共同好友, 删除朋友圈, 删除点赞, 点赞的排序。
• 接口测试 : 接口正常调用, 返回报文正常。比如: 点赞接口调用, 参数 (后端)。
• 弱网测试 : 断网、网络信号差, 操作的时候来电话, 4G/5G 网络切换。比如: 打电话的时候点赞, 断网点赞。
• 性能测试 : 使用该功能的响应时间是否在需求规定的时间, 多次快速操作。比如: 点赞到显示点赞的响应时间, 点赞后好友消息更新的速度, 同时点赞, 多次点赞。
• 安全测试 : 客户端和服务端都需要验证 (不能单单是在客户端验证), 涉及手机号、身份证、银行卡、密码等敏感信息是否加密。比如: 点赞是否泄露用户信息。

编写用例时点注意事项如下：

1. 用例能被别人轻松地阅读、理解和执行
2. 用例要紧密联系测试点
3. 要在 预期结果 中与测试点完成闭环
4. 存在代码时, 代码放 前置条件 里定义好, 再放 操作步骤 里引用
5. 存在特殊需求或情况时, 需要在 备注 里详细说明
6. 存在多团队或组织时, 需要考虑测试对象在多团队或组织下的检查
7. 如果测试点为代码配置项时, 避免贴大段代码, 应该突出配置项及其关联
8. 如果测试对象可以重复, 需要根据其重复规则设计测试场景
9. 如果测试点关联或支持多类型、多场景时, 拆成多条用例来写
10. 编写 用例标题 时
    • 以 ： 分隔, 前面写模块、属性或路径, 后面写测试点
    • 多条用例有大量重复内容时, 需要说明它们之间的差异点
11. 编写 前置条件 时
    • 首先保证 操作步骤 的正常执行, 不能有冲突
    • 其次要明确边界, 刚好能完成 操作步骤 即可
12. 编写 操作步骤 时
    • 要突出测试点, 非测试点放在 前置条件 里一笔带过
    • 当 步骤描述 包含多项检查时, 在 预期结果 中应给出多项结果
    • 当 预期结果 里包含文本检查时, 需要考虑多语言的场景
    • 当 步骤描述 只有单行文本时, 不用有序或无序列表
13. 编写用例内容时
    • 包含专业或难理解的词汇时, 补充简单描述或添加文档链接
    • 包含 uuid、id 等动态数据时, 用参数描述指代
    • 包含多个测试对象时, 可以用 “A～Z”、“a～z” 或数字指代
    • 包含有序列表时, 数字后应用 . 而不是其他符号
    • 当同一个页面有多个入口时, 固定一个入口作为路径, 避免模糊不清
14. 编写前端UI组件的测试用例时
    • 用例内不能依赖设计稿、开发或自己的Demo，要做到只看用例就能测试
    • 如果必须要引用外部内容，可以用文件或图片以附件形式贴到用例里
    • 验证测试点的组件属性或事件要明明白白地写在用例中
      • 在文档不明确时，用别名代替属性或事件，待文档明确后再修改别名
      • 条件允许时，贴上组件属性或事件的配置代码，让用例有较强的可执行性
    • 根据测试点是否复杂，来控制用例的颗粒大小
      • 复杂时，设计多条用例实现
      • 简单时，在一条用例中，将组件属性或事件变成参数，并在步骤中修改参数

具体场景下的用例测试点设计：

• 接口或函数测试
  • 列表参数
    • 排序用途
      • 首尾和中间插入新值
      • 首尾和中间移除旧值
• UI组件库测试
  • 浏览器(Safari/Edge/Chrome/Firefox)兼容性
    • 最新的版本
    • UI组件库支持的最低版本