为什么需要单元测试?
　　彻底测试：仅依靠系统测试会存在大量未覆盖的“死角”，单元测试可以实现代码级彻底测试，从根本上保证代码质量。
　　成本低：排错成本随时间推移和范围扩大直线上升，单元测试是早阶段的测试，且目标小，因此，排错成本低。
　　自动回归：单元测试将代码功能“定格”，代码修改后自动检查是否引入新的错误，避免陷入“系统测试->修改->引入新的错误->新一轮系统测试->修改->引入新的错误”的怪圈。自动回归也使开发过程适应频繁变更的需求，使开发过程自动“敏捷”。
　　促进开发：利用单元测试还可以实现测试驱动开发和可视编程。可视编程使开发过程中程序行为可视，大幅提升开发效率、降低劳动强度。
　　什么是单元测试?
　　单元测试是针对代码单元的独立测试。从实用角度出发，“单元”是指函数，以类为单元则过于复杂。“独立”是指将代码从原始项目中隔离出来，针对各个单元单独进行测试。
　　单元测试的基本方法是?
　　根据程序功能设定输入、执行测试、自动判断输出是否符合预期。测试过程需要以下关键元素：驱动(用于执行测试的代码)、用例(输入及预期输出)、桩(用于隔离耦合代码、或代替未实现代码)。
　　企业项目的单元测试面临哪些难点?
　　测试简单独立的代码是很容易的，测试复杂项目则是另一回事。企业项目的单元测试面临以下难点：可测性问题、失真、不可控、静态局部变量的外部控制、内部输出的自动判断、复杂间接输入难于初始化、白盒覆盖逾后逾难等等。不解决这些难题。测试将无法进行，后面的条目将进一步阐述。
　　单元测试的具体目标是?
　　单元测试是针对代码单元的独立测试，“独立”状态下易于发现的错误，都是单元测试的目标;集成后才易于发现的问题，则不是单元测试的目标。
　　代码单元本身的功能错误都是单元测试的目标，而性能问题(时间性能如执行速度，空间性能如存储空间大小、内存泄漏)难于在小单元内测试，不是单元测试目标。
　　编码规范检查与单元测试无关，无论是否实施单元测试，编码规范检查都是必不可少的工作。
　　静态分析属于全局扫描，严格来说也不是单元测试，提高编译器的警告级别，是简单高效的静态分析。
　　单元测试是意义重大且困难的工作，目标应该具体而明确，将不属于单元测试的工作牵扯进来，其结果往往是“拣了芝麻，丢了西瓜”。
　　选择工具时不要被“功能多多”所迷惑，要首先检查工具能否解决企业项目单元测试的难点，并用实际项目评估。“多”和“精”从来是一对矛盾，要判断工具是不是因为无法解决单元测试的难题，故意把其他东西牵扯进来转移视线。
　　什么是测试用例?
　　测试用例是程序功能的实例，对于单元测试来说，把函数功能明确化、实例化，用什么输入应该产生什么输出的形式记录下来，是测试用例。
　　如何设计用例?
　　根据功能点设定输入，再根据设计功能设定预期的正确输出，这样构成了一个测试用例。
　　通常，一个功能点对应一个等价类，“等价”是指测试效果上的等价，等价类中可能存在一个、多个或无数个值，取其中任何一个，如果测试通过，表示同类中所有值都会测试通过。
　　所谓“彻底测试”，是指等价类划分正确且完整，且设定了正确的预期输出，做到了这一点，代码可以保证不存在功能错误。
　　什么是测试驱动开发(TDD)?
　　首先编写测试代码，然后编写产品代码，使编译和测试通过。
　　优点：编写测试代码是一种设计行为，将程序功能细化、明确化;编程时目标具体而明确，避免多余动作;强制实施单元测试，避免编码后忽略测试。
　　缺点：手工编写测试代码，比较费时;过于强调测试，很多代码是不需测试的，且往往在编写实现时才知道是否有必要测试;对编程过程的帮助不足，很多函数，都是在代码基本完成时，主要用例才能通过，在此过程中，TDD不能提供帮助;改变思维习惯，有些程序员难于接受。