文章目录

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）