一.如果开发说不是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 已经拿到，还有一两个在面试中。
但我对贵公司的岗位和团队更感兴趣，尤其是这边的测试方向与我的项目经历匹配度比较高，所以还是优先考虑这边的发展机会。