我们在工作中会听到很多关于测试的名词，如单元测试UT，集成测试Integration Test，端到端测试end-to-end 等等。

　　我认为，大部分人其实都仅仅是有一个模糊的认识。他们并未真正清楚每种测试的含义。

　　当领导强调要做xx测试时，就随意的把概念扔给下属，其实自己都不清楚为什么要做，怎么做。

　　而据我所知，国内大部分公司更是糟糕。每个开发人员都完全投入到写代码中，甚至不愿意花时间写最最最基本的单元测试。

　　同时测试的重要性已经不仅仅是对质量的保证了。在流行敏捷开发的今天，测试已经成为敏捷开发的重要组成部分。

　　因此我们是否真的明白测试的含义。它们的必要性，应该如何定义它们，它们之间有严格的界限吗，每种测试类型适合的工具是什么。

　　这些都是我们必须思考的问题。

　　现在，对常见测试做一个探讨，如果有什么建议或不认同，欢迎拍砖。

　　单元测试 Unit Test

　　单元测试的定义：

　　A unit test is a test written by the programmer to verify that a relatively small piece of code is doing what it is intended to do. They are narrow in scope， they should be easy to write and execute， and their effectiveness depends on what the programmer considers to be useful. The tests are intended for the use of the programmer， they are not directly useful to anybody else， though， if they do their job， testers and users downstream should benefit from seeing less bugs.

　　上面的定义强调了

　　1，UT应由开发人员写，给开发人员使用。

　　2，UT测试的应该是小段代码，目的是开发人员确定源代码做了希望它做的事。

　　再来看看TestNG的作者是如何概括UT的：

　　unit testing (testing a class in isolation of the others)

　　首先他强调了，一个UT case只能针对一个类。不应该在一个UT case中测试一个以上的类。

　　其次一个重点是：一个类的UT必须是完全独立的，不应再和其他部分代码有任何交互。这也是我们要使用Mockito等mock框架的原因，这样在测试代码时，当必须和其他对象交互时，就使用mock对象来保持UT的独立性。

　　此外，UT 可以是自动的，也可以是手动的。

　　单元测试的工具：

　　大家熟知的JUnit，以及TestNG；.net专用的NUnit；VS2010开始直接提供的测试框架。

　　c/c++专用的CppUnit，PHP专用的PHPUnit。

　　Mockito，easyMock等mock框架也是重要组成部分。

　　另外，单元测试有一个覆盖率的问题。就是指一个UT调用了被测试类中多少代码。一个不负责任的程序员写的UT也许只测试了类中的一个方法，而负责的程序员写的UT应该覆盖掉被测试类中所有主要方法。

　　Cobertura是自动检测UT覆盖率并生成报告的一个开源工具。 将这个工具集成到每天的daily build中是一种很好的做法。

　　要求覆盖率要达到100%是无理且无意义的，通常80~90%就行了。原因有两点：

　　1，是否UT必须覆盖所有的代码？

　　让我们来看看JUnit官网的回答：

　　No， just test everything that could reasonably break.

　　Be practical and maximize your testing investment. Remember that investments in testing are equal investments in design. If defects aren't being reported and your design responds well to change， then you're probably testing enough. If you're spending a lot of time fixing defects and your design is difficult to grow， you should write more tests.

　　If something is difficult to test， it's usually an opportunity for a design improvement. Look to improve the design so that it's easier to test， and by doing so a better design will usually emerge.