解释
用例编号
用例编号是唯一的,一般我们在接到新需求的时候,产品确定好需求文档之后,我们可以开始编写测试用例了,这个测试编号是唯一的,比说 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
备注信息
具体备注的信息
必需的列
我这个测试用例的模板比较完备,一般来讲,测试用例的列不可缺少
测试标题操作步骤预期结果测试结果这四大部分,其他的列可以根据项目需要添加
统计
另外可以在用例最顶上写上统计信息,如下
我们应该怎么写用例?
我自己最常用的就是等价类划分和边界值法,其实还是等价类划分最常用,等价类划分划分到怎么样的细致程度,已经边界值分析分析到什么样的细致的程度,这个是比较灵活的,需要看测试投入时间与收益以及功能重要程度等多方面来考虑
上面所说的都是很粗略的测试用例怎么写,详细点说就是比如一个登陆页面,我们需要关注以下几个维度来编写测试用例
该页面正向主流程正向(正向+异常)该页面各个模块组件的功能验证(正向+异常)各个页面或者多个模块之间数据交互的验证其他的隐藏潜在的待验证点对于正向的页面主流程重要程度可以标记为高,其他的可以标记为中或者低,高级别的用例在冒烟或者回归时候可以被识别来测试