# 手机厂商

# OPPO真题一

# 1、自我介绍

答题思路：
自我介绍应简洁明了，突出个人技能、工作经验和与岗位匹配的优势，时长控制在1-2分钟内。

答题话术：
您好，我叫[您的姓名]，有[数字]年软件测试经验，擅长功能测试、自动化测试和性能测试。我熟悉Python、Selenium、JMeter等工具，曾参与[项目类型]项目的测试工作，负责测试用例设计、自动化脚本开发和持续集成流程搭建。我注重测试效率和产品质量，善于团队协作和问题解决。希望能在贵公司贡献我的技能和经验。

# 2、你们一般的节假日前做性能吗？一般压多少并发量？

答题思路：
说明性能测试的时间安排策略，并发量根据业务特点和数据决定。

答题话术：
我们通常会避开节假日前做性能测试，因为这时流量波动较大，测试结果可能不准确。一般会选择业务平稳期进行性能测试。并发量的设定基于历史数据和业务预测，通常核心业务会模拟日常峰值的1.5-2倍并发，比如登录业务我们一般压1000-3000并发，下单业务500-1000并发，具体数值会根据业务特点和服务器配置调整。

# 3、你们的自动化平台是自己搭建的吗？你参与了吗？

答题思路：
如实回答参与情况，突出个人贡献和技术能力。

答题话术：
是的，我们的自动化测试平台是基于开源工具进行二次开发的。我积极参与了平台的搭建过程，主要负责[具体工作，如：接口自动化模块的设计、测试用例管理功能的实现、与Jenkins的集成等]。通过使用Python+Pytest+Allure技术栈，我们实现了脚本自动生成、定时执行和测试报告自动发送的功能，大大提高了测试效率。

# 4、公司的测试流程？

答题思路：
从需求分析到上线验证，描述完整的测试流程。

答题话术：
我们公司的测试流程主要包括以下几个阶段：

需求评审：测试早期介入，参与产品需求评审，从测试角度提出建议
测试计划：制定测试计划，明确测试范围、资源和时间安排
用例设计：编写测试用例并进行评审
测试执行：进行多轮测试，包括功能、兼容性、性能等
缺陷管理：跟踪缺陷修复情况，进行回归测试
上线验证：在生产环境进行验收测试
测试总结：输出测试报告，进行经验总结

# 5、你们只监控接口吗？（我说了测试右移监控接口后）

答题思路：
说明监控的全面性，不仅限于接口。

答题话术：
不限于接口监控。我们的监控体系包括：

接口监控：关键业务接口的响应时间和成功率
业务监控：核心业务流程的关键指标，如订单成功率
系统监控：服务器CPU、内存、磁盘等资源使用情况
日志监控：错误日志和异常信息的实时监控
用户体验监控：页面加载时间、操作流畅度等
通过多维度监控，确保能够及时发现和处理问题。

# 6、上线流程是什么样的？

答题思路：
描述从测试完成到上线的完整流程，突出规范性和安全性。

答题话术：
我们的上线流程比较规范：

测试报告：测试完成后输出详细的测试报告
上线评审：组织产品、开发、测试进行上线评审
预发验证：在预发环境进行最终验证
上线部署：运维人员按照部署手册进行操作
线上验证：测试人员在生产环境进行核心功能验证
监控观察：上线后密切监控系统运行情况
回滚准备：准备应急预案，出现问题及时回滚

# 7、产品上线后，会做上线验证吗？

答题思路：
强调上线验证的重要性和具体做法。

答题话术：
一定会做上线验证。上线后我们会在生产环境进行：

冒烟测试：快速验证核心功能是否正常
数据验证：检查重要数据的正确性和完整性
监控验证：确认监控系统正常工作
用户流程验证：模拟真实用户操作关键路径
验证通过后才算上线完成，确保用户体验不受影响。

# 8、上线前会针对线上环境的接口做验证吗？

答题思路：
说明线上环境验证的必要性和具体方法。

答题话术：
是的，上线前我们会在预发环境（与生产环境配置基本一致）进行接口验证，主要包括：

连通性测试：验证接口能否正常访问
数据一致性：检查测试环境与生产环境数据格式是否一致
性能基准测试：确保接口性能满足要求
安全验证：检查接口的安全防护措施
避免因环境差异导致上线后出现问题。

# 9、测试过程中怎么把控测试质量？

答题思路：
从流程、技术、人员多角度说明质量控制方法。

答题话术：
我从以下几个方面把控测试质量：

流程规范：严格执行测试流程，确保每个环节质量
用例质量：设计高覆盖度的测试用例，并进行评审
缺陷管理：跟踪缺陷修复情况，严格进行回归测试
自动化测试：对核心功能进行自动化回归
风险评估：识别质量风险点，重点测试
数据驱动：基于数据分析和用户行为设计测试场景
通过多管齐下，确保测试质量。

# 10、提了bug开发解决得比较慢怎么办？

答题思路：
体现沟通技巧和问题解决能力。

答题话术：
我会采取以下措施：

优先沟通：先与开发人员沟通，了解解决慢的原因
评估影响：说明bug的严重程度和对用户的影响
寻求协助：必要时请项目经理或技术主管协调优先级
提供帮助：协助开发复现问题，提供详细信息和日志
跟踪进度：定期跟进修复进度，更新相关方
通过积极沟通和协作，推动问题解决。

# 11、测试左移过程中测试会做什么？

答题思路：
说明测试左移的具体实践和价值。

答题话术：
在测试左移过程中，我们主要做：

需求评审：早期参与需求讨论，从测试角度提出建议
技术评审：参与技术方案评审，评估可测试性和风险
单元测试：推动开发编写单元测试，提高代码质量
接口测试：在开发阶段进行接口测试，早期发现问题
自动化脚本：提前准备自动化测试脚本
通过早期介入，降低后期测试成本和风险。

# 12、测试过程中发现有的功能不符合用户的需求怎么解决的？

答题思路：
体现专业性和沟通协调能力。

答题话术：
我会按以下步骤处理：

确认问题：先确认是需求理解偏差还是功能实现错误
分析影响：评估对用户体验和业务流程的影响程度
沟通产品：与产品经理沟通，确认正确的需求定义
协调解决：如果是需求变更，评估影响范围和优先级
更新文档：相应更新需求文档和测试用例
确保产品功能真正满足用户需求。

# 13、设计测试用例考虑哪些方面？会写性能测试方面的用例吗？

答题思路：
全面说明测试用例设计维度，包括功能和非功能方面。

答题话术：
设计测试用例时我会考虑：

功能测试：正常流程、异常流程、边界值等
兼容性测试：不同浏览器、设备、操作系统
性能测试：响应时间、吞吐量、并发能力等
安全测试：权限控制、数据安全、漏洞防护
用户体验：操作便捷性、界面友好度

是的，我会编写性能测试用例，主要包括：

单接口性能测试用例
混合场景性能测试用例
负载测试和压力测试用例
稳定性测试用例

# 14、如何定位前后端bug？

答题思路：
说明具体的定位方法和工具使用。

答题话术：
我通过以下方法定位前后端bug：

查看网络请求：使用浏览器开发者工具，查看接口请求和响应
- 请求参数错误 → 前端问题
- 响应数据错误 → 后端问题
查看控制台日志：前端JavaScript错误或警告信息
查看服务端日志：后端应用日志中的异常信息
数据库验证：直接查询数据库确认数据是否正确
代码排查：在测试环境复现问题，协助开发定位
通过这些方法，能够快速准确地定位问题所在。

# 15、接口返回的状态码有哪些？

答题思路：
分类说明常见的HTTP状态码。

答题话术：
常见的HTTP状态码包括：

1xx：信息性状态码（如100 Continue）
2xx：成功状态码（如200 OK，201 Created）
3xx：重定向状态码（如301 Moved Permanently，302 Found）
4xx：客户端错误状态码（如400 Bad Request，401 Unauthorized，403 Forbidden，404 Not Found）
5xx：服务端错误状态码（如500 Internal Server Error，502 Bad Gateway，503 Service Unavailable）
在接口测试中，我们会验证接口返回的状态码是否符合预期。

# 16、多久分配一次需求？需求分下来后怎么评估这些需求的工作量？测试时间怎么分配？

答题思路：
体现需求管理和时间规划能力。

答题话术：
我们通常每2-4周分配一次需求，采用敏捷开发模式。需求评估流程：

需求分析：理解需求背景和目标，识别测试点
工作量评估：基于测试点数量、复杂度和风险进行评估
时间分配：
- 30%用例设计和评审
- 40%测试执行和缺陷跟踪
- 20%回归测试和上线验证
- 10%文档编写和总结
缓冲时间：预留20%时间应对突发情况
通过科学评估，确保测试工作有序进行。

# 17、上线前一般是几轮测试？

答题思路：
说明测试轮次的安排和目的。

答题话术：
我们通常进行3轮测试：

第一轮：全量测试，覆盖所有测试用例，发现大部分问题
第二轮：重点回归，验证已修复bug和核心功能
第三轮：回归测试+冒烟测试，确保所有问题已解决
对于复杂项目或重大变更，可能会增加专项测试轮次，如性能测试、安全测试等。

# 18、发现问题后和开发怎么沟通？

答题思路：
体现沟通技巧和协作能力。

答题话术：
我发现问题后的沟通流程：

