文章目录

• 1）什么是测试用例？
• • 1.1 测试用例的定义
  • • • 测试用例的内容：
    • *为什么需要测试用例？
    • • 测试用例的作用：
  • 1.2 测试用例的元素
  • • 测试目标（Why）：
    • 测试对象（What）：
    • 测试环境（Where）：
    • 测试前提（When）：
    • 输入数据（Which）：
    • 操作步骤（How）：
• 2）测试用例的编写流程
• • 2.1 需求分析
  • • 1、过需求文档：
    • 2、根据需求文档，拆分测试点。
    • • 需求的种类：
      • *什么是产品需求文档？
      • *什么是交互需求文档？
      • *如果没有需求文档，怎么设计测试用例？
  • 2.2 提取测试点
  • • 【举例】对PC端QQ账号的登录模块，提取测试点：
    • 【举例】对CSDN的web端登录界面，提取测试点：
  • 2.3 测试用例的编写
  • • 2.3.1 编写测试用例该注意什么？
    • • 测试用例的模板：
    • 2.3.2 测试用例的写作
    • • 用例编号/ 序号
      • 用例说明（检查点）
      • 初始条件
      • 操作步骤
      • 预期结果
      • 用例状态
      • 优先级
      • *举例：
  • 2.4 测试用例的评审
  • • *为什么要进行用例的评审？
    • 2.4.1 测试用例评审要点
    • 2.4.2 测试用例的维护
    • 为什么需要更新测试用例？
    • 常见的测试用例管理工具
• 3）编写测试用例的方法

1）什么是测试用例？

1.1 测试用例的定义

测试用例是对一项特定的软件产品进行测试任务的描述，指定输入，预期结果和一组测试项的执行条件的文档。

• 它是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。
• 体现了测试方案、方法、技术和策略。

• 测试用例的内容：

  内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。具体有：

  • 用例编号、用例名称
  • 测试背景
  • 前置条件
  • 优先级、重要级
  • 测试数据
  • 测试步骤
  • 预期结果、实际结果
  • 备注等

*为什么需要测试用例？

测试用例的作用：

• 检验软件是否满足客户需求
• 体现一个测试人员的工作量
• 展现测试用例的设计思路

• 测试用例是测试人员在测试过程中的重要参考依据。

• 测试用例可以帮助实施有效的测试，所有被执行的测试都是有意义的，不执行毫无意义的测试操作。

• 测试用例是一个知识传递的过程，能保持一致、稳定的测试质量。

• 从项目管理的角度来说，测试用例的通过率是检验代码质量最主要的指标之一。

• 测试用例也可以作为评估测试人员进度、工作量以及跟踪/管理测试的工作效率的主要因素，从而更加合理地做出测试安排或调整。

• 良好的测试用例不断地被重复使用，使得测试过程事半功倍。
  • 在软件产品的开发过程中，开发人员不断的推出新的版本，测试人员需要对原有功能进行多次的回归测试，即使在一个版本中，也要进行 2～3次的回归测试。这些回归测试，就要求能重复使用测试用例。
• 如果没有测试用例，很可能到执行的时候测试点就遗漏了，另外也不便于用例评审，用例总结，对后期测试工作没大的改进作用。
  • 所以测试用例一定要写，颗粒度视情况而定。针对测试人员少，上线时间紧的项目，可只做思维导图列出测试点。

1.2 测试用例的元素

测试用例必须给出测试测试目标、测试对象、测试环境要求、输入数据和操作步骤，即 5W1H。

• 测试目标（Why）：

  为什么而测？功能、性能、可用性、容错性、兼容性、安全性等。

• 测试对象（What）：

  测什么？被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等。

• 测试环境（Where）：

  在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议等单机或网络环境。

• 测试前提（When）：

  什么时候可测？测试用例运行时所处的前提或条件限制。

• 输入数据（Which）：

  哪些数据？在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。

• 操作步骤（How）：

  如何测？执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等。

2）测试用例的编写流程

主要分为以下四步：

需求分析 -> 提取测试点 -> 测试用例编写 -> 测试用例评审

2.1 需求分析

如果直接去测试，会发现有很多需求理解的偏差，测试过程中会发现自己理解的需求跟开发实际做出来的功能不一致。

