• HR 曾经跟我反馈过，说面试者对我颇有微词。
• 我问原因。
• 她说面试者觉得我问的问题大多是业务理解和用例设计的基础问题，并未考核他的技术能力，怎么还挂了他。
• 我不理解。
• 我陷入沉思。
• 我不禁要问。
• 谁带坏了这种风气?

难道用例设计不是测试最核心最基础的技术吗？
新入局的兄弟们是不是真的了解这个职业的工作内容？

是幻想天天 搞开发、安全、性能、架构、AI、运维、云原生
还是 和开发吵架，然后把开发的活干了，让他心服口服？

都不是

普罗大众的测试日常基本都是围绕以下这几个，我象征性的给了比例：

1. 业务需求分析拆解（18%）
2. 需求会议评审（2%）
3. 手工测试执行（15%）
4. 测试用例设计与维护（14%）
5. 缺陷跟踪与复现（12%）
6. 测试环境部署验证（10%）
7. 自动化实现与维护（9%）
8. 跨部门需求对齐（8%）
9. 测试数据/物料准备（7%）
10. 冒烟测试执行（4%）
11. 新技术调研/工具研发（1%）

• 测试设计相关（1+3+4+5+6+10）耗时占比达 73%，如果这个比例不高，离裁员不远了
• 沟通表达相关（2+8+9）耗时占比达 17%
• 编码相关工作（7+11）仅占 10%

因此，这也是为什么我会主要问测试用例设计的能力，
用例设计 是测试最基础最核心的技术能力
沟通表达 是保证工作流程顺利的重要能力
研发相关技术能力：是提升上面两个能力的有效辅助

我主问用例设计
是因为我没有脱离群众

回到开头，面试时，一个好的测试用例设计回答应该是怎样的？
我问你某个场景需求的用例设计
是考察你测试思维、分析能力、沟通技巧和系统化方法的绝佳方式
所以面试者不能一直自己在说，而是要学会互动起来

如最最最最烂大街的问题 A： 用户登录功能的用例

1. 确认需求、理解场景与有效沟通

B： 好的，针对你提到的用户登录功能设计测试用例，我理解我们需要验证的是用户登录的这一流程，为了能设计更全面的用例，我想确认几个点：

• 这个功能的目标用户是谁？有没有特殊用户群体需要考虑？（比如新用户/老用户/管理员）
• 有没有具体的业务规则需要遵循？如，密码复杂度要求、登录失败锁定策略？
• 这个功能依赖哪些外部系统或数据（比如数据库、第三方认证服务）？
• 有没有性能、安全性或兼容性方面的具体要求？
• 你更关注核心流程的验证，还是希望覆盖尽可能多的边界情况？

很多人一看面试官提问题，就会不假思索的开始各种套路模板的述说。我更建议互动起来，就跟你平常和产品经理聊需求一样，不假设，而是通过沟通明确需求，避免遗漏重要方面，体现你的专业性和沟通能力。

2. 确定测试范围和目标

B: 基于这个场景，我认为核心要测试的功能点包括：
[列出 1-3 个最关键的点如：1. 使用有效凭据登录成功 2. 处理无效凭据登录失败 3. 记住登录状态]，
除了功能正确性，我认为还需要关注：[例如：安全性（防暴力破解、密码存储/传输）、用户体验（错误提示清晰度、响应速度）、兼容性（不同浏览器/设备）]

让面试官知道你有大局观，知道测试不仅仅是 “点按钮”，还要考虑质量的不同维度。

3. 应用测试设计技术

B ： 我会结合使用几种测试设计技术来确保覆盖度：

• 等价类划分 & 边界值分析： 这是最基础的。例如对于用户名和密码字段，我会划分有效等价类（正确用户名/密码）、无效等价类（错误用户名、错误密码、两者都错、空用户名、空密码、超长用户名/密码、特殊字符用户名/密码）。边界值比如密码最小长度、最大长度。”

• 决策表/因果图： 如果登录逻辑涉及复杂条件组合（例如：记住我 + 自动登录 + 首次登录/非首次登录），我会用决策表来梳理所有可能的组合和预期结果。

• 状态转换图： 如果登录状态有流转（例如：未登录 -> 登录中 -> 登录成功/失败 -> 登出），我会用状态图来设计覆盖各个状态和转换的用例。

• 错误推测法： 基于经验，我会考虑一些常见的错误场景，例如：网络中断时登录、重复快速点击登录按钮、登录后修改密码再尝试用旧密码登录（如果会话管理不当）、SQL 注入/XSS 尝试等。

• 场景法： 我会模拟真实用户的典型操作路径，例如：打开 App -> 进入登录页 -> 输入正确信息 -> 登录成功进入首页 -> 登出。同时也会考虑异常路径，如登录失败后重试、忘记密码流程的衔接。

展示你掌握专业的测试设计方法，而不是凭感觉罗列用例

