疯狂

STANDING ON THE SHOULDERS OF GIANTS
posts - 481, comments - 486, trackbacks - 0, articles - 1
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理
 
        一个关于移动的项目,现在做了快两年了,项目越来越大,其中有的表数据加上历史数据都到10亿级别,由于这两年团队成员流动大,导致代码越来臃肿,前期项目代码的管理不善,除了较大的版本,一般的小修小改都不经过代码评审,本地测试通过后,直接hotfix,有时候很顺利,但是偶尔导致较大问题,有时候甚至影响客户使用,导致公司亏损。现在领导发现问题就直接骂工程部,导致现在每当有一点点修改,工程部都要求AQ按照测试用进行全用例测试,测试非常的不易,光是功能测试几乎5个测试人员一天时间,还要兼容几乎所有浏览器(ie6~8,火狐,遨游,TT,360,google,搜狗)。工作量巨大。没办法现在我们的做法如下:


1      加强代码的版本控制,对每次代码的修改,都直接联系到个人,代码的修改都要写修改说明,包括:修改内容,修改前效果,修改后效果,对其他接口或功能的影响,回滚策略,测试用例。

2      代码评审:代码评审的标准我们也在不断修改完善,过一段时都会对评审标准进行评审。评审前参会人员都会拿到 上一步相关人员写的修改说明,会前2小时阅读,会中,有相关人员对代码进行流程讲解,并进行效果演示,评审内容包括,代码评审(是否符合代码评审标准),效果评审(是否达到产品需求效果),用例评审(是否可以覆盖当前修改),回滚评审(出错后是否可以及时的回滚到前一版本)。

3      总结每期评审结果,必要时间进行讨论,提出问题:包括项目中遇到的难题,和大家对评审的看法,总结经验,并对公认的技术问题进行归类,由对此熟悉的人员(架构师,开发经理,个人)在周一进行技术讲解(我们是每月2次的技术培训,没有公共话题的情况下,如果有人想分享个人经验的话,可提前准备,现在为了鼓励大家,根据培训效果,对培训讲解人是有偿的,奖励多少不公开,会中很活跃,一般不会刻意打断你,除非公共话题,这一点我是比较喜欢,每天都会去翻大量的文章,书籍去了解话题)。

4 和绩效挂钩,这一点大家都不喜欢啊,不过没办法,领导意思,每次上线都搞得心里惶惶的。

        这些工作我们做了半年,也是有成效,有时候评审会叫上工程部的人来看,工程部也承认我们的工作,也不怎么要求全用例了,但是好多都慢慢形式化,包括评审,主要还是有时候项目特别紧,大家都加班加点干项目,为了上线,项目都改了好几个版本,还没评审一次,结果可想而知。有时候也想过自动化测试,但是离开了人为的控制任然问题多多啊,主要是自动化测试这方便经验不足。

       不知道大家在开发大型项目的过程中,都是如何保证产品质量的,主要是如何在项目比较将紧的情况下防止全用例测试,不要说你们每次修改都全用例测试,都是绿灯才上线,全用例测试对我们来说那简直是要命啦,也不要说刚招聘的一个新人他写的代码你就放心不用测试评审。

        我个人认为是可以避免少量修改导致的全用例测试的,主要的问题就是修改带出来的新问题,如何防止修改老问题带出新问题,个人认为有以下因素导致:人的积极性,人的责任心,人的上进心。人的积极性需要领导层共同解决,如何在紧张的项目下给员工舒适的环境和心情,人的责任心和上进心是就是自己的素养,不管多么没意思的工作你是否愿意去做好,还有就是你是否愿意提高你的技能来防止这些问题。  但是这每一点都不是嘴上说说就能做好的。
   

评论

# re: 如何防止少量的代码修改导致的全用例测试  回复  更多评论   

2010-10-19 08:49 by 阿里巴巴
写的很好,很真实,拜读了

# re: 如何防止少量的代码修改导致的全用例测试  回复  更多评论   

2010-10-19 08:54 by 阿里巴巴
我们公司的项目,能把IE6-8都支持了就不错了,呵呵

# re: 如何防止少量的代码修改导致的全用例测试  回复  更多评论   

2010-10-19 19:50 by
主要功能录一下自动化脚本,发布时跑一下就行了。

# re: 如何防止少量的代码修改导致的全用例测试  回复  更多评论   

2010-10-20 10:46 by heqs
要兼容那么多的浏览器,实在不易,特别是IE6

只有注册用户登录后才能发表评论。


网站导航: