软件测试全程实践.PPT

软件测试全程实践 计算机系 功能测试用例设计方法(7) 场景 下图所示是ATM例子的流程示意图 功能测试用例设计方法(7) 场景 功能测试用例设计方法(7) 场景 测试用例表 功能测试用例设计方法(7) 场景 数据设计 一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。 测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据 功能测试用例设计方法(7) 场景—案例表 功能测试——案例评审规范（1） 评审技术 概念 同行评审：是一个总的概念，在实际执行时有不同的组织形式，有严格的，也有松散的。根据具体情况的不同，可以把同行评审分为走读（Walkthrough）、技术评审（TechnicalReview）、正规检视（Formal Inspection）。 同行评审的审计：是为了保证同行评审的正确执行和效率，需要对同行评审的执行进行评审和审计。其目的是要验证已计划的评审被执行了。评审或审计应当被计划并安排到测试计划中。 方法 评审方法主要有以下三种： 走读：走读的主要目标是发现测试计划、配置管理计划、需求列表、测试案例的缺陷、遗漏和矛盾的地方，以改进测试产品；考虑可替换及修改的实现方法。走读还有其他一些目的，包括：技术的交流、参与人员的技术培训、设计思想的介绍等。走读是同行评审三种形式中最自由的一种形式，其成员包括本身测试者和一个或多个项目评审人员。 技术评审：是由一个正式的组对测试产品进行评价。它确认任何与规格和标准及采用的测试技术不一致的地方或者在检查后给出可替换和修改的建议。技术评审严格程度没有像正规检视那么严格。技术评审的参与者包括测试者、测试技术领域内的专家和有着丰富测试经验的测试工程师。 正规检视：是在软件开发过程中进行的，发现、排除软件在开发周期各阶段存在的错误、不足的过程。是一种软件静态测试方法，其生存周期为软件的开发周期，应用于开发过程中产生的（非阶段性）软件文档和程序代码。 正规检视不同于其他类型的同行评审，它遵循一个严格的过程，人员经过培训，检视过程有评估标准，正规检视针对实际产品或过程中的产品，目的是发现存在的错误。正规检视的参加者来自开发部门、测试部门、质量保证部门和用户。正规检视比其他评审更严格、更容易组织、效率也更高。正规检视不能代替阶段评审、静态检查或者测试。 功能测试——案例评审规范（2） 案例评审目的 由于测试人员的案例编写风格不同,在编写案例过程中可能会出现测试技巧及方法、测试案件中输入项遗漏、重复案例、缺少案例、输写格式不统一、错别字、错误的操作序号、目录结构与层次不正确、用例编号与需求列表不能完全覆盖等诸多问题，因此采用走读（Walkthrough）和技术评审（Technical Review）的案例评审技术。 适用范围 此规范用于整个测试活动过程中，针对每一轮测试结束后每个人的案例评审或测试组内同行进行案例评审时需注意的方面。 参与人 测试工程师、项目经理、配置管理员。 功能测试——案例评审规范（3） 用例评审问题表 测试执行 目的 根据测试设计，完成测试的实施 入口准则 相应的测试设计已经确定 输入 测试设计、系统有关文档 活动 搭建测试环境 实施测试 记录测试结果（BUG，性能测试数据等） 讨论和确认测试发现的问题 出口准则 按照测试设计完成了所有测试，测试问题经过了确认 输出 测试问题记录 功能测试——执行 执行案例并准确记录相关内容： 记录案例执行时间 记录软件版本信息 实际运行结果 比较预期结果和实际结果是否一致，如不一致要对不一致进行描述并记录出现的问题 测试人 回归测试 目的 根据测试发现问题的修改情况和影响情况，对修改后的系统进行复测 入口准则 测试发现问题的修改及其影响情况已提交 回归测试的范围已经确定 输入 测试发现问题的修改及其影响说明 回归测试的范围 活动 分析测试范围和系统修改情况 修改测试设计 搭建测试环境 实施回归测试 记录测试结果（BUG，性能测试数据等） 讨论和确认回归测试的问题 出口准则 按照回归测试范围，完成了测试 输出 回归测试问题记录 测试总结 目的 对测试的结果进行总结，对系统的质量情况进行评价 入口准则 覆盖了所有的测试需求，并且按照合同和计划完成了要求的测试轮次 输入 测试发现问题 活动 对各种类型的测试进行总结，产生相应测试类型的测试报告 对整体测试情况进行综合，产生测试总结报告 内部评审 提交用户进行正式评审 出口准则 完成测试总结报告，并经过评审 输出 测试总结报告 测试报告（功能、性能等）