软件研发流程中的软件测试流程设计

　　软件测试生命周期一般包括7个阶段：1)计划 2)分析，3)设计，4)构建，5)测试周期，6)最后测试和实施，7)实施后。

　　1. 计划(产品定义阶段)

　　 高层次的测试计划(包含多重测试周期)

　　 质量保证计划(质量目标，测试标准等 )

　　 确定计划评审的时间

　　 报告问题过程

　　 确定问题的分类

　　 确定验收标准-给质量保证员和用户。

　　 建立应用程序测试数据库

　　 确定衡量标准，例如缺陷数量/严重程度和缺陷起源(仅举几个例子) 。

　　 确定项目质量度量

　　 开始制定项目整体测试时间表(时间，资源等)

　　 必需阶段：评审产品定义文档

　　 文档中加入质量保证标准，作为工程改善进程的一部分

　　 根据该产品的特点帮助确定问题的范围

　　 大约每月要花5 -1 0小时在这一方面

　　 计划在数据库管理所有测试用例，包括手工方面或者自动化方面。

　　2. 分析(外部文档阶段)

　　 根据业务需求开发功能验证矩阵。

　　 制定测试用例格式-估计时间和分配优先级。

　　 制定测试周期矩阵与时间线

　　 根据功能验证矩阵开始编写测试用例

　　 根据业务需求计划测试用例基准数据

　　 确定用于自动化测试的测试用例。

　　 自动化团队开始在测试工具中创建变量文件和高层次的测试脚本。

　　 为自动化系统中的跟踪组件设置路径和自动化引导。

　　 界定压力和性能测试的范畴。

　　 按照每个测试用例的数据要求开始建立基准数据库。

　　 定义维护基准数据库的过程，即备份，恢复，验证。

　　 开始规划项目所需的测试周期数，和回归测试次数。

　　 开始文档复查，如：功能设计文档，业务需求文档，产品规格说明书，产品外部文档等。

　　 审查测试环境和实验室，前端与后端系统都要。

　　 准备使用McCabe工具，以支持白盒测试中代码的研发和复杂性分析

　　 建立反馈机制并开始录入文档。

　　 必需阶段：审查外部文件

　　 文档中加入质量保证标准，作为工程改善进程的一部分。

　　 根据群体执行反馈编写测试用例

　　 开始研制测试用例估计数目，每个用例的执行时间，和用例是否自动化这些方面的度量

　　 为每个测试用例确定基准数据，

　　 大约每月要花25小时在这一方面

　　3. 设计(文档架构阶段)

　　 根据变更修改测试计划

　　 修改测试周期矩阵和时间线

　　 核实测试计划和用例用到的数据都输入到数据库，或是否必需的。

　　 修改功能验证矩阵

　　 继续编写测试用例，根据变化添加新的用例

　　 制定风险评估标准

　　 规范自动化测试和多用户测试的细节。

　　 挑选出一套用于自动化测试的测试用例，并且把这些用例脚本化

　　 规范压力测试和性能测试的细节。

　　 最终确定的测试周期。 (根据用例的估计时间和优先权确定每个周期所用的测试用例数)

　　 最终确定的测试计划

　　 估计单元测试所需资源

　　 必需阶段：审查架构文件

　　 文档中加入质量保证标准，作为工程改善进程的一部分。

　　 确定要进行编码的的实际组件或模块

　　 在这定义单元测试标准，通过/失败准则等。

　　 单元测试报告，报告进行单元测试后的模块质量如何，白盒测试和黑盒测试都要包括输入/输出数据和所有决定点。

　　 列出所有要进行单元测试的模块

　　4. 构建(单元测试阶段)

　　 完成所有计划

　　 完成测试周期矩阵和时间线

　　 完成所有测试用例。 (手动)

　　 完成第一套自动化测试用例的测试脚本。

　　 完成压力和性能测试的计划

　　 开始压力和性能测试

　　 McCabe工具支持-提供度量

　　 测试自动化测试系统，并修复错误。

　　 发展单元测试

　　 运行质量保证验收测试套件，以确保软件已经可以交给QA测试。

　　5. 测试周期/ 错误修正( 重复/系统测试阶段)

　　 测试周期1，执行第一套的测试用例(前端和后端)

　　 报告错误

　　 错误审核-不断开展的活动。

　　 根据需求修改测试用例

　　 根据需求增加测试用例

　　 测试周期二

　　 测试周期三

　　6. 最后的测试和实施(代码冻结阶段)

　　 执行所有前端测试用例-人工和自动化。

　　 执行所有后端测试案例-人工和自动化。

