企业官网建设流程全解析

去年秋招的时候，我在招聘平台上一页页翻着校招岗位，突然看到“联想22校招-CNBU测试”这个标题。第一反应是愣了几秒：CNBU是什么？测试岗会不会比开发低人一等？说实话，当时我连点进去的勇气都不太够。后来一个在联想工作的学长跟我说，CNBU是联想中国区的一个业务群组，测试岗位在实际业务里的分量比你想象中大得多，而且大厂测试岗对校招生的技能要求很明确，只要准备方向对，是完全能拿到offer的。我后来不仅投了，还一路走完笔试、三面、HR面，最后顺利入职。现在回头看，这个选择比我想象中更适合起点普通、但愿意把测试当成一份正经职业来做的同学。

这篇文章我不会写那种“校招攻略大全”，只围绕“联想22校招-CNBU测试”这个具体岗位，把我从网申、笔试、面试到入职三个月的完整经历拆给你看。如果你正在纠结要不要投测试岗，或者已经投了但不知道怎么准备，这篇文章应该能帮你省下不少时间。

1. 我为什么锁定联想22校招的CNBU测试岗

1.1 CNBU到底是个什么业务单元

很多同学看到岗位名称里的缩写就懵了，我当时也一样。联想校招岗位里这种缩写特别多，IDG、ISG、SSG、CNBU各代表不同业务单元。我投递前专门研究了一下，CNBU一般对应联想中国区面向消费者市场的业务群组，核心是消费级智能设备以及配套的软件、服务和解决方案。测试岗位就是围绕这些业务线做质量保障，从手机App、PC端工具软件到后台服务接口，测试的对象跨度很大，不是外界以为的只测“电脑能不能开机”。

我后来在HR面的时候也追问了一句，得到的解释是：CNBU测试岗会根据部门具体需要安排到不同产品线，但做的事情都一样——保证功能符合需求、性能满足预期、兼容性覆盖主流机型，把问题在上线前拦截住。这也是我最终敢选它的原因：面宽，接触的业务链路长，对新人来说是好事情。

1.2 校招测试岗不是开发岗的退路，而是一条独立的职业路径

很多应届生对测试有刻板印象，觉得是“点点点”，是简历不够硬的人才去投的岗位。这个观念至少落后了五年。现在大厂测试岗拆分得很细，有功能测试、接口测试、自动化测试、性能测试、测试开发，薪资和开发差距并没有想象中那么大。联想这类公司对校招测试生的定位也不是“工具人”，而是带着质量意识参与整个研发流程的工程角色。

我当时选它更现实的原因是这个岗位相对竞争压力小一些。校招里开发岗动辄几百人投一个职位，测试岗虽然也在卷，但至少不会在简历阶段就被学历刷得那么狠。如果你学校背景普通，但专业基础扎实、项目能说清楚，测试岗是一个很值得切入大厂的入口。进去之后可以横向转测开、纵向转测试专家，路线并不窄。

1.3 从JD里拆出的三个关键信号

投简历之前，我特意把岗位描述里反复出现的关键词总结了一遍，大致是“熟悉软件测试流程”“掌握Python/Java中的一种”“了解Linux和数据库”“有项目或实习经验者优先”。翻译一下就是：

• 测试基础是底线，至少要知道用例设计、缺陷生命周期、测试报告怎么写；
• 编程能力是加分项，不要求你手写红黑树，但至少要能写出简单的自动化脚本；
• Linux和数据库是实操工具，因为在测试环境里查日志、造数据几乎每天都要用。

这个拆解在后来笔试和面试中全部应验。所以如果你也想投联想或者其他大厂的测试岗，别光背题，先把这三件事想清楚：测试理论会多少、代码能写到什么程度、有没有一个能拿得出手的小项目。

2. 网申到笔试：简历和刷题我踩过的那些坑

2.1 简历怎么写才能过初筛

我第一版简历犯了一个很多应届生都会犯的错——把课程成绩和校园活动写了一堆，真正和测试相关的内容却只有一行“熟悉软件测试理论”。这种简历投出去基本是石沉大海。后来我换了个思路，把简历当成“证据清单”来写：

• 技能部分，不写“精通”和“熟练”，改成“能够使用XX工具完成XX任务”，比如“能够使用Postman完成接口测试，能够使用pytest+Selenium编写Web自动化用例”；
• 项目部分，用STAR结构写，重点突出“我做了什么”“用了什么方法”“结果如何”，比如“独立设计并执行了xx模块的90条测试用例，发现并跟踪了12个有效bug”；
• 如果你有实习最好，没有实习的同学也不要空着，可以在Github上找开源项目，写一个小的自动化测试脚本集，也算可验证的项目经验。

