搞定这些软件测试面试题，面试通过率提高百分之80！

十九、持续集成
19.1 jenkins + ant + jmeter + svn 接口自动化测试?
jenkins + ant + jmeter + svn 环境搭建
原来这个环境是我这边搭建的，
主要是几个步骤，
第一 Jenkins 安装、第二，ant 安装、第三， jmeter 安装、第四， jmeter 与 ant 连接
第五，Sn 安装、第六，任务的构建
首先我们要确定 jdk 已经安装好了，jdk 安装，可以下载 jdk 包，配置环境变量就行
再 jenkins 搭建，原来我们是用 yum 安装命令， yum install -y jenkins 安装 jelkins
如果 yum 安装不能进行，yum 仓库添加 jenkins 连接信息
或者就用下载安装包进行安装
ant 安装，我们可以百度去下载，
像原来我们这边一般会把常见安装包文件执行，我都会保存一个安装文档，
当下载 ant 安装包以后，只需要解压，并且配置环境就可以了
jmeter 安装，也是先下载安装包，把安装包导入到 linux 服务器，解压，配置环境变量就 ok 了
jmeter 跟 ant 连接，主要是配置 build.xml 的文件，
文件目录放在 jmeter 目录下，build 文件主要是配置,
jmeter 的路径，保存生成 html 跟 jtl 报告的路径，还运行 jmx 脚本的路径
把 jmeter 文件 ant-jmeter-1.1.1.jar 放在 ant 目录下
把 jmeter-results-shanhe-me.xsl 上传至 jmeter 安装目录的 extras 文件夹下
也要配置 jmeter.properties 文件把输出结果由 csv 修改成 xml
配置完成后，我们可以用 ant run 运行调试下，能否运行脚本成功
svn 服务器安装，原来已经安装好
安装，通过 yum 安装到服务器里面，建立资源库，配置里面配置文件，添加用户，修改权限，再通过,
svnserve -d -r /data/svn/启动服务器，同时我们要考虑防火墙是否允许访问或者关闭防火墙

138
jenkins 任务的构建
在 jmeter 系统配置中，先要添加环境变量，主要是 jdk 的路径，ant 的路径(linux 服务器里面的路
径)
添加 2 个插件，一个 html publisher pulin 主要生成 HTML 报告，一个 performance
pgn 运行 jmeter 脚本生成 jtl 报告
再构建一个任务，
在任务中
丢弃旧的构建，
再源码管理，配置 svn 服务器路径，导出文件位置，还有 svn 用户与密码
配置生成 jtl 报告的位置
配置生成 html 报告的位置
配置定时构建，原来我们设置设置半个月跑一次
还配置邮件发送( jenkins，系统配置，配置邮件服务器地址)
原来我们持续集成是半个月运行一次，当然我们也可以手动构建
1，我们一般把写完的 jmeter 的脚本
2，通过 svn 把写好的脚本检入到 svn 服务器
3，在 jenkins 任务下，选择定时构建，或者手动构建，检出 svn 上传最新脚本，去运行一般我们项
目在修改新的功能模块，上线，转测之前，都会自动去运行脚本。
运行完成，我们再 jenkins 下，查看脚本运行结果。
19.2 jenkins 如何使用?
原来我们主要是用来，持续构建环境还有我们的自动化脚本的运行
比如说： jmeter 接口自动化脚本
原来我们 jmeter 脚本运行，在 jenkins 里面，首先先建立一个任务，再从 svn 服务器中导出 jmx 脚
本，设置定时器，原来我们都是早上 B 点钟自动运行，构建 ant run 运行，后面添加生成的 html 根
告跟 jtl 报告，运行完成后，我们进行邮件提醒，我们只需要查看邮件，直看运行结果就 ok，出现
了问题，我再去找开发修复问题。
后续我们编写完成的接口自动化脚本，只需要通过 svn 检入到 svn 服务器即可，就会每天定时去运行，
查看结果就好。
比如说： pytest 框架自动化脚本
也是构建一个任务，设置源码管理，从 svn 导出源码，原来我们都是手工构建，没有建立定时任务，
执行 shell 命令 python pytest -m 测试用例的路径，