清晰描述：提供详细的复现步骤、测试环境、预期结果和实际结果
附加证据：包含截图、日志、视频等辅助信息
初步分析：尝试初步分析问题原因，提供参考意见
当面沟通：复杂问题当面沟通，确保理解一致
跟踪反馈：定期跟进修复进度，验证修复结果
通过专业和友好的沟通，建立良好的协作关系。

# 19、如何针对接口设计测试用例？

答题思路：
系统说明接口测试用例的设计方法。

答题话术：
我针对接口设计测试用例时考虑：

正常流程：参数正确时的各种成功场景
异常流程：
- 参数缺失、类型错误、长度超限
- 必填项为空、格式不正确
边界值：参数取值边界和临界情况
业务逻辑：接口间的依赖和业务规则验证
安全测试：权限验证、SQL注入、XSS攻击等
性能测试：响应时间、并发能力、负载测试
使用工具如Postman、JMeter来管理和执行这些用例。

# 20、怎么过滤日志的关键字？

答题思路：
说明常用的日志过滤方法和工具。

答题话术：
我常用的日志过滤方法：

grep命令：grep "关键字" logfile.log
多关键字：grep -E "错误|异常|fail" logfile.log
上下文查看：grep -n -A5 -B5 "关键字" logfile.log（显示前后5行）
实时监控：tail -f logfile.log | grep "关键字"
按时间过滤：sed -n '/开始时间/,/结束时间/p' logfile.log
对于复杂的日志分析，会使用ELK等日志分析平台。

# 21、linux用得多吗？

答题思路：
如实回答使用情况，突出常用技能。

答题话术：
是的，Linux是我日常工作中经常使用的操作系统。我熟悉的Linux技能包括：

基本操作：文件管理、进程管理、权限管理
日志分析：使用grep、awk、sed等分析日志
环境部署：安装配置测试环境和服务
性能监控：使用top、vmstat、iostat等监控系统性能
脚本编写：编写Shell脚本自动化日常任务
这些技能帮助我高效完成测试工作。

# 22、性能测试关注哪些指标？

答题思路：
系统说明性能测试的关键指标。

答题话术：
性能测试主要关注以下指标：

响应时间：平均响应时间、90%响应时间
吞吐量：每秒处理事务数（TPS）
并发用户数：系统能支持的同时在线用户数
错误率：请求失败或错误的比率
资源利用率：CPU、内存、磁盘I/O、网络带宽使用率
数据库指标：连接数、缓存命中率、锁等待时间
这些指标帮助我们全面评估系统性能。

# 23、怎么用监控命令查看内存的使用率？

答题思路：
说明常用的内存监控命令。

答题话术：
我常用的内存监控命令：

free命令：free -h，以人类可读格式显示内存使用情况
top命令：top，实时显示内存使用情况和进程排名
vmstat命令：vmstat 1，每秒显示内存统计信息
/proc/meminfo：cat /proc/meminfo，查看详细内存信息
htop命令：htop，更友好的交互式监控工具
通过这些命令，可以全面了解系统内存使用情况。

# 24、自动化负责的哪两个模块？

答题思路：
选择两个有代表性的模块，说明工作内容。

答题话术：
我主要负责以下两个模块的自动化测试：

用户管理模块：包括注册、登录、权限管理等功能的自动化测试
订单流程模块：包括下单、支付、退款等核心业务流程的自动化
为这些模块设计了数据驱动框架，实现了接口自动化和UI自动化，大大提高了回归测试效率。

# 25、讲一下自动化测试的流程？

答题思路：
系统说明自动化测试的实施流程。

答题话术：
我们的自动化测试流程包括：

需求分析：确定自动化测试范围和优先级
框架设计：选择合适的工具和框架，设计测试架构
脚本开发：编写和维护自动化测试脚本
数据准备：准备测试数据，实现数据驱动
执行调度：通过Jenkins等工具实现定时执行或触发执行
报告分析：生成测试报告，分析测试结果
持续优化：根据反馈不断优化脚本和流程
形成完整的自动化测试闭环。

# 26、怎么造数据？

答题思路：
说明测试数据准备的方法和工具。

答题话术：
我造数据的方法包括：

SQL脚本：直接通过SQL语句插入或更新数据
接口调用：通过调用业务接口生成测试数据
数据工厂：使用工具如DataFaker生成模拟数据
备份还原：备份生产数据并脱敏后使用
脚本自动化：编写Python脚本批量生成测试数据
根据测试需求选择合适的方法，确保数据真实有效。

# 27、自动化框架接口关联怎么做的？

答题思路：
说明接口关联的技术实现。

答题话术：
我们的自动化框架通过以下方式处理接口关联：

参数提取：使用正则表达式或JSONPath从响应中提取需要关联的参数
参数存储：将提取的参数存储在变量或缓存中
参数传递：在后续请求中自动使用存储的参数
动态构建：根据业务规则动态构建请求参数
依赖管理：管理接口间的依赖关系，确保执行顺序
使用Python的requests库和Pytest框架实现这些功能。

# 28、讲一下迭代器和生成器

答题思路：
准确说明概念、区别和用途。

答题话术：
迭代器是一个可以记住遍历位置的对象，实现了__iter__()和__next__()方法，允许逐个访问元素。

生成器是一种特殊的迭代器，使用yield语句返回值，暂停函数状态，下次从暂停处继续执行。

主要区别：

生成器更简洁，自动实现迭代器协议
生成器惰性计算，节省内存
生成器函数执行到yield时暂停，保持局部变量状态

在测试中常用于处理大量数据或流式数据。

# 29、可变对象和不可变对象在深浅拷贝中会发生什么变化？

答题思路：
准确说明深浅拷贝的区别和影响。

答题话术：
不可变对象（如数字、字符串、元组）：

浅拷贝和深拷贝结果相同，都指向原对象
因为不可变，所以不需要真正复制

可变对象（如列表、字典、集合）：

浅拷贝：创建新对象，但子对象仍引用原对象
深拷贝：完全独立的新对象，所有子对象都复制

在测试中需要注意拷贝行为，避免意外的数据修改影响测试结果。

# 30、在执行多线程编程的时候，线程共享变量的时候，多线程的数据同步怎么处理？

答题思路：
说明多线程同步的常用方法。

答题话术：
处理多线程数据同步的常用方法：

锁机制：使用threading.Lock()确保同一时间只有一个线程访问共享资源
信号量：控制同时访问资源的线程数量
条件变量：用于线程间的协调和通信
队列：使用queue.Queue实现线程安全的数据交换
线程本地数据：使用threading.local()为每个线程创建独立数据
在自动化测试中，需要谨慎处理多线程同步，避免竞态条件。

# 31、python中的反射知道吗？

答题思路：
准确说明反射的概念和用途。

答题话术：
Python中的反射是指在运行时动态获取对象信息、调用方法和操作属性的能力。主要使用以下函数：

getattr(obj, name)：获取对象属性
setattr(obj, name, value)：设置对象属性
hasattr(obj, name)：检查对象是否有某属性
delattr(obj, name)：删除对象属性

在测试中，反射常用于：

动态调用测试方法
插件系统实现
配置文件驱动测试
提高了测试框架的灵活性和扩展性。

# 32、什么是存储过程？

答题思路：
准确说明存储过程的概念和特点。

答题话术：
存储过程是预先编译并存储在数据库中的SQL语句集合，具有以下特点：

预编译：执行效率高，减少解析开销
复用性：可以被多次调用，代码复用
安全性：通过权限控制访问，提高安全性
减少网络流量：只需传输调用指令，而不是大量SQL语句

在测试中，需要测试存储过程的正确性、性能和异常处理。

# 33、什么是索引？我说索引相当于书的目录，他问你知道这个目录是用什么结构存储的吗？

答题思路：
深入说明索引的数据结构。

答题话术：
索引确实相当于书的目录，常见的索引数据结构包括：

B树：最常用的索引结构，适合范围查询
B+树：B树的改进，所有数据存储在叶子节点，更适合磁盘存储
哈希索引：适合等值查询，但不支持范围查询
全文索引：用于文本内容的搜索

MySQL的InnoDB引擎使用B+树索引，这种结构保证了查询效率和数据有序性。

# 34、数据库会用到哪些？

答题思路：
说明常用的数据库类型和使用场景。

答题话术：
在工作中我会用到以下数据库：

MySQL：最常用的关系型数据库，用于业务数据存储
Redis：内存键值数据库，用于缓存和会话存储
MongoDB：文档数据库，用于存储非结构化数据
Elasticsearch：搜索引擎，用于日志和搜索功能
根据不同的业务需求选择合适的数据库。

# 35、讲一下事务，怎么测事务？

答题思路：
说明事务的概念和测试方法。

答题话术：
事务是数据库操作的逻辑单元，具有ACID特性：

原子性：全部成功或全部失败
一致性：保持数据一致性
隔离性：并发事务互不干扰
持久性：事务提交后永久生效

测试事务的方法：

正常测试：验证事务成功提交的数据正确性
异常测试：模拟异常情况，验证事务回滚的正确性
并发测试：测试多事务并发时的数据一致性
超时测试：测试事务超时处理机制

# 36、有没有遇到慢查询sql的问题？怎么测？

答题思路：
说明慢查询的识别和优化方法。

答题话术：
经常遇到慢查询问题，我的处理方法：

