开发和测试的目的相同都是为了制造出高质量的软件；又有相辅相成的作用，开发经验对测试有用，测试经验对开发有用；但侧重点不同，开发是偏重于从无到有，而测试是从有到优
一、开发模式
-
瀑布模型
-
特点
-
阶段间具有顺序性与依赖性
前一阶段的输出文档就是后一阶段的输入文档，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果
-
推迟实现
对于规模较大的软件项目来说，往往编码开始的越早，最终完成开发所需时间越长。 因为前面阶段的工作没做或做的不扎实，过早地考虑进行程序实现， 往往导致大量返工，有时甚至发生无法弥补的问题
瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现
清楚的区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想
-
质量保证的观点
为了保证所开发的软件的质量，在瀑布模型的每一个阶段都应坚持两个重要做法 ①每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务 ②每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误 传统的瀑布模型过于理想化，实际的瀑布模型是带"反馈环"的。当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品后再回来继续完成后面阶段的任务
瀑布模型是文档驱动的模型，遵守这个约束可以使软件维护变得比较容易一些，降低软件预算
-
-
优缺点
- 优点
- 为项目提供了按阶段划分的检查点
- 当前一阶段完成后，只需去关注后续阶段
- 可以在迭代模型中应用瀑布模型
- 缺点
- 不适合需求模糊或需求经常变动的系统
- 由于开销的逐步升级问题，它不希望存在早期阶段的反馈
- 在一个系统完成以前，它无法预测一个新系统引入一个机构的影响
- 在用户可能需要较长等等时间来获取一个可供使用的系统，也许会给用户的信任程度带来影响和打击
- 最终产品往往反映用户的初始需求而不是最终需求
- 优点
-
-
快速原型
快速原型模型不带反馈环，软件产品的开发基本上是线性顺序进行的 快速原型的本质是"快速"。开发人员应尽可能地建造出原型系统，以加速软件开发过程，节约软件开发成本 原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃
-
特点
快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集 快速原型模型是增量模型的另一种形式，在开发真实系统之前，迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，在该原型的基础上，逐渐完成整个系统的开发工作 它允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护
-
优缺点
-
优点
克服瀑布模型的缺点，减少由于软件需求不明确的带来开发风险，适合预先不能确切定义需求的软件系统的开发
-
缺点
所选用的开发和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量底下，使用前提是要有一个展示性的产品原型，一定程度上可能会限制开发人员的创新
-
-
-
增量模型
-
把瀑布模型的顺序特征与快速原型法的迭代特征相结合 将软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量
-
优缺点
-
优点
能在较短的时间内向用户提交可完成部分工作的产品 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整
-
缺点
由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程
-
作用
- 开发初期的需求定义只是用来确定软件的基本结构，使得开发初期用户只需要对软件需求进行大概的描述；而对于需求的细节性描述，则可以延迟到增量构件开发时进行，以增量构件为单位逐个地进行需求补充。这种方式能够有效适应用户需求的变更
- 软件系统可以按照增量构件的功能安排开发的优先顺序，并逐个实现和交付使用。不仅有利于用户尽早用上系统，能够更好地适应新的软件环境，而且在以增量方式使用系统的过程中，还能获得对软件系统后续构件的需求经验
- 软件系统是逐渐扩展的，因此开发者可以通过对诸多构件的开发，逐步积累开发经验。实际上，增量式开发还有利于技术复用，前面构件中设计的算法、采用的技术策略、编写的源码等，都可以应用到后面将要创建的增量构件中去
- 增量式开发有利于从总体上降低软件项目的技术风险。个别的构件或许不能使用，但一般不会影响到整个系统的正常工作
- 实际上，在采用增量模型时，具有最高优先权的核心增量构件将会被最先交付，而随着后续构件不断被集成进系统，这个核心构件将会受到最多次数的测试。这意味着软件系统最重要的心脏部分将具有最高的可靠性，这将使得整个软件系统更具健壮性
-
-
-
螺旋模型
-
描述
-
带箭头的点划线
长度代表当前累计的开发费用
-
螺旋线的角度值代表开发进度
-
螺旋线的每个周期对应于一个开发阶段
-
四个象限代表了以下活动
- 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
- 风险分析：分析评估所选方案，考虑如何识别和消除风险
- 实施工程：实施软件开发和验证
- 客户评估：评价开发工作，提出修正建议，制定下一步计划
-
-
优缺点
螺旋模型在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定 螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统
- 优点
- 设计灵活可以在项目各个阶段进行变更
- 风险驱动,每个项目上线前都要进行风险分析
- 缺点
- 螺旋模型强调风险分析,需要相当丰富的风险评估经验和专门知识,在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失
- 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义
- 优点
-
使用场景
适合使用大规模的软件项目
-
二、测试模式
-
V模型
V模型和瀑布模型有一些共同的特性，V模型中的过程从左到右，描述了基本的开发 过程和测试行为
-
说明
- 单元测试：模块测试，验证软件的基本组成单位的正确性
- 集成测试：模块间的测试，测试接口是否正确
- 系统测试：包括冒烟测试、系统测试、回归测试；检测系统的功能、质量、性能能否满足系统的要求，包括功能、性能、界面、可靠性、兼容性等
- 冒烟测试：主干流测试，确认软件的基本功能能否正常，可以进行后续的测试工作
- 回归测试：修改了旧代码之后重新进行测试，确认修改后的代码没有引入新的错误或导致其它代码产生新的错误
- 验收测试：确保软件的实现能否满足用户的需求或合同的需求
-
优缺点
-
优点
每个阶段都清晰明了，便于控制开发的每个过程，即包含单元测试又包含系统测试
-
缺点
测试介入较晚，对于前期的一些缺陷无从发现和修改、测试和开发串行，总用时较长
-
-
-
W模型（双V模型）
V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试” 的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W 模型（如下图）。在模型中不难看出，开发是“V”，测试是与此并行的“V”。 W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题
-
优缺点
-
优点
测试伴随软件的整个生命周期,例如,在需求分析结束后就可以进行需求分析测试、 测试于开发是并行独立进行
-
缺点
对需求和测试技术要求高 适用于大中型企业
-
-
-
H模型
H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行
- 优缺点
- 优点
- 开发的H模型揭示了软件测试除测试执行外，还有很多工作
- 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行
- 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性
- 缺点
- 管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制
- 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小
- 测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难
- 优点
- 优缺点