139
设置生成 allure 报告，建立邮件提醒，后面的工作当中，如果要运行 pytest 框架编写脚本
只需要通过 svn 把代码导入到 svn 服务器，手工构建，运行完成后，发送邮件提醒运行结束，如果有
错误，可以在 jenkins 平台里面去查看 allure 报告。
搭建环境这块，原来不是我做的，大概的流程。
原来我们构建测试环境，先建一个任务，源码管理，从 svn 服务器导出源码进行构建，运行 she 令，
包的解压跟替换，重启服务，建立一个邮件提醒。后期每次需要提测或者转测的时候，只需要去手动
构建这个任务即可。里面还有一些，dev 环境，部署，线上环境部署，但是一般我们测试就没有怎么
操作，但是原理都是一样。
二十、场景问题
20.1 有没有抓过包，为什么要抓包，具体怎么做的?
抓包这块，其实我们在工作用得是比较多的，一般我们都在测试过程碰到问题，我们有的候通过抓包
去看一下前端与后台的数据交互，通过分析这个数据，来定位到底是前端问题，还是后台问题。
主要用的就是 fiddler 工具，如果只是抓取 Web 端数据的话，只要在浏览器上设置代理服务器，指定
代理服务器为本地的 fiddler 这个工具，设置好端口：8888 就可以了，如果要抓取手机端的包，首
先需要保证手机与电脑(安装了 fiddler 的这个电脑)在同一个网络，在手机上要设置 http 代理服务
器为手动，然后服务器指定为电脑的 ip 地址，端口设置为 8888
例外，如果要抓取 https 包，可能还需要在电脑上安装证书，手机端这边也要安装证书，差不多
这样就可以。
20.2 为什么要进行抓包?具体怎么分析的?
主要是我们在测试过程中，出现 Bug 的时候，为了定位问题，分析问题，需要抓取前端后台的数据交
互过程，通过看数据，从而来分析到底是前端问题还是后台问题
分析这块的话：
1、首先看发的请求是否有问题，请求的接口 url 是否有错误，参数是否有错误，如果 url 或传参有
问题那就是前端 Bug
2、如果请求没有问题，看下后台返回的数据是否有问题，状态码 5 开头的基本都是后台问题，状态
码为 200，响应数据与预期不一致，那也是后台 Bug，不过这里有可能是数据库问题，也有可以是后
台代码问题，这里首先我一般会查看下数据库的数据，如果数据库没有问题，那就需要查看下后台的
日志文件，具体分析下看是后台代码哪里出问题了，然后把日志信息信息截图给开发，
3、返回的数据没有问题，请求参数，u 也没有问题，那可能是前端代码是否转换有问题，那就是前
端 Bug

140
20.3 大概给我讲下抓包的原理?
其实就是把 fiddler 设置为代理服务器，那么浏览器上发出所有请求都由 fiddler 这个工具来代理转
发，其实就是说：通过 fiddler 来拦截客服端与服务端之间的数据交互，这样我们可以拦截到客户端
给服务器发了什么数据，服务器给客户端响应了什么数据，然后对数据进行分析。
20.4 给你一个需求，你具体讲下，你怎么测试?
第一点：首先我要熟恶这个需求的背景，这个需要功能，我至少要知道这个需求做的是什么吧，做的
是一个什么样的解决方法这个要搞清楚。
第二点：这些搞清楚，看这个需要和其他模块有哪些交互，需不需要关联起来分析，有没有影响到其
他模块，或者数据有没有流向其他模块。
第三点：这些都清楚了，那么我会根据熟悉的情况看下工作量，哪个时间点交付，在这个时间点我需
要做一个计划给老大说下，如果时间充分，一个人能搞定，那么就一个人搞定，搞不定，我
会向老大申请人力。其实接下来也差不多了，分析需求，尽量要评审，在前期就保证好质量，
如果没有问题。其他也就是用例实例化，执行啊，bug 跟踪啊等，最后出个报告就好了。
基本我做的活，会这么做主要看你在最短时间把需求吃透，做好计划，展开工作。
20.5 给你一个项目，你怎么展开工作，请详细说一下，你具体怎么做的
面试官考的点：进我公司，给你一个项目，你怎么做，看你有没有独立做项目能力
第一点：首先我要熟悉这个项目的背景，我至少要知道这个项目做的是什么吧，做的是一个什么样的
解决方法这个要搞清楚
第二点：这些搞清楚，那么必须要清楚这个项目的核心模块和业务，我们给这个模块做一个优先级，
先测试哪些核心模块，再做哪些模块
第三点：根据刚刚信息，我会熟悉这个业务，这个业务相关模块，以及写数据前后台交互等
第四点：这些都熟恶了，那么我会根据熟悉的情况看下工作量，哪个时间点交付，在这个时间点我需
要做一个测试计划一般需求分析的话，根据我的经验基本 2 天差不多了，编写用例时间，执行时
间，bug 修复时间，我会做一个工作量评估，如果还有其他测试，我会把这个计划发给大家，让
大家评审这个计划和安排，看安排是否合理，大家能不能在这个计划时间段完成，基本需求分析
等多给个 2 天左右，那么大家要再这个时间段完成，完成后我会安排大家讲解需求，做需求评审
和需要讲解，前期时间多投入点，后面风险小一点，这个我主要跟进下进度就行。
第五点：那么接下来，大家按照计划去编写用例，用例在时间点完成后，我会组织大家评审，这个两
个我必须把控，减少后面测试风险，前面分析和用例把握到位，后续执行和 bug 这块不会有太多
问题后续的话，那么大家执行就行，我主要跟进这个进度，每天大家 bug 解决情况，以及测试进
度，做成日报，像些问题不好解决的，有问题的，我去协助那么测试完成后，我会收集大家测试

