软件测试流程

1. 测试流程

1、测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议。
2、测试计划阶段：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。
3、测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。
4、测试执行阶段：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理直到测试结束。
5、测试评估阶段：出测试报告，确认是否可以上线。

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

一、一定要提交。
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。

2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。

3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。

4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。

5． 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。

二、程序不是测试人员写的，出问题也不是测试人员的原因。
至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。测试人员的任务只是尽力重现问题，而不是必须重现。

三、下次再遇到的时候，拉他们来看就可以了。
因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。

四、你可以告诉程序员，测试过程是没有错误的。
测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。

五、问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。

Bug英文单词，本意是臭虫、缺陷、损坏、犯贫、窃听器、小虫等意思。现在人们将在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题统称为bug(漏洞)。 由于现在社会的发展，bug另有一种引申意义，用来形容某事物厉害的超乎想象，BUG可以使电脑系统崩溃、容易被施诈者攻击，现有修复漏洞的工具。

3. 测试过程中遇到 开发人员不认为的bug你怎么办？

首先，将问题提交到缺陷管理库里面进行备案；然后，要获取判断的依据和标准：根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；根据用户的一般使用习惯，来确认是否是缺陷；与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪；等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

4. 经典用例设计

纸杯测试用例

一、功能测试

 1. 纸杯规格
能放多少水、是否符合需求
地盘直径是多少（有纸杯托盘，是否符合标准，不能太大，也不能太小）
存放时间、存放环境（湿度、温度等）
不能装哪些液体
角度是否合理

二、性能测试

 1. 地盘是否平稳
 2. 角度是否合理
 3. 是否会漏水
	时间（一天、两天。。。）
	温度（零度N多度、200度、300度等）（兼容性测试）
	液体（自来水、牛奶、石油等等、酸性、碱性）（兼容性测试）
 4. 纸杯是否容易变形、硬度是否足够（压力测试）
	装开水或装满水的时候、保持不变形的时间长度是多少（是否符合设计要求）
 5. 是否环保，是否会产生化学反应，产生有毒物质（安全测试）
	健身球
 6. 从不同高度摔下来的损坏程度（压力测试）

三、界面测试

 1. 根据该纸杯的用户进行界面测试：小孩、成年、老人（图片设置、吸引客户）
	比如这杯子针对的是幼儿园（喜洋洋、灰太狼什么的）
	政府机构（党徽等等）、不能有喜洋洋、张曼玉等图标
	公司（公司图标、公司名称等）
比如：广州的法论功图标，客户就很反感：
		北方烽火的无线业务界面有威武的警察图片、大锅棚（高技术工作、自豪）等
 2. 是否有相应的提示：
防止烫伤、垃圾回收、年龄限制等
可口可乐公司的烫伤提示，苏果、沃尔玛购物袋（为了防止窒息、请远离儿童，小孩拿玩）
 3. 图标布局是否合理
中间、大小要合适
 4. 纸杯上的字体是否美观、是否有错别字
 5. 纸杯的图标、文字等印刷是否完整
深圳中兴纸箱
 6. 图标是否容易脱落

四、人性化测试

 1. 是否会产生有毒物质（特别是装了开水的时候）
 2. 水杯的手感如何、口感如何（易用性）
 3. 是否有利于叠在一起存放，使用时是否容易分开
 4. 外观是否适合拿起

购物车测试用例

界面测试：
　　·打开页面后，页面的布局是否合理，显示是否完整；
　　·鼠标浮动在购物车按钮，迷你购物车界面显示是否正常；
　　·不同卖家的商品在不同的table区域显示，区分明显；
　　·页面的tooltips能正常显示；
功能测试：
　　·所有页面链接功能正常，可以点击到正确页面；
　　·页面关联本地软件阿里旺旺的icon点击后，能打开软件；
　　·从商品信息页面添加的商品能显示在购物车中；
　　·购物车页面打开的同时，在其他页面添加了商品，购物车页面刷新后，新的商品能显示；
　　·若未登录，点击购物车，则提示用户输入用户名和密码，或者提示其他的非注册用户购物方式；
　　·商品未勾选的状态下，结算按钮是灰色无法点击的；
　　·勾选商品后，已选商品的总价会显示，结算按钮变高亮可点击工作；
　　·勾选商品，点击结算按钮后，进入确认订单信息页面；
　　·购物车页面中，可以对添加的商品信息做信息的修改，并自动保存成功；
　　·卖家在线的时候，旺旺icon高亮，反之，灰色；
　　·购物车有商品降价或者库存告急的，那么点击对应的tab，降价或者告急商品会归类后显示；
　　·购物车能添加的商品种类是有数量上限的；
　　不要的商品，可以删除；
　　（其他特有的功能不做赘述，只讨论常见通用功能）
性能测试：
　　·打开购物车页面要多久；
　　可用性测试：
　　·快捷键功能知否支持
兼容测试：
　　·不同浏览器上的测试功能是否正常；
　　·app上测试

