某工业企业的生产管理系统项目委托系统集成商A公司进行开发和实施，由A公司的高级项目..

2013年上半年下午试卷案例

第 3 题

知识点	项目验收项目总结测试过程测试阶段工业结论开发人员软件系统生产管理系统维护系统测试系统测试阶段项目计划验收报告验收测试硬件硬件系统

某工业企业的生产管理系统项目委托系统集成商A公司进行开发和实施，由A公司的高级项目经理李某全权负责。按照双方制定的项目计划，目前时间已经到达最后的交付阶段，李某对整体进度情况进行了检查。检查结果是：生产管理系统软件基本开发完成，目前处于系统测试阶段，仍然不断发现缺陷，正在一边测试一边修复；硬件系统已经在客户现场安装完毕，设备正常运行。未来不延误进度，李某决定将目前发现的缺陷再集中修改2天，然后所有开发人员一同去现场进行整体安装联调。
2天后，项目组进入现场，对软件系统进行了部署。李某与客户代表确定了参加验收测试的工作人员，然后开始进行项目验收。在验收过程中，客户认为软件的部分功能不能满足实际工作需要，要求项目组修改。项目组经过讨论后认为对软件进行适当的修改便能够满足客户的需求，便在现场对软件进行了修改。
验收测试过程中发现了部分小缺陷。客户方认为这些小缺陷不影响系统的正常使用。为此双方签署了备忘录，约定系统交付使用后再修复这些缺陷。按照双方的约定，项目组应在试运行前将系统安装手册、使用和维护说明等全套文档移交给客户，但是由于刚刚对软件进行了现场修改，一些文档还未及时更新，因此客户未接受这些文档。由于客户最关心的是试运行，因此李某组织所有力量开展试运行工作。系统上线后，客户发现了一些新问题，同时还有以前遗留的问题未解决。经双方协商，这些问题解决之后再签署验收报告和付款。
回到公司后，公司领导高度重视该项目。项目经理第一时间撰写了项目总结报告，对整个项目实施过程进行了认真的总结和分析。该报告的结论是项目整体进展状况良好，未出现明显问题，本项目可以正常结项。

问题：3.1 请简要叙述该项目在收尾环节存在的主要问题。

问题：3.2 请简要叙述项目经理的总结报告中应包含的主要内容。

问题：3.3 请指出项目组在该系统集成项目收尾后应该向客户移交那些文档？

知识点讲解

· 项目验收

· 项目总结

· 测试过程

· 测试阶段

· 工业

· 结论

· 开发人员

· 软件系统

· 生产管理系统

· 维护

· 系统测试

· 系统测试阶段

· 项目计划

· 验收报告

· 验收测试

· 硬件

· 硬件系统

项目验收

项目验收是项目收尾管理中的首要环节。项目的正式验收包括验收项目产品、文档及已经完成的交付成果。

系统集成项目的验收依据是项目前期所签署的合同内容以及对应的技术工作内容，如果在项目执行过程中发生了合同变更，还应将变更内容也作为项目验收的评价依据。对于软件类型的系统集成项目而言，验收依据除了项目前期的合同内容，还包括甲乙双方签署或认可的软件需求规格说明书。

系统集成项目在验收阶段主要包含以下四方面的工作内容，分别为：

.验收测试：对信息系统进行全面的测试，依照双方合同约定的系统环境，以确保系统的功能和技术设计满足建设方的功能需求和非功能需求，并能正常运行。验收测试阶段应包括编写验收测试用例，建立验收测试环境，全面执行验收测试，出具验收测试报告以及验收测试报告的签署。

.系统试运行：信息系统通过验收测试后，可以开通系统试运行。系统试运行期间主要包括数据迁移、日常维护以及缺陷跟踪和修复等方面的工作内容。

.系统文档验收：系统经过验收测试后，系统的文档应当逐步、全面地移交给客户。客户也可按照合同或者项目工作说明书的规定，对所交付的文档加以检查和评价；对不清晰的地方可以提出修改要求。系统集成项目所涉及的文档一般包括：

系统集成项目介绍。

系统集成项目最终报告。

信息系统说明手册。

信息系统维护手册。

软硬件产品说明书、质量保证书等。

.项目终验：在系统经过试运行以后的约定时间，例如三个月或者六个月，双方可以启动项目的最终验收工作。最终验收的工作包括双方对验收测试文件的认可和接受、双方对系统试运行期间的工作状况的认可和接受、双方对系统文档的认可和接受、双方对结束项目工作的认可和接受。

项目最终验收合格后，应该由双方的项目组撰写验收报告提请双方工作主管认可。这标志着项目组开发工作的结束和项目后续活动的开始。

项目总结

