1先容

属于银行,电子商务,康健管理等领域的Web运用程序具有广泛的用场,并且构成了大部分软件开拓社区的关键焦点。
然而,由于以下关键缘故原由,基于代码的Web运用程序剖析问题仍旧是一个寻衅:(1)客户端页面和做事器端代码都卖力供应运用程序的整体功能,但是常日利用不同的措辞和技能来实现。
(2)客户端页面是由做事器端代码根据做事器端状态的内容动态天生的,但是卖力全体运用程序内的关键掌握流数据流链接。
换句话说,客户端页面在观点上类似于自修正代码,这很难剖析。
(3)须要考虑用户交互。

1.1我们的发起:页面模型

我们完本钱文所述事情的目的是实现Web运用程序的各种端到端白盒剖析。
我们启用此功能的关键发起是页面模型的新观点,它是与做事器端代码利用相同措辞的代码片段。
每个页面规范的页面模型由我们的方法自动天生,并在该页面的所有可能的动态实例中捕获页面的底层打算语义。
随后,结合页面模型(更换原始页面规范)的做事器端代码可以被视为标准程序(在做事器真个措辞中)以用于剖析目的。

jsp无法获取后台model应用页面模子的Web运用测试与剖析 SQL

图3显示了图2中描述的页面规范SelectAddress.jsp的简化页面模型。
将JSP页面转换为包含“root”方法pageModel的Java类,该方法吸收并处理要求。
链接被建模为对得当目标的方法调用;例如,在图3中,第8行是对“DeliveryOptionsServlet”的“doGet”方法的调用,该方法在点击由于图2中的第4行而天生的链接时吸收要求。
请把稳,可以从支配描述符获取该当吸收每个要求的servlet,支配描述符常日是从URL到servlet名称的映射。
在网页中,用户可以选择要单击的链接。
页面模型利用布尔方法“coinFlip()”对此选择机制进行编码,该方法非确定性地返回true或false。

会话属性以及要求参数在页面模型中被建模为全局变量。
前者在图3中利用打字机字体表示。
要求参数利用斜体字体表示——只有一个要求参数从此页面通报给DeliveryOptionsServlet,即地址。
设置会话属性状态的图2中的第7行成为图3中第7行中相应全局变量状态的赋值。
类似地,EL表达式中对会话属性的引用被建模为对相应全局变量的引用。
JSP掌握流布局如forEach和choose-when-otherwise虔诚地转换为页面模型中的等效Java布局。

值得把稳的是,全局变量状态在图3中的第7行更新,这是在第8行的调用之前,纵然在图2中的页面规范中,相应的行(即第7行和第4行)涌如今相反的顺序。
这是为了适当考虑我们在1.4节中谈论过的掌握流的反演。

运用程序中页面的页面模型须要与做事器端代码集成,以产生一种标准(单一措辞)程序,该程序在行为上虔诚于原始Web运用程序。
为此,我们的方法还在做事器端代码中运用了某些代码变动。
例如,对会话属性的所有引用都更换为对相应全局变量的引用。
Java代码中存在的“转发”到页面规范将被相应页面模型中对pageModel方法的调用所取代。

由我们的方法得出的终极标准程序适用于任何单措辞剖析工具。
例如,在我们的运行示例中,来自'DeliveryOptionsServlet'中的语句的后向切片读取要求参数地址的值将拉入图3中的第3-6行,并且还可以通报给其他部分中的代码。
添补列表地址的做事器。
并且(单一措辞)属性检讨器将能够遍历实行路径通过做事器端代码并​​通过页面模型来确定例如“DeliveryOptionsServlet”一定利用当前登任命户的有效地址。

与以前的方法比较,页面模型具有以下上风:

页面模型常日与剖析无关,并且原则上支持任何基于代码的剖析,无论是基于静态剖析,动态剖析,符号实行等。
而以前的白盒方法[2,3,8,9,12,22,26,27]剖析了页面规范以及做事器端代码,每个都针对特定的剖析问题。
因此,页面模型可能潜在地构成通用Web运用程序剖析根本构造的根本。
开拓职员可以直策应用标准程序中丰富的现有单一措辞工具集,这些工具是将页面模型与做事器端代码集成在一起的。
页面模型使静态剖析能够通过要求参数和会话属性同时守旧地跟踪数据流。
以前的静态剖析方法[9,12,26]没有办理这种组合问题。

1.2我们的贡献

我们的紧张贡献是页面模型的新观点,可以对Web运用程序进行各种端到真个白盒剖析。
本文的其他贡献如下:

通过详细描述将动态JSP(Java做事器页面)页面规范转换为Java(做事器端代码的措辞)中的相应页面模型的转换算法,来实现对J2EE运用程序的内容的实例化。
但从观点上讲,我们的核心思想适用于任何利用基于HTML的脚本编写页面规范的技能,例如PHP,Ruby on Rails,Struts等。
方法的实现谈论我们运用各种现成的白盒剖析工具的履历,例如Wala [29]的静态切片,Java Path Finder [14]的逼迫实行,以及基于动态剖析的故障定位Zoltar [5]。
本文的别的部分构造如下。
第2节供应了有关J2EE和JSP的背景知识。
第3节更深入地先容了页面模型的观点,而第4节谈论了我们自动翻译方法,该方法根据页面规范天生页面模型。
第5节供应了履行细节,而第6节供应了实证结果。
我们在第7节谈论干系事情,并在第8节中总结论文。
2页面模型

