1、你负责A项目，别人负责B项目，A项目5点钟会上线新功能，在2点的时候，发现A项目的上线会影响B项目，B项目的人临时被调走，没有办法进行协助，这时该怎么做？

此问题，考察候选人的向上反馈意识，及对突发事件的应变和协调工作的能力。

回答参考：

1、提前3小时发现问题，应及时向上级反映，做出应对方案，请求上级给与指示；

2、向上级申请B项目人员进行突发事件处理，确保A项目的发布顺利进行；

3、评估A项目的上线对B项目的影响是否过大。征求上级意见，进行下一步补救；

4、向上级报备备选方案，如影响较大，延迟A项目上线时间，确保A项目与B项目正常运行与上线是否可行。

2、如果你正在测试一个电商APP，从APP中选择了两个产品，一个全价，一个打折，并且都添加到购物车中，在购物车中成功支付，之后去已购买产品的列表中查看时，发现只有全价产品，没有打折商品。此时你应当如何分析和定位该问题？

此问题考察候选人分析问题定位问题能力，需分多钟情况进行测试。

1、分析单个的打折产品、全价产品购买后，是否有购买记录，需分别进行两种产品的单独购买

2、将题目中的场景再现一次，确定是否是偶发现象（此时分两种情况，若打折产品出现了，则题目中有可能是偶发现象，需按照偶发问题处理方法来解决；若打折产品不出现，此时需通过抓包确定是前端还是后端问题）

3、购买多个打折产品，查看是否有购买记录，排除系统对于打折产品没有单独处理的情况

4、特殊情况：如手机兼容性，网络情况，打折产品库存不足等。

1、APP测试和web测试区别

答：App测试与Web测试从功能测试和整体流程角度来讲，几乎没有什么区别，都是点点点的测试。Web测试，包含了UI测试、链接测试、搜索测试、表单测试、输入域测试、数据交互、兼容性测试、安全性测试、性能测试等等很多方面。而App测试，是基于客户端进行测试，测试人员的手机型号不同、版本不同、测试环境不同，涉及到的兼容性问题会有很多。

系统架构：Web测试一般是B/S架构，只要更新了服务器端，客户端就会同步更新。而且客户端能保证每位用户的客户端完全一致。但是App端一般是C/S架构，除非用户更新客户端，否则无法保证软件在各人手机中的一致性。如果在App下修改了服务端，就意味着又需要进行回归测试。

性能测试：Web测试比较关注网页的响应时间，而App除了关注在流畅网络下的响应时间，还需要关心流量、电量、CPU、GPU、Memory等等因素。

兼容性测试：Web端的测试更倾向于浏览器、电脑硬件配置以及电脑系统方向的兼容，不过一般还是以主流的浏览器为主。而App的测试则必须依赖移动端的设备：手机、平板等，不仅要看设备型号，还要看设备系统：Android和iOS。

App专项测试：异常场景的考虑以及弱网测试。比如：中断，来电，短信，关机，重启等。而弱网测试是App测试中必须执行的一项测试。包括弱网和网络切换，需要测试弱网时的用户体验问题，提示语和等待页面的设置，回退和刷新是否会造成二次提交，以及延时的处理机制等。     针对App产品性质的测试内容，绝大多数用户使用的都是触屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，功能触发区域等测试。

Web测试是针对浏览器，无需考虑安装卸载问题。而App是客户端，需要测试安装卸载和更新的情况。除了常规的操作还要考虑到异常场景。比如说：安装时的中断、弱网、安装后删除文件，强制更新与非强制更新、断点续传、弱网，卸载后删除App相关的文件等等。

2、什么是HTTP请求，HTTP请求方式有哪些

答：HTTP，即超文本传输协议，是HyperText Transfer Protocol的缩写。浏览网页时在浏览器地址栏中输入的URL前面都是以"http://"开始的。HTTP定义了信息如何被格式化、如何被传输，以及在各种命令下服务器和浏览器所采取的响应。HTTP请求方式：GET、POST、PUT、HEAD、DELETE、OPTIONS、TRACE、CONNECT

3、Post请求与get请求的区别

答：GET----获取资源 GET方法一般用来从服务器上获取资源的方法。服务器端接到GET请求后，就会明白客户端是要从服务器端获取相应的资源，然后就会根据请求报文中相应的参数，将需要的资源返回给客户端。使用GET方式的请求，传输的参数是拼接在URI上的。

POST----数据提交 POST方法一般用于表单提交，将客户端的数据塞到请求体中发送给服务器端。

get 和 post区别：

get请求无消息体，只能携带少量数据；post请求有消息体，可以携带大量数据；

get请求将数据放在url地址中；post请求将数据放在消息体中

GET请求请提交的数据放置在HTTP请求协议头中，而POST提交的数据则放在实体数据中；GET方式提交的数据最多只能有1024字节，而POST则没有此限制。

5、常用的测试用例设计方法

  答：等价类划分法：等价类划分主要适用于单个输入条件，输入为数值型的情况，如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类；如果输入只规定了输入范围，可划分出一个有效等价类，一个无效等价类。有效等价类：有意义的合理的正确输入；无效等价类：非法的错误的异常的输入；

