目录
八、 在项目测试过程中，你都测出过哪些类型的 bug？哪些地方最容易出 bug？
九、 fiddler 的工作原理是什么？在项目测试过程中主要在哪些场景下使用？
十一、 小明在刷抖音时发了一个评论，但是 APP 界面没显示出来，如何排查这个问题？
三、有过漏测导致线上 bug 的经历吗？什么情况下会造成漏测？
1、 给/home/demo.txt 文件设置为所有人可读可写权限
2、 搜索 a.log 文件中包含 Exception 的日志以及其后 10 行
4、 在/home 目录下搜索 mysql.log 的存放目录
5、Linux 服务器上有一个文件 a.log，里面记录了用户的访问日志
7、如何查看 a.log 中 zhangsan 用户昨天的操作日志
五、T 表中有以下数据，写一个 SQL 删除表中姓名重复的数据
6、应用服务器 cpu 高和数据库服务器 cpu 高的分析思路是什么？
测试基础
一、没有需求文档，如何开展测试
1. 没有需求文档不代表没有需求。
2. 可以找相关人员进行沟通，获取需求，比如产品经理、开发人员
3. 可以参考同行业竞品，总结梳理需求
4. 可以根据用户的使用习惯和一些行业的规范，来总结一些功能需求
二、如何提高用例的覆盖率，减少漏测
1、要根据需求文档来编写用例，确保每条需求都被对应的用例覆盖
2、要充分理解业务，挖掘隐形需求，并编写对应的用例
3、除了正常的业务场景，多考虑一些异常的场景和数据
4、要从多个维度对软件进行测试，功能、性能、安全等各方面来考虑
5、多站在用户的角度去思考问题，模拟用户的使用场景
6、组织用例评审
三、在浏览器中输入了一个 url 后，请求流程是什么样的
1、DNS 域名解析
2、与服务器建立 TCP 连接
3、发起 HTTP 请求，发送数据
4、服务器响应 HTTP 请求，返回数据
5、浏览器解析数据、渲染
6、关闭连接
四、说几个常见的 HTTP 请求头字段吧
五、 测试用例里都包含哪些要素？
用例编号、所属模块、用例标题、前置条件、操作步骤、优先级、预期结果等
六、 一个 bug 的生命周期是什么？
1.New：提交新 bug，指派给开发人员进行修改。
2.Open：确认 bug，并且认为需要进行修改，指派给相应的开发人员。
3.Fixed：开发人员进行修改后标识成已修复状态，有待测试人员的回归测试验证。
4.Rejected：如果认为不是 Bug，则拒绝修改。
5.Closed：修改状态的 Bug 经测试人员的回归测试验证通过，则关闭 Bug。
6.Reopen：如果经验证 Bug 仍然存在，则需要重新打开 Bug，开发人员重新修改 。
七、 写一下项目测试流程
需求评审、测试计划、技术评审、用例编写、用例评审、测试执行、测试报告、线上验
证、项目总结
八、 在项目测试过程中，你都测出过哪些类型的 bug？哪些地方最容易出 bug？
bug 的类型：主要是代码逻辑错误、配置错误
哪些地方容易出 bug：参数校验、边界条件、复杂的逻辑、以及一些异常的场景没考虑
周全
九、 fiddler 的工作原理是什么？在项目测试过程中主要在哪些场景下使用？
工作原理：fiddler 主要是在客户端和服务端之间起到了一个代理的作用，启动 fiddler 后，
所有的请求和响应都会经过 fiddler。
应用场景：
1> 判断前后端 bug
2> 抓包进行数据分析
3> 请求断点，主要是测试服务端对客户端提交的非法数据是否进行校验，比如购票数
量为 0，无效的活动时间等
4> 响应断点，
请求断点：主要是测试服务端对客户端提交的非法数据是否进行校验，比如购票数量为
0，无效的活动时间等
响应断点：主要测试服务端返回异常数据后，客户端的处理方式，比如服务端返回 500，
或者某些其他异常业务数据
5> 弱网测试，可以修改fiddler中内置的网络延迟时间，默认是上传300ms和下载150ms，
这两个值越大，网络速率越低
十、 如何查看一个 APP 的错误日志？
a. 查看 APP 的包名
b. 通过报名查看 APP 的进程号
c. 通过进程号，过滤 adb logcat 中的错误日志
十一、 小明在刷抖音时发了一个评论，但是 APP 界面没显示出来，如何排查这个问题？
1. 检查客户端网络是否有问题，可以查看其他 APP 能否正常使用
2. 检查是否为版本问题，可以换个操作系统（安卓、ios），或者换个其他软件版本试试
3. 检查是否为兼容性问题，可以换个手机试试
4. 抓包分析，如果 APP 没有向服务器发送请求，或者请求参数对不对，就是 APP 的问
题；如果服务端响应数据不对，就是服务端的问题
场景题
一、一个接口调不通，该如何去排查原因？
请求不通，可能的原因是：
- ip 或者端口号或者 url 写错了
- 客户端和服务端网络不通
- 服务端项目根本没有部署起来
- 服务器的防火墙拦截了
- 服务端程序内部发生了错误
- 没有访问权限（比如缺乏 token、cookie 之类）
- 客户端设置了网络代理
- 如果是浏览器访问，是不是绑定了错误的
二、上线后出现了 bug 怎么办？
根据之前的一些经验来看，首先和开发一起初步评估 bug 的严重程度和产生原因。
如果是出现了影响面比较大的功能性问题，且暂时不好定位具体原因，首先考虑是做代码回
滚，恢复到上一个稳定版本。然后在测试环境进行复测，并定位问题原因。
如果能快速定位问题原因，开发会做紧急修复，测试通过后会申请紧急上线。
如果是性能方面的问题，一般会进行扩容，或者重启尝试解决，然后开发会做进一步问题定
位和优化。
如果是不太严重的问题，通常会放在下一个版本解决。
最后，线上 bug 解决后，要做问题复盘，将整个过程记录下来并进行相关分析总结，避免后
续出现类似问题。
三、有过漏测导致线上 bug 的经历吗？什么情况下会造成漏测？
基本上我所测试的，没有出现过 P0 和 P1 级别的 BUG。
偶有一些很小的问题，主要的原
因都是兼容性方面。特别是安卓手机，它的碎片化太严重。
那我主要说一下常见的漏测 bug 的原因。
⚫ 需求规格不明确，导致测试用例编写过于粗略。
⚫ 需求规格变更，测试用例未及时更新
⚫ 测试用例覆盖不全面，场景出现遗漏
⚫ 测试过程中未严格按照测试用例执行
⚫ 测试时间不充足，导致一些功能点在测试过程中被忽略
⚫ 测试环境或测试数据受限，导致缺陷漏测
⚫ 开发人员修复其他 bug 时引入的新 BUG
四、如果让你单独负责一个项目，需要注意哪些事项？
1、评估项目的测试范围和测试周期，是否能单独完成。
2、做好测试策略和计划安排，尽量保证每个环节按时完成
3、如果自己解决不了问题，要及时向外抛出，暴露风险，寻求帮助
4、尽量采用一些技术手段，提升测试效率
5、对用例设置好优先级，按照优先级去执行
6、及时对 bug 进行追踪，推动开发尽快解决 bug
7、把控好上线标准，测试报告中标明上线风险
五、工作中如何跟开发保持有效的沟通？
1、就事论事，跟开发沟通时不要携带任何情绪，客观真实的进行沟通
2、不要过渡依赖开发，遇到问题先自己尝试分析下，有一个基本判断后，再去找开发
3、描述问题要简洁、清晰，比如现在在做什么事情，遇到了什么问题，需要开发提供什么
帮助
4、测试要有自己的原则和立场，自己认为是正确的事情，要坚定立场和自我判断，不能完
全听信开发
5、尽量集中式沟通问题，避免碎片化沟通，导致开发工作频频被中断
6、提升自己的技术能力和认知，用更专业的语言和开发沟通
7、遇到非常难沟通的开发，有必要时，要及时向上反馈，寻求帮助
LINUX
1、 给/home/demo.txt 文件设置为所有人可读可写权限
chmod 666 /home/demo.txt
2、 搜索 a.log 文件中包含 Exception 的日志以及其后 10 行
grep -A 10 “Exception” a.log
3、 查看 mysql 进程是否启动成功
ps -ef | grep mysql
4、 在/home 目录下搜索 mysql.log 的存放目录
find /home -name mysql.log
5、Linux 服务器上有一个文件 a.log，里面记录了用户的访问日志
用一个名称统计出访问频率最高的前 3个用户
2022-07-04 11:11:11 zhangsan /index.html 192.168.2.2
2022-07-04 12:11:12 lisi /login 192.168.2.2
2022-07-05 16:11:13 zhangsan /shop/buy 192.168.2.2
2022-07-06 09:11:18 jack /cart/go 192.168.2.2
答案：awk ‘{print $3}’ a.log | sort | unic -c | sort -rn | head -3
6、如何查看 3306 端口号是否被占用
netstat -anp | grep 3306
或
lsof -i 3306
7、如何查看 a.log 中 zhangsan 用户昨天的操作日志
grep ‘zhangsan’ a.log | grep ‘昨天日期’
8、关闭防火墙的命令是什么
systemctl stop firewalld
9、如何统计 a.log 中有多少个 Exception
grep ‘Exception’ a.log | wc -l
10、常用的Linux命令
pwd 显示工作路径
shutdown -h now 关闭系统 /halt 关闭系统
shutdown -r now 重启 / reboot 重启
systemctlstop firewalld 关闭防火墙
ip addr 查看ip地址
SQL 题
部门表 departments（dept_id, dept_name）
员工表 employees（emp_id，emp_name, sex, dept_id, jobs）
薪水表 salary (salary_id, emp_id, money)
一、列出总人数大于 4 的部门编号和该部门人数
select dept_id, count(*) from employees e group by dept_id having count(*)>4
二、列出开发部和测试部的职工号，姓名
select e.emp_id,d.emp_name
from employees e inner join department d on e.dept_id = d.dept_id
where d.dept_name in ('开发部','测试部')
三、显示工资最高的前 3 名职工的职工号和姓名
select e.emp_id, e.emp_name,s.money
from salary s inner join employees e on s.emp_id = e.emp_id
order by s.money desc
limit 3
四、列出工资在 1000-2000 之间的所有职工姓名
select e.empname,s.salary
from salary s
inner join employees e on s.empid = e.empid
where s.salary between 1000 and 2000
五、T 表中有以下数据，写一个 SQL 删除表中姓名重复的数据
| id | name | age | city |
1, 张三, 18, Beijing
2, 李四, 35, Shanghai
3, 张三, 20, Nanjing
4, 王五, 31, Tianjin
答案：delete from T where id not in ( select max(id) from T group by name)
自动化
1、 说一下常用的接口自动化工具/框架
Jmeter、Postman
Requests、pytest、unitest、HTTPClient、testNG、Junit
2、 如何提升自动化脚本的稳定性
a. 避免使用固定的数据，测试用例中使用老的测试数据，可能会被别人修改或删除。
所以每次跑脚本前，在脚本中构造新的数据，跑完脚本后，把数据清理掉。
b. 降低用例之间的耦合性，每个用例尽量都走完整的流程，不要依赖于其他用例，避
免其他用例执行失败，影响了后续的用例。
c. 提升依赖环境的稳定行，通常某些用例会依赖第三方系统的环境，如果第三方环境
不稳定，会造成用例执行的不稳定。可以采用 mock 的形式，屏蔽第三方环境，提
升环境稳定性。
d. 脚本的异常处理，在脚本中要多考虑可能出现的异常，尽量对每种异常都有对应的
处理方法，避免失败后程序退出
3、pytest 里如何进行 case 的组装
1) 默认使用检查以 test_ .py 或**test.py 命名的文件名，在文件内部查找以 test 打头
的方法或函数，并执 行
2) 可以使用自定义 marker（装饰器），比如 pytest 运行的时就只运行带有该 marker
的测试用例
3) 在 pytest.ini 配置文件中可以针对 pytest 执行时的 case 做处理，比如要执行某个目
录下的用例，执行某个脚本文件等等
4、如果一个元素无法定位，你一般会考虑哪些方面的原因
1) 定位器选择错误
2) 定位字符串错误
3) 元素嵌套在 frame 当中
4) 页面元素没有及时加载
5) 元素在新窗口中
6) 脚本流程与实际不符
7) 元素不在当前页
性能
1、 性能测试常见的指标有哪些
a) tps：每秒事务量，代表了系统的处理能力，tps 越高，性能越好
b) 响应时间：从发出请求到接受到系统响应数据所花费的时间，响应时间越短，性能
越好
c) 吞吐量：网络上行和下行流量的总和，吞吐量是网络瓶颈定位的重要指标
d) 错误率：在压测过程中系统出现错误的比例
e) 操作系统：CPU、内存、网络、磁盘
2、 TPS 比较低，可能是什么原因造成的？
a)压力机本身性能瓶颈
b)网络 IO 瓶颈
c)中间件（tomcat/nginx/mysql）连接数限制
b)应用程序：内存、线程的阻塞、等待
e)数据库性能问题
f)本系统资源的瓶颈（cpu、内存、磁盘、网络等）
g)其他外部系统响应时间过长，造成本系统的 time-wait
3、如何保证自动化测试的稳定性
1. 避免使用固定的数据，测试用例中使用老的测试数据，可能会被别人修改或删除。所以
每次跑脚本前，在脚本中构造新的数据，跑完脚本后，把数据清理掉。
2. 降低用例之间的耦合性，每个用例尽量都走完整的流程，不要依赖于其他用例，避免其
他用例执行失败，影响了后续的用例。
3. 提升依赖环境的稳定行，通常某些用例会依赖第三方系统的环境，如果第三方环境不稳
定，会造成用例执行的不稳定。可以采用 mock 的形式，屏蔽第三方环境，提升环境稳
定性。
4. 脚本的异常处理，在脚本中要多考虑可能出现的异常，尽量对每种异常都有对应的处理
方法，避免失败后程序退出
4、压测时 tps 压不上去，可能有哪些方面的原因
a) 压力机本身性能瓶颈
b) 网络 IO 瓶颈
c) 中间件（tomcat/nginx/mysql）连接数限制
b) 线程的阻塞、等待
e) 数据库性能问题
f) 本系统资源的瓶颈（cpu、内存、磁盘、网络等）
g) 其他外部系统响应时间过长，造成本系统的 time- wait
5、如何设计性能测试场景
一般基本的场景包括：基准测试、单交易测试、混合测试、稳定性测试。
基准测试，使用 1 个用户或者基准用户数，运行几分钟 单场景测试，并发用户逐渐递增到预估值情况下，运行 10 分钟。
混合场景测试，多种交易设置不同并发用户占比的情况下，运行 30 分钟。
稳定性测试，选择混合测试支持最大并发用户数的 80%，运行 12 小时
6、应用服务器 cpu 高和数据库服务器 cpu 高的分析思路是什么？
1) 应用服务器的 cpu 高，先要看 tps 和响应时间，如果 tps 比较高，我们认为是正常的 cpu
消耗；如果 tps 比较低，那么往往某些代码过于消耗 cpu，可以考虑使用代码剖析工具
分析下
2) 数据库服务器 cpu 高，往往是因为 sql 语句执行效率比较低，可以通过对数据库慢查询
是监控，结合执行计划进行分析，是否是相关表没有索引或索引未生效
接口
一、为什么要做接口测试
A、在公司里，客户端和服务端通常是由不同的团队开发的，在项目开发过程中，客户
端和服务端开发的进度不一致，比如服务端先开发完了，这个时候可以先对服务端进行
接口测试，确保服务端逻辑和返回数据是正确的，然后再测试客户端。另外某些测试部
门，专门测试服务端开发团队，因此，他们的测试对象就是接口。
B、在测试某些业务时，不能仅仅通过前端来测试，比如用户注册，前端限制了用户名
不能为空，但是有些人可能通过工具绕过前端直接调用服务端接口，如果服务端没有做
相关的逻辑判断，就会造成数据错误。包括接口数据传输过程中是否对关键信息加密等。
所以必须针对服务端接口单独做测试。
C、
在开发提测后，可以先通过工具把服务端的接口测试跑一遍，确保接口测试用例都
是通过的，快速判断服务端接口是否符合预期。然后再通过 UI 界面进行测试。否则接
口有 bug，前端页面必定有 bug。
二、接口测试的关注点有哪些
1）入参，包括参数合法性，参数校验，参数边界、参数为空、缺少参数等
2）返回值，包括各种情况下的响应内容是否正常
3）接口业务逻辑和功能是否正常
4）数据库校验
5）性能测试（接口 tps、响应时间等）
6）安全性，敏感信息加密，权限控制等
7）幂等性
三、get 和 post 的区别是什么
1) get 请求的参数是放在 url 里，post 请求参数是在请求体里 2) get 请求可以被浏览器缓存，post 请求不能被缓存
3) get 请求参数放在 url 里，url 的长度是受限的，而 post 接口长度没有限制
4) get 请求参数放在 url 里，安全性比较差；post 请求参数放在 body 中，安全性相
对较好
5) get 请求可以直接通过浏览器访问，支持刷新和后退。post 请求不能直接使用浏览
器访问，刷新后数据要 重新发送。
四、接口测试和 web 页面测试有什么区别？
1) Web 页面测试是通过界面操作来进行测试的，输入不同的数据来测试不同的场景。
2) 接口测试是使用工具直接像服务器发送 HTTP 请求去测试，输入不同的参数来测试不同
的场景。
3) 通常 web 页面会限制某些输入数据，比如必填项、数据的格式等。而接口测试是可以
输入任何数据的，可以测试更多的异常数据场景。
4) Web 测试需要考虑浏览器的兼容，接口测试不需要
5) Web 测试需要将前端，服务端全部开发好后 才可以进行测试，接口测试只要服务端开
发完成，就可以开始测试
