2026年3月软件测试面试自我介绍面试官您好，我叫xx，有 6 年软件测试经验。这这 6 年里，我主要负责过金融，电

自我介绍

面试官您好，我叫xx，有 6 年腾讯外派软件测试经验。

在这 6 年里，我主要负责过金融，电商和企业服务类项目的测试工作

从功能测试到自动化测试、性能测试都有涉及。

我熟练掌握 Python 自动化测试，能独立编写自动化脚本，使用 Pytest+Selenium 搭建 Web 自动化框架，也能用 Appium 做 App 自动化，同时会用 JMeter 做性能测试，能看懂开发代码逻辑。

比如在之前的电商项目中，我就基于这些技术设计了核心交易流程的自动化脚本，把回归测试时间从 3 天缩短到 4 小时；

同时通过性能测试发现支付接口并发超时问题，推动开发优化后，系统日活支撑能力提升了 30%。

对测试左移和 DevOps 流程比较了解，能和开发、产品团队高效协作。
以上是我的基本情况，请问您有什么想进一步了解的吗？

介绍一下最近的一个项目：

我最近做的一个项目是腾讯广告投放平台，主要给广告主做精准投放、数据监测和效果分析，支持信息流、视频、社交这些场景。
在项目中我主要负责四块内容：
一是核心功能全流程测试，从广告创建到数据分析全覆盖；
二是PC 端兼容性，测 Chrome、Firefox 这些主流浏览器；
三是 数据安全，保证数据准确、投放合规；
四是完整参与测试流程，需求评审、用例、回归、缺陷闭环
整体就是保障平台稳定，提升广告主使用体验。

项目问题：

1. 广告投放核心业务流程是什么？

广告主在 PC 端创建广告，选择投放场景（信息流 / 视频 / 社交），
设置定向、预算、排期后提交审核；
平台审核通过后上线投放，
后台实时数据监测，展示报表与转化分析，支持广告启停、修改和数据导出。

4. 遇到过严重缺陷吗？怎么处理？

遇到过**广告提交后状态不更新、数据报表漏统计**的缺陷。
我复现步骤、抓包 / 截日志，提交详细缺陷并标注影响；
持续跟进开发定位修复，修复后做全流程回归 + 兼容性验证，确保上线无风险。

补充：

一、支付流程测试（面试高频）

 支付测试我会从全流程、异常、一致性、接口、安全五个维度展开：

    1.  先覆盖正常流程，确保支付成功后订单、库存、账户正确；
    2.  重点测异常场景：超时、重复支付、弱网、渠道异常，保证不重复扣款；
    3.  测试接口：并发支付，高峰阶段数据一致性。
    5.  最后做安全与性能，防篡改、防越权。

二、电梯测试

  功能、边界值、安全、异常、场景覆盖，
 1. 功能测试：内外呼按钮、楼层显示、开关门、平层精度、上下行正常。 
 2. 边界测试：空载、额定载重、超载（报警不运行）、超重保护。 
 3. 安全测试：断电应急照明与对讲、门光幕防夹、急停开关、限速器安全钳、冲顶/蹲底保护、消防模式。
 4. 场景测试：多人同时呼梯、连续指令、中途拦截关门、故障困人救援逻辑。 
 核心原则：安全第一，所有保护装置必须有效。

三、水杯 & 笔测试

 ### （1）水杯测试 从**功能、性能、安全、界面、兼容性、异常**设计： 
 - 功能：装水不漏水、开合顺畅、刻度准确。 
 - 边界：装热水/冰水、满水/空杯。 
 - 性能：保温时效、防摔、材质耐热耐冷。 
 - 安全：无毒无异味、倾倒防烫、杯盖无尖锐边角。 
 - 异常：跌落、撞击、高温暴晒、低温冷冻后的状态。 
 ### （2）笔测试 
 - 功能：书写流畅、不断墨、不晕染、笔帽松紧合适。 
 - 边界：极限角度书写、快用完墨时状态。 
 - 性能：不同纸张（宣纸/牛皮纸/光滑面）适配、防水耐晒。 
 - 异常：跌落、挤压、高温低温、笔帽丢失后是否漏墨。 
 - 安全：笔身无毛刺、笔芯无毒、儿童防误食结构。

四、http请求过程会经历什么？

    HTTP 请求核心是 “DNS 解析→TCP 连接→发请求→服务器响应→渲染页面”，测试关注状态码和异常处理。
    测试视角补充：我们测试时会重点关注请求的状态码、响应时间、参数传递是否正确，以及断网 / 弱网下请求重试、超时的异常处理。

五、网络七层模型

OSI 七层模型从下到上是物数网传会表应，每层独立且为上层提供服务，测试重点在传输层和应用层。

六、什么是单元测试？

单元测试是测最小可测试单元，独立、自动化，测试岗关注其覆盖率和问题定位价值。
举例：比如测试一个 “计算订单金额” 的函数，单元测试会输入不同参数（原价、折扣、优惠券），验证输出是否等于预期金额，同时测试参数为空、折扣大于 1 等异常场景。

七、浅拷贝和深拷贝

浅 / 深拷贝核心区别是 “是否复制嵌套对象”，测试中复杂数据拷贝优先用深拷贝避免数据污染。
浅拷贝：
定义：只复制对象的 “表层结构”，对于嵌套的引用类型（比如列表里的子列表、对象里的子对象），只复制引用（地址），不复制实际数据。

特点：原对象和拷贝对象的嵌套数据会互相影响（改一个，另一个也变）。
深拷贝：
定义：完全复制对象的所有层级（包括嵌套的引用类型），生成一个全新的独立对象，原对象和拷贝对象互不影响。

特点：占用更多内存，但数据完全隔离。

补充二

1. 说一下之前公司的测试流程

