验收一个设备列表页时，我遇到过一个看起来很具体、其实很容易把测试做歪的问题：需求临时增加了分页，要求有第 2 页截图，还要验证跨页定位、深链还原、分页器布局，以及用键盘左右方向键翻页。页面本身并不复杂，真正麻烦的是，现场的真实设备记录只有 15 条，按当前每页数量根本不会自然产生第 2 页。
当时我先停了一下。这个问题不能简单理解为“数据少，所以补几条记录”。验收要证明的是界面能不能处理多页，不是证明业务系统里真的有更多设备。如果为了让截图好看，直接把真实数据改成几十条，页面或许能出现第 2 页，但我们已经不知道后面的通过到底来自真实状态，还是来自为了测试临时制造的状态。
这件事让我重新意识到，页面验收往往同时包含两种不同的真实性：一种是业务数据的真实性，另一种是交互边界的真实性。它们可以在同一次验收里出现，却不能混成一条证据。
真实记录不足，问题到底在哪里
需求增加分页后，页面需要覆盖的路径明显变长了。默认打开时要能正确展示真实记录；切换每页数量后，分页器要有合理的布局；带有页码参数的地址要能还原到对应页；如果一个设备的锚点在第 2 页，直接打开这个深链时，页面还要自动翻到它所在的页，并把选中项带入可视区域。最后，左右方向键也不能只在第 1 页看起来有效。
这些都不是“多放几行文字”就能替代的检查。分页器上的省略号、当前页状态、跳页输入框和边界页按钮，只有在页数真正超过 2 页时才会露出完整形态。深链定位也一样：第 1 页里的地址能够打开，只能说明参数被读取了，不能说明页面能从参数推导出记录所在页。
可现场只有 15 条真实记录。真实数据没有错，也不应该为了满足验收形式被修改。真实数据不足以覆盖边界，不代表边界可以被假装不存在；它只说明我们需要另建一条受控的验证证据线。
如果不处理这个区分，后面会出现两个相反的风险。第一种是把真实数据改多，导致业务数据被测试污染，之后任何人看到列表都会误以为那些记录真实存在。第二种是完全不测第 2 页，只因为当前数据没有第 2 页，最后报告写着“分页已完成”，但最关键的跨页路径从未被实际走过。
我把数据真实性和交互覆盖拆开
我最后采用的做法很朴素：默认路径继续使用真实数据，边界路径单独注入明确标注的模拟数据。模拟数据只服务于这次多页用例，不写回真实 JSON，也不改变页面默认打开时的业务状态。
这样拆分之后，验收就有了两条证据线。第一条是实页回归，回答“页面在当前真实记录下是否正常”；第二条是多页模拟检查，回答“当记录数量达到分页边界时，界面和交互是否正常”。前者不能替代后者，后者也不能冒充前者。
我选择这种方式，是因为它同时保住了两件事：真实数据仍然能说明默认场景没有被改坏，模拟数据又能把自然条件下暂时到不了的边界拉出来。这里的关键不是“模拟”这两个字听起来是否可靠，而是它有没有被隔离、标注和回收。
在实际检查中，真实数据回归完成了 12 组，多页模拟检查也完成了 12 组。两个数字相同，并不表示两边可以合并成 24 组“真实通过”。它们代表不同前提下的证据，报告里必须原样分开写。模拟回归的价值是扩展覆盖面，不是提高真实数据的数量。
最容易走偏的错误捷径
最容易误判的捷径，是直接修改真实数据，让列表立刻出现第 2 页。这个做法表面上最快，实际上把测试前提改成了业务事实。将来有人重跑验收，可能还会以为那些记录来自设备端，进而把一份为了截图生成的状态当成系统现状。
另一个错误捷径是把模拟通过写成真实通过。报告里如果只写“分页 12 组通过”，读者会自然地理解为真实数据已经覆盖多页。等到线上数据仍只有 15 条时，下一位维护者就无法解释为什么截图里有第 2 页，也无法判断这条结论到底适用于哪种输入。
我没有选择这两种方式，是因为验收报告的作用不只是宣布结果，还要保存结果成立的条件。条件一旦被省略，结论就会在传递过程中被扩大。一个截图可以证明某个画面出现过，却不能单独证明这个画面来自真实业务数据。
所以我给模拟场景加了明确标记：截图文件和报告都说明它是第 2 页模拟数据，真实数据截图则保持原有语境。模拟数据只在测试范围内存在，测试结束后不写回业务文件，也不参与默认路径的截图。
只测到第 2 页还不够
一开始我以为，只要看到第 2 页，分页功能就算覆盖了。后来复核截图时发现，这个判断太粗了。小屏视口下，跳页输入框落到了屏幕下方，用户虽然理论上可以操作，验收截图却无法证明分页器完整可见。另一个问题是，深链定位到了第 2 页的选中项，但选中项没有滚入可视区域，用户打开地址后仍然需要自己找它。
这两个问题说明，分页验收不只是数据层面的“页码对不对”，还包含布局和可见性。于是我缩短了小屏下的列表视区，让跳页框回到可见区域；同时让深链恢复后，把选中项滚入页内的可视范围。修正后，3 个目标视口的分页器都完整可见。
这里也有一个重要的边界：模拟数据只能帮助我们制造条件，不能自动保证视觉结果。多页数据把省略号、跳页和跨页状态显示出来，仍然需要在目标宽度下检查它们有没有被遮挡、挤压或落出屏幕。交互状态通过了，不等于交互在当前视口里可用；数据边界和视觉边界必须分别验收。
左右键翻页、切换每页数量回到第 1 页、带参数地址还原、带锚点地址跨页定位，也都应该被视为不同动作。它们都指向“分页”，但失败原因并不相同。把它们合并成一句“分页可用”，会让某一条路径的失败被其他路径的成功遮住。
一份可复用的双证据流程
以后遇到真实记录不足、但必须验证多页或极端状态的页面，我会先做 4 个判断。第一，哪些是只能用真实数据回答的问题，比如默认加载、真实字段展示、现有记录的选择状态。第二，哪些是需要扩大输入规模才能回答的问题，比如第 2 页、长列表、空结果和跨页深链。第三，模拟数据的注入位置是否在测试边界内，能不能保证不写回业务数据。第四，报告和截图是否能让别人一眼区分两种前提。
接着，我会把检查拆成两组记录。真实组只记录真实数据下的默认路径和回归结果；模拟组记录模拟数据下的边界路径、用例数量、截图范围和清理结果。每组都写清“输入是什么、验证了什么、通过意味着什么”，而不是只写一个总数。
最后再做一次反向检查：把模拟开关撤掉，真实数据是否仍保持原样；重新打开默认页面，是否没有遗留的分页状态；报告读者是否可能把模拟截图误读成真实截图。如果其中任何一个答案不清楚，说明隔离还没有完成。
这个方法并不只适用于分页。权限不足时用受控账号验证拒绝路径，网络不稳定时用隔离故障模拟超时，记录为空时用测试夹具验证空状态，都是同一个原则：不要篡改事实来制造证据，而要在边界内制造条件，并留下条件说明。
下次我会怎么做
下次遇到类似需求，我会在开始截图前先画出两列：真实数据能证明什么，模拟数据必须补什么。这样可以尽早发现“当前输入不足以覆盖验收要求”，也能避免做到最后才临时修改业务记录。
我会先完成真实路径的回归，再启动有标记的模拟场景；模拟场景只覆盖缺失的边界，不顺手替换所有数据。对于每一个模拟用例，我会同时检查功能状态、URL 还原、深链滚动和目标视口的可见性。完成后撤销模拟注入，确认真实数据没有变化。
报告里，我会坚持把“真实数据回归通过”和“多页模拟检查通过”分成两行，截图也按同样的语境命名和归档。这样做看起来多了一点说明，实际却减少了下一次解释证据的成本。
这件事让我更愿意把验收看成一种证据管理，而不只是点按钮。真实数据告诉我们现在的系统是什么样，模拟数据帮助我们看见系统在边界上会怎样。可靠的验收不是让所有截图看起来一样真实，而是让每个结论都带着它成立的前提。