一个登录接口，我们写了47个测试用例——你写了几个？

导语：登录接口是每个系统最基础的功能，看似简单，实则暗藏玄机。本文以一个真实的登录接口为例，系统讲解接口测试用例设计方法，附完整用例清单，建议收藏。

在接口测试中，登录接口往往被当作”入门练习”。很多测试工程师觉得：不就是发个请求、验证返回结果吗？能有多复杂？

然而，正是这种”简单”的认知，让很多Bug在上线后才被发现。我们团队在复盘一次生产事故后，重新审视了登录接口的测试覆盖，最终设计了47个测试用例。这篇文章，我来拆解这些用例是怎么设计出来的。

一、从需求出发：登录接口到底要测什么？

假设我们有一个典型的登录接口：

• 接口地址：POST /api/login
• 请求参数：
  
  username（用户名）、password（密码）
• 返回结果：
  
  成功返回token，失败返回错误码和提示信息

看似简单，但我们需要从多个维度来思考测试覆盖：

1. 功能正确性：
   
   正常登录能否成功？
2. 参数校验：
   
   各种异常输入如何处理？
3. 业务规则：
   
   账号状态、密码错误次数限制等
4. 安全性：
   
   SQL注入、暴力破解防护
5. 性能与并发：
   
   高并发下是否正常？

二、用例设计方法：三种经典方法的综合运用

1. 等价类划分法

将输入数据划分为有效等价类和无效等价类，每个等价类选取一个代表值进行测试。

用户名等价类划分：

• 有效等价类：符合规则的正常用户名（如6-20位字母数字组合）
• 无效等价类：空值、超长、特殊字符、SQL注入字符

2. 边界值分析法

在等价类边界上选取测试数据，这是发现Bug最有效的方法之一。

用户名长度边界：假设规则是6-20位

• 5位（刚好小于最小值）
• 6位（最小值）
• 7位（最小值+1）
• 19位（最大值-1）
• 20位（最大值）
• 21位（刚好大于最大值）

3. 场景法/错误推测法

基于实际使用场景和经验，推测可能出错的情况。

• 账号被锁定后尝试登录
• 密码连续错误5次
• 同一账号多地同时登录

三、47个用例完整清单

说明：以下用例按测试维度分类，实际执行时可根据优先级调整顺序。P0为最高优先级，P2为低优先级。

【一】正常场景（3个）

用例编号	测试点	输入数据	预期结果	优先级
TC001	正常登录	正确的用户名和密码	返回token，状态码200	P0
TC002	用户名大小写	用户名大写/小写变体	根据系统规则处理	P1
TC003	含空格的用户名	用户名前后带空格	自动trim后登录成功	P1

【二】参数校验-用户名（10个）

用例编号	测试点	输入数据	预期结果	优先级
TC004	用户名为空	username=””	返回”用户名不能为空”	P0
TC005	用户名为null	username=null	返回参数错误	P0
TC006	用户名长度=5	5位字符	返回”用户名长度不正确”	P0
TC007	用户名长度=6	6位字符（边界）	继续验证密码	P1
TC008	用户名长度=20	20位字符（边界）	继续验证密码	P1
TC009	用户名长度=21	21位字符	返回”用户名过长”	P0
TC010	用户名含特殊字符	user@name	返回”用户名格式不正确”	P0
TC011	用户名纯数字	12345678	根据规则处理	P1
TC012	用户名含中文	测试用户	根据规则处理	P1
TC013	用户名全空格	username=” “	返回”用户名不能为空”	P1

【三】参数校验-密码（8个）

用例编号	测试点	输入数据	预期结果	优先级
TC014	密码为空	password=””	返回”密码不能为空”	P0
TC015	密码错误	错误密码	返回”用户名或密码错误”	P0
TC016	密码长度边界	按规则测试边界值	正确处理	P1
TC017	密码含特殊字符	P@ssw0rd!	正确处理	P1
TC018	密码全空格	password=” “	根据规则处理	P1
TC019	密码超长	超长字符串	返回错误或截断处理	P1
TC020	密码含SQL字符	pass’word	正常处理，无注入	P0
TC021	密码前后空格	带空格的密码	根据规则处理	P1

