测试面试题

测试流程 

      从产品立项开始，我们(项目经理 产品经理 开发人员 测试等)内部会开立项会，在立项会中进行对需求进行评审，制定需求文档，前端进行设计页面,开发人员根据需求文档进行编码,测试需要制定测试计划，以及对需求进行颗粒划分，不同的测试人员根据自己的任务编写测试用例，然后对用例进行评审，开发提交代码后执行冒烟测试，如果冒烟测试结束后执行用例如果发现bug则提交bug，让开发人员进行修改，修改后进行二次验收，bug修改正确后关闭该bug，如果没有重新打开并进行跟踪bug，项目结束后需要进行编写测试报告。

测试过程中遇到不能复现的bug怎么办？

       将bug的操作步骤进行记录，然后进行在不同的测试环境中多次的调试，如果还是不能复现             bug将根据bug的登记进行上报测试组长，根据需求文档对bug进行评级，看是否需要修改，           如果不能修改的则记录在测试报告中防止后期出现同一bug进行解释说明。

测试过程中遇到不是bug的bug怎么办？

        A：确认问题与评估

        B：明确开发不修改该缺陷的确切原因

        C：具体问题具体分析

        D：与TM和PM沟通

1.微信发红包的测试点

   1、功能测试： 

• 数字：测试0, 0.009, 0.01，0.011, 01， 199.99, 200, 200.01这些边界值
• 中文、英文、特殊字符或者这几种的组合
• 是否支持复制黏贴
• 为空/包含空格
• 金额的增删查改

• 数字、中文、英文、特殊字符、表情或者他们的组合
• 输入超长文本时，是否会给出相应的限制或提示
• 包含空格
• 是否支持复制黏贴
• 留言的增删查改
• 在红包钱数，和红包个数的输入框中只能输入数字
• 红包里最多和最少可以输入的钱数 200 0.01
• 拼手气红包最多可以发多少个红包 100
• 超过最大拼手气红包的个数是否有提醒
• 当红包钱数超过最大范围是不是有对应的提示
• 当发送的红包个数超过最大范围是不是有提示
• 当余额不足时，红包发送失败
• 在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号
• 是否可以输入它们的混合搭配
• 输入红包钱数是不是只能输入数字
• 红包描述里许多能有多少个字符 10个
• 红包描述，金额，红包个数框里是否支持复制粘贴操作
• 红包描述里的表情可以删除
• 发送的红包别人是否可以领取
• 发的红包自己可不可以领取2次
• 24小时内没有领取的红包是否可以退回到原来的账户
• 超过24小时没有领取的红包，是否还可以领取
• 用户是否可以多次抢一个红包
• 发红包的人是否还可以抢红包 多人
• 红包的金额里的小数位数是否有限制
• 可以按返回键，取消发红包
• 断网时，无法抢红包
• 可不可以自己选择支付方式

 2、兼容性测试
      a.苹果手机和安卓手机
      b.苹果手机的不同版本
      c.安卓手机不同的机型
      d.不同分辨率

3、性能测试
       a.打开红包的响应时间不能超过三秒，高并发场景下不能超过5秒
       b.耗电量
       c.消耗流量的多少
       d.所占内存

4、UI测试&易用性测试
       a.界面的设计风格是否统一
       b.界面中文字是否简洁，没有错别字
       c.是否易操作，易学习，易理解

5、中断测试：前后台切换，网络异常，低电量，断电，来电，短信等
6、网络测试
       a.网络兼容性：2g/3g/4g，WiFi，热点，移动/联通/电信
       b.无网测试
       c.弱网：延时&丢包

2.朋友圈点赞的测试点

   

1、功能测试

