1.1面试题：在实际测试中如果出现不可复现的bug怎么办？
经过多次复现后，还是没有出现。此时在本地记录当前的问题
回顾当时操作的流程及测试环境的配置要求，确认是否由于操作失误或者环境临时故障引起
请开发协助（自己）查找当前测试模块是否有对应的日志信息（日志的位置可以问开发）
再考虑更换一套环境查看是否能够复现上述问题
在后续的版本中测试，此时需要关注当时测试该功能时是否还出现上述的问题
在后续版本还出现过，需要开发协助打印日志进行分析定位，同时测试需要提交bug
1.2面试题：你们公司有几套环境？
测试环境：测试人员使用
开发环境：开发人员使用
预生产环境：测试人员使用
生产环境：用户使用
注意：
情况一：两种环境，测试环境+生产环境，如何解决开发和测试进度冲突问题？
答：区分开发周和测试周，开发工作时（开发新功能）不测试，测试工作时，开发不进新代码。
情况二：3种环境，开发环境+测试环境+生产环境
1.3面试题：公司的测试流程？
1.需求评审？
前提： 评审之前阅读需求，记录疑问点。
评审的目的：
知道有什么功能，需求规划是什么
站在不同角度对需求进行查漏补缺
各部门对需求理解一致
2.计划编写？
谁来写？项目测试负责人来写
有几份？2份，项目总计划，个人执行计划
核心：
测什么（目标和范围）
谁来测（人员进度安排）
怎么测（测试策略、测试工具）
准入（提测标准） 什么时候开始测试
准出标准（上线标准） 什么时候结束测试
测试对象（文档、代码、数据）
3.测试设计
如何设计用例？
熟悉要求——设计测试点——编写测试用例
提示： 先设计业务用例，后设计单功能模块用例
4.用例执行
A.按优先级执行
前提：写用例的时候标注清楚优先级并且明确优先级的定义
P0：最高级别
B.顺序执行
5.缺陷管理
提交缺陷：用例执行失败时提交，确保 唯一性 ， 可复现 （优先性、状态、 版本号 ）
验证缺陷：验证后需要注明版本号，验证不通过需要Reopen
关闭缺陷：验证通过则关闭并注明版本号
1.4面试题：简述C/S模式和B/S模式的区别？
B/S的架构 b：Browser 浏览器 Serber 服务器 通过浏览器访问
APP架构是 C/S的架构 Client Server 需要安装APP
B/S的优点： 分布性强，客户端零维护。只要有网络、浏览器，可以随时随地进行查询、浏览等业务处理。 业务扩展简单方便，通过增加网页即可增加服务器功能。 维护简单方便，只需要改变网页，即可实现所有用户的同步更新。 开发简单，共享性强。
B/S的缺点： 个性化特点明显降低，无法实现具有个性化的功能要求。不过随着html5的普及，这个缺点越来越弱化了。 客户端服务器端的交互是请求-响应模式，通常动态刷新页面，响应速度明显降低（Ajax可以一定程度上解决这个问 题）。无法实现分页显示，给数据库访问造成较大的压力。
C/S的优点： 能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器，所以CS客户端响应速度快。 操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。 安全性能可以很容易保证，C/S一般面向相对固定的用户群，程序更加注重流程，它可以对权限进行多层次校验，提 供了更安全的存取模式，对信息安全的控制能力很强。一般高度机密的信息系统采用C/S结构适宜。
C/S的缺点： 需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群体，不能够实现快速部署安装和 配置。 兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新改写程序。开发、维护成本较高，需要具有一定专业水准的技术人员才能完成，发生一次升级，则所有客户端的程序都需要改 变。 用户群固定。由于程序需要安装才可使用，因此不适合面向一些不可知的用户，所以适用面窄，通常用于局域网中。
1.5什么是兼容性测试？兼容性测试侧重哪些方面？
考察对兼容性测试的了解和在工作中的应用。 **核心问题讲解**
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。 兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。 兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件 运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出 做兼容测试的兼容环境了。 **问题扩展** APP兼容性测试 **结合项目中使用**
一个Web系统是否成熟够强大，功能的兼容性的强弱是不容小觑的；我们的Web项目面向的都是大众用户群体，而用户所使用的浏览器都是五花八门，某个功能在A浏览器上显示正常操作Ok，但是在B浏览器上显示就乱糟糟的，严重的可能导致功能都异常，这样一来用户群体对项目系统的好感就大大的打了折扣，所以浏览器的兼容性测试我们得加大关注力度。 兼容性测试从哪些方面入手？
1）了解当前哪些浏览器是主流，挑选前面3-5个左右的浏览器进行兼容性测试（一般选3个左右就差不多了，项目时间允许的话可以做得更多）
2）同浏览器的不同版本也要进行兼容性测试（一般测试最新版本）
3）界面上元素功能是否正常、排版布局是否合理美观，这是兼容性最最最重要的测试范围 那么在不同浏览器中或者是同一浏览器不同版本里需要对那些界面功能进行兼容性测试？ 一眼可见的是网页元素位置是否混乱与错位业务与功能结合的异步交互功能按钮（增删改查、导入导出、超链接、清空）等等 各种控件的检查：日期和时间控件、搜索控件 有些特殊的图标功能比如：盘古系统上的画图功能是否正常（不覆盖区域图标、覆盖区域绘图、站点位置迁移图标、挪动地图坐标等等
兼容工具：test云测平台、三方付费工具
选取数据从何而来：
公共统计平台、产品有明确要求、用户反馈
1.6软件测试的结束标准是什么?
准入标准和准出标准需要跟项目团队同步
问题分析 对测试理论的了解和实际项目中的实际情况。
核心问题讲解
1）基于“测试阶段”的原则： 每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。
2）基于“测试用例”的原则： 测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。
3）基于“缺陷收敛趋势”的原则： 软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。
4）基于“缺陷修复率”的原则： 软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后面版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题，可以暂时不用修改。
5）基于“验收测试”的原则： 很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。
6）基于“覆盖率”的原则： 对于测试“覆盖率”的原则，个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求，包括行业隐性需求、功能需求和性能需求等等，只要测试用例执行的覆盖率达到100%，基本上测试就可以结束。
7）基于“项目计划”的原则：
大多数情况下，每个项目从开始就要编写开发和测试的Schedule，相应的在测试计划中也会对应每个里程碑，对测试进度和测试结束点做一个限制，一般来说都要和项目组成员（开发，管理，测试，市场，销售人员）达成共识，团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了，测试时间就相应缩短。
8）基于“缺陷度量”的原则： 这个原则也许大家用的不是很多，了解比较少。我们可以对已经发现的缺陷，运用常用的缺陷分析技术和缺陷分析工具，用图表统计出来，方便查阅，分时间段对缺陷进行度量。
9）基于“质量成本”的原则： 一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位，就要看是什么软件了。比如说是：人命关天的航天航空软件，那还是质量重要些，就算多花点钱、推迟一下进度，也要测试能保证较高质量以后才能终止测试，发布版本。如果是一般的常用软件，由于利益和市场的原因，哪怕有bug，也必须得先推出产品，没办法呀。一般来说，最主要的参考依据是：“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均 衡”。
10）基于“测试行业经验”的原则： 很多情况下，测试行业的一些经验，也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度，测试人员的工作能力，测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中，每个人都没有项目行业经验数据积累，拿到一个新的项目，自然是一头雾水，不知道从何处开始，测试质量自然不会很高。因此通过测试者的经验，对确认测试执行和结束点也会起到关键性的作用。 问题扩展 第一类标准：测试超过了预定时间，则停止测试。 第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。 第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础。 第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某 一预订 数目的故障。 第五类标准：根据单位时间内查出故障的数量决定是否停止测试。 结合项目中使用 无
1.7如果一个缺陷被提交后，开发人员认为不是问题，怎么处理？
1） 首先，将问题提交到缺陷管理库里面进行备案。
2） 然后，确认研发拒绝的原因. 要获取判断的依据和标准：
A）根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
B）如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
C）根据用户的一般使用习惯，来确认是否是缺陷；
D）与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
3） 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
4） 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
1.8你用过的http协议调试代理工具有哪些？请详细说明抓取https协议的设置过程?
（1）问题分析 考察对Fiddler的了解及抓包过程 （2）核心问题讲解
Fiddler是一个http协议调试代理工具安装证书; Tools--Options--HTTPs,配置允许抓取HTTPS连接和解析HTTPS流量然后选择要解释的来源,点击actions安装证书
1.9购物车数量从1件开始添加，一次加1，加到100件时，向服务器发送多少次求？
一般会有2种情况，下单时发送，或者数量改变时即刻发送。 如果下单时发送，那购物车里的数量改变只是本地做的修改，下单时再向服务器发送请求；在购物车里的请求则是0如果是即刻发送，则是99次。请求的次数和页面变化次数是一一对应的，每加一次，购物车内的数量、价格都在变化。 如果是即刻发送，但是不是点击按钮添加的，而是输入数字100增加的，那么请求次数为1次
2.0get和post的区别？
get的请求参数放在url中，post的请求参数放在请求体当中。get的参数放在url中，浏览器对url有长度限制，所以get的参数有大小的限制，而post是没有的。 一般用get来获取数据，用post来提交数据
2.1简述HTTP协议的状态码包含哪些?
2XX，表示成功3XX，表示重定向4XX，表示客户端错误5XX，表示服务器错误3.
2.2在HTTP和HTTPS的区别?
安全性上的区别:HTTPS：HTTP协议的安全加强版，通过在HTTP上建立加密层，对传输数据进行加密。主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。表现形式：HTTPS站点会在地址栏上显示一把小锁，表明这是加密过的安全网站，如果采用了全球认证的顶级EV SSL证书的话，其地址栏会以绿色高亮显示，方便用户辨认。技术层面：如果要说HTTPS和HTTP的区别，最关键的还是在技术层面。比如HTTP标准端口是80，而HTTPS标准端口是443；HTTP无需证书，HTTPS需要CA机构颁发的SSL证书；HTTP工作于应用层，HTTPS工作于传输层。
2.3项目共有多少张表？所做模块用到多少张表？表与表之间的关系？
答：180-220（选一个具体数值）。
商品模块：商品表，库存表，品牌表，分类表，商品详情表，规格表，图片表，商品排序表，商品筛选表，图片资源类型表，图片资源表，商品日志表，晒单图片说明表。
购物车：商品表，品牌表，分类表，库存表，用户表，库房表，购物车表，购物项表，优惠券表，商品推荐表。 订单：订单表，用户表，用户地址表，商品表，品牌表，分类表，库存表，库房表，地区表，物流信息表。
登录（后台）：用户表，权限 表，角色表，用户角色表，权限角色表，日志表。
2.4工作之余有没有在研究一些流行的技术？
答：有，再看一些技术博客。比如说会浏览CSDN、知乎，去看一些测试相关的技术。学习UI自动化。
2.5测试过程中遇到app出现crash或者ANR，你会怎么处理？
参考答案：可以先把日志记录下来， 方式一：adb logcat >路径\文件名.txt
方式二：（过滤） adb logcat | findstr xxxxx(过滤日志信息) >路径/文件名.txt ， 拿到日志后再搜索其中的关键字，比如：exception、crash（可以从研发处获取），看看是哪些方法或者异常导致了 问题的发送，初步定位问题原因后，可以交给开发人员去具体查找深层原因并修复。 工具：nodepad++、Android studio（研发用）
2.6你觉得app的性能测试，需要重点关注那些方面？
参考答案：app使用时对CPU、内存占用情况（结果怎么看）app使用时对电量、流量的消耗情况（什么场景消耗大）app启动时长（冷启动、热启动）app流畅度（帧率，值越大流畅度越好，值越小，流畅度越差）长时间使用稳定性（monkey）
2.7你觉得app的专项测试，需要重点关注那些方面？
安装卸载升级交叉测试（干扰测试、冲突测试）push推送
2.8易用性app测试和web测试有什么区别？
WEB测试和App测试从流程上来说，没有区别。 都需要经历测试计划方案，用例设计，测试执行，缺陷管理，测试报告等相关活动。
从技术上来说，WEB测试和APP测试其测试类型也基本相似，都需要进行功能测试、性能测试、安全性测试类型。 他们的主要区别在于具体测试的细节和方法有区别，比如：性能测试，在WEB测试只需要测试响应时间这个要素，在App测试中还需要考虑流量测试和耗电量测试。 兼容性测试：在WEB端是兼容浏览器，在App端兼容的是手机设备。而且相对应的兼容性测试工具也不相同，WEB因为是测试兼容浏览器，所以需要使用不同的浏览器进行兼容性测试（常见的是兼容IE6，IE8，chrome，firefox）如果是手机端，那么就需要兼容不同品牌，不同分辨率，不同android版本甚至不同操作系统的兼容。（常见的兼容方式是兼容市场占用率前N位的手机即可），有时候也可以使用到兼容性测试工具，但WEB兼容性工具多用IETester等工具，而App兼容性测试会使用Testin这样的商业工具也可以做测试。 安装测试：WEB测试基本上没有客户端层面的安装测试，但是App测试是存在客户端层面的安装测试，那么就具备相关的测试点。 还有，App测试基于手机设备，还有一些手机设备的专项测试。如交叉事件测试，操作类型测试，网络测试（弱网测试，网络切换） 交叉事件测试：就是在操作某个软件的时候，来电话、来短信，电量不足提示等外部事件。 操作类型测试：如横屏测试，手势测试 网络测试：包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。 从系统架构的层面，WEB测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是APP端是不能够保证完全一致的，除非用户更新客户端。如果是APP项目修改了服务器端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。还有升级测试：升级测试的提醒机制，升级取消是否会影响原有功能的使用，升级后用户数据是否被清除了。
2.6App测试中ios和Android有哪些区别呢？
1.多分辨率测试，Android端20多种，ios较少； 2.手机操作系统，Android较多，ios较少且不能降级，只能单向升级；新的ios系统中的资源库不能完全兼容低版本中的ios系统中的应用，低版本ios系统中的应用调用了新的资源库，会直接导致闪退（Crash）； 3.操作习惯（Android特有）：Android，Back键是否被重写，测试点击Back键后的反馈是否正确；应用数据从内存移动到SD卡后能否正常运行等； 5.push测试：Android：点击home键，程序后台运行时，此时接收到push，点击后唤醒应用，此时是否可以正确跳转；ios，点击home键关闭程序和屏幕锁屏的情况（红点的显示）； 6.安装卸载测试：Android的下载和安装的平台和工具和渠道比较多，ios主要有app store，iTools和testflight下载； 7.升级测试：可以被升级的必要条件：新旧版本具有相同的签名（证书）；新旧版本具有相同的包名；有一个标示符区分新旧版本（如版本号）， 对于Android若有内置的应用需检查升级之后内置文件是否匹配（如内置的输入法）
另外：对于测试还需要注意一下几点： 1.交叉测试：闹铃弹出框提示，另一个应用的启动、视频音频的播放，来电、用户正在输入等，语音、录音等的播放时强制其他正在播放的要暂停； 2.数据来源的测试：输入，选择、复制、语音输入，安装不同输入法输入等； 3.push（推送）测试：在开关机、待机状态下执行推送，消息显示及其推送跳转的正 确性； 应用在前台、未打开状态、应用启动且在后台运行的情况下时push显示和跳转否正确； 推送消息阅读前后数字的变化是否正确； 多条推送的合集的显示和跳转是否正确；4.分享跳转：分享后的文案是否正确；分享后跳转是否正确，显示的消息来源是否正确；5.触屏测试：同时触摸不同的位置或者同时进行不同操作，查看客户端的处理情况，是否会crash等
2.7app出现ANR，是什么原因导致的？
简单的总结有以下两点：1.主线程执行了耗时操作，比如数据库操作或网络编程 2.其他进程（就是其他程序）占用CPU导致本进程得不到CPU时间片，比如其他进程的频繁读写操作可能会导致这个问题。细分的话，导致ANR的原因有如下几点： 1.耗时的网络访问 2.大量的数据读写 3.数据库操作 4.硬件操作（比如camera)5.调用thread的join()方法、sleep()方法、wait()方法或者等待线程锁的时候 6.service binder的数量达到上限 7.systemserver中发生WatchDog ANR 8.service忙导致超时无响应 9.其他线程持有锁，导致主线程等待超时 10.其它线程终止或崩溃导致主线程一直等待。
2.8App出现crash原因有哪些？
App崩溃相关的几个因素：内存管理错误，程序逻辑错误，设备兼容，网络因素等，如下： 1.内存管理错误 ：可能是可用内存过低，app所需的内存超过设备的限制，app跑不起来导致App crash。 或是内存泄露，程序运行的时间越长，所占用的内存越大，最终用尽全部内存，导致整个系统崩溃。 亦或非授权的内存位置的使用也可能会导致Appcrash。2.程序逻辑错误： 数组越界、堆栈溢出、并发操作、逻辑错误。 例如：app新添加一个未经测试的新功能，调用了一个已释放的指针，运行的时候就会crash。数组越界：比如数组定义时有十个元素，a[0] -- a[9] 分别对应相应的元素，在程序中如果使用了a[10]那么就超出了原来的数组定义的范围，也就是数组越界（下标越界） 堆栈溢出：栈是一种线性表，是数据结构中的，有先进先出的特点，堆栈溢出就是超出了栈的存取范围，从而无法继续存储，导致溢出并发操作：一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理机上运行，但任一个时刻点上只有一个程序在处理机上运行3. 设备兼容：由于设备多样性，app在不同的设备上可能会有不同的表现。4.网络因素：可能是网速欠佳，无法达到app所需的快速响应时间，导致app crash。或者是不同网络的切换也可能会影响app的稳定性。
2.9你平常会看日志吗, 一般会出现哪些异常（Exception）?
考察是否看得懂java里面抛出的异常，Exception一般面试中java Exception（runtimeException ）是必会被问到的问题 app崩溃的常见原因应该也是这些了。常见的异 常列出四五种，是基本要求。常见的几种如下：NullPointerException - 空指针引用异常 ClassCastException - 类型强制转换异常。 IllegalArgumentException - 传递非法参数异常。 ArithmeticException - 算术运算异常 ArrayStoreException - 向数组中存放与声明类型不兼容对象异常 IndexOutOfBoundsException - 下标越界异常 NegativeArraySizeException - 创建一个大小为负数的数组错误异常 NumberFormatException - 数字格式异常 SecurityException - 安全异常 UnsupportedOperationException - 不支持的操作异常
3.0app对于不稳定偶然出现anr和crash时候你是怎么处理的？
参考答案：可以先把日志过滤出来： adb logcat | findstr xxxxx(过滤日志信息) ，然后再搜索其中的关键字，比如：exception、crash，看看是那些方法或者异常导致了问题的发送，初步定位问题原因后，可以交给开发人员去具体查找深层原因并修复
