免费智能真题库 > 历年试卷 > 信息系统监理师 > 2013年下半年 信息系统监理师 上午试卷 综合知识
  第30题      
  知识点:   V模型   软件测试   测试类型   开发阶段
  关键词:   开发   软件测试   测试        章/节:   软件与软件工程知识       

 
软件测试类型按开发阶段划分依次是(30)。
 
 
  A.  需求测试、单元测试、集成测试、验证测试
 
  B.  单元测试、系统测试、集成测试、验收测试
 
  C.  单元测试、集成测试、确认测试、系统测试
 
  D.  调试、单元测试、集成测试、用户测试
 
 
 

 
  第31题    2013年上半年  
   40%
软件测试过程中,与用户需求对应的测试是(31)。
  第21题    2018年下半年  
   78%
测试团队需在信息系统集成项目的( )阶段完成集成测试计划。
  第2题    2012年上半年  
   48%
(2)非常明确地标明了软件开发测试过程中存在的不同级别,且清楚地描述了这些测试阶段和开发过程各阶段的对应关系。
   知识点讲解    
   · V模型    · 软件测试    · 测试类型    · 开发阶段
 
       V模型
        在开发模型中,测试常常作为亡羊补牢的事后行为,但也有以测试为中心的开发模型,那就是V模型。V模型只得到软件业内比较模糊的认可。V模型宣称测试并不是一个事后弥补行为,而是一个同开发过程同样重要的过程,如下图所示。
        
        V模型示意图
        V模型描述了一些不同的测试级别,并说明了这些级别所对应的生命周期中不同的阶段。在上图中,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即测试过程的各个阶段。请注意在不同的组织中,对测试阶段的命名可能有所不同。
        V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
        (1)单元测试的主要目的是针对编码过程中可能存在的各种错误。例如,用户输入验证过程中的边界值错误。
        (2)集成测试的主要目的是针对详细设计中可能存在的问题,尤其是检查各单元与其他程序部分之间的接口中可能存在的错误。
        (3)系统测试主要针对概要设计,检查系统作为一个整体是否有效地得到运行。例如,在产品设置中是否达到了预期的高性能。
        (4)验收测试通常由业务专家或用户进行,以确认产品能真正符合用户业务上的需要。
 
       软件测试
        在软件测试阶段,监理的主要活动如下。
        (1)监督承建单位将合适的软件测试工程方法和工具集成到项目定义的软件过程中。
        (2)监督承建单位依据项目定义的软件过程,对软件测试进行开发、维护、建立文档和验证,以满足软件测试计划的要求。
        (3)监督承建单位依据项目定义的软件过程和计划实施软件的确认测试。
        (4)计划和实施软件系统测试,实施系统测试以保证软件满足软件需求。
        (5)软件监理组跟踪和记录软件测试的结果。
        在软件测试阶段,监理的主要方法有定期检查、必要抽查、评审。
        (1)定期审查软件测试的工程活动和工作进度。
        (2)根据实际需要对软件测试工程活动进行跟踪、审查和评估。
        (3)对软件测试工程活动和产品进行评审和(或)审核,并报告结果。
 
       测试类型
        按照测试内容划分,测试类型一般有逻辑测试、功能测试、性能测试、接口测试、人机交互界面测试、强度测试、余量测试、安全性测试、恢复性测试、边界测试、数据处理测试、安装性测试、容量测试等。
        (1)逻辑测试。逻辑测试是测试程序逻辑结构的合理性、实现的正确性。逻辑测试由测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。逻辑测试根据不同的软件级别一般需进行语句覆盖、分支覆盖、条件覆盖、条件组合覆盖、路径覆盖、MC/DC覆盖等。
        (2)功能测试。功能测试是对软件需求规格说明或设计文档中的功能需求逐项进行的测试,以验证其功能是否满足要求。功能测试一般需进行:用正常值的等价类输入数据值测试;用非正常值的等价类输入数据值测试;进行每个功能的合法边界值和非法边界值输入的测试;用一系列真实的数据类型和数据值运行,测试超负荷、饱和及其他“最坏情况”的结果;在配置项测试时对配置项控制流程的正确性、合理性等进行验证。
        (3)性能测试。性能测试是对软件需求规格说明或设计文档中的性能需求逐项进行的测试,以验证其性能是否满足要求。性能测试一般需进行:测试在获得定量结果时程序计算的精确性(处理精度);测试其时间特性和实际完成功能的时间(响应时间);测试为完成功能所处理的数据量;测试程序运行所占用的空间;测试其负荷潜力;测试配置项各部分的协调性;在系统测试时测试软件性能和硬件性能的集成;在系统测试时测试系统对并发事物和并发用户访问的处理能力。
        (4)接口测试。接口测试是对软件需求规格说明或设计文档中的接口需求逐项进行的测试。接口测试一般需进行:测试所有外部接口,检查接口信息的格式及内容;对每一个外部输入/输出接口必须做正常和异常情况的测试;测试硬件提供的接口是否便于使用;测试系统特性(如数据特性、错误特性、速度特性)对软件功能、性能特性的影响;对所有的内部接口的功能、性能进行测试。
        (5)人机交互界面测试。人机交互界面测试是对所有人机交互界面提供的操作和显示界面进行的测试,以检验是否满足用户的要求。人机交互界面测试一般需进行:测试操作和显示界面及界面风格与软件需求规格说明中要求的一致性和符合性;以非常规操作、误操作、快速操作来检验人机界面的健壮性;测试对错误命令或非法数据输入的检测能力与提示情况;测试对错误操作流程的检测与提示;对照用户手册或操作手册逐条进行操作和观察。
        (6)强度测试。强度测试是强制软件运行在不正常到发生故障的情况下(设计的极限状态到超出极限),检验软件可以运行到何种程度的测试。强度测试一般需:提供最大处理的信息量;提供数据能力的饱和实验指标;提供最大存储范围(如常驻内存、缓冲、表格区、临时信息区);在能力降级时进行测试;在人为错误(如寄存器数据跳变、错误的接口)状态下进行软件反应的测试;通过启动软件过载安全装置(如临界点警报、过载溢出功能、停止输入、取消低速设备等)生成必要条件,进行计算过载的饱和测试;需进行持续一段规定的时间,而且连续不能中断的测试。
        (7)余量测试。余量测试是对软件是否达到需求规格说明中要求的余量的测试。若无明确要求时,一般至少留有20%的余量。根据测试要求,余量测试一般需提供:全部存储量的余量;输入/输出及通道的吞吐能力余量;功能处理时间的余量。
        (8)安全性测试。安全性测试是检验软件中已存在的安全性、安全保密性措施是否有效的测试。测试应尽可能在符合实际使用的条件下进行。安全性测试一般需进行:对安全性关键的软件部件,必须单独测试安全性需求;在测试中全面检验防止危险状态措施的有效性和每个危险状态下的反应;对设计中用于提高安全性的结构、算法、容错、冗余及中断处理等方案,必须进行针对性测试;对软件处于标准配置下其处理和保护能力的测试;应进行对异常条件下系统/软件的处理和保护能力的测试(以表明不会因为可能的单个或多个输入错误而导致不安全状态);对输入故障模式的测试;必须包含边界、界外及边界结合部的测试;对“0”、穿越“0”以及从两个方向趋近“0”的输入值的测试;必须包括在最坏情况配置下的最小输入和最大输入数据率的测试;对安全性关键的操作错误的测试;对具有防止非法进入软件并保护软件的数据完整性能力的测试;对双工切换、多机替换的正确性和连续性的测试;对重要数据的抗非法访问能力的测试。
        (9)恢复性测试。恢复性测试是对有恢复或重置功能的软件的每一类导致恢复或重置的情况逐一进行的测试,以验证其恢复或重置功能。恢复性测试是要证实在克服硬件故障后,系统能否正常地继续进行工作,且不对系统造成任何损害。恢复性测试一般需进行:探测错误功能的测试;能否切换或自动启动备用硬件的测试;在故障发生时能否保护正在运行的作业和系统状态的测试;在系统恢复后,能否从最后记录下来的无错误状态开始继续执行作业的测试。
        (10)边界测试。边界测试是对软件处在边界或端点情况下运行状态的测试。边界测试一般需进行:软件的输入域或输出域的边界或端点的测试;状态转换的边界或端点的测试;功能界限的边界或端点的测试;性能界限的边界或端点的测试;容量界限的边界或端点的测试。
        (11)数据处理测试。数据处理测试是对完成专门数据处理功能所进行的测试。数据处理测试一般需进行:数据采集功能的测试;数据融合功能的测试;数据转换功能的测试;剔除坏数据功能的测试;数据解释功能的测试。
        (12)安装性测试。安装性测试是对安装过程是否符合安装规程的测试,以发现安装过程中的错误。安装性测试一般需进行:不同配置下的安装和卸载测试;安装规程的正确性测试。
        (13)容量测试。容量测试是检验软件的能力最高能达到什么程度的测试。容量测试一般应测试到在正常情况下软件所具备的最高能力,如:响应时间或并发处理个数等能力。
        根据软件开发阶段和测试对象,一般可分为单元测试、部件测试(也称为集成测试或组装测试)、配置项测试和系统测试。
               单元测试
               单元测试的对象是软件单元。软件单元测试的目的是检查每个软件单元能否正确地实现设计说明中的功能、性能、接口和其他设计约束等要求,发现单元内可能存在的各种错误。一般由软件的供方组织并实施软件单元测试,也可委托第三方进行软件单元测试。软件单元测试可根据软件单元的重要性、安全性关键等级等对如下技术要求内容进行剪裁,但必须说明理由。单元测试一般应符合以下的技术要求:
               (1)在对软件单元进行动态测试之前,应对软件单元的源代码进行静态测试。
               (2)应建立测试软件单元的环境,如桩模块和驱动模块,其测试环境应通过评审。
               (3)对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试。
               (4)软件单元的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖。
               (5)测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。
               (6)语句覆盖率要达到100%。
               (7)分支覆盖率要达到100%。
               (8)对输出数据及其格式进行测试。
               软件单元测试一般应采用静态测试方法和动态测试方法。通常静态测试先于动态测试。软件单元测试完成后形成的文档有:软件单元测试计划;软件单元测试说明;软件单元测试报告;软件单元测试记录;软件单元测试问题报告。
               部件测试
               部件测试的对象包括软件部件的组装过程和组装得到的软件部件,软件部件由软件单元组成。软件部件测试的目的是检验软件单元和软件部件之间的接口关系,并验证软件部件是否符合设计要求。软件部件测试一般由软件供方组织并实施,测试人员与开发人员应相对独立;也可委托第三方进行软件部件测试。软件部件测试可根据软件部件的重要性、安全性关键等级等对如下技术要求内容进行剪裁,但必须说明理由。部件测试一般应符合以下技术要求:
               (1)应对构成软件部件的每个软件单元的单元测试情况进行检查。
               (2)若对软件部件进行必要的静态测试,应先于动态测试。
               (3)组装过程是动态进行的,因此应标明组装策略。
               (4)应建立部件测试环境,如桩模块和驱动模块,其测试环境应通过评审。
               (5)应逐项测试软件设计文档规定的软件部件的功能、性能等特性。
               (6)软件部件的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖。
               (7)测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。
               (8)应测试软件单元和软件部件之间的所有调用,达到要求的测试覆盖率。
               (9)应测试软件部件的输出数据及其格式。
               (10)应测试软件部件之间、软件部件和硬件之间的所有接口。
               (11)应测试运行条件(如数据结构、输入/输出通道容量、内存空间、调用频度等)在边界状态下,进而在人为设定的状态下,软件部件的功能和性能。
               (12)应按设计文档要求,对软件部件的功能、性能进行强度测试。
               (13)对安全性关键的软件部件,应对其进行安全性分析,明确每一个危险状态和导致危险的可能原因,并对此进行针对性的测试。
               (14)发现是否有多余的软件单元。
               软件部件测试一般应采用静态测试方法和动态测试方法。静态测试方法常采用静态分析、代码审查等方法,动态测试方法常采用白盒测试方法和黑盒测试方法。通常,静态测试先于动态测试。
               在由软件单元和软件部件组装成新的软件部件时,应根据软件单元和软件部件的特点选择便于测试的组装策略。按测试过程中,组合软件单元的方式,有两种不同的组装策略,即一次性组装策略和增值式组装策略。
               一次性组装策略是一种非增值集成方式,首先完成全部软件单元测试,然后再把所有的软件单元集成在一起进行测试,最终得到要求的软件系统。一次性组装策略的优点是工作量相对较小,缺点是定位错误比较困难。
               增值式组装策略也称为递增集成法,即依次将软件单元增加到已测试完成的软件部件中,将已测试的软件部件组装为更大的软件部件,在组装的过程中边增加边测试,以便发现组装过程中的问题。最后增值逐步组装为要求的软件系统。根据组装的过程又可分为自顶向下组装、自底向上组装、“三明治”组装、定向冒险组装、功能定向组装等策略。
               软件部件测试完成后形成的文档包括:软件部件测试计划;软件部件测试说明;软件部件测试报告;软件部件测试记录;软件部件测试问题报告。
               配置项测试
               配置项测试的对象是计算机软件配置项(CSCI,以下简称配置项),软件配置项是为独立的配置管理而设计的并且能满足最终用户功能的一组软件。软件配置项测试的目的是检验软件配置项与软件需求规格说明的致一性。配置项测试可根据软件配置项的重要性、安全性关键等级等对如下技术要求内容进行剪裁,但必须说明理由。配置项测试一般应符合以下技术要求:
               (1)必要时,在高层控制流图中作结构覆盖测试。
               (2)应逐项测试软件需求规格说明规定的配置项的功能、性能等特性。
               (3)配置项的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖。
               (4)测试用例的输入应至少包括有效等价类值、无效等价值和边界数据值。
               (5)应测试配置项的输出及其格式。
               (6)应测试人机交互界面提供的操作和显示界面,包括用非常规操作、误操作、快速操作测试界面的可靠性。
               (7)应测试运行条件在边界状态和异常状态下,或在人为设定的状态下,配置项的功能和性能。
               (8)应按软件需求规格说明的要求,测试配置项的安全性和数据的安全保密性。
               (9)应测试配置项的所有外部输入、输出接口(包括和硬件之间的接口)。
               (10)应测试配置项的全部存储量、输入/输出通道的吞吐能力和处理时间的余量。
               (11)应按软件需求规格说明的要求,对配置项的功能、性能进行强度测试。
               (12)应测试设计中用于提高配置项的安全性和可靠性的方案,如结构、算法、容错、冗余、中断处理等。
               (13)对安全性关键的配置项,应对其进行安全性分析,明确每一个危险状态和导致危险的可能原因,并对此进行针对性的测试。
               (14)对有恢复或重置功能需求的配置项,应测试其恢复或重置功能和平均恢复时间,并且对每一类导致恢复或重置的情况进行测试。
               (15)对不同的实际问题应外加相应的专门测试。
               应保证软件配置项测试工作的独立性。软件配置项测试一般由软件的供方组织,由独立于软件开发的组织实施。软件配置项测试一般应采用黑盒测试方法。
               软件配置项测试完成后形成的文档有:软件配置项测试计划;软件配置项测试说明;软件配置项测试报告;软件配置项测试记录;软件配置项测试问题报告。
               系统测试
               系统测试的对象是完整的、集成的计算机系统(CS),重点是新开发的配置项的集合。系统测试的目的是在真实系统工作环境下检验完整的软件配置项能否和系统正确连接,并满足系统/子系统设计文档和软件开发任务书规定的要求。可根据软件系统的重要性、安全性关键等级等对如下技术要求内容进行剪裁,但必须说明理由。系统测试一般应符合以下技术要求:
               (1)应按系统/子系统设计说明的规定,逐项测试系统的功能、性能等特性。
               (2)系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖。
               (3)测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。
               (4)应测试系统的输出及其格式。
               (5)应测试配置项之间及配置项与硬件之间的所有接口。
               (6)应在边界状态、异常状态或在人为设定的状态的运行条件下,测试系统的功能和性能。
               (7)应测试系统的安全性和数据访问的安全保密性。
               (8)应测试系统的全部存储量、输入/输出通道的吞吐能力和处理时间的余量。
               (9)应按系统或子系统设计文档的要求,对系统的功能、性能进行强度测试。
               (10)应测试人机交互界面提供的操作和显示界面,包括用非常规操作、误操作、快速操作测试界面的可靠性。
               (11)应测试设计中用于提高系统安全性和可靠性的方案,如结构、算法、容错、冗余、中断处理等。
               (12)对安全性关键的系统,应对其进行安全性分析,明确每一个危险状态和导致危险的可能原因,并对此进行针对性的测试。
               (13)对有恢复或重置功能需求的系统,应测试其恢复或重置功能和平均恢复时间,并且对每一类导致恢复或重置的情况进行测试。
               (14)对软件系统的安装性进行测试。
               (15)对不同的实际问题应外加相应的专项测试。
               系统测试一般由软件的需方组织,由独立于软件开发的组织实施。系统测试一般应采用黑盒测试方法。
               系统测试完成后形成的文档包括:系统测试计划;系统测试说明;系统测试报告;系统测试记录;系统测试问题报告。
               可根据需要对上述文档及文档的内容进行裁剪。
 
       开发阶段
               单元测试
               单元测试又称模块测试,是针对软件设计的最小单位——程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
               . 单元测试的内容。
               在进行单元测试时,测试者需要依据详细设计说明书和源程序清单,了解该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理的输入和不合理的输入,都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分,都要进行桌面检查和严格的代码审查。
               在单元测试中进行的测试工作如下图所示,需要在五个方面对所测模块进行检查。
               
               单元测试的工作
               ①模块接口测试。
               在单元测试的开始,应对通过所测模块的数据流进行测试。如果数据不能正确地输入和输出,就谈不上进行其他测试。为此,对模块接口可能需要如下的测试项目:调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配;所测模块调用子模块时,它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配;是否修改了只作输入用的形式参数;输出给标准函数的参数在个数、属性、顺序上是否正确;全局量的定义在各模块中是否一致;限制是否通过形式参数来传送。
               当模块通过外部设备进行输入/输出操作时,必须附加如下的测试项目:文件属性是否正确;OPEN语句与CLOSE语句是否正确;规定的I/O格式说明与I/O语句是否匹配;缓冲区容量与记录长度是否匹配;在进行读写操作之前是否打开了文件;在结束文件处理时是否关闭了文件;正文书写/输入错误,以及I/O错误是否检查并做了处理。
               ②局部数据结构测试。
               模块的局部数据结构是最常见的错误来源,应设计测试用例以检查以下各种错误:不正确或不一致的数据类型说明;使用尚未赋值或尚未初始化的变量;错误的初始值或错误的缺省值;变量名拼写错或书写错;不一致的数据类型。可能的话,除局部数据之外的全局数据对模块的影响也需要查清。
               ③路径测试。
               由于通常不可能做到穷举测试,所以在单元测试期间要选择适当的测试用例,对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试,可以发现大量的路径错误。
               常见的不正确计算有:运算的优先次序不正确或误解了运算的优先次序;运算的方式错,即运算的对象彼此在类型上不相容;算法错;初始化不正确;运算精度不够;表达式的符号表示不正确。
               常见的比较和控制流错误有:不同数据类型的相互比较;不正确的逻辑运算符或优先次序;因浮点数运算精度问题而造成的两值比较不等;关系表达式中不正确的变量和比较符;“差1”错,即不正确地多循环一次或少循环一次;错误的或不可能的循环中止条件;当遇到发散的迭代时不能中止的循环;不适当地修改了循环变量等。
               ④错误处理测试。
               比较完善的模块设计要求能预见出错的条件,并设置适当的出错处理,以便在一旦程序出错时,能对出错程序重做安排,保证其逻辑上的正确性。这种出错处理也应当是模块功能的一部分。若出现下列情况之一,则表明模块的错误处理功能包含有错误或缺陷:出错的描述难以理解;出错的描述不足以对错误定位,不足以确定出错的原因;显示的错误与实际的错误不符;对错误条件的处理不正确;在对错误进行处理之前,错误条件已经引起系统的干预等。
               ⑤边界测试。
               在边界上出现错误是常见的。例如,在一段程序内有一个n次循环,当到达第n次重复时就可能会出错。另外,在取最大值或最小值时也容易出错。因此,要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例,认真加以测试。
               此外,如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。
               虽然模块测试通常是由编写程序的人自己完成的,但是项目负责人应当关心测试的结果。所有测试用例和测试结果都是模块开发的重要资料,必须妥善保存。
               总之,模块测试针对的程序规模较小,易于查错;发现错误后容易确定错误的位置,易于排错,同时多个模块可以并行测试。做好模块测试可为后续的测试打下良好的基础。
               . 单元测试的步骤。
               通常单元测试是在编码阶段进行的。在源程序代码编制完成,经过评审和验证,确认没有语法错误之后,就开始进行单元测试的测试用例设计。利用设计文档,设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入,应有预期的正确结果。
               模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种:
               驱动模块(driver)——相当于所测模块的主程序。它接收测试数据,把这些数据传送给所测模块,最后再输出实测结果。
               桩模块(stub)——也叫做存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作,不需要把子模块所有功能都带进来,但不允许什么事情也不做。
               所测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”,如下图所示。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产品的一部分一同交付,而且它们的编写需要一定的工作量。特别是桩模块,不能只简单地给出“曾经进入”的信息。为了能够正确地测试软件,桩模块可能需要模拟实际子模块的功能,这样,桩模块的建立就不是很轻松了。
               
               单元测试的测试环境
               模块的内聚程度高,可以简化单元测试过程。如果每一个模块只完成一种功能,则需要的测试用例数目将明显减少,模块中的错误也容易被预测和发现。
               当然,如果一个模块要完成多种功能,且以程序包(package)的形式出现的也不少见,这时可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作,对关键模块还要做性能测试。对支持某些标准规程的程序,更要着手进行互联测试。有人把这种情况特别称为模块测试,以区别单元测试。
               集成测试
               集成测试也叫做组装测试或联合测试。通常,在单元测试的基础上,需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
               . 组装时需要考虑的问题。
               ①在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;
               ②一个模块的功能是否会对另一个模块的功能产生不利的影响;
               ③各个子功能组合起来,能否达到预期要求的父功能;
               ④全局数据结构是否有问题;
               ⑤单个模块的误差累积起来,是否会放大,以至达到不能接受的程度。
               因此,在单元测试的同时可进行集成测试,发现并排除在模块连接中可能出现的问题,最终构成要求的软件系统。
               子系统的集成测试称为部件测试,它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
               选择什么方式把模块组装起来形成一个可运行的系统,直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。
               . 模块组装成为系统的方式。
               模块组装成为系统的方式有两种:一次性组装方式和增殖式组装方式。
               ①一次性组装方式(big bang)。
               它是一种非增殖式组装方式,也叫做整体拼装。使用这种方式,首先对每个模块分别进行模块测试,再把所有模块组装在一起进行测试,最终得到要求的软件系统。例如,有一个模块系统结构,如下图(a)所示。其单元测试和组装顺序如下图(b)所示。
               
               一次性组装方式
               在如上图(b)中,模块d1,d2,d3,d4,d5是对各个模块做单元测试时建立的驱动模块,s1,s2,s3,s4,s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下,在分别完成模块单元测试的基础上,将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题,所以一次试运行成功的可能性并不很大。其结果是,发现有错误,却茫然找不到原因。查错和改错都会遇到困难。
               ②增殖式组装方式。
               这种组装方式又称渐增式组装,是首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统,在组装的过程中边连接边测试,以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
               . 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构,沿控制层次自顶向下进行组装。其步骤如下:首先以主模块作为所测模块兼驱动模块,所有直属于主模块的下属模块全部用桩模块代替,对主模块进行测试。再采用深度优先(如下图所示为自顶向下的增殖方式)或广度优先的策略,用实际模块替换相应的桩模块,再用桩模块代替它们的直接下属模块,与已测试的模块或子系统组装成新的子系统。然后,进行回归测试(即重新执行以前做过的全部测试或部分测试),排除组装过程中引入新的错误的可能。最后,判断是否所有的模块都已组装到系统中。是,则结束测试;否则,转到B去执行。
               
               自顶向下的增殖方式
               自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中,判断常常出现在较高的层次里,因而,能够较早地遇到这种问题。如果主要控制有问题,尽早发现它能够减少以后的返工,这是十分必要的。如果选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能,可先对逻辑输入的分支进行组装和测试,检查和克服潜藏的错误和缺陷,验证其功能的正确性,就为其后对主要加工分支的组装和测试提供了保证。此外,功能可行性较早地得到证实,还能够增强开发者和用户成功的信心。
               . 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下:首先由驱动模块控制最底层模块的并行测试;也可以把最底层模块组合成实现某一特定软件功能的簇,由驱动模块控制它进行测试。再用实际模块代替驱动模块,与它已测试的直属子模块组装成为子系统。然后,为子系统配备驱动模块,进行新的测试。最后判断是否已组装到达主模块。是,则结束测试;否则,执行B。
               以如下图一(a)所示的一次性组装方式系统结构为例,可以用如下图二说明自底向上组装和测试的顺序。
               
               一次性组装方式
               
               自底向上的增殖方式
               . 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲,一种方式的优点是另一种方式的缺点。
               自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难,因为,桩模块在接收了所测模块发送的信息后,需要按照它所代替的实际子模块功能返回应该回送的信息,这必将增加建立桩模块的复杂度,而且导致增加一些附加的测试。同时,涉及复杂算法和真正输入/输出的模块一般在底层,它们是最容易出问题的模块,到组装和测试的后期才遇到这些模块,一旦发现问题,就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
               自底向上增殖方式的缺点是“程序一直未能作为一个实体存在,直到最后一个模块加上去后才形成一个实体”。就是说,在自底向上组装和测试的过程中,对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块,而建立驱动模块一般比建立桩模块容易,同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试,可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试,提高测试效率。因此,通常是把以上两种方式结合起来进行组装和测试。
               在进行集成测试时,测试者应当确定关键模块,对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一:
               . 满足某些软件需求;
               . 在程序的模块结构中位于较高的层次(高层控制模块);
               . 较复杂、较易发生错误;
               . 有明确定义的性能要求。
               在做回归测试时,也应该集中测试关键模块的功能。
               . 集成测试的组织和实施。
               集成测试是一种正规测试过程,必须精心计划,并与单元测试的完成时间协调起来。在制定测试计划时,应考虑如下因素:
               ①采用何种系统组装方法来进行集成测试。
               ②集成测试过程中连接各个模块的顺序。
               ③模块代码编制和测试进度是否与集成测试的顺序一致。
               ④测试过程中是否需要专门的硬件设备。
               解决了上述问题之后,就可以列出各个模块的编制、测试计划表,标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
               在缺少软件测试所需要的硬件设备时,应检查该硬件的交付日期是否与集成测试计划一致。例如,若测试需要数字化仪和绘图仪,则相应的测试应安排在这些设备能够投入使用之时,并要为硬件的安装和交付使用保留一段时间,以留下时间余量。此外,在测试计划中需要考虑测试所需软件(驱动模块、桩模块、测试用例生成程序等)的准备情况。
               . 集成测试完成的标志。
               集成测试完成的标志主要有以下几项。
               ①成功地执行了测试计划中规定的所有集成测试。
               ②修正了所发现的错误。
               ③测试结果通过了专门小组的评审。
               集成测试应由专门的测试小组来进行,测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
               在完成预定的集成测试工作之后,测试小组应负责对测试结果进行整理、分析,形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题,提供测试评审和最终决策,以提出处理意见。
               集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
               确认测试
               确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查,确认测试一般由独立的第三方测试机构进行。
               . 进行有效性测试。
               有效性测试是在模拟的环境下,运用黑盒测试的方法,验证所测软件是否满足需求规格说明书列出的需求。为此,需要制定测试计划、测试步骤以及具体的测试用例。通过实施预定的测试计划和测试步骤,确定软件的特性是否与需求相符,确保所有的软件功能需求都能得到满足,所有的软件性能需求都能达到。所有的文档都是正确且便于使用的。同时,对其他软件需求,例如可移植性、可靠性、易用性、兼容性、可维护性等,也都要进行测试,确认是否满足。
               在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类。
               ①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而接受了这部分程序。
               ②测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。
               . 软件配置复查。
               软件配置复查的目的是保证软件配置的所有成分都齐全,各方面的质量都符合要求,具有维护阶段所必须的细节,而且已经编排好分类的目录。
               在确认测试的过程中,还应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查文档资料的完整性和正确性。
               系统测试
               系统测试是将通过集成测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在实际或者模拟运行(使用)环境下,对计算机系统进行一系列测试。
               系统测试的目的在于通过与系统的需求定义作比较,发现软件与系统定义不符合或与之矛盾的地方。
               验收测试
               验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据,并分析测试的输出结果。一般使用生产中的实际数据进行测试。
               目前在国内实际软件开发,特别是系统集成的过程中,验收测试往往在系统测试完成后、项目最终交付前进行。验收测试的测试计划、测试方案与测试案例一般由开发方制定,由用户方与监理方联合进行评审。验收小组由开发方、用户方、监理方代表、主管单位领导及行业专家构成。与确认测试及系统测试不同的是,验收测试往往不是对系统的全覆盖测试,而是针对用户的核心业务流程进行的测试;同时,测试的执行人员也不是开发方的测试组成员,而是由用户方的使用人员完成。
               近年来,越来越多的开发方及用户方认识到对项目进行最终验收测试的重要意义,因此,由第三方完成的专业化全覆盖型技术测试得到了广泛应用。由专门从事测试工作的第三方机构,根据系统的需求分析、用户手册、培训手册等,在开发人员及最终使用人员的配合下,完成对系统全面的测试工作。
   题号导航      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 /
 
第30题    在手机中做本题