CN110502366A - 案例执行方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本发明涉及研发管理技术领域，公开了一种案例执行方法，通过对设备的案例信息的查询得到案例的执行情况来确定案例的执行状态，然后根据执行状态查询对应的故障原因，然后获取到执行故障的案例所在的节点位置，基于上述获取到的信息来生成一个案例执行日志，基于案例执行日志中记载的信息来选择对案例的执行控制，选择的继续执行还是重启执行。本发明还公开了一种案例执行装置、设备及计算机可读存储介质，本发明根据节点位置和上下文数据安排案例的自动重启操作，从而降低了***对案例执行的控制难度，同时也实现了对案例执行失败时的继续执行控制，而继续执行可以节省了案例的执行控制时间，也提高了案例执行的成功率。

Description

案例执行方法、装置、设备及计算机可读存储介质

技术领域

本发明涉及研发管理技术领域，尤其涉及一种案例执行方法、装置、设备及计算机可读存储介质。

背景技术

目前对于案例的执行控制方式中，经常会由于各种原因使得案例在执行过程中出现失败或者是暂停，对于这种情况，现有技术中的解决方案是对案例进行执行失败重跑、失败继续重跑、选择性暂停重跑等操作，但是实现上述重跑的操作大多数都是通过人为检查和人为控制是否继续执行，而对于无法实现继续的案例，则会进行案例的重启，重新对案例进行执行，这样的案例控制执行方式，是非常消耗人力资源的，不利于目前的智能化的发展要求。

发明内容

本发明的主要目的在于提供一种案例执行方法、装置、设备及计算机可读存储介质，旨在解决由于现有的案例执行控制方式中，对于故障案例的控制过于耗时的技术问题。

为实现上述目的，本发明提供一种案例执行方法，所述案例执行方法包括以下步骤：

获取设备上已执行或者正在执行的案例信息，根据所述案例信息检查案例的执行情况，以确定所述案例是否处于故障执行状态；

若所述案例处于故障执行状态，则根据所述故障执行状态，从预置的故障执行状态与故障原因对应的关系表中，查询出所述案例在当前故障执行状态对应的故障原因；

获取所述案例在当前故障执行状态时的节点位置，并基于所述故障原因和所述节点位置生成案例执行日志，其中，在所述案例执行日志中还包括记录所述案例的故障是否已处理的标识信息；

根据所述案例执行日志中的标识信息判断与所述故障原因对应的故障是否被排除；

若判断所述故障已被排除，则将所述案例执行日志中记录的节点位置作为所述案例执行的起点，并将所述案例信息重新加载至所述设备的案例执行单元中，以所述起点为执行点继续执行所述案例；

若判断所述故障未被排除，则将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理。

可选的，所述基于所述故障原因和所述节点位置生成案例执行日志包括：

获取所述案例执行日志的模板信息，所述模板信息为记录所述案例在执行情况和所产生的信息的表格；

获取所述节点位置所对应的执行代码，以及所述节点位置的上下文信息；

将所述节点位置的执行代、所述故障原因和所述上下文信息记录在所述表格中，以形成案例执行日志，其中，所述上下文信息包括cookie、登陆态、变量和时间戳中的至少一种。

可选的，所述故障执行状态包括执行中断状态和执行失败状态；

所述获取所述案例在当前故障执行状态时的节点位置，并基于所述故障原因和所述节点位置生成案例执行日志包括：

判断所述故障执行状态是否为执行中断状态；

若判断为所述执行中断状态，则获取所述案例执行被中断所在的节点位置，将所述节点位置记录至所述案例执行日志中；

若判断不是所述执行中断状态，则判断所述故障执行状态是否满足所述执行失败状态的条件；

若判断满足所述执行失败状态的条件，则确定造成所述案例执行失败的故障原因，以及导致所述案例执行失败所在的节点位置，将所述故障原因和所述节点位置记录至所述案例执行日志中。

可选的，所述确定造成所述案例执行失败的故障原因包括：

检测所述案例执行单元在执行所述案例过程中，是否存在有执行优先级设置的新案例被启动；

检测执行所述案例对应的工作环境是否出现了变化，其中，所述工作环境包括所述设备的配置项、所述设备的服务器、所述案例执行的测试场景和所述设备所使用的网络；

检测所述案例是否是由于非功能问题导致的执行失败，其中，所述非功能问题为不是由所述设备的软件配置或者硬件配置所引起的故障。

可选的，在所述检测到存在有执行优先级设置的新案例被启动之后，所述案例执行方法还包括：

判断所述新案例的执行优先级是否大于当前执行的案例的执行优先级；

若是，则判断所述新案例与当前执行的案例是否为同一类型的案例；

若是同一类型的案例，则将所述新案例替换当前执行的案例，并执行所述新案例；

若不是同一类型的案例，则将当前执行的案例设置为执行中断状态或者执行失败状态，并跳转至所述新案例执行，待所述新案例执行完成后，返回至设置为执行中断状态或者执行失败状态的案例继续执行。

