• 正文
  • 相关推荐
申请入驻 产业图谱

嵌入式软件,有必要进行自测吗?

04/02 09:50
633
加入交流群
扫码加入
获取工程师必备礼包
参与热点资讯讨论

大家好,我是杂烩君。

本次我们来介绍嵌入式可测试软件设计。

什么是可测试性?就是你这个软件模块/函数接口写完之后,可以较为方便、较为全面地进行自测 。

作为嵌入式软件开发者,我们在开发自己负责的模块之前,大家事先会做什么?

在公司没有规定要写文档的情况下,可能我们很多人会直接开干、写代码。

一些对自己模块比较负责的人,会写设计文档,用于评审或者供给其他同事看。

我个人觉得,在写代码之前,除了写设计文档,还有一点很重要:思考我们的模块如何进行自测。

软件迭代,大多公司的过程如下:

软件工程师开发 -> 释放版本 -> 测试工程师测试 -> 软件工程师修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 errn");
        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!n", atoi(argv[0]), atoi(argv[1]));
    }
    else
    {
        printf("input %d, %d, test failed!n", 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!

这就是一个可测试性软件设计的一个小例子,通过这个小例子大家应该认识到可测试性软件的好处了吧?

所以,之后写代码,写之前,有必要先想清楚,这个模块最后要怎么进行自测?要测哪些地方?

设计的软件可测试性强,我们就能在开发阶段进行充分地测试,在开发阶段尽可能多地解决一些逻辑上的问题,从而保证更高质量地软件交付。

以上就是本次的分享,欢迎收藏、转发!

点赞
收藏
评论
分享
加入交流群
举报

相关推荐

登录即可解锁
  • 海量技术文章
  • 设计资源下载
  • 产业链客户资源
  • 写文章/发需求
立即登录

本公众号专注于嵌入式技术,包括但不限于C/C++、嵌入式、物联网、Linux等编程学习笔记,同时,公众号内包含大量的学习资源。欢迎关注,一同交流学习,共同进步!