（计算机应用技术专业论文）自动回归测试系统的设计与实现.pdf

摘要 摘要 随着计算机应用领域的不断扩大，软件测试显得尤为重要。保证软件质量， 提高软件可靠性，成为决定软件成败的关键。回归测试是软件测试的重要组成部 分，贯穿于软件测试的各个阶段，本课题就是在对软件测回归测试技术研究的基 础上，实现自动回归测试系统，使回归测试过程自动化。 本文首先研究自动回归测试技术，分析回归测试中一些关键技术点，如测试 模型和测试策略等，为设计自动回归测试系统奠定基础。然后，设计并实现该系 统，以达到自动回归测试的目的。最后，将系统应用于实际项目，来展示自动回 归测试的流程。 本课题的重点是实现自动回归测试系统，而为了设计该系统，首先要理解自 动回归测试的内容和回归测试的流程。在此，对于回归测试模型进行了研究，并 改进了原有的测试模型，使得回归测试贯穿到同一开发周期的各个阶段。然后， 对于四种回归测试策略进行分析，尤其是对于“再测试修改的部分”这种策略， 给出了详细的算法设计，并实现了该算法。 对于自动回归测试系统，主要从三方面进行设计和实现：用例管理、回归测 试过程管理和结果收集。系统的用户主要有测试管理人员和测试执行人员。他们 在回归测试中的任务不同，因此对于系统的功能权限也不同。对于回归测试流程 的设计，也是本课题研究的重点。 本系统是对于自动回归测试的尝试，也存在着缺点和不足，有待进一步完善。 比如，本系统可以与测试脚本关联，这样可以直接获得测试结果，而无需人工参 与。将自动回归测试系统与自动化测试系统整合起来，是本系统有待改进的内容。 关键词自动回归测试；测试模型；测试策略 a b s t r a c t a b s t r a c t w it ht h ed e v e l o p m e n to fc o m p u t e ra p p lic a t i o n ，t h es o f t w a r et e s th a s b e c o m em o r ea n dm o r ei m p o r t a n t e n s u r i n gt h eq u a lit yo fs o f t w a r ea n d i m p r o v i n gt h er e l i a b i l i t yo f s o f t w a r ea r et h ek e yp o i n to f s o f t w a r e d e v e l o p m e n t r e g r e s s i o nt e s tis o n eo ft h em o s ti m p o r t a n tp a r ti ns o f t w a r e t e s t i ti sa v a i l a b l ei ne v e r ys t a g eo ft h et e s t t h i sp r o j e c ti so nt h e b a s i so fd i s c u s s i o no ft h et e c h n o l o g yo fr e g r e s s i o nt e s t i td e v e l o p st h e a u t o m a t i cr e g r e s s i o nt e s ts y s t e mw h i c hm a k e st h ep r o c e s so fr e g r e s s i o n t e s ta u t o m a t i c t h i st h e s i sb e g i n sw i t hd i s c u s s i o no ft h et e c h n o l o g yo fr e g r e s s i o nt e s t ， a n a l y z i n gt h ek e yp o i n to fr e g r e s s i o nt e s t ，s u c ha st e s tm o d e la n ds t r a t e g y i ti su s e df o rt h ed e v e l o p m e n to fa u t o m a t i cr e g r e s s i o nt e s ts y s t e m n e x t ， im a k et h ea r c h i t e c ta n dd e v e l o p m e n tw o r k f i n a l l y 。ia p p l yi tt ot h er e a l p r o j e c tt os h o wt h ep r o c e s so fa u t o m a t i cr e g r e s s i o nt e s t t h i st h e s i si sf o c u so nt h ed e v e l o p m e n to fa u t o m a t i cr e g r e s s i o nt e s t s y s t e m t h ef i r s t s t e pist ou n d e r s t a n dt h ec o n t e n ta n dp r o c e s so f r e g r e s s i o nt e s t ia n a l y z et h ee x i s t i n gt e s tm o d e la n dm a k ei ti m p r o v e d t h en e wm o d e lc a nm a k et h er e g r e s s i o nt e s tw o r k i n gw i t ht h ed e v e l o p m e n t i ne v e r ys t a g e b e s i d e st h a t ，ia n a l y z et h ef o u rr e g r e s s i o nt e s t s t r a t e g i e s e s p e c i a l l yf o rt h e t e s tm o d i f i e dp a r t s t r a t e g y ，ig i v et h e a r i t h m e t i co fi ta n dm a k ei tr e a l i z a b l e t h ea u t o m a t i cr e g r e s s i o nt e s ts y s t e mh a st h r e em a i np a r t s ：t e s t c a s e m a n a g e m e n t ，r e g r e s s i o np r o c e s sm a n a g e m e n ta n dr e s u l tc o l l e c t i o n t h e u s e r sa r et e s tm a n a g e ra n dt e s te x e c u t o r a sar e s u l to ft h e i rd i f f e r e n t t a s k ，t h e yh a v ed i f f e r e n tr i g h tt oa c c e s st h es y s t e m b e s i d e st h a t ，t h e d e s i g no ft h ep r o c e s so fr e g r e s s i o nt e s ti so n eo ft h em o s ti m p o r t a n tp a r t i nt h i st h e s i s t h i sp r o j e c ti sf o c u so nt h er e s e a r c ho fa u t o m a t i cr e g r e s s i o nt e s t i t i ss u c c e s s f u la n di tc a nb eu s e dt ot e s tt h er e a lp r o j e c t b u ti th a ss o m e d is a d v a n t a g e sa n dw a i t sf o rt h el a t e ri m p r o v e m e n t f o re x a m p l e ， i tc a n b ea s s o c i a t e dw i t ht e s ts c r i p t i nt h a tc a s e ，i tc a ng e tt h er e s u l t a u t o m a t i c i n t e g r a t i n ga u t o m a t i cr e g r e s s i o nt e s ts y s t e mw i t ha u t o m a t i o n i i i 北京工业大学工学硕士学位论文 t e s ts y s t e mi st h ew o r kn e e dt ob ed o n e k e y w o r d sa u t o m a t i cr e g r e s s i o nt e s t ：t e s tm o d e l ：t e s ts t r a t e g y i v 独创性声明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研 究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他 人已经发表或撰写过的研究成果，也不包含为获得北京工业大学或其它教育机构 的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均 已在论文中作了明确的说明并表示了谢意。 关于论文使用授权的说明 本人完全了解北京工业大学有关保留、使用学位论文的规定，即：学校有权 保留送交论文的复印件，允许论文被查阅和借阅；学校可以公布论文的全部或部 分内容，可以采用影印、缩印或其他复制手段保存论文。 ( 保密的论文在解密后应遵守此规定) 签名：导师签名： e t 期：独宝：笸：兰期：幽益：臣：兰 第1 章绪论 i 一一! i ! 詈! ! ! 詈! ! 詈暑! ! ! ! ! 毫! ! 詈曼! 曼! 詈! ! ! 詈! 皇曼! ! ! ! 暑! ! ! ! ! 詈篁 第1 章绪论 1 1 课题背景和研究意义 随着计算机应用领域的不断扩大，软件功能越来越强大，规模也日趋复杂。 因此，保证软件质量，提高软件可靠性成为软件开发中的重要环节，是决定软件 成败的关键。 在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件 带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集 成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管 理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够 透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身， 从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生 新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候， 除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影 响。因此，每当软件发生变化时，必须重新测试现有的功能，以便确定修改是否 达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新 的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需 要进行回归测试u 1 。 回归测试在软件生命周期中扮演着重要的角色，因忽视回归测试而造成严重 后果的例子不计其数，导致阿里亚娜5 型火箭发射失败的软件缺陷就是由于复用 的代码没有经过充分的回归测试造成的。 回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很 大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭 代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中， 更是要求每天都进行若干次回归测试。 因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常 有意义的。 1 2 研究现状 目前，软件测试技术已经发展到一定阶段，但是回归测试，尤其是自动回归 北京工业大学工学硕士学位论文 测试技术并不是很完善，也缺少系统完整的测试工具。 1 2 1 回归测试技术及目前存在的问题 提到测试就不能不提到回归测试，不管是单元测试、集成测试、系统测试还 是验收测试，都不是一次性工作，在需求发生变化、增加新的功能、修复b u g 后， 如何保证软件仍然能够正确运行，满足所有的要求? 这就需要回归测试。回归测 试的目的就是确认软件经过一些小的变更或修改后是否仍满足所有的需求。它要 求软件测试过程是可重复的。 虽然回归测试很重要，但是实际执行情况却不尽如人意，其主要原因是目前 的回归测试通常都是手i n 试。其基本流程如下： 测试执行人员 图卜1 手动回归测试流程 f i g u r e1 1 t h ep r o g r e s so fm a n u a lr e g r e s s i o nt e s t 在手工回归测试过程中，存在以下问题 3 ，8 1 3 ： 1 测试过程中，大量精力花在输入数据、执行程序和数据比较上，无法把精力 集中到关键问题上，如提高测试的有效性，编写更多更好的测试用例等。 2 手工测试工作是一件工作量非常大的、重复的、枯燥的工作，容易使测试人 员热情下降，易出错，而且手工操作效率低下。 3 现在的应用系统使用环境比较复杂，通常会运行在不同的操作系统、数据库、 中间件等系统软件上，很难组织这么多业务人员对所有环境进行测试。 4 随着技术进步，迭代开发越来越盛行，这造成测试工作的周期被缩短了，测 试的频率被增加了。在这种情况下，传统的手i n 试已经严重的满足不了软 件开发的需求。 5 参与测试的业务人员不足，无法保证充分的测试，而且采用的是临时准备的、 2 员人早入镪试测 员 早人姒 业 第1 章绪论 随机的测试用例和数据，效果不好，很难发现逻辑错误，也无法重复。 6 系统投入生产后，紧急版本修复需要发放补丁时，往往没有时间做回归测试。 图1 - 2 手动回归测试存在的主要问题 f i g u r e1 2t h ep r o b l e mo fm a n u a lr e g r e s s i o nt e s t 1 2 2 回归测试的实施 在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的 测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成 的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归测试。通 过测试自动化可以提高回归测试效率。为了支持多种回归测试策略，自动测试工 具应该是通用的和灵活的，以便满足达到不同回归测试目标的要求。 在测试软件时，应用多种测试技术是常见的。当测试一个修改了的软件时， 测试者也可能希望采用多于一种回归测试策略来增加对修改软件的信心。不同的 测试者可能会依据自己的经验和判断选择不同的回归测试技术和策略。 回归测试并不减少对系统新功能和特征的测试需求，回归测试包应包括新功 能和特征的测试。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试 用例使覆盖率达到规定的要求。 回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效 率，在实际工作中可以采用一些策略减轻这些问题。例如，安排新的测试者完成 手工回归测试，分配更有经验的测试者开发新的测试用例，编写和调试自动测试 脚本，做一些探索性的测试口7 1 。还可以在不影响测试目标的情况下，鼓励测试者 创造性地执行测试用例，变化的输入、按键和配置能够有助于激励测试者又能揭 3 北京工业大学工学硕士学位论文 示新的错误。 1 2 3 回归测试的工具 目前，测试工具主要针对黑盒测试、白盒测试、性能测试等领域，对于回归 测试并没有完整独立的测试工具嘲1 。 由于回归测试贯穿于软件开发的每个环节，包括的测试种类多样，如果全部 通过现有的测试工具来实现，则测试工具必须根据测试任务、测试环境等要求进 行统一配置，使几种测试工具协同工作也不是一件容易的事情。而且，由于一般 测试工具价格高昂，如果将所有可能用到的工具都纳入预算，可能使项目失去经 济可行性。 回归测试的自动化不是容易实现的，需要大量的努力。此外，仅有测试工具 不能成功地使回归测试过程自动化，回归测试的自动化需要建立在一个良好的测 试过程之上。建立一个良好的自动化环境是需要花费时间的，在运行测试的几次 跌代之后才会收到成效。 因此，针对自动回归测试的需求和测试流程的管理相结合，开发一个自动回 归测试管理工具，将整个回归测试过程整合在一起。 1 3 研究目的和创新点 1 对现有的测试模型进行分析，针对其中不完善的地方提出新的测试模型，使 软件测试过程分布到软件开发的各个周期中，实现软件开发过程灵活地实现 回溯。 2 对回归测试策略进行研究，尤其是再测试修改的部分时，对测试用例的选取 方法进行研究并实现其算法。 3 对测试用例库进行管理和维护。 4 研究回归测试流程，并可根据测试计划自动选取测试用例。 5 可以收集并管理测试结果。 6 实现自动回归测试系统，并将其应用于实际的软件测试中。 1 4 论文组织结构 本论文分为五章。 第一章为绪论部分，介绍课题的研究背景和意义，以及该领域的研究现状。 此外，对回归测试技术目前存在的问题进行分析，提出本课题研究的创新点。最 4 第1 章绪论 后介绍论文的组织情况。 第二章介绍了软件测试的相关内容。对软件测试的主要阶段进行介绍，包括 单元测试、集成测试、系统测试和回归测试。对于软件测试的核心过程进行研究， 从计划、准备，到执行和完善。重点论述了自动回归测试的相关内容，为后面讨 论自动回归测试技术奠定基础。 第三章讨论了自动回归测试系统的设计，主要是核心技术的研究和系统的模 块设计。研究v 、x 测试模型的不足，并加以改进，提出新的测试模型。然后就 回归测试所涉及的内容和它们之间的结构关系进行研究。此外，对四种回归测试 策略进行比较，并就“再测试修改的部分 这一策略进行深入研究，得出算法， 使其能够自动选取回归测试用例。最后，针对自动回归测试系统的三大部分 测试用例库的管理、自动回归流程、测试结果的收集，进行详细的规划和设计， 搭建系统的整体框架。 第四章实现了自动回归测试系统，主要介绍了测试用例库的管理、自动回归 流程的控制和测试结果的收集这三大方面具体是如何实现的，并应用了第三章提 出的测试策略，实现了该算法。 第五章将自动回归测试系统应用于实际项目中，管理测试用例，控制回归测 试流程，并自动选取测试用例。最后将测试结果进行收集汇总。 北京工业大学工学硕士学位论文 2 1 软件测试的阶段 第2 章软件测试 软件测试是以发现软件的缺陷为目的而运行或分析软件的过程晗1 。软件测试 主要有以下五个阶段：单元测试、集成测试、系统测试、验收测试和回归测试h 1 。 1 单元测试 单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等 等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验 软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言 的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流 测试、数据流测试、排错测试、分域测试等等h 们。 对于单元测试掌握的总体原则就是：来源( 数据或消息) 永远都是对的，并 且格式等特征都像预期的那样啪1 。也就是来源不是测试范围，即使它和预期不一 样，不进行异常处理也不是错的。因为如果都严格的按照单元测试的要求进行， 来源一定是和预期是一样的包括格式，而只测可预见到的。 2 集成测试 集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单 位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合 成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部 分是否合拍。集成测试的策略主要有自顶向下和自底向上两种乜。 集成测试是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的 单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指 多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合 成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其 他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序 由多个进程组成，应该成对测试它们，而不是同时测试所有进程。 3 系统测试 系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正 确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一 项简单的任务，它被称为测试的“先知者问题 。因此，系统测试应该按照测试 计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。 4 验收测试 6 第2 苹软件测试 验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试 数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统 的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前 的最后测试哺3 。 经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接 口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测 试的任务，即软件的功能和性能如同用户所合理期待的那样。 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件 测试的最后一步验收测试即可开始。验收测试应检查软件能否按合同要求进 行工作，即是否满足软件需求说明书中的确认标准。 5 回归测试 回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检 验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修 改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响 软件的其他功能的正确性。 回归测试可以就一套已经安装好并且在运行的服务器进行测试，也可以就临 时安装的服务器进行测试。详细些说，有“并行 和“串行 运行测试之分。串 行模式顺序运行每个测试，而并行模式激活多个服务器进程，并行地运行一组测 试。由于历史原因，串行测试通常对一个现存的安装进行测试，而并行测试是“独 立 的，不过这么做没有什么技术原因。 每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改 变。新的数据流路径建立起来，新的i o 操作可能也会出现，还有可能激活了新 的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试 策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一 遍，以保证上述改变不会传播无法预料的副作用嫡1 。 在更广的环境里，( 任何种类的) 成功测试结果都是发现错误，而错误是要 被修改的，每当软件被修改的时候，软件配置的某些方面( 程序、文档、或者数 据) 也被修改了，回归测试就是用来保证( 由于测试或者其他原因的) 改动不会 带来不可预料的行为或者另外的错误。 回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以 使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测 试用例，然后就可以进行回放和比较。回归测试集( 要进行的测试的子集) 包括 三种不同类型的测试用例 1 4 1 8 ： ( 1 ) 能够测试软件的所有功能的代表性测试用例。 ( 2 ) 专门针对可能会被修改影响的软件功能的附加测试。 ( 3 ) 针对修改过的软件成分的测试。 7 北京工业大学工学硕士学位论文 在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试 应当设计为只包括那些涉及在主要的软件功能中出现的一个或多个错误类的那 些测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不 实际的而且效率很低的。 2 2 软件测试过程 一个成功的测试在于拥有一个成功的过程。按照时间先后顺序描述这些过 程，首先计划测试活动，其次准备测试，在这之后开始执行测试。最后，对系统 测试和测试活动本身进行完善。 1 计划 软件测试是有计划、有组织和有系统的软件质量保证活动，而不是随意地、 松散地、杂乱地实施过程。为了规范软件测试内容、方法和过程，在对软件进行 测试之前，必须创建测试计划。 软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、 测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等 内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明 确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度， 应对测试过程中的各种变更 2 2 2 4 。 2 准备 软件测试的准备工作主要研究下面这些过程n 盯： ( 1 ) 通过人员配备和培训，创建一个由具备合适的技能、态度和动机的专业测 试人员组成的测试组； ( 2 ) 设计、开发、采购、验证和确认测试系统( 测试用例、测试数据、测试工 具、测试环境、测试实施过程等) 。测试组利用这个测试系统来评估待测系统的 质量。 3 执行 虽然有效的测试计划是指导测试用例设计、测试执行的指导性文件，是成功 测试的前提和必要条件，测试用例设计是测试工作的核心，测试用例的成功设 计已经完成了一半的测试任务，但是测试的执行是基础，是测试计划和测试用例 实现的基础，严格的测试执行使测试工作不会半途而废。而且，测试执行的管理 相对复杂些，在整个测试执行阶段中，需要面对一系列问题，为了得到一个真实、 符合要求的执行过程，需要很好地全程跟踪测试过程、过程度量和评审、借助有 效的测试管理系统等来实现。 4 完善 第2 章软件测试 软件测试的完善阶段主要讨论如下的剩余过程 3 3 ，3 4 】： ( 1 ) 记录测试执行过程中发现的错误； ( 2 ) 向关键涉众通报测试结果： ( 3 ) 根据项目环境中的变化进行调整，优化测试过程。 2 3 自动回归测试 2 3 1 自动回归测试的目的 在每一个系统的开发阶段，都会有专门的测试团队和测试阶段。但是，没有 哪个项目和机构能够长期维持住这样庞大的测试团队、忍受那样长期的测试时 间。尤其是软件开发后期，几乎所有功能都已经开发完毕，某一个模块的修改， 不可能花费如此巨大的精力，将所有的功能测试一遍。在软件投产之后，每一次 变动、故障维护，任务都很紧迫，更加不可能重新执行开发阶段成百上千个测试 案例。 要解决这个问题，需要采用最新的技术自动回归测试技术。 回归测试是软件质量保障的正确方法，问题是人工回归测试巨大的代价。而 自动测试技术，使自动回归测试成为可能。通过构件化的自动测试框架、先进的 自动测试工具，可以建设一个包含成百上千个测试用例的自动回归测试系统口引。 每一次软件的变动，在从开发环境发布到生产环境之前，必须先经过自动回 归测试系统的检验自动回归测试系统如同一群不知疲倦的测试团队，在几个 小时内完成成百上千个测试用例，给出测试报告。只有变动的版本通过了“考 验 ，发布上线才是稳健之举啪1 。 2 3 2 自动回归测试的特点 1 易维护性汹1 采用构件化脚本技术，有效封装测试脚本，将脚本的维护量降到最低。 2 业务驱动 可以根据业务测试构件，配合测试数据，快速完成一个业务流的自动测试。 3 高效的测试数据管理 测试数据完全与脚本分离，集中管理，可由业务人员进行配置。 4 提供先进的自动测试框架 提供自动测试框架，极大减少投入成本。 9 2 3 3 自动回归测试的内容 图2 - 1 自动回归测试的内容 f i g u r e2 - 1t h ec o n t e n to fa u t o m a t i cr e g r e s s i o nt e s t 自动回归测试是在回归测试的基础上，提取出可自动化的部分。首先，测试 计划需要手动设计。然后自动地构建测试任务，并选取测试用例。在测试执行阶 段，可依据已有的自动化测试脚本，或手动进行测试。最后，对于测试结果可以 进行自动分析，并形成测试评估和报告口钔。 2 3 4 自动回归测试的缺点 事物总是具有两面性，同样回归测试过程自动化也有不足 2 6 ，3 0 。 1 实现回归测试自动化，并把测试用例集成到自动化框架或者工具的过程就需 要花费许多额外的时间； 2 其二，测试过程的自动化也可能会隐藏一些软件的错误。例如下列情况不适 于自动回归测试：测试依赖手工交互，如加载磁盘；只打算运行一次涉及到为 数不多测试用例的回归测试( 成本不划算) ：测试评估很难通过程序实现，但对 人而言相对简单，如判断输出格式是否易读或者友好。 2 4 本章小结 本章介绍了软件测试的基本概念和主要流程。从单元测试开始，介绍软件测 试的各个阶段。然后简述了软件测试的核心过程计划、准备、执行、完善， 1 0 第2 章软件测试 这也同样适用于回归测试流程。本章的重点围绕自动回归测试的相关内容进行介 绍，包括自动回归测试的目的、特点、内容和缺点，为下一章讨论自动回归测试 的相关技术奠定基础。 北京工业大学工学硕士学位论文 第3 章自动回归测试系统设计 本章对自动回归测试系统中需要的关键技术进行研究和探讨。为设计自动回 归测试系统奠定基础。 首先，需要构建回归测试模型。在已有的测试模型基础上，改进其不足之处， 建立更为合理完善的回归测试模型。 对于回归测试中涉及的内容，包括测试计划、测试用例等，以及它们之间的 关系进行研究，构建关系模型。 另外，在回归测试中一个重要的技术是回归测试策略的选取。不仅要从理论 上研究，还要从实际出发，探讨策略实现的算法。 在回归测试中，完整的测试用例库是必不可少的。它是实现回归测试的前提。 因此，对于回归测试用例库的管理成为回归测试系统中必不可少的内容。 另外，自动回归测试的过程控制技术也是本章探讨的主要内容之一。最后， 给出对测试结果的分析处理方案。 3 1 测试模型的改进 软件测试模型是为了描述软件开发和测试之间的关系，而设计的。目前主要 以v 和x 模型为主。 3 1 1v 模型 v 模型是最具有代表性的测试模型。v 模型最早是由p a u lr o o k 在2 0 世纪 8 0 年代后期提出的，v 模型在英国国家计算中心文献中发布，旨在改进软件开发 的效率和效果 3 6 , - - , 3 8 。 在传统的开发模型中，比如瀑布模型，通常把测试过程作为在需求分析、概 要设计、详细设计和编码全部完成之后的一个阶段，尽管有时测试工作会占用整 个项目周期一半的时间，但是有人仍认为测试只是一个收尾工作，而不是主要的 工程。v 模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关 系，从左到右，描述了基本的开发过程和测试行为，明确地标明了测试工程中存 在的不同级别，清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 1 2 第3 章自动回归测试系统设计 图3 一l 软件测试v 模型 f i g u r e3 - 1vm o d e lo fs o f t w a r et e s t 模型图中箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应 的是右边上升的部分，即测试过程的各个阶段。 v 模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了 源代码的正确性，高层测试是为了使整个系统满足用户的需求。 v 模型的缺点是它把系统开发过程划分为具有固定边界的不同阶段，这使得 人们很难跨过这些边界来采集测试所需要的信息。有些测试应该执行得更早些， 有些测试则需要延后进行。而且，它也阻碍了从系统描述的不同阶段中取得信息 进行综合。 3 1 2x 模型 x 模型的基本思想是由m a r i c k 提出的b 引，但首先是m a r i c k 不建议要建立一 个替代模型。r o b i nf g o l d s m i t h 引用了些m a r i c k 的想法，并重新经过组织， 形成了“x 模型 。 m a r i c k 对v 模型的最主要批评是v 模型无法引导项目的全部过程。他认为 一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文 档的缺乏等等。 北京工业大学工学硕士学位论文 图3 2 软件测试x 模型u 训 f i g u r e3 - 2xm o d e lo fs o f t w a r et e s t n 9 1 一个模型不应该规定那些和当前所公认的实践不一致的行为。x 模型的左边 描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的 交接，通过集成最终合成为可执行的程序。( 右上半部分) ，这些可执行程序还需 要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更 大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。 由上图中可见，x 模型还定位了探索性测试( 右下方) 。这是不进行事先计 划的特殊类型的测试，诸如“这么测一下结果会怎么样? ”，这一方式往往能帮 助有经验的测试人员在测试计划之外发现更多的软件错误。 x 模型的缺点在于：没有在同一开发周期中使得测试工作和开发工作得以并 发进行。 3 1 3 改进的测试模型 由于v 和x 测试模型存在着缺陷，所以需要设计一种更为完善的测试模型， 使得回归测试贯穿到同一开发周期的各个阶段。 1 4 第3 章自动回归测试系统设计 图3 - 3 改进的测试模型 f i g u r e3 - 3 t h ei m p r o v e dm o d e lo ft e s t 改进的测试模型的设计原则是：测试用例尽早开发，回归测试尽早开始。这 种模型吸取了v 和x 模型的优点，将整个测试同软件开发各个生命周期紧密地融 合在一起，使得在任何开发周期内开发过程和测试过程可以并发进行。 在测试开始之前，首先需要根据需求设计系统测试用例。在用户需求逐步明 确，最终形成用户需求说明书这段时间内，开始设计功能测试用例。在进入概要 设计阶段后，测试人员逐步停止设计系统测试用例，根据需求说明书和概要设计 文档开始设计集成测试用例。设计活动一直持续到详细设计进行了一半左右，逐 步停止，并将设计重点转到设计单元测试用例。进入编码阶段后，实现并执行单 元测试用例，并且在测试阶段还应根据需要生成新的测试用例进行编码阶段内部 的回归测试之用。其实根据x p 编程思想，单元测试用例的设计工作可以在编码 阶段之前就行，在这里只是表示大多数设计单元测试用例的情况。对已经可集成 的模块进行集成测试。集成测试完成3 4 左右后，集成好的功能模块就比较稳定 了，这时可开始进行功能测试。在编码阶段后期进行系统测试。最后在编码阶段 结束时完成单元测试和集成测试，继续功能测试和系统测试，直到软件质量达到 需求的基本要求或者当前基线版本的要求。这里真正实现了测试工作和开发工作 并发进行。通过该模型，使不同的测试用例对应于不同的测试阶段，并根据软件 开发的需要做相应的修改和调整。 软件开发过程的各种回溯动作，都会反映到回归测试过程中，测试工作和开 北京工业大学工学硕士学位论文 发工作永远是“配套 并发进行的。这里使得测试工作可以灵活地适应开发阶段 所客观存在着的回溯过程，从而将复杂的回归测试过程简单化。 此外，在该测试模型中，测试计划的生成工作依赖于测试大纲，具体测试任 务的生成又依赖于测试计划。在需求设计将要成形时，开始根据需求编写测试大 纲和生成部分测试计划，用来进行系统测试。进入概要设计阶段后，抽取概要设 计的信息完善测试大纲和进行较为详细的测试计划的编写，用来进行功能测试。 在开发过程进入详细设计时，生成更为详尽的测试计划，用来进行集成测试。大 部分的单元测试测试用例的编写工作在编码工作开始后立即进行，部分单元测试 可以在条件具备的情况的下在编码工作之前进行。 综上，改进的测试模型的优点是需求基本确定之后就可以开始测试工作。在 同一开发周期内，开发工作和测试工作可以同时进行。 3 2 自动回归测试的关系结构 在回归测试中，主要涉及以下内容：测试大纲、测试用例、被测试类、测试 任务、测试计划、测试结果。它们分别位于用例管理、过程管理和结果收集这三 个模块中。它们之间的关系如图3 - 4 所示。 图3 4 回归测试的关系结构 f i g u r e3 - 4t h ea r c h i t e c t u r eo fr e g r e s s i o nt e s t 首先，介绍各组件的定义和作用。测试大纲是在软件测试的开始阶段，用于 规定测试的内容和项目，使软件测试的依据。一般来讲，由一位对整个系统设计 熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合 理的测试用例，以便系统实现后进行全面测试。 在需求确定之后，就可以生成测试大纲了，测试大纲也是验证需求是否完整 的方式之一。不完整的需求往往导致不完整的实现。因此，可以通过编写测试大 纲来验证需求的可测试性，尽早发现问题。另外，测试大纲使得需求之间的关系 1 6 第3 章自动匣i 归测试系统设计 目了然。因此，在编写测试大纲时，测试人员必须研究需求的变化对其他部分 产生的影响。 由于测试大纲反映了需求之间的联系，因此，需要以一种适当的方式组织。 这样，有利于维护需求。一旦需求发生变更，可以通过更改测试大纲项来反映这 种变化。因此，为了有效地组织测试大纲项之间的关系，采用树形结构来表示。 例如，图3 - 5 为测试大纲的组织示意图。 图3 - 5 测试大纲的树形结构不例 f i g u r e3 - 5e x a m p l eo ft h et r e ev i e wo ft e s to u t l i n e 该示例中每个叶结点编号代表一个测试项目，对应一个测试用例。这样的组 织结构就建立起需求和测试之间的桥梁。如果需求发生变化，直接改变对应的测 试用例项目即可。另外，测试大纲还要包括用例的输入、输出和验证结果，以指 导测试用例的编写。 测试用例是执行一次测试的具体内容，包括输入、输出、测试步骤和测试结 果的描述等。测试用例是对测试大纲的进一步细化。测试用例包括手动和自动的 测试，严格按照测试大纲的规定，描述测试的步骤，并且包括各个验证点。 被测类是指程序中使用到的具体类，主要根据u m l 类图来识别这些类。某一 具体的类可能与其他类有关联关系，因此，当某一类修改之后，在回归测试的时 候需要把相关的类一起进行回归测试，也就是把相关类所涉及到的测试用例取 出，进行回归测试。因为当前类的修改可能导致相关类的状态改变。 测试结果是针对测试用例而言的。每个测试用例在一次回归测试中都对应唯 一的测试结果。测试结果包含的信息主要是测试的成败，以及失败的原因。测试 结果主要分为正确性测试和非正确性测试。正确性测试主要针对功能性测试，给 出成功或者失败的结论。非正确性测试需要对测试结果进行分析，例如对程序进 行稳定性分析。 测试计划主要是针对回归测试而言的。在回归测试时，需要对哪些功能进行 测试，这是首先需要考虑的问题，也就是测试计划中的主要内容。其中，也包括 了需要采用何种测试策略等问题。 测试任务是对测试计划的进一步细化。有了测试计划，还需要根据一次回归 1 7 北京工业大学工学坝士学位论文 i i 测试相关的信息进行设置，例如环境信息等。在此基础上，再根据测试策略去关 联相应的测试用例。 在用例管理中，涉及的组件主要有测试大纲、测试用例和被测类。在过程管 理中，主要从测试计划开始，形成测试任务，最后关联测试用例。对于结果收集 模块，主要涉及测试用例和测试结果。由此可见，测试用例是关联各组件的桥梁， 是整个回归测试中最重要的部分。 3 3 自动回归测试策略 对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发 的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件 的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在 需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例 库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测 试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试 用例的手工实现过程。 回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和 进度下，尽可能有效率和有效力地进行回归测试，需要对测试用例库进行维护并 依据一定的策略选择相应的回归测试包。 在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当 大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归 测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，有时 测试组不得不选择一个缩减的回归测试包来完成回归测试。 回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选 择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回 归错误的机会。然而，如果采用了代码相依性分析等安全的缩减技术，就可以决 定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。 3 3 1 回归测试方案 选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的 方式包括m ： 1 再测试全部用例 选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全 的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全 第3 章自动回归测试系统设计 部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是， 随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工 作量，往往超出了预算和进度。 2 基于风险选择测试 可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行 最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳 定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或 四级。一般而言，测试从主要特征到次要特征。 3 基于操作剖面选择测试 如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分 布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试 预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用 例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故 障。这种方法可以在一个给定的预算下最有效的提高系统可靠性。 4 再测试