软件测试必问必背40道互联网企业面试题集（含答案解析），持续更新......_互联网测试面试题

01 接口测试中如何校验结果是否正确？

接口测试中，有两种需要校验：

一、HTTP状态码校验，验证返回的状态码为200

示例：断言 status_code 是否等于200

二、 业务校验：

1.业务的响应码，有请求成功的响应码 和请求失败的响应码。

2.当接口响应报文比较短，比较固定的情况下，校验完全一致

3.当接口响应报文比较长，比较多的情况下，校验最核心的业务信息。

4.当接口响应报文非常复杂的多层级xml格式或者json格式，通过xpath ,JSONpath,正在表达式的匹配方式获取到最关键的业务节点，然后再校验。

5.查询数据库校验

核心就是：业务状态码的校验 和 核心字段校验

示例：

业务的响应码是由项目里边统一定的，之前做过的项目是用10个0代码 接口请求成功，errcode=“0000000000” errmsg=“成功”，可根据具体的响应码进行断言。

核心字段的断言 ，可借助chrome浏览器的插件JSON-handle_0.6.1.crx，非常好用。

HTTP常见的状态码：

200 OK 请求成功。一般用于GET与POST请求（HTTP状态码表示网络传输的意义，如200只应该表示连接上了服务器，而不应该用来表示业务逻辑返回成功。）

301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替

302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI

304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源

307 Temporary Redirect 临时重定向。与302类似。使用GET请求重定向

400 Bad Request 客户端请求的语法错误，服务器无法理解

401 Unauthorized 请求要求用户的身份认证

500 Internal Server Error 服务器内部错误，无法完成请求

502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应

503 Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中

504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求

02 没有接口文档，如何做接口测试？

没有接口文档，想做接口测试的话，自己实践过以下2种方式：

1. 通过抓包的方式，根据业务流获取到对应的接口，然后整理成相关文档，如果有不清楚的字段，将问题汇总后找开发咨询，然后在进行接口测试。（抓包工具charles）

2. 可以通过 jmeter 的代理录制功能，将接口逐一录制下来形成接口文档，然后再逐一进行接口测试。

一般在项目开发阶段，接口文档基本上是必备产物了，一般由后端开发人员提供，作为和前端人员进行前后端接口联调的桥梁，或者与别的项目模块进行交互提供指导等等，接口文档的准确性，实时性，详细与否等，都会极大的影响联调工作。（或者是开发推演阶段，开发会定好接口名称、入参、出参等，维护在接口文档里边，有更新的话，会及时通知相关人员）

目前经历过的公司，都会有接口文档，有差异的地方 就是平台不一样，常见的有swagger、DOClever、sosapi，如果面试过程中遇到该问题，上述的2种回答可供参考，另外可根据具体项目上的情况再聊聊。

03 接口测试中，依赖登录状态的接口如何测试？

依赖登录状态的接口，本质上是每次发送请求的时候，需要带上token才能发送成功，如：查询个人信息的接口，必须是该账号或该用户登录后，请求查询个人信息的接口，要是未登录，查询个人信息接口会直接提示让去登录。类似这样的业务流。

自己实践过的2种方式（移动端）：

第一种：使用jmeter的接口测试，一般登录接口 登录成功后返回token，（1）登录成功后response 里边会返回token （2）获取返回的token（JSON Path Extractor ），存为全局变量 （3）在需要token的地方，直接使用 ${token}

第二种：使用python 代码的方式，（1）登录成功后response 里边会返回token，（2）将token 存到一个文件里边 （3）编写获取token的公共方法 （4） 在需要使用token 的时候，直接调用该公共方法

需要注意的是，token过期问题，当tonken过期后，刷新登录接口，获取最新的token 。

常见的cookie、session、token 都是用于鉴权的，通俗来讲就是：检查用户是否有访问该接口的权限，目前在移动端常用的是token，cookie 和session常见。

04 给一个实际的需求，要求输出测试用例

面试过程中遇到3次都提过此类问题：

第一家，当时在用wx视频面试，面试官就说，就当前的视频界面，输出测试用例

第二家，面试官让 为即将发布的一个活动入口-APP端首页新增一个banner入口,点击banner 可跳转到对应的活动界面，对于该功能，输出测试用例