公司软件测试流程，通常参与需求评审，梳理测试点；编写测试用例并评审，开发提测后先做冒烟测试，通过后执行功能、接口等测试，提交并跟踪缺陷；修复后回归测试，输出测试报告，给出上线结论，上线后跟进问题闭环。

2. 测试报告都有哪些内容？

测试报告包含：项目概述、测试范围、环境信息、用例执行统计、缺陷分布与遗留问题、风险评估、测试结论与上线建议。

3. bug级别，和 bug生命周期

Bug 级别（4 级）
致命：系统崩溃、核心不可用；
严重：核心功能失效；
一般：普通功能缺陷；
轻微：UI / 文案问题。

Bug 生命周期
新建→确认→修复→验证→关闭；异常：可拒绝、重新打开、延期处理。

4. 给你一个网站怎么测？

先测功能（链接、表单、登录、交互）
再测兼容（浏览器 / 设备）
易用性、性能（加载速度）
安全（XSS、SQL 注入）
最后UI与回归，输出测试报告。

5. web 和 app 测试区别

Web 侧重浏览器兼容、页面加载、URL、缓存、跨域；
App 多安装 / 卸载、升级、中断、电量流量、横竖屏、权限、弱网、推送，还需适配不同机型系统，Web 无需考虑。

6. 小程序和app测试区别

小程序依赖微信 / 支付宝容器，侧重入口、分享、授权、缓存清理、热更新、兼容性；
原生 App 需测安装卸载、升级、推送、权限、弱网、机型适配、崩溃，还涉及离线功能，小程序无完整安装流程。

7. android 和 ios 测试区别

Android 机型、系统版本碎片化严重，侧重权限、兼容性、返回键、后台管理；
iOS 封闭统一，侧重审核规则、手势操作、沙盒机制、推送。Android 安装包灵活，iOS 上架严格，权限申请逻辑、交互规范差异大。

8. alpha和beta测试区别

Alpha 是内测，在公司内部、开发环境由测试 / 产品测，版本不稳定；
Beta 是公测，发布给外部真实用户，在真实环境使用，版本较稳定，收集反馈优化。Alpha 先于 Beta，一个内部、一个外部。

9. 测试报告怎么写？

项目概述：目的、范围、版本、测试周期；

测试环境：硬件、系统、工具、数据；

测试执行：用例数、通过率、覆盖情况；

缺陷统计：级别分布、已修复 / 遗留数、未闭原因；

风险评估：潜在问题、影响范围；

测试结论：是否通过、上线建议。

10. 测试计划包括哪些？

包含项目背景、测试范围、测试策略、测试资源、进度安排、测试环境、准入准出标准、风险与应对、交付物清单，明确测试目标、方法及保障措施。

11.get和post区别 http 和 https区别

GET 参数在 URL 可见，有长度限制，可缓存，用于查询数据，不安全；
POST 参数在请求体，无大小限制，不缓存，用于提交数据，更安全。
HTTP 明文传输，端口 80，无加密，不安全；
HTTPS 基于 SSL/TLS 加密，端口 443，需证书，防窃听篡改，更安全。

12. cookie 和 token session 区别

Cookie 是**客户端存储工具**，
Session 是**服务端有状态会话**，
Token 是**客户端无状态凭证**；
单体用 Session，分布式用 Token，Cookie 是基础存储载体。

13. 三次握手四次挥手

三次握手（建立连接）
    客户端发 SYN，
    服务端回 SYN+ACK，
    客户端再回 ACK，
    三次确认后建立可靠连接

四次挥手（断开连接）
     客户端发 FIN，
     服务端回 ACK；
     服务端发 FIN，
     客户端回 ACK，
     双方确认后断开连接

14. fiddler抓包原理

把自己设为浏览器 / APP 的**HTTP/HTTPS 代理**，请求先经过 Fiddler，再转发给服务器；响应先回 Fiddler，再发给客户端，实现**中间人抓取、查看、修改数据包**。

15. fiddler如何定位前后端bug

通过 Fiddler 查看请求与响应：
    1.  前端 Bug：请求参数错误、缺失、格式不对，后端无问题。
    2.  后端 Bug：请求参数正确，但返回数据错误、状态码异常、逻辑错误。
    一句话：看请求判前端，看响应判后端。

16. 接口测试用例具体怎么设计

从**参数、业务、异常、安全**四方面设计：

1.  正常用例：必填 + 可选参数合法，验证返回正确
1.  异常用例：必填为空、类型错误、长度超限、重复提交
1.  边界用例：极值、边界值、特殊字符
1.  业务用例：权限、状态流转、关联接口依赖覆盖**正向、反向、边界、安全。

17. 什么时候进行接口测试？你们公司接口测试是如何做的？

什么时候测：
    后端接口开发完成、前端联调前就开展，越早越好，提早在接口层发现问题，降低联调成本。

怎么做：
    用JMeter编写用例，做参数、业务、异常、边界测试；结合断言 + 参数化，做自动化回归，持续集成验证接口稳定性。

18. 接口测试content type常见的类型

常见：
form-urlencoded**（表单）
multipart/form-data（上传）
application/json**（主流）
还有xml、plain

19. mokey了解吗？工作中如何应用？

Monkey 是什么
    Android 自带的随机压力测试命令，
    模拟用户随机点击、滑动、输入，用来找崩溃、ANR、内存泄漏。

工作中怎么用
    执行 `adb shell monkey` 命令，设定事件数、频率、包名，
    长时间随机操作，发现偶现崩溃；
    结束后导出日志，定位崩溃 / ANR 问题，提交开发修复，保障 APP 稳定性。

20. 微信视频测试点

 1. 播放：正常、暂停、拖拽、全屏、静音 
 2. 收发：拍摄、发送、撤回、转发 
 3. 中断：来电、切后台、锁屏恢复 
 4. 网络：WiFi、弱网、断网重连 
 5. 兼容：不同手机、系统、微信版本 
 6. 异常：权限、存储、崩溃、花屏