点赞成功
点赞后取消点赞
弱网状态点赞
没网情况下点赞
点赞后评论
点赞后消息列表的显示（按时间还是按昵称）
点赞后共同好友可以看到
点赞显示行一行可以显示多少人
点赞人数限制
点赞显示行的排列（按点赞时间）
点赞显示行头像的显示
点赞时断电
点赞时断网
点赞时手机故障
点赞时来电话
点赞时来短信
点赞刚删除的朋友圈
同一朋友圈，两个好友同时点赞
点赞自己的朋友圈
点赞好友的朋友圈

2、性能测试

点赞后好友消息的更新速度

3、界面测试

界面简单美观

4、易用性

操作简单、明了

5、兼容性

不同操作系统
不同微信版本
不同手机型号
不同电脑型号

3.视频播放器的测试点

功能测试

• 
  视频资源可以正常获取，不管是服务器返回还是后台添加等
  视频的封面图、页面UI等正常
  视频时长加载的正确
  暂停：点击屏幕、点击暂停按钮
  恢复暂停：点击屏幕、点击暂停按钮，视频接着播放
  快进：点击进度条、视频右划快进
  后退：点击进度条、视频左划快进
  亮度调节：视频区域上划、下划
  声音调节：按键调节、视频区域上划、下划调节、静音
  视频最大化、最小化
  屏幕旋转：
  横竖屏
  播放完后是否有暂停按钮
   

兼容性测试

• 平台兼容性：如Android、IOS
• 系统兼容性：Android4.4-８.0；IOS8.0-12；谨记哦（低版本的机型问题还是蛮多的，如IOS8系统播放器问题较多，测试要引起注意） 
• 播放器是否与其他类型播放器兼容（需要考虑播放过程中是否和音频等相冲突）

网络测试

• 网络切换测试：WiFi-移动网；移动网-WiFi；WiFi-无网；无网-WiFi；无网-移动网
• 弱网测试：弱网情况下，视频播放是否有卡顿、黑屏、闪退等情况
• 无网进入时是否有提示info；
• 移动网进行播放时是否有非WiFi弹框提示；
• 播放过程中断网时，播放完已加载的部分后停止播放且有相应提示；
• 播放过程中切换网络时有相应提示
• 踩过的坑：Android7.1.2版本切换4G网络查看视频时，出现黑屏，卡死，崩溃等情况
• 异常测试

半屏/全屏切换测试

• 视频右下角全屏按钮，点击全屏横屏播放视频；
• 点击收起按钮，全屏收起回到当前页半屏播放
• 两者切换播放回到当前页面时，页面展示正常（IOSXX项目曾出现页面导航错乱的问题）

横竖屏切换测试

• 旋转模式打开后，验证页面及视频播放是否正常；
• 横屏模式下播放完视频，自动切换回竖屏模式；

视频中断测试

• 播放中快进/后退进度，能正常播放本地资源，快进不卡顿，无延迟；
• 播放中切换到后台，切换到后台后暂停播放，再次进入视频为暂停状态；
• 视频播放时杀掉进程，则视频播放结束（是否保留观看进度具体看产品需求）；

视频易用性测试

• 界面是否方便，整洁（如视频封面图，片头，片尾，视频图像等各个界面）
• 快捷键是否正确
• 菜单是否正确
• 图像是否清楚（在标清、高清，超清等模式下切换时视频播放正常，无卡顿黑屏闪退等问题，在切换过程中是否有加载loading的提示）
• 拖拽滚动条（拖、拽功能用起来是否友好）
• 是否具备播放记忆功能（即播放进度是否有记录）
• 能否自动保存以前的播放列表

4.多部电梯的联动的测试点

