注册模块这种东西看起来简单测起来想哭。一个注册页面输入框也就那么七八个按钮两三个真正能拿出来写进用例集里的场景轻松超过一百条。我在项目里见过太多测试新手接手注册模块第一反应是这个简单验证一下必填项和格式就行了结果上线后各种注册失败、验证码收不到、账号被重复创建的问题从用户反馈里涌进来才明白这个模块的水有多深。这篇文章不聊虚的就从一个注册模块的完整测试角度把字段级校验、业务规则、安全策略、异常场景一条条拆开来盘一遍顺便把我这几年踩过的坑、排查过的线上问题都倒出来。不管你是刚入门的功能测试还是已经在写自动化用例的测试开发这篇文章都能给你一份可以直接拿去用的测试思路。1. 注册模块测试为什么值得单独较真先聊一个最基本的认知注册模块是整个产品用户链路的起点。注册一旦出问题用户根本走不到登录、走不到主业务、更谈不上留存和转化。从产品质量的角度看注册模块是优先级最高的模块之一它直接决定了用户对产品的第一印象。但恰恰是这个模块在测试资源分配里经常被边缘化。为什么因为从功能表面看注册就是一个表单提交似乎没什么复杂性。这是最大的误判。注册模块真正的复杂度不在于表单本身而在于它涉及的隐性逻辑非常多时间相关逻辑比如验证码有效期、发送频率限制状态相关逻辑比如手机号已注册、邮箱已绑定、账号被禁用安全相关逻辑比如防暴力破解、防批量注册、防数据注入环境相关逻辑比如弱网下提交、请求重试、页面刷新后的状态恢复数据一致性问题比如前端校验通过但后端校验失败、并发请求导致重复创建任何一个环节疏忽都会造成线上事故。所以我一直坚持一个观点注册模块测试必须用全链路测试思维来做而不是把它当作一个普通表单页来测。这里我也顺便给一个测试思路上自顶向下的框架先宏观后微观第一层页面交互正常性字段、按钮、跳转第二层字段校验规则格式、长度、必填、非法字符第三层业务规则验证码、密码规则、协议联动、性别/年龄等业务字段第四层安全规则加密传输、接口防刷、防重、幂等性第五层异常容错弱网、超时、重复提交、后端异常返回测试设计的时候按这五层往下拆保证不会漏。下面我分章节把这五层全部展开每个测试点都配上实际案例和操作建议。2. 字段级测试点注册表单里最容易出幺蛾子的地方2.1 必填项校验别想当然觉得已经测全了必填项校验看起来最简单但实际最容易漏场景。最常见的错误是只测所有字段都不填点提交看提示然后草草了事。正确的做法是对每一个必填字段做组合测试。比如一个典型的注册表单字段有昵称、手机号、邮箱、密码、确认密码、验证码。必填项测试至少要覆盖这些场景所有字段为空点击注册应该每个字段下方都出现对应的提示只填写其中任意几个字段其他必填字段为空验证提示精确到具体字段填完一个字段就清空验证已填写后清空和从未填写是否提示一致移动端的失焦校验与提交时校验是否重复提示或者出现提示后无法自动消失的问题这里说一个我实际遇到过的情况某产品的注册页面在前端用的是整体表单校验点击提交后只弹出一个全局提示请填写完整信息但字段下面没有逐项错误提示。用户看了根本不知道哪里缺了注册转化率掉了一截。后来把校验改成逐字段定位提示后才好转。这个教训说明必填校验不仅要做还要做用户能看懂的校验提示信息本身也是测试点。还有一个高频问题就是必填校验和格式校验的优先级。比如手机号和邮箱都为空时到底先提示哪个如果同时提示文案是否会重叠遮挡不同页面在不同状态下提示顺序是否一致这些都是字段级校验必须明确的需求很多时候并没有现成文档测试要主动和产品确认并把确认结果沉淀成用例。2.2 格式校验边界值和非法输入才是真正的分水岭格式校验是最容易体现测试功力的地方。拿手机号举例很多人测一遍输入11位数字成功输入10位提示格式错就觉得测完了。但真正的边界值和输入类型拆分远比这个复杂。手机号校验的关键测试点至少包括这些11位数字且以1开头不同国家的手机号规则不同这里以国内为例非数字字符混合输入如138-1234-5678前端是否过滤或提示1开头但第二位是无效号码段有的产品只校验位数不校验号段空值、null、超长号码、不支持的特殊字符带有前后空格的输入是否会自动trim再校验在输入框中输入全角数字或科学计数法形式的数据这里特别提一下全角数字这个坑。很多web输入框不做限制时用户从输入法直接打出这种全角数字在手机号格式校验时很容易通过前端正则但到后端入库后后续业务系统识别不一致。发现这类问题唯一的办法就是在测试用例里加入非ASCII半角字符的输入类型测试。邮箱校验的坑就更多了。一个基础但常见的规则是必须包含符号、前有字符、后有域名、域名里有点。在此基础上还要覆盖大小写混合的邮箱系统是否统一转小写存储邮箱包含号、连字符、下划线、点号等合法字符不同正则支持程度不一包含连续两个点号、点号开头或结尾的非法邮箱是否被错误放行超长邮箱通常上限是254字符边界长度和超长边界中文邮箱国际化邮箱域名是否支持比如某些纯Ascii校验会拒绝这些测试点的来源其实都是日常真实的用户输入习惯。用户不会按着产品的字段说明去输入他们可能会复制粘贴带空格的内容、从Excel里拖带格式的文本、手机输入法自动补全后多出字符。所以格式校验的测试数据要按用户最可能怎么输错来设计而不是按标准格式来设计。2.3 长度限制与字符集一个经常被前端后端不一致坑翻的雷区长度限制是注册模块测试中非常容易被遗漏的一类问题尤其是前后端不一致的情况。先说常见的不一致场景前端input限制了maxlength20但后端数据库字段长度是varchar(30)。正常情况下看起来没问题但如果后端接口没有做长度拦截攻击者或者通过接口直接调用绕过前端写入20~30个字符的数据就能造成数据越界。更危险的是前端限制了20后端限制也是20但前端统计的是UTF-8字符数、后端统计的是字节数中文输入时一个字符占3个字节20个中文字符就是60字节直接触发数据库超长报错。测试方法上要注意一类非常经典的问题一个英文字符占1个字节一个中文字符在UTF-8下占3个字节所以长度校验要分别用纯英文、纯中文、中英文混合来测边界。具体的边界测试点包括恰好等于最大限制时提交是否成功超出最大限制1个字符时是否提示错误中文字符、emoji字符、生僻字等是否导致实际长度计算偏差复制粘贴超长文本时字符截断是否有乱码前后端长度校验是否一致通过接口绕过前端校验来验证我想强调一下emoji这个点。很多输入框对emoji的校验是存在问题的因为emoji在Java的UTF-16下可能占2个char在JavaScript里又按不同的迭代方式统计。我遇到过注册昵称输入圣诞老人直接导致后端保存时数据库异常整个注册流程返回500。这个场景平时不会注意但一旦线上用户输入了就变成了真实的线上故障。所以在注册模块的测试点清单中我强烈建议增加一条特殊字符与Unicode安全测试包括emoji、零宽空格、组合字符、从右到左的阿拉伯文、各种引号和破折号特别是中文引号和英文引号混排等输入。这些看似不是核心业务的测试往往能在上线前拦截住最恶心的线上事故。3. 业务与交互流程测试注册不是填完表单就完事3.1 验证码测试时序、频控和失效规则一个都不能少验证码是整个注册模块里业务逻辑最密集的部分没有之一。验证码分为图形验证码、短信验证码、邮件验证码、语音验证码等我重点说最常见的短信验证码。短信验证码测试点的基础清单如下获取成功点击获取验证码后按钮进入倒计时状态倒计时时长通常是60秒是否准确再次获取限制倒计时期间再次点击是否被拦截并给出提示频率限制同一手机号在短时间内重复请求是否触发频控比如同一号码一天最多10次有效期验证未在有效期内提交是否提示验证码过期错误验证码输入错误验证码提交提示信息是否准确剩余错误次数是否有限制正确验证码输入正确验证码提交注册成功后验证码是否立即失效图形验证码与短信验证码联动部分产品在连续多次获取短信验证码后会要求先输入图形验证码这个联动逻辑要单独测前后端验证码校验一致性通过接口直接提交绕过前端提示验证码是否正确校验我认为验证码测试里最难的地方在时序和状态转换。举个例子用户点击获取验证码后页面显示60秒后可重发此时用户刷新页面倒计时是否重置如果重置了用户永远等不到按钮可点的那一天。如果不重置倒计时状态是存在哪里的服务端还是本地缓存这些表面上是前端体验问题背后涉及状态存储方案测试时要刻意去验证。再举一个我实际发现的真实缺陷短信验证码接口没有做单手机号唯一校验。用户在注册A账号时获取了验证码然后切换到另一个手机号注册B账号再用A账号验证码提交B账号的注册请求。后端验证码校验只查验证码本身没有核对该验证码是否属于当前提交的手机号结果导致注册成功。这是一个典型的认证身份与操作主体不匹配问题非常隐蔽但对账号安全来说威胁很大。3.2 密码规则复杂度要求之外还有一层人话逻辑密码字段的测试重点包括密码强度规则、确认密码一致性校验、密码传输加密效果、以及密码找回/登录场景下的回环验证。密码强度规则通常有这么几类最小长度、最大长度、必须包含字母和数字、不能包含空格、不能是连续字符、不能是常见弱密码。各产品的策略千差万别但测试方法类似关键是按规则边界值来设计。这里有一个容易被轻视的测试点密码的可见性切换和粘贴功能。现在很多注册页面都有显示密码的小眼睛按钮方便用户确认输入。测试时要覆盖点击小眼睛密码内容是否可见再次点击是否恢复遮蔽密码框中粘贴内容时是否有异常密码框与确认密码框的内容不一致点击提交时提示是否定位准确密码中出现的敏感关键词是否被明文记录到埋点日志里这个安全问题很多团队都踩过再补充一个回环测试的思路注册模块测试不能只测到注册成功为止还要用注册成功的用户名和密码走一遍登录流程验证注册与登录之间的数据一致性。比如注册时密码设置为abcd1234注册成功后立即用abcd1234登录是否成功用ABCD1234大小写变化登录是否失败密码是否被正确加密存储。只测注册不测登录等于没闭环。3.3 协议勾选、提交按钮与页面联动逻辑协议勾选这块经常被当作一个复选框的简单校验来测但实际上还有很多交互细节。典型的测试点有未勾选协议点击注册是否提示请先阅读并同意用户协议和隐私政策协议文本是否可点击打开打开内容是否能正常滚动到底部协议页面返回后勾选状态是否保持已勾选状态下提交一次失败后勾选状态是否还在有的产品会重置表单导致用户要重新勾选引发投诉协议文案中链接是否可用点击后是否会跳转外链或拉起应用提交按钮的测试同样不简单点击注册按钮后按钮是否变为注册中并禁用防止重复提交注册请求未返回时是否可以重复点击提交注册成功后的跳转时机是立刻跳转还是等接口全部返回后跳转注册失败后前端是否回显错误信息并且按钮恢复可点击状态这里面我印象最深的一个问题是有一个注册页面用户快速双击注册按钮结果创建了两个账号。前端在注册请求发出后并没有立即禁用按钮导致同一用户同时发出两个注册请求。这个问题的修复其实非常简单——按钮提交后立即禁用。但如果在测试阶段没有加入重复提交用例这个问题大概率会漏到线上。后来我在所有涉及提交按钮的用例里固定加入一条连续点击N次提交按钮后面又成功拦截了至少三个其他模块的同类型问题。4. 安全与异常场景注册接口是最容易被人盯上的目标4.1 接口安全测试注册模块的防刷重心在幕后很多功能测试人员测注册只关心页面忽略了一个真相注册接口是互联网产品里被攻击最频繁的接口之一。爬虫注册、批量养号、短信轰炸、撞库、注入测试全都集中在注册和登录这两个入口。所以安全层面的测试点不能省。首先要测的是传输层安全。页面必须是HTTPS加密传输提交的密码和手机号字段在请求体中不应该明文展示。测试方式很简单用抓包工具拦截一下注册请求看看请求体里是否直接出现明文密码。如果出现就要反馈给开发加解密逻辑。这是注册模块最基本的安全底线。其次是验证码接口的防刷能力。短信验证码接口的频控逻辑需要做专项测试同一手机号在1分钟、1小时、1天内分别能获取多少次验证码同一IP在不同手机号之间轮换获取是否能被识别并触发限制验证码接口是否在请求头、请求体中加了来源标识防止被第三方直接调用图形验证码失败次数达到阈值后是否强制重新获取验证码是否正确绑定当前session/会话而不是全局通用这里我提供一个实际案例某产品上线后被黑产盯上了短信验证码接口通过循环调用接口给用户发骚扰短信。原因是接口只做了同一手机号限发次数的限制没有做来源IP和设备标识维度的限制黑产每次换一个手机号继续刷。排查后发现其实后台日志里同一IP在5分钟内请求了上千次验证码接口但因为没有IP维度的限制海量请求全部放行。这个问题如果测试人员有安全意识在测试环境用同一个IP循环不同手机号触发验证码接口很大概率能提前发现。还需要重点关注的是接口幂等性和防重机制。注册请求应该具备幂等性即同一个请求重复发送多次在服务端应该只创建第一个账号后续请求返回该手机号已注册或者直接提示成功但不重复创建。如果后端代码没有做幂等控制并发请求下会出现大量重复账号数据。测试时可以借助接口压测工具或简单地用多线程脚本同时提交注册接口验证数据唯一性。4.2 异常与弱网容错注册卡死这种事一般都栽在这里弱网和异常场景测试是注册模块测试里最考验耐心、同时也最容易被测试计划砍掉的部分。但注册模块恰恰非常需要这一类测试因为用户在地铁、电梯、隧道里注册的场景太常见了。需要覆盖的异常场景包括弱网环境下点击注册请求超时页面是否有友好的loading状态和超时提示网络断开后点击注册是否出现网络异常提示而不是无限等待注册请求发出后断网又恢复网络请求是重发还是终止是否会重复创建账号后端返回500、502等异常响应时前端是否捕获并展示错误信息是否会导致页面白屏后端超时未响应时前端是否有重试机制重试次数是否有上限页面在注册请求进行中关闭再次进入注册时上一请求的影响是否被处理上面这些场景能分清请求发出前断网、请求发出中断网、请求响应前断网三个状态的差别才算把弱网测试测明白了。这里面的核心测试难点是请求发出中断网的处理。请求已经到达服务端但响应没有回来用户看到的是超时就会习惯性地再点一次注册。如果服务端没有做幂等处理第二次点击又创建了账号最后用户激动地发现自己注册了两三个号。这个问题在我看来是注册模块弱网测试中最高频、最严重的一类缺陷。在具体实操中移动端可以使用网络模拟工具来模拟弱网和断网场景比如用代理工具设置高延迟、丢包率参数或者在工具的network throttling配置里分别模拟512kbps、2G、3G、无网络四种状态。PC端可以在浏览器开发者工具里直接设置网络节流或者用抓包工具断网响应。测试的时候要给每一个弱网场景配上日志和抓包记录因为很多弱网问题的复现条件非常苛刻没有当时的请求日志事后很难定位是前端的问题还是后端的问题。我自己的习惯是弱网测试中一旦发现页面状态异常马上截屏并导出当次请求的har包或抓包数据然后再继续下一步操作。这个习惯帮我省了很多跟开发扯皮的时间。4.3 数据一致性验证注册成功后的数据不是只在用户表里注册成功不代表测试通过还要验证相关数据是否在各种关联表中同步正确。注册的数据一致性测试点至少包括用户主表中账号数据是否正确用户详情表、绑定关系表、登录日志表等关联数据是否有脏数据注册成功后用户是否获得了默认头像、默认昵称、默认权限等初始数据重复手机号注册时是被拦截还是走了已注册并跳转登录的逻辑注册过程中若某一步失败比如创建用户成功但发送欢迎短信失败是否会存在半初始化账号这里我遇到过的一个真实问题非常有代表性注册接口的逻辑是先创建用户主记录再初始化用户配置最后发送欢迎短信。如果某一步超时导致发送短信失败接口被判定为注册失败前端提示注册失败请重试但用户主记录其实已经创建成功了。用户重试时会提示该手机号已注册无法继续注册也无法登录直接卡死在注册环节。这类半完成操作的数据一致性问题如果不做专项数据校验很容易漏过。测试时可以在接口层人为设置某个后续步骤失败来验证主数据的回滚或补偿机制。5. 常见注册模块缺陷实录与排查思路5.1 提示注册成功但账号不存在先看调用链再查事务这类问题通常出现在注册接口有多个下游依赖的场景。表现是前端提示注册成功用户跳转登录页输入账号密码却提示用户不存在。排查这类问题时我的思路有三个方向第一看日志。确认前端提示成功的依据是什么是接口返回了成功码还是页面做了固定的成功跳转。很多前端逻辑是只要请求没报错就跳转成功页后端实际返回的错误被吞掉了。第二查事务。确认注册主流程和关联数据是否在一个数据库事务里如果事务回滚但接口返回了成功码就会造成提示与数据不一致。第三查异步任务。注册接口如果是异步处理的可能前端返回成功代表已受理但后台任务还没完成用户马上去登录任务恰好还没处理完就会提示失败。这时候需要确认接口语义是注册完成还是注册受理。这个排查思路对测试人员同样适用。遇到这类缺陷不要急着提单先通过抓包确认接口实际返回码再通过数据库查询确认数据是否存在把问题定位到具体环节看起来更像一个测试专家的操作。5.2 验证码一直提示错误大概率卡在缓存或大小写上验证码错误是注册模块最高频的线上反馈之一但原因往往不止一种。我总结过几类典型情况验证码是数字但页面校验时带了空格比如用户输入完验证码后习惯性地加了个空格短信验证码由服务端生成但对比时比对的是密文或错误字段验证码存入缓存时有前缀或后缀校验时没去掉验证码在短信发送和存储之间有时序竞争后写入的验证码覆盖了先发送的图形验证码的大小写敏感设置与后端校验不一致邮箱验证码里的链接被邮件客户端自动换行用户复制的链接少了一段排查这类问题我通常会建议测试附上用户输入内容和服务端接收内容的对比。有一次线上用户反馈验证码一直不正确最后抓包发现用户输入的验证码是123456但请求体里变成了123456 多了个空格。前端输入框没有做trim处理用户其实没有输入空格是移动端输入法的自动联想在末尾加了一个空格。这种问题不抓包根本想不到。所以我在注册模块用例里固定加入一条验证码输入框输入内容前后带空格提交时是否自动去除空格后再校验。这是一个不起眼但真正能拦截线上问题的用例。5.3 按钮置灰点不进去前端状态管理翻车现场注册按钮置灰是另一个高频问题通常和协议勾选、必填项联动开发有关。典型场景是这样的用户先勾选了协议又取消了勾选再勾选按钮状态偶尔正常偶尔不可用。或者用户首次打开页面时所有字段为空按钮是置灰状态但输入了所有必填项后按钮还是置灰。这类问题根因一般是前端对按钮可用状态的判断逻辑没有覆盖所有输入组合。测试的时候需要做状态矩阵验证把每个字段的状态分为空、填写、填写后清空、填写非法值等维度遍历组合验证按钮可用性。用工具按组合自动生成用例会高效很多纯手工组合容易漏。另外还有一个常见的前端状态问题用户在获取短信验证码后清空手机号重新输入一个新号码旧验证码是否仍然可用多数产品的要求是手机号变更后旧验证码不可再用于新号码的注册。但如果前端没有在手机号变更时清除验证码状态用户就可能用旧验证码成功注册。这个问题属于页面输入状态与业务流程状态同步问题测试要在用例里重点覆盖修改前置字段后后续状态是否联动更新。6. 从测试用例到自动化注册模块测试的工程化实践6.1 手工用例如何组织才能不重不漏注册模块的手工用例组织我建议按照页面元素 业务规则 异常场景 安全场景四个维度建立用例矩阵而不是简单地按正常流/异常流两类来写。页面元素维度保证每个输入框都有覆盖业务规则维度保证每个交互逻辑都有测试异常场景维度保证每个容错路径都有验证安全场景维度保证每个风险入口都有检查。在用例优先级上我习惯把P0定为注册主流程、必填项全幅校验、验证码获取与校验、重复提交、注册后登录回环、接口防刷。P1定为格式校验边界、密码强度、弱网与超时、数据一致性。P2定为页面状态联动、协议跳转、样式与文案错误等。用例设计还有一个很重要的实践每一条用例都要写出前置条件、测试步骤、测试数据、预期结果四要素尤其是测试数据要精确到具体输入值。比如输入手机号13812345678验证码123456提交注册和输入合法手机号、正确验证码提交注册后者看起来差不多但可执行性差得多。用例数据不具体执行人员就会自己脑补脑补的结果就是漏测和偏差。6.2 自动化测试注册模块时需要注意的3个关键卡点注册模块自动化测试我做过很多轮总结下来有三个最需要提前考虑的问题。第一个问题是验证码处理。自动化脚本跑注册流程时如果没有验证码的自动化获取通道用例就卡死在这一步。常用解法有三种让开发在测试环境开放万能验证码从数据库中读取最新生成的验证码接入短信平台API查询验证码内容。我建议优先选测试环境万能验证码方案最简单稳定也方便在失败时快速定位是验证码问题还是其他问题。第二个问题是测试数据隔离。自动化注册用例每次可能创建大量用户数据如果测试环境和生产环境的数据混用会出现手机号重复注册等干扰。更好的做法是接入数据工厂或接口造数据动态生成不重复的手机号和邮箱。我自己的经验是手机号用固定前缀时间戳生成比如138当前时间戳的后8位保证每次注册手机号唯一同时也能通过手机号前缀快速识别是测试数据。第三个问题是断言完整性。不要只断言注册成功那个toast弹窗还要断言数据库用户表记录已生成、注册成功后登录可用靠这两个业务结果。自动化用例的断言如果只在前端UI层面就会漏掉后端数据同步问题。习惯做法是注册成功后再调用登录接口或查询数据库接口断言注册结果真正落库且可用。6.3 用接口测试覆盖页面测不到的注册逻辑注册模块的很多逻辑是只有通过接口层才能测到的页面测试根本无从下手。我强烈建议在注册模块测试计划中增加接口层的专项测试至少包括以下场景绕过前端必填校验直接请求注册接口后端是否做了校验很多系统前端校验严格、后端不校验这是严重事故隐患重复手机号注册时接口返回的提示信息是否与前端一致接口并发提交时服务端是否正确创建唯一账号请求参数中注入恶意脚本服务端是否过滤请求头缺失user-agent、referrer等字段时接口是否受影响高风险操作接口是否校验了来源域名、csrf token等防护接口测试可以用现成的接口测试工具来管理用例也可以用脚本做并发、随机等策略性验证。我个人习惯是先把所有接口测试用例整理成接口测试集做冒烟回归时统一跑一遍效率很高。这里尤其要强调绕过前端校验的测试。我测过很多系统发现前端校验严格、后端校验为零的现象非常普遍。比如前端限制密码最长20位但用接口直接提交30位密码注册居然成功。虽然日常没人这么干但这类问题只要存在就说明系统的安全边界是模糊的后续可能被批量利用。7. 注册模块测试的检查清单与收尾建议7.1 一份可以拿去对照的注册模块测试检查清单下面这份检查清单是我整理注册模块测试点时的最终沉淀适合在测试计划评审、用例设计、执行前的查漏补缺阶段直接对照使用。必填项全空、部分空、填写后清空三种状态均验证提示输入格式手机号/邮箱/用户名等按产品规则逐项验证合法与非法值长度边界最大允许值、超长1位、中英文混合、emoji与特殊字符密码规则长度边界、字符组合、确认密码一致性、密码显隐切换验证码获取、倒计时、频控、有效期、错误、过期、正确后失效、手机号变更后失效协议未勾选拦截、勾选后提交、协议链接打开、提交失败后保持勾选状态提交按钮重复点击、提交中禁用状态、失败恢复、成功跳转接口安全传输加密、验证码防刷、防重复提交、参数注入过滤、来源校验异常容错弱网超时、断网恢复、服务端异常返回、页面刷新后状态恢复数据一致性主表与关联表数据、半初始化状态、重复数据、注册后登录回环兼容性主流浏览器、不同分辨率、不同移动端机型下的展示与交互这份清单不要求所有产品全部照搬而是建议根据自己的业务场景做裁剪和扩展。比如有年龄字段就要加年龄边界测试有邀请码就要加邀请码有效期、错误邀请码、重复使用邀请码的测试。7.2 最后分享几个我个人的实操体会走到这里我把注册模块的主要测试维度都拆完了最后再分享几个实操中沉淀下来的小经验和思路。希望读者在真正执行注册模块测试时能少走一些我当年走过的弯路。第一点注册模块的用例一定要在需求评审阶段就开始梳理不要等开发提测了才开始设计。注册相关的很多逻辑验证码频控、字段长度上限、账号唯一性规则在产品需求里经常不写清楚测试需要在需求澄清阶段主动暴露这些疑问而不是测试时自己猜。第二点注册模块的发现率最高的场景往往不是正向用例而是用户错误操作 系统状态交叉的组合场景。比如验证码倒计时未结束就点击获取、手机号一有值就点击获取按钮、协议勾选与必填项清空同时发生。这类组合场景是手工测试时最容易漏但对真实用户体验影响最大的场景。第三点注册模块上线后不要觉得测试完了就万事大吉。我建议在线上环境挂一个轻量的注册监控包含注册接口的成功率、验证码接口的失败率、注册页面报错率这几个指标。一旦指标出现波动马上进来排查。注册模块的特点是影响面大、问题扩散快早一分钟发现就少损失一批用户。还有最后一个小技巧测试注册模块时可以尝试用用户的视角反向走一遍流程从下载App、打开注册页、输错几次、忘记协议、验证码收不到、提交失败、再试一次最后成功。全程记录从用户角度感受到的每一步反馈。这个方法不怎么花时间但每次都让我在正式用例之外找到几个体验层面的问题也算是我个人做注册模块测试时的一个小习惯了。