测试基础理论

1.测试流程？

我们一般在项目进行开立项会的时候进行参与，讨论需求并提出建议，在立项会中制定需求文档，由ui设计原型图，开发根据需求文档进行编码，我们测试会根据需求文档进行编写测试计划，根据模块的颗粒度划分并编写测试用例以及对用例的评审，开发结束后测试对主要功能进行冒烟测试，执行测试用例，提交bug，开发进行修改，修改成功后关闭bug，进行回归测试，在上限前进行测试总结。

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

1.  记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2. 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3. 将bug的操作进行记录（记录bug要尽量描述清楚发生问题时的测试步骤、 测试   环境、测试数据）然后进行在不同的测试环境中多次调试，如果还是不能复现bug 将根据bug的登记进行上报测试组长，

     4. 根据需求文档对bug进行评级，看是否需要修改，如果不能修改的则记录在测试报告中防止     后期出现相同bug

3.遇到开发不认为是bug的bug怎么办？

1.先确认是不是如开发说的那样，环境问题/脏数据，是的话，关闭bug；

2.不是的话，根据产品需求文档来，一般有分歧都是一些小问题（交互、UI、样式、展示顺序等问题），产品经理拍板或者拿出数分数据支持，这样开发的产品更容易引导用户，促进成交；

3.若产品需求文档没有提及，需要凭借个人经验判断（比如登录的时候，第一次输入验证码，不小心输错了，重新输入。这个时候，验证码输入框不提供删除原先输错的验证码。虽然需求没有提到，但是基于自己的经验，这也就是bug）

4.经典用例设计（纸杯、购物车、电梯、登录框、多部电梯具有联动性、视频播放器测试点、三角形的测试设计点、朋友圈点赞的测试用例的设计点、视频播放器测试点、微信发红包）

纸杯

功能

                是否能正常承装液体

                是否有防滑功能

                是否能正常喝水

界面

             纸杯表面图案是否完整、美观

性能

                放半杯水，放一整杯水，放冷水，放热水，放茶叶，放可乐

                倒进水，喝水，再倒水，倒开水，捏变形，弹烟灰，丢弃

安全性

                用料是否环保?

                是否能平稳放在桌面上?

                杯口是否光滑

                到进水是否不漏，

                是否不变形?

                水是不是能倒出来?

易用性

                能否放在桌子上不倒?

                手拿着是否不变形，不会感到不舒服?

                是否能放到杯架、套到别的杯子上?

购物车

功能

1. 购物车页面的所有连接是否正常
2. 购物车中如果存在有商品降价、库存不足、限购件数等，在商品详情的下面，会有对应的字体展示
3. 从商品信息页面添加的商品能显示在购物车中。
4. 若未登录，点击购物车中的商品直接进行结算，则提示用户输入用户名和密码，或者提 示用户进行注册。
5. 若没有选择任何商品，点击结算，则提示用户“请添加要结算的商品”。
6. 勾选商品后，已选商品的总价（和优惠满减活动）会显示。
7. 勾选商品，点击结算按钮后，进去确认订单信息页面。
8. 购物车能添加的商品种类是有数量上限的。
9. 结算的时候商品可以全选，选择底部的全选按钮。

界面

1. 打开购物车页面后，看页面是否布局合理，是否完整
2. 页面的功能按钮可以正常显示
3. 不同卖家的商品在不同的tatle区域显示，区分

    4.商品的最下方显示失效宝贝。

    5.页面的最低端显示“你可能喜欢”

    6.向下滑动页面，在购物车顶端展示“购物车”。

    7.购物车中如果存在有商品降价、库存不足、限购件数等，在商品详情的下面，会有对应的字体展示。

性能

        1.打开购物车时间是否在已定的用户可以棘手的时间范围内。

        2.编辑购物车：删除、添加商品需要的时间。

        3.在购物车页面选择需要购买的商品进行结算的时候，结算金额可不可以实时显示。

        4.清空失效商品需要的时间。

        5.打开购物车页面要多久

        6.快捷键功能知否支持

安全性

1. 登录时是否会泄露密码
2. 支付时是否会泄露支付密码

易用性  

