小米校招测试开发笔试题二全解析：从用例设计到移动端专项

每年到这个时间点，准备校招的同学都开始疯狂刷题了。测试开发这个岗位很有意思，很多人以为它只是“点点点”，结果一看笔试题才发现，既要写代码又要懂网络，还要会设计用例，甚至还要懂点移动端专项测试。小米2020校招这套测试开发笔试题二，我当年准备时认真研究过，后来带新人做训练也经常拿它当模板。这套题覆盖的知识面比较综合，难度属于大厂校招中偏实用的那种——不会故意出偏题怪题，但扎实的基本功和测试思维缺一不可。这篇文章把整套题的考察逻辑、各题型涉及的考点、解题思路和笔试时的经验技巧完整盘一遍。无论你是正在准备校招，还是想转行做测试开发，参考价值都很大。

1. 测试开发笔试的整体考察逻辑：这套题到底想筛什么样的人

先聊一个很多人会忽略的问题：小米作为手机厂商，它招测试开发工程师，和纯互联网公司有什么不一样？这一点直接决定了笔试的出题倾向。小米的业务覆盖手机、智能硬件、MIUI系统、互联网服务，这意味着测试开发要面对的不仅是App和Web，还有系统底层、硬件交互、多设备兼容等场景。所以你会看到，小米的测试开发笔试题里，移动端相关知识的比重通常比一般公司要高，而且更倾向于考察“能不能用测试的视角去理解一个具体的功能”。

从命题角度来看，测试开发笔试一般分几块：计算机基础知识、测试用例设计、编程题、逻辑与场景题。这套笔试题二也是这个结构，但有几个值得注意的信号。

第一，编程题的难度不会太高，但非常看重代码规范和边界处理能力。测试开发平时要写脚本、开发测试工具、搭自动化框架，对代码能力的要求偏向“能干活”而不是“算法竞赛选手”。所以如果你在刷题时只盯hard难度的LeetCode，反而可能跑偏了方向。

第二，测试用例设计题一定会出现在卷子里。这是测试岗和其他技术岗最大的区别。能否根据需求拆出完整的用例覆盖点，直接体现你有没有测试思维。很多同学代码写得不错，但一遇到“给某个功能设计测试用例”就懵，这就是赤裸裸地暴露了对测试工作的理解深度。

第三，计算机基础考得非常务实，不会上来就让你默写红黑树或者TCP拥塞控制的复杂公式，但会把基础概念和实际测试场景结合起来。比如给你一个App页面打不开的问题，让你分析是网络层、服务器还是客户端的问题，这种题目考察的是“用基础理论解决实际问题的能力”，比单纯背概念高一个层次。

我建议准备这套题时，不要按“知识点”去死记硬背，而是按“测试场景”去串联知识。比如HTTP你不仅要记住状态码含义，还要能说清楚接口测试中遇到502、504分别怎么排查；TCP三次握手你不仅要会画图，还要能解释弱网状态下握手失败对移动端测试的影响。这套题的导向很明确：知识落在场景里才是有效的。

2. 测试用例设计题的高频考法与解题框架

测试用例设计题基本上是必考题，而且分值不低。这套笔试题二里出现的用例设计题，考察重点集中在几个经典类型：功能模块用例设计、异常场景覆盖、兼容性场景分析。我拿一个典型的真题模式来拆——给一个具体的功能点，要求写出完整的测试用例。

比如说，题目让你针对“小米应用商店的搜索功能”设计测试用例。这时候如果你直接开始列用例，十有八九会漏掉关键点，而且逻辑会乱。正确的做法是先搭建一个测试用例设计框架，然后在框架里逐层展开。

第一层是功能测试。搜索框最基础的功能是“输入关键词-点击搜索-展示结果”，这个主流程的用例要覆盖以下分支：

