某大型企业IT运营管理平台建设技术方案

大型企业IT运营管理平台建设技术方案

目录1 项目背景 52 建设原则 62.1 标准化原则 62.2 访问速度优先原则 62.3 扩展性原则 62.4 大集中原则 62.5 安全性和稳定性原则 73 需求分析 83.1 业务需求 83.2 功能需求 83.2.1 用户角色 83.2.2 监控管理中心建设 83.2.3 个人门户 93.2.4 基础平台 93.2.5 监控大屏 94 总体设计 104.1 架构设计 104.1.1 总体架构设计 104.1.2 逻辑架构设计 114.1.3 功能架构设计 124.1.4 技术架构设计 134.1.5 网络拓扑设计 144.2 业务流程设计 154.2.1 业务流程图 154.2.2 业务流程描述 154.3 数据流程设计 164.3.1 数据流程图 164.3.2 数据流程描述 165 功能设计 175.1 用户角色 175.1.1 功能描述 175.1.2 功能实现 175.2 监控管理中心建设 175.2.1 资产配置 185.2.2 监控管理 185.2.3 告警及工单管理 215.2.4 统计分析 215.3 个人门户 225.3.1 功能描述 225.3.2 功能实现 225.4 基础平台 235.4.1 系统管理 235.4.2 流程管理 245.4.3 采集平台 255.5 监控大屏 265.5.1 功能描述 265.5.2 功能实现 265.6 系统功能清单 276 接口设计 286.1 接口概述 286.2 接口协议 286.3 接口频率 286.4 主要字段 287 数据模型设计 297.1 数据表设计 297.2 数据结构关系设计 318 非功能性设计 328.1 软件存储设计 328.2 系统性能设计 328.3 系统可靠性设计 328.4 系统安全性设计 339 实施方案 359.1 实施原则 359.2 实施策略 369.3 实施步骤 379.3.1 实施流程 379.3.2 项目启动阶段 389.3.3 需求分析阶段 399.3.4 需求规格阶段 399.3.5 设计阶段 409.3.6 开发阶段 409.3.7 测试阶段 419.3.8 试运行阶段 419.3.9 验收阶段 429.3.10 项目维护阶段 429.4 项目实施工作内容 439.4.1 项目需求分析 439.4.2 项目原型系统搭建 439.4.3 项目测试及验收 449.4.4 项目培训和和功能调试 689.4.5 后期维护与应用升级 689.5 项目组织管理 689.5.1 项目人力资源管理机制 699.5.2 组织结构 699.6 项目质量管理 739.6.1 质量管理体系标准 739.6.2 质量控制过程 739.6.3 质量评定计划 739.6.4 质量管理措施 749.6.5 软件质量控制 7410 项目服务 7810.1 服务工期 7810.2 服务计划 7810.3 项目维护期 7810.4 驻场服务 7810.5 交付文档 7810.6 技术支持 7910.6.1 规划支持 7910.6.2 售后服务 82

项目背景随着企业数字化的迅猛发展，给IT运维带来了全新的挑战，子公司运维现状体现在以下两方面：1、人工运维检查,效率低下、工作量大随着新技术引入、新模块迭代，系统复杂度显著增强，单靠人工检查，工作量大，效率低下，无以为继；企业各在用系统和核心平台采用了不同的框架、开发技术，系统复杂度日益增高，新的故障类型也在不断涌现，对运维人员的能力要求也不断提高。问题感知能力薄弱,导致用户满意度低对子公司系统故障感知能力薄弱，无法及时处理故障，用户满意度降低。子公司各系统应用规范日益增大，其中WLAN平台已接入49客户，涉及2500个AP；视频监控平台已接入23个客户，涉及90路视频，智慧社区已承载200社区，连接设备1770个。

建设原则本项目在软件设计方面严格按照相应的国际、国家标准和规范。在项目设计中，重点考虑具备先进性、可靠性、实用性和经济性，使系统具有扩展性的升级能力、安全性和保密性、标准化和开放性、灵活性和兼容性。标准化原则本项目中所有应用系统的接口、网络数据格式等将严格遵循标准化，对于部分非标准的业务应用内容，也将根据业务的实际情况，为工作人员设计弹性化的系统应用，以确保与其他标准化应用的充分兼容。访问速度优先原则在保证质量的基础上尽可能减少文件大小，并通过良好的网络部署设计架构，以满足网络传输的需求；互动过程的网络带宽要求应适合一般带宽接入环境的网络用户访问。扩展性原则扩展性原则包含2个方面的含义，一是系统功能的扩展，随着信息化建设的不断深入，系统的功能可能将进一步扩大，因此，我们在设计系统的部署架构时，会考虑到这方面的需求，使整个平台在软硬件上都具备很强的扩展能力，方便以后更多功能模块的扩容与改造；二是用户数量的扩展，由于业务的不断开展和增加，势必将带来管理用户的增加，使平台用户数量增多，本系统在进行建设部署时，会考虑到未来用户数量增多、数据负载超过现有设备的问题，使整个平台具备随时扩充用户的能力，有效地保证在各个应用层面的可伸缩性。大集中原则部署设计需要以集中和分布相结合为原则。本项目的设计采用数据集中、业务和服务分布的原则，使数据的处理最终在统一数据服务器进行数据的汇总和分析。通过对整个体系框架实行分层、逐级设置权限操作，为内、外部提供有效、充分的操作手段。安全性和稳定性原则本系统部署设计和实际建设中会充分考虑到了网络的安全性和稳定性，能保证各种在网数据安全、完整，保证各类网络应用的畅通和稳定。

需求分析业务需求其运维面临的问题和挑战体现为：1、运维成本越来越高随着业务发展子公司系统故障影响面越来越大，人工解决问题成本越来越高；2、运维要求越来越高子公司运维基础薄弱、专业人员稀缺，长期无法实现日常操作的标准化，因人而宜产生较大波动的概率高；3、考核压力越来越大母公司对各子公司自有系统运维能力的要求不断提升，考核力度逐年增长；4、运维难度越来越大智慧社区平台、移动OA平台、视频监控和分析平台、内部项目管理系统等都使用了不同的最新技术，系统复杂度日益增高，新的故障类型也在不断涌现。功能需求用户角色运维工程师：资源、监控告警等配置\工单处理\告警查看分析。系统管理员：查看、使用所有功能模块。监控管理中心建设本期项目需实现如下功能：支持资产配置功能支持告警及工单管理功能支持监控管理功能支持统计分析功能个人门户需提供平台与用户的交互界面。基础平台支持系统管理功能；支持流程管理功能；支持平台采集功能；监控大屏需提供包含丰富配置组件的监控系统，并支持各类大屏显示设备。

