企业官网建设流程全解析

想进360做软件测试的同学，估计都绕不开这套题。2015年的这份笔试题放在今天看，依然很有参考价值——不是因为题目有多新，而是它把软件测试工程师最核心的基本功全部串了一遍：测试理论、计算机网络、操作系统、数据库、编程基础，再加上一堆让你“现场设计测试用例”的应用题。很多培训机构出来的同学，简历上写着熟悉测试流程，一碰到这种笔试就直接露馅，因为题目不考背诵，考的是你有没有真正理解测试这件事。

这篇东西不是单纯把题目列出来对答案，而是带着你分析“360为什么这么出题”“每类题到底在筛什么人”“现场答题时怎么组织思路才能拿高分”。适合正在准备软件测试校招或社招笔试的人，也适合已经入行但想补基础、跳槽去大厂或安全厂商的测试工程师。哪怕你完全没接触过安全测试，看完也能把整套题的考察逻辑理顺。

1. 笔试总体结构与考察逻辑

1.1 题量与时间分布

2015年360的软件测试笔试，整场时间大概90到120分钟，题量不小，通常在60到80题之间。名义上是笔试题，实际上是“选择题+简答题+设计题+编程题”的混合体。现在很多公司把笔试挪到线上做，但360这套题当年是纸质作答，所以对书写速度和思路表达要求很高——你光在草稿上演算对了一半，写不到卷面上就等于没分。

从题型结构来看，大致可以分成四个块：

• 基础选择题：覆盖计算机基础、网络协议、操作系统、数据结构，会掺杂少量逻辑题。
• 测试理论题：包括测试分类、测试流程、用例设计方法、缺陷管理，多以简答形式出现。
• 场景设计题：给一个具体功能模块，让你现场设计测试用例，这是整张卷子分值占比最高的部分。
• 编程或逻辑题：一般放在最后，涉及C语言指针、数组、简单算法，重在考察代码功底和边界思维。

题量大的时候，很多人容易在前面选择题上磨太久，等做到用例设计题时只剩十分钟，直接血崩。所以拿到卷子第一件事不是埋头做题，而是花两分钟把整张卷子翻一遍，标出哪些题是不确定但分值高的，哪些是确定能拿分的，然后从性价比最高的题目开始做。这个习惯我到现在都觉得受用。

1.2 出题人真正想筛什么样的人

很多人以为360的测试笔试题会狂考安全测试，什么SQL注入、XSS、木马原理。实际上当时这套题的难点恰恰在于“不偏科”——它用大量基础题筛掉基础不牢的人，再用设计题筛掉没有测试思维的人。

软件测试这个岗位，尤其是安全厂商的测试岗，日常工作面对的不是简单的web页面，而是数款产品组合之下的复杂场景。比如当年的360安全卫士，一个版本要兼容几十种Windows环境，涉及杀毒、清理、漏洞修复、软件管家等多个模块，测试人员如果连进程和线程的区别、TCP三次握手的过程、SQL的left join都说不清楚，根本没办法跟开发沟通，更别提定位一个偶现的崩溃问题。

所以出题逻辑很直白：不指望你背了多少条测试理论，而是看你能不能把计算机基础知识和测试方法论结合起来用。举个典型的例子，卷子上可能会问你“等价类划分和边界值分析有什么区别”，然后下一道题就变成了“请你用这两种方法设计一个登录框的测试用例”。前面是知识，后面是应用，跨不过这个坎的人就是基础没吃透。

1.3 为什么这份老题现在还值得研究

这里有一个很多求职者容易忽略的点：笔试题目虽然每年在变，但考察的方式和底层逻辑高度稳定。当年360考察的是Linux命令、TCP协议、进程线程、数组指针，今天字节、腾讯、阿里考的还是这些东西，无非是换了层皮。你把2015年这套题的每个考点吃透了，再去做现在的新题，会发现大部分题目你都能看穿它的本质。

还有一种情况是，有的公司会直接把往年题拿来改改再用，甚至个别中小厂连改都不改。我见过不止一个朋友面试时碰到原题，结果因为当年没认真研究，白白丢掉送分题。所以别再纠结题目老不老，直接把这套当“题库母本”来啃，性价比最高。

2. 高频考点拆解与答题要点

2.1 软件测试基础理论：不是背概念，是会用

试卷第一部分的选择题和简答题，基本都会涉及测试的基本概念。别小看这些送分题，失分的人一大把。常考的点包括黑盒测试和白盒测试的区别、测试用例的八大要素、软件测试的生命周期、V模型和W模型的差异、回归测试和冒烟测试的使用场景。