所以拿到需求后：

1、过需求文档：

• 先自己过一遍需求文档，标出不理解或者可能会有争议的地方。
• 可以借鉴一下同类产品类似的功能是怎样处理的，这样更有助于理解需求。
• 针对有疑义的地方与产品经理和开发人员一起讨论，尽量减少大家对需求理解上的误差。

2、根据需求文档，拆分测试点。

• 需求的种类：

  • 业务需求：关注系统是否满足业务要求。
  • 用户需求：关注系统是否满足用户习惯。
  • 功能需求：关注系统是否满足功能要求。

*什么是产品需求文档？

产品需求文档就是产品功能说明书，包含大量的功能细节，目的是提高沟通效率，避免研发过程出现误会。

产品需求文档是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。

• 需求背景与目标说明：让别人知道为什么要做，要做到什么程度，用户检验功能完成情况。
• 特性列表：所谓特性其实就是功能模块，把需要做的功能模块都罗列出来，主要用于明确需要做的功能有哪些，用图表体现更佳。
• 主要逻辑：每个特性之下的操作逻辑，简单特性可以文字说明，复杂特性建议用流程图表现。
• 特性功能点：补充每个功能点的相关细节描述，是开发，与测试工作的重要依据。包括：
  • 流程细节描述
  • 正常逻辑表现，异常逻辑表现
  • 文案内容，性能需求
  • 交互图（可无）
• 特性需求，性能需求，数据上报：这一部分类似备注，说明了做这个功能要达到怎样的程度，需要再哪些地方进行数据埋点。

*什么是交互需求文档？

交互需求文档是给交互设计师看的文档，应该在需求文档之外单独呈现，主要目的是让交互设计师理解产品的交互需求。

• 交互需求文档主要是对功能的交互设计，包含功能列表，每个功能的交互要点说明，包含元素等等。

*如果没有需求文档，怎么设计测试用例？

• 查找其他相关文档，来帮助理解所要测试的产品需要完成的目标。
• 尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解。
• 咨询相关人员：项目负责人、市场人员。
• 如果是一款已经上线的产品，可以多使用产品，有不懂的问产品经理。
• 可以去看历史bug，了解到一些需要关注的东西。

2.2 提取测试点

对各个功能模块进行测试点分析，提取测试点，再对测试点进行用例编写。

• 测试点：通过需求分析后，对得出的需求进行测试的具体内容。

【举例】对PC端QQ账号的登录模块，提取测试点：

• 登录：
  • 正常登陆
  • 账号为空时点击登录
  • 密码为空时点击登录
  • 账号密码都为空时点击登录
  • 密码错误时点击登录
• 记住密码功能是否有效
• 自动登录功能是否有效
• 找回密码功能是否有效
• 注册账号能否正确跳转

【举例】对CSDN的web端登录界面，提取测试点：

• 登录：
  • 正常登录
  • 账号为空时点击登录
  • 密码为空时点击登录
  • 账号密码都为空时点击登录
  • 密码错误时点击登录
• 判断输入的手机号或者邮箱是否符合规范
• 判断输入的账号是否存在
• 下次自动登录按钮是否生效
• 忘记密码按钮是否生效
• 第三方登录是否有效
• 注册账号按钮是否生效

2.3 测试用例的编写

2.3.1 编写测试用例该注意什么？

• 根据项目的实际情况设计测试用例表格
• 用例格式不要生搬硬套
• 根据具体情况进行编写
• 小技巧：
  • 把测试管理工具中的缺陷全部分类导出，总结一下哪些模块容易产生哪些缺陷，重点看一下自己没发现或没有考虑到的缺陷。
  • 把测试管理工具中的用例详细看几遍，学习别人的用例编写方法和思想。

• 测试用例的模板：

  
  

2.3.2 测试用例的写作

• 用例编号/ 序号

  • 应该简单且唯一。

• 用例说明（检查点）

  • 也称测试点、检查点、测试概述、用例概述、测试说明。
  • 用一句话对测试用例进行概述，最好看到这句话就能知道如何测试。
  • 可以总结测试目的，可以用“检查、验证、测试”等字眼（如验证 QQ 默认安装）。
  • 用例执行多轮时，越往后执行可能越快，如果用例写得好，直接看概述就行。

