懂得编程的测试人员就能开展单元测试吗？如何实施单元测试

shaoziyi

有一种说法：单元测试应该由开发人员来做而不是测试人员来做的原因是测试人员往往不懂编码。
但是实际情况是这样吗。我有过1~2年的编码经验，应该来说作单元测试还是可以的。现在公司想将单元测试的工作交给测试人员来做，要我来组织一下。但是在我具体做实施方案的时候，却遇到一些问题。

单元测试要求对每一个单元（类或者函数）都执行测试。还要求保证代码、条件、路径等覆盖率。
应该来说单元测试在代码单元完成的时候就进行才是最佳时机，甚至也有测试驱动开发的做法。

那么如果交给测试人员，当测试人员获得代码的时候，实际上单元的组装，引用都已经完成了，所谓的单元早就不是独立的单元了；类或者函数已经被很多次的调用。这个时候再开展单元测试感觉已经过了最佳时机，并且测试人员还要去熟悉整个代码的结构而不是独立的某个单元就可以的，代价也很高。

感觉还不如用黑盒的方式来进行。

不知道各位大侠有没有成功的经验可以借鉴，如果有规范化的大公司的实施方法拿来讨论一下就更加感

激不尽了。

JPeanut

我们公司实现制定一套比较固定的单元测试的规范,,然后开发人员再每开发一个功能点,,就进行编写单元测试的代码..因为,,有一定的规范的脚本,,测试人员可以很容易的就看懂的,,无需要很厉害的编程经验.
但是,,那套单元测试的规范,,很重要,,编制的时候一定需要熟悉开发的测试人员加入

wheetle

开发组长的智能：

如果是大软件，一般分几个模块，一个小组开发一个模块。如果中小软件，可能就一个开发组搞定了。单元测试的组织应该是开发组长的智能之一，当然或许需要和测试部门配合。组长根据本组负责的模块来界定单元测试的基准，然后可以让开发人员或者懂代码的测试人员根据基准来写测试用例。当然开发人员来做最好。单元测试的过程可以根据工作量和进度情况来决定是开发人员还是测试人员做，不必死板追求一个标准

jiangkenan

说的太好了,楼上QQ号多少,我QQ是52504882 有空交流下,我也是做白盒的..顶

bozaibuffer

转贴：……※……

　单元测试由谁来做？单元测试由测试部门来做还是由开发部门来做，是一个引起广泛争论的话题。我们的观点是：由测试部门和开发部门共同来做：测试部门负责制定规范、培训，并检查测试效果；由开发部门负责具体的实施，最好是边开发边测试。
　　测试部门可能不具备实施单元测试的足够人手，即使测试部门有足够的人手，即使项目时间允许，完全由测试部门实施单元测试也会造成资源的较大浪费，因为测试人员要花很多时间来重新理解代码，同时，充分的单元测试通常会发现很多细小的错误，程序员修改代码时，又要再一次理解代码；另一方面，如果等编码基本完成再由测试部门进行单元测试，也就不能发挥单元测试对代码整体结构的约束效果，测试部门拿到代码时，往往会发现难于测试。当然，已经完成编码的项目也不是不能进行单元测试，只不过可能要花费一定的时间成本对代码进行整理重构，后文会有进一步的论述。
　　由开发人员实施单元测试，当然也有问题，主要有：一是程序员可能不喜欢做单元测试；二是开发部门可能担心影响开发进度；三是由于思维定势的原因，不容易保证测试的完整性。我们在设计VU的过程中，充分考虑了这三个问题，提供了切实可行的解决方法和工具。
　　很多开发人员不喜欢做单元测试，甚至抵制单元测试，对于这种现象，常见的说法是程序员太自信，觉得自己的代码不会有错，所以不愿意进行单元测试。这种说法就好象在说程序员“自以为是，不负责任”，所以不愿意做单元测试。事实是这样的吗？作为程序员，我们自己并无这种心理，也调查过一些程序员，没有谁真的有这种心理，实际上，哪个程序员没有翻江倒海地排查一个小小错误的经历？谁写的代码也不能保证毫无错误，人不是机器，即使编程时思维缜密到没有任何疏漏，也还可能有“笔误”呢。那么，程序员为什么不喜欢做单元测试呢？我们认为，主要还是程序员的工作特点造成的。编程是创造性的工作，编程的最大乐趣就在于看到了自己的劳动成果出现在眼前，这就使程序员常有一种“立即实现”的冲动；另一方面，程序员的思维往往是跳跃向前的，当程序员开始了编程思路之后，一般就不愿意中断思路，花较多时间去编写测试代码了；再一方面，跟测试工具也有一定关系，一般的单元测试工具只显示“通过”，“失败”两种状态，相对而言，在产品工程中直接观看代码的运行结果更有吸引力，更容易产生成就感。
　　

bozaibuffer

我认为，单元测试的执行者不一定界定得那么严格。完全没有编程经验的测试人员，肯定是不能很好完成这个任务的。

从详细设计阶段开始，作为单元测试的设计者，组织者，就需要参与到项目中来，要提交可测试性意见，要检视模块、函数接口制定，函数返回值定义等等。这个阶段的参与，也能够做好单元测试用例的设计工作。

现在，极限编程的一个思想就是提倡测试先行，先写单元测试用例，然后再编码，实现函数或者模块。

所以，不管是开发人员，还是测试人员，都需要懂代码，至少能够熟练阅读代码。

而且，单元测试，往往是代码阅读和动态执行结合起来做的。简单的、几句话的函数，可能不需要进行执行验证，代码阅读就可以了。为了验证部分函数的逻辑性，功能正确性，才会进行用例构造，测试验证。
在实际测试过程中，为了测试一个函数，经历痛苦打桩，用例构造后，往往发现，一下子，就测试了几个函数。理想的单个函数的测试，确实比较难操作，特别是涉及到资源分配，硬件驱动等等情况。