ThreadingTest针对车载软件测试ISO26262标准的解决方案

CallmeJack

随着汽车行业的迅速发展，汽车电子电器E/E系统在汽车中的作用不断提高，ECU开发所占用的时间和成本也越来越高。与此同时，越来越多的电子控制系统（例如车身稳定控制系统ESP，防抱死制动系统ABS，自适应前照明系统AFS等）具有与安全相关的功能，因此对ECU的安全要求也越来越高。为了减少产品的开发时间和成本，降低由于安全问题而导致的维护甚至召回的风险，越来越多的整车厂和供应商开始重视汽车领域的功能安全问题 ，ECU软件功能安全的问题也成为汽车行业迫切需要解决的问题，车辆功能安全标准ISO 26262就在这样的环境和需求下应运而生，并于2011年11月正式发布第一版本，该标准是当前汽车业中最流行、最复杂、也是最重要的一份标准。

    ISO 26262的目标是通过避免汽车E/E 系统故障行为可能导致的危害来提高E/E系统的功能安全。ISO 26262采用车辆安全完整性等级（ASIL）来判断系统的功能安全程度，ASIL由ASIL A（最低）、ASIL B、ASIL C及ASIL D（最高）四个等级组成，ASIL等级越高表示系统的功能安全评估越严格,相应的表示系统正确执行安全功能，或者说的避免该功能出错的概率越高，即系统的安全可靠性越高。



什么是ISO 26262

国际标准化组织文件第26262号(ISO 26262)为机动车辆开发和测试紧急安全电子系统提供了一个过程框架和程序模型。它是国际电子委员会文件61508(IEC 61508)的派生，其目的是为了适应汽车行业中遇到的挑战。初稿在2009年7月公开刊登，并在2011年发行最终版。标准已经被OEM厂商部分地采用。

基于V模式的ISO26262软件测试生命周期

    如图所示，基于V模式的ISO 26262-6软件测试生命周期可以划分为五个阶段：

静态分析需求和功能需求：在软件级产品开发初始化阶段和软件安全需求规范制定阶段确定了一些基本的嵌入式软件静态分析需求和功能需求，这部分内容是以后设计和测试的基础；

架构验证：在软件架构设计阶段，我们可以使用人工分析的方式来验证和测试软件架构层的内容，但是有条件的话最好使用合适的架构设计工具，在设计的过程中同时进行架构验证；

静态测试：在软件单元设计和实现阶段同时进行静态测试，可以使用开发辅助工具来进行静态测试，这样不必因为静态测试的活动而改变开发流程。

动态测试：在软件单元测试阶段以及软件集成和测试阶段，使用合适的动态测试工具进行动态单元和集成测试，                                                                                                                                                                                                                                                                                                                                                                             

功能验证：在软件安全需求验证阶段，要根据ISO 26262-6的要求进行功能验证，包括进行ECU网络环境测试和实车测试，必要的时候进行HIL测试。

      因为在静态分析需求中所需要满足的方法基本上都是属于静态测试的范畴的，因此我们以ASIL A为例，将软件测试内容分为静态测试、动态测试和功能验证三部分（注：架构验证暂时未包含在内），见下表。


ThreadingTest测试工具介绍

ThreadingTest（简称“TT”）是创新型的系统级白盒测试工具和数字化软件测试装置，它的设计基于融合了4项国家发明专利而打造成的软件测试行业的革新性测试理念-“穿线测试”。TT首次将黑盒测试与白盒测试过程以及方法进行完美的融合，采用ISO26262标准的打桩方式（保证打桩的代码和正常的代码的执行功能是一致的），以黑盒的测试过程及方法，产生白盒测试的数据，真正将软件测试带入数字化测试时代。除了支持传统的JavaEE应用，同时TT也是全球首款商用级别的移动端白盒测试工具，可以对各种类型的移动类应用进行测试。

TT的所有特性基于对代码、测试等的深度量化分析和智能计算，TT除了可以进行白盒测试外，也可以为软件的安全性测试提供全过程、系统性的方法支持，TT可以在安全性测试黑盒方法的过程中，从辅助分析，自动诊断，快速定位等多个层面提供软件安全性测试解决方案。TT提供的功能远超越了传统安全性白盒测试的功能范畴，配合流行Fuzzing安全性测试方法，可以将安全性测试的效率、质量进行大幅度的提升。

TT数字化数据测试方法，完美结合ISO 26262功能安全标准的测试系统方式，支持在单元、集成、系统等多个环节分开进行或实现测试从需求到上线整个测试数字一体化管理。

TT对标准的静态测试解决方案

静态测试内容里面要求采取多种的测试方法，例如‘低复杂度的强制要求’一般需要通过满足一定的度量指标来实现，度量指标包括圈复杂度、嵌套深度等等，而‘使用语言的子集’在汽车行业一般选择MISRA-C，通过强制使用编码规范来排除未定义行为或者实现定义行为等危险用法，除此之外静态测试还要求一些其它的测试方法，例如如果要满足更高的安全完整性等级的话，静态测试内容还需要包括运行时错误检测等，一般需要使用可靠性测试性的测试。

    在静态测试中，静态分析主要包括规则检测和质量度量；可靠性测试主要进行运行时错误的检测。

    上面提到ASIL A中针对编码准则的需求以及其他ASIL等级所强烈推荐的例如使用风格指南等需求都是不需要运行源程序来检测，因此都属于静态分析的范畴，虽然这些需求也可以通过人工检查的方式实现，但一个好的静态分析工具几乎可以自动化地执行满足这些相关需求。

TT针对静态分析的需求，提供了可以自动化地执行码的静态分析；提供项目、文件和函数质量度量；提供方便快捷的代码结构生成控制流程图以及调用关系，高亮显示代码结构并生成报告文档等。

