省级卫生信息化平台项目实施服务方案

　 省级卫生信息化平台项目 实施服务方案

　目 目 录 第一节、 项目概述 ........................................................................................................... 3 1.1 政策背景 .................................................................................................................... 3 第二节、 项目实施方案 ................................................................................................... 5 2.1 实施服务承诺 ............................................................................................................ 6 2.2 项目实施管理 ............................................................................................................ 9 2.3 项目实施进度安排 .................................................................................................. 13 2.4 项目管理和质量保证 .............................................................................................. 13 2.5 文档管理 .................................................................................................................. 17 2.6 二次开发方案 .......................................................................................................... 18 2.7 系统测试方案 .......................................................................................................... 23 2.8 系统试运行方案 ...................................................................................................... 46 2.9 项目评审验收 .......................................................................................................... 51 2.10 质量保障体系设计 ................................................................................................ 61

　第一节、

　项目概述 1.1 政策背景 卫生信息化工作是医改整体工作的重要一环。中共中央、国务院于 2009年发布的《关于深化医药卫生体制改革的意见》和《国务院关于印发医药卫生体制改革近期重点实施方案（2009-2011）的通知》中，都把卫生信息化建设作为深化医改的八大支撑之一，要求建立实用共享的医药卫生信息系统，大力推进医药卫生信息化建设，以推进公共卫生、医疗、医保、药品、财务监管信息化建设为着力点，整合资源，加强信息标准化和公共服务信息平台建设，逐步实现统一高效、互联互通。

　党和政府高度重视医药卫生信息化工作。2009 年 3 月 17 日中共中央、国务院发布的《关于深化医药卫生体制改革的意见》中提出“建立实用共享的医药卫生信息系统”，要求“以医院管理和电子病历为重点，推进医院信息化建设；利用网络信息技术，促进城市医院与社区卫生服务机构的合作”。2010 年 2 月11 日由卫生计生委等五部委联合发布的《关于公立医院改革试点的指导意见》进一步要求“以医院管理和电子病历为重点推进公立医院信息化建设，充分利用现有资源，逐步建立医院之间、上级医院和基层医疗卫生服务机构之间、医院和公共卫生机构、医保经办机构之间的互联互通机制，构建便捷、高效的医院信息平台”。

　“十二五”期间是全面落实国家医药卫生体制改革任务，实现国家医药卫生体制改革目标的关键时期。卫生信息化（含中医药，下同）建设是深化医药卫生体制改革的重要内容，也是其开展工作、服务民众、发展壮大的重要支撑和

　保障条件。加强卫生信息化建设，对于方便群众就医，规范医疗服务行为，提高医疗卫生服务质量和效率，降低医药费用，缓解看病难、看病贵问题，促进人人享有基本医疗卫生服务具有非常重要的现实意义和社会影响。为配合新医改形势下的卫生信息化建设，卫生计生委相续发布了《健康档案基本架构与数据标准（试行）》、《电子病历基本架构与数据标准（试行）》、《基于健康档案的区域卫生信息平台建设指南（试行）》、《基于健康档案的区域卫生信息平台建设技术解决方案（试行）》、《基于区域卫生信息平台的妇幼保健信息系统建设技术解决方案（试行）》、《基于电子病历的医院信息平台建设技术解决方案（试行）》、《电子病历系统基本功能规范》、《基于电子病历的医院信息平台建设技术解决方案》在内的一系列重要成果，为卫生信息化建设奠定了良好的基础。

　随着计生体系的融入，过去的五项业务将增加计划生育这一新业务变成六项业务，两大基础数据库要增加全国人口数据资源库变成三大基础数据库，也就是说，目前，国家卫生信息化“十二五”规划从“35212”变成“46312”，新的规划具体如下：“十二五”期间，我国将重点建设国家级、省级和（州）市级三级卫生信息平台；加强信息化在公共卫生、医疗服务、计划生育、新农合、基本药物制度、综合管理六项业务中的深入应用；建设电子健康档案、电子病历和全国人口数据资源库三个基础数据库；建设一个医疗卫生信息专用网络；逐步建设信息安全体系和信息标准体系。

　 第二节、

　项目实施方案 鉴于本项目的建设规模大、周期短、涉众度、结构复杂、难度大的特点，为了保障项目按时完成并交付，我公司将采用多地市并行的方式开展实施服务。

　时间 地市 第一个月 第二个月 第三个月 第四个月 地市一

　地市二

　地市三

　地市四

　地市五

　地市六

　 硬件安装联调 硬件安装联调 硬件安装联调 硬件安装联调 硬件安装联调 硬件安装联调 系统集成实施 系统集成实施 系统集成实施 系统集成实施 系统集成实施 系统集成实施

　2.1 实施服务承诺 2.1.1 实施技术支持服务承诺  在实施过程中，我公司承诺参与省级人口健康信息平台商的总体讨论和方案细化，承诺在项目实施过程中接受平台商的相关技术指导，服从业主方的项目统一实施要求。

　 对于已经与当地的区域卫生平台对接过的医院，公司承诺本次招标所有基础软硬件发放到位并指导原来的厂商完成基于本次标准化的接口改造，或者根据所在地市卫生计生委的要求按照省平台建设标准由本公司完成医院与当地区域平台的对接。

　 公司承诺在项目验收时提供的书面技术资料能满足确保系统正常运行所需的运行、维护及管理有关的全套文件，书面技术资料详细清单详见“项目验收交付成果”。

