HR 曾经跟我反馈过，说面试者对我颇有微词。 我问原因。 她说面试者觉得我问的问题大多是业务理解和用例设计的基础问题，并未考核他的技术能力，怎么还挂了他。 我不理解。 我陷入沉思。 我不禁要问。 谁带坏了这种风气? 难道用例设计不是测试最核心最基础的技术吗？ 新入局的兄弟们是不是真的了解这个职业的工作内容？

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

都不是

（顺便吆喝一句，民族企业核心部门年底前的一波岗，base 武汉、深圳、苏州等地，前、后端 or 测试>>>机会；语言：Java、Js、测试、python、ios、安卓、C++ 等！

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

业务需求分析拆解（18%） 需求会议评审（2%） 手工测试执行（15%） 测试用例设计与维护（14%） 缺陷跟踪与复现（12%） 测试环境部署验证（10%） 自动化实现与维护（9%） 跨部门需求对齐（8%） 测试数据/物料准备（7%） 冒烟测试执行（4%） 新技术调研/工具研发（1%） 测试设计相关（1+3+4+5+6+10）耗时占比达 73%，如果这个比例不高，离裁员不远了 沟通表达相关（2+8+9）耗时占比达 17% 编码相关工作（7+11）仅占 10% 因此，这也是为什么我会主要问测试用例设计的能力， 用例设计 是测试最基础最核心的技术能力 沟通表达 是保证工作流程顺利的重要能力 研发相关技术能力：是提升上面两个能力的有效辅助

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

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

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

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

这个功能的目标用户是谁？有没有特殊用户群体需要考虑？（比如新用户/老用户/管理员） 有没有具体的业务规则需要遵循？如，密码复杂度要求、登录失败锁定策略？ 这个功能依赖哪些外部系统或数据（比如数据库、第三方认证服务）？ 有没有性能、安全性或兼容性方面的具体要求？ 你更关注核心流程的验证，还是希望覆盖尽可能多的边界情况？ 很多人一看面试官提问题，就会不假思索的开始各种套路模板的述说。我更建议互动起来，就跟你平常和产品经理聊需求一样，不假设，而是通过沟通明确需求，避免遗漏重要方面，体现你的专业性和沟通能力。

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

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

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

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

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

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

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

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

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

1. 列出关键测试用例 不需要列出所有细节，但给出类别和代表性例子。清晰说明输入、操作步骤、预期输出。 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 等）的测试点，体现全面性。

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

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

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

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

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

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

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

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

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

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

转自：小黑子-IKUN 原文链接：https://testerhome.com/topics/42551