2022年最新软件测试面试题+答案解析（每日20题，持续更新中）【一】

前言

好久不见，甚是想念。各位朋友们，我又携带着最受大家欢迎的面试题回来了，可能会有朋友要问了：哎呀，你咋不更了，这不是上次那一份资料用完了嘛，这不，我又厚着脸皮去问我们公司的主管：Boss，给我份面试题呗。Boss瞥了我一眼，冷笑了一下就不做声了，最终在我答应带他上白银，他才拿了这份资料给我٩(๑❛ᴗ❛๑)۶老规矩：一天20题，喜欢的朋友点个关注就不会错过我的更新了，关注我，带你装*，带你飞。

文末有福利！！！

一、工作中印象深刻的 BUG

我们换位思考一下，面试官问这个问题的目的是什么？
其实，它并不关心你描述的这个bug是否真的有价值，或有多曲折离奇？他只是：
了解你平时工作中的测试能力
所以，这就要求的你平时工作中遇到bug时试着自己去定位，定位bug的过程远比你的单纯的执行测试用例有“价值”（自我技能提高的价值），在定位bug的过程中你需要掌握和运用更多知识。
另外，建议你平时养成总结的好习惯，发现的bug，开发解决了，最好问问他原因以及解决的方法，这样再遇到类似问题时，自己也可以试着定位解决。遇到难解决的bug，也可以把最终的解决过程记录下来。（这不是就有素材了）

举几个例子：
(1)有的用户在系统成功上传文档之后，点击文档的名称没法进行预览。后面是开发做了优化，发布后用户才能使用了。（这个bug是我第一次真正意识到兼容性测试的重要性，也增加了我对兼容性测试的认识）
(2)我遇到的一个就是：
需求：做一排单选功能，能实现单选的功能
开发：做的是点击单选按钮，能选中该内容
测试：也是这么测的

上线后，领导说难用，很难点中那个小圆点。
原因：只实现了选中单选小圆圈，并且圆点点很小，有选中的作用，没有做成点击该行，即可选中。这个问题貌似大家都实现了需求，却没有很好的考虑易用性。

二、怎么设计功能测试用例

1、显式功能性需求
对于显式功能性需求我们最长用到的方案主要有三种：

• 等价类划分法
• 边界值分析法
• 错误推断法

1.1、 等价类划分法
我们如果想测试一个功能的最傻的办法就是穷举。比如说一个密码验证功能，我们把所有的可能的密码都尝试一遍，自然就可以覆盖掉到所有的问题与可能。但是这种穷举的方法明显是做不到的。因此我们要用到等价类划分法。
等价类划分法就是说我们将所有可能的输入数据或操作分为多组不同的子集，每个子集中的数据与操作对发现程序中的潜在错误都有同等的效应。这样我们就将一个子集称为一个等价类。比如输入各种与用户名不相符的密码，是一个等价类；输入各种不存在的用户名是另一组等价类。这样在测试的时候，我们只要在每个等价类中选择一个典型操作，就可以达到较好的测试覆盖度。
等价类还会分为有效等价类和无效等价类两种。有效等价类指的是合理的、有意义的输入，主要用来验证功能是否实现了某个功能。无效等价类与有效等价类相反，指的是无意义的，超过软件规格的，不合理的输入，主要用来测试功能的健壮性，看是否考虑了如何处理不合理的情况。

1.2、边界值分析法
在我们在测试合理与不合理的数据的时候，往往最容易出现问题的就是合理与不合理的边界，这时我们就需要使用边界值分析法了。边界值分析法，就是对恰好大于、小于和等于边界的值进行测试，来验证程序是否做到了合适的处理。边界值分析法一般是作为等价类的补充，来加强测试功能实现的程度与健壮性保障的程度，是否符合规格。

