1. 什么是测试用例
我们之前学习了在需求分析中已经搞懂了这个项目的逻辑，同时呢，我们已经通过xmind为项目提取出了一些测试点(这个项目有哪些东西是需要我去验证的)；那下一步我们每个测试点怎么去测？用什么样的数据去测？应该有什么样的结果？这个环节就是我们本期要说的测试用例。
1.1 定义
测试用例也称为test case，他是为项目需求而制定的，一组测试输入、执行条件以及预期结果，以便测试某个程序是否满足客户需求。可以总结为测试用例是每一个测试点(我们以前说过测试点怎么写的)的数据设计和步骤设计。
或者说它是对每个测试点进行数据及步骤设计的文档，包括数据输入、执行条件以及预期结果(结合需要应该是什么样的)。
补充：
- 预期结果：就是结合需求应该是怎样的结果？
- 实际结果：就是我们对被测软件进行执行实际测试得到的结果。
比如我们需求分析：手机的摄像头是3个(预期结果)，我们去执行测试，实际的结果只有2个摄像头(实际结果)。
1.2 目的
主要就是为了验证程序是否与需求一致。
1.3 编写测试用例的工具是什么？
- excel
- xmind
2. 测试用例包含哪些内容【模版】
2.1 用例编号
用例编号的特点，编号必须是唯一的。
格式：
- 项目名称_编号
- 项目名称_测试阶段(IT/ST/UAT)_测试项_编号
IT：指的是单元测试
ST：指的是系统测试
UAT：指的是验收测试
例如：
XX项目系统_ST_登录_001 或者 XX项目系统_001 或者 001
2.2 模块
什么是模块：模块是为了处理某一个事务对应的所有功能的集合。
测试项与模块的关系： 一个模块包含多个测试项。
补充：一个项目包括多个模块
2.3 用例标题
目的：用的标题是概括你测试的目的的，一般情况必须要言简意骇，标题不能太长。
这个标题怎么去概括怎么去起这个标题呢？如果你不知道就看下述技巧
编写的技巧 ：输入+结果【使用你输入什么得到什么结果来作为他的目的】
比如我们的测试点：用户名与密码正确点击登录按钮，进入系统首页。
| 用例编号 | 模块 | 标题 |
|---|---|---|
| xxx电商系统_ST_001 | 【属于】用户管理模块 | (目的)验证登录成功/输出正确的用户名和密码，登录成功 |
2.4 用例级别
- 高1：主要核心业务功能、冒烟用例
- 中2：错误异常的测试点
- 低3：兼容性(浏览器或者操作系统的兼容)、界面错误
2.5 预置条件
什么是预置条件：就是执行当前用例的时候，我需要做什么特殊的前提准备(比如什么环境/测试数据等)
注意：我们在一般情况下是不需要去填写这个预置条件的。
什么情况下需要填写这个预置条件？：就是需要做特殊准备的情况下。
当你不知道要不要写的时候，你先别写，把其他的写完再回来看。
比如我们上边的测试点，我们必须得是用户名和密码都存在，才能登录成功，这就是我们的预置条件。
| 用例编号 | 模块 | 标题 | 预置条件 |
|---|---|---|---|
| xxx电商系统_ST_001 | 【属于】用户管理模块 | (目的)验证登录成功/输出正确的用户名和密码，登录成功 | 存在于注册账号用户名admin密码admin |
2.6 测试步骤
测试步骤包含什么？怎么写？
包含 ：
具体数据+操作步骤
格式
- 路径：将从哪个地方入口进来找到被测的测试项
- 输入什么样的数据
- 动作：你会做什么样的操作
例如：测试点：用户名与密码正确点击新增功能
| 用例编号 | 模块 | 标题 | 预置条件 | 测试步骤 |
|---|---|---|---|---|
| xxx电商系统_ST_001 | 【属于】用户管理模块 | (目的)验证新增成功/输出正确的用户名和密码，新增成功 | 1、[用户管理]>用户列表，点击[新增] 2、输入用户名：admin 密码:admin3、点击[登录] |
2.7 预期结果
预期结果就是按照操作步骤，应该有什么样的结果【该结果应该与用户需求一致】
编写格式：参考测试步骤
- 多对一：多个步骤对应一个结果【常用,因为简单】
- 一对一：一个步骤对应一个结果
对于多对一：
对于1对1：
2.8 实际结果
实际结果就是我们执行的测试结果。
执行的测试结果一般会有以下几个内容：
- pass通过：用例测试通过(预期结果和实际结果一致)
- failed不通过：用例测试不通过(预期结果与实际结果不一致)
- 阻塞：用例没法执行
你在写测试用例的时候，这个实际结果是不需要去写的，这个实际结果是在测试执行之后才去写的。
软件上线标准
测试覆盖率
测试覆盖率是由我们的测试人员控制的，测试的覆盖率越高越好，理想状态是趋向100%。
- 我们
测试点覆盖率达到100%，是(在需求分析阶段)，我们尽可能把所有的测试点都给找出来。 - 我们将测试点提取出来之后，每一个测试点用什么样的方法来测，怎么去测，就是通过我们编写测试用例去完成，测试点覆盖率要100%，那这里就涉及到
测试用例的覆盖率100%(在我们是用例设计阶段)。 - 那上述测试点的覆盖率，测试用例的覆盖率都只是制定，都没有去具体的做，那接下来如何将所有点都进行一个具体的验证，我们就进入
测试执行覆盖率100%(用例执行阶段)。
我们影响覆盖率的核心是在于需求分析阶段的测试点覆盖率，他是前提。
bug遗留率
理想状态尽可能找出所有的bug，尽可能把所有的bug修复好。但是有时候我们会遗留一些bug到下一个版本继续修复或者暂时修复不了。
所以
bug遗留率=遗留的bug 除以 bug的总数
bug的遗留率是由我们的开发控制的
那么疑问：一个用户名的输入框，我们既要去测试符合要求的用户名，又要去测不符合要求的用户用户名。这样我们上述说测试覆盖率要达到100%，那么是不是要把所有的可能都给列出来，去进行无穷测？
但事实上并不是这样的，此时我们该怎么去测呢？也就是说用较少的测试次数，能够保证我们的覆盖率高，这个就是下期要提到的测试用例的方法，那么下一期我们先介绍测试用例设计方法之等价类。
最后如果觉得这篇知识的整理对你有帮助，别忘了
👍 点赞
⭐ 收藏
👀 关注