免费智能真题库 > 历年试卷 > 信息系统监理师 > 2009年上半年 信息系统监理师 上午试卷 综合知识
  第30题      
  知识点：   测试的类型   动态测试   静态测试   软件测试   白盒测试   测试方法   黑盒测试
  关键词：   白盒测试   测试方法   动态测试   对象   黑盒测试   接口   静态测试   软件测试   条件覆盖   用例   语句覆盖   白盒   测试   黑盒        章/节：   软件与软件工程知识       

 
以下关于软件测试的说法正确的包括（30)。
①代码走査是静态测试方法，白盒测试是动态测试方法
②黑盒测试的对象是程序逻辑结构，白盒测试的对象是程序接口
③无论黑盒测试，还是白盒测试，都无法用穷举法设计全部用例
④对发现错误较多的程序段，应进行更深入的测试。因为发现错误数多的程序段， 其质量较差，同时在修改错误过程中又容易引入新的错误
⑤测试覆盖标准从发现错误的强弱能力依次是路径覆盖、条件组合覆盖、判定覆盖、条件覆盖、语句覆盖
⑤测试覆盖标准从发现错误的强弱能力依次是路径覆盖、条件组合覆盖、判定覆盖、条件覆盖、语句覆盖
 
 
  A.  ①③④
 
  B.  ①②③
 
  C.  ③④⑤
 
  D.  ②③④
 
 
 

 
  第30题    2013年上半年  
   55%
集成测试的测试用例应根据(30)的结果来设计。
  第15题    2014年上半年  
   48%
为了确认网络性能能够满足多媒体应用的需要，需要通过必要的网络测试工具对网络的性能进行测试，以下属于网络测试工具的是（）。..
  第12题    2009年上半年  
   51%