识别慢查询：
- 开启MySQL慢查询日志
- 使用explain分析查询执行计划
- 使用性能监控工具如pt-query-digest
优化方法：
- 添加合适的索引
- 优化SQL语句，避免全表扫描
- 调整数据库配置参数
- 考虑分库分表
测试验证：
- 优化前后性能对比测试
- 压力测试验证优化效果
- 回归测试确保功能正确性

# 37、测试环境、版本部署谁做？会不会搭建测试环境？

答题思路：
体现环境搭建和维护能力。

答题话术：
测试环境部署通常由测试人员负责，我会：

环境搭建：使用Docker、Ansible等工具自动化部署测试环境
版本部署：配合开发进行版本发布和回滚
环境维护：定期清理数据，保持环境稳定
文档编写：编写环境部署和维护文档
具备完整的测试环境搭建和维护能力。

# 38、你有什么问我的？

答题思路：
提出有深度的问题，体现对工作的思考。

答题话术：
我想了解：

团队目前的技术栈和未来的技术规划是怎样的？
这个岗位的日常工作中，测试自动化和手动测试的比例大概是多少？
团队如何保证产品质量，有哪些质量保障体系？
公司对测试人员的职业发展有哪些支持和规划？
目前团队面临的最大技术挑战是什么？

# 39、离职原因？

答题思路：
保持积极正面，体现职业规划。

答题话术：
我离开上一家公司主要是出于职业发展的考虑。在过去的工作中，我积累了丰富的测试经验，但现在希望寻找一个更有挑战性的平台，能够接触更复杂的技术和项目，进一步提升自己的专业技能。贵公司的发展方向和技术栈与我的职业规划非常匹配，我相信这里能为我提供更好的发展空间。

# 40、怎么看待加班？

答题思路：
体现工作态度和效率意识。

答题话术：
我认为加班应该是项目需要的特殊情况，而不是常态。我注重工作效率，会在工作时间内尽可能完成任务。当然，如果项目紧急需要加班，我会积极配合团队完成任务。但我更倾向于通过提高工作效率和提前规划来减少不必要的加班，这样才能保持长期的工作热情和创造力。

# OPPO真题二

# 1. 自我介绍

答题思路：自我介绍应简洁明了，突出个人技能、项目经验和与岗位相关的优势。结构上可包括教育背景、工作经验、技术栈和职业兴趣。 答题话术： "面试官您好，我叫[你的名字]，毕业于[你的学校]的[专业]。我拥有[年限]年的软件测试开发经验，专注于自动化测试和性能优化。在过去的工作中，我主要负责[Sonic项目的测试框架开发]和[支付链路的自动化测试]，熟练使用Java、Python和Spring Boot等技术栈。我对高质量代码和自动化流程有强烈兴趣，希望能在贵团队贡献我的经验。"

# 2. Sonic负责哪块 && 怎么做自动化的展示 && 遇到过什么问题

答题思路：分三部分回答：职责、自动化实现方法、遇到的问题及解决方案。
答题话术：
"在Sonic项目中，我负责测试框架的设计和支付模块的自动化测试。自动化主要通过Selenium和Appium实现UI自动化，结合Jenkins做CI/CD集成。

自动化展示：我们使用Page Object模式管理页面元素，用TestNG组织用例，并通过数据驱动测试（DDT）减少重复代码。例如，支付流程的自动化会模拟用户输入、跳转和验证结果。
遇到的问题：
1. 弹窗处理：随机弹窗（如广告）会中断流程。解决方案是用显式等待和try-catch捕获弹窗，并封装一个统一的弹窗处理工具类。
2. 条件判断（if）：通过断言（Assert）和条件语句处理动态场景，比如检查支付成功后是否跳转正确页面。
3. 稳定性问题：部分用例因网络波动失败。我们加入了重试机制和日志监控，定位flaky tests。"

# 3. 支付链路特点说一下

答题思路：支付链路的核心特点是高可用、数据一致性和安全性。
答题话术：
"支付链路的特点是：

高并发和低延迟：需处理峰值请求，响应时间要短。
数据一致性：支付状态和账务数据必须通过事务保证一致性。
安全性：涉及敏感信息（如银行卡号），需加密和防篡改。
依赖第三方：如银行接口，需mock和熔断机制保障测试稳定性。"

# 4. 快手点赞怎么设计用例

答题思路：从功能、异常、性能和兼容性维度设计用例。
答题话术：
"设计点赞功能的测试用例：

功能测试：
- 正常点赞/取消点赞，验证计数和状态更新。
- 连续快速点赞，检查防抖机制。
异常测试：
- 网络中断时点赞，验证数据回滚。
- 已删除视频的点赞处理。
性能测试：
- 高并发点赞，检查服务器负载和响应时间。
兼容性：
- 多设备（iOS/Android）和版本覆盖。"

# 5. final关键字

答题思路：解释final修饰变量、方法和类时的作用。
答题话术：
"final关键字用于定义不可改变的实体：

变量：一旦赋值不能修改（基本类型值不变，引用类型指向不变）。
方法：不能被子类重写。
类：不能被继承，如String类。"

# 6. ==和equals()区别

答题思路：==比较引用地址，equals()比较内容（可重写）。
答题话术：
"==比较两个对象的内存地址是否相同，而equals()默认行为与==相同，但通常被重写（如String类）用于比较内容。例如：
String s1 = new String("abc"); String s2 = new String("abc"); s1 == s2; // false（地址不同） s1.equals(s2); // true（内容相同）

String s1 = new String("abc"); String s2 = new String("abc"); s1 == s2; // false（地址不同） s1.equals(s2); // true（内容相同）

# 7. 多线程实现的几种方式

答题思路：列举继承Thread、实现Runnable/Callable、线程池。
答题话术：
"Java多线程实现方式：

继承Thread类，重写run()方法。
实现Runnable接口，避免单继承限制。
实现Callable接口，配合FutureTask获取返回值。
使用线程池（如ExecutorService）管理线程资源。"

# 8. 写个Java后端API接口的流程（涉及MySQL）

答题思路：按Spring Boot流程：控制器→服务层→DAO层→数据库。
答题话术：
"以用户查询API为例：

定义RestController和GetMapping路由。
注入Service层类，处理业务逻辑。
Service调用DAO层（如JdbcTemplate或MyBatis），执行SQL查询。
处理异常并返回JSON响应。
示例代码：

@RestController public class UserController { @Autowired private UserService userService;

@GetMapping("/user/{id}")
public User getUser(@PathVariable int id) {
    return userService.findById(id);
}

}

# 9. 数据库的索引有哪几类

答题思路：常见索引类型：B树、哈希、全文等。
答题话术：
"数据库索引类型包括：

B+树索引：最常用，支持范围查询。
哈希索引：适合等值查询，但不支持排序。
全文索引：用于文本搜索（如MySQL的FULLTEXT）。
复合索引：多列组合索引，优化联合查询。"

# 10. Spring Boot点了运行后，怎么运行起来的

答题思路：从main方法启动，自动配置，内嵌服务器。
答题话术：
"Spring Boot启动流程：

执行main方法，调用SpringApplication.run()。
加载自动配置（@EnableAutoConfiguration），根据依赖配置Bean。
启动内嵌Tomcat服务器，扫描Controller并映射路由。
应用 ready后监听端口，处理请求。"

# 11. 算法题：合并有序数组

答题思路：双指针遍历，比较后合并。
答题话术：
"使用双指针从后向前遍历数组，避免覆盖原数据：

public void merge(int[] nums1, int m, int[] nums2, int n) { int i = m - 1, j = n - 1, k = m + n - 1; while (j >= 0) { if (i >= 0 && nums1[i] > nums2[j]) { nums1[k--] = nums1[i--]; } else { nums1[k--] = nums2[j--]; } } }

# 12. 流量回放怎么做的

答题思路：录制线上请求，过滤后回放到测试环境。
答题话术：
"流量回放步骤：

录制：通过代理工具（如Arex）捕获线上HTTP/DB请求。
过滤：去除敏感数据，筛选核心用例。
回放：将请求发送到测试环境，对比响应结果。
校验：自动化断言差异，排查逻辑变更或BUG。"

# 13. Arex的特点和中间件冲突怎么解决

答题思路：Arex用于流量录制/回放；冲突时需隔离或mock。
答题话术：
"Arex的特点：支持全自动流量录制和Mock，降低测试成本。
中间件冲突：如回放时依赖未部署的中间件（如Redis），解决方案：

使用Arex的Mock功能模拟中间件响应。
隔离测试环境，避免污染线上数据。"

# 14. Arex数据库和第三方操作怎么操作

答题思路：录制SQL请求，回放时Mock或影子库。
答题话术：
"Arex录制数据库操作：

录制阶段：捕获SQL语句和结果。
回放阶段：
- 直接Mock返回录制的结果（避免写测试库）。
- 使用影子表（Shadow Table）隔离测试数据。"

# 16. 事务的特性（ACID）

答题思路：分别解释ACID四个特性。
答题话术：
"事务的ACID特性：

原子性：事务要么全部成功，要么全部回滚。
一致性：事务前后数据库状态一致（如余额不为负）。
隔离性：并发事务互不干扰（通过隔离级别实现）。
持久性：事务提交后数据永久存储。"

# 17. 说一下反射

答题思路：反射机制的作用、应用场景和代码示例。
答题话术：
"反射是Java在运行时动态获取类信息、调用方法或操作字段的能力。核心类：Class、Method、Field。
应用场景：框架设计（如Spring的IoC）、动态代理。
示例：