【四】账号状态相关（6个）

用例编号	测试点	输入数据	预期结果	优先级
TC022	账号不存在	不存在的用户名	返回”用户名或密码错误”	P0
TC023	账号已禁用	被禁用的账号	返回”账号已被禁用”	P0
TC024	账号未激活	未激活账号	返回”请先激活账号”	P0
TC025	账号已过期	过期账号	返回”账号已过期”	P1
TC026	账号被锁定	锁定账号	返回”账号已锁定”	P0
TC027	首次登录	首次登录账号	提示修改密码	P1

【五】安全相关（8个）

用例编号	测试点	输入数据	预期结果	优先级
TC028	SQL注入-用户名	admin’ or ‘1’=’1	登录失败，无注入	P0
TC029	SQL注入-密码	‘ or ‘1’=’1	登录失败，无注入	P0
TC030	XSS攻击	<script>alert(1)</script>	正常转义处理	P0
TC031	暴力破解防护	连续错误5次	账号锁定或验证码	P0
TC032	错误次数计数	错误后正确登录	计数清零	P1
TC033	密码明文传输	抓包检查	密码已加密	P0
TC034	Token有效性	登录后验证token	token格式正确	P0
TC035	敏感信息脱敏	返回数据检查	无敏感信息泄露	P0

【六】并发与性能（4个）

用例编号	测试点	输入数据	预期结果	优先级
TC036	同一账号并发登录	10个并发请求	正确处理，无数据错乱	P1
TC037	多账号并发登录	100个不同账号	全部正确响应	P1
TC038	响应时间	正常登录请求	响应时间<500ms	P1
TC039	高并发稳定性	持续并发请求	无内存泄漏、无崩溃	P2

【七】其他场景（8个）

用例编号	测试点	输入数据	预期结果	优先级
TC040	请求方法错误	GET请求	返回405	P1
TC041	Content-Type错误	错误的Content-Type	返回415或正确处理	P1
TC042	缺少必填参数	只传用户名	返回参数错误	P0
TC043	多余参数	添加额外参数	忽略或正确处理	P2
TC044	参数类型错误	username传数字	正确处理或提示	P1
TC045	重复登录	已登录状态再登录	返回新token或提示	P1
TC046	Session处理	检查session创建	正确创建session	P1
TC047	日志记录	登录成功/失败	正确记录日志	P2

四、用例设计的几个关键原则

注意：用例数量不是目的，覆盖率才是。47个用例的价值在于系统性，而非数字本身。

在实际工作中，我总结了几个原则：

1. 先广后深

先保证各个维度都有覆盖，再深入每个维度的细节。比如先覆盖”参数校验、账号状态、安全性”三大类，再细化每类中的具体场景。

2. 边界必测

边界值是用Bug的高发区。长度、次数、时间等有明确边界的场景，边界值测试一个都不能少。

3. 安全先行

登录接口是安全的第一道门，SQL注入、XSS、暴力破解等安全测试必须覆盖。这些Bug一旦漏到生产，后果严重。

4. 优先级分级

不是所有用例都同等重要。P0用例必须100%通过，P1用例尽量覆盖，P2用例视时间情况。这样在时间紧张时也能保证核心质量。

五、写在最后

一个看似简单的登录接口，认真分析下来竟然有47个测试场景。这说明什么？

测试的价值不在于发现Bug，而在于系统性地保障质量。当我们能够穷尽各种可能的情况，才能说”这个功能我测透了”。

当然，47这个数字不是标准答案。不同的业务场景、不同的安全要求，用例数量会有差异。重要的是掌握等价类、边界值、场景法这些设计方法，举一反三。

总结：接口测试用例设计，核心是”全面”和”系统”。从一个登录接口出发，希望你能建立起自己的用例设计思维框架。下次写用例之前，不妨先问自己：我写了几个？