《软件测试》第二章软件开发的过程

2.1 产品的组成部分
- 2.1.1 软件产品需要多少投入
- 2.1.2 软件产品由哪些部分组成
2.2 软件项目成员
2.3 软件开发生命周期模式
- 2.3.1 大爆炸模式
- 2.3.2 边写边改模式
- 2.3.3 瀑布模式
- 2.3.4 螺旋模式
2.4 小结

2.1 产品的组成部分

2.1.1 软件产品需要多少投入

客户需求

利用焦点人群审视软件功能。从软件产品的潜在客户中获得直接反馈的流行做法是借助焦点人群。焦点人群通常由办公室设在商业场所的独立问卷调查公司来组织。问卷调查人员通常穿行于商场中，手持笔记本询问过路人是否愿意参加调查。他们问一些诸如“家里有PC吗？使用某某软件吗？用了多长时间？”之类的小问题来确定对象。如果遇到符合条件的对象，他们会邀请你花一些时间到公司加入焦点人群。在公司里调查问卷人员会询问你计算机软件方面更详细的问题，并可能向你展示各种软件包装让你挑选最喜欢的，或者，与你探讨新产品中你喜欢的功能。最妙的是，你花了时间，得到了相应的报酬。

产品说明书

对客户需求的研究结果其实只是原始资料，并没有描述要做的产品，只是确定是否需要做（或不需要做）以及客户要求的功能。产品说明书综合上述信息以及没有提出但必须要实现的需求，真正地定义产品是什么、有哪些功能、外观如何。

进度表

制作进度的目的是了解哪项工作完成了，还有多少工作要做，何时全部完成。

软件设计文档

根据公司和项目合作小组的不同，程序员的文档千差万别，但其目的都是规划、组织即将编写的代码。一些常用的软件设计文档的清单如下：

结构文档。描述软件整体设计的文档，包括软件所有主要部分的描述以及相互之间的交互方式。

数据流图。表示数据在程序中如何流动的正规示意图。

状态转换图。把软件分解为基本状态或者条件的另一种正规示意图，表示不同状态间转换的方式。

流程图。用图形描述程序逻辑的传统方式。

代码注释。

测试文档

和程序员必须对工作进行计划和进行文档记录的原因一样，测试员也必须写测试文档。下面是比较重要的测试提交清单：

测试计划。描述用于验证软件是否符合产品说明书和客户需求的整体方案。包括质量目标、资源需求、进度表、任务分配、方法等。

测试用例。列举测试的项目，描述验证软件的详细步骤。

缺陷报告。描述执行测试用例找出的问题，通常记录在数据库中。

测试工具和自动测试。如果测试小组使用自动化测试工具测试软件，不管是购买的还是自己编写的工具，都必须有文档记录。

度量、统计和总结。测试过程的汇总。采用图形、表格和报告等形式。

2.1.2 软件产品由哪些部分组成

当产品打包分发时，分发的不仅仅是代码，许多支持也包含在内。由于这些部分用户都要查看或使用，所以也需要测试。

别忘了测试错误提示信息。错误提示信息是软件产品最容易忽视的部分，通常由程序员而不是训练有素的高手来写。他们很少计划这些信息，在修复软件缺陷时常常造成麻烦。软件测试员也难以找到并显示全部信息。

2.2 软件项目成员

项目经理、程序经理或监制人员自始至终驱动整个项目。他们通常负责编写产品说明书，管理进度，进行重大决策。
架构师或者系统工程师是产品小组中的技术专家。他们一般经验丰富，可以胜任整个系统的体系结构或软件设计工作。他们的工作与程序员关系紧密。
程序员、开发人员或者代码制作者设计、编写软件并修复软件中的缺陷。他们与项目经理和设计师密切合作制作软件，然后与项目经理和测试员密切合作修复缺陷。
测试员或质量保证员负责找出并报告软件产品的问题。他们与开发小组全部成员在开发过程中密切合作，进行测试并报告发现的问题。
技术作者、用户协助专员、用户培训专员、手册编写员或者文案专员编制软件产品附带的文件和联机文档。
配置管理员或构建员负责把程序员编写的代码及技术作者写的全部文档资料组合在一起，合成为一个软件包。

2.3 软件开发生命周期模式

软件产品从最初构思到公开发行的过程称为软件开发生命周期模式。作为测试员，需要根据当前项目采取的模式来定制测试的方法。