我个人强烈建议在简历末尾附一个自己的Github或博客链接，不需要多厉害，哪怕只有几个测试脚本和学习笔记，面试官看到也会觉得你是有持续学习意识的。

2.2 笔试的题型分布与刷题策略

联想的校招笔试通常是在牛客网线上完成，岗位不同题型会有差别。我参加的这一场，整体印象是行测题+专业题+两道编程题相结合，时间比较紧张。

具体分布大概是：

我最开始只刷测试理论题，结果在操作系统和网络上栽了。后来重新调整策略：每天刷一套行测保持手感，把牛客网“测试岗专项练习”里的选择题全部过一遍，编程题就按LeetCode easy和部分medium来练。这里特别提醒一句，编程题不要只盯着“算法难不难”，更重要的是能在笔试环境里快速写出可运行的代码。我遇到的第一道编程题其实是“字符串去重并统计字符次数”，思路不难，但手生的人容易在输入输出处理上卡半天。

2.3 没有实习经历，怎么临时补一个能讲的测试项目

如果你投递时间比较早，还有一个月左右的准备窗口，我推荐自己做一个轻量级的测试项目。我当时的做法是：选了一个开源博客网站，用Python+pytest+Selenium给它写了一套自动化冒烟测试用例，覆盖登录、发表文章、删除文章、分页浏览这几个核心流程。

项目不需要大，但要把下面几个点都踩到：

• 用例设计要分层，至少要有正常流程、异常输入、边界条件三种；
• 元素定位优先用CSS或XPath，并处理页面加载的显示等待；
• 测试数据不要写死，用配置文件或数据驱动的方式管理；
• 最后用Allure生成一份测试报告，写下结果分析和后续优化点。

这套项目在面试时特别能打，因为面试官追问的每个细节我都有真实踩坑记忆。比如问“遇到元素点击不到怎么办”，我就会说可能是浮层遮挡，也可能是页面还在异步加载，解决思路是显式等待加上判断元素可点击状态。这种细节是背题背不来的。

3. CNBU测试岗面试复盘：一面二面HR面各在考什么

3.1 一面：技术基础与测试思维

联想的测试岗一面的面试官通常是团队里的技术骨干，全程大概40分钟，节奏比较快。开场就是自我介绍，我把重点放在“计算机相关背景+一个自动化项目+对测试的理解”上，没有啰嗦。

接下来问的内容可以分成三类：

第一类是测试理论。让我对“登录功能”设计测试用例。这类问题是最容易拉开差距的。我当时回答的结构是：先按测试维度拆分——功能测试看输入框的合法性、密码加密、记住密码、验证码；接口测试看提交参数校验、频率限制；安全性看SQL注入、暴力破解；兼容性看不同浏览器和移动端；性能看并发登录。

第二类是网络和数据库基本功。问了HTTP状态码中500、502、504的区别，我用“服务器自己崩了”“中间的网关找不到后端”“后端没在规定时间内返回”来解释，面试官点头认可。然后又让我写一条SQL，统计用户表里同一个邮箱出现两次以上的记录，用GROUP BY和HAVING就能解决。

第三类是Linux排查问题。问题是“线上服务挂了，你会怎么排查”。我的回答是先把服务状态和端口确认一遍，用top看负载，用tail查看最近日志，再做链路检查，最后看监控告警。这种问题不需要你有多深的运维经验，关键是体现出“有排查思路、不慌、有顺序”。

3.2 二面：业务理解与项目深度挖掘

二面的面试官级别更高，问的东西也更偏业务和工程落地。开头直接盯着我简历里的自动化测试项目问了十分钟：

• 为什么选Selenium而不是别的工具？
• 你的用例失败时怎么定位是脚本问题还是产品bug？
• 自动化用例跑一次要多久？多久运行一次？
• 如果页面元素被前端频繁改动，你的脚本怎么办？

这些问题其实没有一个标准答案，面试官想看的是你有没有真实写过代码而不是背概念。我当时回答“用例失败先看截图和日志，再看是等待时间不够还是元素定位失效；如果前端频繁改动，会推进前端团队在关键节点上补充稳定的data-testid属性”，这个回答比较真实，面试官也没有为难我。

