测试工作计划篇（1）

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

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

（一）总体目标

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

（二）任务分工

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

（三）工作安排

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

测试工作计划篇（2）

测试计划是在需求整理完成，和开发计划一起制定的一份计划书，它从属于项目计划中其中的一个计划。

2：测试计划都应该从那几个方面去描述？

测试计划本身就是一个测试工作的指挥棒，他从宏观的角度来阐述我们将来需要做什么事情，具体怎么做不在计划

中详细的阐述，例如，作为一个软件工程师，最后阶段是查毒和安装，具体怎么查毒，那个工具我们都不去关心，只是将

来必须有这个活动。

我认为测试计划应该描述几个事情：

（1）：此项目成员介绍（负责人，设计工程师，测试员）

（3）：此项目的目的或者说需要实现的功能

（4）：用什么工具管理问题

（5）：问题怎么流转

（6）：在整个测试阶段都应该出那些产品（例如，测试案例，测试报告，问题报告）

（7）：都进行了那些测试（安装，查毒，功能）

（8）：在测试的过程中使用的工具

（9）：测试过程中采用的方法（自动或者手动）

（10）：测试中预期风险

（11）：产品的提交标准（产品需要保证到什么程度，三方有一个共同的协议） 3：怎样去监督测试计划的执行情况？

测试工作计划篇（3）

一、前言

建筑幕墙测试作为对建筑幕墙设计施工方案的验证，是必须在建筑幕墙现场施工之前完成的一项重要工作。按照国内建筑幕墙工程验收的规定，依据中国国家标准（GB）进行四项物理性能测试的周期一般为3～5天。随着ASTM、AAMA等测试标准在幕墙测试项目中越来越多的应用，在测试试件的选取、试件的制作、测试内容及过程均较以往有较大的改变，各个环节的复杂性、不可预见性明显提高，项目周期大大增加，甚至达到近60天，这对于生产效率和设备利用率有直接的影响。通过引入科学的管理办法，来有效控制项目进度，节省时间，提高生产效率，以期待创造更高的经济价值。本文主要解决项目计划环节的问题，实施和控制环节的问题暂不讨论。希望本文能够为建筑幕墙测试机构项目管理工作提供参考。

二、项目进度计划的编制

1. 项目描述

首先要编制项目进度计划。对建筑幕墙测试项目进行项目描述，主要内容包括项目名称、项目目标、项目实施主体、交付物、项目工期、工作描述、工作规范、重大里程碑等。

2. 项目工作分解（WBS）

采用项目工作分解结构技术（WBS），将建筑幕墙测试项目分解成为若干明确的具有可交付成果的子项目，这些子项目是用于完成项目工作的元素，使项目更易于识别和管理。如，建筑幕墙测试项目工作分解结构见表1。

在此分解结构中，“预测试”、“正式测试”、“报告编制”等还可以继续分解为更小的子项目，每个子项目的可交付成果更加明确。

3. 项目分工

根据各子项目分工编制工作责任分配表，明确并且使项目成员了解各相关方以及项目成员在本项目中的责任。

4. 子项目工作时间的估算

根据建筑幕墙测试项目工作分解结构，依照项目活动之间的逻辑关系决定工作的先后顺序，运用时间估算方法估算建筑幕墙测试项目中各子项目的工作时间。

1）专家判断的应用：如，在测试项目中，支座定位及安装、建筑幕墙单元板块安装等工作都是由建筑幕墙施工单位完成。施工单位具有丰富施工经验的管理人员对支座定位及安装、建筑幕墙单元板块安装等工作的施工时间估算应该是比较准确的。当然，这也是在现有人员配备的基础上得出的时间估算。如果需要赶工，在某些情况下增加施工人员是可以达到目的的。

2）类比估算的应用：建筑幕墙预测试和测试过程是一个根据已拟定的程序，顺序进行的一系列工作的集合。其主要依据测试标准的要求。在各标准中，对测试的时间或步骤都有相关要求，测试人员可以通过标准所述和以往的经验，基本上可以估算出较为准确的测试所需时间。

3）三个时间估算法的应用：由于建筑幕墙形式多样、千差万别，每一个建筑幕墙测试样品都是不同的，因此对于测试箱体改造（模拟主体结构的施工）工作每次都不同，复杂程度不同、工作量大小不同、精度要求不同等等。另外，如正式测试过程中，可能有许多偶然的事情发生，都会影响到测试时间的估计，譬如设备故障、停水停电等，即使是具有丰富经验的技术人员也不能估算出较为准确的工作持续时间。因此，估算三种持续时间：乐观时间（to）、最可能时间（tm）、悲观时间（tp），采用加权平均法计算期望时间和方差。

期望时间 te = (to +4 tm + tp)/6

方差 σ2= ( ( tp - to) /6 )2

例如，测试箱体改造的时间估算见表2。

5. 进度计划表

根据以上资料，将各个分解任务按照其逻辑关系与组织关系输入软件Microsft Project，得到建筑幕墙测试项目进度计划表（甘特图）。

三、项目进度计划的优化

通过网络计划参数的计算确定关键路径。如果关键路径时间无法满足项目计划工期的要求，则计划还需要进行进一步的优化，以满足工期的要求。

项目进度计划的优化一般可以通过以下几种途径：

1. 在不增加资源的前提下压缩工期

在进行工期优化时，首先应在不增加系统资源的前提下压缩工期，有两条途径：

一是不改变网络计划中各项工作的持续时间，通过改变某些活动间的逻辑关系达到压缩总工期的目的，将某些串联的关键工作调整为平行作业或交替作业。例如，将“试件安装”与“测试仪器准备”从串联工作调整为平行作业，“正式测试”时的各项准备工作可交替作业。

二是改变系统内部的资源配置，削减某些非关键活动的资源，将削减下来的资源调集到关键工作中去以缩短关键工作的持续时间，从而达到缩短总工期的目的。

