测试需求的意义

　　无论对于开发还是测试，一个全面有预见性的设计是保证项目顺利进行的前提。实际项目操作中，常常感受到测试过程有着各种问题：

　　1、产品质量维度关注的不全面，测试类型不完整；

　　2、测试规格设计较为随意，测试分解分配比较随意；

　　导致测试过程中，经常会出现需求遗漏、测试设计遗漏的问题；

　　因此一份详细的测试需求分析有利于这些问题的解决。

　　测试需求的定义

　　软件需求定义的是要产品要实现的功能是什么，而测试需求这个名词业界并没有权威的定义，多数的意见认为测试需求定义测试的范围（即主要解决测什么、及测到什么程度的问题），这样说还是太过泛泛，换个说法，测试人员依据初期功能需求，评估需要测试的功能点都有什么，每个功能点需要什么类型的测试，每个功能点测试到什么程度算是通过，这样初步评估出了测试的规模、复杂程度和风险，同时可以初步预估出哪个环节需要研发同事提供测试接口。

　　测试需求设计的愈加详细，代表对待测试的软件了解的愈深，对各种测试手段了解的愈深，但是这往往要求测试需求的设计者拥有一定的测试经验。

　　测试需求的流程

　　测试需求的采集

　　测试需求直接的来源是：

　　1、软件需求规格；

　　2、业界协议规范；

　　3、测试经验库；

　　4、对于已有旧版本的软件测试，还需要考虑继承性的测试需求。

　　对以上内容进行梳理，形成原始测试需求表，列表的内容包括需求标识、原始测试需求描述、信息来源，如下：

　　测试人员需要对开发需求进行整理，首先需要确认软件需求的正确性、其次保证软件需求的可测试性。所谓的可测试指的是“存在一个可明确预知的结果，可用某种方法对这个明确的结果进行判断、验证。”原则上，所有的软件需求都应该是可测试的，因为如果作为测试人员对需求无法产生准确的理解（即无法得出明确的结果），那么开发人员也同样无法对同一条需求产生准确的理解。每一个测试需求需要保证一条需求只包含一项测试内容，因此一条软件需求通常可能对应多条测试需求。

　　这个阶段的测试需求整理，重要的一点是要注意广泛性和全面性，要尽可能的收集更多的原始需求，不存在遗漏，并且可以对需求进行适当的扩充，这些需求应该不仅仅局限于上述的五种来源类型，也不仅仅局限于各种文档、资料。