测试用例设计不踩雷：面试官想听的回答思路

（个人简介，仅供参考）

🔥个人主页：寻星探路

🎬作者简介：Java研发方向学习者

📖个人专栏：JAVA（SE）----如此简单从青铜到王者，就差这讲数据结构！！数据库那些事！！JavaEE 初阶启程记：跟我走不踩坑测试开发漫谈

⭐️人生格言：没有人生来就会编程，但我生来倔强！！！

​

目录

1. 好的测试用例应该具备哪些东西

2. 功能测试用例设计

3. 测试用例标准化表单

4. 缺陷标准化表单

5. bug的组成

6. 做过哪些测试，整体说一下/测试分类

7. 设计测试用例的思路

8. 如何对接口设计测试用例接口主要的组成部分：请求方法、请求参数、URL、响应结果

1. 好的测试用例应该具备哪些东西

核心原则：可执行、可验证、无歧义、覆盖关键场景，让任何人照着做都能得出明确结果，同时确保测试不遗漏核心风险。

好的测试用例 =“测什么场景”（明确目标）+“怎么测”（可复现步骤）+“该怎么样”（明确结果）+“覆盖关键情况”（全面）+“独立好懂”（无依赖、简洁）。

2. 功能测试用例设计

这里主要分为三个视角去进行用例的设计：

1. 用户视角（用户会怎么用）

   1. 正常操作场景：用户常规流程使用功能，验证核心功能可用（模拟普通用户的常规操作习惯，不关注内部逻辑）

   2. 误操作场景：模拟用户可能的错误操作（如漏填、错填、重复操作），验证系统容错性

   3. 异常中断场景：操作过程中突然中断（如断网、退出 APP、刷新页面），验证数据一致性和流程恢复性

2. 功能逻辑视角（功能该怎么跑）

   1. 核心流程覆盖：功能的主流程，确保完整可用（全链路验证）

   2. 分支场景覆盖：功能中的条件判断（如支付时显示余额不足，支付密码错误）

   3. 关联功能联动：该功能与其他模块的交互（支付成功后订单状态更新）

      1. 核心流程：绑卡→输入金额→输密码→支付成功；

      2. 分支场景：支付时余额不足、支付密码输错、选择不同卡种（储蓄卡 / 信用卡）；

      3. 关联联动：支付成功后订单状态更新、退款功能与支付功能的联动。

3. 边界与数据视角（数据的临界点在哪）

   1. 数值边界：最小/最大/临界值

   2. 数据格式：合法格式、非法格式

   3. 数据量边界：数据为空、数据达上限

   4. 特殊字符：含特殊字符、空格

---

举例淘宝搜索框：

1. 用户视角

   1. 基础搜索操作：

      1. 输入“运动鞋”，验证返回结果是否包含相关商品，链接准确性

      2. 多关键词组合：输入 "耐克 运动鞋 男 42 码"，验证筛选结果是否精准

      3. 拼音搜索：输入 "yundongxie"，验证是否返回 "运动鞋" 相关结果

   2. 用户误操作场景

      1. 输入空内容：点击搜索框后直接点击搜索按钮，验证是否提示 "请输入搜索内容"

      2. 全空格输入：输入多个空格后搜索，验证是否忽略空格并正常搜索或提示

      3. 重复搜索同一词：连续搜索 "iPhone"5 次，验证历史记录排序是否更新

   3. 异常中断场景

      1. 搜索过程中退后台：输入 "连衣裙" 后，App 切至后台再返回，验证输入是否保留

      2. 搜索时断网：输入 "手机" 后断网，验证是否提示网络错误，重新联网后能否继续

