测试需求分析.ppt

1、（测试需求分析）,目录,测试需求分析背景 测试需求分析理论 测试需求分析工程方法 测试需求分析应用,为什么要做测试需求分析？,测试了很多，还有这么多网上问题？,客户到底关心什么？,不知道如何站在客户立场测试？,网上问题漏测：测试设计不充分60%！,这些问题怎么没有考虑到？,需要做测试需求分析！,现状？,测试对象分析,测试用例设计（方案内的）,测试用例,测试输入,TR3,TR4,没有测试需求分析过程,测试经理口头分配 测试方案任务不明确,测试对象分析侧重 测试方案内部实现,现状存在什么问题？,测试过程与结果缺乏质量评估与控制,过多关注功能实现、产品质量维度关注不全面,没有统一成熟的分析设计工程方

2、法支撑,业界情况,SDT公司测试分析设计 IBM的测试设计七步法 某路由器公司的测试阶段和测试类型 MOTO故障插入测试,以业界公司为标杆，建立自己的测试分析设计体系,借鉴业界公司的经验，总结相关工程方法,好的示例,测试需求分析业界介绍（SDT公司）,Test Frame的测试设计模式,测试划分,测试需求分析,业界思路总结,测试类型 测试划分 强调测试需求分析，测试需求不仅仅来自需求文档 电子表格是支撑测试分析设计的主要工具(我现在常用的是freemind,先分解划块儿，在分块细化),不同类型的测试会发现不同类型的Bug。测试类型是从不同的角度来分析和测试产品,目录,测试需求分析背景 测试需求

3、分析理论 测试需求分析工程方法 测试需求分析应用,测试需求分析目的,清晰把握测试需求！,时刻关注产品质量！,测试需求分析目的是：明确应该测试什么。即明确测试需求，其核心是产品质量。 产品质量就是符合用户的明确的或隐含的需求的程度。 需求文档中的产品需求、系统设计需求是明确的需求 未在需求文档中明确的隐含的用户需求也是我们需要分析的，如用户使用产品方式、感受、业务习惯 Test requirements are useful sets of input that should be tested. Brian Marick,测试需求分析的目的？,测试需求分析基本概念（1）测试视角,测试类型,功能

4、交互,产品继承,分解分配,测试有哪些独特的视角？,测试与开发的思路有哪些不同？,测试的视角体现了测试的思维活动 这四个视角是工程方法的基础,测试需求分析基本概念（2）活动框架（1）,产品测试需求分析,测试规格分解分配,产品测试规格,特性测试需求分析,分配后测试规格,特性测试设计,测试设计维护,特性测试规格,测试用例,设计规格 协议/规范/标准 测试分析经验库,SRS 协议/规范 测试设计经验库 其他输入,测 试 需 求 分 析,测 试 方 案 设 计,测 试 用 例 设 计,测试用例设计,测试用例,测试用例设计维护,产品分析,产品包需求 设计需求,仅做参考,测试需求分析基本概念（3）活动框架（

5、2）,测试需求分析基本概念（3）活动框架（2）,产品测试需求分析,特性测试需求分析,特性测试设计,测试用例设计,SRS,HLD,LLD,CODING,测试需求分析活动类比开发活动图,阶段,产品分析,测试规格分解分配,特性测试需求分析,特性测试设计,测试用例设计,活动/子活动,结果输出,测试需求分析,测试方案设计,产品测试规格分析,原始需求提取,产品测试需求分析,测试类型分析； 功能交互分析； 关联图分析； 测试特性建模； 测试规格整合 测试特性交互分析,测试组网分析； 判定表； 因果图； 测试场景分析 正交测试分析法 正交试验设计法,等价类划分； 边界值； 因果图； 正交试验设计法；,测试分析

6、设计表之需求来源表,测试分析设计表之原始需求表,测试分析设计表之产品测试规格表； 测试需求分析报告.doc,特性测试工作任务书.doc,测试分析设计表之特性测试规格表,测试分析设计表之测试用例表,原始需求提取方法 继承性分析,工程方法,测试需求分析基本概念（4）活动框架（3）,测试需求分析基本概念（5）名词解释,测试原始需求：产品测试规格分析的输入，是从产品包需求、系统需求、测试经验库等需求来源中提取的经过整理的输入集合。 测试规格：测试规格是产品测试规格和特性测试规格的通称。一般而言，我们所说的测试规格都是指产品测试规格。产品测试规格是对客户需求、产品包需求、设计需求、设计规格以及其它可能的

