CN111221732B - 脚本执行处理方法、装置及存储介质 - Google Patents

Abstract

本公开是关于一种脚本执行处理方法、装置及存储介质；其中，所述方法包括：当脚本执行过程中第n步骤执行失败时，记录所述第n步骤的信息，其中，所述n为正整数；根据所述第n步骤信息，执行第1个异常排除操作；在所述第1个异常排除操作执行成功后，重新执行所述第n步骤；在第x个异常排除操作执行失败后，执行第x+1异常排除操作；所述x为大于等于1的整数；在所述第x+1个异常排除操作执行成功后，返回所述第x个异常排除操作的执行阶段。如此，在确保每个异常排除操作执行成功后，再去执行上一个未成功的异常排除操作，可以在确定每个异常排除操作都成功的基础上，进一步保证脚本执行处理的成功率。

Description

脚本执行处理方法、装置及存储介质

技术领域

本公开涉及自动化测试领域，尤其涉及一种脚本执行处理方法、装置及存储介质。

背景技术

为了确保应用程序的性能，在进入市场前，研发人员需要对应用程序进行反复又精细的测试。通过录制可执行的测试脚本，执行该测试脚本即可实现对应用程序的自动化测试。在进行自动化测试的过程中有时会遇到一些突发情况，会造成测试脚本执行失败，需要通过重试策略去解决所述意外情况，使测试继续执行下去。但目前的重试策略只能解决一部分意外情况，导致脚本执行的成功率不高。

发明内容

本公开提供一种脚本执行处理方法、装置及存储介质。

根据本公开实施例的第一方面，提供一种脚本执行处理方法，包括：

当脚本执行过程中第n步骤运行失败时，记录所述第n步骤的信息，其中，所述n为正整数；

根据所述第n步骤信息，执行第1个异常排除操作；

在所述第1个异常排除操作执行成功后，重新执行所述第n步骤；

在所述第x个异常排除操作执行失败后，执行第x+1异常排除操作；所述x为大于等于1的整数；

在所述第x+1个异常排除操作执行成功后，返回所述第x个异常排除操作的执行阶段。

可选地，所述方法还包括：

记录各所述异常排除操作的执行次数；

在异常排除失败时，确定各所述异常排除操作的执行次数是否达到预定次数；

若有至少一个所述异常排除操作的执行次数未达到所述预定次数，执行未达到所述预定次数的所述异常排除操作。

可选地，所述异常排除操作包括：

第一类异常排除操作及第二类异常排除操作；

其中，所述第一类异常排除操作包括以下至少之一：

针对运行所述脚本的服务端内的异常排除操作；

针对所述服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作；

所述第二类异常排除操作包括：针对意外弹窗的异常排除操作。

可选地，所述方法还包括：

在所述第x个异常排除操作执行失败后，确定所述第x个异常排除操作的类型；

若所述第x个异常排除操作为所述第一类异常排除操作，根据执行所述第x个异常排除操作的结果，确定出所述第x+1异常排除操作；

若所述第x个异常排除操作为所述第二类异常排除操作，根据各类异常的出现概率，确定出所述第x+1异常排除操作。

可选地，所述方法还包括：

在执行所述第x个异常排除操作执行失败后，将所述第x+1异常排除操作的信息添加至栈中；

在所述第x个异常排除操作执行成功后，将所述第x个异常排除操作的信息从所述栈中移除；

其中，当前执行的异常排除操作为信息位于所述栈的顶部的异常排除操作。

根据本公开实施例的第二方面，提供一种脚本执行处理装置，包括：

记录模块，用于当时脚本执行过程中第n步骤运行失败时，记录所述第n步骤的信息，其中，所述n为正整数；

第一执行模块，用于根据所述第n步骤信息，执行第1个异常排除操作；

第二执行模块，用于在所述第1个异常排除操作执行成功后，重新执行所述第n步骤；

第三执行模块，用于在所述第x个异常排除操作执行失败后，执行到第x+1异常排除操作；所述x为大于等于1的整数；

返回模块，用于在所述第x+1个异常排除操作执行成功后，返回所述第x个异常排除操作的执行阶段。

可选地，所述装置还包括：

次数记录模块，用于记录各所述异常排除操作的执行次数；

确定次数模块，用于在异常排除失败时，确定各所述异常排除操作的执行次数是否达到预定次数；

确定执行模块，用于若有至少一个所述异常排除操作的执行次数未达到所述预定次数，执行未达到所述预定次数的所述异常排除操作。

可选地，所述异常排除操作包括：

第一类异常排除操作及第二类异常排除操作；

其中，所述第一类异常排除操作包括以下至少之一：

针对运行所述脚本的服务端内的异常排除操作；

针对所述服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作；

所述第二类异常排除操作包括：针对意外弹窗的异常排除操作。

可选地，所述装置还包括：

类型确定模块，用于在所述第x个异常排除操作执行失败后，确定所述第x个异常排除操作的类型；

第一确定模块，用于若所述第x个异常排除操作为所述第一类异常排除操作，根据执行所述第x个异常排除操作的结果，确定出所述第x+1异常排除操作；

第二确定模块，用于若所述第x个异常排除操作为所述第二类异常排除操作，根据各类异常的出现概率，确定出所述第x+1异常排除操作。

可选地，所述装置还包括：

第四执行模块，用于在执行所述第x个异常排除操作执行失败后，将所述第x+1异常排除操作的信息添加至栈中；在所述第x个异常排除操作执行成功后，将所述第x个异常排除操作的信息从所述栈中移除；其中，当前执行的异常排除操作为信息位于所述栈的顶部的异常排除操作。

根据本公开实施例的第三方面，提供另一种脚本执行处理装置，包括：

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：执行所述存储器中存储的可执行指令时，实现上述第一方面的任一项所述的方法。

根据本公开实施例的第四方面，提供一种非临时性计算机可读存储介质，当所述存储介质中的指令由脚本执行处理装置的处理器执行时，使得所述脚本执行处理装置能够执行上述第一方面的任一项所述的方法。

