和分析能力.
本质上一个电梯是一个太大的范畴，实际测试的过程中很少一下子会有这么巨大的功能让你测试的。
与其说让你设计测试用例，其实好不如说让你想一个电梯有什么功能,然后根据功能再来考虑测试用例,所以更多的
是考察思路,在实际的测试工作中,如果突然有个人说我今天完成了一个电梯的功能,找个人给我测一下吧。
那么多半这个项目就是个让测试欲哭无泪的项目。
不过既然面试有人问这样的问题，那么就分析分析吧，以下我是把电梯转化为类似互联网产品来做的分析，
完全是个人想法,一定有非常多欠缺。
## 后端服务组件和客户端分离(Client-Server/MVC)
首先其实对把一个电梯分成不同的组件：
- 驱动服务: 可以使电梯上下行(后台服务)
- 门: 开门关门(后台服务)
- 电梯操作面板: 人机界面,担当用户和电梯的一个中间人作用,将用户操作转化为指令来控制电梯 (app/web page)
(如果简单的话可能操作命令转换就都在这个地方了，如果复杂可能还有一个控制系统层)
- 指令控制系统(调度系统,监听器或者Queue)
- 呼叫监控系统:(可以暂时不考虑)
这里就先考虑简单的情况，电梯操作面板模块之内将操作转换成指令给电梯的驱动和门服务
## 逐个组件来考虑用例
### 驱动服务可能包含的功能点有如下:
- 上行, 但是上行有极限位置(可配置)，按照指定步进数量上行
- 中途等待
- 步进距离(一层距离)可以配置
- 下行,下行位置(可配置)，按照指定步进数量下行
- 承载重量
- 可靠性监测，使用寿命监测
- 故障监测
这里注意如果测试电梯产品和测试指定某个大楼的电梯,测试用例的设计考虑点是稍有不同的，如果是电梯产品他就有电梯的配置项需要测试，
如果是测试制定电梯,那么配置项就可以忽略了，配置的就是你目前的配置。
### 门服务
关于门的服务可能会想到的是:
- 开门
- 关门
- 可靠性
对于开门这个功能的测试用例测试可以围绕:
- 接收到开门指令开门并且只做开门
- 在电梯运动过程中接收到开门指令不开门
- 接收不到开门指令则不开门
- 开门指令被中断
- 开门接到后的进行开门的响应时间
关门是类似，但是关门需要考虑超重情况下不能关门.
可靠性考虑多少次开门关门之后开门关门的机械组件才失效
### 电梯操作面板
操作面板这块实际上分为界面控件状态改变和指令转换两大块,在通过操作操作面板按钮后，同时
改变按钮状态以及发送正确指令,而指令处理这块就可
- 门开关按钮, 开关有效,开关无效
- 楼层按钮，启用,取消，灯亮，灯关
- 电梯上下调度, 多个按钮被按下之后,结合电梯自己所在位置决定运行方案
- 易用性等，因为是见人的地方，所有就有usability 测试
### 指令控制系统
指令控制系统可以认为根据电梯运行时的上下文,调度电梯运行的一个模块,这里面应该是根据某种规则
发出实际控制电梯的信号，具体什么的规则其实很难断定。
### 扩展到多个电梯的调度测试
有可能会有多个电梯的调度，同样也是需要一套规则再来进行测试的
这个文章写的有点粗糙,主要凭空去想这些case太伤脑袋，但是总体而言个人认为这是一个考虑问题的方向，同时个人觉得在一个短时间内
针对这样一个系统说写出很多测试用例，其实也就是呵呵了。
也许有更好的方法来总结这样的测试,可能类似于探索性测试之类的，希望有人能够指正。
同时我们也可以看到设计测试用例要包含多少东西,测试需要了解:
- 产品需求(没有需要推测:))
- 功能
- 可靠性
- 性能
- 扩展性
- 可用性
从high level看可能还有更多,这些一个人都可以搞定的话,这个人还是人吗?而在实际的工作中这些会有都
多少人都进行相关类型的测试？不说进行这样的测试，估计连衡量这些测试的优先级都不会,有人说的头头
是道，可是真的有多少实践呢？
生活可能就是这样的,说的天花乱坠的,可能其实都是别人的经验,如果真的自己动手做的时候,就说需要找人做.
然后他就成为领导了.也有更大的领导在说一个什么事情的时候，就接入一个宏大的名词，然后大领导一听，对，
然后他也成了领导了. 而做事的人苦苦的寻觅着那些宏大名次的解答，更为关键的是,很可能是你一个人去寻找
很多宏大名词的解答.
