免费智能真题库 > 历年试卷 > 信息系统监理师 > 2018年上半年 信息系统监理师 下午试卷 案例
  第1题      
  知识点：   承建单位   管理能力   管理能力   设计阶段   需求分析   验收测试   背景   测试过程   测试计划   测试阶段   功能需求   开发过程   软件需求   数据管理   数据库   数据库设计   数据库设计说明   维护   信息管理   信息管理系统   需求分析阶段

 
（共20分）
阅读下列说明，回答问题1至问题4,将解答填入答题纸的对应栏内。
【说明】
X省交通厅拟建设省级智慧交通信息管理系统，聘请A公司作为该信息系统的监理机构。
【事件1】在软件开发过程中，承建单位表示，会在需求分析阶段编制《软件需求规格说明》、《数据库设计说明》，在设计阶段编制《软件功能设计说明》，在测试阶段编制《测试计划》，在系统交付后的维护阶段编制《用户手册》和《操作手册》。
【事件2】承建单位提交了《软件需求规格说明》，章节包括:背景说明、对功能需求的规定、对输入输出要求的说明、对数据管理能力的说明、对运行环境的规定。监理工程师审查通过。系统交付测试时，交通厅发现系统难以负载海量数据、故障频发，导致系统无法上线，据此认为监理工程师对需求分析不完整负有直接责任并要求追责。
【事件3】监理工程师在验收测试阶段认真检查了承建单位的测试方案、测试过程。
 
问题：1.1  

（4分）
针对事件1，作为监理工程师，你是否同意承建单位的文档编制计划？为什么？
 
问题：1.2   （5分）
针对事件2:
（1）请指出监理工程师审核《软件需求规格说明》的错漏之处。
（2）交通厅针对监理工程师对需求分析不完整负有直接责任的问题进行追责，你是否认同？为什么？
 
问题：1.3   （5分）
针对事件3，请指出监理工程师在测试阶段的质量控制过程中，除了测试方案和测试过程，还应监理哪些内容？
 
