软件测试中自动化单元测试要点
1. 改进产品质量
软件测试，很多时候围绕着两个问题：
Verification和Validation，常说的双V。前面的Verification就是Is the software built correctly?。后面的Validation就是Have we built the right software?
单元测试，更多的是Verification。所以有时候经过我单元测试和集成测试以后的功能模块，在交给其他同事做功能测试的时候，依然会有一些BUG，这时候开发可能会埋怨我测试得不够完全，诸如此类。但是其实很多时候，我的关注点是单个方法的功能、行为，没有站到更高的位置来测试这个模块。对于这样的问题，开发和测试应该互相体谅，我本人也会提高自身的水平。希望在单元测试和集成测试中也加入更多关于Validation的思考。
有一个提法叫Tests as Specification，单元测试本身其实就是模拟某个模块的使用者（其他的程序）来进行测试。很多时候我写的测试代码也是其他开发人员的参考，尤其在一些事实上或者只是号称自己是敏捷开发的组织里面，测试代码有可能成为详细设计的替代品，因为有可能根本没有详细设计文档。
单元测试的另一个工作就是发现并且定位BUG。对于BUG的定位和重现，在单元测试代码的编写过程中，每个Assert语句后面都要加上尽可能详细的信息，例如导致这个Assert语句失败的每个参数值，期望结果，实际结果等，这些信息可以帮助开发和测试快速定位问题，减少不必要的DEBUG时间。
2. 降低项目的风险
软件测试，其实是用有限来验证无限的一个过程，很多时候做什么样的测试，做到什么样的程度，很多时候都跟风险有关系。
作为产品的安全网，各种测试在项目中都扮演着重要的角色。例如，中美交互的几十个Web Service接口的回归测试，现在有若干个测试，每天定时做回归测试，因为没人知道在美国的服务器会发生什么事情；对于中国的Web Service，在上线前都会通过回归测试，才部署上线。还有全站的Platform Service接口，每次上线前都需要在做回归测试。软件测试的另一个有趣的结论就是：测试只能证明软件有BUG，但是无论什么样的测试，都不能证明被测软件是没有BUG的。问题出来了，我做完回归测试，都通过了，但是我却不能证明这个软件是没有BUG的。其实每次上线，团队都承担着风险，只不过这样的风险在完成回归测试之后，大家上线的信心增加，风险明显地减小。
什么样的测试才是好的测试？
1. 容易运行
什么样的单元测试是容易运行？答案很简单，自动化的单元测试就是容易运行的测试。如果一批测试在运行之前每次都需要重装系统然后还要找一大堆需要依赖的软件来装上，最后还要输入奇怪的命令才能运行，那么就不是一个好的测试（本人真的见过这样的测试，囧）。个人认为，配置好的持续集成系统，可以实现很好的自动化测试；如果没有一个完善的CI，那么一个one click的自动化测试运行也是一个较好的选择。
2. 自动检查结果
一句话：没有自动检查结果，再好的自动化也是白搭。
3. 可重复
一句话：只能运行一次的单元测试也是白搭。
4. 独立
其实测试的独立，也有利于实现可重复。刚做单元测试的时候，曾经犯过这样的错误，我在写A测试的时候，给数据库插入了一条记录，然后我在写B测试的时候，就觉得我为什么要在两个测试中分别创建两条数据？直接用上一个测试的数据就可以了。不过结果还好，我很快就发现这样做是有问题。单元测试的独立，就是运行测试的人可以先运行A测试，也可以先运行B测试，也可以单独运行A或者B测试，甚至可以A和B测试同时运行。
5. 简单
有时候，测试的代码写的有点复杂，嵌套的语句有点多，可能有些人会觉得写出复杂的单元测试代码才能体现自己的水平，但是，我觉得对于单元测试代码来说，应该越简单越好。最好就是顺序执行下来了，不要有什么分支。因为测试代码本身就是也是代码，那么怎么去验证测试代码写的正确呢？答案可能是再写一个测试代码去验证第一个测试代码。这样就会有死循环了。一个简单的假设就是，如果测试代码足够简单，那么就可以认为测试代码是正确的，无需其他代码对之进行测试。
6. 专注
一个测试应该只测试一个点。如果在一个测试里面验证多个测试点，看起来是比较高效的一种做法，但是当测试中有Assert语句抛出异常的时候，很有可能需要花大量的时间才能找到真正错误的代码，这样不利于实现前面提及到的“定位BUG”。
7. 注释
注释其实就是把代码抽取成可阅读的测试用例，如果别人看自己的程序，可以快速理解测试代码；同时注释还能唤醒自己沉睡的记忆和当时的测试思路。
国内做单元测试的测试工程师少，做集成测试、接口测试的也不多，埋头做事,别忘抬头看路。时常总结，提高自我。
文章来源于领测软件测试网 https://www.ltesting.net/
