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

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

• • 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 软件产品需要多少投入

1. 客户需求

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

2. 产品说明书

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

3. 进度表

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

4. 软件设计文档

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

• 结构文档。描述软件整体设计的文档，包括软件所有主要部分的描述以及相互之间的交互方式。
• 数据流图。表示数据在程序中如何流动的正规示意图。
• 状态转换图。把软件分解为基本状态或者条件的另一种正规示意图，表示不同状态间转换的方式。
• 流程图。用图形描述程序逻辑的传统方式。
• 代码注释。

5. 测试文档

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

• 测试计划。描述用于验证软件是否符合产品说明书和客户需求的整体方案。包括质量目标、资源需求、进度表、任务分配、方法等。
• 测试用例。列举测试的项目，描述验证软件的详细步骤。
• 缺陷报告。描述执行测试用例找出的问题，通常记录在数据库中。
• 测试工具和自动测试。如果测试小组使用自动化测试工具测试软件，不管是购买的还是自己编写的工具，都必须有文档记录。
• 度量、统计和总结。测试过程的汇总。采用图形、表格和报告等形式。

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

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

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

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

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

2.3.2 边写边改模式

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

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

注意：

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

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

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

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

2.3.4 螺旋模式

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

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

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

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

敏捷开发模式下的测试

2.4 小结

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

来源：猫的树999