软件测试：V模型/X模型/H模型

X模型的目标是弥补V模型的一些缺陷。X模型真的能解决测试过程各方面的问题，例如交接、经常性的集成？

在软件测试方面，V模型是最广为人知的模型，尽管很多富有实际经验的测试人员还是不太熟悉V模型，或者其它的模型。V模型已存在了很长时间，和瀑布开发模型有着一些共同的特性，由此也和瀑布模型一样地受到了批评和质疑。在《软件测试：不可忽略的阶段》中已经详细讨论了V模型，这里只作一个概要的介绍。

V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

user posted image





在V模型中，单元测试是基于代码的测试，最初由开发人员执行，以验证其可执行程序代码的各个部分是否已达到了预期的功能要求；

集成测试验证了2个或多个单元之间的集成是否正确，并有针对性地对详细设计中所定义的各单元之间的接口进行检查；

在所有单元测试和集成测试完成后，系统测试开始以客户环境模拟系统的运行，以验证系统是否达到了在概要设计中所定义的功能和性能；

最后，当技术部门完成了所有测试工作后，由业务专家或用户进行验收测试，以确保产品能真正符合用户业务上的需要。

尽管很多人对V模型表示了否定，但很少有人真正详细地讨论这些问题。Brian Marick（《The Craft of Software Testing (Prentice Hall, 1995)》一书的作者）曾如此表示。在STAR2000 (Software Testing Analysis and Review) 东部会议上，Marick曾经和Dorothy Graham（本系列文章的另一位作者）进行过一场论争，并在其个人网站www.testing.com上对V模型提出过一些中肯的反对意见。


X模型


Marick曾提出过一些观点和意见，其中首先是Marick不建议要建立一个替代模型。这里我很冒昧地引用了一些 Marick的想法，并重新经过组织，形成了“X模型”。其实并不是为了和V模型相对应而选择这样的名字，而是由于其它一些原因：X通常代表未知，而 Marick也认为他的观点并不足以支撑一个模型的完整描述，但其中已经有一个模型所需要的一些主要内容，其中也包括了象探索性测试（exploratory testing）这样的亮点。我还需要在使用文字方面也向Marick道歉，因为认同Marick观点的无疑大多属于X一代（X一代）。另外，我勾画了一张X形状的示意图，我相信该图能够很好地以另一种表达形式来体现Marick的观点。




由于X模型从没有被文档化，其内容一开始需要从在V模型的相关内容中进行推断，这在Marick的相关文章中已有体现。这里关于X模型的论述比较简短，因为它还没有完全从文字上成为V模型的全面扩展，而且我不想在这里重复在《软件测试：不可忽略的阶段》文章中所提到的很多测试技术的概念。

Marick对V模型的最主要批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等等。


解决交接和频繁集成的周期的问题


Marick 认为一个模型不应该规定那些和当前所公认的实践不一致的行为。我也很认同这一点。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。(右上半部分），这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。

由上图中可见，X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。Marick虽然没有对此进行明确的说明，但一定很乐意看到该方法的界定。

然而，关注于这样的低级别的行为可能会引起不同的议论。一个模型和一个单独的项目计划有所不同。模型不应该描述每个项目的具体细节，模型应该对项目进行指导和支持。当然，代码的交接也可以简单地认为是一种集成的形式。而V模型也并没有限制各种创建周期的发生次数。


H模型

h模型的示意图仅仅演示了在整个生产周期中，某个（测试）层次上的一次测试“微循环”。图中的“其他流程”可以是任意的开发流程，例如设计流程和编码流程，也可以是其他非开发流程，甚至是测试流程自身。向上的三
角箭头表示，在某个时间点，由于“其他流程”的进展而（由于先后关系）引发或者（由于因果关系）触发了测试就绪点，这个时候，只要测试准备活动完成，测试执行活动就可以（或者说，需要）进行了。
概括而言，h模型揭示了
1、 软件测试不仅仅指测试的执行，还包括很多其他的活动；
2、 软件测试是一个独立的流程，贯穿产品的整个周期，与其他流程并发的进行；
3、 软件测试要尽早准备，尽早执行；
4、 软件测试根据被测物的不同是分层次的，不同层次的测试活动可以是按照某个次序先后进行的，也可能是反复的。

采用h测试模型的三个理由
1、有利于测试的分工，从而降低成本，提高效率。
首先，h模型强调软件测试准备和测试执行分离。准备阶段和执行阶段有不同的测试活动，例如，测试准备活动，包括测试需求分析、测试计划、测试分析、测试编码、测试验证等等，而测试执行活动，则包括测试运行、测试报
告、测试分析等等。准备阶段和执行阶段有不同的工作侧重点，不同的测试活动也需要不同的知识和技能。显而易见，测试的设计人员比执行人员有更高的能力要求，不同的岗位可以聘用不同的人员。如果一个测试设计人员同时
被指派去执行测试，那既是人力资源的浪费，也可能挫伤设计人员的创造性合积极性。所以，软件测试分工带来的第一个直接好处就是降低人力成本。第二个直接好处就是提高效率。分工带来的间接的长期的好处是，软件测试可
以成为一个有职业前景的职位，这有利于吸引人才以此作为自己的职业生涯，从而形成软件测试领域的人力积累和良性循环。
2、有利于认识到测试的复杂性，从而赢得重视和尊重。
H模型可以促使人们充分认识到软件测试的复杂性。这儿的复杂不是指技术上的复杂，而是指过程上的复杂。正如传统的软件开发被简化为编程一样，软件测试也常常被简化为运行一下被测的软件，观察是否有异常的运行结果
。软件测试也有不同的阶段，有不同的活动，而且这些阶段和活动要被组成一个系统才能有效的运作。没有组织的，非结构化的软件测试除了浪费时间和金钱外，几乎不可能有实质性的产出。认识到复杂性才可能得到足够的重视
和必要的尊重。重视主要来自于管理层，而尊重则主要来自于平行的其它流程的人员，例如编程人员。尽管测试流程是一个独立的流程，但它必须被置于整个软件生产的流程系统中，作为一个有机的组成部分，并与其它流程有效
的交互，才可能发挥作用。
3、有利于了解测试投入的去向，从而得到测试效益的公正评判。
第三个理由与一个长期存在的“测试怪圈”有关。测试经理总是抱怨测试上投入不够；测试人员要么被看作是“无所事事”，要么被看作“忙而无功”；而管理层则因为测试上的投入没有一个可视的结果而拒绝加大投入；更糟
糕的是，用户在投诉软件的质量问题，组织的声誉和利润都每况愈下。H模型并不能扭转这种糟糕的局面，但它有助于跟踪测试投入的流向，例如，在各个测试活动上的投入分别有多少，比例是否合理，哪些是用于测试准备的，
而如果由于其它流程的差错导致重做准备，那么浪费的投入有多少。在h模型中，测试是一个有组织的、结构化的独立流程，既保证了自身的有序和结构清晰，也保证了流程之间的“界面”清晰。这样，软件测试就不是一笔糊涂
帐，才可能得到公正的投入-产出的评判，软件测试才可能避免成为“出气筒”和“替罪羊”的“宿命”。