01
自我介绍篇
目的
一般公司第一个问题，主要目的通过自我介绍先了解下你为之后的提问找好切入点，面试官抓紧时间看下你的简历大概了解下你的背景经历，还有缓和下气氛打开话题作准备。
如何去答
简单介绍下项目，重点在负责的工作是什么，在工作中运用了什么技术，学习到了什么，总结了什么经验。除此以外，还要把你自己学习的一些技术也说进去，哪怕你工作中没有用到，但只要你会的，都展现出来，当然前提是这个东西你确实自己研究过，禁得起拷问的才行。
举个栗子
面试官好，我叫xxxx，毕业于xxx大学xxx专业，曾先后任职于xxx公司，最近一份工作是xxx工作，负责xxxx，有功能测试经验，性能，自动化，接口等，做过web，app，参与过敏捷项目，xxxx，最后很荣幸有这次机会来xx公司面试，也希望有机会能加入。
不要太详细解释你做的具体项目，因为在接下来的时间会给你机会具体介绍，只需要流水账似的过一遍你的履历就行，几个亮点就够了。
02
测试计划篇
“5W1H”原则
坚持“5W1H”的原则，明确测试内容与过程
测试范围和内容
明确测试的范围和内容（WHAT）
计划的设计者必须对整个项目系统的设计方法、具体功能分布、性能以及安全性的要求等等，有充分的了解。
大致包括以下内容：各功能点、性能、安全性、稳定性、兼容性、易用性等等，需要列出上述各内容的详细内容及指标。
测试目的
明确测试的目的（WHY要说清楚：我们为什么要进行该项目测试？针对具体的测试项目,到底测试的“度”该如何把握之类的问题。
测试时间
明确测试的开始和结束日期（WHEN）
测试开始结束日期，是建立在开发的开始结束日期、测试内容、人力资源等综合因素的基础之上的，这里需要明确到具体的年月日，并随开发进度而波动。时间的安排上，最好能预留一段的缓冲时间，以便与应对计划的变更，也可以让测试人员有时间完善和补充测试用例。
测试文档存放位置
明确给出测试文档存放位置（WHERE）
整个测试过程中的文档管理的重要性就不必说了，但是，文档管理的工作也必须有计划的进行。计划中需指出明确的文档存放位置，以达到较好的文档管理效果。方便相关人员的监督和看。
测试人
明确测试人员的任务分配（WHO）
好的任务分配，可以提高测试的质量和效率。 我觉得，只有充分了解你的团队的整体实力和团队中每个成员的特点，这样才能做出合理的分工。这里需要确定测试人员的时间及参与测试的方式，如果需要新招聘人员，还要考虑招聘计划。另外，由于每个人的思维方式不同，所以每个项目的测试至少安排两个或两个以上的测试人员以发现更多的BUG。
测试方法和工具
明确指出测试的方法和测试工具（HOW）
结合不同的测试领域，给出具体的测试方法，以供组内成员参考并借鉴。列出测试过程中需使用的测试工具，以便，组内相关成员提前准备环境及相关知识，以提高测试的质量和效率。 采用评审和更新机制，确保测试计划满足实际需求因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可行性进行评估，以保证测试的质量。
03
测试策略篇
测试策略是测试计划中的重要组成部分,测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素， 而测试策略则是说明实际测试过程中，应该怎样具体实施。因此测试策略一定要描述详尽并且重点突出。
要制定出好的测试策略，需要了解软件的结构、功能分布、各模块对用户的重要程度等，从而决定测试的重点、优先次序。
为了达到有效的覆盖，需要考虑用例的设计方法（详细可参见赵宏梅的《测试用例设计方法》系列）。 回归测试也需要充分考虑，根据项目的进度，版本的迭代率，合理安排回归测试的方式。结合各相关影响因素来制定有效的回归测试策略，
04
测试风险评估篇
对于测试过程中可能遇到的风险，也要制定出相应的应对策略。
通常的风险可能是：项目计划的变更、测试资源（测试人员）不能及时到位等等。 对此，我们要制定相应的策略。比如：对项目计划的变更，可以考虑建立良好的沟通渠道，让测试人员及时了解到相应的变更，以做出适当的调整；对于资源的风险，我们可以考虑建立后备机制，后备人员前期也可参加项目例会、评审等活动，以便出现资源紧缺时及时调用。
05
测试用例篇
我觉得首先要确定好面试官跟你描述的功能是什么，主要包括哪些方面，确定好范围，然后再开始设计；其次一定要自己多总结一些通用的功能测试框架，背下来，回答时套用在不同的功能上；而且不要只关注功能方面，接口、性能、兼容、安全等都要考虑全面，下面是具体我被问到的一些问题
1. 测试朋友圈发送功能
2. 测试微信的发送功能
3. 测试输入框功能
4. 测试数据加载过程
5. 测试注册登录和验证码功能
6. 测试视频播放
7. 测试直播中的送礼物
06
测试流程篇
需求阶段-开发阶段-测试阶段-上线阶段-上线后
需求阶段
需求文档规范
首先需求文档要有规范，这部分测试可以要求如果产品需求文档不够完善标准的话，一个好的需求文档应当包含如下几个方面：
- 版本信息（包含版本履历，创建人，修改人，日期等）
- 需求概述包含背景，目的，影响范围等
- 流程图（包含业务流程图，系统操作流程图）
- 具体功能模块详解
需求评审前
- 测试负责人拆分需求模块，分配对应的模块负责人
- 模块负责人进行需求了解、分析，整理需求疑问、建议等，若时间允许，提前发送邮件或口头与产品进行确认，提前发送邮件或口头与产品进行确认。
需求评审中
- 测试需要思考的地方不限于以下几点
了解需求产生的背景，了解产品人员想要达到的效果以及要解决的核心问题是什么？ - 一个新功能添加的必要性需要评估。(产品预期状态是否能够达到，投入产出比是否合适，评估这个需求是否合理，从用户体验角度考虑)
- 功能模块是否与其他模块需求冲突，冲突时是否有相关处理方式？
- 涉及到UI方面，文字，颜色，位置，大小，样式，布局等是否有详细说明，效果是否统一
- 确认之前标注的地方得到解答
- 最后测试需要输出的：
- 测试模块拆分负责表，对应模块测试负责人，测试所需时间
评审会议所需要输出的；需求评审会议记录
需求评审后
- 项目经理根据会议过程整理出会议记录公示所有相关参会人员包括相应领导。
- 测试对应模块负责人开始用例设计，准备测试数据，按照日期监督各模块开发负责人，准时提测
- 产品及时更新文档，确保文档内容是会议三方所述一致
会议记录至少包括以下内容：
- 会议中没有解决的疑问地方，产品给出的解决方案（有些地方产品也需要会下跟业务再次确认）
- 明确对应模块开发负责人，测试负责人，开发测试对应所需要的时间等
- 需求影响的模块以及所涉及到的风险，上线之后应对的容灾方案，回滚计划等
需求优先级排期：
需求变更：
三方确认，如果确认一致通过同意变更，产品发出邮件，产品更新文档，开发重新修改研发时间，测试重新调整计划，是否需要延期，测试工作量，人力，时间资源等调配
跨部门，跨组需要多方配合的需求如何展开测试?
避免以下点即可，如何避免以下问题多沟通多交流，拉到一个群组交流，由项目经理牵头组织，如果没有测试负责。
通过文字邮件等方式确认每个模块开发测试按时完成，最终进行联调测试。
开发阶段
- 参与开发详细设计评审，了解功能实现过程
- 开发书写代码，完毕之后，有两种方式一种人工方式进行code review，组内leader负责检查code。
- 另一种提交到系统，由系统通知相关负责人检查或者借助第三方工具如(Checkstyle，FindBugs，PMD，Jtest），如果review通过则允许提交到svn
- 开发在开发环境自测，书写自测报告
测试阶段
从需求评审阶段就开始，一个是分析需求拆分模块，每个对应的模块负责人书写测试用例（一个根据开发详设或还有就是需求文档），进行测试用例评审，当开发提测之后进行code review环节（适当补充用例），准备测试数据测试环境调试，冒烟测试（不接受一句话提测，对于提测信息不明确或者缺少自测报告或者冒烟不通过给予打回），通过之后进行功能，性能，兼容性，异常测试等（如果有接口测试一定是在客户端没提测时候，如果涉及到前后端分离测试，那么都是先测试服务端，然后测试客户端），提交bug，验证fix的bug，回归测试，最后确定没有问题，发送验收邮件，提交上线申请。
上线阶段
上线的标准：
- 本版本所有需求都已经实现
- 本版本所有测试任务已经执行完毕
- 确认所有major级别bug都关闭，个别问题如果不修复要有明确说明，bug解决率要达到95%以上，
- app稳定性评估，包含以下三个方面
自动化评测
（1）随机浏览自动化评测结果无新增的未知的Crash发生；
（2）随机浏览自动化评测中所有已知Crash能够用修复的均已修复。
线上灰度崩溃
（1）线上主进程Crash全部修复；
（2）线上子进程所有已知Crash均已修复；
（3）线上子进程没有新增的密集的崩溃。
与上一版本数据对比
（1）对上一版本稳定性对比，不差于上一版本。
- app性能评估
页面加载性能
（1）Wifi页面加载速度与上一版本相比，不能下降。
（2）2G3G页面加载速度与上一版本相比，不能下降。
冷启动时间评测
（1）冷启动时间与上一版相比，不能增加。
（2）向竞品看齐，与竞品的差距情况公示。
主观性能感知
（1）高端机不能有非常卡的情况，有点卡的情况也应该控制数量
（2）高中低端机均不能有较线上版明显的卡顿内容
- 对于上线出现的问题应急措施考虑
出现问题，有完善的应急预案，出现问题能够及时回滚或者马上修复
如果上线失败，事后复盘总结出此次的问题，形成邮件形式发送相关人员，避免下次再次出错
上线之后
- 线上监控新功能运行情况
- 出现异常情况或者问题，需要临时发版重新打补丁包
补丁包提测的内容一般是：
修复线上待修复的功能逻辑Bug
修复线上待修复的崩溃
优化线上体验不好的产品需求
- 补丁包评估方法
通过工具检测开发提交的代码
三方及时沟通，为何修改，影响范围，测试需要做的
最后确认要发送补丁包，书写邮件告知相关负责人补丁包内容原因影响范围等
产品功能复合需求，产品验收通过，进入code freeze状态，开发打包发线上环境（一般公司除了测试环境还有会有预发环境模拟）
07
实际项目篇
*主要涉及到你简历所写的项目，举几个例子自动化，你们怎么做的，你负责的是哪块业务
*主要考察你自动化技术水平，同时涉及到的一些技术点会顺带着一起问出来，比如分层自动化，接口自动化。
*有没有使用编程做一些工具或者工具二次开发等
*团队协作如何处理问题的，你项目中你遇到困难如何解决的，还有有没有做的不好的地方如何改进。
*项目架构相关的，现在架构都是web／app－站点层－服务层－数据层
09
算法篇
1. 排序（冒泡、堆排序、快速排序等）
2. 二分查找
3. 判断素数
4. 单链表反转
5. 判断是否为回文数（aabb格式）
6. 十进制转换成二进制
7. 判断IP的有效性
8. 合并两个有序数组，生成一个有序的大数组，要求时间复杂度最低
9. 堆排序
10. 二叉树排序
11. 图的最短路径
当然除了上面这些基础的算法，有的面试官还会临时给个有规律的数据，让你写出一个算法或给出思路，考验下逻辑思维能力，当然如果不会也不要气馁，有的面试官会给你提供思路引导你。
10
Linux、mysql篇
以下只是一些例子，但是可能还有更多情况
1) 常用命令有哪些，包括日常看log一些命令,查看端口命令，哪个端口被占用，关闭进程，打压缩包，vim编辑命令，grep，sed，awk属于高级命令可以简单看下。
2) 数据库的增删改查
3) 数据库的关联查询
4) 数据库建立索引的优点，如何搜索数据的
11
Java/Python/shell开发语言篇
这个问题也是被问到的概率很高，主要是看你简历中写了哪些语言，以下问题都是关于Java/shell/python的
1）./ 和sh 执行shell脚本的区别
2）shell脚本中的第一行的作用是什么
3）怎么用shell脚本取出日志中倒数第二列的内容
4）lamda函数是什么
5）Python中的内存管理
6）字典、列表、元祖的区别，在内存中都是如何存储的，想要搜索数据时，各自的时间复杂度是多少
7）python怎么安装包
8）re模块中的match和search的区别
10）sokect编程
11）items，iteritems区别
12）Java中的collection
13）Java中常用的一些类库
14）Java中怎么开启线程
12
操作系统篇
一般公司不太会问这么底层的，但是360面试比较喜欢问
1) 进程，线程，协程概念区别
2) 进程同步互斥，进程间通信概念
3) 进程调度算法，死锁概念
4) 页面置换算法，makefile概念
5) 虚存，实存，共享内存
13
ADB篇
• android四大组件、activity生命周期、ANR、五种布局、Android动画原理
• adb server重启，apk的安装与卸载
• 文件的push、pull，apk的静默安装
• app的启动停止，app包查找
• 截屏、录屏，logcat，dumpsys meminfo、dumpsys cpuinfo
14
Monkey篇
• monkey命令，monkey场景重现
• 提取crash、ANR信息的方法，填加throttle参数，忽略crash和ANR
• monkey执行指定类型的事件
15
自动化篇
自动化框架包括；数据驱动，关键字驱动，数据＋关键字混合，分布式，行为驱动（lettuce），具体结合自己的项目展开。
接口自动化
怎么做的接口自动化，工具有哪些，你自己怎么写的
模块接口测试
1) 检查接口返回的数据是否与预期结果一致。
2) 检查接口的容错性，假如传递数据的类型错误时是否可以处理。例如上面的例子是支持整数，传递的是小数或字符串呢？
3) 接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。
4) 接口的性能，接口处理数据的时间也是测试的一个方法。牵扯到内部就是算法与代码的优化。
5) 接口的安全性，如果是外部接口的话，这点尤为重要。
Web接口
web接口测试又可分为两类：服务器接口测试和外部接口测试。
服务器接口测试：是测试浏览器与服务器的接口。这个很容易理解，我们知道web开发一般分前端和后端，前端开发人员用html/css/javascript等技术。后端开发人用php/java/python/ruby等各种语言。用户输入的数据是输入到的前端页面上，怎样把这些数据传递的后台的呢？通过http协议的get与post请求来实现前后端的数据传递。这也可认为是接口测试，调用的登录接口还是查询接口，传参的是用户密码还是搜索关键字。
外部接口测试：这个很典型的例子就是第三方登录，比如你做的新系统免于新用户重新注册的麻烦会提供第三方登录，那用户在登录的时候调用的就是第三方登录的接口，由第三方验证用户名和密码并且返回给当前系统。
对于web接口测试来说有哪些测试要点：
• 1、请求是否正确，默认请求成功是200，如果请求错误也能返回404、500等。
• 2、检查返回数据的正确性与格式；json是一种非常创建的格式。
• 3、接口的安全性，一般web都不会暴露在网上任意被调用，需要做一些限制，比如鉴权或认证。
• 4、接口的性能，web接口同样注重性能，这直接影响用户的使用体验。如果我搜索一个关键字半天结果都没返回，果断弃用。
本文原文地址：https://www.cnblogs.com/royfans/articles/8761468.html