测试需求分析课件

测试需求分析测试需求分析目录测试需求分析背景测试需求分析理论测试需求分析工程方法测试需求分析应用目录测试需求分析背景 为什么要做测试需求分析？测试了很多，还有这么多网上问题？客户到底关心什么？不知道如何站在客户立场测试？网上问题漏测：测试设计不充分>60%！这些问题怎么没有考虑到？需要做测试需求分析！ 为什么要做测试需求分析？测试了很多，还有这么多网上问题？现状？测试对象分析测试用例设计（方案内的）测试用例测试输入TR3TR4没有测试需求分析过程测试经理口头分配测试方案任务不明确测试对象分析侧重测试方案内部实现现状存在什么问题？测试过程与结果缺乏质量评估与控制过多关注功能实现、产品质量维度关注不全面没有统一成熟的分析设计工程方法支撑现状？测试对象分析测试用例设计（方案内的）测试用例测试输入T业界情况SDT公司测试分析设计IBM的测试设计七步法某路由器公司的测试阶段和测试类型MOTO故障插入测试以业界公司为标杆，建立自己的测试分析设计体系借鉴业界公司的经验，总结相关工程方法好的示例业界情况SDT公司测试分析设计以业界公司为标杆，建立自己的测测试需求分析业界介绍（SDT公司）TestFrame的测试设计模式测试划分测试需求分析测试需求分析业界介绍（SDT公司）TestFrame的测试业界思路总结测试类型测试划分强调测试需求分析，测试需求不仅仅来自需求文档电子表格是支撑测试分析设计的主要工具(我现在常用的是freemind,先分解划块儿，在分块细化)不同类型的测试会发现不同类型的Bug。测试类型是从不同的角度来分析和测试产品业界思路总结测试类型不同类型的测试会发现不同类型的Bug。测目录测试需求分析背景测试需求分析理论测试需求分析工程方法测试需求分析应用目录测试需求分析背景测试需求分析目的清晰把握测试需求！时刻关注产品质量！测试需求分析目的是：明确应该测试什么。即明确测试需求，其核心是产品质量。产品质量就是符合用户的明确的或隐含的需求的程度。需求文档中的产品需求、系统设计需求是明确的需求未在需求文档中明确的隐含的用户需求也是我们需要分析的，如用户使用产品方式、感受、业务习惯Testrequirementsareusefulsetsofinputthatshouldbetested.－－BrianMarick测试需求分析的目的？测试需求分析目的清晰把握测试需求！时刻关注产品质量！测试需求测试需求分析基本概念（1）－－测试视角测试类型功能交互产品继承分解分配测试有哪些独特的视角？测试与开发的思路有哪些不同？测试的视角体现了测试的思维活动这四个视角是工程方法的基础测试需求分析基本概念（1）－－测试视角测试类型功能交互产品继测试需求分析基本概念（2）－活动框架（1）阶段活动工程方法测试分析设计基本概念测试分析设计组织保证测试分析设计表测试需求分析基本概念（2）－活动框架（1）阶段活动工程方法测产品测试需求分析测试规格分解分配产品测试规格特性测试需求分析分配后测试规格特性测试设计测试设计维护特性测试规格测试用例设计规格协议/规范/标准测试分析经验库SRS协议/规范测试设计经验库其他输入测试需求分析测试方案设计测试用例设计测试用例设计测试用例测试用例设计维护产品分析产品包需求设计需求仅做参考测试需求分析基本概念（3）－活动框架（2）产品测试需求分析测试规格分解分配产品测试规格特性测试需求分析测试需求分析基本概念（3）－活动框架（2）产品测试需求分析特性测试需求分析特性测试设计测试用例设计SRSHLDLLDCODING测试需求分析活动类比开发活动图测试需求分析基本概念（3）－活动框架（2）产品测试需求分析特阶段产品分析测试规格分解分配特性测试需求分析特性测试设计测试用例设计活动/子活动结果输出测试需求分析测试方案设计产品测试规格分析原始需求提取产品测试需求分析测试类型分析；功能交互分析；关联图分析；测试特性建模；测试规格整合测试特性交互分析测试组网分析；判定表；因果图；测试场景分析正交测试分析法正交试验设计法等价类划分；边界值；因果图；正交试验设计法；《测试分析设计表》之需求来源表《测试分析设计表》之原始需求表《测试分析设计表》之产品测试规格表；《测试需求分析报告.doc》《××特性测试工作任务书.doc》《测试分析设计表》之特性测试规格表《测试分析设计表》之测试用例表原始需求提取方法继承性分析工程方法测试需求分析基本概念（4）－活动框架（3）阶段产品分析测试规格分解分配特性测试需求分析特性测试设计测试测试需求分析基本概念（5）－－名词解释测试原始需求：产品测试规格分析的输入，是从产品包需求、系统需求、测试经验库等需求来源中提取的经过整理的输入集合。测试规格：测试规格是产品测试规格和特性测试规格的通称。一般而言，我们所说的测试规格都是指产品测试规格。产品测试规格是对客户需求、产品包需求、设计需求、设计规格以及其它可能的需求进行综合的测试分析，从测试角度分析并整合形成的测试需求集合，明确了测试应该测试什么。产品测试规格经过相关整理后相互之间没有重复，每条产品测试规格都有唯一的标识。测试特性：逻辑上相关的产品测试规格集合，可以是功能性的产品测试规格集合，也可以是非功能性的产品测试规格集合。逻辑相关性，指的是按照一定的规则进行划分，这个规则是个广义的规则，区别于开发按照功能进行划分的特性。测试需求分析基本概念（5）－－名词解释测试原始需求：产品测试测试需求分析活动（1）－产品分析产品分析主要是产品知识前期学习和熟悉确定产品测试需求分析的来源确定测试分析设计策略这个产品/版本是什么？赶紧学习相关资料！下一步如何分析？测试需求分析活动（1）－产品分析产品分析主要是产品知识前期学分析方法有两种形式：先标记后分析、直接分析防止有交互作用的功能的遗漏，提高功能测试的完备性测试参与开发文档评审的一个原则是，必须先要输出自己的交付件，才能参加开发的文档评审：建议对于测试原始需求也要进行整理、合并、分解，只罗列从用户角度所看到的功能和非功能，其他的细节可以作为这些内容的附件，在测试需求分析中考虑。子系统：子系统是一些逻辑相关的模块集合，可以包括多个模块。LCD需提供背景灯，当有来电和短消息、Email时均能自动点亮说明： 表示该测试类型的主要的测试阶段；《测试分析设计表》之特性测试规格表《测试分析设计表》之特性测试规格表如果原始测试规格A/B合并成一条测试规格X,则其中只有一个是新增，其它都是合并。测试的视角体现了测试的思维活动测试特性划分：由于开发和测试之间的分解分配思路不一样，测试需要从提高测试设计与执行的质量和效率出发建立测试自己的模型，避免测试按照设计规格分解分配思路（模块）来分配测试方案，从功能和测试类型两个角度进行测试特性划分，划分过程中考虑以下几个方面的因素：产品测试规格是对客户需求、产品包需求、设计需求、设计规格以及其它可能的需求进行综合的测试分析，从测试角度分析并整合形成的测试需求集合，明确了测试应该测试什么。测试特性划分：由于开发和测试之间的分解分配思路不一样，测试需要从提高测试设计与执行的质量和效率出发建立测试自己的模型，避免测试按照设计规格分解分配思路（模块）来分配测试方案，从功能和测试类型两个角度进行测试特性划分，划分过程中考虑以下几个方面的因素：测试高级工程师（STE）测试组应该建立并不断完善自己的测试类型库。CALL-BASE-CALLED-001测试类型评估（不同测试类型的比率）对于大家常见的分析思路，可以通过经验库的形式进行传递和统一。负责设计规格－测试规格－测试特性的需求跟踪测试需求分析活动（2）－提取测试原始需求子活动准备（分工组织、提取策略）提取测试原始需求测试原始需求整理确定测试规格分析工程方法测试经验库开发需求协议和规范用户需求继承产品需求测试原始需求测试原始需求测试原始需求直接提取继承性分析直接提取直接提取直接提取分工合作确定工程方法合理规整测试原始需求分析方法有两种形式：先标记后分析、直接分析测试需求分析活动（子活动准备（分工组织、工程方法应用策略）运用工程方法进行分析，得出初始的产品测试规格：测试类型分析、功能交互分析、关联图分析、其他分析方法测试特性建模:从测试角度，划分出测试特性，并对初始的测试规格进行整合，按照测试特性进行归类，得到最终具有完整属性的产品测试规格。修正测试原始需求测试类型分析 功能交互分析关联图分析 其他工程方法初始产品测试规格测试特性建模测试特性测试规格整合产品测试规格修正修正测试原始需求测试类型分析 功能交互分析关联图分析 其他工程方法初始产品测试规格测试特性测试规格整合产品测试规格测试特性建模测试特性建模时机的不同产生两种活动方式测试需求分析活动（3）－产品测试规格分析子活动准备（分工组织、工程方法应用策略）修正测试原始需求测试测试需求分析活动（4）－测试规格分解分配通过测试特性建模形成测试特性产品测试规格分解分配到测试特性以测试特性为单位进行测试方案设计以测试方案设计任务书形式交付测试方案设计阶段测试方案设计任务书测试特性3测试特性2测试特性1产品测试规格测试需求分析活动（4）－测试规格分解分配通过测试特性建模形成测试分析设计评估质量测试用例密度覆盖率ODC评估（不同触发因素的比率）测试类型评估（不同测试类型的比率）测试用例/每千行代码不同设计规格的覆盖率（2/8原则）设计规格的覆盖率测试需求分析活动（5）－测试规格评估测试分析设计评估质量测试用例密度覆盖率ODC评估（不同触发因评估方法评估思路适用范围备注测试类型评估不同测试类型能否发现不同类型的缺陷，依据测试类型来评估测试分析设计工作是非常必要的，我们必须在产品初期就要规划测试类型，以期尽可能的发现所有相关类型的缺陷，而不是发现某几种类型的缺陷针对产品测试规格评估，可以发现测试需求分析中的问题。每种测试类型的比率是否合适，需要建立一个基线设计规格覆盖率所有的设计规格都应该覆盖，但是由于部分设计规格不适合做系统测试或者没有相关测试手段，对于这部分设计规格需要明确提出。针对产品测试规格进行评估，可以给出系统测试可以验证的覆盖率对于不能测试的设计规格，应该提出相应的验证方法（检视、单元测试等等），这是一种风险，另外，这些设计规格也是可测试性需求的一部分不同设计规格的覆盖率每个设计规格的使用频率和发生错误的可能性都不一样，对于风险较大的设计规格，应该依据2/8原则，会设计更多的测试用例。基于这种思路来评估，可以确定我们的设计重点针对产品测试规格评估，明确那些测试规格是重点。这种评估可以测试方案设计的策略测试需求分析活动（6）－测试规格评估评估方法评估思路适用范围备注测试类型评估不同测试类型能否发现客户需求产品包需求设计需求设计规格SRSHLDLLDMSTMITMUT产品测试规格测试特性特性测试规格测试用例TSE负责跟踪PL负责跟踪测试要同时验证客户需求、产品包需求、设计需求测试需求分析活动（7）－测试规格跟踪客户需求产品包需求设计需求设计规格SRSHLDLLDMSTM

