企业官网建设流程全解析

每年秋招季，总有朋友问我软件测试岗的笔试题到底该怎么准备。说实话，很多人把精力都堆在刷编程题上，结果一进考场发现测试理论、用例设计占了半张卷子，直接懵了。今天拿格力2020秋招软件测试岗的笔试题做个拆解，这套题我前前后后研究过好几遍，也带着几届学弟学妹复盘过，覆盖面很典型——计算机基础、测试理论、场景设计、编程能力全都有，很能反映传统制造企业在智能化转型中对测试人才的真实要求。

这篇内容适合三类人看：正在准备秋招的应届生、从开发或运维想转测试的从业者，以及想了解家电行业测试岗到底考什么的在校生。我会把整张卷子的考点、答题思路、容易踩的坑全部讲透，你照着这个思路去准备，比盲目刷一百道力扣有用得多。

1. 整卷结构与考点布局，先搞清楚格力想招什么样的人

1.1 卷面组成与时间分配

格力2020秋招软件测试岗的笔试，整体分成五个模块：选择题、判断题、简答题、用例设计题、编程与SQL题。考试时间大概90到120分钟，题量中等偏大，但真正难的不是题目本身，而是时间分配。

我统计过近三年好几家制造业大厂软件测试岗的笔试题，发现一个共性规律：纯测试理论的题约占30%到40%，计算机基础知识约占20%到30%，用例设计和场景题占20%左右，剩下的才是编程和SQL。很多同学看到编程题就兴奋，上来先花40分钟死磕一道算法题，结果后面用例设计题、简答题只写了两行字。这就是典型的战略失误。

正确的策略是：先花3分钟把整张卷子扫一遍，对每道题的分值和难度做个快速判断，然后按“先易后难、先拿分后攻坚”的顺序答题。选择题和判断题是性价比最高的，基本30秒到1分钟就该解决一道，不会的果断标记跳过，千万别恋战。简答题控制在每题5到8分钟，用例设计题15到20分钟，编程题如果卡了超过20分钟就直接放弃，把时间留给后面的题目。

1.2 从考点反推企业用人标准

格力的笔试题，能明显看出这家企业对软件测试工程师的定位。它不像互联网大厂那样追求算法深度的极致，而是更看重三样东西：第一，扎实的计算机基础，因为智能家电产品涉及网络通信、嵌入式、数据库多方面的技术栈，测试人员如果不懂底层原理，出了问题很难定位；第二，严谨的测试思维，制造业产品对稳定性要求极高，空调、冰箱这类设备一旦出bug，影响是直接面向终端用户的，所以测试用例设计能力是重点考察对象；第三，实际问题解决能力，卷子里有大量贴近业务场景的题目，比如设备联网超时、App控制指令丢失这类问题，考察的就是你面对真实产品时能不能快速理清思路。

所以如果你打算投这类企业的测试岗，复习重心一定要放在“基础+实践”两条线上，光会写代码不行，光会背测试理论也不够，两者得结合起来。

2. 客观题高频考点逐个击破，这些分千万不能丢

2.1 计算机网络与操作系统基础

客观题里计算机网络的出镜率极高，格力这套卷子里就有几道典型的，比如TCP三次握手的过程、HTTP和HTTPS的区别、TCP与UDP的适用场景。这些知识点本身不难，但出题人喜欢换着花样考，比如问你“TCP建立连接为什么需要三次握手而不是两次”，如果你只会背“因为要确认双方的收发能力”，就容易被追问细节。

我建议你把这个问题的完整逻辑理清楚：第一次握手，客户端发送SYN，服务端确认客户端发送能力正常；第二次握手，服务端发送SYN+ACK，客户端确认服务端收发能力正常；第三次握手，客户端发送ACK，服务端确认客户端接收能力正常。核心目的是防止失效的连接请求突然传到服务端，导致资源浪费。

操作系统这块，进程与线程的区别是必考项。记住几个关键维度：进程是资源分配的最小单位，线程是CPU调度的最小单位；进程之间相互独立，同一进程的线程共享内存和资源；进程的创建和销毁开销大，线程则轻量得多。还有死锁产生的四个必要条件——互斥、持有并等待、不可剥夺、循环等待，这个经常以判断或选择题形式出现。

2.2 数据库与SQL核心必考点

