测试/开放、智力

测试

1、测试一部电梯

功能测试—单个功能：
1、电梯内分楼层键是否正常
2、电梯内开关门键是否正常
3、电梯内的报警键是否正常使用
4、电梯外的上下键是否正常
5、同时关注显示屏，电梯内外的显示屏显示的电梯层数、运行方向是否正常
6、有障碍物时，电梯门的感应系统是否有效
功能测试—逻辑业务/功能交互
1、功能与功能模块间的集成，可根据电梯当前状态是上行、下行还是停止来设计测试点，以保证覆盖率
电梯当前状态是上行时，有人在X楼按下上升/下降键，电梯是否会停止
电梯当前状态是下行时，有人在X楼按下上升/下降键，电梯是否会停止
在搭载满员的情况下，如有人在X楼按下上升/下降键，电梯是否会停止
2、功能设备与设备间的集成，关注功能接口，比如：
电梯和大楼层，电梯和摄像头，电梯与空调，电梯和对讲机（报警装置），电梯与显示屏，电梯与其他电梯的协作能力
例如：一栋楼有2部电梯，一部停在2楼，一部停在4楼，有人1楼按电梯，是否2楼的电梯下降到1楼开

性能测试
1、测试电梯负载单人时的运行情况（基准测试）
2、多人时的运行情况（负载测试）
3、一定人数下较长时间的运作（稳定性测试）
4、更长时间运作时的运行情况（疲劳测试）
5、不断增加人数导致电梯报警（拐点压力测试）

6、电梯速度
界面测试
1、查看电梯的外观，按钮的图标显示，电梯内部张贴的说明（比如报警装置的说明、称重量等）
易用性测试
1、楼层按键高度（小孩和一些身高矮的用户会按键不方便）
2、电梯是否有地毯、

3、夏天是否有空调、

4、通风条件、

5、照明条件、

6、手机信号是否通畅
7、电梯是否有扶手，是否有专针对残疾人的扶手等等
兼容性测试
1、电梯的整体和其他设备的兼容性，与大楼的兼容，与海地隧道的兼容等等
2、不同类型的电压是否兼容
安全性测试
1、下坠时是否有制动装置
2、暴力破坏电梯时是否报警，超重是否报警
3、停电情况下电梯是否有应急电源装置

对测试的看法

1、发现错误、分析错误

2、作者：梁涛
链接：https://www.zhihu.com/question/20269633/answer/14844243
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。


0. 责任感：这恐怕是开发和测试之间最大的区别。就Bug在整个开发活动中造成的损失来看，在分析、设计处是最小的，而在测试时是最大的，依赖于具体使用的开发工程模型。每个环节引入的Bug都会在下一环节被放大，导致修正成本迅速扩大，到了测试这里再发现和修正Bug，返工成本相当高，拦截和修正的责任重大。1. 成就感：责任感越大，成就感也越大，相伴相生。在测试阶段能测出大Bug并修正，任何人都会感到自豪吧。2. 实践经验密集型岗位：相较于开发，测试需要更多更齐备的实践经验。从正向的系统知识、架构设计，到反向的破坏性思维，无所不包。开发人员通常在理想条件下编程，适时处理一些预想中的异常或错误;而测试则必须确保当这些异常或错误出现时处理代码能正确工作。这种检验工作远比开发工作困难得多。同样的业务代码，开发只需要面对少数“正常执行流”即可，而测试则需要面对大量的“异常执行流”。只有实践经验丰富者才能保持高测试效率。3. 煎熬的协作关系：开发向来难以认同测试的重要作用。还记得刚开始做开发时，SQA老是过来挑我的错，搞得我很恼火。但是Boss却说如果项目顺利收尾，我还必须请SQA吃顿饭，要不是他们的努力，说不定还得延期，严重的话甚至会导致用户体验指数下降，损失远远大过面子。幸而SQA组的同事都比较客观（天天看数据想不客观都难），他们是真正看结果不问过程的角色，一切就事论事。这一点，单向思维的开发人员很难企及。写的代码越多，越认同测试的重要。曾经听过一个很贴切的比喻：写程序的人就像在造没有护栏的桥，自己去走那肯定安全无虞，那怕摸黑也不至于掉河里去;测试则像给桥修护栏的，让桥的普通使用者也能像开发那样来去自如。从这一点上说，测试远比开发重要。我也想过是不是转任测试，但耐性不够，忍受不了测试那种枯燥，是以非常佩服能在测试上坚持五年十年的人。至于测试的魅力么，能说是“与人斗其乐无穷”吗？嘿嘿。

智力：

1、铅笔用途

2、智力题