免费智能真题库 > 历年试卷 > 信息系统监理师 > 2011年上半年 信息系统监理师 上午试卷 综合知识
  第39题      
  知识点:   其他经典模型   需求分析   W模型   测试策略   测试设计   设计过程   质量控制
  关键词:   测试策略   监理方   系统设计   需求分析   质量控制   测试   监理   需求        章/节:   软件与软件工程知识       

 
审查测试设计是监理方质量控制的重要手段。根据常用的W模型测试策略,在需求分析与系统设计过程中,监理方应审杳的相应测试设计为(39) 。
 
 
  A.  验收测试设计与性能测试设计
 
  B.  用户测试设计与集成测试设计
 
  C.  单元测试设计与集成测试设计
 
  D.  确认测试设计与系统测试设计
 
 
 

 
  第32题    2014年下半年  
   43%
软件系统测试计划需要在(32)阶段编制。
  第32题    2010年下半年  
   50%
(32)不是基于组件的开发模型的特点。
  第31题    2013年上半年  
   40%
软件测试过程中,与用户需求对应的测试是(31)。
   知识点讲解    
   · 其他经典模型    · 需求分析    · W模型    · 测试策略    · 测试设计    · 设计过程    · 质量控制
 
       其他经典模型
        在瀑布模型和原型法的基础上衍生出了很多其他的模型,本节将简单介绍这些开发模型。
               变换模型
               变换模型(演化模型)是在快速开发一个原型的基础上,根据用户在调用原型的过程中提出的反馈意见和建议,对原型进行改进,获得原型的新版本,重复这一过程,直到演化成最终的软件产品。
               螺旋模型
               螺旋模型将瀑布模型和变换模型相结合,综合了两者的优点,并增加了风险分析。它以原型为基础,沿着螺线自内向外旋转,每旋转一圈都要经过制定计划、风险分析、实施工程及客户评价等活动,并开发原型的一个新版本。经过若干次螺旋上升的过程,得到最终的系统。螺旋模型的核心思想是循环,在每个循环的出口设置里程碑。
               喷泉模型
               喷泉模型为软件复用和生存周期中多项开发活动的集成提供了支持,主要支持面向对象的开发方法。“喷泉”一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次,相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动中,分析、设计和编码之间不存在明显的边界。
               智能模型
               智能模型是基于知识的软件开发模型,它综合了上述若干模型,并与专家系统结合在一起。该模型应用基于规则的系统,采用归约和推理机制,帮助软件人员完成开发工作,并使维护在系统规格说明一级进行。
               V模型
               在开发模型中,测试常常作为亡羊补牢的事后行为,但也有以测试为中心的开发模型,那就是V模型。V模型只得到软件业内比较模糊的认可。V模型宣称测试并不是一个事后弥补行为,而是一个同开发过程同样重要的过程,如下图所示。
               
               V模型示意图
               V模型描述了一些不同的测试级别,并说明了这些级别所对应的生命周期中不同的阶段。在上图中,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即测试过程的各个阶段。请注意在不同的组织中,对测试阶段的命名可能有所不同。
               V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
               (1)单元测试的主要目的是针对编码过程中可能存在的各种错误。例如,用户输入验证过程中的边界值错误。
               (2)集成测试的主要目的是针对详细设计中可能存在的问题,尤其是检查各单元与其他程序部分之间的接口中可能存在的错误。
               (3)系统测试主要针对概要设计,检查系统作为一个整体是否有效地得到运行。例如,在产品设置中是否达到了预期的高性能。
               (4)验收测试通常由业务专家或用户进行,以确认产品能真正符合用户业务上的需要。
               增量模型
               增量模型融合了瀑布模型的基本成分(重复的应用)和原型实现的迭代特征。增量模型采用随着时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时,第一个增量往往是核心的产品,也就是说第一个增量实现了基本的需求,但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复,直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
               增量模型像原型实现模型和其他演化方法一样,本质上是迭代的。但与原型实现不同的是,增量模型强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本,但它们确实提供了为用户服务的功能,并且提供了给用户评估的平台。增量模型的特点是引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求,而且还需要更改,但只要这个增量包足够小,其影响对整个项目来说是可以承受的。
               采用增量模型的优点是人员分配灵活,刚开始不用投入大量人力资源,如果核心产品很受欢迎,则可以增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时,它提供了一种先推出核心产品的途径,这样就可以先发布部分功能给客户,对客户起到“镇静剂”的作用。此外,增量能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且不能很好地处理,就必须做全盘的系统分析。增量模型采用的将功能细化、分别开发的方法适用于需求经常改变的软件开发过程。
 
       需求分析
        软件需求分析监理的主要任务和目的是对软件需求分析的相关内容(重点是工程需求、功能需求、性能需求和设计约束等)、需求分析过程、需求分析活动及文档格式进行审查,确认是否满足要求,并确定其可否作为软件开发的前提和依据。
        (1)参与用户需求调研,尤其是关键业务及有甲乙双方决策人物参与的大型交流会等。
        (2)组织有关单位参加《需求规格说明书》技术联合评审会议,并根据国家相关标准、软件工程理论、用户需求及工程建设合同等进行审查并提出监理意见。
        (3)根据项目管理的理论,审核承建单位递交的《项目开发计划》。审核的重点是项目参与人员的技术工作背景是否适应本项目、工作分配及进度计划是否合理,以及软件开发风险因素分析、风险防范措施是否到位等。
        (4)审核承建单位提交的软件开发的质量保证及配置管理计划等软件生存周期支持过程的文档。
        (5)审核承建单位针对本工程投入的软硬件资源是否满足工程需要并及时到位。
        (6)审核承建单位在开发过程中使用的软件工具的合法性。
        (7)主持监理例会,做好监理日记,定期将项目进展情况及发现的问题汇总,并以项目月报的形式向项目建设单位做书面汇报。
        (8)做好项目往来文档的整理及存档工作。
        在需求分析阶段,监理工作的重点是对软件需求规格说明书和项目开发计划的审核。
 
       W模型
               W模型建立
               V模型的局限性在于没有明确地说明早期的测试,不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试,被演化为一种W模型,因为实际上开发是“V”,测试也是与此相并行的“V”。基于“尽早地和不断地进行软件测试”的原则,在软件的需求和设计阶段的测试活动应遵循IEEE std 1012-1998《软件验证和确认(V&V)》的原则。
               一个基于V&V原理的W模型示意图如下图所示。
               
               软件测试W模型
               W模型应用
               W模型由Evolutif公司提出,相对于V模型,W模型更科学。W模型可以说是V模型自然而然的发展。它强调:测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。这样,只要相应的开发活动完成,我们就可以开始执行测试,可以说,测试与开发是同步进行的,从而有利于尽早地发现问题。以需求为例,需求分析一完成,我们就可以对需求进行测试,而不是等到最后才进行针对需求的验收测试。
               如果测试文档能尽早提交,那么就有了更多的检查和检阅的时间,这些文档还可用于评估开发文档。另外还有一个很大的益处是,测试者可以在项目中尽可能早地面对规格说明书的挑战。这意味着测试不仅仅是评定软件的质量,测试还可以尽可能早地找出缺陷所在,从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度,这将可以显著地减少总体测试时间,加快项目进度。
               根据W模型的要求,一旦有文档提供,就要及时确定测试条件,以及编写测试用例,这些工作对测试的各级别都有意义。当需求被提交后,就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后,就需要确定测试条件来查找该阶段的设计缺陷。
               W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样的,软件开发和测试保持一种线性的前后关系,需要有严格的指令表示上一阶段完全结束,才可正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。对于当前很多文档需要事后补充,或者根本没有文档的做法下(这已成为一种开发的文化),开发人员和测试人员都面临同样的困惑。
 
       测试策略
        由于标准符合性测试的不同分类,其相应的测试原理也不尽相同。
               数据内容类标准
               如《教育管理信息化标准》(第1部分《学校管理信息标准》),在测试工具设计上,其实现原理如下所示。
               . 将符合标准的信息集(表结构)与代码集(表内容)构建在测试工具数据库中,即建立标准模板;
               . 测试工具通过ODBC、JDBC等数据库连接方式连接被测软件的数据库;
               . 测试工具提供人工或自动方式建立模板库与被测库之间的关联,读取并验证相关数据表信息;
               . 生成信息集与代码集标准符合性检测结果报告。
               注意,在实际应用中,从易维护的角度出发,被测软件的代码集可能不是多个不同类别的小代码表集,而是一个包含各种类别的大代码表,但测试工具模板库往往是多个不同类别的小代码表集,这就要求测试工具能够实现一对多或多对多的关联设置。
               而对于检察机关网络应用软件的数据格式规范与代码符合性规范的测试工具,可采用网上已有的相关工具或自行开发。如数据格式规范测试可辅助采用已有的XML解析器进行,而代码符合性规范可采取自行开发测试工具方式执行,测试步骤包括工具中建立标准模板、连接被测软件、与标准模板比对测试和输出测试结果。
               通信协议类标准
               测试工具的实现原理与第一类标准基本相似,如中国远程教育CELTS-20教学管理标准中的,基于HTTP协议绑定规范的,测试工具可以这样实现:①建立标准模拟课件;②导入模拟课件到被测平台;③测试工具自动运行模拟课件,主动与被测平台进行数据通信;④将二者通信内容与工具中的标准模板内容进行比较,得出比较分析结果。
               开发接口类标准
                      SQL标准符合性测试
                      按照SQL92/97标准,全面测试一个SQL产品的功能特性。在详细研究美国标准技术研究所(NIST)的测试用例库(即在整个测试过程中,只需要执行全部的测试用例文件,最后统计通过的测试用例即可)的基础上,可自行开发一个集测试和结果的定量分析于一体的自动化测试工具,利用该测试工具可以直接选择被测文件,运行并统计运行的结果。
                      通过的入门级测试用例数占入门级测试用例总数的比例,即为入门级测试通过率。通过的过渡级测试用例数占过渡级测试用例总数的比例,即为过渡测试通过率。
                      为了保证测试结果的真实性,还可采用交互式测试用例验证测试结果,如果发现问题,则相应的嵌入式测试用例的结果视为不通过。
                      ODBC标准
                      可采用SWsoft Inc开发的ODBC2.5标准符合性测试工具进行测试。在此基础上,按照ODBC3.0标准对测试用例进行相当规模的修改和扩充,并且将微软的QUICK TEST测试工具的部分模块集成到该测试工具中,同时对测试结果进行了定量的分析。
                      其中,对API函数的测试,参照微软的测试工具(QuickTest)对每个函数选定一种最简单的参数组合来测试,仅用其作简单的支持性测试。此项测试根据通过测试的函数的百分比来计算。对于其他的更重要的应用功能,是通过其他更详细、更复杂的测试用例来验证的,其执行结果的成功与否直接记录为测试结果。
                      JDBC标准
                      可在SUN公司开发的JDBC标准符合性测试工具基础上,按照JDBC3.0标准对测试用例进行修改和扩充,同时加入对测试结果的定量分析功能。
                      JDBC标准符合性测试完成后,统计各个接口或类中API函数通过的测试用例点的数量,按用例通过的比例和每个类或接口所占的权值计算总体得分。
               信息编码类标准
               例如,对GB 18030中文符合性测试,包括字汇完整性和体系正确性两方面。
               对于字汇完整性可采用抽样测试的方法,其过程如下。
               . 生成标准测试文件。即依照GB 18030的字符集生成字符数据文件(如.TXT),包括GB 18030中定义的全部汉字区、符号区、保留区和用户自定义区。
               . 运行被测软件,打开已生成的标准文本文件,将屏幕显示内容与GB 18030中指定内容进行对比,记录屏幕显示对比结果。
               . 运行待测软件,打开已生成的文本文件并打印其内容,将打印结果与GB 18030中指定内容进行对比,记录打印对比结果。
               . 抽样对比。例如:抽样方法可定义为单字节抽样率达到100%,双字节1区抽样率达到约20%,双字节2区抽样率达到约15%,双字节3区抽样率达到约10%,双字节4区抽样率达到约5%,双字节5区抽样率达到约20%和四字节区抽样率达到约5%。抽样范围包括边界字符和中间随机字符,如有错误则抽样率加倍,直至抽样率达到100%。各区矩阵的抽样率均应达到100%。抽样对比测试办法如下:单字节区,逐字对比。双字节1~5区,以第一字节相同的所有字符构成一个矩阵为一个检查单位,每矩阵抽查第一个字符、最后一个字符,在其他字符中按前述抽样率随机抽查数个字符,如果被抽样字符中出现对比结果不符合现象,或发现明显的“?”、方框、连续空白,则按前述抽样方法进行。双字节用户区1~3,与用户文档中承诺的用户自定义字符列表或用户自定义界面的输入结果进行对比,抽样率为10%;如没有用户自定义字符,则应不显示字符。四字节区,每区抽查第一个字符、最后一个字符,在其他字符中随机抽查数个字符(区抽样率≥5%),如果被测字符中出现对比结果不符合现象,或发现明显的“?”、方框、空白,则对比整个矩阵。
               对于体系正确性测试,其测试过程包括:
               . 生成随机文件,即从GB 18030定义的全部字符中随机抽取,而形成的大于5000字符的文本。文本中包括单字节区、各双字节区、四字节区中的字符,所有字符随机组合。
               . 编辑处理,即在被测的软件平台上,将已生成的随机文件打开,并进行编辑处理,包括插入字符、删除字符、存储字符、复制粘贴、打印等操作,各类操作均包括单字节区、各双字节区、四字节区中的字符。
               . 记录结果,即记录编辑处理文本文件的结果。
               对于字汇完整性,符合以下所有条件的,字汇完整性成绩为通过,其他情况为不通过。
               . 单字节区显示和打印的符合率均等于100%。
               . 双字节各区显示和打印的符合率均大于98%。
               . 四字节区显示和打印的符合率均大于97%。
               对于体系正确性,插入字符、删除字符、存储字符、复制粘贴、打印等编辑操作处理正确为通过,出现乱字符、多字符、丢字符或其他影响编辑操作的处理结果为不通过。只有在字汇完整性与体系正确性的成绩均为通过时,总成绩为通过。其他情况为不通过。
               目前,由于GB 18030的测试主要依靠人工验证,所以测试过程相对繁琐一些。
 
       测试设计
        就每一项测试而言,软件测试过程包括测试计划、测试设计、测试执行和测试评估等阶段。测试设计是整个测试过程中非常重要的一个环节,测试设计的输出结果是测试执行活动依赖的执行标准,测试设计的充分性决定了整个软件过程的测试质量。为了保证测试质量,应从多方面来综合考虑系统需求的实现情况,从以下几个层次来进行测试设计:用户层、应用层、功能层、子系统层、协议层。
        用户层测试是面向产品最终的使用操作者的测试,重点突出的是从操作者角度上,测试系统对用户支持的情况,用户界面的规范性、友好性、可操作性,以及数据的安全性等。主要包括用户支持测试、用户界面测试、可维护性测试和安全性测试。
        应用层测试是针对产品工程应用或行业应用的测试,重点放在系统应用的角度,模拟实际应用环境,对系统的兼容性、可靠性、性能等进行测试。主要包括系统性能测试、系统可靠性、系统稳定性测试、系统兼容性测试、系统组网测试和系统安装升级测试。
        功能层测试是针对产品具体功能实现的测试,主要包括功能覆盖测试、功能分解测试、功能组合测试和功能冲突测试。
        子系统层测试是针对产品内部结构性能的测试,重点关注子系统内部的性能、模块间接口的瓶颈。主要包括单个子系统性能测试、子系统间的接口瓶颈测试和子系统间的相互影响测试。
        协议层测试是针对系统支持的协议的测试,主要包括协议一致性测试和协议互通性测试。
 
       设计过程
        结构化设计的过程如下。
        (1)精化DFD。
        (2)确定DFD的信息流类型(变换流或事务流)。
        (3)根据流类型分别将变换流或事务流转换成程序结构图。
        (4)根据软件设计的原则对程序结构图做优化。
        (5)描述模块功能、接口及全局数据结构。
        (6)复查。
 
       质量控制
        质量控制是监督并记录质量活动执行结果,以便评估绩效,并推荐必要的变更过程,其主要作用包括:
        .识别过程低效或产品质量低劣的原因,建议并采取相应措施消除这些原因。
        .确认项目的可交付成果及工作满足主要干系人的既定需求,足以进行最终验收。
               输入
                      项目管理计划
                      项目管理计划中包含质量管理计划,用于控制质量。质量管理计划描述将如何在项目中开展质量控制。
                      质量测量指标
                      质量测量指标描述了项目或产品属性及其测量方式。质量测量指标的例子包括功能点、平均故障间隔时间(MTBF)和平均修复时间(MTTR)。
                      质量核对单
                      质量核对单是结构化清单,有助于核实项目工作及其可交付成果是否满足一系列要求。
                      工作绩效数据
                      工作绩效数据包括实际技术性能(与计划比较)、实际进度绩效(与计划比较)和实际成本绩效(与计划比较)。
                      批准的变更请求
                      实施整体变更控制过程中批准的变更请求,可包括各种修正,如缺陷补救、修订的工作方法和修订的进度计划。需要核实批准的变更是否已得到及时实施。
                      可交付成果
                      可交付成果是任何独特并可核实的产品、成果或能力,最终将成为项目所需的、确认的可交付成果。
                      项目文件
                      项目文件可能包括协议、质量审计报告和变更日志(附有纠正行动计划)、培训计划和效果评估、过程文档。
                      组织过程资产
                      可能影响质量控制过程的组织过程资产包括组织的质量标准和政策、标准化的工作指南、问题与缺陷报告程序及沟通政策。
               工具与技术
                      七种基本质量工具
                      七种基本质量工具包括因果图、流程图、核查图、帕累托图、直方图、控制图和散点图,如本章第1张图所示。
                      统计抽样
                      统抽样是指按照质量管理计划中的规定,抽取和测量样本。
                      检查
                      检查是指检验工作产品,以确定是否符合书面标准。检查的结果通常包括相关的测量数据。检查也可称为审查、同行审查、审计或巡检等。
                      审计已批准的变更请求
                      对所有已批准的变更请求进行审查,以核实它们是否已按批准的方式得到实施。
               输出
                      质量控制测量结果
                      质量控制测量结果是对质量控制活动结果的书面记录。应该以制订质量管理计划过程中所确定的格式加以记录。
                      确认的变更
                      对变更或补救过的对象进行检查,做出接受或拒绝的决定,并把决定通知干系人。被拒绝的对象可能需要返工。
                      核实的可交付成果
                      质量控制过程的一个目的就是确定可交付成果的正确性。核实的可交付成果是范围确认过程的一项输入,以便正式验收。
                      工作绩效信息
                      工作绩效信息是从各控制过程收集,并结合相关背景和跨领域关系进行整合分析而得到的绩效数据。
                      变更请求
                      如果推荐的纠正措施、预防措施或缺陷补救导致需要对项目管理计划进行变更,则应按既定的整体变更控制过程的要求,提出变更请求。
                      项目管理计划更新
                      项目管理计划中可能需要更新的内容包括质量管理计划和过程改进计划。
                      项目文件更新
                      可能需要更新的项目文件包括质量标准、协议、质量审计报告和变更日志(附有纠正行动计划)、培训计划和效果评估、过程文档。
                      组织过程资产更新
                      可能需要更新的组织过程资产包括完成的核对单和经验教训文档。
   题号导航      2011年上半年 信息系统监理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第39题    在手机中做本题