车间维修过程管理信息系统---测试计划

1车间维修过程管理信息系统测试计划合肥天地软件科技有限责任公司2013年8月拟制人：魏章亚日期：2013-08-01审核人：日期：批准人：日期：2修订历史记录日期版本说明作者2013-08-01V1.0初稿魏章亚3目录1.简介41.1目的41.2背景41.3参考文档42.测试范围52.1业务需求52.2业务流程62.3业务模型73.测试策略73.1测试类型83.1.1数据和数据库完整性测试83.1.2功能测试93.1.3业务周期测试103.1.4用户界面测试113.1.5性能评价123.1.6负载测试133.1.7强度测试143.1.8容量测试153.1.9安全性和访问控制测试163.1.10故障转移和恢复测试173.1.11配置测试193.2测试管理工具204.资源需求214.1培训需求214.2人力需求214.2系统需求225.测试过程管理235.1接收测试的条件235.2项目里程碑及风险分析235.3测试文档管理245.4测试过程控制245.5测试用例设计245.6测试实施过程245.7测试方法综述245.8缺陷报告及处理254测试计划1.简介1.1目的本文档是本项目测试整个过程进行的依据、规范和标准。它从策略角度说明本项目测试的组织和管理，指导测试进展，并作为项目测试工作实施的依据。车间维修过程管理信息系统的这一“测试计划”文档有助于实现以下目标：•明确现有项目的信息和应测试的软件构件；•明确测试需求、测试范围，对每个范围制订测试的策略和方法；•确定所需的资源，并对测试的工作量进行估计;•确定测试管理过程及测试任务;•确定测试所需要的环境;•确定测试风险;1.2背景车间维修过程管理信息系统是合肥天地软件有限公司为合肥公交集团开发的一套ERP管理系统，系统采用B/S结构，以.Net作为前台开发工具,以SQLServer作为后台数据库管理系统，设计符合公交集团实际的车辆维修管理过程,使得车辆维修的信息化管理得以实现,规范了维修生产,提高了管理效率目前，车间维修过程管理信息系统还未开始使用，为了更加系统和有效地发现系统中的其它问题，确保交付给客户高质量的软件产品，，启动本项目来对系统进行测试。1.3参考文档下表列出了制定测试计划所用的文档，并标明了文档的可用性：文档（版本/日期）已创建或可用已被接受或已经过复审作者或来源备注需求规约是否是否功能性规约是否是否项目计划是否是否原型是否是否业务模型或业务流程是否是否数据模型或数据流是否是否业务功能和业务规则是否是否项目或业务风险评估是否是否52.测试范围2.1业务需求下面列出了已被确定为测试对象的项目（用例、功能性需求和非功能性需求）。此列表说明了测试的对象。(1)报修症状的标准化问题：避免同一症状出现多种不同的名称；(2)维修和保养的规范化，实现单车故障、维修成本的核算；(3)与物资系统进行对接，实现购、修、领一体化，减少因车辆待料而增加故障耗时；(4)做到应保必保，确保车辆各项技术参数良好；(5)与营运调度系统对接，实现车辆上下线的信息共享，并能根据车间的维修能力合理安排车辆下线，避免集中进场进行低级别保养而影响营运生产；(6)能够加强对返修的管理，提高维修质量；ID需求描述优先级来源用例编号1基础设置1.1班组管理1.2故障编码管理1.3故障编码与必换件管理1.4故障编码工时定额管理1.5故障编码材料定额管理1.6工位设置1.7工位与保养级别关系1.8工位与必换件管理1.9保养工艺规范管理1.10作业编码管理1.11当日未检修车辆原因2车辆小修2.1辅料领料管理2.2919抢修录入2.3小修（返修）报修录入2.4生成派工单：打印2.5派工单完工2.6质量检验单2.7检验派工单：打印合格证2.8修检动态表生成2.9修检动态表管理3车辆保养3.1车辆保养工位单（质检单）4轮胎管理6电瓶管理7工具管理8大型设备管理69固定资产管理10辅助料管理11报表11.1车辆状况11.2生产实绩11.3线路消耗一览表（按日期）11.4各项指标11.5报修日报表2.2业务流程1)、小修流程主修人、检验员将修理、换件、故障耗时等情况填写到保修记录2）、保养流程3）、领料流程4）、抢修流程驾驶员报修登记抄报员登记汇总报修记录抄报员填派工单修理工修理完成确认检验员检验交车出场当天车辆进场根据计划、做相应级别保养检验员检验交车出场修理工、检验员驾驶员共同确定更换件料工开具领料单检验员车间主任签字零件更换驾驶员电话报修919热线记录报修根据抢修地点就近选择保养车间保养车间走小修流程维修结果反馈72.3业务模型3.测试策略根据本系统自身的特点，测试过程策略如下：1.以80/20原理为指导。尽量做到在有限的时间里发现尽可能多的缺陷（尤其是严重缺陷）2.测试计划与需求制定、用例设计同步进行3.必须制定测试需求。通过确定要测试的内容和各自的优先级、重要性，使测试设计工作更有目的性，在需求的指导下设计出更多更有效的用例。4.逐步完善测试用例库。测试用例库的建设是一个不断完善的过程，我们要在有限的时间里，先设计出一整套的测试用例，重要的部分用例需要设计得完善一些，一般部分的则指出测试的要点，在以后的测试工作中再不断去完善测试用例库。5.测试过程要受到控制。根据事先定义的测试执行顺序进行测试，并填写测试记录表，保证测试过程是受控的。6.确定重点。测试重点放在各子系统的功能实现上，问题较多的省中心管理系统和证书管理系统则是重中之重。测试技术本项目采用黑盒测试技术。本项目测试过程中将不会采用测试工具。8测试过程测试需求测试计划测试用例说明书测试执行编写测试用例编写测试计划制定测试需求开始测试总结测试记录缺陷记录测试分析报告结束系统培训/了解系统3.1测试类型3.1.1数据和数据库完整性测试数据库和数据库进程应作为车间维修过程管理信息系统中的子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统(DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和方法。测试目标：[确保数据库访问方法和进程正常运行，数据不会遭到损坏。]方法：[调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据或对数据的请求。检查数据库，确保数据已按预期的方式填充，并且所有数据库事件都按正常方式出现；或者检查所返回的数据，确保为正当的理由检索到了正确的数据]完成标准：[所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。]9需考虑的特殊事项：[测试可能需要DBMS开发环境或驱动程序以便在数据库中直接输入或修改数据。进程应该以手工方式调用。应使用小型或最小的数据库（其中的记录数很有限）来使所有无法接受的事件具有更大的可见性。]3.1.2功能测试测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。这种类型的测试基于黑盒方法，即通过图形用户界面(GUI)与应用程序交互并分析输出结果来验证应用程序及其内部进程。以下列出的是每个应用程序推荐的测试方法概要：测试目标：确保测试对象的功能正常，其中包括导航、数据输入、处理和检索等。方法：利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。完成标准：所计划的测试已全部执行。所发现的缺陷已全部解决。需考虑的特殊事项：确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）103.1.3业务周期测试业务周期测试应模拟在一段时间内对车间维修过程管理信息系统执行的活动。应先确定一段时间（例如一年），然后执行将在该时段内发生的事务和活动。这种测试包括所有的每日、每周和每月的周期，以及所有与日期相关的事件（如备忘录）。测试目标确保测试对象及后台进程都按照所要求的业务模型和时间表正确运行。方法：通过执行以下活动，测试将模拟若干个业务周期：将修改或增强对测试对象进行的功能测试，以增加每项功能的执行次数，从而在指定的时段内模拟若干个不同的用户。将使用有效的和无效的日期或时段来执行所有与时间或日期相关的功能。将在适当的时候执行或启动所有周期性出现的功能。在测试中还将使用有效的和无效的数据，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。完成标准：所计划的测试已全部执行。所发现的缺陷已全部解决。需考虑的特殊事项：系统日期和事件可能需要特殊的支持活动需要通过业务模型来确定相应的测试需求和测试过程。113.1.4用户界面测试通过用户界面(UI)测试来核实用户与软件的交互。UI测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。除此之外，UI测试还要确保UI功能内部的对象符合预期要求，并遵循公司或行业的标准。测试目标：核实以下内容：通过浏览测试对象可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab健、鼠标移动和快捷键）的使用窗口的对象和特征（例如：菜单、大小、位置、状态和中心）都符合标准。方法：为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。完成标准：证实各个窗口都与基准版本保持一致，或符合可接受标准需考虑的特殊事项：并不是所有定制或第三方对象的特征都可访问。123.1.5性能评价性能评价是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评价的目标是核实性能需求是否都已满足。实施和执行性能评价的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评价和微调。注：以下事务均指“逻辑业务事务”。这种事务被定义为将由系统的某个主角通过使用测试对象来执行的特定用例，例如，添加或修改某个合同。测试目标：核实所指定的事务或业务功能在以下情况下的性能行为：正常的预期工作量预期的最繁重工作量方法：[使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代次数。脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多台客户机（虚拟的或实际的客户机，请参见下面的“需考虑的特殊事项”）上重复。]完成标准：[单个事务或单个用户：在每个事务所预期或要求的时间范围内成功地完成测试脚本，没有发生任何故障。][多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。]需考虑的特殊事项：[综合的性能测试还包括在服务器上添加后台工作量。可采用多种方法来执行此操作，其中包括：直接将“事务强行分配到”服务器上，这通常以“结构化查询语言”(SQL)调用的形式来实现。通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。此负载可通过“远程终端仿真”(RemoteTerminalEmulation)工具来实现。此技术还可用于在网络中加载“流量”。使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。性能测试所用的数据库应该是与实际大小相同或等比例缩放的数据库。]133.1.6负载测试负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。[注：以下事务均指“逻辑业务事务”。这些事务被定义为将由系统的最终用户通过使用应用程序来执行的具体功能，例如，添加或修