通过编号方案可以弄清楚测试分析设计输出之间的关系，建立一个跟踪体系。需求来源：来源编码＋XXX原始需求：特性编码＋XXX初始产品测试规格：工程方法编码-子类编码-XXX产品测试规格：测试特性编码-大类编码-[子类编码]-XXX特性测试规格：测试特性编码-XXX测试用例：特性测试规格编号-XXX测试需求分析活动（8）－测试规格编号方案 通过编号方案可以弄清楚测试分析设计输出之间的关系，建立一为什么有测试规格维护？产品测试规格基线化；测试输入产生变更！开发类来源：变更的客户需求产品包需求产品设计需求设计规格概要设计详细设计代码测试类来源：变更的测试经验库测试方案测试报告等更新的基线化输出－产品测试规格、测试用例；总结的经验输出到测试经验库中，更新的测试经验库的相关内容也是一个输出；在《测试需求分析报告》、《测试方案》中对于测试分析与设计维护活动的过程和内容的记录；测试规格维护输入输出测试需求分析活动（9）－测试规格维护为什么有测试规格维护？产品测试规格基线化；开发类来源：更新目录测试需求分析背景测试需求分析理论测试需求分析工程方法测试需求分析应用目录测试需求分析背景测试需求分析工程方法概图产品分析指导书继承性分析工程方法原始测试需求提取指导书需求来源表原始需求表测试类型分析工程方法功能交互分析工程方法关联图分析工程方法产品测试规格分析指导书产品测试规格表(未划分测试特性)测试特性建模工程方法测试规格整合工程方法产品测试规格表(划分测试特性)测试规格分解分配指导书测试特性方案设计任务书测试特性交互分析工程方法测试需求分析工程方法概图产品分析指导书继承性分析工程方法原始能够支持电子邮件的收发关于测试规格粒度的理解（1）失效影响度：特性使用频度、特性重要性。测试特性和开发特性有区别吗？为什么有测试规格维护？测试类型是从不同的角度来分析和测试产品在参与开发评审前，测试应该完成了自己的输出，带着问题参加评审，效果就会不同，参与评审，也是为了解答自己的问题。低粒度的测试方案为测试人员提供一般的系统行为信息填写可能相互影响点描述确定产品测试需求分析的来源TSE召集讨论确定测试类型及其子类型LCD需提供背景灯，当有来电和短消息、Email时均能自动点亮CALL-BASE-CALLED-002测试类型分析,功能交互分析测试特性建模时机的不同产生两种活动方式没有统一成熟的分析设计工程方法支撑失效影响度：特性使用频度、特性重要性。《测试分析设计表》之特性测试规格表测试方案设计工作任务书测试特性建模时机的不同产生两种活动方式推荐的工程方法

虽然说上面提到的工程方法都是一种参考，大家可以依据实际情况选用，但是从测试视角出发，在测试规格的分析活动中，推荐以下三种工程方法：

继承性分析

测试类型分析功能交互分析能够支持电子邮件的收发推荐的工程方法 虽然说上面提到的工程方一、继承性分析一、继承性分析应用背景目前开发的新版本有一个基础版本，他们之间的关系如何？新版本测试策略又是如何制定的？新增和继承特性什么关系？新增了什么？继承了什么？该测试哪些？