　 公司承诺在试运行期间，将派遣有经验的技术人员在现场负责系统的运行和维护，若系统出现问题或故障，公司承诺将免费进行故障处理和软件更新。

　 公司承诺在系统建设和运维过程中，将对系统进行不断的优化和调整，满足性能指标要求。对于特定的业务，项目建设将满足业务开展要求和用户使用习惯的前提下，通过用户、使用单位和公司三方共同协商，制定具体的性能要求指标。

　 公司承诺项目实时期间，将严格按照 CMMI 标准的需求开发与管理流程体系。

　 从项目启动到项目终验结束的各个阶段，派遣有项目开发、集成实施等相关经验的技术人员组成项目服务部到招标人现场实施服务。通过制定完善、可实施和针对性强的技术支持服务方案，并成立技术力量雄厚的技术支持小组，为本项目的实施提供及时、有效、专业的现场技术支持服务。服务的范围涵盖需求、设计、开发、集成、测试、安装部署、培训等过程。并且保证派遣的核心人员相对稳定。

　 在项目实施过程中，要求成立的项目服务组织结构将与本项目建设单位进行密切沟通与配合。对于招标人提出的有关技术问题，要求及时给予满意的答复，并提供切实可行的解决方案，确保本项目按预期进度顺利实施。

　 我公司将在招标人的统一部署安排下，配合第三方测试机构完成第三方测试。测试的内容包含功能测试、常规性能测试（可靠性、效率等）、专项性能测试（负载、压力、疲劳测试等）和安全测试（系统安全性、系统代码安全性、安全漏洞攻击、数据库安全性测试等）。

　 在试运行期间，要求提供足够的培训和技术支持服务，确保招标人能够对系统有正确的理解和熟练使用，并根据系统运行中出现的各类问题以及招标人提出的相关要求，对系统进行及时的修改完善，保证无重大事故发生。

　 要求提供与项目实施相关的各类技术咨询服务。例如：协助招标人预见系统实施过程中可能发生的问题和困难，并向招标人提出可行的解决方案或建议；在系统的运行维护阶段提供技术支持；对运行过程中出现的新问题提供建议和解决方案；提供与信息化项目相关的其他技术咨询服务。

　 密切配合监理的工作，接受监理单位的监督和检查。如果与其他投标人发生争议，必须服从监理单位的裁决。

　 配合总集完成整个软件系统的总集成工作，听从总集的安排完成本项目中相关软件的部署、试运行、正式上线及验收工作。

　2.1.2 质量服务承诺  在项目中需建立符合标准规范的开发与管理流程体系，提供专业的技术团队保证项目顺利实施；  提供完善的质量保障体系，确实可行的质量保障措施，能结合项目要求，提出较完善的质量保障方案。包括质量目标、质量计划、进度计划、质量管理组织、质量管理办法、质量承诺等；  所开发的软件必须符合国家相关标准和功能规范，以及经业主方审批通过的《需求规格说明书》并通过相关测试、评审和验收；  提供详细的技术方案，方案应遵循国家标准规范，符合招标文件中技术要求部分的相关内容，方案应包括但不限于目标、范围、内容、构架、路线、功能指标、性能指标、测试和验收等内容； 2.1.3 验收服务承诺  提供详细的验收方案，方案应遵循国家标准规范，符合招标文件中技术要求部分的相关内容，方案应包括但不限于功能指标、性能指标、验收内容、验收测试方法、测试标准等；  在验收阶段，将按照招标方、监理和投标人都认可的《系统需求规格说明书》和验收方案，由招标方、监理和投标人共同组成验收小组，进行功能和性能的验收测评。从系统的实用性、稳定性、可维护性、灵活性、可操作性和

　安全性，以及系统文档、代码、规范及注释说明等方面组织全面验收。验收测试安排分为系统初验和系统终验；  承诺项目验收时提供的书面和电子全套软件开发文档，符合国家标准和行业规范，符合 CMMI 认证规范要求的软件担保，能满足确保系统正常运行所需的运行、维护及管理有关的全部文件，并在投标文件中列出所提供的书面和电子技术资料详细清单。

　2.2 项目实施管理 在项目实施过程中，公司将制定和实施一个有效的项目管理计划是必不可少的。在工程实施的每个阶段结束之前，对该阶段所产生的结果进行严格的技术审查。在下个阶段开始时，对前一个阶段的工作进行认真的复查，确保已具备开始下阶段工作所必须的条件后，向开发管理小组提交项目的总体状况、成本和进度报告，以便管理小组对开发工作进行审查和安排。项目管理主要有以下内容：

　2.2.1 流程管理

　图 1 项目实施流程 2.2.2 变更管理 由于项目的庞大性、跨地域性、机构繁杂、对接的信息系统较多等特点，变更控制将是项目管理的重要活动之一。变更控制的目标是通过对变更的影响做事先的评估，并在合适的决策层面进行评审，然后通过将变更计划纳入项目计划中进行实施，在保证新产品开发项目中各项重要变更是正确的前提下，最终得到有效的实施。

　 图 2 项目变更流程 2.2.3 沟通管理 项目例会制度：

　 周例会：实施现场每周召开例会，项目各工作小组每周一次例会，主要安排工作计划及对工作完成情况的汇报，每次会议形成会议纪要文件，便于跟踪会议工作内容的落实。

　 月例会：项目领导小组每月听取工作组的工作进展、问题的汇报，同时进行相关协调、支持、指导意见，便于项目顺利执行；形成会议纪要文件，并通报项目领导小组所有成员。