• 初始条件

  • 也称预置条件、前提条件。
  • 初始条件是第一步操作步骤之前的状态，不能太远，不用从头写到尾。
  • 初始条件要是一个状态，而且是静态的，如管理员已登录后台。
  • 很多项目中不写预置条件。

• 操作步骤

  • 步骤要都有序号。
  • 每一步用分号分开，最后用一个句号。每一步必须换行。
  • 参数前加冒号（如用户名：admin）。涉及按钮界面用【】、“”等成对符号间隔。
  • 功能的详细用例步骤 4-6 步左右。
  • 若对数据要求高，需要把数据分离出来。

• 预期结果

  • 是一个状态。
  • 如果参考文档中有描述，原封不动的抄过来。
  • 如果文档中没有具体要求，则点要一致，可以有几个点，如 QQ 默认安装，应能启动、默认选项匹配等。

• 用例状态

  • 通过、失败、阻塞、未执行、搁置、无效用例等。
  • 初始条件达不到时，一般用例状态设置为阻塞。
  • 看如何执行用例，执行完关心什么来定。

• 优先级

  • 用例的执行顺序。

*举例：

2.4 测试用例的评审

评审就是对测试用例进行检查。用例编写完成后，要组织人员进行用例的评审。

• 评审包括：同行评审、小组评审、部门评审和第三方评审等。
• 参与人员：包括需求人员（如产品经理）、测试人员、开发人员等。
• 评审流程：评审后改进测试用例，再进行评审再改进测试用例，这样一直循环直到评审都通过，这时候才结束评审，也标志着测试用例编写的完成。

*为什么要进行用例的评审？

测试用例包含了功能的边边角角，我们不能保证能把所有的测试点都列出来，也不能保证我们所列出来的测试点方向都是正确的，那么就需要其他人来查缺补漏、纠正错误，看一下有没有我们漏掉的点，看一下我们用例的方向是否正确，防止对需求的理解错误。

• 通过评审发现用例的不足
• 方便测试人员改进用例
• 提高测试质量

2.4.1 测试用例评审要点

• 根据检查单或检查表（Check List）进行评审。
• 用例“文字校对”：错别字、病句、语句不通顺、含义不清晰、语句有歧义、格式不一致、标点不一致、中英文混合等。
• 用例质量：遗漏用例、冗余用例、不清晰用例、错误用例、不可测用例等。
• 确定用例的优先级。
• 规划服务器和客户机。
• 用例的分工执行与人员安排。
• 记录评审过程，记录测试环境规划。

2.4.2 测试用例的维护

• 为什么需要更新测试用例？

  • 先前的测试用例设计不全面或者不够准确。随着测试的深入和对产品规格说明书的深入研究，对某些功能、特性、逻辑等的理解越来越清楚、深刻。
  • 所发现的严重的软件缺陷没有被目前的测试用例所覆盖。
  • 新的版本中有新功能的需求或者原有功能的增强而需要发生改动。
  • 编写的测试用例不规范或者语句错误。
  • 旧的测试用例已经不再适用，需要删除。

• 常见的测试用例管理工具

  • 原始的Excel管理
  • TestLink: 免费开源可扩展性高，可以和bugzilla等缺陷管理工具的整合，适合中小型项目的管理。
  • ZenTao（禅道）：免费开源，不过定制能力不足，不好用层级结构管理用例。
  • Bugzilla、ALM等，更详细的可以参考：有哪些比较好的测试用例管理工具？（https://www.zhihu.com/question/26898212）

3）编写测试用例的方法

常见的方法有等价类划分法、边界值分析法、功能图法、错误推测法、因果图法、场景法等。

具体可参考本栏目的《【测试】编写测试用例的常用方法》。（https://blog.csdn.net/m0_37621024/article/details/116860859）

【部分内容参考自】

• 测试开发之编写测试用例：https://bqleng.blog.csdn.net/article/details/105284818
• 一份优秀的需求文档：https://www.pianshen.com/article/8729120291/
• 编写测试用例及一个例子：http://www.51testing.com/html/24/n-3727424.html
• 测试开发之编写测试用例：https://bqleng.blog.csdn.net/article/details/105284818