测试岗的面试其实都是大同小异的，这里我收集整理了185道高频面试题，希望对在找工作或者准备跳槽的各位小伙伴有所帮助！
一. 测试基础
1.如何制定测试计划
参考答案：
测试计划包括测试目标、测试范围、测试环境的说明、测试类型的说明（功能，安全，性能，稳定性）、测试工具、模块的划分、测试负责人、测试执行轮次的时间安排、相关文档在文档管理库中的位置、测试的风险 。其中模块划分需要根据测试人员对于业务的熟悉程度及个人能力进行分配，工作量的估算需要根据以往测试时的经验，结合本次需求的修改，可以大致估算出测试量
2.在项目中如何保证软件质量
参考答案：
项目质量不仅仅是某个人或某个团队来保障的，而是整个团队一起努力的结果，在公司级别需要有一个规范的项目流程
1. 产品，保证迭代过程中的产品逻辑，对于可能的兼容，升级做出预判，并给出方案
2. 设计，满足产品表达的同时，保证设计的延续性
3. 开发，产品细节的保证，技术方案选择要严谨，考虑兼容，性能，开发完成后要充分自测，严格遵循开发规范操作
4. 测试，验证产品逻辑，站在用户角度对交互设计进行系统验证，尽可能多的使用技术手段保证测试质量
3.功能测试用例一般包含哪些内容？
参考答案：
要素一般包括：用例编号、用例优先级、测试目的、所属模块、前提条件、测试环境、
输入数据、测试步骤、预期结果、测试脚本等
核心要素：用例优先级、测试目的、预期结果
4.黑盒（或功能）测试用例设计方法有哪些？
参考答案：
等价类划分方法：等价类划分法将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。
边界值方法：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。
错误推测方法：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。
因果图方法：因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。
判定表驱动分析方法：判定表是黑盒测试的方法之一，判定表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。
正交分解法：是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。
场景分析法：分析软件应用的场景，从用户的角度出发，从场景的角度来设计测试用例，是一种面向用户的测试用例设计方法。关心用户做什么，而不是关心产品做什么。
全局探索式测试方法：测试人员根据应用程序所提供的信息自由发挥，不受限制，不受任何约束的探索程序的各种功能。
5.APP 测试和 web 测试有什么区别
Web 端测试和移动端测试类型基本相似，都需要进行功能测试、性能测试、安全性测
试，他们主要区分 web 端一般都是 b/s 架构，基于浏览器的，app 是 c/s 架构，是有客户端的。
(1) 从系统架构来看的话：web 测试只要更新了服务器端，客户端就会同步更新；而如果是app 端下修改了服务端，意味着客户端用户所有使用的核心版本都需要进行回归测试一遍。
(2) 客户端性能方面：Web 端可能只会关注响应时间；App 则还要关心流量、电量、cpu、等；
(3) 兼容方面：Web 是基于浏览器的，所以更倾向于浏览器（IE、Chrome、firefox）和电脑硬件，电脑系统方向的兼容；App 测试则必须依赖于手机或者 pad，不仅要看分辨率、频目尺寸、重要看设备系统。
6. 发现一个 bug，怎么定位是 APP 端还是服务端的问题
1. 抓包分析 通过对客户端进行抓包，分析服务端返回的数据是否符合预期，如
果服务端数据是正确的，那就是客户端的问题
2. 日志分析 可以通过查看客户端/服务端的日志，分析有没有异常的日志信息，
从而确定具体原因
7.针对 App 的安装功能，写出测试点？
1. 正常安装测试，检查是否安装成功。
2. APP版本覆盖测试。例如：先安装一个1.0版本的APP,再安装一个高版本(1.1版本)的APP，检查是否被覆盖。
3. 回退版本测试。例如：先装一个 2.0 版本的 APP,再安装一个 1.0 版本的 APP,正常情况下版本是可以回退的。
4. 安装时内存不足，弹出提示。
5. 根据安装手册操作，是否正确安装。
6. 安装过程中的意外情况（强行断电、断网、来电话了、查看信息）等等，检查会发生的情况。
7. 通过‘同步软件’，检查安装时是否同步安装了一些文件。
8. 在不同型号、系统、屏幕大小、分辨率上的手机进行安装。
9. 安装时是否识别有 SD 卡，并默认安装到 sd 卡中。
10. 安装完成后，能否正常启动应用程序。
11. 安装完成后，重启手机能否正常启动应用程序。
12. 安装完成后，是否对其他应用程序造成影响。
13. 安装完成后，能否添加快捷方式。
14. 安装完成后，杀毒软件是否会对其当做病毒处理。
15. 多进程进行安装，是否安装成功。
16. 在安装过程中，所有的提示信息必须是英文或者中文，提示信息中不能出现代码、符号、乱码等。
17. 安装之后，是否自动启动程序。
18. 是否支持第三方安装。
19. 在安装中点击取消。
8.持续集成的目的是什么
持续集成指的是，频繁地（一天多次）将代码集成到主干。
它的好处主要有两个：
（1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
（2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败，就不能集成。
9.如何测试纸杯
功能度：纸杯容量（空杯、满杯升数、半杯升数）；水能不能被喝到；纸杯形状（正圆柱、上宽下窄圆柱、上窄下宽圆柱、其他形状）、纸杯材质（全纸质、全塑料、半纸半塑料）、纸杯耐温程度（冷水、热水、冷水、冰）、支持盛放液体名称（水、咖啡、牛奶、可乐）
安全性：杯子有没有毒或细菌、装液体多久有化学反应（例如：异味）
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用、装液体多久漏水、装热水多
久变形、装多少度热水变形
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水放 24 小时检查泄漏时间和情况；盛上汽油放 24 小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透；手挤压多久变形（单
手、双手）
10.当开发人员说不是 BUG 时，你如何应付？
开发人员说不是 bug，有 2 种情况，一是需求没有确定，所以这个时候可以找来产品经理进
行确认，需不需要改动，商量确定好后再看要不要改。二是这种情况不可能发生，所以不需
要修改，这个时候可以先尽可能的说出是 BUG 的依据是什么？如果被用户发现或出了问题，
会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不
行，那可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修
改就不改。如果最终 bug 被确定不改，那么就要在测试报告里面记录一下，以便以后查阅。
11.遇到概率性 bug 怎么办？
概率性 bug，又叫幽灵 bug，首先需要明确的是，该类 bug 也是需要提单的，描述清楚当时操作环境、操作步骤、数据、并提供必要日志，可备注上可能产生原因。然后耐心一点，运用排除法、错误推测找规律，必要时找开发人员、项目经理一起定位分析讨论，如果最终仍未解决，那么需要在测试报告中体现，并分析可能造成的影响，大家一起权衡该 bug 是否可遗留。
12.一个身份证号码输入框，怎么设计用例
校验身份证号规则的有效性（包括地址码、生日期码、顺序码和校验码
校验 15 位身份证号和 18 位身份正好都是可用的
校验末位是 X 的情况
校验不足 15 位、16-17 位和大于 18 位的情况
如果是必输项，校验不输入的时候会不会有正确的提示
如果不是必输项，则要校验不输入的时候流程能否正常进行
校验输入非数字的情况，是否会有正确提示信息（包括大小写字母、汉字、特殊字符和标点符号）
校验输入全角的数字的时候，系统是否会识别（这个得根据需求确定是否可以使用全角的数字）
13.什么是回归测试？如何做回归测试？
回归测试，即就是在软件生命周期中，只要软件发生了改变，就可能给该软件产产生问题;
所以，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否破坏原有的正常功能。
回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试
那我们改如何做回归测试呢？ 总结为以下几点
1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
14.如何提交一份高质量的缺陷跟踪单
首先要明确，缺陷跟踪单不仅仅是给自己看的，所以高质量的缺陷单，最主要的一条判
断标准是，别人一看就懂，标题简洁明了，步骤条理清晰。还需考虑缺陷的完备性，比如缺陷等级、所属功能模块、版本、复现步骤、预期结果、实际结果、产生原因、日志截图等
15. 项目测试流程有哪些？
需求评审、测试计划、技术评审、用例编写、用例评审、测试执行、测试报告、线上验 证、项目总结
16.Bug 优先级和严重程度如何划分
Priority(优先级)和 Severity(严重程度)是提交 bug 的两个重要属性。
通常，测试 人员在提交 Bug 时，只定义 Bug 的 Severity, 即该 Bug 的严重程度，而将 Priority交给 Project Leader 或 Team Leader 来定义，由他们来决定该 Bug 被修复的优先等级。某种意义上来说，Priority 的定义要依赖于 Severity，在大多数情况下，Severity 越严重，那这个 Bug 的 Priority 就越高。
Severity（严重程度）如下：
Blocker（有妨碍的）: 即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异 常退出、无法测试、造成系统不稳定
Critical（紧要的）：即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系 统稳定性
Major（严重的）：即界面、性能缺陷、兼容性。
Minor/Trivial（次要的/不严重的）:即易用性及建议性问题。
Priority（优先级）：Immediate（立刻）、Urgent（紧要、优先）、High（高度重视）、
Normal（正常）、Low（稍缓）
17.您认为做好测试用例设计工作的关键是什么
关键点就是熟悉需求，但是需求可以分为以下几个方面
1. 熟悉本次业务需求
2. 熟悉其他系统和本次需求的关联
3. 熟悉开发设计文档，了解开发实现逻辑
4. 熟悉数据库设计文档，了解数据存储
5. 熟悉项目架构，发现隐藏需求
18.给你一个网站，如何开展测试
1.查找需求说明、网站设计等相关文档，分析测试需求。
2.制定测试计划，确定测试范围和测试策略。
3.设计测试用例，包括功能、兼容、性能、安全等方面
4.开展测试执行
5.回归测试及测试总结
