测试用例编写指南

测试用例编写指南

为了保证我们的产品质量，让测试工作更规范、更高效，我们统一使用本文档定义的规范来编写测试用例。一份好的用例不仅是测试执行的依据，也是产品功能和逻辑的宝贵沉淀。

一、 测试用例的构成元素

每一条测试用例都由以下几个核心部分组成：

二、 如何填写每个字段？

1. 功能模块

• 作用：体现被测功能在整个系统中的位置，方便用例的归类和查找。
• 格式：我们采用“父模块子模块孙模块”的层级结构，用 _ 分隔。
• 示例：阅读器_工具栏_目录列表

2. 用例名称

• 作用：清晰、简洁地概括本条用例的核心测试点。
• 编写技巧：
  • 应高度概括，让人一眼就能看懂测试目的。
  • 格式建议：“验证/检查 + [在什么条件下] + [执行什么操作] + [得到什么结果]”。
• 示例：验证在阅读器中能成功打开并显示正确的目录列表

3. 用例等级

• 作用：定义用例的优先级，帮助我们在时间有限的情况下，优先执行最重要的测试。
• 等级划分 (括号内为常用简称)：
  • 基础 (P0)：“产品跑不起来” 的核心功能。这些用例的失败会导致多处重要功能无法运行，通常是用户最高频使用的基础流程。
    • 示例：书籍能正常打开、阅读器能上下滚动或左右翻页。
  • 高 (P1)：“用户天天用” 的主要功能。包括主要的功能交互、核心的应用场景。
    • 示例：通过目录进行章节跳转、切换阅读器背景色、调整字体大小。
  • 中 (P2)：“不常用但很重要” 的功能。包括使用频率稍低的功能、或一些重要功能的异常/边界情况测试。
    • 示例：昵称输入特殊字符、评论区发表超长文本。
  • 低 (P3)：“锦上添花或犄角旮旯” 的功能。对应较生僻的场景、对用户影响极小的UI规范问题、或在实际使用中频率极低的功能。
    • 示例：检查关于我们页面的UI布局是否对齐、在极差网络下反复点击某个按钮。

4. 前置条件

• 作用：描述执行这条用例前，必须准备好的环境、数据或状态。
• 编写技巧：
  • 这是可选项，如果没有特殊要求则无需填写。
  • 如果有多条，请务必使用数字编号，即使只有一条也要编号。
• 示例：
  1. 用户已登录
  2. 书架上至少有一本书

5. 操作步骤

• 作用：提供清晰、无歧义的复现路径，是开发同学定位问题的直接依据。
• 编写技巧：与 Bug 报告中的“重现路径”完全一致，遵循“一步一操作、编号清晰、语言简洁”的原则。
• 相关链接：bug提交指南

6. 预期结果

• 作用：定义“成功”的标准。如果实际结果与预期不符，则测试不通过。
• 编写技巧：
  • 描述必须清晰、明确、可验证，杜绝“大概、可能、应该”等模糊词汇。
  • 如果一个操作会引发多个结果，建议分点列出，确保覆盖所有验证点。
  • 同样，如果有多条，请务必使用数字编号。
• 示例：
  1. 阅读器背景颜色变为羊皮纸色。
  2. 设置面板自动关闭。
  3. 书籍正文文字和颜色正常显示，未出现错乱。

三、 一个完整的例子