# 阿里

# 真题一

# 1. 自我介绍

答题思路：突出专业背景、核心技能和项目经验，展现与岗位的匹配度。
参考话术：面试官您好，我是[姓名]，有[X]年软件测试经验，精通Python自动化测试、接口测试和性能测试。在上一家公司主要负责[项目名称]的测试工作，独立完成了自动化测试框架搭建和持续集成流程优化，提升了测试效率50%以上。我对质量保障体系有深入理解，期待能加入贵团队贡献价值。

# 2. 介绍项目和测试流程

答题思路：按实际项目说明测试全流程，体现系统性和规范性。
参考话术：我负责的[项目名称]采用敏捷开发模式。测试流程包括：1）需求分析阶段参与评审并制定测试策略；2）开发阶段编写测试用例和自动化脚本；3）提测后执行功能测试、自动化回归和性能测试；4）上线后线上监控和回归验证。我们使用Jenkins实现持续集成，自动化用例执行率超过80%。

# 3. 这些项目是你独立负责的吗？

答题思路：根据实际情况说明，如果是团队合作要体现协作能力。
参考话术：核心模块由我独立负责，包括订单和支付模块的测试方案设计、自动化实现和性能测试。其他模块与团队协作完成，我会参与用例评审和交叉测试，确保整体质量。

# 4. 你负责哪个部分？

答题思路：明确测试范畴，体现代码级测试能力。
参考话术：我主要专注服务端和接口测试，包括API自动化、数据库校验和性能压测。同时也会参与前端功能测试，使用Selennium编写UI自动化脚本，保证端到端的质量。

# 5. 接口自动化数据库校验怎么做？

答题思路：展示数据库操作和断言能力，体现代码实现细节。
参考话术：我使用Python的PyMySQL库进行数据库验证。比如下单后查询订单表校验状态和金额：

def verify_order(order_id, expected_amount):
    conn = pymysql.connect(host=DB_HOST, user=DB_USER, password=DB_PASSWORD, database=DB_NAME)
    cursor = conn.cursor()
    cursor.execute(f"SELECT order_amount FROM orders WHERE order_id = '{order_id}'")
    result = cursor.fetchone()
    assert result[0] == expected_amount, f"订单金额不符，预期{expected_amount}，实际{result[0]}"

1
2
3
4
5
6

# 6. 请求是什么协议的？

答题思路：体现对网络协议的理解，常见HTTP/HTTPS。
参考话术：我们系统主要使用HTTP/HTTPS协议，部分内部服务采用RPC协议。接口测试中使用Requests库处理HTTP请求，配置证书和超时参数保证安全性。

# 7. 包括创建订单吗？

答题思路：肯定回答并举例说明，体现核心业务测试经验。
参考话术：是的，创建订单是我重点测试的场景。包括正常下单、优惠券抵扣、库存校验等异常流程，我都编写了完整的自动化用例覆盖。

# 8. 怎么把整个流程串起来？

答题思路：说明测试框架设计思路，体现架构能力。
参考话术：我使用Pytest测试框架组织用例，通过fixture实现测试数据准备和清理。用Allure生成可视化报告，并结合Jenkins pipeline将接口测试、UI自动化、性能测试串联成完整流水线。

# 9. 订单号生成后做数据清理吗？

答题思路：强调测试数据管理规范性，避免环境污染。
参考话术：一定会清理。我在用例的teardown阶段通过API或数据库删除测试订单。对于性能测试的压测数据，会使用特定前缀方便批量清理。

# 10. 怎么拿到订单号？

答题思路：展示接口关联处理能力。
参考话术：通过解析创建订单接口的响应获取订单号：

def create_order():
    response = requests.post("/api/order", json=order_data)
    return response.json()["data"]["order_id"]  # 提取订单号

1
2
3

# 11. 自动化过程中遇到过什么问题？

答题思路：选择有代表性的技术难题，体现代码能力和解决思路。
参考话术：遇到过异步处理导致的校验失败。比如下单后需要等待支付回调更新状态，我通过轮询查询数据库的方式解决：

def wait_for_order_status(order_id, expected_status, timeout=10):
    start_time = time.time()
    while time.time() - start_time < timeout:
        current_status = get_order_status(order_id)
        if current_status == expected_status:
            return True
        time.sleep(0.5)
    raise TimeoutError(f"订单状态未在{timeout}秒内变为{expected_status}")

1
2
3
4
5
6
7
8

# 12. 没有稳定测试环境吗？

答题思路：体现实战经验，展示环境处理能力。
参考话术：我们有多套测试环境，但确实存在不稳定的情况。我会在用例中加入重试机制，对于依赖第三方服务的接口使用Mock替代，保证自动化可靠性。

# 13. 半夜执行自动化作用大吗？

答题思路：肯定自动化价值，体现质量保障意识。
参考话术：作用很大。夜间执行可以充分利用资源，快速反馈版本质量。发现严重问题时会第一时间通知开发，避免问题遗留到第二天，缩短修复周期。

# 14. 对自动化的定位是什么？

答题思路：阐述自动化测试的价值和局限性。
参考话术：我认为自动化是质量保障的重要补充，能够提升回归效率，但不能完全替代手工测试。适合用于重复性高的回归场景，而探索性测试和用户体验测试仍需手工进行。

# 15. 怎么提高半夜执行效率？

答题思路：展示性能优化实践经验。
参考话术：我采用这些方法提升效率：1）用例并行执行，使用Pytest-xdist插件；2）优化测试数据准备，减少不必要的初始化；3）按优先级分组执行，核心用例先运行。

# 16. 自动化在什么阶段使用？

答题思路：说明自动化介入时机，体现测试策略思维。
参考话术：主要在提测后用于回归测试，确保新功能不影响现有逻辑。在开发阶段也会作为接口契约测试，提前发现接口问题。

# 17. 提测后是准入还是随意弄？

答题思路：强调流程规范性，体现质量门禁意识。
参考话术：我们有严格的准入标准，必须通过冒烟测试才能正式提测。我维护了一个核心场景的自动化冒烟测试集，开发完成后自动触发，通过率100%才能提测。

# 18. 自动化发挥的价值在哪？

答题思路：用数据说明自动化带来的实际效益。
参考话术：主要体现在三方面：1）回归时间从3人天缩短到2小时；2）累计发现隐藏bug 200+；3）支持频繁发布，版本迭代周期从月缩短到周。

# 19. 自动化是辅助手段吗？

答题思路：辩证看待自动化地位，体现测试体系理解。
参考话术：自动化不是万能药，但是现代质量保障体系中不可或缺的一环。它解放了人力去做更有价值的测试设计和技术提升，是推动研发效能提升的关键因素。

# 20. 自动化用例有多少个？

答题思路：给出具体数字并说明覆盖范围。
参考话术：目前接口自动化用例1500+，核心业务流程覆盖率达到95%。UI自动化200+，覆盖主要用户路径。每月新增约50个用例，持续完善覆盖。

# 21. 测试涉及交易相关流程吗？

答题思路：展示金融业务测试经验，体现代码安全性意识。
参考话术：深度参与过交易全流程测试，包括下单、支付、退款、清算等。特别关注资金安全，会校验金额计算、幂等性、防重入等关键点。

# 22. 正向下单有资金风险吗？

答题思路：体现风险意识和防护措施。
参考话术：确实有风险。我们通过以下方式防控：1）测试环境使用虚拟资金；2）金额校验使用固定测试数据；3）生产环境有多层金额校验机制，测试时会重点验证这些防护是否生效。

# 23. 测试重点和最大风险是什么？

答题思路：展示业务理解力和风险识别能力。
参考话术：最大风险是资金安全和数据一致性。我的测试重点是：1）交易核心路径的资金计算；2）分布式系统的数据最终一致性；3）高并发场景下的系统稳定性。

# 24. 怎么保证测试全面性？

答题思路：系统化阐述测试设计方法。
参考话术：我采用多维度的测试设计：1）基于需求的功能测试；2）基于状态迁移的流程测试；3）边界值和异常场景测试；4）定期回溯线上问题补充用例。还会使用代码覆盖率工具检查覆盖盲区。

# 25. 性能测试怎么做的？

答题思路：展示完整的性能测试方法论。
参考话术：采用阶梯式压测策略：1）先进行基准测试确定性能基线；2）然后进行负载测试找出性能拐点；3）最后进行稳定性测试检查内存泄漏。使用JMeter编写脚本，监控系统资源和服务指标。

# 26. 压测脚本是自己写的吗？

答题思路：体现技术能力和独立负责精神。
参考话术：是的，全部脚本由我独立编写。基于实际业务场景设计压测模型，包括用户登录、浏览商品、下单等混合场景，贴近真实用户行为。

# 27. JMeter开发成本大吗？

答题思路：客观评价工具使用难度，体现学习能力。
参考话术：入门简单，但要编写复杂的业务场景需要一定学习成本。我通过BeanShell脚本处理业务逻辑，使用CSV数据文件参数化，实现了高度仿真的压测脚本。

# 28. JMeter需要配置什么？

答题思路：展示工具使用细节经验。
参考话术：主要配置：1）线程组设置并发数和时间；2）HTTP请求头和参数；3）断言验证响应正确性；4）监听器收集结果。还会配置分布式压测和实时监控。

# 29. 数据怎么构造的？

答题思路：体现测试数据管理能力。
参考话术：采用三种方式：1）基础数据通过数据库脚本预埋；2）动态数据使用代码实时生成；3）参数化数据使用CSV文件管理。保证每次压测使用独立数据，避免脏数据影响。

# 30. 是自己捞数据吗？

答题思路：展示全流程负责态度。
参考话术：是的，我会直接查询数据库验证数据正确性，也会使用脚本批量生成测试数据。熟悉数据库查询和数据处理，确保测试数据的准确性和独立性。

# 31. 压接口时body怎么构造？

答题思路：体现接口测试细节经验。
参考话术：根据接口文档定义构造JSON body，使用变量参数化关键字段。比如下单请求：

{
  "product_id": "${product_id}", 
  "quantity": "${quantity}",
  "price": "${price}"
}

1
2
3
4
5

通过CSV文件或随机函数生成参数值。

# 32. 压测数据量控制多少？

答题思路：展示性能测试专业度。
参考话术：根据线上真实流量评估，通常从低到高逐步增加。单接口压测会达到1000+ TPS，全链路压测模拟峰值流量的120%，确保系统有余量支撑业务增长。

# 33. 压测时和开发沟通吗？

答题思路：体现团队协作和沟通能力。
参考话术：全程保持密切沟通。压测前一起评审方案，压测中实时共享监控数据，压测后共同分析瓶颈点。发现问题时能快速定位是应用代码、数据库还是基础设施层面的问题。

# 34. 压预发还是线上？

答题思路：体现线上安全意识。
参考话术：主要在预发环境压测，线上只会在业务低峰期进行小规模压测。预发环境配置尽量贴近生产，压测前做好数据隔离和应急预案，避免影响真实用户。

# 35. 线上不需要压测吗？

答题思路：辩证看待线上压测价值。
参考话术：线上压测能发现环境差异导致的问题，但风险较高。我们通过监控线上真实流量，在预发环境充分压测，结合链路追踪和日志分析，基本能模拟线上场景。

# 36. 自动化用什么语言写的？

答题思路：展示技术栈广度，体现代码能力。
参考话术：主要使用Python，熟悉Requests、Pytest、Selenium等生态圈。也了解Java和TestNG，能够快速上手不同技术栈的测试框架。

# 37. 现在有offer吗？

答题思路：诚实但保留余地，体现求职诚意。
参考话术：目前有几个在谈的机会，但还没有最终决定。我更看重团队氛围和技术挑战，贵公司的岗位和我职业规划非常匹配，希望能有机会加入。

# 38. 对工作有什么期望？

答题思路：展示职业规划和发展诉求。
参考话术：我希望加入一个技术驱动、重视质量的团队，能够在测试开发领域深入发展。期待参与复杂系统的质量保障工作，在提升研发效能方面发挥价值。

# 39. 在那边有级别吗？

答题思路：客观说明级别体系，不透露具体薪资。
参考话术：我们采用P序列专业职级，我目前是P6高级测试开发工程师，负责关键模块的质量保障和技术方案评审。

# 40. 你晋升过吗？

答题思路：体现成长性和成就动机。
参考话术：是的，去年刚从P5晋升到P6。主导完成了自动化测试平台建设，提升了团队整体效率，获得了优秀员工认可。

# 41. 接受加班吗？

答题思路：展现工作态度同时保持理性。
参考话术：我认同目标导向的工作方式，为保障项目上线愿意付出额外努力。但也注重工作效率，会通过自动化等手段减少不必要的加班，保持可持续的工作节奏。

# 42. 你有什么问题？

答题思路：准备有深度的问题，体现思考能力和求职诚意。
参考话术：我想了解：1）团队目前的质量保障体系是怎样的？2）测试开发工程师在项目中的具体职责和挑战？3）公司的技术成长体系和学习资源？

# 真题二

好的，这是按照您的要求格式化后的回答。

# 1. 怎么改善团队低迷现状

问题解析：此问题考察团队管理、激励和问题诊断能力。团队低迷可能源于目标不清、压力过大、缺乏认可或成长空间等。

答题思路：先诊断原因，再采取针对性措施，最后通过沟通和激励提振士气。

答题话术：

首先，我会通过一对一的深度沟通和团队匿名问卷，诊断出团队低迷的根本原因，是目标不清晰、工作负荷过重、缺乏成就感，还是团队协作出现了问题。
其次，针对不同原因采取行动：若是目标问题，就重新同步项目愿景，并将大目标拆解为可衡量、可达成的小里程碑；若是负荷问题，会协调资源、调整优先级或简化流程；若缺乏认可，会建立即时奖励机制，公开表扬个人和团队的贡献。
最后，我会组织技术分享、团队建设或培训活动，为团队注入新的活力和成长机会，并通过自身积极的态度来影响和带动整个团队的氛围。

