# 银行金融

# 招商银行真题一

# 1. 自动化是用什么工具开发的脚本？

答题思路：
说明自动化测试使用的技术栈和工具，强调选择理由和实际应用效果。

话术：
我们主要使用Python语言开发自动化脚本，结合Pytest测试框架和Requests库处理HTTP请求。选择Python是因为其语法简洁、生态丰富，Pytest提供了灵活的用例管理和丰富的插件（如Allure报告），Requests则简化了接口调用。此外，我们会使用Jenkins进行持续集成，定时执行脚本并通知结果。这套工具链高效稳定，覆盖了90%的接口测试需求。

# 2. 用例写了多少条？

答题思路：
给出大致数量，并说明覆盖范围和优先级，体用例管理的有效性。

话术：
目前积累了约800条自动化用例，覆盖核心业务模块（如贷款申请、还款计划计算等）。其中70%是接口用例，20%是数据校验用例，10%是异常场景用例。我们遵循“核心优先”原则，确保关键路径100%覆盖，非核心功能按需补充。

# 3. 一条用例对应脚本的规模？

答题思路：
从代码行数和逻辑复杂度描述典型用例的规模，体现脚本设计的合理性。

话术：
一条典型用例的脚本规模在10-30行代码之间。包括：

请求参数构造（如JSON body）
发送请求并获取响应
2-5个断言验证
我们强调脚本简洁性，避免过度封装，确保可读性和维护性。

# 4. 验证点在脚本里怎么体现的？

答题思路：
说明断言的使用方式和验证内容，体现测试的严谨性。

话术：
验证点通过**断言（Assert）**体现，主要包括：

状态码验证：assert response.status_code == 200
业务码验证：assert response.json()["code"] == "SUCCESS"
关键字段值验证：如贷款金额、利息计算结果
数据库一致性验证：查询数据库比对数据是否正确落地
我们会在关键业务点添加多重断言，确保数据准确性。

# 5. 结合业务详细说一下断言怎么实现的？

答题思路：
以贷款业务为例，说明断言如何验证业务规则和数据逻辑。

话术：
以贷款还款计划生成为例：

调用还款计划接口，获取JSON响应；
断言总期数：assert len(repayment_plan) == 12（假设12期）；
断言每期本金之和：assert sum(plan["principal"] for plan in repayment_plan) == loan_amount；
断言利息计算公式：验证首期利息=剩余本金×利率/365×天数；
断言还款状态：首期应为UNPAID，已还期数为PAID。
通过这些断言确保业务规则和财务计算的准确性。

# 6. 一条用例里面有几个断言？

答题思路：
给出典型数量范围，并解释为什么需要多个断言。

话术：
一条用例通常包含3-5个断言。例如测试贷款申请接口：

状态码=200；
业务码=SUCCESS；
返回贷款ID非空；
数据库贷款状态为“审核中”；
生成了一条风控记录。
多断言确保接口返回、业务状态和数据一致性全部正确。

# 7. 说一下贷款的状态都有哪些？

答题思路：
列举常见贷款状态及其流转，体现业务理解深度。

话术：
贷款状态主要包括：

申请中（PENDING）：提交申请未审核
审核中（UNDER_REVIEW）：风控审核中
已批准（APPROVED）：通过审核待放款
已拒绝（REJECTED）：审核未通过
放款中（DISBURSING）：资金划拨中
已放款（DISBURSED）：资金到账，开始计息
还款中（REPAYING）：部分还款
已结清（SETTLED）：全部还清
逾期（OVERDUE）：未按时还款
坏账（BAD_DEBT）：长期未回收

# 8. 关于还款金额和逻辑计算做过功能测试吗？

答题思路：
肯定回答，并举例测试方法和场景，体现财务测试的严谨性。

话术：
是的，详细测试过。我们会：

等额本息计算：验证每期本金+利息之和是否相等；
提前还款：测试罚息计算和本金减少是否正确；
逾期还款：验证逾期利息和违约金计算；
数据源核对：与业务规则文档和财务Excel计算模板比对，确保分毫不差。

# 9. 还款方式还款逻辑是在那个系统里面进行处理的？

