敲黑板！今日《基于iso26262的单元集成测试过程》在线研讨会核心内容梳理-凯发官方首页

        tessy是一款动态测试工具，主要应用于v模式中单元测试及集成测试阶段。它可以自动生成驱动函数及桩代码，用户无需手动搭建测试环境，只需要编写测试用例，即可进行单元测试、集成测试。通过工具将代码实际运行结果和测试用例中设定的预期结果进行自动比对，检查代码功能正确性。在进行功能测试的同时，工具还对代码测试的覆盖度进行了统计。通过统计得出的覆盖度值，能够直观的了解到测试的充分性。

        该工具能够覆盖iso 26262功能安全规范对单元/集成测试环节的要求，确保使用工具进行测试的被测软件能够达到功能安全不同等级的要求。我们将针对tessy在不同测试阶段的应用与iso 26262要求进行映射，以说明该工具的规范符合性。 

1. 软件单元测试阶段要求

        本章节将说明iso 26262-6中对单元测试阶段的要求，并论证tessy工具如何匹配这些测试要求。iso 26262功能安全规范中将汽车安全综合等级（asil）划分为a，b，c，d四个等级。d为高安全等级，a为低安全等级，不同安全等级对测试要求程度有明显区别。

       ♦  1.1.1 基于需求的测试

        iso 26262中要求在单元级别的测试是基于需求（软件单元级别的设计需求）的测试，所有的测试用例都是基于需求来设计的。针对这条要求，tessy可以从两个方面进行响应。

 

        （1）tessy支持通过ctm(classification tree method)分类树方法，从需求分析开始介入，使用cte(classification tree editor)分类树方法编辑器依照需求来设计测试用例。这种用例设计方法更加系统，所设计的测试用例具有高覆盖低冗余特性，可以保证测试依照需求进行。

 

        （2）tessy具备需求验证管理功能，可以将需求与测试用例进行链接，每一条需求至少需要链接到一条测试用例，以此来检查需求是否完全被覆盖，并通过测试用例执行通过与否，来验证对应的需求是否被满足。

 

（a）需求与用例链接关系

 

（b）需求覆盖度测量

图2 需求验证管理功能

 

       ♦  1.1.2 接口测试

        接口测试是针对被测对象的接口进行验证，一般采用黑盒测试方法进行单元测试，且测试过程中不关注测试对象内部的结构。接口包括被测单元的输入变量和输出变量，tessy通过分析被测单元的源代码自动获取代码的接口。被测单元的接口决定了单元的测试用例的结构。在测试之前对输入变量和输出变量预期值进行设定，测试自动执行完成后，tessy自动对输出变量的预期值与其实际值进行比较，一致则显示绿色，不一致则显示为红色，来判断该测试是否通过，以此进行变量接口测试。对于函数接口，tessy可以针对被调用函数提供打高级桩的选择，从而分析得到函数对应的返回值，形参变量。通过检测返回值及形参变量的类型、数目、顺序和数据传输来进行函数接口测试。

 

 

图3 tessy中接口设置

 

       ♦  1.1.3 故障注入测试

        iso 26262标准规定，故障注入包括随机故障的注入，如通过破坏内存中变量的值来引入故障。如果故障引入是随机的，那么故障注入测试仅仅是指鲁棒性测试，因为这样的测试的结果只能显示测试对象是否崩溃。其实，一个更为有效的故障输入测试要求输入的故障是明确的，响应的输出结果也是明确的，通过对结果的评估来判定功能是否实现。例如空指针的传输，如果在代码中不检查指针，当间接引用一个空指针时将会导致程序崩溃。故而在测试中我们希望可以直接指针输入为null，通过是否会输出异常来确定软件功能的正确性。在tessy中可以支持固定故障的引入，用户可以直接设置指针变量为null，来进行测试。除此之外，tessy还支持桩函数注入故障，通过对桩函数内部编辑自定义代码引入特定的错误行为，检测软件程序针对异常错误的处理行为是否在预期之内。

 