2. 平衡资源供应，压缩关键活动工期

关键路径的长度就是项目的工期，所以要压缩项目工期就必须缩短关键活动的时间。将初始网络计划的计算工期与项目要求工期相比较，会求出需要缩短的工期，通过压缩关键路线的方法进行多次测试计算直至符合项目工期的要求为止。

缩短关键路线上的子项目的时间是最有效的途径。但是必须注意非关键路线上的子项目的时间缩短后，是否令关键路线发生改变。

结论

本文探讨将网络计划技术应用于建筑幕墙测试项目的进度管理中，对其项目进度计划的初始编制、优化等方面进行分析研究，得出如下几点结论：

1）对于建筑幕墙测试项目，涉及到的相关单位多，项目活动多，时间紧，项目活动之间又相互制约和影响，借助项目进度管理的工具和方法，可以对项目进度实施有效的计划和控制。

2）运用进度管理工具和方法，可以在建筑幕墙测试项目众多纷繁复杂的项目活动中较容易地找出关键路线和关键路线上的关键事件。只要抓住项目进度的重点，把关键路线上关键事件的活动时间控制好了，也就实现了对整个项目的进度控制。

3）进度计划制定过程中，项目的各子项目之间的逻辑关系与组织关系的确定，直接决定了该项目进度计划的关键路径，要时刻注意关键路径是否发生改变，以便及时做出调整。

项目管理理论是近几十年来发展起来的新兴学科，其理论正日趋成熟，而中国的幕墙测试也才经历过十几个春秋，其体系和流程也在不断完善。将现代项目管理理论应用到幕墙测试项目上，无论对项目管理理论的发展，还是对幕墙测试项目管理水平的提高，都会起到积极的促进作用和良好的社会经济效益。

参考文献

[1]2007-2008年幕墙行业市场运行及投资分析报告[R]

测试工作计划篇（4）

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

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维护和终结阶段

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

测试工作计划篇（5）

1.引言

软件质量是指与软件产品满足明确或隐含需求的能力有关的特性，由于软件产品是逻辑体，不具有实体的可见性，因而其质量也就更加难以把握。软件产品的质量是通过软件开发活动和软件开发过程构造入软件的，所以软件开发管理者和软件开发者必须了解每一个开发活动对软件产品质量可能产生的影响，及时掌握每一个开发活动对软件质量所产生的影响，并且对在开发过程中可能产生的或已经产生的质量问题，能够及时发现并加以控制。要做到这些必须实现软件开发的工程化。软件全生命周期质量管理实际上就是工程化管理。它的主要任务就是使软件开发活动规范化、程序化、标准化。软件质量管理的基本方法就是根据软件开发活动的各阶段，将质量管理目标分解为若干可实现并可管理的部分，并采用相应的技术和方法进行管理，并对其阶段性产品的质量进行验证，确保最终软件产品质量满足用户的要求。下图是一个软件开发过程的主要阶段分解图。

2.需求分析阶段

2.1 任务及目标

软件需求分析阶段的任务是确定所开发软件的运行环境、功能和性能要求，编写开发计划。软件需求分析是由软件开发方根据委托方提出的软件任务书以及其它文件，详细确定软件需求并编制出一个需求完整、详细的软件需求规格说明。

2.2 实施步骤

1）分析和确定软件开发和运行的环境；2）明确操作者的要求，经分析后将任务书中的技术指标条文拟定成相应的软件需求规格说明的条文；3）确定人机界面；4）编制项目开发计划，确定项目质量要求，并将它分解为对软件开发各阶段的质量要求，给出检查准则；5）确定本项目的质量保证、配置管理工作，并写入项目开发计划；6）编写软件需求规格说明；7）初步编写软件测试工作计划，明确计划安排。软件测试工作计划一般由软件项目组编写。如要求独立测试，则测试计划应由独立测试单位在本阶段评审通过后根据需求规格说明另行编写；8）开始编写软件使用说明；9）评审；10）安排测试工作。若需要开发专门的测试软件或研制专门的软件测试设备，则应在本阶段评审通过后与软件开发并行地进行此项工作，以保证软件测试工作按时顺利进行。软件测试的测试软件开发和测试设备的研制工作按计划由软件项目组或独立测试单位承担。

2.3 阶段产品

1）项目开发计划；2）软件需求规格说明；3）软件测试工作计划；4）软件项目计划数据表。

2.4 技术要求

1）软件需求规格说明应对软件的主要功能、性能、技术指标进行定义，其内容应全面、可检查；2）项目开发计划中应给出阶段评审及配置管理计划，并明确人员。

2.5 配置管理要求

软件任务书、开发计划、软件需求规格说明、软件项目计划数据表、软件需求分析阶段评审表、软件测试工作计划进入受控库。

2.6 评审要求

在软件需求分析阶段，必须进行软件需求评审，以保证软件需求的完整性、一致性和准确性。提交软件任务书、项目开发计划、软件需求规格说明、软件项目计划数据等，针对项目开发计划及软件需求规格说明，对任务和需求分析、可行性分析、质量保证、标准化、配置管理等进行评审，以决定是否开展下阶段工作。

3.软件设计阶段

3.1 任务

软件设计阶段的任务是根据软件需求规格说明进行软件的总体结构和功能模块间的设计，初步编制软件集成测试计划。定义各功能模块的接口并设计数据结构，对功能模块进行过程描述设计，设计功能模块的内部细节，包括算法和数据结构，为编写源代码提供必要的说明。

3.2 实施步骤

1）总体结构设计；2）设计该软件系统的数据结构，给出所需的模型及所采用的算法原理；3）设计高层模块的数据流和控制关系；4）给出各个功能模块的功能描述、数据接口描述及全局数据定义；5）根据软件可靠性要求，对各功能模块进行可靠性指标的分配和相应的可靠性设计；6）进行安全性分析，使安全性关键的软件设计符合安全性要求；7）初步编制软件集成测试计划；8）确定所有模块的功能及详细的接口信息；9）对构成软件系统的各功能模块逐步细化，形成若干个可编码的程序模块或程序单元。

