软件开发过程模型

软件开发过程模型

在软件开发的七年实践中，人们总结了很多软件开发模型用来描述和表示一个复杂的开发过程，如：

软件测试与软件的开发模式有着紧密的联系，作为一名测试人员，应该充分理解软件的开发模式，以便找准自己在其中的位置，从而发挥自身的价值。

软件瀑布模型

1、是线性模型的一种，在所有模型中占有重要地位，是所有其他模型的一个基础。

2、每一个阶段执行一次，按线性顺序进行软件开发。

测试的切入点：

测试阶段处于软件实现后，必须在代码完成后留出足够的时间给测试活动，否则将导致测试不充分，很多问题到项目后期才暴露

瀑布模型的优缺点

优点：

1 开发的各个阶段比较清晰。

2 强调早期计划及需求调查。

3 适合需求稳定的产品开发。

缺点：

1、依赖于早期的需求调查，不适应需求的变化。

2、单一流程不可逆。

3、风险往往延至后期才显露，失去及早纠正的机会。

4、问题在项目后期才开始暴露。

5、前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败。

改良：

沿用瀑布模型的线性思想，细化了各个阶段，在某些重要关注的阶段之间掺入迭代的思想。

软件快速原型模型

在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。

第一步是建造一个快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正需求是什么。

第二步是在第一步的基础上开发出用户满意的软件产品。

快速原型模型的优缺点

优点：

克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。适合预先不能确切定义需求的软件系统的开发。

缺点：

不适合大型系统的开发（适合开发小型的、灵活性高的系统）。前提要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

软件螺旋模型

螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，螺旋模型沿着螺旋线旋转，即在坐标的4个象限上分别表示了4个方面的活动，如图所示：制定计划，风险分析，实施开发，客户评估

软件测试简介

每个系统的成型，上线都离不开测试,软件测试是伴随着软件的产生而产生的，早期的软件开发过程中软件规模都很小、复杂程度低,软件开发的过程混乱无序、相当随意,测试的含义比较狭窄,开发人员将测试等同于“调试”,目的是纠正软件中已经知道的故障,常常由开发人员自己完成这部分的工作。对测试的投入极少,测试介入也晚,常常是等到形成代码,产品已经基本完成时才进行测试。到了上世纪80年代初期,软件和IT行业进入了大发展,软件趋向大型化、高复杂度,软件的质量越来越重要，软件测试概念。

要点

1、软件测试与软件工程息息相关，软件测试是软件工程组成中不可或缺的一部分。

2、在软件工程、项目管理、质量管理得到规范化应用的企业，软件测试也会进行得比较顺利，软件测试发挥的价值也会更大。

3、要关注软件工程、质量管理以及配置管理与软件测试的关系；在不同的开发模式下，如何进行软件测试。

软件测试的历史及定义

1957年之前－调试为主(Debugging Oriented)

1957–1978－证明为主(Demonstration Oriented)

1979–1982－破坏为主(Destruction Oriented)

1983–1987－评估为主(Evaluation Oriented)

1988–至今－预防为主(Prevention Oriented)

调试为主

20世纪50年代，计算机刚诞生不久，只有科学家级别的人才会去编程，需求和程序本身也远远没有现在这么复杂多变，相当于开发人员一人承担需求分析，设计，开发，测试等所有工作，当然也不会有人去区分调试和测试。然而严谨的科学家们已经在开始思考 “怎么知道程序满足了需求？”这类问题了。证明为主

1957年，Charles Baker在他的一本书中对调试和测试进行了区分：

调试(Debug)：确保程序做了程序员想它做的事情

测试(Testing)：确保程序解决了它该解决的问题

这是软件测试史上一个重要的里程碑，它标志测试终于自立门户师出有名了。当时计算机应用的数量，成本和复杂性都大幅度提升，随之而来的经济风险也大大增加，测试就显得很有必要了，这个时期测试的主要目就是确认软件是满足需求的，也就是我们常说的“做了该做的事情”。

破坏为主