1. 是否能一件批量付款

        2.是否有全选、全不选的功能

        3.是否能删除商品

        4.能否把购物车了的商品移入收藏夹

        5.是否有商品件数的总计

        6.是否有商品规格、购买数量的显示

        7.是否有商品名称的显示

        8.是否有店铺活动、满减优惠、降价显示

        9.每个商品是否有店铺名称的提示

        10.点击商品店铺能否进入店铺查看商品

        11.点击商品名称能否进入商品详情页

        12.是否有领券的文字提示

        13.是否会显示领取优惠券之后的优惠价格

        14.失效的商品是否还会出现在购物车的历史记录中

        15.每件商品是否有对应商品图片的展示

        16.是否有凑单提示

        17.在购物车页面能否再次选择商品的种类

        18.划到购物车页面的底部，有没有推荐商品展示

        19.不支持发货的地区是否会有提示，商品前面的全选、全不选多选框是否会变灰色

        20是否有寻找相似商品的功能

电梯

   功能：

        1.测试电梯能否实现正常的上升和下降功能。

        2.电梯的按钮是否都可以使用

        3.电梯内分楼层键是否正常

        4.电梯内开关门键是否正常

        5.电梯内的报警键是否正常使用

        6.电梯外的上下键是否正常

        7.电梯门的打开，关闭是否正常。

        8.报警装置是否可用。

        9.与其他电梯之间是否协作良好。

        10.通风状况如何。

        11.突然停电时的情况。

        12.关注显示屏，电梯内外的显示屏显示的电梯层数、运行方向是否正常

        13.有障碍物时，电梯门的感应系统是否有效

        14.是否有手机信号

性能：

        1.门关上的一刹那出现障碍物。

        2.同时按关门和开门按钮。

        3.点击当前楼层号码

        4.多次点击同一楼层号码

        5.同时按上键和下键

易用性：

        1.电梯的按钮的设计符合一般人的习惯吗

        2.楼层按键高度（小孩和一些身高矮的用户会按键不方便）

        3.电梯是否有地毯、夏天是否有空调、通风条件、照明条件、手机信号是否通畅

        4.电梯是否有扶手，是否有专针对残疾人的扶手等等

安全性：

        1.看电梯的最大承重量，在负载过重时报警装置是否有提醒

        2.在一定时间内不断让电梯上升、下降

        3.看电梯在最大负载下平稳运行的最长时间

        4.下坠时是否有制动装置

        5.暴力破坏电梯时是否报警，超重是否报警

        6.停电情况下电梯是否有应急电源装置

        7.测试电梯负载单人时的运行情况（基准测试）

        8.多人时的运行情况（负载测试）

        9.一定人数下较长时间的运作（稳定性测试）

        10.更长时间运作时的运行情况（疲劳测试）

        11.不断增加人数导致电梯报警（拐点压力测试）

        兼容性测试

        1.电梯的整体和其他设备的兼容性，与大楼的兼容，与海地隧道的兼容等等

        2.不同类型的电压是否兼容

登录框

   功能性用例设计点：

        1.  输入已注册的用户名和正确的密码，验证是否成功登录

        2.  输入已注册的用户名和不正确的密码，验证是否成功失败，且提示信息正确

        3.  输入未注册的用户名和任意密码，验证是否登录失败，且提示信息正确

        4.  使用未激活账户登录，验证是否登录失败

        5.  使用被停用用户登录，验证是否登录失败

        6.  用户名和密码两者都为空，验证是否登录失败，且提示信息正确

        7.  用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确

        8.  如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入正确的验证码，验证是否登录成功

        9.  如果登录功能启用了验证码功能，在用户名和密码正确的情况下，输入错误的验证码，验证是否登录失败，且提示信息正确

        10.用户名和密码是否大小写敏感

        11.页面上的密码框是否加密显示、或者是否需要有明暗码切换按钮

        12.后台系统创建的用户第一次登录成功时，是否提示修改密码

        13.忘记用户名和忘记密码的功能是否可用

        14.前端页面是否根据设计需求限制用户名和密码长度

        15.如果登录功能需要验证码，点击验证码图片或者点击换一张是否可以更换验证码，更换后的验证码是否可用

        16.刷新页面是否会刷新验证码

        17.如果验证码有时效性，需要分别时效性内和时效性外验证码的有效性

        18.用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面

        19.不同级别的用户，比如管理员和普通用户，登录系统后权限是否正确

        20.页面默认焦点是否定位在用户输入框中

        21.快捷键Tab和Enter等，是否可以正常使用

        22.为空和输入空格字符串的校验是否一致

        23.操作错误提示信息是否简单明了