　 座谈会：对于重大事项需要项目领导组进行协调、决策的，首先由项目工作组等提交相关材料，然后组织会议研究解决问题，形成会议纪要便于执行。

　2.2.4 项目报告制度  周汇报：商务组、工作组、开发组、质量组每周向项目管理组进行工作周汇报，主要汇报重点工作、完成进度、偏差分析、问题、建议等内容。

　 月汇报：项目工作组每月向工程领导组进行月度项目汇报，包括项目进展、偏差、存在问题、建议等内容。

　2.2.5 项目管理平台 提供较为全面的项目成员沟通方式，项目管理平台主要包括：

　电子邮件沟通，即时消息，音频会议，视频会议，BBS 交流区，文件交流，问题管理。

　2.2.6 文档管理 项目管理文档主要有以下几类：

　（1）过程文档管理 （2）定稿文档管理 （3）开发文档管理

　2.3 项目实施进度安排 项目整体实施周期为：自合同签订之日起

　120 个工作日内完成终验。

　软硬件基础设施实施周期 前置服务器和安全隔离与信息交换系统将会按照甲方统一规划，在签订合同后 30 个工作日内完成到货验收，并在签订合同后 90 个工作日内完成设备安装和联调工作。

　软件实施周期 前置交换系统的安装部署，我方将按照甲方的统一规划，基于区域卫生数据交换平台，实现与省级人口健康信息平台以及辖区医院系统的集成对接，实现数据统一采集与交换。

　我方将在签订合同后 60 个工作日内完成所在组的所有医院的交换前置系统安装部署工作，并在合同签订后 120 个工作日内完成系统集成工作，并完成项目终验。

　2.4 项目管理和质量保证 2.4.1 管理的保障 为了保证项目管理的有效性，主要可以采用三种工作方式对项目的各个阶段进行检查和控制，这三种方式分别为：评审文档，专题技术讨论和辅助工具评测。

　1．评审文档 调配各个领域的技术工程师，对我公司提交的成果文档进行认真、细致地

　审查。对文档中不符合总体设计的问题或者对总体设计理解有偏差的地方，填写《问题反馈表》。根据《问题反馈表》，通过内部充分的技术交流和讨论，将问题定性，并最终形成《文档评审意见》。

　2．专题技术讨论 对于重大的管理、技术或协调问题，建设方与承建方会以讨论专题讨论的方式进行。讨论的主题可以是具体的技术（比如软件系统、数据库系统、数据中心系统、网络系统、安全系统等）、管理方式或方法（比如质量管理、配置管理、人员管理等）。

　3．辅助工具评测 对于项目过程中非文档的阶段性成果，可采用多种辅助工具对系统的功能、性能进行评测。评测的方式既有模块测试，也有集成测试。

　2.4.2 实施的保障 我们按照下面的程序来保证该项目的实施：

　1．项目准备阶段 组建项目实施队伍，成立一个有实施经验的工程师、卫生信息技术人员及有丰富业务经验的相关专业技术人员组成的项目实施组。

　2．调研设计阶段 现状调研 进行业务调研，对各医院现有系统和数据量进行了解，收集数据字典等材料，完成调研报告。

　系统设计 根据省级人口健康信息平台的要求进行前置交换数据库设计，并根据各医院信息系统情况进行合适得接口选择和设计。

　3．系统实施、试运行阶段 系统实施 在医院部署前置交换系统，实现与前置交换系统与省级人口健康信息平台和医院信息系统的数据交换。

　培训 培训工作分为两部分。一是针对业务部门的实际工作人员进行软件的使用操作培训；另一个是对医院的电脑管理人员进行操作系统、数据库、网络、系统配置等知识的培训。

　2.4.3 效果的保障 为确保系统的顺利实施，制订可行的培训计划，提供全方位多层次的培训服务，并且要提供特色培训，在不同时期，针对不同种类的需求提供一系列行之有效的培训实施方案。

　培训对象主要包括参与系统建设的各单位领导、信息管理人员等；提供的培训分为项目专题培训和项目现场培训。

　1．项目专题培训 项目专题培训将贯穿于整个项目实施过程，项目专题培训中的专业技术培训分为系统管理员培训和系统操作员培训；由我公司的培训教师来完成培训任务，培训地点由我公司与建设方共同商议确定。

　2．项目现场培训 我公司的实施工程师在实施现场负责完成培训任务，培训地点在系统实施现场。

　2.4.4 质量的保障 为保障质量，需要对系统开发、实施等一系列过程进行质量控制，确保产品的质量。

　1． 阶段性评审 在软件实施的各个阶段，对项目实施的每个步骤进行阶段性评审，并完成《阶段性评审报告》。

　2. 变动控制 变动控制一般有两种情况，一种是在实施过程中用户提出新的要求；另外一种是项目组在实施过程中因为碰到了预先未考虑的因素，提出需求变更的请求。

　3. 文档更新控制 在整个项目的实施过程，无论碰到任何需求或设计上的变更，都需要对相关文档进行修改。由版本控制员通知相关人员进行修改，并跟踪实施，从而保证整个文档体系的完整性和正确性。

　4．文档控制 根据项目特点，文档管理要遵循以下原则：

　文档名与文档标号规范、文档存储策略。

　文档质量要求体现在：针对性、精确性、清晰性、完整性、灵活性、可追溯性。

　文档控制包含以下内容：文档管理计划、建立连续控制机制、设计文档标准、编写文档管理、发布文档管理、维护文档管理、开发管理、文档传输流程、访问控制、版本控制。