141
数据，做一份测试报告，这个我会评估这个测试有没有风险，没有的话，发送给开发老大，开发
所有人，测试所有人。这块评审下，后续组织测试人员安排上线，我基本是这么做的
20.6 项目快上线因为开发延迟，测试时间被压缩怎么做？
[开发延期完成，产品还需如期上线，测试需怎么办
首先看下自己还剩下多少时间，然后要评估工作量，评估下风险，比如说，可能我根本做不完，风险
太大，那么这个我首先要把风险提出来，给对应的领导，那么我会要求有人协助我完成，需要多少人
力来完成，
如果只是说，正常时间完不成，那么我可以提下加班，看加班这个时间段能否完成，如果可以，我会
和老大商量，提出加班计划。
如果是其他的，先跟领导确认，比如说我只需要把优先级高的工作完成其他工作可以安排到下一个版
本去做，那么我就做个计划，把计划个老大说下。
20.7 如果时间比较紧的话，你怎么安排你的工作
首先要评估下风险，比如说，可能我根本做不完，风险太大，那么这个我首先要把风脸提出来，给对
应的领导，那么我会要求有人协助我完成，需要多少人力来完成，
如果只是说，正常时间完不成，那么我可以提下加班，看加班这个时间段能否完成，如果可以，我会
和老大商量，提出加班计划，
如果是其他的，比如说我只需要把优先级高的工作完成，其他工作可以安排到下一个版本去做，那么
我就做个计划，把计划个老大说下。
20.8 返回数据现在有问题，怎么排查问题?
这个可能需要抓包，首先抓包看下前后台的数据交互情况，确认下是不是前端请求发送，有问题导致
返回数据有问题。如果是请求有问题，那提 Bug 给前端，让前端修复，
如果请求没有问题，与接口文档对比，查看下返回数据具体是哪里出问题了，这里还得，首先查看下
数据库，看是不是数据库中本身数据就有问题，如果数据库数据没有问题，那可能是后台代码问题，
这个时候可以查看下后台的日志文件，通过分析日志文件的错误信息排
查具体什么原因导致问题出现
20.9 有时候下订单成功有时候下单失败是什么原因
对于订单成功和失败的情况，各自去抓包，把两次抓取的数据来做对比，分析原因
1、假如发送的请求不同，那肯定是前端问题，
2、假如是返回数据不同，那基本判定是后台代码出了问题，这时候可以去看日志，看数据库，把这
些信息提交给开发处理，也可能是网络问题没发出去的。

142
20.10 APP 出现崩溃时怎么抓取日志
# adb logcat android studio logcat
这种情况我肯定要去看手机端的日志，去分析崩溃日志，通过 adb logcat 去直看日志，
根据崩溃时间段去查找这个时间段日志，去查看是否有 Error，Exception，Crash，OOM 等显
现，分析日志，不懂的可以百度查看下原因，然后发给开发处理。
20.11 微信里面，如果大家都看不到你发的朋友圈信息，分析下什么原因
1、A 删除了那条朋友圈信息
2、A 屏蔽了所有好友查看自己的朋友圈
3、如果没有屏蔽，多发几条看看，如果发的所有朋友圈，好友都看不到，
也可能是微信后台出问题了，或者 A 的微信账号有异常等等，
不过这种情况不太可能。
20.12 微信里面，如果只是 B 看不到，其他朋友都可以看到，分析下什么原因
1、B 把 A 拉黑了
2、A 把 B 拉黑了
3、B 设置了不查看 a 的朋友圈
4、A 设置了屏蔽 B 看到自己的朋友圈，或者 A 屏蔽了自己所有的朋友圈
5、A 删除了那条朋友圈信息
6、A 设置了只展示某个时间段的朋友圈信息
7、B 根本就不是 A 的微信好友
20.13 你测试数据是从哪里获得?怎么获得的，假如不告诉你，你怎么处理?
(1) 一般都是我们测试人员在测试过程自己造的测试数据，如果大量数据，我们可以用到存储过程
(2) 也可以让运维人员帮忙从生产环境导出相关的测试数据，如果测试数据中涉及安全性的数据，直
接是不能导出
二十一、测试经理管理
21.1 员工的绩效考核，量化标准
1、考勤，任务完成率，失效，完成，满意度，用例编写量，提交 bug 量，线上问题
2、新的任务完成，新技术研究，对团队的贡献

143
21.2 你组内有一个技术比你牛逼年轻的组员不服你，你会怎么处理
不要开除他，首先要认可他的能力，跟员工沟通，自身要有宽容之心，看下自身的不足以及
需要提升的方面，技术方向，管理的能力等等，看下他为什么不服的，尽量做到让他服你
21.3 你的组员提交的 bug 开发不认同而吵起来了，你怎么处理
如果是我的组员跟开发因为提交的 bug 争吵的时候，我首先会先稳定下他们的情绪，先跟测试沟通为
什么吵起来，沟通的时候要先扬后抑，不好的地方的话指出来。确定问题这边具体是什么原因，如果
是测试这边的问题，就让测试员把自己的问题处理掉，当然，开发这边也是需要沟通的，说明争吵是
不对的，主要是将冋题说明清楚，如果是测试问题可以说明测试这边的问题，如果是开发这边的问题，

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。