# 2. 老板不懂技术，经常突然要东西，时间紧张，测试总背锅怎么办

问题解析：考察向上管理、沟通协调和风险规避能力。核心是如何管理非技术背景老板的期望并保护团队。

答题思路：通过透明化、数据化的方式管理期望，建立缓冲机制，避免硬碰硬，而是引导老板做出更优决策。

答题话术：

加强沟通，主动同步：我会定期向老板汇报测试进度和风险，用通俗易懂的比喻（如“盖楼需要打地基”）解释测试的必要性，让他理解研发和测试的基本流程。
提供选择，而非拒绝：当接到紧急需求时，我不会直接说“做不了”，而是列出选项：“如果今晚就要，我们可以先上主干功能，但会有X%的风险；如果给多1天时间，我们能覆盖核心场景，风险降为Y%”，让老板基于数据做决策。
引入流程缓冲：推动建立轻量级的快速需求评估机制，即使紧急需求也需经过PM、研发、测试负责人简单评估，明确范围、时间和潜在风险，并邮件确认，避免日后扯皮。
事后复盘：事后组织复盘，将因赶工产生的问题数据化地呈现出来，用事实推动流程的改进，逐渐减少此类情况。

# 3. 有能力有责任心的测试，仍然做不好自己的本职工作怎么办?

问题解析：此问题深入考察人员管理的精细度。员工有意愿但结果不好，问题可能出在方法、流程、协作或工具上。

答题思路：排除法，从最容易解决的问题入手。相信员工的意愿，帮助他扫清障碍，而不是质疑他的能力。

答题话术：

首先，我会和他进行一次坦诚的沟通，表达我对他责任心的认可，并表明我的目的是帮他解决问题，而不是指责，消除他的心理负担。
其次，我会和他一起复盘近期的工作，从多角度排查问题：是需求理解有歧义？还是测试用例设计方法有待提升？是使用的测试工具或平台效率低下？或者是跨部门协作中遇到了障碍？
然后，针对找到的原因，制定行动计划：如果是方法问题，安排导师辅导或推荐培训课程；如果是工具问题，协调资源优化工具或引入新工具；如果是协作问题，由我出面帮助厘清职责边界。
最后，我会定期跟进他的改善情况，及时给予反馈和鼓励，帮助他重拾信心。

# 4. 你最怕什么样的员工，你怎么分辨和改变他?

问题解析：考察管理价值观和应对棘手员工的能力。避免说怕能力差的，应关注态度和价值观层面的问题。

答题思路：选择一种对团队破坏性最大的负面特质，并阐述其危害、识别方法和改造策略。

答题话术：

我最怕的是“缺乏责任感、且传播负能量的员工”。因为能力可以培养，但消极的态度会像病毒一样感染整个团队，破坏信任和士气。
分辨方法：①看结果：工作总出纰漏且习惯性找借口；②观言行：经常抱怨、质疑目标却提不出建设性意见，在小组里散播悲观情绪；③听反馈：从同事和合作方那里听到关于他协作困难的评价。
改变策略：①我会第一时间与他一对一沟通，明确指出其行为对团队的影响，并给予清晰的改进期望；②安排他参与具体的、有挑战性的团队任务，在过程中给予积极反馈，帮助他重建责任感与成就感；③如果屡教不改，为了团队整体利益，我会果断地将其调离或劝退。

# 5. 你有没有做具体的执行，自动化框架是不是自己搭建的?

问题解析：考察技术深度、动手能力以及是纯管理还是技术管理出身。 honesty is the best policy.

答题思路：如实回答，但无论答案如何，都要体现出对技术细节的理解和掌控力。

答题话术：

“在我职业生涯的早期，我亲自搭建过公司的UI和接口自动化框架，并深入参与脚本编写。这使我对自动化的技术选型、架构设计和常见坑点有深刻理解。”
“随着职责转向管理，我直接编码和搭建框架的时间减少了，但我依然会参与技术方案评审、把握框架的设计方向和关键指标（如稳定性、覆盖率、ROI）。我要求自己必须能看懂代码，能与团队深入讨论技术实现，以确保决策的合理性。”
“我认为测试负责人不一定事事亲力亲为，但必须保持技术敏感度和判断力，这样才能更好地领导技术团队。”

# 6. 如何协调好每个员工的工作?怎样带动积极性与效率?

问题解析：考察任务分配、资源调度和团队激励的综合能力。

答题思路：协调工作靠流程和工具，带动积极性靠理解和激励。

答题话术：

协调工作：①明确目标：利用OKR等工具让每个人清楚团队目标和个人任务的价值；②合理分配：根据成员能力特长和成长诉求分配任务，用好项目管理工具（Jira/禅道）跟踪进度；③每日站会：快速同步进展、阻塞和下一步计划，确保信息透明。
带动积极性与效率：①给予ownership：让成员负责某个模块或领域，激发主人翁意识；②及时激励：不吝啬公开表扬，为优秀成果申请奖励；③提供成长：提供培训、分享和技术挑战的机会；④优化流程：消除不必要的会议和文档，提供高效工具，为他们赋能。

# 7. 有没有用过阿里云的什么，我没听过的技术构建?

问题解析：考察技术视野和对前沿技术的关注度，以及将云服务应用于测试实践的能力。

答题思路：如实列举，选择一两个最有代表性的说明应用场景和价值，展现学以致用的能力。

答题话术：

“有的。我们在测试中大量使用了阿里云的产品体系。
例如，我们使用函数计算FC来搭建低成本、高弹性的接口自动化测试执行环境，测试时自动拉起，执行完毕自动释放，极大节约了资源成本。
另外，我们利用性能测试服务PTS来模拟海量用户并发，进行全链路压测，它的分布式压测机和实时监控看板非常好用。
在安全测试方面，我们也调研过云安全中心的一些功能来辅助进行漏洞扫描和风险识别。”

# 8. 多个产品并行，产品上线后bug很多怎么办，上升到老板那里怎么办?

问题解析：考察危机处理、复盘分析和向上沟通的能力。核心是冷静应对、承担责任、拿出方案。

答题思路：立即止损 -> 深入复盘 -> 透明沟通 -> 长效改进。

答题话术：

紧急处理：首先，立即组织团队优先修复线上致命和高优先级的Bug，尽快发布补丁版本，将影响降到最低。
向上沟通：主动向老板汇报，不推诿责任。坦诚说明问题，并已经采取的紧急措施，同时汇报下一步详细的复盘和改进计划，争取他的理解和支持。
深度复盘：组织跨部门复盘会，从流程上找根因：是需求频繁变更未同步？测试用例遗漏？回归不全？还是上线流程有漏洞？用数据说话。
长效改进：针对复盘结果，推动流程改进：如加强冒烟测试准入标准、建立核心回归用例库、完善上线Checklist、或引入灰度发布机制，避免问题再次发生。

# 9. 如何做好质量规划?

问题解析：考察对质量保障体系建设的宏观思路。质量是规划出来的，不是测出来的。

答题思路：体现全程、全员的质量观，说明在每个阶段的质量活动和质量门禁。

答题话术：

质量规划不应在测试阶段才开始，而应贯穿整个项目生命周期。
项目初期：参与需求评审，明确质量目标和成功标准，识别风险点，制定《质量保障计划》，确定测试策略、范围、资源和进度。
开发阶段：参与技术方案评审，确保可测试性；推动单元测试、代码Review；提前准备测试用例并进行评审。
测试阶段：执行测试并持续反馈，不仅关注功能，还包括性能、安全、兼容性等非功能需求。
发布阶段：建立发布清单和回滚预案，进行上线前最后一轮冒烟测试。
发布后：监控线上反馈，用线上数据反哺测试用例的补充和优化，形成闭环。

# 10. 如何控制人员流失?

问题解析：考察团队保留和人才管理能力。核心是找到流失原因并系统性解决。

答题思路：预防大于补救，从薪酬、成长、心累、管理关系等关键维度入手。

答题话术：

控制流失的关键是预防，我会重点关注以下几点：
有竞争力的回报：确保团队薪酬福利在行业内具备竞争力，并主动为表现优秀的成员争取升职加薪。
清晰的成长路径：为每位成员制定个人发展计划，提供技术培训、业务培训和软技能培训，让他们看得到成长。
有价值的工作：尽量避免重复性劳动，通过自动化解放人力，让员工做更有挑战性和创造性的工作。
良好的工作氛围：打造开放、透明、互相帮助的团队文化，及时解决团队冲突，让员工干得舒心。
定期沟通：通过一对一沟通，及时了解他们的工作状态、困难和想法，将离职念头消除在萌芽阶段。

# 11. 9月1号提测的大型迭代，既要文档又要技术还要性能，9月10号必须上线。你会怎么安排?

问题解析：考察在极端时间压力下的项目管理、风险管理和资源协调能力。

答题思路：规避风险、优先排序、并行工作、寻求支援、管理期望。

答题话术：

风险前置：立即与开发、产品经理沟通，明确必须上线的核心功能范围，争取砍掉或推迟非核心需求。
测试左移：在开发阶段就介入：派测试人员参与代码评审，督促开发完成单元测试；性能测试团队提前准备压测脚本和环境。
并行与自动化：文档编写与功能测试并行；利用自动化脚本进行冒烟测试和回归测试，节省大量时间。
寻求资源：向公司申请临时人力支援，或将部分测试任务（如兼容性测试）外包。
每日站会：建立战时每日站会机制，极度透明地同步进度和风险，快速决策。
管理期望：明确告知各方，时间压缩意味着测试深度和广度的折衷，必须接受更高的线上风险，并制定好应急预案。

# 12. 经常遇到的软件问题类型有哪些，什么原因导致?

问题解析：考察测试经验和问题分析能力。需要对常见bug类型及其根源有归纳总结。

答题思路：分类别列举常见问题，并深入分析其背后的技术或流程原因。

答题话术：

功能逻辑错误：最常见。原因多是需求理解歧义、开发设计疏忽、或异常流程未考虑周全。
接口兼容性问题：前后端接口字段变更不一致、或跨系统集成时数据格式不匹配。
性能瓶颈：数据库慢查询、代码算法效率低、系统架构扩展性不足、或缓存使用不当。
界面UI问题：多浏览器、多设备兼容性不足，或UI设计与原型不符。
安全性问题：如SQL注入、XSS攻击等，源于开发人员安全意识不足，未对输入做严格校验。
重复性bug：修复一个bug引发另一个新bug，根源在于模块耦合度高且回归测试不充分。

# 13. 经常遇到的人员问题有哪些，与上下级如何有效合作?

问题解析：考察团队协作和沟通中的软技能，以及如何应对常见的人际挑战。

答题思路：分类阐述与上级、下级、平级合作中的问题和解决之道。

答题话术：

常见人员问题：①任务分配不均引发抱怨；②技术能力差异导致协作效率低；③个性冲突影响团队和谐；④员工缺乏主动性。
与上级合作：①主动沟通，理解他的目标和压力；②定期汇报进展和风险，不制造“惊喜”；③提出问题时，最好附带解决方案供其选择。
与下级合作：①明确目标和要求，给予充分授权和信任；②及时提供反馈和资源支持；③公平公正，关心他们的个人成长。
与平级（其他团队）合作：①建立畅通的沟通机制，如定期会议；②换位思考，寻求共赢方案；③遇到分歧，以事实和数据为依据进行讨论。

# 14. 你怎么做自动化的，遇到了哪些问题?

问题解析：考察自动化测试的实战经验，包括技术选型、实施策略和踩坑经验。

答题思路：阐述自动化策略、框架选型、实施过程，并分享遇到的具体挑战和解决方案。

答题话术：

如何做：①选型：基于技术栈（如Java+TestNG）和项目特点（Web/App/API）选择框架；②搭建：设计分层架构（基础层、用例层、数据层）；③切入：从API接口自动化开始，ROI最高，再逐步覆盖UI核心流程；④集成：融入CI/CD流水线，实现无人值守执行。
遇到的问题：①脚本稳定性：UI元素频繁变动导致脚本失败。解决：引入Page Object设计模式，降低维护成本。②环境依赖：测试环境不稳定影响结果。解决：推动环境容器化，保证环境一致性。③ROI不高：盲目自动化大量非核心用例。解决：建立自动化用例筛选标准，优先自动化回归核心场景。④数据构造：构造测试数据复杂。解决：开发数据工厂工具，简化数据生成。

# 15. 为什么有的项目质量好，有的项目质量差？质量差的根因是什么？

问题解析：考察对软件质量本质的理解。质量是过程决定的，而非测试环节。

答题思路：指出质量差的项目通常在流程、文化和协作上存在系统性问题。

答题话术：

项目质量的好坏，绝不仅仅是测试团队的责任，其根因通常在于：
流程缺陷：缺乏严格的需求评审和技术评审，开发过程中缺少单元测试和代码Review等质量内建活动，把“找bug”的压力全堆在测试最后阶段。
文化问题：团队缺乏质量意识，追求速度而牺牲质量，“先上线再修复”的思想盛行。
协作不畅：产品、开发、测试沟通不充分，需求变更频繁且传递失真，导致开发与预期不符。
管理缺失：项目经理对风险不敏感，没有为项目预留合理的技术债务偿还时间和测试时间。

# 16. 你是如何做质量管理的？如何控制质量？

问题解析：考察质量保障体系的建设思路，如何将质量管控融入整个开发流程。

答题思路：展现全流程的质量控制点，体现“质量是构建出来的，不是测试出来的”理念。

答题话术：

