3.1　软件测试过程模型

3.1.1　软件测试过程

ISO 9000将过程定义为： 一组将输入转化为输出的相互关联或相互作用的活动 。过程的任务是基于确定的人、机、料、法、环，将输入转化为输出。过程管理是指以结果为导向，使用一组实践方法、技术和工具，对过程绩效进行持续监视测量，通过有效反馈，持续改进过程，获得持续稳定的过程增值及过程能力提升。增值是过程的目标，改进是过程的方向，演化是过程的活力。一个完整的过程包括过程策划、过程设计、过程实施和过程改进四项基本活动，如图 3-1 所示。

过程策划 是根据组织战略，确定过程活动的目标、要求、流程、输入、输出及过程监视测量的指标、技术、方法和手段，识别关键过程，确定关键过程目标、过程测量指标、过程关键要求、过程有效性、过程敏捷性等要求，为过程活动有效开展及过程改进提供依据。

过程设计 是基于过程类别，建立可测量的过程KPI；确定价值创造过程和支持过程，明确过程输入及输出对象；确定过程顾客和其他相关方及要求；基于过程要求，融合相关要求、相关信息、相关技术，组织实施过程设计。

过程实施 是遵循相关标准规范，采用适宜的技术、方法和工具，持续采集并分析内外部环境因素变化及来自顾客和其他相关方的信息，在过程设计的柔性范围内，对过程设计进行调整、修偏和优化；基于监视测量信息，应用统计过程控制（Statistical Process Control，SPC）方法，控制过程输出的关键特性，确保过程处于受控状态并具有足够的过程能力。

过程改进 是为了优化、改善软件过程开展的一系列活动，包括目标驱动和缺陷驱动两种改进方式。目标驱动的过程改进方式是根据一个预定的目标，自顶而下，建立过程度量和评价模型，有目的地进行过程改进；缺陷驱动的过程改进方式是根据实际产生的关于过程缺陷的反馈信息，实施针对性的改进。在实际工作中，过程改进包括渐进式改进和突破式改进。渐进式改进是对现有过程的持续性改进，是集腋成裘式的改进；突破式改进是对过程的重大变更或使用全新过程取代已有过程。

过程监视和测量包括过程实施中及实施后的监测，旨在通过设计评审、验证确认、试验验证、过程审核，以及为实施SPC、过程改进进行的过程因素、过程输出抽样测量，检查验证过程实施是否遵循过程策划与设计要求，评价过程绩效。

基于系统工程过程思想及测试流程，解耦软件测试与软件开发过程模型的相关性，将软件测试过程活动划分为测试策划、测试设计、测试执行、测试总结四个阶段，以及贯穿于软件测试周期活动的监视和测量，构成如图3-2所示的软件测试过程模型。当然，测试过程的每个阶段活动也构成一个过程。

依据CNAS-CL01等标准规范，采用层次分析、结构化分解等方法，确定测试过程活动的输入、输出，以及测试人员、测试资源、过程控制及监视测量要求，实现过程闭环，确保过程活动受控并得以持续改进。这是一个标准化、基于流程的软件测试过程模型。

3.1.2　软件测试过程活动

3.1.2.1　测试策划

测试策划包括组织级策划和项目级策划。组织级策划由组织的质量方针和质量目标定义，纳入组织级过程。项目级策划则是基于确定的测试项目，从测试目的、质量目标、技术体制、软件架构、操作使用、运行环境、使用场景等进行多维度、多层次、多视角的正向和逆向分析，制定测试策略，确定测试要素、测试级别、测试类型、测试方法、通过准则、测试环境、资源配置、质量保证、配置管理、风险控制、计划管理等目标、内容和要求，指导最佳测试实践。

1.测试策略

测试策略是基于测试过程模型，依据特定的约束条件，确定关键过程和主要风险，制定测试目标，确定测试流程，组建测试团队，对测试生命周期过程的期望值及风险进行管理，实现开发方、测试方、顾客和用户等利益相关方的一致性目标。

2.风险分析