本公开的实施例提供的技术方案可以包括以下有益效果：

本公开实施例在脚本中的第n步骤运行失败后，针对第n步骤执行多种异常排除操作，在每个异常排除操作执行成功后，返回去执行上一次未成功的异常排除操作，以此来使得上一次未成功的异常排除操作也继续执行，直至成功，如此，可以在确定每个异常排除操作都成功的基础上，保证脚本执行处理的成功率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1为脚本录制意外的重试策略的流程示意图。

图2是根据一示例性实施例示出的一种脚本执行处理方法的流程图一。

图3为经脚本录制工具录制完成后的脚本在执行时的流程示意图。

图4为根据一示例性实施例示出的一种脚本执行处理方法的流程图二。

图5为第n步骤和2种异常排除操作在栈中的示意图。

图6为根据一示例性实施例示出的一种脚本执行处理方法的流程图三。

图7为第n步骤在栈中的示意图。

图8为第n步骤在栈中执行成功后栈内示意图。

图9(a)为服务端重启操作入栈的情况。

图9(b)为消除意外弹窗操作入栈的情况。

图10为ADB重连操作压入栈中后栈内示意图。

图11为服务端重启操作压入栈中后栈内示意图。

图12为基于图11的ADB重连操作压入栈中后栈内示意图。

图13是根据一示例性实施例示出的一种脚本执行处理装置的结构图。

图14是根据一示例性实施例示出的一种脚本执行处理装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在用来测试电子设备中应用程序的脚本录制过程中，常见的造成脚本录制执行意外失败的情况多为意外弹窗和安卓调试桥(Android Debug Bridge，ADB)的意外断开等。目前，大多数脚本录制工具对脚本步骤运行时的意外失败都进行了处理，以提高脚本录制执行的成功率。

图1为脚本录制意外的重试策略的流程示意图，在图1中展示了“原始步骤->消除弹窗策略->重连ADB”的循环重试策略。如图1所示，所述循环重试策略每次都是，先执行脚本中的原始步骤，当脚本中的原始步骤执行失败时，先尝试执行消除弹窗策略的步骤，若消除弹窗策略的步骤执行成功，则再一次执行原始步骤，若原始步骤成功，则脚本恢复到正常的运行流程，去执行原始步骤的下一个步骤；若消除弹窗策略的步骤执行失败，则执行重连ADB，重连ADB成功，则又执行原始步骤，依次循环。

从图1中可以看出，在每执行成功一个策略后，就会重新开始执行原始步骤，而再次执行原始步骤由于异常可能还存在，导致再次执行原始步骤仍会失败，导致需要花费更多的时间去排除异常，且也会增加系统消耗。

基于此，为了提高脚本执行处理的成功率，本公开实施例提供一种脚本执行处理方法，图2是根据一示例性实施例示出的一种脚本执行处理方法的流程图一，如图2所示，所述方法包括：

步骤101，当脚本执行过程中时第n步骤运行失败时，记录所述第n步骤的信息，其中，所述n为正整数；

步骤102，根据所述第n步骤信息，执行第1个异常排除操作；

步骤103，在所述第1个异常排除操作执行成功后，重新执行所述第n步骤；

步骤104，在所述第x个异常排除操作执行失败后，执行第x+1个异常排除操作；所述x为大于等于1的整数；

步骤105，在所述第x+1个异常排除操作执行成功后，返回所述第x个异常排除操作的执行阶段。

需要说明的是，在本公开实施例中，所述脚本执行处理方法具体涉及的是脚本执行失败后的重试方法。所述方法可以应用于安装有测试软件的电子设备，所述电子设备可以是电脑、服务器以及智能手机等。所述测试软件作为一种服务端软件，用于对客户端软件的正确性、完整性、安全性和质量等进行鉴定。为了确保应用程序的性能，在进入市场前，研发人员需要对应用程序进行反复又精细的测试。通过录制可执行的测试脚本，执行该测试脚本即可实现对应用程序的自动化测试。

关于脚本的录制，目前有多种基于框架的脚本录制工具，例如，基于马卡卡(Macaca)框架的脚本录制工具等。在基于各录制工具录制好脚本后，即可继续基于该录制工具中的功能模块执行该脚本对应用程序进行测试。

本公开实施例对脚本的录制，及基于录制好的脚本进行测试的执行工具的选取不作限定，一般而言，目前经脚本录制工具录制完成后的脚本在运行时的流程大致相同，如图3所示，图3为经脚本录制工具录制完成后的脚本，在执行时的流程示意图，在图3中，录制生成的脚本经脚本录制工具中的测试模块，向手机发送测试指令，手机接收到该测试指令之后执行相应操作。这里，脚本录制工具以及脚本属于服务端，具体而言，脚本执行处理的过程就是测试应用程序的过程，通过服务端向手机端的手机中的客户端应用程序发送测试指令，以此实现对应用程序测试。

如图3所示，在整个脚本执行处理的过程中在两处位置容易发生意外情况：(1)脚本录制工具内部出现的异常；(2)服务端与手机端通信出现的异常，即ADB断开。这里，所述脚本录制工具是一种服务端，用于对客户端提供服务，那么所述脚本录制工具内部出现的异常也称为运行所述脚本的服务端内的异常。所述手机端用于显示所述脚本执行处理结果。

需要说明的是，在脚本录制中，脚本录制工具(服务端)内部出现异常的发生概率是相较于意外弹窗是少一些的，且重启脚本录制工具就可解决该异常。同样的，在执行脚本时ADB断开也是较为少见的，一般而言ADB重连成功后，脚本便可恢复运行。那么，结合目前脚本执行处理中常见的关于系统权限的意外弹窗，在本公开实施例中将脚本执行处理中可能出现的异常情况分为4种：原始步骤异常、意外弹窗异常、运行所述脚本的服务端内的异常以及服务端与显示所述脚本执行处理结果的终端之间连接的异常。

