【说明】<br />针对省级电子政务信息系统建设项目，信息化主管部门启动了业务系统综合..

免费智能真题库 > 历年试卷 > 信息系统监理师 > 2015年下半年信息系统监理师下午试卷案例

第5题

知识点：承建单位第三方测试电子政务概要设计监理单位建设单位软件测试详细设计信息系统建设招标测试计划监控平台建设评审系统概要设计信息化业务系统质量控制综合管理

【说明】
针对省级电子政务信息系统建设项目，信息化主管部门启动了业务系统综合管理平台建设工作。建设任务涉及到应用系统开发和系统集成工作，平台主要是对现有核心业务系统实施监控、审计、分析、决策、财务管控和信息化管控等。建设单位通过公开招标引入了承建单位，并且引入监理单位负责做好全过程的监理工作。在建设过程中，发生如下事件：
[事件1] 在监理单位全程跟踪下，承建单位完成了系统概要设计和详细设计。建设单位要求监理单位组织专家进行评审，并指出，监理单位作为项目参建单位，应组织得力人员，认真评审，提出合理化建议，如后续仍存在设计缺陷，监理单位也要承担相应责任。
[事件2] 软件测试是监理单位进行质量控制的重要手段。本项目监理团队严格审查了软件测试计划、测试说明，并监督承建单位配合第三方测试单位执行了软件测试。

问题：5.1 在（1）～（5）中填写恰当内容（从候选答案中选择一个正确选项，将该选项编号填入答题纸对应栏内）
针对事件1的描述，监理单位（1）。
（1）供选择的答案：
A．应该组织专家评审，但不应该对设计缺陷负责
B．应该组织专家评审，也应该对设计缺陷承担相应责任
C．不应该组织专家评审，但应该对设计缺陷承担相应责任
D．不应该组织专家评审，也不应该对设计缺陷负责
针对事件1，为保证系统设计质量，监理单位可建议建设单位邀请外部专家组进行评审，评审专家组的人员组成包括（2）、（3）、（4）、（5）。
（2）～（5）供选择的答案：
A．建设单位代表 B．承建单位代表 C．监理单位代表 D．行业专家
E．第三方测试机构代表 F．信息化领域专家 G．用户单位代表

问题：5.2 在（1）～（5）中填写恰当内容（从候选答案中选择一个正确选项，将该选项编号填入答题纸对应栏内）。
针对事件2，第三方测试单位首先执行了黑盒测试。黑盒测试是根据（1）设计测试用例，较少关心程序内部实现过程，侧重于（2）。
（1）～（2）供选择的答案：
A．系统设计文件 B．需求规格说明 C．程序执行结果 D．程序执行效率
在事件2中，第三方测试单位完成测试后，监理单位应要求其提交测试报告和（3）。
（3）供选择的答案：
A．测试计划 B．测试方案 C．测试问题单 D．测试用例
在事件2中，监理单位的监理内容包括审查测试方案、测试工具、测试环境、（4）、测试问题报告、（5）、和测试报告。
（4）～（5）供选择的答案：
A．测试计划 B．测试用例 C．测试过程 D．回归测试 E．测试方法


知识点讲解
· 承建单位 · 第三方测试 · 电子政务 · 概要设计 · 监理单位 · 建设单位 · 软件测试 · 详细设计 · 信息系统建设 · 招标 · 测试计划 · 监控 · 平台建设 · 评审 · 系统概要设计 · 信息化 · 业务系统 · 质量控制 · 综合管理

承建单位

负责具体实施的承建方应该有自己的项目管理，监理方代表项目建设方对承建方提出的工程计划进行监督和协调，对一些关键点进行控制。这些关键点主要属于进度、资金及质量的范畴，但不能涉及管理细节。工程项目管理主要以承建方为主，并强调在项目中组织并制定相关计划。

在一个大型信息系统工程项目的建设中，承建方可能有多个，比如硬件提供商、软件开发商和系统集成商等。而在市场竞争日益激烈的今天，专业化能促进生产效率和提高生产质量，故而承建方常常分解成一定的层次结构，如总承包商和分包商等，从而使一部分人或企业专注于项目管理的科学化。

从市场的角度看，总承包商既是买方又是卖方；从工程合同的角度来讲，他既要对建设方负全部法律责任，又要根据分包合同对分包商进行管理并履行义务，所有的主合同都会限定总承包商可以分包的最大范围。总承包商只能将某些具体的工程施工分包给分包商，但不能分包合同的责任和义务。总承包商不能期望通过分包逃避自己在合同中的法律和经济责任。

作为分包商，一般情况下不与建设方直接发生合同关系。分包商只接受总承包商的统筹安排和调度，它只对总承包商承担分包合同内规定的责任并履行规定的义务。

