免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2013年下半年 信息系统项目管理师 上午试卷 综合知识
  第9题      
  知识点:   V模型   编码   编码阶段   测试计划   软件测试   维护
  关键词:   V模型   编码   测试计划   开发   软件测试   维护   测试        章/节:   信息系统项目的生命周期       

 
软件测试不再是一种仅在编码阶段完成后才开始的活动,现在的软件测试被认为是一种应该包括在整个开发和维护过程中的活动,测试工作往往采用V模型来进行,可以从(9)阶段就开始编写测试计划
 
 
  A.  立项
 
  B.  需求分析
 
  C.  设计
 
  D.  编码
 
 
 

  相关试题:V模型          更多>  
 
  第32题    2018年上半年  
   33%
()不是v模型的特点。
  第1题    2013年上半年  
   38%
根据软件生命周期的V模型,系统测试主要针对(1),检查系统作为一个整体是否有效地得到运行。
  第18题    2008年下半年  
   55%
在软件开发的V模型中,应该在(18)阶段制定单元测试计划。
   知识点讲解    
   · V模型    · 编码    · 编码阶段    · 测试计划    · 软件测试    · 维护
 
       V模型
        V模型是最具有代表意义的测试模型,如下图所示。V模型最早是由Paul Rook在20世纪80年代后期提出的,V模型在英国国家计算中心文献中发布,旨在改进软件开发的效率和效果。
        在传统的开发模型中,比如瀑布模型,人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段,尽管有时测试工作会占用整个项目周期一半的时间,但是有人仍然认为测试只是一个收尾工作,而不是主要的过程。V模型的推出就是对此种认识的改进。V模型是软件开发瀑布模型的变种,它反映了测试活动与分析和设计的关系,从左到右,描述了基本的开发过程和测试行为,非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系,如模型图(下图)中所示,图中的箭头代表了时间方向,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。
        
        软件测试V模型
        V模型的软件测试策略既包括低层测试又包括了高层测试,低层测试是为了源代码的正确性,高层测试是为了使整个系统满足用户的需求。
        V模型指出,单元和集成测试是验证的程序设计,开发人员和测试组应检测程序的执行是否满足软件设计的要求;系统测试应当验证系统设计,检测系统功能、性能的质量特性是否达到系统设计的指标;由测试人员和用户进行软件的确认测试和验收测试,追溯软件需求说明书进行测试,以确定软件的实现是否满足用户需求或合同的要求。
        V模型存在一定的局限性,它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段,主要是针对程序进行测试寻找错误,而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。
 
       编码
               编码过程
               在给定了软件设计规格说明书后,下一步的工作就是编写代码。一般来说,编码工作可以分为四个步骤:
               (1)确定源程序的标准格式,制订编程规范。
               (2)准备编程环境,包括软硬件平台的选择,包括操作系统、编程语言、集成开发环境等。
               (3)编写代码。
               (4)进行代码审查,以提高编码质量。为提高审查的效率,在代码审查前需要准备一份检查清单,并设定此次审查须找到的bug数量。在审查时,要检查软件规格说明书与编码内容是否一致;代码对硬件和操作系统资源的访问是否正确;中断控制模块是否正确等。
               编码准则
               在嵌入式系统中,由于资源有限,且实时性和可靠性要求较高,因此,在开发嵌入式软件时,要注意对执行时间、存储空间和开发/维护时间这三种资源的使用进行优化。也就是说,代码的执行速度要越快越好,系统占用的存储空间要越小越好,软件开发和维护的时间要越少越好。
               具体来说,在编写代码时,需要做到以下几点:
               .保持函数短小精悍。一个函数应该只实现一个功能,如果函数的代码过于复杂,将多个功能混杂在一起,就很难具备可靠性和可维护性。另外,要限制函数的长度,一般来说,一个函数的长度最好不要超过100行。
               .封装代码。将数据以及对其进行操作的代码封装在一个实体中,其他代码不能直接访问这些数据。例如,全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性,提高了对象的内聚性,使封装后的代码对其他行为的依赖性较小。
               .消除冗余代码。例如,将一个变量赋给它自己,初始化或设置一个变量后却从不使用它,等等。研究表明,即使是无害的冗余也往往和程序的缺陷高度关联。
               .减少实时代码。实时代码不但容易出错、编写成本较高,而且调试成本可能更高。如果可能,最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。
               .编写优雅流畅的代码。
               .遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜,而且能捕捉到通过传统测试检查不到的各种问题。
               编码技术
                      编程规范
                      在嵌入式软件开发过程中,遵守编程规范,养成良好的编程习惯,这是非常重要的,将直接影响到所编写代码的质量。
                      编程规范主要涉及的三方面内容:
                      .命名规则。从编译器的角度,一个合法的变量名由字母、数字和下画线三种字符组成,且第一个字符必须为字母或下画线。但是从程序员的角度,一个好的名字不仅要合法,还要载有足够的信息,做到“见名知意”,并且在语意清晰、不含歧义的前提下,尽可能地简短。
                      .编码格式。在程序布局时,要使用缩进规则,例如变量的定义和可执行语句要缩进一级,当函数的参数过长时,也要缩进。另外,括弧的使用要整齐配对,要善于使用空格和空行来美化代码。例如,在二元运算符与其运算对象之间,要留有空格;在变量定义和代码之间要留有空行;在不同功能的代码段之间也要用空行隔开。
                      .注释的书写。注释的典型内容包括:函数的功能描述;设计过程中的决策,如数据结构和算法的选择;错误的处理方式;复杂代码的设计思想等。在书写注释时要注意,注释的内容应该与相应的代码保持一致,同时要避免不必要的注释,过犹不及。
                      性能优化
                      由于嵌入式系统对实时性的要求较高,因此一般要求对代码的性能进行优化,使代码的执行速度越快越好。以算术运算为例,在编写代码时,需要仔细地选择和使用算术运算符。一般来说,整数的算术运算最快,其次是带有硬件支持的浮点运算,而用软件来实现的浮点运算是非常慢的。因此,在编码时要遵守以下准则:
                      .尽量使用整数(char、short、int和long)的加法和减法。
                      .如果没有硬件支持,尽量避免使用乘法。
                      .尽量避免使用除法。
                      .如果没有硬件支持,尽量避免使用浮点数。
                      下图是一个例子,其中两段代码的功能完全一样,都是对一个结构体数组的各个元素进行初始化,但采用两种不同的方法来实现。下图(a)采用数组下标的方法,在定位第i个数组元素时,需要将i乘以结构体元素的大小,再加上数组的起始地址。下图(b)采用的是指针访问的方法,先把指针fp初始化为数组的起始地址,然后每访问完一个数组元素,就把fp加1,指向下一个元素。在一个奔腾4的PC上,将这两段代码分别重复10 700次,右边这段代码需要1ms,而左边这段代码需要2.13ms。
                      
                      算术运算性能优化的例子
 
       编码阶段
        . 可靠性测试(含于单元测试);
        . 排错;
        . 调整可靠性活动计划;
        . 收集可靠性数据;
        . 明确后续阶段的可靠性活动的详细计划;
        . 编制可靠性文档。
 
       测试计划
        制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程,包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。在任何类型的系统测试中,制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于:
        ①构建能够精确地模拟工作环境的测试方案。负载测试指在典型的工作条件下测试应用程序,并检测系统的性能、可靠性和容量等。
        ②了解测试需要的资源。应用程序测试需要硬件、软件和人力资源。开始测试之前,应了解哪些资源可用并确定如何有效地使用这些资源。
        ③以可度量的指标定义测试成功条件。明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标(如检测重负载情况下的服务器响应时间)是不够的。明确的成功条件应类似于“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。
                      检查可靠性
                      确定系统在连续的高工作负载下的稳定性级别。可以创建系统负载:强制系统在短时间内处理大量任务,来模拟系统在数周或数月的时间内通常会遇到的活动类型。
                      查看硬件或软件升级
                      执行回归测试,以便对新旧版本的硬件或软件进行比较。可以查看软件或硬件升级对响应时间(基准)和可靠性的影响。应用程序回归测试需要查看新版本的效率和可靠性是否与旧版本相同。
                      评估新产品
                      可以运行测试,以评估单个产品和子系统在产品生命周期中的计划阶段和设计阶段的表现。例如,可以根据评估测试来选择服务器的硬件或数据库套件。
                      确定瓶颈
                      可以运行测试以确定系统的瓶颈,并确定哪些因素导致性能下降,例如,文件锁定、资源争用和网络过载。使用负载压力测试工具,以及网络和计算机监视工具以生成负载,并度量系统中不同点的性能。如下图所示为系统不同点的性能。
                      
                      系统不同点的性能
                      度量系统容量
                      度量系统容量,并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量,可以查看现有系统中性能与负载间的关系,并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定了当前容量后,便可以确定是否需要增加资源以支持额外的用户。如下图所示为响应时间与负载关系。
                      
                      响应时间与负载关系
 
       软件测试
        测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。
        软件测试是针对一个程序的行为,在有限测试用例集合上动态验证软件是否达到预期的行为。
        软件测试过程如下:
        (1)拟定测试计划。
        (2)编制测试大纲。
        (3)设计和生成测试用例。
        (4)实施测试。
        (5)生成测试报告。
        软件测试方法:
        .人工测试:采用人工方式进行测试,目的是通过对程序静态结构的检查,找出编译时不能发现的错误。人工测试包括个人复查、抽查和会审等。
        .机器测试:把设计好的测试用例作用于被测程序,比较测试结果和预期结果是否一致。机器测试包括黑盒测试(功能测试)和白盒测试(结构测试)。
        软件测试伴随软件开发和维护过程,通常可以在概念上划分为以下三个阶段:
        .单元测试:也称为模块测试,在模块编写完成且无编译错误后就可以进行。
        .集成测试:也称为组装测试,就是把模块按系统设计说明书的要求组合起来进行测试。
        .系统测试:是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起,进行信息系统的各种组装和确认测试。其目的是通过与系统需求相比较,发现所开发的系统与用户需求不符合的地方。
 
       维护
        维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来,作为正式的文档资料加以保存。
   题号导航      2013年下半年 信息系统项目管理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第9题    在手机中做本题