单元测试的开展阶段

windone

请教一下各位专家关于单元测试的开展阶段：
请问单元测试适合在开发初始编码阶段进行还是适合在代码基本稳定后展开？

我的观点：
如果在编码阶段进行，则适合开发人员自我展开单元测试。这样很多初级的简单的代码错误，比如说变量未定义就使用，或者变量定义了却从未使用，开发人员可以自己解决。我们现在针对C语言展开的MISRA C代码规则检查，让开发人员自我检查自我修改，效率就很高。
但是现在国内，像我所在的公司，开发人员在编码阶段主要精力在于产品功能的实现，单元测试很难展开，而是交给独立的测试部门来完成。测试人员如果前期介入，开发的代码不稳定，会产生很高的沟通成本，同时也会急剧增加开发、测试的工作量，版本管理也很难。而且这样的操作，很容易让公司感觉单元测试ROI太低。开发测试都被折腾。
还有一种模式，就是单元测试在完成系统功能测试之后进行，这种模式和我们当前的开发现在比较贴近。开发人员在项目压力下，首先保证实现系统功能，然后提交测试进行系统功能的验证。之后，在功能实现的基础上，软件代码也基本稳定了，客户如果需要也可以提交产品了。还有一点：如果继续展开系统功能测试，已经很难再发现新的Bug。所以，从测试方法和手段的角度来看，开始推行单元测试，对软件代码的边边角角展开扫荡。从某个角度来看，单元测试主要为了提高软件的稳定性，可靠性，是为了提高软件的性能。这个时候开发也有时间来进行项目总结，进行详细设计文档的编写。测试在展开单元测试的时候，可以充分利用软件发展积累下来的质量模型，对软件代码质量进行评估，反馈给开发进行进一步优化，保证代码的稳定性，可靠性，提升产品的性能。

单元测试的关注点，是代码层次的质量，所以对功能可能不是很敏感，更多的是代码性能评估。
请成功实施过单元测试的专家们发表意见。

我这里说到的项目都是项目周期很急，新开发的项目。如果是平台项目，产品项目，可能又会不一样。

windone

没人讨论，本论坛还是下资料的人多啊

cqian

支持第二种模式，第一种模式很容易给开发人员带来压力