数据库知识在软件测试岗笔试里的地位，可能比你想象中高得多。因为测试过程中经常需要造数据、查数据、验证数据一致性，SQL写得不熟，工作效率会大打折扣。

格力的卷子里，数据库相关的考点主要集中在这几块：SQL查询语句的基本语法（select、where、group by、having、order by）、多表连接查询（inner join、left join、right join）、聚合函数（count、sum、avg、max、min）、事务的ACID特性。有个高频易错点是where和having的区别，简单记：where是在分组前对记录进行过滤，不能使用聚合函数；having是在分组后对分组结果进行过滤，可以搭配聚合函数使用。

再强调一下索引相关的概念。面试官和笔试题都爱考“索引为什么能提高查询性能”“什么情况下索引会失效”。底层原理是B+树结构，通过减少磁盘IO次数来加速查找。常见的索引失效场景包括：对索引列使用函数或表达式计算、隐式类型转换、like查询以通配符开头、联合索引未遵循最左前缀原则。这些点笔试中不一定直接考，但面试环节基本必问。

2.3 数据结构与算法选择题解析

软件测试岗的笔试虽然编程题难度不如开发岗，但数据结构和算法的基础知识还是得过关。格力这套题里出现的选择题，主要集中在数组、链表、栈、队列、二叉树这些常见结构。

举例来说，数组和链表的区别是经典中的经典：数组在内存中是连续存储的，随机访问时间复杂度O(1)，但插入和删除需要移动元素，时间复杂度O(n)；链表在内存中是非连续存储的，通过指针连接，随机访问需要遍历，时间复杂度O(n)，但插入和删除只需要修改指针。还有一个容易记混的点是栈和队列，牢记“栈是后进先出，队列是先进先出”即可。

二叉树这块，需要掌握前序、中序、后序遍历的顺序，以及根据遍历结果还原二叉树的思路。有一个技巧：给定中序+前序，或中序+后序，可以唯一确定一棵二叉树，但如果只给前序和后序，则无法唯一确定。这个知识点选择题里偶尔会拐个弯考你，提前记好能省不少时间。

3. 测试用例设计题，这才是整张卷子的核心分水岭

3.1 登录功能用例设计，最经典也最考验功力

用例设计题在格力笔试题里占的权重很大，而且基本是必考。出题方式通常是给你一个功能模块，比如登录、注册、购物车、文件上传，让你设计测试用例。很多人觉得这有什么难的，不就是写几个正常流程和异常流程吗？但真正写起来，高下立判。

以登录功能为例，我给你一套完整的思考框架。第一步，功能测试。正常输入正确的用户名和密码，验证能否成功登录；用户名正确、密码错误，提示信息是否准确；用户名不存在、密码为空、用户名和密码都为空，每个场景都要覆盖。第二步，等价类划分。将输入数据划分为有效等价类和无效等价类，比如用户名的有效等价类是符合长度和字符要求的输入，无效等价类是空、超长、包含特殊字符。第三步，边界值分析。密码长度限制如果是最小6位最大20位，那么5位、6位、7位、19位、20位、21位都要测一遍，因为边界处最容易出现bug。第四步，安全性和兼容性测试。密码是否加密传输，验证码是否有时效性，连续多次输入错误是否触发锁定，在不同浏览器（Chrome、Firefox、Safari）和不同分辨率下页面显示是否正常。第五步，性能方面，可以补充大量用户同时登录时的系统响应时间。

这套思路看起来不复杂，但真正能完整写出来的人很少。绝大多数人写个七八条就停了，而且只关注正常流程，异常场景覆盖不全。我改过不少简历和笔试试卷，得分高的用例设计题，普遍具备三个特点：覆盖了等价类和边界值方法、有明确的预期结果、考虑了安全性和兼容性等非功能维度。

3.2 场景法设计思路，别漏了用户的实际使用路径

除了登录这种基础功能，制造业企业的软件测试题还喜欢考一件完整的事情，比如“用户通过App把空调设为26度并定时两小时后关闭”这个全流程，让你设计测试场景。这种题考察的是场景法的运用能力，核心思想是把用户的实际操作路径串联起来，覆盖主事件流和备选事件流。

主事件流就是最顺畅的那条路径：打开App、连接空调、设置温度、设置定时、确认提交、设备反馈成功。备选事件流包括：App与空调连接超时、设备不在线、温度设置超出允许范围（比如低于16度或高于30度）、定时时间非法、指令下发后设备无响应、操作过程中断网。每一个事件流都要写清楚前置条件、操作步骤、预期结果。

