[开发测试]如何写出测试用例

测试用例编写规范

一、测试用例概念

? 在说测试用例之前首先要明白测试这份工作，保证软件产品的质量。但是这个理解起来是十分空洞的，质量要如何保证？

• 首先我们的产品能有一个明确的需求，比如我们开发的这款产品是用来解决什么问题的？这就涉及到我们这个产品的第一个要求，就是我们这个产品正常的功能能否实现。
• 第二就是在保证正常的功能的基础上，我们的产品有没有什么不合理或者是可以被优化的地方。这是我们测试开发的第二个重要的地方，用户的体验。

? 所以，我对测试用例的理解就是我们在产品发布之前，我们尽可能的用文档的方式想到用户在使用我们的产品的时候可能遇到的各种各样的情况，我们提前发现问题，将其解决，通过这样的方式保证我们产品的质量。

二、测试用例的作用

1. 检验软件是否满足客户需求【更多的是是否满足产品给出的Prd要求，基本也是和产品以及开发沟通出来的结果】
2. 测试人员的工作量的一种体现【将质量用实实在在可以看得到的东西保证】
3. 展示测试用例的设计思路【指导我们在拿到软件的时候如何操作，一种操作守则】

三、如何编写测试用例

3.1 测试用例的内容

测试用例八个基本项是：测试用例编号、测试项目、测试标题、重要级别、预置条件、输入、操作步骤、预期输出

3.2 测试用例的编写流程

需求分析–>提取测试点–>测试用例设计–>测试用例评审

3.3 测试用例的常用方法

此外还有因果图法、错误推测法、判定表驱动法等

3.4 测试用例的编写

对各个功能模块进行测试点分析提取测试点在对测试点用例进行详细的编写

以PC端QQ登录为例

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

3.5 用例设计思路

==从用户实际使用场景，业务目标出发设计测试用例。==不要从页面UI出发编写测试用例。

【Note】
如果有功能和页面的优化，那么测试用例也应该是对之前用例的优化和更新。不要每次迭代就设计和堆砌一些测试用例。

3.6 标题的拟定

原则：清晰明了；不同用例之间解耦，可以独立执行。

• 验证xx角色，xx场景，执行xx操作，预期会xxx。（客户端场景测试用例标题）

• 验证XXX接口，XX场景，返回XXX。（服务端纯接口测试用例标题）

不好的标题：验证电池更换工单信息查询，“更换前模组编码”、“更换后模组编码”、“所属电池包编码”、“备注”字段调整
用例标题分析：

1. 没有从功能角度设计用例，没有从用户想要达到的业务目标出发设计用例，仅仅是检查了页面。这样的用例价值不高。
2. 没有主语（具有xx角色的用户，具有xx权限的用户）
3. 没有明确预期结果，“调整” “变更”“优化”“符合预期”这类字眼不应该出现在标题中。
4. 建议，这次的优化对功能没有变更，建议优化原有的测试用例，在测试步骤中对本次优化的点进行校验。

3.7 校验点

原则：数据流过的地方都要进行校验。
校验各个APPUI展现、检查服务端（考虑接口、日志、数据库、kafka等）各自表现。

3.8 测试数据构造

按照如下优先级选择构造测试数据方法：

1. 优先采用真实使用方法

2. 其次是通过接口构造数据

3. 再次通过操作数据库或者kafka方式构造

4. 最后选择charles抓包模拟接口响应构造。

3.9 测试数据内容

尽量使用用户真实数据内容
例如：保养原因，维修原因，取消原因，真实评价，各种编号等数据

3.10 模块

按照用例归属的模块设置

3.11 优先级设置

P1优先级：用户实际使用过程中常用的正向使用场景、用于进行回归测试的Case、针对线上BUG补充的Case。
P2优先级：用户实际使用过程中可能会经常遇到的异常使用场景，发现过BUG的Case。
P3优先级：文案、UI、体验类cas