如果总承包商违反分包合同，则应该赔偿分包商的经济损失；分包商违反分包合同并造成建设方对总承包商的罚款或制裁，则分包商应该赔偿总承包商的损失。分包商是从总承包商处按分包合同索回其应得部分的，如果总承包商无力偿还债务，则分包商也同样蒙受损失，因此分包商的利益通常与总承包商的利益密切相关。

第三方测试

第三方测试指独立于软件开发方和用户方的测试，也称为“独立测试”。软件质量工程强调开展独立验证和确认（IV&V）活动，是指由在技术、管理和财务上与开发组织具有规定程序独立的组织执行验证和确认过程。软件第三方测试是由相对独立的组织进行的软件测试，一般是在模拟用户真实应用环境下进行软件确认测试。

第三方测试机构是一个中介的服务机构，它通过自己专业化的测试手段为客户提供有价值的服务。但是这些服务不同于公司内部的测试，因为第三方测试机构的测试除了发现软件问题之外，还要科学公正地评价软件的职能，这就要求该机构要保持公正、廉洁、客观、科学且独立的态度。

第三方测试机构存在的价值主要是由软件公司、软件用户，以及国家的公正诉求所决定的。对于软件开发商来说，经过第三方测试机构的测试，不仅可以通过专业化的测试手段发现软件错误，帮助开发商提升软件的品质，而且可以对软件有一个客观且科学的评价，有助于开发商认清自己产品的定位。对于行业主管部门及软件使用者来说，第三方测试机构可帮助选择合适且优秀的软件产品。而对于一些信息工程项目来说，在验收之前，经过第三方机构的严格测试，可以最大程度地避免信息行业的“豆腐渣”工程。此外，经过国家认可的第三方测试机构，还为国家软件产品的质量监督抽查提供独立公正的测试支持。

在选择第三方测试机构时，主要查看其资质、信息系统工程测评经验、测试环境、测试工具及测试工程师队伍的素质等。

电子政务

所谓电子政务，就是政府机构应用现代信息和通信技术，将管理和服务通过网络技术进行集成，在因特网上实现政府组织结构和工作流程的优化重组，超越时间和空间及部门之间的分隔限制，向社会提供优质和全方位的、规范而透明的、符合国际水准的管理与服务。电子政务的主要模式有4种，分别为G2G、G2E、G2B和G2C。

（1）政府对政府（Government To Government，G2G）：政府内部、政府上下级之间、不同地区和不同职能部门之间实现的电子政务活动。G2G模式是电子政务的基本模式，包括电子法规政策系统、电子公文系统、电子司法档案系统、电子财政管理系统、电子办公系统、电子培训系统和业绩评价系统等。

（2）政府对公务员（Government To Employee，G2E）：政府与公务员（即政府雇员）之间的电子政务，主要是利用Intranet建立起有效的行政办公和员工管理体系，为提高政府工作效率和公务员管理水平服务。G2E是政府机构通过网络技术实现内部电子化管理的重要形式，也是G2G、G2B和G2C电子政务模式的基础。

（3）政府对企业（Government To Business，G2B）：政府与企业之间的电子政务，包括电子采购与招标、电子税务、电子证照办理、信息咨询服务和中小企业电子服务等。

（4）政府对公民（Government To Citizen，G2C）：政府与公民之间的电子政务，是指政府通过电子网络系统为公民提供各种服务。包括教育培训服务、就业服务、电子医疗服务、社会保险网络服务、公民信息服务、交通管理服务、公民电子税务和电子证件服务等。

概要设计

概要设计也称为高层设计，即将软件需求转化为数据结构和软件的系统结构。例如，如果采用结构化设计，则从宏观的角度将软件划分成各个组成模块，并确定模块的功能及模块之间的调用关系。

概要设计主要包括设计软件的结构、确定系统由哪些模块组成，以及每个模块之间的关系。它采用的是结构图（包括模块、调用和数据）来描述程序的结构，还可以使用层次图和HIPO（层次图加输入／处理／输出图）。整个过程主要包括复查基本系统模型、复查并精化数据流图、确定数据流图的信息流类型（包括交换流和事务流）、根据流类型分别实施变换分析或事务分析，以及根据软件设计原则对得到的软件结构图进一步进行优化。

监理单位

项目监理方服务于信息系统建设合同的建设方与承建方。接受建设方委托后，监理方作为工程承包合同的监督者，所执行的原则是使工程承包合同成为“平等条约”；作为工程承包合同管理和工程款支付的签认者，所执行的原则是等价交换。因此监理方是为双方的利益服务的，而不仅仅为委托方服务。

根据工程监理的深入程度不同，信息系统工程监理可分为如下三种。

（1）咨询式监理。只解答用户方就企业信息化过程中提出的问题，其性质类似于业务咨询或方案咨询。这种方式费用最少，监理方的责任最轻，适合于对信息化有较好把握，并且技术力量较强的用户方采用。

