测试及验收方案

1.1.1. 测试方案

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

1.1.1.1. 测试阶段

测试分为以下几个阶段：单元测试、代码评审、集成测试、功能测试、性能测试、用户测试。其中代码评审、单元测试和集成测试在软件实现阶段进行，单元测试、集成测试是以软件为测试主体。功能测试、性能测试和用户测试在软件完成阶段进行，以软件所属系统为测试主体，软件参加到系统中进行测试。

1.1.1.2. 测试过程

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

制定测试计划

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

编写测试用例

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

建立测试环境

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

执行测试

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

编写测试报告

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

评审测试结果

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

1.1.1.3. 测试用模板

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

表错误!文档中没有指定样式的文字。-1 评审问题记录单

评审问题记录 登记号 评审日期 评审性质 年 月 日 评审□ 复审□ 项目名 子项目名 实施部门 编号 1 2 3 4 问题摘要 问题类型 是否解决 5 6 7 8 9 10 11 12 13 14

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

评审总结报告 登记号 评审日期 评审性质 年 月 日 评审□ 复审□ 项目名 子项目名 实施部门 阶段名 项目负责人 评 审 任 务 软件定义 需求分析 概要设计 详细设计 编码测试 集成测试 确认测试□ 姓名 □ □ □ 电话 □ □ 及验收□ 评 审 材 料 评 审 结 论 备注 通过 结论概述 不通过

表错误!文档中没有指定样式的文字。-3 评审成员签字表

评 审 小 组 成 员 职务 姓名 职称 组长 副组长 成员 成员 成员 成员 成员 成员 成员 成员 部门 签字 注：可以不设副组长；此外，项目负责人或项目组人员可以作为评审组的成员，但不能担任评审组的组长或副组长。

软件问题报告（第1页，共 页）

软件问题报告 系统名 报告提出部门 阶段名 问 题 程序□ 登记号 登记日期 年 月 日 报告人 需求分析 概要设计 详细设计 编码测试 集成测试 确认测试 运行维护 □ □ 子系统名1 子系统名2 子系统名N 版本号 文档□ 文档1 文档2 文档3 □ □ □ 运行的硬件平台 运行的硬件平台 运行的硬件平台 媒体编号 文档编号 文档编号 文档编号 □ □ 问题描述/影响： 附注： 部门负责人批准 总师办负责人批准 软件修改报告（第1页，共 页）

软件修改报告 登记号 登记日期 系统名 申请修改部门 修改类型 修 改 程序 □ 子系统名N 子系统名2 修改 □ 子系统名1 修改时间 修改部门 修改人 年 月 日 年 月 日 升级 □ 运行的硬件平台 运行的硬件平台 运行的硬件平台 修改已通过测试否 老程序版本号 文档1 新程序版本号 新文档编号 新文档编号 新文档编号 程序媒体编号 测试部门 文档 文档2 □ 修改描述： 附注： 项目审查意见 总体组审查意见 文档3 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性能测试类别与方法举例

测试类别 测试方法 导入大量数据到系统中，检查单用户操作时系统的大数据量测试 性能表现，对于较慢的操作进行分析、查找原因直测试类别 测试方法 到最后修改 用loadrunner模拟并发用户操作，通过多用户并发操作测试 loadrunner及servertrace等工具进行问题查找和跟踪 不同带宽下的测试 疲劳测试 （3）性能测试指标 1、响应时间

用loadrunner模拟不同带宽进行测试 用loadrunner模拟进行测试 响应速度在用户心理所能承受的范围内。无论是客户端还是管理端，当用户登陆，进行任何操作的时候，系统应该及时进行反映，系统应能检测出各种非正常情况，并及时提示用户。

表错误!文档中没有指定样式的文字。-5性能测试类别与方法举例

功能名称 并发数 页面加载 目录树加载 数据列表加载 录入数据检查提醒 数据查询 性能要求 支持1000次/秒并发 页面加载时间< 5秒 目录树加载时间< 5秒； 数据列表加载时间< 5秒； 录入数据检查提醒时间< 2秒 简单查询处理时间< 5秒； 复杂查询处理时间<15秒； 数据统计 简单统计处理时间< 5秒； 复杂统计处理时间<15秒； 数据上载/下载 1M及以下文件上载/下载时间<20秒； 10M及以下文件上载/下载时间<5分钟； 数据汇总 简单汇总处理时间<30秒钟； 复杂汇总处理时间<3分钟； 2、可扩展性