1.2 单元测试用例设计方法要求

        图5对应iso 26262原文第6部分的标准表11：软件单元测试用例设计方法，为了使测试用例满足图1中方法要求，规范指出单元测试阶段用例设计方法应该参照下图中要求执行。

 

图5 软件单元测试用例设计方法

 

       ♦  1.2.1 需求分析

        图5中方法1a需求分析对照图1中的方法1a测试需要基于需求，两者均把需求作为测试用例设计方法和单元测试方法的中心。在单元测试中常见的误区是依据代码进行单元测试，这样的单元测试毫无意义，究其原因是我们的测试目的有些本末倒置。根据代码测试的前提是默认代码的实现方式是正确的，怎么可能检查到设计错误或遗漏的问题呢。所以无论是使用工具测试还是人工编写代码进行测试，用例设计的来源必须是需求，只有满足这个条件，软件单元测试才能可靠有效的检查出软件设计的缺陷。

 

       ♦  1.2.2 等价类生成和分析

        等价类生成和分析又叫做等价类划分。输入输出变量可以拥有多个取值，在测试中覆盖这些变量的所有取值是不可能的（尤其是在检测多个变量组合的情况下），等价类划分法有效的解决了这一问题。它将所有的输入值分为几类，如果测试值被认为在测试中是等价的，则归属于同一等价类。也就是说，如果一个等价类中某个值导致测试失败并生成一个错误，那么此类中的其他值也会导致相同测试的失败，生成同样的错误。

 

        tessy工具所提供的分类树方法编辑器可实现等价类划分方式与边界值取点方式相结合的测试用例设计方法。一个完整的分类树对应的测试用例具有非常高的健壮性，可以完整有效的针对被测对象进行测试。

 

图6 cte分类树设计用例

 

       ♦  1.2.3 边界值分析

        边界值分析一般需要和等价类划分结合进行，边界值的选取是基于等价类的边界。相比于中间值，边界值对于错误的敏感程度更高。在tessy中，边界值分析的方法体现在测试用例设计中。无论是手动输入测试数据还是cte分类树生成测试用例，对于tessy识别到的接口（函数，变量等），在设计测试用例时均需要考虑到这些接口的边界值。

 

       ♦  1.2.4 错误预测

        错误预测法通常要求测试者有一定测试经验，能够凭以往经验找出容易发生错误的测试用例。因此，有别于前面提到的三种方法，错误预测法通常上是没有系统的方法步骤可以遵循。用例设计来源往往是既有项目易发生或已发生的错误。对于方法1c提到的边界值分析，也可以理解为一种错误预测法，因为本质上边界值分析的方法就是基于这些边界可能会出现错误。tessy支持导入既有测试用例和直接设计等方式导入测试用例，对被测代码进行测试。错误预测方式设计的测试用例也可通过这些方式导入进行测试。

 

1.3 软件单元级别的结构化覆盖度量

        图7对应iso 26262原文第6部分标准表12软件单元级结构化覆盖度量。为了评估测试用例的充分性，并证明软件设计没有额外功能错误，规范要求在软件单元测试阶段覆盖范围应该是确定的，需要依照中图7中列出的指标进行度量。

 

图7 软件单元级结构覆盖度量

 

       ♦  1.3.1 语句覆盖

        如果软件单元中所有语句全部被执行，那么语句覆盖率将会达到100%。tessy支持语句覆盖率的自动统计，并将运行结果在源码中对应，直观体现出哪些语句覆盖了，哪些语句还需要增加测试用例进行测试，从而达到100%覆盖要求。

 

图8 tessy中语句覆盖的测量结果示例

 

图9 coverage view中源码覆盖结果

 

       ♦  1.3.2 分支覆盖

        如果软件单元的所有分支全部被执行，那么分支覆盖率会达到100%。tessy支持分支覆盖率的自动统计，通过图9中流程图方式直观体现出哪些分支被覆盖了，哪些分支还需要增加测试用例进行测试，从而达到100%分支覆盖要求。

 

       ♦  1.3.3 修正条件判定覆盖（mc/dc）

        imc/dc考虑的是针对于一个判定如果由多个条件组成以逻辑运算符分隔的情况。如果判定中的所有条件都能独立地影响判定的总体结果，那么将达到100%的mc/dc覆盖率。对于有n个条件的判定，需要n 1测试用例来获得100%的mc/dc覆盖率。tessy可以根据既有用例的执行情况，进行mc/dc覆盖率的统计，通过流程图方式直观体现出哪些条件被覆盖了，哪些子条件还需要增加测试用例进行测试。除了显示功能之外，tessy还可以给出需要补充的用例提示，以达到100%的覆盖要求。

 

