这样行吗？

刚到一新公司，公司想开始做单元测试，可是公司认为以前程序员自己做单元测试执行不力，很难达到预期目的。
所以现在他们想由测试人员来做。

系统设计师设计到很细的程度，基本上程序远不用对自己负责的功能模块写概要设计很详细设计，只需要按照系统设计师的设计编码即可。即主要类都已经确定了，程序远只需要实现功能并通过单元测试。

这样做和我以前的工作习惯很不一样，请问这样做的优点和缺点

呵呵，是不是你们公司做程序员的水平很低或者是要求很低啊？这就是很多人眼中所谓的蓝领了。不过我在想，你们那系统设计师真要忙的，都精细到那种地步了。
   关于单元测试呢，你就要看了，对于java来说，因为Junit的缘故，做起来容易，要是其他的某些语言（比如delphi或者PB什么的），就不那么简单了。而且，对于基于UI的程序做单元测试也是比较麻烦的事情

非常表示怀疑。
从传统的观点看，单元测试是白盒，要测试人员去作显然不合适。这和你们使用的开发指导思想相违背。
而他们看来还没有使用单元测试，所以才会有这样的做法。等着他们去实施好了，你现在只要提出你的建议就可以。等他们失败。
当然这样的做法是非常考验你们领导的调节争端的能力的。很有可能会造成很多的争吵，以至于最后造成部门间的战争。同时这也对你们的测试人员的技术水准提出了更高的要求，至少他们的编码能力不能比你们差。

架构师设计接口
测试工程师根据接口写单元测试
程序员完成功能并通过单元测试

很明显，这里的测试工程师并不是那些功能黑盒测试的测试员

呵呵，他们是真开始这么做了~ 我是新来的，反对声音太小。
这两天还要我给他们写个规范文档，我晕，能写什么规范啊。
没辙，我就给他们弄了个JUnit实施教材~不过东拼西凑的，自己感觉还很满意。

对了，各位觉得Cactus好用吗？我一直感觉用这个东西测试配置有点复杂，弄起来得不偿失。不过《JUnit In Action》的作者好象比较推崇。

如果要你给他们写规范文档，恐怕意味着o6z的预言要成为现实了……
测试人员进行了单元测试，发现不通过。于是他有两种选择：
1 告诉程序员单元测试“某个函数挂掉啦！”然后你自己运行一遍，发现挂掉了，于是改代码。
2 发现某个函数挂掉了。于是自己看代码，发现bug，告诉程序员要如何如何改代码。
第一种方案相当于找了个监工（这也体现了xp风格，呵呵）
第二种方案……测试人员的工资是多少？

但现实恐怕是测试人员要用很长的时间学会使用jUnit。然后发现自己对代码一窍不通。

这倒是让我想起我们一个同事的笑话。他觉得我们的测试人员水平太差。认为他们应该可以测出spring的配置文件写错了；可以接听客户的电话，从客户反映的问题获知是客户的问题还是系统的bug；可以对客户进行培训……
最后我说：“sxxt，你说的是我们的项目经理吧？”