测试工作计划篇(1)

一、进一步提高对饮用水水源地安全保障工作重要性的认识

中央、省、市委高度重视饮用水水源地安全保障工作，“三个一号”文件和中央水利工作会议都对加强饮用水水源地保护提出了明确的要求，水利部已提出了重要饮用水水源地安全保障达标建设的总体目标、任务分工、时间安排和工作要求。各单位要切实提高认识，加强领导，落实责任，完善措施，加大投入，按照《计划》中的要求，认真组织开展重要饮用水水源地安全保障达标建设工作。

二、明确饮用水水源地安全保障达标建设总体目标与任务分工

（一）总体目标

坚持“在保护中开发，在开发中保护”的原则，对重要饮用水水源地水资源统一调度和优化配置，实行水资源开采利用调度令制度，严格控制开采水量和水位，确保在相应的保证率下，取水供水工程正常运行。自2011年开始，力争用5年时间，实现重要饮用水水源地“水量保证，水质合格，监控完备，制度健全”，供水保证率95%以上，水质达标率100%，初步建成饮用水水源地安全保障体系。

（二）任务分工

市水利与渔业局负责饮用水水源地安全保障达标建设工作的组织和指导，并检查、通报达标建设工作情况；市水资源管理办公室负责饮用水水源地安全保障达标建设的日常管理工作。各单位按照职责分工负责做好所管理的饮用水水源地的安全保障达标建设工作。

（三）工作安排

各单位在具体实施过程中，要按照《计划》要求制定自己的总体工作计划和2012年具体工作计划，并按照总体工作计划和年度工作计划编制年度建设工作方案，于每年2月底前上报前一年度的达标建设自评报告和下一年度的具体工作计划（含安全保障达标建设工作方案）。饮用水水源地安全保障达标建设工作所需经费可在水资源费中列支。

三、加强重要饮用水水源地安全保障达标建设的组织领导

测试工作计划篇(2)

1．1阶段划分

软件的生命周期主要由软件定义、软件开发和软件维护三部分组成。对于软件的各个不同阶段，尽可能地将软件的开发设计工作划分为具体的任务，并且使任务之间的关联性降低，尽可能地相互独立，从而可以有效地降低软件开发的复杂性，利于软件开发工作的组织管理，简化其工作流程。

1．2软件定义时期

对软件进行定义的主要目的是明确软件开发工作的总目标和该软件工程的可行性，分析软件系统需要实现的具体功能及采取何种手段实现该功能，并对整个系统所需要的成本和资源进行初步的估算，设计出工程的进度表。该阶段的工作主要由系统分析员完成，其主要工作有：

（1）问题描述和可行性分析。

进行此阶段分析时，主要由软件系统的需求方和软件开发方相互协商，明确软件系统的目标及可行性。问题描述主要是明确需要解决什么问题，对问题进行准确的定位，将问题的困难程度、性质、规模及目标等内容以书面的形式进行描述，并上报给上级主管部门。对软件需求方的使用者进行走访，对问题的理解进行扼要的描述，并将写好的报告反馈给用户，查看问题的描述是否准确，统一双方的意见，直至达到最终的协议。对于可行性的分析，当前对于该定义并没有给出明确的定义，其主要目的是描述该系统是否值得去做，是否有合适的技术能够解决此问题。在该阶段的可行性相对比较简短，只是从总体上进行分析，并不涉及具体的问题。

（2）分析需求。

明确软件系统可行之后，就需要对软件的功能进行详细的分析，即：为了达到使用者的要求，软件系统必须能够做什么和具备哪些具体的功能。另外，用户当进行软件操作时，必须有个清晰的认识，利用该软件系统要达到哪个具体的目标。开发人员和使用者必须进行详细的、准确的沟通，利用数据模型、数据字典、数据流图及算法设计出整个软件系统的逻辑模型。在该阶段，必须让用户参加，并给出具体的意见。

1．3软件开发时期

对于软件的开发，主要由计划、设计、编码和测试四部分组成，计划和设计是系统设计，编码和测试是系统实现。软件的开发由计划开始，完善的计划可以为软件的开发节省大量的时间和精力；设计是在计划的基础上，进一步的完善，给出问题的每一个步骤，是对整个系统功能的完整描述；系统设计完成后，开始进行编码操作，即对问题的具体实现，在编码中，要符合编写规范的要求，保证程序的易读易维护；没有一个软件是一次编写成功的，需要反复的测试才行，当前的测试从小到大，分别是单元测试、集成测试和验收测试，每次测试都要进行详细的记录，为以后软件的维护打好基础。

1．4软件维护时期

如果说前面的步骤是软件的实现过程，那么软件的维护时期就是软件的使用过程，软件的维护时期最长，由于软件随着使用环境的不断变化，软件的功能逐渐不能满足用户的需求和无法正常使用，为了延长软件的使用寿命，必须对软件进行维护处理。对于软件的维护活动主要分为4类，分别是：改正性维护、完善性维护、适应性维护和预防性维护。根据维护的情况不同，每个维护都要有详细的报告，通过报告来进行制定维护计划、修改软件设计、代码修改和测试等一系列的过程。

2测试自动化

开发人员设计好程序之后，无法直接投入使用，需要对代码进行测试，而软件测试是一个非常烦琐的过程。据统计，软件工程人员无法及时交付软件的主要原因是在规定的时间内没有对软件进行完整的测试和修订。21世纪，时间就是金钱，时间就是企业的生命，软件投入市场越早，就越有可能提前掌握先机，从而获得更高的利润。传统的软件测试方法无疑已经无法适应当前IT行业的发展，自动化测试软件可以使测试流水化，使得在较短的时间内充分对软件进行测试，现在，越来越多的软件企业选择测试自动化。

2．1测试自动化的定义

当前，对于测试自动化的定义比较多，但总结起来为：能够通过自动化的测试工具，针对软件测试，在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。从而达到减轻手工测试的劳动量，节省测试时间的目的。测试自动化在很多情况下都具有非常大的使用价值，例如在进行脚本测试时，可以产生许多重复调用的代码，在进行压力测试时，可重用很多次该脚本。如果利用手工测试方式进行压力测试，那么可能要花费相当长的时间，而且有时有些软件的缺陷还不能及时地发现，测试自动化保证了软件的稳定性和准确性。

2．2测试自动化的生命周期

