今天之所以谈到单元测试，是因为在进行系统测试时，在即将结束的时候却发现了很多严重的问题，经过我自己的分析认为是开发人员在进行单元测试时，逻辑的覆盖面不全。
在网上可以搜索到很多关于单元测试的资料，但是在这里我还是想在唠叨两句，说说单元测试的思路，其实这是我在学校时老师讲解的，但是到了工作中，有了更深刻的体会，那么接下来直接步入正题吧！
1、首先分析实时单元测试的必要性，并且对测试人员进行单元测试的培训
针对这一点有人会说，单元测试既然是开发人员来做的，为什么还要给测试人员培训呢，我个人认为在进行单元测试时，开发与测试人员配合协作，有利于测试的进行，测试人员可以尽可能多提供的测试场景，在并且此时测试人员可以根据单元测试的情况，在后续测试中能够更准确的把握测试的重点。
2、确定单元测试的范围
看到第二点也许也有人会体会出疑问吧，已经进行单元测试了，怎么还有确定范围呢，换个角度想，如果这个项目比较紧张，但是又必须进行单元测试，那么此时只要保证主要逻辑结构争取就可以了，再者，如果你新添加的功能只影响到部分逻辑，那么就完全没有必要进行全部逻辑的覆盖。
3、做完以上两点准备工作，接下来就开始进行单元测试
a）静态检查、代码交叉走读
b）通过单元测试用例进行单元测试
其实针对a就需要开发人员养成良好的编码习惯了，因为在代码交叉走读这部分，是需要别人阅读自己的代码的，如果某个人的代码写的很不规范，那么别人阅读起来也很耽误时间。
而b部分，我们需要先搭建单元测试的环境、编写单元测试用例、执行、根据事先制定好的的单元测试出口准测，进行单元测试报告的撰写。
单元测试的简易思想图：
单元测试说起来相对容易，但是执行起来却真的很不容易，一是因为工作量大，二是没有意识到单元测试的价值。
其实在研发或者开发一个项目时，在最初始时应该将整个软件的流程图架构起来，这样在后续迭代增加新功能时，可以通过流程图准确的发现对整个软件的影响程度，但是前提条件要保证流程图设计的正确性。
个人认为单元测试是一个不断积累的过程，所有规则的前期执行都是举步维艰的，但是当真正的执行起来后，会发现通过单元测试得到的收益也是最大的。
以上仅是个人意见，如有错误请大家及时指出！
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/