答题思路：
说明系统架构，指出核心系统负责计算，外围系统负责触发和展示。

话术：
还款逻辑计算主要在银行核心系统（Core Banking System）中处理，因为它涉及账户余额更新、利息计算和账务处理。外围系统（如贷款管理系统或手机银行APP）负责发起还款请求和展示还款计划，但实际计算由核心系统完成，确保数据一致性和准确性。

# 10. 能理解银行外围系统和核心系统的区别吗？

答题思路：
对比两者的功能和特点，体现对银行IT架构的理解。

话术：

核心系统：处理核心账务（存、贷、汇）、会计记账、利率计算，强调事务性和数据一致性，通常采用大型机或分布式数据库。
外围系统：处理渠道接入（APP、网银）、业务管理（贷款申请、客户管理），更侧重业务流程和用户体验。
外围系统通过API或消息队列与核心系统交互，保证核心系统稳定高效。

# 11. 说一下贷款到还款的大概的流程？

答题思路：
按步骤描述端到端流程，突出关键节点和状态变化。

话术：

申请：客户提交贷款申请，系统进行风控审核；
审批：审核通过生成合同，客户电子签约；
放款：核心系统划拨资金到客户账户，生成还款计划；
还款：客户通过渠道还款，核心系统扣款并更新本金利息；
结清：还清后更新状态为结清，释放信用额度。
过程中涉及核心、风控、支付等多个系统协作。

# 12. 测一个贷款业务里面金额的准确性，会设计什么样的用例或场景来覆盖？

答题思路：
从边界值、计算规则、异常场景等多维度设计用例。

话术：

正常场景：验证等额本息/等额本金每期金额计算正确；
边界值：测试最小贷款金额（如100元）、最大金额（如100万）；
利率变化：浮动利率下利息重新计算；
提前还款：部分提前还款后计划更新，罚息计算；
逾期场景：逾期天数与罚息比例匹配；
数据一致性：还款后账户余额、贷款本金同步减少。
我们会用Excel公式反向验证系统计算结果。

# 13. 实际工作中发现的bug?

答题思路：
选择一个典型Bug，描述现象、根因和影响，体现测试价值。

话术：
曾发现一个提前还款罚息计算错误的Bug：系统计算罚息时使用了错误的本金余额（误用了初始本金而非剩余本金），导致多收客户罚息。

根因：开发混淆了本金取值逻辑；
发现方式：对比业务规则文档和测试数据计算；
影响：财务损失和客户投诉风险；
修复后避免了潜在资损。

# 14. 你在测试团队当中测试绩效排名多少位置，或者年终好评？

答题思路：
正面回答排名或评价，用事实和数据支撑，体现个人贡献。

话术：
在最近绩效评估中，我排名团队前20%，获得了“优秀”评价。主要贡献：

牵头完成了接口自动化框架搭建，覆盖率从30%提升到80%；
发现并推动了多个高风险Bug修复；
培养了2名新同事快速上手自动化。
绩效量化指标包括Bug发现数、用例覆盖率、项目支持满意度等。

# 15. 是如何评价的，是有量化指标吗？

答题思路：
说明绩效考核的量化指标和评价维度，体现团队管理的科学性。

话术：
是的，我们有量化指标：

缺陷发现率：提交有效Bug数量/总Bug数；
用例覆盖率：自动化用例覆盖业务场景比例；
漏测率：生产问题数量（越低越好）；
项目贡献：如框架开发、文档输出；
团队协作：需求响应速度、开发评价。
数据来自JIRA、测试报告和360度反馈。

# 16. 一天发现多少bug?有没有漏测的,客户生产环境和实际使用中出现的bug,实际上就问有没有收集客户反馈的问题

答题思路：
给出典型Bug数量，坦诚漏测情况，强调后续改进措施。

话术：

Bug数量：平均每天发现3-5个有效Bug，高峰时（如新版本测试）可达10+；
漏测情况：偶有漏测，主要是边缘场景或兼容性问题（如特定手机型号显示异常）；
客户反馈：我们会收集生产问题并录入Bug系统，定期复盘，更新用例库避免复发。
去年漏测率控制在1%以下。

# 17. 说一下python的四种数据结构