1.3 错误推测法
在测试的时候就算我们使用了等价类划分法和边界值分析法，也很可能会遗漏一些需求中没有清晰提出，技术上比较隐蔽的错误。这种错误就需要测试人员通过已有的经验、对功能实现可能的方法的理解或直觉，来推测出软件中可能存在的各种错误与场景，然后编写测试用例来进行验证，这就叫做错误推测法。比如，登录超时后，某个需要权限操作的功能在使用的时候，是否跳到了登录页，还是直接报错，甚至说依旧可以操作。这种错误是需要测试人员一定的经验、技术积累与直觉的。
虽然说功能性测试往往是黑盒测试，但是如果测试工程师对于功能的实现有一定的理解——比如说是否用了缓存、是否使用了消息队列、是否某个地方会消耗极大的性能等等——将会更容易的推断出哪些地方会产生错误。

2、非功能性需求
在测试工程师测试完显示功能需求之后，还要考虑到系统的非功能性需求。这种需求可能在文档中有明确提到，也可能并没有明确的提出。但是我们的测试工程师在测试的时候却必须要关注到。

2.1 兼容性测试
兼容性指的是开发的软件是否在各种平台都可以使用。比如我们开发一个网站，我们的用户可能会用到各种不同的浏览器访问我们的网站。这样我们在测试的时候，就不能只考虑到某一种浏览器。我们需要考虑到多种浏览器的兼容性。
兼容性测试可能会涉及到：
不同厂商的浏览器及相同厂商不同版本的浏览器。
不同的设备终端及操作系统
不同的屏幕分辨率
不同的用户软件环境（比如是否禁用了cookie、是否可以连接外网等）

2.2 安全性测试
我们的测试人员还需要关注到开发软件的安全性。这涉及到：
用户隐私信息是否加密
需要权限的资源是否有没有权限也可以被拿到的风险
会不会受到跨站脚本的攻击
会不会受到sql注入攻击
等等

2.3 压力测试
测试人员也需要考虑的软件是否能够承载其需求所需的压力，例如：
软件是否能在合理的时间内响应用户行为
软件是否可能承载足够的请求
软件在处理大数据量时会不会产生资源锁死
等等

三、怎么设计接口测试用例

主要从四个方面来设计接口用例：功能，业务逻辑，异常，安全；
　　一、功能：
　　1）功能是否正常；
　　2）功能是否按照接口文档实现
举例：比如博客园添加随笔，需要登录才能添加。也就是业务要求不支持游客添加随笔功能，如果设计一个没有登录的用户，然后去测试添加随笔接口，结果接口能添加到随笔，说明功能不正常，不符合需求和接口文档描述。
　　二、业务逻辑：是否依赖业务；
举例：该接口调用之前，需要调用登录接口，如果不登录也能请求数据，不符合业务逻辑。
　　三、异常：参数异常和数据异常
　　1）参数异常：关键字参数，参数为空，多，少参数，错误参数
　　2）数据异常：关键字数据，数据为空，长度不一致，错误数据
举例：不管数据异常还是参数异常，测试点差不多，一个参数有key和value，key表示参数，value表示数据。第一，看看参数和数据能不能支持关键字，例如Java中的保留关键字等等。第二个就是参数和数据都为空，看看是否做了判断。第三个，参数多和少，例如有两个参数的接口，你需要设计一个三个参数的用例，一个只有一个参数的用例。数据那边长度不一致，例如设计很长的字符串是否支持，因为数据库创建表过程都设置好了每个字段的长度。输入错误的参数和数据，例如故意输出单词等等。
　　四、安全测试用例设计：
　　1)cookie：有cookie才能获取数据，如果不带cookie还有信息返回，说明有问题
　　2)header：正常接口带header信息，删除header看是否能够返回数据。
　　3)唯一识别码：app手机识别码，一般是唯一的。
安全测试主要从上面三点检查。第三个是唯一识别码，主要是指app上手机的识别码，一般很少用到，除非很严格的接口测试，例如银行app登录，需要指纹，而指纹来源手机，一般有一个手机识别码判断过程。

四、对测试流程改进以及测试质量保证提过哪些意见建议？(意思就 是除了大家都能做的这些你对公司还有什么特别的贡献，答好很加分)

1、测试人员介入太晚，基本上都是等代码开发完成时，才介入。

