四川长虹电子控股集团有限公司校招测试助理工程师面试经验——求职精灵（finsight.work）

面试官您好，我叫 XX，XX 专业。在校系统学习软件测试相关知识，掌握功能测试基础，学习过接口测试入门。
实训项目做过智能家居 APP 的功能测试，熟练使用等价类、边界值方法设计测试用例；工具上使用 Postman 做接口测试，MySQL 做数据校验，禅道管理 Bug，了解 Charles 抓包、JMeter 基础压测。
我了解长虹深耕智能家居、物联网硬件领域，希望应聘测试助理岗位，从用例编写、测试执行、缺陷跟进做起，持续学习嵌入式、TV 端软件测试，在长虹长期成长。

实训项目整体开发 + 测试周期 2 个月，纯测试阶段 4 周。工作安排：

1. 需求阶段：参与需求评审，读懂产品业务，标记模糊需求点，和产品确认；
2. 测试计划：确定测试范围、环境、人力、风险；
3. 用例设计：使用等价类、边界值编写用例，组织用例评审；
4. 测试执行：版本提测先跑冒烟测试，冒烟通过执行全量用例，提交 Bug；
5. 回归测试：开发修复缺陷后，执行回归用例；
6. 收尾：输出测试报告，总结风险。

项目遇到偶现 Bug，很难稳定复现。解决：

1. 完整记录环境信息：设备型号、软件版本、操作步骤、截图、系统日志；
2. 反复操作，缩小触发条件，记录复现概率；
3. 使用 Charles 抓包，查看接口请求返回，辅助定位；
4. 把完整证据提交开发，一起分析触发场景；
5. 最终定位是并发场景下的数据问题。

亮点：突出证据留存、协作沟通，不是单纯找 bug。

1. 评估所有功能，区分核心主流程和次要边缘功能；
2. 和产品、开发沟通，优先保障核心业务用例执行，次要功能评估延后；
3. 筛选高风险模块重点测试，低风险模块精简测试点；
4. 重点保障冒烟测试、回归测试；
5. 同步项目组测试风险，在报告中标注未覆盖范围，不隐瞒质量风险。

1. 功能：正常输入文字成功发布；空内容 / 全空格无法提交；达到最大字符限制不能提交；可以删除自己评论，不能删别人；评论按时间排序，支持回复；
2. 异常 & 边界：特殊字符、脚本标签（防 XSS）；断网提交友好提示；
3. UI：文字超长自动换行，页面排版正常，适配不同分辨率；
4. 兼容性：不同 APP 版本、不同设备（手机 / 电视端，贴合长虹业务）；
5. 权限安全：未登录不能发评论；敏感词过滤。

1. 单选：只能选中 1 个选项，不选无法提交；
2. 多选：最多支持指定数量选项，超过上限不能提交；不选不能提交；
3. 业务规则：同一个用户只能投一次票；投票后票数实时更新；
4. 边界：选项数量上限；
5. 异常：断网、重复点击提交；
6. 权限：查看投票结果权限；多端兼容性。

1. 正常场景：生成邀请链接 / 二维码，好友点击注册成功，邀请人获得奖励；
2. 边界：链接有效期，过期链接失效；
3. 异常：重复点击邀请链接；同一账号多次被邀请；网络差提示友好；
4. 权限：未登录账号不能生成邀请；
5. 安全：链接防篡改。

1. 正常：点击收藏成功，再次点击取消收藏；收藏列表能看到对应内容；取消后列表消失；
2. 边界：收藏数量达到上限；
3. 异常：重复点击收藏按钮；断网操作；
4. 权限：未登录不能收藏；切换账号，收藏数据隔离；
5. 多端同步：APP / 电视端收藏数据同步（贴合长虹智能家居）。

1. 使用等价类划分，区分有效、无效等价类；
2. 边界值分析法，重点测最大值、最小值、临界值、超临界值；
3. 梳理需求文档，提取全部约束条件；
4. 使用场景法梳理完整业务流程；
5. 用例评审，同事交叉 Review 查漏；
6. 结合业务经验，补充隐性需求边界。