后来还问了一道业务题：“如果让你测试联想电脑管家的软件管家模块，你会从哪些方向入手？”我没有提具体的系统设计，只从用户使用路径拆解：下载、安装、升级、卸载、异常中断、磁盘空间不足、网络中断。只要能站在用户角度把场景列全面，这道题就算过关。

3.3 HR面：稳定性、性格和期望薪资

HR面相对轻松，但不要掉以轻心。联想很看重候选人对岗位的稳定性，HR反复确认“你对测试岗的理解”“是否愿意长期做测试工作”“如果开发岗也给你offer，你会怎么选”。我的回答是强调自己认真研究过测试方向，认为质量保障是产品交付中不可替代的一环，短期规划是在测试领域深扎两三年，后续向测试开发发展。

还有一个容易被问到的点是“你最大的缺点是什么”。不要去说什么“我太追求完美”这种被用烂的答案。我当时说的是自己公开表达容易紧张，后来通过主动在项目例会上汇报来改善。HR觉得这个回答有自我认知也有行动方案，效果不错。

薪资谈判的话，校招基本是标准价，没有太多空间，但可以问清楚是否有加班补贴、班车、餐补、试用期薪资待遇，这些问题放在最后反问环节问就可以了。

3.4 现场被问倒的一道题：路由器怎么测

我必须坦白，二面里有一个问题问“家里的无线路由器你会怎么测试”，我当时脑子是空白的。因为平时对路由器认知就停留在“能上网就行”，从来没把路由器当成一个需要系统测试的产品。

冷静了几秒后，我强迫自己回答：先看它是硬件设备，所以外观、接口、指示灯、散热是硬件测试点；再看它是网络设备，所以基本功能包括无线连接、有线连接、DHCP分配、NAT转发；然后是管理后台和App，要测配置修改、重启、恢复出厂；还要考虑性能，比如多台设备同时接入、高负载和长时间运行的稳定性；最后是安全和兼容性，比如WPA2/WPA3加密、不同手机和电脑系统的适配。

这个回答其实已经被我补救得比较完整了。面试官后续点评时说，遇到没准备过的题目，不要慌，从“用户会用这个产品做什么”出发，一层层拆到具体测试点，比硬套方法框架更有说服力。这句话我记到现在。

4. 入职三个月，CNBU测试岗真正在做的事

4.1 从“会答题”到“会提Bug”：日常测试流程和产出物

入职后的前两周基本都是熟悉团队和产品，带我的导师给了一份“新人必读”：产品需求文档、原型图、技术架构说明、以往的测试用例和缺陷报告。我把这些当成教材来啃，很快就发现学校学的测试流程和实际工作是有很大差别的——真实项目没有“标准答案”，你面对的是一个一直在变化的需求和永远不够用的测试时间。

团队日常节奏大概是这样的：

• 每天上午有十五分钟晨会，同步当前需求进度和风险；
• 拿到新版本后先在测试环境做一轮冒烟测试，冒烟不通过就直接打回开发，不进入正式测试；
• 正式测试阶段按测试用例执行，发现bug就提缺陷单，严重等级从A到D四级划分；
• 版本提测后在Jira上做缺陷跟踪，开发修复后重新执行回归测试；
• 上线前还要走一轮重点功能回归，确认没有引入新问题。

刚开始我最不适应的是提bug的表述方式。学生时代说自己发现问题很随意，但在公司里，一个合格的缺陷单要写清楚前置条件、复现步骤、实际结果、期望结果，还要附上日志、截图和机型信息。如果复现率不是100%，还要说明大概出现的频率。这些细节直接影响开发的排查效率，也决定你是不是一个靠谱的测试。

4.2 第一次独立负责模块：从用例设计到上线的完整链路

我入职第三个月，导师让我独立负责一个PC端工具软件的设置模块测试。这个模块不算大，但涉及本地配置、云同步、权限管理等多个功能点，足够我完整走一遍流程。

我当时的做法是分为四步：

第一步，把需求文档从头到尾读了三遍，画出业务流程图，把每个功能的正常路径和异常路径都列出来。有些边界条件需求文档里根本没写，比如“配置缓存达到上限怎么办”，这些需要靠和开发确认或结合历史版本的行为来判断。

第二步，整理测试用例，用Xmind做了功能脑图，然后逐条写成Excel用例，包含用例编号、前置条件、测试步骤、预期结果、优先级。整个模块下来大约110条用例，中等优先级以上的约占七成。

