收藏本站 收藏本站
积木网首页 - 软件测试 - 常用手册 - 站长工具 - 技术社区
软件测试 > 其它管理相关 > 正文

首页 | 领域细分: 游戏测试 安全测试 手机测试 Web测试 | 技术研究: 单元测试 入门教程 用例设计 性能测试 功能测试 | 测试职场: 面试精选 职场发展 面试试题

测试管理: 配置及流程 - 需求管理 - 质量验收 - 缺陷管理 - 其它管理相关 | 开发语言: PHP技巧 - PHP基础 - PHP实例 - PHP错误代码

测试工具: LoadRunner JiRa QuickTestPro RoBot WinRunner TestDirector 其它测试工具 | 数据库: Mysql数据库 Oracle数据库 CSS/DIV基础 HTML基础

软件测试过程改进模型入门介绍

来源:互联网 日期:2014-01-03 20:00

  摘要:测试常被看作是一个昂贵且不可控的过程。测试花费太多的时间,耗费的比计划投入的多,无法提供充分的关于测试过程本身的质量情况。因此,信息系统的质量和商务风险难以判断。

  很多组织意识到改进测试过程可以解决这些问题。但是,实际上为了改进和控制测试过程到底应该采取什么步骤以及什么次序是困难的。

  基于实践知识和测试过程开发经验,测试过程改进模型(以下简称TPI)被开发出来。TPI提出了一个组织内测试过程成熟度的观点。

  在这份文件里将介绍TPI的内容和结构。同时,测试过程改进的一些方面及面临的挑战也将做些讨论。

  1、概述

  测试常被看作是一个昂贵且不可控的过程。测试花费太多的时间,耗费的比计划投入的多,无法提供充分的关于测试过程本身的质量情况。因此,信息系统的质量和商务风险难以判断。

  很多组织意识到改进测试过程可以解决这些问题。但是,实际上为了改进和控制测试过程到底应该采取什么步骤以及什么次序是困难的。

  基于实践知识和测试过程开发经验,测试过程改进模型(以下简称TPI)被开发出来。TPI提出了一个组织内测试过程成熟度的观点。

  在这份文件里将介绍TPI的内容和结构。同时,测试过程改进的一些方面及面临的挑战也将做些讨论。

  2、软件测试的目的

  一个信息系统开发阶段的测试活动可以这样来加以说明:

  测试活动是从测试计划、测试准备到测试执行、测试分析这样一个过程,测试的目标是对信息系统(泛指软件)的特性进行确认,以发现该系统应有状态与实际状态的差异。

  测试计划和测试准备活动用以定义测试过程何时开始。在任何测试方法应用前(即测试执行阶段前),测试过程要求有明确的计划和准备阶段。

  测试可以降低系统质量的不确定度级别,但是测试效果的好坏依赖于系统发布所带来的风险,还有我们愿意花费在降低不确定度等级上的时间和资金。

  3、测试等级

  为了有效地组织测试,不同的测试等级需要加以应用。每一个测试等级对应某一组需求、功能或者技术说明。本章内容主要基于 [KoP99]和[ISEO4]。

  3.1 低级测试

  低级测试陷于系统的各个组成部分的测试中,例如程序单元,单独的或者关联的。从系统开发开始,即开始单元,程序和模块的测试。如上面所述这种分离性依赖于程序下部结构和所使用的编程语言。这类测试的执行者多数时候是开发人员。

  当众多的系统基本单元确认已经符合他们的技术规格时,作为系统构成的稍大些的模块在集成测试中进行测试。集成测试主要关注与数据流和程序间的接口部分。

  3.2 高级测试

  高级测试全面、彻底的测试产品。在低级测试已经完成并且缺陷已得到纠正后,要进行系统测试以检验系统是否满足了功能和技术规格说明书中定义的要求。

  系统测试完成后,向客户提交产品进行验收。验收测试需要模拟搭建一个产品环境。

  高级测试尤其应该被作为一个单独的过程来执行。过去的经验显示高级测试过程的设计远比低级测试过程的设计更重要。

  4、关于测试的几个问题

  本章指出测试中的一些常见问题以及测试过程改进的一些必要方面,本章内容基于[KoP99]。

  4.1 测试的原始形式

  在系统进入产品阶段即将被发布前,测试工作短暂的开展一段时间,并且执行测试工作的人员是非专业的,而是随机的,谁有空闲谁来做。这就是测试的最初形式和状态。这类测试往往在系统进入产品发布阶段后或者近期没有发现新的缺陷即宣告终止,结果就是系统带着一些隐含的缺陷即被发布,导致在后续的因为这些缺陷而引发的软件重做、重测上付出高昂的代价。

  4.2 当前情势

  现在,在很多单位或者组织中间对于一个可管理的测试过程的重要性已经有了越来越多的共识。测试在执行前应首先进行计划制定和准备工作,计划和准备的内容应该建立于开发文档上。组织内应该清楚地知道哪些测试过,哪些未被测试过。但是,不管怎样,测试始终面要面对时间短、人员少、资源短缺以及技术支持度低等现状。测试处在开发周期的末端,并且往往陷入一个反复开发、反复测试的无休止的死循环中。即便测试停止之后,对于系统的质量等级依然是一个不确定的答案。

  4.3 最新发展

  要想能够面对当前市场的激烈竞争,组织必须要缩短新产品投向市场的时间。尽管开发过程正在不断加快,但是在开发过程的任何一环节都有可能引入的错误却没有丝毫迹象显示正在减少。相关经验的缺乏和不断上升的技术复杂度佐证了上述现象是正常的。即使现在的测试过程对于当前情势来说看起来是相当令人满意的,但是有一点很明显这不是软件测试的未来模式。

  5、改进测试过程

  5.1 测试过程改进的必要性

  前一章提及的那些问题的产生原因可以归结于不可控的或者准备不足的测试过程。消除这些原因就是测试过程改进的原动力。参考Koomen和Pol关于测试过程改进的论述,TPI可以定义如下:

  从信息服务整体出发,统筹与优化测试过程的质量、成本和周期的过程。

  这里的质量是指测试过程关于被测对象质量方面的度量程度,即测试质量,系统或者程序等具体测试对象的质量不在此范畴。

  当然,一个质量上改良的测试过程并不能给被测系统带来更好的质量。测试本身不会提高系统的质量。事实上,它能做到的是确认系统已具有的质量特征,并试图通过所提供的这些质量信息驱使组织去改善产品质量。

  在整个信息服务来看,测试过程并不是孤立的。低成本、高效率的追求,不是测试的本质目的,测试应该为信息服务更高的效能(信息服务的整体水平)做出更多贡献。

  测试过程改进的一个目标应该是尽可能多地发现缺陷、降低改正成本、更早的报告系统质量情况。所有的评测标准要谨慎地相互兼容,以此取得一个能够尽可能早的发现更过重要缺陷的总体策略。

  测试要朝着更加专业化的方向发展,提高专业测试技能,职能分工细化,如测试管理、测试技术专家、测试工程师。整个测试过程的进步和质量可以被度量,其度量结果在将来可以作为测试过程改进的输入项加以利用。

  5.2 测试过程改进步骤

  改进测试过程类似于任何其他过程的改进。测试过程的改进,通常遵循以下步骤:

  1. 确定目标和需要考虑的域。要确定测试的质量特性:是使测试速度更快、费用更低还是覆盖率更高?什么样的测试过程最需要改进,改进过程需要持续多长时间,具有什么效果?

  2. 确定当前的条件。评估当前情势的优缺点。

  3. 确定需要的条件。基于对当前条件的分析结果和改进目标,确定需要的条件和行动步骤。

  4. 实施改革。根据预先拟制的改进计划,按照建议的改进操作步骤实施改革,同时跟踪改进信息,填写条件检查项,用以验证是否达到了改进目标。

  5. 通过一个参照系,使测试过程的优缺点呈现出来。这个参照系可以是测试方法论或者是一个测试过程改进模型。

  依照Koomen和Pol的通用软件过程改进模型(如SPICE和CMM),它为测试过程的逐步改进提供了一个不是很充分的参照体系。因为是个更高层次的抽象,在这个参照体系中测试过程的改进往往是作为一个步骤来处理。

  当然,有些专门针对测试过程改进而设计的模型,如测试能力度量模型,测试改进模型以及测试度量模型等,这些模型都不包含足够的可应用的改进步骤、详细的描述和使用说明。

  6、TPI模型

  6.1 TPI模型综述

  测试过程改进模型必须从多个视角观测测试过程,例如测试工具的使用,测试技术以及报告。在TPI模型中,这些观测点叫作关键域。每一个关键域可以归类到成熟度中。对于整个测试过程的效能来说,并不是所有的关键域都是同等的,在不同的关键域和等级之间存在着一些关系。

  确认在各个层级上的归类是客观的,在每个层级上设置一个或多个检查点。一个检查点是一个需求。如果一个测试过程符合某个层级的所有检查点,那么这个过程就属于这个层级。

  除了评估测试过程的当前情势外,关键域和层级同样可以用于定义需要的条件和为达到这些条件而需要实施的中间步骤。在这个模型中附有改进建议,给出了如何达到某一特定水平的说明和建议。

  6.2 TMap模型

  TMap,组织测试的方法体系以及第5.2章中所提到的模型的其他方面构成TPI模型的基础。TMap方法体系包括4个环节,这四个环节组成开发周期中所有测试活动的一个生命周期,好的组织体系,正确的测试框架和测试工具以及为执行测试活动可用的技术。

  这些环节是通用的,并且在每一个测试过程中必须给予每一个环节一定的关注度。要有一个和谐的测试过程,则这些环节上的测试开发应该要保持和谐。

  6.3 关键域和等级

  通过查看一个结构化测试过程的每一环节的不同方面,总计20个关键域在TPI模型中得到公认。

  通过测试过程中关键域的应用来判断过程的成熟度。但是无论如何,每一个关键域在使用期间不会是均等的彻底的,因为每个测试过程有它自己的优势和弱势。

  为了能够更深入的观察这些关键域的状态,模型给每个关键域设置了一个上升的等级(通常为从A到D)。一般地说,每个关键域有3至4级。每个高一点的等级在效率、成本和(或)质量方面要优于它前面的层级。每个层级由适用于这个关键域的一定的需求组成。这些一定层级的要求(即检查点)同样包含低层的需求:一个B级的测试过程应该同时完全满足A级和B级的要求。如果一个B级的测试过程不能够满足A级的要求,那么它应该被视作在低一级的层级上或者是针对那个特别的关键域尚未定义的层级上。

  不同层级的关键域的描述详见表1。表1中关键域的不同级别中都包含里程碑,例如,测试过程每周报一次,周报包含发现的缺陷和花费的小时数的概述。因为缺陷没有指出优先级,测试进度也未在报告中提及,所以这个过程应在这个关键域中归类为A级。

