软件测试需求分析与跟踪

软件需求
软件需求是(1)用户解决问题或达到目标所需条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 (3)一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。
需求层次
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。
业务需求反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。
功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。

软件需求规格说明的特点
完整性
不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息,用TBD ( “待确定” ) 作为标准标识来标明这项缺漏。在开始开发之前,必须解决需求中所有的TBD项。
一致性
一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究,才能知道某一项需求是否确实正确。
可修改性
在必要时或为维护每一需求变更历史记录时 ,应该修订SRS。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在SRS中出现一次。这样更改时易于保持一致性。 另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。
可跟踪性
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。
需求管理
定义需求
需求确认
建立需求状态
需求评审
需求承诺
需求跟踪
需求变更控制
流程图如下：

软件需求过程的标准是：清楚（Clear）、完整（Complete）、一致（Consistent）、可测试（Testable）
不适当的需求过程可能弓|发风险
用户不多导致产品无法被接受。
用户需求的增加带来过度的耗费和降低产品的质量。
模棱两可的需求说明可能导致时间的浪费和返工。
用户增加些不必要的特性和开发人员画蛇添足( gold-plating )。
过分简略的需求说明以致遗漏某些关键需求。
忽略某类用户的需求将导致众多客户的不满。
不完善的需求说明使得项目计划和跟踪无法准确进行。
软件测试需求分析目标
对软件测试要解决的问题进行详细的分析,弄清楚参与软件测试活动的相关人员对软件测试活动和交付物的要求，包括需要输入什么数据,要得到什么结果,最后应输出什么等。
必软件测试需求分析步骤
根据软件开发需求说明书逐条列出软件开发需求，并判断其可测试性。
形成可测试的描述并界定出测试范围。
根据质量标准,逐条制定质量需求,即测试通过标准。
分析测试执行时需要实施的测试类型。
建立测试需求跟踪矩阵,并输入测试需求管理系统，对测试需求实施严格有效的管理。
什么是测试需求跟踪矩阵
需求树的概念
需求树的好处
编写测试需求跟踪矩阵的步骤
阅读理解各类需求。
结合界面原型图理解软件各部分功能。
从叶级别的功能点开始编写矩阵。
保证每个功能点都有正反测试思路覆盖,正反测试配比达到1 : 4(部分功能点没有反向测试)。
只写清测试思路和预期结果,不用具体展开。
写好的测试需求跟踪矩阵必须通过评审才算最终完成。