进行自动化测试的工具也是一种软件，有其自身的生命周期，主要分为需求分析、计划、设计、实现、集成、维护和终结等过程。对于需求分析阶段，主要是对测试的用例进行详细的分析，明确测试用例的可行性，考察用例是否可以重复利用，对测试有何价值；在计划阶段，设计测试的进度和生成相关的文档；设计主要是描述自动化测试的模块，而描述是对这些模块的实现；对写好的软件模块进行集成，生成相应的具有特定功能的测试包；最后对软件的测试自动化工具进行维护，随着时间的推移，结束自动化测试生命周期。

3测试自动化软件的实现

3．1需求分析阶段

在该阶段，测试工程师和手机终端使用者要一起参加需求分析的讨论，分析测试的环境和过程，测试不同的环境下手机的使用情况。在进行手机通信测试的需求分析里，假定使用300个测试用例，分析其自动化测试的流程，形成书面的需求规格说明文档，并进行专门的评审，对测试用例进行审查。

3．2计划阶段

主要完成计划进度表的建立。例如整个手机终端测试需要五周时间完成，计划和设计需要半周，开发和执行需要三周，测试需要一周半。在规划测试计划时，在对每一次进行操作进行相关文档的说明，其中文档的完成工作也需要在计划时间以内，建立和维护一个测试环境文档是非常重要的。

3．3设计阶段

对于手机通信系统来说，软件的升级不会带着新的错误，即功能是不变的，由于测试的脚本具有共用性，模块化的设计是非常有必要的。在设计的过程中，要注重命名规则，以免发生混淆，使得模块发生混乱。

3．4实现和集成阶段

实现主要是在设计的基础上，进行编码，最终完成软件，每次代码更改运行要记录初始状态和运行后状态，及时进行备份。对软件进行集成分块测试，将生成的测试包提交给组装集成测试人员，对其进行评审和验证，详细记录其结果。

3．5维护和终结阶段

软件自动化测试生成后，要根据使用环境和用户的不同进行维护处理，并不断对其进行改进，这个过程可以通过问题跟踪工具来完成。随着新技术的来临，软件会越来越不适应企业的要求，就要对其进行终结，重新研发新的测试软件。

4结语

测试工作计划篇(3)

关键词：自动化测试；自动化测试管理平台

中图分类号：TN98 文献标识码：A文章编号：1009-3044(2011)28-7003-05

1 概述

目前中国大部分电信运营商都是以省为单位建设业务支撑系统（以下简称BSS系统），BSS系统包括客户关系管理子系统（简称CRM系统），计费账务子系统以及与其它系统的各种接口。省级运营商市场部门以及下属分公司市场部门为了市场的需要会不断提出各种业务需求，这就需要不断在BSS系统进行修改、增加功能，而BSS系统的支撑既要保障相关的功能修改或增加都必须是安全可靠，又要保障支撑的速度能跟上市场快速发展的需要。但由于软件开发往往采取模块化设计和增量集成的方式，测试版本的和系统上线时间非常有限，大量的变更问题需要验证，还需要进行大量回归测试，这些工作都存在大量的重复性劳动，容易让测试人产生疲惫感，要保证质量难度很大，有必要引入和运用自动化测试方法，将自动化测试和人工测试相结合，让测试人员更好的关注新功能或者改造的功能，做更有意义的测试，降低重复测试投入的成本，提前发现问题，保障系统稳定，提高用户感知。所以本文结合运营商的实际情况和自动化测试在业务支撑系统不断更新过程中的运用，对功能自动化测试在电信运营支撑系统中的引入和具体实施进行阐述。

2 电信行业自动化测试需求

作为运营商的核心生产系统之一，BSS系统的稳定性运行非常关键，其每次发生的重大故障都会给运营商带来严重的经济损失。而BSS系统的稳定运行，与应用开发/集成商提供的应用软件本身的稳定性密切相关。

BSS系统稳可以分为3个方面：系统功能稳定，不要动辄操作失败；系统运行效率好，实时性高；系统运行平稳，不要动辄重启服务器解决严重性能故障问题。而要做到这三方面，不对应用软件进行充分的测试，是无法保证的。

在BSS的实际建设和维护过程中，关于应用软件导致的系统不稳定（主机、存储等设备，数据库、中间件等系统软件导致的不稳定，本文不作讨论），可以大致归结为以下几种：

1）运营商的业务需求繁杂多变，开发周期短，难以进行充分的测试即被迫匆匆上线。每次系统升级前除了进行需求确认测试外，还应进行全量回归测试，以保障变更不会影响到其他功能，这在管理上是很难实现的！

2）新上线系统的BUG过多，功能不稳定。某个新系统上线后，才发现应用软件的BUG很多，营业员时不时的操作失败，而又不是每次都操作失败，让人难以琢磨该系统的“性格”。

3）新上线业务功能导致原有正常业务功能出错。这可以说是BSS系统维护中最常发生的不稳定问题，实际上就是新功能开发时，只对新功能进行了测试，而没有对原有功能的影响进行大量的测试，导致上线前没有发现问题，而仓促上线所致。

4）系统BUG修复后，因回归测试不全面，在上线时会产生新的BUG，得不偿失。

5）新上线业务越来越多，系统越来越慢，直至系统后台死机不处理。这属于典型的性能、压力的测试和分析不够，并进而对系统支撑业务能力估算不足所致

这5个问题，从另一个角度来看，可以理解为解决当前BSS应用软件测试问题的三个步骤。

首先必须加强上线前开发/集成商的软件测试，建立完整的测试流程和测试环境。

在此基础上，对每个新上线的业务功能，除了执行新功能本身的测试外，还通过建立丰富的测试用例库来确保执行严格的功能回归测试，才能确保新上线业务没有对原有正常业务功能产生不良影响;

同时，引入适当的测试工具软件。一方面，即使针对正在研发中的软件，由于在开发过程中不断引入的变更（发现错误进行的变更，业务需求变化引起的变更等），对于已经测试通过的功能，也需要在每次修改代码后进行回归测试，只有这样才能保证即使在代码不断修改的情况下，软件时相应的功能测试仍然是通过的。而这种回归测试的工作量非常之巨，以至于如果完全人工来做，是不可能实际做到的，自动化测试可以解决回归测试、重复测试的问题。这样才能解决以上问题中1、2、3和4；

