嵌入式自动化测试

嵌入式自动化测试

目前该测试主要用于底层开发完成后的自测。

1. 前言

道友们，在做嵌入式开发时你们会对自己的代码进行测试吗？答案毋庸置疑，在工作中，谁不会对自己的代码做测试，自测是对每个工程师最基本的要求，不然谁来保证代码的可靠性。一般公司里面都会具备静态测试、单元测试、集成测试、系统测试等等，所以一整个测试流程下来代码的可靠性和稳定性都是比较高的。但是一般而言，这些都是针对上层的测试，但是对于底层的测试有人关心过吗？我也有跟同行聊到过这个话题，一般对于底层测试这一块基本都是空白的，大多数都是手动测试，顾名思义就是需要测试的时候就手写测试代码集成在目标工程中跑一下，测一下有没有问题。当然我之前也有这么做过，并且我还对此做了一些优化，上了一些框架。下面我先说下我之前的一些被淘汰掉的测试方法：

• shell 命令行测试：
  shell 命令行测试就是把letter-shell组件集成在工程中，然后将测试接口写成一个个指令，然后上位机通过shell 命令行的方式控制下位机执行，上位机和下位机之间靠uart通讯。但是这个测试方法需要开发人员手动去输入命令行，非常的麻烦，只能做一些基础的功能测试，并且测试结果也需要人工去审查。
  

• C-Unity：
  我去网上搜罗了一个测试框架 C-Unity，这个框架可以帮助开发人员编写测试用例并且可以输出测试报告。这样有一个好处就是有了测试框架可以规范测试用例的写法，但是同样的由于所有的测试代码都是固定死的，每个测试用例的测试步骤都必须手写完成，比较死板，而且输出的测试报告密密麻麻的看的人头大。而且针对通讯方面的测试也没有办法执行，因为没有交互对象可言，比如CAN通讯，我需要有一个上位机和下位机进行交互用以测试下位机发送和接收的可靠性和稳定性等等。
  
  

在体验了上面两种测试方法后，我觉得这些都不够称得上“自动化”测试。尤其是在汽车行业使用Autosar，面对不同的开发平台需要经常变更和迭代MCAL，而这些都是第三方提供的，其中也存在各种各样的BUG，因此底层测试也将变得繁琐起来。还有就是随着DBC的变更，通讯栈也会发生频繁的变更，众所周知CAN通讯在汽车交互中起着非常关键的作用，因此针对通讯栈的配置和CAN通讯的可靠性也需要进行严谨的测试。

所以我决定自己开发一套测试框架用来实现我想要的自动化测试，能够让我轻松的完成底层开发后的测试。这套测试框架需要满足以下几点：

• 测试报告可视化
• 测试用例灵活性高
• 交互性强
• 通用性高
• 方便集成

OK，我们通过下面的内容开始介绍本文真正的主角。

2. 整体框架介绍

整体测试框架如上图所示。我们将测试用例导入到上位机，上位机与下位机通讯，完成测试后输出测试报告，这就是整个测试流程。

整体分为三个部分：

• 上位机：解析并运行测试用例，下发测试指令，输出测试报告
• 测试板：执行上位机下发的测试指令，给被测板提供IO输入和获取被测板的IO输出，并且给上位机反馈测试信息
• 被测板（产品板）：执行上位机发下的测试指令，给上位机反馈测试信息

OK，废话不多说，我们先直接看测试效果，后面再对各个部分展开介绍。

2.1 上位机展示

2.2 测试报告展示

如上图所示，我们将测试用例导入上位机后，然后在上位机上配置串口、CAN设备、DBC，然后点击运行即可开始测试。在测试过程中上位机也展示所有的测试用例以及动态的执行结果。在测试完成后会输出一份测试报告，测试报告里面能够展示测试用例、测试步骤以及统计结果。

OK，今天先介绍到这里，大家感兴趣的话可以留言，我再更新。

3. 上位机介绍

3.1 整体框架

3.2 测试用例

3.3 测试报告

3.4 交互功能

4. 下位机介绍

4.1 测试框架