测试点
软件测试 ：
软件测试的流程包括：1、测试需求分析阶段；2、测试计划阶段；3、测试设计阶段；4、测试执行阶段；5、测试评估阶段。具体而言：1、测试需求分析阶段：阅读需求，理解需求，主要是对业务的学习，分析需求点，参与需求评审会议。2、测试计划阶段：主要任务是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。3、测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。4、测试执行阶段：搭建环境，执行冒烟测试（预测试），然后进入正式测试，bug管理直到测试结束。5、测试评估阶段：出测试报告，确认是否可以上线。
测试过程中遇到了不能复现的bug的时候你怎么办：
1、遇到问题就要提，测试的工作就是不放过任何一个bug，在提交的Bug描述中需要加上一句话，那就是复现概率，尝试20次，出现1次或者尝试10次，出现2次，开发会根据bug的复现概率，调整改bug的优先级。
2、尽量回想发生问题时的复现步骤，不要漏掉任何一个细节，按照步骤的组合尝试复现。
3、保留发生bug时的log，附加到提交的bug中，希望可以通过log中找到一些蛛丝马迹。
4、与开发人员配合，让开发同学对相应地方的代码进行检查，看一下是否可以通过代码层面检查出问题。
5、在接下来的测试中，时刻保持关注，每次执行同样或者相近的步骤的时候，看下是否能够复现之前的bug。
通过以上的方法，仍然无法复现，根据bug的优先级，在上线之前对该bug进行处理，严重级别的bug，要召集项目组的成员，集合大家的力量尽可能的复现bug，不严重的bug，也不要关掉，上线后及时的关注用户的使用反馈，如果持续3或者4个版本没有出现，那么可以将bug暂时关掉了，同时关掉的时候要进行评论说明并不是因为修复，而是经过x个版本后不复现了。
3.测试过程中遇到，开发不认为是bug的bug你怎么办？
- 1.通过不同方式或者是不同的测试环境来对bug进行确认
- 2.根据需求文档对bug来进行判断
- 3.将bug的出现的频率，已经出现的方式和对应的操作步骤进行书写，将结果 截图或者是录屏
- 4.找对应的项目经理或者是客户经理来bug进行评审 5.将bug进行记录到测试总结中
4.纸杯测试
功能度：用水杯装水看漏不漏；水能不能被喝到
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
错误测试：装载高密度固体
破坏测试：检查水杯最大抗挤压和拉扯承受力
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损
震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输
外观（里面、外面）美观性
电梯空间尺寸是否和设计尺寸一致
按钮是否清晰和易懂
显示楼层的显示屏是否安装
是否联系外界的电话、紧急电话
设备检测说明书
安全规范说明书
灯
标识的承重和人数
扶手
镜子
仅提供可到达楼层的按钮
电梯制作的材料
功能测试：
测试电梯能否实现正常的上升和下降功能，每层是否都可以停靠。
每层停靠楼层是否与所按的楼层一致
电梯按键在按下时是否点亮按键灯
电梯在每个楼层的上行和下行的申请是否可以有效
电梯满负载的时候，是否会忽略其他楼层外部的上行和下行申请
电梯的两边按钮是否都可以使用，三列按钮。
电梯的楼层选择是否可以取消
电梯门的打开，关闭是否正常关闭（自动关闭）。
报警装置是否可用。（满载）
超重时是否能强制关门
超重时重新挪动一下人员是否可以上下行
与另外一部电梯之间是否协作良好。（算法）
电梯的灯光是否满足看书的要求
联系外界的电话是否可用
通风状况如何，人多的时候是否会很热，通风不畅（排气扇）
电梯里面的摄像头是否可用，拍摄是否清晰
门不夹人
伸手的话，应该不会强制关门
管理员可以和内部人通话
在各种场合下，可以强制开门
运行中时，不能按开门键，不会强制开门
在不同情况下（如：有人挡着、马上关门的时候、停电的时候、没有请求的时候…），一直按开门键和关门键
从电梯外部可以强制开门
不同温度下的测试
进入电梯，拨打手机，是否有信号
进入电梯喊话，外面是否能听到
楼层显示屏显示的楼层、以及电梯运行升降状态是否正确
两台电梯能否同时使用（或停用）
其中一台使用，另一台是否可以停用
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测试步骤地随机测试，在电梯内部和外部均有不同组合申请的情况下，验证楼层停靠是否准确和合理。
电梯的平稳性，是否会上升过快或者下降过快，造成人体不适应反应
可靠性：
无任何申请的时候，可以长时间停留在某层，并且门是关闭的
门关上的一刹那出现障碍物。
长期有障碍物在门口堵住，电梯应该也不会关门或上升和下降
同时按关门和开门按钮。
快速交替按关门开门按钮
点击当前楼层号码。
快速点击不同楼层
上升到顶层后，电梯中的原有下楼请求均会被取消
下降到负楼层后，电梯中的原有上楼请求均会被取消
电梯外部同时按上键和下键会怎样。
长按打开按钮，电梯门是否持续打开
突然停电或超载时的情况，电梯（停靠、正在上升、正在下降）不会坠落，电梯门可以通过外力打开，并且紧急电话可用
电梯运行中，申请马上要经过的楼层停靠，电梯应该不会停靠。
在电梯里面蹦跳，电梯不会出现不稳定的情况。
电压不稳定的情况下的电梯运行情况
电梯不能正常工作的时候是否有监控系统自动报警
电梯不能正常工作的时候，是否有流程可以精确的指定到人进行所有故障解决的高效处理
易用性：
电梯的按钮的设计符合一般人使用的习惯吗．
按钮是否考虑残疾人和小孩儿
楼层显示屏是否处于电梯的上部，方便别人看到
可维护性
是否有方便维修和维护电梯的工作条件（竖井通道、统一断电等）
电梯的常用配件是否容易更换
电梯的维修成本如何
电梯的安装、维护、测试
超过维修年限，是否可以正常运转
token session cookie区别
session（会话）：
当用户打开某个web应用时，便与web服务器产生一次session。服务器为了区分当前给自己发请求的是谁，给每个客户端分配了一个不同的“身份标识”。客户端发请求时需要携带该“身份标识”。“身份标识”的存储方式很多，通常使用cookie。
服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
cookie：
cookie是浏览器里面能永久存储的一种数据。
cookie由服务器生成，发送给浏览器，浏览器把cookie以key-value形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
token（令牌）：
token是用户身份的验证方式，最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库
性能测试的指标有哪些
2.并发（Concurrency）：它最简单的描述就是指多个同时发生的请求操作。（例如，1000个用户同时单击点击生成订单的操作。）
3.响应时间：指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回结果整个过程所耗费的时间
4.点击数：是衡量Web服务器处理能力的一个重要指标。它的统计是客户端向Web服务器发了多少次HTTP请求计算的。通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力。
5.资源利用率：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
6.错误率：指系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100%。
1. 不同系统对错误率要求不同，但一般不超过千分之五；
2. 稳定性较好的系统，其错误率应该由超时引起，即为超时率。
一是按职能进行分工
之所以形成一个组织，必因其具备了一定的目标。根据要达成的目标，将日常性的、重复性的、惯例性的工作谓之“职能”，交由相对固定的人或部门，是分工的第一种模式。比如建筑公司的投标是日常性工作，交由计划部负责，即是一种职能分工。职能分工的关键是范围全覆盖，边界清晰无真空、无重复。
二是按任务进行分工
无论肩负职能的部门，还是管理项目的人，均可分配临时发生的、突发性的、非惯例的工作。一项任务也是一个短期的项目，有明确的起止时间要求。例如，项目部的临设建设只会一次，可以交由具有相关性的项目部办公室作为一项任务来落实。任务分工的关键是一个任务只能由一个人负责，其他人只能是配合。
三是按空间进行分工
一个项目，特别是长距离、空间不连续的项目，可以根据空间特点分为若干个工区。每个工区是相对完善的管理组织，项目部通过工区实施管理活动。例如，某野外作业输水管线工程，即可按段落分为多个工区，同时作业，项目部居中调度资源、协调各方。按空间分工的关键是分人分资源的同时，要分责任，并且要做好监控。
四是按时间进行分工
某项工作，时间跨度很大，或办理过程中涉及不同专业的多个环节的时候，可按时间或流程进行分工。例如，负责办理建设审批手续的人，会在立项、可研、地勘、施设等不同阶段，流程和时间都很长，需要不同的人参与到不同的阶段。按时间分工的关键是一定要有一个总牵头人、总责任人，他要负责全过程的监督、检查和协调。
1.GM：General Manager 总经理
2.VP：Vice President 副总裁FVP（First Vice President）第一副总裁 AVP：Assistant Vice
3.President 副总裁助理 HRD：Human Resource Director 人力资源总监 OD：Operations
4.Director 运营总监 MD：Marketing Director 市场总监 OM：Operations Manager 运作经理
5.PM：Production Manager生产经理、Product Manager产品经理、Project Manager项目经理) 注：这里面变化比较多，要结合谈话时的背景来判断究竟是指哪种身份）
6.BM（Branch Manager）部门经理 DM（District Manager）区域经理 RM（Regional Manager）区域经理 广告公司职位英文对照:
7.AAD〔Associated Account Director〕副客户总监 AAD〔Associated Art Director〕副美术指导
8.ACD〔Associated Creative Director〕副创作总监 AD 〔Account Director〕客户服务总监、业务指导
9.AD〔Art Director〕美术指导（在创作部可以独挡一面执行美术指导工作的美术监督）
10.AE〔Account Executive〕客户执行、客户服务、客户主任；预算执行者，负责广告代理商和广告主之间的一切有关业务，观念，预算，广告表现之联系
11.AM 〔Account Manager〕客户经理
12.AP〔Account Planner〕客户企划（分策略企划和业务企划两种） ASM〔Area Sale Manager〕大区销售经理
13.CVO：VC reception 风险投资商接待专员，首席财务官的另一重要助理。
14.CWO：Writer 首席网络写手，负责将小事扩大化，通过炒作达到扩大网站知名度的目 的，其下属为COO。
15.CXO：Xingxiang（因为中国特有，所以只能用汉语拼音表示） 网站形象代言人，一般 由学历不高且没有任何网络知识的年轻人担任。
16.CYO：Yearly 公司元老，这是一个荣誉称号，授予在同一网站工作满一年的员工（这个 职位通常空缺）。
17.CZO：Zero 最后离开公司的一个人，负责关好门窗，将公司大门钥匙交给物业管理处， 可以由CAO兼任。
浙公网安备 33010602011771号