边界值分析法：边界值方法也是适用于单个输入条件的情况，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。相关术语：上点：边界上的点叫做上点；离点：离边界最近的点叫做离点（如果是闭区间，离点落在边界外；如果是开区间，离点落在边界内）内点：边界内任意一个点叫做内点

因果图法：如果输入之间有关系，我们在测试时必须考虑输入条件的各种组合，那么可以考虑使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。优点：因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

错误推测法：错误推测法主要是测试设计人员的测试经验相关，测试经验不同，设计出来的测试用例也区别很大。

判定表驱动法：判定表适合于解决多个逻辑条件的组合。将各种逻辑的组合罗列出来，避免遗漏。不能表达重复的操作。判定表包括条件桩、条件项、动作桩、动作项。

正交法：当输入条件很多时，因果图等设计方法设计出来的用例数往往多的惊人，用正交法可有效减少用例数。正交法的核心思想是从大量测试数据中选取有代表性的点来测试，从而减少测试用例数。

功能图法：功能图法适合于用来设计程序的控制结构的测试用例。有顺序、选择、重复三种控制结构。

场景法：场景法特别适用于控制流清晰的系统。测试过程中可以针对不同的场景设计测试用例。

6、常用工具的使用，postman，jmeter，Fiddler

（此处常用工具的使用是检查一名测试人员基本技能的基础，也是项目组最为关注的点，这里只简单介绍操作步骤，候选人若能答出流程即可）

Postman：postman是一个开源的接口测试工具，无论是做单个接口的测试还是整套测试脚本的拨测都非常方便。

1）get请求：Get请求是最简单的请求方式，输入URL就能完成。

　　第一步：新建一个tab页面

　　第二步：输入URL ,选择请求方式为GET

　　第三步：点击“send”按钮

　　第四步：查看返回码是否异常。

2）post请求： Post请求跟Get的区别除了请求方式不同之外，还需要添加请求体，请求体内容多半为Json格式。

　　第一步：新建一个tab页面

　　第二步：输入URL ,选择请求方式为POST

　　第三步：输入请求体内容

　　第四步：点击“send”按钮

第五步：查看返回码，返回信息等

3）带cookie的请求： 该请求需要在Heards里面添加Cookie

　　第一步：新建一个tab页面

　　第二步：输入URL ,选择请求方式为POST

　　第三步：输入请求体内容

　　第四步：在Heard里面添加Cookie信息

　　第五步：点击“send”按钮

第六步：查看返回码，返回信息等

4）带Header的请求：该请求需要在Heards里面添加Cookie。

　　第一步：新建一个tab页面

　　第二步：输入URL ,选择请求方式为POST

　　第三步：输入请求体内容

　　第四步：在Heard里面对应的内容

　　第五步：点击“send”按钮

第六步：查看返回码，返回信息等

5）文件上传的请求：发送请求前需要先上传文件。

　　第一步：新建一个tab页面

　　第二步：输入URL ,选择请求方式为POST

　　第三步：输入请求体内容，文件内容选择file, 选择本地的文件上传

　　第四步：点击“send”按钮

第五步：查看返回码，返回信息等

Jmeter：Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器， 等等。

操作步骤如下：

首先，添加线程组，单击右键->添加->Threads(Users)->线程组

右键“线程组” -> “添加” -> “取样器” -> “HTTP请求”, 输入“服务器名称或IP”，对应的端口号，http默认端口号80，可以不写。

以下请求为POST, 所有“方法”那选择“POST”，输入对应的路径，添加参数及值。

右键“线程组” -> “添加” -> “监听器” -> “察看结果数”, 添加“察看结果数”，以察看运行后的结果，如图所示。

数据补充完整后可点击菜单栏目中“启动”按钮以启动测试，如图所示。

运行结束后可在结果树中查看返回结果

简单来说，jmeter操作过程就是：

1、新建一个线程组

2、输入HTTP请求

3、设置一个或者多个断言，增加监听器

4、运行后查看结果树

Linux常用命令举例：（红色字体为输入内容）

   答：cd ..返回上一级目录；cd ../..返回上两级目录；ls查看目录中的文件；ls -F查看目录中的文件；ls -l显示文件和目录的详细资料；ls -a显示隐藏文件；tree 显示文件和目录由根目录开始的树形结构(1)；lstree显示文件和目录由根目录开始的树形结构(2)；mkdir dir1创建一个叫做'dir1' 的目录'；mkdir dir1 dir2同时创建两个目录；find / -user user1搜索属于用户'user1' 的文件和目录；mv dir1 new_dir重命名/移动 一个目录

数据库常用SQL语句：

答：以常见的增、删、改、查为例：

增：插入指定列：insert into 表名(列1,列2,...,列n) values(值1,值2,...,值n);

插入所有列：insert into 表名 values(值1,值2,...,值n);

一次插入多行：insert into 表名 values

(值1,值2,...,值n),

(值1,值2,...,值n),

...

(值1,值2,...,值n);

2）删：delete from 表名 [where 条件]