我的质量管理是贯穿整个研发周期的，核心是“预防”而非“检测”。
事前预防（测试左移）：参与前期评审，明确验收标准；推动开发进行单元测试、代码评审；通过Checklist和自动化手段保证测试环境与数据的可靠性。
事中控制：执行测试并及时反馈，但不止于发现bug，更深入分析bug根因，推动流程改进；通过过程 metrics（如缺陷密度、逃逸率）监控质量状态。
事后评估（测试右移）：监控线上质量 metrics（如千行代码bug率、线上事故数），用数据驱动测试策略的优化，形成闭环。

# 17. 你怎么控制项目的整体质量？如何要求别人？

问题解析：考察质量推动力和影响力。如何让其他人（尤其是开发）共同对质量负责。

答题思路：通过建立流程、设定标准、数据可视化和沟通协作来推动全员质量。

答题话术：

建立流程和标准：与开发团队共同制定质量门禁，如代码规范、单元测试覆盖率要求、提测准入标准等，并将这些标准工具化，成为CI流程中的强制关卡。
用数据说话：定期分享质量报告，如bug分布、修复时长、线上缺陷逃逸率等，让所有人直观看到质量现状和改进效果，从而重视质量。
沟通与协作：我不会用“要求”这个词，而是“协作”。我会与开发负责人共识质量目标，将测试人员早期嵌入开发小组，共同解决问题，而不是对立的关系。
赋能而非指责：为开发提供便捷的测试工具和培训，帮助他们提升自测能力，让他们能更容易地写出高质量代码。

# 18. 你平时遇到的软件bug最多的是哪些类别？为什么会集中出现这种问题的bug？

问题解析：考察对测试数据的分析能力和对项目风险的洞察力。

答题思路：结合过往经验分类，并分析其集中出现的深层次原因。

答题话术：

我遇到最多的类别是边界条件和异常流程处理的bug。
集中出现的原因：①开发过程中，开发者主要精力都集中在实现“happy path”（主流程）上，容易忽视边界和异常情况。②需求文档和设计文档对异常情况的描述也常常是模糊或缺失的。③代码Review和单元测试如果不够严格，也很难发现这类问题。
这提醒我们，在测试设计和评审时要特别关注边界值和异常场景，并推动开发在编写代码时加强这方面的逻辑处理。

# 19. 你怎样维护自己团队的关系，有什么技巧？

问题解析：考察团队建设和维护良好团队氛围的能力。

答题思路：从公平、透明、关怀、成长等多个维度分享具体做法。

答题话术：

公平公正：在任务分配、绩效评价和奖励激励上保持绝对公平，这是建立信任的基础。
透明沟通：保持团队内信息透明，定期同步团队目标、项目进展和公司动态，让大家有安全感和参与感。
真诚关怀：通过一对一沟通，关心成员的职业发展、工作困难和甚至个人生活，提供力所能及的帮助。
鼓励成长：为他们争取培训机会，鼓励技术分享和尝试新技术，支持他们的合理想法。
营造氛围：组织一些团建活动，鼓励团队互助，打造轻松、开放、积极的团队文化。

# 20. 你怎么管理团队的人员，有什么方法？

问题解析：考察人员管理的系统方法论。

答题思路：参考管理学经典框架，如选育用留，并结合测试团队特点展开。

答题话术：

我的人员管理遵循“选育用留”四个环节：
选：招聘时不仅看技术，更看重责任心、逻辑思维和团队协作能力。
育：为新员工指定导师；为每个人制定IDP（个人发展计划）；组织定期内部分享和技能培训。
用：根据各人特长和意愿分配任务，授予相应的 ownership，并给予足够的支持和授权。
留：提供有竞争力的薪酬；创造良好的成长空间和工作氛围；通过定期沟通及时了解动态，预防核心人员流失。

# 21. 你如何与上下级进行有效沟通？怎么与其他团队达成有效合作？

问题解析：考察职场中的沟通协作能力，这是管理者的核心软技能。

答题思路：分对象阐述沟通策略，核心是换位思考、目标一致和积极主动。

答题话术：

与上级：①理解他的核心目标和压力点；②汇报时结论先行，言简意赅；③提出问题时，准备至少两个解决方案供其决策。
与下级：①明确任务背景和目标，而非简单命令；②多倾听，鼓励提出不同意见；③及时给予具体、真诚的反馈（表扬与批评）。
与其他团队：①建立定期沟通机制，主动同步信息；②站在对方立场思考，寻求共赢方案，避免“甩锅”；③共同明确职责边界和对接人，减少推诿扯皮。

# 22. 客户反馈的问题，你们怎么处理？

问题解析：考察客户导向意识和问题处理流程的规范性。

答题思路：描述一个标准化的闭环处理流程，体现专业性和对客户的重视。

答题话术：

我们有一套标准的线上问题处理流程：
接收与分级：客服或产品经理接收反馈后，会根据问题的影响范围和严重程度进行定级（P0-P4）。
应急响应：对于致命问题（P0/P1），立即启动应急响应小组，研发和测试人员第一时间介入定位和修复。
排查与修复：测试团队协助开发复现问题、定位根因，并验证修复方案。
反馈与关闭：修复后，及时向客户反馈结果，并关闭问题工单。
复盘与改进：定期复盘线上问题，分析根因，是bug逃逸、需求误解还是其他，并据此补充测试用例、优化流程，防止再犯。

# 23. 定好的上线日期，结果测试拖了进度，你认为是什么原因导致？该如何解决

问题解析：考察对项目风险的预见性和问题分析解决能力。测试延期通常是表象，根因在前端。

答题思路：分析常见原因，并提出短期和长期的解决方案。

答题话术：

可能原因：①提测质量差，冒烟测试不通过，阻塞测试；②开发延期提测，但上线日期不变，压缩了测试时间；③需求变更频繁，测试范围蔓延；④出现重大阻塞性bug，修复和验证耗时过长。
短期解决：①评估剩余工作量，与PM和开发协商是延期上线、砍需求还是增加测试资源；②优先测试核心功能，简化测试流程；③加班赶工（应作为最后手段）。
长期根治：①建立提测准入标准，如必须通过冒烟测试；②加强持续集成，早集成早发现问题；③推动需求变更流程化，评估变更对测试的影响；④提升自动化回归能力，释放人力。

# 24. 你觉得组织项目完成的最大风险在哪里？

问题解析：考察项目风险识别和管理能力。应跳出纯技术视角，从更宏观的层面看问题。

答题思路：指出人员、流程、沟通等软性因素往往是比技术更难管理的风险。

答题话术：

我认为最大的风险在于沟通不畅和目标不一致。
技术难题通常总有解决方案，但如果项目组成员（产品、开发、测试、运维）对需求的理解不一致，或者团队之间缺乏信任、沟通低效，就会导致工作方向偏差、重复劳动、互相扯皮，最终严重拖慢项目进度甚至导致项目失败。
因此，我作为测试负责人，会非常注重在项目初期就确保所有人对需求的理解同步，并在项目中持续保持透明、高效的沟通。

# 25. 你的测试团队有5个团队，其中有一个团队有2个测试，一个高级、一个中级。在项目快尾声阶段，高级测试要离职。高级测试客户很满意。你怎么办？

问题解析：考察危机管理、客户关系和资源协调的综合能力。

答题思路：稳定军心 -> 保留知识 -> 保障项目 -> 安抚客户 -> 长远规划。

答题话术：

稳定团队：首先与中级测试工程师沟通，安抚情绪，肯定他的能力，明确表示我会支持他完成后续工作，并与他共同制定后续计划。
知识传承：请求高级测试人员在离职前，集中时间进行知识转移，包括核心业务逻辑、测试重点、客户关注点等，并详细文档化。
资源协调：从我管理的其他4个团队中，临时抽调一位资深测试专家（或我亲自）介入该项目，作为技术后盾，支持中级工程师完成收尾工作，并负责最终的质量把关。
客户沟通：主动与客户项目经理沟通，坦诚说明情况，但强调我们已制定了完备的过渡计划，确保项目质量和沟通不会受影响，争取客户的理解。
后续招聘：立即启动招聘，补充团队实力。

# 26. 如果一个测试，你分配了任务，他不执行怎么办？

问题解析：考察解决下属执行力的具体方法。

答题思路：先假设无辜原则（是不是没理解？有困难？），再了解原因，最后采取针对性措施。

答题话术：

我不会立即批评，而是先进行一对一沟通。
我会问他：“关于我上次分配的XX任务，我看进度有些延迟，是遇到了什么困难吗？还是对任务的要求有什么不清楚的地方？”
如果是有困难：我会帮他分析问题，协调资源，扫清障碍。
如果是有误解：我会再次清晰地阐明任务的目标、价值和具体要求。
如果是态度问题：我会明确表达我的期望，并严肃指出不执行任务对项目和团队的影响。如果多次沟通无效，我会考虑将其纳入绩效改进计划，并最终做出人员调整。

# 27. 性能测试的问题，你怎么建议研发修改？如果研发把问题推给了测试说是配置出了问题，你怎么处理？

问题解析：考察技术判断力、沟通能力和解决争议的技巧。

答题思路：用数据和证据说话，定位问题根因，保持专业和合作的态度。

答题话术：

如何建议：我会提供详尽的性能测试报告，包括：TPS/响应时间曲线、资源监控（CPU、内存、IO）图谱、以及通过Profiler工具抓取到的热点函数或慢SQL语句，让开发能快速定位到代码层面的瓶颈点。
应对推诿：①保持冷静，不陷入情绪对抗。②重现问题：在开发环境下，与开发一起复现问题，排除环境差异。③对比验证：如果开发怀疑是测试环境配置问题，我会提供一份标准的配置文档，并和他一起在测试环境和应用配置进行逐项核对。④数据说话：如果配置核对无误，我会出示监控数据，证明问题确实出在应用代码层面（如某个接口的CPU占用率异常高）。⑤共同目标：强调我们的共同目标是解决问题，而不是争论对错，我愿意协助他一起排查。

# 28. 数据库缓存，mysql缓存机制？

问题解析：考察数据库相关的技术基础知识。

答题思路：简要说明MySQL核心的缓存模块及其作用。

答题话术：

MySQL的缓存机制主要包括：
查询缓存（Query Cache）：缓存SELECT语句和其结果。但在高并发写场景下失效频繁，且MySQL 8.0已移除此功能。
缓冲池（InnoDB Buffer Pool）：这是最核心的缓存。用于缓存表数据和索引数据，所有的数据页读写都通过缓冲池进行，极大减少了磁盘IO，对性能至关重要。
此外，数据库性能优化还会涉及到应用层缓存（如Redis）来减少对数据库的直接访问。

# 29. 你们的规范是怎么制定与执行的？

问题解析：考察流程和规范的建设与落地能力。

答题思路：说明规范的产生过程（自下而上、共识）和执行保障（工具化、审查）。

答题话术：

制定过程：规范不是我一个人拍脑袋决定的。我们会成立一个虚拟小组，由各团队资深代表组成，共同讨论和制定初稿，然后全员征求意见，最终评审通过后发布。这样能确保规范的可执行性和大家的认同感。
执行保障：①工具化：将规范尽可能集成到工具中，如代码规范检查集成到Sonar，提测标准集成到Jira工作流，实现硬性约束。②培训宣贯：组织培训，让大家理解规范背后的原因。③定期审查：通过代码Review、用例评审、审计等活动检查执行情况，并与绩效适度挂钩。

# 30. 怎样利用测试用例来评价测试的初、中、高级？

问题解析：考察如何通过工作产出来量化评估人员能力。

答题思路：从用例设计的广度、深度、方法和效率等多个维度来区分不同级别。

答题话术：

初级工程师：能根据需求文档编写正向功能用例，覆盖主流程，但可能缺乏边界和异常场景的考虑。用例结构清晰，但深度不足。
中级工程师：能深入理解业务，设计的用例不仅覆盖功能，还涉及接口、兼容性等。能有效运用等价类、边界值等测试设计方法，考虑较全面。
高级工程师/专家：不仅考虑“点”，更考虑“面”。能从业务场景、用户画像、安全、性能等多维度设计用例。能发现需求中的漏洞，并能针对复杂系统设计高效的测试策略（如正交实验法）。他们还能指导和评审他人的用例，并推动用例的自动化和持续优化。

# 31. 你们是怎么进行用例评审的？

问题解析：考察质量控制流程的细节。用例评审是保证测试覆盖率和质量的关键活动。

答题思路：描述评审的参与人、流程、内容和后续跟进。

答题话术：

评审前：测试作者提前1-2天将用例发给相关人（产品、开发、测试同事），并注明评审会议的重点。
评审中：①作者先讲解测试策略和核心用例；②产品经理确认业务逻辑和场景覆盖是否完整；③开发人员关注异常流程和接口逻辑是否正确；④测试同事互相查漏补缺，交流测试设计方法。⑤记录所有评审意见。
评审后：测试人员根据记录修改用例，并在修改后邮件同步给所有评审人确认闭环。我们会将评审发现的缺陷数量和质量作为测试过程改进的度量之一。

# 32. 安全测试计划、与用例、怎样进行、问题反馈是样进行的？

问题解析：考察安全测试的流程和实践经验。

答题思路：按照测试活动的自然顺序（计划、设计、执行、反馈）来回答。

答题话术：

计划：在项目初期制定，明确测试范围（如OWASP TOP 10）、测试方法（工具扫描、手动渗透）、时间安排和所需资源。
用例设计：基于常见漏洞类型（SQL注入、XSS、CSRF等）设计测试用例，并参考安全测试用例库。
执行：结合自动化扫描工具（如AppScan、AWVS）和手动渗透测试，相互补充。
问题反馈：发现漏洞后，使用标准的漏洞管理平台（如Jira添加安全组件）提交报告，报告中需详细描述漏洞详情、复现步骤、风险等级和修复建议。并跟踪至修复验证完成。