答题思路：
列举并简要说明四种核心数据结构及其特点。

话术：
Python四种核心数据结构：

列表（List）：有序、可变，可存储任意类型元素，如[1, "a", True]；
元组（Tuple）：有序、不可变，适用于不变数据，如(1, 2, 3)；
字典（Dict）：键值对、可变，快速查找，如{"name": "Alice", "age": 30}；
集合（Set）：无序、元素唯一，用于去重和集合运算，如{1, 2, 3}。
它们覆盖了大多数数据存储和处理需求。

# 18. main函数

答题思路：
解释main函数的作用和Python中的常见用法。

话术：
在Python中，main函数是程序的入口点，通常用于组织执行逻辑：

def main():
    # 主逻辑代码
    print("Hello World")

if __name__ == "__main__":
    main()

1
2
3
4
5
6

if __name__ == "__main__"确保当脚本被直接运行时才执行main()，而被导入时不会自动执行。

# 19. 使用python写一段程序，计算一段文本中单词出现的频率

答题思路：
提供简洁代码，使用字典统计词频，处理大小写和标点。

话术：

from collections import defaultdict
import re

def word_frequency(text):
    words = re.findall(r'\b\w+\b', text.lower())  # 提取单词并转小写
    freq = defaultdict(int)
    for word in words:
        freq[word] += 1
    return dict(freq)

# 示例
text = "Hello world, hello Python! World of Python."
print(word_frequency(text))
# 输出: {'hello': 2, 'world': 2, 'python': 2, 'of': 1}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

这段代码使用正则提取单词，字典统计频率，忽略大小写和标点。

# 20. 接口测试是银行有自动化平台还是用外部的框架？

答题思路：
根据实际情况选择回答，银行可能有自研平台，但外部框架更灵活。

话术：
我们采用混合模式：

银行有自研的自动化测试平台，用于简单接口测试和用例管理；
但对于复杂场景（如数据驱动、自定义断言），我们使用外部框架（如Pytest）开发脚本，更灵活；
脚本通过CI工具集成到平台执行，兼顾规范性和灵活性。

# 21. 性能压完后是怎么做性能定位的，比如时间超长？

答题思路：
说明性能分析的方法和工具使用，体现系统化排查能力。

话术：
性能定位步骤：

监控工具：使用APM（如SkyWalking）定位慢事务和慢SQL；
资源分析：检查服务器CPU、内存、IO，发现资源瓶颈；
代码 profiling：用Arthas或PySpy分析Java/Python代码热点；
数据库分析：检查慢查询日志、索引缺失、锁等待；
网络分析：排查DNS、带宽、连接池问题。
曾通过APM发现一个SQL未索引导致响应时间从200ms增至2s，添加索引后解决。

# 22. 排查下来到底在那个环节出现的问题？

答题思路：
举例说明常见问题环节，如数据库、代码逻辑或中间件。

话术：
问题多出现在：

数据库：占70%，如索引缺失、锁竞争、全表扫描；
应用代码：占20%，如循环查询DB、算法效率低、线程阻塞；
中间件/网络：占10%，如Redis连接池不足、Kafka堆积、带宽打满。
最近一个案例是数据库连接池设置过小，高并发时等待连接导致超时。

# 23. 全表扫描

答题思路：
解释全表扫描的含义、危害和避免方法。

话术：
全表扫描指数据库查询时未使用索引，逐行扫描整张表，性能极差（O(n)复杂度）。

危害：CPU和IO飙升，响应时间慢，拖垮数据库；
避免方法：
- 为查询条件字段添加索引；
- 避免在WHERE中使用函数或表达式（如WHERE YEAR(create_time)=2023）；
- 使用EXPLAIN分析执行计划。
  我们要求所有查询必须通过索引优化。

# 24. 使用python能写导入或外挂吗？

答题思路：
肯定Python的能力，举例常见应用场景。

话术：
是的，Python非常适合编写数据导入脚本或外挂工具：

数据导入：用Pandas读取Excel/CSV，清洗后批量入库；
外挂工具：如自动化测试平台的外挂脚本，通过API扩展功能；
协议处理：编写Socket客户端模拟第三方系统交互。
我们曾用Python开发贷款数据迁移工具，处理百万级记录。