界面测试：
外观（里面、外面）美观性
电梯空间尺寸是否和设计尺寸一致
按钮是否清晰和易懂
显示楼层的显示屏是否安装
是否联系外界的电话、紧急电话
设备检测说明书
安全规范说明书
灯
标识的承重和人数
扶手
镜子
仅提供可到达楼层的按钮
电梯制作的材料
功能测试：
测试电梯能否实现正常的上升和下降功能，每层是否都可以停靠。
每层停靠楼层是否与所按的楼层一致
电梯按键在按下时是否点亮按键灯
电梯在每个楼层的上行和下行的申请是否可以有效
电梯满负载的时候，是否会忽略其他楼层外部的上行和下行申请
电梯的两边按钮是否都可以使用，三列按钮。
电梯的楼层选择是否可以取消
电梯门的打开，关闭是否正常关闭（自动关闭）。
报警装置是否可用。（满载）
超重时是否能强制关门
超重时重新挪动一下人员是否可以上下行
与另外一部电梯之间是否协作良好。（算法）
电梯的灯光是否满足看书的要求
联系外界的电话是否可用
通风状况如何，人多的时候是否会很热，通风不畅（排气扇）
电梯里面的摄像头是否可用，拍摄是否清晰
门不夹人
伸手的话，应该不会强制关门
管理员可以和内部人通话
在各种场合下，可以强制开门
运行中时，不能按开门键，不会强制开门
在不同情况下（如：有人挡着、马上关门的时候、停电的时候、没有请求的时候…），一直按开门键和关门键
从电梯外部可以强制开门
不同温度下的测试
进入电梯，拨打手机，是否有信号
进入电梯喊话，外面是否能听到
楼层显示屏显示的楼层、以及电梯运行升降状态是否正确
两台电梯能否同时使用（或停用）
其中一台使用，另一台是否可以停用
A电梯按上行，B电梯按上行
A电梯按上行，B电梯按下行
A电梯按上行，B电梯按上下行
A电梯按上行，B电梯按下上行
A电梯按下行，B电梯按下行
A电梯按下行，B电梯按上下行
A电梯按下行，B电梯按下上行
A电梯按上下行，B电梯按上下行
A电梯按上下行，B电梯按下上行
电梯空时如何运转
电梯门开时不进电梯
进入电梯后不做任何操作
电梯门开的时间多长，超过时间后是否自动关门
电梯门开的时间超时后关门到最后2厘米，是否可以撬开门
电梯门关闭后还未上升时，电梯外按下上行（或下行）按钮，电梯门是否会打开
电梯最底层是否有下行按钮
电梯最顶层是否有上行按钮
 
停靠算法测试：
2部均空闲时，采取就近原则，离乘电梯人最近的电梯优先运行；
有1部运行时，以同行方向且顺路的电梯优先运行，否则安排空闲电梯；
2部均运行时，以方向通行且顺路的电梯优先运行；
每部电梯，在电梯内部每层在上升和下降过程中，再电梯内部均申请每层停靠
每部电梯，在电梯内部每层在上升和下降过程中，再内部没有任何申请的情况下，在电梯外部均申请每层停靠
每部电梯，在电梯内部每层在上升和下降过程中，再电梯内部均申请每层停靠，在电梯外部也申请每层停靠
电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来
电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
类似7、8测试步骤地随机测试，在电梯内部和外部均有不同组合申请的情况下，验证楼层停靠是否准确和合理。
电梯的平稳性，是否会上升过快或者下降过快，造成人体不适应反应
 
可靠性：
无任何申请的时候，可以长时间停留在某层，并且门是关闭的
门关上的一刹那出现障碍物。
长期有障碍物在门口堵住，电梯应该也不会关门或上升和下降
同时按关门和开门按钮。
快速交替按关门开门按钮
点击当前楼层号码。
快速点击不同楼层
上升到顶层后，电梯中的原有下楼请求均会被取消
下降到负楼层后，电梯中的原有上楼请求均会被取消
电梯外部同时按上键和下键会怎样。
长按打开按钮，电梯门是否持续打开
突然停电或超载时的情况，电梯（停靠、正在上升、正在下降）不会坠落，电梯门可以通过外力打开，并且紧急电话可用
电梯运行中，申请马上要经过的楼层停靠，电梯应该不会停靠。
在电梯里面蹦跳，电梯不会出现不稳定的情况。
电压不稳定的情况下的电梯运行情况
电梯不能正常工作的时候是否有监控系统自动报警
电梯不能正常工作的时候，是否有流程可以精确的指定到人进行所有故障解决的高效处理
 