1979年，《软件测试的艺术》 (The Art of Software Testing)第一版问世，这本书是测试界的经典之作。书中给出了软件测试的经典定义：

测试是为发现错误而执行程序的过程。

这个观点较之前证明为主的思路，是一个很大的进步。我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。

评估为主1983年，美国国家标准局提出了测试界很有名的两个名词：验证(Verification)和确认(Validation)。人们提出了在软件生命周期中使用分析，评审，测试来评估产品的理论。软件测试工程在这个时期得到了快速的发展：出现测试经理(test manager)，测试分析师(test analyst)等职称。

开展正式的国际性测试会议和活动

发表大量测试刊物发布相关国际标准以上种种都预示着：软件测试正作为一门独立的，专业的，具有影响力的工程学发展起来了。

预防为主

预防为主是当下软件测试的主流思想之一，STEP(Systematic Test and Evaluation Process)是最早的一个以预防为主的生命周期模型，STEP认为测试与开发是并行的，整个测试的生命周期也是由计划，分析，设计，开发，执行和维护组成，也就是说，测试不是在编码完成后才开始介入，而是贯穿于整个软件生命周期。我们都知道，没有100%完美的软件，零缺陷是不可能的，所以我们要做的是：尽量早的介入，尽量早的发现这些明显的或隐藏的bug，发现得越早，修复起来的成本越低，产生的风险也越小。

软件测试的测试对象

软件测试的对象不仅仅是程序测试,软件测试的对象包括：程序、数据、文档。目标程序和源程序都属于程序。

五大要素和两个目标：

五大要素有：质量、人员、资源、流程、技术。

其中最主要的是软件质量，其他四个要素都是为质量服务的。

其次是人员，决定了技术，资源，流程，以及配置和使用。

技术包含了：软件测试技术、软件测试方法、使用的工具。技术是手段。

流程：测试计划，测试用例，测试执行，测试报告。有一些进入进出的标准（规范性，对软件测试做一个规范的要求）。

资源：测试所需要的硬件设备、网络环境、测试设备、测试时间（周期）。

注意：人不是资源。

目标：

1、提升测试覆盖率-> 能够有效的保证软件的质量。

2、提升测试效率->能够使我们更好地完成软件测试。

软件测试所遵循的原则

一、测试显示缺陷的存在，但不能证明系统不存在缺陷

经过软件测试，可以发现软件中的故障；但是经过软件测试，不能保证软件就没有故障了。

二、穷尽测试是不可能的，应设定及时终止的条件

三、测试应该尽早进行

四、缺陷具备群集特性

越是发现问题多的模块，越是需要重点测试的对象

五、测试的杀虫剂悖论

在测试中，如果采用同样的测试用例，同样的测试方法。多次重复的测试某一个模块，最后就不能再发现新的缺陷。所以说，测试用例和测试方法应该不定期的评审修改，并且增加不同的测试方法和用例来测试不同的部分，从而更多的发现软件的缺陷。

六、测试的二八原则

测试时间和资源往往是有限的，要找出所有的缺陷是不可能的，这时我们需要遵循二八原则。

把80%的时间或者资源用在20%的重点模块上，重点测试模块中20%的重要模块。来达到测试效率和资源配置的最佳的比例。

七、测试活动依赖于测试背景

针对不同的测试背景针对的活动是不同的，比如：电信级的软件对性能、大并发量的访问会有更高的要求。而金融，银行系统相关的软件，对安全性能要求更高。

设计系统测试计划需要参考的项目文挡有哪些？

【软件需求】是软件开发之前做好的，软件开发是根据这个做的，那么软件测试自然也需要参考该文件。

【迭代计划】是软件的某个周期的计划，自然也需要参考。

【可行性】是软件开发前做好，用于证明该计划可行的，没有必要参考。

测试的目的

1、测试是程序的执行过程，目的在于发现错误。

2、一个好的测试用例在于能发现至今未发现的错误。

3、一个成功的测试是发现了至今未发现的错误的测试。