改进建议：在项目需求开始启动时，就能有相应测试人员跟进，并随之开始测试的一系列活动；由于在需求阶段可能测试人员的工作量可能较少；可以让其同时兼顾其它项目任务；到测试用例编写阶段才全职投入。

2、需求变化太多太乱，相关文档没有随之更新，文档与项目实际功能不相符；造成很多时候最新的需求都只是藏在个别人的脑中，而测试人员总是最后一个知道需求变化的人。

改进建议：能够建立需求变更体系，到什么阶段时必须停止需求变更（必须在项目前期就让需求提出人明确这一点）；每次需求变更必须让需求提出人员确认；需求变化后必须由专人更新相关文档（这些文档都是测试人员编写计划及用例的依据）；并能知会相关人员。这样才能做到程序人员修改相应的程序，测试人员修改相应的用例，且能对需求变更后的程序进行正确的测试。

3、项目无分阶段送测，造成无法对阶段性的开发成果进行测试，测试任务积压、问题无法及时发现。

改进建议：在项目前期制定项目计划时，将各阶段性送测纳入到计划中；开发人员根据项目计划进行开发，而测试人员可根据项目计划来安排自身编写用例的先后顺序以及在各阶段性送测时间要求送测（此阶段性送测可视项目的大小、项目与其它系统的关联来定好每个阶段送测的内容）；

4、测试人员没有独立的稳定的测试环境，无法控制版本更新；造成太多重复无效的测试，也常会因为提交无效的BUG。

改进建议：最好可以给测试人员提供一个独立的测试环境（包括数据库以及应用程序都是独立的），以保证测试人员所有的BUG都是稳定的、可重复的环境下发现的；如果不能做到独立测试环境情况下，也尽量做到能让测试人员去控制版本更新的频度，以控制测试的有效性。

5、没有一个行之有效的BUG跟踪机制；造成BUG提交重复、回归不及时，或不能正常被回归。

改进建议：项目中的所有成员都利用同一种方式去进行BUG提交、跟踪；BUG分发人员需做到BUG的过滤，来达到BUG的有效性；在BUG表单中需要能及时体现BUG的最新状态；这样项目组人员才都能对项目中已发现、已解决的BUG做到心中有数；项目管理人员也可以对整个项目的状态做到心中有数。

6、无完善的测试用例检查机制，无法对测试过程进行检查，也即无法保证测试结果的真实性。

改进建议：测试人员之间对测试用例进行走查，或开发人员分配时间出来对测试用例进行走查，以保证用例对需求的覆盖率；测试用例能与BUG对应，使用工具管理用例在每个阶段的执行情况，以对测试过程进行跟踪。

7、开发人员与专业测试人员比例严重不合理，而非专业测试（用户测试）介入太早。

改进建议：一般在国内的情况，测试人员与开发人员的比例是1:5左右，但在这里的比例严重不止，一个测试人员都负责多个项目，严重影响测试的质量；对于用户测试一般是在项目验收阶段才介入的，现在都提前介入了；如果用户必须提前介入测试，且作为测试的人力来算的话，那应该由测试来统一安排这些调度，以保证测试的合理分工。

五、怎么开展自动化测试工作的

1、自动化测试不宜大力投入

不管是自动化测试还是接口测试，都不宜在前期大量投入。当前业务是否适用自动化，哪些框架或者工具更适合，适合做接口自动化还是 UI 的自动化？如何让自动化达到收益和效果？
这些问题都需要根据团队和业务具体的情况去尝试，找到合适的才行。如果前期投入太大，团队对其期望太高，非常容易在遇到一点挫折的时候对自动化丧失信心。
另外，投入太大，毕竟加大人力或者减少手工测试的投入，会造成测试资源的紧张。在项目时间和成本的压力下，测试管理者需要顶着巨大的压力，这本身就很难成功。
可以安排一些技术强或者技术兴趣浓厚的成员，在项目允许的情况下减少其手工测试工作量，让其可以利用部分工作时间和部分业余时间尝试做自动化，先局部功能尝试，能够有效果，在扩大范围。逐步达到一定的自动化规模。