最后，有了这些测试流程、测试环境、测试用例库，才可以进行严格的性能测试和分析，为新业务上线对系统荷载造成的影响进行科学客观的分析，从而准确地把握系统实际运行荷载的变化趋势，并进而尽早发现系统支撑能力的“临界点”。

因此，电信行业的业务运营支撑系统有必要启用自动化测试。

3 自动化测试的好处

自动化测试长久以来，一直是软件测试领域的热点，而今从事或者具有自动化测试技能的工程师更是就业市场非常需要的人才。这是因为自动化测试可以带来很多好处。

将精力投入更有意义的测试。自动化测试的引入会减轻重复的工作，使得测试人员有更多的时间去分析测试需求、设计详细的测试计划、测试用例、构建更复杂的测试。可以说这是自动化测试带给我们的最大好处之一。

回归测试，降低测试成本。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。

充分利用资源。可以在无人时定时执行自动化测试脚本，到时候直接看执行结果即可。人工测试和自动化测试相结合使用，可以在白天上班时间进行新功能的手工测试，原有功能的自动化测试可以在晚上或者周末执行，第二天就可以看到执行的结果。即避免了开发和测试之间的等待，又充分利用时间资源，提高测试效率。

测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。

测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

加大软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度也会增加。

公司实力的象征。自动化测试也从一定程度上体现出一个公司对测试质量的重视和实力，增强用户对软件的信任度。

自动化测试是对手工测试的一种补充，自动化测试不可能完全替代手工测试，因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。而仅仅依赖手工测试，则会让测试过于低效，尤其是回归测试的重复工作量对测试人员造成了巨大的压力。自动化测试的意义不是为了取代人在手工测试中的位置，而是将人从重复繁琐的工作中解放出来，做更有价值的测试工作。

4 自动化测试框架

前面章节介绍了电信行业业务支撑系统对于自动化测试的需求，下面来介绍自动化测试在某省BSS系统支撑过程中的实际应用。

4.1 自动化测试框架整体介绍

建立自动化测试框架就是为了把测试数据与测试用例的分离、测试数据与业务流程的分离、测试用例与业务流程的分离，让自动化测试更容易维护、用例的重复利用率更高，最后再和需求管理、开发进度管理统一起来，整个质量控制体系就更加完善。

自动化测试框架包括：自动化测试管理和自动化测试工具。自动化测试管理包配置管理、组件管理、测试用例管理、测试计划管理、数据管理，自动化测试报告管理。在本自动化测试框架中使用的是SilkTest测试工具和自主配套研发的自动化测试管理工具平台。运用在实际的电信行业中的框架如图1所示。

5 自动化测试工具选用

自动化测试的工具很多，当前主流的自动化测试工具有Mercury Interactive Corporation、IBM Rational、Compuware Corporation、Segue Software等公司的系列产品。产品简介如下，这里选用的是Borland Software SilkTest（原SegueSoftware产品）

SilkTest 是面向 Web 应用、 Java 应用和传统的 C/S 应用，进行自动化的功能测试和回归测试的工具。它提供了用于测试的创建、定制的工作流设置、测试计划和管理、直接的数据库访问及校验等功能，使用户能够高效率地进行软件自动化测试。为提高测试效率， SilkTest 提供多种手段来提高测试的自动化程度，包括：从测试脚本的生成、测试数据的组织、测试过程的自动化、测试结果的分析等方面来进行规范。

SilkTest的脚本语言采用面向对象的编程语言 4Test 来编写灵活的测试脚本，并且SilkTest 有较好的跨平台性。

6 自动化测试管理平台

为了能够让自动化测试入门更简单，维护更加简单容易。我们自主研发了自动化测试管理平台，是基于自动测试工具的自动测试统一工作平台。自动化测试管理平台为B/S结构的系统包括组件管理、测试用例管理、测试计划管理，测试报告管理等。自动化测试工具和自动测试统平台的交互，能够很好的维护自动测试脚本及工程文件，并能以更加直观方式对自动测试结果进行展示。统一的自动化测试平台有如下特点:

通过自动测试平台对象管理功能，可以显示对象的增量修改功能；

SilkTest工具编写的脚本，可以导入到自动测试平台，并通过可视化界面对脚本进行维护；

自动测试平台可以对脚本进行有效的管理，保证脚本的唯一性；

自动测试平台可以对SilkTest整个工程进行管理，方便整个工程的读取；

自动测试平台可以将测试结果文件以pdf文件的形式导出，便于对测试结果的阅读和分析。

6.1 组件管理

组件管理包括：对象导入、对象维护、对象导出。

对象获取。要管理对象，就要先获取取对象。对象获取和整理是编写用例的前提。整理好对象会对在平台上编写用例有很大帮助。也会对接手维护的人员有很大帮助。对象是通过SilkTest工具来获取的，获取对象有两种途径：Window Declarations（获得整个页面的对象）和Window Identifiers（获取单个对象的属性）。Window Declarations获取的对象，结果如图2所示。

对象导入。通过自动化测试平台的导入对象功能，将SilkTest获取的对象存储到数据库中，以便后期维护和部署。页面如图3所示。

对象导出。通过自动化测试平台导出对象文件以便部署到服务器上。页面如图4所示。

对象维护。对导入的对象进行修改或者添加新的元素，页面如图5所示。

6.2 自动化测试用例管理

自动化测试用例的管理包括：测试用例添加，测试用例维护，测试用例导出。

用例添加。需要填写用例名称、用例说明、期望结果和用例类型。操作页面如图6所示。

用例维护。添加用例完成后，在用例维护中将SilkTest中的脚本写成操作步骤。此时页面右边的树就是我们导入的对象，点击对象就可以添加操作步骤。补换卡业务的测试步骤截图如图7所示。

用例导出。将用导出为SilkTest可执行的脚本文件，以后需要调试该用例时，直接通过自动测试管理平台导出用例执行，直接部署到自动化测试机上。操作页面如图8所示。

6.3 数据管理

在编写测试用例的过程中，一定会涉及到数据的交互，例如测试用例的输入数据从哪里获得，如何对输出结果进行验证等。

通常有两种方法：数据写到脚本里面；将数据与脚本分离，存放到excel或数据库中。我们现在选择的是将脚本和数据分离的方式，这样做有如下好处：

1）便于脚本的维护；

2）便于一个脚本支持多个用例，当编写一个新用例时，只需去配置与该用例相关的数据即可；

