背景

之前在社区里看到的一篇关于接口自动化测试平台的文章https://testerhome.com/topics/38797 ，试用了下后就想写写关于自动化的，顺便说下为什么大多数功能测试会觉得测试平台不好用的典型原因，大佬们轻喷。

一、接口自动化到底要验证什么

-> 个人觉得做什么事情前，应该想下做的动机和想要达成的目的，这样会减少很多不必要的弯路

1. 自动化的原因

• 测试界普遍认为应该加自动化用于提高测试效率和保障
• 测试 kpi 任务
• 应对需要频繁执行的测试场景
• 需要增加信心和可靠性

2. 理想中的目的

• 线上定时巡检，监测系统稳定性，更早地发现问题，减少故障恢复的时间

• 辅助提高回归测试质量（就是辅助作用，别想着能靠自动化发现大问题）

• 记录每次巡检的结果，有助于团队了解系统的历史性能

3. 接口自动化的设计方向

-> 说到底接口自动化的所有处理就是围绕下面三步去提取测试点和选型工具，并没有什么很高大上的东西，底层还是看写测试点的这个人的业务水平，创建出有效的测试点。

我们基本根据这三步和上面的目的去规划测试点和实现方式

• 3.1 工具选择原则：

-

• 3.2 主要测试点提取

-

• 3.3 测试场景实现难点（大部分都能借助测试框架解决，解决不了的就用工作流程解决，再解决不了的就不用解决，自动化测试只是辅助措施）

-> 这里用 pytest 的测试框架来描述解决方法，不同的测试框架自己找对应的方法

4. 自动化实现中的实际痛点

-> 现在的普遍论调应该基本都是在技术优化上，但是实际上自动化测试的实际痛点的本质上因为人的痛点：

• 1.日益增长的工作内容同有限人力之间的矛盾
  • 有限的测试人力无法满足日益增加的测试需求/要求
  • 引入自动化测试无法减少工作量的增加，却要挤出时间和资源去实施和维护一个辅助性质的自动化

-

• 2.理想化愿景与实际可行性之间的矛盾
  • 平台化设计过度复杂，想要覆盖各种测试需求，导致用例创建繁琐、学习曲线陡峭
  • 妄想匹配所有项目需求，不断细化和组件化等，导致失去灵活性、增加维护成本

-

• 3.技术追求与实际需求之间不平衡的矛盾
  • 倾向于追求更高级、复杂的技术，以展示其专业技能，导致出现用很复杂的流程和实现方式去验证一件反而简单的事
  • 封装过度，导致代码难以理解和维护（我们不是开发，没必要防御性编程）

-

• 解决思路：
  • 1>自动化设计就要立足于实际的项目需要，只关注当前项目的核心功能和业务流程，不盲目追求覆盖率，只对关键路径、核心功能和高风险场景进行自动化，不一定动辄就是测试平台
  • 2> 接口自动化性价比最高的就是脚本化（复制粘贴是真的方便）搭配一个成熟的测试框架，不搞花里胡哨的封装和平台化，力求易读、易维护的自动化测试脚本
  • 3> 不追求更高级的技术，注重实用性/快捷性，自动化的关键点不是你用了什么技术去做请求断言返回，而是你的这个用例关注的方向对没。（你用 Java 搞了个平台创建断言了接口返回 和 我用 postman 写了个脚本断言返回，测试结果效果上有什么质的区别吗？）

-

5. 自动化搭建大致过程

• 1. 选择一个合适的工具
• 2. 根据我上面主要测试点提取的表，选择需要验证的内容进行断言
• 3. 利用 codeGeex/gpt 的辅助，一步步把需要完成的自动化搭起来
• 4. 后续随着用例数和场景复杂了，遇到什么问题就有什么解决什么，你不可能一开始就能想到全部的问题

如果你是用 python，大致用到的就是这些，除了通用的 http 请求，如果有其他协议，就找对应协议的库

测试框架：
pytest： 用于编写和执行测试用例，支持参数化测试、夹具等功能。
HTTP请求库：requests： 用于发送HTTP请求，方便处理接口的GET、POST等操作
数据驱动：yaml： 用于存储测试数据，例如接口请求参数、期望响应等。可以使用PyYAML库解析YAML格式的数据文件。
数据库连接：mysql-connector-python，用于与MySQL数据库建立连接，执行数据库操作，例如验证接口返回的数据与数据库中的数据是否一致。
日志记录：logbook，用于记录测试过程中的日志信息，有助于排查问题和进行调试。
报告生成：allure-pytest，结合pytest和Allure生成详细的测试报告，提供可视化的测试结果和执行历史。

二、目前测试平台有什么奇怪点

