软件测试的模型
按测试模式来分类： 瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。
1、（传统的）瀑布模型：
项目计划->需求分析->软件设计->程序开发->软件测试->集成维护
项目计划阶段：主要是制定项目总体研发计划，树立项目里程碑节点，输出项目计划书；
需求分析阶段：明确客户的需求定义，并对这个定义进行清晰的描述，是充分理解客户需求，描述产品功能的重要阶段，这个阶段会输出产品的需求规格说明书；
软件设计阶段：则会根据需求的定义，来确定产品实现的方案，包括定义软件硬件的结构，组建模块的实现方法，接口、界面、数据如何进行组织，这个阶段会输出包括概要设计，详细设计在内的多份说明书；
程序开发阶段：这个阶段是开发团队根据需求和设计具体实现我们的产品，来根据编程规范，构建我们的组件模块，最后输出我们的产品版本；
软件测试阶段则是通过独立的测试小组或者QI团队评估我们的产品是否满足需求的定义，最后输出测试结果报告，
集成维护阶段则是产品经过测试以后，交付给用户，根据用户的使用情况，再对产品进行维护，及必要的修改升级等操作。
优点：
- 强调需求，设计的作用；
- 前一阶段完成后只需关注后续阶段；
- 为项目提供按阶段划分的检查点，里程碑清晰
- 文档规范
缺点：
- 线性研发过程难以适应需求的频繁变化，
- 项目周期后段才可看到成果，用户要到末期才能看到开发结果，增加了开发的风险
- 强制的里程碑，对于开发过程中出现的变化，适应能力较差，
- 文档工作量较大，测试在项目的后期，文档的开发带来很大的工作量。
2、V模型（最广泛）
需求分析->概要设计->详细设计->软件编码->单元测试->集成测试->系统测试->验收测试
瀑布模型的变种。
单元测试，集成测试：检测程序是否满足我们设计上的要求；
系统测试：在功能、性能这些质量特性上是否能够满足我们系统要求的指标；
验收测试：确定软件是否满足用户的一些需求，以及合同的一些规定；
优点：
在V模型里，强调软件开发的协作和速度，反应测试活动和分析测试的关系，并且将软件的实现和验证有机的结合了起来，V模型，明确的界定测试过程是存在不同阶段的。
缺点：
但是V模型也有一定的局限性,它仅仅把测试过程放在需求分析、系统设计、编码之后的一个阶段，忽视了测试对于需求的分析和验证。我们对需求的验证，对系统设计的验证，到后期的验收测试才有可能被发现，对于我们测试当中的测试需要尽早进行的原则在V模型中没有体现，这是V模型的局限。
3、W模型（双V模型）
优点：开发与测试并行，有利于尽早发现问题，有利于及时的了解项目的测试风险，来及早的执行相应的应对方案，加快项目的进度。
局限性：需求、设计、编码仍然是串行进行的，测试和开发保持线性的关系，上一个阶段完成之后才能进行下一个阶段，不能够很好的支持迭代的开发模型。
4、X模型
解决交接和频繁集成周期的问题
左边描述的是针对单独的程序片段相互分离的编码和测试，此后进行频繁的交接，再通过集成，最终合成可执行的程序，对这些程序进行测试，这些程序还是需要冀衡测试，已经通过的程序可以进行封板提交给用户，也可以作为更大集成的一部分，X模型还定位了探索式测试，探索式测试是不进行事先计划的特殊类型的测试，能够帮助测试人员在测试计划之外发现更多的错误。
5、H模型：
把软件测试看成一个完全独立的流程，与其他流程并发进行，比如设计流程，编码流程，甚至是测试流程，
H模型强调把测试分为测试准备和测试执行两个不同的阶段，只要由于其他流程的进展引发了测试就绪点的到位，这时候，只要测试准备不能完成，测试执行活动就可以或者需要开展，在H模型当中，测试是一个完全独立的模型，所以可以和其他的流程交叉地进行，也便于我们尽早的执行测试。