企业官网建设流程全解析

开了个头：为什么我建议每个测试工程师都搞懂这两件事

我入行测试这些年，被问得最多的问题就是“自动化测试和功能测试到底啥区别”“自动化是不是就能代替手工测试了”。说实话，每次听到这类问题我都挺感慨的——不是问题太基础，而是太多人把这两个概念搞成了对立关系，一谈起自动化就两眼放光，一说到功能测试就满脸嫌弃。实际上，真正能扛住线上复杂场景的测试体系，是这两者配合出来的结果。

这篇内容没有任何“教你三天速成自动化”的套路，我就想以一个踩过坑、也把坑填平了的从业者身份，把自动化测试和功能测试这两条线的定位、框架选型、落地路径、平台建设思路，以及面试里高频出现的那些考察点，掰开揉碎了讲清楚。

写这篇详解之前，我特意去翻了手里积攒的多个项目测试方案、自动化平台的迭代记录，还有这几年带团队时整理的问题排查手册。不夸张地讲，下面这些内容里至少有一半，是你在测试文档和官方教程里看不到的——它们全部来自真实项目的“战损”经验。不管你是刚入行的功能测试新人、被领导要求“搞个自动化”但不知道怎么下手的中坚工程师，还是在为跳槽面试做储备的求职者，这篇文章应该都能给你一些能直接上手的思路。

一、先别急着选工具，把功能测试和自动化测试的定位理清楚

1.1 功能测试不是“低端活”，它是整个测试体系的基准线

今天开场先聊功能测试。我知道这个词在很多人眼里显得不够“高级”，尤其是当周围都在讨论pytest、接口自动化框架、AI自动化测试的时候，一个只会点点点的功能测试工程师多少会有点焦虑。但我要先泼一盆冷水：功能测试从来不是自动化的“备胎”，而是所有测试活动的基准线。

那功能测试的核心到底在测什么？用一句大白话说，就是验证软件“做没做对”。它关注的不是性能有多少TPS、不是兼容了多少机型，而是用户能感知到的每一个操作路径是否按照需求文档的预期走通了：登录能不能成功、下单加购物车流程是否顺畅、异常输入会不会导致页面崩溃、删除操作有没有二次确认。这些验证逻辑听起来简单，但在真实业务里，一个边界值没覆盖到（比如优惠券金额等于订单总额的极限情况），上线就是资损的事故。

我在带测试团队时做过一次统计，在一个包含账户体系、支付体系、交易流程、营销活动模块等四个核心业务域的项目中，缺陷总量的68%是功能测试用例发现的，而自动化用例（在回归阶段）只捕获了其中大约24%的缺陷。这个数据不是想证明自动化没用，而是想说明：功能测试阶段是缺陷信息密度最高的时段，它的产出质量直接决定了后续自动化测试能不能构建在一个“缺陷已被充分发现”的稳定版本上。

1.2 自动化测试的价值不是“替代人”，而是“把人的时间省下来做更聪明的事”

那么自动化测试又是在解决什么问题？它的本质目标是重复验证。每提一次代码、每合并一个分支、每次上线前，把核心功能和历史回归用例快速跑一遍，确保你昨天修好的功能今天没有被隔壁模块改动牵连回归。这种“枯燥但必需”的重复劳动，恰恰是机器最擅长的事。

但这背后有一个很关键的认知转变：自动化测试不是把功能测试用例拿到工具里跑一遍就完事了。功能测试的核心资产是测试人员的业务理解——你清楚什么样的场景是关键的、什么样的异常会让用户骂街；而自动化测试的核心资产是代码化表达业务场景的能力——你能不能把上面那个人脑里的业务判断，翻译成pytest、selenium、appium能执行的脚本逻辑。

一个常见的误区是：项目里堆了上千条自动化用例，但断言写得全是“页面打开成功”“接口返回200”，根本不去校验关键字段的值的正确性。这种自动化跑得再绿，也是虚假的安全感。说白了，自动化的高度不会超过团队功能测试设计的水平——用例是烂的，自动化只是把“烂”以更快的速度、更稳定的频率重复了一遍。

1.3 用一张对照表看懂它们的分工和配合关系

很多人喜欢问“自动化测试能不能完全替代功能测试”，我在团队里也经常被这么问。我的回答历来是：**能替代的只是一部分，替代不了的是另一部分。**问这个问题之前，先看下面这个对比。