21.微信聊天测试点

1. 收发：文字、表情、图片、语音 
2. 操作：撤回、删除、转发 
3. 中断：来电、切后台、重启恢复 
4. 网络：弱网、断网重发 
5. 异常：权限、存储不足、闪退 
6. 兼容：单聊、群聊、多机型

22. 优惠卷怎么测？

1.功能测试：领取，查看，使用，过期，删除
2.规则测试：满减条件，有效期，适用商品和用户
3.流程测试：下单抵扣，支付，取消订单，退款
4.叠加测试：优惠券之间能否叠加，与活动互斥
5.异常测试：重复领取，已使用，跨店使用，超出限额

23. 添加到购物车的测试点

1. 正常添加商品到购物车，数量默认1 
2. 修改商品数量、规格，添加成功 
3. 重复添加同一商品，数量正确累加 
4. 库存不足、下架商品无法添加 
5. 清空、删除、选中购物车商品结算

24 直播功能怎么测？

1. 开播、推流、画面清晰、声音正常、无卡顿延迟
2. 公屏聊天、点赞、送礼、评论、分享正常
3. 商品上架、讲解、购物车、下单、支付流程
4. 网络切换、弱网、断网重连后恢复直播 
5. 中断场景：来电、切后台、锁屏、重进直播间 
6. 权限校验：麦克风、摄像头、通知权限 
7. 异常场景：主播下播、违规断播、观众闪退恢复 
8. 兼容性：不同机型、系统、网络环境适配

25. 购物车功能怎么测？

1. 单个商品正常加入购物车，数量默认1 
2. 选择不同规格、属性的商品加入，展示正确 
3. 多次加入同一商品，数量正确累加 
4. 修改购物车商品数量，增减、边界值校验 
5. 删除单个、选中、清空全部购物车商品 
6. 库存不足、已下架商品无法结算 
7. 选中商品合计金额计算准确 
8. 跨店铺、多商品批量勾选结算 
9. 登录状态同步，退出后清空或保留 
10. 优惠券、满减活动与购物车联动正常

一功能测试问题 3月2日

1. 请介绍一下功能测试的定义和目的？

功能测试是验证软件功能是否符合需求规格说明书的测试，通过模拟用户操作场景，
检查功能是否正常实现、输入输出是否正确、业务流程是否通畅等，
目的是确保软件功能满足用户需求，避免因功能缺陷影响用户使用。

2. 功能测试的用例设计方法有哪些？请举例说明等价类划分法。

常用方法有等价类、边界值、场景法、因果图、判定表。
比如测试登录功能的用户名，
有效等价类可能是“6-18位字母数字组合”，无效等价类有“少于6位”“包含特殊字符”等，分别取例子测试。

3. 测试用例的核心要素有哪些？

通常包括用例ID、模块、标题、前置条件、输入数据、操作步骤、预期结果、实际结果、优先级、状态等。

4. 发现bug后，你的处理流程是什么？

首先复现bug，确认是否可稳定复现；然后收集详细信息，包括环境、步骤、截图/日志；
接着提交bug到管理工具，明确描述问题；之后跟踪bug状态，与开发沟通；修复后回归测试，
通过则关闭，不通过则重新打开。

5. 如果开发认为你提的bug不是问题，是需求设计如此，你会怎么做？

先查阅需求文档，确认是否与需求描述一致；如果需求不明确，与产品经理沟通确认需求意图；
若确实是需求设计，且不影响用户使用，则关闭bug并记录原因；
若需求存在歧义但实际影响功能，需推动产品澄清需求并确认是否需要修改。

6. 功能测试和集成测试的区别是什么？

功能测试关注单个功能模块是否符合需求，通常在单元测试和集成测试之后进行；
集成测试关注模块之间的接口是否正确，验证模块组合后能否正常协同工作，重点在接口和数据传递。

7. 如何保证功能测试的覆盖率？

参考需求文档和用例设计方法设计用例，确保覆盖所有功能点；使用用例评审，
让团队成员检查是否有遗漏；执行时记录实际覆盖的功能，对比需求进行查漏；
对复杂功能采用场景法，覆盖正常、异常、边界等多种场景。

8. 测试过程中，如果遇到需求变更，你会怎么处理？

首先评估需求变更对现有测试用例的影响，确定需要新增、修改或删除的用例；
更新测试计划和用例文档；与开发同步变更内容，确认修改范围；
重新执行受影响的测试用例，确保变更后的功能正确且不引入新问题。

9. 请描述一个你之前项目中印象深刻的bug，以及你是如何发现和推动解决的？

比如在电商项目中，发现“提交订单时，选择优惠券后总价计算错误”。
复现步骤：选择商品→加入购物车→结算→选择某优惠券→查看总价。
预期总价应为商品价减优惠券面额，实际未减。提交bug后，开发定位是优惠券规则逻辑错误，
修复后回归测试通过。关键在于详细记录步骤和数据，帮助开发快速定位。

10. 功能测试中，你会关注哪些非功能方面的点吗？

虽然功能测试重点在功能正确性，但也会关注一些基础的易用性问题，
比如按钮位置是否直观、操作流程是否繁琐；
还有兼容性，比如在不同浏览器/设备上功能是否正常显示和使用；
以及初步的性能表现，比如简单操作是否有明显卡顿，但深入的非功能测试会交给专项测试。

11. 什么是回归测试？什么情况下需要进行回归测试？

回归测试是指软件修改后，重新执行之前的测试用例，确保修改没有引入新的缺陷，且原有功能依然正常。
需要回归的情况包括：开发修复bug后、需求变更导致功能修改后、版本迭代新增功能后。

12. 测试用例执行完成后，还有哪些工作要做？

