1. 项目概述当AI测试不再需要写脚本如果你是一名测试工程师或者正在管理一个测试团队那么“写脚本”这三个字大概率是你日常工作中最耗时、最繁琐也最容易出错的环节。从理解需求、设计用例到用Selenium、Appium或者各种API测试框架一行行敲出代码再到维护因UI变动、接口调整而“一碰就碎”的脚本这个过程消耗了测试人员大量的创造力。我们更像是在做翻译工作——把自然语言的需求翻译成机器能理解的指令代码。那么有没有可能让机器自己来完成这个“翻译”呢这就是SITS 2026正在尝试回答的问题。SITS 2026这个听起来像未来科技代号的名字实际上是一个正在内测阶段的下一代AI测试框架。它的核心目标直指“零代码自动化测试”但它的实现路径并非简单地提供一个图形化拖拽界面而是试图从根本上改变测试脚本的生成方式通过语义理解与行为建模让AI直接理解“要测什么”和“怎么测”并自动生成可执行、可维护的测试逻辑。简单来说你不再需要告诉它“点击ID为‘submit’的按钮”而是告诉它“用户登录后在商品列表页选择第一个商品加入购物车然后去结算”。框架会自己理解“登录”、“商品列表页”、“加入购物车”、“结算”这些业务概念并找到正确的界面元素和操作路径。这背后的驱动力与近期行业热议的“AI测试”、“AI自动化测试”趋势完全吻合。无论是Testim这类利用AI记录并稳定测试脚本的工具还是业界对“AI测试工程师”这一新兴岗位技能如需要了解Prompt工程、大模型原理的探讨都指向同一个方向测试工作的智能化升级。SITS 2026可以看作是这一趋势下一个更为激进和彻底的实践。它不满足于用AI辅助录制回放或修复脚本而是希望构建一个以“语义”和“行为”为基石的自动化新范式。接下来我将结合内测体验为你深度拆解这套框架是如何工作的以及它可能如何改变我们的测试工作流。2. 核心设计思路从“指令编程”到“意图驱动”传统的自动化测试无论是基于代码还是基于录制本质上都属于“指令编程”模式。测试工程师需要精确地告诉自动化工具在哪个位置XPath、CSS Selector、执行什么操作click、send_keys、然后验证什么结果assert text equals。这种方式高度依赖前端实现的稳定性一个ID的改动就可能导致大批脚本失效。SITS 2026的设计思路完全不同它转向了“意图驱动”模式。其核心架构建立在两大支柱上语义理解引擎和行为建模层。整个框架的工作流可以理解为让AI扮演一个“超级测试新手”——这个新手不懂代码但精通业务并且学习能力极强。2.1 语义理解引擎让AI读懂需求与界面这是框架的“大脑”。它的任务是将自然语言描述的需求或测试用例以及应用程序的图形用户界面GUI转化为机器可处理的结构化语义信息。2.1.1 需求语义的向量化与解析当你输入一段测试场景描述如“验证普通用户成功登录后页面跳转到个人中心并显示欢迎语‘你好[用户名]’”。语义理解引擎会做以下几件事实体识别提取关键业务实体如“普通用户”角色、“登录”动作、“个人中心”页面/状态、“欢迎语”验证点。意图分类判断该描述的核心意图是“功能验证”还是“流程验证”并关联到具体的业务模块如“用户认证模块”。条件与结果解构拆解出前置条件“普通用户”、操作序列“成功登录”、预期结果“跳转到个人中心”并“显示特定欢迎语”。向量化表示将上述结构化信息转换为高维向量存入测试知识图谱。这一步至关重要它为后续的相似用例推荐、变更影响分析奠定了基础。实操心得在初期编写测试场景描述时尽量使用完整、通顺的句子明确主语谁、动作做什么、客体对什么做和预期结果。避免使用过于简略的指令式语言如“登录检查跳转”这有助于AI更准确地理解你的意图。框架通常会提供一个“语义澄清”界面当它不确定时会反问你比如“您说的‘个人中心’在应用中通常被称为‘我的主页’或‘用户面板’请问是哪一个”。2.1.2 界面元素的语义化绑定这是实现“零代码”操作的关键。传统自动化靠定位器Locator找元素而SITS 2026让AI“看”界面并理解元素的含义。多模态感知框架会通过集成计算机视觉CV和可访问性Accessibility树获取当前界面的截图和UI层次结构。元素语义标注AI模型会分析一个按钮不仅识别出它的文本是“提交”还会结合其位置通常在表单底部、常见模式如颜色为蓝色推断出它的语义角色是“表单提交按钮”。对于一个输入框它会关联其旁边的标签如“用户名”或占位符文本理解这是“用户名输入框”。生成语义定位器框架不再存储脆弱的XPath而是生成如{role: ‘submit_button’, associated_form: ‘login’, visible_text: ‘提交’}这样的语义描述符。即使前端的ID或类名变了只要这个按钮的视觉特征和功能语义没变AI依然能找到它。2.2 行为建模层将意图转化为可执行动作链这是框架的“小脑”和“肢体”。它接收来自语义理解引擎的“意图指令”并将其分解、规划成一系列具体的、可在真实应用上执行的低级操作。2.2.1 构建领域行为模型SITS 2026鼓励或者说要求测试团队先为被测应用定义“领域行为模型”。这听起来高大上其实可以理解为创建一个业务操作的“原子动作”库和“复合动作”模板。原子动作不可再分的基本操作如click(语义元素)、input_text(语义元素, 文本)、assert_element_present(语义元素)、assert_text_contains(语义元素, 期望文本)。复合动作/业务流程由原子动作组合而成的常用业务流。例如“登录”这个复合动作可以模板化为1. 导航至“登录页”如果不在。 2. 在“用户名输入框”输入 {username}。 3. 在“密码输入框”输入 {password}。 4. 点击“登录按钮”。 5. 验证是否跳转至“登录后首页”。这个模板中的{username}和{password}是参数。2.2.2 意图到行为的映射与规划当收到“验证普通用户成功登录”的意图后行为建模层会进行如下推理模板匹配在行为模型库中查找匹配的复合动作模板。这里会匹配到“登录”模板。参数填充从测试数据池中为“普通用户”角色获取一组有效的用户名和密码填充到模板参数中。动作序列生成输出一个具体的、参数化的动作序列计划。环境适配与执行执行引擎根据当前应用的实际状态是桌面Web、移动端H5还是原生App将每个原子动作适配为对应平台的可执行指令如WebDriver命令、移动端触控命令并驱动被测应用执行。注意事项行为建模的初期投入是关键。定义准确、完整的原子动作和复合动作模板相当于为AI编写了一本“业务操作词典”。这本词典的质量直接决定了自动化脚本的健壮性和可读性。建议从核心业务流程开始建模并让业务专家参与评审确保模型中的术语和流程与业务实际保持一致。3. 实操流程三步构建零代码自动化测试了解了核心思路后我们来看如何实际使用SITS 2026。整个流程可以概括为“建模 - 描述 - 执行与维护”三个核心阶段。3.1 第一阶段应用建模与行为定义这是最重要的准备阶段目的是让框架“认识”你的应用。3.1.1 应用接入与初始探索首先你需要将待测应用Web URL、Android APK/iOS IPA或已安装的应用接入SITS 2026平台。框架会启动一个“探索模式”自动遍历应用的主要界面。在这个过程中AI会持续进行我们前面提到的界面语义化分析初步构建一个应用的“UI语义地图”。3.1.2 定义领域模型与行为原子接下来你需要在这个初步地图的基础上进行人工校准和丰富。校准语义元素检查AI识别的元素语义是否正确。你可以手动修正或添加更准确的语义标签。例如AI可能将一个图标按钮识别为“未知按钮”你可以将其标注为“搜索按钮”。定义业务领域创建或确认业务领域如“电商”、“用户管理”、“支付”等。将相关的页面和元素归类到对应领域。封装复合行为在IDE中使用框架提供的DSL领域特定语言或可视化编辑器将常用的操作序列封装成可复用的“行为”。例如定义一个名为login(username, password)的行为其内部就是上述的登录动作序列。这些封装好的行为会成为你后续编写测试场景的“高级词汇”。3.2 第二阶段自然语言编写测试场景当行为模型建立好后编写测试用例就变得非常直观。3.2.1 场景描述在测试场景编辑器中你直接用自然语言描述测试步骤。例如场景验证已登录用户将商品加入购物车 前置条件用户“test_user”已登录 步骤 1. 浏览商品列表页。 2. 选择第一个商品查看其详情。 3. 在详情页点击“加入购物车”按钮。 4. 导航到购物车页面。 5. 验证购物车中有一件商品且商品名称与刚才查看的一致。 预期结果商品成功加入购物车信息显示正确。你不需要关心“商品列表页”的URL是什么“加入购物车”按钮的ID是什么。框架会根据你之前定义的领域模型和行为自动理解这些术语。3.2.2 语义澄清与确认在你编写过程中或保存时框架的语义理解引擎会实时分析。如果发现歧义比如应用中有多个地方可被称为“购物车页面”它会弹出对话框让你确认。如果发现某个步骤如“选择第一个商品”没有对应的预定义行为它会提示你是否需要现在创建一个或者尝试基于现有原子动作自动合成一个临时行为。3.2.3 测试数据绑定你可以在场景中直接使用具体数据如test_user也可以使用参数化标记从外部的CSV文件、数据库或随机数据生成器中动态获取数据。框架支持将数据与角色、场景进行关联管理。3.3 第三阶段智能执行、自愈与结果分析3.3.1 执行与自适应点击运行后框架的行为执行引擎会接管一切。它会将场景描述解析为具体的行为执行计划。按计划执行每一步操作。在每一步执行前后进行智能等待和状态验证确保应用处于预期状态。最关键的是自愈能力如果某个元素因为UI微调而找不到引擎不会立即报错失败。它会启动“元素重定位”策略首先尝试用更新的语义信息重新查找其次利用CV模型在相近区域进行图像匹配最后如果是一个流程中的步骤它可能会尝试替代路径比如通过点击菜单进入某个页面而不是直接跳转。如果自愈成功它会自动学习这个新的定位方式并更新语义地图。3.3.2 结果报告与根因分析测试完成后报告不仅会显示通过/失败更重要的是提供“语义化”的分析。失败分析如果失败报告不会只显示“元素未找到”或“断言失败”。它会结合行为模型告诉你“在执行‘加入购物车’行为时未能找到语义为‘加入购物车按钮’的元素。可能的原因为1. 页面未正确跳转到商品详情页2. 按钮的视觉样式已更改。” 这极大地简化了排查过程。可视化追溯整个执行过程会被录屏并与每一步的语义描述、执行动作、应用状态快照关联起来。你可以像看带字幕的电影一样回放测试过程。4. 核心技术实现深度解析SITS 2026并非魔法其背后是多项前沿技术的工程化整合。理解这些有助于我们更好地使用和信任它。4.1 多模态融合的UI理解技术这是语义理解引擎的基石。框架通常采用一个融合模型来处理UI视觉特征编码使用卷积神经网络CNN或视觉TransformerViT对屏幕截图进行编码提取视觉特征。结构特征编码将UI的可访问性树包含组件类型、层级、文本等通过图神经网络GNN或Transformer进行编码提取结构特征。多模态对齐与融合通过一个对齐网络将同一UI元素的视觉特征和结构特征进行融合形成一个统一的、富含语义的向量表示。这个向量能够同时表达元素“看起来像什么”视觉和“在结构里是什么”语义。语义标签预测基于融合后的向量通过一个分类器预测该元素的语义角色如按钮、输入框、标题和业务含义如登录按钮、搜索框。4.2 基于大语言模型的意图解析与规划行为建模层重度依赖大语言模型LLM的能力。指令微调Instruction Tuning框架会用大量“测试场景描述 - 行为序列”的配对数据对基础LLM如Code Llama、GPT系列进行微调使其专门擅长将测试需求翻译成内部的行为规划语言。上下文学习In-Context Learning在实际解析时系统会将当前应用的领域模型、已定义的行为库作为“上下文”提供给LLM。相当于告诉LLM“这是我们的业务词典请用这里的词汇来翻译新的需求。”这保证了生成的计划与现有模型的一致性。规划与验证循环LLM生成初步行为计划后不会直接执行。框架会用一个“验证器”模块可能是一套规则或一个小型判别模型来检查计划的合理性和可行性比如检查步骤间的前后依赖、参数是否齐全等。如果发现问题会将错误反馈给LLM进行修正形成闭环。4.3 强化学习驱动的自愈与探索执行引擎的“智能”很大程度上来自于强化学习RL。状态与动作空间定义将应用界面定义为“状态”将可能的操作点击某个语义元素、输入文本、滑动等定义为“动作”。奖励函数设计设计巧妙的奖励函数。例如成功执行一个计划中的动作获得正奖励到达一个预期的页面状态如购物车页获得大额正奖励执行无关操作或长时间未达到目标获得负奖励。策略学习当遇到元素定位失败等异常时执行引擎就切换为RL代理。它基于当前屏幕状态像素和语义信息尝试各种备选动作如点击其他相似元素、返回上一步、从菜单导航以最大化奖励即最终完成测试场景。成功的恢复路径会被记录下来用于优化未来的策略并可能反哺到语义地图的更新中。5. 内测体验优势、挑战与适用场景经过一段时间的实际试用我对SITS 2026这类框架的优势和当前面临的挑战有了更深的体会。5.1 带来的核心价值大幅降低自动化门槛业务分析师、产品经理甚至新手测试员只要懂业务就能参与创建自动化测试场景。测试用例变成了人人可读的自然语言文档。提升脚本健壮性基于语义和行为的脚本对UI的前端代码改动如CSS类名、DOM结构微调容忍度极高。只要功能语义和视觉布局没有颠覆性变化脚本就能自适应。维护成本显著下降当业务流程变更时如登录增加验证码通常只需要更新对应的那个“复合行为”模板如在登录模板中增加“输入验证码”步骤所有引用该行为的测试场景会自动继承变更无需逐个修改。促进团队协作自然语言的测试场景成为了业务、开发和测试之间沟通的“活文档”对齐理解减少歧义。5.2 当前面临的挑战与注意事项初期建模投入框架的威力建立在高质量的领域行为模型之上。构建这个模型需要前期投入对于业务逻辑极其复杂或界面极不规范如大量自定义控件的应用建模工作量和难度会比较大。这不是一个“开箱即用立即省力”的工具而是一个“先投资后回报”的体系。语义理解的准确率AI对自然语言和UI语义的理解并非100%准确。在复杂、模糊的场景下仍然需要人工介入澄清。这要求测试设计者具备一定的“与AI协作”的能力学会编写更清晰、无歧义的描述。执行性能与稳定性基于CV和AI模型的元素定位其速度通常慢于传统的基于代码的定位器。在大规模测试套件中执行时间可能成为考量因素。此外自愈过程虽然智能但有时会消耗额外时间且其成功率无法保证100%。复杂验证点的表达对于一些涉及复杂业务逻辑、多数据关联的断言例如验证下单后库存减少、用户积分增加、商家后台生成订单仅靠自然语言描述可能不够精确仍需辅以一些自定义的校验脚本或数据查询。5.3 适用场景建议基于以上体验我认为SITS 2026类框架在以下场景能发挥最大价值核心业务流程的回归测试如电商的购物流程、金融的开户流程、SaaS产品的核心功能流。这些流程稳定、关键且用自然语言描述清晰。跨端一致性测试同一业务在Web、iOS、Android端的表现。基于语义的测试可以更容易地实现跨端用例复用。探索性测试的辅助记录手动探索测试时可以用它实时记录操作步骤和观察点自动生成可回放的测试场景。敏捷团队的需求验证在迭代中用自然语言快速编写验收测试场景与产品需求对照确保开发实现符合预期。6. 对测试工程师的影响与技能准备SITS 2026的出现并不意味着测试工程师会被取代而是意味着角色的进化。工作的重心将从“编写和维护脚本代码”转向更高价值的领域。6.1 工作重心的转移从“脚本工人”到“建模专家”最重要的技能变成了为业务系统进行“行为建模”和“语义标注”。你需要像架构师一样抽象出系统的核心领域模型和关键业务流程。从“执行者”到“设计者与分析师”你将花更多时间设计更全面、更具破坏性的测试场景分析AI测试结果背后的业务含义而不仅仅是看通过率。从“找元素”到“训模型”你的部分工作将变成“训练”和“调教”AI测试伙伴。当它理解错误时你需要纠正它当它能力不足时你需要通过提供更多样本或调整模型参数来提升它。6.2 需要储备的新技能结合当前“AI测试工程师”相关的热门讨论未来测试人员可能需要关注以下技能Prompt工程如何用最有效的语言与AI测试框架沟通编写出清晰、无歧义、覆盖全面的测试场景描述。基础AI/ML概念理解语义理解、计算机视觉、大语言模型的基本原理知道它们的优势和局限以便更好地使用和调试相关工具。领域驱动设计DDD思想这对于进行业务行为建模至关重要帮助你更好地划分领域、聚合和定义通用语言。数据思维能够设计测试数据并分析AI测试产生的大量执行日志和结果数据从中发现潜在的质量模式或风险点。6.3 与现有工具链的融合SITS 2026不会完全取代现有的自动化框架如Selenium、Cypress、Pytest。更可能的路径是共存与集成。例如用SITS 2026覆盖上层业务流程和UI交互用传统的代码框架处理底层复杂的计算验证、性能测试或需要高度定制化的特殊场景。测试工程师需要具备整合不同工具构建混合自动化策略的能力。在我个人看来SITS 2026所代表的“语义理解行为建模”的零代码自动化路径是测试自动化发展的一个必然且正确的方向。它直击了传统自动化维护成本高的痛点。虽然目前内测版本在复杂场景和极端性能下仍有挑战但其展现出的潜力是巨大的。它不仅仅是一个工具更是一种新的测试方法论。对于测试从业者而言尽早了解、尝试并掌握与之相关的思维和技能是在AI时代保持竞争力的关键。与其担心被替代不如主动拥抱变化将自己从重复的编码劳动中解放出来去从事更需要人类创造力和批判性思维的工作。毕竟定义“测什么”和“怎么测得好”永远比“怎么写脚本”更有价值。