360测试工程师笔试考点全解析：从测试理论到自动化与安全

1. 从360校招笔试题聊起测试工程师到底在考什么很多人一听到“笔试”两个字就头皮发麻尤其是测试岗总觉得不如开发岗“有技术含量”应该随便写写就能过。说实话这种想法我当年也有直到真正参加了360那年的校招笔试才发现自己错得离谱。360的测试工程师笔试客观题部分涵盖的范畴非常广软件测试基础理论、测试用例设计、Linux命令、数据库SQL、计算机网络协议、数据结构与算法、自动化测试工具、性能测试指标、安全测试常识甚至还包括一些逻辑推理和场景分析题。它不要求你把某一门课学成专家但要求你在本科四年学过的所有计算机核心课程里都有扎实的基础并且能把它们和“测试”这件事联系起来。换句话说它考的不是“你会不会写代码”而是“你有没有测试思维”以及“你知不知道在什么场景下用什么手段保证质量”。这篇文章我就结合360这套客观题合集把典型的考点拆开揉碎了讲一遍也会把我自己备考和实际工作多年后回头看的一些体会放进去。不管你是正在准备校招还是刚入行想补基础这篇内容应该都能给你一个比较完整的参照系。2. 测试基础理论类题目最容易拿分也最容易丢分2.1 软件测试的定义与目的少背概念多理解本质笔试里最常见的一类送分题就是关于软件测试的定义、目的、原则。比如“软件测试的目的是什么”“下列哪项不属于测试原则”等等。很多同学背得滚瓜烂熟却还是选错原因在于概念背得太死没有理解背后的逻辑。软件测试的目的本质上不是“证明软件没有Bug”而是“发现程序中的错误从而证明软件质量不满足要求”。注意这里的措辞差异——测试是一个“证伪”的过程不是“证实”的过程。这就像你检查一扇门有没有锁好你只能通过反复拉动来确认它可能存在锁不上的情况但永远无法通过拉动一次就证明它永远锁得好。笔试题目喜欢在这种地方挖坑把“证明正确性”这种话放在选项里很多不细想的人就直接跳进去了。测试的基本原则也是高频考点。比如“测试应尽早介入”“测试中存在杀虫剂悖论”“缺陷具有集群性”“测试不能穷尽”等。其中“杀虫剂悖论”这个概念笔试经常换着花样考如果反复执行相同的测试用例新的缺陷就无法被发现了因为系统已经“适应”了这套用例。这个比喻来自农药杀虫害虫会产生抗药性软件也一样。答题时要抓住关键词“相同用例反复执行”基本就能锁定答案。2.2 测试用例的组成要素比你想象的更细还有一类题是给出一段需求描述让你判断测试用例中缺少了什么要素。标准的测试用例要素包括用例编号、测试标题、前置条件、测试步骤、测试数据、预期结果、实际结果、优先级等。笔试中常考的坑是“预期结果”和“测试数据”被混在一起或者把“前置条件”和“测试步骤”混淆。我举个例子你就明白了。比如要测试一个登录功能前置条件是“用户已注册且账号未被锁定”测试步骤是“输入用户名和密码点击登录”测试数据是“用户名test密码123456”预期结果是“登录成功跳转到首页”。这里每一步都有各自的位置不能乱塞。有的题目会把“点击登录后页面跳转”放在前置条件里那就是错的。这类题看似简单但恰恰是很多科班出身的人容易栽跟头的地方因为平时写用例少对要素的理解停留在理论层面。我的建议是不管是不是在准备笔试都亲手写几轮完整的测试用例从登录、注册这种基础功能开始写到购物车、订单流程这种带状态的场景。写多了要素自然就刻在脑子里了。2.3 测试分类与开发模型V模型、W模型和敏捷测试测试的分类也是个重要出题点。按阶段划分、按是否运行程序划分、按是否查看源代码划分这三种维度要分清楚。按阶段单元测试、集成测试、系统测试、验收测试按是否运行程序静态测试、动态测试按是否查看源代码黑盒测试、白盒测试、灰盒测试这里最容易混淆的是“集成测试”和“系统测试”的区别。集成测试关注的是模块之间的接口和交互是否正确系统测试关注的是整个系统作为一个整体是否满足需求规格说明。打个比方集成测试像是检查水管和龙头接在一起漏不漏水系统测试像是打开总阀门看整个房子所有水路通不通。开发模型里V模型是笔试绝对绕不开的重点。V模型把开发和测试对应起来需求分析对应验收测试概要设计对应系统测试详细设计对应集成测试编码对应单元测试。这个映射关系几乎每年都考而且有时会换个形式比如给出一个阶段让你选对应的测试类型。W模型则是V模型的补充强调测试与开发同步进行也就是“双V”模型开发和测试并行。敏捷测试在笔试里相对没那么深但近几年的题开始涉及“测试驱动开发TDD”和“持续集成中的测试分层”这类概念可以适当留意。3. 测试用例设计方法黑盒测试的看家本领3.1 等价类划分别把边界值混进来黑盒测试的用例设计方法里等价类划分和边界值分析是笔试的绝对主力。等价类划分的核心思想是把输入域划分成若干个子集每个子集中的数据对揭露程序错误的作用是等价的所以只需要从每个子集中取一个代表值进行测试即可。这里有个关键点需要理解有效等价类和无效等价类的区分。所谓有效等价类是满足需求规格说明的输入无效等价类是不满足需求的输入。大多数情况下笔试题目会这样出一个输入框要求输入1到100之间的整数问下列哪组数据属于无效等价类。答案是0、101、-5、3.14这类。但注意3.14这个选项其实是有争议的因为它不只是超出了范围还涉及类型不对。有些严谨的题目会把“类型不合法”作为一个独立的无效等价类来处理和“范围超界”分开考。3.2 边界值分析笔试的送分题也是丢分题边界值分析可以和等价类划分结合使用。它关注的是输入域边界附近的情况因为大量缺陷都发生在边界值上。一个取值范围是1到100的输入框边界值要测的是0、1、2、99、100、101这六个点。笔试题目往往会在选项中设置一些干扰项比如50、98这种中间值它们不是边界值选了就错。为什么要重视边界值因为开发人员在写判断条件时经常会写错等号比如写成“age 18”而不是“age 18”或者把“”写成“”。这些错误在输入中间值的时候根本测不出来只有在边界上才会暴露。实际工作中我就遇到过很多次金额计算、日期区间判断、分页查询的页码边界这类Bug在开发自测阶段完全发现不了一上边界值用例就现出原形。3.3 判定表、因果图和场景法逻辑组合题怎么破当输入条件存在组合关系时等价类和边界值就不够用了这时候要用判定表或因果图。判定表由条件桩、动作桩、条件项和动作项组成。笔试中常考的是根据一段需求画出判定表或者根据判定表判断覆盖了哪些规则。实际上判定表就是一种穷举策略列出所有条件组合及对应的动作它的好处是保证完整性不会漏掉某种组合。缺点是当条件数量多时组合数会呈指数增长所以实际工作中通常只对关键业务规则使用判定表。场景法在笔试中也经常出现尤其是考“基本流”和“备选流”的概念。比如一个ATM取款流程基本流是插卡、输密码、输入金额、出钞、退卡备选流包括密码错误、余额不足、ATM机没钱、银行卡被吞等。题目会问某个异常分支属于基本流还是备选流或者要求你识别某个场景漏掉了哪条备选流。这类题的答题技巧是把自己代入用户视角把所有可能走歪的路都列出来就基本不会漏。4. 自动化测试与工具不只是Appium和Selenium4.1 自动化测试的适用场景和局限性自动化测试的题目在笔试中大致分两类一类是概念性的比如“自动化测试能替代手工测试吗”“什么项目适合引入自动化测试”另一类是具体工具使用比如Selenium定位元素的方式、Appium的架构、pytest的断言写法等。概念题里最常见的正确表述是“自动化测试适合回归测试、重复执行的测试场景不适合探索性测试和一次性的测试任务”。很多同学会选“自动化测试可以完全替代手工测试”这在任何情况下都是错的。自动化测试有其局限性脚本维护成本高、对需求变更敏感、初期投入大、无法模拟人的主观判断。实际工作中我见过太多团队一上来就想把所有用例自动化结果一个版本迭代后脚本全部废掉维护成本比手工执行还高。4.2 Selenium和Appium的常见考点Selenium的笔试考点非常固定元素定位方式id、name、class name、tag name、link text、partial link text、xpath、css selector、显式等待和隐式等待的区别、WebDriver的工作原理。这里要说一个高频陷阱题显式等待和隐式等待的区别。显式等待是针对某个元素设置的可以在代码中指定等待条件和超时时间隐式等待是全局设置的在WebDriver实例化后设置一次对所有元素生效。如果同时使用显式和隐式等待超时时间以较长时间为准而不是取较短的那个。这个细节很多资料里没写清楚笔试里一旦出对比题特别容易错。Appium的笔试考点主要集中在架构上Appium是基于WebDriver协议扩展而来的通过Android的UIAutomator和iOS的XCUITest驱动底层自动化。还有一个常考的点是Appium的会话Session机制以及Desired Capabilities的作用——它是启动Appium会话时传入的一组键值对用来告诉Appium服务端你要测试什么平台、什么应用、什么设备。4.3 pytest和Jenkins的联动笔试题的新趋势近几年测试开发的概念越来越普及笔试题也开始涉及测试框架和CI/CD的内容。pytest作为目前Python生态里最主流的测试框架在笔试中出现频率越来越高。pytest的常见考点包括fixture的作用域function、class、module、session、参数化parametrize、断言写法assert语句、用例收集规则test_开头或_test结尾的文件、函数以test_开头。这里我提醒一句pytest的fixture作用域是经常考的点尤其是session和module的区别——session是每个会话只执行一次module是每个模块执行一次。如果你没实际用过fixture光靠背概念遇到参数组合的题很容易搞混。Jenkins相关的题目则偏向于流水线概念比如“持续集成中哪个阶段适合执行自动化测试”。答案是构建后的测试阶段。有些题还会问“在Jenkins中配置定时构建用什么表达式”答案是cron表达式例如“H 2 * * *”表示每天凌晨2点执行。这类题属于没接触过就不会接触过就白送分性价比很高建议备考时稍微了解一下。5. 性能测试与安全测试两道硬菜5.1 性能测试的核心指标QPS、响应时间、并发数、吞吐量性能测试在笔试客观题里考的是指标概念和工具参数。核心指标包括响应时间、吞吐量、并发用户数、QPS每秒查询数、TPS每秒事务数、错误率、资源利用率。这里有个概念辨析题非常经典并发用户数和在线用户数的区别。并发用户数是指同时发起请求的用户数量在线用户数是指同时连接在系统上的用户数量。一个在线用户可能并不会发起任何请求所以并发数一般远小于在线数。题目如果描述“系统有1000个在线用户其中10%的人同时提交请求”那么并发用户数是100而不是1000。另一个容易混淆的是QPS和TPS。QPS偏重查询类请求TPS偏重事务类请求。一个事务可能包含多个查询所以在有些场景下TPS是小于QPS的。但在纯查询接口的压测中两者数值可能接近。笔试中一般不会考得太深入只要记住QPS衡量每秒请求数TPS衡量每秒事务数即可。5.2 性能测试工具JMeter和LoadRunner怎么选JMeter近年来越来越火因为它是开源免费的而且支持协议广泛。笔试中关于JMeter的考点集中在线程组Thread Group的含义、监听器Listener的作用、断言Assertion的作用、参数化CSV Data Set Config的实现方式。有一个点很多新手会忽略JMeter默认情况下不会自动保存测试结果需要在测试计划中添加“查看结果树”或“聚合报告”等监听器来查看结果。笔试中如果问“在JMeter中查看响应数据需要添加什么元件”答案是监听器中的查看结果树。这个题不难但没见过就是不会。LoadRunner在笔试中也会出现但频率明显低于JMeter。主要记住它的三大组件Virtual User GeneratorVuGen录制脚本、Controller设计场景、监控场景、Analysis分析测试结果。这三个组件的功能分别是做什么的这是一个非常经典的笔试题。5.3 安全测试从SQL注入到XSS安全测试的客观题在测试岗笔试中占比不算大但几乎每年都会出。最常考的漏洞类型是SQL注入和XSS跨站脚本攻击。SQL注入的笔试形式通常是给一段代码问存在什么安全漏洞。比如String sql SELECT * FROM users WHERE username username AND password password ;如果username传入 OR 11整个SQL就会变成SELECT * FROM users WHERE username OR 11 AND password OR 11这样无论密码是否正确查询都会返回数据从而达到绕过登录的目的。答案是SQL注入。预防手段是使用参数化查询PreparedStatement而不是通过字符串拼接SQL。XSS则有两类需要区分反射型XSS非持久化和存储型XSS持久化。反射型XSS是恶意脚本通过URL参数传入服务器未做过滤直接返回给浏览器执行存储型XSS是恶意脚本被存储到数据库中其他用户访问页面时被加载执行。存储型XSS危害更大因为它影响所有访问该页面的用户。笔试中如果问“攻击者将恶意脚本上传到服务器数据库中其他用户访问时触发这属于哪类攻击”答案是存储型XSS。除了这两种偶尔也会考CSRF跨站请求伪造、越权访问、文件上传漏洞等。对于测试岗的客观题不需要你会挖洞但要知道每种漏洞的基本原理和最常见的防御手段。6. 网络、数据库、操作系统测试工程师的基础课6.1 Linux网络排查测试工程师的日常Linux命令在测试工程师笔试中的重要性怎么强调都不过分。因为测试环境大多部署在Linux服务器上日志查看、服务启动、端口检查、进程管理这些都绕不开Linux。常考命令我整理一下查看端口占用netstat -tlnp或ss -tlnp查看进程ps -ef | grep java查看日志tail -f app.log实时跟踪日志查看磁盘空间df -h查看内存使用free -h文件传输scp -r local_dir userhost:/remote_dir笔试中比较常挖坑的是“如何查看某个端口被哪个进程占用”和“如何实时查看日志变化”。前者答案是lsof -i :8080或netstat -tlnp | grep 8080后者答案是tail -f。有些选项会混入cat、vim这些不合适的命令眼力不好的同学会选错。6.2 数据库与SQL多表查询和事务隔离级别测试工程师笔试中SQL题目通常考三类单表查询where、group by、having、order by的配合使用、多表连接inner join、left join、right join的区别、事务隔离级别。这里说一个高频但容易错的知识点where和having的区别。where是在分组之前对记录进行筛选不能使用聚合函数having是在分组之后对分组结果进行筛选可以使用聚合函数。比如“查询平均成绩大于80分的学生姓名”需要在group by student_id之后用having avg(score) 80而不是用where avg(score) 80。事务隔离级别在测试岗笔试中出现的概率稍低但在面试中几乎是必问。四个级别读未提交、读已提交、可重复读、串行化。其中“可重复读”是MySQL InnoDB引擎的默认级别这一点经常考到。脏读、不可重复读、幻读这三种异常分别发生在哪一级别之下被解决也建议背清楚——它们之间的对应关系是读未提交可能发生所有三种读已提交解决脏读可重复读解决不可重复读和脏读串行化解决所有三种。6.3 HTTP协议与接口测试状态码和请求方法接口测试相关的笔试题核心还是HTTP协议基础。常考的状态码有200请求成功301永久重定向302临时重定向400客户端请求语法错误401未认证403服务器拒绝执行已认证但无权限404资源不存在500服务器内部错误502网关错误503服务不可用这里特别容易混的是401和403。401是“你是谁”未认证403是“我知道你是谁但你不许进来”无权限。笔试里经常会出一个场景让你判断返回什么状态码比如“用户未登录访问需认证的接口”应该返回401“普通用户访问管理员接口”应该返回403。请求方法方面GET和POST的区别是经典题。GET参数放在URL中长度受限主要用于查询POST参数放在请求体中适合提交大量数据。还有几个容易被忽略的PUT更新资源、DELETE删除资源、HEAD只获取响应头。注意PUT和POST的区别——PUT是幂等的执行多次和执行一次效果相同POST不是幂等的每次执行都可能创建新资源。6.4 数据结构和算法不考手写代码但考思路测试工程师的笔试算法题一般不会像开发岗那样要求手撕LeetCode但会通过选择题考察基础的数据结构知识和复杂度分析。常见考点包括栈和队列的区别后进先出 vs 先进先出、二叉树的遍历方式前序、中序、后序、层序、排序算法的时间复杂度、二分查找的前提条件有序数组等。这里说个有意思的题用两个栈实现一个队列。这个题目在开发笔试中也出现过但测试笔试里它换了个问法——问入队和出队的时间复杂度。两个栈实现队列的经典做法是入队时直接压入栈1出队时如果栈2为空把栈1的元素全部弹出压入栈2然后从栈2弹出栈顶。这样入队时间复杂度O(1)出队平均时间复杂度O(1)最坏情况O(n)。还有一个测试相关的高频考点是算法的时间复杂度分析比如冒泡排序的时间复杂度是O(n^2)快速排序平均复杂度是O(n log n)二分查找是O(log n)。这些数字要记牢因为题目里可能会混入“不稳定排序”或“最坏情况”等限定词比如快速排序在最坏情况下复杂度会退化为O(n^2)。7. 客观题避坑指南这些细节决定你能不能进面试7.1 题干中的绝对化用词看到“一定”“全部”“必须”要警惕做客观题有一个通用技巧选项里如果出现“一定会”“完全不会”“任何情况下都”这类绝对化表述这个选项大概率是错误的。测试领域更是如此因为软件测试本身就充满不确定性很少有绝对的结论。举个例子一道题问“关于自动化测试的描述正确的是”选项中有一个是“自动化测试可以完全替代手工测试”有一个是“自动化测试适合所有类型的应用”。这两项都含绝对化表述直接排除。虽然不绝对但大部分情况下这个技巧能帮你排除一到两个错误选项提高蒙对概率。7.2 多选和不定项宁缺毋滥还是宁滥勿缺360的笔试客观题我记得是包含单选和多选的。多选是很多人的噩梦因为少选、多选都不得分。策略上如果你对某个选项不确定建议不要选。因为多选的计分规则通常是全部选对才得分少选一个和错选一个结果都一样是0分那不如只选有把握的。但要注意有些题目会标注“至少有一个正确选项”或者“可能有一个或多个正确选项”读题时看清楚别拿单选的态度做多选也别拿多选的态度做单选。我见过很多同学栽在“不定项选择”上——题目其实是单选但因为没仔细看选项之间的关系多选了一个直接丢了分。7.3 时间分配客观题不要恋战整份试卷里客观题之后往往还有简答题和编程题。我的建议是客观题部分控制在总时长的三分之一以内遇到卡壳的题先标记不要在一道选择题上花超过两分钟。笔试考的不只是你会不会还有你在有限时间内如何分配精力。一道选择题只有一两分花五分钟去纠结挤占了后面大题的时间非常不划算。我自己当年考试时客观题有大概五道题是拿不准的全部先蒙了一个答案并做了标记等做完后面的题再回头复查最后复查改对了两道。7.4 从错题中总结知识图谱而不是背答案很多同学复习笔试题的方法是背答案比如“这道题选B下一道选C”。这种做法非常低效因为同一道题几乎不可能原封不动地出现在下一场笔试中但知识点是会反复考的。我建议每做完一套题就把错题对应的知识点记到一个表格里然后按照“测试理论/用例设计/自动化/性能/安全/网络/数据库/Linux”这几个维度分类。复习时重点看那些你反复出错的知识点——要是两套卷子都栽在“等价类划分”说明这块理解有问题需要回归教材重新梳理而不是继续刷题。我自己整理错题时用过一个简单的方法把知识点写成问题形式比如“边界值分析需要测哪六个点”“V模型中系统测试对应哪个开发阶段”然后遮住答案自己回答答不上来的就标记为薄弱点下一轮重点复习。这个方法比反复过一遍笔记有用得多因为它在逼你主动回忆而不是被动浏览。8. 从笔试到面试客观题结束真正的考验才开始客观题只是校招的第一关通过之后还有面试面试里问的东西反而比笔试更开放、更深入。360的面试通常会有技术面面试官可能会让你现场设计测试用例或者问“如何测试一个电梯”这种生活中随处可见却非常考验思路的题目。关于这类开放性问题笔试客观题打下的基础就派上用场了。回答“如何测试一个电梯”时你需要把等价类划分、边界值分析、场景法这些方法结合实际场景展开楼层选择要测的是超出范围比如只有1到30层输入31层、边界值1层、30层、非法输入负楼层、字母场景法要覆盖正常乘梯、紧急呼叫、超载报警、停电困人等流程。这些思路本质上就是在客观题中反复训练的测试思维。所以不要觉得笔试就是背题刷题它其实在帮你建立一个完整的测试知识体系。认真对待每一道客观题理解它背后的原理你收获的不只是笔试通过还有真正入行干活时需要的基本功。我在实际工作中带过不少校招新人发现一个规律笔试成绩高的人不一定干活最稳但基础知识扎实的人在面对新场景时思路明显更清晰。最终你会发现校招笔试真正折磨人的不是那几道不会做的题而是你平时到底有没有构建起属于自己的测试思维体系。这套体系一旦建立起来无论面试还是工作你都会比别人走得轻松从容。