自动化测试的技术路线

本文中我谈一下自动化测试的技术路线，同时也是测试团队的发展路线。

团队路线1.工程化路线

如果你们公司只有你一个测试，那工程化的路线是必然的选择。另外，我个人比较推崇工程化而非平台化。

下图介绍了工程化路线下写出来的自动化测试：

工程化的测试脚本用法是，我们给他一个命令：我要运行xxx测试，它就去自动执行相关测试，然后给出报告。它的特点就是把测试脚本看做一个软件项目来做，因此测试人员都需要掌握一种编程语言，以及这套脚本里会用到的各种库。

工程化的测试脚本是用这些东西实现的：

某种测试执行器：比如 Junit，pytest，robotframework 等等，来负责执行测试。（关于测试执行器可以看我之前介绍测试执行器的文章：初识测试执行器）

某种测试驱动库：比如测网页，需要 selenium 来驱动浏览器，测app可能用appium 来驱动移动设备或模拟器，测接口就用 requests 来调用接口。

某种方式来管理测试数据：最开始可能是写在csv文件里，也可能写在 excel 里或者写在数据库里，同样需要对应的库来管理这些数据。

某种方式来管理业务逻辑：这块是我们自己写的东西，比如测试脚本怎样管理，业务逻辑怎样重用。举个例子，在selenium web 测试里会很流行用 page object 模式来管理测试逻辑和页面控件。而其他测试里，大家也会自己设计自己的“模式”来做。

然后工程化的测试脚本还会用到一些常见工具：

最常用的工具是：

版本控制系统： git 和 github 等，用来管理测试脚本，因为测试脚本工程化了，可能有很多分支和版本，测试脚本也会和待测软件的版本相对应。

持续集成系统：jenkins 等，用来定时跑测试脚本或者在开发提交代码的时候触发测试脚本。

简单来说，把这套工程化脚本在本地调通之后放到 git 上，接着用 jenkins 来执行这些脚本，这样整个流程就走通了，这也就是工程化路线下的测试脚本的雏形了。这么一套东西，称其为“测试框架”。但这也不是终点，后续还可以引入更多工具，以及对一些工具做二次开发，或更改其源码，或为其开发插件等等。

我比较喜欢把这条路线称为集体飞升路线，怎么说呢，在用工程化的测试脚本的团队里，招人都必须招能写代码的，但是新人需要写的代码又不会太难。同时在测试框架内还有很多别人实现的东西你可以参考。这条路线的难点就是你需要一个高手在最开始搭建一个可以扩展和优化的基础框架，并持续优化这个框架。后续加入进来的各种萌新就可以很快掌握那些用到的技术。最大的优点是整个团队的技术都得到提升。

我之前诺基亚公司用的框架更是好多年前别人写的，一直有专人优化下来，度过了整个3G时代，现在到做5G了，还能用。我现在团队在用的框架我一年前写的，今天我仍然在优化其数据管理的模块，这些优化是持续性的，而非一劳永逸。这种模式的最大缺点是领导可能觉得框架写完是一次性的，你写完了赶紧干别的去，但不优化，一套框架和脚本慢慢就会废掉，变得不适用、用起来麻烦、变成没人愿意碰的东西。

团队路线2.平台化路线

理解了工程化路线，再来看平台化路线，这种路线早期起始与大QA时代。

如果你们公司有很多测试人员，并且测试部门比较有钱，那么就可能选择平台化路线。

下图介绍了平台化路线下写出来的自动化测试：

测试平台的用法是，在网页上做很多事情。写测试，管理测试，调度和执行测试，可能都是在页面上做的。它的特点是把测试脚本分成平台部分和脚本部分。对，脚本部分我上图里没画，因为他不是代码形式的脚本了。因此就出现了两种测试人员：测试平台开发人员和测试脚本编写人员。

测试脚本编写人员并不需要掌握一种编程语言，而只需要掌握业务逻辑，然后使用平台来编写测试。这极大限制了测试脚本编写人员的技术发展路线，因此我并不喜欢这种测试平台。

测试平台开发人员可能需要掌握一般网站开发技能，包括前端和后台，但是很少有像普通软件开发项目一样分工为前端开发和后台开发的测试平台开发人员，这是因为测试平台通常只是玩具级项目，也就是内部用用，没什么流量的xx 管理系统。很多平台可能只是一两个人搞几天搞出来的，好不好用他们不管，做出来就是为了刷KPI升职的。这并不是说测试平台开发人员都是全栈，只是因为领导并不愿意在内部项目里投入更大资源。于是就希望招一些二线开发人员来低成本地做一个能用的平台出来。

测试平台是用这些东西实现的：

自制的测试执行器：与工程化不同，测试平台往往会选择自己做一个执行器。比如诺基亚的某使用了很多年的老测试平台，测试用例你得在网页上打勾勾选，选好了点一个执行按钮它才能执行这些测试。虽然我们都知道勾选很麻烦，但毕竟看起来酷？同样我之前诺基亚公司，后面另一个部门做的新平台选择了让用户输入一个 robotframework 启动命令的方式来执行测试，这就是第三种路线（平台框架混合路线）的雏形了，暂且不提。

某种测试驱动库：这个和工程化里面是完全一样的。

某种方式来管理测试数据：因为采用了web网站形式，所以数据十有八九在数据库里了。数据库的优点是数据都保存下来了，缺点是：慢。读也慢，改也麻烦。

某种方式来管理业务逻辑：这个和工程化里面也是完全一样的。

前端页面和后台：这个看你用比较老的架构还是新的架构，老式的架构要求你至少掌握bootstrap和基础的javascript才能做，还有一些前端模板技术，比如python系里的jinja2，java系里的Struts。前面也提过了，测试平台通常就一两个人搞几天搞出来的，所以这几个人可能很有热情，很想用新技术，于是，有些原来是做前端出身的作者会搞成单页应用形式，用到一些诸如三大前端框架（argular，vue，react）之类的东西，也可能后台也用nodejs做。而有些做java出身的作者则会用 springboot 做。python出身的作者可能用django，flask甚至webpy，bottle做。上次去面试遇到一个面试官说他要先用springboot做，后期再改成golang。我之前诺基亚还有一个平台因为作者想玩一下非关系型数据库所以用了mongodb。还有一个平台的作者设想了使用zookeeper、docker等自动实时创建jenkins master。。。其他后台技术也可能会用到很多很多，总之有什么技术就可能用什么技术。

看到这里，测试平台大概怎么回事，应该也知道了吧。相当于把工程化测试脚本里的所有内容包括jenkins和git都封在了一个平台里。做平台和用平台的往往不是同一批人，我喜欢称其为“割裂路线”。

回想起以前在诺基亚和平台组的无数次撕逼，以及质量本身差的要死的测试平台，我真心不喜欢这种路线。但是，这种路线有其优点，那就是: 看上去高大上，容易刷KPI，忽悠不懂技术的领导。但是，其缺点也是很严重，不好用、割裂的团队。不写代码的测试脚本编写者固然技术路线被锁死，做测试平台开发人员的人，技术路线也不怎么好走，长期做玩具项目也是没什么前途。

前端懂一点，后台懂一点，这个语言懂一点，那个框架懂一点，有什么用？有专精的点吗？懂一百个技术的皮毛未必比得过精通一两项技术。如果要走web开发相关的技术路线，在这种内部项目上是走不下去的。你的测试平台好到足够产品化变成一个对外的项目吗？