单元测试由开发完成还是由测试完成？(2011-5-30)（获奖名单已公布）
单元测试由开发完成还是由测试完成？如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
获奖名单
奖项获奖名单奖励答案链接
一等奖1981david50元手机充值卡15#
当然是开发完成 开发吧，就算是测试做，也是白盒测试的人来做。 领导让谁完成就谁完成 让测试来完成不太现实， 不是说测试人员没有能力，而是对开发代码的熟悉程度和理解是个问题，这个函数是什么作用 有多少路径和参数等等， 即使能让测试人员很熟悉 那应该建立在很长时间基础上， 所以还到不如让开发来完成单元测试， 但要输出测试件，在由测试人员评审测试件，作为转测试入口可能更好些， 个人观点 个人理解，还是共同协作来完成单元测试的，这个时期，应该主要还是开发主导来执行，测试应该更多的是理解，主要是从结构的理解上，要下番功夫，以便后绪更好的进行一下静态的代码检查，同时，也对动态的分析有个学习和提升，当然，最主要的还是为测试人员完整进行的集成，系统测试以及其它验证系统稳定性等的测试做一些积累，更好的理解系统，才能设计出更好的测试用例，以及更好的把握测试方式方法。
拿JAVA开发的WEB应用来说，可能开发人员会在开发过程中，要求用Junit对一些组件进行一个测试（调试），因为可能还没有可显示的输出让测试人员去验证，所以，只能通过Junit来进行一个调试性的验证，如果调试的好，各种预期的输出在代码中都有断言，那这应该也算是进行单元测试了，同时，在提交代码时，用findbugs进行一下静态代码检查，把一些前期的代码缺陷尽可能的消掉，这样在以后的测试，以及开发升级过程中，可能会出现更少的错误。如果公司的测试人员有代码检查以及相关的单元测试验证，并且需要完成相应的单元测试报告，那测试人员就要在开发基本完成的基础上，开始着手先把单元测试报告整理出来，整理的内容要求，个人认为：1，开发那边测试的代码分类，2，测试结果，3，代码的耦合度，4，代码扩展性等。。。同时，测试人员也需要借助代码检查功验证工具，进行一个代码质量抽检，并记录抽检结果。
如果是嵌入式的测试，我想因为这种测试现在很多工具和软件也不支持，而且测试人员上手比较困难，更需要开发人员在设计代码时，进行自身的单元测试，最好是开发人员互测。完成单元测试，这也不是说测试人员无事可做，测试人员需要和开发协作，制订一定的代码规范，最起码应该有代码检查规范，其实近一期的51杂志里也提过，嵌入式单元测试时，可能单元测试本身是弱化的，因为它的测试环境以及测试相关的其他的技术的不成熟，所以，尽量多的代强化代码走读，代码静态检查。如C开发的，可以用pc-lint设置一个比较规范的代码检查级别，开发人员调试，测试时，使用。同样，测试人员在进行新版本发布前，同样也可以集成pc-lint和sourceinsight之类的代码查看工具，进行代码抽检，确定代码里没有明显的错误。
回到楼主所问，代码，结构本身，也属项目（产品）的一部分，所以，也是质量控制的一部分，做为开发人员，为自己的代码，结构设计，进行自测或互测，为了提交的质量更高，更易于让人读懂，测试人员，也更测试控制好代码的质量，代码检查结果的记录工作，为后绪测试，以及以后的新人入职培训，质量传承，做一个比较好的总结。
之前做的一个简单的测试体系中，对单元测试就分开来写了，想想也是因为测试现在不能完全独立开展这方面的工作，所以，单摘出来，让整个技术团队共同来抓起来吧。
1. 取决于单元测试的大小， 大的话，还是有懂code的测试人员来做。
单元小的话， 就开发人员做了算了。开发人员测试的好处是熟悉code, 但是他自己可能局限于自己的思维， 测不出自己的错误。
我觉得应该让开发人员自己测， 但有一个较懂code的人检查一下。 应该由谁来做这根本就不是问题，关键是站在项目资源使用的角度、项目进度安排的角度，谁更合适来做。
一般来说，是完成coding的人完成单元测试最合适，测试应该站在更全局的角度考量整个软件实体。单元测试结果应被视为系统测试的支撑。 多谢 回复 1# 默默巫
当前大多数情况下，单元测试是由开发完成的。但是个人认为，当测试发展到一定程度的时候，单元测试完全有必要让测试人员来完成。 具体问题具体分析吧，像有的公司也就是那几个人的团队，也许就没有单元测试了；:dizzy: 主张由开发人员互相完成，类似于结对编程一样，由于思维的局限性和不愿意找出自己问题的心理存在，自己找自己bug的主观能动性会比较差，但是由于组内的开发之间对代码都比较熟悉，虽然读别人的代码会有点吃力，但相对测试来说是会容易一些的，那么互相完成单元测试用例就会比去完成自己的要更踊跃一点，完成后的验证效果也会好一点。同时如果做单元测试是必须的，不管是自己做和给别人做，时间上也是差不多的，所以我很推崇这样的方式，期待相同的声音~~
不过我们以前的单元测试都是开发自己完成自己的，哈~~ 开发完成这个是必须的 建议开发完成。呵呵
当然如果你有空，你也可以做，在基于良好测试架构的模式下，实现单元测试是很简单的工作，就如同测试用例设计。 LZ问题故意混淆task和role。
首先要明确概念：开发任务/测试任务task，开发人员/测试人员role。
开发任务广义指需求、设计、编码、测试、发布及相关管理活动：配置管理、质量管理、项目管理。
测试是开发的一部分。
狭义的开发指coding。
考虑成本vs质量，对于代码质量要求比较高的部分，会做单元测试。
有了详细设计之后，coding和Unit testing就可以开始了，无所谓谁先谁后。虽然有些人强调unit testing应先做，那只是为执行单元测试的作准备。coding到一定阶段，执行unit testing，完成验证。
在一些组织里，coding和unit testing都交给coder来做，因为这两件事看起来是如此紧密相关、类似。
自己测试自己的代码，是程序员的基本要求。
程序员互相测试对方代码，是很好的做法。曾经将程序员分成编码、测试两个组，发现编码组的家伙越来越懒，把发现bug的任务都给别人了，反正有人最后把关，编码质量急剧下降，人都是惰性的。
unit testing是任务，哪个角色做，只是角色定义而已。组织/项目流程定义它就行了，无所谓。
具体到项目中，一人身兼数岗，承担多个角色的情况大家见的多了。 LZ问题故意混淆task和role。
首先要明确概念：开发任务/测试任务task，开发人员/测试人员role。
开发任务 ...
1981david 发表于 2011-6-1 18:05 http://bbs.51testing.com/images/common/back.gif
讲的很有道理，就是这么回事 在《互联网单元测试》这本书中 51testing系列从书之一
有对单元测试由开发完成还是测试完成的答复：
单元测试作为特殊的代码级测试，既需要编写代码－－是开发擅长的工作，又需要设计用例－－是测试擅长的工作。在开发不擅长设计用例，测试不擅长编写代码的情况下，理想的工作方式为：测试设计单元测试用例，开发完成单元测试用例脚本开发，各取自己优势面。 个人感觉应该由开发部门进行单元测试!
由测试部门进行单元测试的问题
代价高：反复的重新理解代码需要大量的时间，反复的沟通也需要大量的成本。
人手不足：进行单元测试的人员需要具备编码能力，很多软件企业的测试部门都没有足够的人手。
耽误了测试部门对其他测试的准备工作：编码阶段，测试部门要为集成测试、系统测试等做好准备，如果测试部门陷在单元测试的“泥潭”里，很可能影响这些准备工作。
由开发部门进行单元测试的问题
担心影响开发进度：这是现实问题，但自动化的单元测试工具可以解决这个问题。
程序员不习惯做单元测试：这种习惯是可以理解的，但并不难改变，实际上，程序员写程序时都是要进行测试调试的，只不过通常比较零散和随意而已。
测试自己编写的代码，难于保证测试的效果：测试自己写的代码，通常会只测试正常的输入，因此难于保证测试的完整性，但自动化的单元测试工具，可以统计白盒覆盖，甚至提供用于找出遗漏的测试用例的工具，达到很高的测试完整性。只要达到了足够的测试完整性，那么，无论谁测试，效果都是一样的。
无论由哪个部门做单元测试，都要面对一些问题，但开发部门所面对的问题可以借助工具来解决，而由测试部门进行单元测试，要么无法真正实施，要么代价昂贵。 在开发和在测试过程中都有吧，有不同的人员完成。 讨论这个问题前，先要解决下面这两个问题：
1. 时间；
2. 人力资源；
做任何事之前都必须先考虑这两个问题。
1. 如果有足够的时间，有充足的人力资源，单元测试不光开发人员要做，测试人员也要做；只不过各自测试的重点与内容有所侧重。开发人员可能更愿意去做一些程序本身流程与逻辑方面的测试；而测试人员会关注更多的内容比如接口等。在这种情况下，如果测试人员能从事更多的单元测试，开发人员，可能会在更大的压力下从事代码的编写工作。
2. 时间有限，且测试人员能力有限的情况下，这时对开发人员的依赖会增加，测试人员能够做得更像是代码级的黑盒测试。测试人员只关注输入与输出（接口），这样的测试可能会给开发人员更多自由的空间。开发人员对程序本身进行主要测试。
3. 没有时间，没有资源，显而易见，在这种情况下，测试人员想做也做不起来。单元测试的一切只能依靠开发人员了。在这种情况下，开发人员的自由被无限扩大，以至于一不小心就会将很多严重的问题带到下一个阶段。