在设计上必须具有适应变化的能力，当系统新增业务功能或现有业务改变时，应保证业务在整体框架不变的基础上，业务变化造成的影响局部化。

3、易用性

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

4、可靠性

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

5、可用性

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

系统能够简单方便的修改和升级，包含可度性、可修改性、可测试性等。 7、可管理性和服务支持能力

每个层次、每个构件都提供标准的管理接口。实现统一的、一致的日志功能。每个构件都提供应用架构规定的标准外部接口。

1.1.1.9. 用户测试

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

（1）用户测试流程 用户测试流程如下：

明确测试内容，其中包括功能、性能、可用性、安全性、兼容性、与其

他系统集成

确定测试范围：确定业务情况类型是是非常重要的。每一种业务情况类型都对应一个实际商业业务。业务情况类型可以被表达成多种状况（例如，简单情况、或需要进行复杂处理的例外情况）。

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

系统的功能通过功能测试进行验证。在功能测试过程中发现的问题根据其严重程度进行分类。下表列出了功能测试问题的分类。

表错误!文档中没有指定样式的文字。-6功能测试问题严重程度分类

严重程度 问题说明 足以造成系统崩溃，造成文件不可靠或潜在的数据丢失 A类：非常造成非正常地返回操作系统（系统崩溃或显示系统错误信息）。 严重性错Bug造成程序越或要求Reboot系统。 误 造成缺乏关键的程序功能并无法逾越。 由于设计问题，使系统存在严重隐患。 Bug可能不会削弱系统，但将造成严重问题（如：严重的格式化错误等）。 功能缺乏给用户带来极大不方便。 B类：严重性错误 存在不明确或不完整的错误信息提示，极大地影响产品使用。 由于Bug的存在使产品其它部分不能测试。 由于计算方法问题，使数据错误。 由于设计原因，造成前后不一致，但问题可恢复。 容错性方面存在不足。 由于精度问题造成数据不一致。 严重程度 问题说明 这个Bug在将来是严重的，但比主要问题（Major Problem）要轻。 Bug可以绕过，但将会很不方便或很难实现。 可以有一个比较简单的绕过Bug的解决方案。 操作界面错误（包括数据窗口内列名定义、含义是否一致）。 C类：一般打印内容、格式错误。 性错误 简单的输入限制未放在前台进行控制。 删除操作未给出提示。 数据库表中有过多的空字段。 存在不明确或不完整的错误信息提示，但对产品使用影响较小。 界面不规范。 辅助说明描述不清楚。 输入输出不规范。 D类：轻微长操作未给用户提示。 和建议性提示窗口文字未采用行业术语。 错误 可输入区域和只读区域没有明显的区分标志。 对系统运行没有影响，提出可以使系统从可移植性、兼容性、错误恢复能力和可维护性、易用性方面的意见 明确功能测试标准

表错误!文档中没有指定样式的文字。-7功能测试标准

测试标准 测试成果 新系统可执行程序 验收标准 将测试结果与测试计划和功能描述进功能描述 行对照检查，确定系统满足功能描述的接口描述 要求 操作手册 别的问题 不存在B及以上级（2）用户测试设计

设计测试用例：确定每个功能的测试用例，明确系统输入信息和期望的输出结果。针对需求规格说明书的每一条功能，编写测试用例。每个测试用例包括测试条件（包括生成测试条件需要的测试数据类型）和期望的结果。每个测试用例都应该是唯一确定的（例如，赋一个数值）。

设计测试大纲：依据测试范围生成测试大纲。对每一种业务情况类型，生成尽可能多的测试用例来完善测试大纲。为了保证测试大纲包含所有的测试用例，将测试用例的条件映射为测试大纲是非常必要的。测试大纲中测试用例的顺序安排是非常重要的，它应考虑多种方面的因素，主要考虑的因素是按照系统产生的数据，在测试大纲中安排测试用例的顺序，使得一个测试的结果作为另一个测试前提。

