拓十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

多国表单测试数据实践:86 国地址、证件与银行卡的自洽性,以及可复现的种子

多国表单测试数据实践:86 国地址、证件与银行卡的自洽性,以及可复现的种子 做多语言产品表单测试最后往往卡在同一件事上数据。不是没有数据而是手边编出来的数据经不起看。下面三个场景我都在实际项目里遇到过。三个具体的卡点一、日本地址。你随手编一个「东京都 123-4567」能过格式校验但把行政区换成大阪府邮编段就未必成立了 —— 日本的邮政编码分段与都道府县是对应的。测试用例本身不成立排查时却会先怀疑接口。二、证件号。巴西 CPF、西班牙 DNI、土耳其 T.C. Kimlik No 都有官方校验位算法末位数字DNI 是字母由前面的字符算出来。随手编的数字串必然过不了校验测试会直接死在格式校验那一步而且看起来「很像是代码有问题」。三、有的国家根本没有邮编。阿联酋和卡塔尔没有邮政编码体系。如果造数时默认「每个国家都有 postal code」这个分支就永远测不到直到线上表单在这两个市场卡住必填项。这三件事的共同点是难点不在生成随机值而在生成之后这些值彼此还得成立。一、造数的难点是「不变量」不是随机性faker 这类库解决的是「让每个字段有值」它不解决「让字段之间成立」。真正难的是这些不变量城市、一级行政区、邮编三者必须互相一致年龄必须与出生日期一致身高与体重必须是一组解剖学上合理的搭配证件号的格式因国而异且很多带校验位某个字段在该国是否应该存在血型在日本、德国的资料里出现法国不记录族裔信息美国、巴西采集瑞典没有。最后一条最容易被忽略但它恰恰是 i18n 表单里最值钱的一类测试分支条件必填、字段隐藏、默认值。二、我为此做的工具先说清楚下面这个工具是我自己使用AI做的这些机制部分全部由AI来进行分析与实现包括它哪里是真校验位、哪里只标「仅格式」。如果你只想要自己造数时的检查清单可以直接跳到第 7 节。临时工 / Tempyardwww.tempyard.com是一个纯前端的合成身份与地址数据生成器纯前端没有后端不需要注册生成过程全在浏览器里完成数据不出设备覆盖86 个国家和地区、12 种界面语言简繁中文、英语、日语、韩语、葡语、西语、土耳其语、印尼语、越南语、泰语、俄语八个工具身份生成器、地址生成器、信用卡号生成器、临时邮箱、公司信息生成器、职业信息生成器、校验工具、格式大全数据规模1999 个一级行政区、13746 个城市。数据来源值得单独列一下因为「看起来像的地址」和「真实存在的行政区划」是两件事来源许可用途GeoNamesCC-BY 4.0行政区划、城市、邮编、时区dr5hn/countries-states-cities-databaseODbL 1.0区县级地名以及 GeoNames 截断的完整邮编OpenStreetMapODbL 1.0上述两者都未覆盖的国家/地区的邮编faker-js/fakerMIT姓名池构建期预编译Unicode CLDRUnicode License v3国家、语言、货币的显示名三、机制一可复现 —— 用「身份 KEY」把一条记录钉住这是我觉得对测试最有价值的一点。工具的全部随机取值由一个 32 位种子驱动种子用 base36 编码成一个短串界面上叫「身份 KEY」形如kj3f9。记录是三个输入的纯函数记录 f(国家, 性别, 身份KEY)所以同一个 KEY 相同国家 相同性别必然重新生成完全一致的记录换一个 KEY 就是另一个人。它同时可以被 URL 深链复现参数是?s身份 KEY和?c国家代码https://www.tempyard.com/identity/?skj3f9cJP # 日本记录kj3f9 是示例 KEY换成你自己的 https://www.tempyard.com/identity/?skj3f9cBR # 同一个 KEY换成巴西为什么这对测试重要断言可以长期保留。用「每次都不一样」的数据你只有两个选择 —— 把值写死进 fixture然后它和生成器脱钩下次就过期或者每次重跑都重新适配断言。固定种子之后同一条记录随时能重开报 bug 时把 URL 贴给对方就行。在自动化测试里怎么用批量导出里每一行都带自己的 seed于是两种用法都成立按 fixtures 跑推荐或者按 KEY 深链重开单条记录。import{test,expect}fromplaywright/test;import{readFileSync}fromnode:fs;// fixtures/jp-records.json 来自站内的「批量生成与导出」JSON 格式// 每行形如 { country: JP, seed: …, postal: …, state: …, city: …, … }constrecordsJSON.parse(readFileSync(./fixtures/jp-records.json,utf8));for(constrofrecords){test(结账表单 / 日本 /${r.seed},async({page}){awaitpage.goto(/checkout);awaitpage.fill([namepostal],r.postal);// 邮政编码awaitpage.fill([namestate],r.state);// 一级行政区awaitpage.fill([namecity],r.city);// 城市awaitpage.click(button[typesubmit]);awaitexpect(page.locator(.field-error)).toHaveCount(0);});}列名就是界面上的字段名导出与界面所见一致不用另建一套映射。四、机制二一次导出四种格式以及三个值得抄的工程细节批量生成后可以导出成四种格式对应四种消费方式格式用途CSV表格软件 / Excel 打开JSON数组脚本直接读NDJSON一行一个对象流式处理与日志入湖SQLCREATE TABLEINSERT直接灌进数据库实现时有三个细节值得单独说自己写导出功能时可以直接抄CSV 带 UTF-8 BOM。生成的数据里有中日韩、西里尔、阿拉伯字符。不带 BOM 的 UTF-8 CSV用 Excel 双击打开就是乱码而「乱码」通常会被误报成「数据生成有问题」。SQL 里所有列一律TEXT不按内容推断类型。原因很实在某一批的出生年份恰好全是数字类型推断会把它建成整数列下一批出现前导零邮编、电话号码这种就写不进去。这类失败是静默的 —— 数据已经错了但没人报错。列集合取整批记录字段的并集。同一批里混了不同国家时CSV 仍然是矩形不会因为某一行少一个字段就整体错位。-- 导出的 SQL 长这样列取自本批记录的字段并集全部 TEXTCREATETABLEIFNOTEXISTSidentities(countryTEXT,seedTEXT,-- 其余字段姓名、地址、证件号、卡号………);五、机制三校验位是真算出来的算不出来的会明说这部分我建议所有做测试数据的人抄一遍思路。有公开算法的就真的算出来。巴西 CPF、西班牙 DNI、土耳其 T.C. Kimlik No、墨西哥 CURP、智利 RUT 都实现了各国官方校验位算法生成的号码能通过该校验。公司/税号同理法国 SIREN、日本法人番号、中国统一社会信用代码、巴西 CNPJ 由官方算法生成。没有公开算法的明说。有些体系从未公布过校验位算法美国 SSN、印度 PAN以及阿联酋 Emirates ID它的校验位算法并没有官方文档网上流传的说法对不上公开样例。这类字段在界面上标成**「仅格式」**不假装通过。校验工具给的是四态结论而不是一个布尔值校验通过 / 校验失败 /仅格式/ 无规则为什么要单独留「仅格式」这一态把「没有公开算法」含糊地说成「有效」等于替对方作出了它并未作出的承诺说成「无效」又会让人把正确数据退回重填。这个区分对测试数据同样成立 ——一条标着「仅格式」的记录明确告诉你你的测试能证明什么、不能证明什么。如果你导出的测试数据里这类字段被当成「有效」后面的断言就是假的。六、机制四字段本身就是因国而异的前面提过的差异在工具里是显式的血型日本、德国有法国不记录族裔美国、巴西采集瑞典没有护照号本身不含国际校验位所以构造上就是「仅格式」邮编阿联酋、卡塔尔没有邮政编码体系。这些差异对应到业务代码里就是条件必填、字段显示/隐藏、默认值这几类分支。用一个「所有国家同一套字段」的假数据生成器这些分支只能靠人肉想象。七、如果你自己造数这是一份检查清单不变量自造数据时怎么保证行政区 / 城市 / 邮编三者一致不要用三张独立表各自随机从一条真实记录出发年龄 vs 出生日期由生日算年龄不要两边各自随机身高与体重用 BMI 合理区间约束或从同一人群分布里取值证件号校验位实现官方算法没有公开算法的字段里标「仅格式」别让上层误以为已验证字段是否应该存在维护「国家 × 字段」矩阵缺失字段单独走条件分支测试邮编是否存在无邮编体系的国家如阿联酋、卡塔尔要单独处理银行卡号通过 Luhn 取真实 BIN 段卡组织、长度、CVV 规则才自洽可复现用种子 PRNG并把种子随数据一起导出每行一个八、使用边界生成的都是合成数据不对应任何真实个人、住址、账号或证件仅供软件测试、表单演示与数据填充使用。不得用于身份欺诈、冒用他人身份、伪造证件或任何试图绕过实名验证的用途。这一点站内有明确说明也请使用者自己守住。九、小结地址www.tempyard.com临时工 / Tempyard免费、无需注册生成全部在浏览器本地完成建议的试用路径先去校验工具粘一条你手上的号码看结论顺便看清哪些体系只有「仅格式」再去批量生成与导出拿一批固定数据进 fixture如果只需要一个结论测试数据的价值不在「像真的」而在「字段之间成立、且能被复现」。前者让测试跑起来后者让测试留得住。如果你们团队有更省事的造数方案或者踩过上面没提到的坑多语言地址排版、无邮编国家、税号格式欢迎在评论区交流。
返回列表