免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2014年下半年 信息系统项目管理师 上午试卷 综合知识
  第11题      
  知识点:   软件设计、测试与维护   测试阶段   测试人员   软件测试   软件测试阶段
  关键词:   测试阶段   软件测试   测试        章/节:   信息系统及其技术和开发方法       

 
在软件测试阶段,如果某个测试人员认为程序出现错误,他应()。
 
 
  A.  首先要对错误结果进行确认
 
  B.  立刻修改错误以保证程序的正确运行
 
  C.  重新设计测试用例
 
  D.  撰写错误分析报告
 
 
 

 
  第27题    2013年下半年  
   53%
下图为一个UML序列图的一部分,正确的理解是(27)。

①订单类发消息给客户类
②客户类发消息给订单类
③..
  第10题    2014年下半年  
   41%
软件设计包括软件的结构设计、数据设计、接口设计和过程设计,其中结构设计是指()。
  第10题    2017年上半年  
   46%
()的目的是提供软件产品和过程对于可应用的规则、标准、指南、计划和流程的遵从性的独立评价。
   知识点讲解    
   · 软件设计、测试与维护    · 测试阶段    · 测试人员    · 软件测试    · 软件测试阶段
 
       软件设计、测试与维护
        软件设计
        软件设计是“定义一个系统或组件的架构、组件、接口和其他特征的过程”,并得到“这个过程的结果”。
        软件设计由两个处于软件需求和软件构造之间的活动组成:
        .软件架构设计(也叫概要设计):描述软件的结构和组织,标识各种不同的组件。
        .软件详细设计:详细地描述各个组件,使之能被构造。
        软件测试
        测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。
        软件测试是针对一个程序的行为,在有限测试用例集合上动态验证是否达到预期的行为。
        软件测试过程如下:
        (1)拟定测试计划。
        (2)编制测试大纲。
        (3)设计和生成测试用例。
        (4)实施测试。
        (5)生成测试报告。
        软件测试方法:
        .人工测试:采用人工方式进行测试,目的是通过对程序静态结构的检查,找出编译时不能发现的错误。包括个人复查、抽查、会审。
        .机器测试:把设计好的测试用例作用于被测程序,比较测试结果和预期结果是否一致。包括黑盒测试(功能测试)和白盒测试(结构测试)。
        软件测试的三个阶段:
        .单元测试:也称为模块测试,在模块编写完成且无编译错误后就可以进行。
        .集成测试:也称为组装测试,就是把模块按系统设计说明书的要求组合起来进行测试。
        .系统测试:是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起,进行信息系统的各种组装和确认测试,其目的是通过与系统需求相比较,发现所开发的系统与用户需求不符合矛盾的地方。
        软件维护
        软件维护可定义为需要提供软件支持的全部活动。这些活动包括在交付前完成的活动以及交付后完成的活动。交付前完成的活动包括交付后的运行计划和维护计划等。交付后的活动包括软件修改、培训、帮助资料等。
        软件维护的类型有纠错性维护、适应性维护、完善性维护和预防性维护。
 
       测试阶段
        . 可靠性测试(含于集成测试、系统测试);
        . 排错;
        . 可靠性建模;
        . 可靠性评价;
        . 调整可靠性活动计划;
        . 收集可靠性数据;
        . 明确后续阶段的可靠性活动的详细计划;
        . 编制可靠性文档。
 
       测试人员
               测试人员的选择
               测试人员的能力包括以下几项。
               ①一般能力:包括表达、交流、协调、管理、质量意识、过程方法、软件工程等;
               ②测试技能及方法:包括测试基本概念及方法、测试工具及环境、专业测试标准、工作成绩评估等;
               ③测试规划能力:包括风险分析及防范、软件放行/接收准则制定、测试目标及计划、测试计划和设计的评审方法等;
               ④测试执行能力:包括测试数据/脚本/用例、测试比较及分析、缺陷记录及处理、自动化工具;
               ⑤测试分析、报告和改进能力:包括测试度量、统计技术、测试报告、过程监测及持续改进。
               测试人员的激励
                      X理论+Y理论
                      . X理论:胡萝卜+大棒——迫使人们工作;
                      . Y理论:经理的职能不是督促人们工作,而是使人们有可能工作。
                      需要的层次(Maslow模型)
                      . 生存需要——工作职位、工资奖金、休息时间;
                      . 安全需要——公正待遇、应付工作的能力和信心;
                      . 社会需要——团队归属感,互相认同、理解和支持;
                      . 自尊需要——具有受人尊重/赏识的能力或/和业绩;
                      . 自我实现需要——成为自己期望的人物。
                      人员激励的关键点
                      . 管理者习惯用对自己有效的因素激励测试人员,很可能发现无效;
                      . 过多使用权力、资金或处罚手段很可能导致项目失败;
                      . 行业领先企业采取卓有成效的非货币形式的激励措施;
                      . 在项目进行过程中,而不仅是在项目结束时实施激励措施;
                      . 奖励应该在工作获得认同后尽快兑现;
                      . 对人员的工作表现出真诚的兴趣是对他们最好的奖励;
                      . 激励因素是因人而异、因时而异的。已经满足的需要很可能不再成为激励因素。
                      人员自我激励
                      测试工作的快乐哲学:选择积极的态度,把工作当作游戏,让别人快乐,全身心投入工作。
                      注意测试工作的7条效率原则:主动思考,积极行动;一开始就牢记目标,不迷失方向;重要的事情放在首位(但常常把紧急的事情放在首位);先理解人,后被人理解;寻求双赢;互相合作,追求1+1>2;终生学习,自我更新,不断进步。
               测试职业发展
               国际推荐的软件测试职业发展计划如下。
               . 1~2年,测试技能:熟悉整个测试过程及产品业务领域,学习和掌握自动测试工具,学习测试自动化编程技术;开发和执行测试脚本,承担系统测试实施任务;掌握编程语言、操作系统、网络与数据库方面的技能。
               . 3~4年,测试过程:深入了解测试过程,掌握测试过程设计及改进,参与软件工作产品的同行评审;进一步了解产品业务领域,改进测试自动化编程技术;能指导初级测试工程师;加强编程语言、操作系统、网络与数据库方面的技能。
               . 4~5年,测试组织工作:管理1~3名测试工程师,担任任务估算、管理及进度控制;进一步培养在软件项目管理及支持工具方面的技能。
               . 5~6年,技术管理:管理4~8名测试工程师,提高任务估算、管理及进度控制能力,完成测试规划并制定测试计划;研究测试的技术手段,保持使用项目管理及支持工具的技能;用大量时间为其他测试工程师提供技术及过程方面的指导;开始与客户打交道并做演示推介。
               . 6~12年,测试管理:管理8名以上测试工程师,负责一个或多个项目的测试工作;与客户打交道并做演示推介;保持使用项目管理及支持工具的技能。
               人员的培训
                      软件测试培训内容分类
                      . 测试基础知识和技能培训。
                      . 测试设计培训、测试工具培训。
                      . 测试对象——软件产品培训。
                      . 测试过程培训。
                      . 测试管理培训。
                      制定测试人员培训计划
                      . 是测试计划的一个重要组成部分。
                      . 需要管理层的重视,在时间和资源上予以保证。
                      . 认真调查和分析测试人员的培训需求。
                      . 将培训活动安排在测试任务开始前。
                      . “边干边学”模式很可能牺牲质量和效率。
                      . 软件测试实习活动在整个培训中占较大比例。
                      . 鼓励合作学习,团队演练。
                      . 对培训效果要及时评价,发现不足进行改进。
 
       软件测试
        测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。
        软件测试是针对一个程序的行为,在有限测试用例集合上动态验证软件是否达到预期的行为。
        软件测试过程如下:
        (1)拟定测试计划。
        (2)编制测试大纲。
        (3)设计和生成测试用例。
        (4)实施测试。
        (5)生成测试报告。
        软件测试方法:
        .人工测试:采用人工方式进行测试,目的是通过对程序静态结构的检查,找出编译时不能发现的错误。人工测试包括个人复查、抽查和会审等。
        .机器测试:把设计好的测试用例作用于被测程序,比较测试结果和预期结果是否一致。机器测试包括黑盒测试(功能测试)和白盒测试(结构测试)。
        软件测试伴随软件开发和维护过程,通常可以在概念上划分为以下三个阶段:
        .单元测试:也称为模块测试,在模块编写完成且无编译错误后就可以进行。
        .集成测试:也称为组装测试,就是把模块按系统设计说明书的要求组合起来进行测试。
        .系统测试:是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起,进行信息系统的各种组装和确认测试。其目的是通过与系统需求相比较,发现所开发的系统与用户需求不符合的地方。
 
       软件测试阶段
        按阶段展开测试是一种基本的测试策略,一般可分为单元测试、集成测试、确认测试、系统测试、验收测试这几个阶段,不同的测试阶段将制定不同的测试目标,采用不同的测试方法和技术,具有各自的特点。
               单元测试
               单元测试是通过对每个最小的软件模块进行测试,对源代码的每一个程序单元实行测试,检查各个程序模块是否正确地实现了规定的功能,确保其能正常工作。
               单元测试由开发人员执行,一般由模块单元开发者设计测试用例并修改缺陷。单元测试具有如下三种行为:
               (1)单元测试是一种验证行为。验证程序中的每项功能的正确性为代码的重构提供了保障。
               (2)单元测试是一种设计行为。软件设计阶段考虑如何实现软件的功能、性能和用户界面等,而不考虑实现的代码。单元测试关注于软件的具体功能实现是否符合需求设计,而不仅仅定位于代码的实现。
               (3)单元测试是一种文档的行为。单元测试是函数或类等软件模块如何设计、实现和使用的最佳文档。
                      单元测试的特性
                      单元测试具有如下特性:
                      (1)单入测试是覆盖代码区间的最小单元。
                      (2)单元测试支持组包测试。
                      (3)单元测试的执行率为100%。
                      (4)单元测试确定变动后的代码对原代码的功能未做修改。
                      (5)单元测试提升了软件系统整体的可信赖度。
                      (6)单元测试包含对可能出现问题的代码进行排查。
                      (7)单元测试支持开发人员先测试后编码的行为。
                      (8)单元测试支持变化,任何变化导致的失败情况均会被反映出来。
                      (9)单元测试准确地反映了代码设计,便于后期维护。
                      单元测试的认识误区
                      (1)单元测试是全部规范。单元测试本质上是种特定的测试方式,是系统的实现方法规范的补充,而不是整个规范。
                      (2)单元测试浪费时间。单元测试不会浪费太多的时间,反而会节省项目时间。
                      (3)单元测试只需使用测试工具就可完成。单元测试工具生成的测试用例往往无法对被测试的程序进行有效覆盖,必须进行人工检查。
                      (4)单元测试是针对代码进行的测试。单元测试依据详细设计报告设计测试用例,不仅仅只是对代码的测试。
                      单元测试的原则
                      单元测试需要遵守如下原则。
                      (1)单元测试遵循《软件单元测试计划》和《软件单元测试说明》文档,根据详细设计编写单元测试用例,而不能根据代码编写单元测试用例。
                      (2)单元测试执行前先检查单元测试入口条件是否全部满足。
                      (3)单元测试必须满足一定的覆盖率,重要的接口函数必须做单元测试。
                      (4)单元测试在修改代码后修改测试用例,将全部单元测试用例进行回归测试。
                      (5)单元测试必须满足预定的出口条件才能结束。
                      (6)在单元测试完成后,记录《单元测试报告》,分析问题的种类和原因。
                      (7)单元测试始终在配置管理控制下进行,软件问题的修改必须符合变动规程的要求。
                      (8)单元测试文档、测试用例、测试记录和被测程序等齐全,符合规范。
                      单元测试的主要任务
                      单元测试主要针对程序模块进行测试,主要有5个任务:模块接口、局部数据结构、执行路径、出错处理和边界条件。
                             模块接口测试
                             通过对被测模块的数据流进行测试,检查进出模块的数据是否正确。因此,必须对模块接口,包括参数表、调用子模块的参数、全局变量、文件I/O操作进行测试。具体涉及以下内容:
                             .模块接受输入的实际参数个数与模块的形式参数个数是否一致。
                             .输入的实际参数与模块的形式参数的类型是否匹配。
                             .输入的实际参数与模块的形式参数所使用的单位是否一致。
                             .调用其他模块时,所传送的实际参数个数与被调用模块的形式参数的个数是否相同。
                             .调用其他模块时,所传送的实际参数与被调用模块的形式参数的类型是否匹配。
                             .调用其他模块时,所传送的实际参数与被调用模块的形式参数的单位是否一致。
                             .调用内部函数时,参数的个数、属性和次序是否正确。
                             .在模块有多个入口的情况下,是否引用有与当前入口无关的参数。
                             .是否修改了只读型参数。
                             .全局变量是否在所有引用它们的模块中都有相同的定义。
                             局部数据结构测试
                             测试用例检查局部数据结构的完整性,如数据类型说明、初始化、默认值等方面的问题,并测试全局数据对模块的影响。
                             在模块的工作过程中,必须测试模块内部的数据能否保持完整性,包括内部数据的内容、形式及相互关系不发生错误。
                             局部数据结构应注意以下几类错误:不正确或不一致的类型说明;错误的初始化或默认值;错误的变量名,如拼写错误或书写错误;下溢、上溢或者地址错误。
                             执行路径测试
                             测试用例对模块中重要的执行路径进行测试,其中对基本执行路径和循环进行测试往往可以发现大量的路径错误。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。
                             常见的错误有误解或不正确的算术优先级;混合模式的运算;错误的初始化;精确度不够精确;表达式的不正确符号表示。
                             针对判定和条件覆盖,测试用例能够发现的错误有:不同数据类型的比较;不正确的逻辑操作或优先级;应当相等的地方由于精确度的错误而不能相等;不正确的判定或不正确的变量;不正确的或不存在的循环终止;当遇到分支循环时不能退出;不适当地修改循环变量。
                             出错处理测试
                             测试出错处理的重点是模块在工作中发生了错误,其中的出错处理设施是否有效。
                             检验程序中的出错处理可能面对的情况有以下几种:
                             .对运行发生的错误描述难以理解。
                             .所报告的错误与实际遇到的错误不一致。
                             .出错后,在错误处理之前就引起系统的干预。
                             .例外条件的处理不正确。
                             .提供的错误信息不足,以致无法找到错误的原因。
                             边界条件测试
                             边界条件测试是单元测试的最后一步,必须采用边界值分析方法来设计测试用例。在为限制数据处理而设置的边界处,测试模块是否能够正常工作。
                             一些与边界有关的数据类型,如数值、字符、位置、数量、尺寸等,以及边界的第一个、最后一个、最大值、最小值、最长、最短、最高和最低等特征。
                             在边界条件测试中,应设计测试用例检查一下情况。
                             .在n次循环的第0次、第1次、第n次是否有错误。
                             .运算或判断中取最大值、最小值时是否有错误。
                             .数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误。
                      单元测试的执行过程
                      通常,单元测试在编码阶段进行,在源程序代码编制完成,经过评审和验证,确认没有语法错误之后,开始设计单元测试用例。
                      由于模块并不是一个独立的程序,在考虑测试模块时,同时要考虑与其有关的外界联系,因此使用一些辅助模块去模拟与被测模块相关的其他模块。辅助模块分为以下两种:
                      (1)驱动(Drive)模块。用于模拟被测试模块的上一级模块,相当于被测模块的主程序,用于接收测试数据,并把这些数据传送给被测模块,启动被测模块,最后输出实测结果。
                      (2)桩(Stub)模块。用于模拟被测模块工作过程中所调用的模块。桩模块一般只进行很少的数据处理,不需要把子模块的所有功能都带进来,但不允许什么事情也不做。
                      单元测试停止的条件
                      单元测试停止的条件如下。
                      (1)单元测试用例设计已经通过评审。
                      (2)按照单元测试计划完成了所有规定单元的测试。
                      (3)达到了测试计划中关于单元测试所规定的覆盖率的要求。
                      (4)被测试的单元每千行代码必须发现至少3个错误。
                      (5)软件单元功能与设计相一致。
                      (6)在单元测试中发现的错误已经得到修改,各级缺陷修复率达到标准。
               集成测试
               1999年9月,火星气象人造卫星在经过41周4.16亿英里飞行后,在即将要进入火星轨道时失败了,为此,美国投资5万美元调查事故原因,发现太空科学家洛克希德·马丁采用的是英制(磅)加速度数据,而喷气推进实验室则采用的是公制(牛顿)加速度数据进行计算。如果他们进行了集成测试,事故本来是可以避免的。
               在每个模块完成单元测试之后,需要着重考虑的一个问题是:通过什么方式将模块组合起来进行集成测试,这将影响到模块测试用例的设计、所用测试工具的类型、模块编码的次序、测试的次序以及设计测试用例的费用和纠错的费用等。
               集成测试的主要目的是验证组成软件系统的各模块的接口和交互作用,一般不使用真实数据,可以使用一部分代表性的测试数据。在创建测试数据时,应保证数据能充分测试软件系统的边界条件。
                      集成测试的方法
                      集成测试包括非增量式集成测试和增量式集成测试。
                      非增量式集成测试采用一步到位的方法来进行测试,对所有模块进行个别的单元测试后,按程序结构图将各模块连接起来,把连接后的程序当做一个整体进行测试。
                      增量式集成测试具体包括自顶向下增量式测试和自底向上增量式测试。
                             自顶向下增量式测试
                             自顶向下增量式测试按结构图自上而下进行逐步集成和逐步测试。模块集成的顺序是首先集成主控模块(主程序),然后按照软件控制层次结构向下进行集成。自顶向下的集成方式可以采用深度优先策略和广度优先策略,如下图所示。由图可知,深度优先顺序为T1->T2->T5->T8->T6->T3->T7->T4,广度优先顺序为T1->T2->T3->T4->T5->T6->T7->T8。
                             
                             自顶向下的集成方式
                             该方法由下列步骤实现。
                             ①以主模块为所测试模块兼驱动模块,而所有直属于主模块的下属模块全部用桩模块替换,并对主模块进行测试。
                             ②采用深度优先或广度优先测试方式,用实际模块替换相应桩模块,再用桩代替它们的直接下属模块,从而与已经测试的模块或子系统组装成新的子系统。
                             ③进行回归测试排除组装过程中的错误可能性。
                             ④判断是否所有的模块都已经组装到系统中。如果是,则测试结束,否则,转到②。
                             自顶向下增量式测试方式具有如下优点:
                             .在测试过程中较早地验证主要的控制点。
                             .功能性的模块测试可以较早地得到证实。
                             .最多只需要一个驱动模块就可进行测试。
                             .支持缺陷故障隔离。
                             自顶向下增量式测试方式具有如下缺点:
                             .随着底层模块的不断增加,会导致底层模块的测试不充分,特别是被重用的模块。
                             .由于每次组装都必须提供桩,会使得桩的数目急剧增加,从而维护桩的成本也会快速上升。
                             因此,该方法适合采用结构化方法开发软件的体系结构相对比较简单的软件系统。
                             自底向上增量式测试
                             自底向上增量式测试是从“原子”模块(软件结构中最低层的模块)开始,按结构图自下而上逐步进行集成和测试。
                             该方法的具体实现可由下列几个步骤完成。
                             ①把底层模块组合成实现某个待定的软件子功能的族。
                             ②写一个驱动程序(用于测试的控制程序),协调测试数据的输入和输出。
                             ③对由模块组成的子功能族进行测试。
                             ④去掉驱动程序,沿软件结构由下向上移动,把子功能族组合成更大的功能族。
                             ⑤不断重复②~④,直到完成。
                             自底向上增量式测试方法具有如下优点:
                             .虽然模拟中断或异常需要设计一定的桩模块,但总体上减少了桩模块的工作量。
                             .允许对底层模块行为进行早期验证。
                             .在测试初期,可以并行进行集成,相应地比使用自顶向下的方式效率高。
                             自底向上增量式测试方法具有如下缺点:
                             .随着集成到顶层,整个系统变得越来越复杂,对于底层的一些模块将很难覆盖。
                             .驱动模块的开发工作量很大。
                             下面给出了非增量式集成测试和增量式集成测试的比较结果。
                             (1)非增量式集成测试模式是先分散测试,然后集中起来一次完成集成测试。如果在模块的接口处存在错误,只会在最后的集成测试时一下子暴露出来。在非增量式集成测试时可能发现很多错误,但为每个错误定位和纠正非常困难,并且在改正一个错误的同时又可能会引入新的错误,从而更难断定出错的原因和位置;与此相反,增量式集成测试采用逐步集成和逐步测试的方法,测试的范围逐步增大,从而错误易于定位和纠正。因此,增量式集成测试比非增量式集成测试有比较明显的优越性。
                             (2)自顶向下测试的主要优点是逐步求精,从一开始让测试者了解系统的框架。它的主要缺点是需要提供被调用的模拟子模块,被调用的模拟子模块可能不能反映真实情况,因此测试有可能不充分。
                             (3)自底向上测试的优点在于,由于驱动模块模拟了所有调用参数,从而测试数据没有困难。其主要缺点在于,只有到最后一个模块被加入之后才能知道整个系统的框架。
                             (4)核心系统先行集成测试能保证一些重要功能和服务的实现,对于快速软件开发十分有效。如果采用此种模式的测试,则要求系统应能明确区分核心软件部件和外围软件部件,采用高频集成,借助于自动化工具实现测试。
                             总之,采用自顶向下集成测试和自底向上集成测试的方案较为常见。在实际测试工作中,应该结合项目的实际环境及各种测试方案适用的范围进行合理的选型。
                      集成测试遵循的原则
                      为了做好集成测试,需要遵循以下原则:
                      (1)所有公共接口都要被测试到。
                      (2)关键模块必须进行充分的测试。
                      (3)集成测试应当按一定的层次进行。
                      (4)集成测试的策略选择应当综合考虑质量、成本和进度之间的关系。
                      (5)集成测试应当尽早开始,并以总体设计为基础。
                      (6)在模块与接口的划分上,测试人员应当和开发人员进行充分的沟通。
                      (7)当接口发生修改时,涉及的相关接口必须进行再测试。
                      (8)测试执行结果应当如实记录。
                      集成测试过程中的两个重要的里程碑
                      在集成测试过程中的两个重要的里程稗是功能冻结和代码冻结的确定。这两个里程碑可界定出回归测试期的起止界限。
                      (1)功能冻结。经过测试,符合设计要求,确认系统功能和其他特性均不再做任何改变。
                      (2)代码冻结。理论上,在无错误时冻结程序代码,但实际上,代码冻结只标志系统当前版本的质量已达到预期的要求,冻结程序的源代码,不再对其做任何修改。这个里程碑设置在软件通过最终回归测试之后。
                      集成测试与单元测试的区别
                      集成测试与单元测试的区别如下。
                      (1)测试的单元不同。单元测试是针对软件从基本单元(如函数等)所做的测试;而集成测试则是以模块和子系统为单位进行的测试,主要测试接口间的关系。
                      (2)测试的依据不同。单元测试是针对软件详细设计所做的测试,测试用例主要依据详细设计;而集成测试是针对高层(概要)设计所做的测试,测试用例主要依据概要设计。
                      (3)测试空间不同。集成测试的测试空间与单元测试和系统测试是不同的。集成测试也不关心内部实现层的测试空间,只关注接口层的测试空间,即关注的是接口层可变数据间的组合关系。
                      (4)使用的方法不同。集成测试关注的是接口的集成,和单元测试只关注每个单元不同,因此在具体的测试方法上也不同,集成测试在测试用例设计方面和单元测试有一定的差别。
                      集成测试停止的条件
                      集成测试用例设计已经通过评审。
                      按照集成构建计划及增量集成策略完成了整个系统的集成测试。
                      达到了测试中处于集成测试所规定的覆盖率的要求。
                      被测试的集成工作版本每千行代码必须发现两个错误。
                      集成工作版本满足设计定义的各项功能、性能要求。
                      在集成测试中发现的错误已经得到修改,各级缺陷修复率达到标准。
               确认测试
               确认测试又称为合格性测试,用来检验软件是否符合用户的需求。软件确认一般采用黑盒测试法,通过一系列证明软件功能和要求的测试来实现。
               确认测试需制订测试计划和测试过程。测试计划应规定测试的种类和测试进度,测试过程主要定义一些特殊的测试用例,旨在说明软件与需求是否一致。确认测试着重考虑软件是否满足合同规定的所有功能和性能,文档资料是否完整。确认人机界面和其他方面(如可移植性、兼容性、错误恢复能力和可维护性等)是否令用户满意。
               确认测试的结果只有两种可能,一种是功能和性能指标满足软件需求说明的要求,用户可以接受;反之,功能和性能指标不满足软件需求说明的要求,此时发现的错误一般很难在预定的工期内改正,因此往往需与用户协商,寻求一个妥善的解决办法。
               确认测试过程的重要环节就是配置审查工作。配置审查的文件资料包括用户手册、操作手册和设计资料。其目的在于确保软件的所有文件资料均已编写齐全,用于支持日后软件的维护工作。
               系统测试
               系统测试将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来,以需求规格说明为依据,在实际运行环境下进行测试。系统测试过程分为计划与准备、执行、返工与回归测试3个阶段,系统测试一般要完成功能测试、性能测试、恢复测试、安全测试、强度测试以及其他限制条件的测试。
               系统测试由独立测试小组在测试组长的监督下进行,测试组长主要负责保证在质量控制和监督下使用测试技术执行系统测试。系统测试过程由一个独立的测试观察员来监控测试工作。
                      负载测试
                      负载测试是通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
                      负载测试的加载方式通常有如下几种。
                      (1)一次性加载。一次性加载某个数量的用户,在预定的时间段内持续运行。例如,在早晨上班的时间访问网站或登录网站的时间非常集中,基本属于扁平负载模式。
                      (2)递增加载。有规律地逐渐增加用户,每几秒增加一些新用户,交错上升。借助这种负载方式的测试,容易发现性能的拐点,即性能瓶颈。
                      (3)高低突变加载。某个时间用户数量很大,突然降到很低,过一段时间,又突然加到很高,反复几次。借助这种负载方式的测试,容易发现资源释放和内存泄露等问题。
                      (4)随机加载方式。由随机算法自动生成某个数量范围内变化的、动态的负载,这种方式可能是和实际情况最为接近的一种负载方式。虽然不容易模拟系统运行出现的瞬时高峰期,但可以模拟系统长时间的运行过程的状态。
                      压力测试
                      压力测试又称为强度测试,是在强负载(加大数据量、大量并发用户等)下的测试,用于查看应用系统在峰值使用情况下的操作行为,目的是发现系统的功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
                      微软测试实践经验表明,如果软件产品通过72小时压力测试,则在72小时后出现问题的可能性微乎其微。所以,72小时成为微软产品压力测试的时间标志。
                      负载测试与压力测试是两个很容易混淆的概念。负载测试是通过逐步增加系统负载,测试其变化,看最后在满足性能的情况下,系统最多能接受多大负载的测试。压力测试是在满足性能的情况下,能使系统处于失效的状态,通俗来说,就是发现在什么条件下,系统的性能会变得不可接受。
                      压力测试的一般步骤如下:
                      ①进行简单多任务测试。
                      ②简单压力缺陷修正后,增加系统的压力直到系统崩溃。
                      因此,负载压力测试的主要目的是度量应用系统的性能和扩展性。在实施并发负载过程中,通过实时性能监测来确认和查找问题,并针对所发现的问题对系统性能进行优化。负载压力测试工具能够对整个企业架构进行测试,通过这些测试,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。
                      可靠性测试
                      软件可靠性是软件质量的一个重要标志。美国电气和电子工程师协会(IEEE)将软件可靠性定义为:系统在特定的环境下,在给定的时间内无故障地运行的概率。软件可靠性涉及软件的性能、功能、可用性、可服务性、可安装性,以及可维护性等多方面特性,是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。
                      可靠性测试一般伴随着强壮性测试,是评估软件在运行时的可靠性,通过测试确认平均无故障时间(Mean Time to Failure,MTTF)、故障发生前平均工作时间(Mean-Time-To-First-Failure,MTTFF)或因故障而停机的时间(Mean Time To Repairs,MTTR)在一年中应不超过多少时间。可靠性测试强调随机输入,并通过模拟系统实现,很难通过实际系统的运行来实现。
                      安全性测试
                      安全性测试是测试系统在应付非授权的内部/外部访问、非法侵入或故意的损坏时的系统防护能力,检验系统有能力使可能存在的内/外部的伤害或损害的风险限制在可接受的水平内。可靠性通常包括安全性,但是软件的可靠性不能完全取代软件的安全性。安全性还涉及到数据加密、保密和存取权限等多个方面。
                      安全性测试需要设计一些测试用例试图突破系统的安全保密措施,检验系统是否有安全保密漏洞,验证系统的保护机制是否能够在实际中不受到非法的侵入。在安全测试过程中,测试者扮演成试图攻击系统的角色,尝试获取系统密码,利用能够瓦解任何防守的客户软件攻击系统;或者把系统“制服”,使别人无法访问。
                      安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用,有无漏洞。破坏系统保护机构的主要方法有以下几种:
                      (1)正面攻击或从侧面、背面攻击系统中易受损坏的那些部分。
                      (2)以系统输入为突破口,利用输入的容错性进行正面攻击。
                      (3)申请和占用过多的资源压垮系统,以破坏安全措施,从而进入系统。
                      (4)故意使系统出错,利用系统恢复的过程,窃取用户口令及其他有用的信息。
                      (5)通过浏览残留在计算机各种资源中的垃圾(无用信息),以获取如口令、安全码和译码关键字等信息。
                      (6)浏览全局数据,期望从中找到进入系统的关键字。
                      (7)浏览那些逻辑上不存在,但物理上还存在的各种记录和资料等。
                      一般情况下,网络软件的安全评估包括以下情况;
                      (1)检验和测试网络软件中涉及数据传输各部分的配量对安全的影响。
                      (2)会话跟踪是否足够。
                      (3)是否正确使用了加密技术。
                      (4)变量限制的设定。
                      (5)在服务器端执行程序中的安全漏洞。
                      (6)HTML源码中是否有敏感的信息或没有必须出现的信息。
                      兼容性/配置测试
                      兼容性/配置测试用于测试软件与先前发布过的版本、有依赖关系的外部软件、运行的系统的各种版本和硬件平台的不同配置的兼容情况。
                      可以从如下几个方面进行兼容性测试。
                      (1)检查版本是否兼容。检查新版本操作习惯与老版本是否兼容,目的是使老版本的用户很快地适应新版本的变化。
                      (2)检查数据格式是否兼容。数据格式有许多种形式,如文件格式、网络协议和共享数据等。例如,通信协议软件版本升级后,检查升级版本和老版本的通信协议是否一致等。
                      (3)检查系统调用的兼容性。检查系统的哪些功能依赖于系统调用,是否属于某个平台或版本独有,是否在不同平台上有差异。
                      (4)检查是否支持操作系统、数据库系统、硬件和软件平台。配置测试用例设计主要指软硬件环境配置的测试用例,检查计算机系统内各个设备或各种资源之间的相互关联和功能分配中的错误。
                      容错性测试
                      容错性测试是检查软件在异常条件下自身是否具有防护性措施或者灾难恢复手段。如当系统出错时,能否在指定时间间隔内修正错误并重新启动。可以把容错性测试看作是由系统异常处理测试和恢复测试组成的。
                      可用性测试
                      可用性是指系统正常运行的能力和用户接受的程度,一般用如下公式表示。
                      可用性=平均正常工作时间/(平均正常工作时间+平均修复时间)
                      影响可用性的因素有如下几个:
                      (1)不充分的测试。
                      (2)更改管理问题。
                      (3)缺少在线监视和分析。
                      (4)操作错误。
                      (5)弱编码。
                      (6)与外部服务或应用程序的交互。
                      (7)不同的操作条件(使用级别更改、峰值重载)。
                      (8)异常事件(安全性失败、广播风暴)。
                      (9)硬件故障(硬盘、控制器、网络设备、服务器、电源、内存和CPU)。
                      (10)环境问题(电源、冷却、火、洪水、灰尘、自然灾害)。
                      下面给出提高系统可用性的一些办法。
                      (1)使用集群。集群是指将至少两个系统连接到一起,像一个系统那样工作。当某一系统出现失效时,集群提供即时故障转移服务。
                      (2)使用网络负载平衡。当检测某服务器失败后,网络负载平衡自动将通信量重新分发给仍然运行的服务器。
                      (3)使用服务级别协议。可用性指标的期望服务级别要求达到4个或5个“9”。例如,“该应用程序应每周运行7天,每天24小时,年可用性为99.99%”是指全年不能正常工作的时间仅仅只有52分钟,不足1个小时。
                      (4)提供实时的监视。监视系统的工作负荷和失败数据,实时监视对于发现趋势和改善服务至关重要。
                      (5)使用数据备份,保证数据安全。
                      (6)检查所有的安全计划。安全性是确保应用程序服务只对有权使用系统的用户可用,还意味着使得应用程序使用的所有分布式组件和资源受到保护。
                      文档测试
                      文档测试是指对软件开发、测试和维护过程中产生的所有文档的测试,包括对需求规格分析说明书、详细设计报告、系统设计报告、用户手册以及与系统相关的一切文档的审阅和评测。例如,系统需求分析和系统设计说明书中的错误将直接导致编码的错误,用户手册作为软件的一部分,将直接影响用户对系统的使用效果。
                      文档测试强调文档的表述应该清楚、准确,主要包含:
                      .正确地按照文档描述的方法使用系统。
                      .测试每一个提示和建议信息。
                      .使用文档作为测试用例的来源。
                      .测试每一个在线帮助的超链接。
                      .测试每条语句。
                      .测试文档中提供的每一个样例。
                      .把缺陷写入缺陷跟踪库。
                      .检查所有的错误信息。
               验收测试
               验收测试在测试组的协助下,由用户代表执行。测试人员在验收测试工作中将协助用户代表执行测试,并和测试观察员一起向用户解释测试用例的结果。
                      验收测试的主要任务
                      验收测试完全采用黑盒测试技术,其主要任务是文档资料的审查验收、软件系统的功能测试、性能测试、强化测试、性能降级执行方式测试、检查系统的余量要求、安装测试以及用户操作测试。
                      Alpha测试和Beta测试
                      事实上,开发人员不可能完全预见用户实际使用程序的情况。例如,用户可能错误地理解命令,或提供一些奇怪的数据组合等。因此,软件是否真正满足最终用户的要求,应由用户进行一系列“验收测试”,通常执行Alpha测试(α测试)和Beta测试(β测试),其目的是从实际终端用户的使用角度,对软件的功能和性能进行测试,以便发现可能只有是最终用户才能发现的错误。
                      Alpha测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成,Alpha测试发现的错误,在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其要注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后开始。
                      Beta测试是多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,不由程序员或测试员完成;因而,Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中,一旦遇到问题应向开发者报告,开发者根据用户报告,做出修改后交付给全体用户使用:Beta测试着重于产品的支持性,包括文档、客户培训和支持产品的生产能力;当Alpha测试达到一定的可靠程度后,即可开始Beta测试。
               回归测试
               回归测试是一种验证已变更的系统的完整性与正确性的测试技术,是指重新执行已经做过的测试的某个子集,以保证修改没有引入新的错误或者没有发现出于更改而引起之前未发现的错误,也就是保证改变没有带来非预期的副作用。
                      回归测试的实施前提
                      (1)当软件中所含错误被发现时,如果错误跟踪与管理系统不够完善,则可能会遗漏对这些错误的修改。
                      (2)开发者对错误理解得不够透彻,也可能导致所做的修改只修正了错误的外在表现,而没有修复错误本身,从而造成修改失败。
                      (3)修改还有可能产生副作用,导致软件未被修改的部分产生新的问题,使本来工作正常的功能产生错误。
                      回归测试与一般测试的比较
                      通常从下面5点比较回归测试与一般测试:测试用例的新旧、测试范围、时间分配、完成时间和执行效率。
                      (1)测试用例的新旧。一般测试主要依据系统规格说明书和测试计划,测试用例都是新的;而回归测试依据的可能是更改了的规格说明书、修改过的程序和需要更新的测试计划,因此测试用例大部分都是旧的。
                      (2)测试范围。一般测试的目标是检测整个程序的正确性;而回归测试的目标是检测被修改的相关部分的正确性。
                      (3)时间分配。一般测试所需时间通常在软件开发之前预算;而回归测试所需的时间(尤其是修正性的回归测试)往往不包含在整个产品进度表中。
                      (4)完成时间。由于回归测试只需测试程序的一部分,完成所需时间通常比一般测试所需时间少。
                      (5)执行效率。回归测试在一个系统的生命周期内往往要多次进行,一旦系统经过修改就需要进行回归测试。
   题号导航      2014年下半年 信息系统项目管理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第11题    在手机中做本题