# 33. 性能测试方案重点关注什么？

问题解析：考察性能测试的规划能力。方案是性能测试的蓝图。

答题思路：围绕性能测试的核心要素展开。

答题话术：

性能测试方案重点关注以下几点：
测试目标：明确性能指标，如响应时间（<=2s）、吞吐量（TPS）、并发用户数、系统资源利用率（CPU<70%）等。
测试场景：模拟真实用户操作，设计核心业务场景（如登录、下单）、混合场景和峰值场景。
测试环境：确保测试环境（硬件、软件、网络、数据）尽可能贴近生产环境。
数据准备：规划如何构造真实、大量的测试数据。
监控指标：确定要监控的系统指标（如服务器性能、数据库性能、JVM性能、中间件性能）和工具。
风险与应对：预估可能的风险（如环境不稳定、脚本问题）并制定应对策略。

# 34. 视频播放功能有哪些测试关注点？

问题解析：考察特定领域的测试设计能力。

答题思路：从功能、UI、性能、兼容性、异常等多个角度思考。

答题话术：

功能：播放/暂停/快进/快退/音量调节/全屏切换/清晰度切换、播放列表、字幕、播放历史记录等功能是否正常。
UI/UX：播放器控件布局、清晰度切换流畅性、全屏模式下的适配。
性能：首次缓冲时间、拖拽响应时间、不同网速下的播放流畅度、耗电量、CPU占用率。
兼容性：不同机型、不同操作系统版本、不同浏览器、不同视频格式（MP4/FLV/HLS）的兼容性。
异常：断网恢复后能否续播、播放过程中来电/锁屏、视频源失效或地址错误时的提示、低电量下的表现。
安全：视频地址是否可被篡改或盗链。

# 35. 有没有翻过墙？

问题解析：考察获取信息、学习新技术和解决问题的能力。

答题思路：如实回答，并强调其正当用途。

答题话术：

“有的。在工作中，访问Google、Stack Overflow、官方技术文档（如AWS、Kubernetes）和Github等网站是查找技术解决方案、学习前沿知识最高效的途径。这是技术人员拓宽视野、解决复杂问题的常用方式。”

# 36. Mysql的泛查询？

问题解析：考察SQL查询的基本功。

答题思路：解释什么是泛查询（模糊查询）及其语法和注意事项。

答题话术：

泛查询通常指模糊查询，使用LIKE关键字和通配符%（匹配任意多个字符）和_（匹配一个字符）。
例如：SELECT * FROM users WHERE name LIKE '张%'; 查询所有姓张的用户。
需要注意的是，%在字符串开头（LIKE '%xxx'）会导致索引失效，全表扫描，在大数据量下性能极差，应尽量避免。

# 37. 你是怎么组建测试团队的？

问题解析：考察从0到1搭建团队的战略思考和能力。

答题思路：按照规划、招聘、建流程、促文化的逻辑展开。

答题话术：

规划与定位：首先与业务领导沟通，明确团队的目标、职责和在项目中的定位（是成本中心还是价值中心）。
人才画像与招聘：根据业务需要，确定团队的人员结构（功能、自动化、性能、安全测试的比例），并据此招聘不同级别的成员，注重能力互补和文化契合。
建立流程与规范：搭建适合当前阶段的测试流程、工具链和规范（如用例编写、bug管理、自动化框架），确保团队高效运作。
文化建设：逐步塑造团队文化，如倡导质量意识、鼓励技术创新、形成分享互助的氛围。

# 38. 发现制定规则的人在破坏规则你会怎么办？

问题解析：考察处理棘手人际问题、维护规则严肃性的原则性和灵活性。

答题思路：先私下沟通了解原因，再视情况处理，核心是维护规则的公平性。

答题话术：

我会首先选择在私下场合，与该同事进行一次坦诚的沟通。
我会说：“我注意到我们制定的XX流程，这次好像有点例外。是流程本身有什么不合理的地方让你觉得执行困难吗？还是有什么特殊情况？”
如果流程不合理：感谢他的反馈，并邀请他一起讨论如何优化流程，使之更合理、更易于执行。
如果是个人行为：我会委婉但明确地指出，作为规则的制定者，我们的行为对团队有示范效应，破坏规则会让大家对规则失去信任，希望我们能一起带头遵守。
如果多次沟通无效，我会在更大的范围内（如团队会议）再次强调规则的重要性，并一视同仁地执行奖惩，维护制度的公平。

# 39. 如何处理下属的集体离职

问题解析：考察重大危机事件的应急处理和深度复盘能力。

答题思路：立即应对 -> 深入沟通 -> 紧急维稳 -> 长远根治。

答题话术：

紧急应对：第一时间向上级和HR汇报情况，争取支持。立即与每一位提出离职的员工进行一对一深度沟通，真诚倾听他们离职的真实原因（是薪酬、管理、工作内容还是团队氛围）。
稳定军心：召开团队会议，坦诚沟通（在不泄露个人隐私的前提下），稳定留下员工的情绪，明确接下来的工作安排和过渡计划，避免恐慌蔓延。
业务保障：快速评估业务影响，与上级协商调整项目优先级和排期，同时紧急启动招聘和内部调岗，补充人力。
根因复盘与改进：与HR一起，深刻反思管理上的问题，并制定切实可行的改进计划，防止类似事件再次发生。

# 40. 工作中最忌讳什么事？

问题解析：考察职业素养和价值观。

答题思路：选择一种对团队和个人职业发展危害最大的行为。

答题话术：

我认为最忌讳的是缺乏诚信和隐瞒问题。
比如：伪造测试报告、隐瞒已知的bug、为了赶进度而欺骗上级说“没问题”。这种行为一旦暴露，会彻底失去团队和上级的信任，而信任是合作的基石。工作中出现问题很正常，但隐瞒和欺骗会让小问题演变成无法挽回的大事故。

# 41. 手机移动端的性能测试做过哪些？有没有使用过什么工具？

问题解析：考察移动端专项测试的经验和工具链熟悉程度。

答题思路：列举关键性能指标和对应的主流测试工具。

答题话术：

移动端性能测试我们主要关注：
客户端性能：CPU占用、内存消耗、电量消耗、流畅度（FPS）、网络流量。我们使用的工具主要是 PerfDog（兼容iOS和Android）和 Android Studio自带的Profiler。
服务器端性能：虽然用户端是手机，但API接口的性能最终取决于服务器。我们会使用 JMeter 或 LoadRunner 对服务器接口进行压测。
我们会针对核心场景（如启动、首页加载、视频播放、大数据列表滑动）进行专项性能测试和监控。

# 腾讯

# 真题一

# 1. 自我介绍

问题解析：此问题是展示你个人品牌和与岗位匹配度的黄金时间。面试官希望听到一个结构清晰、重点突出、与JD高度相关的介绍。

答题思路：遵循“我是谁-我做过什么-我有什么亮点-我为什么能胜任这个岗位”的逻辑。时长控制在2-3分钟，突出技术管理能力、项目经验和核心成就。

答题话术：

面试官您好，我叫[你的名字]，有[X]年的软件测试工作经验，其中[Y]年是测试管理和团队领导经验。
我擅长构建高效的质量保障体系，精通自动化测试框架的设计与落地、性能测试分析与调优，以及复杂的项目质量风险控制。
在上一家公司，我带领[数字]人的团队，负责[产品领域]的质量工作。主导完成了从0到1的测试框架选型与搭建，将接口自动化覆盖率提升了[百分比]，并通过性能瓶颈定位与优化，成功支撑了[具体业务，如双11]活动期间[数字]倍的流量增长。
我深知测试团队的核心价值是为业务赋能和保驾护航，我对贵公司[提及对方业务]的方向非常感兴趣，相信我的经验能够为团队带来价值。谢谢。

# 2. 测试框架的搭建，选型？都调研过哪些框架？哪些框架符合你们的业务？其他框架有哪些优缺点？为什么选用这个框架？你的框架里面封装的哪些底层的方法？

问题解析：考察自动化测试的架构能力、技术选型思维和对行业技术的了解深度。

答题思路：展现系统性的选型过程，基于业务需求和技术特点做权衡，并证明最终选择的合理性。

答题话术：

选型过程：我们基于技术栈（Java）、团队技能、项目特点（以API测试为主，Web/App为辅）和社区活跃度进行选型。
调研框架：主要调研了RestAssured（API测试）、TestNG（测试管理）、Selenium（Web UI）、Appium（Mobile UI）和JMeter（性能/接口）。
优缺点与符合度：
- RestAssured：语法简洁，专为API测试设计，非常适合我们（后端微服务架构）。而JMeter脚本可读性和维护性较差。
- TestNG：比JUnit更强大，提供了更灵活的用例组织、依赖管理、数据驱动和并发执行能力。
- 我们的业务主要是API，所以优先选择了RestAssured + TestNG的组合，UI自动化作为补充。
框架封装：我在框架底层封装了：
- 通用请求方法：对HTTP Methods（GET/POST/PUT/DELETE）进行统一封装，处理通用Header、签名等。
- 动态参数构造：封装了从数据库或上游接口获取动态参数（如token、ID）的方法。
- 断言工具类：封装了针对JSON响应体的强大断言，支持JSONPath提取和复杂断言。
- 数据驱动引擎：封装了从Excel/YAML/JSON文件中读取测试数据和断言数据的方法。
- 日志与报告：集成ExtentReports或Allure，生成详细的可视化测试报告。

# 3. 每条用例的前置条件怎么处理的？比如说某个接口在测的时候，会依赖其他的一些接口，那你这个场景化用例是怎么做的呢？

问题解析：考察对测试数据管理和接口依赖处理的实战经验。

答题思路：阐述如何通过技术手段（封装、依赖注入）和管理手段（数据准备策略）解决依赖问题。

答题话术：

单一接口前置：对于需要登录态的接口，我们通过@BeforeClass或@BeforeMethod注解，先执行登录接口，将返回的token存入线程局部变量（ThreadLocal）或全局变量，供后续用例使用。
场景化用例：对于需要多个步骤串联的场景（如：创建数据->查询数据->校验数据），我们利用TestNG的dependsOnMethods属性来管理接口执行顺序，确保前置接口先执行，并可将其返回值传递给后续测试方法。
数据准备：对于更复杂的前置数据（如需要先创建一条订单），我们通常有两种做法：
- API准备：在用例前置部分直接调用创建订单的API，这是最主流和干净的方式。
- 数据库准备：极少数情况下，如果通过API创建非常耗时，我们会封装数据库操作工具类，直接向数据库插入预备好的数据。

# 4. 试算、核保都需要一些前置条件，前置条件怎么在excel里面实现的？就是说你的接口参数？

问题解析：考察数据驱动测试的具体实现，特别是如何设计测试数据。

答题思路：说明Excel中数据字段的设计，如何通过占位符或关键字实现动态参数传递。

答题话术：

在Excel中，我们会设计多个字段列来表示这些依赖关系。
例如，试算接口需要产品ID和保额。核保接口需要试算接口返回的报价ID。
我们的Excel可能会这样设计：
- 试算用例：product_id, amount, expected_premium
- 核保用例：quote_id, applicant_info, expected_result
这里的quote_id不会在Excel里写死，而是通过一个占位符来标识。在执行时，我们的数据驱动引擎会识别这个占位符，并从之前接口的响应结果（通常保存在一个上下文对象中）里提取出对应的值，动态替换到这个参数里，从而实现接口间的参数传递。

# 5. 所有的测试用例，前置和后置是怎么做的？

问题解析：考察测试用例的生命周期管理和数据清理的规范性。

答题思路：分层次（方法、类、套件）说明前置后置操作，并强调数据清理的重要性。

答题话术：

我们利用TestNG的注解机制和封装好的工具方法来处理前后置：
前置：
- @BeforeSuite/@BeforeTest：初始化全局配置，如读取配置文件、初始化数据库连接、准备全局测试数据。
- @BeforeClass：执行一些类级别的初始化，如用户登录、获取基础令牌。
- @BeforeMethod：执行方法级别的准备，如为当前用例生成特定测试数据。
后置：
- @AfterMethod：清理当前用例产生的脏数据，这是非常重要的一步，通常通过调用删除接口或执行数据库删除操作来实现，确保测试环境干净，不影响下一条用例。
- @AfterClass/@AfterSuite：关闭全局资源，如数据库连接、浏览器驱动等。

# 6. excel里面有哪些字段？

问题解析：考察测试用例管理的精细度和数据驱动设计的成熟度。

答题思路：列举关键字段，并说明其作用和设计理由。

答题话术：

我们的Excel模板主要包含以下字段：
用例基础信息：用例ID、用例名称、模块、优先级、描述。
请求参数：接口地址（URL）、请求方法（Method）、请求头（Headers）、请求参数（Params/Body）。
预期结果：预期状态码（StatusCode）、预期响应体（Expected Response）。
动态处理：提取表达式（如JSONPath），用于从响应中提取值供后续用例使用。
执行控制：是否执行（Run）、依赖用例（DependsOn）。
其他：作者、更新时间。

# 7. 自动化测试用例覆盖率是多少？你们是怎么评估的？整个自动化提升的效果是怎么样的？

问题解析：考察对自动化ROI（投资回报率）的衡量和效果评估能力。

答题思路：避免空洞地谈覆盖率数字，要结合业务核心，并用量化数据证明效果。

答题话术：