版本B版本A特性1特性2新增特性新增特性新增特性应用背景目前开发的新版本有一个基础版本，他们之间的关系如何分析思路（1）输入：需求来源表历史版本的测试报告历史版本的产品的特性清单及其说明等其它可供参考的资料输出：测试策略建议新增原始需求需要进行功能交互分析的继承特性其它一些过程输出网上使用情况历史测试情况应用变化情况交互成熟度失效影响度测试策略建议新增测试原始需求需要作功能交互分析的继承特性变化独立继承特性现状分析特性交互关系分析版本B版本A新增特性新增特性继承特性继承特性新增特性分析思路（1）输入：输出：网上使用情况交互成熟度测试策略建议分析思路（2）来源编号继承特性失效影响度成熟度继承方式IR001XXX特性交互IR001YYY特性变化IR001ZZZ特性独立IR001MMM特性交互，变化

失效影响度：特性使用频度、特性重要性。

成熟度：经过测试的V/R版本数、网上应用情况反馈（应用性质、应用范围、网上问题数量）。

继承方式：独立、交互、变化或者组合。分析思路（2）来源编号继承特性失效影响度成熟度继承方式IR0过程与结果来源编号继承特性新特性1新特性2..新特性nIR001XXX特性填写可能相互影响点描述IR001YYY特性同上IR001ZZZ特性同上IR001MMM特性同上继承特性与新特性交互分析表来源编号继承特性应用变化1应用变化2..应用变化nIR001XXX特性应用变化情况1应用变化情况2应用变化情况3IR001YYY特性同上IR001ZZZ特性同上来源编号继承特性继承方式影响点说明IR001XXX特性交互IR001YYY特性变化IR001ZZZ特性交互，变化来源编号继承特性测试建议1测试建议2..IR001XXX特性测试建议1测试建议2IR001YYY特性同上IR001ZZZ特性同上继承特性变化分析表需要交互的继承特性继承特性测试建议表继承特性失效影响度分析继承特性成熟度分析交互独立变化过程与结果来源编号继承特性新特性1新特性2..新特性nIR0二、测试类型分析二、测试类型分析应用背景产品应用中出现的问题有各种方面…效率易用性可靠性功能性可维护性可移植性质量模型升级扩容不便？界面太差、操作烦杂？定位问题手段少？……类似如下情况：其实质量是多维的那么如何发现各类问题呢？测试类型分析!不能仅有功能测试功能异常？应用背景产品应用中出现的问题有各种方面…可靠性功能性可移植性分析思路（1）－－基本过程TSE召集讨论确定测试类型及其子类型明确各测试类型分析思路控制分析的粒度分析思路（1）－－基本过程TSE召集讨论确定测试类型及其子类分析思路（2）－－使用阶段测试类型SDVSIT功能测试●一致性测试●安全性测试●性能测试●压力测试配置测试安装测试●恢复测试长时间测试系统指标测试●易用性测试备份测试●大容量测试●流控测试●兼容测试●互操作测试●说明： 表示该测试类型的主要的测试阶段；

