嵌入式——测试活动过程中遇到的问题

项目背景：机器人项目的主控系统——嵌入式

迭代背景：敏捷开发

记录方向：测试活动中遇到的问题

记录时间：长期更新

===================================================

好久没有更新发牢骚了。最近很有感慨，感觉必须的写下来，不然真的就无处发泄；

先定义好整个测试活动过程：测试从参与阶段开始：需求评审、详设评审、设计、测试环境部署、提测、版本管理、测试、bug跟踪、软件部署、团队的质量意识提升等各个环节；

1、嵌入式软件包部署过程中遗忘更新动态链接库；

1.1、现阶段嵌入式软件-主控程序部署流程（不包含算法-导航、定位、路径规划等的部署）：

 

1.1.1、通过个人的编辑环境编译生成可执行文件，然后打包成deb包；

1.1.2、在实体机器人上安装部署deb包（需要单独手工复制开机脚本）

1.1.3、手工配置相关的配置文件（配置文件也是从deb包解压出来的，有些需要动态配置的文件需要个性化处理）

1.1.4、从公共测试用例库中执行冒烟测试；

 

1.2、整个部署流程中全靠“人工“智能，如果存在相应的动态依赖库，还需要手动将动态依赖库复制到实体机器人上；

 备注：后续会规范整个编译、打包、部署流程，在工控机上实现docker容器化的部署方式；

2、嵌入式软件测试环境版本控制问题，在及时的提测过程中，经常出现版本问题导致资源浪费严重；

 2.1、嵌入式软件测试环境组成部分

主要有以下基本部分组成

2.1.1、嵌入式软件：即机器人主控部分，内部分为多个节点，每个节点单独为一个功能块，一个功能块为一个代码仓库，每个功能块都要进行单独编辑生成可执行文件；

这种情况就会触发编译过程繁琐，提测时间浪费；促使了后期的节点合并的发生；

2.1.2、算法部分：导航、定位、路径规划、视觉、避障等模块，各个模块的部署还不一样，一些为可以执行文件的方式部署，一些为二进制的形式；

2.1.3、硬件版本：机器人的硬件部分迭代过快，很多时候嵌入式软件和硬件是有相互依赖关系的；如超声波驱动、电池、电机、驱动轮等各自相互依赖；硬件版本一变化就需要软件变化，时常导致软硬版本不匹配的问题发生；

2.1.4、app板块：主要分为联网部分、离线部分。联网部分是与云平台交互部分；离线部分是直接控制机器人部分；

2.1.5、web云平台：主要分为dev、sit、uat、prod，服务器资源有限，各个环境出现共用部分资源：如mqtt broker、存储资源、存储方式；该平台为机器人的调度平台，是与机器人有强相关的关系，版本不匹配、协议不匹配、代码未更新等问题；

2.1.5、IO板：主要有三部分：机器人的IO板、呼梯的梯控板子、工作站的IO板；由于IO板子的程序是需要烧录在主板上的，需要借助相应的烧录工具如IDE等工具；板子程序更新全靠人为进行更新，板子程序更新不及时、不同机器人上板子程序版本不一致；

2.2、版本控制不力出现的问题

2.2.1、版本不匹配，出现各种奇葩问题；

2.2.2、各个测试团队：嵌入式测试、产品测试、硬件测试版本不一致，没有完整的工作流，导致已经解决的问题在另外的测试环境中出现，bug重复；产生很多无效bug，测试资源的浪费；

2.2.3、嵌入式开发团队各种救火，测试环境问题、版本不匹配问题，开发人员到处排查问题，排查半小时无果，结果后面发现版本不匹配导致，开发资源浪费严重，导致每次迭代结束开发任务部分未完成或者潦草提测，各种肉眼可以的问题出现，提测质量不高，对整体的项目进度推进贡献不大；

2.2.4、各个组成部分步调不协调，内耗严重，测试出现问题总是踢皮球，经常出现bug滞留处理时间长期后延；

2.3、解决措施：

2.3.1、发起跨部门的版本控制会议，联合各个部门公共进行测试环境版本控制；

2.3.2、制作整体的版本控制表大致如下：

 

 希望每个部分内部有自己的版本控制体系，对外只需要提供响应的release版本即可；

2.4、版本控制结果现状

2.4.1、很遗憾的是，尽管版本控制会议发起过多次，也宣贯过版本控制的重要性，并未取到实质性的进步，版本控制不力的问题依旧如此，整体进度推进不佳；尽管算法部分根据会议要求对外提供了部署包或者二进制文件，

但是自身版本老旧，而且还需要进行每台机器的单独调试。例如机器人与工作站对接流程中就需要进行各种config文件配置，调试。按照部署文件部署后无法跑通冒烟测试；

2.4.2、退而求其次，只能选择把嵌入式软件内部版本管理起来。从开发规范、git版本规范、版本管理、提测、部署等方面入手；

2.4.3、测试人员只进行嵌入式软件部署，算法部分由开发人员部署，硬件部分只能在进行部署前找硬件人员确认是否对嵌入式软件有相应的依赖；IO板的程序由相应的开发人员烧录；

2.4.4、真的很遗憾，作为一个纯软件测试人员，工作了6、7后，对嵌入式的测试环境版本控制束手无策，也只能私底下发发牢骚。

 

