软件测试用例的编写（六）

软件测试用例

定义

测试用例（TestCase）是为项目需求而编制的一组测试输入，执行步骤，以及预期结果，以便测试某个程序是否满足客户需求
可以总结为：每一个测试点的数据设计和步骤设计 – 对测试点的细化

作用

• 测试用例是软件测试核心
• 评估测试结果的基准
• 保证测试的时候不遗漏测试功能点，避免漏测和错误测试
• 设计测试用例的过程，可以熟悉需求，对系统架构或者业务流程有一个整体的了解
• 在执行完测试用例之后，补充完善用例
  测试用例不是一次性就能写完的，需要一点点完善

测试用例八大要素（重要）

1. 用例编号：产品名-测试阶段 – st or uat
2. 测试项目：对应一个功能模块（细化功能）
3. 测试标题：直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复（来自测试点）
4. 重要级别：
   • 高(high)：核心功能 – P1
   • 中(medium)：次要功能异常 – P2
   • 低(low)：界面，不常用场景 – P3
5. 预置条件：需求满足一些前提条件，否则用例无法执行 – 不是必填项
6. 测试输入(数据)：需要加工的输入信息，根据具体情况来设计（跟步骤结合起来一定要具有指导性意义）-- 数据构造
7. 操作步骤：明确给出每一个步骤的描述，执行人员可以根据该步骤完成执行工作
8. 预期结果：根据预期输出比对实际结果，来判断被测对象是否符合需求 – 预期结果唯一，不能出现是否或者
9. 实际结果：执行后的最终结果

测试用例编写原则

1. 正常冒烟测试：详细到每一个步骤，进行预期结果的检查 – 第一条用例比较多
2. 后面用例，但凡跟第一个测试用例的点重复的话，去重，用到用例设计方法，细化，正常异常

编写测试用例步骤

1. 分析需求
2. 提取测试点
3. 细化测试用例

测试用例评审

开会[开发,产品,测试]：用例讲解(测试点+思路+展示) – 意见+建议 – 会议记录 – 修改用例 – 二次用例评审 – 评审通过

测试用例变更

由于需求变更，对于业务的不断深入了解和测试用例评审，测试用例是无法一次性全部写好的，所以，测试用例在完成之后是需要不断修正的

测试用例变更通常包含：

1. 需求变动
2. 执行完成后的用例完善
3. 评审后的用例修改

备份测试用例文档

Q：公司就算没有时间，也会做用例评审吗？
A：发邮件（附件用例文档），开发，产品，测试，等待回复，规避责任
Q：如果时间紧急，来不及编写测试用例，怎么办？
A：直接写测试点，项目结束后，完善测试用例，归档
Q：用例的优先级依据什么来确定？有什么作用
A：制定执行策略依据
Q：如何编写测试用例？
A：分析需求-提取测试点-编写测试用例