关于测试内容的基于覆盖率的测试手段

可以根据在使用这些手段时已经掌握知识的不同，把这些手段按所关注的问题进行多种不同的分类。例如，如果把功能集成测试用于检查每个功能与所有其他功能组合在一起时是否能够正常运行，则这种测试及时面向覆盖率的测试。如果有针对功能相互交互的错误理论，并想进行跟踪，则这种测试就是面向问题的测试。（例如，如果意图是想发现功能在相互传递数据时出错，就是面向问题的测试）。

功能测试（function testing）。逐个测试每个功能。彻底测试功能，直到可以确信该功能没有问题。白盒功能测试通常叫做单元测试，集中测试可以看到代码的功能。黑盒功能测试关注命令和特性，以及用户可以做或选择的事情。在做涉及多个功能的更复杂的测试之前，最好先做功能测试。在复合测试中，第一个出现问题的功能可能会使测试停下来，阻止通过这个测试发现多个其他功能也出现问题。如果依靠复合测试而不是单个测试功能，肯呢个要很晚才会知道有一个功能出现问题，可能要花费大量工作在复合测试中定位，最后却发现问题出现在一个简单功能上。

特性或功能集成测试（feature or function integration testing）。一起测试多个功能，以检查功能在一起执行的情况。

菜单浏览（menu tour）。遍历 GUI 产品中的所有菜单和对话框，使用每个可用的选项。

域测试（domain testing）。域是一个（数字）集合，包含所有可能的函数变量取值。在域测试中，要标识函数和变量。变量可以是输入或输出变量。（输入域和值域之间的数字区别在这里无关，因为这两种域的测试分析都是一样的。）对于每个变量，都要把其他取值集合划分为等价类，并从每个类中选择少量代表（一般是边界值）。这种方法假设如果用类中的少量好的代表值进行测试，就可以发现用类中所有成员测试所能够找出的大多数或全部问题。请注意，与功能测试形成对比的是，感兴趣的要素是变量而不是功能。很多变量被多个功能使用。进行域测试时必须分析变量，然后再根据分析，以这个变量作为输入或输出，测试设计这个变量的每个功能。

等价类分析（equivalence class analysis）。等价类是测试员认为是等价的一组变量取值。如果相信一组测试用例：（a）测试的都是相同的东西：（b）如果其中一个捕获到一个程序错误，其他测试用例可能也不能捕获到，则这些测试用例是等价的。一旦找出一个等价类，可只测试其一两个成员。

边界测试（boundary testing）。等价类是一组取值。如果可以把成员映射到一列数字上，则边界值就是类的最小和最大值。在边界测试中，要测试这些值，还要测试相邻类的边界值，这些值要比测试的类的最小值略小，比要测试的类的最大值略大。例如，请考虑一个接受 10~50 整数值的输入字段。感兴趣的边界值是 10（最小整数）、9（小于 10 的最大整数）、50（最大整数）、51（大于 50 的最小整数）。

最佳代表测试（best representative testing）。等价类的最佳代表是在暴露软件中的错误的可能性方面至少与类中其他值一样的值。在边界测试中，边界值几户总是最佳代表。但是有时不能将等价类映射得到一组数字上。例如，兼容惠普 PCL-5 的打印机是（或应该是）一个等价类，因为这些打印机的工作方式相同。假设对于一个具体任务，其中一种打印机与其他打印机相比，略微更可能出现问题。那么这种打印机可以作为这个类的最佳代表。如果对它测试没有发现问题，那么可以比较可靠地认为其他打印机也没有问题。

输入字段测试大纲或矩阵（input field test catalogs or matrices）。对于每种输入字段，可以开发一组相当标准的测试用例，在这个产品和后续产品中的类似字段中重用。

用各种方式映射和测试编辑字段（map and test all the ways to edit a field）。常常可以以多种方式改变某个字段中的值。例如可以把数据输入到该字段，直接在字段中输入数据，通过程序将计算好的结果复制到字段中，通过程序将再次计算好的结果复制到字段中，等等。字段是有限制的（限制字段可以取哪些值）。有些限制是不变的，有些限制要依赖于其他字段的取值。例如，如果 J 和 K 是无符号整数，其限制就是 0 一直到 MaxInt。这些都是不变限制，依赖于程序设计语言对无符号整数的定义。但是，如果 N 也是无符号整数，N=J+K,N=5。在这种情况下 J=5-K，J 不能大于 5（N 的值）。这是可变限制，其所允许的取值范围取决于 N 的值。为了检查 J 是否在所允许的取值范围内（5-K），可以使用各种能够把数据输入到 J 中的方法改变 J 的取值。