测试模型

随着测试过程的管理和发展，测试人员通过大量的实践，从而总结出了不少测试模型，如常见的V模型、W模型、H模型等。这些模型与开发紧密结合，对测试活动进行了抽象，成为了测试过程管理的重要参考依据。

测试模型之V模型

简介：

RAD（Rap Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件测试的V模型，V模型大体可以划分为以下几个不同的阶段步骤：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

要点

1、V模型是最具有代表意义的测试模型，最早是由Paul Rook在20世纪80年代后期提出，由英国国家计算机中心文献中发布，旨在改进软件开发的效率和效果；

2、V模型推出之前，人们通常把测试过程作为在需求分析、概要设计、详细设计、编码全部完成之后的一个阶段，尽管当时已经出现了测试工作会占用这个项目周期一半的时间，但是大多数人认为测试只是一个收尾工作；V模型在这个时候推出，就是为了改变之前行业的普遍认识。

3、V模型本身是软件开发中瀑布模型的变种，它反映了测试活动与分析和设计的关系。

4、V模型标明了测试过程中本身存在的不同阶段，从左到右，描述了开发过程和测试过程间的阶段对应关系。

1、需求分析：用户需求、业务需求、需求规格说明书

2、概要设计：系统架构、模块划分、模块与模块之间的接口。

3、详细设计：模块内部实现的逻辑和方法。

4、编码：实现上面的设计。

5、单元测试：检测代码的开发是否符合详细设计的要求。

6、集成测试：检测此前测试过的各组成部分是否能完好地结合到一起。

7、系统测试：检测已集成在一起的产品是否符合系统规格说明书的要求。

8、验收测试：检测产品是否符合最终用户的需求。

V模型的优点

测试V模型即包含了底层测试又包含了高层测试；

底层测试：检验源代码质量的测试，如：单元测试；

高层测试：检验整个系统的需要，如：系统测试；

V模型清楚地标识出了软件开发的阶段。

它采用自顶向下逐步求精的方式把整个开发过程分成不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程。当所有的阶段都完成之后，该软件的开发过程也随之结束。

V模型的缺点

V模型一大缺点正是它自身的顺序性所导致的。到了测试阶段，程序已经完成，错误已经产生，很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了。

同时实际的开发过程中，在需求阶段很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复，而且都要重复需求、设计、编码、测试等过程，返工量非常大，模型灵活性比较低。

V模型改进：

测试模型之W模型

1、IEEE std1012-1998《软件验证和确认（V&V）》的原则中提出了在软件的需求和设计阶段也应有测试活动，并且提出了相应的原则；

2、W模型由Evolutif公司提出：开发一个V，测试一个V，组合的W模型；

3、测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试。

W模型的优点：

开发强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试；

更早地接入测试，可以发现开发初期的缺陷，那么可以用更加低的成本进行缺陷修复。

同样是分阶段的工作，便于控制项目过程。

W模型的缺点：

依赖于软件开发和软件测试依然保持一前一后的线性关系，依然无法支持迭代、自发性和需求等变更调整；

对于当前很多项目，在执行的过程中根本不产生文档，那么W模型基本无法适用；

使用起来技术复杂度很高，对于需求和设计的测试要求很高，实践起来困难。

测试模型之H模型

H模型诞生背景

人们发现虽然软件开发中需求、设计、编码等活动被分阶段执行、但是实践中，他们并不是完全串行的，它们之间更多时候是交叉进行的，更多的是迭代执行。

为了解决上面的问题，有专家专门提出了H模型，它将测试活动完全独立出来，形成一个完全独立的流程，同时将测试准备和测试执行也清晰表现出来。

测试流程

测试准备：所有测试执行活动的准备；判断是否到测试就绪点；

测试就绪点：测试准入准则，即是否可以开始执行测试的条件；

测试执行：具体的执行测试的程序。

其他流程

具体开发中的流程，如：设计流程

H模型优缺点

H模型的优点：

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

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

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

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

H模型的缺点：

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

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

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

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