软件测试自学全套教程—测试生成最终产品规格以及需求跟踪矩阵

　　软件测试自学全套教程，本章节我们主要讲解“测试生成最终产品规格以及需求跟踪矩阵”的内容，测试需求完成后，开始对最终产品规格进行整理，见表6-31。依据确定的测试规格分析工程方法，针对原始需求逐一分析得出初始的产品测试规格。每个工程分析方法得出的产品测试规格应该先进行内部的测试规格整理，过滤掉重复的。

汇总初始的产品测试规格，为下一步测试特性建模和测试规格整理提供素材。通过测试特性建模，明确本次新增的测试特性及其边界。将分析得出的初始的产品测试规格，按照一定的原则和方法进行整合，并按测试特性归类，得出最终本表所述的产品测试规格。　　

　　表6-31 整理产品测试规格

　　对最终需求整理后，就可以梳理出一个最终的产品规格，见表6-32。在这张表中增加了实际使用频率、影响程度和失效可能性三个维度的内容，目的是确定规格的优先级，这样可以更好地确定用例的优先级，通常情况下我们认为需求的优秀级越高，所对应的用例优先级越高，这样可以方便确定测试的计划以及测试的重点。　　

　　表6-32 最终产品测试规格

　　同时可以根据规格估算出大致的用例规模，这可以方便后续对工作进行有效的评估，通常我们在评估工作时都是以用例数来估算工作量。

　　当然在测试分析过程中，如果想到一些规格特别的约束条件或检查点，请务必及时记录，以避免遗忘。

　　需求跟踪矩阵

　　前面详细地介绍了需求分析的过程，这一节我们重点讨论的是需求跟踪矩阵的内容。那么这里有一个很重要的问题，为什么需要有一个需求跟踪矩阵呢?其实需求跟踪矩阵是在CMM3 中提出来的方法，之所以需要对需求进行跟踪，是因为测试是一个验证客户需求是否被正确实现的一个过程，开发是实现需求的过程，那么如何确定开发的内容是否满足用户需求呢?这就必须对需求的每个实现的阶段进行验证，只有每个阶段验证后没有问题，才能保证每个阶段的工作是对的，这样才能确保最后的系统是满足客户需求的。我们不可能脱离过程直接来衡量结果，这样结果将无法控制，但我们以前的工作中并没有一个对需求进行跟踪的一个全景图，所以需求一个记录需求使用期限全过程的表格来跟踪需求，这就是需求跟踪矩阵被提出的原因。

　　需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。

　　需求跟踪矩阵的目的是：

• 　　(1)建立与维护需求、设计、编程、测试之间的一致性，确保所有的工作成果符合用户需求。

• 　　(2)作为各个环节的负责人沟通的桥梁。

• 　　(3)作为一根线条将需求与最终的实现串联在一起。

• 　　(4)作为一种检验的手段，确认需求是否被实现，确认需求是否被覆盖。

• 　　(5)在某种程度上，需求跟踪提供了一个表明与合同或说明一致的方法。

　　需求跟踪的方式通常有以下两种：

• 　　(1)正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后续工作成果中找到对应点。

• 　　(2)逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

　　跟踪能力(联系)链(Traceability Link)使你能跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。跟踪能力是优秀需求规格说明书的一个特征。为了实现可跟踪能力，必须统一地标识出每一个需求，以便能明确地进行查阅。

　　通常需求跟踪能力是四类需求可跟踪能力，如图6-3 所示。

　　图6-3 四类需求跟踪能力

　　需求分为客户需求和需求两类，客户需求是指客户的原始需求，而这里的需求是我们通常所说的开发的原始需求。需求是通过客户需求追溯过来的，这样的好处是可以区分出开发过程中或开发结束后由于客户需求变更带来的对需求的影响，同时也可以确定客户的需求都被实现了，即我们通常说的需求都被满足了。从需求回溯到客户需求可以确认每个软件需求都有一个来源的源头，不致于是无中生有的，如果用使用实例的形式来描述客户需求，图的上半部分就是使用实例和功能性需求之间的跟踪情况。图的下半部分指出，由于开发过程中系统需求转变为软件需求、设计、编写等，所以通过定义单个需求和特定的产品元素之间的(联系)链，可从需求向前追溯。这种联系链让我们知道每个需求对应的产品部件，从而确保产品部件满足每个需求。第四类联系链是从产品部件回溯到需求，使你知道每个部件存在的原因。

　　绝大多数项目不包括与用户需求直接相关的代码，但对于开发者却要知道为什么写这一行代码。如果不能把设计元素、代码段或测试回溯到一个需求，则可能有一个画蛇添足的程序。然而，若这些孤立的元素表明了一个正当的功能，则说明需求规格说明书漏掉了一项需求。

　　图6-4 所示需求跟踪能力图记录了单个需求之间的父层、互连、依赖的关系，在这个过程中，如果某个需求发生了变更，那么这个变更的信息将会延续下去，这样后面的研发工作就必须做出正确的调整。

　　图6-4 需求跟踪能力联系链

　　需求跟踪是个要求手工操作且工作量很大的任务，需要组织提供支持，随着系统开发的进行和维护的执行，要保持关联链信息一致，跟踪能力信息一旦过时，可能再也不会重建它，所以平时需求正确地使用需求跟踪能力。

　　在工作中，需求可能会出现变更，甚至有的公司需求变更得很频繁，每次变更都会影响整个跟踪链的信息，这些信息可能出现增、删、改。维护可靠的跟踪能力信息，使得维护时能正确、完整地实施变更，从而提高生产率。

　　在开发中，认真记录跟踪能力数据，就可以获得计划功能当前实现状态的记录。还未出现的联系链意味着没有相应的产品部件。再设计(重新建造)时，可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。通过定义跟踪能力信息链提供一种方法收集从一个现成系统的反向工程中所学到的方法。重复利用跟踪信息可以帮助我们在新系统中对相同的功能利用旧系统相关资源，如功能设计、相关需求、代码、测试等。减小风险使部件互连关系文档化，可减少由于一名关键成员离开而给项目带来的风险。测试测试模块、需求、代码段之间的联系链，可以在测试出错时指出最可能有问题的代码段。

　　CMMI要求具备需求跟踪能力。软件产品工程活动的关键过程域关于它的陈述，“在软件工作产品之间，维护一致性。工作产品包括软件计划、过程描述、分配需求、软件需求、软件设计、代码、测试计划、以及测试过程。”

　　在表示需求和其他系统元素之间的联系链时，通常使用的方式是需求跟踪能力矩阵，需求跟踪矩阵见表6-33。

　　表6-33 需求跟踪矩阵

　　上表说明了每个功能性需求向后连接一个特定的使用实例，向前连接一个或多个设计和测试元素。通过需求跟踪矩阵可以清楚地看到每个需求被验证的情况，因为测试是验证需求是否被正确实现的，所以我们这里并没有列举同需求被实现的情况，我们是站在测试的角度，并没有对需求实现的过程进行跟踪。这个表记录了测试过程中我们对每个需求进行验证的情况，这样可以确定测试的完整性，当然如果需求发生变更，我们对相应的测试项也需要进行修改。

　　本章节我们主要学习了关于“软件测试—生成最终产品规格以及需求跟踪矩阵”的内容，大家觉得文章有用的话记得每天来这里和小编一起学习涨薪技能哦。