1 背景
测试是开发的一个非常重要的方面，可以在很大程度上决定一个应用程序的命运。良好的测试可以在早期捕获导致应用程序崩溃的问题，但较差的测试往往总是导致故障和停机。
单元测试用于测试各个代码组件，并确保代码按照预期的方式工作。单元测试由开发人员编写和执行。大多数情况下，使用JUnit或TestNG之类的测试框架。测试用例通常是在方法级别写入并通过自动化执行。
单元测试不仅仅用来保证当前代码的正确性，更重要的是用来保证代码修复、改进或重构之后的正确性。
2．单元测试定义：
单元测试又称模块测试，是针对程序模块（软件设计的最小单位）来进行正确性校验的测试工作，程序模块在面向对象编程中一般指方法。
3．为什么需要进行单元测试
编写单元测试代码并不是一件容易的事情，那为什么还需要去花费时间和精力来编写单元测试呢？原因如下：
- 减少Bug：如今的项目大多都是多人分模块协同开发，当各个模块集成时再去发现问题，定位和沟通成本是非常高的，通过单元测试来保证各个模块的正确性，可以尽早的发现问题，而不时等到集成时再发现问题。
- 放心重构：如今持续型的项目越来越多，代码不断的在变化和重构，通过单元测试，开发可以放心的修改重构代码，减少改代码时心理负担，提高重构的成功率。
- 改进设计：越是良好设计的代码，一般越容易编写单元测试，多个小的方法的单测一般比大方法（成百上千行代码）的单测代码要简单、要稳定，一个依赖接口的类一般比依赖具体实现的类容易测试，所以在编写单测的过程中，如果发现单测代码非常难写，一般表明被测试的代码包含了太多的依赖或职责，需要反思代码的合理性，进而推进代码设计的优化，形成正向循环。
就个人而言，感受最深的就是，有了单测后重构代码起来心里压力小多了，其次是通过单测减少了很多低级错误。
4．单元测试带来的一些问题
单元测试在解决了一些问题的同时也容易产生一些问题
- 学习成本：单元测试框架的学习需要一定的成本
- 开发成本：项目初期，往往最重要的是快速上线，时间非常紧张，这时容易出现单测代码难以编写，代码经常变化导致单测代码也需要更着同步变化，一定程度上会拖慢项目的进度，可以在项目中后期再补上重要部分的单测代码
- 推广实行：项目中推广单测有一定成本，单纯为了覆盖率的单测是没什么意义的，所以在项目中推广单测时，要考虑到项目成员是否接受单测，能否编写出较好的单测代码，否则单测容易流于形式，达不到理想的效果。
个人经验，在项目中要施行单测，需要做到以下几点：
- 说服领导，给出合理的考核指标（如单测覆盖率等要求，需要结合现状给出合理的指标）
- 提供单测指标统计的大盘，显示项目单测指标，督促大家完成指标
- 对项目结构配置等进行调整，提供单测工具类，基础类，让单测易编写，能运行，速度快
- 对项目组成员进行单测编写方法分享，使成员熟悉单测技术
- 提供单测代码示例，示例要够全面够清晰明了，方便成员参考
- 定时检查成员单测代码，提供改进意见，防止流于形式
5 单元测试用例相关概念
5.1正面测试（Positive Testing）
测试被测对象的正确功能实现无误，即正常流程功能。往往需要根据设计说明进行用例导出，严格按照设计说明编写即可，用例划分注意等价类区分等方法。
5.2负面测试（Negative Testing）
测试被测对象的异常功能实现无误，多在异常流程，异常数据中体现。该部分测试需要对被测对象进行错误发散，常依赖于边界值区分等方法。
5.3分支测试
使用流程图，明确可能出现的每条分支，制造响应的数据进行覆盖，实现对被测对象的测试。这个过程对于分支可以进行响应的简化，可以穿插等价类等方法去除同类分支。
5.4 边界值分析法
这种方法更偏向于黑盒测试用例设计中使用，对被测输入进行边界分析，从各个角度都会有边界值，例如程序内部依赖之间，已经有一些边界存在，在程序集成展示后，也会有新的边界出现，在设计的时候，需要注意这些细节。例如我们可输入范围是3-6，和输入类型为浮点数。那么边界值为7-8之间