第三步，执行测试并跟踪缺陷。我执行了三天，发现了大概十几个问题，其中有一个“云同步后本地设置被重置”的严重bug，定位到是和另一个模块共用配置文件的键名冲突。为了确认影响范围，我专门找了开发一起看日志，最后确认是同步逻辑的初始化顺序问题。

第四步，上线前的回归。因为安排比较合理，上线当天没有出现紧急问题，导师在周会上点名夸了一句，当时成就感还是很大的。

4.3 测试环境、测试数据与回归策略：新手最容易忽略的细节

学校做项目不用考虑环境问题，公司里“环境”才是最大的坑。我们团队测试环境不止一套，有日常测试环境和预发布环境，数据也和正式环境隔离。我第一次独立测试时，在测试环境里造了一批订单数据，结果发现不同环境的Mock策略不一样，导致一个支付回调一直收不到。后来学会了很多工作流数据不能自己乱造，要复用线上脱敏数据或通过接口造数工具生成。

回归策略则是另一个学问。新版本推出后，不一定要把全部用例都执行一遍，通常按照风险等级选择：冒烟用例覆盖主流程，定向回归覆盖本次改动涉及的功能，全量回归一般放在大版本或重要模块改动后。如果不知道某个改动的影响面，就用代码仓库的Diff记录来判断改了哪些模块，再去找对应的旧用例。这个思路我在面试时其实答过，但真正落地才发现没那么简单，因为涉及多个团队的改动交织在一起，回归范围经常需要靠业务判断。

5. 给下一届投递者的工具箱与提醒

5.1 我重新整理后的工具与学习路线

如果现在有人问我，想投联想22校招CNBU测试这类岗位，应该先学什么，我会给出一个“够用就好”的工具箱：

学习路线上，我建议不要一上来就啃自动化，先把功能测试的“手感”练出来。理解什么是好的用例、什么是完整的缺陷、什么是清晰的测试报告，再往上走自动化会事半功倍。书的话，《软件测试的艺术》适合建立基本认知，《Web接口开发与自动化测试—基于Python语言》适合边看边写代码，后者里面的代码虽然老一点，但核心思路不过时。

5.2 面试表达：三个“先说结论”的答法

我自己在面试中总结出一个好用的表达套路，遇到任何追问都用“先说结论—再给理由—最后说例子”的结构。举一个例子：

面试官问：如果开发说这个改动影响很小，不需要测试，你怎么办？

很多人会直接回答“跟开发争论”，或者“按流程测试”。但用上述结构就能答得更好：

• 先说结论：我会基于改动影响面来判断，如果影响到核心流程，我会坚持测试；
• 再给理由：开发说的“很小”通常是从代码改动量角度判断，而测试还要考虑用户场景和上下游依赖，代码没改不代表行为不变；
• 最后举例：比如之前一个同学遇到的bug，只是改了一个配置文件，结果上线后把整个模块的兼容性搞坏了。

这样回答既展示你有判断力，也有沟通策略，面试官通常都会觉得你是真的思考过这个问题。

5.3 什么样的人适合来这个岗位

最后说点得罪人的大实话。测试岗不是“不行才去”的通道，但它确实更适合那些人：细心且有耐心，能在一堆信息中找到异常；沟通能力在线，能和开发、产品用事实说话而不是情绪说话；有好奇心，遇到bug想追根因，而不是顺手滑过去；也有工程意识，愿意用脚本和工具把重复劳动自动化掉。

如果你确认自己符合其中两三点，那完全可以投。大厂测试岗的成长环境真的不差，尤其是CNBU这种业务类型，各种智能设备和服务端的质量实验都在身边，你每天接触的是真实用户场景，学到的东西非常落地。我在入职三个月后最大的感觉就是：测试并不是机械地点按钮，而是通过质量视角不断去推动产品变好，这种感觉是单看代码库体会不到的。

最后单独再分享一个小建议：不管投哪个岗位，拿到offer不是终点，拿到之后更要主动了解团队用的工具链和测试体系。你可以在面试反问环节直接问“团队目前自动化覆盖率是多少”“用什么框架做接口测试”“测试环境是怎么管理的”，这些问题既能让面试官觉得你专业，也会帮你在几个offer之间做出更准确的选择。

如果你也看到了“联想22校招-CNBU测试”这个标题，别犹豫，认真准备一轮，值得试。