2、以接口为主UI为辅

UI 自动化因其运行环境的问题，会导致运行速度慢，对环境依赖过高。同时因程序界面的多变性，导致自动化脚本维护成本大大增加。
接口测试有很多优于 UI 自动化的地方。但是接口测试也自有其短板，对流程性质的测试并不适合用接口自动化来覆盖。接口自动化更适合覆盖单一接口功能的检查。
所以我们可以采用核心业务流程使用 UI 自动化，单一功能使用接口自动化，两种层面的自动化结合的方式来进行。

3、不轻谈自动化测试平台

目前测试界开始流行起自己开发测试平台（以接口为主）。简单来说就是模仿常见的接口测试工具，用 Python 或者 Java 写成了一个 web 版本的。
当然也有其理由，“定制性更强！”但是毕竟是软件都需要进行测试，花大量精力开发的平台并不稳定，而本身功能和理念上并没有太多更新。而这样的一些功能，市面上的绝大部分测试工具都能胜任。
如果是为了提高个人能力，项目时间有空余，怎么玩都可以。若是要在实际工作中应用，那么就有点得不偿失了。
自动化测试中，工具的重要性始终是最低的。理念、思维和环境治理才是最重要的。
通过不断小范围试错，找到适合自己团队的自动化策略才是最重要的。任何技术脱离实际应用都是耍流氓。

六、现场设计场景，说出查询服务端日志的命令？

head命令
①　Head -n -5 test.log:显示日志文件的开头5行；
②　Head -c 20 test.log:显示文件前20个字节；

tail命令
①　tail test.log：显示最后10行内容，tail默认显示最后10行内容；
②　tail -n 20 test.log：-n命令显示指定的行数；表示查看文件最后20行内容；
③　tail -f test.log：-f实时显示日志内容（默认10行，相当于添加参数-n 10）；
④　tail -n +10 test.log：从第10行开始显示内容；
⑤　tail -r -n 10 test.log：逆序显示最后10行内容；
cat命令
①　cat -n file：输出file文件中的全部内容,并且对file文件进行从 1 开始的编号；
②　cat -n text.txt > python.txt：把text.txt的文件内容加上行号后输入到python.txt中；
③　cat log.txt | grep ‘qq’:在log日志中查找qq字符；
④　cat log.txt | grep ‘qq’-A 5：在log日志中查找qq字符，并显示所在行之后5行；
⑤　cat log.txt | grep ‘qq’ -B 5：在log日志中查找qq字符，并显示所在行之前5行；
⑥　cat log.txt | grep ‘qq’ -C 5：在log日志中查找qq字符，并显示所在行前后5行；
⑦　cat log.txt | grep -v‘qq’：在log日志中查找排除qq字符所在的行；

grep命令
①　grep qq /home/test：在/home/test文件中查找单词qq；
②　grep qq /home/test /home/test1:在多个文件中查找单词qq；
③　grep -l qq /home/test /home/test1：使用-l参数，列出包含指定模式的文件的文件名；
④　grep -n qq /home/test：使用-n参数，在文件中查找指定模式并显示匹配行的行号；
⑤　grep -v qq /home/test：使用-v参数，输出不包含指定模式的行；输出/home/test文件中不包含单词qq的行；
⑥　grep ^qq /home/test：Bash脚本将 ^ 符号视作特殊字符，用于指定一行或者一个单词的开始。例如输出/home/test文件中所有以“qq”开头的行；
⑦　grep -i qq /home/test：使用-i参数，在查找时忽略字符的大小写；在/home/test文件中查找“qq”单词；
⑧　grep -e qq -e ww /home/test：使用-e参数，一条grep命令中在/home/test文件中查找‘qq和‘ww单词；
⑨　grep -B 4 qq /home/test：使用-B参数输出匹配行的前4行；
⑩　grep -A 4 qq /home/test:使用-A参数输出匹配行的后4行；
⑪　grep -C 4 qq /home/test：使用-C参数输出匹配行的前后各4行；
⑫　grep test *file：查找后缀有 file 字样的文件中包含 test 字符串的文件，并打印出该字符串的行；
⑬　grep -r update /home：以递归的方式查找符合条件的文件。例如，查找指定目录/home及其子目录（如果存在子目录的话）下所有文件中包含字符串"update"的文件，并打印出该字符串所在行的内容；
⑭　grep -v test test：反向查找。前面各个例子是查找并打印出符合条件的行，通过"-v"参数可以打印出不符合条件行的内容。查找文件名中包含 test 的文件中不包含test 的行；
more命令
①　more +3 test.log:从第三行开始显示内容；
②　more -4 test.log:将日志内容设置为每屏显示4行；
③　more -5 +10 test.log：一屏5行，从第10行开始显示；
④　more -5 +qq test.log：先找到qq字符串，然后在这个字符串所在行的前两行开始显示；