整理测试报告，汇总测试情况、用例执行率、bug数量及状态；
对未解决的bug进行风险评估，判断是否影响上线；归档测试文档，包括用例、报告、日志等；
参与项目复盘，总结测试过程中的问题和经验。

13. 你认为一个优秀的功能测试工程师需要具备哪些素质？

熟悉业务需求，能准确理解用户场景；
掌握用例设计方法，能设计全面的测试用例；
具备细心和耐心，善于发现细节问题；
良好的沟通能力，能与开发、产品有效协作；
较强的问题分析和定位能力，能辅助开发排查原因；
持续学习能力，适应不同项目和技术的变化。

14. 如何测试一个登录功能？请列出关键测试点。

正常登录：正确用户名+正确密码→成功登录；
错误场景：用户名不存在、密码错误、用户名/密码为空、输入特殊字符、验证码错误/过期；
边界值：用户名/密码长度为最小值、最大值；
安全性：密码是否明文显示、登录失败次数限制、session是否有效；
其他：记住密码功能、自动登录功能、登录后跳转页面是否正确。

15. 如果项目时间紧张，测试任务无法按时完成，你会怎么办？

首先与项目经理沟通，说明当前测试进度和剩余工作量；根据用例优先级，优先执行核心功能和高优先级用例，
确保主要功能无问题；
简化非核心功能的测试深度，或采用抽样测试；若仍无法完成，建议是否可以延期，或协调资源增加测试人力，
同时确保已执行部分的测试质量。

二性能测试问题 3月3日

1. 什么是性能测试？

性能测试是通过模拟真实用户场景，对软件系统的响应时间、吞吐量、并发用户数、资源利用率等
性能指标进行测试，验证系统是否满足性能需求，发现性能瓶颈的过程。

2. 性能测试的常见指标有哪些？

主要包括响应时间、吞吐量、并发用户数、资源利用率、错误率、点击率、思考时间等。

3. 响应时间和吞吐量的区别是什么？

响应时间是单个用户请求从发出到收到响应的时间，关注单个用户体验；
吞吐量是单位时间内系统处理的请求数或数据量，关注系统整体处理能力。

4. 性能测试的流程是什么？

通常包括需求分析、测试计划制定、测试环境搭建、测试脚本开发、
测试场景设计与执行、结果分析与调优、报告输出这几个阶段。

5. 什么是负载测试、压力测试、容量测试？

负载测试是在预期负载下测试系统性能；
压力测试是逐步增加负载，直到系统性能崩溃，找出最大承载能力；
容量测试是确定系统能处理的最大数据量。

6. 性能测试中为什么要设置思考时间？

模拟真实用户操作习惯，用户在执行下一个操作前会有停顿，
加入思考时间能让测试场景更接近真实情况，避免测试结果失真。

7. 如何分析性能测试结果？

先看关键指标是否达标，再检查资源利用率是否有瓶颈，然后结合日志和监控工具定位具体瓶颈点，
比如数据库慢查询、接口响应慢、服务器配置不足等。

8. 性能测试脚本开发时需要注意什么？

要参数化动态数据，避免脚本固化；添加事务来统计关键操作的响应时间；
设置合理的思考时间；处理关联，确保请求的正确性；脚本需要进行调试和优化。

9. 什么是性能瓶颈？常见的性能瓶颈有哪些？

性能瓶颈是导致系统性能不满足需求的环节。
常见的有CPU瓶颈、内存瓶颈、磁盘I/O瓶颈、网络瓶颈、数据库瓶颈、应用服务器瓶颈等。 
不同系统的瓶颈指标和阈值差异很大，得看具体场景。
比如 CPU 瓶颈，通常当 CPU 使用率持续超过 80%-90%，且系统响应变慢，可能就是瓶颈了。
内存瓶颈的话，物理内存使用率接近 100%，开始大量使用交换空间，应用就容易卡顿或崩溃。
磁盘 I/O 瓶颈，一般看 IOPS 或吞吐量，比如机械硬盘 IOPS 到几百就可能瓶颈，SSD 能到几万，但如果实际业务需求超过这个值，读写延迟就会飙升。
网络瓶颈，当带宽使用率长期接近上限，或者网络延迟、丢包率明显增加，数据传输就会受影响。
这些数值不是绝对的，得结合具体业务负载和系统配置来看

10. 数据库性能瓶颈通常有哪些表现？如何优化？

表现为慢查询、连接数不足、锁竞争等。
优化方法有索引优化、SQL语句优化、增加缓存、分库分表、调整数据库参数等。

11. 性能测试环境和生产环境有什么关系？

性能测试环境应尽量模拟生产环境，包括硬件配置、软件版本、数据量、网络环境等，
这样测试结果才更有参考价值。如果无法完全一致，需注明差异并评估对结果的影响。

12. 什么是并发用户数和在线用户数？

在线用户数是指同时登录系统的用户数量，这些用户可能处于 idle 状态；
并发用户数是指同时向系统发送请求的用户数量，是真正对系统产生压力的用户数。

13. 性能测试中如何模拟大量并发用户？

通过性能测试工具，设置虚拟用户数，让工具同时发送请求来模拟真实用户的并发操作。

14. 性能调优的步骤是什么？

首先通过性能测试定位瓶颈点，然后针对瓶颈点提出优化方案，
实施优化后再次进行性能测试验证效果，若未达标则重复以上步骤，直到性能满足需求。

15. 你在性能测试中常用的工具是什么？

LoadRunner、JMeter、Gatling等用于脚本开发和场景执行；
监控工具如Nmon、Zabbix、Prometheus+Grafana等；
数据库分析工具如MySQL的Explain、SQL Server的Profiler等。

16. 性能测试前需要准备哪些数据？

