一.今天完成的主要内容

1.学习理解bug修复流程

第一,测试人员提出bug,并且将bug指派给项目负责人,同时在禅道创建bug

直接将bug指派给项目负责人的原因是测试人员并不是非常清楚这个bug所在的模块是由具体的那个开发完成的,所以先将bug都指定给负责人,具体由负责人去指定开发人员解决

第二,负责人看完bug描述之后,确认属于bug,在禅道中点击确认bug,同时指定具体的开发人员去解决bug

第三,开发人员解决bug,解决之后在禅道中将bug状态更改为已完成

第四,开发人员提交bugList,因为bug不止一个,不能没改好一个bug就去找测试演示一遍,这样太过于浪费时间,所以在bug改好之后,组合为一个bugList,统一向测试演示

第五,开发人员和测试人员约时间对bug的修复进行演示

第六,如果演示通过,打tag,开发人员发发布测试环境申请邮件

第七,测试人员在测试环境进行测试,测试通过,发布线上,关闭bug,测试不通过,继续该流程

2.修复了两个bug

这两个bug都比较简单,算是练练手,熟悉流程

一个是短信的内容模版有多余的字符,还有一个是判断时漏判了一种情况

总结一下今天改bug的感觉吧

首先,第一步就是要bug复现,改bug其实就是解决问题的过程,要解决问题,先要定位问题的位置,复现不了bug,什么都白搭

复现bug第一是根据bug描述,点击相应的页面和按钮,找到相关的接口,这一步算是大概定位问题

第二是根据接口中的代码,判断是在哪张表中的那个字段,这时可以通过更改开发环境的数据进行,这一步算是精确定位问题

第三是阅读逻辑代码,此时可以通过打日志,断点调试等手段查找出逻辑漏洞,然后进行修复

第四是测试修复的情况,检查有没有新的bug

感觉原则上是源代码尽量不要做太大的更改,能不动的就不要动,以免出现bug没改掉,反倒出现新的bug的情况,不要偷懒,该登陆就登陆,该注册就注册

3.学习了怎么打tags

其实命令很简单,可以在本地打,也可以在服务器上打,但因为是第一次操作,还是出现了不少问题

第一步是,用mvn release:prepare命令将代码打成tags版本,放在svn上

第二步,用mvn release:perform命令将打好的包上传到公司私服镜像上

看起来简单,但实际操作中还是有地方需要注意

最主要的就是在执行第一步的时候,会有三个地方要求你选择,第一个是选择当前svn上tags的版本号,第二个是选择在私服上的版本号,第三个是选择下一个trunk版本的版本号,其中第三个选择中必须要求是SNOPSHOT版本,因为trunk中的代码属于开发中,开发中的一定是快照版,而不是稳定版.

今天出现问题的原因就是不理解这三个选择的含义,选择第三个时选择了稳定版,结果导致回滚之后再打tags的时候就一直失败,也算是长了个记性

二.明天计划完成的事情

明天上午请了半天假,要去医院检查一下身体

1.如果还有bug,就继续保质保量的修复bug

2.如果没有bug可以改,整理老大讲的关于敏捷开发的各个环节

三.遇到的问题

如何打tag,一开始各种报错;解决方式是百度+主动询问

四,收获

学会了如何打tag

五,项目进度情况

今天自己负责的两个bug,都改掉了,没有延期