# 25. 开发改了一个逻辑，你是怎么去设计和分析的，他的影响范围？

答题思路：
说明变更分析流程，包括代码审查、影响模块识别和回归测试。

话术：

理解变更：与开发沟通修改内容和原因；
影响分析：查看代码依赖，识别受影响模块（如数据库、接口、前端）；
用例更新：修改相关测试用例，添加新场景；
回归测试：执行影响模块的自动化用例，手动测试边缘场景；
沟通同步：通知上下游团队（如产品、运维）变更影响。
我们会使用代码diff工具辅助分析。

# 26. 对常用的库表或工具，像Linux

答题思路：
列举熟悉的Linux命令和常用工具，体现运维能力。

话术：
熟练使用Linux：

文件操作：grep, find, sed, awk；
进程管理：ps, top, kill, nohup；
日志分析：tail -f, less, grep error；
网络调试：netstat, telnet, curl；
权限管理：chmod, chown。
日常通过SSH登录服务器排查问题，写Shell脚本自动化任务。

# 27. tomcat进程是不是还活着，想重启杀掉怎么做？

答题思路：
给出检查进程和重启的Linux命令，体现实际操作经验。

话术：

检查进程：ps -ef | grep tomcat 或 systemctl status tomcat（如果用了systemd）；
平滑杀死：kill <PID> 发送SIGTERM，等待优雅关闭；
强制杀死：kill -9 <PID> 如果进程无响应；
重启：./catalina.sh start（在Tomcat的bin目录下）或 systemctl restart tomcat。
我们会先确认进程是否假死（通过curl本地接口），再决定是否重启。

# 28. 没有进行过滤吗？

答题思路：
解释输入过滤的重要性，举例安全测试中的过滤漏洞。

话术：
输入过滤是必须的，否则会导致安全漏洞：

SQL注入：未过滤单引号，攻击者可执行恶意SQL；
XSS：未转义HTML标签，脚本注入页面；
业务绕过：如负数金额、超长字符串导致系统异常。
我们会在测试中专门验证过滤规则，用BurpSuite扫描漏洞。

# 29. 你认为你最大的优势是什么？

答题思路：
结合岗位要求，突出技术深度、业务理解或软技能，用实例证明。

话术：
我最大的优势是技术与业务的结合能力：

技术方面：精通自动化、性能测试和Python开发，能快速解决复杂问题；
业务方面：深入理解金融业务（如贷款、保险），能精准设计测试场景；
案例：曾通过自动化脚本发现一个利息计算漏洞，避免百万资损。
这使我不仅能发现问题，还能从业务角度推动优化。

# 招商银行真题二

# 1、自我介绍

答题思路：
应涵盖工作经验、技术栈、项目经验和与岗位相关的技能，突出测试开发和自动化方面的能力。

答题话术：
面试官您好，我叫[您的姓名]，有[数字]年测试开发经验。精通接口自动化测试框架设计与开发，熟悉Python、Java等编程语言。在保险、金融等领域有丰富的项目经验，擅长构建稳定的自动化测试体系，推动测试左移和持续集成。主导过多个项目的质量保障工作，能有效提升测试效率和质量。期待能加入团队，为项目质量保驾护航。

# 2、做的这个项目业务是什么样，说说重难点（其中提到了不能重复买相同保单）

答题思路：
清晰描述业务背景，重点突出业务规则复杂性和数据一致性带来的测试挑战。

答题话术：
我负责的是互联网保险业务系统，用户可通过H5、小程序等渠道购买保险产品。核心业务涉及投保、核保、支付、出单等流程。
重点难点在于业务规则复杂，比如"同一用户不能重复购买相同保单"的约束：

需要验证同一用户多次购买同一产品的拦截逻辑
并发场景下如何保证数据一致性（如双重请求）
边界情况处理（如保单过期后是否可重新购买）
测试时需要设计覆盖这些特殊场景的用例，并通过自动化手段持续验证。

# 3、这个业务里边的重点或者难点，你们测试是怎么做保障的，特别的保障手段，或者是特别的测试方法？

