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