头条面试题总结
内面-技术
1简单做一下自我介绍(150字左右)
参考答案：
自己说吧
2简要介绍一下项目/你负责的模块/选一个模块说一下功能点
参考答案：
比如说注册模块
功能点包括输入数据
注册按钮
重置按钮
纠错功能
不成功的说明
注册成功之后的跳转
3有一张学生表，查询80~90分之间的同学，写语句
参考答案：
select *
from student
where grade between 80 and 90
4微信发朋友圈测试用例
参考答案：
功能测试
1、朋友圈发送功能
1）只发送文本
a、考虑文本长度：1-1500字符（该数据为百度数据）、超出最大字符长度
b、考虑文本类型：纯中文、纯数字、纯字母、纯字符、纯表情（微信表情/手机自带表情）、混合类型、包含url链接；因为过长纯类型需要换行很容易出现超出边框问题，所以这里先考虑过长纯类型情况
c、文本是否支持复制粘贴
d、为空验证
2）只发送图片
a、本地相册选择/拍摄
b、图片数量验证：1-9张图片、超出9张
c、图片格式验证：常见图片格式jpg、png（以实际微信需求支持的格式为准）、动态gif图片、不支持的图片格式
d、图片尺寸验证：最大700*800像素(此为百度数据)、超出最大尺寸范围是否压缩
e、图片大小验证：1-300kb（此为百度数据）、超出300kb
f、图片的预览验证：点击支持预览大图、多张图片支持左右滑动预览
g、图片的增删改操作
h、为空验证
3）只发送视频
a、本地相册选择/拍摄
b、视频秒数验证：1-10s，超出10s
c、视频个数验证：1个，超出1个
d、视频格式验证：支持的视频格式，例mp4、不支持的视频格式
e、视频大小验证：苹果400kb以内、Android200-300kb（此为百度数据）、超出规定大小
f、视频预览增删改操作
g、为空验证
4）发送文本 图片：输入满足要求的文本、图片进行一次验证
5）发送文本 视频：输入满足要求的文本、视频进行一次验证
6）发送图片 视频：不支持发送
7）朋友圈发送内容是否有限制，例如涉及黄赌毒等敏感字
8）所在位置
a、不显示位置：发送到朋友圈动态不显示位置
b、选择对应位置：搜索支持、自动定位、手动编辑
C、点击取消，返回上一级页面
9）谁可以看
a、设置公开：所有朋友可见
b、设置私密（仅自己可见）：自己查看朋友圈-可见、好友查看朋友圈-不可见
c、设置部分可见（部分朋友可见）：选择的部分好友-可见、不被选择的好友-不可见、是否有人数上限
d、设置不给谁看（选中的朋友不可见）：不被选中的朋友-可见、被选中的朋友-不可见、是否有人数上限
e、点击取消，返回发送页面
10）提醒谁看
a、提醒单人/提醒多人：被提醒的朋友-收到消息提醒、未被提醒-未有消息提醒
b、是否有人数上限
c、点击取消，返回发送页面
11）同步QQ空间：默认不同步、同步到QQ空间
12）取消发送朋友圈操作
a、选择相机，点击取消，返回朋友圈页面
b、进入朋友圈发送页面，选择文本图片，点击取消
13）朋友圈当天发送次数是否有上限限制
2、朋友圈浏览功能
1）文本查看：
a、过长文本内容是否隐藏，并支持查看全文
b、右键选择复制、收藏、翻译
c、url链接是否支持点击跳转网页
2）图片查看
a、小图右键支持收藏/编辑
b、点击支持大图浏览
c、选择发送给朋友、收藏、保存图片、编辑
d、多张图片支持左右滑动浏览
3）视频查看
a、右键视频支持静音播放/搜藏
b、点击视频播放按键支持播放视频
c、选择发送给朋友、收藏、保存视频、编辑
4）分享动态浏览：QQ空间/公众号文章/非腾讯产品分享后朋友圈是否正常显示
5）赞：点赞、取消点赞
6）评论
a、评论长度：评论字数合理长度、评论超过字数上限
b、评论类型：纯中文、纯数字、纯字母、纯字符、纯表情（微信表情/手机自带表情）、混合类型、包含url链接；
c、评论是否支持复制粘贴
d、为空验证
e、发表评论后删除
f、评论回复操作
7）删除朋友圈动态
8）更换相册封面
9）刷新是否正常获取新动态
10）上滑是否加载更多
界面/易用性测试
1、技术人员角度：页面布局设计是否跟产品原型图/ui效果图一致
2、但除了考虑1之外，我们同样要考虑到用户使用：功能操作是否简便，页面布局排版风格是否美观合理，提示语相关信息是否易于理解
中断测试
1、主要考虑：a)核心功能 b)当前功能存在实时数据交换，例发朋友圈、浏览朋友圈进行中断，是否容易出现崩溃
2、中断包括：前后台切换、锁屏解锁、断网重连、app切换、来电话/来短信中断、插拔耳机线/数据线
网络测试
1、三大运营商不同网络制式测试
2、网络切换测试：WIFI/4G/3G/2G
3、无网测试：对于缓存在本地的数据，部分朋友圈信息是否支持浏览
4、弱网测试：
a、延时：页面响应时间是否可接受、不同网络制式是否区分超时时长、出现请求超时，是否给予相应的提示
b、丢包：有无超时重连机制、如果未响应，是否给予相应提示
c、页面呈现的完整性验证
兼容性测试
1、Android手机端、苹果手机端、pad版（主流）功能界面显示是否正常
2、各平台朋友圈展示数据是否一致
安全测试
发送朋友圈时，文本输入脚本代码，是否出现异常
性能测试
1、服务器性能测试
可通过loadrunner/jmeter工具实现，主要关注TPS、响应时间、吞吐量、CPU、内存等
2、app客户端性能测试
可通过GT工具实现，运行时关注cpu、内存、流量、电量等占用率
3、app压力稳定性测试
通过monkey工具实现，频繁发送朋友圈，浏览朋友圈请求，是否容易发生崩溃
5说一下直播打赏功能的测试点
参考答案：
1、业务层，打赏即金融类的交易，既然跟钱有关系，那么会有这些情况：
1）支付超时，即你支付一笔订单因各种原因服务器创建订单超时，系统是如何处理的，是一直排队等待还是超过多少秒按照交易失败处理还是异步处理，不同的处理方式会有不同的结果，如果代码里没做这些判断就会保存或者前端无响应；
2）回调超时，即服务器创建订单成功后，会将这些订单信息以报文的形式发送至第三方支付平台处理，那么就会产生第三方平台因为种种原因迟迟没有尽快给服务器响应就会造成回调超时。回调超时就会交易失败，交易失败的话，我们的代码也是要进行判断，是超过多少秒重新发送报文呢，发几次，也就是有没有重发机制，如果没有重发机制又是如何判断的，是判定失败还是成功还是退款，然后订单如何标识，如果这些代码逻辑没有写清楚，就会报错；
3）退款，退款又分为退款成功，退款失败，退款超时。退款成功就是钱是怎么扣掉的然后原路返回；退款失败的话系统如何处理，是人工退款还是系统批处理退款还是隔日退款，这些都不一样；再就是退款超时，是否有重发机制，以及对应的逻辑处理。
2 数据层，一般做交易类的业务，数据库的表结构会比较复杂，相关的字段也比较多，例如通常要关注：一个打赏动作完成后，打赏的商品表，订单表，退款表，日统计表，月统计表，年统计表，或者其他的数据分析类的统计表，如果跟财务系统有挂钩的话可能还要去看一下会计科目是否都有正常的更新，金额正常增加或者回退，重要业务字段正确的更新流转。具体还要看公司的业务体量业务形态以及用户量的大小，底层的数据结构会业务量的扩大会不断的增加，越来越复杂最后数据量大了，可能还要涉及分表分库，业务重构系统重构等等。
3、性能方面，例如快手这样的，一个直播间，如果人数达到 10 万➕，那可能会产生并发，同时有很多人调用打赏接口，查询接口等，那就要去做一个并发测试，做之前可能先要去做一下生产数据采集，看看一个月或者三个月，找到业务峰值大概是多少，算出 TPS，然后对高频繁调用的接口做一个并发测试，逐步增加 UV，看看系统各指标的瓶颈在哪里，然后再分析结果，自己能定位瓶颈的原因并给出解决方案更好，否则给出对应的报错结果让开发去处理即可。这里可能不止并发一个性能问题，其他的就不展开说了，实际场景可能不是太大问题，把并发处理好就行。
6说一下支付功能的测试点
参考答案：
支付金额
1.小于最小值，如：小于0.01
2.大于最大值/金额上限
3.无实际意义金额，如0元
4.格式错误（负数、非数字）
5.余额小于实际需要支付的金额
6.超过第三方支付接口当日消费/单笔消费金额
支付接口
第三方接口，微信/支付宝/网银系统/post机终端服务
支付操作
1.指纹支付
2.免密支付
3.账号 密码支付
4.动态获取支付验证码支付
5.银行卡密支付
6.信用卡支付码
异常处理
1.退款处理
2.支付数据交换时中断（断电、断网、弱网），重新启动能否再支付
3.支付失败后如何处理
4.支付金额不足时，充值后可否继续支付
5.持续点击
6.多次扣款如何处理退款
7.取消支付/取消支付后再次支付
8.第三方支付未登录时支付
兼容性
PC/笔记本/平板/手机端支付
后台处理订单
1.成功订单财务处理
2.失败订单财务处理
3.退款订单财务处理
4.差错账单如何处理等
技术一面
1Linux 在项目中什么场景用到了
参考答案：
网卡驱动相关
NCSI相关
共享资源的保护
自旋锁
原子操作
信号量
内核定时器
线程互斥
进程互斥
线程间通信
进程间通信
中断处理
Linux程序常见的安装包格式及安装方法
非阻塞IO的访问
信号
2视频下载的测试用例
参考答案：
- 在线播放清晰度是否符合要求
- 下载后的视频是否可正常播放
- 视频的声音
- 声音发出是否清晰无噪音
- 有无侧键的情况下，调节音量的测试
- 有音量显示图标清晰下，注意静音/播放音量时的音量图标显示
- 播放界面切换到其他界面，播放视频是否会自动暂停
- 弱网下的视频播放：
- 是否出现xxkb加载和loading的提示
- 弱网下暂停视频播放，网速恢复后，是否自动接着播放
- 弱网下手动点击暂停播放，网络恢复后，查看是否仍是暂停状态
- WiFi下播放视频，关闭WiFi，是否有切换流量播放的提示
- WiFi信号较弱，使用流量播放视频，WiFi信号恢复到强，是否自动切换为WiFi网络播放，停止移动网络流量的消耗
- 导入大文件的视频，查看导入提示与播放情况
- 导入不同视频的格式文件，验证不支持的格式，应该给出合理提示
- 支持的视频格式文件，但文件已损坏，查看导入时的提示
- 视频播放列表
- 查看列表文件的排序
- 注意长名称视频文件的显示
- 存在很多个文件时的列表显示
- 多个同一个视频文件，删除其中一个文件后，其他剩余文件的列表显示
- 同一个视频文件的多次新增，查看列表显示
- 导入视频后，查看视频播放列表的来源信息显示，并注意条数显示
- 查看、新增、移除当前播放列表视频的测试
- 从主菜单进入[视频播放器]界面，查看各功能图标
- 进入[视频设置]界面，查看菜单
- 在视频播放器界面
- 当前视频点击按钮切换到下一个视频，直接播放
- 按全屏键，并验证设置后的有效性
- 按收缩全屏建
- 视频的功能按键 暂停、前进、后退进行查看功能的有效性
- 视频的 暂停/播放按钮，观察点击前后的图标显示状态变化
- 视频界面的放大与缩小显示
- 分别在视频播放、暂停、停止状态下，执行长按左或者右方向键对视频进行快退快进操作
- 全屏播放时，测试视频的暂停、播放、播放模式的切换和点击屏幕返回标准屏幕
- 在视频播放器暂停情况下，点击视频画面
- 在视频播放器播放情况下，点击视频画面
- 无视频文件情况下的界面显示
- 退出视频播放器再进入后，关注默认的视频
- 后台运行后再进入，当前视频应为刚才退出前最后播放的视频
- 视频播放过程中
- 播放页面左右长拖动，上下长拖动实现的效果
- 切换至后台运行
- 来入电话
- 进度条显示正常
- 拖动进度条，视频画面根据拖动的进度条位置变化
- 视频长度提示时间正常
- 视频播放结束，视频长度提示时间正常，不会出现负数显示
- 页面图像失真情况
- 分辨率高低的切换查看
- 不同亮度背景下的色饱和度失真，影响彩色效果
- 不同亮度背景下，色调失真，由某种颜色变成了其他种颜色
- 图像出现彩色字幕时，是否发生失真，导致彩色字幕相对应的背景亮度上的对比度产生失真
3微信换头像的测试点
参考答案：
1、点击头像可以放大观看
2、查看头像是否支持放大，缩小
3，刚创建账号时是否显示默认头像
4，查看头像之后点击其它区域自动退出
5，头像支持的图片格式，图片大小
6，支持相机拍摄的图片和从网上下载的图片
7，选择完图片后是否有一个定框
8，选择相片—从手机相册获取
9，选择相片—用照相机拍照
10，头像显示的是方形还是圆形
11，选择图片范围时图片是否支持放大／缩小
12，选择好图片区域后保存，头像是否居中显示，还是只显示选择图片区域的某个角落
13，保存完图片后是否会有提示更换头像成功
14，修改头像后去app其它模块时是否马上刷新显示最新的头像
15，进入更换头像界面时可以取消更换头像
16，选择从相册选取图片还是从照相机时都能取消，返回到修改头像界面
17，头像是否支持本地缓存，断开网络之后是否还能显示头像
18，网络异常时，修改头像失败，会有提示
19，更换头像后，测试好友是否能及时看到更改的头像
20，不同网速下更换头像，是否都能更换成功
4有一个5L的杯子和6L 的杯子 和无穷无尽的水，怎么测出3L水
参考答案：
先用5L的杯子倒满水，然后把满杯的水倒进6L的杯子里， 再用5L的杯子继续装满水，然后再次倒进6L的杯子里，最终5L的杯子里只剩下4L的水了， 这个时候，会把6L的杯子的水全部倒掉， 然后把5L的杯子里的4L水倒进6L的杯子里， 然后再倒满5L的杯子的水， 最后，再把5L的水倒满6L的水杯中，由于原本6L的水杯中就已经有了4L的水，所以只需要再倒满2L的水即可，最后5L的杯子里就只有3L水！
技术二面
1简单自我介绍/项目介绍
简单说一下
2微信给朋友发图片的测试用例
参考答案：
1.选取图片的各种格式
2.图片的大小
3.预览功能
4.一次性发送图片的数量
5.对方接收时显示的内容
6.发送一张的时间
7.对方手机不同的牌子接收的图片
8.自己这边不同手机发送的状况
3有一个教师表，写出如何查询姓李的老师有多少个
参考答案：
select count（*）
from teacher
where name like “李%”
4你提交的bug 开发不认为是个bug怎么处理
参考答案：
开发人员说不是bug，有2种情况，
一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。
二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
5两个密度不同的香，每个点燃的时间是一小时，怎么测出一刻
参考答案：
首先两根一起烧，但一根两边同时烧，另一根只烧一边。两边一起烧的那根烧完就是半小时，这时候把一边烧的那根再两端一起烧，烧完的时候正是15分钟！