项目总结属于项目收尾的管理收尾。管理收尾有时又被称为行政收尾，即检查项目团队成员及相关干系人是否按规定履行了所有职责。

项目总结的意义

项目总结的主要意义如下：

.了解项目全过程的工作情况及相关的团队或成员的绩效状况。

.了解出现的问题并进行改进措施总结。

.了解项目全过程中出现的值得吸取的经验并进行总结。

.对总结后的文档进行讨论，通过后即存入公司的知识库，从而纳入企业的过程资产。

项目总结会的准备工作

召开项目总结会以前需要做如下准备工作：

.收集整理项目过程文档和经验教训：需要全体项目人员共同参与，对所有的文档进行归类和整理，项目经理可将此项工作列入项目的收尾工作中。

.经验教训的收集和形成项目总结会议的讨论稿：在此初始讨论稿中，项目经理有必要列出项目执行过程中的若干主要优点和若干主要缺点，以利于讨论的时候加以重点呈现。

项目总结会

项目总结会需要全体参与项目的成员都参加，并由全体讨论形成文件。项目总结会议所形成的文件一定要通过所有人的确认，任何有违此项原则的文件都不能作为项目总结会议的结果。项目总结会议还应对项目进行自我评价，以利于后面的项目评估和审计工作开展。

项目总结会通常应讨论如下内容：

.项目绩效：包括项目的完成情况、具体的项目计划完成率、项目目标的完成情况等，作为全体参与项目成员的共同成绩。

.技术绩效：最终的工作范围与项目初期的工作范围比较结果是什么，工作范围上有什么变更，项目的相关变更是否合理，处理是否有效，变更是否对项目质量、进度和成本等有重大影响，项目的各项工作是否符合预计的质量标准，是否达到客户满意。

.成本绩效：最终的项目成本与原始的项目预算费用，包括项目范围的有关变更增加的预算是否存在大的差距，项目盈利状况如何。这牵扯到项目组成员的绩效和奖金的分配。

.进度计划绩效：最终的项目进度与原始的项目进度计划比较结果是什么，进度为何提前或者延后，是什么原因造成这样的影响。

.项目的沟通：是否建立了完善并有效利用的沟通体系；项目沟通管理计划完成情况如何；项目内部会议记录资料是否完备等。

.识别问题和解决问题：项目中发生的问题是否解决，问题的原因是否可以避免，如何改进项目的管理和执行等。

.意见和建议：项目成员对项目管理本身和项目执行计划是否有合理化建议和意见，这些建议和意见是否得到大多数参与项目成员的认可，是否能在未来项目中予以改进。

测试过程

软件测试过程一般包括：测试需求分析、测试策划、测试设计和实现、测试执行、测试总结（包括评价过程和总结），如下图所示。

软件测试过程

测试需求分析

根据被测软件的需求规格说明或设计文档，进行测试需求分析，包括：

（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）审查测试结果的真实性和正确性。

测试阶段

. 可靠性测试（含于集成测试、系统测试）；

. 排错；

. 可靠性建模；

. 可靠性评价；

. 调整可靠性活动计划；

. 收集可靠性数据；

. 明确后续阶段的可靠性活动的详细计划；

. 编制可靠性文档。

工业

立体显示技术可以应用于过程控制、数值模拟、CAD/CAM（计算机辅助设计／制造）设计、工业检测、远程监视、危险产品生产安装以及远程机器人视觉显示等各个方面，可以带来前所未有的逼真视觉效果。

目前，3D技术在专业行业的应用已经十分成熟，包括汽车设计制造、船舶设计制造、航天航空、能源动力、机械电子、建筑房产、城市规划等行业，3D技术为设计方式和用户界面带来了新的革命。3D技术常用的设计软件包括ProE、AutoCAD、3Dmax、MAYA等，这些工具已经成为行业必备的设计软件。在工业设计领域，ProE和AutoCAD已经具备了丰富的3D设计功能，并被广大工程设计人员所采用；在图形图像领域，3Dmax、MAYA已经被广大艺术和IT工作者熟练使用。

结论

从上面的概念和例子可以看出，要进行上面的白盒测试是需要投入巨大的测试资源，包括人力、物力和时间等。但是为什么还要进行白盒测试呢？原因如下。

. 逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们的工作中。日常处理往往被很好地了解（和很好地细查），而“特殊情况”的处理则难以发现。

. 我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设，可能导致设计错误。只有路径测试才能发现这些错误。

. 印刷上的错误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些打印错误，很多将被语法检查机制发现，但是，其他的错误只有在测试开始时才会被发现。打印错误出现在主流上和出现在不明显的逻辑路径上的可能性是一样的。

开发人员

①多媒体软件：项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。