答题思路：
从流程、技术、数据三个维度阐述质量保障体系，突出自动化建设和专项测试。

答题话术：
我们采取了多层次的质量保障措施：

流程层面：
- 测试左移：早期参与需求评审，识别业务规则风险点
- 用例评审：组织跨团队用例评审，确保场景覆盖全面
技术层面：
- 接口自动化：覆盖核心业务流和异常场景，定期回归
- 混沌工程：注入故障模拟异常（如数据库连接失败）
- 契约测试：保障前后端接口约定的一致性
数据层面：
- 测试数据工厂：按需生成测试数据，支持多种测试场景
- 数据清理机制：保证测试环境数据可用性
监控预警：
- 生产环境监控关键业务指标（如保单创建成功率）
- 建立质量度量体系，持续改进测试策略

# 5、你们测试重点是测端到端，还是接口测试，或者怎么个测试的方式？

答题思路：
说明测试金字塔理念，强调接口测试的价值和自动化策略。

答题话术：
我们遵循测试金字塔模型，以接口测试为重点：

接口测试（占比70%）：快速反馈业务逻辑正确性，执行效率高
集成测试（20%）：验证系统间调用和数据传递
端到端测试（10%）：覆盖关键用户旅程，但维护成本高

选择这个策略是因为：

保险业务逻辑复杂，接口测试能深入验证各种业务规则
执行速度快，适合持续集成流水线
相对于UI自动化，接口测试更加稳定和维护成本低

# 6、你们在做接口测试的时候主要考虑什么样的场景？

答题思路：
从正常流程、异常流程、边界值、安全、性能等维度说明测试场景设计。

答题话术：
我们主要考虑以下几类场景：

正常流程：合法参数请求，验证业务功能正确性
异常流程：
- 参数异常：缺失、格式错误、类型错误、长度超限
- 业务异常：重复投保、保单不存在、用户不存在
边界值：金额边界、日期边界、数量边界等
安全测试：SQL注入、XSS攻击、权限绕过
并发场景：同时发起多个请求验证数据一致性
数据一致性：验证数据库与接口返回数据一致

# 7、你们这个自动化测试框架是怎么实现的

答题思路：
介绍技术选型、框架架构、关键模块和特色功能。

答题话术：
我们的自动化测试框架基于Python + pytest实现，主要包含以下模块：

核心层：
- 用例管理：基于pytest框架组织测试用例
- 数据驱动：通过YAML文件管理测试数据
服务层：
- HTTP客户端：封装requests库处理接口请求
- 数据库操作：封装SQLAlchemy进行数据验证
- 断言机制：自定义断言库验证业务规则
支撑层：
- 配置管理：区分不同环境配置
- 日志系统：记录详细执行日志
- 报告生成：使用Allure生成可视化报告
特色功能：
- 自动重试机制：处理环境不稳定问题
- 用例依赖管理：处理用例间依赖关系
- 数据工厂：自动生成测试数据

# 8、你们这个框架里边是怎么保障用例可以重复地执行，然后保障它执行稳定性的。

答题思路：
从环境隔离、数据管理、异常处理等方面阐述稳定性保障措施。

答题话术：
我们通过以下方式保障用例稳定性和可重复执行：

环境隔离：
- 使用独立的测试环境，避免与开发环境冲突
- 通过Docker容器化部署，保证环境一致性
数据管理：
- 前置条件：每个用例执行前构造所需测试数据
- 数据清理：用例执行后自动清理产生的数据
- 数据隔离：使用唯一标识（如时间戳+随机数）避免数据冲突
异常处理：
- 网络异常重试机制：对网络波动进行自动重试
- 超时控制：设置合理的接口超时时间
稳定性提升：
- 用例独立性：保证用例间无依赖，可单独执行
- 异步处理：对异步接口增加轮询查询机制

# 9、比如说有一些接口可能它不一定都是读的接口，可能会有一些写的接口，你是怎么保障它可以重复地去写的？

答题思路：
重点说明写接口的数据管理和清理策略。

答题话术：
对于写接口（如创建保单），我们采取以下策略：

