很多团队做纯视觉知识库，一开始的定位就是"帮AI更好地识别元素"。但我们的经验是，知识库更大的价值在于：让AI能够自主生成真正可执行的测试用例，而不只是执行人写的用例。
这是两个完全不同的层次。前者是提高执行效率，后者是从0到1实现用例生成自动化。
纯视觉自动化测试是当前移动端测试领域最具潜力的技术方向之一。相较于传统的基于控件属性的自动化方案，纯视觉方案不依赖开发暴露控件ID，支持跨平台、跨应用，对UI层变更的容忍度更高，落地成本也更低。
当前主流的实现方式是结合大模型的视觉理解能力来识别UI元素、生成操作指令。但在实际落地中，很多团队把90%的精力都花在模型选型和Prompt调优上，跑了几个月后发现，同样的模型和技术方案，不同团队的成功率能差出30%以上。核心差异就在于知识库的积累深度。
大模型提供的是通用视觉理解能力，而具体业务场景下的UI特征、交互逻辑、业务规则都是通用知识无法覆盖的。没有高质量的专属知识库，纯视觉自动化就像一个没有业务经验的外包测试人员，看起来什么都能做，但实际跑起来处处踩坑。
本文从UI元素、页面结构、交互逻辑、断言规则、问题案例五个维度，系统梳理纯视觉自动化测试知识库需要积累的核心内容。
一、UI元素知识库
为什么要积累这些知识？因为AI生成测试用例的时候，需要知道：这是什么元素？可以做什么操作？操作后会有什么结果？这些知识都没有的话，AI生成的用例就是空架子，根本跑不起来。
积累控件知识的目的，不只是为了执行时能点对地方。更重要的是，让AI知道"这个控件可以做什么操作"。
比如知道这是个输入框，AI生成用例的时候就知道可以在这里输入文本；知道这是个开关，AI就知道可以切换状态；知道这是个列表，AI就知道可以滑动、可以点击某一项。
没有这些知识，AI生成的用例可能会让Agent去点一个根本不可点击的静态文本，或者去滑动一个根本不能滑动的卡片。
通用控件识别知识
移动端常见控件包括按钮、输入框、开关、单选、多选、下拉、列表、卡片、导航栏、标签栏等。每个控件都有其视觉特征、常见交互方式和可能的状态变化。
以按钮为例，需要识别的视觉特征包括：圆角、阴影、颜色对比、可点击区域大小、文字排版、图标位置等。不同App的按钮风格差异很大，但底层视觉特征是相通的。我们的做法是把通用控件的视觉特征抽象出来，比如按钮的核心特征是"有明确边界、与背景有颜色对比度、包含文字或图标、有可点击热区范围"。把这些特征写入知识库后，模型对通用控件的识别准确率能提升20%左右。
业务专属控件
每个App都有自己特有的控件，比如电商的商品卡片、社交的头像框、金融的K线图、视频的播放控件。这些是通用大模型识别最差的地方，必须自己积累。
要记录的内容包括：控件的视觉特征、在哪些页面出现、有什么交互逻辑、有哪些变种。比如我们的商品卡片就有大图模式、列表模式、瀑布流模式三种，每种模式下的识别点都不一样。刚开始模型经常把商品卡片和普通内容卡片搞混，操作错了好几次。后来把这三种卡片的特征都记到知识库，识别错误率就从15%降到了2%以下。
控件状态知识
同一个控件在不同状态下视觉表现差异很大。按钮有正常、禁用、选中、加载中、高亮等状态；输入框有空、有内容、错误状态、聚焦状态；开关有开、关、半开等状态。
状态识别错了，后续操作全错。印象很深的一次，有个提交按钮禁用状态下是灰色的，模型以为是普通按钮就去点，点了好几次都没反应，脚本就卡住了。后来把所有控件的各种状态都记下来，操作前先判断状态，这种问题就再也没出现过。
二、页面结构知识库
为什么要积累这些知识？因为AI生成测试用例的时候，需要知道：这是什么元素？可以做什么操作？操作后会有什么结果？这些知识都没有的话，AI生成的用例就是空架子，根本跑不起来。
知道页面的结构和跳转关系，AI生成用例的时候就能连贯地从一个页面走到另一个页面，而不是每步都断片。
比如知道从商品列表点进去是详情页，从详情页加购后会到购物车，AI生成的用例就能形成一个完整的业务流程，而不是一堆孤立的操作步骤。
典型页面模板
登录页、列表页、详情页、搜索页、个人中心、设置页等，每个页面都有典型结构、元素分布和导航关系。比如登录页通常有logo、账号输入框、密码输入框、登录按钮、忘记密码链接。
知道当前页面是什么类型，就能预判元素位置，不用整张图瞎找。我们的做法是把App里所有页面都归类，每个页面类型总结出结构特征。比如列表页的特征是"有导航栏、中间是可滚动的列表、底部可能有标签栏"。模型先判断当前是哪种页面类型，再去找对应类型下的元素，比整张图扫描效率高3倍，准确率也高很多。
页面跳转关系
哪个页面点哪个按钮会跳到哪个页面，这是很重要的上下文知识。AI知道了跳转关系，就能预判下一个页面是什么，不用等页面完全加载出来就知道该找什么元素。
举个例子，在商品详情页点"加入购物车"按钮，正常情况下应该留在当前页，弹出一个toast提示。但如果点"立即购买"，就会跳转到订单确认页。模型知道这个跳转关系，操作完就知道接下来该等什么页面出现，不用傻乎乎地等半天然后发现不对又回去。跳转关系知识库建起来后，我们的脚本执行速度提升了40%。
弹窗和异常页面
各种系统弹窗、业务弹窗、加载页、错误页、空状态页，这些是自动化测试最容易挂的地方。必须把所有可能出现的弹窗都记下来，什么时候会出现，出现了应该怎么处理。
比如系统的权限弹窗，刚开始经常把脚本卡死。我们把所有可能弹出来的相机权限、位置权限、通知权限，还有各种业务弹窗都整理出来，每个弹窗的处理方式都记清楚。现在脚本遇到弹窗就知道该点"允许"还是"拒绝"，不会卡在那。还有网络错误页、服务器500页、列表为空的页面，这些也都要记下来，遇到了知道怎么处理。
三、交互逻辑知识库
为什么要积累这些知识？因为AI生成测试用例的时候，需要知道：这是什么元素？可以做什么操作？操作后会有什么结果？这些知识都没有的话，AI生成的用例就是空架子，根本跑不起来。
知道交互逻辑，AI生成用例的时候就能知道什么操作后面应该跟什么操作。
比如删除操作后面应该有二次确认弹窗，提交订单后面应该跳支付页。
没有这些知识，AI生成的用例可能会在删完东西后直接点返回，或者提交订单后去点首页，这些都是不符合业务逻辑的。
通用交互模式
点击、长按、滑动、双指缩放、拖拽、输入文本、选择日期、选择图片等，每种交互都有其视觉特征、操作方式和预期结果。
比如滑动，需要知道是横向滑动还是纵向滑动、从哪滑到哪、滑多远。这些不是AI天生就会的，必须教。我们最开始以为滑动很简单，结果就是经常滑过头或者力度不够。后来把各种滑动场景都总结出来：轮播图是横向滑，列表是纵向滑，删除操作要滑多少距离，刷新要从什么位置开始滑。把这些规则都写清楚，模型操作的成功率从60%提升到了95%。
业务交互逻辑
特定业务场景下的交互规则，比如：购物车勾选商品后总价会变、提交订单后要跳支付页、删除操作需要二次确认。这些业务规则是通用大模型不知道的，必须自己积累。
有一次跑加购流程，模型点完加购按钮直接就去结算了，结果因为没注意到有个选择规格的弹窗。后来把"加购前如果有多个规格需要先选择规格才能加购"这个规则加到知识库，这种情况就不会再错了。业务逻辑这个东西，只有你们自己最清楚，大模型不可能知道。
异常处理逻辑
操作失败了怎么办？网络断了怎么办？服务器报错怎么办？正常流程AI能跑，但出了异常就懵了。知识库要记录各种异常情况的视觉特征和处理方式。
比如提交订单失败了，是重试还是返回上一页？网络断了弹出提示是等网络恢复还是终止任务？这些都要有明确的处理逻辑。我们现在把常见的十几种异常场景都整理了处理方案，脚本遇到异常不会直接挂掉，而是按照知识库的规则去处理。异常处理覆盖后，我们的脚本成功率从75%提升到了90%。
四、断言规则知识库
为什么要积累这些知识？因为AI生成测试用例的时候，需要知道：这是什么元素？可以做什么操作？操作后会有什么结果？这些知识都没有的话，AI生成的用例就是空架子，根本跑不起来。
这是生成可执行用例最关键的部分。AI光知道要做什么操作还不够，还得知道做完之后怎么验证对不对。
知道视觉断言规则，AI就能生成"检查页面标题是否正确"这样的断言；知道业务断言规则，AI就能生成"检查购物车数量是否+1"这样的断言；知道性能断言规则，AI就能生成"检查页面加载时间是否超过3秒"这样的断言。
视觉断言规则
怎么判断一个页面是对的？元素是不是在应该在的位置？文字是不是正确？颜色是不是对的？布局是不是整齐？这些视觉判断的规则，必须量化。不能说"看起来差不多"，要说"文本匹配度95%以上"、"元素位置偏差不超过5个像素"。
我们最开始的断言写得很松，结果有次UI改了没测出来。后来把每个页面的关键元素位置、文字内容、颜色值都记下来，用具体的数值去判断，就靠谱多了。当然也不能太严，不然随便动个一两个像素就挂了也不行，这个度要把握好。我们现在的标准是：关键元素位置偏差不超过8像素，文字内容匹配度95%以上，主色调偏差在可接受范围内。
业务断言规则
操作完成后，业务状态应该是什么样的？比如：加购成功后购物车数量应该+1、下单成功后订单状态应该是"待支付"、删除成功后列表应该少一条。这些业务规则是测试的核心，必须精准。
有一次加购成功了，页面上购物车图标上的数字没及时刷新，模型以为没加上就又点了一次。后来把"加购成功后检查购物车数量+1"这个断言加上，操作完先等数字变了再往下走，就不会重复加购了。业务断言是保证测试有效性的关键，没有业务断言的自动化就是在瞎跑。
性能断言规则
操作的响应时间在多少以内算正常？页面加载超过3秒就算慢，动画卡顿超过500ms就算有问题。这些性能指标，也要写到知识库裡。
我们现在每个关键操作都加了时间断言：启动App到首页加载完成不能超过2秒，点击按钮到页面跳转完成不能超过1.5秒，列表滑动帧率不能低于50fps。刚开始跑的时候，经常发现有些页面加载特别慢，通过这些断言就能及时发现性能问题。性能断言加上后，我们在测试过程中发现了十几个之前没注意到的性能问题。
五、问题案例知识库
为什么要积累这些知识？因为AI生成测试用例的时候，需要知道：这是什么元素？可以做什么操作？操作后会有什么结果？这些知识都没有的话，AI生成的用例就是空架子，根本跑不起来。
识别失败案例
AI识别错了的那些案例，一定要存下来。错在哪了？把按钮认成了卡片？把文字认成了图片？为什么会错？分析原因，然后补充到知识库裡，下次就不会再错了。
我们有个"错题本"，每次识别错了都记下来。比如有次把两个挨得很近的按钮搞混了，分析原因是两个按钮长得太像，只是文字不一样。后来就把"相邻相似按钮优先看文字区分"这个规则加上，类似的错误就少了。错题本积累了100多个案例后，我们的识别错误率下降了80%。
典型Bug案例
自动化测试发现的Bug，也要存下来。这个Bug长什么样？视觉特征是什么？在什么场景下出现？以后遇到类似的视觉特征，就能重点关注。
比如有个Bug是列表加载到最后一页时，下面多出一片空白。我们把这个Bug的截图和特征记下来，以后跑列表页的时候就会特意检查一下底部是不是有多余的空白。虽然不是每次都能发现新Bug，但至少已知的不会再漏了。现在我们的典型Bug案例库有50多个案例，覆盖了大部分常见的UI问题。
人工干预案例
AI跑不通，人工介入处理的那些场景。人是怎么判断的？人是怎么操作的？把人的判断逻辑和操作方式记录下来，教给AI。
刚开始跑复杂场景的时候，经常需要人去救场。每次救场的时候我们都把操作录下来，分析人是怎么判断的、怎么操作的，然后把这些逻辑提炼出来加到知识库。比如有个很复杂的筛选页面，刚开始AI总搞不定，后来把人操作的步骤拆解成12条规则，后来AI就能自己搞定了。人工干预案例积累了30多个后，我们的人工介入率从40%降到了5%以下。
六、知识库的持续迭代
为什么要积累这些知识？因为AI生成测试用例的时候，需要知道：这是什么元素？可以做什么操作？操作后会有什么结果？这些知识都没有的话，AI生成的用例就是空架子，根本跑不起来。
知识库不是建完就完了，是要持续迭代的。每次跑测试，不管成功还是失败，都要分析。成功了，看看有没有可以优化的地方。失败了，分析是不是知识库缺东西，该补充什么。
我们团队的经验是：前3个月，知识库每周都要更新，每次更新至少加5条新规则；3个月后，更新频率降下来，但还是要保持每周至少一次复盘。刚开始的时候，每周都能加好多东西，感觉永远加不完。慢慢的，加的东西越来越少，稳定性越来越高，就说明知识库慢慢成熟了。
我们的知识库从0到现在，已经积累了500多条规则，覆盖了UI元素、页面结构、交互逻辑、断言规则、问题案例五个维度。随着知识库的不断完善，我们的纯视觉自动化测试成功率从最开始的30%，提升到了现在的92%，而且还在持续提升。
总结
纯视觉自动化测试，不是把大模型接进来就能跑好的。真正的核心竞争力，是你有没有一个足够深、足够全的专属知识库。
UI元素、页面结构、交互逻辑、断言规则、问题案例，这五个维度缺一不可。大模型是通用的，但你的业务是专属的。知识库就是把通用大模型变成你的专属测试工程师的关键。
与其不断换模型、调Prompt，不如沉下心来好好建知识库。模型会越来越便宜、越来越好用，但知识库是你自己的，别人抄不走，这才是真正的壁垒。
纯视觉自动化的终局，不是人写用例AI来跑，而是AI自己理解业务、自己生成用例、自己执行验证。
知识库就是实现这个终局的基础设施。没有足够深的业务知识，AI生成的用例只是看起来像那么回事，实际上根本跑不起来。
从这个角度看，知识库的深度，直接决定了你的纯视觉自动化能走到哪一步。
纯视觉自动化的下半场，拼的不是谁的模型好，而是谁的知识库深。