●表示对应测试阶段有该测试类型或回归测试针对不同的测试阶段，使用不同的测试类型：分析思路（2）－－使用阶段测试类型SDVSIT功能测试●测试需求分析基本概念（3）－活动框架（2）测试特性的介绍及相应产品测试规格列表针对不同的测试阶段，使用不同的测试类型：更新的基线化输出－产品测试规格、测试用例；测试的视角体现了测试的思维活动填写可能相互影响点描述如果原始测试规格A/B合并成一条测试规格X,则其中只有一个是新增，其它都是合并。RF-HOST-001确定产品测试需求分析的来源测试需求分析基本概念（2）－活动框架（1）如何合理的划分子系统，需要参考系统架构设计。Build（SDV）测试执行策略需要考虑如何回归，并保证功能交互测试的完备性；对测试类型分析、功能交互分析的结果进行补充测试类型分析,功能交互分析分析思路（1）－－交互关系LCD需提供背景灯，当有来电和短消息、Email时均能自动点亮在参与开发评审前，测试应该完成了自己的输出，带着问题参加评审，效果就会不同，参与评审，也是为了解答自己的问题。Build（SDV）测试执行策略需要考虑如何回归，并保证功能交互测试的完备性；新版本测试策略又是如何制定的？测试特性建模的主要目的是划分测试特性，明确每个测试特性的内容和边界。分析思路（3）－－建立测试类型库测试类型分析法是从不同的角度来分析和测试产品，不同类型的测试会发现不同类型的Bug，每类测试类型的测试方法也会不同；通过测试类型的建立，我们可以对整个产品的测试有一个系统的思路，而不是仅仅关注功能测试；测试组应该建立并不断完善自己的测试类型库。多发现25%的测试需求业界公司都建立了完整的测试类型库拓展了测试思路测试需求分析基本概念（3）－活动框架（2）分析思路（3）－－三、功能交互分析三、功能交互分析产品功能不是独立的，功能之间存在交互防止有交互作用的功能的遗漏，提高功能测试的完备性是功能测试方面的分析，与测试类型分析形成互补应用背景产品其他相关功能被测功能功能交互产品功能不是独立的，功能之间存在交互应用背景产品其他相关功能分析思路（1）－－交互关系交互点原始需求与功能特性关系影响与约束时序关系影响（时间、时序）功能之间存在顺序关系功能之间存在交互关系共享关系影响（数据和资源）共享数据影响共享资源影响分析思路（1）－－交互关系交互点原始需求与功能特性关系影响与分析思路（2）－－基本过程横轴是新增特性和继承特性，继承特性来自于继承性分析的结果分析方法有两种形式：先标记后分析、直接分析功能交互分析的结果可以作为测试类型分析的输入，但是操作复杂，不建议这样应用分析思路（2）－－基本过程横轴是新增特性和继承特性，继承特性四、关联图分析四、关联图分析从用户角度出发来关注每个用户如何使用被测功能特性如何影响被测功能特性对测试类型分析、功能交互分析的结果进行补充应用背景从用户角度出发来关注每个用户应用背景分析思路对象用户2用户1用户3用户1对对象的影响对象对用户1的影响用户4用户3对对象的影响对象对用户3的影响用户4对对象的影响对象对用户4的影响用户2对对象的影响对象对用户2的影响确定用户：对象与外部实体/端点确定相互联系的数据流、物流、行为依据不同的用户类和响应的影响因素，输出测试规格用户类可以是执行者，也可以是应用软件、系统硬件、目标实体、接口实体或者三维空间、时间等。分析思路对象用户2用户1用户3用户1对对象的影响用户4用户3分析样例特性用户类产品测试规格编号产品测试规格定义指定用户BAM打印维护人员RF-OPERATOR-001设置不同的打印方式RF-OPERATOR-002设置不同的打印级别RF-OPERATOR-003各种界面操作主机/PCRF-HOST-001主机各种复位影响RF-HOST-002PC关机复位影响用户跟踪RF-TRACE-001不影响用户跟踪RF-TRACE-002不影响BAM打印局域网络RF-LAN-001局域网故障影响业务实体RF-SERVICE-001各种典型流程的打印分析样例特性用户类产品测试规格编号产品测试规格定义指定用户B五、测试特性建模五、测试特性建模在参与开发评审前，测试应该完成了自己的输出，带着问题参加评审，效果就会不同，参与评审，也是为了解答自己的问题。如何合理的划分子系统，需要参考系统架构设计。要考虑A接口各种异常情况下的基本呼叫等等。CALL-BASE-SEPC-001不同类型的测试会发现不同类型的Bug。防止有交互作用的功能的遗漏，提高功能测试的完备性失效影响度：特性使用频度、特性重要性。CALL-BASE-CALLED-001电子表格是支撑测试分析设计的主要工具(我现在常用的是freemind,先分解划块儿，在分块细化)CALL-BASE-CALLED-002TSE是测试分析设计的灵魂人物，他组织产品的技术决策，职责是：LCD能够显示手机的状态、错误信息、呼叫状态、号码RF-TRACE-001负责测试需求分析阶段的相关活动测试需求分析应用样例（2）－基本过程特性测试规格：测试特性编码-XXXBuild（SDV）测试执行策略需要考虑如何回归，并保证功能交互测试的完备性；分析思路（1）－－基本过程测试需求分析活动（1）－产品分析T测试类型独特虽然和测试特性有关系，但是有自己的独特测试方法，建议独立划分到非功能测试特性应用背景测试特性和开发特性有区别吗？如何合理划分测试方案？在参与开发评审前，测试应该完成了自己的输出，带着问题参加评审全局因素：指对大部分特性都有影响的因素，这里指的因素是泛义的，可以是具体的硬件，也可以是软件实体，或者是逻辑实体，只要它们的变化对大部分特性有影响就可以确定是全局因素。子系统：子系统是一些逻辑相关的模块集合，可以包括多个模块。平时常说的子系统，比如：话统子系统、话单子系统、维护子系统等等，就属于这个范畴。如何合理的划分子系统，需要参考系统架构设计。基本概念（1）全局因素：指对大部分特性都有影响的因素，这里指的因素是泛义的测试特性划分：由于开发和测试之间的分解分配思路不一样，测试需要从提高测试设计与执行的质量和效率出发建立测试自己的模型，避免测试按照设计规格分解分配思路（模块）来分配测试方案，从功能和测试类型两个角度进行测试特性划分，划分过程中考虑以下几个方面的因素：开发特性或者功能Build划分系统架构（模块）全局因素或者技术风险分析测试组人员技能基本概念（2）测试特性划分：由于开发和测试之间的分解分配思路不一样，测试需SDV/SIT所有的测试用例分布在不同的测试特性中，随着每个Build构建完成，需要确定SDV/SIT测试策略；Build（SDV）测试执行策略需要考虑如何回归，并保证功能交互测试的完备性；图例中，BuildB首先需要对BuildA进行回归，确保BuildA没有出现新问题，同时补充测试两者之间的功能交互的测试用例，然后再执行测试特性3和测试特性4的相关测试用例。测试特性1测试特性2测试特性3测试特性4测试特性5测试特性6BuildABuildBBuildCTR4测试策略划分测试特性SDV/SIT策略决定测试用例如何执行基本概念（3）SDV/SIT所有的测试用例分布在不同的测试特性中，随着每个基本过程（1）测试特性分解分配测试规格测试类型全局因素……测试方案设计任务书测试特性模型测试特性建模的主要目的是划分测试特性，明确每个测试特性的内容和边界。原则上，一个测试方案对应一个测试特性。基本过程（1）测试特性分解分配测试规格测试类型全局因素……测子系统1子系统2子系统3子系统4子系统5全局因素1全局因素2全局因素3全局因素4测试特性功能1TCCCC功能测试特性1功能2CTCS功能测试特性2功能3TCXCC功能测试特性3功能4CCTSC功能测试特性3功能5CTCTCC功能测试特性5测试特性功能测试特性6功能测试特性8功能测试特性9T对应的功能和子系统关联密切，主要实现在该子系统中，适合在该功能的测试特性中测试，强调以功能为主导的思想。C功能和该子系统有接口，关系比较松散，可以将该子系统作为检查点对待X对应的功能和子系统关系松散，子系统可以作为功能测试特性的主要检查点;但是为确保这种关系深入测试，在子系统或者全局因素特性中，要作为主要内容进行测试S对应的功能和子系统关联松散，不过子系统作为功能测试特性的检查点不合适，在子系统或者全局因素特性中，要作为主要内容进行测试基本过程（2）子系统1子系统2子系统3子系统4子系统5全局因素1全局因素2功能测试特性1功能测试特性2功能测试特性3功能测试特性4功能测试特性5功能测试特性6功能测试特性7测试特性测试类型1TTTTTTT非功能测试特性1测试类型2TTTTT非功能测试特性2；非功能测试特性4测试类型3OOOOOO测试类型4NNNNNNN非功能测试特性3测试类型5XXTTT非功能测试特性5T测试类型独特虽然和测试特性有关系，但是有自己的独特测试方法，建议独立划分到非功能测试特性X测试类型一部分和功能测试特性关系密切，测试方法和功能测试相同，这部分适合放在功能测试特性中测试，一部分有自己独特的测试方法，建议独立划分非功能测试特性。O测试类型和功能测试特性关系密切，测试方法和功能测试相同，建议划分到相应的功能测试特性中。N测试类型和功能测试特性关系不紧密，需要单独划分非功能测试特性基本过程（3）功能测试特性1功能测试特性2功能测试特性3功能测试特性4功能分析样例分析样例六、测试规格整合六、测试规格整合应用背景测类型分析功能交互分析关联图分析初始产品测试规格存在很多冗余没有跟踪关系测试规格整合应用背景测类型分析功能交互分析关联图分析初始产品测试规格存在关联图分析 其他工程方法LCD能够显示手机的状态、错误信息、呼叫状态、号码测试过程与结果缺乏质量评估与控制N测试类型和功能测试特性关系不紧密，需要单独划分非功能测试特性RF-OPERATOR-003为什么有测试规格维护？LCD需提供背景灯，当有来电和短消息、Email时均能自动点亮原始需求：特性编码＋XXX测试的视角体现了测试的思维活动如何合理的划分子系统，需要参考系统架构设计。测试需求分析应用样例（2）－基本过程测试过程与结果缺乏质量评估与控制Repeated：该测试规格已存在“纯”结构化（白盒）测试测试粒度是指一个测试焦点的精细度或粗糙度如果原始测试规格A/B合并成一条测试规格X,则其中只有一个是新增，其它都是合并。因此，在TR2时，必须先完成测试规格。测试类型分析,功能交互分析落实设计需求（设计规格）、测试规格、特性测试规格、测试用例的跟踪测试特性方案设计任务书基本思路测试建模测试特性树建立测试规格分配测试规格合并测试规格整合如果建模不能满足要求如果特性树遗漏根据特性整合要求删除冗余和合并测试规格测试规格分析1.松散的测试规格2.特性树3.已分配测试规格4.合并后测试规格5.整合后测试规格测试规格分解分配关联图分析 其他工程方法基本思路测试建模测试特性树建立测试规测试规格整合样例New：在测试规格中新增一项测试规格Repeated：该测试规格已存在Combined：将测试规格归入到一条已经存在的测试需求。如果原始测试规格A/B合并成一条测试规格X,则其中只有一个是新增，其它都是合并。测试规格整合样例New：在测试规格中新增一项测试规格目录测试需求分析背景测试需求分析理论测试需求分析工程方法测试需求分析应用目录测试需求分析背景什么时候进行测试需求分析？产品测试需求分析测试规格分解分配产品测试规格特性测试需求分析分配后测试规格特性测试规格特性测试设计测试项系统规格SRS（参考）测试用例设计测试用例TR2产品分析产品包需求TR1TR3TR4什么时候进行测试需求分析？产品测试需求分析测试规格分解分配产测试参与TR的方式测试参与开发文档评审的一个原则是，必须先要输出自己的交付件，才能参加开发的文档评审：先有测试分析，后有开发文档评审参与在参与开发评审前，测试应该完成了自己的输出，带着问题参加评审，效果就会不同，参与评审，也是为了解答自己的问题。因此，在TR2时，必须先完成测试规格。保留评审不改问题的测试规格测试参与评审提出的问题，开发答复不需要修改或者风险较小，这部分的测试规格也应该保留，只是不用进行分配和测试。如果网上发现问题和这些内容相关，测试就有据可查，是风险分析的一个参考内容。测试参与TR的方式测试参与开发文档评审的一个原则是，必须先要测试需求分析应用原则测试需求分析报告产品分析测试规格分解分配产品测试规格分析测试原始需求提取需求来源表测试原始需求表产品测试规格表测试方案设计工作任务书过程记录和结果分开（《测试需求分析报告》与结果表《测试分析设计表》分开）活动可以裁减，工程方法是参考，工程方法有一定的使用环境每个工程方法都有明确的输出，但是每个活动的结果可以脱离于工程方法结果表输出过程记录输出工程方法测试需求分析应用原则测试需求分析报告产品分析测试规格分解分配关于测试规格的理解业界公司的实践提出，不管设计规格是否完善都要建立测试需求，我们称为测试规格；测试规格是测试对于产品设计规格分析之后的产物；测试分析设计整体思路都是围绕着测试规格来开展的；如果产品设计规格是测试的“客户需求”，那么测试规格就是测试的“产品设计规格”；关于测试规格的理解业界公司的实践提出，不管设计规格是否完善都测试粒度是指一个测试焦点的精细度或粗糙度测试粒度是一个谱，而不是一系列的“是…/或…”类别一个高粒度的测试方案允许测试人员检查低级别的细节，一般是系统的内部；低粒度的测试方案为测试人员提供一般的系统行为信息“纯”结构化（白盒）测试“纯”行为化（黑盒）测试“纯”现场测试开发测试技术支援关于测试规格粒度的理解（1）测试粒度是指一个测试焦点的精细度或粗糙度“纯”结构化（白盒测试规格的粒度应该把握灰度原则，建议各测试组在进行需求分析之前，内部经过充分讨论，就粒度问题达成共识；尽可能的从不同侧面分析（测试类型、功能交互等）测试原始需求，给出初始的测试规格，可能会产生冗余，此时不要过分要求初始测试规格的粒度统一，在测试规格整合时考虑粒度统一问题；对于一些较为清晰的功能，相似的子功能可以组合在一起描述，作为一个测试规格对待。比如：涉及到一个表格的设置，我们可以将增加、修改、删除等作为一个测试规格，大家一目了然，没有歧异；（CRUD原则）测试规格应该是完整地描述从用户角度出发所能看到的需求，而不是一个需求的片断，比如：彩铃业务的建立、释放是需求的片断，用户是看不到这一点的，建议这样描述：彩铃业务基本呼叫，考虑各种释放情况把握灰度用户可见关于测试规格粒度的理解（2）测试规格的粒度应该把握灰度原则，建议各测试组在进行需求分析之对于大家常见的分析思路，可以通过经验库的形式进行传递和统一。比如：常见的组网模型、常见的用户分类以及各种用户常见的操作等等；测试规格的描述要清晰，不能有混淆的地方，在测试方案设计阶段，可以直接对测试规格进行细化，而不用参考其他的文档即可。比如：要考虑各种异常情况下的基本呼叫功能，这个测试规格就不是十分清晰，可以进一步给出具体的异常类别形成新的测试规格，比如：要考虑主叫各种异常释放情况下的基本呼叫；要考虑A接口各种异常情况下的基本呼叫等等。测试规格的粒度，不仅仅和测试需求分析的思路有关，而且和测试原始需求的粒度有关。建议对于测试原始需求也要进行整理、合并、分解，只罗列从用户角度所看到的功能和非功能，其他的细节可以作为这些内容的附件，在测试需求分析中考虑。比如：支持彩铃业务的触发、建立，可以合并为彩铃业务的基本呼叫（触发、建立作为附件）。前后联系传递经验积累约定关于测试规格粒度的理解（3）对于大家常见的分析思路，可以通过经验库的形式进行传递和统一。测试经理(PM)项目经理(PL)测试工程师(TE)项目经理(PL)项目经理(PL)测试工程师(TE)测试工程师(TE)测试工程师(TE)测试工程师(TE)测试系统工程师(TSE)项目经理（PL）测试高级工程师（STE）TSE是测试分析设计的灵魂人物，他组织产品的技术决策，职责是：负责测试需求分析阶段的相关活动对最终的产品测试规格完备性、正确性负责负责设计规格－测试规格－测试特性的需求跟踪负责划分测试特性，确保合理性和完备性指导测试方案设计工作测试需求分析的组织与职责测试经理(PM)项目经理(PL)测试工程师(TE)项目经理产品分析原始需求提取产品测试规格分析质量评估测试规格分解分配TSE任务分工选择模型组建测试系统组Chart客户需求；产品规模；人力资源；测试组模式测试分析设计模型；测试需求分析报告客户需求；产品包需求；规范协议；经验库需求来源表；测试需求分析报告测试规格基线化客户需求；产品包需求；规范协议；经验库；继承特性原始需求表；继承特性；测试需求分析报告；继承特性；原始需求表；测试类型；全局因素产品测试规格；测试特性；测试需求分析报告产品测试规格测试特性方案设计任务书产品测试规格测试特性测试需求分析应用样例（2）－基本过程产品分析原始需求提取产品测试规格分析质量评估测试规格分解分配原始需求来源文档名称来源编号开发需求MINI988设计需求样例.DOCDR001开发需求MINI988E2EOR.XLSDR002开发需求MINI988设计规格样例.DOCDR003用户需求MINI988E2EOR-bussiness.XLSUR001需求来源表：样例开发需求？用户需求？协议和规范？测试经验库？继承产品需求？测试需求分析应用样例（3）－产品分析原始需求来源文档名称来源编号开发需求MINI988设计需求样开发需求用户需求协议和规范测试经验库继承产品需求需求来源样例测试原始需求编号测试原始需求描述开发特性需求标识需求描述需求优先级测试规格分析的工程方法需求是否实现EMAIL-001能够支持电子邮件的收发EmailOR_MKT.00010能够支持电子邮件的收发H测试类型分析,功能交互分析需实现LCD-001LCD能够显示手机的状态、错误信息、呼叫状态、号码LCDOR_SPT.00011通过LCD可以查看手机中的各种状态和错误信息H测试类型分析,功能交互分析需实现LCD手机应该支持显示输入的号码（0-9#*：

