什么是单元测试?
“单元测试”通常又被称为“白盒测试”,这些概念虽然在测试对象和方法的定义上,业内可能存在略有差异的理解方式,但它们并没有本质的区别。单元测试,就是对软件中最小可测单元或单元之间的逻辑关系所做的测试和验证。比如对C/C++代码中的一个函数、类或是少数函数组成的一个集合,抑或是一个小的功能模块的测试,通常都可以归为单元测试的范畴。
单元测试通过为被测单元设计输入参数,并验证其执行后的输出值、关联值或执行过程来验证被测对象的坚固性(鲁棒性)和正确性。坚固性取决于被测单元在各种类型或极端输入条件下运行正常与否;正确性则是通过判定代码的运行逻辑是否符合原本的设计需求来验证。单元测试的效果依赖于测试用例,也就是外部输入参数是否合理、充分,而这些输入参数主要需要测试人员根据被测单元的业务逻辑需求来设计,所以并不存在万能的“银子弹”代替所有单元测试的工作。
• 对单个函数的单元测试。根据函数的设计需求,来设计输入值、桩函数和全局变量等相关的外部输入条件,在测试执行完成后判定实际的输出值是否符合预定的期望值,以此作为单元测试用例通过与否的依据。如下图所示:
• 对多个单元的测试,也可以理解为单元之间的集成测试,因为其测试对象仍然集中于底层函数级别,也是单元测试工作中常见的测试场景。对多个单元的测试可以验证多个单元连续调用执行之后的输出值,也可以用来测试多个单元之间的相互依赖逻辑。
为什么要做单元测试?
因为传统的系统功能测试(又称“黑盒测试”),由于系统集成后的复杂性,在有限的时间内无法充分地对软件内部的分支、模块及模块之间的错误进行检测,并且由于系统测试阶段的bug所需的修复成本往往较高,所以对于要求高可靠性和安全性的系统,软件的测试需要“左移”到项目研发的更早期,对底层的代码行、函数、类、子模块进行验证,以实现对软件更早、更彻底地测试。另外,由于早期bug的修复相对容易,项目整体研发成本也得以降低 – 这也就是单元测试初衷。
换言之,单元测试的目的就是为了在系统集成之前根据下层需求测试函数或子模块的bug,以减轻后期系统集成测试的压力,最终实现对软件更彻底地测试,提高质量并降低成本。
殊途同归,关于功能安全ASIL, SIL认证标准,如ISO 26262, IEC 61508, EN 50128, IEC 62304, 或是GJB-5000A等标准明确要求了软件的研发过程中需要进行单元测试,其出发点也正是为了通过强制要求更底层的测试以规避测试不充分可能导致的安全风险,保证汽车、工业、轨道交通、医疗器械和国防军工等各类事故容忍度极低的系统的安全可靠。
难点和挑战
单元测试耗时耗力。准备测试环境、编写驱动代码、设计测试用例、执行结果判定、测试用例的管理、回归和覆盖率分析等每一步都需要繁琐的工作,对于一个包含几百甚至几千乃至上万个函数单元的工程来说,人工方式严格完成单元测试所需要的工作量不亚于整个软件的开发工作
下层需求文档和测试经验的缺失形成了单元测试实施的门槛。函数级的设计需求文档不足或不规范的情况,在历史遗留项目中是非常常见的,单元测试全凭少数的测试人员通过解读代码来进行会造成测试工作举步维艰
嵌入式软件的单元测试因为关系到交叉编译过程,以及对目标机的兼容,准备测试环境和执行测试用例会更加困难
海量的单元测试用例库的变更分析、回归执行和复用,对测试用例的管理方式有很高的要求
单元测试的覆盖率统计几乎不可能通过人工方式完成
解决方案
使用VectorCAST自动生成的单元测试环境,原生态支持绝大部分主流上位机环境编译器和嵌入式交叉编译器,避免对代码大幅修改或重构、甚至为了测试变更编译器
VectorCAST支持业界领先的智能、自动地批量生成单元测试用例,通常可达50%-80%甚至更高的测试覆盖率
自动解析代码结构,提供便捷、多样化的图形化测试设计平台,极大简化单元测试用例设计工作
有机管理单元测试用例,让测试用例的协作、维护和复用变得非常容易
VectorCAST提供丰富的第三方集成,无缝集成开发过程上下游的研发工具链和管理平台,如需求管理、持续集成、模型开发和静态分析工具等
真正的嵌入式的单元测试,测试用例无缝集成到嵌入式目标板或模拟器上运行
多种报告形式,满足单元测试不同的使用场景和第三方认证审计需求
相关资源
白皮书
博客
新闻资讯
修复和预防Bug的成本量化对比_白皮书
点击下载
如何评估嵌入式软件测试工具_白皮书
点击下载
如何开发高质量的软件_白皮书
点击下载
利用Wind River VxWorks7实现自动化软件测试_白皮书
点击下载
基于变更的测试_白皮书
点击下载
故障注入和多维度白盒测试_白皮书
点击下载
2015软件测试技术报告_白皮书
点击下载
如何满足IEC 61508-3 2010标准相关的软件验证和确认要求_白皮书
点击下载
RELATED RESOURCES
下载申请