• 搜索关键词的匹配模式：精确匹配、模糊匹配、大小写不敏感、中文/英文/数字/特殊字符
• 搜索结果的排序逻辑：默认排序、按下载量、按评分、按更新时间
• 搜索历史记录：是否记录、点击历史能否搜索、清空历史
• 候选词联想：输入时是否有联想词、点击联想词的行为
• 空态场景：搜索无结果时的页面展示、搜索关键词为空白时的提示

第二层是边界和异常测试。这是测试用例设计的加分项，也是很多没经验的人最容易遗漏的部分：

• 搜索关键词的最大长度限制、超长输入是否被截断或报错
• 搜索关键词为纯空格、空格加关键词、前后带空格
• 网络异常的提示：断网、弱网、超时分别展示什么
• 服务器异常的兜底：接口返回500时页面是否有错误提示，而不是白屏
• 快速连续搜索：用户连续点击搜索按钮，是否有防抖或取消上一次请求

第三层是兼容性与体验测试，这一层很贴合小米的场景：

• 不同机型适配：全面屏、不同分辨率下搜索页布局是否正常
• 不同MIUI版本的表现
• 深浅色模式下页面显示是否正常
• 搜索过程中来电话、退到后台再回来，页面状态是否正常
• 搜索结果的加载方式：分页加载、上拉加载更多、加载失败重试

你看，按照功能→边界异常→兼容体验这样分层去设计用例，逻辑就非常清晰。而且这个框架不光能用于笔试，实际工作中画测试用例、写测试计划，也是同样的思路。

关于用例设计这块，我再多说几句经验。很多人设计用例时喜欢追求“多”，觉得写满一页纸就赢了。但面试官和阅卷人真正看重的是用例的覆盖率和有效性——你写的每一条用例都得能落地执行，每一条都有明确的预期结果，而且不能有大量的冗余用例。写用例之前先在草稿纸上画出功能模块的数据流和状态流转，再动手写每条用例，这样思路会清晰很多。另外，边界值分析和等价类划分这两个方法一定要熟，因为几乎所有功能测试用例都能用上。比如搜索关键词的空串、超长串、特殊字符，就是典型的边界值场景，这些用例写上去，一眼就能看出你有测试方法的底子。

3. 编程题实战解析：思路、代码与测试思维

编程题是这套笔试题二里区分度比较高的一部分。前面说了，测试开发的编程题不会太偏向算法竞赛，更看重基础数据结构和字符串、数组处理能力。但有一个容易被忽略的点：编程题的阅卷不仅看你的代码能不能跑通，还会看你的代码能不能体现“测试思维”——你写的代码边界情况处理得好不好，防御性编程做没做到位，这本身就是一道隐形的测试题。

我拿一道当年很有代表性的真题来说：实现一个函数，判断一个字符串是否是合法的IP地址（IPv4）。这道题目看起来简单，但它把字符串处理、边界判断、逻辑完整性全都考进去了。

先理清判断规则：

• IPv4地址由4段组成，段与段之间用点分隔
• 每段是0-255之间的整数
• 每段不能有前导零（除非该段本身就是0）
• 每段不能为空，不能包含非数字字符

这里最容易写漏的是“前导零问题”和“非数字字符问题”。很多人用split('.')切分之后，直接用Integer.parseInt转成int去判断范围，这样会漏掉“01.2.3.4”这种非法情况，因为parseInt("01")结果是1，程序会误判成合法地址。这时候如果你有测试思维，你就会在写完主逻辑之后，潜意识里列出几组测试用例去自测代码——这正是面试官想看到的。

给一个带着自测用例的参考实现：