字母），手机状态，呼叫状态。H测试类型分析,功能交互分析需实现LCD-002LCD需提供背景灯，当有来电和短消息、Email时均能自动点亮LCDOR_MKT.00028LCD需提供背景灯，当有来电和短消息、Email时均能自动点亮M测试类型分析,功能交互分析需实现SIM-001支持PIN码和PIN2码，以保护手机中的信息安全。SIM卡支持PIN码和PIN2码，以保护手机中的信息安全。H测试类型分析,功能交互分析需实现测试策略建议测试原始需求表测试需求分析应用样例（4）－提取原始需求开发需求用户需求协议和规范测试经验库继承产品需求需求来源样例测试原始需求编号测试特性产品测试规格编号产品测试规格描述测试类型验证方法优先级估计用例规模TEL-001语音呼叫CALL-BASE-CALLER-001手机作为主叫，呼叫其他用户功能测试系统测试H10TEL-001语音呼叫CALL-BASE-SEPC-001手机作为主叫呼叫特殊号码功能测试系统测试H5TEL-001语音呼叫CALL-BASE-CALLED-001手机作为被叫，接听电话功能测试系统测试H10TEL-001语音呼叫CALL-BASE-CALLED-002手机作为被叫，拒绝电话功能测试系统测试M5样例修正修正测试原始需求初始产品测试规格测试特性测试规格整合产品测试规格测试特性建模关联图分析其他工程方法分析测试类型分析功能交互分析测试需求分析应用样例（5）－测试规格分析测试原始需求编号测试特性产品测试规格编号产品测试规格描述测试通过LCD可以查看手机中的各种状态和错误信息运用工程方法进行分析，得出初始的产品测试规格：测试类型分析、功能交互分析、关联图分析、其他分析方法测试需求分析基本概念（2）－活动框架（1）比如：支持彩铃业务的触发、建立，可以合并为彩铃业务的基本呼叫（触发、建立作为附件）。全局因素或者技术风险分析测试需求分析活动（3）－产品测试规格分析分析思路（1）－－基本过程落实设计需求（设计规格）、测试规格、特性测试规格、测试用例的跟踪关于测试规格粒度的理解（1）这种评估可以测试方案设计的策略测试需求分析的组织与职责每个设计规格的使用频率和发生错误的可能性都不一样，对于风险较大的设计规格，应该依据2/8原则，会设计更多的测试用例。传递测试需求分析的思想、落实测试方案设计策略测试过程与结果缺乏质量评估与控制每种测试类型的比率是否合适，需要建立一个基线测试粒度是一个谱，而不是一系列的“是…/或…”类别明确各测试类型分析思路没有统一成熟的分析设计工程方法支撑RF-TRACE-001测试需求分析活动（6）－测试规格评估产品测试规格测试特性测试规格分解分配测试方案设计工作任务书传递测试需求分析的思想、落实测试方案设计策略落实设计需求（设计规格）、测试规格、特性测试规格、测试用例的跟踪测试特性的介绍及相应产品测试规格列表测试方案设计策略具体个测试方案设计工作任务安排测试需求分析应用样例（6）－规格分解分配通过LCD可以查看手机中的各种状态和错误信息产品测试规格测试测试需求分析测试需求分析目录测试需求分析背景测试需求分析理论测试需求分析工程方法测试需求分析应用目录测试需求分析背景 为什么要做测试需求分析？测试了很多，还有这么多网上问题？客户到底关心什么？不知道如何站在客户立场测试？网上问题漏测：测试设计不充分>60%！这些问题怎么没有考虑到？需要做测试需求分析！ 为什么要做测试需求分析？测试了很多，还有这么多网上问题？现状？测试对象分析测试用例设计（方案内的）测试用例测试输入TR3TR4没有测试需求分析过程测试经理口头分配测试方案任务不明确测试对象分析侧重测试方案内部实现现状存在什么问题？测试过程与结果缺乏质量评估与控制过多关注功能实现、产品质量维度关注不全面没有统一成熟的分析设计工程方法支撑现状？测试对象分析测试用例设计（方案内的）测试用例测试输入T业界情况SDT公司测试分析设计IBM的测试设计七步法某路由器公司的测试阶段和测试类型MOTO故障插入测试以业界公司为标杆，建立自己的测试分析设计体系借鉴业界公司的经验，总结相关工程方法好的示例业界情况SDT公司测试分析设计以业界公司为标杆，建立自己的测测试需求分析业界介绍（SDT公司）TestFrame的测试设计模式测试划分测试需求分析测试需求分析业界介绍（SDT公司）TestFrame的测试业界思路总结测试类型测试划分强调测试需求分析，测试需求不仅仅来自需求文档电子表格是支撑测试分析设计的主要工具(我现在常用的是freemind,先分解划块儿，在分块细化)不同类型的测试会发现不同类型的Bug。测试类型是从不同的角度来分析和测试产品业界思路总结测试类型不同类型的测试会发现不同类型的Bug。测目录测试需求分析背景测试需求分析理论测试需求分析工程方法测试需求分析应用目录测试需求分析背景测试需求分析目的清晰把握测试需求！时刻关注产品质量！测试需求分析目的是：明确应该测试什么。即明确测试需求，其核心是产品质量。产品质量就是符合用户的明确的或隐含的需求的程度。需求文档中的产品需求、系统设计需求是明确的需求未在需求文档中明确的隐含的用户需求也是我们需要分析的，如用户使用产品方式、感受、业务习惯Testrequirementsareusefulsetsofinputthatshouldbetested.－－BrianMarick测试需求分析的目的？测试需求分析目的清晰把握测试需求！时刻关注产品质量！测试需求测试需求分析基本概念（1）－－测试视角测试类型功能交互产品继承分解分配测试有哪些独特的视角？测试与开发的思路有哪些不同？测试的视角体现了测试的思维活动这四个视角是工程方法的基础测试需求分析基本概念（1）－－测试视角测试类型功能交互产品继测试需求分析基本概念（2）－活动框架（1）阶段活动工程方法测试分析设计基本概念测试分析设计组织保证测试分析设计表测试需求分析基本概念（2）－活动框架（1）阶段活动工程方法测产品测试需求分析测试规格分解分配产品测试规格特性测试需求分析分配后测试规格特性测试设计测试设计维护特性测试规格测试用例设计规格协议/规范/标准测试分析经验库SRS协议/规范测试设计经验库其他输入测试需求分析测试方案设计测试用例设计测试用例设计测试用例测试用例设计维护产品分析产品包需求设计需求仅做参考测试需求分析基本概念（3）－活动框架（2）产品测试需求分析测试规格分解分配产品测试规格特性测试需求分析测试需求分析基本概念（3）－活动框架（2）产品测试需求分析特性测试需求分析特性测试设计测试用例设计SRSHLDLLDCODING测试需求分析活动类比开发活动图测试需求分析基本概念（3）－活动框架（2）产品测试需求分析特阶段产品分析测试规格分解分配特性测试需求分析特性测试设计测试用例设计活动/子活动结果输出测试需求分析测试方案设计产品测试规格分析原始需求提取产品测试需求分析测试类型分析；功能交互分析；关联图分析；测试特性建模；测试规格整合测试特性交互分析测试组网分析；判定表；因果图；测试场景分析正交测试分析法正交试验设计法等价类划分；边界值；因果图；正交试验设计法；《测试分析设计表》之需求来源表《测试分析设计表》之原始需求表《测试分析设计表》之产品测试规格表；《测试需求分析报告.doc》《××特性测试工作任务书.doc》《测试分析设计表》之特性测试规格表《测试分析设计表》之测试用例表原始需求提取方法继承性分析工程方法测试需求分析基本概念（4）－活动框架（3）阶段产品分析测试规格分解分配特性测试需求分析特性测试设计测试测试需求分析基本概念（5）－－名词解释测试原始需求：产品测试规格分析的输入，是从产品包需求、系统需求、测试经验库等需求来源中提取的经过整理的输入集合。测试规格：测试规格是产品测试规格和特性测试规格的通称。一般而言，我们所说的测试规格都是指产品测试规格。产品测试规格是对客户需求、产品包需求、设计需求、设计规格以及其它可能的需求进行综合的测试分析，从测试角度分析并整合形成的测试需求集合，明确了测试应该测试什么。产品测试规格经过相关整理后相互之间没有重复，每条产品测试规格都有唯一的标识。测试特性：逻辑上相关的产品测试规格集合，可以是功能性的产品测试规格集合，也可以是非功能性的产品测试规格集合。逻辑相关性，指的是按照一定的规则进行划分，这个规则是个广义的规则，区别于开发按照功能进行划分的特性。测试需求分析基本概念（5）－－名词解释测试原始需求：产品测试测试需求分析活动（1）－产品分析产品分析主要是产品知识前期学习和熟悉确定产品测试需求分析的来源确定测试分析设计策略这个产品/版本是什么？赶紧学习相关资料！下一步如何分析？测试需求分析活动（1）－产品分析产品分析主要是产品知识前期学分析方法有两种形式：先标记后分析、直接分析防止有交互作用的功能的遗漏，提高功能测试的完备性测试参与开发文档评审的一个原则是，必须先要输出自己的交付件，才能参加开发的文档评审：建议对于测试原始需求也要进行整理、合并、分解，只罗列从用户角度所看到的功能和非功能，其他的细节可以作为这些内容的附件，在测试需求分析中考虑。子系统：子系统是一些逻辑相关的模块集合，可以包括多个模块。LCD需提供背景灯，当有来电和短消息、Email时均能自动点亮说明： 表示该测试类型的主要的测试阶段；《测试分析设计表》之特性测试规格表《测试分析设计表》之特性测试规格表如果原始测试规格A/B合并成一条测试规格X,则其中只有一个是新增，其它都是合并。测试的视角体现了测试的思维活动测试特性划分：由于开发和测试之间的分解分配思路不一样，测试需要从提高测试设计与执行的质量和效率出发建立测试自己的模型，避免测试按照设计规格分解分配思路（模块）来分配测试方案，从功能和测试类型两个角度进行测试特性划分，划分过程中考虑以下几个方面的因素：产品测试规格是对客户需求、产品包需求、设计需求、设计规格以及其它可能的需求进行综合的测试分析，从测试角度分析并整合形成的测试需求集合，明确了测试应该测试什么。测试特性划分：由于开发和测试之间的分解分配思路不一样，测试需要从提高测试设计与执行的质量和效率出发建立测试自己的模型，避免测试按照设计规格分解分配思路（模块）来分配测试方案，从功能和测试类型两个角度进行测试特性划分，划分过程中考虑以下几个方面的因素：测试高级工程师（STE）测试组应该建立并不断完善自己的测试类型库。CALL-BASE-CALLED-001测试类型评估（不同测试类型的比率）对于大家常见的分析思路，可以通过经验库的形式进行传递和统一。负责设计规格－测试规格－测试特性的需求跟踪测试需求分析活动（2）－提取测试原始需求子活动准备（分工组织、提取策略）提取测试原始需求测试原始需求整理确定测试规格分析工程方法测试经验库开发需求协议和规范用户需求继承产品需求测试原始需求测试原始需求测试原始需求直接提取继承性分析直接提取直接提取直接提取分工合作确定工程方法合理规整测试原始需求分析方法有两种形式：先标记后分析、直接分析测试需求分析活动（子活动准备（分工组织、工程方法应用策略）运用工程方法进行分析，得出初始的产品测试规格：测试类型分析、功能交互分析、关联图分析、其他分析方法测试特性建模:从测试角度，划分出测试特性，并对初始的测试规格进行整合，按照测试特性进行归类，得到最终具有完整属性的产品测试规格。修正测试原始需求测试类型分析 功能交互分析关联图分析 其他工程方法初始产品测试规格测试特性建模测试特性测试规格整合产品测试规格修正修正测试原始需求测试类型分析 功能交互分析关联图分析 其他工程方法初始产品测试规格测试特性测试规格整合产品测试规格测试特性建模测试特性建模时机的不同产生两种活动方式测试需求分析活动（3）－产品测试规格分析子活动准备（分工组织、工程方法应用策略）修正测试原始需求测试测试需求分析活动（4）－测试规格分解分配通过测试特性建模形成测试特性产品测试规格分解分配到测试特性以测试特性为单位进行测试方案设计以测试方案设计任务书形式交付测试方案设计阶段测试方案设计任务书测试特性3测试特性2测试特性1产品测试规格测试需求分析活动（4）－测试规格分解分配通过测试特性建模形成测试分析设计评估质量测试用例密度覆盖率ODC评估（不同触发因素的比率）测试类型评估（不同测试类型的比率）测试用例/每千行代码不同设计规格的覆盖率（2/8原则）设计规格的覆盖率测试需求分析活动（5）－测试规格评估测试分析设计评估质量测试用例密度覆盖率ODC评估（不同触发因评估方法评估思路适用范围备注测试类型评估不同测试类型能否发现不同类型的缺陷，依据测试类型来评估测试分析设计工作是非常必要的，我们必须在产品初期就要规划测试类型，以期尽可能的发现所有相关类型的缺陷，而不是发现某几种类型的缺陷针对产品测试规格评估，可以发现测试需求分析中的问题。每种测试类型的比率是否合适，需要建立一个基线设计规格覆盖率所有的设计规格都应该覆盖，但是由于部分设计规格不适合做系统测试或者没有相关测试手段，对于这部分设计规格需要明确提出。针对产品测试规格进行评估，可以给出系统测试可以验证的覆盖率对于不能测试的设计规格，应该提出相应的验证方法（检视、单元测试等等），这是一种风险，另外，这些设计规格也是可测试性需求的一部分不同设计规格的覆盖率每个设计规格的使用频率和发生错误的可能性都不一样，对于风险较大的设计规格，应该依据2/8原则，会设计更多的测试用例。基于这种思路来评估，可以确定我们的设计重点针对产品测试规格评估，明确那些测试规格是重点。这种评估可以测试方案设计的策略测试需求分析活动（6）－测试规格评估评估方法评估思路适用范围备注测试类型评估不同测试类型能否发现客户需求产品包需求设计需求设计规格SRSHLDLLDMSTMITMUT产品测试规格测试特性特性测试规格测试用例TSE负责跟踪PL负责跟踪测试要同时验证客户需求、产品包需求、设计需求测试需求分析活动（7）－测试规格跟踪客户需求产品包需求设计需求设计规格SRSHLDLLDMSTM