易用性：
电梯的按钮的设计符合一般人使用的习惯吗．
按钮是否考虑残疾人和小孩儿
楼层显示屏是否处于电梯的上部，方便别人看到
可维护性
是否有方便维修和维护电梯的工作条件（竖井通道、统一断电等）
电梯的常用配件是否容易更换
电梯的维修成本如何
电梯的安装、维护、测试
超过维修年限，是否可以正常运转

5.水杯的测试点

1、需求测试：查看杯子的使用说明书，有不理解或者有歧义的地方提出来
2、功能测试：杯子是否可以装水，能否装热水，能装多少热水，是否会漏水，用杯子是否可以喝水
3、界面测试:查看杯子是否美观，是否符合大部分用户的审美
4、易用性测试：使用杯子装水是否烫手，是否有防滑措施，杯子是否容易清洗，是否方便饮用，装冰水时是否冻手，装
热水时是否烫手
5、可靠性测试：检查杯子质量，倒入开水后是否容易变形或者破裂，杯子是否加有填充物，在多高的情况下不会摔破
，从不同高度落下的损坏程度
6、安全性测试:杯子材质是否有毒，是否有细菌，使用杯子喝水是否安全
7、兼容性测试：杯子除了装水外，能否装果汁、酒精、白水、汽油等液体
8、疲劳测试：将杯子盛上水放置24小时检查泄漏情况，盛上汽油放置24小时检查泄漏情况
9、可移植性：将杯子放在不同地方、温度等环境下是否可以正常使用
10、震动测试：杯子是否有填充物，六面震动，检查产品是否能应对恶劣的铁路\公路\航空运输
11、压力测试：用根针，并在针上面不断加重量，看压强多大时能压迫
12、用户文档测试：检查用户说明书的准确性，是否对杯子的用法、限制、使用条件等有详细描述

水杯这个类是否可以对外提供接口，水杯的属性和方法是否可以供子类使用，属性有材质、形状、容量等。
方法有盛水等。水杯可以装泥土当花盆使用，此时水杯可以提供接口给花盆。

6.购物车的测试点

一、界面测试

1、打开页面后，页面的布局是否合理，显示是否完整；

2、鼠标浮动在购物车按钮，迷你购物车界面显示是否正常；

3、不同卖家的商品在不同的table区域显示，区分明显；

4、页面的tooltips能正常显示；

二、功能测试

1、若未登录，点击购物车，则提示用户输入用户名和密码，或者提示其他的非注册用户购物方式；

2、所有页面链接功能正常，可以点击到正确页面；

3、从商品信息页面添加的商品能显示在购物车中；

4、购物车页面刷新后，新的商品能显示；

5、新加入购物车商品排序（添加购物车中存在店铺的商品和购物车中不存在店铺的商品）；

6、商品未勾选的状态下，结算按钮是灰色无法点击的；

7、勾选商品，点击结算按钮后，进入确认订单信息页面；

8、勾选商品后，已选商品的总价会显示，结算按钮变高亮可点击工作价格总计是否正确；

9、购物车页面中，可以对添加的商品信息做信息的修改，并自动保存成功；

10、购物车商品总数是否有限制；

11、商品总数是否正确；全选功能是否好用；

12、商品文字太长时是否显示完整；店铺名字太长时是否显示完整；

13、不要的商品，可以删除；商品删除后商品总数是否减少；

14、购物车有商品降价或者库存告急的，那么点击对应的tab，降价或者告急商品会归类后显示；

15、购物车中下架的商品是否有特殊标识；

三、性能测试

1、打开购物车页面要多久；

2、结算时间需要多久；

3、增加删除商品响应时间；

四、兼容测试