②多媒体电子出版物：策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。

软件系统

网络系统软件包括网络操作系统和网络协议等。网络操作系统是指能够控制和管理网络资源的软件，是由多个系统软件组成，在基本系统上有多种配置和选项可供选择，使得用户可根据不同的需要和设备构成最佳组合的互联网络操作系统。网络协议是保证网络中两台设备之间正确传送数据的约定。

生产管理系统

一旦管理者确定了需求，而且决定要去实施它，后面的任务就是生产管理信息系统的内容了。这里所说的生产是广义的生产。对生产产品的企业来说它就是制造，对于服务业来说它就是服务运营，生产和服务具有一定的相似性。由于生产管理中最困难的最复杂的是制造业，所以这里主要针对制造业来介绍生产管理信息系统，即制造信息系统。

制造信息系统一般可以分为两大类：一类是通过技术实现产品生产的系统；一类是通过管理实现生产的系统。技术信息系统包括：计算机辅助设计（Computer Aided Design，CAD），计算机辅助制造（Computer Aided Manufacturing，CAM），计算机数字控制（Computer Numeric Control，CNC）和机器人（Robot）等。另一类管理系统是以物料需求计划（Material Requirement Planning，MRP），制造资源计划（Manufacturing Resources Planning，MRP-Ⅱ）为中心，还有计算机辅助质量控制（Computer Aided Quality Control，CAQ）等将技术系统和管理系统结合，如计算集成制造系统（Computer Integrated Manufacturing Systems，CIMS）和企业资源规划系统（Enterprises Resources Planning Systems，ERP）等。

传统物料需求计划MRP

MRP的发展经历了三个阶段。20世纪60年代初期主要目的是解决“订货点管理”的不足，发展了主要控制物料的物料需求计划。此阶段的MRP可定义为，利用主生产调度（MPS）对物料用量清单（BOM）、库存（inventory）和未交货单（open order）等各种资料计算后得到未来的物料需求，并进行订单的补充和修改。这一般称为初期的或传统物料需求计划MRP，其系统结构如下图所示。

传统MRP的系统结构

闭环式MRP

20世纪70年代闭环式（closed loop）MRP逐渐取得成功。在制定主生产计划时进行了产能分析，如果可行就去执行物料计划，如果不可行就要反馈回去，重新修改主生产计划，同样在执行物料计划和执行车间计划时出现问题，也要反馈回去，并修改主计划或物料计划。这样就构成了闭环的动态控制。闭环式MRP加强了各子系统之间的联系，既能适应主生产计划的改变，又能适应现场情况的变化，其结构如下图所示。

闭环式MRP的系统结构

制造业全面资源计划与控制系统MRP-Ⅱ

20世纪80年代MRP逐渐为MRP-Ⅱ所代替，这时企业资源不仅是材料，人力、资金、设备和时间也被看成企业资源，并加以控制。它除了生产外，还包括销售、财务、会计及成本的处理，MRP-Ⅱ的功能已能满足制造业的所有经营及生产活动，这也是MRP-Ⅱ被称为“制造业全面资源计划与控制系统”的原因。但总的来说，MRP-Ⅱ是对内管理的系统，企业战略规划、市场方面以及高层决策方面功能较弱，现在又在流行ERP（Enterprises Resources Planning），它是在MRP-Ⅱ的基础上扩充市场、财务等功能的系统。一般MRP-Ⅱ均由10个左右的子系统组成，子系统相对独立，但实现时必须有先有后，各子系统之间联系起来构成MRP-Ⅱ的系统结构图，如下图所示。

MRP-Ⅱ的系统结构

各子系统按运行顺序连接起来称为系统的流程图，如下图所示。

MRP-Ⅱ的系统流程图

MRP-Ⅱ系统的结构和流程因工厂不同可能很不相同。例如有的企业在主计划前还有汇总计划，有的企业财务上有较多的功能等。

目前国内企业用得较多的MRP产品有：SSA公司在AS400上开发的BPICS；QAD公司在HP9000上开发的OPENMFG；ASC公司在DEC机上开发的MANiMANX 1；SAP公司的MRP软件R3等等。

这里主要介绍MRP-Ⅱ系统中的几个主要子系统功能。

主生产计划子系统

主生产计划子系统一般包括两部分：一部分叫总量计划子系统；一部分叫主生产调度计划子系统。

总量计划是关于总体水平的计划，它不是细的要求，例如，总量是钢，不是钢板或钢锭等；计划要用人，是忽略了各种技术的人。它是用标准产品代表所有产品。总量计划的目标是充分利用人力和资源设备。总量计划是制定一年的计划，它考虑用一些方法平衡全年的生产。常用的方法有：经验图表法、管理系数法和最优化方法。

