某某系统软件测试计划(新1).doc

某某某某某某系统软件测试方案版本V1.0软件开发部门：BTEST软件测试部门：Z*第*小组编 写：* 日 期：*年*月*日审 核：*老师 日 期：批 准：*老师 日 期：版 本 历 史版本/状态作者参与者起止日期备注1.0张三张三2010-7-15建立文档1.2张三张三2010-7-30修订文档2.2张三张三2010-8-15修订文档版本历史是指测试方案修改的历史.某某某某某公司二00八年目录测试方案有三重境界：第一重：什么都有用第二重：什么都没用第三重：仅局部有用方案:达成统一认识,对过程控制一、工程简介21.1、目的2目的(文档目的,测试目的)1.2、背景21.2文档受众:2.适用对象开发经理测试经理公司高层领导二、测试参考文档和测试提交文档4文档写法一定要统一(不用写扩展名.doc,具体哪一个文件)三、术语介绍：所有软件测试的专业词汇都要写！如果是第三方，或者是用户要看测试方案，要保证用户看懂如：缺陷的定义，功能测试，压力测试，性能测试等看hf(测试模型(这个看受众用户,如果用户是开发团队,是第三方测试,要写清楚)测试架构(测试模型)1.为什么选择模型2.模型细化,每个阶段做什么->输出好几版本:V,螺旋(边测边改,1个方案,死亡线) 用例结果带给下一个版本H模型)四、测试需求测试范围 依据需求分析,找测试需求五、测试策略1.值域测试:2.数据库测试3.功能测试4.裸机测试5.版本验证测试->冒烟测试6界面测试7.可用性测试8.强度测试9.安装测试10.平安性测试11. 加密测试12.接口测试13.集成测试14.配置测试15.压力测试16.容量测试17.故障转移和恢复性测试18.负载测试验收测试注意:测试结构:功能,性能不属于策略,黑白盒也不属于策略,测试阶段也不属于策略.六、严重程度、优先级的定义(可写在这里)1用例的优先级2缺陷的优先级3缺陷的严重程度七、测试进度5模型->对规模再细化阶段->里程碑->具体每天里程碑 -要加评审(时间安排,考虑并行的情况:需求方案在评审中,写用例,搭建环境,时间紧且人员充足的情况下这样做)需求分析需求评审测试方案方案评审编写用例用例评审执行用例测试总结八、测试资源6系统:是实体机还是虚拟机,要写清楚硬件:不用网络就不写.游戏:要写显卡硬盘工具:研发人员开发,内部开发的工具.九、系统风险 (不写)1系统风险1.1影响方案的潜在因素1.2应急措施1.3测试的局限性2测试通过标准2.1测试模块通过标准2.2系统测试通过标准(ISO 9000规定,有些公司会更严格一些)当没有发现致命性错误，严重功能性错误数量小于测试用例总数的2%，一般功能性错误数量小于测试用例总数的5%，那么认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准十、附录：一般添加模板：方案模板，用例模板，日志模板，缺陷报告模板，会议记录记录人，参与人，评审人测试说明:各种模板,如何使用,如何做需求分析的?1.简介1.1 测试目的:1.确定工程的信息和软件构件。2.需求3.策略4. 确定资源,任务,工作量,工作进度5.可交付元素某某某某某某某某系统的这一“测试方案文档有助于实现以下目标：l 确定现有工程的信息和应测试的软件构件。l 列出推荐的测试需求高级需求。l 推荐可采用的测试策略，并对这些策略加以说明。l 确定所需的资源，并对测试的工作量进行估计。确保测试工作进度l 列出测试工程的可交付元素。1.2 测试背景软件名称:用户:开发者:测试版本:最新版本:软件背景:为了谁的需求,使用软件功能简介:有哪几个模块构成. 主要的功能,以及工程的简史工程名称：某某某某某某某某系用 户：北京*公司人事专员和财务专员开发者： 北大青鸟北航校区测试版本:2.0最新版本:2.2某某某某某某某某系统,为*公司提供更好的高效办公环境,而设计*系统.主要是通过文件发送与接收、文件下载、文件查询、错误处理、站点监控、权限控制等功能，使文件流转顺畅、资源共享、信息有序管理，根本实现无纸化办公，从而提高办公效率和工作质量，降低管理本钱，为核心业务工作提供强有力的技术支持。1.3范围测试操作的范围,描述测试各个阶段的测试类型.各个阶段:单元,集成,系统,验收;测试类型:功能,性能,压力;描述测试的各个阶段.这个范围,有多种写法第一种:按照测试类型分类,画表格:( 这种常用)测试类型是否方案进行测试测试的优先级说明安装/卸载测试是最高优先级程序的安装与卸载测试功能测试是最高优先级系统功能的正确实现及与需求是否符合的测试.l l平台之间的接口l l数据流程控制l l业务流程控制l l用户权限控制资源占有测试否对系统在安装或运行后对硬盘、内存、CPU及网络占有率测试兼容性测试是低优先级系统对各种运行环境的兼容性例如操作系统、浏览器以及与历史版本的兼容性、与第三方软件的兼容性测试可靠性/稳定性测试是最高优先级系统运行的可靠性、对各种异外情况错误处理能力的测试l l系统响应时间l l系统稳定性并发测试是系统对并发操作的支持性测试l l并发用户访问同一资源压力测试否系统在大负载量条件的性能测试用户友好性测试是中等优先级主要是指测试人员以用户的角度对系统操作的方便性、可使用性、界面友好性的给出评价。软件平安性测试否主要从软件平安性角度测试系统对业务数据保存、访问及软件系统自身的平安性进行测试。配置测试否指对被测系统使用说明书中要求的软硬件配置进行验证。在此主要指硬件的配置要求验证测试。恢复测试否是指被测试系统的效劳器端或客户端或网络在机器突然出故障例如突然断电或断网后重新恢复正常的能力测试。文档检查否对提供的用户手册、系统的在线帮助等技术文档进行一致性检查。其他测试：否备注：1请在表中选择本次测试方案进行的测试类型，并对测试的优先级给以说明。2测试的优先级分为四个级别，请在表格中填写相应序号。1 最高优先级：首先测试，并详细测试；2 中等优先级：正常测试；3 低优先级： 只需粗略测试，但本次测试必须进行；4 最低优先级：只需粗略测试，可以留到下轮测试进行；第2种:按模块名称,各模块的测试需求是什么本方案主要定位于各模块功能测试，界面测试，验收测试的工作，测试类型以功能测试为主，辅以用户界面测试。模块名称测试需求测试优先级备注文件发送与接收网络正常情况下发送与接收;网络中断情况一发送与接收,判断是否支持续传;当文件本身发生错误时发送与接收情况高文件下载网络正常情况下,下载;网络中断时下载情况;当正在下载,突然管理员删除文件时的情况;高文件查询根据文件名称查询;根据文件内关键字查询;判断查询提示信息,并显示相应的查询结果高错误处理当网络出现错误时,各种提示错误信息是否正确高站点监控各个终端,进行监控,查找各个终端上传下载情况;并且进行压力和负载测试,查看站点繁忙时的状态高权限控制不同的人,有不同的权限访问不同的文件;判断权限是否正确中退出系统低第3种:按照测试实施的各个阶段来划分:测试的各个阶段：1. 测试设计根据需求规格说明书和最终的系统设计，制订测试方案、测试方案，包括收集测试方法、测试用例，可能的测试工具等。2. 集成测试前期主要针对单个的功能和模块，及简单的功能组合，后期主要针对根本的流程；同时进行对新参加测试人员的培训。3. 系统测试前期根据需求规格说明书进行功能测试，中期是针对重点模块的性能测试，后期是模拟用户的业务测试，并结合可能的用户测试。4. 验收测试根据用户手册对功能进行检查，复查报告库中的所有BUG，对Release版本进行安装测试，典型配置环境的裸机测试，加密测试。备注：此测试方案不包含单元测试的内容。2.测试参考文档和测试提交文档第一种写法:分别列出来,如下: (这种常用)2.1测试参考文档Ø 产品需求说明书Ø 产品概要设计Ø 产品详细设计Ø 产品使用说明书2.2测试提交文档Ø 测试方案Ø 测试用例设计与执行报告Ø 测试用例设计评审记录Ø 功能测试报告Ø 性能测试报告Ø 压力测试报告Ø 安装测试报告Ø 测试日志Ø 缺陷报告Ø 验收测试总结报告第二种方法:将测试方案参考文档,写上:下表列出了制定测试方案时,需要参考哪些文档,全列在下方,并且标识这些文档的可用性：(这个偏硬件)注：可适当地删除或添加文档项。文档版本/日期已创立或可用已被接收或已经过复审作者或来源备注可行性分析报告是否是否软件需求定义是否是否软件系统分析STD,DFD,CFD,DD是否是否软件概要设计是否是否软件详细设计是否是否软件测试需求是否是否硬件可行性分析报告是否是否硬件需求定义是否是否硬件概要设计是否是否硬件原理图设计是否是否硬件结构设计包含PCB是否是否FPGA设计是否是否硬件测试需求是否是否PCB设计是否是否USB驱动设计是否是否Tuner BSP 设计是否是否MCU设计是否是否模块开发手册是否是否测试时间表及人员安排是否是否测试方案是否是否测试方案是否是否测试报告是否是否测试分析报告是否是否用户操作手册是否是否安装指南是否是否下表列出了制定测试方案时所使用的文档，并标明了各文档的可用性：(一般工程用)文档版本/日期已创立或可用已被接收或已经过复审作者或来源备注需求规约o 是ý 否o 是o 否  功能性规约o 是ý 否o 是o 否  用例报告o 是ý 否o 是o 否  工程方案þ 是o 否o 是o 否  设计规约o 是ý 否o 是o 否  原型þ 是o 否o 是o 否  用户手册o 是ý 否o 是o 否  业务模型或业务流程o 是ý 否o 是o 否  数据模型或数据流o 是ý 否o 是o 否  真实原始数据o 是ý 否o 是o 否业务功能和业务规那么o 是ý 否o 是o 否  工程或业务风险评估o 是ý 否o 是o 否  3.术语和定义程序员和开发人员,因为术语不同,发生争执.统一术语此局部定义与测试方案执行有关的重要术语和缩略语，其中主要对软件错误与缺陷的划分标准进行定义。3.1 软件错误与缺陷定义软件错误与缺陷定义见附录。3.2 其他术语的定义无。4.测试功能模块范围模块名称对应测试用例编号主要功能测试内容优先级5.测试策略把讲的测试策略,再结合着要求的进行修改.内容测试 对于系统来说，总有些内容局部需要测试，例如帮助等。对于网站来说，文字说明也是相当重要的。内容测试的第一步就是将内容局部标识出来，再确定谁来实施测试。 提示和技巧 如果内容只是一些帮助文件，用户教育部门会编写和验证这些内容。如果系统是以内容为主的，拥有上百万的文字、千个链接以及不计其数的图片，在这种情况下需要使用由编辑、校对和测试人员组成的小组来负责内容测试。 与内容提供者确定“什么是内容的缺陷。防止出现模糊的问题，比方“读起来有点问题或者“太文绉绉。 哪些内容需要测试。 如何将内容测试与其他工作分开。4.1测试策略下面列出了在进行每项测试时需考虑的事项，除此之外，测试还应在平安的环境中使用的、有控制的数据库来执行。注意：不实施某种测试，那么应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。该测试本工程不适用。4.1.1数据和数据库完整性测试数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统DBMS，还需要进行深入的研究，以确定可以支持以下测试的工具和技术。测试目标：确保数据库访问方法和进程正常运行，数据不会遭到损坏测试范围：数据库及表结构技术：检查数据库，确保数据已按预期的方式填充，并且所有的数据库事件已正常发生；或者检查所返回的数据，确保正当的理由检索到了正确的数据开始标准：系统数据库设计完毕完成标准：所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。测试重点和优先级：需考虑的特殊事项：测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。进程应该以手工方式调用。应使用小型或最小的数据库记录的数量有限来使所有无法接受的事件具有更大的可视度。4.1.2单元测试测试目标确保模块及单元的正确性测试范围：记录输入输出数据技术：开始标准： 编码完成完成标准： 集成测试测试重点和优先级：需考虑的特殊事项：接口的限制条件4.1.3功能测试对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规那么的测试需求。这种测试的目标是核实数据的接收、处理和检索是否正确，以及业务规那么的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面GUI与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要：测试目标确保测试的功能正常，其中包括导航，数据输入，处理和检索等功能。测试范围：技术：利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规那么都得到了正确的应用。开始标准：集成测试完成完成标准：所方案的测试已全部执行。所发现的缺陷已全部解决。测试重点和优先级：需考虑的特殊事项：确定或说明那些将对功能测试的实施和执行造成影响的事项或因素内部的或外部的4.1.4用户界面测试用户界面UI测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。测试目标通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法Tab键、鼠标移动、和快捷键的使用窗口的对象和特征例如，菜单、大小、位置、状态和中心都符合标准。测试范围：技术：为每个窗口创立或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。开始标准：系统整合完毕完成标准：成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准测试重点和优先级：需考虑的特殊事项：并不是所有定制或第三方对象的特征都可访问。4.1.5性能评测性能评测是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件例如工作量或硬件配置的一种函数来进行评测和微调。注：以下所说的事务是指“逻辑业务事务。这种事务被定义为将由系统的某个Actor通过使用测试对象来执行的特定用例，添加或修改给定的合同。测试目标核实所指定的事务或业务功能在以下情况下的性能行为：正常的预期工作量预期的最繁重工作量测试范围：用户登录，查询，添加，修改，删除、发送、下载等技术：使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。脚本应该在一台计算机上运行最好是以单个用户、单个事务为基准，并在多个客户机虚拟的或实际的客户机，请参见下面的“需要考虑的特殊事项上重复。开始标准：功能开发完毕并可用完成标准：单个事务或单个用户：在每个事务所预期时间范围内成功地完成测试脚本，没有发生任何故障。多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。测试重点和优先级：用户登录，查询，添加，修改，删除、发送、下载需考虑的特殊事项：综合的性能测试还包括在效劳器上添加后台工作量。可采用多种方法来执行此操作，其中包括：直接将“事务强行分配到效劳器上，这通常以“结构化语言SQL调用的形式来实现。通过创立“虚拟的用户负载来模拟许多个通常为数百个客户机。此负载可通过“远程终端仿真Remote Terminal Emulation工具来实现。此技术还可用于在网络中加载“流量。使用多台实际客户机每台客户机都运行测试脚本在系统上添加负载。性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。4.1.6负载测试负载测试是一种性能测试。在这种测试中，将使测试对象承当不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。注：以下所说的事务是指“逻辑业务事务。这里事务被定义为将由系统的某个最终用户通过使用应用程序来执行的特定功能，例如，发送或接收报文文件。测试目标核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。测试范围：用户登录，查询，添加，修改，删除等技术：使用为功能或业务周期测试制定的测试。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务发生的次数。开始标准：完成标准：多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障。测试重点和优先级：功能开发完毕并可用需考虑的特殊事项：负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。4.2 工具此工程将列出测试使用的工具：用途工具生产厂商/自产版本缺陷管理BugzillaTerry Weissman3.2功能测试QTPMI9.2性能测试LoadrunnerMI9.1六、严重程度、优先级的定义(可写在这里)1用例的优先级2缺陷的优先级3缺陷的严重程度对于软件的错误和缺陷，目前主要依据其严重程度划分五个级别： 致命性错误数据丧失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机。 严重性错误应用系统崩溃、非正常关闭和无响应，但没有造成数据丧失。系统的主要功能不能正确实现或不完整。 一般性错误规定的非主要功能没有实现或不完整、影响系统的运行； 设计不合理造成性能低下。 告警性错误不影响业务运行的功能问题。 建议软件设计和功能实现等不完全合理之处提出建议。 7.资源培训需求 本节说明工程测试人员需要哪些培训。 提示和技巧： l 对于新手需要先介绍测试系统，如果测试人员比拟熟悉该系统，那么需要说明新系统的功能。 l 是否进行自动测试。 l 测试人员要不要培训以编写自动化脚本。 B. 硬件需求 本节说明测试人员需要的各种类型的硬件以及这个测试团队需要的硬件。 C. 软件需求 本节说明测试人员需要使用的软件。 D. 办公空间需求 本节说明需要多少办公空间。6.1角色下表列出了在此工程的人员配备方面所作的各种假定。小公司:角色推荐的最少资源所分配的专职角色数量具体职责或注释测试经理张明进行管理监督。 职责：提供技术指导获取适当的资源生成测试方案，测试方案管理测试数据Notes数据库收集测试用例参与测试测试员测试中心提供测试员23名。执行测试。职责：执行测试记录结果从错误中恢复返测报告收集测试用例测试系统管理员张明确保测试环境和资产得到管理和维护。职责：管理测试系统授予和管理角色对测试系统的访问权大公司:人力资源角色所推荐的最少资源所分配的专职角色数量具体职责或注释测试经理测试工程经理TBD进行管理监督。职责：n 提供技术指导n 获取适当的资源n 提供管理报告测试设计员TBD确定测试用例、确定测试用例的优先级并实施测试用例。职责：n 生成测试方案n 生成测试模型n 评估测试工作的有效性测试员TBD执行测试。职责：n 执行测试n 记录结果n 从错误中恢复n 记录变更请求测试系统管理员TBD确保测试环境和资产得到管理和维护。职责：n 管理测试系统n 分配和管理角色对测试系统的访问权数据库管理员TBD确保测试数据数据库环境和资产得到管理和维护。职责：n 管理测试数据数据库设计员TBD确定并定义测试类的操作、属性和关联关系。职责：n 确定并定义测试类n 确定并定义测试包实施员TBD实施测试类和测试包，并对它们进行单元测试。职责：n 创立在测试模型中实施的测试类和测试包6.2系统第一种:测试工程所需的系统资源。(这个适用于对显卡要求比拟高的系统,如:XXXX编辑系统4.0)1. 硬件资源CPU：P4 1.5G以上，或者双PIII 800以上。主板：Pinnacle推荐的主板，带有AGP插槽，5个PCI32插槽。如果需要支持3路无压缩视频流实时播放，那么需要带有2个PCI64插槽。内存：256 MB最好512MB。显卡：支持双屏显示，带有OpenGL加速的显卡，显存不低于32MB。支持2048×768真彩色，支持YUV直接显示。如ELSA Synergy III NVIDIA QUADRO MXR、AGP 、32MB、Dual Monitor Support。视频卡：b系列及配套的接口箱。SCSI卡：支持SCSI 160的双通道SCSI卡机箱：带有配套视频接口背板的机箱。硬盘：1块IDE或SCSI系统硬盘20G以上，SCSI硬盘阵列4块或者8块10000转以上的SCSI硬盘。2. 软件环境Windows 2000SP2b系列的SDK驱动被测试软件第二种:下表列出了测试的系统环境软件环境相关软件、操作系统等Windows 2003 server MySql 5.0,Tomcat 5.0 Windows XP Windows 2000Linux硬件环境网络、设备等效劳器 hp380客户端 P4 2.53GHz 1G 80G 网络：100M Ethernet8.测试进度包括主要时间点的安排 日期 代码完成时间 测试遍数 第一遍测试 第X遍测试 系统发行时间至少要运行一遍完整的测试和一个简短的测试。前者用于发现错误，后者用于验证发行版本。时间安排:跟开发一起走开发编码:写用例.补充用例培训,测试员熟悉文档-筹划文档执行时间最长搭环境长8.1 各测试阶段资源要求及时间安排 人员设备时间安排制定测试方案张明无2008-10-22至2008-10-24设计测试张明无2008-10-27至2008-11-10集成测试刘涛、张明、刘月测试用机 132008-11-12至2008-11-28系统测试张明、测试中心提供测试员56名测试用机 45套2008-12-01至2008-12-22性能测试刘涛、测试中心提供测试员23名测试用机 34套2008-12-10至2008-12-19验收测试1人月客户参与测试用机 12008-12-22至2008-12-23产品发布12008-12-24至2008-12-248.2 工程里程碑里程碑任务工作量方案开始日期实际开始日期结束日期制定测试方案1.0人月2008-10-222008-10-222008-10-24设计测试1.0人月2008-10-272008-10-272008-11-10集成测试3.0人月2008-11-112008-11-122008-11-28系统测试7.08.0人月2008-12-012008-12-012008-12-22性能测试3.04人月2008-12-102008-12-102008-12-19验收测试1.0人月客户参与2008-12-222008-12-222008-12-23产品发布1.0人2008-12-242008-12-242008-12-24对于新参加测试人员的培训，前期提供了一些参考书和资料，供他们自学，估计只能到达初步了解的效果；由于时间比拟紧，只能在集成测试阶段，针对X4.0系统进行必要的培训；系统测试阶段也需要新参加的测试人员一边测试，一边了解相关的知识；希望通过这次的测试，新参加测试人员能够积累一定的经验。8.3任务分配 测试员测试任务刘涛、功能测试、数据库测试、集成测试张明用户界面测试、性能评价测试、平安性测试刘月容量测试、平安性和访问控制测试、故障转移和恢复测试吴涛配置测试、安装测试9.系统风险、优先级风险:研发未按时完成人员流失软件不熟悉 培训测试方案有误需求不明确.无需求文档9.1系统风险Ø 由于目前同类产品比拟多，市场压力比拟大。Ø 方案的测试时间，不能满足测试组的要求，主要是功能冻结后的系统测试的时间可能不够。Ø 测试资源的及时到位设备和人员。Ø 测试人员的培训。Ø 开发进度的变化，需求或设计的变更。Ø 开发组的版本控制。Ø 需求不明确可能导致开发的产品与目标不一致。Ø 需求变更不及时通知。Ø 测试人员获取的需求与开发人员产生分歧。Ø 测试人员与开发人员的协调与沟通。9.3影响方案的潜在因素在测试方案执行过程中，可能存在以下因素影响方案的按时完成：Ø 测试人员对被测试产品的熟悉进度慢；Ø 测试人员对测试工具的使用熟悉程序不够；Ø 被测试产品存在重大错误，以致于测试无法继续，需要开发组进行额外的调试和修改才能继续；Ø 硬件、软件或网络环境出现故障等。其中第一点是影响测试进度的最大的因素。9.4应急措施如果上述潜在的可能事件发生，那么通过适当加班来保证方案的按时完成。如果是由于被测试产品存在重大错误而严重影响测试进度，那么考虑按照测试暂停标准来暂停该测试。9.5测试的局限性Ø 系统硬件配置存在不可预测的问题；Ø 测试范围不能覆盖所有的可能情况；Ø 测试时间的限制；Ø 测试数据可能不全面；Ø 测试工具自身的缺陷；Ø 测试人员的失误。测试进入退出准那么测试状态转换标准和再启动要求“测试状态转换标准用于开始、暂停或结束全部或局部与本方案有关的测试项的测试活动的标准，这三种标准通常指启动标准、暂停标准和退出标准。“测试再启动要求规定当测试重启动时必须重复的测试活动。测试启动标准测试部由公司管理层领导，具体由总工负责领导职能。各软件产品或工程组提交测试需经过公司管理层书面指派。公司所研发的各项面向市场的软件系统均需通过测试，才能对外发布，特殊情况由公司管理层书面认可。公司各项软件产品的开发方案书中均需要列出交付测试时间和测试时间，以及相应的修改和回归测试时间。测试部基于各开发方案制定相应的测试方案，软件系统开发方案的变更必须变更相关的测试安排。软件产品或工程提交测试部进行测试必须满足以下条件：提交测试的软件系统必须是一个稳定的、待发布的版本，必须明确定义系统版本号即在系统各局部，系统本身、用户手册等方面均说明该版本，如果本版本还没有开发完成或将进行大量的修改，不能提交测试；Ø软件产品或工程在提交测试之前，本产品或工程组必须在内部进行自己的单元测试和集成测试；提交测试的软件系统必须是商品化包装的，并需附有：用户手册、使用说明书至少两者必备其一；软件需求说明书；其它最好还能够提交相关培训教材、演示程序等电子文档。软件系统开发组必须向测试部提供足够的培训和技术指导，以便测试工作的顺利开展。在测试期间，开发组必须指定一名骨干开发人员，帮助测试部解决相关问题。假设是对将发布的产品或将验收的工程进行测试，那么必须给测试留出足够的时间，以保证测试的质量。提交测试的软件系统版本在测试期间保持稳定，即测试部只对初始提交的系统版本进行测试，产品或工程组在测试期间的修改只在下一轮测试中进行测试。特殊情况即提交版本无法继续测试，如安装程序错误等问题下，可以在测试期间更换版本，但必须经过测试部的同意。回归测试是指不包含功能修改含界面修改等情况下测试部对原来测出的问题进行的再次测试。假设引入新功能超过10%，那么认为是新的系统测试，测试部必须进行全面测试。测试暂停标准当在测试过程中出现以下情况之一，那么测试将暂停：对于某类测试，测试环境变得或者测试中发现没有准备好，那么暂停此类测试；对于提交测试的版本而言，如果其预计的功能修改量超过总功能的10%，产品或工程组应即时通报测试部，并向公司相关负责人汇报，测试部有权利向公司领导建议暂停或取消本轮测试，防止测试的无效劳动，防止造成人力、财力等资源的浪费。发现被测试系统有大量错误或非常严重错误，以至于测试不能继续或继续测试没有意义，那么测试部应向总工提交报告，由总工决定是否暂停整个系统测试。当系统中某个功能模块有非常严重的错误，以致于不能完成预期的功能，那么暂停此功能模块的测试。测试退出标准当出现以下情况之一那么退出此系统的本次测试：测试方案中所有规定的测试内容和回归测试都已经运行完成。根据上级主管对测试结果的意见，要求结束本次测试。4启动要求当测试重新启动时，必须重复的主要测试活动有：当是某功能模块的测试重新启动时，那么此功能模块的所有测试用例都要重新运行，并且调用此功能模块的其他功能模块的相关测试用例也要重新运行。当是整个系统的测试重新启动时，那么发生修改的局部和与之相关联的局部的测试用例都要重新运行。测试通过标准1测试模块通过标准测试项的通过标准目前定义为：当此项的功能能够正确地完成，并且它的操作没有引起其他功能项或整个系统的错误，那么认为此项测试通过。2系统测试通过标准系统测试的通过标准目前定义为：当没有发现致命性错误，严重功能性错误数量小于测试用例总数的2%，一般功能性错误数量小于测试用例总数的5%，那么认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准。测试标准应该包含的内容：?有效测试用例功能执行率到达X%？?单元测试代码行覆盖率到达X%？?单元测试用例通过率X%？?单元测试用例设计通过评审?核心模块A,;B,D等模块测试覆盖?所发现缺陷均纳入缺陷管理系统?优先级最高的bug全部修复?其他bug全部被处理修复，延迟并报告等处理方式?功能测试用例模块，功能点覆盖率到达？ 按照测试类型来的测试停止标准：比方单元测试活动在满足以下所有条件之后可停止：?核心模块代码100 经过Code Review?单元测试用例设计通过评审?测试用例执行率100%?最新版本的单元测试通过率为100%?单元测试全局代码行覆盖率不低于80%