　项目组负责人与专门负责版本控制的开发人员密切配合，及时沟通使符合医院需求的版本能及时发送到医院，从而使需求得到及时反馈。

　2.5 文档管理 2.5.1 文档管理控制 文档控制是指对项目实施过程中所产生的文档进行的管理控制行为，是为了让文档管理要作到及时、真实、符合规范，应按以下要求来定制文档模版和组织实施。根据项目特点，文档管理要遵循以下原则：

　文档名与文档标号规范、文档存储策略。

　文档质量要求。体现在：针对性、精确性、清晰性、完整性、灵活性、可追溯性。

　文档控制包含以下内容：文档管理计划、建立连续控制机制、设计文档标准、编写文档管理、发布文档管理、维护文档管理、开发管理、文档传输流程、访问控制、版本控制。

　2.5.2 文档更新控制 在整个项目的实施过程，无论碰到任何需求或设计上的变更，都需要对相关文档进行修改。由版本控制人员通知相关人员进行修改，并跟踪实施，从而保证整个文档体系的完整性和正确性。

　对于一个软件项目而言，所涉及的文档有：

　主要的开发类文档：需求分析说明书、概要设计说明书、详细设计说明书、

　数据库设计说明书、测试计划、测试报告、程序维护手册、程序员开发手册、用户操作手册、项目总结报告。

　主要的管理类文档：项目计划书、质量控制计划、配置管理计划、用户培训计划质量总结报告、评审报告、会议记录、开发进度月报。

　2.6 二次开发方案 2.6.1 二次开发需求处理工作流程 定制/二次开发过程建设方技术组承建方需求分析组建设方承建方需求分析组应用该设计组 应用该设计组 应用该设计组需求、建议业务分析 接收技术分析、设计技术处理、编码需求验证测试通过测试？否否发布 需求处理反馈验收通过验收？否结束

　图 3 二次开发需求处理流程 2.6.2 系统分析与设计 1、 主要参与人员 需求、建议阶段的主要参与人员包含：建设方需求分析组、承建方技术组、承建方的各业务部门、各行政部门。

　2、 输入 建设方提出的需求、建议：由需求分析组对建设方各业务部门、行政部门等提出的需求需求、建议，进行收集、汇总、分析并整理成需求文档。

　承建方需求分析组提出的需求、建议：由需求分析组的调研人员经过详细调研后提出需求、建议，并整理成需求文档。

　3、 输出 由建设方将所有收集回来的需求进行汇总、分类并整理成需求说明文档。

　2.6.2 业务分析 1、 主要参与人员 需求、建议阶段的主要参与人员包含：建设方需求分析组、承建方技术组以及建设方各业务模块、行政部门相关负责人。

　2、 输入 由需求分析组负责人组织需求分析会议，通过会议对各类型的需求说明文档进行讨论、分析并根据需求类别提出解决建议方案。

　3、 输出

　1) 业务（行政）类需求解决方案 通过需求分析将可以通过行政手段、实施手段等方式处理的需求筛选出来，并提供需求解决方案，并将需求说明文档、需求解决方案等资料移交给实施（培训）小组进行需求处理与需求反馈工作。

　2) 技术类需求解决建议方案 通过需求分析将需要通过技术手段处理的需求筛选出来，并进行需求分析、讨论后提出需求解决建议方案，将需求说明文档、需求解决建议方案移交到应用设计组。

　2.6.3 技术分析 1、 主要参与人员 技术分析主要由应用设计组根据需求分析组提供的需求说明文档、需求解决建议方案进行分析、讨论并提出需求技术解决方案，为了确保应用设计组人员对需求理解的准确性，在技术分析阶段需要有需求分析组人员参与。

　2、 输入：由应用设计组相关负责人组织会议对需求分析组提供的需求说明文档、需求解决建议方案进行技术实现分析、讨论，并根据分析、讨论结果提出技术解决方案 3、 输出：技术解决方案 2.6.4 需求分配 1、 参与人员：应用设计组

　2、 输入：由应用设计组负责人根据需求说明说、技术解决方案分配工作任务，每项任务必需明确项目组预期完成时间及计划完成时间，其中预期完成时间需要与需求分析组协商后确定（要求需求分析组人员提交文档时进行描述），计划完成时间根据任务具体情况确定，任务接收人如有疑问必须及时提出。

　3、 输出：研发安排表：包含需求处理负责人、需求处理时间、需求预计完成时间等。

　2.6.5 需求处理与提交 1、 参与人员：应用设计人员 2、 输入：需求处理负责人根据需求说明书、技术解决方案、研发安排表进行需求的技术实现，并提交需求。

　3、 输出：需求处理完，需要提交文档内容必须包括：

　1) 测试环境描述文档 2) 修改对象描述文档 3) 功能描述以及特殊说明文档 测试组如果对此文档有不明白的地方，修改人有义务向测试组描述清楚。

　2.6.6 测试 1、 参与人员：应用设计组、需求分析组 2、 输入：测试人员根据测试任务执行测试后，根据不同测试结果进行测试结果反馈。对于存在 Bug 的产品则填写测试报告后反馈给程序员进行处

　理；对于可交付成果进行打包提交给实施组进行程序发布、需求反馈。

　3、 输出：测试记录单、测试报告、产品操作手册 2.6.7 需求反馈 1、 参与人员：需求分析组、应用该设计组、实施（培训）组 2、 输入：由需求分析组、应用该设计组将需求说明书、技术解决方案、测试报告、产品操作手册等交接给实施（培训）组，由实施（培训）组负责产品的实施、培训、需求处理结果反馈等工作。

