一条创建订单的自动化用例，运行报告显示"通过"。测试人员打开业务系统，却发现订单金额不对，状态也还停在"草稿"。回头看用例，它只检查了一件事：点击提交后，页面出现过"保存成功"。
这条断言没有写错；它确实看到了成功提示。问题是它回答的不是团队真正关心的问题。"页面说成功了"与"这笔订单按预期创建了"是两个不同的结论。 如果用例只验证前者，就可能一路绿灯，把后者的错误漏过去。
先找出"假通过"是怎么来的
自动化报告中的"通过"，只表示已经配置的检查通过了。下面四种录法，都可能让错误业务结果逃过检查。
| 录法 | 实际验证了什么 | 可能漏掉什么 |
|---|---|---|
| 只录入、点击，不加断言 | 页面操作没有在中途报错 | 数据是否保存、保存到哪里、字段是否正确 |
| 只断言"保存成功" | 页面出现过一条成功提示 | 后台处理结果、最终状态和关键字段 |
| 断言整页包含"已完成" | 当前页面某处有这几个字 | "已完成"是否属于本次订单 |
| 断言列表里有"自动化订单" | 找到一条相似记录 | 是否是本轮运行新建的那条 |
遇到测试通过却查出业务错误，第一步不是给每个按钮都补一条断言，而是把用例的测试目标写成一句话：本次提交的订单，应该在详情页显示正确的订单号、金额和状态。 后续断言围绕这句话设计。
一条有效断言，要说清对象、结果和位置
设计断言时，先问三个问题。
对象是谁？ 是本次新建的订单，还是列表里任意一笔订单？创建时可以写入每次唯一的测试备注，并保存本次输入值；后续再核对备注与系统生成的订单号，避免误把旧订单当作新订单。若用例使用固定测试数据，也要用明确的业务编号区分目标。
结果是什么？ 是"出现过成功提示"，还是"订单金额为 100.00 元、状态为待审批"？反馈可以检查，但关键断言必须覆盖本用例要保护的业务规则。
在哪里验证？ 提交按钮附近的提示适合判断页面是否接受了操作；列表和详情页更适合检查最终结果。需要确认持久化时，可以刷新或重新打开目标记录再验证。如果目标系统本来是异步处理，应等待其公开的完成状态，而不是假设点击后立刻完成。
把这三个问题说清楚，断言才不会因为页面上碰巧有相同文字就通过。
用创建订单示范：从提交反馈走到业务结果
假设测试环境中，新建订单时填写金额 100.00 元，并在备注中写入每次唯一的 回归订单-{时间戳}；提交后系统生成订单号。可以把用例组织成这样：
text
填写订单，金额为 100.00 元，备注使用"回归订单-时间戳"
保存本次备注值为变量 order_tag
点击"提交"
断言：页面出现提交反馈
在详情页保存本次订单号为 order_no
断言：详情页备注等于 {{order_tag}}
进入订单列表，搜索 {{order_no}}
断言：搜索结果出现 {{order_no}}
打开该订单详情
断言：详情页订单号为 {{order_no}}，备注为 {{order_tag}}
断言：金额为 100.00 元
断言：状态为"待审批"这里的检查有三层，职责各不相同：
- 提交反馈帮助定位问题停在提交环节，但它不是最终结论。
- 唯一备注与订单号一致确认提交后打开的详情，以及后面查到的记录，都属于本次订单，而不是旧数据。
- 金额和状态直接验证这条用例关心的业务结果。
如果订单提交后需要异步计算金额或推进状态，金额和状态断言应放在结果可见的位置，并使用等待状态成立的策略；不要在页面仍显示旧值时立即下结论。反过来，如果业务要求提交后必须立即显示某个状态，才适合把"立即检查"作为测试要求。
一个判断方法： 删除"保存成功"断言后，剩下的断言仍能证明订单创建正确吗？如果不能，说明这条用例还没有覆盖真正的业务结果。
在 CueCast 中，断言目标和匹配方式怎么选？
回演 CueCast 可以在录制时添加断言，保存后也可以在用例详情里编辑断言步骤。文本断言的目标包括整页文本、指定元素、URL、失败提示（错误/警告） ；匹配方式包括包含、等于、不包含、正则匹配 ，指定元素还可选择元素可见。
不同目标适合回答不同的问题：
| 要确认的事情 | 更合适的断言目标 | 原因 |
|---|---|---|
| 是否进入订单详情页 | URL 或详情页特有元素 | 先确认页面上下文 |
| 本次订单号是否正确 | 订单号所在的指定元素 | 避免匹配到列表或其他区域的旧订单号 |
| 金额、状态是否正确 | 对应字段的指定元素 | 把预期限制在具体业务字段上 |
| 页面是否出现报错 | 失败提示 | 用于发现错误/警告，不能代替正向结果断言 |
如果选中的元素只显示 100.00，用"等于"比"包含"更明确；如果元素显示"订单金额：100.00 元"，则可以用"包含"，或者选择更小的金额值元素。整页文本适合验证页面是否出现某个明确标识，不适合证明某个值属于哪条记录。 对关键字段，尽量选到目标订单详情中的具体元素。
CueCast 的文本断言还提供"等待断言成立"和"立即检查"。列表刷新、异步提交、状态更新通常需要前者；后者用于业务确实要求立刻呈现的状态。等待断言成立不是放宽预期，而是在设定时间内等待同一个明确的预期出现。
使用 {{order_tag}}、{{order_no}} 这类运行时变量时，要让本次输入、搜索和断言引用对应的本次值。尤其是系统生成的订单号，保存后应先结合提交时填写的唯一备注核对身份，再用它搜索；否则页面若意外停在旧订单详情，单纯"保存当前订单号并再次断言它"仍可能假通过。 
两个容易忽略的细节
"不包含"也可能造成假通过。 例如刚点击删除，就立即断言整页"不包含订单号"；此时列表还在加载，页面暂时没有任何订单号，断言自然通过。更稳妥的顺序是先确认列表已经加载完成，再在相关列表区域检查目标订单是否消失，必要时刷新后再次验证。
断言越多，不等于覆盖越好。 同一页面上连续检查三个相似的成功提示，并不会比检查一次订单号和一次最终状态更有价值。把断言放在业务状态发生变化的节点：提交后、重新查到记录后、打开详情后。这样失败时也更容易知道问题停在哪一步。
已经出现"假通过"，怎么修？
先保留那次执行报告和业务系统中的实际结果，再按下面顺序修改用例：
- 写下漏掉的业务错误。 是金额不对、状态不对，还是操作到了别人的订单？
- 找到最接近错误的页面。 优先在列表或详情里增加针对本次对象的断言。
- 缩小断言范围。 从整页文字改为具体字段；从通用名称改为本次订单号。
- 检查时机。 该等结果稳定时等待；该验证立即生效时立即检查。
- 用一个错误结果验证断言。 在可控测试环境中，让目标字段与预期不符，确认用例确实会失败，再恢复数据并正常回放。
修复后如果断言变红，先看 CueCast 执行详情中的失败步骤、截图、实际页面内容和预期值。确认是产品结果错误、用例预期过期，还是断言选错了元素。不要只为恢复绿灯，就把"等于"改成宽泛的"包含"，或删掉失败的断言。
最后
一条断言是否有价值，可以用一句话检验：它能否证明"本次的哪条数据，在什么页面，呈现了什么结果"？
CueCast 可以记录操作、回放页面并执行断言；真正决定用例是否会"假通过"的，是测试人员选择验证什么。先认准本次业务对象，再检查关键字段和最终状态，自动化报告中的绿色才更接近团队想要的结论。