航空订票系统软件测试计划v.doc

航空订票系统测试计划航空订票系统测试计划 文件编号： ticket/2009-06-11 版 本 号：1.0 发放编号： 受控状态： 审 核：， 日 期：2009 年 06 月 11 日 批 准： 日 期：2009 年 06 月 11 日 发布日期：2009 年 06 月 11 日 实施日期：2009 年 06 月 11 日 目目 录录 1 引言.5 1.1 测试计划概述.5 1.2 被测试系统概述.5 1.3 测试计划制定依据.6 1.4 预期读者.6 2 测试范围.6 2.1 测试特性与软件需求的对应关系.7 2.2 被测试特性.7 3 术语定义.7 3.1 软件错误与缺陷定义.7 3.2 其他术语的定义.7 4 测试目标与策略.7 4.1 测试目标.7 4.2 测试方法.7 4.3 测试工具.8 4.4 测试地点.8 5 测试状态转换标准和再启动要求.8 6 测试通过准则 .8 7 应提供的测试文档.8 8 测试资源需求 .8 8.1 硬件需求.8 8.2 软件需求.9 8.3 网络需求.9 8.4 人员需求.9 8.5 其他需求.9 9 人员、职责及培训要求.9 9.1 人员组成.9 9.2 人员分工与职责.9 9.3 培训要求.9 10 测试进度.10 11 风险和应急.10 11.1 影响计划的潜在因素.10 11.2 应急措施.11 12 测试的局限性 .11 13 计划的批准.11 14 参考文档.11 1引言引言 1.1测试计划概测试计划概述述 计划名称：航空订票系统测试计划 文档编号：ticket/2009-06-11 测试部门：软件测试部 计划作者：罗敏 计划审核：在 windows 平台下运行航空订票系统,针对该项目中各个模块应 实现的不同功能,生成测试用例文档,再手动进行测试。 /* 此部分主要对测试计划的名称、背景、目标、制定依据以及执行部门， 测试的方法、工具、范围作一个简明扼要的阐述。*/ 1.2被测试系统概被测试系统概述述 产品名称：航空订票系统 开发部门：软件开发部 测试版本：v 1.0 最新版本：v 1.0 系统概述：该系统主要实现了预订机票的功能,并生成订单便于查询和修改, 主要针对用户登录模块和生成订单模块进行测试。 /* 此部分主要对被测试系统的基本用途、功能、特性以及计划测试的软件 项进行简要的描述。 */ 1.3测试计划制定依据测试计划制定依据 对测试计划的制定依据给以说明。 测试计划的制定依据本系统的软件需求规格说明书，另外还可能包括开 发部提供的软件测试需求说明书、被测试系统的用户手册、使用说明书以及软 件系统自身特性，有时还需要参考用户的意见和建议。另外测试计划的制定要与 被测试系统的质量保证计划相一致。 1.4预期读者预期读者 主要可能包括以下人员：项目管理人员、测试人员、系统开发人员，有时 还会包括部分用户。 2测试范围测试范围 在这一部分中，要定义需要测试和不需要测试的内容，定义与测试计划执 行有关的重要术语和缩略语，并决定与测试子项目有关的测试工作所发生的场 合。 严格按照软件需求规格说明书中的功能、性能等要求，同时兼顾软件系统 自身特性、用户的意见和建议、被测试系统的质量保证计划等，对软件系统的被 测试特性和不被测试特性以下表的格式详细列出。 航空订票航空订票系统的测试范围系统的测试范围 被测试模块被测试模块被测试特性被测试特性 InputInput usernameusername 用户登录模块用户登录模块 InputInput passwordpassword DateDate ofof FlightFlight FlightsFlights namename InsertInsert orderorder UpdateUpdate orderorder 生成订单模块生成订单模块 DeleteDelete orderorder 菜单栏菜单栏File Edit Analysis Help Insert order Open order Delete order Graph Report 工具栏工具栏 Help 2.1测试特性与软件需求的对应关系测试特性与软件需求的对应关系 本部分详细说明在本次测试中计划测试的内容与软件需求规格说明书 的对应关系，对照需求计划测试的内容。 2.2被测试特性被测试特性 1. 用户登录模块：用户登录模块： 测试用户名和密码的有效性，主要包括文本框中所输入文本的长度，类 型，格式，密码的显示状态以及用户名与密码的一致性，还有是否能实 现控件所标注的功能。 2生成订单模块：生成订单模块： (1)测试机票订单的有效性，主要包括航班日期，航班路线和详细信息，以 及预定者的姓名。 (2)测试是否能实现与订单相关其他的功能，主要包括插入订单，修改订单 以及删除订单。 (3)测试各种控件的组合使用，主要包括整个界面的布局以及风格，控件间 的相互作用，Tab 键的顺序，热键的使用，回车键和 ESC 键的使用，控 件组合后功能的实现。以及文本框是否可输入，下拉列表是否可选，单选 框是否有默认值且不能多选，按钮是否有默认值等。 3菜单栏：菜单栏： 测试是否能够正确实现菜单栏中各菜单项指明的功能。 4工具栏：工具栏： 测试是否能够正确实现工具栏中指明的各项功能。 /*指明所有要被测试的软件特性及其组合，指明每个特性或特性组合有关的测 试设计说明。*/ 3术语定义术语定义 此部分定义与测试计划执行有关的重要术语和缩略语，其中主要对软件错 误与缺陷的划分标准进行定义。 3.1软件错误与缺陷定义软件错误与缺陷定义 软件错误与缺陷定义见附录。 3.2其他术语的定义其他术语的定义 4测试目标与策略测试目标与策略 4.1测试目标测试目标 通过对该系统中各个模块的测试，找出系统中可能存在的缺陷，确保该系统的可用性 和稳定性。 4.2测试方法测试方法 该系统用到得测试方法有： 1.界面测试：主要针对系统中的登录界面和生成订单界面，如各个控件的 摆放次序是否规范,是否存在中英文混杂的问题。 2.功能测试：对菜单栏和工具栏的测试大部分都是功能测试，主要用来确 定是否完整的实现了模块的功能。 3 控件测试：既要对单个控件的功能进行测试，也要看控件是否符合自身的需求,如: 单选框是否有默认值等,还要看各控件组合起来是否实现了其对应的功能。 4.3测试工具测试工具 对于测试中用到的测试工具给以简单的介绍，对使用测试工具准备进行的 测试种类给以简明的描述。 4.4测试地点测试地点 北京达内中关村校区中鼎大厦 231 教室。 5测试状态转换标准和再启动要求测试状态转换标准和再启动要求 测试状态转换标准和再启动要求见附录。 6测试通过准则测试通过准则 测试通过准则参见附录。 7应提供的测试文档应提供的测试文档 软件产品提交测试委托书 软件测试需求说明书 测试计划 测试用例设计与执行报告 测试结果报告 测试分析报告 8测试测试资源需求资源需求 8.1硬件需求硬件需求 /* 对于测试所必备的和希望有的硬件设备及其配置给以说明。并指出目前还 不能得到的硬件设备及其配置。 */ 8.2软件需求软件需求 操作系统：WindowsXP/Windows2000 /* 对于测试所必备的和希望有的软件（包括所需要的测试工具软件）给以说 明，并指出目前还不能得到的软件。 */ 8.3网络需求网络需求 对于测试所必备的和希望有的网络环境给以说明。 8.4人员需求人员需求 对于测试所需人员及其应具备的知识给予说明。 8.5其他需求其他需求 对于上面没有涉及到的其他需求给以说明。 9人员、职责及培训要求人员、职责及培训要求 9.1人员组成人员组成 对参与测试活动的所有人员的姓名及其工作角色给以清楚的说明。 参与测试的人员通常由项目负责人、质量人员、测试负责人、测试人员、 项目开发组负责人或项目开发人员组成，有时还包括用户等参与测试的其他人 员。 9.2人员分工与职责人员分工与职责 人员分工与职责见附录。 9.3培训要求培训要求 指出测试人员开展和完成测试所需要进行的培训活动。培训活动主要包括 被测试系统、被测试系统的支撑系统以及测试工具的培训。同时对每一项培训 的负责人给以明确的说明。 测试工具的培训通常由测试部内部委派人员来完成。 被测试系统及其支撑系统的培训通常由被测试系统开发部委派人员来 完成。 10 测试进度测试进度 此部分要明确给出测试活动中主要事件的计划表。估计完成每项测试任务 所需的时间，为每项测试任务和测试里程碑规定进度。 测试进度可以以下表的格式给出。 测试进测试进度度计计划表划表 起止日期起止日期测试测试任任务务 2009-6-11用户登录模块, 生成订单模块 2009-6-12菜单模块,工具栏模块 11 风险和应急风险和应急 11.1 影响计划的潜在因素影响计划的潜在因素 在测试计划的执行过程中，对可能存在的影响计划按时完成的风险因素进 行分析。 在测试计划执行过程中，通常可能存在以下因素影响计划的按时完成，其中 第一点和第三点是影响测试进度的最大可能因素： 测试人员对被测试产品的熟悉进度较慢； 测试人员对测试工具的使用熟悉程度不够； 被测试产品存在重大错误，以致于测试无法继续，需要开发部进行额外 的调试和修改才能继续； 硬件、软件或网络环境出现故障等。 11.2 应急措施应急措施 对潜在风险因素的应急措施逐项给以明确规定。 通常的应急措施有： 通过适当加班来保证计划的按时完成； 如果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照 测试暂停标准来暂停该测试。 12 测试的局限性测试的局限性 对由各种因素（包括测试方法、使用的工具、测试环境及测试人员的素质 等）引起的测试局限性进行简要的分析。 影响测试完全的因素通常包括： 系统硬件配置存在不可预测的问题； 测试范围不能覆盖所有的可能情况； 测试时间的限制； 测试数据可能不全面； 测试工具自身的缺陷； 测试人员的失误。 13 计划的批准计划的批准 规定本计划必须由哪些人 (姓名和职务)审批，并为签名和日期留出位 置。 14 参考文档参考文档 列出本测试计划引用的其他文档，如产品使用说明书、用户手册、产品需 求分析、质量风险分析文档、测试需求方案，以及其他相关信息。 列出这些文档可以避免大量重复其内容。 附录附录 软件错误与缺陷的定义软件错误与缺陷的定义 对于软件的错误和缺陷，目前主要依据其严重程度划分五个级别： 致命性错误致命性错误 数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系 统或其他支撑系统崩溃、非正常关闭和非正常死机。 严重性错误严重性错误 应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。系统的主要功 能不能正确实现或不完整。 一般性错误一般性错误 规定的非主要功能没有实现或不完整、影响系统的运行； 设计不合理造成 性能低下。 告警性错误告警性错误 不影响业务运行的功能问题。 建议建议 软件设计和功能实现等不完全合理之处提出建议。 附录附录 测试测试状态转换标准和再启动要求状态转换标准和再启动要求 “测试状态转换标准”用于开始、暂停或结束全部或部分与本计划有关 的测试项的测试活动的标准，这三种标准通常指启动标准、暂停标准和退出 标准。 “测试再启动要求”规定当测试重启动时必须重复的测试活动。 2测试启动标准测试启动标准 测试部由公司管理层领导，具体由总工负责领导职能。各软件产品或项 目组提交测试需经过公司管理层书面指派。 公司所研发的各项面向市场的软件系统均需通过测试，才能对外发布， 特殊情况由公司管理层书面认可。 公司各项软件产品的开发计划书中均需要列出交付测试时间和测试时间， 以及相应的修改和回归测试时间。测试部基于各开发计划制定相应的测 试计划，软件系统开发计划的变更必须变更相关的测试安排。 软件产品或项目提交测试部进行测试必须满足以下条件： 提交测试的软件系统必须是一个稳定的、待发布的版本，必须明确定 义系统版本号（即在系统各部分，系统本身、用户手册等方面均表明 该版本） ，如果本版本还没有开发完成或将进行大量的修改，不能提 交测试； 软件产品或项目在提交测试之前，本产品或项目组必须在内部进行自 己的单元测试和集成测试； 提交测试的软件系统必须是商品化包装的，并需附有： 用户手册、使用说明书（至少两者必备其一） ； 软件需求说明书； 其它最好还能够提交相关培训教材、演示程序等电子文档。 软件系统开发组必须向测试部提供足够的培训和技术指导，以便测试 工作的顺利开展。在测试期间，开发组必须指定一名骨干开发人员， 帮助测试部解决相关问题。 若是对将发布的产品或将验收的项目进行测试，则必须给测试留出足 够的时间，以保证测试的质量。 提交测试的软件系统版本在测试期间保持稳定，即测试部只对初始提 交的系统版本进行测试，产品或项目组在测试期间的修改只在下一轮 测试中进行测试。特殊情况（即提交版本无法继续测试，如安装程序 错误等问题）下，可以在测试期间更换版本，但必须经过测试部的同 意。 回归测试是指不包含功能修改（含界面修改等）情况下测试部对原来 测出的问题进行的再次测试。若引入新功能超过 10%，则认为是新的 系统测试，测试部必须进行全面测试。 3测试测试暂停标准暂停标准 当在测试过程中出现下列情况之一，则测试将暂停： 对于某类测试，测试环境变得（或者测试中发现）没有准备好，则暂停 此类测试； 对于提交测试的版本而言，如果其预计的功能修改量超过总功能的 10%，产品或项目组应即时通报测试部，并向公司相关负责人汇报，测试 部有权利向公司领导建议暂停或取消本轮测试，避免测试的无效劳动， 避免造成人力、财力等资源的浪费。 发现被测试系统有大量错误或非常严重错误，以至于测试不能继续或继 续测试没有意义，则测试部应向总工提交报告，由总工决定是否暂停整 个系统测试。 当系统中某个功能模块有非常严重的错误，以致于不能完成预期的功能， 则暂停此功能模块的测试。 4测试测试退出标准退出标准 当出现下列情况之一则退出此系统的本次测试： 测试计划中所有规定的测试内容和回归测试都已经运行完成。 根据上级主管对测试结果的意见，要求结束本次测试。 5启动要求启动要求 当测试重新启动时，必须重复的主要测试活动有： 当是某功能模块的测试重新启动时，则此功能模块的所有测试用例都要 重新运行，并且调用此功能模块的其他功能模块的相关测试用例也要重 新运行。 当是整个系统的测试重新启动时，则发生修改的部分和与之相关联的部 分的测试用例都要重新运行。 附录附录 测试测试通过准则通过准则 1测试项通过标准测试项通过标准 测试项的通过标准目前定义为： 当此项的功能能够正确地完成，并且它的操作没有引起其他功能项或整个 系统的错误，则认为此项测试通过。 2系统测试通过标准系统测试通过标准 系统测试的通过标准目前定义为： 对于每一类测试，当没有发现致命性错误和严重性错误、一般性错误数量 小于测试用例总数的 2%，告警性错误数量小于测试用例总数的 5%，则认为系统 通过