1.3 软件开发过程

作为软件测试人员，在进行软件测试工作之前，有必要对软件开发的整个过程有相当的认识和理解。一项完整的、正式的软件开发项目及完成过程与计算机程序爱好者编写的小程序过程是不能相提并论的，也是完全不一样的。一个新软件产品的项目开发过程可能需要几十、几百甚至几千人的协同合作才能够完成。据称，微软公司的Word产品开发过程共使用了约1700人；Windows 2000 Server的开发投入了6000人之多，并且整个开发都需要在严格的计划进度的控制下进行密切的合作。从全局观点出发，软件测试人员分析构成软件产品的各部分并了解常用的一些方法，对正确理解具体的软件测试任务和工作过程将十分有益。

1.3.1 软件产品的组成

1.软件产品需要各种开发投入

软件产品的开发究竟需要哪些投入呢？一般地说，开发软件产品需要产品说明书、产品审查、设计文档、进度计划、上一版本（若有的话）的信息反馈、商业竞争对手的同类软件产品情况、客户调查、易用性数据、观察与感受说明书、软件代码等，甚至是一些大多数软件产品用户不曾想到过的内容。

在软件行业，用“可提供的”一词来描述开发出来并交付使用的软件产品。为了得到“可提供的”软件产品，需要付出各种各样大量的工作。图1.9显示了得到“可提供的”软件产品的工作过程。

2.客户需求

开发软件产品的目的是满足客户的需求。为了达到这一根本目的，软件产品开发项目组必须清楚客户的需求。这里的需求包括调查收集的详细信息，以前软件的使用情况及存在的问题，竞争对手的软件产品的信息等。除此之外，还有收集到的其他信息，并对这些信息进行研究和分析，以确定将要开发的软件产品应该具有哪些功能。

从客户那里得到反馈意见，目前主要的途径除了直接由开发组进行的调查外，还需通过独立调查机构进行调查问卷活动获取有关的问题反馈。

3.产品说明

仅仅有了对客户的需求的研究结果后，这些原始材料还不能对所要开发的产品进行描述，只是确定哪些要做、哪些不做以及客户所需要的产品功能。产品说明书的作用就是对上述信息进行综合描述，并包括用户没有提出但软件产品本身必须要实现的要求，从而针对产品进行定义并确定其功能。

产品说明书的格式并没有统一的形式。对某些软件产品，如金融公司、政府机构、军事部门的特制软件，要采取严格的程序对产品说明书进行检查，检查内容十分详细，并且在整个产品说明书中是完全确定的。在非特殊情况下，产品说明书不能随意发生变化，软件开发工作组的任务是完全确定的。

但对于软件开发队伍结构编制不严格的团队，对某些应用软件产品，其产品说明书写得比较简单粗糙。这种做法的好处是比较灵活，但存在目标不明确的潜在问题。

4.设计文档

有一些常见的错误开发观念，即当创建程序时，没有经过正规的设计就开始坐下来编写源代码。这种现象在一些小型的、不正规的开发小组中常见，但对于稍大的软件系统而言，必须要有一个计划来实施软件的设计过程。这如同在建筑一栋大厦，在施工前必须要先进行规划设计、绘制各类工程图纸一样，软件开发同样要有类似的计划，这些计划通常是由软件设计文档来体现的。

常用的软件设计文档的内容如下：

（1）构架，即产生描述软件整体设计的文档，包括软件所有主要部分的描述以及相互间的交互方式。

（2）数据流示意图，表示数据在程序中如何流动的正规示意图，通常由圆圈和线条组成，所以也称为泡泡图。

（3）状态变化示意图，将软件分解为基本状态或者条件的另一种正规示意图，表示不同状态间的变化的方式。

（4）流程图，用图形描述程序逻辑的最常用方式之一。根据详细的流程图编写程序代码简单方便。

（5）注释代码，软件代码通常也需要被其他没有直接参与开发的人员（如维护人员）阅读参考，因此代码注释是不能缺少的，便于维护代码的程序员掌握代码的内容和执行方式。

5.测试文档

测试文档是完整的软件产品的一部分。根据软件产品开发过程的需要，程序员和测试员必须对工作进行文档说明。下面是一般测试文档所包含的内容。

（1）测试计划：描述用于验证软件是否符合产品说明书和客户需求的整体方案。

