（系统分析与集成专业论文）国际化软件测试研究.pdf

摘要 由于软件规模的不断扩大，软件功能不断加强，软件应用行业的不断拓展，对于软 i 件质量的要求不断提高，因此人们越来越意识到测试在软件开发过程中的重要性。国际 化软件需要更复杂的软件开发技术和管理方法，需要满足全球用户的不同需求，这就对 国际化软件的功能、性能等质量指标提出了更高的要求。提高软件测试在软件生命周期 中的地位是保证软件质量的关键，做好软件测试工作是解决软件质量问题的根本。为了 保证国际化软件的产品质量，进行有效的国际化软件测试成为必不可少的生产过程。 本文首先对软件测试的相关知识进行了归纳，阐述了测试目的、原则、类型和测试 用例的定义及其分类，讨论了软件测试策略的选择依据，研究了软件测试生命周期以及 测试过程的不同模型与选择策略，并且介绍了c m m i , i s 0 9 0 和t m m 等质量规范；其 次，阐述了国际化软件测试的基本概念，探讨了软件国际化的开发技术、工程技术以及 软件本地化语言翻译技术、工程技术等国际化软件技术，介绍了国际化软件测试的目标、 特征、级别和内容；最后，通过一个本地化测试的实例，介绍了s t 项目组的测试内容 以及本地化测试的目的、原则和内容，并且对s t 项目组测试过程中发现的缺陷的各种 类型以及缺陷的寻找方法进行了一个归纳和总结。 关键词：软件测试；国际化；本地化 a b s 仃a c t p e o p l eb f c o n em o r ea n dm o t ea w a r eo ft h ei m p o r t a n c ea b o u tt h et e s t i n gi ns o i h w r e d e v e l o p i n gp r o c e s s , f o ri n c e s s a n t l ya l l 甜g i n go ft h es o f t w a r es i z e ，i n c e s s a n t l ye n h a n c e m e n t o ft h es o f t w a r e f u n c t i o n , i n c e s s a n t l ye x t e n d i n go fa p p l i c a t i o ni l i 西咖i n c e s s a n t l y i m p r o v e m e n t o fs o f t w a r e q u a l i t y sr e q u e s t i n t e r n a t i o n a l i z a t i o ns o f t w n e e dn l o 怫 c o m p l i c a t e ds o f t w a r ed e v e l o p i n gt e c h n o l o g ya n dm a n a g i n gm e t h o d , n e e ds a t i s f y i n ga l lk i n d s o fr e q u i r e m e n ta l io v e rt h ew o r 正w h i c hb r i n g sf o r w a r dt h eh i g h e rr e q u i r e m e n to fq u a l i t y t a r g e ts u c ha si n t e r n a t i o n a l i z a t i o ns o f t w a r e sf u n c t i o n , p e r r o r m e n c e 锄珂s oo i l e n h a n c i n gt h e s o f t w a r et e s t i n gs t a t u si ns o f t w a r el i f e c y c l ei st h ek e yo fg u m - a n t e e i n gs o r w a r e 8q u a l i t y , a n d t od os o f t w a r e t e s t i n gj o bw e l l i st h er o o to fs o l v i n gs o f t w a r e q u a l i t yp r o b l e m t o g u a r a n t e e i n gt h ep r o d u c tq u a l i t yo f i n t e r n a t i o n a l i z a t i o ns o r w m e , i ti sa b s o l u t e l yn c c c & 蚰l r yt o d oe f f i c i e n ti n t e r n a t i o n a l i z a t i o ns o f t w a r et e s t i n gi np r o d d i n gp r o c e s s f i r s t l y , t h ep a p e rh a sd o n eac o n c l u s i o n c o r r e l a t i v ek n o w l e d g eo fs o f t w a r et e s t i n g , e x p a t i a t e st h et e s t sg o a l ，p r i n c i p l e , t y p ea n dt e s t s e sd e f m i f i o na n dc l a s s ，d s e n s s e st h e c h o i c eg i s to fs o r w a et e s t i n gs t r a t e g y , d o e s 翻 m n er e s e a r c ho ns o f t w a r et e s t i n gl i f e c y c l ea n d d i f f e r e n tm o d e l sa n dc h o i c es t r a t e g yd u r i n gt e s t i n gp r o e m s ，a n di n t r o d u c e sq u a l i t yc d t 甜o n ， s u c ha sc m m i ，i s 0 9 0 0 0 ，t m ma n ds oo n ；s e c o n d l y , t h i sp a p e re x p a t i a t e sb a s i cc o n c e p to f m t e m a t i o n a l i z a f i o ns o f t w a r et e s t i n g , d i s c u s s e st h ed e v e l o p i n gt e c h n o l o g y , p r o j e c tt e c h n o l o g y o fs o r w a r ei n t e r n a t i o n a l i z a t i o na n dl a n g u a g et r a n s l a t i n gt e c h n o l o g y , p r o j e c tt e c h n o l o g yo f s o f t w a r el o c a l i z a t i o na n ds u c hi n t e r n a t i o n a l i z a t i o ns o f t w a r et e c h n o l o g y , i n t r o d u c e st h eg o a l ， c h a r a c t e r , l e v e la n dc o n t e n to fi n t e r n a t i o n a l i z a t i o ns o f t w a r et e s t i n g ；f i n a l l y , w i t hae x a m p l e o fl o c a l i z a t i o nt e s t , i n t r o d u c e st h et e s t i n gc o n t e n ti ns tp r o j e c tt e a ma n dt h eg o a l ，p r i n c i p l e a n dc o n t e n to fl o c a l i z a f i o nt e s t , i n l e t sac o n c l u s i o na n ds m n m a r ya b o u tt h ed e f e c t s a l lk i n d s o f t y p e sa n dt h es e a r c h i n gd e f e c t sm o h o dd u r i n gt e s t i n gp r o c e s si ns tp r o j e c tt e a m k e y w o r d s ：s o f t w a r et e s t ；i n t e r n a t i o n a l i z a t i o n ；l o c a l i z a t i o n 湖北大学学位论文原创性声明和使用授权说明 原创性声明 本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所 取得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任 何其他个人或集体已经发表或撰写的成果作品。对本文的研究做出重要贡 献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的 法律后果由本人承担。 论文作者签名：曾绎 日期：2 。7 年月髟日 学位论文使用授权说明 本学位论文作者完全了解学校有关保留、使用学位论文的规定，即： 按照学校要求提交学位论文的印刷本和电子版本；学校有权保存学位论文的印 刷本和电子版，并提供目录检索与阅览服务；学校可以允许采用影印、缩印、数字 化或其它复制手段保存学位论文：在不以赢利为目的的前提下，学校可以公开学位 论文的部分或全部内容。( 保密论文在解密后遵守此规定) 作者签名：曹桴 指导教师撇：婚皮瞅 日期：工。0 1 年日彩b 隅啊、啪 第一章绪论 第一章绪论 本章介绍软件测试的发展状况及相关理论，描述国际化测试理论的发展前景、论文 的研究意义和研究内容 1 1软件测试的发展状况 1 1 1 软件测试的发展 每天都会发生一些由计算机软件问题引出的新故事：银行未正确报告收支平衡状 况，火星探测器在太空丢失，商店的刷卡机塞满了香蕉，还有臭名昭著的千年虫。随着 软件变得越来越复杂、功能越来越多、相互连接越来越广，就会出现越来越难以做出不 会出错的程序。无论程序员水平有多高，工作多么仔细，都难免产生软件问题。这就是 软件测试的来由。 在信息化建设当中，软件功能薄弱、漏洞众多等问题频频出现，软件质量理所当然 地成为了关注焦点。业界专家认为，不成熟的软件产品是国内信息化项目失败的一个重 要原因，同时，产品质量问题也将成为软件企业能否继续发展壮大的关键所在。纵观国 内和国外的软件产业，技术上的差距当然是存在的，但更为明显的也是致命的差距就在 于生产产品过程当中的质量控制。软件质量差、软件成本难以控制、可靠性不能保证等 一系列的问题让软件开发人员不得不考虑如何来解决这些困难和混乱。 随着软件产业化的发展，人们对软件的质量、成本和进度提出了较高的要求。质量 的控制已经不再是传统意义上的软件测试。传统的软件测试是基于代码运行的，只有在 软件开发的后期才能介入。然而，产业界的大量研究表明【“，设计活动引入的错误占软 件过程中出现所有错误数量的5 0 - 6 0 。m m 的研究结果表明，假定在分析阶段发现 的错误其改正成本为1 个单位的话，那么在测试之前发现一个错误的修改成本约为6 5 个单位，在测试时发现一个错误的修改成本约为1 5 个单位，而在发布之后发现一个错 误的修改成本约为6 0 到1 0 0 个单位同样该比例也适用于发现一个错误需要的时间。可 以看图1 i 中的两条曲线走向【i 】： 湖北大学硕士学位论文 图卜1 缺陷修改成本趋势图 m m 的研究结果还表明：缺陷存在放大趋势。如果在需求阶段漏过一个错误，该错 误就会引起n 个设计错误，n 成为放大系数。一般而言，不同阶段其n 不同。经验表明， 从概要设计到详细设计的错误放大系数约为1 5 ，从详细设计到编码阶段的错误放大系 数约为3 。图1 2 表示了 缺陷放大模垫的大致状况。 放大n l 倍放大n 2 倍放大1 1 3 倍 需求阶段缺陷 概要设计阶段 缺陷 详细设计阶段 缺陷 图1 - 2 缺陷放大模型图 编码阶段缺陷 因为有上面这些内在因素的制约，就能确定为什么很多软件产品在其开发过程中投 入了大量的时间和金钱在没完没了的系统测试上，而最后得到的产品却依然是低质量的 软件。 1 1 2 国际化软件测试的发展 由于软件规模的不断扩大，软件功能不断加强，软件应用行业的不断深入，软件市 场竞争更趋激烈，对于软件质量的要求不断提高。与传统行业制造的产品不同，软件的 质量属性不能简单地从外观上很直观地显现出来，因此需要采用适合软件测试特点的适 当方法，对软件的功能特性进行测试和评价。 国际化软件是面向全球发布的软件，不同区域市场的用户由于语言、文化和习俗的 不同，对软件的功能和质量的要求更趋复杂。显然，国际化软件与针对单 第一章绪论 一语言用户的常规软件不同，除了软件核心功能之外，对软件的国际数据处理和支持能 力，以及软件的本地化语言质量提出了更高的要求。 软件企业在进军国际化的进程中，面临着众多国际对手的竞争，软件产品的质量是 竞争条件中的重中之重。软件质量表示软件符合用户使用要求的程度，这种程度不仅表 现在软件产品自身的功能和性能方面，也表现在软件的国际化能力和本地化能力等方 面。软件企业只有提高软件质量，不断改进质量管理的方法和流程，提供具有符合国际 市场和用户需求的高质量软件产品，才能具备进军国际市场的实力。 国际化软件需要更复杂的软件开发技术和管理方法，需要满足全球用户的不同需 求，这就对国际化软件的功能、性能等质量指标提出了更高的要求。提高软件测试在软 件生命周期中的地位是保证软件质量的关键，做好软件测试工作是解决软件质量问题的 根本。为了保证国际化软件的产品质量，进行有效的国际化测试成为必不可少的生产过程。 1 2论文的研究目的和意义 在重视软件产品质量的今天，人们越来越意识到测试在软件开发过程中的重要性。 做好软件测试，尤其是国际化软件的测试，是非常重要的。近年来，国内外对国际化软 件测试进行了大量的研究，但目前该领域仍处于百家争鸣的阶段，所以有必要开展国际 化软件测试技术的研究。 1 3 论文的研究内容和组织结构 1 3 1 论文的研究内容 本论文研究了软件测试的基础理论以及一些基本的软件测试技术，在此基础上结合 国际化软件的特点，分析了国际化软件的特点对软件测试的影响及其给软件测试提出的 难题；然后重点研究了国际化新特性给软件测试带来的影响并提出了新的测试要求；另 外，本文在全面剖析国际化测试的基础上，结合一些实例阐述了国际化软件测试的方法、 流程和特点最后，对国际化测试前景进行了分析和展望。 1 3 2 论文的组织结构 第一章介绍了论文研究的问题背景，包括软件测试和国际化软件测试的发展状况、 软件测试的基础理论，以及论文的研究内容和章节安排。 第二章阐述了测试目的、测试原则、测试类型、测试用例的定义及其分类，讨论了 软件测试策略的选择依据，研究了软件测试生命周期以及测试过程的不同模型与选择策 略，并介绍了c m m l ，i s 0 9 0 0 0 和t m m 等质量规范。 湖北大学硕士学位论文 第三章阐述了国际化的基本概念和术语、国际化软件技术以及国际化软件测试特征 与测试内容。 第四章首先简介了s t 项目的情况，然后介绍了本地化测试的内容，最后结合一些 缺陷图分析和总结了本地化测试中的一些典型缺陷。 最后阐述对论文工作的总结和对后续工作的展望 4 第二章软件测试基础 第二章软件测试基础 本章主要对软件测试的概念和相关定义进行了梳理。阐述了测试目的、测试原则、 测试类型、测试用例的定义及其分类，讨论了软件测试策略的选择依据，研究了软件测 试生命周期以及测试过程的不同模型与选择策略，并介绍了c m m i , i s 0 9 0 0 0 和t m m 等 质量规范。 2 1 软件测试技术 2 1 1 测试目的与原则 测试的目的决定了整个测试活动的方针与政策。如果测试的目的是证明程序中没有 缺陷，就会在测试过程中自然地回避出现故障的地方，从而极大降低测试结果的可靠性 相反，如果测试的目的是证明程序中存在缺陷，就会在测试中力求发现缺陷。g l e nm 耐捌 在其关于软件测试的著作中陈述了一系列可以服务于测试目的的规则： ( 1 ) 测试是一个为了发现错误而执行程序的过程。 ( 2 ) 一个好的测试用例是指能找到迄今为止尚未发现的错误的用例。 ( 3 ) 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。 事实上，测试的目标就是能够通过一组有效的测试用例系统地揭示不同类型的错误， 并且耗费最少时间与最小工作量。同时，测试结果本身无法说明软件不存在错误和缺陷， 它只能表示软件错误和缺陷曾经出现过。在进行有效的测试之前，还需要了解软件测试 的基本原则网； ( 1 ) 所有的测试都应根据需求分析来制定。 2 ) 测试计划应该在测试工作执行真正开始前较长时间就进行。 ( 3 ) 在软件测试中应用- - a 原则 ( 4 ) 测试应从“小规模”开始，逐步转向。大规模”。 ( 5 ) 不需进行穷举测试，然而有必要充分覆盖程序逻辑并确保使用程序设计中的所 有条件。 ( 6 ) 为了达到最有效的测试，应该由独立的第三方团队实施测试活动。 2 1 2 软件测试的类型 黑盒测试和白盒测试是广泛使用的两种测试类型。 ( 1 ) 黑盒测试又称功能测试。黑盒测试的基本观点是：任何程序都可以看做是从定 义域映射到值域的函数。该观点将被测程序看做一个关闭的黑盒子，里面的内容对测试 5 湖北大学硕士学位论文 人员而言是未知的在用黑盒测试方法设计测试用例时，测试人员所使用的唯一信息就 是软件的需求说明书，在完全不考虑程序内部结构和内部特性的情况下，只依靠被测程 序输入和输出之问的关系或程序的功能来设计测试用例，推断测试结果的正确性，即所 依据的只是程序的外部特性。 ( 2 ) 白盒测试又称结构测试，或者又叫基于程序的测试。白盒测试将被测程序看做 一个打开的盒子，测试人员可以看到被测的源程序，可以分析被测程序的内部构造。此 时测试人员可以完全不考虑程序的功能，只根据其内部构造设计测试用例。 ( 3 ) 黑盒测试与白盒测试的比较 黑盒测试和白盒测试是两种完全不同的测试方法，它们的出发点不同，反映了事物 的两个极端。它们各有侧重，都有坚定的理论拥护者。r o b e r tp o s t o n l 2 6 认为：“白盒测试 自2 0 世纪7 0 年代以来一直在浪费测试人员的时间它不支持良好的软件测试实践， 应该从测试人员的工具包中剔除”，而e d w a r dm i l l 一3 0 1 ，则认为：“如果能达到8 5 或更好的分支覆盖率，那么白盒测试能识别出的软件故障，一般是黑盒测试能找出的故 障的两倍”。事实上，黑盒测试和白盒测试在测试实践中都非常有效而且都很实用， 两者互相补充。 黑盒测试基于外部规格说明，它根据需求说明书设计测试用例，不涉及程序的内部 结构因此，黑盒测试有两个显著的优点：第一，黑盒测试与软件具体实现无关，所以 如果软件实现发生了变化，测试用例仍然可以使用。第二，设计黑盒测试用例可以和软 件实现同时进行，因此可以压缩项目总的开发时间。然而，黑盒测试的缺点是需求说明 书无法保证其完全正确。如果程序的外部特性本身有问题或者需求说明书的规定有误， 例如说明书中规定了多余的功能或是漏掉了某些功能，黑盒测试则无法进行判断。另一 方面，白盒测试只根据程序的内部结构进行测试，而不考虑其外部特性。白盒测试要求 对被测程序的代码实现一定程度的覆盖。测试人员可以严格定义要测试的确切内容，明 确提出要达到的测试覆盖率，以减少测试的盲目性。如果要求被测软件。做了所有它该 做的事，而没有做一点它不该做的事”【坫】，就需要把黑盒测试与白盒测试结合起来使用。 2 1 3 测试用例设计 测试用例是软件测试的核心。每个项目都需要一套优秀的测试方案和测试设计方 法，来保证以最少的人力和资源投入，在最短的时间内完成测试并发现软件系统的缺陷， 保证软件的优良品质，因此它是测试工作的指导，是软件测试的必须遵守的准则，更是 软件测试质量稳定的根本保障。 6 第二章软件测试基础 测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、 技术和策略，其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试 脚本等，并形成文档嗍。编制测试用例需要遵循以下具体做法： ( 1 ) 测试用例文档模板 编写测试用例文档时应有文档模板，须符合内部的规范要求。测试用例文档将受制 于测试用例管理软件的约束。软件产品或软件开发项目的测试用例一般以该产品的软件 模块或子系统为单位，形成一个测试用例文档。 ( 2 ) 测试用例的设置 早期的测试用例类似功能清单，是按功能设置用例。后来逐步演变为按功能、路径 混合模式设簧测试用例。按功能测试是最简捷的，按用例规约遍历测试每一功能。而路 径分析最大的优点是在于可以避免漏测试。但路径分析法也有局限性，比如一个稍微复 杂的模块常常会有几十到上百条路径，因此需要根据实际情况进行选择 ( 3 ) 设计测试用例 测试用例可以分为基本事件、备选事件和异常事件。基本事件的测试用例应包含所 有需要实现的需求功能，覆盖率达1 0 0 。设计备选事件和异常事件的用例，则可以采 用常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖 法等。在实际工作中，需要灵活运用各种基本方法来设计完整的测试用例。 2 1 4 软件测试覆盖准则 软件测试覆盖准则是用来判定测试用例是否充分的重要依据。测试覆盖分为逻辑覆 盖、功能覆盖和需求覆盖等，其中，逻辑覆盖准则是以程序内部的逻辑结构为基础设计 的白盒测试用例，要求对被测程序的逻辑结构有清楚的了解。逻辑覆盖又可分为语句覆 盖、判定覆盖、条件覆盖、判定条件覆盖及路径覆盖等。 语句覆盖要求设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少 被执行一次。与其他几种逻辑覆盖相比较，语句覆盖是比较弱的覆盖准则。 判定覆盖要求设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支 和取假分支至少执行一次，即判断的真假值均要被检测。判定覆盖又称为分支覆盖 条件覆盖要求设计若干测试用例，执行被测程序，使得程序中每个判断的每个条件 的可能取值至少被执行一次。 判定条件覆盖要求设计足够的测试用例，执行被测程序，使得判断中每个条件的所 有可能取值至少被执行一次，同时每个判断的所有可能判断结果也至少被执行一次。 7 湖北大学硕士学位论文 路径覆盖要求设计足够多的测试用例，覆盖程序中所有可能的路径。在实际问题中， 要在测试中覆盖所有的路径是不可能实现的，只能把覆盖的路径数压缩到一定限度内， 有选择地测试程序中有代表性的路径。 此外，还有数据流测试覆盖准则，包括定义覆盖、引用覆盖、定义一引用覆盖准则 等；面向对象的类覆盖和方法覆盖准则【9 l ；以及针对黑盒测试的功能覆盖、需求覆盖和 场景覆盖准则等 2 2 软件测试策略 2 2 1 测试阶段划分 软件测试是在软件投入运行前，对软件需求分析、设计说明和编码进行确认，在软 件生存期中占据着重要位置。程序中的故障并不总是由编码引起，有时是由详细设计、 概要设计阶段，或者需求分析阶段的问题引起，即使针对源程序进行测试，发现故障的 根源也属于开发前期的各个阶段。解决问题、排除故障也必须追溯到前期的工作。软件 工程界普遍认为：在软件生存期的每一阶段都应进行评测，检验本阶段的工作是否达到 了预期的目标，尽早地发现并消除故障，以免因故障延时扩散而导致后期测试困难【2 5 1 。 因此，软件测试应贯穿于软件定义与开发的整个期间。测试阶段主要包括：单元测试、 集成测试、确认测试、系统测试和验收测试等，可以针对不同的测试过程作出相应的裁 减。 ( 1 ) 单元测试 单元测试是在软件开发过程中进行的最低级别的测试活动，其测试的对象是软件设 计的最小单位。在传统的结构化编程语言中，单元测试的对象一般是函数或子过程。在 类似c + + 这种面向对象的语言中，单元测试的对象可能是类，也可能是类的成员函数。 单元测试的原则同样也可以扩展到第四代语言中，而单元被典型地定义为一个菜单或显 示界面。单元测试一般在编码之后进行，由于每个模块在整个软件中并不是孤立的，在 对每个模块进行测试时，需要考虑它和周围模块之间的相互联系。为模拟这一联系，在 进行单元测试时，必须设置若干个辅助测试模块，即驱动模块和桩模块。 ( 2 ) 集成测试 当每个模块都能单独工作后，需要将这些模块组装起来验证是否正常。程序在某些 局部反映不出的问题，就会在全局上暴露出来，影响到功能的正常发挥。因此，在每个 模块完成单元测试以后，需要按照设计的程序结构图，将它们组合起来，进行集成测试。 8 第二章软件测试基础 集成测试是按设计要求把通过单元测试的各个模块组装在一起，检测与接口有关的各种 故障非增式集成测试法是独立地测试程序的每个模块，然后再把它们组合成一个整体 进行测试；增式集成测试法先把下一个待测模块组合到已经测试过的那些模块上去，再 进行测试，逐步完成集成。 ( 3 ) 确认测试 集成测试完成以后，分散开发的模块被连接起来，构成了一个完整的程序，其中各 模块之间存在的种种问题己被消除，于是进入了确认测试阶段。所谓确认测试，是对照 软件需求说明书，对软件产品进行评估以确定其是否满足软件需求的过程。在软件开发 过程中或完成以后，为了对它在功能、性能、接口以及限制条件等方面做出切实的评价， 就应进行确认测试 ( 4 ) 系统测试 软件只是计算机系统的一个重要组成部分，软件开发完成以后，还应与系统中其他 部分联合起来，进行一系列系统联调测试，以保证系统各组成部分能够协调地工作。系 统测试实际上是针对系统中各个组成部分进行的综合性检验，很接近r 常测试实践。系 统测试的目标不是要找出软件故障，而是要证明系统的性能一般认为：独立测试机构在 测试过程中查错积极性高并且有解决问题的专业知 谚 【1 4 】。因此，系统测试最好由独立的测试机构完成。 ( 5 ) 验收测试 验收测试是将最终产品与最终用户的当前需求进行比较的过程，是软件开发结束后 软件产品向用户交付之前进行的最后一次质量检验活动，它解决开发的软件产品是否符 合预期的各项要求，用户是否接受等问题。验收测试不只检验软件某方面的质量，还要 进行全面的质量检验并决定软件是否合格。因此，验收测试是一项严格的、正规的测试 活动，并且应该在生产环境中进行。如果软件是按合同开发的，在合同中规定了验收标 准，则验证测试由签订合同的用户进行。如果产品不是按合同开发的，开发组织可以采 用其他形式的验收测试，即a l p h a 测试和b e t a 测试。 a l p h a 测试和b e t a 测试都是在指定的时问内以生产方式运行并操作软件。a l p h a 测 试一般在开发公司内，由最终用户进行。被测试的软件由开发人员安捧在可控的环境下 进行检验并记录发现的故障和使用中的问题。b e t a 测试则一般在开发公司之外，由经过 挑选的真正用户群进行，它是在开发人员无法控制的环境下，对要交付的软件进行的实 际应用性检验。在测试过程中用户要记录遇到的所有问题，并且定期向开发人员通报测 9 湖北大学硕士学位论文 试情况。a l p h a 测试和b e t a 测试都要求仔细挑选用户，要求用户有使用产品的积极性， 能提供良好的硬件和软件配置等。 2 2 2 验证和确认 验证是对需求说明书、设计规格说明和代码之类的产出物进行评审的过程，可应用 到开发过程中所有产出物上，以确保该阶段的产品与期望的一致。确认是在开发过程中 或结束时进行的评估系统或组成部分的过程，目的是判断系统是否满足规定的要求，包 括实际软件或仿真模型的运行，是“基于计算机的测试”【2 刀验证和确认是为捕获不同类 型的软件故障而设置的过滤器，它们相互补充，以保证最终软件产品的正确性、完善性 和一致性。 软件包括程序以及开发、使用和维护程序所需的所有文档。程序只是软件产品的一 个组成部分，表现在程序中的故障，并不一定是由编码所引起的。实际上，软件需求分 析、设计和实施阶段都是软件故障的主要来源因此，软件测试不仅包含对代码的测试， 而且包含对软件文档和其他非执行形式的测试。验证测试就是针对开发过程中的任何中 间产品进行的测试。按照i e e e a n s i 的定义，验证测试是为确定某一开发阶段的产品是 否满足在该阶段开始时提出的要求而对系统或部分系统进行评估的过程。所谓验证，是 指确定软件开发的每个阶段、每个步骤的产品是否j 下确无误，是否与上游阶段的产出物 相一致，对诸如软件需求说明书、设计规格说明和代码之类的产品进行评估、审查和检 查的过程，属于静态测试。如果是针对代码，就是指代码评审，或者称为代码走查。另 一种称之为确认的测试则只能通过运行代码来完成。按照i e e e a n s i 的定义，确认测试 是在开发过程中或结束时，对系统或部分系统进行评估以确定其是否满足需求说明书的 过程。所谓确认，是指确定最后的软件产品是否正确无误，包括实际软件或仿真模型的 运行，是动态测试。从广义上讲，测试= 验证+ 确认。确认测试包括前述的单元测试、集 成测试、确认测试、系统测试和验证测试等。确认和验证互相关联，但也有明显的区别。 相应的验证测试计划和确认测试计划涉及不同的内容。总之，确认和验证互相补充，保 证最终软件产品的正确性、完全性和一致性。 ( 1 ) 验证是对软件产品进行评审或人工检查的过程。 验证的基本方法有：审查、走查、单人复审、多人复审等，它们有许多相似之处， 但也不尽相同，通常审查是最正规的方式。具体的验证活动包括计划评审、需求评审、 架构设计评审、代码走查、测试用例评审、测试报告评审等。 1 0 第二章软件测试基础 正式评审、技术评审以及软件评审是审查的几种不同说法审查以会议的形式进行， 剩用集体的智慧查找软件产品中存在的问题，从而保证软件产品的质量。软件审查的对 象可以是任何重要的工作产品，例如，软件需求、概要设计、详细设计等阶段的成果以 及源程序代码、测试计划和测试用例等。审查的目标是为了找出软件中存在的问题一不 仅是出错的地方，还包括遗漏或多余的地方。审查要遵守一套固定的规则，比如设定要 审查的工作量，提前预审的时间以及正式评审会的时间安排等，其重要性在于使评审人 员了解自己的作用及预期的目标，这样有助于使审查工作进展顺利。参加评审的人员包 括需求设计人员、开发人员、测试人员和第三方同行专家，以3 至6 人为宜，这样可以 使会议参加者昕到更多的不同声音。每一个参审人员都应了解自己的责任和义务，为审 查做好准备，并积极参与审查工作。审查过程中找出的问题大部分是在预审期间发现的， 评审会上进行确认。审查小组必须做出总结审查结果的书面报告，诸如发现了多少问题， 在哪里发现的以便于开发成员进行修改。， 走查不像审查那么正式。准备工作一般由主持者负责，参加人员只是简单地参加会 议，在会议前不需要做更多的准备工作。走查的目标是：熟悉材料、发现软件故障。走 查的会议只有主持人必须事先准备。主持人通常是待评审材料的作者。走查的输入是被 检查的材料以及可使用的标准等，走查的输出是走查报告。因为主持人是作者，其他参 加人员没有多少负担，使得走查工作的覆盖面可以比审查大一些，从而给更多的人提供 了一个熟悉了解材料的机会。有时，走查的目的不是为了发现软件故障，而只是为了熟 悉材料，进行交流。走查对象通常是“继承”过来的，如果能发现一些问题当然好，但 主要目的是使自己更加熟悉材料，了解产品。 单人复审和多人复审通常是在编写代码的程序员和充当审查者的其他一、两个程序 员或测试人员之间进行，这个小团体只是在一起走读代码或其他材料，寻找问题和失误。 这种方式最为灵活，同时也是要求最低的一种验证方式。 ( 2 ) 确认测试 确认测试以需求说明书中的规定作为检验尺度，在开发过程中或结束时，对系统或 组成部分进行评估，确认开发的软件是否满足需求说明书规定的所有功能和性能，文档 资料是否完整、人机界面和其他方面是否令用户满意，例如可移植性、兼容性、故障恢 复能力及可维护性等。 确认测试活动包含的任务有单元测试、集成测试、系统测试、确认测试、验收测试 湖北大学硕士学位论文 以及综合起来的各种测试任务，确认的目标是决定最后的软件产品是否正确无误。比如， 开发的软件是否符合软件需求说明书和用户要求，输出的信息是否是用户想要的信息， 在将来的实际使用环境中能否正确稳定地运行，是否存在隐患等，其中也包古了对它在 功能、性能、接口以及限制条件等方面是否满足需求的评价。由于穷举测试是不现实的， 因此测试的目标是通过有限的测试，发现尽可能多的故障。 基于需求的侧试必须采用黑盒测试方法，在不知道详细设计规格说明或代码的情况 下根据软件需求或用户需求进行测试，采用等价类划分、边界值分析和故障猜测等方法 设计测试用例。基于软件内部逻辑结构的测试只能采用白盒测试方法。无论哪种测试策 略，都应满足结果明确和可重复性。 2 3 软件测试周期模型 2 3 1 测试生命周期 软件测试过程是用于定义软件测试的流程和方法。持续的过程改进由许多小的、循 序渐进的改进步骤汇聚而成，而不是一次性的革命性的变革。测试过程的质量将直接影 响测试结果的准确性和有效性。软件测试过程和软件开发过程一样，都遵循软件工程原 理，遵循管理学原理。随着测试过程管理的发展，在实践中总结出了很多好的测试过程 模型。这些模型将测试活动进行了抽象，并与开发活动有机的进行了结合，是测试过程 管理的重要参考依据。 测试要符合生命周期的要求。如果要理解项目的实际情况，一个很重要的部分就是 考虑如何让测试符合整个系统的生命周期、各个阶段、各个组成部分的活动以及与那些 活动相关联的活动的要求，因为其中的策略、计划和各项措施也许对于某个生命周期来 说非常理想的，但是对于测试系统开发和测试实施来说，他们的作用非常有限。因此， 对于许多不同的生命周期模型定义，要想使测试工作很好地配合整个项目的生命周期， 关键的因素就是合理的划分各个测试阶段，为它们制定合理的准入准出标准，并遵循这 些标准。 2 3 2v 模型 常用的软件测试生命周期模型是v 模型，它最早由p a u lr o o k c 怕1 提出，如图2 1 所 示，从左到右描述了基本的开发过程和测试行为，明确地标注了不同类型的测试，清楚 地描述了这些测试阶段和开发过程期间各阶段的对应关系。 1 2 第二章软件测试基础 图2 - i 软件测试v 模型图 v 模型指出，单元测试和集成测试应检测程序的执行是否满足软件设计的要求；系 统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件 的实现是否满足用户需要。但v 模型仅仅把测试作为在编码之后的一个阶段，而忽视了 测试活动对需求分析、系统设计等活动的验证和确认的功能，存在一定的局限性。 2 3 3 w 模型 相对于v 模型，w 模型【1 6 】增加了软件各开发阶段中应同步进行的验证和确认活动。 如图2 2 所示，w 模型由两个v 字型模型组成，分别代表测试与开发过程，图中明确表 示出了测试与开发的并行关系。 湖北大学硕士学位论文 图2 - 2 软件测试w 模型图 w 模型强调，测试伴随整个软件开发周期，而且测试的对象不仅仅是程序，需求和 设计等同样需要测试，测试过程与开发过程应该是同步进行。w 模型有利于尽早而全面 地发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动 中。同时，对需求的测试也有利于尽早了解项目难度和测试风险，及时制定应对措施。 但w 模型也存在局限性。在w 模型中，需求、设计和编码等活动是串行的，而测 试和开发活动也保持着一种线性的前后关系，这样就无法支持迭代的开发模型，不能解 决复杂测试管理面临的困惑。 2 3 4 h 模型 v 模型和w 模型都把软件的开发视为需求、设计、编码等一系列串行的活动，而实 际上，这些活动在大部分时间内可以交叉进行，所以，相应的测试之间也不存在严格的 时序关系。同时，各层次的测试如单元测试、集成测试、系统测试等也存在反复迭代的 关系。 为了解决以上问题，出现了h 模型【1 6 1 。它将测试活动完全独立出来，形成了一个完全独 立的流程，将测试准备活动和测试执行活动清晰地体现出来，如图2 3 所示。 1 4 第二章软件测试基础 需求需求舒辑设计编皤集成i 隋赣醢 图2 - 3 软件测试h 模型 该示意图展示了在软件生命周期，测试始终处于一种微循环状态下。图中显示的其 他流程可以是任意的开发流程，例如设计或者编码。而只要测试条件成熟，并且测试准 备活动己经完成测试执行活动就可以开始进行。 h 模型认为软件测试是一个独立的流程，贯穿产品的整个生命周期，与其他流程并 发地进行。h 模型指出软件测试要尽早准备，尽早执行。不同的测试活动可以按照某个 次序先后进行，但也可以相互迭代，只要某个测试活动准备就绪，就可以开展下一阶段 测试活动。 2 3 5 模型选取策略 从以上模型中可以看出，v 模型强调，项目开发阶段应该对应不同的测试阶段，但 没有将程序以外的其它内容作为测试对象。而w 模型则明确指出需要对需求和设计 阶段进行测试。然而，v 模型和w 模型都没有抽象出完整的测试过程，不适合当前软 件开发中广泛应用的迭代模型。h 模型则明确指出，测试是可以完全独立的。只要测试 条件成熟，就可以开展测试。在实际测试工作中，应该尽可能地利用各模型中对项目有 实际价值的方面，而不能强行的将这些模型生搬硬套。在测试实践中，可以运用w 模 型搭建框架，尽早开展测试活动，同时结合h 模型的独立测试思想，一旦某个阶段相关 测试活动准备就绪，就可以独立开展下一阶段的测试工作，同时将测试任务迭代进行。 除上述几种常见模型外，业界还流行其他几种模型，例如x 模型等。x 模型提出针 对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合 1 5 湖北大学硕士学位论文 成可执行的程序。前置测试模型则体现了开发与测试的结合，要求对每一个交付内容进 行测试。这些模型都针对其他模型的缺点提出了一些修正意见，但本身也存在一些不足 之处所以在测试过程管理中，需要结合项目特点正确选取过程模型。 2 4 质量管理与成熟度模型 2 4 1 质量管理的八项原则与i s 0 9 0 0 0 八项质量管理原则是i s 0 9 0 0 0 族标准的理论依据，为组织建立和实施质量管理体系 提供了坚实的理论基础。八项质量管理原则是最基本、最通用的一般性规定，因此使得 以其为基础的i s 0 9 0 0 0 族标准在全世界范围内得到普遍的接受。八项质量管理原则【悖l 的内容包括：以顾客为关注焦点；领导作用；全员参与；过程方法；管理的系统方法； 持续改进；基于事实的决策方法和与供方互利的关系。从这些内容可以看出，组织在进 行质量管理，实现、保持并改进其整体业务能力时，应用八项质量管理原则不仅能够为 组织带来直接的利益，而且能够降低组织的经营成本和经营风险，使组织的所有相关方 受益。 i s 0 9 0 0 0 族是由国际标准化组织的i s o t c l 7 6 技术委员会制订的国际标准，是在总 结世界各国，特别是工业发达国家质量管理经验的基础上产生的质量管理体系，是宝贵 的软件财富。质量管理体系的目的是鼓励组织分析顾客需求，规定有助于实现顾客能接 受的产品的过程并使这些过程受控，提供持续改进的框架改进组织的业绩以持续达到顾 客满意。这样组织就能够向组织的顾客和其他相关方始终提供满足要求的产品，得到信 任。质量管理体系理论研究的对象就是如何建立质量方针和质量目标，如何识别、确定、 实现和管理为达到这些目标的活动或过程的系统 2 4 2 从c m m 到c m m i 卡内基梅隆大学软件工程研究院推出的c m m ( 软件能力成熟度模型) 模型将软件组 织的过程能力分为5 个成熟度级别，每一个级别定义了一组过程能力目标，并描述了要 达到这些目标应该采取的实践活动。软件组织通过努力一步步达到这些预定的目标，从 而得到持续的过程改进，实现组织高效率、低成本地交付高质量软件产品的战略目标。 2 0 0 0 年，s e i 又提出了新一代成熟度模型的要求，整合不同模型中的最佳实践、建立统 一模型，覆盖不同领域，供企业进行整个组织的全面过程改进，并形成了适用于企业全 面过程改进的统一框架- - c m m 集成，即c m m i 。c m m i 产品集包括c m m i 产品框架及 1 6 第二章软件测试基础 由框架衍生的一套c m m i 产品c m m _ i 模型主要组成部分包括：过程域、特定目标、特 定实践、通用目标和通用实践 在c m m i 的过程域中，与测试密切相关的两个过程域是v e r ( v e r i f i c a t i o n ，验证) 和 v a l ( v a l i d a t i o n ，确认) 。v e r 过程域确保选定的工作产品满足特定的需求。根据特定的 需求选择工作产品，并且要选择有效的验证方法对工作产品进行验证。同行评审是已经 证实的有效的验证方法之一。验证是一种增量过程，从产品部件验证开始，直到整个产 品装配完成结束验证。v a l 过程域确认产品满足了用户的需要，确认可以在实际操作环 境和仿真操作环境下进行。确认的范围包括对产品、产品部件、选定的交互工作产品与 过程的确认等，通常需要对产品、产品部件、选定的交互工作产品和过程进行再验证和 再确认。 2 4 3 测试成熟度模型 在过去的几年时问里，业界还出现了许多衡量测试过程成熟度的方法，如 t t m k o o m e n h 和m a r t i np o l 提出的测试过程改进模型：d a v i do e l p e r i n 和a l d i nh i y a