这篇文章有点特殊给的输入里没有正文和关键词只有标题和一堆热搜词。不过这些热搜词挺有意思里面有不少真实用户在接口自动化这条路上会碰到的痛点比如429限流、Excel读取格式错乱、sw未检测到Excel版本这种幺蛾子。我就顺着题主这个技术栈组合把从环境搭建到报告落地的完整链路串一遍把我实际踩过的坑也一并甩出来。1. 这套技术栈是怎么凑到一起的PythonRequestsPyTestExcelAllure这五个词搁一起乍看像是培训机构的招生简章但真在接口自动化这个方向泡过几年的人会明白这其实是性价比极高的一套组合。我见过不少团队用JavaTestNGExtentReport也见过用PostmanNewman堆case的但Python系这套在中小团队里落地最快、维护成本最低几乎没有之一。为什么这么说先拆开看Python做脚本语言生态成熟写接口测试用例比Java少一半样板代码Requests是Python里最顺手的HTTP客户端封装程度恰到好处PyTest负责用例组织和执行fixture机制比unittest的setUp/tearDown好用太多Excel解决测试数据维护问题让不懂代码的同事也能参与进来Allure则是把执行结果变成一份像样的可视化报告领导看得懂团队复盘也方便。这套组合的核心价值在于它把接口测试的数据执行报告三个环节彻底解耦了。测试人员不需要为了加一条用例去改代码只需要在Excel里加一行执行层只管跑用例、采集结果报告层自动汇总。我见过不少团队自动化脚本装了但每次加用例都要改Python文件跑完了用控制台输出当结果这不是自动化这是给自己找事。适合谁来抄这套方案初学接口自动化的测试工程师、想从手工测试往自动化转的同学、以及团队里已经有接口测试需求但还没找到合适框架的Leader。这套东西学起来曲线不高只要会点Python基础照着下面的思路一步步搭就行。2. 环境准备里最容易翻车的几个环节2.1 Python版本与依赖安装Python装哪个版本Python 3.8往上其实都行3.10、3.11更稳。为什么我不推荐最新版因为第三方库的兼容性永远滞后特别是后面要用的Allure相关插件在Python 3.12上偶尔会出些莫名其妙的兼容问题。这不算什么大坑但没必要给团队埋雷稳妥选择3.10或3.11就好。依赖安装命令如下pip install requests pip install pytest pip install pytest-allure-adaptor pip install openpyxl pip install allure-pytest注意pytest-allure-adaptor和allure-pytest是两个东西。老教程里经常让人装前者但那是Allure 1.x时代的产物了现在Allure 2.x需要的是allure-pytest。我在之前的团队里接手过一个项目就是装错了依赖导致生成的报告目录压根不是Allure能识别的格式白排查了半天。2.2 Allure命令行工具的安装Python库装完还得装Allure命令行本身。它是个Java工具依赖JDK 1.8所以机器上得有Java环境。下载方式就不细说了网上搜Allure下载能找到官方打包好的zip解压之后把bin目录加进系统PATH就行。装完验证一下allure --version能输出版本号就说明OK了。这一步容易踩坑的地方是很多人装完Python库就去跑pytest --alluredir结果Allure命令不存在因为这是两个独立的东西。Python库负责在测试执行时生成XML格式的结果文件Allure命令行负责把这些XML渲染成HTML页面缺一不可。2.3 Excel文件格式的那点事用Excel维护测试数据有个小细节值得注意尽量用.xlsx后缀的文件别用.xls。openpyxl这个库只支持.xlsx老版的.xls需要xlrd才能读而且xlrd2.0之后只支持读取.xlsx了。如果你的测试数据还是老同事传下来的.xls文件第一步就是先另存为.xlsx再进流程。还有个真实场景——热搜词里有一条安装sw出现这样的字样怎么解决未检测到有效版本虽然说的是SolidWorks和Excel之间的事情但原理和接口测试里遇到的Excel问题是一样的Excel文件格式的兼容性牵扯的往往是文件本身被其他进程占用或版本环境不匹配。在我们接口自动化场景里对应的坑是用openpyxl读取Excel时文件被另一个人用WPS或Excel开着导致读取报权限错误。所以数据文件最好放到单独的data目录里并约定执行期间不要手动打开。3. Excel测试数据管理的完整设计与实现3.1 测试数据表怎么设计很多初学的人把接口测试数据一股脑塞进Excel一列里这是最典型的错误设计。字段拆分得越细后期的可维护性越好。我建议的列设计如下列名含义示例case_id用例唯一标识TC001module所属模块用户模块api_name接口路径/api/user/loginmethod请求方法POSTheaders自定义请求头{Content-Type:application/json}paramsGET参数{page:1}json_dataJSON请求体{username:admin}expected_code期望HTTP状态码200expected_msg期望响应关键字successis_run是否执行Y/N这套字段覆盖了90%以上的接口测试场景。我见过有些设计把基础URL也放进Excel里比如https://xxx.com/api/user/login这其实是个设计失误——环境一换整列数据都要改。正确的做法是Excel里只存接口路径协议、IP、端口这些环境信息放到配置文件中统一管理。3.2 用openpyxl封装一个数据读取模块读取这块直接上代码import openpyxl import json def read_excel_data(file_path, sheet_nameNone): 读取Excel测试数据返回列表套字典的结构 workbook openpyxl.load_workbook(file_path, data_onlyTrue) sheet workbook[sheet_name] if sheet_name else workbook.active headers [] rows_data [] for row_index, row in enumerate(sheet.iter_rows(values_onlyTrue)): if row_index 0: headers list(row) continue # 跳过空行 if row[0] is None: continue case_data {} for col_index, cell_value in enumerate(row): header headers[col_index] # 处理JSON格式的字段 if header in [headers, params, json_data] and isinstance(cell_value, str): try: case_data[header] json.loads(cell_value) except json.JSONDecodeError: case_data[header] {} else: case_data[header] cell_value rows_data.append(case_data) return rows_data这里有几个细节必须说明data_onlyTrue这个参数如果你在Excel的单元格里写了公式比如拼接URL那么不传data_only时openpyxl读出来的是公式本身传了才能读到公式计算后的值。而且注意data_onlyTrue必须等到Excel文件被某个支持公式计算的软件打开过并保存之后公式结果才会被缓存否则读出来还是None。这个坑我踩过一次后来直接把测试数据里的所有公式都去掉了纯用静态值。JSON字段的解析问题我建议在Excel单元格里JSON字段就用标准JSON字符串格式比如{page:1}。openpyxl读出来的确实是字符串所以用json.loads转一下。但有个问题——如果你的JSON里中文是以Unicode编码存的比如Excel在某些环境下会自动转码json.loads之后要再做一次ensure_asciiFalse处理不然测试数据里的中文就变成\u7528\u6237这种东西了。3.3 数据驱动与用例的映射关系数据读取模块封装好了怎么把数据喂给用例最常用的是通过PyTest的pytest.mark.parametrize参数化。import pytest from utils.excel_reader import read_excel_data all_cases read_excel_data(./data/api_cases.xlsx, 登录模块) pytest.mark.parametrize(case, all_cases, idslambda case: case[case_id]) def test_login(case): ...注意这里的ids参数。如果不指定测试报告里显示的是case0、case1这种毫无意义的标识指定了idslambda case: case[case_id]报告里就能直接看到TC001排查问题的时候一眼就能定位到具体Excel行。还有一个常见问题Excel数据是一次性全部读入的还是每个用例单独读取我个人建议在conftest.py里用session级fixture读一次然后通过request.param传给用例。如果每次执行用例都重新解析Excel数据量大了之后性能损耗很明显尤其是几千条用例跑一轮几个小时的场景下这种无谓的解析开销积少成多会让整个执行周期明显拉长。4. Requests层封装为什么需要封装以及封装成什么样4.1 直接裸写Requests的问题初期写接口自动化大家都喜欢直接一个requests.get(url)扔上去跑通了就完事。但项目一复杂问题就冒出来了每个接口都要拼完整URL环境切换时改到吐血登录接口返回的token每个接口都要手动塞进header里响应结果没有统一校验逻辑每个用例自己写断言风格乱七八糟请求失败时没有日志出了问题只能靠print猜测。所以我封装了一个ApiClient类把公共逻辑收敛到一处。4.2 ApiClient的核心设计import requests import json import logging from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry logger logging.getLogger(__name__) class ApiClient: def __init__(self, base_url, tokenNone, timeout10): self.base_url base_url.rstrip(/) self.session requests.Session() self.timeout timeout # 重试机制 retry_strategy Retry( total2, backoff_factor0.5, status_forcelist[429, 500, 502, 503, 504], allowed_methods[GET, POST, PUT, DELETE] ) adapter HTTPAdapter(max_retriesretry_strategy) self.session.mount(http://, adapter) self.session.mount(https://, adapter) if token: self.session.headers.update({Authorization: fBearer {token}}) def _request(self, method, path, **kwargs): url self.base_url path kwargs.setdefault(timeout, self.timeout) kwargs.setdefault(verify, False) # 关闭SSL警告 requests.packages.urllib3.disable_warnings() response self.session.request(method, url, **kwargs) logger.info(f[{method}] {url} - {response.status_code}) return response def get(self, path, **kwargs): return self._request(GET, path, **kwargs) def post(self, path, jsonNone, **kwargs): return self._request(POST, path, jsonjson, **kwargs) def put(self, path, jsonNone, **kwargs): return self._request(PUT, path, jsonjson, **kwargs) def delete(self, path, **kwargs): return self._request(DELETE, path, **kwargs)这段代码里有几个设计决策值得展开说说。Session还是裸请求用requests.Session()比直接调用requests.get/post多了一个持久连接和cookie自动管理的机制。接口自动化场景里多个接口往往属于同一个会话登录之后cookie和token需要被后续请求自动带上Session直接解决了这个问题。另外Session还自动复用底层TCP连接执行几千条用例时性能更优。重试机制为什么加上429热搜词里有个现象挺典型exceeded retry limit, last status: 429 too many requests——很多人在跑接口测试时碰到过限流。如果你测的接口背后有网关或限流策略尤其是那种认证请求有更高额度限制的接口429会时不时冒出来。直接让用例失败不太公平但重试太激进又会把服务打死。所以我配置了total2最多重试2次、backoff_factor0.5重试冷却按0.5秒递增即第一次0.5秒第二次1秒。这个配置在大多数场景下比较温和既不会因为瞬时限流误报也不会对服务造成二次压力。verifyFalse的使用很多公司的测试环境是自签HTTPS证书requests默认会校验证书不关掉就直接SSL报错。加了verifyFalse再配合disable_warnings()请求才能通畅。但在生产环境跑测试时建议还是把verify设为True安全至上。4.3 响应断言怎么写才省心封装了请求还得封装断言。我之前见过一个项目的断言写成这样assert response.json()[code] 200单独看没错但每个用例都写一遍等于把断言逻辑散落到各处。更好的方式是做一个断言工具类支持多种断言类型import json import re def assert_response(response, expected_code, expected_msgNone): 统一的响应断言函数 assert response.status_code expected_code, \ f状态码不一致期望:{expected_code}实际:{response.status_code}响应体:{response.text} if not expected_msg: return try: body response.json() except json.JSONDecodeError: body response.text # 直接返回布尔值的断言 if expected_msg in (true, false): assert body is (expected_msg true), f布尔断言失败响应体:{response.text} # 正则匹配 elif expected_msg.startswith(regex:): pattern expected_msg[6:] assert re.search(pattern, response.text), f正则 {pattern} 未匹配响应体:{response.text} # 普通关键字包含 else: assert expected_msg in response.text, f关键字 {expected_msg} 未出现在响应中响应体:{response.text}这里的思路很简单状态码是硬性的必须精确匹配响应内容可以根据需要选择关键字包含、正则匹配或布尔值匹配。Excel的expected_msg列里可以直接写success、写regex:\token\:\([a-zA-Z0-9])\或者写true。灵活性远比一刀切的必须包含xxx要高。5. PyTest用例编排fixture、参数化与钩子5.1 全局fixture规划PyTest的fixture机制是整个用例组织的核心。我建议把公共fixture统一放在conftest.py里这文件是PyTest的特殊约定文件它能自动被发现不需要手动导入。一个典型的conftest.py长这样import pytest import logging from utils.api_client import ApiClient from utils.excel_reader import read_excel_data logging.basicConfig(levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s) pytest.fixture(scopesession) def base_url(): 从配置文件读取基础URL from configs.config import ENV return ENV[base_url] pytest.fixture(scopesession) def client(base_url): 创建一个无token的API客户端实例只在session范围内创建一次 return ApiClient(base_url) pytest.fixture(scopesession) def login_token(client): 登录并返回token整个测试过程中只登录一次 resp client.post(/api/user/login, json{username: admin, password: 123456}) token resp.json()[data][token] return token pytest.fixture(scopesession) def auth_client(base_url, login_token): 带token认证的API客户端 return ApiClient(base_url, tokenlogin_token) pytest.fixture(scopefunction) def case_data(): 每条用例数据每次测试重新加载 return read_excel_data(./data/api_cases.xlsx)fixture的scope参数决定了生命周期。session表示整个测试会话只创建一次登录token这种成本高的操作放在session级fixture里避免每条用例都重新登录大幅提升执行效率。注意登录token有可能过期如果你的接口token过期时间很短比如5分钟session级fixture就不合适了建议改成module或直接用单独的fixture放token过期校验逻辑。5.2 parametrize与Excel数据的深度绑定参数化是PyTest最核心的用法之一。前面提到过用read_excel_data读取Excel数据然后在测试函数上加pytest.mark.parametrize注解。比较规范的写法是import pytest from utils.excel_reader import read_excel_data login_cases read_excel_data(./data/api_cases.xlsx, 登录模块) pytest.mark.parametrize(case, login_cases, idslambda c: c[case_id]) def test_login_cases(auth_client, case): if case[is_run] ! Y: pytest.skip(f{case[case_id]} 跳过执行) method case[method].lower() path case[api_name] response None if method get: response auth_client.get(path, paramscase[params] or {}) elif method post: response auth_client.post(path, jsoncase[json_data] or {}) assert_response(response, case[expected_code], case[expected_msg])有个比较实用的操作用pytest.skip来处理is_run标记。我见过不少团队把不执行的用例从Excel里删掉这是很危险的动作——删掉容易但等你想恢复这条用例回滚验证的时候数据找不回来了。用is_run列标记用例保留在Excel里只是执行时跳过。报告里也会显示为跳过保留完整的执行链路。5.3 钩子函数做失败自动截图和录制请求日志PyTest最强大的地方在于它提供了非常灵活的钩子函数hook。我特别推荐两个钩子一个用来做失败时的请求响应日志采集一个用来给用例标记上下文中关联的接口信息。# conftest.py pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: # 从item里获取请求和响应的上下文 context item.funcargs.get(_api_context) if context: request_info context.get(request, 无) response_info context.get(response, 无) logging.error(f用例 {item.name} 失败\n f请求信息: {request_info}\n f响应信息: {response_info})配合在测试函数里把请求响应塞到上下文pytest.fixture def _api_context(): return {} pytest.mark.parametrize(case, login_cases, idslambda c: c[case_id]) def test_login_cases(auth_client, case, _api_context): ... _api_context[request] f{method.upper()} {path} _api_context[response] response.text ...这样失败用例会自带请求和响应快照排查问题不需要重新跑一遍用例效率翻倍。这个设计是我个人极力推荐的接口自动化的核心价值就是快速定位不是帮你把用例跑绿。6. Allure报告不只是好看关键是要信息密度高6.1 生成报告的正确姿势# 执行测试并产生allure结果文件 pytest --alluredir./allure-results --clean-alluredir # 启动本地报告服务 allure serve ./allure-results # 或者生成静态HTML文件 allure generate ./allure-results -o ./allure-report --clean # 如果需要保留历史趋势加上这个参数 allure generate ./allure-results -o ./allure-report --clean--clean-alluredir很关键它会在每次执行前清空历史结果文件避免旧数据混进来。不然你跑了100条用例新版本只跑了50条报告里可能出现上轮残留的50条假装跑过的用例。allure serve会在本地起一个HTTP服务并自动打开浏览器适合开发时快速预览。想要真正交付报告文件或者集成到CI平台用的是allure generate生成一个静态HTML目录。6.2 装饰器使用技巧Allure最核心的价值在于它有层次结构让报告从一坨用例列表升级为带业务模块划分的测试报告。import allure allure.epic(用户中心) allure.feature(登录模块) allure.story(正常登录) allure.title(TC001-用户名密码正确登录成功) allure.severity(allure.severity_level.BLOCKER) def test_login_cases(...): ...层级关系是epic项目/产品线 feature功能模块 story业务场景 title具体用例。一份好的报告执行完应该能让不懂代码的产品经理一眼看出用户中心这个模块的用例是不是全绿。另外还有几个非常好用的装饰器allure.link(url, namexxx)在报告里挂上系统需求或接口文档链接别人看报告时能直接跳转allure.attachment(请求参数, content, ...)把请求体内容挂到报告里代码里用allure.attach函数即可allure.description给用例补一段文字说明为啥这条用例要测这个场景。6.3 环境信息与类别清洗生成报告时默认会带上运行环境信息但默认内容比较少。你可以手动创建一个environment.properties文件放到allure-results目录下里面像这样BaseURLhttps://test.api.example.com Python3.10.0 Requests2.28.1 Browserheadless 执行环境本地这样报告顶部的Environment栏就会显示这些信息对多人协作时快速判断这份报告是哪个环境跑出来的用的什么版本代码非常有帮助。还有一个容易被忽略但是很实用的配置——categories。Allure默认把失败用例归为测试失败把被中断的归为测试中断但实际排查问题的时候这个分类太粗了。可以在allure-results目录下建一个categories.json[ { name: 接口超时, matchedStatuses: [failed], messageRegex: .*Timeout.*|.*timed out.* }, { name: 服务端异常, matchedStatuses: [failed], messageRegex: .*500 Internal Server Error.* }, { name: 限流, matchedStatuses: [failed], messageRegex: .*429.* } ]这样那些因为限流429失败的用例会自动归到限流类别里一眼能看出来团队的接口是不是被压测机或者自动化测试打爆了。6.4 中文乱码那点破事用Windows跑Allure报告时经常看到一堆锟斤拷或者???这是编码问题。原因通常集中在两个方面一是pytest执行时控制台的输出编码和Allure写入结果文件时的编码不一致二是Windows下的Java进程默认不是UTF-8。最省事的解决办法# Windows下设置环境变量 set JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8 # 或者临时用 java -Dfile.encodingUTF-8 -jar allure-commandline.jar ...这个坑几乎每个在Windows上跑Allure的人都遇到过方法虽然简单但不提前设置的话报告里的中文标题全变乱码领导看一眼就不想看了。7. 工程化落地从能跑到跑得长久7.1 项目目录结构我推荐的目录结构长这样api_test/ ├── configs/ │ ├── __init__.py │ ├── config.py # 环境配置管理 │ └── settings.py # 全局常量 ├── data/ │ ├── api_cases.xlsx # 接口测试数据 │ └── environment.properties ├── tests/ │ ├── __init__.py │ ├── conftest.py # 全局fixture和钩子 │ ├── test_login.py │ └── test_user.py ├── utils/ │ ├── __init__.py │ ├── api_client.py # 请求封装 │ ├── excel_reader.py # 读取Excel │ ├── assert_utils.py # 断言工具 │ └── logger.py # 日志配置 ├── reports/ # 生成的报告 ├── requirements.txt └── pytest.inipytest.ini里可以放一些运行配置[pytest] addopts -v -s --alluredir./allure-results --clean-alluredir testpaths ./tests python_files test_*.py python_classes Test* python_functions test_*addopts很关键它让你不用每次敲一长串参数直接在命令行跑pytest就带了Allure的配置。但注意CI环境里如果还要叠加其他参数注意不要重复定义同一参数导致冲突。7.2 多环境切换的设计接口测试最要命的就是环境管理。dev、test、staging、prod每个环境的前缀URL不一样还有可能各自的账号权限不同。我在configs/config.py里用的方案是import os ENVIRONMENTS { dev: { base_url: http://192.168.1.100:8080, username: test_dev, password: test_dev_pass }, test: { base_url: http://test.api.example.com, username: test_user, password: test_pass }, prod: { base_url: https://api.example.com, username: monitor_user, password: monitor_pass } } # 通过环境变量或命令行参数指定 ENV_NAME os.getenv(TEST_ENV, test) ENV ENVIRONMENTS[ENV_NAME]然后在命令行执行时TEST_ENVtest pytest这套方案的好处是代码里不出现任何环境的硬编码URL所有用例都通过base_url这个fixture获取当前环境的基础地址。换环境跑测试只需要改一个环境变量Excel里的数据不用动。7.3 接入CI的思考网上很多教程会告诉你把pytest命令挂到Jenkins/GitLab CI上但具体怎么挂很少有人讲明白。我的建议是在CI的构建步骤中安装Python依赖最好做一个独立的虚拟环境执行pytest命令并生成Allure结果用Allure官方提供的allure-jenkins-plugin之类的集成插件或者直接跑allure generate后把HTML目录作为制品发布。这里唯一的坑是CI机上的JDK版本。Allure 2.20需要JDK 11JDK 8会起不来。之前有同事在Jenkins的从节点上没配JDK 11结果每次生成报告都报错检查到想砸电脑。8. 实际踩过的坑和后续优化的方向8.1 我在这个技术栈上踩过的几个深坑坑一openpyxl读取日期格式变成一串数字Excel单元格里存的是日期格式openpyxl读出来是一串整数比如45391代表2024-04-12。这个问题在接口测试数据里尤其隐蔽——如果你某个字段恰好是个日期参数比如用户生日、活动开始时间从Excel读出来变成45391请求发出去后端直接报参数格式错误。解决办法两种要么在Excel里把日期列设为文本格式这样openpyxl按字符串读要么在读取代码里做判断把datetime对象或数值转成yyyy-MM-dd格式from datetime import datetime, date def format_cell_value(value): if isinstance(value, (datetime, date)): return value.strftime(%Y-%m-%d %H:%M:%S) return value坑二pytest参数化后Excel数据被反复读取前面我强调过用session级fixture读一次Excel但有人图省事把读取逻辑直接放在模块顶层all_cases read_excel_data(./data/api_cases.xlsx)这其实是可以的因为Python模块只会加载一次不会反复读取。但是如果你把这个读取逻辑写在测试函数内部Parametrize用例数量是执行前确定的这部分不受影响真正会反复读取的是每个用例内再去读Excel的写法几百条用例下来磁盘IO损耗大。坑三429限流的误伤热搜词里反复出现429说明很多人被接口限流折磨过。我的建议是自动化测试执行前先和服务端确认限流阈值如果条件允许用测试环境的独立限流配置。重试策略放在ApiClient里但也不建议把所有失败都归为网络抖动去重试只在明确已知会偶发限流的场景下启用重试否则重试会把服务打得更惨。坑四Allure历史报告覆盖问题allure generate --clean会清空输出目录但如果你没有配置每次生成的汇报HTML里历史趋势图永远是空的。想要保留历史趋势需要在allure generate时不要清空allure-report/history目录或者在专门的CI流水线用Allure的--report发布机制。我本地直接看报告一般不管这个趋势图但如果要定期发给团队这个历史趋势是很有参考价值的建议研究一下。8.2 后续可以扩展的方向这套基础框架跑通之后往上叠东西的路径很清晰接口依赖处理登录token拿到后存到文件或内存缓存测试用例里通过fixture拿支持多接口串联测试数据断言增强遇到复杂嵌套JSON响应直接用jsonpath库提取字段再做断言覆盖率统计结合服务端的接口定义文档比如Swagger/OpenAPI把Excel里的用例和接口定义做映射自动检查哪些接口还没覆盖到测试数据性能回归在ApiClient里加耗时统计每次跑完自动输出接口平均耗时、P99耗时接口经常变慢的话一眼就能看出来数据构造测试前置数据如果依赖数据库可以在fixture里直接用pymysql连库造数据跑完再清理保证用例可重复执行。8.3 个人一点真实体会说实话PythonRequestsPyTestExcelAllure这套组合有它的天花板——Excel一旦超过几百条用例维护起来就会有点力不从心用例执行时间长了以后排查失败的效率反而会成为瓶颈。但作为一个入门到中级接口测试团队的基础设施它依然是我目前最推荐的起步方案。原因是它的学习成本低、组件替换灵活比如Excel可以换成YAMLPyTest可以单换成Robot Framework、各环节都能拆分独立优化。在我的使用经验里最值得花时间的部分是把Excel数据结构和断言逻辑做规范让测试团队的新人哪怕不会Python也能照着Excel模板往里加用例。这套东西真正用好了能省下的时间远比搭它花掉的时间多。