可选的，所述将所述案例执行日志中记录的节点位置作为所述案例执行的起点，并将所述案例信息重新加载至所述设备的案例执行单元中，以所述起点为执行点继续执行所述案例包括：

若所述故障执行状态为执行失败状态，则通过反射获取到所述执行失败状态的所述案例的类名和方法名；

根据所述类名和方法名从所述案例执行日志中读取所述上下文信息，并调用案例执行失败处理策略对所述执行失败状态的案例进行重启操作。

可选的，在所述将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理的步骤之前，还包括：根据所述故障原因对所述案例进行类型划分；

所述将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理包括：

根据所述案例的类型从所述设备中选择对应的案例缓存区；

将待重新加载的所述案例信息加载至所述案例缓存区中等待所述案例执行单元的调取执行。

此外，为实现上述目的，本发明还一种一种案例执行装置，所述案例执行装置包括：

监测模块，用于获取设备上已执行或者正在执行的案例信息，根据所述案例信息检查案例的执行情况，以确定所述案例是否处于故障执行状态；

查询模块，用于在所述案例处于故障执行状态时，根据所述故障执行状态，从预置的故障执行状态与故障原因对应的关系表中，查询出所述案例在当前故障执行状态对应的故障原因；

记录模块，用于获取所述案例在当前故障执行状态时的节点位置，并基于所述故障原因和所述节点位置生成案例执行日志，其中，在所述案例执行日志中还包括记录所述案例的故障是否已处理的标识信息；

判断模块，用于根据所述案例执行日志中的标识信息判断与所述故障原因对应的故障是否被排除；

处理模块，用于在判断所述故障已被排除时，将所述案例执行日志中记录的节点位置作为所述案例执行的起点，并将所述案例信息重新加载至所述设备的案例执行单元中，以所述起点为执行点继续执行所述案例；以及在判断所述故障未被排除时，将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理。

可选的，所述记录模块包括采集子单元和日志生成子单元；

所述采集子单元用于获取所述案例执行日志的模板信息，所述模板信息为记录所述案例在执行情况和所产生的信息的表格；以及获取所述节点位置所对应的执行代码，以及所述节点位置的上下文信息；

所述日志生成子单元，用于将所述节点位置的执行代、所述故障原因和所述上下文信息记录在所述表格中，以形成案例执行日志，其中，所述上下文信息包括cookie、登陆态、变量和时间戳中的至少一种。

可选的，所述故障执行状态包括执行中断状态和执行失败状态；所述记录模块包括检测子单元、和记录子单元

所述检测子单元，用于判断所述故障执行状态是否为执行中断状态；

所述记录子单元，用于在判断为所述执行中断状态时，获取所述案例执行被中断所在的节点位置，将所述节点位置记录至所述案例执行日志中；

所述检测子单元，用于在判断不是所述执行中断状态时，判断所述故障执行状态是否满足所述执行失败状态的条件；

所述记录子单元，用于在判断满足所述执行失败状态的条件时，确定造成所述案例执行失败的故障原因，以及导致所述案例执行失败所在的节点位置，将所述故障原因和所述节点位置记录至所述案例执行日志中。

可选的，所述记录子单元用于检测所述案例执行单元在执行所述案例过程中，是否存在有执行优先级设置的新案例被启动；检测执行所述案例对应的工作环境是否出现了变化，其中，所述工作环境包括所述设备的配置项、所述设备的服务器、所述案例执行的测试场景和所述设备所使用的网络；检测所述案例是否是由于非功能问题导致的执行失败，其中，所述非功能问题为不是由所述设备的软件配置或者硬件配置所引起的故障。

可选的，所述判断模块还用于判断所述新案例的执行优先级是否大于当前执行的案例的执行优先级；若是，则判断所述新案例与当前执行的案例是否为同一类型的案例；

在判断是同一类型的案例时，将所述新案例替换当前执行的案例，并执行所述新案例；

所述处理模块，用于在判断不是同一类型的案例时，将当前执行的案例设置为执行中断状态或者执行失败状态，并跳转至所述新案例执行，待所述新案例执行完成后，返回至设置为执行中断状态或者执行失败状态的案例继续执行。

可选的，若所述故障执行状态为执行失败状态，所述处理模块用于通过反射获取到所述执行失败状态的所述案例的类名和方法名；根据所述类名和方法名从所述案例执行日志中读取所述上下文信息，并调用案例执行失败处理策略对所述执行失败状态的案例进行重启操作。

可选的，所述案例执行装置还包括分类模块，用于根据所述故障原因对所述案例进行类型划分；

所述处理模块用于根据所述案例的类型从所述设备中选择对应的案例缓存区；将待重新加载的所述案例信息加载至所述案例缓存区中等待所述案例执行单元的调取执行。