主生产调度计划就是安排具体的产品的生产计划。如果说总量计划的目的是进行宏观控制的话，那么主生产调度计划就是用微观的方法安排可执行的年度计划。它要回答生产什么产品、数量多少、什么日期生产等问题，最终给出一个报表形式的最终报告。主生产调度子系统是企业高层管理与整个系统的主要界面。为了使管理人员做出正确的决策，系统要提供多种形式的模拟功能来辅助决策。

库存管理子系统

库存管理子系统也可以说就是物料需求计划（MRP）子系统，它利用主生产计划（MPS），物料清单（BOM），根据采购、生产等订货资料计算出相关需求的状况，管理库存信息。该系统的主要功能有如下。

计算各种原材料和零部件的需求时间、需求数量和需求地区。

配合作业控制，使仓库和车间管理人员对物料运送、设备和工具需求等事宜及早安排准备。

及时采购原材料，避免库存积压。

计划和控制产品加工全过程，使其准时交货。

库存管理子系统的基本功能如下图所示。

库存管理系统基本功能

库存控制有两种基本方法：订货点技术法（即统计库存控制）和物料需求计划法（MRP法）。对于统计的方法，计算机可以根据消耗的历史数据自动统计出消耗的均值与方差，不断修正订货点，如果对前导期t也作均值与方差统计，可使订货点更为精确。但订货点法的前提是消耗平衡，每次消耗量小，而且适应独立需求。对大多数相关需求行为，并且是突发性的批量需求，必须用物料需求计划法来处理。MRP方法要求处理大量数据，一般制造厂大约需要几万个记录，只有借助计算机才能解决。当某种物资需求既来自独立需求，且消耗平衡，又来自相关需求，且消耗是批量的情况，系统将把两种控制方法综合起来。

库存计划是通过一个循环机制来实现的，循环的步骤简述如下：

（1）库存计划首先确定各个周期的产品总需求，初始根据是主生产计划确定的产品需求量和备品备件需求、试验用需求等。根据历史统计资料和生产上的要求，确定安全存储量。

（2）根据安全库存的要求和当前可用的库存量求得净需求量。考虑经济批量，确定订货日期。

（3）产品按产品结构用MRP的方法逐级进行展开。每展开一级，下一级的组件需求又作为“总需求”的一部分来对待，返回到第（1）步由系统汇总后继续处理，一直展开到原材料、元件为止。

由于系统是一个实时系统，对计划变化的适应和库存出入库业务非常敏感，但如果过于敏感则会降低系统运行的效率。因此库存管理系统应及时准确地记录每一微小变化，但并不是一有变化立即做出全面反应。抑制变化要制定应变的标准，可以定时采取行动，定时的标准可根据实际情况来定，可以几小时，也可以一天，也可按模拟的时间周期来定，也可按库存量来制订标准。

库存管理系统采用“限定需求”技术，即某项的需求可通过计算机搜索，追溯到需要它的上一级需求项。“限定需求”技术对实现各种跟踪功能有很大作用，“限定”技术一般靠数据库来实现。

库存管理系统输出的类型大致有以下几种。

指示库存管理人员做出行动的命令。

向“生产制造活动计划”子系统提供机内输出信息，指示每个项的开发初步计划。

库存系统执行主生产调度计划情况报告。

库存会计与库存控制的执行情况报表。

成本计划与控制子系统

成本系统与生产信息系统共享数据，生产系统及工厂监控系统可以向成本管理系统直接提供数据。

（1）直接劳动成本的计划与控制。一个项目的计划直接劳动成本可以估算，也可以从直接劳动标准推导而得，即用劳动标准和操作时间数来求得。每个项的记录中都存放该项的计划直接劳动成本。信息系统的计算机一次运行，就可根据产品的结构对一个组件的各个组成部分的标准直接劳动成本进行累加，得到该组件的标准直接劳动成本。

实际的直接劳动成本的基本信息来自工厂监控子系统，这些信息包括车间工作令号、机器标识、工作令开始结束时间等。系统分析了实际直接劳动成本与标准直接劳动成本之间的偏差，通知有关成本中心，督促管理人员调整不合理偏差。

（2）材料成本计划与控制。标准材料成本是按标准材料消耗和标准材料单价来计算的。标准价格要由采购部门经常审核。每个项的合理需用量和合理损耗量定为标准材料消耗，按产品结构逐层累加可以得到最终产品的标准材料消耗。

实际材料成本偏差来自采购价格波动、工艺过程变更、加工废品和额外消耗等方面，材料使用的情况来自库存控制系统。

成本计划与控制子系统在分析了材料成本变动的情况后，向有关成本中心提供报告。