看过这张表，你就明白我的态度了：两者不是“替代关系”，而是“接力关系”。新功能先靠功能测试把质量基线打牢，稳定后把核心用例沉淀为自动化测试资产，再往后每一次改动就靠自动化快速兜底回归。那些宣称“全自动化”“零手工测试”的项目，要么是业务形态极其简单（内部后台管理系统），要么就是在吹牛。

二、框架选型与测试分层：从pytest到appium到接口自动化

2.1 核心分层模型：把自动化测试拆成三个可独立建设的层级

聊自动化测试，必须先聊分层。分层模型不是某本教科书拍脑袋想出来的，而是从成本、稳定性、维护复杂度三个维度倒推出来的最优解。业内最成熟的分层方式是三层金字塔，我从实际落地角度把它翻译一下：

• 第一层：接口自动化测试（Unit/API层）。这一层离代码最近，测试的是服务端接口的入参校验、逻辑处理、数据返回。它的执行速度最快，一个接口用例通常毫秒级就能跑完，而且非常稳定——接口响应内容和你的UI长什么样没关系。优先级最高，ROI（投入产出比）最优秀。
• 第二层：UI自动化测试（Web/App UI层）。这一层模拟真实用户在页面上的点击、输入、滑动等操作，验证页面元素是否按预期渲染和响应。执行速度最慢，环境稳定性对结果影响巨大——一条网络波动就能让用例误报。它的定位是“少量但关键”，只覆盖核心业务主链路。
• 第三层：手工探索性测试（Manual层）。金字塔塔尖，靠人的业务理解去发现自动化脚本发现不了的问题，尤其是那些跨模块、涉及真实业务判断的场景。

我见过不少团队一上来就盯着UI自动化猛做，结果项目维护成本高得吓人——前端一个按钮改了class名，一百条用例全军覆没，一天时间全花在修定位器上。正确的投入配比是：接口自动化用例占比60%以上，UI自动化占比20%左右，剩下留给人工场景。

2.2 pytest：为什么我最推荐它作为接口自动化的底座

讲接口自动化，就必须提Python生态里的事实标准——pytest。市面上能写接口测试的工具很多：postman、jmeter、httprunner、robot framework都有人用，但要做到复杂断言、灵活的参数化、与持续集成无缝结合，pytest是绕不开的一环。

我给出的理由很具体：

• 断言的天然友好。pytest直接使用Python原生的assert语句，不需要学一套自定义的断言语法，写起来就是普通Python逻辑。比如验证响应JSON里某个字段是否为期望值，一行assert resp_json["code"] == 200就完事。
• fixture机制是接口测试的宝藏。fixture可以处理用例的前置准备和环境清理。比如你需要在接口测试前完成用户登录、获取token、准备测试数据，这个逻辑写成fixture后，同模块下所有用例都能复用，而且pytest会自动管理它的作用域和生命周期——你不用在每个用例里手写重复的setup和teardown。
• 参数化让用例密度成倍提升。同一个接口往往要覆盖几十种入参组合（正常值、边界值、非法值、空值等），pytest的@pytest.mark.parametrize装饰器可以让你把测试数据与测试逻辑分离，一个函数定义一次，数据驱动跑N遍。

光说不练假把式，我放一个简化但完整的小例子，展示pytest结合requests如何搭建接口测试用例。

import requests import pytest BASE_URL = "https://api.example.com" @pytest.fixture(scope="module") def auth_token(): """登录获取token，在整个模块范围内只执行一次""" resp = requests.post(f"{BASE_URL}/login", json={"username": "testuser", "password": "123456"}) assert resp.status_code == 200 token = resp.json().get("token") return {"Authorization": f"Bearer {token}"} # 参数化：一组测试数据对应一组测试用例 @pytest.mark.parametrize("product_id, expected_code", [ ("1001", 200), # 正常商品 ("99999", 404), # 不存在的商品 ("abc", 400), # 非法入参 ("", 400), # 空值边界 ]) def test_get_product_detail(auth_token, product_id, expected_code): headers = auth_token resp = requests.get(f"{BASE_URL}/product/{product_id}", headers=headers) assert resp.status_code == expected_code if expected_code == 200: assert resp.json()["data"]["status"] == "on_sale"