3.3 阶段产品

1）软件设计说明；2）软件集成测试计划（初步）。

3.4 技术要求

1）各功能模块间应具有低耦合度及高内聚度，功能模块的作用范围应在其控制范围之内；2）各模块功能单一，模块接口的复杂度低；3）软件设计说明和软件需求规格说明要保持一致，并具有良好的可追踪性；4）各子项目、模块的功能和接口要求必须完整、正确。

3.5 配置管理要求

集成测试计划（初步）、软件设计说明进入受控库。

3.6 评审要求

评审软件设计是否实现了软件需求规格说明的要求；评审设计方案与主要算法的可行性和先进性；并针对集成的单元之间的信息流和控制流的可追溯性、数据加工处理与数据结构的一致性、并发性信息处理的正确性、可靠性和安全性技术应用的程度及正确性等进行评审，并最终做出本阶段工作是否完成、是否转入下阶段工作的评审结论。

4.代码开发阶段

4.1 任务

根据软件设计说明对各程序单元进行编码、调试、静态分析和单元测试，验证程序单元与设计说明的一致性，并将经过单元测试的模块逐步集成和调试，完成软件系统集成，

4.2 实施步骤

1）对每个程序单元用指定的程序设计语言进行编码和测试；2）对完成编码的源程序进行静态分析；3）补充和完善单元测试用例并依此产生测试输入数据，开发单元测试程序；4）进行程序单元测试；5）将经过单元测试和调试的程序逐步集成和调试，直至集成为相对独立的软件功能模块；6）及时清除程序中用于调试等项工作的多余语句和程序“垃圾”；7）在集成调试后，对经过修改的模块应进行单元回归测试；8）编写软件使用说明初稿；9）评审。

4.3 阶段产品

1）修改了的软件设计文档及相应的修改报告单；2）程序单元的编码；3）程序单元的测试结果、测试用数据及测试辅助程序；4）软件使用说明初稿。

4.4 技术要求

1）用指定的编程语言进行编码；2）编码符合规定语言的编码格式约定；3）每个程序单元实现的功能、性能和接口应该满足设计说明的要求；4）必须进行程序静态分析；5）按要求应分别采用自检、互检、专检等方式检测软件，以提高软件质量和可靠性；6）被测试单元中的每项软件特性和功能都必须被至少一个测试用例所覆盖；7）采用必要的安全性设计措施，保证安全性设计需求的实现；8）对在单元测试中发现错误的程序应进行修改，修改后的程序单元必须进行回归测试；9）不仅要考虑对合法的输入产生测试用例，而且要对非法的、非预期的输入产生测试用例，既要对正常的处理路径进行测试，也要考虑对出错的处理路径进行测试； 10）程序单元的测试用例需加明确的注释，并和测试辅助程序一起纳入测试集，存档保留。

4.5 配置管理要求

修改的文档和相应的修改报告单、软件使用说明、程序单元的代码、单元测试数据和测试程序、软件实现阶段评审表进入受控库。

4.6 评审要求

评审编码、单元测试的正确性和完整性，在完成文档、程序编码、程序单元调试及单元测试的前提下，提供程序单元的编码、程序单元测试的结果和测试用例、程序开发卷宗等，对程序代码与详细设计的一致性、代码格式与规定要求的一致性、程序代码调试结果的正确性、静态分析过程的正确性和合理性、单元测试用例的充分性和合理性、单元测试数据的产生和测试过程的正确性、合理性和完整性、软件实现过程中若修改了软件详细设计或概要设计，则应多途径审查从被修改阶段开始到软件实现阶段为止所有改动部分的正确性等进行审查，做出软件实现阶段是否完成、是否将程序和文档提交，以便进行软件集成测试的结论。

5.集成测试阶段

5.1 任务

根据集成测试计划，在将底层程序单元逐步集成到子项目、直至整个开发项目的过程中对软件进行测试。在进入集成测试前，各程序单元必须完成代码静态分析和逐步审查、无错误地通过编译或汇编、完成单元测试、满足软件质量要求、程序单元已置于软件配置管理之下等。

5.2 实施步骤

1）补充、修改和完善软件集成测试计划；2）校订集成顺序，编制软件集成测试程序并核对其正确性；3）建立软件集成测试环境；4）对集成软件功能模块进行测试；5）对集成软件子项目进行测试；6）对集成软件产品总体进行测试；7）分析测试结果，找出产生错误的原因；8）提交软件集成测试分析报告，以便尽快修改错误；9）完成软件使用说明的编写工作；10）评审。

5.3 阶段产品

1）修改后的软件集成测试计划；2）修改后的软件设计文档及相应的修改报告单；3）软件集成测试分析报告；4）通过集成测试的代码；5）集成测试用例集和集成测试辅助程序；6）软件使用说明。

5.4 技术要求

1）软件集成测试应保证模块间无错误地连接；2）应测试软件系统或子系统对数据的正确处理能力和经受错误的能力；3）在软件集成测试中，在找出错误后，程序应送回编码者进行修改、调试和单元测试，然后再重新进行软件集成测试；4）通过软件集成测试的软件应满足各模块无错误地连接、满足各项设计要求、对错误输入有正确的处理能力、人机界面正确无误、满足全部操作要求等。

5.5 配置管理要求

软件集成测试计划、修改的软件设计文档及相应的修改报告单、软件集成测试分析报告、最后集成完成的程序代码、集成测试用例集和集成测试辅助程序、软件使用说明、软件集成测试的评审报告进入受控库。

5.6 评审要求

