发明内容
为了解决上述技术问题,本申请提供了一种获取WebApp执行过程的方法及***,能够快速、自动地展现WebApp代码在实际环境下的执行过程。
为了达到本申请目的,本申请提供一种获取WebApp执行过程的方法,包括:按照预先设置的录制模型,基于WebApp调试协议控制WebApp的执行;
WebApp执行程序并返回执行过程。
所述录制模型包括用于表示在所述WebApp执行过程中需要覆盖的WebApp代码的代码范围;
用于控制WebApp代码的执行过程的执行策略;
用于标明WebApp代码的执行过程中所需要探测的各种变量的信息探测。
所述基于WebApp调试协议控制WebApp的执行包括:
基于WebApp调试协议,在所述录制模型指定的代码范围内,向WebApp所在运行端发送按照所述录制模型中的执行策略探测指定变量的调试指令,控制WebApp的执行。
所述WebApp执行程序并返回执行过程包括:
所述WebApp基于WebApp调试协议、按照所述调试指令在指定代码范围内,按照所述执行策略执行程序,以探测指定变量的值并返回。
所述返回的执行过程为执行日志。
该方法还包括:对所述执行日志进行分析和汇总,获得直观的执行报告。
所述录制模型还包括用于指明需要探测的事件的事件触发条件。
所述执行策略包括:按照广度遍历优先、或者深度遍历优先及探测深度;其中,
广度遍历优先,为分析所述WebApp代码执行过程时,按照广度优先的方式逐层展现所述WebApp代码的执行过程;
深度遍历优先,为所述WebApp代码调用的关系按照调用堆栈的方式展现所述WebApp代码的执行过程;
探测深度,用于指明所述WebApp代码调用的最大堆栈深度。
所述信息探测包括局部变量、全局变量和表达式。
本申请还提供一种获取WebApp执行过程的***,包括WebApp运行端,及录制中心,其中,
录制中心,其中存储有预先设置的录制模型,用于按照预先设置的录制模型,基于WebApp调试协议控制WebApp的执行;
WebApp运行端,用于在录制中心的控制下,WebApp执行程序并向录制中心返回执行结果。
所述录制中心,具体用于基于WebApp调试协议,按照所述录制模型指定的代码范围内,向所述WebApp运行端发送按照录制模型中的执行策略探测指定变量的调试指令,以控制WebApp的执行。
所述WebApp运行端,具体用于基于WebApp调试协议,按照所述调试指令在指定代码范围内,按照所述执行策略执行程序,以探测指定变量的值并返回给录制中心。
所述返回给录制中心的结果为WebApp执行的执行日志。
所述录制中心,进一步用于对所述WebApp运行端返回的执行日志进行分析和汇总,获得直观的描述录制过程中WebApp执行的全过程的执行报告。
本申请提供的方案包括按照预先设置的录制模型,基于WebApp调试协议控制WebApp的执行;WebApp执行程序并返回执行过程。本申请获取WebApp执行过程的方法,由于在实际运行环境中探测WebApp代码的真实执行情况,对于Javascript这种动态脚本语言,更准确和真实;而且,本申请获取WebApp执行过程的方法无需人工干预,快速、自动地控制了程序的执行;也无需对源代码有任何修改,不会在代码中留下与业务无关的干扰代码,从而避免了引入风险和性能损耗。
本申请的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本申请而了解。本申请的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚明白,下文中将结合附图对本申请的实施例进行详细说明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互任意组合。
在本申请一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行。并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
目前,记录WebApp在实际运行环境下的执行过程的方式大致包括:
一种是基于WebApp代码的静态分析,即通过对WebApp代码的静态分析,得到WebApp代码的调用关系,从而在一定程度上分析出WebApp的执行过程。比如一些面向对象的建模语言(UML,Unified Modeling Language)工具通过运用统一的、标准化的标记和定义,以实现对软件***进行面向对象的描述和建模,可以从实际代码中直接生成程序执行的时序图。但是,由于Javascript是一种动态脚本语言,因此WebApp的执行过程和调用关系很容易受到实际运行环境的影响,而仅仅通过对运行前的代码进行静态分析,是很难准确地分析出WebApp的实际执行过程的。
另一种是手动调试,即基于WebKit调试协议对移动设备中的WebApp进行远程调试,这样就可以使得开发人员通过手动调试Javascript来分析WebApp代码的执行过程。其中,WebKit是运行WebApp的开源引擎,苹果操作***(iOS)和安卓操作***(Android os)的WebApp的运行环境都是基于WebKit构建的。WebKit调试协议是WebKit将内部的调试能力定义为标准的协议,基于WebKit调试协议,外部的第三方工具如调试IDE就能对WebKit上运行的WebApp进行调试。通过手动调试虽然能够准确地分析出WebApp代码的执行过程,但是,手动调试需要建立在开发人员的主观判断之上,只有开发人员事先已具备了对代码的一定分析判断能力,知道如何调试代码后,才能开始对WebApp代码进行分析。可见,手动调试是无法快速地、自动地给开发人员展现WebApp代码的执行过程的。
还有一种是在代码中手动添加日志,即在WebApp代码的每个方法中都添加日志输出,并根据需求在日志中打印需要查看的执行过程的信息,比如在某方法method1的开头加上打日志的代码:log(“method1 begin”),这样当执行method1时,就会在日志文件中看到这样的日志,从而得知method1开始执行的时间。为了能全面展现WebApp代码的执行过程,就需要在某个可能的程序方法中添加日志信息。这种在WebApp代码中手动添加日志的方式不但繁琐,而且还会在代码中留下与业务无关的干扰代码,除影响了实际代码的美观,还为代码的执行引入了一定风险和性能损耗。
图1为本申请获取WebApp执行过程的方法的流程图,如图1所示,包括以下步骤:
步骤100:按照预先设置的录制模型,基于WebApp调试协议控制WebApp的执行。
本步骤中录制模型至少包括代码范围、执行策略、信息探测;其中,
代码范围,用于定义在录制过程(即WebApp执行过程)中需要覆盖的WebApp代码,只有在代码范围内的WebApp代码才会被探测到并被执行。代码范围可以是代码文件名路径或者方法名,其支持通配符,比如:*Action.js表示所有文件名以Action.js结尾的代码都在WebApp执行的范围内。
执行策略,用于控制WebApp代码的执行过程。比如按照广度遍历优先、或者深度遍历优先及探测深度等。其中,广度遍历优先,是指分析WebApp代码执行过程时,按照广度优先的方式逐层展现WebApp代码的执行过程;深度遍历优先,是指WebApp代码调用的关系按照调用堆栈的方式展现WebApp代码的执行过程;探测深度,用于指明可展现WebApp代码调用的最大堆栈深度。
信息探测,用于标明在代码执行过程所需要探测的各种变量的值。其中,变量可以包括局部变量、全局变量和表达式。举例来看,假设指明探测变量为message,则WebApp代码的执行过程中会记录变量message的值的变化的全过程。
录制模型还进一步包括:事件触发条件,用于指明需要探测的事件,比如异常的发生,按时间周期的循环等触发的录制过程。
本步骤中基于WebApp调试协议控制WebApp的执行具体包括:基于WebApp调试协议,在预先设置好的录制模型指定的代码范围内,向WebApp运行端发送按照录制模型中的执行策略探测指定变量的调试步骤如WebKit调试协议提供的breakpoint,stepIn,stepOut,stepOver等调试指令,以此控制WebApp的执行。其中,breakpoint表示从代码中具体行数开始控制执行,stepIn/stepOut表示按深度遍历优先方式执行代码下一步,stepOver表示按广度遍历优先方式执行代码下一步。比如,假设按照广度遍历优先控制程序的逐步执行的指令为:{″method″:″Debugger.stepInto″,″id″:53},该指令指明了该指令是要到方法method里执行下一步,其中,id:53是该指令的标识,当有回复时,用于与回复一一对应。
步骤101:WebApp执行程序并返回执行过程。
本步骤中,WebApp运行端如移动设备中的WebApp基于WebApp调试协议、按照调试指令在指定代码范围内,按照执行策略执行程序,以探测指定变量的值并返回。本步骤中的具体实现属于本领域基于WebKit调试协议的单步调试过程,具体实现属于公知技术,这里不再赘述。本步骤强调的是,移动设备中的WebApp是按照预先设置的录制模型的具体策略和要求执行调试指令的,从而实现了对WebApp在移动设备中执行过程的录制。
本步骤中,返回的执行过程可以以执行日志的方式返回的,该执行日志是显示执行过程的执行报告的数据来源,数据格式基于WebKit调试协议,描述了录制过程中WebApp执行的全过程。举例来看:
(1)执行日志。
这里只是被调试的一段Javascript程序,具体含义是本领域技术人员熟知的技术。
(2)当WebApp执行完成即录制完后,得到的日志如下,其中结果(result)开头的都是日志信息,method开头的都是调试指令:
{″result″:{″breakpointId″:″http://t.com/yuanzhijun/testDebug.js:2:0″,″locations″:[{″scriptId″:″115″,″lineNumber″:2,″columnNumber″:1}]};属于日志,表示已在第二行处停止执行;
{″method″:″Debugger.paused″,″params″:{″callFrames″:[{″callFrameId″:″{\″ordinal\″:0,\″injectedScriptId\″:7}″,″functionName″:″test_debug″,″location″:{″scriptId″:″115″,″lineNumber″:2,″columnNumber″:1}]};属于指令,表示要在第二行处停止执行;
{″method″:″Debugger.resumed″};属于指令,表示继续执行下一步;
{″method″:″Debugger.paused″,″params″:{″callFrames″:[{″callFrameId″:″{\″ordinal\″:0,\″injectedScriptId\″:7}″,″functionName″:″test_debug″,″location″:{″scriptId″:″115″,″lineNumber″:3,″columnNumber″:14}]};属于指令,表示在第三行处停止执行;
{″method″:″Debugger.resumed″};属于指令,表示继续执行下一步;
{″method″:″Debugger.paused″,″params″:{″callFrames″:[{″callFrameId″:″{\″ordinal\″:0,\″injectedScriptId\″:7}″,″functionName″:″setInnerText″,″location″:{″scriptId″:″115″,″lineNumber″:6,″columnNumber″:8}]};属于指令,表示在第六行处停止执行。
上述执行日志中包含了对整个WebApp的执行过程,指明了每一步代码执行的方法名和行数,因此,通过该执行日志即可分析出WebApp代码的执行过程。
(3)上述例子,按照广度优先控制程序的逐步执行的指令为:{″method″:″Debugger.stepInto″,″id″:53},该指令指明了该指令是要到方法method里执行下一步,其中,id:53是该指令的标识,当有回复时,用于与回复一一对应。
(4)为了更直观的显示WebApp的执行过程,本申请方法还包括:对获得的执行日志进行分析和汇总,即收集result中的信息并顺序展示的过程,以获得直观的执行报告,比如采用各种统计图形来图形化辅助展示等,具体实现属于本领域技术人员的惯用技术手段,这里不再赘述。比如,上述例子中得到的执行报告为:
test_debug(testDebug.js)
---setInnerText(testDebug.js);
其中,test_debug(testDebug.js):表示testDebug.js文件中的方法test_debug;setInnerText(testDebug.js):表示testDebug.js文件中的方法setInnerText。表示上述例子执行过程是test_debug->setInnerText(在test_debug调用函数steInner Text)。
本申请获取WebApp执行过程的方法相比于代码的静态分析的方法,由于是在实际运行环境中探测WebApp代码的真实执行情况,对于Javascript这种动态脚本语言,在运行环境中探测的数据比代码的静态分析更准确和真实;本申请获取WebApp执行过程的方法相比于人工调试,无需人工干预,自动展现代码执行过程,完全自动化地控制了程序的执行以及得到执行报告;本申请获取WebApp执行过程的方法相比于在代码中手动添加日志的方法,无需对源代码有任何修改,不会在代码中留下与业务无关的干扰代码,从而避免了引入风险和性能损耗。
图2为本申请获取WebApp执行过程的***的组成结构示意图,如图2所示包括WebApp运行端,及录制中心,其中,
录制中心,其中存储有预先设置的录制模型,用于按照预先设置的录制模型,基于WebApp调试协议控制WebApp的执行。具体用于,基于WebApp调试协议,按照预先设置好的录制模型指定的代码范围内,向WebApp运行端发送按照录制模型中的执行策略探测指定变量的调试指令,以控制WebApp的执行。
WebApp运行端,用于在录制中心的控制下,WebApp执行程序并向录制中心返回执行结果。具体用于,基于WebApp调试协议,按照调试指令在指定代码范围内,按照执行策略执行程序,以探测指定变量的值并返回给录制中心。其中,WebApp可以以执行日志的方式返回给录制中心。
录制中心,进一步用于对WebApp运行端返回的执行日志进行分析和汇总,获得直观的描述录制过程中WebApp执行的全过程的执行报告。
本领域的技术人员应该明白,上述的本申请实施例所提供的装置的各组成部分,以及方法中的各步骤,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上。可选地,它们可以用计算装置可执行的程序代码来实现。从而,可以将它们存储在存储装置中由计算装置来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本申请不限制于任何特定的硬件和软件结合。
虽然本申请所揭露的实施方式如上,但所述的内容仅为便于理解本申请而采用的实施方式,并非用以限定本申请。任何本申请所属领域内的技术人员,在不脱离本申请所揭露的精神和范围的前提下,可以在实施的形式及细节上进行任何的修改与变化,但本申请的专利保护范围,仍须以所附的权利要求书所界定的范围为准。