Level Key area Cornerstone

关键域层级里程碑

A

B

C

D

Test strategy L

测试策略

Strategy for single high-level test

针对单一的高级测试的策略

Combined strategy for high-level tests

针对高级测试的组合策略

Combined strategy for high-level tests and low-level tests or evaluation

针对高级测试、低级测试和评价的组合策略

Combined strategy for all test and evaluation levels

针对所有层次的测试和评价的组合策略

Life-cycle model L

生命周期模型

Planning, Specifica-tion, Execution

计划、方案、执行

Planning, Preparation, Specification, Execu-tion, Completion

计划、准备、方案、执行、完成

Moment of involvement L

参与时机

Completion of test basis

完成主要部分测试

Start of test basis

从主要部分测试开始

Start of requirements definition

从需求定义开始

Project initiation

项目启动

Estimating and planning T

评估和计划

Substantiated estimating and planning

评估和计划的案例

Statistically substanti-ated estimating and planning

可统计的评估和计划的案例

Test specification techniques T

测试设计技术

Informal techniques

不正式的技术

Formal techniques

正式的技术

Static test techniques T

静态测试技术

Inspection of test basis

测试的基本项目检查

Checklists

检查单

Metrics T

度量

Project metrics (product)

项目度量[侧重产品]

Project metrics (process)