2.3.1 大爆炸模式

如上图所示，一大堆东西（人力和资金）放在一起，巨大的能量释放——通常很野蛮——产生了优秀的软件作品——或者一堆废品。

大爆炸模式的优点是简单。计划、进度安排和正规开发过程几乎没有，所有精力都花在开发软件和编写代码上。

多数情况下，大爆炸模式几乎没有什么测试。加入要让测试员参与大爆炸模式下生产产品的测试，会面临一个既容易又困难的任务。因为软件已经完成，测试员手里有了完美的产品说明书——产品本身。但同时，，因为不可能回头修复已经打乱的事情，软件测试的工作就是报告发现的问题让客户知道。更差的情况是，从项目管理的角度看，产品已经完工，准备交付，因此软件测试员的工作妨碍了交付。测试工作越深入，会发现越来越多的软件缺陷，争吵就越多。尽量避开在此模式下进行测试。

2.3.2 边写边改模式

边写边改模式是项目小组在未刻意采用其他开发模式时默认的开发模式。这是在大爆炸模式基础上更进了一步，至少考虑到了产品需求。

采用这种方式的小组通常最初只有粗略的想法，接着进行一些简单的设计，然后开始来回编写、测试和修改缺陷的漫长过程。等到觉得足够了，就发布产品。

由于开头几乎没有计划和文档编制，项目小组得以迅速展现成果。因此，边写边改模式极其适合意在快速制作而且用完就扔的小项目。

与大爆炸模式类似，测试在边写边改模式中未特别强调，但是在编写代码和修复缺陷过程中举足轻重。作为边写边改的项目的软件测试员，需要和程序员一样清醒地认识到自己将陷入无休止的循环往复。几乎每一天都会拿到新的软件版本并着手测试。当新版本出来时，旧版本的测试可能尚未完成，而新版本还可能包含新的或者经过修改的功能。最后，终于有机会对几乎所有功能进行测试了，并且发现软件缺陷越来越少，这时，某人（或者进度）决定该发布软件了。

2.3.3 瀑布模式

采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时，项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来，直到准备好。

注意：

瀑布模式非常强调产品的定义。开发或者代码编制阶段只是其中单独的一块。
瀑布模式各步骤是分立的，没有交叉。
瀑布模式无法回溯。一旦进入某个步骤，就要完成该步骤的任务，然后才能向下继续——无法回溯。

该模式的目标是在编写代码之前解决所有的未知问题并明确所有细节。缺点是，在这个变化迅速、在互联网上开发产品的时代，当软件产品还在细细考虑和定义时，当初制造它的理由可能变了。

从测试角度看，瀑布模式比截至目前的其他模式更有优势。瀑布模式下所有一切都有完整细致的说明。当软件提交到测试小组时，所有细节都已确定并有文档记录，而且实现在软件之中。由此，测试小组得以指定精确的计划和进度。测试对象非常明确，在分辨是功能还是缺陷上也没有一点问题。

然而，因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现。由于软件缺陷修复费用随时间指数级增长，我们需要一个可以在早期费用不大时就执行测试的模式。

2.3.4 螺旋模式

螺旋模式的总体思想是一开始不必详细定义所以细节。从小开始，定义重要功能，努力实现这些功能，接受客户反馈，然后进入下一阶段。重复上述过程，直至得到最终产品。

螺旋模式每一次循环包括6个步骤：

确定目标、可选方案和限制条件。
明确并化解风险。
评估可选方案。
当前阶段开发和测试。
计划下一个阶段。
确定进入下一阶段的方法。

螺旋模式中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边写边改模式（螺旋模式的每一次）和一点大爆炸模式（从外界观察）。加上该模式发现问题早、成本低的特点，可以算作相当好的开发模式。

敏捷开发模式下的测试

2.4 小结

现在我们知道了软件产品是如何制作的——包括所有组成部分及其合成过程。可以看到，制造产品无定式可言，本章所讲的4个模式就是例证。当然还有许多其他模式以及这些模式的变形模式。每一个公司、每一个项目和每一个小组都会选择适合自身情况的模式，选择有可能是对的，也有可能是错的。软件测试员的工作是在所处的开发模式中尽最大的努力工作，运用本书所讲的测试技术创造出尽量完善的软件。