这里有个常见误区：很多人只写功能层面的场景，不考虑状态同步、异常恢复等场景。比如空调收到指令后执行成功，但App端没有刷新状态，用户看到的一直是旧温度；再比如用户在空调运行中修改了定时，系统是覆盖还是叠加？这些都属于高价值用例，写出来会明显拉高你的得分。

3.3 用例设计的书写规范，格式就是你的门面

用例设计题除了内容要完整，书写格式也很重要。规范格式一般包含：用例编号、所属模块、用例标题、前置条件、测试步骤、测试数据、预期结果、实际结果、优先级。笔试时间有限，不用每项都写，但至少要把用例编号、步骤、预期结果这三项写清楚。

我见过不少卷子，用例写得像流水账，一条用例里塞了五六个测试步骤和多种数据组合，这在用例设计里是大忌。正确做法是一条用例只验证一个独立场景，逻辑越单一越好。比如“输入正确的用户名和密码点击登录验证跳转成功”是一条用例，“输入正确的用户名和错误的密码点击登录验证错误提示”是另一条用例，不要混在一起。

优先级也要做个标注。P0级是核心功能，比如用户无法登录就是阻断性缺陷；P1级是重要功能，影响用户使用体验但不阻断；P2级是次要功能，比如某个按钮的样式不符合规范。这样写的好处是，阅卷人一眼就能看出你有没有完整的测试思维。

4. SQL与编程题实战，代码题拿分的关键技巧

4.1 典型SQL题目与多表查询的解题思路

格力这套笔试题里的SQL题不算难，但很典型。有一道是：给定学生表（student）、课程表（course）、成绩表（score），查询每门课程的平均分并按平均分降序排列。这道题考的就是分组聚合和排序，标准答案写法如下：

SELECT course_id, AVG(score) AS avg_score FROM score GROUP BY course_id ORDER BY avg_score DESC;

还有一道常见的是查询选修了特定课程的学生信息，需要用到多表连接。这类题的核心是先理清表与表之间的关联字段，再决定用哪种连接方式。记住一个关键点：inner join 只返回两边匹配上的记录；left join 返回左表全部记录，右表没有匹配就显示NULL。笔试中如果要求“列出所有学生的信息，包括没有选课的学生”，那就必须用left join，用inner join会把没选课的学生丢掉。

另外提醒一句，SQL题阅卷时很看重关键字书写规范，SELECT、FORM、GROUP BY、ORDER BY这些建议大写，不仅美观，而且能减少笔误。笔试如果是线上环境，写完一定要在脑子里过一遍执行逻辑，尤其是group by 后面的字段和select后面的字段是否对应，少了group by却用了聚合函数，这种低级错误一旦出现直接扣分。

4.2 编程题高频类型：字符串处理、数组、排序

软件测试岗的编程题，考察重点是代码基本功和逻辑思维，不会出特别偏难怪的算法题。格力这套卷子里，有字符串反转、数组去重、冒泡排序这类基础题，也有一个链表相关的题目。

以字符串反转为例，有多种实现思路，笔试里最稳妥的是用双指针：

public String reverseString(String s) { char[] chars = s.toCharArray(); int left = 0, right = chars.length - 1; while (left < right) { char temp = chars[left]; chars[left] = chars[right]; chars[right] = temp; left++; right--; } return new String(chars); }

这道题考察的不是算法本身，而是你是不是真的理解了字符数组和字符串的底层关系，以及有没有基本的代码规范意识。另外，数组去重也经常考，最简单的方案是利用HashSet的不重复特性，但更好的做法是使用双指针或位运算，能够在O(n)时间复杂度和O(1)空间复杂度下完成。

编程题得分的关键，不在于你用多高级的解法，而在于：代码能不能运行、逻辑是否清晰、边界情况是否考虑到位。我阅卷时经常看到有人写快排，但递归边界条件写错，导致数组越界，这种还不如老老实实写冒泡排序拿满分。

4.3 编程题常见错误与调试思路

笔试编程题里，有几类错误非常高频，提前预防就能拿到大部分分数。第一类是索引越界，尤其是处理数组或字符串的循环条件，很多人写循环边界时少了等号，或者多移了一位。写完后用最小用例自测一遍，比如数组长度为0、长度为1、长度为2这三种情况，跑通了基本就稳了。

