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

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

作为一种可交付使用的合同，或更一般地说，作为一种劳动产品，要求可跟踪性的任务生成了一个测试验证矩阵(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部分)中安全性相关软件的要求，第五节，“测试和集成”