这里有个实操细节值得强调：token fixture用了scope="module"，意味着整个测试模块共享同一个登录态，能显著减少测试耗时。但如果你的接口逻辑依赖不同角色的权限差异，就得拆成多个fixture或者用参数化动态获取token——这是我在真实项目中被坑过之后总结出来的。

2.3 selenium与appium：UI自动化的两条主流路线

聊完接口层，来看UI层的两个扛把子：selenium和appium。

selenium是Web端UI自动化的老牌框架，它的核心机制是通过WebDriver协议驱动浏览器执行操作，支持Chrome、Firefox等主流浏览器。appium则是移动端UI自动化的主流方案，它建立在WebDriver协议之上，扩展了移动端相关的操作能力，支持iOS和Android双平台。

这两个框架在技术理念上高度同源——都是定位元素、执行操作、断言结果这三板斧。但落地时，selenium相对宽容，元素定位手段丰富（id、class、xpath、css selector），调试方便；appium就麻烦不少——首先环境搭建就是一道坎，Android需要配置SDK、连接真机或模拟器、处理adb命令，iOS更是只能在Mac环境处理一堆签名问题。这也是热词里为什么“app自动化测试环境搭建”会被反复搜索，因为不管脚本写得再好，环境搭不起来一切都是零。

我自己在移动端项目上的实践经验是：在移动端UI自动化中，优先用相对稳定的定位策略，少依赖xpath绝对路径。比如Android上用resource-id、iOS上用accessibility id，这些都是开发可以配合暴露的属性，页面结构小幅调整也不至于让用例全挂。相反，xpath写死了层级路径，前端布局一变化，你的用例立刻红成一串。

2.4 接口自动化测试框架的整体组织方式

单独会用pytest还不够，一个能落到项目里的接口自动化框架，至少要包含以下五个组成部分：

• 基础封装层：封装requests请求方法，统一处理请求头、超时、日志记录、异常捕获。调用方不用关心每个接口怎么拼URL、带什么头。
• 测试数据层：把测试数据从测试代码中剥离出来，存放在Excel、YAML或JSON文件中。一旦业务调整，改数据文件而不改用例逻辑。
• 用例管理层：按模块划分test_case目录，每个模块一个测试文件。用例命名遵循test_前缀，pytest就能自动收集执行。
• 测试报告层：集成allure或pytest-html报告插件，把执行结果、失败原因、截图（UI层）呈现出一个非技术人员也能看明白的报表。
• 持续集成层：通过Jenkins或GitLab CI，在代码提交后自动触发测试任务，结果推送到群里通知相关人。

这套结构的核心价值是：用例与数据分离、逻辑与资源分离、执行与反馈闭环。

三、实操记录：从0到1写一个可运行的自动化测试用例

3.1 先定场景再写脚本：一个实际项目的需求拆解

说太多框架概念，不如完整走一遍实操。我用一个实际做过的电商项目中的“商品搜索+购物车添加+订单提交”主链路来演示。

这个项目的业务背景很简单：用户在搜索框输入商品关键词，系统返回商品列表；用户点击商品，进入详情页；用户点击“加入购物车”，系统写入购物车数据；用户提交订单，系统生成订单记录。

在写任何自动化代码之前，先做的事情不是打开编辑器，而是圈定测试范围和断言点。

• 功能测试阶段的用例设计：验证不同关键词的搜索命中情况、空结果处理、加入不存在的商品ID时是否有提示、连续多次加购是否重复计数、提交订单时金额是否与购物车一致。
• 自动化阶段选定回归范围：对上述核心流程建立接口层用例（查询商品接口、加购接口、提交订单接口），再为关键的UI页面（搜索页、详情页、购物车页）建立少量UI冒烟用例。

这种先设计、后编码的顺序，是整个自动化工程里最容易被人忽略却最不能省略的环节。没有范围界定的自动化，最后一定会膨胀成一个不敢改、跑不动、没人维护的遗留系统。

3.2 环境准备与依赖清单

实操之前，先把环境搭建的步骤摆出来，这个清单是多个项目跑下来验证过稳定可用的：