需要准备基础测试数据，数据量应接近生产环境；
还需要准备测试脚本中用到的参数化数据，如用户账号、请求参数等。

17. 什么是吞吐量和TPS？

吞吐量是单位时间内系统处理的请求数或数据量，单位可以是请求数/秒、字节/秒等；
TPS是每秒事务数，是吞吐量的一种具体表现形式，指每秒完成的业务事务数量。

18. 性能测试中如果发现响应时间过长，你会从哪些方面排查？

先检查网络是否有延迟或丢包；再看应用服务器的CPU、内存、线程数等是否正常；
然后检查数据库是否有慢查询、锁等待；
最后检查应用代码是否有性能问题，比如循环过多、未释放资源等。

19. 什么是集合点？为什么要使用集合点？

集合点是在脚本中设置的一个同步点，让多个虚拟用户在执行到该点时等待，
直到达到指定数量的用户后再同时继续执行，用于精确模拟高并发场景，
比如秒杀时大量用户同时提交订单。

20. 性能测试报告应该包含哪些内容？

包括测试目的、测试环境、测试场景、测试结果、性能瓶颈分析、优化建议、结论等部分，
结果部分要列出关键指标的实际值与目标值对比。

三接口测试问题

1. 什么是接口测试？

接口测试是对系统组件间接口进行的测试，验证接口功能、性能、安全性等是否符合需求。

2. 接口测试的核心关注点有哪些？

包括功能正确性、参数校验、返回值验证、错误处理、安全性、性能、兼容性等。

3. 常用的接口测试工具有哪些？

Postman、JMeter、SoapUI、RestAssured、Charles等。

4. 接口测试中如何处理依赖接口？

可以通过前置步骤调用依赖接口获取返回数据，作为当前接口的入参，比如在JMeter中用后置处理器提取变量。

5. 如何设计接口测试用例？

根据接口文档，覆盖正常场景、异常场景，用等价类、边界值等方法设计，包含请求参数、预期响应。

6. 接口返回的JSON数据如何校验？

可以用工具自带的断言功能，或编写脚本解析JSON后对比字段值、类型、结构。

7. 接口测试中各种返回码代表什么意思？

1xx：信息类（几乎不用管）
2xx：成功（你想要的结果）
3xx：重定向（一般不用处理）
4xx：客户端错（你的锅 / 前端锅）
5xx：服务端错（后端锅）

8. 如何保证接口测试的有效性？

定期更新用例、覆盖全场景、结合自动化持续执行、与开发同步接口变更。

9. 接口自动化测试的流程是什么？

先梳理接口文档，设计测试用例，选择工具或框架编写脚本，执行脚本并分析结果，持续维护用例。

10. 接口测试中如何模拟不同的网络环境？

用JMeter的网络限制插件，或Charles的节流功能设置带宽、延迟、丢包率。

11. 什么是接口的幂等性？如何保证？

幂等性指多次调用同一接口结果一致，可通过唯一ID、版本号、状态机等方式保证。

12. 接口测试中如何处理加密参数？

先了解加密算法，在请求前对参数加密，响应后解密再校验。

13. 接口测试和UI测试的区别是什么？

接口测试测后端接口，不依赖界面，更稳定、效率高；UI测试测用户界面，关注交互和视觉。

14. 如何进行接口的性能测试？

用JMeter等工具模拟多用户并发请求，监控响应时间、吞吐量、错误率等指标。

15. 接口文档重要吗？如果没有接口文档怎么测？

重要，是测试依据。没有的话，可通过抓包分析接口参数和返回，或与开发沟通获取信息。

四自动化测试问题

web自动化 Pytest+Selenium

1. Selenium 中 8 种元素定位方式是什么？

id、name、class name、tag name、link text、partial link text、xpath、css selector。

2. 如何处理 iframe？

先通过 switch_to.frame () 切入，操作完后用 switch_to.default_content () 切回主文档。

2.1 定位不到怎么办？

定位失败优先从**元素存在性、定位表达式、等待机制、iframe / 窗口切换、动态属性、隐藏元素、Shadow DOM**这几个方面排查，通过**优化稳定定位 + 显式等待 + 处理页面结构**来解决

3. 如何处理 alert 弹窗？

用 switch_to.alert.accept () 接受，dismiss () 取消，text 获取文本。

4. 什么是隐式等待和显式等待？区别？

答案：隐式等待是全局设置，等待元素出现，单位秒；显式等待针对特定元素，设置条件和超时时间，更灵活。

5. 如何处理下拉框？

用 Select 类，select_by_value ()、select_by_visible_text ()、select_by_index () 选择选项。

6. 如何处理浏览器窗口切换？

用 driver.window_handles 获取所有窗口句柄，通过 switch_to.window (句柄) 切换，通常结合索引或标题定位。

7. Selenium 中 get () 和 navigate ().to () 的区别？

功能类似，get () 会等待页面加载完成再执行下一步，navigate ().to () 不会等待，且 navigate () 还有 back ()、forward ()、refresh () 方法。

8. 如何处理文件上传？

如果是 input 标签，直接 send_keys (文件路径)；非 input 标签需用 AutoIt、SendKeys 等工具。

9. 如何实现用例失败重试？

答案：使用 unittest 的装饰器 @retry，或 pytest 的 pytest-rerunfailures 插件配置重试次数和间隔。

10. 如何处理动态元素？

用显式等待 + xpath 的 contains、starts-with 等模糊匹配，或通过父元素定位子元素。

11. Selenium Grid 的作用？

实现分布式测试，可在多台机器、多个浏览器上并行执行用例，提高测试效率。

12. 如何禁止浏览器加载图片？

通过浏览器选项设置，如 
ChromeOptions ().add_experimental_option ("prefs", {"profile.managed_default_content_settings.images": 2})。

UI自动化

1. 自动化测试的流程是什么？

