一、自我介绍
（自我介绍不局限于下面模板，灵活表达）
面试官你好，我叫xxx，今年xx岁，家乡是xx省xx市。20xx年毕业后一直从事软件测试工作，到现在已经x年了。
目前为止，经历过x家公司。第一份工作是在xxx公司，工作了大概x年，岗位是测试工程师，主要负责公司的web和APP项目的功能测试；第二份工作是在xxx公司。。。
工作这几年，我积累了丰富的功能测试经验，可以独立负责项目的功能测试。另外还负责过服务端的接口测试，可以用测试工具实现基本的接口自动化。其他的像Linux和SQL工作中用的也比较多。代码方面会一些Python基础，现在正在持续学习中。
以上就是我的一些基本情况，谢谢！
二、 测试基础
1. 低-如何制定测试计划
测试计划包括：
测试目标、测试范围、测试环境的说明、测试类型的说明（功能，安全，性能，稳定性）、测试工具、模块的划分、测试负责人、测试执行轮次的时间安排、测试的风险等。
2. 中-在项目中如何保证软件质量
项目质量不仅仅是某个人或某个团队来保障的，而是整个团队一起努力的结果，因此，在公司级别需要有一个规范的项目流程
A. 产品，保证迭代过程中的产品逻辑，对于可能的兼容，升级做出预判，并给出方案
B. 架构设计，满足产品表达的同时，保证设计的延续性
C. 开发，产品细节的保证，技术方案选择要严谨，考虑兼容，性能，开发完成后要充分自测，严格遵循开发规范操作
D. 测试，验证产品逻辑，站在用户角度对交互设计进行系统验证，尽可能多的使用技术手段保证测试质量
E. 运维，制定严谨的上线流程和权限管控，做好生产环境监控报警，出现事故后有应急预案
3. 高-功能测试用例一般包含哪些内容？
核心内容：
用例编号、标题、前提条件、测试步骤、预期结果、用例优先级、所属模块、输入数据等
4. 中-黑盒（或功能）测试用例设计方法有哪些？
主要有等价类、边界值、流程分析、因果图、判定表、场景分析、错误推测等
5. 高-APP测试和web测试有什么区别
(1) 从系统架构来看的话：web端一般都是b/s架构，基于浏览器的，app是c/s架构，是有客户端的。
(2) 兼容性方面：Web是基于浏览器的，所以更倾向于不同浏览器（Chrome、firefox）的兼容；App测试则必须依赖于手机，更关注系统版本、分辨率、屏幕尺寸等兼容性问题。
(3) 除了功能测试，APP端还需要额外关注一些专项的测试，比如弱网测试、中断测试、安装/卸载测试、流量/电量的测试，移动端性能测试等
6. 高-发现一个bug，怎么定位是APP端还是服务端的问题
A、抓包分析，对接口进行抓包分析，如果请求里的参数出现错误，一般都是客户端bug；如果请求正常而响应是错误的，那就是服务端的bug
B、日志分析，还可以通过查看客户端/服务端的日志，分析有没有异常的日志信息，从而确定具体原因
7. 高-讲一下你们的测试流程
1> 需求评审和分析
2> 制定测试计划
3> 根据需求文档编写测试用例
4> 测试用例评审
5> 提测后执行冒烟测试
6> 执行第一轮测试，找bug
7> 执行回归测试，验证bug
8> 执行第二轮测试
9> 部署项目到预生产环境
10> 预生产环境测试
11> 发测试报告
12> 项目上线
13> 线上验证（主流程、主功能点的验证）
8. 高-当开发人员说不是 BUG 时，你如何应付？
开发人员说不是bug，有2种情况：
一是需求没有确定，所以这个时候可以找来产品经理进行确认，需不需要改动，商量确定好后再看要不要改。
二是这种情况不可能发生，所以不需要修改，这个时候可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？
如果还是不行，那可以给这个问题提出来,跟开发经理和测试经理进行确认。如果最终bug被确定不改，那么就要在测试报告里面记录一下，以便以后查阅。
9. 中-遇到概率性bug怎么办？
首先需要明确的是，该类bug也是需要提bug的，描述清楚当时操作环境、操作步骤、数据、并提供必要日志，可备注上可能产生原因。然后耐心一点，运用排除法、错误推测找规律，必要时找开发人员一起定位分析讨论。如果最终仍未解决，那么需要在测试报告中体现，并分析可能造成的影响，大家一起权衡该bug是否可遗留。
10. 低-如何提交一份高质量的缺陷跟踪单
首先要明确，缺陷跟踪单不仅仅是给自己看的，所以高质量的缺陷单，最主要的一条判断标准是，别人一看就懂，标题简洁明了，步骤条理清晰。还需考虑缺陷的完备性，比如缺陷等级、所属功能模块、版本、复现步骤、预期结果、实际结果、产生原因、日志截图等
11. 低-Bug优先级和严重程度如何划分
严重：需要立即解决的问题，比如死机、进程无响应、崩溃
高：软件的主要功能错误，或者引起数据丢失的缺陷
中：影响软件功能和性能的一般缺陷
低 ：对软件的质量影响非常轻微的缺陷，多为建议性或者UI层级的问题
12. 中-做好测试用例设计工作的关键是什么
1) 熟悉业务需求和用户使用场景
2) 了解本次需求对其他系统的影响
3)了解开发技术实现和数据库设计
4) 从不同的维度编写测试用例，功能、性能、安全、兼容等
13. 中-给你一个项目，如何开展测试
1.查找需求说明、项目设计等相关文档，分析需求。
2.制定测试计划，确定测试范围和测试策略。
3.设计测试用例，包括功能、兼容、性能、安全等方面
4.开展测试执行
5.回归测试以及发送测试报告
14. 高-bug的生命周期
New：新发现的bug，指定给对应的开发
Open：开发确认bug，并且认为需要进行修改
Fixed：开发人员进行修改后标识成已修复状态，等待测试人员的回归测试验证
Rejected：如果开发认为不是Bug，则拒绝修改
Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改，并需要给出理由
Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改
Later：延期修改（下一个版本修复）
15. 低-黑盒测试和白盒测试的区别
黑盒测试就是把系统当成一个黑盒子一样，不需要了解系统内部的细节，只关注输入和输出，通过手动
输入不同的数据，来验证输出是否符合预期；
白盒测试需要了解系统内部实现细节，通常是针对函数进行测试，需要写测试代码来调用对应的函数，
通过传入不同的参数，来测试函数返回值是否符合预期。
16. 中-测试报告里都包含哪些内容
测试范围，测试时间、参与人员、测试策略、BUG数量、上线风险、遗留问题、测试是否通过
17. 高-如何提高用例的覆盖率，减少漏测
1、要根据需求文档来编写用例，确保每条需求都被对应的用例覆盖
2、要充分理解业务，挖掘隐形需求，并编写对应的用例
3、除了正常的业务场景，多考虑一些异常的场景和数据
4、要从多个维度对软件进行测试，功能、性能、安全等各方面来考虑
5、多站在用户的角度去思考问题，模拟用户的使用场景
6、组织用例评审
18. 高-当发现一个bug时，如何确定是不是一个bug
1、看需求文档，是否有明确的要求
2、看下这个问题是否违反了正常人的行为习惯，或者行业的通用规范
3、可以找产品经理或者开发人员沟通确定是否为bug
4、对于无法打成一致的问题，可以组织相关人员开会，共同来决定是否为bug
19. 高-没有需求文档，如何开展测试
没有需求文档不代表没有需求。
可以找相关人员进行沟通，获取需求，比如产品经理、开发人员
可以参考同行业竞品，总结梳理需求
可以根据用户的使用习惯和一些行业的规范，来总结一些功能需求
篇幅限制此处仅展示部分面试题及答案，完整版已经整理成文档，可以点击下方卡片获取哈
