《项目(产品)系统测试计划清单.pdf》由会员分享，可在线阅读，更多相关《项目(产品)系统测试计划清单.pdf（19页珍藏版）》请在三一文库上搜索。
1、实用文案 文案大全 文档号：密级：内部 版本号：2.0 系统 系统测试计划 撰写： 审核： 测试中心 日期：年8 月 测试中心系统测试计划 测试中心- 2 - 系统测试计划 变更记录 变 更 章节号 及名称 变更内容描述变更人 变更 日期 变更 前版 本号 批准人 A 1.4 增加测试后需要提交的测试文档 M 4.2 修改测试工具名称及版本 M 全部更新目录及页眉页脚 注：变更分三种： A增加， M修改， D删除 测试中心系统测试计划 测试中心- 3 - 系统测试计划 目录 1 前言 4 1.1目的. 4 1.2术语定义 . 4 1.3测试参考文档 . 5 1.4测试提交文档 . 5 2测试进
2、度与工作量 . 6 3测试启停标准 . 7 4测试资源 . 8 4.1人力资源 . 8 4.2测试环境 . 8 4.3测试工具 . 9 5测试策略 . 9 5.1功能测试 . 10 5.2数据和数据库完整性测试. 10 5.3用户界面测试 . 11 5.4安全性和访问控制测试 . 12 5.5性能测试 . 13 5.6故障转移和恢复测试 . 13 5.7回归测试 . 15 5.8安装测试 . 16 6测试风险分析及优先级 . 17 6.1测试风险 . 17 6.2功能模块测试优先级 . 18 测试中心系统测试计划 测试中心- 4 - 系统测试计划 1 前言 项目名称： 系统 V2.0，以下简称
3、 系统 系统V2.0 主要包括 系统服务器、 系统Web 服务器， 是一种无客户端的 纯 Web 模式交流平台，适合广域网上提供客户服务和咨询服务办公模式。 系统是为了 支持 M2M 网站系统的在线客服功能，实现M2M 网站访客与网站管理员进行在线交流。 同时 系统也是网上交互平台，实现即时交流、咨询和服务等。实现了网上即时客 服功能， 实现了企业产品的售前、售后服务功能， 由原来电话咨询服务转为网上在线咨询和 服务模式，为企业节省了服务费用，同时也为用户咨询和服务带来方便。 1.1 目的 本测试计划的编写目的在于使测试人员更好地执行测试工作，它说明了测试工作的各项 要求和性能指标， 明确测试
4、任务， 阐述实用范围及背景，提供维护人员解决问题所需的条件， 形成本系统的质量记录，为以后工作提供参考资料。 本测试报告的预期读者是 系统即时办公系统的软件开发人员、项目管理人员、研 发管理人员、测试经理、测试人员、维护人员。 1.2 术语定义 XMPP 协议： XMPP （Extensible Messageing and Presence Protocol ：可扩展信息与存在 协议）是目前主流的四种IM （Instant Messaging，即时信息）协议之一，其他三种分别为： 即时信息和空间协议(IMPP) 、空间和即时信息协议(PRIM) 、会话启动协议(SIP)。在这四种 协议中，
5、XMPP 是最灵活的。 XMPP 是一种基于XML 的协议，它继承了在XML环境中灵 活的发展性。因此，基于XMPP 的应用具有超强的可扩展性。经过扩展以后的XMPP 可以 通过发送扩展的信息来处理用户的需求，以及在XMPP 的顶端建立如内容发布系统和基于 地址的服务等应用程序。而且， XMPP 包含了针对服务器端的软件协议，使之能与另一个进 行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。 测试中心系统测试计划 测试中心- 5 - 系统测试计划 1.3 测试参考文档 下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性： 表 1-1 测试参考文档 文档已创建或可用
6、 已被接收或 已经过复审 作者或来源备注 系统即时办公系统需求规格说 明书 可用已被接收 系统Express V2.0 开发计划可用已被接收 1.4 测试提交文档 系统V2.0 系统结题验收测试报告 系统V2.0 质量分析报告 系统V2.0 性能测试报告 系统V2.0 问题报告 系统V2.0 系统测试用例 系统V2.0 系统测试报告 系统V2.0 系统测试分析报告 系统V2.0 性能测试计划 系统V2.0 系统测试计划 测试中心系统测试计划 测试中心- 6 - 系统测试计划 2 测试进度与工作量 表 2-1 测试进度与工作量估计表 测试活动计划开始日期计划结束日期工作量估计工作成果 测试准备
7、-7-25 -7-31 5 个工作日测试计划、测试用例 功能测试 -8-1 -8-8 6 个工作日功能测试总结 回归测试 -8-11 -8-13 3 个工作日测试记录及BUG 提交 其它类型测试 -8-14 -8-15 2 个工作日测试记录及BUG 提交 性能测试 -8-18 -8-23 5 个工作日性能测试报告 安装测试 -8-24 -8-26 2 个工作日提交安装程序 其他 -8-27 -9-02 4 个工作日 测试分析报告编写 相关结题文档 其它类型测试包括：数据库和数据完整性能测试、安全性和访问控制测试、故障转移和 恢复测试、配置测试。 测试中心系统测试计划 测试中心- 7 - 系统测
8、试计划 3 测试启停标准 表 3-1 系统测试开始、停止标准表 测试阶段开始标准停止标准 系统测试 模块的单元测试结 束，达到单元测试 停止标准。 （1） 按照系统测试计划，完成了系统测试。 （2） 达到了确认准则中关于系统测试所规定的覆 盖率（达到100%）的要求。 （3） 系统满足产品需求规格说明书的要求。 （4） 缺陷状态为closed 或 later 状态。 （5） 在系统测试中发现的错误已经得到修改，各级 缺陷修复率达到标准。 （6） 系统测试的缺陷密度（个 /KLOC ）需要符合组 织级质量目标中要求并达到项目控制范围。 测试中心系统测试计划 测试中心- 8 - 系统测试计划 4
9、测试资源 4.1 人力资源 下表列出了此项目的人员配备计划。 表 4-1 测试人员需求表 角色所推荐的最少资源具体职责说明 功能测试员2 人 撰写测试计划（总体） 、 撰写测试小组工作规范、 设计 TD 库结构、 检查组内工作、 撰写测试分析报告、 分析测试需求、 设计测试用例、 执行测试工作、 撰写测试记录、 撰写测试总结 性能测试员1 人 撰写性能测试分析报告、 执行性能测试工作、 撰写性能测试记录、 撰写性能测试总结 4.2 测试环境 表 4-2 测试环境说明表 软件环境（相关软件、操作系统等） 服务器端： 操作系统：Windows XP SP2 mysql5,Tomcat5.5.25
10、，JDK1.6.03 版本 测试中心系统测试计划 测试中心- 9 - 系统测试计划 客户端： 操作系统：Windows XP SP2 浏览器：MicroSoft IE6.0 硬件环境（网络、设备等） 服务器配置： PC 机配置： Intel(R) Pentium(R) 4 CPU 1.60GHz ，1.00GB 内存 客户端配置： PC 机配置： Intel(R) Pentium(R) 4 CPU 1.60GHz ，1.00GB 内存 网络环境 采用 10/100M 办公网 4.3 测试工具 下表列出了测试使用的工具。 表 4-3 测试工具使用表 用途工具生产厂商 /自产版本 BUG 管理Te
11、stDirector8.0 Mercury Interactive 8.0 文档书写Officer 2003/2007 Microsoft 2007 配置管理工具TortoiseSVN 开源1.3.5 测试管理工具TestDirector8.0 Mercury Interactive 8.0 自动化测试工具LoadRunner8.0 HP 8.0 开发 IDE Eclipse3.2 免费3.2 5 测试策略 测试策略提供了对测试对象进行测试的推荐方法。对于每种测试，都应提供测试说明， 测试中心系统测试计划 测试中心- 10 - 系统测试计划 并解释其实施的原因。制定测试策略时所考虑的主要事项有
12、：将要使用的技术以及判断测试 何时完成的标准。下面列出了在进行每项测试时需考虑的事项，除此之外， 测试还只应在安 全的环境中使用已知的、有控制的数据库来执行。 5.1 功能测试 对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试 需求。 这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否 恰当。此类测试基于黑盒技术，该技术通过图形用户界面（GUI ）与应用程序进行交互，并 对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列 出了推荐使用的测试概要： 表 5-1 功能测试策略 测试目标确保测试的功能正常 测试范围 系统
13、所有模块 技术 利用有效的和无效的数据来执行各个用例、用例流或 功能，以核实以下内容： 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用。 开始标准模块功能完成，提交测试 完成标准所有缺陷已经被修复 测试重点和优先级 需考虑的特殊事项 确定或说明那些将对功能测试的实施和执行造成影 响的事项或因素（内部的或外部的） 5.2 数据和数据库完整性测试 要在 系统中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子 系统时， 不应将测试对象的用户界面用作数据的接口。对于数据库管理系统还需要进行深入 的研究，以确定可以支持以下测试的
14、工具和技术。 测试中心系统测试计划 测试中心- 11 - 系统测试计划 表 5-2 数据和数据库完整性测试策略 测试目标确保数据访问方法和进程正常运行、确保数据一致性 测试范围 系统所有功能模块 技术 检查数据库，确保数据已按预期的方式填充，并且所 有的数据库事件已正常发生；或者检查所返回的数据，确 保正当的理由检索到了正确的数据 开始标准数据库可正常运行、测试版本已经提交测试 完成标准 所有的数据库访问方法和进程都按照设计的方式运 行，数据没有遭到损坏。 所计划的测试已全部执行。发现的缺陷已全部解决。 测试重点和优先级 需考虑的特殊事项确保数据的一致性和完整性 5.3 用户界面测试 用户界面
15、测试用于核实用户与软件之间的交互。用户界面测试的目标是确保用户界面会 通过测试对象的功能来为用户提供相应的访问或浏览功能。用户界面测试还可确保界面中的 对象按照预期的方式运行，并符合公司或行业的标准。 表 5-3 用户界面测试策略 测试目标 通过测试进行的浏览可正确反映业务的功能和需求， 这种浏览包括窗口与窗口之间、字段与字段之间的浏览， 以及各种访问方法（Tab 键、鼠标移动和快捷键）的使用。 窗口的对象和特征（例如，菜单、大小、位置、状态 和中心）都符合标准。 测试范围 系统所有功能模块 技术 为每个窗口创建或修改测试，以核实各个应用程序窗 口和对象都可正确地进行浏览，并处于正常的对象状态
16、。 开始标准测试版本已经提交测试 测试中心系统测试计划 测试中心- 12 - 系统测试计划 完成标准 成功地核实出各个窗口都与基准版本保持一致，或符 合可接受标准。 测试重点和优先级 需考虑的特殊事项并不是所有定制或第三方对象的特征都可访问。 5.4 安全性和访问控制测试 安全性和访问控制测试侧重于安全性的两个关键方面： 应用程序级别的安全性，包括对数据或业务功能的访问。 系统级别的安全性，包括对系统的登录或远程访问。 应用程序级别的安全性可确保：在预期的安全性情况下只能访问有限的数据。 表 5-4 安全性和访问控制测试策略 测试目标应用程序级别的数据安全性 测试范围 系统安全 技术 应用程序
17、级别的安全性： 确定并列出各用户类型及其被授权访问的功能或数据。 为各用户类型创建测试，并通过创建各用户类型所特有 的事务来核实其权限。 开始标准 系统模块提交 完成标准 各种已知的Actor 类型都可访问相应的功能或数据， 而且所有事务都按照预期的方式运行，并在先前的应用程 序功能测试中运行了所有的事务。 测试重点和优先级 需考虑的特殊事项 必须与相应的网络或系统管理员一直对系统访问权 进行检查和讨论。由于此测试可能是网络管理可系统管理 的职能，可能会不需要执行此测试。 测试中心系统测试计划 测试中心- 13 - 系统测试计划 5.5 性能测试 性能测试对响应时间、事务处理速率和其他与时间相
18、关的需求进行评测和评估。性能评 测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行 为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。 注：以下所说的事务是指“ 逻辑业务事务 ” 。这种事务被定义为将由系统的某个Actor 通 过使用测试对象来执行的特定用例，添加或修改给定的合同。 表 5-5 性能评测策略 测试目标 核实所指定的事务或业务功能在以下情况下的性能 行为： 正常的预期工作量 预期的最繁重工作量 测试范围队列消息、主题消息(并发访问 ) 技术使用代码驱动桩的方式 开始标准功能测试完成 完成标准性能达到需求，无致命性能障碍 测试重点和优先级
19、需考虑的特殊事项需要考虑到数据量的大小以及大数据量 5.6 故障转移和恢复测试 故障转移和恢复测试可确保测试对象能成功完成转移，并能从导致意外数据损失或数据 完整性破坏的各种硬件、软件和网络故障中恢复。 故障转移测试可确保：对于必须持续运行的系统，一旦发生故障， 备用系统就将不失时 机地 “ 顶替 ” 发生故障的系统，以避免丢失任何数据或事务。 恢复测试是一种对抗性的测试过程。在这种测试中， 将把应用程序或系统置于极端的条 件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出（ I/O ）故障或无效的 数据库指针和关键字） 。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或
20、 测试中心系统测试计划 测试中心- 14 - 系统测试计划 系统和数据已得到了正确的恢复。 表 5-6 故障转移和恢复测试策略 测试目标 确保恢复进程（手工或自动）将数据库、应用程序和 系统正确地恢复到预期的已知状态。 测试范围 系统全部模块 技术 使用为功能和业务周期创建的测试来创建一系列的 事务。达到预期的测试起点后，分别执行或模拟以下操作： 客户机断电：关闭PC 机的电源。 服务器断电：模拟或启动服务器的断电过程。 通过网络服务器产生的中断：断开通信线路的连接或关 闭网络服务器或路由器的电源。 一旦实现了上述情况（或模拟情况），就应该执行其 他事务。而且一旦达到第二个测试点状态，就应调用
21、恢复 过程。 在测试不完整的周期时，所使用的技术与上述技术相 同，只不过应异常终止或提前终止数据库进程本身。 开始标准 系统功能测试已经结束 完成标准 在所有上述情况中，应用程序、数据库和系统应该在 恢复过程完成时立即返回到一个已知的预期状态。 此状态包括仅限于已知损坏的字段、指针或关键字范 围内的数据损坏，以及表明进程或事务因中断面未被完成 的报表。 测试重点和优先级 需考虑的特殊事项 恢复测试会给其他操作带来许多的麻烦。断开缆线连 接的方法（模拟断电或通信中断）可能并不可取或不可行。 所以，可能会需要采用其他方法，例如诊断性软件工具。 这些测试应该在工作时间之外或在一台独立的计算 机上运行
22、。 测试中心系统测试计划 测试中心- 15 - 系统测试计划 5.7 回归测试 回归测试指在测试或其他活动中发现的缺陷经过修改后重新测试。目的是验证软件缺陷 得到了正确的修复，同时对系统的变更没有影响以前的功能。回归测试作为软件生命周期的 一个组成部分， 在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进 行多次回归测试。 当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些 错误的修改； 而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在 表现， 而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未 被修改的部分
23、产生新的问题，使本来工作正常的功能产生错误。同样， 在有新代码加入软件 的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。 因此， 每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到 了预期的目的，检查修改是否损害了原有的正常功能。同时， 还需要补充新的测试用例来测 试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。 回归测试策略分为完全重复性测试和选择性重复测试。选择性重复测试包括：覆盖修改 法、周边影响法、指标达成法。 表 5-7 回归测试策略 测试目标 检验已经被发现的缺陷有没有被正确的修改和修改 过程中有没有引发新
24、的缺陷。 测试范围 系统所有功能模块 技术 手工开发脚本或开发自动脚本，以验证新版本的缺陷 已经被正确修复并且没有造成新的缺陷。 技术策略使用选择性重复测试方法进行。 开始标准提交修改后的版本 完成标准 系统所有 Bug 已经修复没有新的Bug 产生。 测试重点和优先级 需考虑的特殊事项 测试中心系统测试计划 测试中心- 16 - 系统测试计划 5.8 安装测试 安装测试有两个目的： 第一个目的是确保该软件在正常或异常情况下都能进行安装，例如，进行首次、升级、 完整的或自定义的安装。异常情况包括磁盘空间不足、缺少目录创建权限等。 第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为
25、功能测试制定 的测试。 表 5-8 安装测试策略 测试目标 核实在以下情况下，测试对象可正确地安装到各种所 需的硬件配置中： 首次安装：以前从未安装过 系统的新计算机 更新安装：以前安装过相同版本的* 系统的计算机 以前安装过 系统较早版本的计算机 测试范围系统的安装程序 技术 启动或执行安装。 使用预先确定的功能测试脚本子集来运行事务。 开始标准 系统的完整安装包已经提交 完成标准 系统事务成功执行，没有出现任何故障。 测试重点和优先级 需考虑的特殊事项 应该选择 系统的哪些事务才能准确地测试出 系统应用程序已经成功安装，而且没有遗漏主要的软件构 件。 测试中心系统测试计划 测试中心- 17
26、 - 系统测试计划 6 测试风险分析及优先级 6.1 测试风险 1、交付日期 由于开发人员未能在计划规定的日期内交付被测试对象，可能会导致测试计划时间的 滞后，影响到整个项目进度。或者由于交付日期的滞后，造成测试时间的缩减，影响测试 工作质量。 规避方法： 开发人员尽可能的在计划规定的日期内交付被测对象。如果交付的被测试 对象确实需要延后，应该得到项目组长、开发经理、QA的认可，并且尽可能的保证测试 工程时间。 2、测试需求 在开发人员提供的测试需求中，可能会存在需求点的遗漏、需求指标的估算不足或者 过于的远离实际，项目过程中测试需求的变更等，这些可能会造成测试的不充分或者测试 时间、资源的浪
27、费。 规避方法： 在将测试需求提交给开发人员前，应该确保需求中各项指标数据与实际测 试过程中误差尽可能的小。最好不要随意的进行需求的变更，否则造成测试过程管理上的 混乱。如果需要对测试需求进行变更，应该得到项目组长、开发经理、QA的认可。 3、测试范围 由于开发过程中模块的开发范围优先级别的不一致，造成测试不能连贯性，这样会对 测试人员在进行测试用例编写过程中，不能很好的将前后模块完成的对应起来，导致测试 的范围缺乏必要的广度，造成测试的不充分。 规避方法：在测试人员指定好测试范围后，开发人员能够提供必要的支持，对测试人 员划定的测试范围进行评审和建议。 4、人员的能力 由于开发过程中，项目需
28、要利用到很多的不同的技术做支撑。而测试人员不可能去对 每一门技术做到如数家珍，面面俱到，这就涉及到一个测试工作的深度问题。由于测试人 员自身的业务技术知识不够也会影响到测试质量。 测试中心系统测试计划 测试中心- 18 - 系统测试计划 规避办法： 在测试之前开发人员能够将相关技术做一些简单讲解，提供一些相关技术 资料，并对可能会出现的问题，能给出一些指导性的建议。测试人员尽可能的有目的、有 计划的、有针对的尽快提高自己的业务素质。 5、测试环境 在测试过程中，由于网络故障、计算机硬件故障、或者其他软硬件支持的问题对测试 进度造成影响。 规避办法： 在测试之前做好这些相关准备工作，并且要考虑到
29、如果发生了如何尽快的 解决，以不致影响到测试进度。 6、劣质组件 开发人员提供的被测对象，存在着很多显而易见的BUG 。由于这些劣质组件的存在， 会给测试工作带来了很多的资源浪费。 规避方法：开发人员在提交被测对象之前，能够进行必要的自测。 7、测试工具 在进行一些性能测试或者其他利用到测试工具的测试过程中，由于测试工具自身的原 因造成测试偏差，影响测试结果。 规避方法：在测试过程中，进行人为的自检，以发现自动化工具造成的偏差，把偏差 值控制在一个很小的范围之内，不能说测试工具得出的结果是100正确的。 6.2 功能模块测试优先级 表 6-1 测试范围的功能点模块划分 模块 /功能点功能描述备
30、注优先级 客 户 端 随机为访客分 配会话名称 访客名称予以区别，避免客服人员在同 时应对多个咨询时，弄乱客户次序 新功能高 发送方式在对话窗口设置了发送快捷键新功能高 发送附件 客服端的附件发送功能，可直接为客户 提供资料帮助，也方便客户直接提供问 题图片，更加直观 旧功能低 接收信息客服能准确接收到访客的信息，旧功能低 测试中心系统测试计划 测试中心- 19 - 系统测试计划 客户能准确接收到客服的回话， 客服之间会话准确没有错乱 客服列表 客户能正确看到客服列表和信息 客服能准确看到客服列表的信息 旧功能低 访客离线提示 访客离线后，在客服会话端提示访客的 离线信息，并限制客服对离线的访客进 行回复 新功能高 客服分组 允许一个客服同时属于几个不同的组， 并且能正确显示个人信息和上线、下线 的信息 新功能高 客服列表刷新 客服上线、下线后，客服和客户看到的 客服列表都能即时显示当前状态 新功能高 管 理 端 保存会话记录后台保存会话记录新功能高 删除会话记录对保存的会话记录进行删除新功能高 查询用户根据用户名称、昵称模糊查询旧功能低 修改用户信息对用户的信息进行更新旧功能低 查看在线用户查看当前在线用户的名单新功能高 清理在线用户可以断开在线用户的连接，使其下线新功能高