《测试需求分析》PPT课件.pptx

测试需求分析 目录 测试需求概要什么是测试需求测试需求的特征为什么需要测试需求测试需求分析过程测试需求采集测试需求分析测试需求评审 2 需求 背景 冯大勇吃鱼时嗓子被鱼刺卡住了 现在正坐在椅子上候诊 大夫 在桌上拿起一份挂号单 大声的喊 冯大勇 冯大勇 病怏怏的样子 边走边咳嗽 我是 大夫 怎么了 低头整理手中的资料 自言自语 并打手势 示意冯大勇坐下 冯大勇 我 咳嗽 我今天 咳嗽 大夫 不用说了 我知道了 从桌子下面拿出一个大盒子 放在桌子上 我看你适合吃这种药 这是本院独家开创的哮喘新药 咽喉糖浆 疗程短 见效快 一个疗程吃3盒 平均每天只需花费3块钱 给你先开6盒吧 边说边开药方 冯大勇非常惊讶地瞪大眼睛并止不住地弯腰大声咳嗽 以至于把鱼刺都咳出来了 冯大勇从口里掏出一条巨型鱼刺 递给医生 医生见到鱼刺先是吃惊 而后又非常尴尬 测试需求主要解决 测什么 的问题 即细化被测对象 测试需求通常是以软件开发需求为基础进行分析 通过对开发需求的细化和分解 形成可测试的内容 测试需求应全部覆盖已定义的业务流程 以及功能和非功能方面的需求 4 什么是测试需求 什么是需求 需求是产品必须完成的事以及必须具备的品质 分类 显式需求 明确定义的一系列约束软件实现的要求 隐式需求 并不是需求设计人员特意隐藏 更多的是由理解人员对某方面专业知识 或对产品的业务了解程度有限导致的 5 需求分析没有做好的后果一般会有下列现象 需求分析的重要性 如果你在编码的时候发现某几行有误 那么改掉这几行就行了 而如果在编码阶段发现需求有误 那么你很可能需要改变所有代码来适应新的需求在需求阶段消除问题的代价最小 而如果需求问题等到产品发布出去后才发现的话 那修复的成本就会N倍的增加 稳定的需求是软件开发的关键 有了稳定的需求 软件开发工作可能从结构设计到详细设计到代码到测试都会平稳顺利的进行 开头错 全盘错 全盘输 如何进行需求分析 一般可以从三个方面去考虑 1 功能需求2 非功能性需求3 限制条件了 功能性需求 功能性需求是产品必须完成的那些事 要求一定的功能和品质 例 培训机构的班主任可以给所在班级学员打考勤 9 非功能性需求 非功能性需求是产品必须具备的属性或品质 诸如观感 可用性 安全性和法律限制等 例 平台用户数为5万人 每天登录用户数为1000左右 网络的带宽为100M带宽 在工作时间根据资料名称条件进行搜索 可以在3秒内得到搜索结果 这类需求通常在产品的功能确定之后 一旦知道了产品要做的事情 就可以确定它的行为方式 它需要具备什么品质以及它的响应速度 可用性 可读性和安全性 10 限定条件 限制条件是全局性的需求 它们可以是对项目本身的限制 或是对产品最终设计的限制 例 南京平台必须在2010年开学的第一学期上线客户是在说 如果顾客不能在给定的时间前使用该产品 那么它就没有什么用了 其效果是需求分析师必须对需求进行限制 只包括那些在最后期限前能够提供最大价值的需求 需求分析的步骤 熟悉需求背景及商业目标 1 了解清楚项目发起的原因 是为了解决用户的什么问题 2 当前的解决方案是不是最优的 为什么会这样做 业务模型法 1 考虑本项目与外部系统的交互 划分系统边界 除了本项目的需求中要求做的事情 其他的都可以是外部系统 本系统和外部系统之间的交互就是系统的边界 可以参考系统分析说明书 2 确定测试范围和关注点 系统的边界是测试的重点 特别需要关注边界交互时的数据交互 13 需求审查点 易读性二义性一致性统一性是否存在需求过度或不合理 测试人员在需求阶段应做哪些工作 用户的需求是否恰当的描述如果不恰当 那么是否要确认 这里存在一个隐患 用户可能会在开发的后期突然要求让你的需求变动 所以要事先明确好一 是用户是否真的能正确地描述自己的需求 二 是需求人员是否真的能正确地理解需求 三 是需求文档被正确的撰写 制定的测试需求项必须是可核实的 即它们必须有一个可观察 可评测的结果 无法核实的需求不是测试需求 即 期望输出 测试需求应指明满足需求的正常的前提条件 同时也要指明不满足需求时的出错条件 测试需求不涉及具体的测试数据 测试数据设计是测试设计 用例设计 环节应解决的内容 16 测试需求的特征 软件测试需求是开发测试用例的依据 有助于保证测试的质量与进度 测试需求是衡量测试覆盖率的重要指标 17 为什么需要测试需求 测试需求分析过程 a 对原始测试需求列表中列出的每一条开发需求 形成可测试的分层描述的测试要点 b 对步骤a 所确定的测试要点 分析测试执行时需要实施的测试类型 d 建立测试需求跟踪矩阵 对测试需求进行管理 测试需求分析 需求采集的过程是将软件开发需求中的那些具有可测试性的需求或特性提取出来 形成原始测试需求 一句话定义 可测试性是指这些提取的需求或特性必须存在一个可以明确预知的结果 期望输出 可以用某种方法对这个明确的结果进行判断 实际输出 验证 验证是否符合文档中的要求 需求采集 需求采集的提取方法 a 通过列表的形式对软件开发需求进行梳理 形成原始测试需求列表 列表的内容包括需求标识 原始测试需求描述 信息来源 b 需求标识 产品版本号 功能模块版本号 LOGOc 将每一条软件需求对应的开发文档及章节号作为软件需求标识 d 使用软件需求的简述作为原始测试需求描述 e 软件需求获取的来源信息作为信息来源 需求采集 提取的原始测试需求中 可能存在重复和冗余 在提取原始测试需求过程中 可以通过以下方法整理原始测试需求 a 删除 删除原始测试需求表中重复的 冗余的含有包含关系的原始测试需求描述 b 细化 对太简略的原始测试需求描述进行细化 c 合并 如果有类似的原测试始需求 在整理时需要对其进行合并 需求采集 需求采集 举例 测试需求分析 测试要点是对原始测试需求表每一条开发需求的细化和分解 形成的可测试的分层描述的软件需求 对开发需求的细化和分解具体包括 a 通过分析每条开发需求描述中的输入 输出 处理 限制 约束等 给出对应的验证内容 b 通过分析各个功能模块之间的业务顺序 和各个功能模块之间传递的信息和数据 功能交互分析 对存在功能交互的功能项 给出对应的验证内容 测试要点分析 功能交互分析 测试要点分析 进行细化和分解还需考虑 a 需求的完整性 经过分解获得的需求必须能够充分覆盖软件需求的各种特征 包括隐含的特征 每个需求必须可以独立完成有意义的功能或功能组合 可以进行单独测试 b 需求的规模 每个最低层次的需求能够使用数量相当的测试用例来实现 测试要点分析 测试要点分析 举例 不同的质量子特性可以确定出不同的测试内容 这些测试内容可以通过不同的测试类型来实施 软件测试可以划分为以下测试类型 功能测试 安全性测试 接口测试 容量测试 完整性测试 结构测试 用户界面测试 负载测试 压力测试 疲劳强度测试 恢复性测试 配置测试 兼容性测试 安装测试等 根据质量子特性的定义 以及各测试类型的测试内容 可以分析出质量子特性与测试类型的对应关系 分析测试类型 质量子特性和测试类型的对应关系基准表 分析测试类型 分析测试类型 举例 分析测试类型 举例 为了避免遗漏 在确定测试类型时 还需考虑 a 文档中是否包含测试类型相对应的情况的说明 b 列出的常见测试类型是否已完全覆盖了被测软件 c 被测软件的某些特殊情况是否已包含在所列出的测试类型中 分析测试类型 建立测试需求跟踪矩阵 对测试需求进行管理 将上述步骤分析 确定的开发需求 测试需求 测试类型填入测试跟踪需求矩阵 测试需求跟踪矩阵为原始测试需求与测试要点的对应关系表 格式如下 测试需求跟踪矩阵 建立测试需求跟踪矩阵 对测试需求进行管理 将上述步骤分析 确定的开发需求 测试需求 测试类型填入测试跟踪需求矩阵 通过测试需求跟踪矩阵的方式对需求变更实施 软件需求一旦发生变化 就要对需求跟踪表进行维护 启动配置管理过程 将与软件需求变更相关的内容进行同步变更 测试需求跟踪矩阵 增加培训信息 测试需求跟踪矩阵 举例 增加培训信息 测试需求跟踪矩阵 举例 测试需求跟踪矩阵需要不断的维护 a 一方面 软件需求一旦发生变化 应启动配置管理过程 将与软件需求变更相关的内容进行同步变更 b 另一方面 随着测试工作的进行 会不断添加新的跟踪内容 对跟踪表进行扩展 例如 测试设计阶段的测试用例 测试执行阶段的测试记录和测试缺陷都可以添加到跟踪矩阵中 测试需求跟踪距阵 评审的内容 a 完整性审查 应保证测试需求能充分覆盖软件需求的各种特征 重点关注功能要求 数据定义 接口定义 性能要求 安全性要求 可靠性要求 系统约束等方面 同时还应关注是否覆盖开发人员遗漏的 系统隐含的需求 b 准确性审查 应保证所描述的内容能够得到关各方的一致理解 各项测试需求之间没有矛盾和冲突 各项测试需求在详尽程度上保持一致 每一项测试需求都可以作为测试用例设计的依据 测试需求评审 评审的形式a 相互评审 交叉评审 甲和乙在一个项目组 处在一个领域 但工作内容不同 甲的工作成果交给乙审查 乙的工作成果交给甲审查 相互评审是最不正式的一种评审形式 但应用方便 有效 测试需求评审 b 小组评审 通过正式的小组会议完成评审工作 是有计划的和结构化的评审方式 评审定义了评审会议中的各种角色和相应的责任 所有参与者在评审会议的前几天就拿到了评审材料 并对该材料进行了独立研究 测试需求评审 需求内审 评审的形式a 审查 审查和小组评审很相似 但更为严格 是最系统化 最严密的评审形式 包含了制定计划 准备和组织会议 跟踪和分析审查结果等 测试需求评审 评审的人员组成 a 正式评审小组中 一般存在多种角色 包括协调人