有一道反复出现的经典题：什么是软件缺陷？很多人张口就说“程序出错”，这在测试工程师眼里完全不合格。软件缺陷的正确理解是：软件未实现需求文档中规定的功能，或者实现了但表现不符合预期，或者出现了需求文档中未提及但用户难以接受的问题，都算缺陷。换句话说，缺陷不是“代码写错了”这么简单，它跟需求、跟用户体验都挂钩。

答题的时候记住一个原则：概念题不要只写定义，最好补一句“在实际测试中的应用场景”。比如问你“什么是等价类划分”，你不但要写清楚定义，还可以补一句：“比如测试一个用户名输入框，有效等价类是长度6到20位的字符，无效等价类是空值、超长、特殊字符，我在实际用例设计中会优先覆盖这些边界。”这一句话就能让阅卷人看出你真的做过测试，而不是临时背的书。

2.2 操作系统和Linux命令：安全测试的隐形门槛

操作系统相关的题目，在360这套卷子里的比重明显高于一般互联网公司，原因其实很简单——安全产品测试离不开对系统底层的理解。常考的知识点包括进程和线程的区别、死锁产生的四个必要条件、内存管理的基本概念、虚拟内存和物理内存的关系。

进程和线程这道题几乎是必考的，你要能第一时间答出来：进程是操作系统资源分配的基本单位，线程是CPU调度的基本单位；同一个进程下的多个线程共享进程的地址空间和资源，而不同进程之间的地址空间是相互隔离的。面试官喜欢追问“多线程有什么好处”，你要能接上“可以减少并发时的系统开销，但需要注意线程安全问题”。

Linux命令这块，当年纸质考试没办法实机操作，所以更多是考记忆和理解。常见的有：

• ps：查看进程状态，配合aux参数查看所有进程的详细信息
• grep：文本搜索过滤，常配合管道符使用，例如ps aux | grep 360
• find：查找文件，按名字、权限、时间等条件过滤
• chmod：修改文件权限，chmod 755是常见的设置方式
• netstat：查看网络端口和连接状态，排查服务是否正常监听
• top：实时查看系统资源占用和进程状态

备考提示：别只是背命令，要自己搭个Linux虚拟机实际敲一遍，搞清楚每个命令的输出格式长什么样。因为笔试虽然只考选择和简答，但到了面试环节，很多面试官会现场让你手写命令，或者直接看你在终端里的操作熟练度，这个坑我见得太多了。

2.3 网络协议：三次握手、状态码、GET和POST的区别

计网是软件测试笔试的硬骨头，360这套卷子也一样。常考的知识点非常集中：TCP三次握手和四次挥手的过程、TCP和UDP的区别、HTTP状态码的含义、GET和POST的区别、DNS解析过程。

以TCP三次握手为例，你不但要能把过程画出来，还要能用通俗的话解释：第一次是客户端发SYN，表示“我要建立连接”；第二次是服务端回SYN+ACK，表示“我收到你的请求了，也准备好建立连接”；第三次是客户端再回ACK，表示“我也收到你的确认了，连接建立成功”。为什么需要第三次？因为如果只有两次握手，服务器无法确认客户端是否真的收到了自己的同步信号，可能造成资源浪费。

HTTP状态码在单选题里面基本会覆盖到，你至少要记住：

• 200：请求成功
• 301：永久重定向
• 302：临时重定向
• 403：服务器拒绝请求，权限不足
• 404：请求的资源不存在
• 500：服务器内部错误
• 503：服务器暂时不可用

GET和POST的区别也是一道高频题。最准确的理解从语义出发：GET是获取资源，参数放在URL后面，有长度限制，浏览器会缓存，不安全；POST是提交数据，参数放在请求体中，理论上没有长度限制，不会被浏览器主动缓存。但在实际项目中，很多开发者把GET当POST用，测试人员看到这种行为需要提bug吗?答案是：如果接口设计文档明确规定用POST，那开发用GET就是缺陷，不能因为“功能能跑”就忽略协议层面的问题。

2.4 MySQL和SQL：测试必备的定位工具

数据库的题目在测试笔试中几乎不会缺席，360这套题也不例外。考察方式不是让你背 SQL 语法，而是给你两张表，让你写查询语句，或者让你改正一段写错的SQL。