总体设计架构设计通过对本项目的理解，设计总体架构、功能架构、技术架构及网络架构，并对各个架构进行描述，具体如下：总体架构设计总体架构图总体架构描述企业IT运营管理平台包括监控管理中心、操作管理中心、业务管理中心、运营管理中心、运维管理中心等功能，本期重点完成监控管理中心。监控管理中心主要由数据采集、数据处理、自动告警引擎以及数据分析组成。数据采集会自动采集被监控系统的各项运行数据，再由统一处理根据配置的规则对数据进行分析。当发现了故障或风险时由告警引擎负责告知维护人员，而系统管理员则可以通过可视化报表及时掌握各系统的整体运行与故障情况。逻辑架构设计逻辑架构图逻辑架构描述软件架构包括数据源层、数据采集层、业务处理层、展示层及能力接口，具体如下：数据源层：主要实现基础设施服务器、虚拟机、数据库、中间件、容器、应用、服务等的接入；数据采集层：针对数据源层进行指标采集、日志采集、链路采集、采集网格、采集存储等；业务处理层：实现资产配置、硬件配置、软件配置、中间件配置、告警管理、通知管理、指标配置、采集配置、系统配置、服务配置、调用链管理、日志管理等；展示层：实现视图、报表、大屏等可视化展示。能力接口：实现数据分发、同步、异步通知等功能。功能架构设计功能架构图功能架构描述企业IT运营管理平台由监控管理中心、操作管理中心、业务管理中心、运营管理中心、运维管理中心等子系统组成，形成以客户体验为视角的业务监控能力和运营分析能力，同时完成对运维工作的电子化、规范化、流程化的管理。本期项目目标（上图绿色图标）旨在完成监控管理中心模块建设。技术架构设计技术架构图技术架构描述企业IT运营管理平台通过运用Grafana、SkywalkingUI、Kibana、Prometheus、Elasticsearch、Logstash等技术实现基础设施、服务器虚拟机中间件数据库、容器服务、应用服务、性能等的监控及展示，具体如下：Prometheus技术实现基础设施、服务器虚拟机、中间件数据库的指标采集监控，其他性能指标通过Prometheuspushgateway进行采集监控，并通过Influxdb进行存储；SkyWalking技术实现容器服务指标的采集监控；Logstash技术实现应用服务及容器服务的日志采集，并通过Elasticsearch实现日志的查询；指标展示、服务调用链展示、日志展示通过Grafana、SkywalkingUI、Kibana等技术在WEB-UI层进行展示。网络拓扑设计网络拓扑图网络拓扑描述OMC平台软件部署架构如上图所示，系统服务器清单如下：服务器用途Cpu内存存储数量备注监控、日志门户2核8G200G1部署监控门户WEB服务、Nginx服务、接口服务监控计算Prometheus监控数据存储InfluxDB链路追踪服务Skywalking链路追踪数据存储4核16G500G1部署Prometheus监控数据采集服务日志缓冲kafka日志处理logstash日志存储Elasticsearch4核16G1T1部署ES服务集群，用于日志查询、监控数据查询监控push网关监控收集collector日志推送网关4核16G500G1接入机元数据存储Mysql4核16G500G1Mysql数据库，定期备份数据业务流程设计业务流程图业务流程描述通过各系统监控点数据采集，自动生成运维工单，提交运维进行处理关闭，逐步形成告警处理解决方案知识沉淀，并对知识库进一步进行问题分析，根据分析结果，进行系统专项优化。实现应急处置治标、持续迭代改进治本结合，不断完善和规范监控管理操作流程。数据流程设计数据流程图数据流程描述运营管理平台数据流程如上图所示，具体描述如下：数据采集：实现被监控服务器、中间件及应用等的指标数据进行数据采集；数据存储及处理：运用InfluxDB、Skywalking等技术对监控数据进行存储；数据统计分析：运用大数据技术对数据进行统计分析。终端及大屏展示：利用监控大屏对IT运维业务进行集中的监控。

功能设计用户角色功能描述运维工程师：资源、监控告警等配置\工单处理\告警查看分析。系统管理员：查看、使用所有功能模块。功能实现监控管理中心建设监控管理中心模块，为子公司提供系统运行状态监控、各项数据采集、主动式的IT系统故障监控告警、核心产品阻断式不可用处理监控、故障管理流程和报表统计分析等功能，实现集中监控管理能力。其具体系统功能架构参见如下：资产配置功能描述支持主机配置支持中间件配置支持应用配置支持前端配置功能实现监控管理功能描述支持主机、中间件、数据库、应用、前端、调用链、日志、监控配置、故障定义、故障类型配置。功能实现图主机监控图组件监控图日志查询图网关监控图平台监控告警及工单管理功能描述支持告警配置、告警通知配置、告警通知、告警历史查询、告警处理管理等。通过各系统监控点数据采集，自动生成运维工单，提交运维进行处理关闭，逐步形成告警处理解决方案知识沉淀，并对知识库进一步进行问题分析，根据分析结果，进行系统专项优化。实现应急处置治标、持续迭代改进治本结合，不断完善和规范监控管理操作流程。功能实现图告警列表统计分析功能描述支持告警数据统计、报表分析。功能实现图统计分析个人门户功能描述提供了平台与用户的交互界面，是用户开展具体运维工作的工作台。功能实现图用户登录图运维人员门户示例基础平台基础平台负责整个平台系统的基础架构管理；基础平台为前端应用提供基础业务数据服务、核心能力服务、业务处理与管理服务。系统管理功能描述实现用户管理、权限管理、组织管理、数据字典。功能实现图用户管理图数据字典流程管理功能描述支持流程和规则管理，流程监控，为工单管理提供报警故障闭环处理流程。功能实现采集平台功能描述实现采集策略、模板、规则等管理，为上层应用提供各类采集监控数据。功能实现监控大屏功能描述平台提供了包含丰富配置组件的监控系统，并支持各类大屏显示设备。利用监控大屏对IT运维业务进行集中的监控，不仅可以直观、及时的掌握各系统的整体运行、资源利用与故障情况，还可快速响应系统故障的处理。功能实现图工单监控图性能监控系统功能清单工作专项

大类模块

监控管理中心建设资产配置主机、中间件、应用和前端配置告警及工单管理告警配置、告警通知配置、告警通知、告警历史查询、告警处理管理等监控管理主机、中间件、数据库、应用、前端、调用链、日志、监控配置、故障定义、故障类型配置统计分析数据统计、统计分析个人门户个人门户基础平台系统管理用户管理、权限管理、组织管理、数据字典流程管理流程和规则管理，流程监控采集平台采集策略、模板、规则管理监控大屏大屏展示及页面开发资源、主机等告警等关键信息展示

接口设计接口概述本次项目主要涉及采集接口，包括基础设施、服务器、虚拟机、数据库、中间件、容器服务、应用服务等。接口协议可以提供多种标准接口协议，例如：支持HTTP、Webservice、API等接口。接口频率满足实际需要。主要字段序号字段名类型1指标名称字符2指标IDINT3指标类型字符4采集策略字符5采集规则字符6告警类型字符7告警设置字符8……

数据模型设计数据表设计表1.主机监控数据表序号字段名字段类型说明1主机名称字符2主机ID数值3CPU使用率数值以图形形式展现CPU使用率4内存使用率数值以图形形式展示内存使用率5网络使用率数值以图形形式展示网络使用率6硬盘使用率数值以图形形式展示硬盘使用率7读写IO频率数值以图形形式展示IO读写频率8………表2.日志监控数据表序号字段名字段类型说明1日志名称字符2日志ID数值3日志类别字符4日志文件字符存储日志文件路径5时间段时间用来显示某一时间段的日志信息6服务单元字符7日志内容字符8………表3.采集配置数据表序号字段名字段类型说明1采集名称字符2采集ID数值3类型字符4更新时间时间显示采集数据更新时间5对象名字符6模块名字符7分组名字符8………表4.页面性能监控数据表序号字段名字段类型说明1系统名称字符2系统ID数值3URL字符4浏览器字符使用浏览器类型及版本5创建时间时间6………表5.网关监控数据表序号字段名字段类型说明1引擎名称字符2引擎ID数值3URL字符4时间段时间5总访问量数值6访问量排名数值支持按照一定顺序展示7错误量数值8正确量数值9评价响应时长字符10请求TPS字符11………表6.告警信息数据表序号字段名字段类型说明1告警名称字符2告警ID数值3告警类型字符4告警时间时间5告警原因字符6告警统计数值7告警阈值设置字符设置告警值8………数据结构关系设计