逻辑测试（logic testing）。变量在程序中有关系。例如，程序可能有这样一个决策规则：如果 PERSON-AGE 大于 50，并且如果 SMOKER 是 YES，则 OFFER-INSURANCE 必须是 NO。这总决策规则表达了一个逻辑关系，逻辑测试试图检查程序中的所有逻辑关系。因果图（cause-effect graphing）是一种用于设计大量基于逻辑测试的手段。

基于状态的测试（state-based testing）。程序的状态要发生转换。在给定状态中，有些输入是有效的，其他输入被忽略或拒绝。对于有效输入，被测程序要完成它可以做的事，并且不尝试做它不能做的事。在基于状态的测试中，每次都要通过经过大量状态迁移（状态改变）并仔细检查结果来检验程序。

路径测试（path testing）。一条路径包含测试员所执行的所有步骤，或程序为了得到正确状态所通过的所有语句。路径测试包括测试通过程序的很多路劲。通过非平凡程序的路径是不可能的。因此，有些测试员进行子路径测试（subpath testing）,测试很多部分路径。例如，基于路径测试（basis-path testing）包括测试一定类型（基本路径）的大多数或全部假设，这里采用的假设是如果测试了所有基本路径，那么几户没有更长的路径会找出这些测试所遗漏的问题。

语句与分支覆盖率（statement and branch coverage）。如果测试执行了程序中的所有语句（或代码行），则达到 100%的语句覆盖率。如果执行了所有语句和一个语句到另一个语句之间的所有分支，则达到 100%的鱼护和分支覆盖率。设计自己的测试，达到高的语句与分支覆盖率，有时叫做“基于覆盖率的测试（coverage-based testing）”。（达到覆盖率目标后，可以停止测试，或停止设计更多的测试）。把它叫做语句与分支覆盖率，是为了与关注其他类型覆盖率的测试相区别。配置覆盖率就是一个很好例子，这种手段执行同一条语句很多次，但是潜在产生非常不同的结果。其他例子还有很多很多（Kaner 1995a）。关注达到高语句与分支覆盖率的测试往往遗漏很多类型的问题，例如（但不限于）与以下因素有关的程序错误：遗漏代码、边界值处理不正确、时序问题、硬件和软件配置兼容性问题，诸如指针越界、内存泄露或栈破坏等最终导致栈溢出的滞后暴露问题、可使用性问题，以及其他方面没有满足客户需求的问题。这种手段在标识不完备测试方面（哪些代码还没有测试过）要跟有价值得多，而不是在所需测试量的最低标准方面。的确，让测试员停止测试只是因为达到了 X%的覆盖率，这样做很危险（Marick 1999）。

配置覆盖率（configuration coverage）。如果必须测试 100 台打印机的兼容性，并且已经测试了 10 台，就达到 10%的打印机覆盖率。更一般地，配置覆盖率度量测试员已经运行（并且程序已经通过）的配置测试占计划运行的配置测试总数的百分比。为什么要把它叫做测试手段？一般我们只是将它看做是已经完成了多少一定类型测试的度量。但是，有些测试员完成的一系列特殊测试，可以更快、更容易地完成大量配置测试。对于他们来说，优化工作以达到高的覆盖率，是一种测试手段。

基于规格说明的测试（specification-based testing）。这种测试关注验证在规格说。明中所做的有关产品的每个事实声明。（事实声明是可以用真或假表示的任何语句。）常常包括手册、市场开发文档或广告、技术支持人员寄给客户的印刷品中的所有声明。

基于需求的测试（requirements-based testing）。测试关注证明程序满足需求文档中的所有需求（或关注逐个需求地证明某个需求没有被满足。）

组合测试（combination testing）相互组合测试两个或更多变量。组合测试很重要，但是很多测试员对这种测试研究得还很不够。通过程序得到的大部门好处都基于很多变量的交互。如果不在测试中一起改变这些变量，就会遗漏由不同的组合（而不是不同的单个取值）触发的错误。

搜索微信公众号：TestingStudio 霍格沃兹的干货都很硬核