实施单元测试的理由（一点体会）

cmsbai

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

cmsbai

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

wangxh1000

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 ]