通过这件事,我逐渐明白了软件工程师和程序

目录

背景介绍

发现问题

问题描述

问题确认

解决问题

反思总结

自身问题

外部干扰

改进措施

背景介绍

前段时间,我司产品的硬件平台更新了CPU和flash,底层软件平台紧接着发布了适配新硬件平台的SDK包。为保证产品各项功能不受影响,软件开发团队将迁移到新平台的软件的各项功能重新测试一遍。

在测试过程中,我所负责的GPS定位功能出现了问题。今天这边文章就是讲述我解决GPS问题的心路历程,并由此引发的关于工程师和程序员的思考。

发现问题问题描述

在测试新产品的GPS功能时,我将新硬件拿到外界环境进行测试,并通过CANoe实时读取经纬度。在测试结束分析log时,我发现CANoe读取的经纬度会发生抖动,即经纬度从非0值跳变为0值。

起初,我并未将其当做问题放在心上,简单的认为是测试环境不好而影响GPS定位(测试地点在阳台,测试上方有屋檐,测试环境属于弱场环境)。

但随着测试增多,我发现该问题属于必现的问题。于是,我做了以下测试:

排查测试环境是否有问题

测试方法:拿旧硬件和新硬件放在同一地点,同时进行测试。

测试结果:发现旧硬件的GPS定位效果非常稳定,而新硬件的GPS定位效果仍会出现了抖动。

排查新硬件是否出现单件问题,即是否只有这块新硬件有问题

测试方法:拿三块新硬件放在同一地点,先后进行测试

测试结果:发现三块新硬件均出现GPS定位效果抖动的情况。

问题确认

上述测试结束后,我确认新硬件的GPS定位的确出现了问题。由于该产品分为底层硬件、底层软件平台和应用层软件,而我负责的应用层软件的代码没有做过任何改动,所以该问题是由底层硬件或者底层软件平台出现bug导致的。

此外,我司提供产品是整车唯一提供GPS定位的ECU。OEM厂商对于我司产品的ECU的GPS定位功能要求非常严格。此时,我意识到该问题的严重等级非常高,为保证产品不会被该问题block住。

我写邮件通知项目PTM,让他知晓该问题并协调和推动相关团队去定位解决该问题。

解决问题

底层软件平台也分为两个部分,一部分是供应商提供的linux内核和各种驱动,另一部分是我司德国团队对供应商提供的软件进行二次封装的中间层软件。

我给德国团队提交了GPS定位抖动的bug,并提供了测试log。接下来就是等待国外团队的回复,外企工作的朋友可能明白国外团队龟速般的相应速度,很漫长...

经过了将近一周的等待,我收到德国团队的回复说GPS天线的硬件增益过大,达到了-12db的极限值。

接下来,我把目光转向了硬件,却非常担心硬件真的出现问题,因为硬件出问题那么上层软件均需要做修改适配,波及范围会非常广。

我向硬件团队咨询了新旧硬件是否更改了GPS天线的设计和型号,并得到他们未做任何修改的肯定答复。此时,我松了一口气,但却疑惑问题到底在哪里。

为了彻底排除硬件问题,我和硬件同事一起做了传导测试,并未发现任何异常,硬件问题排除。

没办法,我又把目光转向了软件,毕竟还没有排除供应商软件是否有问题。我了解到GPS功能隶属于modem模块,而modem模块的软件是由供应商提供。

接着,我与供应商开会讨论GPS的问题。他们建议我做ABA测试,说白了就是将新旧硬件的天线互换进行测试,接着再将天线换回来再进行测试。在做这个测试时,我犯了无法挽回的错误导致了后来的尴尬情况。

我犯的错就是没有将出现问题的新硬件保存起来,团队的新硬件都不同程度的做过改动。在做过ABA测试后,我再用新硬件测试GPS问题时,问题就变成了偶发,但还好复现概率比较高,但这也造成了无法知晓之前GPS抖动必现的原因。

供应商分析完测试log后,结论是测试环境属于弱场环境,信号不好。他们建议修改/etc目录下的gps.conf文件一个配置项,保证GPS在弱场环境下也能上报GPS数据。

但我发现新硬件中没有gps.conf文件,因此GPS定位出现抖动大概率是由于缺少gps.conf文件导致的问题。我给德国团队发邮件询问为何没有gps.conf文件,并建议添加上该文件以改善GPS的定位性能。

反思总结

这个问题从年12月10号就上报给项目组,但直到年2月5日才解决,历时将近2个月。

为了解决该问题,软件开发团队、测试团队、硬件团队、底层平台团队和供应商全部参与分析排查。事情虽然得到了解决,但回想起来还是有很多没做好的地方。

在修改新硬件之前,为何测试概率是必现,而修改硬件后测试概率变为偶发

排查问题过程中,没有保留最初有问题的新硬件

测试过程中没有做表格追踪每次的测试结果,每次都是单独抓取log

没有保存好每次的测试log,这导致后期查看log时遇到了很多困难

GPS定位抖动的问题是我工作三年来遇到的最困难的问题,但也是给我带来了最多思考的问题。从这次的事情中,我理解了软件工程师和程序员的区别。

程序员是根据需求进行功能设计,并完成相关编码,解决bug,保证软件功能正常和质量稳定。

软件工程师除了完成程序员的工作外,当遇到问题时还需要使用工程化的思维进行分析和解决。

软件开发工程师的眼中不能只有自己开发的软件,他要使用工程化的思维来对待自己的产品。

就拿GPS定位抖动的问题来说,应用层软件的代码没有任何改动,我完全可以甩锅说和我没关系。但这个问题是我测试出来的,作为一名软件开发工程师,我的职责就是发现问题并解决问题,所以我积极与德国团队、硬件团队、高通和供应商共同解决这个问题。

自身问题

经过这次的事情,我发现了自身存在以下问题:

工程化思维比较弱。此前一直认为自己是程序员,目光全部放在了软件开发上

没有跟踪记录的习惯。为解决这个问题,我做了很多很多测试,但我从未使用任何工具跟踪记录自己的测试过程和分析结果,这导致我每次都需要花费时间翻看邮件

测试log保存不齐全。我做了测试后,仅保存了当时需要的log,没有把所有工具记录的log保存下来,这导致后期分析问题时遇到严重的阻碍

没有保存问题硬件。这是我犯的最大的低级错误,导致后期测试时遇到了极大的困难

外部干扰

这个问题之所以花费将近两个月的时间,很大一部分原因是由于参与团队太多,在沟通时会花费大量时间。另一部分原因是各团队都认为自己没有问题,彼此间互相甩锅,反而让我这没问题的人沟通协调各团队。

改进措施

对于外部干扰,我没法左右,这应该是职场的正常现象,坦然接受就好。

就个人来说,我打算从以下几个方面来改善:

以后出现非应用层软件问题,我要把出问题的硬件和软件保留起来,并详细记录问题的现象和结果,便于以后分析

每次测试复现问题时,使用excel跟踪记录每次的测试结果和测试log

在测试之前,制定测试计划,并找leader复审测试计划是否严谨,之后严格按照测试计划执行和记录

结语:没有哪一段经历是白费的,只要用心去感受则一定能够从中汲取到成长的养分。

ps:欢迎


转载请注明:http://www.jiaju1314.com/xxzl/xxzl/14527.html

  • 上一篇文章:
  •   
  • 下一篇文章: 没有了