某某系统软件测试计划_软件测试面试必备

1、软件测试面试必备 某某某某某某系统软件测试计划版本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.3 文档受众:2. 适用对象

2、开发经理测试经理公司高层领导二、测试参考文档和测试提交文档4文档写法一定要统一（不用写扩展名.doc,具体哪一个文件）三、术语介绍：所有软件测试的专业词汇都要写！（如果是第三方，或者是用户要看测试计划，要保证用户看懂）如：缺陷的定义，功能测试，压力测试，性能测试等（测试模型（这个看受众用户,如果用户是开发团队,是第三方测试,要写清楚）测试架构（测试模型）1.为什么选择模型2.模型细化，每个阶段做什么-输出好几版本：V,螺旋（边测边改,1个计划 ,死亡线 ） 用例结果带给下一个版本H 模型 ）四、测试需求测试范围依据需求分析,找测试需求五、测试策略1.值域测试:2.数据库测试3.功能测试4.裸机

3、测试5.版本验证测试-冒烟测试6界面测试7.可用性测试8.强度测试9.安装测试10.安全性测试11. 加密测试12.接口测试13.集成测试14.配置测试15.压力测试16.容量测试17.故障转移和恢复性测试18.负载测试验收测试注意 :测试结构:功能 ,性能不属于策略,黑白盒也不属于策略,测试阶段也不属于策略.六、严重程度、优先级的定义（可写在这里）1）用例的优先级2）缺陷的优先级3）缺陷的严重程度七、测试进度5 模型-对规模再细化阶段-里程碑 -具体每天里程碑要加评审（时间安排,考虑并行的情况:需求计划在评审中,写用例,搭建环境,时间紧且人员充足的情况下这样做）需求分析需求评审测试计划计划评

4、审编写用例用例评审执行用例测试总结八、测试资源6系统 :是实体机还是虚拟机,要写清楚硬件 :不用网络就不写.游戏:要写显卡硬盘工具:研发人员开发,内部开发的工具.九、系统风险（不写）1 系统风险1.1 影响计划的潜在因素1.2 应急措施1.3 测试的局限性2 测试通过标准2.1 测试模块通过标准2.2 系统测试通过标准 （ISO 9000 规定 ,有些公司会更严格一些）当没有发现致命性错误，严重功能性错误数量小于测试用例总数的2%，一般功能性错误数量小于测试用例总数的5%，则认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准十、附录：一般添加模板：计划模板，用例模板，日志模板，缺陷

5、报告模板，会议记录（记录人，参与人，评审人）测试说明:各种模板,如何使用,如何做需求分析的?1. 简介1.1 测试目的:1. 确定项目的信息和软件构件。2. 需求3. 策略4. 确定资源, 任务 , 工作量 , 工作进度5. 可交付元素某某某某某某某某系统的这一 “测试计划”文档有助于实现以下目标:确定现有项目的信息和应测试的软件构件。列出推荐的测试需求（高级需求）。推荐可采用的测试策略，并对这些策略加以说明。确定所需的资源，并对测试的工作量进行估计。确保测试工作进度列出测试项目的可交付元素。1.2 测试背景软件名称:用户 :开发者 :测试版本:最新版本:软件背景: 为了谁的需求,使用软件功能

6、简介: 有哪几个模块构成. 主要的功能, 以及项目的简史项目名称：某某某某某某某某系用 户：北京* 公司人事专员和财务专员开发者：北大青鸟北航校区测试版本:2.0最新版本:2.2某某某某某某某某系统, 为 * 公司提供更好的高效办公环境, 而设计 * 系统 . 主要是通过文件发送与接收、文件下载、文件查询、错误处理、站点监控、权限控制等功能，使文件流转顺畅、资源共享、信息有序管理，基本实现无纸化办公，从而提高办公效率和工作质量，降低管理成本，为核心业务工作提供强有力的技术支持。1.3 范围测试操作的范围, 描述测试各个阶段的测试类型.各个阶段: 单元, 集成, 系统,验收 ;测试类型: 功能,

