软件系统通用技术方案及实施方案

1目录 1.数据库建设原则 2.数据库设计 2.1数据库设计原则 2.2数据库逻辑架构设计 2.3数据库逻辑模型设计 2.4主题域模型设计 3.概念模型设计 5.数据应用流程 1.总体方案设计 1.1设计目标 1.2设计思路 1.3设计原则 1.4平台整体架构 302.软件研发方案 2.1项目启动过程 2.2需求分析 2.4设计与编码实现 2.4.1系统设计 2.4.2编码实现 2.7问题处理机制 23.功能实现方案 3.IIT基础设施包括网络及硬件平台层和数据层 3.2基础服务应用平台 3.3业务组件与表示层 3.4我司通用企业运维应用平台 3.5通用企业应用平台的结构 3.6通用企业运维应用平台的特点 3.7基于通用企业平台的运维服务 3.8核心经办业务技术架构概述 3.9核心经办业务技术架构设计 3.10技术架构中各层对象在创建过程中的依赖关系 4.功能研究 4.1软硬件基础环境 4.2研究管理流程 4.2.1项目定义 4.2.2需求分析 4.2.3项目设计 4.2.4项目研究 4.2.5项目验证 4.2.6部署上线 1.系统测试报告 2.压力测试报告 2.1压力测试报告 2.2压力测试流程 3.软件部署安装说明 3.1硬件技术要求 3.2服务器系统环境变量配置 3.3服务器安装过程说明 3.4客户端访问方式 1.项目服务要求 2.项目保密制度 3.服务宗旨 5.项目管理机构 35.1项目管理机构设置 5.3组织架构 6.1有效的管理原则 6.5实行时效工作制 6.7加强员工培训 8.1员工培训计划 8.2服务质量的监控考核 8.4人员配置原则 1.3.1定义项目成功的标准 1.3.9不要为人员安排超过他们80%的时间 41.3.11记录估算并且使用估算工具 1.3.12遵守学习曲线 1.3.13考虑意外缓冲 1.3.14录实际情况与估算情况 1.3.15只有当任务100%完成时，才认为该任务完成 1.3.16公开、公正地跟踪项目状态 1.4质量控制、质量保证方案 1.4.1项目质量管理的关键 1.4.2本项目质量保证措施 1.4.3IT项目质量管理的目标和质量控制 1.5项目验收方案 1.5.1验收目的 1.5.2验收对象 1.5.4验收方法 1.5.5验收步骤 1.5.6验收程序 1.5.7验收依据 1.5.8验收内容和标准 1.5.9验收结论 1.5.10项目交接 2.测试方案 2.1测试内容设计 2.1.1系统功能测试 2.1.2系统性能测试 2.1.3系统安全性测试 2.1.4易用性测试 2.1.5接口测试 2.1.6可扩展性测试 2.1.7兼容性测试 2.1.8用户文档检查 2222.2测试阶段规划 2.2.1单元测试 2.2.2软硬件联调测试 2.2.3集成测试 2.2.4系统测试 2.2.5验收测试 52.3测试工作流程 2.3.1各过程测试整体流程 2.3.3测试计划 2.3.4测试准备 2.3.5测试执行 2.3.6测试报告 2.4测试结果评价与测试工具 2352.4.1测试用例设计 2.4.2测试结果评估准则 2.4.3测试输出成果 2.4.4测试人员名单 3.项目风险管理 3.1风险管理过程 3.1.1风险管理计划 3.1.2项目风险的跟踪 3.2项目风险管理计划 3.3本项目风险和对策 4.1项目实施各方职责 4.2需要用户和原承建商配合的建议 4.2.1项目管理方面 4.2.2软件研发阶段 4.2.3培训组织工作 4.2.4项目验收阶段 4.3客户交互的安排 5.质量保证方案 5.1项目质量方针 5.2项目质量目标 5.3质量保证承诺 5.4项目质量范围和标准 5.4.1质量范围 5.4.2质量标准 5.4.3质量管理 5.4.4质量保证的基本思想 5.4.5软件研发过程中主要的工作活动 2615.4.6质量过程管理 6 1.项目培训手册 1.1培训部门 1.2培训要点说明 1.2.1培训目标 1.2.3项目培训计划 275 1.2.5关键用户培训计划 1.2.6最终用户培训计划 2821.2.7系统管理员培训计划 285 2.软件操作手册 3.系统运维手册 4.1项目试运行报告 4.2项目试运行计划 5.1系统变更单格式 7.3会议主题 7.4沟通时间 2.人员培训方案 72.1培训目标及理念 2.2培训方式 2.2.1实施过程中的培训 2.2.2阶段性统一培训 2.2.5培训讲师介绍 2.3培训内容 2.3.1系统管理维护人员 2.3.2卡务中心操作人员 2.3.3终端操作人员 2.3.4各个子系统的管理人员 2.3.5各个子系统的操作人员 2.3.6第三方接入研究人员 3.软件平台故障支撑计划 3.2服务内容 3.2.1咨询服务 3.2.2应用系统的故障响应 3.2.3应用系统辅助操作 3.2.4应用系统的维护服务 3.2.5交流和培训 3883.2.6应用系统业务调整 3.2.7应用系统软件升级 3.2.8支持机构 3.2.9咨询服务组 3.2.10咨询服务专家组 3.2.11支持方式 3.2.12远程登录诊断维护 4.1远程支持服务流程 4.2现场服务流程 4.3服务内容 4.4客户服务质量文件 5.应急维护方案 5.1应急预案目标 5.2应急预案具体措施 85.3应急处理流程 6.集成服务方案 6.1集成服务目标 6.2岗位分工和职责 6.3维护作业制度 6.4系统安全制度 6.5故障处理制度 6.6技术档案和原始记录的管理制度 7.现场服务方案 7.1现场组织管理策略 7.2项目管理组织体系 7.3项目组织各角色的职责 7.3.1项目领导小组 7.3.2项目指导小组 7.3.3运维总负责人 7.3.4总协调人 7.3.5项目管理组 7.3.6现场负责人 7.3.7项目软件经理 7.4现场维护管理 7.5项目管理监控 7.5.1阶段评估 7.5.2迭代评估 7.5.3状态评估 7.6.1人员策划 7.6.2人员变更 1.疫情期间应急预案 2.疫情防控教育、宣传方案 3.疫情时期车辆管理方案 5.疫情防控检查方案 7.正确使用口罩防护的方法 91.1、总体规划，建立科学、完整的信息资源管理体系整体规划，将以往分散的数据资源进行整合，建立科学、完整的信息资源体系结构，确保业务人员、技术开发人员等使用和维护信息资源的用户从整体上把握数据资源的情况，方便、准确的利用信息资源和有效的维护、管理信息资源。科学、完整的信息资源管控体系不但包括信息资源自身的完整性，科学性，也应包括信息采集、管理、共享、利用方式的规划，以及数据模型、数据指标等规范化、标准化的考虑。1.2、统一规划、集中管理各类信息资源统一规划数据资源，不只是要对各类信息资源进行物理集中存储管理，还要在对业务数据分析的基础上，一体化规划并设统一制定业务数据指标体系，以管理服务对象为核心，组织相关联的业务数据，实现对内业务使用、对外服务应用的统一视图。设计集中、统一的数据库服务系统，实现信息资源的集中存储、集中处理、集中管理、集中服务，并保障数据的一致性，降低数据交换、系统内共享使用复杂性。1.3、按照业务需要规划主题数据以面向管理服务对象的业务主题设计为核心，依据管理的业务管理范围和业务管理要点，建立面向管理服务对象、面向业务管理、面向公共服务、面向决策支持等的多个主题数据库，并以面向管理服务对象的主题数据库为核心来建设。1.4、通过数据集成和数据交换实现数据共享利用数据资源的共享是数据资源体系设计的主要目标之一。对内，通过数据集成实现数据共享；对外，通过数据交换实现数据共享。分析系统内、外的数据共享、交换需求，规划统一数据共享、交换数据区域，提供标设计数据管理服务中心应用系统，统一规划数据的获取、操作、展现、管理、服务等处理。同时解决数据综合利用问题，以及数据深加工利用。支持业务宏观、微观决策分析。1.6、数据模型设计具有较高的可扩展性随着业务不断发展和数据应用的不断深入，必然要产生新的业务指标和新的系统数据。数据模型(包括概念模型、系统数据模型)的设计要保证能适应这种变化，在指标体系变化时或业务内容增加时，尽可能不用修改各类数据表的结构。2.数据库设计2.1数据库设计原则整体性间的数据结构的整体性，投标方将按照EDM(企业级数据模型)的方法，全面性2.2数据库逻辑架构设计换数据、内部交换数据、业务机构交换数据(各级智慧系统与同级部门的元数据是描述数据及其环境的数据，主要包括各类系统使用的共享元数据和各类系统自主元数据。2.4主题域模型设计主题数据库是经科学规划，面向业务主题的数据组织存储形式。主题库的结构设计与应用处理过程相分离，能有效实现数据的关联和共享，降低大型信息系统的开发和维护成本。系统设计中一般有三类主题组织形式：面向业务管理的数据主题按照业务领域建立业务主题。面向管理服务对象的数据主题按照管理服务对象来组织相关数。决策分析主题按照决策分析需求组织数据，例如：辖区经济秩序评价主题、企业信用分类主题、人员绩效考核主题。三者之间的关系如下图：信息系统设计基本采用面向对象的信息工程方法，数据分析与规划也与此相适应，以面向管理服务对象的业务主题设计为核心，开展主题库模主题数据库模型设计将管理业务数据主题分为三类，共23个业务主题管理服务对象主题是以管理的主要管理服务对象为核心，把该对象的状态和管理信息集中起来，能方便直观的掌握管理服务对象的信息全貌，公共业务实体主题是将业务处理过程中的公共信息实体进行整合，有其它业务管理主题是指现阶段没有完全抽象成管理服务对象和公共业存在部分业务是以管理过程为核心或者还不太稳定，不便于也没有必要完全以对象为核心来组织数据主题，另一方面也是为了突出重点，更好的完成管理核心业务对象的设计。被保留的业务管理主题在主题细分和应用设计时仍然可采用面向对象的设计方法。概念数据模型反映用户综合性信息需求，一般采用主题库名称及其内容(简单数据项或复合数据项)的列表来表达。主题库逻辑模型设计是从系统分析人员的视角，对概念数据模型的进一步分解和细化，一个逻辑主题库由一组规范化的基本表构成。基本表是按规范化的理论和方法建立起来的数据结构，一般要考虑达到第三范式的在信息化总规阶段，本设计报告只对主题库逻辑模型进行初步设计，不具体设计描述数据项，采用“简化E-R图”的方式，用长方框代表“基本表",用向后缩进排列代表"下一级"基本表。基本表和下级基本表的对应关系一般为“一对多”,省略关系联线。对不同主题中基本表之间的关系和联系，本设计采用虚线长方框加关联说明的描述方式。主要有两种表现形式。表现形式一：基本表加向后缩进一级的虚框关联表。例如：说明企业基本信息表与网格主题中地理网格信息表是存在关联关系的(即企业基本信息表中存在地理网格ID这一外键字段),通过关联来说明企业所在地的地址网格信息。表现形式二：基本表注明“XX基本信息”随后紧跟同级的虚框关联表“XX信息”。说明本主题需要记录部分业务信息，但更多详细信息可以到相关主题中去查询。例如：信息件基本信息涉及主体基本信息涉及主体信息(关联到航船主体相关信说明信息件主题中存在"涉及主体基本信息"表，涉及主体的详细信息可以关联到业务主体主题中去继续查询。出现这种情况表明两个主题存在一定的数据冗余，但这也是正常业务的特性造成的，即信息件涉及的主体可能不是本地注册的业务主体，甚至可能是未注册的主体，实际信息处理时只能先到主体信息表中查询，如果找到则自动关联引用，如果找不到则手工录入。数据应用的总体流程如下所示：1根据应用需要，以及数据库的规划，将数据应用分为操作型数据处理、分析型数据处理。分析型数据处理主要是针对OLAP类型的应特征和OLTP系统的部分特征，它是“面向主题的、集成概念。一家企业的实体数据指通过历次申请沉淀，集成各类附加信息，反映企业当前情况的数据。此例反映出ODS数据由操作型数据不断更新，面向主题，当前或接近当前并且不断变化的特征。通过此例，也反映出对于ODS的应用特点包括：在业务系统和数据仓库之间形成一个隔离层智慧业务数据仓库应用具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。转移一部分业务系统细节查询的功能在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。例如，对统计概念"本期设立",其主要来源于操作数据，而统计概念"期末实有"则可根据企业状态，自ODS数据产出。完成数据仓库中不能完成的一些功能带有ODS的数据仓库体系结构中，数据仓库层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS,但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数由于操作型数据不直接产生，而需要经过筛选才能产生ODS数据。例如，企业的ODS数据中不需要业务申请的办理人、办理过程，因为其不直接反映企业现状，这个筛选过程被称为ETL过程(采集、转换、传输、装载)。通过分析型数据处理的数据ETL过程(采集、转换、传输、装载)将各类业务数据资源归集到数据中心的ODS数据中。ODS本身可以提供主题数据，通过ODS数据的加工处理(统计定制和模型建立),可形成各类统计分析数据。五类系统管理功能：(1)描述哪些数据在数据仓库中；(2)定义要进入数据仓库中的数据和从数据仓库中产生的数据；(3)记录根据业务事件发生而随之进行的数据抽取工作时间安排；(4)记录并检测系统数据一致性的要求和执行情况；(5)衡量数据质量。二、系统设计方案1.1设计目标在现有信息化系统进行有效整合基础上，借鉴新一代的应用技术体系，实现对管理要素的全面感知、有效传输和按需定制服务，为行政管理人员和相关单位及人员提供高效的管理辅助，并为公众提供便捷、实时的信息1.2设计思路根据项目的建设目标和系统的总体框架、设计思路、建设内容及保障采用“全面整合、重点补充、突出共享、逐步完善”策略，加强重点区域或运输通道交通基础设施、运载装备、运行环境的监测监控，完善运行协以"统筹协调、综合监管"为目标，以提供综合、动态、实时、准确、实用的安全畅通和应急数据共享为核心，围绕“保畅通、抓安全、促应急”系统充分整合和利用业务管理部门现有相关信息资源，以信息技术、网络视频技术、互联网技术、移动通信技术、云计算技术为支撑，结合业务管理与数据交换平台，构建业务与各部门之间智慧、畅通、安全、高效系统充分考虑业务安全及安全职责今后的变化与发展趋势，应用目前主流的、成熟的应用技术，内联外引，优势互补，使系统建设具备良好的1.3设计原则结合本系统建设要求，需要保证各系统的完整性和功能的实用性，在保证平台运行稳定运行和数据提供准确迅速的同时，界面简单实用，系统在本次系统的建设过程中，系统实施和业务模型的建立严格贴合业务管理实际，且充分考虑业务管理部门内部管理的需求特点，本系统将有力的辅助完成公文流转、管用互动和事务管理，有效实现与其相关联系统的数据共享与数据交互，增强系统可实施性。同时系统操作简单、快捷，具有良好的人机交互界面，易于使用推广，且维护方便；此外系统良好的人机接口与灵活多样的展现方式，还能提高用户的查询效率，并做到快速响在系统功能划分模块化设计，预留了发展余地，系统结构设计、系统配置、系统管理方式等方面采用国际上先进同时又是成熟、实用的技术；系统设计所采用的技术和设备符合国际标准、国家标准和业界标准，在系统架构设计上充分考虑到各接口的开放性和可扩展性，满足用户根据信息系统采用先进的系统结构和技术措施，采用成熟的开发手段，具有良好的可靠性，能有效的避免单点失败，关键设备和部件采用冗余配置，能建立各种故障的快速恢复机制，确保系统7×24小时地正常运转，在技术服务和维护响应上同用户积极配合，确保系统的可靠，保证数据指标完整系统在系统级、应用级、网络级提供各自的安全手段和措施，为系统提供全方位、立体化的安全实施方案，以便合法用户能够随时得到所需要的数据支持，系统提供高安全度防护手段，防止内部用户的非法入侵以及操作人员的越级操作，非法用户则无法接触有权限的数据，保护信息的机密，所有应用项目和软硬件都遵守国家保密条例，符合国家有关电子政务系统安全要求，具备较强的自我保护机制，以便能有效抵御各种恶意攻击，管理业务及其管理模式将随着社会的发展而不断的变化，与此相对应的是，安全畅通与应急处置的需求也将不断拓展，管理部门将不断产生新的需求。在此情况下，本次系统建设不可能一步到位，这就需要在发展过程中不断完善。因此系统软件体系结构设计上支持大数据量的扩展，以能够适应业务的不断发展和用户规模的扩大，具体设计方式如下：(1)定时清理数据，可以通过使用触发器或者带存储过程的作业来实现定时清理数据业务；(2)利用数据的转换与提取，定期用程序或用事务复制导入原始/汇总数据，把数据复制到一台专门做统计的服务器上，专门做查询所用；查询的时候做相应的优化，例如索引，视图等这样查询的时候压力就会小很多；同时考虑负载平衡，在空隙时利用其CPU和内存；(3)各业务系统和外部数据源传送的数据为维系挽留系统输入，这些数据分别经过数据格式检查；源数据清洗抽取转换、装载数据到收集层；对收集层中数据抽取、转换、装载到数据仓库；数据仓库中数据进行抽取、转换并结合模型算法库中的算法生成维系结果集以供输出；同时通过数据仓库接口，可将数据提供给应用系统的本地化查询使用；(4)划分存储硬盘把数据、日志、索引分盘存放，这样可以提高I0吞吐率用优化器，优化查询。系统的各种接口满足开放和标准化原则。所有系统设备不但满足当前需要，并在扩充模块后满足可预见将来需求，保证建设完成后的系统在向新的技术升级时，能保护现有的投资。1.4平台整体架构系统总体架构严格遵循安全性、共享性、扩充性、可维护性、可兼容性的开发原则；平台建成后，将会有大量的工作人员及船舶公司、商户等同时在线使用。因此在整个平台建设时，将进行良好的规划及架构设计；同时，为了适应未来项目的新增和变更，平台将具有足够的柔性，可通过简单配置和二次开发适应新的需求。在本次中也包括部分软件研发工作，按招标文件要求我公司将组织后台研发人力资源，现场技术人员与后端支持按照研发和维护服务要求配置资源，主要研发人员要培养后备力量，防止人员变动影响服务质量，确保软件研发和维护工作按计划顺利完成。我公司经过多年的研发实践，根据自己的业务特点，形成自己的项目研发实施过程，可分为八个阶段，即项目启动、需求分析、原型研发与策划、设计与编码实现、测试、安装实施、总结验收和运行维护。每个阶段对应着不同的活动内容和工作任务。在中我公司将按照研发实施过程，根据软件升级的需求和升级软件的规模适当的裁剪和简化研发过程，达到系统升级稳定快速上线运行要求。项目升级内容工作量少于30个工作人日，通过软件《变更请求单》,对需求变更进行描述，并由相关主管人员对变更内容进行确认后，安排研发人员进行研发，详细流程见系统维护流程；工作量高于30个工作人日，建议进行正式需求调研，调研与需求分析的任务主要是获取用户需求，分析用户需求特点和要求，形成系统需求，作为项目研发工作的基准。我公司的软件研发方案简单介绍如下：2.1项目启动过程软件研发启动过程意味着项目组正式成立，本公司领导在内部项目启动会上任命软件研发负责人，激励项目组成员，并介绍项目和客户背景，以便项目组顺利开展工作。如果软件研发内容较多，影响范围较大，根据情况最好召开现场启动会，现场启动会议建议由客户方领导组织项目成员和相关人员参加，是一个项目正式开始的动员会，宣告项目启动，明确各方责任，说明注意事项，并要求所有相关人员和部门配合项目开展。我公司项目负责人简要介绍研发实施的过程和方法。对于业务部门提出的应用软件研发需求，由现场工程师与业务部门进行沟通，了解业务部门对应用软件的研发需求，形成需求文档，经相关部首先需要经双方协调，制定《需求调研计划》及《需求调研大纲》,确定准备工作、需求调研的内容、方法方式以及人员和日程安排等内容，用户也须做好准备工作，经双方同意后按此计划开始调研。调研正式开始按调研计划的进度进行现场调研，主要任务是用业务语言描述客户需求。尽可能及早落实主要算法，确定关键参数，掌握客户政策文件，收集需要打印的报表等。每天应将当天调研的内容整理成文档，并及时与用户确认，提高工作效率。及时将访谈记录、用户政策材料整理成规范格式的需求分析报告，向客户项目组长汇报调研结果，共同对需求分析报告内容进行确认。同时明确今后需求变更控制的规程需求变更控制流程。对于调研期间未落实的问题，以待明确问题的形式体现在需求报告中，并确定落项目研发组根据调研编写《系统需求分析报告》,并由项目组评审，不合格的部分进一步完善调研；评审通过后由双方共同签署评审意见，并对于软件生产过程而言，需求阶段是整个过程中最重要的阶段，需求分析成果的好坏将直接导致项目的成功与否。评审通过后的需求报告将成为系统的设计、研发、测试、实施、试运行和项目验收的基本依据之一，因此原则上用户需求将不再因为其它因素的改变而变更，如需进行此种变更，需经双方项目负责人协商确定。研发组与客户一起制定总体项目计划，共同确定本项目的各项工作进度安排，明确每一阶段的工作内容，以及需要用户配合完成的具体工作。需求调研结束后，根据当前掌握的项目信息进行项目研发过程的策划，软件研发组对用户需求进行深入分析，并和我公司项目原型库各原型进行对比分析，选出和本项目模式接近的复用源作为原型，以便能快速架构和研发出符合本项目特点的稳定适用的原型系统。必要时给项目组成员培训原型系统。将系统需求各部分功能进行分解，估算分解后各子功能的根据各成员的特长和业务发展方向分配任务。将研发过程分为几个阶段，把某些重要任务的完成作为检查点。根据任务划分结果制定研发计划进度表，并标记出各阶段检查点，作为项目跟踪监控的依据。研发计划要符合公司的模板模范，并与前面提到的总体项目计划保持一致，不可预知事务建议采用日程表记录，不再制定计划。《项目研发计划》制定出来后，要提交给部门进行评审和风险分析，评审通过后纳入配置管理。研发计划一般作为研发过程进度安排，在执行中根据实际情况变化应及时调整修改计划，并将实际执行结果与最初的计划相比较，作为考评研发负责人的一项内容。研发计划进度表参见《软件执行中参照的规程或标准：本公司质量体系文件《软件需求管理规2.4设计与编码实现项目经理召集项目组全体成员一起讨论和明确系统设计、数据结构、每个人的工作内容、各部分之间的接口关联等。做到每个项目组成员对项目的总体情况、整体工作目标和个人工作目标、工作时间、与其他人的关系、工作的方式方法等都有个清晰的概念，为项目的顺利开展及项目组成应全面考虑调研时用户提出的每个功能模块，研发出的程序应贴近用户需求，研发人员应从用户的角度来考虑问题。做到定期检查和总结，来项目研发组通过对系统的功能、运行和性能要求加以分析，产生一个高层次的系统结构、软件结构、接口和数据格式的设计，形成《系统设计报告》(其中包括数据库设计),提交项目组评审。对其中评审不合格的部分进一步完善和重新策划，评审通过后，作为后续软件研发和测试的基础。根据系统设计输出结果和公司编码规范的要求进行代码编写，实现软件功能。制定二级研发计划，作为软件编码阶段的项目管理和监控依据，项目研发小组要严格据此计划控制项目进度，按时向工程领导小组汇报工作进展。为保证质量软件研发组应每周进行代码审查，提前发现问题，减为了使用户能够及时获知项目的进展情况，研发小组向客户项目组长或相关领导提交项目周报。在编码实现过程中，也欢迎客户业务和技术负2.5系统测试测试是检验软件研发结果质量的重要手段之一，根据阶段不同，可将首先是单元测试，侧重于核实软件的最小可测试元素。单元可以是一个窗口(窗体),也可以是一个函数、菜单、报表或一个存储过程。单元测试应对单元内所有重要的控制路径设计测试用例，以便发现单元内部的集成测试是把通过单元测试的各个模块组装在一起之后，按设计要求进行的测试，以便发现与接口有关的各种错误，保证系统的初步正确和稳系统测试在单元测试和集成测试后，基于系统的整体需求说明书而对根据测试的内容和侧重点不同又可将测试分为：功能测试、性能测试功能测试是对软件系统的功能需求进行的测试。主要暴露由于系统说性能测试是为描述测试对象与性能相关的特征并对其进行评价，而实施和执行的一类测试，如描述和评价计时配置文件、执行流、响应时间以及操作的可靠性和限制等特征。包括负载测试、强度测试、并发测试、恢1)负载测试：核实在保持配置不变的情况下，测试对象在不同操作条件(如不同用户数、事务数等)下性能行为的可接受性；2)压力测试：核实测试对象性能行为在异常或极端条件(如资源减少或用户数过多)之下的可接受性；3)并发操作测试：核实测试对象在处理多个并发请求时的可接受4)恢复测试：恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。通过加强性能测试提高软件可靠性，使系统每年中断工作次数不超过3次，累计时间不超过1小时。安全性测试是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时的表现。测试人员在软件研发过程中开始编写测试用例和测试大纲，根据制定的《测试计划》,在软件功能模块完成后，根据需求和设计结果的要求对软件进行测试，填写《测试问题卡》,并进行测试总结编制《测试总结报告》,对测试所发现的问题进行追踪修改和确认测试，直到彻底修改完成并对其它模块没有任何影响。测试过程尽量能够模拟用户环境测试几个周期。测试组测试时，研发人员应密切配合，及时改正测试出的问题，对问题应做备忘录，以便将来查询。测试资料作为项目验收的重要内容之一。为加快项目进度，建议用户方测试组及早介入测试，最晚也应在我方的系统测试完成之前介入，并按事先双方约定的规范方式进行测试。2.6总结验收验收分两个阶段：安装运行前的用户测试；系统正式运行后的实际业务操作的检验。系统运行满足约定时间后，进行软件的验收工作。验收前和用户沟通好验收的时间和方式，制定验收计划，列出模块清单，并且安排好每个模块验收的时间段，按照这个时间列表与用户逐个模块验收。双方事先商定验收过程要求及参加人员，必要时邀请行业专家和相关领导参软件验收以符合需求分析、业务要求作为验收标准。验收结果说明软件满足下列要求：符合通过审核的需求和设计文档中表述的功能要求，以问题处理：将验收过程中发现的所有错误都必须记录下来；对错误进行分类和确定级别；报告的错误得到修改/处理，或修改错误的计划得到验收工作建议由用户相关部门组织的专家组对软件系统进行全面的验收和鉴定，并出具项目验收小组领导签字的项目验收报告，并签署验收意2.7问题处理机制对运行中的系统进行维护时，要严格按流程操作，以防带来意想不到的后果。系统维护一个很重要的事情就是我们要与用户沟通好工作的方式系统我司计划采用当下流行的微服务架构，各业务应用分别注册在云平台及现场服务中，模型服务对应模型数据及围绕模型的业务逻辑，各业流程引擎、表单引擎、公文交换平台是系统的三大核心组件。系统采表单引擎有丰富的资源库，便捷的画布设计、自由拖拽组合，支持快速流程模板配置，真正意义实现千人千面页面展示效果。表单引擎架构图表单控件表单控件富文本、单选多选择地址本选择、公式表单扩展层控件设计扩展控件展现扩展控件生成扩展控件解析扩展控件导入扩展集成辅助控件表单应用功能布局控件表、表格操作(增、删、插入等操作)。系统数据库具有灵活的系统兼容性和伸缩性，可灵活接入其他系统，是一个实用、高效、安全的平台。其采用安全的数据交换技术实现平行文、下行文、上行文的公文交换。网络及硬件平台包括网络设备、服务器主机、操作系统、存储设备等资源，是应用软件开发、运行的基础平台。网络平台层的构成具有个性化的特征，不同的应用环境具有不同的主机设备、不同的网络设备、不同的存储介质、不同的操作系统。因此这要求建立在网络平台层之上的应用支撑平台层必须具备跨平台的特性，只有这样才可延伸原有资源的生命周期，避免硬件设施的重复投资。我司的统一电子解决方案框架平台是基于J2EE技术建设的，因此系统具备跨操作系统的特性，从而可最大程度地保护用户的使用。其中应用服务器中间件采用BEAWeblogic中间件，数据库采用3.2基础服务应用平台应用支撑平台层起到保证事务完整性、响应大规模并发处理、支持异构系统的互联，并对应用数据的安全性进行保障，是三层结构不可或缺的重要组成部分。本系统采用BEAWeblogicPlatform、BEATUXEDO为J2EE应用服务器和消息/中间件。业务支撑平台层是多层架构业务系统的核心支撑部分。我司的业务支撑平台以J2EE应用服务器和消息中间件为核心依托，包括我司自主版权的通用中间件产品。三层框架开发平台，为实现业务应用的快速开发提供了动力和保障；工作流平台，用于管理业务系统易变的流程；数据交换平台，用于数据传输和数据转换以及应用系统集成；消息平台，主要用于公共服务系统中将手机、语音等多种渠道的消息统一成一种消息。业务支撑平台将各系统中的共性功能抽象、封装并统一解决，提供丰富的功能组件，使用开发人员可以将主要精力集成在业务逻辑，而不是复杂的技术实现。业务支撑平台是我司的核心企业应用平台，在今后的运维服务系统开发中，我公司也将充分利用该开发平台的优势，利用平台中的一系列的组件和工具以及相应的开发方法，进而达到快速建设应用系统的根本目的。3.3业务组件与表示层业务逻辑层实现了应用系统所有的业务组件，业务组件基于应用支撑层进行构建开发，并且业务组件设计开发遵循“高内聚、低偶合”的思想，使业务组件之间可以保持相对独立，并且通过表示层个性化定制业务组件。用户通过系统表示层实现对业务系统的操作与交互，系统表示层设计遵循操作方式简便、灵活、友好；操作界面设计风格统一，符合业务办理流程规范，便于操作员学习掌握等标准进行设计，并可以根据每个用户使用特点和角色的不同，形成个性化的应用界面。表示层提供业务展现、内3.4我司通用企业运维应用平台本次开发基于我司自主研发的通用企业应用平台进行运维。下面对通如果从更广义的角度来讲，又称为“组件框架”,即Component技术实现模型的多层应用开发、运行的框架和平台。它不仅仅是一个框架它还提供了一系列的组件和工具以及相应的开发方法，进而达到快速建设应用系统的根本目的。它是一个基于组件技术的快速开发和运行平台，它统一的业务逻辑层种体系结构共用统一的业务逻辑层种体系结构共用同一套业务逻辑处理服务，只是表现和控制层不同。大、灵活易用的功能组件。既支持C/S/S结构也支持B/S/S结构，其中两通用应用平台在整体框架上采用典型的MVC模式，集中了大量功能强工作流服务DefinesU商业逻辑层以EJB/JavaBean技术为实现手段，提供了对象持久化等商业逻辑组件。设计要点如下：2.通过统一的服务组件基类调用安全、日志、工作流、规则等引擎3.在管理管理信息系统中对象持久化是一个关键性服务，单一的数据库接口解决全部问题并不现实，因此采用由OP层统一包装，统一管理，但暴露多种操作接口的方式来解决。对象持久化接口提供面向对象和面向过程两大类，具体支持四种方式：1)得到connection2)简单的sqlexecute封装3)可持久化的数据总线DataSet,通过其xml接口可发送到页面)4)DAO(单表抽成的可持久化的实体类对象)平台在商业逻辑层还提供了许多通用业务组件，如打印、报表组件。C/S/S结构的视图层和控制层"工厂”模式来获取服务组件对象的。这样做的好处是可以以透明的方式任务分发环节Event调用业务逻辑服务组件时，是通用BSFactory"工厂”模式来获取服务组件对象的。这样做的好处是可以以透明的方式任务分发环节Event调用业务逻辑服务组件时，是通用BSFactory利用业务逻辑层采用我公司统一的通用企业应用平台，所以在控制层最后一道套经过验证是健壮稳定的架构。与系统核心平台二版略有不同的是：由于C/S/S结构的框架设计基本上采用系统核心平台二版的结构，这是一古《《接口>《《接口>请求入口转换层DCM(数据控制管理层)数DAO(数据访问对象)处理EJB和JavaBean的服务对象。C/S/S结构中客户端的设计要点是：1.GUI采用传统的Window界面，以Delphi为开发工具；2.客户端通过统一的动态库函数与服务端的门户MainServlet通讯，通讯的内容以XML为数据格式，整个通讯协议完全模拟SOAP协议；3.客户端的设计在分层基础上对类进行了适当的归类。做到类之间的调用关系明确。类的责任单一。类之间的依赖关系简单。编程实现较为方便。下面简略的介绍一下编程常用的调用关系。为了说明上的方便，图中把框架完成的调用关系去掉了。调用关系简图如下：SieafSieaf.dl1ServerServerDCMC/S/S结构中控制层的设计要点是：1.整个控制层的设计思路参考B/S/S结构中的Struts框架。MainServletStrutsActionServletRequstEvent可映射到Struts的Action;2.但与Struts不同的是它与客户端之间传递的均是XML,没有表现语义，因此它要增加XML信息过滤器、转换器等功能；B/S/S结构的视图层和控制层设计界面层以JSP/XML界面层以JSP/XML/XSL/JS技术为主要实现手段，为系统开发提供了系列功能强大的组件，主要有以下几大类：一卤web.xml请求校验及格式化客户端请求接口请求入口HT[P(S)请求ActionServletHTTP(S)回应1.轻型控件：封装所有的HTMLForm元素和按钮，提供显示、标准3.局部刷新和对话框：采用微软提供的局部刷新控件，提供局部请求控制层以Servlet技术为实现手段，综合运用struts框架和2.组织机构和权限管理模块进行身份和权限认证，从视图、操作、在流程多变的业务系统中用3.6通用企业运维应用平台的特点1)采用了三层结构的技术框架，为应用系统提供了一个非常良好的结构，应用系统将来的升级、扩充、修改和定制都非常方便。当用户需要发生变化或需要对某个功能进行修改的时候，可能只需要对某一个层次的组件进行修改，而不会对整个系统的结构发生影响。2)支持WWW技术，允许用户通过WWW浏览器来操作。简化了系统安装和维护的难度，降低安装和维护的成本，由于界面操作风格一致、操作简单，也降低了对用户培训的要求。另外，由于支持WWW技术，为将来支持其他的客户端和移动用户也提供了技术上的可能。3)提供了最基本的系统组件，如用户管理、权限管理、组织机构管理、工作流管理、菜单管理、数据库管理等功能，简化了应用系统开发的过程，提高了工作效率。而且在将来应用系统开发的过程中，也可以提取和积累各种通用组件，增强系统功能。4)实现了界面层和数据层的统一管理，在应用系统的开发过程中，不需要对界面层和数据层进行编码，只需要通过系统工具对界面层和数据层对象进行定义即可。这样不仅简化了开发过程、提高了开发效率，而且在界面层和数据层需求发生变化和需要重新定制的时候，可以通过简单地修改界面层和数据层的进行来完成。5)基于应用框架，应用系统开发员可以集中精力开发业务层组件，不需要过多地考虑各种技术问题和其他方面的实现细节，也提高了业务层组件的独立性，减少与其他模块的关联，便于将来扩充、升级和修改。6)提供了一个统一的界面层，该界面层包括菜单管理、视图管理、界面权限管理、界面操作逻辑管理、界面元素自动生成等功能。应用系统开发员只需要定义好自己的界面层对象，不需要把精力花费在界面逻辑和界面操作的实现上，简化应用系统开发的过程，而且所有基于UniEAP的应用系统界面风格一致、统一管理、操作方便，方便了用户学习和使用，也降低了培训和维护的费用。7)提供了一个通用的数据层，业务系统不需要重新开发，只需要定义自己的数据层对象，因次简化了应用系统的开发过程。8)从界面层到数据层，都充分体现了业务对象之间的各种关系(一对一、一对多、多对多等),并且提供了充分的实现手段，使得应用系统实现业务对象之间的复杂的逻辑关系成为可能，而且非常简单。方便了业9)在很多方面提供了通用的模式和技术规范，如组件设计、数据库设计、界面设计等，可以为应用系统的开发提供有效的指导和参考。由于本此项目系统的的设计和开发我司未进行参加、因此本次运维我司自主研发的通用企业应用平台进行运维，所有我司有信心做好采购方软提供了统一的模式和共享组件，降低了系统间的耦合度、减少了应用系统开发的模块，因而能够准确地控制应用系统开发的过程，有效地提高按招标文件要求对于采购单位提出的应用软件升级需求，由现场工程师与采购单位业务部门进行沟通，了解业务部门对应用软件的升级需求，按双方商定的开发进度进行开发和实施。采用组件技术，系统具有非常好的可扩充性，对新技术的发展也具有很好的适应性。这是因为采用了组件技术后，可以开发出各种共享组件和通用组件，也可以集成第三方开发的组件，组件的升级也非常方便，而且随着组件技术的标准化，不同的组件标准之间也可以实现通讯，因而无论采用哪种组件标准都具有可扩充性和因此，应用升级中，对系统平台充分了解的情况下，能够较准确的规避升级过程中的技术难点，提出多种适合劳动保障系统的升级方案，能够较准确的根据企业平台的特点估计工作量，对升级时间进度准确把握，让另外，由于由于采用了组件技术，提供了很强的可定制能力，因而应用系统能够在此基础上能够建立面向具体行业的业务模型，在每一次为具体用户定制业务系统的时候，都可以积累经验，提高业务模型的通用性，以便适应更加广泛的用户需求。软件系统将涉及系统等多个分公司及与其他相关公司和内部系统的接口，软硬件基础设施复杂，因此在系统的实现上必须采用标准的技术，以求跨操作系统平台、跨数据库平台、跨中间件平台。基于此本公司在整体技术实现路线上采用基于J2EE和webservice组件的技术构建应用逻辑。应用逻辑层和公用服务层的每个功能模块均是一个相对独立的组件，这些组件的开发和部署保持相对的独立性，而且在未来很可能是由不同的团队开发和部署的，也是可以相对独立的进化的。每个组件通过定义良好的接口，向外部提供服务。这些服务的获取者可能来自客户端、可能来自其他组件。这种基于组件的设计可以达到比较好的重用性。在J2EE的架构下，各组件通过J2EE标准定义的RMI协议，向各客户组件提供服务。业务操作员及公众信息查询人员通过标准的HTTP协议或安全的HTTPS协议访问系统管理信息系统及公共服务系统。公用服务层同样以组件的方式实现，可以与业务逻辑的组件的部署在同一应用服务器上，也可以部署在不同的服务器上。如果业务逻辑层的组件和公用服务层的组件驻留在同一进程空间中，则通过对象间的消息机制通讯，如果驻留在不同的进程空间中，则通过标准的RMI-IIOP的协议通在管理信息系统中，最重要，难度最大的是数据操作的实现策略，因为在任何一个管理信息系统中"信息"都是系统的核心，几乎每一个业务逻辑都与数据操作相关，因此本方案将对数据操作的实现策略进行详细阐持久性(Beanmanagedpersistence),也即组件自行管理数据库操作的完整性和一致性；另一种EJB容器管理的持久性(ContainerManagedPersistence),也即通过J2EE的应用服务器提供的对数据库操作的服务。考虑到性能和负载方面的因素，我们建议采用结合事务处理服务器和组件管理的持久性的方式，管理对数据源的操作。介于业务逻辑层和数据服务器之间的是事务处理服务器，处理服务器负责处理实际的对数据源的操作，保证多个数据读写请求对多数据源的操作的原子性、一致性、隔离性和持久性。同时通过处理服务器，进一步降低业务逻辑层和数据源之间的耦合度。逻辑架构中的服务和查询处理服务均驻留在事务处理服务器上，操作数据库，保证的完整性和查询的性能。J2EE组件与事务处理服务器通讯的机制，与事务处理服务器的平台和应用服务器的平台有关。事务处理服务器一般需要在数据库服务器上安装相应的组件，通过紧密集成的数据库访问机制，访问数据库。介于处理服务器和业务逻辑层之间的是公用的数据存取服务，这一层封装业务逻辑和公用服务层其他组件对各种数据源的读写操作，直接管理与数据库、目录服务器、应用集成服务器之间的数据交换请求，进一步降纯文本文件等。这样存在如下缺点，即访问这些系统的API很不统一。组件通常使用私有的API来访问外部或遗产系统，以便于检索和存到影响。组件需要透明于实际的持久性存储或者数据源实现，以便于提供装图-1实现示意图其中业务对象代表数据客户端，该对象需要访问数据源以获取和存储数据。数据存储对象是数据存取服务的主要对象，数据存储对象封装业务对象对数据源的访问，以保证对数据源的透明访问，业务对象也把数据加载和存储操作委托给数据存取对象。事务处理服务负责完成对数据对象的实际存储和加载的工作，应用集成服务实际完成将数据发布到外部系统以及从外部系统读取数据的职能。值对象代表用作数据携带的值对象。数据存取对象可能使用值对象来把数据返回给客户端。数据存取对象也可能使用值对象接受来自于客户端的数据，并更新数据源中的数据。下面的时序图表示使用数据存取对象读取数据库数据、更新数据库数图-2过程示意图业务对象负责完成应用逻辑的处理，通过数据存取对象向事务处理服务器发出读取数据的请求，事务处理服务器将数据为了运维本套系统，我司在本项目应用软件系统中综合利用核心平台的架构特点，基于核心平台进行运维，设计实现基础服务应用平台，在此平台基础上构建可拆可合、可配置的业务组件。下面对其结构、功能和特点进行简要介绍。基础服务应用平台，如果从更广义的角度来讲，又称为"组件框架",是构建于多层架构的，以J2EE规范为核心技术实现模型的多层应用开发、运行的框架和平台。它不仅仅是一个框架，它还提供了一系列的组件和工具以及相应的开发方法，进而达到快速建设应用系统的根本目的。基础服务应用平台不是ApplicationServer,它与BEAWeblogicApplicationServer、Tomcat、JBOSS均不属于同等性质产品。它是一个基于组件技术的快速开发和运行平台，它的部分组件最终同业务应用组件一起部署到ApplicationServer上。Rep0StMgmt0ry基础服务应用平台的结构简图如上图所示，各组成部分的功能及职责GUI:用户界面层呈现用户交互界面提供表现控件界面控件布局控制界面的表现，包括具体的设备和与设备相应的UI的控制。功能限于界面的具体在设备上的展现(如：Browser对html的解析)、界面表现的控制、界面组件的布局。InteractionControl:交互控制层定义业务逻辑的逻辑表单开启和关闭事务响应用户界面层的业务请求图-3架构简图局部刷新和对话框：采用微软提供的局部刷新控件，提供局部刷新功1)得到connection2)简单的sqlexecute封装3)可持久化的数据总线DataSet,通过其xml接口可发送到页面)4)DAO(单表抽成的可持久化的实体类对象)平台在商业逻辑层还提供了许多通用业务组件，如打印、报表组件。基础服务应用平台在逻辑服务组件上借鉴Spring的实现机制，采用类似WebService的UDDI所定ServiceRequestorServiceRegistryServiceProvi式，所有发布的InteractionObject都在InteractionObjectFactory中注册，且可以同时存在多个Provider(如在J2EE体系中就存在JavaBean、EBJ、WebService三种典型的Provide)。Action相当于ServiceRequestor,它调用InteractionalObject时先通过InteractinalObjectFactory根据注册信息找到InteractionalObject的Provider,然后得到由Provider提供一个InteractionalObject的stub,最后再调用InteractionalObject的servicemethod对请求进行处理。这所以这样做的一个根本目的是：将逻辑组件开发和部署分开，由工具插件统一负责"InteractionalObjectFactory"层，这一层主要考虑的是屏蔽在下的移植变得很方便(不管是何种组件的调用方式，返回给Action的服务3.10技术架构中各层对象在创建过程中的依赖关系架构中的几层在“创作”过程的依赖关系是什么，即凭什么知道要创下图阐述了几层对象在创作过程中的依赖关系，它们之间的连线是本节说明的重点，所以颜色调成了红色，对这些线的说明调成了蓝色，以显用户界面需求会决定最终的界面窗口是什么样子的。我们提倡在需求样的功能。但并非一个窗口就完全对应一个Interaction,一个窗口可能然怎么管Interaction叫“交互对象呢”?一次交互就是一个完整的事务。就是有什么实体类，有什么控制类。其中实体类会在编码阶段被拆分为Interaction是GUI层和BL层的"和事佬",它主要是要满足GUI的请求，但也要照顾AppLogic的脸色，必要时要对GUI和BL做个折中处理。实体是会在妈码阶段械拼分为DataSe1,DAO,行为类图广系由肃水含达定最林的是前前以是什复界而都确定下EQ\*jc3\*hps12\o\al(\s\up2(),)EQ\*jc3\*hps12\o\al(\s\up2(),)EQ\*jc3\*hps12\o\al(\s\up2(),on)EQ\*jc3\*hps12\o\al(\s\up2(),A)EQ\*jc3\*hps12\o\al(\s\up2(),c)EQ\*jc3\*hps12\o\al(\s\up2(),t)EQ\*jc3\*hps12\o\al(\s\up2(),on)EQ\*jc3\*hps12\o\al(\s\up2(),)Aetion的命运intersction优发HTIP请求的门量DA0实体类控制类要而食决定有作么样的amcuion,a就完金对应一个lateraction,一个育口可能★逻辑需求及行业经验用户界面需求图-5示意图序号基础环境备注1线上服务器2台式机3研究环境4部署环境5模拟项目环境6研究管理首先我们先了解完整研究过程，如图所示：评审从上图中我们能看到一个完整的项目的研究包括很多的环节，在实际项目研究中，一般每个环节都有专门的人负责。比如：原型的设计有产品经理负责。界面的美化有专门的UI设计负责。前端有专门的前端研究人员负责。而研发主要工作就是根据项目的需求文档设计系统架构、设计数据库、编写调试程序代码。基于对客户需求、业务目标、业务能力和IT环境的理解，结合多年的软件研究和系统实施经验，将项目的实施周期划分为六个活动阶段，保证在项目生命周期内，应用合理的项目管理和控制技术。书面的文档。它阐述以SOW为基础的业务需求，这个阶段组建项目团队，保证项目的成功。公司人员与客户人菜单按钮操作步骤测试结果测试人测试结论本文是对信息系统采购性能测试所做的讲明，为充分利用已有的软硬件资源，配合对各系统应用模块的运行测试方案，查缺补漏完善系统的各项具体功能，保证项目的顺利进行，本测试报告有助于实现以下目标：明确此次性能测试的测试资源；明确此次性能测试的测试内容；明确此次性能测试的测试方法；明确此次性能测试的系统性能。测试地点：公司试验机房测试方案编写人：软件管理师测试方案编写时间：项目完成时间内压力测试实施时间：压力测试时间2个月压力测试概述技术目标量在100以上，并能正常工作。测试环境软硬件环境硬件环境应用服务器数据库服务器客户端硬件配置软件配置_客中端客中端以太网应用服务器、数据库服务器紧业务(下点单、制作相册)进行压力和负载测试。系统在并发用户100时，系统表现稳固压力测试结果6.1测试时刻及人员6.压力测试标准LoadRunner进行100用户场景模拟测试结果收集后，显示的该结果的一个摘要信息，如图5-1所示。概要中列出了场景执行情形、"StatisticsSummary(统计信息摘要)"、"TransactionSummary(事务摘要)”以及“HTTPResponsesSummary(HTTP响应摘要)”等。以简要的信息列出此次测试结果。 ScenarioNamesoftHPLosdRunnerlscenariolidc ResultsinSessiomProgramFilesMercuryInteraciveMeruryLoadRunnerscriptslidcardnewlAvsrageThrooghputbyterron0000000000000000E图5-1性能测试结果摘要图刻，如图5-2所示。从该图我们明白，此次测试从16:17:08开始，到16:54:38终止，共历时37分30秒。图5-2场景执行情形描述图StatisticsSummary(统计信息摘要)总要求数、平均每秒要求数的统计值，如图5-3所示。从该图我们得知，此次测试运行的最大并发数为200,总吞吐量为960,974,180字节，平均每秒的吞吐量为426910字节，总的要求数为117,105,平均每秒的要求为52.024。QQQQ.QViewHTTPResponsesSummary图5-3统计信息摘要图TransactionSummary(事务摘要)等情形，如图5-4所示。从该图我们得到每个Action的平均响应时刻与MaximymStdDeviationloqinActionTranaaction0.45247.115109.3830.25726.648144.70411.23193.983329.97400.0111.2970.097yusarinitTraneactionQ0.001图5-4事务摘要图HTTPResponsesSummary(HTTP响应摘要)该部分显示在场景执行过程中，每次HTTP要求发出去的状态，是成功依旧失败，都在那个地点体现，如图5-5所示。从图中能够看到，在此次测试过程中LoadRunner共模拟发出了117105次要求(与“统计信息摘要"中的"TotalHits"一致),其中“HTTP200”的是117105次，讲明在此次过程中，通过发出的要求全部分都能正确响应了(“HTTP200”“RunningVusers(运行的并发数)”显示了在场景执行过程中并发数的执行情形。它们显示Vuser的状态、完成脚本的Vuser的数量以及集合统计信息，将这些图与事务图结合使用能够确定Vuser的数量对事务响应时刻产生的阻碍。图5-6显示了在系统业务性能测试过程中Vusers运行情形，从图中我们能够看到，Vusers的运行趋势与我们场景执行打算中的设置是一样，表明在场景执行过程中，Vusers是按照我们预期的设置运行的，没有Vuser致Vuser运行错误。Elapsedscenariotimemm:ssAve.Max.1图5-6运行的并发数图我们此次测试RunningVusers与集合点是一致，讲明整个场景执行过程中，并发数用户的执行正确，系统测试服务器能够应对200个并发用户的业务操作。响应时刻"AverageTransactionResponseTime(平均事务响应时刻图)"(图5-7),这张图是平均事务响应时刻与结果摘要中的"TransactionSummary”合成的。Elapsedscenariotimemm:ss日Min.Max.1281 91 117115图5-7平均事务响应时刻图的Action是"selectoneAction",他们的"AverageTime(平均响应时刻为)"分不是47.115秒与26.648秒与93.983秒，从这三个数值来看，登录：47.115/5-5=4.423(减5登录时包含了一个用户信息查选择信息查询：93.983/5/7=2.685(除7做了7次点击选择信息)注：除5所有的事物都被重复执行5次看完了"AverageTime",我们再看“90PercentTime”,表示90%的事务登录：95.711/5-5=14.142(减5登录时包含了一个用户信息查询)选择信息查询：146.797/5/7=4.194(除7做了7次点击选择信注：除5所有的事物都被重复执行5次从图5-7能够看出，所有Action平均事务响应时刻的趋势有较大的录如表5-1所示。测试项实际值是否通过登录业务响应时刻14.142秒Y批量查询响应时刻7.825秒Y选择信息响应时刻4.194秒Y登录业务成功率考勤业务成功率登录查询总数批量查询总数选择信息总数CPU使用率坚持100%表5-1测试结果对比表一每秒点击数tes/second)"的复合图，从图中能够看出，两种图形的曲线都正常同时差不多一致，讲明服务器能及时的同意客户端的要求，并能够返回结果。图5-8每秒点击数与每秒吞吐量复合图业务成功率。在"TransactionSummary"中我们能的执行状态，如图5-9所示。1图5-9事务状态统计图从图中能够看出，所有的Aciton差不多上绿色的，即表示为Passed,同时除了vuserinit与vuserend两个事务，其他的事务通过数为2163,也就表明在30分钟的时刻里，共完成了2163次登录考勤业务操作。那么按照这些能够判定此次测试登录业务与考勤业务的成功率是100%,再次更新测试结果记录表如表5-2所示。测试项实际值是否通过登录业务响应时刻14.142秒Y批量查询响应时刻7.825秒Y选择信息响应时刻4.194秒Y登录业务成功率Y考勤业务成功率Y登录查询总数Y批量查询总数Y选择信息总数YCPU使用率内存使用率表5-2测试结果对比表二系统资源试监控的是测试服务器的CPU使用率与内存使用率，以度，具体的数据如图5-10所示。Elapsedscenariotimemm:ssI1314图5-10测试服务器系统资源监控结果图标的曲线逗较为平滑，三者的平均值分不为：63.813%、500.596、1.962,按照此次性能测试要求的：CPU使用率不超过75%,内存使用为130M。eLength(处理器队列长度)"一直超过二，则可能表示处理器堵塞，我们那个地点监控出来的数值是1.962接近2,而且总体上保持平稳，那么由此推断，测试服务器的CPU也可能是个瓶颈。获得上述数据后，最新的测试结果记录表如表5-3所示。测试项实际值是否通过登录业务响应时刻14.142秒Y批量查询响应时刻7.825秒Y选择信息响应时刻4.194秒Y登录业务成功率Y考勤业务成功率Y登录查询总数Y批量查询总数Y选择信息总数YCPU使用率内存使用率表5-3测试结果对比表三从上表数据来看，此次测试总体上差不多达到了预期的性能指标，但从其他的数据，例如CPU的队列长度、内存使用率来看，被测服务器的硬件资源需要提升。通过tomcat检测工具probe,内存使用130M。测试中，系统在大量用户使用和长时刻反复运行中，系统未显现不良反应，包括cpu、内存占用过高、内存泄露等，系统反应良好，在大吞吐量情形系统响应时刻令人中意，系统稳固性比较可靠。另：测试250到300用户的情形下系统表现情形。结果发觉系统在250以上显现连接超时等现象，故在此次测试环境下并发用户峰值在250。2.2压力测试流程根据软件外部测试的要求，以及在软件测试项目的特殊性，我们通过总结，认为要保证软件测试项目目标的顺利实现，项目的实施必须遵循以避免系统建设过程中可能存在的风险，实施方案应建立在成熟稳定的、保证系统上线对现有业务、服务功能继续使用，保持对客户服务的连符合成本效益原则，投资收益最大化，充分利用设备、人力和技术等目标系统设计、开发和维护工作都严格按照软件工程的方法执行，并均衡性原则目标系统提供较好的运行效率，避免产生系统瓶颈。合理划分系统组拓展性原则目标系统采用合理的层次结构，体现分层设计和模块化的原则，具有先进性原则目标系统采用先进的体系结构，先进的设计、开发和项目实施管理方开放性原则在满足系统业务需求的前提下，采用开放的技术标准、软硬件工具和具有多年的软件测试实施经验，我们深刻理解应用软件项目的实施是事关未来发展的关键作用。每一个系统项目都具有涉及面广、时间紧、安全性要求高等特点。要保证工程的顺利实施及工程质量，必须通过项目中的多方通力合作，加强项目实施管理，并严格按照软件工程的方法及有关在软件测试项目实施过程中，我们以质量体系规范为指导，结合项目实际情况，通过对项目管理关键领域进行科学管理，以保证项目按计划、按质量完成。我们将重点关注下面几方面关键要素：需求、计划、质量、人力资源、沟通、风险。首先我们将明确项目的需求，即项目范围管理，是为了实现项目的目标，对项目的工作内容进行控制的管理过程。它包括范围的界定，范围的规划，范围的调整等。其次，我们将制定合理的项目实施进度计划，通过对项目进度的控制保证项目在计划时间内完成。为了确保项目达到客户所规定的质量要求，我们还将制定质量计划，主要包括为保证项目质量所实施的一系列管理过程，如质量规划、质量控制和质量保证等。在项目实施过程中，人力资源无疑是非常关键的要素，为项目实施需要准备了充沛的人力资