1. 安装Python 3.9+，建议使用虚拟环境管理项目依赖（python -m venv venv），避免多个项目之间包版本冲突。
2. 安装pytest、requests、allure-pytest等依赖。
3. Web UI自动化需要安装浏览器对应版本的WebDriver（chrome driver版本必须与浏览器一致，这一条卡住过无数人）。
4. 移动端App自动化需要安装Appium Server、对应平台的驱动（Android的话还需要配置SDK和adb环境变量）。

下面这段是接口自动化项目的虚拟环境依赖文件，可以直接照抄使用：

# requirements.txt 内容 pytest==7.4.0 requests==2.31.0 allure-pytest==2.13.2 PyYAML==6.0 openpyxl==3.1.2 # 用于读写Excel测试数据

安装命令就一条：pip install -r requirements.txt。如果在公司内网环境，需要提前把依赖包下载到本地或者配置好私有源，否则装包的时候你会经历一段特别漫长的等待。

3.3 从接口用例到UI用例的编写实操

先给一个接口用例的完整示例，这个用例模拟“用户搜索商品并获取商品列表”的接口逻辑：

import requests def test_search_product_list(base_url, auth_token, search_data): """测试搜索商品接口""" url = f"{base_url}/api/search" params = {"keyword": search_data["keyword"], "page": 1, "size": 10} resp = requests.get(url, params=params, headers=auth_token, timeout=5) assert resp.status_code == 200 data = resp.json() assert data["code"] == 0 # 关键断言：返回的商品列表必须包含搜索关键词相关的商品 if data["data"]["list"]: for item in data["data"]["list"]: assert search_data["keyword"] in item["title"]

再看一个selenium对应的Web UI冒烟用例——同样是搜索，但这一层会真实打开浏览器页面操作：

import pytest from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC @pytest.fixture def browser(): driver = webdriver.Chrome() driver.maximize_window() yield driver driver.quit() def test_ui_search_product(browser): browser.get("https://example-shop.com") # 等待搜索框可见 search_input = WebDriverWait(browser, 10).until( EC.visibility_of_element_located((By.CSS_SELECTOR, "#search-input")) ) search_input.send_keys("手机壳") browser.find_element(By.CSS_SELECTOR, "#search-btn").click() # 等待搜索结果区域加载并校验 result_items = WebDriverWait(browser, 10).until( EC.presence_of_all_elements_located((By.CSS_SELECTOR, ".product-item")) ) assert len(result_items) > 0 first_title = result_items[0].find_element(By.CSS_SELECTOR, ".product-title").text assert "手机壳" in first_title

这里有个新手绕不开的坑：UI自动化里大量使用隐式等待和强制sleep。我在代码里用的是WebDriverWait显式等待，这是唯一推荐的方式——不是因为它看起来高级，而是因为页面元素加载有快有慢，显式等待可在元素满足条件的第一时间放行，不浪费系统时间。而固定的sleep(3)要么因等待过长拖慢用例执行，要么因等待不够导致元素未渲染就报错。可以说，从sleep切换到WebDriverWait，是UI自动化脚本从“碰运气”走向“稳定”的第一步。

3.4 执行失败后的排查流程

脚本写完、本地跑通过之后，还有一项工作被严重低估：分析失败用例并分类。

我把自动化排查归纳为一个“三分法”：

1. 看一眼报错类型——是元素定位异常、断言数值不符，还是网络超时？三种情况对应三种不同的排查方向。
2. 看日志和截图——UI层用例在执行中断时自动截图是标配，否则几分钟后的排查你可能完全回忆不起来当时页面长什么样。
3. 看测试数据状态——很多自动化用例失败是因为共享了同一个测试账号，上一个用例把数据改了，下一个用例就跟着遭殃。建议每个用例都用独立测试数据，或者用例间做好数据清理与隔离。

四、聊透自动化测试平台：一个平台应该具备的六种能力

4.1 为什么不能只靠脚本：平台化解决了什么痛点

很多团队走到“脚本化”这一步就停了，每个测试工程师在自己电脑上跑各自的用例，结果可想而知：脚本越跑越多，但执行结果散落在各个人手里，没人能说清楚当前这个版本的自动化覆盖率和通过率是多少。于是“自动化测试平台”这个需求就被推上了台面。

这不是要你做一个像TestRail、禅道那样的大而全的“测试管理平台”，而是做一个能承载自动化测试资产、调度测试任务、沉淀执行结果的一体化基础设施。根据我带团队落地平台的经验，一个真正能用的自动化测试平台，至少要具备以下六种能力。

