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

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

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

      2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。 
9.是否有手机信号
可靠性： 
1.门关上的一刹那出现障碍物。
 2.同时按关门和开门按钮。 
3.点击当前楼层号码
4.多次点击同一楼层号码
5.同时按上键和下键
易用性：
电梯的按钮的设计符合一般人的习惯吗
用户文档：
使用手册是否对电梯的用法、限制、使用条件等有详细的描述
压力测试：
1.看电梯的最大承重量，在负载过重时报警装置是否有提醒
2.在一定时间内不断让电梯上升、下降
稳定性测试：

看电梯在最大负载下平稳运行的最长时间

　　如何编写测试用例：
　　1、了解软件的原始需求(测试目的)
　　在编写一个软件或者模块的测试用例时候，一定要明白这个功能的原始需求，也就是软件的使用者(客户)的需求。理解原始需求后，编写的测试用例才更有目的性。
　　2、熟悉软件的功能需求(测试点)
　　这个功能需求是指软件的细化需求点，这个一般在需求文档里面都会体现。这里要做的是把需求稳定的“粗略”的需求，细化成一个个小需求点。
　　熟悉功能需求后，要知道软件是怎么使用的，这也才能覆盖到各种操作。
　　总之，测试用例一定要全部覆盖所有的需求点，这是最基本的一点。
　　3、熟悉软件的实现原理(测试点)
　　在理解原始需求和软件的功能需求后，软件有什么功能，如何使用就基本上都知道啦。这时候在根据需求编写测试用例，基本上都能覆盖的比较全面。
　　在此基础上，熟悉软件的实现原理，理解软件的内部处理。
　　(1)熟悉原理的过程是进一步深入熟悉软件的过程。如果单单是从需求点上面覆盖案例，测试用例只能覆盖“表面”的一层。一些内部的处理流程也许没有覆盖到，而这些没有覆盖到的代码很可能就是一个风险点。
　　(2)熟悉模块原理后，还有一点就是易于分析软件模块的关联性。一个大型的软件，都是一些小模块的组合而成。软件越是大型，耦合就越大。“互相影响”就会越多，设计用例单单是从模块本身考虑的话，很可能就会对其他模块造成风险。
　　4、用户场景和网上问题(测试点)
　　从用户的使用场景考虑，这些在一些网络设备比较重要。比如软件后期在一些真实的使用环境中使用。
　　还要就是从一些网上问题总结出来的，那些地方容易出错。在设计案例的时候需要考虑进去
　　5、测试用例的框架
　　我觉得一个测试用例的框架体现了一个测试人员在设计测试用例的整体思路。框架也是从大到小划分下来，可以是：
　　UI界面，功能，容错，兼容，性能等几大类，每个大类在根据软件的逻辑等进行划分成小类，最后细分到测试点。
　　6、测试步骤(测试技巧方法)
　　前面4点都是从测试点的角度考虑，测试用例在完成测试点外，下来就是测试步骤和测试结果啦。
　　测试用例可以写的很详细，也可以写的比较简单。看公司的要求，有些公司要去测试步骤很细很细，包括测试结果和测试步骤一一对应。
　　我个人不太认同这种做法，测试用例最重要的我认为是测试点。只要理解了测试目的后，下来的就是测试人员的执行工作啦。如果对一些非常娴熟的测试人员，他们一般看测试用例的标题就是知道你测试目的了，具体的操作就是根据他们的测试方法进行测试。如果测试步骤写的很详细的话，一会很耗时间。你要考虑到文字语言的描述，以及一些前置步骤的操作，这也会导致案例有时候像个文章，而且过于详细的会限制执行人员的思维。
　　要求测试步骤写的很详细的公司，一般是怕执行人员的执行力不到位，导致没有理解案例的目的，导致漏测。一般出现在新员工对软件系统的不熟悉。
　　7、测试用例的一些思路
　　在设计案例中，我用的最多的是边界值，等价类，正常和异常的测试。下面是我想到的几个方面：(结合一些网上文章的观点)
　　一)从单个模块或者单个功能点考虑
　　(1)UI界面(易用性，提示信息，整体布局，色彩，中英文标点错别字)
　　(2)数据的多样性
　　有效数据
　　合法的无效数据(边界值)
　　非法和异常数据
　　各种数据的组合
　　(3)操作多样性
　　添加删除编辑查询
　　多用户的操作
　　(4)容量测试
　　(5)用户权限(使用权限)
　　(6)升级安装卸载(平滑升级)
　　(7)日志相关(包括调试日志)
　　(8)软件功能的逻辑划分
　　功能上划分未能覆盖的代码逻辑，可以添加白盒灰盒用例;
　　(9)关联的功能
　　设计关联的测试的用例
　　(10)可靠性，容错性
　　(11)兼容性(浏览器，系统)
　　(12)安全性
　　(13)性能(这里的性能是指，单个模块或者子系统的性能)
　　总之
　　测试用例首先要能覆盖所有功能需求点，然后搞懂软件处理逻辑，可以找开发一起看测试用例，把没有覆盖到的代码流程相应的补充用例。用例覆盖到这2点基本不会出现基本功能的问题。
　　在此基础上，可以进行一些可靠性，容错性，兼容性等用例的设计，测试下软件的稳定性。

5771001803090012095 579036822859633082
5771001803090012386 576137399735760696
5771001803090013594 578077579902515512
5771001803090012387 577164982601818051
5771001803090012138 572131192158918326
5771001803090012359 579036822361076053
5771001803090012356 576135286143791742
5771001803090012355 575087869704693279

17088100343355274 101229944325833379
17088100343355275 101866732938832008
17088100343356107 101581152501500522
17088100343356108 101000180059871732
17088100343354295 101074194142687017
17088100343356184 101878660869628802
17088100343356185 101775831174086674
17088100343356109 101086014373572846
17088100343356110 101152207216014916
17088100343355237 101027041605702709
17088100343355238 101229364861425414
17088100343356169 101862204402635718
17088100343354928 101760654089788804