在 E2E 测试中使用生成身份（Playwright 与 Cypress）
走完注册、开通或结账流程的端到端测试，会在真实后端里创建真实记录，而后端执行的正是生产环境的那套规则：邮箱必须唯一、重复订单会被拒绝，于是昨天全绿的用例今天就报"账号已存在"。可靠的解法是让每次运行都用一个全新的一次性身份——被测系统从未见过的生成姓名、邮箱、地址和电话。
本文汇总了在真实 Playwright 与 Cypress 套件中行之有效的模式：并行 worker 之间如何保证邮箱唯一、确定性数据与随机数据如何取舍、用导出的夹具文件还是运行时内联生成，以及如何清理测试留下的账号。
为什么注册与结账流程需要每次都用新身份
复用同一个邮箱的注册用例只会绿一次：第二次运行时邮箱唯一性约束就会拒绝注册，用例因为与被测功能毫无关系的原因失败。结账流程的问题更隐蔽——很多后端有幂等逻辑，会悄悄合并同一客户的重复订单，重跑时你断言的那笔订单可能根本没有被创建。
并行执行让情况雪上加霜。Playwright 默认把用例分片到多个 worker，Cypress 在 CI 中并发跑 spec，两个 worker 同时去用同一个硬编码身份就会中途相撞：一个注册成功，另一个报重复错误，而且失败位置每次都不一样——这正是"不稳定用例"的定义。按用例、按 worker、按运行分配全新身份，能整类地消灭这些问题。
让邮箱唯一的三种方法
最轻量的是加号别名（plus-addressing）：多数邮件系统会把 qa+anything@yourteam.dev 投递到 qa@yourteam.dev，套件只要在加号后面拼上运行标识，就能得到无限多的唯一地址，且全部落在你掌控的同一个收件箱里——需要真正接收验证邮件时非常合适。注意有些校验器（偶尔恰好就是你在测的那个）会拒绝加号，这本身就是值得抓住的 bug。
如果不需要真实投递，时间戳后缀是最简单的唯一性保证：用基础名加测试启动时的毫秒时间戳拼出邮箱前缀。并行运行时再加上 worker 前缀——Playwright 提供 worker 序号，Cypress 可以从 spec 名或 CI 任务 ID 派生——即使两个 worker 在同一毫秒启动也不会撞车。基础名 + worker 前缀 + 时间戳三者组合，得到的地址既唯一、可追溯到具体一次运行，之后还能按模式批量清除。
确定性还是随机？固定种子并写进日志
随机身份能扩大覆盖面：O’Brien 里的撇号、带连字符的姓氏、三十个字符的街道名，迟早会暴露固定值永远测不出的 bug。但危险在于断言悄悄依赖了随机值——生成随机姓名后再断言它在用户列表中的字母序位置，通过与否完全取决于抽到了哪个名字。这就是伪装起来的不稳定用例。
解法是随机种子。所有正经的数据库都支持传入种子，固定种子的运行每次都产出完全相同的身份，"无法复现"就变成了普通的调试。推荐做法：CI 里默认固定种子保证可复现，另设一个用随机种子的定时任务去探索边界，并且始终在运行开始时把种子打进日志，任何失败都能重放。同时把角色分清——必须变化的字段（如邮箱）单独叠加唯一性，断言真正依赖的字段保持确定。
导出夹具文件还是运行时内联生成
把生成器导出的 CSV 或 JSON 放进夹具目录有实打实的好处：数据能在 PR 里被审阅、在所有机器上一致、零运行时依赖——Cypress 原生加载 JSON 夹具，Playwright 一个 import 就能读。弱点在唯一性：静态邮箱第二次运行必挂，所以常见做法是从夹具加载稳定的档案字段，运行时再给每条记录盖上一个全新的唯一邮箱。
用库内联生成则每次都是新数据、可按用例精细控制，代价是多一个依赖。很多团队最终采用混合方案：需要审阅的场景化数据用导出夹具，一次性的批量数据内联生成。无论哪种方案都有一条铁律：生成的卡号虽然通过 Luhn 校验，只能用来测输入掩码和客户端校验，绝不能发给支付网关——支付集成测试必须在支付服务商的沙箱环境里，使用其官方公布的测试卡号。
用日、德、法身份把同一套用例再跑一遍
身份一旦来自生成器，切换地区就只是改一个参数——而这个参数是性价比极高的捉虫工具。日文身份能端到端地暴露编码问题：汉字在表单里没事、进了数据库却成乱码，或者姓名顺序假设把姓和名渲染反了。德文身份考验布局：超长的复合街道名会撑爆定宽栏、在确认邮件里被截断。法文身份则把重音字符送进姓名和邮箱字段，粗糙的正则校验器经常直接拒绝。
实践上，把套件在一个小的地区矩阵上参数化，作为单独的 CI 任务运行。你不是在翻译测试——断言原封不动，只是把不同的身份灌进同样的流程。正因如此，它找到的 bug 修起来便宜，发布出去却很丢人。
清理账号，并让测试用户远离版本库
每次全绿都会留下账号，堆积了成千上万陈旧测试用户的预发布数据库迟早自己出问题：查询变慢、分页断言失效、分析数据被假注册污染。清理时优先在 afterEach 或全局 teardown 钩子里走 API 或直接清库，而不是在 UI 里点删除账号——又慢又可能自己失败。更好的做法是让套件指向一个专用测试租户，由夜间任务整体清空；前文的 worker 邮箱前缀正好让按模式批量清除变得轻而易举。
最后，凡是带凭据的测试身份都不要进版本库。一份姓名地址夹具无伤大雅，但提交上去的密码或看起来很真的 API key 不行，密钥扫描器也会正当地报警。测试账号密码通过环境变量或 CI 密钥库注入，本地导出的身份文件加进 gitignore，更不要"借用"真实客户记录当夹具——生成身份存在的意义，就是让你永远不必这么做。
常见问题
可以用生成的卡号做支付测试吗？ +
只能做 UI 层面的检查：输入掩码、Luhn 校验、按首位数字识别卡组织。这些卡号不关联任何账户，任何真实网关都会拒绝。凡是要打到支付服务商的集成测试，必须使用其沙箱环境和官方文档里的测试卡号。
默认该用随机数据还是固定数据？ +
断言依赖的一律固定，其余随机。CI 用固定种子保证失败可复现，另设随机种子的定时任务去挖边界情况，并始终把种子打进日志，任何发现都能重放。
并行 worker 怎样避免创建同一个用户？ +
给每个 worker 独立的命名空间。Playwright 提供可拼进邮箱前缀的 worker 序号，Cypress 可以用 spec 名或 CI 任务 ID。再叠加时间戳后缀，即使多个任务同时启动，冲突也几乎不可能发生。
每次运行后都必须删除测试账号吗？ +
不一定每次都删，但必须有明确策略。专用测试租户加定时整体清空最不容易出错；逐用例走 API teardown 最干净。真正会出事的是毫无计划，任由预发布环境堆积测试用户，直到不相干的用例开始超时。