Class<?> clazz = Class.forName("com.example.User"); Object obj = clazz.newInstance(); Method method = clazz.getMethod("setName", String.class); method.invoke(obj, "John");

# VIVO 真题一

# 1. 自我介绍

# 2. 有做过单测吗

答题思路：肯定回答，展示对单元测试的理解和实践经验，包括使用的工具和具体案例。 答题话术： "是的，我经常编写单元测试。在项目中，我们使用JUnit和Mockito来编写单元测试用例。例如，在支付服务中，我为金额计算方法和支付状态验证方法编写了单元测试，通过Mockito模拟外部依赖（如数据库和第三方支付接口），确保核心逻辑的正确性。单测覆盖率要求达到80%以上，我们通过Jacoco插件来监控覆盖率。"

# 3. 讲一下你之前写过的这个框架

答题思路：选择一个熟悉的测试框架（如自动化测试框架），介绍其设计目标、核心模块和实现特点。 答题话术： "我主导开发了一个基于Selenium和TestNG的UI自动化测试框架。该框架的主要目标是提高测试效率和可维护性。核心模块包括：

页面对象层：封装所有页面元素和操作。
测试用例层：使用TestNG组织测试用例，支持数据驱动。
工具层：提供日志、截图、报告生成等功能。框架支持并行执行和自动重试机制，减少了Flaky Test的影响。例如，通过封装WebDriver等待机制，解决了元素加载不稳定导致失败的问题。"

# 4. 设计一个框架需要考虑哪些因素

答题思路：从可扩展性、易用性、维护性、稳定性等方面展开。 答题话术： "设计框架时需要考虑：

可扩展性：预留扩展点，方便后续集成新功能。
易用性：提供清晰的API和文档，降低使用门槛。
维护性：代码结构清晰，模块化设计，便于排查问题。
稳定性：引入异常处理和日志监控，保障框架稳定运行。
兼容性：支持不同环境和版本，避免硬编码。"

# 5. 你是怎么理解数据驱动的

答题思路：解释数据驱动的概念，并结合自动化测试中的实际应用。 答题话术： "数据驱动是将测试数据和测试逻辑分离的一种设计模式。在自动化测试中，我们通过外部文件（如Excel、JSON）管理测试数据，用例执行时动态读取数据，实现同一用例覆盖多组输入。例如，支付接口测试中，我将金额、货币类型等参数存储在CSV文件中，通过TestNG的@DataProvider读取数据，高效覆盖边界值和异常场景。"

# 6. UI自动化中是怎么模拟用户操作的

答题思路：介绍常用工具和模拟操作的方法，如点击、输入、拖拽等。 答题话术： "在UI自动化中，我使用Selenium的Action类或Appium的TouchAction来模拟用户操作。例如：

点击：element.click()
输入：element.sendKeys("text")
拖拽：new Actions(driver).dragAndDrop(source, target).perform() 对于复杂操作（如长按、滑动），我们封装了自定义方法，并加入显式等待确保元素可交互，避免操作失败。"

# 7. 讲下你负责的业务模块

答题思路：选择核心业务模块（如支付、订单），介绍职责和成果。 答题话术： "我负责支付业务模块的测试开发工作，主要包括支付流程验证、资金对账和异常处理。我设计了端到端的自动化测试用例，覆盖从下单到支付成功的全链路，通过Mock银行接口模拟不同响应，确保支付成功、失败、超时等场景正确处理。自动化脚本集成到CI/CD后，每次发布前自动回归，减少了70%的手动测试时间。"

# 8. 设计支付接口的异常用例设计

答题思路：从网络、数据、第三方依赖等维度设计异常用例。 答题话术： "支付接口的异常用例设计包括：

网络异常：模拟请求超时、断开重连，验证事务回滚。
数据异常：输入非法金额、重复订单号，检查错误提示。
第三方异常：Mock银行返回失败、延迟响应，验证系统容错。
并发异常：多用户同时支付同一订单，检查数据一致性。
安全异常：模拟篡改请求参数，验证签名机制。"

# 9. Java的多态、反射机制、泛型的作用、垃圾回收

答题思路：分别解释概念和作用，简要举例。 答题话术：

