软件测试（白盒测试与黑盒测试）

• 黑盒测试
  • 概述
    • 黑盒测试用例设计方法包括 等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景图法等
  • 等价类划分法
    • 概念
      • 等价类划分法是把所有可能输入的数据，即程序的输入域划分若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。
      • 测试某等价类的代表值就等于对这一类其他值的测试
    • 等价类：
      • 在所有测试的数据中，具有某种共同特征的数据子集
    • 等价类的分类：
      • 有效等价类：满足需求的
        • 有效等价类，是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。
        • 利用有效等价类可检验程序是否实现了规格说明所规定的功能和性能
      • 无效等价类：不满足需求的
        • 无效等价类 指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。
        • 对于具体的问题，无效等价类至少应有一个，也可能多个。
    • 等价类划分规则

      

      • 1.明确需求
      • 2.明确有效和无效等价类
      • 3.为每一个等价类规定一个唯一的编号
      • 4.设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止
      • 5.设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止
  • 边界值分析法
    • 概念
      • 大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部，因此针对各种边界情况设计测试用例，可以查出更多的错误
      • 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。
      • 通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界
      • 与等价类区别：
        • 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
        • 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况
    • 边界范围
      • 使用边界值分析方法设计测试用例，首先应确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况
      • 应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据
        • 上点：边界上的点（等于）
        • 离点：距离上点最近的点
        • 内点：范围内的点
      • 常见边界值：
        • 1.对16Bit的整数而言，32767和32768是边界
        • 2.屏幕上光标在最左上、最右下位置
        • 3.报表的第一行和最后一行
        • 4.数组元素的第一个和最后一个
        • 5.循环的第0次、第1次和倒数第2次、最后一次
  • 错误推测法（经验）
    • 概念
      • 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法
      • 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例
  • 因果图法
    • 概念
      • 因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况
      • 等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系，这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了
      • 如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）
    • 因果图
      • 因果图中使用了简单的逻辑符号，以直线联接左右结点，左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）
      • C1表示原因，通常置于图的左部，e1表示结果，通常在图的右部
      • 关系

        

        • 恒等：若c1是1，则e1也是1；否则e1为0。
        • 非：若c1是1，则e1是0；否则e1是1。
        • 或：若c1或c2或c3是1，则e1是1；否则e1为0。“或”可有任意个输入。
        • 与：若c1和c2都是1，则e1为1；否则e1为0。“与”也可有任意个输入。
      • 约束

        

        • 输入状态相互之间还可能存在某些依赖关系，称为约束。例如,某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
        • E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。
        • I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。
        • O约束（唯一）；a和b必须有一个，且仅有1个为1。
        • R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。
  • 判定表驱动法
    • 判定表是分析和表达多逻辑条件下执行不同操作的情况的工具
    • 能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。
    • 因此，利用判定表能够设计出完整的测试用例集合，在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表适合于处理这类问题
    • 判定表建立步骤：
      • 1） 确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故2n种规则。
      • 2） 列出所有的条件桩和动作桩
      • 3） 填入条件项
      • 4） 填入动作项，等到初始判定表
      • 5） 简化，合并相似规则（相同动作）
  • 正交试验法
    • 从大量的（实验）数据（测试例）中挑选适量的，有代表性的点（例），从而合理地安排实验（测试）的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等