非功能性设计软件存储设计在本次项目中，在软件存储设计方面我们将充分考虑业务发展情况，确保数据库业务存储可以满足未来2年的软件使用要求。系统性能设计在本项目中，我们将在系统架构、可用性、资源配置、系统功能等方面进行性能优化设计，以确保系统性能可以满足业务要求。具体，在项目中系统的性能设计方案如下：支持365*24的平台运作要求考虑到系统是企业业务的核心应用，系统将保证以365*24模式进行运作，在满足备份要求的情况下，故障恢复的时间在30分钟之内。支持历史信息保存6个月系统设计将考虑问题追溯，需要至少保留6个月的数据。系统运行每1000小时中可用时间不小于999小时，故障间隔时间大于1000小时；功能模块部署上线时，能够在8小时内完成部署工作；系统之间进行数据传输时，其数据的一致性，完整性，准确性可达到99%；支持对客户输入的数据进行合法性检查，确保流程的通畅性，并且支持对错误数据进行自动纠错处理系统可靠性设计1) 应用系统支持连续7×24小时不间断地工作，应用软件中的任一构件更新、加载时，在不更新与上下构件的接口的前提下，不影响业务运转和服务。2) 系统具有安全的管理体系结构，可通过管理员安全定义，权限划分和管理信息传输加密、网络隔离等措施保证管理系统的安全。3) 系统将充分利用防火墙、安全证书、SSL等数据加密技术保证系统与数据的安全。4) 系统支持操作失效时间的配置，当操作员在所配置的时间内没有对界面进行任何操作则该应用自动失效。5) 系统将提供完善的日志记录功能，对系统关键数据的每一次增加、修改和删除都能记录相应的修改时间、操作人和修改前的数据记录。6) 系统具有自检功能，能监视系统各功能模块的运行情况，随时发现系统自身的问题。7) 为了保证系统的高可靠运行，本系统提供容错机制，避免单点故障的发生，如采用集群、负载均衡等技术；同时，系统提供完整的备份和恢复手段。系统安全性设计为保证企业系统规划、建设及运行安全管理工作的开展，依据“GBT35273-2017信息安全技术个人信息安全规范”相关要求,客流分析建设系统规划方面需进行如下安全性的考量：1、网络安全：如结构设计（分层设计）、路由控制、访问控制（权限控制）、网络隔离（防火墙）、边界保护、网络监控（定期安全扫描）等。2、应用系统安全：如身份认证、访问控制、系统容错（NGINX负载均衡）等。3、数据安全：包括数据存储（数据备份）、敏感数据保护等。4、数据去隐私化：根据国家相关法律法规以及集团公司文件要求，针对涉及用户隐私的数据，不提供对外服务。相关数据包括：单个用户的MAC地址、单个用户的位置轨迹等。相关隐私信息除计算需要，不在服务端存留，并进行去隐私化处理。企业IT运营管理平台（一期）建设除满足上述规划性要求外，还应满足以下细则：对用户敏感信息进行加密存储，敏感信息包括但不限于:用户手机号、用户密码、身份证号、银行卡信息、社保信息等。对用户银行卡信息、密码、身份证、手机号码等敏感信息进行加密传输、避免直接传输明文信息。设置用户密码最低复杂度要求，避免用户设置过于简单的密码，密码至少要包含：8位及以上大小写字母、数字及特殊字符等混合、随机组成。对用户密码错误次数进行限制，避免账户被暴力破解，当用户尝试登陆6次失败后锁定用户账号30分钟以上。将避免短信和邮件接口暴露，并增加验证和频率限制功能避免接口被滥用。将在关键界面设置覆盖提示信息，降低钓鱼劫持风险。在开发前将对所选开发框架、库的版本进行检查，避免使用含有漏洞的框架，库和开发框架要求使用维保期内的最新版本。为保证数据安全，文件上传功能应遵循：文件上传目录设置为不可执行；判断文件类型；使用随机数改写文件名和文件路径；单独设置文件服务器的域名等原则。对注入类型的攻击满足“数据与代码分离原则”，在“拼凑”发生的地方进行输入检查。防止XSS攻击，即指黑客通过“HTML”注入篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。为防止XSS攻击应对用户输入进行检查和输出检查，针对如<>（尖括号）、”（引号）、‘（单引号）、%（百分比符号）、;（分号）、()（括号）、&（&符号）、+（加号）等。严格控制输出。开发环境引用的工具和程序版本采用最新的版本，并在提交测试时将告知测试工程师，确保开发、测试环境的一致性，减少环境差异导致的系统缺陷，影响上线质量。不使用本地cookies，记录用户重要数据。

