上篇文章为大家讲述了AI技术趋势与核心原理，接下来继续为大家讲述AI工具与平台的应用及实践场景与挑战。
02
工具与平台应用
3、Test.AI与Applitools Eyes在UI测试中的核心差异是什么？如何选择？
（工具对比：组件识别技术、视觉比对精度、跨平台支持）
如果把 UI 测试比作 “给手机 APP 做体检”，Test.AI 和 Applitools Eyes 就像两位各有所长的医生 —— 一个擅长 “查功能是否正常”，一个专注 “看外观是否达标”。
1
核心差异：就像 “功能检测师” vs “视觉质检员”
1. 技术套路：靠特征认东西 vs 靠对比找不同
Test.AI：像个会认特征的快递员
比如要找 APP 里的 “提交” 按钮，它不记 “门牌号”（ID、XPath），而是记 “长相”——“灰色圆角方块 + 上面写着‘提交’+ 在输入框下面”。
就算开发把按钮挪到输入框右边，或者改了 ID，只要 “灰色 +‘提交’字” 这两个特征没变，它一眼就能认出来。这种 “看特征组合” 的本事，能自动适应 UI 的小改动，就像快递员就算你换了发型，也能通过 “戴眼镜 + 穿蓝外套” 认出你。
Applitools Eyes：像个拿着样板的质检员
它先给合格的界面拍张 “标准照”（基准图像），测试时再拍一张 “当前照”，两张对比找不同。
比如按钮颜色从灰色变成浅灰、字体加粗了，它都能标出来，还能分清 “大问题”（按钮消失了）和 “小变化”（广告图换了）。
就像服装厂质检员拿着样板，对比新衣服的针脚、颜色是否一致，一点差别都逃不过。
2. 擅长领域：管功能跑不跑 vs 管样子对不对
Test.AI：专注 “功能能不能用”
比如测试 “登录流程”，它会找到 “用户名输入框”（不管 ID 怎么变），输入文字，再找到 “登录按钮” 点一下，最后看能不能跳转到首页。
哪怕输入框从左边移到右边，只要还能输入文字，它就照测不误。核心是确保 “按钮能点、输入有反应”，不管界面长得有没有微调。
Applitools Eyes：专注 “样子对不对版”
比如设计师要求 “提交按钮必须是圆角 10px、蓝色 #007AFF”，它会精确对比像素 —— 如果按钮变成直角，或者颜色深了一点，立刻标红提醒。
但它不管 “点了按钮会不会提交”，就像质检员只看衣服版型对不对，不管穿起来舒不舒服。
2
怎么选？看你要解决什么 “麻烦”
场景 1：APP 天天改，定位老失效 —— 找 Test.AI
如果你们团队每周都更新功能，今天改个按钮位置，明天换个 ID，传统测试脚本总报错，选 Test.AI 准没错。
比如电商 APP 搞促销，“加入购物车” 按钮从商品名下面移到右边，Test.AI 凭着 “橙色 + 购物车图标” 的特征，照样能找到并点击，不用手动改脚本。
场景 2：多设备适配，怕样子走形 —— 找 Applitools Eyes
如果你们要在手机、平板、电脑上都用同一个 APP，怕 “在手机上按钮是圆的，到平板上变成方的”，Applitools Eyes 是强项。
它能同时对比 iPhone、安卓、电脑端的界面，像个 “跨设备质检员”，把按钮变形、文字错位这些 “外观 bug” 全揪出来。
场景 3：又要功能稳，又要样子对 —— 俩都要
比如银行 APP 的转账功能：
用 Test.AI 确保 “输入金额后点转账，钱能转出去”（管功能）；
用 Applitools Eyes 检查 “转账按钮的红色必须符合品牌规范，在老年模式下字体不能太小”（管外观）。
就像体检时既要看 “心脏跳得稳不稳”，也要看 “皮肤有没有异常”，两者搭配才放心。
3
总结：不是 “二选一”，是 “按需组队
Test.AI 就像 “功能测试界的导航仪”—— 不管路牌换没换，只要终点特征没变，就能带你找到地方；
Applitools Eyes 像 “视觉测试界的放大镜”—— 拿着标准图对比，一点不一样都能看清楚。
实际测试时，完全可以让它们 “搭伙干活”：用 Test.AI 保证 APP 能正常用，用 Applitools Eyes 保证 APP 长得符合设计。毕竟用户既在意 “点了按钮有反应”，也在意 “界面看着舒服、没错位”!
03
实践场景与挑战
4、AI生成的测试用例是否存在“幻觉”问题？如何通过人工审核规避风险？
（实践挑战：LLM输出准确性、测试场景覆盖验证、人工复核流程）
AI 生成测试用例时的 “幻觉” 问题，就像学生写作业时 “凭感觉编答案”—— 看起来逻辑通顺，细究却发现和实际需求对不上。
这种 “幻觉” 不仅会浪费测试精力，甚至可能漏掉真正的风险。先搞懂它为啥会 “走神”，再针对性审核，才能让 AI 用例靠谱起来。
AI 测试用例的 3 种常见 “走神现场”
“幻觉” 本质是 AI 对需求的 “过度脑补” 或 “记忆混淆”，具体表现很接地气：
凭空造功能：
比如需求里只说 “支持手机号登录”，AI 却生成 “支持邮箱登录的验证码输入测试”—— 其实产品根本没做邮箱登录功能，这就是 AI 把其他场景的记忆 “套” 过来了。
逻辑拧麻花：
测试 “购物车结算” 时，AI 写 “先提交订单，再选择商品”—— 明显反了流程，就像有人说 “先吃蛋糕，再买蛋糕”，属于想当然的逻辑错误。
细节瞎填空：
需求里写 “密码长度 6-18 位”，AI 生成 “测试密码长度为 5 位、19 位的提示信息”（这部分没问题），但后面加了句 “测试密码包含特殊符号时自动转换为大写”—— 实际上产品没这规则，AI 自己 “加戏” 了。
之所以会这样，核心是 AI 依赖训练数据里的 “规律”：如果训练数据里 “登录功能” 常和 “邮箱、手机号” 绑定，它就可能默认两者都存在；如果逻辑复杂的场景数据少，它就容易按简单规律 “瞎编”。
人工审核怎么 “打假”？4 步把 “幻觉” 拦在门外
如果把 AI 生成的用例比作 “初稿”，人工审核就是 “校对 + 优化”—— 不用从头写，但要盯着关键处 “挑刺”。具体可以按这四步来：
1
先 “对需求”：给 AI 用例画个 “紧箍咒”
拿着产品需求文档（PRD）或原型图，像 “查字典” 一样核对：
先圈出需求里明确的功能（比如 “仅支持微信支付”），删掉 AI 生成的 “支付宝支付测试”（假功能）；
标注需求里的核心规则（比如 “订单满 200 元免邮”），检查 AI 用例里的条件是否符合（比如有没有写 “满 150 元免邮” 这种错规则）。
关键：只认 “需求里写的”，对 AI“额外加的功能 / 规则” 零容忍。
2
再 “顺逻辑”：把用例当 “剧本” 走一遍
把测试步骤当成 “剧本”，自己模拟执行一次，看能不能走通：
比如 AI 写 “注册流程：输入手机号→设置密码→点击登录→完成注册”—— 明显错了（应该是 “点击注册”），模拟时一顺就发现逻辑断了；
对 “如果 A 则 B，否则 C” 的分支场景（比如 “填写正确手机号→收验证码；填错→提示错误”），检查 AI 有没有漏分支，或者把 “正确 / 错误” 的结果写反。
关键：别只看文字通顺，要代入 “用户操作场景”，不通顺的就是坑。
3
重点盯 “边界”：AI 最容易在 “极端情况” 上翻车
AI 擅长写 “常规场景”（比如 “输入正确密码登录成功”），但对 “边界值、异常场景” 容易瞎编，这部分要重点审：
比如测试 “年龄输入框”（需求是 “18-60 岁”），AI 可能漏了 “17 岁（下限 - 1）、61 岁（上限 + 1）” 的测试，或者错写成 “测试 0 岁、100 岁”（虽然极端，但需求外的场景没必要测，属于无效用例）；
异常场景（比如 “网络断了时提交订单”），检查 AI 写的 “预期结果” 是否合理 —— 比如 AI 写 “提示‘网络错误’并自动保存草稿”，但实际产品没做 “自动保存”，这就是幻觉，需要改成 “提示‘网络错误’”。
关键：边界值、异常场景是 AI 的 “弱项”，宁多审一遍，别放过一个。
4
最后 “做减法”：删掉 “无效努力”
AI 为了 “显得全面”，可能生成重复或没必要的用例，比如：
测试 “按钮颜色” 时，既写 “点击红色按钮”，又写 “点击 #FF0000 色按钮”（其实是同一个按钮，重复了）；
需求里明确 “仅支持安卓 10 及以上版本”，AI 却生成 “安卓 9 版本兼容性测试”（属于无效场景）。
人工审核时要像 “修剪树枝”—— 留下核心场景，剪掉重复、无效的 “冗余枝”，避免测试时做无用功。
总而言之，AI 生成测试用例的优势是 “快”（几分钟出几十条），但缺点是 “没常识”（容易瞎编）；人工审核不用替代 AI，而是做 “最后的过滤器”—— 用需求卡真假，用逻辑查通顺，用边界补漏洞。
就像做蛋糕时，AI 负责快速搅拌面糊，人工负责检查 “糖没放多、没忘了放酵母”，这样最后出炉的测试用例才既高效又靠谱。
......
本文节选自51Testing软件测试网【专题】
《AI在软件测试中的应用》
专题后续还介绍了
“相关实战场景与挑战、职业发展与技能转型”
长按识别下方二维码
查看本期专访！
每日有奖互动
你在工作中用到过哪些AI 工具？
你觉得最好用的是哪款？
