怎么理解SWE.4 软件单元测试 Part2-动态UT

lixinfu

标准总是抽象的，我们可以实例来消化。

参考功能安全国标GB/T 34590.6-2017对于软件单元测试的要求，比如软件单元测试方法，软件单元测试用例的得出方法，软件单元层面的结构覆盖率度量和软件单元测测试的测试环境，这是其实都是针对动态单元测试。因此为了更好地理解动态单元测试，本文将针对基于模型设计的软件开发，对这几个方面做详细的说明。
在开始下文前强调一下软件单元测试的目：

验证软件单元满足软件单元设计规范；验证软件单元不包含非期望的功能。

1 软件单元测试方法   

GB/T 34590.6-2017对于软件单元测试方法要求如下表：


对于不同的ASIL等级，所要求的采用方法不一样，总的来说，不管哪一个ASIL等级，基于需求的测试和接口测试是必须要执行的。  故障注入测试和资源使用测试主要针对ASIL D的需求，这种一般不在应用层软件执行，而是应用层软件和底层软件集成后再执行。

基于需求的测试很好理解，根据详细设计文档来进行测试。而接口测试是针对接口属性执行的测试，比如测试软件单元的模型或代码的输入与参数在个数、属性、量纲、顺序上是否一致。

举一个简单的例子来说明接口测试进行数值范围验证: 假设软件单元的模型有一个输入类型为uint8，即数值范围为[0,255]，应用边界法进行接口测试用例设计，可设计测试用例取四个点：-1，0，255，256，以此来验证该接口的数值范围是否正确。

对于基于需求的测试和接口测试的关系，可以理解为两者的范围存在一定的重叠，以基于需求的测试为主，接口测试用做查缺补漏。
2 软件单元测试用例的得出方法
GB/T 34590.6-2017对于软件单元测试用例的得出方法如下表：



这里是想表达怎么去设计测试用例，有这样几个思路或方法: 根据需求分析，等价类的生成和分析，边界值分析等来做。结合例子来说明: 假设有需求: VCU需要获取某温度传感器的物理信号，然后判断温度是否有效（[0,140]℃），是否过温（>120℃），模型逻辑如下：


采用基于需求分析的方法，可以设计如下测试用例来验证是否满足需求，得到期望的结果。


这样设计的测试用例虽然能验证设计满足需求，但一些关键数据点并未测试到，那么如何用更少的测试用例来覆盖更多的测试，通常采用等价类划分和边界值分析相结合的方法。等价类划分是指根据需求将输入划分成若干个等价类，从等价类中选定一个测试用例，如果该用例通过，则表明整个等价类通过，目的是使用较少的测试用例尽可能多覆盖功能。边界值分析法是对等价类划分法的补充，一般从等价类的边界寻找错误。正好等于边界值，刚好小于边界值，刚好大于边界值作为测试数据。接着上面的例子，对于温度是否有效可以划分为三个等价类，对于温度是否过温可以划分两个等价类，若同时考虑两者，可以合成4个等价类，如下所示：

再根据边界值分析方法设计测试用例，取值6个温度值，并计算出预期的结果，如下所示：


3 软件单元层面的结构覆盖率度量GB/T 34590.6-2017对于软件单元层面的结构覆盖率度量如下表：

这里是从不同角度对被测模型或代码进行测试，通过实例来详细解释常用的几个覆盖率：语句覆盖率，分支覆盖率，条件覆盖率和MC/DC。假设：

如果A与B同时为真，则执行动作1；如果A与B不同时为真，且A1或B1为真，2则执行动作2；如果A与B不同时为真，且A1或B1不为真，则执行动作0。

模型如下所示：


模型从if的条件开始判断，由上向下来执行，如果if成立，则执行其动作1；如果if不成立，则看elseif，其成立则执行动作2，否则执行动作0。1）语句覆盖语句覆盖（Statement Coverage）是要求所有代码被执行一遍，即动作0，1，2都需要被执行一遍。因此，设计测试用例使得：

A与B成立，去执行动作1；A与B不成立，但A1或B1成立，去执行动作2；A与B不成立，且A1或B1也不成立，去执行动作0。

如下所示：


2）分支覆盖分支覆盖（即判断覆盖，Decision Coverage, DC）是要求设计用例对模型或代码中所有的逻辑判定分支都被执行测试，即每个判定逻辑真假两条分支都需要被测试到，接着这个例子，那么：

