V 模型：1980 年，Paul Rook（保罗•洛克）提出，旨在改进瀑布模型的开发效率和效果。“V”的左端表示传统的瀑布开发模型，而“V”的右端表明相应的测试阶段。
优点：
- V 模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确性，高层测试是为了整个系统满足用户的需求。
缺点：
W模型：基于尽早和不断测试的原则，W 模型既强调了测试方案设计，也强调了测试执行。
优点：
缺点：
H模型：真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量。为了解决 V 模型和 W 模型存在的问题，有专家提出了 H 模型。
特点：
-
它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。测试贯穿产品整个生命周期，与其他流程并发地进行。
-
软件测试不仅仅指测试的执行，还包括很多其他的活动（计划、需求分析、用例设计、环境搭建、提交缺陷、评估总结等）。
-
当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
-
软件测试要尽早准备，尽早执行。
-
软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
敏捷测试模型：
极限编程：
- 20 世纪 90 年代 Kent Beck 设计了一种名为极限编程（eXtreme Programming，XP）的新型软件开发方法。
极限测试：
- XP 模型需要客户参与，高度依赖模块的单元和验收测试。：
- 对任何一个递增的代码变更，开发人员都必须进行单元测试，以确保代码库满足其规格说明的要求。
- 单元测试完成后，用户进行验收测试。
基于 XP 的项目的步骤:
-
程序员与客户会晤，决定产品需求并建立使用场景。客户不在场时，程序员进行会晤，将需求分解为独立的任务，并估计完成每项任务所需的时间。程序员向客户提交任务清单和时间估计，并要求客户产生一个功能优先级清单。
-
每一对程序员依据应用程序的规格说明，对其编程任务生成单元测试用例。
-
编程小组依据程序员具备的能力，将任务分配给结对的程序员。两位程序员协同工作，在同一台机器开发代码库，对代码进行实时检查。所有代码归所有程序员所有。遵循一致的系统隐喻，所有的代码看上去都一致。每一对程序员完成其任务，编写出代码库。每一对程序员在所有单元测试通过之前，不断修改和重测他们的代码。所有的结对程序员每天都整合、集成他们的代码库。编程小组发布应用程序的一个预览版本
-
客户进行验收测试，要么确认该应用程序，要么提交一份报告指出存在的 bug或不足。程序员在验收测试成功的基础上发布一个产品版本。开发人员和编程小组可以随时接触客户，这样可以快速、准确地解决问题。
-
程序员根据最新的经验更新时间估计。
-
不允许加班。如果每周都全力工作了 25 小时，就不需要加班。在重大发布前的一星期例外。
总结：
-
敏捷测试是协同测试的一种形式，程序员结对编程，程序员分饰测试员角色，敏捷测试是连续测试。
-
敏捷测试侧重单元测试和验收测试。单元测试的过程是先设计单元测试用例，然后进行编码，之后执行测试。
-
敏捷测试强调客户参与，单元测试通过之后代码集成到代码库中，再由客户进行验收测试。
测试模型的使用：
测试模型小结
原文：https://www.cnblogs.com/qinzhenhong/p/12196688.html