3）改：update 表名 set 列1=新值1,列2=新值2,...,列n=新值n [where 条件];

4）查：查询部分列：select 列1,列2,...,列n from 表名 [where 条件];

查询所有列：select * from from 表名 [where 条件];

测试过程中遇到一个bug,开发不认为是bug如何解决？

     答：该问题是面试时常见问题，没有固定答案，但是该问题能够反映出测试人员在发现问题后，如何解决问题的能力，能够体现出候选人的主动解决问题的能力和思路，作为一名测试人员，发现并主动解决问题最为关键，这里列出几点，便于HR参考：

首先分析下到底会有哪些原因会导致开发不修改bug：

1、开发与测试对bug的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。

2、工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急，来不及修改、开发不关注名下的bug、开发认为目前的实现比产品需求好等情况

3、当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因

4、另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等

我们逐条分析并列出简单的解决方案：

针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点：

从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性。

可以和开发人员列举一个之前的类似问题，为开发提供参考。

产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。

上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改。

修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案。

第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题。

bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。

[测试用例设计题：

回答此处问题时，结合APP测试的特点进行回答，针对APP测试专项测试如：手机操作系统iOS、安卓、兼容性、后台应用、通知、短信提醒、弱网、消息提醒等用例此处不做重复介绍，详细请见问题一，但是候选人在回答问题时需要答出，下面详细介绍点赞功能。

微信朋友圈点赞功能

功能类：1、首先检查朋友圈可见权限设置，针对不同的权限、好友关系设置哪些好友可见

2、设置单个好友可见时，发送一条朋友圈，对方好友是否可见；

3、可见之后是否有可展开的操作栏（其中包括点赞和评论）；

4、多次点击后操作栏是否能够重复展开或退回

5、点赞功能：UI检查，是否有点赞图标，点赞提示，评论图标，评论提示

6、点击点赞图标后，图标是否有点赞成功提示；

7、点赞成功后点赞提示是否变为取消点赞；

8、点赞成功后是否在该条朋友圈下有点赞人姓名及图标；

9、点赞成功后，是否在被点赞人朋友圈处出现被点赞数统计提示；

10、被点赞人点击被点赞的提示后，页面是否跳转至被点赞朋友圈处，并显示已点赞的好友图标；

11、设置多个好友可见时，重复点赞步骤后，被点赞人查看个人朋友圈，是否能够展示所有点赞人的图标，统计数量；

12、若多个好友同时点赞，被点赞人收到赞时页面展示是否按照点赞时顺序排序；

13、多个人同时点赞时，顺序如何排序。

14、若其余几位点赞人之间不互为好友关系，是否能够看到对方点赞情况。

15、若有个别人员是好友关系，能否通过点赞的头像进入对方信息；

16、点赞之后该条赞能否一直保持

17、若该条朋友圈被删除，点赞的讯息是否也被删除

18、取消点赞，只能对已点赞的朋友圈进行取消点赞；

19、在已点赞的朋友圈下点击操作栏，是否弹出取消点赞的图表及提示

20、点击取消后是否提示已取消点赞；

21、取消的点赞后是否可以再次点赞；

22、取消点赞后是否会通知被点赞人；

23、设置朋友圈可见限制，当被点赞人收获很多赞之后，关闭朋友圈可见，那么被点赞人是否能够看到自己收获点赞统计，其点赞好友是否能够看到已点赞的信息；

（以上用例仅为参考，若有不足之处可以增加补充，完善用例）

场景问题解决：

如果在购物平台上选购了物品，并且成功支付，但在“我的订单”中没有查到该笔订单，此时怎么处理？

（该问题旨在考察候选人在面临场景问题时的处理问题能力，并且如何准确定位问题，解决问题的思路，答案不固定）

答：测试人员发现问题后，先确认该问题是否满足需求，若在需求要求下，则：

1.重现问题：如果是测试环境，可以再做一笔订单，详细记录该笔订单讯息，检查该问题是否为偶发性问题，此处分两种情况：

1、若该笔订单能够查到，则需判断，没有找到订单的那笔有可能是偶发现象，需明确记录；

2、若该笔订单还是无法找到，则需确定是前端还是后端问题。

排查问题：若为web类测试，通过开发者工具查看界面返回结果，若“我的订单”中有返回值，但在页面中没有展示，需找前端同事确认是否是做数据处理时没有展示结果；若“我的订单”中没有返回值，有可能是数据没有传给前端，需确认是否是接口没有返回或数据传输丢失。此时可以通过检查数据库对应表格、或者用抓包工具检查接口是否报错。若为APP类测试，通过抓包工具检查接口返回，同时检查数据库中对应表，是否有存储该笔数据。

3、确认是前端或后端问题后，可以截图发送给对应同事确认问题，并将该问题提交至缺陷管理工具中，并及时跟踪问题。若问题较严重并短期内无法解决，需及时与负责人，项目经理联系，及时汇报该问题。

4、若该问题为偶发问题，需记录该笔订单详细情况，并在后期测试中重点关注，若经过几个迭代后该问题没有再次出现，则可降低该问题等级，但仍需留意。