对应的，在本公开实施例中，解决上述异常的方法就是对应的异常排除操作，所述异常排除操作包括：针对意外弹窗的异常排除操作、针对运行所述脚本的服务端内的异常排除操作以及针对服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作。这里，所述原始步骤异常是指本应该正常的步骤，在脚本执行时存在不正常而导致的输出失败；例如，假设原始步骤是：判断界面1上是否有相机这个应用图标，录制的时候界面1上是有相机这个应用程序的应用图标，但是在脚本执行时发现由于存在一些异常(如遮挡住了相机这个应用图标)，导致判断出界面1上有相机应用图标失败，如此认为原始步骤异常。

需要说明的是，针对意外弹窗的异常排除操作可以是消除意外弹窗操作，针对运行所述脚本的服务端内的异常排除操作可以是服务端重启操作，针对服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作可以是ADB重连操作。

如此，针对在脚本执行处理过程中可能出现的异常，进行本公开实施例提供的脚本执行处理方法的具体说明。在本公开实施例中，所述脚本中包含多个步骤，当脚本执行中第n步骤运行失败时，就记录所述第n步骤的信息。这里的第n步骤是指脚本执行处理中任一个执行失败的步骤，n为正整数。

所述记录所述第n步骤的信息可以是：在第n步骤执行失败后，记录所述第n步骤的内容；具体可以是将执行失败的所述第n步骤记录至栈中。由于第n步骤执行失败，为了脚本能够执行成功，需要排除异常以此实现第n步骤能够重新执行成功，进而所述脚本中的后续步骤可以继续进行。

在本公开实施例中，在记录所述第n步骤的信息后，会开始第1个异常排除操作的执行。所述第1个异常排除操作可以是：针对意外弹窗的异常排除操作，还可以是针对运行所述脚本的服务端内的异常排除操作或者针对所述服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作。

这里，当脚本中的步骤运行失败，如果系统并未抛出明确的异常指示，此时想要使该失败的脚本重新执行成功，就需要执行异常排出操作对异常进行排除。如此，所述第1个异常排除操作可以是按照设定的顺序来执行的异常排除操作中的第一个异常排除操作，所述设定顺序可以按照经验来确定，即脚本执行处理失败时最大概率可能发生的异常作为第一个异常排除操作针对的异常。

在本公开实施例中，先执行第1个异常排除操作(第x个异常排除操作，x为1)，如果所述第1个异常排除操作执行成功，则重新执行所述第n步骤。如果所述第1个异常排除操作执行失败，意味着异常还未解决，这时可能是其他异常导致的第1个异常排除操作执行异常，需要先解决其他异常才能使得异常得到解决；这时就进入到下一个异常排除操作(第x+1个异常排除操作，即第2个异常排除操作)的执行阶段，如果所述第2个异常排除操作执行成功，则重新回去执行所述第1个异常排除操作，如此在保证第2个异常执行成功的基础上，重新执行所述第1个异常排除操作，大概率第1个异常排除操作是可以成功执行；进一步地当重新执行的所述第1个异常排除操作执行成功，才去执行第n步骤。那么，由于保证了各异常排除操作的成功执行，使得第n步骤大概率可以执行成功，由此，可以尽可能地保证脚本执行处理的成功率。

这里，如果异常是上述提到的异常，那么第x个异常排除操作可为意外弹窗异常、运行所述脚本的服务端内的异常以及服务端与显示所述脚本执行处理结果的终端之间连接的异常中的一个。

如此，本公开实施例在脚本中的第n步骤运行失败后，针对第n步骤执行多种异常排除操作，在每个异常排除操作执行成功后，再返回去执行上一次未成功的异常排除操作，以此来使得上一次未成功的异常排除操作也继续执行，直至成功，如此，可以在确定每个异常排除操作都成功的基础上，保证脚本执行处理的成功率。

在一些实施例中，图4为根据一示例性实施例示出的一种脚本执行处理方法的流程图二，如图4所示，所述脚本执行处理方法还包括：

步骤106，记录各所述异常排除操作的执行次数；

步骤107，在异常排除失败时，确定各所述异常排除操作的执行次数是否达到预定次数；

步骤108，若有至少一个所述异常排除操作的执行次数未达到所述预定次数，执行未达到所述预定次数的所述异常排除操作。

需要说明的是，在上述步骤103中，如果第1个异常排除操作执行成功，则针对第1个异常排除操作的异常已得到解决，这时重新执行所述第n步骤，如果重新执行所述第n步骤再次失败，可能需要重新执行第1个异常排除操作。

考虑到如果要保证脚本中步骤运行成功，可能在脚本执行处理的过程中异常排除操作需要多次执行；而有的异常排除操作，如针对服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作(ADB重连操作)的执行较为耗费时间，不便于多次执行。但如果为了避免使用ADB重连操作，而不停地使用其他的异常排除操作来解决异常，可能会造成需要很多次循环执行各其他的异常排除操作才能保证脚本执行成功，且一旦手机自身出现异常，就会使得其他的异常排除操作的执行失败，继续下一异常排除操作的处理，而由于手机自身出现异常，所述下一异常排除操作也会执行失败，由此会导致各其他的异常排除操作的执行无法停止，所述脚本执行处理方法会陷入循环中。

基于此，为了在尽可能地不耗费时间，且也能尽快地让脚本执行成功，在本公开实施例中会对各所述异常排除操作的执行次数进行记录，并对各所述异常排除操作的执行次数进行限制。所述各所述异常排除操作的执行次数可以根据实验数据或异常的出现历史记录确定。

本公开实施例中，通过大量的测试验证，针对原始步骤异常的异常排除操作、针对意外弹窗的异常排除操作(消除意外弹窗操作)、针对运行所述脚本的服务端内的异常排除操作(服务端重启操作)的执行次数限制均为2次，而针对服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作(ADB重连操作)的限制执行次数为1次。如此，设置限制次数可确保脚本从意外状况恢复，也可避免因为手机异常使得所述脚本执行处理方法陷入循环，进而也提高了脚本执行处理的效率。

