苏州公司做变更网站,如何开发游戏软件,比较经典的营销案例,企业邮箱网易嵌入式软件测试相关分析
1. 引言
在软件发展之初#xff0c;上个世纪五六十年代#xff0c;软件被视为数学领域#xff0c;编程是为了进行数学计算#xff0c;由数学公式推导#xff0c;来写函数。因此#xff0c;在那个时候所编写的程序是被视为数学问题#xff0c;数…嵌入式软件测试相关分析
1. 引言
在软件发展之初上个世纪五六十年代软件被视为数学领域编程是为了进行数学计算由数学公式推导来写函数。因此在那个时候所编写的程序是被视为数学问题数学的一大特征即是可证明性可以使用数学推导的方式来证明一段程序的正确性。但是随着软件行业的发展代码的量级越来越大功能越来越复杂再将编程视作数学问题将所有的代码以数学方式来证明变得不切实际编程由此而转为了科学问题。而科学问题的特性即是不可证明性与可证伪性。不可证明即我们无法证明这个程序完全正确永远不出问题。可证伪性表明我们可以通过一些特例来去验证我们的程序当这些特例通过时我们可以说暂时未发现问题但不能说程序绝对正确。当这些特例未能通过时那么我们就可以说这个程序绝对有问题。这样的一些特例即为软件测试的测试用例。
软件测试的意义对于软件开发来说是毋庸置疑的正如Robert C Martin在《The Clean Coder》中所言: I don’t think that surgeons should have to defend hand-washing, and I don’t think that programmers should have to defend TDD. 2. 测试方式
软件测试既有手动测试也有自动化测试手动测试相信每个开发人员都有做过这样的事我们常常写了一些功能然后在main函数这样的地方去直接调用我们写的功能这样的测试往往是一次性的随着开发的进行这些测试就会被抛弃。或者更进一步会有个功能回调的表然后我们手动来触发相应的功能来验证功能的正常。而自动测试借助一些测试框架来隔离业务代码和测试代码并且能够一次性测试多个用例测试代码和业务业务代码相应迭代演进。
自动化测试的意义在于快速、快捷、全面地进行软件测试。我们开发中应该尽量做到一键实现测试只有足够便捷才方便频繁地测试我们的代码。而且在开发过程中应当尽量精简测试当不涉及其他模块时我们仅需要验证当前开发模块编译和运行测试用例不超过10s这样我们可以在每分钟都运行一次测试用例直到模块开发完成。
3. 嵌入式软件测试
嵌入式软件也需要进行测试嵌入式软件开发人员部分是硬件开发人员兼职使用C语言来完成驱动开发。对于软件测试嵌入式行业尤其是mcu方面并未有足够的认识当然这也是嵌入式开发所独特开发方式和运行环境所致嵌入式开发通常都是需要跨平台编译也就是说开发平台和运行平台不同这也导致了依赖于硬件的IO会有所不同如果仅在开发平台上运行测试用例那无法避免地需要将设备驱动相关的部分打桩掉使得代码运行在设备无关的平台上。所以这种方式只能测试应用层的一些代码对于驱动部分的代码则无能为力。
在最近我们部门展开了一个新项目将原来的mcu平台迁移到arm64的CPU平台上运行linux内核的rtos系统。在mcu项目中就缺乏相应的测试手段仅能通过一些shell的方式来手动测试部分功能。缺乏自动化测试就使得开发时不能时常测试验证时也无法全面测试。所以最近在考虑搭建测试框架的问题原先的意思是需要一个系统测试框架在我看来单元测试反而更加急迫也更贴近于开发人员。不过最后决定系统测试和单元测试框架都做先实现较为基础的单元测试框架然后再整合单元测试框架和必要的系统模拟组件实现系统测试框架。
单元测试是对软件微颗粒级别的测试若被测试功能对其他模块或组件有所依赖那么最好将依赖的部分打桩掉以免其他模块的功能修改影响到本测试用例的检测也就是说功能的测试应该独立化不应有所依赖在面向对象的开发模式中模块和模块之间本就是解耦的程序的可测试性相当好然而在面向过程中往往模块之间会有直接的依赖使得程序的可测试性下降要么将业务代码解耦重构要么使用一些三方的打桩工具在运行时使用桩函数替换掉原有的接口。
系统测试更像模拟出一套运行系统出来来完整测试整个业务流程根据项目的特点来设计模拟器功能这和项目的业务强相关这里就不过多赘述。
上述的单元测试和系统测试仅在应用层使用在开发环境中使用高级的测试工具来完成自然不是问题。但我们还有一部分代码未受到测试用例覆盖那就是和硬件高度相关的驱动代码。在之前的一篇文章中提出嵌入式软件开发应该分层设计1在测试方面也应当进行分层测试。驱动抽象层及应用层代码应该在开发环境中使用高级测试框架实现。设备层代码应当使用运行环境使用一些轻量级的测试框架集成测试设备驱动代码这样就可以尽可能地覆盖更多的代码以提高测试覆盖率实现测试全面自动化测试。
4. 总结
软件作为科学问题呈现不可证明性和证伪性就表明了测试是永远不会停止测试会持续存在于软件的整个生命周期内即使再完善的测试用例覆盖和系统验证也无法保证软件在交付之后不会问题。受限于人的有限性无法在测试阶段就保证能覆盖所有场景运行时暴露出问题也可以进一步去完善我们的测试场景在接下来的回归验证中我们就可以覆盖更全面的场景。自动化测试的意义在于解决一些低效的测试手段让自动化实现在开发和验证的每一个时刻根据各自的需求实现不同测试范围的自动化测试。在嵌入式软件开发中有其特殊性即非常依赖于硬件功能使得测试情况变得复杂。不过使用测试分层是一个非常好的思路配合软件设计时的架构分层可以更好地解决嵌入式软件的架构问题。在有些嵌入开发中将设备层做成BSP包软件开发人员仅需要负责应用层代码开发在这种情况下BSP作为外部依赖业务层的开发人员应该对其做验收测试已判断外部依赖功能的有效性。 嵌入式软件架构-CSDN博客 ↩︎