（3）管理费的处理。管理费用的计划和控制对成本管理有很大影响。为了有效控制管理费用，要求做到：

对每类开支项目都赋以会计编码，计算机系统可以对会计编码制定得很细。

划分成本中心，其目的是使开支按职能区域汇总。

对成本中心来说，它对某一项成本的升降是负有责任的。计算机系统对每一成本中心标识编码。成本中心常与部门划分相一致。为了使较低层管理人员也参与成本管理，一般把成本中心划分得很细。使用计算机进行管理费分摊时，每个成本可以认为是独立的，每个成本中心赋以分摊编号。它决定分摊次序，越是非直接的成本中心它的分摊编号越小。它的成本先分摊到其他非直接成本中心和直接成本中心，然后再来分摊编号高的成本中心。每个成本中心还要确定一个分摊因子，它提供一个分摊基准，比如人数、占地面积、标准劳动工时、标准机器工时等。

由于计算机的功能，分摊的分组和分摊因子数目不受限制。生产部门（或成本中心）总的管理费可按生产输出进一步分摊，比如铸造铸件重量；热处理工件数目等。这样可把整个管理费分摊到每个加工操作上，又从每个操作的管理费汇总得到每个产品的管理费用上。

计划和控制资产消耗管理子系统

无论考虑收入和支出的平衡，还是作长期的利润规划，都要考虑资产和投资项目的问题。系统在计划和控制资产消耗时自动执行一些计算。固定资产一旦设置，就要有相应记录，系统自动按期进行折旧，并记录每一个变化。一个项目开发的过程中，系统不断重复计算项目投资对将来产品成本的影响。在长期计划范围中反映利润的情况，系统可用关键路径方法利用一切可用资源，加速工程完成，减少投资。

以上介绍了MRP-Ⅱ的主要子系统，作为完整的MRP-Ⅱ系统一般还包括采购管理、指令发放、仓库管理和工厂维护等子系统。采购管理的目的是适时、适量，符合质量地提供原材料和外购件，以减少资金支出和库存，它保存有许多行情数据，而且不断更新，如质量、价格、信用等。它还保存有供应商与供应商的报价管理等。指令发放系统是计划与执行间的桥梁，任何计划只有通过指令发放才能执行，它能发出工作令报告，工作令卡等。仓库管理系统是从物流方面指挥仓库，使仓库达到合理的利用，东西放在合适的地方，如早用的放在外面。工厂维护子系统是负责维修，包括维修期的确定、维修计划的安排，维修材料的准备以及维修费用的管理，有时还应包括事故的应急计划等。由于企业不同，MRP的软件厂家不同，MRP系统的结构和子系统划分很不相同，不过万变不离其宗，它们都不过是这些功能的组合。

维护

维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。

系统测试

系统测试将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来，以需求规格说明为依据，在实际运行环境下进行测试。系统测试过程分为计划与准备、执行、返工与回归测试3个阶段，系统测试一般要完成功能测试、性能测试、恢复测试、安全测试、强度测试以及其他限制条件的测试。

系统测试由独立测试小组在测试组长的监督下进行，测试组长主要负责保证在质量控制和监督下使用测试技术执行系统测试。系统测试过程由一个独立的测试观察员来监控测试工作。

负载测试

负载测试是通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

负载测试的加载方式通常有如下几种。

（1）一次性加载。一次性加载某个数量的用户，在预定的时间段内持续运行。例如，在早晨上班的时间访问网站或登录网站的时间非常集中，基本属于扁平负载模式。

（2）递增加载。有规律地逐渐增加用户，每几秒增加一些新用户，交错上升。借助这种负载方式的测试，容易发现性能的拐点，即性能瓶颈。

（3）高低突变加载。某个时间用户数量很大，突然降到很低，过一段时间，又突然加到很高，反复几次。借助这种负载方式的测试，容易发现资源释放和内存泄露等问题。

（4）随机加载方式。由随机算法自动生成某个数量范围内变化的、动态的负载，这种方式可能是和实际情况最为接近的一种负载方式。虽然不容易模拟系统运行出现的瞬时高峰期，但可以模拟系统长时间的运行过程的状态。

压力测试

压力测试又称为强度测试，是在强负载（加大数据量、大量并发用户等）下的测试，用于查看应用系统在峰值使用情况下的操作行为，目的是发现系统的功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。

微软测试实践经验表明，如果软件产品通过72小时压力测试，则在72小时后出现问题的可能性微乎其微。所以，72小时成为微软产品压力测试的时间标志。

负载测试与压力测试是两个很容易混淆的概念。负载测试是通过逐步增加系统负载，测试其变化，看最后在满足性能的情况下，系统最多能接受多大负载的测试。压力测试是在满足性能的情况下，能使系统处于失效的状态，通俗来说，就是发现在什么条件下，系统的性能会变得不可接受。