还需要说明的是，上述预定次数为经过大量实验后得出的结果，一般而言，当达到该预定次数可以极大概率实现脚本执行处理成功，当已达到该预定次数，但仍未将异常排除，可能是其他的问题，例如硬件问题。那么，为了提高执行效率，尽可能地减少不必要的重复执行，在本公开实施例中如果任一异常排除操作的执行次数满足预定次数时，也可停止执行，此时认为第n步骤执行异常。

在一些实施例中，所述脚本执行处理方法还包括：

当各所述异常排除操作的所述执行次数均达到预定次数时，停止所述异常排除操作，并确定所述第n步骤执行异常。

如上所述，由于设置限制次数可确保脚本从意外状况恢复，也可以尽可能地避免因为手机异常使得所述脚本执行处理方法陷入循环。那么，当每种异常排除操作的执行次数都达到预定次数，就直接停止所述异常排除操作，并确定所述第n步骤执行异常。

即按照预期，在执行完ADB重连后大概率是可以解决掉存在的异常；在此基础上，基于ADB重连再加上服务端重启操作和消除意外弹窗操作，再结合各自执行的次数就更加是可以解决异常，使脚本执行处理成功。但如此操作还未解决掉异常，就可能是其他问题导致的脚本执行失败，所述其他问题无法通过上述几类异常排除操作得到解决，重复执行异常排除操作没有意义，且会耗费时间。

对此，在本公开实施例中，当各所述异常排除操作所述执行次数均达到预定次数时，停止所述异常排除操作并确定所述第n步骤执行异常。如此，通过确定执行次数均达到预定次数来终止脚本中失败步骤的重试流程，确定出脚本中的第n步骤执行异常，可以在尽可能地节省重试时间，提供操作操作效率。

在一些实施例中，所述异常排除操作包括：

第一类异常排除操作及第二类异常排除操作；

如上所述，所述异常排除操作有多种，在本公开实施例中，为了尽可能地保证脚本执行成功，采用多种异常排除操作来对异常进行排除。

在本公开实施例中，考虑到第n步骤执行失败时，可能会出现两种情况，即：明确抛出异常和未明确抛出异常。所述未明确抛出异常是指未明确出异常原因，而明确抛出异常一般可以是意外弹窗等。当明确抛出了异常，就只需要根据抛出的异常执行对应的异常排除操作。当未明确抛出异常，就需要进行异常的排除，由于异常如果是出现在脚本录制工具(服务端)的内部，通过重启脚本录制工具就可解决该异常，且重启脚本录制工具并不需要耗费大量的时间，由此，本公开实施例可以先执行针对运行所述脚本的服务端内的异常排除操作来进行初步地排除。如此，在公开实施例中所述第一类异常排除操作可以包含2类异常，所述第一类异常排除操作包括以下之一：

针对运行所述脚本的服务端内的异常排除操作；

针对意外弹窗的异常排除操作。

这里，针对运行所述脚本的服务端内的异常排除操作就是未明确抛出异常时，初步进行的异常排除操作。针对意外弹窗的异常排除操作就是明确抛出异常时，所进行的异常排除操作。如此，通过为运行中出现的不同情况执行不同的异常排除操作，可以有针对性地进行异常的消除，提高异常的排查效率。并且利用了服务端重启操作可以解决掉大部分异常的特点，在未明确抛出异常时，将服务端重启操作作为第一类异常排除操作的一种情况，可以极大地提高异常排除效率，进而使得脚本执行处理效率也得到了相应地提高。

基于此，在本公开实施例中，若所述第一类异常排除操作为针对运行所述脚本的服务端内的异常排除操作，意味着此时未明确抛出异常，在未明确抛出异常，先进行针对运行所述脚本的服务端内的异常排除操作(服务端重启操作)，如果所述服务端重启操作失败，就进行针对所述服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作(ADB重连操作)。由于ADB重连可以极大概率地解决掉该异常，为异常的解决提供了保障。

需要说明的是，所述第二类异常排除操作包括：针对意外弹窗的异常排除操作。

若所述第1个异常排除操作为第二类异常排除操作，即针对意外弹窗的异常排除操作，意味着此时在执行第n步骤失败时明确抛出了异常；若执行到所述第二类异常排除操作，且所述第二类异常排除操作执行失败，则继续进行第x+2个异常排除操作，这时所述第x+2个异常排除操作可以是：针对所述服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作(ADB重连)，也可以是：针对运行所述脚本的服务端内的异常排除操作(服务端重启操作)。这里，利用ADB重连可以极大概率地解决掉异常的特点，极可能地解决掉异常，提高脚本执行处理的成功率。

在一些实施例中，所述脚本执行处理方法还包括：

步骤109，在所述第x个异常排除操作执行失败后，确定所述第x个异常排除操作的类型；

步骤110，若所述第x个异常排除操作为第一类异常排除操作，根据执行所述第x个异常排除操作的结果，确定出所述第x+1异常排除操作；

步骤111，若所述第x个异常排除操作为第二类异常排除操作，根据各类异常的出现概率，确定出所述第x+1异常排除操作。

如上所述，在本公开实施例中，对于不同类型的异常排除操作，对应出现的结果是不同的，如此会导致异常排除操作在执行失败后，后续的再执行的下一个异常排除操作的选择依据存在不同。

作为一个示例，若第x个异常排除操作为针对运行所述脚本的服务端内的异常排除操作的第一类异常排除操作；假设第x个异常排除操作执行失败，则导致它失败的原因可能是服务端与显示所述脚本执行处理结果的终端之间连接的异常，而不可能是意外弹窗；即不可能在第x个异常排除操作执行失败后，去执行消除意外弹窗操作会使得再次第x个异常排除操作就成功。换句话说，在所述第x个异常排除操作为第一类异常排除操作时，需要根据第一类异常排除操作的执行结果来确定后续再执行的异常排除操作。

