高效的测试确保可跟踪性和验证要求

集成汽车电子硬件和软件测试的需求，可以是开发更为流畅，成本更为低廉。对要求可跟踪性和验证的需要像一个契约要求给汽车电子供应商施加着影响。随着频率的提高，厂商逐渐意识到以要求为基础的测试通常是软件开发工程成功的重要要素。

作为一种可交付使用的合同，或更一般地说，作为一种劳动产品，要求可跟踪性的任务生成了一个测试验证矩阵(TVM)，TVM是一个很难制成的产品，这个过程消耗着从其他生产率更高的活动中转移过来的有价值的资源。

在人们试图通过项目的测试、集成和展开阶段去维护TVM之时，TVM的真实重要性才会显现出来。当缺陷出现时，TVM的固有不足和它代表的人工处理就会以缺陷的形式暴露出来。确切的说，大部份这类缺点都归因于对要求管理，包括要求确认、分配和正确的实现。事实上，记录显示高达70% 的此类缺陷被归类为与要求管理相关!

下个挑战是生成一个专门面向开发和测试团队的、工作在现有工具和程序环境中的要求可跟踪性方案。目前，大多数的客户LDRA拥有要求数据库或扁平的文档处理能力，在此，他们定义并且维护系统或高级别的需求。

延迟映射

一些客户把这些高级别的要求映射到顶层的设计；甚至较少把这些要求映射为实际建造设计和源代码。大体上，客户至少要把要求映射到验证这些要求的测试用例。然而，当用户等待测试以执行要求可跟踪性之前，错误映射出现的可能性非常大，尤其在系统测试中。

出现这么晚的要求映射的原因在于，项目经理的办公室和开发工程师工作站的测试环境或在实验室目标系统上的要求数据库对操作约束施加了影响。或者在远端，转包商正在执行测试。在最小程度上，这些操作约束规定，要在要求数据库和该测试环境之间进行某种级别的集成，以引入一种自动的解决方案。。

一种更有效的方法是至少把要求映射到(或详细的)实际建造设计和嵌入式源代码。映射已构建的系统是测试资格或测试预备过程的组成部分，测试预备程序决定要求和代码之间的合适关系；这种检查得到的一个推论就是，要消除源代码中的废弃代码(用不上的代码)。此外，可能引起争议的是，行不通的代码或在任何测试数据组合之下不能运行的代码，也应该在测试准备就绪之前校正或清除。

要求可跟踪性的最佳解决方法包括：第一步，把系统要求映射为最高层设计，在使用一个设计建模工具时适当地执行(该选项在 LDRA 白皮书“LDRA Tool Suite/ Telelogic I-logix Rhapsody Integration ”)。

原型设计

现有的低级和引伸要求迫使对实际建造设计做进一步的要求可跟踪性，开发团队要在详细制定系统要求(或原型设计)的过程中定义这些要求，并定义可工作和可测试的系统构造。该产品进化的模式在嵌入式软件任务的开发过程中最为显著，其中，也必须考虑目标约束和硬件需求。

低级要求的流行和上下文环境对要求可跟踪性来说是另外一个重大挑战。这些要求不考虑系统或客户需求；它们解决软件系统“如何”工作的问题，而客户需求定义的是系统应该“做什么”的问题。结果，低级和引伸要求常常与系统要求脱节。这就提出了另一个数据管理需求。

低级要求管理、跟踪和验证的一个关键方面，就是怎样把这些要求划分给开发工程师和测试工程师。开发工程师要完全掌握他们将实现的代码的接口规范以及该代码将要调用的程序。这些规范必须明确连接到相关的高级要求，以便开发工程师正确地理解实现的上下文环境。获得了合适的信息，开发工程师就可以针对可测性开展设计，并考虑必须在多个测试级使用的功能。

关键软件在汽车工业以及全球其他的商业和政府部门方面都有许多应用，例如安全关键、任务关键和商业关键的应用。下面列举了一组常用的此类应用程序。

如果人们考虑“消费者关键”的应用，那么，这些软件的应用领域更宽，包括ATM和游戏机(特别是花自己钱的时候)。大多数这些应用都是为工业和政府组织开发的，他们定义和出版自己的软件开发和测试标准。下列为此类标准的代表：

MISRA: 车载软件开发指南，3.6， “测试”

IEEE 1012: 软件验证和确认标准

IEEE 829: 软件测试文档编制标准

IEC 61508: 电气/电子/可编程安全性相关系统的功能安全性

FDA: 软件验证的通用原则， 5.2.5， “由软件开发工程师进行的测试”

EN 50128: 铁路应用， “铁路控制和保护系统的软件”

RTCA DO-178B: 航弹系统和设备认证要求中的软件考虑， 6.x， “软件验证过程”

Def Stan 00-55:国防设备(第2部分)中安全性相关软件的要求，第五节，“测试和集成” [p] [p]

需求可从任一来源捕获，它们可被(通过用于Testbed的可跟踪性及验证)测试管理工具使用。可跟踪性及需求映射直接在Testbed中执行，并且信息是通过设计评审、源码文件及TBrun获取的。验证结果和可跟踪性信息可上载至软件库。

TBreq软件有两种类型的基本工作过程。第一种通过低层次需求和实际建造设计评审来包含需求可跟踪性和测试验证。测试管理工具支持需求与源代码过程或方法之间的映射。这些映射需求相继地为开发人员或测试人员所获取，其目的在于生成测试规范和测试验证。测试管理工具同样也将促进这些测试规范中的测试用例的自动生成。接下来的发布将支持测试值从数据表或规范中自动输入。这一类型的工作流程的结果然后将反向映射回需求源中。

这一封包同样可用于没有TBrun的测试验证中。在这一工作流程场景中，LDRA Testbed用来作为工具源代码，这一代码是通过客户提供的测试用具执行的。

TBreq还使用一种被称为需求描述符线程(或线程)的机制来帮助实现快捷可跟踪性和验证能力。这一线程的特征为：

文件规范

源代码或框架文件名

需求术语

需求名称及数字

需求源文档

需求主体

需求正文

测试配置

相关的测试用例/序列

覆盖层次

测试用例/序列验证状态

测试规范

过程或类接口

测试数据

测试管理

项目经理姓名

开发人员/测试人员姓名

线程类型(RV或DV)

线程是为所有高层次(系统)及所有低层次(设计)需求创造的。前一线程类型被称为需求验证(RV)线程，后一线程类型被称为设计验证(DV)线程。线程包含需求名称和数字及需求主体(正文)。线程同样也包含源代码文件规范及相关过程原型(测试规范)在内的映射信息，相关的测试用例映射是由测试配置及所需的覆盖层次所提供的(如：语句 100%；分支 80%)

本文小结

软件TBreq为需求可跟踪性和验证提供了一个全面、完整的解决方案。此外，TBreq与LDRA工具包集成的封包完全符合前面所讨论的关键性软件标准的要求。并且，TBreq为CMMI 2级过程域(需求管理)和CMMI 3级过程域(需求开发)提供了受该标准要求的过程基础架构。