评审集成测试结果的有效性、软件的结构和接口间的协调性；评审在软件集成测试中对所发现的问题进行软件设计修改、程序代码修改的正确性。在完成测试、测试分析和文档提供软件集成测试计划、软件集成测试分析报告、软件问题报告单的前提下，对软件集成测试的恰当性、测试用例集的完整性和恰当性、测试结果和测试用例集的一致性、测试环境和正式运行环境的相容性、测试分析过程和结论的正确性等进行评审。

6.确认测试阶段

确认测试主要是针对软件的全部功能和性能要求的黑盒测试。软件项目开发单位的质量管理部门的测试人员负责测试过程的实施和测试结果的确认，技术管理部门的有关人员与业务部门及项目组成员共同组成确认测试小组，完成确认测试任务。

6.1 任务

1）根据软件需求规格说明中定义的全部功能和性能要求及确认测试计划，测试整个软件，确认其是否符合软件需求规格说明的要求；2）软件确认的依据是软件需求规格说明、概要设计说明及详细设计说明等，测试对象为通过了软件集成测试的源程序代码；3）软件确认测试工作包括测试环境的建立和测试计划的编制两项，此两项工作在软件需求分析阶段就应开始。

6.2 实施步骤

1）组织和确定软件确认测试组成员；2）修订确认测试计划，对确认测试计划进行评审，经批准后实施；3）建立和确认软件测试环境；4）接口测试；5）根据软件需求规格说明中规定的功能对软件逐项进行测试；6）根据软件需求规格说明中规定的性能要求，如精度、速度、适应性等，对软件逐项进行测试；7）逐条运用软件使用说明进行测试，以进一步证实该说明的适应性和有效性，并改正其中的错误；8）分析测试结果，找出产生错误的原因；9）编写确认测试报告；10）评审。

6.3 阶段产品

1）确认测试计划；2）确认测试分析报告；3）确认测试用例集及有关测试辅助程序；4）通过确认测试的程序代码。

6.4 技术要求

1）关键软件部件或测试项目的确认测试应由与该软件项目组无关的技术人员进行，以保证测试的客观性；2）应在正常输入数据和合理的异常输入数据的条件下，考查被测软件功能和性能的完备性；3）确认测试的测试环境必须与软件真实运行环境一致或相容；4）全部测试结果、预期结果及测试数据应当存档保留；5）个别功能和接口要求只能在系统联试后才能确认的，必须在确认测试分析报告中写明；6）软件项目组应积极配合确认测试组的测试工作。

6.5 配置管理要求

确认测试计划、确认测试分析报告、确认测试用例集及有关测试辅助程序、通过确认测试的程序代码、确认测试计划评审表和确认测试阶段评审表进入受控库。

6.6 评审要求

在本阶段应进行两次评审，软件确认测试计划评审和软件确认测试阶段评审。

1）确认测试计划评审

评审确认测试计划的合理性、完备性以及与软件需求规格说明的一致性。提供软件确认测试计划，确认测试计划安排的合理性；确认测试环境选择的合适性；确认测试计划中功能测试的合理性、齐全性；确认测试计划中性能测试的合理性、齐全性；确认测试用例、测试数据、测试方案的合理性、正确性和全面性；确认测试结果分析的合适性；确认测试组人员组成和安排的恰当性。该评审应得出的结论是该确认测试计划是否可行，是否批准实施。

2）确认测试阶段评审

评审确认测试结果的有效性；评审软件功能、性能与软件需求规格说明的相容性；评审确认测试分析结果的正确性。完成确认测试后提供软件确认测试分析报告、确认测试用例集，对确认测试用例集的完备性和恰当性、确认测试用例集和确认测试结果的一致性、确认测试环境和运行环境的相容性、确认测试分析过程和结论的正确性进行评审，最终确认该软件是否实现了软件需求规格说明所要求的技术指标，对确认测试过程不正确或不完整，需改进测试过程后重做或另外组织确认测试组重做。

7.系统联试阶段

7.1 任务

系统联试是大系统开发的一个重要阶段。系统联试应由大系统的开发部门主持，软件项目组参加，以保证软件与大系统的对接。

7.2 技术要求

1）软件与所属大系统的接口应重点测试，不允许有不协调之处；2）对软件向所属大系统输出的信息以及从所属大系统向软件输入的信息，都应仔细归类进行测试，并注意边缘测试；3）测试应在软件和大系统的正式工作环境下进行；4）对存在的问题应分析其产生的原因并给出修改意见；5）全部预期结果、测试结果及测试数据应存档保留。

8.总结

软件生命周期质量管理就是使软件开发过程规范化、程序化和标准化。它通过将复杂的问题分解为若干可实现并可管理的部分，对软件生命周期的各阶段采取相应有效的方法，对其阶段性产品的质量进行验证，以保证软件的质量。

参考文献

测试工作计划篇（6）

一、水平衡测试工作的地位作用

我国是一个缺水国家，而且随着经济和社会的发展，对水的需求越来越大，水资源的供需矛盾越来越突出，水资源短缺已经成为制约经济社会发展的瓶颈。开展节约用水工作，缓解水资源紧缺局面，就显得越来越重要。今年中央1号文和中央水利工作会议，要求实行最严格的水资源管理制度和用水效率控制制度，更是把节约用水提升到国家战略的高度。

我国大部分城市的节约用水工作，开始于上世纪八十年代初期，经过近三十年的改革与发展，取得了很大成绩，形成了较为完备的节约用水管理体系。节约用水工作主要包括计划用水与定额管理、水平衡测试与用水调查、“三同时、四到位”管理等核心内容。

“三同时”即新建、改建、扩建、建设项目与节水工程设施同时设计、同时施工、同时投产使用。“四到位”即用水单位要做到用水计划到位、节水目标到位、节水措施到位、管理制度到位。

水作为工业生产中的原料和载体，在任一用水单元内存在着水量的平衡关系，通过对用水单元实际测试，确定其各用水参数的水量值，根据其平衡关系分析用水合理程度，称之为水量平衡测试，通常简称为水平衡测试。

