前言

去面试自动化测试岗位，尤其是接口自动化岗位，面试官总会问：说下你的自动化框架如何设计的？
为什么回答后，面试官对你的框架设计总是感觉不满意？

自动化测试实现的几种方式

对于不同的公司来说，实现自动化的方式不太一样，其实不管哪种实现方式，只要能解决工作中的问题，都是好的。
总的来说有以下这几种实现方式：

1.高度依赖于成熟自动化框架或自动化平台

作为一个公司的测试leader ，想要快速把自动化测试落地，年底好写PPT评绩效。那么会找个成熟的开源自动化框架，或者公司不差钱的可以买一些成熟的自动化平台。
如果你是参与者，你只需要按测试leader 部署好的框架或平台去落地就行了
比如：

robotframework 等一些成熟的关键字驱动框架，没代码功底的也可以快速入门
yapi, apifox, metersphere 或一些大公司自己开发的内部平台化的方案，部署后就可以直接在上面添加用例
postman, jmeter 等一些工具的使用

优点：
对于测试人员来说，可以快速参与到自动化项目中，有参与自动化测试的项目经验。
对于测试领导来说，落地快，出成果快，年底好写PPT评绩效（至于用例质量和高效性不care, 反正不是他自己去落实）
缺点：
对于测试人员，你只是在平台上添加用例，那么对你个人来说提升空间不大，一旦哪天脱离了平台，你什么都不是。
对于测试领导，你无法把控用例质量和提升编写用例效率，只能适用于一些常规项目的普通需求，有特殊需求需要二次开发的没能力解决，比如后续CI/CD集成与实施上就没那么灵活了。

2.基于unittest/pytest或junit 等测试框架

公司有招聘专门的自动化专员的，专职做自动化的人员，一般都是有代码功底掌握了python / java 等语言。
有代码功底的更倾向于开源的测试框架，可以结合单元测试框架（unittest/pytest或junit）去实现不能项目，不同需求的自动化，于是又可以细分成web，接口，app自动化。

web 自动化：
以python语言为例，通过实现方式是 unittest/pytest + selenium, 然后搞个 POM 模式去实现。

优点：
可以灵活的组织自己的测试用例了，写不同场景的自动化用例，还可以定制生成各种漂亮的报告，如allure报告
相同的模块可以代码复用

缺点：
由于不同人员代码质量参差不齐，定位元素只学了皮毛，大量的时间和精力都花在了定位上，你会看到学web自动化的人员，问的最多的永远都是：xx元素怎么定位？
代码质量不高的，不是在报错，就是在报错的路上，排错浪费大量时间和精力。

接口自动化：

以python语言为例，通过实现方式是 unittest/pytest + requests ，然后是搞参数化数据驱动，测试数据和代码分离。
常见的几种方式：
1.所有的接口用例和测试数据放到excel 文件，封装读取和执行excel 用例的方法，让小白也能参与使用
2.参数化（数据驱动、数据代码分离）接口数据放到yaml 或 json 文件，封装读取数据和执行的方法
3.写公共方法，调用函数的方式去组织不同场景用例，更偏重代码的方式实现
4.用httprunner框架，纯数据的方式实现

优点：
接口自动化实现相对来说比较简单，实现的方式也是各种各样的，一般只要有自己的一套方案，都能实现

缺点：
门派太多，实现方式各种各样，用excel的瞧不上用yaml的，用yaml的瞧不上用excel的，用excel、yaml的又瞧不上写代码的。
反正各门派之间内斗严重，去面试的时候也是没统一的标准答案。不像web自动化，POM就是标准答案。

APP自动化：

app 自动化分android 和 ios 两个平台，常用的有appium 和 airtest。
app 自动化是最难学的了，并且能真正落地的很少，没扎实的自动化功底很难做起来。

优点：
能做好的，前途无量

缺点：
环境问题就能劝退一大片的人了

3.基于自己公司的测开人员开发的平台

如果公司有专门的测开人员，根据自己公司的项目需求，开发自动化平台，或者工具。
那么有人会问了，既然有开源的接口自动化工具了，为什么要去开发一个呢？
现有的接口自动化工具，大部分都是基于HTTP/HTTPS 协议的，如果你们公司是其它的接口，比如：websocket/mqtt/Dubbo.
或者开发一个可视化的平台，在平台上维护用例。

优点：
自己公司开发的平台，具有保密性，接口和测试账号不会被泄露
可以根据自己公司的需求，灵活定制
可视化的平台方便领导查阅，知道你具体做了多少工作。
只要平台稳定了，后续其它测试也能快速参与到自动化的工作

缺点：
对测开人员能力要求高

说下你的框架是怎么设计的？

去面试自动化测试岗位，尤其是接口自动化岗位，面试官总会问：说下你的自动化框架如何设计的？
对于这种开放性的问题，因为每个人做的自动化实现方式不太一样，也没标准答案，这里我总结了自动化测试人员的几个阶段，大家可以对号入座，看自己处于哪个阶段。

一、初级入门-以线性用例为主

1.早期的以录制为主，生成的用例，对于不会写代码的人来说，录制简直就是神器。
页面上点点点，就可以自动生成用例了，只需要稍微改一改，快速的实现了自动化。
这种就是典型的线性用例（用例是一条直线形状，不带拐弯的），缺点也很明显，业务的改动，会导致大量用例失效，得重新去录制，复用性很差。

2.以postman、jmeter 等工具为主的接口自动化用例，这比录制稍微强一些了，能自己去组织用例，维护用例了，还可以继承一些报告。

postman 工具实现接口自动化