3）利于扩展和组织测试计划。

6.4 测试计划管理

测试计划管理包括：计划新增、计划维护和计划生成。

计划新增。自动化测试管理平台上有测试计划管理功能，查询出用例并放到新计划中。同时系统还提供了对测试计划维护的功能。如图9。

计划维护。自动化测试管理平台上有测试计划维护功能，即修改已经存在的计划里面包含的用例，可增加或者删除，操作页面如图10所示。

计划生成。由测试计划生成功能，生成脚本、生成计划。即可部署到自动化测试主机上执行。如图11。

6.5 自动化定时执行

编写一个bat文件，定时执行即可，如图12。

6.6 自动化测试报告管理

结果数据的抽取、汇总与展示。在测试执行过程中，通过特定的数据采集组件以及事件触发，获得我们关心的中间结果数据，并且将数据全部入库，根据客户需求，展现一份客户能够看得懂的报告。避免了工具原有报告难理解的问题。同时，记录下来的中间数据可以很好的体现出每个步骤地详细信息和过程时间，这样可以提供一段时间内的横向和纵向的对比，为系统特别是生产系统上的性能渐变提供有力的监控和依据。

自动化测试平台从数据库中捞出测试结果进行处理，根据需要生成用户容易看懂的PDF格式的自动化测试报告，如图13，图14所示。

7 自动化测试流程

有了上面自动化测试管理平台的支撑，自动测试流程中编写测试脚本、执行自动化测试的开展就会更加顺利。

表1为自动化测试流程角色表。自动化测试流程如图15所示。

1）制定测试计划。测试经理要制定测试计划，明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求，并确保测试所需的人力、硬件、数据等资源都准备充分。制定好测试计划后，分派给QA；

2）分析测试需求。QA根据测试计划和需求说明书，分析测试需求，设计测试需求树，以便用例设计时，能够覆盖所有的需求点；

3）设计测试用例。QA通过分析测试需求，设计足够多能够覆盖所有需求点的测试用例，形成专门的测试用例文档。并不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例；

4）搭建测试环境。自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。包括被测系统的部署、测试硬件的调用、测试工具的安装和设置、网络环境的布置等等；

5）编写测试脚本。自动化测试人员在自动化测试管理平台的支持下，编写自动化测试用例步骤，通过自动化测试工具编辑脚本插入检查点和异常判定反馈语句，调试脚本；

6）执行自动测试。自动化测试人员测试测试计划，验证软件功能，执行回归测试、流程测试等，以替代重复性的手工测试工作；

7）分析测试结果。自动化测试人员根据执行结果，分析测试通过与没通过的情况，通过自动化测试平台生产用户容易读懂的自动化测试报告；

8）记录测试问题。QA在测试脚本执行完毕之后，即可查看测试工具的测试报告，然后将没有通过的地方提取出来，描述成BUG，反馈给开发人员；

9）跟踪测试BUG。QA将测试中发现的BUG记录到BUG管理工具中去，以便定期跟踪处理。开发人员修改后，需要对此问题执行回归测试，即重复执行一次该问题对应的脚本，通过则关闭，否则继续修改。如果问题（BUG）的修改方案与客户达成了一致，但与原来的需求有所偏离，那么回归测试前，还需对脚本进行必要的修改和调试。

8 系统软硬件环境

系统的软硬件基本要求如表2所示。

9 结束语

电信行业业务支撑系统随着电信业务的发展和计算机技术的日新月异，系统功能不断扩充和更新。每次需求变更，系统缺陷，都会给系统带来大大小小的频繁更新。在需求管理、测试流程管理、测试环境这些都具备的条件下，要满足运营商给开发商预留的项目工期越来越紧，对软件的质量要求越来越高，对开发商软件正式上线前尽量减少程序BUG这些要求，这就必须要提高软件测试的质量和效率，在手工测试的基础上引入自动化测试，建立完善的自动化测试管理平台，统一管理测试用例库，让自动化测试完成大量的回归测试和重复性测试，让测试人员将精力投入更有意义的测试，制定更加合理的测试计划、设计更完善的测试用例，使得测试覆盖率更高，发现更多的问题，最终保障BSS系统的质量、降低业务支撑系统给运营商带来的风险，也将对电信运营商的业务支持起到非常积极的作用。

参考文献：

[1] 科兹纳.项目管理：计划、进度和控制的系统方法[M].10版.杨爱华,译.北京:电子工业出版社,2010:19-102.

[2] 柳胜.软件自动化测试框架设计与实践[M].北京:人民邮电出版社,2009.

[3] 陈能技.软件自动化测试成功之道[M].北京:人民邮电出版社,2010.

[4] Paul C.Jorgensen. 软件测试[M].韩柯,杜旭涛,译.北京:机械工业出版社,2003.

[5] 胡贝蒂.软件质量和软件测试[M].马博,赵云龙,译注.北京:清华大学出版社,2003.

[6] 布莱克.软件测试实践[M].郭耀,译.北京:清华大学出版社,2008.

[7] 朱少民.轻轻松松自动化测试[M].北京:电子工业出版社,2009.

[8] 蔡为东.赢在测试[M].北京:电子工业出版社,2010.

[9] 温伯格.完美软件[M].宋锐,译.北京:电子工业出版社,2009.

[10] 惠特克.探索式软件测试[M].方敏,张胜,钟颂东,等,译注.北京:清华大学出版社,2010.

[11] 曹向志.软件测试项目实战[M].北京:电子工业出版社,2010.

[12] Dennis M.Ahern.CMMI精粹[M].3版.北京:清华大学出版社,2009.

测试工作计划篇(4)

关键词：软件测试；过程管理

中图分类号：TP311.5 文献标识码：A 文章编号：1007-9599 (2011) 22-0000-01

Analysis of Software Testing Process Work Request

Yuan Zhengjiang

(Jiangnan Institute of Mechanical and Electrical Engineering,Guiyang 550009,China)

Abstract:This paper divided software testing into requirements analysis,software testing planning,design and implementation,software testing and software testing summary execution phases,and the test process management requirements are described.

Keywords:Software test;Process management

一、前言

软件测试是软件质量保证的重要内容，随着软件规模的不断扩大，复杂程度的不断提高，测试质量更加难以度量。为促进软件测试质量，应规范软件测试过程管理。软件测试过程包括：软件测试需求分析、软件测试策划、软件测试设计和实现、软件测试执行和软件测试总结等。本文对各软件测试过程的工作要求进行了阐述。

