我在兰亭这三年之开展自动化

在我刚入职时候，部门的组织架构还是分功能测试组和自动化组，每个组的负责人都向CTO汇报，功能测试组都是做纯功能测试的，而自动化组包括测试环境的搭建维护，自动化框架开发，自动化用例编写及性能测试，当然不同的负责人之间的知识共享也并不是很多，所以也就造成了功能测试组对技术研究的并不是很多，多专注于业务相关的技术上，自动化及性能相关的也多是停留在知识分享及培训上，也许个别同学有下来自己研究并尝试实践，但毕竟不深入，而自动化组也较多的脱离业务，自动化脚本很多都不是关键业务点或者写了很多根本不适宜做自动化的东西。

2011年大概10月底突然空降一个测试总监，统管这两个组，当然新官上任三把火，怎么着也要烧完了。其中一把火就是把自动化工作进行分拆，自动化组改为自动化框架组，只做框架开发不做业务case编写，而把case的编写划入到相应的功能测试组，当然性能测试工作还是这个组负责。也得益于此，我才有了再一个接触自动化的机会。说是再，那是因为这之前在深圳工作的时候，自己也研究过使用QTP编写自动化用例，写过一部分，但是不是特别多，而且并没有广泛应用到工作中。

当然总监来公司很重要的一项KPI就是自动化，为了达成目标，也制定出全年甚至是最近三年的自动化计划，这第一步当然就是培训，毕竟功能测试组只有个别人之前涉及过自动化测试，为了工作更好开展，也并不是培训每一个人，而是像改革开放之初一样，先让一小部分人富起来，然后先富带后富。在前台（即用户网站端）组，当时的测试负责人和我则在第一批之列，后台（公司内部系统如ERP）组也是两个人。培训工作就如火如荼的开展起来了，我也是这个时候才接触到JAVA，接触到selenium。

凡是开头难，对于我之前只用过C，VBS，略知C++，刚上手使用JAVA时也是经常会出很多Null Pointer Exception的异常，为了避免这个问题，自动化框架组还特意写了个工厂类，避免像我们这种初学者老是忘记new一个对象，一出问题当然就避免不了麻烦他们，也是在这个时候我边用边学JAVA，同时也尝试着写了一些JAVA编码规范，自动化测试用例设计规范等文档。在2012年第一个Q时我们的目标是完成冒烟测试用例的自动化，当时对冒烟测试用例重新进行了一次梳理，因为发现很多很细的case优先级也标记成P0，冒烟测试用例的占比严重超标，也根本不符合业务特点和占比规范，一般来说冒烟占比1/10～1/8，最后梳理完大概40多条，然后我们就开始分工干活了。

当时自动化也是按照分层架构来设计的，DB层用于操作数据，UI层用来识别并操作页面元素，业务层即是真正的测试用例，刚开始时我们只关注于case级别的编写，DB层和UI层都是框架组封装好了直接供我们调用即可，所以我们需要经常找他们协调设计新的页面或模块的底层方法，以及解决一些技术难题，其中也是最令大家头疼的就是弹出框，因为最开始我们用的是selenium1.0，本来对于弹出框支持就不够好，尝尽各种办法都不能很好的accept或dismiss，后来干脆使用别的方法来绕过去。还有就是支持的浏览器版本比较低，而我们要实现多语言多浏览器的冒烟测试，当时firefox3.6，chrome4已经没有用户在使用了，后来干脆就升级到了selenium2.0，当然这已经是2012年中的事情了，当时我也负责起了整个前台组的测试工作，这中间的故事在以后的《部门动荡》及《自动化框架升级》中再说。

在每一个Q中，大家都有明确的任务，为了达到目标大家难免也需要加班赶工，但是每个人都没有太大的情绪，原因就是大家都能从所作的工作中有所收获有所提高，忙并快乐着。在这期间，我也有所感悟，做好一个leader并不只是自己的工作要做好，而是要挖掘团队每一个人的潜力，让大家的能量都能迸发出来。简单点讲，这是一个中间层，既要完成上司下达的目标和期望，又要能提供空间和机会让下面的人成长，学到更多的东西，做好他们的服务者，做起来却一点也不简单。庆幸的是，在这期间的一年半左右的时间里，团队也非常稳定，没有一人离职。

在这2年多时间里，我自己也花了不少时间在学习和成长，从无到有，从不会到会，从了解到熟悉，都花了不少时间在学习JAVA，学习自动化，从对testNG一无所知到熟悉它的各种机制，并且不断改进和升级自动化，有了一些自己的想法等等，我也要特别感谢以前工作过的地方能有一个平台给我学习和成长。如果说当时做的这些自动化工作有什么地方做的不好的话，可能就是为了完成KPI太过追求自动化比率了，从0开始到后来P0&P1级别的用例完成了70%共计400多条，这也导致很多不适宜自动化的到后来维护成本很高，大家都疲于每个版本之后修改，小改就是对xpath，大改可能就是整个相关的业务逻辑case，而当时页面级别的自动化占比非常高，ROI相对较低。但是好处很多：1）激发大家的工作兴趣，来钻研更多更深的技术；2）每个版本发布前的自动化回归，保证了网站主要功能流程无误，确保了上线前的质量；3）减少了很多人工重复劳动，让大家将更多的精力投入在业务探索性测试上，也是因为自动化的实现，以保证了2012年～13年一年中约20种多语言的发布上线。

提到多语言，又不得不说一下在多语言自动化道路上过的河摸过的石头。最开始是人工整理把每个语言用到的校验文案存储到数据库中，然后通过运行的xml配置文件指定语言，代码中凡是涉及到URL的地方都通过这个配置来获取语言参数，这样就能保证每次打开对应语言的URL，执行的是该语言的功能回归，在遇到有多语言文案的地方就从数据库中查一遍，这种方案很明显工作量体现在两点：一是文案的收集整理和维护；二是每一种语言都要执行一遍然后调试成功，测试结果成20几倍级增长。后来，我们发现在这么多语言中，其实在前端开发人员代码实现时只处理成2类，一类是从左到右显示系语言，如英语，法语等绝大多数语言，另一类是从右向左显示系语言，如阿拉伯语和希伯来语。这两种在CSS及JS处理时就有很大的差异，而服务端php对同一系语言实现最大的差异就是多语言文案不同，但是我们测试过程中文案的正确性和可用性并不是我们检查的，所以像第一个方案一样来做多语言自动化其实是过度设计了，所以后来就想方设法在自动化代码中去掉任何与文案相关联的部分，改用别的方法来操作页面元素或执行结果校验，比如原来是校验某处提示什么文案，现在改成某处出现这个元素（XPATH），该元素的文案内容不再成为我们的检查点。当然，好在大家都理解自动化主要是用来回归验证功能的，并不是验证提示文案。这样，减少了很大一部分工作量。

【推荐】

前面的关于我在兰亭这三年系列文章，可以查阅：

039：我在兰亭这三年（一）

040：我在兰亭这三年（二）