在金融科技、電商、政府專案做 QA,大量資料測試是日常 — 但用真實資料測試在 GDPR / 個資法下是違規的。這篇講為什麼需要假資料、台灣官方校驗演算法怎麼算,以及這些資料在 QA 流程的真實應用。
為什麼一定要用假資料(合規面)
台灣個資法第 6 條明確規定:個人身分證字號屬於敏感個資,非經本人同意不得蒐集、處理、利用。內部開發 / 測試環境若使用真實身分證號(即使是員工的),被稽核出來就是違規。
實務上:
- 金融業 QA:KYC 流程測試需要大量身分證,不能用真的 → 必須產合法格式的假資料
- 電商:會員系統壓測 1 萬筆假帳號,身分證要過格式驗證
- 政府 / 醫療 API 整合:沙箱環境需要過格式檢查的測試資料
- 風控規則測試:模擬不同年齡 / 性別 / 地區的客群
重點:假資料要「格式合法」(過得了驗證器),但內容是假的(對應的真人不存在)。
台灣身分證演算法(內政部官方公式)
10 碼:[A-Z] + [12] + 8 個數字。
步驟:
- 字母對應:A=10、B=11、C=12…I=34、O=35、X=30、Y=31、Z=33(I/O 跳出順序是歷史原因)
- 把字母拆成兩位數
N1 N2 - 加權公式:
N1 × 1 + N2 × 9 + d1 × 8 + d2 × 7 + d3 × 6 + d4 × 5 + d5 × 4 + d6 × 3 + d7 × 2 + d8 × 1 - 校驗碼 =
(10 - 加權和 mod 10) mod 10 - 第 2 碼:1 = 男、2 = 女(新住民會用 8、9,本工具不產生)
例:A123456789,A → 10、9 → 18(權重 1+9)、123456789 加權 → 總和 % 10 → 應為 0 才合法。
統一編號(8 位)的官方規則
8 位數,加權 [1, 2, 1, 2, 1, 2, 4, 1]。
演算法:
- 每位數乘對應權重
- 若乘積 ≥ 10,個位與十位數相加(例:7 × 2 = 14 → 1 + 4 = 5)
- 全部相加得 sum
- 若 sum mod 10 == 0 → 合法
- 特殊情況:若第 7 位是 7,則 (sum + 1) mod 10 == 0 也算合法
這個第 7 位是 7 的特殊規則,是國稅局歷史上為了避免亂碼撞號加的。自己寫驗證器一定要記得這條,否則會誤殺合法統編。
本站 TW 測試資料工具 的演算法跟國稅局官方一致,可以直接拿去過大多數驗證器。
Luhn 信用卡演算法(全球通用)
Luhn 是國際信用卡產業通用的校驗碼演算法,Visa / Mastercard / JCB / Amex 都用。也用在 IMEI、加拿大社會保險號等。
步驟(從右往左):
- 最右一位是校驗碼,先放著
- 從右二開始,每隔一位數字 × 2
- 若 × 2 後 > 9,減 9(等價於個位 + 十位)
- 所有數字(含校驗碼)相加
- 總和 % 10 == 0 → 合法
例:4532015112830366
4 5 3 2 0 1 5 1 1 2 8 3 0 3 6 6
×1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 (從右算 — 校驗碼這位是 ×1)
Stripe 測試卡號:4242424242424242(Visa)、5555555555554444(Mastercard)— 這些都過 Luhn 但都是專門的測試號碼,Stripe 不會真的扣錢。
QA 真實使用場景
我在金融科技 QA 工作中,這些假資料每天都用:
- 開戶流程壓測:產 10000 筆過驗證的身分證 + 統編 + 信用卡,用 JMeter / k6 跑開戶 API
- 風控規則回歸測試:用不同性別 / 地區字母的身分證,確認規則沒誤判
- 海外用戶 onboarding:測新住民身分證(2 開頭非 1/2)走特殊流程的分支
- 信用卡綁定:測 Visa / Master / JCB 不同卡頭的 BIN 識別邏輯
- 資料庫 seed:測試環境一開機,seed 100 筆假帳號讓 QA 跟 PM 進去 demo
重要:tw-test-data 工具上的資料僅供格式測試,不要拿去申辦業務、開戶、註冊真實服務 — 那就變偽造文書。
立刻試:用 TW 測試資料工具 產 100 筆身分證,把結果丟到你公司的驗證器,看是否 100% 通過。