测试需求分析

1、Next Different 改变下一站 测试需求分析测试需求分析Next Different 改变下一站目录测试需求概要测试需求概要 什么是什么是测试需求测试需求 测试需求的特征测试需求的特征 为什么需要测试需求为什么需要测试需求测试需求分析过程测试需求分析过程 测试需求采集测试需求采集 测试需求分析测试需求分析 测试需求评审测试需求评审2Next Different 改变下一站需求? 背景：冯大勇吃鱼时嗓子被鱼刺卡住了。现在正坐在椅子上候诊。 大夫：（在桌上拿起一份挂号单，大声的喊）冯大勇！ 冯大勇：（病怏怏的样子，边走边咳嗽）我是。 大夫：怎么了？（低头整理手中的资料，自言自语，并打手势

2、，示意冯大勇坐下） 冯大勇：我.咳嗽.我今天.咳嗽. 大夫：不用说了，我知道了。（从桌子下面拿出一个大盒子，放在桌 子上） 我看你适合吃这种药。这是本院独家开创的哮喘新药“咽喉糖浆”，疗程短，见效快，一个疗程吃3盒，平均每天只需花费3块钱。给你先开6盒吧！（边说边开药方） 冯大勇非常惊讶地瞪大眼睛并止不住地弯腰大声咳嗽，以至于把鱼刺都咳出来了。冯大勇从口里掏出一条巨型鱼刺，递给医生。医生见到鱼刺先是吃惊，而后又非常尴尬。Next Different 改变下一站 测试需求主要解决“测什么”的问题 ，即细化被测对象。 测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测

3、试的内容。 测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。4什么是测试需求？什么是测试需求？Next Different 改变下一站什么是需求 需求是产品必须完成的事以及必须具备的品质。分分类：类：显式需求显式需求：明确定义的一系列约束软件实现的要求。隐式需求隐式需求：并不是需求设计人员特意隐藏，更多的是由理解人员对某方面专业知识，或对产品的业务了解程度有限导致的。5Next Different 改变下一站需求分析没有做好的后果一般会有下列现象：浪费时间和资源来满足用户并不需要的需求（过度实现一些功能）总是需要比较长的时间来达成对产品设计的共识员工会厌倦因需求不断被重新解释而

4、导致的返工不稳定的产品，用户的不满意对我们未来的市场造成损失开发出来的产品技术上先进，但并不满足用户需求在产品设计，开发和测试对于用户需求的解释不一致未说明的或不正确的需求会导致员工与用户间的不满浪费时间，增加成本，使得在一些投标的项目中不能低价Next Different 改变下一站需求分析的重要性 如果你在编码的时候发现某几行有误，那么改掉这几行就行了。而如果在编码阶段发现需求有误，那么你很可能需要改变所有代码来适应新的需求 在需求阶段消除问题的代价最小，而如果需求问题等到产品发布出去后才发现的话，那修复的成本就会N倍的增加。 稳定的需求是软件开发的关键。有了稳定的需求，软件开发工作可能从

5、结构设计到详细设计到代码到测试都会平稳顺利的进行。开头错开头错-全盘错全盘错-全盘输全盘输Next Different 改变下一站如何进行需求分析 一般可以从三个方面去考虑：1.功能需求2.非功能性需求3.限制条件了Next Different 改变下一站功能性需求 功能性需求是产品必须完成的那些事，要求一定的功能和品质。例： 培训机构的班主任可以给所在班级学员打考勤9Next Different 改变下一站非功能性需求 非功能性需求是产品必须具备的属性或品质。诸如观感、可用性、安全性和法律限制等。 例： 平台用户数为5万人,每天登录用户数为1000左右，网络的带宽为100M带宽。在工作时间根

6、据资料名称条件进行搜索，可以在3秒内得到搜索结果。 这类需求通常在产品的功能确定之后，一旦知道了产品要做的事情，就可以确定它的行为方式，它需要具备什么品质以及它的响应速度、可用性、可读性和安全性。10Next Different 改变下一站限定条件 限制条件是全局性的需求。它们可以是对项目本身的限制,或是对产品最终设计的限制。 例： 南京平台必须在2010年开学的第一学期上线 客户是在说，如果顾客不能在给定的时间前使用该产品，那么它就没有什么用了。其效果是需求分析师必须对需求进行限制，只包括那些在最后期限前能够提供最大价值的需求。Next Different 改变下一站需求分析的步骤 熟悉需求

