结构视图与行为视图的最明显差别在于：前者侧重于“程序是什么”,而后者则关注“程序干什么”.然而不断困扰测试人员的一个问题是：基础性的文档通常都是由开发人员编写的，并且是为开发人员服务的，所以文档就很自然地强调程序的结构信息而不是行为信息。本节将开发一种简单的维恩图，借以明确一些测试中很微妙的问题。
我们先来看看程序的行为空间（注意，此处我们研究的是测试的本质），对于给定的程序及其规格说明，考察其规格说明所规定的行为集合S和编程实现的行为集合P.图1-3给出了程序行为空间与S以及P之间的关系。在程序的所有可能行为中，规定的行为都在圆圈S内，所有实际实现的行为都在圆圈P中（此处要留心P同全空间U之间存在的差异）。利用这个维恩图，可以清楚地看到测试人员所遇到的问题。如果某些规定行为未经编程实现，情况会怎样呢？用前面提到的术语来讲，这些是遗漏故障。类似地，如果编程实现的某些行为不是规格说明所规定的，情况又会怎样呢？这些就是过失故障，或者在规格说明完成之后所发生的错误。S与P的交集（图中的橄榄球型区域）是“正确”的部分，即那些按规定实现的行为。对测试的一个很好的认识是：测试就是确定按规定实现的程序行为的范围的过程。（需要补充的是，正确性仅仅是对确定的规格说明和具体的程序实现而言的。正确性是相对的，而不是绝对的。）
图1-3 程序的规定行为与实现行为
在图1-4中，新圆圈代表测试用例集合。注意，它同程序行为全空间以及各个行为集合之间存在些许不同。由于测试用例要引发程序行为，所以数学家们应该能谅解这种表述中的不严密性。下面来考察集合S、P和T之间的关系。可能会有测试不到的规定行为（2号区和5号区）、测试到的规定行为（1号区和4号区）以及对应于未规定的行为的测试用例（3号区和7号区）。
类似地，也会有测试不到的实现行为（2号区和6号区），测试得到的实现行为（1号区和3号区），以及对应于未实现的行为的测试用例（4号区和7号区）。在维恩图中，每一个区域都很重要。如果某些规定行为没有相应的测试用例，那测试就是不完备的。如果有测试用例对应的是未规定的行为，会产生几种可能：或者此测试用例设计得不恰当，或者规格说明不够充分，或者测试人员故意要确认规定不该发生的行为确实不会发生。（就我个人的经验来讲，好的测试人员经常会有意设计这最后一种情况的测试用例。这也是在对规格说明和系统设计进行评审时，吸收有经验的测试人员参与的重要原因。）
至此我们已经可以看清几个把软件测试称为技艺的原因了：为了使所有行为集合的交集（1号区）尽可能大，测试人员应该怎样做呢？也就是说，应该如何确定集合T中的测试用例。答案很简单：通过测试方法来构造测试用例。从这个思路出发就可以利用本文给出的维恩图来比较各种测试方法的有效性。
------------------------------------------------------------------------------------
转自：http://book.51cto.com/art/201102/246041.htm