通过编号方案可以弄清楚测试分析设计输出之间的关系，建立一个跟踪体系。需求来源：来源编码＋XXX原始需求：特性编码＋XXX初始产品测试规格：工程方法编码-子类编码-XXX产品测试规格：测试特性编码-大类编码-[子类编码]-XXX特性测试规格：测试特性编码-XXX测试用例：特性测试规格编号-XXX测试需求分析活动（8）－测试规格编号方案 通过编号方案可以弄清楚测试分析设计输出之间的关系，建立一为什么有测试规格维护？产品测试规格基线化；测试输入产生变更！开发类来源：变更的客户需求产品包需求产品设计需求设计规格概要设计详细设计代码测试类来源：变更的测试经验库测试方案测试报告等更新的基线化输出－产品测试规格、测试用例；总结的经验输出到测试经验库中，更新的测试经验库的相关内容也是一个输出；在《测试需求分析报告》、《测试方案》中对于测试分析与设计维护活动的过程和内容的记录；测试规格维护输入输出测试需求分析活动（9）－测试规格维护为什么有测试规格维护？产品测试规格基线化；开发类来源：更新目录测试需求分析背景测试需求分析理论测试需求分析工程方法测试需求分析应用目录测试需求分析背景测试需求分析工程方法概图产品分析指导书继承性分析工程方法原始测试需求提取指导书需求来源表原始需求表测试类型分析工程方法功能交互分析工程方法关联图分析工程方法产品测试规格分析指导书产品测试规格表(未划分测试特性)测试特性建模工程方法测试规格整合工程方法产品测试规格表(划分测试特性)测试规格分解分配指导书测试特性方案设计任务书测试特性交互分析工程方法测试需求分析工程方法概图产品分析指导书继承性分析工程方法原始能够支持电子邮件的收发关于测试规格粒度的理解（1）失效影响度：特性使用频度、特性重要性。测试特性和开发特性有区别吗？为什么有测试规格维护？测试类型是从不同的角度来分析和测试产品在参与开发评审前，测试应该完成了自己的输出，带着问题参加评审，效果就会不同，参与评审，也是为了解答自己的问题。低粒度的测试方案为测试人员提供一般的系统行为信息填写可能相互影响点描述确定产品测试需求分析的来源TSE召集讨论确定测试类型及其子类型LCD需提供背景灯，当有来电和短消息、Email时均能自动点亮CALL-BASE-CALLED-002测试类型分析,功能交互分析测试特性建模时机的不同产生两种活动方式没有统一成熟的分析设计工程方法支撑失效影响度：特性使用频度、特性重要性。《测试分析设计表》之特性测试规格表测试方案设计工作任务书测试特性建模时机的不同产生两种活动方式推荐的工程方法

