软件测试模型

　　了解了软件的开发模型之后随之而来的就是软件的测试模型了，常常可以听到这样的声音：“软件测试是伴随着整个软件开发的各个阶段的”，似乎应该是指的W模型，可是实际上就我目前短暂的工作经验来看测试工作真正走的从来都是下面的V模型。往往是开发人员分析需求直接上手开发，编码工作完成了，开发人员通知测试人员来测试，可是测试的内容是什么测试人员都不知道，还要去向开发人员来请教业务，这样的测试工程师就完全沦为了开发的小跟班，只能测出一些低级的问题。即使是在测试过程中会发现很多很烂的设计，也没有什么话语权！还是希望公司能尽早设立产品经理的角色，在软件开发前期的分析设计阶段投入更多的精力，也让软件测试能够真正参与到产品的前期分析设计工作中来，真正落实W的测试模型，不至于让测试人员沦为开发人员的小跟班，这样才能让产品质量更好，让测试人员站起身来！

V模型：为古老的瀑布模型，测试过程被加在开发过程的后半部分

单元测试：检测代码的开发是否符合详细设计的要求。

集成测试：检测此前测试过的各组成部分是否能完好地结合到一起。

系统测试：检测已集成在一起的产品是否符合系统规格说明书的要求。

验收测试：检测产品是否符合最终用户的需求。

V模型的缺陷 　
仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段 　　
忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。

 

w模型：增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

W模型的缺陷

但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。 　　

 

 

X模型：也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。

         　　

　　X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执 行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。 由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但 这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

 

 

H模型： 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。

 

这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程,例如设计流程或者编码流程。也就是说, 只要测试条件成熟了,测试准备活动完成了,测试执行活动就可以进行了。

H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备, 尽早执行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展