摘要： 持续交付涉及到软件开发从需求到上线、运维全生命周期的各个活动。其中很重要的一个活动是测试。如果没有自动化测试，整个交付的节奏会慢下来。接下来我们来聊一聊这背后的逻辑和如何才能把它做好。 软件开发中的自动化测试可以粗略的分为自动化单元测试和自动化功能测试。二者有很多的相似之处，但同样也有很多不同
　　持续交付涉及到软件开发从需求到上线、运维全生命周期的各个活动。其中很重要的一个活动是测试。如果没有自动化测试，整个交付的节奏会慢下来。接下来我们来聊一聊这背后的逻辑和如何才能把它做好。
　　软件开发中的自动化测试可以粗略的分为自动化单元测试和自动化功能测试。二者有很多的相似之处，但同样也有很多不同的关注点。本文主要关注的是 自动化功能测试 。
　　为什么要做自动化测试
　　如果你的软件是Web形态的，则用户可以通过浏览器来使用你的软件；如果你的软件是手机游戏，则用户需要有一台手机才能使用你的软件。而 功能测试 ，顾名思义，测的是这些用户能够看到并使用的功能。
　　其实大多数软件开发流程都有功能测试这个环节。比如在传统的瀑布模式中，每次发布之前都需要进行一轮或者多轮的回归测试，以保证软件功能正确。在这种模式下，**手动的功能测试** 是全部的测试活动。这些测试起到了防护网的作用，保证在发布前能够找到大部分的bug，并修复之。听起来不错，那为什么我们还是需要自动化的功能测试呢？
　　强哥的故事
　　让我们回到开发人员的视角来看看强哥的故事。强哥所在的团队使用迭代开发，每个功能开发完成之后，会让测试人员及时进行测试，每个月会进行一次发布。
　　作为一个有节操的开发人员，秉承为自己的代码负责的原则，强哥喜欢对自己所开发的功能进行细致的分析、开发和测试。这不，手上接了一个活，经过一番分析，梳理出了8个case：
　　花了一个小时完成了case 1，进行了一番完备的测试。又过了一个小时，case 2也完成了。强哥把case 1和case 2都再测试一遍。如此反复，等完成case 5的时候，自然需要从1到5都测试一遍。
　　这时候强哥心里有点犯嘀咕了：“case 1测了好几遍了，都的有点想吐了，而且case 5修改的代码其实跟case 1不是特别相关，要不先不测了，等到后功能完成的时候在一起测试一遍吧”。于是在没有回归测试的前提下强哥完成了5、6、7、8这些case，而这时距离刚开始做这个功能已经过去两天了。
　　“终于做完了”，强哥长吁了一口气，“整体测一下吧”。不测不要紧，一测发现case 1、3，7都通不过了。
　　“还好又进行了测试”，强哥得意地想着，然后着手开始修复这些问题。经过一番艰苦卓绝的debug，终于定位了问题，并全部修复。这些工作又花掉了强哥3个小时。但强哥觉得这都是值得的，然后带着程序员的骄傲把功能交付给了测试人员。强哥考虑到的这些场景经过测试人员的测试，没有任何问题，一次通过。只是还有两个异常场景强哥没有考虑到，所以又回过头来修复了一下，这次倒是很快，10分钟修好了。不过为了保险起见，强哥还是把所有的场景又回归了一遍。幸好，没什么问题，然后又提交给了测试人员。这次再没有什么问题了，通过！
　　这样，强哥带着程序员的骄傲一次次高质量地完成了手里的工作。然后来到了迭代末尾，距离强哥完成上面那个功能已经过去三周了。要进行发布了，回归测试肯定还是要做的。第一轮结束后，发现了几个问题，其实一个竟然出现在强哥开发的功能中。“这个case我可是精心测过的，还测了好几遍，怎么挂了？”，强哥很不高兴。其他的开发同事跟强哥说：“别人做功能的时候，不可避免会影响已有的功能嘛，这都是正常现象，不然要回归测试干嘛呢？”
　　他说的好有道理，强哥一时竟无法反驳。在进行某一个小功能的开发时，可以在每次修改之后，都把这个功能所涵盖的case都回归一遍，但当这个功能提交给测试以后呢？别人在同一个代码库中做了某些修改，是不会对你的功能再进行一遍测试的。且不说别人都不知道你做了什么功能，算知道，也不可能把所有的功能都再测试一遍呀，那要花多少时间呢？
　　修好这个问题之后，带着无奈和不甘心，强哥查了一下是哪次提交破坏了他的功能。让他惊讶的是，在他完成那个功能的两天后，也是将近三周前，这个功能坏掉了。强哥心里很不舒服。。。
　　自动化拯救世界
　　强哥所开发的软件是Web应用。后来强哥在一篇文章中知道了Selenium可以用来做浏览器的自动化测试。感觉豁然开朗：“如果我做的功能都能够用这个自动化测试来覆盖，那之前的那些问题大概都能解决了吧”。
　　· 每次做完一个小功能时，补充一个自动化测试。后面每加一个功能只需要运行一遍这个不断增加的测试集即可。
　　· 这些测试不光可以在我开发一个功能的时候帮我去运行这些重复性的验证，别人也可以在做完修改之后运行这些测试，以保证他没有破坏已有的功能。
　　· 有了这些测试的保证，发布前的回归也会快的多。
　　为什么不做自动化测试？
　　听起来做自动化功能测试真的是一件很美好的事情，但实际上做的人并不多。那都是什么原因呢？
　　初始投入
　　做自动化测试的技术门槛不算高，但一开始还是需要一些投入。其中包括工具的学习和使用，基础框架的搭建、相关CI任务的搭建等。于是很多人都是这种状态：
　　持续的投入
　　测试本身也是以代码的形式存在的，是代码会腐化。于是编写测试也会变成一件成本越来越高的事情。另一方面，测试的有效性也很关键。比如如果一个用例声称会覆盖功能A，但是功能A出问题时，测试竟然没报错；或者当一个测试失败10次，其中有5次是因为测试环境出错、测试代码本身不稳定造成的，那估计团队也会越来越不想做写自动化测试了。