了解问题的核心关键在于 “从群众中来,到群众中去”，这句话同样适用于测试岗，很多平台都会标注【独特的用例编写方式】、【低门槛，易使用】的特性，但是实际上都是粗制 web 化的 jmeter 或者粗制 web 化的 postman 又或者是奇葩的低代码拖拽，不仅创建用例麻烦不灵活 且 调试接口费时间，功能细化和封装过度也导致了不小的学习使用成本，且该学习成本不像 jmeter 这种工具的使用经验那样可复用。这些既不能提高效率又不能用来提高测试水平的做法用一句话来形容的话就是：“离群众太远了”。

-

1. 测试平台使用槽点

测试平台交互模式：
- 1. 创建项目 ->创建模块->创建 case->关联项目->关联模块
- 2. 编写 case：请求参数、前后置、预期值等多个输入框，需要逐个点击填写信息 (和 jmeter 创建用例的方式有什么区别？),当接口发生变更时，也是需要逐个用例手动修改信息，维护成本高,用例的可读性也差
- 3.调试 case: 调试信息不够清晰且慢，调试出问题时也无法马上明确是平台问题还是接口本身问题

-

2. 测试平台的设计通病

- 把【低门槛，易使用】理解为：不用写代码就是容易用，抛开实际意义上的实用。
- 太想通用：平台的灵活性本身比较差，为了增加灵活性又为了考虑功能测试不懂代码，通常都会将多种操作流程组件化，增加很多配置项。但是一件产品如果是一端的产出，没有对应的产品、测试和持续的用户反馈，必定会有设计不当或者过度组件化，导致测试用例的抽象层次变得复杂、上手难度增加、执行有性能问题等
- 鸡肋：为体现自身技术，选型难度较大的前后端技术栈，过度追求技术炫耀让平台更难理解和使用，底层逻辑还是走的对返回包的断言，导致难以让人信服。就像赛博丁真绕了个大圈关灯一样

-

3. 意识形态差异：

- 都什么年代了，现在面试功能测试哪个不要求基本的代码脚本能力？，更别说现在都有 gpt 加持，真的不用特别考虑测试无代码能力的场景
- 都是测试，肯定是希望通过写脚本去巩固自己熟悉的开发语言，即使繁琐，也有学习成长的快感

三、写自动化的心理误区

1. 没使用设计模式，很心虚

• 特别是新手，认为如果没有使用设计模式来编写自动化测试代码，就会感到不够专业或不足够好。
• 设计模式的确在自动化测试中可以提高代码的可维护性和可扩展性，但并非所有项目都需要复杂的设计模式。如果你只是为了实现简单的接口测试，引入设计模式只会导致代码过于复杂，增加了维护成本。
• 设计模式是一个不断演进的过程，可以在需要的时候逐步引入，而不必为了设计模式而设计模式。始终专注于编写简单、可读、可维护的脚本。
  

哪怕你用下面最简单明了的模式，哪又怎样？ 能达到自动化的目的即可，干嘛要折磨自己（个人见解，大佬忽略）

project_root/
|-- api_tests/     存放 API 测试用例的目录
|   |-- project1/      项目1
|   |   |-- __init__.py
|   |   |-- test_api_project1.py
|   |   |-- utils/
|   |       |-- __init__.py
|   |       |-- api_client_project1.py   封装 API 请求的客户端工具
|   |-- project2/          项目2
|       |-- __init__.py
|       |-- test_api_project2.py
|       |-- utils/
|           |-- __init__.py
|           |-- api_client_project2.py   封装 API 请求的客户端工具
|-- conftest.py      共享的 fixture 和配置信息
|-- pytest.ini          Pytest 的配置文件
|-- requirements.txt

-

2. 过度关注工具而非测试目标

• Java 的 TestNG、python 的 pytest、jmeter、postman 还是在前面工具基础上封装平台，本质上都是向目标接口发出请求再进行断言，不管技术实现上有多难，最后实现的测试目标都是一样的。
• 自动化最终难题都在用例维护和管理上，即使平台化也是如此。
• 测试用例的设计和执行质量直接影响测试的有效性，良好设计的测试用例可以更好地捕捉潜在的问题，而低质量的测试用例可能导致遗漏重要的测试点

-

3. 一切都可以自动化

• 自动化是业务逻辑抽象的结果，只是业务逻辑测试的一种方式，相比手工的确是效率更高些，但是需要一个基础条件：稳定的项目

-

4. 试图一步到位

• 一开始就想覆盖所有的接口和测试场景，徒增压力和维护成本
• 要逐步增量的方法，从一些核心的接口和关键的测试场景开始，逐步扩展测试范围。

"To be continued。。。"
先记录着，有时间再回来改下，话说社区的 markdown 语法能不能支持下字体颜色还有换行。。。。