通过测试，得到单个网络组件的最大吞吐量，并计算其与网络系统最大可支持吞吐量之间的差额以达到定位系统最小负载及组件余量的测..
   知识点讲解    
   · 测试的类型    · 动态测试    · 静态测试    · 软件测试    · 白盒测试    · 测试方法    · 黑盒测试
 
       测试的类型
        软件测试方法一般分为两大类：动态测试和静态测试。
               动态测试
               动态测试是指通过运行程序发现错误，分为黑盒测试法、白盒测试法和灰盒测试法等。
                      黑盒法
                      把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书检查程序是否满足功能要求。因此，黑盒测试又称为功能测试或数据驱动测试，使用这种方法，为了做到穷尽测试，至少必须对所有输入数据的各种可能值的排列组合都进行测试。黑盒测试使用所有有效和无效的输入数据来测试程序是不现实的，所以黑盒测试同样不能做到穷尽测试，只能选取少量最有代表性的输入数据，以期用较少的代价暴露出较多的程序错误。常用的黑盒测试用例的设计方法有等价类划分、边界值分析、错误猜测和因果图等。
                      .等价类划分：把程序的输入域划分成若干部分，然后从每个部分中选取少数有代表性的数据作为测试用例，每一类代表性数据在测试中的作用等价于这一类中的其他值。
                      .边界值分析：这是一种补充等价类划分的测试用例设计技术，它不选择等价类的任意元素，而选择等价类边界的测试用例。实践证明，为检验边界附近的处理而专门设计测试用例，常常可以取得良好的测试效果。
                      .错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。基本思想是列举出程序中所有可能的错误和容易发生错误的特殊情况，再根据它们选择测试用例。
                      .因果图法：该方法从自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。
                      白盒法
                      把测试对象看做是一个打开的盒子，测试人员需了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。由于白盒测试是结构测试，因此被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。常用的白盒测试用例设计方法有基本路径测试、循环覆盖测试及逻辑覆盖测试等。
                      .逻辑覆盖：以程序内部逻辑为基础的测试技术，常用的有语句覆盖、判定覆盖、条件覆盖、判定／条件覆盖、条件组合覆盖、点覆盖、边覆盖和路径覆盖等。
                      .循环覆盖：单循环及嵌套循环。
                      .基本路径：在程序控制流程图的基础上，通过分析控制结构的环路复杂性导出基本路径集合，然后设计测试用例，保证这些路径都至少通过一次。
                      灰盒法
                      灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。
                      灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境，在系统组件的协同性环境中评价应用软件的设计。
               静态测试
               静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态分析中进行人工测试的主要方法有桌前检查（Desk Checking）、代码审查和代码走查。经验表明，使用这种方法能够有效地发现30%～70%的逻辑设计和编码错误。
                      桌前检查
                      由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。检查项目如下所述。
                      .检查变量的交叉引用表。重点是检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐个检查变量的引用、变量的使用序列，临时变量在某条路径上的重写情况，局部变量、全局变量与特权变量的使用等。
                      .检查标号的交叉引用表。验证所有标号的正确性；检查所有标号的命名是否正确，以及转向指定位置的标号是否正确。
                      .检查子程序、宏、函数。验证每次调用与被调用位置是否正确；确认每次被调用的子程序、宏和函数是否存在；检验调用序列中调用方式与参数顺序、个数和类型上的一致性。
                      .等值性检查。检查全部等价变量的类型的一致性，解释所包含的类型差异。
                      .常量检查。确认每个常量的取值和数制、数据类型；检查常量每次引用同它的取值、数制和类型的一致性。
                      .标准检查。用标准检查程序或手工检查程序中违反标准的问题。
                      .风格检查。检查在程序设计风格方面发现的问题。
                      .比较控制流。比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档并校正错误。
                      .选择、激活路径。在程序员设计的控制流图中选择路径，再到实际的控制流图中激活这条路径。如果选择的路径在实际控制流图中不能激活，则源程序可能有错。用这种方法激活的路径集合应保证源程序模块的每行代码都被检查，即桌前检查应至少是语句覆盖的。
                      .对照程序的规格说明，详细阅读源代码。程序员对照程序的规格说明书、规定的算法和程序设计语言的语法规则，仔细地阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，并从它们的差异中发现程序的问题和错误。
                      .补充文档。桌前检查的文档是一种过渡性的文档，不是公开的正式文档。通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。
                      由于程序员熟悉自己的程序和自身的程序设计风格，这种桌前检查可以节省很多的检查时间，但应避免主观片面性。
                      代码审查
                      代码审查是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。
                      第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
                      第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。
                      在会前，应当给会审小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。这种检查表类似于本章单元测试中给出的检查表。
                      代码走查
                      代码走查与代码审查基本相同，其过程也分为两步。
                      第一步，把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。
                      第二步，开会的程序与代码会审不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论使用。
                      值得说明的是，使用静态测试的方法也可以实现白盒测试。例如，使用人工检查代码的方法来检查代码的逻辑问题也属于白盒测试的范畴。
 
       动态测试
        动态测试是指通过运行程序发现错误，分为黑盒测试法、白盒测试法和灰盒测试法等。
               黑盒法
               把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书检查程序是否满足功能要求。因此，黑盒测试又称为功能测试或数据驱动测试，使用这种方法，为了做到穷尽测试，至少必须对所有输入数据的各种可能值的排列组合都进行测试。黑盒测试使用所有有效和无效的输入数据来测试程序是不现实的，所以黑盒测试同样不能做到穷尽测试，只能选取少量最有代表性的输入数据，以期用较少的代价暴露出较多的程序错误。常用的黑盒测试用例的设计方法有等价类划分、边界值分析、错误猜测和因果图等。
               .等价类划分：把程序的输入域划分成若干部分，然后从每个部分中选取少数有代表性的数据作为测试用例，每一类代表性数据在测试中的作用等价于这一类中的其他值。
               .边界值分析：这是一种补充等价类划分的测试用例设计技术，它不选择等价类的任意元素，而选择等价类边界的测试用例。实践证明，为检验边界附近的处理而专门设计测试用例，常常可以取得良好的测试效果。
               .错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。基本思想是列举出程序中所有可能的错误和容易发生错误的特殊情况，再根据它们选择测试用例。
               .因果图法：该方法从自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。
               白盒法
               把测试对象看做是一个打开的盒子，测试人员需了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。由于白盒测试是结构测试，因此被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。常用的白盒测试用例设计方法有基本路径测试、循环覆盖测试及逻辑覆盖测试等。
               .逻辑覆盖：以程序内部逻辑为基础的测试技术，常用的有语句覆盖、判定覆盖、条件覆盖、判定／条件覆盖、条件组合覆盖、点覆盖、边覆盖和路径覆盖等。
               .循环覆盖：单循环及嵌套循环。
               .基本路径：在程序控制流程图的基础上，通过分析控制结构的环路复杂性导出基本路径集合，然后设计测试用例，保证这些路径都至少通过一次。
               灰盒法
               灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。
               灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境，在系统组件的协同性环境中评价应用软件的设计。
 
       静态测试
        静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态分析中进行人工测试的主要方法有桌前检查（Desk Checking）、代码审查和代码走查。经验表明，使用这种方法能够有效地发现30%～70%的逻辑设计和编码错误。
               桌前检查
               由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。检查项目如下所述。
               .检查变量的交叉引用表。重点是检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐个检查变量的引用、变量的使用序列，临时变量在某条路径上的重写情况，局部变量、全局变量与特权变量的使用等。
               .检查标号的交叉引用表。验证所有标号的正确性；检查所有标号的命名是否正确，以及转向指定位置的标号是否正确。
               .检查子程序、宏、函数。验证每次调用与被调用位置是否正确；确认每次被调用的子程序、宏和函数是否存在；检验调用序列中调用方式与参数顺序、个数和类型上的一致性。
               .等值性检查。检查全部等价变量的类型的一致性，解释所包含的类型差异。
               .常量检查。确认每个常量的取值和数制、数据类型；检查常量每次引用同它的取值、数制和类型的一致性。
               .标准检查。用标准检查程序或手工检查程序中违反标准的问题。
               .风格检查。检查在程序设计风格方面发现的问题。
               .比较控制流。比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档并校正错误。
               .选择、激活路径。在程序员设计的控制流图中选择路径，再到实际的控制流图中激活这条路径。如果选择的路径在实际控制流图中不能激活，则源程序可能有错。用这种方法激活的路径集合应保证源程序模块的每行代码都被检查，即桌前检查应至少是语句覆盖的。
               .对照程序的规格说明，详细阅读源代码。程序员对照程序的规格说明书、规定的算法和程序设计语言的语法规则，仔细地阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，并从它们的差异中发现程序的问题和错误。
               .补充文档。桌前检查的文档是一种过渡性的文档，不是公开的正式文档。通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。
               由于程序员熟悉自己的程序和自身的程序设计风格，这种桌前检查可以节省很多的检查时间，但应避免主观片面性。
               代码审查
               代码审查是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。
               第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
               第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。
               在会前，应当给会审小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。这种检查表类似于本章单元测试中给出的检查表。
               代码走查
               代码走查与代码审查基本相同，其过程也分为两步。
               第一步，把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。
               第二步，开会的程序与代码会审不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论使用。
               值得说明的是，使用静态测试的方法也可以实现白盒测试。例如，使用人工检查代码的方法来检查代码的逻辑问题也属于白盒测试的范畴。
 
       软件测试
        在软件测试阶段，监理的主要活动如下。
        （1）监督承建单位将合适的软件测试工程方法和工具集成到项目定义的软件过程中。
        （2）监督承建单位依据项目定义的软件过程，对软件测试进行开发、维护、建立文档和验证，以满足软件测试计划的要求。
        （3）监督承建单位依据项目定义的软件过程和计划实施软件的确认测试。
        （4）计划和实施软件系统测试，实施系统测试以保证软件满足软件需求。
        （5）软件监理组跟踪和记录软件测试的结果。
        在软件测试阶段，监理的主要方法有定期检查、必要抽查、评审。
        （1）定期审查软件测试的工程活动和工作进度。
        （2）根据实际需要对软件测试工程活动进行跟踪、审查和评估。
        （3）对软件测试工程活动和产品进行评审和（或）审核，并报告结果。
 
       白盒测试
        白盒测试方法一般包括控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、修订的条件／判定覆盖MC/DC、条件组合覆盖测试、路径覆盖测试）、数据流测试、程序变异、程序插桩、域测试和符号求值等。
               控制流测试
               控制流测试依据控制流程图产生测试用例，通过对不同控制结构成分的测试验证程序的控制结构。所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行，也称这一过程为覆盖。以下介绍几种覆盖：
               （1）语句覆盖。语句覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被遍历，语句覆盖在测试中主要发现错误语句。
               （2）分支覆盖。分支覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分支至少执行一次，分支覆盖也称判定覆盖。
               （3）条件覆盖。条件覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中的每个条件的可能取值至少满足一次。
               （4）修订的条件／判定覆盖（MC/DC——Modified Condition/Decision Coverage）。修订的条件／判定覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判定中的每个条件都曾独立的影响判定的结果至少一次（独立影响意思是在其他的条件不变的情况下，只改变一个条件，就可影响整个判定的值）。
               对安全性要求比较高的软件，一般采用此覆盖要求。此覆盖要求在测试用例的效率和数量之间较为平衡。
               （5）条件组合覆盖。条件组合覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中条件的各种组合至少出现一次，这种方法包含了“分支覆盖”和“条件覆盖”的各种要求。
               （6）路径覆盖。路径覆盖要求设计适当数量的测试用例，运行被测程序，使得程序沿所有可能的路径执行，较大程序的路径可能很多，所以在设计测试用例时，要简化循环次数。
               以上各种覆盖的控制流测试步骤如下：
               （1）将程序流程图转换成控制流图。
               （2）经过语法分析求得路径表达式。
               （3）生成路径树。
               （4）进行路径编码。
               （5）经过译码得到执行的路径。
               （6）通过路径枚举产生特定路径的测试用例。
               控制流图是描述程序控制流的一种图示方式，它由结点和定向边构成。控制流图的结点代表一个基本块，定向边代表控制流的方向。其中要特别注意的是，如果判断中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符连接的逻辑表达式，则需要改变复合条件的判断为一系列单个条件的嵌套的判断。控制流图的基本结构如下图所示。
               
               控制流图基本结构
               数据流测试
               数据流测试是用控制流程图对变量的定义和引用进行分析，查找出未定义的变量或定义了而未使用的变量，这些变量可能是拼错的变量、变量混淆或丢失了语句。数据流测试一般使用工具进行。
               数据流测试通过一定的覆盖准则，检查程序中每个数据对象的每次定义、使用和消除的情况。
               数据流测试步骤：
               （1）将程序流程图转换成控制流图。
               （2）在每个链路上标注对有关变量的数据操作的操作符号或符号序列。
               （3）选定数据流测试策略。
               （4）根据测试策略得到测试路径。
               （5）根据路径可以获得测试输入数据和测试用例。
               动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析检查的局限，但动态方式检查是沿与测试输入有关的一部分路径进行的，检查的全面性和程序结构覆盖有关。
               程序变异
               程序变异是一种错误驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小错误。本方法应用于测试工具。
               程序插装
               程序插装是向被测程序中插入操作以实现测试目的方法。程序插装不应该影响被测程序的运行过程和功能。
               有很多的工具有程序插装功能。由于数据记录量大，手工进行将是一件很烦琐的事。
               域测试
               域测试是要判别程序对输入空间的划分是否正确。该方法限制太多，使用不方便，供有特殊要求的测试使用。
               符号求值
               符号求值是允许数值变量取“符号值”以及数值。符号求值可以检查公式的执行结果是否达到程序预期的目的；也可以通过程序的符号执行，产生出程序的路径，用于产生测试数据。符号求值最好使用工具，在公式分支较少时手工推导也是可行的。
 
       测试方法
        根据是否执行软件，将软件测试方法分为静态测试和动态测试。动态测试是建立在程序的执行过程中，根据是否要求了解被测对象的内部，分为黑盒测试和白盒测试。
               静态测试和动态测试
                      静态测试
                      静态测试方法包括检查单和静态分析方法，对软件文档的静态测试方法主要是以检查单的形式进行文档审查，而对软件代码的静态测试方法一般采用代码审查、代码走查和静态分析的形式进行。
                      静态分析是一种对代码的机械性和程序化的特性分析方法。一般包括控制流分析、数据流分析、接口分析和表达式分析。
                      代码审查是检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性。代码审查应根据所使用的语言和编码规范确定审查所用的检查单，检查单的设计或采用应经过评审。
                      代码走查是由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，按照程序的逻辑，逐步运行测试用例，查找被测软件缺陷。代码走查应由测试人员集体阅读讨论程序，是用“人脑”执行测试用例并检查程序。
                      对于规模较小、安全性要求很高的代码也可进行形式化证明。静态分析常需要使用软件工具进行。
                      静态测试的特点有：不必设计在计算机上执行的测试用例；可充分发挥人的逻辑思维优势；不需特别条件，容易开展；发现错误的同时也就定位了错误，不需作额外的错误定位工作。
                      动态测试
                      动态测试是建立在程序的执行过程中，根据是否对被测对象内部的了解，分为黑盒测试和白盒测试。
                      黑盒测试是一种按照软件功能说明设计测试数据的技术，不考虑程序内部结构和编码结构，也不需考虑程序的语句及路径，只需了解输入／输出之间的关系，依靠这一关系和软件功能说明确定测试数据，判定测试结果的正确性。黑盒测试又称功能测试、数据驱动测试或基于需求的测试。
                      白盒测试是一种按照程序内部逻辑结构和编码结构设计测试数据的技术，可以看到程序内部结构，并根据内部结构设计测试数据，使程序中的每个语句、每个条件分支、每个控制路径的覆盖情况都在测试中受到检验。白盒测试又称结构测试、逻辑测试或基于程序的测试。
                      动态测试的特点有：实际运行被测程序；必须设计测试用例来运行；测试结果分析工作量大，测试工作费时、费力；投入人员多、设备多，处理数据多，要求有较好的管理和工作规程。
                      在软件动态测试过程中，应采用适当的测试方法，实现测试要求。配置项测试和系统测试一般采用黑盒测试方法；部件测试一般主要采用黑盒测试方法，辅助以白盒测试方法；单元测试一般采用白盒测试方法，辅助以黑盒测试方法。
               黑盒测试
               黑盒测试方法一般采用功能分解、等价类划分、边界值分析、判定表、因果图、随机测试、猜错法和正交试验法等。
                      功能分解
                      功能分解是将需求规格说明中每一个功能加以分解，确保各个功能被全面地测试。功能分解是一种较常用的方法。
                      步骤如下：
                      （1）使用程序设计中的功能抽象方法把程序分解为功能单元。
                      （2）使用数据抽象方法产生测试每个功能单元的数据。
                      功能抽象中程序被看成一种抽象的功能层次，每个层次可标识被测试的功能，层次结构中的某一功能有由其下一层功能定义。按照功能层次进行分解，可以得到众多的最低层次的子功能，以这些子功能为对象，进行测试用例设计。
                      数据抽象中，数据结构可以由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集。程序的每一个输入和输出量的取值集合用数据抽象来描述。
                      等价类划分
                      等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干部分，然后在每部分中选取代表性数据形成测试用例。
                      步骤如下：
                      （1）划分有效等价类：对规格说明是有意义、合理的输入数据所构成的集合。
                      （2）划分无效等价类：对规格说明是无意义、不合理的输入数据所构成的集合。
                      （3）为每一个等价类定义一个唯一的编号。
                      （4）为每一个等价类设计一组测试用例，确保覆盖相应的等价类。
                      边界值分析
                      边界值分析是针对边界值进行测试的。使用等于、小于或大于边界值的数据对程序进行测试的方法就是边界值分析方法。
                      步骤如下：
                      （1）通过分析需求规格说明，找出所有可能的边界条件。
                      （2）对每一个边界条件，给出满足和不满足边界值的输入数据。
                      （3）设计相应的测试用例。
                      对满足边界值的输入可以发现计算错误，对不满足的输入可以发现域错误。该方法会为其他测试方法补充一些测试用例，绝大多数测试都会用到本方法。
                      判定表
                      判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件组合的取值及其相应要执行的操作构成规则，条目中的每一列是一条规则。
                      条件引用输入的等价类，动作引用被测软件的主要功能处理部分，规则就是测试用例。
                      建立并优化判定表，把判定表中每一列表示的情况写成测试用例。
                      该方法的使用有以下要求：
                      （1）需求规格说明以判定表形式给出，或是很容易转换成判定表。
                      （2）条件的排列顺序不会影响执行哪些操作。
                      （3）规则的排列顺序不会影响执行哪些操作。
                      （4）每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
                      （5）如果某一规则的条件的满足，将执行多个操作，这些操作的执行与顺序无关。
                      因果图
                      因果图方法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试用例。
                      步骤如下：
                      （1）分析需求规格说明，引出原因（输入条件）和结果（输出结果），并给每个原因和结果赋予一个标识符。
                      （2）分析需求规格说明中语义的内容，并将其表示成连接各个原因和各个结果的“因果图”。
                      （3）在因果图上标明约束条件。
                      （4）通过跟踪因果图中的状态条件，把因果图转换成有限项的判定表。
                      （5）把判定表中每一列表示的情况生成测试用例。
                      如果需求规格说明中含有输入条件的组合，宜采用本方法。有些软件的因果图可能非常庞大，根据因果图得到的测试用例数目非常多，此时不宜使用本方法。
                      随机测试
                      随机测试指测试输入数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比较困难，多用于可靠性测试和系统强度测试。
                      猜错法
                      猜错法是有经验的测试人员，通过列出可能有的错误和易错情况表，写出测试用例的方法。
                      正交实验法
                      正交实验法是从大量的实验点挑出适量的、有代表性的点，应用正交表，合理地安排实验的一种实验设计方法。
                      利用正交实验法来设计测试用例时，首先要根据被测软件的需求规格说明找出影响功能实现的操作对象和外部因素，把它们当作因子，而把各个因子的取值当作状态，生成二无的因素分析表。然后，利用正交表进行各因子的状态的组合，构造有效的测试输入数据集，并由此建立因果图。这样得出的测试用例的数目将大大减少。
               白盒测试
               白盒测试方法一般包括控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、修订的条件／判定覆盖MC/DC、条件组合覆盖测试、路径覆盖测试）、数据流测试、程序变异、程序插桩、域测试和符号求值等。
                      控制流测试
                      控制流测试依据控制流程图产生测试用例，通过对不同控制结构成分的测试验证程序的控制结构。所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行，也称这一过程为覆盖。以下介绍几种覆盖：
                      （1）语句覆盖。语句覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被遍历，语句覆盖在测试中主要发现错误语句。
                      （2）分支覆盖。分支覆盖要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分支至少执行一次，分支覆盖也称判定覆盖。
                      （3）条件覆盖。条件覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中的每个条件的可能取值至少满足一次。
                      （4）修订的条件／判定覆盖（MC/DC——Modified Condition/Decision Coverage）。修订的条件／判定覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判定中的每个条件都曾独立的影响判定的结果至少一次（独立影响意思是在其他的条件不变的情况下，只改变一个条件，就可影响整个判定的值）。
                      对安全性要求比较高的软件，一般采用此覆盖要求。此覆盖要求在测试用例的效率和数量之间较为平衡。
                      （5）条件组合覆盖。条件组合覆盖要求设计适当数量的测试用例，运行被测程序，使得每个判断中条件的各种组合至少出现一次，这种方法包含了“分支覆盖”和“条件覆盖”的各种要求。
                      （6）路径覆盖。路径覆盖要求设计适当数量的测试用例，运行被测程序，使得程序沿所有可能的路径执行，较大程序的路径可能很多，所以在设计测试用例时，要简化循环次数。
                      以上各种覆盖的控制流测试步骤如下：
                      （1）将程序流程图转换成控制流图。
                      （2）经过语法分析求得路径表达式。
                      （3）生成路径树。
                      （4）进行路径编码。
                      （5）经过译码得到执行的路径。
                      （6）通过路径枚举产生特定路径的测试用例。
                      控制流图是描述程序控制流的一种图示方式，它由结点和定向边构成。控制流图的结点代表一个基本块，定向边代表控制流的方向。其中要特别注意的是，如果判断中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符连接的逻辑表达式，则需要改变复合条件的判断为一系列单个条件的嵌套的判断。控制流图的基本结构如下图所示。
                      
                      控制流图基本结构
                      数据流测试
                      数据流测试是用控制流程图对变量的定义和引用进行分析，查找出未定义的变量或定义了而未使用的变量，这些变量可能是拼错的变量、变量混淆或丢失了语句。数据流测试一般使用工具进行。
                      数据流测试通过一定的覆盖准则，检查程序中每个数据对象的每次定义、使用和消除的情况。
                      数据流测试步骤：
                      （1）将程序流程图转换成控制流图。
                      （2）在每个链路上标注对有关变量的数据操作的操作符号或符号序列。
                      （3）选定数据流测试策略。
                      （4）根据测试策略得到测试路径。
                      （5）根据路径可以获得测试输入数据和测试用例。
                      动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析检查的局限，但动态方式检查是沿与测试输入有关的一部分路径进行的，检查的全面性和程序结构覆盖有关。
                      程序变异
                      程序变异是一种错误驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小错误。本方法应用于测试工具。
                      程序插装
                      程序插装是向被测程序中插入操作以实现测试目的方法。程序插装不应该影响被测程序的运行过程和功能。
                      有很多的工具有程序插装功能。由于数据记录量大，手工进行将是一件很烦琐的事。
                      域测试
                      域测试是要判别程序对输入空间的划分是否正确。该方法限制太多，使用不方便，供有特殊要求的测试使用。
                      符号求值
                      符号求值是允许数值变量取“符号值”以及数值。符号求值可以检查公式的执行结果是否达到程序预期的目的；也可以通过程序的符号执行，产生出程序的路径，用于产生测试数据。符号求值最好使用工具，在公式分支较少时手工推导也是可行的。
 
       黑盒测试
        黑盒测试又称为数据驱动测试、基于规格的测试、输入输出测试或者功能测试。黑盒测试基于产品功能规格说明书，从用户角度针对产品特定的功能和特性进行验证活动，确认每个功能是否得到完整实现，用户能否正常使用这些功能。
        黑盒测试在不知道系统或组件内部结构的情况下进行，不考虑内部逻辑结构，着眼于程序外部结构，在软件接口处进行测试。黑盒测试主要具有如下功能：
        （1）检查程序功能能否按需求规格说明书的规定正常使用，测试各个功能是否有遗漏，检测是否满足性能等特性要求。
        （2）检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息（如数据库或文件等）的完整性。
        （3）检测程序初始化和终止方面的错误。
        黑盒测试方法主要有等价类划分、边界值分析、决策表、因果图、错误推测和功能图法等测试方法，本节主要介绍等价类划分、边界值分析、决策表和元素分析法与错误推测法。
               等价类划分
               等价类是指某个输入域的子集合。在该子集合中，测试某等价类的代表值就等于对这一类其他值的测试，对于揭露程序的错误是等效的。因此，将输入的全部数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。
               等价类划分有两种情况，即有效等价类和无效等价类。
               （1）有效等价类。对于程序的规格说明来说，它是由合理的、有意义的输入数据构成的集合，利用它可检验程序是否实现了规格说明中所规定的功能和性能。
               （2）无效等价类。与有效等价类相反，它是由对程序的规格说明无意义、不合理的输入数据构成的集合。
               测试用例的设计不仅接收合理的数据，也能经受意外的不合理数据的考验，这样才能确保软件具有较高的可靠性。
               分析可能的输入情况，按照如下几条规则对等价类进行划分。
               （1）在输入条件规定了取值范围或值的个数的情况下，确立一个有效等价类和两个无效等价类。
               例如，若输入条件规定了x的取值为1～100的整数，则等价类划分有效等价类1≤x≤100，两个无效等价类分别为x<1或x>100。
               （2）按照数值集合划分。在输入条件规定了输入值的集合或者规定了“必须如何”的条件下，确立一个有效等价类和一个无效等价类。
               例如，输入条件规定了x的取值为偶数，则有效等价类为x的值为偶数，无效等价类为x的值不为偶数的整数。
               （3）输入条件是一个布尔量的情况，确定一个有效等价类和一个无效等价类。
               （4）规定输入数据取一组值（假定n个），并且程序要在对每一个输入值分别处理的情况下，确立n个有效等价类和一个无效等价类。
               例如，分房方案中对教授、副教授、讲师、助教分别计分，则有效类为4个；无效类为1个。
               （5）按照限制条件或规则划分。在规定输入数据必须遵守的规则的情况下，确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
               例如，C程序设计语言的语法规定．每个语句应以“；”结束，则其有效类有1个，而无效类有若干个（如以“，”结束、以“：”结束、以空格结束等）。
               （6）在确知已划分的等价类中各元素在程序处理方式不同的情况下，再将该等价类进一步划分为更小的等价类。
               等价类划分后，形成等价类表，见下表。
               
               等价类表样式
               根据等价类表，确定测试用例。首先，为每一个等价类规定唯一编号；其次，设计新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；最后，设计新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止（通常，程序在执行一个错误后不继续检测其他错误，故每次只测一个无效类）。
               边界值分析
               软件测试实践中，大量的错误往往发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。例如，数组下标、循环控制变量等边界附近往往出现大量错误。因此，作为等价类划分方法的补充，边界值分析方法不是选择等价类的任意元素，而主要是针对各种边界情况设计测试用例。
               常见的边界值一般具有如下情况：
               （1）对16位的整数而言，32767和-32768是边界。
               （2）屏幕上的光标在最左上、最右下位置是边界。
               （3）报表的第一行和最后一行是边界。
               （4）数组元素的第一个和最后一个是边界。
               （5）循环的第0次、第1次和倒数第2次、最后一次是边界。
               边界值分析法应着重测试的情况，一般选取等价类划分的输入和输出的边界正好等于或刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
               边界值分析方法具有如下原则。
               （1）如果输入条件规定了值的范围，则应选取刚达到范围的边界值，以及刚刚超越边界的值作为测试的输入数据。
               （2）如果输入条件规定了值的个数，则用略低于最小值、最小值、略高于最小值、正常值、略低于最大值、最大值和略高于最大值作为测试数据。
               （3）如果程序规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
               决策表
               决策表又称为判定表，用于分析多种逻辑条件下执行不同操作的技术。在程序设计发展的初期，决策表是程序编写的辅助工具。决策表可以把复杂的逻辑关系和多种条件的组合情况表达明确，与高级程序设计语言中的if-else、switch-case等分支结构语句类似，它将条件判断与执行的动作联系起来。但与程序语言中的控制语句不同的是，决策表能将多个独立的条件和多个动作联系清晰地表示出来。
               决策表的组成如下。
               （1）条件桩：列出了问题的所有条件。通常认为，列出的条件次序无关紧要。
               （2）动作桩：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。
               （3）条件项：列出了针对条件桩的取值在所有可能情况下的真假值。
               （4）动作项：列出了在条件项的各种取值的有机关联情况下应该采取的动作。
               规则即任何条件组合的特定取值及其相应要执行的操作。在决策表中，贯穿条件项和动作项的列就是规则。显然，决策表中列出多少个条件取值，也就有多少个规则，条件项和动作项就有多少列。
               所有条件都是逻辑结果的决策表称为有限条件决策表。如果条件有多个值，则对应的决策表就叫做扩展条目决策表。决策表用来设计测试用例，条件解释为输入，动作解释为输出。
               决策表适合以下特征的应用程序：
               （1）if-then-else分支逻辑输出。
               （2）输入变量之间存在逻辑关系。
               （3）涉及输入变量子集的计算。
               （4）输入和输出之间存在因果关系。
               （5）很高的圈复杂度。
               构造决策表的步骤：
               ①确定规则的个数。
               有n个条件的决策表有2n个规则（每个条件取真、假值）。
               ②列出所有的条件桩和动作桩。
               ③填入条件项。
               ④填入动作项，得到初始决策表。
               ⑤简化决策表，合并相似规则。
               元素分析法与错误推测法
               元素分析法主要是对测试对象中的各个元素的属性、范围、特点等进行分析，通过对元素的分析，寻找出测试空间和缺陷空间，设计测试用例的方法。
               元素分析法的基本过程如下：
               （1）找出测试对象中的各个元素。
               （2）分析每个元素的特点和属性，确定测试空间与缺陷空间。
               （3）分析元素的组合情况。
               错误推测法是基于经验和直觉的推测，列举出程序中所有可能错误和容易发生错误的特殊情况，有针对性地设计测试用例。
               经验表明，一段程序中已发现的错误数目和尚未发现的错误数目成正比。程序中容易出错的情况如下所示：当输入数据为零时，或者输入或输出的数目允许变化（例如，被检索的或生成的表的项数），或者输入或输出的数目为0和1的情况（例如，表为空或只有一项）等，都较容易发生错误。又如，在单元测试时曾列出许多在模块中常见的错误，以前产品测试中曾经发现的错误等，这些就是经验的总结。
               错误推测法是根据测试人员的经验来确定测试的范围和程度，主要采用如下技术：
               （1）有关软件的设计方法和实现技术。
               （2）有关前期测试阶段结果的知识。
               （3）根据测试类似或相关系统的经验，了解在以前的这些系统中曾在哪些地方出现过缺陷。
               （4）典型的产生错误的情况，如被零除错误等。
               （5）通用的测试经验规则。
   题号导航      2009年上半年 信息系统监理师 上午试卷 综合知识   本试卷我的完整做题情况  
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题    在手机中做本题