51Testing软件测试论坛

标题: 大家谈谈如何控制代码质量 [打印本页]

作者: enjoyyin 时间: 2008-7-23 23:42
标题: 大家谈谈如何控制代码质量
最近部门项目出现了一些质量问题，
经常发现开发为了赶进度，不自测，导致交付测的东东没法运行，浪费了大量时间，
不知道针对这种情况，如何去通过体系去约束比较好

作者: yangxiaowen0622 时间: 2008-7-24 09:00
我也很想知道。
最近也为这个烦着呢!

作者: yangxiaowen0622 时间: 2008-7-24 09:04
其实在我原先的脑海中，对于代码的控制，最好的办法是进行良好的配置管理控制。进行版本的锁定，健全的变更管理流程。

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

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

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

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

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

作者: tofy 时间: 2008-7-24 19:44
这种现象应该在很多公司都存在，确实是一件非常棘手的问题，又要赶进度又要高质量的产品，本身就是矛盾的。当然方法肯定是有，关键是能否实施。参加过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
谢谢LS几位, tofy说的对, 尽量还是使用一些工具来实现部分检查, 然后做好一些框架直接给开发用,目前我们用checkstyle来检查,用习惯了,大家也就默认了

作者: chengxq 时间: 2008-8-4 10:38

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

进度、质量、成本，这个质量管理的三角形，如过关注质量，可能进度和成本就有问题，意思是只要关注其中任何一个，那么另外2个都会有问题。
这就需要项目经理在这三者中确定平衡点
首先，这对于项目交付来说，已经是个风险，对产品质量来说已经是问题
其次，要确定客户的品质要求，如果客户现在急着上系统，那和客户进行说明，就是现在的系统不稳定，如果可以一边使用一边测试。
在此，如果项目不急着上系统，可以和客户沟通，和客户说明其中的依赖关系，利益关系，为了产品质量，退后交付。
PS：沟通！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)