★ FEATURED ARTICLE 这已经是这个系列的第七篇了。前面几篇把软件测试的基础理论、用例设计、缺陷管理这些底子都打了一遍从这篇开始我们正式扎进自动化测试的实战泥潭。先说句不太好听的大实话很多人学自动化测试是从照着网上的视频抄一段Selenium脚本开始的结果脚本跑起来没几天就挂元素定位不到、用例互相影响、维护成本比手工点一遍还高最后项目不了了之。这不是你不行而是从一开始就把自动化这件事想窄了。这一篇我不会再给你堆框架API的文档翻译而是把自动化测试从“要不要做”“怎么做”“踩坑了怎么修”到“面试怎么聊”完整捋一遍。不管你是在准备软件测试面试还是工作中要接手一个自动化测试项目或者想基于Playwright、pytest、Appium搭一套能真正落地的东西这篇都适合你。我会把接口自动化、UI自动化、App自动化、嵌入式与物联网测试、以及这几个人都在提的AI辅助生成自动化脚本这些方向串起来讲尽量让你看完能直接照着做。1. 自动化测试的“为什么”先想清楚再做1.1 自动化并不是“把手工用例翻译成代码”我最常见到的错误操作就是把现有的手工测试用例一条条“翻译”成自动化脚本。比如手工用例里有50条登录相关的用例那自动化也照着写50条登录脚本。结果是什么登录页面稍微改个按钮位置50条用例全军覆没你花了一个通宵去修定位符第二天产品又改了直接心态爆炸。自动化的核心价值不是“替代手工”而是“用机器的时间换人的时间”。它真正擅长的是三类事情第一高频回归也就是每次发版都要反复验证的核心路径第二大批量数据准备和清理比如测试环境需要100个不同状态的订单第三需要长时间稳定运行的验证比如接口压测、稳定性测试。至于探索性测试、界面视觉走查、突发线上问题的快速验证这些场景自动化帮不上忙甚至还会拖后腿。所以动手之前先把你要自动化的对象筛一遍。我的习惯是让团队先回答三个问题这个功能一个月内会被手工回归多少次它的页面或接口在可预见的未来会不会频繁改动测试环境是可复用的、数据是可控的吗如果答案分别是“经常”“会改”“不稳定”那这个功能就不该上自动化或者至少不该一上来就全量铺开。1.2 三个判断标准与ROI账本聊ROI不一定非要算精确的工时成本但心里得有本账。我在决定要不要做一套自动化时会粗略估一个公式自动化一次性投入脚本开发调试必须小于手工单次执行成本乘以未来执行次数再打个维护折扣。举个例子一条接口用例手工执行一次大概5分钟一个月要回归20次一年就是1200分钟也就是20个小时如果写脚本只要1个小时那毫无疑问值得做。反过来一个一年才回归两三次的后台报表页面你花半天写脚本就纯属自己感动自己。顺着这个思路你也能理解为什么“自动化测试平台”这个概念在国内的软件测试面试和实际招聘里那么火。一个真正能用的平台不只是把测试脚本塞到Jenkins里跑一跑它至少需要具备用例管理谁写的、覆盖什么需求、是否过期、执行调度定时触发、按标签选择、失败重跑、结果聚合与报告通过率、失败趋势、历史对比、告警通知失败了发给谁、以及数据沉淀哪些模块的自动化是稳定的、哪些模块一直在修脚本。这些能力哪怕你用开源的pytest Allure Jenkins去拼也应该在动手前先规划出来而不是等项目跑挂了再补。2. 框架选型与工程搭建动手前先定骨架2.1 Python技术栈主流框架横向对比自动化测试的技术选型我一直推荐从Python起步。理由很现实写起来快、生态全、社区里踩坑记录多而且大部分测试团队的代码基础就是Python。当然你团队全是Java那就用Java没必要为了“潮流”硬换语言。选框架的时候别听别人说“我们公司用XX”就无脑跟要看你的实际对象是什么。测试层级主流方案优势常见的坑接口自动化pytest requests轻量、灵活、断言直观用例之间共享数据导致互相污染UI自动化WebPlaywright / SeleniumPlaywright自动等待、多浏览器、能拦截网络Selenium定位不稳定、执行速度慢UI自动化AppAppium / MaestroAppium生态成熟、支持安卓iOS双端环境搭建麻烦、真机兼容性难搞数据驱动pytest yaml/json/excel用例与代码分离非技术同事也能维护过度设计一个小项目引入一堆抽象层这里我尤其想提醒一句如果是新项目Web端UI自动化优先考虑Playwright而不是Selenium。你问为什么Selenium赢在“大家都会”传统的WebDriver协议也确实稳定但Playwright的自动等待机制、断言重试、trace回放、多浏览器支持都是原生内置的用起来省心太多。后面我在UI自动化部分会专门展开讲。2.2 一套可复用的分层工程结构框架选完下一步是工程结构。我见过太多测试脚本是一个py文件几百行里面元素定位、请求逻辑、断言写在一起改一个接口字段要全文搜索。这种脚本就是给自己埋雷。一个能长期维护的自动化工程应该把“怎么测”和“测什么”分开。autotest/ ├── config/ # 环境配置区分dev/staging/prod │ └── config.yaml ├── common/ # 通用封装请求客户端、断言工具、日志 │ ├── http_client.py │ └── assertion.py ├── data/ # 测试数据yaml/excel/json │ └── user_data.yaml ├── testcase/ # 测试用例按模块分目录 │ ├── test_api/ │ └── test_ui/ ├── page/ # UI对象库页面元素与操作封装 │ └── login_page.py ├── report/ # 测试报告、截图、trace文件 ├── pytest.ini └── conftest.py # 全局fixture与钩子每个目录的职责要清楚testcase里只写“步骤断言”page层负责“这个元素在哪、点了会怎样”config不随手改data里的数据尽量用唯一标识避免用例间互相影响。这套分层不是教条它解决的是三个实际问题元素变了只改page层、接口地址变了只改config、数据变了只改data文件。你要是从第一天就按这个结构组织后维护起来会舒服很多。2.3 pytest与conftest的核心配置pytest是当前Python生态做测试的事实标准它的conftest机制和fixture系统用好了自动化工程能省一半的心。先看一个最基础的pytest.ini[pytest] testpaths testcase addopts -v -s --strict-markers markers smoke: 冒烟用例 regression: 回归用例这里面的addopts我建议加上--strict-markers这样如果用例上标了未注册的markerpytest会直接报错而不是默默忽略能拦下一批低级错误。conftest.py则是放fixture的地方fixture是pytest最核心的概念之一它解决的是“测试前置条件和清理工作”的问题。# conftest.py import pytest from common.http_client import HttpClient pytest.fixture(scopesession) def base_url(): return https://api.example.com pytest.fixture def api_client(base_url): client HttpClient(base_url) return client注意fixture的scope参数function是每个用例都执行一次session是整个测试会话只执行一次。登录拿token这种操作建议用session级别再用yield把token传给用例如果每个用例都登录一遍接口自动化跑100条用例登录请求就发了100次纯粹浪费。很多新手在这里就踩坑了fixture函数不会用所有准备工作都写在测试函数里代码一大片重复。3. 接口自动化实战从用例设计到数据驱动3.1 接口用例怎么设计才不容易漏接口自动化的用例设计和手工接口测试思路一样只是要用代码固下来。我的经验是按照五个维度去铺用例正向流程、参数异常、边界值、权限校验、依赖关系。正向流程就是业务上的主链路比如下单、支付、查询订单参数异常包括必填字段缺失、字段类型错误、非法枚举值边界值不仅仅是数字的最大最小值还包括字符串长度、列表为空、时间字段的零点权限校验要覆盖未登录、已登录但无权限、越权访问他人数据依赖关系则是前一个接口的状态对后一个接口的影响比如订单必须先创建成功才能支付。很多初学自动化的人有一个误解觉得接口测试的断言就是判断HTTP状态码是不是200。实际上状态码只能说明“请求被处理了”不能说明“业务是对的”。你调用一个查询订单的接口状态码200但返回的业务码可能是10001意思是“订单不存在”。所以我建议断言策略分三层状态码保证协议层通业务码保证业务层符合预期关键字段再深入验证数据正确性。def test_get_order_detail(api_client, token): resp api_client.get(/api/order/detail, headers{ Authorization: fBearer {token} }, params{order_id: 2024001}) # 第一层状态码 assert resp.status_code 200 # 第二层业务码 body resp.json() assert body[code] 0 # 第三层关键字段 assert body[data][status] PAID assert body[data][amount] 0有时候接口返回的字段特别多没必要全量比较你要做的是聚焦“验证业务结果的关键字段”和“最可能出问题的字段”剩下的交给开发的自测。断言写得太多会让用例对数据的变化极其敏感稍微加个字段就红了维护成本直线上升。3.2 pytest requests 的实战骨架接口自动化我最常用的组合就是pytest requestsrequests提供了一个Session对象它比裸的requests功能更合适做接口自动化因为Session可以保持cookies、复用TCP连接、统一设置headers你不用在每一条用例里重复塞登录态。下面是一个典型的骨架# conftest.py import pytest import requests pytest.fixture(scopesession) def token(): resp requests.post( https://api.example.com/api/login, json{username: tester, password: 123456} ) assert resp.status_code 200 assert resp.json()[code] 0 return resp.json()[data][token] pytest.fixture def api_client(token): session requests.Session() session.headers.update({ Authorization: fBearer {token}, Content-Type: application/json }) session.base_url https://api.example.com return session然后用例里面可以通过pytest.mark.parametrize做数据驱动。接口自动化的数据驱动我强烈建议把数据放到外部文件里而不是直接写在装饰器里。原因很简单yaml或json文件里改数据不用动代码测试人员改数据即可跑而且减少了代码行数看着清爽。# data/user_data.yaml - case: 正常用户名密码 username: testerexample.com password: password123 expect_code: 0 - case: 密码错误 username: testerexample.com password: wrong expect_code: 10001import pytest import yaml with open(data/user_data.yaml, encodingutf-8) as f: LOGIN_CASES yaml.safe_load(f) pytest.mark.parametrize(case_data, LOGIN_CASES, idslambda d: d[case]) def test_login(api_client, case_data): resp api_client.post(/api/login, json{ username: case_data[username], password: case_data[password] }) assert resp.json()[code] case_data[expect_code]用ids给每条用例命个名跑起来报告里就能看到“正常用户名密码”“密码错误”这样的可读名称而不是test_login[0]、test_login[1]。这个小细节能让报告的可读性提升一个档次。3.3 环境切换、造数与幂等性处理接口自动化里另一个容易翻车的是环境问题。开发环境、测试环境、预生产环境的地址、账号、数据都不一样。我的做法是写一个config.yaml用环境变量控制切换# config/config.yaml dev: base_url: https://dev.example.com username: dev_tester staging: base_url: https://staging.example.com username: stage_tester然后在conftest.py里读取环境变量比如在命令行执行ENVstaging pytest -m smoke这样切换环境只需要改环境变量名不用改代码。造数也有讲究接口测试的数据尽量通过调用业务接口去准备而不是直接改数据库。为什么因为通过接口造的数据更贴近真实用户场景而且能自动覆盖前置依赖。创建类用例要保证幂等性也就是用例重复跑结果一致。最常见的做法是给数据加唯一标识比如测试用例名时间戳先查数据是否存在存在就删掉重建不存在就创建。不然同一份数据每次跑都新建越积越多最后环境一塌糊涂。4. UI自动化实战从元素定位到稳定运行4.1 元素定位策略与等待机制UI自动化是面试和实战里的重头戏也是最容易让人劝退的部分。先说定位我见过太多人写XPath全是从浏览器里右键复制出来的一大串/*[idfoo]/div[2]/div[3]/span这种定位符页面布局稍微调整一下就全灭。我更推荐按优先级选择定位方式优先用可见文本和角色定位其次是placeholder、label然后才是data-testid最后兜底才用简洁的XPath。以Playwright为例它的定位API做得非常友好page.get_by_text(登录)、page.get_by_role(button, name提交)、page.get_by_label(用户名)这些定位方式贴近用户实际感知即使页面结构变了也不容易碎。如果你发现某个元素实在没有语义化的定位方式那就推动前端在页面里加上data-testid属性这是成本最低、收益最高的做法。等待机制同样关键。新手最爱用time.sleep(3)觉得等3秒总够了吧。结果在本地跑得好好的到CI上就挂为什么因为sleep是固定的环境慢的时候3秒不够环境快的时候纯浪费时间。正确的姿势是优先依赖框架的自动等待Playwright内置了对元素的可见、可编辑、稳定状态的自动轮询如果用Selenium就要写显式等待WebDriverWait expected_conditions。记住一句话元素存在不等于可见可见不等于可交互你等到的可能只是一个还挂在DOM里但尚未渲染完成的节点这时候点击必然出问题。4.2 Playwright 实战示例为什么我建议新项目用Playwright因为它把几个最让人头疼的问题原生解决了自动等待、多浏览器支持、Trace回放、网络拦截。举一个实际登录用例的例子# testcase/test_ui/test_login.py from playwright.sync_api import Page, expect def test_user_login(page: Page): page.goto(https://example.com/login) page.get_by_label(用户名).fill(tester) page.get_by_label(密码).fill(password123) page.get_by_role(button, name登 录).click() # 断言等待跳转后页面出现用户名 expect(page.locator(.nav-user)).to_contain_text(tester) def test_login_failure(page: Page): page.goto(https://example.com/login) page.get_by_label(用户名).fill(tester) page.get_by_label(密码).fill(wrong) page.get_by_role(button, name登 录).click() expect(page.locator(.error-tip)).to_be_visible()注意Playwright的expect断言自带重试机制它会等元素状态满足预期这是它和普通assert最本质的区别。普通断言网页还没渲染完就开始执行直接就红了。另外调试UI用例时我强烈建议用有头模式或者在代码里临时加一句page.pause()这样点击之后能实时看到页面状态。很多人一上来就headlessTrue跑挂了完全不知道发生了什么调试效率极低。还有一个实用小技巧Playwright的trace功能。在conftest.py里打开失败时保留trace.zip然后用playwright show-trace trace.zip打开你能完整看到页面每一步做了什么、网络请求是什么、元素定位到了哪里。这个能力简直是UI自动化排查问题的救星比看截图日志强十倍。4.3 稳定性治理三板斧UI自动化最大的敌人不是功能bug而是用例自身不稳定。我自己维护过的几套UI自动化从“三天一个小红”到“每周只偶发一次”总结下来就三板斧。第一板斧是重试机制。UI自动化允许明显少于接口自动化的重试因为UI定位本身就有偶发性。pytest-rerunfailures这个插件可以给用例加重试我一般设置reruns2、reruns_delay3超过两次还失败就不应该再试了真失败还是伪失败得靠证据判断。第二板斧是用例隔离。每一条UI用例都应该有自己独立的登录态和数据不要用一条用例登录另一条用例默认“反正前面已经登录过了”这是最典型的用例互相依赖。我把登录写成一个fixture每条用例自动登录或者通过前端预置会话保证任意一条用例都能单独执行。第三板斧是失败证据完整。我的conftest里固定配置了失败时自动截图并保存DOM快照配合trace文件一起存到report目录。没有证据的重试就是在赌运气有了证据才能判断到底是页面改版、数据异常、网络超时还是用例本身写错了。这一套下来自动化才真正是“可持续维护”的而不是每次红了就找人去看。# conftest.py 失败自动截图 import os import pytest from playwright.sync_api import sync_playwright pytest.hookimpl(tryfirstTrue, hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.failed and hasattr(item, funcargs): page item.funcargs.get(page) if page: os.makedirs(report, exist_okTrue) page.screenshot(pathfreport/{item.name}.png) page.locator(body).inner_html()5. App自动化与嵌入式物联网测试的特别之处5.1 Appium环境搭建与真机无线连接App自动化这些年热度一直有但真正跑得好的团队不多问题一般出在环境搭建和真机适配。先说Appium的架构它不是一个框定你写脚本的库而是Appium Server 平台驱动 脚本客户端的三层结构。Android端驱动一般是UiAutomator2iOS端是XCUITest你用Python脚本发请求给Appium ServerServer再通过驱动操作手机上的App。环境搭建的步骤网上很多我只提醒三个坑。第一个Appium版本和驱动版本必须对齐直接执行appium-doctor检查环境依赖别等启动报错才排查。第二个Android真机从USB切换到无线模式用adb connect这是局域网调试不是外部网络的事别混淆了adb devices adb tcpip 5555 adb connect 192.168.1.100:5555 # 然后就可以拔掉USB用无线继续调试 appium --address 0.0.0.0 --port 4723第三个运行用例之前先进入App首页很多脚本直接在启动App瞬间就去点按钮结果被系统弹窗、权限请求、版本更新弹窗打断。我一般会在第一句加一个循环处理弹窗的逻辑把“允许”“以后再说”这类按钮统一处理掉不然用例跑几天就红几天。App的元素定位和Web区别非常大Web上可以用文本、CSS、XPathApp里的控件属性少很多常用的就是resource-id对应Web的id、content-desc无障碍描述、class名、XPath而且原生页面层级深XPath又长又脆弱。我建议用Appium Inspector这类工具先看页面层级树能选resource-id或content-desc就不要选XPath。如果真到了必须用XPath的地步尽量用相对路径加稳定属性不要整段复制。5.2 嵌入式与物联网设备测试的抓手“嵌入式软件测试怎么测”“物联网设备的软件测试怎么测”是最近搜出来的高频问题我在这里一并说透。嵌入式与物联网的自动化和Web/App/接口自动化最大的不同是你没有一个现成的浏览器或手机屏幕去操作设备上的资源非常有限你没法在设备上装一个庞大的测试框架。但这不代表不能自动化反而是自动化的价值更大因为手工去重复验证几万条协议报文是不现实的。物联网设备测试可以拆成四层看设备端固件、通信协议、移动/Web端、云端服务。设备端固件的测试重点是通过交叉编译环境把单元测试跑在主机上代码逻辑正确性在PC上就能验证不需要每改一行代码都烧录一遍真机。通信协议层是最适合自动化的地方用MQTT/CoAP/HTTP的模拟器或测试桩模拟云端和设备之间的双向报文然后对比报文内容是否符合协议规范这类自动化甚至可以用来做长时间稳定性测试。云端服务和移动端就可以回到你熟悉的接口自动化和App自动化框架里去覆盖。我在真实项目中做过一个最简单的实践写一个脚本通过串口或者网络调试接口定时读取设备日志然后根据关键字异常警告、崩溃堆栈、状态跳转做断言。设备一旦出现非预期的日志自动截图或者保存上下文。这种方式的投入很小但对嵌入式黑盒测试的提升很明显你不再需要一直盯着串口工具看几个小时的滚动日志了。自动化在这里的本质是“扩大人的监控范围”而不是“完全替代人的判断”。6. AI自动化测试从Prompt到Agent的探索6.1 一条值得复现的Agent实现思路最近“基于langchain开发一个能读取测试用例自动生成UI自动化脚本的Agent”这类话题在软件测试圈热度非常高。我试过类似方向先说结论这条路可行但没有那么神它最适合的场景是把已有的自然语言测试用例转化成自动化脚本初稿。我的实现思路分成四步。第一步解析测试用例文档不一定用多复杂的技术先写脚本把Excel或Markdown里的用例行抽出来得到“前置条件、操作步骤、期望结果”这样的结构化文本。第二步用大模型抽取关键动作比如“输入用户名”“点击登录”“断言页面显示用户名”这些动作这里Prompt设计要非常具体要求模型输出一个JSON结构而不是自由文本这样后面才好处理。# 思路示例伪代码级别的原型 case_text 用例正确登录。打开登录页输入用户名tester密码123456点击登录断言页面右上角显示tester。 prompt f请把下面的测试用例转换成动作序列只输出JSON数组。 每个动作包含字段action_type(open/input/click/assert)、target_selector、value。 用例{case_text} # LLM返回一个JSON数组然后由脚本体映射到Playwright API第三步把动作序列映射到具体的UI框架API这里要注意LLM生成的target_selector往往是“用户名输入框”这样的自然语言描述你需要结合你自己项目里的page object对象库把它翻译成page.get_by_label(用户名)这类真正的定位器。这个映射层是Agent能不能落地的关键我建议把它做成一个静态配置表不要让模型去猜选择器。第四步生成完整脚本文件写入testcase目录交给人工Review后执行。6.2 实测边界与落地建议我实测下来大模型最擅长的是“从自然语言到代码模板”的转换比如“点击登录”这种动作生成的质量已经很高了。最容易翻车的是三块复杂的业务断言比如“支付成功后的订单金额应等于商品总价减优惠”、动态元素定位列表项、弹窗内容会变化、多层页面跳转的时序问题。所以我的落地建议是让Agent做初稿生成人工只改10%的定位符和断言而不是期待它一次生成可运行且永远稳定。在实际项目里可以把Agent做成一个内部小工具输入是测试用例文档输出是一个包含脚本文件、代码说明、需要人工确认的清单。然后用“AI生成 - 人工审核 - 纳入执行”的流程去跑。这个工具用langchain主要是方便做Prompt模板管理、上下文传递和结构化输出解析但其实你用原生大模型API加json解析也能实现别迷信框架关键是Prompt设计和映射层实现。有一条经验值得记下来如果Agent生成的脚本一直不稳定大概率不是模型能力问题而是你的测试目标描述不够清晰。“点击登录按钮”谁都会生成难的是“当用户名为空时点击登录按钮页面下方应该出现红色提示文案”这种既包含前置条件又包含异常断言的场景你必须把这类规则沉淀到Prompt的例子里让模型学会你的项目风格。7. 面试高频考点速览与经验沉淀7.1 七个最容易被问到的自动化考点把AI工具聊清楚之后再看面试。下面这些题是我在软件测试面试复盘里见得最多的自动化方向考点我按“典型问法”和“回答要点”列出来建议你对照自己项目想想会怎么回答。考点典型问法回答要点自动化价值自动化测试能完全替代手工测试吗不能自动化擅长回归、重复、数据准备探索性测试和用户体验判断还得靠人pytest机制fixture scope有哪些conftest作用session/module/class/functionconftest按目录层级生效放公共fixture和钩子框架对比Selenium和Playwright有什么区别Playwright原生自动等待、trace、多浏览器、可拦截网络Selenium生态更成熟元素定位元素定位不到怎么处理检查是否在iframe、是否在shadow DOM、是否页面未加载完、优先用稳定属性稳定性自动化用例不稳定你怎么办先收集失败证据然后区分定位问题/数据问题/环境问题再做用例隔离和重试接口断言接口测试断言什么状态码是底线业务码、关键字段、落库数据、时序流转都要覆盖AI自动化你有没有用过AI做测试脚本说清LLM生成脚本的思路、映射层设计、以及人工兜底的必要性7.2 用项目案例代替八股背诵最后一点建议面试官真正想听的不是你把上面的表格背一遍而是你能不能讲出一个真实的项目案例。回答问题的时候尽量按照“项目背景 - 选型理由 - 我的具体工作 - 遇到的坑 - 数据成果”这个结构来。比如被问到“你做过最复杂的自动化项目是什么”你可以这样说上个项目是电商后台Web端下单流程频繁迭代手工回归一次要40分钟。我用Playwright搭了一套UI自动化把下单、支付、退款三条核心路径覆盖了用page object管理元素在CI上每天晚上跑一遍。最开始的通过率只有70%主要原因是弹窗和网络延迟后来加了显式等待、弹窗统一处理和失败自动截trace通过率稳定在95%以上每次发版前的人力回归时间从40分钟压缩到10分钟剩下时间只需要检查失败用例的证据。这个讲法不华丽但每一句话都经得起追问。面试官一旦追问“你那个等待是怎么处理的”“trace是什么”你能接得上来分数自然就上去了。我个人在实际操作中的体会是自动化测试这个方向做的过程比学的阶段更重要。你不需要一开始就掌握所有框架只需要挑一条最核心的链路从接口自动化开始然后UI自动化再到App、物联网这种特殊场景一步步把脚本跑稳。等你亲手把一个从天天跑挂的用例集调到每晚上路、稳定报警、能帮团队省出半天时间的时候你对自动化测试的理解才算真正入门了。
阅读完成 · 觉得有帮助？