def is_valid_ipv4(ip: str) -> bool: # 前置校验：为空直接返回False if not ip: return False parts = ip.split('.') # 必须是4段 if len(parts) != 4: return False for part in parts: # 每段必须非空，且只包含数字 if not part or not part.isdigit(): return False # 前导零检查：长度大于1时，首位不能是0 if len(part) > 1 and part[0] == '0': return False # 范围检查 if not (0 <= int(part) <= 255): return False return True # 自测用例 test_cases = [ ("192.168.1.1", True), ("0.0.0.0", True), ("255.255.255.255", True), ("256.1.1.1", False), ("01.2.3.4", False), ("1.2.3", False), ("1.2.3.4.5", False), ("a.b.c.d", False), ("", False), (" 1.2.3.4", False), ] for ip, expected in test_cases: result = is_valid_ipv4(ip) status = "PASS" if result == expected else "FAIL" print(f"{status} | {ip!r} -> {result}")

从这道题的实现中可以看出，测试开发岗的编程题有几个评分要点：代码能否覆盖所有边界情况、逻辑是否简洁清晰、有没有自测意识。建议准备这类题时，用“实现功能 + 写自测用例”双输出模式来练习，这个习惯不仅在笔试里加分，实际工作中写测试工具、写自动化脚本时也特别有用。

顺便说一句，编程语言的选择上，Python在测试开发岗笔试中的优势很明显——代码量少、表达能力清晰，阅卷时也容易看逻辑。但如果你对Java更熟，用Java写也完全可以，关键是核心逻辑要对，边界情况要全。别在这种题上炫技，用最稳的写法拿满分，才是性价比最高的策略。

4. 计算机网络与操作系统高频考点：从概念到测试场景

计算机基础这块，测试开发笔试题考得特别“活”。如果你只是背概念，那看到题往往会觉得四个选项都对，因为题目考察的是概念在具体场景中的理解和应用。我结合这套题的高频考点，把最值得重点关注的内容逐一梳理。

4.1 网络协议与接口测试的结合

HTTP和HTTPS的区别、常见状态码的含义、TCP和UDP的区别，这些都是基础中的基础。但在测试开发笔试中，它们往往会和接口测试、弱网测试的场景绑在一起考。

举个例子，一个经典考法：App首页数据加载失败，让你排查原因。可能的因素有哪些？这时候你需要按层次去拆解：

• 客户端侧：请求是否发出、超时设置是否合理、缓存策略是否生效
• 网络侧：DNS解析是否正常、TCP连接是否建立成功、弱网或断网状态下请求是否被中断
• 服务器侧：接口是否返回5xx、是否有接口限流策略、服务器是否过载

这个排查思路比单个知识点重要得多。建议复习时把TCP三次握手、DNS解析、HTTP状态码这几个概念串成一条线：用户在App上点击一个按钮，到页面展示数据，在这期间网络层发生了什么。能把这个链路讲清楚，笔试和面试基本就稳了。

关于HTTPS，重点掌握它和HTTP的核心差异：加密传输、证书验证机制，以及为什么接口测试中HTTPS请求需要额外的证书处理。实际测试工作中，用Charles或Fiddler抓HTTPS包需要装证书，这就是对HTTPS机制的直接验证。

4.2 进程、线程与死锁的理解角度

操作系统考点里，进程与线程的区别、死锁产生的四个必要条件，是出现频率极高的两道题。但测试开发笔试很少直接让你默写，而是会出一些情境判断类的题目。

比如：一个App出现卡顿，可能是什么原因？我们从操作系统角度分析：

• 主线程被耗时操作阻塞（比如在主线程做了网络请求或大文件读写）
• 内存不足导致频繁GC
• 多个线程竞争共享资源导致死锁或锁等待时长过长

这里的考察点已经不只是“你知不知道线程和进程的区别”，而是“你能不能把这个知识应用到App性能问题的分析中”。这才是测试开发需要的思维方式。

死锁这块，除了记住互斥、持有并等待、不可剥夺、循环等待这四个条件，建议再准备一个实际例子。比如多线程测试中，两个线程分别持有锁A和锁B，同时又在等待对方持有的那把锁，这就形成了死锁。笔试里如果让你分析“如何避免死锁”，可以从破坏四个必要条件中的任意一个入手来回答。