第二类是空指针，对象没有判空就直接调方法。在测试岗笔试里，代码的健壮性是加分项，哪怕是标准解法，也应该带上判空逻辑。第三类是返回值类型不匹配，题目要求返回int[]，你返回了List ，这种错误看起来低级，但在紧张状态下很容易犯。

一个小建议：答题前一定先花30秒把题目完整读两遍，圈出输入范围、输出格式、时间和空间复杂度要求。很多同学匆匆扫一眼就开写，写完才发现理解偏差，一改就是20分钟，得不偿失。

5. 场景题与综合素质考察，这些开放题没有标准答案但要答出逻辑

5.1 缺陷生命周期与Bug管理流程

格力的卷子里还有一类题，不属于专业知识，而是考察你的工程实践认知。比如“简述一个Bug从发现到关闭的完整生命周期”，或者“测试过程中发现开发不认为这是bug，你怎么办”。这类题没有绝对标准答案，但答得好不好，完全能看出你有没有真实项目经验。

Bug的完整生命周期一般是：发现bug、提交缺陷报告、开发确认、修复、回归测试、关闭。中间会有多种状态流转，比如“待确认”“已拒绝”“重新打开”“延迟修复”。这里有个容易忽视的细节：bug被开发拒绝后，测试人员不是直接妥协，而是要先复现、补充日志和截图，再和开发沟通。如果确实是缺陷而开发坚持不改，那就需要上报测试负责人或产品经理来决策。

第二道题考察的是沟通能力和原则性。比较好的答题思路是：先表明自己的立场，缺陷是否修复最终依据项目标准和用户影响来判断；然后讲具体的操作步骤，包括复现缺陷、提供完整的证据链、进行风险评估、拉上相关角色开会讨论；最后强调测试的底线，如果缺陷影响用户体验或数据安全，就应该坚持修复。这种开放题，切忌只回答“我会听开发的”，或者“我坚决不改”，都显得极端且不专业。

5.2 测试计划与测试策略的编写思路

有些笔试题会出得更宏观，比如“给你一个智能空调App项目，测试周期只有两周，你怎么安排测试计划”。这道题看着难，其实考察的是测试策略和优先级判断能力。

回答框架可以这样搭：首先明确测试范围和测试目标，比如核心功能（设备配网、温度控制、模式切换）必须全部覆盖，非核心功能（个人中心、消息推送）可以做冒烟测试；其次确定测试环境，包括不同型号的空调设备、Android和iOS系统、2.4G和5G网络环境；然后规划测试进度，第一周完成功能测试和接口测试，第二周前半段做兼容性和性能测试，最后两天做回归测试和验收测试；最后明确风险点，比如设备不足、某些场景无法在实验室复现，需要提前和硬件团队沟通。

这个框架的核心是“先保证核心功能的质量，再兼顾非核心功能的覆盖”。答题时你还可以补充一句：“在资源有限的情况下，我会用风险驱动的方式安排测试优先级，把高风险模块放在前面测。”这句话一说出来，阅卷人就知道你懂测试管理的底层逻辑。

5.3 开放性场景题的高分答题模型

综合场景题在整张卷子里通常占10到15分，虽然分数不算多，但它往往是区分“背题党”和“有实战思维的人”的关键。我总结了一个适用性极强的答题模型：场景理解、问题拆解、方案设计、异常补充、优先级排序。

先说场景理解。不管题目描述多复杂，第一步先复述题目的关键信息，确认自己没有理解偏。然后是问题拆解，把一个大问题拆成几个独立的子问题，比如“App无法控制空调”可以拆成“App端问题”“网络问题”“设备端问题”“云端问题”四个方向。再往下是方案设计，针对每个子问题给出对应的测试方案或排查思路。异常补充就是多想想特殊场景，比如断网、断电、设备离线、并发操作。最后是优先级排序，明确哪个方案先做，哪个可以放一放。

这套模型在我看来是所有开放题的通解，不管是测试题还是面试题，只要照着这个顺序答，逻辑链条就是完整的，内容也不会散。

6. 笔试之后的面试衔接，怎么把卷子上的内容变成谈资

6.1 从笔试复盘反推面试准备方向

