Testbed

关于Testbed项目基线怎么建立，以及Testbed基线更新后历史问题怎么对比，它的核心逻辑就是先把当前的代码质量状态给固定下来，然后再利用后续跑出来的报告，和它去进行差异方面的判断。在建立基线之前，配置需要先被稳定下来，明显无效的项也要被清理掉，并且版本信息要被写清楚；而在更新了基线以后，新增的问题、关闭的问题，还有持续遗留的问题，都需要被人员重点地区分开来。

Testbed覆盖率分析在实际操作时，不能简单当成去点击运行报告，因为覆盖率分析是动态验证里的一环，工具首先要针对代码进行插桩或者把测试环境准备好，接着靠着测试用例的运行结果，来算出来哪些语句、分支或者函数被执行到了；在LDRA工具链里面，结构覆盖分析能够看到语句、分支判定还有函数调用这些指标，TBrun也支持过程调用等内容，并且在生成的报告里，能把具体走到的语句和条件都显示出来。

在接口的调用一接进自动化测试以后，就不能再只靠着“能不能访问得通”这一条，去判断它到底安不安全了，testbed接口的调用，要怎么去验明正身，还有，当验明正身失败了，那本记着失败的日志，又该跑到哪里去翻，这通常是要从调用方的身份、接口的权限、令牌是不是还在有效期内、网关有没有在半道上把人给拦下来，还有服务端自己记的日志，这么好几条线索，搁在一块儿去瞅的，认证这码事，它主要就是为了去确认，跑来调用的到底是谁；而授权呢，它决定的是，这被确认了身份的家伙，都能去碰哪些资源，在接口那一类的系统里头，尤其要去躲开一种坑，就是只把登录时候的校验给做了，却松松散散地，把对权限的判断，给撂在了一边。

在单元测试、集成测试、回归测试，还有那种对安全要求特别严格的软件验证里面，testbed的测试数据要怎么去隔离开，还有，数据串着用了的问题，又要怎么去避免它，这一类的情况是会经常碰到的，拿跟它相关的那一套工具链来打个比方，测试的管理、执行出来的结果、覆盖率的统计，还有需求的追溯，这几样东西，是可以被放在同一套验证的流程里面，去统一管起来的，而且，它还会靠着分析代码的控制流和数据流，去把单元的接口、参数、全局变量，还有返回值这些信息，给摸清楚，可也正因为，数据能钻进来的入口实在是多，结果又是环环相扣的链条，所以，一旦测试的数据给混着用了，它就会去影响到对用例的判断、对覆盖率的解释，还有最后评审得出来的那个结论。

在LDRA的工作流里，单元测试失败不是只看一个红色结果就结束，真正要看的是失败到底落在测试向量、预期结果、桩代码、运行环境，还是覆盖与结果采集这一层。LDRA官方资料把这条链讲得很清楚，TBrun负责单元与集成测试的生成、执行和管理，TBvision负责把静态与动态分析结果、覆盖率和代码结构放回源码上下文里看，而整个LDRA tool suite又把测试结果、覆盖数据和需求追踪连在一起。也就是说，失败定位不能只盯一次执行结果，要顺着执行链往回看。

对于Testbed调用关系的查看，并不是只把一张图打开就可以了，更重要的是通过这种调用关系，来把各个函数之间的入口、出口以及依赖边界给看清楚。一般情况下，调用关系图是结合着静态分析的结果一起生成的，大家经常用它来理解模块的结构、对函数的依赖进行检查、还有把没测试到的调用路径找出来，另外对覆盖率分析和代码评审也能起到一些辅助作用。

在嵌入式C/C++项目中进行编码规范检查时，团队刚开始配置静态分析工具时常常会碰到两个具体问题，即如何在Testbed工具中导入MISRA规则，以及怎样把检测出的MISRA违规项按等级进行整理。这里面的核心并不是简单地把规则开关打开，而是要把规则版本、检查范围、编译环境以及结果分级这几个方面一起理顺。静态分析工具一般会依据这些类别来组织输出检查结果，这样后续的整改和审查工作就能更加方便。