（2）里程碑式监理。将信息系统的建设划分为若干个阶段，在每一个阶段结束都设置一个里程碑，在里程碑到来时通知监理方进行审查或测试。一般来讲，这种方式比咨询式监理的费用要多，监理方也要承担一定的责任。不过，里程碑的确定需要承建方的参与，或者说监理合同的确立需要开发方的参与，否则就会因对里程碑的界定不同而引起纠纷。

（3）全程式监理。一种复杂的监理方式，不但要求对系统建设过程中的里程碑进行审查，还应该派相应人员全程跟踪并收集系统开发过程中的信息，不断评估承建方的开发质量和效果。这种方式费用最高，监理方的责任也最大，适合于那些对信息系统的开发不太了解且技术力量偏弱的用户采用。

监理单位的主要作用如下。

（1）信息系统工程监理可以帮助建设单位更合理地保证工程的质量、进度和投资，并合理且客观地处理好它们之间的关系。监理由独立的第三方依据相关技术标准来对工程建设进行监督，这样对信息系统工程的建设质量更能起到保驾护航的作用。在项目建设全过程中，监理单位要依据国家有关法律和相关技术标准，遵循守法、公平、公正、独立的原则，对信息系统建设的过程进行监督和控制。即在确保质量、安全和有效性的前提下，合理安排进度和投资。监理单位要帮助建设单位对工程有关方面控制进行再控制，对承建单位项目控制过程进行监督管理。

（2）在信息系统工程建设中，建设单位和承建单位有许多问题存在争议，双方都希望由第三方在工程的立项、设计、实施、验收及维护等各个阶段的效果都给予公正、恰当且权威的评价，这就需要监理单位来协调和保障这些工作的顺利进行。

（3）由于建设单位在信息技术等相关领域普遍存在缺乏人才和经验不足的问题，实践证明建设单位自行管理对于提高项目投资的效益和建设水平是无益的。通过第三方的专业服务，帮助建设单位对项目实施控制，并对建设单位和承建单位都做出约束，是监理作用一个重要体现。

建设单位

建设方是建设项目的主要投资者，有时也是项目的最终使用者，是在工程建设阶段的全权代表，建设项目的经济效益，如投资额度、工程质量、投入使用时间和使用寿命直接关系着建设方的切身利益。虽然承建方、监理方与建设方是平等的市场主体，但由于建设方是投资方，掌握着项目的最终资源——决定了其他方为从属地位，所以说建设方对工程项目管理起着主导性作用。建设方加强和改善对项目的管理是从根本上实现项目按质如期完成的最有效的途径之一。

作为项目管理集体中的主要负责人，建设方的作用是阐明本项目的目标并确认各项工作的轻重缓急，组织协调参与各方为此目标而通力合作，在管理决策过程中做出决策。但在某些具体的项目管理事务中，建设方并不总是处于主要负责人的地位，还要作为裁判、支持者、服务员及督促员的角色。

软件测试

在软件测试阶段，监理的主要活动如下。

（1）监督承建单位将合适的软件测试工程方法和工具集成到项目定义的软件过程中。

（2）监督承建单位依据项目定义的软件过程，对软件测试进行开发、维护、建立文档和验证，以满足软件测试计划的要求。

（3）监督承建单位依据项目定义的软件过程和计划实施软件的确认测试。

（4）计划和实施软件系统测试，实施系统测试以保证软件满足软件需求。

（5）软件监理组跟踪和记录软件测试的结果。

在软件测试阶段，监理的主要方法有定期检查、必要抽查、评审。

（1）定期审查软件测试的工程活动和工作进度。

（2）根据实际需要对软件测试工程活动进行跟踪、审查和评估。

（3）对软件测试工程活动和产品进行评审和（或）审核，并报告结果。

详细设计

详细设计也称为低层设计，即对结构图进行细化，得到详细的数据结构与算法。同样，如果采用结构化设计，则详细设计的任务就是为每个模块进行设计。

详细设计确定应该如何具体地实现所要求的系统，得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。经常使用的工具包括程序流程图、盒图、PAD图（问题分析图）及PDL（伪码）。

总的来说，在整个软件设计过程中，需完成以下工作任务。

（1）制定规范，作为设计的共同标准。

（2）完成软件系统结构的总体设计，将复杂系统按功能划分为模块的层次结构，然后确定模块的功能，以及模块间的调用关系和组成关系。

（3）设计处理方式，包括算法、性能、周转时间、响应时间、吞吐量和精度等。

（4）设计数据结构。

（5）可靠性设计。

（6）编写设计文档，包括概要设计说明书、详细设计说明书、数据库设计说明书、用户手册和初步的测试计划等。

（7）设计评审，主要是对设计文档进行评审。

