简介这是一份面向Web自动化测试入门者与Python测试开发人员的实战型PDF资料围绕PythonSeleniumChrome工具链完整演示TPshop商城从注册到登录的自动化测试流程。资料逐段拆解了元素定位、隐式/显式等待、ActionChains操作、JavaScript滚动、输入校验与错误信息捕获等核心知识点并给出了可直接运行的示例代码。包体为单个PDF文档大小仅97KB内容紧凑适合系统学习后随时查阅。目前已有2431人学习下载获得较多学习者关注。通过这套实战练习读者可快速理解Selenium自动化的标准操作步骤掌握编写、调试和验证测试脚本的常见思路为商城项目后续实战打下扎实基础。1. 从零跑通Selenium注册登录脚本先别急着写代码接触过Web自动化测试的同学对Python加Selenium加Chrome这套组合应该都不陌生。但说实话很多刚入门的朋友拿着教程里的一段脚本看完了觉得懂了一放到自己电脑上跑各种报错直接把人劝退。我在学习TPshop商城项目自动化测试时也经历了这么一段从一脸懵到逐渐理顺的过程。这里说的TPshop是一个开源的单商户B2C商城系统前后台功能完整非常适合拿来做自动化测试练手。为什么选它而不选那些更复杂的电商系统因为测试入门阶段最忌讳的就是把精力花在环境的坑和业务理解的复杂上。TPshop的注册和登录逻辑足够典型又不会太绕用来练习定位、等待、断言这些基本功恰恰是性价比最高的选择。这篇博文我打算讲清楚一件事如何用Python加Selenium驱动Chrome把TPshop商城的注册和登录功能做成一套可反复执行的自动化脚本。我不会只丢一段代码让你自己研究而是会把每一步设计背后的原因、容易踩的坑、以及排查思路都摊开来聊。无论你是刚学会Python基础语法还是已经写过一点Selenium但总感觉不够系统这篇内容都能给你一个可复现的完整参考。2. 环境准备中最容易被忽略的版本匹配问题2.1 Python、Selenium、Chrome三者之间的关系先把这套工具链的分工理顺。Python负责写测试逻辑Selenium相当于一个翻译官把Python指令翻译成浏览器能听懂的操作而Chrome是最终执行操作的那个“人”。所以整个链路里任意一层出了问题脚本都没法正常工作。在实际配置环境时最常见的坑恰恰出现在这里。很多初学者会把Selenium库安装好然后直接写脚本结果运行时报错找不到ChromeDriver或者报SessionNotCreatedException一看错误信息是Chrome版本和驱动版本不匹配。这时候有人会去下载最新的驱动但仍然不行因为Chrome浏览器本身是自动更新的驱动版本必须和浏览器版本严格对齐。以我当时的环境为例Chrome版本是116对应的ChromeDriver也必须是116系列的版本。Selenium有个很实用的设定它支持的driver版本号和Chrome主版本号前几位保持一致就没问题不需要精确到小版本一模一样。但如果你用的Chrome是115而驱动下载的是116大概率会报错而且错误信息往往不够友好容易让人误以为是代码写错了。2.2 安装步骤与验证方法第一步安装Python。这个没什么好说的官网下载安装包安装时记得勾选Add Python to PATH。这个勾选框我每次都要提醒一次因为漏了它后面在命令行里输入python会提示找不到命令很多新人卡在这一步卡了半天。第二步安装Selenium库。在命令行执行pip install selenium即可。如果下载速度慢可以加-i https://pypi.tuna.tsinghua.edu.cn/simple换清华源。第三步下载ChromeDriver。打开Chrome浏览器在地址栏输入chrome://version查看版本号。然后去ChromeDriver的下载页面找到对应版本下载后解压得到一个chromedriver.exe文件。这里有两种用法一是把这个exe直接放到Python安装目录的scripts文件夹里二是放到项目目录下在代码中指定路径。我个人的习惯是放到项目目录下显式指定这样项目换到别的电脑时只要整个文件夹拷走就能跑不太依赖系统环境。验证环境是否准备好可以用一段极简脚本from selenium import webdriver driver webdriver.Chrome() driver.get(https://www.baidu.com) print(driver.title) driver.quit()如果能正常启动浏览器并打印出百度标题说明这套链路已经通了。如果这段脚本都跑不通后面的内容先不用看了回去把环境理顺再说。环境通了整个自动化测试就等于成功了三分之一。3. TPshop注册功能的定位策略与业务逻辑拆解3.1 先理清页面元素再动手写脚本TPshop安装好之后前台首页地址一般是http://127.0.0.1/tpshop/或者带端口号的地址具体看本地环境配置。打开首页右上角就能看到“注册”入口。做自动化测试和手工点鼠标最大的区别在于你得先告诉脚本“去哪里”以及“点什么”而这个“告诉”的过程依赖的就是元素定位。我看到很多新手拿到一个页面第一反应是去抄页面上的XPath什么//*[idapp]/div[1]/div[2]/div[2]/div[2]这种定位方式说实话能用但极其脆弱只要前端HTML有一丁点变动脚本直接崩溃。正确的做法是优先使用ID、Name、ClassName这类相对稳定的定位方式实在不行再用XPath或者CSS选择器而且XPath也尽量用包含文本或者属性判断的方式减少层级依赖。TPshop的注册页面邮箱输入框、手机号输入框、密码输入框、确认密码输入框都带有比较明确的属性。以手机号输入框为例它的HTML结构里通常会有namemobile或类似的属性用driver.find_element(By.NAME, mobile)就比那一长串XPath稳当得多。核心思路是定位方式越简单、越靠近元素的稳定属性脚本的健壮性就越强。3.2 业务逻辑TPshop注册还有一个容易被忽略的点TPshop注册分为账号注册和手机号注册两种方式我强烈建议新手从手机号注册入手。为什么因为账号注册流程太简单了输入用户名和密码点提交就完事对自动化测试而言几乎没有技术含量。而手机号注册涉及一个动态验证码的获取逻辑——它真正的验证码不是由用户输入的而是由后台发到手机上的测试环境中一般会在页面上直接显示。这就引出一个非常关键的测试设计点在处理这类验证码时不能人为地把等待时间写死。比如有的同学习惯time.sleep(3)觉得等三秒验证码就出来了其实这是不科学的——网络状况不同、服务器响应速度不同实际等待时间有波动。更合理的做法是用Selenium提供的WebDriverWait显式等待轮询页面元素直到出现为止。这不仅让脚本更加稳定也符合真实自动化框架的设计理念。等待的逻辑想通了再来看页面操作的顺序点击注册入口切换到注册页面选择手机号注册输入手机号触发发送验证码等待验证码输入框出现并填入填写密码和确认密码点击同意协议最后提交。这里面每一项操作都对应一个Selenium的动作每一步动作之间都需要一个明确的预期结果这就是自动化测试脚本设计的核心思维——不仅仅是写代码而是把业务逻辑翻译成代码。3.3 注册脚本的核心代码参考下面这段代码是我当时跑通时使用的核心逻辑为了篇幅不会把全部代码贴出来但关键的几个步骤都有体现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 import time driver webdriver.Chrome() driver.get(http://127.0.0.1/tpshop/) driver.maximize_window() # 点击免费注册 WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.LINK_TEXT, 免费注册)) ).click() # 切换到手机号注册页签 WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.CSS_SELECTOR, .tab li:last-child a)) ).click() # 输入手机号 mobile 13800138000 driver.find_element(By.NAME, mobile).send_keys(mobile) # 点击获取验证码 driver.find_element(By.ID, sendCode).click() # 页面上会显示测试环境的验证码等待输入框可见后填入 code_input WebDriverWait(driver, 10).until( EC.visibility_of_element_located((By.NAME, verify_code)) ) test_code driver.find_element(By.CSS_SELECTOR, .code_tip).text code_input.send_keys(test_code) # 密码和确认密码 driver.find_element(By.NAME, password).send_keys(test123456) driver.find_element(By.NAME, password2).send_keys(test123456) # 勾选用户协议提交 driver.find_element(By.CSS_SELECTOR, .checkbox).click() driver.find_element(By.CSS_SELECTOR, .btn-reg).click()这段代码有几个值得注意的设计细节。第一所有关键操作都用显式等待包了一层而不是裸奔的find_element加sleep这就保证了元素还没加载好之前脚本会耐心等待而不是直接抛异常。第二截取测试验证码的方式是通过读取页面上的某个提示元素来完成的这依赖TPshop在测试环境把验证码直接输出到了页面上。第三每次跑完注册脚本要换一个新的手机号因为TPshop默认一个手机号只能注册一个账号第二次用同一个号跑会提示已被注册脚本就会失败。注册成功之后页面上通常会出现用户中心入口或者弹出注册成功的提示你可以用这个提示来断言注册是否成功。4. 登录脚本的断言设计与会话保持验证4.1 为什么登录比注册更考验脚本的兼容性TPshop的登录逻辑比注册流程要多考虑一层页面上登录入口和注册入口距离很近但登录表单的控件结构有所不同而且登录成功后页面会跳转如果只验证“点击登录按钮没有报错”这不算一个合格的自动化测试用例。一个合格的登录用例至少应该验证三件事登录动作确实执行了、页面发生了预期的跳转、页面上出现了只有登录用户才能看到的标志性元素。这三个验证点用Selenium实现起来不难但需要你有断言的意识。我见过很多初学者的脚本从头到尾都是在操作元素最后页面上报了个登录成功弹窗脚本就结束了没有做任何校验。这其实只能叫“脚本”不能叫“测试”因为你连结果对不对都没验证。4.2 完整操作流程及代码写法TPshop的登录页面通过首页右侧的登录入口进入也可以直接访问登录页URL。登录表单包含用户名输入框和密码输入框用户名这里支持手机号登录也就意味着注册用的手机号和密码直接可以用来登录。脚本逻辑如下# 打开首页点击登录 driver.get(http://127.0.0.1/tpshop/) WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.LINK_TEXT, 登录)) ).click() # 输入用户名和密码 username 13800138000 password test123456 name_input WebDriverWait(driver, 10).until( EC.visibility_of_element_located((By.ID, username)) ) name_input.send_keys(username) driver.find_element(By.ID, password).send_keys(password) # 如果有图形验证码这里是测试环境时可以直接跳过或自动获取 # 点击登录 driver.find_element(By.CSS_SELECTOR, .btn-login).click() # 验证登录结果等待用户中心入口出现 user_center WebDriverWait(driver, 10).until( EC.visibility_of_element_located((By.CSS_SELECTOR, .user-info)) ) assert user_center.is_displayed(), 登录失败未找到用户信息区域等你真正跑起来马上会遇到一个TPshop特有的问题——登录页面可能有图形验证码。图形验证码是自动化测试最头疼的事情之一因为它的设计初衷就是防止机器操作。如果做的验证码比较复杂比如扭曲变形的文字、需要拖动滑块的拼图那就不太适合放进初学阶段的自动化脚本里了。对于TPshop默认的图形验证码如果只是简单的四位字符可以找开发配置一个万能验证码或者在测试环境关闭验证码校验。做自动化测试时千万不要把重心放在破解验证码上除非你专门研究这一块否则纯粹是浪费时间。登录成功后的断言我习惯用页面跳转后出现的用户中心区域来判断。Selenium的is_displayed()方法可以判断元素是否可见再配合assert语句如果元素没出现脚本就会报AssertionError这就能明确表示登录失败了。用这种断言方式脚本跑完以后你一眼就能看出登录是否成功不用自己去翻浏览器界面。4.3 一个参数化设计优化数据驱动注册和登录跑通之后可以顺手做一个简单的数据驱动改造。不要继续在代码里硬编码用户名和密码而是把它们提取到一个外部文件里比如CSV或者JSON每次运行时从外部读取。这样做的好处在后期的回归测试里非常明显——你可以准备一组有效账号、一组无效账号循环执行登录脚本验证系统对不同账号的校验是否正确。简化的实现思路是import csv def load_test_data(path): cases [] with open(path, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: cases.append(row) return cases for case in load_test_data(login_data.csv): username case[username] password case[password] expected case[expected] # 执行登录最后用expected来判断断言内容这个改造本身不难但它能让脚本从“一次性玩具”变成“可回归的工具”这是自动化测试和手动点按钮最大的差异所在。几乎每一个正式的自动化测试框架核心都是数据与脚本分离。5. 实战中必须记录的四个老大难问题5.1 ChromeDriver版本不匹配错误信息看不明白这个问题我在环境准备部分提过但在实战中遇到的概率实在太高值得单独拿出来再说一次。报错通常是这样的SessionNotCreatedException: Message: session not created: This version of ChromeDriver only supports Chrome version 114。这句话其实已经把答案说得很清楚了但新手往往看不懂英文或者不知道去哪里查Chrome版本。解决办法就是去chrome://version页面查一下浏览器版本号然后找到对应版本的ChromeDriver替换掉。这里有个小技巧ChromeDriver的下载页面列出的版本里可能找不到完全一致的小版本号但只要你选择主版本号一致的版本一般都能正常工作。我见过一个比较极端的案例同事的Chrome版本是116.0.5845.188他下载了116.0.5845.96的驱动心里不踏实问我差这么多会不会有问题实际跑下来完全正常。所以记住主版本号对齐就基本没问题。5.2 元素明明存在点击却报超时这种情况通常不是元素不存在而是元素被遮挡了。TPshop的页面里很多按钮会被弹窗或者浮层盖住比如登录时弹出的营销活动弹窗、注册时的用户协议遮罩层。Selenium点击一个被遮挡的元素时会提示element not interactable或者超时。排查思路分三步一先判断元素是否在DOM中存在用find_elements看返回的列表长度二看元素是否可见用is_displayed三如果都正常但点不了考虑是不是有浮层盖住了。解决方式有两种一是等浮层消失后再点击二是用JavaScript强制执行点击。对于测试环境我一般优先用第一种因为更贴近真实用户的操作习惯——真用户看到弹窗第一反应是点关闭测试脚本也应该模拟这个流程。5.3 验证码导致用例无法稳定执行系统加了验证码之后自动化的稳定性会瞬间下降。刚接触测试的同学往往想着怎么去识别验证码比如用OCR、接第三方平台但这些方案成本高、不稳定而且每次跑测试可能都要花钱。在项目早期做冒烟测试和功能回归时最好的方案是找开发配合在测试环境下屏蔽掉验证码校验或者提供一个万能的测试验证码。如果实在没法修改系统只能在脚本层想办法那至少要让这个用例可配置可以加一个环境判断如果当前是测试环境就跳过验证码校验逻辑如果跑在生产环境预发环境则提示需要人工介入。这样用例既能在日常回归中跑通又不会在不该跑的环境里乱跑。5.4 断言位置不对脚本“假成功”脚本跑完没有报错并不代表测试通过了。我遇到过不止一次这样的情况脚本从头到尾非常流畅地执行完了控制台也没有报任何异常最后打开浏览器一看根本没有登录成功只是登录按钮的点击动作触发了一个前端校验提示而脚本没有校验这个结果。原因很直接就是断言的位置放错了或者压根没有断言。处理这个问题有没有什么方法论有而且是三条铁律。第一每次操作之后必须有一个校验否则这个操作就没有意义第二校验的必须是业务结果而不是页面有没有加载出来第三如果预期是成功但实际是失败断言必须让脚本显式地失败而不是默默无闻地跑过去。登录成功最重要的标志不是停留在登录页而是跳转到用户中心或首页并出现账号信息要拿这类强标志性元素来断言而不是看页面标题变了没有。6. 项目结构如何组织才能让它从练习变成资产前面写的基本都是脚本层面的事情但如果你只是把代码堆在一个py文件里跑通一次就算完了那这个项目对你的成长价值非常有限。真正值得花时间做的是把这套练习按标准的自动化测试项目结构组织起来哪怕项目的规模并不大。我当时做的目录规划如下tpshop_auto_test/ ├── base/ │ ├── __init__.py │ ├── base_page.py # 封装WebDriver的公共操作 │ └── base_test.py # 封装用例的公共逻辑 ├── pages/ │ ├── __init__.py │ ├── register_page.py # 注册页面的元素与操作 │ └── login_page.py # 登录页面的元素与操作 ├── testcases/ │ ├── __init__.py │ ├── test_register.py │ └── test_login.py ├── data/ │ └── login_data.csv ├── utils/ │ └── driver_factory.py ├── reports/ └── requirements.txt这种结构还能发挥一个作用——为将来引入pytest等主流测试框架铺垫。如果你从一开始就把脚本写成函数堆叠想迁移到pytest框架等于要全部推翻重写。而如果你一开始就把注册和登录分别写成独立的class和方法将来加一段pytest断言就能直接跑出漂亮的测试报告。说到底注册和登录这两个功能只是起点。TPshop这个项目最好的地方在于它给你提供了一个可以无限扩展的练习场购物车、订单流程、后台商品管理、优惠券模块所有这些功能都值得从手工功能测试的眼光转向自动化测试脚本。你每写完一个模块的脚本Selenium的操作熟练度、定位策略的直觉、断言点的敏感度都会上一个台阶。在你开始动手之前我最后提一个建议不管你的Python基础多扎实一定要老老实实地把环境从零开始搭一遍然后把注册和登录脚本至少手敲三遍不要复制粘贴。手敲三遍之后你自然就理解了哪些地方容易报错哪些坑是必然要踩的这种体感和看代码是完全不一样的。自动化测试从来不是把代码跑通就够了真正有价值的是每一次报错之后你能独立定位问题的过程。把这些过程记录下来比任何测试报告都有意义。本文还有配套的精品资源点击获取