举个例子，假设有两张表：学生表student（id, name, age, class_id）和班级表class（id, class_name）。常见题目是“查询每个班级的学生人数并按人数降序排列”，正确答案是：

SELECT c.class_name, COUNT(s.id) AS student_count FROM class c LEFT JOIN student s ON c.id = s.class_id GROUP BY c.id, c.class_name ORDER BY student_count DESC;

注意几个细节：

• 用LEFT JOIN而不是JOIN，因为如果某个班级没有学生，内连接会把该班级过滤掉，不符合“每个班级”的要求
• GROUP BY 的字段除了聚合函数里的字段，其他需要包含所有非聚合查询列，否则在严格模式下会报错
• 排序用ORDER BY，降序是DESC，这个常被粗心写错

另外索引和事务也是常考点。索引的作用是加速查询，但会增加写入负担，所以不是越多越好；事务的ACID四个特性——原子性、一致性、隔离性、持久性——需要能解释清楚，尤其是隔离性相关的问题，比如脏读、不可重复读、幻读，这些名词在简答题里出现过很多次。

为什么测试要考数据库？因为bug定位、数据校验、接口测试都离不开数据库。你测一个注册功能，填完表单点提交，怎么判断数据是不是真正写进去了？最简单的办法就是登数据库查一下。测试人员写SQL的熟练程度，直接影响日常工作效率。

2.5 编程基础：数组和指针，C语言的基本功

当年这套题里有个有意思的现象：编程部分的题目特别偏爱C语言，而且非常喜欢考数组和指针。这跟360的产品基因有关，很多底层安全模块和客户端组件都是C或C++写的，测试人员如果能看懂代码，定位问题会快得多。

最经典的一道辨析题是：数组名和指针有什么区别？很多人张口就说“数组名就是指向首元素的指针”，严格来说是错的。数组名在大多数表达式中会退化为指向首元素的指针，但在两个场景下不会：一是sizeof(数组名)得到的是整个数组占用的字节数，而不是指针大小；二是对数组名取地址&arr时，得到的是指向整个数组的指针，类型是int ()[N]，而不是int。

另一个常考的是字符串和指针的关系：

char str1[] = "hello"; char *str2 = "hello";

这两者有什么区别？str1是字符数组，内容保存在栈上，可以被修改；str2是指针，指向字符串常量区，内容不可被修改，如果你尝试执行str2[0]='H'，程序会崩溃或产生未定义行为。测试人员在排查崩溃类bug时，这类内存问题非常常见。

如果卷子上出现了手写编程题，一般是比较简单的算法，比如反转字符串、求最大公约数、判断回文数等。作答时注意三点：先写注释说明思路；判空和边界条件不能漏；变量命名要清晰。哪怕代码不能运行，只要逻辑清晰、边界处理完整，阅卷人也会给大部分分值。

2.6 安全测试基础：360的特色加分项

虽然前面说这份卷子不狂考安全，但作为安全厂商，安全测试的基础概念依然是拉开差距的地方。至少三个名词你必须能解释清楚：XSS（跨站脚本攻击）、SQL注入、CSRF（跨站请求伪造）。不需要你写攻击代码，但要能说出攻击原理、危害和基本的防护思路。

• XSS：攻击者在网页中注入恶意脚本，当其他用户访问该页面时脚本执行，从而窃取cookie或篡改页面内容。防护思路是输入过滤和输出转义。
• SQL注入：攻击者把恶意SQL代码拼接到输入参数中，使服务器执行非预期的数据库操作。防护思路是使用参数化查询或预编译语句，不直接拼接SQL。
• CSRF：攻击者诱导已登录用户点击恶意链接，在用户不知情的情况下以用户身份发起请求。防护思路是增加CSRF Token验证和校验Referer字段。

答题的时候，如果能结合360产品的场景来描述会更好。比如“如果安全卫士的漏洞扫描功能检测到一个网页存在XSS漏洞，你会怎么设计测试用例？”，这时候你回答的框架就直接反映了你的安全测试素养。我的建议是：学安全测试先不需要看多深的攻击技巧，先把这三类基础漏洞的原理和测试方法吃透，笔试和大部分面试都够了。

3. 经典题型与答题思路现场拆解

3.1 用例设计题：拿分的关键在结构和边界

360这套笔试卷子里，最拉分的题目永远是测试用例设计题。常见给法有两种：一种给你一个具体功能，比如“请设计登录功能的测试用例”；另一种给你一个通用对象，比如“请设计一款电梯的测试用例”。应对这类题，关键是建立结构化的答题框架。