7、需求进行综合的测试分析，从测试角度分析并整合形成的测试需求集合，明确了测试应该测试什么。产品测试规格经过相关整理后相互之间没有重复，每条产品测试规格都有唯一的标识。 测试特性：逻辑上相关的产品测试规格集合，可以是功能性的产品测试规格集合，也可以是非功能性的产品测试规格集合。逻辑相关性，指的是按照一定的规则进行划分，这个规则是个广义的规则，区别于开发按照功能进行划分的特性。,测试需求分析活动（1）产品分析,产品分析主要是产品知识前期学习和熟悉 确定产品测试需求分析的来源 确定测试分析设计策略,这个产品/版本是什么？赶紧学习相关资料！,下一步如何分析？,测试需求分析活动（2）提取测试原始需求,子活

8、动准备（分工组织、提取策略） 提取测试原始需求 测试原始需求整理 确定测试规格分析工程方法,子活动准备（分工组织、工程方法应用策略） 运用工程方法进行分析，得出初始的产品测试规格：测试类型分析、功能交互分析、关联图分析、其他分析方法 测试特性建模:从测试角度，划分出测试特性，并对初始的测试规格进行整合，按照测试特性进行归类，得到最终具有完整属性的产品测试规格。,修正,测试原始需求,测试类型分析功能交互分析 关联图分析其他工程方法,初始产品测试规格,测试特性建模,测试特性,测试规格 整合,产品测试规格,修正,修正,测试原始需求,测试类型分析功能交互分析 关联图分析其他工程方法,初始产品测试规格,

9、测试特性,测试规格整合,产品测试规格,测试特性建模,测试特性建模时机的不同产生两种活动方式,测试需求分析活动（3）产品测试规格分析,测试需求分析活动（4）测试规格分解分配,通过测试特性建模形成测试特性 产品测试规格分解分配到测试特性 以测试特性为单位进行测试方案设计 以测试方案设计任务书形式交付测试方案设计阶段,测试分析设计评估,质量,测试用例密度,覆盖率,ODC评估（不同触发因素的比率） 测试类型评估（不同测试类型的比率）,测试用例/每千行代码,不同设计规格的覆盖率（2/8原则） 设计规格的覆盖率,测试需求分析活动（5）测试规格评估,测试需求分析活动（6）测试规格评估,TSE负责跟踪,PL负

10、责跟踪,测试要同时验证客户需求、产品包需求、设计需求,测试需求分析活动（7）测试规格跟踪,通过编号方案可以弄清楚测试分析设计输出之间的关系，建立一个跟踪体系。 需求来源：来源编码XXX 原始需求：特性编码XXX 初始产品测试规格：工程方法编码-子类编码-XXX 产品测试规格：测试特性编码-大类编码-子类编码-XXX 特性测试规格：测试特性编码-XXX 测试用例：特性测试规格编号-XXX,测试需求分析活动（8）测试规格编号方案,测试需求分析活动（9）测试规格维护,目录,测试需求分析背景 测试需求分析理论 测试需求分析工程方法 测试需求分析应用,测试需求分析工程方法概图,推荐的工程方法,虽然说上面

11、提到的工程方法都是一种参考，大家可以依据实际情况选用，但是从测试视角出发，在测试规格的分析活动中，推荐以下三种工程方法： 继承性分析 测试类型分析 功能交互分析,一、继承性分析,应用背景,目前开发的新版本有一个基础版本，他们之间的关系如何？ 新版本测试策略又是如何制定的？,分析思路（1）,输入： 需求来源表 历史版本的测试报告 历史版本的产品的特性清单及其说明等 其它可供参考的资料,输出： 测试策略建议 新增原始需求 需要进行功能交互分析的继承特性 其它一些过程输出,分析思路（2）,失效影响度：特性使用频度、特性重要性。 成熟度：经过测试的V/R版本数、网上应用情况反馈（应用性质、应用范围、网

