年齡驗證測試怎麼做？門檻、邊界日與閏日出生

年齡驗證測試最容易通過的部分是判斷式，最容易出錯的是邊界：剛好滿、差一天、生日當天，以及閏日出生的使用者。以下說明常見門檻的來源、自我填報與文件查驗的差別，以及要怎麼設計測試資料才不會漏掉真正會出錯的那一天。

常見門檻是從哪裡來的

常見的幾個數字各有自己的背景。十三歲與兒童線上隱私保護有關，十六歲是部分地區對資訊服務同意年齡的預設值，十八歲是多數地區的成年年齡，二十一歲則出現在少數特定情境。這些數字的來源不同，適用範圍也不同。

把它們合併成一條規則是最常見的錯誤。同一個服務在不同地區可能要適用不同門檻，甚至在同一個地區，不同功能也可能適用不同年齡。系統應該把門檻當成可設定的參數，而不是一個放諸四海皆準的常數。

還有一種錯誤是把門檻當成資料的一部分。門檻會隨法規與產品調整，一旦寫進資料庫或測試樣本，調整時就會留下大量過時的值，而且沒有人知道哪一份是對的。

自我填報只證明使用者輸入了某個日期，不證明那是真的。它的價值在於取得同意與區分內容，缺點是很容易被繞過，因此不該被描述成「已驗證年齡」。

文件查驗則試圖確認生日與本人相符，通常需要讀取證件、比對照片或透過其他機制確認。它的門檻高得多，也牽涉更多個人資料的處理，因此在設計時要一併考慮最小化與保存期限。

測試時兩條路徑要分開準備資料。自我填報的測試重點是邊界與格式，文件查驗的測試重點是失敗情境：證件過期、格式不支援、生日讀不出來、使用者中途放棄。把所有情況混在同一組樣本裡，通常兩邊都測不完整。

因為「滿了沒」的答案每天都可能不同。同一個生日，今天差一天、明天剛好滿，如果測試只跑一次，就只驗證了其中一種結果。真正會出錯的是那些只在特定日期才成立的組合。

年齡也不該用年份相減來算。以年為單位相減會讓十二月底出生的人提前「滿歲」，也讓閏日出生的人在某些年份得到不一致的結果。正確的做法是以整日為單位比較，先算出「今天」與生日之間的差距，再判斷是否達到門檻。

「今天」本身也需要明確定義。伺服器所在時區、使用者所在時區與資料庫儲存的時間可能不同，當三者跨過午夜時，同一筆資料在不同環節會得到不同年齡。這類問題通常只在少數時間點出現，因此更難被發現。測試若固定在一天中的某個時刻執行，可能永遠遇不到跨日的那一刻；把判斷邏輯抽出來單獨驗證，比依賴真實時間可靠。

閏日的處理沒有唯一答案，重點是選定一種並全系統一致。常見作法是在非閏年把生日視為二月二十八日或三月一日，兩者對「哪一天滿歲」的答案不同；若前後端各選一種，使用者在生日前後會看到矛盾的結果。

判斷某一年是否為閏年也有規則：能被四整除，但整百年必須能被四百整除。因此有些整百年不是閏年。若程式用簡單的除法判斷，會在這些年份出錯，而測試若沒有涵蓋，就不會有人發現。

測試資料應該明確包含閏日出生的樣本，並在閏年與非閏年各跑一次。單純加一筆閏日生日但不檢查換算結果，等於沒有測到任何東西。想把這類日期問題一次看清楚，可以先讀出生日期邊界。

本站的身份產生器可以依國家與年齡區間產生對應的生日，方便一次造出整組邊界樣本；這些資料只供測試與示範，不能用來冒充真人，也不代表能通過任何實名或年齡查驗。樣本該怎麼固定下來，可以參考測試固定裝置裡的身份資料與可重現的測試資料。

因為改動的成本會落在最不該承擔的地方。當門檻散落在多個判斷式中，任何調整都要重新搜尋、逐一修改並重新驗證，出錯的機率隨著出現次數增加。集中成一處設定，改動才可能被一次檢查完。

設定化還有個額外好處：測試可以直接針對不同門檻跑同一組樣本，而不必為了每個數字複製一份測試。要驗證的邏輯因此減少，覆蓋的組合反而變多。

另一個值得一試的做法是讓門檻帶上生效日期。當規則改變時，已經發生的判斷結果不該跟著變動，回頭查詢時也才看得出當時適用的是哪一個版本；否則同一筆紀錄會在改版之後忽然得到另一種結論，排查問題時完全無從還原。設定集中之後，這件事只需要在一個地方處理。

一個年齡驗證流程的品質往往取決於失敗路徑，而不是成功路徑。當使用者填不出正確的生日、證件讀取失敗，或年齡剛好落在門檻附近時，系統該提供什麼選擇、能不能重試、會不會留下誤判紀錄，都需要事先設計。

最常見的問題是過度阻擋：規則寫得比法規更嚴，年齡明顯足夠的使用者也被拒絕，而且沒有申訴管道。測試時應該準備一批「應該通過卻很容易被誤擋」的樣本，例如生日落在邊界前後，以及日期格式符合當地慣例的輸入。

紀錄也需要節制。為了調查誤判而保存完整的證件影像，往往超出原本的目的；只留下判斷結果與發生時間，通常就足以排查問題。保留越多，後續要保護與刪除的東西也越多。

先找出系統裡所有判斷年齡的地方，確認它們用的是同一個時區與同一種算法；再把門檻集中到一處設定，並用剛好滿、差一天與閏日三組樣本各跑一次。任何一組得不到預期結果，就代表邊界還沒處理完。