用例编写方法及管理流程说明

目目 录录 1 测试用例是软件测试的核心 2 2 什么是测试用例 2 3 测试用例的意义 3 4 如何设计测试用例 3 5 测试用例分析 4 6 有没有跳过一些测试 如果有 为什么 4 7 测试用例状态转换分析 5 8 黑盒测试的测试用例设计 7 9 传统的测试用例文档编写有两种方式 8 10 评价测试用例的好坏有以下两个标准 9 11 创建测试数据时主要考虑如下步骤 9 12 确定实际的测试数据时 必须说明处理测试数据的以下 4 个属性 9 13 辅助测试工具 9 14 执行测试 10 15 评估测试 10 16 覆盖评测 10 17 性能评测 11 18 测试的成功经验 11 19 测试种类 11 20 测试用例版本管理 11 21 软件测试流程 12 22 软件测试结果统计分析 13 24 回 归 测 试 16 25 测试策略 17 测试用例编写方法写及其管理流程测试用例编写方法写及其管理流程 1 测试用例是软件测试的核心 测试用例是软件测试的核心 如何以最少的人力 资源投入 在最短的时间内完成测试 发现软件系统的缺陷 保 证软件的优良品质 则是软件公司探索和追求的目标 测试用例是测试工作的指导 是软件测试的必须遵守的准则 更是软件测试质量稳定 的根本保障 2 什么是测试用例 什么是测试用例 所谓的测试用例就是将软件测试的行为活动 做一个科学化的组织归纳 软件测试是有组织性 步骤性和计划性的 而设计软件测试用例的目的 就是为了能 将软件测试的行为转换为可管理的模式 软件测试是软件质量管理中最实际的行动 同时也是耗时最多的一项 基于时间因素的考虑 软件测试行为必须能够加以量化 才能进一步让管理阶层掌握 所需要的测试过程 而测试用例就是将测试行为具体量化的方法之一 因为我们不可能进行穷举测试 为了节省时间和资源 提高测试效率 必须要从数量 极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试 目前研究室测试过程中 所有的测试用例都放在 测试大纲 中 使用测试大纲的好 处 保证测试功能不被遗漏 使得功能不被重复测试 合理安排测试人员 使得软件测试不依赖于个人 3 测试用例的意义 测试用例的意义 使用测试用例的好处主要体现在以下几个方面 在开始实施测试之前设计好测试用例 可以避免盲目测试并提高测试效率 测试用例的使用令软件测试的实施重点突出 目的明确 在软件版本更新后只需修正少部分的测试用例便可展开测试工作 降低工作强度 缩 短项目周期 功能模块的通用化和复用化使软件易于开发 而相对于功能模块的测试用例的通用化 和复用化则会使软件测试易于开展 并随着测试用例的不断精化其效率也不断攀升 组织性 有利于测试的组织 功能覆盖 确保功能不被遗漏 重复性 有利于测试的重复 跟踪 有利于测试的跟踪 测试确认 在少数高风险的测试中 必须证明确实执行了计划执行的测试 4 如何设计测试用例 如何设计测试用例 测试用例一般指对一项特定的软件产品进行测试任务的描述 体现测试方案 方法 技 术和策略 值得提出的是 测试数据都是从数量极大的可用测试数据中精心挑选出具有代 表性或特殊性的 测试用例是软件测试系统化 工程化的产物 而测试用例的设计一直是 软件测试工作的重点和难点 设计测试用例即设计针对特定功能或组合功能的测试方案 并编写成文档 测试用例应该 体现软件工程的思想和原则 测试用例应由测试人员在充分了解系统的基础上在测试之前设计好 测试用例的设计是 测试系统开发中一项非常重要的内容 集成测试阶段测试用例的设计依据为系统需求分析 系统用户手册和系统设计报告等相关资料的内容 而且测试人员要与开发人员充分交互 另外有一些内容由测试人员的相关背景知识 经验 直觉等产生 测试用例的设计需要考虑很周全 在测试系统功能的同时 还要检查系统对输入数据 合法值 非法值和边界值 的反应 要检查合法的操作和非法的操作 检查系统对条件 组合的反应等 好的测试用例让其他人能够很好地执行测试 能够快速地遍历所测试的功 能 能够发现至今没有发现的错误 所以测试用例应该由经验丰富的系统测试人员来编写 对于新手来说 应该多阅读一些好的测试用例 并且在测试实践中用心去体会 在编写测试用例之前 应该给出测试大纲 大纲基本上是测试思路的整理 以保证测试 用例的设计能够清晰 完整而不是顾此失彼 测试大纲可以按照模块 功能点 菜单和业 务流程这样的思路来策划 5 测试用例分析 测试用例分析 关于测试用例的分析 通常包括以下的内容 计划了多少个测试用例 实际运行了多少 有多少测试用例失败了 在这些失败的测试用例中 有多少个在错误得到修改后最终运行成功了 这些测试平均占用的运行时间比预期的长还是短 6 有没有跳过一些测试 如果有 为什么 有没有跳过一些测试 如果有 为什么 测试覆盖了所有影响系统性能的重要事件吗 等等 这些问题都可以从相关的测试用例的设计和测试问题记录中找到相应的答案 当然 如 果使用了数据库 这些问题就更能轻松地被解答了 测试用例的分析报告可以以多种形式 体现出来 文字描述 表 图等 用例编写方案用例编写方案 测试工作和开发通常一同进行 所以在完成测试计划编写后 就可以进行用例的编写 工作 测试和开发相对应的关系如表 开发阶段依据文档编写的用例 需求分析结束后需求文档系统测试对应的用例 概要设计阶段结束后概要设计 体系设计集成测试对应的用例 详细设计阶段详细设计文档单元测试对应的用例 测试用例各栏目列表如下 6 1 用例 ID 用于唯一标识测试用例号 可根据自身需要定义规则 最好易于跟踪和维 护 6 2 版本 软件版本号 6 3 作者 编写测试用例的人 6 4 测试时间 测试一条测试用例的相对时间 6 5 用例级别 按 ABC 三个等级定义 6 6 功能项 列出所测的功能项目 6 8 预置条条 列出用例的预置条件 6 9 测试目的 用例的测试目的 6 10 测试步骤 描述测试的过程 步骤或状态 6 11 预期结果 预料中与规格相符的正确结果 6 12 执行结果 实际测试结果 6 13 测试结论 对测试作最终结论 6 14 问题 ID 6 14 测试日期 6 15 测试人 6 16 备注 测试用例各阶段方法描述测试用例各阶段方法描述 第一阶段 冒烟测试 即版本确认测试 每个测试版本需通过所有该级测试用例 否则拒绝继续测试 至顶向底的测试方法 第二阶段 关键路径测试 每个测试版本需执行该级测试用例 若该级测试用例 均通过 意味着软件功能趋于稳定 至底向顶的测试方法 第三阶段 可接受级测试 该级测试用例只要执行一次通过即可 该级测试用例 通过意味着可以准备发布了 验收测试 如果有时间 最好执行该级测试用例 测试用例执行结果测试用例执行结果 执行时填写 分为通过 失败 警告 阻塞 忽略 测试用例覆盖率分析报告测试用例覆盖率分析报告 7 测试用例状态转换分析 测试用例状态转换分析 以下测试用例生命周期图显示了一个典型测试用例的生命周期 依据不同类型和规模的项 目可以自行定制 测试用例生命周期图 队列中 In Queue 测试用例在排队等待中 进程中 In Progress 表示测试正在进行 并且可能会持续一段时间 如果一个测试 花费的时间少于一天或两天 只需将它显示在处于排队状态 阻塞 Block 一些外部条件 如缺少部分功能 将无法执行测试 忽略 Skip 已经决定 或被告知 跳过这个测试用例 通过 Pass 终点状态 没问题 失败 Fail 测试用例执行出错 警告 Warn 结果处于 Pass 和 Fail 之间 错误严重性等级较轻 不影响功能和性能 关闭 Closed 以前识别出的错误都已经被修正 实际项目中 一个测试用例有多个执行步骤 每个步骤可能有不同结果 如步骤 1 通过 步骤 2 失败 步骤 3 被步骤 2 中的失败所阻塞 那么该测试状态如何 单纯指出这个测试 用例阻塞或失败都将遗漏重要的信息 因此必须指定双重状态 如 阻塞 失败 阻塞 警告 忽略 通过 忽略 关闭等 然而 如果显示十几个状态 则测试结果可能更难以解 释 如何使结果明了又能精确反映实际结果 需要精明选择包括哪些状态 举例 多媒 体播放测试用例 ID1 29 播放状态如下图 ID158 ID232 ID233 8 黑盒测试的测试用例设计 黑盒测试的测试用例设计 目前黑盒测试的测试用例设计方法有 4 5 种 8 1 等价类划分等价类划分 等价列划分设计方法是把所有可能的输入数据 即程序的输入域划分成若干部分 子集 然后从每一个子集中选取少量具有代表性的数据作为测试用例 等价类是指某个输入域的子集合 在该子集合中 各个输入数据对于揭露程序中的错误都 是等效的 并合理地假定 测试某等价类的代表值就等于对这一类其他值的测试 等价类划分有两种不同的情况 有效等价类和无效等价类 设计时要同时考虑这两种等价 类 干个无效等价类 从不同角度违反规则 6 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下 则应再将该等价类 进等价类中按以下的 3 个原则设计测试用例 为每一个等价类规定一个唯一的编号 设计一个新的测试用例 使其尽可能多的覆盖尚未被覆盖的有效等价类 重复这一步 直 到所有的有效等价类都被覆盖为止 设计一个新的测试用例 使其仅覆盖一个尚未被覆盖的无效等价类 重复这一步 直到所 有的无效等价类都被覆盖为止 举例多媒体测试用例 ID158 关于文件名的显示用例类 有效文件名 无效文件名 文件名长度等 8 2 边界值分析法边界值分析法 使用边界值分析方法设计测试用例 首先 应确定边界情况 通常输入和输出等价类 的边界 就是应着重测试的边界情况 其次 应但选取正好等于 刚刚大于或刚刚小于边 界的值作为测试数据 而不是选取等价类中的典型值或任意值作为测试数据 基于边界值分析方法选择测试用例的原则 1 如果输入条件规定了值的范围 应取刚达到这个范围的边界值 以及刚刚超过这个范 围边界的值作为测试输入的数据 2 如果输入条件规定了值的个数 应用最大个数 最小个数 比最小个数少一 比最大 个数多一的数作为测试输入的数据 3 根据规格说明的每个输出条件 使用前面的原则 1 4 根据规格说明的每个输出条件 使用前面的原则 2 5 如果程序的规格说明给出的输入域或输出域是有序集合 则应选取集合的第一个元素 和最后一个元素作为测试用例数据 6 如果程序中使用了一个内部数据结构 应当选择这个内部数据结构边界上的值作为测 试用例 7 分析规格说明 找出其他可能的边界条件 例如多媒体测试用例 ID161 8 3 错误推测法错误推测法 错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误 从而有针对性地 设计测试用例的方法 基本思路 列举出程序中所有可能有的错误和容易发生错误的特殊情况 根据他们选择测 试用例 例如 输入数据和输出数据为 0 的情况 下表为输出条件及相应的测试用例表 媒体播放器测试用例 ID224 ID225 ID226 8 4 因果图法因果图法 因果图法是一种适合于描述对于多种条件的组合 相应产生多个动作的形式的测试用例设 计方法 利用因果图生成测试用例的基本步骤 8 41 1 分析软件规格说明描述中那些是原因 那些是结果 并给每个原因和结果赋予一个 标识符 8 4 2 分析软件规格说明描述的语义 找出原因和结果之间 原因和原因之间的关系 根据 这些关系 画出因果图 8 4 3 在因果图上用一些记号表明约束或限制条件 8 4 4 把因果图转换为判定表 8 4 5 把判定表的每一列拿出来作为依据 设计测试用例 例如多媒体测试用例 ID108 140 以下为因果图建立的实例 A 根据因果图建立判定表 根据因果图建立判定表 按条件的各种组合情况产生对应的动作 原因 1 和原因 2 不能同时成立 故可排除这种情 况 从判定表可设计出测试用例 6 个测试用例是所需的数据 例如 有一个处理单价为 5 角钱的饮料的自动售货机软件测试用例的设计 其规格 说明如下 若投入 5 角钱或 1 元钱的硬币 押下 橙汁 或 啤酒 的按钮 则相应的饮料就送出 来 若售货机没有零钱找 则一个显示 零钱找完 的红灯亮 这时在投入 1 元硬币并押 下按钮后 饮料不送出来而且 1 元硬币也退出来 若有零钱找 则显示 零钱找完 的红 灯灭 在送出饮料的同时退还 5 角硬币 1 分析这一段说明 列出原因和结果 原因 1 售货机有零钱找 2 投入 1 元硬币 3 投入 5 角硬币 4 押下橙汁按钮 5 押下啤酒按钮 建立中间结点 表示处理中间状态 11 投入 1 元硬币且押下饮料按钮 12 押下 橙汁 或 啤酒 的按钮 13 应当找 5 角零钱并且售货机有零钱找 14 钱已付清 结果 21 售货机 零钱找完 灯亮 22 退还 1 元硬币 23 退还 5 角硬币 24 送出橙汁饮料 25 送出啤酒饮料 B 画出因果图 所有原因结点列在左 所有结果结点列在右边 C 由于 2 与 3 4 与 5 不能同时发生 分别加上约束条件 E D 因果图 9 传统的测试用例文档编写有两种方式 传统的测试用例文档编写有两种方式 一种是填写操作步骤列表 将在软件上进行的操作步骤一步一步详细记录下来 包括所 有被操作的项目和相应的值 另一种是填写测试矩阵 将被操作项作为矩阵中的一个字段 而矩阵中的一条条记录 则是这些字段的值 10 评价测试用例的好坏有以下两个标准 评价测试用例的好坏有以下两个标准 是否可以发现尚未发现的软件缺陷 是否可以覆盖全部的测试需求 11 创建测试数据时主要考虑如下步骤 创建测试数据时主要考虑如下步骤 识别测试资源 识别测试情形 排序测试情形 确定正确的处理结果 创建测试事务 12 确定实际的测试数据时 必须说明处理测试数据的以下确定实际的测试数据时 必须说明处理测试数据的以下 4 个属性 个属性 1 深度 2 宽度 3 范围 4 结构 13 辅助测试工具辅助测试工具 做软件测试通常需要以下一些基本工具 优秀的办公处理软件 秒表 错误跟踪系统 自动测试工具 软件分析工具 好的操作系统 多样化平台 14 执行测试执行测试 执行测试是执行所有的或选定的一些测试用例 并观察其测试结果的过程 尽管为执行 测试所做的准备和计划工作会贯穿于软件开发生命周期之中 但是执行测试往往都会在软 件开发生命周期的末期 或者接近末期进行 即在编码完成之后进行 由于测试过程一般 分成代码审查 单元测试 集成测试 系统测试和验收测试几个阶段 尽管这些阶段在实 现细节方面都不相同 但其工作流程方面却是一致 14 1 执行测试的过程由以下 4 个部分组成 输入 要完成工作所必须的入口标准或可交付的结果 执行过程 从输入到输出的过程或工作任务 检查过程 确定输出是否满足标准的处理过程 输出 推出标准或工作流程产生的可交付的结果 产品输入 产品输出 执行测试 检查测 试工作 工具 是 15 评估测试评估测试 软件测试的主要评测方法包括测试覆盖和质量评测 测试覆盖是对测试完全程度的评测 它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的 质量评测是对测试对象 系统或测试的应用程序 的可靠性 稳定性以及性能的评测 它建立在对测试结果的评 估和对测试过程中确定的变更请求 缺陷 分析的基础上 16 覆盖评测 覆盖评测 覆盖指标提供了 测试的完全程度如何 这一问题的答案 最常用的覆盖评测是基于需求 的测试覆盖和基于代码的测试覆盖 简而言之 测试覆盖是就需求 基于需求的 或代码 的设计 实施标准 基于代码的 而言的完全程度的任意评测 如用例的核实 基于需求的 或所有代码行的执行 基于代码的 16 质量评测 测试覆盖的评估提供对测试完全程度的评测 在测试过程中已发现缺陷的评估提供了最 佳的软件质量指标 17 性能评测性能评测 评估测试对象的性能行为时 可以使用多种评测 这些评测侧重于获取与行为相关的数 据 如响应时间 计时配置文件 执行流 操作可靠性和限制 18 测试的成功经验测试的成功经验 为了减少系统的开发费用 越早测试越好 这是多年来软件行业的一个成功经验 即在整 个软件开发生命周期中通过各种软件工程技术尽量早地完成各种软件测试任务 首先 软件的整个测试生命周期是与软件的开发生命周期基本平齐的过程 在软件开发生命周期中 软件是通过迭代来不断加以完善的 在这种环境中 对于每个作 为测试目标的工作版本 测试的生命周期还都必须具有一种迭代方法 对于针对每个工作 版本执行的测试 都做出了增补和改进 并累积为一个测试体 用于后续阶段的回归测试 19 测试种类测试种类 阶段和用例关系具体的关系如表所示 测试阶段测试类型执行人员 单元测试模块功能测试 包含部分接口 测试 路径测试 开发人员 集成测试接口测试 路径测试 含部分 功能测试 开员人员 如果测试人员 水平较较高的可以由测试 人员执行 系统测试功能测试 健壮性测试 性能 测试 用户界面测试 安全性 测试 压力测试 可靠性测试 测试人员 验收测试对于实际项目基本上同上 并 包含文档测试 对于软件产品 主要测试相关技术文档 测试人员 可能包含用户 20 测试用例版本管理 测试用例版本管理 版本管理是用例管理的核心部分 建议用 Visual sourcesafe 对用例进行控制 流 程如下 20 1 编写用例编写用例 测试工程师根据需求规约 概要设计 详细设计等文档编定测试用 20 2 用例评审用例评审 原则上用例象程序一样 要经过多次的修改才可以通过 实际工作中通 常进行一次 20 3 用例修改用例修改 评审结束后 需要根据评审意见进行修改 修改后通常不再进行评审 如果时间和人力充裕的情况下 对用例的评审就象测试开发部门的产品一样 要经过反复 的评评审和修改 然后正式投入使用 因为每次评审都可能有新的发现 20 4 使用用例使用用例 在执行任务时版本按制库取出用例 执行用例时建试超拔接在用例记录 上记录测试结果 这样做有两个好处 首先是下次测试时可以看见上次测试结果 可以起 一个提醒的作用 其次 可以统一把发现的缺陷输入到数据中 在输入时可以进行分析 同时避免输入重复的缺陷 每次使用后送入版本控制库 进行版本控制 20 5 用例升级用例升级 维护维护 随着软件的不断修改 升级 对应的用例也需要升级维护 针对同 一个项目 可以根据需求的变更不断进行维护 对于软件测试用例来说 就随着软件版本 的升级而用例的维护版本也要升级 测试用例和版本要做到一一对应 21 软件测试流程 软件测试流程 22 软件测试结果统计分析 软件测试结果统计分析 软件问题统计与分析 在对软件产品测试过程中发现的问题进行充分分析 归纳和总 结的基础上 由全体参与测试的人员完成 软件问题倾向分析表 对该软件或该类型系统 回归测试 制定测试计划 设计测试 实施测试 执行测试 评估测试 按版本统计结果 0 20 40 60 80 100 120 1 2 3 4 5 版本 Bug 数 软件产品在模块 功能及操作等方面出错倾向及其主要原因进行分析 软件问题倾向分析 表将为以后开发工作提供一个参考 使开发人员根据软件问题倾向分析表明确在开发过程 中应注意和回避的问题 该表也可为以后的测试工作明确测试重点提供依据 按版本统计结果按版本统计结果图表达的是软件的不同版本在测试时检测出的缺陷 Bug 数的对应关系 这里的版本指的是同一软件经过不同的测试阶段并修复 Bug 及作必要的调整后所产生的软 件产品 显然 该图所表达的测试结果的变化是非常理想的 日期统计日期统计结果表达的是在一个测试阶段所发现的缺陷数与测试日期之间的对应关系 测 试过程中所发现的缺陷是随着时间的推移而增多的 但一段时间后 测试所发现的缺陷增 加会渐缓 甚至没有增加 如果测试还在进行 那么表明 在现有测试用例 软硬件环境 及相关条件下已经很难再发现新的缺陷了 虽然可以肯定系统中仍然存在缺陷 那么这个 测试阶段应该考虑停止了 按等级统计图按等级统计图表达的是测试中所发现的不同等级的缺陷的数目 关于 A B C D 等级 或者还有 E F G 所表达的不同含义由相关测试和开发人员来制定 而这种按等 级的统计结果可以清楚地反映开发工作中的薄弱之处 日期 按日期统计结果 Bug 数 0 20 40 60 80 100 120 140 160 180 200 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 A B C D 按等级统计结果 等级 Bug 数 0 20 40 60 80 100 120 140 Bug 数 按原因统计结果 0 50 100 150 200 需求 设计 编码 测试 原因 Bug 数 按原因统计结果按原因统计结果 表达的是测试所发现的缺陷数目与究其原因缺陷所属的软件工程的不 同阶段之间的关系 这个图表会又一次验证软件工程的任何阶段都会有导致程序中产生错 误的因素 只是程度和数目不同而已 通过该图表的分析 可以清楚地看到 软件工程中 的哪个阶段更应该加强控制 按模块统计按模块统计 表达的是程序的不同模块与在其中所发现的缺陷数目之间的关系 缺陷的 产生有多方面的原因 但也可以从该图中反映出哪些程序员所开发的模块中 Bug 很多 而 另一些程序员的则很少 那么在相同的系统设计和工作条件下 这也反映了程序员的工作 能力或者责任感的不同 按公开关闭日期统计按公开关闭日期统计 表达的是在测试过程中每日发现的错误报告公开 关闭的对应关 系图 公开是指错误被发现并被公告 关闭则指错误已被处理完毕的状况 图中中间两条 粗线反映的是错误累计公开和累计关闭的实际状况 随着时间的推移 累计公开和累计关 闭的错误数目都是渐增的 但到某个时间点 两条曲线会会合 即累计公开的数目等于累 M1 M2 M3 M4 M5 M6 M7 M8 按模块统计 模块 Bug 数 0 10 20 30 40 50 计关闭的数目 那就是说所有发现的错误都得到了处理 错误原因根本分析 错误原因根本分析 表达的是错误原因分析 其中纵轴表达的是每类测试发现错误占所 有错误的百分比 可以看出 只有每个错误都被明确细致地归类后才能得到这样的分析图 表 也才能知道该从哪里去控制以减少错误的产生 23 测试测试 软件开发设计人员在软件开发设计时 不可能完全预见用户实际使用软件系统的情况 另外 一个软件产品可能拥有众多用户 不可能由每个用户验收 此时多采用称为 测试的过程 以发现那些似乎只有最终用户才能发现的问题 测试是在软件开发公司内模拟软件系统的运行环境下的一种验收测试 即软件开发公司 组织内部人员 模拟各类用户行为对即将面市的软件产品 称为 版本 进行测试 试图 发现并修改错误 经过 测试调整的软件产品称为 版本 紧随其后的 测试是指软件开发公司组织各方 面的典型用户在日常工作中实际使用 版本 并要求用户报告异常情况 提出批评意见 然后软件开发公司再对 版本进行改错和完善 所以 一些软件开发公司把 测试看成是对一个早期的 不稳定的软件版本所进行的验 收测试 而把 测试看成是对一个晚期的 更加稳定的软件版本所进行的验收测试 24 回 回 归归 测测 试试 回归测试是指软件系统被修改或扩充 如系统功能增强或升级 后重新进行的测试 是为了保证对软件所做的修改没有引入新的错误而重复进行的测试 每当软件增加了新的 功能 或者软件中的缺陷被修正 这些变更都有可能影响软件原有的功能和结构 24 1 回归测试技术和测试数据回归测试技术和测试数据 回归测试一般采用黑盒测试技术来测试软件的高级需求 而无须考虑软件的实现细节 也可能采用一些非功能测试来检查系统的增强或扩展是否影响了系统的性能特性 以及与 其他系统间的互操作性和兼容性问题 错误猜测在回归测试中是很重要的 错误看起来像是通过直觉发现软件中的错误或缺陷 实际上错误猜测主要来自于经验 测试者是使用了一系列技术来确定测试所要达到的范围 和程度 这些技术主要有 有关软件设计方法和实现技术 有关前期测试阶段结果的知识 测试类似或相关系统的经验 了解在以前的这些系统中曾在哪些地方出现缺陷 典型的产生错误的知识 如被零除错误 通用的测试经验规则 设计和引入回归测试数据的重要原则是 应保证数据中可能影响测试的因素与未经修改 扩充的原软件上进行测试时的哪些因素尽可能一致 否则要想确定观测到的测试结果是由 于数据变化还是很困难的 回归测试的范围回归测试的范围 在回归测试范围的选择上 一个最简单的方法是每次回归执行所有在前期测试阶段建立 的测试 来确认问题修改的正确性 以及没有造成对其他功能的不利影响 常用的用例选择方法可以分为以下 3 种 1 局限在修改范围内的测试 2 在受影响功能范围内回归 3 根据一定的覆盖率指标选择回归测试 24 2 回归测试人员回归测试人员 由于回归测试一般与系统测试和验收测试相关 所以要由测试组长负责 确保选择使用 合适的技术和在合理的质量控制中执行充分的回归测试 测试人员在回归测试工作中将设 计并实现测试新的扩展或增强部分所需的新测试用例 并使用正规的设计技术创建或修改 已有的测试数据 在回归测试过程中 测试过程由一个测试观察员来监控测试工作 在回归测试完成时测试 组组长负责整理并归档大量的回归测试结果 包括测试结果记录 回归测试日志和简短的 回归测试总结报告 24 3 下面简要介绍常用的下面简要介绍常用的 3 种排错方法 种排错方法 原始类排错方法是最常用也是最低效的方法 只有在万般无奈的情况下才使用它 主要思想是 通过计算机找错 回溯法能成功地用于程序的排错 归纳和演绎法采用 分治 的概念 首先基于错误出现有关的所有数据 假想一个 错误原因 用这些数据证明或反驳它 或者一次列出所有可能的原因 通过测试 一一排除 只要某次测试结果说明某种假设已呈现倪端 则立即精化数据 进一 步进行深入的测试 24 4 有问题提到 修改一处老问题可能引入几处新问题 有时程序越改越乱 但若能做有问题提到 修改一处老问题可能引入几处新问题 有时程序越改越乱 但若能做 到每次纠错前都细心注意以下到每次纠错前都细心注意以下 3 个问题 情况将大为改观 个问题 情况将大为改观 导致这个错误的原因在程序其他部分还可能存在吗 本次修改可能对程序中相关的逻辑和数据造成什么影响 引起什么问题 上次遇到的类似问题是如何排除的 25 测试策略 测试策略 测试策略描述测试小组用于测试整体和每个阶段的方法 要描述如何公正 客观地开展测 试 要考虑模块 功能 整体 系统 版本 压力 性能 配置和安装等各个因素的影响 要尽可能地考虑到细节 越详细越好 并制作测试记录文档的模板 为即将开始的测试做 准备 测试记录具体说明如下 相对日期的测试进度表相对日期的测试进度表 测试任务开始时间期限 测试计划完成说明书完成之后起 7 天4 周 测试案例完成测试计划完成12 周 第一阶段测试通过代码完成6 周 第二阶段测试通过Beta 构造6 周 第三阶段测试通过发布构造4 周 测试方法选择的综合策略 以下是各种测试方法选择的综合策略 可在实际应用过程中参考 首先进行等价类划分 包括输入条件和输出条件的等价划分 将无限测试 变成有限测试 这是减少工作量和提高测试效率的最有效方法 在任何情况下都必须使用边界值分析