测试设备一旦开始运转，真正让人头疼的往往不是某一次的结果，而是这些结果散落在日志、报表、脚本平台，还有人工记录的各种地方，testbed结果看板怎么搭建，还有看板上冒出来的指标异常该怎么去解释，核心都是要把测试的状态、执行的结果、设备被谁占着、异常到底是什么原因引起的，还有责任最后有没有闭环，这所有的东西，都给放到同一个观察视角里，让项目经理、测试人员，还有做开发的，都能一眼就看得懂当前的风险在哪里。

在测试台架这边，去安排固件的升级，还有升级完了以后，要是冒出来了兼容性方面的异常，又该拿什么去验证它，这件事，可不能光是盯着那个升级的按钮，看看它能不能点得下去就完了，一套测试的台架，它往往是连着控制器、各种板卡、仿真机、负责采集数据的模块、通信的设备，还有一整套自动化的脚本的，这固件稍微一动，跟在后头的驱动、模型、输入输出的映射关系、通信时候的时序，还有那些测试的用例，全都有可能被牵连到，所以，在安排升级的时候，要先去把涉及的范围给确认好，再去搞一轮小范围的验证，等确认了它已经稳下来了，然后，才能进到正式的台架里面去。

这里先把口径说清一下。按TestbedOS官方文档，这一块更准确的说法其实是test harness驱动的集成测试，而不是传统意义上只围绕单个函数做mock的单元测试。官方把test harness定义为用来测试testbed全部功能的integration tests，测试用例以kvm-compose.yaml和kvm-compose-config.json的形式组织，并通过asset testing与连通性测试去验证虚拟机、网桥和网络行为是否正确。所以如果你现在说的“单元测试回归”，放到TestbedOS场景里，更稳的理解其实是“基于test case的回归测试”和“变更后的自动重跑”。

很多嵌入式软件团队在刚开始用静态分析工具的时候，通常都会碰到两个头疼的问题，那就是Testbed编码规范检查怎么开启，以及Testbed编码规范检查结果怎么筛选；这里提到的Testbed软件，一般就是指LDRA Testbed和TBvision相关的工具环境。TBvision这个工具能够让操作人员在源代码的上下文里面去查看违反编码标准的地方，而且还能在这些违规项、源代码以及软件支持的编码标准之间，来回切换着进行查看。

在多人共用的测试台架上，权限的边界一旦没划清楚，就会直接影响到设备的预约、任务的执行、数据的查看，还有环境的维护，testbed的权限分组到底要怎么去划分，还有当权限被改过了以后，为什么它看起来好像还是没有生效，碰到这种事，可不能只是去瞅一眼，那个账号还能不能登得进去就算了，还得去看一看，角色、项目、资源池、执行的队列，还有缓存里的状态，这些东西，是不是都走到一块儿去了，权限要是设计得太粗糙了，那普普通通的测试人员，就有可能会不小心去改动了环境；可要是设计得太细碎了呢，项目真正跑起来的时候，又会被各种各样的申请流程，给死死地卡住，所以，这得照着真实使用时的场景，去把它给划分开。

在测试项目里面，去设置testbed这种设备的预约，还有当预约的时间撞了车，发生了冲突以后要怎么去协调，这件事说到底，其实就是在管一种挺稀缺的资源，不少团队里，像台架、仿真的环境、硬件的板卡、传感器，还有总线这些设备，数量都是很有限的，要是光靠着在群里面发消息，临时去约个时间，就很容易闹出两个人抢同一台设备、测试用的版本对不上、问题刚复现到一半就被人给打断了，这一类的情况，想让预约这件事真正落了地，关键就是要把设备的状态、能用的时间段、该由谁来负责，还有冲突了该怎么处理，这些规矩都给提前定得明明白白的。

