免费智能真题库 > 历年试卷 > 系统架构设计师 > 2021年下半年 系统架构设计师 上午试卷 综合知识
  第55题      
  知识点:   软件架构评估   安全性   构件   加密   评估
  章/节:   软件架构评估       

 
在架构评估中,(55)是一个或多个构件(和或构件之间的关系的特性。改变加密级别的设计决策属于(56),因为它可能会对安全性和性能产生非常重要的影响。
 
 
  A.  敏感点
 
  B.  非风险点
 
  C.  权衡点
 
  D.  风险点
 
 
 

 
  第62题    2010年下半年  
   55%
正确识别风险点、非风险点、敏感点和权衡点是进行软件架构评价的关键步骤。其中(62)是实现一个特定质量属性的关键特征,该特征为..
  第63题    2010年下半年  
   54%
正确识别风险点、非风险点、敏感点和权衡点是进行软件架构评价的关键步骤。其中(62)是实现一个特定质量属性的关键特征,该特征为..
  第60题    2014年下半年  
   63%
识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程。“改变业务数据编码方式会对系统的性能和安全性产生影响&..
   知识点讲解    
   · 软件架构评估    · 安全性    · 构件    · 加密    · 评估
 
       软件架构评估
        架构评估可以只针对一个架构,也可以针对一组架构。在架构评估过程中,评估人员所关注的是系统的质量属性。有关质量属性,请参考11.6.3节。
        为了后面讨论的需要,我们先介绍两个概念:敏感点(sensitivity point)和权衡点(tradeoff point)。敏感点和权衡点是关键的架构决策。敏感点是一个或多个构件(和/或构件之间的关系)的特性。研究敏感点可使架构设计师或系统分析师明确在搞清楚如何实现质量目标时应注意什么。权衡点是影响多个质量属性的特性,是多个质量属性的敏感点。例如,改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性,但可能要耗费更多的处理时间,影响系统性能。如果某个机密消息的处理有严格的时间延迟要求,则加密级别可能就会成为一个权衡点。
                      主要的评估方式
                      从目前已有的软件架构评估技术来看,基本可以归纳为3类主要的评估方式:基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。
                             基于调查问卷或检查表的评估方式
                             CMU/SEI(Carnegie Mellon University/Software Engineering Institute,卡耐基梅隆大学的软件工程研究所)的软件风险评估过程采用了这一方式。调查问卷是一系列可以应用到各种架构评估的相关问题,其中有些问题可能涉及到架构的设计决策;有些问题涉及架构的文档,例如架构的表示用的是何种ADL(Architecture Description Language,架构描述语言);有的问题针对架构描述本身的细节问题,如系统的核心功能是否与界面分开。检查表中也包含一系列比调查问卷更细节和具体的问题,它们更趋向于考察某些关心的质量属性。例如,对实时信息系统的性能进行考察时,很可能问到系统是否反复多次地将同样的数据写入磁盘等。
                             这一评估方式比较自由灵活,可评估多种质量属性,也可以在软件架构设计的多个阶段进行。但是由于评估的结果很大程度上来自评估人员的主观推断,因此不同的评估人员可能会产生不同甚至截然相反的结果,而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确的重要因素。尽管基于调查问卷与检查表的评估方式相对比较主观,但由于系统相关的人员的经验和知识是评估软件架构的重要信息来源,因而它仍然是进行软件架构评估的重要途径之一。
                             基于场景的评估方式
                             场景是一系列有序的使用或修改系统的步骤。基于场景的方式主要应用在架构权衡分析方法(Architecture Tradeoff Analysis Method,ATAM)和软件架构分析方法(Software Architecture Analysis Method,SAAM)中。在架构评估中,一般采用刺激(stimulus)、环境(environment)和响应(response)3方面来对场景进行描述。刺激是场景中解释或描述项目干系人怎样引发与系统的交互部分,环境描述的是刺激发生时的情况,响应是指系统是如何通过架构对刺激作出反应的。
                             基于场景的方式分析软件架构对场景的支持程度,从而判断该架构对这一场景所代表的质量需求的满足程度。例如,用一系列对软件的修改来反映易修改性方面的需求,用一系列攻击性操作来代表安全性方面的需求等。这一评估方式考虑到了所有与系统相关的人员对质量的要求,涉及到的基本活动包括:确定应用领域的功能和软件架构的结构之间的映射,设计用于体现待评估质量属性的场景,以及分析软件架构对场景的支持程度。
                             不同的系统对同一质量属性的理解可能不同,例如,对操作系统来说,可移植性被理解为系统可在不同的硬件平台上运行,而对于普通的应用系统而言,可移植性往往是指该系统可在不同的操作系统上运行。由于存在这种不一致性,对一个领域适合的场景设计在另一个领域内未必合适,因此基于场景的评估方式是特定于领域的。这一评估方式的实施者一方面需要有丰富的领域知识,以对某一质量需求设计出合理的场景;另一方面,必须对待评估的软件架构有一定的了解,以准确判断它是否支持场景描述的一系列活动。
                             基于度量的评估方式
                             度量是指为软件产品的某一属性所赋予的数值,如代码行数、方法调用层数、构件个数等。传统的度量研究主要针对代码,但近年来也出现了一些针对高层设计的度量,软件架构度量即是其中之一。基于度量的评估技术都涉及3个基本活动:首先,需要建立质量属性和度量之间的映射原则,即确定怎样从度量结果推出系统具有什么样的质量属性;然后,从软件架构文档中获取度量信息;最后,根据映射原则分析推导出系统的某些质量属性。
                             基于度量的评估方式提供更为客观和量化的质量评估,需要在软件架构的设计基本完成以后才能进行,而且需要评估人员对评估的架构十分了解,否则不能获取准确的度量。
                             比较
                             经过对3类主要的软件架构评估方式的分析,我们用下表从通用性、评估者对架构的了解程度、评估实施阶段、评估方式的客观程度等方面对这3种方式进行简单的比较。
                             
                             3类评估方式比较表
                      ATAM评估方法
                      使用ATAM方法对软件架构进行评估的目标,是理解架构关于软件的质量属性需求决策的结果。ATAM方法不但揭示了架构如何满足特定的质量目标(如性能和可修改性),而且还提供了这些质量目标是如何交互的,即它们之间是如何权衡的。这些设计决策很重要,一直会影响到整个软件生命周期,并且在软件实现后很难以修改这些决策。
                             ATAM评估的步骤
                             整个ATAM评估过程包括9个步骤:
                             (1)描述ATAM方法。评估小组负责人向参加会议的项目干系人介绍ATAM评估方法。在这一步,要解释每个人将要参与的过程,并预留出解答疑问的时间,设置好其他活动的环境和预期结果。关键是要使每个人都知道要收集哪些信息,如何描述这些信息,将要向谁报告等。
                             (2)描述业务动机。参加评估的所有人员必须理解待评估的系统,在这一步,项目经理要从业务角度介绍系统的概况。
                             (3)描述架构。首席架构设计师或设计小组要对架构进行详略适当的介绍。这一步很重要,将直接影响到可能要做的分析及分析的质量。在进行更详细的分析之前,评估小组通常需要收集和记录一些额外的架构信息。
                             (4)确定架构方法。ATAM评估方法主要通过理解架构方法来分析架构,在这一步,由架构设计师确定架构方法,由分析小组捕获,但不进行分析。
                             (5)生成质量属性效用树。评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标,并对这些质量目标设置优先级和细化。这一步很关键,它对以后的分析工作起指导作用。
                             (6)分析架构方法。一旦有了效用树的结果,评估小组可以对实现重要质量属性的架构方法进行考察。这是通过文档化这些架构决策和确定它们的风险、敏感点和权衡点等来实现的。在这一步中,评估小组要对每一种架构方法都考察足够的信息,完成与该方法有关的质量属性的初步分析。这一步的主要结果是一个架构方法或风格的列表,与之相关的一些问题,以及架构设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。
                             (7)讨论和对场景分级。场景在驱动ATAM测试阶段起主导作用,实践证明,当有很多项目干系人参与ATAM评估时,生成一组场景可为讨论提供极大的方便。
                             (8)分析架构方法。在收集并分析了场景之后,架构设计师就可把最高级别的场景映射到所描述的架构中,并对相关的架构如何有助于该场景的实现做出解释。在这一步中,评估小组要重复第(6)步中的工作,把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第(7)步中,如果未产生任何在以前的分析步骤中都没有发现的高优先级场景,则进入第(8)步,就是测试步骤。
                             (9)描述评估结果。最后,要把ATAM分析中所得到的各种信息进行归纳,并反馈给项目干系人。这种描述一般要采用辅以幻灯片的形式,但也可以在ATAM评估结束之后,提交更完整的书面报告。在描述过程中,评估负责人要介绍ATAM评估的各个步骤,以及各步骤中得到的各种信息,包括业务环境、驱动需求、约束条件和架构等。最重要的是要介绍ATAM评估的结果。
                             :我们可以修改这9个步骤的顺序,以满足架构信息的特殊需求。也就是说,虽然这9个步骤按编号排列,但并不总是一个瀑布过程,评估人员可在这9个步骤中跳转或进行迭代。
                             ATAM评估的阶段
                             ATAM方法的各个步骤是随着时间的推移而展开的,可大致分为两个阶段。第一个阶段以架构为中心,重点是获取架构信息并进行分析;第二个阶段以项目干系人为中心,重点是获取项目干系人的观点,验证第一个阶段的结果。
                             之所以要分为两个阶段,是因为评估人员要在第一个阶段收集信息。在整个ATAM评估过程中,评估小组中的部分人(通常是1~3人)要与架构设计师、1或2个其他关键的项目干系人(例如,项目经理、客户经理、市场代表)一起工作,收集信息。对支持分析而言,在大多数情况下,这种信息是不完整的或不适当的,所以,评估小组必须与架构设计师一起协作引导出必须的信息,这种协作通常要花几周的时间。当评估人员觉得已经收集了足够的信息,并已把这些信息记录成文档,则就可以进入第二个阶段了。
                      SAAM评估方法
                      SAAM方法是最早形成文档并得到广泛使用的软件架构分析方法,最初是用来分析架构的可修改性的,但实践证明,SAAM方法也可用于对许多其他质量属性及系统功能进行快速评估。
                      与ATAM方法相比,SAAM比较简单,这种方法易学易用,进行培训和准备的工作量都比较少。SAAM评估可以分6个步骤进行,在这些步骤进行之前,通常有必要对系统做简要的介绍,包括对架构的业务目标的说明等。
                      (1)形成场景。在形成场景的过程中,要注意全面捕捉系统的主要用途、系统用户类型、系统将来可能的变更、系统在当前及可预见的未来必须满足的质量属性等信息。只有这样,形成的场景才能代表与各种项目干系人相关的任务。
                      (2)描述架构。在这一步,架构设计师应该采用参加评估的所有人员都能够充分理解的形式,对待评估的架构进行适当的描述。这种描述必须要说明系统中的运算和数据构件,也要讲清它们之间的联系。除了要描述这些静态特性外,还要对系统在某段时间内的动态特征做出说明。描述既可采用自然语言,也可采用形式化的手段。
                      (3)对场景进行分类和确定优先级。在SAAM评估中,场景就是对所期望的系统中某个使用情况的简短描述。架构可能直接支持该场景,即这一预计的使用情况不需要对架构做任何修改即可实现,一般可以通过演示现有的架构在执行此场景时的表示来确定。在SAAM评估方法中称这样的场景为直接场景。也就是说,直接场景就是按照现有架构开发出来的系统能够直接实现的场景。与在设计时已经考虑过的需求相对应的直接场景并不会让项目干系人们感到意外,但将增进对架构的理解,促进对诸如性能和可靠性等其他质量属性的研究。
                      (4)对间接场景的单个评估。一旦确定了要考虑的一组场景,就要把这些场景与架构的描述对应起来。对于直接场景而言,架构设计师需要讲清所评估的架构将如何执行这些场景;对于间接场景而言,架构设计师应说明需要对架构做哪些修改才能适应间接场景的要求。
                      (5)评估场景的相互作用。当两个或多个间接场景要求更改架构的同一个构件时,我们就称这些场景在这一组构件上相互作用。
                      (6)形成总体评估。最后,评估人员要对场景和场景之间的交互作一个总体的权衡和评价,这一权衡反映该组织对表现在不同场景中的目标的考虑优先级。根据对系统成功的相对重要性来为每个场景设置一个权值,权值的确定通常要与每个场景所支持的业务目标联系起来。如果是要比较多个架构,或者针对同一架构提出了多个不同的方案,则可通过权值的确定来得出总体评价。权值的设置具有很强的主观性,所以,应该让所有项目干系人共同参与,但也应合理组织,要允许对权值及其基本思想进行公开讨论。
                      上述6个步骤是关于SAAM评估中技术方面的问题,与ATAM评估方法类似,在进行SAAM评估时,也要考虑合作关系、准备工作等问题。需要对评估会议的时间做出安排、确定评估小组的人员组成、确定会议室、邀请各类项目干系人、编制会议日程等,这些工作都是必需的。
 
       安全性
        (1)可用性。可用性评价指标及测量,如下表所示。
        
        可用性评价指标及测量
        
        (2)完整性。完整性评价指标及测量,如下表所示。
        
        完整性评价指标及测量
        (3)保密性。保密性评价指标及测量,如下表所示。
        
        保密性评价指标及测量
        
 
       构件
        为了达到门户站点的基本要求,一个企业的网站应当由以下构件组成:
        (1)应用服务器(Application Server)。主要用于企业较大规模电子商务应用的开发、发布和管理,同时实现与企业原有系统的集成。
        (2)工作流和群件服务器。主要用于使工作人员和商业伙伴能通过Internet共享资源、协同工作。
        (3)内容管理子系统。简化企业网站的产品管理、提高效率,并将相应的、经过筛选的内容发送给最终用户。
        (4)目录服务器。企业使用它来管理防火墙内外的用户、资源和控制安全权限,同时为用户的通信和电子商务提供一个通道。
        (5)性能优化工具。改善网站服务质量,包括流量管理、动态数据缓存、网络动态负载(Load Balancing)、知识管理等。
        (6)邮件和消息服务器。使企业和服务提供者能为所有员工、合作伙伴和客户社区提供商业级的通信架构。
        (7)个性化信息服务。在实时分析用户数据的基础上提供一对一的交易平台。通过对用户行为的更好理解,企业更跟踪、分析和理解网站用户。
        (8)搜索引擎。用户提供更广泛的资源。
        (9)安全服务器。包括数据安全、应用安全和交易完全。其基本内容有用防火墙阻止对网络的非授权访问,在安全和个人的角色授权的基础上,只需一次登录就可以访问网站的所有应用,通过提供一种对在线交易的每一方的可信任的授权方式,帮助客户、合作伙伴和员工访问Internet应用。
        (10)网站服务器(Web Server)。将各种网站的信息发布给用户。
        以上是通常构建网站所需要的构件,企业可针对自己的特点以及网站规模大小,应用的类型等自行选择。
        在网站结构的实现上,通常在逻辑上将网站分为三层:表示层、应用逻辑层、数据层。这种结构使得网站具有较好的可扩充性,将表示层与业务功能的实现分离开来,能够更灵活地适应业务的发展。网站不需要对业务逻辑组件进行任何变动,就能够适用新出现的表示形式和客户端。例如,为了使用户更方便地在网站上购物,网站调整了页面格局和页面风格。由于网站结构层次分明,只需要改动网站表示层,业务逻辑层和数据连接层则不需要改变。
        (11)表示层和相关技术。表示层用于为最终用户提供一个友好的用户界面,接受用户提交的事件,并将处理的结果返还给用户。这一层作为应用的前端和“窗口”,决定了用户对网站优劣的评价和总体印象。
        网站从总体上说是独立于客户端的,客户端包括基于浏览器的HTML客户端、给予Java的客户端、传统的C/C++应用、Power Builder客户端以及VB客户端。
        在表示层除了使用最基本的HTML语言外,通常还利用JavaScript Internet脚本语言,以及Java Internet程序开发语言。JavaScript程序运行在客户端,能够完成用户事件获取、数据提交前的合法性校验、错误检查和实现动画效果等。而利用Java开发的JavaServlet程序运行于服务器端,负责实现与业务逻辑层的交互,从业务逻辑层获得数据,并将用户提交的信息传给业务逻辑层,而基于Java语言的JSP程序,则实现数据的动态显示,它将JavaServlet程序获得的数据形成相应的HTML页面传给客户端。
        为了适应电子商务的各种需求,新的表示层技术不断发展。如XML(可扩展标记语言)和RDF(资源描述框架)等都是当前最新的、对表示层产生重大影响的技术。XML通过一种结构化的文本方式来表述数据;RDF提供一种统一的、可互操作的方法通过Internet在程序间交换元数据。
        (12)商务逻辑与实现。商务逻辑层是电子商务系统的核心,也是系统建造过程中的重点和难点。商务逻辑层包括商务应用程序、支持平台(包括商务服务层、商务支持层和基础支持层)。
        支持层向上层(商务应用层)提供的服务主要包括:表达、商务支持、运行支持、开发与集成服务。构成支持平台的技术产品至少应当包括:Web服务器、商务支持软件、集成与开发工具、计算机主机、网络及其他系统软件(如操作系统、管理工具软件等)。
        通常,Web服务器、商务支持软件、部分集成开发环境被集成到一个被称为“应用服务器”的软件包里,所以商务逻辑层在物理上可以简化为以下三个部门:应用软件(实现商务逻辑);应用服务器(为应用软件提供软件支持平台)和其他支持软件;计算机主机及网络(为应用软件提供硬件支持平台)。
        构造商务逻辑层的任务是为选择合适的应用服务器和其他支持软件,开发实现商务逻辑的应用软件系统。
        (13)数据层及实现。构造数据层的关键是开发电子商务与外部系统、内部资源系统的接口,完成系统集成。
        数据层的数据源主要包括:相关信息系统(如ERP系统)的数据与企业的数据库,企业与协作企业(如供应商)间交换的数据,企业与银行间交换的数据,企业与认证中心之间的认证数据,企业与其他商务中介交换的电子数据。
        由于企业商务逻辑的处理过程是一个从市场、销售、采购到客户服务的整体,所以必须将商务逻辑处理过程中所涉及到的数据集成到一起,因此构造数据层的任务是:实现电子商务系统与企业内部和外部信息系统之间的网络互联,并确保安全的网络环境,基于应用服务器平台的商务应用系统与企业内部数据的共享。
 
       加密
               保密与加密
               保密就是保证敏感信息不被非授权的人知道。加密是指通过将信息进行编码而使得侵入者不能够阅读或理解的方法,目的是保护数据和信息。解密是将加密的过程反过来,即将编码信息转化为原来的形式。古时候的人就已经发明了密码技术,而现今的密码技术已经从外交和军事领域走向了公开,并结合了数学、计算机科学、电子与通信等诸多学科而成为了一门交叉学科。现今的密码技术不仅具有保证信息机密性的信息加密功能,而且还具有数字签名、身份验证、秘密分存、系统安全等功能,来鉴别信息的来源以防止信息被篡改、伪造和假冒,保证信息的完整性和确定性。
               加密与解密机制
               加密的基本过程包括对原来的可读信息(称为明文或平文)进行翻译,译成的代码称为密码或密文,加密算法中使用的参数称为加密密钥。密文经解密算法作用后形成明文,解密算法也有一个密钥,这两个密钥可以相同也可以不相同。信息编码的和解码方法可以很简单也可以很复杂,需要一些加密算法和解密算法来完成。
               从破译者的角度来看,密码分析所面对的问题有三种主要的变型:①“只有密文”问题(仅有密文而无明文);②“已知明文”问题(已有了一批相匹配的明文与密文);③“选择明文”(能够加密自己所选的明文)。如果密码系统仅能经得起第一种类型的攻击,那么它还不能算是真正的安全,因为破译者完全可能从统计学的角度与一般的通信规律中猜测出一部分的明文,而得到一些相匹配的明文与密文,进而全部解密。因此,真正安全的密码机制应使破译者即使拥有了一些匹配的明文与密文也无法破译其他的密文。
               如果加密算法是可能公开的,那么真正的秘密就在于密钥了,密钥长度越长,密钥空间就越大,破译密钥所花的时间就越长,破译的可能性就越小。所以应该采用尽量长的密钥,并对密钥进行保密和实施密钥管理。
               国家明确规定严格禁止直接使用国外的密码算法和安全产品,原因主要有两点:①国外禁止出口密码算法和产品,目前所出口的密码算法都有破译手段,②国外的算法和产品中可能存在“后门”,要防止其在关键时刻危害我国安全。
               密码算法
               密码技术用来进行鉴别和保密,选择一个强壮的加密算法是至关重要的。密码算法一般分为传统密码算法(又称为对称密码算法)和公开密钥密码算法(又称为非对称密码算法)两类,对称密钥密码技术要求加密解密双方拥有相同的密钥。而非对称密钥密码技术是加密解密双方拥有不相同的密钥。
               对称密钥密码体制从加密模式上可分为序列密码和分组密码两大类(这两种体制之间还有许多中间类型)。
               序列密码是军事和外交场合中主要使用的一种密码技术。其主要原理是:通过有限状态机产生性能优良的伪随机序列,使用该序列将信息流逐比特加密从而得到密文序列。可以看出,序列密码算法的安全强度由它产生的伪随机序列的好坏而决定。分组密码的工作方式是将明文分成固定长度的组(如64比特一组),对每一组明文用同一个密钥和同一种算法来加密,输出的密文也是固定长度的。在序列密码体制中,密文不仅与最初给定的密码算法和密钥有关,同时也是被处理的数据段在明文中所处的位置的函数;而在分组密码体制中,经过加密所得到的密文仅与给定的密码算法和密钥有关,而与被处理的明数据段在整个明文中所处的位置无关。
               不同于传统的对称密钥密码体制,非对称密码算法要求密钥成对出现,一个为加密密钥(可以公开),另一个为解密密钥(用户要保护好),并且不可能从其中一个推导出另一个。公共密钥与专用密钥是有紧密关系的,用公共密钥加密的信息只能用专用密钥解密,反之亦然。另外,公钥加密也用来对专用密钥进行加密。
               公钥算法不需要联机密钥服务器,只在通信双方之间传送专用密钥,而用专用密钥来对实际传输的数据加密解密。密钥分配协议简单,所以极大简化了密钥管理,但公共密钥方案较保密密钥方案处理速度慢,因此,通常把公共密钥与专用密钥技术结合起来实现最佳性能。
               密钥及密钥管理
               密钥是密码算法中的可变参数。有时候密码算法是公开的,而密钥是保密的,而密码分析者通常通过获得密钥来破译密码体制。也就是说,密码体制的安全性建立在对密钥的依赖上。所以,保守密钥秘密是非常重要的。
               密钥管理一般包括以下8个内容。
               (1)产生密钥:密钥由随机数生成器产生,并且应该有专门的密钥管理部门或授权人员负责密钥的产生和检验。
               (2)分发密钥:密钥的分发可以采取人工、自动或者人工与自动相结合的方式。加密设备应当使用经过认证的密钥分发技术。
               (3)输入和输出密钥:密钥的输入和输出应当经由合法的密钥管理设备进行。人工分发的密钥可以用明文形式输入和输出,并将密钥分段处理;电子形式分发的密钥应以加密的形式输入和输出。输入密钥时不应显示明文密钥。
               (4)更换密钥:密钥的更换可以由人工或自动方式按照密钥输入和密钥输出的要求来实现。
               (5)存储密钥:密钥在加密设备内采用明文形式存储,但是不能被任何外部设备访问。
               (6)保存和备份密钥:密钥应当尽量分段保存,可以分成两部分并且保存在不同的地方,例如一部分存储在保密设备中,另一部分存储在IC卡上。密钥的备份也应当注意安全并且要加密保存。
               (7)密钥的寿命:密钥不可以无限期使用,密钥使用得越久风险也就越大。密钥应当定期更换。
               (8)销毁密钥:加密设备应能对设备内的所有明文密钥和其他没受到保护的重要保护参数清零。
 
       评估
        评估测试不只针对物理设备,更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统(如路由器)和网络技术(如ATM或FDDI等)的评估。评估测试不适用于全局网络,因为全局网络拓扑负载、网络设备太多,不好准确定位引起问题的原因和位置,不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
        很多公司都有其固定合作的网络设备供应商,如路由器、集线器或交换机的供应商,通常很少再做设备比较测试,但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题,所以技术评估是评估测试中很重要的一项。
        在比较设备与技术时,除了使用专用于待测设备或技术的工程负载外,有经验的程序员也使用真实负载,使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较,可以获知待测设备还有多少多余容量。
        评估测试与设备或技术的功能/特征测试一样,用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
        评估测试实质是衰减测试的基础,评估测试中对几种设备或技术进行比较;衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划/设计阶段进行测试是非常好的方法,最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
        评估测试是最常进行的测试,在设备选型、技术选型,以及网络系统升级过程中都要进行或多或少的评估测试。
        用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形(工程负载)和真实负载模式进行测试,两种方式都提供了唯一的、重要的检测结果,测试人员要能够理解、解释测试结果间的不同。
        工程检测结果是被测设备和技术在最理想的情形下测试得到的结果,因此不能在真实运行环境里显示它们的运行性能;真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能,但无法预测设备的总容量。如果时间允许,两种测试都要做。通常测试人员只有时间进行一种测试,一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形(工程负载)下的测试结果。
        所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置,任何有效、公正的测试配置都能对被测产品进行很好的比较。然而,测试配置和负载越接近运行网络的配置和负载,测试的结果越能反映被测设备在运行网络中的运行情况。
        在安装和配置测试网络时必须注意:要确保配置中所有测试组件都是最新版本,使测试尽可能地公正和统一,以取得最好的测试结果。在测试非正式版时一定要小心,因为发布日期经常有错误。测试配置中安装了非正式版后,它还可能会变,所以非正式版的测试结果和正式版的测试结果经常不一致,分析非正式版的设备经常会延误项目的进行。
        进行评估测试时,除了被测设备,测试配置中的所有网络组件都要保持不变。这一点非常重要,只有这样才能保证被测设备可以进行公平比较。对于子网,这一点很容易做到(一个网络设备很容易被另一个设备所替代)。
        网络技术评估要比较各种网络技术,因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换,路由器也需要更换。传输负载和端点的配置要保持不变。
        需要评估测试计划中的各个测试任务,逐步完成测试、数据收集和数据解释。在评估测试中,各测试进行的先后次序没有关系,因为它们不是线性关系,而是多次重复进行的。当在测试中发现了新的信息时,以前所做的测试可能要重新进行以确定它的测试结果,或要对以前的测试稍作改变以检验网络运行的其他方面。此外,在评估期间设备提供商经常发布新的版本或非正式的版本,所以各种基于这种设备的测试都要重新进行。
        制定网络设备、技术比较或取舍标准时,不仅要参考评估测试所得的测试结果数据,还要综合考虑其他一些信息,如各设备的性能价格比,但由于没有运行网络的持续和峰值负载要求,所以缺少比较基准,往往将产品评估测试引入歧途。
        最后要根据评估测试所得的数据和图表对网络系统作出总结性评估,并撰写网络系统评估报告。
   题号导航      2021年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第55题    在手机中做本题