测试过程中遇到的问题
- 不知道是否较全面的测试了所有功能
- 测试的覆盖率无法衡量
- 对新版本的重复测试很难实施
- 存在大量冗余测试影响测试效率
- 容易出现漏测，重复测试
- 测试人员没有明确的工作目标，工作效率低
软件测试用例的概念
- 测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
- 测试用例一般可以简单划分为：场景测试用例（简称“测试用例”）和基本测试用例（或称为“公用测试用例”）
设计测试用例的方法
- 等价类
- 边界值
- 场景法
- 错误推断法
- 因果图
- 状态图
- 正交排列
- 路径覆盖
设计测试用例的优缺点
-
优点
- 有效性
- 完整性
- 组织性
-
缺点
- 测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
- 随着测试用例的不断积累，所带来的维护成本也会越来越高，维护难度也会逐渐增加
- 测试用例的执行效率低
- 需求的变更导致写的测试用例变的一文不值
测试用例的要素
测试用例的组成元素及作用
用例编号：该用例在整个测试套件中的编号
所属模块：测试用例所对应的测试模块
用例标题：清晰表达出该测试用例是测试什么问题的（包含测试目标/测试对象）
操作步骤：执行测试时的步骤
测试数据：测试用例执行时所需要使用的数据
预期结果：根据所输入的测试数据，期望得到怎么样的结果
实际结果：根据所输入的测试数据，实际得到的测试结果
编写人
编写时间
测试优先级：该用例执行的优先级
设计测试用例的基本原则
- 设计测试用例是为了找bug，找出产品中的缺陷，所以不能照搬需求规格说明书
- 设计正面的测试用例，需求规格说明书中必须满足的需求功能，覆盖率须达100%
- 设计反面／异常的测试用例，错误的，异常的测试用例
测试用例的作用
- 整个测试活动的基础
- 指导测试工程师完成测试任务的依据
- 测试结果是否通过的重要依据
- 有助于节省测试时间，提高测试效率
- 知识传递/逐渐完善/测试资源库
- 评估测试人员工作进度，工作量，以及跟踪/管理测试人员的测试安排或者调整
测试用例的管理
- TAPD
- 禅道
- JRA
- TestLink
- Excel
- 等等其他同类工具
设计测试用例所需要的素质
- 测试用例的方法
- 考虑问题的全面性
- 业务知识的深刻性
- 逆向思维能力
- 丰富的测试经验
测试用例的更新与维护
- 需要更新和维护的原因
- 需求变更，功能变化，测试用例也需要更新
- 测试用例需要细化和不断完善，是个循序渐进的过程
- 通过测试实践检验测试用例并添加、修改、删除测试用例
- 测试用例要经过正式、有效的评审
- 利用测试工具来管理测试用例
二八原则
-
80%的错误是由20%的模块引起的
- 站在用户角度，并非研发实现的角度，正确地选择重要模块作为测试重点，从而不偏离方向。
-
80%的测试成本花在20%的软件模块中
- 设计用例时需要将时间花倾斜在复杂的20%核心模块上，从而设计更高效的测试用例。
-
80%的测试时间花在20%的软件模块中
- 软件测试执行过程中需要将时间倾斜在重要模块的测试用例中，从而使测试更加有效，发现bug。
-
80%的bug总是出现在20%的模块