单元测试通常不测试很简单的代码，一般也不测试“边界代码”。很简单的代码容易理解，例如Get/Set函数，这里解释一下“边界代码”。“边界代码”是指用于与外部系统交互的代码，例如用于处理用户界面的代码。数据库、文件、网络都可以看作是外部系统，用于读写数据库或文件、或访问网络的代码也可以看作是“边界代码”，这类代码应该独立出来，可以进行单元测试，但对这些代码的单元测试通常不能自动验证预期输出，而是需要人工察看。编程时，不要把普通代码与“边界代码”混在一起，例如，不要把各种运算直接写在界面类中，做到了这一点，绝大多数代码都可以进行单元测试。
实际工作中，单元测试能实现什么程度的测试覆盖?
单元测试的最低要求是100%语句覆盖，这个覆盖率还是不够的，最好实现多种覆盖的组合，比较理想的覆盖率组合是：100%的语句、条件、分支、路径覆盖，另外，测试工具最好还能自动生成边界测试用例捕捉未处理特殊输入形成的错误。在达到这种覆盖之后，残留的编码错误可以几乎说没有了(设计方面的错误除外，这些属于集成或系统测试的范畴)。
单元测试如何改良项目代码的整体结构?
具有良好整体结构的代码，应该符合“低耦合”的特性，即具有“可测性”。测试不具有“可测性”的代码时一般会产生编译错误，或者需要打桩才能测试，从而将问题暴露出来。发现问题后，重构代码、消除不当耦合一般不难，这种简单的重构将有效地改良代码的整体结构。
我希望依赖全自动的工具来完成单元测试，这一想法现实吗?
完全自动化是一个美妙的愿望，但由于单元测试的基本特性，完全自动化的单元测试是不现实的。
与其他不同，单元测试是“隔离”的测试，要求代码具有可测性，一个项目甚至一个文件中，难免会有一些影响可测性的代码，编译到这些代码时常常会产生编译错误，因此，全自动的单元测试工具往往只能测试小部分代码，即使使用某种技术手段屏蔽掉编译错误，也得不偿失，因为同时也屏蔽掉了改良代码整体结构的宝贵机会。如果采用自底向上的方式，一个一个文件测试，测试一个文件前，先将该文件加入测试工程并编译，没有编译错误时再测试，这样可以及时发现并消除不当耦合，使代码具有可测性，这种非全自动的方式，可以测试绝大多数代码，也保证了代码具有良好的整体结构。
另一方面，主要由测试工具自动生成测试用例来进行测试往往没有实际意义，因为测试工具无法自动了解程序的功能，因此，自动测试用例通常只能发现异常之类的极端错误，大多数一般错误都是无法发现的。测试工具最重要的不是自动生成测试用例，而是能提供快速建立和编辑测试用例的工具。
如果由开发部门实施单元测试，那么测试部门要做哪些工作?
●推动、组织单元测试的实施。单元测试既然叫做“测试”，开发部门常常认识不到其重要性和必要性，需要由测试部门推动和协助组织实施。
●制定单元测试规范，培训单元测试技术。
●检查、审核单元测试结果，保证单元测试的有效性。
文章来源于领测软件测试网 https://www.ltesting.net/
