?

	Eduardo Lluna拥有巴伦西亚大学的物理学位和巴伦西亚大学理工学院电子工程系的博士学位。他一向对于软件测试，电子测量设备和感测网路方面的研究都很积极。Lluna有20多年的关于交通控制，公众视野，支付，电信系统领域的即时嵌入系统的软件的专业经验。他曾在SICE， Telvent还有 Design of Systems on Silicon (DS2)公司任过职。他是巴伦西亚大学计算机科学部的副教授，且自2011年1月起，就已在ITI公司的软件质量部担任协助不同研发项目的项目经理。更多详细资料，见：www.linkedin.com/in/elluna。
	Maximiliano Mannise拥有乌拉圭天主教大学的计算机工程学位。他是西班牙巴伦西亚ITI公司软件质量部的负责人。Maximiliano在乌拉圭蒙得维的亚大学担任过教授，还参与过西班牙政府或业内所创建的关于软件质量和软件测试的调研项目。 自2007年起，他一直在ITI公司从事与软件质量测试，研究及传播活动（如：VLCTESTING）相关的项目。之前，他还在乌拉圭IBM工作过9年多，包括2年多的测试项目经理。Maximiliano对实际测试过程提升及用于测试项目的项目管理很感兴趣。更多详细资料，见：www.linkedin.com/in/mmannise。

?

?

　　代码验证包括检查一些规则，并且随着项目安全水平的提升，需要检查的规则的数量也要增加。可以用不同的工具检查，验证团队独立于开发团队之外的情况在安全关键系统中并不常见。集中式系统需要处理所有的缺陷信息并轻松生成报告。本文展示了一个开发用以管理大型项目的验证结果的数据管理系统。解决方案基于一个商务智能引擎。

　　1.引言
　　 代码验证过程包括检查特定规则被遵守且特定代码如指定的执行。可以手工检查，但这是一件很累，易错的事，所以使用自动化工具才是最佳选择。要接受检查的规则数量是可变的且依赖项目安全水平。随着项目变大且安全水平增加，需要检查的规则的数量及要执行的代码变得很高，使用自动化验证工具势在必行。
　　 验证任务由一个团队或一个不同于通常负责开发安全关键系统的公司执行时，所有检查结果都必须被管理以生成缺陷报告并计算可以被及时交付给开发团队的项目进展指标。一般情况下，不同的工具要进行所有的检查（通常是静态和动态分析），因此信息将来自于不同源头并且是不同的形式。管理来源不同的大量信息产生了问题，工具要汇总所有缺陷信息并管理它们以计算指标并以集中方式生成报告。 
　　 本文展现了按严格安全要求创建以管理大型项目验证任务的数据管理系统。解决方案是基于一个商务智能引擎的。 
　　 本文结构如下。第二部分简要概述了验证任务。第三部分介绍了推荐的验证流程，描述了不同活动和产品。第四部分讲了内部执行和商务智能引擎。第五部分展示了一些使用工具的真实案例结果。最后，第六部分做了一些总结。