　3、 输出：需求处理反馈表 2.6.8 二次开发范围 从项目启动开始到系统验收截止，所有的业务流程调研、收集、挖掘建设方需求以及建设方提出的需求、建议，经过需求汇总、分析、筛选、评估后，所有需要从技术方面进行解决的需求，均认为是系统的二次开发范围。

　2.6.9 二次开发依据 二次开发过程遵循《计算机软件质量保证计划规范》（GB/T12504-90）

　、《信息技术软件工程生存期过程》（GB/T8566）、CMM3 标准以及我们自己的《技术部份》之《工程质量控制方案》的相关规定。

　2.6.10 二次开发规范管理 1）二次开发工作由建设方技术组、各相关业务部门、相关行政部门以及承

　建方的需求分析组、应用该设计组、实施（培训）组共同完成。

　2）建设方项目需求首先必须通过建设方技术组、承建方需求分析组、应用设计组等负责人进行分析处理。

　3）建设方所有需求都必须通过承建方与建设方约定的方式提供（一般以书面形式通过文档管理平台进行提交），并由建设方技术组、承建方需求分析组、承建方应用设计组等进行需求分析并确认需求处理方案以及绩效分值，必要时可以由相关应用设计组人员直接与业务流程调研了解需求。

　4）所有需求处理完后必须提交给应用设计组的测试小组，并由测试小组将测试结果反馈给应用设计组和实施（培训）组，应用设计组根据测试结果进行需求二次处理或者发布新程序的工作。所有应用设计组人员提交完成需求处理结果时必须写程序修改、发布日志说明及相关注意事项。

　5）项目提出需求属于重大需求（具有通用性且修改要一周以上），应用设计组负责人必须向项目经理提出“需求评审”，召集相关人员一起作需求分析； 6）关于版本控制必须严格按照测试小组管理条例，带出或者带回源代码、版本库、数据库必须经过项目经理审批并办理相关手续。

　2.7 系统测试方案 为了确保系统质量，保证系统实施建设符合客户实际的业务需求和管理模式，公司建立了一套完整、科学、多角度的系统测试流程。通过系统测试、模拟和试运行，反复多次的进行系统性能检验，确保系统质量合格。

　2.2.1 测试任务与步骤 系统测试是衡量产品质量的重要过程，建立详细的测试计划是测试工作保质保量完成的前提。而一个详细的测试计划需要依据项目的实际实施中发生的活动和系统需求来编制，我们将在项目实施过程中根据需要而制订详细、切实可行的测试计划。

　本项目进行测试的主要任务有：

　 制订测试计划、测试标准及测试风险评估和避免措施；  设计测试过程、用例和数据；  测试执行；  评价准确性；  利用测试结果，监控和改进测试过程；  分析测试结果，给出测试报告，确定系统的可用性。

　验收测试过程包含以下步骤：

　 制定测试策略和过程；  设计测试用例和数据；  准备测试环境；  测试执行；  测试总结。

　2.2.2 制定测试策略和过程 在测试过程中，客户对递交的系统进行测试和评估，确信系统满足规定的验

　收标准，确定系统是否能够提高工作效率，客户将对系统的各个方面进行评估。制定一个好的测试范围是成功进行验收测试的关键。

　下面提出系统测试的主要范围：

　 用户界面测试：验证用户界面符合标准。要求的测试数量取决于开发过程中为保证一致性所采用的工具，一般在测试刚开始时进行。

　 功能测试：保证系统的运行满足功能需求。

　 接口测试：保证与其它系统或子系统的接口工作正常。

　 兼容性测试：保证系统在各种可能的用户都可以正常使用，如，不同的操作系统、浏览器、数据库等。

　 负载测试：保证系统在最大设计负载下运行平稳，一个好的测试经验是让系统在超过最大设计负载 25%的数据和处理负载下运行。

　 恢复测试：保证备份和恢复程序工作正常，以及当系统遇到突发事件如断电、网络连接中断时对数据的正确处理。一般来说，恢复程序的基本测试在系统测试开始时进行，然后在系统测试结束之前再进行进一步的恢复测试。

　 安全测试：验证系统安全满足要求，必须是系统的合法用户才能登录并进行允许的相关操作。由于安全是系统的基本功能，所以安全测试通常安排在系统测试的开始。

　 转换测试：验证现有的数据能进行正确的转换。通常情况下，在处理测试过程中转换的数据与新数据一起使用来验证数据转换的正确性。

　 文档测试：验证系统的用户手册、安装手册、帮助信息等说明性文档的内容是否符合功能及易读、易理解。

　 性能测试：验证系统满足性能标准（例如响应时间）。

　验收测试工作通常由不同的用户来进行（例如：业务人员测试系统功能，技术人员测试系统性能等）。有些情况下，一些测试工作可以合并在一个测试中完成。为协调各类测试人员的工作，做好周密的计划是非常重要的。

　2.2.3 设计测试用例和数据 测试用例和数据准备的目的是帮助用户在不熟悉实际环境的时候，能正常的测试系统并对系统做出正确的评价。

　测试用例和数据的准备是一项枯燥和费时间的工作。为了提高工作效率可以从以下几方面着手：

　 将信息放在一个指定的位置，便于反复利用，降低变化产生的影响；  一次完成一个步骤，避免冗余和额外的工作；  尽早尽可能完成多个步骤。

　为了保证每一个业务流程准备测试用例和数据的正确性，在测试计划中应遵循下列过程，并完成以下步骤：

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

