1.1 软件概述

对于软件大家应该都不陌生，我们每天都会使用各种各样的软件，如Windows、Office、微信、QQ等。软件是相对于硬件而言的，它是一系列按照特定顺序组织的计算机数据和指令的集合。

软件和其他产品一样，都有一个从“出生”到“消亡”的过程，这个过程称为软件的生命周期。在软件的生命周期中，软件测试是非常重要的一个环节。学习软件测试，必须要对软件相关知识有一定了解，包括软件生命周期、软件开发模型、软件质量等。本节将对软件的这些知识进行详细讲解。

1.1.1 软件生命周期

软件生命周期分为多个阶段，每个阶段有明确的任务，这样就使得结构复杂、管理复杂的软件开发变得容易控制和管理。通常，可将软件生命周期划分为6个阶段，如图1-1所示。

图1-1中每个阶段的目标任务及含义分别介绍如下。

第1阶段：问题定义，该阶段由软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

第2阶段：需求分析，该阶段对软件需求进行更深入的分析，划分出软件需要实现的功能模块，并制作成文档。需求分析在软件的整个生命周期中起着非常重要的作用，它直接关系到后期软件开发的成功率。在后期开发中，需求可能会发生变化，因此，在进行需求分析时，应考虑到需求的变化，以保证整个项目的顺利进行。

第3阶段：软件设计，该阶段在需求分析结果的基础上，对整个软件系统进行设计，如系统框架设计、数据库设计等。

第4阶段：软件开发，该阶段在软件设计的基础上，选择一种编程语言进行开发。在开发过程中，必须要制订统一的、符合标准的程序编写规范，以保证程序的可读性、易维护性以及可移植性。

第5阶段：软件测试，该阶段是软件开发完成后对软件进行测试，以查找软件设计与软件开发过程中存在的问题并加以修正。软件测试过程包括单元测试、集成测试、系统测试3个阶段；测试的方法以黑盒测试、白盒测试或者两者结合的形式进行。在测试过程中，为减少测试的随意性，需要制订详细的测试计划并严格遵守；测试完成之后，要对测试结果进行分析并对测试结果以文档的形式汇总。

第6阶段：软件维护，软件完成测试并投入使用之后，面对庞大的用户群体，软件可能无法满足用户使用需求，此时就需要对软件进行维护升级以延续软件的使用寿命。软件的维护包括纠错性维护和改进性维护两个方面。软件维护是软件生命周期中持续时间最长的阶段。

1.1.2 软件开发模型

软件测试工作与软件开发模型息息相关，在不同的软件开发模型中，测试的任务和作用也不相同，因此测试人员要充分了解软件开发模型，以便找准自己在其中的定位与任务。

软件开发模型规定了软件开发应遵循的步骤，是软件开发的导航图，它能够清晰、直观地表达软件开发的全过程，以及每个阶段要进行的活动和要完成的任务。开发人员在选择开发模型时，要根据软件的特点、开发人员的参与方式选择稳定可靠的开发模型。

自有软件开发以来，软件开发模型也从最初的“边做边改”发展出了多个模型，下面以软件开发模型发展历史为顺序，介绍几个典型的开发模型。

1. 瀑布模型

瀑布模型是W.W.罗伊斯（W.W.Royce）于1970年提出的软件开发模型，由模型名称可知该模型遵循从上至下一次性完成整个软件产品的开发方式。

瀑布模型将软件开发过程分为6个阶段：计划→需求分析→软件设计→编码→测试→运行维护，其开发过程如图1-2所示。

在瀑布模型中，软件开发的各项活动严格按照这条线进行，只有当一个阶段任务完成之后才能开始下一个阶段。软件开发的每一个阶段都要有结果产出，结果经过审核验证之后作为下一个阶段的输入，下一个阶段才可以顺利进行。如果结果审核验证不通过，则需要返回修改。

瀑布模型为整个项目划分了清晰的检查点，当一个阶段完成之后，只需要把全部精力放置在后面的开发上即可，它有利于大型软件开发人员的组织管理及工具的使用与研究，可以提高开发的效率。

但是瀑布模型是严格按照线性方式进行的，无法适应用户需求变更，用户只能等到最后才能看到开发成果，增加了开发风险。如果开发人员与客户对需求理解有偏差，到最后开发完成后，最终成果与客户需求可能会差之千里。

使用瀑布模型开发软件时，如果早期犯的错误在项目完成后才发现，此时再修改原来的错误需要付出巨大的代价。瀑布模型要求每一个阶段必须有结果产出，这就势必增加了文档的数量，使软件开发的工作量变大。