在设计阶段，必须根据要解决的问题做出设计的选择。例如，半结构化决策问题就适合由交互式计算机软件来解决。

信息系统建设

信息系统建设周期长、投资大、风险大，比一般技术工程有更大的难度和复杂性。这是因为技术手段复杂；内容复杂，目标多样；投资密度大，效益难以计算；环境复杂多变。

信息系统在使用过程中，随着其生存环境的变化，要不断维护、修改，当它不再适应的时候就要被淘汰，就要由新系统代替旧系统，这种周期循环称为信息系统的生命周期，如下图所示。

信息系统的生命周期

从上图可见，信息系统的生命周期可以分为系统规划、系统分析、系统设计、系统实施、系统运行和维护5个阶段。

系统规划阶段的任务是对企业的环境、目标及现行系统的状况进行初步调查，根据企业目标和发展战略确定信息系统的发展战略，对建设新系统的需求做出分析和预测，同时考虑建设新系统所受的各种约束，研究建设新系统的必要性和可能性。根据需要与可能，给出拟建系统的备选方案。对这些方案进行可行性分析，写出可行性分析报告。可行性分析报告审议通过后，将新系统建设方案及实施计划编写成系统设计任务书。

系统分析阶段的任务是根据系统设计任务书所确定的范围，对现行系统进行详细调查，描述现行系统的业务流程，指出现行系统的局限性和不足之处，确定新系统的基本目标和逻辑功能要求，即提出新系统的逻辑模型。这个阶段又称为逻辑设计阶段。这个阶段是整个系统建设的关键阶段，也是信息系统建设与一般工程项目的重要区别所在。系统分析阶段的工作成果体现在系统说明书中，这是系统建设的必备文件。它既是给用户看的，也是下一个阶段的工作依据。因此，系统说明书既要通俗，又要准确。用户通过系统说明书可以了解未来系统的功能，判断是不是所要求的系统。系统说明书一旦讨论通过，就是系统设计的依据，也是将来验收系统的依据。

简单地说，系统分析阶段的任务是回答系统“做什么”的问题，而系统设计阶段要回答的问题是“怎么做”。该阶段的任务是根据系统说明书中规定的功能要求，考虑实际条件，具体设计实现逻辑模型的技术方案，也就是设计新系统的物理模型。这个阶段又称为物理设计阶段。这个阶段又可分为总体设计和详细设计两个阶段。这个阶段的技术文档是系统设计说明书。

系统实施阶段是将设计的系统付诸实施的阶段。这一阶段的任务包括计算机等设备的购置、安装和调试、程序的编写和调试、人员培训、数据文件转换、系统调试与转换等。这个阶段的特点是几个互相联系、互相制约的任务同时展开，必须精心安排、合理组织。系统实施是按实施计划分阶段完成的，每个阶段应写出实施进展报告。系统测试之后写出系统测试分析报告。

系统投入运行后，需要经常进行维护和评价，记录系统运行的情况，根据一定的规格对系统进行必要的修改，评价系统的工作质量和经济效益。

招标

下列工程建设项目包括项目的勘察、设计、施工、监理，以及与工程建设有关的重要设备、材料等的采购，因此必须进行招标。

（1）大型基础设施、公用事业等关系社会公共利益、公众安全的项目。

（2）全部或部分使用国有资金投资或者国家融资的项目。

（3）使用国际组织或者外国政府贷款、援助资金的项目。

任何单位和个人不得将依法必须进行招标的项目化整为零或者以其他任何方式规避招标。招标投标活动应当遵循公开、公平、公正和诚实信用的原则。必须进行招标的项目，其招标投标活动不受地区或者部门的限制。任何单位和个人不得违法限制或者排斥本地区、本系统以外的法人或其他组织参加投标，不得以任何方式非法干涉招标投标活动。

招标分为公开招标和邀请招标。公开招标是指招标人以招标公告的方式邀请不特定的法人或者其他组织投标。邀请招标是指招标人以投标邀请书的方式邀请特定的法人或者其他组织投标。国务院发展计划部门确定的国家重点项目和省、自治区、直辖市人民政府确定的地方重点项目不适宜公开招标的，经国务院发展计划部门或者省、自治区、直辖市人民政府批准，可以进行邀请招标。

招标代理机构

招标人有权自行选择招标代理机构，委托其办理招标事宜。任何单位和个人不得以任何方式为招标人指定招标代理机构。招标人具有编制招标文件和组织评标能力的，可以自行办理招标事宜。任何单位和个人不得强制其委托招标代理机构办理招标事宜。依法必须进行招标的项目，招标人自行办理招标事宜的，应当向有关行政监督部门备案。

招标代理机构是依法设立、从事招标代理业务并提供相关服务的社会中介组织。招标代理机构应当具备下列条件。

