| 第 153 贴【 2004 － 12 － 1 】：测试件的管理
测试件包括了开发的测试工具、测试套、测试驱动程序、测试桩模块等。认识到测试件也是软件，也需要像其他软件一样被管理和被工程化，把测试件作为产品的一部分等同管理起来，并且使用相同的评价标准和过程。这一点很重要。事实上，测试件是一个特殊的应用系统，它的主要目的是为了测试和评价别的应用或系统。如果应用是关键的，那么测试该应用的测试件应当也是关键的，并且必须使用好的工程原则，包括适当的测试和评价（针对测试件的测试）。
对于工程化测试件，其生命周期过程是和开发的软件完全一样的。一些好的软件工程概念和原则都可以被应用到测试件的开发上。有效的测试件工程化关键是获得合适的时间。如果你创建测试件太迟，并且在大部分软件组件已经被设计和编码之后，那么你就不能获得预防的好处和积极的反馈。如果你试图创建得太早，在软件设计和需求稳定之前就完成，那么你就不能够有效的开发出符合测试需求和目标的测试件，并且你需要面临着很多的返工。
第 154 贴【 2004 － 12 － 2 】：自动化工具支持
自动化支持的一个关键元素是用于所有测试交付物和工作产品的中心项目数据库。这可以指的是测试管理系统，包括用于对测试进行保存、描述、文档化和跟踪，并且对测试目标和结果进行记录、跟踪、评审的辅助设施。好的工具可以使得这些信息很容易被项目组获得，并且提供稳定的工作流支持来简化和跟踪软件开发过程。其它一些重要的工具支持包括：用于支持不同测试环境的测试床和模拟器；提供变更前后分析和工作产品风险及复杂度评价的静态分析器和比较器；用于测试执行和回归的测试驱动及捕获 / 回放工具；度量和报告测试结果及覆盖率的动态分析工具等等。
第 155 贴【 2004 － 12 － 3 】：加强测试度量工作和缺陷分析工作，不断的改进测试
量化管理是项目管理的一个发展趋势。对于测试而言，加强测试成本、结果和效益的度量对测试的管理及改进是非常有帮助的。你无法管理你无法看到和理解的事情，并且对于理解测试来说，你必须收集和跟踪测试过程以及测试有效性方面的数据。
一般来说，在测试过程中，我们需要度量的基本数据包括：
测试投入的工作量和成本数据；
测试任务完成情况；
测试规模数据；
测试结果数据，包括缺陷数据，覆盖率数据等
有了充分的度量数据，管理人员就有了更好调整测试的依据，同时也为今后类似的项目提供了参考。但是有一点需要紧记：度量绝对不能用于对个人或组织的考核！
第 156 贴【 2004 － 12 － 6 】：漏测分析
对于测试来说，进行漏测分析有助于测试的不断改进。漏测的分析不仅仅分析版本发布之后的缺陷，还可以针对内部每轮系统测试版本的漏测问题进行分析。一般对于每个缺陷我们需要从以下几个角度进行分析：
该缺陷是否能够在内部或者上一个系统测试版本中被发现？为什么没有被发现？如何避免这类情况产生？
该缺陷是否有相应的用例？如果没有，则设计用例，同时还需要分析是否还有类似的问题？针对这些类似的问题是否也需要补充相应的用例？
该缺陷是否属于因开发修改其它缺陷而引入的新缺陷？为什么会引入新的缺陷？回归的时候为什么没有考虑这方面测试，是否回归分析不够全面？如何改进？
第 157 贴【 2004 － 12 － 7 】：加强测试的培训
在软件测试中存在一个很大的误区，即很多管理人员把不合格的开发人员安排做测试，这导致了一种不利的思维：即测试是不重要的，测试是不需要技术的工作。因而很多人把测试作为了一个向开发过渡的工作。然而，事实上，安排一个没有丰富开发经验的人来做测试工作是不利的。因为要做好测试工作，你必须对开发很了解。而另一方面，测试本身是一门需要技术的学问，它包含了众多的理论和实践。缺乏这些知识和经验，测试的深度和广度就不够，测试的质量也就无法保证。因此，对测试人员加强培训是很关键的。
测试和开发有很多的不同，在很多公司中，对于开发人员的技术发展通道一般都比较明确，然而对测试人员的技术发展通道却比较模糊，这在很大程度上打击了测试人员的积极心和士气。很多测试人员看不到未来的发展方向，也定位不准自己的角色。这导致的结果是大量测试人员离职或转去做开发工作，而对公司来说，整体的测试水平一直得不到提高。
第 158 贴【 2004 － 12 － 8 】：函数覆盖
有很多测试工具，例如 TrueCoverage ， Logiscope 等，都提供了函数覆盖的概念，函数覆盖是针对系统或一个子系统的测试的，它表示在该测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大。函数覆盖是一个比较容易自动化的技术，同时也易于理解。其公式如下：
函数覆盖 ＝ （至少被执行一次的函数数量） / （系统中函数的总数）
由于函数覆盖也是基于代码的，因此你可以把其归入到白盒的范畴内。
第 159 贴【 2004 － 12 － 13 】：判定路径覆盖
判定路径覆盖（ Decision-to-Decision Paths Coverage ， DDP Coverage ）是判定覆盖的一个变体。这里的判定指的是一个序列语句，其起始位置是函数入口或一个判定（如 If, while, switch 等）的开始，结束位置是下一个判定的开始。
通过计算哪些判定路径已经走过，哪些没有走过，我们就可以得到 DDP 覆盖率了。其公式如下：
DDP 覆盖 ＝ （至少被执行到一次的判定路径数量） / （系统中判定路径总数）
第 160 贴【 2004 － 12 － 14 】： 更改条件判定覆盖
更改条件判定覆盖（ Modified Conditions/Decisions Coverage ， MC/DC Coverage ）是判定条件覆盖的一个变体。更改条件判定覆盖主要为多条件测试提供了方便，通过分析条件判定的覆盖来增加测试用例，防止测试的指数上升趋势。
定义：
MC/DC 标准满足下列需求：
需求 1 ：被测试程序模块的每个入口点和出口点都必须至少被走一次。并且每一个程序判定的结果至少被覆盖一次。
需求 2 ：通过分解逻辑操作，程序的判定被分解为基本的布尔条件表达式，每个条件独立的作用于判定的结果，覆盖所有条件的可能结果。
第 161 贴【 2004 － 12 － 15 】：分支条件组合覆盖
分支条件组合覆盖（ Branch Condition Combination Coverage ）是一种比判定条件覆盖更强的覆盖。它的含义是，设计一定的测试用例，使得每个分支的各操作数值的组合都遍历一次。其计算公式如下：
分支条件组合覆盖 ＝ （被评价到的分支条件组合数） / （分支条件组合总数）
我们看下面这个例子：
其中， A 和 B 是操作数，应用前面判定条件覆盖的概念，我们可以判断出下面一组用例可以达到判定条件覆盖要求：
如下表，满足判定条件覆盖的用例
用例序号 A 的值 B 的值
Case1 True True
Case2 False Fase
但显然，在该例中， A 和 B 的条件组合有四种（ TRUE,TRUE ），（ TRUE,FALSE ），（ FALSE,TRUE ），（ FALSE,FALSE ）。因此，如果要达到分支条件组合覆盖，还得补充两个用例：（ TRUE,FALSE ），（ FALSE,TRUE ）。
第 162 贴【 2004 － 12 － 17 】： Z 路径覆盖
Z 路径覆盖是路径覆盖的一个变体。路径覆盖是白盒测试最为典型的问题。着眼于路径分析的测试可称为路径测试。完成路径测试的理想情况是做到路径覆盖。对于比较简单的小程序实现路径覆盖是可能做到的。但是如果程序中出现多个判断和多个循环，可能的路径数目将会急剧增长，达到天文数字，以至实现路径覆盖不可能做到。
为了解决这一问题，我们必须舍掉一些次要因素，对循环机制进行简化，从而极大地减少路径的数量，使得覆盖这些有限的路径成为可能。我们称简化循环意义下的路径覆盖为 Z 路径覆盖。
这里所说的对循环化简是指，限制循环的次数。无论循环的形式和实际执行循环体的次数多少，我们只考虑循环一次和零次两种情况。也即只考虑执行时进入循环体一次和跳过循环体这两种情况。
对于程序中的所有路径可以用路径树来表示。当得到某一程序的路径树后，从其根结点开始，一次遍历，再回到根结点时，把所经历的叶结点名排列起来，就得到一个路径。如果我们设法遍历了所有的叶结点，那就得到了所有的路径。
当得到所有的路径后，生成每个路径的测试用例，就可以做到 Z 路径覆盖测试。
第 163 贴【 2004 － 12 － 20 】： ESTCA 覆盖
逻辑覆盖其出发点似乎是合理的。所谓 “ 覆盖 ” ，就是想要作到全面，而无遗漏。但事实表明，它并不能真的作到无遗漏。面对这类情况我们应该从中吸取的教训是测试工作要有重点，要多针对容易发生问题的地方设计测试用例。
K.A.Foster 从测试工作实践的教训出发，吸收了计算机硬件的测试原理，提出了一种经验型的测试覆盖准则，较好地解决了上述问题。
Foster 的经验型覆盖准则是从硬件的早期测试方法中得到启发的。我们知道，硬件测试中，对每一个门电路的输入、输出测试都是有额定标准的。通常，电路中一个门的错误常常是 “ 输出总是 0” ，或是 “ 输出总是 1” 。与硬件测试中的这一情况类似，我们常常要重视程序中谓词的取值，但实际上它可能比硬件测试更加复杂。 Foster 通过大量的实验确定了程序中谓词最容易出错的部分，得出了一套错误敏感测试用例分析 ESTCA （ Error Sensitive Test Cases Analysis ）规则。事实上，规则十分简单：
[ 规则 1] 对于 A rel B （ rel 可以是 <, = 和 > ）型的分支谓词，应适当地选择 A 与 B 的值，使得测试执行到该分支语句时， A < B, A = B 和 A > B 的情况分别出现一次。
[ 规则 2] 对于 A rel1 C （ rel1 可以是 > 或是 < ， A 是变量， C 是常量）型的分支谓词，当 rel1 为 < 时，应适当地选择 A 的值，使： A = C–M
（ M 是距 C 最小的容器容许正数，若 A 和 C 均为整型时， M = 1 ）。同样，当 rel1 为 > 时，应适当地选择 A ，使： A = C + M
[ 规则 3] 对外部输入变量赋值，使其在每一测试用例中均有不同的值与符号，并与同一组测试用例中其它变量的值与符合不一致。
显然，上述规则 1 是为了检测 rel 的错误，规则 2 是为了检测 “ 差一 ” 之类的错误（如本应是 “IF A > 1” 而错成 “IF A > 0” ），而规则 3 则是为了检测程序语句中的错误（如应引用一变量而错成引用一常量）。
上述三规则并不是完备的，但在普通程序的测试中确是有效的。原因在于规则本身针对着程序编写人员容易发生的错误，或是围绕着发生错误的频繁区域，从而提高了发现错误的命中率。
第 164 贴【 2004 － 12 － 21 】：继承上下文覆盖
结构化覆盖率用来度量测试的完整性已经被大家所接受。但是由于传统的结构化度量没有考虑面向对象的一些特性，如多态，继承和封装等，所以这个技术在面向对象领域却遇到了挑战，传统的结构化覆盖必须被加强，以满足面向对象特性。继承上下文覆盖就是扩展到面向对象领域里的一种覆盖率度量方法，它用于度量在系统中的多态调用被测试得多好。
继承上下文覆盖不是一个单个的度量，它是一种扩展传统结构化覆盖来考虑当方法被继承时的额外接口。继承上下文覆盖提供了一个可替代的度量定义，它考虑在每个类的下上文内获得的覆盖率级别。继承上下文定义把基类上下文内例行程序的执行作为独立于继承类上下文内例行程序的执行。同样，它们在考虑继承上下文内例行程序的执行也独立于基类上下文内例行程序的执行。为了获得 100 ％继承上下文覆盖，代码必须在每个适当的上下文内被完全执行。
第 165 贴【 2004 － 12 － 22 】：基于状态的上下文覆盖
在绝大多数面向对象系统中，存在许多类，它们最好可以被描述为状态机。这些类的对象可以存在于众多不同状态中的任何一种，并且每个类的行为在每个可能的状态中其性质是不同的 —— 类的行为依赖于状态。如何测试这种类成为了传统覆盖率的一个难题。
基于状态的上下文覆盖类似于继承上下文覆盖：它提供了传统结构化覆盖率度量的一个可选择的定义。这些可选择的定义在不同的上下文内其独立度量的覆盖率不同。
基于状态的上下文覆盖对应于被测类对象的潜在状态。这样基于状态的上下文覆盖把一个状态上下文内的一个例行程序的执行认为是独立于另一个状态内相同例行程序的执行。为了达到 100 ％的基于状态的上下文覆盖，例行程序必须在每个适当的上下文（状态）内被执行。
第 166 贴【 2004 － 12 － 23 】：覆盖率不是目标，只是一种手段
测试的目标是尽可能的去发现错误，去寻找被测对象与既定的规格不一致的地方。因此我们在进行测试用例设计的时候，首先应当从对需求和设计的了解，使用已有的经验去挖掘测试用例，包括正常的用例和异常的用例。在这个基础上，我们再使用需要的覆盖率准则来衡量已有的测试设计并补充相应的用例来达到需要的覆盖率准则。如果我们仅以覆盖率目标来指导测试的话，会丢失很多重要的信息，陷入到追求覆盖率数字的极端中去。
| 