兼容性测试用例设计点：

1.  不同浏览器下，验证登录页面的显示以及功能正确性

2.  相同浏览器的不同版本下验证登录页面的显示以及功能正确性

3.  不同移动设备终端的不同浏览器下，验证登录页面显示以及功能的正确性

4.  不同分辨率的界面下，验证登录页面的显示以及功能正确性

安全性测试用例设计点：

1.  用户密码后台存储是否加密

2.  用户密码在网络传输过程中是否加密

3.  密码是否具有有效期，密码有效期到期后，是否提示需要修改密码

4.  不登录的情况下，在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面

5.  密码输入框是否不支持复制粘贴

6.  密码输入框内输入的密码是否都可以在页面源码模式下被查看

7.  用户名和密码输入框分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面

8.  用户名和密码输入框分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改

9.  连续多次登录失败的情况下，系统是否会阻止后续的尝试以应对暴力破解

10.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期

11.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性

12.是否可以记住密码，记住的密码保存是否加密，记住的密码是否有有效期，过了有效期后是否清空密码

13.是否支持第三方登录

14.密码的强弱性，复杂度校验

15.异地登录校验、更换设备登录校验、登陆信息异常是否考虑账户冻结停用、是否允许第三方平台存储密码

16.登录错误后的提示是否存在安全隐患

性能压力测试的用例设计点：

1.  单用户登录的响应时间是否小于3秒

2.  单用户登录时，后台请求数量是否过多

3.  高并发场景下用户登录的响应时间是否小于5秒

4.  高并发场景下服务端的监控指标是否符合预期

5.  高集合点并发场景下，是否存在资源死锁和不合理资源等待

6.  长时间大量用户连续登录和登出，服务器是否存在内存泄露

多部电梯具有联动性

界面测试：

外观（里面、外面）美观性
1.电梯空间尺寸是否和设计尺寸一致
2.按钮是否清晰和易懂
3.显示楼层的显示屏是否安装
4.是否联系外界的电话、紧急电话
5.设备检测说明书
6.安全规范说明书
灯
7.标识的承重和人数
8.扶手
9.镜子
10仅提供可到达楼层的按钮
11.电梯制作的材料

功能测试：

1.测试电梯能否实现正常的上升和下降功能，每层是否都可以停靠。
2.每层停靠楼层是否与所按的楼层一致
3.电梯按键在按下时是否点亮按键灯
4.电梯在每个楼层的上行和下行的申请是否可以有效
5.电梯满负载的时候，是否会忽略其他楼层外部的上行和下行申请
6.电梯的两边按钮是否都可以使用，三列按钮。
7电梯的楼层选择是否可以取消
8电梯门的打开，关闭是否正常关闭（自动关闭）。
9报警装置是否可用。（满载）
10超重时是否能强制关门
11超重时重新挪动一下人员是否可以上下行
12与另外一部电梯之间是否协作良好。（算法）
13电梯的灯光是否满足看书的要求
14联系外界的电话是否可用
15通风状况如何，人多的时候是否会很热，通风不畅（排气扇）
16电梯里面的摄像头是否可用，拍摄是否清晰
17门不夹人
18伸手的话，应该不会强制关门
19管理员可以和内部人通话
20在各种场合下，可以强制开门
21运行中时，不能按开门键，不会强制开门
22在不同情况下（如：有人挡着、马上关门的时候、停电的时候、没有请求的时候…），一直按开23门键和关门键
24从电梯外部可以强制开门
25不同温度下的测试
26进入电梯，拨打手机，是否有信号
27进入电梯喊话，外面是否能听到
28楼层显示屏显示的楼层、以及电梯运行升降状态是否正确
29两台电梯能否同时使用（或停用）
30其中一台使用，另一台是否可以停用
31A电梯按上行，B电梯按上行
32A电梯按上行，B电梯按下行
33A电梯按上行，B电梯按上下行
34A电梯按上行，B电梯按下上行
35A电梯按下行，B电梯按下行
36A电梯按下行，B电梯按上下行
37A电梯按下行，B电梯按下上行
38A电梯按上下行，B电梯按上下行
39A电梯按上下行，B电梯按下上行
40电梯空时如何运转
41电梯门开时不进电梯
42进入电梯后不做任何操作
43电梯门开的时间多长，超过时间后是否自动关门
44电梯门开的时间超时后关门到最后2厘米，是否可以撬开门
45电梯门关闭后还未上升时，电梯外按下上行（或下行）按钮，电梯门是否会打开
46电梯最底层是否有下行按钮
47电梯最顶层是否有上行按钮