笔试结束不等于万事大吉，恰恰相反，笔试才是面试准备的最佳素材。我强烈建议你考完当天就做一次复盘，把不会的题、犹豫的题、答错的题都整理出来，因为这些地方大概率会出现在面试官的追问里。

比如你在笔试题里TCP三次握手答得不好，面试环节面试官很可能问TCP相关的追问，如果你提前复盘过，就能接住这个话题。再比如测试用例设计题你写得很完整，面试官可能会说“你刚才这个登录用例设计得不错，那我问你，如果这个登录接口有验证码，你的用例怎么改动”。这种追问都是基于你的笔试答案展开的，所以复盘越充分，面试越从容。

我的一个习惯是准备一个“笔试错题本”，按知识点分类记录，比如计算机网络、数据库、测试理论、算法，每道题标注错因和正确答案。面试前翻一遍，比自己无头绪地刷面经有效得多。

6.2 软件测试岗面试高频追问方向

笔试之后的面试，节奏一般会更快，问题更聚焦。根据我自己参加校招和后来面试别人的经验，软件测试岗的面试追问大致集中在这些方向：测试理论基础，比如黑盒测试和白盒测试的区别、常见的黑盒测试方法；项目经历，比如你简历里写的测试项目，是怎么设计用例的、发现了哪些有价值的bug；技术深度，比如接口自动化怎么做、性能测试关注哪些指标；以及综合素质，比如遇到需求频繁变更怎么办、和开发有分歧怎么解决。

其中项目经历是重头戏。面试官最想听到的不是你“参与了XX项目”，而是你在项目里具体负责了什么、怎么用测试方法论指导实践、产出了什么结果。比如你说自己做过一个电商系统的测试，那就要准备好回答“购物车模块你是怎么设计用例的”“并发下单的压测你是怎么做的”“发现的最有价值的bug是什么”。这些问题的素材，其实在你准备笔试题的时候就可以同步积累，把每个项目按模块梳理成“功能点+测试方法+典型bug”的形式，面试时直接调用。

6.3 秋招软件测试岗的准备路线建议

如果你是2020年之后参加秋招的同学，按目前行业的情况看，软件测试岗的竞争其实越来越激烈，但机会依然很多。关键是你得有体系化地准备，而不是零散地刷题。

我建议把准备周期分成三个阶段。第一阶段是打基础，用时两到三周，把计算机基础（计算机网络、操作系统、数据库）过一遍，重点学习常见的面试考点，同时每天刷10道SQL题和5道简单编程题。第二阶段是测试专业深耕，用时两到三周，系统学习测试理论、用例设计方法、缺陷管理流程，并且至少要完整做过两个测试实战项目，哪怕是自己搭一个简单Web系统来测，也比空谈理论强。第三阶段是模拟冲刺，用时一到两周，做历年真题、参加模拟笔试、找人做模拟面试，针对薄弱点查漏补缺。

这期间还有一个很重要的事情：关注岗位要求和笔试形式的变化。格力这类制造企业的智能化产品线越来越多，对软件测试的要求也在动态调整，比如物联网设备测试、嵌入式软件测试，这些都是加分方向。你如果提前了解这些赛道的基本知识，笔面试中会更有优势。

7. 写在最后，关于这道笔试题的一些个人体会

这套格力2020秋招软件测试岗笔试题，我之所以反复推荐给准备测试岗的同学，是因为它的考察面非常均衡，既有基础理论，又有实践设计，还有业务场景。相比那些纯考算法的大厂笔试题，这种风格其实更贴近软件测试岗位的真实工作内容——测试工程师不需要你写出多么精巧的算法，但需要你具备严谨的逻辑、完整的思维和解决问题的能力。

我自己在带新人时经常说一句话：软件测试岗的笔试，筛掉的从来不是不会写代码的人，而是思维不严谨、做事没章法的人。一套用例设计题，就能看出你是想一步到位写出完美方案，还是先把场景拆清楚再逐个击破；一道bug定位题，就能看出你是凭感觉瞎猜，还是按“客户端、网络、服务端、设备端”的层次逐层排查。这些能力不是刷题刷出来的，而是在一次次实战和复盘中沉淀出来的。

所以我的建议是：以这套题为基础，认真做一遍、复盘一遍、扩展一遍，把它当成你软件测试求职路上的第一块垫脚石。后续不管是做测试项目、准备面试还是进入工作岗位，这套思维方法都会一直跟着你走。