首先对于if分支，其成立与不成立的情况都要考虑。成立则A与B为真，不成立则A与B为假；然后对于elseif分支，同样地，其成立与不成立的情况都要考虑。成立则A1或B1为真，不成立则A1或B1为假；

因此设计测试用例进行分支覆盖，如下所示：



从图可以看到只有3行测试数据，对此稍作说明：当if不成立（A和B不全为1）时，是为了测试if为假的分支，但此时可以测试elseif的分支情况，因此测试了elseif为真或为假的分支。因此只需要设计三个测试数据点就可以做到100%分支覆盖度。注意对比语句覆盖和分支覆盖，虽然这里它俩使用了相同的测试用例，但是设计测试用例的思路是不一样，再通过一个例子来理解，如下：

3）条件覆盖条件覆盖（Condition Coverage, CC）是要求测试设计时涉及逻辑判定的每个条件均要考虑到真假两种情况，覆盖时通常不考虑每个条件测试取值对整体判定路径覆盖的影响，也不考虑条件间的组合，只考虑每个条件要设计真假两种情况，如下所示：


上图示意的两种测试用例设计都满足条件覆盖的要求，甚至还存在其他的测试用例，但是图示的两种测试用例对分支覆盖是有差别的，比如右上角的用例对于A与B的两条分支都覆盖到了，但是右下角的用例却只覆盖到A与B为假的分支；同样地对于A1或B1来说，右下角的用例只覆盖A1或B1为真的分支。

由此可以看出：条件覆盖只要求每个条件的真假要被覆盖，不关注条件之间的组合或组合对最终判定的影响。因此，如果使用仅符合条件覆盖要求的测试用例，在某些情况下可能导致某些分支不会被覆盖。那有没有这样一种覆盖方案：既考虑分支的判断覆盖又满足参与判定的条件覆盖？有，比如MC/DC，对条件覆盖和判定覆盖组合后进行了一定的修正。
4）MC/DCMC/DC（Modified Condition/ Decision Coverage）是要求在程序中的每一个输入和输出点要至少被调用一次，程序里一个判定中每个条件要至少一次考虑达到所有可能性的结果，程序里每个判定至少一次考虑达到了所有可能性结果，并且一次判定中的每个条件已体现独立地影响该判定的结果。一个条件可以通过以下方式独立地影响决策的结果：

只改变该条件，同时保持所有其他可能的条件不变；或只改变该条件，同时保持所有其他可能影响结果的条件不变。

因此设计测试用例进行MC/DC覆盖，如下所示：


具体测试用例怎么设计出来的，分析与设计思路如下：首先针对模型的逻辑，根据MC/DC的要求，每个判断都需要被覆盖，因此A与B为真为假的情况都需要考虑，当A与B为假时，A1或B1为真为假的情况也都需要考虑；然后MC/DC要求一次判定中的每个条件已体现独立地影响该判定的结果。针对A与B为假时，A真B假和A假B真都需要考虑。当A与B为假时，同理考虑A1或B1为真为假的情况，最终得到了测试用例，如下所示：


4 软件单元测测试的测试环境
GB/T 34590.6-2017中，对于软件单元测试的测试环境,应尽可能地接近目标环境。如果软件单元测试不是在目标环境下执行,应分析源代码和目标代码的差异及测试环境和目标环境之间的差异,以便在后续测试阶段的目标环境中定义额外的测试。软件单元测试可以在不同的环境中执行，即可以采用MIL/SIL/PIL/HIL等测试方法。其中：

MIL，Model in the Loop：模型在环测试，验证控制算法模型是否满足功能需求；SIL，Software in the Loop：软件在环测试，在PC上验证模型是否与代码功能一致；PIL，Processor in the Loop：处理器在环测试，在目标处理器上验证模型是否与代码功能一致；HIL，Hardware in the Loop：硬件在环测试，在ECU/整套系统上验证代码是否与需求功能一致。

  source: 自动驾驶测试：MIL、SIL、PIL、HIL_mil sil-CSDN博客通常，对于动态单元测试，最常用的MIL/SIL测试环境来验证功能需求。
5 小结以上就是针对GB/T 34590.6-2017中对动态单元测试的较抽象定义通过实际的例子来详细解释和说明，并给出了很具象的落地思路，如果还有什么问题，可以关注后续文章，再详细地分享一个针对某个SWC的动态单元测试。

---

创作不易，欢迎点赞收藏再看关注！