二、软件测试需求分析

根据软件测试任务书、被测软件的需求规格说明和设计文档，对测试任务进行测试需求分析，分析的主要内容包括：

1.确定需要的测试类型及其测试要求。测试类型包括功能测试、性能测试、接口测试、安全性测试、人机交互界面测试、强度测试等；测试要求包括状态、接口、数据结构、设计约束等。2.确定测试类型中各测试项及其优先级。3.确定每个测试项的测试充分性要求。根据被测软件的重要性、测试项目和约束条件，确定每个测试项应覆盖的范围。4.确定每个测试项测试终止的要求，包括测试过程正常终止的条件和导致测试过程异常终止的可能情况。5.测试需求分析阶段的工作产品：软件测试需求规格说明文档。

三、软件测试策划

根据软件测评任务书、软件需求规格说明和设计文档、软件测试需求规格说明文档等进行测试策划，策划一般包括：

1.确定测试策略。2.确定测试需要的技术或方法，如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术。3.确定要受控制的测试工作产品，列出清单。4.确定用于测试的资源要求，包括软硬件设备、环境条件、人员数量和技能等要求。5.进行测试风险分析，如技术风险、人员风险、资源风险和进度风险等。6.根据软件测试任务书和被测软件的特点确定测试任务结束条件。7.确定被测软件的评价准则和方法。8.根据测试资源和测试项，确定进度。9.确定需采集的度量及采集要求。10.测试策划阶段的工作产品：软件测试计划文档。

四、测试设计和实现

根据测试需求规格说明和测试计划进行测试设计和实现，应完成如下工作：

1.按需求分解测试项。将需测试的测试项进行层次化的分解。2.说明最终分解后的每个测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等。3.设计测试用例；测试用例包括如下内容。（1）测试用例名称和用例标识；（2）测试用例追踪。说明测试所依据的内容来源，并跟踪到相应的测试项；（3）测试用例说明。简要描述测试的对象、目的和所采用的测试方法；（4）测试用例的初始化要求，包括硬件配置、软件配置、测试配置、参数设置等初始化要求；（5）测试用例的输入。包括：每个测试的名称、用途和具体内容及其性质；测试输入的来源，以及选择输入所使用的方法；测试输入是真实的还是模拟的；测试输入的时间顺序或事件顺序；（6）测试用例的期望结果；（7）测试用例的期望结果评估准则。评估准则用以判断测试用例执行产生的中间或最后结果是否正确；（8）实施测试用例的执行步骤；（9）测试用例的前提和约束，如特别限制、参数偏差或异常处理；（10）测试终止条件。说明测试用例的测试正常终止和异常终止的条件；4.确定测试用例的执行顺序；5.准备和验证所有的测试用数据。针对测试输入要求，设计测试用的数据；6.准备并获取测试资源，如测试环境所必须的软、硬件资源等；7.必要时，编写测试执行需要的程序，如开发部件测试的驱动模块、桩模块以及测试支持软件等；8.建立和校核测试环境，记录校核结果，说明测试环境的偏差；9.测试设计与实现阶段的工作产品：软件测试说明文档。

五、测试执行

按照测试计划和测试说明的内容和要求执行测试。测试执行的要求如下：

1.如实填写测试原始记录，当结果有量值要求时，应准确记录实际的量值；2.根据每个测试用例的期望测试结果、实际测试结果和评估准则，判定测试用例是否通过；3.当测试用例不通过时，应根据不同的缺陷类型，采取相应措施：对测试工作中得缺陷，进行记录并实施相应的变更；对被测软件的缺陷应记录到软件问题报告单中；4.当所有的测试用例都执行完毕后，根据测试的充分性要求和有关原始记录，分析测试工作是否充分，是否需要进行补充测试；5.在执行测试的过程中，可根据测试的进展情况补充测试用例，但应留下用例记录，并在执行测试后，变更测试说明；6.测试执行阶段的工作产品：测试记录、软件问题报告单。

六、测试总结

根据软件测试任务书、被测软件文档、测试过程文档等，对测试工作和被测软件进行分析和评价。测试总结的要求如下：

1.对测试工作进行分析和评价。总结测试是否符合过程管理要求，测试是否充分，是否满足用户要求等；2.对被测软件进行分析和评价。总结被测软件功能、性能、安全性、可靠性等是否满足要求，对软件缺陷影响进行描述，提出改进建议等；3.测试总结阶段的工作产品：软件测试报告。

七、结束语

只有把每个测试阶段应完成的工作做好了，才能保证最终的软件测试质量。软件测试组织都应制定适合自己的软件测试过程管理体系文件，确保过程管理规范，各阶段工作做到位。

参考文献：

[1]单锦辉,姜瑛,孙萍.软件测试研究进展[J].北京大学学报(自然科学版),2005,1

测试工作计划篇(5)

关键词：软件测试；工作流；H模型；工作流引擎

中图分类号：TP301 文献标识码：A 文章编号：16727800（2013）002002403

0 引言

软件测试过程用于指导软件测试的流程及安排测试活动的实施。测试过程的优劣会影响测试结果的准确和有效性。针对被测试软件的特点和测试目的，在实践中总结出了若干测试过程模型。软件测试模型是测试工作进行的依据，它描述了测试过程的主要活动及其相互关系等。为了提高模型的准确性和有效性，并能在测试的整个生命周期发挥作用，关键是合理划分模型中的各个阶段，及其实施的活动，并为这些活动制定合理的执行顺序。

1 常用软件测试过程模型

模型是一种沟通工具，测试过程模型能帮助项目中的测试人员明确目标和确认职责，良好的测试模型可以提高测试的效率。现有软件测试过程模型有很多，常用的主要有 V 模型、W模型等。

1.1 V模型

现有的模型中最有代表性的是V模型，20世纪80年代后期由Paul Rook提出。V模型反映了测试过程与分析、设计阶段之间的关系，认为测试的过程存在不同级别，并描述各个阶段之间的对应关系，软件测试过程V模型如图1所示。

V模型揭示了软件测试活动分层和分阶段的本质特性，但也存在一些问题，V模型把系统开发过程划分为具有固定边界的不同阶段，容易让人形成测试是开发之后的一个阶段。V模型没有明确测试设计，导致需求阶段隐藏的错误可能要到最后验收测试时才被发现，解决这样的错误要付出很大的代价，相比之下，Evolutif公司提出的W模型显得更科学些。