• 白盒测试
  • 概念
    • 白盒测试，又称结构测试、逻辑驱动测试或基于程序代码内部构成逻辑的测试，测试工程师需深入考察程序代码的内部结构、逻辑设计等
    • 对于白盒测试工程师来说，软件产品内部构成是透明的

      

    • 特点
      • 优点：代码覆盖率高
        • 黑盒测试基于业务需求，因为不涉及代码层面，测试用例无法覆盖所有的代码逻辑
      • 缺点：
        • 覆盖所有代码路径难度大
        • 业务功能可能覆盖不全
        • 测试开销大
  • 白盒测试方法
    • 静态白盒测试方法（不需要执行代码）
      • 桌面检查（Code Review）
        • 相互交叉审查代码
      • 代码审查
        • 会议中，由开发人员讲解代码逻辑
      • 代码走查
        • 会议中，参会人在会议过程中，使用测试用例查看代码走向（演示查看）
      • 代码扫描工具
    • 动态白盒测试方法
      • 逻辑覆盖法：通过程序逻辑结构的遍历实现程序的覆盖
        • 覆盖率：用于衡量测试完整性的手段
          • 覆盖率 = 至少被执行一次的item数 / item总数
          • item为程序逻辑结构，如语句、判断、条件、路径等
        • 语句覆盖
          • 语句覆盖测试设计测试用例，使得程序中每条语句至少被执行一次
          • 语句覆盖率 = 至少被执行一次的语句数 / 可执行的语句总数
          • 例如：代码共有4条可执行语句，设计的测试用例执行了3条，语句覆盖了为3/4=75%
          • 弊端：
            • 语句覆盖不能准确判断运算中的逻辑关系错误，因为即使用例能覆盖到所有语句，当也可能无法检测到判断运算中的逻辑
        • 判定覆盖
          • 判定覆盖也叫分支覆盖，设计测试用例，使得程序中的每个判断的”真“和”假“都至少被执行一次
            • 即：程序中的每个分支至少执行一次
            • 只要满足了判定覆盖标准就一定满足语句覆盖标准
          • 判断覆盖率 = 每个判断的真假值至少出现一次 / 判定结果的总数
          • 例如：代码共有2个判定，4个判定结果，设计的测试用例执行了3个分支，分支覆盖了为3/4=75%
          • 弊端：
            • 判断覆盖会忽略条件中取或（||）的情况
        • 条件覆盖（组合的条件被拆分开）
          • 条件覆盖设计测试用例，使得判定中的每个条件至少有一次取真值，有一次取假值
          • 条件覆盖率 = 每个条件的真假值至少出现一次 / 条件结果的总数
          • 例如：代码中有判定2个，条件3个，条件结果6个，设计测试用例执行了5个条件结果，条件覆盖率为5/6=83%
          • 弊端：
            • 条件覆盖笔判定覆盖，增加了对判定中所有条件的测试，但是条件覆盖无法保证判定覆盖（无法保证所有判定结果都被覆盖）
        • 判定-条件覆盖（判定和条件都被覆盖）
          • 判定条件覆盖设计测试用例，使得被测试程序中的每个判断本身的判定结果（真假）至少满足一次，同时，每个逻辑条件的可能值（真假）也至少被满足一次。
            • 即同时满足100%判定覆盖和100%条件覆盖的标准
          • 判定条件覆盖率 = 每个条件的真假值和判定的真假值至少出现一次 / 条件结果的总数 + 判定结果的总数
          • 例如：代码中有判定2个，条件3个，判定结果4个，条件结果6个，设计测试用例执行了3个判定结果，5个条件结果，判定条件覆盖率为：（3+5）/（4+6）=80%
          • 弊端：
            • 满足判定-条件覆盖后，一定能满足条件覆盖、判定覆盖、语句覆盖，但还是会忽略条件中取或的情况
        • 条件组合覆盖（每个判定中条件的可能性）
          • 条件组合覆盖设计测试用例，使得被测试程序中的每个判定中条件结果的所有可能组合至少执行一次
          • 条件组合覆盖率 = 条件组合至少出现一次 / 条件组合的总数
          • 例如：案例代码中有判定2个，条件3个（判定1有2个条件，判定2有1一个条件），判定1的条件组合为4个，判定2的条件组合为2个，设计测试用例执行了5个条件组合，条件组合覆盖率为：5/（4+2）=83%
          • 弊端：
            • 满足条件组合覆盖后，一定能满足条件覆盖、判定覆盖、条件-判定覆盖、语句覆盖，但还是会忽略条件中取或的情况
            • 条件组合覆盖不能保证所有路径被执行
        • 路径覆盖
          • 路径覆盖设计测试用例，覆盖程序中所有可能的路径
          • 路径覆盖率 = 至少被执行过一次的路径数 / 路径总数
          • 例如：案例代码中共有4条路径，设计测试用例执行了3条路径，路径覆盖率为3/4=75%
          • 弊端：
            • 路径覆盖可以对程序进行彻底的测试，但是满足路径覆盖，并不一定满足条件覆盖，也就不能满足条件组合覆盖
      • 基本路径测试法
        • 由于路径覆盖在实际项目中会非常复杂，工作量巨大，所以出现了基本路径测试法
        • 基本路径测试法在程序控制流程图的基础上，通过分析程序的环路复杂性，导出基本可执行路径集合，从而设计测试用例

          

        • 步骤：
          • 1.根据代码画出程序控制流图，并转换为控制流图

            

          • 2.计算环路复杂度，三种计算方法：

            

            • 流图中区域的数量，就对应于环型的复杂性（区域数量 = 环形复杂度）
            • 给定流图G的圈复杂度V(G)，定义为v(G)=E-N+2
              • E是流图中边的数量，N是流图中节点的数量
              • 上图: V(G)=10-8+2
            • 给定流图G的圈复杂度V(G)，定义为v(G)=P+1
              • P是流图G中判定节点的数量
              • 上图:V(G)=3+1
          • 3.导出可执行路径（只需经过节点即可，一般路径数和复杂度相等）

            

          • 4.根据路径，设计测试用例