4.2 平台能力的六项拆解

• 用例管理能力：平台需要能够展示接口用例和UI用例的完整目录树，支持在线编辑、批量导入导出、按模块/标签筛选。更重要的是要有“生效/失效”开关——临时失效的用例不应该删除，但也不该参与常规回归，否则会干扰数据统计。

• 环境管理能力：这是平台建设中经常被低估的一环。测试环境、预发布环境、生产环境的地址和账号体系各不相同，一个成熟的平台必须支持环境配置的动态切换。用例脚本里不应该写死任何环境URL，而是通过平台传入的全局变量动态替换，否则换环境就是在脚本里做“大规模查找替换”。

• 任务调度能力：定时任务和触发式任务缺一不可。定时任务用于每日凌晨跑全量回归，并在上班前输出报告；触发式任务集成在CI流程中，开发提交代码后自动执行冒烟用例，失败则阻止代码合并。这个能力背后需要一套稳定的调度框架，常见方案是Jenkins配合平台接口。

• 执行机资源管理能力：当自动化用例量达到几百上千条时，单机执行就成了性能瓶颈。平台需要管理一批执行机节点（可以理解为多台安装了执行环境的服务器或容器），把用例分发到不同节点并行执行。我在实际项目中，把原本需要3小时跑完的接口全量回归，通过5台执行机并行，压缩到了40分钟以内。

• 数据统计与报表能力：平台要能回答几个核心问题：本版本自动化通过率是多少？哪个模块的用例最不稳定？哪条用例长时间无人维护？通过率趋势图、按模块聚合的用例稳定性排行，都是平台必须具备的看板指标。

• 权限与审计能力：测试资产同样是公司的核心资产，平台要区分管理员、测试开发、普通访客等角色。谁改了用例、谁手动触发了任务、谁删除了历史报告，这些操作日志都要留痕，尤其是多人协作的团队，没有权限体系一定会出现“用例被别人改了但没人承认”的混乱局面。

4.3 平台建设的技术选型建议

关于平台本身的技术架构，给一个既稳妥又不过度设计的组合方案：

• 后端使用Python的主流Web框架（比如FastAPI或Flask），与测试团队的技术栈保持一致，降低维护门槛。
• 前端不用自己从零写组件库，直接用现成的后台管理模板（比如Vue Element Admin），快速搭出用例管理、报告展示等页面。
• 调度依赖用Jenkins做任务触发器，测试平台通过调用Jenkins API来发起执行任务。
• 测试报告优先集成Allure，它生成的可视化报告在行业内接受度最高，展示层级清晰、失败信息完整。

这个组合没有引入特别冷门的高大上组件，每一环都有成熟的社区支撑。平台的核心不是技术多新，而是把自动化的执行过程透明化、结果数据化。

五、常见问题排查与避坑技巧实录

5.1 自动化测试中踩过的高频坑

我把这几年在项目里遇到的、以及在给团队做代码评审时反复见到的典型问题整理成了下面的对照表。这份表格可以当作团队内部排查手册直接使用。

看这张表可以发现一个共性规律：自动化用例90%的“不稳定”都不是产品bug，而是测试工程本身的问题——等待策略不对、数据相互干扰、环境配置漂移。所以处理自动化失败的第一原则是：先怀疑测试代码与测试环境，再怀疑被测系统逻辑。

5.2 一个真实的排查案例：从“偶发失败”到“定位缺陷”

分享一个让我印象深刻的真实排查过程，当时项目里有一套UI自动化冒烟用例，有一条用例每周总会稳定地挂上一两次，重跑之后又通过。团队里同学的惯用操作是“重跑一下看能不能过”，但我强行拦住了一次，抓到了当时的失败截图和日志。

日志显示报错是“元素不可点击”，截图上页面停留在订单确认页，但提交按钮被一个营销弹窗遮挡住了。这个弹窗只在特定条件下出现——用户购物车中存在某一类优惠券时。为什么偶发？因为其他用例执行时消费掉了购物车里的优惠券，到了这条用例时弹窗有时出现、有时不出现。

这其实是一个真实的产品缺陷：营销弹窗不应该遮挡订单提交按钮，它在交互层级上违反了可点击区域的用户预期。自动化用例帮我们抓到了一个功能测试阶段非常容易漏掉的边界场景。从那之后，我把这条用例从“不稳定用例”的名单里保护了起来，并同步给了功能测试同学、让他们把“购物车含优惠券时提交订单”的场景明确补充到手工回归用例中。