　　 执行所有压力和性能测试。

　　 提供对正在进行的缺陷跟踪度量。

　　 提供对正在进行的复杂性和设计的度量。

　　 更新测试用例和测试计划的估计时间。

　　 文件测试周期，回归测试，并更新相应文档。

　　7. 实施后

　　 开展实施后评估会议以回顾整项工程。 (经验所得)

　　 准备最终的缺陷报告和相关度量。

　　 制定战略以防止类似的问题在今后的项目中重复出现。

　　 创建如何改进流程的计划目标和里程碑，

　　 McCabe工具-制作最后的报道和分析。

　　 自动化测试组-1 )审查测试用例以评估其他可用于自动化回归测试的用例2 )清理自动化测试用例和变量，和3 )审查自动化测试和手工测试结果的整合过程

　　 测试实验室和测试环境-清理测试环境，标记和存档用过测试用例和数据，恢复测试仪器到原始状态等。

　　1、 引言

　　有很多种不同的生命周期模型用于软件的开发。软件开发的生命周期是以对软件的需求定义为起点，以对软件的正式验收作为终点。

　　它并不是独立存在的，而是一个完整产品生命周期实实在在的一部分。在产品生命周期之中，软件的开发会不断改正其自身的错误并且时常针对软件的需求而进行调整。软件产品最简单的形式只不过是一个程序软件，但实际上确没有那么简单，由于软件产品是由开发出的不同软件部分所构成的一个完整的系统，这将会使产品变的非常复杂。

　　有许多不同的软件开发生命周期模型，但是它们都有一个共同的特点，那就是在生命周期中的某一时刻，软件都会被测试。这篇文章概述了一些常用的软件生命周期模型，并重点强调了在各个模型中的测试工作。

　　2、 顺序生命周期模型

　　软件开发生命周期模型以需求定义为开端，以对需求的正式验收作为终结。传统意义上，被用于软件开发生命周期的模型应该是顺序的并且开发过程的各个阶段都经过完善的定义。通常用V型生命周期模型和瀑布生命周期模型来表示这种顺序的开发过程。而事实上，这两种生命周期模型有许多不同的形态，将不同的阶段引入生命周期模型，并在不同阶段之间设立边界。以下介绍的生命周期模型的各个阶段是经过许多最有经验的开发者经过反复实践而得来的。

　　图1、V型生命周期模型

　　图2、瀑布生命周期模型

　　* 需求分析阶段

　　这个阶段主要是收集并分析用户的需求，并且根据软件需求建立完整而明确的需求说明书。

　　* 概要设计阶段

　　在这个阶段，针对用户需求的软件结构将会被设计，并确定软件内部各个部件的相关联系。

　　* 详细设计阶段

　　软件各个部件的执行功能将被详细说明。

　　* 遍码与单元测试阶段

　　在本阶段，将对软件的各个部件进行编码，并且进行单元测试以确定各个部分确实执行了详细设计阶段所制定的目标。

　　* 软件集成阶段

　　这个阶段被测试过的各个部件被逐渐集成起来测试直到构成了一个完整的软件。

　　* 系统集成阶段

　　这个阶段将软件程序集成起来，构成产品并进行测试。

　　* 验收测试阶段

　　这个阶段将进行测试以验证软件确实完整的执行了用户的需求。

　　3、 渐进开发生命周期模型

　　顺序模型(V型和瀑布生命周期模型)只是代表着一种理想化的软件开发模型。但实际上出于种种原因，例如需求的多变性和为应付过长的开发时间而开发零时系统的需要，还有其它的生命周期模型将会被采用。

　　现在，让我们以渐进开发的迭代生命周期为例，来看一下其它的生命周期模型。软件开发所具有的一个问题就是用户急需软件产品，但是开发者却要花费很长的时间去完整地进行开发。那么取一个折中的解决方法就是节省一些时间，但在功能上打一点折扣——开发出一个功能有所缩减的试用版给用户，作为完整版发布前的一个跳板。也可以将这个跳板作为软件减少软件开发风险的一种方式。

　　在软件开发中，通常将这种方法称为渐进开发或是执行阶段。与之相对应的生命周期模型被称为渐进开发生命周期模型。在渐进开发的生命周期之中，每一个独立的阶段都将遵从V型和瀑布型生命周期模型。

　　图3、渐进开发生命周期

　　每一个软件的发布都会经过验收测试以证明软件的各个部分所构成的整体确实实现了需求。但是每个阶段的测试和集成将会耗费大量的时间和精力。由于过多的开发周期会增加成本，耗费时间，所以应该经过认真估算，尽早地规划好到底应该使用多少个周期来进行软件的开发。

