1. 动手之前先想清楚框架要解决什么问题才不至于做出来没人用我在不少团队看到过这样的场景A同学花了两周搭了一套自动化测试框架结构精巧、分层清晰、代码优雅用的是时下流行的技术栈结果上线之后用的人寥寥无几。不是框架质量差而是它解决的根本不是团队真正痛的那个问题。自动化测试框架这东西拆开来看就两句话第一把手工回归中重复、可机器化的验证动作交给程序去执行第二把怎么测的复杂度收敛到框架内部让写用例的人只关心业务逻辑。但每家团队的业务形态、技术栈、人员水平差异极大不存在一个通用的最佳实践只有最贴合当前团队的取舍。在设计阶段我建议先回答三个问题被测对象是什么形态Web端、移动端、API接口还是小程序/桌面端这三类的自动化策略差异很大。Web端依赖浏览器驱动和页面元素定位移动端还要考虑设备管理和系统兼容API测试则几乎不涉及UI层面的等待和定位问题。如果你同时要覆盖好几类就得考虑框架是否要统一入口还是分开维护。团队的用例编写能力在什么水平如果团队成员大多是手工测试出身写代码经验不足那框架的封装就要更厚一些把大部分技术细节隐藏起来最好能做到理解业务的人填几个参数就能写用例。如果团队本身有不错的开发能力那框架可以做得更薄给足够的灵活性避免过度封装反而限制发挥。自动化到底要跑多频繁是每天定时跑一遍回归还是每个提交都触发全量执行不同频率决定了框架在稳定性、执行速度、资源消耗上要有不同的侧重。每天都跑那用例稳定性就是命根子不能三天两头因为环境问题报红每次提交都跑那就必须做用例分级不能把所有用例都塞进快速验证的流程里。这三个问题没想清楚之前选型、写代码都是瞎忙。我见过太多团队框架选型完全跟风看别人用什么就抄什么结果用了一个月后才发现跟自己的技术栈根本不匹配又从头再来一遍。技术栈选型方面我个人的倾向是不要在一个框架里堆太多东西能用成熟方案解决的就不要自己造轮子。基于Python的pytest配合Selenium/Appium或者基于Java的TestNG配合WebDriver这两条路线最稳。UI自动化用Selenium系接口自动化用Requests配合pytest或像RestAssured这样的库测试报告用Allure或者自研轻量级汇总CI用现成的流水线平台集成。这套组合的好处是社区成熟、坑都有文档可查、招人也好招。那些听起来很炫的组合比如用某个小众的录制回放工具或者把测试脚本写进业务代码仓库的方案除非有极强的定制需求否则不建议作为主框架。提示框架设计的第一原则不是功能全面而是降低后续所有人的使用成本。你写的每一行框架代码都是在给未来几个月甚至几年的团队使用体验做投资。2. 框架的骨架分层设计、目录规划和基类封装2.1 一套能支撑长期演进的目录结构选型定了之后最基础也是影响最深的工作就是目录结构设计。这个看似简单的事情直接决定了框架后续能不能长大而不变形。一个合理的目录结构应该达到这样的效果新成员加入团队后不用看文档也能大致猜到什么东西该放哪个目录。以UI自动化为例我维护过的一个Web测试框架是这么划分的你可以参考auto_test/ ├── config/ # 配置文件环境和业务参数分离 │ ├── env.ini │ └── settings.yaml ├── data/ # 测试数据和文件存放 │ ├── test_data.xlsx │ └── downloads/ ├── drivers/ # 浏览器驱动、移动端驱动 ├── framework/ # 框架底层封装 │ ├── base_page.py # 页面对象基类 │ ├── browser_engine.py # 浏览器启动和复用逻辑 │ ├── logger.py # 日志封装 │ ├── assertion.py # 断言扩展 │ └── retry.py # 失败重试机制 ├── pages/ # 页面对象层Page Object Model │ ├── login_page.py │ └── home_page.py ├── testcases/ # 用例层按模块组织 │ ├── test_login.py │ ├── test_home.py │ └── conftest.py ├── report/ # 测试报告输出 ├── utils/ # 通用工具函数 └── run.py # 执行入口这个结构的核心思想是分层业务逻辑、页面对象、用例脚本、框架基础组件各管各的层与层之间通过明确的接口协作。页面对象层把元素定位和页面操作封装起来用例层只表达测试意图。这样当界面改版时需要动的只有pages/下的文件当新增测试需求时主要是在testcases/下加脚本底层框架的改动理论上不涉及业务代码。这里要特别强调一下conftest.py的用法。pytest的conftest机制非常灵活你可以在根目录、模块目录、子目录各放一个conftest.py实现不同范围的fixture定义和钩子函数。我建议把全局的fixture比如浏览器实例、日志初始化、测试环境切换放在根目录或框架层把模块内部特有的fixture比如某模块的初始化数据准备放在该模块目录下。这样既方便又不会出现fixture互相污染的情况。2.2 基类封装把重复的事情收敛到一个地方框架设计里最见功夫的就是基类封装。封装得好用例代码能缩短一半以上封装得过头就变成了一个万能类谁也不知道这个方法该不该放进来最后连写的人自己都很难维护。我见过两种极端一种是什么都裸写每个用例里都重复造driver初始化、日志记录、截图留存另一种是把所有能想到的操作全部塞进基类一个页面基类里有上百个方法光查找方法就要翻半天。这两种都不可取。合理的基类设计应该遵循封装共性暴露差异的原则。所谓共性是指所有页面对象都需要的那些操作元素查找与等待、点击、输入、获取文本、截图、日志记录、页面滑动移动端。这些操作和具体业务没有关系放进基类是完全合理的。以Web自动化为例一个页面基类大致是这么个样子class BasePage: def __init__(self, driver, timeout10): self.driver driver self.timeout timeout self.logger LoggerManager.get_logger(self.__class__.__name__) def find_element(self, locator, waitTrue): 统一的元素查找入口支持显式等待 if wait: element WebDriverWait(self.driver, self.timeout).until( expected_conditions.presence_of_element_located(locator) ) else: element self.driver.find_element(*locator) return element def click(self, locator, waitTrue): element self.find_element(locator, wait) try: element.click() self.logger.info(f点击元素成功: {locator}) except Exception as e: self.save_screenshot(click_failed) raise e def input_text(self, locator, text, waitTrue): element self.find_element(locator, wait) element.clear() element.send_keys(text) self.logger.info(f输入文本: {locator} - {text}) def save_screenshot(self, name): 失败时自动截图的统一入口 screenshot_dir os.path.join(Config.REPORT_DIR, screenshots) timestamp time.strftime(%Y%m%d_%H%M%S) path f{screenshot_dir}/{name}_{timestamp}.png self.driver.save_screenshot(path) self.logger.error(f截图已保存: {path})当然还有更简练的写法但核心逻辑是所有方法内部天然包含日志记录和失败处理。这样用例脚本里就不需要到处写try-except和logger只关心业务动作本身。至于元素定位我强烈推荐用显式等待而不是time.sleep()。sleep是UI自动化里最常见也最坏的习惯——等待时间设短了不稳定设长了拖慢执行速度而且无法应对元素突然出现但尚未可点击的情况。显式等待会在指定时间内轮询检查元素状态元素一满足条件立刻继续执行既不浪费时间也足够稳健。封装到基类后用例层写起来会非常干净。2.3 配置管理环境切换不能靠改代码框架能不能真正落地配置管理是很关键的一环。很多框架用不起来不是功能不行而是切换测试环境太麻烦——每次都得改代码里的URL、账号、开关一不小心改错就提交上去把环境搞得一团糟。配置管理要解决的核心问题是一套代码多套环境不用改代码。推荐的做法是把配置拆成两个层次第一层是框架配置放在config目录下用YAML或INI格式维护。包括测试地址、超时时间、浏览器类型、是否开启无头模式、失败重试次数、报告输出路径等。这一层跟具体环境和业务无关是框架运行的基本参数。第二层是环境配置按环境划分维护多套参数。比如这样组织config/ ├── settings.yaml # 框架基础配置 ├── environments/ │ ├── dev.yaml # 开发环境 │ ├── test.yaml # 测试环境 │ └── staging.yaml # 预发布环境 └── env.ini # 指向当前激活的环境env.ini里面只放一行指明当前使用哪个环境运行时通过命令行参数或者环境变量覆盖它。CI流水线里因为有独立的配置管理机制也可以直接用环境变量注入。这样团队里任何一个人拿到代码后不用问别人就能知道怎么跑起来、连哪个环境。有个细节容易被忽略测试账号和对接人的联系方式不要写在配置里。这里的配置指业务系统里的真实账号应放在单独的密钥管理服务或CI的变量区避免敏感信息直接平铺在仓库里。特别是涉及到权限类、支付类的测试账号一旦泄露后果不可控。3. 关键机制断言怎么设计、数据怎么管理、报告怎么做3.1 断言的层次不是只有一个assert断言是自动化测试的灵魂。用例写得再漂亮断言设计不合理结果就是两种典型问题要么断言太弱用例永远绿实际上功能已经坏了都没发现要么断言太强UI上无关紧要的文字变化都能导致用例失败维护成本爆炸。我理解的断言设计至少分三个层次第一层是基础断言验证某个元素存在、文本等于/包含期望值、接口返回的code字段是否为0。这是最常用的也是绝大多数用例的主体。第二层是业务断言验证的不仅仅是文案显示出来了而是业务状态真的对了。比如下单成功不仅仅是页面上出现下单成功几个字更关键的是订单列表里出现了这笔订单、订单金额正确、订单状态是待支付。这个层次需要查询数据库或者调用后端接口来验证虽然多写几行代码但测试的价值完全不同。第三层是数据一致性断言一个操作做完后不同位置的数据是否一致。比如提交退款申请后前端显示的退款金额、后台DB里的退款记录、给用户发的通知短信中的金额三者是否一致。这里往往需要跨系统验证是整个体系中含金量最高的断言类型。我建议框架里预先封装一些常用断言工具避免每个用例重复写。比如def assert_text_contains(actual, expected, msg): 断言文本包含失败时打印明确的上下文信息 if expected not in actual: raise AssertionError( f{msg} | 期望包含: {expected} | 实际文本: {actual} )这类断言失败时输出的信息要足够详细。很多团队跑自动化用例红了之后还要花几分钟去翻日志找哪个环节失败。如果断言本身能明确告诉你期望是什么、实际是什么、差异在哪里排障效率会大幅提升。3.2 测试数据管理把数据分成三类别混在一起测试数据管理是自动化测试里最容易被低估的领域。很多框架初期跑得很顺用着用着就开始大量失败一查原因——数据环境被污染了或者一条用例依赖了另一条用例的数据。这类问题几乎都可以通过数据分类治理来规避。我把测试数据分成三类静态数据登录账号、基础配置、公共数据。这类数据基本不变写在配置文件里就好。要注意的是公共数据如果被并发用例同时使用会产生数据竞争。比如多个用例同时用同一个账号登录很容易互踢或者触发风控。解决思路是给静态数据加上按用例隔离的机制每个用例用独立账号或者临时创建的数据。动态数据运行时生成的数据时间戳、随机字符串、交易流水号等。这类数据看起来简单但有个坑断言时往往需要把运行时生成的数据记录下来才能在后置步骤里使用。框架里可以用一个简单的上下文对象来传递动态数据class TestContext: 用例级上下文用于在用例步骤之间传递动态数据 def __init__(self): self._data {} def set(self, key, value): self._data[key] value def get(self, key, defaultNone): return self._data.get(key, default)环境数据测试环境本身的存量数据比如某个环境的商品列表、用户信息。这类数据最大的问题是不同环境之间不一致导致同一个用例在开发环境跑得通、在测试环境却失败。处理方法是把准备数据的动作也写进用例的前置步骤里——要么通过接口创建数据要么从环境配置里读取该环境特有的数据彻底避免因为环境不同所以用例失败这种情况。有个团队分享过他们的做法我非常认同每条用例必须自带数据准备和数据清理逻辑。用例跑完不管成功失败都要把数据清理掉不能给环境留下垃圾。这样做的好处是环境永远处于可重跑状态自动化才能真正做到每天稳定执行。3.3 并发执行与报告可视化提速之外更要稳定自动化执行速度也是个体验问题。单线程跑100条用例可能要40分钟开发等不起反馈循环太长。合理的并发执行可以把时间压缩到10分钟以内但并发引入的另一类问题——用例之间的数据隔离和资源竞争——需要提前处理。pytest的-n参数配合插件就可以实现用例级并行。但要注意并行不是简单地把-n auto写上去就完事。需要做三件事用例之间无数据依赖。一条用例用到另一条用例产生的数据是并行的大忌。前期要通过用例评审把这种隐性依赖找出来改成自给自足。各用例使用的测试数据要隔离。如果两条用例同时操作同一个订单号必然打架。解决方案是每条用例动态创建自己的数据用完再清理。并发数要结合执行环境的硬件资源。不是越大越好8核机器跑10个并发和跑30个并发整体耗时可能差不多因为CPU密集型的操作都被占满了。报告方面Allure是我用到现在觉得最省心的方案。失败截图自动嵌入、用例步骤层级展示、历史趋势统计基本覆盖了日常分析需求。还有一个容易被忽略的能力是报告里的日志关联。用例失败时能把对应的框架日志、请求日志、响应日志都关联到报告的附件里排障会快很多。这个可以通过自定义Allure的插件或者简单地在失败时写一个汇总日志文件来实现。注意报告的作用不是看起来漂亮而是快速定位问题。所以报告的核心指标应该是失败用例的失败环节一目了然、三条以内点击就能看到关键日志和截图。如果做不到这两点报告工具换得再花哨也没用。4. 实施阶段最容易崩的三个环节4.1 从0到1先跑通最小闭环再谈完整覆盖框架设计的最大敌人是完美主义——想把所有功能都设计好了再动手写用例。我的建议完全相反第一天就用框架跑通一条真正的业务用例。为什么这么强调最小闭环因为框架设计中的很多问题只有在真实用例运行中才会暴露。你设计的基类方法是否真的好用、配置管理是否足够灵活、并发执行是否稳定、报告是否对排查有帮助——这些问题在一两条用例跑通后就会有直观感受。等整套框架都开发完才发现某个核心设计不合理改起来代价就大了。最小闭环的路径大概是这样的选定一条覆盖核心业务的用例建议是登录后走一个完整流程这样能验证框架的多数基础能力。用手工方式完整走一遍记录每一步涉及的元素定位、数据、断言点。手写这条用例的场景脚本先跑通它。然后再逐步抽象——把重复的步骤提炼到页面对象层把通用逻辑收进基类。跑通两三条同类流程后框架的核心机制就基本定型了剩下的就是机械式地扩展用例。这个阶段有个技巧先不要急着处理各种异常场景把正常流程的稳定性做到极好再去扩充边界场景。异常场景的用例要等框架核心逻辑稳定后再加否则排查失败时很难分清是脚本问题还是业务问题。4.2 与CI集成自动化测试真正发挥价值的临门一脚自动化测试如果没有跟CI/CD流水线打通价值就要打一半折扣。因为它的核心价值恰恰在于每次变更后自动验证——代码提交、构建完成后测试自动跑起来结果自动反馈到提交记录或群通知里开发者不需要去记住哦我还要手动跑一下测试。流水线集成的关键动作有这几步拉取代码后先安装依赖。这一步很容易因为环境差异失败。建议把依赖安装写成一个独立的脚本在本地和CI环境都能跑避免本地好好的、CI上爆炸这种经典问题。指定测试执行的入口。不能是所有用例全跑而是按测试集分组冒烟集提交后必跑、核心回归集每天定时跑、完整回归集发版前跑。分组可以通过pytest的mark机制实现。报告与构建结果关联。测试失败时构建状态置为失败并把报告链接和失败摘要推送到协作群里。这一步能显著缩短问题被发现的响应时间。失败重跑策略。CI上因为网络抖动、环境未就绪导致的偶发失败很常见不加处理会让团队对自动化测试失去信心。建议对每条用例提供重试机制比如失败后重试1次但重试要通过标记而不是全局开启且要记录重试原因供后续分析。还有一个小细节CI执行环境的浏览器版本和本地要保持兼容。Selenium版本和浏览器驱动版本不匹配是CI上最常见的环境失败原因。建议在依赖文件里锁定浏览器和驱动版本或者干脆用容器化方案固定镜像版本。我之前在一个项目里测试环境部署有固定的容器镜像测试直接跑在一致的容器中彻底杜绝了环境差异问题。代价是镜像维护要多花一些精力但跟每次版本升级都带来一批莫名失败的维护成本相比完全值得。4.3 Flaky用例治理稳定性比覆盖率更需要关注只要是UI自动化跑得够久就必然会遇到顽固不稳定用例——就是那种这次跑绿、下次跑红、十次里有两三次失败、重跑又过了的用例。这类用例的破坏性不在于失败本身而在于消耗团队信任。当自动化测试红了没人看成为常态后这套体系基本就废了。处理flaky用例的正确方式不是一次次盲目重试而是先识别、再归类、后治理。识别方式很简单统计每一条用例在近20次执行里的失败率。失败率超过10%且失败原因不是产品缺陷就应该给它打上不稳定的标记。然后分类治理常见的flaky来源我列个表失败类型典型特征治理思路元素时序问题元素有时找不到、有时找得到检查等待策略优先使用显式等待而不是sleep数据竞争问题并发执行时偶发失败做数据隔离避免用例之间共享可变数据环境不稳定接口超时、网络抖动加入超时退避重试检查CI环境资源断言依赖UI细节文案变化导致失败弱化对纯展示文案的断言改为核心业务状态历史状态遗留前置页面残留了上个用例的弹窗增加用例前置清理和后置恢复机制治理flaky用例有个纪律不要为了让用例变绿而削弱断言的严谨性。比如把断言删掉、把断言等于改成断言包含但不校验具体内容、把边界条件放宽——这些都是自欺欺人。宁可让用例保持失败状态由专人去定位根因也不要做掩盖问题式修复。有一些通用icon想法是写一个统一的重试装饰器失败时自动重跑重跑前清理页面状态。这类机制可以提高整体稳定率但要配合上面表格里的根因治理一起用。只重试不治理就像房间里漏水了你不去修水管而是一直拖地治标不治本。还有个实用经验每次CI跑完把失败用例的产品缺陷数量 vs 不稳定用例数量分开统计。如果不稳定用例清零了就说明框架健康度不错。这个数字应当作为团队质量指标之一定期回顾。5. 框架建成之后维护机制和持续演进框架不是写完了就能一直用的。运营得好的自动化测试框架其实是一个活的系统需要持续投入维护。总结下来有几件事要坚持做日常维护机制。每天定时跑完核心回归后第一件事不是看总数而是看失败用例的分布。如果失败集中在某几个模块很可能就是业务改动引起的需要及时更新页面对象或用例。维护工作应该作为固定任务安排到测试团队的工作项里而不是有空再改。框架自身的演进路径。自动化测试的投入是有回报曲线的初期投入大、回报低中期用例量上来了回报快速增长后期如果框架维护没跟上会进入维护成本大于收益的衰退期。为了不让框架过早进入衰退期要定期审视框架设计是否还支撑得住业务变化——比如页面对象层是不是越来越臃肿、公共函数的参数是不是越来越多、用例之间有没有出现新的隐式依赖。团队协作规范。多人写用例时风格不统一会成为后续维护的定时炸弹。建议制定一份简洁的《用例编写规范》约定命名规则、断言风格、数据准备方式、注释规范。同时用例代码也要评审——不是走形式的过场而是评审者真的去看这条用例是不是有稳定性的隐患、数据管理是否合理、有没有不必要的外部依赖。好的用例评审能在问题发生前就拦住。定期复盘。每个月花半天时间复盘自动化测试的整体运行情况跑了多少用例、失败了多少、失败类型分布、团队有没有因为自动化发现过真正有价值的问题。通过复盘你会逐渐摸索出适合自己团队的黄金比例——哪类用例适合自动化、哪类用例用自动化纯粹是浪费维护时间、怎样安排更高效。另外想补充一点现在生成式AI的能力越来越强确实可以用来辅助写一些模板化的测试脚本。我测试过让AI根据页面元素生成xpath的初稿省了不少时间。但要注意AI生成的定位器和断言逻辑一定要人工审查一遍不能直接信任。尤其是一些看起来很有道理但实际无效的定位方式可能会让用例在错误的方向上跑很久。把AI当加速器可以但当方向盘不行。最后分享一点个人体会做了几年自动化测试框架踩过不少坑最重要的一条体会是自动化测试的价值不在于有多少条用例在跑而在于每次业务变更后它是否真的帮你拦截了问题、节约了时间。如果团队跑完几百条用例全是绿的但发布时还是出事故说明用例覆盖的点根本没切中要害如果每天确确实实靠自动化发现3-5个问题哪怕也是同样的几百条用例这才是真正有价值的自动化体系。所以别急着追求用例数量先把用例质量、执行稳定性、数据管理、CI集成这几件事做扎实。框架从设计到实施这条路最大的坑从来不是技术选型或者代码实现而是做着做着就忘了当初为什么要做它。每一条用例都应该回答一个问题如果它跑红了说明产品哪里可能出了问题如果它跑绿了这个业务场景的哪些风险可以被我们放心地忽略想清楚这一点框架设计的方向基本就不会跑偏。