若第x个异常排除操作为针对意外弹窗的异常排除操作的第二类异常排除操作，假设第x个异常排除操作执行失败，则导致它失败的原因可能是针对运行所述脚本的服务端内的异常排除操作，或者针对所述服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作。这时，对于导致是哪种，可以根据各类异常的出现概率来确定出下一个需要执行的异常排除操作。在所述第x个异常排除操作执行失败后，根据各类异常的出现概率，可以确定出根据各类异常的出现概率，即下一个异常排除操作。如此，可以尽可能快速地排除异常，提高脚本执行处理的效率。

这里通过各类异常的出现概率来确定出在所述第x个异常排除操作执行失败后，下一个异常排除操作该执行哪个，具体而言，就是出现概率越大的异常，就在第x个异常排除操作执行失败后执行。例如，如果所述第x个异常排除操作为针对意外弹窗的异常排除操作，而假设服务端内的异常的出现概率大于服务端与显示所述脚本执行处理结果的终端之间连接的异常，则确定出的所述第x+1个异常排除操作为针对运行所述脚本的服务端内的异常排除操作。

那么上述提出的设定的顺序就是按照各类异常的出现概率确定的顺序，而各类异常的出现概率可以根据经验来确定。例如，当消除意外弹窗失败，按照以往的经验判断此时大概率是服务器内部出现故障，那么，在执行异常排除操作时，就先执行针对运行所述脚本的服务端内的异常排除操作，即执行服务端重启操作。

如此，根据异常排除操作的类型，来针对不同的类型情况来确定出下一个该执行的异常排除操作，可以实现尽可能较快地解决掉异常，进而为脚本执行处理效率地提高打下了基础。

在一些实施例中，所述脚本执行处理方法还包括：

步骤112，在执行所述第x个异常排除操作执行失败后，将所述第x+1异常排除操作的信息添加至栈中；在所述第x个异常排除操作执行成功后，将所述第x个异常排除操作的信息从所述栈中移除；其中，当前执行的异常排除操作为信息位于所述栈的顶部的异常排除操作。

需要说明的是，这里，每个异常排除操作执行之前都需要进行入栈处理，而入栈的顺序决定了后续的执行顺序；即在执行所述第x个异常排除操作排除之前，需要将所述第x个异常排除操作的信息添加至栈中。为了使得各所述异常排除操作的执行顺序可以按照设定的顺序执行，提出了将所述异常排除操作依次添加到栈中的方式。利用栈中数据先进后出特点，来对本公开实施例中各异常排除操作的执行顺序进行限定，使得在一种异常排除操作失败时，继续去尝试下一种异常排除操作(即往栈中加入一种异常排除操作)，当所述下一种异常排除操作执行成功时，所述异常排除操作从栈中弹出，此时栈中的栈顶的异常排除操作为前一种执行失败的异常排除操作，如此，可以回去执行所述前一种异常排除操作。那么，将各所述异常排除操作添加入栈的方式可以保证异常排除操作的执行顺序，且让每个异常排除操作都尽可能地执行完全，尽可能地保证脚本的成功执行。

本公开实施例中为了使得每次一个异常排除操作执行成功后，不用直接去重新执行脚本中的原始步骤，即不用重新去执行第n步骤，增加原始步骤的执行次数；在执行各所述异常排除操作之前，将所述原始步骤添加至所述栈中。利用栈只允许在栈顶进行数据的插入和删除运算的特点，将本公开实施例中各异常排除操作和原始步骤的执行顺序得到了限定，使得每个异常排除操作执行成功后，继续去执行上一个未执行成功的异常排除操作，而不是原始步骤，在减少系统消耗的同时，也提高了执行效率。

图5为第n步骤和2种异常排除操作在栈中的示意图，如图5所示，在脚本中的第n步骤执行失败后，首先将脚本中的第n步骤入栈，再执行第1个异常排除操作：服务端重启操作，当服务端重启操作执行失败，则执行第2个异常排除操作：ADB重连操作。如此，由于设置在栈中，基于栈只允许在栈顶进行数据的运算的特点，使得ADB重连操作执行成功抛出后，再执行的就是服务端重启操作而不是去执行第n步骤。

同样的，ADB重连操作执行成功抛出后，如果再次执行服务端重启操作且再次失败，就可以将下一个异常排除操作添加至栈中，直至下一个异常排除操作执行成功，且服务端重启操作可以在预定次数内也执行成功，才会去执行第n步骤。如此，极大地减少了第n步骤的执行次数，也进而较少了系统消耗，减少了执行时间，提高了执行效率。

需要说明的是，为了实现各所述异常排除操作的执行顺序可以按照设定的顺序执行，且减少第n步骤的执行次数，除了使用栈结构还可以使用链表结构，即：使用具备有运算顺序的数据存储结构来执行上述异常排除操作。通过栈或者链表等限制了运算顺序的线性表来保证各所述异常排除操作和第n步骤的执行顺序，减少各步骤的执行次数，由此实现极大地提高执行效率。

这里，结合图6、图7、图8、图9(a)、图9(b)、图10、图11和图12对本公开实施例中的脚本执行处理方法进行下述的综合说明：

图6为根据一示例性实施例示出的一种脚本执行处理方法的流程图三，如图6所示，在脚本的运行中，当第n步骤运行失败，就将第n步骤入栈，此时所述栈中只有所述第n步骤，如图7所示，图7为第n步骤在栈中的示意图。在图7中所述该栈的栈顶元素即为第n步骤，这时执行栈顶元素，若所述第n步骤执行成功，我们则将所述第n步骤从栈顶弹出，继续执行下一个步骤，那么，此时栈内情况如图8所示，图8为第n步骤在栈中执行成功后栈内示意图，在图8中，所述栈为空栈。