项目度量[侧重过程]

System metrics

度量体系

Organisation metrics (>1 system)

组织度量

Test tools I

测试工具

Planning and control tools

规划和控制工具

Execution and analysis tools

执行和分析工具

Extensive automation of the test process

测试过程的广泛自动化

Test environment I

测试环境

Managed and con-trolled environment

可管理可控制的环境

Testing in most suitable environment

在最适合的环境进行测试

Environment on call

基于需求的环境

Office environment I

办公环境

Adequate and timely office environment

充分和及时的办公环境

Commitment and motivation O

承诺和动机

Assignment of budget and time

预算和时间上的分配

Testing integrated in project organisation

测试整合在项目组中

Test-engineering

测试工程化、独立化

Test functions and training O

测试技能和培训

Test manager and testers

测试主管和测试人员

(Formal) Methodical, technical and functional support, management

有方法的

技术和技能支持

管理

Formal internal Quality Assurance

正式的内部质量保证

Scope of methodology O

方法适用范围

Project specific

具体项目

Organisation generic

组织通用

Organisation optimising (R&D)

组织优化

Communication O

交流

Internal communication

内部交流

Project communication (defects, change control)

项目组交流(如缺陷、变更控制)

Communication within the organisation about the quality of the test processes

有组织地进行关于测试过程质量的交流