（2）测试用例：依据测试的项目，并描述验证软件的详细步骤。

（3）软件测试报告：描述依据测试用例找出的问题，通常提交测试报告。

（4）归纳、统计和总结：采用图表、表格和报告等形式来描述整个测试过程。

6.开发进度表

开发进度表是软件产品的关键部分，随着软件项目的不断扩大和复杂性的增加，开发产品需要大量的人力、物力，必须有某种机制来跟踪进度。制定进度的目标是明确哪项工作完成了，哪些工作还没有完成，何时能够完成。通常应用Gantt图表来描述软件开发的进度，如图1.10所示，图表的水平时间轴显示软件开发进度。

7.软件产品组成的其他部分

综前所述，软件产品不仅仅应当只关心程序代码，还要关注各种各样的技术支持，这些部分通常由客户使用或查看，所以也需要进行测试。下面列出除程序代码之外的，但也属于软件产品各种组成。

（1）帮助文件。

（2）用户手册。

（3）样本和示例。

（4）标签。

（5）产品支持信息。

（6）图表和标志。

（7）错误信息。

（8）广告与宣传材料。

（9）软件的发布安装。

（10）软件说明文件。

（11）测试错误提示信息。

1.3.2 软件开发项目组

根据软件公司的规模和软件项目的规模大小不同，开发项目组的人员多少也不尽相同。但在大多数情况下，分工是相同的。一般情况下软件开发项目组由下列人员组成，并承担相应的工作职责。

（1）项目管理经理：全程负责整个软件项目的开发，通常负责编写软件产品说明书、管理项目开发进度、进行重大决策。某些公司或组织还根据项目规模和人力资源配备设置开发经理和测试经理，分别担负其工作并对工作负责。

（2）系统设计师：担任软件项目小组技术专家，设计整个系统构架或软件构思。通常这部分人需要具有丰富的工作经验与行业背景。

（3）程序员/软件工程师：负责设计、编写程序，并修改软件中的缺陷。通常与项目管理经理、软件设计师密切合作、共同工作。

（4）软件测试员/测试工程师：负责找出并报告产品的问题，与开发组密切合作，进行测试并报告发现的问题。

（5）用户助手、用户培训员、手册编写和文件档案专员：负责编写软件产品附带的文件和联机文档。

（6）结构管理和发布制作人员：负责将程序员编写的全部文档资料合并成一个软件包。

1.3.3 软件开发模式

从最初构思到公开发行软件产品的过程称之为软件开发模式（也称为开发流程）。采用正确、适宜的软件开发方法，并严格地按照计划组织整个开发进程是非常重要的。

由于软件开发需求和规模各不相同，因此在开发不同软件的过程中也会采用不同的开发流程。目前流行的软件产品开发的流程方法有多种，例如，大棒开发模型、瀑布模型、螺旋模型、RUP模型、IPD流程、敏捷开发等，不同的过程模型适合于不同类型的软件项目。

1.大棒开发模型

关于宇宙的诞生源自一种大棒理论，据说在几亿年前，一股极强的能量爆发创造了宇宙。而世界上的万物都是由能量和物质积聚而成的，于是便有了生物、大楼、软盘和其他许多东西，并假如形成这些事物的能量和物质不遵循某种排列与组合，因此，这些事务可能会变成一堆杂乱的东西，而非预期的事物。

软件开发的大棒模式就源自上述理论。一大堆能量（这里指开发软件所需要的人力和物力）放在一起，巨大的能量（智力、体能、物理性物质）组合并释放，通常结果可能是产生了优秀的“东西”（软件产品）或一堆“废品”（不成功的软件）。

大棒开发模式的最大优点是思路简单，经常可能是开发者的“突发奇想”。但它几乎没有任何产品计划、进度安排和规范的开发过程，软件开发者的主要精力花费在程序设计和代码编写上，开发过程是非工程化的。大棒模式的软件测试通常在开发任务完成后进行，测试工作有时较容易，有时则非常困难，这是因为软件已形成产品后，已经无法再修复存在的问题，所以软件测试的工作只是向客户报告软件产品经过测试后发现的情况。

软件的边写边改开发模式是对大棒开发模式的一种改进，但考虑到了软件产品的要求，如图1.11所示。这种开发模式是软件项目组在未刻意采用其他开发模式时常用的一种开发模式。