2.1构建一个精确页面模型的寻衅

我们在1.5节中先容了页面模型背后的基本思想。
图3中的简化页面模型确实是图2中页面规范的可接管页面模型。
但是,在更繁芜的页面规范中,具有如图3所示的大略形式的页面模型是不足的。

第一个问题是须要重新排序更新会话属性的语句,以便考虑掌握流的反转。
图3中的页面模型包含了这种重新排序(如第1.5节所述)。
让我们考虑一个更繁芜的页面规范,它有一个循环,在循环中包含状态更新和链接规范。
现在,在页面模型中,所有状态更新语句都须要在代表链接的所有调用之前涌现。
这将须要以保持语义的办法将循环分成两个循环,这常日是繁芜的变换。
如果在页面规范中同时利用排序,循环,条件等,则这种代码复制变得更加繁芜。

其次,链接点击的真实语义是不返回的。
然而,代表链接的呼叫彷佛许可掌握返回到页面,然后是另一个链接被点击等。
这个问题不能大略地通过在每个呼叫站点之后放置“goto”来修复页面模型的一部分,由于这会使得在页面模型的任何实行中碰着的第一个链接看起来始终是所采取的链接。

2.2一个实用,精确的建模办法

为相识释我们的实际发起,我们在图5中呈现了这种方法为图2中的页面规范天生的页面模型。
该页面模型的显著特色如下。
第6-18行是页面模型的核心。
这部分代码基本上具有与页面规范相同的掌握流构造,但具有如下所述的某些局部变换。

在每个链接的位置,而不是对应于链接的呼叫,设置局部变量'whichClicked'来记录链接的URL。
例如,图5中的第9行和第16行分别对应于图2中第4行和第10行的链接规范。

第19-27行包含我们称之为finalBlock的内容。
这基本上是一个“switch”语句,用于检讨'whichClicked'的值,并调度到相应的servlet。
这样,表示链接的调用基本上不会返回。

局部变量'anyClicked'用于确保在页面模型的任何路径中最多单击一个链接。

更新会话属性的语句保留在与页面规范相同的相应位置;拜会图5中的第12行和第18行,它们对应于图2中的第7行和第11行。
这样,所有状态更新都发生在所有调用之前(在finalBlock中)。

末了,在原始链接位置,要求参数的值被捕获到新引入的阴影变量中(拜会图5中的第11行)。
稍后,就在finalBlock中的“switch”语句之前,这些影子变量被复制到相应的全局变量中,这些变量代表建模程序中的要求参数(拜会第19行)。
这样,将会精确处理第1.4节中的示例,个中会话属性首先在链接规范中利用然后更新。
此外,在finalBlock的开头,表示所有页面的所有要求参数的所有全局变量都设置为null,以确保作为要求参数发送到页面的值不会终极到达某个其他后续页面。

3实现与运用

3.1剖析1:利用JPF进行深度属性检讨

通过我们的翻译实现的强大剖析是检测运用程序中的功能缺点,完备考虑动态客户端页面,做事器端逻辑以及这两者之间的交互。
对付此剖析,我们利用Symbolic PathFinder(SPF)工具[14],它是广泛利用的工具Java PathFinder(JPF)[4]的繁芜实行变体。
我们在此草拟了在我们的方法天生的修正后的运用程序上运用SPF时所遵照的步骤。
首先,我们在天生的页面模型中实行了三种修正,以确保运用程序的详尽覆盖(而不是仅通过一个随机的页面序列):(1)页面模型现在利用SPF API来选择所有可能的链接每当访问一个页面时,逐页形成一个页面。
(2)同样,下拉列表中的所有值都是逐个考试测验的。
(3)利用SPF API添补文本框,该API返回新的符号值。
到目前为止,我们已手动在天生的页面模型中实行了这些修正;然而,原则上自动化很随意马虎。

我们还在做事器端代码中进行了两种修正:(1)SPF没有现成的精确剖析运用程序中的数据库操作。
因此,我们手动修正了我们在实验中利用的基准测试运用程序,以利用普通的Java凑集而不是数据库。
(2)我们将属性检讨代码插入基准,以实际检讨是否存在所需属性的违规。
现在可以利用SPF以系统的办法探索运用程序的痕迹以查找违规行为。

我们检讨了各种功能属性的基准测试,例如,“不许可利用相同的电子邮件ID进行多次注册”,“如果购物车为空,则总数应为零”,依此类推。
我们从作为官方iTrust文档的一部分供应的需求规范中提取了iTrust的属性。
其他基准没有供应文件;因此,我们哀求与我们的事情无关的研究生运行基准并确定空想的属性。
我们以这种办法共得到了19处房产。
表2总结了该实验。
如表2所示,具有页面模型(PM)的JPF报告在一些运行中违反了19个属性中的8个。
个中六个是可重现的,而两个(IT和MS各一个)是误报。
个中一个误报是由于SPF的限定,而另一个是由于页面模型在表单有多个“提交”按钮时没有精确表达语义。