电梯测试用例

一、如果给你一台电梯，请问你如何测试它，分析如下 1.功能：上升、下降、停止、开门、关门、梯内电话、灯光、指示灯等； 2.性能：速度、反应时间、关门时间等；3.压力：超载、尖锐物碰撞电梯壁等； 4.安全：停电、报警装置、轿箱停靠位置、有人扒门时的情况等；5.可用性：按键高度、操作是否方便、舒适程度等；6.UI：美观程度、光滑程度、形状、质感等；7.稳定性：长时间运行情况等； 8.兼容性：不同电压是否可工作、不同类型电话是否可安装等。 其实在简单分析的过程中，发现许多东西根本测试不全，比如电话、灯光、材质、调度程序、可维修性等，当发现在一个用例中无法说清楚时，这些应该拆分开来分别测试。可以告诉主考官，你需要模块化地测试电话、灯光等。再有在一起的组装测试。

登录测试用例

一、界面
1、登录界面是否清晰合理美观，无乱码（文字简洁、无错别字）

二、功能（主要采用等价类、边界值方法）
1、输入正确的用户名、密码，是否登录成功
2、输入错误的用户名或者密码，登录失败有没有提示（用户名或密码为空）
3、用户名、密码支持的字符类型
4、输完用户名之后按Tab键是否能到输入密码的框，输完密码之后按回车能否登录
5、如果有记住用户名密码的功能，下一次打开页面，是否默认有用户名密码
6、用户名、密码是否大小写敏感
（具体还可以考虑：这个用户名密码是否已注册）

三、安全性
1、在登录页面，输入的密码是否隐藏显示
2、多次登录失败，系统会不会阻止后续的尝试以应对暴力破解
3、用户名、密码能否支持复制、黏贴
4、在浏览器中直接输入登录成功后的URL地址，验证是否会重新定向到用户登录界面
5、密码输入框内的密码是否都可以在页面源码模式下被查看

四、兼容性
1、不同操作系统上同版本的浏览器能否正常打开登录界面，界面正常
2、相同操作系统的不同浏览器能否正常打开登录界面，界面正常
3、这个登录界面能否在移动手机端正常打开

五、性能压力
1、输入正确用户名、密码之后点击登录按钮，直到登录成功打开页面，需要多长时间（小于3秒）
2、多个用户同时进行登录操作，相应登录的时间是否会变长（小于5秒）

多部电梯具有联动性

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

功能测试：
测试电梯能否实现正常的上升和下降功能，每层是否都可以停靠。
每层停靠楼层是否与所按的楼层一致
电梯按键在按下时是否点亮按键灯  电梯在每个楼层的上行和下行的申请是否可以有效
电梯满负载的时候，是否会忽略其他楼层外部的上行和下行申请
电梯的两边按钮是否都可以使用，三列按钮。
电梯的楼层选择是否可以取消   电梯门的打开，关闭是否正常关闭（自动关闭）。
报警装置是否可用。（满载）    超重时是否能强制关门
超重时重新挪动一下人员是否可以上下行    与另外一部电梯之间是否协作良好。（算法）
电梯的灯光是否满足看书的要求   联系外界的电话是否可用
通风状况如何，人多的时候是否会很热，通风不畅（排气扇）
电梯里面的摄像头是否可用，拍摄是否清晰
门不夹人   伸手的话，应该不会强制关门
管理员可以和内部人通话    在各种场合下，可以强制开门
运行中时，不能按开门键，不会强制开门
在不同情况下（如：有人挡着、马上关门的时候、停电的时候、没有请求的时候…），一直按开门键和关门键
从电梯外部可以强制开门   不同温度下的测试
进入电梯，拨打手机，是否有信号    进入电梯喊话，外面是否能听到
楼层显示屏显示的楼层、以及电梯运行升降状态是否正确
两台电梯能否同时使用（或停用）

其中一台使用，另一台是否可以停用
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测试步骤地随机测试，在电梯内部和外部均有不同组合申请的情况下，验证楼层停靠是否准确和合理。
电梯的平稳性，是否会上升过快或者下降过快，造成人体不适应反应

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

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

视频播放器测试用例

功能测试：
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
屏幕分辨率：不同电脑显示器分辨率不同，视频相关页面是否有模糊、适配是否合理；
播放器是否与其他类型播放器冲突（例如音乐播放器打开后，视频是否暂停还是继续播放）；
网络测试：

网络切换测试：无线网与宽带；
弱网测试：弱网情况下视频是否卡顿、画面是否失帧；
无网络状态进入是否会有相应提示；
网络切换时视频是否暂停、保存当前播放状态；
易用性测试：