停靠算法测试：

2部均空闲时，采取就近原则，离乘电梯人最近的电梯优先运行；
有1部运行时，以同行方向且顺路的电梯优先运行，否则安排空闲电梯；
2部均运行时，以方向通行且顺路的电梯优先运行；
每部电梯，在电梯内部每层在上升和下降过程中，再电梯内部均申请每层停靠
每部电梯，在电梯内部每层在上升和下降过程中，再内部没有任何申请的情况下，在电梯外部均申请每层停靠
每部电梯，在电梯内部每层在上升和下降过程中，再电梯内部均申请每层停靠，在电梯外部也申请每层停靠
电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来
电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
类似7、8测试步骤地随机测试，在电梯内部和外部均有不同组合申请的情况下，验证楼层停靠是否准确和合理。
电梯的平稳性，是否会上升过快或者下降过快，造成人体不适应反应

可靠性：

1无任何申请的时候，可以长时间停留在某层，并且门是关闭的
2门关上的一刹那出现障碍物。
3长期有障碍物在门口堵住，电梯应该也不会关门或上升和下降
4同时按关门和开门按钮。
5快速交替按关门开门按钮
6点击当前楼层号码。
7快速点击不同楼层
8上升到顶层后，电梯中的原有下楼请求均会被取消
9下降到负楼层后，电梯中的原有上楼请求均会被取消
10电梯外部同时按上键和下键会怎样。
11长按打开按钮，电梯门是否持续打开
12突然停电或超载时的情况，电梯（停靠、正在上升、正在下降）不会坠落，电梯门可以通过外力13打开，并且紧急电话可用
14电梯运行中，申请马上要经过的楼层停靠，电梯应该不会停靠。
15在电梯里面蹦跳，电梯不会出现不稳定的情况。
16电压不稳定的情况下的电梯运行情况
17电梯不能正常工作的时候是否有监控系统自动报警
18电梯不能正常工作的时候，是否有流程可以精确的指定到人进行所有故障解决的高效处理

易用性：

1电梯的按钮的设计符合一般人使用的习惯吗．
2按钮是否考虑残疾人和小孩儿
3楼层显示屏是否处于电梯的上部，方便别人看到
4可维护性
5是否有方便维修和维护电梯的工作条件（竖井通道、统一断电等）
6电梯的常用配件是否容易更换
7电梯的维修成本如何
8电梯的安装、维护、测试
9超过维修年限，是否可以正常运转

视频播放器测试点

UI测试：

1导航栏元素位置、大小、颜色等要素是否一致/是否符合UI效果图；

2导航栏视频分类下拉框位置、颜色、按钮是否正确

3鼠标滑过、点击时、点击后按钮状态是否有相应颜色、状态变化；

4视频列表页面title、视频图片、视频title、是否付费等元素的颜色、大小、位置等是否正确；

5视频播放页面：视频title、视频默认加载图、播放按钮、目录、视频列表、视频介绍等元素位置、大小、颜色、鼠标操作时状态是否与预期一致；

6视频播放时进度条、快进按钮、快退按钮、播放按钮、暂停按钮位置是否正确

功能测试：

1首先判断用户是否登录，未登录不能进入主页（应提示用户先进行登录），已登录状态用户可以进行视频观看；

