之所以谈到单元测试，是因为在进行系统测试时，在即将结束的时候却发现了很多严重的问题，经过我自己的分析认为是开发人员在进行单元测试时，逻辑的覆盖面不全。

　　在网上可以搜索到很多关于单元测试的资料，但是在这里我还是想在唠叨两句，说说单元测试的思路，其实这是我在学校时老师讲解的，但是到了工作中，有了更深刻的体会，那么接下来直接步入正题吧！

　　1、首先分析实时单元测试的必要性，并且对测试人员进行单元测试的培训

　　针对这一点有人会说，单元测试既然是开发人员来做的，为什么还要给测试人员培训呢，我个人认为在进行单元测试时，开发与测试人员配合协作，有利于测试的进行，测试人员可以尽可能多提供的测试场景，在并且此时测试人员可以根据单元测试的情况，在后续测试中能够更准确的把握测试的重点。

　　2、确定单元测试的范围

　　看到第二点也许也有人会体会出疑问吧，已经进行单元测试了，怎么还有确定范围呢，换个角度想，如果这个项目比较紧张，但是又必须进行单元测试，那么此时只要保证主要逻辑结构争取可以了，再者，如果你新添加的功能只影响到部分逻辑，那么完全没有必要进行全部逻辑的覆盖。

　　3、做完以上两点准备工作，接下来开始进行单元测试

　　a）静态检查、代码交叉走读

　　b）通过单元测试用例进行单元测试

　　其实针对a需要开发人员养成良好的编码习惯了，因为在代码交叉走读这部分，是需要别人阅读自己的代码的，如果某个人的代码写的很不规范，那么别人阅读起来也很耽误时间。

　　而b部分，我们需要先搭建单元测试的环境、编写单元测试用例、执行、根据事先制定好的的单元测试出口准测，进行单元测试报告的撰写。

　　单元测试的简易思想图：

　　单元测试说起来相对容易，但是执行起来却真的很不容易，一是因为工作量大，二是没有意识到单元测试的价值。

　　其实在研发或者开发一个项目时，在初始时应该将整个软件的流程图架构起来，这样在后续迭代增加新功能时，可以通过流程图准确的发现对整个软件的影响程度，但是前提条件要保证流程图设计的正确性。

　　个人认为单元测试是一个不断积累的过程，所有规则的前期执行都是举步维艰的，但是当真正的执行起来后，会发现通过单元测试得到的收益也是大的。

　　以上仅是个人意见，如有错误请大家及时指出！