一、简介
很多团队都倾向于认为自动化是一种加速软件交付的方式，因为这是团队内部经常能够感知到的瓶颈。但是，如果他们将自己的开发实践过程当作一个整体来深入研究的话，那么他们会得到更好的结果。
二、预防BUGs
测试，尤其是UI层面的自动化测试，通常会被安排在软件交付周期的最末端，通常会试图发现一些可能进入生产环境并给最终用户造成不良影响的bug（这些bug就如同细菌一般）。在这种情况下进行的测试可以探测出bug的症状，开发人员进行的修复就是治疗。这就如同我们在等待我们的系统生病并为此采取一些措施。
这种方法对于团队来说是有一定的效果，但是，现在的工作环境迫使我们用更少的人做更多的事并且要比以往更快地完成任务。因此，这种方法并不能长期可持续地运转。这时基于预防的方法而非治疗的方法就横空出世了。
通过对如何构建系统作出调整，我们就可以在故障发生之前探测出问题，或者更好的是，让他们从一开始就不那么容易产生bug(这就是所谓的“预防”)。这就意味着我们在bug产生前就预防它的发生而非试图在bug产生后再治疗它。古语有云：预防胜于治疗！
三、我们的测试自动化之旅
在我刚开始加入移动团队（该团队负责创建并管理公司的点播产品）时，我们所有的测试都是手工执行的，平均每年我们只在每个平台上发布2到3次。我们知道如果想要加快速度，最明显的瓶颈就是测试。在没有发现新bug的情况下，每个回归测试周期要花费将近两周的时间。如果发现了新bug，那么开发团队需要时间理解并确认bug，确定一个修复方案，然后再应用这个方案。这会导致已经执行的任何测试都变得无效，因此需要重新启动测试过程，最终导致测试周期花费两倍以上的时间。
因此，我们开始着眼于将更多的UI测试进行自动化处理。我们总是从小的方面开始改变看看这样的尝试能否将我们引入我们想要的正确的方向上，并且我们只选择对新功能进行自动化测试。这种尝试一旦被证实是有效的，我们就会将自动化测试引入到现存系统的其他领域或者已知的问题领域。
我们组织3个朋友作为一个团队来理解我们想要构建什么，以及该特性的关键接受标准应该是什么。这为我们提供了一个起点，让我们了解如何分解该特性以及哪些用户场景需要自动化。
......
查看更多精彩内容，请点击下载：
版权声明：本文出自《51测试天地》第五十五期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
