软件测试基础理论知识

精品文档 1欢迎下载 一 一 软件测试概论软件测试概论 1 11 1 基础概念基础概念 定义定义 软件测试是使用人工或者自动手段来运行或测试某个系统的过程 其目的 在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别 它是帮助识别开发完成 中间或最终的版本 的计算机软件 整体或部分 的正确度 完全度和质量的软件过程 内容内容 软件测试主要工作内容是验证 verification 和确认 validation 验证是保证软件正确地实现了一些特定功能的一系列活动 即保证软件做 了你所期望的事情 Do the right thing 确认是一系列的活动和过程 目的是想证实在一个给定的外部环境中软件 的逻辑正确性 即保证软件以正确的方式来做了这个事件 Do it right 软件测试的对象不仅仅是程序测试 软件测试应该包括整个软件开发期问 各个阶段所产生的文档 如需求规格说明 概要设计文档 详细设计文档 当 然软件测试的主要对象还是源程序 目的目的 软件测试的目的是想以最少的人力 物力和时间找出软件中潜在的各种错 误和缺陷 通过修正错误和缺陷提高软件质量 回避软件发布后由于潜在的软 件缺陷和错误造成的隐患带来的商业风险 软件测试的出发点就是质量 软件测试的一切工作应该围绕质量而开展 测试是保证质量的重要手段之一 测试本身就是为质量服务的 精品文档 2欢迎下载 原则原则 1 测试的标准是用户的需求 所有的软件测试都应追溯到用户需求 测试人员要始终站在用户的角度去 看问题 去判断软件缺陷的影响 系统中最严重的错误是那些导致程序无法满 足用户需求的缺陷 2 事先定义好产品的质量标准 有了质量标准 才能依据测试的结果对产品的质量进行正确的分析和评估 例如 进行性能测试前 应定义好产品性能的相关的各种指标 同样 测试用 例应确定预期输出结果 如果无法确定测试结果 则无法进行校验 3 应当 尽早地和不断地进行软件测试 作为测试者的座右铭 在软件开发生命周期早期引入的错误占软件过程中出现所有错误 包括最 终的缺陷 数量的 50 60 缺陷存在放大趋势 如需求阶段的一个错误可 能会导致 N 个设计错误 因此 越是测试后期 为修复缺陷所付出的代价就会 越大 4 制定测试计划 排除随意性 在进行实际测试之前 应制定良好的 切实可行的测试计划并严格执行 特别要确定测试策略和测试目标 测试计划应包括 所测软件的功能 输入和 输出 测试内容 各项测试的进度安排 资源要求 测试资料 测试工具 测 试用例的选择 测试的控制方法和过程 系统的配置方式 跟踪规则 调试规 则 以及回归测试的规定等以及评价标准 5 周密的测试用例 不可将测试用例抛开 要根据测试的目的 采用相应的方法去设计测试用例 从而提高测试的效 率 更多地发现错误 提高程序的可靠性 除了检查程序是否做了应该做的事 还要看程序是否做了不该做的事 不仅应选用合理的输入数据 对于非法的输 入也要设计测试用例进行测试 6 充分注意群集现象 抓住 80 20 原则可以有针对性的优化测试 在最短的时间内发现更多的问 题 同时也能保证测试者对测试过程的整体把握 特别是当项目时间紧 复杂 度高时 可以分时间 阶段 模块解决问题 是有效的解决问题的方式之一 精品文档 3欢迎下载 7 避免测试自己的程序 由于心理因素 人们潜意识都不希望找到自己的错误 基于这种思维定势 人们难于发现自己的错误 因此 软件开发者应尽量避免测试自己的产品 应由第三方来进行测试 当然开发者需要在交付之前进行相关的自测 一定程 度的独立测试 可以避免开发人员对自己代码的偏爱 可以更加高效的发现软 件缺陷和软件存在的失效 但独立测试不是完全的替代物 因为开发人员也可 以高效的在他们的代码中找出很多缺陷 在软件开发的早期 开发人员对自己 的工作产品进行认真的测试 这也是开发人员的一个职责之一 8 完全测试是不可能的 测试需要终止 穷尽测试是不可能的 应结合当前实际情况当满足一定的测试出口准则时 测试就应当终止 9 回归测试 修改程序后 应该重新进行测试以确认修改没有引入新的错误或导致其他 代码产生错误 10 妥善保存一切测试过程文档 1 21 2 软件测试要素软件测试要素 1 质量 软件质量是软件测试的目标 也是软件测试工作的中心 一切从 质量出发 也就是一切从客户需求出发 任何违背质量的东西都是问题 测试就是要找出这些问题 2 人员 人是决定的因素 测试人员的态度 素质 能力决定着测试 的效果 对测试产品的质量也有很大的影响 测试人员因素包括测试组 织结构 角色和责任的定义 3 技术 软件测试技术 包括方法 工具 4 资源 主要是指测试环境中所需要的硬件设备 网络环境 甚至包 括测试数据 另外一个重要因素就是测试时间 时间也是测试的资源 但测试人员不能看做资源 每个人的能力千差万别 不同的测试人员担 任不同的角色 不能相互代替 这也是软件图书的经典之作 人件 的作者反对将人作为资源对待的原因 精品文档 4欢迎下载 5 流程 从测试计划和测试用例的创建 评审到测试的执行 报告 设定每个阶段的进出标准 1 31 3软件测试与质量保证软件测试与质量保证 1 3 11 3 1 软件质量软件质量 软件产品质量评价国际标准 ISO 14598 把软件质量定义为 软件特性的总 和 软件满足规定或潜在用户需求的能力 上述定义反应如下 3 个方面的问题 1 软件需求是度量软件质量的基础 2 软件人员必须遵循软件过程的规范 3 如果软件只是满足规定的需求 而不能满足可能存在的隐含需求 软件 质量也不能保证 1 3 21 3 2 软件测试与软件质量保证的区别软件测试与软件质量保证的区别 软件测试只是质量保证工作中的一个环节 软件质量保证与软件测试是软 件质量工程的两个不同层面的工作 质量保证是通过预防 检查与改进来保证软件质量 采用全面质量管理和 过程改进的原理来开展质量保证工作 主要关注软件质量的检查与测试 主要 着眼于软件开发活动的过程 步骤和产物 软件测试是通过执行软件来对过程 中的产物 开发文档和程序 进行走查 发现问题 报告质量 具体说来 软件测试盒软件质量保证的区别体现在 从性质上看 软件测 试属于技术性工作 而软件质量保证属于管理性工作 从对象上看 软件测试 的对象是软件产品 而质量保证的对象是整个软件过程 覆盖公司层面的各个 领域 从手段上看 软件测试以事后检验为主 而软件质量保证则强调缺陷的 预防 质量不是测试人员测试出来的 糟糕的早期设计结合最优的后期质量保证 往往颇费力气 仍然打造不出用户满意度高的产品 精品文档 5欢迎下载 二 二 软件测试过程管理软件测试过程管理 2 12 1 测试团队测试团队 2 1 12 1 1 测试团队的基本责任测试团队的基本责任 1 发现软件程序 系统或产品中所有的问题 2 尽早地发现问题 3 督促和协助开发人员尽快地解决程序中的缺陷 4 帮助项目管理人员制定合理的开发计划 5 对缺陷进行跟踪 分析和分类总结 以便让项目的管理人员和相关 的负责人员能够及时 清楚地了解产品当前的质量状态 6 帮助改善开发流程 调高产品开发效率 7 促进程序编写的规范性 易读性 可维护性等 2 1 22 1 2 测试团队的组成测试团队的组成 如何组织一个测试团队 应当视企业的人力资源而定 一般 一个比较健全的测试组 所具有的角色包括测试组长 实验室管理 人员 自动化测试工程师 资深测试工程师 初级测试工程师 测试组长测试组长 业务专家 负责项目的管理 测试计划的制定 项目文档的审 查 测试用例的设计和审查 任务的安排 与项目经理和开发组长的沟通等 实验室管理人员实验室管理人员 设置 配置和维护实验室的测试环境 主要是服务器和 网络环境等 资深测试工程师资深测试工程师 负责产品设计规格说明书的审查 测试用例的设计和技 术难题的解决 主要参与数据库 系统性能和安全性等技术难度较高的测试 自动化测试工程师自动化测试工程师 负责测试工具的开发 测试脚本的开发等 初级测试工程师初级测试工程师 执行测试用例和相关的测试任务 侧重功能测试用例的 设计和执行 精品文档 6欢迎下载 2 1 32 1 3 软件测试团队与开发团队的关系软件测试团队与开发团队的关系 软件测试与软件开发具有天然的联系 软件测试的输入是软件开发的产品 测试输出的结果需要开发人员相应处理 处理后的结果再次需要测试人员的验 证 因此 软件测试与软件开发如影相随 互为服务对象 开发人员和测试人员需要不断的沟通合作 才能持续优化项目 对于开发 人员而言 利用测试人员对需求的理解 越早将测试提到项目周期 帮助就越 大 对于测试人员而言 搞好和开发人员的关系 则可以在测试方向上获得更 多的帮助 编写测试用例时询问可能遗漏的用例 在测试即将结束时询问测试 是否有风险 2 22 2 软件测试风险分析软件测试风险分析 1 风险类型 项目风险 指潜在的预算 进度 人力 资源 客户 需求等方面的问题 以及它们对软件项目的影响 技术风险 指潜在的设计 实现 接口 验证和维护等方面的问题 商业风险 商业风险威胁到要开发软件的生存能力 2 识别风险 识别风险是试图系统化地确定对项目计划的威胁 识别风险的一个方法是 建立风险条目检查表 检查表包括 产品规模 与要建造或要修改的软件的总体规模相关的风险 商业影响 与管理或市场所加诸的约束相关的风险 客户特性 与客户的素质以及开发者和客户定期通信的能力相关的风险 过程定义 与软件过程被定义的程度以及它们被开发组织所遵守的程度相 关的风险 开发环境 与用以建造产品的工具的可用性及质量相关的风险 建造的技术 与待开发软件的复杂性及系统所包含技术的 新奇性 相关 的风险 人员数目及经验 与参与工作的软件工程师的总体技术水平及项目经验相 关的风险 精品文档 7欢迎下载 3 评估风险影响 风险的性质 当风险发生时可能产生的问题 风险的范围 结合了严重性及整体分布情况 风险的时间 主要考虑何时能够感到风险 风险会持续多长时间 4 风险应对 风险分析活动的目的是辅助项目组建立处理风险的策略 一个有效的策略 必须考虑如下 3 各问题 风险避免 风险监控 风险管理及意外事件计划 2 32 3 软件测试成本管理软件测试成本管理 测试费用有效性测试费用有效性 测试的策略由商业的经济利益来决定 对风险测试过少 会造成软件的缺 陷和系统的瘫痪 测试的过多 会增加测试成本 下图的测试费用 质量曲线可 以形象的表示测试费用的有效性 测试成本测试成本 测试实施成本 测试准备成本 测试执行成本 测试结束成本 缺陷探测率缺陷探测率 精品文档 8欢迎下载 缺陷探测率 DDP 是另一个衡量测试工作效率的软件质量成本的指标 缺陷探测率 DDP Bugs tester Bugs tester Bugs customer 缺陷探测率越高 也就是测试者发现的错误多 发布后客户发现的错误就 越少 降低了外部故障不一致成本 达到节约总成本的目的 可获得较高的测 试投资回报率 精品文档 9欢迎下载 三 三 测试流程测试流程 3 13 1 测试过程测试过程 软件测试过程一般包括 测试计划 测试设计 测试准备 测试执行 测试 评估和缺陷跟踪等阶段 每个阶段都有一系列的任务 测试过程具有以下几个特点 1 测试工作开始于需求分析之后 2 测试经过评估后 达到了结束的标准后才能结束 3 测试也是迭代过程 4 测试需求来自于软件需求 5 测试过程与开发过程的关系 6 都是软件过程的有机组成部分 7 测试过程与开发过程同步进行 8 测试过程与开发过程相互依赖 又相互独立 9 开发过程 测试过程 项目管理过程以及其他支撑过程相互交织共 同组成了软件过程 开开发发生生命命周周期期 维护 需求定义应用定义 应用开发 修订 建立建立 测测试试生生命命周周期期 执行 执行执行 测试计划 缺陷跟踪 测试开发 测试设计 评估 精品文档 10欢迎下载 3 23 2 测试过程的常见模型测试过程的常见模型 3 2 13 2 1 V V 模型模型 映出了测试活动与分析设计活动的关系 从左到右描述了基本的开发过程 和测试行为 非常明确的标注了测试过程中存在的不同类型的测试 并且清楚 的描述了这些测试阶段和开发过程期间各阶段的对应关系 但 V 模型存在一定的局限性 它仅仅把测试作为在编码之后的一个阶段 是针对程序进行的寻找错误的活动 而忽视了测试活动对需求分析 系统设计 等活动的验证和确认的功能 3 2 23 2 2 W W 模型模型 精品文档 11欢迎下载 W 模型强调 测试伴随着整个软件开发周期 而且测试的对象不仅仅是程 序 需求 设计等同样要测试 也就是说 测试与开发是同步进行的 W 模型 有利于尽早地全面的发现问题 但 W 模型也存在局限性 在 W 模型中 需求 设计 编码等活动被视为串 行的 同时 测试和开发活动也保持着一种线性的前后关系 上一阶段完全结 束 才可正式开始下一个阶段工作 这样就无法支持迭代的开发模型 3 2 33 2 3 H H 模型模型 H 模型将测试活动完全独立出来 形成了一个完全独立的流程 将测试准 备活动和测试执行活动清晰地体现出来 测试准备和测试执行分离 有利于资 源调配 降低成本 调高效率 有组织 结构化的独立流程 有助于跟踪测试 投入的流向 H 模型还充分体现了测试过程 不是技术 的复杂性 精品文档 12欢迎下载 四 四 测试技术测试技术 4 14 1软件测试类型软件测试类型 4 1 14 1 1 按测试阶段划分按测试阶段划分 单元测试单元测试 1 定义 又称模块测试 是针对软件设计的最小单位程序模块进行正确性 检查的测试工作 可以从程序的内部结构出发设计测试用例 多个模块 测试可以平行地独立进行测试 2 目的 发现模块内部可能存在的各种差错 3 内容 模块接口测试 IO 测试 数据的流入流出 局部数据结构 测试 路径测试 错误处理测试 边界测试 4 步骤 利用设计文档设计测试用例 创建被测模块的桩模块或驱动 模块 利用被测试模块 驱动模块和桩模块来建立测试环境 进行测试 集成测试集成测试 1 定义 又称组装测试或联合测试 在单元测试基础上 将所有模块按概 要设计和详细设计进行组装 2 目的 发现模块连接中的接口可能存在的各种差错 3 内容 穿越模块之间的数据是否会丢失 一个模块组装后是否会对另一模块或其他模块存在影响 各个子功能组装在一起是否会达到预期的父功能 全局数据结构是否有问题 单个模块的错误累积起来是否会放在 4 组装方法 包括一次性组装方式 增殖式组装方式两种组装方法 5 完成标志 成功地执行了测试计划中规定的所有测试用例 修正了 所发现的错误 测试结果通过专门小组的评审 精品文档 13欢迎下载 确认测试确认测试 1 目的 验证软件的功能和性能及其他特性是否与用户的要求一致 2 测试内容 验证所测软件是否满足需求规格说明书列出的需求 所 有文档正确且便于使用 软件可移植性 易用性 兼容性进行测试 软 件配置复查 保证软件配置的所有成分都齐全 系统测试系统测试 1 目的 验证和确认系统是否达到其原始目标 而对集成的硬件和软件系 统进行的测试 2 测试内容 在真实或模拟系统运行环境下 检查完整的程序系统能 否和系统 硬件设备 网络 系统软件 正确配置 连接 满足用户需 求 验收测试验收测试 1 测试目的 在用户环境中进行测试 以确定系统和产品是否能够满足合 同或用户所规定的需求 2 测试内容 根据任务书或合迥 供需双方约定的验收依据文档进行 对整个系统的测试与评审 确认是否接收或拒绝系统 4 1 24 1 2 按测试实施组织划分按测试实施组织划分 产商产商测试测试 开发方测试通常也叫 验收测试 或 a 测试 在软件开发环境中 开发者检 测与证实软件的实现是否满足软件设计说明或软件需求说明的要求 用户测试用户测试 在用户的应用环境下 用户检测与核实软件实现是否符合自己预期的要求 测试通常被认为是用户测试 把软件有计划地免费地分发到目标市场 让 用户大量使用 评价检查软件 精品文档 14欢迎下载 第三方测试第三方测试 由第三方测试机构来进行的测试 也称独立测试 4 1 34 1 3 按测试方法划分按测试方法划分 静态测试静态测试 静态测试又称为静态分析技术 不执行被测试软件 对需求分析说明书 软件设计说明书 源程序做结构检测 流图分析 符号执行等找出软件的错误 动态测试动态测试 通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序 而 达到发现程序错误的过程 4 1 44 1 4 按测试技术划分按测试技术划分 白盒测试白盒测试 白盒测试也称为结构测试或逻辑驱动测试 是通过对程序内部结构的分析 检测来寻找问题 检查程序的结构及路径是否正确 检查程序的内部动作是 否按照设计说明的规定正常进行 黑盒测试黑盒测试 黑盒测试又称功能测试 通过运行程序发现其缺陷和错误 黑盒测试是对 程序接口进行的测试 它只检查程序功能是否能按照规格说明书的规定正常使 用 程序是否能适当地接收输入数据产生正确的输出信息 并且保持外部信息 的完整性 灰盒测试灰盒测试 介于白盒和黑盒测试之间 关注输出对于输入的正确性 也关注程序的内 精品文档 15欢迎下载 部结构 但没有白盒测试那样详细 完整 4 24 2 白盒测试白盒测试 4 2 14 2 1 白盒测试方法白盒测试方法 4 2 1 1代码检查法代码检查法 检查内容检查内容 代码检查包括桌面检查 代码审查和走查等方式 主要对以下内容进行检 查 检查代码和设计的一致性 代码对标准的遵循 可读性 代码逻辑表达的正确性 代码结构的合理性 程序编写与编写标准的符合性 程序中不安全 不明确和模糊的部分 编程风格问题等 检查方式检查方式 1 桌面检查 由程序员对源程序代码进行分析 检验 并补充相关的文档 发现程序中的错误 2 代码审查 由程序员和测试员组成的审查小组通过阅读 讨论和争 议 以程序进行静态分析的过程 3 走查 程序员和测试员组成的审查小组通过逻辑运行程序 发现问 题 检查项目检查项目 检查变量的交叉引用表 检查未说明的变量和违反了类型规定的变量 变 量的引用和使用情况 精品文档 16欢迎下载 检查标号的交叉引用表 验证所有标号的正确性 检查子程序 宏 函数 验证每次调用与所调用位置是否正确 调用的子 程序 宏 函数是否存在 参数是否一致 等价性检查 检查全部等价变量的类型的一致性 常量检查 确认常量的取值和数制 数据类型 标准检查 检查程序中是否违反标准的问题 风格检查 检查程序的设计风格 比较控制流 比较设计控制流图和实际程序生成的控制流图的差异 选择 激活路径 在设计控制流图中选择某条路径 到实际的程序中激活 这条路径 如果不能激活 则程序可能有错 对照程序的规格说明 详细阅读源代码 比较实际的代码 从差异中发现 程序的问题和错误 4 2 1 2静态结构分析法静态结构分析法 在静态结构分析中 测试者通过使用测试工具分析程序源代码的系统结构 数据结构 数据接口 内部控制逻辑等内部结构 生成函数调用关系图 模 块控制流图 内部文件调用关系图等各种图形图表 清晰地标识整个软件的组 成结构 便于理解 通过分析这些图表 检查软件有没有存在缺陷或错误 主 要包括控制流分析 数据据流分析 接口分析 表达式分析 4 2 1 3代码代码质量度量法质量度量法 代码质量度量法即根据 ISO 9126 质量模型的 6 个方面 即功能性 可靠性 易使用性 效率 可维护性 可移植性 对软件进行的动态测试方法 白盒 测试的动态测试包括功能确认与接口测试 覆盖率分析 性能分析 内存分析 等 动态测试通常在静态测试之后进行 白盒测试的动态测试要根据程序的控 制结构设计测试用例 其原则是 保证每个模块的所有独立路径至少被使用一次 对所有的逻辑值均测试 true 和 false 上下边界及可操作范围内运行所有循环 精品文档 17欢迎下载 检查内部数据结构以确保其有效性 4 2 24 2 2 白盒测试综合策略白盒测试综合策略 1 在测试中 首先尽量使用测试工具进行静态结构分析 2 采用先静态后动态的组合方式 先进行静态结构分析 代码检查 和静态质量度量 然后现进行覆盖测试 3 利用静态结构分析的结果 通过代码检查和动态测试的方法对结果 进一步确认 使测试工作更为有效 4 覆盖率测试是白盒测试的重点 使用基本路径测试达到语句覆盖标 准 对于重点模块 应使用多种覆盖标准衡量代码的覆盖率 5 不同测试阶段 侧重点不同 单元测试 以代码检查 逻辑覆盖 集成测试 增加静构结构分析 静态质量度量 系统测试 根据黑盒测试结果 采用白盒测试 4 34 3 黑盒测试黑盒测试 4 3 14 3 1 黑盒测试方法黑盒测试方法 4 3 1 1等价类划分法等价类划分法 1 划分基础 需求规格说明书中输入 输出要求 2 等价类 某个输入域的子集合 分为有效等价类和无效等价类 有效等价类 指对于程序规格说明书来说是合理的 有意义的输入数据构 成的集合 利用有效等价类可以检验程序是否实现了规格说明书中的功能和性 能 无效等价类 与有效等价的定义恰巧相反 3 划分等价类原则 序号序号输入条件 数据 输入条件 数据 划分等价类划分等价类 1 规定了取值范围 值的个数 一个有效等价类 两个无效等价类 2 规定了输入值的集合 规定了 必须如何 的条件 一个有效等价类 一个无效等价类 精品文档 18欢迎下载 序号序号输入条件 数据 输入条件 数据 划分等价类划分等价类 3 是一个布尔量 一个有效等价类 一个无效等价类 4 输入数据的一组值 n 个 并且程序对每一 个输入值分别进行处理 n 个有效等价类 一个无效等价类 5 规定必须遵守的规则 一个有效等价类 符合规则 若干个无效等价类 6 在确知已划分的等价类中 各元素在程序处理中的方式不同的情况下 则应 再将该等价类进一步地划分为更小的等价类 4 确定测试用例步骤 第一步 为每个等价类规定一个惟一的编号 第二步 设计一个新的测试用例 使其尽可能多地覆盖尚未覆盖的有效等 价类 重复这一步骤 最后使得所有有效等价类均被测试用例所覆盖 第三步 设计一个新的测试用例 使其只覆盖一个无效等价类 重复这一 步骤 最后使得所有有效等价类均被测试用例所覆盖 4 3 1 2边界值分析法边界值分析法 1 边界类型 边界条件 可以在产品说明书中有定义或者在使用软件过程中确定 次边界条件 在软件内部 也称为内部边界条件 其他边界条件 如输入信息为空 对于此类问题应建立单独的等价类空 间 非法 错误 不正确和垃圾数据 2 边界值的选择方法 序号序号输入条件 数据 输入条件 数据 输入边界值数据输入边界值数据 1 规定了取值范围 刚刚达到这个范围 刚刚超越这个范围 2 规定值的个数 最大个数 比最大个数大 1 最小个数 比最小个数少 1 3 根据规格说明书的每个输出条件 使用 原则 1 2 4 输入或输出是个有序集合集合的第一个 最后一个元素 5 程序中使用一个内部数据结构内部数据结构边界上的值 6 分析规格说明 找出其他可能的边界 4 3 1 3错误推测法错误推测法 错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误 有 精品文档 19欢迎下载 针对性地设计测试用例的方法 错误推测法的基本思想是列举出程序中所有可 能有的错误和容易发生错误的特殊情况 根据它们选择测试用例 4 3 1 4因果图法因果图法 因果图法是从用自然语言书写的程序规格说明的描述中找出因 输入条件 和果 输出条件 通过因果图转换成判定表 4 3 1 5判定表驱动法判定表驱动法 判定表是分析和表达多逻辑条件下执行不同操作的情况的工具 适合使用判定表设计测试用例的条件 规格说明以判定表的形式给出 或很容易转换成判定表 条件的排列顺序不影响执行哪些操作 规则的排列顺序不影响执行哪些操作 当某一规则的条件已经满足 并确定要执行的操作后 不必检验别的规则 如果某一规则要执行多个操作 这些操作的执行顺序无关紧要 4 3 1 6正交试验法正交试验法 正交试验法从大量的试验数据中挑选适量的 有代表性的点 从而合理地 安排测试的一种科学的试验设计 正交试验法在软件测试中是一种有效的方法 例如在平台参数配置方面 每个参数就是一个因子 参数的不同取值就是水平 这样我们可以采用正交试验法设计出最少的测试组合 达到有效的测试目的 正交试验法有如下优点 节省测试工时 可控制生成的测试用例的数量 测试用例具有一定的覆盖率 4 3 1 7功能图法功能图法 一个程序的功能说明通常有动态说明和静态说明组成 动态说明描述了输 入数据的次序或转移的次序 静态说明描述了输入条件与输出条件之间的对应 精品文档 20欢迎下载 关系 对于较复杂的程序 由于存在大量的组合情况 仅用静态说明组成的规 格说明对于测试来说是不够的 必须用动态说明来补充功能说明 功能图法是 用功能图形形象地表示程序功能说明 并机械的生成功能图的测试用例 功能图方法实际上是一种白盒和黑盒相混合的用例设计方法 要用到逻辑 覆盖和路径测试的概念和方法 4 3 1 8场景法场景法 现在的软件几乎都是用事件触发来控制流程的 事件触发时的情景便形成 了场景 而同一事件不同的触发顺序和处理结果就形成事件流 这种在软件设 计方面的思想也可以引入到软件测试中 可以比较生动地描绘出事件触发时的 情景 有利于测试设计者设计测试用例 同时使测试用例更容易理解和执行 4 3 24 3 2 黑盒测试用例设计方法的选择策略黑盒测试用例设计方法的选择策略 1 首先进行等价类划分 包括输入条件和输出条件的等价类划分 将无限 测试变成有限测试 这是减少测试量和提高测试效率的最有效办法 2 在任何情况下都必须使用边界值分析方法 此方法设计的测试用例 发现程序错误的能力最强 3 可以用错误和推测法追加一些测试用例 4 对照程序的逻辑 检查已设计的测试用例的逻辑覆盖度 如果没有 达到要求 应在补充 5 如果程序的功能说明中含有输入条件的组合情况 一开始就可以使 用因果图法和判定表驱动法 6 对于参数配置类的软件 要用正交试验法选择较少的组合方式达到 最佳效果 7 功能图法也是很好的测试用例设计方法 我们可以通过不同时期条 件的有效性设计不同的数据 8 对于业务流清晰的系统 可以利用场景法贯空整个测试案例过程 在案例中综合使用各种方法 精品文档 21欢迎下载 4 44 4 自动化测试自动化测试 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程 通常 在设计了测试用例并通过评审之后 由测试人员根据测试用例中描述的规程一 步步执行测试 得到实际结果与期望结果的比较 在此过程中 为了节省人力 时间或硬件资源 提高测试效率 便引入了自动化测试的概念 精品文档 22欢迎下载 五 五 测试用例设计测试用例设计 5 15 1 测试用例设计原则测试用例设计原则 1 单个用例覆盖最小化原则 这条原则是所有这四条原则中的 老大 也是在工程中最容易被忘记和忽 略的 它或多或少的都影响到其它几条原则 测试用例的覆盖边界定义更清晰 则测试结果对产品问题的指向性更强 测试用例间的耦合度最低 则彼此之间的干扰也就越低 上述这些优点所能带来直接好处是 测试用例的调试 分析和维护成本最 低 每个测试用例应该尽可能的简单 只验证你所要验证的内容 2 测试用例替代产品文档功能原则 通常我们会在开发的初期 Scrum 每个 Sprint 的头两天 用 Word 文档或 者 OneNote 的记录产品的需求 功能描述 以及当前所能确定的任何细节等信 息 勾勒将要实现功能的样貌 便于团队进行交流和细化 并在团队内达成对 产品功能共识 但随着产品开发深入 团队会对产品的功能有更新的认识 产 品功能也会被更具体细化 在一个迭代或者 Sprint 结束的时候最终实现的功能 很可能是 A 如此往复 在不断倾听和吸收用户的反馈 多个迭代过后 原本 被描述为 A 的功能很可能最终变为了 Z 这是时候再去看看曾经的 Word 文档和 OneNote 页面 它们仍然记录的是 A 之所以会这样 是因为很少有人会去以 及能够去不断地去更新那些文档 以准确地反映出功能当前准确的状态 3 单次投入成本和多次投入成本原则 成本永远是任何项目进行决策时所要考虑的首要因素 项目中的测试也是 如此 对成本的考虑也应该客观和全面的体现在测试的设计 执行和维护的整 个阶段中 测试中的成本按其时间跨度可以分为 单次投入成本和多次投入成本 例 如 编写测试用例可以看作是单次投入成本 因为编写测试用例一般是在测试 的计划阶段进行 Scrum 每个 Sprint 的开始阶段 的 虽然后期会有小的改动 但绝大多数是在一开始的设计阶段就基本上成型了 精品文档 23欢迎下载 4 使测试结果分析和调试最简单化原则 这条原则实际上是单次投入成本和多次投入成本原则 针对自动化测试用 例的扩展和延续 在编写自动化测试代码时 要重点考虑如何使得测试结果分 析和测试调试更为简单 包括 用例日志 调试辅助信息输出等 5 25 2 测试用例设计方法测试用例设计方法 5 2 15 2 1 常用方法常用方法 1 等价类划分 2 边界值分析 3 错误推测 4 因果图 5 判定表驱动分析 6 正交实验设计 7 功能图法 8 场景设计法 5 2 25 2 2 测试用例设计角度测试用例设计角度 1 从需求到测试用例 从用户需求出发 了解功能设计背景 针对不同的功能特性会有多种用例 而每个用例有可以有多个不同的应用场景 所以 从需求到功能 从功能到 用例 从用例到场景 可以逐步分解 形成一对多的关系 最后为每个应用场 景设计一个到多个测试用例 2 基于流程图设计测试用例 从程序流程图到业务流程图 针对功能测试用例 要从业务流程图着手 把业务需求转化为流程图 根据业务流程图设计测试用例 逐层细化业务流程 并根据业务流程设计测试用例 3 基于 UML 视图设计测试用例 精品文档 24欢迎下载 UML Unified Modeling Language 即统一建模语言 它是一种定义良好 易于表达 功能强大且普遍适用的建模语言 UML 视图包括结构图和行为图 结构图描述系统及其组成部分的静态关系 常包括类图 对象图 包图 综合 结构图 组件图 部署图等 行为图描述系统的动态信息 包括用例图 状态 机图 活动图 和交互作用图 根据测试方法选择不同的视图能够有效帮助我 们设计测试用例 很多应用中 功能点都存在一定的交叉 如果合理设计用例 不仅可以 完成目标功能点测试 还可以覆盖其他交叉点的测试 精品文档 25欢迎下载 六 六 功能测试功能测试 功能测试主要分为以下几个阶段 测试准备 测试计划 测试用例设计 测试执行 测试总结 6 16 1 测试准备测试准备 接到一个项目任务时 不要立即去执行测试用例 而是要先做好测试准备 工作 1 了解相关项目背景及其相关技术 了解做什么 为什么做 用了什么新技术等问题 对于测试人员 了解 这些对发现更多缺陷 出现问题时进行有效分析将有很大帮助 2 尽早发现问题 提出问题 从用户需求到产品需求说明书 再到用户接口规格说明书等一系列项目 过程文档都是测试对象 问题发现的越早越好 可以减少不必要的麻烦 同时更好的保证质量 3 画出功能图 分析业务功能点 画出功能图 方便理解需求 确定范围 4 用数据流图描述业务范围 功能图描述了完成的主要功能点 而各功能点又有着一定的联系 可以 通过流程图来抽象出功能点之间的数据流动及端到端的业务过程 5 根据项目需求熟悉和掌握相关的系统信息 6 26 2 测试计划测试计划 根据项目相关文档 需要定义测试范围 测试策略 人员分配 软硬件配 置 进度表以及测试过程每个阶段需要达到的目标 精品文档 26欢迎下载 6 36 3 功能测试用例功能测试用例 6 3 16 3 1 功能测试用例的设计功能测试用例的设计 测试用例必须能够使测试人员能够明确理解 并能够依据测试用例的描述 执行测试 其次 测试之前必须明确功能逻辑 熟知每个测试用例的场景 测试用例主要包括用例编号 用例描述 前提条件 输入数据 测试步骤 和期望结果 6 项关键内容 1 用例编号 用例的组织要方便测试人员执行测试用例 应设计一套良好的用例编号 体系 2 用例描述 用例描述应使用最精简的文字 描述出用例的全貌 让测试人员不用看 测试步骤 只看这个描述就可以知道这个用例是描述哪个场景 哪个功 能点 3 前提条件 一个测试用例一般是针对一个特点的场景 而需要测试的场景发生时通 常会有一些铺垫场景 即测试用例的前提 如软硬件环境配置 权限设 置 数据准备 4 输入数据 一个测试用例可以有一个或多个输入数据 也可以无输入数据 5 测试步骤 测试步骤是测试用例的主体 一个测试用例由一个或多个步骤组成 每 个步骤之间有一定的前后关系 每个步骤必须表述详细 描述清晰 用 于规范 严谨而又客观 最基本的要求是能够使其他人理解 并能正确 的执行编写者希望的操作 6 期望结果 期望结果是测试执行对执行结果进行对比的标尺 是测试是否通过的判 断依据 测试结果必须保证其正确性 精品文档 27欢迎下载 6 3 26 3 2 功能测试用例执行窍门功能测试用例执行窍门 1 不要离开测试用例 但不依赖 测试用例是经过设计 思考的 力图涵盖所有的功能点 所以它是测试 执行的依据 但是因为测试的深度有限 很难覆盖所有的路径 加上需 求变更 测试用例很难及时更新 而且只生搬硬套测试用例执行 效果 不好 手工测试时 仅把测试用例作为一个参考即可 不要过分依赖它 我们可以进行更多的发散测试 加上不断的思考 效果要好得多 2 测试执行时 学会从测试用例中生成测试用例 测试用例的描述 有个基本原则是不要写得太复杂 所以功能交叉的测 试用例 一般不会写得太复杂 但测试执行时 要特别注意多种条件组 合及其逻辑先后顺序 要学会从多个单一的测试用例中 基于整体考虑 而生成更多的测试用例 这也是熟悉业务的测试人员比不熟悉的测试人 员发现更多测试点的原因之一 6 46 4 功能测试方法功能测试方法 6 4 16 4 1 测试步骤测试步骤 功能测试一般分为走查 基本功能验证 回归测试 1 走查 正式测试之前 可以安排少量熟悉需求的人员走查一遍开发提交的测试 版本 把基本需求 主要功能等走查一遍 如果有很多影响测试的问题 可以拒绝测试 让开发人员继续进行单元测试 2 基本功能验证 参照测试用例 适时的查找相关文档来测试 在此测试的过程中 可以 由表及里 由局部到整体进行测试 3 回归测试 基于主要功能点和项目整个阶段 特别是最近修复的严重缺陷 反复验 证测试用例 精品文档 28欢迎下载 空或 0 值是数值的临界值 也常用作标记软件中某种特殊运行状态 如 初始状态 或数据状态 如初始默认值 因此置零是软件边界测试重 点 也是容易出现错误的地方 类似的还有空格 null 最大值 最小 值等数据 6 4 26 4 2 查找遗漏问题的方法查找遗漏问题的方法 1 Spec 是基础和标准 测试的执行 通常按测试用例来进行 但测试用例的设计编写是依据产品 规格说明书 需求规格说明书 界面设计规范等 写测试用例时难免有考虑不 到的地方 因此反复阅读说明文档 也许会有一些新的思路和启发 在项目后 期 回归测试阶段 容易思维定势 疲惫 这是可以把这些文档拿出来 再看 一下功能点是否覆盖 覆盖到的是不是和需求一致 没有偏差 2 相关变动邮件 讨论记录 变动是一个项目过程中不可少的部分 而这些变动 通常是通过讨论的 方式定下来的 因此会有一些文档记录和邮件 反复阅读这些邮件和文 档记录 可以更深入的理解项目 3 不定期阅读别人的缺陷 每个人的思路 考虑的角度和操作习惯各不相同 因此发现的问题就会 不一样 多阅读别人的缺陷可以拓宽思路 看多了 也会不自觉把多种 思路集中到一起 慢慢得应用到测试实践中了 4 多和开发人员沟通 功能测试对测试人员来说大多是黑盒测试 只有开发人员最清楚哪个函 数调用哪个函数 哪块单元测试不够充分 哪个逻辑结构比较复杂 多 和他们沟通 可以知道哪里还需要多关注一下 5 有选择的重新验证以前的缺陷 特别在回归测试 验收测试阶段 除了验证前面发现的缺陷 还要重视 那些与缺陷相关的模块 一个底层参数的变动 可能会引起很多相关功 能的问题 继而造成缺陷的遗漏 精品文档 29欢迎下载 6 关注变化 一段代码的改动 需要开发人员和测试人员去识别 开发人员知道改动 的地方会被哪些模块调用或者会引起哪些模块的变化 但由于时间紧 任务重 很难做好单元测试 因此开发人员要通知测试人员需要关注的 测试点 7 简单思维方式 以主线为主 减少大遗漏 一个项目的成功不是把缺陷全报出来 而是在有限的代价下达到预期的 质量 按计划进行的项目 主要功能的质量在一定程度上决定了产品的 好坏 在项目工期紧张时 全部走完所有测试用例是很难的 可以基本 功能为主线 做好相关测试用例的执行 保证不会发生大的质量事故 在测试后期 测试人员可能对质量已经很有信心 受思维和经验的局限 性 可能仅限于此 若此时 在产品发布之前 调动其他组的员工参与 限时测试并给予奖励 必然能有效减少软件缺陷带来的风险 提高产品 质量 6 4 36 4 3 缺陷预防缺陷预防 测试发现软件中的缺陷 避免问题在软件发布之后还遗留在系统里 实际 上就是事后检查 确保所发布的产品满足用户需求 并具有较高的质量 但是 当我们做测试时 问题已经发生了 我们只是去找问题 找到问题后让开发人 员修正问题 修正问题需要返工 造成人力成本的浪费 如果是代码问题 返 工比较少 如果是设计 需求的问题 就需要重新定义需求 修改设计 然后 再修改代码 除了开发人员返工之外 测试人员在开发修改之后还要进行回归 测试 会占用更多的人力成本 因此 我们要降低开发成本 就必须减少缺陷 根本方法就是预防问题的产生 从一开始就将事情做对 做好 1 做好前期工作 自软件开发项目启动之时 从需求定义 系统设计到编程 就不断引入 问题 质量也就取决于这个过程中引入多少问题 在这个工程中 引入 的问题越少 质量就越高 引入的问题越多 质量就越低 要想减少问 精品文档 30欢迎下载 题 避免缺陷的引入 就要抓住每个入口 让每个入口符合标准 满足 事先预定的要求 而在软件开发中就要做好需求评审 设计评审和代码 评审等工作 以保证开发的各个环节都能获得高质量的阶段性成果 2 缺陷的统计分析 通过软件缺陷根本原因分析 Root Cause Analysis RCA 可以找到 问题发生的根本原因 对缺陷进行分类统计 了解缺陷主要发生在哪些 模块 哪一类缺陷最多或排在前三位缺陷的是哪几类 制订相应的防护 措施 以避免今后发生类似的问题 需记录的缺陷信息包括 软件缺陷 产生所属模块 缺陷来源 如需求设计文档 技术设计 源代码等 缺陷被发现的阶段 缺陷所表现出的现象 如不清晰或错误的需求规范 不正确的行为 数据不一致 计算错误 设计不合理等 测试跟踪 如新引进的缺陷 迟发现的缺陷 回归缺陷等 缺陷对应的测试用 例 ID 3 深度分析找到根本原因 只有找到问题的根本原因 才能消除问题产生的根源 主要从人员 技 术 流程 业务四个方面出发 通过和团队讨论 一起回顾产品测试过 程 就能发现问题的根本原因 4 找到问题的解决办法 真正的原因被挖掘之后 找到解决的办法就不难了 当然 找到解决办 法还不够 还需要设定相应的目标 跟踪这个改进过程 直至达到目标 如果没有达到效果 就需要进行新一轮的根本原因分析 在软件测试管 理中 这是一个持续分析 持续改进的过程 6 56 5 如何有效开展测试如何有效开展测试 1 周期性进行头脑风暴 促成知识交流 共享 升值 不同的测试人员对于测试软件的看法 实践经验都会有所不同 即使对 于同一个软件 测试人员发现的缺陷也相差甚远 因此周期性进行头脑 风暴 在一起讨论测试的系统 测试可能疏忽的问题 可以集众人智慧 促成知识融合 加快测试进度 保证测试质量 精品文档 31欢迎下载 2 项目中创造好的测试条件 在测试时间较紧的情况下 使得测试人员可能疲于 奔命 这种情况 下 测试人员学习的速度可能比较快 但是也可能因为疲劳 时间紧而 放弃利用学过的知识及时调整测试的方法或细节 因此在项目进行中 权衡项目时间与测试质量是必须要考虑的 可以考虑给测试人员一定的 时间自由轻松的去思考 去完善测试 从而持续优化质量 3 根据具体项目 测试人员经验决策测试开展 项目的难度 测试人员的工作经验直接影响测试开展的时间 方式和效 果 如果项目比较简单 测试人员经验丰富 在项目计划和测试设计阶 段可完成大多数测试的设计 相反 如果测试项目难度大 测试人员经 验不足 在测试计划阶段就要思索如何学习要测试的系统 如何有效的 测试等问题 精品文档 32欢迎下载 七 七 敏捷测试敏捷测试 7 17 1 敏捷敏捷开发开发 敏捷开发要求在短时间内开发出高质量的软件产品 并且符合客户需求 极限编程 XP 就是敏捷型开发的一种 与传统开发方法相比 敏捷开发有如 下特点 1 敏捷型方法是 适配性 而非 预设性 传统开发方法试图对一个软件开 发项目在很长的时间跨度内作出详细的计划 然后依计划进行开发 这 类方法在计划制定完成后拒绝变化 而敏捷型方法则欢迎变化 其实 它们的目的就是成为适应变化的过程 甚至能允许改变自身来适应变化 2 敏捷型方法是 面向人 的 people oriented 而非 面向过程 的 process oriented 它们试图使软件开发工作顺应人的天性而非逆 之 它们强调软件开发应当是一项愉快的活动 以上两个特点很好的概括了敏捷开发方法的核心思想 适应变化和以人为 中心 敏捷开发可理解为在原有软件开发方法基础上的整合 取其精华 去 其糟粕 因此敏捷开发继承了不少原有方法的优势 敏捷开发的理念敏捷开发的理念 1 个体和交互 胜过 过程和工具 2 可以工作的软件 胜过 面面俱到的文档 3 客户合作 胜过 合同谈判 4 响应变化 胜过 遵循计划 遵循的原则遵循的原则 1 通过尽早的 持续的交付有价值的软件来使客户满意 2 即使到了开发的后期 也欢迎改变需求 敏捷过程利用变化来为客户创 精品文档 33欢迎下载 造竞争优势 3 经常性地交付可以工作的软件 交付的间隔可以从几个星期到几个月 交付的时间间隔越短越好 4 在整个项目开发期间 业务人员和开发人员必须天天都在一起工作 5 围绕被激励起来的个体来构建项目 给他们提供所需的环境和支持 并 且信任他们能够完成工作 6 6 在团队内部 最具有效果并富有效率的传递信息的方法 就是面对面的最具有效果并富有效率的传递信息的方法 就是面对面的 交谈交谈 7 工作的软件是首要的进度度量标准 8 敏捷过程提倡可持续的开发速度 责任人 开发者和用户应该能够保持 一个长期的 恒定的开发速度 9 不断地关注优秀的技能和好的设计会增强敏捷能力 10 简单是最根本的 11 最好的构架 需求和设计出于自组织团队 12 每隔一定时间 团队会在如何才能更有效地工作方面进行反省 然 后相应地对自己的行为进行调整 7 27 2 敏捷测试敏捷测试 针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试 在敏 捷团队中 测