模板
| 用例编号 | 测试模块 | 用例名称（测试项目） | 前置条件 | 操作步骤 | 预期结果 | 测试结果 | 重要程度 | 更新时间 | 测试人员 | 能否接口自动化 | 能否 UI 自动化 | 备注信息 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 项目代码-需求代码-用例编号 | 可以写被测试的模块名称 | 可以按照功能划分 | 该测试用例要准备的数据以及要准备的一些前置操作 | 1.第一步操作 2.第二步操作 3.第三步操作 |
PASS 或者 FAIL 或者 WAITING 或者 N/A | 高或者 中或者低 | 2020-01-13 | 李明 | Y 或者 N | Y 或者 N | 备注信息 |
解释
-
用例编号
用例编号是唯一的，一般我们在接到新需求的时候，产品确定好需求文档之后，我们可以开始编写测试用例了，这个测试编号是唯一的，比说 A 项目 售后模块改进.doc 的需求，售后模块改进的英文是 After Sale Module Improvement，那么这个用例编号我可以写 A-ASI-001
-
测试模块
比如说我测试售后功能的改进，那我这里可以写
售后模块-xxx模块 -
用例名称
这里可以写用例名称或者测试项目，比如我要测搜索功能，这里就应该写
售后模块-搜索测试 -
前置条件
比如登录账号进入系统这个前置操作，其中写明账号密码是多少即可
-
操作步骤
具体详细无歧义的操作步骤，按照 1 2 3 4 … 来划分步骤
-
预期结果
测试用例每一步都要写预期结果，有的步骤可能纯粹操作你可以不写，写有预期结果的，比如最后一步犹豫期结果就写
1.N/A 2.N/A 3.xxxx -
测试结果
填写
PASS表示通过，Fail表示失败，WAITING表示等待中，N/A表示该条测试用例因某些原因可以不用管了 -
重要程度
高中低，看该功能的重要程度，是否影响主流程等等总和判断，这个考验测试人员对业务场景的熟悉程度。正向主流程的用例可以标记为高级别
-
更新时间
测试用例最近一次的更新时间，可以统一一下时间格式
-
测试人员
该条测试用例是谁来测试的
-
能否接口自动化
填写 Y 或者 N
-
能否 UI 自动化
填写 Y 或者 N
-
备注信息
具体备注的信息
必需的列
我这个测试用例的模板比较完备，一般来讲，测试用例的列不可缺少
- 测试标题
- 操作步骤
- 预期结果
- 测试结果
这四大部分，其他的列可以根据项目需要添加
统计
另外可以在用例最顶上写上统计信息，如下
我们应该怎么写用例？
我自己最常用的就是等价类划分和边界值法，其实还是等价类划分最常用，等价类划分划分到怎么样的细致程度，已经边界值分析分析到什么样的细致的程度，这个是比较灵活的，需要看测试投入时间与收益以及功能重要程度等多方面来考虑
上面所说的都是很粗略的测试用例怎么写，详细点说就是比如一个登陆页面，我们需要关注以下几个维度来编写测试用例
- 该页面正向主流程正向（正向+异常）
- 该页面各个模块组件的功能验证（正向+异常）
- 各个页面或者多个模块之间数据交互的验证
- 其他的隐藏潜在的待验证点
对于正向的页面主流程重要程度可以标记为高，其他的可以标记为中或者低，高级别的用例在冒烟或者回归时候可以被识别来测试
