先说说这套题的总体观感。京东2019校招测试开发工程师的笔试放在今天看依然很有代表性。它不追求偏题怪题而是实打实地考察一个测试开发候选人应该具备的基础功数据结构与算法、计算机网络、操作系统、数据库以及最关键的测试思维。我当时做完这套题最大的感受是它不是想难倒你而是想通过一套题看清你有没有做测试开发的底子。这篇文章我会把整套题的考点拆开揉碎结合我自己的答题思路和后来做面试官的经验讲清楚每一类题背后的考察逻辑以及怎么准备才能稳稳通过。如果你正在准备大厂校招的测试开发岗或者刚入行想系统补齐基础知识这篇文章可以当作一份复习地图来用。我会把高频考点、典型题目、容易踩的坑还有笔试现场的提分技巧全部梳理清楚。1. 京东测试开发校招笔试的整体思路拆解1.1 考点分布与出题逻辑京东这套笔试的题型大致分为四块单选题、多选题、编程题、测试设计题。单多选覆盖计算机基础编程题考察代码实现能力测试设计题则直接检验你有没有测试思维。这个结构在互联网大厂校招里很常见但京东有自己的侧重点。首先计算机网络和操作系统是选择题的绝对主力。TCP三次握手、HTTP状态码、进程与线程的区别、死锁产生的条件这些几乎是必考的。京东作为电商平台对网络协议的理解有天然的业务需求毕竟每秒钟都有大量的请求在浏览器和服务器之间流转。候选人如果连GET和POST的区别都说不清楚那后续的接口测试、性能测试根本无从谈起。其次数据结构与算法在编程题中占了很大比重。链表操作、字符串处理、数组排序这类基础题是主流难度不会到ACM竞赛那种级别但要求你写得又快又对。京东的编程题有一个特点很多题目会带一点业务背景比如商品价格排序、订单状态判断、优惠券计算这其实是在考察你把算法应用到实际场景的能力。最后测试设计题是整套笔试题的灵魂。它通常会给一个具体的功能模块比如登录、购物车、订单支付让你设计测试用例。这道题的分值往往不高但它是面试官判断你是否有测试思维的重要依据。很多科班出身的同学写代码很厉害一到测试设计题就露怯只能写出“输入正确的账号密码登录成功”这种毫无营养的用例这就是典型的测试思维缺失。1.2 笔试与面试的联动关系顺着笔试往下说你会发现京东的笔试和面试是环环相扣的。笔试里你写过的测试用例面试官可能会让你现场重新设计一遍然后追问你“为什么这么设计”“还有没有遗漏的场景”。笔试里考察的算法题面试时可能换一个业务背景再让你手写一遍。所以准备笔试不能只为了过笔试而是要把每一道题都当成面试的预演。我认识不少同学笔试高分通过结果面试时基础概念一问三不知这就是典型的“刷题式备考”——只记答案不理解背后的原理。反过来也有人笔试分数一般但面试时把测试设计的思路讲得很透彻最后依然拿到了offer。那具体的知识点应该怎么准备下面我把几个核心模块逐一拆解。2. 编程题的核心考点与解题要点2.1 高频算法题型与应对策略从京东历年的出题风格来看编程题一般有两道难度递进。第一道通常是easy到medium级别的题目比如字符串处理、数组操作、链表反转第二道会稍微复杂一些可能涉及动态规划、二叉树遍历、或者带有业务包装的场景题。我统计了一下近几年测试开发岗位的编程题出现频率最高的题型有这几类字符串类字符统计、子串判断、版本号比较、括号匹配。数组类去重排序、两数之和、最大子序和、数组旋转。链表类链表反转、环形链表判断、合并两个有序链表。场景应用题满减优惠计算、库存扣减逻辑、订单状态流转判断。很多同学会问测试开发工程师为什么要考算法这里我要说一个很多人没想明白的点测试开发写自动化框架、设计测试平台、开发性能压测工具本质上都是在写代码。如果没有扎实的算法基础写出来的框架效率低、扩展性差遇到大数据量的测试场景就会出问题。所以算法不是刁难人而是筛选程序员的底线。2.2 典型编程题逐步推演版本号比较我挑一道比较有代表性的题目来推演一遍——版本号比较。这道题在京东笔试里出现过变形而且它非常贴近真实开发场景App发版、接口兼容性判断都需要比较版本号。题目描述大致是给定两个字符串形式的版本号如1.10.2和1.9.0按从左到右的顺序比较每个修订号的大小。如果version1大于version2返回1小于返回-1相等返回0。注意版本号可能长度不一致比如1.0和1.0.0应视为相等。拿到这道题我建议按下面的思路来拆解第一步把字符串按.分割成数组。比如1.10.2分割成[1,10,2]。第二步确定两个数组的最大长度用0补齐较短的数组。这里补齐成等长的好处是后续比较逻辑统一不用单独处理长度不一致的情况。第三步逐个比较对应位置上的数字大小。把字符串转成数字后直接比较因为版本号的每一位都是非负整数不会出现负数。第四步如果全部相等返回0。按照这个思路写出来的代码很简洁def compare_version(v1, v2): arr1 v1.split(.) arr2 v2.split(.) n max(len(arr1), len(arr2)) for i in range(n): num1 int(arr1[i]) if i len(arr1) else 0 num2 int(arr2[i]) if i len(arr2) else 0 if num1 num2: return 1 elif num1 num2: return -1 return 0这里有两个细节值得注意。第一个是补零策略1.0和1.0.0之所以相等因为缺省位补零后每一位都相等。第二个是int转换如果你直接用字符串比较会得到10小于9的错误结果这是LeetCode同类题目里最常见的坑。作为测试开发看到这道题你还应该多问一句如果版本号里有前缀v怎么办如果某一节有前导零怎么办如果版本号包含字母后缀比如1.0.0-beta怎么办这些都是你在设计测试用例时要考虑的场景。在笔试答卷里如果你能在代码之外补充这些边界情况的说明面试官会对你有额外的好感。2.3 编程题的高分写法与常见失误编程题不是写出来就完事阅卷时会看你的代码风格和解题思路。我给准备笔试的同学三个实操建议。第一个建议先写注释再写代码。在正式编码之前用注释把解题思路写清楚哪怕代码有瑕疵阅卷人也能看出你的思考过程。很多同学一上来就敲代码忽略了注释遇到复杂的逻辑就容易把自己绕晕。第二个建议变量命名要见名知意。不要用a、b、c这种毫无信息的命名用left、right、cur、count这样的命名会让你自己写起来更顺手阅卷时也更容易理解你的代码。第三个建议写完代码一定要自己跑一遍示例。很多在线笔试系统不支持运行调试你需要在心里模拟执行一遍检查边界条件。我见过太多人写了快排却处理不了数组长度为0或1的情况一提交就数组越界。还有一类常见失误是输入输出格式没搞对。有的同学在本地IDE里写了完整的类定义结果笔试系统要求只写核心函数最后格式不对一分不得。建议考前了解一下目标公司的笔试系统用的是牛客网、赛码网还是自家系统提前适应它们的输入输出规范。3. 计算机基础选择题失分重灾区与高分策略3.1 计算机网络必考知识点盘点单多选里的网络题考察范围相对固定集中在TCP/IP协议栈和HTTP协议这两个大方向上。TCP三次握手几乎是年年必考。你要理解为什么是三次而不是两次第一次握手客户端发送SYN第二次服务端回复SYNACK第三次客户端再回复ACK。三次握手的关键作用是确认双方的收发能力都正常。如果你只答出“建立连接要三次握手”而不理解背后原因面试时很容易被追问到答不上来。HTTP相关的考点则集中在状态码和请求方法上。200、301、302、400、401、403、404、500、502、503这几个状态码的含义要脱口而出。特别是301和302的区别301是永久重定向302是临时重定向这在接口测试中很常见。GET和POST的区别也是高频考点但要注意这个问题的标准答案已经随着HTTP协议的发展发生了变化——现在的浏览器和服务器对GET和POST的处理方式已经没那么大差异了你需要从语义、请求体、幂等性、缓存等角度去分析而不是背老一套的“GET有长度限制POST没有”。Session和Cookie的区别也需要掌握。Session存在服务端Cookie存在客户端Session id通常通过Cookie传递。电商场景下购物车数据放Session还是放Redis为什么这个问题如果你答得好会让面试官觉得你懂业务。3.2 操作系统高频考点与易错点操作系统部分进程与线程的区别是必考题。核心要点是进程是资源分配的最小单位线程是CPU调度的最小单位同一进程下的线程共享地址空间和资源进程之间相互独立。这个知识点在性能测试中特别重要——你压测时要清楚并发到底是指进程并发还是线程并发这直接影响压测模型的设计。死锁产生的四个必要条件也是常客互斥、持有并等待、不可剥夺、循环等待。问你怎么避免死锁答案就藏在条件里——破坏任意一个条件即可。实际工作中写自动化脚本时如果涉及多线程同时操作共享资源一定要考虑加锁和释放的顺序不然就可能出现死锁导致脚本hang住。内存管理里堆和栈的区别、虚拟内存、页面置换算法是选择题的重点。堆是程序员手动管理的内存区域栈由编译器自动分配和释放。我在笔试时总结了一个口诀堆靠new和malloc栈靠系统自动来。这个区别在写测试代码时也有体现——你创建的对象多了堆内存不够就会OOM而递归层级太深则会导致栈溢出。3.3 数据库SQL高频考点与实例数据库在测试开发笔试中的地位很高因为几乎所有的测试工作都离不开数据校验。选择题常考索引失效的场景、事务的ACID特性、SQL执行顺序而更多的分数来自专门的SQL编程题。这里我讲一个典型的SQL题统计每个商品分类下销量最高的前三个商品。假设有三张表商品表productid, name, category_id订单表ordersid, order_time, user_id订单明细表order_itemid, order_id, product_id, quantity首先需要理清表之间的关联关系订单表通过order_id关联订单明细表订单明细表通过product_id关联商品表商品表通过category_id关联分类表。第一步关联三张表得到每个商品的销售总量SELECT p.category_id, p.id AS product_id, SUM(oi.quantity) AS total_quantity FROM product p JOIN order_item oi ON p.id oi.product_id JOIN orders o ON oi.order_id o.id GROUP BY p.category_id, p.id第二步用窗口函数按分类分组、按销量排序取前三SELECT category_id, product_id, total_quantity FROM ( SELECT p.category_id, p.id AS product_id, SUM(oi.quantity) AS total_quantity, ROW_NUMBER() OVER(PARTITION BY p.category_id ORDER BY SUM(oi.quantity) DESC) AS rn FROM product p JOIN order_item oi ON p.id oi.product_id JOIN orders o ON oi.order_id o.id GROUP BY p.category_id, p.id ) t WHERE rn 3这里有两个关键点。第一窗口函数ROW_NUMBER()在MySQL 8.0及以上版本才支持如果你环境是5.7就需要用用户变量模拟或者改用GROUP_CONCAT等变通方案。第二取前三名时如果销量并列ROW_NUMBER会随机排序如果你希望并列的都显示应该用DENSE_RANK()或者RANK()具体用哪个取决于题目要求“前三名”是有几个名额还是所有并列都算。我还想提醒一个SQL笔试的共性问题很多人写SQL不会在头脑里执行写出来的语句逻辑上说不通。我的建议是拿一张小表手动模拟一下每一步的执行结果确认每一步的过滤条件、分组逻辑都符合预期后再提交。SQL本身语义复杂一步错步步错不像代码可以调试必须靠推演。4. 测试设计题最能拉开差距的题型4.1 测试用例设计的思维模型测试设计题是测试开发笔试和普通开发笔试最不一样的题型。它不考你写代码而是考察你有没有“找漏洞”的思维习惯。要做好测试设计题核心是建立一套自己的思维模型而不是靠灵光一现。我常用的一个思维模型叫“三层分析法”第一层是功能层。从用户的角度思考这个功能应该怎么用正常的操作路径是什么。比如购物车结算功能用户把商品加入购物车点击结算选择地址选择支付方式确认支付这是主流程。第二层是逻辑层。从系统的角度思考这个功能背后有哪些规则和约束。比如购物车结算要考虑商品库存是否充足、优惠券是否满足使用条件、满减活动是否叠加、商品是否下架、价格是否变动、收货地址是否有效这些都属于逻辑层面的校验。第三层是异常层。从对抗的角度思考系统在异常情况下能不能正确处理。比如网络中断、支付超时、重复提交、并发操作、数据丢失、接口返回异常这些场景测试新人很容易忽略但恰恰是线上最容易出问题的地方。用这个模型去设计用例基本可以保证不遗漏大方向。当然要拿高分还需要结合具体的业务场景和测试方法。4.2 典型电商场景测试设计实例以京东笔试里比较有代表性的“购物车结算功能”为例我写几个核心测试用例来演示。先看功能层。主流程用例包括用户登录后添加商品到购物车点击结算按钮选择商品、修改数量、进入订单确认页选择收货地址、支付方式、核对订单金额提交订单并完成支付。这些用例关注的是功能能否走通通常用正例来覆盖。再看逻辑层。这里要结合电商的业务规则来设计用例购物车中有多个商品部分商品库存不足结算时给出提示并允许移除库存不足的商品。商品价格在加入购物车后发生变化结算时按最新价格计算并弹窗提示用户。优惠券金额加上满减活动的总额不超过订单金额防止出现负支付金额。结算时身份校验失败提示用户重新登录购物车数据不丢失。收货地址数量为0时引导用户新增地址而不是直接报错。这些用例可以用等价类划分和边界值分析法来设计。比如价格优惠金额的边界值测试订单金额100元一张满100减20的券那正好100元应该能用99.9元就不能用100.1元肯定能用。这组边界值用例在产品逻辑里很容易被忽略但测试必须覆盖。再看异常层。典型的异常用例包括点击提交订单后断网订单状态处于未知状态再次进入时能通过订单查询接口确认实际状态用户连点两次提交按钮系统只生成一个订单幂等性测试两个用户同时购买同一件只剩一件的商品只有一个能下单成功并发测试。这些用例是测试设计的加分项也是面试官判断你有没有实战经验的试金石。4.3 自动化测试和性能测试基础考点京东的笔试题里偶尔会涉及自动化测试和性能测试的基础概念。不需要你精通工具但至少要理解核心原理。自动化测试方面最常见的考点是Selenium的基本使用、元素定位方式id、name、class、xpath、css selector、PO模式Page Object的设计思路以及接口自动化测试中如何管理token和cookie。笔试题不会让你写完整的自动化脚本但会通过选择题考察你是否理解这些概念。性能测试方面需要掌握几个核心指标QPS每秒请求数、TPS每秒事务数、响应时间、并发用户数、吞吐量。你要能理清它们之间的关系QPS是指单位时间内完成的请求数而响应时间是指从发送请求到收到响应的时间两者之间存在反比关系——在系统达到瓶颈之前并发数增加QPS提升但响应时间也会变大一旦超过瓶颈QPS反而会下降。考察性能测试的题目往往会给一组压测数据让你判断系统是否存在瓶颈、需要优化哪个环节。比如一个接口平均响应时间2秒QPS上限1000但线上业务峰值需要支撑2000 QPS你怎么优化常见的思路是先看代码逻辑有没有慢查询、再看缓存命中率、再看数据库连接池配置、最后考虑水平扩容。这其实是在考察你分析问题的思路是否完整。5. 笔试现场提分技巧与常见问题排查5.1 时间分配与做题顺序京东这套笔试题的题量不小正常情况下选择题40道左右、编程题2道、测试设计题1道考试时间90分钟。时间分配上我建议选择题控制在40分钟以内编程题30分钟测试设计题20分钟。选择题拿不准的先标记跳过不要在一道题上纠结超过2分钟因为后面的编程题和设计题每一分都比选择题值钱。做题顺序上我个人的习惯是先做编程题再做选择题最后做测试设计题。原因是编程题需要清醒的大脑和完整的思路趁精力充沛的时候先啃硬骨头。选择题即便后面时间紧张蒙一个答案也有25%的正确率但编程题不会就是不会。测试设计题放在最后是因为它不需要太多计算但需要静下心来全面思考相对容易在时间紧张时保质完成。当然这只是一个参考顺序实际考试时要根据自己的强项灵活调整。如果你选择题基础特别扎实先做选择题可以建立信心进入状态。5.2 高频失误与规避方法我在辅导过的简历上看到最多的问题不是知识点不会而是考场上的低级失误。归纳起来有三个高频坑。第一个坑是审题不清。笔试系统里描述的题目往往比你平时练习的题目更复杂动不动就一大段业务背景。很多同学看到前面几行就觉得自己见过这道题直接套用模板结果漏掉了题目最后一句的限制条件。建议每道题读三遍第一遍看题目问的是什么第二遍圈出关键条件第三遍确认输入输出格式。第二个坑是边界条件遗漏。写代码时只考虑了正常情况忽略了空数组、极大值、极小值、重复元素、负数、字符串为空这些边界。这种错误在LeetCode上可以通过测试用例发现但在笔试系统里没有提示只能靠自己在写代码时养成下意识检查边界的习惯。我每次写完代码都会回头问自己如果输入是空我的代码会怎么样如果输入是最大值会不会溢出第三个坑是测试用例设计过于零散。很多同学写测试设计题时想到一个写一个用例之间没有逻辑关联。面试官看这种答案会觉得你没有系统性思维。我建议在答题之前先在草稿纸上列一个测试维度清单比如功能测试、接口测试、兼容性测试、性能测试、安全测试然后按清单逐项展开这样既有层次感又不容易遗漏。5.3 笔试后的复盘方法最后聊聊笔试结束之后应该做什么。很多人考完就撒手不管了等结果出来再决定要不要准备下一家。我的建议是考完趁记忆还新鲜立刻把里面的题目回忆出来整理成文档特别是编程题和测试设计题。为什么要这么做最大的原因是笔试题目具有很强的重复性。你这次没做出来的题下次换一家公司大概率会碰到类似的。我把京东这套题复盘之后整理的文档后来在另外两家的笔试里直接命中了同类题型。而且复盘本身就是一次学习你会发现自己当时卡在哪里、知识盲区在哪这时候针对性地查漏补缺效率比漫无目的地刷题高得多。复盘的方法很简单先把题目重新做一遍不看参考答案再对照网上能找到的题解或讨论检查自己的思路最后把题目的考点、自己的第一反应、最优解、错误原因写成一个索引表。这个索引表在你面试前冲刺复习时会非常宝贵。我个人这几年带过不少新同学每次都会让他们把笔试复盘文档留底。一年后再翻出来看大部分人都会感慨这些考点其实大学都学过当时觉得难纯粹是因为没建立知识之间的联系。测试开发这个岗位的笔试就是这样不靠死记硬背也不靠奇技淫巧它考察的是你在大学四年里有没有认真对待每一门专业基础课以及你有没有养成用测试思维看世界的好习惯。准备笔试的过程其实是把你学过的东西重新串起来的过程这个功夫下到了拿到的不只是一张笔试通过的通知更是入行测试开发的第一块基石。 测试开发校招笔试核心考点全解析：从数据结构到测试思维
先说说这套题的总体观感。京东2019校招测试开发工程师的笔试放在今天看依然很有代表性。它不追求偏题怪题而是实打实地考察一个测试开发候选人应该具备的基础功数据结构与算法、计算机网络、操作系统、数据库以及最关键的测试思维。我当时做完这套题最大的感受是它不是想难倒你而是想通过一套题看清你有没有做测试开发的底子。这篇文章我会把整套题的考点拆开揉碎结合我自己的答题思路和后来做面试官的经验讲清楚每一类题背后的考察逻辑以及怎么准备才能稳稳通过。如果你正在准备大厂校招的测试开发岗或者刚入行想系统补齐基础知识这篇文章可以当作一份复习地图来用。我会把高频考点、典型题目、容易踩的坑还有笔试现场的提分技巧全部梳理清楚。1. 京东测试开发校招笔试的整体思路拆解1.1 考点分布与出题逻辑京东这套笔试的题型大致分为四块单选题、多选题、编程题、测试设计题。单多选覆盖计算机基础编程题考察代码实现能力测试设计题则直接检验你有没有测试思维。这个结构在互联网大厂校招里很常见但京东有自己的侧重点。首先计算机网络和操作系统是选择题的绝对主力。TCP三次握手、HTTP状态码、进程与线程的区别、死锁产生的条件这些几乎是必考的。京东作为电商平台对网络协议的理解有天然的业务需求毕竟每秒钟都有大量的请求在浏览器和服务器之间流转。候选人如果连GET和POST的区别都说不清楚那后续的接口测试、性能测试根本无从谈起。其次数据结构与算法在编程题中占了很大比重。链表操作、字符串处理、数组排序这类基础题是主流难度不会到ACM竞赛那种级别但要求你写得又快又对。京东的编程题有一个特点很多题目会带一点业务背景比如商品价格排序、订单状态判断、优惠券计算这其实是在考察你把算法应用到实际场景的能力。最后测试设计题是整套笔试题的灵魂。它通常会给一个具体的功能模块比如登录、购物车、订单支付让你设计测试用例。这道题的分值往往不高但它是面试官判断你是否有测试思维的重要依据。很多科班出身的同学写代码很厉害一到测试设计题就露怯只能写出“输入正确的账号密码登录成功”这种毫无营养的用例这就是典型的测试思维缺失。1.2 笔试与面试的联动关系顺着笔试往下说你会发现京东的笔试和面试是环环相扣的。笔试里你写过的测试用例面试官可能会让你现场重新设计一遍然后追问你“为什么这么设计”“还有没有遗漏的场景”。笔试里考察的算法题面试时可能换一个业务背景再让你手写一遍。所以准备笔试不能只为了过笔试而是要把每一道题都当成面试的预演。我认识不少同学笔试高分通过结果面试时基础概念一问三不知这就是典型的“刷题式备考”——只记答案不理解背后的原理。反过来也有人笔试分数一般但面试时把测试设计的思路讲得很透彻最后依然拿到了offer。那具体的知识点应该怎么准备下面我把几个核心模块逐一拆解。2. 编程题的核心考点与解题要点2.1 高频算法题型与应对策略从京东历年的出题风格来看编程题一般有两道难度递进。第一道通常是easy到medium级别的题目比如字符串处理、数组操作、链表反转第二道会稍微复杂一些可能涉及动态规划、二叉树遍历、或者带有业务包装的场景题。我统计了一下近几年测试开发岗位的编程题出现频率最高的题型有这几类字符串类字符统计、子串判断、版本号比较、括号匹配。数组类去重排序、两数之和、最大子序和、数组旋转。链表类链表反转、环形链表判断、合并两个有序链表。场景应用题满减优惠计算、库存扣减逻辑、订单状态流转判断。很多同学会问测试开发工程师为什么要考算法这里我要说一个很多人没想明白的点测试开发写自动化框架、设计测试平台、开发性能压测工具本质上都是在写代码。如果没有扎实的算法基础写出来的框架效率低、扩展性差遇到大数据量的测试场景就会出问题。所以算法不是刁难人而是筛选程序员的底线。2.2 典型编程题逐步推演版本号比较我挑一道比较有代表性的题目来推演一遍——版本号比较。这道题在京东笔试里出现过变形而且它非常贴近真实开发场景App发版、接口兼容性判断都需要比较版本号。题目描述大致是给定两个字符串形式的版本号如1.10.2和1.9.0按从左到右的顺序比较每个修订号的大小。如果version1大于version2返回1小于返回-1相等返回0。注意版本号可能长度不一致比如1.0和1.0.0应视为相等。拿到这道题我建议按下面的思路来拆解第一步把字符串按.分割成数组。比如1.10.2分割成[1,10,2]。第二步确定两个数组的最大长度用0补齐较短的数组。这里补齐成等长的好处是后续比较逻辑统一不用单独处理长度不一致的情况。第三步逐个比较对应位置上的数字大小。把字符串转成数字后直接比较因为版本号的每一位都是非负整数不会出现负数。第四步如果全部相等返回0。按照这个思路写出来的代码很简洁def compare_version(v1, v2): arr1 v1.split(.) arr2 v2.split(.) n max(len(arr1), len(arr2)) for i in range(n): num1 int(arr1[i]) if i len(arr1) else 0 num2 int(arr2[i]) if i len(arr2) else 0 if num1 num2: return 1 elif num1 num2: return -1 return 0这里有两个细节值得注意。第一个是补零策略1.0和1.0.0之所以相等因为缺省位补零后每一位都相等。第二个是int转换如果你直接用字符串比较会得到10小于9的错误结果这是LeetCode同类题目里最常见的坑。作为测试开发看到这道题你还应该多问一句如果版本号里有前缀v怎么办如果某一节有前导零怎么办如果版本号包含字母后缀比如1.0.0-beta怎么办这些都是你在设计测试用例时要考虑的场景。在笔试答卷里如果你能在代码之外补充这些边界情况的说明面试官会对你有额外的好感。2.3 编程题的高分写法与常见失误编程题不是写出来就完事阅卷时会看你的代码风格和解题思路。我给准备笔试的同学三个实操建议。第一个建议先写注释再写代码。在正式编码之前用注释把解题思路写清楚哪怕代码有瑕疵阅卷人也能看出你的思考过程。很多同学一上来就敲代码忽略了注释遇到复杂的逻辑就容易把自己绕晕。第二个建议变量命名要见名知意。不要用a、b、c这种毫无信息的命名用left、right、cur、count这样的命名会让你自己写起来更顺手阅卷时也更容易理解你的代码。第三个建议写完代码一定要自己跑一遍示例。很多在线笔试系统不支持运行调试你需要在心里模拟执行一遍检查边界条件。我见过太多人写了快排却处理不了数组长度为0或1的情况一提交就数组越界。还有一类常见失误是输入输出格式没搞对。有的同学在本地IDE里写了完整的类定义结果笔试系统要求只写核心函数最后格式不对一分不得。建议考前了解一下目标公司的笔试系统用的是牛客网、赛码网还是自家系统提前适应它们的输入输出规范。3. 计算机基础选择题失分重灾区与高分策略3.1 计算机网络必考知识点盘点单多选里的网络题考察范围相对固定集中在TCP/IP协议栈和HTTP协议这两个大方向上。TCP三次握手几乎是年年必考。你要理解为什么是三次而不是两次第一次握手客户端发送SYN第二次服务端回复SYNACK第三次客户端再回复ACK。三次握手的关键作用是确认双方的收发能力都正常。如果你只答出“建立连接要三次握手”而不理解背后原因面试时很容易被追问到答不上来。HTTP相关的考点则集中在状态码和请求方法上。200、301、302、400、401、403、404、500、502、503这几个状态码的含义要脱口而出。特别是301和302的区别301是永久重定向302是临时重定向这在接口测试中很常见。GET和POST的区别也是高频考点但要注意这个问题的标准答案已经随着HTTP协议的发展发生了变化——现在的浏览器和服务器对GET和POST的处理方式已经没那么大差异了你需要从语义、请求体、幂等性、缓存等角度去分析而不是背老一套的“GET有长度限制POST没有”。Session和Cookie的区别也需要掌握。Session存在服务端Cookie存在客户端Session id通常通过Cookie传递。电商场景下购物车数据放Session还是放Redis为什么这个问题如果你答得好会让面试官觉得你懂业务。3.2 操作系统高频考点与易错点操作系统部分进程与线程的区别是必考题。核心要点是进程是资源分配的最小单位线程是CPU调度的最小单位同一进程下的线程共享地址空间和资源进程之间相互独立。这个知识点在性能测试中特别重要——你压测时要清楚并发到底是指进程并发还是线程并发这直接影响压测模型的设计。死锁产生的四个必要条件也是常客互斥、持有并等待、不可剥夺、循环等待。问你怎么避免死锁答案就藏在条件里——破坏任意一个条件即可。实际工作中写自动化脚本时如果涉及多线程同时操作共享资源一定要考虑加锁和释放的顺序不然就可能出现死锁导致脚本hang住。内存管理里堆和栈的区别、虚拟内存、页面置换算法是选择题的重点。堆是程序员手动管理的内存区域栈由编译器自动分配和释放。我在笔试时总结了一个口诀堆靠new和malloc栈靠系统自动来。这个区别在写测试代码时也有体现——你创建的对象多了堆内存不够就会OOM而递归层级太深则会导致栈溢出。3.3 数据库SQL高频考点与实例数据库在测试开发笔试中的地位很高因为几乎所有的测试工作都离不开数据校验。选择题常考索引失效的场景、事务的ACID特性、SQL执行顺序而更多的分数来自专门的SQL编程题。这里我讲一个典型的SQL题统计每个商品分类下销量最高的前三个商品。假设有三张表商品表productid, name, category_id订单表ordersid, order_time, user_id订单明细表order_itemid, order_id, product_id, quantity首先需要理清表之间的关联关系订单表通过order_id关联订单明细表订单明细表通过product_id关联商品表商品表通过category_id关联分类表。第一步关联三张表得到每个商品的销售总量SELECT p.category_id, p.id AS product_id, SUM(oi.quantity) AS total_quantity FROM product p JOIN order_item oi ON p.id oi.product_id JOIN orders o ON oi.order_id o.id GROUP BY p.category_id, p.id第二步用窗口函数按分类分组、按销量排序取前三SELECT category_id, product_id, total_quantity FROM ( SELECT p.category_id, p.id AS product_id, SUM(oi.quantity) AS total_quantity, ROW_NUMBER() OVER(PARTITION BY p.category_id ORDER BY SUM(oi.quantity) DESC) AS rn FROM product p JOIN order_item oi ON p.id oi.product_id JOIN orders o ON oi.order_id o.id GROUP BY p.category_id, p.id ) t WHERE rn 3这里有两个关键点。第一窗口函数ROW_NUMBER()在MySQL 8.0及以上版本才支持如果你环境是5.7就需要用用户变量模拟或者改用GROUP_CONCAT等变通方案。第二取前三名时如果销量并列ROW_NUMBER会随机排序如果你希望并列的都显示应该用DENSE_RANK()或者RANK()具体用哪个取决于题目要求“前三名”是有几个名额还是所有并列都算。我还想提醒一个SQL笔试的共性问题很多人写SQL不会在头脑里执行写出来的语句逻辑上说不通。我的建议是拿一张小表手动模拟一下每一步的执行结果确认每一步的过滤条件、分组逻辑都符合预期后再提交。SQL本身语义复杂一步错步步错不像代码可以调试必须靠推演。4. 测试设计题最能拉开差距的题型4.1 测试用例设计的思维模型测试设计题是测试开发笔试和普通开发笔试最不一样的题型。它不考你写代码而是考察你有没有“找漏洞”的思维习惯。要做好测试设计题核心是建立一套自己的思维模型而不是靠灵光一现。我常用的一个思维模型叫“三层分析法”第一层是功能层。从用户的角度思考这个功能应该怎么用正常的操作路径是什么。比如购物车结算功能用户把商品加入购物车点击结算选择地址选择支付方式确认支付这是主流程。第二层是逻辑层。从系统的角度思考这个功能背后有哪些规则和约束。比如购物车结算要考虑商品库存是否充足、优惠券是否满足使用条件、满减活动是否叠加、商品是否下架、价格是否变动、收货地址是否有效这些都属于逻辑层面的校验。第三层是异常层。从对抗的角度思考系统在异常情况下能不能正确处理。比如网络中断、支付超时、重复提交、并发操作、数据丢失、接口返回异常这些场景测试新人很容易忽略但恰恰是线上最容易出问题的地方。用这个模型去设计用例基本可以保证不遗漏大方向。当然要拿高分还需要结合具体的业务场景和测试方法。4.2 典型电商场景测试设计实例以京东笔试里比较有代表性的“购物车结算功能”为例我写几个核心测试用例来演示。先看功能层。主流程用例包括用户登录后添加商品到购物车点击结算按钮选择商品、修改数量、进入订单确认页选择收货地址、支付方式、核对订单金额提交订单并完成支付。这些用例关注的是功能能否走通通常用正例来覆盖。再看逻辑层。这里要结合电商的业务规则来设计用例购物车中有多个商品部分商品库存不足结算时给出提示并允许移除库存不足的商品。商品价格在加入购物车后发生变化结算时按最新价格计算并弹窗提示用户。优惠券金额加上满减活动的总额不超过订单金额防止出现负支付金额。结算时身份校验失败提示用户重新登录购物车数据不丢失。收货地址数量为0时引导用户新增地址而不是直接报错。这些用例可以用等价类划分和边界值分析法来设计。比如价格优惠金额的边界值测试订单金额100元一张满100减20的券那正好100元应该能用99.9元就不能用100.1元肯定能用。这组边界值用例在产品逻辑里很容易被忽略但测试必须覆盖。再看异常层。典型的异常用例包括点击提交订单后断网订单状态处于未知状态再次进入时能通过订单查询接口确认实际状态用户连点两次提交按钮系统只生成一个订单幂等性测试两个用户同时购买同一件只剩一件的商品只有一个能下单成功并发测试。这些用例是测试设计的加分项也是面试官判断你有没有实战经验的试金石。4.3 自动化测试和性能测试基础考点京东的笔试题里偶尔会涉及自动化测试和性能测试的基础概念。不需要你精通工具但至少要理解核心原理。自动化测试方面最常见的考点是Selenium的基本使用、元素定位方式id、name、class、xpath、css selector、PO模式Page Object的设计思路以及接口自动化测试中如何管理token和cookie。笔试题不会让你写完整的自动化脚本但会通过选择题考察你是否理解这些概念。性能测试方面需要掌握几个核心指标QPS每秒请求数、TPS每秒事务数、响应时间、并发用户数、吞吐量。你要能理清它们之间的关系QPS是指单位时间内完成的请求数而响应时间是指从发送请求到收到响应的时间两者之间存在反比关系——在系统达到瓶颈之前并发数增加QPS提升但响应时间也会变大一旦超过瓶颈QPS反而会下降。考察性能测试的题目往往会给一组压测数据让你判断系统是否存在瓶颈、需要优化哪个环节。比如一个接口平均响应时间2秒QPS上限1000但线上业务峰值需要支撑2000 QPS你怎么优化常见的思路是先看代码逻辑有没有慢查询、再看缓存命中率、再看数据库连接池配置、最后考虑水平扩容。这其实是在考察你分析问题的思路是否完整。5. 笔试现场提分技巧与常见问题排查5.1 时间分配与做题顺序京东这套笔试题的题量不小正常情况下选择题40道左右、编程题2道、测试设计题1道考试时间90分钟。时间分配上我建议选择题控制在40分钟以内编程题30分钟测试设计题20分钟。选择题拿不准的先标记跳过不要在一道题上纠结超过2分钟因为后面的编程题和设计题每一分都比选择题值钱。做题顺序上我个人的习惯是先做编程题再做选择题最后做测试设计题。原因是编程题需要清醒的大脑和完整的思路趁精力充沛的时候先啃硬骨头。选择题即便后面时间紧张蒙一个答案也有25%的正确率但编程题不会就是不会。测试设计题放在最后是因为它不需要太多计算但需要静下心来全面思考相对容易在时间紧张时保质完成。当然这只是一个参考顺序实际考试时要根据自己的强项灵活调整。如果你选择题基础特别扎实先做选择题可以建立信心进入状态。5.2 高频失误与规避方法我在辅导过的简历上看到最多的问题不是知识点不会而是考场上的低级失误。归纳起来有三个高频坑。第一个坑是审题不清。笔试系统里描述的题目往往比你平时练习的题目更复杂动不动就一大段业务背景。很多同学看到前面几行就觉得自己见过这道题直接套用模板结果漏掉了题目最后一句的限制条件。建议每道题读三遍第一遍看题目问的是什么第二遍圈出关键条件第三遍确认输入输出格式。第二个坑是边界条件遗漏。写代码时只考虑了正常情况忽略了空数组、极大值、极小值、重复元素、负数、字符串为空这些边界。这种错误在LeetCode上可以通过测试用例发现但在笔试系统里没有提示只能靠自己在写代码时养成下意识检查边界的习惯。我每次写完代码都会回头问自己如果输入是空我的代码会怎么样如果输入是最大值会不会溢出第三个坑是测试用例设计过于零散。很多同学写测试设计题时想到一个写一个用例之间没有逻辑关联。面试官看这种答案会觉得你没有系统性思维。我建议在答题之前先在草稿纸上列一个测试维度清单比如功能测试、接口测试、兼容性测试、性能测试、安全测试然后按清单逐项展开这样既有层次感又不容易遗漏。5.3 笔试后的复盘方法最后聊聊笔试结束之后应该做什么。很多人考完就撒手不管了等结果出来再决定要不要准备下一家。我的建议是考完趁记忆还新鲜立刻把里面的题目回忆出来整理成文档特别是编程题和测试设计题。为什么要这么做最大的原因是笔试题目具有很强的重复性。你这次没做出来的题下次换一家公司大概率会碰到类似的。我把京东这套题复盘之后整理的文档后来在另外两家的笔试里直接命中了同类题型。而且复盘本身就是一次学习你会发现自己当时卡在哪里、知识盲区在哪这时候针对性地查漏补缺效率比漫无目的地刷题高得多。复盘的方法很简单先把题目重新做一遍不看参考答案再对照网上能找到的题解或讨论检查自己的思路最后把题目的考点、自己的第一反应、最优解、错误原因写成一个索引表。这个索引表在你面试前冲刺复习时会非常宝贵。我个人这几年带过不少新同学每次都会让他们把笔试复盘文档留底。一年后再翻出来看大部分人都会感慨这些考点其实大学都学过当时觉得难纯粹是因为没建立知识之间的联系。测试开发这个岗位的笔试就是这样不靠死记硬背也不靠奇技淫巧它考察的是你在大学四年里有没有认真对待每一门专业基础课以及你有没有养成用测试思维看世界的好习惯。准备笔试的过程其实是把你学过的东西重新串起来的过程这个功夫下到了拿到的不只是一张笔试通过的通知更是入行测试开发的第一块基石。