第三家，重点问了小程序端的测试 跟APP端测试的差异，同时假设给你一个小程序，请输出测试用例

记得4-5年前，那时比较火的一个面试题就是，给你一个带广告图案的纸杯，请输出测试用例。

测试用例设计的核心，主要从以下几个方面入手（测试类型）：

功能测试、UI测试、兼容性测试、性能测试、安全测试、易用性测试等

以下提供了2个功能的测试用例，可供参考：

案例一：以一个带广告图案的纸杯为例，设计测试用例：
基本功能:

杯子的容量（P0）：能装多少水，空杯、半杯、满杯
杯子的形状（P1）：圆形，上面口大，下面下
杯子的材料（P1）：纸杯
杯子的抗摔能力（P1）：风吹是否会倒，摔一次是否会摔坏，摔多次是否会摔坏
杯子的耐温性（P1）: 装冷水，冰水，热水

广告图案（P1）:
广告内容与图案碰水是否会掉色
广告内容与图案是否合法
广告内容与图案是否容易剥落
广告内容与图案是否符合某个民族的禁忌

可用性及安全性（P2）:

可用性：

1，装入液体多久会漏水
2，装入热水多久后可以变温，装入冰水多久后可以融化
3，如果装入的不是液体，像石头、沙子、铁块等

安全性：

1，装入不同液体，是否会有化学反应，比如：可乐、咖啡等饮料
2，装入热水杯子是不是会变形和异味
3，可以加入当热水小于多少度（一个确定值）时，手不会被烫伤

易用性和性能（P3）：

易用性：

1，不同人群是否能适合杯子的形状，包括握着杯子的感觉和拿着杯子喝水的感觉
2，不同人群是否能接受杯子的广告内容和图案
3，纸杯杯壁的薄厚，杯子的深度是否可以让消费者接受

性能：

1，杯子在50度，80度的水温下可以使用多少次
2，倒满开水后，放入冰箱冷冻结冰，取出再融化后杯子都是可以继续使用等等。

案例二：为即将发布的一个活动入口-APP端首页一个banner入口,点击banner 可跳转到对应的活动界面，对于该功能，输出测试用例
功能测试：

1，banner入口在app端的哪个版本上发布（由产品或运营定）
2，banner 入口是在后台维护，还是在前端维护，如果是在后台维护，那么后台发布后，所有APP端不同版本都能展示该入口，如果是前端维护，那么必须升级APP 才能看到最新的banner入口（需求培训时产品会定）
3，点击banner ,能正常跳转到活动页面（是否需要用户登录，得提前确认好-鉴权）
4，用户在APP端首页 左右滑动banner（默认轮播的形式）,可正确找到该入口
5，后台更新了banner图片后，APP端可正常展示最新的banner图片
6，APP切换tab后，再切换回来，banner及背景是否正常
7，后台下架了该 banner , banner 在APP端就不展示了
8，活动量大的情况下，需要考虑：限流（只允许一定数量的访问）、降级（停掉不重要的功能）、熔断（当A服务模块中的某块程序出现故障后为了避免影响其余客户端的请求而作出的及时回应，友好提示）、风控（防止刷单操作等）

UI测试：

1，不同设备上 banner 的图片是否变形
2，banner 文案是否吸引人，是否突出活动
3，banner的尺寸大小、展示位置、展示形式、轮播提示

兼容性测试：

1，不同的手机设备上 banner 图片是否变形
2，Android 不同厂商的手机、不同系统的设备都能看到 banner 入口，并正常查看活动界面(一般兼容性测试 根据公司的测试机来定，有经费的话 直接找第三方云测机构)
3，IOS 不同型号 不同版本的设备都能看到 banner 入口，并正常查看活动界面
4，老人家放大字体后，banner 是否正常展示

性能测试：

1，活动发布后，支持多少用户同时点击该banner
2，点击bannner 进入活动页面至活动页面内容全部展示出来的时长

安全测试：

1，是否可以通过抓包 获取接口信息，用户的隐私信息

易用性测试：

1，首页banner 是否好找，是否明显(APP首屏第一帧banner)

其他：

1，是否需要埋点
2，是否有小程序端的业务，注意多端同步的问题

