全栈软件测试工程师宝典连载（2）

1.3 软件工程模型

讨论软件测试，不得不涉及软件工程模型，因为软件测试学与软件工程的发展是依依相关、相辅相成的。软件工程模型大体上可以分为两类：瀑布模型及其衍生模型和敏捷模型，下面分别进行介绍。

1.3.1 瀑布模型及其衍生模型

1．瀑布模型

图1-2为瀑布模型。这个模型是经典的软件工程模型，包括“计划”->“需求分析”->“设计”->“编码”->“测试”->“运行维护”这六个阶段。

图1-2 瀑布模型

但是，这个模型存在比较严重的缺点。

•不可反复及不适用于需求变更比较频繁的情况。

由于瀑布模型从业务建模到运行维护是一脉相承，不可以反复的。而现代软件项目中，需求变更是无处不在的：“唯一不变的是需求变更”。若使用这种模型，只要项目需求发生变化，就要把原有的设计打翻，重新进行系统分析、概要设计、详细设计、开发、测试、部署等工作。

•用户很难在项目初期了解项目状态。

由于用户在项目初期很难提出明确的需求，而利用瀑布模型只有到编码结束，软件测试工程师才可介入软件测试，客户才可以看到是否是他们需要的产品，在此之前这些产品他们不完全了解，有时需要补充，有时客户也有可能推翻他们原本的需求，提出新的需求，这样往往会给客户方、开发方带来很大的麻烦。

2. 快速原型法

通常简称为原型法，其核心是用交互的，快速建立起来的原型取代了形式的、僵硬的（不允许更改的）大部分的规格说明，用户通过在计算机上实际运行和试用原型系统而向开发者提供真实的、具体的反馈意见。快速原型法通常使用到一些原型工具，简单的包括：线框图、PowerPoint等，专业的包括：Axure RP、墨刀、Adobe XD、ProtoPie、Framer X等。

3．迭代模型和螺旋模型

图1-3为迭代模型（又名螺旋模型）。瀑布模型和迭代模型往往在概念上区别不明显。事实上，这两个模型在思想本质上是一致的。它将客户的需求按照用户的重要等级和模块自身的等级进行安排，从最开始进行分析、设计、编码、测试，然后再进入下一轮迭代。用户只要在每一轮结束后，就可以看到产品的一些雏形，从而可以进行需求变更和提出下一轮建议。该模型初期开发工作比较少，用户又可以及时提出下一轮更详细的需求和变更，所以这样的模型往往利于软件公司产品的研发。这类模型有著名的RUP模型、快速开发模型等。

图1-3 迭代模型

1.3.2 敏捷软件开发

敏捷软件开发是指一组基于迭代开发的软件开发方法，其中需求和解决方案通过自组织的跨功能团队之间的协作来开发的。敏捷方法或敏捷过程通常可以推进一个严格的项目管理过程，鼓励频繁的检查和适应，鼓励一个领导哲理的团队协作，自组织和问责制，一组工程最佳实践旨在允许快速交付高质量的软件，将客户需求和公司目标作为企业经营决策。敏捷宣言如下。

•个体和互动高于流程和工具。

•工作的软件高于详尽的文档。

•客户合作高于合同谈判。

•响应变化高于遵循计划。

敏捷12原则包括。

•通过早期和连续型的高价值工作交付满足“客户”。

•大的工作分成可以迅速完成的较小组成部分。

•识别最好的工作是从自我组织的团队中出现的，

•为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。

•创建可以改善可持续工作的流程。

•维持完整工作的不变的步调。

•欢迎改变的需求，即使是在项目后期。

• 在项目期间每天与项目团队和业务所有者开会。

•在定期修正期，让团队反映如何能高效，然后进行相应行为的调整。

•通过完成的工作量计量工作进度。

• 不断地追求完善。

• 利用调整获得竞争优势。

1．Scrum

Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责（Scurm Master：SC）维护过程和任务，产品负责人（Product Owner：PO）代表利益所有者，开发团队包括了所有开发人员和测试员。

2．XP

极限编程（Extreme Programming，XP）是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效的响应客户的需求变化，哪怕是在软件生命周期的后期。它强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接。

1.4 软件测试模型

1.4.1 V模型

图1-4所示为V模型测试。

图1-4 V模型测试

•单元测试相对于编码进行，这一步往往由开发工程师执行。

•集成测试相对于详细设计，将模块以由上到下、由下到上或混合方式进行逐步集成，测试软件模块与模块、类与类之间的关联性。

•系统测试相对于概要设计，软件测试工程师站在整体的立场上对系统进行全面的软件测试工作。

•验收测试是用户对产品进行的测试，一般分为Alpha测试和Beta测试。验收测试往往由系统维护人员或者用户来完成，需要完全站在用户的立场上进行测试，测试环境也要尽可能与用户的实际环境保持一致，大多数时候，需要到用户现场去进行验收测试工作。

1.4.2 W模型

图1-5所示为W模型测试。W模型其实是V模型的变种，又名双V模型。它提倡的主要思想是软件前置测试理念（即软件测试需要贯穿软件研发的始终）。在需求、设计和编码阶段对产生的工件进行文档评审，一个目的是提出自己的建议和意见，另外一个目的是尽可能理解产品的需求和实现方式。使用前置软件测试法，Bug在软件前期就可以发现，从而降低软件研发的成本。

图1-5 W模型测试

1.3.3 X模型

图1-6为X模型测试。X模型将软件系统分为若干模块，对每个模块进行单元测试、集成测试以及系统测试，然后统一对模块进行集成测试。事实上，这里已经提出了“探索式软件测试”的概念，在作者的《软件测试技术实战 设计、工具及管理》[1] 一书的第3节进行了详细介绍。

图1-6 X模型测试

1.4.4 敏捷测试模型

图1-7是敏捷测试模型。

图1-7 敏捷测试模型

首先说明，敏捷测试模型其实出现很久了，由于敏捷开发得到普及后，这个模型得到了很大的普及。从图1-7可以看到：第1、4象限是主要面对技术的测试、第2、3象限主要是面对业务的测试、第1、2象限是支持团队的测试、第3、4象限是评价产品的测试。

1.5 软件测试方法

软件测试方法见表1-1。

表1-1软件测试方法

即测试方法包括动态白盒测试、静态白盒测试、动态黑盒测试和静态黑盒测试四类。

1.6 软件测试步骤

图1-8描述了软件测试步骤，具体如下。

图1-8 软件测试步骤

•软件测试计划。

•软件测试分析。

•软件测试设计。

•软件测试实施。

•软件测试执行。

•评估出口准则和报告。

•软件测试结束活动。

•测试监督和控制贯穿所有阶段。