多态：同一接口的不同实现方式，如父类引用指向子类对象，提高代码灵活性。
反射：运行时动态获取类信息，用于框架开发（如Spring IOC）。
泛型：提供类型安全，避免强制类型转换，如`List list = new ArrayList<>()。
垃圾回收：JVM自动回收无用对象内存，开发者可通过System.gc()建议回收，但不确定立即执行。"

# 10. Python的元组和列表的区别、装饰器的作用、静态方法和实例方法的区别

答题思路：对比元组和列表，解释装饰器和方法的区别。 答题话术：

元组和列表：元组不可变（如(1,2)），列表可变（如[1,2]），元组更节省内存。
装饰器：用于扩展函数功能，如@staticmethod将方法转为静态方法。
静态方法和实例方法：静态方法（@staticmethod）无需访问实例属性，实例方法需通过self访问实例数据。"

# 11. 讲下RabbitMQ集群的压测过程

答题思路：介绍压测目标、工具、步骤和监控指标。 答题话术： "我对RabbitMQ集群的压测过程如下：

目标：测试高并发下消息生产和消费的吞吐量及延迟。
工具：使用JMeter模拟生产者和消费者，连接RabbitMQ集群。
步骤：逐步增加并发连接数，监控队列堆积、内存和CPU使用率。
监控：通过RabbitMQ Management插件跟踪消息速率，发现瓶颈时调整集群节点或优化配置。"

# 12. 有没有做过多接口的压测

答题思路：肯定回答，结合场景描述压测设计和问题发现。 答题话术： "是的，我做过电商下单流程的多接口压测，涉及商品查询、库存扣减和订单创建。我使用JMeter模拟用户并发请求，通过阶梯式增加线程数定位系统瓶颈。压测中发现数据库连接池不足，优化后吞吐量提升了50%。"

# 13. 有多少台发压机器和多少个被压节点

答题思路：根据实际经验回答，强调资源规划和压测策略。 答题话术： "在最近的项目中，我使用3台发压机器（配置为8核16GB），通过JMeter分布式部署模拟10万用户并发。被压测系统是一个由10个节点组成的微服务集群（包括4个应用节点和3个数据库节点）。我们根据监控数据动态调整发压策略，确保压力均匀分布。"

# VIVO真题二

# 1. 自我介绍

# 2. 拿到接口怎么分析？

答题思路：从接口文档、业务逻辑、参数、返回值、异常场景等维度进行分析。 答题话术： "拿到接口后，我会从以下几个方面进行分析：

阅读接口文档：了解接口功能、请求方法、URL、参数含义和返回值结构。
理解业务逻辑：明确接口在业务流程中的角色和上下游依赖。
分析参数：检查必填参数、参数类型、边界值和取值范围。
分析返回值：理解不同状态码的含义、正常返回和错误返回的数据结构。
考虑异常场景：如参数缺失、类型错误、网络超时、服务宕机等。
评估性能要求：了解接口的预期响应时间和并发要求。"

# 3. 冒烟流程为什么要写自动化？

答题思路：解释冒烟测试的目的和自动化带来的效率、可靠性提升。 答题话术： "冒烟测试是验证核心功能是否可用的基础测试，将其自动化可以：

提高效率：每次版本变更后自动执行，快速反馈版本稳定性，节省手动测试时间。
保证一致性：避免人为遗漏或错误，确保每次测试的步骤和验证点一致。
早期发现问题：集成到CI/CD流水线中，代码提交后立即运行，提前阻断严重缺陷。
释放人力资源：让测试人员专注于更复杂的新功能测试和探索性测试。"

# 4. 一个需求从开始到最后的有哪些步骤？

答题思路：按照软件开发生命周期（SDLC）描述需求经过的典型阶段。 答题话术： "一个需求从开始到上线通常经历以下步骤：

需求评审：产品经理讲解需求，开发、测试、设计等相关角色参与，明确需求细节和可行性。
技术设计与评审：开发人员设计技术方案，进行评审。
开发阶段：开发人员编码实现功能。
测试用例设计与评审：测试人员编写测试用例，并组织评审。
测试执行：测试人员执行测试用例，提交并跟踪Bug。
回归测试：修复Bug后进行回归测试，确保没有引入新问题。
预发布/灰度发布：在接近生产环境的环境进行验证，或先对部分用户发布。
正式上线：全量发布到生产环境。
线上验证：上线后进行快速 smoke test，确保功能正常。"

# 5. 这些步骤测试的角色是什么？

答题思路：在需求各个阶段中，测试人员的主要职责和活动。 答题话术： "测试在需求全流程中的角色包括：

需求评审阶段：从测试角度评估需求的可测性、合理性，识别潜在风险和遗漏点。
技术评审阶段：理解系统架构和实现细节，思考测试策略和难点。
开发阶段：编写测试用例，准备测试数据，搭建测试环境。
测试用例评审阶段：确保用例覆盖全面，邀请开发、产品等角色参与评审。
测试执行阶段：执行测试，提交缺陷，评估测试进度和质量风险。
回归测试阶段：验证Bug修复，进行全量或部分回归。
发布阶段：支持上线，进行线上验证和监控。"

# 6. 数据测试的bug多不多？

答题思路：根据经验客观回答，并举例说明常见的数据类Bug。 答题话术： "在我的经验中，数据相关的Bug占有一定比例，虽然不如业务逻辑Bug那么多，但一旦出现影响往往比较严重。常见的数据类Bug包括：

数据准确性：计算错误、统计错误（如金额、数量）。
数据一致性：不同模块或表之间的数据对不上（如订单状态和库存）。
数据存储与查询：数据库字段类型或长度问题导致存储失败或查询慢。
数据迁移：在老数据迁移或转换过程中出现错误。这些Bug通常需要仔细设计测试用例，特别是边界值和异常数据，才能有效发现。"

# 7. 数据库测试怎么测？

答题思路：从数据准确性、一致性、完整性、性能等维度说明测试方法。 答题话术： "数据库测试主要从以下几个方面进行：

数据准确性测试：
- 执行前端操作后，验证后端数据库中的数据是否按预期存储（如字段值、状态）。
- 通过SQL查询直接校验数据。
数据一致性测试：
- 检查关联表之间的数据逻辑是否正确（如外键约束、业务逻辑约束）。
数据完整性测试：
- 测试非空约束、唯一约束、默认值等是否生效。
数据库操作测试：
- 测试增删改查操作的性能，特别是在大数据量下的响应时间。
事务测试：
- 验证事务的ACID特性，例如在操作中途中断，数据是否会回滚。我通常会结合前端操作和直接数据库查询来进行验证。"

# 8. 前端bug多还是后端bug多？

答题思路：客观分析，说明两者特点，避免绝对化，并强调依赖具体项目。 答题话术： "这取决于项目的类型、阶段和架构。在我的经验中：

前端Bug：通常与UI/UX相关，如页面布局错乱、交互失效、浏览器兼容性问题。在项目早期或UI大改时可能较多。
后端Bug：更多涉及业务逻辑、数据处理、性能和安全问题。这类Bug往往更核心，修复成本也可能更高。一般来说，复杂的业务系统后端Bug可能会更多一些，但移动端或重展示的项目前端Bug比例会上升。更重要的是关注Bug的严重程度和对用户的影响，而不是单纯比较数量。"

# 9. 怎么定位前后端bug？

答题思路：描述一套系统的排查方法，常用工具和判断依据。 答题话术： "我的定位思路如下：

查看浏览器开发者工具（F12）：
- Network标签：查看接口请求是否成功发出（Status 200）、请求参数是否正确、接口响应数据是否符合预期。如果接口请求失败或返回错误，通常是后端问题。
- Console标签：查看是否有JavaScript报错，有则通常是前端问题。
模拟请求：
- 使用Postman等工具直接调用后端接口，传入相同参数。如果Postman测试也失败，基本是后端问题；如果成功，则是前端处理响应或发送请求的问题。
查看日志：
- 查看后端应用日志和数据库日志，确认请求是否到达后端以及后端处理逻辑是否有异常。
经验判断：
- 界面显示、样式、交互问题 → 前端。
- 数据错误、计算错误、状态不对 → 先查后端接口返回，再判断。"

# 10. 屏幕白屏了怎么定位？

答题思路：提供一套从前端到后端的系统性排查步骤。 答题话术： "白屏是一个典型问题，我会按以下步骤定位：

打开浏览器开发者工具（F12），首先看Console是否有红色的JS报错（如语法错误、变量未定义、资源加载失败）。这是最常见的原因。
查看Network标签：
- 检查关键的JS、CSS文件是否加载成功（Status 200）。
- 检查首页或主接口（API）是否请求成功并返回了正确数据。
如果是单页面应用（SPA如Vue, React），检查路由配置是否正确。
检查后端服务：
- 确认后端服务是否正常启动（通过健康检查接口）。
- 查看后端日志是否有异常抛出，导致首页所需数据接口失败。
检查环境配置：如CDN、Nginx反向代理配置是否正确，是否指向了正确的资源路径和服务地址。通常90%的白屏问题通过第1步查看Console错误就能快速定位。"

# 11. 接口自动化怎么做的？

答题思路：介绍框架选型、设计模式、关键组件和集成方式。 答题话术： "我之前的接口自动化主要基于Python + pytest + Requests库构建：

框架核心：
- 请求封装：对Requests进行二次封装，统一处理请求头、认证（如Token）、日志和基础断言。
- 数据驱动：使用@pytest.mark.parametrize或将测试数据存储在JSON/YAML文件中，实现用例与数据分离。
- Fixture管理：使用pytest的fixture来管理前置后置操作，如初始化数据、清理环境。
目录结构：
- common/：存放公共方法和配置。
- api/：封装所有接口的调用方法。
- test_cases/：存放测试用例。
- data/：存放测试数据文件。
- reports/：存放生成的测试报告。
断言：不仅断言HTTP状态码，更重点断言响应体中的业务码（code）、关键字段值和数据库数据一致性。
持续集成：将自动化脚本集成到Jenkins/GitLab CI，定时执行或触发执行，并生成Allure等可视化报告。"

# 12. 登录接口的测试用例。

答题思路：从功能、安全、性能、异常等角度设计用例。 答题话术： "登录接口的测试用例可以考虑以下方面： 功能测试：

用户名/密码正确，登录成功。
用户名正确，密码错误，登录失败并有相应提示。
用户名不存在，登录失败并有相应提示（提示语不应泄露用户是否存在）。
用户名/密码为空，登录失败。
密码是否加密传输（抓包查看）。 安全测试：
连续多次登录失败，是否触发账号锁定或验证码机制。
登录成功后返回的Token或Session是否有效且安全。
检查SQL注入漏洞（用户名输入' or '1'='1）。
旧Token是否在登出后失效。 性能测试：
单用户登录的响应时间。
多用户并发登录的性能表现。 兼容性测试：
不同终端（Web, App）调用登录接口是否正常。其他：
第三方登录（如微信、QQ）集成测试。"

# 13. Python常用的库，我说了request 那些，他问我还有吗？

答题思路：列举测试开发中常用的Python库，并简要说明其用途。 答题话术： "除了Requests，我在测试开发中还经常使用以下Python库：

pytest: 强大的测试框架，用于组织和运行测试用例。
Selenium: Web UI自动化测试。
Appium: 移动端APP自动化测试。
Paramiko: 用于SSH连接服务器，执行命令或传输文件，进行环境部署或日志查看。
OpenPyXL / pandas: 用于操作Excel测试数据。
Allure-pytest: 生成美观的测试报告。
PyMySQL: 连接MySQL数据库，进行数据验证和构造。
Faker: 生成虚假测试数据。
Logging: 进行日志记录，方便调试和排查问题。
unittest: Python标准库中的单元测试框架（有时与pytest混用）。"

# 14. 接口测试有哪些工具？

答题思路：列举常用的开源和商业接口测试工具。 答题话术： "接口测试工具非常多，可以分为： 开源工具/框架：

Postman: 最流行的API调试和测试工具，有图形化界面和CLI Newman。
JMeter: 功能强大，既可做性能压测，也可做功能接口测试。
RestAssured: 基于Java的DSL接口测试库。
HttpRunner: 基于Python的开源接口测试框架。
curl: 命令行工具，非常灵活。 商业工具：
Apifox: 集成了API文档、调试、Mock、测试于一体的协作平台。
SoapUI: 专用于SOAP和REST API测试的功能强大的工具。我个人最常用的是Postman（用于快速调试和简单测试）和pytest + Requests（用于构建复杂的自动化测试项目）。"

# 15. 有没有什么印象深刻的bug？

答题思路：讲述一个真实的、能体现你技术深度和解决问题能力的Bug案例。使用STAR原则（Situation, Task, Action, Result）来描述。 答题话术： "有一个让我印象深刻的Bug是关于‘资金定时任务重复出账’的问题。

情景(Situation)：线上偶尔有用户投诉余额被扣了两次，但发生在深夜，且不是必现。
任务(Task)：需要快速定位这个严重的数据一致性问题的根本原因。
行动(Action)：
1. 我首先排查了用户的账户流水，确认了确实存在两笔完全一样的支出记录。
2. 根据流水时间戳，去查询了后台任务日志，发现那个时间点附近的日志异常混乱，似乎同一个任务被执行了多次。
3. 我怀疑是分布式任务调度系统（Elastic-Job）的幂等性问题。我查阅了该框架的配置文档和我们的代码，发现虽然配置了分片，但我们的任务逻辑没有做幂等性处理。
4. 在测试环境，我模拟了网络抖动和服务器时间差，成功复现了该问题：某个任务节点被误认为宕机，其分片被转移到另一个节点，导致同一个分片上的数据被重复处理。
结果(Result)：我推动开发人员在任务处理逻辑中增加了基于数据库乐观锁的幂等性校验，彻底解决了这个问题。这个Bug让我深刻理解了分布式系统下保证幂等性的重要性。"

# 16. Web弱网怎么做？

答题思路：说明模拟弱网的常用工具和方法，以及测试关注点。 答题话术： "Web弱网测试主要通过以下工具和方法进行：

浏览器开发者工具：Chrome DevTools的Network面板可以直接模拟弱网（Slow 3G, Fast 3G等），这是最快捷的方式。
专业代理工具：
- Charles / Fiddler: 它们的‘Throttling’功能可以自定义网络带宽、延迟、丢包率。
- Facebook的ATC(Augmented Traffic Control)：更强大的弱网模拟工具，可以精确控制上下行带宽和延迟。
系统级工具（适用于App或更深层次的测试）：
- Network Link Conditioner (macOS)
- Clumsy (Windows)
- Linux TC命令 测试关注点：

页面加载时间、渲染是否正常。
图片、视频等资源是否能逐步加载或有无友好提示（如加载失败、重试按钮）。
用户操作（点击、输入）的响应和反馈，是否会因网络慢导致用户重复提交。
超时机制是否合理，是否会长时间卡死或无响应。
网络恢复后，数据和状态是否能自动同步或恢复。"

# 17. 自动化的用例怎么写的？

答题思路：阐述自动化用例与手动用例的区别，以及编写高质量自动化用例的原则。 答题话术： "自动化用例的编写侧重于可执行性、稳定性和可维护性，我会遵循以下原则：

用例设计：
- 原子性：一个用例尽量只验证一个主要功能点，避免过长和复杂的流程。
- 独立性：用例之间没有依赖，可以单独运行，通过setup和teardown机制管理测试数据，保证不互相影响。
- 可重复性：用例可以反复运行，结果一致。
用例结构（Arrange-Act-Assert模式）：
- Arrange (准备)：初始化测试数据、状态和环境。
- Act (执行)：调用被测试的接口或执行UI操作。
- Assert (断言)：验证实际结果是否符合预期（响应码、数据库状态、页面元素等）。
代码实现：
- 使用清晰的命名（用例名、变量名、方法名）。
- 添加必要的注释，特别是复杂的业务逻辑。
- 对页面元素、接口URL等进行封装，便于统一维护。
- 使用显式等待（WebDriverWait）代替硬性等待（sleep），提高稳定性和执行速度。
数据管理：将测试数据从代码中分离，使用数据驱动来提高覆盖率。"

# 18. 入职新公司怎么快速接手业务？

答题思路：展示你的主动性、学习方法和沟通能力，给出一个系统性的计划。 答题话术： "为了快速接手新公司的业务，我会采取以下步骤：

熟悉人与环境：
- 主动认识团队成员（产品、开发、测试、运维），了解他们的角色和职责。
- 熟悉公司的沟通工具、文档平台、代码仓库、CI/CD流程等基础设施。
全面了解产品：
- 作为用户去体验产品的主要功能，建立直观感受。
- 阅读产品文档、需求文档、设计稿，理解业务背景、用户价值和核心流程。
深入技术细节：
- 阅读现有的测试用例（手动和自动），这是最快了解系统功能点和测试重点的方式。
- 查阅技术文档、架构图，了解系统模块划分和技术栈。
- 申请权限，尝试搭建本地开发测试环境，并成功运行起项目。
从小事入手：
- 主动请求先负责一些简单的Bug验证或小的需求测试，在实践中学习。
- 在测试过程中，遇到不理解的及时向同事请教，并做好笔记。
总结与反馈：定期总结所学，并尝试优化现有的测试流程或脚本，积极提出自己的想法和建议。"

# 19. 有什么要问我的吗？

答题思路：提出有深度、能体现你思考和对公司兴趣的问题，避免只关注薪资福利。 答题话术： "是的，我想了解以下几个问题：

团队与文化：我们测试团队目前的规模和组织结构是怎样的？团队的技术氛围如何？（了解环境）
工作内容：这个岗位除了日常的需求测试和自动化，是否会涉及性能、安全测试或质量体系建设等方面的工作？（了解职责深度）
挑战与机遇：目前团队在产品质量或测试效率方面面临的最大挑战是什么？您希望这个岗位的人才能帮助团队解决什么问题？（了解期望）
发展路径：公司对于技术同学的职业发展（如技术专精或管理路线）提供了哪些支持或通道？（了解成长空间）"

# 华为真题一

# 1. 自我介绍

# 2. 选一个项目详细介绍

答题思路：选择一个你最熟悉、最能体现你技术能力的项目，按照STAR原则（Situation, Task, Action, Result）来介绍。 答题话术： "我选择介绍我负责的电商支付链路项目。这个项目的目标是保证用户从下单到支付完成的全流程稳定可靠。

项目背景：随着业务量增长，原有支付系统经常出现超时和掉单问题。
我的任务：设计并执行全链路的测试方案，包括功能、异常、性能和自动化测试。
我的行动：
1. 绘制详细的业务流程图和系统架构图，识别所有关键接口和潜在风险点。
2. 设计了覆盖正常支付、失败重试、并发支付、第三方回调超时等场景的测试用例。
3. 使用Postman和JMeter进行接口功能和压力测试。
4. 搭建了基于Python + Requests的自动化测试框架，将核心流程自动化，并集成到Jenkins实现每日构建。
5. 引入了分布式链路追踪工具Skywalking，协助开发快速定位性能瓶颈。
项目结果：上线后支付成功率从99.2%提升到99.95%，自动化覆盖率核心流程达到80%，并建立了支付系统的常态化压测机制。"

# 3. 一整套流程都是你负责吗

答题思路：如实回答，如果是，就说明具体负责了哪些环节；如果不是，就说明你在团队中的角色和协作方式。 答题话术： "是的，在这个项目中，我独立负责了测试的全套流程。从前期的需求分析和测试计划制定，到中的测试用例设计、评审、测试数据准备、环境搭建、测试执行和缺陷跟踪，再到后期的自动化脚本编写、性能测试和上线报告撰写，都是由我主导完成的。当然，在这个过程中我会与开发、产品经理和运维同事保持密切沟通，确保测试的顺利进行和问题的有效解决。"

# 4. 试算这个公司写case从哪些角度

答题思路：面试官可能在问一个特定业务（如“试算”）的用例设计思路。从功能、业务规则、数据、界面、交互、异常、兼容性、性能等角度考虑。 答题话术： "如果是对一个'试算'功能（比如保费试算、贷款试算）设计测试用例，我会从以下几个角度考虑：

功能角度：输入不同条件，验证计算结果是否正确。
业务规则角度：验证试算是否遵循了业务定义的各种规则（如费率表、计算公式、优惠规则）。
数据角度：
- 边界值：输入金额、期限的上下边界。
- 特殊值：输入0、负数、小数位数很长的数、极大值。
- 非法值：输入非数字字符、SQL注入脚本等。
界面/交互角度：输入框的格式校验、提示信息、计算结果的展示格式、页面交互是否流畅。
异常角度：网络中断、服务异常时，试算功能是否有友好的错误提示。
兼容性角度：在不同浏览器、手机系统上试算功能是否正常。
性能角度：试算接口的响应时间是否在要求范围内。"

# 5. 给你一个需求，你从哪些角度去写用例

答题思路：展示你系统化的测试思维，可以从功能、UI、兼容、易用、性能、安全、异常、交互等维度展开。 答题话术： "当我拿到一个需求时，我会从多个维度来设计和编写测试用例，以确保覆盖的全面性：

功能测试：验证需求文档中定义的每个功能点是否都正确实现。这是最核心的部分。
UI测试：验证界面布局、字体、颜色、样式等是否符合设计稿。
兼容性测试：包括浏览器兼容（Chrome, Firefox, Safari等）、操作系统兼容（iOS, Android, Windows, macOS）、分辨率兼容、APP版本兼容等。
易用性测试：从用户角度出发，操作流程是否顺畅，提示信息是否清晰易懂。
性能测试：关注操作响应时间、页面加载时间、接口响应时间、并发能力等。
安全性测试：检查SQL注入、XSS攻击、数据泄露（敏感信息是否加密、脱敏）、权限控制等问题。
异常测试：模拟各种异常场景，如网络异常、服务异常、数据异常、操作中断等，看系统的容错和处理能力。
交互测试：关注功能模块之间的数据传递和状态同步是否正确。我会先使用XMind等工具进行测试点脑图发散，然后再将其细化成具体的测试用例。"

# 6. 你们手机号和身份证号有做安全吗，加密什么的

答题思路：肯定回答，并具体说明在存储、传输、展示三个层面分别采取了哪些安全措施。 答题话术： "是的，我们对手机号和身份证号等敏感信息有严格的安全处理：

传输安全：全程使用HTTPS协议进行加密传输，防止中间人窃听。
存储安全：在数据库存储时，我们对这些敏感字段进行了加密存储（如使用AES加密算法），而不是明文存储。查询时再解密。
展示安全：在前端界面显示时，会进行数据脱敏处理。例如，手机号会显示为138****1234，身份证号显示为110105******1234。后端接口返回给前端的数据也是脱敏后的数据。
日志安全：在打印应用程序日志时，我们会使用自定义的日志脱敏组件，确保敏感信息不会被记录到日志文件中，防止敏感信息泄露。这些措施共同构成了我们对用户隐私数据的安全防护体系。"

# 7. 写登录接口测试用例

答题思路：从功能、安全、性能、异常等角度设计用例。 答题话术： "登录接口的测试用例可以考虑以下方面： 功能测试：

用户名/密码正确，登录成功，返回正确的Token/Session信息。
用户名正确，密码错误，登录失败，返回明确的错误提示（如'用户名或密码错误'），且提示语不应泄露用户是否存在。
用户名不存在，登录失败，返回与上一条相同的错误提示（防止用户名枚举攻击）。
用户名/密码为空，登录失败，返回'用户名/密码不能为空'的提示。
密码是否加密传输（通过抓包工具查看请求体，密码应为加密后的密文）。 安全测试：
连续多次（如5次）登录失败，是否触发账号临时锁定或需要验证码。
登录成功后返回的Token，在其有效期内是否能够正常访问需要认证的接口。
用户登出后，之前的Token是否立即失效。
检查SQL注入漏洞（在用户名输入' or '1'='1等 payload）。
验证码是否可被绕过、暴力破解或重复使用。 性能测试：
单用户登录的响应时间应在100ms以内。
模拟100用户并发登录，检查接口的响应时间和错误率。 兼容性测试：
请求头的Content-Type等参数是否正确，不同客户端（Web, iOS, Android）调用是否都正常。"

# 8. 购物车去结算按钮没反应，怎么定位问题

答题思路：提供一套从前端到后端的系统性排查步骤，这是考察问题定位能力。 答题话术： "如果'去结算'按钮点击没反应，我会按以下步骤进行定位：

前端排查（首先进行）：
- 打开浏览器开发者工具（F12），切换到Console面板，查看点击按钮时是否有JavaScript报错（红色错误信息）。这是最常见的原因。
- 切换到Elements面板，检查按钮元素是否被其他元素遮挡或覆盖，导致无法点击。
- 检查按钮的HTML属性，是否被禁用了（disabled="true"）。
- 切换到Network面板，点击按钮，看是否有HTTP请求发出。如果没有请求发出，绝对是前端问题；如果有请求发出，则进入下一步。
后端排查：
- 查看上一步中发出的HTTP请求，查看其Status状态码。
- 如果状态码是4xx（如401未授权、403禁止访问），可能是用户认证或权限问题。
- 如果状态码是5xx（如500服务器内部错误），肯定是后端问题。
- 如果状态码是200，但响应体中的业务状态码（如code）是错误值，则根据错误信息判断是后端业务逻辑问题还是前端处理响应错误。
抓包分析：使用Charles/Fiddler抓包，对比正常和异常情况的请求/响应差异。通过以上步骤，基本可以快速将问题定位到前端或后端，并进一步缩小范围。"

# 9. 页面白屏、闪退怎么定位

答题思路：白屏是Web问题，闪退是App问题，分别说明排查方法。 答题话术： "对于Web页面白屏：

首选打开浏览器开发者工具（F12），这是最关键的一步。
查看Console面板是否有红色的JavaScript错误（如JS语法错误、变量未定义、依赖文件加载失败）。90%的白屏由此导致。
查看Network面板，检查关键的JS、CSS静态资源是否都加载成功（Status 200）。特别是单页面应用（SPA）的app.js、vendor.js等文件。
如果资源加载失败，检查网络连接或CDN服务是否正常。
如果是单页面应用，检查路由配置是否正确。

对于App闪退：

查看设备日志：这是最主要的手段。Android使用adb logcat命令抓取日志，iOS使用Xcode的Device and Simulator或第三方工具查看崩溃日志。在日志中搜索Fatal、Exception、Crash等关键词，找到崩溃的堆栈信息。
复现路径：尝试找到稳定复现的步骤，这能极大帮助开发定位问题。
监控平台：如果接入了像Bugly、Firebase Crashlytics这样的崩溃监控平台，直接平台上查看崩溃报告，里面会详细记录崩溃机型、系统版本、堆栈信息等。
资源问题：检查是否是因为内存泄漏导致内存溢出（OOM）而闪退。"

# 10. App捞日志怎么捞的

答题思路：说明Android和iOS两个平台获取日志的常用方法。 答题话术： "对于Android平台：

使用ADB命令：这是最常用和强大的方法。用USB连接手机和电脑，开启USB调试模式，在电脑终端输入adb logcat即可实时输出日志。可以添加过滤条件，如adb logcat | grep "关键字" 或 adb logcat -v time > log.txt 将日志输出到文件。
使用Android Studio：在Logcat窗口中可以看到连接的设备和应用日志，可以方便地按进程、日志级别过滤。
手机本地获取：有些App会集成日志SDK，在App的设置里可能有'保存日志到本地'的功能，或者摇一摇上传日志。

对于iOS平台：

使用Xcode：用USB连接Mac和iPhone，在Xcode的Window -> Devices and Simulators中选中设备，即可查看设备控制台日志。
使用第三方工具：如iTools、iOS Console等软件也可以查看iPhone的系统日志。
手机本地获取：在iPhone的设置 -> 隐私与安全性 -> 分析与改进 -> 分析数据中，可以找到系统生成的各种崩溃日志（ips文件），但需要符号化才能阅读。

在测试过程中，我最常用的就是ADB和Xcode来实时抓取和分析日志。"

# 11. 抓包用的多吗，Charles会用吗

答题思路：肯定回答，并展示你对Charles的熟练程度。 答题话术： "抓包是我日常测试工作中非常高频的操作，Charles是我最常用的抓包工具之一，非常熟悉。我经常用它来：

接口调试：截获App或Web的API请求和响应，查看请求参数、返回值、Header信息，用于辅助接口测试和问题定位。
弱网模拟：使用它的Throttle Settings功能模拟2G/3G/4G等不同网络环境，测试App在弱网下的表现。
断点和篡改：使用Breakpoints功能对特定请求进行断点，然后修改请求参数或响应结果，测试服务器的容错性和前端对异常数据的处理能力。
映射和重写：使用Map Local功能将线上请求映射到本地修改过的文件，用于快速调试；使用Rewrite功能修改请求/响应的特定内容。
HTTPS抓包：熟练配置Charles的SSL证书到电脑和手机，以解密HTTPS流量。 Charles是定位前后端问题、分析业务逻辑的利器。"

# 12. 抓包Mock会做吗，怎么做的

答题思路：解释Mock的概念，并说明如何使用Charles进行Mock。 答题话术： "会的，Mock是抓包工具一个非常实用的功能。我主要使用Charles的Map Local和Map Remote功能来实现Mock。

Map Local：将指定的网络请求重定向到本地文件。当我想模拟某个接口返回一个特定的响应（如错误码、超长数据、异常结构）时，我就在本地创建一个对应的JSON或TXT文件，然后在Charles中设置规则，将对这个接口的请求映射到我本地的这个文件。这样，App每次请求这个接口，收到的都是我预设的响应，非常适合构造各种测试场景。
Map Remote：将一个远程请求重定向到另一个远程URL。这通常用于将线上环境的请求定向到测试环境，或者替换某个资源文件的地址。

具体步骤（以Map Local为例）：

在Charles中抓取到需要Mock的接口请求。
右键该请求，选择Save Response...，将正常响应保存为一个本地文件（如mock_data.json）。
编辑这个本地文件，修改成我想要的Mock数据。
再次右键该请求，选择Map Local...，然后选择编辑好的mock_data.json文件。
启用Map Local功能。之后所有的这个请求都会返回我本地文件的内容。

通过Mock，我可以独立地测试前端功能，无需等待后端开发完成或配合，大大提高了测试效率。"

# 13. 做测试工作有什么优势

答题思路：结合个人特质，突出测试工程师所需的细心、逻辑思维、沟通能力、技术能力等。 答题话术： "我认为我从事测试工作有以下几个优势：

强烈的责任心和细心：我能够敏锐地发现开发中容易被忽略的细节和边界问题，对产品质量有很高的要求，有'守门员'意识。
严密的逻辑思维和分析能力：我擅长梳理复杂的业务逻辑，能够系统性地设计测试用例，并且在遇到问题时，能运用排查逻辑快速定位问题根源，而不仅仅是报告现象。
良好的技术基础和学习能力：我具备一定的编码能力（Python/Java），能够开展自动化测试、性能测试等技术性工作，并且乐于学习新技术和工具，不断提升测试效率。
出色的沟通和协作能力：我能够清晰地描述Bug现象，并与开发、产品等角色进行有效沟通，推动问题解决。我相信测试是串联整个研发流程的重要角色。
用户视角和同理心：我善于从用户的角度思考，关注产品的易用性和用户体验，这能帮助我发现更多潜在的问题。"

# 14. 项目排期重合了怎么办

答题思路：展示你的优先级排序能力、沟通协调能力和时间管理能力。 答题话术： "当项目排期重合时，我会采取以下措施：

评估优先级：首先我会和产品经理、项目经理一起沟通，明确各个项目的紧急程度和重要性，确定测试的优先级顺序。
沟通资源：如果优先级都很高，我会及时向上级领导反馈情况，说明当前的人力资源瓶颈，看是否能协调其他测试同事支援，或者协商是否可能调整某个项目的上线时间。
优化测试策略：
- 对于高优先级的项目，投入主要精力进行全量测试。
- 对于优先级稍低的项目，优先保障核心功能的测试，或者利用现有的自动化脚本进行回归，提高效率。
- 尽可能地将一些重复性的测试任务自动化，节省时间。
透明化进度：通过每日站会或邮件等方式，同步各个项目的测试进度和风险，让所有相关人员信息对齐，共同决策。我的原则是主动沟通、积极协调，而不是被动地接受所有任务最终导致质量下降或延期。"

# 15. 说一下接口自动化一整套流程

答题思路：从技术选型、框架搭建、脚本开发、持续集成到报告生成，完整地描述流程。 答题话术： "我们接口自动化的完整流程是这样的：

技术选型与框架搭建：我们选择Python + pytest + Requests + Allure作为技术栈。搭建项目结构，封装公共方法（如请求工具类、数据库操作、日志管理）。
脚本开发：
- 接口封装：将每个接口的URL、方法、默认参数封装成独立的函数。
- 用例编写：基于测试用例，使用pytest编写测试脚本。遵循Arrange-Act-Assert模式。
- 数据驱动：使用@pytest.mark.parametrize或将测试数据存储在JSON/YAML文件中，实现数据与脚本分离。
- Fixture应用：使用pytest的fixture管理前置操作（如获取Token、清理数据）和后置操作。
断言增强：不仅断言HTTP状态码，更重点断言响应体中的业务码、关键字段值，有时还需要断言数据库数据是否一致。
持续集成（CI）：将自动化项目集成到Jenkins，配置定时任务或Git钩子，实现代码提交后自动触发测试。
报告生成：测试执行后，自动生成并发布Allure可视化测试报告，报告中清晰展示了用例通过率、失败详情、日志步骤等，便于快速分析结果。
异常监控与维护：定期检查失败用例，分析是脚本问题还是接口变更，持续维护和优化脚本。"

# 16. 自动化case怎么写的

答题思路：阐述自动化用例与手动用例的区别，以及编写高质量自动化用例的原则和具体写法。 答题话术： "编写自动化用例我遵循以下原则和结构：原则：

原子性：一个用例只验证一个主要功能点，保持简洁。
独立性：用例之间没有依赖，可以任意顺序单独运行。
可重复性：每次运行结果应该一致，依赖于良好的数据准备和清理机制。
可读性：用例命名清晰，结构明了，必要时添加注释。

用例结构（通常遵循AAA模式）：

准备（Arrange）： setup部分。准备测试数据，初始化环境。例如，通过数据库操作插入一条待查询的数据。 python test_data = create_test_data() # 创建一个测试用户
执行（Act）：调用被测试的接口。 python response = user_api.login(test_data.username, test_data.password)
断言（Assert）：验证执行结果是否符合预期。包括状态码、响应体、数据库状态等。 python assert response.status_code == 200 assert response.json()["code"] == 0 assert db.query_user_status() == "active"

此外，我们会大量使用pytest的fixture来进行初始化和清理工作，使用parametrize来实现数据驱动，让一套逻辑可以覆盖多组测试数据。"

# 17. 怎么写断言的，需要断言的地方是哪些

答题思路：说明断言的多层次性和关键断言点。 答题话术： "我的断言是分层级的，不会只断言HTTP状态码200：

第一层：HTTP层断言：断言响应的状态码（200 OK, 201 Created, 400 Bad Request等），确保请求本身是成功的或被正确拒绝。
第二层：业务层断言（最关键）：断言响应体JSON中的业务状态码（通常是code、status字段）。这是判断业务逻辑是否成功的核心。例如 assert response.json()["code"] == 0。
第三层：数据层断言：
- 响应数据完整性：断言返回的JSON数据中关键字段存在且值正确（如用户名、订单号、金额）。
- 数据库数据一致性：对于写操作（增删改）的接口，一定会去数据库查询，断言数据库中的记录是否与预期一致。这是保证数据不丢不出错的关键。
第四层：业务逻辑断言：有时需要断言一些业务规则，比如支付成功后，订单状态、账户余额、流水记录必须联动变化，这可能需要查询多个表进行验证。

需要断言的地方：每一个接口的每一次调用都必须有断言，否则这个自动化用例就失去了验证价值，只是在'傻跑'。"

# 18. Ui自动化做过吗

答题思路：如果做过，就简要介绍用的什么工具、负责什么、遇到什么挑战；如果没做过，可以坦诚说明，但表示有了解和学习意愿。 答题话术： "是的，我做过Web UI和移动端App的UI自动化测试。

Web端：主要使用Selenium + Pytest框架。我们采用Page Object Model (POM)设计模式，将页面元素定位和操作封装在Page类中，测试用例只调用Page对象的方法，这样大大提高了代码的可维护性和复用性。
移动端App：使用Appium工具，同样采用POM模式。我会使用UiAutomator2等引擎来定位Android元素。
挑战与解决：UI自动化最大的挑战是稳定性，比如元素加载慢导致定位失败。我们通过封装显式等待（WebDriverWait）来代替硬性等待（sleep），并加入了失败重试机制和自动截图功能，有效提升了脚本的稳定性和排查效率。虽然UI自动化的维护成本相对较高，但对于核心且稳定的业务流程，它带来的回归价值是非常大的。"

# 19. 说一下压测全流程

答题思路：从目标制定、脚本开发、环境准备、执行监控到结果分析，描述一个完整的压测过程。 答题话术： "我们实施压力测试的全流程如下：

需求分析与目标制定：与开发、产品沟通，明确压测目标。例如，要支持1000用户并发登录，95%的API响应时间低于200ms，错误率低于0.1%。
场景设计与脚本开发：使用JMeter编写压测脚本。脚本要模拟真实用户行为，包括思考时间、集合点、关联、参数化（使用CSV文件管理测试数据）等。
环境准备：搭建一个独立的、与生产环境配置尽可能一致的压测环境。准备充足的监控工具，如APM（Application Performance Monitoring）工具（如Skywalking, Pinpoint）监控应用性能，Prometheus + Grafana监控服务器资源（CPU、内存、磁盘IO、网络IO）。
执行压测：
- 先进行基准测试：单用户测试，获取性能基准。
- 然后进行负载测试：逐步增加并发用户数（阶梯式增压），观察系统性能变化曲线，找到性能拐点。
- 最后进行稳定性测试（ endurance test）：在特定压力下持续运行一段时间（如2小时），检查是否有内存泄漏等问题。
监控与问题定位：在压测过程中，实时观察各项监控指标，一旦发现性能瓶颈（如数据库慢查询、某服务CPU飙升），立即记录并通知开发。
结果分析与报告：压测结束后，收集所有监控数据和分析日志，编写压测报告。报告内容包括：是否达到预期目标、发现的性能瓶颈、优化建议、系统当前的最大承载能力等。"

# 20. 压测工具用什么

答题思路：列举最常用的压测工具，并说明你的使用经验和选择理由。 答题话术： "我最常用也最熟悉的压测工具是 Apache JMeter。

选择原因：它是开源且功能非常强大的纯Java应用，既能做接口功能测试，更能做强大的性能测试。它支持HTTP、TCP、JDBC等多种协议，图形化界面易于上手，也支持命令行模式便于集成到CI/CD。它的插件生态也很丰富。
其他工具：
- LoadRunner：功能非常强大的商业工具，但成本高昂，在一些传统大型企业中使用较多。
- Gatling：基于Scala的开源工具，性能开销比JMeter小，脚本用代码编写，更易于版本管理，但学习曲线稍陡。
- locust：基于Python的开源工具，可以用Python代码定义用户行为，非常灵活。
- wrk：一款轻量级的命令行压测工具，非常适合做HTTP基准测试。

对于大多数Web接口的压测需求，JMeter已经完全能够满足。我会根据项目具体需求和团队技术栈选择合适的工具。"

# 21. 现在的工作强度是啥样的，上班时间怎么样，他们是早10晚9左右

答题思路：这是一个了解公司工作节奏和文化的问题，要表现出对工作投入的积极态度，同时也要关心工作与生活的平衡。 答题话术： "我目前的工作节奏也比较紧凑，通常是早9晚7左右，在版本发布前夕或者遇到紧急线上问题时，也会和团队一起加班攻关，保证产品顺利上线。我对工作投入度很高，也理解互联网行业的工作特性。贵公司早10晚9的节奏我可以接受，我更关注的是工作的价值感和团队的协作氛围。想了解一下，这种工作节奏是常态化的，还是主要集中在特定的发版周期呢？团队内部是如何保证高效协作和员工可持续性发展的？"

# 22. 抖音直播间弹幕测试用例

答题思路：从功能、性能、兼容性、异常、UI交互、安全等多个维度设计测试点。 答题话术： "对于直播间弹幕功能，我会从以下角度设计测试用例： 功能测试：

基础功能：用户能否正常发送文字弹幕、表情弹幕（系统表情/Emoji）、特殊符号弹幕。
显示功能：发送的弹幕能否在直播间界面正确、清晰地显示出来（颜色、字体、位置）。
交互功能：点击弹幕用户头像能否跳转到其个人主页。
特殊弹幕：付费礼物弹幕、高亮弹幕、进场通知等特殊消息是否正常显示且效果正确。
刷屏控制：连续快速发送多条相同或类似弹幕，是否触发刷屏限制（如短暂禁言）。
敏感词过滤：发送包含预设敏感词的弹幕，是否被过滤为***或直接发送失败并有提示。

性能测试：

单直播间大量用户（如万人）同时发弹幕，消息接收是否延迟，客户端是否会卡顿或崩溃。
长时间停留在直播间，弹幕消息累积过多，客户端内存占用是否正常，是否有内存泄漏。

兼容性测试：

在不同机型（iOS/Android）、不同屏幕尺寸、不同系统版本上，弹幕显示和功能是否正常。
在不同版本的抖音APP上，弹幕功能是否正常（向前兼容）。

异常测试：

网络中断时发送弹幕，网络恢复后消息是否自动重发或是否有提示。
服务端异常时，客户端弹幕功能是否有友好提示，而不是卡死或白屏。

UI交互测试：

弹幕是否会遮挡关键直播内容（如主播的脸、商品链接）。
弹幕的滚动速度、密度是否适中，不影响用户观看直播。
是否有开关可以关闭弹幕显示。"

← 互联网中厂通信厂商 →