软件测试为软件系统验收交付、鉴定定型、上线运行、市场投放、司法鉴定、著作权登记等提供支撑，为用户建立信心。风险分析是在测试策划过程中，分析并识别软件测试过程中的资源、技术、环境、数据等风险，确定风险等级，制定基于风险的测试策略并实施风险防控措施，规避风险。

3.测试需求分析

基于系统规格、需求规格、设计文档、用户文档，依据相关标准规范、产品规范及相应规则、惯例、约定，分析确定测试需求，建立软件需求与测试需求的映射关系，以及正向和逆向的追踪关系，确定测试充分性要求及准则，确保测试需求覆盖软件需求。

4.测试大纲编制

软件测试大纲用于确定并描述软件的测试目的、测试范围、测试策略、测试级别、测试类型、测试方法、测试环境、计划进度、安全保密、知识产权保护、配置管理、质量管理、风险管理等内容。GB/T 9386—2008规定了软件测试大纲的格式及主要内容，为测试大纲编制构建了一致的对话平台。

3.1.2.2　测试设计

1.测试用例

测试用例是对某一特定测试项设计的一组测试输入、执行条件及预期结果，用于验证软件是否满足确定的需求。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。测试用例设计将在相应章节详细讨论，此处不赘述。但需要强调的是，测试用例及测试资产重用对于测试效率提升和测试质量保证具有重要意义。

2.测试代码开发

测试设计过程中，需要开发必要的测试代码，尤其是单元测试和集成测试。设计驱动模块（主程序），负责接收测试数据，并将其传送至被测模块，完成顶层模块及不能独立运行模块的测试。设计桩模块，为被测模块设计模拟其下级模块功能的替身模块，代替被测模块接口，接收或传递被测模块数据，解决被测模块的调用和返回问题。一般情况下，只要设计一个伪模块（只有入口和出口而无其他语句的模块）即可。对于逻辑驱动测试，为考察程序的执行路径，往往需要在程序中插入显示或打印语句，通过程序输出的数据流分析程序执行路径。

3.测试数据准备

为验证软件运行的正确性，测试执行前需要准备一组已经验证的数据，尤其是验收测试过程中，需要准备相关试验、使用、校核及环境等真实数据。对性能测试所需要的大批量测试数据，可以设计数据发生器，自动生成测试数据。另外，还需要一些为使被测软件正常运行所需的初始化数据和软件用户的典型数据。

4.测试脚本编制

基于测试设计、测试方法、测试资源、测试风险等约束，确定测试用例执行顺序，包括操作流程、测试输入、测试输出及期望结果，执行测试时，需要录制和编辑测试脚本。测试脚本是一组由测试工具执行、具有正规语法的测试操作指令和/或数据，以实现测试用例、导航、测试设置及测试结果比较。通常，测试脚本以文本形式保存或输出。

3.1.2.3　测试执行

在确定的环境中，执行测试用例，驱动测试，录取、分析并判断测试结果。若采用手工测试，则需要根据实际测试流程，逐一执行每个测试项，记录每一步的测试结果，当测试过程出现异常时，可以硬拷贝出错的显示画面，打印测试输出，如曲线、表格等。

当测试环境发生异常时，同步记录测试环境的异常情况，采取措施，对测试过程的正常或异常终止情况进行核对，根据核对结果，对未达到测试终止条件的测试用例，停止测试，分析原因，再行对是否继续进行测试做出决策。如果采用自动化测试工具，则由测试工具回放测试脚本进行测试，自动记录、比对和分析测试结果，生成测试结果统计图表和缺陷报告。

3.1.2.4　测试总结

基于测试过程监测数据，分析评价测试工作是否按照测试策划的流程，组织完成测试大纲规定的测试内容，是否达到测试目标；对测试大纲、测试说明的变化及受控情况，因测试异常终止未实施的测试情况，无法解决的测试问题，测试安排或测试执行能力匹配性等进行分析说明，对测试的规范性、符合性、完备性及测试质量进行评价，如果存在偏差，则需要对测试的充分性、有效性进行分析，实施并评价改进措施。列出被测软件的功能实现情况、性能达标情况、质量度量指标及问题报告单，分析被测软件与需求规格的符合性，对软件缺陷的严重性等级和缺陷处理的优先级进行划分，分析软件缺陷的严重性及分布情况，编制测试报告，对被测软件是否通过测试给出明确结论。