这个案例给我的最大启发是：当你面对一条偶发失败的用例，不要急着重跑掩盖问题，而是把它当成一次深入理解业务和系统的机会。每一处“不稳定”背后，要么是测试工程缺陷，要么是隐藏的产品缺陷——两者都有价值，都值得被认真对待。

5.3 维护自动化测试资产：比编写更重要的事

最后这点算是我特别想强调的心法：自动化测试的长期成本在维护，不在编写。

一套自动化测试体系上线第一周通常是最欢乐的，脚本新鲜出炉、每天全绿。然而业务需求不会停止变化，前端页面会改版，后端接口会加字段，测试数据会过期。如果团队没有建立用例维护的固定机制，三个月后你就会看到一个“僵尸自动化方案”：执行能跑，但报告没人看；用例有一千条，但没人敢说它们还符不符合当前业务。

我用来对抗资产腐化的手段包括这么几条：

• 每周固定安排半天“用例保养日”，处理本周失败的用例，判断是脚本问题还是产品变更。
• 建立用例质量评分规则：最近七天内失败但未处理的用例、超过三十天未执行用例、断言内容过于空泛的用例，都有相应的标记和整改任务。
• 自动化报告必须面向“会用的人”设计——团队领导和开发只需要看“什么挂了、影响哪个模块”，具体调试信息放在二级页面里。

这套机制执行下来，我的团队里自动化的“有效性”远比“用例数量”重要得多。不要为了KPI上的自动化覆盖率数字好看而堆用例，那只会让你维护一个越来越沉重的负担。

5.4 结合面试场景：自动化测试面试时会问些什么

因为热词里出现了“自动化测试面试题”，我也顺手总结一下，这几年面试测试工程师时我常考察的几个点。不是要你背答案，而是让你理解：面试官问这些问题，背后到底在考察什么。

• 你如何设计一个接口自动化的测试框架？如果你只说“用pytest+requests”，那是零分回答；有经验的人会说清分层思路：请求封装、数据驱动、断言策略、报告集成、CI触发，每一层传递什么价值。
• pytest的fixture是用来做什么的？scopes有哪些？除了答出“处理前置条件和清理”，最好能举一个实际业务场景——比如“登录状态如何跨模块复用”“临时测试数据如何在用例结束后自动删除”。
• UI自动化中为什么要尽量避免使用静态等待？如果你能顺着这个问题聊到显式等待和隐式等待的区别，再结合实际踩过的坑来讲，面试官基本就能判断出你的实践深度了。
• 自动化用例不稳定怎么排查？这一题考的是问题分析能力。我上面那张“常见问题对照表”里的内容，如果能在面试时信手拈来，就已经超过绝大多数候选人了。

我把这些面试题穿插在这篇文章里，不是让你去背八股文，而是希望你能注意到：面试官真正想了解的，是你面对真实问题时有没有一套自洽的排查思路和判断逻辑。这些思路，上面每一个章节都在一五一十地梳理过了。

写到最后：我个人在实际项目中想再强调的事

这篇文章从功能测试与自动化测试的本质区别，讲到了pytest、selenium、appium的实操，再到平台建设、问题排查和维护机制，内容跨度不小。但我心里清楚，文字永远替代不了你在一个真实项目里把框架跑起来、把平台搭起来的过程。

我个人的实际体会是：自动化测试这件事，难点永远不在某个框架怎么用、某个工具怎么配，而在于你能不能把测试当成一个“长期经营的工程体系”来对待。功能测试和自动化测试，一个负责发现缺陷、一个负责守护质量，两者从来不是竞争关系。优秀的测试团队从不会问“该选手工还是自动化”，他们只会问：当前的业务阶段最需要哪种验证手段，以及我怎么把这两种手段组合成一个可持续运转的体系。

如果你正在准备搭建自动化测试体系，我的建议是：别一上来就铺大摊子，选一个最核心、最有回归价值的业务模块，把接口自动化跑起来，让pytest的绿色报告成为团队的日常；稳定之后再考虑UI层、再考虑平台化。这条路我走过，稳扎稳打地走，效果远比一口吃成胖子好得多。