　　2.验证任务
　　 验证包括检查任务中创造的产品满足要求且正确。有各种验证技术，项目定义中的一项重要任务是为制定项目选择正确的验证技术。安全关键的开发是按标准管理的，比如：IEC 61508-3， EN-50128， DO-178B，且根据项目的安全水平，它们提供一系列可以考虑的技术。一般情况下，可以认为，所有标准中都需要有两个基本类型的代码分析验证技术：静态和动态分析。静态分析包括检查源代码而不运行，并寻找被认为是危险的或易错的结构。检查有很多规则，包括代码标准，但是一系列非常重要的规则是来自使用一个不安全语言的情况中的语言子集定义。大多数安全关键系统是用C或C++编码的，且两种语言都被认为是不安全的，所以使用它们的方法是只使用一种被认为安全的语言子集。对于C和C++，有两种被广泛使用的子集：MISRA C/C++和JSF。两种子集都制定一系列必须遵守且必须检查的规则。动态分析包含执行部分代码以检查它如预期进行。过程包括定义一系列通过它的界面和（结果与规范中一致的）检查去执行的代码测试用例。一般来说，验证任务可以自动或手工执行。优先选自动化方法，但不可能总这样。静态分析可以是自动的，且有商用工具。动态分析不容易自动化，一般而言，它要求手工定义测试用例。另一个限制自动化使用的问题是：在安全关键系统中，工具必须被认证可以安全使用，因此可用工具的数量被减少了。另一个出现在一个真实项目中的问题是，通常，没有一个单独的工具可以检查项目要求的所有的规则。认证工具很贵，有时不会选择去买一些工具。还有一些项目或公司依赖的规则，比如检查主文件格式，对这些任务进行脚本特别检查。一般情况下，验证任务必须包括开发这些特殊脚本的计划。即使是挑选了工具，开发了脚本去执行特殊检查后，一些规则因为它们的复杂性而无法自动化，所以验证过程必须包括一些将被验证和验证工程师执行的手动检查。无论如何，手动检查的结果必须被输入管理系统。验证过程中的另一个重要因素是度量计算。一些度量是由工具计算的且如果值超出范围时它们可被当做一个缺陷（圈复杂，嵌套级别，函数长度等）。但也有其他度量是关于追踪基于随版本而变化的参数的过程演变的，所以有必要保存所有的信息并可随时用于计算这些度量。这些度量的一个实例是Stability Index，它提供了一个版本间变化的指示，每个版本的既定类型的缺陷数量，等。

　　3.建议流程
　　 验证流程必须考虑一些可以自动执行的任务及及其他手动执行的任务，但是所有情况下，都要把信息存到信息系统中。基本工作流程如图1所示。流程开始输入源代码，最后输出关于代码质量的报告，基本是一大堆没达到的规则。获取数据的流程包括使用各种工具执行所有要求进行的检查。数据输入模块是数据存储的进入点它获取不同来源不同形式的信息并存入数据库。数据来源有三个基本类型：商业分析工具，特别编写的脚本，和手工检查。手工检查中，有一个搜集数据并创建一个（给数据输入模块使用的文件的）特别脚本。数据输入功能使用一个固定格式的XML文件。开发的脚本以正确的文件格式创建输出，但是用转化层将商业工具的输出转化为正确的格式。存储和处理系统也能充分利用接收到的所有数据并生成报告。

图1.流程概貌

　　数据库不允许删除缺陷，但是当就算没有满足规定也有正当理由可以违背时，有一个机制接受缺陷。接受机制要求一个人的识别要负责接受并包含接受的具体理由。可被接受的缺陷可以被总结并列在报告中。图2展示了具体流程。如之前所见，静态分析包括自动化和手动任务。自动化任务直接提供一个如输出所示的XML文件，但是手动分析的结果也必须被处理以生成一个XML文件。动态分析并不是完全自动化的。测试用例必须手动定义，但其执行是自动的，结果被存入XML文件中。也要给数据库提供关于度量和检查规则的信息。

图2. 流程详图

　　4.解决方案的内部结构
　　 存储和处理系统构成缺陷管理的BI核心并为缺陷版本，列表及报告生成提供基本功能。数据库逻辑上是由三个不同类别的元素构成：缺陷，规则和度量。基本元素是缺陷，它包括明确识别缺陷所需的所有信息。作为检查流程的结果，缺陷记录是为每个规则或失败的动态测试而创建的。每个缺陷结构中包含的基本数据如图3所示，且由本地数据（项目，模块，文件，线路，等），尤其是关于缺陷，已发现缺陷的工具还有临界等的信息。系统必须熟悉规则列表。数据库规则元素包括识别规则所需的所有信息。规则结构包含关于项目中检查的每个规则的信息。创建包含除所发现的缺陷外的所有被执行的测试时，就需要该信息。图4展示了为规则存储的，包含了规则的基本定义及规则是否是主动的基本数据。度量结构包含关于每个计算度量的信息。创建报告也需要该信息。图5 展示了为一个度量存储的基本数据，还包含了关于识别度量的信息，尤其是有效期的临界值及位置，以防数值超出范围。

图3. 缺陷数据结构

图4. 规则数据结构

图5. 度量数据结构