SDK的自动化测试离不开CICD，简单来说，测试人员手动/定时通过Jenkins向服务器发送请求，服务器通过openocd服务将编译完的程序下载到待测板和辅助板中，然后通过辅助板/待测板的打印来断言测试的结果
CICD部分的框架搭建可以参考以下文章
在一家初创企业如何快速搭建自动化测试流程(CI/CD, 测试管理系统，分布式自动化测试） - 知乎
而SDK的例程运行在开发板中，因此相较于普通的软件测试，SDK的自动化又离不开硬件的实现
SDK例程的手工测试中，我们需要将代码编译后烧录至芯片中，然后通过芯片引脚信号、打印等信息来判断例程的正确性；同一份代码往往支持多种编译方式，同一块MCU也许也支持不同的代码存放路径（flash，sdram），公司也往往是多种型号的MCU支持同一份代码，因此一份sample的代码往往会被测试N次，自动化的性价比也就变得非常高了
对于简单的代码，例如烧录后仅会打印“hello,world”至串口，那对于自动化来说也非常简单，你只需要去串口中捕获这个字符串
对于复杂的功能，譬如从引脚输出一个PWM波的例程，在手工测试中，需要外接示波器进行测试，而在自动化测试中，也就必须要通过另外一块板卡，将输出的信号通过输入捕获后计算得出周期和占空比，然后去判断是否通过
需要使用两块板卡(DUT)的自动化例程，必然面临如何区分这两块DUT的问题
这里给出两种方案：
- 将两块DUT接在不同的test executor下，通过软件去实现区分
- 如果DUT支持SN号，那么在你开启openocd服务时，指定SN号
这就是对于非回环的输入输出自动化的核心思路，往待测板内烧录待测的程序，再往辅助板内烧录辅助程序
举一个更具体的例子，HPM6200evk的GPTMR的输出比较例程，将PC08引脚初始化为GPTMR2的CMP1，例程开始后，通过PC08输出周期为1S，占空比为30%的方波；为了验证程序的有效性，在辅助板中运行的程序是对PWM周期和占空比的测量，然后在串口中打印捕获到的信息；然后，将辅助板的输入捕获和测试版的输出比较引脚（PC08）连接起来，就完成了硬件环境的构建
如果拥有足够的硬件资源，那么你可以搭建N套这样的环境，对于辅助板和待测板之间的接线，可以设计一款转接小板，两块板子插在一起即可，也没有接线的烦恼
当硬件资源受限，需要辅助板一对多的时候，又该怎么办呢
还是大体有两种方案
- 假设你的开发板有非常丰富的外设，且这些外设都通过引脚接了出来；根据最受限的资源（譬如你的开发本只有两个DAC输出）的数量，决定了你这块板卡可以一对N的能力；本质上还是之前一对一的方案，只不过用不同的外设分配给不同的待测板
- 利用模拟开关实现同一外设测试多块不同的测试板
接下来具体讲讲这第二种方案
模拟开关根据型号的不同，往往有不同的功能，例如CD4067，支持4个控制信号(ABCD)，一个使能信号(INMIBIT)，通过4个控制信号决定主路和0-15路支路哪一路导通；以此为基础，就可以实现1：16的测试环境搭建
在测试开始的时候，辅助板通过4个引脚控制ABCD这4个控制信号，决定COMMON IO与哪一个支路导通；这时其他支路截止，不会对测试造成干扰
对于稳定环境的搭建，也可以通过PCB的方式去固化环境，避免环境的维护性较差
可以画一块大板，满足所有需要用到的测试信号，然后待测板再接到这块大板上，这样的环境也是稳定的
也可以画几块小板，小板之间通过级联的方式传递控制信号
假设一块板上只测三个信号，不同的待测DUT接到对应的引脚上，当辅助板与DUT1导通时，三个模拟开关同时导通（因为ABCD这四个信号在不同模拟开关上是串联的）；通过这种方式就可以实现，辅助板即和DUT1直连，又和DUT2直连的这种假象了
当然，模拟开关对于高频信号没有直连那么优秀，如果是10MHZ以上的信号，就要考虑别的方案了
文章来源：https://www.toymoban.com/news/detail-830360.html
文章来源地址https://www.toymoban.com/news/detail-830360.html
到了这里，关于MCU原厂是如何对例程进行自动化测试的的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