此外，为实现上述目的，本发明还一种案例执行设备，所述案例执行设备包括：存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的案例执行程序，所述案例执行程序被所述处理器执行时实现如上述任一项所述的案例执行方法的步骤。

此外，为实现上述目的，本发明还一种计算机可读存储介质，所述计算机可读存储介质上存储有案例执行程序，所述案例执行程序被处理器执行时实现如上述任一项所述的案例执行方法的步骤。

本发明通过对案例执行失败的原因的检测，并在对检测到的原因进行分类，同时记录执行失败的节点位置和节点对应的上下文数据，在解决了的执行失败的原因后，根据节点位置和上下文数据安排案例的自动重启操作，基于这种记录和自动重启的方式来实现对案例的重跑控制，从而降低了***对案例执行的控制难度，同时也实现了对案例执行失败时的继续执行控制，与现有的案例重新执行的方式相比，继续执行可以节省了案例的执行时间，也提高了案例执行的成功率。

附图说明

图1为本发明提供的案例执行方法第一实施例的流程示意图；

图2为本发明提供的案例执行方法第二实施例的流程示意图；

图3为本发明实施例方案涉及的服务器运行环境的结构示意图；

图4为本发明提供的案例执行装置一实施例的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

在本发明提出的案例执行控制方式，可以通过移动设备来实现的，该移动设备的物理实现可以是智能手机、平板、特殊功能的设备等，也可以是案例执行***来实现，该***的物理实现可以是个人计算机(PC)、服务器等，基于这样的硬件结果，提出本发明案例执行方法的各个实施例，为描述方便，该设备以服务器为例进行说明。

参照图1，图1为本发明实施例提供的案例执行方法的流程图。在本实施例中，所述案例执行方法具体包括以下步骤：

步骤S110，获取设备上已执行或者正在执行的案例信息，根据所述案例信息检查案例的执行情况，以确定所述案例是否处于故障执行状态；

在该步骤中，所述案例可以理解为是测试案例，也可以理解为是***或者设备上的某种功能代码的执行过程或者是测试过程，甚至还可以是应用程序和数据处理的案例等等，在实际应用中，所述案例可以是包括多个案例的集合。

对于这里的获取动作，具体实现可以是从***或者设备上的代码执行池中采集，也可以是从启动的应用管理后台中读取。

在该步骤中，具体是采集设备中对于案例的实时执行情况，所述实时执行情况包括正常执行和故障执行两种状态，其中故障执行状态可以理解为是案例被中断执行、停止执行、临时暂停执行，甚至是重跑执行。

当然在实际应用中，对于实时的案例执行情况获取，其就是设备上正在执行的案例进行监控获取其案例在执行过程的所产生的信息；而对于已执行的案例信息的获取，则是可以从案例执行日志记录中进行获取，一般的设备在案例的执行中都会对一定时间段上的案例进行短期的记录。

在本实施例中，对于故障的监控具体是通过监控案例执行过程中生成的工作日志文件中的记录，通过监控比对工作日志文件中的每条工作日志是否正确，并计算不正确的工作日志，直到计算的工作日志数量大于预设值时，则认为该案例的执行出现了故障，或者是停止、暂停等等。

步骤S120，若所述案例处于故障执行状态，则根据所述故障执行状态，从预置的故障执行状态与故障原因对应的关系表中，查询出所述案例在当前故障执行状态对应的故障原因；

步骤S130，获取所述案例在当前故障执行状态时的节点位置，并基于所述故障原因和所述节点位置生成案例执行日志，其中，在所述案例执行日志中还包括记录所述案例的故障是否已处理的标识信息；

在本实施例中，对于上述故障原因包括***上的非功能问题、工作环境等等因素，该非功能问题应当理解为是非***缺陷所导致的问题，例如环境问题，即是******的一些配置项配置错误、某些***的服务器正在重启、某些***正在测试场景异常、某些网络故障等等。

在实际应用中，对于案例的执行情况的检查，具体可以通过以下方式来实现：

首先，在开发该案例时，针对每个案例中的每条执行语句中都设置有测试语句，将所有测试语句组合起来得到一个案例的测试程序，而该程序在执行该案例的同时会自行启动，通过这些测试语句对案例的执行情况进行监控和记录。

在实际应用中，而每个语句的执行基本上是反应为“真”或者“假”值，通过判断这些语句的“真”、“假”值来实现对案例的每个案例语句的执行状况进行检测，从而判断案例是否存在故障。

若检查到存在语句故障时，则获取该案例中故障对应的语句，分析该语句在案例中的执行功能，从而来确定该故障数据哪种故障执行状态，并且根据该语句的故障经验或者故障排查历史来综合判断导致该故障的主要原因，例如该语句的主要功能是实现数据调取的路径映射，那么一般来说导致该语句无法执行的原因就是映射的路径信息不存在或者路径信息不正确，由此可见其故障的原因为路径信息不正确，并进行路径信息不正确的标记。

