测试需求分析.pptVIP

（测试需求分析）;目录; 为什么要做测试需求分析？;现状？;业界情况;测试需求分析业界介绍（SDT公司）;业界思路总结;目录;测试需求分析目的;测试需求分析基本概念（1）－－测试视角;测试需求分析基本概念（2）－活动框架（1）;产品测试需求分析;测试需求分析基本概念（3）－活动框架（2）;阶段;测试需求分析基本概念（5）－－名词解释;测试需求分析活动（1）－产品分析;测试需求分析活动（2）－提取测试原始需求;子活动准备（分工组织、工程方法应用策略）

运用工程方法进行分析，得出初始的产品测试规格：测试类型分析、功能交互分析、关联图分析、其他分析方法

测试特性建模:从测试角度，划分出测试特性，并对初始的测试规格进行整合，按照测试特性进行归类，得到最终具有完整属性的产品测试规格。;测试需求分析活动（4）－测试规格分解分配;测试分析设计评估;评估方法;客户需求;测试需求分析活动（8）－测试规格编号方案;为什么有测试规格维护？;目录;测试需求分析工程方法概图;推荐的工程方法;一、继承性分析;应用背景;分析思路（1）;分析思路（2）;过程与结果;二、测试类型分析;应用背景;分析思路（1）－－基本过程;分析思路（2）－－使用阶段;分析思路（3）－－建立测试类型库;三、功能交互分析;;分析思路（1）－－交互关系;分析思路（2）－－基本过程;四、关联图分析;从用户角度出发来关注每个用户

如何使用被测功能特性

如何影响被测功能特性

对测试类型分析、功能交互分析的结果进行补充;分析思路;分析样例;五、测试特性建模;应用背景;全局因素：指对大部分特性都有影响的因素，这里指的因素是泛义的，可以是具体的硬件，也可以是软件实体，或者是逻辑实体，只要它们的变化对大部分特性有影响就可以确定是全局因素。

子系统：子系统是一些逻辑相关的模块集合，可以包括多个模块。平时常说的子系统，比如：话统子系统、话单子系统、维护子系统等等，就属于这个范畴。如何合理的划分子系统，需要参考系统架构设计。;测试特性划分：由于开发和测试之间的分解分配思路不一样，测试需要从提高测试设计与执行的质量和效???出发建立测试自己的模型，避免测试按照设计规格分解分配思路（模块）来分配测试方案，从功能和测试类型两个角度进行测试特性划分，划分过程中考虑以下几个方面的因素：

开发特性或者功能

Build划分

系统架构（模块）

全局因素或者技术风险分析

测试组人员技能

;SDV/SIT所有的测试用例分布在不同的测试特性中，随着每个Build构建完成，需要确定SDV/SIT测试策略；

Build（SDV）测试执行策略需要考虑如何回归，并保证功能交互测试的完备性；

图例中，BuildB首先需要对BuildA进行回归，确保BuildA没有出现新问题，同时补充测试两者之间的功能交互的测试用例，然后再执行测试特性3和测试特性4的相关测试用例。

;基本过程（1）;;;分析样例;六、测试规格整合;应用背景;基本思路;测试规格整合样例;目录;什么时候进行测试需求分析？;测试参与TR的方式;测试需求分析应用原则;关于测试规格的理解;测试粒度是指一个测试焦点的精细度或粗糙度

测试粒度是一个谱，而不是一系列的“是…/或…”类别

一个高粒度的测试方案允许测试人员检查低级别的细节，一般是系统的内部；低粒度的测试方案为测试人员提供一般的系统行为信息;测试规格的粒度应该把握灰度原则，建议各测试组在进行需求分析之前，内部经过充分讨论，就粒度问题达成共识；

尽可能的从不同侧面分析（测试类型、功能交互等）测试原始需求，给出初始的测试规格，可能会产生冗余，此时不要过分要求初始测试规格的粒度统一，在测试规格整合时考虑粒度统一问题；

对于一些较为清晰的功能，相似的子功能可以组合在一起描述，作为一个测试规格对待。比如：涉及到一个表格的设置，我们可以将增加、修改、删除等作为一个测试规格，大家一目了然，没有歧异；（CRUD原则）

测试规格应该是完整地描述从用户角度出发所能看到的需求，而不是一个需求的片断，比如：彩铃业务的建立、释放是需求的片断，用户是看不到这一点的，建议这样描述：彩铃业务基本呼叫，考虑各种释放情况;对于大家常见的分析思路，可以通过经验库的形式进行传递和统一。比如：常见的组网模型、常见的用户分类以及各种用户常见的操作等等；

测试规格的描述要清晰，不能有混淆的地方，在测试方案设计阶段，可以直接对测试规格进行细化，而不用参考其他的文档即可。比如：要考虑各种异常情况下的基本呼叫功能，这个测试规格就不是十分清晰，可以进一步给出具体的异常类别形成新的测试规格，比如：要考虑主叫各种异常释放情况下的基本呼叫；要考虑A接口各种异常情况下的基本呼叫等等。

测试规格的粒度，不仅仅和测试需求分析的思路有关，而且和测试原始需求的粒度有关。建