Tessy嵌入式C单元测试：边界用例与覆盖率实战

简介这份PDF白皮书围绕Tessy单元测试与分类树方法展开面向嵌入式软件测试人员、开发工程师及需要提升单元测试规范性的技术团队重点回应如何系统设计测试用例、执行单元测试并改善软件质量。压缩包仅含1个PDF文件大小约1.87MB便于下载后直接查阅。内容从单元测试在IEC 61508、ISO 26262、Automotive SPICE、IEC 62304等标准中的要求切入结合TESSY工具示例说明被测单元、接口、初始用例、测试执行、故障排查与回归测试流程并逐步讲解分类树方法的测试相关方面识别、分类、重复分类及组合表用例指定配有示例与工具支持说明。已有4876人学习下载适合希望把单元测试从概念落到用例设计与自动化执行的读者参考。1. 从一条边界用例翻车说起Tessy 单元测试能补上什么某嵌入式项目里有个区间判断函数集成测试跑了几轮都正常现场却偶发把上界值当成区间内。回头补一条单元测试用例start5,len2,value7预期返回 0实际返回 1问题当场暴露。Tessy 单元测试就是干这个的围绕 C 函数自动识别接口、组织用例、驱动执行、回收覆盖率并生成报告把这类边界错误按在软件测试的最底层也让软件质量不再只靠集成测试兜底。它适合写嵌入式 C、要过功能安全标准、被集成测试拖慢回归节奏的团队。后面按测试对象、两种执行方式、分类树用例设计、避坑和覆盖率基线拆开讲力求照着能复现。2. 单元测试与模块测试在安全标准里把测试对象定准2.1 unit 和 module 在 C 语言里为什么最后都落到函数安全相关嵌入式软件的标准里模块测试和单元测试经常混着出现。IEC 61508 用 module testingISO 26262 用 unit testingAutomotive SPICE 说 software unitIEC 62304 在 5.5 要求 Software Unit Implementation and VerificationDIN EN 50128 把最低层软件组件叫 moduleISO 13849 的 V 模型也要求模块测试DO-178 则盯低层需求和软件组件验证。术语不同落到 C 语言测试对象基本都是一个函数。ISO 26262 对 unit 的定义是“atomic level software component … that can be subjected to stand-alone testing”翻成工程话就是能单独拉出来测的最小软件组件。IEC 61508 对 module 的定义是“construct that consists of procedures and/or data declarations …”一个 module 里可能有好几个函数但实际项目里最常见还是一个函数对应一个 module。为了避免和 C 的源文件 module 混淆后面统一说 unit指 C 函数。这个定义看着像咬文嚼字实际影响测试边界。比如一个函数只做数值转换入参和返回值都在寄存器/栈上隔离成本低另一个函数读写全局状态、调外设驱动、依赖中断硬把它当 unit 测stub 工作量可能比函数本身还大。我一般会先看函数的接口复杂度纯计算函数优先做单元测试带硬件副作用和全局状态的函数先拆接口再测。标准要求的是验证单元按规格工作不是让测试工具去硬啃一个耦合怪。注意标准里写“模块测试”不等于只能测整个 .c 文件。C 语言里把函数作为 unit 是通行做法前提是接口清单列全全局变量和被调函数都算进广义接口。2.2 接口清单黑盒测试的输入、输出和被调函数单元测试按接口规格做黑盒测试不依赖函数内部结构。接口不只是形参函数读取的变量是输入写入的变量是输出返回值算结果被调函数在广义上也属于接口。一个变量可以同时是输入和输出比如自增计数器。测试用例的结构就是“给输入变量一组具体值断言输出变量和返回值等于预期”。以区间判断函数为例接口表可以这样列变量/元素方向类型约束边界关注点start输入int任意整数负值、0、正值len输入int规格要求 len00、1、大于1、负数非法value输入int任意整数小于 start、等于 start、区间内、等于 startlen、大于上界返回值输出int1 在区间0 不在两个分支都要有预期被调函数广义接口函数按规格返回/写状态正常返回、错误码、副作用Tessy 用源码自动识别接口形参、全局变量、返回值一般都能扫出来。自动识别之后必须人工核对三件事全局变量有没有漏指针参数指向的缓冲区长度按谁算宏和条件编译有没有把接口改掉。指针参数尤其容易翻车工具看到的是指针地址测试数据要按指针指向的类型和长度准备否则用例看着执行了实际只覆盖到前几个字节。接口表不是给工具看的摆设它决定用例设计的上限。输入变量列不全分类树就少一个维度输出断言写少了函数改坏也发现不了。我习惯把接口表贴在测试工程目录里后面加用例、改 stub、做回归都拿它对一遍省得三周后自己都忘了某个全局变量是干嘛的。2.3 什么时候值得做复杂度、调用频次、安全关键三条筛选线单元测试能降低测试复杂度把整个应用里的一小块功能单独拎出来验证也能检查错误敏感输入不只测“正常值”。但它不是所有函数都值得同等投入。白皮书里提到用 McCabe 圈复杂度筛函数我一般再加两条调用频次和安全等级。三条线一起过优先级基本就清楚了。筛选线观察指标建议动作复杂度McCabe 圈复杂度高、分支多、嵌套深优先做单元测试用例按分支和条件组合展开调用频次被多个模块调用、在中断/周期任务里频繁执行优先做回归频率也高安全关键属于安全相关单元、标准要求 SIL/ASIL 对应覆盖必须做覆盖率目标按等级定接口纯度纯计算、少全局状态、少硬件依赖适合做隔离成本低时序交互单元间时序、中断与主循环交互单元测试单独做不完交给集成测试复杂度高但接口很脏的函数常见做法是先重构再测不然 stub 会写成另一个小系统。调用频次高的函数哪怕逻辑简单也值得测因为一旦错了影响面大。安全关键单元没什么好商量的标准要求单元测试和覆盖率省这一步后面审计还得补。单元测试也有边界。它验证不了单元之间的时序交互比如两个任务通过队列传递数据的时序、中断和主循环的竞态这些归集成测试。把单元测试当万能药最后会得到一堆绿色用例和一个仍然偶发死机的系统。筛选的目的不是少测是把测试资源放在能最早暴露缺陷的地方。2.4 谁写用例谁执行分工的现实折中开发者不适合测自己的代码这一点在单元测试里尤其明显。规格要求的功能如果开发者压根没实现他设计用例时也很难想到去测这个缺失功能异常输入、错误处理、边界条件自己写代码时容易顺着自己的实现思路走。外部测试人员来测也有问题大部分时间花在熟悉接口上得搞清楚“绿色”这种抽象输入怎么变成具体 RGB 值还得判断结果变量对不对。折中做法是测试人员按规格写抽象用例和预期结果开发者把抽象值转成具体值并执行。比如测试人员写“输入颜色绿色预期输出亮度等级2”开发者知道绿色对应 RGB(0,255,0)把它填进 Tessy 用例执行。用例失败开发者当场能查实现改完再跑。这个分工把“用例设计基于规格”和“执行基于实现知识”拆开了比让开发者凭空想用例靠谱。交接字段测试人员填开发者填用例 IDUT_RANGE_001不改规格来源需求条目/接口文档核对实现输入抽象值上界值、区间内值具体 start/len/value预期输出返回 0/1、错误码核对断言执行结果不填通过/失败/阻塞缺陷链接不填缺陷单号很多标准要求开发和测试组织分离这种“测试人员设计、开发者执行”的做法不完全满足分离要求实践中也不多见。但它至少把用例设计的规格视角保住了比开发者自己写自己测强。团队小的时候我一般会让另一个人做用例评审哪怕不独立成组也能把“漏实现的功能没人测”这个坑填掉一半。3. 用 Tessy 跑通区间判断单元original-binary 与 test-application 怎么选3.1 被测单元与那个必现的边界错误原始资料里的示例是一个整数区间判断函数给定起点 start 和长度 len判断 value 是否落在start value startlen内只看整数。C 实现常见写法如下/* 判断整数值是否落在 [start, startlen) 区间内 * start: 区间起点 * len: 区间长度规格要求 len 0 * value: 待判断的整数 * 返回: 1 在区间内0 不在区间内 */ int range_contains(int start, int len, int value) { if (value start value (start len)) { /* 边界错误应为 */ return 1; } return 0; }逻辑说明函数有两个分支比较value和区间上下界。错误在第二个比较用了当value start len时会被误判为在区间内。参数说明start和value可以是任意整数len按规格必须大于 0长度非法时函数没有错误码这本身就是接口设计缺口测试时要单独标出来。用start5, len2, value7执行预期返回 0实际返回 1。这个用例不需要跑整个系统也不需要等某个业务流程触发单元测试几秒钟就能暴露。后面所有操作都围绕这个函数展开换成自己的被测函数时接口表和预期值照同样方式替换。3.2 两种执行路径原二进制测试与测试应用测试单元测试有两种常见执行方式。原二进制测试用完整应用编译、链接、烧录都按最终产品来调试器在函数入口下断点应用跑到断点后喂输入数据单步或继续执行到函数结束读输出变量。测试应用测试只把被测单元从原应用里拿出来配一个测试用 main 和启动代码被调函数用 stub 替代编成一个专门的可执行测试应用。| 维度本文还有配套的精品资源点击获取