测试环境准备：为了预防出现问题，如数据损坏或对系统资源的争用，需要建立一个独立的测试环境。在进行测试之前，根据测试计划中确定的时机建立一个独立的测试环境。其准备工作包括：

技术活动：如建立不同的服务器或在一台服务器上建立多个数据库实例，将相应的程序迁移到适当的程序库中；

准备活动：包括加载数据表，建立用户访问权限； 建立版本控制程序，保证有效的控制对系统的修改；

建立文档控制程序，保证随着系统的修改，有效地控制文档的修改（如，培训文档、联机帮助和用户手册）。 （3）用户测试结果

测试结束后，测试小组根据测试数据，制定并向验收工作领导小组提交《用户测试报告》。

测试报告结果说明软件满足下列要求： 在认可的外部设计文档中表述的功能要求 在认可的系统描述文档中表述的非功能要求 此外，测试报告中还包括对系统提出的改进意见。

测试过程中产生的工作成果： 《测试计划》 《测试方案》 《测试需求分析》 《功能测试用例》 《业务测试案例》 《测试报告》 《各阶段评审》 《系统测试方案》 《系统测试案例》 《系统测试报告》 《试运行测试报告》 《工作周报月报》 《评审文档相关》 《缺陷数据和分析》

1.1.2. 验收方案

由于本项目采购的服务器、工作站、机架、NVR等都是大型厂商提供的标准通用产品，不存在工厂定制生产的情况，所以不进行工厂验收。本项目的验收包括到货验收、分部工程验收、单位工程验收、合同项目完成验收。在验收阶段，所有应用系统将按照南水北调中线管理局和我公司都认可的《系统需求分析》，组织验收小组，进行功能和性能的验收测试。从系统的实用性、稳定性、可维护性、灵活性、可操作性、和安全性及系统文档、代码、规范及注释说明等方面组织全面验收。

1.1.2.1. 验收组织

成立由招标人、监理方、其它相关单位人员以及有关方面的专家组成的验收

小组，负责对项目进行各项验收。

1.1.2.2. 验收通用要求

1. 项目部提出本项目部的验收方案，并与招标人讨论协商，报监理人审批

后实施。

2. 本项目检验前，项目部提前5天通知监理人和招标人。验收过程中项目

部与招标人在验收程中应密切合作，以完成本项目验收。

3. 招标人对验收的认可、参加或放弃参加验收和测试，项目部均不认为减

轻对合同的任何责任。

4. 招标人有权拒绝接收有缺陷的产品（服务）或要求进行改造，由此引起

的一切费用应由项目部负责。经改造后的产品（服务）应重新进行验收。 5. 所有验收结果和结论，都应详细记录并由项目部的有关当事人正式签字。

验收报告一式四份，其中二份交招标人，一份交监理人，一份交中标人。

1.1.2.3. 验收依据

验收依据包括招标书、投标书、合同、软件说明书、相关的国家标准、行业标准、规范以及检测规程、开发报告、测试报告、技术开发文档等。

1.1.2.4. 到货验收

到货验收包括硬件设备的到货验收和软件安装介质的到货验收，以及软件安装调试的初步验收。

到货验收应依招标文件要求对全部硬件设备的名称、型号、数量、包装及资料进行验收，同时对全部软件的名称，版本、数量、介质外形、包装及资料、文件进行验收。到货验收步骤是先检查包装是否符合要求，确认外包装完好且运输没有受损；然后检查编号、数量、名称是否与到货清单一致；最后开箱检验箱内设备外观是否受损，数量是否短缺。

1.1.2.5. 分部工程验收

分部工程验收内容主要包括：需求分析阶段验收、详细设计阶段验收、监理测试阶段验收。针对需求分析阶段验收，项目部提供需求分析报告用于验收；针对详细设计阶段验收，项目部提供详细设计说明书用于验收；针对监理测试阶段验收，项目部提供测试方案及用例用于验收。软件安装调试初步验收时，项目部提供测试方案，并按方案对其产品的性能和功能进行测试检查，进行符合性验收，检验是否满足指标要求。