若所述第n步骤执行失败，首先判断所述第n步骤的执行次数是否大于2次，如果所述第n步骤的执行次数大于2次，认为是第n步骤运行异常，则流程结束；如果所述第n步骤的执行次数小于或等于2次，则根据执行第n步骤抛出的异常执行相应的入栈计划，这里，可能直接抛出了意外弹窗异常，也可能未明确异常，从运行所述脚本的服务端内的异常开始尝试解决办法。如此存在2种栈的可能顺序，即如图9(a)所示的情况一：在第n步骤后，将服务端重启操作入栈；或者即如图9(b)所示的情况二，在第n步骤后，将消除意外弹窗操作入栈。

如图9(a)所示，对于服务端重启操作入栈的情况(图6中的情况一)，在服务端重启操作入栈后，获取栈顶元素来执行栈顶元素，由于此时栈顶元素为服务端重启操作，则执行服务端重启操作。若服务端重启操作执行成功(情况一)，则将服务端重启操作从栈顶弹出，服务端重启操作从栈顶弹出后发现此时栈顶元素为第n步骤，如此只需重复上图7的情况即可，即执行第n步骤。若服务端重启操作执行失败，就先判断服务端重启操作的执行次数，如果服务端重启操作的执行次数小于等于2次，考虑到脚本执行的成功率和执行效率，将ADB重连操作压入栈中。如果服务端重启操作的执行次数大于2次，考虑到执行效率，认为异常无法排除，第n步骤运行异常，退出程序。

所述ADB重连操作压入栈中后，所述栈中元素如图10所示，在图10中此时栈顶元素为ADB重连操作。在ADB重连操作中，由于ADB重连操作的执行时间较长，为了避免过长的等待，在本公开实施例中，对所述ADB重连操作的执行时间设置在预定的时间，所述预定时间可以根据实际需要来设置，例如，可以相对较长的等待就将所述预定的时间较长一些。在本公开实施例中，将所述预定的时间设置为60秒。在意外情况下60秒足以使得ADB完成重连。如果ADB重连时间超出60秒，则认为ADB重连操作执行失败，抛出ADB重连操作运行异常，认为第n步骤运行异常，退出程序。若ADB重连操作成功，则将ADB重连操作从栈顶弹出，此时栈顶元素为服务端重启操作，之后只需重复执行如上图9(a)的情况即可，即执行服务端重启操作。如此，直至服务端重启操作的执行次数达到预设次数，或者服务端重启操作成功，则继续执行第n步骤，进而如果第n步骤执行成功，则执行脚本中的第n+1步骤，如果第n步骤执行次数大于2次，则认为第n步骤运行异常，退出程序。

需要说明的是，由于ADB重连操作的执行时间相对来说较长，在本公开实施例中，对于ADB重连操作的执行次数设置为1次。实际操作中，在执行ADB重连操作之前，需要判断它的执行次数。

如图9(b)所示，对于消除意外弹窗操作入栈的情况(图6中的情况二)，在消除意外弹窗操作入栈后，获取栈顶元素来执行栈顶元素，由于此时栈顶元素为消除意外弹窗操作，则执行消除意外弹窗操作。若消除意外弹窗操作执行成功，则消除了意外弹窗，那么将消除意外弹窗操作从栈顶弹出，此时发现栈顶元素为第n步骤，则重复如上图7的情况即可，即执行第n步骤。

若消除意外弹窗操作执行失败，则先判断消除意外弹窗操作的执行次数，如果消除意外弹窗操作的执行次数小于等于2次，考虑到系统抛出异常情况和脚本执行的成功率和执行效率，将服务端重启操作压入栈中，此时栈内情况如图11所示。如果消除意外弹窗操作的执行次数大于2次，考虑到执行效率，认为异常无法排除，第n步骤运行异常，退出程序。

在图11中，此时服务端重启操作位于栈顶，执行栈顶的服务端重启操作，若服务端重启操作执行成功(情况二)，则将服务端重启操作从栈顶弹出，此时栈顶元素为消除意外弹窗操作，则重复图9(b)的情况，去执行消除意外弹窗操作；若服务端重启操作执行失败，则先判断服务端重启操作的执行次数，如果服务端重启操作的执行次数小于等于2次，则将ADB重连操作压入栈中，如图12所示，此时ADB重连操作位于栈顶。如果服务端重启操作的执行大于2次，认为异常无法排除，第n步骤运行异常，退出程序。

在图12中，ADB重连操作位于栈顶，即继续执行栈顶元素ADB重连操作，如果ADB重连操作的执行时间超出60秒，则ADB重连操作执行失败，认为异常无法排除，第n步骤运行异常，退出程序。若ADB重连操作执行成功，则将ADB重连操作从栈顶弹出，发现此时栈顶元素为服务端重启操作，则重复图11的情况即可，即执行服务端重启操作。

需要说明的是，本公开实施例的脚本执行处理方法可通过如下代码实现：

其中，handleRetries表示重试方法，其中items指存储四种异常排除操作的栈，fetchPromise指第n步骤中的具体执行操作，result表示执行结果。move表示执行的栈顶元素对象，run表示栈顶元素对象的执行方法，condition表示栈顶元素对象执行失败时的抛出的异常是否满足条件，条件可以是满足macaca框架的异常或者ADB断开的异常等等，若满足条件则items栈新压入move对象next方法指向的对象，否则抛出异常，令脚本中第n步骤执行失败。这里，所述异常排除操作可基于如下代码实现：

/>

其中，每一个XXXStep表示一个异常排除操作，所述操作拥有run方法，condition方法，next方法和times变量。run方法用于执行该异常排除操作的任务，消除意外弹窗操作的run方法是执行消除弹窗任务，服务端重启操作的run方法是执行服务端重启的任务，ADB重连操作的run方法是执行ADB重连的任务。condition方法用于判断当XXXStep失败后是执行其他异常排除操作还是执行抛出异常退出脚本。next方法是指XXXStep模块对应的下一个异常排除操作，times变量是指该异常排除操作最多执行的次数。当脚本中的某个步骤运行意外失败后，通过上述的基于栈结构的重试模型可恢复脚本中意外失败的步骤，并使脚本恢复到之前正常的运行流程，使得脚本继续正常运行，保证脚本的执行成功率。针对其他框架开发的脚本录制工具，该重试模型也可适用，不限制于脚本录制工具的实现框架。