除此之外，对于现代软件来说，软件开发各阶段之间的关系大部分不会是线性的，很难使用瀑布模型开发软件，因此瀑布模型不再适合现代软件开发，已经被逐渐废弃。

2. 快速原型模型

快速原型模型与瀑布模型正好相反，它在最初确定用户需求时快速构造出一个可以运行的软件原型，这个软件原型向用户展示待开发软件的全部或部分功能和性能，客户对该原型进行审核评价，然后给出更具体的需求意见，这样逐步丰富细化需求，最后开发人员与客户达成最终共识，确定客户的真正需求。确定客户的真正需求之后，开始真正的软件开发。

快速原型模型类似于建造房子，确定客户对房子的需求之后快速地搭建一个房子模型，由客户对房子模型进行评价，房子的样式、功能、布局等是否满足需求，哪里需要改进等，一旦最后确定了客户对房子的要求，就开始真正地建造房子。该模型的开发过程如图1-3所示。

与瀑布模型相比，快速原型模型克服了需求不明确带来的风险，适用于不能预先确定需求的软件项目。但快速原型模型关键在于快速构建软件原型，准确地设计出软件原型存在一定的难度。此外，这种开发模型也不利于开发人员对产品进行扩展。

3. 迭代模型

迭代模型又称为增量模型或演化模型，它将一个完整的软件拆分成不同的组件，然后逐个组件地开发测试，每完成一个组件就展现给客户，让客户确认这一部件功能和性能是否达到客户需求，最终确定无误，将组件集成到软件体系结构中。整个开发工作被组织为一系列短期、简单的小项目，称为一系列迭代，每一个迭代都需要经过需求分析→软件设计→编码→测试的过程，其开发过程如图1-4所示。

在迭代模型中，第一个迭代（即第一个组件）往往是软件基本需求的核心部分，第一个组件完成之后，经过客户审核评价形成下一个组件的开发计划，包括对核心产品的修改和新功能的发布，这样重复迭代步骤直到实现最终完善的产品。

迭代模型可以很好地适应客户需求变更，它逐个组件地交付产品，客户可以经常看到产品，如果某个组件没有满足客户需求，则只需要更改这一个组件，降低了软件开发的成本与风险。但是迭代模型需要将开发完成的组件集成到软件体系结构中，这样会有集成失败的风险，因此要求软件必须有开放式的体系结构。此外，迭代模型逐个组件地开发修改，很容易退化为“边做边改”的开发形式，从而失去对软件开发过程的整体控制。

4. 螺旋模型

螺旋模型由巴利·玻姆（Barry Boehm）于1988年提出，该模型融合了瀑布模型、快速原型模型，它最大的特点是引入了其他模型所忽略的风险分析，如果项目不能排除重大风险，就停止项目从而减小损失。这种模型比较适合开发复杂的大型软件。

螺旋模型将整个项目开发过程划分为几个不同的阶段，每个阶段按部就班地执行，这种划分方式采用了瀑布模型。每个阶段在开始之前都要进行风险评估，如果能消除重大风险则可以开始该阶段任务。在每个阶段，首先构建软件原型，根据快速原型模型完成这个迭代过程，产出最终完善的产品，然后进入下一个阶段，同样下一个阶段开始之前也要进行风险评估，这样循环往复直到完成所有阶段的任务。螺旋模型的若干个阶段是沿着螺线方式进行的，如图1-5所示。

图1-5有4个象限：制订计划、风险分析、实施工程、客户评估，各象限含义如下。

（1）制订计划：确定软件目标，制订实施方案，并且列出项目开发的限制条件。

（2）风险分析：评价所制订的实施方案，识别风险并消除风险。

（3）实施工程：开发产品并进行验证。

（4）客户评估：客户对产品进行审核评估，提出修正建议，制订下一步计划。

在螺旋模型中，每一个迭代都需要经过这4个步骤，直到最后得到完善的产品，可以进行提交。

螺旋模型强调了风险分析，这意味着对可选方案和限制条件都进行了评估，更有助于将软件质量作为特殊目标融入产品开发之中。它以小分段构建大型软件，使成本计算变得简单容易，而且客户始终参与每个阶段的开发，保证了项目不偏离正确方向，也保证了项目的可控制性。

5. 敏捷模型

敏捷模型是20世纪90年代兴起的一种软件开发模型。在现代社会，技术发展非常快，软件开发也是在快节奏的环境中进行的。在业务快速变换的环境下，往往无法在软件开发之前收集到完整而详尽的软件需求。没有完整的软件需求，传统的软件开发模型就难以展开工作。