水平衡测试工作是一项技术性极强的工作；是加强计划用水、节约用水管理的基础工作；是搞好计划用水、节约用水、控制用水总量的重要手段；是科学制定用水计划、用水定额的重要依据；也是用水单位最大限度地科学用水，提高用水效率的重要技术手段。

二、水平衡测试的目的意义

水平衡测试是企业加强用水科学管理，合理用水的一项基础性工作。

通过水平衡测试应达到以下目的：

1、掌握单位用水现状。如给排水管网颁布情况，各类用水设备、设施、仪器、仪表分布及运行状况，用水总量和各用水单元之间的定量关系，获取准确的实测数据。

2、健全单位用水三级计量仪表。计量既能保证水平衡测试量化指标的准确性，又为今后的用水计量和考核提供技术保障。

3、测漏堵漏。找寻用水管网和设施的泄漏点，及时进行修复，堵塞跑、冒、滴、漏。

4、用水指标分解。准确地把用水指标层层分解下达到各用水单元，将用水纳入各级承包责任制或目标管理，定期考核，调动其节水积极性。

5、对用水单位现状进行合理化分析。依据掌握的资料和获取的各种数据，计算、分析、评价有关用水技术指标，找出薄弱环节和节水潜力，制订出切实可行的技术、管理措施和规划。

6、建立用水技术档案。在水平衡测试工作中，将搜集的有关资料、原始记录和实测数据，按照有关要求进行处理、分析，形成一套完整详实的包括图、表、文字材料在内的用水档案。

7、提高管理人员技术素质。通过水平衡测试可以培养管理人员，提高管理人员的节水管理水平和业务素质。

8、为制定用水计划指标和制定用水定额提供准确的基础数据。

通过水平衡测试，全方位为用水单位服务，指导用水单位节水管理工作，做到最大程度地节约用水，缓解供水压力。以节水减少水资源开发利用量，减轻对水资源污染，涵养水资源。以节水保用水，让有限的水资源得到充分利用，对促进社会可持续发展具有重要意义。

三、安阳市水平衡测试工作的历史、现状和经验

1、安阳市水平衡测试工作的历史、现状。

安阳市节约用水工作的开展与全国大部分城市一样，开始于上世纪八十年代初期。1982年成立了安阳市节约用水领导小组，下设办公室即安阳市计划节约用水办公室，其后经过多次机构改革，2002年底划归水利部门管辖，但安阳市计划节约用水办公室的职责基本没变，仍然从事计划用水、节约用水管理工作。

水平衡测试技术是效仿企业能平衡测试而产生的，并很快得到推广和发展，而且水平衡测试技术还在不断快速发展。

河南省供水协会节水工作部1987年编印了《工业水平衡测试技术培训教材》，河南省各地市以此为依据开展水平衡测试工作。安阳市水平衡测试工作从上世纪八十年代未开始进行，到2000年，大部分企业进行了水平衡测试。节水管理机构改革以后，自2005年开始进行新一轮水平衡测试，至2010年，历时5年多，已基本完成一个测试周期，共有300多个用水单位进行了水平衡测试，占计划用水单位的1/5，测试单位总水量占计划用水单位总取水量的96.2%。通过水平衡测试，基本摸清了安阳市用水现状，为进一步开展节约用水工作打下了良好基础。

2、安阳市水平衡测试工作的主要经验

经过三十年来的工作实践，特别是近几年来的工作实践，我们认为在水平衡测试工作中的主要经验有以下几点：

（1）加强水平衡测试工作管理。市节水办根据各计划用水单位情况和历年水平衡测试情况，制定年度水平衡测试工作计划，确定水平衡测试单位名单，在《安阳日报》等媒体上公示，并发文通知用水单位按要求进行水平衡测试。对于新建、改建、扩建的建设项目，当建设项目投产后，生产设备运行正常，生产稳定即开始进行水平衡测试工作，检验设计是否达到预想结果。此后的水平衡测试工作要跟踪服务，当产品种类改变、产品原材料改变、生产技术设备改变、生产工艺改变，用水量增加或减少变动较大时应进行水平衡测试。对于申请增加用水计划指标的用水单位，其用水量达到一定规模时，也应进行水平衡测试。同时，加强对水平衡测试工作的检查、验收等管理。

（2）转变工作方式，推行市场化运作。上世纪九十年代，国营企业多，水平行测试工作主要是计划经济模式，由市财政补贴经费，市节水办制定水平衡测试计划，并组织实施。2005年以后，随着产业结构的调整，民营企业得到了很大发展。而且经过多年的宣传，人们的节水意识得到了很大提高。针对市场经济新形势，我们转变水平衡测试工作方式，逐渐推行市场化运作模式。用水单位在接到市节水办水平衡测试工作的通知后，可以选择出一定费用，委托有能力的科研院所、技术咨询机构等进行测试，（在安阳市有能力进行水平衡测试的单位有河南省电力设计研究院、豫北水利勘察设计院、安阳赛波节水技术服务中心等），也可以选择单位自测。市节水办加强对水平衡测试工作的检查、督导和验收管理，确保水平衡测试工作质量。

（3）加强水平衡测试培训、指导。水平衡测试是一项长期复杂、繁重的技术工作。针对现在市场经济条件下用水单位民营企业多，工业行业多，用水工艺、设备复杂，人员变动大，且人员素质参差不齐的现状，节水办组织专业技术人员，每年对节水办和用水单位管理人员进行培训，提高其业务水平。同时在测试期间，加强技术指导，保证水平衡测试工作质量。

