1. 项目概述为什么选择 Sahi 来啃 Web 自动化测试这块硬骨头做 Web 自动化测试有些年头了从最早的 QTP 到后来火遍大江南北的 Selenium再到各种基于 Selenium 封装的框架几乎都摸了一遍。每次新项目启动选型都是一个让人头疼的问题。直到几年前在一个老牌金融项目里被一个基于 Java 的古老 Web 应用折磨得够呛才真正开始正视 Sahi 这个工具。当时那个应用用了大量的自定义组件和复杂的动态 ID用 Selenium 写脚本光是处理元素定位和等待就耗掉了大半精力维护成本高得吓人。团队里一个老伙计扔过来一句“试试 Sahi 吧它看网页的方式跟咱们不一样。” 这一试就打开了一扇新大门。简单来说Sahi 是一个开源的 Web 自动化测试工具。但它的核心魅力不在于它又是一个“录制回放”的工具而在于它解决 Web 自动化测试痛点的独特思路。我们常说的自动化测试尤其是 UI 层的最怕的就是“脆弱”——页面改个 ID、加个 div、异步加载慢个半秒脚本就可能跑不过去。Sahi 设计之初就冲着“健壮性”和“可维护性”来的。它不依赖于那些容易变化的元素属性比如 id、name、甚至是 XPath而是提供了一套基于页面内容、角色和关系的定位策略。你可以把它想象成一个更“聪明”的测试员它不是靠死记硬背按钮的“身份证号”ID来点击而是靠识别按钮上的文字、它在表单中的位置、或者它旁边是什么标签来找到它。这种思路对于现代前后端分离、大量使用 JavaScript 框架如 React, Vue, Angular生成动态内容的 Web 应用来说简直是福音。那么Sahi 适合谁呢如果你是测试工程师正在为那些元素属性变幻莫测、页面结构复杂的 Web 应用寻找稳定的自动化解决方案Sahi 值得你深入研究。如果你是一名开发想为自己的项目快速搭建一套可回归的端到端测试Sahi 相对较低的学习曲线和强大的内置函数也能让你事半功倍。当然它也不是银弹。对于追求极致执行速度、需要与 CI/CD 深度集成、或者测试移动端/H5 的场景你可能需要结合其他工具。但就纯粹的、复杂的 Web 应用 UI 自动化而言Sahi 提供了一种截然不同且异常坚固的解题思路。2. 核心设计思路Sahi 如何重新定义“元素定位”2.1 从“属性定位”到“智能识别”的范式转变传统自动化工具包括 Selenium其核心是“基于属性的定位”。你需要告诉工具“去找到那个idsubmitBtn的按钮”或者“找到第二个classlist-item的 div”。这种方式直接、高效但致命弱点是耦合度太高。一旦前端开发重构页面修改了 ID 或 class或者仅仅是调整了样式导致 DOM 结构变化你的定位语句就失效了。维护脚本成了与前端开发斗智斗勇的拉锯战。Sahi 引入了一种更接近人工测试的“智能识别”范式。它的脚本语言Sahi Script一种类似 JavaScript 的方言内置了大量识别函数Accessor这些函数允许你使用更稳定的特征来定位元素。例如基于文本内容_link(登录)会找到页面上文本包含“登录”的超链接。按钮文字、标签文本通常比 ID 更稳定。基于邻近关系_textbox(0, _near(_cell(用户名)))可以定位在“用户名”这个单元格附近的第一个文本框。这种定位不关心元素在 DOM 树中的绝对路径只关心它们的相对位置关系抗变动能力极强。基于角色和类型_submit(提交)直接定位提交类型的按钮。_password(0)定位第一个密码框。这种方式的优势显而易见提升了脚本的健壮性。前端可以随意修改底层 HTML 结构和属性只要按钮上的文字还是“提交”只要密码框还在用户名框下面Sahi 脚本就能正常工作。这极大地降低了因前端微调而导致的脚本维护成本。2.2 内置的“等待”与“重试”机制告别显式等待的烦恼另一个让 Sahi 在复杂 Web 应用中表现出色的特性是其内置的智能等待和重试机制。在 Selenium 中处理 Ajax 加载、动态渲染的元素时我们必须显式地编写等待逻辑WebDriverWait并指定等待条件和超时时间。这不仅增加了代码量也对测试人员编写健壮代码的能力提出了更高要求。Sahi 将这部分复杂性封装了起来。当 Sahi 控制器执行一条如_click(_button(保存))的指令时它会自动尝试寻找这个按钮。如果没立即找到它不会立刻报错而是会等待一小段时间可配置并在此期间持续重试查找。只有在多次重试超时后才会抛出“元素未找到”的错误。这相当于为每一条操作指令都默认加了一个“智能隐式等待”。对于绝大多数异步操作场景你根本不需要写额外的等待代码脚本的流畅度和成功率自然就上去了。当然这种“全自动”并非万能。对于某些特定的、耗时长且不稳定的操作如上传大文件后的处理你可能还是需要用到_wait函数进行显式等待。但 Sahi 的_wait同样强大它可以等待某个元素出现、消失、包含特定文本或者等待一个自定义的 JavaScript 条件为真。这种设计哲学是让常见场景变得极其简单同时为复杂场景保留足够的控制力。2.3 脚本录制与生成快速入门的利器Sahi 提供了一个强大的录制器Sahi Controller。你启动它打开浏览器像正常用户一样操作页面Sahi 会实时地将你的操作翻译成 Sahi Script 代码。这对于初学者快速生成脚本骨架、或者对于快速覆盖一个简单流程来说效率非常高。但这里我必须分享一个重要的实操心得录制生成的脚本绝不能直接用于生产环境。录制的脚本往往包含大量绝对路径的 XPath 或依赖于临时生成的 ID健壮性很差。它的正确使用方式是作为“脚手架”或“学习样本”。你应该录制一个基本流程然后基于生成的代码手动将其重构用上文提到的智能识别函数如_link、_near等替换掉那些脆弱的定位语句并添加必要的逻辑判断、数据驱动等。把录制当作写脚本的起点而不是终点。3. 环境搭建与核心配置详解3.1 部署模式选择Standalone 还是 ProxySahi 支持两种主要的部署运行模式理解它们的区别对后续脚本开发和执行至关重要。Standalone 模式独立模式这是最简单快速的入门方式。你从官网下载 Sahi 的压缩包解压后运行start_dashboard.batWindows或./sahi.shLinux/Mac。它会启动一个本地服务器默认端口 9999和一个 Web 控制台。你的测试脚本.sah 或 .js 文件通过这个控制台提交执行。这种模式适合本地学习、调试和运行小规模测试。Proxy 模式代理模式这是 Sahi 的核心和推荐的生产运行模式。你需要将浏览器的代理服务器设置为 Sahi 代理默认localhost:9999。所有浏览器与 Web 服务器之间的 HTTP/HTTPS 流量都会经过 Sahi 代理。Sahi 正是在这个层级注入自己的 JavaScript 引擎从而获得对页面的完全控制能力实现智能识别和自动化操作。优势功能最完整支持 HTTPS 录制、修改请求/响应、模拟网络延迟等高级特性。配置注意需要为浏览器安装 Sahi 的根证书以便代理可以解密和重新加密 HTTPS 流量。这是一个关键步骤如果证书安装不正确HTTPS 网站将无法访问。提示对于新手强烈建议从 Standalone 模式开始熟悉基本操作。当需要录制 HTTPS 网站或进行更复杂的测试时再切换到 Proxy 模式。在 Windows 上Sahi 安装目录下的config文件夹中的sahi.properties文件是核心配置文件可以在这里修改代理端口、浏览器路径、脚本超时时间等。3.2 浏览器配置与驱动管理Sahi 本身内置了对 Firefox 和 Chrome 的良好支持。你只需要在sahi.properties文件中正确设置浏览器可执行文件的路径即可。例如browser_typechrome chrome_browser_pathC:\Program Files\Google\Chrome\Application\chrome.exe对于更现代的 Chrome/Edge 版本可能需要下载对应的 ChromeDriver 或 EdgeDriver并将其路径也配置在属性文件中。Sahi 在底层会利用这些驱动来启动和控制浏览器。一个常见的坑是浏览器版本与驱动版本不匹配。我的经验是尽量使用稍旧一点但稳定的浏览器版本并去官方仓库下载对应版本的驱动。将驱动放在 Sahi 的drivers目录下或者在系统 PATH 环境变量中包含其路径通常能解决大部分启动问题。3.3 第一个脚本从“Hello World”到真实操作环境搭好后我们来写第一个脚本。打开 Sahi Controller 的 Web 界面通常是http://localhost:9999/_s_/spr/conductor.html。创建脚本文件在 Sahi 安装目录的userdata/scripts文件夹下新建一个文本文件命名为demo.sah。编写脚本内容// demo.sah // 打开百度首页 _navigateTo(http://www.baidu.com); // 在搜索框输入“Sahi 自动化测试” _setValue(_textbox(百度一下), Sahi 自动化测试); // 点击“百度一下”按钮 _click(_button(百度一下)); // 等待搜索结果页面加载并检查标题 _wait(3000); // 等待3秒 var title _title(); _assertEqual(title.contains(Sahi 自动化测试), true, 搜索结果页标题验证);运行脚本在 Conductor 页面选择你的浏览器类型在“脚本路径”中输入demo.sah然后点击运行。你会看到浏览器自动打开百度执行搜索并验证。这个简单的例子展示了 Sahi 脚本的基本结构导航、定位元素、操作元素、等待、断言。_textbox(百度一下)这里利用了百度搜索框旁边有“百度一下”这个文本来进行定位这就是智能识别的简单应用。4. Sahi 脚本语言核心语法与最佳实践4.1 元素访问器你的“寻人启事”Sahi 的强大一半体现在它丰富的元素访问器上。以下是一些最常用、最核心的访问器_link(文本)/_button(文本)通过链接或按钮的可见文本来定位。_textbox(邻近文本)/_password(邻近文本)通过输入框附近的标签文本来定位如“用户名”后面的框。_cell(单元格文本)定位表格中的单元格。_div(文本)/_span(文本)通过 DIV 或 SPAN 内的文本来定位。_near(accessor)定位在某个已知元素附近的元素。这是构建健壮定位器的神器。_under(accessor)定位在某个元素下方的元素。_in(accessor)定位在某个容器元素内部的元素。_byId(id)/_byXPath(xpath)传统定位方式Sahi 也支持但建议作为最后手段。最佳实践定位元素的优先级应该是文本/角色定位 邻近关系定位 CSS选择器 XPath。尽量使用与业务逻辑相关且稳定的特征如按钮文字、表单标签避免使用开发视角的临时属性。4.2 控制流与数据驱动Sahi Script 支持完整的 JavaScript 语法因此条件判断、循环、函数定义等都不在话下。// 条件判断 if (_isVisible(_div(成功提示))) { _log(操作成功); } else if (_isVisible(_div(错误提示))) { _log(操作失败); _assertTrue(false, 业务操作失败); } else { _log(状态未知); } // 循环操作 var items _fetchAll(_cell(/产品\d/)); // 获取所有匹配“产品X”的单元格 for (var i0; iitems.length; i) { _click(items[i]); _wait(500); // ... 对每个产品执行操作 } // 函数封装 function login(username, password) { _setValue(_textbox(账号), username); _setValue(_password(密码), password); _click(_button(登录)); _waitFor(_div(欢迎页面), 5000); } login(testUser, 123456);对于数据驱动测试你可以将测试数据存储在外部文件如 CSV、Excel或数据库中在脚本中读取并循环调用业务函数。Sahi 本身不提供复杂的数据驱动框架但这恰恰给了你灵活性可以用你最熟悉的 JavaScript 方式来处理。4.3 断言与日志让测试结果自己说话没有断言的自动化脚本是没有灵魂的。Sahi 提供了多种断言函数_assertTrue(condition, message)条件为真则通过。_assertEqual(actual, expected, message)判断相等。_assertExists(accessor, message)判断元素存在。_assertNotExists(accessor, message)判断元素不存在。断言失败会立即导致当前测试用例失败并在报告和日志中记录相关信息。日志对于调试和报告至关重要。除了断言自带的日志你还可以使用_log(信息)输出普通信息到 Sahi 日志。_debug(调试信息)输出调试信息需开启调试模式。_report(报告信息)输出信息到最终的测试报告摘要中。实操心得在关键的业务检查点、操作步骤前后添加有意义的_log信息。当脚本在 CI/CD 流水线中夜间运行时清晰的日志是第二天早上排查失败用例的唯一线索。避免使用无意义的“Step 1 passed”这样的日志而是记录如“已成功使用订单号[XXX]提交采购申请”这样的业务上下文。5. 高级特性与应用场景挖掘5.1 处理复杂 UI 组件弹窗、iframe 与动态内容现代 Web 应用的复杂性往往体现在各种 UI 组件上。弹窗/对话框Sahi 将其视为普通的页面元素。关键是要在操作前确保它已经加载完成。通常使用_waitFor(_div(弹窗标题), 5000)来等待弹窗出现然后再操作其中的元素。关闭弹窗可能是_click(_button(确定))或_click(_image(close.png))。iframe/框架页这是 Web 自动化的经典难题。Sahi 使用_frame访问器来切入和切出框架。// 切入到名为“contentFrame”的iframe _inFrame(_frame(contentFrame), function() { // 在这个块内的所有操作都在该iframe上下文中执行 _setValue(_textbox(内部输入框), 数据); }); // 操作完成后自动切回主页面上下文切记在_inFrame块内你只能定位该 iframe 内部的元素。动态生成的内容对于 Ajax 加载的列表、表格_waitFor是你的好朋友。等待代表数据加载完成的元素如“加载中”图标消失或第一条数据记录出现后再进行后续操作。Sahi 的智能重试机制在这里也能帮上大忙。5.2 模拟用户交互上传、下载与鼠标键盘事件文件上传Sahi 处理文件上传非常直接。对于input typefile元素使用_setFile访问器。_setFile(_file(), C:\\test_data\\image.jpg);注意文件路径需要是绝对路径且 Sahi 代理所在的机器可能是测试服务器上必须存在该文件。文件下载Sahi 可以监控浏览器的下载行为。你需要预先在sahi.properties中配置下载目录然后使用_download相关函数来等待和验证文件是否下载成功。高级鼠标键盘事件虽然_click和_setValue覆盖了大部分场景但有时需要右键菜单、双击、拖放或组合键。Sahi 提供了_rClick右键点击、_doubleClick双击、_dragDrop拖放等函数。对于复杂的键盘操作可以使用_keyDown、_keyUp和_type来模拟。5.3 集成与扩展命令行运行、CI/CD 与自定义函数命令行运行这是将 Sahi 测试集成到 CI/CD 管道如 Jenkins的关键。Sahi 提供了testrunner脚本。# Windows cd C:\sahi_pro bin\testrunner.bat -suitePath C:\myTests\smoke.suite -browserType chrome -baseURL http://myapp.com你可以通过命令行参数指定测试套件、浏览器、环境URL等非常灵活。测试套件与报告你可以创建.suite文件来组织多个测试脚本按顺序执行。Sahi 会生成 HTML 格式的测试报告包含通过/失败状态、日志和截图如果配置了截图。虽然不如 Allure 或 ExtentReports 华丽但信息足够实用。自定义 JavaScript 函数这是 Sahi 扩展性的体现。你可以将常用的操作或复杂的业务校验封装成自定义函数放在userdata/bin目录下的.js文件中。然后在任何脚本中通过_include指令引入并调用它们。这有助于构建可复用的测试库。6. 实战避坑指南与性能优化6.1 常见问题与排查技巧实录即使 Sahi 很健壮在实际项目中还是会遇到各种问题。下面是一个常见问题速查表问题现象可能原因排查步骤与解决方案脚本回放时找不到元素1. 页面未加载完成。2. 元素定位器写法错误或不稳定。3. 页面存在 iframe未切入正确上下文。4. 动态ID或属性每次刷新都变化。1. 在操作前添加_wait或_waitFor。2. 使用 Sahi Controller 的“元素识别”功能重新捕获元素检查生成的访问器。优先使用文本、_near等智能定位。3. 检查页面结构使用_inFrame切入 iframe。4. 避免使用绝对 XPath 或依赖动态生成的 ID。使用相对定位或基于业务特征的定位。HTTPS 网站无法录制或访问浏览器未正确信任 Sahi 的根证书。1. 确保以 Proxy 模式运行。2. 访问http://sahi.example.com:9999(替换为你的代理地址) 下载并安装根证书到“受信任的根证书颁发机构”。3. 重启浏览器。脚本在 CI 服务器上失败本地却成功1. 环境差异浏览器版本、驱动版本、屏幕分辨率。2. 网络延迟或应用在测试环境性能更差。3. 文件路径问题上传文件不存在。1. 统一 CI 服务器和本地的浏览器及驱动版本。2. 增加关键步骤的等待时间或使用_waitFor替代固定的_wait。3. 确保 CI 服务器上存在脚本中引用的绝对路径文件或改用相对路径需配置 Sahi 工作目录。操作速度过快导致后续步骤失败页面 JavaScript 反应不过来。在关键操作如点击触发 Ajax 的按钮后添加适当的_wait或使用_waitFor等待某个标志性元素出现。报告中没有截图未配置截图或截图保存路径错误。在sahi.properties中设置failure_screenshottrue和screenshot_dir路径。确保 Sahi 进程有该路径的写入权限。独家避坑技巧使用_debug和_pause进行调试在脚本中临时插入_debug(“到达检查点A”)和_pause(5000)然后在 Sahi Controller 的日志面板观察输出并手动检查此时页面状态这是定位时序问题最有效的方法。善用“元素识别”工具不要完全依赖录制。当定位器失效时手动使用 Controller 中的“识别”功能它会尝试给出多种定位建议从中选择一个最健壮的。封装页面对象虽然 Sahi 没有官方 Page Object 模式但你可以用 JavaScript 对象或自定义函数来模拟。将同一个页面的元素定位器和常用操作封装在一起能极大提升脚本的可维护性。设置合理的超时在sahi.properties中调整script.timeout和action.timeout。对于慢速环境适当调大这些值。6.2 脚本性能与稳定性优化减少不必要的等待虽然 Sahi 有智能等待但显式的_wait用多了会拖慢整体执行速度。尽量用_waitFor替代固定的_wait让脚本在条件满足时立即继续。优化定位器性能过于复杂的 XPath 或 CSS 选择器会影响查找速度。智能访问器如_near在大多数情况下性能很好但也要避免在巨型页面中寻找一个特征非常模糊的元素。保持浏览器清洁长期运行的测试套件可能会使浏览器积累缓存和 cookies偶尔导致异常。可以在测试套件开始或结束时加入清理浏览器数据或重启浏览器的步骤。并发执行考虑Sahi 支持通过启动多个 Sahi 代理实例来实现一定程度的并发测试。但这需要仔细规划端口分配、数据隔离和资源竞争问题。对于大规模并发通常建议结合 Selenium Grid 或更专业的云测平台。7. 总结与展望Sahi 在自动化测试生态中的位置用了这么多年 Sahi我个人的体会是它就像一把特制的瑞士军刀不是万能的但在处理复杂、动态、元素定位困难的 Web 应用 UI 自动化时其“智能识别”和“内置等待”的特性让它显得格外顺手和可靠。它降低了编写稳定自动化脚本的门槛尤其适合那些被“脆弱测试”困扰的团队。当然它也有其局限性。社区活跃度相比 Selenium 要小遇到深坑时可能需要自己花更多时间研究源码。其原生的脚本语言和报告系统在需要与现代化开发栈如 Node.js, Allure, Jenkins Pipeline as Code深度集成时可能需要一些额外的胶水代码。技术选型从来都是权衡。如果你的项目是传统的、结构复杂的 Web 应用对测试脚本的健壮性和可维护性要求极高那么 Sahi 绝对是一个被低估的强力候选。你可以从一个小模块开始试点用它来处理那些最令 Selenium 头疼的页面感受一下它“以不变应万变”的定位哲学带来的维护成本下降。或许它会成为你测试武器库中一件不可或缺的利器。
Sahi Web自动化测试：智能识别与健壮定位实战指南
发布时间：2026/6/22 16:15:10
1. 项目概述为什么选择 Sahi 来啃 Web 自动化测试这块硬骨头做 Web 自动化测试有些年头了从最早的 QTP 到后来火遍大江南北的 Selenium再到各种基于 Selenium 封装的框架几乎都摸了一遍。每次新项目启动选型都是一个让人头疼的问题。直到几年前在一个老牌金融项目里被一个基于 Java 的古老 Web 应用折磨得够呛才真正开始正视 Sahi 这个工具。当时那个应用用了大量的自定义组件和复杂的动态 ID用 Selenium 写脚本光是处理元素定位和等待就耗掉了大半精力维护成本高得吓人。团队里一个老伙计扔过来一句“试试 Sahi 吧它看网页的方式跟咱们不一样。” 这一试就打开了一扇新大门。简单来说Sahi 是一个开源的 Web 自动化测试工具。但它的核心魅力不在于它又是一个“录制回放”的工具而在于它解决 Web 自动化测试痛点的独特思路。我们常说的自动化测试尤其是 UI 层的最怕的就是“脆弱”——页面改个 ID、加个 div、异步加载慢个半秒脚本就可能跑不过去。Sahi 设计之初就冲着“健壮性”和“可维护性”来的。它不依赖于那些容易变化的元素属性比如 id、name、甚至是 XPath而是提供了一套基于页面内容、角色和关系的定位策略。你可以把它想象成一个更“聪明”的测试员它不是靠死记硬背按钮的“身份证号”ID来点击而是靠识别按钮上的文字、它在表单中的位置、或者它旁边是什么标签来找到它。这种思路对于现代前后端分离、大量使用 JavaScript 框架如 React, Vue, Angular生成动态内容的 Web 应用来说简直是福音。那么Sahi 适合谁呢如果你是测试工程师正在为那些元素属性变幻莫测、页面结构复杂的 Web 应用寻找稳定的自动化解决方案Sahi 值得你深入研究。如果你是一名开发想为自己的项目快速搭建一套可回归的端到端测试Sahi 相对较低的学习曲线和强大的内置函数也能让你事半功倍。当然它也不是银弹。对于追求极致执行速度、需要与 CI/CD 深度集成、或者测试移动端/H5 的场景你可能需要结合其他工具。但就纯粹的、复杂的 Web 应用 UI 自动化而言Sahi 提供了一种截然不同且异常坚固的解题思路。2. 核心设计思路Sahi 如何重新定义“元素定位”2.1 从“属性定位”到“智能识别”的范式转变传统自动化工具包括 Selenium其核心是“基于属性的定位”。你需要告诉工具“去找到那个idsubmitBtn的按钮”或者“找到第二个classlist-item的 div”。这种方式直接、高效但致命弱点是耦合度太高。一旦前端开发重构页面修改了 ID 或 class或者仅仅是调整了样式导致 DOM 结构变化你的定位语句就失效了。维护脚本成了与前端开发斗智斗勇的拉锯战。Sahi 引入了一种更接近人工测试的“智能识别”范式。它的脚本语言Sahi Script一种类似 JavaScript 的方言内置了大量识别函数Accessor这些函数允许你使用更稳定的特征来定位元素。例如基于文本内容_link(登录)会找到页面上文本包含“登录”的超链接。按钮文字、标签文本通常比 ID 更稳定。基于邻近关系_textbox(0, _near(_cell(用户名)))可以定位在“用户名”这个单元格附近的第一个文本框。这种定位不关心元素在 DOM 树中的绝对路径只关心它们的相对位置关系抗变动能力极强。基于角色和类型_submit(提交)直接定位提交类型的按钮。_password(0)定位第一个密码框。这种方式的优势显而易见提升了脚本的健壮性。前端可以随意修改底层 HTML 结构和属性只要按钮上的文字还是“提交”只要密码框还在用户名框下面Sahi 脚本就能正常工作。这极大地降低了因前端微调而导致的脚本维护成本。2.2 内置的“等待”与“重试”机制告别显式等待的烦恼另一个让 Sahi 在复杂 Web 应用中表现出色的特性是其内置的智能等待和重试机制。在 Selenium 中处理 Ajax 加载、动态渲染的元素时我们必须显式地编写等待逻辑WebDriverWait并指定等待条件和超时时间。这不仅增加了代码量也对测试人员编写健壮代码的能力提出了更高要求。Sahi 将这部分复杂性封装了起来。当 Sahi 控制器执行一条如_click(_button(保存))的指令时它会自动尝试寻找这个按钮。如果没立即找到它不会立刻报错而是会等待一小段时间可配置并在此期间持续重试查找。只有在多次重试超时后才会抛出“元素未找到”的错误。这相当于为每一条操作指令都默认加了一个“智能隐式等待”。对于绝大多数异步操作场景你根本不需要写额外的等待代码脚本的流畅度和成功率自然就上去了。当然这种“全自动”并非万能。对于某些特定的、耗时长且不稳定的操作如上传大文件后的处理你可能还是需要用到_wait函数进行显式等待。但 Sahi 的_wait同样强大它可以等待某个元素出现、消失、包含特定文本或者等待一个自定义的 JavaScript 条件为真。这种设计哲学是让常见场景变得极其简单同时为复杂场景保留足够的控制力。2.3 脚本录制与生成快速入门的利器Sahi 提供了一个强大的录制器Sahi Controller。你启动它打开浏览器像正常用户一样操作页面Sahi 会实时地将你的操作翻译成 Sahi Script 代码。这对于初学者快速生成脚本骨架、或者对于快速覆盖一个简单流程来说效率非常高。但这里我必须分享一个重要的实操心得录制生成的脚本绝不能直接用于生产环境。录制的脚本往往包含大量绝对路径的 XPath 或依赖于临时生成的 ID健壮性很差。它的正确使用方式是作为“脚手架”或“学习样本”。你应该录制一个基本流程然后基于生成的代码手动将其重构用上文提到的智能识别函数如_link、_near等替换掉那些脆弱的定位语句并添加必要的逻辑判断、数据驱动等。把录制当作写脚本的起点而不是终点。3. 环境搭建与核心配置详解3.1 部署模式选择Standalone 还是 ProxySahi 支持两种主要的部署运行模式理解它们的区别对后续脚本开发和执行至关重要。Standalone 模式独立模式这是最简单快速的入门方式。你从官网下载 Sahi 的压缩包解压后运行start_dashboard.batWindows或./sahi.shLinux/Mac。它会启动一个本地服务器默认端口 9999和一个 Web 控制台。你的测试脚本.sah 或 .js 文件通过这个控制台提交执行。这种模式适合本地学习、调试和运行小规模测试。Proxy 模式代理模式这是 Sahi 的核心和推荐的生产运行模式。你需要将浏览器的代理服务器设置为 Sahi 代理默认localhost:9999。所有浏览器与 Web 服务器之间的 HTTP/HTTPS 流量都会经过 Sahi 代理。Sahi 正是在这个层级注入自己的 JavaScript 引擎从而获得对页面的完全控制能力实现智能识别和自动化操作。优势功能最完整支持 HTTPS 录制、修改请求/响应、模拟网络延迟等高级特性。配置注意需要为浏览器安装 Sahi 的根证书以便代理可以解密和重新加密 HTTPS 流量。这是一个关键步骤如果证书安装不正确HTTPS 网站将无法访问。提示对于新手强烈建议从 Standalone 模式开始熟悉基本操作。当需要录制 HTTPS 网站或进行更复杂的测试时再切换到 Proxy 模式。在 Windows 上Sahi 安装目录下的config文件夹中的sahi.properties文件是核心配置文件可以在这里修改代理端口、浏览器路径、脚本超时时间等。3.2 浏览器配置与驱动管理Sahi 本身内置了对 Firefox 和 Chrome 的良好支持。你只需要在sahi.properties文件中正确设置浏览器可执行文件的路径即可。例如browser_typechrome chrome_browser_pathC:\Program Files\Google\Chrome\Application\chrome.exe对于更现代的 Chrome/Edge 版本可能需要下载对应的 ChromeDriver 或 EdgeDriver并将其路径也配置在属性文件中。Sahi 在底层会利用这些驱动来启动和控制浏览器。一个常见的坑是浏览器版本与驱动版本不匹配。我的经验是尽量使用稍旧一点但稳定的浏览器版本并去官方仓库下载对应版本的驱动。将驱动放在 Sahi 的drivers目录下或者在系统 PATH 环境变量中包含其路径通常能解决大部分启动问题。3.3 第一个脚本从“Hello World”到真实操作环境搭好后我们来写第一个脚本。打开 Sahi Controller 的 Web 界面通常是http://localhost:9999/_s_/spr/conductor.html。创建脚本文件在 Sahi 安装目录的userdata/scripts文件夹下新建一个文本文件命名为demo.sah。编写脚本内容// demo.sah // 打开百度首页 _navigateTo(http://www.baidu.com); // 在搜索框输入“Sahi 自动化测试” _setValue(_textbox(百度一下), Sahi 自动化测试); // 点击“百度一下”按钮 _click(_button(百度一下)); // 等待搜索结果页面加载并检查标题 _wait(3000); // 等待3秒 var title _title(); _assertEqual(title.contains(Sahi 自动化测试), true, 搜索结果页标题验证);运行脚本在 Conductor 页面选择你的浏览器类型在“脚本路径”中输入demo.sah然后点击运行。你会看到浏览器自动打开百度执行搜索并验证。这个简单的例子展示了 Sahi 脚本的基本结构导航、定位元素、操作元素、等待、断言。_textbox(百度一下)这里利用了百度搜索框旁边有“百度一下”这个文本来进行定位这就是智能识别的简单应用。4. Sahi 脚本语言核心语法与最佳实践4.1 元素访问器你的“寻人启事”Sahi 的强大一半体现在它丰富的元素访问器上。以下是一些最常用、最核心的访问器_link(文本)/_button(文本)通过链接或按钮的可见文本来定位。_textbox(邻近文本)/_password(邻近文本)通过输入框附近的标签文本来定位如“用户名”后面的框。_cell(单元格文本)定位表格中的单元格。_div(文本)/_span(文本)通过 DIV 或 SPAN 内的文本来定位。_near(accessor)定位在某个已知元素附近的元素。这是构建健壮定位器的神器。_under(accessor)定位在某个元素下方的元素。_in(accessor)定位在某个容器元素内部的元素。_byId(id)/_byXPath(xpath)传统定位方式Sahi 也支持但建议作为最后手段。最佳实践定位元素的优先级应该是文本/角色定位 邻近关系定位 CSS选择器 XPath。尽量使用与业务逻辑相关且稳定的特征如按钮文字、表单标签避免使用开发视角的临时属性。4.2 控制流与数据驱动Sahi Script 支持完整的 JavaScript 语法因此条件判断、循环、函数定义等都不在话下。// 条件判断 if (_isVisible(_div(成功提示))) { _log(操作成功); } else if (_isVisible(_div(错误提示))) { _log(操作失败); _assertTrue(false, 业务操作失败); } else { _log(状态未知); } // 循环操作 var items _fetchAll(_cell(/产品\d/)); // 获取所有匹配“产品X”的单元格 for (var i0; iitems.length; i) { _click(items[i]); _wait(500); // ... 对每个产品执行操作 } // 函数封装 function login(username, password) { _setValue(_textbox(账号), username); _setValue(_password(密码), password); _click(_button(登录)); _waitFor(_div(欢迎页面), 5000); } login(testUser, 123456);对于数据驱动测试你可以将测试数据存储在外部文件如 CSV、Excel或数据库中在脚本中读取并循环调用业务函数。Sahi 本身不提供复杂的数据驱动框架但这恰恰给了你灵活性可以用你最熟悉的 JavaScript 方式来处理。4.3 断言与日志让测试结果自己说话没有断言的自动化脚本是没有灵魂的。Sahi 提供了多种断言函数_assertTrue(condition, message)条件为真则通过。_assertEqual(actual, expected, message)判断相等。_assertExists(accessor, message)判断元素存在。_assertNotExists(accessor, message)判断元素不存在。断言失败会立即导致当前测试用例失败并在报告和日志中记录相关信息。日志对于调试和报告至关重要。除了断言自带的日志你还可以使用_log(信息)输出普通信息到 Sahi 日志。_debug(调试信息)输出调试信息需开启调试模式。_report(报告信息)输出信息到最终的测试报告摘要中。实操心得在关键的业务检查点、操作步骤前后添加有意义的_log信息。当脚本在 CI/CD 流水线中夜间运行时清晰的日志是第二天早上排查失败用例的唯一线索。避免使用无意义的“Step 1 passed”这样的日志而是记录如“已成功使用订单号[XXX]提交采购申请”这样的业务上下文。5. 高级特性与应用场景挖掘5.1 处理复杂 UI 组件弹窗、iframe 与动态内容现代 Web 应用的复杂性往往体现在各种 UI 组件上。弹窗/对话框Sahi 将其视为普通的页面元素。关键是要在操作前确保它已经加载完成。通常使用_waitFor(_div(弹窗标题), 5000)来等待弹窗出现然后再操作其中的元素。关闭弹窗可能是_click(_button(确定))或_click(_image(close.png))。iframe/框架页这是 Web 自动化的经典难题。Sahi 使用_frame访问器来切入和切出框架。// 切入到名为“contentFrame”的iframe _inFrame(_frame(contentFrame), function() { // 在这个块内的所有操作都在该iframe上下文中执行 _setValue(_textbox(内部输入框), 数据); }); // 操作完成后自动切回主页面上下文切记在_inFrame块内你只能定位该 iframe 内部的元素。动态生成的内容对于 Ajax 加载的列表、表格_waitFor是你的好朋友。等待代表数据加载完成的元素如“加载中”图标消失或第一条数据记录出现后再进行后续操作。Sahi 的智能重试机制在这里也能帮上大忙。5.2 模拟用户交互上传、下载与鼠标键盘事件文件上传Sahi 处理文件上传非常直接。对于input typefile元素使用_setFile访问器。_setFile(_file(), C:\\test_data\\image.jpg);注意文件路径需要是绝对路径且 Sahi 代理所在的机器可能是测试服务器上必须存在该文件。文件下载Sahi 可以监控浏览器的下载行为。你需要预先在sahi.properties中配置下载目录然后使用_download相关函数来等待和验证文件是否下载成功。高级鼠标键盘事件虽然_click和_setValue覆盖了大部分场景但有时需要右键菜单、双击、拖放或组合键。Sahi 提供了_rClick右键点击、_doubleClick双击、_dragDrop拖放等函数。对于复杂的键盘操作可以使用_keyDown、_keyUp和_type来模拟。5.3 集成与扩展命令行运行、CI/CD 与自定义函数命令行运行这是将 Sahi 测试集成到 CI/CD 管道如 Jenkins的关键。Sahi 提供了testrunner脚本。# Windows cd C:\sahi_pro bin\testrunner.bat -suitePath C:\myTests\smoke.suite -browserType chrome -baseURL http://myapp.com你可以通过命令行参数指定测试套件、浏览器、环境URL等非常灵活。测试套件与报告你可以创建.suite文件来组织多个测试脚本按顺序执行。Sahi 会生成 HTML 格式的测试报告包含通过/失败状态、日志和截图如果配置了截图。虽然不如 Allure 或 ExtentReports 华丽但信息足够实用。自定义 JavaScript 函数这是 Sahi 扩展性的体现。你可以将常用的操作或复杂的业务校验封装成自定义函数放在userdata/bin目录下的.js文件中。然后在任何脚本中通过_include指令引入并调用它们。这有助于构建可复用的测试库。6. 实战避坑指南与性能优化6.1 常见问题与排查技巧实录即使 Sahi 很健壮在实际项目中还是会遇到各种问题。下面是一个常见问题速查表问题现象可能原因排查步骤与解决方案脚本回放时找不到元素1. 页面未加载完成。2. 元素定位器写法错误或不稳定。3. 页面存在 iframe未切入正确上下文。4. 动态ID或属性每次刷新都变化。1. 在操作前添加_wait或_waitFor。2. 使用 Sahi Controller 的“元素识别”功能重新捕获元素检查生成的访问器。优先使用文本、_near等智能定位。3. 检查页面结构使用_inFrame切入 iframe。4. 避免使用绝对 XPath 或依赖动态生成的 ID。使用相对定位或基于业务特征的定位。HTTPS 网站无法录制或访问浏览器未正确信任 Sahi 的根证书。1. 确保以 Proxy 模式运行。2. 访问http://sahi.example.com:9999(替换为你的代理地址) 下载并安装根证书到“受信任的根证书颁发机构”。3. 重启浏览器。脚本在 CI 服务器上失败本地却成功1. 环境差异浏览器版本、驱动版本、屏幕分辨率。2. 网络延迟或应用在测试环境性能更差。3. 文件路径问题上传文件不存在。1. 统一 CI 服务器和本地的浏览器及驱动版本。2. 增加关键步骤的等待时间或使用_waitFor替代固定的_wait。3. 确保 CI 服务器上存在脚本中引用的绝对路径文件或改用相对路径需配置 Sahi 工作目录。操作速度过快导致后续步骤失败页面 JavaScript 反应不过来。在关键操作如点击触发 Ajax 的按钮后添加适当的_wait或使用_waitFor等待某个标志性元素出现。报告中没有截图未配置截图或截图保存路径错误。在sahi.properties中设置failure_screenshottrue和screenshot_dir路径。确保 Sahi 进程有该路径的写入权限。独家避坑技巧使用_debug和_pause进行调试在脚本中临时插入_debug(“到达检查点A”)和_pause(5000)然后在 Sahi Controller 的日志面板观察输出并手动检查此时页面状态这是定位时序问题最有效的方法。善用“元素识别”工具不要完全依赖录制。当定位器失效时手动使用 Controller 中的“识别”功能它会尝试给出多种定位建议从中选择一个最健壮的。封装页面对象虽然 Sahi 没有官方 Page Object 模式但你可以用 JavaScript 对象或自定义函数来模拟。将同一个页面的元素定位器和常用操作封装在一起能极大提升脚本的可维护性。设置合理的超时在sahi.properties中调整script.timeout和action.timeout。对于慢速环境适当调大这些值。6.2 脚本性能与稳定性优化减少不必要的等待虽然 Sahi 有智能等待但显式的_wait用多了会拖慢整体执行速度。尽量用_waitFor替代固定的_wait让脚本在条件满足时立即继续。优化定位器性能过于复杂的 XPath 或 CSS 选择器会影响查找速度。智能访问器如_near在大多数情况下性能很好但也要避免在巨型页面中寻找一个特征非常模糊的元素。保持浏览器清洁长期运行的测试套件可能会使浏览器积累缓存和 cookies偶尔导致异常。可以在测试套件开始或结束时加入清理浏览器数据或重启浏览器的步骤。并发执行考虑Sahi 支持通过启动多个 Sahi 代理实例来实现一定程度的并发测试。但这需要仔细规划端口分配、数据隔离和资源竞争问题。对于大规模并发通常建议结合 Selenium Grid 或更专业的云测平台。7. 总结与展望Sahi 在自动化测试生态中的位置用了这么多年 Sahi我个人的体会是它就像一把特制的瑞士军刀不是万能的但在处理复杂、动态、元素定位困难的 Web 应用 UI 自动化时其“智能识别”和“内置等待”的特性让它显得格外顺手和可靠。它降低了编写稳定自动化脚本的门槛尤其适合那些被“脆弱测试”困扰的团队。当然它也有其局限性。社区活跃度相比 Selenium 要小遇到深坑时可能需要自己花更多时间研究源码。其原生的脚本语言和报告系统在需要与现代化开发栈如 Node.js, Allure, Jenkins Pipeline as Code深度集成时可能需要一些额外的胶水代码。技术选型从来都是权衡。如果你的项目是传统的、结构复杂的 Web 应用对测试脚本的健壮性和可维护性要求极高那么 Sahi 绝对是一个被低估的强力候选。你可以从一个小模块开始试点用它来处理那些最令 Selenium 头疼的页面感受一下它“以不变应万变”的定位哲学带来的维护成本下降。或许它会成为你测试武器库中一件不可或缺的利器。