3、在测试新建地图过程中，发现建图过大时就会出现画面变化迟缓，突然变化巨大，且机器人实时位置跨越式跳跃；

3.1、出现背景，建图大小操作100M时，建图画面开始迟缓，机器人实时位置跨越式跳跃；

3.2、原因分析：

a、建图传输协议，采用的是rtsp流媒体传输协议，底层为UDP协议；

b、当地图很小的时候不会出现这种情况，地图很大时就会出现这种情况，通过抓包1帧/s，1帧的大小为5/6百kb，每一帧数据在传输的时候被分为60包数据进行传输，app端在接收到数据时会rtsp底层会进行响应的校验；

一旦出现60包数据中某一包数据丢失，app的处理逻辑为将这60包数据丢弃即这1帧数据就会被丢失，导致了画面变化迟缓；

c、通过抓包测试，机器人上使用的是4G路由器的方式 ，外网连接的下载速度为200kb/s，有时候峰值可以达到1、2M/s；

3.3、什么是帧

a、帧的定义（来自于百科）

量词，一幅字画叫一帧。

网络上的帧　数据在网络上是以很小的称为帧（Frame）的单位传输的，帧由几部分组成，不同的部分执行不同的功能。帧通过特定的称为网络驱动程序的软件进行成型，然后通过网卡发送到网线上，通过网线到达它们的目的机器，在目的机器的一端执行相反的过程。接收端机器的以太网卡捕获到这些帧，并告诉操作系统帧已到达，然后对其进行存储。就是在这个传输和接收的过程中，嗅探器会带来安全方面的问题 。

数据帧　Frame，数据链路层的协议数据（protocol data unit）单元。数据链路层的主要职责是控制相邻系统之间的物理链路，它在传送“比特”信息的基础上，在相邻节点间保证可靠的数据通信。为了保证数据的可靠传输，把用户数据封装成帧。

FLASH　帧——就是影像动画中最小单位的单幅影像画面，相当于电影胶片上的每一格镜头。

关键帧——任何动画要表现运动或变化，至少前后要给出两个不同的关键状态，而中间状态的变化和衔接电脑可以自动完成，FLASH中，表示关键状态的帧叫做关键帧。

过渡帧——在两个关键帧之间，电脑自动完成过渡画面的帧叫做过渡帧。 [

b、帧的分类

帧分为关键帧和过渡帧。

两个关键帧的中间可以没有过渡帧（如逐帧动画），但过渡帧前后肯定有关键帧，因为过渡帧附属于关键帧；

关键帧可以修改该帧的内容，但过渡帧无法修改该帧内容。

关键帧中可以包含形状、剪辑、组等多种类型的元素或诸多元素，但过渡帧中对象只能是剪辑（影片剪辑、图形剪辑、按钮）或独立形状。

影片是由一张张连续的图片组成的，每幅图片就是一帧，PAL制式每秒钟25帧，NTSC制式每秒钟30帧。

 

4、在测试机器人补给流程中，经常出现机器人与工作站对接、补给不成功的情况，从日志中可以看到机器人与工作站的连接心跳断开。

4.1、原因分析

初步分析原因为工作站IO板死机，导致连接心跳断开，但是通过观察工作站IO上的工作灯还在闪烁；

通过tcpdump抓包工具，将机器人与IO板的连接通讯信息拦截并写入文件，持续跟踪分析该问题。

4.2、TCPDUMP工具

tcpdump工具有许多参数可以使用来帮助我们对拦截到的信息进行有效的筛选和过滤。以下的tcpdump命令包含了我们日常所使用的参数。该段指令是我在网上大神的博文中复制过来的，嘿嘿！

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

 (1)tcp: ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第一个参数的位置，用来过滤数据报的类型
(2)-i eth1 : 只抓经过接口eth1的包
(3)-t : 不显示时间戳
(4)-s 0 : 抓取数据包时默认抓取长度为68字节。加上-S 0 后可以抓到完整的数据包
(5)-c 100 : 只抓取100个数据包
(6)dst port ! 22 : 不抓取目标端口是22的数据包
(7)src net 192.168.1.0/24 : 数据包的源网络地址为192.168.1.0/24
(8)-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析

5、机器人充电流程中，机器人实际上已经在充电，工作站电池已经亮起充电信号灯，但上层应用查询出来的机器人的状态为未充电，过一会儿再次查询显示充电中？

5.1、原因分析：

主控节点主动查询工作站IO板的时间间隔为20s间隔；

6、SIT、UAT环境的维护问题

SIT主要使用于测试环境；

UAT主要使用于验收环境，起的作用为预发布发布环境，在SIT测试通过后将程序部署在UAT环境中，验收通过后即可部署在UAT环境；在项目组的实际应用过程中从代码管理及CICD的过程中版本管理按照相关的流程进行管理，但是缺少了一个管理环节：在整个软件生命周期前、中、后期在各个环境中部署通用的第三方组件流程的管控，运维工程师在UAT环境直接搭建新的应用导致mq服务启动不了，直接影响整个团队（开发、测试）无法进行后续的调试工作，持续时间半天。

管控策略：任何待验证的开发任务（基础框架、业务代码、部署第三方组件）应该 把风险降低到个人，任务delay只会影响到自身，不会因为自身的原因将风险平移到整个团队；

管控措施：严格规范CICD的过程及环境部署的流程，对应的环境不能随意进行操作；