实施方案实施原则1．用户方项目小组的成员，争取参与项目的全过程用户方成立领导亲自挂帅的项目小组，在调研、设计、编码、安装调试、测试、培训、运行、验收、售后服务等项目的各个阶段，配合系统开发方的工作，一方面可以培训自己的技术维护队伍，为系统的使用保驾护航；另一方面，在开发过程中，协调用户方和开发方的关系，保证项目的顺利进行，及时发现问题，并对项目进度和质量进行监督。此外，我公司在项目实施过程中承担如下职责：按招标方的要求，我方负责开展详细全面的需求调研工作，进行需求分析并形成需求说明书由招标方确认。负责指导所提供的应用软件现场安装、调测和开通。除了负责自己应用软件系统的互通，还将配合招标方保证能与其它应用系统之间的互通。向招标方提交测试内容、方法和测试计划。测试计划和测试内容由我方拟定，经招标方确认。我方确保技术建议以及所提供的应用软件的完整性和可用性，保证应用软件能够投入正常运行。若出现由于我方提供的应用软件不满足要求或其所提供的技术支持和服务不全面而导致系统功能无法实现或不能完全实现，由我方负全部责任。提供系统装调试时所需的工程设计资料,我方有责任在保证安全和质量的前提下提供技术服务,包括技术咨询等。在系统调试期间,招标方有权派出技术人员参加,我方有义务对其进行指导。在系统试运行期间，根据需要我方有责任派技术人员到现场指导维护工作。在系统和设备扩容及软件升级时，我方派技术人员到场指导。2．采用“两手抓”的方针，一手抓开发、一手抓使用对于软件项目，之所以称为一个工程，很大程度上是因为软件项目的建设，除了技术因素外，还有很多的非技术因素需要考虑，并且必须被得到重视。衡量一个软件项目是否成功，很大程度上不是看这个软件项目采用了多么先进的技术，而是软件对用户来说是否实用，是否能够帮助用户解决许多预期的问题。国内很多软件项目的失败，很大程度上是使用抓得不够。建议在项目的试运行过程中，在抓系统维护的同时，也要狠抓系统的使用，开发方和用户方齐心协力帮助业务人员从原来的手工处理转到计算机辅助处理上来，在业务人员适应计算机辅助业务处理的过程中，尽可能早发现系统中存在的问题，从而最大可能地使系统保质保量的按时完成。3．数据同程序同等重要该系统的建设，数据位于首要的地位，程序的编写完成，仅仅意味着系统完成了一半，数据的收集、整理、录入，对系统的建设来说同等重要。在项目实施过程中，一定要重视系统中数据的录入工作，充分估计数据处理的难度，在系统建设之初，就将数据工作提到议事日程上来，安排相应的资金、时间等，将数据工作落到实处，只有这样才能争取系统早日达到实用化。实施策略由于本项目实施的范围广、工作量较大，因此需要良好的实施策略保障实施的顺利进行。考虑到本系统的建设是一个逐渐深入，滚动发展的过程，同时也是一个不断完善的过程，项目组综合各方面的因素考虑，拟采用“原型法”来进行本项目的实施。具体策略措施主要包括以下几个方面：1、统一规划，分步实施。项目实施采用统一规划，分步实施的策略，明确项目每一个阶段的实施范围，保障本系统建设高效、有序地实施。在项目实施过程中，将提交详细的项目实施计划列表，以及实施时间表，按照需求调研论证、软件开发设计、安装、培训、调试、初验、试运行、终验等各步骤有序地实施。2、版本控制，统一系统。我们将采用严格的版本控制方法，统一本项目的系统版本。3、分层实施策略。信息化系统的建设，不是简单的信息化技术改造和提升，更重要的是它意味着对内部与外部的业务梳理和整合。项目建设分三层：一是认识问题，二是操作问题，三是工程和技术问题。其中认识问题其中包括系统的目标、价值、意义、时机、重要性、利弊等方面，也就是项目组成员在许多问题上要达成一些基本的共识；操作问题包括如何做好系统和如何运行好系统，包括管理，规划，投资，标准，组织，阶段性，评价，系统结构，运营，规范制度和环境等等；工程和技术问题包括这个具体是指项目实施和方案问题，包括软硬件，安全，认证，人员培训等。实施步骤实施流程瀑布模型迭代模型A迭代模型B项目启动阶段需求分析阶段需求规格阶段设计阶段开发阶段测试阶段试运行阶段验收阶段验收阶段：提供源代码、数据库设计文档、数据库脚本、测试文档、产品帮助手册、用户手册等相关资料项目维护阶段项目实施工作内容项目需求分析深入调查并了解本项目信息化需求，形成需求调研报告，保证项目可操作性和实用性。本次项目建设的成功与否不仅取决于系统本身的性能和功能，还要取决于科协当前业务模式和基层工作人员对该系统的熟悉和使用。对此需要进行全面调查和分析才能保证本次项目建设可操作性和实用性。因此，根据我公司实施相关项目的经验，在项目启动阶段首要的一个任务基于已有基础，搭建直观的原型系统演示给客户，与客户讨论，提出功能增删和改进意见。在此阶段同时进行的有项目信息收集工作，信息主要包括：数据例表、组织结构图、文件格式、业务流程等基本信息资料。在上述工作全部完成后完成《项目需求调研分析报告》，综合分析用户需求的情况下确定项目的范围与内容。此报告交由最终用户签收，并作为以后项目实施工作的依据。在此基础上，进一步完成业务模型分析和数据模型分析，并完成本次项目建设概要设计工作。概要设计包括功能详细定义，并且要考虑到安全限制：谁可以操作哪些功能、谁可以看哪些内容等等。项目原型系统搭建考虑到本系统的建设是一个逐渐深入，滚动发展的过程，实施的范围广、工作量大，同时也是一个不断完善的过程，综合各方面的因素考虑，拟采用“原型法”来进行本项目的实施。通过运用已有成熟产品和技术基础、先进的信息化架构体系，搭建直观的原型系统，以确保客户需求直达，沟通便捷、功能快速修正，在短时间内建成贴合实际需求的高质量系统。项目测试及验收项目测试目的和任务软件测试的目的是采用技术的手段，根据预定的目标，按照一定的规则和过程，检测和发现软件中存在的各种问题、缺陷和错误。软件测试是检验和保证软件产品的正确性与可靠性的一种基本方法。开发的任何软件产品都必须经过必要的测试过程并经确认后才能付诸使用。为了保证测试的完整性和全面性，原则上测试活动应由开发者以外的人员设计和进行。测试完成以后应及时作好总结并提呈测试报告。测试所用到的工具及产生的所有说明、数据等文档资料必须作为项目开发的基本文档妥善保存。测试的阶段与目的测试是一项复杂的软件质量保证技术，由不同的人在软件开发的不同阶段，针对不同的目标采用不同的技术手段来进行。根据软件测试的要求、范围和目的的不同，测试过程一般可分为下列三个阶段：单元测试(UnitTest)集成测试(IntegrationTest)验收测试(AcceptanceTest,FAT)测试内容功能测试1、划分等价类把所有可能的数据输入划分为若干部分，然后从每一部分选择少数具有代表性的数据作为测试用例。（1）有效等价类合理，有意义的输入数据构成的集合，检验程序是否实现规格说明预先规定的功能和性能。（2）无效等价类不合理，无意义的输入数据构成的集合，检验程序的容错能力。边界值分析大量的错误发生在输入或输出的边界上，而不是某个范围的内部。语句覆盖设计若干个测试用例，运行所测程序，使得每一可执行语句至少执行一次，语句覆盖是最弱的逻辑覆盖在准则。判定覆盖设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值都能满足。条件覆盖设计若干测试用例，运行被测程序，要使判断中的每个条件的可能取值至少满足一次。路径覆盖覆盖所有可能的路径。条件覆盖使得每个条件的所有可能至少出现一次，并且至少每个判断本身的判断结果出现一次。功能测试的方法(1)页面链接检查，每一个链接是否有对应的界面(2)相关性检查，删除/增加一项会不会对其他项产生影响，如果产生影响，是否正确(3)检查按钮功能是否正确(4)字符串长度检查，输入超出需求所说明的字符串长度的内容，看系统是否检查，会不会出错。(5)字符类型检查(6)标点符号检查(7)中文字符处理，乱码或出错(8)检查带出信息的完整性，在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致。(9)信息重复，在一些需要命名，且名字唯一的信息输入重复的名字或ID，看系统有没有处理，重名包括是否区分大小写，以及在输入内容的前后输入空格，看系统是否处理。(10)检查删除功能，在一些可删除多个的地方，不选任何内容按删除按钮看系统如何处理(11)选择一个或多个时又如何处理(12)检查添加修改是否一致，检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.(13)检查修改重名，修改时把不能重名的项改为已存在的内容，看会否处理，报错，同时看会否报和自己重名的错。(14)重复提交表单，一条已成功提交的记录，back后在提交，看系统是否进行处理。(15)检查多次处理back键的情况(16)Search检查:在有search功能的地方输入系统存在和不存在的内容，看结果是否正确；(17)如果可以输入多个search条件，同时可以添加合理和不合理的条件，看系统是否处理正确。(18)输入信息的位置，输入信息时，光标的位置(19)上传和下载文件的检查，上传下载的功能是否实现，上传文件是否能打开，上传文件的格式规定，系统是否有解释信息。(20)必填项检查，必填项是否有提示信息(21)快捷键检查，是否支持常用快捷键检查(22)回车键检查，在输入结束后直接按回车键，看系统处理如何，会否报错。2．界面测试的常用方法界面测试要遵循的规则：一．易用性，按钮名称通俗易懂，望文知意。（1）完成相同或相近功能的按钮，要用Frame框起来，常用按钮要有快捷键（2）完成同一功能或任务的元素要集中放置，减少鼠标的移动距离（3）按功能将界面划分区域块，并要有功能说明和标题（4）界面要支持键盘自动浏览按钮功能，Tab，回车键等（5）界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。（6）同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。（7）分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab（8）默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。（9）可写控件检测到非法输入后应给出说明并能自动获得焦点（10）Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。（11）复选框和选项框按选择几率的高底而先后排列。（12）复选框和选项框要有默认选项，并支持Tab选择。（13）选项数相同时多用选项框而不用下拉列表框。（14）界面空间较小时使用下拉框而不用选项框。（15）选项数较少时使用选项框，相反使用下拉列表框。（16）专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。二．规范性，通常界面设计都按Windows界面的规范来设计（1）常用菜单要有命令快捷方式（2）完成相同或相近功能的菜单用横线隔开放在同一位置。（3）菜单前的图标能直观的代表要完成的操作。（4）菜单深度一般要求最多控制在三层以内（5）工具栏要求可以根据用户的要求自己选择定制。（6）相同或相近功能的工具栏放在一起。（7）工具栏中的每一个按钮要有及时提示信息。（8）一条工具栏的长度最长不能超出屏幕宽度。（9）工具栏的图标能直观的代表要完成的操作。（10）系统常用的工具栏设置默认放置位置（11）工具栏太多时可以考虑使用工具箱。（12）工具箱要具有可增减性，由用户自己根据需求定制。（13）工具箱的默认总宽度不要超过屏幕宽度的1/5。（14）状态条要能显示用户切实需要的信息，常用的有：目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。（15）滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。（16）状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。（17）菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感（18）菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。（19）右键快捷菜单采用与菜单相同的准则。三．独特性（1）安装界面上应有单位介绍或产品介绍，并有自己的图标。（2）主界面，最好是大多数界面上要有公司图标。（3）登录界面上要有本产品的标志，同时包含公司图标。（4）帮助菜单的“关于”中应有版权和产品信息（5）公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。四．安全性（1）最重要的是排除可能会使应用非正常中止的错误。（2）应当注意尽可能避免用户无意录入无效的数据（3）采用相关控件限制用户输入值的种类。（4）当用户作出选择的可能性只有两个时,可以采用单选框。（5）当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。（6）当选项特别多时，可以采用列表框，下拉式列表框。（7）在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作（8）对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。（9）对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。（10）对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。（11）对错误操作最好支持可逆性处理，如取消系列操作。（12）在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。（13）对可能造成等待时间较长的操作应该提供取消功能。（14）特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格。（15）与系统采用的保留字符冲突的要加以限制。（16）在读入用户所输入的信息时，根据需要选择是否去掉前后空格。（17）有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。性能测试1、负载测试负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？负载测试应该安排在Web系统发布以后，放在Internet上接受负载测试。2、前端连接测试用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。以上需要关注的前端性能指标，主要包含以下三个指标：加载时间指标a.TimetoFirstImpression表示从用户在浏览器键入URL按下回车键一刻开始，到页面开始有反应（用户可以在页面中看见一点点内容）为止。直观信号就是网页开始显示title。b.TimetoonLoadEvent表示从页面开始显示内容，到浏览器开始触发OnLoad函数（开始执行js）这一时间段。只有当初始的文本和所引用的对象加载完成，浏览器才开始触发OnLoad函数c.TimetoFullyLoaded表示从上一时间段末到整个网页完全加载完成（所有OnLoad函数以及相关的动态资源加载完成）。资源情况指标网页由初始的html文本中嵌入图片以及通过XHR或者修改dom树动态加载的内容组成，css负责样式，js负责行为。a.TotalNumberofRequests包括html网页请求，css、js资源下载及其它网络请求。优化的目标之一是要尽量减少请求数。b.TotalNumberofHTTP300s/400s/500s表示返回状态为300（重定向）、400（客户端错误）、500（服务器端错误）的http请求。尽量避免这些请求，以提高页面load的时间。造成这些状态的原因经常是服务器的实施、配置和部署问题。c.TotalSizeofWebSite构成网页元素总的大小。图片或者js库的增加都会对下载时间造成重要的影响。d.TotalSizeofImages/CSS/JSimage、css、js在网页元素大小中占主要比例。e.TotalNumberofXHR(XMLHttpRequest)Requests通过js异步从服务器端获得数据的请求数。一些js框架提供了跟服务器端的更新机器，就是XHR请求。通过配置可以减少XHR请求的数目。网络连接指标浏览器底层的网络连接对资源的下载速度有很大影响。资源的下载过程分为很多阶段。下面介绍这些阶段以及浏览器、网络、请求如何影响这些阶段的时间。a.DNSTimedns查询的时间。网页请求会产生一次寻找该网页资源所在主机的dns查询。在同个域名进行网页切换不会造成新的dns查询。b.ConnectTime指浏览器和服务器之间建立tcp/ip连接的时间，对于ssl连接包括握手的时间。网络连接过慢、使用ssl、使用短连接而非常连接都是造成connecttime较多的原因。c.ServerTime指收到请求后服务器逻辑处理的时间，d.TransferTime这一指标与浏览器和服务器之间的连接速度相一致，通过减小传输内容或使用cdn来降低TransferTime。e.WaitTime等待时间和同一个域中服务资源的数量直接相关。每个域的浏览器的物理网络的限制，导致资源等待可用的连接。减少资源的数量，或将资源散布在不同的域，能将这一时间降低。平均等待时间的大小更能反映等待时间是否需要注意。f.NumberofDomains/SingleResourceDomains部署网站资源的域主机数量是很重要的，因为它影响的DNS，连接和等待时间。专门用户资源下载的域是必要的，他将直接减少等待时间。应避免单一的资源域，否则将为dns查询以及资源下载付出昂贵的代价。稳定性测试压力测试压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。1、压力测试概述压力测试是针对系统在应对密集整转的压力下业务处理能力的测试，检验系统的吞吐率；针对主要业务功能、报表统计进行，检查在日间应用高峰时期，并发用户数较多的时候的处理能力等等。2、测试目的压力测试的目的就是检验系统的最大吞吐量，检验现行的业务系统在各种压力交易量下的运行状况，检验系统地运行瓶颈，获取系统的处理能力等等。3、测试方法及测试用例对系统进行脚本录制、测试回放、逐步加压和跟踪记录。测试过程中，跟踪记录服务器端的运行情况和返回给客户端的运行结果。针对每个测试用例，都将采用逐步加压和瞬间加压两种客户端连接方式进行，查看服务器端在客户端的连接数量变化过程中对应的处理能力，以更好的定位系统在达到多少并发或压力下我们的系统出现了不稳定。4、测试指标及期望在本次性能测试中，各类测试指标包括测试中应该达到的某些性能指标，这些性能指标均是来自应用系统设计开发时遵循的业务需求，当某个测试的某一类指标已经超出了业务需求的要求范围，则测试已经达到目的，即可终止压力测试。5、应用软件级别的测试指标 CPU的利用率小于40% 内存占用小于80% Processorqueuelength小于2 Responsetime小于1s 吞吐量throughtput大于90% 业务执行的平均响应时间（期望值：<15s） 不同并发用户数的状况下的记录上述值网络级别的测试指标 吞吐量：单位时间内网络传输数据量 冲突率：在以太网上监测到的每秒冲突数操作系统级别的测试指标 进程/线程交换率：进程和线程之间每秒交换次数 CPU利用率：即CPU占用率（％） 系统CPU利用率：系统的CPU占用率（％） 用户CPU利用率：用户模式下的CPU占用率（％） 磁盘交换率：磁盘交换速率 中断速率：CPU每秒处理的中断数数据库级别的测试指标 数据库I/O的流量大小 数据库锁资源的使用数量 数据库的并发连接数：客户端的最大连接数测试数据准备根据测试系统的硬件条件，选择满负荷的压力，在系统的资源使用基本维持在90%左右的状况下，测试天威宽带业务管理系统的处理能力。数据准备工作包括：测试数据库需具备与真实环境成一定比例或基本一致的数据运行状况记录记录可扩展性测试中的测试结果及其系统的运行状况。除了记录测试指标以外，应该结合测试实时记录系统各个层次的资源和参数。主要包括： 硬件环境资源 服务器操作系统参数 网络相关参数 数据库相关参数：具体数据库参数有所不同，结合各个数据库独有的特点记录容错测试时钟中断测试概念时钟源中断测试是指通过模拟时钟信号中断来测试时钟源中断对系统的影响的测试过程。测试目的测试时钟源中断对系统的影响，检查系统对时钟源中断的处理过程是否符合要求。故障产生原因（1）、外部时钟源中断（2）、相关模块故障故障可能产生的后果（1）、误码（2）、业务中断测试步骤（1）、启动系统，加入一定的业务量。（2）、在系统正常运行时，切断时钟信号线或模拟失效使时钟信号中断。（3）、观察系统的状态测试的期望结果系统能检测到时钟源中断所影响的范围并上报故障，同时对于重要业务，能及时倒换到备用设备上去。当时钟源恢复正常后，系统也能恢复到故障前的正常状态。资源丢失测试[概念]资源丢失是指资源没有正在被使用，也不在对应的资源管理程序中，即该资源已经不受控了。[测试目的]资源丢失测试的目的是验证在发生资源丢失故障时软件是否能从故障中恢复过来，在故障恢复过程中是否还引入了其它的故障。[故障产生原因]（1）、重入（2）、申请出来的资源使用后没有释放（3）、在某些路径下资源没有释放[故障可能产生的后果]（1）、复位（2）、输出错误（3）、软件内部状态错误（4）、业务无法完成或业务性能降低[测试时的故障产生方法]把资源申请出来后不释放。[测试步骤]（1）、申请一个资源（2）、经过一段时间后，检查软件是否能发现出现资源丢失，观察软件是否采取了什么恢复措施，该措施是否有效。（3）、重复申请一批资源出来，不释放，过一段时间后，检查软件是否能发现出现资源丢失故障，故障软件是否采取了相应的措施，以及该措施是否有效。[测试的期望结果]对于一般系统，要求在资源耗尽以后能复位，这时要注意耗尽型资源和非耗尽型资源的差异，复位条件的检测要特殊设计。对于系统，要求能恢复资源丢失造成的影响，并且不影响业务的正常运作。故障测试内存过载测试[概念]当一个计算机系统的内存占用率为80%~100%时，视为内存过载。[测试目的]内存过载测试主要是测试系统在内存即将用完的时候，系统运行的可靠性。[故障产生原因]（1）、大流量冲击（2）、内存丢失（3）、算法缺陷，需要占用大量内存[故障可能产生的后果]（1）、复位（2）、空转（3）、系统内部数据状态不一致，即发送消息的模块和接收消息的模块状态不一致。[测试时的故障产生方法]采用内存丢失的办法实现内存过载。[测试步骤]（1）、丢失空闲内存，使内存占用率达到80%，运行一段时间，观察系统的运行状态。（2）、在前面的基础上再丢失10%的内存，运行一段时间，观察系统的运行状态。（3）、把剩余的所有内存全部申请出来丢掉，观察系统的运行情况。[测试的期望结果]对于一般系统，内存过载时能自动降低业务处理量，如果持续时间过长，复位单板。对于系统，要求能区分是大流量冲击还是内存丢失造成的内存过载，如果是大流量冲击造成的过载，应能自动降低业务处理量，如果是内存丢失造成的过载，应能复位单板，但对业务不造成影响。CPU过载测试[概念]当一个计算机系统的CPU占用率达到80%~100%时，称为CPU过载。[测试目的]CPU过载测试主要是测试系统在高CPU占用率状态下系统的可靠性情况。[故障产生原因]（1）、大流量冲击（2）、算法效率低下，例如在等待某些事件时没有交出CPU权限[故障可能产生的后果]（1）、对实时事件响应不及时（2）、影响提供业务的能力[测试时的故障产生方法]创建一个任务，用循环的方式强制消耗掉一部分CPU资源，循环次数可以动态调整，通过调整循环次数可以调整CPU占用率。[测试步骤]（1）、创建一个最高优先级的CPU过载测试任务，调整循环次数，使CPU过载，观察系统的运行情况。（2）、降低过载测试任务的优先级，使原来优先级较高的任务可以正常运行，优先级较低的任务受到影响，运行一段时间，观察系统的运行情况。（3）、重复步骤2，使各优先级的任务均受到过过载干扰。[测试的期望结果]CPU过载时应能自动启动流控，降低业务流量，同时，系统运行的各种业务不应出错，输入输出的各类消息顺序保持不变。安全性测试1、SQL注入漏洞检测SQL注入漏洞攻击检测分为入侵前的检测和入侵后的检测。入侵前的检测，可以通过手工方式，也可以使用SQL注入漏洞扫描工具软件。检测的目的是为预防SQL注入漏洞攻击，而对于SQL注入漏洞攻击后的检测，主要是针对审计日志的查看，SQL注入漏洞攻击成功后，会在WebService和数据库的审计日志中留下“痕迹”。检测方法如下：（1）动态SQL检查动态的SQL语句是一个进行数据库查询的强大的工具，但把它和用户输入混合在一起就使SQL注入成为了可能。将动态的SQL语句替换成预编译的SQL或者存储过程对大多数应用程序是可行的。预编译的SQL或者存储过程可以将用户的输入作为参数而不是命令来执行，这样就限制了入侵者的行动。当然，它不适用于存储过程中利用用户输入来生成SQL命令的情况。在这种情况下，用户输入的SQL命令仍可能得到执行，数据库仍然存在SQL注入漏洞攻击的危险。（2）有效性校验如果一个输入框只可能包括数字，那么要通过验证确保用户输入的都是数字。如果可以接受字母，检查是不是存在不可接受的字符，那就需要设置字符串检查功能。确保应用程序要检查以下字符：分号、等号、破折号、括号以及SQL关键字。（3）数据表检查使用SQL注入漏洞攻击工具软件进行SQL注入漏洞攻击后，都会在数据库中生成一些临时表。通过查看数据库中最近新建的表的结构和内容，可以判断是否曾经发生过SQL注入漏洞攻击。（4）审计日志检查在Web服务器中如果启用了审计日志功能，则WebService审计日志会记录访问者的IP地址、访问时间、访问文件等信息，SQL注入漏洞攻击往往会大量访问某一个页面文件（存在SQL注入点的动态网页），审计日志文件会急剧增加，通过查看审计日志文件的大小以及审计日志文件中的内容，可以判断是否发生过SQL注入漏洞攻击事件；另外还可以通过查看数据库审计日志，查询某个时间段是否有非法的插入、修改、删除操作。（5）其他SQL注入漏洞攻击成功后，入侵者往往会添加特权用户（如：administrator、root、sa等）、开放非法的远程服务以及安装木马后门程序等，可以通过查看用户帐户列表、远程服务开启情况、系统最近日期产生的一些文件等信息来判断是否发生过入侵。SQL注入攻击源于英文“SQLInjectionAttack”。微软技术中心从两个方面对SQL注入攻击进行了描述：一是脚本注入式的攻击；二是恶意用户输入用来影响被执行的SQL脚本。StephenKost对这种攻击形式的描述是“从一个数据库获得未经授权的访问和直接检索”。SQL注入就其本质而言，是利用SQL语法，对应用程序中的漏洞的攻击。当攻击者能够操纵数据，在应用程序中插入一些SQL语句时，SQL注入攻击就发生了。理论上，这种攻击对于所有基于SQL语言标准的数据库软件都是有效的，包括MSSQLServer，Oracle，DB2，Sybase，MySQL等。特别是现在一些AQL注入攻击工具的出现，使得Web应用更易遭到SQL注入攻击。原始的手工测试不适用于大型Web应用程序，可使用N-Stealth、WebInspect、WiktoWebScarab、Nikto等工具进行扫描，测试系统是否存在SQL注入的安全漏洞。为防止SQL注入，程序员编写代码时，要对客户端和服务端进行两级检查。检查数据类型、数据长度和敏感字符的合法性。客户端检查可减少网络流量，降低服务器负荷，将一般误操作、低等级攻击与高等级攻击行为区分开来。对于绕开客户端检查的攻击，提交的数据被直接发往服务端，服务端检查到的提交异常基本可以认定为恶意攻击行为所致，就应中止提交信息的处理，进行攻击备案，并对客户端给出出错或警告提示。另外，在构造查询时，应根据用户输入的内容设置参数值来创建参数化查询，从而避免SQL注入及由此带来的安全问题。2、表单漏洞检测⑴表单数据提交测试。对表单数据提交的测试，主要检查程序中是否对表单所提交数据的完整性、正确性进行了验证（如果在页面部分进行验证的话），如：查询条件输入一些特殊字符，比如“--”，“‘，，’”，““”等会使查询的SQL语句出错检查程序中是否屏蔽了表单提交的html语句、VBScript和Jscript等客户端脚本语句检查是否会出现“脚本利用”问题检查程序是否对表单域长度进行了真正的限制检查是否存在重复提交数据的问题检查这些验证是否在服务器端进行对表单提交数据的测试，可以采用手工和编写可重复使用的脚本代码相结合的方法，进行边界值测试、等价类测试，以及异常类测试。编写的脚本代码可以在测试、回归测试时运行。若在测试中发现数据完整性、正确性验证只是在客户端进行，应在服务器端增加对表单提交数据的验证，防止出现本地提交表单的漏洞。⑵本地提交表单的漏洞测试。本地提交表单的漏洞容易受到参数篡改的攻击。这类测试可用手工的方式进行。对于如下用户注册页面：Cookie欺骗监测如果系统使用了cookie，就要对cookie的使用情况进行检测。检查Cookies在生存期内能否正常工作而且对这些信息是否加密，是否按预定的时间进行保存，是否存在cookie可被伪造提交的问题，刷新对Cookie有什么影响及过期处理等。用户身份验证检测测试有效和无效的用户名和密码，测试是否大小写敏感，是否有最大字符数的限制规则等。测试重试次数的限制，如果登录失败的次数超过允许值，应用程序将会做出何种反应（譬如拒绝此IP地址在短时间内的登录）。测试是否可以利用历史登录信息或以前的URL来绕开登录程序。测试执行添加、删除、修改等动作中是否需要登录操作，退出系统之后的操作是否仍可继续等。测试用户密码是否符合指定要求（字符、长度），如果不符合，对有什么影响，新用户自己修改密码后，创建时分配的密码是否会失效。测试用户账户过期后，是否完全、正确的删除其信息或使其失效。是否存在不验证而直接进入Web应用系统的问题，是否存在不登录就可查看非会员页面和权限问题。用户身份验证测试一般使用手工和测试工具相结法的方法，若在测试中发现问题，应及时修改代码，使用加密码算法对密码加密，采用Session对象进行登录验证。文件操作漏洞检测测试系统是否允许上传脚本文件、可执行文件等有可能给系统带来危害的文件。若有下载功能，可供下载的文件是否与系统的程序分别存放，是否存在数据库文件、包含文件和页面文件下载的可能。文件操作漏洞测试一般使用手工测试的方法，若发现问题，应及时修改代码并将可供下载的文件重新布署。Session漏洞检测Session互窜Session互窜即是用户A的操作被用户B执行了。验证Session互窜，其原理还是基于权限控制，如某笔订单只能是A进行操作，或者只能是A才能看到的页面，但是B的session窜进来却能够获得A的订单详情等。Session互窜方法：多TAB浏览器，在两个TAB页中都保留的是用户A的session记录，然后在其中一个TAB页执行退出操作，登陆用户B，此时两个TAB页都是B的session，然后在另一个A的页面执行操作，查看是否能成功。预期结果：有权限控制的操作，B不能执行A页面的操作，应该报错，没有权限控制的操作，B执行了A页面操作后，数据记录是B的而不是A的。Session超时基于Session原理，需要验证系统session是否有超时机制，还需要验证session超时后功能是否还能继续走下去。测试方法：打开一个页面，等着10分钟session超时时间到了，然后对页面进行操作，查看效果。多TAB浏览器，在两个TAB页中都保留的是用户A的session记录，然后在其中一个TAB页执行退出操作，马上在另外一个页面进行要验证的操作，查看是能继续到下一步还是到登录页面。Session测试主要检查Web应用系统是否有超时的限制，也就是检查用户登录后在一定时间内没有点击任何页面，是否需要重新登录才能正常使用，检查超时后能否自动退出，退出之后，浏览器回退按钮是否可以回到登录页面。Session测试一般使用手工测试和工具测试相结合的方法，若发现问题，应及时修改代码。跨网站脚本（XSS）漏洞测试对于呈增长趋势的跨站脚本（XSS）攻击，可使用内嵌检测的方式进行处理。使用WebInspect工具识别所有的假造参数，使用DevInspect工具通过特定代码关联在页面上发现安全缺陷，对于显示代码，采用CSEHTMLValidator工具进行测试。若在检测中发现系统存在跨站脚本(XSS)漏洞，使用输出数据编码也就是将任何数据返回给用户前均采用HTML编码，可以有效防止跨站点脚本攻击。因为通过HTML编码，可将大多数脚本命令自动转换为无害文本。互通测试MPCP帧格式的验证OAM发现流程测试发现、认证和注册功能测试OLT对ONU的逻辑标识认证功能混合认证功能测试上行带宽分配功能测试下行加密功能测试ONU的PON光接口指标测试光链路测量和诊断功能测试ONUVLAN功能测试ONUVLANTrunk功能测试ONUN:1VLAN汇聚功能测试ONUQoS功能及业务应用验证测试ONU以太网端口的PAUSE帧流控功能单元测试单元测试是软件开发过程中的一种技术性行为，目的是检查每个程序模块或模块组的功能是否达到设计的要求。单元测试常和程序调试(Debug)结合在一起，由编写本模块的程序员自行设计和进行。单元测试通常采用白盒测试法(WhiteBoxTest)，通过分析程序模块或模块组的内部结构和模块间的接口要求设计测试用例，按增量法的原则逐步扩大测试的范围。单元测试完成后程序员必须将测试的主要内容、方法和数据等整理记录并填写测试报告。入口条件：程序模块编写完毕并能通过编译。出口条件：程序模块在设定的条件下能正常的运行，对输入的合理数据和可预见的不合理数据都能正确地处理，不出现死机或死循环现象且返回正确的信息。能提供正确的编译和运行条件及方法。集成测试集成测试是将系统的某个完整的组成部分或整个系统放在模拟的实际应用环境中运行，检测和发现各功能模块在互相协作上的问题，以及系统完成的功能与设计目标的距离。进行集成测试的条件是所有有关的程序模块都完成了单元测试（不能单独测试的模块例外）。集成测试必须从系统的功能、数据的完整性和正确性、系统的安全性和可靠性（强壮性）、大容量和并发性等方面进行重点测试。首先，根据需求规模说明书中规定的性能指标，对网络系统进行性能测试，以确认在未上应用之前网络系统的性能满足合同要求。然后，在独立的环境中，再次独立地演示应用子系统的功能，并运行部分在实验室中进行过的接口与集成测试，以此来证明该子系统可以接收全面集成测试了。一旦确信所有子系统的功能稳定，就将开始整体验收测试。整体验收测试将核实在全面集成环境中整个系统所有的特点、功能及性能需求。集成测试是系统开发过程中的一个重要的步骤，必须有计划、有组织地进行，通常由系统开发人员自行组织和实施，QA人员提供帮助和监督。入口条件：参加集成测试的程序模块都通过了单元测试，且模块之间有一定的逻辑联系，能够实现特定的系统功能。出口条件：系统的部分或整体能够正常地运行，对输入的有效和无效数据、正确的和不正确的操作、正常和不正常的工作环境等都能正确地处理，并给出合理的信息或结果。有完整的文档，说明系统的安装条件和运行方法。