2导航栏下拉框是否可以正确打开和关闭，打开和关闭时的状态是否和预期一致；

3鼠标滑过、点击时、点击后相应条目的状态是否和预期一致；

4点击相应条目时，页面右边是否同步切换至相应页面，是否有延时、卡退、切换错误等情况；

5视频播放页面鼠标滑过、点击时、点击后视频对应条目、标题是否有相应状态变化（具体变化状态根据产品原型进行分析），点击后是否能够正确跳转至相应的视频播放界面；

6判断用户点击的视频属于免费还是付费，如果为免费则所有人均可以进行观看，如果为付费则要判断用户是否付费，如果已经付费则可以进行观看，如未支付则提示用户先购买后再进行观看并提供支付入口或者联系客服进行支付的方式；

7进入视频播放界面判断当前视频title是否和用户上一步点击的视频title一致；

8视频默认加载图是否显示正确或者显示异常等情况；

9视频播放按钮是否可以点击，点击后视频是否正常播放；

10视频目录是否显示正确，如有子列表是否正常显示，如果没有子列表是否有相应提示（具体效果根据产品原型进行分析）；

11视频介绍是否与当前视频一致，讲师是否一致等情况；

12点击播放后进度条是否随之变化；

13视频快进、快退、暂停、播放是否可以正常使用，是否有卡顿、延时、闪退等情况；

14播放完成后是否自动切换下一视频（如有多节视频情况下，如果只有一条子视频的情况下，播放完成后是否关闭当前页面或者给予用户相应提示），如果需要手动切换是否有相应的友好提示；

15视频播放时声音、画面是否一致或者是否有异常等情况；

16视频最大化、全屏、最小化是否可以正常使用，切换时是否有卡顿、延时等情况；

17当前视频与其他视频来回切换时，视频是否有卡顿、延时等情况；

18电脑关机或者其他异常情况下，视频是否会保存播放记录，下次进入观看时是否继续上次的播放记录继续播放；

兼容性测试：

平台兼容性：Windows、Mac

系统兼容西：Win7、Win10、Mac

屏幕分辨率：不同电脑显示器分辨率不同，视频相关页面是否有模糊、适配是否合理；

播放器是否与其他类型播放器冲突（例如音乐播放器打开后，视频是否暂停还是继续播放）；

网络测试：

1网络切换测试：无线网与宽带；

2弱网测试：弱网情况下视频是否卡顿、画面是否失帧；

3无网络状态进入是否会有相应提示；

4网络切换时视频是否暂停、保存当前播放状态；

易用性测试：

1界面是否一目了然（比如：视频title、片头、片尾、视频画面等）；

2视频页面操作是否方便，菜单栏是否正确、易上手；

3进度条拖拽使用起来是否方便；

4视频是否具有视频记忆功能/是否保存当前播放进度

三角形的测试设计点

在三角形计算中，要求三角形的三个边长：A B C 。           

          1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。

          2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。

          3、若是等边三角形，则打印：“等边三角形”。

          4、画出程序流程图并设计一个测试用例。

          分析一下：

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

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

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

            4、构成等边三角形的条件：三条边都相等。

           那么用什么样的设计方法进行测试用例的设计呢？

              一、等价类划分：三角形三条边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、少于三个数

朋友圈点赞的测试用例的设计点
点赞不同类型的朋友圈：
1，有图片的
2，纯文字的
3，音频转发的
4，好友的
5，不同分组的
6，转发的朋友圈
7，自己的朋友圈
8，新朋友的朋友圈
点赞不同时间的朋友圈：
9，一周内
10，一年内
11，刚刚发的
次数：
12，1次
13，两次
14，多次
地点：
15，国内和国外
16，不同省份
容错：
17，网络不佳
18，断网
19，屏幕卡死
20，刚删除的朋友圈
21，点赞->取消->点赞
性能：
22，点赞显示的速度
23，一分钟可以给不同朋友圈点多少个赞
兼容
24，不同操作系统
25，不同硬件
安全
26，携带病毒的推送
27，需要隐私信息的朋友圈
28，内容有诈骗等不良信息
29，点赞过程给设备带来病毒
界面
30，图标简洁，美观