less命令
①　less -n test.log：查看文件并显示行号；
②　less +10g test.log：定位到第10行；

Vim命令
补充：
跟tail功能类似的命令还有：
cat 从第一行开始显示档案内容。
tac 从最后一行开始显示档案内容。
more 分页显示档案内容。
less 与 more 类似，但支持向前翻页
head 只显示前面几行
tail 只显示后面几行
n 带行号显示档案内容
od 以二进制方式显示档案内容

七、输入网址后，发生了什么

1.DNS解析
DNS解析的过程就是寻找哪台机器上有你需要资源的过程，寻找的过程遵循就近原则。
输入一个网址并按回车的时候浏览器会根据输入的URL去查找对应的IP，具体过程如下：
（1）首先是查找浏览器缓存，浏览器会保存一段时间内访问过的一些网址的DNS信息，不同浏览器保存的时常不等。

（2）如果没有找到对应的记录，这个时候浏览器会尝试调用操作系统缓存来继续查找这个网址的对应DNS信息。

（3）如果还是没找到对应的IP，那么接着会发送一个请求到路由器上，然后路由器在自己的路由器缓存上查找记录，路由器一般也存有DNS信息。

（4）如果还是没有，这个请求就会被发送到ISP（注：Internet Service Provider，互联网服务提供商，就是网络运营商，中国电信中国移动等），ISP也会有相应的ISP DNS服务器，就是本地DNS服务器，请求的域名基本上都能在这里找得到。

（5）如果还是没有的话， ISP的DNS服务器会将请求发向根域名服务器进行搜索。根域名服务器就是面向全球的顶级DNS服务器，共有13台逻辑上的服务器，从A到M命名，真正的实体服务器则有几百台，分布于全球各大洲。

（6）如果到了这里还是找不到域名的对应信息，那只能说明一个问题：这个域名本来就不存在，它没有在网上正式注册过。或者域名过期了。

这也就是为什么有时候打开一个新页面会有点慢，因为如果本地没什么缓存，查找域名的过程要这样递归地查询下去，查找完还要一层层的向上返回。例如"mp3.baidu.com"，域名先是解析出这是个.com的域名，然后跑到管理.com域的服务器上进行进一步查询，然后是.baidu，最后是mp3， 所以域名结构为：三级域名.二级域名.一级域名。
所以DNS根据域名查询IP地址的过程为：浏览器缓存 --> 操作系统缓存 --> 路由器缓存–>本地（ISP）域名服务器缓存 --> 根域名服务器。

2.进行TCP连接
浏览器终于得到了IP以后，向服务器发送TCP连接，TCP连接经过三次握手。