05 给出具体问题，让定位是前端问题还是后端问题

这个题目，印象比较深，面试官提前出好题并打印出来了，面试的时候直接问。

问题大概是以下这2个：

一、在APP端新创建了一条数据，提示创建成功，但是数据库和后台管理端都查不到

分析：

步骤1, 核对APP端调用的接口是否正确
步骤2，若接口调用正确，确保调用的方式、 入参 、必填项都ok
步骤3, 前端核查创建按钮是否生效，是调接口返回的创建成功，还是前端写死的成功？通过抓包的方式，确定点击登录按钮后是否请求接口，如果没有请求接口，可以先将 bug指派给前端，如果请求了接口，且提示创建成功，继续进行下一步
步骤4，查看数据库，看该条记录是否在数据库中存在，依据题目要求此条记录在数据库中不存在，那就去服务器，查看该创建数据对应时间点的日志，查看是否有报错日志，有报错的话，直接提给对应的后台开发即可，没有报错的话，找出创建数据的insert 语句的 trace id ,接着查看调用链路，查看调用链路的日志，逐步去分析（到这一步就给后台开发就行）
其他：
若APP端的环境与后台管理的环境不一致，则也可能导致新增成功但是查不到，如：APP端是开发环境，但是后台管理和数据库都是在测试环境。

二、在APP端新创建了一条数据，提示创建成功，数据库有数据了，但是后台管理查不到

分析：环境确保一致（开发环境、测试环境、预发布环境、生产环境）
步骤1，先确认创建的数据跟数据库的记录 是否一致，一致的话证明APP端创建数据成功
步骤2，核查后台管理调用的接口是否正确，检查入参、必填项等，是否正确,若正确，继续下一步
步骤3，（1）先考虑当前登录用户是否有权限查看APP端创建的数据、过滤条件（2）在服务器上找到点击查询按钮时请求的日志， 打印出查询的 sql，分析sql ,重点关注过滤条件 ，可对照接口文档对比或者直接找前端开发

以上回答可回答该问题：如何判断一个bug是前端还是后端的？遇到问题，都需要抽丝剥茧，找到问题关键。

以下是 APP 端和 Web 端 找问题的思路，可供参考：

APP端发现问题：

APP 端上有明显的报错信息，如闪退、黑屏、无响应等，可以由友盟去查看具体的报错日志
App 端发现问题，通过抓包的方式确认前端输入或请求的内容是否跟返回的一致，若一致的话 再去查看数据库 ，看是否都一致。
同时可根据接口文档逐一核对 app端页面显示的字段是否与接口文档一致，然后再对比与自己输入的一致 。

Web 端发现问题：

F12 查看接口的入参 出参 是否与接口文档一致，若都没问题，去服务端查看请求的日志信息，是否报错 ，报错的话 ，将关键记录 截图附在bug 里边，bug里边详细记录 问题发生的路径，后台日志里边会详细记录 用户的操作步骤 。

06 对于依赖第三方的接口如何进行测试？

之前在项目中遇到这种情况：

1. 跟第三方对接，联调的时候，若是对方的接口暂时没开发完成，但是有接口文档的情况下， 需要模拟。

2. 还有就是 常见的调用微信支付、支付宝支付的情况下，需要模拟。

那我们在做接口测试的时候，测试这部分内容就需要自己模拟，假设第三方的接口完全是按照接口文档实现的，那么我们就可以使用postman来进行mock(一般用于测试环境)，还有其他的moco 开源框架（moco-runner-0.12.0-standalone.jar）都可以实现。

之前用posman实践过，可参考如下链接，内容很详细：

Postman的Mock Servers功能使用

也可以通过Flask，Django 来实现接口的Mock 服务。

07 接口自动化测试怎么做？

面试过程中，也问了该问题，以下是自己的回答：