问题：1.4   （6分）
关于在信息网络系统过程控制中常用的监理方法，从候选答案中选择一个正确选项，将该选项编号填入答题纸对应栏内（候选答案可重复选择）。
（1）：验证承建方的网络设计方案是否能够满足业主方的需要。
（2）：主要适用于网络设备的选型和采购。
（3）：对于某些网络的连通性和通信质量进行一定比率的测试。
（4）：比较适合于网络综合布线的质量控制。
（5）：通过必要的网络测试工具，对网络的性能进行测试。
（6）：用于某些关键网络设备的质量保证。
A.评估 B.网络仿真 C.现场旁站 D.抽查测试/测试 E.网络性能测试
 
 
 

   知识点讲解    
   · 承建单位    · 管理能力    · 管理能力    · 设计阶段    · 需求分析    · 验收测试    · 背景    · 测试过程    · 测试计划    · 测试阶段    · 功能需求    · 开发过程    · 软件需求    · 数据管理    · 数据库    · 数据库设计    · 数据库设计说明    · 维护    · 信息管理    · 信息管理系统    · 需求分析阶段
 
       承建单位
        负责具体实施的承建方应该有自己的项目管理，监理方代表项目建设方对承建方提出的工程计划进行监督和协调，对一些关键点进行控制。这些关键点主要属于进度、资金及质量的范畴，但不能涉及管理细节。工程项目管理主要以承建方为主，并强调在项目中组织并制定相关计划。
        在一个大型信息系统工程项目的建设中，承建方可能有多个，比如硬件提供商、软件开发商和系统集成商等。而在市场竞争日益激烈的今天，专业化能促进生产效率和提高生产质量，故而承建方常常分解成一定的层次结构，如总承包商和分包商等，从而使一部分人或企业专注于项目管理的科学化。
        从市场的角度看，总承包商既是买方又是卖方；从工程合同的角度来讲，他既要对建设方负全部法律责任，又要根据分包合同对分包商进行管理并履行义务，所有的主合同都会限定总承包商可以分包的最大范围。总承包商只能将某些具体的工程施工分包给分包商，但不能分包合同的责任和义务。总承包商不能期望通过分包逃避自己在合同中的法律和经济责任。
        作为分包商，一般情况下不与建设方直接发生合同关系。分包商只接受总承包商的统筹安排和调度，它只对总承包商承担分包合同内规定的责任并履行规定的义务。
        如果总承包商违反分包合同，则应该赔偿分包商的经济损失；分包商违反分包合同并造成建设方对总承包商的罚款或制裁，则分包商应该赔偿总承包商的损失。分包商是从总承包商处按分包合同索回其应得部分的，如果总承包商无力偿还债务，则分包商也同样蒙受损失，因此分包商的利益通常与总承包商的利益密切相关。
 
       管理能力
        .已建立完备的企业质量管理体系，通过国家认可的第三方认证机构认证并有效运行一年以上。
        .已建立完备的客户服务体系，配置专门的机构和人员，能及时、有效地为客户提供优质服务。
        .已建成完善的企业信息管理系统并能有效运行。
        .企业的主要负责人应具有5年以上从事电子信息技术领域企业管理经历，主要技术负责人应获得电子信息类高级职称且从事系统集成技术工作不少于5年，财务负责人应具有财务系列中级以上职称。
 
       管理能力
        .已建立完备的企业质量管理体系，通过国家认可的第三方认证机构认证并有效运行一年以上。
        .已建成完备的客户服务体系，配置专门的机构和人员，能及时、有效地为客户提供优质服务。
        .已建成完善的企业信息管理系统并能有效运行。
        .企业的主要负责人应具有4年以上从事电子信息技术领域企业管理经历，主要技术负责人应获得电子信息类高级职称且从事系统集成技术工作不少于4年，财务负责人应具有财务系列中级以上职称。
 
       设计阶段
        设计阶段监理进行质量控制的要点如下。
        （1）了解建设单位的建设需求和对信息系统安全性的要求，协助建设单位制定项目质量目标规划和安全目标规划。
        （2）对各种设计文件提出设计质量标准。
        （3）进行设计过程跟踪，及时发现质量问题，并及时与承建单位协调解决。审查阶段性成果，并提出监理意见。审查承建单位提交的总体设计方案，审查承建单位对关键部位的测试方案。
        （4）协助承建单位建立质量保障体系。
        （5）协助承建单位完善现场质量管理制度。
        （6）组织设计文件及设计方案交底会，制定质量要求标准。
 
       需求分析
        软件需求分析监理的主要任务和目的是对软件需求分析的相关内容（重点是工程需求、功能需求、性能需求和设计约束等）、需求分析过程、需求分析活动及文档格式进行审查，确认是否满足要求，并确定其可否作为软件开发的前提和依据。
        （1）参与用户需求调研，尤其是关键业务及有甲乙双方决策人物参与的大型交流会等。
        （2）组织有关单位参加《需求规格说明书》技术联合评审会议，并根据国家相关标准、软件工程理论、用户需求及工程建设合同等进行审查并提出监理意见。
        （3）根据项目管理的理论，审核承建单位递交的《项目开发计划》。审核的重点是项目参与人员的技术工作背景是否适应本项目、工作分配及进度计划是否合理，以及软件开发风险因素分析、风险防范措施是否到位等。
        （4）审核承建单位提交的软件开发的质量保证及配置管理计划等软件生存周期支持过程的文档。
        （5）审核承建单位针对本工程投入的软硬件资源是否满足工程需要并及时到位。
        （6）审核承建单位在开发过程中使用的软件工具的合法性。
        （7）主持监理例会，做好监理日记，定期将项目进展情况及发现的问题汇总，并以项目月报的形式向项目建设单位做书面汇报。
        （8）做好项目往来文档的整理及存档工作。
        在需求分析阶段，监理工作的重点是对软件需求规格说明书和项目开发计划的审核。
 
       验收测试
        验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求的那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统了，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能是否如同用户所合理期待的那样。
        验收测试的结果有两种可能：一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
               验收测试的常用策略
               验收测试通常可以分为正式验收和非正式验收，具体选择的策略通常建立在合同需求、组织和公司标准，以及应用领域的基础上。
                      正式验收测试
                      正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。
                      在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。这种测试形式的优点是：
                      .要测试的功能和特性都是已知的。
                      .测试的细节是已知的，并且可以对其进行评测。
                      .这种测试可以自动执行，支持回归测试。
                      .可以对测试过程进行评测和监测。
                      .可接受性标准是已知的。
                      缺点包括：
                      .要求大量的资源和计划。
                      .这些测试可能是系统测试的再次实施。
                      .可能无法发现软件中由于主观原因造成的缺陷，这是因为只查找了预期要发现的缺陷。
                      非正式验收测试
                      在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。
                      大多数情况下，非正式验收测试是由最终用户组织执行的。这种测试形式的优点是：
                      .要测试的功能和特性都是已知的。
                      .可以对测试过程进行评测和监测。
                      .可接受性标准是已知的。
                      .与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
                      缺点包括：
                      .要求资源、计划和管理资源。
                      .无法控制所使用的测试用例。
                      .最终用户可能沿用系统工作的方式，并可能无法发现缺陷。
                      .最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
                      .用于验收测试的资源不受项目的控制，并且可能受到压缩。
               验收测试的条件
               在真正进行用户验收测试之前，一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）。
               （1）软件开发已经完成，并全部解决了已知的软件缺陷。
               （2）验收测试计划已经过评审和批准，并且置于文档控制之下。
               （3）对软件需求说明书的审查已经完成。
               （4）对概要设计及详细设计的审查已经完成。
               （5）对所有关键模块的代码审查已经完成。
               （6）对单元、集成、系统测试计划和报告的审查已经完成。
               （7）所有的测试脚本已完成，并至少执行过一次，且通过评审。
               （8）使用配置管理工具且代码置于配置控制之下。
               （9）软件问题处理流程已经就绪。
               （10）已经制定、评审并批准验收测试完成标准。
               验收测试的过程
               （1）软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。
               （2）编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并制订出经过客户参与评审的计划。
               （3）测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。
               （4）测试环境搭建：，建立测试的硬件环境和软件环境等（可在委托客户提供的环境中进行测试）。
               （5）测试实施：测试并记录测试结果。
               （6）测试结果分析：根据验收通过准则分析测试结果，做出验收是否通过的决定，给出测试评价。
               （7）测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。
               软件配置审核
               软件配置审核包括审查和审核。
               审查是指审查可执行程序、源程序、配置脚本、测试程序或脚本、主要的开发类文档和主要的管理类文档。
               通常，正式的审核过程分为5个步骤，即计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是指对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是指最终确定工作产品中包含的错误和缺陷。
               审核要达到的基本目标是根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。
               在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面，由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。
               对软件需求说明书的审查，可以从清晰性、完整性、依从性、一致性、可行性和可管理性等几个方面考虑。对软件设计说明书（详细设计说明书、概要设计说明书）的审查，可以从清晰性、完整性、依从性、一致性、可行性、数据使用性、功能性、接口、可维护性、性能、可靠性、易测性和可追溯性等方面考虑。对测试计划（单元测试计划、集成测试计划、确认测试计划、系统测试计划）的审查，可以从完整性、依从性、一致性、正确性、详细级别／程度、易测性／可行性和可追溯性等方面考虑。对软件编码规范的审查，可以考虑源程序文档化、数据说明、输入输出等方面，评审的目的是为了使程序具有良好的风格，便于阅读。
               可执行程序的测试
               在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后，就可以进行验收测试的最后一个步骤——可执行程序的测试了，包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量5个部分。
               不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。
               验收测试的内容
               具体的测试内容通常可以包括安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）及可靠性测试等。
               如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题也都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。
 
       背景
        .项目的承担者。
        .用户。
        .本项目和其他系统或机构的关系和联系。
 
       测试过程
        软件测试过程一般包括：测试需求分析、测试策划、测试设计和实现、测试执行、测试总结（包括评价过程和总结），如下图所示。
        
        软件测试过程
               测试需求分析
               根据被测软件的需求规格说明或设计文档，进行测试需求分析，包括：
               （1）确定需要的测试类型及其测试要求并进行标识（编号），标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型；测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试级别（单元测试、部件测试、配置项测试、系统测试）、测试类型相匹配。
               （2）确定每个测试项的优先级。
               （3）确定每个测试项的测试充分性要求。
               （4）根据被测软件的重要性、测试目标和约束条件，确定每个测试项应覆盖的范围及范围所要求的覆盖程度。
               （5）确定每个测试项测试终止的要求，包括测试过程正常终止的条件（如测试充分性是否达到要求）和导致测试过程异常终止的可能情况。
               （6）确定测试项与软件需求规格说明或设计文档的追踪关系。
               将测试需求分析结果按所确定的文档要求，形成测试需求规格说明或写入测试计划。
               应对测试需求规格说明或测试需求分析结果进行评审，评审内容如下：
               （1）测试级别和测试对象所确定的测试类型及其测试要求是否恰当。
               （2）每个测试项是否进行了标识，并逐条覆盖了测试需求和潜在需求。
               （3）测试类型和测试项是否充分。
               （4）测试项是否包括了终止要求。
               （5）文档是否符合规定的要求。
               测试策划
               根据软件需求规格说明或设计文档等进行测试策划，策划一般包括：
               （1）确定测试策略，如部件或配置项测试策略。
               （2）确定测试需要的技术或方法，如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术。
               （3）确定要受控制的测试工作产品，列出清单。
               （4）确定用于测试的资源要求，包括软硬件设备、环境条件、人员数量和技能等要求。
               （5）进行测试风险分析，如技术风险、人员风险、资源风险和进度风险等。
               （6）确定测试任务的结束条件。
               （7）确定被测软件的评价准则和方法。
               （8）确定测试活动的进度。应根据测试资源和测试项，确定进度。
               应将测试策划结果，按所确定的文档要求形成测试计划。
               测试设计和实现
               应根据测试需求规格说明和测试计划进行测试设计和实现，应完成如下工作：
               （1）按需要分解测试项。将需要测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有高层次的接口图说明所有接口和要测试的接口。
               （2）说明最终分解后的测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等。
               （3）设计测试用例。
               （4）确定测试用例的执行顺序。
               （5）准备和验证所有的测试用数据。针对测试输入要求，设计测试用的数据，如数据类型、输入方法等。
               （6）准备并获取测试资源，如测试环境所必须的软、硬件资源等。
               （7）必要时，编写测试执行需要的程序，如开发部件测试的驱动模块和桩模块以及测试支持软件等。
               （8）建立和校核测试环境，记录校核结果，说明测试环境的偏差。
               应将测试设计与实现的工作结果，按照所确定的文档要求编写测试说明，测试说明一般应包括：
               （1）测试名称和项目标识。
               （2）测试用例的追踪。说明测试所依据的内容来源，并跟踪到相应的测试项的标识（编号）。
               （3）测试用例说明。简要描述测试的对象、目的和所采用的测试方法。
               （4）测试用例的初始化要求，包括硬件配置、软件配置（包括测试的初始条件）、测试配置（如用于测试的模拟系统和测试工具）、参数设置（如测试开始前对断点、指针、控制参数和初始化数据的设置）等的初始化要求。
               （5）测试用例的输入。每个测试用例输入的描述中应包括的内容：
               ①每个测试输入的名称、用途和具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）。
               ②测试输入的来源（如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（如等价类划分、边界值分析、猜错法、因果图以及功能图等）。
               ③测试输入是真实的还是模拟的。
               ④测试输入的时间顺序或事件顺序。
               （6）测试用例的期望测试结果。期望测试结果应有具体内容（如确定的数值、状态或信号等），不应是不确切的概念或笼统的描述。必要时，应提供中间的期望结果。
               （7）测试用例的测试结果评估准则。评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息，如：
               ①实际测试结果所需的精确度。
               ②允许的实际测试结果与期望结果之间差异的上、下限。
               ③时间的最大或最小间隔。
               ④事件数目的最大或最小值。
               ⑤实际测试结果不确定时，重新测试的条件。
               ⑥与产生测试结果有关的出错处理。
               ⑦其他有关准则。
               （8）实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤，执行步骤应包括：
               ①每一步所需的测试操作动作、测试程序输入或设备操作等。
               ②每一步期望的测试结果。
               ③每一步的评估准则。
               ④导致被测程序执行终止伴随的动作或指示信息。
               ⑤需要时，获取和分析中间结果的方法。
               （9）测试用例的前提和约束。在测试用例中还应说明实施测试用例的前提条件和约束条件，如特别限制、参数偏差或异常处理等，并要说明它们对测试用例的影响。
               （10）测试终止条件。说明测试用例的测试正常终止和异常终止的条件。
               （11）确定测试说明与测试计划或测试需求规格说明的追踪关系，给出清晰、明确的追踪表。
               （12）测试说明应经过评审，得到相关人员的认同，测试说明评审内容如下：
               ①测试说明是否完整、正确和规范。
               ②测试设计是否完整和合理。
               ③测试用例是否可行和充分。
               测试执行
               应按照测试计划和测试说明的内容和要求执行测试，主要完成下列工作：
               如实填写测试记录，当结果有量值要求时，应准确记录实际的量值。
               （1）测试记录应受到严格管理，并规范格式，至少包括测试用例标识、测试结果和发现的缺陷。
               （2）应根据每个测试用例的期望测试结果、实际测试结果和评估准则，判定测试用例是否通过。
               （3）当测试用例不通过时，应根据不同的缺陷类型，采取相应的措施：
               ①对测试工作中的缺陷，如测试说明的缺陷、测试数据的缺陷、执行测试步骤时的缺陷、测试环境中的缺陷等，记录到相应的表格中，并实施相应的变更。
               ②对被测软件的缺陷应记录到软件问题报告中。
               ③软件问题报告的格式应规范。
               （4）当所有的测试用例都执行完毕后，实验室应根据测试的充分性要求和有关记录，分析测试工作是否充分，是否需要进行补充测试：
               ①当测试过程正常终止时，如果发现测试工作不足，或测试未达到预期要求时，应进行补充测试。
               ②当测试过程异常终止时，应记录导致终止的条件、未完成的测试或未被修正的错误。
               测试总结
               应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录、测试问题及变更报告和软件问题报告等，对测试工作和被测软件进行分析和评价，主要完成下列工作：
               （1）对测试工作进行分析和评价，分析和评价内容应包括：
               ①总结测试需求规格说明、测试计划和测试说明的变化情况及其原因。
               ②在测试异常终止时，说明未能被测试活动充分覆盖的范围及其理由。
               ③确定无法解决的软件测试事件并说明不能解决的理由。
               （2）对被测软件进行分析和评价，分析和评价内容应包括：
               ①总结测试中所反映的被测软件与软件需求（或软件设计）之间的差异。
               ②可能时，根据差异评价被测软件的设计与实现，提出改进的建议。
               ③当进行配置项测试或系统测试时，当需要时，测试总结中应对配置项或系统的性能做出评估，指明偏差、缺陷和约束条件等对于配置项或系统运行的影响。
               （3）分析测评项目中的数据和文档，以供以后的测试使用。数据如：缺陷数据（包括缺陷描述、类型、严重性等）、用例数据、管理数据（如生产率、工作量、进度等）；文档如：好的用例设计、好的需求规格说明等。
               （4）应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录和软件问题报告等有关文档，对测试结果和问题进行分类和总结，按所确定的文档要求编写测试报告。测试报告除了应包括对测试结果的分析，还应包括对被测软件的评价和建议。
               测试总结评审应在测试报告编制工作完成后进行，以确定是否达到测试目的，给出评审结论。评审的具体内容和要求包括：
               （1）审查测试文档与记录内容的完整性、正确性和规范性。
               （2）审查测试活动的独立性和有效性。
               （3）审查测试环境是否符合测试要求。
               （4）审查软件测试报告与软件测试原始记录和问题报告的一致性。
               （5）审查实际测试过程与测试计划和测试说明的一致性。
               （6）审查测试说明评审的有效性，如是否评审了测试项选择的完整性和合理性、测试用例的可行性和充分性。
               （7）审查测试结果的真实性和正确性。
 
       测试计划
        制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程，包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。在任何类型的系统测试中，制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于：
        ①构建能够精确地模拟工作环境的测试方案。负载测试指在典型的工作条件下测试应用程序，并检测系统的性能、可靠性和容量等。
        ②了解测试需要的资源。应用程序测试需要硬件、软件和人力资源。开始测试之前，应了解哪些资源可用并确定如何有效地使用这些资源。
        ③以可度量的指标定义测试成功条件。明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标（如检测重负载情况下的服务器响应时间）是不够的。明确的成功条件应类似于“50个客户能够同时查看他们的账户余额，并且服务器响应时间不超过1分钟”。
        下面详细论述负载压力测试计划过程的4个步骤。
               分析应用程序
               负载测试计划的第一步是分析应用程序。应该对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。应用程序分析可以确保使用的测试环境能够在测试中精确地反映应用程序的环境和配置。
                      确定系统组件
                      绘制一份应用程序结构示意图。如果可能，从现有文档中提取一份示意图。如果要测试的应用程序是一个较大的网络系统的一部分，应该确定要测试的系统组件。确保该示意图包括了所有的系统组件，例如客户机、网络、中间件和服务器等。
                      如下图所示说明了一个由许多Web用户访问的联机银行系统。各Web用户连接到同一数据库以转移现金和支票余额。客户使用不同的浏览器，通过Web方式连接到数据库服务器。
                      
                      联机银行系统应用布署
                      描述系统配置
                      增加更多详细信息以完善示意图。描述各系统组件的配置。应当掌握以下信息：
                      . 连接到系统的用户数；
                      . 应用程序客户端计算机的配置情况（硬件、内存、操作系统、软件、开发工具等）；
                      . 使用的数据库和Web服务器的类型（硬件、数据库类型、操作系统、文件服务器等）；
                      . 服务器与应用程序客户端之间的通信方式；
                      . 前端客户端与后端服务器之间的中间件配置和应用程序服务器；
                      . 可能影响响应时间的其他网络组件（调制解调器等）；
                      . 通信设备的吞吐量以及每个设备可以处理的并发用户数。
                      例如，在如上图所示的示意图中，多个应用程序客户端在访问系统。客户端的配置如下表所示。
                      
                      客户端配置内容
                      分析使用模型
                      定义系统的典型使用方式，并确定需要重点测试的功能。考虑哪些用户使用系统、每种类型用户的数量，以及每个用户的典型任务。此外，还应考虑任何可能影响系统响应时间的后台负载。
                      例如，假设每天上午有200名员工登录记账系统，并且该办公室网络有固定的后台负载：50名用户执行各种字处理和打印任务。可以创建一个200个虚拟用户登录访问记账数据库的方案，并检测服务器的响应时间。要了解后台负载对响应时间的影响，可以在运行方案的网络中再模拟员工执行字处理和打印活动的负载。
                      任务分布
                      除定义常规用户任务外，还应该查看这些任务的分布情况。例如，假设银行用户使用一个中央数据库为跨越多个州和时区的客户提供服务。250个应用程序客户端分布在两个不同的时区，全都连接到同一个Web服务器中。其中150个在芝加哥，另外100个在底特律。每个客户端从上午9点开始工作，但由于处于不同的时区，因此在任何特定时间内都不会有超过150个的用户同时登录。可以分析任务分布，以确定数据库活动峰值期的发生时间，以及负载峰值期间的典型活动。
               定义测试目标
               开始测试之前，应精确地定义想要实现的目标。
                      以可度量的指标制定目标
                      确定了负载测试的一般性目标后，应该以可度量指标制定更具针对性的目标。为了提供评估基准，应精确地确定、区分可接受和不可接受测试结果的标准。
                      例如：
                      . 一般性目标产品评估：选择Web服务器的硬件。
                      . 明确目标产品评估：在一台HP服务器和一台NEC服务器上运行同一个包含300个虚拟用户的组。当300个用户同时浏览Web应用程序页面时，确定哪一种硬件提供更短的响应时间。
                      . 测试目标
                      ①度量最终用户的响应时间，完成一个业务流程需要多长时间；
                      ②定义最优的硬件配置，哪一种硬件配置可以提供最佳性能；
                      ③检查可靠性，系统无错误或无故障运行的时间长度或难度；
                      ④查看硬件或软件升级对性能或可靠性有何影响；
                      ⑤评估新产品，应选择哪些服务器硬件或软件；
                      ⑥度量系统容量，在没有显著性能下降的前提下，系统能够处理多大的负载；
                      ⑦确定瓶颈，哪些因素会延长响应时间。
                      确定测试的时间
                      负载测试应贯穿于产品的整个生命周期。如下表说明了在产品生命周期的各个阶段有哪些类型的测试与之相关。
                      
                      产品生命周期与测试类型
               计划方案实施
               下一步是确定如何实现测试目标。
                      定义性能度量的范围
                      可以度量应用程序中不同点的响应时间。根据测试目标确定在哪里运行Vuser（虚拟用户）以及运行哪些Vuser。
                      . 度量端到端的响应时间。
                      可以在前端运行GUI Vuser（图形用户界面用户）或RTE Vuser（终端用户）来度量典型用户的响应时间。GUI Vuser可以将输入提交给客户端应用程序并从该应用程序接收输出，以模拟实际用户；RTE Vuser则向基于字符的应用程序提交输入，并从该应用程序接收输出，以模拟实际用户。
                      可以在前端运行GUI或RTE Vuser来度量跨越整个网络（包括终端仿真器或GUI前端、网络和服务器）的响应时间。如下图所示为端到端的响应时间。
                      
                      端到端的响应时间
                      . 度量网络和服务器响应时间。
                      可以通过在客户机运行Vuser（非GUI或RTE Vuser）来度量网络和服务器的响应时间（不包括GUI前端的响应时间）。Vuser模拟客户端对服务器的进程调用，但不包括用户界面部分。在客户机运行大量Vuser时，可以度量负载对网络和服务器响应时间的影响。如下图所示为网络和服务器的响应时间。
                      
                      网络和服务器的响应时间
                      . 度量GUI响应时间。
                      可以通过减去前两个度量值，来确定客户端应用程序界面对响应时间的影响。GUI响应时间=端到端响应时间-网络和服务器响应时间。如下图所示为GUI响应时间。
                      
                      GUI响应时间
                      . 度量服务器响应时间。
                      可以度量服务器响应请求（不跨越整个网络）所花费的时间。通过在与服务器直接相连的计算机上运行Vuser，可以度量服务器性能。如下图所示为服务器响应时间。
                      
                      服务器响应时间
                      . 度量中间件到服务器的响应时间。
                      如果可以访问中间件及其API，便可以度量服务器到中间件的响应时间。可以使用中间件API创建Vuser，来度量中间件到服务器的性能。如下图所示为中间件到服务器响应时间。
                      定义Vuser活动
                      根据对Vuser类型的分析以及它们的典型任务和测试目标来创建Vuser脚本。由于Vuser模拟典型最终用户的操作，因此Vuser脚本应包括典型的最终用户任务。例如，要模拟联机银行客户端，应该创建一个执行典型银行任务的Vuser脚本。需要浏览经常访问的页面，以转移现金或支票余额。
                      
                      中间件到服务器响应时间
                      根据测试目标确定要衡量的任务，并定义这些任务的事务。这些事务度量服务器响应Vuser提交的任务所花费的时间（端到端时间）。例如，要查看提供账户余额查询的银行Web服务器的响应时间，则应在Vuser脚本中为该任务定义一个事务。
                      此外，可以通过在脚本中使用集合点来模拟峰值期活动。集合点指示多个Vuser在同一时刻执行任务。例如，可以定义一个集合点，以模拟70个用户同时更新账户信息的情况。
                      选择Vuser
                      确定用于测试的硬件配置之前，应该先确定需要的Vuser的数量和类型。要确定运行多少个Vuser和哪些类型的Vuser，请综合考虑测试目标来查看典型的使用模型。以下是一些一般性规则：
                      . 使用一个或几个GUI用户来模拟每一种类型的典型用户连接；
                      . 使用RTE Vuser来模拟终端用户；
                      . 运行多个非GUI或非RTE Vuser来生成每个用户类型的其余负载。
                      例如，假设有五种类型的用户，每种用户执行一个不同的业务流程，如下表所示。
                      
                      Vuser的数量和类型
                      选择测试硬件和软件
                      硬件和软件应该具有强大的性能和足够快的运行速度，以模拟所需数量的虚拟用户。
                      在确定计算机的数量和正确的配置时，请考虑以下事项。
                      . 建议在一台单独的计算机上运行测试工具主控台。
                      . 在一台Windows计算机只能运行一个GUI Vuser；而在一台UNIX计算机上则可以运行几个GUI Vuser。
                      . GUI Vuser测试计算机的配置应该尽量与实际用户的计算机配置相同。
                      关于每个测试组件的硬件要求，请参考下表一和下表二。要获得最佳性能，应满足表中所列要求。
                      
                      测试机硬件与软件要求（Windows配置要求）
                      注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。
                      有关最新的安装要求，请访问
                      http://www.mercuryinteractive.com/products/loadrunner/technical/
                      
                      测试机硬件与软件要求（UNIX配置要求）
                      注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。
               检查测试目标
               测试计划应该基于明确定义的测试目标。下面概述了常规的测试目标。
               ①度量最终用户响应时间。
               ②定义最优的硬件配置。
               ③检查可靠性。
               ④查看硬件或软件升级。
               ⑤评估新产品。
               ⑥确定瓶颈。
               ⑦度量系统容量。
                      度量最终用户响应时间
                      查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。如下图显示了一个银行应用程序的负载和响应时间度量之间的关系。
                      
                      负载和响应时间度量关系
                      定义最优的硬件配置
                      检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。
                      例如，可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异。
                      . 配置1：200MHz、64MB RAM。
                      . 配置2：200MHz、128MB RAM。
                      . 配置3：266MHz、128MB RAM。
                      检查可靠性
                      确定系统在连续的高工作负载下的稳定性级别。可以创建系统负载：强制系统在短时间内处理大量任务，来模拟系统在数周或数月的时间内通常会遇到的活动类型。
                      查看硬件或软件升级
                      执行回归测试，以便对新旧版本的硬件或软件进行比较。可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。应用程序回归测试需要查看新版本的效率和可靠性是否与旧版本相同。
                      评估新产品
                      可以运行测试，以评估单个产品和子系统在产品生命周期中的计划阶段和设计阶段的表现。例如，可以根据评估测试来选择服务器的硬件或数据库套件。
                      确定瓶颈
                      可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。使用负载压力测试工具，以及网络和计算机监视工具以生成负载，并度量系统中不同点的性能。如下图所示为系统不同点的性能。
                      
                      系统不同点的性能
                      度量系统容量
                      度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量，可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定了当前容量后，便可以确定是否需要增加资源以支持额外的用户。如下图所示为响应时间与负载关系。
                      
                      响应时间与负载关系
 
       测试阶段
        . 可靠性测试（含于集成测试、系统测试）；
        . 排错；
        . 可靠性建模；
        . 可靠性评价；
        . 调整可靠性活动计划；
        . 收集可靠性数据；
        . 明确后续阶段的可靠性活动的详细计划；
        . 编制可靠性文档。
 
       功能需求
        功能需求即网络在用户单位业务中应该提供的功能，可以通过了解用户单位所从事的行业、该单位在行业内的地位以及和其他单位的关系等来确定其功能需求。另外，还可以通过了解项目背景来明确用户单位建网的目的，从而有助于描述详细的功能需求。
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。
        ：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。
        最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。
 
       软件需求
        在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。
        （1）功能需求。
        （2）性能需求。
        （3）用户或人的因素。
        （4）环境需求。
        （5）界面需求。
        （6）文档需求。
        （7）数据需求。
        （8）资源使用需求。
        （9）安全保密要求。
        （10）可靠性要求。
        （11）软件成本消耗与开发进度需求。
        （12）其他非功能性要求。
               需求分析的任务
               需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
               （1）确定软件系统的综合要求，包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
               （2）分析软件系统的数据要求，包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
               （3）导出系统的逻辑模型，在结构化方法中可用数据流图来描述；在面向对象分析方法中可以用类模型来描述。
               （4）修正项目开发计划。
               （5）如有必要，可开发一个原型系统以验证用户的需求。
               软件需求的分类
               下面介绍软件需求的分类。
               （1）功能需求。所开发的软件必须具备什么样的功能。
               （2）非功能需求。它是指产品必须具备的属性或品质，如可靠性、性能响应时间、容错性和可扩展性等。
               （3）设计约束。其也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。
               软件需求分析方法
               需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
 
       数据管理
               数据生命周期
               在数据的整个生命周期中，不同的数据需要不同水平的性能、可用性、保护、迁移、保留和处理。通常情况下，在其生命周期的初期，数据的生成和使用都需要利用高速存储，并相应地提供高水平的保护措施，以达到高可用性和提供相当等级的服务水准。随着时间的推移，数据的重要性会逐渐降低，使用频率也会随之下降。伴随着这些变化的发生，企业就可以将数据进行不同级别的存储，为其提供适当的可用性、存储空间、成本、性能和保护，并且在整个生命周期的不同阶段都能对数据保留进行管理。
               数据的安全性管理是数据生命周期中的一个比较重要的环节。在进行数据输入和存取控制的时候，企业必须首先保证输入数据的数据合法性。要保证数据的安全性，必须保证数据的保密性和完整性，主要表现在以下5个方面：
               （1）用户登录时的安全性。从用户登录网络开始，对数据的保密性和完整性的保护就应该开始了。
               （2）网络数据的保护。包括在本地网络上的数据或者穿越网络的数据。在本地网络的数据是由验证协议来保证其安全性的。
               （3）存储数据以及介质的保护。可以采用数字签名来签署软件产品（防范运行恶意的软件），或者加密文件系统。
               （4）通信的安全性。提供多种安全协议和用户模式的、内置的集成支持。
               （5）企业和Internet网的单点安全登录。
               随着时间的推移，大部分数据将不再会被用到。一般情况下，一些无用的数据将被删除以节省空间，或者将有用的数据无限期地存储，以避免数据损失。
               信息资源管理
               信息资源管理（Information Resource Management，IRM）是对整个组织信息资源开发利用的全面管理。IRM把经济管理和信息技术结合起来，使信息作为一种资源而得到优化地配置和使用。上次我们在谈企业信息化的任务时，说开发信息资源既是企业信息化的出发点，又是企业信息化的归宿；只有高档次的数据环境才能发挥信息基础设施作用、建立集成化的信息系统、落实信息资源的开发和利用。因此，从IRM的技术侧面看，数据环境建设是信息资源管理的重要工作。
               企业信息资源管理不是把资源整合起来就行了，而是需要一个有效的信息资源管理体系，其中最为关键的是从事信息资源管理的人才队伍建设；其次，是架构问题，在信息资源建设阶段，规划是以建设进程为主线的，在信息资源管理阶段，规划应是以架构为主线，主要涉及的是这个信息化运营体系的架构，这个架构要消除以往分散建设所导致的信息孤岛，实现大范围内的信息共享、交换和使用，提升系统效率，达到信息资源的最大增值；技术也是一个要素，要选择与信息资源整合和管理相适应的软件和平台；另外一个就是环境要素，主要是指标准和规范，信息资源管理最核心的基础问题就是信息资源的标准和规范。
               数据管理
               企业信息资源开发利用做得好坏的关键人物是企业领导和信息系统负责人。IRM工作层上的最重要的角色就是数据管理员（Data Administrator, DA）。数据管理员负责支持整个企业目标的信息资源的规划、控制和管理；协调数据库和其他数据结构的开发，使数据存储的冗余最小而具有最大的相容性；负责建立有效使用数据资源的标准和规程，组织所需要的培训；负责实现和维护支持这些目标的数据字典；审批所有对数据字典做的修改；负责监督数据管理部门中的所有职员的工作。数据管理员应能提出关于有效使用数据资源的整治建议，向主管部门提出不同的数据结构设计的优缺点忠告，监督其他人员进行逻辑数据结构设计和数据管理。
               数据管理员还需要有良好的人际关系：善于同中高层管理人员一起制定信息资源的短期和长期计划。在数据结构的研制、建立文档和维护过程中，能与项目领导、数据处理人员和数据库管理员协同工作。能同最终用户管理部门一起工作，为他们提供有关数据资源的信息。
               一般来说，由数据管理员对日常数据进行更新和维护。数据库为了保证存储在其中的数据的安全和一致，必须有一组软件来完成相应的管理任务，这组软件就是数据库管理系统，简称DBMS, DBMS随系统的不同而不同，但是一般来说，它应该包括数据库描述功能、数据库管理功能、数据库的查询和操纵功能、数据库维护功能等。为了提高数据库系统的开发效率，现代数据库系统除了DBMS之外，还提供了各种支持应用开发的工具。
               目前许多厂商提供了相应的DBMS，便于数据管理员对底层的数据进行维护。例如MySQL、东软的OpenBase、金仓的KingbaseES等。
               公司级的数据管理
               如何进行信息资源规划？信息资源规划主要可以概括为“建立两种模型和一套标准”。“两种模型”是指信息系统的功能模型和数据模型，“一套标准”是指信息资源管理基础标准。信息系统的功能模型和数据模型，实际上是用户需求的综合反映和规范化表达；信息资源管理基础标准是进行信息资源开发利用的最基本的标准，这些标准都要体现在数据模型之中。
               企业信息化的最终目标是实现各种不同业务信息系统间跨地域、跨行业、跨部门的信息共享和业务协同，而信息共享和业务协同则是建立在信息使用者和信息拥有者对共享数据的涵义、表示及标识有着相同的而无歧义的理解基础上。然而，由于各部门、各行业及各应用领域对于相同的数据概念有着不同的功能需求和不同的描述，从而导致了数据的不一致性。数据的不一致性主要表现为：数据名称的不一致性、数据长度的不一致性、数据表示的不一致性以及数据含义的不统一性。
               数据标准化是一种按照预定规程对共享数据实施规范化管理的过程。数据标准化的对象是数据元素和元数据。数据元素是通过定义、标识、表示以及允许值等一系列属性描述的数据单元，是数据库中表达实体及其属性的标识符。在特定的语义环境中，数据元素被认为是不可再分的最小数据单元。元数据是描述数据元素属性（即语义内容）的信息，并被存储在数据元素注册系统（又称数据字典）中。数据元素注册系统通过对规范化的数据元素及其属性（即元数据）的管理，可以有效实现用户跨系统和跨环境的数据共享。数据标准化主要包括业务建模阶段、数据规范化阶段、文档规范化阶段等三个阶段。
               数据标准化是建立在对现实业务过程全面分析和了解的基础上的，并以业务模型为基础的。业务建模阶段是业务领域专家和业务建模专家按照《业务流程设计指南》，利用业务建模技术对现实业务需求、业务流程及业务信息进行抽象分析的过程，从而形成覆盖整个业务过程的业务模型。该阶段着重对现实业务流程的分析和研究，尤其需要业务领域专家的直接参与和指导。业务模型是某个业务过程的图形表示或一个设计图。
               数据规范化阶段是数据标准化的关键和核心，该阶段是针对数据元素进行提取、规范化及管理的过程。数据元素的提取离不开对业务建模阶段成果的分析，通过研究业务模型能够获得业务的各个参与方、确定业务的实施细则、明确数据元素对应的信息实体。该阶段是业务领域专家和数据规范化专家按照《数据元素设计与管理规范》利用数据元素注册系统（或数据字典）对业务模型内的各种业务信息实体进行抽象、规范化和管理的过程，从而形成一套完整的标准数据元素目录。在实现数据元素标准化的同时，还应关注数据元素取值的规范化，以此实现信息表示和信息处理的标准化。
               文档规范化阶段是数据规范化成果的实际应用的关键，是实现离散数据有效合成的重要途径。标准数据元素是构造完整信息的基本单元，各类电子文档则是传递各类业务信息的有效载体，并是将分离的标准数据元素信息进行有效合成的手段。该阶段是业务领域专家和电子文档设计专家按照《电子文档设计指南》对各类电子文档格式进行规范化设计和管理的过程，并形成了一批电子文档格式规范。
               综上所述，数据标准化所涉及的三个主要阶段缺一不可、彼此密不可分。业务建模是数据标准化的基础和前提；数据规范化及其管理是数据标准化的核心和重点；文档规范化是数据标准化成果的有效应用的关键。
               此外，数据标准化也可以采用数据字典、数据指南或信息系统字典等加以统一。数据字典实际上也是以数据表和视图为主要存在形式的，它是关于数据的数据表和视图。管理员可以通过数据字典获得全面的数据库信息。
               数据库审计支持
               数据安全是大型数据库应用系统中必须仔细考虑的一个重要问题，也是数据库管理人员和系统管理人员日常工作中最为重要的一部分。有效的数据库审计是数据库安全的基本要求。企业应针对自己的应用和数据库活动定义审计策略。智能审计的实现对安全管理的意义重大，不仅能节省时间，而且能减少执行所涉及的范围和对象。通过智能限制日志大小，还能突出更加关键的安全事件。
               信息系统审计员可以从数据库系统本身、主体和客体三个方面来进行审计，审计对数据库对象的访问以及与安全相关的事件。数据库审计员可以分析审计信息、跟踪审计事件、追查责任以及使用审计服务器记录审计跟踪，并且可以根据审计信息，对审计结果进行统计、跟踪和分析，进行审计跟踪、入侵检测等。
               目前许多数据库供应商都提供了支持数据库审计的功能，例如东软公司的OpenBASE Secure就提供了十分完善的审计功能。
 
       数据库
        数据库（DataBase，DB）是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。
        系统使用的所有数据存储在一个或几个数据库中。
 
       数据库设计
        数据库的设计质量对整个系统的功能和效率有很大的影响。数据库设计的核心问题是：从系统的观点出发，根据系统分析和系统设计的要求，结合选用的数据库管理系统，建立一个数据模式。设计的基本要求是：
        .符合用户需求，能正确反映用户的工作环境
        .设计与所选用的DBMS所支持的数据模式相匹配
        .数据组织合理，易操作、易维护、易理解
               数据库设计步骤
               数据库的设计过程可以分为4个阶段，即用户需求分析、概念结构设计、逻辑结构设计和物理结构设计。下图反映和分析了这一设计过程，其中：
               
               数据库设计步骤
               .用户需求分析是对现实世界的调查和分析
               .概念结构设计是从现实世界向信息世界的转换。根据用户需求来进行数据库建模，也称为概念模型，常用实体关系模型表示。
               .逻辑结构设计是从信息世界向数据世界的转化。将概念模型转化为某种数据库管理系统所支持的数据模型。
               .物理结构设计是为数据模型选择合适的存储结构和存储方法。
               用户需求分析
               用户需求分析需要结合具体的业务需求分析，确定信息系统的各类使用者以及管理员对数据及其处理、数据安全性和完整性的要求。主要设计如下三方面：
               （1）系统应用环境分析。
               系统应用环境及系统所服务和运行的特殊组织环境。不同业务单位有不同的组织结构和业务工作流程。环境的特殊性将决定数据库的整体设计思路和风格。
               （2）用户数据需求及加工分析。
               用户需求及加工分析指用户希望从数据库中获得那些信息以及对信息的处理要求。由此决定数据库中应该存储哪些信息以及对数据需要进行哪些加工处理，包括在处理过程中特定的查询要求、响应时间要求，以及数据安全性、保密性、完整性和一致性等方面的要求，应在此基础上编制数据字典。
               （3）系统约束条件分析。
               系统约束条件分析及分析现有系统的规模、结构、资源和地理分布，明确现有系统存在的种种限制或约束，从而使系统设计不至于脱离实际条件，确保系统设计顺利实施。
               数据库概念结构设计
               概念结构设计是指由现实世界的各种客观事物及其联系转化为信息世界中的信息模型的过程，即为数据库的概念结构设计。E-R模型即实体-联系模型是描述数据库概念结构的有力工具。下面结合实例说明E-R模型的构建。
               在一个政府部门中存在着多个不同科室，每一个由若干名科员构成，每个科室都有一名主管上级领导，科室公务员负责为前来机关办事的群众提供相关的服务。现分别画出各个科室的E-R模型图，再画出整个机关的E-R模型。
               一个科室结构应包括：
               （1）实体，即上级领导、科室、科员、群众。
               （2）实体联系，主管领导与科室之间是一对多的关系，科室与科员之间的联系也是一对多的关系，科员与群众之间是多对多的关系。
               （3）各个实体所具有的属性。
               .主管上级领导，属性可以有编号、姓名、性别、年龄、职务、任职时间、参加工作时间、入党时间、学历
               .科室的属性可以包括科室号
               .科员的属性包括编号、姓名、性别、年龄、职称、参加工作时间、入党时间、学历
               .群众属性包括服务日期、服务事宜、处理结果
               .服务，包括服务日期、服务事宜、处理结果
               通过以上分析，可以得到如下的E-R模型，如下图所示（部分属性）。
               
               科室E-R模式图
               数据库逻辑结构设计
               逻辑结构设计的任务是要将概念结构设计阶段完成的概念模型转换成能被选定的数据库管理系统支持的数据模型。现行的数据库管理系统一般支持网状、层次和关系三种数据模型中的一种，其中关系型的数据模型在DBMS中的应用和支持较为广泛，已成为主流。
               下面简单介绍一下由E-R模型转换为关系数据模型的转化规则。在关系数据模型下，数据的逻辑结构是一张二维表，每个关系为一张二维表格。E-R模型转换为关系数据模型的转化规则如下。
               .每一实体及其属性对应于一个关系模式。实体名作为关系名，实体的属性作为对应关系的属性。所谓关系模式，就是对关系的描述，用关系名（属性1、属性2、属性3，……属性n）来表示。
               .两两实体之间的联系及其属性一般对应一个关系模式，联系名作为对应的关系名，联系的属性作为对应关系的属性；不带属性的联系可以去掉。
               .实体和联系中关键字属性在关系模式中仍作为关键字。
               上图中所示的实体关系图可以按照这些转换规则进行转化得到如下对应的关系模型。
               .主管上级领导，编号、姓名、性别、年龄、职务、任职时间、参加工作时间、入党时间、学历
               .科室，包括主管上级领导编号、科室号
               .科员，包括科室号、编号、姓名、性别、年龄、职称、参加工作时间、入党时间、学历
               .群众，包括来访者编号、姓名、性别、年龄、来访日期、服务事宜
               .服务，包括受理公务员编号、来访者编号、服务日期、服务事宜、处理结果
               不同的系统配备的数据库管理系统性能不同，因而必须结合具体DBMS的性能和要求将一般数据模型转换成所选用的数据管理系统支持的数据模型，若选用的DBMS支持层次、网络模型，则还要完成从关系模型向层次或网络模型的转换。
               数据库物理结构设计
               数据库的物理设计以逻辑结构设计的结果为输入，结合关系数据库系统的功能和应用环境、存储设备等具体条件为数据模型选择合适的存储结构和存储方法。从而提高数据库的效率。物理结构设计的主要任务如下。
               （1）确定存储结构。
               根据用户对数据结构和处理的要求，权衡数据存取时间、空间利用率和维护代价等三方面的利弊，综合考虑存储效率、维护成本等相关因素，从数据库管理系统提供的各种存储结构（例如顺序存储结构、索引存储结构，等等）中，选取合适的结构并加以实现。
               （2）选择和调整存储路径。
               数据库必须支持多个用户的多种应用，因此必须提供多个存取入口、多条存取路径，建立多个辅助索引。此过程中需要考虑一些问题，例如如何选取合适的数据项建立索引，如何建立辅助索引从而达到检索效率和存储空间的统一等。
               （3）确定数据存储位置。
               按照不同的应用可将数据分为若干个组。根据各组数据利用频率和存储要求的不同，各类数据的存放位置、存储设备以及区域划分都应有所不同。应该把存取频率和存取速度要求较高的数据存储在高速存储器上，把存取频率和存取速度要求较低的数据存储在低速存储器上。
               （4）确定存储分配。
               大多数据库管理系统会提供一些存储分配参数，例如溢出区大小、块大小、缓冲区大小和个数等，设计人员应全面考虑这些参数，以进行物理优化。
               （5）确定数据的完整性与安全性约束。
               进行物理设计时不仅要考虑所选用数据库管理系统提供的安全机制和完整性约束，还要考虑用户使用制度、应用程序、计算机系统等各个涉及具体应用的方面。
               （6）考虑数据恢复方案。
               数据库的物理设计阶段也要考虑数据库的恢复问题，采取必要的物理措施和手段，为突发事件和故障后的恢复做好准备，提供必要的物理工具。
 
       数据库设计说明
        数据库设计是指数据库应用系统的设计。编制数据库设计说明书的目的是对设计中的数据结构的所有标识、逻辑结构和物理结构做出具体的设计规定。编写提纲和内容要求如下。
        （1）概述。
        .目标，说明开发的意图、应用目标、作用范围以及有关数据库开发的背景材料
        .主要功能，简要说明数据库系统的主要功能。
        .用户的安排，指最终用户。说明操作人员、数据管理人员和维护人员的水平。
        （2）需求规定。
        .性能规定
        .精度，简述对数据精度的要求。
        .有效性，说明对数据库存取数据的有效性的要求。
        .时间要求，如响应时间、数据的转换和传送时间等。
        .其他专门要求。
        （3）运行环境要求。
        .设备，简述运行数据库系统的硬设备及其专门功能。
        .支撑软件，列出支撑软件并说明测试前的软件。
        .安全保密，说明在安全保密方面的全部要求。
        .其他要求。
        （4）设计考虑。
        .逻辑结构设计，简要说明本系统（或子系统）内所使用的数据结构中，有关数据项、记录、文件的标识定义、长度及它们之间的相互关系。
        .物理结构设计，简要说明本系统内所使用的数据结构中有关数据库的存储要求、访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密处理。
        （5）评价。
        简要说明对时间、空间效率、维护代价和各种用户要求进行权衡所产生的方案性能情况。
        （6）验收。
 
       维护
        维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。
 
       信息管理
        管理信息系统是由人、计算机和管理规则等组成，以采集、加工、维护和使用信息为主要功能的人－机系统。例如金融、财会、经营、管理、教育、科研、医疗、人事、档案、物资等各方面都有大量的信息需要及时分析和处理，以便为决策提供依据。虽然在这方面应用中计算公式并不复杂，但数据量极大，在当今信息爆炸的时代，人工已难以胜任这一重任，计算机则成为信息管理的重要工具。该系统一般以数据库管理系统为核心，以其他软件和网络系统为支撑环境，而用户则通过专门的人机交互界面，进行数据的查询、修改等操作，并实现统计分析、规划、决策等功能。在信息管理方面，我们正经历着从单项事务的电子数据处理，向以数据库为基础的管理信息系统，及以数据库、模型库和方法库为基础的决策支持系统发展的过程，并且呈现出系统集成化、结构分布化、信息多元化、功能智能化等趋势。
 
       信息管理系统
        用来管理和分发项目信息的工具有很多，包括：
        .纸质文件管理，如信件、备忘录、报告和新闻稿。
        .电子通信管理，如电子邮件、传真、语音信箱、电话、视频和网络会议、网站。
        .项目管理电子工具，如基于网页界面的进度管理工具和项目管理软件，会议和虚拟办公支持软件，门户网站和协同工作管理工具。
 
       需求分析阶段
        . 确定软件的可靠性目标；
        . 分析可能影响可靠性的因素；
        . 确定可靠性的验收标准；
        . 制定可靠性管理框架；
        . 制定可靠性文档编写规范；
        . 制定可靠性活动初步计划；
        . 确定可靠性数据收集规范。
   题号导航      2018年上半年 信息系统监理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
 
第1题    在手机中做本题