1、不同浏览器上的测试功能是否正常；

2、相同浏览器的不同版本测试功能是否正常；

五、易用性测试

1、删除功能是否有提示；是否有回到顶部的功能；

2、商品过多时结算按钮是否可以浮动显示

7.登录框的测试点

功能测试

1.    输入框空值测试：保持输入框为空，点击登录。（非空检查）

2.    空格测试：

（1）用户名和密码前后有空格的处理

（2）是否过滤掉输入字符前后和中间输入的空格

3.    无效数据测试：

（1）输入正确的账号，错误的密码

（2）输入不存在的账号，注册过的密码

（3）输入注册过的账号与密码不匹配

4.    有效性测试：输入正确注册的账号、密码

5.    密码输入框：

（1）不能明文显示

（2）是否区分大小写

（3）输入框是否可复制粘贴

（4）修改密码后再次登陆验证老密码和新密码是否能登陆成功

6.    输入框长度限制：边界值测试

7.    溢出测试：输入很长长度的字符看页面是否会蹦

8.    登录成功后能否能否跳转到正确的页面

9.    记住用户名的功能

10. 登陆失败后，不能记录密码的功能

11. 密码是否加密显示（星号圆点等）

12. 有验证码的，要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用

13. 登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确

14. 输入密码的时候，大写键盘开启的时候要有提示信息。

15. 多设置同时登陆

16. 一台设备登陆多个账号（数据会不会混乱）

17. 密码输入错误的登陆次数限制

18. 成功登陆后，退出再次登陆是否需要重新登陆

19. 登陆按钮禁止多次点击

20. 网络异常时有加载页面

21. 手机设置不同的语言看界面是否显示正常

安全性测试：

1.    登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)

2.    cookie 缓存问题，sql语句注入

3.    设备的兼容性：不同机型（Android、iOS）、不同型号（屏幕大小）的界面显示问题，（华为的虚拟键盘）

4.    用户名和密码是否通过加密的方式，发送给Web服务器

5.    用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript验证

6.    用户名和密码的输入框，应该屏蔽SQL注入攻击

7.    用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）

8.    错误登陆的次数限制（防止暴力破解）

性能测试：

1.    打开登录页面时间

2.    登录进入页面时间

3.    支持多少人同时在线

4.    输入正确的用户名和密码后，登录成功跳转到新页面，不超过5秒

可用性测试(Usability Test):

1.    是否可以全用键盘操作，是否有快捷键

2.    输入用户名，密码后按回车，是否可以登陆

3.    输入框能否可以以Tab键切换

兼容性测试（Compatibility Test）:

1.    主流的浏览器下能否显示正常已经功能正常（IE,6,7,8,9,Firefox, Chrome, Safari,等）

2.    不同的平台是否能正常工作，比如Windows,Mac

3.    移动设备上是否正常工作，比如Iphone,Andriod

4.    不同的分辨率

8.三角形的测试设计点

   分析：

            构成三角形的条件：任意两边之和大于第三边；

            构成直角三角形的条件：两条边的平方和等于第三边的平方和

            构成等腰三角形的条件：任意两边相等；

            构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；

            构成等边三角形的条件：三条边都相等；

  设计：

           

            一、等价类划分：三角形三条边A、B、C的数据类型不同

　　     二、边界值分析：由于三角形的边长可以是正整数或正小数，所以就不对长度进行测试，                      那么边界值分析就不用了

　　     三、因果图法：三角形的三条边数据输入组合

  三角形的等价类：

       有效等价类：

　　输入3个正整数或正小数：

　　1、两数之和大于第三数，如A<B+C；B<C+A；C<A+B

　　2、两数之和不大于第三数

　　3、两数相等，如A=B或B=C或C=A

　　4、三数相等，如A=B=C

　　5、三数不相等，如A！=B，B！=C，C！=A

　　无效等价类：

　　1、空

　　2、负整数

　　3、非数字