（1）有从事招标代理业务的营业场所和相应资金。

（2）有能够编制招标文件和组织评标的相应专业力量。

（3）有符合规定条件，可以作为评标委员会成员人选的技术、经济等方面的专家库。

从事工程建设项目招标代理业务的招标代理机构，其资格由国务院或者省、自治区、直辖市人民政府的建设行政主管部门认定。具体办法由国务院建设行政主管部门会同国务院有关部门制定。从事其他招标代理业务的招标代理机构，其资格认定的主管部门由国务院规定。

招标代理机构与行政机关和其他国家机关不得存在隶属关系或者其他利益关系。招标代理机构应当在招标人委托的范围内办理招标事宜。

招标公告

招标人采用公开招标方式的，应当发布招标公告。依法必须进行招标的项目的招标公告，应当通过国家指定的报刊、信息网络或者其他媒介发布。招标公告应当载明招标人的名称和地址、招标项目的性质、数量、实施地点和时间，以及获取招标文件的办法等事项。

招标人采用邀请招标方式的，应当向3个以上具备承担招标项目的能力、资信良好的特定法人或者其他组织发出投标邀请书。投标邀请书应当载明的事项与招标公告相同。

招标人可以根据招标项目本身的要求，在招标公告或者投标邀请书中要求潜在投标人提供有关资质证明文件和业绩情况，并对潜在投标人进行资格审查。国家对投标人的资格条件有规定的，依照其规定。招标人不得以不合理的条件限制或者排斥潜在投标人，不得对潜在投标人给予歧视待遇。

招标文件

招标人应当根据招标项目的特点和需要编制招标文件。招标文件应当包括招标项目的技术要求、对投标人资格审查的标准、投标报价要求和评标标准等所有实质性要求和条件，以及拟签订合同的主要条款。

国家对招标项目的技术、标准有规定的，招标人应当按照其规定在招标文件中提出相应要求。招标项目需要划分标段、确定工期的，招标人应当合理划分标段、确定工期，并在招标文件中载明。招标文件不得要求或者标明特定的生产供应以及含有倾向或者排斥潜在投标人的其他内容。

招标人根据招标项目的具体情况，可以组织潜在投标人踏勘项目现场。招标人不得向他人透露已获取招标文件的潜在投标人的名称、数量，以及可能影响公平竞争的有关招标投标的其他情况。招标人设有标底的，标底必须保密。

招标人对已发出的招标文件进行必要的澄清或者修改的，应当在招标文件要求提交投标文件截止时间至少15日前，以书面形式通知所有招标文件收受人。该澄清或者修改的内容为招标文件的组成部分。

招标人应当确定投标人编制投标文件所需要的合理时间。但是，依法必须进行招标的项目，自招标文件开始发出之日起至投标人提交投标文件截止之日止，最短不得少于20日。

测试计划

制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程，包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。在任何类型的系统测试中，制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于：

①构建能够精确地模拟工作环境的测试方案。负载测试指在典型的工作条件下测试应用程序，并检测系统的性能、可靠性和容量等。

②了解测试需要的资源。应用程序测试需要硬件、软件和人力资源。开始测试之前，应了解哪些资源可用并确定如何有效地使用这些资源。

③以可度量的指标定义测试成功条件。明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标（如检测重负载情况下的服务器响应时间）是不够的。明确的成功条件应类似于“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配置要求）

检查测试目标

测试计划应该基于明确定义的测试目标。下面概述了常规的测试目标。

①度量最终用户响应时间。

②定义最优的硬件配置。

③检查可靠性。

④查看硬件或软件升级。

⑤评估新产品。

⑥确定瓶颈。

⑦度量系统容量。

度量最终用户响应时间

查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。如下图显示了一个银行应用程序的负载和响应时间度量之间的关系。

负载和响应时间度量关系

定义最优的硬件配置

检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。

例如，可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异。

. 配置1：200MHz、64MB RAM。

. 配置2：200MHz、128MB RAM。

. 配置3：266MHz、128MB RAM。

检查可靠性

确定系统在连续的高工作负载下的稳定性级别。可以创建系统负载：强制系统在短时间内处理大量任务，来模拟系统在数周或数月的时间内通常会遇到的活动类型。

查看硬件或软件升级

执行回归测试，以便对新旧版本的硬件或软件进行比较。可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。应用程序回归测试需要查看新版本的效率和可靠性是否与旧版本相同。

评估新产品

可以运行测试，以评估单个产品和子系统在产品生命周期中的计划阶段和设计阶段的表现。例如，可以根据评估测试来选择服务器的硬件或数据库套件。

确定瓶颈

可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。使用负载压力测试工具，以及网络和计算机监视工具以生成负载，并度量系统中不同点的性能。如下图所示为系统不同点的性能。

系统不同点的性能

度量系统容量