别的11个属性可以被认为是针对长度达到所考虑范围的路径进行验证。
这是由于我们的方法是详尽地考虑所有选择,并对所有文本框利用符号值,如第5.2节所述。

我们不雅观察到的运行韶光对付19个属性中的每一个都在几秒到7分钟之间。

3.2剖析2:利用Zoltar进行缺点定位

Zoltar [5]是一种基于动态剖析的故障定位工具。
给定一组通过和失落败的测试用例,该工具根据所有给定的测试用例剖析程序中所有语句的实行相对频率。
对付程序中的每个语句,它会报告一个疑惑分数,表明该陈述可能是导致测试失落败的缘故原由。

对付本实验,我们首先利用我们的方法将基准Web运用程序集转换为修正(标准Java)程序。
为了在所有实验中保持同等,我们在此剖析中以及不才一次剖析(即切片)中利用修处死式的版本,个中数据库操作被凑集操作更换(拜会第5.2节)。
不才一步中,我们手动为每个基准创建了一组测试用例。
测试用例只是一系列要访问的页面,以及每个访问过的页面中的输入选择元组。
我们所有的测试用例都通过了测试用例。
然后我们在(修正的)基准程序中播种缺点。
为了以无偏见的办法栽种bug,我们利用了一种变异测试工具,即PIT [15]。
我们从PIT建议的每个基准中随机选择了20个突变,把稳选择导致至少一些测试用例失落败的突变。
因此,我们得到了每个基准测试的20个版本。

然后我们在每个基准测试的每个变异版本上运行Zoltar,利用基准测试用例(个中一些现在失落败了)。
然后,我们评估了Zoltar在确定每个基准测试的每个缺点版本中的变异位置的有效性。

从Zoltar的每次运行(在基准的缺点版本上),我们首先打算每种方法的疑惑分数,作为该方法中任何语句的最大疑惑分数。
然后,我们将那些分数大于或即是包含种子缺点的方法得分的方法入围。

在基准TD的20个缺点版本中,每个版本的入围方法的均匀数量仅为3.27%。
(在本节中,我们仅利用几何均匀值。
)也便是说,直不雅观地说,在找到缺点之前,只须要检讨缺点版本中3.27%的方法。
其他基准的入围方法的相应均匀百分比为:RO为5.3%,MS为4.9%,HD为3.9%,IT为0.2%。
这些极低的数字表明我们的页面模型与Zoltar工具结合利用来定位我们的基准程序中的故障。

我们很难得到这些实验的基线。
由于运用程序的分层体系构造,以及做事器端框架和库,Zoltar(或者就此而言,大多数动态剖析工具)无法直接在Web运用程序上事情。

3.3剖析3:利用Wala进行静态切片

对付这个实验,我们对由我们的方法天生的修处死式运用静态反向切片。
由于Wala的“完备”切片常日不会扩展到更大的基准,我们利用“工具类型高下文敏感度”选项打算“瘦”切片[23]。
我们的目标是理解大切片在实践中的方向,它们如何常常超过多个页面的边界,以及切片是否有助于检测缺点的缘故原由。
我们选择这种剖析的另一个动机是切片一贯是软件工程界的一个研究课题,乃至特殊是针对网络运用的研究职员[12,19,26]。

在我们的第一组切片实验中,我们利用程序中的所有“输出”表达式——即,将值插入数据库或显示页面的表达式——作为标准。
表3(a)部分供应了有关所有这些标准的切片的统计数据。
表格中前四列的含义如下:(1)基准名称,(2)标准总数(即采纳的切片总数),(3)均匀页数(即,包含在切片中的不同“pageModel”方法,以及(4)运用程序中包含在切片中的方法的均匀百分比。
很随意马虎看出切片常日超过大量页面边界;换句话说,用于Web运用程序的切片工具肯定须要考虑通过页面的数据流。
而且,这些切片每每很小,因此有可能对开拓职员有用。

表3的(b)部分供应了有关我们根据条件打算的切片的信息,这些条件是某些运行中包含禁绝确值的表达式。
这些标准是从JPF检测到的财产违规行为中确定的(见上文第6.1节)。
这样的切片可以帮助识别缺点的根本缘故原由。

4总结与未来事情

以前关于Web运用程序剖析的研究已经产生了繁芜的技能,但每种技能都办理了一种非常分外的剖析问题。
大概正由于如此,令人惊异的是缺少可扩展,强大的工具和平台,用于Web运用程序的细粒度白盒剖析。
比较之下,我们利用页面模型的方法可以运用Web运用程序中存在的大量强大的单措辞工具。
此外,与先前用于Web运用程序的静态剖析方法比较,我们的第一个通过要求参数和会话属性以原则办法处理同步数据流。
未来事情的想法包括办理cookie,Javascript以及其他平台,如Ruby on Rails和PHP。

致谢

此文由南京大学软件学院2016级本科生虞圣呈翻译转述。