电梯功能得测试用例和测试方案.docxVIP

一、如果给你一台电梯，请问你如何测试它，分析如下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、测试用例的一些