软件测试面试题（面试前准备篇）
目录
一、问题预测
1、让简单介绍下自己（每次面试开场）
2、让说下自己会的内容
3、看了哪些书籍（有问到）
4、了解过哪些技术博客/论坛（有问到）
5、是否了解软件测试需要掌握哪些知识（问到类似问题）
6、之前面试过，觉得自己需要补充哪些？做了哪些行动？
7、为什么做测试,觉得自己做测试有哪些优势？（有问到）
8、知道哪些Bug系统
9.测试用例的基本要素是?
二、介绍一下公司项目
三、技能方面
1、 数据库方面常识
2、 linux操作
3、缺陷方面（有问到）
4、用例部分
5、软件测试流程
6、网络相关
7、测试工具
8、其他概念问题
四、你还有什么想问的吗（必答）
五、简历模板
一、问题预测
让简单介绍下自己（这个不用说了每次面试开场）
你好，我叫马威，毕业于成都理工大学。目前有五年的软件测试经验。最近的一份工作是无敌勇士科技公司，主要参与app系统测试，负责Good Luck、LuckMoney等小游戏app的测试，有社交视频类如直播软件、主题壁纸类、刮卡观看激励视频类。主要运用边界值，等价类，错误推测等常见黑盒测试方法。测试过程中做过接口测试。
需求文档：
我们测试的流程大致是这样，首先是文档评审，
在系统开始开发之前，产品经理会根据收集到的用户意见和最终方案编写需求文档
编写完成后，要进行需求文档评审；
说是评审，实际上主要是需求讲解。
给开发们讲解业务知识、我们要做什么东西、为什么这么做、要做成什么样子。
知道产品最终的上线目标是什么，来判断什么时候能达到交付的程度。
凭借经验对需求文档中的部分设计提出不同的意见。
凭借经验对需求文档中没有涉及到的一些异常情况和特殊场景进行讨论。
开发文档：
需求文档定型之后，开发经理会根据需求文档来编写开发文档。
开发文档的内容大概包括：开发模型、代码架构、代码规范、接口规范、数据库设计......
为什么测试要参加开发文档的评审？（其实主要是去听）
测试人员需要了解系统的基本架构和实现原理，方便分析问题原因
测试人员需要了解数据库表结构，对后续的测试很有必要
测试人员可以提出一些规范性的要求，便于后面的测试。（比如要求前端人员尽量给所有前端组件加上id或name属性，方便自动化测试时定位元素）
测试人员可以发现代码中缺少对某些异常场景的逻辑判断。
测试计划
测试计划是测试人员的工作量预估，也是将来测试人工作考核绩效的重要依据。
测试计划的内容包括：测试范围是什么、分为哪些阶段、什么时间点完成什么、测试的具体内容列表（流程、功能、接口）、测试资源的成本（人/天）等等。
但是产品的诞生过程中，免不了出现各种各样的特殊情况，所以实际的测试可能会跟测试计划有所出入。
所以测试报告中需要写明与测试计划产生偏差的原因，并计算变差量，分析偏差的风险。
最终的测试过程和测试结果还是以 测试报告 为准。
单元测试
接口
集成测试
发布阶段
进入发布阶段就意味着产品已经通过了测试，可以发布到线上，交付给用户使用。那如何确认测试已经通过？在发布过程中，我们测试人员又需要完成哪些工作？
测试通过准则规范
上线前，需要确认测试已经通过，现在程序越来越复杂，如果没有量化的规范，就很难确定测试到什么时候可以上线。所以我们需要设定测试通过的准则，只有达到准则才能上线
测试需求功能覆盖率100%
测试用例通过率95%以上
遗留缺陷没有严重程度3级以及以上的缺陷
测试报告
完成测试后，提交测试报告，给出此次测试过程中的数据，例如：测试用例的数量，发现缺陷的总数，各个严重程度的缺陷数量，总共修复的缺陷数量以及缺陷修复率等等
系统回滚方案
每一次发布都不能说百分之百的没有问题，如果真的出现问题，我们该如何处理？
如果线上出现的问题不是很严重，尽量当时处理掉再上线
如果线上出现的问题很严重，就必须要系统回滚，保证线上用户的正常使用
系统回滚方案须跟开发/项目经理确认
线上功能检查
程序原有功能的回归测试
新上线的功能全面测试
小结：
每一次发布后，测试人员都应该持续反馈，改进、总结每个版本中遇到的问题，不管是缺陷还是流程问题，从一次次的问题中总结一些经验，提高整个软件生命周期的质量
日常维护阶段
产品上线后，用户能稳定的长期使用，就意味着发布的功能进入到日常维护阶段。而这里并不是终点，这个阶段将一直存在。
在这个阶段，测试人员的主要工作就比较简单
持续测试，没有产品是没有缺陷的
即使收集用户反馈的问题，并尽快组织人员修复
长时间稳定性测试（自动化测试）
让说下自己会的内容
我熟悉软件测试基础理论和测试流程，测试方法等，有app测试、web测试、接口测试经验。熟悉数据库增删改查操作，熟悉使用测试管理工具。
看了哪些书籍（有问到）
软件测试，软件测试的艺术、软件测试实用教程，在我负责短视频的推荐引擎测试期间看完了项亮的《推荐系统实战》主要是推荐系统的评测部分。
了解过哪些技术博客/论坛（有问到）
51testing论坛，CSDN一些博客（面试经验：面试中会问具体哪些博客），和公众号（搜狗测试、软件测试资源分享）
是否了解软件测试需要掌握哪些知识（有问到类似问题）
软件测试基础知识，流程，测试用例方法，数据库相关知识，抓包分析，接口测试、测试工具、性能测试等。
之前面试过，觉得自己需要补充哪些？做了哪些行动？
很多公司对性能测试和自动化测试工具有要求，由于之前的工作主要涉及的是功能测试，所以这方面的知识储备不够。不过最近我在学习这方面的知识，希望以后在工作中能深入学习。
为什么做测试,觉得自己做测试有哪些优势？（有问到）
我觉得我个人的性格比较适合做测试。我比较细心耐心，考虑事情比较全面，这样对于我在设计测试用例时很有帮助，而且我能够很好的与人协调沟通，当我们测试和开发发生沟通上的矛盾时我也能很好的解决，我平常喜欢刷微博、知乎看热门评论，喜欢考究大众心理，这有助于我站在用户角度设计测试点。
知道哪些Bug系统
禅道/bugzila等
9.测试用例的基本要素是?
版本号，功能模块，优先级别，前置条件，步骤，预期结果，实际结果等。
二、介绍一下公司项目
xxapp，是一款集短视频、游戏、直播、社交互动于一体的内容娱乐APP。公司大约一个月发布一个较大的版本，需求数20几个-40几个不等(用例数xx+)，每个版本包括的需求www\wap、后台以及客户端的需求。项目分客户端版本负责人、后台版本负责人、H5版本负责人等，负责人牵头及落实整个测试流程。我当过的角色有H5活动负责人、推荐引擎版本负责人、客户端和后台系统测试人员。负责过的模块用例数大概是500左右。
三、技能方面
1、数据库方面常识
l关系型数据库：把复杂的数据结构归结为简单的二元关系（即二维表格形式），通过SQL结构化查询语句存储数据
典型产品：
Mysql：互联网领域、大中小型网站，游戏公司，电商平台等等。体积小、速度快、成本低、开放源代码
Oracle：传统大企业、大公司、政府、金融、证券等。安全性、成本高、
l非关系型数据库：非关系型数据库也被成为NoSQL数据库，NOSQL的本意是“Not Olnly SQL”。NOSQL为了高性能、高并发而生
其他分类
1）键值（Key-Value）存储数据库：主要是使用一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。简单、易部署、高并发
典型：Redis、Memcached
2）列存储（Column-oriented）数据库：应对分布式存储的海量数据。如果我们有一个Person类，我们通常会一起查询他们的姓名和年龄，而不是薪资。这种情况下，姓名和年龄就会被放入一个列族中，而薪资则在另外一个列族中。
典型：Hbase
3）面向文档数据库：数据存储的最小单位是文档
典型：Mongodb、Hive
Mongodb一个介于关系型数据库和非关系型数据库之间的产品。高性能、易部署、易使用，存储数据非常方便。
Hive可以用来进行统计查询，HBase可以用来进行实时查询
一些增删改查笔试题准备
（另起一篇）
2、linux操作
linux搭建测试环境，比如web系统服务搭建。
一些常见命令准备
（另起一篇）
3、缺陷方面（有问到）
描述一个你印象最深刻的bug
在做上传视频的测试时，发现华为荣耀V10上传手机自带相机专业模式录制的视频会闪退。而ios上传同个视频提示合成失败。
我将手机自带相机录制的专业模式和普通模式录制的同样时长的视频发到电脑上，用格式工厂软件查看视频的不同之处，之后发现视频编码是不同的。
我继续网上查阅了视频编码方面的知识，发现mp4视频有几种编码，而继续测试验证发现我们的app上传的视频只支持mp4视频中的H.264编码格式。于是提交了视频上传不支持非H.264格式的视频。并补充完善了相关用例。
（因为在公司没有查日志权限，所以其实应该先查日志）
4、用例部分
现场让你设计个用例，比如水杯、凳子怎么测试？
首先说明的是，遇到这样的测试题目，首先应该反问面试官，需求是什么样的，比如是测什么样的杯子。
因为设计测试用例的规则应该是根据需求分析文档设计用例，客户需求什么，就测试什么。
但是在没有需求分析文档的前提下，来设计测试用例，可以考查一个测试人员的基本功，比如考虑问题是否全面，设计测试用例的方法是否合理等。
一般是根据自己的日常经验和测试的思维来设计测试用例。在设计测试用例时一般从以下几个方面进行分析：功能测试，性能测试，界面测试，安全性测试，兼容性测试，可用性测试，可靠性测试，本地化/国际化测试。
例子（另起一篇）
5、软件测试流程
公司严格规范测试流程和测试文档，首先是参与需求评审，编写测试计划、测试方案、测试用例，进行测试方案及用例的测试组内部评审，外部评审。
提取部分一级用例提交研发自测，研发自测通过后开开始执行一轮系统测试。
测试过程中发现并提交、跟踪问题。
问题修复后进行回归测试。
一轮测试完成后对修复包进行冒烟测试，测试通过则进行二轮测试。
二轮测试完成后会进行需求交叉测试。
完成测试编写系统测试报告提交验收测试。验收测试通过输出验收测试报告。
6、网络相关
网络协议，如TCP/UDP的区别？（https://www.cnblogs.com/steven520213/p/8005258.html）
1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
三次握手与四次挥手
三次握手通俗版：
第一次握手：客户端要和服务端进行通信，首先要告知服务端一声，遂发出一个SYN=1的连接请求信号,”服务端哥哥，我想给你说说话”。
第二次握手：当服务端接收到客户端的连接请求，此时要给客户端一个确认信息，”我知道了（ACK）,我这边已经准备好了，你现在能连吗（SYN）”。
第三次握手：当客户端收到了服务端的确认连接信息后，要礼貌的告知一下服务端，“好的，咱们开始联通吧（ACK）”。
到此整个建立连接的过程已经结束，接下来就是双方你一句我一句甚至同时交流传递信息的过程了。
四次挥手断开连接通俗版：
第一次挥手：双方交流的差不多了，此时客户端也已经结尾了，接下来要断开通信连接，所以告诉服务端“我说完了（FIN）”，此时自身形成等待结束连接的状态。
第二次挥手：服务端知道客户端已经没话说了，服务端此时还有两句话要给客户端说“我知道你说完了（ACK），我再说两句&*…%￥”…
第三次挥手：此时客户端洗耳恭听继续处于等待结束的状态，服务器端也说完了，自身此时处于等待关闭连接的状态，并对告诉客户端，“我说完了，咱们断了吧（FIN）”。
第四次挥手：客户端收知道服务端也说完了，也要告诉服务端一声（ACK），因为连接和断开要双方都按下关闭操作才能断开，客户端同时又为自己定义一个定时器，因为不知道刚才说的这句话能不能准确到达服务端（网络不稳定或者其他因素引起的网络原因）。
所以默认时间定为两个通信的最大时间之和，超出这个时间就默认服务器端已经接收到了自己的确认信息，此时客户端就关闭自身连接，服务器端一旦接收到客户端发来的确定通知就立刻关闭服务器端的连接。
到此为止双方整个通信过程就此终结。
这里要声明一下：断开链接不一定就是客户端，谁都可以先发起断开指令，另外客户端和服务端是没有固定标准的，谁先发起请求谁就是客户端。
三次握手阐述：
在第一次消息发送中，A随机选取一个序列号作为自己的初始序号发送给B；
第二次消息B使用ack对A的数据包进行确认，因为已经收到了序列号为x的数据包，准备接收序列号为x+1的包，所以ack=x+1，同时B告诉A自己的初始序列号，就是seq=y；
第三条消息A告诉B收到了B的确认消息并准备建立连接，A自己此条消息的序列号是x+1，所以seq=x+1，而ack=y+1是表示A正准备接收B序列号为y+1的数据包。
四次挥手阐述：
由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，
收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。
首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。
（1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
（2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
（3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
（4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
7、测试工具
测试工具，无非这几类：
自动化测试工具 (如QTP)
性能测试工具 (如loadrunner)
测试管理类 （如jira）
安全测试工具
渗透测试工具
8、其他概念问题
Beta测试与Alpha测试有什么区别
1、Alpha测试
Alpha测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。开发者坐在用户旁边，这是在开发者受控的环境下进行的测试。由开发者随时记录下错误情况和使用中的问题。
2、Beta测试
Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，这是在开发者无法控制的环境下进行的测试。由用户记录下遇到的所有问题，定期向开发者报告。beta测试是一模拟真实的使用环境从而发现缺陷的一种测试
3、验收测试
验收测试是以用户为主的测试，软件开发和QA人员也应该参加，测试一般在用户所在地进行，由用户验证软件产品是否满足了所有的需求的一系列的验收测试工作。
仅限于做项目的公司，部门内部测试稳定后，根据合同中需求由发包商进行验收测试。验收测试的目的是为了以发现”未实现的需求”为目的，以评估”适合使用”为目标，该类测试的不是以发现缺陷为主要目的。
区别：两者的主要区别是测试的场所不同。
Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。
而beta测试的环境是不受开发方控制的,谁也不知道用户如何折磨软件,用户数量相对比较多,时间不集中。
一般地,alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。如果产品通过了beta测试,那么就可以正式发行了。
Alpha测试在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。
Beta测试 当开发和测试根本完成时所做的测试，最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。
四、你还有什么想问的吗（必答）
我非常希望能够加入公司，所以想请问您觉得我还有哪些地方比较不足，能否给一些建议？以及是否有复试时间呢？