采用边写边改模式的软件开发通常在有了比较粗略的想法后就开始进行简单的设计，然后进行较长的反复编写、测试与修复这样一个循环的过程，在认为无法更精细地描述软件产品要求时就发布产品。

因为从开始就没有严格的计划和文档编制，软件开发能较迅速地展现成果。因此，边写边改模式适合用在快速制作而且用完就扔掉的小型项目上，如示范程序与演示程序。

处于边写边改开发项目组的软件测试人员要明确的是，自己将和程序员一起陷入可能是长期的循环往复的一个开发过程。通常，新的软件（程序）版本在不断产生，而旧的版本的测试工作可能还未完成，新版本还可能又包含了新的或修改了的软件功能。边写边改开发模式虽然有缺点，但它是通向采用合理软件开发流程的路径，有助于理解更正规的软件开发方法。

2.瀑布开发模型

瀑布开发模型是应用最为广泛的一种软件开发模型，也是最容易理解和掌握的模型，然而它的缺陷也是显而易见的。遗漏的需求或者不断变更的需求会使得该模型无所适从，它适用于那些需求比较稳定、容易理解的项目。瀑布开发法是将软件生命周期的各项活动规定为按照固定顺序相连的若干个阶段性工作，形如瀑布流水，最终得到软件产品。因为这种开发模式形如瀑布，由此而得名。如图1.12所示为该开发模式的示意图。

瀑布开发模式中各阶段的主要工作及其相应的质量控制方式如表1.1所示。

（1）瀑布开发模型的优点。

①易于理解。

②调研开发的阶段性。

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

④确定何时能够交付产品及何时进行评审与测试。

（2）瀑布开发模型的缺点。

①需求调查分析只进行一次，不能适应需求的变化。

②顺序的开发流程，使得开发中的经验教训不能反馈到该项目的开发中去。

③不能反映出软件开发过程的反复性与迭代性。

④没有包含任何类型的风险评估。

⑤开发中出现的问题直到开发后期才能显露，因此失去了及早纠正的机会。

3.快速原型法

瀑布开发模式的缺点在于开发过程没有结束前产品不够直观，快速原型开发模式则改进了这一缺点。一般情况下，根据客户的需求在较短的时间内解决用户最迫切需要解决的问题，完成一个可演示的产品。这个产品只实现软件最重要的功能（产品部分功能）。应用快速原型开发模式的目的是为了确定用户的真正需求，使得用户在原型面前能够更加明确自己的需求是什么。在得到用户的明确需求之后，原型将被丢弃。因为原型开发的速度较快，设计方面的付出不多，也只是表达了软件的最主要功能。如图1.13所示为快速原型开发模式示意图。

4.螺旋模型

螺旋模型开发是瀑布模型与边写边改方法演化、结合的形式，并加入了开发风险评估所建立的软件开发模式。该软件开发模式由美国TRW公司B.W.Boehm博士提出。

螺旋模型也是一个经典模型，它关注于发现和降低项目的风险。螺旋模型的主要思想是在开始时不必详细定义所有细节，而是从小的规模开始，定义重要功能，尽量实现，然后探测风险，制定风险控制计划，接受客户反馈，进入下一阶段并重复上述过程，然后进行下一个螺旋的反复，确定下一步项目是否还要继续，直到获得最终产品。其示意图如图1.14所示。该模型的最大优点就是随着成本的增加，风险程度随之降低。但螺旋模型的缺点是比较复杂，且需要管理人员有责任心，专注且有管理方面的经验。

每一螺旋包括5个步骤：①确定目标，选择方案和限制条件；②对方案风险进行评估，并能解决风险；③进行本阶段的开发和测试；④计划下一阶段；⑤确定进入下一阶段的方法。

螺旋开发模式中包含了一些瀑布模式（分析、设计、开发和开发步骤）、边写边改模式（每次盘旋上升）和大棒模式（从外界看）。该开发模式具有发现问题早、产品的来龙去脉清晰、成本相对低、测试从最初就参与各项工作的特点。该软件开发模式目前最常用，并被广泛认为是软件开发的有效手段。

螺旋开发模式具有以下优点：①严格的全过程风险管理；②强调各开发阶段的质量；③提供机会评估项目是否有价值继续下去。