12、上问题数量）。 继承方式：独立、交互、变化或者组合。,过程与结果,继承特性与新特性交互分析表,继承特性变化分析表,需要交互的继承特性,继承特性测试建议表,继承特性失效影响度分析 继承特性成熟度分析,交互,独立,变化,二、测试类型分析,应用背景,产品应用中出现的问题有各种方面,分析思路（1）基本过程,TSE召集讨论确定测试类型及其子类型 明确各测试类型分析思路 控制分析的粒度,分析思路（2）使用阶段,说明： 表示该测试类型的主要的测试阶段； 表示对应测试阶段有该测试类型或回归测试,针对不同的测试阶段，使用不同的测试类型：,分析思路（3）建立测试类型库,测试类型分析法是从不同的角度来分析和测试产品

13、，不同类型的测试会发现不同类型的Bug，每类测试类型的测试方法也会不同； 通过测试类型的建立，我们可以对整个产品的测试有一个系统的思路，而不是仅仅关注功能测试； 测试组应该建立并不断完善自己的测试类型库。,三、功能交互分析,产品功能不是独立的，功能之间存在交互 防止有交互作用的功能的遗漏，提高功能测试的完备性 是功能测试方面的分析，与测试类型分析形成互补,应用背景,产品其他相关功能,被测功能,功能交互,分析思路（1）交互关系,分析思路（2）基本过程,横轴是新增特性和继承特性，继承特性来自于继承性分析的结果 分析方法有两种形式：先标记后分析、直接分析 功能交互分析的结果可以作为测试类型分析的输入

14、，但是操作复杂，不建议这样应用,四、关联图分析,从用户角度出发来关注每个用户 如何使用被测功能特性 如何影响被测功能特性 对测试类型分析、功能交互分析的结果进行补充,应用背景,分析思路,确定用户：对象与外部实体/端点 确定相互联系的数据流、物流、行为 依据不同的用户类和响应的影响因素，输出测试规格,用户类可以是执行者，也可以是应用软件、系统硬件、目标实体、接口实体或者三维空间、时间等。,分析样例,五、测试特性建模,应用背景,全局因素：指对大部分特性都有影响的因素，这里指的因素是泛义的，可以是具体的硬件，也可以是软件实体，或者是逻辑实体，只要它们的变化对大部分特性有影响就可以确定是全局因素。 子

15、系统：子系统是一些逻辑相关的模块集合，可以包括多个模块。平时常说的子系统，比如：话统子系统、话单子系统、维护子系统等等，就属于这个范畴。如何合理的划分子系统，需要参考系统架构设计。,基本概念（1）,测试特性划分：由于开发和测试之间的分解分配思路不一样，测试需要从提高测试设计与执行的质量和效率出发建立测试自己的模型，避免测试按照设计规格分解分配思路（模块）来分配测试方案，从功能和测试类型两个角度进行测试特性划分，划分过程中考虑以下几个方面的因素： 开发特性或者功能 Build划分 系统架构（模块） 全局因素或者技术风险分析 测试组人员技能,基本概念（2）,SDV/SIT所有的测试用例分布在不同的

16、测试特性中，随着每个Build构建完成，需要确定SDV/SIT测试策略； Build （SDV）测试执行策略需要考虑如何回归，并保证功能交互测试的完备性； 图例中，Build B首先需要对Build A进行回归，确保BuildA没有出现新问题，同时补充测试两者之间的功能交互的测试用例，然后再执行测试特性3和测试特性4的相关测试用例。,基本概念（3）,基本过程（1）,测试特性建模的主要目的是划分测试特性，明确每个测试特性的内容和边界。原则上，一个测试方案对应一个测试特性。,T 对应的功能和子系统关联密切，主要实现在该子系统中，适合在该功能的测试特性中测试，强调以功能为主导的思想。 C 功能和该子

17、系统有接口，关系比较松散，可以将该子系统作为检查点对待 X 对应的功能和子系统关系松散，子系统可以作为功能测试特性的主要检查点; 但是为确保这种关系深入测试，在子系统或者全局因素特性中，要作为主要内容进行测试 S 对应的功能和子系统关联松散，不过子系统作为功能测试特性的检查点不合适，在子系统或者全局因素特性中，要作为主要内容进行测试,基本过程（2）,T 测试类型独特虽然和测试特性有关系，但是有自己的独特测试方法，建议独立划分到非功能测试特性 X 测试类型一部分和功能测试特性关系密切，测试方法和功能测试相同，这部分适合放在功能测试特性中测试，一部分有自己独特的测试方法，建议独立划分非功能测试特性