7、背景及商业目标： 1) 了解清楚项目发起的原因，是为了解决用户的什么问题。 2) 当前的解决方案是不是最优的，为什么会这样做？Next Different 改变下一站 业务模型法：业务模型法： 1) 考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），可以参考系统分析说明书。 2) 确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互13Next Different 改变下一站需求审查点 易读性 二义性 一致性 统一性 是否存在需求过度或不合理 Next Different 改变

8、下一站测试人员在需求阶段应做哪些工作 用户的需求是否恰当的描述用户的需求是否恰当的描述 如果不恰当，那么是否要确认这里存在一个隐患，用户可能会在开发的后期突然要求让你的需求变动，所以要事先明确好 一.是用户是否真的能正确地描述自己的需求； 二.是需求人员是否真的能正确地理解需求。 三.是需求文档被正确的撰写Next Different 改变下一站 制定的测试需求项必须是可核实的。即它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求；即-期望输出。 测试需求应指明满足需求的正常的前提条件，同时也要指明不满足需求时的出错条件。 测试需求不涉及具体的测试数据，测试数据设计是测试设计(用例

9、设计)环节应解决的内容。16测试需求的特征测试需求的特征Next Different 改变下一站 软件测试需求是开发测试用例的依据。 有助于保证测试的质量与进度。 测试需求是衡量测试覆盖率的重要指标。17为什么需要测试需求为什么需要测试需求Next Different 改变下一站测试需求分析过程测试需求分析过程Next Different 改变下一站 a）对原始测试需求列表中列出的每一条开发需求，形成可测试的分层描述的测试要点； b）对步骤a）所确定的测试要点，分析测试执行时需要实施的测试类型； d）建立测试需求跟踪矩阵，对测试需求进行管理。测试需求分析测试需求分析Next Different

10、 改变下一站 需求采集的过程是将软件开发需求中的那些具有可测试性的需求或特性提取出来，形成原始测试需求。 一句话定义：可测试性是指这些提取的需求或特性必须存在一个可以明确预知的结果(期望输出)，可以用某种方法对这个明确的结果进行判断(实际输出)、验证，验证是否符合文档中的要求。 需求采集需求采集Next Different 改变下一站 需求采集的提取方法：a)通过列表的形式对软件开发需求进行梳理，形成原始测试需求列表，列表的内容包括需求标识、原始测试需求描述、信息来源。b)需求标识：产品版本号/功能模块版本号/LOGOc)将每一条软件需求对应的开发文档及章节号作为软件需求标识。d)使用软件需求

11、的简述作为原始测试需求描述。e)软件需求获取的来源信息作为信息来源。需求采集需求采集Next Different 改变下一站 提取的原始测试需求中，可能存在重复和冗余，在提取原始测试需求过程中，可以通过以下方法整理原始测试需求：a）删除：删除原始测试需求表中重复的、冗余的含有包含关系的原始测试需求描述；b）细化：对太简略的原始测试需求描述进行细化；c）合并：如果有类似的原测试始需求，在整理时需要对其进行合并。 需求采集需求采集Next Different 改变下一站“人力资源管理系统人力资源管理系统”原始测试需求表原始测试需求表序号序号软件需求标识软件需求标识原始测试需求描述原始测试需求描述信

12、息来源信息来源13.1.1基本信息管理增加员工信息人事部门招聘专员对于新招聘的职员信息可以录入到HRMIS系统中，主要职员信息如下：姓名、性别、出生日期、政治面貌、文化水平、婚姻情况、家庭住址、身份证号、办公电话、移动电话、紧急情况下的联系人和联系方式、毕业院校、入职时间、岗位及职责，其中，性别包含男、女两个类别；婚姻情况包括未婚、已婚、离异三种情况 。 人力资源管理系统业务需求说明书删除员工信息删除需用户确认，可以逐条删除或多条一次删除GB/T 17544-199823.2.2时间特性要求并发15个用户，平均登录时间小于10秒 人力资源管理系统业务需求说明书3隐含需求：在使用中操作错误的易恢