1.2 W模型

W模型是在V模型的基础上自然发展起来的，软件的错误具有传递性，在需求分析阶段产生的错误，会传递到设计和编码阶段，因此，测试工作应尽早进行。W模型强调，整个软件生命周期都应该伴随有测试活动，阶段性的开发活动完成后，就可以开始测试，也就是说，测试与开发可以同步进行。W模型还认为，测试的对象不仅是编码阶段的成果，需求、功能和设计同样要测试。软件测试过程W模型如图2所示。

V模型和W模型的共同点是，它们都认为软件开发过程是由需求、设计、编码组成等一系列串行的活动，适用于那些有明确需求的项目，开发和测试人员按照需求和设计开展工作。而在大部分的开发过程中，需求通常会产生变动，文档会时时更新，这样V模型和W模型就难以实施。

事实上，在大部分开发时间内，开发过程中的活动可以交叉进行，对应的测试活动也不应存在严格的次序，单元、集成和系统测试之间可以反复迭代。遵循这种思想，人们又提出了H模型。

2 软件测试过程H模型

人们利用新的设计思想，对软件测试的流程重新进行了更加系统的分析，随之提出一种适应性更强、应用更广泛的软件测试过程模型―H模型，如图3所示。

图3是软件开发过程中某个阶段上的一次测试活动流程。图中的流程适用于任意的开发过程，例如设计或编码过程。在某个时间点，其它过程的进行触发了测试就绪点，此时，只要准备活动完成了，测试活动就可以进行。

H模型充分体现了“尽早测试”、“全程测试”、“独立测试”、“迭代测试”的原则。

本模型对软件测试过程进行定义，将其划分为5个阶段，分别是测试需求、测试策划、测试设计、测试执行、测试总结。这种划分非常符合H模型的思想，测试需求、测试策划和测试设计对应 H 模型中的测试准备阶段，测试执行和测试总结对应 H 模型的测试执行阶段。五阶段模型的使用实例如图4所示。

主要组成部分如下：

（1）工作流执行服务组件（Workflow Enforcement Services）提供了一个或多个工作流引擎组成运行环境，可对过程进行实例化、解释及激活，同时可与外部进行数据交换。

（2）工作流引擎（Workflow Engine）是一个为工作流实例提供运行执行环境的软件服务。

（3）过程定义组件（Process Definition）主要用于描述、分析并记录业务过程。它输出一个能被工作流引擎解释的过程定义。

（4）工作流相关数据（Workflow Data）指与业务过程流相关的数据。系统使用这些数据确定工作流实例的状态转移，工作流相关数据既可以被工作流引擎使用，也可以被应用程序调用。

（5）工作流客户端应用组件（Workflow Client Application）是与活动相关的人员进行交互的软件实体。通常包括工作列表（Worklist）及工作列表管理器（Worklist Handler）两个主要组成部分。

（6）需要激活的应用程序（Invoked Applications）是指工作流执行服务在过程运行中调用处理应用数据的外部应用程序。

3.2 软件测试管理应用模型

根据目前通用的软件开发过程模式，考虑实际操作的可行性，以软件测试过程H模型为基础，结合工作流模式，建立如图6所示的软件测试管理应用模型。

此模型中，执行任务分配的工作流引擎是一个核心部件，测试过程的基本流程是：

（1）测试开始前建立测试用例库，保证能产生合格的测试用例，以供任务分配；

（2）任务分配触发工作流引擎，测试员开始进行测试并填写测试报告。若测试结果无误，该测试用例关闭；若有误，则产生相关缺陷；

（3）产生的缺陷经审核，如确是一个待修正的缺陷，则重新作为任务分配对象；

（4）任务分配再次触发工作流引擎，程序员对缺陷进行修正，确认完成后，进入回归测试流程，等待回归测试的缺陷又成为任务分配的对象；

（5）回归测试再次触发工作流引擎，流程回到（2），循环此过程直至缺陷“关闭”。

3.3 工作流引擎――任务分配

任务分配相当于工作流引擎。测试任务的分配依照计划（Plan）、执行（Do）、检查（Check）、调整（Adjust）的原则进行，在测试开始前要建立测试计划，明确各阶段要完成的任务，预估完成活动所需的时间和资源，从而进行人员安排和任务分配等。任务分配管理框架如图7所示。

参考文献：

＼[1＼] 胡玮.软件测试过程模型的改进与应用＼[D＼].杭州：浙江大学，2006.

＼[2＼] 赵瑞东.工作流与工作流管理技术综述＼[J＼].科技信息，2007（8）.

＼[3＼] 郑小军.基于工作流技术的软件测试流程定义与监控＼[J＼].计算机应用研究，2007（2） .

测试工作计划篇(6)

关键词：功能测试；用户测试；测试方法

中图分类号：TP393

软件测试是一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程，而不能证明软件完全没有缺陷。软件测试可分为黑盒测试和白盒测试，他们的主要区别在于是否关注于软件的内部结构。这两种测试方法从不同的角度出发，反映了软件的不同侧面，也适用于不同的开发环境。黑盒测试常用于功能测试，白盒测试常用于性能测试。由于黑盒测试不涉及内部设计和代码，通过较好的组织、计划与设计同样可以运用到软件的用户测试中。

1功能测试介绍

软件测试中的功能测试也叫黑盒测试，只测试应用程序的功能，而不考虑其内部结构或运作。测试者只需要输入特定的数据，得到预期的输出，且输入输出、操作过程均满足系统的功能需求即可。功能测试是数据驱动的测试，它不基于内部设计和代码，而是基于系统的需求和功能，针对软件界面和功能进行测试。

功能测试主要是为了发现以下几类错误：是否有不正确或遗漏了的功能；在接口上，输入能否正确地接受，能否输出正确的结果；是否有数据结构错误或外部信息（例如数据文件）访问错误；性能上是否能够满足要求；是否有初始化或终止性错误。为了节省时间和资源，提高测试效率，功能测试的测试方法主要有等价类划分、边值分析、因果图、错误推测等。采用这样的方法才能高效地发现软件中隐藏的错误和缺陷。

2功能测试在应用系统中的应用

当应用系统通过单元测试、集成测试、系统测试和验收测试后，系统基本满足了开发的要求，经验收后方可交付使用。