虽然说上面提到的工程方法都是一种参考，大家可以依据实际情况选用，但是从测试视角出发，在测试规格的分析活动中，推荐以下三种工程方法：

继承性分析

测试类型分析功能交互分析能够支持电子邮件的收发推荐的工程方法 虽然说上面提到的工程方一、继承性分析一、继承性分析应用背景目前开发的新版本有一个基础版本，他们之间的关系如何？新版本测试策略又是如何制定的？新增和继承特性什么关系？新增了什么？继承了什么？该测试哪些？

版本B版本A特性1特性2新增特性新增特性新增特性应用背景目前开发的新版本有一个基础版本，他们之间的关系如何分析思路（1）输入：需求来源表历史版本的测试报告历史版本的产品的特性清单及其说明等其它可供参考的资料输出：测试策略建议新增原始需求需要进行功能交互分析的继承特性其它一些过程输出网上使用情况历史测试情况应用变化情况交互成熟度失效影响度测试策略建议新增测试原始需求需要作功能交互分析的继承特性变化独立继承特性现状分析特性交互关系分析版本B版本A新增特性新增特性继承特性继承特性新增特性分析思路（1）输入：输出：网上使用情况交互成熟度测试策略建议分析思路（2）来源编号继承特性失效影响度成熟度继承方式IR001XXX特性交互IR001YYY特性变化IR001ZZZ特性独立IR001MMM特性交互，变化

