测试用例设计实例：从登录功能看如何写好用例

登录功能的测试用例该怎么写

很多人刚接触软件测试时，面对一个简单的登录页面反而不知道怎么下手。输入框就两个，按钮一个，看起来没啥可测的。其实越是常见的功能，越能看出测试用例设计的功力。

比如用户登录，看似只是输入账号密码点登录，但背后要考虑的情况可不少。比如用户名输错、密码少一位、网络中断、连续输错五次被锁定……这些都得覆盖到。

从需求出发拆解场景

假设我们有一个Web系统的登录页，要求如下：

• 用户名为邮箱格式
• 密码长度6-20位
• 输错5次后账户锁定30分钟
• 支持“记住我”功能

这时候不能直接写用例，先分类型。通常可以按功能模块分：输入验证、业务逻辑、异常处理、界面交互等。

输入验证类用例

这是最基础的部分，主要检查前端有没有对输入做正确限制。

测试用例编号：TC_LOGIN_001
测试项：用户名格式校验
前置条件：用户未登录
操作步骤：
1. 打开登录页
2. 在用户名输入框中输入 “abc123”
3. 点击密码输入框失去焦点
预期结果：显示提示 “请输入有效的邮箱地址”

测试用例编号：TC_LOGIN_002
测试项：密码长度校验
操作步骤：
1. 输入合法邮箱
2. 输入密码 “12345”
3. 提交表单
预期结果：提示 “密码长度需为6-20位”

业务逻辑用例

这类关注的是系统行为是否符合规则，比如登录成功跳转、失败次数累计。

测试用例编号：TC_LOGIN_008
测试项：连续输错5次账户锁定
操作步骤：
1. 使用正确用户名+错误密码登录第1次
2. 重复4次相同操作
5. 第5次提交后观察提示
6. 再次尝试登录
预期结果：
- 前4次提示 “用户名或密码错误”
- 第5次提示 “账户已锁定，请30分钟后重试”
- 锁定期间无法提交登录请求

边界和异常情况别漏掉

实际使用中总有人“不按常理出牌”。比如复制带空格的邮箱、密码含特殊字符、浏览器刷新、断网重连。

有个真实案例：某公司上线后发现一批用户登不上，查了半天才发现是iOS自带键盘在切换时自动加了全角字符，而系统没做trim处理。这种就得在用例里加上“前后有空格的邮箱能否正常登录”这一条。

用表格整理更清晰

写多了会发现纯文字描述容易乱，建议用表格管理。例如：

这样开发、测试、产品都能快速对齐理解。

别忘了正向和反向都要覆盖

新手常犯的错误是只写“能登上去”的情况，忽略了各种“登不上去”的路径。好的测试用例应该像交通信号灯，既让正常的车通过，也能拦下违规的。

比如“忘记密码”链接要不要测？当然要。点击后跳转页面是否正确、验证码能不能收到、重置链接有效期多久，这些都是关联流程。

再比如，有人会在登录页直接按回车，系统有没有响应？这属于交互细节，但用户真会这么干。

自动化脚本里的用例设计

如果要做自动化，用例设计就得考虑可复用性。比如把登录封装成一个函数：

<?php
function login($email, $password) {
    setInput('#email', $email);
    setInput('#password', $password);
    click('#login-btn');
}

// 测试用例调用
login('test@example.com', 'wrongpass');
assertTextPresent('用户名或密码错误');

这样一来，多个测试都可以复用这个登录动作，只需要传不同参数就行。

测试用例设计不是为了填表格应付检查，而是为了真正发现潜在问题。每个用例背后都是一个可能发生的用户故事。多想想“如果我是用户，我会怎么操作”，往往能找到那些藏在角落里的bug。