写单元测试的一些问题

我们开发的是一个流程管理的软件，使用delphi开发
输入数据，然后通过一个检查，处理的流程。
现在我们的测试方法完全是手动的方式进行。
我有在网上找到一个DUnit的测试组件，和JUnit类似。
现在我在自己的实际使用过程中发现以下的一些问题：

1.写单元测试的时候，要考虑是否覆盖了需求，是否覆盖了所有出现的状况，
这样写单元测试的时候，花费的时间要比实际开发过程多很多。消耗了很多心力。

2.我在设计的时候，考虑到了写测试代码的方便性，但是在用户UI操作的方面，
要么写单元测试代码的速度远远比不上直接手工测试，要么无法发现所有问题（比如界面格式上的问题，需要眼睛来看）。

3.我们是有专门的测试人员的，那么对于开发人员来说，是否应该把测试代码编写和测试的任务交给测试人员，
如果这样的话，开发人员自己测试自己的代码，应该到什么样的程度才行？
测试人员发现了Bug，是否应该扣开发人员的绩效？如果这样的话，开发人员都自己测试了，还要测试人员做什么？

基本思想是:
1.测试代码编写时间 是用在了设计之上 了.
在设计上找到bug修正所花的时间
10倍于在写代码时
100倍于在测试时
1000倍于上线时
10000倍于运行一年之后

你浪费的时间对于上线期时改bug时间哪个更值?

2.对于界面来说手工测试必不可少
因为界面本身用人来测试就是一种
TDD用眼睛测试显示逻辑是最直接的测试先行
(与设计阶段更接近)
而写代码反而是间接的测试浪费严重.


3.你要明白你写测试是为了设计
而不是为了找bug
找bug还是给测试人员去作吧

4.有关绩效你会发现很多公司是由于恐惧bug带来的不缺定而产生的规则
当你能够正确的衡量项目进度
绩效这东西会慢慢从公司规定中去掉.

恩，这里也有详尽的解释。
http://en.wikipedia.org/wiki/Test-driven_development

没那么严重，你们缺少的是一套规范的测试流程。
可以看一下HP的TestDirector，大致分为需求用例、测试用例、Bug提交、自动化测试等等。
在需求文档基线发布之后，需求用例这块由测试人员完成，然后测试人员写测试用例，这个过程与开发人员的设计同步。测试用例和需求用例一一对应，TD可以自动显示覆盖率，这个覆盖率应达到100%。
至于单元测试，我认为这个和测试用例是点面的关系。单元测试一般做的就是看看某些类、方法是否执行正确，有无异常，逻辑有无错误，在此基础上笼统的东西应该在程序可运行之后交给测试人员来进行。