软件测试用例
定义
测试用例(TestCase
)是为项目需求而编制的一组测试输入,执行步骤,以及预期结果
,以便测试某个程序是否满足客户需求
可以总结为:每一个测试点的数据设计和步骤设计 -- 对测试点的细化
作用
- 测试用例是软件测试核心
- 评估测试结果的基准
- 保证测试的时候不遗漏测试功能点,避免漏测和错误测试
- 设计测试用例的过程,可以熟悉需求,对系统架构或者业务流程有一个整体的了解
- 在执行完测试用例之后,补充完善用例
测试用例不是一次性就能写完的,需要一点点完善
测试用例八大要素(重要)
用例编号
:产品名-测试阶段 -- st or uat测试项目
:对应一个功能模块(细化功能)测试标题
:直接对测试点
进行细化
得出,输入内容+结果
,同一功能模块标题不能重复(来自测试点)重要级别
:- 高(high):核心功能 -- P1
- 中(medium):次要功能异常 -- P2
- 低(low):界面,不常用场景 -- P3
预置条件
:需求满足一些前提条件,否则用例无法执行 -- 不是必填项测试输入(数据)
:需要加工的输入信息,根据具体情况来设计(跟步骤结合起来一定要具有指导性意义)-- 数据构造操作步骤
:明确给出每一个步骤的描述,执行人员可以根据该步骤完成执行工作预期结果
:根据预期输出比对实际结果,来判断被测对象是否符合需求 -- 预期结果唯一,不能出现是否或者- 实际结果:执行后的最终结果
测试用例编写原则
- 正常冒烟测试:详细到每一个步骤,进行预期结果的检查 -- 第一条用例比较多
- 后面用例,但凡跟第一个测试用例的点重复的话,去重,用到用例设计方法,细化,正常异常
编写测试用例步骤
- 分析需求
- 提取测试点
- 细化测试用例
测试用例评审
开会[开发,产品,测试]:用例讲解(测试点+思路+展示) -- 意见+建议 -- 会议记录 -- 修改用例 -- 二次用例评审 -- 评审通过
测试用例变更
由于需求变更,对于业务的不断深入了解和测试用例评审,测试用例是无法一次性全部写好的
,所以,测试用例在完成之后是需要不断修正的
测试用例变更通常包含:
- 需求变动
- 执行完成后的用例完善
- 评审后的用例修改
备份测试用例文档
Q:公司就算没有时间,也会做用例评审吗?
A:发邮件(附件用例文档),开发,产品,测试,等待回复,规避责任
Q:如果时间紧急,来不及编写测试用例,怎么办?
A:直接写测试点,项目结束后,完善测试用例,归档
Q:用例的优先级依据什么来确定?有什么作用
A:制定执行策略依据
Q:如何编写测试用例?
A:分析需求-提取测试点-编写测试用例