需求分析→选择工具和框架→编写测试用例→搭建环境→开发脚本→执行脚本→分析结果→维护脚本。

2. 自动化测试的优缺点？

优点：提高回归测试效率、覆盖更全面、减少人为错误；缺点：初期投入大、维护成本高、不适合频繁变动的 UI。

3. 什么情况下不适合做自动化测试？

需求频繁变化、测试周期短、UI 不稳定、一次性项目。

4. 如何设计可维护的自动化测试脚本？

采用页面对象模型、模块化设计、数据驱动、关键字驱动，避免硬编码。

5. 自动化测试发现 bug 后如何处理？

重现 bug，确认是否为脚本问题，若不是则提交给开发，标记脚本为失败用例。

6. 页面对象模型 (POM) 的优势？

提高代码复用性、可维护性，测试用例更清晰，分离页面元素和测试逻辑，便于多人协作。

7. 数据驱动和关键字驱动的区别？

数据驱动是用不同数据执行同一脚本，关键字驱动是将操作封装为关键字，用表格管理关键字和数据。

8. 自动化测试脚本为什么需要维护？

需求变更导致 UI 元素变化、页面逻辑修改、新功能添加，需要更新脚本以保证有效性。

9. 如何选择自动化测试工具？

根据项目类型、技术栈、团队熟悉度、成本等，比如 Web 选 Selenium，APP 选 Appium，桌面应用选 AutoIt。

10. 自动化测试与手动测试的关系？

自动化不能完全替代手动，适合回归、冒烟等重复测试，手动适合探索性、新功能、UI 细节测试，两者互补。

11. 什么是持续集成 (CI)？自动化测试如何融入 CI？

CI 是频繁将代码集成到主干并自动构建测试，自动化测试可配置在 CI 流程中，每次代码提交后自动执行，快速反馈问题。

12. 自动化测试用例的设计原则？

选择核心功能、高频执行的用例，避免依赖复杂前置条件，确保用例独立、可重复执行。

app自动化

1. Appium 的工作原理？

客户端发送请求，Appium Server 解析后转发给对应的驱动，驱动与设备通信执行操作，结果返回给客户端。

2. 如何获取 APP 的包名和启动名？

通过 adb 命令：adb shell dumpsys window | findstr mCurrentFocus，或用 aapt dump badging 应用.apk。

3. 如何处理 APP 的滑动操作？

使用 TouchAction 类的 press、move_to、release 方法，或用 swipe () 方法，传入起始和结束坐标。

4. APP 自动化中常见的定位方式有哪些？

除了 Selenium 的 8 种，还有 accessibility id、android uiautomator、ios predicate string 等。

5. 如何处理 APP 的安装和卸载？

用 driver.install_app (apk 路径) 安装，driver.remove_app (包名) 卸载，driver.is_app_installed (包名) 判断是否安装。

6. Appium 支持的自动化引擎有哪些？

Android 支持 UiAutomator2、Espresso，iOS 支持 XCUITest，旧版本还支持 Selendroid。

7. 如何模拟手机的按键操作？

用 driver.press_keycode (键码)，比如 Home 键 3、返回键 4、电源键 26。

8. APP 自动化中如何处理 Toast 消息？

用显式等待 + xpath 定位，因为 Toast 是动态元素，持续时间短，需设置较短的轮询间隔。

9. 如何实现 APP 的多设备并行测试？

使用 Appium Grid 搭建节点，配置不同设备的 desired_caps，通过测试框架并发执行用例。

10. 什么是 desired_caps？有哪些常用参数？

是一组键值对，告诉 Appium Server 测试的平台、设备、应用等信息，常用参数：platformName、deviceName、appPackage、appActivity、automationName。

11. 如何处理 APP 的手势操作？

使用 TouchAction 或 MultiTouchAction 类，如 tap 点击、long_press 长按、pinch 缩放等。

12. APP 自动化中遇到安装失败的原因可能有哪些？

设备未连接成功、apk 包损坏、设备存储空间不足、应用已存在且签名不一致、系统版本不兼容。

13.adb 核心必背命令：

`adb devices`/`install`/`uninstall`/`logcat`/`shell am start/force-stop`/`pull/push`
 adb shell input keyevent <按键码> # 模拟按键

五 linux测试问题

0. 创建文件 touch 修改文件名 mv 旧名姓名

1. 看日志：

tail -f、grep

2. 查端口：

netstat、ss、lsof

3. 查进程：

ps -ef、kill -9

4. 查文件：

find

5. 磁盘内存：

df -h、free -h、top

6. 解压：

tar -zxvf

7. 编辑：

vim → i → ESC → :wq

8. 权限：

chmod 755 权限：读 4、写 2、执行 1

9. 传文件：

scp

10. 排查：ping → 端口 → 日志 → 进程 → 磁盘

ping 看网络通不通
telnet IP 端口 看端口通不通
用 tail -f 看实时日志
grep 搜报错关键字
看进程是否存在 ps -ef | grep xxx
看磁盘是否满 df -h

六数据库测试问题

1. WHERE 和 HAVING 区别

- WHERE：分组前过滤，不能用聚合函数 
- HAVING：分组后过滤，可以用聚合函数 
- 执行顺序：WHERE → GROUP BY → HAVING

2. IN 和 EXISTS 区别

- IN：先执行子查询，再执行主查询，适合子查询结果集小 
- EXISTS：主查询逐条匹配子查询，适合主查询数据量小、子查询大

3. DELETE、TRUNCATE、DROP 区别

- DELETE：DML，可加WHERE，可回滚，不清自增 
- TRUNCATE：DDL，清空全表，不可回滚，清自增，速度快 
- DROP：DDL，删表结构+数据，不可回滚

4. 内连接、左连接、右连接区别