3.浏览器发送HTTP请求
浏览器和服务器建立连接以后，浏览器接着给这个IP地址给服务器发送一个http请求，方式为get，例如访问www.baidu.com。其本质是在建立起的TCP连接中，按照HTTP协议标准发送一个索要网页的请求。
这个get请求包含了主机（Host）、用户代理(User-Agent)，用户代理就是自己的浏览器，它是你的"代理人"，Connection（连接属性）中的keep-alive表示浏览器告诉对方服务器在传输完现在请求的内容后不要断开连接，不断开的话下次继续连接速度就很快了。可能还会有Cookies，Cookies保存了用户的登陆信息，一般保存的是用户的JSESSIONID，在每次向服务器发送请求的时候会重复发送给服务器。
在建立连接发送请求时每个服务端需要和客户端保持通信，有很多客户端都会和服务器进行通信。服务器为了识别是哪个客户端与它通信，就必须用一个标识记录客户端的信息。客户端首次访问服务器，服务端返回响应时通过附带一个记录的客户端信息的标识来返回给客户端，这个标识就是JSESSIONID，JSESSIONID就放在了客户端的Cookies里。当客户端再次向服务器发送请求时上就使用上次记录的Cookies里面的JSESSIONID，这样服务器就知道是哪个浏览器了。这样他们之间就能保持通信了。
发送完请求接下来就是等待回应了，如下图：


4.服务器处理请求
发送完请求接下来就是等待回应了，如下图：

服务器收到浏览器的请求以后），会解析这个请求（读请求头），然后生成一个响应头和具体响应内容。接着服务器会传回来一个响应头和一个响应，响应头告诉了浏览器一些必要的信息，例如重要的Status Code，2开头如200表示一切正常，3开头表示重定向，4开头是客户端错误，如404表示请求的资源不存在，5开头表示服务器端错误。响应就是具体的要请求的页面内容。

5.浏览器解析渲染页面
（1）浏览器显示HTML
当服务器返回响应之后，浏览器读取关于这个响应的说明书（响应头），然后开始解析这个响应并在页面上显示出来。
浏览器打开一个网址的时候会慢慢加载这个页面，一部分一部分的显示，直到完全显示，知道最后的旋转进度条停止。因此在浏览器没有完整接受全部HTML文档时，它就已经开始显示这个页面了。

（2）浏览器向服务器发送请求获取嵌入在HTML中的对象
在浏览器显示HTML时，打开一个网页的过程中，主页（index）页面框架传送过来以后，浏览器还会因页面上的静态资源多次发起连接请求，需要获取嵌入在HTML中的其他地址的资源。这时，浏览器会发送一些请求来获取这些文件。这些内容也要一点点地请求过来，所以标签栏转啊转，内容刷啊刷，最后全部请求并加载好了就终于好了。
这时请求的内容是主页里面包含的一些资源，如图片，视频，css样式，JavaScript文件等等。
这在文件属于静态文件，首次访问会留在浏览器的缓存中，过期才会从服务器去取。缓存的内容通常不会保存很久，因为难保网站不会被改动。
静态的文件一般会从CDN中去取，CDN根据请求获取资源的时候可能还会用到负载均衡。

（3）浏览器发送异步（AJAX）请求
对于那些动态的请求，动态网页等就必须要从服务器获取了。对于静态的页面内容，浏览器通常会进行缓存，而对于动态的内容，浏览器通常不会进行缓存。对于这些动态请求，Nginx可能会专门设置一些服务器用来处理这些访问动态页面的请求。

6.关闭TCP连接
当数据完成请求到返回的过程之后，根据Connection的Keep-Alive属性可以选择是否断开TCP连接，HTTP/1.1一般支持同一个TCP多个请求，而不是1.0版本下的完成一次请求就发生断开。TCP的断开与连接不一样，断开可以分为主动关闭和被动关闭，需要经过4次握手。
当浏览器需要的全部数据都已经加载完毕，一个页面就显示完了。

八、Nginx负载均衡策略

九、为什么要写用例

①　理清思路，避免漏测和重复测；
②　提高测试效率；
③　跟进测试进度；
④　更好的发现问题，记录问题，复现问题；
⑤　跟进重复性工作；
⑥　告诉领导：我做过；
⑦　接口测试流程中的一个产物（测试用例）

十、怎么进行接口测试