压力测试的一般步骤如下：

①进行简单多任务测试。

②简单压力缺陷修正后，增加系统的压力直到系统崩溃。

因此，负载压力测试的主要目的是度量应用系统的性能和扩展性。在实施并发负载过程中，通过实时性能监测来确认和查找问题，并针对所发现的问题对系统性能进行优化。负载压力测试工具能够对整个企业架构进行测试，通过这些测试，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

可靠性测试

软件可靠性是软件质量的一个重要标志。美国电气和电子工程师协会（IEEE）将软件可靠性定义为：系统在特定的环境下，在给定的时间内无故障地运行的概率。软件可靠性涉及软件的性能、功能、可用性、可服务性、可安装性，以及可维护性等多方面特性，是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。

可靠性测试一般伴随着强壮性测试，是评估软件在运行时的可靠性，通过测试确认平均无故障时间（Mean Time to Failure，MTTF）、故障发生前平均工作时间（Mean-Time-To-First-Failure，MTTFF）或因故障而停机的时间（Mean Time To Repairs，MTTR）在一年中应不超过多少时间。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。

安全性测试

安全性测试是测试系统在应付非授权的内部／外部访问、非法侵入或故意的损坏时的系统防护能力，检验系统有能力使可能存在的内／外部的伤害或损害的风险限制在可接受的水平内。可靠性通常包括安全性，但是软件的可靠性不能完全取代软件的安全性。安全性还涉及到数据加密、保密和存取权限等多个方面。

安全性测试需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密漏洞，验证系统的保护机制是否能够在实际中不受到非法的侵入。在安全测试过程中，测试者扮演成试图攻击系统的角色，尝试获取系统密码，利用能够瓦解任何防守的客户软件攻击系统；或者把系统“制服”，使别人无法访问。

安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。破坏系统保护机构的主要方法有以下几种：

（1）正面攻击或从侧面、背面攻击系统中易受损坏的那些部分。

（2）以系统输入为突破口，利用输入的容错性进行正面攻击。

（3）申请和占用过多的资源压垮系统，以破坏安全措施，从而进入系统。

（4）故意使系统出错，利用系统恢复的过程，窃取用户口令及其他有用的信息。

（5）通过浏览残留在计算机各种资源中的垃圾（无用信息），以获取如口令、安全码和译码关键字等信息。

（6）浏览全局数据，期望从中找到进入系统的关键字。

（7）浏览那些逻辑上不存在，但物理上还存在的各种记录和资料等。

一般情况下，网络软件的安全评估包括以下情况；

（1）检验和测试网络软件中涉及数据传输各部分的配量对安全的影响。

（2）会话跟踪是否足够。

（3）是否正确使用了加密技术。

（4）变量限制的设定。

（5）在服务器端执行程序中的安全漏洞。

（6）HTML源码中是否有敏感的信息或没有必须出现的信息。

兼容性／配置测试

兼容性／配置测试用于测试软件与先前发布过的版本、有依赖关系的外部软件、运行的系统的各种版本和硬件平台的不同配置的兼容情况。

可以从如下几个方面进行兼容性测试。

（1）检查版本是否兼容。检查新版本操作习惯与老版本是否兼容，目的是使老版本的用户很快地适应新版本的变化。

（2）检查数据格式是否兼容。数据格式有许多种形式，如文件格式、网络协议和共享数据等。例如，通信协议软件版本升级后，检查升级版本和老版本的通信协议是否一致等。

（3）检查系统调用的兼容性。检查系统的哪些功能依赖于系统调用，是否属于某个平台或版本独有，是否在不同平台上有差异。

（4）检查是否支持操作系统、数据库系统、硬件和软件平台。配置测试用例设计主要指软硬件环境配置的测试用例，检查计算机系统内各个设备或各种资源之间的相互关联和功能分配中的错误。

容错性测试

容错性测试是检查软件在异常条件下自身是否具有防护性措施或者灾难恢复手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动。可以把容错性测试看作是由系统异常处理测试和恢复测试组成的。

可用性测试

可用性是指系统正常运行的能力和用户接受的程度，一般用如下公式表示。

可用性=平均正常工作时间／（平均正常工作时间+平均修复时间）

影响可用性的因素有如下几个：

（1）不充分的测试。

（2）更改管理问题。

（3）缺少在线监视和分析。

（4）操作错误。

（5）弱编码。

（6）与外部服务或应用程序的交互。

（7）不同的操作条件（使用级别更改、峰值重载）。

（8）异常事件（安全性失败、广播风暴）。

（9）硬件故障（硬盘、控制器、网络设备、服务器、电源、内存和CPU）。

