第三讲测试需求分析.pptVIP

测试需求及需求分析 1 测试需求概述 1.1 什么是测试需求 1.2 测试需求的特征 1.3 为什么需要测试需求 2 测试需求分析过程 2.1 需求采集 2.2 测试需求分析 2.3 测试需求评审 1.1 什么是测试需求 测试需求主要解决“测什么”的问题 ，即指明被测对象中什么需要测试。 测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容。 测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求； 1.2 测试需求的特征 制定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求； 测试需求应指明满足需求的正常的前置条件，同时也要指明不满足需求时的出错条件； 测试需求不涉及具体的测试数据，测试数据设计是测试设计环节应解决的内容。 1.3 为什么需要测试需求 软件测试需求是开发测试用例的依据。 有助于保证测试的质量与进度 。 测试需求是衡量测试覆盖率的重要指标。 2 测试需求分析过程 2.1 需求采集 需求采集的过程是将软件开发需求中的那些具有可测试性的需求或特性提取出来，形成原始测试需求。 可测试性是指这些提取的需求或特性必须存在一个可以明确预知的结果，可以用某种方法对这个明确的结果进行判断、验证，验证是否符合文档中的要求。 2.1 需求采集 需求采集的提取方法： 通过列表的形式对软件开发需求进行梳理，形成原始测试需求列表，列表的内容包括需求标识、原始测试需求描述、信息来源。 将每一条软件需求对应的开发文档及章节号作为软件需求标识。 使用软件需求的简述作为原始测试需求描述。 软件需求获取的来源信息 作为信息来源。 2.1 需求采集 提取的原始测试需求中，可能存在重复和冗余，在提取原始测试需求过程中，可以通过以下方法整理原始测试需求： 删除：删除原始测试需求表中重复的、冗余的含有包含关系的原始测试需求描述； 细化：对太简略的原始测试需求描述进行细化； 合并：如果有类似的原测试始需求，在整理时需要对其进行合并。 2.1 需求采集-举例 2.2 测试需求分析 2.2 测试需求分析 a）对原始测试需求列表中列出的每一条开发需求，形成可测试的分层描述的测试要点； b）对步骤a）形成的每一条测试要点，从GB/T 16260.1-2006《软件工程 产品质量 第1部分：质量模型》中定义的软件内部/外部质量模型来确定软件产品的质量需求； c）对步骤b）所确定的质量需求，分析测试执行时需要实施的测试类型； d）建立测试需求跟踪矩阵，对测试需求进行管理。 2.2.1 测试要点分析 测试要点是对原始测试需求表每一条开发需求的细化和分解，形成的可测试的分层描述的软件需求。 对开发需求的细化和分解具体包括： 通过分析每条开发需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容； 通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据（功能交互分析） ，对存在功能交互的功能项，给出对应的验证内容。 2.2.1 测试要点分析 功能交互分析 2.2.1 测试要点分析 进行细化和分解还需考虑： 需求的完整性，经过分解获得的需求必须能够充分覆盖软件需求的各种特征（包括隐含的特征），每个需求必须可以独立完成有意义的功能或功能组合，可以进行单独测试； 需求的规模，每个最低层次的需求能够使用数量相当的测试用例来实现，也即测试的粒度是均匀的 2.2.1 测试要点分析-举例 2.2.2 质量特性分析 对每一条测试要点，从GB /T16260.1定义的软件质量子特性角度出发，确定所对应的质量子特性。 2.2.2 分析质量特性-举例 2.2.2 分析质量特性-举例 2.2.3 分析测试类型 不同的质量子特性可以确定出不同的测试内容，这些测试内容可以通过不同的测试类型来实施。 软件测试可以划分为以下测试类型：功能测试、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复性测试、配置测试、兼容性测试、安装测试等。 根据质量子特性的定义，以及各测试类型的测试内容，可以分析出质量子特性与测试类型的对应关系。 2.2.3 分析测试类型 2.2.3 分析测试类型-举例 2.2.3 分析测试类型-举例 2.2.3 分析测试类型 为了避免遗漏，在确定测试类型时，还需考虑： 文档中是否包含测试类型相对应的情况的说明； 列出的常见测试类型是否已完全覆盖了被测软件； 被测软件的某些特殊情况是否已包含在所列出的测试类型中。 2.2.4 测试需求跟踪矩阵 建立测试需求跟踪矩阵，对测试需求进行管理。将上述步骤分析、确定