在分析出原因后，从监控的工作日志文件中提取故障点的位置，并将该位置作为故障的节点位置；

基于该节点位置，确定案例执行代码中的节点代码位置；

将该代码位置上的代码以及该代码位置前后的代码数据(即是上下文数据)记录下来生成一个执行日志。

在实际应用中，一般一个案例对应一个工作日志文件，而工作日志文件在记录案例执行情况时，是按照案例的语句执行的顺序来进行记录，在记录过程中会对语句在执行过程的所有状态信息和需要应用的信息，以及故障标注都进行记录，通过处理器对工作日志文件的解析，遍历每个语句所执行时产生的数据进行检查比对来确定是否存在故障的标注，若存在，则获取该标注以及该标注对应的语句所在案例语句中的位置，从而确定故障的节点位置，进一步的，将故障的标注、案例的信息、标注所在的案例语句位置以及该位置上的上下文信息全部摘取下来，形成一个检查的执行日志，在后续的案例维护中通过该执行日志来对案例进行处理即可。优选的，对于语句在案例中的位置具体可以通过案例执行时语句的指向帧来确定。

在本实施例中，该上下文信息还可以是案例执行过程中的变量和参数等等，同时还包括记录该执行失败的案例的类名和方法名，并且在记录节点信息时可以通过建立类名和方法名与上下文信息之间的对应关的方式存储，储存在生成的案例执行日志中。

步骤S140，根据所述案例执行日志中的标识信息判断与所述故障原因对应的故障是否被排除；

该步骤中的故障排除，主要是通过人为的干扰方式来实现对故障的排除，而***在分析出存在故障导致了案例执行失败时，会对该故障进行定时的探测，通过探测该故障是否被排除了，当然该故障被排除的响应，可以是通过排除故障后通过标识信息的反应，也可以是通过一些其他参数的反应来实现，若排除了，则调至步骤S160，进行案例的重启操作。

在实际应用中，对于标识信息具体可以通过以二进制的标识位进行标识，“0”为未排除，“1”为已排除，而该步骤中，通过获取该标识位中的0或1来确定故障是否被排除；另外，还可以通过在执行日志中增加一个符号位来标识，具体标识包括“N”和“Y”两种，“N”为未排除，“Y”为已排除，而判断的方式与二进制的标识位一致，这里不再重复赘述。

步骤S150，若判断所述故障已被排除，则将所述案例执行日志中记录的节点位置作为所述案例执行的起点，并将所述案例信息重新加载至所述设备的案例执行单元中，以所述起点为执行点继续执行所述案例；

步骤S160，若判断所述故障未被排除，则将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理。

在本实施例中，所述重启操作指的是对案例的重跑；当***检测到故障被排除的响应后，返回该案例的执行流程，并从执行日志中获取到与该案例对应的节点记录，调取响应的处理方法对该案例进行重跑操作。

在实际应用中，为了便于重启的处理，还包括设置一个重启案例加载数据缓存器，在确定需要进行重启执行处理的案例之后，将对应的案例的信息上传至该缓存器，该缓存器将上传的案例的信息保存到缓存器中重启表格中，当定时器计时到达后，直接读取表格中的案例的信息案例执行重启的程序即可实现对案例的重启执行操作。

在本实施例中，为了便于后续对案例重启的操作，其还包括：根据造成案例执行失败的原因对案例进行分类，例如原因解决后将可以进行继续执行的案例分为一类，将可以重新执行的案例分为一类等等。

在本实施例中，对于案例执行失败的原因具体可以理解为分为以下几种：新案例启动被中断、语句的映射不正确、***硬件故障和操作***故障，对于根据执行失败的原因对案例的分类，具体的，根据上述的集中原因，对案例做初步的分类，而对于分类后的案例具体是执行继续操作还是重启操作，则跳转至步骤S140进行下一步的处理。

在本实施例中，对于重跑可以是对案例的继续执行，也可以是对案例的重新执行，当然优选的，根据造成案例故障执行的原因来选择继续执行还是重新执行。

基于上述的步骤实现对案例的执行控制，通过根据案例执行失败的分类实现不同的重跑操作，从而避免了现有的案例失败都是重新执行导致执行时间过于浪费，且消耗资源的问题。实现了支持失败自动重跑、失败继续重跑、选择性暂停重跑等案例的控制方式，大大提高了用户的使用和操作体验。

进一步的，在本实施例中，所述基于所述故障原因和所述节点位置生成案例执行日志包括：

获取所述案例执行日志的模板信息，所述模板信息为记录所述案例在执行情况和所产生的信息的表格；

获取所述节点位置所对应的执行代码，以及所述节点位置的上下文信息；

将所述节点位置的执行代、所述故障原因和所述上下文信息记录在所述表格中，以形成案例执行日志，其中，所述上下文信息包括cookie、登陆态、变量和时间戳中的至少一种。

