《软件测试计划说明书》由会员分享，可在线阅读，更多相关《软件测试计划说明书（23页珍藏版）》请在文档大全上搜索。
1、精选优质文档-倾情为你奉上卷号卷内编号密级分 类:TEST使用者:项目名称：跳棋游戏 项目编号:S600-03-2010 测试计划Version: 1.00项 目 承 担 部 门： 电子工程学院 撰 写 人（签名）： 张受干 完 成 日 期： 2010-7-4 本文档 使 用部门： 主管领导 项目组 客户（市场） 维护人员 用户 评审负责人（签名）： 评 审 日 期： 文档信息项目名:跳棋游戏 项目编号: S600-03-2010 标题:System Test Plan作者:张受干创建日期:2010-6-12 10:32上次更新日期: 版本:1.0部门名称:软件评测部文档状态文档状态草稿 正式
2、文档评审人员评审时间修订文档历史记录日期版本说明作者2010-06-121.0初始版本张受干2010-06-152.0根据项目计划及迭代计划调整，修改部分测试需求及测试策略朱国柱专心-专注-专业目录 Test Plan1. 简介1.1 目的“跳棋游戏的测试计划”文档有助于实现以下目标：a、 确定幸福跳棋游戏测试的信息和应测试的软件构件。b、 确定游戏测试的测试需求（高级需求）。c、 根据测试需求确定测试策略，并对这些策略加以说明。d、 确定系统测试所需的资源，并对测试的工作量进行估计。e、 列出项目测试的可交付工件。1.2 背景本软件来源幸福之家的小游戏，经过用户的广泛应用，发现了一些吧不易发
3、现的bug，因此要对该游戏进行改进和测试。1.3 范围a、 本测试计划是在项目的Elaboration Phase对整个项目测试工作的一个详细描述，它将是以后所有测试工作的基础。b、 幸福跳棋游戏项目的测试包括以下类型的测试活动。功能确认测试性能测试容量测试安全性和访问控制测试配置测试安装测试用户界面测试c、 系统测试将实现部分测试自动化，自动化脚本采用Rational Robot编写；实现100%的需求覆盖，采用TestManager来评估需求覆盖情况。d、 本测试计划中的活动在Elaboration阶段将完成系统测试计划，所有高优先级的系统测试用例。e、 本测试计划实施的前提条件是：项目组
4、按照开发计划完成项目的实施、测试组能够熟练使用Rational测试工具、测试组与分析与设计组、编码组协调一致。f、 本测试计划在以后的迭代中会根据需求和迭代计划的变更而新增或更新。g、 本测试计划适用于“幸福之家跳棋游戏”项目。本文档将供给项目经理及项目开发各组使用，包括测试组、分析与设计组、编码组、SQA组、SCM组。1.4 项目标识下表列出了制定系统测试计划所用的文档，并标明了文档的可用性：文档（版本/日期）已创建或可用已被接受或已经过复审作者或来源备注用例模型 是 o 否 是 o 否REQ补充规约 是 o 否 是 o 否REQ前景 是 o 否 是 o 否REQ项目计划 是 o 否 是 o
5、 否PM迭代计划 是 o 否 是 o 否PMElaboration迭代计划测试需求下面列出了在项目测试中需要测试的测试对象（用例、功能性需求和非功能性需求）。1.5 功能测试需求核实Use Case Model中的所有用例、用例场景。测试需求ID核实用例优先级TR-SST-QueryConsignQueryconsign高TR-SST-ReaveTaskReaveTask高TR-SST-CreateInstanceTR-SST-CreateInstance高TR-SST-AssignTaskAssignTask高TR-SST-UpdateTaskStateUpdateTaskState高TR-
6、SST-GetBackTacheGetBackTache低TR-SST-GetHistoryTacheGetHistoryTache低TR-SST-GetFlowTypeGetFlowType高TR-SST-GetFrontTacheGetFrontTache低TR-SST-ApplyRuleJumpApplyRuleJump低TR-SST-ConfirmValidityConfirmValidity低TR-SST-ConfirmFlowConfirmFlow高TR-SST-SelJumpTypeSelJumpType低TR-SST-SelTargetTacheSelTargetTache低T
7、R-SST-ExeRuleJumpExeRuleJump低TR-SST-AllotTacheAllotTache高TR-SST-AllotTaskAllotTask低TR-SST-ReAssignTaskReAssignTask低TR-SST-EditModelEditModel高TR-SST-GetUsersGetUsers高TR-SST-ManageRuleAuthorityManageRuleAuthority低TR-SST-TestValidityTestValidity低TR-SST-SubmitModelSubmitModel高TR-SST-ImportModelImportMod
8、el高TR-SST-VerifyUserVerifyUser高TR-SST-注册组件注册组件高TR-SST-CreateTaskConsignCreateTaskConsign高TR-SST-UpdateTaskConsignUpdateTaskConsign高TR-SST-CancelTaskConsignCancelTaskConsign高缺查询任务委托高TR-SST-BackupLogBackupLog低TR-SST-QueryLogQueryLog低TR-SST-DeletingLogDeletingLog低TR-SST-ModifyRolePeopleModifyRolePeople
9、高TR-SST-QueryRolePeopleQueryRolePeople高TR-SST-QueryPersonRoleQueryPersonRole高TR-SST-ModifyRoleNameModifyRoleName高TR-SST-DeleteRoleDeleteRole高TR-SST-AddURoleAddURole高TR-SST-QueryServerStateQueryServerState高TR-SST-DeActivateInstanceDeActivateInstance低TR-SST- ShutdownServerShutdownServer高TR-SST- Activa
10、teInstanceActivateInstance低TR-SST- StartServerStartServer高TR-SST- interposeInstanceinterposeInstance低TR-SST- ResetInstanceResetInstance低TR-SST- RestartServerRestartServer高TR-SST- distoryInstancedistoryInstance低TR-SST- QueryRouteInfoQueryRouteInfo高TR-SST- QueryTaskQueryTask低TR-SST- DeleteTaskDeleteTa
11、sk低TR-SST- PromptOverTimeTaskPromptOverTimeTask低TR-SST- PromptInTimeTaskPromptInTimeTask低TR-SST- PromptNewTaskPromptNewTask低1.6 性能测试需求根据补充规约，本系统没有性能方面的特殊需求。1.7 安全性和访问控制测试需求核实Supplementary Specification中的访问控制需求。测试需求ID：TR-SST-Safety-001 优先级：高核实非注册产品可以在三十天内随意使用，三十天后产品自动会要求用户注册。1.8 用户界面测试需求核实Supplementa
12、ry Specification中的用户界面要求：测试需求ID：TR-SST-GUI-001 优先级：低核实用户界面的设计将遵循Microsoft 用户界面开发和分析指南。1.9 安装测试需求 核实以下测试需求：测试需求ID：TR-SST-Install-001 优先级：低核实首次安装、重复安装、选择安装后，安装游戏能正常运行。测试需求ID：TR-SST-Install-002 优先级：低核实卸载后，该游戏没有残余。2. 测试策略首先用确定软件检测软件的功能是否符合用户的要求，参照需求规格说明书，其次才采用系统测试，使其与计算机硬件，外设，某些支持软件，数据和人员等其他系统元素结合在一起，在实
13、际运行环境下，对计算机系统一系列的测试，并有测试人员模拟用户进行测试。 2.1 测试类型2.1.1 数据和数据库完整性测试因项目不涉及数据库，不需要数据和数据库完整性测试。2.1.2 功能测试功能测试是对2.1中的测试需求进行功能确认测试。这些测试的目标在于确认用例或用例场景是否能够实现。这种类型的测试采用黑盒测试方法，即通过图形用户界面 (GUI) 与应用程序交互并分析输出结果来确认应用程序的正确性。测试目标：确保功能测试需求对应的用例、用例场景能够实现。方法：采用黑盒测试技术设计功能测试用例。为各测试用例制定测试过程。并且录制、编辑脚本用于回归测试。执行测试用例来核实各用例、用例场景、用例
14、流。主要核实以下内容： 使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。完成标准： 所计划的测试能够覆盖用例事件流（基本流及所有备选流），并且所计划的测试已全部执行。 所发现的缺陷已全部解决。需考虑的特殊事项：无业务周期测试因项目不涉及具体业务，不需要业务周期测试。3.1.4 用户界面测试通过用户界面 (UI) 测试来核实用户与软件的交互。UI 测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。确保 UI 功能内部的对象符合预期要求，并遵循补充规约中定义的用户界面设计标准Microsoft 用户界面开发和分析指南。为测试需求TR-SST-G
15、UI-001设计测试。测试目标：核实以下内容： 通过浏览测试对象可正确反映功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab 健、鼠标移动和快捷键）的使用 窗口的对象和特征（例如：菜单、大小、位置、状态和中心）都符合标准。方法：为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。完成标准：各界面元素满足Microsoft 用户界面开发和分析指南标准。需考虑的特殊事项：因Microsoft 用户界面开发和分析指南内容较多，希望提取常用界面元素标准形成检查表。以检查表的形式来检查界面。性能评价本项目没有性能方面的要求。
16、负载测试本项目不作负载测试。2.1.3 强度测试本项目不考虑强度测试。2.1.4 容量测试本项目不考虑容量测试。安全性和访问控制测试安全性和访问控制测试侧重于安全性的两个关键方面：应用程序级别的安全性，包括对数据或功能的访问游戏级别的安全性，包括对游戏的登录或远程访问。应用程序级别的安全性可确保：系统级别的安全性可确保：非注册用户在30天内可以使用本系统，30天后提示用户注册。测试目标：用来对测试需求TR-SST-Safety-001进行验证。方法：应用程序级别的安全性：确定并列出各用户及其被授权访问的日记和日记本。为各用户创建测试，并通过创建各用户所特有的功能(如翻看日记)来核实其访问权限。
17、系统级别的访问：1、 非注册用户下载程序，利用功能测试脚本运行程序。2、 修改系统时间为29、30、31天后，利用功能测试脚本运行程序。在29天能够正常运行，30天和31天后，出现提示用户注册信息。3、 用户注册后，利用功能测试脚本运行程序，所有功能正常运行。完成标准：完成所计划的测试。需考虑的特殊事项：无2.1.5 故障转移和恢复测试本项目不考虑故障转移和恢复测试。2.1.6 配置测试本项目不考虑配置测试。安装测试安装测试有两个目的。第一个目的是确保该软件能够在所有可能的配置下进行安装，例如，进行首次安装、完整的或自定义的安装，以及在正常和异常情况下安装。异常情况包括磁盘空间不足、缺少目录创
18、建权限等。第二个目的是核实软件在安装后可立即正常运行。这是指运行大量为功能测试制定的测试。另外在安装测试后需要测试卸载。测试目标：核实在以下情况下，测试对象可正确地安装到各种所需的硬件配置中，或从计算机卸载。首次安装。以前从未安装过TPWF的新计算机更新。以前安装过相同版本的 TPWF 的计算机卸载。卸载TPWF。 方法：安装：启动或执行安装。使用预先确定的功能测试脚本子集来运行软件。 卸载： 卸载应用程序，检查注册表、安装路径、系统路径中关于TPWF的文件或信息是否完全卸载。完成标准：软件能够成功执行，没有出现任何故障。 软件完全卸载，没有残余。需考虑的特殊事项：安装和卸载时，对于公共组件应
19、该提示。2.2 工具此项目将使用以下工具：用途工具厂商/自行研制版本测试管理Rational TestManagerRational2001.05缺陷跟踪Rational ClearQuestRational2001.05用于功能性测试的工具Rational RobotRational2001.05用于性能测试的工具Rational TestManagerRational2001.05项目管理MS Word、MS ProjectMicrosoft20003. 资源以下确定了项目测试所需要的人力资源以及软硬件资源。对测试所需要的脚色进行了分配、明确职责。3.1 角色人力资源角色推荐的最少资源（所
20、分配的专职角色数量）具体职责或注释测试经理吕军进行管理监督。 职责：提供技术指导获取适当的资源提供管理报告测试设计员吕军、刘飚、陈旭确定测试用例、确定测试用例的优先级并实施测试用例。职责：生成测试计划生成测试模型（测试用例、测试过程、测试脚本）评估测试工作的有效性测试员陈旭、刘飚执行测试。职责：执行测试记录结果从错误中恢复记录缺陷测试系统管理员吕军确保测试环境和资产得到管理和维护。职责：管理测试系统授予和管理角色对测试系统的访问权配置管理员邱小波职责： 对测试工件实施配置管理。 及时通知对测试有影响的变更。 项目里程碑跳棋游戏测试在Elaboration Phase划分成以下2个阶段。具体时间
21、安排见Elaboration Iteration Plan.里程碑任务工作量开始日期制定测试计划2day待Use Case Model & Supplementary Specification通过复审后开始设计测试10day待Use Case Specification通过复审后开始TPWF 的系统测试在Construction Phase划分成以下5个阶段。具体时间安排见Construction Iteration Plan.里程碑任务工作量制定测试计划0.5day设计测试10day实施测试10day执行测试15day评估测试2day4. 可交付工件系统测试需交付的主要工件如下：工件名称负
22、责人参与者交付时间系统测试计划张受干张受干2010-6-17系统测试用例朱国柱张受干、陈旭2010-6-17系统测试脚本刘飚吕军、陈旭TBD系统测试评估报告吕军刘飚TBD4.1 测试模型系统测试模型将引用系统测试用例、测试脚本。并建立它们之间的关系。4.2 测试日志计划使用 Rational RequisitePro 来确定测试用例并跟踪每个测试用例的状态。测试用例的最终状态将在 RequisitePro中定义成“No Test”、“Pass”、“Conditional Pass”、“Failure”四种状态。当然，在测试过程中，你还可以自定义中间状态。也就是说，可以通过设置 Requisit
23、ePro 以支持下列每个测试用例的属性：1、测试状态 2、工作版本号 3、测试者 4、测试日期 5、测试说明 更新 RequisitePro 中的测试用例的状态是系统测试员的职责。测试结果将保留在配置控制之下。4.3 缺陷报告可采用ClearQuest 用来记录和跟踪各个独立的缺陷。采用“测试日记”来报告缺陷。附录 A：项目任务以下是一些与测试有关的任务：制定测试计划- 确定测试需求- 评估风险- 制定测试策略- 确定测试资源- 创建时间表- 生成测试计划设计测试-准备工作量分析文档-确定并说明测试用例-确定并结构化测试过程-复审和评估测试覆盖实施测试- 记录或通过编程创建测试脚本- 确定设计与实施模型中的测试专用功能- 建立外部数据集执行测试-执行测试过程-评估测试的执行情况-恢复暂停的测试-核实结果-调查意外结果-记录缺陷评估测试-评估测试用例覆盖-评估代码覆盖-分析缺陷-确定是否达到了测试完成标准与成功标准