（10）环境问题（电源、冷却、火、洪水、灰尘、自然灾害）。

下面给出提高系统可用性的一些办法。

（1）使用集群。集群是指将至少两个系统连接到一起，像一个系统那样工作。当某一系统出现失效时，集群提供即时故障转移服务。

（2）使用网络负载平衡。当检测某服务器失败后，网络负载平衡自动将通信量重新分发给仍然运行的服务器。

（3）使用服务级别协议。可用性指标的期望服务级别要求达到4个或5个“9”。例如，“该应用程序应每周运行7天，每天24小时，年可用性为99.99%”是指全年不能正常工作的时间仅仅只有52分钟，不足1个小时。

（4）提供实时的监视。监视系统的工作负荷和失败数据，实时监视对于发现趋势和改善服务至关重要。

（5）使用数据备份，保证数据安全。

（6）检查所有的安全计划。安全性是确保应用程序服务只对有权使用系统的用户可用，还意味着使得应用程序使用的所有分布式组件和资源受到保护。

文档测试

文档测试是指对软件开发、测试和维护过程中产生的所有文档的测试，包括对需求规格分析说明书、详细设计报告、系统设计报告、用户手册以及与系统相关的一切文档的审阅和评测。例如，系统需求分析和系统设计说明书中的错误将直接导致编码的错误，用户手册作为软件的一部分，将直接影响用户对系统的使用效果。

文档测试强调文档的表述应该清楚、准确，主要包含：

.正确地按照文档描述的方法使用系统。

.测试每一个提示和建议信息。

.使用文档作为测试用例的来源。

.测试每一个在线帮助的超链接。

.测试每条语句。

.测试文档中提供的每一个样例。

.把缺陷写入缺陷跟踪库。

.检查所有的错误信息。

系统测试阶段

UML模型可作为测试阶段的依据。系统的测试通常分为单元测试、集成测试、系统测试和验收测试几个不同级别。

.单元测试是对几个类或一组类的测试，通常由程序员进行。

.集成测试集成组件和类确认它们之间是否恰当的协作。

.系统测试将系统当成一个黑箱，验证系统是否具备用户所要求的所有功能。

.验收测试由客户完成，与系统测试类似，验证系统是否满足所有的需求。

不同的测试小组使用不同的UML图作为测试依据：单元测试使用类图和类规格说明；集成测试使用组件图和合作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。

项目计划

项目计划阶段，监理的主要工作如下。

（1）对软件计划的相关内容（重点是组织、技术标准、开发计划和进度要求等）、项目计划过程、项目计划组织和文档格式等进行审查，确认是否满足要求。

（2）给出符合要求的结论。

（3）确定其可否作为软件开发的前提和依据。

项目计划监理的基本准则如下。

（1）承建单位制订了软件项目计划，同时该项目计划通过了正式的评审，软件项目计划对项目组织、进度计划、工程标准进行了承诺，项目的风险分析合理，风险管理方案可行。

（2）项目的阶段划分是明确的。

验收报告

验收报告的主要内容包括验收的各项内容、评价与验收结论、验收委员会全体成员签字及验收委员会主任的意见。

如果验收未通过，则需要重新验收或进入合同争议。如果验收通过，则监理需要审查承建单位的项目资料清单、协助建设单位和承建单位交接项目资料、确保软件文档和软件的一致性，同时将开发软件做好备份，保管在安全的地方，文件材料归档。

验收测试

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求的那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统了，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能是否如同用户所合理期待的那样。

验收测试的结果有两种可能：一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。

验收测试的常用策略

验收测试通常可以分为正式验收和非正式验收，具体选择的策略通常建立在合同需求、组织和公司标准，以及应用领域的基础上。

正式验收测试

正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。

在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。这种测试形式的优点是：

.要测试的功能和特性都是已知的。

.测试的细节是已知的，并且可以对其进行评测。

.这种测试可以自动执行，支持回归测试。

.可以对测试过程进行评测和监测。

.可接受性标准是已知的。

缺点包括：

.要求大量的资源和计划。

.这些测试可能是系统测试的再次实施。

.可能无法发现软件中由于主观原因造成的缺陷，这是因为只查找了预期要发现的缺陷。

非正式验收测试

在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。

大多数情况下，非正式验收测试是由最终用户组织执行的。这种测试形式的优点是：

.要测试的功能和特性都是已知的。

.可以对测试过程进行评测和监测。

.可接受性标准是已知的。

.与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。

缺点包括：

.要求资源、计划和管理资源。

.无法控制所使用的测试用例。

.最终用户可能沿用系统工作的方式，并可能无法发现缺陷。

.最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。