　　4、少于三个数

三角形测试用例类别
输入条件	有效等价类	无效等价类
是否是三角形	(A>0)   (1) (B>0)   (2) (C>0)   (3) (A+B>C)   (4) (B+C>A)   (5) (C+A>B)   (6)	(A<=0)   (7) (B<=0)   (8) (C<=0)   (9) (A+B<=C)   (10) (B+C<=A)   (11) (C+A<=B)   (12)
是否是等腰三角形	(A=B)   (13)     (B=C)   (14) (C=A)   (15)	(A!=B)and(B!=C)and(C!=A)      (16)
是否是等腰直角三角形	(A=B)and(A2+B2=C2)   (17) (B=C)and(B2+C2=A2)   (18)   (C=A)and(C2+A2=B2)    (19)	(A!=B)and(B!=C)and(C!=A)     (20)
是否是等边三角形	(A=B)and(B=C)and(C=A)     (21)	(A!=B)      (22) (B!=C)     (23) (C!=A)     (24)

 

三角形测试用例：用最少的测试用例覆盖所有的有效等价类，而无效等价类每个类型都要覆盖到

序号	输入[A,B,C]	覆盖等价类	输出
1	[3,4,5]	(1)(2)(3)(4)(5)(6)	是三角形
2	[0,1,2]	(7)	非三角形
3	[1,0,2]	(8)	非三角形
4	[1,2,0]	(9)	非三角形
5	[1,2,3]	(10)	非三角形
6	[1,3,2]	(11)	非三角形
7	[3,1,2]	(12)	非三角形
8	[3,3,4]	(1)(2)(3)(4)(5)(6)(13)	等腰三角形
9	[3,4,4]	(1)(2)(3)(4)(5)(6)(14)	等腰三角形
10	[3,4,3]	(1)(2)(3)(4)(5)(6)(15)	等腰三角形
11	[2√2,2√2,4]	(1)(2)(3)(4)(5)(6)(17)	等腰直角三角形
12	[4,2√2,2√2]	(1)(2)(3)(4)(5)(6)(18)	等腰直角三角形
13	[2√2,4,2√2]	(1)(2)(3)(4)(5)(6)(19)	等腰直角三角形
14	[3,4,5]	(1)(2)(3)(4)(5)(6)(16)(20)(22)(23)(24)	是三角形
15	[3,3,3]	(1)(2)(3)(4)(5)(6)(16)(21)	等边三角形
16	[,,,]	无效等价类	错误提示
17	[-3,4,5]	无效等价类	错误提示
18	[a,3,@]	无效等价类	错误提示
19	[3,4]	无效等价类	错误提示

 

9.token、session、cookie的区别

 cookie 举例：服务员看你的身份证，给你一个编号，之后会根据你出示的编号查询你是谁

 token  举例：直接亮身份证给他看（令牌）

    session：服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会  被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。

    cookie：cookie是保存在客户端上的一些基本信息，服务不保存，每次请求时客户端带上cookie，里面有一些账户密码，浏览记录什么的。cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
 

    token：token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件；cookie就是写在客户端的一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用cookie自动登录用户名；session和cookie差不多，只是session是写在服务器端的文件，也需要在客户端写入cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。

cookie和session的区别

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗
   考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
   考虑到减轻服务器性能方面，应当使用cookie。

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

5、建议：将登陆信息等重要信息存放为session， 其他信息如果需要保留，可以放在cookie中

10.性能测试的指标有哪些
  资源使用率 cpu 内存 io 70%-75%
  TPS
  响应时间 2-5-8
  电压 电流的损耗
  FTP帧率
  响应成功率（根据用户量决定）

11.所在部门有多人 以及分工 以及测试如何分工的 。。
     项目组   前端  后台   移动端  测试  
12.部门负责人的简称 
  PM（项目经理）

  TM（测试经理）

  DEV（开发人员）

  TESTER（测试人员）