一.如果开发说不是bug,你怎么解决?
1.自查确认:我会首先检查测试用例和复现步骤,确保不是测试误判或环境问题;
2.提供依据:如果确认是问题,我会结合需求文档、接口规范或 UI 设计稿等依据,说明为什么这属于不符合预期的行为;
3.复现演示:我会准备复现步骤或录屏演示,让开发更直观理解问题发生的位置和场景;
4.协同分析:如果开发仍坚持不是 Bug,我会邀请产品或测试组长参与沟通,一起确认预期行为是否合理;
5.结论处理:如果最终确认不是 Bug,我会在 Jira 中备注说明,作为“非缺陷关闭”;如果是 Bug,也会及时推动修复和回归测试。
二.说一下你遇到的APP的bug
(1)在我平时对某款校园 APP 做兼容性测试时,发现一个机型相关的 Bug:在小米手机 Android 13 上打开课程表页面会直接闪退,但在华为和荣耀设备上都正常。
我抓取了崩溃日志,并用 Android Studio 查看错误栈信息,发现是因为该页面调用了系统日历 API,而小米定制系统权限未适配导致崩溃。后来我协助开发优化了权限判断逻辑并加上容错处理,Bug 得以修复。
(2)我在使用微信的过程中曾遇到一个典型的多端同步 Bug:当手机和电脑端同时登录时,部分消息会在电脑端显示正常,但手机端不会有新消息提醒,甚至无法在聊天记录中第一时间看到对应消息。
我复现这个问题的方法是:手机和电脑端同时登录 → 在另一个账号向我发送多条连续消息 → 电脑端实时收到,但手机端既没有通知,也没有红点提示,部分消息在进入聊天框前也不会同步显示。
这个问题属于典型的多端状态同步不一致,可能的原因是:
手机端因后台运行机制或网络状态未及时拉取消息;
消息状态未正确更新(如被标记为已读);
多端消息收敛逻辑(如“已读优先”)处理不合理。
这类 Bug 虽然不会导致功能崩溃,但会严重影响用户体验,容易错过重要消息,在 IM 系统中属于较为敏感的问题。
如果在正式项目中遇到类似情况,我会:
明确复现路径和测试环境;
抓取客户端日志或消息状态码;
与开发确认消息队列处理、拉取机制或设备状态;
并在 Bug 单中注明影响等级、设备类型与多端状态。
一句话总结:我在使用微信时发现一个同步 Bug:电脑和手机同时登录时,手机端有时会不提示消息,也不显示新内容,影响沟通体验。我通过复现步骤、环境对比判断这是一个多端同步异常的问题,像这种 Bug 在多端协同产品中比较常见,也需要从消息队列、状态更新和前后台逻辑去排查。
三.你最喜欢哪款app,为什么?
我最喜欢的 App 是小红书。它不仅是一个分享生活的平台,也在不断强化搜索、推荐、购物等多种功能融合,我平时会用它记录生活、查资料、看穿搭、美食、甚至软件工具推荐,内容非常多样。
我特别喜欢它的“个性化推荐”和“信息沉浸感”。比如搜索“大学宿舍整理”或者“软件测试学习笔记”时,它能很快给我推送出高相关性的内容,并且卡片式信息展示既美观又不杂乱。
作为测试人员,我也会从逻辑角度关注它的推荐算法、图片加载策略、多端同步(草稿保存)、点赞评论状态一致性等细节。像它的视频播放逻辑、图文滑动手势处理等交互体验都做得很流畅,也体现出产品背后的调优能力。
总体来说,小红书在用户体验和功能精细度之间找到了很好的平衡,我在使用中既是用户也会带着测试思维去观察产品的细节。
四. 你觉得团队合作中什么最重要
在我看来,团队合作中最重要的是高效沟通与责任意识。
一个团队想要协作顺畅,必须做到信息透明、及时反馈,尤其在开发与测试之间,沟通越及时,问题解决得越快。同时,每个人都要有清晰的角色定位,愿意对自己的工作结果负责,不推诿、不拖延。
此外,尊重与理解也很重要,每个人的思维方式和表达风格不同,出现分歧时,我会以项目目标为导向,理性表达观点、倾听他人建议,寻求更好的解决方案。
在我参与的项目中,无论是和开发联调,还是和产品确认需求,我始终重视沟通的效率和态度,也积极补位和协助其他成员,共同保证交付质量。
五.你和开发人员遇到的最大困难
我在和开发合作中遇到过最大的困难,是在一个接口联调阶段,测试发现返回数据结构和接口文档不一致,但开发坚持这是“按最新逻辑实现的”,认为不算 Bug。
当时我没有争论,而是先确认用例逻辑与接口说明,整理出旧文档、实际响应和预期对比表,然后找产品一起沟通需求是否有变更。结果发现,开发确实按口头沟通的“最新方案”实现了,但接口文档没有同步更新,造成了测试误判。
最后我们一致决定:文档更新必须同步版本控制,我也补充了测试用例说明,防止后续误解。这个过程让我明白:测试和开发的冲突,往往不是技术问题,而是沟通和信息同步的问题,只要理性处理、换位思考,是完全可以共赢的。
六.你在项目里遇到的印象最深的困难是什么
想看你是否真的参与过项目,能不能面对问题、解决问题、总结经验。
回答结构建议(STAR 法则):
S(Situation)场景: 项目背景是什么
T(Task)任务: 你当时负责什么
A(Action)行动: 你怎么做的、用了哪些方法
R(Result)结果: 最后怎么解决的,你学到了什么
在参与对抗样本生成平台项目时,最大的困难是模型复杂、数据依赖多,导致测试过程不稳定。我没有简单报 Bug,而是深入排查流程、引入日志比对和 wandb 跟踪机制,最终提升了测试稳定性。这让我体会到,测试不仅是执行任务,更是主动解决问题、保障质量的一环。
七.你说你善于总结,这怎么体现
不仅在工作中,我在生活中也有总结复盘的习惯。比如做完一件事情之后,我会习惯性地回顾一下过程有没有更高效的方式,或者有没有哪一步可以优化。
举个简单的例子,像我平时做 PPT 或准备答辩汇报时,完成后我会先自己过一遍内容逻辑和语言表达,再总结哪些地方讲得不够清晰,下次就会改进表达顺序或者精简内容结构。
包括我日常学习也是一样,比如看完一段测试视频或学完一门课程,我会写笔记,整理成知识框架,而不是学完就放那。
这些习惯也延伸到了我的工作中,比如测试结束后,我会复盘用例设计是否完整、流程中是否有遗漏、沟通是否及时,形成闭环思维,下一轮就能更高效、少犯错。
八.你的简历中写你在校团委新媒体中心工作过,你在工作中有没有遇到印象深刻的问题?
是的,在校团委新媒体中心平台部工作期间,我印象最深的一次问题是关于一次重要校园活动推文的发布协调。
当时我们需要在某个特定时间点发布一篇学校重大活动的宣传推文,但策划部的文案迟迟未定稿,后期部门也在等最终素材,而我这边还要负责整体内容整合、美化和平台排期。如果流程中任何一环延迟,整条推文就可能错过发布时间。
面对这种情况,我主动和策划部沟通文案核心结构,让他们先提供初稿,我这边先行排版;同时和后期组协商提前处理固定素材部分,把可并行的工作拆分开来,最后再统一对齐细节。
通过这种前置协调 + 多线并行 + 临近校验的方式,我们最终成功按时发布了推文,也没有影响活动宣传的节奏。
这次经历让我意识到,在多方协作中,及时沟通、合理拆解任务、掌握节奏非常重要,也提升了我项目统筹和协作推进的能力。
一句话总结:我当时在平台部,负责整合策划部和后期部门的内容。有一次活动推文快到期但文案没出图也没到,我就提前拆任务、同步推进、最后合并校验,确保按时上线。这次经历让我体会到跨部门协作中,主动沟通和统筹节奏非常关键。
九.在初试到复试这个期间,你又学了什么测试的知识?
在初试和复试之间这段时间,我主要做了两件事:
一是对初试内容进行了复盘总结,特别是我在哪些题目回答得不够深入、哪些知识点掌握还不扎实,我有做笔记,查漏补缺;
二是我找了现在从事软件测试的同学交流,了解了他们实际工作中对自动化测试和脚本编写的应用场景,也意识到掌握基础编程能力很重要,所以我重点学习了 Python + unittest 框架,包括如何组织测试用例、如何编写断言、怎么生成测试报告等内容,还尝试写了一些简单的接口测试脚本。
这段时间让我意识到,测试不只是点点点,更需要技术理解、思维方法和持续学习的意识,所以我也会继续提升自己的能力,争取更快适应岗位需求。
最近我重点学习了 Python 的 unittest
测试框架,了解了它的四个核心概念和整体执行流程:
TestCase(测试用例):是最小的测试单元,用于定义具体的测试逻辑;
TestFixture(测试夹具):是测试的前置和清理操作,比如
setUp()
和tearDown()
方法;TestSuite(测试套件):用于组织多个 TestCase,方便批量运行;
TestRunner(测试运行器):负责执行 TestSuite,并生成测试结果。
执行流程是:编写 TestCase → 用 TestLoader 加载到 TestSuite → 由 TextTestRunner 运行 → 输出结果到 TextTestResult。
通常我们也可以使用 unittest.main()
作为入口,它会默认调用 TextTestRunner 去执行测试。
此外,我还了解了可以使用 HTMLTestRunner 等方式将结果输出为 HTML 格式,生成更美观的测试报告。
十.hr问你有没有别的offer
是的,目前我确实也在跟进一些其他机会,有个 offer 已经拿到,还有一两个在面试中。
但我对贵公司的岗位和团队更感兴趣,尤其是这边的测试方向与我的项目经历匹配度比较高,所以还是优先考虑这边的发展机会。