TT可视化的代码结构分析

函数调用图：

TT展示一系列关于软件系统的整体信息。如：类或者函数以及类的成员函数的总数目，调用关系或者类的继承关系的深度、层次结构、语句总行数和总体复杂度，整体的测试覆盖率（分累积的结果和最后一次运行的结果，可选择语句、分支和MC/DC测试覆盖率标准）、整体的性能分析结果以及各模块所占的用时比例、以及全局变量和静态变量的分析结果等；同时，又给出了各个模块具体的信息，包括：各模块的源码行数和复杂度、测试覆盖率分析结果、扇入扇出信息，高亮显示一个模块及其所有相关的模块，或者以任何一个模块为根生成局部子树等。

函数调用图的特性：

TT函数调用图采用了超高速图形绘制技术，不光支持图形的大小缩放和平滑移动，并可按照自己的需求，进行自动绘制类分组聚集布图以及函数调用关系布图，更能实现子树逐级展开和下钻，达到完美结构清晰绘制。

TT会在函数调用图上会展示当前的覆盖率信息， 以及覆盖率与函数相关信息，并通过选择图中任意一个模块而追溯所有调用它的路径和相关模块以及被他调用的模块，达到修改模块不一致性缺陷的预防等。

TT为了使得团队的各个组群或者个人可以方便的得到相关的局部信息，在函数调用图中设计了任何一个模块为根生成局部子图，并且生成子图的相关信息，为了发挥更好的可视化效果，TT还设计了各模块与逻辑框图的链接：完成宏观（函数调用图）与微观视图（控制流程图）的结合。

函数调用聚集图：

以类对函数进行分组，通过图表把同一类的函数聚集在一起进行展示。

类继承图：

显示的是当前项目所有类的集成和派生关系。

控制流程图

通过函数的if-else，while，for，do-while，switch-case等控制语句结构绘制组成的流程关系的展示图；配合下方的源代码展示界面，显示能清晰查看函数内部运行逻辑和结构、条件的真假运行状况、MC/DC的满足率等。

特性：

TT可视化的控制流程图，对主要的控制逻辑语句对应有清晰的图元显示，并支持嵌套显示以及串联显示。当点击控制流图的每个图元可以清晰看到对应的代码段以及代码段的执行次数、覆盖率情况。当条件语句成为选中热点后，可以清楚的展示条件语句的各个子条件的各种组合执行的真假情况。

TT控制流程图为了达到更加的展示效果，支持了缩略图的显示，可平滑的进行缩放以及全屏显示，并实现函数调用图相互自动链接、追溯、转换等功能。

函数列表：

针对整个程序的所有函数，按照各种覆盖率、复杂度进行排序，帮助用户能快速的定位查看所有的函数信息，并通过和函数调用图、控制流程图、覆盖率可视化图以及累计覆盖率图的快速切换，使得用户在查看和解决实际问题上提供了方便。

使用ThreadingTest进行代码复杂度分析和安全检查

复杂软件不稳定，也经不起不可预测的行为。所以，我们努力使软件的复杂度变小。如果有条件采用某种自动化工具，可以通过工具对软件设计或/和代码进行控制，用图形化的方法反映出软件结构中的控制流和数据流，通过连结数/调用数、节点数、嵌套深度等这样一些结构关系的检查，获得复杂度的度量，将会获得很好的效果。

TT在对代码的分析过程中，TT可以直接给出代码复杂度的计算结果，通常复杂度越高的软件模块更容易引入缺陷，也更加容易引入安全性问题，高度复杂的数据结构难以彻底测试，可以采用TT等复杂性评估技术来标示出需要进一步改进的区域，以便提升软件的安全性。

TT对标准的动态测试解决方案

以前的动态测试大部分是通过人工的方式实现，但是由于动态测试巨大的工作量，以及测试用例难以重用，测试覆盖率无法计算的困难，因此在测试解决方案中还是需要选择合适的动态测试工具来执行软件单元测试。又因为ISO 26262对需求和测试有可追溯性的要求，所以最好测试工具可以和相关需求管理工具集成，例如能够从需求管理工具中将需求导入，再将测试用例和需求链接起来，并且实现数据的双向同步。

TT针对静态分析的需求，采用了双向追溯专利技术+API接口开放结合各类项目管理工具，把测试的覆盖率、代码、测试用例、测试需求、BUG进行有效的链接。

TT双向追溯专利技术--测试用例（功能）与源代码关系的自动生成

通过ThreadingTest运行测试用例，采用TT百万图元级别的超高速图形绘制技术展示图，对各种大、中、小型软件进行功能逻辑实现分析，实现测试用例与被测源码间相互追溯。该追溯技术方便了用户查看和设计测试用例，通过基于双向追溯的实测用例分析，测试人员可以快速追踪修改代码的波及范围，针对已修改的模块和波及到的模块有针对性的补充测试用例，把回归测试的成本降至最低。

正向追溯技术：

通过点击某个测试用例，追溯到该用例所对应的函数控制图，并展示其测试的逻辑和结构，点击其中某个函数，可以进行该函数的覆盖率、复杂度、代码、控制流程图等信息查看，帮助测试人员通过简单查看发现测试遗漏，并且有利于开发人员直接定位测试发现的缺陷，测试和开发之间的高效互动。想象下，当一个核心工程师离职时，他所带走的是对整个程序的理解及开发思路，交接的工程师需要花费大量的时间去理解，TT通过正向追溯，可以使交接的工程师能通过测试用例所展现的程序逻辑和结构等信息，快速的掌握和理解程序的开发思路。