数据唯一性：
- 使用唯一标识：如"保单号+时间戳+随机数"组合
- 业务字段差异化：相同业务不同测试数据
前置清理：
- 执行前检查并清理可能冲突的测试数据
后置清理：
- 用例执行后自动清理产生的数据
数据工厂：
- 通过数据工厂按需生成测试数据
- 支持参数化数据生成模板

# 10、你们的这个接口自动化是在什么时候执行的？

答题思路：
说明测试执行时机和触发方式。

答题话术：
我们的接口自动化在以下时机执行：

持续集成流水线：
- 代码提交后触发执行
- 每日定时执行回归测试
手动触发：
- 测试人员手动选择用例集执行
预发布验证：
- 发布前执行全量回归测试
生产监控：
- 定期执行核心流程监控测试

# 11、自动框架写了400多条测试用例，你一个人维护的吗？

答题思路：
说明团队协作模式和维护机制。

答题话术：
不是一个人维护的，我们采用团队协作模式：

分工负责：
- 不同模块由对应测试人员负责维护
- 我负责框架设计和核心模块维护
规范制定：
- 建立用例编写规范和维护流程
- 提供模板和示例降低上手难度
代码评审：
- 所有用例变更都需要代码评审
- 定期组织用例重构和优化
知识共享：
- 定期组织自动化技术分享
- 建立知识库记录最佳实践

# 12、你们测试环境是由运维去做一个部署？

答题思路：
说明测试环境部署的协作模式。

答题话术：
我们采用DevOps模式进行环境部署：

运维负责：
- 基础环境搭建和维护
- 容器平台和监控系统维护
测试参与：
- 提供环境部署需求和要求
- 编写部署脚本和配置模板
自动化部署：
- 使用CI/CD流水线自动部署测试环境
- 环境部署脚本版本化管理
自助服务：
- 测试人员可以按需触发环境部署
- 支持多版本环境并行部署

# 13、你们这个不是集成到整个研发部署流程的，是吧？

答题思路：
说明自动化测试与CI/CD的集成情况。

答题话术：
我们的自动化测试已经深度集成到研发部署流程中：

CI集成：
- 代码提交后自动触发接口测试
- 测试通过后才能合并代码
CD集成：
- 发布前自动执行回归测试套件
- 测试通过后才能部署到生产环境
质量门禁：
- 设置测试通过率阈值
- 关键用例失败阻断部署流程
反馈机制：
- 测试结果自动通知相关责任人
- 生成质量报告供团队查看

# 14、测系统发现它白屏了，一般是怎么去看问题的，包括它是前端问题还是后端问题

答题思路：
系统化说明白屏问题的排查思路和方法。

答题话术：
白屏问题排查我们按照以下步骤进行：

初步判断：
- 打开浏览器开发者工具，查看Console错误信息
- 检查Network面板，查看接口请求状态
前端问题特征：
- JavaScript执行错误（Console有红色错误）
- 资源加载失败（CSS/JS文件404）
- 接口请求正常但页面渲染失败
后端问题特征：
- 关键接口返回5xx错误码
- 接口返回数据格式异常
- 数据库连接失败等基础设施问题
深入排查：
- 查看前端日志和错误监控系统
- 检查后端服务日志和性能监控
- 使用抓包工具分析网络请求

# 25、它是容器化的，还是直接部署在物理机上面的？物理机的集群是用的Docker或者K8S这种的。

答题思路：
说明技术栈和部署架构。

答题话术：
我们的系统采用容器化部署：

技术栈：
- 使用Docker进行容器化封装
- 基于Kubernetes进行容器编排和管理
部署架构：
- 微服务架构，每个服务独立部署
- 使用Ingress进行流量管理
- 配置中心统一管理应用配置
基础设施：
- 云原生架构，运行在私有云平台
- 使用CI/CD工具链进行自动化部署

# 16、你们是用的Docker，大概知道的命令？

答题思路：
列举常用的Docker命令和用途。

答题话术：
常用的Docker命令包括：

容器管理：

docker ps -a  # 查看容器列表
docker logs <container>  # 查看容器日志
docker exec -it <container> bash  # 进入容器

1
2
3

镜像管理：

docker images  # 查看镜像列表
docker build -t <image> .  # 构建镜像
docker push <image>  # 推送镜像

