X模型的基本思想是Brian Marick提出来的,Robin F. Goldsmith引用了 Marick的想法,经过重新组织,形成了 X模型。X模型的左侧描述的是对各个程序片段进行的相互独立的编码和测试,然后(右上部分)通过多次集成,最终成为可执行代码,而且还要对这些可执行代码进行测试。已经通过集成测试的产品可以直接发布给客户,或者作为更大规模集成测试的一个子模块。在X模型的右下部分,还定义了探索性测试,这是不在计划之内的特殊类型的测试,这种方式往往能使有经验的测试人员在计划之外发现更多的软件缺陷。
但Marick自己也认为他的观点并不能支撑一个完整的模型,也就很难对整个软件项目进行指导和支持。V模型或W模型都明确地指出了需求的重要角色,但X模型并没有提及,这也是X模型不完整的一个表现。X模型并没有要求在集成测试之前做单元测试,这也正像很多开发人员实际做的一样,省略了单元测试而直接开始集成测试。一方面,这种做法的结果很可能是要在集成测试阶段付出更大的代价去修复本应在单元测试中花费很小代价就能够解决的问题。另一方面,X模型也没能提供一个可以跳过单元测试的准则。X模型和探索性测试都提倡把更多的时间投入到实际的测试活动中,而不是测试文档的编写上面。但实际上应该避免旳是大量的和冗余的测试文档,而用精炼的测试文档把重要的信息记录下来,不仅可以避免遗忘,而且方便自己进一步完善测试计划,也更利于实现与他人的共享。
d) H模型
H模型中,软件测试流程贯穿于整个软件产品的周期,完全独立项目中的其他流程,并与其他流程并发地进行。当某个测试点就绪时,就可以从测试准备阶段过度到测试执行阶段。软件测试就可以尽快的进行,而且可以根据被测对象的不同而分层次进行。H模型的示意图所描述的仅仅是整个软件生命周期里,某一次测试活动的微循环。图中的其他流程可以理解为任意的开发流程,如设计流程,编码流程等。H模型揭示的道理简单而直接:尽早准备测试活动,只要测试的条件满足了,就可以或者说应该开展测试活动。不同测试活动可以按照某种次序先后开展,也可以是并行,有时候甚至是反复的。业内关于H模型本身的论述和讨论较少,是因为其直接而简单地阐述了一种不同于按照模型而顺序执行流程的工作思路和方法。但H模型本身并不是一个完整的方法论,不能够为实际的测试工作进行全面的指导,而需要使用者根据自身实际情况进行不同的过程设计而灵活运用。
e)前置测试模型
前置测试模型(Proactive Testing Model)来源于V模型和X模型,是由RobinF Goldsmith等人提出的,是一个将测试和幵发紧密结合的模型,它定义了如何在编码之前对程序进行测试设计,并强调了要对每一个交付的开发结果进行一定方式的测试。相对于V模型和X模型,前置测试模型更趋向于设计出一种更高效率的测试流程。
前置测试模型把幵发流程和测试流程整合到同一个生命周期里,并且定义了从项目开始到结束过程中的各个关键行为。它具体地描绘出了几个关键的概念:
对每一个交付物都应该进行测试
如同W模型提到的,除了软件代码要进行测试,开发过程中每一个交付物都需要以适当的方式进行测试。如图中圆角方框所示的项目可行性报告、业务需求说明书、设计说明文档和软件代码等,其可测试的范围设计更广,定义更为明确。例如,前置测试模型理论中提到,许多人认为可测试性是需求定义需要解决的最主要的问题之一,并且进一步认为测试用例就是要对每一项需求进行对应和验证。而事实上,针对需求的测试是必须和必要的,但仍然是不完备的。仅根据需求的幵展的测试,至多也只能够把测试做的和需求一样好。不可避免的是,需求本身也有可能犯错,或者不全面,这就要求测试设计者以更高的视角来理解产品和设计测试。
在设计阶段进行测试的规划和设计
设计阶段是最适合开展测试规划和测试设计的时机,有效的测试设计能够更经济地增加测试中发现的缺陷的数量。
把测试紧密地结合在开发中
在开发阶段,采用编码-测试,再编码-再测试的模式,把测试活动紧密地结合在开发过程中。只要一交付代码,测试就要接入开展工作,而不是按照流程定义的阶段完全隔离开。
保持验收测试和技术测试的相互独立
如果验收测试和技术测试能够保持相互独立,它们将为产品的设计和实现提供双重的保障。前置测试模型主张验收测试和技术测试从两个不同的方向开展工. 作,而能够从两个不同的视角来证明产品是符合用户的需求的。
反复交替地开展开发和测试
项目进行的过程中,总会因为需要优化和修复交付物而回到前面的阶段,这就要求幵发和测试活动要反复交替地开展。尽管和V模型一样,前置模型并没有明确指出这种情况发生的程度,但它确实明确地指出了这一点。
敏捷测试
2001年2月,由17位在DSDM、XP、Scrum、FSD等领域的编程大师组成的代表团,共同制定和宣布了敏捷软件开发宣言。敏捷开发模式是一种软件幵发流程管理的新模式,明显区别与传统的文档驱动幵发的瀑布式开发模式。它更强调人的核心作用,采用迭代和循序渐进的开发方法。其中敏捷并不是专指开发速度,而是体现这种开发方式响应客户需求变化的速度。其核心价值观体现在:沟通、简单、反馈、勇气和尊重。敏捷开发其实并不是某种开发方法,而是某一类开发方法。而这壁开发方法都强调有效的沟通和交流,而不是仅仅纠结于文档,以便更早更快地发现问题,进而减小修复问题的成本和降低项目的风险。例如,Scrum和XP都是敏捷开发的具体方式,Scrum更倾向于过程管理,而XP更注重实践的作用。在实际中,也可以将两者结合起来应用。
而敏捷测试(Agile Testing)并不是与敏捷幵发同一个层面的定义,而是敏捷幵发中的一部分。区别于传统的测试理念,敏捷测试并不是独立于敏捷开发的一个阶段或者过程,而是与整个敏捷幵发中的其他活动紧密地交织在一起,使敏捷测试的思想贯穿于整个敏捷开发的各个环节。所以说,敏捷测试更多地体现的是一种理念,一种思路,或者说一种态度,只要是按照敏捷的核心价值观,在敏捷开发过程中幵展的测试活动都可以被称作是敏捷测试。
敏捷测试的重点是测试关注持续迭代的新特性,而不再适用传统测试过程中定义的测试阶段。由于敏捷开发的迭代周期明显比传统的开发周期要短,敏捷测试更强调要尽早开展测试活动,对软件质量进行及时的和持续的反馈。而在敏捷测试的过程中,整个团队合作是无缝隙的,以任务为导向而不以角色为导向,开发和测试人员共同对软件质量和项目进度负责,保证对产品质量的度量持续可见,而不仅仅专注于发现软件缺陷。测试人员可以积极参与或者支持原来开发人员主导的单元测试,而开发人员也将有力地支持测试人员的任务。
