先说一下我自己吧,到目前为止已经工作5年了,目前在一家规模可以的公司中任职,我来这家公司之前是做qt桌面应用的,为了以后不被淘汰,我觉得应该深挖底层

所以到了这家公司维护qt底层库,我觉得这是一个不错的工作,因为我可以远离无聊的业务代码和业务需求,转而去学习一下底层库代码

       不过现在我遇到了问题,公司的应用是用qt开发的,但是出了崩溃、闪退问题,他们看看堆栈,发现是崩溃在Qt库里面就直接把bug转过来了,刚开始我还有精力看一下

但是推给我的问题越来越多,问题堆积的越来越多,导致我很难静下心去研究每个问题

        更难受的是,有的问题排查到最后其实就是业务代码的问题,我两三天找到问题的根源,和应用同步一下,人家半天就改完了,我也只算参与排查,不能算是修改

除了崩溃、闪退这种极端的问题,还有一些功能性的问题,应用实现的功能有问题,也会转到我这里,这都极大的浪费了我的精力

我自己最近复盘了一下,得出了以下结论

            1. 我的这个岗位可能就是干这个活的,我以前所在的公司都没有维护qt库的岗位,
               这家公司有这个岗位,那么默认应用只管使用qt,qt有问题就找我,我也应该解决(有点PUA自己了哈)

            2. 应用那边就是偷懒,不愿意尽力去排查,毕竟每个人都愿意省事

            3. 我现在也没有很好的方法去判断应用推给我的问题是不是qt底层库的问题(我大概率认为不是qt库的问题,qt不能这么烂)
            我没有明确的证据也不好推回去

分析完之后,我发现我自己也就能把第三点完善一下,公司和其他同事,我也不能去要求什么,所以我梳理了一个排查步骤

崩溃、闪退问题排查

1. 在确认是qt库导致的问题之前,不接受指派的bug

2. 让应用负责人提供崩溃堆栈信息,这里要注意有的人为了省事直接就用gdb看release版本的堆栈,这样的堆栈信息什么都没有,不会展现应用上的细节,这也是很多人一看堆栈,没看到应用的崩溃就给底层的原因,所以要和应用负责人确认是不是按照以下步骤获取的崩溃堆栈信息

            采集堆栈信息的步骤:
                    
            (1) 安装应用对应的debug包和qt对应版本的debug包
            (2) 再次复现一次问题
            (3) 使用gdb查看新生成的堆栈信息

一些非主产品线上会找不到应用对应的debug包,这时候需要在复现问题的电脑上搭建开发环境去编译debug版本

我目前处理的两个崩溃问题,最后都是在安装debug包后,从崩溃堆栈上看到崩溃位置是在应用业务代码上,这是目前是最容易划分崩溃责任的方式了

3. 应用负责人按照正确的步骤提供堆栈信息,如果堆栈信息中有明确的qt代码崩溃位置,则接收bug,反之,qt框架可以协助排查,视情况决定是否接受指派bug

4. 在排查问题时,要拉测试和应用负责人进群沟通,避免做传话筒

5. 在要完全投入去排查问题前,要确认如下信息

        (1) 通过堆栈信息已经无法看出崩溃的具体位置
        (2) 确认测试负责人 确认应用负责人
        (3) a.确认电脑硬件 
                b.确认操作系统版本(build id) 
                c.确认应用版本 
                d.确认qt版本
                
        (4) 确认问题的现象,测试提供问题现象视频
        (5) 确认问题是否必现,确认问题复现的手法,测试应提供高复现率的操作手法

6. 问题排查阻塞,无法继续进行的,要及时向上汇报

 

功能性问题排查

1. 在确认是qt功能问题之前,不接受指派的bug

2. 应用负责人应提供一份能复现功能问题的最小demo,这样就不用梳理应用的业务逻辑

3. 应用版本不变,更换qt版本比较

        例如,目前的版本是qt0.3版本有问题,那么可以将qt更换到qt0.2版本再测试,如果还有功能问题
        大概率就是qt的问题了

总结

        虽然我自己梳理了一些排查步骤,不过还是很难落地。本质上还是没有一个能快速划分问题责任的方式,有些问题看起来是qt问题而且也不好推给应用,我也不想去为了一个问题归属扯皮(可能再干烦了就会去扯皮了)

        不知道我以上的思考是否正确,请看到这篇文章的大佬提供点建议,谢谢