在整个软件修改过程中需求开发和测试开发的工程师都注意到了这条变动，更改了相关的需求规范和测试规范，唯独在Coding和Implementation这个环节漏掉了这项更改。该规则与程序实现的功能无关，与程序运行效率无关，甚至有些程序要符合MISRAC规则会看上去非常的“傻气”。上图显示条件覆盖度为83%，MCDC覆盖度为67%，针对这个代码测试用例是不充分的。新课程，敬请关注IND4汽车人1《拧紧扭矩的计算与测量》
作者：JACK（来源：IND4汽车人）
在OEM打交道的过程中，ECU供应商常常会碰到类似“你们的软件质量怎么样？你们怎样来保证你们的软件是可靠的？你们都做过了什么样的测试？”这样的问题。
OEM听到的回答往往是“我们在出厂之前会做大量的软件测试、台架验证和实车测试，保证所有功能都得到了实现；此外我们还会进行故障注入测试，保证当我们的系统在发生任何故障（当然是已经定义的故障）的情况下都是安全的。”
如此充其量只能说是一个初级阶段的回答，也只是部分的符合了主机厂所期望的答案：
·功能测试和故障注入测试只是软件测试的一部分，即使测试用例100%覆盖了所有的功能需求和安全需求（假设有这么两份文件的话），不能排除软件中存在其它的分支导致系统出现其它非预期的结果。
讲个小小的故事吧：
某车灯控制的功能需求为开关1和开关2以或逻辑实现对灯的控制，该功能需求在某历史项目的基础上做了一点点改动（之前的功能需求为开关1/2/3三者以或逻辑实现对灯的控制）。在整个软件修改过程中需求开发和测试开发的工程师都注意到了这条变动，更改了相关的需求规范和测试规范，唯独在Coding和Implementation这个环节漏掉了这项更改。
于是测试人员按照下表Test Vectors进行测试：
由于在测试过程中，给switch3的输入一直给的是一个0信号，因此所有测试都通过了，但这个BUG却结结实实的流出去了，功能需求的改动根本就没有得到执行，只要Switch3信号为1，灯就被打开了。这种貌似非常低级的错误看起来相当可笑，甚至觉得是笔者牵强臆造出来的，但这实际上是真真实实发生过的事实。
·虽然主机厂不要求供应商提供软件源码，但主机厂期望有一个量化的数字能够反映软件的可读性、可维护性和可测性，以上功能测试并不能回答上述问题。部分主机厂会要求供应商提供特定工具的检测报告（如Coverity/QAC/Polyspace静态分析后的缺陷报告，Defensics网络漏洞检测报告等）。
·软件中是否有其它潜在的BUG？测试的覆盖率有多少（这里指的是针对软件代码的覆盖率而不是针对功能需求的覆盖率）？
其实说白了，这些问题都指向了软件的健壮性（鲁棒性），下面从方法论上简单地讲讲怎样控制并提高软件的开发质量即软件的鲁棒性。
（一） 流程开发
一般来说我们需要按照如下的过程进行软件的开发工作（仅作示例，尚未考虑Model based design部分，MBD的部分会包含建模规范检查，模型Review， MIL， SIL等测试，用到的工具如MES model Examiner， BTC等）。
而实际上在软件质量做的比较低的公司里，往往只做了软件的Coding工作和testing工作，REVIEW做的很少 ，也没有一个公司级别的完整的Checklist和代码编写规范。
RviewCheckList示例：无非从软件开发的方方面面进行启发式的提问，帮助发现问题。
代码编写规范示例：
（二） 软件静态分析
软件静态分析主要是利用一些专业的分析工具（如：Coverity，QAC，Polyspace等）对软件代码进行检查。主要有三方面的检查工作：
（2.1）对MISRA C规则的符合情况
MISRA C规则是由英国的汽车工业软件可靠性协会（The Motor Industry Software Reliability Association）组织在对大量程序员及软件代码进行了调查的基础上、结合了不同的编译器的编译规则，所总结出的一套C语言编码规则。该规则与程序实现的功能无关，与程序运行效率无关，甚至有些程序要符合MISRA C规则会看上去非常的“傻气”。但这个规则是基于“大数据”总结而来，遵守该规则将使得你的程序最大限度的减少潜在的Bug，并且有很好的可维护性和在不同平台之间的移植性。
（2.2）软件Coding质量度量
软件分析工具能给出数十个用来度量source code质量的指标数据。一般来说，常用的是下面几个：
（2.3）代码安全性、缺陷检查
软件的缺陷如并发缺陷、算数错误、变量未初始化、资源泄漏，控制流缺陷，非法内存访问，内存崩溃等诸多缺陷；安全性会涉及到优先权扩张、保密数据泄漏、数据丢失、仲裁代码执行、整型溢出、缓冲区溢出、安全编码缺陷等。
（三） 软件动态测试
动态测试是指通过给软件一定的测试用例，检查软件执行以后的结果与期望输出的符合情况,可以使用的软件有SIMULINK/TESSY/BTC等等（参考前文《小议MIL/SIL/PIL/HIL（一）》）
同时软件会对测试用例的覆盖度进行分析。覆盖度的分析参数有路径覆盖、条件覆盖、判定覆盖、修订的条件/判定覆盖（MCDC）等。对安全级别要求比较高的产品，一般都是要求MCDC达到100%的覆盖率（如果因程序员从可靠性角度出发特意编写了一些冗余的代码导致某些代码不可测，则需要在测试报告中撰写justification进行声明）。
回到文首我们讲的switch logic的例子，看看我们用表格1所用的测试用例能达到多少的覆盖度？
上图显示条件覆盖度为83%，MCDC 覆盖度为67%，针对这个代码测试用例是不充分的。因此基于这个统计数据，在软件的UnitTest阶段就能发现Bug，从而不至于流到客户。
最后，让我们来看看，按照上述流程完成了软件的测试及质量度量以后，我们可以这么回答OEM:
“我们的软件首先要做单元测试，我们的软件符合绝大部分MISRA C规则的，不符合的部分我们经过了专门的分析，没有潜在的风险；然后我们还要做软件圈复杂度、软件静态路径数等软件质量度量分析，代码质量和安全性分析，不合规的软件即使实现了软件功能我们也要做整改；我们单元测试的MCDC覆盖度目标是100%，保证了使用足够多的测试用例进行测试，单元测试以后，我们还要进行台架集成测试、整车验证和故障注入测试，所有的功能需求和安全需求都得到了100%的验证，所以请您放心，我们的软件是可靠放心的。如果需要，我们可以提供测试工具的分析报告。”
这样的回答，是不是很酷？
新课程，敬请关注IND4汽车人1
《拧紧扭矩的计算与测量》
