此文为原创文章，转载请注明作者及原出处
这是一个老生常谈的话题，如果你打开这篇文章，说明你正困惑于“如何开展自动化”这类问题。相信目前测试业内普遍认同"自动化并不是银弹"的说法。也就是说自动化并不能完美的解决测试的所有问题，但很多公司又都在搞自动化，说明开展自动化是需要具备一定条件的。
适不适合开展自动化测试
开展自动化测试之前，你第一个要问自己的问题就是"我们的团队适不适合开展自动化测试?"。并不是公司老板说我们需要开展自动化测试来提高工作效率，节约公司成本，就匆匆忙忙的开始进行自动化测试。你至少应该从以下几个方面考虑是否适合开展自动化测试:
公司及业务的规模
一般说来,自动化测试是大公司才能玩得转的游戏。因为在这些公司，开发流程相对比较严谨和完善，有专门的自动化测试团队来实施自动化;同时也因为规模大，可以使自动化测试形成规模优势，从而降低成本，提高效率
项目的规模和性质
并不是所有项目都适合进行，一些短平快的项目不适合自动化测试,一些需求长期变动频繁的项目也不适合自动化测试，只有迭代周期长且需求变动平稳的项目才适合自动化测试.
做好ROI(投资回报率)
做工作干事业，我们总是会考虑投入和产生的问题,自动化测试自然也例外。简单的概括,自动化测试的ROI可以用如下公式来计算:
ROI=(手工测试成本-自动化测试成本)/自动化测试成本*100%
比如：现在有100条测试用例,设计这些用例需要耗费3天时间,执行一次需要耗费1天时间,那么以1月执行5次为例，
那么一个月手工测试成本为3+1*5=8人日，而自动化测试100条用例设计需要7天，执行一次需要耗费2小时,
但由于业务需求更改，每次需要花费半天进行脚本调整，那么一个月的自动化测试成本为7+0.5*5=9.5人日
由此可见,只有在需求尽量少变更（减少维护成本），且需要多进行自动化测试的情况下,自动化测试才会有比较高的回报率.
测试团队的技术水平
虽然目前自动化测试框架的成熟度已经很高，但依然需要测试人员具备一定的开发能力。如果在技术储备不足的情况下开展自动化测试，成功的几率很低。
业务需求变动频繁
关于这点,几乎已经是业界内的共识。对变更很频繁的功能进行自动化测试，结局几乎都是灾难性的。测试人员往往陷入到自动化测试用例维护的漩涡中,结果就是自动化测试没有起到应有的作用，手工测试也被耽误了。
持续集成的项目
目前越来越多的团队实施了敏捷开发模式，敏捷开发中比较重要的观点就是持续集成。由于持续集成的持续性和即时性，所以非常需要自动化测试来持续的，及时的反馈测试的结果。
节制且有策略的实施自动化测试
很多公司都曾经开展过自动化测试，但取得成效的确很少。其中一个很重要的原因就是缺乏策略性，仓促的就开展自动化,甚至把自动化测试作为KPI来考核，结果大家都一窝蜂的编写自动化测试用例，KPI是漂亮了，但开展自动化测试对实际工作效率和效果的改善确没有尽如人意。其实，开展自动化测试应该一步一步来。先拿一个项目，甚至一个模块来做实践，"实践是检验真理的唯一标准",那么花费最小的代价来实践出真理就是最好的结果。通过实践，你总是会得到“自动化测试适不适合你们公司”,“如何更好的开展自动化测试”这些问题的答案。而且通过最佳实践，你也更有底气的在项目，甚至公司里广泛的开展自动化测试。![timg.jpg]
要选择合适的自动化测试
大家对上面这幅图都应该很熟悉，测试金字塔揭示了进行测试的优先级。如果你们公司需要开展自动化测试，那么如上图所示，从单元测试开始是最好的选择。但单元测试是否实施以及如何实施的主动权往往在开发的手里。所以开展自动化测试的最佳选择往往是API测试(接口测试)。尤其是在现在越来越盛行基于服务的开发以及前后端分离，给接口测试实施自动化带来了极大的便利。对于UI自动化测试,虽然关于UI自动化测试讨论以及相关技术和框架都比较多，但实施的效果往往都不尽如人意。
你可能需要一个自己的框架
我们需要自己的框架并不是为了显示自己逼格高，而是当自动化测试规模到了一定的规模，维护自己的框架才会使你的自动化测试更好的进行。你也不必自己从头开始造轮子，在现有的测试框架上实现适合自己公司的功能就可以。比如说，使用Junit驱动API测试用例的执行，那么你可能需要一个平台来管理你目前的用例，批量执行测试以及测试报告的查看。
结束语
自动化测试,你是否值得拥有，我想答案是肯定的。但如何拥有，确有很长的一段路要走。如何结合技术与实践总结出适合工作的最佳方案是最终的目标。