　（2）确定测试用例 对每一条规定验收要求，确定测试用例。每个测试用例包括测试条件（包括生成测试条件需要的测试数据类型）和期望的结果。每个测试用例都应该是唯一

　确定的（例如，赋一个数值）。

　（3）生成测试大纲 对每一种业务情况类型，生成尽可能多的测试用例来完善测试大纲。为了保证测试大纲包含所有的测试用例，将测试用例的条件映射为测试大纲是非常必要的。

　测试大纲中测试用例的顺序安排是非常重要的，它应考虑多种方面的因素，主要考虑的因素：

　按照系统产生的数据，在测试大纲中安排测试用例的顺序，使得一个测试的结果作为另一个测试前提。

　（4）编制测试脚本 在了解系统构造的情况下，将测试大纲概要作为编制测试脚本的指导。

　根据系统输入指导测试人员如何进行测试。例如，编写详细的测试步骤或给出如何进行数据输入的说明（如已经填好数据的屏幕实例）。即使没有相应的测试，也要包括每一个必要的测试步骤以便确定测试条件。确定进行测试的时间（例如，进行输入的模拟日期和期望观察输出结果的模拟日期，或对循环测试，对测试大纲进行测试的逻辑上的天数、周数、月数和年数要相当于两个月的实际时间）。

　（5）检查测试 每步测试完成后，需要利用测试计划中确定的处理步骤对测试过程进行检查（例如，检查业务情况类型、测试用例、业务情况和测试脚本）

　2.2.4 建立测试环境 为了预防出现问题，如数据损坏或对系统资源的争用，需要建立一个独立的

　测试环境。在进行测试之前，根据测试计划中确定的时机建立一个独立的测试环境。其准备工作包括：

　 技术活动：如建立不同的服务器或在一台服务器上建立多个数据库实例，将相应的程序迁移到适当的程序库中；  数据准备活动：包括加载数据表，建立用户访问权限；  建立版本控制程序，保证有效的控制对系统的修改；  建立文档控制程序，保证随着系统的修改，有效地控制文档的修改（如，培训文档、联机帮助和用户手册）。

　2.2.5 测试执行 测试执行的目的是发现不满足用户要求的任何问题，在真实的环境中，客户的工作人员按照准备好的测试大纲来对系统进行测试。

　测试过程中的测试结果是非常重要的。文档可用于：

　 检查测试的进度；  确定测试过程是否需要改进；  分析系统是否准备就绪。

　（1）集成测试 集成测试用来确认新系统中所有程序以及新系统与所有外部接口通信准确无误。集成测试还必须证明新系统能按功能说明书上的需求进行工作，且在运行环境下有效发挥功能，而不会对其他系统造成影响。

　（2）检查验收测试的进度 随着测试地进行，定期的（一般每周）收集数据。将验收进度与初始指定的

　测试计划进度进行比较，一旦发现测试计划进度的延迟，就需要马上解决。

　（3）确定验收测试过程是否需要改进 测试小组内部应定期进行交流与共享在测试过程中得到的经验，应善于接受改进建议，监测过程变化，保证达到正确的结果。验收测试小组可以定期召开小组会议或采用其它方法进行沟通。项目经理和团队成员必须以统一的方式检查每一周期的测试结果。在随后的测试周期再检查详细测试结果，确认在正常和非正常条件下每项功能是否正常执行。这在回归测试阶段尤为重要，因为同样的代码要用数据不断进行测试和再测试，直到确认所有详细测试结果正常无误。

　（4）用户认可测试 用户认可测试模拟新系统的实际运行环境，包括用户手册和程序。用户应广泛参与测试，用户可以在操作新系统方面得到非常有价值的培训。同时，程序员和设计人员还可以了解到用户对新程序的反应，这种联合参与行为有助于用户和操作人员对系统评估达成一致意见。

　（5）分析系统是否准备就绪 测试状态报告表明了系统准备的状态。项目管理人员通过经常检查未解决的问题类型状态，从而保证没有重大的问题影响系统的实现。如果判定系统未准备好，可根据测试结果来改进测试计划，改正的错误报告和改正计划必须详细说明。

　2.2.6 工程系统集成测试

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

　表：功能测试问题严重程度分类 严重程度 问题说明 A  不能提供任何系统能力；  不能完成操作或基本任务能力，但其它功能仍然可用；  影响操作完成或基本任务能力，没有替代方案。

　B  影响操作完成或基本任务能力，有替代方案。

　C  给用户或操作者带来不便或厌烦，但不影响要求的操作成或基本任务能力；  给支持人员带来不便或厌烦，但不影响工作的执行。

　D 任何其它影响或所提建议。

　显示了系统功能测试验收流程图：

　图 4 系统功能测试验收流程 功能测试：

　测试标准 测试成果 验收标准 将测试结果与测试计划和功能描述进行对照检新系统可执行程序； 功能描述； 不存在 B 及以上级别的问题。

　开始功能测试 接受验收 寻找解决方案 用户按照测试用例测试系统 将验收表交还项目协调人

　项目协调人签署递交的成果

　项目协调人将签署的标交给本公司项目经理

　存在关键或严重的问题?

　 模块递交测试已经2 周？

　 解决问题

　 已经采取纠正措施? 问题升级到验收委员会进行解决

　 采取纠正措施

　YYYNNN

　查，确定系统满足功能描述的要求。

　接口描述； 操作手册。

　可靠性测试流程图

　图 5 系统可靠性测试验收流程

　可靠性测试 测试标准 测试成果 验收标准 功能测试完成 接受验收 寻找解决方案

