电梯功能的测试用例和测试方案

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

2、以告诉主考官，你需要模块化地测试电话、灯光等。再有在一起的组装测试。二、下面是详细的测试点：需求测试：查看电梯使用说明书、安全说明书等界面测试：查看电梯外观功能测试：1 .测试电梯能否实现正常的上升和下降功能。2 .电梯的按钮是否都可以使用。3 .电梯门的打开，关闭是否正常。4 .报警装置是否可用。5 .与其他电梯之间是否协作良好。6 .通风状况如何。7 .突然停电时的情况。8 .上升途中的响应。1）电梯本来在1 楼，如果有人按18 楼，那么电梯在上升到5 楼的时候，有人按了10 楼，这时候是否会在10 楼先停下来；2）电梯下降到10 层时显示满员，此时若8 层有人等待电梯，是否在8 层停。9

3、 .是否有手机信号可靠性：1 .门关上的一刹那出现障碍物。2 .同时按关门和开门按钮。3 .点击当前楼层号码4 .多次点击同一楼层号码5 .同时按上键和下键易用性：电梯的按钮的设计符合一般人的习惯吗用户文档：使用手册是否对电梯的用法、限制、使用条件等有详细的描述压力测试：1 .看电梯的最大承重量，在负载过重时报警装置是否有提醒2 .在一定时间内不断让电梯上升、下降 稳定性测试： 看电梯在最大负载下平稳运行的最长时间如何编写测试用例:1、了解软件的原始 需求（测试目的）在编写一个软件或者模块的测试用例时候， 一定要明白这个功能的原始 屋, 也就是软件的使用者（客户）的霹茎。理解原始需求后，编写的

4、测试用例才更有目 的性。2、熟悉软件的功能需求（测试点）这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。 这里要做的是把需求稳定的“粗略”的需求，细化成一个个小需求点。熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。总之，测试用例一定要全部覆盖所有的需求点，这是最基本的一点。3、熟悉软件的实现原理（测试点）在理解原始需求和软件的功能需求后， 软件有什么功能，如何使用就基本上 都知道啦。这时候在根据需求编写测试用例，基本上都能覆盖的比较全面。在此基础上，熟悉软件的实现原理，理解软件的内部处理。（1）熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上

5、面覆盖案例，测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有 覆盖到，而这些没有覆盖到的代码很可能就是一个风险点。（2）熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型 的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大。“互相影响” 就会越多，设计用例单单是从模块本身考虑的话，很可能就会对其他模块造成风 险。4、用户场景和网上问题（测试点）从用户的使用场景考虑，这些在一些慨维设备比较重要。比如软件后期在一 些真实的使用环境中使用。还要就是从一些网上问题总结出来的， 那些地方容易出错。在设计案例的时 候需要考虑进去5、测试用例的框架我觉得一个测试用例的框架体现了

6、一个 测试人员在设计测试用例的整体思 路。框架也是从大到小划分下来，可以是：UI界面，功能，容错，兼容， 性能等几大类，每个大类在根据软件的逻辑 等进行划分成小类，最后细分到测试点。6、测试步骤（测试技巧方法）前面4点都是从测试点的角度考虑，测试用例在完成测试点外，下来就是测 试步骤和测试结果啦。测试用例可以写的很详细，也可以写的比较简单。看公司的要求，有些公司 要去测试步骤很细很细，包括测试结果和测试步骤一一对应。我个人不太认同这种做法，测试用例最重要的我认为是测试点。 只要理解了 测试目的后，下来的就是测试人员的执行工作啦。 如果对一些非常娴熟的测试人 员，他们一般看测试用例的标题就是知道

7、你测试目的了，具体的操作就是根据他们的测试方法进行测试。如果测试步骤写的很详细的话，一会很耗时间。你要考 虑到文字语言的描述，以及一些前置步骤的操作，这也会导致案例有时候像个文 章，而且过于详细的会限制执行人员的思维。要求测试步骤写的很详细的公司，一般是怕执行人员的执行力不到位，导致 没有理解案例的目的，导致漏测。一般出现在新员工对软件系统的不熟悉。7、测试用例的一些思路在设计案例中，我用的最多的是边界值，等价类，正常和异常的测试。下面 是我想到的几个方面：(结合一些网上文章的观点)一)从单个模块或者单个功能点考虑(1)UI界面(易用性，提示信息，整体布局，色彩，中英文标点错别字)(2)数据的多样性有效数据合法的无效数据(边界值)非法和异常数据各种数据的组合(3)操作多样性添加删除编辑查询多用户的操作(4)容量测试(5)用户权限(使用权限)(6)升级安装卸载(平滑升级)(7)日志相关(包括调13c日志)(8)软件功能的逻辑划分功能上划分未能覆盖的代码逻辑，可以添加 白盒灰盒用例；关联的功能设计关联的测试的用例(10)可靠性，容错性(11)兼容性(浏览器，系统)(12)安全性(13)性能(这里的性能是指，单个模块或者子系统的性能)总之测试用例首