测试过程中遇到的问题
- 不知道是否较全面的测试了所有功能
- 测试的覆盖率无法衡量
- 对新版本的重复测试很难实施
- 存在大量冗余测试影响测试效率
软件测试用例的作用
- 执行测试的有效依据(文档而非口头或主观)
- 追溯测试的有效依据(回归、缺陷分析)
- 衡量测试工作量的有效依据
- 衡量测试人员工作量和工作质量的依据
- 评估测试覆盖力度的依据
- 验证需求和寻找缺陷的重要手段
- 为新版本或其他项目参考和累积测试经验
软件测试用例的概念
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
解决要测什么、怎么测和如何衡量的问题
测试用例一般可以简单划分为：场景测试用例（简称“测试用例”）和 基本测试用例（或称为“公用测试用例”）
编写测试用例的优缺点
- 优点
- 组织性、有计划、规划、规范
- 有科学依据或经验支撑
- 避免重复、冗余，降低成本、提高效率
- 功能覆盖
- 可持续复用
- 跟踪
- 测试确认
- 缺点
- 测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
准备编写测试用例
- 收集资料
- 需求文档
- 设计文档
- 遗留系统相关文档
- 与相关人员讨论
- 探索性测试
- 把软件当产品说明书来对待，分步骤地逐项探索软件特性，记录软件执行情况，详细描述功能。
- 可以通过探索性测试来获得更多的需求。
- 可用于重现和分析缺陷、研究缺陷和程序其他模块的相关性
- 是测试用例有利的补充
- 具体问题具体分析
何时编写、修改测试用例
- 如果需求、设计缺失或不完整
在软件完成后编写用例 - 需求、设计完整:
熟悉需求、设计之后,在编码之前或实现过程中设计用例 - 软件代码、需求、设计变更后测试用例需要变更
- 执行用例过程中或执行之后需要适时调整、修改
测试用例的模版
Word
Excel
使用工具
根据公司、项目具体情况制定模版
设计测试用例所需要的素质
测试用例的方法
考虑问题的全面性
业务知识的深刻性
逆向思维能力
丰富的测试经验
测试用例的更新与维护
- 需要更新和维护的原因
- 需求变更，功能变化，测试用例也需要更新
- 测试用例需要细化和不断完善，是个循序渐进的过程
- 通过测试实践检验测试用例并添加、修改、删除测试用例
- 测试用例要经过正式、有效的评审
- 利用测试工具来管理测试用例