前言
我刚出来工作的时候,一直逃避BUG,总会找借口说修复不了,后果可想而知。经历了几年的社会打滚经验,我在上级领导与其他同事的影响,逐渐慢慢的学会克服了各种一些我以为没办法修复的BUG,从而领悟出一些BUG解决经验。
延伸:
![f816eff81b1418c96157f33345561cc5.png](https://i-blog.csdnimg.cn/blog_migrate/7f244fd174d1b8f090da0f977e60cb9e.jpeg)
BUG分类
Software Defect (软件缺陷)≈ Software Bug (软件漏洞)
横向划分
- 业务逻辑缺陷
if-else / switch语句判断错误。
for 循环语句判断错误。
函数执行顺序错误。
注意异步操作问题。
- 技术缺陷
数据编码缺陷。
数据类型转换缺陷。
工具库 / 框架缺陷。
代码笔误缺陷。
代码性能缺陷。
软件配置缺陷。
软件运行环境缺陷。(Java/Nodejs/.Net/PHP/Python等各种软件运行环境版本)
软件系统环境缺陷。(Windows/Linux/Mac OS/Android/iOS等各种软件系统环境版本)
硬件设备环境缺陷。(CPU/硬盘/内存/网络/路由器)
注意IPV6与网络防火墙问题。
- 操作失误
软件权限。
软件打包。
软件版本号。
严格来讲,操作缺陷不算真正的软件缺陷,但操作失误也会导致软件产生意外缺陷。
纵向划分
- 优先级
紧急 > 高 > 中 > 低
BUG是永远修不完,BUG优先级划分,有利于研发人员利用合理时间去解决重要的BUG问题,而不是浪费时间去修复一些无关紧要BUG,导致自己的产品蒙受损失。
BUG修复
1. 复现问题
- 了解BUG的普遍性与特殊性。
找出在自己能正常运行应用,别人不能正常运行应用的问题。
- 了解BUG的复现步骤。
针对测试人员或用户的反馈步骤进行复现问题。
2. 定位问题
- 采用打断点方法。
在代码运行打断点,了解代码运行环节。
- 采用注释代码方法。
将代码一句句注释,来缩小BUG范围。
- 采用打印方法。
在代码打印出变量值、函数运行顺序。
必要时需要输出日志文件进行定位。
- 检查版本控制的历史代码。
检查自己代码是否被覆盖,是否存在冲突。
3. 修复问题
- 进行代码审查。
- 请教你身边的同事,上级领导。
不耻下问,不要不问。
- 将错误提示复制,到搜索引擎搜索。
延伸:
![1aece8034dfcd918525069575a49b8e0.png](https://i-blog.csdnimg.cn/blog_migrate/c6afd47e8f64deea4b22da50afded1ce.png)
注意分析BUG的真伪性,确认是真正意义上的BUG才去修复,否则只会适得其反,BUG越修越多。
BUG管理
- 通过文档管理BUG。
![b109f4aa07d1ee17ee242f504e5fe90a.png](https://i-blog.csdnimg.cn/blog_migrate/9173734eaa546658595c5b0c1c3ca827.jpeg)
- 通过项目管理系统软件管理BUG。
![a3c0c4f0ef06d05e9895ff5c53d16075.png](https://i-blog.csdnimg.cn/blog_migrate/3b643ca2a41616a656c301ea12ef21fa.jpeg)
延伸:
反馈BUG的参考格式
时间: (年/月/日)
标题: (简单标题)
等级: (紧急 / 高 / 中 / 低)
描述: (详细内容)
环境: (软件系统环境/硬件设备环境/网络环境)
位置: (URL地址 / 应用页面)
截图/录像: (选填,产生BUG现象截图)
复现:(产生BUG操作步骤)
实际结果:(出现什么现象 / 问题)
预期结果:(应该是什么样 )
是否修复:(是 / 否)
备注:(选填,如果不能修复软件BUG,补充说明原因)
如果实在无法修复严重的BUG,应该及时停用,减少不必要的损失与麻烦。
不建议在生产环境继续运行有严重的BUG的产品。
建议
BUG并不可怕,可怕是你自己不去克服它。
要相信自己,不要给自己找借口。
不要轻信自己的直觉,抱有质疑的态度。
冷静分析代码,大多数的BUG是可以修复的。