世上本没有路，走的人多了，也有了路。不讲技术，只讲感悟。

　　第一节：质量意识是自动化的前提

　　任何东西都有个价格，质量也一样，如果在产品的战略定位中，质量不是核心价值，那么质量的价格自然不会高，为质量付出的代价也不会高。

　　普遍讲，客户端产品的质量要求高于Web产品，客户端出了Bug，用户修复很麻烦，Web产品出了Bug，可以临时上线，或在下次上线修复；Web产品中，涉及money的质量要求高于没有盈利模式的产品，比如：游戏 or 购物类；还有是用户群体的大小和产品活跃度，等等。

　　第二节：减轻测试负担是现实动机

　　古语有云：凡是机器可以解决的，把它自动化吧！

　　有代码重构和服务器配置变更等涉及面广大的任务时，须要大量的回归测试，这时候先使用接口测试回归，可以速度得到反馈，确保功能无错，再配合UI测试。

　　日常工作中，不会天天重构，但做一下每日回归，上线前再密集的多回归几个轮次，应该是比较靠谱的。

　　自动化脚本尤其是接口测试脚本还可以用于批量准备测试数据，偶尔用用，不亦乐乎。

　　第三节：结合产品本身的状况是必由之路

　　额。。。这里的水太深了。简单讲，自动化不贴合一个产品本身的特点，十有八九是举步维艰。

　　一个比较理想状况是，产品的发展思路比较清晰，项目流程比较规范，上线的节奏稳定有序。在这种情况下，测试比较容易和开发沟通，取得开发的协助写用例，也比较容易确定啥时候写用例，跑用例，维护用例，维护的用例也可以反复利用，而不至于因为产品的频繁变化而失效，反而拖累大家陷入维护用例的泥沼。

　　第四节：持续投入，方可见到效果

　　无论从哪个角度看，自动化发现的Bug都是很少的，自动化主要是用来回归的。

　　用例只有十几二十个，不会有太大的收益，没有量的积累不会有质的变化。写很多用例？很大的成本，而且，产品在不断发展，用例本身也要不断维护，这些都是成本，看起来是个无底洞。

　　跑个一次两个，搞个每日回归，收益不见得高，好是搞成持续集成，密集的连续跑。但是，用例挂了谁来检验？谁来维护？谁来反馈？如何做到及时？这些都须要人力。

　　所以，做自动化，不做则已，一做要有花成本的勇气，用例要足够，至少覆盖所有核心的功能点，尽量做到持续集成，毕竟都是敏捷开发模式，代码提交的频度很高，还要有坚持扩充，维护用例库的恒心。

　　一个优良的自动化框架的价值主要体现在这里：使得用例好写，好维护，运行稳定，运行快。

　　发现Bug不是我们的目的，保证质量才是。