13、复性程序应对关键数据的操作给出警告或在执行前确认GB/T 17544-1998需求采集需求采集-举例举例Next Different 改变下一站测试需求分析测试需求分析Next Different 改变下一站 测试要点是对原始测试需求表每一条开发需求的细化和分解，形成的可测试的分层描述的软件需求。 对开发需求的细化和分解具体包括：a）通过分析每条开发需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容；b）通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据（功能交互分析） ，对存在功能交互的功能项，给出对应的验证内容。 ）测试要点分析测试要点分析Next Diff

14、erent 改变下一站 功能交互分析 测试要点分析测试要点分析Next Different 改变下一站 进行细化和分解还需考虑：a）需求的完整性，经过分解获得的需求必须能够充分覆盖软件需求的各种特征（包括隐含的特征），每个需求必须可以独立完成有意义的功能或功能组合，可以进行单独测试；b）需求的规模，每个最低层次的需求能够使用数量相当的测试用例来实现。测试要点分析测试要点分析Next Different 改变下一站测试要点分析测试要点分析-举例举例Next Different 改变下一站 不同的质量子特性可以确定出不同的测试内容，这些测试内容可以通过不同的测试类型来实施。 软件测试可以划分为以下

15、测试类型：功能测试、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复性测试、配置测试、兼容性测试、安装测试等。 根据质量子特性的定义，以及各测试类型的测试内容，可以分析出质量子特性与测试类型的对应关系。 分析测试类型分析测试类型Next Different 改变下一站质量子特性和测试类型的对应关系基准表 分析测试类型分析测试类型Next Different 改变下一站分析测试类型分析测试类型-举例举例Next Different 改变下一站分析测试类型分析测试类型-举例举例Next Different 改变下一站 为了避免遗漏，在确定测

16、试类型时，还需考虑：a）文档中是否包含测试类型相对应的情况的说明；b）列出的常见测试类型是否已完全覆盖了被测软件；c）被测软件的某些特殊情况是否已包含在所列出的测试类型中。分析测试类型分析测试类型Next Different 改变下一站 建立测试需求跟踪矩阵，对测试需求进行管理。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。 测试需求跟踪矩阵为原始测试需求与测试要点的对应关系表，格式如下： 测试需求跟踪矩阵测试需求跟踪矩阵Next Different 改变下一站 建立测试需求跟踪矩阵，对测试需求进行管理。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需

17、求矩阵。 通过测试需求跟踪矩阵的方式对需求变更实施。软件需求一旦发生变化，就要对需求跟踪表进行维护，启动配置管理过程，将与软件需求变更相关的内容进行同步变更。 测试需求跟踪矩阵测试需求跟踪矩阵Next Different 改变下一站增加培训信息测试需求跟踪矩阵测试需求跟踪矩阵-举例举例Next Different 改变下一站增加培训信息测试需求跟踪矩阵测试需求跟踪矩阵-举例举例Next Different 改变下一站 测试需求跟踪矩阵需要不断的维护。 a）一方面，软件需求一旦发生变化，应启动配置管理过程，将与软件需求变更相关的内容进行同步变更；b）另一方面，随着测试工作的进行，会不断添加新的跟

18、踪内容，对跟踪表进行扩展。例如，测试设计阶段的测试用例、测试执行阶段的测试记录和测试缺陷都可以添加到跟踪矩阵中。 测试需求跟踪距阵测试需求跟踪距阵Next Different 改变下一站 评审的内容： a）完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；b）准确性审查：应保证所描述的内容能够得到关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。 测试需求评审测试需求评审Next Different 改变下一站评审的形式评审的形式a a）相互评审、交叉评审：）相互评审、交叉评审： 甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给乙审查，乙的工作成果交给甲审查。相互评审是最不正式的一种评审形式，但应用方便、有效。测试需求评审测试需求评审Next Diff