HTTP 是应用层超文本传输协议，基于 TCP，无状态，用于客户端与服务端通信。
请求头常见字段：Host 目标主机、User-Agent 客户端信息、Content-Type 请求体格式、Cookie、Accept 客户端支持的数据类型。

使用 JMeter 设置多线程并发发起请求；重点验证超卖问题：同一订单并发下单，只能成功 1 次，数据库库存数据准确，不会出现脏数据。

分页入参一般是 page 页码、size 每页条数。测试点：

1. 正常：page=1、size=10，返回 10 条数据；
2. 边界：page=0、负数、超出最大页码；size=0、超过最大限制；
3. 最后一页数据少于 size；
4. 校验分页排序一致性；
5. 异常参数：非数字页码。

1. 模拟服务端响应延迟，超过接口超时时间；预期客户端抛出超时提示，不会无限等待；
2. 响应时间小于超时时间，正常返回数据；
3. 验证超时后的重试机制（如有）。

1. 使用 Postman / Charles 直接调用后端接口，查看原始返回 JSON；
2. 如果后端原始返回字段、格式错误 → 后端 bug；
3. 如果后端返回正确，页面展示错误 → 前端 bug；
4. 同时核对前端传给后端的请求参数是否错误。

在校学习 UI 自动化，学习 Selenium + Python，可以编写简单脚本打开网页、定位元素、点击输入。自动化适合稳定重复的回归场景，例如冒烟回归。现阶段我的重心是手工功能测试，后续希望学习自动化提升效率。

区分原生 alert 弹窗和前端自定义弹窗；使用隐式等待、显式等待等待弹窗元素出现；定位弹窗确定 / 取消按钮；捕获异常，防止脚本崩溃。

Python logging 模块，分级记录 debug、info、warning、error；记录操作步骤、报错信息、时间；日志保存文件，脚本失败便于定位问题。

pytest 框架使用插件 pytest-rerunfailures，配置失败用例自动重跑，设置重跑次数；仅针对偶现不稳定用例，不是全部用例。

1. 自动化用例覆盖率：覆盖核心回归用例比例；
2. 人力节省：每次回归节省手工测试时长；
3. 缺陷发现能力：自动化脚本能否提前捕获回归 bug；
4. 维护成本：业务变更，脚本修改成本高低。

open() 打开文件，close() 关闭。with 是上下文管理器，代码块结束自动关闭文件，即使代码异常也释放资源，避免忘记 close 造成句柄泄露。

最简洁的写法是切片：

def reverse_str(s: str) -> str:
    return s[::-1]

其他常见写法：

# 1. reversed + join
def reverse_str(s):
    return ''.join(reversed(s))

# 2. 双指针（原地交换，适用于列表）
def reverse_str(s):
    lst = list(s)
    i, j = 0, len(lst) - 1
    while i < j:
        lst[i], lst[j] = lst[j], lst[i]
        i += 1
        j -= 1
    return ''.join(lst)

补充：面试时最好把边界一并说明——空字符串、单字符、含中文或 emoji 的情况都能正常处理；如果要求不使用切片，就用双指针写法。

lambda 是匿名单行函数，适合简单表达式，不需要 def 定义。

# 普通函数
def add(a, b):
    return a + b

# 等价的 lambda
add = lambda a, b: a + b

# 常见用法：作为排序 key
users = [{'name': 'Tom', 'age': 20}, {'name': 'Mary', 'age': 18}]
users.sort(key=lambda u: u['age'])

补充：lambda 只能写单个表达式，不能写多行逻辑；复杂逻辑仍应使用 def。

pip install 库名；测试常用：requests（接口）、pytest（测试框架）、selenium（UI 自动化）、json（解析 json）。

导入 json 模块：json.loads()：json 字符串转为 python 字典；json.dumps()：python 字典转为 json 字符串。

学习过 JMeter 做基础压测。

• 负载测试：逐步增加用户，验证系统在预期业务负载下响应时间、TPS 指标，看系统正常负载能否稳定运行。
• 压力测试：不断加压直到系统达到瓶颈、崩溃，找到系统最大承载极限。

JMeter 设置思考时间模拟用户操作停顿；设置并发线程；使用真实业务参数，模拟不同用户操作链路。