微信发红包

1、功能测试
1）发给单个好友
① 正确的金额+无留言+无表情
② 错误的金额+无留言+无表情
③ 正确的金额+有留言+无表情
④ 错误的金额+有留言+无表情
⑤ 正确的金额+无留言+有表情
⑥ 错误的金额+无留言+有表情
⑦ 正确的金额+有留言+有表情
⑧ 错误的金额+有留言+有表情
其中，金额（0.01-200）可以测试以下数据

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

留言可以测试以下数据

数字、中文、英文、特殊字符、表情或者他们的组合
输入超长文本时，是否会给出相应的限制或提示
包含空格
是否支持复制黏贴
留言的增删查改

表情可以测试以下数据

选择收藏的表情测试（动图/静图）
选择下载的表情测试（动图/静图）
录制表情，并添加进行测试
表情的增删查改

⑨ 点击塞钱进红包，选择零钱付款，此时需要考虑金额＞零钱，金额＜零钱，金额=零钱三种情况
⑩ 点击塞钱进红包，选择已添加的银行卡付款，此时同样需要考虑金额＞银行卡余额，金额＜银行卡余额，金额=银行卡余额三种情况
⑪ 点击塞钱进红包，选择使用新卡付款，按照流程添加新卡，此时同样需要考虑金额＞新卡余额，金额＜新卡余额，金额=新卡余额三种情况
⑫ 使用指纹确认付款（正确的/不正确的指纹）
⑬ 使用密码确认付款（正确的/不正确的密码 ）
⑭ 发送成功之后，对应的途径会减少相应的金额
⑮ 发送者/接受者可以点击红包查看到红包的具体信息，且金额，留言，表情均能正确显示
⑯ 好友点击红包之后，零钱中将增加相应的金额，再次点击之后，只能查看到红包的信息
⑰ 24小时之内没有领取的红包，将退回原账户，此时原账户的零钱将增加相应金额的金钱。24小时后好友点击红包，显示红包已过期，无法查看到红包的余额
⑱ 右上角的红包记录中，可以查看刚刚发出的红包的金额
⑲ 检测帮助中心中链接是否均可以正常跳转，查看
20 当红包超过24小时之后，则无法查看红包被每个人领取的详细信息
2）发送群红包（与发给好友的测试点相似，以下仅写出不同的部分）
① 选择为拼手气红包时，群中每个人收到的金额随机（但加起来为红包的总金额），为普通红包时，群中每个人收到的金额相同
② 红包个数（1-100）：0，1，2，大于群成员人数，小于群成员人数，等于群成员人数，99，100，101，小数，中文、英文、特殊字符、表情或者他们的组合
③ 但红包没有被抢完时，此时首次点击该红包的人可以抢到一定金额的红包，不是首次点击该红包的人只能查看该红包的信息；当红包抢完时，所有人只能查看该红包的信息。
④ 在24小时之内红包的金额被完全抢完，且此时为拼手气红包时，金额最多的人会显示为最佳手气（若有两个人取得红包的最大值时，则只有一个人会显示为最佳手气）；若没有被完全抢完，则没有最佳手气，且余额会退还到原账户
⑤ 群中所有人均可以抢红包（包括自己），每个人最多只有一次抢该红包的机会
⑥ 测试当红包个数使得每个红包分到钱小于0.01，即总金额为0.02，而红包个数为3时的情况
2、兼容性测试
1）苹果手机和安卓手机
2）苹果手机的不同版本
3）安卓手机不同的机型
4）不同分辨率
3、性能测试
1）打开红包的响应时间不能超过三秒，高并发场景下不能超过5秒
2）耗电量
3）消耗流量的多少
4）所占内存等
4、UI测试&易用性测试
1）界面的设计风格是否统一
2）界面中文字是否简洁，没有错别字
3）是否易操作，易学习，易理解
5、中断测试：前后台切换，网络异常，低电量，断电，来电，短信等
6、网络测试
1）网络兼容性：2g/3g/4g，WiFi，热点，移动/联通/电信
2）无网测试
3）弱网：延时&丢包