为了解决这个问题，人们提出了敏捷开发模型。敏捷模型以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷模型中，软件项目在构建初期被拆分为多个相互联系而又独立运行的子项目，然后迭代完成各个子项目，开发过程中，各个子项目都要经过开发测试。当客户有需求变更时，敏捷模型能够迅速地对某个子项目做出修改以满足客户的需求。在这个过程中，软件一直处于可使用状态。

除了响应需求，敏捷模型还有一个重要的概念——迭代，就是不断对产品进行细微、渐进式的改进，每次改进一小部分，如果可行再逐步扩大改进范围。在敏捷模型中，软件开发不再是线性的，开发的同时也会进行测试工作，甚至可以提前写好测试代码，因此在敏捷模型中，有“开发未动，测试先行”的说法。

另外，相比于传统的软件开发模型，敏捷模型更注重“人”在软件开发中的作用，项目的各部门应该紧密合作、快速有效地沟通（如面对面沟通），提出需求的客户可以全程参与到开发过程，以适应软件频繁的需求变更。为此，敏捷模型描述了一套软件开发的价值和原则，具体如下所示。

（1）个体和交互重于过程和工具。

（2）可用软件重于完备文档。

（3）客户协作重于合同谈判。

（4）响应变化重于遵循计划。

对于敏捷模型来说，并不是工具、文档等不重要，而是更注重人与人之间的交流沟通。

敏捷模型可以及时响应客户需求变更，不断适应新的趋势，但是在开发灵活的同时也带来了一定程度的混乱。例如，缺乏文档资料；软件之前版本的可重现性、可回溯性较低；对于较大的项目，人员越多，面对面的有效沟通越困难。因此敏捷模型比较适用于小型项目的开发，而不太适用于大型项目。

多学一招：敏捷模型的开发方式

敏捷模型主要有2种开发方式：Scrum与Kanban，下面分别对这两种开发方式进行简单的介绍。

1. Scrum

在Scrum开发方式的团队中，会选出一个Scrum Master（产品负责人）全面负责产品的开发过程。Scrum Master把团队划分成不同的小组，把整个项目划分成细小的可交付成果的子项目，分别由不同的小组完成，并对各小组的工作划分优先级，估算每个小组的工作量。

在开发过程中，每个小组的工作都是一个固定时长的短周期迭代，开发短周期一般为1～4周。开发完成之后，经过一系列的测试、优化等，将产品集成，交付最终成果。

2. Kanban

Kanban（看板）源于丰田的生产模式，它将工作细分成任务，将工作流程显示在“看板卡”上，每个人都能及时了解自己的工作任务及工作进度。这种生产理念后来被引入到软件开发中，利用可视化软件将开发的软件项目细分成小任务，并分配给团队成员，每个成员都可以在“看板”上了解自己的工作任务及整个团队的工作进度。项目开始之后，从目前执行的任务和过程开始，团队会针对每个成员的工作做出持续、增量、渐进式的改变。

1.1.3 软件质量概述

软件产品与其他产品一样，都是有质量要求的，软件质量关系着软件使用程度与使用寿命，一款高质量的软件更受用户欢迎，它除了满足客户的显式需求之外，往往还满足了客户隐式需求。下面分别从软件质量的概念、软件质量模型、影响软件质量的因素这几个方面介绍软件质量的相关知识。

1. 软件质量的概念

软件质量是指软件产品满足基本需求及隐式需求的程度。软件产品满足基本需求是指其能满足软件开发时所规定需求的特性，这是软件产品最基本的质量要求；其次是软件产品满足隐式需求的程度。例如，产品界面更美观、用户操作更简单等。

从软件质量的定义，可将软件质量分为3个层次，具体如下。

（1）满足需求规定：软件产品符合开发者明确定义的目标，并且能可靠运行。

（2）满足用户需求：软件产品的需求是由用户产生的，软件最终的目的就是满足用户需求，解决用户的实际问题。

（3）满足用户隐式需求：除了满足用户的显式需求，软件产品如果满足用户的隐式需求，即潜在的可能需要在将来开发的功能，将会极大地提升用户满意度，这就意味着软件质量更高。

所谓高质量的软件，除了满足上述需求之外，对于内部人员来说，它应该也是易于维护与升级的。软件开发时，统一的符合标准的编码规范、清晰合理的代码注释、形成文档的需求分析、软件设计等资料对于软件后期的维护与升级都有很大的帮助，同时，这些资料也是软件质量的一个重要体现。

2. 软件质量模型

软件质量是使用者与开发者都比较关心的问题，但全面客观地评价一个软件产品的质量并不容易，它并不像普通产品一样，可以通过直观的观察或简单的测量能得出其质量是优还是劣。那么如何评价一款软件的质量呢？目前，最通用的做法就是按照ISO/IEC 9126:1991国际标准来评价一款软件的质量。

