感觉现在我所在开发团队太依赖测试部。产品线有一个相当大的系统测试部门，软件有3个大的子系统，协议子系统，由专门的一个平台部门完成，驱动子系统和微码子系统，这两个子系统由一个部门完成。项目现在运作的流程是这样的：需求分析->设计方案->详细设计->编码->联调。这些都是开发人员的工作。联调是协议子系统、驱动子系统和微码子系统的联调。之后版本就到测试部。一年前又在开发部成立了一个集成测试小组，原因是项目老大们认为以前到测试部的版本质量太差。 我们的开发周期比较长，开发效率也是非常低下的。一年来我的观察（具体数据作为开发人员的我是不知道的），项目到测试部后一般要维护半年以上才能发布，发布后网上问题也比较多。我觉得这跟我们现在的开发过程有很大的关系。单元测试、集成测试我们都没有做好，依赖系统测试来保证质量，我觉得这是不科学的。开发过程没有明确的单元测试阶段，有经验的开发人员会在联调前自己做自己子系统的单元测试，但是一般也是简单的测测，据我所知，很少有人真正按照单元测试的方法编写单元测试用来进行单元测试，我觉得这不是开发人员的责任，是项目管理的责任。子系统的联调周期非常的长，因为经常会出现一个问题导致联调无法继续。可以说联调阶段很少有不延期的，一旦任务延期，项目经理又催着合版本，结果就是开发人员草草的测后将代码合入正式版本。在版本提交给测试部之前，集成测试小组会对版本的基本功能进行一个初步的测试，这个测试跟真正的集成测试还差的很远。因为项目经理永远都认为开发代码和维护比这个工作更重要，集成测试小组的人员都是兼职的，所以根本无法做到真正的集成测试。版本到测试部后就进入了维护阶段。开发部是需要相当大的人力维护版本的。版本维护前期，开发人员是经常需要去测试部定位问题的。 个人觉得现在这种开发模式是很不好的，我觉得新增功能应该在开发部有一个充分的测试之后才能进入测试部进行系统测试，不能太依赖于测试部的系统测试。测试部测出故障再修改的成本是相当大的。定位问题至少需要几小时，这时，测试人员什么也做不了，然后再修改，合入版本再验证。 我觉得单元测试不可少，应该明确定义单元测试，这个由功能的开发人员完成，并且需要按照单元测试方法来做，需要一定的结束准则，比如语句覆盖等。集成测试也是需要的，这个可以由功能开发人员来做，也可以由专门的集成测试小组来做，集成测试需要做到真正的集成测试。灰盒测试。联调实际上可以说就是集成测试，但是以前的联调没有准则，无法知道测试的程度。既然开发部觉得没有人力支持专门的集成测试小组，我觉得我们是完全可以通过控制联调的质量来控制版本的质量的。虽然各个功能集成起来以后可能还会有一些问题，但是我们至少可以保证单个功能模块是没有问题的。在版本到达测试部之前，可以由现在的集成测试小组进行一个基本的验证。我觉得我们只要每个步骤都踏踏实实的做，效率肯定会提高，版本周期肯定会缩短的，版本质量也会提高。因为有些设计的问题，依赖系统测试是很难测试出来的。 我第一份工作所在的公司这方面就做的比现在好。他们是有明确的单元测试的，要求语句覆盖率100%，开发人员还需要进行集成测试和系统测试（这个系统测试和测试部的系统测试有点不一样），版本才能进入测试部，一般维护版本只需要测试几轮，版本就可以发布了。我们现在的版本，已经测试了十几二十轮了，还是不能发布。 我希望我们的项目经理们应该抽出时间来分析一下我们版本质量差的原因，而不是出了问题就对开发人员进行处罚。他们应该负很大的责任的，遗憾的是，他们整天都在忙于“救火”。现在有点恶性循环的感觉，版本越多，维护就越累，维护再加上新版本开发，人力永远都不够用的，光靠招聘新人是解决不了问题的。 原文链接：/javaschema/288023.html