具体的，对于节点位置的记录具体表现为将所述节点位置所对应的案例的程序中的执行代码，即是将节点位置对应的执行代码进行记录，同时还节点位置所在的上下文信息记录在所述执行日志中，所述上下文信息包括cookie、登陆态、变量和时间戳中的至少一种。

在本实施例中，所述故障执行状态包括执行中断状态和执行失败状态；

所述获取所述案例在当前故障执行状态时的节点位置，并基于所述故障原因和所述节点位置生成案例执行日志包括：

判断所述故障执行状态是否为执行中断状态；

若判断为所述执行中断状态，则获取所述案例执行被中断所在的节点位置，将所述节点位置记录至所述案例执行日志中；

若判断不是所述执行中断状态，则判断所述故障执行状态是否满足所述执行失败状态的条件；

若判断满足所述执行失败状态的条件，则确定造成所述案例执行失败的故障原因，以及导致所述案例执行失败所在的节点位置，将所述故障原因和所述节点位置记录至所述案例执行日志中。

在实际应用中，对于执行中断状态的判断，可选的，是通过检测***中的案例执行中断按钮来判断该案例的执行是否为认为的中断操作，若案例中断按钮被按下，或者是该按钮有响应信号输出，则认为是案例处于中断状态。

基于处于中断状态时，且是用户主动的暂停。在平台上有暂停按钮，用户如果在案例执行过程中点击暂停，那么平台后台会将该案例进程挂起，并保存执行到某处的所有变量和信息，以便后续进程继续时可以正常继续执行。

对于执行失败状态的判断，可选的，是通过该案例的执行方法是否被结束，若是，则进一步对被结束的原因进行深入的分析，确定被结束的原因是什么，一般情况下，案例的执行方法被结束处理的情况会存在以下几种，分别是环境原因、案例被人为结束、***功能缺陷等等。

在本实施例中，所述确定造成所述案例执行失败的故障原因包括：

检测所述案例执行单元在执行所述案例过程中，是否存在有执行优先级设置的新案例被启动；

检测执行所述案例对应的工作环境是否出现了变化，其中，所述工作环境包括所述设备的配置项、所述设备的服务器、所述案例执行的测试场景和所述设备所使用的网络；

检测所述案例是否是由于非功能问题导致的执行失败，其中，所述非功能问题为不是由所述设备的软件配置或者硬件配置所引起的故障。

在实际应用中，该工作环境指的是***的一些配置项、***的服务器、***正在测试场景、网络等等，而工作环境的变化指的是***的一些配置项配置错误、***的服务器正在重启、***正在测试场景异常、网络故障等等。

当案例执行失败是因为环境原因失败时，案例的执行流程将会被停留在失败的节点处，将失败时的上下文记录起来，当环境问题解决后，可以通过点击继续执行按钮，使得案例从失败节点处继续执行，或者是通过预先设置的案例重启程序来实现自动案例的自动启动。

对于环境原因的案例重跑的具体实现方案可以如下：

记录下执行代码的上下文，即cookie、登陆态、变量、时间戳等信息，存在数据库中

当环境问题解决后，通过反射获取到当前执行失败用例的类名和方法名

点击继续执行按钮时，读取上下文数据，调用当前失败用例的失败处的方法，从而继续该案例。

在本实施例中，若分析到案例是由于新案例的启动而导致执行失败时，所述案例执行方法还包括：

判断所述新案例的执行优先级是否大于当前执行的案例的执行优先级；

若是，则判断所述新案例与当前执行的案例是否为同一类型的案例；

若是同一类型的案例，则将所述新案例替换当前执行的案例，并执行所述新案例；

若不是同一类型的案例，则将当前执行的案例设置为执行中断状态或者执行失败状态，并跳转至所述新案例执行，待所述新案例执行完成后，返回至设置为执行中断状态或者执行失败状态的案例继续执行。

在实际应用中，对于一个案例的执行失败有可能是由于优先级别高的案例启动了，但是***的处理资源又不够用的前提下，才会选择性的停止部分当前正在执行的案例来空闲出一部分资源供给新案例使用。对于这种情况的案例执行失败是可以通过继续执行的方式来重跑案例的。

进一步的，当案例是因非功能问题执行失败时，则直接选择自动重新执行该案例的方式启动案例，直至案例完整执行成功或者多次因功能问题执行失败为止，停止对该案例的操作。

具体的实现方案可以是在@AfterMethod注解方法中，添加测试执行结果的监听，通过ITestResult接口去判断测试执行是否成功，如果失败了就通过反射获取到当前执行失败用例的类名和方法名，然后调用方法，实现了重跑一次或多次，对于重跑的次数可以自己设定。

在本实施例中，若所述故障执行状态为执行失败状态时，所述将所述案例执行日志中记录的节点位置作为所述案例执行的起点，并将所述案例信息重新加载至所述设备的案例执行单元中，以所述起点为执行点继续执行所述案例的步骤具体包括：

通过反射获取到所述执行失败状态的所述案例的类名和方法名；