Reporting O

报告

Defects

缺陷

Progress (status of tests and products), activities (costs and time, milestones), defects with priorities

进度(测试和产品的状态),活动(成本和时间,里程碑),带优先级的缺陷

Risks and recommendations, substantiated with metrics

风险和建议,度量案例

Recommendations have a Software Process Improve-ment character

具有软件过程改进性质的建议

Defect management O

缺陷管理

Internal defect management

内部缺陷管理

Extended defect management with flexible reporting facilities

基于灵活的报告工具的扩展缺陷管理

Project defect management

项目缺陷管理

Testware management O

测试工件管理

Internal testware management

内部测试工件管理

External management of test basis and test object

测试主要部分和测试对象扩展管理

Reusable testware

可复用测试工件

Traceability system requirements to test cases

测试用例可追溯到系统需求

Test process management O

测试过程管理

Planning and execution

规划和执行

Planning, execution, monitoring, and adjusting

规划,

执行,

控制,和调整

Monitoring and adjust-ing within organisation

有组织的控制和调整

Evaluation (all)

评价

Evaluation techniques

评价技术

Evaluation strategy

评价策略

Low-level testing (all)

低级测试

Low-level test life-cycle: planning, specification and execution

低级测试生命周期:规划,方案和执行

White-box techniques

白盒测试技术

Low-level test strategy

低级测试策略

  6.4 检查点

  我们要使用检查点以确定某一层级的要求。这些要求以问题的形式加以定义,它们是为了判断是否达到某一层级而必须要严肃回答的。

  基于这些检查点,我们能够评估一个测试过程,并为每一个关键域建立正确的所处层级。每个关键域的下一个层级对应一个改进。这些检查点也是累积的:为了给等级B归类,测试过程需要同时满足等级B和等级A两个等级的检查点。

  例子:测试工具这个关键域的检查点

  规划和控制工具(等级A)

  检查点:

  ● 在缺陷管理和至少其他两项规划、控制活动中应用自动化工具(字处理等办公类软件不算)

  执行和分析工具(等级B)

  检查点:

  至少两类自动化工具应用于测试执行阶段,如录制回放工具、测试覆盖率分析工具等。测试团队借助于这些工具对于测试的费效比有个大概的了解。

  测试过程的自动化扩展(等级C)

  检查点:

  自动化工具(标准字处理软件除外)应用在测试计划阶段(主要是活动评估、计划编制、进度追踪、配置管理和缺陷管理)、测试准备、方案和执行(总计不少于5种工具得到应用)。

  6.5 测试成熟度矩阵

  在各个关键域的层级确定后,注意力应集中在采取哪一个改进步骤上,因为不是所有的关键域和层级都是同等重要的。举例来说,一个好的测试策略(测试策略关键域的A级)就比测试技术应用的描述更加重要(方法适用范围关键域的A级)。

  除了上述的优先级外,在不同关键域的层级之间也存在着依赖性。例如,在缺陷发现情况统计报表(度量关键域A级)出来之前,测试过程不得不在缺陷管理域中向B级努力。同样,在很多关键域和层级间都存在着依赖性,这样的例子不再一一枚举。

  因此,层级和关键域在测试成熟度矩阵中相互间是紧密联系的。这个矩阵的纵轴是关键域,横轴表示成熟度。在矩阵里每一个等级对应一定成熟度。这样,在测试成熟度上共有13级。不同层级间的单元不再表示它们原有的意义,而是表示:一个关键域达到更高的成熟度与其它关键域的成熟度的关系。不同的层级没有顺序。只要测试过程没有完全达到B级标准,那它就始终是A级。测试成熟度矩阵结构绘制如表2。

Table 2 Test Maturity Matrix [Sog04]

本周排行

别人正在浏览

强悍的草根IT技术社区,这里应该有您想要的!
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号