有没有老板一提到“单元测试”就胆颤心惊，谈虎色变？
单元测试位于测试金字塔的最底层，而越向上反馈的时间越长，实现的成本也越高；且素有“单元测试能发现约80%的缺陷”的业界说法。
然而，在国内大部分的公司都不要求，或者难以要求，以至于工作了很多年的程序员都不知道如何去写一个正确的单元测试，更不要提手工点点点占了大部分精力的测试员了。
主流声音“单元测试是程序员的事，测试不需要关心！”成为测试员的挡箭牌。然而，现在更有一种声音“测试左移”（左移的核心思想是尽量让测试团队尽早接入软件项目的测试，并扩展测试内容项，达到提前把缺陷消灭在萌芽阶段的目的，具体看《软件测试左移、右移和DevOps小结》一文）。那作为测试金字塔最底层的单元测试，测试员该怎么介入？能做什么呢？
当然，你会在网上看到很多文章告诉你如何使用Junit、Nunit、TestNG等等，然后告诉你这就是单元测试。让绝大部分连看懂代码都困难的测试员一脸懵逼。MMP，看得追瞌睡了~
不要装逼了，看下我们测试切实能做的：
code review与代码检查是两种主要的人工测试方法。
code review
code review，即代码评审。
是指在软件开发过程中，对源代码的系统性检查；是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等。
要做好code review，要注意：
1、代码审查要求团队有良好的文化；
2、谨慎的使用审查中问题的发现率作为考评标准；
3、控制每次审查的代码数量；
4、带着问题去进行审查；
5、所有的问题和修改，必须由原作者进行确认；
6、利用代码审查激活个体“能动性”；
7、在非正式，轻松的环境下进行代码审查；
8、提交代码前自我审查，添加对代码的说明；
9、实现中记录笔记可以很好的提高问题发现率；
10、使用好的工具进行轻量级的代码审查。
推荐一些 Code Review 工具：
- Crucible：Atlassian 内部代码审查工具；
- Gerrit：Google 开源的 git 代码审查工具；
- GitHub：程序员应该很熟悉了，上面的“Pull Request”在代码审查这里很好用；
- LGTM：可用于 GitHub 和 Bitbucket 的 PR 代码安全漏洞和代码质量审查辅助工具；
- Phabricator：Facebook 开源的 git/mercurial/svn 代码审查工具；
- PullRequest：GitHub pull requests 代码审查辅助工具；
- Pull Reminders：GitHub 上有 PR 需要你审核，该插件自动通过 Slack 提醒你；
- Reviewable：基于 GitHub pull requests 的代码审查辅助工具；
- Sider：GitHub 自动代码审查辅助工具；
- Upsource：JetBrain 内部部署的 git/mercurial/perforce/svn 代码审查工具。
代码检查
所谓代码检查，是以组为单位阅读代码，它是一些列规程和错误检查技术的集合。对代码检查的大多数讨论都集中在规程、所要填写的表格等。
代码检查要求人们组成一个小组来阅读或直观检查特定的程序。准备工作的高潮——“头脑风暴会”的目标是找出错误来，但不必找出改正错误的方法。
一个代码检查小组通常由四人组成，其中一个发挥着协调作用。协调人应该是个称职的程序员，但不应该是程序的编码人员，不需要对程序的细节了解的很清楚。协调人的职责包括以下几点：
- 为代码检查分发材料、安排进程；
- 在代码检查中起主导作用；
- 记录发现的所有错误；
- 确保所有错误随后得到改正。
小组的其他成员通常是程序的设计人员（如果设计人员不同于编码人员的话），以及一名资深测试员（到底要多资深？测试理论扎实，起码看代码无压力）。
在检查进行时，主要进行两项活动：
- 由程序编码人员逐条语句讲述程序的逻辑结构。
- 对着历来常见的编码错误列表分析程序。
在代码检查的时间和地点的选择上，应该避免所有的外部干扰。理想时间90~120分钟。大多数代码检查都是按每小时大约阅读150行代码的速度进行。大型软件的检查应安排多个代码检查会议同时进行，每个代码检查会议处理一个或几个模块或子程序。代码检查的目标是发现程序中的错误，从而改进软件的质量。建议对代码检查的结果保密，仅限于参与者范围内部。