字节面试题
1、重点：抖音的点赞和评论功能，抖音刷视频页面，设计测试用例；（尽量说的全面一点，这个会影响面试结果）
2、数据库查询的一个题；
3、Linux和adb命令；
比如查看日志的时候，我们可以使用cat、less、more，查看前10行head，查看后10行tail，实时追踪查看tail -f，因为实时追踪时，前端页面操作太多的话，日志太多会看不清，也会使用grep过滤关键字，过滤error或exception异常信息，查看某特定区间时间段的日志也可以使用sed -n时间1，时间2p 文件路径，还有搭建环境也会使用到rz、sz上传和下载，unzip，tar -xf解压命令，性能测试也会使用htop命令监控服务器状态，ps -ef查看进程，nestat -anpt查看端口号，还有一些基本的文件创建touch，目录创建mkdir等等
adb devices查看设备号，adb push上传，adb pull下载，还有adb install安装，adb shell pm uninstall卸载，包括adb monkey做安卓机的健壮性测试等
4、抓包工具的使用；
抓包工具的话如果是小程序的包我会使用Charles，如果是web端的话我这边会使用F12开发者工具来抓包，fiddler也有了解，用的稍微少一些，因为fiddler不会对同一个域名进行整合，只有在已知ip的情况下，可能会使用fiddler。
5、视频播放卡顿，是什么原因导致的；
可能是网络原因，
6、发布前出现bug，怎么解决；
发现bug一定是以解决bug为主的，先分析bug的严重程度
严重bug，影响整个系统运行的，停下所有一切工作紧急修复，修复后再上线；
如果只是影响个别功能模块的使用，看着不着急发版，如果急于发版，可以将个别功能模块关闭，修复后进行热更新处理；
如果一般性建议bug可以留到下一版本进行迭代
7、Python的数据类型；
字符串，int，元组，列表，集合，字典，布尔，空值
8、fiddler限速怎么限，断点的作用；Fiddler 抓包判断 缺陷方法，弱网等使用
fiddler链接手机
fiddler怎么抓取https的一个包
首先要安装
9、重点会问项目：需要对自己的项目有个深入的了解；
10、印象深刻的bug
11、客户端的bug比服务器的bug多很多是什么情况？
具体看项目是什么类型
--如果项目是以渲染为主，兼容为主，大量的运算都交给前端来做的话，那这种情况前端bug可能要远多于后端bug，比如office365、wps网页版、线上ps等；
--如果是各有承载型，比如ERP、线上办公、OA系统、远程教育都是属于各有承载型，这种项目前后端bug基本差不多；
--如果前端只做渲染的，比如百度、谷歌的海量广告投放基本都是后端运算后的精准投放，那么就是后端bug比较多。
12、Http常见状态码
100 继续请求服务器
200 请求成功
301 永久重定向
302 临时重定向
400 请求报文出错
401 请求header出错
403 鉴权访问
404 not found文件未找到
500 服务器内部错误
502 无效网关
13、能简单讲讲你是怎么做性能测试的吗
14、DNS是什么有接触过吗
没怎么接触过，大概听过，是一个服务是吗？就是将域名解析为IP的一个服务
15、比如说我现在有接到一个需求，类似于像 QQ 音乐那个下载音乐的功能，需要你进行用例设计
UI界面：下载按钮的排版、样式、颜色是否符合需求文档
不同网络下载：WIFI,5G，4G,3G,2G,弱网，断网的情况是否下载成功
中断测试：下载中断后能否继续下载，比如下载过程中突然来了一个电话
继续下载是否有已下载提醒
兼容：
16、比如说我收到一条微信消息，然后我在那个锁屏的时候点了以后，点击了那条消息。然后我解锁屏幕，
但是它没有正确的跳到 App 里面。你觉得这样可能的问题是什么？
17、音乐软件进度条的测试用例（重点）
因为进度条测试肯定会结合下面的播放按钮一起来测的嘛
UI界面 进度条的排版、布局、样式、颜色是否符合需求<br /> 进度条下面的显示时间是否正确，比如3:40秒的音乐，下面应该正确显示0:00-3:40<br /> 功能 进度条是否支持左、右拖拽，音乐也会停留在正确的时间点进行播放<br /> 点击播放按钮，进度条会随着音乐的播放而移动，并且从浅灰色显示为黑色<br /> 点击暂停按钮，进度条也随之暂停<br /> 播放过程中，左边显示正确的已播放时长<br /> 进度条播放到最后是否会跳转下一首歌<br /> 中断 播放过程中突然来电话，是否会自动暂停，电话结束是否可以继续播放<br /> 播放过程中微信语音视频，播放是否会暂停，语音结束是否会继续播放<br /> 播放过程中切换页面是否会在后台自己播放<br /> 播放过程中右微信消息、短信消息是否影响播放<br /> 兼容 不同的Android机型、不同的Android版本进度条显示是否一样<br /> 不同的IOS手机机型版本显示是否正常<br /> 不同的操作系统Windows7-11，Mac是否正确显示<br /> 是否支持PC端的快捷键，比如空格键暂停和继续播放这样<br /> 网络 不同的网络WIFI,5G,4G,3G,2G,无网情况下是否播放正常，进度条显示正确<br /> 暂时就想到这么多<br /> <br />18、iOS怎么查看日志<br />--Mac电脑自带的控制台可以查看日志，只需要将iphone手机通过手机连接电脑就好了；<br />--Mac电脑可以安装一个Xcode软件，通过devices界面选择view device logs就可以了，前提也要通过数据线手机连电脑；<br />--Windows电脑可以安装itools软件，通过数据线将IOS手机连入电脑，19、Charles抓包工具断点操作
20、列表和元祖的区别
列表可变，元组不可变，相同点都是可以通过索引值找到对应的值
面试温馨提示：
1、有碰见不会的要有话术 ，说自己之前没怎么深入接触，但是愿意学习相信能很快上手
2、面试千万不要崩， 不会就说不会， 脑子要清醒
3、中途不能查阅任何资料
4、面试前2分钟调试好会议室，不能迟到哦~
mentor导师
前端开发语言：HTML+CSS+JavaScript
后端开发语音：Java
git init初始化仓库
git add提交
git commit
git push上传
git pull下载
面试流程和技术方向：
1、介绍一下业务流程？
2、自动化测试的情况（不会的就说不会）
目前可以使用JMeter做单接口的参数化，串联接口的上下游传参，以及使用JMeter中JDBC连接数据库的操作
3、自动化测试总共写过多少个case
这个没有一个标准数字啊，功能的case要写的话一天一百多吧，业务逻辑的case一天50个左右吧，还真不好说，也没有天天写case这样
4、对java和python哪个更熟一些？
python吧，目前也是自学中，暂时掌握的比如python的基本数据类型，循环，以及requests库和pytest库有了解，其他方面目前还在学习中。
5、你目前的薪资是多少？
14K这样
6、你离职的主要原因是什么？
上一个项目结束了嘛，然后下一个项目是要外派到外地这样，所以看看新的机会
7、测试用例的设计方有哪些？
让我设计测试用例，首先常用的有比如：等价类、边界值、流程分析法、正交实验法、错误推测法等
8、需求上线的上线质量你关注吗？
关注的，我们公司产品上线都是产品、开发、测试都会在场的，上线之后，需要我们测试对上线的功能做一下基本的回归，点一点看一看新增的功能能不能正常使用，差不多是这样，然后再出一份测试报告交给上级leader。
9、预防线上出问题的措施？
10、兼容性测试/适配测试的策略和覆盖机型
11、熟悉的工具有哪些？接口测试工具？
Xshell连接服务器，Navicat连接数据库，bug管理工具，禅道，jira都有使用过，postman，JMeter做接口测试，抓包工具Charles，F12开发者工具都有使用
12、jmeter工具的使用的一些步骤？
添加线程组，线程组上添加HTTP请求，请求中输入对应的协议，ip，端口号，请求方式，请求地址，encoding Utf8，请求体的content type有三种，application/json,表单格式，form data格式，添加信息头管理器，单接口参数化添加CSV配置元件，多接口使用json提取器，jmespath提取器，正则表达式提取器，提取出变量在下游接口使用${}引用变量，针对服务器返回的结果添加对应的断言，文本断言，json值断言，jmespath断言，最后添加查看结果树查看运行结果，或者断言结果看断言结果，压测可以添加聚合报告，还有固定定时器模拟真实用户等待时间，还有使用JDBC连接数据库
13、如果和开发发生了分歧，你该如何做？
14、平时在和大家沟通的时候，你的缺点和优点都说一个？
缺点没有别人的天生聪明机智，优点是自己一直坚持一个空杯心态，愿意不断的学习，哪怕是自己知道的领域，也愿意去跟别人虚心交流，就像孔子论语中说的，三人行必有我师嘛，每个人都有值得我去学习的优点。
14、之前工作中遇到的难点是什么？
还有就是在工作中我觉得不管遇到什么问题，没有沟通解决不好的事情，解决不了要么就是沟通没沟通好，比如用户更改需求，然后也没有第一时间通知我们测试这边，开发提测后我们发现问题，找到开发，开发说不是问题，用户需求变更了，然后我们又要找用户这边去确认需求，然后用户说要么就是自己没有放下心态去好好学习，就像我儿子天天看那个动画片汪汪队，我也是这么鼓励我儿子的，没有绝对的困难，只有勇敢的狗狗啊。
15、如果人家提出的改进建议你该怎么办？
16、内存溢出和内存泄露
17、爱奇艺方向的场景写测试用例：看广告观看6分钟，开通会员，开通会员可以下载和观看
微信发红包：个人
1.sed 在1.txt 文件中 hello 替换成hi；
sed ‘s/hello/hi/1 hello.txt
2.bug 的严重程度；
- 致命问题（eg:系统崩溃、死机）
- 严重问题（eg:系统主要功能部分丧失、但不影响其他功能的测试）
- 一般性问题（eg:功能没有完全实现，但不影响使用）
- 建议问题（eg:界面性能缺陷等建议问题，不影响操作功能的执行）
3.发现一个Bug，开发不认同怎么处理；
你再需求测试中，时间不够，进度不符合预期怎么处理；
首先将时间被压缩的风险上报测试经理，因为测试时间被压缩测试覆盖范围会不全，由测试经理出面沟通，看是否可以延迟上线：
A.如果可以延迟上线，就按照正常的测试计划执行
B.如果不可以延迟，那么看测试经理是否可以增加人力或者加班完成
C.又不可以延迟、又不可以增加人力，那么就按照模块优先级划分去执行优先级高的模块，一些优先级低的模块放入下一个迭代版本，或者按照测试用例的优先级去执行，优先级低的案例可暂不执行，放入下一个迭代版本执行
4.抓包使用工具，怎么抓取https请求；
由于fiddler安装后默认只能抓取http请求，如果需要抓取https请求需要进行配置。配置方式：
Tools--->Options--->HTTPS，勾选CaptureHTTPS CONNECTs、Decrypt HTTPS traffic 、ignore server certificate errors(unsafe)，点击OK，会弹出证书直接确认即可。
5.自动化有没有学过；
6.登录功能，输入账号密码，点击登陆没有反应，怎么排查；
抓包，定位前后端问题，查看日志，看数据库；
7.测试的流程；
首先会召开需求分析会议，参加人员有产品、开发和测试，主要是探讨需求主要的一些功能点；然后开发就排期进行开发，主管开始编写测试计划，对我们进行任务分配。
我们参考需求规格说明书及原型图编写测试用例，写完之后会进行用例评审，有评审修改的就修改整理形成最终的用例版本；开发人员版本编译完成后，我们会先进行预测，主要对主功能业务进行测试，如果主业务流程不通过，直接返回给开发进行修改。预测通过，依据测试用例进行系统测试。测试过程中，提交 bug，跟踪 bug，进行回归测试直至不存在严重 bug，满足用户需求，测试完后编写测试报告；产品发布上线后，关注 web 是否正常运行，要进行常规的维护性测试。
8.有没有其他的测试环境；
测试环境和预发布环境
9.预发布环境与真实环境的区别；
数据更加贴近生产环境
10.数据库表和预发布环境的数据使用的是一样的吗；
不是，数据更加贴近生产环境
11.微信收发红包测试点。
1.功能
①红包钱数精度为两位小数，直接输入小数点会不会自动补0，当输入钱数为0时，“塞钱进红包”置为灰色
②红包输入的前述超过最大钱数时是否会有提示
③红包描述可以输入正常字符，是否可以输入数字，汉字，英文，表情，检查他们是否可以任意搭配，各种字符最多的限制是多少，在输入后，是否可以进行修改
④红包的金额数字，描述是否可以复制粘贴
⑤点击塞钱进红包是否可以跳出支付界面
⑥是否可以选择支付方式，余额不足的时候会不会自动匹配
⑦是否支持密码和指纹支付
密码输入错误是否会提示，指纹验证错误是否会提示
以上操作是否能够中断并且返回
输入正确是否会发送成功，跳转到聊天界面
⑧转到聊天界面后是否会看到红包
⑨24个小时没有被领取，是否会返回金额到原来的账户
⑩私发的红包在被领取后，在聊天界面是否会有提示
20.可不可以自己选择支付方式
21.余额不足时，会不会自动匹配支付方式
22.在发红包界面能否看到以前的收发红包的记录
23.红包记录里的信息与实际收发红包记录是否匹配
24.支付时可以密码支付也可以指纹支付
25.如果直接输入小数点，那么小数点之前应该有个0
26.支付成功后，退回聊天界面
27.发红包金额和收到的红包金额应该匹配
28.是否可以连续多次发红包
29.输入钱数为0，"塞钱进红包"置灰
兼容
苹果，安卓是否都可以发送红包
2.电脑端可以抢微信红包安全
1.对方微信号异地登录，是否会有提醒 2人
2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加
3.发送红包失败，余额和银行卡里的钱数不会少
4.红包发送成功，是否会收到微信支付的通知输入密码是否可见 支付大额是否限额提醒 发红包是否有到账时间 发错是否可以申诉追回 支付过程接口请求要加密 是否有二次确认发送红包和抢红包的时候抓包，请求会加密，不应该抓到对应的包以及或者抓到应该加密。
界面
1.发红包界面没有错别字 2.抢完红包界面没有错别字 3.发红包和收红包界面排版合理， 4.发红包和收到红包界面颜色搭配合理
扫码支付怎么
兼容性
总结：不同台 ios 安卓 PC
1.iOS和安卓是否都可以发送红包
2.电脑端是否可以抢微信红包
界面测试
总结：错别字，排版，颜色
1.发红包界面没有错别字
2.发红包和收红包界面排版合理
3.发红包和收红包界面颜色搭配合理
安全测试
总结：异地登陆，收发双方金额，通知
1.对方微信号异地登录，是否会有提醒
2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加
3.发送红包失败，余额和银行卡里的钱数不会少
4.红包发送成功，是否会收到微信支付的通知
易用性测试
总结：指纹支付，语音输入
1.红包描述，可以通过语音输入
2.支付方式可以为指纹支付也可以为密码支付
微信发红包的测试用例点
单个好友发红包
1.金额为0时 红包按钮呈现灰色 无法点击
2.单个金额不能超过最大金额200
3.留言为空时 默认输入恭喜发财，大吉大利
4.留言字数在0–25之间
5.发送时可选择动画表情，不选择默认为空
6.红包封面可以用户自行选择
7.输入密码错误时最多可以尝试三次，超过三次提示认证身份信息
8.支付时零钱余额不足 提示更换支付方式
9.零钱与银行卡余额都不够时红包发送失败
10.发出去的红包自己不能领取
11.发出去超过24小时的红包没有被领取自动退回原支付途径
群聊发红包
1.金额为0时，红包按钮呈现灰色 无法点击
2.红包个数最多可发送100个
3.专属红包可在群聊中指定某人领取，其他人无法领取
4.拼手气红包每个人领取金额不同但总金额等于发出红包金额
5.普通红包发出的每个金额都相同
6.发出的红包自己也可以领取
7.留言为空时 默认输入恭喜发财，大吉大利
8.留言字数在0–25之间
9.发送时可选择动画表情，不选择默认为空
10.红包封面可以用户自行选择
11.输入密码错误时最多可以尝试三次，超过三次提示认证身份信息
12.支付时零钱余额不足 提示更换支付方式
13.零钱与银行卡余额都不够时红包发送失败
14.发出超过24小时剩余未被领取的金额自动退回原支付途径
APP 与 web 测试区别
- 系统层面
APP 属于 C/S 架构,WEB 属于 B/S 架构
2. 下载安装层面
a. APP 需要通过应用市场下载的，需要用户主动下载的
b. WEB 是代码部署到服务器上，就会自动更新，无需用户主动下载
3. 测试层面
a. APP
1) 兼容性（手机系统 Android 和 IOS，手机型号不同 OPPO、华为、VIVO
等，iPhone X、iPhone 6 等）
2) 干扰测试（来电中断、系统推送、关机重启等）
3) 手势（横竖屏幕切换、前后台切换）
4) 安全与权限
5) 功能测试
6) 界面样式和 URL 地址
b. WEB 测试
1) 功能测试
2) 界面样式和 URL 地址
3) 兼容性测试（谷歌浏览器、火狐浏览器、IE 等）
4. 测试便捷性
a. WEB 测试比较便捷，可以用开发者工具 F12 查看前后端数据交互
b. APP 借助于第三方抓包工具，看到前后端数据交互
水杯的测试点
功能性：
1、水装到规定的安全线看是否会漏水
2、水超过安全线，观察杯子是否会变形
3、水装满且溢出，看是否对杯子产生什么影响，比如变形之类的
4、是否有刻度线
5、刻度线是否标的准确
6、盖子拧紧水是否会流出
7、是否隔热，能装多少度的水不会烫手
8、是否可以折叠（运动杯），防滑
9、是否可以装入一些饮料，牛奶之类（防腐蚀功能）
10，能否显示水的温度（测温功能）
11、材质是否安全（加热水会不会产生有害物质），
12、有误异味
13、保不保温，（保冷），可以保温多久
14、掉不掉色
15、防摔的能力（一摔就变形等）
16、可不可以进行加热（热水中加热等）
17、保质期
18、有无滤网（泡茶的时候）
19、是否方便清洁
20、是否带有习惯
21、晃动会不会漏水
界面
1、外观是否完整美观
2、大小与设计（说明书）是否一致 高，宽，容量，直径等
3、材质与（说明书）一致
4、形状，有无把手
5、颜色
易用性：
1，倒水是否方便
2，是否符合人体力学的设计（拿着是否舒服）
3、杯口设计是否方便喝水
4、杯身沾水后，是否防滑
5、使用简单，操作方便
6、是否有手提绳
兼容性：
是否可以装入一些饮料，牛奶，醋，油等之类（防腐蚀功能）
性能：
1、保温时长
2、杯子的耐热性
3、杯子的耐寒性
4、侧放或者倒放会不会漏水
5、抗压性，被子上放重物到什么 程度杯子会变形
安全性：
1、材质是否安全
2、加热水会不会产生有害物质
3，加热醋等之类的会不会产生化学反应
4、低温材质释放毒性
5、是否会发生爆炸（只能杯里的电池）
震动测试：
加填充物是否便于运输
ios和Android推送方式
前言 iOS和Android上的实时消息推送差异很大，往小了说是技术实现的差异，往大了说是系统实现理念的不同。实时消息推送在移动端互联网时代很平常，也很重要，它的存在让智能终端真正成为全时信息传播的工具。本文将从原理上谈谈两个平台上实时消息推送的区别。
简要对比
iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。你的例子里面，腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。
Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。
技术原理
首先讲解下服务器如何先找到设备、再找到app的问题。
每一个设备都有一个自己的设备号，而设备中的app又都有一个唯一的包名。所以服务器只需要找到设备号与包名就可以定位到某个设备的某个应用，而这设备号与包名会一起构成一个标识符，叫做device_token，因此问题就简化为把device_token与消息内容等信息交给服务器，服务器把内容发到唯一的device_token上。这就好像你在上海要通过顺丰寄送一个快件儿给某某小区的某某房间，那么快件儿首先会邮递到顺丰公司在北京的总站点，之后再根据小区的地址投递/路由到某某房间，这样一个寄件过程就算完成了。
iOS 实时消息推送
iOS的推送是通过苹果自己的APNs服务进行的，用户需要将device_token以及消息内容等推送信息交给APNs服务器，剩下的均由苹果自己来完成。iOS应用的推送大部分情况下都要依赖苹果生态提供的APNs（Apple Push Notification Service）服务。
https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/db29e6a729147172d199cde6e2cf3682_hd.png
首先作为设备标识的device-token是由APNs颁发的，App开发者或者第三方推送平台(图中的Provider)做的工作是收集这个device-token，APNs的推送是要求基于APNs颁发的device-token来推送的。只有正确的device-token会被APNs接受，如果是一个错误的、或者无效的device-token(比如App已经卸载了)，APNs就不会接受。
接着开发者使用第三方推送平台（图中的Provider）在将推送内容与范围选定之后进行推送，第三方推送平台将信息提交给APNs，剩下的操作全部都由APNs来进行完成，整个过程第三方推送平台就不能控制了。但是如果提供的device_token是失效的（app被卸载、系统版本升级导致device_token变化等情况）那么推送过程就会被中断，频繁的断线重连甚至会被APNs认为是一直DoS攻击。（详情可以参考为什么苹果的推送，两次推送之间间隔比较久的话，第二次推送会很慢？）
Android 实时消息推送
Android平台在不使用GCM的情况下就需要将自己的服务器或是第三方推送服务提供商的服务器与设备建立一条长连接，通过长连接进行推送。但是不建议自己设置服务器实现推送功能，一是因为成本太高（开发成本、维护成本），自己搭建的服务器无论是稳定性还是速度上都比不了第三方推送服务提供商的效果。另一个是因为自己的数据量较小，使用第三方推送服务提供商可以用他们的维度进行推送，实现精准推送。友盟推送就是做的比较好的，可以根据用户分群、地区、语言等多维度进行推送，最大程度减少对于用户的干扰，仅把消息推送给相关用户。
开发者通过第三方推送服务提供商将信息直接下发给需要的设备，第三方推送服务提供商与设备建立一条长连接通道，并且将消息路由到APP中（图中的设备1与设备2），对于像设备3这种无网络连接或是没有成功建立长连接通道的设备，会在设备3连网且推送消息没有过期的情况下自动收到由第三方推送服务提供商推送过来的消息，保证消息不会丢失。
实现上的差异所带来的直观感受
iOS的实时消息推送
iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。
所以 iOS 的推送可以不严谨的理解为：
苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。
然后，系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事
然后，系统分别通知这些 Apps 。
带来的好处是不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）。
Android的实时消息推送
Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。），大家挂后台等待推送就成为技术选择。当然， Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。
用户的电池？ Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。而 Google 不强制的结果就是：没人真正为用户的电池负责。
但是， Google 的方案也并非全是悲剧：也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。