測試不是流程，是停損
站上幾乎每一頁都寫著同一句話：先做小規模測試，再報價、再執行。這不是為了顯得嚴謹，是因為這類專案最貴的失敗方式是做到一半發現做不成。
資料擷取有一個特點：需求聽起來完全合理，目標頁面看起來也完全正常，但真正跑起來才會暴露問題——關鍵欄位只在登入後可見、單次查詢最多回傳一百多筆、要的那個欄位有六成是空的。這些事情在報價階段靠看和靠猜都發現不了。
測試的作用就是用最小的成本把這些問題提前暴露出來。它的產出不是資料，是結論。
具體驗證這五件事
一、欄位可得性
需要的欄位是不是真的在公開頁面上，以及在哪一層。
這一項最常出問題的不是「有沒有」，而是「在哪」。欄位在列表頁可見，一次請求能拿幾十筆；只在詳情頁可見，就得逐筆點進去，請求量差一到兩個數量級。測試會明確告訴你每個欄位屬於哪一種，以及這對成本意味著什麼。
二、實際可擷取筆數
不是目標網站上有多少，是我們實際能穩定拿到多少。
這兩個數字經常差很遠。多數平台對單次查詢的結果數量有上限，超出部分無法透過繼續翻頁取得，必須依地區、類目或時間段把查詢拆成很多次再合併去重。測試會跑通一次完整的拆分邏輯，據此估算涵蓋率和總工作量。
三、欄位完整率
每個關鍵欄位有多少比例是空的。
這一項決定了數量預期是否現實。如果你要求名單裡每一筆都必須有網站和電話，而目標平台上這兩個欄位的填寫率只有一半左右，那麼要拿到一萬筆合格資料需要處理的原始資料遠不止一萬筆。完整率是平台的客觀情況，不會因為多花錢而提高，所以必須在報價前對齊，而不是交付時才發現。
四、結果穩定性
同樣的請求重複跑，結果是否一致。
有些平台的搜尋結果存在個人化或隨機波動，同一條件下兩次擷取拿到的集合並不完全相同。如果專案需要做週期性比較，這個波動幅度必須先測出來——否則後續每一次資料變化，你都分不清是市場真的變了，還是平台本身在抖。
五、服務邊界
需要的內容是不是真的無需登入即可瀏覽，資料類型有沒有涉及個人資訊，目標平台的條款有沒有明確限制，最終用途屬不屬於我們不承接的範圍。
這一項和前四項不同：前四項決定成本，這一項決定做不做。任何一條不通過，後面四項算得再準也沒有意義。
測試之後你會拿到什麼
- 一份結論：每一項分別是什麼情況，哪些能做、哪些做不到、為什麼
- 一份範例資料：依實際欄位結構跑出來的真實結果，不是虛構佔位
- 一份基於實測的報價：不是估算，是依測出來的工作量算的
如果結論是這個需求不值得做，我們會直接說，並指出是哪一項卡住的。這份結論無論是否合作都歸你——你拿著它去找別家，至少知道該問什麼。
什麼情況下結論會是「別做」
- 需要的核心欄位只有登入後才可見
- 單次查詢上限很低而目標涵蓋範圍很大，拆分成本遠超資料本身的價值
- 關鍵欄位的缺失率高到剩餘資料無法支撐原定用途
- 目標網站結構頻繁變動，規則維護成本高於資料帶來的收益
- 資料用途本身處在我們不承接的範圍內
前四種我們會說明成本結構，由你判斷值不值得。第五種直接拒絕。
一個常見誤解
測試資料不是小批量交付。
測試的樣本量很小，欄位口徑可能還沒最終確定，去重規則也還沒跑完整。它的用途是回答能不能做，不是拿去進業務流程。見過把測試樣本直接匯進系統然後得出錯誤結論的情況，所以這裡單獨說明一次。
正式交付的資料會附完整的欄位說明、完整率統計、去重規則和已知限制——那些在測試階段都還沒定型。
測試是整個專案四個步驟裡的第二步，前後各步的產出見關於我們裡的流程說明。