接口自动化测试，之前做过，第一个版本是用jmeter 做的，1 主要是将P0级别的功能接口梳理出来，根据业务流抓包获取相关接口，并在jmeter中跑通，2 是整理了项目上的所有接口，先将单个接口跑通，然后再编写不同的接口用例，如入参、必填项、状态值不同，考虑异常情况、接口安全等，整理的一套接口脚本。随着项目不断的迭代，基本功能稳定，每次新加功能或者是修改已有功能，只需要将已有的接口跑一遍，速度很快。但是呢，也不应该止步不前，第二阶段接着用Python 代码去实践一波，当时使用的是unittest 框架，做了一些基础的 封装工作，如维护全局的token、封装http的get 和post 请求、使用了assert断言，添加了日志和报告，完成了1.0版本的代码，代码能跑起来，但是还有值得改进的地方。（向pytest 过度，如参数化、标记冒烟测试的用例、测试用例分类执行、顺序执行、失败重跑、跳过、丰富的第三方插件等）目前对pytest学习中。

回答完看了面试官的反应，感觉还行，面试官就追着问了几个问题：
1.python 常用的库有哪些？

os、request、pymyql、time、xlrd、xlwt、math、random、logging等等

2.jmeter做接口自动化 与Python 做 接口自动化有什么区别？是什么原因让你想去拿代码实现的呢？

jmeter 偏向于代码弱的同学或者 是无代码基础的同学，上手快，适合迭代频率高、时间少的项目

如果有充足的测试时间 和写代码的时间，那就可以试试拿python,主要还是看团队成员的水平及项目情况。

选择适合自己项目的才是最重要的。

3.是否能落地(问了好几次)

能落地，但是还有改进空间，离那种大型项目框架的代码还是有些许的距离的，我会继续实践并向其靠拢。

面试结束后，我去bili上搜索了一下该问题，以下是别人的答案，积累经验吧。

接口自动化测试怎么做？

1. 项目组做自动化的可行性分析，自动化率能够实施什么样的程度
2. 调研测试团队对于自动化技术的程度，一般会伴随着demo演示
3. 计划制定，自动化测试框架搭建，逐步实施。发现框架的问题进行改善
   指定计划，提取或编写自动化测试用例，由leader 编写自动化测试框架，组员编写和调试自动化测试脚本，无人值守的jenkins，脚本的维护
4. 把自动化流程化，框架出使用文档和规范文档
5. 持续不断的完善框架
6. 把自动化测试标准推广到其他的项目。

面试过程中，还是需要随机应变，仔细听面试官问问题的重点，TA想知道流程还是细节，具体场景具体分析。

08 接口测试过程中发现过哪些bug?

回答之前先思考，面试官问这个问题重点想了解什么。

看你有没有做过接口测试？是否关注过接口的入参及返回信息？是否通过接口返回检查数据的交换、传递和控制管理以及上下游依赖？

回答问题要有框架性思维，就跟功能测试类似，功能测试一般要从功能、UI、兼容性、性能、安全等等几个方面回答，那么接口测试也可以从以上这几个方面回答：

如功能：接口是否实现了产品给出的所有异常情况的异常信息提示，必填项、选填项、默认值（null \空’'）、字段类型的校验、字段长度校验（边界值）、插入相同的入参多次执行报错，提示数据已存在；

兼容性：修改旧接口是否兼容了老的功能；

性能：接口超时提示、接口存在高并发场景、同一接口只能请求一次，再次拿相同的入参header请求时报错；

安全：接口对敏感信息如身份证、手机号、密码等信息掩码展示、非登录用户访问需要登录的接口（鉴权）；

等等

以下是我在接口测试过程中遇到的bug，可供参考：

• 异常信息提示未按照产品给出的文案实现（通常在测试过程中，异常类的测试可能测试得不够全面，如弱网测试提示、接口异常提示、框架的一些异常提示由配置文件集中化定义，方便的话拿过来一一对照着过一遍）；

• 绕过前端页面验证，如购买接口，有价格参数，测试时将把价格改为-3，购买成功；

• 绕过身份验证，大多是需要用户登录才能访问的接口，但是不带用户token 也能访问接口；

• 密码安全 遇到过的现象是在APP 端输入的密码掩码展示了，但是通过抓包，发现接口请求参数里边的密码明文展示了；

• 提现输入框，绕过前端，金额可以输入负数；

• 修改已有的接口影响了接口的老功能，或是未兼容历史数据

回答上述问题之前，可先说明自己做接口测试用的是什么工具，如何做的，然后再回答发现过哪些bug，这样比较全面一点。