　用户按照测试用例测试系统 将验收表交还项目协调人

　项目协调人签署递交的成果

　项目协调人将签署的标交给项目经理

　 存在关键或严重的问题?

　超过 2 周期限?

　 解决问题

　问题得到解决? 问题升级到验收委员会进行解决

　 采取纠正措施

　YYYNNN 延长 1 周测试期限

　Y

　将系统需求与功能描述进行对照检查，确定系统是否满足功能要求；通过分析系统资源消耗来检查系统是否有效运行。

　新系统可执行程序； 功能描述； 接口描述； 操作手册。

　不存在 B 及以上级别的问题。

　图 6 系统集成测试流程 2.2.7 单元测试 2.2.2.1 单元测试计划编制 单元测试计划编制主要描述如何进行单元测试活动，如何控制单元测试活动，测试输入应用设计组（ 测试小组 ）测试小组负责人 测试人员项目经理( ( PM) ) 、 应用设计开发人员输出测试准备 实施测试 交付测试用例TS-11 搭建测试环境测试计划TS-07 编写测试计划TS-06 确定测试结束准则TS-09 设计测试用例产品设计说明书TS-05 安排进度计划测试计划产品需求说明书TS-01 指定测试负责人、分配测试人员TS-02 确定测试范围测试申请单TS-10 评审测试用例测试报告TS-04 制定测试策略项目进度表开始TS-08 评审测试计划项目计划书缺陷记录TS-03 定义测试环境TS-12 冒烟测试？TS-13 退出测试否TS-14 执行测试并提交bugTS-15 修改bugTS-16 分析缺陷TS-17 调整测试策略TS-18 调整测试用例TS-20 制定下一轮测试计划TS-19 结束测试？否TS-21 编写测试报告是TS-23 CM纳入基线管理产品基线是TS-22 编写用户手册用户手册交付包TS-24 PM确定可交付成果TS-27 取交付内容并打包TS-29 发送交付包交付清单TS-28 PPQA做交付审计TS-25 确定交付清单TS-26 PM审批交付清单项目计划书交付清单交付包TS-30 通知客户结束

　单元测试活动的流程以及单元测试活动的工作安排等。指导与规划整个测试过程，保证测试工作进行的高效有序。详细的单元测试计划编制《单元测试计划》 2.2.2.2 测试准备 项目的测试准备阶段是为测试工作的实施做准备工作，主要包括策划测试活动，设计测试用例，以及搭建测试环境。测试准备活动的详细描述如下：

　步骤 描述 TS-01 指定测试负责人及分配测试人员 测试小组负责人接到项目测试需求后，在测试团队内部指派负责该项目测试管理的负责人，并且分配相关的测试人员，并知会该项目的项目经理。

　TS-02 确定测试范围 根据《产品需求说明书》标识出待测试的产品或产品构件，明确测试的任务。测试需求体现在测试计划书中，书写在《测试计划》文档中。

　TS-03 定义测试环境 根据项目的技术方案和需求定义系统测试环境，包括系统资源环境和人力资源环境，以及确定系统测试需要的工具。

　TS-04 制定测试策略 项目负责人根据测试需求和项目计划书制定测试的策略、方法，明确测试的目标，注意事项等。

　TS-05 安排进度计划 根据项目计划，确定测试任务的时间点（里程碑）、工期、人员安排等。

　TS-06 确定测试结 测试负责人组织讨论，确定测试结束的条件。最后汇总到

　束准则 测试计划书中。

　TS-07 编写测试计划 根据上述工作确定的内容，测试负责人书写和整理本项目的测试计划。最后输出《项目测试计划》文档。

　TS-08 评审测试计划 《项目测试计划》编写完成后，测试负责人组织测试计划评审活动，主要参与人员包括：测试经理、项目经理、项目测试人员。评审通过后，测试计划才可以使用。

　TS-09 设计测试用例 测试人员根据《产品需求说明书》和《产品设计说明书》编写测试用例。

　TS-10 评审测试用例 测试用例编写完成后，测试负责人组织用例的评审活动，评审参加人员包括用例设计人员、测试人员、项目经理及开发人员，评审通过后，测试用例才可以使用。

　TS-11 搭建测试环境 由开发人员负责在执行系统测试之前需根据《测试计划》建立相应的测试环境，测试人员协助完成。主要包括主机环境、操作系统环境、数据库平台、网络环境、应用平台、测试应用发布服务器等。

　2.2.2.3 单元测试 在《测试计划》、《测试用例》评审通过，并且测试环境搭建完成后开始执行测试，过程中需要判断是否结束测试，否则一直迭代进行测试工作。测试结束后再进行测试报告和用户手册的书写。

　活动详细描述如下表所示：

　步骤 描述 TS-12 冒烟测试 测试人员接收到开发提交的测试申请后，先对系统做冒烟测试，根据冒烟测试定义的通过准则，判定是否通过冒烟测试，通过则进入下一个活动，不通过则退出测试，返回给开发。

　TS-13 退出测试 当冒烟测试不通过时则退出测试，继续等待开发处提交测试申请。

　TS-14 执行测试并提交 bug 冒烟测试通过后，测试人员正式执行测试，并记录测试过程发现的 bug，提交给开发人员。执行测试包括验证开发已经修复的bug。

　TS-15 修改 bug 开发人员对测试提交的 bug 进行调优、修复，并返回给测试人员进行验证。

　TS-16 分析缺陷 测试负责人对本次测试的缺陷进行分析，包括缺陷分布、严重等级、修复率等进行分析统计。