如此，在脚本中的步骤执行失败时，就通过不同的异常排除操作去排除异常，即采取一系列逐层递进的方式去排查和恢复的步骤，当第一种异常排除操作失败时会将下一种异常排除操作压入栈，当对应的异常排除操作有效时，会将对应的异常排除操作弹出栈顶，进而执行未成功的异常排除操作，直到栈为空为止，当栈为空时表示可以继续执行脚本中第n步骤的下一步骤。如此，利用逐层递进的方式，通过多种异常排除操作去实现异常的排除，极大地保证脚本执行成功率。

为了提高脚本执行处理的成功率，本公开实施例还提供一种脚本执行处理装置，图13是根据一示例性实施例示出的一种脚本执行处理装置的结构图，如图13所示，所述脚本执行处理装置600，包括：

记录模块601，用于当脚本执行时第n步骤运行失败时，记录所述第n步骤的信息，其中，所述n为正整数；

第一执行模块602，用于根据所述第n步骤信息，执行第1个异常排除操作；

第二执行模块603，用于在所述第1个异常排除操作执行成功后，重新执行所述第n步骤；

第三执行模块604，用于在所述第x个异常排除操作执行失败后，执行到第x+1异常排除操作；所述x为大于等于1的整数；

返回模块605，用于在所述第x+1个异常排除操作执行成功后，返回所述第x个异常排除操作的执行阶段。

在一些实施例中，所述装置还包括：

次数记录模块，用于记录各所述异常排除操作的执行次数；

确定次数模块，用于在异常排除失败时，确定各所述异常排除操作的执行次数是否达到预定次数；

确定执行模块，用于若有至少一个所述异常排除操作的执行次数未达到所述预定次数，执行未达到所述预定次数的所述异常排除操作。

在一些实施例中，所述装置还包括：

确定停止模块，用于当各所述异常排除操作所述执行次数均达到预定次数时，停止异常排除处理并确定所述第n步骤执行异常。

在一些实施例中，所述异常排除操作包括：

第一类异常排除操作及第二类异常排除操作；

其中，所述第一类异常排除操作包括以下至少之一：

针对运行所述脚本的服务端内的异常排除操作；

针对所述服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作；

所述第二类异常排除操作包括：针对意外弹窗的异常排除操作。

在一些实施例中，所述装置还包括：

类型确定模块，用于在所述第x个异常排除操作执行失败后，确定所述第x个异常排除操作的类型；

第一确定模块，用于若所述第x个异常排除操作为第一类异常排除操作，根据执行所述第x个异常排除操作的结果，确定出所述第x+1异常排除操作；

第二确定模块，用于若所述第x个异常排除操作为第二类异常排除操作，根据各类异常的出现概率，确定出所述第x+1异常排除操作。

在一些实施例中，所述装置还包括：

第四执行模块，用于在执行所述第x个异常排除操作执行失败后，将所述第x+1异常排除操作的信息添加至所述栈中；在所述第x个异常排除操作执行成功后，将所述第x个异常排除操作的信息从栈中移除；其中，当前执行的异常排除操作为信息位于所述栈顶的异常排除操作。

如此，在脚本中的步骤执行失败时，就通过不同的异常排除操作去排除异常，即采取一系列逐层递进的方式去排查和恢复的步骤，当第一种异常排除操作失败时会将下一种异常排除操作压入栈，当对应的异常排除操作有效时，会将对应的异常排除操作弹出栈顶，进而执行未成功的异常排除操作，直到栈为空为止，当栈为空时表示可以继续执行脚本中第n步骤的下一步骤。如此，利用逐层递进的方式，通过多种异常排除操作去实现异常的排除，极大地保证脚本执行成功率。

图14是根据一示例性实施例示出的一种脚本执行处理装置800的框图。例如，装置800可以是移动电话、计算机、数字广播终端、消息收发设备、游戏控制台、平板设备、医疗设备、健身设备、个人数字助理等。

参照图14，装置800可以包括以下一个或多个组件：处理组件802，存储器804，电力组件806，多媒体组件808，音频组件810，输入/输出(I/O)接口812，传感器组件814，以及通信组件816。

处理组件802通常控制装置800的整体操作，诸如与显示、电话呼叫、数据通信、相机操作和记录操作相关联的操作。处理组件802可以包括一个或多个处理器820来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件802还可以包括一个或多个模块，便于处理组件802和其他组件之间的交互。例如，处理组件802可以包括多媒体模块，以方便多媒体组件808和处理组件802之间的交互。

存储器804被配置为存储各种类型的数据以支持在装置800的操作。这些数据的示例包括用于在装置800上操作的任何应用程序或方法的指令、联系人数据、电话簿数据、消息、图片、视频等。存储器804可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)、电可擦除可编程只读存储器(EEPROM)、可擦除可编程只读存储器(EPROM)、可编程只读存储器(PROM)、只读存储器(ROM)、磁存储器、快闪存储器、磁盘或光盘。

电力组件806为装置800各种组件提供电力。电力组件806可以包括：电源管理系统，一个或多个电源，及其他与为装置800生成、管理和分配电力相关联的组件。

多媒体组件808包括在所述装置800和用户之间提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件808包括一个前置摄像头和/或后置摄像头。当装置800处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和/或后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件810被配置为输出和/或输入音频信号。例如，音频组件810包括一个麦克风(MIC)，当装置800处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器804或经由通信组件816发送。在一些实施例中，音频组件810还包括一个扬声器，用于输出音频信号。

