单元测试

到底单元测试是做什么用的？

        所谓的测试，产品质量保证的手段之一。我按照需求规格说明书制造了一件产品，那么谁来确保这个产品符合了需求规格的要求呢？就是测试。它会根据需求规格说明书设计一系列的场景和用例，来对产品进行测试，看看产品是不是真的符合所期望的需求。要达到这个目标，其实并不十分的容易，因为一个真正的系统，情况十分复杂，里面充满了数不清的分支、异常、边界条件，甚至运行环境，将这些东西组合起来，产生的需要测试的点将会是一个天文数字，在有限的时间内做完一个充分而可靠的测试，是不可能的。           为了将充分测试变得可能，一个比较好的途径就是分层测试。在做运行测试或性能测试的时候，有一个前提，就是假设整个系统的集成运行已经没有问题了，将不再考虑“系统无法正常运行”这种场景。那么如何保证集成运行没问题呢？我们用集成测试来检验。但是在做集成测试的时候，我们同样要基于一个假定，就是各个模块的功能都能够如期正常工作。而这一点，又是通过模块自身的功能测试来完成的。……这样一层层往下推，每个层次就假设它所依赖的层次没有问题，这样就可以减少很多场景以及由这些场景引出的额外的分支。将原先一个几何级数的测试用例分解成可以接受的若干层次的算术级数的用例。这样一来测试就变得有可能做好了。           而单元测试，正是这些测试的最低层次——保证每个函数/方法，或者说最小功能模块的正确性的一种测试。      1. 单元测试是一种测试，它不是代码的一部分；      2. 单元测试是最低层级的测试，它只保证函数的可靠性，不保证其它；      3. 单元测试应该能保证每一个函数的可靠性。

单元测试的内容是什么？

一般，单元测试包括两个部分：   （1）接口测试（实际上属于功能或黑盒测试）   （2）内部逻辑测试。需要根据内部逻辑，选择适当的覆盖率（如语句覆盖率、条件覆盖率、分支覆盖率等）。选择的覆盖率越精确，测试的成本和周期就越大。

单元测试怎么写？

对于测试代码的编写，我们的重点应该是：          1、如何搭建测试环境、测试场景；          2、如何选择测试用例；          3、如何校验测试结果。   对于测试代码本身，应该尽可能的简单，能不要使用技巧尽量不要使用，我们的目的在于测试，如果测试本身过于复杂，我们不能保证测试的正确性，测试这个工作就白做了。测试必须是以函数为单位的。每个函数应该拥有自己单独的一个测试。

何时编写单元测试？

        “在你编写一个方法之前或是之后编写单元测试，只要你在编写代码的几乎同时就考虑并编写单元测试程序，那么这就无关紧要了为什么我喜欢把单元测试放在最开始的位置?很简单!我的实践经验告诉我，那样可以帮助提高代码的质量，并且节约调试时间。在开始时写十个小的单元测试所花的时间比在以后修复Bug所花的时间要少，如果代码经过了正确的单元测试，那就不会有Bug了。根据我的经验，当人们在编写完程序之后才开始编写单元测试，就如同事后才有这样的想法，他们很难写出这些测试了(‘我已经完成了所有的代码，此时我还得去写单元测试’)。或者根本就不去做。在这种情况下，代码是否完成了呢?如果代码运行地很好，那就算是完成了。这样的话，再写单元测试就大大地丧失了它的价值。还不仅如此，事后编写的单元测试将是肤浅的，不会对代码进行良好地测试。或者，开发者已经耗完了时间，他们根本就不想再为单元测试伤神了。” John Ferguson Smart。

谁来写单元测试？

        测试是一种针对需求的验证工作。绝大部分时候，单元测试的编写，是由开发人员做的。如果这个需求非常清晰，清晰到开发人员之外的人都可以轻易掌握，这时单元测试可以由独立的测试人员完成。但是大部分情况下对于函数级别，做不到这一点。这时最清楚函数需求的人就是开发人员本人，在这种情况下当然就应该是开发人员自己编写测试用例。但是开发人员必须搞清楚自己身兼两个不同的角色：运动员（实现代码）和裁判员（检验代码），在编写测试用例的时候绝不能假定任何函数的实现，而应该完全按照它应该有的需求来做。这样才能做好单元测试这件事。很多时候单元测试形同虚设，就是因为开发人员没有很好的转换自己的角色造成的。          相关文章： http://baike.baidu.com/view/106237.htm