（转）测试开发之路--聊聊自动化的打开方式

https://testerhome.com/topics/7271

前言

自动化好像是测试行业永恒不变的热点话题。貌似也是测试行业争议最大的话题。不知道如今还有多少言论说自动化没有用的，记得前段时间的时候网上还有很多人在争论自动化的价值和做用，但其实自动化不只仅是存在测试行业。 如今的运维行业以及最近特别火的devops概念都是深深的依赖着自动化的。 好像咱们也从没据说人家运维圈子在争论自动化有没有用。往近了说咱们公司专门有运维开发来搞运维自动化， 往远了说google也有SRE团队大行其道。自动化是人家圈子里根正苗红的标配。为何到了测试圈子里争议就这么大呢？我一直以为这是个很奇怪的现象。大道理我就不讲了，理科男没那么多文绉绉的词汇，我只讲讲我以为有价值的自动化是怎么个打开方式把。
注：测试圈子太大，每一个领域有各自不一样的状况，若有不一样，欢迎探讨。

自动化的目的

节省资源。我实在想不出来有什么目的比这个还更重要的了。我一贯以为不以节省资源为目的的自动化都是耍流氓。

先说说UI自动化

误区一: UI自动化实现很简单

之因此有这么一个误区缘由也很简单。UI自动化不管是selenium仍是rf。日常用的API确实没多少，很好学。稍微有代码基础的人就能很快上手，而且以为这真的很简单。 可是，实则否则。写个脚本跑起来很简单。可是按产品业务构建起一个由数百甚至数千个脚本组成的自动化测试项目就彻底不是一回事了。脚本的稳定性，可维护性，可扩展性,业务上的拆分，执行的性能，报表的展现，日志的展现，异常捕获与处理，分布式运行，与数据库和各类底层存储介质的通讯等等都是要考虑的。同时你还要考虑自动化最大的敌人--需求变化所带来的影响。你要从项目之初就设计好自动化项目的架构来针对这个多变性。 这要求测试人员有起码的代码设计能力。只惋惜不少人用着Python，用着Java。可我看着都觉得这是在写shell，写c。连起码的封装都作很差，我实在不以为这是在用“面向对象的语言”。

误区二: UI自动化没用

形成这个误区的缘由也很简单。技术和业务拆解能力不足就直接去搞自动化了。因此天然就没什么好效果。并且忙于在维护脚本中奔波。而后总结出了一个结论--UI自动化没有什么卵用。

正确的打开方式

1. 首先，代码能力要好，代码能力要好，代码能力要好。重要的事情说三遍。好的UI自动化项目依赖于好的设计。好的代码能力不是说你会使用各类牛逼的技术，框架。而是你能设计好一个项目，该封装变化的封装变化，该抽象分层的分层，设计模式该用就用。把脚本层，数据层，基础框架层，业务层，page层等等剥离清楚。 按业务需求把各模块分割明白。 这时候要明白，我是写代码的。以一个开发的标准要求本身。
2. 挑选最合适的开源框架。别装逼本身写，本身写的确定没人家开源的作得好。除非你是大神不然别本身写。但也别一刀不动，要根据本身的需求对开源框架作二次开发。 推荐一个java系的工具链。UI工具用selenide，注意不是selenium。report框架allure，断言框架assert-core和assert-db。基础测试框架testng或junit。 UI相关的差很少就这些。别再用老旧过期的工具了，还在用原生webdriver是很痛苦的。连自旋等待机制都没有。
3. 别迷恋关键字驱动，录制回放和各式测试平台。这些东西的发展就目前来讲虽然逼格满满，但还没法作好自动化，它们善于下降学习成本，让没有技术能力的人能迅速作到60分，而咱们这里说的是要作到90分以上。而且脚本数量一上来就是维护噩梦。公司体量没到必定程度的时候也别去自研测试平台，测试平台也不是保姆式的无脑下降学习成本，主要目的还在于标准化，自动化。
4. 要与业务绑定，让技术人员只写脚本无论业务测试是大忌。先不说别的，架构都是根据业务拆分设计的，你看哪一个架构师设计的时候不看业务需求直接动手的？退一步讲业务不熟练你用例都写很差。
5. 标准化，咱们并非在一我的在战斗。最好要有统一的技术栈，运行环境，代码风格等等。标准化真的是好处多多。
6. 理性看待UI自动化，合理运用UI自动化。它不是神，有不少东西不适合作UI自动化的别硬去作。也别由于有些东西UI自动化作的很差就否认它。