.用于验收测试的资源不受项目的控制，并且可能受到压缩。

验收测试的条件

在真正进行用户验收测试之前，一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）。

（1）软件开发已经完成，并全部解决了已知的软件缺陷。

（2）验收测试计划已经过评审和批准，并且置于文档控制之下。

（3）对软件需求说明书的审查已经完成。

（4）对概要设计及详细设计的审查已经完成。

（5）对所有关键模块的代码审查已经完成。

（6）对单元、集成、系统测试计划和报告的审查已经完成。

（7）所有的测试脚本已完成，并至少执行过一次，且通过评审。

（8）使用配置管理工具且代码置于配置控制之下。

（9）软件问题处理流程已经就绪。

（10）已经制定、评审并批准验收测试完成标准。

验收测试的过程

（1）软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。

（2）编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并制订出经过客户参与评审的计划。

（3）测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。

（4）测试环境搭建：，建立测试的硬件环境和软件环境等（可在委托客户提供的环境中进行测试）。

（5）测试实施：测试并记录测试结果。

（6）测试结果分析：根据验收通过准则分析测试结果，做出验收是否通过的决定，给出测试评价。

（7）测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。

软件配置审核

软件配置审核包括审查和审核。

审查是指审查可执行程序、源程序、配置脚本、测试程序或脚本、主要的开发类文档和主要的管理类文档。

通常，正式的审核过程分为5个步骤，即计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是指对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是指最终确定工作产品中包含的错误和缺陷。

审核要达到的基本目标是根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。

在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面，由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。

对软件需求说明书的审查，可以从清晰性、完整性、依从性、一致性、可行性和可管理性等几个方面考虑。对软件设计说明书（详细设计说明书、概要设计说明书）的审查，可以从清晰性、完整性、依从性、一致性、可行性、数据使用性、功能性、接口、可维护性、性能、可靠性、易测性和可追溯性等方面考虑。对测试计划（单元测试计划、集成测试计划、确认测试计划、系统测试计划）的审查，可以从完整性、依从性、一致性、正确性、详细级别／程度、易测性／可行性和可追溯性等方面考虑。对软件编码规范的审查，可以考虑源程序文档化、数据说明、输入输出等方面，评审的目的是为了使程序具有良好的风格，便于阅读。

可执行程序的测试

在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后，就可以进行验收测试的最后一个步骤——可执行程序的测试了，包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量5个部分。

不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。

验收测试的内容

具体的测试内容通常可以包括安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）及可靠性测试等。

如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题也都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。

硬件

硬件是计算机物理设备的总称，也称为硬件设备，通常是电子的、机械的、磁性的或光的元器件或装置，一般分为中央处理器、存储器和输入、输出设备。

硬件系统

硬件系统是计算机网络的基础，硬件系统由计算机、通信设备、连接设备及辅助设备组成，通过这些设备的组成形成了计算机网络的类型。下面来学习几种常用的设备。

（1）服务器。在计算机网络中，核心的组成部分是服务器。服务器是计算机网络中向其他计算机或网络设备提供服务的计算机，并按提供的服务被冠以不同的名称，如数据库服务器，邮件服务器等。常用的服务器有文件服务器、打印服务器、通信服务器、数据库服务器、邮件服务器、信息浏览服务器、文件下载服务器等。

（2）客户机。客户机是与服务器相对的一个概念。在计算机网络中享受其他计算机提供的服务的计算机就称为客户机。

（3）网卡。网卡是安装在计算机主机板上的电路板插卡，又称为网络适配器或网络接口卡（Network Interface Board）。网卡的作用是将计算机与通信设备相连接，负责传输或者接收数字信息。

（4）调制解调器。调制解调器（Modem）是一种信号转换装置，可以将计算机中传输的数字信号转换成通信线路中传输的模拟信号，或将通信线路中传输的模拟信号转换成数字信号。一般将数字信号转换成模拟信号，称为“调制”过程；将模拟信号转换成数字信号，称为“解调”过程。调制解调器的作用是将计算机与公用电话线相连，使得现有网络系统以外的计算机用户能够通过拨号的方式利用公用事业电话网访问远程计算机网络系统。

（5）集线器。集线器是局域网中常用的连接设备，有多个端口，可以连接多台本地计算机。

（6）网桥。网桥（Bridge）也是局域网常用的连接设备。网桥又称桥接器，是一种在链路层实现局域网互联的存储转发设备。

（7）路由器。路由器是互联网中常用的连接设备，可以将两个网络连接在一起，组成更大的网络，如局域网与Internet可以通过路由器进行互联。

（8）中继器。中继器可用来扩展网络长度。中继器的作用是在信号传输较长距离后，进行整形和放大，但不对信号进行校验处理等。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5