2.1测试的方法和应用

（1）单元测试的策略，是把白盒测试与黑盒测试结合使用。先根据黑盒测试的测试方法提出一组基本的测试用例，然后用白盒测试方法作为验证。先根据白盒测试方法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒测试进行补充。（2）集成测试及其后的测试阶段一般采用黑盒测试。用边界值分析法或等价类分析法提出基本的测试用例。用猜测法补充新的测试用例。如果系统中含有复合的输入条件，则应先使用因果图发，再按前两步进行。

2.2测试人员的组织

软件测试应贯穿于系统设计与开发的整个过程，因此在软件测试不同段也应组织相应的测试人员。在需求分析阶段：系统分析人员，系统设计人员，开发人员，测试人员和用户。在设计评审阶段：系统分析员，软件设计人员，测试负责人等。编码和单元测试阶段：系统开发人员进行内部的交叉测试。综合测试阶段：具有一定的分析、设计和开发经验的专业人员。

2.3软件测试的文档

测试分析报告，是对测试结果的分析和说明。经过测试后，证实了软件具有的能力，以及它的缺陷和限制，并给出评价的结论性意见，这些意见既是对软件质量的评价，又是决定该软件是否交付用户使用的依据。

3功能测试在用户测试中应用

3.1特点及目的

软件的用户测试是基于所开发的应用系统，根据具体的业务需求，对组织结构，工作流程，角色权限，业务数据和报表等方面，从用户的角度出发对系统进行再测试，是使软件更加成熟必须经历的过程成。对用户来说，在进行用户测试时，软件本身只是个黑匣子。开发者只需为用户提供满足需求的用户界面，对于软件的核心技术是保密的。对于用户只需关注输入了什么和得到了什么，不必了解系统的工作过程。因此，对于软件的用户测试和验收，用户的主要的测试方法就是功能测试即黑盒测试方法。软件用户测试目的同软件测试的目的是一致的，即测试软件的功能是否满足用户的需要。

3.2方法及步骤

用户面对着黑匣子进行测试，由于受制于软件原有的功能，无法按照自己的意愿随意订制软件功能，测试的目的和要求同测试人员有所不同。但软件测试的方法还是可以借鉴的。对于测试的过程设计、计划编制，样例设计、测试文档的编写、组织等都可以参照软件测试的原理来设计。对于人员的要求，同样可对照测试人员的标准。因此，从以上分析来看，结合软件用户测试的特点和目的，其过程至少包括：编制测试计划、设计测试样例、编写测试文档、组织测试人员。一个成功的软件用户测试要求具备强有力的组织，完备详尽的测试计划，完备的测试样例体系，周详的测试文档。在历年的某企业主要业务评估及管理系统的实施过程中，系统在交付使用前都会组织一定规模针对用户的客户化测试，下面结合该系统的实例来介绍如何实施软件的客户化测试。

（1）强有力的组织。组织成员应当包括：行政技术领导、系统开发及测试人员、关键用户。对于该业务评估及管理系统，该公司业务办公室的行政技术领导在软件用户测试中，统一管理和掌控测试工作，并在具体的工作节点把关。我公司作为系统实施方，在客户化测试中配备了开发人员和测试人员。这样就具备了即了解客户化的全过程，又熟悉业务流程。设计的测试用例结合了用户在实际工作中的业务特点和软件系统开发中的技术特点。在关键用户方面。根据该公司的组织结构，分为上级总公司及下属四家分公司共五个组。每组配备了负责相关业务三条线及经济评价的四名关键用户。关键用户是用户测试的重要成员，决定了测试工作是否成功。通过关键用户介绍工作流程及提供的数据，才能设计出与系统实际应用相符合的测试用例，也只有这样才能做到发现问题解决问题。当然我们的关键用户都是高素质的，具备一定的计算机方面的基础知识，保证了测试工作顺利进行。（2）测试计划。测试计划就是对测试的工作范围和具体的测试工作步骤进行规划。完备的测试计划，就是要计划的详细、可操作，对关键用户的测试工作能够起到指导的作用，这样用户测试工作才能顺利进行。在该业务系统的关键用户测试前，我们不但制订了完备详尽的测试计划，也设计了应对出现问题的解决方法，并从硬件、软件方面对测试工作进行了保障。（3）测试样例体系。测试样例设计的好坏决定了整个测试工作的成功与否。影响测试样例设计的因素很多，首先设计人员对系统的功能尽可能全面了解；其次设计人员对用户需求全面把握；第三设计满足测试需要能够到达测试目标的样例。另外测试样例应为一个完备的体系。体系有清晰的层次结构，与系统的功能结构相对应。这样使测试样例有条理，便于关键用户测试。在某企业主要业务评估及管理系统的关键用户测试中，测试用例按系统功能的体系结构设计，依据相关业务的三条线、系统管理、经济评价、ORGE、电子文档、领导查询等进行分类。每一类根据用户需求设计测试用例的功能点，例如：自动计算功能、提醒功能、审核方式一致、采用国家标准的参数单位、Excel导出功能等。（4）详细的测试文档。通过软件客户化测试，对关键用户的提出的调整问题及建议进行收集整理，如：界面设置、增加表格内项目等。并参照用户提出的对系统的整体印象，如：可提高系统性能进行服务器扩容，形成最终的测试文档。对发现的系统缺陷进行及时完善。

4结论

通过对软件功能测试和软件用户测试的分析与研究，二者的共同点在于都不需要考虑软件的内部逻辑结构，而只关注软件的外部，如软件界面和软件功能是否满足需求。因此在软件用户测试工作中，可以参照软件功能测试的方法和步骤，并结合软件用户测试的特点进行用户测试工作，使软件更好的满足用户的需要。目前某企业主要业务评估及管理系统的用户测试工作借鉴了软件测试的方法，组织实施的很成功。

参考文献：

[1]Patton R.软件测试[M].北京:机械工业出版社,2002.

[2]朱少民.软件测试方法和技术[M].北京:清华大学出版社,2005.

[3]周伟明.软件测试实践[M].北京:电子工业出版社,2008.

[4]袁玉宇.软件测试与质量保证[M].北京:北京邮电大学出版社,2008.

测试工作计划篇(7)

（Disaster Recovery Plan，灾难恢复计划）。

