怎么理解SWE.4软件单元测试 Part4- 制定策略

hk4835

通过3篇文章:

怎么理解SWE.4 软件单元测试 Part1 怎么理解SWE.4 软件单元测试 Part2-动态UT 怎么理解SWE.4 软件单元测试 Part3-落地实施

我想已经应该写清楚了什么是软件单元测试，怎么去落地实施。如果还有点疑问点，可以再读一遍，也可以留言一起交流。当别人面试我，或者我面试别人的时候，经常会问：为什么你们选择DC或选择MC/DC？为什么你们选择MIL或选择SIL？为什么要做单元测试？说实话这类问题不太好回答，尤其是在中国汽车软件开发的这块土壤上，可能我们觉得这习以为常了，平时也不太花时间去弄清是怎么回事，反正我们项目就是这样定义的，照着去执行就行。另外，好像我们从来没有看到过量化的数据，来证明到底谁优谁劣。现实情况可能是这样：谁最先定义或提出，然后就这样定下来了。以前我试着去寻找答案，但是似乎从未找到很好的资源，我觉得这里面是应该很有故事。因此，我打算以自己的见闻，尝试上升一个维度来继续探讨软件单元测试策略。1 软件单元测试策略  

暂且我将软件单元测试的计划，规范和报告等内容打包在一起，就称为软件单元测试策略。软件单元测试策略主要取决于软件团队内部的重要成员的经验和认知，大家最先或熟悉的策略是什么那就可能是什么，具体体现形式可能在用什么样的测试工具和测试方法。


比如大家都熟悉Simulink test，那可能就采用Simulink test作为主要工具，纵然它有一些不完美之处；大家之前一直采用MC/DC作为覆盖度指标，也许就继续采用MC/DC，纵然需要花费更多的时间设计测试用例，但是就觉得MC/DC才能更好的测试到一些非预期的功能表现。当然这是有道理的，至少能保证策略能被执行落地，但如果我们去深究，也许会发现可能有一定的优化空间。回归到软件单元测试的目的，即验证设计的逻辑是否满足需求，同时验证是否会出现一些非预期的功能。我们最终目的是排除需求之外的，只留下需求要求的，以此提升软件的质量。那具体如何提升软件的质量，前面文章已谈过，需要至少明确以下几点：

用什么样的方法来测试？比如基于需求的测试和接口测试等用什么样的指标来度量？比如CC、DC和MC/DC等用什么样的方法设计测试用例？比如需求分析和边界值分析等用什么样的形式来验证？如MIL、SIL和PIL等

这些具体怎么选择，没有标准的答案，那不妨先通过经验做选择，再通过不断的工程实践，优化和完善，最终形成了较成熟的软件单元测试策略。对于软件单元测试策略，光有这些还不够，需要有强大的测试工具助力，才能保障软件单元测试的落地，以及提升测试的效率。如何以最少的测试时间投入，获得更优的软件质量至关重要。常听到的单元测试工具有：Simulink test, TPT, ECU-Test，BTC和Tessy等单元测试工具，不管使用何种工具，最终想要达到的目的就是测试者只需要专注于测试用例设计，其他均可通过测试工具实现自动化。


因此，用户通常希望通过对测试工具的配置来实现：

统一的测试框架，适用于任意软件组件；统一的测试管理，运行和使用环境，比如测试用例与需求的追溯，测试用例的管理，测试结果分析与评估，测试报告生成和用户使用或操作的环境等；极其友好的用户操作体验，简而言之，简单好用。

测工具能提供很好的测试平台基础，但通常都需要二次开发来达到相对较完美的使用效果。测试工具也是软件单元测试策略的重要内容，选好工具，事半功倍。上述这些内容属于软件单元测试策略的核心内容之一，从一个软件项目开发角度，需要通盘考虑，包括：   

软件单元测试的输入具体有哪些？什么时候去做软件单元测试？谁负责软件单元测试？怎么去做软件单元测试？采用什么测试工具来执行？软件单元测试验证失败怎么去处理？软件单元测试的交付物有哪些？交付节点是什么时候？是否采用公司已有的模板，是否需要一些技术培训等支持性活动

以上基本就是从正向思考角度来制定软件单元测试策略，这部分内容主要以软件单元测试计划和规范文档形式呈现，另外可能附加一些辅助文档。2 外部需求驱动   实际项目中软件单元测试策略的形式可能会有差异，为什么呢？因为当前软件开发项目的节点越来越短，这导致实际的思路可能是这样，最重要的因素是时间和资源。项目会给多少时间来做软件开发，从而决定会给多少时间来做单元测试。项目会给投入多少资源做软件开发，比如能投入多少个人头，能投入多少预算来买工具。如果项目开发时间短，投入资源少，那就得看碟下菜，灵活裁剪原来的软件单元测试策略，以满足项目的要求。如果项目有ASPICE和功能安全的需求，比如ASPICE就针对每个实践都要有相应的交付物，如下要求的内容：

功能安全同样要求有交付物：

此时，如果客户能够为这些交付物买单，那么项目就可以投入，从而可能确确实实地落实APSICE和功能安全所要求的内容。因此，可以说外部需求也是决定最终的软件单元测试策略。3 小结  

不管软件团队内部驱动，还是外部需求驱动，我觉得逻辑应该这样，至少在自己的认知里有一套完善的软件单元测试策略，知道如何通过更有效的测试提升软件的质量。然后面对不同的项目要求，本着工程问题的折衷精神，合理裁剪，不断实践，最终寻找到一个投入与收益的平衡点，一个合适的软件单元测试策略。

---

创作不易，欢迎关注点赞收藏分享。