📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）
📝 职场经验干货：
-
HR 曾经跟我反馈过，说面试者对我颇有微词。
-
我问原因。
-
她说面试者觉得我问的问题大多是业务理解和用例设计的基础问题，并未考核他的技术能力，怎么还挂了他。
-
我不理解。
-
我陷入沉思。
-
我不禁要问。
-
谁带坏了这种风气?
难道用例设计不是测试最核心最基础的技术吗？
新入局的兄弟们是不是真的了解这个职业的工作内容？
是幻想天天搞开发、安全、性能、架构、AI、运维、云原生，还是和开发吵架，然后把开发的活干了，让他心服口服？
都不是！
普罗大众的测试日常基本都是围绕以下这几个，我象征性的给了比例：
-
业务需求分析拆解（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:好的，针对你提到的用户登录功能设计测试用例，我理解我们需要验证的是用户登录的这一流程，为了能设计更全面的用例，我想确认几个点：
-
这个功能的目标用户是谁？有没有特殊用户群体需要考虑？（比如新用户/老用户/管理员）
-
有没有具体的业务规则需要遵循？如，密码复杂度要求、登录失败锁定策略？
-
这个功能依赖哪些外部系统或数据（比如数据库、第三方认证服务）？
-
有没有性能、安全性或兼容性方面的具体要求？
-
你更关注核心流程的验证，还是希望覆盖尽可能多的边界情况？
很多人一看面试官提问题，就会不假思索的开始各种套路模板的述说。我更建议互动起来，就跟你平常和产品经理聊需求一样，不假设，而是通过沟通明确需求，避免遗漏重要方面，体现你的专业性和沟通能力。
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. 总结与开放性:
来个总结： “综上所述，我会围绕功能正确性、安全性、用户体验、兼容性等维度，运用等价类、边界值、错误推测等方法，设计覆盖核心流程、主要异常、边界条件和安全风险的测试用例集。”
寻求反馈： “这是我初步的思路，你觉得是否覆盖了你关心的重点？或者您希望我在某个方面再深入展开一下吗？” 或者 “在实际项目中，我还会参考需求文档、与开发和产品经理进一步沟通来完善这些用例。”
目的： 展示沟通闭环和持续改进的意愿。
一般这样一整套下来，我相信只要是价值观正向的面试官，基本都会觉得你沟通能力和基础不错。
最后
社会里有一小部分人,会以工资高低论英雄,会以开发能力论测试能力,但是我希望你能回归到现实。
无关岗位，大部分人工资都是不高的，不要觉得工资待遇和能力水平是等价的，时间、机遇、市场环境都是因素。
测试的工作内容也是测试，大部分人遇不到什么高大上的场景和技术，每个人的境遇都不同，但绝大多数测试工作的内容会一致，那就是做测试工作。
最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
扫一扫
835
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
