enjoyyin 发表于 2008-7-23 23:42:51

大家谈谈如何控制代码质量

最近部门项目出现了一些质量问题,
经常发现开发为了赶进度,不自测,导致交付测的东东没法运行,浪费了大量时间,
不知道针对这种情况,如何去通过体系去约束比较好

yangxiaowen0622 发表于 2008-7-24 09:00:11

我也很想知道。
最近也为这个烦着呢!

yangxiaowen0622 发表于 2008-7-24 09:04:34

其实在我原先的脑海中,对于代码的控制,最好的办法是进行良好的配置管理控制。进行版本的锁定,健全的变更管理流程。

相应的代码,尤其是初程写的代码,都要经过经验者的代码走查。

经过评审完毕后,代码是必须封锁的。要改动要走变更管理流程。


对于代码走查中发现的问题&变更的内容,要详细的定义,比对。来分析是否存在类似的问题。




以上思路仅为我个人看法,但是已经被领导否定了。我自己也不知道应该怎么做了。

zhongmg108 发表于 2008-7-24 18:29:06

对代码质量的控制,不要到编码才想起来控制,应该更早一点开始,至少在设计阶段就要开始了。如果设计就有问题,那么编码水平再高也与事无补。代码质量受前面工作的影响很大,有时候代码的缺陷可能是需求或设计的问题。需求要准确完整,设计要合理,这些是代码质量的前提!
当然,在编码阶段仍然需进行质量控制,如进行必要的培训,确保编程人员的水平;引入代码静态检测工具和编译工具;组织好代码评审活动,白盒测试等,当然配置管理也要做好!总之,要从多方面着手。

tofy 发表于 2008-7-24 19:44:58

这种现象应该在很多公司都存在,确实是一件非常棘手的问题,又要赶进度又要高质量的产品,本身就是矛盾的。当然方法肯定是有,关键是能否实施。参加过MSUP培训的时候,了解了微软的质量管理,这里提出来和大家分享,但是要借鉴有很大的难度,下面看下微软的代码CHECK IN流程:
1) Code Review (代码审查)
2) Sanity Check (完整性检查)
3) Smoke Test   (冒烟测试)
4) Buddy Build   (增量Build)
5) Smoke Review
6) Check In
7) Post Smoke
除了代码审查,其他的步骤都是通过自动化实现的。国内很少有公司能做到这样的流程,所以我们还是现实一点,根据自身的情况来想办法提高代码的质量,我的看法是:
1、尽量做到代码走查,很多公司因为资源限制,无法做到,所以我们不要期望人工做了,但是我们可以使用一些单元测试工具,如c++ test,logiscope,cppunit等,我们做好框架给开发人员用,我相信用自动化来实现,开发人员应该会用的;
2、对于公司的主打产品,可以考虑功能自动化,利用现有的QTP,WR等工具来实现,录制好脚本,要求开发人员做完以后,直接运行一遍,开发人员应该也不会拒绝的;
3、当然如果这两点做好了,提交到测试人员手里的产品质量应该很不错了,这样测试人员就可以专心于其他一些异常测试和深层次的测试;目前我们正在做这两块,今年底应该会有效果的;
4、对以上都做不到的,最现实的就是加大考核力度,根据开发提交的质量来考核开发人员,BUG和他们的绩效挂钩,他们应该会引起重视的。

enjoyyin 发表于 2008-7-30 16:59:32

谢谢LS几位, tofy说的对, 尽量还是使用一些工具来实现部分检查, 然后做好一些框架直接给开发用,目前我们用checkstyle来检查,用习惯了,大家也就默认了

chengxq 发表于 2008-8-4 10:38:13

原帖由 enjoyyin 于 2008-7-23 23:42 发表 http://bbs.51testing.com/images/common/back.gif
最近部门项目出现了一些质量问题,
经常发现开发为了赶进度,不自测,导致交付测的东东没法运行,浪费了大量时间,
不知道针对这种情况,如何去通过体系去约束比较好
进度、质量、成本,这个质量管理的三角形,如过关注质量,可能进度和成本就有问题,意思是只要关注其中任何一个,那么另外2个都会有问题。
这就需要项目经理在这三者中确定平衡点
首先,这对于项目交付来说,已经是个风险,对产品质量来说已经是问题
其次,要确定客户的品质要求,如果客户现在急着上系统,那和客户进行说明,就是现在的系统不稳定,如果可以一边使用一边测试。
在此,如果项目不急着上系统,可以和客户沟通,和客户说明其中的依赖关系,利益关系,为了产品质量,退后交付。
PS:沟通!
页: [1]
查看完整版本: 大家谈谈如何控制代码质量