度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量，可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定了当前容量后，便可以确定是否需要增加资源以支持额外的用户。如下图所示为响应时间与负载关系。

响应时间与负载关系

监控

主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行及潜在问题的及时发现与干预。

（1）服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端Web Server，就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否崩溃、通过ICMP包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，这些只是一部分，还有多种监控方式，依应用特点而定。还有一些问题需解决，如集群过大，如何高性能地进行监控也是一个现实问题。

（2）集群状态类的监控或统计，为合理管理调优集群提供数据参考，包括服务瓶颈、性能问题、异常流量、攻击等问题。

平台建设

底层平台

在区块链产业，平台级的机会是目前很多公司关注的方向。无论是创业公司还是大公司，纷纷在布局区块链底层平台，希望能抢占下一波红利。但是，由于区块链还处于非常早期的阶段，因此各家对于平台的理解和实践路径并不一样。目前，公有链、联盟链和BaaS是三种比较主流的平台模式。

（1）公有链。公有链是指向全世界所有人开放，每个人都能成为系统中的一个节点参与记账的区块链，它们通常将激励机制和加密数字验证相结合，来实现对交易的共识。目前，公有链被看作是区块链领域最有前景的方向，因为它更符合区块链的本质，很可能成为下一个系统级的平台。

（2）联盟链。联盟链是指若干个机构共同参与记账的区块链，即联盟成员之间通过对多中心的互信来达成共识。联盟链的数据只允许系统内的成员节点进行读写和发送交易，并且共同记录交易数据。联盟链作为支持分布式商业的基础组件，更能满足分布式商业中的多方对等合作与合规有序发展要求。联盟链和公链相比，在高可用、高性能、可编程，隐私保护上更有优势，它被认为是“部分去中心”或者是“多中心”的区块链。

（3）BaaS。BaaS通常是一个基于云服务的企业级的区块链开放平台，可一键式快速部署接入、拥有去中心化信任机制、支持私有链、联盟链或多链，拥有私有化部署与丰富的运维管理等特色能力。BaaS目前可广泛应用于金融、医疗、零售、电商、游戏、物联网、物流供应链、公益慈善等行业中，重塑商业模式，提升客户在行业内的影响力。

公有链与联盟链/BaaS虽然采取了不同的策略和发展路径，但是两者依然会长期共存，甚至有些平台最后可能会殊途同归，或者通过跨链技术将分散的联盟链系统与公链相连接，形成更大范围的价值互联网产业生态。

数字资产存储

区块链产业的发展需要有新型的数字资产存储方式，这就催生了数字钱包的诞生。数字钱包提供钱包地址的创建、数字加密资产的转账、钱包地址的历史交易查询等功能。数字钱包按照密码学原理，可以创建一个或多个钱包地址，每个钱包地址对应一个密钥对：私钥和公钥。在数字加密资产的世界里，私钥是最重要的，它是数字加密资产所有权的唯一凭证，因为公钥和地址均能通过私钥推导出来。因此，私钥的生成和存储方式决定了数字加密资产的安全性，而数字钱包的主要作用就是帮助用户管理和使用私钥。安全是数字钱包的根基，一个安全的数字钱包应该能在任何时候都让用户的私钥／助记词处于安全保护之下。目前，数字钱包类型主要分为冷钱包和热钱包等。冷钱包就是不联网的钱包，也叫离线钱包；热钱包就是保持联网上线的钱包，也就是在线钱包。冷钱包不联网会比热钱包更安全，因为它能保证私钥不接触网络，从而防止私钥被黑客窃取。

此外，去中心化也是区块链领域数字钱包发展的一大特点。中心化钱包和去中心化钱包的最根本区别就是，私钥是否自持。去中心化钱包的特点包括：①私钥是用户自持，当然密码也是用户自持；②资产是存储在区块链上，而不是托管在中心化的服务器上，并且目前也无需实名认证，即可生成钱包；③无法实现“账户冻结”“交易回滚”等操作。因此，去中心化钱包很难遭受黑客的集中攻击，用户也不用担心钱包服务商出现监守自盗的情况。

区块链技术解决方案

区块链解决方案主要是指在底层平台的基础上进行扩展，目的是便于开发者基于区块链技术开发出产品和应用，或者是服务商直接为客户提供针对具体业务场景的解决方案。

评审

对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。

系统概要设计

信息化

