软件测试中不可忽略的阶段[3] 软件测试工具
What-How-Do
对于传统的瀑布生命周期模型来说，V模型常被错误地认为是要求开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。这样就无法支持迭代，自发性以及变更调整。例如，Brian Marickarick(《The Craft of Software Testing (Prentice Hall, 1995)》一书的作者)在“测试过程新模型”一文中提到，“V模型的问题在于一定要将系统开发过程分为具有严格边界的阶段，这使人们无法在这些边界之间交接和交换测试信息。”
情况其实并不是这样的，严格规定不是有效的开发人员和测试人员在应用各种模型过程中所采用的方式。实际上，各种模型只是简单地提醒我们，有必要定义一些必须要做什么(需求)--What，然后描述如何做(设计)--How，然后花很多力气来实现(编码)--Do。V模型所做的是强调每一个开发级别都有一个与之相关联的测试级别，并且建议测试应该在各级别之前进行设计。
各模型并没有规定工作量大小。有效的开发人员总是能将项目分解为可操作的小阶段，例如在迭代式开发中整个项目被分解为很多小片断，并忽略了各片段的实际大小。此时，模型的what-how-do顺序对于按时交付就具有重要意义，而且对于保证每一个阶段目标的实现也非常重要。
V模型所不能做的
V模型适用于所有类型的开发过程，但并不一定适用于开发和测试过程的所有方面。不管是GUI还是批处理、大型机还是Web、Java还是Cobol，都需要单元测试、集成测试、系统测试和验收测试。但是，V模型本身并不会告诉你如何定义单元测试或集成测试的内容、以如何顺利工作、如何进行具体的测试设计，以及该输入怎样的数据，输出怎样的输出结果才是正确的。
有些测试者认为：“是否使用V模型要看该所应用的项目。有些项目需要应用V模型，而有些项目不需要。可以只在需要V模型的项目中采用。”这样的做法实际上对任何模型都是有害的。我们应该尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没有实际意义。
例如，V模型的反对者经常声称V模型只有对需求非常明确，已经文档化了的项目才有用，因为所有的开发人员和测试人员都需要严格定义好的需求和设计来开展工作。对于当前很多文档需要事后补充，或者根本没有文档的做法下(这已成为一种开发的文化)，开发人员和测试人员都面临同样的困惑。在这种情况下，V模型的概念仍然是有用的，但在需求不明确的情况下更难应用，因为不管要开展什么工作，要测试什么，首先需要明确知道开发了什么。
V模型的反对者可能会声称V模型不适用于极限编程(XP)，在XP中提倡快速开发，结对编程，在编码之前就已完成测试用例。首先，我们提倡同时应用这两种方法，另外，也需要指出的是XP方法也强调在编程之前尽可能发现需求。
V模型没有明确说明需求和设计文档应如何定义，要定义多少文档，同时V模型也没有说明在各测试阶段如何进行测试设计。在采用XP策略的开发过程中，V模型的支持者认为，可以将单元测试应用于所划分的各个代码片段上，但V模型没有定义各单元测试之间应如何匹配。只在必要的时候，才需要进行集成测试，而最终意义上的集成测试也就是系统测试。尽管一些XP工作者将这些测试看作为“验收测试”，其实际目的只是希望降低让用户进行测试的必要性，同时又希望能确保系统在功能上满足用户业务的需要。
V模型的替代品--X模型? 软件测试
也许是由于V模型存在已有了一段时间，它曾带来过一定程度上的滥用，尤其是在那些Internet时代比较紧急的项目中。
Marick认为："我们对V模型的需要就象是鱼对自行车的需要一样。"在他的文章中提出了测试过程的新模型。他认为，有些测试要比商业行为更早些，而另外一些测试则要在更晚的时候得以进行。而且，V模型使人很难对不同阶段的系统描述进行综合。
V模型的支持者则认为，虽然在显示面前没有一个模型表现得无可挑剔，但在实践过程中，有些模型还是比较有用的。在下一篇中，我们将审视Marick所提倡的X模型。
文章来源于领测软件测试网 https://www.ltesting.net/