企业运营管控典型场景项目实施方案1.1实施策略制定科学合理的项目实施计划，明确信息部门、实施厂商、运维团队的职责与分工，按照进度和里程碑要求进行实施，实施过程引入严格的风险识别、风险分析和风险控制机制，保证各个阶段的质量。

本项目将按照数据仓库的开发思路进行整体设计，结合数据中心现有项目的情况，本项目的实施策略总结如下：按类型、业务域分类，对于相同类型的应用按需求应用率高低合理安排开发周期和开发顺序。

1.2项目开发1.2.1开发思路2014年企业运营管控典型场景建设大体思路是先完成数据存储层构建，然后建设公共运营管控服务，最后进行运营管控支持应用建设。

其中数据存储主要包括实时运营管控数据构建、历史管控数据构建；而公共运营管控服务主要是实现数据加载的自动管控，实现从各分子公司业务系统抽取业务数据加载到数据库，然后统计分析为运营管控支持应用提供数据支撑。

而运营管控支持应用建设则遵循软件项目开发的一般流程，即需求分析->概要设计->详细设计->编码实现->程序测试->系统部署。

1.2.2开发内容2014年企业运营管控典型场景建设主要实施以下内容：✧数据存储构建数据存储层构建的目标是提供运营管控支撑数据实时查询分析、历史数据趋势分析及预测等的数据的查询存储服务、利用组织数据更好有效的辅助运营管控过程。

数据仓库构建包含了基础数据存储区和共享数据区的模型分析、模型设计和结构搭建。

✧公共运营管控服务功能研发公共运营管控服务功能目的是在原有分散的数据库数据抽取汇总和整理得到的运营管控数据，以保证运营款控数据信息实时性、完整性、准确性的一致的全局信息。

负责日常数据抽取、拆分、合并，进而被用来进一步理解数据。

作业管理维护，根据业务要求实现实时运作业流程和作业处理程序；实现运营管控数据处理功能；实现运作流程管理功能，可灵活设置运作流程；实现监控运作监控管理功能。

✧运营管控支持应用开发实现企业运营管控典型场景项目的资产生命周期管理运营管控典型场景、客户全方位服务运营管控典型场景、财务管理运营管控典型场景、横向业务协同管控典型场景的功能设计及研发：实现资产生命周期管理运营管控典型场景相关功能：资产综合绩效管控典型场景、资产运营状况管控典型场景、资产关键流程管控典型场景等功能设计及研发；实现客户全方位服务运营管控典型场景相关功能：生产可靠型指标分析的可靠性指标分析、因果关系指标分析、指标变动分析；生产设备综合扩展分析等功能设计及研发；实现财务管理运营管控典型场景相关功能：财务管理综合绩效管控典型场景、财务管理运营状况管控典型场景等功能设计及研发；实现横向业务协同管控典型场景相关功能：运营管控典型场景等功能设计及研发。

1.3系统测试软件测试是软件开发过程中的一个重要组成部分，是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题与用户需求、预先定义的不一致性。

我公司根据长期的项目建设过程中积累的系统测试经验，建议本项目可从如下几方面开展系统测试工作：1.3.1测试内容系统测试目的是为了确保各项功能和性能指标能够达到预期目标，测试的内容包括：1.功能测试主要测试系统各项功能是否达到预期目标，测试的对象包括：管理驾驶舱、决策事项等各项功能。

2.性能测试主要测试系统的处理能力，包含的内容有：系统容量、接入能力、系统处理能力、响应性能等。

3.可用性测试可用性测试是改善产品的最佳方式之一，它是让一群有代表性的用户尝试对产品进行典型操作，同时测试人员和开发人员在一旁观察，聆听，做记录，收集用户在系统使用上的意见，最终把所有用户的意见汇总、评估，形成系统的改进点。

4.安全性测试安全性测试是有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。

安全性测试并不最终证明应用程序是安全的，而是用于验证所设立策略的有效性，这些对策是基于威胁分析阶段所做的假设而选择的。

1.3.2测试策略我公司依据对本项目的理解，制订了如下的系统测试策略：1.迭代化测试为保证测试的全面性、防止关联性错误，测试采取逐步深入的方法，每个阶段都需要规划多轮测试。

因此，在每一个测试阶段，依据阶段测试目标，需要制定每阶段的迭代测试计划，并设定每轮迭代测试的目标和完成准则。

在每轮迭代测试实际开始前需要根据项目实际进度修正各轮迭代测试的目标。

2.顺序推进、并行测试对模块间业务逻辑依赖不紧密的功能，例如：管理驾驶舱、报表等功能，将采取并行推进的测试方法。

这种方法既可以单项验证各业务功能的正确性，又可以加快整体测试进度。

对模块间业务逻辑依赖紧密的功能，即上游模块的输出是下游模块的输入，例如：登录、报表查询等功能，在每轮测试过程中，将采取顺序推进的测试方法，以便有效验证模块间的接口逻辑和数据传递的正确性。

