软件开发模型和软件测试模型
V模型、W模型、瀑布模型、 H模型、快速原型模型（敏捷开发）、X模型
软件开发模型
边写边改模型
当一个软件产品格说明或主要设计的情况下被开发时，开发者往往不得不重新对产品编码多次直到他们得到正确稳定的产品。这种开发模型就是边做边改模型。
开发者们首先开发出一个产品的最初版本给客户验收，然后开发团队开发一个新的版本再次给客户验收。这个过程一直持续到客户感觉产品满意为止
瀑布模型
瀑布模型规定了各项软件工程活动，包括制定开发计划、需求分析说明、软件设计、程序编码、测试和运行维护，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级落下。它具有以下特征：
1.从上一项活动接受本项活动的丄作对象作为输入
2.利用这一输入实施本项活动应完成的工作
3.给出本项活动的工作结果，作为输出传递给下一项活动
对本项活动实施的工作进行评审，若工作得到确认则继续进行下一项活动，否则返回前一项活动，甚至更前项工作进行返工
瀑布模型的优缺点
优点
- 开发的各个阶段比较清晰
- 强调早期计划及需求调查
- 适合需求稳定的产品开发
缺点
- 依赖于早期的需求调查，不适应需求的变化；
- 单一流程不可逆；
- 风险往往延至后期才显露，失去及早纠正的机会；
- 问题在项目后期才开始暴露；
- 前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败。
快速原型模型
快速原型模型又称为敏捷开发模型。其核心是以人为本，适用变化。
在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。
第一步是建造一起快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化开发软件的需求。通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正需求是什么。
第二步是在第一步的基础上开发出用户满意的软件产品。
| 优点 | 1. 克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。 2. 适合预先不能确切定义需求的软件系统的开发。 |
|---|---|
| 缺点 | 1. 不适合大型系统的开发（适合开发小型的、灵活性高的系统）。 2. 前提要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。 |
螺旋模型
螺旋模型将瀑布模型和原型模型结合起来，不仅体现了两个模型的优点，而且还增加了两个模型都忽略了的风险分析，弥补了两者的不足。沿螺旋线向外每旋出一圈便开发一个更为晚上的新的软件版本，并且进行风险评估。
| 软件开发模型 | 优缺点 | 适用场景 |
|---|---|---|
| 边写边改模型 | 1. 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改； 2. 忽略需求环节，给软件开发带来很大的风险； 3. 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。 |
某些场合这种简单的方式非常有用。对需求简单和容易明白，软件期望的功能行为容易定义，实现的成功或失败容易检验的工程可以使用这种模型 |
| 瀑布模型 | 1. 为项目提供了按阶段划分的检查点； 2. 当前一阶段完成后，只需要去关注后续阶段。 3. 可在迭代模型中应用瀑布模型。 1. 在项目的各个阶段极少有反馈； 2. 只有在项目生命周期的后期才能看到结果；3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 |
a. 用户的需求非常清楚全面，在开发过程中没有或很少变化： b. 开发人员对软件的应用领域很熟悉 c. 用户的使用环境非常稳定； 4. 开发工作对用户参与的要求很低。 |
| 快速原型模型 | 1. 可以得到比较良好的需求定义，容易适应需求的变化； 2. 有利于开发与培训的同步 3. 开发费用低、开发周期短且对用户更友好。 1. 客户与开发者对原型理解不同； 2. 准确的原型设计比较困难； 3. 不利于开发人员的创新。 |
a. 对所开发的领域比较熟悉而且有快速的原型开发工具； b. 项目招投标时，可以以原型模型作为软件的开发模型； c. 进行产品移植或升级时，或对已有产品原型进行客户化工作时。 |
| 螺旋模型 | 1. 设计上的灵活性，可以在项目的各个阶段进行变更； 2. 以小的分段来构建大型系统，使成本计算变得简单容易； 3. 客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性； 4. 随着项目推进，客户始终掌握项目的最新信息，从而能够和管理层有效地交互 5. 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目中，如果未能及时识别风险，势必造成重大损失 6. 过多的迭代次数会增加开发成本，延迟提交时间 |
螺旋模型只适合于大规模的软件项目 |
软件测试模型
V模型
V模型：需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试
V模型的优缺点
| 优点 | 1. 包含了底层测试（单元测试）和高层测试（系统测试）； 2. 清楚地标识了开发和测试的各个阶段，每个阶段都与开发的各个阶段相对应； 3. 每个阶段分工明确，便于整体项目的把控。 |
|---|---|
| 缺点 | 1. 测试工作只在需求分析、系统设计及编码之后，不能及时发现并修改错误； 2. 测试的对象仅仅是程序，忽略了需求分析，系统设计的测试验证，很可能到最后的验收测试才发现需求和系统设计的错误； 3. 过程是线性的，不能反复迭代和测试 |
W模型
W模型：用户需求-需求分析-概要设计-详细设计-编码-单元测试-集成测试-验收测试-单元测试设计-集成测试设计-系统测试设计-验收测试设计-集成-实施-交付。
W模型的优点和局限性
| 优点 | 1. 测试伴随着整个开发周期，需求和设计同样要测试; 2. 更早的介入测试，可以发现初期的缺陷，修复成本低； 3. 分阶段工作，方便项目整体管理。 |
|---|---|
| 局限性 | 1. 需求、设计、编码等活动被视为串行的，开发和测试依然是线性的关系，上一阶段工作完全结束，才可正式开始下一个阶段工作； 2. 每一阶段都要有文档，没有文档根本无法执行w模型； 3. 对于需求和设计、项目组成员的技术的要求很高，实践起来困难。 |
H模型
H模型：测试准备-测试就绪点-测试执行-测试流程-其他流程。
H模型是为了解决V模型和W模型存在的问题，尤其是线性问题，导致无法重复迭代和测试的问题。
特点：
- 它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。测试贯穿整个生命周期，与其他流程并发地进行。
- 软件测试不仅仅指测试的执行，还包括很多其他的活动(如计划、需求分折、用例设计、环境搭建、提交缺陷、评估总结等)
当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。 - 软件测试要尽早准备，尽早执行。
- 软件测试是根据被测物的不同而分层次进行的，不同层次的测试话动可以是按照某个次序先后进行的，但也可能是反复的。
优点：
（1）介入早，与开发并行，更早的发现问题
（2）测试过程是独立于开发过程，更客观和主动的
X模型
X模型：程序片段1-测试设计-工具配置-执行测试-编码完成-执行测试-工具配置-测试设计-程序片段N；封版-执行测试-测试设计-工具配置-迭代1…N-探索式测试-执行测试
X模型是对V模型的改进。
X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。
右上半部分，这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。
多根并行的曲线表示变更可以在各个部分发生。
X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。
软件笔试题经常会看到V模型上的几种测试方法。
测试阶段
软件测试按测试阶段可以划分为以下几个测试，这个也是
1、单元测试
又称模块测试，针对软件设计中的最小单位-- 桩模块，进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
2、集成测试
又叫组装测试。集成测试主要用来测试模块与模块之间的接口，同时还要测试一些主要业务功能。重点测试不同模块的接口部分。
集成测试界於单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。
3、系统测试(system testing)：
系统测试是将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。
系统测试在系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。
系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
4、验收测试
α测试：Alpha是内测版本，即现在所说的C8。通常只在软件开发者内部交流，α测试主要看有没有功能缺失或系统错误。也有很少一部分发布给专业测试人员。
β测试：Beta是公测版本，是对所有用户开放的测试版本。主要是看用户对软件外观、使用方便等的反应。给用户测的目的一方面是使最终产品尽可能地满足用户的需要，另一方面也尽量成少了软件中的bug。
λ测试：Camma版本，指的是软件版本正式发行的候选版。该版本已经相当成熟了，与即将发行的正式版相差无几，成为正式反布的候选版本。
简单来说，α测试主要是测试人员在开发环境下的测试，β测试是在实际环境中的测试。
从测试设计方法可以划分为
黑盒测试不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。一般会有一个输入值，一个输入值，和期望值做比较。
白盒测试主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑结构，测试手段有：语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖。
灰盒测试介于黑盒和白盒之间