【软件测试】软件测试模型

目录

 

1.软件测试模型

1.1（传统的）瀑布模型

1.2 敏捷模型

1.3 （最广泛）V模型

1.4 W模型（双V模型）

1.5 X模型

1.6 H模型

---

1.软件测试模型

1.1（传统的）瀑布模型

软件测试生命周期：项目计划->需求分析->架构设计->详细设计->编码->测试

 

项目计划阶段：主要是制定项目总体研发计划，树立项目里程碑节点，输出项目计划书；

需求分析阶段：明确客户的需求定义，并对这个定义进行清晰的描述，是充分理解客户需求，描述产品功能的重要阶段，这个阶段会输出产品的需求规格说明书；

架构设计与详细设计阶段：则会根据需求的定义，来确定产品实现的方案，包括定义软件硬件的结构，组建模块的实现方法，接口、界面、数据如何进行组织，这个阶段会输出包括概要设计，详细设计在内的多份说明书；

编码：这个阶段是开发团队根据需求和设计具体实现我们的产品，来根据编程规范，构建我们的组件模块，最后输出我们的产品版本；

软件测试阶段：则是通过独立的测试小组或者QI团队评估我们的产品是否满足需求的定义，最后输出测试结果报告，

优点：

       强调需求，设计的作用；

　　前一阶段完成后只需关注后续阶段；

　　为项目提供按阶段划分的检查点，里程碑清晰

　　文档规范

         瀑布模型适合用于小项目，不会有很大的需求变化

缺点：

　　线性研发过程难以适应需求的频繁变化，

　　项目周期后段才可看到成果，用户要到末期才能看到开发结果，增加了开发的风险

　　强制的里程碑，对于开发过程中出现的变化，适应能力较差，

　　文档工作量较大，测试在项目的后期，文档的开发带来很大的工作量。

1.2 敏捷模型

简单来理解，瀑布模型就是按照规划一步一步去完成一个项目，敏捷开发就是一边开发一边交互迭代测试。

优势：

       开发的阶段性成果会在开发过程中尽早的进行审查，项目的风险会降低；

       适用于需求不明确情况，因为需求不明确，所以需要在不断迭代的过程中来逐步理清需求。

       灵活性较高，几乎可以在任何时间进行需求变更；

       敏捷鼓励开发人员与业务用户之间进行多频次的沟通，业务用户的不合理需求以及开发人员的错误理解都会在这些频繁的沟通中进行不断审查和更新，

       敏捷的协作通常要高得多，通常能开发出更高质量的产品；

       适用于快速变化的项目，特别是面向前端业务人员的CRM项目更容易根据业务的变化而变化。

劣势：

       敏捷的概念接受度还不算太高，初次尝试可能不会非常成功；

       最终交付的内容无法预测，预期和实际完成的内容经常会有很大差异；

       敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。 业务和IT人员在沟通前需要做大量的准备工作，但很多情况下业务的沟通时间无法保证；

       当存在乙方供应商的情况，敏捷会面临更大的挑战性。 客户通常希望尽早了解他们的项目投入。 预估项目时间和成本难度较高；

       在敏捷项目中，最大的问题可能是业务部门永远不希望有最终的截止时间。
 

1.3 （最广泛）V模型

软件测试生命周期：需求分析->概要设计->详细设计->软件编码->单元测试->集成测试->系统测试->验收测试

　　瀑布模型的变种。

单元测试、集成测试：检测程序是否满足我们设计上的要求；

集成测试：在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。

系统测试：在功能、性能这些质量特性上是否能够满足我们系统要求的指标；

系统测试包括：冒烟测试 系统测试 回归测试

（1）冒烟测试：主干流程测试，确认软件的基本功能正常，可以进行后续的测试工作

（2）系统测试：是检测系统的功能、质量、性能能否满足系统的要求，包括功能、性能、界面、可靠性、兼容性等等，是黑盒测试

（3）回归测试：修改了旧代码之后重新进行测试，确认修改后的代码没有引入新的错误或导致其他代码产生新的错误

验收测试：确定软件是否满足用户的一些需求，以及合同的一些规定；

优点：

　　在V模型里，强调软件开发的协作和速度，反应测试活动和分析测试的关系，并且将软件的实现和验证有机的结合了起来，V模型，明确的界定测试过程是存在不同阶段的。

缺点：

　　但是V模型也有一定的局限性,它仅仅把测试过程放在需求分析、系统设计、编码之后的一个阶段，忽视了测试对于需求的分析和验证。我们对需求的验证，对系统设计的验证，到后期的验收测试才有可能被发现，对于我们测试当中的测试需要尽早进行的原则在V模型中没有体现，这是V模型的局限。

1.4 W模型（双V模型）

优点：

       开发与测试并行，有利于尽早发现问题，有利于及时的了解项目的测试风险，来及早的执行相应的应对方案，加快项目的进度。

缺点：

       需求、设计、编码仍然是串行进行的，测试和开发保持线性的关系，上一个阶段完成之后才能进行下一个阶段，不能够很好的支持迭代的开发模型。

1.5 X模型

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

　　左边描述的是针对单独的程序片段相互分离的编码和测试，此后进行频繁的交接，再通过集成，最终合成可执行的程序，对这些程序进行测试，这些程序还是需要冀衡测试，已经通过的程序可以进行封板提交给用户，也可以作为更大集成的一部分，X模型还定位了探索式测试，探索式测试是不进行事先计划的特殊类型的测试，能够帮助测试人员在测试计划之外发现更多的错误。

1.6 H模型

　　把软件测试看成一个完全独立的流程，与其他流程并发进行，比如设计流程，编码流程，甚至是测试流程，

　　H模型强调把测试分为测试准备和测试执行两个不同的阶段，只要由于其他流程的进展引发了测试就绪点的到位，这时候，只要测试准备不能完成，测试执行活动就可以或者需要开展，在H模型当中，测试是一个完全独立的模型，所以可以和其他的流程交叉地进行，也便于我们尽早的执行测试。