通过工具模拟客户端向服务端发送请求并接受服务器返回的数据来对接口的功能，逻辑业务，异常，安全进行测试；
（1）功能测试：测试这个接口的功能是否实现，并且测试这个接口是否按照接口文档来进行开发的（比如说接口文档规定了一些关键字，而开大的时候把关键字改成了其他的关键字，因为在整个项目周期，并不只有一个开发而是有多个，所以可能因为在开发过程中因为关键字不一样导致某些开发的功能异常，还有自动化脚本也会发生异常）

（2）逻辑业务，主要指的是一些逻辑业务依赖关系（比如支付宝提交订单的时候要保证你是在登录的情况下，如果你没有登录而提交成功了，这就是异常，可以修改请求的cookie来测试）

（3）异常测试：参数异常：关键字参数（应用其他的关键字替换进行测试）、参数为空、参数多少（通过添加参数增添个数），参数错误。数据异常：关键字数据（填入的数据用其他的数据语言的数据替用）、数据长度、数据为空、数据错误。
　　
　　由于我们项目前后端调用主要是基于http协议的接口，所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
　　–也可以用 接口自动化来实现，就是用代码实现，框架和UI自动化差不多，发送请求用断言来判断。

十一、没有接口文档，如果做接口测试？（这是个送命题）

1.没有接口文档，那就需要先跟开发沟通，然后整理接口文档（本来是开发写的，没办法，为了唬住面试官，先说自己整理了）
2.没有接口文档，可以抓包看接口请求参数，然后不懂的跟开发沟通

十二、在手工接口测试或者自动化接口测试的过程中，上下游接口有数据依赖如何处理？

用一个全局变量来处理依赖的数据，比如登录后返回token,其它接口都需要这个token,那就用全局变量来传token参数

十三、用一个全局变量来处理依赖的数据，比如登录后返回token,其它接口都需要这个token,那就用全局变量来传token参数

这个标准答案是：mock

十四、当一个接口出现异常时候，你是如何分析异常的？

1.抓包，用fiddler工具抓包，或者浏览器上f12,app上的话，那就用fiddler设置代理，去看请求报文和返回报文了
2.查看后端日志，xhell连上服务器，查看日志

十五、如何模拟弱网测试？

fiddler和charles都可以模拟弱网测试，平常说的模拟丢包，也是模拟弱网测试

十六、如何分析一个bug是前端还是后端的？

平常提bug的时候，前端开发和后端开发总是扯皮，不承认是对方的bug
这种情况很容易判断，先抓包看请求报文，对着接口文档，看请求报文有没问题，有问题就是前端发的数据不对
请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题

十七、在实际项目中你是如何做测试计划

1. 对客户提供的或需求分析人员编写的用户需求文档或需求规格说明书进行分析，提炼出测试要点；
2. 根据测试要点编写测试用例。
3. 由评审组对测试用例进行评审–修改–再次评审–初步定稿
4. 执行测试
   4.1 按照测试用例对系统进行功能验证及客户的需求验证
   4.2 将测试过程中产生的Bug录入缺陷管理系统
   4.3 新版本发布后，对本次版本新增加的功能以及开发人员修正的Bug进行回归测试
   4.4 根据项目需要提交测试报告。

十八、测试这个系统对于我们测试来说，你觉得最大的挑战是什么？最复杂的模块？

熟悉业务，只有熟悉业务，才能充分全面的设计测试用例，覆盖所有的功能，最后才能保证项目的质量；

十九、第三方接口依赖，用 Python 写的 mock 服务吗？主要写的哪几个？ 做什么用的啊？

二十、postman 怎么搭建 mock 服务？

(1)打开postman,新建一个mocke服务；
(2)自定义方法的请求方法（post get delete等），接口名称，请求包体，接口描述、接口返回代码,接口返回数据；
(3)mockserver会生成一个域名，向这个域名+自定义的接口进行发送请求，返回结果代码以及结果内容就是之前定义好的内容；

尾言

突发奇想，咱们面试题开始了第一期， 有的朋友和我说，能不能把面试题做个合集，我拍脑一想，也是啊，为什么不做个合集呢，于是乎，我就把资料进行了打包，

需要的朋友可以加文末卡片中的微信，免费领取！！！