4.3 高频考点速查

下面这个表格总结了我认为测试开发笔试中网络和操作系统部分最高频的知识点，建议重点背熟并能举出测试场景中的例子：

看这张表你会发现，每个知识点都能落到一个具体的测试动作上。复习时按这个思路去整理，计算机基础不但不难背，反而越学越清晰。

5. 数据库与Linux指令：测试开发手里的两个工具

数据库和Linux对测试开发来说，不是“了解就行了”，而是每天都要用的工具。这套笔试题二在这部分依然延续了务实路线，基本不考概念默写，而是直接考操作和场景运用。

5.1 SQL题：增删改查之外的考察点

SQL题目在测试开发笔试里一般占10-20分，题型很固定：给你两张表，让你写查询语句。但有几个细节非常容易丢分，我逐一提醒。

第一，连表查询的语法要非常熟练。内连接（INNER JOIN）、左连接（LEFT JOIN）的区别必须能说清楚。笔试中常考的一个场景：查“购买了商品A但没购买商品B的用户”，这种题需要子查询或左连接配合判断，非常考验SQL基本功。

第二，聚合函数和分组的使用要熟练。统计“每个分类下的商品数量”“订单金额最高的前5个用户”，这类题都要用到GROUP BY配合COUNT、SUM、ORDER BY和LIMIT。建议亲手在本地MySQL或SQLite上把这些题写一遍，不要只在纸上写，因为运行结果的校验能加深记忆。

第三，别忘了关注SQL在测试工作中的应用场景。测试中经常需要用SQL构造测试数据、清理脏数据、验证数据一致性。笔试中如果出现“插入一条测试订单数据”这样的题，不单是考语法，还在考你有没有数据准备和清理的意识。

给一个常考题型示例：用户表（user）和订单表（order），查所有下过订单的用户姓名（按姓名去重）。参考语句：

SELECT DISTINCT u.name FROM user u INNER JOIN `order` o ON u.id = o.user_id;

注意order是MySQL的保留字，真实场景中表名一般不会直接叫这个，笔试时如果遇到这种情况，用反引号包起来，这个细节也能体现你的实战经验。

5.2 Linux指令：日志定位与问题排查基本功

Linux指令在测试开发笔试中出现频率很高，考察方向非常固定：文件操作、权限管理、日志查看、进程管理、网络状态。

日志查看是最核心的场景。线上或者测试环境出问题时，第一件事往往是查看日志。下面几个指令几乎必考：

• tail -f app.log：实时跟踪日志输出
• grep "ERROR" app.log：过滤错误信息
• grep -n "keyword" app.log | tail -100：查关键字并显示行号
• awk '{print $4}' app.log | sort | uniq -c：按某一列统计

还有一套完整的日志分析组合拳，我建议练熟：先tail -n 1000 app.log > /tmp/error_part.log截取最近一段日志，再用grep -E "ERROR|Exception"过滤异常，最后用sort | uniq -c | sort -nr统计重复出现的错误。这套动作能应对大多数日志问题定位场景。

进程和端口相关的指令也要熟：ps -ef | grep java查Java进程、netstat -tlnp查端口占用、lsof -i:8080查哪个进程占了8080端口。接口测试中端口被占用、服务起不来这类问题，都会用到这些指令，笔试中它们常以“给你一个运维场景，让你写出排查命令”的形式出现。

文件权限这块，简单记住chmod 755表示所有者可读写执行、组和其他用户可读执行即可。如果需要更细的权限控制，再学chown和chgrp。笔试考这个点不算多，但属于“不会就感觉基础不牢”的知识点。

5.3 数据库与Linux的结合场景

笔试中有一种题型很有意思，它把数据库和Linux合到一个场景题里：比如“接口响应慢，怀疑是数据库慢查询导致的，你如何定位”。这个问题的完整排查步骤就是：