从内容上分，该阶段的集成测试至少包括以下几种类型：功能测试：对各子系统根据需求调研文档和重构文档中所描述的功能逐项进行测试，以确认该软件具备合同中所规定的各项功能。例如应用安全系统、数据交换共享平台等。强度测试（压力测试）：一是测量在目前的系统架构下面能否满足客户方所设计的业务流量需求，反过来而言即是验证目前应用系统的业务响应时间；二是测试目前的系统架构所能支持的最大业务流量。同时在该测试过程中对整个系统中各部分的参数配置着相应的调整，以使整个系统在一个最佳的环境中运行。接口测试：接口测试是为了保证不同子系统之间的接口正确性，从而验证信息在不同子系统之间的及时、准确的流动，完成管理信息系统的整体功能需求，而这一切的依据便是不同子系统之间签定的接口文档。验收测试验收测试又称FAT(FactoryAcceptanceTest)，是软件产品在验收出厂(Release)和正式递交给用户使用(Delivery)前必须进行的一种测试行为。其目的是检验最终产品与预期目标（用户的需求）间的符合情况。验收测试常采用黑盒测试法(BlackBoxTest)，以系统应当实现的功能为主线，按照客户提出的需求和系统目标确定测试范围和设计测试用例。验收测试还应包括系统的安装步骤、兼容性和用户使用手册等非程序性的内容。验收测试应由公司指定的质量管理机构组织和实施，由项目组和QA人员分工合作，共同进行。验收测试的测试计划和测试用例的开发等工作应与项目的开发过程同步进行。程序开发人员必须向测试人员提供有关的文档资料、程序的编译、配置与运行方法、运行的环境要求和及时有效的技术支持。验收测试的测试结果必须报告公司管理层。入口条件：系统完成和通过了整体的集成测试，能够正常的运行。出口条件：系统完成了所有的测试用例，并对发现的问题给出明确的答案。项目验收系统验收流程系统验收的一般过程如下：由项目组书面提出验收申请，申请进行项目验收项目组提交项目相关技术文档用户方相关业务部门对应用系统功能进行确认，对于应用系统中功能不满足合同要求的，项目组将安排在短期内进行修正，并重新提交业务部门确认用户方相关技术部门对软件集成工作进行确认。在确认工作过程中，我方工程师将会同业主相关技术人员对系统进行一次全面检查。对于不满足合同要求的地方，将安排在短期内修正用户方项目负责人对整体项目建设工作进行确认编制验收报告和验收用户意见召开专家评审会、举行验收签字仪式验收准则按照上海信息化项目管理的有关规定，以竞争性谈判文件、合同及项目任务书为标准。根据系统设计技术和功能要求，进行完善的测试和验收。提供测试文档和验收文件，完成所有的用户培训，提供全套完善的档案资料，包括应用系统的源代码，做好系统的移交工作。提交技术文件验收时，我方会提供与其提供的软件通相一致的技术文件。提供的技术资料将能够满足用户对系统安装、管理及运行维护等的需要。我方提供的技术文件包括：项目用户需求说明书项目概要设计项目详细设计项目需求规格说明书项目集成测试方案、项目集成测试记录、项目集成测试报告项目用户接收测试方案、项目用户接收测试记录、项目用户接收测试报告系统用户操作使用手册（安装、操作、维护、故障排除等）项目试运行报告项目技术报告、项目研制报告等系统安全评估报告验收合格条件系统最终验收合格的条件通常为：系统设计各项功能满足双方的需求约定试运行中出现的问题均得到解决提供了业务合同规定的技术文档验收方法初验：在系统通过系统测试后，完成安装、调试及培训后，由提交初验申请，进行系统初验，双方共同签署初验报告。系统初验通过后系统正式上线试运行。在设备安装、带少量业务调测达到规定指标后，可按双方确认的方式和标准进行初验。初验结果经双方签字后生效。试运行：初验合格即可投入试运行。在运行期间，投标方负责网络的调整、优化，并提供相关的技术支持。在此期间由于设备自身的原因及安装调试原因出现的问题均必须由投标方负责及时处理。但在修复后应重新开始计算试运行期。终验：在系统试运行后，我司提出最终验收申请，由双方共同组织人员对系统进行验收工作，验收工作结束后，双方共同签署验收报告，标志系统验收完成，进入系统维护期。项目培训和和功能调试在项目的推广和应用培训上将分别面向不同的用户对象，设计完整的培训体系，灵活采用多种培训方法，组织开展人员的应用培训，进行项目的应用推广。后期维护与应用升级在项目维护和应用调整上将针对项目的实施、后期和长期合作，提供一整套的服务体系，包括项目的前期咨询服务、项目建成后的保障服务和后期运行维护过程中的全面护航服务等三类服务方式，从人员管理方面、数据资源管理方面、应用管理方面等各个层面对招标方提供的支持。应用的维护和升级将贯穿项目建成后的保障服务和后期运行维护过程中的全面护航服务过程，保障应用系统具有长久的生命力。项目组织管理1) 项目组织结构规范项目经理将进行资格认证、授权及工作考核软件测试将配备专职测试人员公司将指派专职QA人员全程监督项目实施过程的质量和规范执行情况配备专职配置管理人员进行软件版本控制、配置项变更控制、软件发布管理、文档管理等2) 软件开发规范开发过程流程规范：包括软件开发过程定义，各项开发工作的步骤及流程开发文档规范：包括软件生命周期各阶段必须产生的技术文档及格式内容项目人力资源管理机制项目实施过程中人力资源管理是项目管理中一项十分重要工作，项目实施成功主要依靠公司整体的实力，依靠组织的制度与纪律。我司的质量体系中具有一套完善的项目管理规范，本项目实施将通过执行这些规范来保证有效的项目人力资源管理：项目组每个员工都已经按照公司培训制度接受管理规范的培训，从而保证项目人员具备合格的知识技能来完成其工作；通过项目质量量化管理机制（根据缺陷率进行考核），考核及奖惩制度激励员工追求上进、努力工作；项目组每个员工填写日报，提高项目实施过程的透明度；项目人员的工作成果定期组织审核与评审，以保证项目每一项实施工作的正确性；项目人员所有的工作成果纳入到配置管理库中，以保证项目实施工作的完整性；项目人员所有工作都必须按照“文档交付”章节提交文件，以保证项目实施工作可追溯性及可跟踪性；项目组成员必须必须按照“项目会议制度”章节执行沟通规范，以保证交流的效率及有效性，充分体现项目人员每个个人的尊严与价值；组织结构一套健全有效的组织和领导机构是贯彻工程意图和顺利进行工程实施的重要条件和保证。在工程规划之初，首要的是提出并组建起适于本项工程实施和管理的全套组织和领导机构。从实施和管理的职责看这套组织应是完整配套的，从人员构成素质看这套组织应是精练高效的。组织结构建议甲方公司和我司共同成立项目组，采用项目领导小组下的各方项目经理负责制，并明确规范所属下级各组的职责及组间协调关系。为工程验收，设置了直属项目领导小组之下的多方方共同组成的验收小组。这种结构是在多个大型工程项目中采用，并被验证为行之有效的工程组织方案。建议项目组织结构图如下所示：图组织架构图机构中人员构成与职责项目领导小组由招标方与我公司的相关领导组成，主要负责提供行政业务上的保证（为项目的前期调研和后期的需求变更确认，以及项目的实施等各项工作的顺利开展，提供人力、物力、财力上的保证），负责项目实施过程中的重大事件的决策，根据项目过程中的进度、质量、技术、资源、风险等实行宏观监控等。项目组会定期向管理领导小组汇报项目进度。一、项目领导小组工作职责1、审核批准项目的总体方案、实施计划、把握需求，控制进程；2、项目团队总体管理；协调各方面关系；3、负责项目实施过程中的重大事件的决策；4、根据项目过程中的进度、质量、技术、资源、风险等实行宏观监控；5、协调参与项目的各级业务单位与我公司双方关系；6、重大项目变更的决策；7、对项目的执行、质量进行监督和调控。二、项目经理职责1、与用户讨论并确定最终项目范围和实施方法；2、负责制订具体的项目计划，包括培训计划；3、把握项目各方面的进程；4、指导业务流程重组和项目变更；5、检查及调控项目实施范