不论是单元测试还是接口测试，熟悉程序内部实现都是有用的——这种理解是有问题的，我们目前所做的测试除了集成测试就是小规模的集成测试。

现在测试组目前的所有测试都不是单元测试，因为单元测试最基本的单位是函数，接口测试是一种测试手段，不是一种测试分类。

编写测试用例跟程序实现没有必然联系，比如按照测试驱动开发的理论的测试用例编写是从函数接口都没有的情况下开始写的，此时接口都没有，更别说实现了，这样就写不出测试用例来了么？
编写测试用例关注什么，关注的是模块的行为，也就是通过输入看输出，是否和设计文档、接口头文件中的描述一致。比如一个函数声明为

// 为公司的数据库添加一位新员工的信息，包括工号，姓名，性别
// 约定工号始终为正数，男同事为1打头，女同事为0打头
// 姓名不得为空
// 性别0代表女同事，1代表男同事
// 添加成功则返回true，失败返回false
bool AddEmployee(int iNumber, String sName, int iSex)；

有了上述这些信息就可以开始设计测试用例了，比如iNumber = 047788, sName = "li hong",  iSex = 1, 我们期待的返回值就是false，因为性别和工号有冲突。如果测试返回true，则说明软件有bug。

这是写一条测试用例的整个过程，其中并没有设计到函数的内部实现啊？

我们现在的开发离测试驱动开发还有很长的路要走。
我们能做的是什么呢？
是回归测试，开发人员对模块进行回归测试，带着反馈工作，尤其是在添加新功能，修正bug的时候，有了回归测试，就像有了杂技演员的身上有了保险绳，可以放心地在高空中做各种动作。

现在该怎么做呢？
我的想法是，测试框架的搭建是由开发人员做好的，因为一些解耦和的工作是必须开发组来做的（随着技术的进步，越来越多的解耦合方法被提出来，想详细了解这方面的东西，推荐看《修改代码的艺术》）。具体来说，比如我要做一个模块，现在已经做到一半了，基本功能都做得差不多了，但是心里没底，因为没有QA。这是后就可以用DUnit来创建测试工程，写一些测试用例。但是，现在版本压力大，没有这么多时间把测试用例写全面，怎么办？把测试框架给测试组，由测试组的同学来完善和丰富测试用例，因为测试组的同学比开发组的同学有更深厚的测试用例设计基础，能写出更好的测试用例，同时也有助于提高测试组同学开发水平，促进TEST向QA转变。另外，这也避免了开发人员在编写测试用例时的思维定势，导致明显的问题也测不出来。

这样，随着模块的不断完善，开发人员把测试框架进行补充，测试人员丰富测试用例。如此交替进行。

另外一个比较关键的问题是开发组测试组提供什么来进行测试。提供源文件的方式是行不通的，目前采用比较多的是提供DLL，同时为了避免测试规模增长，采用了DLL注册等一系列机制。
我的想法是由开发组提供模块代码的.obj文件和测试用例的源文件，这样测试人员可以随时构建出自己需要运行的版本，感觉上就像手里有模块的源代码一样，只是不能进去debug。

所以说，现在先做一个模块，解耦合、大框架、测试组编写测试用例，这一整套流程做通了，证明切实可行，方便有效。开发组自然就乐于接受了，测试组可以在模块的级别上进行QA，而不是在发布版本之后才进行集成测试。

一点小想法，具体实现，还需要各位都加把劲啊，呵呵。