人们在生活和从事生产等活动中不断产生各种消息，接收者通过各种方式了解到的消息被称为信息。信息的传送一般应借助一定的运载工具，并将信息变换成各种表现形式，如语言、文字、图像、声音等。信息是普遍存在的，像空气一样渗透到全球各个角落、各个领域。人们在生活和工作中要随时随地地获取信息、交流和处理信息，并根据它决策或采取行动。企业为了在竞争中求得生存和发展，获取及时可靠的信息将成为第一需要。信息已同能源和材料一起成为现代化社会的三大资源。信息是资源，而且是一种战略资源。信息与材料、能源不同，信息可以被很多人使用，使用的人越多，创造的价值就越高，而且一条信息可以衍生出多条信息，取之不尽。信息与信息资源不同，信息的日常表现是无序的，但是信息本身存在着内在联系和规律，信息只有通过加工处理才能成为有价值的、可利用的信息资源。随着科技的进步和发展，特别是通信技术、电子技术、激光技术、集成电路、计算机等高技术的出现，在加快经济建设和社会发展的过程中，信息的作用越来越突出，信息和我们的日常生活密切相关，获取信息已经成为我们生活、工作中的重要内容，信息在服务于我们的生活的同时，对我们生活方式的影响也越来越大，所以我们称当前的社会为信息社会。由此衍生出了许多新兴的概念。

信息技术是指对信息进行采集、存储、处理、检索、传递、分析与显示的高技术群。信息技术发展的总趋势是数字化、网络化与智能化，并以互联网技术及其应用技术为中心。信息产业是以现代信息技术为手段，以开发和利用信息资源为中心内容，提供信息产品和信息服务的产业部门。它包括信息产品制造业、软件与信息服务业、通信业。

信息化是指培育、发展以智能化工具为代表的新的生产力并使之造福于社会的历史过程。智能工具一般必须具备信息获取、信息传递、信息处理、信息再生和信息利用的功能。

完整的信息化内涵如下。

（1）信息网络体系，它是大量信息资源、各种专用信息系统及其公用通信网络和信息平台的总称。

（2）信息产业基础，即信息科学技术的研究、开发、信息装备的制造，软件开发与利用，各类信息系统的集成及信息服务。

（3）社会支持环境，即现代工农业生产，以及管理体制、政策法律、规章制度、文化教育、道德观念等生产关系和上层建筑。

（4）效用积累过程，即劳动者素质、国家的现代化水平和人们生活质量不断得到提高，精神文明和物质文明不断获得进步。

通常人们习惯用信息产业部门所制造的收入在国民生产总值中所占的比重和信息从业者占就业人口的比例作为衡量社会信息化程度的指标。粗略认为两者均超过50%以上，其社会已进入信息社会。

业务系统

该重工集团有自己的管理模型。顶端按照工业4.0，集团管控，包括阿米巴经营模式；相应的流程制度，岗位职责，工作标准，成本绩效。左边是信息化管控，右边是智能化建设，下面是精益管理，底下是企业文化。这样的管理需要用信息化系统去实现。

在这架构中，ERP系统是基础，利用CRM系统和客户对接，SRM管理供应链，MES监控生产。利用OA把所有业务打通，而后利用专业软件，实现前端的商务智能分析。

下图的物联网设想把MES系统和机床、物流以及检测设备连起来，做成物联化，把ERP升级到CRM或者SCRM，把供应商和客户打通，形成企业的互联网。

智能工厂物联网体系

下图是整个业务系统的总体架构图。一个平台、两级部署、三层应用，包括商业分析、移动应用、企业门户和协同管理。

智能工厂业务系统整体架构

在业务系统这块，先后上线了ERP系统、PLM系统、OA系统和MES系统。上线的这些系统，虽然参与了生产、管理，打通了业务，却没有让领导层参与，反馈报告依然采用Excel、PPT。作为决策者，领导层更应该参与数据的可视化呈现过程。所以，2014年上线了帆软报表系统，提升了数据前端展示，利用某报表软件承担的BOSS系统决策，将领导层纳入管理体系。

质量控制

质量控制是监督并记录质量活动执行结果，以便评估绩效，并推荐必要的变更过程，其主要作用包括：

.识别过程低效或产品质量低劣的原因，建议并采取相应措施消除这些原因。

.确认项目的可交付成果及工作满足主要干系人的既定需求，足以进行最终验收。

输入

项目管理计划

项目管理计划中包含质量管理计划，用于控制质量。质量管理计划描述将如何在项目中开展质量控制。

质量测量指标

质量测量指标描述了项目或产品属性及其测量方式。质量测量指标的例子包括功能点、平均故障间隔时间（MTBF）和平均修复时间（MTTR）。

质量核对单

质量核对单是结构化清单，有助于核实项目工作及其可交付成果是否满足一系列要求。

工作绩效数据

工作绩效数据包括实际技术性能（与计划比较）、实际进度绩效（与计划比较）和实际成本绩效（与计划比较）。

批准的变更请求

实施整体变更控制过程中批准的变更请求，可包括各种修正，如缺陷补救、修订的工作方法和修订的进度计划。需要核实批准的变更是否已得到及时实施。

可交付成果

