免费智能真题库 > 历年试卷 > 信息系统监理师 > 2012年上半年 信息系统监理师 下午试卷 案例
  第5题      
  知识点:   承建单位   电子商务   监理单位   建设单位   性能测试   测试过程   审核   完整性

 
【说明】
电子商务应用系统项目已由承建单位完成了开发工作,正在开展验收前的各项测试工作。为了保证系统上线后业务的顺畅运行,建设单位要求监理单位承建单位性能测试进行重点把关和审核。在性能测试过程中,监理单位重点检查了承建单位测试方案及相应的测试指标设定,保证了测试的正确性和完整性
 
问题:5.1   测试方案中设定的压力测试指标中,并发用户数是监理关注的重点内容,现假设该系统有100人同时在线,在线状态如下:
①45人填写调查问卷 ②30人浏览各种网页 ③25人在线聊天
则对服务器系统压力最大的应用是()(从下述候选答案中选择)。
A.① B.② C.③ D.无法判定
监理人员需要了解性能测试相关的简单命令,比如查看内存统计的linux命令是()(从下述候选答案中选择)。
A. vmstat B. iostat C. top D. netstat
 
问题:5.2   为保证性能测试指标的合理性,监理审核了与操作系统、数据库、应用软件等相关的性能指标,请指出这些性能指标包括哪些。
 
 
 

   知识点讲解    
   · 承建单位    · 电子商务    · 监理单位    · 建设单位    · 性能测试    · 测试过程    · 审核    · 完整性
 
       承建单位
        负责具体实施的承建方应该有自己的项目管理,监理方代表项目建设方对承建方提出的工程计划进行监督和协调,对一些关键点进行控制。这些关键点主要属于进度、资金及质量的范畴,但不能涉及管理细节。工程项目管理主要以承建方为主,并强调在项目中组织并制定相关计划。
        在一个大型信息系统工程项目的建设中,承建方可能有多个,比如硬件提供商、软件开发商和系统集成商等。而在市场竞争日益激烈的今天,专业化能促进生产效率和提高生产质量,故而承建方常常分解成一定的层次结构,如总承包商和分包商等,从而使一部分人或企业专注于项目管理的科学化。
        从市场的角度看,总承包商既是买方又是卖方;从工程合同的角度来讲,他既要对建设方负全部法律责任,又要根据分包合同对分包商进行管理并履行义务,所有的主合同都会限定总承包商可以分包的最大范围。总承包商只能将某些具体的工程施工分包给分包商,但不能分包合同的责任和义务。总承包商不能期望通过分包逃避自己在合同中的法律和经济责任。
        作为分包商,一般情况下不与建设方直接发生合同关系。分包商只接受总承包商的统筹安排和调度,它只对总承包商承担分包合同内规定的责任并履行规定的义务。
        如果总承包商违反分包合同,则应该赔偿分包商的经济损失;分包商违反分包合同并造成建设方对总承包商的罚款或制裁,则分包商应该赔偿总承包商的损失。分包商是从总承包商处按分包合同索回其应得部分的,如果总承包商无力偿还债务,则分包商也同样蒙受损失,因此分包商的利益通常与总承包商的利益密切相关。
 
       电子商务
        电子商务是指买卖双方利用现代开放的Internet,按照一定的标准所进行的各类商业活动,主要包括网上购物、企业之间的网上交易和在线电子支付等新型的商业运营模式。狭义的电子商务是指利用Web提供的通信手段在网上买卖产品或提供服务;广义的电子商务除了以上内容外,还包括企业内部的商务活动,如生产、管理、财务等,以及企业间的商务活动,即把买家、卖家、厂家和合作伙伴通过Internet、Intranet和Extranet连接起来所开展的业务。
        电子商务分三个方面,即电子商情广告、电子选购和交易,电子交易凭证的交换、电子支付与结算,以及网上售后服务等。参与电子商务的实体有4类:顾客(个人消费者或集团购买)、商户(包括销售商、制造商和储运商)、银行(包括发卡行和收单行)及认证中心。电子商务主要有三种模式,分别是B2B、B2C和C2C。
        (1)企业对企业(Business To Business,B2B):是指企业与企业之间通过因特网进行产品、服务及信息的交换。B2B电子商务模式包括两种基本模式,一种是企业之间直接进行的电子商务(如制造商的在线采购和在线供货等),另一种是通过第三方电子商务网站平台进行的商务活动。
        (2)企业对个人(Business To Customer,B2C):商家对消费者,也就是通常说的商业零售,即直接面向消费者销售产品和服务。最具有代表性的B2C电子商务模式就是网上零售网站。B2C电子商务的模式并不是唯一的,专门依靠网站开展网上零售只是B2C电子商务的一种形式,企业网站也可以开设面向消费者的在线直接销售,这也是B2C电子商务的表现形式。
        (3)个人对个人(Customer To Customer,C2C):消费者对消费者的交易,简单地说就是消费者本身提供服务或产品给消费者,最常见的形态就是个人工作者提供服务给消费者,如保险从业人员、促销人员的在线服务及销售网点或是商品竞标网站。此类网站非企业对消费者,而是由提供服务的消费者与需求服务的消费者私下达成交易的方式。C2C商务平台就是通过为买卖双方提供一个在线交易平台,使卖方可以主动提供商品上网拍卖,而买方可以自行选择商品进行竞价。
 
       监理单位
        项目监理方服务于信息系统建设合同的建设方与承建方。接受建设方委托后,监理方作为工程承包合同的监督者,所执行的原则是使工程承包合同成为“平等条约”;作为工程承包合同管理和工程款支付的签认者,所执行的原则是等价交换。因此监理方是为双方的利益服务的,而不仅仅为委托方服务。
        根据工程监理的深入程度不同,信息系统工程监理可分为如下三种。
        (1)咨询式监理。只解答用户方就企业信息化过程中提出的问题,其性质类似于业务咨询或方案咨询。这种方式费用最少,监理方的责任最轻,适合于对信息化有较好把握,并且技术力量较强的用户方采用。
        (2)里程碑式监理。将信息系统的建设划分为若干个阶段,在每一个阶段结束都设置一个里程碑,在里程碑到来时通知监理方进行审查或测试。一般来讲,这种方式比咨询式监理的费用要多,监理方也要承担一定的责任。不过,里程碑的确定需要承建方的参与,或者说监理合同的确立需要开发方的参与,否则就会因对里程碑的界定不同而引起纠纷。
        (3)全程式监理。一种复杂的监理方式,不但要求对系统建设过程中的里程碑进行审查,还应该派相应人员全程跟踪并收集系统开发过程中的信息,不断评估承建方的开发质量和效果。这种方式费用最高,监理方的责任也最大,适合于那些对信息系统的开发不太了解且技术力量偏弱的用户采用。
        监理单位的主要作用如下。
        (1)信息系统工程监理可以帮助建设单位更合理地保证工程的质量、进度和投资,并合理且客观地处理好它们之间的关系。监理由独立的第三方依据相关技术标准来对工程建设进行监督,这样对信息系统工程的建设质量更能起到保驾护航的作用。在项目建设全过程中,监理单位要依据国家有关法律和相关技术标准,遵循守法、公平、公正、独立的原则,对信息系统建设的过程进行监督和控制。即在确保质量、安全和有效性的前提下,合理安排进度和投资。监理单位要帮助建设单位对工程有关方面控制进行再控制,对承建单位项目控制过程进行监督管理。
        (2)在信息系统工程建设中,建设单位和承建单位有许多问题存在争议,双方都希望由第三方在工程的立项、设计、实施、验收及维护等各个阶段的效果都给予公正、恰当且权威的评价,这就需要监理单位来协调和保障这些工作的顺利进行。
        (3)由于建设单位在信息技术等相关领域普遍存在缺乏人才和经验不足的问题,实践证明建设单位自行管理对于提高项目投资的效益和建设水平是无益的。通过第三方的专业服务,帮助建设单位对项目实施控制,并对建设单位和承建单位都做出约束,是监理作用一个重要体现。
 
       建设单位
        建设方是建设项目的主要投资者,有时也是项目的最终使用者,是在工程建设阶段的全权代表,建设项目的经济效益,如投资额度、工程质量、投入使用时间和使用寿命直接关系着建设方的切身利益。虽然承建方、监理方与建设方是平等的市场主体,但由于建设方是投资方,掌握着项目的最终资源——决定了其他方为从属地位,所以说建设方对工程项目管理起着主导性作用。建设方加强和改善对项目的管理是从根本上实现项目按质如期完成的最有效的途径之一。
        作为项目管理集体中的主要负责人,建设方的作用是阐明本项目的目标并确认各项工作的轻重缓急,组织协调参与各方为此目标而通力合作,在管理决策过程中做出决策。但在某些具体的项目管理事务中,建设方并不总是处于主要负责人的地位,还要作为裁判、支持者、服务员及督促员的角色。
 
       性能测试
        性能测试是通过自动化的测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行,统称为负载压力测试。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或不能接收的性能点来获得系统能提供的最大服务级别的测试。
               性能测试的目的
               性能测试的目的是验证软件系统是否能够达到用户提出的性能指标,同时发现软件系统中存在的性能瓶颈,并优化软件,最后起到优化系统的目的。具体来说,包括以下几个方面。
               (1)评估系统的能力。测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力,并帮助做出决策。
               (2)识别体系中的弱点。受控的负荷可以被增加到一个极端的水平并突破它,从而修复体系的瓶颈或薄弱的地方。
               (3)系统调优。重复运行测试,验证调整系统的活动得到了预期的结果,从而改进性能。
               (4)检测软件中的问题。长时间的测试执行可导致程序发生由于内存泄露等引起的失败,揭示程序中隐含的问题或冲突。
               (5)验证稳定性和可靠性。在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
               性能测试的类型
               性能测试类型包括负载测试、强度测试和容量测试等。
               (1)负载测试:一种性能测试,指数据在超负荷环境中运行,程序是否能够承担。
               (2)强度测试:在系统资源特别低的情况下考查软件系统运行情况。
               (3)容量测试:确定系统可处理的同时在线的最大用户数。
               性能测试的步骤
               由于工程和项目的不同,所选用的度量及评估方法也有不同之处。不过仍然有一些通用的步骤可帮助我们完成一个性能测试项目。其步骤如下:
               (1)制定目标和分析系统。
               (2)选择测试度量的方法。
               (3)学习相关技术和工具。
               (4)制定评估标准。
               (5)设计测试用例。
               (6)运行测试用例。
               (7)分析测试结果。
               负载压力测试
               系统的负载压力测试(负载测试)中的负载是指系统在某种指定软件、硬件及网络环境下承受的流量,例如并发用户数、持续运行时间、数据量等,其中并发用户数是负载压力的重要体现。系统在应用环境下主要承受并发访问用户数、无故障稳定运行时间和大数据量操作等负载压力。
               负载压力测试的目的如下。
               (1)在真实环境下检测系统性能,评估系统性能是否可以满足系统的性能设计要求。
               (2)预见系统负载压力承受力,对系统的预期性能进行评估。
               (3)进行系统瓶颈分析、优化系统。
               在网络应用系统中,负载压力测试应重点关注客户端、网络及服务器(包括应用服务器和数据库服务器)的性能。应获取的关键测试指标如下。
               (1)客户端:并发用户数、响应时间、交易通过率及吞吐量等。
               (2)网络:带宽利用率、网络负载、延迟,以及网络传输和应用错误等。
               (3)服务器:操作系统的CPU占用率、内存使用和硬盘I/O等;数据库服务器的会话执行情况、SQL执行情况、资源争用及死锁等;应用服务器的并发连接数、请求响应时间等。
 
       测试过程
        软件测试过程一般包括:测试需求分析、测试策划、测试设计和实现、测试执行、测试总结(包括评价过程和总结),如下图所示。
        
        软件测试过程
               测试需求分析
               根据被测软件的需求规格说明或设计文档,进行测试需求分析,包括:
               (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)审查测试结果的真实性和正确性。
 
       审核
        依据知识库内容加入的审核标准,由资深技术人员审核内容的正确性和完整性,避免与原有的知识库内容重复或冲突,给出审核意见后提交批准加入知识库中。
 
       完整性
        完整性(Integrity)是指网络信息或系统未经授权不能进行更改的特性。例如,电子邮件在存储或传输过程中保持不被删除、修改、伪造、插入等。完整性也被称为网络信息系统CIA三性之一,其中I代表Integrity。完整性对于金融信息系统、工业控制系统非常重要,可谓“失之毫厘,差之千里”。
   题号导航      2012年上半年 信息系统监理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
 
第5题    在手机中做本题