测试用例编写规范.md 6.5 KB

编写规范、高质量的测试用例是保障软件质量的关键环节。一份优秀的测试用例不仅要自己能看懂,更要让团队其他成员(如开发、产品、其他测试人员)都能轻松理解并执行。

以下是测试用例编写的一套标准规范指南:

一、 测试用例的核心要素(必填项)

一个标准的测试用例通常包含以下核心字段:

  1. 用例编号
    • 规范:需具有唯一性,通常采用“模块_子模块_功能_序号”的格式。
    • *示例*:SYS_LOGIN_001SHOP_CART_ADD_002
  2. 用例标题
    • 规范:用简练的语言概括测试点。建议采用“条件+动作+预期结果”的结构,且结尾通常不带句号。
    • *示例*:输入正确的用户名和密码,登录成功
  3. 前置条件
    • 规范:描述执行本用例前必须满足的状态或环境准备。
    • *示例*:用户已注册账号且状态为激活;已打开登录页面
  4. 测试步骤
    • 规范:步骤要清晰、具体、可执行。避免模糊词汇(如“反复操作”、“多试几次”)。步骤编号要有序(1、2、3...)。
  5. 预期结果
    • 规范:明确描述系统应有的反馈,包括页面提示、数据库变化、接口返回值等。切忌模棱两可(如“显示正常”应改为“显示‘登录成功’弹窗”)。
  6. 优先级
    • 规范
      • P0(冒烟/核心):阻碍系统运行的核心功能。
      • P1(重要):主要业务流程。
      • P2(一般):次要功能、边界情况。
      • P3(次要):UI优化、体验类、极低概率场景。
  7. 所属模块/标签

    • 用于分类管理,便于筛选和统计。

      二、 编写原则(核心心法)

      在编写具体内容时,需遵循以下五大原则:

      1. 单一职责原则

  8. 规范:一个测试用例只验证一个功能点或一个业务场景。

  9. 反例:一个用例里既测试登录成功,又测试修改密码,又测试注销。这会导致用例冗长,且出错后难以定位具体环节。

    2. 可判定性/可验证性

  10. 规范:预期结果必须是客观的、可被观察到的。不能依赖测试人员的主观感受。

  11. *错误写法*:“界面美观,用户体验好。”

  12. *正确写法*:“登录按钮圆角为4px,点击后有加载动画,时长不超过2秒。”

    3. 可重复性

  13. 规范:无论谁执行,无论执行多少次,只要环境一致,结果应该一致。步骤描述不能有歧义。

  14. *模糊写法*:“输入一些特殊字符。”

  15. *精确写法*:“在用户名输入框输入 test@#$%。”

    4. 独立性

  16. 规范:用例之间尽量保持独立,不要有强依赖关系。

  17. *问题*:用例B执行必须依赖用例A执行成功后的数据。如果用例A失败,用例B就无法执行,增加维护成本。

  18. *建议*:通过数据准备或公共前置条件来解耦。

    5. 覆盖性

  19. 规范:不仅要覆盖“正确路径”,更要覆盖“错误路径”和“边界值”。

    三、 具体编写技巧

    1. 步骤编写规范

  20. 量化具体:不要说“多输入几次”,要说“输入5次错误密码”。

  21. 操作明确:不要说“操作下拉框”,要说“点击下拉框,选择‘选项A’”。

  22. 数据明确:不要说“输入正确的数据”,要说“输入用户名 admin,密码 123456”。

    2. 预期结果编写规范

  23. 多维验证:不仅要看界面表现,还要关注后台数据。

    • *UI层*:提示文案、跳转页面、按钮状态。
    • *数据层*:数据库字段是否更新、日志是否记录。
    • *接口层*:HTTP状态码、返回的JSON结构。

      3. 边界值分析规范

  24. 必须包含:正好等于边界、刚刚小于边界、刚刚大于边界。

  25. *示例*(限额1-100元):

    • 0元(无效边界)
    • 1元(有效边界)
    • 100元(有效边界)
    • 101元(无效边界)

      四、 常见的分类与设计方法

      在编写用例前,建议使用以下方法设计测试点:

  26. 等价类划分:将输入数据分为有效等价类和无效等价类,减少测试用例数量。

  27. 边界值分析:重点测试边界情况(最容易出Bug的地方)。

  28. 错误推测法:根据经验推测可能存在的隐患(如断网、并发、超时)。

  29. 场景法:覆盖业务流程(基本流和备选流)。 按测试类型分类:

  30. 正向用例:符合需求定义的正常操作。

  31. 逆向用例:异常操作、错误数据、权限不足、网络中断等。

  32. UI/体验用例:布局、兼容性、易用性。

    五、 案例模板演示

    用例编号USER_LOGIN_001 用例标题:使用已注册且激活的账号,正确输入用户名和密码,登录成功 优先级:P0 前置条件

  33. 数据库中存在用户 testuser,密码 123456

  34. 用户状态为 Activated

  35. 打开系统登录页面。 | 序号 | 测试步骤 | 预期结果 | | :--- | :----------------------------- | :----------------------------------------------------------- | | 1 | 在用户名输入框输入:testuser | 输入框正常显示字符 | | 2 | 在密码输入框输入:123456 | 显示为密文(如圆点或星号) |

    | 3 | 点击“登录”按钮 | 1. 按钮置灰并显示“登录中...”加载状态
    2. 页面跳转至首页
    3. 右上角显示用户名 testuser |

    六、 常见误区(避坑指南)

  36. “大概齐”步骤:步骤写得像说明书,而不是操作指引。例如:“输入用户信息”。(错误,应具体到输入什么信息)。

  37. 预期结果空泛:预期结果写“登录成功”。(错误,应写明具体的页面跳转、提示弹窗或数据库记录)。

  38. 遗漏异常场景:只写正确流程,忘记写密码错误、账号锁定、网络波动等异常场景。

  39. 用例不可执行:前置条件描述为“准备好测试数据”,但没说准备什么数据,导致执行者无法开始。 遵循以上规范,可以确保测试用例库具有良好的可读性、可维护性和执行效率,从而真正发挥测试用例的价值。