衡泰技术测试工程师笔试：五类题型与四道问答真题复盘

《面试题目》

1. 单选题覆盖了哪些方向？
2. 不定项选择题考了哪些内容？
3. 填空题考查了哪些 Linux 命令？
4. 给出一个缺陷情境，应该怎么分析这个 bug、怎么测试并验证修复？
5. 给出公式的应用题应该怎么下手？
6. 系统马上要上线但还有改动，回归范围应该怎么确定？
7. 开发说这个缺陷不影响上线、可以下次再解决，应该怎么处理？
8. 编程题：给定一张表，怎么用 SQL 按条件分组查询并按倒序排列？

---

《参考解析》

卷面结构与时间分配是这场笔试最容易吃亏的地方。 五部分、五大类题型的卷子，知识点覆盖面很广但单题不难：单选混了测试理论、行测和数学应用题；不定项考 SQL 与国产数据库产品、测试工具的功能；填空全是 Linux 命令；问答四道（缺陷分析、套公式计算、上线前回归范围、缺陷定级争议）；编程只有一道 SQL。复盘里最值得记的一条是时间——问答题写得太满，最后编程题来不及看，而编程题本身并不难。稳妥的打法是拿到卷子先花两三分钟扫全卷，给问答和编程各留出下限时间（例如问答每道不超过 8 分钟、编程至少留 15 分钟），卡住的题先标记跳过，别在一道题上把后面的分丢掉。

Linux 命令填空的高频考点。 「日志滚动」「确定关键字的行数」「日志最后 100 行」「修改文件权限」这几类几乎是测试岗笔试的固定动作，要练到能默写：

• 看日志末尾：tail -n 100 app.log（实时跟踪用 tail -f app.log，配合 grep 过滤 tail -f app.log | grep ERROR）。
• 统计关键字出现的行数：grep -c "ERROR" app.log（-c 统计的是匹配的行数不是出现次数，要统计次数用 grep -o "ERROR" app.log | wc -l）。
• 日志滚动：手工切割是 mv app.log app.log.20261010 && touch app.log，线上更规范的做法是 logrotate——按大小或日期轮转、压缩历史、保留 N 份，配置写在 /etc/logrotate.d/ 下；如果程序持有文件句柄，切割后需要 kill -USR1 <pid> 通知它重开日志文件。
• 修改权限：chmod 用数字法（chmod 644 file、chmod 755 script.sh、chmod -R 750 dir）或符号法（chmod u+x file、chmod go-w file），改属主属组是 chown user:group file。
• 顺带把测试常用的几条一起记住：查文件行数 wc -l、按内容找文件 grep -rn "关键字" ./、查磁盘 df -h / du -sh *、看端口占用 netstat -tunlp | grep 8080 或 ss -tunlp、找文件 find . -name "*.log" -mtime +7、看进程 ps -ef | grep java。

缺陷情境题怎么答。 这类题给一段情境让你「分析怎么测试和修复验证」，评分点是流程是否完整、有没有证据意识。按这条线答：① 复现与确认——把现象、环境、前置条件、复现步骤固化下来，先在测试环境稳定复现，判断是必现还是偶现（偶现要记录频率、并发条件、数据特征）。② 定位与影响面——结合日志与报错定位到哪一层（前端、接口、服务、数据库、第三方），同时判断影响范围：哪些功能、哪些用户群、哪些数据、是否涉及资金或合规。③ 设计用例——正常场景、边界值、异常输入与并发场景都要覆盖，尤其要覆盖「修复可能引入的新问题」那一侧。④ 修复验证——不只是重跑原用例，还要跑回归用例、关联模块的冒烟，并在修复后确认数据是否需要对历史脏数据做订正。⑤ 收尾——记录验证结论与遗留风险，补上能防止同类问题再发生的自动化用例或监控告警。答题时把「先复现、有日志、能回归」这三点明确说出来，比罗列测试方法的名字得分高。

应用题的公式怎么用。 给公式的应用题基本是「套进去就能算」，失分往往不在公式而在过程：先把题目里的变量逐个列出来并统一单位（秒/分钟、字节/KB、比率与百分数别混），再写出用到的公式（如利用率 U = 到达率 × 服务时间、排队论里的 L = λW、可靠性里的串联 R = ∏R_i、可用性 A = MTBF / (MTBF + MTTR)），最后代入并写清中间步骤。留一位有效数字的取舍也要说明。别因为「看起来太简单」就怀疑自己——按部就班写清过程即可，写清过程本身就能拿到步骤分。

上线前改动的回归范围怎么确定。 判断依据是改动的影响面，不是「改了哪几个文件」：① 先看变更内容——是新增功能、修改逻辑还是只改了配置与文案，改动点在调用链的哪个位置；② 顺着调用链找上下游——被改动的模块谁在调用、它又依赖谁，接口契约有没有变（字段、状态码、超时）；③ 按风险分级挑范围：核心链路（资金、登录、主流程）必跑全量，改动点及其直接上下游做完整功能回归，间接关联模块做冒烟或抽样，与改动完全无关的模块只做冒烟确认；④ 结合历史数据缩小范围——这个模块近期事故多、这次改动大（diff 行数、涉及表结构或并发逻辑）就扩大；⑤ 兜底方案要一起上——灰度发布、开关与回滚预案、上线后的监控与日志观察点，以及回归结论由谁签字。答题的收尾句可以说「回归范围是风险评估的结果，范围之外的部分要有明确的理由」。

开发说「这个缺陷不影响上线」怎么处理。 核心原则是：不能靠口头结论放行，要靠评估和留痕。步骤是：① 让开发说清判断依据——缺陷的触发条件是什么、影响哪些功能与用户、有没有临时规避手段、修复成本多大；② 测试侧独立评估影响面，把缺陷按严重程度（是否阻断主流程、是否造成数据错误或资金损失、是否有合规风险）和使用频率定级，并给出具体的复现路径作为证据；③ 走升级与评审——与开发、产品（必要时加上业务方）对齐，由有决定权的一方拍板是本期修、带规避上线还是接受风险，结论写进缺陷单与上线检查单；④ 如果确实带缺陷上线，必须有配套的监控告警、用户反馈收集、以及明确的后续修复排期和跟进人；⑤ 测试的立场是把风险说清楚、把证据留全，既不做「我说没问题」的背书，也不替业务方决定接不接受风险。

SQL 编程题：分组加倒序。 这类题的写法是固定的四件套——SELECT 里放分组字段和聚合函数，WHERE 过滤原始行，GROUP BY 分组，ORDER BY 排序（倒序加 DESC），需要过滤聚合结果时再用 HAVING。例如「按部门分组统计人数和平均薪资，按平均薪资倒序，只看人数超过 3 的部门」：

SELECT dept_id,
       COUNT(*)      AS emp_cnt,
       AVG(salary)   AS avg_salary
FROM   employee
WHERE  status = 1
GROUP  BY dept_id
HAVING COUNT(*) > 3
ORDER  BY avg_salary DESC;

要点有三个：WHERE 在分组前过滤、HAVING 在分组后过滤，两者不能互换；SELECT 里只能出现分组字段和聚合函数（否则在严格模式下会报错）；排序默认 ASC，倒序必须显式写 DESC，多字段排序时逐个指定方向。写完顺手检查一遍「空值会不会影响聚合」（COUNT(*) 与 COUNT(列) 结果不同、AVG 会跳过 NULL），这类坑在现场很容易漏。