软件测试用例
定义
测试用例(TestCase)是为项目需求而编制的一组测试输入,执行步骤,以及预期结果,以便测试某个程序是否满足客户需求
可以总结为:每一个测试点的数据设计和步骤设计 -- 对测试点的细化
作用
- 测试用例是软件测试核心
- 评估测试结果的基准
- 保证测试的时候不遗漏测试功能点,避免漏测和错误测试
- 设计测试用例的过程,可以熟悉需求,对系统架构或者业务流程有一个整体的了解
- 在执行完测试用例之后,补充完善用例
 测试用例不是一次性就能写完的,需要一点点完善
测试用例八大要素(重要)
- 用例编号:产品名-测试阶段 -- st or uat
- 测试项目:对应一个功能模块(细化功能)
- 测试标题:直接对- 测试点进行- 细化得出,- 输入内容+结果,同一功能模块标题不能重复(来自测试点)
- 重要级别:- 高(high):核心功能 -- P1
- 中(medium):次要功能异常 -- P2
- 低(low):界面,不常用场景 -- P3
 
- 预置条件:需求满足一些前提条件,否则用例无法执行 -- 不是必填项
- 测试输入(数据):需要加工的输入信息,根据具体情况来设计(跟步骤结合起来一定要具有指导性意义)-- 数据构造
- 操作步骤:明确给出每一个步骤的描述,执行人员可以根据该步骤完成执行工作
- 预期结果:根据预期输出比对实际结果,来判断被测对象是否符合需求 -- 预期结果唯一,不能出现是否或者
- 实际结果:执行后的最终结果

测试用例编写原则
- 正常冒烟测试:详细到每一个步骤,进行预期结果的检查 -- 第一条用例比较多
- 后面用例,但凡跟第一个测试用例的点重复的话,去重,用到用例设计方法,细化,正常异常
编写测试用例步骤
- 分析需求
- 提取测试点
- 细化测试用例
测试用例评审
开会[开发,产品,测试]:用例讲解(测试点+思路+展示) -- 意见+建议 -- 会议记录 -- 修改用例 -- 二次用例评审 -- 评审通过
测试用例变更
由于需求变更,对于业务的不断深入了解和测试用例评审,测试用例是无法一次性全部写好的,所以,测试用例在完成之后是需要不断修正的
测试用例变更通常包含:
- 需求变动
- 执行完成后的用例完善
- 评审后的用例修改
备份测试用例文档
Q:公司就算没有时间,也会做用例评审吗?
A:发邮件(附件用例文档),开发,产品,测试,等待回复,规避责任
Q:如果时间紧急,来不及编写测试用例,怎么办?
A:直接写测试点,项目结束后,完善测试用例,归档
Q:用例的优先级依据什么来确定?有什么作用
A:制定执行策略依据
Q:如何编写测试用例?
A:分析需求-提取测试点-编写测试用例