单元测试不象黑盒测试那样容易上手，对测试人员的要求相对高一些（起码要有代码编写经验），同时要求测试人员在整个项目进度中彻底参与进去，特别是确立项目需求、开发计划、详细设计过程中要和开发人员准备的一样充分，所以说单元测试的准备工作量是远远大于黑盒测试的，同时对于各个测试点要以代码来实现，工作量整体上也远远大于黑盒测试。但是单元测试的好处是多方面的：
一、        测试代码可以复用，编写完之后在开发人员更改被测代码后可以自动执行。
二、        可以把产品质量保证到代码级，发现问题可以准确定位到代码行，大大减少了开发人员定位BUG的时间开销。
三、        单元测试的介入是一个更加规范的开发过程，每个环节都在保证产品的质量。
四、        要求测试人员更高技能的同时，为测试人员的发展提供了更快更宽广的提升之路，同时TDD模式提高了测试人员的地位。
五、        测试代码本身就是很好的文档，记录了代码模块的功能以及关系。

引用:

Originally posted by cmsbai at 2005-6-7 11:20 AM:
单元测试不象黑盒测试那样容易上手，对测试人员的要求相对高一些（起码要有代码编写经验），同时要求测试人员在整个项目进度中彻底参与进去，特别是确立项目需求、开发计划、详细设计过程中要和开发人员准备的一 ...

上面的哥哥说得很好，我也说说我的感想：

• 感觉“单元测试可以拿来做自动化的回归测试”是最爽的，一次编写，无数次重复执行
  
• 测试越往后，投入产出的性价比越差。所以，更早地干掉更多的错误可以帮助减少后期测试压力，帮助每阶段的测试都更聚焦在本阶段的测试目标上。
  
• 一个疑问：尽管我也帮开发人员编过单元测试代码，但理论实践上说单元测试应该是开发人员的活动阿，包括TDD也是，是开发人员先编写测试用例，然后再实现测试用例对应的代码。
  
• 测试代码就是最好的API说明。（这点是JUnit这样的自动化单元测试标榜的优势之一）
  

[ Last edited by wangxh1000 on 2005-6-9 at 16:54 ]

在现阶段大部分单元测试的确是由开发人员自己做的，开发人员做的好处是自己了解自己的代码，编写测试比较容易，同时减少了沟通时间。但是开发人员自己做单元测试可靠的前提是其比较负责，这种依赖负责精神的工作流程并不是一个严格规范的流程。测试人员做单元测试的分工做到了各有其责，虽然在时间上多消耗了一些，但是是更加规范的流程，减少了对开发人员责任心的依赖。

我现在面对的问题是项目周期太短,这样一来只有对语言相当熟悉并且对测试有深刻理解的测试人员才能担当此重任.
另外人力不足,有可能这个项目是Java开发的,下一个项目又是C/C++开发的,所以对测试人员的要求又多了一条.
最后通过单元测试后再做性能测试可能会更有针对性,发生问题进行调试分析也会给开发更大的帮助.但是这样测试人员要做很多的工作,我想最好的方式是有明确的分工,但这只是理想情况.
列出这些情况只是想说明一下,单元测试任重道远,前途肯定是光明的.