8年资深测试总结，接口自动化框架的设计与实现，一文打通...
目录：导读
- 前言
- 一、Python编程入门到精通
- 二、接口自动化项目实战
- 三、Web自动化项目实战
- 四、App自动化项目实战
- 五、一线大厂简历
- 六、测试开发DevOps体系
- 七、常用自动化测试工具
- 八、JMeter性能测试
- 九、总结（尾部小惊喜）
前言
1、自动化测试框架
在大部分测试人员眼中只要沾上“框架”，就感觉非常神秘，非常遥远。
大家之所以觉得复杂，是因为落地运用起来很复杂。
每个公司，每个业务及产品线的业务流程都不一样，所以就导致了“自动化测试框架”去完成自动化测试的时候产生很多不稳定因素，这样就很难定位成一个固定的框架。
其实不然，真正的自动化测试框架不是一个模式，而是一种思想和方法的集合，通俗的讲就是一个架构。
2、自动化测试框架思想
为了更好的了解自动化测试框架，先从自动化测试的发展历程说起；
一般测试工作限在3年以上且接触过自动化测试的应该对以下几种自动化测试框架思想有一定的认知：
模块化思想；
库思想；
数据驱动思想；
关键字驱动思想；
以上仅仅是代表了一种自动化测试的思想，并不能定义为框架。上面讲到框架=思想+方法，于是演化了以下五种框架：
1）模块化测试脚本框架
需要创建小而独立的可以描述的模块、片断以及待测应用程序的脚本。这些树状结构的小脚本组合起来，就能组成能用于特定的测试用例的脚本。
2）测试库框架
与模块化测试脚本框架很类似，并且具有同样的优点。不同的是测试库框架把待测应用程序分解为过程和函数而不是脚本。这个框架需要创建描述模块、片断以及待测应用程序的功能库文件。
3）关键字驱动或表驱动的测试框架
这个框架需要开发数据表和关键字。
这些数据表和关键字独立于执行它们的测试自动化工具，并可以用来“驱动＂待测应用程序和数据的测试脚本代码，关键宇驱动测试看上去与手工测试用例很类似。
在一个关键字驱动测试中，把待测应用程序的功能和每个测试的执行步骤一起写到一个表中。
这个测试框架可以通过很少的代码来产生大量的测试用例。同样的代码在用数据表来产生各个测试用例的同时被复用。
4）数据驱动测试框架
在这里测试的输入和输出数据是从数据文件中读取（数据池，ODBC源，CSV文件，EXCEL文件，Json文件，Yaml文件，ADO对象等）并且通过捕获工具生成或者手工生成的代码脚本被载入到变量中。
在这个框架中，变量不仅被用来存放输入值还被用来存放输出的验证值。整个程序中，测试脚本来读取数值文件，记载测试状态和信息。
这类似于表驱动测试，在表驱动测试中，它的测试用例是包含在数据文件而不是在脚本中，对于数据而言，脚本仅仅是一个“驱动器”，或者是一个传送机构。
然而，数据驱动测试不同于表驱动测试，尽管导航数据并不包含在表结构中。在数据驱动测试中，数据文件中只包含测试数据。
5）混合测试自动化框架
最普遍的执行框架是上面介绍的所有技术的一个结合，取其长处，弥补其不足。这个混合测试框架是由大部分框架随着时间并经过若干项目演化而来的。
3、接口自动化测试框架策略
设计出来的框架是直接给测试人员，而且其他的测试人员只需要简单的向里面不断的补充测试用例即可；
所以我们的框架设计必须三简化即操作简单，维护简单，扩展简单。
设计框架的同时一定要结合业务流程，而且不仅仅靠技术实现，其实技术实现不难，难点对业务流程的理解和把握。
设计框架时要将基础的封装成公用的，如：get请求、post请求和断言封装成同基础通用类。
测试用例要与代码分享，这样便于用例管理，所以将我们选择上面的数据驱动思想。
4、接口自动化测试框架设计
1）进行接口框架设计前，我们先看看当前的一些主流接口自动化工具框架
2）以上各工具特性
| 工具 | 学习成本 | 录制 | 持续集成 | 测试报告 | 用例管理 | 性能测试 | 扩展难度 | 最低要求 |
|---|---|---|---|---|---|---|---|---|
| Java+testng+Maven | 高 | 否 | 是 | 是 | 难 | 是 | 中 | Java |
| Requests+Python | 低 | 否 | 是 | 是 | 难 | 是 | 中 | Python |
| Robot Framework | 低 | 否 | 是 | 是 | 易 | 否 | 高 | 工具组件 |
| HttpRunner | 低 | 是 | 是 | 是 | 易 | 是 | 低 | Python |
根据以上的特性可得我们优先考虑Python+Requests和HttpRunner；
下面根据其两个框架分别来分析下用例执行过程。
3）用例执行解析
Python的Requests库针对所有的HTTP请求方法，采用的是统一的接口
requests.request(method, url, **kwargs)
其中，kwargs可以保护HTTP请求所有可能用到的信息，例如：headers、cookies、params、data、auth等。
所以，只要遵循Requests的参数规范，在接口测试用例中复用Requests参数的概念即可。而HttpRunner处理逻辑很简单，直接读取测试用例中的各项参数，传递给Requests发起请求。
Requests接口请求示例
def test_login(self):url = "www.xxx.com/api/users/login"data = {"name": "user1","password": "123456"}resp = requests.post(url, json=data)self.assertEqual(200, resp.status_code)self.assertEqual(True, resp.json()["success"])
在该用例中，实现了HTTP POST请求，然后对响应结果进行判断，检查响应code等是否符合预期。
这样的用例在实际项目中会存在两个问题：
用例模式基本固定，会存在大量相似或重复的用例，用例维护有很大问题；
用例与执行代码不分离，参数数据也未分离，同样不易维护；
HttpRunner使用json/yaml格式处理测试用例，分离后的用例描述如下
{"name": "test login","request": {"url": "www.xxx.com/api/users/login","method": "POST","headers": {"content-type": "application/json"},"json": {"name": "user1","password": "123456"}},"response": {"status_code": 200,"headers": {"Content-Type": "application/json"},"body": {"success": true,"msg": "user login successfully."}}}
HttpRunner用例执行引擎
def run_testcase(testcase):req_kwargs = testcase['request']try:url = req_kwargs.pop('url')method = req_kwargs.pop('method')except KeyError:raise exception.ParamsError("Params Error")resp_obj = requests.request(url=url, method=method, **req_kwargs)diff_content = utils.diff_response(resp_obj, testcase['response'])success = False if diff_content else Truereturn success, diff_content
从测试用例中获取HTTP接口请求参数，testcase[‘request’]
{"url": "www.xxx.com/api/users/login","method": "POST","headers": {"content-type": "application/json"},"json": {"name": "user1","password": "123456"}}
发起Http请求
requests.request(url=url, method=method, **req_kwargs)
检测测试结果，即断言
utils.diff_response(resp_obj, testcase['response'])
| 下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
勇敢面对挑战，坚定前行，你的努力终将开花结果。每一步都是向着梦想迈进的力量，相信自己，勇往直前，创造属于你自己的辉煌。
不忘初心，砥砺前行，每一次努力都将成就辉煌。勇敢地迎接挑战，坚定地迈向梦想，因为你的努力终将开启成功之门。相信自己，你必定能创造奇迹。
困难并不可怕，勇敢面对挑战，才能收获辉煌。坚持不懈，努力奋斗，梦想的光芒终将照亮前行的道路。相信自己，你定能创造属于自己的奇迹。