（4）适当扩大水平衡测试工作范围。通常所说的水平衡测试是指工业企业水量平衡测试，现有国家有关水平衡测试的规范、标准也是主要针对工业企业制定的。但是，在实际工作中，我们发现有些非工业企业用水单位，用水量较大，用水工艺比较复杂，有必要进行水平衡测试，才能掌握单位用水状况。所以，我们在实际工作中，参照工业企业水平衡测试技术规范和标准，对用水量达到一定规模的医院、宾馆、大专院校、大型商场、洗浴中心、车站等用水单位，进行水平衡测试，取得了较好的效果。

（5）加强整改措施落实情况检查督导，以水平衡测试为基础，带动全市节水工作的开展。水平衡测试的目的之一，就是了解单位用水现状，找出节水潜力，制定节水措施，并加以落实。作为水平衡测试后续管理的重要内容，我们十分重视用水单位节水整改措施的落实情况，加强检查、督导，通过节水整改措施的落实，带动全市节水工作的开展，以达到节约用水的目的。例如：安阳钢铁（集团）公司、安阳电厂通过水平衡测试，挖掘节水潜力，进行节水技术改选，建设节水工程，两个单位工业用水重复利用率均达到98%以上，实现了工业用水零排放。

（6）注重全市范围内资料的收集、分析和归档。水平衡测试是针对某一个用水单位的，其所获得的资料是单一的，零散的。但当水平衡测试单位达到相当数量时，对这些大量的信息进行统计、整理和分析，就能很好地反映整个城市以及各个行业的用水水平，为节约用水工作的进一步开展提供科学依据。在各项节水信息中我们特别注重节水工程建设、运行及统计工作，为此在水平衡测试的图件中增加了“节水工程卡片”，节水工程卡片中的内容主要包括：间接冷却水量、工艺循环水量、串联用水量、水处理中水回用量，生产取水量、设计能力、重复利用率，安装使用的配套设备、型号、能力，特别是水泵的正常运行及备用能力，工程建设起止时间、总投资、单位投资等。据统计，到2010年，安阳市已建节水工程多达216项，其中工业170项，生活48项，设计节水能力21.15亿m3/年，其中工业20.91亿m3/年，生活0.24亿m3/年。2010年实际节水量8.72亿m3，是设计能力41.2%。从2010年绘制的各种水量比例图表（见附件）内容看，工业节水量8.52亿m3/年，生活节水0.20亿m3/年，合计8.72亿m3/年。工业用水重复利用率93.6%，生活用水重复利用率33.3%，城区全社会用水重复利用率77.8%。由此可见，只有搞好节约用水，才能保障经济社会可持续发展。

四、安阳市水平衡测试工作中存在的主要问题

总结几年来水平衡测试工作的经验，我们认为主要存在以下几个方面的问题。

1、管理机构特别是县一级节水管理机构不够完善。市辖各县节水、水政管理是一套机构，两块牌子，日常工作主要以水政管理为主，主要是取水许可审批、水资源费征收、水事案件查处等。受人员编制和水平限制，很难正常开展节约用水和水平衡测试工作。

2、相关法律、法规和技术规范、标准有得进一步完善。现在安阳市进行水平衡测试工作的法律依据主要有《水法》、《河南省节约用水管理条例》技术规范标准主要有《企业水平衡测试通则》等。针对性、可操作性有待加强。例如，对用水单位内部节水管理网络建设，二、三级计量设施的安装，缺乏强制性规定，给基层管理造成一定影响。

3、用水单位主动性较差，被动配合多，硬件设施不完善。在市场经济条件下，民营企业多，一些用水单位在水平衡测试工作中被动配合，缺乏主动性，而且很多单位在建设之时，为了节约成本，未安装二、三级计量装置等硬件设施，给水平衡测试工作带来了很大难度。

4、资金短缺，影响水平衡测试工作开展和整改措施的落实。

5、节水办受人员编制、用人机制限制，用水单位受管理成本等因素限制，造成水平衡测试人员素质参不齐，影响了水平衡测试工作的进一步开展。

五、解决问题途径的初步探讨

1、理顺管理机制，加强水平衡测试工作的统一管理。

市节水办对全市各市、县水平衡测试工作实行统一管理。市节水办负责市区用水单位的水平衡测试工作。市辖各县应健全节水管理机构，积极组织开展水平衡测试、计划用水管理等节水管理工作，负责县域内用水单位的水平衡测试工作，业务受市节水办的指导监督。

2、国家、省等上级政府尽快完善相关法律、法规和技术规范、标准，使之更具有针对性、可操作性。

3、结合人事制度改革，组织专业技术人员，加强技术培训，提高节水管理人员的素质和业务水平。

测试工作计划篇（7）

中图分类号：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.

测试工作计划篇（8）

1.2测试过程不可控QC软件测试计划中测试执行阶段为2013.3.8-2013.3.27，执行三轮测试；实际测试时间为2013.3.23-2013.4.20，执行测试三轮，计划完成时间严重偏离，表2为原计划与实际计划的对比。表2显示测试计划进行了较大调整，计划截止时间比原计划延迟23天。延迟原因经分析主要为开发提交测试时间延迟，开发提交版本问题较多，测试计划安排不合理，在两轮测试间为安排开发修改bug时间等。想要解决该问题，不仅需要对测试过程进行管理，同时也需要对开发提交的测试版本质量进行管理。

2软件质量管理改进对策

2.1需求工程管理软件开发过程中，需求不明确会带来需求的频繁变更，浪费了很多时间。针对此项问题，可对需求相关的活动进行统一管理，其需求管理结构图如图2所示。加强需求开发和需求管理的有机结合，不仅减少了需求的变更次数，还解决了工程师对需求不能理解到位的问题。需求开发和需求管理同样重要，只有两者互相配合才能做出用户满意的产品。

2.2立项管理为了使有限的资源发挥更高的价值，公司可通过立项管理流程进行立项管理，立项管理流程分为立项建议、立项评审和立项筹备三个阶段，其具体流程图3所示。

