测试需求预案.ppt

* 测试特性划分可以从两个角度来考虑：功能和测试类型，在划分测试特性过程中，要考虑以下几个方面的因素： 开发特性或者功能 Build划分 系统架构（模块） 全局因素或者技术风险分析 测试组人员技能 测试组组织结构 * * 测试规格整合的目的是通过工程建模的方法，将测试规格分析的结果整合成规整的测试规格体系，从而指导后续的测试方案设计。 测试规格整合的基础是测试规格分析完成后得到的各种原始测试规格。 测试规格整合的依据是测试建模得到的初始建模。 经过整合的测试规格：完备性，无二义，可扩展，可跟踪 适用范围： 适用于产品测试需求分析阶段，用于整合各种测试需求分析方法得到的分析结果 输入： 原始测试规格 初始测试建模结果 输出： 经过整合的测试规格 整合后的测试规格跟踪表 * 1、测试需求分析和TR的关系： 测试分析设计活动和TR之间的关系的一个基本原则是，测试相应的活动会滞后于开发的相关TR点：产品测试需求分析、测试规格分解分配滞后于TR2，特性测试需求分析、特性测试规格重分配滞后于TR3，特性测试设计和测试用例设计活动应该在TR4之前完成，由于TR3和TR4之间周期较长，开发的相关活动有：概要设计、详细设计、编码/调试、项目单元测试、项目集成测试、项目系统测试，这里建议特性测试设计在概要设计结束前完成，测试用例设计在详细设计结束前完成。相关的自动化脚本编写和调试，以及测试环境准备等等工作建议在项目级调试、系统测试期间完成。 2、测试需求分析和SDV/SIT的关系： IPD中强调了SDV/SIT两个测试阶段，这两个测试阶段的测试内容是不同的，这是测试分析设计所需要区分的。在产品和测试特性层面的分析和设计包含了SDV/SIT的测试分析设计，在测试规格分解分配活动中考虑如何划分测试特性，确定适合SDV/SIT测试的测试特性。 * 测试对象原始资料：包括各个活动需要的输入分析对象，如产品需求包、设计需求，协议规范、测试需求库等。 * 测试规格： 测试规格不仅仅针对设计规格而言 测试规格验证的对象包括：客户需求、产品包需求、设计需求、设计规格以及其他可能的输入 测试规格和设计规格类同，是测试方案的输入 * 测试原始需求明确了产品将要实现了什么 产品测试规格明确了测试应该测试什么（明确的以及不明确的） 特性测试规格明确了测试设计内容（操作步骤统一，参数明确） 测试用例明确了测试实现内容（参数具体化） * 关于测试规格的理解 业界公司的实践提出，不管设计规格是否完善都要建立测试需求，我们称为测试规格； 测试规格是测试对于产品设计规格分析之后的产物； 测试分析设计整体思路都是围绕着测试规格来开展的； 如果产品设计规格是测试的“客户需求”，那么测试规格就是测试的“产品设计规格”； 测试粒度是指一个测试焦点的精细度或粗糙度 测试粒度是一个谱，而不是一系列的“是…/或…”类别 一个高粒度的测试方案允许测试人员检查低级别的细节，一般是系统的内部；低粒度的测试方案为测试人员提供一般的系统行为信息 “纯”结构化（白盒）测试 “纯”行为化（黑盒）测试 “纯”现场测试 开发 测试 技术支援 关于测试规格粒度的理解（1） 测试规格的粒度应该把握灰度原则，建议各测试组在进行需求分析之前，内部经过充分讨论，就粒度问题达成共识； 尽可能的从不同侧面分析（测试类型、功能交互等）测试原始需求，给出初始的测试规格，可能会产生冗余，此时不要过分要求初始测试规格的粒度统一，在测试规格整合时考虑粒度统一问题； 对于一些较为清晰的功能，相似的子功能可以组合在一起描述，作为一个测试规格对待。比如：涉及到一个表格的设置，我们可以将增加、修改、删除等作为一个测试规格，大家一目了然，没有歧异；（CRUD原则） 测试规格应该是完整地描述从用户角度出发所能看到的需求，而不是一个需求的片断，比如：彩铃业务的建立、释放是需求的片断，用户是看不到这一点的，建议这样描述：彩铃业务基本呼叫，考虑各种释放情况 把握灰度 用户可见 关于测试规格粒度的理解（2） 对于大家常见的分析思路，可以通过经验库的形式进行传递和统一。比如：常见的组网模型、常见的用户分类以及各种用户常见的操作等等； 测试规格的描述要清晰，不能有混淆的地方，在测试方案设计阶段，可以直接对测试规格进行细化，而不用参考其他的文档即可。比如：要考虑各种异常情况下的基本呼叫功能，这个测试规格就不是十分清晰，可以进一步给出具体的异常类别形成新的测试规格，比如：要考虑主叫各种异常释放情况下的基本呼叫；要考虑A接口各种异常情况下的基本呼叫等等。 测试规格的粒度，不仅仅和测试需求分析的思路有关，而且和测试原始需求的粒度有关。建议对于测试原始需求也要进行整理、合并、分解，只罗列从用户角度所看到的功能和非功能，其他的细节可以作为这