根据所述类名和方法名从所述案例执行日志中读取所述上下文信息，并调用案例执行失败处理策略对所述执行失败状态的案例进行重启操作。

在实际应用中，上述反射是java编程中一种技术，通过反射可以获得指定的类对象。在本实施例中，运用了反射来获取类对象，作用是为了保存执行失败时的类对象，并保存下来，以便后续可以调用该对象执行对应案例的后续步骤方法。

对于类名和方法名是指java编程代码中一些代码的用语。在代码中，是通过类来创建对象，通过对象来操作方法的，而一个方法就是实现了一些数据处理，也就是完成了一些案例的操作步骤。

读取上下文数据，是指在点击继续执行案例时，后台会根据之前保存的类名、方法名，去读取数据库中保存的所有与这条案例有关的变量值，然后通过重新定义变量并赋值，以此来重现案例的数据环境。从而，可以继续把暂停了的案例执行下去。

也即是说，在检测到案例为执行失败状态时，会同时记录案例的类名和执行该案例的方法名，在解决了导致执行失败的问题后，通过反射查询到师失败案例的类名和方法名，并基于记录的节点位置和上下文数据进行案例的重跑处理。

在本实施例中，若对于造成案例执行失败的原因是用户结束案例时，则会启动案例清理程序，对该终止的案例的相关进行全部清理，从而实现对案例的结束操作。

在本实施例中，在所述将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理的步骤之前，还包括：根据所述故障原因对所述案例进行类型划分；

所述将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理包括：

根据所述案例的类型从所述设备中选择对应的案例缓存区；

将待重新加载的所述案例信息加载至所述案例缓存区中等待所述案例执行单元的调取执行。

综上所述，本发明实施例提供的案例执行方法，通过对设备的案例信息的查询得到案例的执行情况来确定案例的执行状态，然后根据执行状态查询对应的故障原因，然后获取到执行故障的案例所在的节点位置，基于上述获取到的信息来生成一个案例执行日志，基于案例执行日志中记载的信息来选择对案例的执行控制，选择的继续执行还是重启执行，即是通过对案例执行失败的原因的检测，并在对检测到的原因进行分类，同时记录执行失败的节点位置和节点对应的上下文数据，在解决了的执行失败的原因后，根据节点位置和上下文数据安排案例的自动重启操作，从而降低了***对案例执行的控制难度，同时也实现了对案例执行失败时的继续执行控制，与现有的暗中重新执行的方式相比，继续执行可以节省了案例的执行时间，也提高了案例执行的成功率。

下面以具体的故障原因为例对本发明提供的案例执行方法进行详细的说明，如图2所示，为案例执行失败时的具体实现流程图，该方法具体包括以下步骤：

步骤S210，获取取设备上执行失败的案例信息；

在该步骤中，具体可以是已经执行结束的案例，但是该结束应当理解为是已经存储在案例记录表中的案例信息，即是说由于被设备***记录为师表的且过了一段时间已经不再重新执行的案例；进一步的，还可以是正在执行的案例，刚被标记为执行失败的案例。

步骤S220，分析提取出该案例在执行时导致其执行失败的节点位置；

在该步骤中，该种节点位置可能会存在多个，对此，还需要根据节点位置以及该节点位置导致失败的原因来判断案例是否可以进行继续执行操作，若不行，则直接启动重启操作步骤。

进一步的，还可以通过对案例的执行历程进行履历来确定第一失败节点位置，判断第一失败节点位置的可执行性，若不可继续进行则直接重启操作，若可以，则继续判断下一节点位置的可执行性，直到案例的所有节点有只要有一个具有不可继续执行的，则重启，反之则继续执行。

步骤S230，判断节点位置的故障原因的可执行性；

在实际应用中，这里的可执行性包括可使用继续执行案例操作和不可继续执行案例操作。

步骤S240，根据判断的结果选择案例的控制方案；

在该步骤中，其控制方案指的是继续执行操作和重跑操作。

步骤S250，根据节点位置和控制方案生成案例执行日志文件；

步骤S260，根据案例执行日志文件中的记录信息对案例进行控制操作。

在本实施例中，在记录节点位置时，还包括记录节点位置的执行代码以及节点位置对应的位置的上下文数据，该上下文数据包括cookie、登陆态、变量、时间戳等信息，存储在案例执行日志文件中。

在本实施例中，进一步检测到是由于环境问题导致执行失败的，环境问题解决后，可以选择继续执行的控制方案进行处理，具体当环境问题解决后，通过反射获取到当前执行失败用例的类名和方法名，点击继续执行按钮时，读取上下文数据，调用当前失败用例的失败处的方法，从而继续该案例。

进一步的，若是因非功能问题执行失败时，则选择自动重新执行该案例的方式控制，直至案例完整执行成功或者因功能问题执行失败为止。

