节奏四：我只要会xxx语言就可以了，其他的语言不需要

　　理论上这是正确的，但是语言说白了还是工具，在做一件很复杂事情的时候，单一的工具往往是难以很好的完成任务的。任何语言都有其擅长的部分，不擅长的地方，取长补短才是王道。我用过很多的语言，但是在做前端UI自动化的时候，我发现ruby+watir webdriver很方便，于是一直用，项目一直在做，几年了都没失败。但如果当年用的是java的话，我估计我们的产品在改版几次以后，这个自动化项目就要寿终正寝了。多学一点语言其实没坏处，不过如果你选择专注，那么你有你的道理，你可以坚持，没人会责怪你。

　　说了这么多作死的节奏，现在就稍微总结一下自动化应该怎么做。

　　原则一：能力使然

　　这个能力是指的综合能力。首先你要会测试，自动化测试毕竟是在用代码写用例。其次你要会写代码，你要把用例翻译成代码。不要迷信于录制回放工具，光用这个基本上做不成项目。而且会录制回放对你来说也没什么意义，任何一个人学习个一天一定能学会录制回放。做自动化测试实际上是对自身能力一个很好的提升，一定要抓住这个机会，不要去弄没啥技术含量的录制回放，学会了有什么用，大家都会录，凭什么让你录。

　　做自动化测试其实挺难的，会有很多困难，毕竟前端UI的东西是最容易变化的，但是如果你能力足够强大的话，这些变量对你来说总会有办法去克服。比如UI老是变，就可以封装一些page object的思想，让UI修改变得容易一些。还有用例老是跑出错，不如在代码里加入自动截图，一眼就能定位问题，代码维护起来自然就容易不少。

　　没有一个成功的自动化项目是菜鸟做成功的，当你做成功了一个项目以后，你自然就从菜鸟变成了高手。

　　原则二：不变应万变

　　UI总是在变，比孙悟空还会变。但是在变的过程中一定有一些东西是不变的，我们做自动化测试的时候要尽量用这些不变的东西。比如表单元素的name，一般不会频繁变动，相对稳定。另外数据是会变的，比如你进入一个工单的列表页面，有时候会有10条数据，有时候会有20条。有时候第一条数据的内容是A，有时候是B，这是因为数据在变化，这时候你只要让数据能固定住，这样进入工单列表后一定只有10条数据，第一条数据永远是A，那么你的用例写起来自然是神清气爽，难度不高，也容易维护。

　　原则三：团结一切可团结的力量

　　对我来说，很多时候我总是一个人在战斗。开发努力改一个迭代，改出若干新功能和若干bug，然后我更新对应的自动化用例。因为我的框架扩展性还不错，所以开发改两周的UI，我两天就能改完，不过如果老是我一个人在改，那么我一定会非常孤独吧。这时候不如让手工测试人员帮我一起改，对他们来说自动化是福音，能节约其回归的时间，所以改用例对他们来说是很有必要的一件事情，然后我教他们怎么改，他们学会了以后我就可以放手去做其他事情。现在我已经基本不做自动化了，原因就在这里，有人帮我做，而且比我更有动力去做。

　　原则四：把成果展示出来

　　我专门写了个报告平台来展示自动化的测试报告。一定要让团队成员知道你在干什么，报告是最简单的途径。成功的项目一定有很不错的报告，这点不容置疑。

　　原则五：可维护的代码

　　代码要容易读，容易改。看看我写的lazyman框架里的示例代码吧，再看看原生的webdriver代码，你应该会有所感触。记住，原生的webdriver代码一定是不太好维护的，没有框架支持和封装，原生的webdriver代码一般很难规模化，很难达到成百上千个用例的规模。好的框架可以使你事半功倍，不要迷恋原生代码，可以用，但不够用。

　　最后再来点Q&A

　　自动化用例从哪里来？

　　从手工用例中来，择其善者而从之，不善者而改之，仅此而已。

　　自动化用例要测到多细？

　　这要看你有多少时间和人力。时间多人手够就细一点，不然就粗放一点，保证能节约回归成本就好。

　　我的项目老是在改UI，是不是不适合自动化？

　　这要看你有多少时间和人力。时间多人手够的话开发改，你也改，反正改用例的工作量一定小于开发的工作量，只要你能改的过来，自动化就可以做。

　　我的项目里面那些元素没有id和name，怎么去定位啊？

　　自己加id和name，如果你连修改html的代码权限都没有，那么恭喜你，你的自动化项目做起来很难很难。

　　我是初学者，用什么语言和工具啊？

　　watir-webdriver