3.手工与自动化测试相结合由于需要对系统进行反复多轮测试，利用测试工具将部分关键测试用例自动化。

4.综合运用各种测试技术➢测试过程采用黑盒测试法，所有测试数据的录入、查询、核对通过系统功能页面进行；➢通过分析业务需求和业务功能说明书，使用用例场景技术分析确定测试用例的基本流和备选流；➢测试场景设计时需要尽量考虑打破常规的业务规则，考虑各种可能的业务组合，验证系统的容错性；➢测试用例数据设计时，需要综合运用等价类划分法、因果图法、判定表法、边界值测试方法、正交试验设计法等方法组织规划测试用例。

1.3.3测试标准1.3.3.1测试进入准则➢开发人员提交被测系统的业务需求、业务功能说明书；➢开发人员提交可运行的被测系统，且被测系统已通过开发人员的单元测试；➢测试所需的业务规则配置已确定。

1.3.3.2测试完成准则➢测试用例设计经过同行评审和用户认可；➢业务需求100%覆盖；测试用例100%得到成功执行；➢测试报告得到用户签字确认。

1.3.3.3测试通过标准1.3.4测试方法与技术1.3.4.1功能测试方法1.3.4.1.1用户界面测试好的用户界面要素：符合标准和规范、直观性、一致性、灵活性、舒适性、正确性、实用性。

1.3.4.1.2核心业务逻辑检查核心业务处理实现是否正确，验证系统对每个逻辑分支或可能的输入、输出项都做了友好的异常处理。

1.3.4.1.3模块间或子系统间检查模块间和子系统间功能执行的连贯性、正确性。

1.3.4.1.4文档测试检查文档的正确性、完备性、可理解性。

1.3.4.2非功能测试方法针对决策支持系统快速响应性、可用性、安全性要求较高等特点，在非功能测试方面，主要利用LoadRunner或编写测试程序等测试工具，以及采用编写测试程序等方法，分别模拟系统的实际运行、各种可能的非法操作、外部攻击等。

测试必须在与生产环境基本具备可比性的环境下进行，并设计多轮迭代，以便可保证测试采样的真实性、可靠性。

1.3.4.3测试用例技术1.3.4.3.1用例技术说明测试用例指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

测试用例的设计和编制是软件测试活动中最重要的。

测试用例是测试工作的指导，是软件测试的必须遵守的准则。

在最初测试时，一般测试用例是考虑不周全的，需要随着测试的进行和软件版本更新，逐步深入、日趋完善。

针对本项目的测试，较好的做法是把测试数据和测试脚本从测试用例中划分出来。

测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的实施方案。

对测试用例描述的详细和复杂程度有时难以明确要求。

测试需要在给定的资源、时间条件下尽可能达成目标，我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行，测试用例的详细程度根据需要确定：对核心的复杂流程和算法，测试用例必须明细到每一步可能的分支；对系统中各个功能模块都需要的通用测试用例，可以提炼通用的测试要素，制定详细的测试用例，而不需在每个用例中重复，以节省编写时间和执行时间，提高用例的复用性。

如：日期校验、金额合法性检查、输入字段合法性检查等。

1.3.4.3.2测试用例设计方法1.3.4.3.3测试用例应用1.指导测试的实施在实施测试时测试用例作为测试的准则和指导，测试执行人员一定要按照用例严格按测试项目和测试步骤逐一实施测试，并将测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

根据测试用例的测试等级，每一轮迭代测试哪些用例在设计用例时都已作明确规定，测试执行时测试人员不能随意作变动。

2.规划测试数据的准备在我们的实践中测试数据是与测试用例分离的。

按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。

尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

3.编写测试脚本的"设计规格说明书"为提高测试效率，软件测试应大力发展自动测试。

自动测试的中心任务是编写测试脚本。

如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

4.评估测试结果的度量基准完成测试实施后需要对测试结果进行评估，并且编制测试报告。

判断软件测试是否完成、衡量测试质量需要一些量化的指标。

例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。

以前统计基准是软件模块或功能点，显得过于粗糙。

采用测试用例作度量基准更加准确、有效。

5.分析缺陷的标准通过收集缺陷，对比测试用例和缺陷数据库，分析确认是漏测还是缺陷复现。

漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步保障软件质量。

而已有相应测试用例，则反映测试实施或变更处理过程中存在问题。

6.测试用例的评审测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。

测试用例在设计编制过程中要组织同级互查。

完成编制后应组织专家评审，需获得通过才可以使用。

评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

7.测试用例的修改更新测试用例在形成文档后也还需要不断完善。

主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。

软件的版本升级更新，测试用例版本一般也应随之编制升级更新。

1.3.4.3.4测试用例管理运用测试用例还需配备测试用例管理软件。

它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值、测试覆盖表和测试通过或不通过的测试用例清单列表。