界面是否一目了然（比如：视频title、片头、片尾、视频画面等）；
视频页面操作是否方便，菜单栏是否正确、易上手；
进度条拖拽使用起来是否方便；
视频是否具有视频记忆功能/是否保存当前播放进度

三角形测试用例

一、等价类划分：三角形三条边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(A^2+B^2=C^2) (17)
(B=C)and(B^2+C^2=A^2) (18)
(C=A)and(C^2+A^2=B^2) (19)
是否是等边三角形 :
(A=B)and(B=C)and(C=A) (20)
(A!=B) (21)
(B!=C) (22)
(C!=A) (23)
三角形测试用例：
序号 [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] 无效等价类 错误提示

朋友圈点赞测试用例

功能测试
1.点赞后是否显示结果；
2.点赞后是否可以取消；
3.点赞取消后是否可以重复点赞；
4.共同好友点赞后，是否有消息提醒；
5.非共同好友点赞后，是否有消息提醒；
6.点击点赞人昵称，是否可以跳转到他/她的主页；
7.自己能否给自己点赞；
8.屏蔽了该用户，共同好友点赞是否提示；
9.点赞人有备注时，是否展示备注昵称；
10.点赞后删除好友，是否继续展示其点赞；

UI界面测试
1.界面是否简介美观；
2.点赞后动态特效是否正常显示；
3.朋友圈界面图片是否正常显示；
4.朋友圈界面文字是否正常显示；

性能测试
1.点赞人数过多是否能正常显示；
2.同一时间点赞人数过多是否正常收到提示；、

安全测试
1.发送部分可见的朋友圈，其余人不可见；
2.发送部分可见的朋友圈，点赞后共同好友不可见；

弱网测试
1.弱网环境下，点赞是否成功；
2.弱网环境下，点赞的时间；

易用性测试
发送部分可见，是否可以沿用上次的名单；

微信发红包测试用例

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 三者的区别？

• cookies
  用户登录以后，在浏览器端生成一个文件，保存在浏览器的客户端
  一般存储用户的身份信息
  可以删除，删除后重新登录可以再次生成
  使用不同的浏览器，电脑登录同一网站，会产生不同的cookies
  有的系统会通过cookies存储用户行为习惯

• session
  登录后服务器端发送一个随机的ID值，来进行用户身份的识别
  session的有效性，是在代码中进行设计的，一般是30分钟
  session只针对一个应用服务器有效

• token
  登录后，服务器端发送一个token令牌
  token也有时效性
  token可以支持多平台访问

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

• RT：响应时间
• TPS：每秒完成事务数
• CPU性能指标：利用率、负载
• Mem：内存性能指标，可用物理内存、虚拟内存使用率
• Disk：磁盘性能指标，Disk Time、IO等待
• NetWork：网络指标，带宽使用率、任务队列长度

TCP连接数，可以用netstat命令统计得到
中间件建立的线程池，监控线程状态
JVM性能指标，GC情况、Heap使用情况
CPU负载队列长度
服务器与中间件之间建立的连接数及连接状态

一般性能分析的过程

1. 检查RT 客户端响应时间
2. 检查TPS TPS大时RT小， 说明性能良好
3. 检查负载机资源消耗 检查CPU使用率
4. 检查被压服务器的资源消耗 CPU 、 内存、磁盘IO、带宽、响应时间
5. 检查中间件配置 确定是否有配置参数问题
6. 数据库服务器 CPU、内存、IO繁忙程度、数据库监控。

7. 如何合理安排测试团队人员分工的问题？

1 : 项目组三个人，后端6个，前端两个，测试一个  
	一个后端负责加盐加密，一个负责数据抓取，一个负责封装执行函数，一会负责三方，一个是架构师
2 : 小公司的话  一个前端  俩个后端  一个运维 一个测试  还有一个组照

8. 部门负责任的简称？

行政部 Administrative Department，简称为AD。
人力资源部 Human Resources Department，简称为HRD。
市场部 Market Department，简称为MD。
技术部 Technology Department ，简称为TD。
客服部 Customer Service Department,简称为 CSD

其他部门英文简称：

1、财务部 Finance Department ，简称为FD。
财务部是指在本机构一定的整体目标下，关于投资，筹资和营运资金，以及利润分配的管理的部门。

2、制造部 Manufacture department ，简称为MD。
制造部 负责对各种设备事故、工伤、伤亡事故、急性中毒事故以及环境污染事故的调查处理，并制订改进措施计划。

3、供应部 Supply department ，简称为SD。
供应部即供给所需的财物。

4、质量部 Quality Department ，简称为TD。
质量部是明确规定全厂各部门、各环节以及每一个人在质量工作上的具体任务、责任、要求和权力，以保证产品质量的一种责任制度。