　TS-17 调整测试策略 根据缺陷分析的结果，测试负责人调整测试的策略。

　TS-18 调整测试用例 测试负责人根据缺陷分析结果及调整后的测试策略调整测试用例。

　TS-19 判断是否结束测试 根据测试计划定义的测试结束准则，判断是否结束测试：不能结束，则进入步骤 TS -20”制定下一轮的测试计划”；如果测试结束，则转到步骤 9 汇总编写测试报告。

　TS-20 制定下一轮 根据上次的测试结果和最新的开发进度表制定下一轮送测的测

　测试计划 试计划。然后再重复前面的测试步骤，进行下一次的迭代过程。

　TS-21 编写测试报告 完成系统测试后，汇总分析测试结果，编写测试报告。

　TS-22 编写用户手册 完成系统测试后，测试人员进行用户手册的书写。

　TS-23 纳入基线管理 配置管理人员，将测试过程的产物纳入配置库基线管理。

　2.2.2.4 测试交付 当测试结束后，项目测试经理需要判断是否可以交付产品，并提交测试报告。如果可交付则进入交付阶段，主要是列出交付的产品清单，对交付物进行打包和评审，再提交给客户。

　活动详细描述如下表所示：

　步骤 描述 TS-24 PM确定可交付成果 当测试结束后，项目经理需要判断是否可以交付成果。判断的方法可能是召开交付里程碑的评审会议。

　TS-25 确定交付清单 当确定可以交付以后，由项目经理确定交付清单内容，由测试人员书写交付清单。

　TS-26 PM审批交付清单 项目经理对交付清单进行审批。

　TS-27 取交付内容 项目经理根据交付清单，对交付的内容进行提取和打包。

　2.2.8 集成测试 2.2.8.1 集成测试计划编制 系统集成测试是描述前置交换系统的集成测试的大纲文章，主要描述如何进行集成测试活动，如何控制集成测试活动，集成测试活动的流程以及集成测试活动的工作安排等。指导与规划整个测试过程，保证测试工作进行的高效有序。

　关于详细的集成测试计划详见：《集成测试计划》 2.2.8.2 测试环境准备 集成测试原则上应尽量与应用实际环境接近，故项目测试组在搭建项目测试环境时，尽量靠近实际环境，同时考虑到系统将来的扩展性、可维护性等方面，在搭建测试环境时还需要考虑可能出现的环境。

　2.2.8.3 集成测试 在单元测试中，已将交换前置系统与省级人口健康信息平台接口、医院外部并打包 TS-28 PPQA 做交付审计 PPQA 对交付过程进行审计，并检查交付的产品。

　TS29

　发送交付包 当 PPQA 审计通过以后才由项目经理发送交付包给客户。这里的客户可能是产品的使用人，也有可能是公司的销售部。

　TS-30 通知客户 发送成功后，需要通知客户。

　系统接口等进行了测试，在集成测试阶段，需要侧重于对所有可直接追踪到用例或业务功能和业务规则的测试需求进行功能测试。在本次项目的集成测试中：采取以下几个步骤：

　1、 设计《集成测试设计用例》、采用自底向上集成测试的步骤，具体步骤说明如下：

　步骤 1：按照软件设计规格说明书，明确有哪些被测模块。在熟悉被测模块性质的基础上对被测模块进行分层，在同一层次上的测试可以并行进行，然后排出测试活动的先后关系，制定测试进度计划 步骤 2：在步骤 1 的基础上，按时间线序关系，将软件单元集成为模块，并测试在集成过程中出现的问题。这里，可能需要测试人员开发一些驱动模块来驱动集成活动中形成的被测模块。对于比较大的模块，可以先将其中的某几个软件单元集成为子模块，然后再集成为一个较大的模块。

　步骤 3：将各软件模块集成为子系统（或分系统）。检测各自子系统是否能正常工作。同样，可能需要测试人员开发少量的驱动模块来驱动被测子系统。

　步骤 4：将各子系统集成为最终用户系统，测试是否存在各分系统能否在最终用户系统中正常工作。

　2、 集成测试：组织人员按照《集成测试设计用例》测试系统集成度。

　1) 测试人员按照测试用例逐项进行测试活动,并且将测试结果填写在测试报告上；（测试报告必须覆盖所有测试用例）

　2) 测试过程中发现 Bug，将 Bug 填写在 Zentao 上发给集成部经理； （Bug状态 NEW）

　3) 对应责任人接到 Zentao 发过来的 Bug

　4) 对于明显的并且可以立刻解决的 Bug，将 Bug 发给开发人员；（Bug 状态 ASSIGNED）对于不是 Bug 的提交，集成部经理通知测试设计人员和测试人员，对相应文档进行修改; （Bug 状态 RESOLVED，决定设置为 INVALID）;对于目前无法修改的,将这个 Bug 放到下一轮次进行修改；（Bug 状态 RESOLVED，决定设置为 REMIND）

　2.2.8.4 测试交付 测试人员根据测试用例执行测试后，在测试用例表的相应栏目中记录测试结果，对异常情况填写测试异常报告单。根据不同测试结果进行测试结果反馈。

　1、反馈 Bug 给应用设计人员。

　1) 应用设计人员接到发过来的 Bug 立刻修改;（Bug 状态 RESOLVED，决定设置为 FIXED）

　2) 测试人员接到 Zentao 发过来的错误更改信息，应该逐项复测，填写新的测试报告（测试报告必须覆盖上一次中所有 REOPENED 的测试用例）； 2、可交付成品 测试结束后，经测试人员及项目测...