2018年那会儿我也在准备校招笔试看到“广联达测试开发”这几个字还挺亲切的。广联达在建筑信息化领域深耕多年产品线覆盖造价、施工、BIM、CAD看图等业务形态以桌面端为主、Web和移动端并存。这种背景决定了它的测试开发岗位笔试内容和互联网大厂那种纯算法刷题风格有明显区别——更偏工程落地更看测试思维和代码功底是不是真的能扛住业务需求。这篇文章我打算以广联达2018校招测试开发自动化测试方向为切入点把这类笔试背后真正想考察的东西拆开讲清楚。不是单纯的“原题复述”而是把题目映射到测试开发的核心能力模型上分析每类题型的考察意图、答题切入点和准备方法。不管你是正在备考的应届生还是想转岗测试开发的工程师这篇内容应该能帮你少走不少弯路。1. 先弄明白测试开发笔试到底在选什么样的人1.1 测试开发岗位的底层能力模型很多同学准备测试开发笔试时最大的误区就是把它当成“开发笔试的降级版”觉得只要刷题刷得够多就稳了。实际上测试开发岗位的能力模型和纯开发岗位有本质区别。开发岗位看重的是“从无到有构建系统”的能力而测试开发看重的是“理解系统并设计验证方案”的能力说得直白点就是——你得能看懂别人写的东西还得能设计方法证明它没写错。从我自己的面试经历和带人的经验来看测试开发笔试通常围绕三个维度展开能力维度考察内容占比参考编程能力语言基础、数据结构、算法、代码质量35%-45%测试理论测试用例设计方法、测试流程、质量意识25%-35%工程实践自动化测试框架、工具链、CI/CD、脚本编写25%-35%广联达这类建筑软件企业还有一个特点产品形态复杂。桌面端的CAD/算量软件、Web端的项目协同平台、移动端的移动验工等多端并存导致测试策略必须灵活。所以笔试里经常会出现“如何设计某个功能的测试方案”“自动化脚本怎么处理弹窗”这类偏向真实业务场景的问题这就不只是背概念能解决的了。1.2 建筑信息化业务的测试特点广联达的产品和其他纯互联网产品不一样。造价软件、BIM建模软件这类工具的测试最大的痛点是逻辑复杂、专业门槛高。比如算量软件里面一个“外墙保温层面积计算”的功能测试人员如果不懂建筑构造连有效等价类都划分不出来更别提设计自动化验证脚本了。这就解释了为什么这类公司的测试开发笔试题会让你 “读一段需求描述然后设计测试方案”——考察的不只是测试方法还有快速理解业务逻辑的能力。另一方面桌面端产品的自动化测试比Web端要麻烦得多UI控件识别、跨版本兼容、图形渲染校验都容易出问题。所以笔试中关于桌面端自动化测试的技术选型和方案设计题几乎是保留节目。我在实际工作中遇到过的最典型的场景就是用Selenium做Web自动化跑得挺顺利一到桌面端就处处碰壁。Win32控件、WPF控件、Qt控件每一家UI框架的自动化方案都不一样。这类经验在笔试里会以“你会选择什么工具、为什么”的形式出现能答出工具背后的原理比光会列工具名要加分得多。2. 编程与算法部分测试开发也要过代码关2.1 语言选型Java还是Python编程题是笔试的硬门槛。广联达这类以Java为主要开发语言的企业笔试通常默认用Java写代码但也会接受其他主流语言。我个人建议准备时主攻Java或Python其中一门务必熟练到条件反射的程度。Java的优势在于静态类型语言能考察你对编码规范、异常处理、设计模式的理解很多测试框架如TestNG、Selenium的Java版本用得最广。Python的优势在于脚本简洁写自动化测试很容易而且读起来快笔试时间紧张时更能快速出活。我的建议是如果你已经熟悉Java就用Java如果你Python写得更顺也完全可以。但不管是哪门语言HashMap、List、String这些核心API必须用得熟排序、查找、去重这些基础操作得能直接手写不能边写边想API怎么拼。2.2 高频算法题型的考察逻辑测试开发的算法题一般不会出到动态规划、图论这种难度更多是偏实际应用的题目。从我收集的信息来看这类笔试高频出现的是字符串处理类判断回文串、字符串去重、统计字符出现频率、解析版本号数组操作类数组排序后找最大/最小值、合并两个有序数组、数组去重基础数据结构用栈实现队列、判断括号匹配、链表反转逻辑计算类求最大公约数、判断闰年、实现一个简单的计算器这些题目的共同点是既考察基本数据结构与算法能力又贴近测试场景里的数据准备、结果校验需求。做这些题的时候代码的边界处理比单纯能算对结果更重要。比如写一个判断回文串的方法空字符串怎么处理字符串里有空格和标点要不要忽略大小写要不要统一这些异常场景恰恰是测试人员最敏感的写代码时主动考虑这些本身就是向面试官展示测试思维。2.3 手写代码的实战要点笔试手写代码和平时在IDE里写代码完全是两回事。没有自动补全没有编译器兜底拼写错了就是错了逻辑不完整就是扣分。我有几点实际经验可以分享第一先在纸上把思路理清再动手写。不要一上来就写代码先写核心逻辑的伪代码确认没有逻辑漏洞再落到完整代码上。第二变量命名要有意义不要写一堆a、b、c这也是代码质量的一部分。第三写完代码一定要检查边界条件比如数组长度为0、字符串为null、输入负数这些情况。第四如果有余力可以把时间复杂度的思考写上去这会让面试官觉得你不只是个写代码的机器。注意很多同学笔试时看到题目就兴奋噼里啪啦写一大堆最后发现逻辑错了却来不及改。宁可前面多想三分钟也不要后面花十分钟改错。我还记得我自己当年笔试时踩过的一个坑写一个从字符串中提取数字并求和的函数我主逻辑写得飞快但没考虑字符串里没有数字、连续多个数字、数字带正负号这些情况。结果测试用例一跑挂了两个边界case。虽然算法思路是对的但代码的鲁棒性不足这在测试开发岗的笔试里是硬伤——因为测试开发的核心价值就是发现别人没考虑到的情况。3. 测试理论基础概念背后是思维深度3.1 用例设计方法等价类、边界值、场景法怎么用测试理论部分的题目看起来是“背概念”但实质上考察的是能不能把概念用起来。最典型的题目就是给你一个功能描述让你设计测试用例。这类题没有标准答案但有明显的层次差异。以登录功能为例低分回答是输入正确账号密码能登录输入错误账号密码提示错误。高分回答会怎么做先划分等价类——有效等价类包括正确的账号、正确的密码、正确的账号正确的密码组合无效等价类包括错误的账号、错误的密码、空账号、空密码、账号或密码超长等。然后再补充边界值——密码长度是8到20个字符那7个字符、8个字符、20个字符、21个字符各是什么情况。接着考虑场景法——正常登录、连续输错5次被锁定、密码过期需要重置、未勾选用户协议不允许登录。最后还要加上异常场景——网络超时、服务器返回500、数据库连接失败时前端如何提示。这背后反映的是测试工程师的思维习惯不是“把功能测一遍”而是“系统地找出潜在缺陷”。我见过不少同学能把等价类、边界值、判定表这些方法倒背如流但一到设计用例就东一个西一个完全没有章法。这就是典型的“知道概念但不会应用”笔试时容易被一眼看穿。3.2 测试流程与质量体系的理解除了用例设计测试理论部分还可能考到软件开发流程中的测试活动。比如敏捷开发模式下测试人员如何介入、测试左移怎么做、缺陷的生命周期管理、测试报告如何呈现等。这里我特别想强调一个点不要死记硬背V模型、W模型的流程而是要去理解每个环节为什么存在。比如“测试左移”这个概念本质是希望尽早发现缺陷、降低修复成本。理解了这一点你就能分析出为什么需求评审阶段测试就要参加因为需求阶段的逻辑漏洞比代码阶段的Bug修复成本低得多这是经济学问题不是流程问题。笔试中如果出现“如何看待测试在软件开发中的价值”这类开放题千万不要回答“保证软件质量”这种套话。比较有质量的回答思路是测试的本质是信息收集与风险评估为版本发布决策提供依据同时测试活动形成的自动化用例是项目资产能持续降低回归成本。这种表述说明你真正思考过测试岗位的价值而不只是在背书。3.3 测试数据与测试环境的准备思路另外一个容易被忽视的考点是测试数据和测试环境的准备。笔试可能会问“如何准备测试数据”“测试环境怎么管理”这类问题。这类题目背后的真实痛点在于很多测试脚本跑得好好的换一套数据就全挂了或者测试环境一重置几百条测试用例全军覆没。我个人的经验是测试数据设计要区分“基础数据”如用户信息、权限配置和“业务数据”如一条造价单、一个BIM模型基础数据通过自动化脚本在环境初始化时准备业务数据尽量通过API接口构造而不是直接操作数据库。为什么因为直接改数据库容易绕过业务逻辑的校验构造出来的数据在真实流程中根本不存在测出来的结果没有参考价值。笔试时如果能答出这种层次面试官会很有印象。4. 自动化测试专项笔试的重头戏4.1 接口自动化与UI自动化的选型逻辑自动化测试是测试开发岗位笔试的核心板块也是最容易拉开差距的部分。这块的考点通常集中在两个方向接口自动化测试和UI自动化测试。我经常被问到的一个问题是接口自动化和UI自动化到底先做哪个我的回答一直是优先接口自动化。原因很直接接口自动化脚本的执行速度快、稳定性高、维护成本低而且能更早地发现后端逻辑问题。UI自动化则更适合做关键核心流程的回归验证比如登录、下单、提交审批这类高频且重要的路径不要把大量UI自动化覆盖所有细枝末节的功能否则维护脚本的成本会拖垮整个测试团队。笔试中出现“如何设计一个接口自动化测试方案”这类题目时答题框架可以参考确认被测接口的协议类型HTTP/RPC梳理接口文档与依赖关系搭建接口测试框架选择请求库如Python的requests、Java的RestAssured和测试框架如pytest、TestNG设计用例正向用例覆盖正常入参与正确断言反向用例覆盖异常入参、权限不足、参数缺失等数据隔离测试数据与脚本分离通过fixture或工厂方法构造数据集成到CI与Jenkins等CI工具联动实现代码提交后自动触发接口回归这套思路能完整写出来说明你真正实操过而不只是听过概念。4.2 Selenium、Appium等工具链的考察要点关于工具类的问题“会不会用Selenium”和“懂不懂Selenium背后的机制”是两个层次。笔试和面试时考官更看重后者。比如问Selenium的工作原理核心要讲清楚WebDriver的作用Selenium通过WebDriver与浏览器之间建立一套标准化的通信协议脚本将操作命令发送给WebDriverWebDriver再调用浏览器原生支持把它转化为实际的浏览器操作。这套机制的关键在于WebDriver直接调用浏览器内核的自动化测试接口而不是像JavaScript注入那样受到同源策略限制所以能做到模拟真实用户操作。Appium的原理也类似它基于WebDriver协议扩展了移动端的支持通过XCUITest和UiAutomator2等驱动与iOS/Android系统通信。笔试如果考到移动端自动化重点讲清这套分层思想就够了测试脚本不需要关心底层系统差异框架层已经把平台差异封装好了。另外桌面端自动化工具在广联达这类产品中是刚需也算是特色考点。WinAppDriver是微软提供的Windows UI自动化驱动支持UWP、WinForms、WPF等应用如果桌面应用使用Qt框架可以考虑Squish。答题时如果能结合被测系统的技术栈选型并说明选择的理由分数会明显高一个档次。4.3 自动化测试框架的设计思路“如何设计一个自动化测试框架”是笔试最常出现的开放型题目之一也是很多人最没底的一道题。这道题没标准答案但答题的广度与深度直接反映你平时有没有实践。我常用的答题框架是“四层结构”基础层Common Layer封装对Selenium/Appium/requests等工具库的调用提供统一的元素定位、点击、输入、断言方法数据层Test Data Layer测试数据的配置与存储使用Excel、YAML或JSON文件管理用例层Test Case Layer具体的测试用例通过TestNG/pytest编写负责组装操作步骤和断言业务层Business Layer封装业务操作流程比如登录、创建订单等供用例层调用为什么要四层而不是写成一坨核心目的是降低维护成本。页面元素变了只改基础层业务规则变了只改业务层测试数据变了只改数据文件。如果写代码时把这些全耦合在一起一个按钮的id变了你可能要改几十个用例这种框架上线后维护成本就会失控。再补充一个容易被忽略的设计点失败用例的自动重试机制。接口偶尔超时、前端偶现弹窗遮住按钮都会导致用例失败。此时如果不加区分地直接重跑或直接报错都不能真正反映被测系统的质量状态。比较常用的做法是针对网络超时类异常进行多线程或循环重试针对业务断言失败则立即失败不进行无脑重试因为业务逻辑的错误重试一百遍也还是会错。这个细节在笔试中答出来会让考官觉得你踩过坑、有实战经验。4.4 CI/CD集成与自动化测试的闭环自动化测试如果不接入持续集成价值会折损一大半。所以笔试中“如何把自动化测试集成到CI流水线”也是高频考点。在我看来这里最需要讲清楚的逻辑是“自动化测试在流水线中的位置”。通常的流程是开发提交代码 → 触发构建 → 构建产物部署到测试环境 → 执行自动化测试先用冒烟测试快速验证再跑全量回归→ 生成测试报告 → 结果反馈给开发。这个流程讲起来简单但真正跑通有很多细节。比如自动化测试在流水线中是“阻塞门禁”还是“非阻塞通知”我的做法是冒烟测试必须阻塞发布因为核心路径挂了就不能发布全量回归可以非阻塞因为耗时长、失败率相对高不一定要卡住发布流程而是把报告直接推给对应开发人员。这种策略性的考虑往往比盲目追求所有测试都通过更有工程价值。再比如测试报告如何留存和追溯。测试报告至少要能追溯到对应的代码版本和测试环境否则报告就是一堆无主的数据对定位问题毫无帮助。Jenkins的HTML Publisher插件可以把报告归档Allure也能很好地和pytest/TestNG结合输出直观的测试趋势图表建议笔试答题时把这些工具名词带上会显得你很懂落地细节。5. 场景题与开放题怎么展示测试思维5.1 经典场景题电梯测试、搜索框测试场景题是测试岗位笔试的特色也是不少同学的痛点。最常见的两类是“给一个日常物品设计测试方案”和“给一个业务功能分析怎么测”。电梯、搜索框、洗衣机、登录功能都是典型题目。这类题目的考察重点不是覆盖面有多全而是答题的结构性和逻辑性。我建议采用“六步法”来组织回答明确被测对象和测试目标先搞清楚测什么、验证什么功能测试基本功能是否正常接口/兼容性对外交互是否正常不同平台/浏览器表现是否一致性能与可靠性并发、超时、故障恢复安全性权限、数据加密、越权访问易用性与异常场景用户误操作、极端场景、非典型路径以电梯为例先用这个框架拆解功能层面包括按键响应、楼层停靠、开关门接口层面包括与外呼系统、监控系统的联动性能包括高峰期响应时间、连续运行稳定性安全包括超载保护、急停按钮易用性包括按钮标识是否清晰、轮椅用户是否方便操作。这样答下来逻辑清晰、层次分明基本不会漏项。5.2 面对“如何测试一个复杂系统”的答题框架比电梯更进一层的是“如何测试一个复杂系统”的题目。比如“给你一个电商系统怎么设计测试方案”“如何测试一个造价计算引擎”。这类题目考察的不只是测试方法还有系统级思维。我的答题思路是“从端到端的视角”出发按用户旅程来组织用户从登录开始到浏览、操作、提交、得到结果每一个环节都有对应的测试关注点。具体到方案输出时可以先列业务流程标注关键节点和异常分支然后按测试层次展开单元层侧重核心算法接口层侧重模块间协作UI层侧重用户交互路径端到端层覆盖关键用户旅程。针对造价计算引擎这类专业系统特别注意要加一个评测思路用“基准数据”验证计算逻辑也就是准备一批有标准答案的历史工程数据输出结果与标准答案比对容差精度要明确如金额精确到分。这种用真实的行业标准数据做回归验证的方法是这个领域最有效的测试策略。5.3 非预期弹窗导致自动化失败的问题这里我想单独讲一个特别实际的场景问题因为太常见了UI自动化跑到一半系统弹出一个非预期的弹窗脚本就卡死了。尤其是桌面端软件升级提示、错误提示、系统权限弹窗五花八门。笔试中如果问“自动化测试中遇到非预期弹窗导致失败你怎么解决”一个好的回答应该包含两个层面。第一事前防御在用例执行前统一关闭已知弹窗的入口比如在测试环境配置中禁用自动升级、错误报告脚本中封装一个“弹窗处理器”在初始化时启动一个新线程轮询检测是否有弹窗出现发现就按预设策略关闭。第二事后分析从测试报告中识别出弹窗出现的频率和规律推动开发或产品从根因上解决而不是一直靠脚本兜底。这个题目非常经典的原因在于它同时考察了脚本编写能力、环境治理能力和沟通推动能力。自动化测试能真实跑起来拼的不只是代码水平还有对被测系统的熟悉程度和产品沟通能力。6. 备考点滴经验从笔试到面试的衔接6.1 笔试准备的节奏安排备考测试开发笔试不能眉毛胡子一把抓。我的建议是分三阶段准备第一阶段1-2周打基础。把语言基础过一遍常用数据结构数组、链表、栈、队列、哈希表的API和用法要熟练再把等价类、边界值、场景法等测试方法理清楚。第二阶段2-3周刷题与项目并行。笔试刷题每天2-3道算法题同时把你做过的一个自动化测试项目或脚本梳理成文字。笔试和面试都会问到项目经历提前整理能大幅提高临场表达的条理性。第三阶段1周模拟与复盘。找几套真题或模拟题严格按考试时间过一遍重点训练时间分配能力。我当年笔试最大的教训就是时间分配不合理。选择题犹豫太久导致后面的大题来不及写完整。正式笔试时建议拿到卷子先把所有题目扫一遍按“会做的先做、分值大的先做、不会的先跳过”的原则推进。6.2 笔试中的答题技巧与禁忌关于笔试答题有一些非常实际的经验不要留空白。即便是完全不会的大题也要把思路写出来。比如设计测试用例的题目就算你只写了功能测试用例也比什么都不写强。阅卷人更看重的是你的思考过程而不只是最终答案。代码题如果时间不够优先写主逻辑再补边界处理。写一个“函数实现”的题目核心逻辑完整了能拿60%的分数边界处理补全了能拿80%以上但核心逻辑都没有想清楚就开始扣细节反而容易把自己绕晕在规定时间内拿不到分。不要忽视简单题。有些同学眼高手低觉得字符串反转太简单了于是省略步骤直接写出答案。但实际上越简单的题越容易考察答题的规范性——函数有没有处理空输入是用API投机取巧还是手动实现这些细节反而会暴露你平时的编码习惯。6.3 笔试到面试的知识迁移最后说说笔试和面试的衔接。笔试题里出现的知识点大概率会在面试里被追问得更深。比如笔试考了你设计测试用例的能力面试就可能追问“具体怎么判断用例的优先级”“你的用例覆盖率怎么评估”。笔试试卷上的回答是“点”面试时的深挖是“线”和“面”。所以考完笔试后不要立刻把题目忘掉把它当作面试的准备素材好好复盘一遍特别重要。我自己当时的一个习惯是笔试结束后把每一道觉得自己答得不够好的题都重新整理一遍写成文字笔记。后来面试时遇到类似的问题直接基于笔试时的思考再展开回答质量明显好于临场发挥。这算是“一笔两用”了推荐你们也试试。再聊聊广联达这类企业测试开发岗的长线发展。笔试通关只是第一步真正到了工作中你会发现在建筑信息化这个领域测试开发的核心竞争力来自“技术能力行业理解”的交叉优势。你越懂业务测试方案就越有价值你越懂技术测试效率就越高。笔试只是第一道门槛未来的成长空间反而更大。备考的过程虽然紧张但回头看其实是专业能力快速提升的阶段。遇到不会的题目不用怕把它当作查漏补缺的机会踏踏实实搞清楚背后的原理比背一百道“标准答案”都管用。希望这份笔试题拆解能帮你建立清晰的复习框架少走一些弯路。