1. 服务器资源不稳定：CPU、内存波动；
2. 数据库查询慢、缺少索引；
3. 后端服务频繁 GC；
4. 网络抖动；
5. 并发线程不稳定。

使用工具限制服务器 CPU 使用率，再执行压测；观察系统响应时间、报错，验证资源不足时系统是否优雅降级，不会直接崩溃。

最难的是模拟真实线上环境，测试环境很难完全复刻真实用户行为；其次性能瓶颈定位，需要同时排查服务器、数据库、网络多个维度。

在线程组下添加正则表达式提取器，填写引用名称、正则表达式；提取接口响应的数据，作为下一个接口的参数，实现接口关联。

使用 Collection Runner，导入 csv 或 json 文件；请求中用 {{变量名}} 读取文件中的参数。

Charles 打开 Throttle Settings 节流设置，开启节流，配置延迟时间；可以单独对指定域名设置弱网延迟。

创建多分支流水线任务，关联 Git 仓库；Jenkins 自动扫描仓库分支；读取仓库内 Jenkinsfile，不同分支执行不同构建、测试任务。

拉取镜像，启动容器，快速部署数据库、后端服务；可以快速销毁、重建环境，保证测试环境干净，环境一致性。

常用写法一（NOT EXISTS，推荐，语义最直接）：

SELECT u.user_id, u.user_name
FROM users u
WHERE NOT EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.user_id = u.user_id
      AND o.created_at >= DATE_SUB(CURDATE(), INTERVAL 1 MONTH)
);

写法二（LEFT JOIN + IS NULL）：

SELECT u.user_id, u.user_name
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.user_id
 AND o.created_at >= DATE_SUB(CURDATE(), INTERVAL 1 MONTH)
WHERE o.order_id IS NULL;

注意点：

1. 时间条件必须写在 ON / 子查询里，写在 WHERE 里会把 LEFT JOIN 退化成 INNER JOIN，查出的结果就不对了。
2. 「没有下过单」与「注册超过一个月且从未下单」是两种口径，题目要求的是前者；如需后者，再加 AND u.created_at < DATE_SUB(CURDATE(), INTERVAL 1 MONTH)。
3. 需向面试官确认订单表是否含已取消 / 已退款状态，是否要过滤。

主键：唯一标识一行记录，非空且唯一；外键：关联另一张表主键，保证表之间引用完整性。

SQL 注入：攻击者输入恶意 SQL 语句，后端直接拼接 SQL 执行，造成数据泄露、篡改。
测试：在输入框 / 请求参数输入 '、or 1=1-- 等字符；观察页面异常；抓包查看请求参数；查看后端日志。

JMeter 多线程同时发起新增 / 修改请求；校验：并发写入后数据库数据正确；唯一字段不能插入重复数据；事务失败自动回滚。

1. UI 操作删除，前端页面数据消失；
2. 查询数据库：硬删除记录消失，软删除看删除标记；
3. 校验关联数据，按业务规则处理；
4. 边界：删除不存在 ID、重复点击删除；
5. 权限校验：无权限用户无法删除。

查看权限：ls -l 文件名；修改权限：chmod，例 chmod 755 test.sh。权限分为所有者、用户组、其他用户，r 读 w 写 x 执行。

查找文件：find / -name "test.txt"；找到后删除：find / -name "test.txt" -delete；也可以拿到路径后执行 rm 文件路径。

history，查看执行过的所有历史指令。

pwd，打印当前目录绝对路径。

cp -r 源文件夹 目标路径，-r 代表递归复制文件夹内全部子文件和子目录。

Redis 分布式锁使用 set key value NX EX；NX = 不存在才设置；EX 设置过期时间，防止死锁。学习过原理，用来控制并发争抢资源，防止超卖。

缓存雪崩：大量 key 同一时间过期，大量请求直接打到数据库，压垮 DB。
规避：过期时间增加随机值打散；Redis 集群高可用；接口限流熔断。

消息队列有 ACK 确认机制；消费者宕机，消息不会删除，放回队列等待其他消费者消费；业务需要保证消息幂等，防止重复消费。

1. 生产者发送消息，验证消息入队；
2. 消费者宕机，消息不丢失，重启后正常消费；
3. 消费失败，消息重试 / 进入死信队列；
4. 高并发发送，验证消息不丢、不重复。