图10  tessy中mc/dc覆盖用例补充提示功能

 

2. 软件集成测试阶段要求

        本章节将说明iso 26262-6中对集成测试阶段的要求，并论证tessy工具如何匹配这些测试要求。

 

2.1 软件集成测试方法要求

        图11对应规范iso 26262原文第6部分标准表13。图11中列出了软件集成测试的方法应适用于验证软件组件及嵌入式集成的实现。除了asil等级c对于方法1c的推荐程度不同，图11中陈列方法与asil等级要求对应矩阵和图1完全一致。

 

图11 软件集成测试方法

 

       ♦  2.1.1 基于需求的测试

        iso 26262规范中对于软件集成测试要求同单元测试一致，测试同样基于需求。tessy对于此项要求的支持同单元测试一致。

 

       ♦  2.1.2 接口测试

        与单元测试一样，tessy可以支持集成测试阶段的接口检测。对于变量接口，tessy在单元测试和集成测试的处理方法一致。对于函数接口，tessy在集成测试阶段对于函数接口的处理分为两种情况，组件函数及static类型的内部函数，而这在单元测试阶段并不会体现显示出来，单元测试中所有函数接口的显示方法是一样的，并不会区别对待。

 

图12 集成测试的接口测试

 

       ♦  2.1.3 故障注入测试

        关于故障注入在tessy中的应用，详见章节1.1.3。

 

       ♦  2.1.4 资源占用测试

        tessy测试工具主要是进行单元/集成测试的功能测试，资源占用测试是一个辅助功能，在某些特定环境下可以支持时间特性的测量。除此之外，测试人员也可以通过用户自定义的方式，编写测试代码，来实现内存占用及函数执行时间的测量。

 

       ♦  2.1.5 背靠背对比测试

        针对集成测试，tessy可以以两种方式实现。一高级集成，比如场景测试，在tessy中称为组件测试。二简单集成，在tessy中可以选择unit test选项，但是对于被调用函数不进行打桩操作，在执行时也可遍历被调用函数内部逻辑，以此实现函数集成目的。

 

        针对组件测试，tessy不支持从文件导入数据，因此tessy也就不支持组件测试中的背靠背测试。对于简单集成，可以在测试过程中进行配置，以单元方式进行集成测试，因此对于集成阶段背靠背比较测试，同单元测试一致。

 

2.2 软件集成测试用例设计方法要求

        图13对应规范iso 26262原文第6部分标准表14。为了使测试用例满足图11中方法要求，规范指出集成测试阶段用例设计方法应该依照下图中要求。

 

 

2.3 软件体系架构覆盖度量

        图14对应规范iso 26262原文第6部分标准表15：软件体系架构覆盖度量。为了保证软件集成测试的完整性，并证明软件设计没有额外功能错误，规范要求在软件集成阶段覆盖范围应该是确定的，需要参照下图中列出的指标进行测试。

 

图14 软件体系架构覆盖度量 

        对于函数覆盖，一个功能单元只要被调用1次，就可以覆盖到这个函数。对于调用覆盖，一个功能单元必须被所有可能的地方全部调用到，才能达到调用完全覆盖。

 

       ♦  2.3.1 函数覆盖

        tessy可以支持对被测代码进行函数覆盖的统计，并体现在报告中。

 

图15 函数覆盖示例

 

       ♦  2.3.2 调用覆盖

        tessy不支持对调用覆盖的统计，但是可以通过对分支覆盖的统计，来保证函数调用覆盖。对于tessy中分支覆盖计算，函数调用也会被算作一条分支，因此只要分支覆盖达到100%，调用覆盖即可达到100%。