1. 这份笔试考的是什么整体设计与考察思路拆解广联达2018年那场测试工程师校招笔试我印象很深。当时岗位面向计算机相关专业挂在名字里的“计算机相关专业”六个字就很说明问题他们不想要只会点按钮的功能测试而是想招能跟开发顺畅沟通、能理解系统底层逻辑、能自己动手解决问题的人。整套卷子做完我的第一反应是——题不难但很“密”覆盖范围广每道题都在逼你把知识用起来而不是背概念。作为后来自嘲“用笔试当敲门砖”的过来人我想把这套题完整复盘一遍。它不只是广联达一家的风格也是2018年前后国内中大型软件企业测试岗位笔试的典型样本。如果你是正在准备测试笔试的应届生、打算从开发或运维转测试的工程师或者想系统梳理测试岗位知识体系的朋友这篇文能帮你少走不少弯路。1.1 从岗位JD反推笔试重点当年广联达测试工程师的JD里明确写了“计算机相关专业”“熟悉软件测试流程”“有自动化测试或性能测试经验者优先”之类的要求。从这条JD回推卷面设计就能看出笔试在刻意筛选三类能力技术基础、测试思维、问题定位能力。广联达是做建筑行业信息化软件的公司产品线涉及造价、算量、施工管理、BIM协同这类业务逻辑复杂的领域。这类软件不像电商App那样页面简单、流程短而是存在大量专业术语、角色权限、数据关联。所以笔试里测试理论部分不会只问“什么是黑盒测试”而是更侧重“给你一个复杂业务场景你怎么设计用例”。另外因为建筑软件的数据精度要求高、逻辑链路长卷子里对数据库和Linux的考查比例也明显偏高这和互联网公司“重框架、重算法”的风格有一定差异。这套题从结构上大体分成五个模块计算机基础、测试理论与用例设计、数据库与Linux操作、编程逻辑题、开放性场景题。分值占比大致是计算机基础30%、测试理论25%、数据库与Linux 20%、编程与逻辑15%、场景题10%。整体看下来纯背书能拿到的分有限拉开差距的都在分析和设计题上。1.2 为什么计算机相关专业要考这么多基础很多准备测试岗的同学会问测试不是点点点吗为什么要考数据结构、考操作系统、考计网这个问题我在入了行之后才彻底想明白。测试工程师本质上是一个“质量守门员”日常工作中做的每一件事都需要基础功底托底。比如定位线上问题你得会看Linux日志、会用命令查端口和进程排查数据问题你得会写SQL去比对预期结果评估一个接口的性能瓶颈你得理解并发、锁、内存这些概念设计自动化测试框架你又绕不开数据结构、编程语言的运行机制。计算机基础不是用来直接解题的但它是你理解“系统为什么会这样工作”的底层框架。有一道我至今记得的投资回报率极高的题“进程和线程的区别”。这道题几乎年年出现在各种测试笔试里。很多人能背出“进程是资源分配的基本单位线程是CPU调度的基本单位”但面试官真正想听的是你能不能结合场景说清楚——为什么一个进程崩溃不一定影响其他进程而一个线程死锁可能拖垮整个服务。一个测试工程师如果连这点都讲不明白遇到多线程并发类的bug时基本无从下手。2. 计算机基础题看似送分实则是淘汰栏2.1 数据结构与组成原理的常见出题方式计算机基础这一块卷子里出题方式很典型选择、填空为主偶尔穿插简答。数据结构部分常考栈与队列的区别、二叉树三种遍历、常用排序算法的时间复杂度与稳定性、哈希表冲突解决方案。这里有一个规律出题人不会让你手写红黑树但一定会用选择题考验你“遇到场景选哪种结构”。比如括号匹配、函数调用、浏览器后退功能对应的数据结构是栈打印机任务、消息队列对应的是队列。这种题目考的不是记忆而是你能不能把抽象结构映射到现实场景。测试人员在设计用例时恰恰需要这种映射能力——拿到一个功能你得能快速判断它的数据流、状态流转和边界条件。计算机组成原理部分会考进制转换、原码反码补码、浮点数精度丢失这些基础题。很多非科班同学看到“浮点数精度”直接懵但这恰恰是测试工作的高频考点。做财务软件、造价软件金额计算出现0.30000000000000004这种结果就是严重缺陷。笔试里考这道题其实是在暗示你测试这个岗位要有“数据敏感度”不能放过任何看起来微小但影响用户核心利益的异常。2.2 Linux与数据库考点及答题盲区Linux题在2018年的卷子里占比不低而且题型很务实。我记得有一道题是“从access.log中统计访问次数最多的前10个IP”要求写出命令。这题放在今天依然是面试经典标准答案是awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这道题考查的知识点其实是一个链条awk取列、sort排序、uniq去重计数、sort -rn按数字倒序、head取前N行。很多人知道每个命令单独怎么用但串在一起就卡壳说明平时只背命令不练场景。测试人员排查线上问题时这类“组合命令”的使用频率非常高比如查某段时间的错误日志、统计接口响应码分布、定位CPU占用高的进程本质都是同样的思路。数据库题的经典出法是给两张表让你用SQL查出指定结果。我遇到的是一道“查学生成绩平均分大于80的班级按平均分降序排列”的题标准写法是SELECT class, AVG(score) AS avg_score FROM student_scores GROUP BY class HAVING AVG(score) 80 ORDER BY avg_score DESC;这道题最大的坑在于很多新手会写成WHERE AVG(score) 80,然后在脑子里纠结为什么报错。WHERE是筛选行的HAVING才是筛选分组后的聚合结果的。这种细节恰恰是笔试想筛选的——测试人员写SQL不比开发少如果连这个都分不清日常验证数据时容易得出错误结论。后来我面试测试岗位候选人时遇到能主动说出“这里必须用HAVING因为AVG是聚合函数”的基本印象分都不错。2.3 网络和操作系统里的高频陷阱网络题考查的深度不算高但陷阱多。常见的是“TCP为什么需要三次握手”“HTTP与HTTPS的区别”“Cookie和Session的区别”“301和302的区别”。这里面每一道题都有标准答案但如果只背答案遇到变体题就会露馅。比如“TCP为什么需要三次握手”比较通透的回答不是“因为要确认双方收发能力”而是把它讲成一个类比两个人打电话至少要经历“你能听到我吗”“我能听到你你能听到我吗”“我能听到你”三个来回才能确定双方通信链路都通畅。如果只有两次握手服务端无法确认客户端的接收能力如果四次又浪费了一次往返。测试人员在排查接口超时、连接重置问题时如果能从握手层面分析很多疑难问题会豁然开朗。操作系统部分常考死锁的四个必要条件、进程与线程区别、内存溢出和内存泄漏的区别。内存泄漏这一点做移动端测试的一定要重点掌握。App长时间运行后内存持续上涨大概率是内存泄漏如果程序直接崩溃可能是内存溢出。2018年移动测试刚进入精细化阶段广联达这种重度软件公司对这类问题的敏感度比一般公司更高。3. 测试理论题怎么把“背概念”答成“有经验”3.1 测试用例设计的经典套路与答题框架测试理论部分几乎每套题都会有“请为XX功能设计测试用例”的大题。广联达那年给的是“登录功能”这个题目看起来简单但答得好不好一眼就能看出来。初级答法是把正常登录、错误密码、用户不存在这些列一遍就完事。高级答法是用系统性的方法组织先划分等价类和边界值再画场景流程再考虑异常和容错。我建议按这个框架作答功能测试正常输入、错误输入、为空、超长、特殊字符、前后空格安全性SQL注入、密码加密传输、验证码失效、多次失败锁定兼容性不同浏览器、不同操作系统、不同分辨率性能并发登录、弱网环境、快速重复点击体验光标定位、错误提示清晰度、回车键默认提交行为这个框架的价值不在于列得全而在于体现了测试人员的思维路径先功能、再安全、再兼容、再性能。面试官看到这种答案会觉得你是做过事的人不是背题库的人。我整理当年答题时常用的表格模板考场上直接套用可以快速组织思路编号测试项前置条件操作步骤预期结果优先级TC001正常登录已注册账号输入正确用户名密码点击登录登录成功跳转首页P0TC002密码错误已注册账号输入正确用户名、错误密码提示“密码错误”不跳转P0TC003用户名为空登录页面密码填写点击登录提示“请输入用户名”不提交P1TC004SQL注入登录页面用户名输入 OR 11登录失败不泄露数据P03.2 冒烟测试、回归测试这些词面试官想听到什么简答题里高频出现“什么是冒烟测试”“什么是回归测试”“黑盒白盒的区别”。这类题看似送分但拿满分不容易。以“冒烟测试”为例如果只写“冒烟测试是测试主干功能是否可用的验证”能得基础分但拿不到高分。更好的答法是把它放到流程里讲开发提测之后测试人员先执行一轮覆盖核心功能的冒烟测试如果主流程都跑不通直接打回不进入详细测试阶段。冒烟用例的选取原则是最小化、最快速度覆盖最高风险路径。这样回答面试官能看到你理解“冒烟”在项目管理中的价值它是提测质量的闸门能帮团队省下大量无效工时。回归测试也有类似答题逻辑。不要只是说“修改代码后重新测试”而要补充“回归测试的范围不完全由本次改动决定还要评估改动影响到的上下游模块以及曾经出过问题的历史区域。”这个认知在广联达这类大型软件公司尤其重要——建筑软件模块多、依赖重一次小的数据字典改动可能影响到报表、打印、权限等多个模块。能写出以上补充的分数自然不会低。3.3 Bug报告的艺术会找问题更要会描述问题测试理论模块最后一类题会给你一段描述让你判断是不是一个合格的Bug单或者让你写一个Bug单。很多人在这里栽跟头因为平时习惯口头描述Bug没有形成书面化、结构化的习惯。一份合格的Bug单至少要包含标题概括问题、环境操作系统、浏览器版本、软件版本、前置条件、复现步骤、预期结果、实际结果、严重程度、优先级、日志与截图。我当年第一次写Bug单就被开发怼过“这个Bug我没法复现你给的步骤不够完整。”那次教训让我明白测试人员最大的价值是“可复现地描述问题”。这里分享一个经验当你写“我点了按钮就报错”时开发一定无从下手。但如果写成“在Windows 10 Chrome 120.0环境下用已登录账号进入项目列表页点击第三行项目的‘编辑’按钮页面在1秒内弹出500错误提示并停留在当前页控制台输出Uncaught TypeError: x is not a function”开发拿到这条Bug单基本可以不问一句就直接开干。4. 自动化与性能方向2018年的加分项现在的基本功4.1 自动化测试怎么答才能拿高分2018年的笔试卷里自动化属于“加分项”会的人不多分会给得很慷慨。现在回头看那时会自动化的人现在都已经是团队骨干了这个方向确实值得下功夫储备。卷子里关于自动化的考题大致是简述Selenium自动化测试的原理、元素定位的几种方式、什么是隐式等待和显式等待、做App自动化用什么工具。如果只背结论不够还要会解释为什么。比如元素定位Selenium支持id、name、className、xpath、cssSelector等方式。答题时如果能补充一句“优先使用id定位因为id在页面中唯一且稳定xpath尽量少用绝对路径否则页面结构一调整脚本就挂”这个回答立马有了实战感。关于等待显式等待和隐式等待的区别不只是“一个等一个不等”这么简单。隐式等待是全局的轮询机制显式等待可以针对单个元素设置条件和超时时间。我见过很多人在自动化脚本里只用隐式等待结果页面局部加载慢时用例随机失败改用显式等待或者结合重试机制才稳定下来。App自动化方面当年问的是Appium为主。Appium的核心思路是基于WebDriver协议通过iOS和Android原生驱动的桥接实现跨平台自动化。答题时能说清楚这个架构比啰嗦一长串安装步骤要有价值得多。此外如果能提到真机兼容性测试、机型适配、弱网模拟这类实践概念会显得不是纸上谈兵。4.2 性能测试的核心逻辑和答题突破口性能测试在当年卷子里占比不大一般就一两道简答题。但凡是考了分数含金量高。常考的是“性能测试有哪些指标”“如何分析性能瓶颈”。指标这块必须覆盖并发用户数、TPS每秒事务数、响应时间、错误率、资源利用率CPU、内存、磁盘IO、网络带宽。很多人会漏掉“思考时间”这个概念——用户操作之间的停顿时间。性能测试脚本如果不加思考时间压出来的TPS可能虚高和生产环境实际表现差距很大。分析性能瓶颈的思路可以按层次展开先看应用层日志有没有异常报错再看数据库有没有慢查询然后看中间件比如Redis、消息队列是否有堆积最后看系统资源是否达到瓶颈。这个过程像排查水管的堵点需要一层层往下探。我当年在卷子上画了一条“用户请求→网关→应用→数据库”的链路并标注每一层可能的问题点后来面试时面试官专门问了这题的思路说这个答法让他印象深刻。4.3 安全与移动测试的延伸考点随着热度进来安全测试、渗透测试、车载测试、App测试这些词现在越来越热当年卷子里虽然没有专门的安全题但有两道选择题涉及SQL注入和XSS。只要会区分“被动攻击”和“主动攻击”基本能答对。现在准备测试岗的同学安全方向至少要知道OWASP Top 10里的常见类型尤其是SQL注入、XSS、CSRF、越权访问。不需要会渗透但要能从测试角度写验证用例。移动测试除了功能还要关注启动时间、内存占用、流量消耗、弱网稳定性、崩溃率这些专项。比如弱网测试可以用Charles或Network Link Conditioner模拟高延迟、丢包等场景观察App是否有合理的超时和重试机制。车载测试是这几年兴起的细分方向它跟互联网软件测试最大的区别在于安全等级高、对实时性和稳定性要求苛刻。如果你对传统软件测试应试已经比较熟练可以把车载测试作为差异化方向储备。不过2018年那会儿还不需要考虑这些今天在这里补充是想让准备笔试的朋友知道测试领域在快速演进卷面上不考的东西面试桌上可能就会聊起来。5. 实操演示把自己当成考生走一遍完整答题流程5.1 选择题的速判技巧怎么又快又稳笔试开场是选择题时间紧很多人紧张到在选择题上浪费太多时间。我总结了一套速判逻辑供你参考。看到“下列排序算法中哪种是不稳定的”脑海里要瞬间闪过堆排序、快速排序、希尔排序、选择排序是不稳定的冒泡、插入、归并、基数排序是稳定的。只要记“快些选一堆”这个口诀快排、希尔、选择、堆排一秒锁定答案。看到“栈的特点”直接反射“先进后出”看到“队列”直接反射“先进先出”。题目文字再花哨本质就是考这些基础特性。看到HTTP状态码时我的判断顺序是2开头代表成功3开头是重定向4开头是客户端错误5开头是服务端错误。如果选项里有“404”立刻联想到“请求的资源不存在”“500”则对应“服务器内部错误”。这种条件反射式的知识结构考前对着刷两遍题就能建立性价比很高。还有一类常识判断题比如“64位操作系统最大支持多少内存”这类题如果拿不准就直接跳过不要恋战。选择题的规则是“选对得分”不选不扣分与其卡在一道题上耽误后续大题不如先跳过把时间留给真正的大题。我当年策略是先做完所有有把握的最后再回头补做拿不准的整张卷子基本没空题。5.2 一道典型编程题的完整作答过程当年编程题大概率的考察方向集中在字符串处理、数组操作、排序。给你一道我记忆很深的典型题“给定一个字符串输出每个字符出现的次数按出现次数降序排序如果次数相同则按字符的字典序升序排列。”拿到题先不急着写理清思路用字典统计字符频率再按规则排序最后格式化输出。我用Python给出一个参考实现from collections import Counter def count_and_sort(s: str): if not s: return counter Counter(s) # 先按次数降序再按字符字典序升序 sorted_items sorted(counter.items(), keylambda x: (-x[1], x[0])) return \n.join(f{ch}: {cnt} for ch, cnt in sorted_items) print(count_and_sort(banana))这道题的关键点有两个一是排序规则的实现Python的sorted函数用元组作为key时可以同时处理两级排序条件二是空字符串的边界处理能写上去会让阅卷人觉得你考虑周全。如果编程能力弱写不出完整代码也要把思路写出来“用哈希表统计→按规则排序→格式化输出”同时标注边界情况。这样做即使代码没跑通也能展示逻辑能力拿到一半左右的过程分。另外测试人员写代码和开发写代码有一个明显的区别测试人员更关注“验证”思维。拿到任何编程题做完之后要补充自己的验证用例比如空字符串、单个字符、全是相同字符、包含数字和空格的长字符串。卷面上就算不要求写我也建议在代码旁边用注释标一下自测用例这是完全符合测试岗位思维的加分做法。5.3 面试官视角的评分标准与时间分配根据我对笔试的复盘和后来参与出题的经验阅卷人会快速按模块扫分重点看简答题和编程题里有没有“关键词”“专业感”和“边界思维”。选择题分值有限决定不了最终结果大题才是区分点。时间分配上我建议60分钟的卷子这样切选择题15分钟、简答题20分钟、编程题15分钟、场景题10分钟。编程题一定要花时间把思路想清楚再写不要上来就敲代码容易漏边界条件。场景题是拉开层次的关键宁可简答题少写两句也要给场景题留足时间。打个比方笔试就像爬山选择填空是平缓的山脚人人可走简答题是山腰需要储备编程题是陡坡很多人卡在这里场景题是山顶的雾气能不能看清全局靠的是日常积累。很多人不是能力不够而是时间分配失衡导致最后两道大题草草收场。6. 常见问题与避坑指南6.1 答题中的高频失误能避一个是一个我把这些年看过的笔试题和自己踩过的坑汇总一下。第一个误区是简答题只写概念不写场景。问“什么是黑盒测试”低分回答是“不关注内部逻辑只测试功能是否正常”。更好的回答是“黑盒测试把被测系统视为黑盒测试人员通过输入和输出来验证功能是否符合需求常用方法包括等价类划分、边界值分析、因果图等主要用于功能测试和系统测试层面优点是测试角度贴近用户缺点是可能遗漏代码内部的逻辑分支。”这一对比后者明显高出几个段位。第二个误区是SQL题目忽略题目条件。比如要求“按班级分组并筛选平均分大于80”不少人写完了GROUP BY却忘写HAVING或者把HAVING写成了WHERE。这类细节在这种基础题上丢分非常可惜。第三个误区是Linux题只背命令不背参数。awk取列、sort去重、uniq计数每个工具单独拎出来都知道合在一起就写不对说到底还是平时缺少“组合使用”的练习。建议考前专门练三组命令组合统计日志、查端口进程、看资源占用。6.2 笔试的时间节奏和应对策略拿到考卷先别急着动笔花2分钟浏览全卷标记一下哪些题有把握、哪些题没思路。我的习惯是选择题直接顺着做遇到卡壳超过1分钟的标个记号先跳过简答题先挑自己最有把握的写因为大题是按点给分多写一个关键词就多一分编程题无论如何留出15分钟场景题最后答但也必须答空题是笔试大忌。有一个小技巧不会的简答题也不要空着。把题干中的关键词用自己的话拆开解释再加一句“从测试角度看这个问题主要影响XX方面”往往能触发阅卷人的“关键词给分”至少不会零分。比如问“什么是兼容性测试”即使你不太确定也可以写“在不同操作系统、浏览器、分辨率下验证功能表现一致性的测试”这句话的核心关键词就是“不同环境”和“一致性”阅卷人就能给到基础分。6.3 笔试只是开始后续的复盘与面试衔接笔试结束后别光等通知把没把握的题目默写下来当晚就翻书查漏补缺。面试官很可能拿着你的笔试卷追问比如“你SQL题里用了HAVING能讲讲为什么不用WHERE吗”这时候如果答得流畅反而能制造加分点。如果笔试挂了也不要只怪题难。复盘自己到底是基础题失分多还是大题没时间做然后按模块补短板。我见过不少同学连续面了好几家都挂在同一个环节问题往往不在运气而是某个知识模块存在系统性盲区。这次考砸了不要紧下次面对同样的问题不再犯错就是实实在在的进步。最后分享一个个人体会这套题放在今天看计算机基础、SQL、Linux、用例设计这些考点依然是测试面试的底子。技术工具会升级平台会变化但“理解系统、拆解需求、严谨验证、清晰表达”这四项能力永远不会过时。我当年从功能测试转岗靠的就是把每一道错题和每一次被拒的面试都当作学习材料一步步补齐了计算机基础和自动化测试的短板。希望这篇复盘能帮你少走一些我当时走过的弯路。