以登录功能为例，很多人的第一反应是列一堆“账号正确密码正确能登录”“账号错误提示错误”这类用例，然后就没有然后了。这样答题拿不到高分，因为内容太单薄，没有体现测试的系统性。我的建议是按以下维度展开：

• 功能测试：正常登录成功；用户名错误/密码错误/两者都错误时给出对应提示；空用户名、空密码的校验；密码大小写是否敏感；回车键能否提交；输错密码多次后被锁定的规则。
• 界面测试：页面布局是否正常、错误提示文案是否清晰、密码框是否掩码显示、字体和颜色在主流分辨率下是否正常。
• 性能测试：大量用户同时登录的并发情况；弱网环境下登录的响应时间；连续快速点击提交按钮是否会造成重复请求。
• 安全测试：密码传输是否加密；输入框是否防SQL注入和XSS攻击；登录失败日志是否记录；验证码是否有时效限制和错误次数限制。
• 兼容性测试：主流的操作系统（Windows、macOS、Linux）、浏览器（Chrome、Firefox、Edge）、移动端不同屏幕尺寸。

每个维度下面至少写3-5条具体用例，结构清晰、覆盖完整，阅卷人一眼就能看出你的测试思路。这里有个容易被忽略的细节：一定要突出“边界值”和“异常场景”，比如用户名长度刚好20位和21位、密码包含特殊字符、连续错误锁定前一次和后一次的状态，这些细节是区分普通考生和高手的分水岭。

如果遇到“电梯”“水杯”“椅子”这类开放对象，就用同样的框架往上套：功能（开关门、楼层选择、超载报警）、性能（满载运行速度、高峰时段调度效率）、安全（急停按钮、门防夹功能）、兼容（不同的楼层布局、不同型号的控制系统）、易用性（按钮标识是否清晰、语音提示是否友好）。框架在手，任何对象都能拆。

3.2 场景题：给你一个“新功能”，你怎么测

除了常规用例设计，360这套卷子还喜欢出场景题，题目形式一般是：“产品经理提了一个需求，实现了一个新功能，请你规划测试方案。”这种题考的不是具体的某条用例，而是你对测试流程的整体把控。

举个例子，题目可能会说：“360安全卫士新增了一个‘一键优化’的功能，请设计测试计划。”答题时不要一上来就写用例，要先写整体思路：

• 需求分析：明确功能的目标用户、使用场景、核心流程和异常流程。
• 测试范围：功能测试、性能测试、兼容性测试、安全测试、回归测试分别覆盖哪些内容。
• 测试环境：需要覆盖哪些操作系统版本（比如Win7、Win10、Win11 32位/64位）、是否需要虚拟机、是否需要不同配置的测试机。
• 测试数据和工具：准备哪些样本文件、使用什么工具做性能监控和抓包分析。
• 风险点和优先级：哪些模块改动大、风险高，需要优先测试和增加测试深度。
• 用例设计：再按第3.1节的结构层层展开。

这个答题逻辑适用于任何场景题。你要让阅卷人看到你脑子里装着一套完整的测试流程，而不是只会零散地写几条用例。

3.3 缺陷管理题：会写bug也是一种核心技能

简答题部分还经常出现缺陷管理相关的内容。常考的包括：bug的生命周期是什么、严重程度和优先级怎么区分、如何撰写一份高质量的bug报告。

bug的生命周期一般是：新建（New）→ 已指派（Assigned）→ 已修复（Fixed）→ 已验证（Verified）→ 已关闭（Closed），如果验证不通过，则重新打开（Reopen）。有些团队会多出“延迟修复”“重复提交”“无法复现”“设计如此”等状态，需要根据实际情况流转。

严重程度和优先级的区别是高频考点。严重程度（Severity）指缺陷对系统的影响程度，优先级（Priority）指缺陷需要被修复的紧迫程度。这两者不一定是正相关的：一个严重程度很低但影响用户主流程的界面问题，优先级可能很高；一个严重程度很高但发生在极其冷门场景中的问题，优先级可能很低。测试人员提交bug时要把这两个字段准确区分，不能混淆。

至于bug报告怎么写得让人看得懂，这里分享一个我常用的模板：标题要简洁明了，包含模块和问题现象，例如“登录模块：使用正确账号密码登录时，偶现页面无响应”；环境信息要注明操作系统、浏览器、版本号；复现步骤要按操作顺序写清楚，每一步之间用句号隔开，不要跳步；预期结果和实际结果要分开写，这是很多人最容易漏掉的部分；附件尽量附上截图、录屏、日志，证据越全，开发处理效率越高。

