测试不是流程，是止损
站上几乎每一页都写着同一句话：先做小规模测试，再报价、再执行。这不是为了显得严谨，是因为这类项目最贵的失败方式是做到一半发现做不成。
数据采集有一个特点：需求听起来完全合理，目标页面看起来也完全正常，但真正跑起来才会暴露问题——关键字段只在登录后可见、单次查询最多返回一百多条、要的那个字段有六成是空的。这些事情在报价阶段靠看和靠猜都发现不了。
测试的作用就是用最小的成本把这些问题提前暴露出来。它的产出不是数据，是结论。
具体验证这五件事
一、字段可得性
需要的字段是不是真的在公开页面上，以及在哪一层。
这一项最常出问题的不是“有没有”，而是“在哪”。字段在列表页可见，一次请求能拿几十条；只在详情页可见，就得逐条点进去，请求量差一到两个数量级。测试会明确告诉你每个字段属于哪一种，以及这对成本意味着什么。
二、实际可采条数
不是目标网站上有多少，是我们实际能稳定拿到多少。
这两个数字经常差很远。多数平台对单次查询的结果数量有上限，超出部分无法通过继续翻页获得，必须按地区、类目或时间段把查询拆成很多次再合并去重。测试会跑通一次完整的拆分逻辑，据此估算覆盖率和总工作量。
三、字段完整率
每个关键字段有多少比例是空的。
这一项决定了数量预期是否现实。如果你要求名单里每条都必须有网站和电话，而目标平台上这两个字段的填写率只有一半左右，那么要拿到一万条合格数据需要处理的原始数据远不止一万条。完整率是平台的客观情况，不会因为多花钱而提高，所以必须在报价前对齐，而不是交付时才发现。
四、结果稳定性
同样的请求重复跑，结果是否一致。
有些平台的搜索结果存在个性化或随机波动，同一条件下两次采集拿到的集合并不完全相同。如果项目需要做周期性对比，这个波动幅度必须先测出来——否则后续每一次数据变化，你都分不清是市场真的变了，还是平台本身在抖。
五、服务边界
需要的内容是不是真的无需登录即可访问，数据类型有没有涉及个人信息，目标平台的条款有没有明确限制，最终用途属不属于我们不承接的范围。
这一项和前四项不同：前四项决定成本，这一项决定做不做。任何一条不通过，后面四项算得再准也没有意义。
测试之后你会拿到什么
- 一份结论：每一项分别是什么情况，哪些能做、哪些做不到、为什么
- 一份样例数据：按实际字段结构跑出来的真实结果，不是虚构占位
- 一份基于实测的报价：不是估算，是按测出来的工作量算的
如果结论是这个需求不值得做，我们会直接说，并指出是哪一项卡住的。这份结论无论是否合作都归你——你拿着它去找别家，至少知道该问什么。
什么情况下结论会是“别做”
- 需要的核心字段只有登录后才可见
- 单次查询上限很低而目标覆盖范围很大，拆分成本远超数据本身的价值
- 关键字段的缺失率高到剩余数据无法支撑原定用途
- 目标网站结构频繁变动，规则维护成本高于数据带来的收益
- 数据用途本身处在我们不承接的范围内
前四种我们会说明成本结构，由你判断值不值得。第五种直接拒绝。
一个常见误解
测试数据不是小批量交付。
测试的样本量很小，字段口径可能还没最终确定，去重规则也还没跑完整。它的用途是回答能不能做，不是拿去进业务流程。见过把测试样本直接导进系统然后得出错误结论的情况，所以这里单独说明一次。
正式交付的数据会附完整的字段说明、完整率统计、去重规则和已知限制——那些在测试阶段都还没定型。