I/O接口812为处理组件802和外围接口模块之间提供接口，上述外围接口模块可以是键盘、点击轮、按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件814包括一个或多个传感器，用于为装置800提供各个方面的状态评估。例如，传感器组件814可以检测到装置800的打开/关闭状态、组件的相对定位，例如所述组件为装置800的显示器和小键盘，传感器组件814还可以检测装置800或装置800一个组件的位置改变，用户与装置800接触的存在或不存在，装置800方位或加速/减速和装置800的温度变化。传感器组件814可以包括接近传感器，被配置为在没有任何的物理接触时检测附近物体的存在。传感器组件814还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件814还可以包括加速度传感器、陀螺仪传感器、磁传感器、压力传感器或温度传感器。

通信组件816被配置为便于装置800和其他设备之间有线或无线方式的通信。装置800可以接入基于通信标准的无线网络，如WiFi、2G或3G，或它们的组合。在一个示例性实施例中，通信组件816经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件816还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术、超宽带(UWB)技术、蓝牙(BT)技术或其他技术来实现。

在示例性实施例中，装置800可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器804，上述指令可由装置800的处理器820执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

一种非临时性计算机可读存储介质，当所述存储介质中的指令由脚本执行处理装置的处理器执行时，使得脚本执行处理装置能够执行上述实施例所述的脚本执行处理方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种脚本执行处理方法，其特征在于，包括：

当脚本执行过程中第n步骤执行失败时，记录所述第n步骤的信息，其中，所述n为正整数；

根据所述第n步骤信息，执行第1个异常排除操作；

在所述第1个异常排除操作执行成功后，重新执行所述第n步骤；

在第x个异常排除操作执行失败后，执行第x+1个异常排除操作；所述x为大于等于1的整数；其中，所述异常排除操作包括：第一类异常排除操作及第二类异常排除操作；

所述在第x个异常排除操作执行失败后，执行第x+1个异常排除操作，包括：

在所述第x个异常排除操作执行失败后，确定所述第x个异常排除操作的类型；

若所述第x个异常排除操作为所述第一类异常排除操作，根据执行所述第x个异常排除操作的结果，确定出所述第x+1异常排除操作；

若所述第x个异常排除操作为所述第二类异常排除操作，根据各类异常的出现概率，确定出所述第x+1异常排除操作；

在所述第x+1个异常排除操作执行成功后，返回所述第x个异常排除操作的执行阶段。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

记录各所述异常排除操作的执行次数；

在异常排除失败时，确定各所述异常排除操作的执行次数是否达到预定次数；

若有至少一个所述异常排除操作的执行次数未达到所述预定次数，执行未达到所述预定次数的所述异常排除操作。

3.根据权利要求1至2任一项所述的方法，其特征在于，所述第一类异常排除操作包括以下至少之一：

针对运行所述脚本的服务端内的异常排除操作；

针对所述服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作；

所述第二类异常排除操作包括：针对意外弹窗的异常排除操作。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在执行所述第x个异常排除操作执行失败后，将所述第x+1异常排除操作的信息添加至栈中；

在所述第x个异常排除操作执行成功后，将所述第x个异常排除操作的信息从所述栈中移除；

其中，当前执行的异常排除操作为信息位于所述栈的顶部的异常排除操作。

5.一种脚本执行处理装置，其特征在于，包括：

记录模块，用于当脚本执行过程中第n步骤运行失败时，记录所述第n步骤的信息，其中，所述n为正整数；

第一执行模块，用于根据所述第n步骤信息，执行第1个异常排除操作；

第二执行模块，用于在所述第1个异常排除操作执行成功后，重新执行所述第n步骤；

第三执行模块，用于在第x个异常排除操作执行失败后，执行到第x+1异常排除操作；所述x为大于等于1的整数；其中，所述异常排除操作包括：第一类异常排除操作及第二类异常排除操作；

所述第三执行模块，包括：

类型确定模块，用于在所述第x个异常排除操作执行失败后，确定所述第x个异常排除操作的类型；

第一确定模块，用于若所述第x个异常排除操作为所述第一类异常排除操作，根据执行所述第x个异常排除操作的结果，确定出所述第x+1异常排除操作；

第二确定模块，用于若所述第x个异常排除操作为所述第二类异常排除操作，根据各类异常的出现概率，确定出所述第x+1异常排除操作；

返回模块，用于在所述第x+1个异常排除操作执行成功后，返回所述第x个异常排除操作的执行阶段。

6.根据权利要求5所述的装置，其特征在于，所述装置还包括：

次数记录模块，用于记录各所述异常排除操作的执行次数；

确定次数模块，用于在异常排除失败时，确定各所述异常排除操作的执行次数是否达到预定次数；

确定执行模块，用于若有至少一个所述异常排除操作的执行次数未达到所述预定次数，执行未达到所述预定次数的所述异常排除操作。

7.根据权利要求5至6任一项所述的装置，其特征在于，所述第一类异常排除操作包括以下至少之一：

针对运行所述脚本的服务端内的异常排除操作；

针对所述服务端与显示所述脚本执行处理结果的终端之间连接的异常排除操作；

所述第二类异常排除操作包括：针对意外弹窗的异常排除操作。

8.根据权利要求5所述的装置，其特征在于，所述装置还包括：

第四执行模块，用于在执行所述第x个异常排除操作执行失败后，将所述第x+1异常排除操作的信息添加至栈中；在所述第x个异常排除操作执行成功后，将所述第x个异常排除操作的信息从所述栈中移除；其中，当前执行的异常排除操作为信息位于所述栈的顶部的异常排除操作。

9.一种脚本执行处理装置，其特征在于，包括：

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：执行所述存储器中存储的可执行指令时，实现权利要求1至4任一项所述的方法。

10.一种非临时性计算机可读存储介质，当所述存储介质中的指令由脚本执行处理装置的处理器执行时，使得所述脚本执行处理装置能够执行权利要求1至4任一项所述的方法。