交换机验收

对交换机进行物理特性测试、功能测试、操作维护测试。

1. 物理特性测试包括：各指示灯的状态测试、告警指示灯状态测试、交换

机的启动与关闭测试。

2. 功能测试包括： 连通性测试、路由协议测试。 3. 操作维护测试包括：查看配置信息、管理交换机。 测试表格： 测试目的 1. 物理特性测试：各指示灯的状态测试、告警指示灯状态测试、交换机的启动与关闭测试。 2. 功能测试： 连通性测试、路由协议测试。 3. 操作维护测试：查看配置信息、管理交换机。 测试步骤和过程 1. 物理特性测试 交换机上电自检时，各种指示灯指示是否正确。 交换机无告警信息，端口指示灯工作是否正常。 远程、本地重启或关闭交换机，是否可成功完成。 2. 功能测试 接入不同网段的两台操作主机，是否可以通过交换机的路由协议相互连通。 3. 操作维护测试 检查交换机的数据配置情况是否和方案要求一致。 是否能以Telnet管理方式（或其它可用的管理方式）登录交换机。 预期测试结果 交换机无故障，工作状态正常，路由协议运行正常、管理功能正常。 实际测试结果 备注 服务器验收

1. 查看各台服务器有无报警，能正常的启动与关闭。

2. 对所调试的服务器进行测试，测试所装的操作系统是否为相应的版本，硬件

是否与供货清单一致，所有设备驱动是否都已安装。 测试表格： 测试目的 1. 查看各台服务器有无报警，能正常的启动与关闭。 2. 对所调试的服务器进行测试，测试所装的操作系统是否为相应的版本，硬件是否与供货清单一致，所有设备驱动是否都已安装。 测试步骤和过程 1. 服务器开机，面板上的电源指示灯是否常亮，硬盘指示灯是否闪烁，报警指示灯是否不亮。 2. 启动服务器，服务器自检完成后，自动启动Windows server系统，查看的操作系统版本是否与要求一致。 3. 在硬件---设备管理器中各个硬件驱动是否安装完成，系统的各个设备是否工作正常。 4. 网络配置是否正确，是否能PING通各自的网关。 预期测试结果 1. 服务器开机，面板上的电源指示灯常亮，硬盘指示□正常 □不正常 灯闪烁，不亮报警指示灯，说明服务器开机自检正常，内部硬件无报错。 2. 操作系统的版本为正版。 3. 所有的设备驱动都已经安装完成。 实际测试结果 备注 □正常 □不正常 NVR设备验收

对设备进行物理特性测试、操作维护测试。

1. 物理特性测试包括：各指示灯的状态测试、告警指示灯状态测试、存储设备

的启动与关闭测试。

2. 操作维护测试包括：查看配置信息、管理存储设备。 测试表格： 测试目的 1. 物理特性测试：各指示灯的状态测试、告警指示灯状态测试、设备的启动与关闭测试。 2. 操作维护测试：查看配置信息、管理存储设备。 测试步骤和过程 1. 物理特性测试 设备上电自检时，各种指示灯指示是否正确。 设备无告警信息，端口指示灯工作是否正常。 重启或关闭设备，是否可成功完成。（需注意对服务主机的影响） 2. 操作维护测试 登陆存储管理界面，查看配置信息是否与方案要求一致。 是否可对存储进行相关操作。 预期测试结果 存储设备无故障，工作状态正常；主机均能识别存储空间，并能进行读写操作。管理、维护功能正常。 实际测试结果 备注 机柜验收

□正常 □不正常 检验机柜是否符合方案要求。 测试表格： 测试目的 测试步骤和过程 检验机柜是否符合方案要求。 1. 检查机柜是否与方案要求一致。 2. 检查配件是否齐全。如：镙丝、固定伸缩脚等。 3. 检查放入机柜中的设备是否平衡。（U数是否一致） 4. 检查机柜是否摆放平稳。 5. 机柜是否接地。 预期测试结果 配件齐全，设备摆放平稳，机柜摆放平稳，接线板安装牢固，机柜接地。 实际测试结果 备注 网络测试