ISO/IEC 9126:1991是最通用的一个评价软件质量的国际标准，它不仅对软件质量进行了定义，而且还制订了软件测试的规范流程，包括测试计划的撰写、测试用例的设计等。ISO/IEC 9126:1991标准由6个特性和27个子特性组成，如图1-6所示。

ISO/IEC 9126:1991标准所包含的6大特性的具体含义如下。

（1）功能性：在指定条件下，软件满足用户显式需求和隐式需求的能力。

（2）可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力。

（3）可使用性：在指定条件下，软件产品被使用、理解、学习的能力。

（4）效率：在指定条件下，相对于所有资源的数量，软件产品可提供适当性能的能力。

（5）可维护性：指软件产品被修改的能力。修改包括修正、优化和功能规格变更的说明。

（6）可移植性：指软件产品从一个环境迁移到另一个环境的能力。

这6大特性及其子特性是软件质量标准的核心，软件测试工作就从这6个特性和27个子特性去测试、评价一个软件的。

多学一招：纸杯测试

“纸杯测试”是一个经典的测试案例，这是微软公司曾给软件测试者出的一道面试题，用于考察面试者对软件测试的理解与掌握程度。

测试项目：纸杯。

需求测试：查看纸杯说明书是否完整。

界面测试：观察纸杯外观，测试表面是否光滑、手感是否舒适。

功能测试：用纸杯装水，观察是否漏水。

安全测试：纸杯是否有毒或细菌。

可靠性测试：从不同高度摔下来，观察纸杯的损坏程度。

易用性测试：用纸杯盛放开水是否烫手，纸杯是否易滑、是否方便饮用。

兼容性测试：用纸杯分别盛放水、酒精、饮料、汽油等，观察是否有渗漏现象。

可移植性测试：将纸杯放在温度、湿度等不同的环境中，查看纸杯是否还能正常使用。

可维护性：将纸杯揉捏变形，看其是否能恢复。

压力测试：用一根针扎在纸杯上不断增加力量，记录多大压强时针能穿透纸杯。

疲劳测试：用纸杯分别盛放水、汽油放置24小时，观察其渗漏情况（时间和程度）。

跌落测试：纸杯（加包装）从高处落下，查看可造成破损的高度。

震动测试：纸杯（加包装）六面震动，评估它是否能应对恶劣的公路/铁路/航空运输等。

测试数据：编写具体测试数据（略），其中可能会用到场景法、等价类划分法、边界值分析法等测试方法。

期望输出：期望输出需要查阅国际标准及用户的使用需求。

用户文档：使用手册是否对纸杯的用法、使用条件、限制条件等有详细描述。

说明书测试：查看纸杯说明书的正确性、准确性及完整性。

3. 影响软件质量的因素

现代社会处处离不开软件，为保证人们生活工作正常有序地进行，就要严格控制好软件的质量。由于软件自身的特点和目前的软件开发模式使得隐藏在软件内部的质量缺陷无法完全根除，因此每一款软件都会存在一些质量问题。影响软件质量的因素有很多，下面介绍几种比较常见的影响因素。

（1）需求模糊

在软件开发之前，确定软件需求是一项非常重要的工作，它是后面软件设计与软件开发的基础，也是最后软件验收的标准。但是软件需求是不可视的，往往也说不清楚，导致产品设计、开发人员与客户存在一定的理解误差，开发人员对软件的真正需求不明确，结果开发出的产品与实际需求不符，这势必会影响软件的质量。

除此之外，在开发过程中客户往往会一而再再而三地变更需求，导致开发人员频繁地修改代码，这可能会导致软件在设计时期存在不能调和的误差，最终影响软件的质量。

（2）软件开发缺乏规范性文件指导

现代软件开发，大多数团队都将精力放在开发成本与开发周期上，而不太重视团队成员的工作规范，导致团队成员开发“随意性”比较大，这也会影响软件质量，而且一旦最后软件出现质量问题，也很难定责，导致后期维护困难。

（3）软件开发人员问题

软件是由人开发出来的，因此个人的意识对产品的影响非常大。除了个人技术水平限制，开发人员问题还包括人员流动，新来的成员可能会继承上一任的产品接着开发下去，两个人的思维意识、技术水平等都会不同，导致软件开发前后不一致，进而影响软件质量。

（4）缺乏软件质量控制管理

在软件开发行业，并没有一个量化的指标去度量一款软件的质量，软件开发的管理人员更关注开发成本和进度，毕竟这是显而易见的，并且是可以度量的。但软件质量则不同，软件质量无法用具体的量化指标去度量，而且软件开发的质量并没有落实到具体的责任人，因此很少有人关心软件最终的质量。