螺旋开发模式由于引入了非常严格的风险识别、风险分析和风险控制，因此对风险管理的技能水平提出了很高的要求，并需要较多的人员、资金和时间上的投入。

5.RUP模型

RUP（Rational Unified Process）是Rational公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程，并具有相同的结构，即相同的流程构架。RUP为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。

RUP设计具有两个轴向，一个轴是时间轴，这是动态的；另一个是工作流轴，这是静态的。在时间轴上，RUP划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上，RUP设计了六个核心工作流程和三个核心支撑工作流程，核心工作流程包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流；核心支撑工作流程包括：环境工作流、项目管理工作流和配置与变更管理工作流。

RUP汇集了现代软件开发中多方面的管理经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。

6.IPD流程

IPD（Integrated Product Development）流程是由IBM提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及软硬件结合的项目。IPD从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工程设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。IPD是一个端到端的流程。该流程中总共划分了六个阶段，即概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段）；四个决策评审点，即概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点），以及六个技术评审点。

IPD流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。在一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有率。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目，该流程就显得不大适合了；对于一些小的项目，也不是非常适合使用该流程。

7.敏捷开发

敏捷开发产生于2001年，一批软件业界专家为解决许多公司的软件团队陷入不断增长的软件过程的“泥潭”，概括出了一些可让开发团队具有快速工作和响应变化能力的价值观和原则，由此而诞生了敏捷软件开发方法。敏捷开发不是仅为一个过程，而是一类过程的统称，这些过程有一个共性，就是符合敏捷价值观，遵循敏捷开发的原则：简单、灵活和效率。敏捷的价值观为：个体和交互胜过过程和工具；可运用工作的软件胜过面面俱到的文档；客户合作进行合同谈判，以响应变化胜过教条地遵循计划。

敏捷开发过程主要包括：SCRUM，Crystal，特征驱动软件开发（FDD），自适应软件开发（ASD）及极限编程（XP）等。

（1）XP（极限编程eXtreme Programming，简称XP），是一个轻量级的、灵巧的软件开发方法，同时也是一个严谨和周密的方法。XP的基础和价值观是交流、朴素、反馈和勇气，即任何一个软件项目都可以从四方面入手进行改善，加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近似螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极交流、反馈以及其他一系列方法，开发者和客户都能够非常清楚开发的进度、变化、待解决的问题和潜在困难，等等，并根据实际情况及时地调整开发过程。XP无需开发人员在软件开发初期就制作出很多文档，以适应计划的不断改变。XP提倡测试先行，这是为了将后期出现bug的概率降到最低。XP将项目的所有参与者视为同一团队成员（开发人员、客户、测试人员等），并一起工作在开放场所中。

（2）SCRUM。SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。该方法的核心是旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。

（3）Crystal Methods（水晶方法族）。它是一个系列，因为不同类型的项目需要不同的方法。虽然“水晶系列”不如XP有那样高的产出效率，但有不少开发者接受并遵循这一开发方法。

（4）FDD（Feature-Driven Development，特性驱动开发）。这是一套针对中小型软件项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调简化、实用、易于被开发团队接受，适用于需求经常变动的项目。

（5）ASD（Adaptive Software Development，自适应软件开发）。ASD强调开发方法的适应性，这一思想来源于复杂系统的混沌理论。ASD不像其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。

（6）DSDM（动态系统开发方法）也是敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。DSDM方法不但遵循了敏捷方法的原理，而且也适合那些相对成熟传统开发方法具有坚实基础的软件组织。

（7）轻量型RUP。RUP本质上是一个过程框架，可以包容许多不同类型的过程，一些软件专家极力主张以敏捷方式来使用RUP，并认为如此推进敏捷方法，是因为开发者广泛把RUP当做面向对象开发方法的主流。

敏捷方法将开发与测试过程融为一体。在敏捷方法中，测试以很多不同的方法扮演着同样的角色，而不同的测试种类扮演着不同的角色。大家知道，测试大体上可分为手工测试和自动化测试。根据敏捷原则，要确保能用自动化测试的事情绝不要用手工测试，同时要做到适于手工测试的内容绝不花高昂成本做自动化测试。另外，不因为某方面不能实现自动化测试而不去做测试。敏捷开发中，如何运用手工测试和自动化测试？如何设计测试用例？这些是敏捷测试面临的挑战。