1.1.测试及验收方案1.1.1.测试方案在软件开发项目中，测试非常重要，测试贯穿规范的软件开发流程的整个过程。

测试能尽早地发现软件问题，促进软件的改进和软件质量的提高；另一方面，测试能验证软件是否满足任务书、软件需求分析、软件设计和相关标准所规定的技术要求，为软件可靠性与安全性评估提供依据，为软件项目的验收评审提供依据。

1.1.1.1.测试阶段测试分为以下几个阶段：单元测试、代码评审、集成测试、功能测试、性能测试、用户测试。

其中代码评审、单元测试和集成测试在软件实现阶段进行，单元测试、集成测试是以软件为测试主体。

功能测试、性能测试和用户测试在软件完成阶段进行，以软件所属系统为测试主体，软件参加到系统中进行测试。

1.1.1.2.测试过程每个测试阶段包括如下测试过程：制定测试计划、编写测试用例、建立测试环境、执行测试、编写测试报告、评审测试结果。

制定测试计划测试计划确定测试范围、测试任务、测试项目、被测试特性、测试方法、进度、资源和评价准则。

编写测试用例根据被测试特性，设计测试用例，确定特性通过准则，为每一个测试用例制定输入、输出和测试规程。

建立测试环境根据测试计划中规定的测试方法和测试资源，建立测试环境，选择测试工具。

执行测试按测试规程获得并验证所需要的输入数据，执行测试用例集，观察并记录输出数据和其他状态现象，测试过程中发现问题，应填写《软件测试问题报告单》。

编写测试报告评价测试工作和被测软件，编写测试报告，测试报告包括代码审查报告、单元测试、集成测试、功能测试和性能测试的测试报告。

评审测试结果各测试阶段均应编制测试计划和测试报告两个测试文档，测试文档应经过相应评审，其中，代码审查、单元测试和集成测试的测试文档由开发组内部组织评审，项目经理参与各阶段文档的审核，评审过的文档由时纳入配置管理。

1.1.1.3.测试用模板测试过程要用到多个文档模板，包括评审问题记录单、评审总结报告、软件问题报告、软件修改报告等。

表错误!文档中没有指定样式的文字。

-1 评审问题记录单评审问题记录登记号评审日期年月日评审性质评审□复审□项目名子项目名实施部门编号问题摘要问题类型是否解决1234表错误!文档中没有指定样式的文字。

-2 评审总结报告表错误!文档中没有指定样式的文字。

-3 评审成员签字表注：可以不设副组长；此外，项目负责人或项目组人员可以作为评审组的成员，但不能担任评审组的组长或副组长。

软件问题报告（第1页，共页）软件修改报告（第1页，共页）1.1.1.4.单元测试单元测试主要采用白盒测试技术，用控制流覆盖和数据流覆盖等测试方法设计测试用例；主要测试内容包括单元功能测试、单元性能测试和异常处理测试等。

单元测试流程分为单元测试设计、单元测试准备、单元测试实施和记录、单元测试错误跟踪。

单元测试设计即单元测试用例设计，由系统设计人员在详细设计的同时完成。

单元测试准备为按照测试用例的要求，准备单元测试驱动数据和驱动模块，由开发人员在开发过程中完成。

单元测试实施和记录由开发人员在编码完成以后进行。

单元测试问题跟踪由开发人员和系统设计人员共同完成，根据引起问题的不同原因进行不同处理。

如果测试问题为编码错误，则由开发人员完成纠错后重新测试。

如果测试问题为设计阶段引起的问题，则需要进行设计变更。

1.1.1.5.代码评审编程组组长组织人员进行代码检查。

若所写的代码不符合编码规范，即便已实现了系统功能，仍然认为不合格的，需要重写。

代码检查的意义保证代码编写的规范保证代码编写的过程不产生BUG代码检查的依据检查代码是否有更新检查存在问题是否有更新检查存在问题是否已解决问题已解决，则填写《代码检查记录》1.1.1.6.集成测试集成测试采用白盒测试和黑盒测试相结合的测试技术和渐增式的测试策略，用数据流等测试方法设计测试用例。

主要测试内容包括单元之间的接口测试、全局数据结构测试等。

集成测试包括集成测试设计、集成测试准备、集成测试实施和测试记录、集成测试问题跟踪和结束测试等阶段。

集成测试设计由测试组组长根据项目计划和开发计划编制《集成测试计划》，设计《测试用例》。

测试计划和测试用例应当通过项目经理的审查。

集成测试准备需要系统测试组组长建立独立的测试环境。

测试环境包括测试硬件环境、网络、数据库、应用服务器等以及测试对象(程序)的安装和初始化工作。

集成测试实施和测试记录是由系统测试组组长组织人员按照测试计划和测试用例要求进行测试，并且记录测试过程和测试结果。

集成测试问题跟踪是在测试过程中发现的问题由系统测试组组长根据测试记录提交测试问题报告，并由系统设计人员和开发人员解决每一个问题的过程。

测试结束指测试问题报告中的问题解决后，进行回归测试。

当测试问题降低到一定程度并通过测试通过准则时，系统测试组组长提交测试总结报告结束测试。

1.1.1.7.功能测试功能测试包括两大部分，一是包括基本业务功能、业务测试、接口测试和可用性测试等方面的功能测试，二是包括：安全性测试、故障恢复测试、数据库测试、配置测试、安装测试的产品化测试。

验收测试主要从系统的实用性、稳定性、可维护性、灵活性、可操作性、和安全性方面进行测试。

（1）测试目标在整个的软件开发过程中，由于各种原因应用系统会有不完善的问题，这些问题会体现在开发后发布的软件产品中，并在产品中极大的影响着产品的使用，对于用户，这些缺陷阻碍着完成他们的既定目标和工作。

