SauceDemo 登录功能测试实践记录
第一周我用 AI 辅助生成了 16 条登录测试用例，当时觉得“差不多了”。最近重新审视，发现测试数据模糊、预期结果不确定、安全覆盖不足……于是重构到 33 条。这篇文章记录了我从“依赖 AI”到“驾驭 AI”的完整迭代过程。
一、背景
第一周学测试时，我用 AI 辅助生成了一份 SauceDemo 登录功能的测试用例，16 条。当时觉得“差不多了”，就去 SauceDemo 上执行，登录成功、报错提示、空值校验……跑完一圈，发现几个异常就报了 Bug，用例执行完就放进文件夹，再没回头看过。
最近重新打开 SauceDemo 登录测试，我重新设计了一份用例，从 16 条扩展到 33 条。把两份用例放在一起对比时，我发现自己对“测试用例”这件事的理解，已经和第一周完全不同了。
二、直观对比：16 条 vs 33 条
| 对比项 | 第一版（16条） | 第二版（33条） |
|---|---|---|
| 用例总数 | 16条 | 33条 |
| 测试方法标注 | 无 | 等价类/边界值/场景法/安全测试明确标注 |
| 安全测试覆盖 | 2条 | 9条（SQL注入3种、XSS 2种、路径遍历、暴力破解、信息泄露等） |
| UI交互测试 | 无 | 4条（密码掩码、Tab键、回车提交、错误关闭） |
| 场景法覆盖 | 2条 | 3条（含登出后退、未登录访问保护页） |
| 测试数据精确度 | 部分模糊（如“含前后空格”） | 明确量化（如“前后各1个空格”） |
| 预期结果确定性 | 部分写“或” | 全部确定 |
| Bug判断方式 | 发现异常直接报Bug | 先确认系统设计，再决定结论 |
| 错误提示记录 | 简化版 | 完整版（含产品前缀 “Epic sadface”） |
直观变化很明显：用例数量翻倍，覆盖维度从“基本功能”扩展到“功能 + 安全 + UI + 场景”。但真正重要的不是数量，而是设计思路的变化。
三、4 个具体的改进点
改进 1：测试数据从模糊变精确
| 版本 | 写法 |
|---|---|
| 第一版 | “输入用户名 standard_user（含前后空格）” |
| 第二版 | “输入用户名 " standard_user "（前后各1个空格）” |
问题在哪：“含前后空格”——到底几个空格？一个？两个？三个？不写清楚，换一个人执行时无法复现这个用例。
怎么改的：明确写成“前1个空格 + standard_user + 后1个空格”，任何人都能准确复现。
改进 2：预期结果从不确定变确定
| 版本 | 写法 |
|---|---|
| 第一版 | “登录成功，但页面加载明显慢（>2秒），最终进入商品页” |
| 第二版 | “登录成功，加载约3-4秒后进入商品页” |
问题在哪：写“>2秒”其实不够具体——3秒算不算“明显慢”？5秒呢？测试用例的预期结果必须是确定的。如果你自己都说“大概”，那执行的时候就没有判断标准。
怎么改的：去 SauceDemo 实际执行了 performance_glitch_user 这个账号，观察到加载耗时约 3-4 秒，就把这个具体数值写进了用例。
改进 3：从“发现异常报Bug”到“先确认是不是系统设计”
第一版的做法： 发现用户名带空格登录失败 → 默认“系统应该自动 trim 空格” → 直接报 Bug
第二版的做法： 发现用户名带空格登录失败 → 先确认 SauceDemo 的设计是否支持 trim → 确认不支持 trim → 结论改为“通过”，不是 Bug
为什么会有这个变化：第一次测试时，我默认“系统应该自动 trim 空格”是行业标准，发现不 trim 就觉得是缺陷。但后来我确认了 SauceDemo 的设计就是不对用户名做 trim——带空格的用户名被视为完全不同的用户名。
学到的经验是：报 Bug 之前，先确认自己的预期是否合理。不能把自己的假设当成标准。
改进 4：错误提示从简化版变成完整版
| 版本 | 写法 |
|---|---|
| 第一版 | “Username and password do not match” |
| 第二版 | “Epic sadface: Username and password do not match any user in this service” |
问题在哪：SauceDemo 的错误提示有产品前缀 Epic sadface:，这是产品特性的一部分。第一次写的时候只记了后半句，忽略了前缀。
怎么改的：实际执行时观察完整提示，把完整文案写进用例，并在多次执行中确认了不同错误场景下的提示差异（如“不匹配”和“已锁定”的提示不同）。
四、一份好的测试用例，应该是什么样的？
经过这次迭代，我对“好的测试用例”有了更清晰的标准。下面用一条用例展示从初稿到终稿的完整演变过程：
📝 用例演变示例（TC-010：用户名前后空格）
第一版（初稿）：
输入用户名
standard_user（含前后空格）预期：系统自动trim空格后成功登录
实际：登录失败，提示不匹配
结论：❌ 不通过（已提Bug）
第二版（最终修正）：
输入用户名
" standard_user "（前后各1个空格）预期：登录失败，显示“Epic sadface: Username and password do not match any user in this service”
实际：登录失败，显示“Epic sadface: Username and password do not match any user in this service”
结论：✅ 通过
备注：SauceDemo 不对用户名做 trim，带空格视为无效用户，属预期行为
五、从“第一版”到“第二版”我学到了什么
| 认知 | 第一版 | 第二版 |
|---|---|---|
| AI 的角色 | AI 生成什么，我就测什么 | AI 是初稿，我自己审查后再执行 |
| 预期结果的标准 | 大概差不多就行 | 必须确定，不能写“或” |
| 测试数据的要求 | 写个大概意思 | 必须精确到可复现 |
| Bug 的判断方式 | 和预期不一致就报 Bug | 先确认是系统设计还是缺陷 |
| 错误提示的记录 | 记个大概意思 | 完整记录，含前缀 |
六、我整理出的“AI 用例审查清单”
基于这次迭代经验，我总结了一份快速审查清单，每次收到 AI 生成的用例初稿时，按这 5 条检查一遍：
| 序号 | 检查项 | 检查方法 |
|---|---|---|
| 1 | 测试数据是否精确？ | 看到“含空格”要追问“几个空格”；看到“超长”要追问“多少字符” |
| 2 | 预期结果是否确定？ | 看到“或”字要警惕，必须改成确定的结果 |
| 3 | 错误提示是否完整？ | 是否包含产品前缀？是否与实际执行一致？ |
| 4 | 用例命名是否规范？ | 是否含内部标记？是否清晰描述了测试场景？ |
| 5 | 安全覆盖是否充分？ | 是否需要补充注入类攻击、权限验证等场景？ |
七、最终产出
| 项目 | 状态 | 说明 |
|---|---|---|
| 33条登录用例 | ✅ | 含精确步骤、确定预期、完整错误提示 |
| 6条核心用例执行记录 | ✅ | 正向/异常/边界/安全/权限全维度覆盖 |
| 截图证据 | ✅ | 关键步骤均已保存截图 |
| Bug报告修正 | ✅ | 在原 Bug 报告文档中补充修正说明（见 第一周Bug报告.docx） |
第二版最终用例分布：
| 分类 | 用例数 | 覆盖内容 |
|---|---|---|
| 正常流程 | 2条 | 有效登录、登录后状态检查 |
| 异常流程 | 4条 | 无效用户名/密码/锁定用户 |
| 边界条件 | 9条 | 空值、空格、超长输入 |
| 安全测试 | 9条 | SQL注入、XSS、路径遍历、暴力破解、信息泄露 |
| UI/交互 | 4条 | 密码掩码、Tab键、回车提交、错误关闭 |
| 兼容性 | 2条 | 大小写验证 |
| 场景法 | 3条 | 已登录访问、登出后退、未登录访问保护页 |
| 合计 | 33条 |
八、写在最后
回头看，第一周写用例时最大的问题不是“不会写”，而是“不知道自己哪里写得不对”。当时觉得“含前后空格”已经很清楚了，觉得“>2秒”已经很具体了，觉得“报Bug”就是测试的终点。
现在我知道了：测试用例不是给自己看的，是给别人也能复现的。预期结果不是“大概猜的”，是必须确定的。发现异常不等于发现Bug——先确认是设计还是缺陷。
最大的变化，不是“会写的用例变多了”，而是“知道自己哪里会写错”了。 这可能才是真正的进步吧。
九、相关资源
- 测试用例文件：
SauceDemo_登录功能测试用例_33条_最终版.xlsx - 核心用例执行记录：
核心用例执行记录.md - 完整复盘记录：
复盘记录.md - 项目仓库：software-testing-notes
标签：软件测试 AI辅助测试 测试用例 SauceDemo 功能测试