覆盖率：我们更关注核心业务场景的接口覆盖率，这个指标达到了[80%-90%]。我们不会盲目追求100%的UI自动化覆盖率，因为ROI太低。
评估方法：我们通过代码统计工具（如JaCoCo）统计后端接口被测试脚本调用的比例，来衡量接口覆盖率。
提升效果：效果主要体现在效率和质量上：
- 效率提升：回归测试时间从原来的[X]人天缩短到[Y]小时，版本发布频率提升了[Z]%。
- 质量提升：线上缺陷漏出率降低了[百分比]，因为每日构建的自动化测试能快速发现开发提交引入的回归问题。
- 人力解放：将测试人员从大量的重复回归中解放出来，更多地投入到新功能测试、探索性测试和专项测试中。

# 8. 涉及到支付问题的话，你们会关注哪些点，整个支付的流程是什么样的？

问题解析：考察对关键业务场景的测试设计深度和理解能力。

答题思路：先梳理支付的核心流程，再分点阐述测试关注点，体现全面性。

答题话术：

支付流程：用户提交订单 -> 选择支付方式 -> 跳转至支付网关（微信/支付宝） -> 用户输入密码完成支付 -> 支付网关异步通知我们系统 -> 我们系统更新订单状态为“已支付”。
测试关注点：
- 功能：支付成功、支付失败、支付中途取消、重复支付、退款流程。
- 金额：金额是否正确（包括折扣、优惠券）、小数精度问题。
- 安全：网络传输加密、防止重复提交（幂等性）、防篡改（签名验证）。
- 状态同步：支付成功後，订单状态、库存、用户权益等是否正确、及时地更新。
- 异常：网络超时、银行扣款成功但异步通知失败（如何对账补单）。

# 9. 在支付过程中，网络出问题了，或者有一些兼容性问题，调微信失败了，怎么处理？有模拟失败的这种场景吗？

问题解析：考察异常场景测试能力和Mock技术的应用。

答题思路：给出具体的模拟方案和技术手段，证明测试的深度。

答题话术：

模拟方案：有的，我们主要通过Mock Server和代理工具来模拟支付网关的各种异常返回。
- 在测试环境，我们会搭建一个Mock支付网关，它可以被配置成返回任何我们想要的响应，如超时、支付失败、签名错误等。
- 我们也会使用Charles或Fiddler这类代理工具，在请求发送到支付网关的路上，进行断点或映射，篡改返回结果，模拟网络异常或失败场景。
处理逻辑：我们需要验证在上述异常情况下，我们系统的行为：
- 是否有友好的用户提示？
- 是否启动了重试机制？（需要注意幂等性）
- 是否生成了正确的对账文件，以便后续人工或系统自动处理？

# 10. 支付流程的测试用例异常设计有哪些点？

问题解析：考察测试用例设计的思维广度和对风险点的识别能力。

答题思路：从用户、网络、系统、第三方等多个维度思考异常场景。

答题话术：

用户端异常：支付中途退出App、锁屏、来电中断、余额不足、密码输错次数超限。
网络异常：支付请求过程中断网、弱网（模拟支付请求超时）、切换网络（Wi-Fi/4G）。
系统端异常：支付时服务端重启、数据库连接失败、缓存失效。
第三方异常：微信/支付宝渠道繁忙、返回未知错误、异步通知延迟或丢失。
数据异常：金额为0或负数、订单号重复、订单已支付再次支付（幂等测试）。

# 11. 怎么模拟微信那边没有扣钱？

问题解析：考察对支付业务中“掉单”这种核心异常场景的测试方法。

答题思路：模拟支付网关通知失败的情况，并检查系统的后续处理机制。

答题话术：

这个场景模拟的是“银行已扣款，但异步通知未成功到达我们系统”的经典“掉单”问题。
模拟方法：在测试环境，当用户支付请求跳转到Mock支付网关后，我们让Mock网关模拟支付成功，但不向我们系统发送异步通知。
验证点：然后我们需要验证：
- 我们系统是否有主动查询的机制？即在一定时间后，由于没收到通知，系统会主动调用支付网关的订单查询接口来同步状态。
- 如果没有主动查询，那么日常的对账流程是否能发现这笔差异？系统是否能根据第二天的对账文件自动将订单补单为“已支付”状态？

# 12. 你对整个压测场景，包括整个容量评估，压力评估啊，你怎么去执行一些压测的一些计划？

问题解析：考察性能测试的全流程管理能力。

答题思路：按照性能测试的标准流程（目标->方案->准备->执行->分析->报告）来阐述。

答题话术：

明确目标：首先与业务、运营团队沟通，根据历史数据和未来增长预期（如促销活动），确定性能目标（如QPS、响应时间、并发用户数）。
制定方案：设计压测场景（混合场景、峰值场景、疲劳测试），确定需要监控的系统指标（应用、数据库、中间件、服务器）。
环境与数据准备：协调一个独立的、尽可能贴近生产的环境。构造符合生产数据量和分布规律的测试数据，这是压测成功的关键。
执行与监控：使用JMeter等工具执行压测脚本，并实时监控所有系统资源，观察系统性能曲线的变化。
分析与定位：发现性能瓶颈后，结合监控工具（APM、日志）定位问题根因，是代码问题、数据库问题还是架构问题。
优化与报告：协助开发进行优化，并回归测试。最后输出性能测试报告，给出系统容量评估和建议。

# 13. 压测目标怎么来的？

问题解析：考察性能测试的源头，目标是否以业务为导向。

答题思路：强调目标不是拍脑袋来的，而是基于业务数据和规划的。

答题话术：

压测目标主要来源于业务需求：
- 历史数据：分析生产环境监控系统（如Prometheus）的历史数据，找到日常和高峰时段的QPS、并发量作为基线。
- 未来增长：与产品运营讨论，明确未来一段时间（如半年）的业务增长预期和重大活动（如618、双11）的预期流量，通常是在基线基础上增加一定的倍数（如2-5倍）。
- 用户体验：结合用户体验要求，确定可接受的响应时间目标（如99%的请求在200ms内完成）。

# 14. QPS和TPS的区别？

问题解析：考察对基本性能指标概念的清晰理解。

答题思路：从定义和应用层面解释两者的区别与联系。

答题话术：

QPS：Queries Per Second，每秒查询率。主要指一台服务器每秒能够响应的查询次数，通常用于衡量一个简单的读操作。
TPS：Transactions Per Second，每秒事务数。一个事务可以包含多个请求/查询。
区别与联系：在一次Web请求中，用户点击一个按钮（一个事务/T），可能会向后端发起多个API调用（多个查询/Q）。因此，TPS更偏向于从业务角度衡量系统处理能力，而QPS更偏向于从系统接口层面衡量。对于一个简单的查询接口，TPS ≈ QPS。对于一个包含多个步骤的复杂业务事务，1个TPS可能对应N个QPS。

# 15. 你的压测数据、压测参数怎么实现的？在线上压还是测试环境压？

问题解析：考察压测的实践细节和安全意识。

答题思路：详细说明数据构造的方法论，并坚决强调不能在线上压测。

答题话术：

压测环境：绝对不能在线上环境压测！我们是在独立的预生产环境进行，其硬件配置、网络架构、软件版本都尽可能与生产环境保持一致。
数据构造：
- 总量：通过数据库脚本或数据工厂工具，生成与生产环境数据量级（如表记录数）相当的数据。
- 分布：数据不能是均匀的，要模拟真实的数据分布（如热点数据），例如使用梯形函数或随机函数来构造用户ID、商品ID等参数，避免所有请求都落在少量数据上，导致缓存失效，测试结果失真。

# 16. 压测数据会对你的压测性能会有哪些影响呢？为什么要做这个数据构造呢？

问题解析：考察对性能测试本质的理解，数据是性能测试的核心之一。

答题思路：阐述不良数据如何导致假象，以及良好数据如何真实反映性能。

答题话术：

巨大影响：压测数据直接影响结果的真实性。
不良数据的影响：如果数据量太小或分布不均匀，会导致：
- 数据库缓存失效：所有请求都命中数据库，无法反映生产环境有缓存时的真实性能。
- 结果过于乐观：测出的QPS会远高于实际水平，上线后可能瞬间崩溃。
数据构造的目的：就是为了真实模拟生产环境的负载，让数据库查询、缓存命中率、索引效率、磁盘IO等行为都和线上一致，这样压测得到的性能数据和瓶颈才有参考价值。

# 17. 线程阻塞指什么？你是怎么发现出来线程阻塞的？你是怎么一步步分析出来的？排查了哪些问题？具体哪个地方有线程阻塞呢？（我说了线程dump，定位到代码级别）

问题解析：考察深层次的性能问题排查和故障定位能力。

答题思路：展现一个从现象到根因的完整排查链路，体现技术深度。

答题话术：

线程阻塞：指线程因为某些原因（如等待锁、等待IO、等待网络响应）无法继续执行，处于等待状态，浪费了系统资源。
发现与排查步骤：
1. 现象：压测时TPS上不去，CPU使用率也不高。
2. 监控：通过APM工具（如Arthas）或jstack命令多次打印应用的线程堆栈快照（thread dump）。
3. 分析：将thread dump导入分析工具（如fastthread.io），发现大量线程状态为BLOCKED或WAITING。
4. 定位：分析工具会指出这些线程在等待哪个锁（synchronized关键字或Lock对象），并定位到持有该锁的线程和代码行。
5. 根因：最终发现是在一段同步的数据库操作代码，或者一个效率低下的同步方法上发生了锁竞争。解决方案是优化代码，减小锁的粒度或改用并发容器。

# 18. 数据库连接数是一个什么样的概念？面试官说现在都是连接池

问题解析：考察对数据库基础架构和连接池原理的理解。

答题思路：解释连接数的含义，并重点说明连接池如何管理它。

答题话术：

数据库连接数：指应用程序与数据库之间建立的TCP连接数量。每个连接都会消耗数据库和服务器的内存和CPU资源。
连接池的作用：正因为创建和销毁连接成本很高，所以我们使用连接池（如HikariCP, Druid）。
连接池管理：连接池在启动时会创建一定数量的连接并维护起来。当应用需要操作数据库时，直接从池中获取一个空闲连接，用完后归还，而不是直接关闭。这样就避免了频繁创建和销毁的开销。
关键配置：连接池需要配置最大连接数，这个值需要根据压测结果来设置，设置过小会导致请求等待连接而阻塞，设置过大会耗尽数据库资源。

# 19. 你在以前的工作中有除了自动化、性能，还有哪些亮点？就是说有什么除了你之外，其他人做不了的

问题解析：考察你的独特价值和核心竞争力，是展示差异化的好机会。

答题思路：选择一个能体现你技术深度、业务理解或创新能力的项目或举措。

答题话术：

我认为我的一个核心亮点是将质量保障活动深度融入到DevOps流程中，实现了质量门禁的自动化。
具体来说，我推动并落地了一套“质量红线”系统：在CI/CD流水线中，集成了代码规范检查、单元测试覆盖率强制要求（如低于80%则构建失败）、核心接口自动化用例集。任何代码提交想要合并上线，必须自动通过这些关卡。
这件事需要同时具备技术架构能力（熟悉Jenkins/GitLab CI、脚本编写）、流程推动能力和与开发团队协商的软技能。它从根本上提升了提交代码的质量，将问题发现时机大幅左移，这是单纯写用例或执行测试无法达到的效果。

# 20. 开发自测有哪些效益呢？

问题解析：考察你对“质量是构建出来的”这一理念的理解，以及推动流程改进的能力。

答题思路：从效率、质量和成本多个角度阐述开发自测的好处。

答题话术：

推动开发进行有效的自测，效益非常显著：
- 提升效率：开发在本地就能发现并修复大部分低级bug，减少了后期与测试的来回沟通和bug修复成本，缩短了交付周期。
- 提高质量：bug在开发阶段就被fix，其修复成本远低于流转到测试甚至线上阶段。这是一种质量左移，能显著降低线上缺陷率。
- 增强责任感：让开发对自家代码的质量负起首要责任，改变了“我编码，你测试”的旧观念，培养了全员质量意识。

# 21. 他测不测你怎么衡量？

问题解析：考察如何量化管理流程，确保规范落地。

答题思路：给出可量化的监控指标，而不是凭感觉。

答题话术：

我们会通过一些客观的数据指标来衡量：
- 提测质量：统计版本首次提测时，冒烟测试通过率。如果通过率低，说明开发自测不充分。
- Bug数据：分析Bug的引入阶段和发现阶段。如果发现大量本该在单元测试或编码阶段发现的Bug流转到了系统测试阶段，就说明自测环节薄弱。
- 流程卡点：我们将单元测试覆盖率、静态代码扫描结果作为CI流水线的强制门禁，不达标则无法合并代码，从流程上强制保障。

# 22. 冒烟测试不通过，打回之后，对开发本人有什么影响？

问题解析：考察流程的严肃性和如何通过机制保障执行力。

答题思路：说明打回是一种常态化的质量管控机制，并与绩效等挂钩。

答题话术：

首先，我们会明确规定“冒烟测试不通过，测试有权直接打回”，这是一个硬性规则。
影响：打回意味着开发需要重新修改代码、自测、再提测，这直接耽误了他自己的开发进度。
后续：我们会统计每个开发人员或团队的“版本首次提测打回率”，并将这个指标纳入他们的月度或季度绩效考核中。这样就将质量与个人的绩效直接关联，从而有效地驱动开发做好自测。

# 23. 你们公司这个流程规范是什么样的呢？

问题解析：考察你对完整研发流程的理解和规范化管理能力。

答题思路：按时间顺序描述从需求到上线的全过程，并突出测试在每个阶段的活动和价值。

答题话术：

