从企业WEB应用挖掘行为模式.doc

从企业WEB应用挖掘行为模式摘要：今天的企业WEB应用需要很高的发行循环，因此需要频繁的测试。自动进行这些测试通常需要一个行为模型：一种状态描述，应用程序可以在这些状态与期望的结果之间进行转换。此外，人们需要脚本使得抽象动作转换成可执行的模型。由于指定这样的行为模式和手动编写必要的脚本是一个艰巨的任务，一种可行的替代是从现有的应用中提取他们。然而，挖掘这样的模型是一种挑战，尤其是因为需要知道何时两种状态是等价的，以及如何达到该状态。我们提出了PROCRWAL（过程爬虫），一种通用的从多用户企业WEB应用中挖掘行为模式的途径。PROCRWAL通过它的用户接口观察应用程序的行为，产生并执行测试去发现未观察到的行为。在我们评估的三个有意义的WEB应用中，PROCRWAL产生了精确抽象应用程序行为的模型，并且它可以直接用于有效的基于模型的回归测试。1、简介今天的企业WEB应用具有高频率更新的特征。为了避免这样的更新破坏功能性，人们不得不进行测试频繁的更新需要频繁的测试。自动这些测试需要一个模型描述可能的和被期望的应用程序行为。然而，典型的WEB应用程序都没有明确的模型，这意味着几乎手动和效率低下的测试，同时也减慢了对应用的理解与维护。规范挖掘领域的目标是促进这些从程序和他们的执行结果中挖掘抽象概念的活动通常情况下，程序的行为模式。如果这些模式足够精确，它们甚至可以用于时候的程序规格书。规范挖掘已经成功的用于推导公理规范像程序中的功能以及不可变数据，或有限状态自动机描述状态和单独类之间的转换。对于这样小规模的域，它可以相当容易的验证规范，因为程序代码和程序状态两者都可以访问并顺从符号推理和详细的测试。对于企业应用，抽取描述他们可能的行为模式是非常困难的。举个例子，程序代码和程序状态可能因为应用被分布在多个不同的层面和站点而导致不能被有效的分析。通常，唯一可以做出的假设是有一些像WEB接口之类的用户接口允许人进行交互。在本文中，我们提出PROCRAWL，一个为了进行系统测试与维护的工具，它可以挖掘企业WEB应用中明确的行为模式。所有PROCRAWL所需要的是WEB应用的URL、用户的登录证书、一个范围定义（例如，需要进行观察的WEB应用的部分）并启动事件。由此产生的行为模式是一个有限状态自动机，其中的节点表示WEB应用的抽象独立状态，PROCRAWL根据他们检测到的顺序进行编号，然而转换代表用户在不同的角色中执行、修改状态的动作。该模式可以作为一个“黄金法则”用于检测从一个应用版本到另一个应用版本的回归。作为一个例子，图例1显示的是OpenConf的审阅者页面，基于Web的会议管理系统。作者可以通过OpenConf提交论文，论文经过同行的审查并可以进行拒绝或接受（我们假设一个过程是大多数熟悉这个本文的大多数读者）。分别针对作者、审阅者和主持人使用不同的登录脚本，PROCRAWL推断一个提交（参见图2）的生命周期：经过作者对论文做的一个提交，所提交的状态呈现为等待（状态2）。在将论文分配给审阅者之前，主持人可以接受（状态9）或者拒绝（状态10）该份论文。为三个未分配状态对应审阅者分配后的状态（状态3，4，5）和审阅者提交审议（状态7，6，8）之后。在任何时候，主持人可以撤销先前的决定或分配新的审阅者。然而，在分配评审，没有办法恢复到未分配状态（状态2，9，10）。为了恢复到未分配状态下的行为，ProCrawl需要一个命令重置，将状态迁移到OpenConf状态1。数字（特征）3：ProCrawl是如何工作，以及它的配置信息：(a)描述个体的活动和它们的初始化数据，例如，登录，它在web应用上触发了开始事件（提交）和(b)决定了应用的状态，这将产生一个初始化行为模式，(c)这个行为模式包括开始事件和观察状态，ProCrawl它将系统地和自动地去生成更长远的执行力(d)去探索额外的状态和转变。这个结果是一个更加强化的行为模式（e）从web应用中可以得到。2. 企业级应用测试当执行这些业务流程时，企业web应用程序支持业务流程围绕数据存贮在后台操作，业务流程包括多个相互作用的角色（比如卖方和供应商，或一个作家，评论家，会议主席等）这个中央数据的合作编辑是通过客户端，这些客户端可能有不同的功能，根据用户角色和一些主要的UI视图来区分这个应用的功能。在先进的架构访问是基于浏览器的客户端。一个说明性的列子是OpenConf,而更多的面向业务在第5部分中介绍)。对于管理的复杂性，测试企业应用通常发生在服务层，单元测试确保这个软件单元是功能在孤立的高代码覆盖率下是正确的，但是服务和综合测试确保合同的实现和集成测试确保合同的实现和集成测试义务服务/组件和正确的沟通服务/组件之间的耦合。在本文中,我们专注于最顶部水平在该层次结构系统经历一个交叉模块系统测试,重演业务流程应用程请注意,在这个层面上我们并不关心所有的这个源代码通过测试,从一个终端用户的角度来看,而是成功地执行所有必需的业务流程即与多个用户通过UI测试不同的角色。在一个集成的系统许多服务/组件,这样做的优势在于访问源代码不是必需的。然而这是一个有效的假设我们至少可以重置系统状态初始化，最初,例如通过重新设置应用程序的数据库。在今日的工业实践上工程企业应用程序(特别是应用程序“在云中部署”)发布的频率通常是非常高的。因此回归测试确保功能保存从一个版本到另一个系统上的水平需要高度有效性和自动化。随着这一目的就是测试自动化,基于测试的模型(MBT)已经扩展为自动化软件测试在测试设计阶段，行为模型可以用来获得一个测试套件然后通过自动化测试框架执行，今天，工业应用显示积极地MBT除开发生产力（例如11），然而大规模应用缺少详细的模型去测试和维护，尤其是对回归测试，自动挖掘模型反映出可以从实际的行为去运行企业系统，（黄金标准）是一个十分钟的意义在推动自动测试模型上。总体来说，这样的模型需要覆盖来自非正式文档所需的行为，用户故事等，但不是更多（精度和召回，见第五节）。而且他们应该正确使用程序去实现，即MBT测试应该转换成可再生的程序执行，这些执行将会导致失败，如果路径在前面版本实现的业务流程不再是可能的，我们将会重新审视这些高层的目标。 从技术上讲,这些因素导致至关重要需求需要满足作为一个模型合理的输入企业的基于模型的回归测试Web应用程序第一、需要提供一个适当的抽象模型在后端的两个状态，事实上在用户交互和数据存储在后端。可确定应用程序的行为。第二、通常跨多个业务流程用户在dierent角色。因此,抽象状态在测试模型必须考虑组合来自多个用户会话的状态。此外不测试跨越所有实现的过程可维护的,因此需要模块化,即分裂在一个测试中每个业务流程模型第三、,虽然UI测试是一个完美的测试手段用户级要求,他们不稳定的UI变化频繁。防止模型过时的UI更改,他们应该只包括业务逻辑操作,即行动navigat UI视图之间不应该导致一个新的状态的行为模型,并在脚本中被分离抽象模型中可执行的操作3. 模型推理：ProCrawl 高度自动推断行为模型与适当的抽象状态覆盖多用户流程场景,这一过程详细如下。首先，几乎完全自动，通过系统地抓取sut，procrawl 产生一种行为模式，这种技术是在3.1节描述的，行为模型测算出来的质量非常依赖与应用的抽象机制,这是在3.2节描述的。第二，一个测试工程师可以用附加属性补充推断模型。基于这些模型和通过ProCrawl生成的UI场景,验收测试可以派生并自动执行(cf第七节), 检查是否场景跨越多个不同角色的用户可以重现在SUT的版本中,得到预期的结果。3.1 实验行为模式挖掘ProCrawl是一个实验程序分析工具，即“通过这个工具的控制执行，产生多个执行计划的结果”23。处理业务流程交互涉及多个角色,ProCrawl模拟多个用户(演员) 通过web浏览器操作SUT。演员都配置了一个登录脚本初始化用户会话。在抓取的过程中, ProCrawl为每个演员使用一个单独的web浏览器。图3展示了一个示例在第一节中介绍的会议管理系统的ProCrawl。ProCrawl配置了一组脚本，通过web UI操作SUT,每个脚本的开采范围,即一组脚本(通常是简单的url)导航到UI的观点被认为是状态抽象,UI脚本开始触发事件(:提交),可选地,一个UI元素选择器被认为是状态抽象(见3.2节),和一个命令重置SUT的状态ProCrawl运行启动脚本并通过抽象的活跃的UI元素确定SUT的状态。用观察到的行为生成初始模型。模型是一个迭代的过程：完善状态观察,建模和测试: 测试:ProCrawl生成可执行的脚本的行为模型并且执行在SUT上，探索尚未观察到的行为。观察:ProCrawl决定SUT的状态。模型:该模型在观察的基础上被提炼。丰富模型存储为一个有限状态自动机(见图2), 即一个直接油印属性注释节点和边,可以直接用于规范和基于模型的测试(cf第七节).图中的点代表SUT的状态，被ProCrawl 通过SUT的web UI观察;边缘代表的一系列UI事件被引发通过ProCrawl 配置的一个演员。3.2状态和事件的抽象正如第二节中的讨论，企业web应用程序以不同的角度分离功能,通过触发导航UI事件它可以被访问。通过UI暴露的业务逻辑，提取模型描述SUT，抽象的UI元素procrawl主动识别相似的状态和排除导航事件的行为模式，没有抽象，每一个在UI中的变化会导致一个不同的状态。状态抽象，状态抽象机制采用procrawl背后的想法是，SUT的当前状态是由界面反射，每个演员/视图关系暴露了应用程序的状态的一个特定部分。因此ProCrawl使用一个抽象函数的状态的文档对象模型(DOMs)演员/视图关系区分SUT的不同状态。这允许procrawl无需访问该系统的源代码，就可以确定应用程序状态。一组视图(开采范围) 为每个演员配置。ProCrawl并行的自动导航到各自的观点与所有演员,事件抽象：ProCrawl分类没有改变这个观察状态用SUT（自循环）作为引导，导航事件是特殊对于SUT的用户界面，因此在整个应用程序中不完全生命周期，此外，通常是大量的导航事件杂乱的行为模型， 掩盖了有效地业务逻辑，使模型可能打破造成UI更改，然而，由于流程场景一般跨几个观点，ProCrawl可能需要执行为了激活一个HTML元素导航事件触发一个功能的事件，所以单一的推导一步的场景可能需要执行几个导航事件的另外一个功能活动，ProCrawl通过引入两层抽象来解决这个问题，一个模型独立的导航事件在java UI事件，并自动执行脚本，第二层，绑定导航功能的事件，通过这种方式，如果SUT的UI更改，它就会生成有效的脚本，这种模型只适应导航事件，模型保持不动3.3转向爬行程序通过计算不同的活动的UI元素之前，之后触发一个事件，ProCrawl能够确定事件之间的因果依赖关系，如触发进行提交事件，提交视图。因此行为模型只包含事件的一个因果链。这在业务流程中是很常见的，这样模块化的话更容易理解和维护4、 实现ProCrawl实现是在java SE7中，使用Selenium5 工具使Web浏览器自动化，该工具提供了一个基于观察者模式的扩展机制，观察者可以注册某些事件，比如：procrawl 应用在Java SE 7 中，使用selenium5实现Web浏览器自动化。该工具基于观察者模式提供了一个扩展机制；观察者可以注册某些事件，比如在点击一个HTML元素之前或是之后。测试预言在爬行程序执行过程中可以被称为观察者。算法1显示的爬行程序的初始化为了猜想行为模型。首先，SUT的初始状态s0被检索（第一行）。如前所述，一个状态有一套待定事件，这些事件被procrawl触发，通过在那个状态下的SUT的用户界面；对于初始状态S0的挂起的事件设置为启动事件，在爬行的配置定义（2行）。此外，我们维护一组挂起状态Sp,这仍然需要探索；这一套是用S0初始化（3行）。一个空的FSA用s0创建作为初始状态（4行）。最后，这个爬虫过程被称为s0和FSA(行5)，这是在这套状态上通过迭代是建立的。Algorithm 1: init /Data: set of actors A, set of pending states Sp, configOutput: FSA1 s0 retrieveState();2 s0:pending fconfig:startEventg;3 Sp fs0g;4 FSA new FiniteStateAutomaton(s0);5 returnSUT的状态检索算法2所示。对于每个参与者，在参与者配置中定义的DOM（view）被检索，通过导航图和检查产生的HTML代码（4行）。在从DOM中取出失活的和看不见的HTML元素后，交互式的HTML元素被提取出来然后加到状态的多组事件中。Algorithm 2: retrieveStateData: set of actors AOutput: current state s of the SUT1 s new State();2 foreach actor 2 A do3 foreach view 2 actor:config:scope do4 dom actor:retrieveDom(view);5 df filter(dom);6 s:events s:events events(actor; view; df );7 end8 end9 generateScripts(s:events);10 return s;算法3显示了爬行程序递归建立行为模型。在每次迭代的当前状态SUT的S0检查等待事件。如果集合不为空，一个事件被删除，与事件相关的用户界面脚本被执行（4行）。在脚本执行后，SUT的当前状态S1被检索，一组挂起的事件，即，被执行脚本激活的事件，被计算作为相应的补充，多组事件在s1相对于事件在s0（5-6行）。如果不存在，当前状态s1被添加到挂起状态Sp和FSA节点中；一个从s0到s1的边界，标有触发事件被加到FSA边界的集合中（7-10行）。最后，爬行程序是用S1和更新的FSA递归调用（11行）。如果设定的等待事件是空的，s0从sp中被删除（13行）。如果仍有悬而未决的状态在sp, 回溯程序（算法4）被调用去进入挂起状态的SP和爬行程序通过sp被调用。如果设置挂起的状态是空的，返回FSA（18行）Algorithm 3: crawlData: set of pending states SpInput: current state s0 of the SUT, initial FSAOutput: enriched FSA1 if s0:pending 6= ; then2 event 2 s0:pending;3 s0:pending s0:pending n feventg;4 executeScript(event);5 s1 retrieveState();6 s1:pending s1:events n s0:events;7 Sp Sp fs1g;8 edge new Edge(s0; event; s1);9 FSA.nodes FSA.nodes fs1g;10 FSA.edges FSA.edges fedgeg;11 FSA crawl(s1, FSA);12 else13 Sp Sp n fs0g;14 if Sp 6= ; then15 sp backtrack(s0; Sp);16 FSA crawl(sp, FSA);17 else18 return FSA;19 end20 end算法4显示了回溯过程，这计算最短路径从SUT当前状态S0到待定状态SP使用Dijkstra算法（2行），执行UI脚本到sp(5行)。如果FSA不包含从s0到sp状态的路径，SUT通过执行在配置中的命令设置为初始化状态。s0被设置为初始化状态，回溯过程被再一次调用（11-12行）。Algorithm 4: backtrackData: FSA, configInput: current state s0 of the SUT, pending states SpOutput: pending state sp1 foreach p 2 Sp do2 edges FSA.shortestP ath(s0; p);3 if edges 6= ; then4 foreach e 2 edges do5 executeScript(e:event);6 end7 return retrieveState();8 end9 end10 executeCommand(config:initSut);11 s0 FSA.initialState;12 return backtrack(s0; Sp);5、评价方法为了评估procrawl的在推理行为模型的有效性，我们进行了三个案例研究现实世界Web应用程序：一个SAP企业的Web应用程序，一个开源的网上商店和同行评审系统。我们使用procrawl为核心的行为模式的在核心程序中，评估三套措施：精度。正确性。回归测试的适用性。5.1、评价主体SAP Web应用（S1）：在我们的第一个案例研究，我们应用procrawl在一个SAP企业web应用中为了交换和处理产品符合性信息（参见图4）。OXID eShop（S2）社区：（是一个的e-commerce系统,采用PHP开发,）OpenConf（S3）：（开源的会议管理系统）图4：SAP应用交换和管理产品符合性信息。5.2评估环境评价的环境英特尔酷睿2双核2.5 GHz，带有with 4 GB RAM, runningWindows 7 x64 with Google Chrome 24.4 GB的RAM，windows7x 24,谷歌浏览器24。6、模型的准确性在这一节中我们评估通过procrawl推断的模型的精度，召回率和精度（ACC），正如在第五节（参见表1）。除了配置，没有用户的输入在爬行的过程是必要的。6.1研究1：SAP应用目标的过程。第一个实验的目的是为了推断一个行为模型为了与供应商的联系，这是应用程序的第一个核心场景，涉及两个伙伴。在的情况下，制造商（客户）发送一个连接请求到供应商安装程序发现。C1和C2，PROCRAWL在图5中推断出对FSA的描述。在C2中缩小挖掘范围，把运行时间从64分钟减少到42分钟并限制了HTML元素的设置，考虑了C3中状态抽象也把运行时间减少到17分钟。FSA推断C1和C2由14种状态和31中变化组成，自己形成循环。比如，变化并不改变状态，而是从模式中扩展。FSA还涵盖了进程的描述，在连接进程中对用户和供应者之间的交互进行建模(Cust)。所有的转变代表和目标进程相关的事件，并且所有相关进程的事件都包含在模式内，其精确度和召回率为1.0。PROCRAWL形成5个UI脚本，从模式和触发的由多个UI事件组成的114个复合事件中删除航行的事件。在C3中的用户配置里，PROCRAWL把状态4融合进状态12，把状态9融合进状态14，造成12种状态和28种变化。在应用中手动对这些状态进行比较，我们发现在默认配置中两种叠加的状态在应用程序的收件箱界面呈现不同的信息类型。在状态12和14中，用户的收件箱中有拒绝和确认的提示。然而，在C3的用户配置里，超链接决定信息类型，且不被考虑作为状态抽象。6.2目标进程。第二个案例的研究推断除了 OXID的行为模式的订购流程涉及用户和零售商。用户通过商店的前端进行交互，而零售商可以通过一个单独的后端接口交互：1. 用户在产品界面中选择一个物品并且通过点击购物车按钮把它加入购物车里。2. 用户选择在购物车中选择一种付款方式然后点击”进入下一步“按钮。3. 用户通过点击购物车界面中的”现在下单“按钮确认订单。4. 零售商根据订单的状态通过点击订单界面中的”马上装载“按钮设置订单状态。在第一步和第二步之间，用户可以输入有效的效验码并通过点击“提交优惠券“按钮提交一张优惠券。在第一步和第三步之间，用户可以在购物车界面中选择一些物品并点击”删除”按钮将它们删除。第三步之后，零售商可以有以下操作： 点击订单界面中的链接并确认弹窗，取消订单；这将改变订单状态并且防止装载（步骤四）。 点击订单界面中的链接并确认弹窗，删除订单；这将删除整个系统中所有界面视图中的该订单，并取消所有与之相关的事件。 点击订单界面中的“生成PDF”按钮生成发票。在第四步之后零售商可以通过点击订单界面的“重置订单数据”按钮重新设定订单状态。设置。我们设定了两种机制：(C1) 默认状态抽象化。 (C2) 消费状态抽象化需要考虑特定的具有CSS类的按钮和链接。对于两种机制我们都配置了具有两种动作可分别表现消费者和零售商状态的PROCRAWL，并提供登陆证书和一个添加产品到购物车的启动脚本。根据提供UI脚本去接收前端的购物车和订单历史，挖掘范围正是由此设定的，后台的订单界面也是同样据此设定。只要从后台删除了订单，PROCRAWL就不需要别的命令去重置应用数据。发现。从图6中PROCRAWL默认的配置可以推断出对FSA的描述。考虑到在C2的状态抽象化，减少了HTML元素的数量，由此把运行时间从49分钟减少到18分钟，同样的也将被触发的复合事件数量从170减少到61。FSA推断C1由6种状态和13种变化组成。FSA推断C2也是等同的，但是并不包括途中状态2到状态3虚线上的变化，它代表一个和“进入下一步”按钮有相同功能的链接。对于模型中的每一个区别来说，PROCRAWL形成了一个UI脚本，比如C1中的9，C2中的8。在FSA推断出的C1中，除了那条虚线，所有的变化都代表相关的事件，并且精确度在0.92。在C2中，所有的12中变化都是相关的。在两种配置中，PROCRAWL不包括”提交优惠券“和”生成PDF“事件。虽然两个时间都会在爬行程序中被触发，但他们并不会在状态抽象化中改变任何元素；两种模式涵盖了12至16中相关事件（8至10种分离事件），精确度为0.75。在C1中的154个真实否定和C2中的45个，它们的精确度分别为0.97和0.93。6.3 Study 3: OpenConf目标进程。根据第三个案例研究可以推断出一种对于OPENCONF 同行评审的行为模式，涉及一个作者，一个审稿人和一个主席。1 作者通过填充表格然后单击”提交”按钮进行提交操作。2 主席通过在自动指定审稿人界面中点击“安排”按钮给提交的作品指定审稿人。