实现方案：在@AfterMethod注解方法中，添加测试执行结果的监听，通过ITestResult(最佳试验结果)接口去判断测试执行是否成功，如果失败了就通过反射获取到当前执行失败用例的类名和方法名，然后调用方法，实现了重跑一次(或多次，次数可以自己设定)。

为了解决上述的问题，本发明还提供一种案例执行设备，该案例执行设备可以用于实现本发明实施例提供的案例执行方法，其物理实现以服务器的方式存在，该服务器的具体硬件实现如图1所示。

参见图3，该服务器包括：处理器301，例如CPU，通信总线302、用户接口303，网络接口304，存储器305。其中，通信总线302用于实现这些组件之间的连接通信。用户接口303可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，网络接口304可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器305可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器305可选的还可以是独立于前述处理器301的存储装置。

本领域技术人员可以理解，图3中示出的设备的硬件结构并不构成对案例执行装置的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图3所示，作为一种计算机可读存储介质的存储器305中可以包括操作***、网络通信模块、用户接口模块以及基于案例执行程序。其中，操作***是管理和案例执行装置和软件资源的程序，支案例执行程序以及其它软件和/或程序的运行。

在图3所示的服务器的硬件结构中，网络接口104主要用于接入网络；用户接口103设备上执行的案例信息，以及执行案例过程中所产生的数据，而处理器301可以用于调用存储器305中存储的案例执行程序，并执行以下案例执行方法的各实施例的操作。

在本大明实施例中，对于图3的实现还可以是一种手机等可以触控操作的移动终端，该移动终端的处理器通过读取存储在缓存器或者存储单元中的可以实现案例执行方法的程序代码来进行案例进行分析，生成案例执行日志，从而控制选择哪种方式对案例进行执行操作。

为了解决上述的问题，本发明实施例还提供了一种案例执行装置，参照图4，图4为本发明实施例提供的案例执行装置的功能模块的示意图。在本实施例中，该装置包括：

监测模块41，用于获取设备上已执行或者正在执行的案例信息，根据所述案例信息检查案例的执行情况，以确定所述案例是否处于故障执行状态；

查询模块42，用于在所述案例处于故障执行状态时，根据所述故障执行状态，从预置的故障执行状态与故障原因对应的关系表中，查询出所述案例在当前故障执行状态对应的故障原因；

记录模块43，用于获取所述案例在当前故障执行状态时的节点位置，并基于所述故障原因和所述节点位置生成案例执行日志，其中，在所述案例执行日志中还包括记录所述案例的故障是否已处理的标识信息；

判断模块44，用于根据所述案例执行日志中的标识信息判断与所述故障原因对应的故障是否被排除；

处理模块45，用于在判断所述故障已被排除时，将所述案例执行日志中记录的节点位置作为所述案例执行的起点，并将所述案例信息重新加载至所述设备的案例执行单元中，以所述起点为执行点继续执行所述案例；以及在判断所述故障未被排除时，将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理。

基于与上述本发明实施例的案例执行方法相同的实施例说明内容，因此本实施例对案例执行装置的实施例内容不做过多赘述。

本实施例通过对案例执行失败的原因的检测，并在对检测到的原因进行分类，同时记录执行失败的节点位置和节点对应的上下文数据，在解决了的执行失败的原因后，根据节点位置和上下文数据生成案例执行日志来安排案例的自动重启操作，基于这种记录和自动重启的方式来实现对案例的重跑控制，从而降低了***对案例执行的控制难度，同时也实现了对案例执行失败时的继续执行控制，通过这样的控制方式可以节省了案例的执行时间，也提高了案例的控制效率，以及提高了案例执行的成功率。

本发明还提供一种计算机可读存储介质。

本实施例中，所述计算机可读存储介质上存储有案例执行程序，所述案例执行程序被处理器执行时实现如上述任一项实施例中所述的案例执行方法的步骤。其中，案例执行程序被处理器执行时所实现的方法可参照本发明案例执行方法的各个实施例，因此不再过多赘述。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，这些均属于本发明的保护之内。

Claims (10)

1.一种案例执行方法，其特征在于，所述案例执行方法包括以下步骤：

获取设备上已执行或者正在执行的案例信息，根据所述案例信息检查案例的执行情况，以确定所述案例是否处于故障执行状态；

若所述案例处于故障执行状态，则根据所述故障执行状态，从预置的故障执行状态与故障原因对应的关系表中，查询出所述案例在当前故障执行状态对应的故障原因；

获取所述案例在当前故障执行状态时的节点位置，并基于所述故障原因和所述节点位置生成案例执行日志，其中，在所述案例执行日志中还包括记录所述案例的故障是否已处理的标识信息；

根据所述案例执行日志中的标识信息判断与所述故障原因对应的故障是否被排除；

若判断所述故障已被排除，则将所述案例执行日志中记录的节点位置作为所述案例执行的起点，并将所述案例信息重新加载至所述设备的案例执行单元中，以所述起点为执行点继续执行所述案例；

