面灵AI→

捷螺智能设备 机器人测试两轮面经:自动化稳定性与权限越权测试

轮次
多轮面试合集
时间
2026-08
来源
牛客网

《面试题目》

一面(2026/8/12 下午 16:00)

  1. 英文自我介绍
  2. 大概介绍一下项目的完整业务流程
  3. 项目中不同角色的权限区分怎么测试的?
  4. 测试用例怎么分类的?有没有哪些不合理的用例?
  5. 微信小程序自动化测试过程出现弹窗怎么处理?
  6. 接口测试怎么做?
  7. Linux 系统了解多少?
  8. 版本发布前完整的测试流程是什么?你实习的时候大概多久发版一次?
  9. 自动化测试失败后怎么区分是产品的 bug 还是脚本的 bug?
  10. 自动化测试流程中,测试数据的生成和清理是怎么做的?
  11. 怎么保证测试用例覆盖率的?
  12. 需求文档不全的情况下怎么开展测试?
  13. 自动化测试不稳定怎么优化?
  14. bug 偶现怎么处理?
  15. 测出来越权访问怎么处理?
  16. 为什么选择做测试?
  17. 反问

二面(2026/8/21 上午 11:00)

  1. 介绍一下之前做过的项目
  2. git 合并分支怎么操作?
  3. git 代码版本不同步怎么解决?
  4. 有没有 Jenkins 的实操经验?
  5. 有没有用过网络抓包工具?
  6. 毕业设计做的是哪方面的项目?有没有英文答辩的经历?
  7. 机器人测试需要懂一点嵌入式,Linux 这方面有经验吗?
  8. 介绍自己学习的特质,能接受学习机器人测试的新知识吗?
  9. 学习过程中遇到困难怎么应对的?
  10. 能不能接受海外出差和加班?
  11. 反问

《参考解析》

  1. 权限区分怎么测:先画出角色与资源的矩阵(角色 × 功能 × 数据范围),再按矩阵补用例——正向是各角色能访问自己该访问的;反向是越权,分水平越权(同级用户 A 改 URL 参数访问 B 的数据)和垂直越权(低权限用户直接调高权限接口)。接口层面可以拿一个低权限 token 重放高权限请求,看服务端是否只依赖前端隐藏菜单做控制。权限区分是一面问到的重点,也是这类 To B 系统的高频考点,答的时候把「矩阵 + 正反向 + 接口层重放」说出来就够了。

  2. 自动化失败怎么判责:先看失败位置与报错类型——脚本侧的典型是元素找不到、等待超时、断言数据过期、环境没起;产品侧的典型是接口返回结构变化、业务流程真的断了、数据状态不符合预期。工程上要把失败现场留全(截图、DOM 快照、请求与响应日志、traceId),再用同一用例手工复现一次来定性;长期做法是维护一份「已知不稳定用例」清单并单独看护,不要让它污染整体通过率。

  3. 小程序自动化的弹窗怎么处理:弹窗来源一般有三类——授权类(位置、通知、用户信息)、运营类(活动、更新提示)、系统类(网络异常提示)。做法是封装统一的弹窗处理钩子,在每次元素查找前的隐式等待里探测常见弹窗并关闭,同时给授权类弹窗准备预设状态(提前写入授权或直接用测试专用包),别每次都靠点击。稳定性靠「探测优先、点击兜底、失败留现场」。

  4. 测试数据生成与清理:生成侧按业务约束造合法的唯一数据(手机号、单号带时间戳或随机后缀),有依赖关系的数据按顺序构造;清理侧给测试数据打统一标记后批量删除,或使用独立测试账号与租户。要注意软删除与级联关系,避免残留数据影响下一轮;并发执行时用数据命名空间隔离。

  5. 需求文档不全怎么测:从已有的原型、接口文档、历史版本和竞品行为里反推预期;把不确定点整理成问题清单,找产品与开发确认并把结论回写到用例里,避免口头约定丢失。同时用探索性测试补文档覆盖不到的分支,对高风险路径加自动化回归。面试官想听的是「你怎么在信息不足的情况下推进」,而不是抱怨文档不全。

  6. 偶现 bug 怎么处理:先提升复现概率——收集日志与请求记录、放开并发或时序条件、用相同数据重放;再缩小范围,二分定位到具体模块或时间窗。留下带时间戳与上下文的证据(traceId、录屏、堆栈),在缺陷单里写清尝试过的复现条件与失败次数。判断为低概率但影响大(数据错乱、资金类)的必须升级处理,不能因为「偶现」就搁置。

  7. Git 分支合并与版本不同步:合并用 git merge(保留分支历史)或 git rebase(把本地提交搬到目标分支顶端,历史更线性);冲突时先 git status 看冲突文件,手动改完 git add 再 git rebase --continue / git commit。代码不同步的常见处理是 git fetch origin 后看 git log HEAD..origin/main 的差异,本地有未提交改动先 stash,再 rebase 到最新。团队里更关键的是约定好主干与发布分支的流转规则。

  8. Jenkins 实操要能讲一条完整流水线:拉代码(凭据 + 分支参数)→ 装依赖缓存 → 跑单测与静态检查 → 构建镜像或产物 → 部署到测试环境 → 触发自动化用例 → 通知(邮件或群机器人)。追问点通常在「怎么看结果」和「失败了怎么办」:用构建历史与测试报告定位失败用例,通过重跑参数区分环境抖动与真实失败,并把结果回写到提交或缺陷系统。