面试题

面试题

1 测试流程？

项目启动后，测试人员尽早找开发人员拿到接口文档，获取接口文档后进行接口用例的编写和调试，
完成后部署到持续集成的测试环境中，进行接口的日常监控，
定期对接口脚本的维护更新，接口异常的处理。

2 测试过程中遇到不能复现的BUG 时候你怎么办？

一、一定要提交。
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。

二、程序不是测试人员写的，出问题也不是测试人员的原因。 

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

三、下次再遇到的时候，拉他们来看就可以了。 

因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。
四、你可以告诉程序员，测试过程是没有错误的。 

测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
五、问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。

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

3 测试过程中遇到 开发不认为的BUG怎么办？

1找到需求文档或者是原型图进行匹配
2尝试多种测试环境和多种测试方法来确认是否为bug
3整理bug的复现的步骤和出现的频率
4开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug
5将客户经理 测试 测试经理和项目经理进行确认会来判定是否为bug
6测试人员需要将bug整理并写入测试总结中

4 经典用例设计 ？

杯子

功能测试(Function test)
能否装水，除了装水， 能否装其他液体。比如可乐，酒精
能装多少ML的水  杯子是否有刻度表
杯子能否泡茶，跑咖啡     杯子是否能放冰箱，做冰块
杯子的材质是什么（玻璃，塑料,黄金做的）

界面测试(UI Test)
外观好不好看。 什么颜色
杯子的形状是怎么样的。  杯子的重量是多少
杯子是否有异味    杯子的图案是否合理

性能测试(performance test)
能否装100度的开水 (泡茶)   能否装0度冰水
装满水，放几天后，是否会漏水
杯子内壁上的涂料是否容易脱落。   杯子上的颜色是否容易褪色或者脱落

安全性测试(Security test)
制作杯子的材料，是否有毒   放微波炉里转的时候，是否会爆炸, 或者杯子是否会熔化。
从桌子上掉到水泥地上是否会摔碎。   杯子是否容易长细菌
杯子是否有缺口，会划坏嘴巴    杯子内壁上的材料，是否会溶解到水中
杯子破碎后，是否会对使用者造成伤害

可用性测试(Usability Test)
杯子是否容易烫手   杯子是否好端，好拿
杯子的水是否容易喝到   杯子是否有防滑措施

购物车

界面测试：
　　·打开页面后，页面的布局是否合理，显示是否完整；
　　·鼠标浮动在购物车按钮，迷你购物车界面显示是否正常；
　　·不同卖家的商品在不同的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 三者的区别？ （笔试题）

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

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

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

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

1.用户数：注册用户数、在线用户数、并发用户数
2.事务的响应时间：事务的响应时间就是衡量用户执行这些操 作集所花费的时间
3.每秒点击数：每秒点击数是指每秒钟向web服务器提交的HTTP请求数，它是衡量服务器处理能力的一个常用指标。
4.吞吐率：吞吐率通常指单位时间内从服务器返回的字节数
5.业务成功率：指多用户对某一业务发起操作的成功率
6.TPS--吞吐量：TPS表示服务器每秒处理的事务数，他是衡量系统处理能力的一个非常重要的指标
7.资源利用率：资源利用率就是指资源的使用情况
8.QPS ： 每秒查询率
9.错误率 ：一批请求中结果出错的请求所占比例

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。
质量部是明确规定全厂各部门、各环节以及每一个人在质量工作上的具体任务、责任、要求和权力，以保证产品质量的一种责任制度。