可交付成果是任何独特并可核实的产品、成果或能力，最终将成为项目所需的、确认的可交付成果。

项目文件

项目文件可能包括协议、质量审计报告和变更日志（附有纠正行动计划）、培训计划和效果评估、过程文档。

组织过程资产

可能影响质量控制过程的组织过程资产包括组织的质量标准和政策、标准化的工作指南、问题与缺陷报告程序及沟通政策。

工具与技术

七种基本质量工具

七种基本质量工具包括因果图、流程图、核查图、帕累托图、直方图、控制图和散点图，如本章第1张图所示。

统计抽样

统抽样是指按照质量管理计划中的规定，抽取和测量样本。

检查

检查是指检验工作产品，以确定是否符合书面标准。检查的结果通常包括相关的测量数据。检查也可称为审查、同行审查、审计或巡检等。

审计已批准的变更请求

对所有已批准的变更请求进行审查，以核实它们是否已按批准的方式得到实施。

输出

质量控制测量结果

质量控制测量结果是对质量控制活动结果的书面记录。应该以制订质量管理计划过程中所确定的格式加以记录。

确认的变更

对变更或补救过的对象进行检查，做出接受或拒绝的决定，并把决定通知干系人。被拒绝的对象可能需要返工。

核实的可交付成果

质量控制过程的一个目的就是确定可交付成果的正确性。核实的可交付成果是范围确认过程的一项输入，以便正式验收。

工作绩效信息

工作绩效信息是从各控制过程收集，并结合相关背景和跨领域关系进行整合分析而得到的绩效数据。

变更请求

如果推荐的纠正措施、预防措施或缺陷补救导致需要对项目管理计划进行变更，则应按既定的整体变更控制过程的要求，提出变更请求。

项目管理计划更新

项目管理计划中可能需要更新的内容包括质量管理计划和过程改进计划。

项目文件更新

可能需要更新的项目文件包括质量标准、协议、质量审计报告和变更日志（附有纠正行动计划）、培训计划和效果评估、过程文档。

组织过程资产更新

可能需要更新的组织过程资产包括完成的核对单和经验教训文档。

综合管理

统一门户

运维门户（如下图所示）是运维管理的人机交互接口，提供了面向不同角色人的友好界面，方便操作。使得相关人员只要通过门户登录系统，就可以将角色所需的信息和功能推送到浏览器上，与其工作职责相关的最新信息，包括待办事宜、系统通知、作业计划以及个人信息等都一目了然，能够办理与该用户相关的所有待办的工作事宜。

统一门户

系统支持单点登录功能，提供基于Web的统一管理访问入口，支持统一登录、统一认证。

支持与监控、资产配置和流程等管理系统的数据集成，进行统一展示。

具备全文检索功能，快速查询工单、知识、配置项等信息。

支持用户身份认证、授权检查等功能，具备完整的权限管理功能，实现面向组用户组织架构（部门）、角色的单独授权，授权范围包括功能模块、IT资源、展现视图、统计报表、告警列表等。

针对不同的登录用户，提供个人桌面，定位不同用户各自关注的工作内容。

通知中心

系统提供了集中统一的通知中心（如下图所示），将用户关注的信息通过通知中心进行集中展现。

通知中心

具备统一的通知中心，实现监控、事件告警、资产配置、流程工单的统一通知。

提供集中的通知页面，按通知发送时间的倒序、分页显示成功发给当前用户的通知记录。

支持通知策略的定义，包括通知对象、通知方式、业务场景、通知内容等。

提供邮件通知方式、提供短信通知方式、提供声音通知方式、提供Web弹窗通知方式等。

系统支持按照权限展现相关通知内容，即技术人员登录系统后只能看到其权限范围内的通知内容，管理人员通过“我的工作台”——“我的通知”即可查看和他有关的通知信息。系统支持按通知发送时间的倒序、分页显示成功发给当前用户的通知记录；帮助管理人员方便、快捷的了解当前需要完成的工作内容。

通知中心支持灵活的策略设置，包括通知方式、通知对象、业务场景、通知内容等，均可按照实际管理需求进行配置。

此外，系统还提供通知记录的统计和查询，方便后续的跟踪和追溯，对于通知记录，系统提供多种条件查询，包括按通知方式、通知内容、消息等级、通知状态、接受者、通知时间等，如下图所示。

通知记录与查询

报表平台

该维护管理系统包含运行监控、资源配置、运维管理各方面应用的大量原始数据，并支持从多角度综合展现这些数据。广通运维系统内置了大量的运行分析报表，内容包括：资源故障分类统计报表、资源在线率统计报表、资源运行正常率统计报表、资源PKI性能指标分析报表、网络链路性能报表、业务可用性报表，系统用户可通过这些报表和图表，了解IT资源的运行状况和运行趋势。如下图所示为系统内容统计分析报表。