监控指标：消息堆积数量、生产速率、消费速率、失败消息数量、消费者在线状态；消息持续堆积代表消费能力不足。

1. 我先在测试环境复现 bug，完整记录版本、设备、操作步骤、截图、日志；
2. 和开发对齐两边环境差异：版本、配置、数据库数据；
3. 如果环境不一致，邀请开发到测试环境一起复现；
4. 拿出抓包、日志证据，一起定位；
5. 目标是确认产品质量问题，不是争辩对错。

文档是测试工作的产出，方便团队对齐需求，工作可追溯。实训写过：测试用例、测试计划、Bug 报告、测试总结报告。文档简洁清晰，重点突出需求、测试点、风险即可。

重复回归是保障版本稳定必不可少的。认真完成，不漏缺陷；同时思考，稳定重复的流程可以尝试自动化脚本，减少手工重复工作量。

非常需要。不懂业务只能测表面功能，很难发现业务逻辑缺陷；评估缺陷严重程度、和产品沟通需求，都依赖业务理解。像长虹智能家居，要理解家电真实使用场景。

外包可以承接基础执行类测试。我的求职目标是长虹正式测试助理，希望深度参与产品完整研发流程，深耕智能家居业务，长期在业务内成长。

长虹是国内智能家电、物联网龙头，产品覆盖智能电视、智能家居硬件，软硬件一体化，有大量嵌入式、TV 端软件测试场景。我对物联网硬件配套软件测试很感兴趣；测试助理岗位可以让我从基础用例、测试执行入手，打好测试基本功，希望长期在长虹学习成长。

• 根据需求编写测试用例，执行手工测试；
• 提交、跟进缺陷，和开发、产品沟通 bug；
• 执行回归测试，记录测试日志；
• 协助测试工程师准备测试环境、整理文档；
• 持续学习测试工具、业务知识。

首先复现 Bug，留存截图、日志等证据；和开发沟通，倾听对方想法；需求模糊时邀请产品一起评审，以需求文档为准；沟通目标是保障产品质量，不是争论对错。

细心、怀疑精神，良好沟通能力，持续学习能力。测试需要挖掘隐藏问题，还要和团队协作，持续学习新技术、新业务。

1 年内：熟练基础功能测试，独立写用例、管理缺陷，熟悉长虹智能家居业务；
2~3 年：学习接口测试，尝试简单自动化，成长为独立软件测试工程师，独立承担模块测试。

长虹智能电视、智能家居全套产品、物联网模组，还有智慧社区软硬件，大量嵌入式、TV 端 APP 软件，都是测试对象。

面试官您好，我是 XX，XX 大学 XX 专业应届毕业生。在校期间系统学习了软件测试相关课程，实训做过智能家居 APP 的功能测试，能独立用等价类、边界值设计用例，会用 Postman、MySQL、禅道等工具。我求职目标明确，就是做测试，希望从测试助理做起，长期在长虹的智能家居业务里成长。
提示：HR 面的自我介绍要比一面短，重点放在求职动机和稳定性上。

我期望薪资符合公司应届生薪酬体系。相比薪资，我更看重岗位成长机会。

项目上线紧急阶段，我可以配合团队加班完成测试；平时我会高效完成本职工作。

优点：细心，学习能力强，擅长梳理业务流程；
缺点：真实项目实战经验有限，希望入职后在项目中快速补齐。

如实回答，重点表达长虹是我的意向选择。
提示：有就说有、没有就说没有，但无论哪种都要把落点放在「长虹是我的优先选择，因为 XX（业务方向 / 培养 / 地点）」。

可以接受。我了解长虹的测试岗位主要在绵阳 / 成都，我本人和家庭方面都没有障碍，可以稳定在当地长期发展。
提示：这是稳定性考察，明确表态即可，不要含糊。

反问推荐（选 1~2 条）：

1. 测试助理岗位，日常主要负责哪一类产品测试？智能电视还是智能家居 APP？
2. 团队对测试助理工程师的新人培养路径是怎样的？
3. 团队手工测试、自动化测试的占比大概是多少？

提示：优先问业务方向和培养路径，避谈薪资与加班。