在Squish里，验证点并不只是“录一段脚本后顺手加一句判断”，它本质上是把界面状态、对象属性、截图或表格内容转成可重复执行的检查动作。官方文档明确说明，验证点既可以通过代码直接写，也可以通过IDE里的Verification Point Creator点选生成；而属性校验最常见的落地方式，就是用对象属性加`test.compare()`或`test.verify()`这样的验证函数来完成。

　　一、Squish验证点怎么写

　　这一节要解决的，不是“能不能写出验证点”，而是“怎样把验证点写得稳定、可维护、失败后容易定位”。Squish官方把验证点分成属性验证、截图验证、可视化验证等类型，实际项目里最常用的仍然是属性验证，因为它可读性高、修改成本低，也最适合做回归测试。

　　1、先把验证点放在状态稳定之后

　　不要在刚点击完按钮、界面还没刷新完时立刻断言，先用`waitForObject`或等价等待动作拿到稳定对象，再写验证点。这样做的目的，是把“界面还没更新”与“功能真的错误”区分开，避免脚本时灵时不灵。

　　2、优先写属性验证点，不要一上来就用截图

　　如果你要验证按钮是否可用、文本是否正确、勾选状态是否变化，优先直接校验对象属性，例如`text`、`enabled`、`checked`、`value`。官方文档把这类验证定义为最常见的验证点类型，而且在IDE里点击属性后就能直接进入Verification Point Creator。

　　3、录制生成后优先转成脚本化验证

　　Squish允许把验证点插成资源型VP，也可以插成脚本化属性验证。官方说明里推荐的默认方式是Scriptified Properties VP，因为这种写法更容易阅读、修改和删除，维护成本明显更低。

　　4、对象名先稳定，再写验证点

　　验证点失败很多时候不是属性错了，而是对象定位不稳定。写之前先确认对象识别属性足够精简且唯一，至少保证类型和关键名称字段可唯一命中。官方在对象识别文档里也强调，通常至少需要类型属性，再配合名称等标识才能稳定访问对象。

　　5、复杂验证用循环和函数封装，不要复制粘贴

　　当你要校验列表、表格或多条字段时，不要一条条手工写重复断言，优先封装成函数或循环遍历。官方在验证点说明里也提到，直接写代码的好处之一，就是能比点选方式实现更灵活的批量验证逻辑。

　　6、失败信息里写清业务语义

　　给验证函数加上message参数，把校验意图写清楚，例如“保存后状态应为已发布”而不是“check1 failed”。`test.compare()`和`test.verify()`都会把message写进测试日志，这对后续定位失败原因非常有帮助。

　　二、Squish属性校验与断言逻辑怎么选

　　这一节的核心不是API背诵，而是根据校验对象和失败语义选对断言方式。Squish官方把`test.compare()`定义为比较两个值是否相等的布尔测试，把`test.verify()`定义为直接判断一个条件是否为真；两者都能写入PASS或FAIL日志，但适用场景并不一样。

　　1、值对值校验优先选test.compare

　　当你明确知道期望值是什么，例如文本应等于“登录成功”，计数应等于3，勾选状态应等于True，这种“实际值对期望值”的场景优先用`test.compare(actual,expected,message)`。它的好处是失败时能直接看出左右值不一致，定位更直观。

　　2、布尔条件校验优先选test.verify

　　当你关注的是条件是否成立，例如对象已启用、元素已隐藏、某个值大于0、某个字符串包含关键字，这类不强调固定期望值的场景更适合用`test.verify(condition,message)`。官方也明确把它定义为对布尔条件进行判断的函数。

　　3、资源型验证点适合稳定界面资源，脚本断言适合业务逻辑

　　如果你要反复验证同一批固定属性，或者需要把截图、属性组合成可复用资源，可以用`test.vp(name)`调用资源型验证点。若验证逻辑随数据变化明显，或你需要循环、分支、动态拼接条件，直接写脚本断言更合适。官方对Verification Point Creator和`test.vp()`的说明也对应了这两种路径。

　　4、预期失败场景不要硬写普通断言

　　如果某个缺陷是已知问题、当前版本允许暂存但希望持续跟踪，优先用`test.xverify()`或`test.xvp()`表达“预期失败”，不要把它写成普通FAIL后再靠人工忽略。这样日志语义更清晰，也更利于回归阶段判断问题是否被修复。

　　5、截图与可视化验证只放在属性断言覆盖不到的地方

　　当你要验证整块界面布局、复杂样式或多个控件组合状态时，再考虑Screenshot VP或Visual Verification Point。官方提供了截图验证和可视化验证专门入口，但这类验证通常比属性断言更重，也更依赖环境一致性。

　　6、断言失败后的停测策略要提前定好

　　`test.verify()`和`test.compare()`默认都会写日志，但是否在失败后中断，要看`testSettings.breakOnFailure`和`testSettings.throwOnFailure`这类设置。对冒烟测试可以更激进，关键路径失败就中断；对批量回归则更适合继续执行，把问题一次收集全。

　　三、Squish验证点维护与结果复盘怎么做

　　前两节解决的是“怎么写”和“怎么选”，这一节解决的是“怎么让它长期可维护”。很多团队的Squish脚本一开始能跑，后来越来越脆，通常不是工具不行，而是验证点写得太散、对象识别不稳、结果日志没有形成复盘闭环。官方文档里，Test Results视图支持按PASS、FAIL、LOG逐项分析，失败的截图、表格和可视化验证还可以直接查看差异，这些能力本身就适合做验证点治理。

　　1、把高频验证封装成公共函数

　　像按钮可用性、文本一致性、表单必填校验这类高频动作，建议封装成共享函数，不要每个用例各写一套。这样对象属性或日志口径要改时，只改一处就够。

　　2、把对象识别和断言逻辑分层

　　对象定位尽量单独放在对象库或公共定位函数里，断言逻辑只负责拿对象和校验结果。这样界面改版时，多数情况下只需要调整对象识别，不必重写整批测试。

　　3、失败后优先看日志语义是否足够定位

　　每次失败都先问一句，日志能不能直接告诉我“哪个对象、哪个属性、期望什么、实际是什么”。如果不能，就说明验证点还不够好，应该回去优化message或断言粒度。

　　4、把截图和差异查看留给最终证据，不要拿它替代属性校验

　　属性能说明白的问题，就不要让人工去比图。截图差异更适合作为最终失败证据或视觉类验证补充，而不是回归测试主路径里的默认验证手段。

　　5、定期清理无效VP与重复断言

　　资源型VP删掉后，如果脚本里还保留`test.vp(name)`调用，就会带来无意义失败；同样，一段流程里重复断言同一属性也会增加维护噪声。建议每次版本迭代后顺手做一次清理，让验证点始终保持精简。

　　总结

　　写Squish验证点时，先把对象状态等到稳定，再优先用属性验证和脚本化断言落地；选择断言逻辑时，值对值用`test.compare()`，布尔条件用`test.verify()`，资源型VP适合固定资源，脚本断言适合动态业务逻辑。最后再把Squish验证点维护与结果复盘做成固定动作，你的脚本才会从“能跑一次”变成“长期可维护”。