自己面试总结的一些软件测试面试题，都是自己亲身经历过的面试遇到的问题，希望可以帮助到其他小伙伴！！
一、Web端测试和App端测试的区别
单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。 系统架构方面： web项目，一般都是b/s架构，基于浏览器的 app项目，则是c/s的，必须要有客户端，用户需要安装客户端。 web测试只要更新了服务器端，客户端就会同步会更新。App项目则需要客户端和服务器都更新。
性能方面: web页面主要会关注响应时间 而app则还需要关心流量、电量、CPU、GPU、Memory这些。 它们服务端的性能没区别，都是一台服务器。
兼容方面： web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容 app测试则要看分辨率，屏幕尺寸，还要看设备系统。 web测试是基于浏览器的所以不必考虑安装卸载。 而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件 此外APP还有一些专项测试：如网络、适配性。。。
APP测试特点
（除了按需求说明书外的功能测试之外还需要进行如下测试）
1： 适配性测试（也叫兼容性测试，不同的安卓版本，不同厂商，不同手机品牌）
2： 不同网络测试 （2G网络/3G网络/4G网络/WIFI网络）
3; 在线升级测试
4： 中断测试（电话、短中消息打扰）
5： 耗电量测试
6： 弱网测试（信号差，信号屏蔽实验室）
7： 安装卸载 （C/S）
8: 流量测试
二、在项目中遇到哪些困难，是如何解决的，你在这个过程中做了什么
1. 提测质量差
问题描述：第一个提测版本差，有些均未通过冒烟测试
问题分析
A. 版本提测质量差，但基于发布时间已在，因此，在提测差时就开始测试
提测质量差的点：- 基于上每项功能的完成度都不高 - 有些功能均未实现 -
B. 新的团队，团队处于磨合期
C. 在提测时，对提测要求不明确，在时间点到后，匆忙提测
解决方式：
明确版本提测要求，并且开发得到了足够的时间。
2. 版本控制
问题描述：
最初阶段，每天出一个版本，基于新版本测试，记录每个版本上测试的功能。版本过于频繁，质量把控不好
问题分析：
A. 基于版本提测质量差，而且每天出一个版本，差上加差，
B. 虽然记录每个版本上测试的功能，但仍然无法把控当前版本的质量状况。
解决方式：暂停每天发布一个版本
前期：将全功能版本作为下一个版本发布目标，但由于一些功能并没有完成，因而，全功能版本分成了好几个阶段
后期：以测试一轮周期，发布最新版本
3. 功能反复
问题描述：在上一个版本是OK的功能，在新版本中功能失常
功能反复分两点：一是大功能反复，二是小功能（如：某个bug）反复
问题分析：
大功能反复：情况主要发生成项目前期和中期
A. 功能未完成，在完善功能时，未考虑到与该功能相关的点
B. 在提测之后，发现一些问题，导致了整个模块重构，重构后导致了问题的反复
小功能反复：这个情况主要发生在项目中后期
A. 因为项目里的部分开发是外援的，在项目中期时，撤出了团队，新接手的人员，对代码不熟悉，在修改bug时，经常出来顾此失彼
B. 开发小一在修改代码时，动到了小二的代码，导致了小二出了问题
解决方式：
对大功能反复，是这么处理：冒烟测试由开发来完成，冒烟通过后，再交由测试
对小功能反复，没有有效的处理方式，测试这边可以做的是，加强测试，这个问题，在发布前夕好了很多，但问题仍然存在
4. 需求不明确，前后不一致
问题描述：需求不明确，特别在一些边界，各端统一上
问题分析：
A. 交互文档经历6任交互，最后一任交互只参与两个模块的定义，现任交互对于以往交互了解不够深入
B. 产品提测时，交互验证不足
解决方式：
由于项目已提测，因此在整个周期里，对于交互需求方面的疑问直接找相关人员去确认。
在后期的小版本中，我们把这类问题尽量控制在提测之前（详见小版本里的改进与问题）
5. 测试和开发信息不对称
问题描述：测试获取到的消息，与产品实现的方式不一致，如：有的功能定义了，但产品并未实现或实现方式与定义不一致
问题分析：
A. 在开发阶段，测试并未参与讨论需求，还在其他项目里
B. 需求重新确认后，没有及时通知测试
解决方式：
强调消息需要通知到测试，现在阶段，如果因这种类型而引起的问题，将建ticket，指派给相关人员
小版本里的改进与问题
现存在问题：
1. 现对Release版本会做RC checklist, 进行最后版本的质量控制，
但会存在一些问题，在小版本提测时，就已经存在，而冒烟测试是测不到的，在最后做checklist时，才发现
改进点：
1. 需求疑问在提测之前尽量提出，并且通知到开发，在开发阶段便把该问题解决
测试在开发阶段跟踪产品进度
在写测试用例时，就把问题抛出。
2. 提测流程：
对功能方面的ticket，交互在提测之前便在开发机器上验证，通过后再提测
把不符合交互预期的问题，在提测之前更改，节约了时间，避免问题在提测后才提出
另外一些测试过程中遇到的问题和沟通方式
从一开始，测试就要关注需求。
往往在讨论设计时，开发和需求很容易忽略了测试成员，他们潜意识里觉得这不关测试什么事。可是，测试也要熟悉业务，熟悉功能，熟悉各种设计，而且测试需要站在用户的角度来去考量他们的设计是否有不合理的地方，并提出自己的建议。这些工作，测试成员需要主动，积极参加，多提建设性意见，这样可能会让开发慢慢发现测试成员的重要性。其次，沟通最频繁应该还是关于bug的讨论。下面列出几个遇到的沟通问题，及我的解决办法。
1、这个bug我这边重现不了
解决办法
Bug应该简明扼要，重点突出。
如果描述存在歧义，一定要总结并尽快改进。有时会遇到概率性的bug，要告诉开发概率是多少，尽可能多的提供重现的条件。 在复现问题时，希望能大致判断几个问题点，然后和测试人员沟通下，需要如何捕获信息，捕获那类信息？是不是提供debug版本进行复现，或者根据预判的点增加打印信息版本进行复现？
2、这个不是代码问题，需求这么定义的
解决办法
需求也是人定的，如果觉得有异议，
可以找需求人员询问清楚，为什么这样定义，把自己的想法告诉他们，看他们怎么决定。如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。但是我们可以保留交流的记录，证明曾经在这里发生过歧义。
3、这块是别人负责的，我负责的部分没有问题
解决办法
如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。
4、有问题吗？（也就是开发不认为这是个问题）
解决办法
测试人员一定比开发要敏感，对bug
的容忍度也要低一些。特别是一些不符合用户习惯的bug
，开发总觉得无大碍。比如，一个列表默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调节。开发觉得问题很小，不影响功能，而且也有解决办法，所以不认为是bug。这个时候，就要发挥测试的本事了，嘴甜一点，说说好话，态度柔和一些。因为既然是小问题，解决起来一定不难，耐心地催开发的改过来就好。催一次不行催两次，记住态度一定要好。
5、用户不会像你这样操作的！
解决办法
用户怎么操作，谁都预料不到。我们不可能覆盖所有可能性，但是大多数用户会出现的操作，
我们当然要测试。慢慢地把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是要满足用户需求的。如果最后还是没能说服他，第一向上级反映，第二做好沟通的记录，将来备份在测试报告里。总结起来，测试在工作上要主动询问，态度上不能轻易妥协，习惯上要善于记录细节，方法上软硬兼施
三、 说一下你们的测试流程（必问）
没有做过项目的直接介绍下v模型（老师上课肯定有讲过），有经验的直接从接到项目/单子后讲自己如何一步步实施测试的。
例如你可以回答这样的流程：
1.软件开发完成以后，就会把需求规格说明书、软件程序和软件源代码发过来；
2.项目经理出测试方案（要使用什么样的测试方法、测试策略）安排测试计划（测试人员、资源、进度的安排，测试的范围和完成的目标）；
3.测试人员编写和执行测试用例；
4.提交缺陷并且进行跟踪；
5.编写测试报告。
四、你平时会写测试用例吗？
其实这是一个很经典的面试问题，留心的朋友会发现，基本上很多公司都有这样的问题。遇到这种问题最关键的不要怕，说话的时候有条有理，阐述的时候面面俱到的就好了，最重要的一定要稳。
例如：给你一个杯子如何测试？
界面测试：查看杯子的外观是否得体。（外形、图案）、
易用性：杯子是否烫手、是否有防滑措施、是否方便饮水、是否易用手端着或手拿。
安全性：使用过程中杯口是否容易给身体造成伤害，，杯子有没有毒和细菌。
可靠性：杯子从不同高度掉下的损坏程度。
稳定性：杯子一直盛着水，时间长了是否会漏水。
兼容性：是否可容纳高温度水、果汁、酒精、汽油等。
用户文档：用户使用手册上是否有对杯子的使用方法进行限制，是否出现使用过程中友好的提示、该注意的问题、使用环境等有详细的描述。
五、 哪些信息应包含在给开发的缺陷或错误报告中？
1、缺陷的简要总结
2、完整描述缺陷，包括重现步骤
3、如果需要，可以截取附件
4、发现和提出缺陷的日期
5、谁报告了这个缺陷
6、缺陷的严重性和/或优先级
7、哪个组件是指定的缺陷
六、软件测试方法有哪些分类？各有什么特点？设计测试用例的主要方法有哪些？
软件测试方法分类 1）白盒、黑盒、灰盒 2）单元测试、集成测试、系统测试、验收测试、回归测试、Alpha 测试、Beta 测试 3）静态测试和动态测试 设计测试用例的主要方法 1）等价类划分 2）边界值分析法 3）因果图法 4）场景法 2.系统测试是什么？需要考虑哪些方面？ 1）系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案.。 2）它的的任务是尽可能彻底地检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统”做得怎样？”。这阶段又可分为三个步骤：模块测试，测试每个模块的程序是否有错误；组装测试，测试模块之间的接口是否正确；确认测试，测试整个软件系统是否满足用户功能和性能的要求。该阶段结束应交付测试报告，说明测试数据的选择，测试用例以及测试结果是否符合预期结果。 3）测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。 4）系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。 系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试