1、 Openoffice.org writer 应用软件 测试计划 文 档 编 号：JBTEST-011-05- Openoffice.org writer 03 版 本 号：2.0.4 软件产品名称：Openoffice.org writer 软件开发部门：开发一部 软件测试部门：软件测试部 编 写：刘绍华 日 期：2003 年 06 月 30 日 审 核：秃 子 日 期：2003 年 07 月 01 日 批 准：X X 日 期：2003 年 07 月 01 日 软件测试计划 文档编号: JBTEST-011-05- OPENOFFICE.ORG WRITER 03 目 录 1. 引言4 1.
2、1 测试计划概述.4 1.2 被测试系统概述.4 1.3 测试计划制定依据.4 1.4 预期读者.4 2. 测试范围5 2.1 测试特性与软件需求的对应关系.6 2.1.1 安装/卸载测试6 2.1.2 功能测试.6 3. 术语定义7 3.1 软件错误与缺陷定义.7 3.2 其他术语的定义.7 4. 测试目标与策略8 4.1 测试目标.8 4.2 测试方法.8 4.3 测试工具.8 4.4 测试地点.8 5. 测试状态转换标准和再启动要求8 6. 测试通过准则8 7. 应提供的测试文档8 8. 测试资源需求9 8.1 硬件需求.9 8.2 软件需求.9 8.3 网络需求.9 8.4 人员需求.
3、9 8.5 其他需求.9 9. 人员、职责及培训要求.10 第 2 页 共 16 页软件测试计划 文档编号: JBTEST-011-05- Openoffice.org writer 03 9.1 人员组成10 9.2 人员分工与职责10 9.3 培训要求10 10.测试进度.10 11.风险和应急.11 11.1 影响计划的潜在因素11 11.2 应急措施11 12.测试的局限性.11 13.计划的批准.11 14.参考文档.11 第 3 页 共 16 页软件测试计划 文档编号: JBTEST-011-05- Openoffice.org writer 03 1 引言 1.1 测试计划概述
4、计划名称： Openoffice.org writer 应用软件文档编号： JBTEST-011-05- Openoffice.org writer 03 测试部门： 软件测试部 计划作者： 刘绍华 计划审核： 于晓鹏（总工程师） 本测试计划将对 Openoffice.org writer 应用软件的测试方法、测试工具、测试 范围、测试种类、测试的软件硬件环境、测试进度、测试人员的分工和职责以及 测试流程进行详细的定义和整体的描述。 对 Openoffice.org writer 应用软件将采用黑盒测试方法、计划利用 10 个工作 日完成第一轮测试。 1.2 被测试系统概述 产品名称： Ope
5、noffice.org writer 应用软件开发部门： 开发一部 测试版本： V2.0.4 最新版本： V2.0.4 Openoffice.org writer 应用软件基础功能：文件管理、编辑管理、视图管理、插入管理、格式管理、表格管理、工具管理、视窗管理、帮助管理。1.3 测试计划制定依据 本测试计划是依据 Openoffice.org writer 应用软件开发计划 、 Openoffice.org writer 应用软件需求规格说明书等。 1.4 预期读者 （1） 项目管理人员； （2） 测试人员； （3） 开发人员。 第 4 页 共 16 页软件测试计划 文档编号: JBTEST-
6、011-05- OPENOFFICE.ORG WRITER 03 2 测试范围 测试类型 是否计划进行测试 测试的优先级 说明安装/卸载测试 是 最高优先级 程序的安装与卸载测试功能测试 是 最高优先级 系统功能的正确实现及与需求是否符合的测试资源占有测试 否 对系统在安装或运行后对硬盘、内存、CPU及网络占有率测试兼容性测试 是 低优先级 系统对各种运行环境的兼容性（例如操作系统浏览器）以及与历史版本的兼容性、与第三方软件的兼容性测试可靠性/稳定性测试是 最高优先级 系统运行的可靠性、对各种异外情况错误处理能力的测试并发测试 否 系统对并发操作的支持性测试压力测试 否 系统在大负载量条件的性
7、能测试用户友好性 是 中等优先级 主要是指测试人员以用户的角度对系统操作的方便性、可使用性、界面友好性的给出评价。软件安全性 否 主要从软件安全性角度测试系统对业务数据保存、访问及软件系统自身的安全性进行测试。配置测试 否 指对被测系统使用说明书中要求的软硬件配置进行验证。在此主要指硬件的配置要求验证测试。恢复测试 否 是指被测试系统的服务器端或客户端或网络在机器突然出故障（例如突然断电或断网）后重新恢复正常的能力测试。文档检查 否 对提供的用户手册、系统的在线帮助等技术文档进行一致性检查。其他测试： 否备注：（1 ）请在表中选择本次测试计划进行的测试类型，并对测试的优先级给以说明。 （2）测
8、试的优先级分为四个级别，请在表格中填写相应序号。 1 最高优先级：首先测试，并详细测试； 2 中等优先级：正常测试； 3 低优先级： 只需粗略测试，但本次测试必须进行； 4 最低优先级：只需粗略测试，可以留到下轮测试进行； 第 5 页 共 16 页 软件测试计划 文档编号: JBTEST-011-05- OPENOFFICE.ORG WRITER 03 2.1 测试特性与软件需求的对应关系 2.1.1 安装/卸载测试 表 3 安装环境测试需求说明 操作系统 数据库 其他支撑软件或操作系统 备注Server 端 Win 2000 advance serverSql server 2000 ent
9、erprise edition如果是独立软件也请填写本各行数据。Client/Browser端Winxp、 win2000professional如果是 B/S 结构或独立软件，本行数据不填。2.1.2 功能测试 表 4 功能测试需求说明 模块名称 测试需求 模块开发人员 备注文件管理 刘绍华编辑管理 刘绍华视图管理 刘绍华插入管理 刘绍华格式管理 刘绍华表格管理 刘绍华工具管理 刘绍华视窗管理 刘绍华帮助管理 刘绍华备注：（1）在测试项一栏中，请填写需要进行测试的主要功能模块，不需要划分太细， 以功能模块进行划分即可。 （2）在“测试注意事项或特殊说明”一栏，请给出在进行本项测 试时，需要重
10、点测试的方面或其他使用说明。 3 术语定义 此部分定义与测试计划执行有关的重要术语和缩略语，其中主要对软件错误 与缺陷的划分标准进行定义。 3.1 软件错误与缺陷定义 软件错误与缺陷定义见附录。 3.2 其他术语的定义 无。 第 7 页 共 16 页 软件测试计划 文档编号: JBTEST-011-05- OPENOFFICE.ORG WRITER 03 4 测试目标与策略 4.1 测试目标 尽可能发现系统中存在的错误和设计缺陷。验证系统的可靠性，检查系统 的正确性和系统的友好性。 4.2 测试方法 采用黑盒测试的方法。 4.3 测试工具 主要进行功能的手工测试，所以没有使用特殊的测试工具。
11、4.4 测试地点 本测试计划的的执行地点在本公司。 5 测试状态转换标准和再启动要求 测试状态转换标准和再启动要求见附录。 6 测试通过准则 测试通过准则参见附录。 7 应提供的测试文档 软件产品提交测试委托书 软件测试需求说明书 测试计划 测试用例设计与执行报告 测试用例设计评审记录 软件问题清单 测试分析报告 第 8 页 共 16 页 软件测试计划 文档编号: JBTEST-011-05- OPENOFFICE.ORG WRITER 03 8 测试资源需求 8.1 硬件需求 根据系统的环境要求，系统运行要求满足的最低硬件配置标准为： 系统环境需求 硬件环境 软件环境 服务器 PII 266
12、, 512M, 30G 以上机型 Win2000Server、 SQL Server2000 客户端 P166, 32M, 2G 以上机型 Win9x, Win2000 测试部现有 P 1.0GHZ，128M 内存微机两台，P 1.6GHZ、128 内存微 机三台，可以满足上述硬件配置的最低标准。 8.2 软件需求 在上表列出了系统运行要求的软件环境。 测试还需要文档处理软件 Microsoft Office2003 。8.3 网络需求 现有的 100M 局域网就可以满足测试需求。 8.4 人员需求 （1） 本测试需要测试人员 四名（一名测试负责人、三名测试人员） ； （2） 需要该系统开发人
13、员一名，负责对测试人员进行该系统的使用培训和 解释测试人员在测试中遇到的各种系统使用问题，同时负责对错误加 以确认。 8.5 其他需求 暂无。第 9 页 共 16 页 软件测试计划 文档编号: JBTEST-011-05- OPENOFFICE.ORG WRITER 03 9 人员、职责及培训要求 9.1 人员组成 奥组委网招聘系统的测试主要有以下人员参与： （1） 项目总负责人：于晓鹏 （2） 测试部负责人：于晓鹏 （3） 测试人员：刘绍华、小李阳、闫宇宇 （4） 开发一部负责人： 于晓鹏 （5） 开发二部开发人员：王志辉范孝龙等 9.2 人员分工与职责 人员分工与职责见附录。 9.3 培训
14、要求 由开发人员于晓鹏进行被测试系统的培训； 10 测试进度 测试进度计划表 起止日期 测试任务 6 月 28 日6 月 30 日 制定测试计划；（赵树斌） 熟悉被测试系统 7 月 1 日 搭建测试环境 7 月 1 日 进行测试前被测系统培训; （相松林） 7 月 1 日7 月 7 日 设计测试用例（赵瑞、赵磊、石海军） 7 月 8 日 测试用例评审 7 月 8 日7 月 10 日 执行测试用例（赵瑞、赵磊、石海军） 7 月 11 日 整理测试结果，出软件问题清单和测 试分析报告。 （赵树斌） 7 月 11 日-7 月 14 日 确认软件问题清单（相松林） 7 月 14 日 上报测试结果，第一
15、轮测试结束. 注：回归测试时间将在回归测试前进行详细制定。 第 10 页 共 16 页 软件测试计划 文档编号: JBTEST-011-05- OPENOFFICE.ORG WRITER 03 11 风险和应急 11.1 影响计划的潜在因素 在测试计划执行过程中，可能存在以下因素影响计划的按时完成： 测试人员对被测试产品的熟悉进度慢； 测试人员对测试工具的使用熟悉程序不够； 被测试产品存在重大错误，以致于测试无法继续，需要开发组进行额外的调 试和修改才能继续； 硬件、软件或网络环境出现故障等。 其中第一点是影响测试进度的最大的因素。 11.2 应急措施 如果上述潜在的可能事件发生，则通过适当加
16、班来保证计划的按时完成。如 果是由于被测试产品存在重大错误而严重影响测试进度，则考虑按照测试暂停标 准来暂停该测试。 12 测试的局限性 系统硬件配置存在不可预测的问题； 测试范围不能覆盖所有的可能情况； 测试时间的限制； 测试数据可能不全面； 测试工具自身的缺陷； 测试人员的失误。 13 计划的批准 本测试计划需测试部上级主管，谢冰总工程师批准。 14 参考文档 Openoffice.org writer 应用软件开发计划 ； Openoffice.org writer 应用软件需求规格说明书 ； 第 11 页 共 16 页 软件测试计划 文档编号: JBTEST-011-05- OPENO
17、FFICE.ORG WRITER 03 附录 软件错误与缺陷的定义 对于软件的错误和缺陷，目前主要依据其严重程度划分五个级别： 致命性错误 数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系 统或其他支撑系统崩溃、非正常关闭和非正常死机。 严重性错误 应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。系统的主要功 能不能正确实现或不完整。 一般性错误 规定的非主要功能没有实现或不完整、影响系统的运行； 设计不合理造成性 能低下。 告警性错误 不影响业务运行的功能问题。 建议 软件设计和功能实现等不完全合理之处提出建议。 第 12 页 共 16 页 软件测试计划 文档编号:
18、JBTEST-011-05- OPENOFFICE.ORG WRITER 03 附录 测试状态转换标准和再启动要求 “测试状态转换标准”用于开始、暂停或结束全部或部分与本计划有关 的测试项的测试活动的标准，这三种标准通常指启动标准、暂停标准和退出 标准。 “测试再启动要求”规定当测试重启动时必须重复的测试活动。 1 测试启动标准 测试部由公司管理层领导，具体由总工负责领导职能。各软件产品或项目 组提交测试需经过公司管理层书面指派。 公司所研发的各项面向市场的软件系统均需通过测试，才能对外发布，特 殊情况由公司管理层书面认可。 公司各项软件产品的开发计划书中均需要列出交付测试时间和测试时间， 以
19、及相应的修改和回归测试时间。测试部基于各开发计划制定相应的测试 计划，软件系统开发计划的变更必须变更相关的测试安排。 软件产品或项目提交测试部进行测试必须满足以下条件： 提交测试的软件系统必须是一个稳定的、待发布的版本，必须明确定 义系统版本号（即在系统各部分，系统本身、用户手册等方面均表明 该版本） ，如果本版本还没有开发完成或将进行大量的修改，不能提交 测试； 软件产品或项目在提交测试之前，本产品或项目组必须在内部进行自 己的单元测试和集成测试； 提交测试的软件系统必须是商品化包装的，并需附有： 用户手册、使用说明书（至少两者必备其一） ； 软件需求说明书； 其它最好还能够提交相关培训教材
20、、演示程序等电子文档。 软件系统开发组必须向测试部提供足够的培训和技术指导，以便测试 工作的顺利开展。在测试期间，开发组必须指定一名骨干开发人员， 帮助测试部解决相关问题。 若是对将发布的产品或将验收的项目进行测试，则必须给测试留出足 够的时间，以保证测试的质量。 提交测试的软件系统版本在测试期间保持稳定，即测试部只对初始提 交的系统版本进行测试，产品或项目组在测试期间的修改只在下一轮 测试中进行测试。特殊情况即提交版本无法继续测试，如安装程序 错误等问题下，可以在测试期间更换版本，但必须经过测试部的同 意。 回归测试是指不包含功能修改（含界面修改等）情况下测试部对原来 测出的问题进行的再次测
21、试。若引入新功能超过 10%，则认为是新的 系统测试，测试部必须进行全面测试。 2 测试暂停标准 当在测试过程中出现下列情况之一，则测试将暂停： 对于某类测试，测试环境变得（或者测试中发现）没有准备好，则暂停此 类测试； 对于提交测试的版本而言，如果其预计的功能修改量超过总功能的 10%， 第 13 页 共 16 页 软件测试计划 文档编号: JBTEST-011-05- OPENOFFICE.ORG WRITER 03 产品或项目组应即时通报测试部，并向公司相关负责人汇报，测试部有权 利向公司领导建议暂停或取消本轮测试，避免测试的无效劳动，避免造成 人力、财力等资源的浪费。 发现被测试系统有
22、大量错误或非常严重错误，以至于测试不能继续或继续 测试没有意义，则测试部应向总工提交报告，由总工决定是否暂停整个系 统测试。 当系统中某个功能模块有非常严重的错误，以致于不能完成预期的功能， 则暂停此功能模块的测试。 3 测试退出标准 当出现下列情况之一则退出此系统的本次测试： 测试计划中所有规定的测试内容和回归测试都已经运行完成。 根据上级主管对测试结果的意见，要求结束本次测试。 4 启动要求 当测试重新启动时，必须重复的主要测试活动有： 当是某功能模块的测试重新启动时，则此功能模块的所有测试用例都要重 新运行，并且调用此功能模块的其他功能模块的相关测试用例也要重新运 行。 当是整个系统的测
23、试重新启动时，则发生修改的部分和与之相关联的部分 的测试用例都要重新运行。 第 14 页 共 16 页 软件测试计划 文档编号: JBTEST-011-05- OPENOFFICE.ORG WRITER 03 附录 测试通过准则 1 测试项通过标准 测试项的通过标准目前定义为： 当此项的功能能够正确地完成，并且它的操作没有引起其他功能项或整个系 统的错误，则认为此项测试通过。 2 系统测试通过标准 系统测试的通过标准目前定义为： 对于每一类测试，当没有发现致命性错误和严重性错误、一般性错误数量小 于测试用例总数的 2%，告警性错误数量小于测试用例总数的 5%，则认为系统通 过本次测试，但要以测
24、试结果评审会的评审结果为最后标准。 第 15 页 共 16 页 软件测试计划 文档编号: JBTEST-011-05- OPENOFFICE.ORG WRITER 03 附录 人员分工与职责 1 项目总负责 负责审定和批准测试计划 ； 负责审定其他测试文档，包括： 测试用例设计及执行报告 、 软件问题 清单 、 测试分析报告 ； 负责测试状态转换（进入、暂停、退出）的最终审定和批准。 2 测试负责人 负责制定系统测试计划； 负责组织实施测试计划； 负责整个测试过程的管理工作； 负责对被测试产品的评价工作，并编写 测试分析报告 ； 负责与开发组交流测试结果和测试进展情况，并协调错误的修改和测试的
25、 矛盾； 负责对测试人员进行测试工具的培训； 负责组织被测试产品的培训； 负责的所有测试文档的管理。 3 测试人员 负责设计测试用例； 负责执行测试； 负责测试用例原始文档的保存和整理工作； 负责错误的分类和测试结果的统计工作； 负责编写测试用例设计与执行报告 。 4 开发人员 负责软件问题分析、确认； 进行被测试系统的培训； 填写软件问题清单 中相应的栏目。 5 测试用例的评审 测试用例评审会主要由测试部相关人员、开发部相关人员组成，必要时 包括质量部相关人员。如果是验收测试还要包括客户、最终用户的有关人员。 特殊情况下，还包括有公司相关领导及有关专家。 评审结果报项目总负责人批准。 6 测试结果的评审 测试结果评审会主要由测试组相关人员、开发组相关人员和质量部组成，如 果是验收测试还要包括客户、最终用户的有关人员。如果是重要的项目或产品发 布前的测试结果评审，还包括有公司相关领导及有关专家。 评审结果报项目总负责人批准。 第 16 页 共 16 页