jmeter 工具实现接口自动化

这种工具为主的，确点也很明显，跨平台使用不方便，还有个很大的缺点，你写的用例，只能在你自己电脑上跑，别人无法跟你的用例共享。
2-3个人共同维护一个项目的时候，缺点就暴露出来了。

这种单个人实现的接口自动化，算是自动化初级入门了。

二、unittest/pytest 框架使用 - 代码复用

有一定的代码能力了，于是可以学一些自动化测试框架。
以 unittest/pytest 为主的使用，结合selenium， requests 等库实现web或接口的自动化，可以解决前面说到的的问题。

早期基于unittest + excel的项目设计结构

或者以下一个简单的pytest 接口自动化项目结构

web自动化框架都是POM设计模式，主要写个base的文件，其它页面都基于base继承，每个页面封装一个Object 对象。页面上的点点点基于页面对象调用对应方法

这一阶段的主要目的是代码的复用，写一些读取excel或者json/yaml 文件的广告方法，公共模块的封装，比如登录这种公共方法，很多流程都会用到的，那么就可以写成公共函数去调用。

这时候面试官又会说了，那你的框架有没有实现数据和代码的分离呢？

三、参数化/数据驱动 - 数据可维护性

当上一阶段实现了代码的复用，你会发现很多操作其实都是重复的动作，像接口自动化里面的发送请求，都是调用一个方法，传不同的接口参数就行了。
于是这一阶段的追求是数据驱动模式，通过代码和数据的分离实现参数化，写公共方法去读取excel/yaml/json 文件。
项目基本设计结构：
1.接口的数据写到excel/yaml/json 文件
2.写公共方法读取excel/yaml/json 文件，解析出测试数据，生成用例
3.写个main去执行用例

那么这一阶段的实现，具有代表性的实现方式如下pytest+yaml
在yaml 文件中写接口数据

学公共方法去读取接口数据，封装提取参数和校验参数的方法

最后写个方法去生成用例，通过main.py 去执行全部用例，生成报告
（目前网上看到的绝大部分都是这种思路）

四、具有代表性的框架是 httprunner 框架

pytest+yaml 测试数据和代码分离成熟的方案就是httprunner框架了，可以直接使用别人封装好的框架。

上面一种自己写的和别人写的httprunner框架对比有哪些不一样呢？
1.别人的框架始终是别人写的，你去面试的时候说用的httprunner框架，面试官会觉得你不会写框架，都是用的别人的
2.你给领导看的时候，你全写的yaml用例，领导觉得你没水平啊，换个人也能做
3.你没写代码，领导觉得你不会写代码吧，下次不给你涨工资了

所以自己的东西再烂，那也是自己的，可以唬住面试官和领导。
这就是为什么，网上都喜欢自己去写一套pytest+yaml 的方案的
1.代码在项目结构里面，可以唬住领导，让领导觉得你好厉害，写这么多
2.面试的时候，可以非常自信的说是自己写的，还可以介绍每个模块实现的功能
3.可以让其他不会代码的人员觉得你这20k不是白拿的，确实厉害，很有优越感
4.金框架银框架不如自己的狗框架

五、自己开发框架/插件

我这里说的自己开发框架，不是前面说的简单建几个文件夹的事情，是开发一个能给大家使用的，比如httprunner框架开发。
还有我近期开发的基于pytest 框架的 pytest-yaml-yoyo 插件，项目地址https://gitee.com/yoyoketang/pytest-yaml-yoyo?_from=gitee_search

所有的用例读取和执行都封装好了，只需一个pip安装就能使用

pip install pytest-yaml-yoyo

用例只需要写个yaml文件，不需额外的代码了

config:name: getteststeps:
-name: getrequest:method: GETurl: http://httpbin.org/getvalidate:- eq: [status_code, 200]

用例执行，跟pytest执行一样，只需一个命令

pytest test_demo.yml

只有当你熟练使用了各种测试框架后，你才会知道每个框架的优缺点，知道测试人员的痛点在哪，那么你设计的框架能解决这些痛点就是优秀的。

六、平台化-测试开发

有很多测试人员一直搞不明白，测试开发的工作是做什么，跟自动化测试有什么区别？
测试开发的工作是不是就是开发一个web网站这种测试平台呢?

不同公司对测试开发的岗位定位其实不太一样，总的来说，测试开发的工作是为给自动化测试提供服务的。
比如自动化测试人员需要一个测试平台，那么就需要开发一个平台让他们去维护自动化用例。
比如自动化测试人员想参与CI/CD的工作，那么测试开发就去建设对应的工作。
比如自动化测试人员需要一个测试dubbo接口的工具，那么测试开发人员就去开发一个工具。
还有其它很多能提高自动化效率的事情，都是测试开发人员的工作。

七、人工智能-自动生成自动化用例

最近chatGPT 很火，各大媒体都在蹭流量，它的出现，可以帮助程序员快速实现一些基础的逻辑代码。
我们做自动化测试的早期目的，就是为了解决手工的重复劳动。
于是早期我们通过代码的方式让双手解放了出来。
但是想一想，虽然不用手工点点点了，你去写自动化用例敲代码，也是需要双手的，所以并没有真正的解放双手，虽然双手没有解放，但节省了时间。
当接口自动化用例写多了之后，你会发现大部分工作都是复制粘贴，改改参数，这其实也是重复劳动。

于是就有面试官问：那你的框架能不能根据接口文档自动生成自动化用例呢?
如果开发给一个swagger文档，你写的框架能自动根据接口文档，生成不同的请求参数，自动去校验结果，那么就是面试官所需要的。