各卡组织测试号段：Visa、Mastercard 与美国运通

做支付相关的测试时，一个很常见的偷懒做法是：随便找一张能用 16 位的号码，在所有场景里反复用。它通常能跑通，也因此掩盖了问题。等到接入运通卡或银联卡的真实用户时才会发现，前端的输入框宽度、后端的长度白名单、甚至校验位以外的字段规则都和你想象的不一样。按卡组织分别准备测试号段，就是为了避免这种延迟暴露。

这篇文章把公开的号段区间整理成一张可对照的表，并说明每一段值得测什么。

卡组织在号码里留下的痕迹

一家卡组织的号码能一眼辨认，靠的是两处公开约定：首位数字落在哪个区间，以及允许的总长度是多少。两者结合起来，就构成了这家卡组织的「形状」。

这些约定写在公开的编号方案里，因此你可以放心地按区间描述号码，而不用记住任何具体账户。需要强调的是，从号段只能读出「这串数字被设计成哪家卡组织的号码」，读不出它属于谁、是否存在、是否还能用。

卡组织之间最实在的差异有四处：

• 前缀区间，决定这串号码被归到哪家。
• 总长度，各家并不统一。
• 安全码位数与位置，多数是背面三位，运通是正面四位。
• 是否存在额外的校验规则，例如某些卡组织对号段内部还有更细的划分。

第二和第三点最容易在实装时被漏掉，因为它们不会在成功路径上暴露。

为什么一套号码不能通用

把同一张号码从一家卡组织的场景搬到另一家，是测试里最省事也最容易出错的偷懒做法。原因在于前面那份差异清单：长度不同会让按位数判断的逻辑走错分支，安全码位数不同会让输入框宽度错误，前缀不同会让卡组织识别返回空值。

这些错误在测试环境里往往表现为「看起来能用」，因为单纯的表单校验并不会抱怨这些差异。它们真正暴露的时机，是某天有真实用户拿着那家卡组织的卡来下单——前端的输入框拦住了他，而后端返回了一条没人见过的错误。

所以结论很直接：卡组织之间不能互相替代。测试数据必须按网络分别准备，即使你只上线一种支付方式，也要确认其他网络不会把你的流程弄坏。

公开号段对照

下面这张表按卡组织整理了公开可查的前缀区间与长度。把它当作测试数据的选号地图使用：

表里的长度写的是常见值，不是唯一值。同一家卡组织在不同时期发行的号码长度可能不同，这也正是「不要按长度写死」这条建议的来源。

使用这张表时有一个前提要记住：区间描述的是公开的编号方案，而不是某一家银行的发行清单。从一段前缀能读出它被设计成哪家卡组织的号码，读不出它的发卡机构，更读不出任何账户信息。因此不要在这张表上做超出编号规则的推断。

哪个号段最值得单测？

如果测试时间有限，优先覆盖这几个：

• 15 位的那一家。它是唯一一个「长度不是 16」的常见例外，能一次性验证你所有按长度写的硬编码是否安全。
• 安全码四位的那一家。它能验证输入框宽度是否真的随卡组织变化。
• 前两位相同但需要区分区间的号段（例如 51 至 55 与 2221 至 2720 同属一家）。它能验证你的号段匹配是不是只做了粗略的首位判断。
• 14 位的那一家。它比 15 位更极端，常被遗漏在长度白名单之外。
• 同时支持多种长度的那一家。它能验证你的长度集合判断逻辑是否只是一条范围比较。

把这五个场景准备成固定的几组号码，就足以覆盖绝大多数「按卡组织分支」的代码路径。

一条常见误解：号段能证明什么？

需要反复强调的是：一段落在某卡组织公开区间里的号码，只能说明它被设计成了那家卡组织的形状。它不说明这张卡存在，也不说明任何机构发行过它。

围绕号段还能衍生出更深的误解，比如「前几位能看出是哪家银行」。发卡行识别号确实由公开方案分配，但把它映射到具体的发卡机构需要权威的对照数据，而且映射关系会随时间变化。因此，在代码里硬编码「某段前缀等于某家银行」是一件很容易过期的事。

对测试来说，坚持一个原则就够了：只按公开的卡组织号段选号，不对发卡银行做任何断言。

在本站按卡组织生成号码

在信用卡号生成器里，卡组织是可以指定的。选定之后生成的号码会落在对应卡组织的公开号段内，并按该卡组织的常见位数补足，因此可以一次备齐上面说的几种例外情况。

如果手上已经有了部分前缀，卡号补全模式更合适：把已知段填进去，用占位符标出待补的位置，其余位会按该号段的规则补齐。批量生成多张、再批量复制，能省下手工拼测试数据的时间。

所有生成内容都是合成数据：结构上合法，但从未发行给任何人，也不属于任何账户。它们适合灌进测试数据库或联调页面，不能用于任何真实交易。

给开发者：按卡组织准备测试矩阵

把测试数据组织成矩阵，比按号码逐个维护更不容易漏。建议的行是卡组织，列是关注点：

• 长度分支：每个卡组织至少准备该组织允许的最短与最长各一个。
• 长度例外：单独标记出 15 位与 14 位的那几家，确保它们在白名单里。
• 安全码位数：为四位的卡组织准备一条端到端用例，验证输入框和校验都跟着变。
• 前缀边界：号段区间的起点与终点各准备一个，例如区间下限与上限。上下限两侧各一个「刚好落在区间外」的号码，用来确认匹配逻辑没有写成开区间。
• 应当被拒绝的号码：前缀落在未分配区间、长度正确但校验位错误、以及看起来像但少一位的号码。挑选方法见测试信用卡号是什么。

命名建议直接体现卡组织与关注点，例如「运通的前缀边界上限」，而不是用编号。矩阵准备好之后，把它连同期望结果一起纳入回归，这样将来有人调整长度白名单或号段表时，失败的是测试而不是线上。

另外提醒一处容易过度设计的地方：不要把号段表做得过细。卡组织的公开区间本身就是会调整的，你维护得越精细，需要更新的地方就越多。够用即可——能识别出主要卡组织、能让分支测试跑起来，就已经达到目的。更细的校验顺序问题见校验信用卡号。

下一步

先补上你缺的那两个分支：15 位的卡和四位安全码的卡。它们能暴露的问题，比再多准备几张 16 位号码要多得多。

需要现成的号码来填矩阵，用信用卡号生成器按卡组织批量生成；想弄清号段是怎么划分出来的，读信用卡号格式。