18、。 O 测试类型和功能测试特性关系密切，测试方法和功能测试相同，建议划分到相应的功能测试特性中。 N 测试类型和功能测试特性关系不紧密，需要单独划分非功能测试特性,基本过程（3）,分析样例,六、测试规格整合,应用背景,基本思路,测试规格整合样例,New：在测试规格中新增一项测试规格 Repeated：该测试规格已存在 Combined：将测试规格归入到一条已经存在的测试需求。如果原始测试规格A/B 合并成一条测试规格X, 则其中只有一个是新增，其它都是合并。,目录,测试需求分析背景 测试需求分析理论 测试需求分析工程方法 测试需求分析应用,什么时候进行测试需求分析？,测试参与TR的方式,测试参

19、与开发文档评审的一个原则是，必须先要输出自己的交付件，才能参加开发的文档评审： 先有测试分析，后有开发文档评审参与 在参与开发评审前，测试应该完成了自己的输出，带着问题参加评审，效果就会不同，参与评审，也是为了解答自己的问题。因此，在TR2时，必须先完成测试规格。 保留评审不改问题的测试规格 测试参与评审提出的问题，开发答复不需要修改或者风险较小，这部分的测试规格也应该保留，只是不用进行分配和测试。如果网上发现问题和这些内容相关，测试就有据可查，是风险分析的一个参考内容。,测试需求分析应用原则,测试需求分析报告,产品分析,测试规格分解分配,产品测试规格分析,测试原始需求提取,需求来源表,测试原

20、始需求表,产品测试规格表,测试方案设计工作任务书,过程记录和结果分开（测试需求分析报告与结果表测试分析设计表分开） 活动可以裁减，工程方法是参考，工程方法有一定的使用环境 每个工程方法都有明确的输出，但是每个活动的结果可以脱离于工程方法,结果表输出,过程记录输出,工程方法,关于测试规格的理解,业界公司的实践提出，不管设计规格是否完善都要建立测试需求，我们称为测试规格； 测试规格是测试对于产品设计规格分析之后的产物； 测试分析设计整体思路都是围绕着测试规格来开展的； 如果产品设计规格是测试的“客户需求”，那么测试规格就是测试的“产品设计规格”；,测试粒度是指一个测试焦点的精细度或粗糙度 测试粒度

21、是一个谱，而不是一系列的“是/或”类别 一个高粒度的测试方案允许测试人员检查低级别的细节，一般是系统的内部；低粒度的测试方案为测试人员提供一般的系统行为信息,关于测试规格粒度的理解（1）,测试规格的粒度应该把握灰度原则，建议各测试组在进行需求分析之前，内部经过充分讨论，就粒度问题达成共识； 尽可能的从不同侧面分析（测试类型、功能交互等）测试原始需求，给出初始的测试规格，可能会产生冗余，此时不要过分要求初始测试规格的粒度统一，在测试规格整合时考虑粒度统一问题； 对于一些较为清晰的功能，相似的子功能可以组合在一起描述，作为一个测试规格对待。比如：涉及到一个表格的设置，我们可以将增加、修改、删除等作

22、为一个测试规格，大家一目了然，没有歧异；（CRUD原则） 测试规格应该是完整地描述从用户角度出发所能看到的需求，而不是一个需求的片断，比如：彩铃业务的建立、释放是需求的片断，用户是看不到这一点的，建议这样描述：彩铃业务基本呼叫，考虑各种释放情况,把握灰度,用户可见,关于测试规格粒度的理解（2）,对于大家常见的分析思路，可以通过经验库的形式进行传递和统一。比如：常见的组网模型、常见的用户分类以及各种用户常见的操作等等； 测试规格的描述要清晰，不能有混淆的地方，在测试方案设计阶段，可以直接对测试规格进行细化，而不用参考其他的文档即可。比如：要考虑各种异常情况下的基本呼叫功能，这个测试规格就不是十分清晰，可以进一步给出具体的异常类别形成新的测试规格，比如：要考虑主叫各种异常释放情况下的基本呼叫；要考虑A接口各种异常情况下的基本呼叫等等。 测试规格的粒度，不仅