1. 在Linux上查看接口所在服务器的CPU和内存情况，排除资源瓶颈
2. 查看应用日志，确认慢请求的时间点和接口路径
3. 到数据库上开启慢查询日志，找到耗时超过阈值的SQL
4. 使用EXPLAIN分析SQL执行计划，确认是否命中索引
5. 根据分析结果优化SQL或增加索引

答案里既用到了Linux指令，也用到了数据库知识，还能体现测试开发“定位问题”的完整思路。这类综合题得分的关键是有条理，步骤清晰，能让阅卷人一眼看出你有实际排查经验。

6. 移动端测试专项：小米笔试中的特色内容

前面反复提到小米是手机厂商，移动端测试内容在笔试题二里占了相当分量。这部分对很多只做过Web测试或纯后端测试的同学来说，是拉开差距的地方。我梳理一下最可能出现的移动端测试考法和应对策略。

6.1 专项测试的类型与考察方式

移动端测试比Web测试多出几个特有的专项：安装卸载测试、升级测试、兼容性测试、弱网测试、交叉事件测试、性能测试（启动时间、内存、功耗、流量）。

笔试里最常见的考法是让你设计某类专项测试的用例，或者针对某个App功能分析需要做哪些专项测试。比如“设计小米社区App的安装与升级测试用例”，考点包括：

• 首次安装、覆盖安装、卸载后重装
• 不同渠道包的安装验证
• 低版本直接升级到高版本、跨版本升级
• 升级过程中断网、断电对数据的影响
• 升级后老数据是否保留、账号登录状态是否保持
• 应用内数据缓存是否被清理

兼容性测试也是高频考点。如果你准备过测试开发面试，一定见过这种题：“某功能在特定机型上出现崩溃，你如何分析”。正确的思路是：

• 复现问题，收集崩溃日志（logcat）
• 确认崩溃发生的机型、系统版本、分辨率、内存状况
• 对比相同系统版本但不同机型的表现，缩小问题范围
• 检查是否涉及硬件相关的功能（摄像头、传感器、GPU渲染）
• 将问题和日志提交给开发，协助定位

这个思路里，logcat的使用是关键技能。笔试可能会直接考logcat的指令：adb logcat -s AndroidRuntime:E查看崩溃日志、adb logcat | grep -i exception过滤异常信息。建议把这些命令都亲自跑一遍，熟悉了才记得牢。

6.2 弱网与性能测试的思路

移动端测试中弱网测试和性能测试是产品体验的底线。笔试中考这些内容，一般不会让你写出具体工具的命令行，而是考思路和策略。

弱网测试要关注的点：

• 弱网环境下页面加载时间是否符合预期（一般超过3秒会流失用户）
• 弱网下请求超时和重试机制是否生效
• 弱网切换到正常网络后，页面数据是否刷新、是否有缓存策略
• 弱网下是否有重复提交问题

性能测试的考察点则更细致：

• App冷启动和热启动的时间
• 内存占用峰值、是否有内存泄漏
• 长时间使用后的流畅度（卡顿、掉帧）
• 耗电量、流量消耗
• 后台运行时的CPU占用

如果你在笔试里碰到让设计性能测试方案的题，建议按照“指标定义→测试环境→测试步骤→结果分析”的结构来答，思路清晰、逻辑完整，得分会高很多。不要一上来就写用什么工具，先想清楚“测什么、怎么测、结果怎么评价”，这是测试开发的通用方法论。

6.3 自动化测试工具的底层原理

测试开发岗位和纯功能测试最大的区别，就是要能开发和维护自动化测试工具。笔试这部分不会考得太深，但会考察你对常用自动化测试工具的理解程度。

Appium和Selenium是两大核心工具。Selenium操作浏览器的底层是通过WebDriver协议和浏览器通信，Appium则是基于WebDriver协议扩展了移动端的支持，通过iOS的XCUITest和Android的UIAutomator驱动原生应用。理解这个层级关系比死记API重要得多。

