1. 项目概述当登录测试遇上AI与2FA最近在搞一个挺有意思的测试项目核心就一句话用AI自动化测试工具去测一个开启了双重认证2FA的GitHub登录流程。听起来是不是有点“自讨苦吃”毕竟2FA设计出来就是为了增加安全门槛防止自动化脚本轻易通过的。但恰恰是这种“反自动化”的场景成了检验现代AI测试工具能力的绝佳试金石。这个项目不是为了破解或绕过安全机制而是站在质量保障和用户体验的角度去验证一个完整的、包含人机交互环节的登录流程在自动化测试框架下是否依然能被可靠地验证。对于任何涉及敏感操作或高频使用的在线平台登录模块的稳定性都是命脉而2FA的引入让传统的基于接口的自动化测试几乎失效这就给了AI驱动的UI自动化测试一个巨大的舞台。你可能会问为什么是GitHub因为它几乎是全球开发者的标配其登录流程尤其是2FA流程设计得相对标准和典型。从输入账号密码到跳转至2FA验证页面可能是输入TOTP动态码、点击邮件/短信链接、或使用安全密钥这一系列步骤涵盖了现代Web认证的主要形态。成功模拟并测试这个流程意味着你的自动化方案具备了处理复杂、多步骤、且包含临时验证码这类“动态障碍”的能力。这不仅仅是测试一个按钮能不能点而是测试一整套需要“理解”上下文、并能应对“变化”的交互逻辑。这个指南适合谁如果你是测试工程师正在为如何自动化测试带有2FA的应用而头疼如果你是开发者想为自己的项目构建更健壮的登录测试套件或者你单纯对“AI如何解决传统自动化难题”感到好奇那么接下来的内容应该能给你不少直接的参考和可落地的思路。我们会绕过那些空洞的理论直接进入“怎么做”的环节并分享我在这个过程中踩过的坑和总结出的有效经验。2. 核心思路拆解“不可自动化”的2FA流程传统的自动化测试无论是Selenium还是Puppeteer在面对2FA时都会卡壳。核心矛盾在于2FA的验证码无论是TOTP、短信还是邮件是动态的、一次性的并且通常设计为“人工读取并输入”。直接让脚本去获取并输入这些码在技术上有一定难度如需要读取短信数据库或邮件服务器在安全策略上也可能被禁止如Google Authenticator的种子密钥通常不会暴露。因此我们的核心思路不是“破解”2FA而是“策略性地处理”它让自动化流程能够顺畅地通过这个环节又不违背安全原则和测试的初衷。2.1 测试环境策略使用“测试专用”2FA方法这是最关键的一步。我们绝对不能在真实的、绑定了个人手机或邮箱的GitHub账号上进行自动化测试。相反必须建立一个完全受控的测试环境。创建测试账号专门注册一个用于自动化测试的GitHub账号。确保该账号没有关联任何重要的仓库或个人信息。配置可预测的2FA这是打破僵局的核心。GitHub支持多种2FA方式我们需要选择一种在自动化环境中“可获取”或“可模拟”的。最佳选择TOTP基于时间的一次性密码 固定种子。我们可以使用像pyotp这样的库在测试代码中预先生成一个固定的TOTP种子密钥Secret。在GitHub的2FA设置中选择“设置身份验证器应用程序”然后手动输入我们代码中生成的这个种子密钥。这样在测试运行时我们就可以用同一个pyotp库根据当前时间实时生成正确的6位验证码。这完全模拟了真实用户打开Authenticator App查看码的过程但它是完全可编程、可预测的。备用方案不推荐用于CI/CD使用备用恢复码。GitHub在启用2FA时会提供一组一次性使用的恢复码。你可以将其中一个恢复码硬编码在测试脚本中用于登录。但请注意每个码只能用一次用后即废不适合需要反复运行的自动化测试套件。绝对避免在测试账号上绑定真实的手机号短信验证或主邮箱。这会导致测试依赖外部不可控服务且可能触发风控。注意将TOTP种子密钥存储在代码或配置文件中时务必确保其安全。不要将其提交到公开的版本库。应使用环境变量或安全的密钥管理服务来传递。2.2 AI自动化测试工具的选型逻辑“AI自动化测试”在这里并不是指用一个通用AI如ChatGPT来写测试脚本而是指那些集成了计算机视觉CV、自然语言处理NLP或自愈Self-healing等AI能力的测试工具或框架。它们能更好地处理UI变化、动态内容和复杂的交互流。Playwright 视觉AI插件/模式Playwright本身是一个强大的浏览器自动化库。它的优势在于稳定、快并且对现代Web技术支持非常好。我们可以将其与一些视觉识别库如pytesseract用于OCR但这里我们不需要结合但更关键的是利用Playwright的codegen模式录制登录流程然后手动修改脚本在2FA输入步骤插入我们生成的TOTP码。对于“AI”部分我们可以考虑使用像Healenium这样的开源自愈框架的后端理念或者寻找能智能定位元素的AI插件但在这个具体场景下元素定位通常很明确核心挑战是2FA码的生成与输入。专精的AI测试平台如Testim, Mabl, Functionize这些商业平台内置了基于AI的元素定位、自愈和流程理解能力。它们通常能更好地处理页面的微小变化。你可以将登录流程录制下来然后在需要输入2FA码的步骤配置一个“自定义脚本”步骤来调用一个接口或执行一段代码来生成TOTP码。这类平台的优点是维护成本相对较低但缺点是通常较贵且可能对测试环境的控制力不如纯代码方案。基于Selenium的AI增强框架例如使用Selenium配合SeleniumBase框架它包含一些智能等待和断言功能。或者使用Robocorp的rpaframework它集成了很多用于企业级自动化的智能库。但对于这个特定任务Playwright往往是更现代、更轻量的起点。我的选择与理由对于这个“Shortest”指南我选择Playwright (Python)。原因如下它免费、开源、功能强大社区活跃它生成的脚本简洁可靠它能无缝处理SPA单页应用和网络请求这对于跟踪GitHub登录后的跳转至关重要最重要的是我们可以用纯代码完全控制整个流程包括集成pyotp来生成2FA码这种控制力对于构建稳定可靠的自动化测试至关重要。3. 实战构建最短的GitHub 2FA登录AI测试脚本让我们开始动手。目标是创建一个尽可能简洁、但功能完整的脚本能够自动完成从打开登录页到成功登录通过2FA的全过程。3.1 环境准备与依赖安装首先确保你有一个干净的Python环境建议3.8。# 创建项目目录并进入 mkdir github-2fa-ai-test cd github-2fa-ai-test # 创建虚拟环境可选但推荐 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 安装核心依赖 pip install playwright pyotp # 安装Playwright所需的浏览器 playwright install chromiumplaywright: 主自动化库。pyotp: 用于生成符合TOTP标准的动态验证码。我们选择安装chromium作为测试浏览器因为它轻量且足够。3.2 获取并配置TOTP种子密钥在GitHub上为测试账号启用2FAAuthenticator App方式登录你的GitHub测试账号进入 Settings - Password and authentication - Two-factor authentication。点击“Set up using an app”。GitHub会显示一个二维码和一个手动输入密钥一串Base32编码的字符串。不要扫描二维码我们只需要那串密钥。在测试代码中安全地使用密钥绝对不要将密钥直接写在代码里。创建一个.env文件确保在.gitignore中忽略它来存储密钥。# .env 文件内容 GITHUB_TEST_USERNAMEyour_test_github_username GITHUB_TEST_PASSWORDyour_test_github_password GITHUB_2FA_SECRETJBSWY3DPEHPK3PXP # 这是示例替换成你的真实密钥安装python-dotenv来读取环境变量pip install python-dotenv3.3 编写核心测试脚本创建一个名为test_github_2fa_login.py的文件。import asyncio import os from dotenv import load_dotenv import pyotp from playwright.async_api import async_playwright # 加载环境变量 load_dotenv() GITHUB_USERNAME os.getenv(GITHUB_TEST_USERNAME) GITHUB_PASSWORD os.getenv(GITHUB_TEST_PASSWORD) TOTP_SECRET os.getenv(GITHUB_2FA_SECRET) # 你的Base32密钥 async def test_github_login_with_2fa(): 使用Playwright和PyOTP自动化测试GitHub 2FA登录流程。 async with async_playwright() as p: # 启动浏览器headlessFalse便于调试正式运行可设为True browser await p.chromium.launch(headlessFalse, slow_mo100) # slow_mo让操作变慢方便观察 context await browser.new_context() page await context.new_page() try: print(步骤1: 导航至GitHub登录页) await page.goto(https://github.com/login) # 等待登录表单加载 await page.wait_for_selector(input[namelogin]) print(步骤2: 输入用户名和密码) await page.fill(input[namelogin], GITHUB_USERNAME) await page.fill(input[namepassword], GITHUB_PASSWORD) # 点击登录按钮 await page.click(input[namecommit]) # 等待页面跳转此时应该进入2FA验证页面 print(步骤3: 等待2FA验证页面加载...) # GitHub的2FA页面可能有多种元素一个常见的标识是包含“two-factor”字样的标题或输入框 await page.wait_for_selector(input[nameapp_otp], timeout10000) # 等待OTP输入框出现 print(步骤4: 生成并输入TOTP验证码) # 使用pyotp生成当前时间的有效验证码 totp pyotp.TOTP(TOTP_SECRET) current_otp totp.now() print(f生成的TOTP码: {current_otp}) # 将验证码输入到2FA输入框 await page.fill(input[nameapp_otp], current_otp) # 点击验证按钮按钮文本可能是“Verify”或“Submit” # 使用更通用的选择器包含‘verify’文本的按钮 await page.click(button:has-text(Verify)) print(步骤5: 等待登录成功跳转) # 登录成功后通常会跳转到主页或用户仪表盘。我们通过检查页面URL或特定元素来确认。 # 例如等待用户头像菜单出现这是登录成功的可靠标志。 await page.wait_for_selector(img[alt*], timeout15000) # 等待包含的用户头像alt文本 # 或者检查URL不再是登录页 # assert login not in page.url.lower() print(✅ 登录成功2FA自动化测试通过。) # 这里可以加入更多的断言比如检查用户名是否正确显示等。 # username_display await page.text_content(span[data-login]) # assert GITHUB_USERNAME in username_display # 为了演示我们停留几秒然后退出 await asyncio.sleep(3) except Exception as e: # 出错时截图这是非常重要的调试手段 await page.screenshot(pathlogin_error.png) print(f❌ 测试失败错误信息: {e}) print(已保存错误截图至 login_error.png) raise e finally: # 关闭浏览器 await browser.close() if __name__ __main__: asyncio.run(test_github_login_with_2fa())3.4 脚本逐行解析与关键点环境变量加载load_dotenv()从.env文件安全地读取敏感信息。这是保护密钥的最佳实践。浏览器启动参数headlessFalse在调试阶段非常有用你可以亲眼看到浏览器执行每一步操作。slow_mo100将每个Playwright操作减慢100毫秒让你能看清过程。正式运行时应移除或设为0。等待策略page.wait_for_selector是UI自动化的核心。它等待特定元素出现在DOM中比固定的time.sleep更可靠、更高效。我们分别等待了登录输入框、2FA输入框和登录成功后的头像元素。TOTP生成pyotp.TOTP(TOTP_SECRET).now()这一行是整个2FA自动化的“魔法”。它根据共享密钥和当前时间基于30秒间隔计算出完全符合RFC 6238标准的6位数字。只要测试机的时间与标准时间NTP同步相差不大这个码就是有效的。元素定位登录表单使用了input[name...]这种基于属性的精确选择器非常稳定。2FA输入框同样使用input[nameapp_otp]。GitHub的这个name属性相对稳定。验证按钮使用了文本选择器button:has-text(Verify)。这比依赖可能变化的CSS类名更健壮。如果GitHub的按钮文本本地化或更改了你需要相应调整。成功标识使用img[alt*]来查找用户头像因为头像的alt属性通常包含用户名。这是一个巧妙的、相对稳定的检查点。错误处理与截图在except块中捕获异常并截图能极大提升调试效率。你一眼就能看出脚本是在哪一步失败的例如页面没加载出来、元素没找到、验证码错误等。4. 将脚本升级为“AI增强”测试上面的脚本是基础、可靠的自动化。那么“AI”体现在哪里在这个上下文中我们可以从以下几个方向引入AI或智能化的能力使其更健壮、更“聪明”更能应对真实世界的波动。4.1 自愈定位Self-healing Locators这是AI自动化测试最典型的应用。如果GitHub的前端工程师某天把登录按钮的name属性改了或者把2FA输入框的CSS类名重构了我们的脚本就会因为找不到元素而失败。自愈定位器能解决这个问题。实现思路模拟我们可以不依赖单一属性而是定义元素的“多重特征”并在主定位器失败时尝试备用方案。async def smart_click(page, selector_attempts): 智能点击函数尝试多种选择器直到成功。 selector_attempts: 一个列表包含多个选择器字符串或定位策略。 for selector in selector_attempts: try: element await page.wait_for_selector(selector, timeout2000) # 给每个选择器较短超时 await element.click() print(f使用选择器 {selector} 点击成功。) return True except Exception as e: print(f选择器 {selector} 失败尝试下一个...) continue raise Exception(所有备选选择器都失败了无法点击元素。) # 在脚本中使用 # 替换原来的 await page.click(input[namecommit]) login_button_selectors [ input[namecommit], # 主选择器 input[typesubmit], # 备用1提交类型输入框 button[typesubmit], # 备用2提交类型按钮 button:has-text(Sign in), # 备用3按钮文本 form[action/session] input[typesubmit] # 备用4基于表单结构的更复杂选择器 ] await smart_click(page, login_button_selectors)虽然这还不是真正的AI如基于视觉或语义的识别但它通过“备选策略”实现了类似自愈的效果显著提升了脚本的鲁棒性。一些高级的AI测试工具正是将这类策略内化并可能结合视觉特征来定位元素。4.2 动态等待与条件断言AI测试的另一个特点是能“理解”页面状态而不是机械等待固定时间或固定元素。我们可以通过组合Playwright的内置等待条件来实现更智能的流程控制。# 示例更智能地等待登录成功 try: # 方案1等待导航到一个非登录页的URL await page.wait_for_url(lambda url: login not in url and session not in url, timeout15000) # 方案2同时等待多个成功标志中的任意一个出现更稳健 from playwright.async_api import TimeoutError as PlaywrightTimeoutError try: # 尝试等待用户菜单 await page.wait_for_selector(details-menu, timeout5000) except PlaywrightTimeoutError: try: # 如果没等到菜单尝试等待仓库列表或动态消息流 await page.wait_for_selector(.dashboard, timeout5000) except PlaywrightTimeoutError: # 如果都没等到检查页面标题或URL是否包含用户名 title await page.title() if GITHUB_USERNAME.lower() in title.lower(): print(通过页面标题判断登录成功。) else: raise Exception(无法确定登录状态可能失败。) print(✅ 通过智能条件判断登录成功。) except Exception as e: print(登录状态确认失败。) raise e这种“尝试A不行再试B最后兜底C”的逻辑模仿了人类在遇到不确定情况时的判断过程是让自动化脚本更智能、更适应变化的关键。4.3 集成视觉验证进阶虽然在这个登录流程中必要性不高但对于更复杂的UI验证可以集成简单的视觉AI。例如使用pytesseractOCR来读取页面上的文本信息进行断言或者使用opencv进行图像匹配来确认某个图标是否出现。但这会引入更多依赖和复杂性对于纯登录测试来说可能有点“杀鸡用牛刀”。更常见的AI视觉应用是在回归测试中对比页面截图检测非预期的UI变化。5. 常见问题、调试技巧与避坑指南在实际运行中你几乎一定会遇到一些问题。下面是我在多次实践中总结的“血泪经验”。5.1 TOTP码验证失败这是最常见的问题。症状脚本成功输入了TOTP码但点击验证后页面提示“验证码无效”或类似错误。排查与解决时钟不同步这是头号嫌疑犯。TOTP基于精确的30秒时间窗口。运行脚本的机器或容器必须与标准时间如通过NTP同步保持高度一致。偏差超过30秒就会导致生成的码无效。检查在脚本中打印datetime.datetime.utcnow()并与网络时间对比。解决确保测试环境时钟同步。在Docker容器中尤其要注意。密钥错误.env文件中的GITHUB_2FA_SECRET与你在GitHub后台手动输入或扫描的密钥不一致。确保没有多余的空格或换行。密钥通常是Base32编码字母A-Z, 2-7。编码问题pyotp需要的是Base32编码的字符串。如果你从二维码解码或其他途径获取的密钥格式不对也会失败。手动验证在脚本中打印出生成的TOTP码同时用你手机上的Authenticator App绑定的是同一个密钥查看同一时刻的码对比是否一致。这是最直接的验证方法。5.2 页面元素定位失败症状脚本在wait_for_selector处超时抛出TimeoutError。排查与解决页面未加载/跳转错误先检查上一步操作是否成功。在关键步骤后添加await asyncio.sleep(2)并设置headlessFalse观察浏览器状态。使用page.screenshot()截图看看停在了哪一步。选择器过时GitHub的UI可能会更新。使用浏览器的开发者工具F12重新检查目标元素的属性。尝试使用更稳定、更语义化的属性如name、>
AI自动化测试实战：破解GitHub双重认证(2FA)登录难题
1. 项目概述当登录测试遇上AI与2FA最近在搞一个挺有意思的测试项目核心就一句话用AI自动化测试工具去测一个开启了双重认证2FA的GitHub登录流程。听起来是不是有点“自讨苦吃”毕竟2FA设计出来就是为了增加安全门槛防止自动化脚本轻易通过的。但恰恰是这种“反自动化”的场景成了检验现代AI测试工具能力的绝佳试金石。这个项目不是为了破解或绕过安全机制而是站在质量保障和用户体验的角度去验证一个完整的、包含人机交互环节的登录流程在自动化测试框架下是否依然能被可靠地验证。对于任何涉及敏感操作或高频使用的在线平台登录模块的稳定性都是命脉而2FA的引入让传统的基于接口的自动化测试几乎失效这就给了AI驱动的UI自动化测试一个巨大的舞台。你可能会问为什么是GitHub因为它几乎是全球开发者的标配其登录流程尤其是2FA流程设计得相对标准和典型。从输入账号密码到跳转至2FA验证页面可能是输入TOTP动态码、点击邮件/短信链接、或使用安全密钥这一系列步骤涵盖了现代Web认证的主要形态。成功模拟并测试这个流程意味着你的自动化方案具备了处理复杂、多步骤、且包含临时验证码这类“动态障碍”的能力。这不仅仅是测试一个按钮能不能点而是测试一整套需要“理解”上下文、并能应对“变化”的交互逻辑。这个指南适合谁如果你是测试工程师正在为如何自动化测试带有2FA的应用而头疼如果你是开发者想为自己的项目构建更健壮的登录测试套件或者你单纯对“AI如何解决传统自动化难题”感到好奇那么接下来的内容应该能给你不少直接的参考和可落地的思路。我们会绕过那些空洞的理论直接进入“怎么做”的环节并分享我在这个过程中踩过的坑和总结出的有效经验。2. 核心思路拆解“不可自动化”的2FA流程传统的自动化测试无论是Selenium还是Puppeteer在面对2FA时都会卡壳。核心矛盾在于2FA的验证码无论是TOTP、短信还是邮件是动态的、一次性的并且通常设计为“人工读取并输入”。直接让脚本去获取并输入这些码在技术上有一定难度如需要读取短信数据库或邮件服务器在安全策略上也可能被禁止如Google Authenticator的种子密钥通常不会暴露。因此我们的核心思路不是“破解”2FA而是“策略性地处理”它让自动化流程能够顺畅地通过这个环节又不违背安全原则和测试的初衷。2.1 测试环境策略使用“测试专用”2FA方法这是最关键的一步。我们绝对不能在真实的、绑定了个人手机或邮箱的GitHub账号上进行自动化测试。相反必须建立一个完全受控的测试环境。创建测试账号专门注册一个用于自动化测试的GitHub账号。确保该账号没有关联任何重要的仓库或个人信息。配置可预测的2FA这是打破僵局的核心。GitHub支持多种2FA方式我们需要选择一种在自动化环境中“可获取”或“可模拟”的。最佳选择TOTP基于时间的一次性密码 固定种子。我们可以使用像pyotp这样的库在测试代码中预先生成一个固定的TOTP种子密钥Secret。在GitHub的2FA设置中选择“设置身份验证器应用程序”然后手动输入我们代码中生成的这个种子密钥。这样在测试运行时我们就可以用同一个pyotp库根据当前时间实时生成正确的6位验证码。这完全模拟了真实用户打开Authenticator App查看码的过程但它是完全可编程、可预测的。备用方案不推荐用于CI/CD使用备用恢复码。GitHub在启用2FA时会提供一组一次性使用的恢复码。你可以将其中一个恢复码硬编码在测试脚本中用于登录。但请注意每个码只能用一次用后即废不适合需要反复运行的自动化测试套件。绝对避免在测试账号上绑定真实的手机号短信验证或主邮箱。这会导致测试依赖外部不可控服务且可能触发风控。注意将TOTP种子密钥存储在代码或配置文件中时务必确保其安全。不要将其提交到公开的版本库。应使用环境变量或安全的密钥管理服务来传递。2.2 AI自动化测试工具的选型逻辑“AI自动化测试”在这里并不是指用一个通用AI如ChatGPT来写测试脚本而是指那些集成了计算机视觉CV、自然语言处理NLP或自愈Self-healing等AI能力的测试工具或框架。它们能更好地处理UI变化、动态内容和复杂的交互流。Playwright 视觉AI插件/模式Playwright本身是一个强大的浏览器自动化库。它的优势在于稳定、快并且对现代Web技术支持非常好。我们可以将其与一些视觉识别库如pytesseract用于OCR但这里我们不需要结合但更关键的是利用Playwright的codegen模式录制登录流程然后手动修改脚本在2FA输入步骤插入我们生成的TOTP码。对于“AI”部分我们可以考虑使用像Healenium这样的开源自愈框架的后端理念或者寻找能智能定位元素的AI插件但在这个具体场景下元素定位通常很明确核心挑战是2FA码的生成与输入。专精的AI测试平台如Testim, Mabl, Functionize这些商业平台内置了基于AI的元素定位、自愈和流程理解能力。它们通常能更好地处理页面的微小变化。你可以将登录流程录制下来然后在需要输入2FA码的步骤配置一个“自定义脚本”步骤来调用一个接口或执行一段代码来生成TOTP码。这类平台的优点是维护成本相对较低但缺点是通常较贵且可能对测试环境的控制力不如纯代码方案。基于Selenium的AI增强框架例如使用Selenium配合SeleniumBase框架它包含一些智能等待和断言功能。或者使用Robocorp的rpaframework它集成了很多用于企业级自动化的智能库。但对于这个特定任务Playwright往往是更现代、更轻量的起点。我的选择与理由对于这个“Shortest”指南我选择Playwright (Python)。原因如下它免费、开源、功能强大社区活跃它生成的脚本简洁可靠它能无缝处理SPA单页应用和网络请求这对于跟踪GitHub登录后的跳转至关重要最重要的是我们可以用纯代码完全控制整个流程包括集成pyotp来生成2FA码这种控制力对于构建稳定可靠的自动化测试至关重要。3. 实战构建最短的GitHub 2FA登录AI测试脚本让我们开始动手。目标是创建一个尽可能简洁、但功能完整的脚本能够自动完成从打开登录页到成功登录通过2FA的全过程。3.1 环境准备与依赖安装首先确保你有一个干净的Python环境建议3.8。# 创建项目目录并进入 mkdir github-2fa-ai-test cd github-2fa-ai-test # 创建虚拟环境可选但推荐 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 安装核心依赖 pip install playwright pyotp # 安装Playwright所需的浏览器 playwright install chromiumplaywright: 主自动化库。pyotp: 用于生成符合TOTP标准的动态验证码。我们选择安装chromium作为测试浏览器因为它轻量且足够。3.2 获取并配置TOTP种子密钥在GitHub上为测试账号启用2FAAuthenticator App方式登录你的GitHub测试账号进入 Settings - Password and authentication - Two-factor authentication。点击“Set up using an app”。GitHub会显示一个二维码和一个手动输入密钥一串Base32编码的字符串。不要扫描二维码我们只需要那串密钥。在测试代码中安全地使用密钥绝对不要将密钥直接写在代码里。创建一个.env文件确保在.gitignore中忽略它来存储密钥。# .env 文件内容 GITHUB_TEST_USERNAMEyour_test_github_username GITHUB_TEST_PASSWORDyour_test_github_password GITHUB_2FA_SECRETJBSWY3DPEHPK3PXP # 这是示例替换成你的真实密钥安装python-dotenv来读取环境变量pip install python-dotenv3.3 编写核心测试脚本创建一个名为test_github_2fa_login.py的文件。import asyncio import os from dotenv import load_dotenv import pyotp from playwright.async_api import async_playwright # 加载环境变量 load_dotenv() GITHUB_USERNAME os.getenv(GITHUB_TEST_USERNAME) GITHUB_PASSWORD os.getenv(GITHUB_TEST_PASSWORD) TOTP_SECRET os.getenv(GITHUB_2FA_SECRET) # 你的Base32密钥 async def test_github_login_with_2fa(): 使用Playwright和PyOTP自动化测试GitHub 2FA登录流程。 async with async_playwright() as p: # 启动浏览器headlessFalse便于调试正式运行可设为True browser await p.chromium.launch(headlessFalse, slow_mo100) # slow_mo让操作变慢方便观察 context await browser.new_context() page await context.new_page() try: print(步骤1: 导航至GitHub登录页) await page.goto(https://github.com/login) # 等待登录表单加载 await page.wait_for_selector(input[namelogin]) print(步骤2: 输入用户名和密码) await page.fill(input[namelogin], GITHUB_USERNAME) await page.fill(input[namepassword], GITHUB_PASSWORD) # 点击登录按钮 await page.click(input[namecommit]) # 等待页面跳转此时应该进入2FA验证页面 print(步骤3: 等待2FA验证页面加载...) # GitHub的2FA页面可能有多种元素一个常见的标识是包含“two-factor”字样的标题或输入框 await page.wait_for_selector(input[nameapp_otp], timeout10000) # 等待OTP输入框出现 print(步骤4: 生成并输入TOTP验证码) # 使用pyotp生成当前时间的有效验证码 totp pyotp.TOTP(TOTP_SECRET) current_otp totp.now() print(f生成的TOTP码: {current_otp}) # 将验证码输入到2FA输入框 await page.fill(input[nameapp_otp], current_otp) # 点击验证按钮按钮文本可能是“Verify”或“Submit” # 使用更通用的选择器包含‘verify’文本的按钮 await page.click(button:has-text(Verify)) print(步骤5: 等待登录成功跳转) # 登录成功后通常会跳转到主页或用户仪表盘。我们通过检查页面URL或特定元素来确认。 # 例如等待用户头像菜单出现这是登录成功的可靠标志。 await page.wait_for_selector(img[alt*], timeout15000) # 等待包含的用户头像alt文本 # 或者检查URL不再是登录页 # assert login not in page.url.lower() print(✅ 登录成功2FA自动化测试通过。) # 这里可以加入更多的断言比如检查用户名是否正确显示等。 # username_display await page.text_content(span[data-login]) # assert GITHUB_USERNAME in username_display # 为了演示我们停留几秒然后退出 await asyncio.sleep(3) except Exception as e: # 出错时截图这是非常重要的调试手段 await page.screenshot(pathlogin_error.png) print(f❌ 测试失败错误信息: {e}) print(已保存错误截图至 login_error.png) raise e finally: # 关闭浏览器 await browser.close() if __name__ __main__: asyncio.run(test_github_login_with_2fa())3.4 脚本逐行解析与关键点环境变量加载load_dotenv()从.env文件安全地读取敏感信息。这是保护密钥的最佳实践。浏览器启动参数headlessFalse在调试阶段非常有用你可以亲眼看到浏览器执行每一步操作。slow_mo100将每个Playwright操作减慢100毫秒让你能看清过程。正式运行时应移除或设为0。等待策略page.wait_for_selector是UI自动化的核心。它等待特定元素出现在DOM中比固定的time.sleep更可靠、更高效。我们分别等待了登录输入框、2FA输入框和登录成功后的头像元素。TOTP生成pyotp.TOTP(TOTP_SECRET).now()这一行是整个2FA自动化的“魔法”。它根据共享密钥和当前时间基于30秒间隔计算出完全符合RFC 6238标准的6位数字。只要测试机的时间与标准时间NTP同步相差不大这个码就是有效的。元素定位登录表单使用了input[name...]这种基于属性的精确选择器非常稳定。2FA输入框同样使用input[nameapp_otp]。GitHub的这个name属性相对稳定。验证按钮使用了文本选择器button:has-text(Verify)。这比依赖可能变化的CSS类名更健壮。如果GitHub的按钮文本本地化或更改了你需要相应调整。成功标识使用img[alt*]来查找用户头像因为头像的alt属性通常包含用户名。这是一个巧妙的、相对稳定的检查点。错误处理与截图在except块中捕获异常并截图能极大提升调试效率。你一眼就能看出脚本是在哪一步失败的例如页面没加载出来、元素没找到、验证码错误等。4. 将脚本升级为“AI增强”测试上面的脚本是基础、可靠的自动化。那么“AI”体现在哪里在这个上下文中我们可以从以下几个方向引入AI或智能化的能力使其更健壮、更“聪明”更能应对真实世界的波动。4.1 自愈定位Self-healing Locators这是AI自动化测试最典型的应用。如果GitHub的前端工程师某天把登录按钮的name属性改了或者把2FA输入框的CSS类名重构了我们的脚本就会因为找不到元素而失败。自愈定位器能解决这个问题。实现思路模拟我们可以不依赖单一属性而是定义元素的“多重特征”并在主定位器失败时尝试备用方案。async def smart_click(page, selector_attempts): 智能点击函数尝试多种选择器直到成功。 selector_attempts: 一个列表包含多个选择器字符串或定位策略。 for selector in selector_attempts: try: element await page.wait_for_selector(selector, timeout2000) # 给每个选择器较短超时 await element.click() print(f使用选择器 {selector} 点击成功。) return True except Exception as e: print(f选择器 {selector} 失败尝试下一个...) continue raise Exception(所有备选选择器都失败了无法点击元素。) # 在脚本中使用 # 替换原来的 await page.click(input[namecommit]) login_button_selectors [ input[namecommit], # 主选择器 input[typesubmit], # 备用1提交类型输入框 button[typesubmit], # 备用2提交类型按钮 button:has-text(Sign in), # 备用3按钮文本 form[action/session] input[typesubmit] # 备用4基于表单结构的更复杂选择器 ] await smart_click(page, login_button_selectors)虽然这还不是真正的AI如基于视觉或语义的识别但它通过“备选策略”实现了类似自愈的效果显著提升了脚本的鲁棒性。一些高级的AI测试工具正是将这类策略内化并可能结合视觉特征来定位元素。4.2 动态等待与条件断言AI测试的另一个特点是能“理解”页面状态而不是机械等待固定时间或固定元素。我们可以通过组合Playwright的内置等待条件来实现更智能的流程控制。# 示例更智能地等待登录成功 try: # 方案1等待导航到一个非登录页的URL await page.wait_for_url(lambda url: login not in url and session not in url, timeout15000) # 方案2同时等待多个成功标志中的任意一个出现更稳健 from playwright.async_api import TimeoutError as PlaywrightTimeoutError try: # 尝试等待用户菜单 await page.wait_for_selector(details-menu, timeout5000) except PlaywrightTimeoutError: try: # 如果没等到菜单尝试等待仓库列表或动态消息流 await page.wait_for_selector(.dashboard, timeout5000) except PlaywrightTimeoutError: # 如果都没等到检查页面标题或URL是否包含用户名 title await page.title() if GITHUB_USERNAME.lower() in title.lower(): print(通过页面标题判断登录成功。) else: raise Exception(无法确定登录状态可能失败。) print(✅ 通过智能条件判断登录成功。) except Exception as e: print(登录状态确认失败。) raise e这种“尝试A不行再试B最后兜底C”的逻辑模仿了人类在遇到不确定情况时的判断过程是让自动化脚本更智能、更适应变化的关键。4.3 集成视觉验证进阶虽然在这个登录流程中必要性不高但对于更复杂的UI验证可以集成简单的视觉AI。例如使用pytesseractOCR来读取页面上的文本信息进行断言或者使用opencv进行图像匹配来确认某个图标是否出现。但这会引入更多依赖和复杂性对于纯登录测试来说可能有点“杀鸡用牛刀”。更常见的AI视觉应用是在回归测试中对比页面截图检测非预期的UI变化。5. 常见问题、调试技巧与避坑指南在实际运行中你几乎一定会遇到一些问题。下面是我在多次实践中总结的“血泪经验”。5.1 TOTP码验证失败这是最常见的问题。症状脚本成功输入了TOTP码但点击验证后页面提示“验证码无效”或类似错误。排查与解决时钟不同步这是头号嫌疑犯。TOTP基于精确的30秒时间窗口。运行脚本的机器或容器必须与标准时间如通过NTP同步保持高度一致。偏差超过30秒就会导致生成的码无效。检查在脚本中打印datetime.datetime.utcnow()并与网络时间对比。解决确保测试环境时钟同步。在Docker容器中尤其要注意。密钥错误.env文件中的GITHUB_2FA_SECRET与你在GitHub后台手动输入或扫描的密钥不一致。确保没有多余的空格或换行。密钥通常是Base32编码字母A-Z, 2-7。编码问题pyotp需要的是Base32编码的字符串。如果你从二维码解码或其他途径获取的密钥格式不对也会失败。手动验证在脚本中打印出生成的TOTP码同时用你手机上的Authenticator App绑定的是同一个密钥查看同一时刻的码对比是否一致。这是最直接的验证方法。5.2 页面元素定位失败症状脚本在wait_for_selector处超时抛出TimeoutError。排查与解决页面未加载/跳转错误先检查上一步操作是否成功。在关键步骤后添加await asyncio.sleep(2)并设置headlessFalse观察浏览器状态。使用page.screenshot()截图看看停在了哪一步。选择器过时GitHub的UI可能会更新。使用浏览器的开发者工具F12重新检查目标元素的属性。尝试使用更稳定、更语义化的属性如name、>
