测试需求分析与测试计划PPT学习课件

第十章测试需求分析与测试计划 目录 1 测试目标和准则 1 测试的目标 明确测试目标是测试需求分析和计划测试的前提测试目标向风险管理活动提供信息提供软件系统质量有关信息评估软件产品是否满足相关利益者的期望评估缺陷修正 清除 而不带来负面效应评估软件变更实施而不带来负面效应评估软件是否完全符合合规性要求 1 测试的目标 项目的具体测试目标提供哪些质量风险信息新改动的业务是否正确实现 对已有业务是否有负面影响是否满足功能性要求和非功能性要求在测试覆盖率 测试效率上的具体要求 1 测试的目标 如何确定测试目标哪些业务改动 会影响哪些已有业务 系统改动会影响哪些系统功能和非功能特性 测试覆盖率 新业务 功能 已有业务 功能呢 如何最大程度提高测试效率 2 测试进入的准则 清楚了解项目的整体计划框架 完成需求规格说明书评审 技术知识或业务知识的储备 标准环境技术设计文档 足够的资源 人员组织结构及其责任已确定 2 测试需求分析 1 测试需求 什么是测试需求 简单来说 测试需求就是确定在项目中需要测试什么 即细化被测对象 测试需求通常是以软件开发需求为基础进行分析 通过对开发需求的细化和分解 形成可测试的内容 测试需求应全部覆盖已定义的业务流程 以及功能和非功能方面的需求 测试需求描述测试的目标 特别是描述了产品的质量需求 测试需求分析目的是帮助定义测试对象和测试范围 发现软件需求中不完善和不明确的地方并加以完善以节省测试时间的投入 便于软件需求基线化和跟踪业务需求的变更 1 测试需求 为什么要做测试需求分析测试需求是测试计划的基础与依据 我们在测试活动中 首先需要明确测试需求 What 才能决定怎么测 How 测试时间 When 需要多少人 Who 测试的环境是什么 Where 是衡量测试覆盖率的重要指标 1 测试需求 测试需求分析意味着什么确定测试范围测试项和测试子项测试优先级测试风险 2 测试需求分析过程 熟悉需求需求项整理提取出测试点测试点细化确定测试范围制定测试策略 3 测试需求分析的基本方法 无论是功能测试 还是非功能性测试 其测试需求的分析都有以下两个基本的出发点 1 从客户角度进行分析 通过业务流程 业务数据 业务操作等分析 明确要验证的功能 数据 场景等内容 从而确定业务方面的测试需求 2 从技术角度分析 通过研究系统架构设计 数据库设计 代码实现等 分析其技术特点 了解设计和实现要求 包括系统稳定可靠 分层处理 接口集成 数据结构 性能等方面的测试需求 4 测试需求的分析技术 在软件测试需求分析过程中 可以借助下列途径来达到良好的分析效果 1 通过提炼 抓住主要线索 或作为整体来进行分析 使测试需求分析简单化 2 通过业务需求或功能层次的整理 使测试需求分析结构化 层次化 3 通过绘制业务流程图 数据流程图等 使测试需求分析可视化 4 通过类比 隐喻 加强用户需求的理解 更好地转化为测试需求 4 测试需求的分析技术 在测试需求分析时 产品本身往往处于需求分析和设计过程中 静态分析技术是常用的分析技术 静态分析技术包括如下通过系统建模语言 SysML 的需求图 可以更好地分析各项需求之间的关系 比较容易确定测试需求的边界 通过状态图 活动图更容易列出的测试场景 了解状态转换的路径和条件 哪些是重要测试场景等 实体关系图可以明确测试的具体对象 实体 及其之间的关系 进行相关分析 4 测试需求的分析技术 鱼骨图法 思维导图等 有一个清晰的分析思维过程 迅速展开测试需求 随时补充测试需求等 代码复杂度静态分析工具 代码越复杂 测试的投入也需要越多 还可以用一些普通工具 如检查表 脑力激荡法 让大家发散思维 相互启发 让任何测试需求不会被错过 5 功能测试范围分析 在分析测试范围时 一般先进行功能测试的范围分析 然后再进行非功能性测试的范围分析 对于功能测试 可以借助业务流程图 功能框图等来帮助我们进行测试的需求分析 在面向对象的软件开发中 也可借助UML用例图 活动图 协作图和状态图来进行功能测试范围分析 5 功能测试范围分析 GoogleTalk 6 非功能性的系统测试需求 对于非功能性的系统测试 主要目的是验证软件系统的整体性能等是否满足其产品设计规格所指定的要求 涉及非功能性的质量需求有系统性能 安全性 兼容性 扩充性等的测试对于每一个应用软件系统 非功能特性的质量需求都是存在的 这类测试需求会因不同的项目类型差异比较大 这些需求的程度 重要性不同 因此要求为非功能性测试需求设置优先级系统非功能性测试的需求在不同应用领域也体现较大差异 如网上银行 信用卡服务等系统 其安全性 可用性和可靠性等多方面的测试至关重要 因为这方面的缺陷很可能会给用户造成较大的损失 这些系统需要得到充分的安全性测试 容错性测试和负载测试 6 非功能性的系统测试需求 对于局域网内的企业级应用来说 有关权限控制 口令设置等安全性测试依然重要 但兼容性测试就相对简单对于企业级应用系统来说 存在着不同的应用模式 其系统的架构也不一样 可以分为 以功能为中心 以数据库为中心和以业务逻辑 工作流 为中心 等 在进行系统测试时 所设定的目标也有一定的区别 3 测试项目的估算与进度安排 1 测试工作量估算 测试工作量是根据测试范围 策划任务和开发阶段来确定的 测试范围和测试任务是测试工作量估算的主要依据 测试任务由质量需求 测试目标决定测试范围由产品 新 功能特性或测试任务决定 代码质量越低 测试越要充分 回归测试次数与频率加大 处在不同的开发阶段测试工作量不同 自动化程度高 测试工作量就越低 针对不同的应用领域 技术 编程语言 其估算方法不同 1 测试工作量估算 工作量估算过程 2 估算方法 工作分解结构表方法功能点方法 对象点方法代码行预估历史数据推算 相似规模 同类型 经验法 资深人员或专家小组 综合方法 3 工作分解结构表方法WBS 测试工作量的估算依赖于测试任务的细化 对每项测试任务进行分解 然后根据分解的子任务进行估算 通常分解粒度越小 估算精度越高列出本项目需要完成的各项任务 测试计划 需求和设计评审 测试设计 脚本开发 测试执行等 对每个任务进一步细分 可进行多层次的细分 直到不能细分为止 这建立在对于每一阶段工作的细致把握 列出需要完成的所有任务之后 根据任务的层次给进行编号 就形成了完整的工作分解结构表 3 工作分解结构表方法WBS 工作分解结构表 4 功能点估算法 功能点是其中一个比较可靠的工作量估算方法 它先估算每个功能点所需要的工作量 然后进行累加获得总的工作量借助分解结构表 WBS 方法来分解功能国际功能点用户组 IFPUG 颁布的标准方法主要参数有 外部输入数 外部输出数 内部逻辑文件 外部接口文件和外部查询数详细参考功能点实用手册 FunctionPointCountingPracticesManualRelease4 1 1999 4 功能点估算法 AFP 调整后功能点 UFP 未调整功能点数目 AF 影响因子 5 测试用例估算法 依据测试用例数来估算测试工作量 例如用功能模块所有要执行的测试用例总数 除以每个人日所能执行的测试用例平均数 就得出人日数工作量估算 往往基于其它一些假定效率假设 即测试队伍的工作效率测试假设 为了验证一个测试需求所需测试动作的数目 可能包括每个测试用例的估算时间风险假定 考虑增加10 20 的工作量来处理风险产生的不确定性 6 相对比例估算法 如果确实没有任何可行的办法 就可以按照测试人员和开发人员的比例来确定大致可以分为3类 其比例分别是1 2 1 1 2 1 7 总工作量 W Wo Wo R1 Wo R2 Wo R3W为总工作量 Wo为一轮测试所需的工作量R1 R2 R3为每轮的递减系数 受代码质量 开发流程和测试周期等影响 R1 R2 R3的值是不同的 4 测试风险和测试策略 1 测试风险 软件测试存在较高的风险 测试风险管理就是设法降低或缓解测试过程中的风险 包括确定哪些风险是可以避免的 可以采取哪些措施等 风险识别的有效方法就是建立风险项目检查表此前 历史资料 Brainstorming等帮助建立项目检查表风险识别并确定其程度 给出预防或处理措施 1 测试风险 风险项目检查表 1 测试风险 风险项目检查表 2 控制风险的对策 消除执行风险降低进度风险减少人员风险 2 控制风险的对策 风险管理 2 控制风险的对策 风险的控制方法采取措施避免可以避免的风险 高风险转移为低风险 设法降低不可避免的风险做好风险管理计划 制定处理风险一些应急 有效的方案 计划时 对于估算资源 时间 预算留有余地制定文档标准 建立机制 保证文档及时产生 3 测试策略及其内容 测试策略描述当前测试项目的目标和所采用的测试方法 描述不同测试阶段的测试对象 范围和方法以及每个阶段内所要进行的测试类型 针对风险 工作量 时间等压力 采取对策 包括遵照的标准取舍 测试任务的优先级等如何更好地执行测试用例以及后续的回归测试选定使用测试技术和工具考虑影响资源分配的特殊情况 3 测试策略及其内容 测试策略影响因素测试方式 静态 动态 探索式方式 黑盒 白盒 测试层次 单元 集成 系统 测试人员 责任 能力 独立性 测试用例选择 优化 如用例是否有优先级 测试环境 设置是否简单 自动部署 测试工具 能不能用测试工具 使用简单与否 质量标准 采用国内标准或美国DO 178C 3 测试策略及其内容 制定测试策略全面细致地了解产品的项目信息 应用领域 测试范围 市场需求 产品的特点和主要功能 技术架构基于模块 功能 整体 系统 版本 压力 性能 配置和安装等各个因素对产品的影响 公正客观地开展测试计划根据程序的重要性和一旦发生故障将造成的损失 来确定它的测试等级和测试重点认真研究测试策略 以便能使用尽可能少的有效测试用例 发现尽可能多的程序错误 因为一次完整的软件测试过后 如果程序中遗漏的错误过多并且很严重 则表明本次测试是失败的 是不足的 而测试不足意味着让用户承担隐藏错误带来的危险 同时反过来说 如果过度测试 则又会浪费许多宝贵的资源 找到一个最佳平衡点 5 测试计划内容与编制 1 测试计划内容 软件测试计划是指导测试过程的纲领性文件 描述测试活动的范围 方法 策略 资源 任务安排和进度等 并确定测试项 哪些功能特性将被测试 哪些功能特性将无需测试 识别测试过程中的风险 内容主要集中在测试目标和需求说明 测试工作量估算 测试策略 测试资源配置 进度表 测试风险等 1 测试计划内容 IEEE829 1998 测试计划内容 测试计划标识符 文档编号 项目总体情况简介 测试项 testitem 需要测试的功能 方法 策略 不需要测试的功能 测试项通过 失败的标准 测试中断和恢复的规定 测试完成所提交的材料 测试任务 测试环境要求 测试人员职责 人员安排与培训需求 进度表 潜在的问题和风险 审批 2 测试项目的计划过程 计划初期是收集项目各类信息 理解用户的真正需求确定测试需求和测试范围起草计划 内部审查 计划讨论和修改 测试计划的多方审查 测试计划的定稿和批准 测试计划的跟踪 3 制定有效的测试计划 测试计划的创建和评审 3 制定有效的测试计划 制定有效的测试计划确定测试项目的任务 清楚测试范围和测试目标尽量识别出各种测试风险 制定出相应的对策让所有合适的相关人员参与测试项目的计划制定客观 准确 留有余地 制定测试项目的输入 输出和质量标准识别出可变因素 建立变化处理和控制的流程规则不要忽视技术上的问题要对测试的公正性 遵照的标准做一个说明测试计划应简洁 易读并有所侧重 3 制定有效的测试计划 测试输入 输出标准测试的输入标准整体项目计划框架 需求规格说明书 技术知识或业务知识标准环境设计文档 足够的资源人员组织结构 测试的输出标准测试执行标准Bug描述和处理标准文档标准和模板测试分析 质量评估标准等 3 制定有效的测试计划 测试输入 输出标准测试的输入标准整体项目计划框架 需求规格说明书 技术知识或业务知识标准环境设计文档 足够的资源人员组织结构 测试的输出标准测试执行标准Bug描述和处理标准文档标准和模板测试分析 质量评估标准等 计划不是文档 是一个过程 3 制定有效的测试计划 测