笔试中关于自动化工具的常见问题有：

• Selenium中如何定位动态元素（相对定位、XPath/ CSS选择器的优先级）
• UI自动化用例不稳定如何解决（等待机制、重试机制、元素唯一性分析）
• 如何设计一套可持续维护的自动化框架（POM模式页面对象模型）

我强烈建议准备这部分时，亲手搭一个最小可用的UI自动化脚本，哪怕只是让脚本打开一个网页并断言标题是否正确。只有亲手写过，你才能真正理解元素定位、等待、断言这些概念的含义，而不是停留在背面试题的状态。

7. 笔试答题节奏与备考经验：这些坑你一定不要踩

最后这部分聊聊笔试题之外的“软实力”——答题节奏和备考策略。我见过很多技术能力不差的同学在笔试上翻车，原因往往不是不会做，而是时间分配和答题策略出了问题。

7.1 拿到试卷先花3分钟浏览全卷

笔试开始后不要急着做第一题。先把整张试卷快速浏览一遍，弄清楚各部分的分值分布、题目数量和难易程度。心里有一个全局的地图之后，再决定做题顺序。我个人的习惯是：

1. 先做测试用例设计题，因为这类题只要逻辑清晰就能拿分，而且不需要长时间“启动”
2. 再做编程题，这是整张卷子的核心分，需要保证大脑清醒
3. 然后做数据库和Linux操作题，这些是抢分题
4. 最后做计算机网络和操作系统选择题（如果比较顺手可以提前做）
5. 先跳过不会的题，不要在单题上耗超过5分钟

这套策略的核心就是一个思路：先把能拿的分牢牢握在手里，再集中火力啃硬骨头。

7.2 用例设计题别怕“写太多”，但要分点清晰

很多同学写测试用例时有一个误解，觉得写得越长越好。事实上，笔试阅卷看的是覆盖层级和逻辑结构，不是凑字数。每条用例之间要有清晰的逻辑关系，能看出你是按什么维度拆解的。如果功能测试、异常测试、兼容测试分条列组，阅卷人一眼就能看出你有测试方法论。

建议养成用表格写测试用例的习惯，笔试中即使不要求，简洁的表格也会让阅卷体验好很多。比如：

7.3 编程题写完后留时间自测

编程题千万不要写完就交卷，一定要留出时间在草稿纸上手动跑几组测试用例。比如你实现了一个字符串处理函数，至少要把正常输入、空输入、超长输入、特殊字符输入这四类情况都过一遍。这个习惯能帮你抓出很多边界条件的疏漏。笔试环境虽然不一定能实际运行代码，但你可以在脑内“干跑”数据流，把逻辑推演一遍，很多低级错误就是这样发现的。

7.4 综合题拿高分的套路：结构化表达

最后一种题型是开放性的场景题，比如“设计一个功能模块的测试方案”“分析某个线上问题的排查思路”。这种题没有标准答案，但拿高分的套路是固定的：用结构化的方式组织你的答案。

回答测试方案时，按照“测试范围→测试类型→测试环境→测试用例→缺陷管理”这个顺序来。回答排查问题时，按照“现象确认→初步判断→逐步排查→定位根因→验证修复→回归测试”的逻辑来。这种结构化表达不仅能让你想得更全面，也能让阅卷人在几十份卷子里一眼记住你。

根据我个人经验，这套笔试题二的难度，总体来说比纯互联网大厂略低，但对测试思维和移动端能力的重视程度很高。准备时与其海量刷题，不如把每一个考点吃透，尽量做到“知其然更知其所以然”。希望这篇文章能帮你在准备测试开发笔试的路上少走一些弯路。如果你正在准备小米或同类手机厂商的测试开发岗，移动端专项、数据库操作和用例设计这三块能力一定要重点打磨，它们才是真正决定你笔试分数的关键。