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

2011-2-23 来源：网络

集成汽车电子硬件和软件测试的需求，可以是开发更为流畅，成本更为低廉。对要求可跟踪性和验证的需要像一个契约要求给汽车电子供应商施加着影响。随着频率的提高，厂商逐渐意识到以要求为基础的测试通常是软件开发工程成功的重要要素。
作为一种可交付使用的合同，或更一般地说，作为一种劳动产品，要求可跟踪性的任务生成了一个测试验证矩阵(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部分)中安全性相关软件的要求，第五节，“测试和集成”

这些标准的共同之处是运行以要求为基础的测试。在这些标准之中最显著的是航弹系统标准，DO-178B。这个标准主要定义了两个基于测试的要求活动作为功能测试或黑盒测试(下图)，以及结构覆盖或白盒测试。

功能测试需要开发工程师或测试工程师掌握确定被测代码行为的软件要求。更确切的说，开发工程师(或测试工程师)必须根据输出和预期的结果来定义输入和条件，以便制定出测试规范。该测试规范可能会以一或多个测试用例的形式给出，以便完全遍历测试规范的要求。

结构覆盖或白盒测试有助于验证黑盒测试的完整性。结构测试也有助于确定实际建造设计的正确性；例如，如果所必的软件功能已经全部运行过，但仍然有未覆盖的代码，那么，这段多余的代码的作用就是问题所在，代码运行时间的可预测性也一样。

基于需求的测试及其固有的需求可跟踪性和验证过程被普遍认为推广企业标准的最佳实践，如能力成熟度模型集成(CMMI)。CMMI是一个能够为组织提供有效过程关键元素的过程改进方法。它能够用于引导一个项目、部门或整个组织的过程改进。CMMI能同时使关键性及非关键性软件均获益。

如下方工程过程区域图所示，需求管理(REQM)和需求开发(RD)是CMMI的两个主要的过程域

表中的技术解决方案(TS)是将需求细化为原型或组件。验证过程域(VER)确保所选择的工作产品满足规定的需求。验证过程域(VAL)则根据客户的需求加强对产品的验证。验证过程可以在工作环境或模拟工作环境中进行。

最后，从编程标准的角度看，对于所有的开发活动来说，过程如极限编程(Extreme Programming)及基于需求的开发和测试是不可或缺的。如下图所示，采用极限编程，用户的“故事”在代码开发之前，通过与客户一起合作就可以准备好，并且用作测试场景的软件前缀。

TBreq介绍

TBreq由LDRA Testbed(包括代码评审、质量评审、设计评审组件及代码覆盖)和TBrun(单元测试组件)构成，通过与LDRA工具包集成，能够提供一套独特的解决方案来克服困难，从而在测试规格、单元测试场景、测试数据及代码覆盖率验证与高层次的设计需求之间建立映射关系。

TBreq直接与需求管理工具(DOORS、ReqPro、Word或Excel)接口来保证整个软件生命周期中实现需求可跟踪性，同时保证需求覆盖的完整性(见下图)。

在LDRA工具包里，TBreq根据需求直接生成测试规范和可执行的测试用例。测试结果自动返回到需求管理工具中，提供“双向”需求可跟踪性验证。

TBreq的作用描述如下：需求可通过需求管理工具，如DOORS、ReqPro、文挡或电子数据表获取。TBreq作为这些需求源与LDRA Testbed测试管理仪表盘之间的网关，并且直接与LDRA Testbed项目及其基层项目目录接口。

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

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

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

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

文件规范

源代码或框架文件名

需求术语

需求名称及数字

需求源文档

需求主体

需求正文

测试配置