免费智能真题库 > 历年试卷 > 信息系统管理工程师 > 2014年上半年 信息系统管理工程师 下午试卷 案例
  第1题      
  知识点：   系统测试   开发过程   可靠性   逻辑覆盖   逻辑覆盖法   软件测试   网络测试   硬件

 
（15分）
阅读以下有关信息系统开发方面的叙述，回答问题1至问题3,将答案填入答题纸的对应栏内。
【说明】
信息系统测试是信息系统开发过程中的一个非常重要的环节，主要包括软件测试、硬件测试和网络测试三个部分，它是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析、系统设计与实施的最后审查。
在软件测试中，逻辑覆盖法可分为语句覆盖、判定覆盖、路径覆盖等方法。其中：语句覆盖的含义是设计若干个测试用例，使得程序中的每条语句至少执行一次；判定定覆盖也称为分支覆盖，其含义是设计若干个测试用例，使得程序中的每个判断的取真分支和取假分支至少执行一次路径覆盖的含义是设计足够多的测试用例，使被测程序中的 所有可能路径至少执行一次。
 
问题：1.1   一个规范化的测试过程如图1-1所示。请将图1-1所示的测试过程中的（1）~（3）处的内容填入答题纸上对应位置。
 
问题：1.2   信息系统测试应包括软件测试、硬件测试和网络测试三个部分，请简要描述这三个部分需要做的工作。
 
