软件测试

图1.2开发进度表

4.设计文档

一个常见的错误观念是当程序员创建程序时，没有计划直接就开始编写代码。对于稍大一些的程序而言，就必须要有一个计划来编写软件的设计过程。 下面是一些常用软件设计文档的内容。

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

（2）数据流示意图。表示数据在程序中如何流动的正规示意图，有时被称为泡泡图。 （3）状态变化示意图。把软件分解为基本状态或者条件的另一种正规示意图，表示不同状态间变化的方式。

（4）流程图。用图形描述程序逻辑的传统方式。流程图现在虽不流行了，但是一旦投入使用，根据详细的流程图编写程序代码是很简单的。

（5）注释代码。在软件代码中嵌入有用的注释是极为重要的，这样便于维护代码的程序员轻松掌握代码的内容和执行方式。

5.测试文档

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

下面是一般测试文档所包含的内容。

（1）测试计划。描述用于验证软件是否符合产品说明书和客户需求的整体方案。 （2）测试案例。列举测试的项目，描述验证软件的详细步骤。

（3）软件缺陷报告。描述依据测试案例找出的问题。可以在纸上记录，但通常记录在数据库中。

（4）归纳、统计和总结。把生产过程转化为测试过程，采用图形、表格和报告等形式。

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

软件产品不仅仅应当关心程序代码，还要关注各种各样的技术支持，这些部分通常由客户使

1

用或查看，所以也需要进行测试。

下面列出软件产品除程序代码之外的其他各种组成。 （1）帮组文件； （2）用户手册； （3）样本和示例； （4）标签；

（5）产品支持信息； （6）图标和标志； （7）错误信息；

（8）广告和宣传材料； （9）软件的安装； （10）软件说明文件； （11）测试错误提示信息；

1.3.2开发人员角色

软件开发过程中，软件开发人员各司其职，根据职责的不同分为多种角色。

1.项目经理

项目经理负责管理业务应用开发或者软件和系统开发项目。项目经理角色计划、管理和分配资源，确定优先级，协调用户和客户的交互。项目经理也要建立一系列的实践活动以确保项目工作产品的完整性和质量。

2.业务分析人员

业务分析人员的任务是理解和描绘客户的需求，引导和协调用户和业务需求的收集和确认，使其文档化，组织系统的需求，或者向整个团队传达需求。

3.架构师

架构师负责理解系统的业务需求，并创建合理、完善的系统体系架构。架构师也负责通过软件架构来决定主要的技术选择。典型的包括识别和文档化系统的重要架构方面，包括系统的需求、设计、实现和部署“视图”。

4.数据设计人员

对于大多数的应用开发项目来说，用于持久存储数据的技术是关系型数据库。数据库架构师负责定义详细的数据库设计，包括表、索引、视图、约束、触发器、存储过程和其他的特定数据库用于存储、返回和删除持久性对象的结构。

5.开发人员

开发人员通常负责设计和实现可执行的代码方案、测试开发出的组件和分析运行时情况，以去除可能存在的错误。有时开发人员还负责创建软件的体系架构或者使用快速开发工具。

6.测试人员

系统测试人员负责制定测试计划并依照测试计划进行测试。这些测试包括功能性的测试（黑盒测试）和非功能性的测试（白盒测试）。测试人员需要良好的测试工具来辅助完成测试任务，自动化的测试工具将大幅度提高测试人员的工作效率和质量。

1.3.3软件开发模式

2

1.大棒模式

大棒模式的优点是简单，计划、进度安排和正规开发过程几乎没有。软件项目组成员的所有精力都花在开发软件和编写代码上，它的开发过程是非工程化的。

大棒模式的软件测试通常是在开发任务完成后进行，也就是说已形成了软件产品才进行测试。测试工作有的较为容易，有的则非常困难，这是因为软件及其说明书在最初就已经完成，待形成产品后，已经无法回头修复存在的问题，所以软件测试的工作只是向客户报告软件产品经过测试后发现的情况。

软件产品开发工作应当避免采用大棒模式作为软件开发的方法。

2.边写边改模式

边写边改模式是项目小组在未刻意采用其他开发模式时常用的一种开发模式。它是在大棒模式基础上的一个进步，考虑到了软件产品的要求。 采用这种方式的软件开发通常最初只有初略的想法，就进行简单的设计，然后开始较长的反复编写、测试和修复过程，在认为无法更精细地描述软件产品要求时就发布产品。

因为从开始就没有计划和文档的编制，项目组能够较为迅速地展现成果。因此，边写边改模式适合用在快速制作而且用完就扔的小项目上。

处于边写边改开发项目的软件测试人员将和程序员一起陷入可能是长期的循环往复的一个开发过程。通常，新的软件（程序）版本在不断地产生，而旧的版本的测试工作可能还未完成，新版本还可能又包含了新的或修改了的功能。

在进行软件测试工作期间，边写边改开发模式最有可能遇到。虽然它有缺点，但它是通向采用合理软件开发的路子，有助于理解更正规的软件开发方式。

3.瀑布模式

瀑布模式是将软件生命周期的各项活动规定为按照固定顺序相连的若干个阶段性工作，形如瀑布流水，最终得到软件产品。

瀑布模式具有的优点是：易于理解；调研开发呈阶段性；强调早期计划及需求调查；确定何时能够交付产品及何时进行评审与测试。

但同时瀑布模式也存在一些缺点，如：需求调查分析只进行一次，不能适应需求的变化；顺序的开发流程，使得开发中的经验教训不能反馈到该项目的开发中去；不能反映出软件开发过程的反复性与迭代性；没有包含任何类型的风险评估；开发中出现的问题直到开发后期才能显露，因此失去了及早纠正的机会。

4.快速原型模式

快速原型模式是一种以计算机为基础的系统开发方法，它首先构造一个功能简单的原型系统，然后通过对原型系统逐步求精，不断扩充完善得到最终的软件系统。原型就是模型，而原型系统就是应用系统的模型，它是待构筑的实际系统的缩小比例模型，但是保留了实际系统的大部分性能。这个模型可在运行中被检查、测试、修改，直到它的性能达到用户需求为止，因而这个工作模型很快就能转换成原样的目标系统。 快速原型模式的主要优点在于它是一种支持用户的方法，使得用户在系统生存周期的设计阶段起到积极的作用；它能减少系统开发的风险，特别是在大型项目的开发中，对项目

3