免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2018年下半年 信息系统项目管理师 上午试卷 综合知识
  第10题      
  知识点：   软件设计、测试与维护   单元测试   回归测试   集成测试   确认测试   软件测试   系统测试   用户需求
  关键词：   单元测试   回归测试   集成测试   软件测试   系统测试   需求   测试        章/节：   信息系统及其技术和开发方法       

 
软件测试可分为单元测试、集成测试、确认测试、系统测试、配置测试、回归测试等类别。（）主要用于检测软件的功能、性能、和其他特性是否与用户需求一致。
 
 
  A.  单元测试
 
  B.  集成测试
 
  C.  确认测试
 
  D.  系统测试
 
 
 

 
  第26题    2013年下半年  
   55%
UML是一种标准的建模方法，UML标准并没有定义一种标准的开发过程，它虽然可以支持现有的大部分软件开发过程，但还是比较适用于（..
  第24题    2011年上半年  
   57%
基于各个阶段对信息的需求不同，软件开发工具可分为：计划工具、分析工具、设计工具、集成开发工具等。代码生成器属于（24）。
  第5题    2012年下半年  
   28%
边界值分析是一种常用的黑盒测试法。某程序循环体最少执行0次，最多执行100次，采用边界值分析法，宜选择（5）作为测试用例。
   知识点讲解    
   · 软件设计、测试与维护    · 单元测试    · 回归测试    · 集成测试    · 确认测试    · 软件测试    · 系统测试    · 用户需求
 
       软件设计、测试与维护
        软件设计
        软件设计是“定义一个系统或组件的架构、组件、接口和其他特征的过程”，并得到“这个过程的结果”。
        软件设计由两个处于软件需求和软件构造之间的活动组成：
        .软件架构设计（也叫概要设计）：描述软件的结构和组织，标识各种不同的组件。
        .软件详细设计：详细地描述各个组件，使之能被构造。
        软件测试
        测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。
        软件测试是针对一个程序的行为，在有限测试用例集合上动态验证是否达到预期的行为。
        软件测试过程如下：
        （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）在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
 
       回归测试
        回归测试是一种验证已变更的系统的完整性与正确性的测试技术，是指重新执行已经做过的测试的某个子集，以保证修改没有引入新的错误或者没有发现出于更改而引起之前未发现的错误，也就是保证改变没有带来非预期的副作用。
               回归测试的实施前提
               （1）当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，则可能会遗漏对这些错误的修改。
               （2）开发者对错误理解得不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败。
               （3）修改还有可能产生副作用，导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。
               回归测试与一般测试的比较
               通常从下面5点比较回归测试与一般测试：测试用例的新旧、测试范围、时间分配、完成时间和执行效率。
               （1）测试用例的新旧。一般测试主要依据系统规格说明书和测试计划，测试用例都是新的；而回归测试依据的可能是更改了的规格说明书、修改过的程序和需要更新的测试计划，因此测试用例大部分都是旧的。
               （2）测试范围。一般测试的目标是检测整个程序的正确性；而回归测试的目标是检测被修改的相关部分的正确性。
               （3）时间分配。一般测试所需时间通常在软件开发之前预算；而回归测试所需的时间（尤其是修正性的回归测试）往往不包含在整个产品进度表中。
               （4）完成时间。由于回归测试只需测试程序的一部分，完成所需时间通常比一般测试所需时间少。
               （5）执行效率。回归测试在一个系统的生命周期内往往要多次进行，一旦系统经过修改就需要进行回归测试。
 
       集成测试
        集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
        . 组装时需要考虑的问题。
        ①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
        ②一个模块的功能是否会对另一个模块的功能产生不利的影响；
        ③各个子功能组合起来，能否达到预期要求的父功能；
        ④全局数据结构是否有问题；
        ⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。
        因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
        子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
        选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。
        . 模块组装成为系统的方式。
        模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。
        ①一次性组装方式（big bang）。
        它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。
        
        一次性组装方式
        在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。
        ②增殖式组装方式。
        这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
        . 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。
        
        自顶向下的增殖方式
        自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。
        . 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。
        以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。
        
        一次性组装方式
        
        自底向上的增殖方式
        . 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。
        自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
        自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。
        在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：
        . 满足某些软件需求；
        . 在程序的模块结构中位于较高的层次（高层控制模块）；
        . 较复杂、较易发生错误；
        . 有明确定义的性能要求。
        在做回归测试时，也应该集中测试关键模块的功能。
        . 集成测试的组织和实施。
        集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：
        ①采用何种系统组装方法来进行集成测试。
        ②集成测试过程中连接各个模块的顺序。
        ③模块代码编制和测试进度是否与集成测试的顺序一致。
        ④测试过程中是否需要专门的硬件设备。
        解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
        在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。
        . 集成测试完成的标志。
        集成测试完成的标志主要有以下几项。
        ①成功地执行了测试计划中规定的所有集成测试。
        ②修正了所发现的错误。
        ③测试结果通过了专门小组的评审。
        集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
        在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。
        集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
 
       确认测试
        经过组装测试之后，软件就被集成起来，接口方面的问题已被排除，就可以进入软件测试的最后一个环节——确认测试。确认测试的任务是进一步验证软件的有效性，也就是说，检查软件的功能和性能是否与用户的要求一样。系统分析说明书描述了用户对软件的要求，所以是软件有效性验证的标准，也是确认测试的基础。
        确认测试的步骤如下图所示。首先要进行有效性测试以及软件配置审查，然后进行验收测试和安装测试，经过管理部门的认可和专家的鉴定后，软件即可交给用户使用。
        
        确认测试的步骤
        （1）有效性测试。
        有效性测试就是在模拟环境下，通过黑盒测试检验所开发的软件是否与需求规格说明书一致。为此，需要制定测试计划，规定要做的测试类型，设计测试用例，组织测试人员对已集成的软件进行测试。在设计测试用例时，除了检测软件的功能和性能之外，还需要对软件的容错性、维护性等其他方面进行检测。测试人员可由开发商的内部人员组成，但最好是没有参加该项目的有经验的软件设计人员。在所有测试用例完成之后，测试结果有两种情况：
        .功能和性能等都满足需求，可以接受。
        .发现测试结果与预期的不符，这时要列出缺陷清单。在这个阶段才发现的严重错误一般很难在预定的时间内纠正，需要与用户协商，寻找妥善解决问题的办法。
        （2）软件配置审查。
        确认测试的另一个环节是软件配置的审查，主要是检查软件（源程序、目标程序）和文档（包括面向开发和用户）是否齐全以及分类是否有序。确保文档、资料的正确和完善，以便维护阶段使用。
        （3）验收测试。
        在经过软件的有效性测试和软件配置复查后，就应该开始软件系统的验收测试。验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。在验收测试之前，需要对用户进行培训，以便熟悉该系统。验收测试的测试用例由用户参与设计，主要验证软件的功能、性能、可移植性、兼容性、容错性等，测试时一般采用实际数据。
 
       软件测试
        测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。
        软件测试是针对一个程序的行为，在有限测试用例集合上动态验证软件是否达到预期的行为。
        软件测试过程如下：
        （1）拟定测试计划。
        （2）编制测试大纲。
        （3）设计和生成测试用例。
        （4）实施测试。
        （5）生成测试报告。
        软件测试方法：
        .人工测试：采用人工方式进行测试，目的是通过对程序静态结构的检查，找出编译时不能发现的错误。人工测试包括个人复查、抽查和会审等。
        .机器测试：把设计好的测试用例作用于被测程序，比较测试结果和预期结果是否一致。机器测试包括黑盒测试（功能测试）和白盒测试（结构测试）。
        软件测试伴随软件开发和维护过程，通常可以在概念上划分为以下三个阶段：
        .单元测试：也称为模块测试，在模块编写完成且无编译错误后就可以进行。
        .集成测试：也称为组装测试，就是把模块按系统设计说明书的要求组合起来进行测试。
        .系统测试：是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种组装和确认测试。其目的是通过与系统需求相比较，发现所开发的系统与用户需求不符合的地方。
 
       系统测试
        系统测试将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来，以需求规格说明为依据，在实际运行环境下进行测试。系统测试过程分为计划与准备、执行、返工与回归测试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）检查所有的安全计划。安全性是确保应用程序服务只对有权使用系统的用户可用，还意味着使得应用程序使用的所有分布式组件和资源受到保护。
               文档测试
               文档测试是指对软件开发、测试和维护过程中产生的所有文档的测试，包括对需求规格分析说明书、详细设计报告、系统设计报告、用户手册以及与系统相关的一切文档的审阅和评测。例如，系统需求分析和系统设计说明书中的错误将直接导致编码的错误，用户手册作为软件的一部分，将直接影响用户对系统的使用效果。
               文档测试强调文档的表述应该清楚、准确，主要包含：
               .正确地按照文档描述的方法使用系统。
               .测试每一个提示和建议信息。
               .使用文档作为测试用例的来源。
               .测试每一个在线帮助的超链接。
               .测试每条语句。
               .测试文档中提供的每一个样例。
               .把缺陷写入缺陷跟踪库。
               .检查所有的错误信息。
 
       用户需求
        收集用户需求是要找出用户需要的重要服务和功能。收集用户需求的机制主要包括与用户群的交流、用户服务和需求归档3个方面。
        收集用户需求最常用的方式有观察和问卷调查、集中访谈、采访关键人物。在整个设计和实施阶段，应始终保持与关键人员之间的交流，以确保网络工程建设不偏离用户需求。
        用户服务表用于表示收集和归档的需求信息，也用来指导管理人员和网络用户进行讨论。
   题号导航      2018年下半年 信息系统项目管理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第10题    在手机中做本题