（计算机软件与理论专业论文）基于cmmi和gqim的软件测试过程度量研究.pdfVIP

基于c m m i 和g q ( i ) m 的软件测试过程的度量研究 摘要 软件测试作为保证软件质量的一种重要手段，在软件的生命周期中具有非常 重要的地位。研究表明，越早发现软件中存在的问题，开发费用就越低，软件质 量越高，软件发布后的维护费用越低。而业界也普遍认为，除了软件测试技术以 外，一个好的、成熟的软件测试过程能够最大限度地保证软件测试的有效性和适 度性，进而保证软件产品的质量。 软件度量技术在软件工程领域的研究中占据着重要的地位，它是改进过程的 有效途径之一。通过对过程的度量，可以使过程规范化、可视化；通过对度量数 据的分析，可以衡量过程的有效性以及发现过程中存在的问题；通过度量信息可 以跟踪和监督过程状态，从而能够为过程管理提供决策支持，降低过程承担的风 险。因此，通过在软件测试过程中引入过程度量，保证软件测试过程的有效性， 最终实现软件产品质量的保证和提高。 c m m i 是由美国卡耐基梅隆大学的软件工程研究所提出的一个成功的、广 泛使用的软件过程改进模型，它针对软件过程的管理、改进和评估，其根本目的 就是软件过程改进。软件测试和软件度量是软件过程中不可分割的一部分，因此 c m m i 包含了一系列支持软件测试过程改进和软件度量分析的过程域。 g q ( i ) m 方法是卡耐基梅隆大学软件工程研究所软件工程度量和分析组在 g q m 的基础上提出的一种改进模型。它在q 和m 之间加入了一个中间步骤，用于 建立问题和度量数据之间的联系。它构造了可视化的指示器( i n d i c a t o r ) ，这些指 示器可以作为需求说明书，指导需要收集什么数据，对这些数据需要做哪些处理 和分析，为这些活动做计划。 本文正是运用c m m i 各个过程域中对软件测试和软件度量的支持框架、实际 指导、过程分析等，结合g q ( i ) m 度量方法，对软件测试过程度量进行了研究。 本文研究的主要工作集中在以下三个方面： 根据软件测试过程的研究现状，结合软件测试理论、软件度量理论和 c 删i ，提出了适合于度量的基于c m m i 的c m m l 4 s t p 。 经过研究软件测试过程方面的特殊属性提出了适合c m m l 4 s t p 度量的信 息需求、基本度量、派生度量和指示器。 本文采用n e t 开发了一个针对软件测试过程的度量工具s t p m t 。 关键词：c m m i 软件度量软件测试过程 软件测试过程度量 r e s e a r c ho fs o f t w a r et e s tp r o c e s sm e a s u r e m e n tb a s e d o nc m m ! a n dg q ( i ) m a b s t r a c t a sa ni m p o r t a n tm e t h o dt oa s s u r es o f t w a r eq u a l i t y s o f t w a r et e s ti sv e r y i m p o r t a n ti nt h es o f t w a r el i f e c y c l e s o m es t u d i e si n d i c a t et h a tt h ee a r l i e rt h eb u g so f s o f t w a r ea r ed i s c o v e r e d ，t h el o w e rs o f t w a r ep r o g r a m m i n gc o s t s ，t h eh i g h e rt h eq u a l i t y o fs o f t w a r ei sa n dt h el o w e rt h em a i n t e n a n c ec o s t sa f t e rs o f t w a r er e l e a s e s t h e s o f t w a r ei n d u s t r yg e n e r a l l yc o n s i d e r st h a t ，b e s i d e st h et e c h n i q u eo fs o f t w a r et e s t ，a g o o da n dm a t u r es o f t w a r et e s tp r o c e s sc a na s s u r et h ee f f i c i e n c yo fs o f t w a r et e s t ， t h e r e b ye n s u r i n gt h eq u a l i t yo f s o f t w a r ep r o d u c t s s o f t w a r em e a s u r e m e n ti sv e r yi m p o r t a n ti nr e s e a r c ho fs o f t w a r ee n g i n e e r i n g i t s a ne f f e c t i v ew a yt oi m p r o v es o f t w a r ep r o c e s s t h r o u g ht h em e a s u r e m e n to fs o f t w a r e p r o c e s s ，i t c a nm a k et h ep r o c e s sb es t a n d a r d i z e da n dv i s u a l i z a t i o n t h r o u g h a n g l i c i z i n gm e a s u r e m e n td a t a ，i tc a n k n o wt h ee f f i c i e n c ya n dp r o b l e m so ft h ep r o c e s s t h r o u g ht r a c k i n gm e a s u r e m e n ti n f o r m a t i o na n dm o n i t o r i n gp r o c e s sc o n d i t i o n s ，i tc a n p r o v i d ed e c i s i o ns u p p o r tf o rp r o c e s sm a n a g e m e n ta n dr e d u c et h er i s k o fp r o c e s s t h e r e f o r e ，t h r o u g hi n t r o d u c i n gs o f t w a r em e a s u r e m e n ti n t ot h es o f t w a r et e s tp r o c e s s ， w ec a na s s u r et h ee f f i c i e n c yo fs o f t w a r et e s tp r o c e s s ，f i n a l l yi m p r o v et h eq u a l i t yo f s o f t w a r ep r o d u c t s c m m ip r o v i d e db yt h es o f t w a r ee n g i n e e r i n gi n s t i t u t eo fc a r n e g i em e l l o n u n i v e r s i t y ，c a p a b i l i t ym a t u r i t ym o d e li n t e g r a t i o n ，i sas u c c e s s f u la n dw i d e l yu s e d m o d e lo fs o f t w a r ep r o c e s si m p r o v e m e n t a si ti sk n o w n ，s o f t w a r et e s ta n ds o f t w a r e m e a s u r e m e n ti sa ni n t e g r a lp a r to fs o f t w a r ep r o c e s s s ot h ec m m ii n c l u d e sas e r i e so f p r o c e s sa r e a st os u p p o r ts o f t w a r et e s tp r o c e s sa n ds o f t w a r em e a s u r e m e n t a n dt h e p r o c e s sa r e a sc a nb eu s e da l o n eb y t h es o f t w a r eo r g a n i z a t i o ni nt h ec o n t i n u o u s r e p r e s e n t a t i o no fc m m i m a i sc l o s ec o n n e c t i o nt os o f t w a r em e a s u r e m e n t g q ( i ) mi sa l s op r o v i d e db yt h es o f t w a r ee n g i n e e r i n gi n s t i t u t eo fc a r n e g i e m e l l o nu n i v e r s i t y ，c a p a b i l i t ym a t u r i t ym o d e li n t e g r a t i o n i ti sb a s e do ng q m i t i n t r o d u c ei n d i c a t o ri n t ot h em i d d l eo fqa n dm t h ei n d i c a t o ri su s e dt om a k eq c o n t a c tw i t hma n dd i r e c tw h a tt oc o l l e c t ，h o wt od e a lw i t ht h ed a t aa n dm a k ep l a nf o r t h ea c t i o n s t h ed i s s e r t a t i o na p p l i e st h ep r o c e s sa r e a so fc m m ic o r r e l a t ew i t hs o f t w a r et e s t a n ds o f t w a r em e a s u r e m e n ti n c l u d e si t ss u p p o r tf r a m e w o r k ，p r a c t i c a lg u i d a n c e ， p r o c e s sa n a l y s i s ，a n dg q ( i ) mt o r e s e a r c ht h es o f t w a r et e s tp r o c e s sm e a s u r e m e n t t h e r e r et h r e es t u d i e so ft h ed i s s e r t a t i o ni nt h ef o l l o w i n g 。 2 b a s e do nt h ea d v a n t a g e so fe x i s t i n gs o f t w a r et e s tp r o c e s sm o d e l ，s o f t w a r e m e a s u r e m e n ta n dc m m i ，t h ed i s s e r t a t i o np r e s e n t sc m m l 4 s t pb a s e do nc m m i t h ed i s s e r t a t i o na n a l y z e st h es p e c i a la t t r i b u t e so fs o f t w a r et e s tp r o c e s sa n d p r o v i d e st h et e s tp r o c e s sm e a s u r e m e n ti n f o r m a t i o n ，b a s em e a s u r e m e n t ，d e r i v e d m e a s u r e m e n ta n di n d i c t o r w ed e v e l o pas o f t w a r et e s tp r o c e s sm e a s u r e m e n tt o o ln a m e ds t p m t i n n e t k e y w o r d s ：c m m i ；s o f t w a r em e a s u r e m e n t ；s o f t w a r et e s tp r o c e s s ；s o f t w a r et e s t p r o c e s sm e a s u r e m e n t 插图清单 图2 1 验证语境图5 图2 2 确认语境图6 图2 3v 测试模型8 图2 4w 测试模型9 图2 5h 测试模型9 图2 6c m m l 4 s t p 10 图3 1 度量用户对象l3 图3 2 度量关系模型1 4 图3 3 软件过程度量框架15 图3 4 软件测试过程度量的作用1 8 图3 5g q m 模型19 图3 6g q ( i ) m 模型2 0 图3 7 度量和分析语境图2 3 图3 8m a 执行流程2 4 图3 9 度量计划的三个主要活动2 4 图5 1s t p m t 系统结构图4 0 图5 2 度量元管理界面4 1 图5 3 指示器管理界面4 1 图5 4 度量数据导入界面4 2 图5 5 度量数据分析界面4 2 表格清单 表2 1c m m i 关键过程域分布5 表2 2 基于c m m i 的软件测试过程各阶段任务描述“ 表3 1 软件过程度量分类1 4 表4 1 测试过程度量信息需求表2 7 表4 2 代表性的3 个基本度量表3 0 表4 3 测试过程四个派生度量表3 0 表4 4 缺陷数据收集检查表3 2 表4 5 基本度量表3 3 表4 6 派生度量表3 5 表4 7 指示器表3 8 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的研究成果。 据我所知，除了文中特别加以标志和致谢的地方外，论文中不包含其他人已经发表或撰 写过的研究成果，也不包含为获得 金g 曼王些太堂 或其他教育机构的学位或证书而 使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的 说明并表示谢意。 学位论文作者签字：孑弛咨签字日期：彻7 年铲月勿日 学位论文版权使用授权书 本学位论文作者完全了解 金巴王些盔堂 有关保留、使用学位论文的规定，有权 保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅或借阅。本人 授权 金g 旦王些盔堂 可以将学位论文的全部或部分论文内容编入有关数据库进行检 索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文者签名： 铂吃陟 签字日期：7 , 0 0 7 年华月护e t 学位论文作者毕业后去向： 工作单位： 通讯地址： 导师签名： 婵嗍：7 ”蛳 l 致谢 毕业在即，三年的研究生学业生涯即将成为往事。首先，感谢我的导师李心 科副教授。本文的研究工作是在李老师的精心指导和悉心关怀下完成的，在我的 学业和论文的研究工作中无不倾注着导师辛勤的汗水和心血。李老师严谨的治学 态度、渊博的知识、谦和的待人风范使我深受启迪。从尊敬的李老师身上，我不 仅学到了扎实、宽广的专业知识，也学到了做人的道理。在此，再次向李老师致 以最衷心的感谢和深深的敬意。 其次要感谢的是邵垫副教授、王钊高级工程师，两位老师理论功底扎实，思 路缜密，在我的学业生涯中给予了重要的帮助和指导；在我写作论文的过程中给 了我许多灵感与启发，提出了许多改进的意见。 还要感谢软件工程实验室的王霜、杨明等同学以及师弟师妹们，和他们在一 起工作和学习使我受益匪浅，大家在一起学习和讨论的日子使我终生难忘。 特别要感谢我的父母，是他们含辛茹苦抚养我成人，给我以人生指导，给我 学业以物质和精神支持，没有他们的支持与赞赏，我不可能走到现在。 在此，谨以此文向以上关怀和帮助过我的所有老师、同学、朋友、亲人表示 衷心的感谢1 4 作者：杨晓辉 2 0 0 9 年3 月 第一章绪论 1 1 研究背景及意义 近年来，信息技术迅猛发展，软件业也取得了辉煌的成就。但随着软件技 术的发展和应用，软件规模越来越大，软件开发风险也随之增加，软件质量很 难得到有效的控制。为了摆脱软件危机，生产低成本、高质量、按时交付的软 件产品，软件开发组织开始对软件工程方法进行深入的研究，不断提出和改进 软件工程方面的技术、方法和工具。虽然这些方法和工具提供了许多帮助，但 它们并没有根本解决软件开发中存在的进度和成本失控、质量不能令人满意和 开发人员疲惫不堪等问题。软件界的多年研究表明，要在预算的时间和成本下 生产高质量的软件关键在于软件过程的有效管理。只有将过程规范化并进行度 量和不断改进，才能生产出高质量的软件产品。 而软件测试过程作为软件过程的重要组成部分，它对软件产品的质量产生 重要的影响。任何一个软件的测试都受到期限、费用、人力和资源的限制，软 件的测试在一定的时候是必须要终止的。因此，有必要研究管理和控制软件测 试的方法及技术，为实现在指定的期限内，以适当的费用、合理的人力、物力 投入，恰当安排，避免无效或低效的重复测试，保证测试本身的质量，适时终 止测试。为及时推出优秀的软件产品的目标，提供科学、合理的依据。通过在 软件测试的计划和实施过程中进行度量，我们可以利用以往项目的历史数据来 规划当前测试项目，来增加项目控制的可视化程度，来标识出项目中有待完善 的地方，来促进测试过程的改进和提高。通过软件测试过程的度量，还可以定 量地衡量软件测试是否充分，定量地评价软件测试过程本身的质量，为软件项 目的管理决策提供科学的数据等。综上所述，为了尽可能多地找出程序中的错 误，生产出高质量的软件产品，为了加强对测试工作的组织和管理，我们必须 对软件测试过程进行度量，通过对测试过程的量化分析和总结，进而改进软件 测试过程，提高软件测试效率，提高软件产品的质量。 1 2 国内外研究现状 1 2 1c m m 到c m m i 国际上有关软件测试过程和质量评价体系主要有i s o 、c m m 、t m m 等。基于 c m m c m m l 的软件测试过程改进已成为当前的主流。c m m i 为企业提供了软件测试 过程改进的框架，帮助指导软件企业提高软件测试过程能力。 软件能力成熟度模型c m m 是由c m u s e i 受美国国防部委托和资助而研究制 定的一种用于评价软件承包能力并帮助其改进软件质量的方法，也是评价软件 过程能力和成熟度的一套标准，侧重与软件开发过程的管理及工程能力的评估 和改进。c m m c m m i 所依据的想法是只要不断地对企业的软件工程过程的基础结 构和实践进行管理和改进，就可以克服软件生产中的困难，增强开发制造能力， 从而能按时地、不超预算地制造出高质量的软件。 自1 9 9 1 年s w c m m 首次开发后，s e i 又开发了其他成熟度模型，包括系统 工程、采购、人力资源管理和集成产品开发等。为了整合不同的模型中的最佳 实践，建立统一模型，覆盖不同领域、供企业进行整个组织的全面过程改进， s e i 又推出c m m i ( 能力成熟度模型集成) 以替代c m m 。c m m i 主要起源于三个源 模型：软件能力成熟度模型( s w c m m ) 、电子行业协会临时标准( e i a i $ 7 3 1 ) 、 集成产品开发能力成熟度模型( i p d c m m ) ，此后模型中又集成了供应管理的内 容。在c m m i 模型组件中，s e s w 是核心。与原有的能力成熟度模型类似，c m m i 也包括了在不同领域建立有效过程的必要元素，反映了业界普遍认可的最佳实 践，专业领域覆盖软件工程、系统工程、基础产品和系统采购。c m m i 为企业的 过程构建和改进提供了指导和框架作用；同时为企业评估自己的过程提供了可 参考的行业标准。c m m i 融入了大部分最新的软件管理实践，同时弥补了c m m 的 缺陷。c m m i 的主体是一个整体框架，其内容涉及四个知识领域：系统、软件、 集成的产品和过程开发、采购。 1 2 2 软件测试过程度量研究现状 在度量技术发展的早期，软件度量研究的重点是度量产品的性能。进入上 世纪8 0 年代，鉴于软件过程度量的重要原因，软件度量的研究领域又拓宽到实 施度量的机制和方法的研究上。国内外不少组织都对软件过程度量技术进行了 研究，提出了各自的度量理论和方法，出现了很多度量模型。 在具体的过程度量定义方法方面，出现了很多度量过程模型。其中最具有 代表性的是由b a s i l i 教授及其合作者提出目标驱动( g o a l q u e s t i o n m e t r i c ， g q m ) 模型 3 。g q m 模型是一种面向目标的、自上而下由目标细化到度量的 逐步求精的度量定义方法，它将目标与软件过程、产品和质量方面的模型结合 起来，形成了建立可度量软件过程的基本方法。r o b e r te p a r k 对g q m 模型做 了改进，在q u e s t i o n 层和m e t r i c 层之间加入了i n d i c a t o r ( 指示器) ，提出了 g q ( i ) m 模型 1 】。g q ( i ) m 模型使得度量更直观，易于理解。 w i l l i a ma f l o r a e 和a n i t ad c a r l e t o n 等人对软件过程度量的过程模型和度 量分析技术进行了研究【l4 】，于1 9 9 9 年提出了一个度量过程行为模型，该框架 由六个部分组成：确定商业目标，确定问题并安排优先次序，选择和定义度量， 采集、验证、保存数据，分析过程行为和评估过程性能，通过不断循环执行框 架所包含的活动，达到持续改进软件过程的目的。 软件测试过程方面的研究在我国起步较晚，对软件测试过程度量、与c m m i 等成功模型相结合的研究工作在我国开展得更晚，目前可查的资料有限。上海 计算机软件技术开发中心的宿为民教授等人提出从过程建模的角度考虑对支持 过程的度量，并给出了一个一种支持过程度量的软件过程建模方法的g q m d 度量框架 4 2 】，其基本思想是在g q m 模型的度量层下增加一个数据项分层，将 关于过程度量的一些特定的活动完全融入到过程模型中，使之成为软件过程各 活动中的一种。西安交通大学的张春霞、苏秦在软件测试过程分析【4 0 】一 文中分析了传统软件测试的不足，阐述尽早开始测试的必要性，总结出系统测 试过程所需经历的阶段一计划、设计、执行和评估。 1 3 研究内容 软件测试过程度量是对软件测试过程的量化分析，通过测试过程度量对于 指导和改进软件测试过程具有实际意义。近年来，软件度量引起了企业界和学 术界的广泛重视并且有了长足的发展，但是关于软件测试方面的度量研究还比 较少。目前，软件测试大多仅仅是于对软件产品进行相关的测试，而缺乏对软 件测试过程本身的监控和管理的支持，也很少对测试过程中发现缺陷和错误进 行分类、统计和分析，在测试进度、测试成本的有效控制等方面存在一些不足 之处。基于以上存在的一些不足，本文对软件测试理论方法、技术及测试过程 进行深入细致的研究和分析，通过研究其特殊的属性和度量要求，提炼出来适 合测试过程度量的信息需求，设计出相应的基本度量、派生度量和指示器等。 其中有些是基于前人的研究结果的应用，有些理论和技术是本文首次提出，通 过本文的研究希望能够推动软件测试过程度量的研究工作。本文主要从测试过 程改进、测试项目的管理和控制、测试本身的质量及测试资源等几个方面入手 进行研究，主要内容有以下几个方面： 根据软件测试过程的研究现状，结合软件测试理论、软件度量理论和 c m m i ，提出了适合于度量的基于c m mi 的软件测试过程模型c m m l 4 s t p 。 经过研究软件测试过程方面的特殊属性提出了适合于软件测试过程度量 的信息需求。 经过对软件测试过程度量方法的研究，提出了适合于测试过程度量的设 计基本度量的度量方法，提出了适合于设计派生度量的度量函数方法和适合于 设计指示器的分析模型方法，并使用这些方法，生成对c m m l 4 s t p 度量的基本 度量、派生度量和指示器。 本文根据研究理论采用n e t 开发了一个针对于软件测试过程的度量工具 s t p m t 。 1 4 本文的组织结构 本文共分为六章。 第一章介绍本文的研究背景和内容。在简要介绍了c m m c m m i 、过程度 量、测试过程度量技术和国内研究现状的基础上，给出本文研究的内容和所要 进行的工作。 第二章详细介绍c m m i 和软件测试过程的相关知识以及现有的软件测试过 程模型的优缺点以及c m m i 的确认过程域和验证过程域对软件测试过程的扩展 的基础上，提出一种基于c m m i 的软件测试过程模型c m m l 4 s t p ，并详细定义 了c m m l 4 s t p 各个阶段的任务、策略和问题。 第三章首先介绍软件过程度量的基本范畴和框架，分析软件测试过程度量 的关注点和重要作用，然后介绍g q ( i ) m 方法，并详细分析c m m i 中的m a ， 最后分析度量过程与过程改进的关系。 第四章在前面两章分析的基础上，详细地阐述了本文在软件测试度量方面 的研究，主要包括测试度量的信息需求的确定、测试度量方法和研究以及测试 度量过程的实施框架等，结合c m m l 4 s t p 模型，提出了软件测试过程度量的基 本度量、派生度量和指示器。 第五章在上述研究成果的基础上，设计并开发了一个支持测试过程度量的 工具原型系统s t p m t 。详细分析了s t p m t 的系统结构、功能和特点。 第六章对全文的工作做了总结，并对下一步工作进行了展望。 4 第二章c m m i 和软件测试过程 2 1c m m i 对软件测试的扩展 c m m i 是针对软件过程提出的，融合了6 s i g m a 、c m m 等标准的质量管理 概念，更加适合于软件过程开发。c m m i 有两种表示方法，一种是延用c m m 的阶段式的表现方法，另一种是连续式的表现方法。在c m m i 的阶段式的表现 方法中，c m m l 分成5 个成熟度级别，关键过程域为2 5 个关键过程域( 如表 1 1 所示) ，以及5 4 个目标和l8 6 个方法。 表2 1c m m ! 关键过程域分布 成熟度等级包含过程域 初始级 已管理级 7 个：需求管理、项目计划、项目监督和控制、供应商合同管 理、产品过程质量保证、配置管理、度量与分析 己定义级1 4 个：需求开发、技术解决方案、产品集成、验证、确认、 组织过程焦点、组织过程定义、组织培训、集成项目管理、 风险管理、合成团队、集成供应商管理、决策分析和决定、 组织的一体化环境 定量管理级 2 个：组织过程性能、定量项目管理 优化级2 个：原因分析和解决方案、组织创新和推广应用 软件测试是软件过程中不可分割的一部分，所以c m m i 提供了一系列软件 测试过程改进的指导方针。在c m m i 中，验证( v e r ) 和确认( v a l ) 过程域紧密的 与软件测试联系在一起；而诸如配置管理( c m ) 、风险分析( r s k m ) 、量化项目 管理( q p m ) 等过程域也同样包含了对测试过程改进的有力支持。 v e r 验证的目的是确保选择的工作产品满足其特定的需求。它主要包含了三个 特定e l 标：验证准备、执行同行评审和验证选择的产品，如图2 1 所示。 兰兰竺苎卜二： l 么二竺彳竺：三| 验证计划 1 l e = -j 、i验证选择的i i 工作产品 l 工 图2 1 验证语境图 验证准备：验证准备是验证前的前序工作，要求在项目的早期拟订验证策 略，建立验证环境并定义详细的验证规程和标准。验证策略之所以在项目早期 被制定，是因为许多和需求开发与设计有关的活动( 如分析、评审和演示) 要确 保需求事实上是可验证的。该特定目标包含3 个关键实践：确定需验证的工作产 品、建立验证环境和建立验证规则和规程。 执行同行评审：主要是对项目过程中的工作产品的评审，它是一个专门的 验证活动，其目的是减少在选择的关键产品或关键产品构件中的缺陷。该特定 目标包含3 个关键实践：准备同行评审、进行同行评审和分析同行评审数据。 验证选择的产品：执行选择产品的验证活动，分析验证结果，并确定纠正 措施。该特定目标包含2 个关键实践：进行验证和分析验证结果和确定纠正措施。 验证过程域实际上是对软件开发过程中形成软件代码之前所有产品的测 试，包括软件需求说明书、系统设计说明书、详细设计说明书等文档是否满足 预期的要求的测试，它贯穿于整个软件产品的开发过程，从需求的验证开始， 到对软件产品开发各个阶段的验证，最后结束于对完整的软件产品的验证。验 证过程域抽象了传统的同行评审，使其更加符合于整个软件过程。c m m i 中验 证过程域要求验证的产品、提出的验证过程、对验证结果的处理以及最终达到 的状态等等实践，都是对传统软件测试过程的一个扩充。 v a l 确认的目的是证实产品或产品构件置于预期的环境时满足预期的用途。它 主要包含了两个特定目标：确认准备和确认产品或产品构件。图2 2 是确认过程 域的语境图。 客户需求 产品需求 产品 确认需求 过程和支持需求 图2 2 确认语境图 确认准备：和验证准备类似，在软件生命周期的早期，应在项目中拟订确 认策略，然后建立确认环境，最后由测试人员定义详细的确认规程和标准。该 特定目标包含3 个关键实践：选择确认产品、建立确认环境和建立确认规则和规 程。 6 确认产品或产品构件：测试人员根据策略执行确认，以表明产品或产品构 件能够像预期的那样。在获取确认数据后，再对数据进行分析，标识问题和未 解决的事项。该特定目标包含2 个关键实践：执行确认和汇集及分析确认结果。 确认过程域实际上是对已经形成的软件成品的测试工作，包括对软件产品、 软件构件、产品运行表现、维护方法以及用户说明书等等。确认在开展过程中， 必须构建软件的测试环境，主要关注的是测试软件成品是否符合预期的用途， 目的是在软件生命期前尽早地找出软件中存在的缺陷，这一点与验证过程域是 不一样的。验证只是关心是否“正确地构造了产品”，而确认保证的是“构造 了正确的产品。但两者都是c m m i 对软件测试方法、范围的扩展，始终贯穿 于软件开发过程中，也是软件测试过程必备的核心和灵魂。 2 2 现有的软件测试过程模型 在软件开发的几十年中，随着开发方法的不断发展，开发理论渐趋成熟， 人们通过实践总结出了很多很好的开发过程模型，如瀑布模型、原型模型、螺 旋模型、增量模型以及r a t i o n a l 统一过程等。在这些模型中，测试作为软件开发 的一个阶段，往往被附加在开发模型的后面，并没有充分强调测试的价值，也 没有给测试以足够的重视。随着对软件质量问题的关注，软件测试专家在开发 模型的基础上总结出了一些测试模型。这些测试模型对测试活动进行了抽象， 并与开发活动有机结合，是测试过程管理的重要参考依据。下面对主要的测试 过程模型做一简单的介绍。 2 2 1v 模型 v 模型是最具有代表意义的测试模型，最早是由p a u lr o o k 在2 0 世纪8 0 年代 后期提出的，v 模型在英国国家计算机中心文献中发布，旨在改进软件开发的 效率和效果。v 模型的推出是对传统软件开发瀑布模型的改进，它反映了测试 活动与分析和设计的关系。如图2 3 中所示，图中的箭头代表了时间方向，左边 下降的是开发过程各阶段，与此对应的是右边上升的部分，即测试过程的各个 阶段。 图2 3v 测试模型 v 模型的从左到右描述了基本的开发过程和测试行为，非常明确地标明了 测试过程中存在的不同级别，并且清晰地描述了这些测试阶段和开发过程期间 各阶段的对应关系，这方便了测试源的追溯。此外，v 模型的软件测试策略既 包括低层测试( 单元测试和集成测试) ，又包括了高层测试( 确认测试、系统测试 和验收测试) ，低层测试是为了源代码的正确性，高层测试是为了使整个系统满 足用户的需求。 v 模型的不足之处在于，它仅仅是把测试过程作为在需求分析、概要设计、 详细设计以及编码之后的一个阶段，如果在软件开发中直到最后阶段才进行测 试，就错过了早期发现系统构架设计和逻辑设计中存在的严重问题的时机，到 了后期，要修复这种级别的问题将付出巨大代价，因为缺陷在软件开发过程中 是一个扩散放大的过程。同时，v 模型给人的感觉是模型的左边进行的是建设 性的活动，而模型的右边进行的是破坏性的活动。同时产品的开发到编码实现 之后就结束了，没有描述在实际情况中发现缺陷，需要多次开发和回归测试流 程。 2 2 2w 模型 w 模型由e v o l u t i f 公司提出，相对于v 模型，w 模型增加了软件开发中各阶 段应同步进行的验证和确认活动。如图2 4 中所示，w 模型由两个v 模型组成， 分别代表测试与开发过程，图中明确表示出了测试与开发的并行且相对独立的 关系。 图2 4w 测试模型 w 模型强调测试应伴随着整个软件开发周期，而且测试的对象不仅仅是程 序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。w 模型 有利于尽早地全面地发现问题。 但w 模型也存在局限性。在w 模型中，需求、设计、编码等活动被视为串 行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结 束，才可正式开始下一个阶段工作。但是在现实的软件开发项目中，系统的需 求往往无法在项目开始的阶段完全确立。对于当前软件开发需求变更频繁的情 况，w 模型并不能解除测试管理面临着困惑。 2 2 3h 模型 v 模型和w 模型都把软件的开发视为需求、设计、编码等一系列串行的活 动，而实际上，这些活动在大部分时间内可以交叉进行，所以相应的测试之间 也不存在严格的时序关系。 为了解决以上问题，有专家提出了h 模型，它将测试活动完全独立出来， 形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来， 如图2 5 所示。 测试流程 ： ； ； |其他流程( 如设计流程) i i - - - - - ： 图2 5h 测试模型 以上的h 模型示意图仅仅演示了在整个生产周期中某个层次上的一次测试 “微循环 ，图中的其他流程可以是任意开发流程，例如设计流程和编码流程。 9 也就是说，只要测试条件成熟了，测试准备活好了，测试执行活动就可以进行 了。 h 模型认为软件测试是一个独立的流程，贯穿产品的整个生命周期，与其 他流程并发地进行。不同的测试活动可以按照某个次序先后进行，但也可以相 互迭代，只要某个测试活动准备就绪，就可以开展下一阶段测试活动 2 3 基于c m m i 的软件测试过程模型 由于现有的各个软件测试过程模型都没有涉及到对软件测试流程本身的定 义，这不利于本文进行有关软件测试过程的度量研究。基于上述原则，以过程 度量为目的，提出了一个基本c m m i 的软件测试过程模型( c m m if o rs o f t w a r e t e s tp r o c e s s ，c m m l 4 s t p ) ，如图2 6 所示。 。o o 。o o - oo o 。- - - - - - - - - - - - - m i - - - - o - 测试需求 ；i - - - - - m e - - t im - - - - - i a - - - - h i - - - - - - - - - o - - - - - _ _ - - - - - p 图2 6c m m l 4 s t p 在c m m l 4 s t p 中显示的是软件测试的基本流程，包括测试计划、测试设计、 测试开发、测试执行以及结论分析、缺陷管理、记录等。每个流程阶段都有一 系列自身的任务，这些任务都和整个测试流程息息相关。在测试计划中，主要 是针对特定的测试需求准备测试，计划包括单元测试、集成测试或者是代码走 查、同行评审等等。在测试设计中，主要是根据测试计划定义的测试内容，编 写测试用例。在测试开发中，准备软件测试所需要的环境、数据库、测试脚本 以及测试工具等等。而测试执行阶段主要是根据前面准备的测试进行软件测试， 记录测试数据和测试结果。在结论分析中，主要是分析测试结果的正确性和真 实性，判断出软件中存在的缺陷，对可疑的缺陷可以进行回归测试，并将测试 出来的缺陷部分交至缺陷管理中。在缺陷管理中，主要是对缺陷进行分析，定 位缺陷在软件中存在的位置，以便缺陷修正后进行回归测试。c m m l 4 s t p 中的 各个测试流程都不是独立分割的，而是相互联系的，前一个阶段的输出数据会 成为另外几个阶段的输入数据，这都保证了测试信息流的独立和完整，在表2 1 详细地列出了c m m l 4 s t p 中各个阶段的任务。 1 0 表2 2 基于c m m l 的软件测试过程各阶段任务描述 过程阶段任务 内容： 1 确定测试范围，必须确定测试的类型。 2 确定测试需求，按照测试类型分类，对具体的测试内容划分测试需 求。 3 确定测试策略和测试方法。 4 确定风险，识别出测试项目中存在的风险，测试计划编写者应该规 避这些风险。 测试计划5 规划资源。测试资源包括：人力资源和系统资源。 6 指定时间进度表。根据实际项目的测试时间要求编写。 策略： 1 执行时间问题。在某些项目中，测试计划经常是等到开发周期后期 才开始实行，从而没有时间有效地执行计划。 问题： 1 经验问题。测试计划的编写者的测试经验是否足够? 2 度量问题。测试的量度和复杂性可能太大，没有自动化工具。 内容： 编写测试用例。按照测试计划中对测试需求的定义编写测试用例。 策略： 1 选择与测试需求的实质部分最相关的测试用例。 2 选择的测试用例应该不受应用程序改变的影响。 测试设计 问题： 1 测试过程流程顺序问题。必须先做测试设计( 包括测试需求) ，再 进行测试用例设计。 2 用例覆盖问题。测试用例是否覆盖了每个测试需求? 是否详尽? 3 用例有效性问题。是否采用了最好的技术方法来检验测试需求? 内容： 1 搭建测试环境。 2 准备测试数据库。主要是对测试结果数据的存储。 3 准备测试脚本。 4 准备测试工具。 测试开发 策略： 1 创建可以重用的测试过程和测试用例。 2 维护测试过程、测试用例与相关测试需求的一一对应。 问题： 1 测试开发问题。测试开发是否与测试需求或测试用例相对应? 2 重用性问题。测试过程或测试用例不可重复或不可重用。 内容： 1 执行测试用例和测试脚本。 2 验证预期的测试结果。 测试执行 3 记录测试发现的缺陷。 策略： 1 对发生错误或失败的测试用例、测试脚本，从终止的测试恢复，重 新进行测试开发。 2 对发现的缺陷进行确认。 问题： 1 测试工具问题。是否有效地利用更多的自动化测试工具? 2 测试记录问题。是否获取了所有的测试结果? 内容： 1 评估测试效率。主要是获取测试需求的覆盖率，是否已完成对所有 测试计划中要求的测试需求。 2 分析测试变更，对报告中的每个结论指标进行分析确认，尤其重要 的是确认发现的缺陷。 3 评价测试计划中的完成标准。 4 修正测试发现的缺陷，将发现的缺陷返回给项目开发方。 策略： 结论分析1 最大限度保证测试过程可视化，量化测试过程。 2 生成缺陷和测试覆盖率的总结报告。 问题： 1 测试完成标准问题。是否吧测试覆盖率作为测试进度的根据? 2 登陆问题。评估缺陷好似测试过程度量的重要指标，是否对发现的 缺陷进行度量? 3 工具问题。是否采用