5.Token  session  cookie  三者有什么区别（笔试）？

令牌，是用户身份的验证方式。

最简单的token组成:uid(用户唯一的身份标识)、time（当前时间的时间戳）、sign（签名）。

对Token认证的五点认识

一个Token就是一些信息的集合；

在Token中包含足够多的信息，以便在后续请求中减少查询数据库的几率；

服务端需要对cookie和HTTP Authrorization Header进行Token信息的检查；

基于上一点，你可以用一套token认证代码来面对浏览器类客户端和非浏览器类客户端；

因为token是被签名的，所以我们可以认为一个可以解码认证通过的token是由我们系统发放的，其中带的信息是合法有效的；

session

会话，代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续。

cookie中存放着一个sessionID，请求时会发送这个ID；

session因为请求（request对象）而产生；

session是一个容器，可以存放会话过程中的任何对象；

session的创建与使用总是在服务端，浏览器从来都没有得到过session对象；

session是一种http存储机制，目的是为武装的http提供持久机制。

cookie

储存在用户本地终端上的数据，服务器生成，发送给浏览器，下次请求统一网站给服务器。

cookie与session区别

cookie数据存放在客户端上，session数据放在服务器上；

cookie不是很安全，且保存数据有限；

session一定时间内保存在服务器上,当访问增多，占用服务器性能。

session与token

作为身份认证，token安全行比session好；

Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。 而Token ，如果指的是OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对App 。其目的是让 某App有权利访问 某用户 的信息。

token与cookie

Cookie是不允许垮域访问的，但是token是支持的， 前提是传输的用户认证信息通过HTTP头传输；

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

6.性能测试的指标有哪些？

性能测试最基本要考虑以下几点：

1、时间特性，主要指的是软件产品的事物响应时间（用户发出请求到收到应答的这段时间）

2、资源利用率，包括：cpu、内存、网络、硬盘、虚拟内存（如Java虚拟机）

3、服务器可靠性，指服务器能在相对高负载情况下持续的运行

4、可配置优化性，指服务器配置优化、业务逻辑优化、代码优化等

1、响应时间

响应时间是最能反应服务器性能的指标之一，也是用户最关心的业务体验。比如登录某个商城网站时，只消耗1s钟。在进行性能测试时，是通过对事务响应时间（Transaction Response Time）来分析服务器的响应速度。

（一般响应时间在3s内，用户会感觉比较满意。在3s~8s之间用户勉强能接受，大于8s用户就可能无法接受，从而刷新页面或者离开，仅供参考）

2、吞吐量

吞吐量表示单位时间内能够完成的事务数量，因此也被称为每秒事务数（Transaction Per Second），计算方式是完成的事务数除以时间。

3、服务器资源占用

服务器资源占是指在负载情况下，系统的资源利用率。资源占用越低，说明系统越优秀。例如，cpu的占用率、内存使用率、查询Cache命令率、磁盘I/O读写速率等。

7.部门负责人的简称

PO : Product Owner，产品或业务负责人，熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员

PM ：Product Manager，产品经理，主导整个产品的规划

PM: Project Manager, 项目经理，推送整个项目的进展

BA ：Business Analysis, 业务需求分析师, 在IT公司里,BA的角色就是PM(产品经理),只是这类PM要承接某个很具体的业务或者领域

QA : quality assurance ,质量保证, 测试

TCO : Testing Coverage Outline 测试覆盖大纲，做TCO是从测试的角度分析当前被测系统有哪些测试需求、测试要点。

FE: Front-End Development，前端开发

UI: user interface ,用户界面,UI设计则是指对软件的人机交互、操作逻辑、界面美观的整体设计

UX : User Experience,又称UE, UED（产品交互设计师，用户体验师）

OP : Operations,运维

KYM ：测试分析，业务项目背景，系统，人员，测试背景

MAU : 思维导图之类的文件

ODC：Offshore Development Center，离岸开发文员，ODC服务是目前软件外包行业比较普遍的一种合作方式

RD:RD指Research and Development(研发的意思)

CTO:首席技术官也称CTO（Chief Technology Officer），即企业内负责技术的最高负责人。