- INNER JOIN：只返回两表匹配的数据 
- LEFT JOIN：返回左表全部，右表匹配，不匹配为NULL 
- RIGHT JOIN：返回右表全部，左表匹配，不匹配为NULL

5. UNION 和 UNION ALL 区别

- UNION：去重并排序，效率低 
- UNION ALL：直接合并，不去重，效率高

6. MySQL 分页 SQL

```sql SELECT * FROM 表 LIMIT (页码-1)*每页条数, 每页条数;  
二、索引高频题

1. 什么是索引？测试为什么关注？

索引是提升查询速度的数据结构（如B+树）。 
测试关注：索引影响接口性能、性能测试瓶颈、慢SQL定位。

2. 常见索引类型

- 主键索引 - 唯一索引 - 普通索引 - 复合索引 - 全文索引

3. 最左前缀原则

复合索引(a,b,c)，查询必须从左到右连续匹配才走索引。 
如 where a=? and b=? 走索引；where b=? 不走。

4. 索引失效场景（高频）

- 字段使用函数/运算 
- LIKE '%xx' 以%开头 
- 隐式类型转换 
- OR 连接非索引字段 
- 复合索引不满足最左前缀
- 数据量太小优化器走全表

5. 如何查看SQL是否走索引

使用 EXPLAIN 
- key：显示索引名则走索引，NULL 不走 
- type：ALL 为全表扫描
三、事务与隔离级别（必考）

1. 事务 ACID

- 原子性：不可分割，全成功或全回滚 
- 一致性：事务前后数据完整一致 
- 隔离性：并发事务互不干扰 
- 持久性：提交后永久生效

2. 事务并发三大问题

- 脏读：读到未提交数据 
- 不可重复读：同一事务内两次查询结果不同（update） 
- 幻读：同一事务内记录数变了（insert/delete）

3. 四大隔离级别（MySQL）

1. READ UNCOMMITTED（读未提交） 
2. READ COMMITTED（读已提交）
3. REPEATABLE READ（可重复读，MySQL默认）

4. SERIALIZABLE（串行化）

四、锁机制高频题

1. 乐观锁 vs 悲观锁

- 悲观锁：操作前加锁，阻塞其他事务，适合写多 
- 乐观锁：不加锁，用版本号控制，适合读多

2. 什么是死锁？如何避免？

死锁：多个事务互相持有对方需要的锁，无限等待。 
避免： - 按固定顺序访问资源 - 缩短事务 - 使用乐观锁 - 设置超时时间 
五、测试场景题（测试岗专属）

1. 接口测试如何做数据库断言

- 增删改：执行后查库，校验数据是否正确 
- 查询：对比接口返回与库中数据一致 
- 异常：校验事务回滚后数据恢复

2. 性能测试数据库瓶颈分析

- 开启慢查询日志定位慢SQL 
- EXPLAIN分析索引 
- 查看锁等待、连接数、CPU/IO 
- 分析是否需要加索引、分库分表

3. 如何构造测试数据

- 单条：INSERT 
- 批量：INSERT ... VALUES(...),(...) 
- 复制表：INSERT INTO ... SELECT ... 
- 存储过程/脚本造压测数据

4. SQL注入及防范

通过拼接SQL非法操作数据库。 
防范： 
- 使用预编译语句 
- 参数校验过滤 
- 最小权限原则 
- 禁止字符串拼接SQL 
六、高级拓展（大厂常问）

1. 主从复制作用

主库写、从库读，实现读写分离、故障转移、数据备份。 
测试关注：主从数据一致性、读写分离是否生效。

2. 分库分表

解决单库/单表数据量过大问题。 
测试关注：路由正确性、跨表聚合、分布式事务。

七安全测试问题

一、基础概念类（必问）

1. 什么是SQL注入？如何测试？如何防御？

SQL 注入是恶意构造 SQL 语句，非法获取 / 篡改数据库。
测试：输入`' or 1=1--`等 payload 看是否绕登录、查数据。
防御：预编译语句（参数化查询） 、禁用拼接 SQL、权限最小化、输入过滤。


- 定义：攻击者在输入框拼接SQL语句，绕过验证或直接操作数据库。 
- **测试方法**： 
1. 输入单引号 `'` 看是否报错 
2. 输入 `or 1=1--` 尝试绕过登录 
3. 联合查询 `union select 1,2,3` 探测字段数 
4. 工具：SQLmap自动化扫描 
- **防御**： 
1. 预编译语句/参数化查询（最有效） 
2. 输入过滤与校验 
3. 最小权限原则 
4. 禁用数据库错误回显 ###

2. 什么是XSS？分类？测试与防御？

XSS 是跨站脚本攻击，注入恶意脚本窃取信息。
分三类：**存储型、反射型、DOM 型**。
测试：输入`<script>alert(1)</script>`看是否执行。
防御：**输入过滤、输出编码、CSP、HttpOnly**。


- **定义**：跨站脚本攻击，攻击者向页面注入恶意JS脚本，窃取Cookie、会话等。 
- **分类**： 
1. 反射型XSS（一次性，通过URL触发） 
2. 存储型XSS（存入数据库，所有访问者中招，危害最大） 
3. DOM型XSS（前端JS处理不当导致） 
- **测试**：
输入 `<script>alert(1)</script>` 等payload看是否执行 
- **防御**： 
1. 对输入进行HTML转义 
2. 使用CSP（内容安全策略） 
3. HttpOnly Cookie 防止脚本读取

3. 什么是CSRF？如何测试和防御？

CSRF 即跨站请求伪造，攻击者冒用用户身份执行非法操作。
测试：构造恶意链接 / 页面，验证是否直接执行操作。
防御：Token 校验、验证码、Referer 校验、SameSite Cookie。


