软件产品的质量模型

  • 功能性：能够满足明确和隐含要求的功能
  • 可靠性：能够处理异常情况，在错误中很快恢复
  • 易用性：易懂、易学、易用、漂亮好看
  • 效率性：占用少量的资源，提供适当的性能
  • 维护性：是指产品可被修改的能力
  • 可移植：是指软件产品从一种环境迁移到另外一种环境

软件测试的常见分类

是否覆盖源代码

  • 黑盒测试
  • 白盒测试
  • 灰盒测试

按照阶段划分

  • 单元测试：对软件中最小的可测单元进行的测试。
  • 集成测试：在单元测试的基础上，对多个单元组装后的产物进行测试。
  • 系统测试：在集成测试的基础上，把软件看作一个整体进行测试。
  • 验收测试：也叫交付测试，以最终用户的角度确认软件是否符合预期。

是否运行

  • 静态测试
  • 动态测试

是否自动化

  • 手工测试
  • 自动化测试

其他分类

  • 冒烟测试：对基本功能、主要功能进行的测试，避免测试资源的浪费
  • 回归测试：对BUG或测试用例进行回归测试
  • 随机测试：假设第一次接触软件进行测试，避免惯性思维
  • 探索测试：同时做测试设计和测试执行，探索复杂场景，容易被忽略的场景

软件开发常见模型

  • 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。
  • 软件工程的主要环节包括人员管理、项目管理、需求分析、系统设计、程序设计、测试、维护等。软件开发模型是对软件过程的建模，即用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，好比工厂的生产线。

1. 边做边改模型（Build-and-Fix Model）

许多产品都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

alt

2. 瀑布模型（Waterfall Model）

1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

瀑布模型中，如图所示，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；

（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

alt

3. 快速原型模型（Rapid Prototype Model）

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

4. 增量模型（Incremental Model）

增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：

（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。 alt

5.螺旋模型（Spiral Model） 如图所示，螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3） 实施工程：实施软件开发和验证；

（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

（1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。

（2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。

（3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

alt

6.喷泉模型（fountain model）(也称面向对象的生存期模型, OO模型)

喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。

alt

7.智能模型(四代技术（4GL）)

智能模型拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等），每个工具都能使开发人员在高层次上定义软件的某些特性，并把开发人员定义的这些软件自动地生成为源代码。

alt

软件测试常见模型

（1）V模型

  • 设计原理：将测试工作，分阶段完成

  • 优点：将复杂的测试工作分成了目标明确的小阶段完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的底层测试也包含了对于软件需求的高层测试。

  • 缺点：只能在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患。

alt

（2）W模型

  • 设计原理：扩大测试范围

  • 优点：测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早全面的发现问题。

  • 缺点：它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目。

alt

（3）H模型

  • 设计原理：H模型的设计原理是将测试活动完全独立了出来，形成一个完全独立的流程，这个流程将测试准备活动和测试执行活动清晰的体现出来。测试流程和其他工作流程是并发执行的，只要某一个工作流程的条件成熟就可以开始进行测试。

  • 优点：

    1. 开发的H模型揭示了软件测试除测试执行外，还有很多工作；

    2. 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；

    3. 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；

    4. 软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

  • 缺点：

    1. 管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；

    2. 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；

    3. 测试就绪点分析困难：测试很多的时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；

    4. 对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。

alt

（4）X模型

  • 设计原理：X模型的设计原理是将程序分成多个片段反复迭代测试，然后将多个片段集成再进行迭代测试。

  • 优点：对单独程序片段进行的相互分离的编码和测试，保证了测试效果。增加了探索测试，可以帮助测试人员发现计划之外的软件错误。

  • 缺点：频繁的集成会增加测试成本；探索测试对测试人员要求更高。

alt

软件缺陷

软件或程序中存在的各种问题及错误

  • 未达到需求规格说明书标明的功能
  • 出现了需求指明不会出现的错误
  • 超出了需求的范围
  • 未达到需求虽未指明，但应达到的目标
  • 软件难以理解，不易使用，运行速度慢