2.3测试流程管理针对测试流程中发现的问题，可对整体的测试流程做如下的改变：（1）测试部门可进行需求学习及需求讨论，对理解不清楚及有疑问的需求，由研发设计部门进行解答，研发设计部门不能解答的由其联系用户确认后作出解答；（2）需求确认后，针对系统功能和性能等指标，由测试工程师进行测试测用例的设计，设计从两个方面进行，一方面测试工程师根据需求进行测试用例的编写，另一方面测试工程师可根据用户反馈问题进行分析汇总；（3）使用QC功能测试工具对应用软件兼容性、操作系统兼容性进行测试，以便于使用测试工具完成多种环境下的功能和兼容性测试；（4）进行自由测试以便于对系统测试用例进行补充，分析测试用例未覆盖问题的原因；（5）定期分析缺陷库中的问题，分析问题产生的原因，进行测试用例的修改。

测试工作计划篇（9）

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）17-0226-03

Abstract： Modeling software testing can greatly improve the quality and efficiency of software testing， and CMMI and other popular models， there is no detailed description of the process for software testing， software testing is no level of maturity of the evaluation and measurement， There is a lack of software testing process improvement goals and guidance. Based on this situation， this article Test Maturity Model（TMM） has been proposed by Dr. Burnstein formal description given maturity level structure TMM model elaborated five test level of maturity goals and sub-goals，， TMM and implementation methods are described， as well as the author summarizes and Reflection on the TMM model.

Key words： software testing； Test Maturity Model（TMM）； modeling framework； maturity level structure

1 背景

随着信息时代的快速发展，软件产业也逐步进入高速增长态势，软件过程的研究已经发展为软件测试行业的基础工作之一。要加强软件组织的开发能力、提高软件产品的质量，就必须不断地对软件过程的能力进行改进。因此，软件能力成熟度模型即CMM在1987年美国Carnegie Mellon 大学软件工程研究所应运而生CMM逐渐成为了评估软件开发过程的管理以及工程能力的标准。目前，已经形成了以个体软件过程、团队软件过程以及过程成熟度集成模型CMMI等为主导的软件开发过程改进体系[1]。但是，传统CMM的着眼点在于软件组织的开发过程和软件过程能力，并没有关于软件测试成熟度的概念，也没有研究改进软件测试过程的方法，因此，随着软件测试在软件生命周期中的地位越来越突出，软件测试成熟度得到了业内人士的高度重视，并且在传统的软件过程成熟度基础上继续进行模型改进，其中，比较具有代表性的是由Ilene Burnstein博士等人提出的软件测试成熟度模型（TMM），该模型是对CMMI模型的补充，是对CMMI模型的存在问题的修正，同时也对改进软件测试过程及提高软件测试能力做出了思想和方法上的指导。

2 TMM模型框架简介