- **定义**：跨站请求伪造，攻击者诱导用户在已登录状态下执行非本意操作。
- **测试**：构造第三方页面请求，看是否能直接操作目标系统 
- **防御**： 
1. 使用CSRF Token验证 
2. 验证码、二次确认 
3. 校验Referer/Origin 
4. 敏感操作使用POST而非GET

1. 什么是安全测试？安全测试的目标是什么？

安全测试是**验证软件系统是否符合安全需求、防范安全风险**的测试活动，核心是发现系统中存在的安全漏洞、缺陷和风险。 
目标： 
1. 保密性：数据不被未授权访问 
2. 完整性：数据不被非法篡改、破坏 
3. 可用性：系统在攻击下仍可正常提供服务 
4. 不可否认性：操作行为可追溯，无法抵赖 
5. 授权与认证：确保只有合法用户可访问对应资源

2. 安全测试和功能测试的区别？

1. 目的不同：功能测“是否实现需求”，安全测“是否被非法利用、破坏” 
2. 视角不同：功能站在正常用户视角，安全站在攻击者/黑客视角
3. 关注点不同：功能关注业务流程，安全关注漏洞、权限、数据泄露 
4. 用例设计不同：功能基于正向流程，安全基于攻击场景、异常输入
5. 覆盖范围不同：功能覆盖业务逻辑，安全覆盖代码、配置、网络、部署等

3. 常见的安全测试类型/方法有哪些？

1. 渗透测试（黑盒为主，模拟黑客攻击） 
2. 漏洞扫描（工具自动化扫描） 
3. 代码安全审计（白盒，检查源码漏洞） 
4. 权限测试（垂直/水平越权） 
5. 注入测试（SQL、XSS、命令注入） 
6. CSRF、SSRF、文件上传、越权访问专项测试 
7. 安全配置检查（端口、服务、中间件配置） ##

二、OWASP TOP 10 核心类（高频中的高频

4. 什么是OWASP Top 10？说出你熟悉的几个漏洞

OWASP Top 10是Web应用最关键、最常见的十大安全风险，是安全测试核心依据。 
高频重点： 
1. 注入攻击（SQL注入、命令注入） 
2. 失效的身份认证 
3. 敏感数据暴露 
4. XML外部实体（XXE） 
5. 失效的访问控制（越权） 
6. 安全配置错误 
7. XSS跨站脚本攻击 
8. 不安全的反序列化 
9. 使用含有已知漏洞的组件 
10. 日志和监控不足 
###

8. 什么是越权访问？水平越权和垂直越权的区别？

- **定义**：用户访问了自身权限以外的功能/数据。 
- **水平越权**：同级别用户互相访问对方数据（A用户看B用户订单） 
- **垂直越权**：低权限用户访问高权限功能（普通用户访问管理员接口） 
- **测试方法**：修改用户ID、角色字段，直接请求高权限接口 
- **防御**：接口层严格鉴权，基于用户上下文校验数据归属 
## 三、渗透测试&工具类（必问） ###

9. 什么是渗透测试？黑盒/白盒/灰盒的区别？

 渗透测试是**模拟黑客攻击手段**，对系统进行攻击性测试，发现可被利用的漏洞。 
- 黑盒：无任何源码、架构信息，模拟外部黑客 
- 白盒：拥有源码、架构、配置，全面审计 
- 灰盒：部分信息（如接口文档），兼顾效率与效果 ###

10. 你用过哪些安全测试工具？分别做什么？

1. **Burp Suite**：抓包改包、重放、爆破、XSS/SQL注入手工测试（最核心） 
2. **SQLmap**：自动化SQL注入检测与利用 
3. **AWVS/AppScan**：Web漏洞扫描器 
4. **Nessus**：主机/系统漏洞扫描 
5. **Fiddler/Charles**：HTTP/HTTPS抓包，辅助安全测试 
6. **Nmap**：端口扫描、服务探测 ###

11. 简述一次完整的渗透测试流程

1. 情报收集：域名、IP、端口、子域名、目录枚举 
2. 漏洞探测：扫描+手工验证 
3. 漏洞利用：获取权限、数据 
4. 权限提升：扩大控制范围 
5. 痕迹清理：删除日志等 
6. 输出报告：漏洞详情、危害、复现步骤、修复建议 
## 四、实战&方案类（面试官最爱问）

12. 登录接口你会做哪些安全测试？

1. 弱口令测试（123456、admin等） 
2. 暴力破解（验证码绕过、锁定机制） 
3. SQL注入测试 
4. 会话固定/会话劫持 
5. 密码传输是否加密（HTTPS） 
6. 验证码有效性（可复用、前端可绕过） 
7. 记住我功能安全（Cookie时效、加密）

13. 文件上传功能如何做安全测试？

1. 上传jsp/aspx/php等后门文件 
2. 绕过后缀校验：修改文件名、MIME类型、二次渲染绕过 
3. 文件大小、数量限制 
4. 上传目录是否可执行 
5. 文件名是否存在路径穿越 
**防御**：后缀白名单、随机文件名、存储到非Web目录、查杀病毒

14. HTTPS和HTTP的区别？HTTPS就绝对安全吗？

- 区别：HTTP明文传输，HTTPS基于SSL/TLS加密，有身份认证 
- HTTPS不绝对安全： 
1. 证书过期/伪造/不信任仍有风险 
2. 仍可能存在XSS、CSRF、注入等应用层漏洞 
3. 抓包工具可解密HTTPS（安装证书后）

15. 作为普通功能测试，如何在日常工作中做安全测试？

1. 输入框做特殊字符校验（`' " < > script`） 
2. 接口测试时修改ID/role参数校验越权 
3. 检查敏感数据是否明文展示、明文存储 
4. 验证接口是否未登录可访问 
5. 关注密码策略、验证码、权限控制 
6. 配合安全团队做漏洞回归测试 
7. 遵循安全需求开展测试，而不是只测功能

八兼容测试问题