问题：1.3   程序M流程如图1-2所示，假设设计的测试用例及覆盖路径如下：
①输入数据的数据A=3，B=0，X=3（覆盖路径acd）
②输入数据的数据A=2，B=0，X=6（覆盖路径ace）
③输入数据的数据A=2，B=l，X=6（覆盖路径abe）
④输入数据的数据A=l，B=l，X=1（覆盖路径abd）
（1）采用语句覆盖法应选用（a），判定覆盖法应选用（b）路，路径覆盖法应选用（c）测试用例。
（2）就图1-2所示的程序M流程简要说明语句覆盖和判定覆盖会存在什么问题。
 
 
 

   知识点讲解    
   · 系统测试    · 开发过程    · 可靠性    · 逻辑覆盖    · 逻辑覆盖法    · 软件测试    · 网络测试    · 硬件
 
       系统测试
        系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方。系统测试是根据系统分析说明书来设计测试用例的，常见的系统测试主要有以下内容：
        （1）恢复测试（Recovery Testing）。
        恢复测试将检测系统的容错能力。检测方法是采用各种方法让系统出现故障，检验系统是否能按照要求从故障中恢复过来，并在预定的时间内开始处理事务，而且不对系统造成任何损害。如果系统的恢复是自动的（由系统自动完成），则需要验证重新初始化、检查点、数据恢复等是否正确。如果恢复需要人工干预，就要对恢复的平均时间进行评估并判断它是否在允许的范围内。
        （2）安全性测试（Security Testing）。
        系统的安全性测试用于检测系统的安全机制、保密措施是否完善且没有漏洞。主要是为了验证系统的防范能力。测试的方法是测试人员模拟非法入侵者，采用各种方法冲破防线。例如，以系统的输入作为突破口，利用输入的容错性进行正面攻击；故意使系统出错，利用系统恢复的过程，窃取密码或其他有用的信息；想方设法截取或破译密码；利用浏览非保密数据，获取所需信息，等等。从理论上说，只要时间和资源允许，没有进入不了的系统。所以，系统安全性设计准则是使非法入侵者所花费的代价比进入系统后所得到的好处要大，此时非法入侵已无利可图。
        （3）强度测试（Stress Testing）。
        强度测试是对系统在异常情况下的承受能力的测试，是检查系统在极限状态下运行的情况下，性能下降的幅度是否在被允许的范围内。因此，强度测试要求系统在非正常数量、频率或容量的情况下运行，例如，运行使系统处理超过设计能力的最大允许值的测试用例；设计测试用例使系统传输超过设计最大能力的数据，包括内存的写入和读出，外部设备等；对磁盘保留的数据，设计产生过度搜索的测试用例；等等。强度测试主要是为了发现，在有效的输入数据中可能引起的不稳定或不正确的数据组合。
        （4）性能测试（Performance Test）。
        性能测试用于检查系统是否满足系统分析说明书对性能的要求。特别是实时系统或嵌入式系统，即使软件的功能满足需求，但性能达不到要求也是不行的。性能测试覆盖了软件测试的各阶段，而不是等到系统的各部分所有都组装之后，才确定系统的真正性能。通常与强度测试结合起来进行，并同时对软件、硬件进行测试。软件方面主要从响应时间、处理速度、吞吐量、处理精度等方面来检测。
        （5）可靠性测试（Reliability Testing）。
        对于系统分析说明书中提出了可靠性要求时，要对系统的可靠性进行测试。通常使用以下几个指标来衡量系统的可靠性：
        .平均失效间隔时间（Mean Time Between Failures MTBF）是否超过了规定的时限。
        .因故障而停机时间（Mean Time To Repairs MTTR）在一年中应不超过多少时间。
        （6）安装测试（Installation Testing）。
        在安装软件系统时，会有多种选择。安装测试就是为了检测在安装过程中是否有误、是否易操作等。主要检测：系统的每一个部分是否齐全；硬件的配置是否合理；安装中需要产生的文件和数据库是否已产生，其内容是否正确等。
        最后再强调一下，信息系统的开发过程通常为系统分析、设计、编码实现等阶段。而每个阶段都有可能出现错误，测试过程正好与开发过程相反，其开发和测试的关系如下图所示，单元测试主要是发现编码阶段的错误。组装测试主要用于发现设计阶段产生的错误，如果在确认测试中发现系统分析有错误，这就需要重新修改系统分析、设计和编码。这说明越早犯的错误要到最后才能被发现，因此要重视开发的前期工作。
        
        测试与开发的各阶段的关系
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。
        ：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。
        最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。
 
       可靠性
        （1）完备性。完备性评价指标及测量，如下表所示。
        
        完备性评价指标及测量
        （2）连续性。连续性评价指标及测量，如下表所示。
        
        连续性评价指标及测量
        
        （3）稳定性。稳定性评价指标及测量，如下表所示。
        
        稳定性评价指标及测量
        （4）有效性。有效性评价指标及测量，如下表所示。
        
        有效性评价指标及测量
        （5）可追溯性。可追溯性评价指标及测量，如下表所示。
        
        可追溯性评价指标及测量
        
 
       逻辑覆盖
        逻辑覆盖考察用测试数据运行被测程序时对程序逻辑的覆盖程度。主要的逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、判定／条件覆盖、条件组合覆盖和路径覆盖6种。
        （1）语句覆盖。语句覆盖是指选择足够的测试数据，使被测试程序中每条语句至少执行一次。语句覆盖对程序执行逻辑的覆盖很低，因此一般认为它是很弱的逻辑覆盖。
        （2）判定覆盖。判定覆盖是指设计足够的测试用例，使得被测程序中每个判定表达式至少获得一次“真”值和“假”值，即程序中的每一个取“真”分支和取“假”分支至少都通过一次，因此判定覆盖也称为分支覆盖。判定覆盖要比语句覆盖更强一些。
        （3）条件覆盖。条件覆盖是指构造一组测试用例，使得每一判定语句中每个逻辑条件的各种可能的值至少满足一次。
        （4）判定／条件覆盖。判定／条件覆盖是指设计足够的测试用例，使得判定中每个条件的所有可能取值（真／假）至少出现一次，并使每个判定本身的判定结果（真／假）也至少出现一次。
        （5）条件组合覆盖。条件组合覆盖是指设计足够的测试用例，使得每个判定中条件的各种可能值的组合都至少出现一次。满足条件组合覆盖的测试用例是一定满足判定覆盖、条件覆盖和判定／条件覆盖的。
        （6）路径覆盖。路径覆盖是指覆盖被测试程序中所有可能的路径。
 
       逻辑覆盖法
        白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：
        . 保证一个模块中的所有独立路径至少被使用一次；
        . 对所有逻辑值均需测试true和false；
        . 在上下边界及可操作范围内运行所有循环；
        . 检查内部数据结构以确保其有效性。
        但是对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。而且即使精确地实现了白盒测试，也不能断言测试过的程序完全正确。如下图所示的穷举测试流程图，其中包括了一个执行达20次的循环，它所包含的不同执行路径数高达520条，假使有这么一个测试程序，对每一条路径进行测试需要1ms，假设一天工作24小时，一年工作365天，若要对它进行穷举测试，也需要3024年的时间。
        
        穷举测试
        以上的情况说明，实现穷举测试的工作量过大，需要的时间过长，实施起来是不现实的。任何软件开发项目都要受到期限、费用、人力和机时等条件的限制，尽管我们以为为了充分揭露程序中的所有隐藏错误，彻底的做法是针对所有可能的数据进行测试，但事实告诉人们，这样做是不可能的。
        在测试阶段既然穷举测试不可行，为了节省时间和资源，提高测试效率，就必须精心设计测试用例，也就是从数量巨大的可用测试用例中精心挑选少量的测试数据，使得采用这些测试数据就能够达到最佳的测试效果。
        本节和下节将介绍几种实用的白盒测试用例设计方法：逻辑覆盖法和基本路径测试法。
        逻辑覆盖是通过对程序逻辑结构的遍历实现程序的覆盖。它是一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖（SC）、判定覆盖（DC）、条件覆盖（CC）、条件判定组合覆盖（CDC）、多条件覆盖（MCC）和修正判定条件覆盖（MCDC）。
        为便于理解，我们使用如下所示的程序（用C语言书写），如下图所示的是其流程图。
        ［程序］：
        
        
        参考例子流程图
               语句覆盖（SC）
               为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此，语句覆盖（Statement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。
               为了使上述程序中的每条语句都能够至少执行一次，我们可以构造以下测试用例即可实现：
               a=T, b=T, c=T。
               从程序中的每条语句都得到执行这一点看，语句覆盖的方法似乎能够比较全面地检验每一条语句，但是语句覆盖对程序执行逻辑的覆盖很低，这是其最严重的缺陷。
               假如，这一程序段中判定的逻辑运算有问题，例如，判定的第一个运算符“&&”错写成运算符“||”，或第二个运算符“||”错写成运算符“&&”，这时使用上述的测试用例仍然可以达到100%的语句覆盖，上述的逻辑错误无法发现。
               因此一般认为语句覆盖是很弱的逻辑覆盖。
               判定覆盖（DC）
               比语句覆盖稍强的覆盖标准是判定覆盖（Decision Coverage）。判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。
               除了双值的判定语句外，还有多值判定语句，如case语句，因此判定覆盖更一般的含义是：使得每一个判定获得每一种可能的结果至少一次。
               以上述代码为例，构造以下测试用例即可实现判定覆盖标准：
               . a=T, b=T, c=T。
               . a=F, b=F, c=F。
               应该注意到，上述两组测试用例不仅满足了判定覆盖，而且满足了语句覆盖，从这一点看，判定覆盖要比语句覆盖更强一些。但是同样地，假如这一程序段中判定的逻辑运算有问题，如下表所示，判定的第一个运算符“&&”错写成运算符“||”或第二个运算符“||”错写成运算符“&&”，这时使用上述的测试用例可以达到100%的判定覆盖，仍然无法发现上述的逻辑错误。因此需要更强的逻辑覆盖标准。
               
               判定覆盖
               条件覆盖（CC）
               在设计程序中，一个判定语句是由多个条件组合而成的复合判定，在如上图所示参考例子流程图的程序中，判定（a）AND（b OR c）包含了三个条件：a, b和c。为了更彻底地实现逻辑覆盖，可以采用条件覆盖（Condition Coverage）的标准。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
               按照这一定义，上述例子要达到100%的条件覆盖，可以使用以下测试用例：
               . a=F, b=T, c=F。
               . a=T, b=F, c=T。
               仔细分析可以发现，上述用例在满足条件覆盖的同时，把判定的两个分支也覆盖了，这样是否可以说，达到了条件覆盖也就必然实现了判定覆盖呢？
               假如选用以下的两组测试用例：
               . a=F, b=T, c=T。
               . a=T, b=F, c=F。
               我们会发现覆盖了条件的测试用例并没有覆盖分支，如下表所示。为解决这一矛盾，需要对条件和分支兼顾。
               
               条件覆盖
               条件判定组合覆盖（CDC）
               条件判定组合覆盖的含义是：设计足够的测试用例，使得判定中每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。
               对于如上图所示的例子，选用以下的两组测试用例可以符合条件判定组合覆盖标准：
               . a=T, b=T, c=T。
               . a=F, b=F, c=F。
               但是条件判定组合覆盖也存在一定的缺陷，例如，判定的第一个运算符“&&”错写成运算符“||”或第二个运算符“||”错写成运算符“&&”，如下表所示，这时使用上述的测试用例仍然可以达到100%的条件判定组合覆盖，上述的逻辑错误无法发现。
               
               条件判定组合覆盖
               多条件覆盖（MCC）
               多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
               对于如下图所示的例子，判定语句中有三个逻辑条件，每个逻辑条件有两种可能取值，因此共有23=8种可能组合，如下表所示的测试用例保证了多条件覆盖。
               
               计算最少测试用例数实例
               
               多条件覆盖
               由上可知，当一个程序中判定语句较多时，其条件取值的组合数目是非常大的。
               修正条件判定覆盖（MCDC）
               修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的bool条件，每个条件对于判定的结果值是独立的。
               对于如下图所示的例子，可以设计如下表中的8个用例，在此基础上，按照MCDC的要求选择需要的用例。
               
               参考例子流程图
               
               修正条件判定覆盖
               从表中我们可以看出，布尔变量a可以通过用例1和5达到MCDC的要求（用例2和6或用例3和7也可以满足相应要求），变量b可以通过用例2和4达到MCDC的要求，变量c可以通过用例3和4达到MCDC的要求，因此使用用例集｛1，2，3，4，5｝即可满足MCDC的要求。显而易见，这不是惟一的用例组合。
 
       软件测试
        测试是为评价和改进产品质量、识别产品的缺陷和问题而进行的活动。
        软件测试是针对一个程序的行为，在有限测试用例集合上动态验证软件是否达到预期的行为。
        软件测试过程如下：
        （1）拟定测试计划。
        （2）编制测试大纲。
        （3）设计和生成测试用例。
        （4）实施测试。
        （5）生成测试报告。
        软件测试方法：
        .人工测试：采用人工方式进行测试，目的是通过对程序静态结构的检查，找出编译时不能发现的错误。人工测试包括个人复查、抽查和会审等。
        .机器测试：把设计好的测试用例作用于被测程序，比较测试结果和预期结果是否一致。机器测试包括黑盒测试（功能测试）和白盒测试（结构测试）。
        软件测试伴随软件开发和维护过程，通常可以在概念上划分为以下三个阶段：
        .单元测试：也称为模块测试，在模块编写完成且无编译错误后就可以进行。
        .集成测试：也称为组装测试，就是把模块按系统设计说明书的要求组合起来进行测试。
        .系统测试：是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种组装和确认测试。其目的是通过与系统需求相比较，发现所开发的系统与用户需求不符合的地方。
 
       网络测试
        网络测试是对网络设备、网络系统以及网络对应用的支持进行检测，以展示和证明网络系统能否满足用户在性能、安全性、易用性、可管理性等方面需求的测试。网络测试的实施一般包括以下环节。
        ◆根据测试目的，确定测试目标。
        ◆在对相关网络技术和实现细节透彻掌握的基础上，设计测试方案。
        ◆建立网络负载模型。
        ◆配置测试环境，包括测试工具的选择及必要的测试工具的研发。
        ◆采集和整理数据。
        ◆分析和解释数据。
        ◆准确、直观、形象地表示测试结果。
        网络测试包括网络设备测试、网络系统测试和网络应用测试3个层次。
        1）网络设备测试
        网络设备测试主要包括以下几个方面：功能测试、可靠性和稳定性测试、一致性测试、互操作性测试和性能测试等。
        （1）功能测试用来验证产品是否具有设计的每一项功能。
        （2）可靠性和稳定性测试往往通过加重负载的办法来分析和评估系统的可靠性和稳定性。
        （3）一致性测试用来验证产品的各项功能是否符合标准。
        （4）互操作性测试用来考查一个网络产品是否能在不同厂家的多种网络产品互联的网络环境中很好地工作。网络产品不同于其他产品的最大特点是必须符合标准，不同的网络产品之间要能互操作。
        （5）性能测试的主要目标是分析产品在各种不同的配置和负载条件下的容量和对负载的处理能力，如交换机的吞吐量、转发延迟等。
        典型的网络设备性能测试方法有两种：第一种是将设备放在一个仿真的网络环境中进行测试，第二种是使用专用的网络测试设备对产品进行测试。
        2）网络系统测试和网络应用测试
        网络系统测试除了普通意义上的物理连通性、基本功能和一致性的测试以外，主要包括网络系统的规划验证测试、网络系统的性能测试、网络系统的可靠性与可用性的测试与评估、网络流量的测量和模型化等。
        （1）网络系统的规划验证测试主要采用的两个基本手段是模拟和仿真。
        ◆模拟是通过软件的办法，建立网络系统的模型，模拟实际网络的运行。通过设定各种配置和参数模拟系统的行为，对系统的容量、性能以及对应用的支撑程度给出定量的评价。这对于大型网络的规划设计是不可缺少的环节。
        ◆仿真是指通过建立典型的试验环境，仿真实际的网络系统。规划验证测试的目的在于分析所采用的网络技术的可行性和合理性，网络设计方案的合理性，所选网络设备的功能、性能等是否能够合理地、有效地支持网络系统的设计目标。
        （2）网络系统的性能测试是指通过对网络系统的被动测量和主动测量来确定系统中站点的可达性、网络系统的吞吐量、传输速率、带宽利用率、丢包率、服务器和网络设备的响应时间、产生最大网络流量的应用和用户，以及服务质量等。此项工作同时可以发现系统的物理连接和系统配置中的问题，确定网络瓶颈，发现网络问题。测试设备记录一段时间内的网络流量，实时和非实时地分析数据。被动测量不干涉网络的正常工作，不影响网络的性能。主动测量向网络发送特定类型的数据包或网络应用，以便分析系统的行为。
        （3）网络系统的可靠性与可用性的测试与评估。系统可用性取决于系统的可靠性（MTTF）及可维护性（MTTR）的高低，其中可靠性是指系统服务多久不中断，可维护性是指服务中断后多久可恢复。三者之间满足如下关系：
        System Usability=MTTF/(MTTF+MTTR)*100%
        其中，MTTF是指平均无故障时间，MTTR是指平均故障修复时间，MTBF是指平均故障间隔时间。有MTBF=MTTF+MTTR，故
        System Usability=MTTF/MTBR*100%
        （4）网络流量的测量和模型化。网络流量的测量和模型化对于分析网络性能和带宽的利用率、指导网络流量管理、开发高效的网络应用十分重要。这方面的工作主要有以下几个方面。
        ◆产生已知特征的流量，使该流量沿网络传播，最后回到测试仪。记录和分析流量特性的任何改变（如延迟漂移）。
        ◆对链路总体流量的测量和传输时间、吞吐量、带宽利用率等进行分析。
        ◆分析特定流量的特征和提供的QoS；收集一个时间段内的测量数据进行分析，分析流量沿网络传播过程中流量特征的变化和网络流量的统计行为，建立流量模型。
        （5）网络应用层次上的测试则主要体现在测试网络对应用的支持水平，如网络应用的性能和服务质量的测试等。例如，部署基于IP的语音传输VoIP时，最直接的问题是网络中的交换机和路由器设备能否有效地支持语音传输，网络能支持多大的语音流量、多少个语音通道；如果网络支持VoIP，对网络的其他业务特别是关键业务，会产生什么样的影响；网络是否支持服务质量QoS。这些问题都需要通过网络应用测试来回答。
        （6）网络系统测试的核心工具是协议分析仪。这是一种专用的网络测试设备，它能够连接到网络上，产生并向网络发送数据，捕捉网络数据，分析数据。协议分析仪一般具有网络监测、故障查找、协议解码和流量产生等功能。
 
       硬件
        硬件是计算机物理设备的总称，也称为硬件设备，通常是电子的、机械的、磁性的或光的元器件或装置，一般分为中央处理器、存储器和输入、输出设备。
   题号导航      2014年上半年 信息系统管理工程师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
 
第1题    在手机中做本题