单元测试的方法其实最主要的是测试用例的生成方法。教科书上的方法与实践中还是有些差距的，实践是“不管白猫黑猫，带住老鼠就是好猫”，实践中一般是先对被测单元的入口参数进行等价类划分、边界值分析以生成测试用例，然后再考虑单元内部的实现逻辑进行覆盖率分析以生成测试用例。
3 过程
在进行单元测试的过程定义与相关的规范定义时应把握一个基本的原则：“先松后严，形成闭环”。即，在推广的初期，要求可以没有必要那么深入，可能是先要求大家做测试用例，然后再要求测试用例个数，再要求的覆盖率等等。但是定义了制度就要检查，要落实，要确保制度的执行。
单元测试是由开发人员自己来进行的，过程的定义要简单，只要把握几个关键点就OK了：
（1）是否写了测试用例？
（2）测试用例是否达到了组织级要求的个数？
（3）测试的缺陷是否记录了？
（4）是否自我分析了缺陷的原因、类型及分布情况？
测试驱动的开发方法提倡在编码之前写测试用例，这种实践可以很好的预防错误，值得尝试。上述的4个关键点中开发人员就不愿意做的是测试缺陷记录，最容易忽略的是缺陷的分析。自己的BUG，自己改，出了错就去修改，不愿意记录下来，认为耽误自己的时间，没有什么用途，如果开发人员自己分析了自己缺陷的原因、类型等分布情况，可以发现自己的弱点，在以后的开发过程中改进之，实现自我的提高。子曰：君子日三省其身。不反省，就不能天天向上。
单元测试和同行评审一样，都是很简单的质量措施，但是推广的时候却会有很多的具体问题和阻力，需要从公司建立起这种文化，让开发人员形成这样的开发习惯，才能充分发挥其作用。
文章来源于领测软件测试网 https://www.ltesting.net/