所以我们要组织并执行测试，以降低软件产品中存在的缺陷，保证产品的质量和可用性，测试工作的目标就是降低BUG率，从各个方面提高软件产品的质量和可用性，为用户提供优质的解决方案。

计划进度表和测试计划对业务系统测试进行了时间和内容上的定义与约束。

（2）测试流程下图是功能测试的流程，概要描述了测试过程中所涉及的角色，测试阶段，以及各阶段不同角色需要完成的任务。

图错误!文档中没有指定样式的文字。

-1业务测试流程在准备测试用例这一活动中，我们所执行的具体任务如图所示，在确定具体的测试范围及内容后，进行测试分类，并根据分类的结果确定需要设计的测试用例。

测试用例是测试工作中重要的指导性文件，测试需求的输入是《系统需求规格说明》。

在整个测试过程中，我们将用IBM Rational缺陷管理工具ClearRequest对测试大纲、测试用例、测试问题等进行管理，并可对问题进行统计。

（3）测试完成标准实现功能完全符合功能列表。

所有的功能页面均可达。

问题得到妥善处理，不含有A,B,C类问题。

定义的测试项目完成。

产品化测试的约束达成。

（4）缺陷管理追踪工具描述中提到的ClearRequest，可以应用于测试的全过程，也可以用于管理各类评审的缺陷等。

还提供一些模板，例如测试计划、测试总结、测试大纲、测试问题卡，因此可以实现从测试计划到总结的各测试活动管理。

我们以需求说明书、软件需求规格说明为输入编写测试大纲，对应测试大纲中的内容和测试需求编写测试用例，测试人员可以根据测试大纲和用例执行测试，发现问题后，记录在ClearRequest中，测试负责人通过查看缺陷问题列表将问题分配给对应的开发人员，开发人员通过查看问题列表修改问题，ClearRequest还提供了各种统计功能，例如根据问题的发现日期、问题等级、问题的分布、问题引入阶段等进行统计，这些统计结果可用来进行分析和总结。

测试过程中使用ClearRequest管理工具的益处在于：提高了测试的生产率工具自动进行统计和分析能够将问题卡输出到Excel文件中，便于与相关人员进行交流和确认。

1.1.1.8.性能测试性能测试总体流程与业务系统测试的流程基本相同。

验收测试主要从系统的实用性、稳定性、可维护性、灵活性、可操作性、和安全性方面进行测试。

性能测试的内容源于南水北调中线管理局对系统的性能要求，此外就是针对南水北调中线干线工程安防综合监控与信息服务系统业务多、范围广、层次多、用户量大的特点，对关键业务、关键流程进行性能测试。

（1）测试目标性能测试的目标是在整个系统或一个系统的特定组件上定义、建立和执行性能测试。

验证系统是否满足性能要求，如不能满足，要进行相应的优化。

（2）测试流程根据系统的性能要求，我们首先对性能测试进行策划，确定性能测试的类别和测试方法。

然后开发性能测试的用例，确定测试环境并准备就绪后执行性能测试，确定测试中的系统或组件的性能，并使用其结果决定性能是否可以被业务所接受。

如果在测试中度量的性能特性证明是不能被接受的，我们可以通过对业务的改进、数据库、应用服务器等进行调优，以提高性能质量，在进行系统调优前，我们同样要进行调优的设计与分析。

性能测试与应用和技术架构紧密相关并且两者互相影响。

表错误!文档中没有指定样式的文字。

-4性能测试类别与方法举例测试类别测试方法导入大量数据到系统中，检查单用户操作时系统的大数据量测试性能表现，对于较慢的操作进行分析、查找原因直（3）性能测试指标1、响应时间响应速度在用户心理所能承受的范围内。

无论是客户端还是管理端，当用户登陆，进行任何操作的时候，系统应该及时进行反映，系统应能检测出各种非正常情况，并及时提示用户。

表错误!文档中没有指定样式的文字。

-5性能测试类别与方法举例数据上载/下载1M及以下文件上载/下载时间<20秒；10M及以下文件上载/下载时间<5分钟；数据汇总简单汇总处理时间<30秒钟；复杂汇总处理时间<3分钟；2、可扩展性在设计上必须具有适应变化的能力，当系统新增业务功能或现有业务改变时，应保证业务在整体框架不变的基础上，业务变化造成的影响局部化。

3、易用性所有的业务功能界面风格和操作流程一致，业务表单做到所见即所得，录入能够完全通过键盘完成。

4、可靠性系统应保证7*24小时内不宕机，保证在正常情况下和极端情况下业务逻辑的正确性。

5、可用性必须避免由于单点故障或系统升级而影响整个系统的正常运行。

6、可维护性系统能够简单方便的修改和升级，包含可度性、可修改性、可测试性等。

7、可管理性和服务支持能力每个层次、每个构件都提供标准的管理接口。

实现统一的、一致的日志功能。

每个构件都提供应用架构规定的标准外部接口。

1.1.1.9.用户测试为保证系统适合业务管理的功能要求，除了我公司组织测试外，还积极配合发标方最终用户对系统进行测试。

（1）用户测试流程用户测试流程如下：明确测试内容，其中包括功能、性能、可用性、安全性、兼容性、与其他系统集成确定测试范围：确定业务情况类型是是非常重要的。

每一种业务情况类型都对应一个实际商业业务。

业务情况类型可以被表达成多种状况（例如，简单情况、或需要进行复杂处理的例外情况）。

测试小组成员确定：由管理人员、业务人员、技术人员等组成，我方提供验收测试过程中的技术支持。

明确问题分类标准系统的功能通过功能测试进行验证。