4. 列出关键测试用例

不需要列出所有细节，但给出类别和代表性例子。清晰说明输入、操作步骤、预期输出。
B：

• 功能 - 正向：

  • 1: 输入有效的用户名和密码 -> 点击登录 -> 成功跳转到指定页面，用户会话建立。
  • 2: 输入有效用户名和密码，勾选 “记住我” -> 点击登录 -> 登录成功，关闭浏览器再打开，应保持登录状态（需澄清 “记住我” 的具体实现）。

• 功能 - 负向：

  • 3: 输入有效用户名 + 错误密码 -> 点击登录 -> 登录失败，提示 “用户名或密码错误” (提示信息需明确，不透露是用户名错还是密码错)。
  • 4: 输入错误用户名 + 有效密码 -> 点击登录 -> 登录失败，提示同上。
  • 5: 用户名字段留空 + 输入任意密码 -> 点击登录 -> 提示 “请输入用户名”。
  • 6: 输入有效用户名 + 密码字段留空 -> 点击登录 -> 提示 “请输入密码”。
  • 7: 连续 N 次（如 5 次）登录失败 -> 账户应被临时锁定（需澄清锁定策略）-> 提示 “账户已锁定，请 XX 分钟后重试或联系管理员”。
  • 8: 输入超长用户名/密码（超过字段定义）-> 系统应妥善处理（如前端截断、后端拒绝并报错），不应崩溃。

• 安全性：

  • 9:验证登录请求是否通过 HTTPS 加密传输（密码明文传输是严重漏洞）。
  • 10:登录成功后，检查 Cookie/Session ID 是否设置了 HttpOnly 和 Secure 属性

• 用户体验：

  • 11:登录过程中，应有明确的加载状态指示（如按钮变灰、旋转图标）。
  • 12:错误提示信息应清晰、友好、指导性强（如 “密码错误” 比 “登录失败” 更好；“账户未激活，请查收邮件激活”）。
  • 13:提供 “忘记密码？”、“注册新账号” 等辅助功能的可见且可用的入口。

• 兼容性：

  • 在不同浏览器
  • 在不同操作系统
  • 在不同设备尺寸（桌面、平板、手机）

• 性能 (如果场景要求)：

  • 单用户登录操作的响应时间应在可接受范围内（如<2 秒）。
  • 模拟多用户并发登录，系统应能处理且响应时间在可接受范围内，无错误率飙升。

• 可访问性：

  • 使用键盘可以完成所有登录操作（Tab 键切换焦点，Enter 键提交）。
  • 登录表单元素有正确的标签，屏幕阅读器可以正常读取。

目的： 展示你能覆盖不同维度、不同优先级（正向、负向、安全、UX 等）的测试点，体现全面性。

5. 考虑测试数据和环境 :

测试数据： “设计用例时我会考虑准备不同的测试数据：有效用户账号、无效账号、被锁定账号、不同权限的账号（如果系统有权限区分）、带特殊字符的用户名/密码等。”
环境： “我会考虑在不同环境测试：开发环境、测试环境、预发布环境。明确是否需要模拟特定的网络条件（如弱网、断网）。”

目的： 展示你理解测试执行的准备工作。

6. 优先级与风险评估

• 说明优先级： 在资源有限的情况下，我会优先执行核心正向路径（1）和关键的负向路径（3, 4, 5, 6）以及高安全风险的用例。账户锁定和性能也很重要。

• 风险评估： “我认为最高风险点是安全漏洞（如密码泄露、注入攻击）和核心功能失效（所有人无法登录）。其次是糟糕的用户体验（如错误提示不清导致用户困惑）和账户锁定策略失效（如无法锁定暴力破解）。”

目的： 展示你具备风险意识，知道如何合理分配测试资源。

7. 总结与开放性:

来个总结： “综上所述，我会围绕功能正确性、安全性、用户体验、兼容性等维度，运用等价类、边界值、错误推测等方法，设计覆盖核心流程、主要异常、边界条件和安全风险的测试用例集。”

寻求反馈： “这是我初步的思路，你觉得是否覆盖了你关心的重点？或者您希望我在某个方面再深入展开一下吗？” 或者 “在实际项目中，我还会参考需求文档、与开发和产品经理进一步沟通来完善这些用例。”

目的： 展示沟通闭环和持续改进的意愿。

一般这样一整套下来，我相信只要是价值观正向的面试官，基本都会觉得你沟通能力和基础不错

最后
社会里有一小部分人
会以工资高低论英雄
会以开发能力论测试能力
但是我希望你能回归到现实
无关岗位，大部分人工资都是不高的，不要觉得工资待遇和能力水平是等价的，时间、机遇、市场环境都是因素
测试的工作内容也是测试，大部分人遇不到什么高大上的场景和技术
每个人的境遇都不同
但绝大多数测试工作的内容会一致
那就是做测试工作