现实表明，传统的风险管理意识和经验已经不能应对信息化时代出现的新威胁和新挑战，企业需要更新的风险意识和风险管理知识，需要开发并综合应用各种新的计划、组织流程和降低风险的技术方案。在新的风险和威胁挑战的推动下，业务连续性管理计划（BCP，Business Continuity Plan）、危机管理计划（CMP，Crisis Management Plan）和灾难恢复计划（DRP）应运而生。

摩托罗拉公司在上个世纪后20年的全球化生产和商业活动中已经充分认识到业务连续性管理的重要性，从公司战略、政策、组织和战术流程等各个层面在全球建立、推广和执行业务连续性计划，危机管理计划和灾难恢复计划。公司已经建立了一整套符合相关法律法规要求的风险管理体系，并在全球供应链生产管理和市场营销管理活动中成功应用。

设立专业职能小组

首先，把风险管理提高到战略高度，公司《内部控制标准》中对BCP、CMP和DRP都作了明确的定义，以公司基本政策的形式做出清楚的管理层承诺。

公司要求在达到或超过100名员工的地区和办公运营场所必须遵照标准操作流程和指南建立并实施BCP和CMP管理，建立相应的危机管理队伍，选定代表联络人，这个人的职责包括：

负责本地的年度风险评估；

参照事业部制定的统一计划模板制定计划；

定期培训、评审、测试计划；

在危机发生时负责计划的启动、执行；

危机发生后，进行事后总结、评估、整改计划；

负责对上一级风险管理组织的汇报和协调。

公司在全球事业部组织层面上设立了相应的BCP、CMP专业职能部门，统一制定标准框架、参考计划流程、计划文档样板、关键任务模板，制定并执行长期性的培训计划，负责企业层面、跨部门地区的事务协调，管理企业级核心流程计划的测试，并负责可能造成企业级影响安全事件的监控及响应处置等。

公司在基本法《内部控制标准》中对信息系统控制要求作了明确定义，IT部门作为公司关键业务流程服务的提供者，必须和信息系统所支持的业务部门及业务系统所有人一起负责信息系统和数据中心的业务影响评估（BIA， Business Impact Analysis），制定、维护、测试和执行DRP计划。

IT部门在公司全球信息系统安全部门内建立了专业的职能小组，命名为企业柔性管理办公室（ERO，Enterprise Resiliency Office），负责IT DRP标准和框架的制定，指导IT部门DRP策略定义和DRP计划制定，指导信息系统DRP与核心业务流程BCP、 CMP的衔接与集成，并负责与管理BCP、CMP职能部门的组织和协调，向公司最高层领导报告存在的问题和改进建议。企业柔性管理办公室向公司首席信息安全官报告工作。

生命周期持续方案

作为上市公司，摩托罗拉需要满足业务经营所在国家和地区的各种法律和法规的监管要求，如萨班斯法案。其中很多法规都对IT系统的数据备份和信息系统的DRP管理有明确的规定。由此，公司面临严格的定期外部审计，必须能够通过相关系统性的审计检验和测试，并提供完整的证据，表明公司符合相关法律规定。

公司IT内部ERO部门在长期实践，并参考业界最佳经验的基础上，如BS/ISO 17799、BS 25999等，逐步形成了完整的DRP管理框架体系。针对IT应用系统和数据中心的DRP计划，在业务影响评估，DRP创建、维护、测试，关键定量管理指标的考校等方面都制定了系列政策、框架文件、技术指南、标准操作规程等，并融入生命周期持续改进循环内，整个生命周期如附图所示。

DRP战术流程标准化

为了便于培训、普及、推广和保证易用，公司ERO部门制定了大量DRP技术标准指南和计划文档模板，保证了DRP在编写、测试、实施和维护过程的一致性和标准化。

一、根据行业标准，在业务影响性分析报告模板中对风险可能造成的损失尽可能量化，从而能够为业务部门管理层提供具有统一标准衡量尺度的风险指示（见表1），方便管理层理解和平衡风险，并从投入产出的角度选择灾难恢复策略。

二、由于公司内部存在大量的IT系统，为了区分轻重缓急和保证合理分配公司IT资源，本着分而治之的原则，ERO部门制定了应用系统分级标准，根据系统业务影响分析报告中的系统恢复时间目标（Recovery Time Objective，RTO），把应用系统分为0～3级，并根据现有IT水平给出每类系统的灾难恢复策略的建议方案（见表2）。

三、根据IT应用系统分级，在灾难恢复计划框架中定义统一的系统DRP测试要求，测试种类分为：

基础测试：包括计划的评审，桌面演练，关注于计划本身的完整性和相关人员对恢复流程的熟悉程度，所有DR（数据恢复）分类为三级的IT系统必须每3年进行至少一次基础测试；

中级测试：灾难恢复计划的模拟演练，关注于计划操作的有效性，所有DR分类为二级的IT系统必须每2年至少进行一次中级测试。

高级测试Ⅰ：并行或迁移测试，关注于实际数据恢复的有效性，确认RTO（Recovery Time Objective）和RPO（Recovery Point Objective）是否在测试中成功达到，所有DR分类为一级或零级的IT系统必须每年至少进行一次高级测试Ⅰ。

高级测试Ⅱ：完全业务中断测试，关注于备份场所处理能力的有效性，确认RTO和RPO是否在测试中成功达到，所有DR分类为一级或零级的IT系统必须每年至少进行一次高级测试Ⅱ。

四、采用业界领先的专用灾难恢复计划管理系统LDRPS （Living Disaster Recovery Planning System），提供统一、可重用和可灵活自定义的DRP模板、关键任务流程样板和其他在灾难恢复计划管理寿命中期各种不同角色和人员需要使用的管理维护功能模块，相比与传统Office手工文档模板，能够帮助DRP的计划人员以更高效、更经济和人机界面更友好的方式创建、维护IT系统和数据中心的灾难恢复计划，极大地改善和提高IT人员和业务部门对灾难恢复计划工作支持的积极性。

通常一个完整的IT部门应用系统的DRP文件包含如下内容:

1）计划的综述；

2）灾难的职责和计划的启动流程；

3）各职能组成员组成及其承担的任务；

4）通信；

5）备份场所和恢复策略；

6）应用系统的关联性；

7）恢复流程描述；

8）计划的测试；

9）计划的日常维护；

10）软件清单；

11）硬件清单；

12）其他设备清单；

13）重要记录。