从标题中可以看出，我否定了单元测试就是功能测试。
为什么会这样呢？
在通常的情况下，我们要实现一个功能（客户的需求），通常是需要通过几个函数，甚至是几个对象合作才能完成的。而我们通常的单元测试，只能够对函数及的测试，无法对一个完整的功能进行测试。
单元测试适合一个算法函数的测试，我想大家也看到了大多讲单元测试大多都会列举一些sample，那么这个sample 一定是两个数的相加。为什么会这样呢？因为这样的函数不需要前后的环境，但是在我们编写程序的时候，象这样的函数并不多，大多都是需要前前后后几个函数来完成一个功能。有的可能还要通过发一些消息，或是一些回调函数来配合。在这中情况下，单元测试往往力不从心。同样换成一些自动化测试工具，对这样的需求也是没有办法。至少我是没有发现有什么好的工具来解决这些问题。
  那么是不是没有办法来解决这个问题呢？？

[ 本帖最后由 ricmy 于 2006-1-19 10:35 编辑 ]

引用:

原帖由 jackjackjack 于 2006-1-19 07:59 发表
对于多个函数的问题，其实就是做集成测试吧；至于说设计到一些消息什么，这些和操作系统相关的东西，这涉及到设计阶段，体系构架和设计是否合理，单元测试这种技术方法本身是有一定针对性的；

其实，作为测试来讲，不论是什么测试，最终的目的还是为了软件的稳定性，所以，作为一个测试工具，不是说我只作单元测试，就不作整合测试，这样来说，不是“针对性”，而是“片面性”了。
其实我个人认为测试最原始，最有效的办法就是，将SPEC中的需求，用TestCase的形式表现出来，让程序自动的检测编码的正确性。

表面看，似乎所有的测试工具都是这样，其实不然。
正如我上面所说，单元测试工具只能针对函数进行测试，而SPEC中的需求并不会具体到函数级，所以基于SPEC的testcase 很难用单元测试进行编写。

再从使用的角度讲，函数测试没有问题，并不代表你的功能正确
  为什么这样说呢？菜单一个动作，背后可能会调用到若干个函数，而且这些函数的参数，顺序都是有要求的，那么这个时候单元测试应该如何进行呢？
我们再看单元测试的对象获取方法
  通常在编写TestCase 的时候我们需要定义一个被测试的对象，然后对这个对象进行测试。
   那么显然，这种方法也是很不好的。为什么这样说呢，在很多时候，我们使用的是对象的组合，那么就是说在这个对象里面很有可能会需要访问到父类的东西。这个时候单元测试又是没有办法完成测试。
再看消息的传递  
   我们知道，基于windows 的编程很多时候我们离不开消息，经常我们会Post 或是Send 一个message 给另外一个window。那么这里面就会有两个问题
      1. 另外windows是否也被创建出来
      2.如果创建了，Post message 是不会立即返回的，如何验证正确性
.....
其实在编写单元测试的时候，还碰到很多其他的问题，特别是对于那些编写windows程序的人，这些问题应该怎么解决呢？
期待大家的讨论

哈哈，确实如此。
但是作为spec要详细到函数，这确实是很困难的一件事情。就不要说是函数了，有时候连类的架构都会重构，更不要说是函数了，这样的spech会经常变动，哈哈，是好也是坏。
再说工具
一个工具要想做到精，其实是很困难的，就像jackjackjack说的那样，行业不同，需求不同。
在单元测试这块，我感觉CPPUnit是个不错的东西，他可以支持PlugIn ，这是一个不错的扩充，我们可以通过写一个PlugIn来满足自己的需求，还有另外一个方法也可一满足这中需求，那就是自己写个测试工具。

不错，没有矛盾，没有缺点，没有探索，就没有进步。
但是作为软件工程来讲，他将软件的开发分的过细，企图通过对过程的细分，然后逐层规范。当然这样作并不是不好。
“船小好调头”
这个意思很明显，如果规则制度制定的太多，势必对突发事件相应不及时，而软件这个行业，突发事件（需求的变更，架构的调整...）乃是家常便饭。
Martin Fowler就说过这样的话：一个团队如果光有一个好的架构师和完善的管理流程是不能保证能产出高品质的软件。恰恰，如果团队中的每个成员都是非常优秀的，那么，开发出来的产品品质一定会很高。

这句话跟“船小好调头”显然在部分上有着相同的意思。
所以我想说的是，只要能有效的保证软件的品质，过程，程序，都是次要的。

而且通常我们在软件分工上面，打都都是安功能来划分。可能部分人在做UT 测试，而部分人在 执行 IT 测试。这个我个人认为也是许可的。
当然，以个人为单位来讲，肯定是先UT 后IT 。这个实体还是遵守软件工程的流程。

不错，我不否认CMMI在软件工程方面的会给我们带来很多好处。但是作为一门理论的学科，它的理论来源于实践，是从众多的实践中提升出来的，所以应该是理论不断的靠近实践；当然，实践也应该不断的靠近理论。
那么在一个实际的情况下，如果实践与理论不相付，我们应该拿什么来衡量谁靠近谁呢？

其实原则很简单，谁有效率，我们就会采用谁。

所以说当你的Team 或是项目并不是一开始就按照CMMI 的某个模型来运行，或是运用某个模式发生困难的时候，我们并不能一味的强调“我们没有遵守规则”，而是应该根据实际运行的情况灵活的调整状态，当然，在CMMI中也是这样强调的。
同时在CMMI中也是有强调 人的因素以及技术的因素 在整个软件开发中还是一个很重要的。
特别是在中国，这个尤为突出。

所以我们更多的应该是根据实际的情况来带领我们的Team ，而不是一味的用条条框框来限制我们。

当然，我并不是说不用CMMI，而是说借鉴CMMI的方法。

[ 本帖最后由 ricmy 于 2006-1-24 11:41 编辑 ]

看了，支持一下。但有些还是不太明白。