开发转测试：从零开始的6年自动化之路

lsekfe

自动化初识
　　作为一个测试人，我们或多或少都听过或用过自动化，我们都曾在初入测试行业时，满怀期待的以为测试的尽头是不用测试员点点了，项目一提测，小手点下自动化的开关，瞬间测试的工作就完成了。
　　这就是我一开始从开发转向测试时最好奇的地方，带着这个好奇心，我激情满满地加入了公司刚成立的自动化组，一探测试到底是如何摆脱手工劳动而完成测试的，一干就是6年。
　　接下来，把我们的自动化在公司的使用进程一一介绍给大家，希望它能对你有所启发，有所帮助。
　　自动化启动
　　我相信每一个搭建起自动化团队的公司，无疑不是想通过自动化来提高工作效率、节省时间、节省人力。
　　但有一个致命的地方，很多初次起草做自动化的人，他可能根本不了解自动化的本质和特点，仅仅知道“做了自动化就可以像其他公司一样提高效率”，这是我们做了3年自动化之后觉悟出来的道理。
　　这不是在批评、埋怨谁，我很感谢感激走过那3年，人生每一段路都没有虚度，它让我深刻认识到什么样的做法是可以的什么样是行不通的。
　　我在这里说出来，只是想后来者可以不用花这么长时间来明白，希望你们在做出决策之前对自动化有更全面的认识。
　　2016年，领导决定测试部要做自动化，当时我才从开发转到测试没多久，还在做功能测试（体验功能测试阶段），做了一段时间便感觉挺繁琐的，加上自己平常也在查阅相关自动化领域的资料。
　　所以，当领导说要成立自动化组时，我特别兴奋，决定要加入自动化组，心想终于有真正的机会来尝试自动化这个新玩意了。
　　虽然我有一些蹩脚的开发功底，但毕竟没有实战过自动化，于是我们从外面招来了一个自动化方向的大牛。
　　技术大牛就是不一样，仅用2周就搭建起了我们的自动化项目架构，并进行了相关封装抽取。那个时候我真正知道了Selenium、Webdriver、TestNg、Jenkins集成起来的一套自动化系统的工作流程及用法。
　　写到这里，你大概已经知道，我们实现的是一套UI自动化方案。框架搭建完了，剩下的就开始收集用例、转化脚本了，也是在写脚本的过程中，我慢慢知道了所谓的自动化测试是如何实现自动的。
　　自动化初期，我们并没有什么经验，我们只知道至少要把公共主流程性的用例给自动化了。
　　于是，便以我功能测试几个月对业务的了解开始抽取了某一模块这种类型的用例，技术大牛和我分工把这些用例都给转化出来了，这个过程，对于我来说学到了很多，知道了PO模式、数据驱动、元素定位以及里面的一些坑等。
　　写脚本对于我来说上手很容易，很快我俩就完成了一期自动化用例，然后又把这些用例集成到Jenkins上，至此，自动化就算初步运作起来了。
　　探索自动化的意义
　　完成一期脚本转化以后，马不停蹄地开始做二期的脚本开发规划。有很长一段时间，我觉得我们做自动化好像失去了做它的意义，我们完成了脚本开发，为啥不用呢？怎么才能把它用到工作中去呢？
　　当自己做的东西没有在工作中发挥它的价值的时候，做的人就会逐渐丧失对这份工作的热情，因为他没有得到反馈，他不知道接下来奋斗的目标在哪里。当然，也依然会持续做着一些可有可无的工作。
　　次年，也就是2017年，领导开始跟我们一起想办法，一开始的办法是跟功能测试人员说，我们哪些模块一些什么样的用例已经实现自动化了，让他们在测试的过程中，如果需要执行那种类型的用例的时候，就去Jenkins上执行。
　　试运行了一段时间证明，靠自由自愿的方式就别想把工作干好。
　　大部分人都不选择用自动化，即使他的项目可以用。还有一部分有心用的同学，由于不懂开发相关技术，不会分析出错时的问题，常常需要找自动化开发者去帮忙看，加之，前期UI自动化脚本确实没那么稳定，运行错误的概率又更高了。
　　那不用自动化的原因就出来了：
　　1、不感兴趣，觉得手工测测挺好的；
　　2、想用，奈何自己技术有欠缺，不会分析脚本问题，加大使用难度；
　　3、想用，但脚本稳定性太差，丧失对自动化的信任度。
　　相比其他同事，自认为算是一个自动化的狂热者，不太相信自动化不能在工作中发挥作用。心想，一定是你们自己不会用才这样。于是，我申请了做一段时间适合自动化应用模块的测试。
　　我是怎么做的呢？以下，是一个正常项目测试中自动化应用流程图，直到今天我也依然使用的这个思路。

按照这样的流程，磕磕绊绊地应用了几个项目。真实的效果是：
　　1、使用了自动化以后确实发现了一些问题，但分析定位出那是一个bug确实不是肉眼一下就能看出的；
　　2、效率上看，若考虑投入成本/产出，这谈不上提高了我多少测试效率，但若是一份脚本开发维护，多人使用，那又是不一样的；
　　3、Jenkins上执行用例并没有那么方便，常常看得头昏眼花。
　　也只有在我真正参与使用了我们的自动化以后才认识到，咱们这个自动化确实有很多不完美的地方，那我也总算清楚了，下一步也知道调整的方向在哪。