楼主太厉害了
楼主对测试有深刻的认识看来，谢谢sdlkfj2 很详细,顶下,好贴哦！
你能再帮我找些有关C或C++的测试用例吗？谢谢！ sdlkfj3 好帖子顶顶学习了
谢谢。GOOD 我什么时候能这样呢! 不用下载，很好，保存了以后看。多谢回复 #1 sincky 的帖子
很长，但是看完了，好文章。 很好，刚好用上 看了，觉得还是有点点收获的～ 学习 写得非常不错，只是学生想对老是提出两个小问题：1由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。
UT到底该由程序员完成还是测试员完成，这只能说是互有利弊。如果是程序员，那很有可能会按照自己的习惯思维去测试，而很难全面的找出BUG；如果是测试员，虽能够比之程序员找出更多的BUG，但没有程序员的参与，往往无法高效的完成工作。所以我的建议是，应该由双方同事参与完成。
2关于桩代码，老纳认为，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，
在实际过程中，你往往需要编写驱动函数和桩函数，这是无法避免的，我们应该结合实际情况而决定对中间层的定位。
sdlkfj2 to liulinzhu (猪哥) :
您说得太对了。我是这篇文章的作者，这文章写于差不多两年前，当时对解决可测性难题没有好的办法，并且由于在实际工作中，感觉编写桩代码太费时了，如果由工具生成空桩，又可能导致程序的行为完全不同而使测试没有意义，所以主张由程序员实施单元测试，由底向上开发，避免编写桩代码。这些主张在不是很大的项目中，还是可行的，因为我所写的，都是经过自己实践的。但对于大型团队大型项目来说，则不现实，这一年多，我接触了一些大公司的大项目，很多认识已经完全不同了。希望有机会好好聊聊。
回复 #38 VisualUnit 的帖子
太看得起我啦，在测试行业你都老一辈的人了，我只是个新手而已，应该向你多多请教，多多学习啊！ 我在单元测试上也是个新手，前些日子对一些项目进行单元测试的尝试，个人认为单元测试还是可行的。但是单元测试不可过分依赖于工具，最重要的还是靠自己的双手!我所进行的单元测试项目是C#开发的，由于项目架构得还不错，当然也是一个小型的专业应用软件了，整个项目里面产生了3个DLL，以及一些自定义的插件，当然还有一些继承于FORM的窗体代码了。经过测试，我认为单元测试并不需要对每一个.cs文件都去测，至少可以这样来区分：DLL文件是要测的，里面几乎都是精华，控件也是需要测试的，这样可以减轻功能测试(其实我更乐意把它叫做“集成测试”)的负担，也利于及早发现功能性问题。而继承于FORM的代码我建议不要拿来做单元测试，放到功能测试中去做更为适合。
说实在的，基于一些原因，我并不能持久地开展测试工作，看法有误的地方还请各位看客读者手下留鸡蛋。。
其实测试人员做单元测试并不是十分的难，至少起步并不十分的难，但是要深入进去那就。。。至少懂得编码是必不可少的。
最后，还有一点儿要说给初入行的兄弟姐妹，搞测试的不要只埋着攻功能测试，而忽略了编码能力的提升，因为我们做测试的，不要过多指望在你测试之前所有的文档、资料、程序都是一切就绪的，项目往往很赶时间，所以过地苛求别人提供文档、资料的，并不那么现实，自己能读懂代码，摸清功能我认为是更好不过的了。