1. 检查网络结构是否正确 2. 检查各设备之间是否连通 3. 检查IP地址是否正确 测试表格： 测试目的 测试步骤和过程 检验网络结构是否符合方案要求。 1检查网络结构是否正确：根据网络规划图，用观察的方式检查网络结构是否正确。 2 检查各设备之间是否连通：根据下表使用ping命令测试网络设备，检查从本地设备到目的设备之间是否连通。 □正常 □不正常 预期测试结果 实际测试结果 备注 网络结构是否正确，各设备之间连通正常。 □正常 □不正常 1.1.2.6. 单位工程验收

在完成分部工程验收后，进行单位工程验收。单位工程验收即用户测试验收，项目部根据相关技术规定，主要针对各个软件之间的协同运行，先行制定系统集成联调验收测试方案（相关的测试工具由中标人提供），并经招标人批准执行。系统集成联调验收测试在招标人主持下进行。系统集成联调验收测试通过后，经招标人、监理人同意后召开单位工程验收会，对应用服务平台所应提供的各类服务逐项进行验收。

项目部提供单位工程验收所要求的所有资料。招标人出具书面验收纪要给项目部。项目部按初验纪要采取修改、完善和补救措施。符合全部条件（完成项目的全部测试，并提出正式报告；项目合同规定的项目内容全部完成；各种文档资料齐备，提交招标人；按单位工程验收纪要完成了全部必要工作）后，项目部向招标人提出试运行要求。经招标人同意后，系统方可正式试运行。

安防业务综合监控系统主要验证对视频监控管理、智能电子围栏管理，以及对视频监控和电子围栏两个系统的功能与业务集成，实现综合监视、现场入侵判断、声音警告联动控制、视频联动控制、与监控中心软件系统联动、值守人员视频复核后联动、报警管理、监控调度等内容。同时实现权限管理、设备分级管理和报警信息管理等。

安防信息服务应能提供包括各类专题信息以及各应用系统处理后的成果信息的查询和统计。业务流程为各级用户向安防信息服务模块发出服务请求，安防信息服务模块通过应用支撑平台数据交换，从各业务系统数据库中提取数据，经过组织和加工处理，进而为各级用户主体的服务请求做出响应，其中也包括主动对拥有的系统全面信息进行深层次分析，满足中线局领导或专家对信息服务多样性的需要。

1.1.2.7. 合同项目完成验收

系统在试运行期间连续运行3个月后，项目部申请合同项目完成验收。 由华胜天成提出书面申请，招标人批准后进行本项终验，即合同项目完成验收，确保项目部承担的项目已符合有关合同、标准，文档齐备、需修改项目已完成。在验收过程中，如发现质量、数量、种类、性能或功能不符合合同要求或存在剩余工作，项目部应按招标人规定的时间完成全部工作，再提出验收申请。

验收的内容包括以下几个部分：

（一） 验收内容一般包括软件验收（按功能要求的可执行软件、开发计划文档、详细设计文档、质量保证计划、设备相应附件、设备运行、网络运行等）

（二） 验收评测工作主要包括：文档分析、方案制定、现场测试、问题单提交、测试报告；

（三） 验收测试内容主要包括：功能度、安全可靠性、易用性、可扩充性、兼容性、效率、资源占用率、用户文档。

（四） 文档验收标准一般包括：文档完备性、内容针对性、内容充分性、内容一致性、文字明确性、图表详实性、易读性、文档价值等。

（五） 软件、硬件验收标准要符合国家和相关标准。 文档验收（需要删减） 01.合同书

02.软件实施进度计划 03.调研计划 04.需求规格说明书 05.质量保证计划 06.文档编制规范 07.软件编码规范 08.概要设计说明书 09详细设计说明书 10.测试计划 11.测试用例 12.测试报告 13.安装手册 14.用户手册

15.有关图纸资料及设备清单 16培训计划 17.软件培训报告 18.软件试运行计划 19.软件试运行报告 20.质保维护方案 21系统维护及常见问题 22.运行维护记录

23.验收方案 24项目工作总结报告 25.技术报告

26.经费使用情况报告 27.运行管理制度 28.项目的相关标准文本 29.用户报告