失效影响度：特性使用频度、特性重要性。

成熟度：经过测试的V/R版本数、网上应用情况反馈（应用性质、应用范围、网上问题数量）。

继承方式：独立、交互、变化或者组合。分析思路（2）来源编号继承特性失效影响度成熟度继承方式IR0过程与结果来源编号继承特性新特性1新特性2..新特性nIR001XXX特性填写可能相互影响点描述IR001YYY特性同上IR001ZZZ特性同上IR001MMM特性同上继承特性与新特性交互分析表来源编号继承特性应用变化1应用变化2..应用变化nIR001XXX特性应用变化情况1应用变化情况2应用变化情况3IR001YYY特性同上IR001ZZZ特性同上来源编号继承特性继承方式影响点说明IR001XXX特性交互IR001YYY特性变化IR001ZZZ特性交互，变化来源编号继承特性测试建议1测试建议2..IR001XXX特性测试建议1测试建议2IR001YYY特性同上IR001ZZZ特性同上继承特性变化分析表需要交互的继承特性继承特性测试建议表继承特性失效影响度分析继承特性成熟度分析交互独立变化过程与结果来源编号继承特性新特性1新特性2..新特性nIR0二、测试类型分析二、测试类型分析应用背景产品应用中出现的问题有各种方面…效率易用性可靠性功能性可维护性可移植性质量模型升级扩容不便？界面太差、操作烦杂？定位问题手段少？……类似如下情况：其实质量是多维的那么如何发现各类问题呢？测试类型分析!不能仅有功能测试功能异常？应用背景产品应用中出现的问题有各种方面…可靠性功能性可移植性分析思路（1）－－基本过程TSE召集讨论确定测试类型及其子类型明确各测试类型分析思路控制分析的粒度分析思路（1）－－基本过程TSE召集讨论确定测试类型及其子类分析思路（2）－－使用阶段测试类型SDVSIT功能测试●一致性测试●安全性测试●性能测试●压力测试配置测试安装测试●恢复测试长时间测试系统指标测试●易用性测试备份测试●大容量测试●流控测试●兼容测试●互操作测试●说明： 表示该测试类型的主要的测试阶段；

●表示对应测试阶段有该测试类型或回归测试针对不同的测试阶段，使用不同的测试类型：分析思路（2）－－使用阶段测试类型SDVSIT功能测试●测试需求分析基本概念（3）－活动框架（2）测试特性的介绍及相应产品测试规格列表针对不同的测试阶段，使用不同的测试类型：更新的基线化输出－产品测试规格、测试用例；测试的视角体现了测试的思维活动填写可能相互影响点描述如果原始测试规格A/B合并成一条测试规格X,则其中只有一个是新增，其它都是合并。RF-HOST-001确定产品测试需求分析的来源测试需求分析基本概念（2）－活动框架（1）如何合理的划分子系统，需要参考系统架构设计。Build（SDV）测试执行策略需要考虑如何回归，并保证功能交互测试的完备性；对测试类型分析、功能交互分析的结果进行补充测试类型分析,功能交互分析分析思路（1）－－交互关系LCD需提供背景灯，当有来电和短消息、Email时均能自动点亮在参与开发评审前，测试应该完成了自己的输出，带着问题参加评审，效果就会不同，参与评审，也是为了解答自己的问题。Build（SDV）测试执行策略需要考虑如何回归，并保证功能交互测试的完备性；新版本测试策略又是如何制定的？测试特性建模的主要目的是划分测试特性，明确每个测试特性的内容和边界。分析思路（3）－－建立测试类型库测试类型分析法是从不同的角度来分析和测试产品，不同类型的测试会发现不同类型的Bug，每类测试类型的测试方法也会不同；通过测试类型的建立，我们可以对整个产品的测试有一个系统的思路，而不是仅仅关注功能测试；测试组应该建立并不断完善自己的测试类型库。多发现25%的测试需求业界公司都建立了完整的测试类型库拓展了测试思路测试需求分析基本概念（3）－活动框架（2）分析思路（3）－－三、功能交互分析三、功能交互分析产品功能不是独立的，功能之间存在交互防止有交互作用的功能的遗漏，提高功能测试的完备性是功能测试方面的分析，与测试类型分析形成互补应用背景产品其他相关功能被测功能功能交互产品功能不是独立的，功能之间存在交互应用背景产品其他相关功能分析思路（1）－－交互关系交互点原始需求与功能特性关系影响与约束时序关系影响（时间、时序）功能之间存在顺序关系功能之间存在交互关系共享关系影响（数据和资源）共享数据影响共享资源影响分析思路（1）－－交互关系交互点原始需求与功能特性关系影响与分析思路（2）－－基本过程横轴是新增特性和继承特性，继承特性来自于继承性分析的结果分析方法有两种形式：先标记后分析、直接分析功能交互分析的结果可以作为测试类型分析的输入，但是操作复杂，不建议这样应用分析思路（2）－－基本过程横轴是新增特性和继承特性，继