若判断所述故障未被排除，则将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理。

2.如权利要求1所述的案例执行方法，其特征在于，所述基于所述故障原因和所述节点位置生成案例执行日志包括：

获取所述案例执行日志的模板信息，所述模板信息为记录所述案例在执行情况和所产生的信息的表格；

获取所述节点位置所对应的执行代码，以及所述节点位置的上下文信息；

将所述节点位置的执行代、所述故障原因和所述上下文信息记录在所述表格中，以形成案例执行日志，其中，所述上下文信息包括cookie、登陆态、变量和时间戳中的至少一种。

3.如权利要求1所述的案例执行方法，其特征在于，所述故障执行状态包括执行中断状态和执行失败状态；

所述获取所述案例在当前故障执行状态时的节点位置，并基于所述故障原因和所述节点位置生成案例执行日志包括：

判断所述故障执行状态是否为执行中断状态；

若判断为所述执行中断状态，则获取所述案例执行被中断所在的节点位置，将所述节点位置记录至所述案例执行日志中；

若判断不是所述执行中断状态，则判断所述故障执行状态是否满足所述执行失败状态的条件；

若判断满足所述执行失败状态的条件，则确定造成所述案例执行失败的故障原因，以及导致所述案例执行失败所在的节点位置，将所述故障原因和所述节点位置记录至所述案例执行日志中。

4.如权利要求3所述的案例执行方法，其特征在于，所述确定造成所述案例执行失败的故障原因包括：

检测所述案例执行单元在执行所述案例过程中，是否存在有执行优先级设置的新案例被启动；

检测执行所述案例对应的工作环境是否出现了变化，其中，所述工作环境包括所述设备的配置项、所述设备的服务器、所述案例执行的测试场景和所述设备所使用的网络；

检测所述案例是否是由于非功能问题导致的执行失败，其中，所述非功能问题为不是由所述设备的软件配置或者硬件配置所引起的故障。

5.如权利要求4所述的案例执行方法，其特征在于，在所述检测到存在有执行优先级设置的新案例被启动之后，所述案例执行方法还包括：

判断所述新案例的执行优先级是否大于当前执行的案例的执行优先级；

若是，则判断所述新案例与当前执行的案例是否为同一类型的案例；

若是同一类型的案例，则将所述新案例替换当前执行的案例，并执行所述新案例；

若不是同一类型的案例，则将当前执行的案例设置为执行中断状态或者执行失败状态，并跳转至所述新案例执行，待所述新案例执行完成后，返回至设置为执行中断状态或者执行失败状态的案例继续执行。

6.如权利要求1-5任一项所述的案例执行方法，其特征在于，所述将所述案例执行日志中记录的节点位置作为所述案例执行的起点，并将所述案例信息重新加载至所述设备的案例执行单元中，以所述起点为执行点继续执行所述案例包括：

若所述故障执行状态为执行失败状态，则通过反射获取到所述执行失败状态的所述案例的类名和方法名；

根据所述类名和方法名从所述案例执行日志中读取所述上下文信息，并调用案例执行失败处理策略对所述执行失败状态的案例进行重启操作。

7.如权利要求6所述的案例执行方法，其特征在于，在所述将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理的步骤之前，还包括：根据所述故障原因对所述案例进行类型划分；

所述将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理包括：

根据所述案例的类型从所述设备中选择对应的案例缓存区；

将待重新加载的所述案例信息加载至所述案例缓存区中等待所述案例执行单元的调取执行。

8.一种案例执行装置，其特征在于，所述案例执行装置包括：

监测模块，用于获取设备上已执行或者正在执行的案例信息，根据所述案例信息检查案例的执行情况，以确定所述案例是否处于故障执行状态；

查询模块，用于在所述案例处于故障执行状态时，根据所述故障执行状态，从预置的故障执行状态与故障原因对应的关系表中，查询出所述案例在当前故障执行状态对应的故障原因；

记录模块，用于获取所述案例在当前故障执行状态时的节点位置，并基于所述故障原因和所述节点位置生成案例执行日志，其中，在所述案例执行日志中还包括记录所述案例的故障是否已处理的标识信息；

判断模块，用于根据所述案例执行日志中的标识信息判断与所述故障原因对应的故障是否被排除；

处理模块，用于在判断所述故障已被排除时，将所述案例执行日志中记录的节点位置作为所述案例执行的起点，并将所述案例信息重新加载至所述设备的案例执行单元中，以所述起点为执行点继续执行所述案例；以及在判断所述故障未被排除时，将所述案例信息重新加载至所述设备的案例执行单元中对所述案例进行重启执行处理。

9.一种案例执行设备，其特征在于，所述案例执行设备包括：存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的案例执行程序，所述案例执行程序被所述处理器执行时实现如权利要求1-7中任一项所述的案例执行方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有案例执行程序，所述案例执行程序被处理器执行时实现如权利要求1-7中任一项所述的案例执行方法的步骤。