比孚信息科技测试开发面经：一天两面的完整题目

《面试题目》

一面（约 42 分钟）

1. 请做一下自我介绍。
2. 介绍一下你的实习业务。
3. 这段实习里你做的测试工作是什么？可以详细聊一下吗？
4. 现在有一个用于提测的表单，类似运维工单，包含工单信息填写和附件，你会怎么设计测试？
5. 进入一个新团队，你会怎么解决第一个任务、怎么快速适应？
6. 你做过哪些测试？
7. 返回 200 但是却没有数据，你会怎么排查？

二面（约 30 分钟）

8. 请做一下自我介绍，并讲一下你简历里这个业务报表、数据分析的 Agent。
9. 你写的 CSR、ISR（评测指标）是什么？
10. SWE-Bench 系列难题通过率提升约 25%+、单任务推理成本降低约 30%+，这些指标你们是怎么计算的？
11. 429 退让是什么意思？
12. 你负责了哪个 Rubric 条目？这四项条目详细讲一下。
13. 你做过漏洞扫描、渗透测试吗？可以简单聊聊。
14. 你做过性能测试吗？用的什么工具？会看哪几个参数？
15. Selenium 自动化测试你会怎么设计，会看哪些参数？
16. Cookie 和 Session 有什么区别？
17. Token 认证你了解吗？知道 JWT 吗？说一下它的认证原理和过程：谁去签发这个 token，它包含哪些内容？
18. 接口测试你用什么？在 Postman 中你是怎么调接口做测试的？
19. 用简短的两句英语说一下你在那家公司实习学到的东西。

《参考解析》

提测表单这类「业务表单」怎么设计测试。 先把需求拆成可验证的维度，再逐维度出用例：① 字段级——必填与选填、类型与长度边界（0、1、最大、超长）、枚举取值、格式校验（时间、编号、手机号）、特殊字符与前后空格、中文与 emoji；② 业务规则级——工单编号唯一性与前后一致性（提交后回显与入库一致）、状态流转是否合法（不能跳状态、不能重复提交）、字段之间的联动与互斥；③ 附件级——大小上下限、类型白名单（改扩展名绕过）、个数上限、上传中断与断点续传、重名覆盖、下载与预览是否可打开、含病毒文件与超长文件名；④ 权限与流程——不同角色的可见与可编辑范围、越权访问他人工单、审批人与抄送人规则；⑤ 异常与并发——网络超时重试是否产生重复工单（幂等）、两人同时编辑同一单的冲突处理、提交成功但消息通知失败的补偿；⑥ 非功能——大数据量下的列表分页与查询性能、日志与审计是否留痕。回答时给一句收尾：先按「正常路径—边界—异常—权限—并发」排序，再按投入产出比挑优先级，比一次报几十条散点用例更像做测试的人。

「返回 200 但没有数据」的排查顺序。 200 只说明 HTTP 层通了，不代表链路对，所以按数据流自后向前收窄：先看请求本身是否带对了参数（查询条件、日期区间、分页 page/size、排序字段），再看响应体结构（是空数组、null 还是异常包裹成功码）以区分「查不到」和「没返回」；接着确认鉴权与租户上下文（token 有效但查的是别人的数据、切了环境），以及前端渲染层（字段名与后端不一致、大小写、数组和对象结构变化、前端过滤条件把结果滤空）。后端侧依次核对：SQL 条件是否命中（拿日志里的实际 SQL 手工执行）、索引与数据是否真的存在（换一个已知有数据的条件对照）、分页越界（第 2 页但总数只有 1 条）、多数据源或读写分离的主从延迟、缓存里存了空值或旧 key。最后看中间层：网关与 BFF 是否做了字段裁剪、序列化配置是否把空字段丢掉、灰度环境连的是哪个库。排查动作要可复现：固定请求参数、抓完整链路日志与 traceId，把「现象—假设—验证」记下来，这类问题事后基本都会变成回归用例。

Agent 项目的评测口径：CSR/ISR、SWE-Bench、429 与 Rubric。 这类缩写在面试里第一件事是确认定义，因为各家叫法不统一——CSR 常见的口径是任务完成率（Completion Success Rate），ISR 常见的是指令遵循率（Instruction Success Rate），二者分子分母必须说清楚（分母是全部任务还是可判定任务、判分是人工还是规则/模型裁判）。SWE-Bench 一类的通过率通常按 pass@1 计算：用官方 harness 在固定仓库与版本上跑测试，解决任务数 / 任务总数；成本口径则是该批次消耗的 token 或金额除以任务数（要说明是否含重试与失败任务的消耗），把「通过率提升 25%+」说成相对提升还是绝对提升也很关键——相对提升在低基线下很容易被夸大。429 是 HTTP 的「请求过多」状态码，服务端限流时返回，客户端要做退让（backoff）：指数退避加随机抖动、尊重 Retry-After、限制并发与重试上限，并且要区分「限流重试」与「业务失败重试」，幂等接口才能安全重放。Rubric 是评分表式的评测方式，把「好答案」拆成若干可勾选的条目（如正确性、完整性、格式、引用、工具使用），逐条判定后加权汇总；被追问「四项条目」时要能逐条讲清判定标准与例外，并说明为什么这么拆能覆盖真实失败模式。

通用测试基础：安全测试、性能测试、Selenium、Cookie/Session、JWT、Postman。 安全测试要先区分漏扫与渗透：漏扫是用工具（AWVS、Nessus 等）按特征库批量发现已知问题，输出多但误报率高；渗透是人工按攻击路径验证可利用性，覆盖逻辑漏洞（越权、支付篡改、验证码绕过）。性能测试的指标分两头：响应时间看平均、P90/P95/P99 而不是只看均值，吞吐看 TPS/QPS，同时盯并发数、错误率与资源水位（CPU、内存、连接数、慢 SQL），并且必须说明压测的模型（梯度加压、持续时长、数据量与是否含思考时间），否则数字没有意义。Selenium 侧关注定位方式是否稳定（避免脆弱的绝对路径 XPath，优先 id 与 data 属性）、显式等待替代强制 sleep、失败重试与截图留证、用例间数据隔离，以及在 CI 里并发执行时的会话冲突。Cookie 与 Session 的核心差异是存储位置与状态归属：Cookie 存在客户端、每次请求自动带上，Session 的数据存在服务端、客户端只拿一个会话 ID（通常也放在 Cookie 里），因此 Session 更适合放敏感信息但要多考虑服务端存储与集群共享。JWT 是自包含的令牌，形如 header.payload.signature 三段 Base64URL，前两段是明文可读的声明（用户标识、过期时间、签发方、权限），第三段是对前两段的签名，用于验真伪；由认证服务在登录通过后用私钥（或 HMAC 密钥）签发，资源服务用公钥（或同一密钥）验签而不查库，代价是签发后无法直接撤销，只能靠短过期时间加刷新令牌、黑名单或版本号来兜。面试里值得主动提一句：JWT 的 payload 不要放敏感信息，而且必须校验 alg 防止算法混淆。Postman 做接口测试的要点是把环境变量与密钥抽出来（dev/test/prod 切换）、写断言（状态码、字段类型、业务码、响应时间）、用 pre-request 脚本造签名与时间戳、把接口组织成集合后用 Runner 或 newman 做批量与 CI 回归，并覆盖异常分支（缺参、越权、重复提交）。最后一题用英语自我介绍式的收获总结，提前准备两句「技术 + 协作」的短句即可，不用长。