7、 性能, 压力;描述测试的各个阶段. 这个范围, 有多种写法第一种：按照测试类型分类，画表格：（这种常用）测试类型是否计划进行测试测试的优先级说明安装/卸载测试是最高优先级程序的安装与卸载测试功能测试是最高优先级系统功能的正确实现及与需求是否符合 的测试.平台之间的接口数据流程控制业务流程控制用户权限控制资源占有测试否对系统在安装或运行后对硬盘、内存、CPUK网络占有率测试兼容性测试是低优先级系统对各种运行环境的兼容性（例如操 作系统、浏览器）以及与历史版本的兼 容性、与第三方软件的兼容性测试可靠性/稳定性测试是最高优先级系统运行的可靠性、对各种异外情况错 误处理能力的测试系统响应时间系统稳定

8、性并发测试是系统对并发操作的支持性测试并发用户访问同一资源压力测试否系统在大负载量条件的性能测试用户友好性测试是中等优先级主要是指测试人员以用户的角度对系统 操作的方便性、可使用性、界面友好性 的给出评价。软件安全性测试否主要从软件安全性角度测试系统对业务 数据保存、访问及软件系统自身的安全 性进行测试。配置测试否指对被测系统使用说明书中要求的软硬 件配置进行验证。在此主要指硬件的配 置要求验证测试。恢复测试否是指被测试系统的服务器端或客户端或 网络在机器突然出故障（例如突然断电 或断网）后重新恢复正常的能力测试。文档检查否对提供的用户手册、系统的在线帮助等 技术文档进行一致性检查。其他测试：

9、否备注：（1）请在表中选择本次测试计划进行的测试类型，并对测试的优先级给以说明 （2）测试的优先级分为四个级别，请在表格中填写相应序号。1最高优先级：首先测试，并详细测试；2中等优先级：正常测试；3低优先级：只需粗略测试，但本次测试必须进行；4最低优先级：只需粗略测试，可以留到下轮测试进行;第2种：按模块名称，各模块的测试需求是什么本计划主要定位于各模块功能测试，界面测试，验收测试的工作，测试类型以功能测试为主，辅以 用户界面测试。模块名称测试需求测试优先级备注文件发送与接收网络正常情况下发送与接收；网络中断情况一发送与 接收，判断是否支持续传；当文件本身发生错误时发 送与接收情况高文件下载网

10、络正常情况下，下载；网络中断时下载情况；当正在 下载，突然管理员删除文件时的情况；高文件查询根据文件名称查询；根据文件内关键字查询；判断查 询提示信息，并显示相应的查询结果高错误处理当网络出现错误时，各种提示错误信息是否正确高站点监控各个名端，进行监控，查找各个终端上传下载情况 ；并 且进行压力和负载测试，查看站点繁忙时的状态高权限控制不同的人，有不同的权限访问不同的文件；判断权限是否正确中退出系统低第3种:按照测试实施的各个阶段来划分 ：测试的各个阶段：1. 测试设计根据需求规格说明书和最终的系统设计，制订测试计划、测试方案，包括收集测试方法、测试用例，可能的测试工具等。2. 集成测试前期主

11、要针对单个的功能和模块，及简单的功能组合，后期主要针对基本的流程；同时进行对新加入测试人员的培训。3. 系统测试前期根据需求规格说明书进行功能测试，中期是针对重点模块的性能测试，后期是模拟用户的业务测试，并结合可能的用户测试。4. 验收测试根据用户手册对功能进行检查，复查报告库中的所有BUG又Release版本进行安装测试，典型配置环境的裸机测试，加密测试。备注：此测试计划不包含单元测试的内容。2 .测试参考文档和测试提交文档第一种写法：分别列出来，如下：（这种常用）2.1 测试参考文档产品需求说明书产品概要设计产品详细设计产品使用说明书2.2 测试提交文档测试计划测试用例设计与执行报告测试用