3.1.3　基于流程的测试过程模型

3.1.3.1　V模型

V模型定义了基本的开发过程和测试行为，描述测试过程活动与开发过程的关系，展示了动态测试的全部过程，确定了软件开发过程中需要经历的测试级别，是最具代表性、最基础的测试过程模型之一。基于V模型的测试策略包括低层测试和高层验证。低层测试旨在验证源代码的正确性，而高层验证将关注的重点放在软件系统与需求符合性的验证上。V模型如图3-3所示。

3.1.3.2　W模型

V模型将软件测试作为编码结束后查找程序错误的一项过程活动，忽视了对系统规格、需求规格、系统设计的验证和确认，与瀑布模型形成紧耦合关系，不利于过程的展开和优化。1993年，为解决V模型存在的不足，Paul Herzlich将V模型耦合成V&V模型，即W模型。与V模型相比，W模型增加了软件开发各阶段需要同步开展的验证和确认活动，强调测试与开发同步。W模型如图 3-4所示。

W模型是V模型的自然拓展，将测试过程同开发过程融为一体，每项测试活动对应一个开发行为，展示了测试与开发的并行关系，同时将程序、文档及数据作为测试对象，体现了测试贯穿于开发过程及“尽早和持续不断地进行测试”的思想，更加科学地展示了软件测试的目的和意义。

虽然V模型和W模型都将开发行为与测试行为相互对应，但W模型并不主张动态测试必须与开发阶段严格对应。例如，在某些情况下，系统测试中的功能测试、性能测试、安全性测试等即可构成动态测试的全部内容，在验收测试过程中，采信系统测试结果。同时，W模型也不限制动态测试行为必须严格地基于对应开发行为所产生的文档。

W模型同样基于瀑布模型，开发和测试保持线性的前后关系，不利于迭代支持、自发性及变更调整。对于迭代开发、敏捷开发、持续集成及基于原型的大型复杂系统开发，难以有效解决软件测试管理所面临的困难。

3.1.3.3　H模型

无论是V模型还是W模型，均基于瀑布模型，将需求分析、软件设计、编码实现过程线性展开。而工程上，这些活动可能相互交叉、相互重叠。软件测试是一个反复触发、不断迭代的过程活动，并非严格的次序关系。H模型将测试过程活动独立出来，形成一个独立过程，构建开发过程中某阶段的一次测试循环，清晰地展示测试策划、测试设计、测试执行等过程活动，贯穿于软件生命周期，与其他流程并发进行，当某个测试点准备就绪时，就可以从测试准备阶段进入测试执行阶段。H模型如图3-5所示。

H模型描述了软件开发过程中某个阶段所对应的测试活动。模型中的其他开发流程可以是任意的开发流程，如软件设计或编码实现。也就是说，只要测试准备就绪，就可以开始测试执行活动。在软件生命周期过程中，存在多个这样独立的测试活动，与其他活动并发进行，不同测试活动可以按次序进行，也可以迭代实施。

3.1.3.4　X模型

X模型针对单独的软件元素，进行相互分离的编码和测试，然后通过频繁的交接，集成为可执行程序。X模型同样也是对V模型的改进。X模型如图3-6所示。

X模型左侧描述的是对单独程序片段进行的相互分离的编码和测试，然后进行交接，集成为最终的可执行程序，随后对这些可执行程序进行测试。多条并行的曲线表示变更可能在各个部分发生。X模型定位了探索性测试，这是不进行事先计划的特殊类型测试，该方法能帮助测试人员在测试计划之外发现更多错误。但运用该模型可能造成人力、物力和财力浪费，并且对软件测试人员的能力和素质提出了更高的要求。

3.1.4　基于RUP的测试过程模型

统一开发过程（Rational Unified Process，RUP）是RATIONAL公司的一款基于网络平台，以架构为中心，面向对象，用例驱动的迭代和增量开发过程模型，包括初始、细化、构造、移交四个阶段。每个阶段都由若干迭代周期构成，每个迭代周期都是一个微型瀑布模型，但随着项目进展所处阶段不同而有所不同。将软件测试过程活动与RUP模型结合，能够建立基于RUP的软件测试模型。

