一.测试流程
1）测试需要分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点
2）测试计划阶段：主要任务时编写测试计划，参考软件需求规格说明书、项目总体计划、内容包括测试范围(来自需求文档)、进度的安排，人力物力的分配，整体测试策略的制定，和风险的评估与规格措施有一个制定，一般有测试负责人编写，当然我们也会参与相关的评审工作。
3）测试设计阶段：主要任务是编写测试用例，会参考需求文档（原型图）、概要设计、详细设计等文档，有不明确的也会及时和开发、产品经理沟通。用例编写完成后会进行评审。
4）测试执行阶段：首先搭建测试环境，执行预测（冒烟），以判定当前版本是否可测？如果预测通过，正式进入系统测试，遇到问题提交Bug到缺陷管理平台，并对bug进行追踪，直到被测试软件达到测试需求的要求，没有重大bug，测试结束。
5）测试评估阶段：出测试报告，对整个测试的过程中版本质量做一个 详细的评估。确认是否可以上线
二.测试过程中遇到不能复现的bug，该怎么办？
不能复现的代码有两种情况：
1）在测试阶段，执行了一个用例为覆盖的场景，或者随机测试，盲目点点点，一旦产生bug，很容易忘记之前操作了什么。对于这样的情况，通常根据bug的现象和当前的操作页面，可以大概推断出进行了哪些操作，尝试几次可能路径后，一般会找到导致缺陷的步骤。但是还会有少量情况，无论怎么操作都无法复现刚才的bug。
2）对于已经提交给开发的bug，在开发环境怎么也复现不了，开发要求关闭该bug。这种情况，就要分析提交给开发的bug描述是不是准确详细，有没有必要的前置条件，操作步骤是否详细，是否提供必要的截图信息。排查测试环境和开发环境的配置是否相同，可以要求开发在测试环境中验证通过在关闭该bug。一些没有经验的测试人员，再遇到第一种情况时，认为这种bug的概率非常小，可以不用提交bug。而且，开发人员有时候也要求必须有重新路径才能提交bug，这样一旦线上出现问题，背锅的自然就是测试了。
正确的做法：
1.首先，再遇到非必然重现的bug，一定要提bug，并且要在bug单中说明复现的概率。
2.在发现bug时，要分析产生的原因，尽量多尝试出现的步骤。排除环境和 自己电脑配置的原因，比如浏览器的版本，系统的版本等。还可以寻找开发帮助，让开发同学对相应地方的代码进行检查，看一下是否可以通过代码层面检查出问题。
3.如果还未复现。在接下来的测试中，时刻保持关注，每次执行同样或者相近的步骤的时候，看下是否能够复现之前的bug。
4.那些一致未能复现的bug，需要测试经理定期将这些bug汇总，选择优先级高的缺陷，组织开发人员和测试人员专门投入到复现问题。如果经过这样的专门复现依然不能复现，可以降低问题的优先级。如果在项目的前期，跟踪至少3个版本，如果任然无复现，可以暂时关闭该bug，备注说明并不是因为修复关闭，而是经过x个版本后不复现了。
5.如过项目周期比较紧张，不能跟踪多个版本，那么bug就不能关闭，上线后及时关注用户的使用反馈，如果持续3或者4个版本没有出现，那么可以将这个bug暂时关掉，同时关掉的时候要进行备注说明
三.经典用例设计
（一）、纸杯
1.功能测试
能放多少水、是否符合要求
地盘直径时多少
存放时间、存放的环境
不能装哪些液体
角度是否合理
2.性能测试
地盘是否平稳
角度是否合理
是否漏水
纸杯是否容易变形、硬度是否足够
从不同高度摔下来的损坏程度
3.界面测试
根据该纸杯的用户进行界面的测试
是否有相应的提示
图标布局是否合理
纸杯上的字体是否美观，收否有错别字
纸杯上的图标和字体是否完整
图案是否容易脱落
4.人性化测试
是否产生有毒物质
水杯的手感如何、口感如何
是否有利于叠在一起存放，使用时是否容易分开
外观是否适合拿起
（二）、购物车
1.功能测试
2.性能测试
（三）、电梯
1.功能测试
电梯门的打开、关闭是否正常
按钮是否可以正常使用
能否实现正常的上升和下降功能，是否停到相应楼层
电梯内是否有灯，灯光是否柔和，电梯运行中灯是否稳定
报警装置是否可用
通风状况如何，是否有手机信号
突然停电的状况
上下升途中的响应
1）先只按17楼上升，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来，下降类似模拟
2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停
2.可靠性：
1、关门时出现障碍物
2、同时按关门和开门按钮
3、同时按上下键、开关门按钮
4、多次选择同一楼层
3.压力测试：
1、看电梯的最大承重量，在负载过重时报警装置是否有提醒
2、在一定时间内不断让电梯上升、下降
4.稳定性：
1、升降过程中晃动是否明显
2、有人在电梯里运动，晃动感如何
3、看电梯在最大负载下平稳运行的最长时间
5.易用性：
1、按钮的设计符合一般人的习惯吗（高度、文字）
2、高级电梯内层是否有设计小孩和残疾人可以触摸到的按钮
（四）、登录框
1.界面
1、登录界面是否清晰合理美观，无乱码（文字简洁、无错别字）
2..功能（主要采用等价类、边界值方法）
1、输入正确的用户名、密码，是否登录成功
2、输入错误的用户名或者密码，登录失败有没有提示（用户名或密码为空）
3、用户名、密码支持的字符类型
4、输完用户名之后按Tab键是否能到输入密码的框，输完密码之后按回车能否登录
5、如果有记住用户名密码的功能，下一次打开页面，是否默认有用户名密码
6、用户名、密码是否大小写敏感
（具体还可以考虑：这个用户名密码是否已注册）
3.安全性
1、在登录页面，输入的密码是否隐藏显示
2、多次登录失败，系统会不会阻止后续的尝试以应对暴力破解
3、用户名、密码能否支持复制、黏贴
4、在浏览器中直接输入登录成功后的URL地址，验证是否会重新定向到用户登录界面
5、密码输入框内的密码是否都可以在页面源码模式下被查看
4.兼容性
1、不同操作系统上同版本的浏览器能否正常打开登录界面，界面正常
2、相同操作系统的不同浏览器能否正常打开登录界面，界面正常
3、这个登录界面能否在移动手机端正常打开
5.性能压力
1、输入正确用户名、密码之后点击登录按钮，直到登录成功打开页面，需要多长时间（小于3秒）
2、多个用户同时进行登录操作，相应登录的时间是否会变长（小于5秒）
（五）、多部电梯具有联动性
1.功能测试
测试电梯能否实现正常的上升和下降功能，每层是否都可以停靠。
每层停靠楼层是否与所按的楼层一致
电梯按键在按下时是否点亮按键灯
电梯在每个楼层的上行和下行的申请是否可以有效
电梯满负载的时候，是否会忽略其他楼层外部的上行和下行申请
电梯的两边按钮是否都可以使用，三列按钮。
电梯的楼层选择是否可以取消
电梯门的打开，关闭是否正常关闭（自动关闭）。
报警装置是否可用。（满载）
2.可靠性
无任何申请的时候，可以长时间停留在某层，并且门是关闭的
门关上的一刹那出现障碍物。
长期有障碍物在门口堵住，电梯应该也不会关门或上升和下降
同时按关门和开门按钮。
快速交替按关门开门按钮
点击当前楼层号码。
快速点击不同楼层
上升到顶层后，电梯中的原有下楼请求均会被取消
下降到负楼层后，电梯中的原有上楼请求均会被取消
电梯外部同时按上键和下键会怎样。
3.易用性
电梯的按钮的设计符合一般人使用的习惯吗．
按钮是否考虑残疾人和小孩儿
楼层显示屏是否处于电梯的上部，方便别人看到
可维护性
是否有方便维修和维护电梯的工作条件（竖井通道、统一断电等）
电梯的常用配件是否容易更换
（六）、视频播放器测试点
1.功能测试
1.打开，关闭播放器
2.播放，暂停，停止播放器
3.上一个視频，下一个视频
4.音量大小，静音
5.最大化，最小化
6.播放列表的添加，删除，查看
7.播放列表的播放顺序，单循环，多循环，顺序播放，随即播放
8.支持的所有播放格式的文件
9.能否播放被隐藏的媒体文件
10.能否通过网络播放已共享的媒体文件
2.易用性测试
1.界面是否方便，整洁
2.快捷键是否正确
3.菜单是否正确
4.图像是否清楚
5.拖拽滚动条
6.是否支持直接拖动文件到播放器中
7.是否具备播放记忆功能
8.是否能否自动保存以前的播放列表
3.性能测试
1.一次性添加多个文件到播放列表，看播放器的反应时间
2.播放大容量的文件，看加载多长时间能正常播放
4.兼容性测试
1.播放器是否能在其他平台上正常播放
2.播放器是否与其他类型播放器兼容
（七）、三角形的测试设计点
1、构成三角形的条件：任意两边之和大于第三边；
2、构成等腰三角形的条件：任意两边相等；
3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；
4、构成等边三角形的条件：三条边都相等。
（八）、朋友圈点赞的测试用例的设计点
1.功能测试
点赞成功
点赞后取消点赞
弱网状态点赞
没网情况下点赞
点赞后评论
点赞后消息列表的显示（按时间还是按昵称）
点赞后共同好友可以看到
点赞显示行一行可以显示多少人
点赞人数限制
点赞显示行的排列（按点赞时间）
点赞显示行头像的显示
点赞时断电
点赞时断网
点赞时手机故障
点赞时来电话
点赞时来短信
点赞刚删除的朋友圈
同一朋友圈，两个好友同时点赞
点赞自己的朋友圈
点赞好友的朋友圈
2.性能测试
点赞后好友消息的更新速度
3.界面测试
界面简单美观
4.兼容性
不同操作系统
不同微信版本
不同手机型号
不同电脑型号
（九）、微信发红包
1.功能测试
1、在红包钱数和红包个数的输入框中输入数字。
2、红包里最多和最少可以输入的钱数是200和0.01。
3、拼手气红包最多可以发100个红包。超过最大拼手气红包的个数是否有提醒。
4、当红包钱数超过最大范围是不是有相应的提示。
5、当发送的红包个数超过最大范围是不是有提示。
6、当余额不足时，红包发送失败。红包分别从银行卡和零钱中扣除。
7、在红包描述里是否可以输入汉字、英文、符号、表情、纯数字等。
8、输入红包钱数是否只能是数字。
9、红包描述最多能有几个字符。
10、红包描述、金额、红包个数框中是否支持复制粘贴操作。
2.性能测试
1、弱网抢红包时，发红包时间。
2、不同网速时抢红包，发红包的时间。
3、发红包和收红包成功后的跳转时间。
4、收发红包的耗电量。
5、退款到账的时间。
3.兼容性
1、安卓，苹果是否都可以收发红包。
2、电脑端是否可以抢红包
4.安全性
1、对方微信号异地登录，是否会提醒。
2、红包被领取后，发红包金额是否会减少，收红包金额是否会增加。
3、发生红包失败。余额和银行卡余额是否会减少。
4、红包发送失败，是否收到微信支付的通知。
四、token session cokkie 三者区别
三者都是用来进行状态保持的
因为http协议本事是无状态的为了让用户登录成功之后在下次请求数据的时候，服务器仍然认识，因此进行状态保持
cookie：
cookie是浏览器（客户端）里面能永久存储的一种数据。
cookie由服务器生成，发送给浏览器，浏览器把cookie以key-value形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
session（会话）：
当用户打开某个web应用时，便与web服务器产生一次session。
服务器为了区分当前给自己发请求的是谁，给每个客户端分配了一个不同的“身份标识”。客户端发请求时需要携带该“身份标识”。“身份标识”的存储方式很多，通常使用cookie。
服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。
可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
token（令牌）：
token是用户身份的验证方式，最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库
五、测试过程中遇到开发不认为是bug的bug怎么办？
将问题提交到缺陷管理库里面进行备案；
然后，要获取判断的依据和标准：
根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷
如果产品觉得是BUG，一般情况是需要修复的。如果产品经理觉得问题不大，那这个BUG就可以不解决。最后记录在测试报告中
六、部门负责人的简称
职位英文缩写
GM（General Manager）总经理
VP（Vice President）副总裁
FVP（First Vice President）第一副总裁
AVP（Assistant Vice President）副总裁助理
CEO（Chief Executive Officer）首席执行官
COO（Chief Operations Officer）首席运营官
CFO（Chief Financial Officer）首席财务官
CTO（Chief Technology Officer）首席技术官
HRD（Human Resource Director）人力资源总监
OD（Operations Director）运营总监
MD（Marketing Director）市场总监
OM（Operations Manager）运作经理
PM（Production Manager生产经理、Product Manager产品经理、Project Manager项目经理) 注：这里面变化比较多，要结合谈话时的背景来判断究竟是指哪种身份）
BM（Branch Manager）部门经理
DM（District Manager）区域经理
RM（Regional Manager）区域经理
