利用Controller Tester进行基于场景的集成测试

何为基于场景的集成测试？

基于场景的集成测试是指用基于软件架构设计场景，从综合角度验证软件功能出发，执行集成测试的一种方法。

通过执行基于场景的集成测试，可以验证软件的架构设计遵守状态、硬件和软件接口明细遵守状态、可能性以及使用的适当性等。

图 1 ISO 26262 : V-model、集成测试方法、覆盖率测量指标

通过ISO 26262的V模型我们可知，集成测试是在单元测试之后进行的，它是为了确认软件各单元的集成是否顺利，组件之间的集成是否顺利而进行的测试阶段。

集成测试和单元测试一样，根据目标软件等级（ASIL, Automotive Safety Integrity Levels）的不同，有与其相应的推荐方法及需要满足的结构性覆盖率（Structural Coverage: Function coverage, Call coverage），正如前面所提到的，为了满足这一要求，需要基于设计需求生成场景进行集成测试。

通过执行基于场景的集成测试的优点是：针对在HILS（Hardware In the Loop Simulation）或系统测试中发现的特定场景的缺陷，进行基于场景的集成测试，可早期发现并快速应对发现的缺陷，从而节约人力、物力资源。基于设计要求的测试不仅适用于汽车领域国际标准ISO 26262，也适用于核能测量控制器、铁路、国防等多个领域。

利用Controller Tester进行基于场景的集成测试的流程

流程如下图所示

基于场景进行的集成测试的流程如上图所示，与基于覆盖率的普通集成测试最大的差异在于是否有测试场景。

首先，在Controller Tester中，构建一个基于环境信息创建的开发环境，例如集成开发环境和目标软件的编译器版本，然后继续构建一个测试环境以通过创建一个测试项目来生成测试代码。

测试环境构建完成后，与单元测试流程一样，生成进行测试所需的附加测试代码

Controller Tester通过分析设计需求、详细设计及代码，反映所使用的变量的输入/输出信息或必要的存根信息。此时，集成测试将设定进行测试的项目对象范围，小至模块，大则可以TASK为单位进行。

集成测试对象的范围越大，测试需要花费的时间就越长，但测试可以更接近实际代码运行环境。

环境构建完成后，基于反映的信息生成测试用例。执行基于场景的集成测试首先需要测试场景。已有测试场景的情况下可以直接执行相应的集成测试，当场景不存在时便可参考SDD(Software Design Description), SAS(Software Architecture Specification), SRS(Software Requirement Specification)等资料生成场景。

基于场景生成测试用例进行测试的方法如下。

下图是ADAS ALC(Adaptive Light Control)功能的SAS内容中体现的ALC状态趋势，通过这些信息我们可得知生成并执行测试场景的方法。

基于ADAS  ALC(Adaptive Light Control)生成上述场景后，利用Controller Tester将场景的条件作为输入值、输出值为期待值，生成测试用例并执行后确认结果。

但是，如果测试结果与TC2一样，对场景输入值制定的期望值与实际输出值不一致，则判断为SAS或源代码存在缺陷，并将对其原因进行分析。 如上所述，通过HILS或系统测试可以确认存在上述缺陷，但通过基于场景的集成测试能在早期发现缺陷。

在执行基于场景的集成测试时，即使对准备好的场景全部进行了测试，也可能无法满足结构性覆盖率（Structural Coverage: Function Coverage, Function Call Coverage）。这种情况下，可以追加生成场景，以满足覆盖效果;若无法生成场景，则可通过其他方法增加测试用例，测量覆盖率，反复执行测试，直到满足规定的覆盖率为止。

如果利用Controller Tester功能中的"覆盖率视图"功能或以选择的函数为中心，可以确认函数调用关系信息的"函数调用图表(Function Call Graph)"，可更轻易确认覆盖率满足程度。

在集成测试中确认的Function Coverage是指被选择的函数是否在对象范围的流程中被调用的Coverage，而Function Call Coverage是指被选择的函数调用的函数Coverage。
确认测试结果时，通过分析可能产生致命错误的部分或获取无法满足覆盖率的原因，如单元测试相同，导出各类型软件的缺陷。

我司的Controller Tester不仅可执行单元测试，也可帮助嵌入式软件在目标环境或与目标环境类似的主机环境中轻松进行集成测试。