3.1.4.1　初始阶段

初始阶段旨在通过策划确定测试过程活动，定义测试需求，制定测试策略，确定测试资源，分析测试风险，编制测试大纲，使相关人员能够就软件测试生命周期目标及活动达成一致。该阶段的目标如下：

（1）确定软件范围及边界条件，包括关于可操作的概念、可接受的准则。

（2）识别软件系统的主要任务场景，以驱动系统的功能行为并对重要功能做出权衡。

（3）针对某个主要场景展示或演示其候选架构。

（4）对所需资源、时间等进行估算，对细化阶段进行评估。

基于软件开发过程的宏观变换模型，如果某次循环的初始阶段建立在上一循环的基础之上，那么整体测试策略、测试过程、测试方法就是上一循环的迭代。RUP初始阶段的测试活动如图3-7所示。

3.1.4.2　细化阶段

细化阶段旨在分析问题域，建立基础架构，进行风险分析和评估，确定主要风险因素并进行排序，制定风险防控措施。RUP细化阶段的测试活动如图3-8所示。

细化阶段的工作产品包括需求规格、软件架构描述、可执行架构原型、开发计划、用例模型等。该阶段，测试策划所需要素已全部具备，测试需求已明确，能够以此确定测试范围、测试级别、测试类型、测试项，确定每个测试项的测试方法及充分性条件，构建测试环境，确定质量控制，配置管理要求，编制测试大纲。

针对工作产品生成时间，逐一按序进行测试，检出错误，为后续测试尤其是系统测试和验收测试奠定基础。对于需求规格，通常以静态评审进行需求测试，检出需求缺陷，同时对修改情况实施跟踪和回归。

通常，将细化阶段划分为一至两次迭代，在迭代的最后，系统测试用例已经明确，以这些用例为基础，着手进行不同级别、不同类型的测试设计，如果采用自动化测试，尚需依据测试用例生成测试脚本，准备测试数据，到构造阶段形成产品后即可开展测试执行。

3.1.4.3　构造阶段

在构造阶段，通过持续集成构建，开发一个有效版本并确保其质量。构造阶段是测试活动最集中的阶段。软件构造是一个持续的过程，通常将构造阶段划分成多次迭代。每次迭代，都要按测试过程模型进行测试策划、测试设计、准备测试脚本和测试数据、执行测试，对发现的问题进行分析、处理、跟踪和回归，直至完成系统构造。所有迭代并非彼此孤立，后一次迭代通常会重用或采信前一次迭代的资产。

一次迭代结束之后的测试评估可以产生大量数据和经验，如测试用例设计的有效性、容易产生缺陷的模块及原因、测试领域知识等。在下一次迭代过程中，能够有的放矢，对测试资源进行合理调整。显而易见，根据测试重用原则，各次迭代中测试的工作量，尤其是测试用例设计的工作量逐步递减。RUP构造阶段的测试活动如图3-9所示。

3.1.4.4　移交阶段

移交阶段是软件系统的验收交付阶段。RUP移交阶段的测试活动如图3-10所示。

此阶段，所有迭代结束，软件系统运行于实际使用环境，基于实际使用条件和场景，进行系统测试，验证系统的符合性及交付能力。这个阶段的测试可以是上线测试，也可以是鉴定测试，但其本质一样，都是为系统验收交付和状态鉴定提供支撑。

不同开发阶段，测试的对象及重点不同，测试活动需要一系列支撑过程，包括测试风险管理、测试环境准备、配置管理、人员管理、质量保证、计划管理等内容。

每个项目的特点、迭代划分、测试开销均不同。当然，RUP并非一成不变，它既是一个过程，也是一个产品，并且是一个可以根据项目特点和用户需求进行裁剪和定制的过程。迭代测试过程突出了迭代过程所具有的优点，可以更早地、全流程地检出错误，缓解风险，可以更容易地管理变更，可以更加有效地提高测试资产的重用率，可以更加有效地促进项目组在整个过程中不断学习，持续增强测试过程能力。