修改bug的流程

流程上大致是: 重现 - 定位 - 评估 - 回归

重现
不能重现的Bug都不能叫Bug， 所以对于Bug的追踪管理十分重要。在现代的软件项目中，提Bug的人和修Bug的人往往不是同一个人。对于提Bug的人要能准确的描述出环境和详尽的重现步骤，如果Bug直接来自客户，往往需要在维护人员和客户之间多加一层工作人员，和客户确认Bug的详情。如果你实在无法重现，请迅速找到寻求离Bug最近的（QE， 客户）帮助，节省宝贵的时间。

定位
重现之后需要根据问题的种类来定位。但不管是哪种类型的，首先考虑的就是查日志，比如问题是crash日志里又有stacktrace，那么你该感谢上帝了，一般情况下可以快速定位问题所在
还有别的很多问题，随便例举一些，比如
与预期行为不一致，大多是设计错误或者是逻辑错误，设计错误就是需要修改设计文档，逻辑错误几乎就是少考虑了逻辑，还能怎么办，断点debug，对于快速定位到代码，可以使用搜索该代码使用的文本内容，以及通过二分法， profiler等查找。
数据不一致， 可以通过查看SQL trace（针对SQL Server)，Wireshark等查看数据包，有多线程的时候考虑同步问题
performance差，注意查看execution plan（针对SQL Server)优化执行过程
内存泄漏， windbg来排查（针对. NET）考虑事件未退订，GDI的资源未释放等

评估
查看历史代码, git(svn) blame，找出错误代码是从哪个版本引入的，在系统里存在多久了，再提交code review，审核后提交到代码库

回归测试
修完Bug就完事了，too naive，事实上即使在code review后你的代码也可能存在问题，需要自己和QE跑回归测试用例

手牵手科技 http://www.45zq.cn/