3.4 逻辑与智力题：思路比答案更值钱

这类题在笔试中经常以选择题或简答题出现，数量不多，但很容易卡住人。常见的题型有数字推理、图形推理、逻辑判断，也有部分数学题，比如概率、排列组合、天平称重等。

应对这类题，我的经验是不要在一道题上死磕超过5分钟。如果5分钟内没有思路，直接标记跳过，等整张卷子做完再回来慢慢想。因为逻辑题的分数占比通常不高，为了一道题牺牲后面的大题非常不划算。

如果简答题中出现推理题，比如“1000瓶药水中有一瓶有毒，用小白鼠测试，最少需要多少只小白鼠能在24小时内找出毒药”，答案是用二进制编码，因为1000小于2的10次方1024，所以最少需要10只。注意答题时一定要把推理过程写清楚，即使答案不完全正确，过程也会有分。

4. 易错点汇总与答题避坑指南

这些年我接触了不少参加测试笔试的同学，也帮朋友改过不少模拟卷，发现有些错误出现的频率非常高。整理成一张速查表，你们对照着自查。

再补一句经验之谈：笔试答题的时候，凡是简答题和设计题，尽量分条分段来写，不要用大段文字糊在一起。阅卷人一天要看几十份卷子，眼睛也累，结构清晰的答案本来就占优势。你写的每条用例之间留出空隙，重点词加粗或者用括号标注，这种小细节都能帮你多赚一点印象分。

5. 备考冲刺建议与拓展思路

5.1 三周复习计划

如果你现在离笔试还有三周到一个月的时间，可以按照下面这个节奏来安排。

第一周主攻基础理论：把测试基础、操作系统、网络协议、数据库四块内容过一遍，重点做选择题和简答题。每天抽出一小时做用例设计练习，不需要写完整用例，只要在纸上列出用例设计的框架和边界点就行。

第二周主攻刷题和编程：把Linux命令实际操作一遍，SQL题目每天做5道以上，编程题按照数组、指针、字符串、基础算法的顺序刷。这个阶段要刻意练习“手写代码”，不要依赖IDE的自动补全，因为笔试现场是纯手写。

第三周主攻模拟考和查漏补缺：找两套完整的测试笔试题，按照正式考试的时间限制做一遍，然后对照答案查找薄弱环节。错题要整理到错题本，重点看错因是概念不清、逻辑失误还是时间不够，针对性地补强。

5.2 日常积累比临考突击更重要

测试这个岗位有一个特点：平时怎么工作，笔试大概率就怎么答题。日常工作中如果养成了写用例前先列框架的习惯，笔试的用例设计题基本不用复习。如果平时定位bug只是直接丢给开发说“这里有bug”，笔试遇到缺陷管理题就会露怯。

所以我的建议是，不要把备考当成一个短期冲刺项目，而是当成日常工作的复盘和提炼。你每写一条用例，就想想它属于功能还是性能还是安全维度；每提交一个bug，就按模板检查信息是否完整。时间久了，这些东西会内化成你的一种本能反应，笔试自然就稳了。

5.3 拿到这套题之后还能延伸学什么

把2015年这套题吃透之后，我建议你再往前走一步：把安全测试的核心知识补起来。360毕竟是安全厂商，如果后续面试进了安全测试相关的团队，光会功能测试是不够的。最低限度要掌握OWASP Top 10中提到的web安全风险，尤其是SQL注入、XSS、CSRF、文件上传漏洞、越权访问这几种常见的。

还有一个方向是自动化测试。2015年的时候很多团队还在手工测试为主，但现在的测试岗位在笔试或面试中多少会问一点自动化知识，比如Selenium的原理、接口测试工具Postman的用法、持续集成的基本概念。不一定要求你精通，但至少不能一问三不知。

我在实际备考和带新人的过程中，最大的体会是：笔试题目本身并不是最大的拦路虎，最大的门槛在于“用测试的思维方式去思考问题”。很多同学一道题不会做，第一反应是“我没复习到”，但真正的短板是基础概念没串起来，知识之间是断层的。你把计算机基础和测试方法论打通了，再去看任何一家公司的笔试题，都会发现题目只是同一个知识体系的不同呈现方式。准备360这套题就像给自己的技术底子做一次全面体检——老题新做，反而能帮你把以前模糊的知识点查出来，一次补牢。