我们公司推行的是敏捷开发与DevOps相结合的流程：
1. 需求阶段：测试参与需求评审，从可测试性和用户体验角度提出建议。
2. 开发阶段：测试参与技术方案评审；开发编写单元测试并完成自测；测试编写测试用例并进行评审。
3. 提测阶段：开发提测需通过冒烟测试（测试提供冒烟用例集）。
4. 测试阶段：测试执行测试、提交Bug；每日站会同步进度和风险。
5. 发布阶段：上线需通过QA验收，并严格执行上线Checklist和回滚预案。
6. 发布后：监控线上反馈，进行线上Bug复盘，并更新回归测试用例库。

# 24. 你有什么要问我的？

问题解析：考察你的求职动机、对公司的兴趣以及思考深度。

答题思路：提出问题要围绕团队、技术、业务和发展，展现出你的积极性和长远考虑。

答题话术：

（问团队）：“我想了解一下，测试团队目前的组织架构是怎样的？以及这个岗位在团队中的具体职责是什么？”
（问技术）：“团队目前的技术栈和常用的测试工具链是怎样的？在未来一年，团队在技术建设方面有哪些规划？”
（问业务）：“您能否分享一下，目前团队面临的最大挑战是什么？您希望这个岗位的人来帮助解决什么问题？”
（问发展）：“公司对于技术人员的职业发展路径是如何设计的？是否有相应的培训或晋升机制？”

# 字节

# 真题一

# 1. 自我介绍

答案：
我叫[你的名字]，有[年限]年测试开发经验，专注于测试自动化、性能测试和测试平台开发。熟悉Python、Django、Vue.js及相关测试工具（如pytest、Selenium、JMeter）。在上一家公司，我主导了测试平台的从0到1建设，提升了团队效率。

答题思路：

简要介绍背景、技能和主要成就。
突出与岗位匹配的经验（如自动化、性能测试）。
保持简洁，避免冗长。

话术：
"面试官您好，我叫XXX，有X年测试开发经验，擅长自动化测试和性能优化。在上一家公司，我主要负责测试平台开发和自动化框架设计，通过引入工具链和流程优化，帮助团队提升了XX%的测试效率。"

# 2. 最近一份工作项目介绍、职责

答案：
最近项目是公司内部的测试管理平台，集成用例管理、自动化执行和性能测试。我的职责包括：

需求分析和架构设计。
后端开发（Django+REST框架）。
前端Vue组件开发。
自动化测试框架集成（pytest+Jenkins）。
推广培训和后续优化。

答题思路：

说明项目目标和核心功能。
明确个人角色（开发、设计、推广等）。
突出技术栈和成果。

话术：
"我负责的测试平台主要解决团队用例管理和自动化执行问题。我牵头完成了后端API设计和前端模块开发，并集成CI/CD。上线后，团队用例执行效率提升了30%。"

# 3. 项目的业务流是怎么样的？后台技术架构有了解吗？

答案：
业务流：用户通过前端创建用例→触发自动化执行→生成报告→归档分析。
后台技术架构：

Django REST Framework提供API。
Celery处理异步任务（如测试执行）。
MySQL存储数据，Redis缓存队列。
Jenkins调用测试任务。

答题思路：

描述用户操作到结果输出的流程。
分层说明后端组件（Web框架、数据库、异步机制）。

话术：
"业务流是用户通过Web界面操作，后端通过Django处理请求，Celery调度异步任务，数据存MySQL。架构上采用了分层设计，保证可扩展性。"

# 4. 介绍一下Django搭建平台的功能、技术架构

答案：
功能：用例管理、任务调度、报告生成。
技术架构：

Django + DRF（REST API）。
Vue.js前端，Axios请求。
MySQL数据库，Redis缓存。
Celery+RabbitMQ异步任务。
Nginx部署，Docker容器化。

答题思路：

分功能模块和技术栈介绍。
强调架构选型理由（如Django高效、Vue响应式）。

话术：
"平台用Django快速搭建REST API，Vue做前后端分离，Celery处理耗时任务。这样保证了系统可维护性和性能。"

# 5. 平台操作数据库使用的是什么？

答案：
使用MySQL作为主数据库，Django ORM操作数据；Redis缓存热点数据（如任务状态）。

答题思路：

直接回答数据库类型和工具（ORM）。
补充缓存使用场景。

话术：
"主要用MySQL存储结构化数据，Django ORM简化查询；Redis缓存频繁访问的数据，减少数据库压力。"

# 6. 前端使用 VUE，说下父子组件之间传值怎么做的？

答案：

父传子：通过props传递数据。
子传父：通过$emit触发事件，父组件监听。

示例：

// 父组件
<Child :data="parentData" @update="handleUpdate"/>
// 子组件
props: ['data'], 
methods: { sendData() { this.$emit('update', data) } }

1
2
3
4
5

答题思路：

说明两种传值方式。
简单代码示例增强理解。

话术：
"父组件用props向下传值，子组件用$emit向上传递事件。这是Vue的典型数据流，保证组件解耦。"

# 7. 说下你平台前端的跨域问题怎么解决的？

答案：
后端Django配置CORS：

安装django-cors-headers包。
设置CORS_ORIGIN_ALLOW_ALL=True（开发环境）或白名单。

答题思路：

说明跨域原因（前后端分离不同端口）。
提供解决方案（后端配置CORS）。

话术：
"因为前后端分离部署，浏览器会跨域拦截。我们在Django中通过cors-headers包添加HTTP头允许跨域访问。"

# 8. 平台或者框架在公司里面怎么推广的？

答案：

内部培训：演示使用方法和优势。
文档支持：编写详细指南和FAQ。
试点团队：先小范围试用，收集反馈优化。
集成流程：与CI/CD绑定，强制使用。

答题思路：

分步骤说明推广策略。
强调沟通和迭代优化。

话术：
"我们先找核心团队试点，通过培训让用户熟悉工具，然后逐步推广到全公司。过程中持续收集反馈，优化体验。"

# 9. 你在搭建平台过程中遇见过什么难题？怎么解决的？

答案：
难题：高并发测试任务导致Celery阻塞。
解决：

调整Celery worker数量和队列优先级。
引入Redis作消息队列，提升吞吐量。

答题思路：

选择典型技术难题。
说明解决方法和效果。

话术：
"遇到过任务堆积问题，通过优化Celery配置和引入Redis分发任务，解决了性能瓶颈。"

# 10. 你说提高了效率，提高了多少？怎么算出来的？

答案：
效率提升40%，计算方式：

之前：手动执行用例平均耗时2小时/人天。
之后：平台自动执行耗时0.5小时/人天。
公式：(2-0.5)/2 * 100% = 75%（但保守说40%包括其他流程优化）。

答题思路：

用具体数据对比。
说明计算逻辑（时间/人力节省）。

话术：
"通过统计手动和自动执行的时间差，算出节省了40%的人力成本，同时减少了人为错误。"

# 11. 说下你 0-1 接口自动化的过程？问了技术选型、框架设计等问题

答案：
过程：

技术选型：pytest+requests+Allure（轻量易扩展）。
框架设计：分层（用例层、数据层、工具层）。
集成CI：Jenkins定时执行。
报告生成：Allure可视化。

答题思路：

分阶段说明从选型到落地。
强调设计原则（可维护、可扩展）。

话术：
"从零开始选用pytest做核心，封装请求工具，数据驱动测试。最后集成到Jenkins，每天自动执行并发报告。"

# 12. 失败重试的功能怎么实现的？

答案：
使用pytest的插件：

pytest-rerunfailures，添加--reruns n参数。
或自定义重试装饰器（如@retry(times=3)）。

答题思路：

说明工具或自实现方法。
简单示例。

话术：
"通过pytest-rerunfailures插件实现，失败时自动重试3次，减少环境波动带来的误报。"

# 13. pytest 参数化方式有哪些？

答案：

@pytest.mark.parametrize：直接参数化。
从JSON/YAML文件读取数据。
使用pytest_generate_tests钩子动态生成。

答题思路：

列举常见方式。
说明适用场景。

话术：
"最常用的是parametrize装饰器，也支持从文件加载测试数据，适合数据驱动测试。"

# 14. 自动化测试执行的策略是什么？

答案：

触发式：代码提交后CI自动触发。
定时执行：每天夜间回归。
手动执行：按需测试特定模块。

答题思路：

分场景说明执行方式。
强调自动化与手动结合。

话术：
"我们采用CI触发为主，结合每日定时执行，保证及时反馈，重要版本还会手动补充测试。"

# 15. 自动化测试数据怎么管理？为什么这样做？

答案：

独立JSON/YAML文件存储测试数据。
数据库初始化脚本准备环境数据。
原因：数据与代码分离，易于维护和复用。

答题思路：

说明数据存储方式和工具。
解释分离的好处（易维护、可读性）。

话术：
"测试数据放在外部文件中，用脚本自动初始化，这样避免硬编码，方便多人协作修改。"

# 16. 提高 UI 自动化稳定性

答案：

显式等待替代隐式等待（WebDriverWait）。
使用更稳定的定位器（如CSS选择器）。
页面对象模型（PO）减少代码耦合。
异常截图和日志记录。

答题思路：

列举常见稳定性措施。
强调等待机制和设计模式。

话术：
"通过显式等待元素加载、用PO模式封装页面，以及失败时截图，显著提升了UI自动化稳定性。"

# 17. 怎么加快 UI 自动化的执行效率

答案：

并行执行：Selenium Grid或pytest-xdist。
无头模式（Headless Chrome）。
减少不必要的操作（如跳过登录复用Cookie）。

答题思路：

从并行、浏览器模式、流程优化角度回答。
举例说明。

话术：
"使用pytest-xdist并行执行用例，并配置Headless模式，速度提升了60%以上。"

# 18. Python 字典和列表的区别

答案：

字典：键值对，无序（Python3.7+有序），查找快（O(1)）。
列表：有序序列，通过索引访问，查找慢（O(n)）。

答题思路：

对比数据结构、特性和性能。
举例使用场景。

话术：
"字典用键访问值，适合快速查找；列表按顺序存储，适合有序数据遍历。"

# 19. Python *args和**kwargs的区别

答案：

*args：接收可变位置参数（元组）。
**kwargs：接收可变关键字参数（字典）。

示例：

def func(*args, **kwargs):
    print(args)  # (1,2)
    print(kwargs) # {'a':3}
func(1,2,a=3)

1
2
3
4

答题思路：

解释参数类型和用途。
代码示例说明。

话术：
"args用于非关键字参数，kwargs用于关键字参数，常用来设计灵活的函数接口。"

# 20. Python 的深拷贝和浅拷贝

答案：

浅拷贝：copy.copy()，只复制顶层对象。
深拷贝：copy.deepcopy()，递归复制所有嵌套对象。
示例：列表嵌套时，浅拷贝修改嵌套元素会影响原对象。

答题思路：

说明区别和风险。
举例嵌套结构的影响。

话术：
"浅拷贝只复制一层，深拷贝完全独立。处理嵌套结构时常用深拷贝避免意外修改。"

# 21. Python 装饰器及实际使用场景

答案：
装饰器：在不修改原函数基础上添加功能（如日志、鉴权）。
示例：

