（计算机应用技术专业论文）基于规则引擎的测试用例提取与维护方法研究.pdf

摘要 基于规则引擎的测试用例提取与维护方法研究 作者简介：孙晓飞，男，19 8 1 年6 月出生，20 0 5 年9 月师从于成都理工 大学罗省贤教授，于20 0 8 年7 月获硕士学位。 摘要 软件测试是保证软件质量和可靠性的主要手段，软件测试的工作量一般占 软件总开发量的4 0 至6 0 ，而测试工作中有很大部分适于采用自动化测 试方法。自动化测试可以提高测试过程的系统性和计划性，大规模地提高测试 效率，减少测试开销，并有利于进行回归测试。 本论文以成都理工大学d n c p c 实验室与企业合作的项目为依托，重点研 究了测试用例规则模型、交易参数模型、测试用例加载、用例集优化、测试要 素管理、基准数据管理，通过交易参数模型和测试用例规则模型把规则全部显 式地表达出来，使规则匹配的完整性和一致性得到很大提高，在此基础上提出 了由规则模型产生测试点以及提取测试点相关的测试用例集的方法；应用了配 对算法来优化用例集，使用例数可降低好几个量级。在以上基础上研究了基于 规则引擎的软件测试用例提取与维护技术。 本文讨论了基于规则引擎的测试用例提取和维护的基本理论和相关概念， 研究了当前流行的基于j 2 e e 的轻量级框架和规则引擎，设计了一套基于 f l e x + s p r i n g + d r o o l s + h i b e m a t e 的测试用例提取系统的体系架构。这种架构在 设计上充分体现了分层的思想。整个系统分为呈现层、业务层和持久层，显著 提高了系统的可扩展性和可维护性。 本文在以上研究的基础上用规则引擎技术设计与实现了基于规则引擎的 测试用例提取与维护系统，本系统能显著提高测试用例的可维护性和可复用 性，所采用的技术框架能显著提高业务规则复杂的软件测试自动化程序的开发 效率。实践证明将规则引擎应用于测试用例的提取对测试自动化具有重要的指 导意义和实用价值。 关键词：软件测试规则引擎交易要素用例提取用例维护 成都理ji ：人学硕+ 学位论文 r e s e a r c ho nt h er u l ee n g i n e b a s e dt e s tc a s e se x t r a c t i o n a n dm a i n t e n a n c e i n t r o d u c t i o no ft h ea u t h o r ：s u nx i a o f c i ，m a l e ，w a sb o r ni nj u n e ，19 81w h o s e t u t o rw a sp r o f e s s o rl u os h e n g x i a n h eg r a d u a t e df r o mc h e n g d uu n i v e r s i t yo f t e c h n o l o g yi nc o m p u t e ra p p l i c a t i o nt e c h n o l o g ym a j o ra n dw a sg r a n t e dt h e m a s t e rd e g r e ei nj u n e ，2 0 0 8 a b s t r a c t s o f t w a r et e s t i n gi st oe n s u r et h a ts o f t w a r eq u a l i t ya n dr e l i a b i l i t yo ft h em a j o r m e a n so fs o f t w a r et e s t i n gt h ew o r k l o a do ft h eg e n e r a ld e v e l o p m e n to fs o f t w a r ef o r t h e4 0t o6 0p e r c e n t ，w h i l et h et e s t sa r ev e r ys u i t a b l ef o rt h em a j o r i t yo ft h eu s eo f a u t o m a t e dt e s t i n gm e t h o d s a u t o m a t e dt e s tc a ni m p r o v et h et e s t i n gp r o c e s so f s y s t e m a t i ca n dp l a n n e d ， l a r g e s c a l et e s t i n gt oi m p r o v ee f n c i e n c ya n dr e d u c e t e s t i n gc o s t s ，a n di sc o n d u c i v et or e g r e s s i o nt e s t i n g t h i sp a p e rd i s c u s s e st h er u l e s b a s e de n g i n et e s tc a s ee x t r a c ta n d p r e s e r v et h e b a s i ct h e o r ya n dr e l a t e dc o n c e p t s ，t h es t u d yo ft h ec u r r e n tp o p u l a rj 2 e e b a s e d l i 曲t w e i 曲tf r a m e w o r ka n dr u l e se n g i n e ，a n dd e s i g na na r c h i t e c t u r eb a s e do nf l e x + s p r i n g + d r o o l s + h i b e r n a t e t h i sa r c h i t e c t u r ed e s i g n e dt of u l l yr e n e c tt h e h i e r a r c h i c a lt h i n k i n g t h el a y e r e ds t r u c t u r eo ft h es y s t e ms i g n i f i c a n t l yi m p r o v et h e s y s t e ms c a l a b i l i t ya n dm a i n t a i n a b i l i t y at e s tc a s em o d e lr u l e s ，t h et r a n s a c t i o np a r a m e t e rm o d e l ，t h et e s tc a s ef o rt h e a c h i e v e m e n ta n dm a i n t e n a n c eo fe x t r a c t i o np r o v i d eas o l i dt h e o r e t i c a lf o u n d a t i o n ar u l e b a s e de n g i n et e s tc a s ee x t r a c t i o na n dm a i n t e n a n c eo fs o f t w a r et e c h n o l o g y a n da p p l i c a t i o n su s i n gj a v aa n dr e t ea l g o r i t h mr u l e se n g i n et e c h n o l o g yd e s i g na n d t r a i n i n go ft h er u l e - b a s e de n g i n et e s tc a s ee x t r a c t i o na n dn l a i n t e n a n c e a p p l i c a t i o n o ft h er u l e se n g i n et e c h n o l o g y ，s i g n i f i c a n t l yi n l p r o v et h em a i n t a i n a b i l i t yo ft h et e s t c a s ea n dr e u s a b i l i t y ，a n do t h e ra s p e c t so fd w a r f s a tt h es a m et i m et h ei n t r o d u c t i o n o fm l e se n g i n e s ，a n dc a ns i g n m c a n t l yi m p r o v et h eb u s i n e s sr u l e sf o rb e t t e r s o f t w a r ea u t o m a t i c a l l yg e n e r a t e dt e s tc a s ea p p l i c a t i o nd e v e l o p m e n te 伍c i e n c y p r a c t i c eh a sp r o v e dt h a tt h i sp a p e rw i l lp r o p o s et h er u l e se n g i n et e s tc a s ef 0 rt h e e x t r a c t i o no fa u t o m a t e dt e s t i n go fm a jo rg u i d i n gs i g n i f i c a n c ea n d p r a c t i c a lv a l u e k e yw o r d s ：s o r w a r et e s t i n g ，r u l e se n g i n e ， t r a n s a c t i o n se l e m e n t s ， t e s tc a s e s e x t r a c t i o n ，t e s tc a s e sm a i n t e n a n c e n 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的 研究成果。据我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其 他人已经发表或撰写过的研究成果，也不包含为获得盛都堡王太堂或其他教 育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何 贡献均已在论文中作了明确的说明并表示谢意。 学位论文作者签名：孙砣酞飞 训矿墨年岁月g 日 学位论文版权使用授权书 本学位论文作者完全了解邀都理王太堂有关保留、使用学位论文的规定， 有权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅和 借阅。本人授权盛壑堡王盔堂可以将学位论文的全部或部分内容编入有关数 据库进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文作者签名：孙噬飞 学位论文作者导师签名： 丫省赁 训童年 歹 月 二8 日 第l 章引言 1 1 选题依据 第1 章引言 1 1 1 测试用例提取及维护的意义 软件测试就是在软件交付用户使用或投入运行前，对软件需求规格说明、设 计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是为了发 现错误而执行程序的过程。软件测试在软件生命周期中横跨两个阶段：通常在编 写出每一个模块之后就需要对它做必要的测试( 称为单元测试) 。编码和单元测 试属于软件生命周期中的同一个阶段。在结束这个阶段后对软件系统还要进行各 种综合测试，如集成测试、系统测试、性能测试和配置测试等，这是软件生命周 期的另一个独立阶段，即测试阶段【l 】。 软件测试的工作量一般要占软件总开发时间的4 0 6 0 ，而测试中又有 很大部分适于自动化。自动化测试能够提高测试过程的系统性和计划性，大规模 提高测试效率，减少测试开销，有利于进行回归测试。测试用例的自动生成是软 件自动化测试的前提与关键。 软件测试是保证软件质量和可靠性的主要手段，测试用例的生成是其关键和 难点。目前，测试用例的生成主要依靠测试人员的直觉和经验手工完成，测试成 本高昂，测试效率低下。开发一些实用的测试数据自动生成工具，实现软件测试 的自动化，有着十分重要的现实意义。 开发一个软件产品，会发布多个版本，并伴随着测试用例( t e s tc 嬲e ) 的不 断维护，使测试用例不断完善并与产品功能、特性( f e a t u r e s ) 的变化保持一致，所 以测试用例是和产品版本相关联的。特别是对提供软件服务的软件产品，多个版 本常常共存，为客户提供服务，这时多个版本的测试用例也是并存的，所以在新 建、修改、删除测试用例时要十分小心，并有相应的规则。【2 】 1 1 2 规则引擎在用例提取及维护中的应用 d r o o l s 是一个基于c h 砌e sf o r g y s 的r e t e 算法并专为j a v a 语言所设计的规 则引擎。r e t e 算法应用于面向对象的接口，使基于商业对象的商业规则的表达更 为自然。 对于测试用例的维护和自动生成，需要实现的逻辑的复杂程度难以想象，用 面向过程的i f t h e n 表达式是绝对无法胜任的，做出来的系统也是无法维护的。 而规则引擎恰恰可以很好的担当这一重任。对于业务规则复杂繁多的软件测试用 成都理ji ：人学硕+ 学位论文 例自动生成应用程序，也能较好地提高开发效率。 1 2 论文研究内容 1 2 1 论文研究内容 测试用例提取：每次回归测试将会涉及到测试用例的重用问题，其中一个重 要的问题是用例集的优化，或用例集的简约，即应用一种生成最小测试用例集的 方法，首先充分考虑测试目标中各个测试需求之间的相互关系，将满足测试需求 的所有可用测试用例进行划分，根据划分的结果生成一个测试用例集，然后利用 配对算法来消除冗余，对这个测试用例集进行进一步的简化。应用用例集优化技 术具有巨大的优势，它可以生成满足所有测试需求的最小测试用例集【3 j 。 在测试实践中常常遇到的情况是，有一个系列的多个产品总体上功能相似， 界面上也有很多相似，实际上新产品是不断在前一个产品基础上经过增删功能、 重新构思部分界面形成的。因此，需要建立一个统一的用例规则库对大量用例加 以管理，以实现用例的重用并提高用例管理的效率。例如当有公共模块被修改时， 受影响的用例可以在用例规则库中一次修改完成，并在使用用例时能够方便地检 索到指定产品和指定功能的用例。本课题的研究目标是：以现有的测试理论为基 础，利用规则引擎技术，从业务要素和业务流程所遵循的规则出发，建立起一个 统一的用例规则库，并设计和实现一套对用例规则库进行维护管理并提取测试用 例的“测试用例维护与提取系统”。 主要研究内容如下： ( 1 ) 交易参数模型与测试用例规则模型，以及以此为基础的测试用例提取 机制的研究； ( 2 ) 测试用例提取中用例集优化技术的研究，应用相关的简约技术达到提 取最小有效用例集的目的； ( 3 ) 应用规则引擎后测试用例的表达技术研究，交易要素规则的表达技术 研究。测试用例是由交易要素按照一定流程组合而成的，交易要素规则的有序组 合便成为测试用例的业务规则，因此交易要素规则表达技术是应用业务规则引擎 的基础； ( 4 ) 将规则引擎应用到测试用例提取和维护领域的研究； ( 5 ) f l e x + s p 血g + d r o o l s + h i b e m a t e 的整合和架构设计，及应用此架构的平 台的设计与开发。 2 第l 章引言 1 3 相关领域国内研究现状 ( 1 ) 测试用例维护 国内外对于回归测试用例维护技术的研究都还不充分。国内大多企业对测试 用例库的维护和管理处于混乱状态，导致测试用例库不可重用，造成时间与人力 的巨大浪费，严重危及回归测试的成败。 现在最好的用例维护方法是，把版本衍生的详细信息与用例库关联起来。管 理用例库时，除了给每个用例规定编号、版本、产品型号等分类属性，还要给每 个用例规定若干关于功能的关键字，用于用例的检索。要保证的就是按版本、按 型号、按功能的组合能够把相关的用例都找到，不要有遗漏。这种管理、维护的 方式是粗粒度的，维护任务繁重，当项目进展时间稍长，就难以做到对用例库的 有效维护。1 4 j ( 2 ) 用例自动生成 目前国内外对用例自动生成的研究包括：基于啪l 时序图测试用例的自动生 成、基于x y z e 规范的软件测试用例自动生成方法、基于z 路径覆盖的测试 用例自动生成技术、基于形式规约的软件测试用例自动生成技术，这些方法在应 用时都有一定的局限，且难于实施，所以国内的应用很少见。 ( 3 ) 用例提取 在回归测试时，如何在已有的测试用例集中提取最优最小的用例集是一项值 得研究的技术，因为回归测试所需的用例集应最大限度地复用现有用例，国内在 这方面的研究尚属少见。 成都理j l ：人学硕十学位论文 第2 章软件测试与业务规则 2 1 软件测试概况 软件测试是软件开发过程中的一个重要的环节，是保证软件质量和可靠性的 重要手段。在软件开发的过程中，软件开发的每个阶段都有可能产生误解或差错。 因此，要力求通过每个阶段的技术审查、走查、测试实施等能够尽早、尽量地发 现软件中存在的错误并将其排除。软件测试就是在软件投入运行使用之前，对软 件需求分析、设计规格说明、编码实现的最终复审，贯穿于软件定义与开发的整 个期间。 2 1 1 软件测试定义 传统上认为软件测试的方法从总体上分为两类。第一类测试方法是试图验证 软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的； 而第二类测试方法则是设法证明软件是“不工作的。 提出第一类方法的代表人物是软件测试领域的先驱d r b i l lh e t z e l ，他首先在 1 9 7 3 年给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预期 的设想运行。 后来在1 9 8 3 年他又将定义修订为：“评价一个程序和系统的特性 或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。 在他的定义中的“设想”和“预期的结果”，就是用户需求或功能设计【5 j 。 第一类测试可以简单抽象地描述为这样的过程：在设计规定的环境下运行软 件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果 不相符则视为b u g 。这一过程的终极目标是将软件的所有功能在所有设计规定的 环境全部运行并通过。 在软件行业中一般把第一类方法奉为主流和行业标准。1 9 9 0 年的i e e e a n s i 标准将软件测试进行了这样的定义：“就是在既定的状况条件下，运行一个系统， 观察记录结果，并对其某些方面进行评价的过程”。 第二类方法的代表人物是g l e r 曲r dj m y e r s ，他认为测试不应该着眼于验证 软件是工作的，相反应该首先认定软件是有错误的，然后去发现尽可能多的错误。 他还从人的心理学的角度论证，将“验证软件是工作的”作为测试的目的，非常 不利于测试人员发现软件的错误。于是他于1 9 7 9 年提出了他对软件测试的定义： “就是以发现错误为目的而运行程序的过程。”这就是软件测试的第二类方 法，简单地说就是验证软件是“不工作的 ，或者说是有错误的【6 1 。 在此，本文对两种方法进行一个简单的对比。 4 第2 章软件测试与业务规则 虽然软件测试总目的是为了软件产品的质量，但很明显这两类测试方法在具 体目标或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上有很 大的差别，并各有利弊。 第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便 于部署测试的侧重点，加强针对性。而第二类测试方法与需求和设计没有必然的 关联，如果计划管理不当，测试活动很容易丢失重点，走入歧途。 第一类测试方法可以与软件的架构和软件开发的计划相配合，使软件测试活 动逐层次地展开，从而使软件的功能和质量有计划地逐步完善和提高。第二类测 试方法不具备这种过程的渐进性。 第一类测试方法的缺点是缺乏灵活性，不利于测试人员主观能动性的发挥， 正像m y e r s 先生所说，不容易找到软件的缺陷( b u g ) 。而这方面正是第二类测试 方法的长处。 2 1 2 软件测试分类与测试阶段 ( 1 ) 软件测试分类【4 】 软件测试可以从不同的角度进行分类： 根据程序执行的方式，可以将软件测试方法分为人工测试( m a n u a lt e s t i n 曲和 自动化测试( a u t o m a t i ct e s t i n g ) 两类。 根据测试过程中程序的执行状态，可以将软件测试分为静态测试( s t a t i c a j l a l y s i s ) 和动态测试( d y n 锄i ct e s t i n g ) 。静态测试方法是对被测试程序特征分析 的一些方法的总称，其最大的特征是在对程序进行静态分析的过程中不执行被测 程序，如：审查、符号验算及验证。动态测试方法的一个最大的特征就是在测试 的过程中执行被测试源程序，其基本思想是使程序有控制的进行，并从多种角度 观察程序执行时的行为。因此，动态测试必须包括被测程序和用以运行软件的数 据( 称为测试数据) 。 根据测试过程对系统内部结构和具体实现算法细节的关心情况，软件测试方 法可分为黑盒测试和白盒测试。 黑盒测试又称为数据驱动测试( d a ：t ad r i v i n gt e s t i n g ) 或基于规格说明的测试。 黑盒测试是从用户的观点出发的测试，它是从软件需求出发，根据软件需求规格 说明设计测试用例，并按照测试用例的要求运行被测程序的测试方法。黑盒测试 方法主要有等价类划分、边界值分析、因果图、错误推测等。 白盒测试也称为结构测试( s t m c t l j r et e s t i n 曲、逻辑驱动测试( l o g i c a ld r i v i n g t e s t i n g ) 或基于程序的测试( p r o 黟a j t l b a s e dt e s t i n g ) 。采用这种测试方法，测试者 需要掌握被测试程序的内部结构，并根据内部结构构造测试用例。白盒测试需要 运行程序，并能在运行过程中跟踪程序的执行路径【7 j 。 ( 2 ) 软件测试阶段 成都理1 ：人学硕士学位论文 在软件交付周期的不同阶段，通常需要对不同类型的目标应用进行测试。这 些阶段是从测试小的模块( 单元测试) 到测试整个系统( 系统测试) 不断向前发展 的。在软件测试中包括的测试阶段有：单元测试、集成测试、确认测试和系统测 试。 单元测试 单元测试的对象是软件设计的最小单位一模块。单元测试多采用白盒测试技 术，系统内多个模块可以并行地进行测试。 集成测试 集成测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模 块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。 确认测试 确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书 中的确认标准。 系统测试 计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系 统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。系统测试 应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能j 下 常工作并完成所赋予的任务。 2 1 3 软件测试的不确定性 软件测试不确定性主要是指软件测试人员的能力达不到规定的要求，软件测 试的过程失去控制，从而导致软件测试结果的重现性差，不同的测试人员对同一 个软件的测试结果经常是不同的。在软件测试中往往“重操作、轻管理，重结果、 轻过程”，使软件测试的质量得不到保证。j 下如许多软件工程专家所指出的：“软 件发展的主要问题是管理问题，而不是技术问题”。究其原因存在以下4 方面的 情况： ( 1 ) 软件测试立场 软件测试的目的是最大限度地发现软件中存在的错误，而不是为了证明软件 没有错误。软件测试应该站在客户立场采用“攻击”的手法去测试软件，但是有些 企业往往为了争取进入市场的时间而站在开发者立场去表明软件没有错误。 ( 2 ) 软件测试人员素质 软件测试在很大程度上依赖测试人员的个人经验，有经验的测试人员知道： 控件的测试步骤不同产生的结果是不同的；a p i 的测试应该采用程序方式进行； 而g u i 的测试应该采用键盘和鼠标方式进行：中间件和构件的功能和性能必须 放在相应的场景中才能显现等。有不少人认为“做不了开发，就去做测试”，好像 6 第2 章软件测试与业务规则 软件测试比软件开发的要求低得多。由此引发的结果是测试人员素质不高，测试 质量降低，更谈不上对软件测试人员的培训提高了。 ( 3 ) 软件测试过程 软件测试过程与软件开发过程一样，应该进行过程建模。在实际情况中，往 往是软件测试没有一定的流程，如测试没有计划，随机进行。又如测试用例即时 构想，没有事先设计。更谈不上对软件测试过程进行监督了，由此引发的结果是 测试过程失控。 ( 4 ) 软件测试结果 对软件测试的结果，特别是对软件测试中发现的缺陷应该能够重现，为软件 的维护和修改提供依据。一个软件的功能是否正确和性能是否符合要求，是在该 软件采用的开发技术、运行环境和应用场景的三维坐标中显现出来的，软件测试 的结果应该对照软件的需求和软件测试的记录而产生。由于在软件测试过程中缺 少详细的记录，往往使软件测试报告缺乏充分的依据。 2 1 5 解决途径 改进软件过程、提高软件的开发质量一直是软件工程界努力的目标。软件测 试是软件生命周期中的一个子过程，对软件测试过程的规范化问题，越来越受到 软件测试领域专家的重视。软件测试工程化的主要思想是要求建立正式的测试组 织、明确测试的目标和流程、确定测试的活动、对测试的过程和活动进行监控， 从而保证软件测试的质量。软件测试工程化的研究始于1 9 9 6 年，从测试过程的 改进、测试组织测试度、测试评估程序到测试成熟度模型，进行了一系列的研究。 特别是使用软件测试成熟度模型( t m m ) 改进软件测试过程的提出，将软件测试成 熟度模型分为5 级，为软件测试成熟度的评估提供了依据【8 】。 在c m m 体系中间，并没有对测试管理模型作详细的规定，为了弥补这个缺 陷，t m m 将测试划分为五个级别，正好匹配c m m 的五个相应级别，这五个级 别分别是：初始级、定义级、集成级、管理级和优化级，每一个成熟度等级又包 括若干成熟度目标，每个成熟度目标又包含若干成熟度子目标。图2 1 表示t m m 的框架结构。 7 成都理1 ：人学硕士学位论文 衰明 - l 测试能力 成熟度等级 包含 成熟度目标l 弋广得到支持 赢舂司 _ f 。得到完成 亟函 活动，任务责任i 。_ _ - - o o o r o o o 。o - 上由一些观点组成 重要观点 发人员，涮试人员il 用户，客户 图2 1 t m m 框架结构 从图中可以看出，为了达到某一级测试成熟度，子目标定义了软件组织必须 采取的一组措施的界限和范围。进而根据这些措施定义了一组与软件组织的承诺 相联系的活动和任务，并将这些活动和任务以及相应的职责分配给在测试过程中 的主要参与者：管理人员、开发人员与测试人员、用户或客户。职责不同的几种 人员履行各自的责任，通过完成与子目标相关的各种任务和活动达到预定的子目 标。 除初始级外，每个成熟度等级均包含若干要实现的目标。为了达到一个成熟 度等级，就必须满足该等级要求的所有成熟度目标。按成熟度等级排列的成熟度 目标如图2 2 所示。 1竺竺：堡堕竺竺塑堡兰苎竺竺! ! ! 优化测试过程，质量控制，应用过程数据预舫缺陷 管理与测量级( 4 ) 软件质量评价，建立组织范围内的评审程序腱立 控制和监视测试过程，软件全寿命周期测试 制定技术培训规翘l 健立软件测试组织 定义级( 2 ) 嗣度化基本的测试技术和方法，启动测试计划过程 制定测试与调试目标 韧始级( 1 ) 图2 - 2 成熟度等级排列的成熟度目标 8 第2 章软件测试与业务规则 2 2 业务规则 2 2 1 什么是业务规则 业务规则描述在实现一个组织的目标时所应用到的操作、定义和约束。这些 规则用来帮助组织去更好地达成目标，在委托方和代理方内部进行更好的沟通， 以及在组织和有兴趣的第三方之间的更好沟通，更好地示范了法定义务的履行， 操作更有效率，操作更好地自动化，在当前的实践中更好地执行分析，等等。业 务规则可以被看作是业务实践的一个集合，定义实际的实现业务逻辑。这种 逻辑的实现经常可以通过使用专门的工具进行简化业务规则语言和业务规 则引擎。 规则语言是一种特定于领域的语言，包含定义业务规则的构造。这些构造可 以根据业务需求而大相径庭。从文本描述( 使用一种特定于规则的语言或者简单 英语) ，到决策表或者决策树的使用，都有可能。在有些情况下，也可能以图形 的形式确定使用规则流的那些业务规则的执行顺序。最后一种经常是导致业务流 程和业务规则之间产生混淆的原因。虽然它们看起来类似，但是业务流程流定义 的是可以跨许多不同且异构系统的服务的执行顺序。另一方面，业务规则流则受 限于规则执行顺序的编制。 2 2 2 剖析业务规则 业务规则应该如何描述，显然应该有一套标准，而不能凭空想象，下面就业 务规则应该是什么样的内容，进行剖析。若要描述一个业务规则，基本上要包含 业务规则简介、目的、范围、参考资料、概述、定义等等，具体意义如下： ( 1 ) 简介 业务规则的简介应提供整个文档的概述，定义问题领域的专用术语，并解释 用例说明或其他项目文档的读者可能尚不熟悉的术语。 ( 2 ) 目的 阐明此业务规则的目的。 ( 3 ) 范围 简要说明此业务规则文档的范围：它的相关项目，以及受到此文档影响的任 何其他事物。 ( 4 ) 参考资料 完整地列出此业务规则文档中其他部分所引用的任何文档及其来源。每个文 档应标有标题、报告号、日期和发布组织。 ( 5 ) 概述 说明此业务规则文档中其他部分所包含的内容，并解释此文档的组织方式。 9 成都理：l ：人学硕+ 学位论文 ( 6 ) 定义 定义术语并形成整个文档的基础。它们可以按任意顺序定义，但字母顺序通 常最便于查找。 如果分析得当，业务规则几乎可以表示所有的业务逻辑。 2 2 3 业务规则引擎的编程方式 业务规则引擎d r o o l s 采用产生式编程，产生式编程( g e n e r a t i v ep r o g 陷m m i n g ， g p ) 是一种软件工程范型，基础是对系统族建模。产生式编程的目标针对的是 系统族，而不是一个或者一种的系统，它是基于通用的产生式领域模型之上的。 产生式领域模型是由三部分组成的：指定的系统族成员的方法；可以组装出每个 成员的实现组件；成员说明书和一个已有成员的配置知识映射关系。 开发式编程、声明式编程、产生式编程差别如下： 开发式编程是编码的，如：j a v a ，c 群。声明式编程是解析的，如：a n t 。 产生式编程是生成的，如：a o p ( a s p e c t j ) ，d s l ( d r o o l s ) 。开发式编程是聚合 性的，声明式编程是声明性的，产生式编程是组合性的。 产生式和声明式本质的区别在于： ( 1 ) 产生式是自底向上，而声明式是自顶向下。即产生式编程用的思路是 组合概念( 用小粒度的概念组合生成大粒度的概念) ，而声明式编程是解析概念， 用统一的概念来理解，把不同差异性交由具体程序解析。 ( 2 ) 声明式编程的编辑器生成的是x l l l l 文件，将由框架程序解析；而产生 式生成程序代码，不做解析运行。产生式是相对细粒度的，而声明式是粗粒度的。 黄柳青博士曾是中国最早的互联网应用开发商亚信的c t o ，早期他在开发 电信互联网应用的时候，就发现了原来的代码开发模式存在很大的不足，很多精 力经常浪费在底层w e b 技术的代码开发上，而无法集中精力将应用做的更为顺 畅和快速。黄柳青谈中国软件开发情况：“目前，国内传统大型企业应用软件有 两种方式居多：编码式开发方式和一次开发方式。值得注意的是，两种方式都有 致命的缺陷编码式开发方式使得企业级应用软件的快速开发和实施难以实 现；一次性开发持续运行的方式，则导致软件的严重僵化和应用的不适应”。黄 柳青断言，如果在未来三五年内不改变软件的生产方式、运作方式，国内软件产 业必将举步为艰，甚至有全军覆没的可能。 如果代码生成的结果仅仅是结构性的代码，就没有太大价值，因为这种代码 是大都可以用t e m p l a t e 完成的，同时因为这种代码往往不是最终的产物，就存在 同步维护问题。但如果生成的是功能性代码，这类代码是最终执行代码，那么通 常就把用于设计的代码看作是最终产物，最明显的例子是d s l 。 由此可见，使用规则引擎将会使企业集中精力将应用做的更为顺畅和快速， 有助于中国软件业形成个性化而灵活的业内氛围，帮助国内软件企业摆脱黄柳青 i o 第2 章软件测试与业务规则 博士断言的“致命缺陷 。 2 2 4 业务规则引擎的编程语言 首先了解一个概念：g p l ( g e n e r a j p u 印o s el a n g u a g e ，一般用途的语言) 是 指可以用在很多开发领域，没有特定用途的语言。例如：c 、c + + 、j a v a 、c 撑、 r u b y 、p y 廿l o n 都算是g p l 。在适合使用g p l 的地方使用g p l ，当然没问题；但 是在不适合g p l 的地方使用它，事情可能一样可以做得到，只是要花更多精力， 事倍功半，且潜在的问题会更多。 d r o o l s 内置的“特定于领域的编程语言( d s l ) ”是一种对特定的任务组特别 有用的编程语言。这是相对于通用编程语言( g p l ) 如c 、j a v a 、c 稃等等而言的。 d s l 一般专门针对特定的问题领域进行量身定做。因而它能精确地捕捉领域的 语义。为了进一步简化它们的用法，d s l 一般是高度声明式的，并描述需要发 生什么，而不是如何完成( 后者是语言实现者的责任) 。由于这一点，d s l 经常 被当作( 可执行的) 规范，而不是编程语言【9 1 。 特定的d s l 的主要优点在于特定于领域的抽象和符号，以及有限制( 或者 相当集中) 的表达功能。对于应用程序的有些类而言，使得d s l 比g p l 更具吸 引力的原因有几个： ( 1 ) 更容易编程 因为它使用了一个更高级别的抽象，与问题领域密切结合，定义要实现的内 容，而不是如何实现，相比于g p l 实现，d s l 程序一般来说更加精确( 由于它 与领域的密切结合) ，并且更容易实现和理解( 不仅对于开发人员，对于领域专 家们也是如此) 。这一般会致使缩短开发时间，减少昂贵的维护成本。此外，d s l 还有高级的数据处理( d e b a g g i n g ) 支持，允许直接在领域概念级别上分析和调 试代码。 ( 2 ) 系统的重用 重用始终是改善新应用程序的实现和缩短开发周期的方法之一。虽然g p l 通过使用标准的和特定于领域的库来促进重用，但是它们的实际用法还是取决于 开发人员。另一方面，d s l 强制重用被d s l 实现使用的库。此外，由于d s l 是 为特别的问题领域而定义的，因此它们捕捉且因此重用特定的领域知识。 ( 3 ) 更容易验证 随着软件工程的发展，正规的代码验证在成功的开发中正扮演着重要的角 色。而对g p l 而言，这种验证仅仅确保代码会执行，对于d s l 而言，由于它们 的简洁和领域结盟，验证经常可以确保代码将生成正确的结果。 ( 4 ) 增进合作 跨组织使用相同的业务相关的语义，促进了信息的共享，降低了业务逻辑的 成都理i ：人学硕士学位论文 实际实现与业务用户的预期之间不符的风险。 业务规则引擎支持用相应的规则语言表达的规则的评估。它们的主要功能是 管理事实的集合，并评估由几个断言之一组成的规则组。处理大量的事实，并且 有效地评估断言，这是规则评估的主要挑战之一。根据业务规则定义，用业务规 则语言表达，业务规则引擎一般提供一些映射机制来生成更低级别的执行代码 一般是通用的语言类。那些类可以用作一个更大业务组件的部分实现。这种 方法的一种直接的后果是，业务规则的实现生命周期与它们所属的业务组件的生 命周期紧密地结合在一起。 业务规则实现的灵活性和可修改性，通过激活动态变化的规则维护支持而实 现( 使用初始的规则语言) 。这种能力提供了一种动态地修改业务规则的方法， 并且不用重新构建和重新部署实现来快速地适应改变了的业务环境。 产生式的编程代表规则的选择模型：根据规则取值为t m e 还是脚s e ，可以 触发事件或动作。控制流是隐式的，并在规则触发时显现出来。 1 2 第3 章规则引擎及其可用性 3 1 规则引擎 第3 章规则引擎及其可用性 3 1 1 业务规则 业务规则描述在实现一个组织的目标时所应用到的操作、定义和约束。这些 规则用来帮助组织去更好地达成目标，在委托方和代理方内部进行更好的沟通， 以及在组织和有兴趣的第三方之间更好沟通，更好地示范了法定义务的履行，操 作更有效率，操作更好地自动化，在当前的实践中更好地执行分析，等等。业务 规则可以被看作是业务实践的一个集合，定义实际的实现业务逻辑。这种逻 辑的实现经常可以通过使用专门的工具进行简化业务规则语言和业务规则 引擎。 一个业务规则包含一组条件和在此条件下执行的操作，它们表示业务规则应 用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和 修改，但有些复杂的业务规则也可以由技术人员使用面向对象的技术语言或脚本 来定制。业务规则的理论基础是：设置一个或多个条件，当满足这些条件时会触 发一个或多个操作。 3 1 2 规则引擎 规则引擎的定义目前还是业界一个比较有争议的问题，在j s r 9 4 中也几乎 没有定义。本文暂且对规则引擎作如下理解：规则引擎由推理引擎发展而来，是 一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来， 并使用预定义的语义模块编写业务决策。它接受数据输入，解释业务规则，并根 据规则做出业务决策。 3 1 3 规则引擎工作原理 规则引擎的架构如图3 1 所示： 成都理： 大学硕十学位论文 图3 1 业务规则引覃架构 规则引擎的推理步骤如下： ( 1 ) 将初始数据( f ；疵) 输入至工作内存( w r o r k i n gm e m o r y ) ； ( 2 ) 使用p a t t e mm a t c h e r 将规则库( r u l e sr e p o s i t 0 巧) 中的规则( r u l e ) 和数据 ( f a c t ) 比较； ( 3 ) 如果执行规则存在冲突( c o l l f l i c t ) ，即同时激活了多个规则，将冲突的 规则放入冲突集合； ( 4 ) 解决冲突，将激活的规则按顺序放入a g e n d a 。e 执行a g e n d a 中的规 则； ( 5 ) 重复步骤( 2 ) 至( 4 ) ，直到执行完毕a g e n d a 中的所有规则； 任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效 率问题。 当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例， 由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则 执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条 件的规则，生成新的规则执行实例进入队列。于是就产生了一种“动态”的规则执 行链，形成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数据 驱动的。 3 1 4 规则引擎算法 规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据 对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1 9 8 2 年美 1 4 第3 章规则引擎及其可用性 国卡耐基梅隆大学的c t 塌r l e sl f o r ：l 搿发明了一种r e t e 算法，很好地解决了这方 面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用m e 算法。 大部分规则引擎产品的算法，基本上都来自于d lc h a l l e sf o 哟r 在1 9 7 9 年提 出的r e t e 算法及其变体，r e t e 算法是目前效率最高的一个f o r w a r d c h a i n j n g 推 理算法，d r o o l s 项目是r e t e 算法的一个面向对象的j a v a 实现，r e l t e 算法其核心 思想是将分离的匹配项根据内容动态构造匹配树，以达到显著降低计算量的效 果。 使用r e t e 算法进行模式匹配时，是根据生成的鉴别网络来进行的。网络中非 根结点的类型有1 i i l p u t 结点( 也称为a l p l l a 结点) 和2 卸u t 结点( 也称为b 嘲 结点) 两种。1 i n p u t 结点组成了触p 1 1 a 网络，2 岫姗结点组成了b e t a 网络。 每个非根结点都有一个存储区。其中1 i n p u t 结点有d p l l a 存储区和一个输入口； 2 i n p u t 结点有l e f t 存储区和r i g h t 存储区和左右两个输入口，其中1 e f 【存储区是 b 咖存储区，r i g h t 存储区是a l p h a 存储区。存储区储存的最小单位是工作存储区 元素( w o 出m gm e m o r ye 1 e i n e n t ，简称w m e ) ，w m e 是为事实建立的元素，是 用于和非根结点代表的模式进行匹配的元素。t o k e n 是w m e 的列表，包含有多 个w m e ，( 在f o r g y 的论文中，把t o k e n 看成是w m e 的列表或者单个w m e ， 为了阐述方便，本文将把t 0 k e n 只看成啪的列表，该列表可以包含一个啪 或者多个w m e ) ，用于2 i n p u t 结点的左侧输入。事实可以做为2 i n p u t 结点的右 侧输入，也可以做为1 i 1 1 p u t 结点的输入。每个非根结点都代表着产生式