1
2
3

生命周期：

docker run -d <image>  # 启动容器
docker stop <container>  # 停止容器
docker rm <container>  # 删除容器

1
2
3

排查问题：

docker stats  # 查看容器资源使用
docker inspect <container>  # 查看容器详情

1
2

# 17、怎么判断性能测试有没有问题的

答题思路：
说明性能测试评估标准和问题判断方法。

答题话术：
我们从多个维度判断性能测试结果：

性能指标：
- 响应时间：是否超过预期阈值（如P95<2s）
- 吞吐量：是否达到预期TPS要求
- 错误率：是否低于可接受范围（如<0.1%）
资源 utilization：
- CPU、内存使用率是否正常
- 数据库连接池是否耗尽
- 网络带宽是否成为瓶颈
稳定性：
- 长时间运行是否出现内存泄漏
- 性能指标是否随时间退化
可扩展性：
- 负载增加时性能是否线性扩展
- 系统瓶颈点在哪里

# 18、性能测试是什么样的问题？怎么排查它的。

答题思路：
系统化说明性能问题类型和排查方法论。

答题话术：
性能问题主要分为以下几类，排查方法如下：

高延迟问题：
- 使用APM工具分析调用链耗时
- 检查数据库慢查询和索引优化
- 分析网络延迟和带宽情况
低吞吐量问题：
- 检查线程池配置和并发数限制
- 分析系统资源瓶颈（CPU、内存、IO）
- 验证负载均衡是否正常工作
稳定性问题：
- 检查内存泄漏（Heap Dump分析）
- 分析GC日志和垃圾回收情况
- 监控数据库连接池使用情况
排查工具：
- 使用jstack分析线程状态
- 使用jmap分析内存使用
- 使用arthas进行在线诊断

# 19、代码问题，比如给你一个a、d、B、C、D这样的一个字符串，返回它这个字符串里面没有重复字符的最长的字串就是返回b、c、d

答题思路：
给出算法实现思路和代码示例。

答题话术：
这是一个典型的无重复字符最长子串问题，可以用滑动窗口算法解决：

def longest_unique_substring(s): # 处理大小写统一（根据需求决定） s = s.lower()

char_index = {}  # 记录字符最后出现的位置
left = 0        # 滑动窗口左边界
max_len = 0     # 最长子串长度
start_index = 0 # 最长子串起始位置

for right in range(len(s)):
    char = s[right]
    
    # 如果字符已在窗口中，移动左边界
    if char in char_index and char_index[char] >= left:
        left = char_index[char] + 1
    
    # 更新字符位置
    char_index[char] = right
    
    # 更新最大长度
    if right - left + 1 > max_len:
        max_len = right - left + 1
        start_index = left

return s[start_index:start_index + max_len]

# 测试示例

print(longest_unique_substring("adBCD")) # 输出 "abcd"

这个算法的时间复杂度是O(n)，空间复杂度是O(字符集大小)。

# 20、日常工作里边写一些脚本，工作占比是什么样的

答题思路：
合理分配脚本开发在工作中的比重，体现自动化思维。

答题话术：
脚本开发在工作中的占比大约30-40%，主要包括：

测试自动化（60%）：接口自动化脚本、性能测试脚本
工具开发（20%）：测试数据生成工具、环境部署脚本
效率提升（20%）：日志分析脚本、报表生成脚本
应急响应：线上问题排查和修复脚本

我坚持"自动化优先"原则，对于重复性工作都会考虑通过脚本自动化实现。

# 21、会自己写一些脚本或者工具去给自己做提效吗？

答题思路：
举例说明具体提效工具和带来的价值。

答题话术：
是的，我经常编写脚本工具来提升效率，比如：

测试数据生成工具：
- 根据业务规则自动生成合规测试数据
- 支持批量生成和导出
环境部署脚本：
- 一键部署测试环境
- 自动配置和初始化
日志分析工具：
- 自动化分析测试日志，快速定位问题
- 生成错误报告和统计信息
报表生成脚本：
- 自动收集测试结果生成质量报表
- 可视化展示测试进度和通过率

← 新能源汽车