登录测试很容易写成一张不断变长的清单正常登录、账号为空、密码错误、长度边界、弱网、安全、兼容性……但在真实测试中第一步通常不是继续补测试点而是先确认这次要测的是哪一种登录、需求改了什么、哪些能力不在本次范围内。同样是“登录”普通内容网站、内部管理后台和金融系统的风险并不相同账号密码、短信验证码、第三方登录和单点登录的状态也完全不同。范围没有确定之前讨论“应该写多少条用例”没有统一答案。本文以一个普通Web站点的账号密码登录为例先固定测试依据再使用等价类、边界值、决策表和状态迁移设计27条核心用例。这里关注的是用例怎样从需求和风险中产生而不是把27当作完整登录测试的标准数量。一、先固定本次测试范围为了让案例能够落地先约定这是一个面向普通内容社区的Web登录页使用用户名和密码认证主要支持桌面端浏览器。本次不包含短信验证码、第三方登录、MFA、找回密码和“记住我”。测试所依据的示例需求如下编号已确认的示例需求AUTH-001正常账号输入正确凭据后登录成功创建新会话并跳回登录前的目标页面AUTH-002用户名长度为420位密码长度为864位空值和越界输入在提交前给出提示AUTH-003账号不存在、密码错误和账号停用时对外统一提示“账号或密码错误”AUTH-00410分钟内连续失败5次后临时锁定15分钟锁定期间不能登录AUTH-005登录成功后更新会话标识登录前的旧标识不能直接获得登录态AUTH-006请求处理中禁止重复提交断网后不能误显示登录成功AUTH-007接口只接受约定字段类型非法类型返回客户端错误且不暴露服务端堆栈AUTH-008输入框有明确标签错误信息使用文本说明并能定位到对应字段AUTH-009在约定负载下登录接口的响应时间和错误率满足容量目标AUTH-010在产品声明支持的浏览器中核心流程、提示和键盘操作保持可用用户名长度、锁定时间、并发量和响应时间都是为了演示而设定的需求不是通用标准。实际测试时这些值应来自产品需求、接口文档、安全基线或容量目标如果没有写清楚应先记录为待确认项而不是由测试人员自行补成事实。还有一个常见误区注册、改密和登录的输入规则不一定相同。登录需要兼容系统中已经存在的合法账号不能把新用户注册时的密码复杂度校验直接照搬过来。二、一次登录不只是页面跳转用户看到的是两个输入框和一个按钮系统内部至少经过页面、登录接口、认证服务、会话与数据几层页面交互输入、必填提示、按钮状态、键盘操作和重复点击。登录接口请求字段、错误结构、超时以及异常参数。认证服务凭据校验、账号状态、失败计数和锁定策略。会话与数据会话标识、登录态、跳转地址和审计记录。因此“登录成功”的判定不能只有页面跳转。还要检查接口结果、登录后的用户身份、新会话是否生效、跳转地址是否正确以及失败计数是否被重置。“登录失败”也不只是出现一句错误提示。系统不应创建有效会话失败次数应按规则变化不同失败原因不能意外泄露账号状态本次失败造成的锁定状态还会影响下一次请求。这样拆开后每条用例都应该能回答依据哪条需求、验证哪个风险、需要什么前置状态、怎样判断通过以及执行后保留什么证据。三、用设计方法减少无意义的组合1. 等价类和边界值用户名和密码的输入空间很大不可能逐个尝试。可以先划分有效、无效和空值等价类再围绕边界取值。用户名允许420位时选择3、4、20、21密码允许864位时选择7、8、64、65。边界值用例需要准备对应账号。例如验证20位用户名可以正常登录测试环境中必须存在一个20位用户名的有效账号否则失败原因只是账号不存在无法证明长度上界是否正确。2. 决策表登录结果同时受到账号是否存在、密码是否正确、账号是否停用和是否锁定等条件影响。把条件组合写成决策表更容易发现遗漏和冲突规则账号存在密码正确状态正常已锁定预期结果R1是是是否登录成功并创建新会话R2是否是否拒绝登录并累计失败次数R3否--否拒绝登录不暴露账号是否存在R4是是否否拒绝登录不创建会话R5是是是是拒绝登录保持锁定状态这里有一个实际的取舍分别提示“账号不存在”和“密码错误”对用户更直接但也可能帮助攻击者确认有效账号。对于本文的示例系统约定公开文案和错误响应采用统一策略详细失败原因只进入内部日志。3. 状态迁移连续失败、临时锁定和到期恢复都依赖前一次操作单次请求无法覆盖整个过程。锁定流程至少要验证第4次失败后仍能继续尝试、第5次失败后进入锁定、锁定期间正确密码也不能绕过以及锁定到期后能够恢复。还要关注失败计数是否清零、锁定时间从何时开始计算以及并发请求会不会绕过计数。四、27条核心用例是什么基于前面的范围和10项需求本次整理出27条核心用例。下面的表格保留测试场景和关键判定先让覆盖内容可见。用例编号类别测试场景关键判定结果LOGIN-F-001功能有效账号输入正确凭据登录成功跳回目标页并创建新会话LOGIN-F-002功能用户名为空阻止提交用户名框显示必填提示LOGIN-F-003功能密码为空阻止提交密码框显示必填提示LOGIN-F-004功能用户名为3位低于下界阻止提交提示用户名长度不符合要求LOGIN-F-005功能用户名为4位等于下界使用预置有效账号登录成功LOGIN-F-006功能用户名为20位等于上界使用预置有效账号登录成功LOGIN-F-007功能用户名为21位超过上界阻止提交提示用户名长度不符合要求LOGIN-F-008功能密码为7位低于下界阻止提交提示密码长度不符合要求LOGIN-F-009功能密码为8位等于下界使用预置有效密码登录成功LOGIN-F-010功能密码为64位等于上界使用预置有效密码登录成功LOGIN-F-011功能密码为65位超过上界阻止提交提示密码长度不符合要求LOGIN-D-001安全使用不存在的账号统一失败提示不暴露账号状态LOGIN-D-002安全有效账号输入错误密码拒绝登录失败次数增加1LOGIN-D-003安全停用账号输入正确密码拒绝登录不创建会话LOGIN-S-001功能连续第4次输入错误密码累计失败次数账号仍可继续尝试LOGIN-S-002安全连续第5次输入错误密码账号进入临时锁定并记录锁定时间LOGIN-S-003安全锁定期间输入正确密码仍然拒绝登录不创建会话LOGIN-S-004功能锁定到期后输入正确密码登录成功失败计数清零LOGIN-I-001功能快速连续点击两次登录按钮只处理一次有效请求只创建一个会话LOGIN-I-002功能请求提交后立即断网显示网络错误不误报登录成功LOGIN-I-003接口username传入数组类型返回约定客户端错误不暴露堆栈LOGIN-SEC-001安全对比多种认证失败响应状态码和文案一致无稳定可利用的时间差LOGIN-SEC-002安全登录前后比较会话标识登录后标识更新旧标识不能获得登录态LOGIN-A-001可用性检查输入框和按钮标签标签含义清楚键盘可以识别控件LOGIN-A-002可用性用户名、密码同时为空文本指出错误字段焦点到达首个错误位置LOGIN-P-001性能200并发用户持续10分钟P95不超过500毫秒错误率不超过0.1%LOGIN-C-001兼容性在三个受支持浏览器执行核心流程流程和提示一致布局无遮挡键盘可操作从类别看其中功能15条、安全7条、接口1条、可用性2条、性能1条、兼容性1条。分类只是便于整理同一个用例往往同时涉及多个质量属性。例如“锁定期间正确密码不能登录”既是状态迁移也是安全控制。五、27条够不够如果问题是“能不能完整覆盖一个生产环境的登录系统”答案是不能。27条只覆盖本文已经明确的账号密码登录范围可以作为功能测试和第一轮回归的基础但不能代表完整认证测试。用例是否足够应该检查测试依据和风险而不是只看数量检查维度当前覆盖情况已确认需求AUTH-001AUTH-010均有对应测试用例输入边界覆盖空值、下界外、下界、上界和上界外条件组合覆盖正常账号、错误密码、不存在账号、停用和锁定状态变化覆盖失败累计、达到阈值、锁定期间和到期恢复系统层次覆盖UI、API、认证服务和端到端链路主要异常覆盖重复提交、断网和非法字段类型如果产品实际支持下面这些能力还需要单独扩展测试验证码、短信登录、MFA及验证码过期、重放和绕过“记住我”、主动退出、会话过期、并发会话和多设备登录找回密码、首次登录改密、密码过期和账号恢复OAuth、单点登录以及第三方认证服务异常手机端、国际化、代理网络和更多浏览器环境认证绕过、权限校验、限速、日志审计等专项安全测试。实际执行时测试人员通常根据需求、接口文档、团队检查表和产品适用的安全或可访问性要求来设计用例不需要背诵某个标准编号。比如本例中的键盘操作、焦点位置和文本错误提示只有在产品要求或团队质量基线中明确后才会成为可验收的测试项。六、风险等级不等于执行优先级风险通常看缺陷发生概率和失败影响执行优先级还要考虑是否属于核心链路、是否适合快速回归、执行成本以及本次改动范围。两者有关但不能简单画等号。以普通内容社区为背景重新评估后这组用例包含高风险7条、中风险8条、低风险12条执行批次分为P0 5条、P1 12条、P2 10条。P0只保留正常登录、错误密码必须被拒绝、达到锁定阈值、锁定期间不能绕过、登录后会话更新这5条核心检查。停用账号和失败响应一致性仍属于高风险但更适合放在专项回归中所以安排为P1。用户名为空的失败影响较低但执行成本很小且经常受页面改动影响也可以进入P1。实际回归时可以先用P0做提交后快速检查再执行P0和P1完成主要功能回归版本发布前或相关模块改动较大时再补充P2边界和低风险场景。如果换成后台管理或金融系统同一条安全用例的风险和优先级都可能上调。七、小结与思考登录测试没有固定的“标准用例数量”。更可靠的做法是先确定产品场景和本次范围再从需求、条件组合、状态变化、系统链路和风险中生成用例并为每条用例写出可判断的结果。本文的27条用例能覆盖当前10项示例需求但不能覆盖短信验证码、MFA、第三方登录、找回密码和完整会话管理。明确这些边界并不是测试不充分而是为了让测试结论有清楚的适用范围。需求增加时用例也应该沿着新的状态、接口和风险继续扩展。本文代码GitHub002-login-test-design 
长河君 · 2026/8/8 8:37:58 · 阅读 1.2k 从一个登录功能开始：需求、状态和风险如何落到测试用例
登录测试很容易写成一张不断变长的清单正常登录、账号为空、密码错误、长度边界、弱网、安全、兼容性……但在真实测试中第一步通常不是继续补测试点而是先确认这次要测的是哪一种登录、需求改了什么、哪些能力不在本次范围内。同样是“登录”普通内容网站、内部管理后台和金融系统的风险并不相同账号密码、短信验证码、第三方登录和单点登录的状态也完全不同。范围没有确定之前讨论“应该写多少条用例”没有统一答案。本文以一个普通Web站点的账号密码登录为例先固定测试依据再使用等价类、边界值、决策表和状态迁移设计27条核心用例。这里关注的是用例怎样从需求和风险中产生而不是把27当作完整登录测试的标准数量。一、先固定本次测试范围为了让案例能够落地先约定这是一个面向普通内容社区的Web登录页使用用户名和密码认证主要支持桌面端浏览器。本次不包含短信验证码、第三方登录、MFA、找回密码和“记住我”。测试所依据的示例需求如下编号已确认的示例需求AUTH-001正常账号输入正确凭据后登录成功创建新会话并跳回登录前的目标页面AUTH-002用户名长度为420位密码长度为864位空值和越界输入在提交前给出提示AUTH-003账号不存在、密码错误和账号停用时对外统一提示“账号或密码错误”AUTH-00410分钟内连续失败5次后临时锁定15分钟锁定期间不能登录AUTH-005登录成功后更新会话标识登录前的旧标识不能直接获得登录态AUTH-006请求处理中禁止重复提交断网后不能误显示登录成功AUTH-007接口只接受约定字段类型非法类型返回客户端错误且不暴露服务端堆栈AUTH-008输入框有明确标签错误信息使用文本说明并能定位到对应字段AUTH-009在约定负载下登录接口的响应时间和错误率满足容量目标AUTH-010在产品声明支持的浏览器中核心流程、提示和键盘操作保持可用用户名长度、锁定时间、并发量和响应时间都是为了演示而设定的需求不是通用标准。实际测试时这些值应来自产品需求、接口文档、安全基线或容量目标如果没有写清楚应先记录为待确认项而不是由测试人员自行补成事实。还有一个常见误区注册、改密和登录的输入规则不一定相同。登录需要兼容系统中已经存在的合法账号不能把新用户注册时的密码复杂度校验直接照搬过来。二、一次登录不只是页面跳转用户看到的是两个输入框和一个按钮系统内部至少经过页面、登录接口、认证服务、会话与数据几层页面交互输入、必填提示、按钮状态、键盘操作和重复点击。登录接口请求字段、错误结构、超时以及异常参数。认证服务凭据校验、账号状态、失败计数和锁定策略。会话与数据会话标识、登录态、跳转地址和审计记录。因此“登录成功”的判定不能只有页面跳转。还要检查接口结果、登录后的用户身份、新会话是否生效、跳转地址是否正确以及失败计数是否被重置。“登录失败”也不只是出现一句错误提示。系统不应创建有效会话失败次数应按规则变化不同失败原因不能意外泄露账号状态本次失败造成的锁定状态还会影响下一次请求。这样拆开后每条用例都应该能回答依据哪条需求、验证哪个风险、需要什么前置状态、怎样判断通过以及执行后保留什么证据。三、用设计方法减少无意义的组合1. 等价类和边界值用户名和密码的输入空间很大不可能逐个尝试。可以先划分有效、无效和空值等价类再围绕边界取值。用户名允许420位时选择3、4、20、21密码允许864位时选择7、8、64、65。边界值用例需要准备对应账号。例如验证20位用户名可以正常登录测试环境中必须存在一个20位用户名的有效账号否则失败原因只是账号不存在无法证明长度上界是否正确。2. 决策表登录结果同时受到账号是否存在、密码是否正确、账号是否停用和是否锁定等条件影响。把条件组合写成决策表更容易发现遗漏和冲突规则账号存在密码正确状态正常已锁定预期结果R1是是是否登录成功并创建新会话R2是否是否拒绝登录并累计失败次数R3否--否拒绝登录不暴露账号是否存在R4是是否否拒绝登录不创建会话R5是是是是拒绝登录保持锁定状态这里有一个实际的取舍分别提示“账号不存在”和“密码错误”对用户更直接但也可能帮助攻击者确认有效账号。对于本文的示例系统约定公开文案和错误响应采用统一策略详细失败原因只进入内部日志。3. 状态迁移连续失败、临时锁定和到期恢复都依赖前一次操作单次请求无法覆盖整个过程。锁定流程至少要验证第4次失败后仍能继续尝试、第5次失败后进入锁定、锁定期间正确密码也不能绕过以及锁定到期后能够恢复。还要关注失败计数是否清零、锁定时间从何时开始计算以及并发请求会不会绕过计数。四、27条核心用例是什么基于前面的范围和10项需求本次整理出27条核心用例。下面的表格保留测试场景和关键判定先让覆盖内容可见。用例编号类别测试场景关键判定结果LOGIN-F-001功能有效账号输入正确凭据登录成功跳回目标页并创建新会话LOGIN-F-002功能用户名为空阻止提交用户名框显示必填提示LOGIN-F-003功能密码为空阻止提交密码框显示必填提示LOGIN-F-004功能用户名为3位低于下界阻止提交提示用户名长度不符合要求LOGIN-F-005功能用户名为4位等于下界使用预置有效账号登录成功LOGIN-F-006功能用户名为20位等于上界使用预置有效账号登录成功LOGIN-F-007功能用户名为21位超过上界阻止提交提示用户名长度不符合要求LOGIN-F-008功能密码为7位低于下界阻止提交提示密码长度不符合要求LOGIN-F-009功能密码为8位等于下界使用预置有效密码登录成功LOGIN-F-010功能密码为64位等于上界使用预置有效密码登录成功LOGIN-F-011功能密码为65位超过上界阻止提交提示密码长度不符合要求LOGIN-D-001安全使用不存在的账号统一失败提示不暴露账号状态LOGIN-D-002安全有效账号输入错误密码拒绝登录失败次数增加1LOGIN-D-003安全停用账号输入正确密码拒绝登录不创建会话LOGIN-S-001功能连续第4次输入错误密码累计失败次数账号仍可继续尝试LOGIN-S-002安全连续第5次输入错误密码账号进入临时锁定并记录锁定时间LOGIN-S-003安全锁定期间输入正确密码仍然拒绝登录不创建会话LOGIN-S-004功能锁定到期后输入正确密码登录成功失败计数清零LOGIN-I-001功能快速连续点击两次登录按钮只处理一次有效请求只创建一个会话LOGIN-I-002功能请求提交后立即断网显示网络错误不误报登录成功LOGIN-I-003接口username传入数组类型返回约定客户端错误不暴露堆栈LOGIN-SEC-001安全对比多种认证失败响应状态码和文案一致无稳定可利用的时间差LOGIN-SEC-002安全登录前后比较会话标识登录后标识更新旧标识不能获得登录态LOGIN-A-001可用性检查输入框和按钮标签标签含义清楚键盘可以识别控件LOGIN-A-002可用性用户名、密码同时为空文本指出错误字段焦点到达首个错误位置LOGIN-P-001性能200并发用户持续10分钟P95不超过500毫秒错误率不超过0.1%LOGIN-C-001兼容性在三个受支持浏览器执行核心流程流程和提示一致布局无遮挡键盘可操作从类别看其中功能15条、安全7条、接口1条、可用性2条、性能1条、兼容性1条。分类只是便于整理同一个用例往往同时涉及多个质量属性。例如“锁定期间正确密码不能登录”既是状态迁移也是安全控制。五、27条够不够如果问题是“能不能完整覆盖一个生产环境的登录系统”答案是不能。27条只覆盖本文已经明确的账号密码登录范围可以作为功能测试和第一轮回归的基础但不能代表完整认证测试。用例是否足够应该检查测试依据和风险而不是只看数量检查维度当前覆盖情况已确认需求AUTH-001AUTH-010均有对应测试用例输入边界覆盖空值、下界外、下界、上界和上界外条件组合覆盖正常账号、错误密码、不存在账号、停用和锁定状态变化覆盖失败累计、达到阈值、锁定期间和到期恢复系统层次覆盖UI、API、认证服务和端到端链路主要异常覆盖重复提交、断网和非法字段类型如果产品实际支持下面这些能力还需要单独扩展测试验证码、短信登录、MFA及验证码过期、重放和绕过“记住我”、主动退出、会话过期、并发会话和多设备登录找回密码、首次登录改密、密码过期和账号恢复OAuth、单点登录以及第三方认证服务异常手机端、国际化、代理网络和更多浏览器环境认证绕过、权限校验、限速、日志审计等专项安全测试。实际执行时测试人员通常根据需求、接口文档、团队检查表和产品适用的安全或可访问性要求来设计用例不需要背诵某个标准编号。比如本例中的键盘操作、焦点位置和文本错误提示只有在产品要求或团队质量基线中明确后才会成为可验收的测试项。六、风险等级不等于执行优先级风险通常看缺陷发生概率和失败影响执行优先级还要考虑是否属于核心链路、是否适合快速回归、执行成本以及本次改动范围。两者有关但不能简单画等号。以普通内容社区为背景重新评估后这组用例包含高风险7条、中风险8条、低风险12条执行批次分为P0 5条、P1 12条、P2 10条。P0只保留正常登录、错误密码必须被拒绝、达到锁定阈值、锁定期间不能绕过、登录后会话更新这5条核心检查。停用账号和失败响应一致性仍属于高风险但更适合放在专项回归中所以安排为P1。用户名为空的失败影响较低但执行成本很小且经常受页面改动影响也可以进入P1。实际回归时可以先用P0做提交后快速检查再执行P0和P1完成主要功能回归版本发布前或相关模块改动较大时再补充P2边界和低风险场景。如果换成后台管理或金融系统同一条安全用例的风险和优先级都可能上调。七、小结与思考登录测试没有固定的“标准用例数量”。更可靠的做法是先确定产品场景和本次范围再从需求、条件组合、状态变化、系统链路和风险中生成用例并为每条用例写出可判断的结果。本文的27条用例能覆盖当前10项示例需求但不能覆盖短信验证码、MFA、第三方登录、找回密码和完整会话管理。明确这些边界并不是测试不充分而是为了让测试结论有清楚的适用范围。需求增加时用例也应该沿着新的状态、接口和风险继续扩展。本文代码GitHub002-login-test-design