def log_time(func):
    def wrapper(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        print(f"Time used: {time.time()-start}")
        return result
    return wrapper

@log_time
def test():
    pass

1
2
3
4
5
6
7
8
9
10
11

答题思路：

定义+代码示例。
列举常见场景（性能监控、权限检查）。

话术：
"装饰器像包装纸，比如我们用它记录函数执行时间，或者检查用户权限，代码更整洁。"

# 22. 说一下 Python 单例模式

答案：
确保类只有一个实例，如数据库连接池。
实现方式：

使用__new__方法控制实例创建。
或通过模块导入（Python模块天然单例）。

答题思路：

说明目的和实现方法。
举例应用场景。

话术：
"单例模式保证全局唯一实例，比如配置管理类。我们通过重写__new__方法实现。"

# 23. 说下迭代器和生成器

答案：

迭代器：实现__iter__和__next__的对象，惰性计算。
生成器：用yield返回的函数，自动实现迭代器协议。

示例：

def gen(n):
    for i in range(n):
        yield i

1
2
3

答题思路：

对比概念和实现。
强调生成器的内存优势。

话术：
"生成器是简化的迭代器，用yield按需生成值，节省内存，适合处理大数据流。"

# 24. Django和 flask 的区别

答案：

Django：大而全（ORM、Admin、认证内置），适合复杂项目。
Flask：微框架，灵活扩展，适合轻量级应用。

答题思路：

从功能、适用场景对比。
根据项目需求选型。

话术：
"Django开箱即用，快速开发；Flask更自由，适合定制化高的项目。"

# 25. 列表反转有哪些方法快速实现

答案：

list.reverse()：原地反转。
reversed(list)：返回迭代器。
切片：list[::-1]。

答题思路：

列举多种方法。
说明区别（是否生成新列表）。

话术：
"最简单的是切片[::-1]，或者用reverse()原地反转，根据是否需要新列表选择。"

# 26. 给一个列表，进行去重，保证元素位置顺序不变

答案：
使用字典键有序特性（Python3.7+）：

def dedupe(items):
    seen = set()
    return [x for x in items if not (x in seen or seen.add(x))]

1
2
3

或直接list(dict.fromkeys(list))。

答题思路：

利用集合检测重复，保持顺序。
提供代码示例。

话术：
"用字典键不可重复且有序的特性，dict.fromkeys()可以快速去重并保留顺序。"

# 27. 说一下你们的性能指标是怎么制定的？

答案：

业务需求：如TPS（每秒事务数）、RT（响应时间）。
历史数据：参考线上日志。
资源阈值：CPU<80%，内存<90%。
用户共识：与产品、开发讨论确定。

答题思路：

说明指标来源（业务、技术、历史）。
强调团队协作制定。

话术：
"指标基于业务场景（如登录TPS≥100），结合系统资源限制，和开发一起评审确定。"

# 28. 性能测试数据、性能场景设计怎么准备的？

答案：

数据：通过脚本生成真实数据（如用户信息）。
场景：
- 基准测试：单用户验证功能。
- 负载测试：模拟峰值流量。
- 压力测试：直到系统崩溃。

答题思路：

分数据和场景说明。
强调模拟真实性。

话术：
"用Python脚本批量构造测试数据，场景设计包括梯度增加压力，观察系统瓶颈。"

# 29. 压测服务的架构是什么样

答案：

控制机：JMeter Master调度任务。
压力机：多台Slave生成流量。
监控：Prometheus+Grafana监控服务器指标。
测试目标：隔离的预发环境。

答题思路：

描述分布式压测架构。
包括监控和隔离措施。

话术：
"我们用JMeter分布式压测，Master控制多台Slave，同时监控目标服务器资源，确保结果准确。"

# 30. 最近一次性能测试的指标是多少？TPS、RT、压测工具线程数

答案：
项目：用户登录接口。

TPS：1200。
RT：95%请求<200ms。
线程数：500并发（JMeter）。

答题思路：

提供真实数据（可调整）。
说明场景和结果。

话术：
"最近测登录接口，500并发下TPS达到1200，响应时间在200ms内，满足预期目标。"

# 31. 性能测试过程遇到过什么性能问题？怎么分析的？

答案：
问题：数据库慢查询导致RT突增。
分析：

监控数据库CPU和慢日志。
发现未索引的查询语句。
优化SQL后重测恢复正常。

答题思路：

描述典型问题。
说明分析工具和解决步骤。

话术：
"通过监控发现数据库CPU飙高，排查慢日志找到问题SQL，添加索引后性能提升50%。"

# 32. 使用jmeter压测发现，接口响应每隔一段时间响应一次，也不报错？说下分析思路

答案：
可能原因：

服务端资源回收（如GC）。
中间件（如数据库连接池刷新）。
网络波动。
分析：

监控服务器GC日志和资源使用。
检查中间件配置。

答题思路：

列举可能原因。
提供排查方向。

话术：
"先检查服务器GC情况，再确认中间件（如Redis）是否有定期任务，逐步定位问题源。"

# 33. 在浏览器输入一个网址到页面展示出来，这个过程经历哪些处理

答案：

DNS解析：域名→IP。
TCP三次握手建立连接。
HTTP请求（SSL握手如果HTTPS）。
服务器处理并返回响应。
浏览器解析HTML/CSS/JS，渲染页面。

答题思路：

分网络、服务器、浏览器阶段。
简要说明关键步骤。

话术：
"从DNS解析开始，经过TCP/IP连接、HTTP传输，服务器处理返回数据，浏览器最后渲染展示。"

# 34. 举例说下你项目的推动能力？

答案：
案例：推广测试平台时，开发团队有抵触。
推动方式：

沟通价值：减少重复工作。
试点演示：现场解决问题。
上级支持：争取管理层认可。

答题思路：

选择协作推动的实例。
体现沟通和解决问题能力。

话术：
"有的团队不愿改用新平台，我通过演示自动化收益和一对一支持，最终让他们主动推广使用。"

# 35. 对于有截止时间的项目，发现开发提测之后问题比较多、还有功能未完成，你会怎么做？

答案：

立即沟通：与开发确认未完成功能的原因和计划。
风险评估：告知项目经理延期风险。
调整测试策略：先测核心功能，阻塞问题优先跟进。
加班/加人：保证进度。

答题思路：

体现主动沟通和风险管控。
提出应对措施。

话术：
"我会第一时间拉通开发确认进度，优先测试主干功能，同时向上汇报风险，争取资源确保项目按时交付。"

# 36. 对于用户反馈线上出现很多问题，你可以做那些工作？

答案：

紧急响应：复现问题，定位原因。
临时解决：回滚或热修复。
复盘改进：
- 加强测试覆盖（尤其是回归测试）。
- 引入自动化检查。
- 优化发布流程（如灰度发布）。

答题思路：

分短期和长期措施。
强调预防机制。

话术：
"先快速解决线上问题，然后复盘根因，比如补充自动化用例，避免类似问题再发生。"

# 小米

# 真题一

好的，这是一个非常深入的技术面试，涵盖了Python底层、操作系统、数据库、测试等多个领域。我将按照您的要求，以Markdown格式为您逐一解答。

# 1. 之前已经面过一轮了，你这边有什么感想或者疑问，可以先聊聊？

答案：这是一个双向交流的好机会。可以表达对上一轮面试的良好感受，并提出一些有深度、能体现你思考和对职位兴趣的问题。

答题思路：

感想：简要积极回应，表示交流愉快或对技术讨论印象深刻。
疑问：提出2-3个精心准备的问题，问题方向可以包括：
- 团队与技术：了解团队结构、技术栈、当前面临的挑战。
- 业务与规划：了解产品未来发展方向、测试在其中扮演的角色。
- 个人发展：了解岗位的期望、团队的学习成长文化。

话术： “上一轮和面试官交流得非常愉快，特别是关于[提及上轮一个具体技术点，如测试平台架构]的讨论，让我很有收获。我这边有几个小问题想请教一下：

咱们测试团队目前的规模和架构是怎样的？大家是如何分工协作的？
我了解到咱们在自研仿真软件，这是一个非常棒的方向。想了解一下这个3D仿真项目目前的技术挑战和测试重点是什么？
这个岗位对于候选人的长期期望是什么？希望他在未来一年内为团队带来哪些价值？”

# 2. 你对扫地机器人有了解吗？

答案：是的，有一定的了解。扫地机器人是一种集成了环境感知、路径规划、运动控制等技术的智能家用设备。其软件系统通常包括：

SLAM（即时定位与地图构建）：核心算法，用于构建环境地图并实时定位自身位置（分为LDS激光雷达和VSLAM视觉导航两种主流方案）。
路径规划算法：基于地图，规划高效、无遗漏的清扫路径（如弓字形、沿边清扫）。
障碍物识别与避障：通过传感器（激光、视觉、超声波）和AI算法识别鞋子、电线、宠物粪便等障碍物并规避。
人机交互：通过APP、语音等进行控制，查看清扫地图和状态。

答题思路：

表明你并非完全陌生，概述其作为“智能硬件”的核心技术模块。
提到关键术语（如SLAM）会显得更专业。
将话题引导到面试官提到的“仿真软件”上，表示出兴趣。

话术： “是的，我有关注过这类产品。扫地机器人的核心在于它的‘大脑’，也就是SLAM算法和路径规划能力。它通过传感器感知环境，构建地图并规划出最优清扫路径。所以我非常理解咱们需要通过仿真软件来对这些复杂的算法进行大量、高效的测试和验证，这比直接测试实体机器人成本更低、效率更高。您刚才提到2D和3D仿真，这应该就是分别针对激光SLAM和视觉VSLAM算法的测试环境吧？”

# 3. Python内存管理（内存池还有垃圾回收介绍下）？

答案： Python的内存管理是一个分层体系，主要由内存池机制和垃圾回收机制两大部分组成。

内存池机制：
- 目的：为了避免频繁地向操作系统申请和释放小块内存，造成性能开销。
- 原理：Python对于小整数、小字符串等小对象（通常小于256KB），会直接从预先申请好的内存池中分配。这个内存池维护了多个大小等级（如8、16、24...字节）的内存块链表。当需要分配内存时，从对应的链表上取一块；释放时，再放回链表。这样就大大提升了小对象内存分配的效率。
垃圾回收机制：
- 目的：自动回收不再使用的对象所占用的内存，防止内存泄漏。
- 原理：以引用计数为主，并辅以标记-清除和分代回收来解决循环引用问题。
  - 引用计数：每个对象都有一个计数器，记录有多少引用指向它。当引用数为0时，立即回收。
  - 标记-清除：解决容器对象（如列表、字典）循环引用导致无法被引用计数回收的问题。它分为两个阶段：标记所有可达对象，清除所有未被标记的不可达对象。
  - 分代回收：基于“年轻对象很快会死，老对象存活更久”的假设。将对象分为0，1，2三代。新对象在第0代，经历一定次数的垃圾回收后仍存活，就移到下一代。分代回收允许垃圾回收器更频繁地检查年轻代对象，减少每次检查的代价。

答题思路：

先总述，再分点详细解释两个机制的目的和原理。
对于垃圾回收，要清晰说明三种机制的关系：引用计数是主力，标记清除和分代回收是辅助，解决其短板。

话术： “Python的内存管理设计得很精巧，主要分两层。第一层是内存池，它像是一个‘内存批发市场’，专门高效地管理小块内存的分配和释放，避免零碎操作OS。第二层是垃圾回收，它主要是引用计数，一发现对象没人用了就立刻回收。但光有这个不够，比如两个对象互相引用，但外界都没用了，引用计数就不为0，这就内存泄漏了。所以Python又加了标记-清除来处理这种‘循环引用’，再用分代回收来优化性能，只频繁检查那些‘大概率快死了’的新对象。”

# 4. Python内存池中使用什么数据结构或者什么形式去管理内存块的？内存池本身是怎么样的，是说先预留了一块内存，后续根据需求再去扩充还是怎么样的？

答案：

数据结构：内存池使用多个单向链表来管理内存块。每个链表专门负责管理一种特定大小的内存块（例如，8字节的链表、16字节的链表、24字节的链表……直到256字节）。这种结构称为“空闲列表分配器”。
内存池本身：
- Python在初始化时，会预先向操作系统申请一大块连续的内存空间（称为arena）作为内存池的“仓库”。
- 当程序申请小块内存时，分配器就从对应大小的链表中取出一块空闲内存。如果链表为空，分配器会从arena中切出一段新的内存块，并加入到链表中。
- 当arena被用尽时，Python会再次向操作系统申请新的arena来扩充内存池。这个过程对Python对象来说是透明的。

答题思路：

具体化数据结构是“多个不同尺寸的空闲链表”。
解释内存池的初始化、分配、扩充流程。

话术： “内存池内部是用一个数组来维护多条空闲链表，每条链表对应一种尺寸的内存块。内存池在启动时就会先向操作系统‘批发’一大块内存（arena）。当我们需要申请内存时，比如要28字节，系统会向上取整到32字节，然后就去32字节的那条链表上取一块。如果链表空了，就从之前‘批发’来的那块大内存里切一块新的出来，挂到链表上。如果‘批发’来的内存也用光了，那就再向OS‘批发’一次，就这样动态扩充。”

# 5. 内存池是每个python进程有一个？还是每个线程都有一个？有没有想过有什么方法去优化这个内存池？比如多线程编程，有很多线程同时需要申请内存，可能存在瓶颈的情况，这方面有考虑过有什么方法去优化吗？

答案：

** per-process & per-thread**：在CPython中，内存池（即PyMalloc）是每个进程一个。但是，为了应对多线程环境下的锁竞争问题，Python引入了线程本地内存池的概念。
- 每个线程都拥有自己本地的一些小块内存池（用于非常小的分配）。
- 当线程需要分配内存时，它会先在自己的本地池中操作，这样就避免了和其他线程竞争全局锁。
- 只有当本地池不足时，才会去申请全局锁，从进程的全局内存池中申请一大块内存作为新的本地池。
优化思路：面试官提到的“排队、限流”策略，在Python中对应的就是上述的线程本地存储策略。这本质上是一种减少锁竞争的优化方案。通过让每个线程大部分时间操作自己独立的内存区域，将全局锁的竞争概率降到最低，从而提升多线程内存分配的效率。

答题思路：

首先纠正一个误区：不是纯全局或纯线程，而是“全局池+线程本地缓存”的二级结构。
直接点明Python已经采用了这种优化，并解释其如何解决锁竞争问题。

话术： “问得非常好，这正是多线程编程的经典问题。Python的内存池是每个进程一个，但它已经做了优化来处理您说的这个瓶颈。它的方法是给每个线程都设置一个本地的内存缓存。线程要内存时，优先从自己的‘小金库’里拿，这样就不用和别人抢锁。只有‘小金库’空了，它才需要去申请全局锁，从进程的大仓库里批一大块回来充实自己的‘小金库’。这种‘线程本地存储’的策略就是Python应对多线程内存分配瓶颈的核心方法，效果类似于您说的把‘排队’冲突降到了最低。”

# 6. 垃圾回收机制真正在回收的时候，你刚刚讲到的那3种机制，有没有什么使用策略（是说先使用哪个机制再使用哪个，还是同时掺杂着使用）？

答案：它们不是按顺序先后使用的，而是协同工作、各有侧重的策略：

引用计数是时刻都在进行的基础机制。每当一个对象的引用关系发生变化（如被赋值、被删除）时，它的计数就会更新。一旦发现计数为0，就立即回收。这是最快、最及时的回收方式。
标记-清除和分代回收是配套使用的，它们是为了解决引用计数无法处理的循环引用问题，并且不是随时触发的。
- 它们的触发有一个阈值，当Python分配的对象数量减去释放的数量超过某个阈值时，垃圾回收器才会启动。
- 启动后，默认先检查第0代对象。如果这次回收后，第0代幸存对象数量大于某个值，就触发对第1代的检查，以此类推。
- 标记-清除是“做什么”（标记和清除不可达对象），而分代回收是“对谁做”和“何时做”的策略（主要对年轻代做，很少对老年代做）。

答题思路：

强调引用计数的实时性和后两者的周期性。
解释后两者触发的条件（阈值）和执行策略（分代）。

话术： “它们是分工合作的。引用计数是‘急诊医生’，24小时值班，随叫随到，处理立刻就能回收的垃圾。而标记-清除和分代回收是‘巡检大队’，它们定期出动，专门处理‘急诊医生’搞不定的疑难杂症（循环引用）。出动频率由分代回收策略控制，只盯着最可能出问题的新生代对象频繁检查，对‘老员工’对象就查得少，这样效率最高。所以不是先后的关系，是实时和周期性、普通情况和特殊情况互补的关系。”

# 7. python中想手动触发一次垃圾回收机制可以吗，有尝试过这种操作吗？

答案：可以。通过gc模块的collect()函数即可手动触发一次完整的垃圾回收（主要是标记-清除和分代回收过程）。

使用场景：

性能测试和调试：在运行一段可能产生大量临时对象或循环引用的代码后，手动触发GC，并计算回收的内存大小，用于分析代码的内存使用情况。
解决特定内存问题：在长时间运行的服务器程序中，有时会在一个批处理任务结束后手动触发GC，以便及时释放可能存在的循环引用垃圾，避免内存占用峰值过高。

话术： “可以的，通过import gc; gc.collect()就可以手动触发。我在之前做性能剖析的时候用过。比如写一个脚本批量处理数据，跑完一段逻辑后我会手动调用一下gc.collect()，然后看回收了多少内存，这样能帮我判断这段代码是否存在不必要的内存滞留或者潜在的循环引用问题。但在正常业务代码里很少用，因为Python的自动回收策略已经足够智能了。”

# 8. python多线程有用过吗？

答案：用过。但由于CPython的GIL（全局解释器锁） 的存在，Python的多线程无法利用多核CPU优势来并行执行CPU密集型的代码（因为GIL要求任何线程执行字节码前必须先获得这把锁）。

适用场景：因此，Python的多线程更适用于I/O密集型的任务，例如：

网络请求（爬虫、调用API）
文件读写
数据库操作

在这些场景中，线程在等待I/O操作完成时会释放GIL，从而让其他线程得以运行，提高了程序的并发处理能力。

话术： “经常使用。但我对它的理解是，在CPython中由于GIL的存在，多线程更适合I/O密集型的任务，比如同时发起多个网络请求或者处理多个文件。线程在等待IO的时候会释放锁，这样其他线程就能接着跑，整体效率就高了。如果是计算密集型的任务，我会改用multiprocessing多进程来绕过GIL，真正利用多核。”

# 9. 线程之间的同步有了解吗，比如两个线程任务都要同时去数据库取一笔数据，这个情况要怎么处理？锁的机制

答案：这个问题更准确的描述是：如果两个线程要同时修改同一笔数据，需要同步机制来防止数据混乱。如果只是“读取”，通常不需要同步。

处理方法：使用锁机制。

是什么：锁（threading.Lock)是一种同步原语，一次只允许一个线程进入被锁保护的代码段（临界区）。
如何做：
- 在访问共享资源（如数据库的某条记录）前，线程先acquire()获取锁。
- 获取成功后，执行修改操作。
- 操作完成后，release()释放锁，让其他线程可以获取。
为什么：这样可以确保在同一时间，只有一个线程在修改数据，避免了数据竞争和不一致的结果。