12、例设计评审记录功能测试报告性能测试报告压力测试报告安装测试报告测试日志缺陷报告验收测试总结报告第二种方法：将测试计划参考文档，写上：下表列出了制定测试计划时，需要参考哪些文档，全列在下方，并且标识这些文档的可用性：（这个偏 硬件）注：可适当地删除或添加文档项。文档（版本/日期）已创建或可用已被接收或已经过复审作者或来源备注可行性分析报告是口 否口是口 否口软件需求定义是口 否口是口 否口软件系统分析是口 否口是口 否口(STD,DFD,CFD,DD软件概要设计是口 否口是口 否口软件详细设计是口 否口是口 否口软件测试需求是口 否口是口 否口硬件可行性分析报告是口 否口是口 否口硬件需求定义是

13、口 否口是口 否口硬件概要设计是口 否口是口 否口硬件原理图设计是口 否口是口 否口硬件结构设计（包含 PCB是口 否口是口 否口FPG破计是口 否口是口 否口硬件测试需求是口 否口是口 否口PC股计是口 否口是口 否口USB驱动设计是口 否口是口 否口Tuner BSP 设计是口 否口是口 否口MCUO是口 否口是口 否口模块开发手册是口 否口是口 否口测试时间表及人员安排是口 否口是口 否口测试计划是口 否口是口 否口测试方案是口 否口是口 否口测试报告是口 否口是口 否口测试分析报告是口 否口是口 否口用户操作手册是口 否口是口 否口安装指南是口 否口是口 否口下表列出了制定测试计划时所

14、使用的文档，并标明了各文档的可用性：（一般项目用）文档（版本/日期）已团建或可用已被接收或已经过复审作者或来源备注需求规约是否是否功能性规约是含是否用例报告是含是否项目计划是否是否设计规约是否是否原型是否是否用户手册是否是否业务模型或业务流程是否是否数据模型或数据流是否是否真实原始数据是否是否业务功能和业务规则是否是否项目或业务风险评估是否是否3 .术语和定义程序员和开发人员，因为术语不同，发生争执.统一术语此部分定义与测试计划执行有关的重要术语和缩略语，其中主要对软件错误与缺陷的划分标准进行定 义。3.1 软件错误与缺陷定义软件错误与缺陷定义见附录Io3.2 其他术语的定义无。4 .测试功能

15、模块范围模块名称对应测试用例编号主要功能测试内容优先级5 .测试策略把讲的测试策略，再结合着要求的进行修改.内容测试对于系统来说，总有些内容部分需要测试，例如帮助等。对于网站来说，文字说明也是相当重要的。内容测试的第一步就是将内容部分标识出来，再确定谁来实施测试。提示和技巧如果内容只是一些帮助文件，用户教育部门会编写和验证这些内容。如果系统是以内容为主的，拥有上百万的文字、千个链接以及不计其数的图片，在这种情况下需要使用由编辑、校对和测试人员组成的小组来负责内容测试。与内容提供者确定“什么是内容的缺陷”。避免出现模糊的问题，比如“读起来有点问题”或者“太文绐绐” 哪些内容需要测试。如何将内容测

16、试与其他工作分开。4.1 测试策略下面列出了在进行每项测试时需考虑的事项，除此之外，测试还应在安全的环境中使用已知的、有控 制的数据库来执行。注意：不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。该测试本项目不适用”。4.1.1 数据和数据库完整性测试数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界 面用作数据的接口。对于数据库管理系统（ DBMS,还需要进行深入的研究，以确定可以支持以下测试的 工具和技术。测试目标：确保数据库访问方法和进程正常运行，数据不会遭到损坏测试范围：数据库及表结构技术：检查数据库，确保数据已按

17、预期的方式填充，并且所有的数据库事件已 正常发生；或者检查所返回的数据，确保正当的理由检索到了正确的数据开始标准：系统数据库设计完毕完成标准：所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损 坏。测试重点和优先级：需考虑的特殊事项：测试可能需要DBMSFR发环境或驱动程序在数据库中直接输入或修改数 据。进程应该以手工方式调用。应使用小型或最小的数据库（记录的数量有限）来使所有无法接受的事 件具有更大的可视度。4.1.2单元测试测试目标确保模块及单元的正确性测试范围：记录输入输出数据技术：开始标准：编码完成完成标准：集成测试测试重点和优先级：需考虑的特殊事项：接口的限制条件4.1.

18、3 功能测试对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接收、处理和检索是否正确， 以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应 用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要：测试目标确保测试的功能正常，其中包括导航，数据输入，处理和检索等功能。测试范围：技术：利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下 内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则

19、都得到了正确的应用。开始标准：集成测试完成完成标准：所计划的测试已全部执行。所发现的缺陷已全部解决。测试重点和优先级：需考虑的特殊事项：确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内 部的或外部的）4.1.4 用户界面测试用户界面（UI）测试用于核实用户与软件之间的交互。 UI测试的目标是确保用户界面会通过测试对象 的功能来为用户提供相应的访问或浏览功能。另外， UI测试还可确保UI中的对象按照预期的方式运行, 并符合公司或行业的标准。测试目标通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和

20、快捷键）的使用窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。测试范围：技术：为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正 确地进行浏览，并处于正常的对象状态。开始标准：系统整合完毕完成标准：成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准测试重点和优先级：需考虑的特殊事项：并不是所有定制或第三方对象的特征都可访问。4.1.5性能评测性能评测是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来

21、进行评测和微调。注：以下所说的事务是指“逻辑业务事务”。这种事务被定义为将由系统的某个Actor通过使用测试对象来执行的特定用例，添加或修改给定的合同。测试目标核实所指定的事务或业务功能在以下情况下的性能行为：正常的预期工作量预期的最繁重工作量测试范围：用户登录，查询，添加，修改，删除、发送、下载等技术：使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务 的迭代数量。脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准）， 并在多个客户机（虚拟的或实际的客户机，请参见下面的“需要考虑的特 殊事项”）上重复。开始标准：功能开发完毕并可用完

22、成标准：单个事务或单个用户：在每个事务所预期时间范围内成功地完成测试 脚本，没有发生任何故障。多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本， 没有发生任何故障。测试重点和优先级：用户登录，查询，添加，修改，删除、发送、下载需考虑的特殊事项：综合的性能测试还包括在服务器上添加后台工作量。可采用多种方法来执行此操作，其中包括：直接将“事务强行分配到"服务器上，这通常以“结构化语言” （SQL 调用的形式来实现。通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。 此负载可通过“远程终端仿真（RemoteTerminal Emulation）工具来实现。 此技术还可

23、用于在网络中加载“流量”。使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负 载。性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完 全的控制和精确的评测。性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。4.1.6负载测试负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象 在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最 大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。注：以下所说的事务是指“逻辑业务事务”。这里事

24、务被定义为将由系统的某个最终用户通过使用应用程序来执行的特定功能，例如，发送或接收报文文件。测试目标核实所指定的事务或商业理由在不同的工作量条件下的性能行为时 间。测试范围：用户登录，查询，添加，修改，删除等技术：使用为功能或业务周期测试制定的测试。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务 发生的次数。开始标准：完成标准：多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有 发生任何故障。测试重点和优先级：功能开发完毕并可用需考虑的特殊事项：负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完 全的控制和精确的评测。负载测试所用的数据库应该是实际大小或相同缩

25、放比例的数据库。4.2工具此项目将列出测试使用的工具:用途工具生产厂商/自产版本缺陷管理BugzillaTerry Weissman3.2功能测试QTPMI9.2性能测试LoadrunnerMI9.1六、严重程度、优先级的定义 （可写在这里）1）用例的优先级2）缺陷的优先级3）缺陷的严重程度对于软件的错误和缺陷，目前主要依据其严重程度划分五个级别：致命性错误数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系统或其他支撑系统崩溃、 非正常关闭和非正常死机。严重性错误应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。系统的主要功能不能正确实现或不完整。一般性错误规定的非主要功能

26、没有实现或不完整、影响系统的运行；设计不合理造成性能低下。告警性错误不影响业务运行的功能问题。建议软件设计和功能实现等不完全合理之处提出建议。A. 资源培训需求本节说明项目测试人员需要哪些培训。提示和技巧：l对于新手需要先介绍测试系统，如果测试人员比较熟悉该系统，则需要说明新系统的功能 l是否进行自动测试。l测试人员要不要培训以编写自动化脚本。B. 硬件需求本节说明测试人员需要的各种类型的硬件以及这个测试团队需要的硬件。C. 软件需求本节说明测试人员需要使用的软件。D. 办公空间需求本节说明需要多少办公空间。6.1 角色下表列出了在此项目的人员配备方面所作的各种假定。 小公司：角色推荐的最少资

27、源（所分配的专职角色数量）具体职责或注释测试经理张明进行管理监督。职责：提供技术指导获取适当的资源生成测试计划，测试方案管理测试数据（Notes数据库）收集测试用例参与测试测试员测试中心提供测试员23名。执行测试。职责：执行测试记录结果从错误中恢复（返测报告）收集测试用例测试系统管理员张明确保测试环境和资产得到管理和维护。职责：管理测试系统授予和管理角色对测试系统的访问权大公司：人力资源角色所推荐的最少资源（所分配的专职角色数量）具体职责或注释测试经理测试项目经理TBD进仃管理监督。职责：提供技术指导获取适当的资源 提供管理报告测试设计员TBD确定测试用例、确定测试用例的优先级并实施测 试用例

28、。职责：生成测试计划生成测试模型评估测试工作的有效性测试员TBD执行测试。职责：执行测试记录结果从错误中恢复记录变更请求测试系统管理员TBD确保测试环境和资产得到管理和维护。职责：管理测试系统分配和管理角色对测试系统的访问权数据库管理员TBD确保测试数据（数据库）环境和资产得到管理和 维护。职责：管理测试数据（数据库）设计员TBD确定并定义测试类的操作、属性和关联关系。 职责：确定并定义测试类确定并定义测试包实施员TBD实施测试类和测试包，并对它们进行单元测试。 职责：创建在测试模型中实施的测试类和测试包6.2 系统第一种：测试项目所需的系统资源。（这个适用于对显卡要求比较高的系统，如:XXX

29、X编辑系统4.0）1. 硬件资源CPU P4 1.5G以上，或者双 PIII 800 以上。主板：Pinnacle推荐的主板，带有 AGP1槽，5个PCI32插槽。如果需要支持 3路无压 缩视频流实时播放，则需要带有2个PCI64插槽。内存:256 MB （最好 512MB。显卡：支持双屏显示，带有 OpenGL加速的显卡，显存不低于 32MB支持2048X 768真 彩色，支持 YUW接显示。如 ELSA Synergy III （NVIDIA QUADRO MXR AGP、32MB Dual Monitor Support 。视频卡：b系列及配套的接口箱。SCSI卡：支持SCSI 160的

30、双通道SCSI卡机箱：带有配套视频接口背板的机箱。硬盘：1块IDE或SCSI系统硬盘（20G以上），SCSI硬盘阵列（4块或者8块10000转 以上的SCSI硬盘）。2. 软件环境Windows 2000 + SP2b系列的SDK驱动被测试软件第二种：下表列出了测试的系统环境软件环境（相关软件、操作系统等）Windows 2003 server MySql 5.0,Tomcat 5.0Windows XPWindows 2000Linux硬件环境（网络、设备等）服务器hp380客户端 P4 2.53GHz 1G 80G网络：100M Ethernet8 .测试进度包括主要时间点的安排日期代码完

31、成时间测试遍数第一遍测试第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性能测试刘涛、测试中

32、心提供测试员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性能测

33、试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系统进行必要的培训；系 统测试阶段也需要新加入的测试人员一边测试，一边了解相关的知识；希望通过这次的测试， 新加入测试人员能够积累一定的经验。9 .3任务分配测试员测试任务刘涛、功能测试、数据库测试、集 成测试张明用户界

34、面测试、性能评价测 试、安全性测试刘月容量测试、安全性和访问控 制测试、故障转移和恢复测 试吴涛配置测试、安装测试9.系统风险、优先级风险：研发未按时完成人员流失软件不熟悉培训测试方案有误需求不明确.无需求文档9.1 系统风险由于目前同类产品比较多，市场压力比较大。计划的测试时间，不能满足测试组的要求，主要是功能冻结后的系统测试的时间可能不 够。测试资源的及时到位（设备和人员） 测试人员的培训。开发进度的变化，需求或设计的变更。开发组的版本控制。需求不明确可能导致开发的产品与目标不一致。需求变更不及时通知。测试人员获取的需求与开发人员产生分歧。测试人员与开发人员的协调与沟通。9.3 影响计划的

35、潜在因素在测试计划执行过程中，可能存在以下因素影响计划的按时完成：测试人员对被测试产品的熟悉进度慢；测试人员对测试工具的使用熟悉程序不够；被测试产品存在重大错误，以致于测试无法继续，需要开发组进行额外的调试和修改才能继续；硬件、软件或网络环境出现故障等。其中第一点是影响测试进度的最大的因素。9.4 应急措施如果上述潜在的可能事件发生，则通过适当加班来保证计划的按时完成。如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照测试暂停标准来暂停该测试。9.5 测试的局限性系统硬件配置存在不可预测的问题；测试范围不能覆盖所有的可能情况；测试时间的限制；测试数据可能不全面；测试工具自身的缺陷；

36、测试人员的失误。测试进入退出准则测试状态转换标准和再启动要求测试状态转换标准”用于开始、暂停或结束全部或部分与本计划有关的测试项的测试活动的标准，这 三种标准通常指启动标准、暂停标准和退出标准。测试再启动要求”规定当测试重启动时必须重复的测试活动。测试启动标准 测试部由公司管理层领导，具体由总工负责领导职能。各软件产品或项目组提交测试需经过公司管理 层书面指派。 公司所研发的各项面向市场的软件系统均需通过测试，才能对外发布，特殊情况由公司管理层书面认 可。公司各项软件产品的开发计划书中均需要列出交付测试时间和测试时间，以及相应的修改和回归测试时间。测试部基于各开发计划制定相应的测试计划，软件系

37、统开发计划的变更必须变更相关的测试安排。 软件产品或项目提交测试部进行测试必须满足以下条件：提交测试的软件系统必须是一个稳定的、 待发布的版本，必须明确定义系统版本号（即在系统各部分， 系统本身、用户手册等方面均表明该版本），如果本版本还没有开发完成或将进行大量的修改，不能提交测 试；软件产品或项目在提交测试之前，本产品或项目组必须在内部进行自己的单元测试和集成测试；提交测试的软件系统必须是商品化包装的，并需附有：用户手册、使用说明书（至少两者必备其一）；软件需求说明书；其它最好还能够提交相关培训教材、演示程序等电子文档。软件系统开发组必须向测试部提供足够的培训和技术指导，以便测试工作的顺利开

38、展。在测试期间， 开发组必须指定一名骨干开发人员，帮助测试部解决相关问题。若是对将发布的产品或将验收的项目进行测试，则必须给测试留出足够的时间，以保证测试的质量。提交测试的软件系统版本在测试期间保持稳定，即测试部只对初始提交的系统版本进行测试，产品或项目组在测试期间的修改只在下一轮测试中进行测试。特殊情况（即提交版本无法继续测试，如安装程序错误等问题）下，可以在测试期间更换版本，但必须经过测试部的同意。回归测试是指不包含功能修改（含界面修改等）情况下测试部对原来测出的问题进行的再次测试。若引入新功能超过10%，则认为是新的系统测试，测试部必须进行全面测试。测试暂停标准当在测试过程中出现下列情况

39、之一，则测试将暂停： 对于某类测试，测试环境变得（或者测试中发现）没有准备好，则暂停此类测试； 对于提交测试的版本而言，如果其预计的功能修改量超过总功能的10%， 产品或项目组应即时通报测试部，并向公司相关负责人汇报，测试部有权利向公司领导建议暂停或取消本轮测试，避免测试的无效劳动，避免造成人力、财力等资源的浪费。 发现被测试系统有大量错误或非常严重错误，以至于测试不能继续或继续测试没有意义，则测试部应向总工提交报告，由总工决定是否暂停整个系统测试。 当系统中某个功能模块有非常严重的错误，以致于不能完成预期的功能，则暂停此功能模块的测试。测试退出标准当出现下列情况之一则退出此系统的本次测试： 测试计划中所有规定的测试内容和回归测试都已经运行完成。 根据上级主管对测试结果的意见，要求结束本次测试。4 启动要求当测试重新启动时，必须重复的主要测试活动有： 当是某功能模块的测试重新启动时，则此功能模块的所有测试用例都要重新运行，并且调用此功能模块的其他功能模块的相关测试用例也要重新运行。 当是整个系统的测试重新启动时，则发生修改的部分和与之相关联的部分的