接口测试就是为了避免绕过前端验证，直接访问后端接口的BUG。现在的项目都强调前后端都要校验。

09 对于复现率不高的bug怎么处理的？

发现问题，多次尝试仍然不能重现，先把bug记录到bug管理平台上，回忆问题发生的场景，详细的描述操作步骤、业务流、记录出现问题的设备的操作系统及版本，APP应用的版本，环境信息，测试账号信息等。

附带对应的截图或录屏，备注问题发生的时间（时间很重要，方便开发定位到某个时间段的日志）【只要发现问题，都要记录到bug 管理平台】

一定要在bug标题标注是偶现，备注中写出出现的频率，或者是发生过的次数。避免开发自测时只验证一次该问题没有复现就关闭了bug。

如果项目时间允许，bug等级高，需要开发协助重现；如果时间不允许，记录到bug平台长期跟进。每一轮回归测试都重新回归该bug。多轮回归未重新复现该bug且bug等级低，就可以关闭该bug了，若bug等级高，多轮回归测试未复现，让开发协助复现，如果还是复现不了，在后续的版本继续跟进。

10 给你一个新项目，你怎么开展测试？

之前遇到这个面试题，一般都是按照工作流来进行回答的，如拿到新项目后，先熟悉原型，了解需求，书写测试用例，测试用例评审，提测后，进行测试 提交bug 回归，产品验证，上线验证等。

现在再看这个题目，有了些许的疑问？这个新项目是指还没开 kick-off meeting 的项目还是对测试人员来说是之前没有做过的项目，项目已经在进行中了？

1. 学了项目管理的知识后，觉得可以先提出一些问题，然后再去回答面试官的问题。

2. 先了解目前项目的进展，处于哪个阶段? 【启动、规划、执行、监控、收尾】

3. 项目计划，包含开发时间、测试时间、上线时间, 是否都已经定好了？

4. 是作为测试负责人的角色 还是项目组测试人员之一？

5. 项目的已知风险和潜在风险？

根据面试官的回答，然后在脑子里调整自己的答案。

• 如项目还未开始，提前了解项目已有的文档。

• 如需求培训或开发阶段，吃透需求、书写测试用例、测试用例评审、提测后测试用例执行、bug提交、回归测试、上线验证等等。

• 如测试阶段，先了解是否之前写过测试用例，熟读需求，对照着需求逐步测试，在此过程中理解业务，了解上下游业务并重点掌握，把控项目进度，按时完成测试任务。同时整理常用的测试环境账号、链接、数据库链接等信息，帮助更好地熟悉业务。【按照工作流程发挥】

总的来说：不同的阶段， 有不同的侧重点。根据面试官的回复来做调整。

以上就是今天分享的内容，如果你在面试中也遇到过该问题，欢迎后台留言写下你的回答，我们共同成长，一起进步，攻克更多的面试题。

由于篇幅原因，以上只展示十道面试题答案解析，需要更多面试题以及答案解析的可以文末查看

11 弱网测试是怎么做的？

12 adb命令用过哪些？列出所有应用的包？

13 APP 端兼容性测试怎么做？

14 Monkey的常用参数及日志分析

15 测试同学如何有效获取到最新需求？

16 关键字驱动和数据驱动了解吗？

17 python中修饰器的作用

18 elasticsearch存储数据和传统关系型数据库有什么区别？

19 怎样获取字典中的所有键的列表

20 如何查看Linux服务器的负载？

21 linux常问的面试题

22 编写测试用例的价值

23 redis面试题

23 使用reduce实现阶乘

24 发现不可复现的缺陷如何处理？

25 软件测试结束的标准有哪些？

26 常见的软件测试方法

27 开发不承认是bug，你该怎么做？

28 测试过程中遇到需求变更应该怎么做 ？

29 线上出了bug怎么办？

30 项目提测checklist

31 测试过程中常见的一些风险点总结

32 mysql常见的面试题(1)

32 mysql常见的面试题(2)

33 HTTP常见的状态码

34 测试用例评审的必要性

35 项目时间紧张，有哪些措施可以保证按时上线？

36 什么是版本控制？常见的版本控制系统有哪些？

37 如何设计自动化测试用例？

38 Cookie 相关的知识点

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一 键三连哦！