测试入门知识点
测试入门
1. 测试流程
从产品立项开始，我们(项目经理 产品经理 开发人员 测试等)内部会开立项会，在立项会中进行对需求进行评审，制定需求文档，前端进行设计页面,开发人员根据需求文档进行编码,测试需要制定测试计划，对需求进行颗粒划分，不同的测试人员根据自己的任务编写测试用例，然后对用例进行评审，开发提交代码后执行冒烟测试，冒烟测试结束后执行用例，如果发现bug则提交bug，让开发人员进行修改，修改后进行二次验收，bug修改正确后关闭该bug，如果没有重新打开并进行跟踪bug，项目结束后需要进行编写测试报告。
2. 测试过程中遇到了不能复现的bug的时候你怎么办
将bug的操作步骤进行记录，然后进行在不同的测试环境中多次的调试，如果还是不能复现bug将根据bug的登记进行上报测试组长，根据需求文档对bug进行评级，看是否需要修改，
如果不能修改的则记录在测试报告中防止后期出现同一bug进行解释说明。
3. 测试过程中遇到 开发不认为是bug的bug你怎么办
- 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
- 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
- 根据用户的一般使用习惯，来确认是否是缺陷；
- 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
如果仍然存在争议，可以向项目经理进行沟通。
任然存在争议的话将其写入测试报告当中去。
4. 经典用例设计（纸杯、购物车、电梯、登录框、多部电梯具有联动性、视频播放器测试点，三角形的测试设计点、朋友圈点赞的测试用例的设计点、微信发红包）
纸杯：
一需求：
测试一个带广告图案的花纸杯
二相关背景：
1.杯子特性：
(1)杯子的容量：能装多少升水，空杯，半杯，满杯
(2)杯子的型状：圆型，上面口大，下面小。
(3)杯子的材料：纸杯
(4)杯子的抗摔能力：风吹是否会倒，摔一次是否会摔坏，摔多次是否会摔坏 (5)杯子的耐温性：装冷水，冰水，热水
2.广告图案：
(1)广告内容与图案碰水是否会掉色
(2)广告内容与图案是否正当
(3)广告内容与图案是否轻易剥落
三影响范围：
1.可用性：
(1)装进液体多久后会漏水
(2)装进热水多久后可以变温，装进冰水多久后可以融化
2.安全性：
(1)装进不同液体，是否会有化学反应。比如：可乐，咖啡等饮料
(2)装进热水杯子是不是会变型和异味
3.性能：
(1)不同人群是否能适合杯子的型状，包括握杯的感觉和喝水的感觉
(2)不同人群是否能接受杯子的广告内容与图案
购物车：
界面测试：
·打开页面后，页面的布局是否合理，显示是否完整；
·鼠标浮动在购物车按钮，迷你购物车界面显示是否正常；
·不同卖家的商品在不同的table区域显示，区分明显；
·页面的tooltips能正常显示；
功能测试：
·所有页面链接功能正常，可以点击到正确页面；
·页面关联本地软件阿里旺旺的icon点击后，能打开软件；
·从商品信息页面添加的商品能显示在购物车中；
·购物车页面打开的同时，在其他页面添加了商品，购物车页面刷新后，新的商品能显示；
·若未登录，点击购物车，则提示用户输入用户名和密码，或者提示其他的非注册用户购物方式；
·商品未勾选的状态下，结算按钮是灰色无法点击的；
·勾选商品后，已选商品的总价会显示，结算按钮变高亮可点击工作；
·勾选商品，点击结算按钮后，进入确认订单信息页面；
·购物车页面中，可以对添加的商品信息做信息的修改，并自动保存成功；
·卖家在线的时候，旺旺icon高亮，反之，灰色；
·购物车有商品降价或者库存告急的，那么点击对应的tab，降价或者告急商品会归类后显示；
·购物车能添加的商品种类是有数量上限的；
·不要的商品，可以删除；
（其他特有的功能不做赘述，只讨论常见通用功能）
若商品已经失效，购物车的商品是否可以继续结算
已进入支付界面但支付未成功，重新进入购物车，又重新添加了一些物品，则原有的物品是否能正确保留；
（感觉这个还挺关键，经常是没完成支付，又添加了一些物品，最后再一起支付）
性能测试：
·打开购物车页面要多久；
可用性测试：
·快捷键功能知否支持
兼容测试：
·不同浏览器上的测试功能是否正常；
·app上测试
电梯联动：
界面测试：
外观（里面、外面）美观性
电梯空间尺寸是否和设计尺寸一致
按钮是否清晰和易懂
显示楼层的显示屏是否
功能测试：
测试电梯能否实现正常的上升和下降功能，每层是否都可以停靠。
每层停靠楼层是否与所按的楼层一致
电梯按键在按下时是否点亮按键灯
电梯在每个楼层的上行和下行的申请是否可以有效
电梯满负载的时候，是否会忽略其他楼层外部的上行和下行申请
电梯的两边按钮是否都可以使用，三列按钮。
电梯的楼层选择是否可以取消电梯门的打开，关闭是否正常关闭（自动关闭）。
报警装置是否可用。
（满载）超重时是否能强制关门超重时重新挪动一下人员是否可以上下行与另外一部电梯之间是否协作良好。
（算法）电梯的灯光是否满足看书的要求联系外界的电话是否可用通风状况如何，人多的时候是否会很热，通风不畅（排气扇）
电梯里面的摄像头是否可用，拍摄是否清晰
门不夹人伸手的话，应该不会强制关门管理员可以和内部人通话在各种场合下，可以强制开门运行中时，不能按开门键，不会强制开门在不同情况下（如：有人挡着、马上关门的时候、停电的时候、没有请求的时候…），一直按开门键和关门键从电梯外部可以强制开门
不同温度下的测试：
进入电梯，拨打手机，是否有信号进入电梯喊话，外面是否能听到
楼层显示屏显示的楼层、以及电梯运行升降状态是否正确
两台电梯能否同时使用（或停用）
其中一台使用，另一台是否可以停用
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测试步骤地随机测试，在电梯内部和外部均有不同组合申请的情况下，验证楼层停靠是否准确和合理。
电梯的平稳性，是否会上升过快或者下降过快，造成人体不适应反应
可靠性：
无任何申请的时候，可以长时间停留在某层，并且门是关闭的门关上的一刹那出现障碍物。
长期有障碍物在门口堵住，电梯应该也不会关门或上升和下降同时按关门和开门按钮。
快速交替按关门开门按钮点击当前楼层号码。快速点击不同楼层上升到顶层后，电梯中的原有下楼请求均会被取消下降到负楼层后，电梯中的原有上楼请求均会被取消电梯外部同时按上键和下键会怎样。
长按打开按钮，电梯门是否持续打开突然停电或超载时的情况，电梯（停靠、正在上升、正在下降）不会坠落，电梯门可以通过外力打开，并且紧急电话可用电梯运行中，申请马上要经过的楼层停靠，电梯应该不会停靠。
在电梯里面蹦跳，电梯不会出现不稳定的情况。电压不稳定的情况下的电梯运行情况电梯不能正常工作的时候是否有监控系统自动报警电梯不能正常工作的时候，是否有流程可以精确的指定到人进行所有故障解决的高效处理
易用性：
电梯的按钮的设计符合一般人使用的习惯吗．
按钮是否考虑残疾人和小孩儿
楼层显示屏是否处于电梯的上部，方便别人看到
可维护性：
是否有方便维修和维护电梯的工作条件（竖井通道、统一断电等）
电梯的常用配件是否容易更换
电梯的维修成本如何电梯的安装、维护、测试超过维修年限，是否可以正常运转
登录框：
设计功能点的测试用例
我们的系统不做记住用户和忘记密码的功能，所以针对这二个功能未设计测试点。
2.设计安全性测试用例
4.测试界面
在测试过程中，我们不仅要关注功能点是否按照需求已经实现了，同时我们还需要关注界面和用户体现性，需要进行界面和体现方面的测试。
在测试界面中，主要测试以下内容：
1.界面内容
登录模块放置在页面中的哪个位置，如果居中，是否又居中显示了；
其它位置放置什么东西；
用户输入框、密码输入框、登录按钮排列、是否对齐；框的大小；
用户名、密码字样是否相同，对齐.
2.提示
用户名、密码输入框是否有默认提示内容；
输入错误的用户名或密码是否给出了正确的提示，提示的文字、大小、颜色是否按需求描述（如果需求中没有明确指出，那可以借鉴其它网站相同功能的提示风格）;
用户名和密码是否是必填的，如果是必填的，是否用红色星号表示（通用规则）；
输入为空时，给出的提示是否正确。
密码显示：密码是否是密文显示，如果需求中规定了可支持明文显示，显示有相应的控件。
视屏播放器：
功能测试
- 视频资源可以正常获取，不管是服务器返回还是后台添加等
- 视频的封面图、页面UI等正常
- 若一个视频中涉及到上一个视频、下一个视频时点击后都能正常切换到相应的视频，且视频正常播放
- 音量大小（如静音模式下播放时无声音）
- 视频最大化、最小化（如切换到最大化时视频全屏播放）
- 播放列表的播放顺序，单循环，多循环，顺序播放，随机播放（还需要考虑下视频若是后台上传的，若在后台将某视频进行增加，删除，修改操作，验证视频播放是否正常）
- 其他逻辑：
- 点击视频时，视频正常播放；再次点击时暂停播放资源；
- 播放视频时应用切换到后台---切换到后台后暂停播放，再次进入应用为暂停状态；
- 播放时杀掉程序进程---视频播放结束，不保留观看进度，再次进入到该视频，从头播放
- 播放视频A时切换到视频列表下的视频B----播放视频B；从进度B开始播放
- 播放视频A时切换到其他项目下的视频C---播放视频C；再次切换到视频A时从头播放
- 播放时上下滚动页面---视频播放器位置恒定，滚动不影响播放
兼容性测试
- 平台兼容性：如Android、IOS
- 系统兼容性：Android4.4-８.0；IOS8.0-12；谨记哦（低版本的机型问题还是蛮多的，如IOS8系统播放器问题较多，测试要引起注意）
- 播放器是否与其他类型播放器兼容（需要考虑播放过程中是否和音频等相冲突）
网络测试
- 网络切换测试：WiFi-移动网；移动网-WiFi；WiFi-无网；无网-WiFi；无网-移动网
- 弱网测试：弱网情况下，视频播放是否有卡顿、黑屏、闪退等情况
- 无网进入时是否有提示info；
- 移动网进行播放时是否有非WiFi弹框提示；
- 播放过程中断网时，播放完已加载的部分后停止播放且有相应提示；
- 播放过程中切换网络时有相应提示
- 踩过的坑：Android7.1.2版本切换4G网络查看视频时，出现黑屏，卡死，崩溃等情况
- 异常测试
半屏/全屏切换测试
- 视频右下角全屏按钮，点击全屏横屏播放视频；
- 点击收起按钮，全屏收起回到当前页半屏播放
- 两者切换播放回到当前页面时，页面展示正常（IOSXX项目曾出现页面导航错乱的问题）
横竖屏切换测试
- 旋转模式打开后，验证页面及视频播放是否正常；
- 横屏模式下播放完视频，自动切换回竖屏模式；
视频中断测试
- 播放中快进/后退进度，能正常播放本地资源，快进不卡顿，无延迟；
- 播放中切换到后台，切换到后台后暂停播放，再次进入视频为暂停状态；
- 视频播放时杀掉进程，则视频播放结束（是否保留观看进度具体看产品需求）；
视频易用性测试
- 界面是否方便，整洁（如视频封面图，片头，片尾，视频图像等各个界面）
- 快捷键是否正确
- 菜单是否正确
- 图像是否清楚（在标清、高清，超清等模式下切换时视频播放正常，无卡顿黑屏闪退等问题，在切换过程中是否有加载loading的提示）
- 拖拽滚动条（拖、拽功能用起来是否友好）
- 是否具备播放记忆功能（即播放进度是否有记录）
- 能否自动保存以前的播放列表
5. token session cookie 三者的区别 （笔试题）
token
登录后，服务器端发送一个token令牌
token也有时效性
token可以支持多平台访问
session
登录后服务器端发送一个随机的ID值，来进行用户身份的识别
session的有效性，是在代码中进行设计的，一般是30分钟
session只针对一个应用服务器有效
cookie
用户登录以后，在浏览器端生成一个文件，保存在浏览器的客户端
一般存储用户的身份信息
可以删除，删除后重新登录可以再次生成
使用不同的浏览器，电脑登录同一网站，会产生不同的cookies
有的系统会通过cookies存储用户行为习惯
cookie数据存放在客户端上，session数据放在服务器上；
cookie不是很安全，且保存数据有限；
session一定时间内保存在服务器上,当访问增多，占用服务器性能。
浙公网安备 33010602011771号