TMM模型为了改进软件测试与评价过程，对CMM模型进行了较大程度的改进与补充。TMM模型在CMM模型的原有基础将软件测试过程划分为初始级、定义级、集成级、管理与度量级和优化级5个等级[2]`。处于初始级的软件测试，是一个混乱的过程，测试过程在编码之后，与调试未加区分；阶段定义级的测试过程，很大程度上凸显出测试过程与调试的区分，但是其被定义为编码之后进行的的独立阶段，显然不符合软件工程的要求；前两个阶段的存在的问题在集成级得到改善，集成级将软件测试融入到整个软件生命周期中，从需求分析开始，测试人员将伴随这个开发过程制定相应的测试计划、测试目标等；从管理和度量级开始，整个测试过程就已经由定性描述进入可度量化的过程。在此过程中，除进行测试之外，还有对软件生命周期各个环节的管理与审查；优化级是以前四级为基础，优化并预防缺陷、质量控制、监控测试成本与效率，为整个测试过程指引方向。

而每个等级（除等级1）都有自己的成熟度目标、子目标以及活动、任务和职责。TMM的模型框架如图1所示。

由图1可以得出，若要达到某成熟度等级，所必须实现的成熟度目标，即软件测试的改进目标。而成熟度子目标的定义更为具体，定义了该等级的范围、界限和需要完成的事项。通过活动和任务来实现子目标，任务和活动涉及实施和组织调整问题。活动和任务则定义了为了软件组织达到某一等级，进行软件测试改进的行动计划。三组人员各司其职，完成相关任务与活动，达到成熟度子目标[3]。

3 TMM的等级结构

TMM将测试的成熟度分为5个等级，每一级别都是一个测试过程，都有自己的过程域，软件组织要想达到更高的级别，就必须先满足前一个级别的过程域。同时也必须完成所有的被定义的目标。这些目标的定义，需要通过活动、任务和责任进行标记，在进行过程中，需要根据相关人员的特殊需求来不断调整[1]。如图2所示：

在TMM等级描述中，详细阐述了测试过程的特点以及为达到规定级别所需要完成的目标和子目标。

1）第一等级为初始级。软件测试的终极目标是为了查找程序中的错误，在这一阶段，由于相应的编码任务还没有完成，缺乏一定的测试资源，因此软件测试没有相对清晰的目标，测试任务也可有可无。

2）第二等级为定义级。在这一阶段，软件测试的目标是为了验证软件是否符合相应的需求，因此会启动一些相应的软件测试计划过程，并对采用的软件测试方法制度化，在定义级，由于在进行软件测试之前要把所有的编码工作完成，导致的结果就是在需求分析阶段与设计阶段产生的一些软件缺陷会一直遗留到编码阶段才能被发现。

3）第三等级是集成级。在这一阶段，会有相应的、相对独立的测试部门出现，测试工作不需要在完成编码后才能进行，而是在满足用户需求的目标上进行测试工作。并集成到软件生命周期的各个阶段中。在第三等级，需组建一个软件测试组织用于负责测试规划、测试缺陷跟踪等测试技术工作。同时在测试过程中需要有相应的测试工具对测试工作进行辅助。同时，软件测试小组成员要和质量保证专家一起，与客户进行沟通，从软件需求分析阶段制定软件测试计划，并根据需求分析表格制定相应的软件测试目标。该阶段的缺点为没有行之有效的评审制度以及没有一套质量控制与度量的标准等。

4）第四等级为管理与度量级。在这一阶段，软件测试是可以进行度量与质量控制的过程，应保证进行可靠性、可用性与可维护性等方面的测试。软件测试活动既包括程序语言，还把评审与审查作为软件测试活动的补充，用于发现及消除软件产品缺陷。为了测试过程的完备性，建立了缺陷管理系统并将缺陷的等级进行划分。同时测试人员采用数据库记录和管理相应的测试数据以及测试用例。但在管理与度量级，由于没有相应的缺陷预防系统，不能自动的进行收集与分析软件测试中生成的相应数据。

5）第五等级为优化级。在这一阶段，改进了第四等级的缺陷，已经具有相应的缺陷预防能力和软件质量控制能力，能够保证之前发现的缺陷不会在后期继续产生。在这一级，自动化测试工具是整个测试过程的重要组成部分。可以进行自动的收集与分析测试中产生的数据。并建立了测试流程与测试的规章制度。由于优化级的测试活动是可重复性、已定义、已管理和已测量，所以软件组织可以对测试过程进行不断的优化改进和调整。

根据上面描述的TMM的5个等级，给出相应的成熟度等级目标和子目标，如表1所示。

② 为软件测试活动定义相应的目标、任务、活动和工具等＼&

启动测试计划过程＼&① 制定软件测试计划模版并进行任务分配

② 获取用户需求

③ 准备软件测试活动所需的工具＼&将基本的测试技术和方法制度化＼&① 在软件组织中实施基本的测试技术与方法，例如黑盒测试、白盒测试策略等。

② 制定相应的管理制度，明确规定基本的测试技术和方法何时、怎样实施，以及基本的测试工具等。＼&集成级＼&

建立软件测试组织＼&① 选择和培训相关人员成立测试小组

② 为每个测试小组成员进行职责分配

③ 与客户进行讨论，获取用户需求＼&

制定技术培训计划＼&① 为测试人员制定技术培训计划

② 明确具体的培训内容，例如：测试方法、测试标准、测试技术与工具、审查与评审过程等＼&将软件测试集成到软件生命周期中＼&① 将软件测试计划阶段划分为和生命周期各阶段相关联的各个子阶段

② 将测试策划集成到生命周期的各阶段

③ 打通渠道，提高用户参与度＼&控制与监督测试过程＼&① 监督和控制过程可视化，为测试过程提供依据

② 随时与测试策划对比，及时调整测试进展

③ 定义和配置测试相关项＼&

管理和测量级＼&

建立组织范围内的评审程序＼&① 拟定正式的评审程序

② 将评审定义为测试活动，在生命周期中实施通行评审

③ 识别、记录、清除软件产品和测试工作的缺陷＼&

拟制测试度量程序＼&① 拟定一套关于测试过程质量与能力的度量程序

② 准确识别测试数据，对测试数据进行详细处理分析

③ 根据测试结果，不断修正测试计划＼&

软件质量评价＼&① 根据测试过程充分性，定义可度量的质量属性和目标

② 测试过程完成后，需要保证软件产品可靠、可用、稳定、安全＼&

优化级＼&

应用过程数据预防缺陷＼&① 成立预防缺陷相关小组

② 记录缺陷、分析缺陷，找出缺陷根源

③ 缺陷预防组的相关成员与其他组的成员相互配合制定缺陷预防计划，防止已被识别的缺陷再次产生＼&

实施质量控制度量＼&① 根据所定义质量属性，进行测试

② 通过统计抽样、等级度量促进测试过程

③ 融入开发团队，减少缺陷，提高软件质量

④ 运用模型工具，加强测试充分性＼&

优化测试过程＼&① 根据测试进展，量化测试过程，对测试过程不断优化调整

② 建立组织结构标准，支撑成熟度的不断提高＼&]

4 TMM实施

为了指导软件工程人员进行正确的软件过程评估，采用TMM等级提供支持。在软件组织中实施TMM时，可遵循以下步骤：

1）准备活动

这个步骤中要建立评估小组，选择与培训小组成员，确定组长，选择测评项目，并制定评估计划，准备参加评估的组织部门。根据客户需求制定评估问题表。

2）实施评估

评估过程中，评估小组成员通过和被评估人员进行沟通，获取相关的评估信息，通过查询相关文档与调查表进行信息补充。为保证信息的准确性与客观性，可将信息记入问题表。评估人员根据记录信息，划分软件组织的TMM等级。

3）分析评估结果

评估人员根据评估输出的TMM等级及相应的记录分析当前软件组织存在的缺陷，并指出该软件组织需要提高的领域以及要达到的下一个目标的优先级。量化的改进目标，制定出相应的行动计划。

4）活动计划

为了使软件组织能够达到TMM的高等级，评估小组应根据高优先级的改进目标开发活动计划，通过该计划描述相应的活动和资源，并改进现有的实践内容和进度。

5 结束语

软件产品的开发过程是一项长期的工程，需要不断研究和实践。本文针对传统软件成熟度模型的不足，将TMM模型进行了详细的阐述。TMM模型补充了CMMI模型的不足，能够充分的覆盖软件测试的一系列问题，并且软件组织可以根据TMM的要求，评估当前软件测试能力的状态，并对测试目标和测试过程进行不断修正，极大提高软件测试人员的工作效率。利用TMM模型不断优化测试过程和目标，将会给软件开发和测试组织带来质量和经济上的双丰收。

参考文献：

[1] 朱少民. 软件测试方法和技术[M]. 北京： 清华大学出版社， 2010： 71-74.

测试工作计划篇（10）

中图分类号：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.测试总结阶段的工作产品：软件测试报告。

七、结束语

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

参考文献：