嵌入式软件，有必要进行自测吗？

嵌入式大杂烩

大家好，我是杂烩君。
本次我们来介绍嵌入式可测试软件设计。
什么是可测试性？就是你这个软件模块/函数接口写完之后，可以较为方便、较为全面地进行自测 。
作为嵌入式软件开发者，我们在开发自己负责的模块之前，大家事先会做什么？
在公司没有规定要写文档的情况下，可能我们很多人会直接开干、写代码。
一些对自己模块比较负责的人，会写设计文档，用于评审或者供给其他同事看。
我个人觉得，在写代码之前，除了写设计文档，还有一点很重要：思考我们的模块如何进行自测。
软件迭代，大多公司的过程如下：
软件工程师开发 -> 释放版本 -> 测试工程师测试 -> 软件工程师修bug -> 释放版本 -> ...
每次发现一个bug，这个bug修复的周期会很长。
所以，我们尽可能地在释放给测试之前，进行一个完整的自测，减少一些不必要的bug产生（主路径bug）。
增加一个步骤：
软件工程师开发 -> 软件工程师自测 -> 释放版本 -> 测试工程师测试 -> 软件工程师修bug -> 释放版本 -> ...
软件工程师自测，这个在我们嵌入式行业，很多大公司可能会作为一个标准的流程。但是在一些中小公司，可能会忽略这个步骤，那这就靠我们自觉了。因为进行充分的自测，受益的也是我们，免去了后面反复地被bug修复打断我们的需求开发。
其实，我们自己模块的开发，除了供给测试工程师测试之外。有时候，我们也会供给我们的团队成员调用，或是其他部门的同事使用，我们在交付出去进行联调之前，需要保证质量，也能免去后面很多的联调成本。
建议大家，写代码之前，写个文档，里面包含：

自测的思考

设计思路并且自测的思考放在设计之前。需要先思考如何自测，因为在思考自测的时候，会对我们的设计也是有帮助的。
举个简单的例子来认识可测试性程序。
有一个计算函数cal_func，其计算依赖于存在flash里的数据a，与一个外部输入的数据b。
此时，有如下两种实现方法：
方法一：
int get_a_from_flash(void)
{
int a = 0;
flash_read(&a, sizeof(int));
return a;
}
int cal_func(int b)
{
int res = 0;
int a = get_a_from_flash();
res = a + b;
return res;
}
// 调用
cal_func(5);
方法二：
int get_a_from_flash(void)
{
int a = 0;
flash_read(&a, sizeof(int));
return a;
}
int cal_func(int a, int b)
{
int res = 0;
res = a + b;
return res;
}
// 调用
cal_func(get_a_from_flash(), 5);
这种类似场景，实际开发中应该有不少，大家平时都是按照方式一写代码还是方式二写代码呢？
从可测试性的角度来看， 方法二的实现，更具备可测试性 。
我们写完代码，一般为了保证质量我们要进行充分的测试。
方式一，因为有一个数据是在函数内部从flash中读取的，所以这个数据我们不太方便进行控制，而能控制的只有参数b。那么，这样子，我们在调用测试时，测得就不是很全，也不能灵活地控制测试路径。
方式二，计算所依赖的数据都通过函数参数留出来了，我们可以很方便地对函数进行测试，可以很方便地输入不同的数据组合。
并且，一般地，我们会引入一些 单元测试框架 ，用来统一管理我们的测试例子。
嵌入式中，常用的测试框架：
Unity：https://github.com/ThrowTheSwitch/Unity/releasescutest：https://sourceforge.net/projects/cutest/embunit ：https://sourceforge.net/projects/embunitgoogletest：https://github.com/google/googletest/releases使用测试框架之后，针对cal_func函数设计的测试代码如：
int ut_cal_func(int argc, char *argv[])
{
    if (argc != 3)
    {
        printf("Param num err
");
        return USAGE;
    }
    // 预期结果
    int expected_res = atoi(argv[2]);
    // 实际结果                  
int res = cal_func(atoi(argv[0]), atoi(argv[1]));   
    if (expected_res == res)
    {
        printf("input %d, %d, test pass!
", atoi(argv[0]), atoi(argv[1]));
    }
    else
    {
        printf("input %d, %d, test failed!
", atoi(argv[0]), atoi(argv[1]));
    }
return0;
}
我们封装成串口测试指令：
// 测试路径1
ut app ut_cal_func 1 2 3
   
// 测试路径2
ut app ut_cal_func 2 3 5
   
// ...
输出：
input 1, 2, test pass!
input 2, 3, test pass!
这就是一个可测试性软件设计的一个小例子，通过这个小例子大家应该认识到可测试性软件的好处了吧？
所以，之后写代码，写之前，有必要先想清楚，这个模块最后要怎么进行自测？要测哪些地方？
设计的软件可测试性强，我们就能在开发阶段进行充分地测试，在开发阶段尽可能多地解决一些逻辑上的问题，从而保证更高质量地软件交付。
以上就是本次的分享，欢迎收藏、转发！

猜你喜欢：
嵌入式编程模型 | MVC模型
嵌入式编程模型 | 观察者模式
手把手教你搭建嵌入式容器化开发环境！一款优雅的嵌入式多功能调试器！
一个非常轻量的嵌入式日志库！
一个非常轻量的嵌入式线程池库！
Github上热门 C 语言项目汇总！
实用 | 10分钟教你通过网页点灯
嵌入式开发必备技能 | Git子模块