第2章
软件开发的过程
要想成为好的软件测试员，至少要对软件开发的全过程有个总体了解。作为学生或爱好者编写小程序的方法与作为大公司开发软件的方法大相径庭。一个新软件产品的建立可能需要数十个、数百个甚至上千个小组成员在严密的进度计划下各司其职、相互协作。软件开发的过程描述了这些人做什么、如何交互、如何决策的细节。
本章的目的不是讲述软件开发过程的每一个细节—这需要一整本书来讲，本章的目的是综观构成软件产品的各个部分，了解目前常用的一些方法。这些知识有助于更好地理解如何恰当运用本书后面各章节所讲述的软件测试技术。
本章重点包括：
- 软件产品构成的主要部分
- 软件产品中包含哪些人员和技术
- 软件从构想到最终产品的过程
2.1 产品的组成部分
软件产品到底是什么？大多数人认为，软件产品仅仅是从互联网上下载或者从DVD光盘安装到计算机上的程序。这样描述并没有错误，但实际上制作软件还包括许多隐含的内容。还有许多“藏在背后”的东西通常被认为理所当然或者被忽视。尽管这些部分容易被遗忘，但是软件测试员要铭记在心，因为这些全是可测试的对象并且可能包含缺陷。
2.1.1 软件产品需要多少投入
首先，让我们看一下软件产品需要多少投入。图2-1显示了一些我们可能考虑不到的抽象内容。
那么，除了实际的代码外，这些构成软件的部分是什么呢？初看它们远不如程序员所列的程序清单那么实在。的确不能从产品光盘中直接看到它们，然而，至少像一个食品广告所说的那样：“它们就在里面。”
在软件行业中，用于描述制造出来并交付他人的软件产品组件的术语是可交付的部分
（deliverable）。解释所有可交付部分内容的最简便方法是分门别类。
1. 客户需求
编写软件的目的是满足一些人的需求，这些人称为客户。为了准确地满足需求，产品开发小组必须摸清客户所想的。有些小组只是凭猜测，但大多数小组搜集详细信息时采取问卷调查、收集软件以前版本反馈信息、收集竞争产品信息、收集期刊评论、收集焦点人群的意见以及其他诸多方式，一些是正规的，一些是非正规的。接下来，所有这些信息都将被研究、提炼、分析，以便确定软件产品应该具备哪些功能。
利用焦点人群审视软件功能
从软件产品的潜在客户中获得直接反馈的流行做法是借助焦点人群。焦点人群通常由办公室设在商业场所的独立问卷调查公司来组织。问卷调查人员通常穿行于商场中，手持笔记本询问过路人是否愿意参加调查。他们问一些诸如“家里有PC吗？使用某某软件吗？用了多长时间？”之类的小问题来确定对象。如果遇到符合条件的对象，他们会邀请你花一些时间到公司加入焦点人群。在公司里调查问卷人员会询问你计算机软件方面更详细的问题，并可能向你展示各种软件包装让你挑选最喜欢的，或者，与你探讨新产品中你喜欢的功能。最妙的是，你花了时间，得到了相应的报酬。
多数情况下，焦点人群是不知道软件公司的名字的。但是，通常又很容易猜到是谁。
2. 产品说明书
对客户需求的研究结果其实只是原始资料，并没有描述要做的产品，只是确定是否需要做（或不需要做）以及客户要求的功能。产品说明书综合上述信息以及没有提出但必须要实现的需求，真正地定义产品是什么、有哪些功能、外观如何。
产品说明书的格式千差万别。有些公司—特别是为政府、航天部门、金融机构和医药企业开发产品的公司—采用严格的过程，要进行大量的检查和对比。结果是产品说明书极其详细完整，而且是锁定的，也就是说，没有极特殊的理由绝不能变。开发小组的每一个成员都清楚地知道他们在做的是什么。
有一些开发小组，通常是开发不很关键应用的小组，在餐巾纸上就写出产品说明书。这样做的明显好处是非常灵活，但是存在的风险是并非所有人都“站在一起”。此外，最终产品是什么样子在发布之前无从得知。
3. 进度表
软件产品的一个关键部分是进度表。随着项目的不断庞大和复杂，制造产品需要投入很多人力和物力，因而必须要有某种机制来跟踪进度。从简单地在Gantt图表（见图2-2）上列出任务，到使用项目管理软件详细跟踪每一分钟的任务，各种机制不一而足。
制定进度的目的是了解哪项工作完成了，还有多少工作要做，何时全部完成。
4.软件设计文档
一个常见的错误观念是，当程序员编写程序时，他坐下来就开始编写代码。这种现象在一些小的、不正规的软件作坊中可能发生，但是对于稍大一些的程序而言，就必须要有一个设计过程来规划软件如何编写。以本书为例，在落笔之前需要有一个大纲。再比如，一幢建筑在施工之前要绘制蓝图。软件也应该有同样的计划。
根据公司和项目合作小组的不同，程序员的文档千差万别，但其目的都是规划、组织即将编写的代码。
下面是一些常用软件设计文档的清单：
- 结构文档。描述软件整体设计的文档，包括软件所有主要部分的描述以及相互之间的交互方式。
- 数据流图。表示数据在程序中如何流动的正规示意图。有时被称为泡泡图（bubble chart），因为它是用圆圈和线画的。
- 状态转换图。把软件分解为基本状态或者条件的另一种正规示意图，表示不同状态间转换的方式。
- 流程图。用图形描述程序逻辑的传统方式。流程图现在不流行了，但是一旦投入使用，根据详细的流程图编写程序代码是很简单的。
- 代码注释。有一个老的说法，你写一次代码，至少被别人看10次。在软件代码中嵌入有用的注释是极为重要的，这样便于维护代码的程序员轻松掌握代码的内容和执行方式。
5. 测试文档
测试文档将在第17～20章详细讨论，在此提出是因为它是完整的软件产品的一部分。和程序员必须对工作进行计划和进行文档记录的原因一样，测试员也必须写测试文档。软件测试小组提交的文档比程序员提交的还多的情况并不少见。
下面是比较重要的测试提交清单：
- 测试计划（test plan）。描述用于验证软件是否符合产品说明书和客户需求的整体方案。包括质量目标、资源需求、进度表、任务分配、方法等。
- 测试用例（test case）。列举测试的项目，描述验证软件的详细步骤。
- 缺陷报告（bug report）。描述执行测试用例找出的问题。可以记录在纸上，但通常记录在数据库中。
- 测试工具和自动测试（test tool and automation）。第15章“自动测试和测试工具”将详细讨论。如果测试小组使用自动化测试工具测试软件，不管是购买的还是自己编写的工具，都必须有文档记录。
- 度量、统计和总结（metric，statistic，summary）。测试过程的汇总。采用图形、表格和报告等形式。
2.1.2 软件产品由哪些部分组成
到目前为止，我们知道了制作软件产品所需的投入。同样重要的是，要认识到当产品打包分发时，分发的不仅仅是代码，许多支持也包含在内（见图2-3）。由于所有这些部分客户都要查看或使用，所以也需要测试。
遗憾的是，这些部分常常在测试过程中被忽略。你一定试图使用过产品本身的帮助文件，发现其不实用或者—糟糕—甚至错误，或者你检查购买的软件产品包装盒上的系统要求，却发现按它所述无法在自己的机器上运行。这些虽然看上去很容易测试，在产品制作完成并发布之前甚至可能没有人愿意看它们第二眼，但是软件测试员要检查这些。
本章后面将讲述这些非软件部分，以及如何正确测试。在此之前，请牢记下面的清单，从而对软件产品不仅限于代码这点有个初步印象：
**帮助文件 用户手册
样本和示例 标签和不干胶
产品支持信息 图标和标志
错误信息 广告和宣传材料
安装 说明文件**
别忘了测试错误提示信息
错误提示信息是软件产品最容易忽视的部分，通常由程序员而不是训练有素的高手来写。他们很少计划这些信息，在修复软件缺陷时常常造成麻烦。软件测试员也难以找到并显示全部信息。千万不要让以下错误提示信息出现在软件中：
2.2 软件项目成员
知道了软件产品由什么组成、附带了什么之后，现在该搞清楚制作软件的人员了。当然，公司和项目不同，人员也就大不相同。但是对于大多数情况，分工是一样的，只是叫法不同而已。
下面的清单不按次序地列出了主要人员及其职责。给出了最常用的名称，但是不包括变动和增加等情况：
- 项目经理、程序经理或者监制人员自始至终驱动整个项目。他们通常负责编写产品说明书，管理进度，进行重大决策。
- 架构师或者系统工程师是产品小组中的技术专家。他们一般经验丰富，可以胜任整个系统的体系结构或软件设计工作。他们的工作与程序员关系紧密。
- 程序员、开发人员或者代码制作者设计、编写软件并修复软件中的缺陷。他们与项目经理和设计师密切合作制作软件，然后与项目经理和测试员密切合作修复缺陷。
- 测试员或质量保证（Quality Assurance，QA）员负责找出并报告软件产品的问题。他们与开发小组全部成员在开发过程中密切合作，进行测试并报告发现的问题。第21章“软件质量保证”完整地讲述了软件测试和软件质量保证任务的差别。
- 技术作者、用户协助专员、用户培训专员、手册编写员或者文案专员编制软件产品附带的文件和联机文档。
- 配置管理员或构建员**负责把程序员编写的代码及技术作者写的全部文档资料组合在一起，合成为一个软件包。
可见，一个软件产品需要多个小组协作。大型的小组可能有数十甚至上百人共同协作。为了更好地交流和组织管理，就需要制定计划，即从一点过渡到另外一点的方法。这正是下一节讨论的话题。
2.3 软件开发生命周期模式
计算机行业流行一个笑话：有三样东西在制造过程中是永远看不见的—法律、香肠和软件。它们的制造过程混乱复杂、令人生厌，以致最好只看最后的结果。这种说法不一定全对，但是俗话说无风不起浪。有些软件开发严格有序、精工细作，有些软件控制混乱不堪，还有的软件则是一堆杂乱无章的垃圾。一般来说，客户最终可以清楚地看出开发过程如何。软件产品从最初构思到公开发行的过程称为软件开发生命周期模式。
如前所述，在开发软件过程中有各种不同的方法。对特定项目而言，没有哪个模式一定是最好的。以下是4种最常用的模式，其他模式只是这些模式的变形：
- 大爆炸模式
- 边写边改模式
- 瀑布模式
- 螺旋模式
每个模式都有它自己的优点和缺点。作为测试员，可能会遇到以上所有模式，你需要根据当前项目采取的模式来定制测试的方法。在学习后面的内容时，考虑针对每种模式，如何应用所学的不同测试技术。
2.3.1 大爆炸模式
关于宇宙的形成有一种大爆炸说，数百亿年前，一股无穷的能量大爆炸创造了宇宙。世界万物皆由能量和粒子排列而成，于是有了这本书、DVD和比尔·盖茨。假如原子没有正确排列，这些事物就会变成一堆烂泥。
图2-4所示的软件开发大爆炸模式与上述理论一样。一大堆东西（人力和资金）放在一起，巨大的能量释放—通常很野蛮—产生了优秀的软件产品—或者一堆废品。
大爆炸模式的优点是简单。计划、进度安排和正规开发过程几乎没有，所有精力都花在开发软件和编写代码上。假如产品需求无须很好理解，而且最终发布日期可以随便更改，这样的开发过程当然很理想。此外，还要有聪慧过人的客户，因为他们直到最后才知道自己会拿到什么样的软件。
注意图2-4中没有出现测试。多数情况下，大爆炸模式几乎没有什么测试。假如有的话，也要挤在产品发布前进行。这种模式下居然有测试的容身之地真是令人感到神奇，也许是进行测试会使大家感觉好一些。
假如要测试员参与大爆炸模式下生产产品的测试，会面临一个既容易又困难的任务。因为软件已经完成，测试员手里有了完美的产品说明书—产品本身。但同时，因为不可能回头修复已经打乱的事情，软件测试的工作其实就是报告发现的问题让客户知道。
更差的情况是，从项目管理的角度看，产品已经完工，准备交付，因此软件测试员的工作妨碍了交付。测试工作越深入，会发现越来越多的软件缺陷，争吵就越多。尽量避开在此模式下进行测试。
2.3.2 边写边改模式
图2-5所示的边写边改模式是项目小组在未刻意采用其他开发模式时默认的开发模式。这是在大爆炸模式基础上更进了一步，至少考虑到了产品需求。
一位智者曾说过：“没有时间做好，但总有时间完成。”这是该模式的真实写照。采用这种方式的小组通常最初只有粗略的想法，接着进行一些简单的设计，然后开始来回编写、测试和修改缺陷的漫长过程。等到觉得足够了，就发布产品。
由于开头几乎没有计划和文档编制，项目小组得以迅速展现成果。因此，边写边改模式极其适合意在快速制作而且用完就扔的小项目，例如原型范例和演示程序。即便如此，许多著名的软件仍然采用了边写边改模式。如果文字处理或者电子表格软件存在大量软件缺陷，或者功能似乎不完备，就可能是在边写边改模式下制造出来的。
与大爆炸模式类似，测试在边写边改模式中未特别强调，但是在编写代码和修复缺陷过程中举足轻重。
作为边写边改的项目的软件测试员，需要和程序员一样清醒地认识到自己将陷入无休止的循环往复。几乎每一天都会拿到新的软件版本并着手进行测试。当新版本出来时，旧版本的测试可能尚未完成，而新版本还可能包含新的或者经过修改的功能。最后，终于有机会对几乎所有功能进行测试了，并且发现软件缺陷越来越少，这时某人（或者进度）决定该发布软件了。
在进行软件测试工作期间，边写边改模式是最有可能碰到的。这种模式是软件开发的入门，有助于理解更加正规的方法。
2.3.3 瀑布模式
瀑布模式常常是编程学校所教的第一课，现在已经无处不在。它简捷、精致，很有意义，在合适的项目中效果显著。图2-6给出了该模式的步骤。
采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时，项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来，直到准备好。
关于瀑布模式有三点需要强调：
- 瀑布模式非常强调产品的定义。注意，开发或者代码编制阶段只是其中单独的一块。
- 瀑布模式各步骤是分立的，没有交叉。
- 瀑布模式无法回溯。一旦进入某个步骤，就要完成该步骤的任务，然后才能向下继续—无法回溯。
看起来似乎限制太多，实际上也是如此。但是，对于拥有明确清晰的产品定义和训练有素的开发人员的项目而言，该模式的效果很好。该模式的目标是在编写代码之前解决所有的未知问题并明确所有细节。缺点是，在这个变化迅速、在互联网上开发产品的时代，当软件产品还在细细考虑和定义时，当初制造它的理由可能变了。
从测试的角度来看，瀑布模式比截至目前的其他模式更有优势。瀑布模式下所有一切都有完整细致的说明。当软件提交到测试小组时，所有细节都已确定并有文档记录，而且实现在软件之中。由此，测试小组得以制定精确的计划和进度。测试对象非常明确，在分辨是功能还是缺陷上也没有一点问题。
然而，这个优点也带来一个巨大的缺点。因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现。还记得第1章“软件测试的背景”中所讲的软件缺陷修复费用怎样随时间增长吗？我们需要一个可以在早期费用不大时就执行测试的模式。
2.3.4 螺旋模式
尽管螺旋模式不太理想，但是该模式（见图2-7）确实经历了很长的路来解决其他模式中存在的问题，同时有一些好的突破。
螺旋模式于1986年由Barry Boehm在美国计算机协会（Association for Computing Machinery，ACM）的论文“一种软件开发的螺旋模式和加强”中引入。目前使用相当广泛，并被证实是开发软件的有效手段。
螺旋模式的总体思想是一开始不必详细定义所有细节。从小开始，定义重要功能，努力实现这些功能，接受客户反馈，然后进入下一阶段。重复上述过程，直至得到最终产品。
螺旋模式每一次循环包括6个步骤：
1）确定目标、可选方案和限制条件。
2）明确并化解风险。
3）评估可选方案。
4）当前阶段开发和测试。
5）计划下一阶段。
6）确定进入下一阶段的方法。
螺旋模式中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边写边改模式（螺旋模式的每一次）和一点大爆炸模式（从外界观察）。加上该模式发现问题早、成本低的特点，可以算作相当好的开发模式。
软件测试员喜欢该模式。因为通过参与最初的设计阶段，可以尽早地影响到产品，可以把产品的来龙去脉弄得很清楚；并且在项目末期，不至于最后一分钟还在匆匆忙忙地进行全面测试。软件测试员的测试一直都在进行，所以最后一步只是验证表面的所有部分都没有问题。
敏捷软件开发
有一种开发过程受到许多软件公司的喜爱，叫作敏捷软件开发（Agile Software Development）。我们也许听说过它的另外一些名称，如快速原型、极限编程或进化开发等。
如网站www.agilemanifesto.org
上的敏捷宣言中所述，敏捷软件开发的目的是：
“通过过程和工具理解个人和交流的作用
通过全面的文档理解运行的软件
通过合同和谈判得到客户的协作
在计划的执行中做出对变更的响应
也就是说，在一方面有价值的时候，更应评价它在另外一方面的价值”
敏捷软件开发取得了一定的发展，也有一些成功的项目，但远未成主流。敏捷软件开发中，如果开发人员和他的项目陷在了过程和文档中的话，它就似乎成了深奥的哲学，在我看来，敏捷软件开发很容易偏离主题而造成混乱。一种方法是先观察、了解，再决定是否采用此方法。目前，我并不想像坐喷气式飞机一样，用一个极限编程员采用快速原型法来开发软件。也许以后会。
想了解更多的信息，参考两本Sams出版社出版的书—《Agile Modeling, Teach Yourself Extreme Programming in 24 Hours》和《Extreme Programming Practices in Action》。
## 小 结
现在我们知道了软件产品是如何制作的—包括所有组成部分及其合成过程。可以看到，制造产品无定式可言，本章所讲的4个模式就是例证。当然还有许多其他模式以及这些模式的变形模式。每一个公司、每一个项目和每一个小组都会选择适合自身情况的模式，选择有可能是对的，也有可能是错的。软件测试员的工作是在所处的开发模式中尽最大的努力工作，运用本书所讲的测试技术创造出尽量完善的软件。
##小测验
以下是帮助读者加深理解的小测验。答案参见附录A—但是不要偷看！
- 说出在程序员开始编写代码之前要完成哪些任务。
- 正式并被锁定不能修改的产品说明书有何缺点？
- 软件开发大爆炸模式的最大优点是什么？
- 采用边写边改模式时，如何得知软件发布的时间？
- 瀑布模式为什么不好用？
- 软件测试员为什么最喜欢螺旋模式？
