我的测试开发十年之路

cleardo / 2023-09-02 / 原文

目前在测试开发行业已经摸爬滚打了十年，一直忙于工作，基本没有多少时间可以静下心来进行沉淀。现在，终于有了个机会，可以对自己的测试开发生涯十年进行一次总结，希望这次能够写完吧。

（绪）

从毕业后，我干了几年PHP开发，可能因为不是专业原因，遇到了一些瓶颈，在技术上无法突破，也可能是因为天赋原因，可能也不适合干开发这行。机缘巧合之际，遇到了一个好领导Z总，他在简单面试过我后，就决定同意我转入到QA部，担任测试开发工程师，算是晋升了一级，在第一年，领导开始给我定了CICD的方向，把项目的CICD给打通了，当时应该是2013年的时候，devops没像现在这么火热，但是因为教育系统的复杂性，大家都意识到，这玩意儿，没有CICD可不行，每天出问题，都是用户第一个发现。

于是我们开始研究CICD的技术方案，当时用的是jenkins和teamcity，为什么用两套，因为开发团队又有C#.NET帮，又有PHP帮（手动狗头，逃！），teamcity对C#显然支持更好，而PHP当时有xinc，hudson（如果我没记错的话），jenkins，当时jenkins从hudson出来后，社区活跃，所以选择他当然没错，所以一款产品火不火得起来，好的社区很重要。我于是开发了一个ci_sync的同步工具脚本，集成到了jenkins，自动对一些配置脚本进行分析，替换一些变量，去除一些不必要的调试代码，其实就是类似autoconf、automake这类的构建系统，只不过autoconf这一套有点复杂，我没有这块基础和背景，所以还是选择简单实现，采用大量正则进行匹配。当然，这个实现很丑陋，所以我后面也开始学习类似语法解析这类方法，来进行脚本的解析和处理。开发完以后当然开始用起来，后面就开始一直在维护这套脚本。但是，Z总找到我说，虽然我能力还行，但是距离他的期望，其实有挺大距离，他希望找到的是一个架构师，现在他不知道该不该把这个位置留给我。虽然我不知道这个架构师到底是个啥，但是还是默默答应下来，好的，我会成为一个测试架构师，事实上，我后来也看了《测试架构师修炼之道》，但是咱就是个社恐，理念可能略懂，但是要跟开发大佬们滔滔不绝，咱还是没这个底气。

(一）测试框架养成

上一节咱谈到了测试架构师，在我看来，实在也不懂这条路怎么走，后面应该是又一个机缘巧合，几个测试小组开始研究起了接口测试框架，大公司就是这样爱一起扎堆造轮子。我的大Z总知道了这个事，又出面了，搞了个workshop，叫上了部门的几个技术大牛，当然，好像也包括我，一起去PK接口测试框架用哪个。我有点头疼，你安排我做行，让我去争，我还是有点犯蹙的。不过，既然领导开头了，咱硬着头皮也要上吧。我的编程哲学其实是很不入流的，大部分人是先有鸡（规划）再有蛋（实现），而我遵循的是，这个水就是有H元素和O元素构成的，你拿HO还可以组成双氧水，你可以在头脑里有个大概的样子，但是你没法清晰定义他，就尝试着写把他组合起来看看吧。所以，我在这个过程中，我写了个http请求的lib，然后再把他放到unittest里，这个就是一个测试框架的雏形，这样对吗，好像对，也好像不对，跑能跑，少了点啥，unittest的报告可太丑了，不直观。所以，又找了个htmlrunner，把测试集扔进去，报告出来了，有点好看了，但是代码还是很丑，还有bug，所以我就把htmlrunner拆开来了，研究他写的啥，然后就加了下调用时长，blah...blah。由于我当时刚好参与的是基础设施的平台，叫共享平台，是一个可以提供各种基础设施服务，申请使用的平台，我就想着这些东西可是宝贝，意味着我们的框架可以测试他，也可以利用他，于是我加了mysql连接池、加了mongodb，加了casandra等等。其实后面，我还搞了分词库，用的搜狗词库，但这些有点脱离了框架的本质，所以其实我没有在框架介绍中包括进去。

随着加的东西多了，整理了下代码，画个分层结构，比如用例层、业务方法层、公共函数库、第三方依赖，再加一些日志装饰器等等，就挺唬人了，当然，最后这个框架被推广起来了，我又写了setup.py，进行打包，放到了自己的镜像中管理起来，这样，大家可以通过指定pip源，就可以更新安装。

（二）测试之殇 - 无尽的UI自动化

接口测试框架其实用python来写，是最没技术含量的，因为python足够简单，库足够多，但是大部分测试开发其实是没多少底子的，有些是测试兼职写代码的，所以就挺适合他们。

轮到UI自动化，这里先说WEB，PC我后面再补充，大部分人做不好PC，其实我感觉方向错了，因为PC是操作系统强相关，你依赖的是windows的win32 API。（跑题了，逃！）回到WEB UI自动化，当时的王者是selenium，其实现在还是，只不过这破东西，就是一个接口测试框架，他的核心就是牛逼的http连接池，然后去调用chromedriver、gekodriver、safaridriver、Edge driver、IE driver。

我自己尝试编译了下chromedriver和Edge Driver，你会发现，人家这才是牛逼的代码，你直接绕过driver，触发对应的浏览器，稳定性一定会上一个台阶，当然，代价就是这个代码普通人看不懂，chromium的代码，堪称行业的C++工程典范，干测开的，你没时间去同时维护这么多，所以，自然而然的，基于selenium来打造一个UI自动化测试框架，就成了唯一的路，通过重试啊、等待啊，勉强能够发现一些问题。代价就是你要天天去看，为什么没跑过，哪里异常了。框架底层的大部分，都是在折腾这些事。

当然，我这种菜鸡，也是折腾这些。一开始，封装元素定位层，封装控件操作层，只要一个基类就可以搞定了，当时应该是selenium3，就pip安装下，指定chrome的路径，写一个drivermanager的驱动管理类，就可以把流程跑起来了。其实我做UI自动化的时间并不长，因为当时部门的重心还是放在了接口上。当时也没有pytest、allure这样的神器，大家对PO模式也是一知半解，所以整个UI自动化测试过程是痛苦的。

后面，来了个叫H2的测试开发大佬，他打字不快，但是编码逻辑思路很清晰，在测试开发经验上也很丰富，我记得他的一个理念就是反对在框架中封装过多的js脚本，因为对于端到端的测试来说，用户是不可能去直接执行JS脚本的，能模拟用户点击的，还是应该模拟。最后我们组的UI自动化测试框架由他使用java重新写了一遍，还加上了分布式执行，使用的apache mq，来接收消息，并触发用例脚本。这个架构基本是没啥问题的，但是稳定性的保证还是需要做不少工作，感觉适用staf这个分布式框架来托管脚本，应该是个不错的选择。总之，我得承认的是，我在WEB UI自动化领域，不算资深，但是在框架的理解上，应该也是正确的，毕竟实践才是检验真理的唯一标准，实践不够，只能说我的小脑袋，还是没法做到真全栈。