51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 5055|回复: 6
打印 上一主题 下一主题

[讨论] 大家谈谈如何控制代码质量

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-7-23 23:42:51 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
最近部门项目出现了一些质量问题,
经常发现开发为了赶进度,不自测,导致交付测的东东没法运行,浪费了大量时间,
不知道针对这种情况,如何去通过体系去约束比较好
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

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

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

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2008-7-30 16:59:32 | 只看该作者
谢谢LS几位, tofy说的对, 尽量还是使用一些工具来实现部分检查, 然后做好一些框架直接给开发用,目前我们用checkstyle来检查,用习惯了,大家也就默认了
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2015-1-13 13:37
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    5#
    发表于 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和他们的绩效挂钩,他们应该会引起重视的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    3#
    发表于 2008-7-24 09:04:34 | 只看该作者
    其实在我原先的脑海中,对于代码的控制,最好的办法是进行良好的配置管理控制。进行版本的锁定,健全的变更管理流程。

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

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


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




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

    使用道具 举报

    该用户从未签到

    2#
    发表于 2008-7-24 09:00:11 | 只看该作者
    我也很想知道。
    最近也为这个烦着呢!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-26 21:12 , Processed in 0.073665 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表