软件测试技术基础讲义.ppt

白盒测试 分支/条件覆盖 分支覆盖+条件覆盖 条件组合覆盖 每个判定中各条件的每一种组合至少出现一次 路径覆盖 要求覆盖程序中所有可能的路径 白盒测试 循环测试 跳过这个循环 只循环一次 循环二次 循环N次 灰盒测试 基于白盒测试和黑盒测试之间 百盒测试使用代码 黑盒测试使用功能规格说明 使用可获得的关于系统的结构或设计信息 数据抽象 数据结构、内部状态、其他 例如，数组、链表、堆栈、队列、数据库、数据文件 代码抽象 软件架构、数据操作、算法、其他 例如，递归调用、堆栈操作 探查式测试 需求说明可能不清楚、不完整、需要探查 通过探查发现缺陷较多的部件，为确定测试重点提供依据 测试案例集覆盖的情况有限，需要补充 避免束缚与测试案例集，尽可能多地发现有价值的缺陷 从已知的缺陷和测试案例获得线索或启发，依据直觉或经验，进行探查以发现更多缺陷 探查式测试的步骤 收集和分析相关的信息，确定探查的范围和重点 拟出可能的探查方案 评估提出的探查方案，决定要采取的最佳方案 确定实施计划 实施探查方案，记录实施结果 判断是否进行下一轮探查 探查式测试的步骤 确定探查的范围和重点 由已有的软件工作产品分析 关键的功能部件，这些部件满足用户的关键的重要的需求 复杂的功能部件，这些部件包含复杂的计算或/和操作 出现问题较多的功能部件，这些部件中可能隐藏更多的质量问题 由已有的测试案例集和已发现的缺陷的报告分析 缺陷坐在德恭恩努间可能与其他那些功能部件相关？后者可能出现什么问题？ 发现缺陷后，后续操作是否可以执行？有什么问题吗？ 是否存在其它的同类操作或数据？他们有什么问题吗？ 已有测试案例是否有覆盖不足的问题？应补充什么测试案例？ 缺陷讨论会 定期抽出一些世安，例如每二周抽出一天时间，举行非正式的Bug讨论会 在会上针对测试问题进行自由的思考和联想，相互激发想象力，获得启发 轮流发言，提出关于测试策略的各种设想，并最终形成有效的测试策略 是否要书面纪录测试案例？为什么？ 更加周密地书写测试案例 便于评审 执行者和用例编写者可能不是一个人 回归测试 测试案例模版 编号 简要说明、优先级 前置条件及运行准备 运行步骤 预期运行结果 测试数据 运行后处理（环境恢复） 与其他测试案例的关系 运行状态、实际运行结果、测试员 测试案例的状态 未运行 最初所有测试案例处于未运行状态 不能运行 无法运行这个测试案例，可能是因为系统问题致使不能运行，也可能是测试案例未说明清楚或其他原因 通过 运行这个测试案例后观察到所有预期结果，即运行通过 失败 运行这个测试案例后发现缺陷，即运行未通过 测试案例与测试数据表 测试案例评审 完整性 测试案例集在组织结构，内容上的完整性 所包含的测试案例的内容的完整性 正确性 测试案例集及其测试案例在内容和形式上的正确性 经济性 测试案例的执行、分析在成本上比较经济 可读性 测试案例集及其测试案例的可理解性 其他 单元测试的目标 单元测试的质量要求 正确地实现规定的功能 错误处理正确 边界条件处理正确 达到预定的代码覆盖率 单元测试的目标 单元测试的质量要求 代码覆盖率目标 语句覆盖率100% 分支覆盖率100% 条件组合覆盖率50%以上（可选） 基本路径覆盖率100%（可选） 错误处理路径覆盖率100% 分离式单元测试 驱动模块 针对性地对部分模块进行测试 拥有方面快捷的输入界面，用来改变输入条件 容易开发/维护 对驱动模块进行配置管理 桩(stub)模块 减少工程上对其他产品的依赖性，达到并行开发的目的 排除其他模块对被测试模块的影响 对桩模块进行配置管理 单元测试实施 建立单元测试环境 执行单元测试 记录和跟踪软件缺陷 修复软件缺陷，进行回归测试 更新相关的软件文档 编写单元测试报告 评审和批准单元测试报告 软件缺陷报告 基本信息 缺陷编号、缺陷名称、测试版本 对应测试案例编号、缺陷状态、持有人 报告信息 报告者、报告日期、测试部件、缺陷起源 测试环境、重现性、重现步骤、缺陷描述及隔离 分类信息 严重等级、缺陷类型、建议优先级(报告者) 审定优先级（开发主管）、审定人 软件缺陷的分类---按严重等级 1级---缺陷导致了软件失败(崩溃)或无法操作 2级---缺陷导致了一个特性或功能不能实现并且不可能有替代方案，或者虽然有替代方案，但难以获得或代价较高 3级---缺陷导致了一个特性或功能不能实现，但有一个合理的或可接受的替代方案 4级---缺陷是表面化的或微小的 我们的软件缺陷的分类（参考） 1级---遗漏了式样书记述的功能 或者无法实现式样书中记述的功能。 2级---编写了式样书中记述的功能，虽然方式与式样书中的记述不一致，但是可以正常实现预期的功能。 3级---式样书中没有记述，但是会影响功能的正常实现，导致功能的可用