每一个项目面对的状况不同，我就不说太多了。介绍下我厂如今的状况。 6个浏览器并发一个小时基本跑完全部UI自动化。以前3个QA3天跑完全部case，如今是7个小时。如今的痛点仍然是运行速度问题。 但愿今年能申请到更多的资源。

接口自动化

这个在业界比较火，各大厂测试圈子的宠儿。自从分层测试理念出现之后就开始崭露头角。成本低，速度快，效果好，运行也稳定。UI自动化中不少奇形怪状的坑在接口测试里是踩不到的。根据金字塔型的测试理念，测试人员大多都更关注这一层。 打开方式上其实与UI自动化并没有太大的区别，上面说的那些该作的仍是得作。仍是那句话，得有代码设计能力和业务能力来支撑接口自动化。只不过接口自动化不只仅是http接口自动化，还有各种底层协议通信，例如一些RPC协议的接口。 广义上来讲只要是对外提供服务的都是接口，不只局限于须要网络通信的。哪怕是个lib是个jar包，都是能够作接口测试的。 咱们公司也叫模块级测试。这时候就是语言相关的东西了，再也不是你想用什么语言就用什么语言，是要使用开发的语言去开发的repo里以单侧的形式编写测试代码。这时候偏底层的东西多，须要了解开发代码和架构，须要用mock。正确的打开方式参照UI吧，理念上差的不太多。工具仍是推荐java的，rest-assured，其余的跟UI的工具同样

环境自动化

这部分也一直是有争议的。纠结于究竟是QA来仍是运维来负责这部分自动化。各家公司的观点都不同，以前面试的时候问过不少候选人环境相关的问题，其中比较多的都是说交给运维来作的，他们最多自动化部署一个前端(app,browser)或某一个模块。不多见候选人是能独立把整个产品部署起来的，能画出产品架构图的就更少了。我比较偏向于公司内部的产品环境由QA维护，我厂也确实是这么作的。个人理由也很简单，咱们的产品很偏底层，要测负载均衡，高可用，异常处理等等，常常要增减节点，kill掉各类底层服务。因此必需要对产品架构很了解。要清楚各层各模块是怎么通信的，都负责什么任务。出了错怎么定位，去哪看日志，找哪一个开发都要清楚，因此搭建环境的过程是十分有助于以后的测试工做的。同时QA负责环境自动化也是有一些好处的。

1. 首先，QA更了解本身对于测试环境的需求，直接本身定制比跨部门协做效率高。
2. 其次，QA是链接开发，运维，产品，售前，进场工程等职位的角色。能够说咱们跟全部部门都紧密的合做着，咱们是比较容易获取他们对于环境的需求。
3. 最后，我现阶段倾向于QA做为一个接口输出方，交出去的就是直接可用没有坑的产品以及部署方案。把运维从这些琐碎的事情中解放出来。

到底该谁来作不争论了，各家有各家的状况。我来介绍一下咱们的打开方式把。

基于docker的解决方案

如今业界要么用传统的虚拟机加shell。要不就用当前大火的Docker。 我以前使用前者，如今热爱后者。下面是我厂的环境部署流程图。

 

过程说明：

1. 首先读取用户配置，启动N个编译容器并发编译全部模块。
2. 统一发送到汇总容器，由汇总容器打成一个符合部署规范，能够直接发送给进场同窗的大包。并传送到FTP服务器上。
3. 根据配置挑选部署镜像(各版本的centos, ubantu, suse, redhat等)，从FTP上拉取部署包进行部署。若是是线上镜像，不会部署，而是制做成一个可在线上部署的镜像。

解释一下