话术： “您说的这个场景，如果只是读数据，多个线程同时读是没问题的。但如果是要更新同一条数据，那就必须用锁来保证线程安全。具体做法是，在代码里 critical section 之前先获取锁lock.acquire()，等操作完数据库、提交事务之后再释放锁lock.release()。这样就强制了同一时间只有一个线程能执行这段更新逻辑，避免了数据写错乱。Python的threading模块提供了Lock、RLock这些工具来做这个事情。”

# 10. python中的协程coroutine有了解吗？

答案：有了解。协程是比线程更轻量级的并发编程方式，可以理解为用户态的、由程序员协作调度的“微线程”。

核心概念：

async/await：Python3.5+的关键字，用于定义异步函数(async def)和在异步函数中等待(await)一个耗时的I/O操作完成。
事件循环：作为总调度器，负责在单个线程内调度和执行多个协程任务。当一个协程遇到await去等待时，事件循环会挂起它，转而执行其他就绪的协程。
优势：极高的并发性能。因为它没有线程切换的开销，且能在I/O等待时自动切换任务，用很少的资源（一个线程）就能处理成千上万的网络连接。非常适合高性能Web服务器、爬虫等场景。

话术： “是的，协程是Python处理高并发I/O的利器。它通过async/await语法来声明，核心是一个事件循环。我写一个协程函数，在遇到网络请求这类IO操作时就用await挂起，这时事件循环就会去执行别的协程。等IO数据回来了，事件循环再回来继续执行。这样在一个线程里就能实现超高的并发，比如用aiohttp写爬虫效率就非常高，因为它几乎没有线程创建和切换的成本。”

# 11. 有遇到python内存爆掉的吗？主要是想了解有没有因为python进程申请内存一直增加，然后被系统强制干掉，有没有分析过这方面内存增加的一些原因之类的实际经验？

答案：遇到过。Python进程内存无限增长直至被OOM Killer kill掉，通常不是Python本身的问题，而是代码编写不当导致的。

常见原因及分析手段：

循环引用： container对象（list, dict, class实例）之间相互引用，且不再被外部使用，由于引用计数不为0，无法被立即回收，只能等待标记清除。如果产生的速度大于回收的速度，内存就会增长。分析：使用gc模块的gc.set_debug(gc.DEBUG_LEAK)来辅助定位，或使用objgraph库可视化对象引用关系。
全局变量或缓存无限膨胀：例如用一个全局的list或dict不停地追加数据，从未清理。分析：查看代码中全局数据结构的生命周期。
C扩展模块内存泄漏：如果使用了第三方C扩展，可能是它内部存在内存泄漏。分析：注释掉可疑扩展代码或更换版本来排查。

话术： “确实遇到过。一次是我们有一个后台服务，内存缓慢增长最后被系统干掉了。我们先用ps命令持续监控它的RSS内存变化，确认是持续增长。然后我们怀疑是循环引用，就用objgraph这个库画出了内存中数量增长最快的对象的引用链，最后发现是一个第三方库的事件监听器没有正确注销，导致很多对象无法被回收。还有一次是一个缓存字典没有设置大小限制，业务量一大就把内存撑爆了。所以经验就是：对于缓存要用functools.lru_cache或者自己设置上限；对于可能产生循环引用的复杂对象，要留意其生命周期，或者用weakref弱引用。”

# 12. Linux三剑客？

答案：指grep、sed、awk这三个强大的文本处理命令行工具，常结合管道|使用。

grep：查找。用于在文本中搜索匹配指定模式的行。
sed：编辑。一种流编辑器，用于对输入流（文件或管道）进行基本的文本转换（如替换、删除、插入）。
awk：分析报告。更强大的编程式文本处理工具，尤其擅长处理结构化文本（如日志、CSV），能按列处理数据、进行计算和生成报告。

话术： “Linux三剑客是grep, sed, awk。我几乎每天都会用。比如查日志：grep 'Error' app.log 过滤错误行；用 awk '{print $1}' 提取第一列（比如IP地址）；或者用 sed -i 's/foo/bar/g' file.txt 批量替换文件里的文本。awk功能最强，我常用它来做数据统计，比如分析Nginx日志的PV和UV。”

# 13. 性能监控指令？

答案：最常用的是top（及其增强版htop）和vmstat。

top/htop：综合性实时监控。可以动态查看系统概况（负载、CPU、内存使用率）和各个进程的资源占用情况（PID、CPU%、MEM%、TIME+等）。
vmstat：虚拟内存统计。vmstat 2 5（每2秒采样一次，共5次）可以查看进程、内存、交换分区、IO块和CPU活动的详细信息。它对分析系统瓶颈非常有用。

其他常用命令：

iostat：监控磁盘IO
netstat/ss：监控网络连接
free -h：查看内存和交换分区使用情况
df -h：查看磁盘空间使用情况
pidstat：监控特定进程的详细资源使用

话术： “我最常用的是top和vmstat。top是第一反应，先看整体负载和哪个进程最耗资源。如果想看更详细的上下文切换、内存换页、磁盘阻塞队列这些指标，就会用vmstat 2来定时采样。如果是磁盘IO问题，会用iostat -x 1看%util和await；如果是网络问题，会用ss -tlnp看连接状态。”

# 14. cpu监控字段里有total、cache、available、free等这些，你知道他们的区别吗？

答案：这些是free命令或/proc/meminfo中看到的内存指标，不是CPU字段。

total：物理内存总大小。
free：完全未被使用的内存大小。这个值通常很小，因为Linux会利用空闲内存做缓存。
cache：被用作磁盘缓存的内存大小。这部分内存可以被应用程序立刻回收使用。
available：估算的、可供应用程序使用的内存大小。它是 free 内存加上大部分可回收的cache内存。这是评估内存是否充足的最重要指标。

话术： “您这里指的应该是内存监控的字段。free是完全闲置的内存，意义不大。cache是系统拿来加速磁盘读写的，这部分内存需要时可以马上还给应用程序。最关键的是available，它才真实反映了系统还剩多少内存能给新程序用。所以看内存压力，主要看available的值是不是充足，而不是看free。”

# 15. 查表查的慢有什么优化方法？添加索引，面试官还介绍了一个方法，就是mysql中有个缓存的配置设置，可以设置增大缓存，默认很小（128M），如果专门用来做数据库，可以设置成1/4的内存。

答案：是的，除了最常用的添加合适的索引，还有多种优化手段：

优化SQL语句：避免SELECT *，检查是否有导致索引失效的写法（如对索引列做运算、函数处理，使用!=，OR等）。
调整数据库配置：
- 增大缓冲池：如面试官所说，调整innodb_buffer_pool_size（InnoDB引擎最重要的参数），将其设置为机器物理内存的50%-80%。这样可以将数据和索引缓存在内存中，极大减少磁盘IO。
- 调整其他参数，如query_cache_size（但注意在MySQL 8.0中已被移除）、sort_buffer_size等。
读写分离和分库分表：对于数据量极大、并发极高的场景。

话术： “您说的对，加索引是第一步。其次就是优化SQL本身，避免全表扫描。然后就是调整数据库参数，您提到的增大innodb_buffer_pool_size 非常关键，相当于给数据库配了一个‘内存硬盘’，热数据都放里面，速度自然就快了。我们之前确实会把专用于数据库的服务器这个值调到物理内存的60%左右。如果再往上，就要考虑架构层面的比如读写分离了。”

# 16. 自己搭的数据库，测试时候导入的数据量级是怎样的？千还是万级别等等

答案：根据测试类型不同，数据量级也不同。

功能测试/接口自动化：千/万级别足以覆盖大多数业务逻辑测试。
性能测试/压力测试：需要百万级甚至千万级的数据量，才能真实模拟生产环境的数据体积，测出数据库在高压下的性能表现、索引效果和SQL瓶颈。

话术： “这要看测试目的。如果是功能测试和日常的接口自动化，我们一般造几千到几万条数据就够了，主要是验证逻辑正确性。但如果是做性能压测，我们一定会造百万级以上的数据。因为数据量太小，SQL执行可能都在内存里，完全发现不了真实环境下可能出现的慢查询和磁盘IO瓶颈。我们的性能测试数据量级都是尽量向生产环境看齐的。”

# 17. Web端、H5测试时关注的点有哪些？链接测试工具有想过自己去写工具测试出死链接吗？

答案： Web/H5测试关注点：

功能：业务流程、表单提交、数据校验、交互逻辑。
UI/UX：布局、兼容性（不同浏览器、手机机型分辨率）、易用性。
性能：页面加载时间（白屏时间、首屏时间）、网络请求耗时、渲染性能。
安全：XSS、CSRF、数据传输是否加密（HTTPS）。
交互：手势操作、与原生App的交互（如果嵌入在WebView中）。

死链接测试工具：想过并且完全可以实现。Python有非常成熟的库（如requests用于同步，aiohttp用于异步）和HTML解析库（如BeautifulSoup）来快速编写一个爬虫工具。

思路：递归地爬取页面，提取所有<a>标签的href属性，然后用HTTP客户端去请求这些链接，根据状态码（4xx, 5xx）判断是否为死链。
优势：自定义工具可以更好地集成到CI流程中，或者针对公司内部网站的结构进行特定优化。

话术： “Web/H5测试除了基本功能，我特别会关注多端兼容性、页面性能指标和安全性。关于死链接测试，这是一个非常典型的自动化场景。我确实想过并且可以用Python写一个。思路就是用requests和BeautifulSoup，从一个入口URL开始，爬取所有页面上的链接，然后并发地去检查每个链接的HTTP状态码。这种工具不仅可以找出死链，还能生成一个完整的站点地图报告，完全可以集成到CI里每晚自动跑。”

# 18. 工作内容？仿真软件中自动化测试用例的编写、有余力，可以去搞白盒测试相关。

答案：这是一个陈述句，是面试官在向你介绍岗位的工作内容。你的回答应该表示出理解、认可和兴趣。

话术： “我明白了。工作的核心是围绕咱们自研的仿真软件，编写自动化测试用例来验证扫地机器人的各种算法和行为。这非常吸引我，因为它结合了我对自动化和智能硬件的兴趣。同时我也很乐意听到公司鼓励深入技术，有余力时可以参与白盒测试。我对代码底层实现很感兴趣，如果能从代码层面去设计更精准的测试用例，或者和开发同学一起进行代码评审、单元测试覆盖率的提升，我觉得能对产品质量带来更大的价值。”

# 19. 测试人员规模和架构？

答案：这是一个需要你向面试官提出的问题，用于了解团队情况。

话术： “我想了解一下，咱们整个测试团队大概的规模是怎样的？是如何分工的呢？比如是否有同学专门负责自动化框架、有人负责性能专项、有人负责业务线测试？这样我能更清楚地了解我如果加入，在团队中的定位和协作方式。”

← HR面试题互联网中厂 →