年龄验证测试：门槛从哪来，边界日怎么测

年龄验证测试最容易写成走个形式：拿一条明显成年的记录跑一遍，看到页面放行，就认为这个功能没问题。真正决定成败的是门槛前后那一天，以及出生日期本身是否可信。本文把门槛的来源、自报与核验的差别、以及闰日与跨时区这两类边界讲清楚，读完你能给自己项目的年龄限制列出一份能落地的用例清单。

常见的年龄门槛是从哪来的?

年龄门槛不是一个统一的数字，它来自不同的规则与场景，彼此之间没有换算关系。十三岁这个门槛通常与儿童在线服务的家长同意要求有关；十六岁出现在一些地区对信息类服务默认同意年龄的规定里，并且允许各成员在一定区间内自行调整；十八岁是多数地区的成年年龄，涉及合同与多数受限行为；二十一岁则出现在少数地区针对酒精等特定商品的场景中。

理解了来源的分散，就能理解为什么不能把这些数字合并成一条全局规则：同一个产品在不同地区、不同功能上，门槛可能不同，而且随时间还可能调整。把它们做成配置项而不是散落在代码里的常量，是唯一能让后续变更不至于失控的做法。

自己填的生日和证件核验差在哪?

用户自己填写的出生日期是一种声明，它没有任何外部依据，随时可以被填成任何值。证件核验则是把声明与一份外部材料比对，成本高得多，也只在必要时才值得引入。两者在测试里的行为完全不同：前者要验证的是流程能否正确读取并解释这个日期，后者要验证的是核对环节收到不符合的结果时该怎么处理。

把这两件事混在一起，是很多年龄限制形同虚设的原因：系统以为自己在核验，实际上只是在读一个用户可以随手改的字段。测试用例如果把「填了成年生日就能通过」当成核验成功的证据，会掩盖掉整条核对链路缺失的问题。

边界日该怎么测?

围绕任何门槛，真正需要跑的是三档数据：刚好满岁的那一天、差一天的那一天、以及刚过多一天。中间那些远离门槛的值无论怎么测都不会暴露逻辑错误，反而会让人误以为覆盖面已经足够。

这三档还要叠加另一个维度：判定基准是哪一天。年龄由「今天」减去出生日期得出，而「今天」在不同时区可能不是同一天，所以在服务端与客户端分别计算的系统里，门槛前后的记录会在某个时间段内得出不同结论。测试如果不覆盖这个窗口，线上就会看到用户说「我明明已经够了」而系统拒绝。

闰日出生的记录是第三类边界。平年里这类用户在前一年的二月没有对应日期，一些体系约定以二月二十八日计算，另一些以三月一日计算。两种口径都会有人采用，因此这不是代码问题而是规则问题，需要产品明确决定并写进用例。

为什么不能只存一个「是否成年」的标记

把判定结果存成一个布尔值看起来省了计算，代价是它会随时间失真。今天未成年的用户明天可能已经满岁，如果系统只在注册时算一次并永久保存，这个标记就会在生日当天开始出错，而这个错误没有任何机制会主动发现。

更耐用的做法是存出生日期本身，在需要的时候实时计算。这样规则改了、门槛变了、时区基准调整了，都不需要回头批量修数据。如果出于性能考虑确实要缓存判定结果，那缓存必须带有效期，并且在生日当天必然失效。

哪些年龄档必须各测一遍?

一个常见的偷懒做法是只准备一条「明显成年」的记录，用它跑所有与年龄相关的用例。这条记录确实能让流程走通，但它证明不了任何判断逻辑，因为无论门槛是多少，它都会落到同一个分支里。

合理的做法是按门槛把数据分成若干档：门槛以下的、刚好达到门槛的、以及明显超过的。如果产品在多个地区有不同门槛，那每一档都要按门槛重新划分——同一条记录在一个地区是成年、在另一个地区可能还不够。这类分档数据看起来简单，却能在规则调整时立刻告诉你哪些用例需要跟着改。

还有一类容易被忽略的档位是「接近但没有记录」。出生日期为空的用户、填写了明显不合理日期的用户、以及拒绝提供生日的用户，都会走到与普通用户不同的分支上。这些分支很少被覆盖，一旦缺失，线上遇到的第一位这类用户就会看到报错页。合成数据只用于测试与演示，不代表任何真实的人，也不能拿它去通过真实的年龄或身份核验，这一点与数据本身属于哪一档无关。

给开发者：把门槛与计算方式都做成可配置

第一，门槛按地区与场景分别配置，不要写死在判断语句里。用一张配置表描述「哪个地区、哪个功能、门槛多少」，新增规则时只改配置。

第二，年龄计算按日进行，不按年份相减。把计算函数集中到一处，服务端与客户端共用同一套口径，避免同一个用户在两个界面上得到不同答案。

第三，明确写出判定所用的时区，并在测试里固定这个基准。跨时区的时间窗口值得专门造一条用例。

第四，边界数据按「差一天、当天、过后一天」各准备一条，并额外准备闰日记录、刚好跨过门槛的年份记录、以及出生日期为空的记录。这些记录里的出生日期是程序生成的，只用于验证判断逻辑；它们不代表任何真实的人，也不能被拿来当作年龄或身份证明去通过核验、开户或者购买受限商品，两者的界限在任何场景下都不该模糊。

第五，为规则变更留一条回归路径。门槛调整时，最怕的是有一批历史数据已经带上旧结论。把计算保留在读取时进行，这类问题会自动消失。出生日期本身的边界处理见出生日期校验的边界，测试数据的组织方式见测试固定装置。

下一步

要一份覆盖到门槛前后的测试数据，去身份信息生成器生成一批不同年龄档的记录，再按上面那三档各补一条手工样本；这些数据仅供测试，不能用来通过任何真实的年龄或身份核验。