之因此弄成这样要解释一下，这个跟咱们的业务形态耦合的很重。 因为咱们是TO B的业务，并且大部分状况是进入到客户场地部署的。客户场地会出现各类限制。 例如没有网络，没有root权限，五花八门的操做系统等等。因此就衍生出了部署测试，咱们也称后端兼容性测试。因此上图的右边咱们的部署镜像有不少个系统版本的。这些是咱们跟运维和进场工程师共同协定的标准镜像----基本就是一个官方的OS镜像加少许的工具。同时使用一个普通的没有任何额外权限的用户。目的就是测试产品对各类状况的兼容性。因此才造就了咱们的部署包很大，由于依赖都打在了部署包里。 咱们部署环境的时候能够选择一个镜像进行部署。

正确的打开方式

1. 标准化，docker很适合作标准化。全部环境都是同样的，不会出现什么bug在这个地方能重现，那个地方复现不了的。也能让开发人员尽早发现部署上的bug，例如本身开发的时候不当心用了root权限，这样会很快发现这个bug，由于全部环境里都是没有root权限的。
2. 并行化，我能够一我的起N个容器并发编译全部模块增长编译速度，也能够N我的同时起更多的容器并发的部署不一样的环境。不会像之前的虚拟机同样一我的编译的时候另外一我的就得等着。
3. 定制化，标准化以外咱们还能够定制化。为不一样的角色定制化他们须要的环境。例如产品人员需求稳定可用的环境，咱们给他们作蓝绿部署，服务高可用。运维人员需求一个标准镜像直接在线上部署，咱们就给他作一个镜像。进场人员需求一个部署包，咱们就在部署环境的过程当中自动的打成一个大包(上图的汇总容器)放到FTP上，他下载直接带走。开发人员除了平常部署还须要能随时搭建一个老版本的产品(TO B业务的特性)来重现并修复一个bug，咱们就对环境部署项目也作多分支策略，保留每一个版本的镜像。总之咱们能够针对不一样的岗位为他们定制化不一样的功能。
4. 环境编排，当你的环境到达必定数量之后必然就会面临一个问题，一台服务器没法抗住这么多容器运行的压力。因此就会慢慢的变成2台，3台甚至更多。 这时候须要考虑不少东西，例如资源分配怎么搞，怎么肯定哪些容器部署再哪一个节点上。例如若是一台节点挂了怎么办？难道在它恢复正常以前这个节点上的服务就一直不可用么，是否是要加入recovery机制等等。因此这时候须要引入环境编排机制。通常无非就是在swarm，mesos，k8s，rancher上选了，通常公司没那个精力自研。只是用在测试环境上推荐docker 1.12内置的swarm mode， 以前还分别研究了mesos和k8s， 对于QA来讲它们都过于复杂了，须要至关大的学习成本。以mesos来讲须要各类其余插件才能正常服务，光是一个服务发现就须要安装一个mesos dns，高可用得维护ZK等等，就算你什么都没要求也得装个marathon，各类配置文件确实也让我这个非运维感受比较棘手，想搞好它真的须要投入大量精力。而swarm mode全部的东西都已然内置，使用起来很简单方便，至于swarm mode的那些使人诟病的缺点，咱们能够忽略了，这又不是生产环境。 固然了，劝告各位QA同僚。。。能不搞集群就别搞集群，能一台机器扛着就一台机器扛着。一但涉及到环境编排，那坑就多了。。。。。。 对swarm mode有兴趣的同窗请看我以前发的swarm mode的科普贴

持续集成

以上介绍的全部自动化类型都是要加入到持续集成里的。 我以前写过一篇文章介绍过持续集成，在那里我就说过持续集成是个比较难的东西。它是对团队工程文化的一种考验。是细节的堆砌。你要把上面所说的全部自动化类型都作好，而后开发人员要写好单元测试，团队要设计好的分支模型。具体细节能够翻我以前的帖子，我就不重复的逼逼叨了。

总结

好了，这就是小弟作过的能拿的出手的自动化了，其余各种牛逼的东西不提也罢，我都不专业。