基于Matlab建模方式的持续集成策略

由于基于模型的开发内容涉及较广泛，本文主要集中在单元构建阶段。

文章目录

前言

一、单元构建阶段简介

二、单元构建阶段的验证

1.单元静态检查

2.单元动态验证

3.组件内测试

4.组件外测试

总结

---

前言

Matlab作为一款基于模型的设计软件，在汽车行业嵌入式开发中占有很大的比例，对软件开发而言，如何高效的使用其特性来持续搭建符合客户要求的软件模型，是一个不断探讨丰富的话题。在当前ASPICE流行的浪潮中，遇到时代的不断变迁，客户需求的日新月异，软件开发的实际工作不再局限于瀑布式传统开发方法，而是在ASPICE的框架下进行持续集成，迭代交付符合客户期望的产品，缩短开发的周期，以及将验证过程阶段前移，提前发现问题，及时更正，让客户真正参与到产品的验证和确认过程中，而不是在最后的阶段才参与进来导致需求于期望的偏差带来的变更，增加成本的同时，降低满意度。

---

一、单元构建阶段简介

单元构建阶段是软件实现的最后一个阶段，主要是将软件需求，软件详细设计通过编码或者搭建模型的方式进行实现。软件工程师需要对软件需求和软件详细设计具备深刻的理解才能搭建出符合要求的软件模型，故软件工程师通常会担任软件需求工程师和软件架构工程师，在软件需求的早期阶段就开始介入，通过多轮评审，实现对客户需求的彻底理解，从而挑选出合适的算法和架构实现产品的功能。

软件的实现受限于工程师的水平和对产品的经验，故相同的需求搭建出来的模型也是优略各异，常用的模型搭建架构是按照软件分层次的架构实现，同时对功能块的划分要具备高耦合、低内聚等特性，这部分需要软件工程师加强经验积累，同时对于管理者来说，要不断引入新的理念对相关工程师进行培训。

二、单元构建阶段的验证

1.单元静态检查

对于一些常见的易范错误的类型，可以通过编写代码脚本的方式进行软件模块的检查，减少由于粗心大意或者新手不熟悉规则导致的缺陷。常用的方法有如下几种方式推荐：

1）通过使用Matlab自带的检测方法（Matlab advisior）挑选规则对编码模块进行模块静态检查。常用的规则为MAAB，对其中的error项进行更改，对warning项进行识别，按照公司的要求确定是否需要整改。

2）由于每一家公司在经验总结的基础上都会单独提炼出自身的建模规范，对于没有涵盖在MAAB中的一些规则，需要通过编写脚本文件的方式对搭建的模块进行单独检测，进而发现不符合规范的模型搭建方式。此处查找出来的问题一般属于必须整改的条目，需要修改完成并全部通过后才能符合要求。例如：stateflow中的节点跳转条件需要有默认跳转，防止卡死；stateflow中的输入信号名需要与线上的名字一致等等。

单元静态检查可以检查出常见的编码错误，如果检查项足够丰富，一般可以极大的避免软件编码引入的错误，减少测试的成本，且该方法具有自动化的特性，能够减轻软件工程师的工作负担。

2.单元动态验证

在单元静态检查的基础上需要对软件单元的实现进行单元验证，单元的划分要适宜，过小会导致零散，不具备单一的功能，单元验证无法实现对单一功能的验证；划分过大会导致验证起来无法满足分支和覆盖度的要求，导致验证粗糙，通常的软件单元划分至少需要承担一条软件需求的实现，且不要超过三条。

1）单元动态验证首先实现的是模型级别的验证，即通过提取对应的软件单元，搭建输入输出信号，实现预期结果与实际仿真结果的对比，通常借用Matlab的DV工具。具体步骤可参考如下：打开Maltab模型->提取要验证的软件单元为TestObject->提取软件单元包含的parameters，生成.mat文件->搭建测试案例模型（通常使用matlab中的stateflow，对输入和预期的输出信号进行设置,同时Sample Time和仿真时间，以及允许的输出误差需要手动设置），以及生成对应的EXCEL版本->将测试案例生成的数据导入对应的测试案例Excel(自动生成)->生成harness模型以及将案例模型生成的输入输出数据自动导入到模型中的signal builder模块->模型在环测试并输出测试结果（对比预期的输出结果与仿真的输出结果误差是否在设定的范围之内）。如果测试不满足，需要查看是否设置的测试案例不合理，特别是对于具有Ramp,Filter等功能的模块由于其输出结果很难准确预测，需要多次反复修改测试案例。

2）基于模型的测试能够检测搭建模型的准确性，为了确保生成的代码依然能够满足要求，需要对模型进行SIL测试，即将模型转换成代码，在输出信号值不变的情况下，对比SIL仿真的输出结果与MIL仿真的输出结果是否在误差允许的范围内，通常二者基本相同，误差主要是模拟量的精度引起的。

3.组件内测试

此处主要是针对组件或子组件模块的功能进行验证，由于在单元级别已经进行了动态和静态验证，故此处主要是针对软件架构中分配到组件的功能需求进行验证，根据组件的大小，可以进一步拆分成子组件，即多个单元聚合在一起的功能块儿。此处的验证方法属于MIL仿真验证，不用再进行SIL对比，故若不涉及到接口的更改，通常该部分搭建出输入信号后，若需求发生变更，只需要变更预期的输出即可，工作量较单元验证要小很多。

4.组件外测试

此处主要是针对一个大的功能需要多个组件共同完成的场景，主要用于验证接口间的信号传递和时序，该部分有时候也会放到软件集成测试以及软件合格性测试阶段。

---

总结

构建软件单元模块与单元验证是相辅相成的过程，该部分内容在实际开发中是一个个循环迭代，通常若软件单元验证通过，则在后续的合格性验证以及标定测试阶段会极大的减少返工的Bug，从而在某种程度上加快软件的开发，提升软件的质量。