技术栈：Python + Requests + PyTest + Allure + Excel 基于 Python 语言搭建的轻量级、可扩展的接口自动化测试框架，核心组件分工明确，适配企业级接口测试需求： 核心组件 核心作用 Python 框架开发的基础语言，语法简洁、生态丰富 Requests 发送 HTTP/HTTPS 请求（GET/POST/PUT/DELETE 等），处理接口请求与响应 PyTest 测试用例管理（支持参数化、夹具 fixtures、跳过/重试等），执行测试套件 Allure 生成可视化测试报告（包含用例通过率、失败详情、日志等），便于问题定位 Excel 用例数据驱动（存储接口信息、请求参数、预期结果等），实现数据与代码分离
fixture 是测试框架提供的夹具函数，用来统一管理测试的前置条件和后置清理， 这些每个用例都要做、重复写很麻烦的东西，封装成 fixture，用的时候直接调用就行
一、框架执行流程： 1、数据准备：在 Excel 中维护接口测试用例，包含 接口URL、请求方法、请求头、请求参数、预期响应码、预期返回字段 等； 2、用例编写：通过 PyTest 编写测试函数，利用 fixtures 实现执行前置（如登录获取 token）、后置（如清理测试数据）操作； 3、请求发送：调用 Requests 库发送接口请求，接收响应数据； 4、结果断言：对比实际响应与 Excel 中的预期结果，判断用例是否通过； 5、报告生成：执行完用例后，通过 Allure 生成 HTML 格式的测试报告，展示用例执行结果； 6、持续集成（可选）：可结合 Jenkins 实现定时执行、失败邮件通知等。 二、框架优势（面试加分点） 1、数据驱动：Excel 分离测试数据和代码，非技术人员也能维护用例，降低维护成本； 2、易扩展：可新增接口加密 / 解密、接口依赖处理、多环境配置（测试 / 预发 / 生产）等功能； 3、可视化报告：Allure 报告清晰展示失败原因、请求 / 响应详情，便于快速定位问题； 4、兼容性强：PyTest 支持丰富的插件（如 pytest-html、pytest-xdist 分布式执行），可灵活扩展。
“在做接口自动化测试时，我主要从四个维度考虑： 第一是测试设计，覆盖接口的功能、异常、依赖场景，比如用 Excel 管理多组参数，验证登录接口的正确密码、错误密码、空密码等场景； 第二是框架落地，基于 Python+Requests+PyTest 封装通用请求函数，用 Allure 生成可视化报告，实现数据与代码分离； 第三是执行保障，设置超时、重试机制，对接 Jenkins 实现定时执行，确保用例稳定； 第四是维护优化，定期清理无效用例，用分布式执行提升效率，降低维护成本。核心目标是让接口自动化既能覆盖全场景，又能稳定、高效运行，真正落地解决回归测试的问题。”
一、测试设计层面（核心测试点） 这是接口自动化的基础，要覆盖接口的全场景验证，避免遗漏关键逻辑： 1、功能完整性验证 1）基础参数：必传 / 非必传参数、参数类型（字符串 / 数字 / 布尔）、参数边界值（如长度限制、数值范围）； 2）请求方法：GET/POST/PUT/DELETE 等方法的正确性，比如 POST 接口是否支持 GET 请求（应返回错误）； 3）响应验证：响应码（200/400/401/500 等）、响应字段（必返字段是否存在、字段类型 / 长度是否符合预期）、响应格式（JSON/XML 格式正确性）； 2、异常场景：参数缺失、参数错误、权限不足、数据不存在、接口限流 / 熔断等异常的响应是否符合预期。 3、接口依赖处理 比如登录接口返回的 token，需要传递给后续接口，通过 PyTest 的 fixtures 实现前置登录， 将 token 存入全局变量或会话中； 4、多接口联动场景（如创建订单→支付订单→查询订单），确保自动化用例按依赖顺序执行。 5、业务场景覆盖 核心业务流程：比如 “用户登录→加入购物车→提交订单” 的全链路接口自动化； 特殊业务规则：比如积分计算、权限校验、数据唯一性（如手机号重复注册）等业务逻辑的验证。
二、框架落地层面（适配你的技术栈） 结合你使用的 Python + Requests + PyTest + Allure + Excel 框架，重点考虑落地的实用性： 1、数据驱动设计 用 Excel 管理测试数据，按 “接口模块 - 接口名称 - 请求参数 - 预期结果” 分类，实现数据与代码分离； 支持多环境配置（测试 / 预发 / 生产），通过配置文件（如 config.ini/yaml）管理不同环境的接口域名，避免硬编码。 2、用例管理规范 按模块划分 PyTest 测试用例文件（如 test_login.py、test_cart.py），用例命名清晰（如 test_login_success、test_login_error_password）； 利用 PyTest 的参数化（@pytest.mark.parametrize）批量执行多组测试数据，提升效率； 封装通用函数：比如封装 Requests 请求方法（send_request）、Excel 读取函数（read_excel），减少代码冗余。 3、报告与日志 集成 Allure 生成可视化报告，包含请求 / 响应详情、断言结果、执行耗时，方便定位失败原因； 增加日志记录（logging 模块），记录接口请求的 URL、参数、响应、执行时间等，便于问题排查。
三、执行保障层面 确保自动化用例能稳定执行，避免 “假失败” 或执行效率低： 1、稳定性处理 1）接口超时设置：Requests 设置 timeout（如 10s），避免用例卡死； 2）重试机制：对偶发失败的接口（如网络波动），通过 pytest-rerunfailures 插件实现自动重试； 3）环境隔离：测试数据独立（如测试账号、测试订单），避免与手动测试、生产环境数据冲突，用例执行后清理测试数据（如删除测试订单）。 2、执行效率优化 1）分布式执行：通过 pytest-xdist 插件实现多线程 / 多进程执行用例，缩短执行时间； 2）用例分层：核心接口用例全量执行，非核心接口用例按需执行（如每日全量 vs 上线前关键用例）。 3、持续集成 对接 Jenkins，配置定时执行（如每日凌晨）或触发执行（如代码提交后）； 执行结果通知：失败时通过邮件 / 企业微信 / 钉钉推送报告，及时发现问题。
四、维护优化层面 避免自动化用例 “写了不用、用了难维护”： 1、用例维护成本 定期清理无效用例（如接口已下线），更新变更接口的用例（如参数调整）； 版本管理：用 Git 管理代码和 Excel 用例，记录变更记录，便于回滚。 2、扩展性设计 预留扩展接口：比如后续增加接口加密 / 解密、接口 mock（如 requests-mock）、性能监控等功能； 兼容多协议：若后续涉及 HTTP/HTTPS 之外的协议（如 WebSocket），框架可快速适配。
在接口自动化测试用例设计中，我会从功能正确性、异常场景、业务逻辑、数据一致性等多个维度来覆盖测试点 面试回答示例（精简版） “在设计接口自动化用例时，我会重点考虑以下几点： 基础功能：验证请求合法性、参数正确性和响应字段的完整性。 异常场景：覆盖参数错误、权限不足、数据不存在等情况，确保接口在异常下的稳定性。 业务逻辑：处理接口依赖和业务规则，比如登录后才能操作订单，确保全链路流程正确。 数据验证：保证测试数据隔离，执行后清理数据，同时校验数据库一致性。 可维护性：通过数据驱动和参数化，让用例易于维护和扩展，避免随着业务迭代而失效。” 1. 基础功能验证 ✅ 请求合法性：验证接口地址、请求方法（GET/POST/PUT/DELETE）、请求头（如 Content-Type、Authorization）是否符合设计要求。 参数正确性： 必传参数：验证缺失时是否返回 400 等错误码。 参数类型：如字符串、数字、布尔值、枚举值，验证类型不匹配时的处理。 参数边界：如字符串长度、数字范围、日期格式，验证边界值和超限场景。 响应正确性： 响应码：200（成功）、400（参数错误）、401（未授权）、403（禁止访问）、500（服务异常）等。 响应字段：必返字段是否存在、字段类型 / 格式是否符合预期、业务字段值是否正确。 响应格式：JSON/XML 结构是否合法，无语法错误。 2. 异常场景覆盖 ⚠️ 参数异常：空值、非法字符、超长字符串、负数、特殊符号等。 权限异常：未登录、登录过期、权限不足的用户访问接口，验证返回 401/403。 数据异常：查询不存在的 ID、重复提交相同数据、操作已删除的数据。 服务异常：模拟服务超时、数据库宕机、依赖服务不可用，验证降级 / 熔断逻辑。 3. 业务逻辑与依赖处理 🔗 业务规则：如积分计算、库存扣减、状态流转（订单创建→支付→发货），验证业务规则是否被正确执行。 接口依赖： 前置依赖：如登录接口获取 token，后续接口必须携带 token，用 PyTest fixtures 实现前置登录。 多接口联动：如创建订单后必须支付，支付后才能查询到订单状态，用例按依赖顺序执行。 幂等性：重复提交相同请求（如支付、创建订单），验证是否只执行一次，避免重复扣款或数据重复。 4. 数据一致性与隔离 📊 数据隔离：测试用例使用独立的测试账号、测试数据，避免与手动测试或其他用例冲突。 数据清理：用例执行后清理测试数据（如删除测试订单、取消测试支付），保证环境干净。 数据库校验：关键操作（如创建、修改、删除）后，校验数据库中对应记录的状态和字段值是否正确。 5. 性能与安全考量 🛡️ 性能指标：接口响应时间是否符合要求（如 < 200ms），高并发下是否稳定。 安全测试： 防注入：验证 SQL 注入、XSS 攻击的防护是否生效。 防重放：验证 token 过期、签名校验是否有效。 敏感信息：响应中是否泄露密码、手机号等敏感数据。 6. 用例可维护性与复用性 🧩 数据驱动：用 Excel 管理测试数据，实现数据与代码分离，方便批量维护用例。 参数化：用 PyTest 的 @pytest.mark.parametrize 实现多组数据的批量执行。 用例分层： 核心用例：覆盖主流程，每日全量执行。 辅助用例：覆盖边缘场景，按需执行。 通用封装：封装请求、断言、日志等通用函数，减少代码冗余，提升复用性。
- 针对登录接口，会涉及哪些接口自动化测试用例及测试点
面试回答示例（精简版） “针对登录接口，我会设计四类自动化用例： 基础功能：验证正确账号密码登录成功，返回有效 token 和用户信息。 异常场景：覆盖空参数、错误密码、账号锁定、验证码错误等，确保接口在异常下返回合理提示。 安全性能：验证密码加密传输、防重放攻击，以及响应时间和并发能力达标。 业务联动：验证单点登录、会话管理、登录日志等联动逻辑，确保全链路正常。 在实现上，我会用 Excel 管理多组测试数据，通过 PyTest 参数化批量执行，并用 Allure 生成详细报告，方便定位问题。” 一、基础功能验证 ✅ 正常登录 用例：输入正确的用户名和密码，验证登录成功，返回合法 token、用户信息及 200 响应码。 测试点：响应字段完整性（user_id、token、expire_time）、token 有效性（可用于后续接口鉴权）。 记住我 / 自动登录 用例：勾选 “记住我” 选项登录，验证返回的 refresh_token 有效，且过期时间符合预期。 测试点：refresh_token 可用于无感续登，避免频繁输入密码。 二、异常场景覆盖 ⚠️ 参数异常 用户名 / 密码为空：验证返回 400 及 “参数不能为空” 提示。 用户名 / 密码错误：验证返回 401 及 “账号或密码错误” 提示。 特殊字符注入：如用户名输入 ' OR 1=1 --，验证接口有防注入处理，不返回敏感信息。 超长字符：如用户名超过 50 字符，验证返回参数校验失败。 账号状态异常 账号锁定：连续输错密码 N 次后，验证账号被锁定，无法登录。 账号禁用 / 注销：验证禁用账号无法登录，返回 “账号状态异常”。 账号未激活：验证未激活账号登录时，提示 “请先激活账号”。 安全与防刷 验证码错误：输入错误的图形 / 短信验证码，验证登录失败。 验证码过期：使用过期验证码，验证登录失败。 频繁登录：短时间内多次请求，验证触发限流（如 429 响应码）。 三、安全与性能测试 🛡️ 安全测试点 密码传输：验证密码在请求中是加密传输（如 MD5/SM2），不明文传输。 防重放攻击：使用旧 token 或重复提交相同登录请求，验证被拒绝。 敏感信息：验证响应中不返回密码、手机号明文等敏感数据。 性能测试点 响应时间：验证登录接口平均响应时间 < 200ms，95 分位响应时间 < 500ms。 并发能力：模拟 100 并发用户登录，验证 TPS 达标，无超时或 5xx 错误。 四、业务联动与依赖 🔗 登录后联动场景 单点登录（SSO）：验证登录后可自动跳转至关联系统，无需二次登录。 会话管理：验证登录后，其他设备的同账号会话被挤下线（或提示 “异地登录”）。 登录日志：验证登录成功 / 失败后，系统日志中记录了登录时间、IP、设备信息。 接口依赖处理 Token 依赖：用 PyTest fixture 封装登录函数，将 token 注入后续接口用例，避免重复登录。 多设备登录：验证同一账号在多设备同时登录的策略（如允许 / 拒绝）。
面试满分简短回答（直接背） “登录接口的性能指标我一般从这几方面评估： 响应时间：平均≤200ms，95%≤300ms，99%≤500ms； 吞吐量：根据集群配置，TPS 至少达到 500 以上，支持峰值流量； 并发能力：支持几百并发同时登录，不报错、不超时； 错误率：压测期间服务端错误率必须为 0； 资源监控：CPU 不超过 70%~80%，无内存泄漏、无连接耗尽。 登录接口性能指标（标准、通用、可落地） 1. 响应时间 RT（最核心） 平均响应时间：≤ 200ms 95% 响应时间：≤ 300ms 99% 响应时间：≤ 500ms 说明：登录一般涉及密码校验、token 生成、数据库查询，属于关键核心接口，必须快。 2. 吞吐量 TPS / QPS 根据项目规模不同，一般要求： 单节点：TPS ≥ 100~200 集群部署：TPS ≥ 500~1000+ 峰值可支持：支持平时流量的 3~5 倍峰值不雪崩 登录属于瞬时高并发接口（如活动、刚上班、刚开门），必须抗峰值。 3. 并发用户数 支持 100~500 并发用户同时登录，无报错、无大量超时。 支持重复登录、异地登录、顶下线等高并发场景稳定。 4. 错误率 错误率 = 0% 不允许出现 502、503、504、连接超时、连接拒绝等。 业务异常（密码错、验证码错）不算错误，只算服务异常。 5. 资源利用率（服务器端） 压测时监控： CPU 利用率：≤ 70%~80% 内存使用率：无持续上涨、无内存泄漏 网络 I/O、磁盘 I/O：正常 DB 连接、Redis 连接：不耗尽、不超时 6. 安全性 + 限流指标（也算性能保障） 支持 接口限流：如每分钟最多 10 次登录失败 防刷、防暴力破解 高并发下不会因为大量请求打挂认证服务
- 除了 API focus，你还会用什么工具做性能测试
面试回答示例（精简版） “除了 API Focus，我常用的性能测试工具分两类： 核心压测工具：首选 JMeter（开源、分布式压测适配登录接口高并发），其次 Locust（Python 脚本易上手，匹配我的技术栈），大型企业场景会用 LoadRunner；轻量快速验证会用 k6，高并发场景用 Gatling。 监控分析工具：用 Prometheus + Grafana 监控服务器资源，结合 MySQL 慢查询日志、Arthas 定位瓶颈，比如登录接口响应慢时，能快速查到是数据库索引问题还是 JVM 卡顿。 实际工作中，我会根据场景选工具：比如登录接口日常压测用 JMeter，集成到 CI/CD 用 k6，高并发压测用 Gatling，核心是能精准测出接口的性能瓶颈。” 一、主流性能测试工具（按使用频率排序） 1. JMeter（最常用） 适用场景：接口性能测试（如登录接口压测）、Web 页面性能测试、数据库性能测试，支持 HTTP/HTTPS、TCP、JDBC 等多种协议。 核心优势： 开源免费，社区生态丰富，可通过插件扩展功能（如 JSON 提取器、Redis 插件）； 支持分布式压测（多台机器模拟高并发），适合登录接口的高并发场景； 可录制脚本、参数化测试数据（如批量生成不同账号密码），生成可视化报告。 落地示例：用 JMeter 模拟 1000 并发用户登录，设置线程组、HTTP 请求（登录接口）、响应断言、聚合报告，监控 TPS / 响应时间 / 错误率。 2. Locust（Python 生态首选） 适用场景：接口性能测试、分布式压测，尤其适合懂 Python 的测试人员（匹配你的技术栈）。 核心优势： 纯 Python 编写，脚本易上手（用 Python 代码定义用户行为，如登录→查询用户信息）； 支持分布式压测，可动态调整并发用户数； 自带 Web 监控界面，实时查看 TPS、响应时间、错误率。 落地示例：针对登录接口，用 Locust 编写压测脚本，定义用户登录的行为逻辑，启动 master + slave 节点模拟高并发。 3. LoadRunner（企业级商用工具） 适用场景：全栈性能测试（接口、Web、APP、数据库、中间件），适合大型企业复杂场景。 核心优势： 支持协议最全（HTTP、WebService、MQ、Redis 等），可模拟复杂业务场景； 自带强大的监控分析功能，能定位性能瓶颈（如服务器 CPU、内存、数据库慢查询）； 支持场景录制与回放，非技术人员也能快速上手。 不足：商用收费，学习成本较高。 4. k6（轻量级现代工具） 适用场景：接口性能测试、CI/CD 集成（适合自动化流程）。 核心优势： 基于 JavaScript/TypeScript，脚本简洁，易集成到 Jenkins/GitLab CI； 轻量化，启动快，适合快速验证接口性能（如登录接口的基础响应时间）； 自带云压测功能，无需搭建本地分布式环境。 5. Gatling（高性能压测工具） 适用场景：高并发接口压测，要求极致性能的场景。 核心优势： 基于 Scala 编写，性能优于 JMeter，支持百万级并发； 脚本基于 DSL 语法，结构清晰，报告可视化程度高； 低资源占用，单台机器可模拟更多并发用户。 二、辅助监控工具（性能测试必备） 性能测试不仅要压测，还要定位瓶颈，这些工具是配套核心： Prometheus + Grafana：监控服务器 CPU、内存、磁盘 I/O、网络带宽，以及 Redis/MQ/ 数据库的性能指标； nmon/top/htop：Linux 服务器本地监控，实时查看资源占用； MySQL Explain / 慢查询日志：定位登录接口的数据库瓶颈（如用户表查询未加索引）； JProfiler/Arthas：监控 Java 服务的 JVM 性能（如 GC 频率、线程阻塞），适合后端是 Java 的登录服务。
- 积分商城的商品发货管理流程是怎样的
- 积分商城的发货是通过什么方式实现的
- 针对商城购物车，会涉及哪些测试点
- 你平时使用中间件相关的东西多吗，比如 Redis、MQ
平时用得非常多，测试过程中经常和 Redis、MQ 打交道，主要是这几块： 1、Redis 做功能测试时，会去查缓存，判断数据是否正确、是否过期、是否击穿、是否一致性； 压测时看 Redis 连接数、命中率、内存、慢查询，判断是不是缓存瓶颈。 2、MQ 功能测试：看消息是否发送、是否消费、是否重复、是否丢失、顺序是否正确； 性能 / 异常测试：模拟消息堆积、消费失败、Broker 宕机，验证系统容错能力。 测试过程中经常要 查 Redis key、清缓存、验数据 查 MQ 消息内容、堆积量、重置位点
一、先定位：快速确定堆积的核心范围 1、查看 MQ 控制台 / 监控面板 1）堆积指标：队列长度（消息总数）、消费堆积量（生产 - 消费差值）、消费进度； 2）分区 / 队列维度：是否是某一个分区 / 队列堆积（比如 Kafka 分区、RocketMQ 队列），还是全量 堆积； 3）时间维度：堆积开始时间、堆积速率（每秒新增未消费消息数）。 2、确认生产 / 消费侧基本状态 1）生产侧：是否突发大量消息写入（比如营销活动、批量任务），生产 QPS 是否远超平时； 2）消费侧：消费进程是否存活（机器 / 容器是否宕机）、消费线程是否卡住、消费节点数量是否正常。 二、分析根因：按优先级排查常见问题 1. 消费侧故障（最常见） 消费进程异常、消费速度过慢 2、生产侧突发流量 3、 MQ 中间件本身问题 排查步骤： ① 检查 MQ 集群状态： ② 查看 MQ 自身资源：broker 的磁盘是否满（消息无法落盘）、内存不足导致消息刷盘延迟； ③ 确认 MQ 配置：是否有消费限流、、消息过期时间设置不合理。 三、临时解决 & 长期优化 1. 临时缓解（先止损） 紧急扩容：增加消费节点 / 消费线程数（针对消费能力不足）； 跳过异常消息：临时跳过导致消费阻塞的坏消息（记录 msgid，后续分析）； 分流处理：将堆积消息迁移到临时队列，分批消费； 暂停非核心生产：临时关闭非核心业务的消息生产，降低入队速率。 2. 长期优化（避免复发） 消费侧： ✅ 异步化：将耗时操作异步处理，缩短单条消息消费时间； ✅ 限流熔断：消费端增加限流（避免压垮下游）、熔断（避免线程阻塞）； ✅ 监控告警：配置堆积阈值告警（如 lag>10000 触发告警）、消费延迟告警； ✅ 幂等性：确保消费端重复消费不影响业务，避免重复处理导致的耗时。 生产侧： ✅ 流量控制：生产端增加限流，避免突发流量打满 MQ； ✅ 消息分片：超大消息拆分成小消息，分批发送； ✅ 削峰填谷：使用 MQ 的流量控制功能（如 RocketMQ 的流控）。 MQ 层面： ✅ 集群扩容：根据业务增长扩容 MQ broker 节点； ✅ 配置优化：合理设置消息刷盘策略、重试次数、死信队列规则。
- 针对 MQ 的专项测试，你会提炼哪些测试用例和测试点
MQ 消息内容验证（必答） 字段完整性：消息体字段不缺、不为 null 数据正确性：值、类型、枚举、状态与业务一致 格式规范性：JSON/protobuf 结构合法、无乱码 边界值校验：空串、超长、特殊字符、大消息 一致性校验：发送内容 = 接收内容，不篡改、不丢字段 完整 MQ 专项测试点（最终精简面试版） 1、功能测试 发送、消费、重试、死信、顺序消息、位点重置 2、消息内容验证 完整性、正确性、格式、边界、一致性 3、可靠性 不丢、不重、不乱、幂等、异常不丢失 4、性能 吞吐量、延迟、高并发无堆积 5、异常故障 Broker 宕机、网络断、消费阻塞、限流降级
Redis Hash 核心是结构化存储对象数据，专门解决单 key 下多属性存储的问题(多个 field-value 绑定到一个 key 下)，替代多个独立 String 键，节省内存且便于管理 1、Redis Hash 核心价值是结构化存储对象数据，替代多个独立 String 键，节省内存且便于管理； 2、支持对单个 field 独立操作，无需修改整个对象，提升操作效率； 3、典型场景：用户信息、商品属性、购物车等结构化数据存储
索引不是万能的，核心看「数据访问频率、修改频率、数据量」，以下场景不适合： 1、数据量极小的表（如配置表、字典表）：索引维护成本＞查询收益，全表扫描更快； 2、写远大于读的表（如日志表、秒杀订单表）：每次增删改都要维护索引，严重拖慢写入性能； 3、频繁更新的字段（如库存、状态字段）：索引会随字段更新频繁重构，消耗资源； 4、低区分度的字段（如性别、是否删除）：索引过滤效果差，全表扫描效率更高； 5、临时查询 / 一次性查询：创建索引的成本远高于单次查询收益，没必要； 6、大字段 / 超长文本（如 text/blob）：索引存储成本高，查询时回表开销大。
1、作用： 索引是数据库为指定字段生成的「有序映射表」，存储字段值和对应数据行的物理地址； 查询时先查索引（二分查找）定位地址，再取数据，替代全表扫描； 核心价值：将「逐行遍历」的低效操作，变成「有序快速查找」的高效操作。 2、创建索引： -- 给phone字段建普通索引（索引名：idx_user_phone） CREATE INDEX idx_user_phone ON user_info(phone); 3、映射表 索引值（phone） 对应数据行的物理地址 13800138000 磁盘地址 XXX 13800138001 磁盘地址 YYY 4、有索引时，还是SQL查询，只是逻辑变了 执行逻辑： 1）先查索引表（小且有序），用二分法 1ms 定位到「13800138000」对应的物理地址； 2）直接去磁盘该地址取数据，不用扫全表；
测试流程（精简面试版） 1、需求评审参与产品、开发、测试一起评审需求，明确业务逻辑、风险点、可测性。 2、测试计划 & 用例设计根据需求写测试点、测试用例，内部评审用例，确保覆盖主流程、异常、边界。 3、提测 / 冒烟测试开发提测后，先做冒烟测试，核心流程跑通才正式进入测试。 4、功能测试 + 回归测试按用例执行测试，提交缺陷，跟踪修复，修复后做回归。 5、接口 / 兼容性 / 性能等专项测试接口自动化、兼容性、线上环境验证，有必要时做性能、安全测试。 6、测试报告 & 上线评估输出测试报告，统计用例执行、缺陷情况，给出是否可上线结论。 7、上线后验证 & 线上监控上线后做线上回归，观察监控、日志，确保功能正常。
- 你工作中遇到过印象深刻的 bug 吗，简单说一下这个 bug 后续是怎么复盘的
我一般是两种结合，但以专项压测为主。 1、专项压测（常态）核心接口、核心链路单独压：比如登录、下单、支付、商品列表、MQ 消费、定时任务等目的：确认单机容量、阈值、性能瓶颈。 2、全项目 / 全链路压测（大促 / 版本前）上线前、大促前做一次混合场景、全链路压测模拟真实用户流量，看整体系统稳定性、是否有级联影响。 不管是专项还是全链路压测，我都会同步输出压测报告，标注性能瓶颈（如接口响应超时、数据库慢查询、MQ 堆积），并给出针对性优化建议（如接口缓存、数据库索引优化、服务扩容），联动开发落地优化，确保压测结果真正服务于系统性能提升。 一句话总结（直接背） 平时以核心接口专项压测为主，定位性能瓶颈；大促或重要版本前做全链路混合压测，保证整体系统稳定。
- 请介绍一下基于 AI 的 UI 自动化测试框架
- 简单介绍一下桑尼克框架
- APP 大版本更新时，UI 自动化脚本怎么维护
- 针对 UI 自动化，有做到对应的自动化集成吗
自动化集成，就是持续交付、持续集成 有，我做过完整的 UI 自动化集成，主要是这几块： 1、接入 Jenkins/GitLab CI代码提交、构建后，自动触发 UI 自动化脚本执行。 2、与项目流程集成一般放在冒烟 / 回归阶段，作为提测、合码、上线前的质量卡点。 3、结果自动上报自动生成测试报告，失败自动截图、录屏，推送到企业微信 / 钉钉 / 邮件。 4、环境自动准备配合 Selenium Grid、Docker 分布式执行，支持多浏览器、多设备并行跑。 5、失败自动重跑处理 UI 不稳定问题，排除偶然失败，提高通过率。
1、执行后的报告在 Allure/Extent 可视化页面，报错日志、失败截图都有； 2、集成到 Jenkins 后，可在 CI 平台 查看， 3、、同时会自动发到 钉钉 / 企业微信 告警。
- 你是怎么维护 UI 自动化框架的，数据和模板如何分层维护
我对 UI 自动化框架做了分层解耦维护，核心是「数据、模板、脚本分离」，具体这样做： 1. 框架整体维护 基础层抽离：把元素定位、驱动管理、通用操作（点击 / 输入 / 截图）封装成公共类，统一维护，改一处全框架生效； 版本 / 依赖管控：用 Pipfile/POM 管理依赖版本，定期升级 Selenium/Appium，做兼容性验证； 异常统一处理：封装重试、等待、异常捕获逻辑，避免脚本因环境抖动失败。 2. 数据分层维护 配置数据：环境地址、账号密码、超时时间等，存在yaml/ini配置文件，按环境（测试 / 预发）分文件； 测试数据：用例入参、预期结果，存在Excel/CSV/JSON，通过数据驱动读取，新增用例只加数据不改脚本； 敏感数据：密码、token 等存在加密配置中心，脚本解密使用。 3. 模板（页面 / 用例）分层维护 页面层（POM）：按页面拆分 Page Object 类，每个页面封装专属元素和操作（如登录页的login()方法），页面变更只改对应类； 用例层：用例只调用页面层方法，不写具体定位和操作，比如test_login()只调login_page.login(账号, 密码)； 模板复用：通用场景（如弹窗处理、数据校验）封装成用例模板，新功能直接复用。 面试一句话亮点版（直接背） 我按 POM 设计模式做分层维护：基础逻辑封装成公共类，测试数据存在配置文件 / Excel， 页面操作封装成 Page 类，数据和模板完全分离，改需求 / 改页面只动对应层，维护成本降低 60% 以上。 总结 1、框架维护核心是抽离公共逻辑，避免重复代码，统一管控依赖和异常； 2、数据分层：配置数据 / 测试数据 / 敏感数据分开存储，按环境隔离，支持数据驱动； 3、模板分层：POM 模式拆分页面和用例，页面变更不影响用例，复用性更高。
在我参与的项目里，三者精力占比大概是： 1、功能测试：60%～70% 2、自动化测试：10%～20% 3、性能测试：5%～10% 为什么是这个比例 1、功能是基础：需求迭代、回归、兼容性、异常场景，主要靠功能测试保证质量。 2、自动化做回归：只覆盖核心主流程，不追求全量，减少重复劳动。 3、性能是专项测试：只在大促、版本上线前、核心接口瓶颈时做，不常态化全量压测。
压测过程中 TPS 上不去，从测试性能角度有哪些可能的原因
TPS 上不去（服务端还没打满，压测端先限流） —— 性能测试角度排查（精简版） 1、压测机本身瓶颈（机器自身） 压测机 CPU、内存、网络带宽打满 压测工具线程数、连接数设置不够 2、接口 / 应用服务瓶颈 服务线程池、连接池太小 代码逻辑慢、同步阻塞、锁竞争 下游依赖（RPC/HTTP）响应慢 3、中间件瓶颈 Redis 卡顿、连接不够 MQ 消费慢、消息堆积 4、数据库瓶颈（最常见） 慢 SQL、没有索引 / 索引失效 连接池不足、锁等待、事务过大 DB 服务器 CPU/IO 高 5、压测场景不合理 并发数不够，加压不到位 数据不合理，导致大量等待 / 异常 一句话总结（直接说） 从压测机、应用服务、中间件、数据库、压测场景五个方向排查，优先看压机瓶颈、服务线程池、慢 SQL、连接池这四个最常见点。
1、服务线程池（业务线程池） 每进来一个请求，服务就要开一个线程去处理。（一个请求会绑定一个处理线程） 线程池 = 一群提前准备好的干活员工。 2、连接池（DB/Redis/RPC 连接池） 服务要查数据库、Redis、调其他服务，都需要建立连接。 连接池 = 提前建好的连接通道。 连接池太小 = 通往数据库的桥太窄，一次只能过几辆车。