2. 功能逻辑视角

   1. 搜索功能核心流程覆盖：（输入关键词 → 触发搜索 → 返回结果 → 浏览/筛选/排序 → 点击商品)

      1. 搜索触发：点击搜索按钮、键盘回车、语音输入、扫码 / 拍照搜索 (如支持)

      2. 结果展示：验证商品列表包含图片、名称、价格、评价等必要信息

      3. 结果筛选：验证价格区间、品牌、销量等筛选条件是否生效

   2. 历史记录功能流程覆盖 (首次搜索 → 记录保存 → 再次进入搜索页面 → 显示历史列表 → 点击记录重新搜索/删除/清空)：

      1. 历史触发：点击搜索框，验证历史记录是否在预设位置显示

      2. 记录点击：点击历史记录中的 "衬衫"，验证是否重新搜索该词

      3. 单条删除：长按或点击历史记录旁的删除按钮，验证对应记录是否移除

      4. 全部清空：点击 "清空历史"，验证所有记录是否删除

   3. 关联功能联动

      1. 与搜索建议联动：输入 "苹"，验证是否显示 "苹果手机"" 苹果电脑 " 等联想词

      2. 与登录状态联动：验证未登录时是否保存历史，登录后是否同步至账号

3. 边界与数据视角

   1. 输入长度边界

      1. 极短输入：1 个字符 (如 "a")，验证是否返回相关结果

      2. 极长输入：255 个字符 (超长)，验证是否截断处理或提示

      3. 临界长度：测试搜索框最大支持字符数 (如 50)，输入 50、51 个字符

   2. 特殊数据测试

      1. 特殊字符：输入 "#$%^&*()_+", 验证是否正常搜索或过滤

      2. 中文特殊符号：输入 "～！@#￥%……&*（）——+", 验证处理方式

      3. 中英文混合：输入 "iPhone 15 Pro Max 官方旗舰店"，验证解析准确性

      4. 表情符号：输入 "😊👟", 验证是否返回相关商品 (如 "笑脸鞋")

   3. 历史记录边界

      1. 记录数量上限：测试最多保存多少条历史 (如 100 条)，满额后新增是否顶掉最早记录

      2. 重复记录：连续搜索同一关键词，验证历史中是否只保留一条 (最新) 或多条

      3. 特殊记录：搜索含特殊字符的关键词 (如 "##123"), 验证能否正确保存和检索

其他角度设计

• 界面测试（好不好看、看着舒服）

  • 布局：按钮、文字、图片位置对不对？不歪不挤？

  • 样式：颜色、字体统一吗？不辣眼、没错别字

  • 反馈：点一下、加载时，有没有明显显示

• 性能测试（快不快、稳不稳、抗造不抗造）：

  • 响应快不快：操作后多久有结果

  • 用多久不崩：连续几小时、几十次，会不会卡/死机

  • 多人/多任务抗不抗住：很多人同时用、同时干多个活（比如APP同时搜/下载），会不会崩

• 兼容性测试（“在哪里都能用”）：

  • 不同设备：换个手机、电脑、家电型号，能用吗？

  • 不同环境：换个地方（比如低温、高温、弱网），能用吗？

  • 不同版本：软件更新、系统升级后，还能用吗？

• 易用性测试（用着顺、不用学就会）

  • 操作简单吗？不用看说明书就能上手

  • 犯错了好改吗？输错东西能一键清空、有提示？

  • 特殊人能用吗？比如老人、左手用户，用着方便？

• 安全测试（用着放心、不出危险/丢东西）

  • 人身或设备安全：会不会损害其他东西

  • 数据安全：会不会泄露个人信息（比如密码、地址）

  • 防篡改 / 盗用：别人能不能随便改设置、偷你的东西（比如 APP 账号、家电控制权）？

3. 测试用例标准化表单

常见通用字段及核心作用：

1. 用例 ID（唯一标识）

2. 用例标题（核心场景）

3. 所属模块（功能归属）

4. 优先级（执行顺序、重要程度）

5. 前置条件（执行前提）

6. 操作步骤（具体流程）

7. 预期结果（验证标准）

8. 执行状态（测试结果）

4. 缺陷标准化表单

1. 缺陷 ID（唯一标识）

2. 缺陷标题（核心问题概括）

3. 所属模块（功能归属）

4. 严重程度（问题影响范围）

5. 优先级（修复紧急程度）

6. 复现步骤（重现问题的操作）

7. 预期结果（应有的正确表现）

8. 实际结果（实际出现的问题）

9. 缺陷状态（处理进度：新建 / 已修复 / 关闭等）

10. 测试环境（执行环境：设备 / 系统 / 版本）

5. bug的组成

1. 基础标识：Bug 编号、所属模块、标题、报告人 / 时间，用于定位追溯。

