​怎么理解SWE.4 软件单元测试 Part3-落地实施

shuizhonghua

针对软件单元测试，已经通过两篇文章：  

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

介绍了单元测试的基本概念和规范等内容，本文基于Simulink环境来介绍具体的落地方案。
1 落地方案
之前文章借助模型举了两个例子，因本文需要，特将这两个模型放到同一个软件组件（SWC）中，如下所示：

通过之前文章可知，做软件单元测试前，首要的是确定测试对象，即软件单元。这里，软件单元可以是SWC EX所包含的EX1，也可以就是SWC EX，这么说的原因是因为这个模型很简单。方案1先介绍一个最简单原始的方案，不局限于测试资源，在任何公司都可以落地。该方案就是设计好测试用例，以simulink支持形式将测试用例导入模型，比如使用Signal Builder作为输入形式，对于给定的输入，直接观察运行结果是否符合期望的结果。若以SWC EX为软件单元，落地方案如下所示：   

这个方案我曾经应用过，但没法应用于一个多人的团队，也没法去形成良好的软件开发流程，有一系列的缺陷，测试用例不好管理，模型如何保证不被修改，测试结果不能自动评估等等。不过这方案是原始的，自然存在很多可以改进的地方，比如：

这里直接假设软件组件就是软件单元，而实际的量产软件开发，软件组件可能非常复杂，那么软件单元范围该如何定义？这是第一步，比如这里也可以将EX1, EX2定位为软件单元；如何自动评估测试结果？即导入期望的测试结果，可以与运行后的实际结果自动对比，以评估测试是否通过；如何有效地管理测试用例？以及如何来实现单元测试与需求追溯？如何可以改变被测对象的标定量，以验证与标定相关的功能？如何设置软件单元测试的运行环境和测试指标？

针对以上这些问题，接下来的方案2基本都可以解决。       方案2方案2是采用Mathworks所提供的测试工具Test harness和Test manager（Simulink test），通过Test harness构建单元测试框架，再通过Test manager构建自动化的测试管理环境。大致落地操作步骤如下：首先利用Test harness构建目标软件单元的测试框架，操作如下：   

利用Test  harness构建测试框架，输入有几种形式，如下所示：



这里选择inport类型，最终构建Test harness模型由被测模型，输入信号和输出信号三部分组成，如下所示：


当软件单元的测试框架都构建好了之后，然后就是使用Test manager进行构建自动化的测试管理环境，新的一点simulink版本叫Simulink test, 老一点的版本叫Test manager。


进入Test manager界面后，针对一个软件组件，其操作顺序如下：1．创建test file，在该层级可以设置软件单元测试的通用要求，比如测试的需求链接导入，覆盖度设定和测试报告设定等内容。   

2．然后可以按功能划分创建Test suite，在该层级，如果覆盖度有特殊要求，可以额外的设置。

关于Test Suite，每一个测试文件中，都可以定义若干个Test Suite，可以把同一类型或同一功能的测试用例放到一个Test Suite中。https://blog.csdn.net/wx17343624830/article/details/130527843

3．最后在相应的Test suite下创建Test case，去配置每个软件单元的测试环境，需要的配置包括不限于：需求链接，Test harness模型导入，参数或标定量的数值修改，测试用例和期望结果导入，迭代次数等设置等。

关于Test Case，每一个Test Suite中都可以定义若干个Test Case，Test Case中规定了测试详细的执行信息。实际测试执行的时候也针对每一个Test Case进行测试的。https://blog.csdn.net/wx17343624830/article/details/130527843

依此方法设置好每一个测试用例后，最后运行一个或整个软件组件的测试用例，就可以得到单元测试结果和单元测试报告。

以上就是基于Test harness和Test manager来实现软件单元测试的方案2，总体上解决了方案1需要改善的问题，已经是相对不错的方案了，最近我也深度体验了一番，小批量的测试能接受，但是对于一个软件开发团队来说，可实施性还是不太好，仍存在一些痛点：

对于工具的操作仍然繁琐和耗时，对于一个由成百上千的软件组件的软件项目而言，没有可操作性；对于软件单元而言，在软件开发过程中，软件单元既有可能产生接口或者内部逻辑的变更，这样会导致需要重新构建Test harness模型，没有继承性与维护性。
对于软件单元测试的覆盖度，在实际测试过程中经常会碰到覆盖度未满足的情况，这时需要分析原因而去查看覆盖情况，目前操作仍有点复杂。

针对这些痛点（可能对工具功能有待挖掘的地方，有兴趣指出的可留言），那意味着又有很多改进的地方，接着看方案3。
方案3针对已有的被测模型，需要构建自动化测试框架和测试管理环境，一个统一的测试框架，适用于软件项目中的所有软件组件，如下示意：


这样对于开发或测试人员来说，工作重点在于测试用例的设计和期望结果的计算，而不需要花大量时间去做测试的配置工作，并且操作还要力求简单，才能在多人团队更好的落地。曾经项目中，以软件组件作为软件单元，就构建了这样统一的测试框架，落地效果非常好。

---

以上就是针对软件单元测试方案的介绍，从方案1的原始操作到方案3的高度自动化，这就是一个解决工程应用问题的典型过程，不断迭代和优化，最终形成一个比较满意的结果，有机会再具体展开方案3如何实施，总体而言，基于模型的如那件单元测试，Mathworks所提供的工具基本都具备，只是如何通过脚本进行二次开发，以适应一个可以大规模的软件团队的更简洁自动化的方案。


创作不易，动动你的小拇指欢迎点赞收藏转发，也欢迎继续关注下篇文章，小结一下软件单元测试的方方面面。

---