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