在LDRA Testbed里处理静态分析误报，最容易走偏的地方，不是结果太多，而是把“规则本身不适用”“规则需要正式偏离”和“单条结果确实是误报”这三种情况混成一类去压掉。LDRA的公开资料已经把边界说得比较清楚，一方面，像MISRA这类标准里本来就存在部分undecidable规则，静态分析在信息不足时可能出现false-positive或false-negative；另一方面，LDRA工具链又明确支持项目级、团队级和个人级的violation exclusion，以及Deviation Records和Deviation Permits这类合规工件。也就是说，误报处理不是简单点一下忽略，而是先分类，再决定是调规则集、做偏离，还是做单条抑制。

这里先说明一下，以下内容是按官方文档中的TestbedOS来写的。官方把它定义为一个用于在抽象拓扑上启动虚拟机、支撑研究与测试的testbed平台，并且把安装、依赖、服务启动和集群运行拆成了完整文档。也正因为这样，安装问题通常不是“软件本体坏了”，而是依赖链、运行权限和配置文件没有接顺。

Testbed报告不是把扫描结果导出来就完事了，评审人员真正看的不单单是有没有违规项、覆盖率是多少，他们还会看这份报告能不能把问题来源、分析范围、规则口径和处理结论都说明白，所以我们在调整报告模板的时候，重点应该放在“证据能不能复查”上面，而不是只把版式做得更整齐，毕竟LDRA工具链本身就覆盖了静态分析、动态分析、单元测试和需求追踪这些内容，而Testbed与TBvision也都是用来进行静态、动态分析以及查看标准符合性结果的。

在完成软件的静态分析以及覆盖率测试工作之后，研究人员通常需要对质量度量结果进行分析。在实际工作中，开发人员可以使用LDRA工具链里面的Testbed和TBvision软件来做静态和动态分析，这些软件能够输出关于质量度量、代码覆盖情况以及标准符合情况的各种图表；同时，TBvision软件还可以计算代码的复杂程度、循环嵌套的层数、函数的数量等各项数据，并把这些数据和提前设置好的合格标准进行对比。

关于“Testbed静态分析怎么配置，Testbed静态分析规则误报怎么处理“，这两个问题不能只看怎么点按钮。Testbed这类静态分析工具，重点是让工具尽量还原项目真实的编译环境，再用合适的规则去检查代码。LDRA工具链本身面向软件质量、标准符合性和自动化验证等场景，静态分析通常会检查代码是否符合选定的编码标准，并在报告中标出不符合项。

在静态分析、动态测试、单元测试，还有回归测试扎堆执行的时候，有一类问题是挺常见的，就是testbed的执行队列要从哪里去看，还有，一旦队列给堵住了，又该先从哪里下手去查，这testbed一旦接上了批量跑的任务，或者是接进了流水线，那队列的状态，就会直接影响到测试的效率，还有报告能不能按时出得来，拿LDRA Testbed这类工具来打个比方，它可以把测试的执行、覆盖率的结果，还有需求的追踪，结合到一块儿去，生成审计要用的材料，而动态测试呢，还有可能牵扯到，在宿主机和真实目标机这两种环境底下，去执行，再把覆盖到的数据给收回来。

在测试台架、自动化验证环境，还有嵌入式联调环境里面，有一类问题是挺常见的，就是testbed环境的镜像，要怎么才能快速地把它给还原回去，还有，当镜像被还原了以后，发现缺了依赖，又该拿什么东西去把它给补齐，testbed这套环境，一旦被那些驱动、工具链、脚本库，还有许可证的组件给搞乱了，再想靠人工去一项一项地修回来，通常是要搭进去很多时间的，所以，镜像还原这件事，得要提前去把快照、版本、依赖的清单，还有验证的脚本，都给规划好了，镜像这个东西，它是能把系统给拉回到一个基准的状态上去，可它自己，是没办法去解决掉，所有跟外部依赖有关的那些麻烦的，尤其是像网络上的源、硬件的驱动、许可证的服务、环境变量，还有私有包的地址这些，往往在还原完了以后，还得再去重新补齐一遍。