2. 核心属性：严重程度（致命 / 严重 / 一般 / 轻微）、优先级（高 / 中 / 低）、缺陷状态，用于评估修复优先级。

3. 测试环境：系统 / 软件版本、设备型号、网络环境，明确缺陷发生场景。

4. 核心描述：前置条件、可复现步骤、预期结果、实际结果，是研发定位问题的关键。

5. 佐证材料：截图 / 录屏、日志、测试数据，辅助验证缺陷真实性。

6. 做过哪些测试，整体说一下/测试分类

• 功能测试：通过等价类边界值等方法来设计测试用例

• 自动化测试：使用selenium框架模拟人工操作浏览器（如点击、输入、跳转），验证 Web 应用功能是否符合预期，提升测试效率，减少人工重复工作量

• 接口测试：使用Postman可视化工具，无需编写代码，快速完成接口功能验证，重点校验参数合法性、返回结果正确性、状态码合规性

• 性能测试：使用JMeter模拟多线程高并发来验证对系统的整体性能情况，通过聚合报告，TPS可视化，响应时间可视化三个报告来反映系统整体性能

• 单元测试：通过Junit来验证单个方法/类的逻辑正确性

7. 设计测试用例的思路

功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试 测试用例越多越好吗？

• 不是，测试用例能够提高系统测试覆盖率就是好的测试用例

• 功能测试（能不能用，用着有没有毛病）：

  • 正常操作场景：“该干的活能不能干好”

  • 误操作场景：乱操作、输错东西、没条件（比如没网）能不能抗住？

  • 异常中断场景：参数调到最大/最小、用很久，会不会出问题

• 界面测试（好不好看、看着舒服）

  • 布局：按钮、文字、图片位置对不对？不歪不挤？

  • 样式：颜色、字体统一吗？不辣眼、没错别字

  • 反馈：点一下、加载时，有没有明显显示

• 性能测试（快不快、稳不稳、抗造不抗造）：

  • 响应快不快：操作后多久有结果

  • 用多久不崩：连续几小时、几十次，会不会卡/死机

  • 多人/多任务抗不抗住：很多人同时用、同时干多个活（比如APP同时搜/下载），会不会崩

• 兼容性测试（“在哪用都能用”）：

  • 不同设备：换个手机、电脑、家电型号，能用吗？

  • 不同环境：换个地方（比如低温、高温、弱网），能用吗？

  • 不同版本：软件更新、系统升级后，还能用吗？

• 易用性测试（用着顺、不用学就会）

  • 操作简单吗？不用看说明书就能上手？

  • 犯错了好改吗？输错东西能一键清空、有提示？

  • 特殊人能用吗？比如老人、左手用户，用着方便？

• 安全测试（用着放心、不出危险/丢东西）

  • 人身或设备安全：会不会损害其他东西

  • 数据安全：会不会泄露个人信息（比如密码、地址）

  • 防篡改 / 盗用：别人能不能随便改设置、偷你的东西（比如 APP 账号、家电控制权）？

8. 如何对接口设计测试用例接口主要的组成部分：请求方法、请求参数、URL、响应结果

• 检查数据正确性：不同的参数对应的不同接口返回结果；检查数据库数据是否正确

  • 200=>表示访问成功

  • 301=>永久重定向（当浏览器收到这种响应时，后续的请求都会被自动改成新的地址）

  • 302=>临时重定向（临时更改）

    就相当于手机号码中的"呼叫转移"功能，比如我本来的⼿机号是186-1234-5678，后来换了个新号码135-1234-5678，那么不需要让我的朋友知道新号码，只要我去办理一个呼叫转移业务，其他人拨打186-1234-5678，就会自动转移到135-1234-5678上.

    • 理解"重定向" ：

  • 404=>没有找到资源

  • 403=>表示访问被拒绝（比如没有权限）

  • 405=>方法不被允许（比如资源存在但是用的HTTP方法对URL无效）

  • 500=>服务器出现内部错误

  • 504=>当服务器负载比较大的时候，服务器处理单条请求的时候消耗的时间就会很长，就可能会导致出现超时的情况

• 不同的请求类型：get post不同的请求类型下是否符合预期

• 校验接口兼容性：传入异常数据接口是否会崩溃，接口之间互相调用的情况下是否兼容老版本的接口