　　在早期开发出来的产品没有任何的实用价值，只是作为下一步开发的一个原型。这些原型仅仅是用来满足、核对用户关键需求所走的一个捷径。可是如果其中缩减了文档的书写和对软件的测试，那么就有必要将这些将这个原型抛弃并从下一个阶段开始重新设计。因为一个缺乏质量的原形不可能给下一步的开发打下一个好基础。

　　4、 迭代生命周期模型

　　迭代生命周期模型并不是一开始就完全适应需求，而是先根据说明先开发软件的部分些可执行部件。而是先开发一些具有部分功能的部件，这些部件要求能够通过审查以确定更进一步的需求。不断重复这个过程，为此模型的每一个周期遍写出更新版本的软件。

　　一个迭代周期模型由下图的四个连续部分组成不断重复组成。

　　图4、迭代生命周期模型

　　*　需求分析阶段

　　在这个阶段，主要是收集并分析用户的需求，并且制定这个迭代模型最终并且完整的需求说明书。

　　*　定义阶段

　　在这个阶段，设计出适应需求的软件解决方案。这有可能是一个全新的设计，也有可能是原来设计的一个延伸。

　　*　执行、测试阶段

　　在这个阶段，将对软件进行编码，集中并进行测试。

　　*　审查阶段

　　在这个阶段，将对软件进行评估，对目前的需求进行审查，并对其进行修改和更新。

　　在迭代模型的每一个周期，都要作出一个决定：要将编写出的软件抛弃，还是作为下一个周期的起点。如果软件完全符合了需求，那么就可以进行发布，否则就是一个失败的开始。

　　迭代生命周期模型可以说是采用了一种连续逼近的方式来制作软件。将这种方式类比成一个连续逼近最终解决方案的数学模型，那么这种方式能否成功的关键就是多快能够形成解决方案。

　　也许经过不断的类比也不能找到解决方案，而迭代的过程不是在可行的解决方案周围盘旋就是逐渐远离目标。而且需要迭代的次数太过庞大会使软件开发变得不切实际，在很多软件开发的过程中我们都能发现这个问题。

　　成功运用迭代软件生命周期模型来开发的关键就是要严格按照需求，并且根据需求对每个周期制造出来的各版本软件进行验收(包括测试)。迭代模型的前三个阶段就好比是简化版本的V型模型或是瀑布模型。迭代模型中的每一个周期所编写出来的软件都要为软件的集中，系统集中和验收进行单元测试。在迭代模型中软件的开发经历了多少个这样的周期，那么就要进行多少次这样的测试。

　　5、 维护

　　成功编写的软件最终将成为产品的一部分并进入维护阶段。在这个阶段将不断地修正软件的错误，并时常对其进行调整以适应多变的需求。正如刚开始开发一样，软件的维护也要遵循软件开发生命周期，但不一定要使用和开始相同的生命周期模型。在整个维护阶段，软件将会得到不断的测试，修正，并且扩展。对软件修正和重复多次的测试占用了整个软件开发所需费用的很大一部分。

　　6、 概要和结论

　　无论何种生命周期模型被用于软件的开发，都会对软件进行测试。质量、功能都很完美的软件产品需要在其软件开发生命周期的早期进行测试，并且无论发生什么变故，都要进行完善的回归测试。

　　在渐进、迭代生命周期中，这种行为显得尤为重要。重复测试对于软件质量的控制，在渐进、迭代模型中相比于传统的顺序生命周期模型也显得尤为重要。

　　回归测试是对软件进行维护的重要手段。在软件开发之中，由于不能完全预料到最终的结果，会进行诸多的修改。但如果不对软件使用完善回归测试，就会导致产品质量的下降。

　　软件开发管理中常犯的一个错误就是在V型模型或是瀑布模型开发的起始阶段，采用了不完善的管理制度，那最终就会引起问题的累积而使局势无法得到控制。这就是使软件开发走向失败的另一种情形。

　　AdaTEST 和 Cantata是使软件测试能够便捷，自动化，可重复，可维护的工具。对于Ada、C、C++的软件开发有重要的意义。在渐进模型或是迭代模型采用AdaTEST或是 Cantata进行重复的维护性软件测试，对于软件开发会有更大的收益。

　　还有很多软件开发生命周期模型在这里没有提到，然而那些模型大都遵循这里提到的一些形式，基本上共用相同的道具，AdaTEST 和 Cantata都有助于这些模型的开发。

原文转自：http://www.ltesting.net