CN117667181A - 运维变更方法及装置 - Google Patents

Abstract

本申请公开一种运维变更方法及装置，涉及计算机技术领域。本申请的方法包括：接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据；基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果。

Description

运维变更方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种运维变更方法及装置。

背景技术

为保证软件系统的稳定性和可靠性，在软件线上运行期间，不可避免的需要对软件系统进行运维变更。在这个过程中，由于运维变更时会对软件系统的软硬件、网络等进行变更修改，为了确保变更后的顺利运行，一般还需在对其变更后的软件系统进行回归测试成功的情况下，才能认定此次运维变更操作完成。

目前，运维变更的过程中，运维人员在对软件系统进行变更调试后，一般会交由测试人员进行测试，但在这个过程中，测试人员为了确保变更调试所影响的范围都能被测试到，往往会选定较大的范围进行测试，例如，当运维变更仅涉及业务A中的某个或某几个选项的调试时，测试人员往往需要将整个业务A进行测试。这就会因测试范围与运维变更的实际范围之间不匹配导致整个运维变更过程需要花费较大的时间等待测试过程，从而影响了运维变更的效率。

发明内容

本申请实施例提供一种运维变更方法及装置，主要目的在于解决当前运维变更过程中因测试范围与运维变更的实际范围之间不匹配导致整个运维变更过程需要花费较大的时间等待测试过程，从而影响了运维变更的效率的问题。

为解决上述技术问题，本申请实施例提供如下技术方案：

第一方面，本申请提供了一种运维变更方法，所述方法，包括：

接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据；

基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；

对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果。

可选的，所述基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据包括：

基于所述目标数据在预设数据库中获取对应所述目标数据的配置信息，其中，所述预设数据库中保存有至少一个目标数据、以及每个目标数据对应的配置信息，所述配置信息用于记录每个数据存在依赖关系的服务；

基于所述配置信息，获取与所述目标数据存在依赖关系的服务对应的数据，作为所述变更范围数据。

可选的，所述对所述变更范围数据执行测试操作，得到测试结果包括：

根据预设映射关系，在测试用例集合中获取对应所述变更范围数据的测试用例，其中，所述预设映射关系中包含有至少一个变更范围数据、以及每个所述变更范围数据和测试用例间的关系；

基于所述测试用例执行所述测试操作，得到测试结果。

可选的，所述基于所述测试用例执行所述测试操作，得到测试结果，包括：

当所述测试用例为多个时，获取测试计划，并基于所述测试计划执行所述测试操作，得到所述测试结果，其中，所述测试计划包括多个所述测试用例、以及多个所述测试用例在执行所述测试操作时的执行顺序。

可选的，在所述获取测试计划，并基于所述测试计划执行所述测试操作，得到所述测试结果之前，所述方法还包括：

将多个所述测试用例按照业务功能进行划分，得到对应每种业务功能的测试用例组，其中，每个所述测试用例组中至少包括一个所述测试用例；

基于多个所述测试用例组生成测试计划，其中，所述测试计划中的多个测试用例组中存在第一逻辑关系时，所述执行顺序是基于所述第一逻辑关系确定的；

所述获取测试计划，并基于所述测试计划执行所述测试操作，得到所述测试结果，包括：

基于所述测试计划中所述执行顺序，依次对每个所述测试用例组执行所述测试操作。

可选的，所述基于所述测试计划中所述执行顺序，依次对每个所述测试用例组执行所述测试操作，包括：

当确定所述测试用例组中的多个所述测试用例中存在第二逻辑关系时，按照所述第二逻辑关系确定测试顺序，并按照所述测试顺序在所述测试用例组中依次对每个所述测试用例执行所述测试操作；

和/或，

当确定所述测试用例组中的存在至少两个不存在所述第二逻辑关系的所述测试用例时，对不存在所述第二逻辑关系的所述测试用例按照预设方式执行所述测试操作。

可选的，述基于所述测试结果确定变更结果包括：

统计多个所述测试用例的在执行所述测试操作后得到的第一结果的数量和第二结果的数据；其中所述第一结果的数量用于表征通过测试的数量，第二结果的数量用于表征未通过测试的数量；

当确定第一结果的数量达到第一预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第一预设条件为所述第一结果的数量超越预设数量或所述第一结果的数量大于预设比例；

当确定所述测试结果符合第二预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第二预设条件用于表征指定功能的测试用例通过测试。

可选的，在所述基于所述测试结果确定变更结果之后，所述方法还包括：

基于运维变更操作信息和所述变更结果，为所述运维变更操作添加操作状态，其中，所述运维变更操作信息用于表征已对目标数据执行了所述运维变更操作，所述运维变更操作信息用于表征已对目标数据执行了所述运维变更操作，所述运维变更操作信息用于表征已对目标数据执行了所述运维变更操作，所述操作状态包括基于运维变更操作信息生成的行为信息、以及基于所述变更结果生成的用于表征变更操作是否符合发布条件的信息。

可选的，所述基于所述测试用例执行所述测试操作，得到测试结果，包括：

当确定目标测试用例在执行所述测试操作后得到的用例结果为异常时，则终止第一剩余测试用例的测试操作，并将所述用例结果确定为所述测试结果；其中，所述第一剩余测试用例为除已测试的测试用例和所述目标测试用例之外的测试用例。

或者，

当确定失败用例的比例超过预设比例时，则终止第二剩余测试用例的测试操作，并将所述失败用例的用例结果确定为所述测试结果；其中，所述失败用例为执行所述测试操作后得到的所述用例结果为异常的测试用例；所述第二剩余测试用例为除所述失败用例之外的测试用例。

第二方面，本申请还提供一种运维变更装置，包括：

获取单元，用于接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据；

第一确定单元，用于基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；

第二确定单元，用于对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果。

可选的，所述第一确定单元还用于基于所述目标数据在预设数据库中获取对应所述目标数据的配置信息，其中，所述预设数据库中保存有至少一个目标数据、以及每个目标数据对应的配置信息，所述配置信息用于记录每个数据存在依赖关系的服务；以及，用于基于所述配置信息，获取与所述目标数据存在依赖关系的服务对应的数据，作为所述变更范围数据。

可选的，所述第二确定单元，还用于根据预设映射关系，在测试用例集合中获取对应所述变更范围数据的测试用例，其中，所述预设映射关系中包含有至少一个变更范围数据、以及每个所述变更范围数据和测试用例间的关系；以及，用于基于所述测试用例执行所述测试操作，得到测试结果。

可选的，所述第二确定单元，还用于当所述测试用例为多个时，获取测试计划，并基于所述测试计划执行所述测试操作，得到所述测试结果，其中，所述测试计划包括多个所述测试用例、以及多个所述测试用例在执行所述测试操作时的执行顺序。

可选的，所述第二确定单元，包括：

划分模块，用于将多个所述测试用例按照业务功能进行划分，得到对应每种业务功能的测试用例组，其中，每个所述测试用例组中至少包括一个所述测试用例；

生成模块，用于基于多个所述测试用例组生成测试计划，其中，所述测试计划中的多个测试用例组中存在第一逻辑关系时，所述执行顺序是基于所述第一逻辑关系确定的；

测试模块，用于基于所述测试计划中所述执行顺序，依次对每个所述测试用例组执行所述测试操作。

可选的，所述测试模块，用于当确定所述测试用例组中的多个所述测试用例中存在第二逻辑关系时，按照所述第二逻辑关系确定测试顺序，并按照所述测试顺序在所述测试用例组中依次对每个所述测试用例执行所述测试操作；

所述测试模块，还用于当确定所述测试用例组中的存在至少两个不存在所述第二逻辑关系的所述测试用例时，对不存在所述第二逻辑关系的所述测试用例按照预设方式执行所述测试操作。

可选的，所述第二确定单元包括：

统计模块，用于统计多个所述测试用例的在执行所述测试操作后得到的第一结果的数量和第二结果的数据；其中所述第一结果的数量用于表征通过测试的数量，第二结果的数量用于表征未通过测试的数量；

第一确定模块，用于当确定第一结果的数量达到第一预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第一预设条件为所述第一结果的数量超越预设数量或所述第一结果的数量大于预设比例；

第二确定模块，用于当确定所述测试结果符合第二预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第二预设条件用于表征指定功能的测试用例通过测试。

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

添加单元，用于基于运维变更操作信息和所述变更结果，为所述运维变更操作添加操作状态，其中，所述运维变更操作信息用于表征已对目标数据执行了所述运维变更操作，所述操作状态包括基于运维变更操作信息生成的行为信息，以及基于所述变更结果生成的用于表征变更操作是否符合发布条件的信息。

可选的，所述第二确定单元，还具体用于当确定目标测试用例在执行所述测试操作后得到的用例结果为异常时，则终止第一剩余测试用例的测试操作，并将所述用例结果确定为所述测试结果；其中，所述第一剩余测试用例为除已测试的测试用例和所述目标测试用例之外的测试用例。

可选的，所述第二确定单元，还具体用于当确定失败用例的比例超过预设比例时，则终止第二剩余测试用例的测试操作，并将所述失败用例的用例结果确定为所述测试结果；其中，所述失败用例为执行所述测试操作后得到的所述用例结果为异常的测试用例；所述第二剩余测试用例为除所述失败用例之外的测试用例。

第三方面，本申请的实施例提供了一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行第一方面中任一项所述的运维变更方法。

第四方面，本申请的实施例提供了一种运维变更装置，所述装置包括存储介质；及一个或者多个处理器，所述存储介质与所述处理器耦合，所述处理器被配置为执行所述存储介质中存储的程序指令；所述程序指令运行时执行第一方面中任一项所述的运维变更方法。

借由上述技术方案，本申请提供的技术方案至少具有下列优点：

本申请提供一种运维变更方法及装置，本申请能够接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据；然后，基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；最后，对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果，从而实现运维变更功能。与现有技术相比，由于在运维变更过程中，能够基于目标数据和配置信息获取到变更范围数据，并以变更范围数据进行测试，这就使得在整个运维变更的过程中，可以使测试时的范围与变更操作所需修改的数据相对应，从而保证了测试范围与运维变更范围之间相匹配，从而避免了现有技术需要将整个业务范围作为测试范围的过程，与其相比，本申请的测试范围明显要小于为了确保测试完整性而将整个业务功能作为测试的范围，这就可以明显减少测试所需的时间，从而使得整个运维变更的过程会因测试时间的缩短而提高整个方案的执行效率，解决了现有技术因测试范围和运维变更范围之间不匹配而导致影响运维变更效率的问题。此外，在本申请中，上述方法执行时是可以自行运行，无需人工介入，也就避免了人工方式进行测试时需要人员消耗人力的问题，同时，也避免了人工测试过程需要人工与运维人员进行沟通来确定测试范围的过程，继而可以解决人力介入所带来的准确性和时效性的问题。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过参考附图阅读下文的详细描述，本申请示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本申请的若干实施方式，相同或对应的标号表示相同或对应的部分，其中：

图1示出了本申请实施例提供的一种运维变更方法流程图；

图2示出了本申请实施例提供的另一种运维变更方法流程图；

图3示出了本申请的实施例提供一种运维变更方法执行过程的示意图；

图4示出了本申请实施例提供的一种运维变更装置的组成框图；

图5示出了本申请实施例提供的另一种运维变更装置的组成框图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施方式。虽然附图中显示了本申请的示例性实施方式，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

需要注意的是，除非另有说明，本申请使用的技术术语或者科学术语应当为本申请所属领域技术人员所理解的通常意义。

本申请实施例提供一种运维变更方法，具体如图1所示，该方法包括：

101、接收运维变更信息。

其中，所述运维变更信息包括待修改的目标数据。所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据。

在本实施例中，所述运维变更信息可以理解为在运维人员对软件系统进行运维变更操作时需要对某些软件、硬件或网络进行调整修改的记录信息，该运维变更信息能够体现出当前运维人员需要对哪些东西进行调整。在本实施例中，该运维变更方法的执行主体可以为一种运维变更系统，该系统可以云端系统，也就是部署在云端服务器，在运维人员进行基于硬件或软件的运维变更时，运维变量系统通过通信传输通道与发送运维变更操作的硬件设备或软件平台进行实时的通信。当然，该执行主体还可以为一种运维人员进行运维操作的硬件设备，该硬件设备上部署了运维变更系统，对发生的运维变更操作的设备进行监控，并基于监控结果自动获取该运维变更信息，以及基于该运维变更信息进行后续的测试操作并确定变更结果。当然，还有一种情况，该运维变更系统还可以为一种分体式系统，其中分为子母两个部分，其中子部分如前述示例中部署于本地运维人员进行运维操作的硬件设备，用于监控和接收运维变更信息，而母部分则如前述示例中部署于云端，用于通过传输通道与子部分进行传输，从而在母部分进行测试并得到变更结果，然后将该变更结果发送至子部分，以提示运维人员当前执行的运维操作是否完成。具体的，上述执行主体的具体形式包括但不限于上述任一种方式，在实际应用本实施例所述的方法时，运维人员可以基于需要自行设置即可。

同时，在本实施例中，在接收该运维变更信息的过程中，可以通过该系统中的预设接口或预设交互界面接收的，也就是说运维人员在需要进行运维变更操作时需要通过该预设接口或预设交互界面来输入当前需要修改的东西的信息。当然，在实际应用中，还可以通过记录的方式，通过对运维变更操作进行监控，并基于监控结果实现获取，在此对于上述两种方式可以选取任意一个方式进行，在此不做具体的限定。

另外，在本发明实施例中，所述目标数据可以理解为运维变更操作所需修改的内容，其可以为运维人员需要变更修改的功能、服务、网络配置等具体的数据参数中的任一种数据，也可以为运维人员实际调整的某个硬件变更后随之需要在软件层面上需要同步变更的数据，在此，对于该目标数据的具体类型、内容、以及数量不做限定，可以基于运维人员的实际需要进行选取即可。

102、基于目标数据获取对应目标数据的配置信息，并基于配置信息确定变更范围数据。

其中，所述变更范围数据为与所述目标数据存在依赖关系的数据。

由于目标数据实际上是运维人员执行运维变更操作时所要调整的软硬件所涉及的数据，同时由于在软件系统中，不同的功能、服务之间是存在一定的依赖关系的，例如当运维人员需要对服务A中的某个选项或配置进行调整，当该选项或配置的实现依赖于功能a的支持，那么在对其进行修改的过程中就需要考虑对功能a的同步调整。因此，在本实施例中，当确定了目标数据后，就需要获取到和目标数据存在关系的配置信息，该配置信息可以理解为预设配置的用于记录各种数据之间依赖关系的信息，因此在获取到该配置信息后，就可以基于该配置信息来确定与目标数据A存在依赖关系的数据，即变更范围数据。

例如，当确定目标数据为数据a时，那么需要在多个配置信息中获取到记录有数据a的配置信息，当确定配置信息1至配置信息n中，配置信息2和配置信息3中都记录有数据a，那么说明这两个配置信息中就记录有数据a有依赖关系的数据。配置信息2中记录了数据a对应的数据x，配置信息3中记录数据a对应的数据j，接下来就可以将数据x和数据j确定为变更范围数据。

当然在上述示例中，由于有些情况下目标数据可以对应多个不同的数据，而这些不同的数据中可能有部分是无需进行测试的，那么在本步骤中还可以基于运维人员的需要设置相应的规则来确定这些与目标数据存在依赖关系的多个数据中的哪些作为实际的变更范围数据，或者也可以通过预设交互界面或预设端口将这些数据发送至运维人员帐户所使用的设备，并基于运维人员帐户的反馈来确定哪些作为变更范围数据。

103、对变更范围数据执行测试操作，得到测试结果，并基于测试结果确定变更结果。

当确定变更范围数据后，实际上就确定了在本次运维变更操作过程中所影响的数据都有哪些，那么接下来受到影响的数据就需要进行回归测试以确定这次运维变更操作是否符合操作规范或需求，因此在本步骤中就可以基于该变更范围数据执行测试操作，并获取相应的测试结果，当然由于测试结果能够反应出此次进行运维变更操作是否符合操作规范或需求，也就是说，经过运维变更操作后的软件系统是否能够正常运行，因此将测试结果确定变更结果，就能够体现出此次的运维人员进行运维变更操作后的软件系统是否可以正常使用。

例如，当测试结果为异常时，那么说明此次变更范围数据并没有通过测试，那么就说明运维变更操作完成后，当前的软件系统是存在问题的，那么此次的运维变更操作实际上是失败的，那么基于此就可以确定变更结果为失败，也就是说需要运维人员重新进行调试并分析出现问题的原因。反之，当确定测试结果为成功时，说明当前软件系统经过运维变更操作后还是正常运行，那么此时就可以将变更结果确定为成功，以体现此次运维变更操作没有对其他的功能或服务造成影响，软件系统可以回归使用。

本实施例提供了一种运维变更方法，本申请能够接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据；然后，基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；最后，对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果，从而实现运维变更功能。与现有技术相比，由于在运维变更过程中，能够基于目标数据和配置信息获取到变更范围数据，并以变更范围数据进行测试，这就使得在整个运维变更的过程中，可以使测试时的范围与变更操作所需修改的数据相对应，从而保证了测试范围与运维变更范围之间相匹配，从而避免了现有技术需要将整个业务范围作为测试范围的过程，与其相比，本申请的测试范围明显要小于为了确保测试完整性而将整个业务功能作为测试的范围，这就可以明显减少测试所需的时间，从而使得整个运维变更的过程会因测试时间的缩短而提高整个方案的执行效率，解决了现有技术因测试范围和运维变更范围之间不匹配而导致影响运维变更效率的问题。此外，在本申请中，上述方法执行时是可以自行运行，无需人工介入，也就避免了人工方式进行测试时需要人员消耗人力的问题，同时，也避免了人工测试过程需要人工与运维人员进行沟通来确定测试范围的过程，继而可以解决人力介入所带来的准确性和时效性的问题。

以下为了更加详细地说明，本申请实施例提供了另一种运维变更方法，具体如图2所示，该方法包括：

201、接收运维变更信息。

其中，所述运维变更信息包括待修改的目标数据。所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据。

在本步骤中，当运维人员通过预设输入接口或者预设交互界面输入了运维变更信息后，就说明已经对软件或硬件系统执行运维变更操作了，在此对于运维变更信息的接收可以基于上述两种方式中的任意一种进行。这样，当接收到运维变更信息后，就可以得知运维人员已经完成了对软件或硬件设备的修改，当然只完成了修改但并不表示修改是成功的，运维变更操作整个流程是否成功实际上还需要确保所修改的过程并不影响其他的功能的正确运行和实现。因此就需要后续步骤继续进行操作。对于运维人员而言，在执行运维变更操作的过程中实际上可以直接将本次运维变更操作所需要修改的功能利用上述两种方式中的任意一种进行，也就是说直接通过预设交互界面或预设接口输入上述内容作为运维变更信息即可，然后基于运维人员输入的运维变更信息获取到其所需修改的功能涉及的数据即为目标数据。

在发明实施例中，该目标数据除了如同上述方式进行确定，也可以直接基于运维人员输入亦可，例如当运维人员需要对某个功能或的具体参数进行调整，那么也可以直接将需要修改的数据作为运维变更信息通过预设接口或预设交互界面进行输入，然后在接收到该运维变更信息后，直接将其内容确定为目标数据。在此，对于基于运维变更信息确定目标数据的过程可以按照上述任一种方式进行，具体的选取哪一种可基于运维人员的需求确定。

202、基于目标数据获取对应目标数据的配置信息，并基于配置信息确定变更范围数据。

其中，所述变更范围数据为与所述目标数据存在依赖关系的数据。

具体的，本步骤在执行时可以包括：

基于所述目标数据在预设数据库中获取对应所述目标数据的配置信息，其中，所述预设数据库中保存有至少一个目标数据、以及每个目标数据对应的配置信息，所述配置信息用于记录每个数据存在依赖关系的服务；

基于所述配置信息，获取与所述目标数据存在依赖关系的服务，进而获取该服务对应的数据作为所述变更范围数据。

在本实施例中，存在依赖关系的变更范围数据和目标数据可以为两个存在影响的服务所对应的数据，服务所对应的数据也就是实现该服务的数据。例如，筛选服务对应的数据为目标数据，而筛选服务能够顺利执行的前提是查询服务运行正常，那么查询服务对应的数据则为本实施例所述的变更范围数据，也就是说，运维人员如果想要对实现筛选服务的数据修改时，那么同时也需要对查询服务对应的数据进行同步调整。

当前述步骤确定了目标数据后，实际上就明确了在本次运维变更过程中修改的是哪部分功能或服务，但由于软件系统中的各个功能或服务之间彼此是存在一定的关联的，也就是说，在某些功能或服务修改的过程中，与之存在依赖关系的其他功能或服务可能也需要随之受到影响，那么为了确定运维变更能够顺利进行(也就是运维变更之后软件系统的运行保持正常)，在本实施例中就需要在确定了目标数据后，还需要基于该目标数据来确定与之存在依赖关系的数据，即变更范围数据。

当然，变更范围数据按照以往的方式来说，实际上需要运维人员在进行了运维变更之后告知维护人员，由维护人员基于经验自行确认的，但在本实施例中，不用于现有技术需要依赖运维人员人工介入来确定与目标数据存在依赖关系的变更范围数据，而是可以基于预设数据库中保存的配置信息进行。其中，该预设数据库可以为CMDB数据库，其中CMDB(Configuration Management Database，配置管理数据库，简称CMDB)是一种基于专门用作记录企业的信息和设备的数据库。它收集和存储了各种参数信息，包括硬件、软件、网络设备、应用程序等，以及它们之间的关系。而在该预设数据库中存储了软件系统所涉及的所有的软件、硬件、网络等信息，以及彼此之间通过配置信息记录了彼此之间的依赖关系。因此在本实施例中，通过该配置信息就可以确定目标数据存在依赖关系的数据，即本实施例所述的变更范围数据。

203、对变更范围数据执行测试操作，得到测试结果，并基于测试结果确定变更结果。

当前述步骤已经确定运维变更操作完成后，实际上仅仅说明运维人员修改行为实施完毕，但修改内容是否符合要求，或者修改后的软件系统是否能正确运行才是确定运维变更操作是否成功依据。因此，在本实施例中，对于修改涉及的范围就需要进行测试，也就是说需要对目标数据所涉及的变更范围数据进行测试。

具体的，本步骤在执行时，所述对所述变更范围数据执行测试操作，得到测试结果包括：

首先，根据预设映射关系，在测试用例集合中获取对应所述变更范围数据的测试用例，其中，所述预设映射关系中包含有至少一个变更范围数据、以及每个所述变更范围数据和测试用例间的关系；

然后，基于所述测试用例执行所述测试操作，得到测试结果。

在本实施例中，测试过程对于不同的数据而言，可以基于不同的测试用例进行，由于目标数据实际上就是不同功能、服务涉及的到数据，因此在修改时所影响的也是相关的功能和服务，那么在这个过程中就可以基于变更范围数据确定对应的测试用例，执行测试用例，以进行测试，得到测试结果。这样就实现了以测试用例的方式来进行测试，确保了测试结果能模拟出实际运行时的情况，确保了测试结果的准确性。

进一步的，本步骤中，所述基于所述测试用例执行所述测试操作，得到测试结果，包括：

将多个所述测试用例按照业务功能进行划分，得到对应每种业务功能的测试用例组，其中，每个所述测试用例组中至少包括一个所述测试用例；

基于多个所述测试用例组生成测试计划，其中，所述测试计划中的多个测试用例组中存在第一逻辑关系时，所述执行顺序是基于所述第一逻辑关系确定的；

基于所述测试计划中所述执行顺序，依次对每个测试用例组执行所述测试操作。

应当理解，在本申请实施例中的“多个”可以理解为两个及两个以上。同时，在本实施例中，当确定多个测试用例之间不存在逻辑关系，或多个测试用例组之间不存在逻辑关系的情况下，可以基于运维人员的需要，自行选取测试用例或测试用例组的执行测试操作时的顺序。当然，也可以基于多个测试用例自身默认的顺序进行测试，在此不做赘述，可基于实际情况进行选取即可。

由于软件系统可能包含多个不同的业务场景，不同业务场景下的某些功能是通用的，或者说有些业务场功能之间也是存在逻辑关系的，譬如数据处理场景和数据分析场景之间，前者是后者分析的前提和数据来源。因此，对于这些存在业务功能层面上有逻辑关系的测试用例而言，彼此之间也需要在测试的过程中按照一定的逻辑进行。因此可以如上述步骤所示，将多个测试用例按照业务功能划分成多个测试用例组，然后按照业务功能间的第一逻辑关系确定这些测试用例组测试时所需的执行顺序，并生成对应的测试计划，最后在进行测试操作时，也是按照这个执行顺序分别执行对应的测试用例组。

在此，需要说明的是，该第一逻辑关系以及后续的第二逻辑关系均可以通过前述描述的CMDB数据库进行获取，当然，在某些特定情况下，如果CMDB数据库中记录存在异常，或运维人员临时修改各个功能之间的关系的情况下，还可以基于前述示例所述的预设接口或预设交互界面进行获取，也就是说，本实施例所述的方法在执行过程中，运维人员可以基于上述接口或交互界面来输入测试用例之间的逻辑关系，或测试用例对应的功能之间的逻辑关系，并以此来确定第一逻辑关系和第二逻辑关系。

这样，就确保了当某些测试用例涉及的业务功能之间有逻辑关系的情况下，按照该逻辑关系的顺序进行测试，那么当某个执行顺序靠前的测试用例测试出问题时，基于逻辑关系的影响，势必后续的测试用例涉及的功能也会出现问题，这样就避免了将所有测试用例都测试的情况，可以在出现问题时尽早跳出测试过程，从而提高测试效率。

当然，在某些情况下，需要执行测试操作的测试用例的数量较多，如果在将所有的测试用例测试完成后再进行变更结果的确定，很可能会影响变更结果的确认效率，有鉴于此，在本实施例中还可以在对测试用例进行测试操作时，设置中止跳出机制。

具体的，本实施例中，所述基于所述测试用例执行所述测试操作，得到测试结果，在执行时可以具体为：当确定目标测试用例在执行所述测试操作后得到的用例结果为异常时，则终止第一剩余测试用例的测试操作，并将所述用例结果确定为所述测试结果.

其中，所述第一剩余测试用例为除已测试的测试用例和所述目标测试用例之外的测试用例。

在测试过程中，由于某些测试用例对应的功能是核心功能、或支撑核心数据稳定、安全与效率的功能，那么当这部分功能对应的测试用例在经变更操作出现问题时，其他部分功能对应的测试用例实际上就没有必要进行后续测试了，因此在本步骤中可以通过为目标测试用例的用例结果进行分析，当发现该目标测试用例测试后的结果存在异常时，那么就可以直接中止当前测试操作，将该目标测试用例的用例结果确定为测试结果，这样就避免了在目标测试用例存在问题的情况下继续进行测试导致时间上的浪费，从而提高测试效率的情况下，提高变更效率。需要说明的是，在本实施例所述的方法在具体实施的过程中，目标测试用例可以理解为根据需求设定的目标功能对应的测试用例，例如目标功能可以是重要、核心的功能，或支撑核心数据稳定性与安全性的功能。

另外，本实施例中，所述基于所述测试用例执行所述测试操作，得到测试结果，还可以按照下述方式进行：

当确定失败用例的比例超过预设比例时，则终止第二剩余测试用例的测试操作，并将所述失败用例的用例结果确定为所述测试结果。

其中，所述失败用例为执行所述测试操作后得到的所述用例结果为异常的测试用例；所述第二剩余测试用例为除所述失败用例之外的测试用例。

通过对失败用例进行分析，可以确保在存在多个测试用例时，当发现测试出的用例结果为异常的比例超过阈值的时候，及时中止测试，避免了全部测试带来的时间消耗，从而可以尽早的发现问题的情况下跳出测试流程，从而提高测试效率。

具体的，在本步骤中，由于在同一个业务功能下的多个测试用例所涉及的功能或服务彼此之间可能也存在逻辑关系，因此在确定测试计划并执行的过程中，也可以基于彼此间的逻辑关系来确定每个测试用例组中各个测试用例执行测试操作的顺序。

基于此，所述基于所述测试计划中所述执行顺序，依次对每个所述测试用例组执行所述测试操作，在执行时可以按照下述两种方式进行：

一方面，当确定所述测试用例组中的多个所述测试用例中存在第二逻辑关系时，按照所述第二逻辑关系确定测试顺序，并按照所述测试顺序在所述测试用例组中依次对每个所述测试用例执行所述测试操作；

另一方面，当确定所述测试用例组中的存在至少两个不存在所述第二逻辑关系的所述测试用例时，对不存在所述第二逻辑关系的所述测试用例按照预设方式执行所述测试操作。其中该预设方式至少包括并行方式或串行方式，其中当利用并行方式时，则可以将多个测试用例同时进行测试操作，这样就可以确保在面对数量较多的测试用例时，可以提高测试过程的效率。另外，利用串行方式时，则可以依照一定顺序对多个测试用例一一进行测试操作，这样就可以确保在某些测试用例需要占用较大的运算开销时，避免多个测试用例同时测试所导致的因性能瓶颈使测试效率受到影响的问题。

结合上述两方面，还可能存在一种情况，即部分测试用例之间存在第二逻辑关系，而其他的测试用例不存在第二逻辑关系，那么此时则可以分别按照上述方式进行，例如当测试用例A和测试用例B之间存在第二逻辑关系时，并基于该第二逻辑关系确定测试顺序为测试用例B优先于测试用例A，同时还有与上述两个测试用例不存在第二逻辑关系的测试用例C，那么此时则可将测试用例B和测试用例C并行测试，并当测试用例B完成测试后继续执行测试用例A，如果测试用例C的测试时长较长，那么就相当于在测试用例C进行测试操作时，同时执行了“测试用例B-测试用例A”的并行“支路”。这样既可以确保有逻辑关系的测试用例之间按照一定顺序先后进行的同时，还能保证另外不存在逻辑关系的测试用例同步并行执行，从而可以提高测试效率的同时还兼顾的测试过程中有逻辑关系的测试用例间能够按照一定顺序进行的效果。

对于前一个方面而言，当确定测试用例组中的测试用例之间是有第二逻辑关系，那么就可以基于该第二逻辑关系来确定测试顺序，并以此进行测试操作。这样就确保了当一个业务功能下的测试用例之间有逻辑关系的情况下，也能按照逻辑关系所确定的测试顺序进行测试，保证了测试过程中较早测试顺序的测试用例有问题的情况下，能够尽早的跳出测试过程，从而提高测试效率。

又进一步的，所述基于所述测试结果确定变更结果包括：

统计多个所述测试用例的在执行所述测试操作后得到的第一结果的数量和第二结果的数据；其中所述第一结果的数量用于表征通过测试的数量，第二结果的数量用于表征未通过测试的数量；

当确定第一结果的数量达到第一预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第一预设条件为所述第一结果的数量超越预设数量或所述第一结果的数量大于预设比例；

当确定所述测试结果符合第二预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第二预设条件用于表征指定功能的测试用例通过测试。

在本实施例中，确定变更结果可以基于测试过程中每个测试用例反馈的结果进行确定，也就是说在测试后要统计第一结果和第二结果的数量，其中第一结果就是测试通过，第二结果就是未通过测试，当第一结果的数量超过预设数量或者大于预设比例的时候，即达到第一预设条件，那么就可以确定变更结果为变更成功，也就是说运维变更操作完成后确定其对软件系统没有影响。反之，当确定第一结果的数量未达到第二预设条件，也就是没超过预设数量或预设比例，那么说明出现问题的测试用例较多，被影响的功能或服务实际上受到了影响，那么变更结果就是变更失败，也就是运维人员的操作对软件系统有不良影响，此时的软件系统需要重新排查问题。

在上述方案中，第二预设条件与第一预设条件不同，实际上表征运维人员指定功能的测试用例是否通过的条件，也就是说，在某些情况下，运维人员可以指定某个功能，只要该功能对应的测试用例通过的测试，那么就可以确认运维变更是有效的，这样就避免了全部测试用例的检测从而提高测试效率。需要说明的是，在本实施例所述的方法在具体实施的过程中，指定功能可以理解为根据需求设定的功能，例如指定功能可以是重要、核心的功能，或支撑核心数据稳定性与安全性的功能。

204、基于运维变更操作信息和所述变更结果，为运维变更操作添加操作状态。

其中，所述运维变更操作信息用于表征已对目标数据执行了所述运维变更操作，所述操作状态包括基于运维变更操作信息生成的行为信息，以及基于所述变更结果生成的用于表征变更操作是否符合发布条件的信息。

当确定了运维人员已经执行运维变更操作后，就可以基于本实施例的方式记录对应的运维变更操作信息，还可以基于本步骤的方法，为运维变更操作添加操作状态。一个实施例中，添加的操作状态分为两个部分，一部分是表征操作是否执行的行为信息，也就是基于运维变更操作生成的；另一部分则是表征该次运维变更操作是否符合要求，是否对软件系统造成不良影响的信息。例如，前一部分，可以用“已完成”来表征当前运维变更操作这个行为已经发生，而后一分半可以用“变更成功”来表征该运维变更操作这个行为未对软件系统造成不良影响，可以进行发布。这样，通过为变更操作添加操作状态，就确保了可以实时查询每次运维变更操作当前的操作情况，从而在在一个批次执行多个运维变更操作的情况下，及时分布哪些已完成，哪些完成了也确定了是否能发布，从而利用对有问题的运维变更操作进行及时排查。

另外，作为图2所示的方法的进行一步描述，结合实际应用场景，本申请实施例还提供了一种具体的运维变更方法的执行过程，具体可以如图3所示。

301、运维人员输入运维变更信息。

该运维变更信息可以通过向用户展示预设交互界面提示用户进行输入。或在运维变更系统的提示界面上提示预设交互接口。

302、运维变更系统接收运维变更信息，并基于运维变更信息确定变更范围数据。

首先，基于目标数据在预设数据库中获取对应所述目标数据的配置信息，

然后，基于所述配置信息，获取与目标数据存在依赖关系的服务对应的数据，作为变更范围数据。

303、运维变更系统根据预设映射关系，在测试用例集合中获取对应变更范围数据的测试用例。

304、运维变更系统基于多个测试用例确定测试计划。

具体的，首先可以将多个所述测试用例按照业务功能进行划分，得到对应每种业务功能的测试用例组，其中，每个所述测试用例组中至少包括一个所述测试用例；然后基于多个所述测试用例组生成测试计划。

305、运维人员执行运维变更操作。

306、运维人员输入运维变更操作信息。

在输入运维变更操作信息的过程中，具体的方式可以采用前述步骤中的预设交互界面或预设接口进行输入，在此不做限定。

307、运维变更系统接收运维变更操作信息。

此时说明运维变更操作已经进行，那么就需要对此前运维人员操作的相关功能或服务进行测试。

308、运维变更系统按照测试计划进行测试操作。

其中，测试计划中的测试用例按功能划分成多组，每组之间有逻辑关系时，即第一逻辑关系，各个测试用例组按照第一逻辑关系确定的执行顺序进行测试。

同时，每组中的多个测试用例之间如果涉及第二逻辑关系，那么多个测试用例之间按照第二逻辑关系确定的测试顺序进行测试。

另外，如果测试用例组之间不存在第一逻辑关系时，则可以按照并行或串行的方式中的任一种进行。同理，如果在一个测试用例组中的多个测试用例之间也不存在第二逻辑关系时，多个测试用例之间也可以采用并行或串行的方式进行测试操作。

309、运维变更系统在测试操作执行时，如果确定测试失败的测试用例比例过大或目标测试用例的用例结果为异常时，中止测试。

具体的，当确定目标测试用例在执行所述测试操作后得到的用例结果为异常时，则终止第一剩余测试用例的测试操作，并将所述用例结果确定为所述测试结果；另外，当确定失败用例的比例超过预设比例时，则终止第二剩余测试用例的测试操作，并将所述失败用例的用例结果确定为所述测试结果。

310、运维变更系统基于每个测试用例的测试情况确定测试结果，并根据测试结果确定对应的变更结果。

首先，统计多个所述测试用例的在执行所述测试操作后得到的第一结果的数量和第二结果的数据；第一结果的数量表征通过测试的数量，第二结果的数量表征未通过测试的数量。

一方面，当确定第一结果的数量达到第一预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，第一预设条件为测试成功的数量超过某个预设数值，或者超过全部测试结果的某个比例。

另一方面，当确定所述测试结果符合第二预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功。该第二预设条件表明用户指定的某个功能或某几个功能的测试用例通过测试。

311、运维变更系统基于运维变更操作信息和变更结果，为运维变更操作添加操作状态。

由于此前步骤中已经接收到运维变更操作信息，说明在当前运维人员已经进行了运维变更操作，同时，前述步骤已经确认了变更结果，因此基于二者结合，就能够确定运维变更操作的实际操作状态。例如，“已变更；变更成功”其中，“已变更”表征基于运维变更操作信息确定的变更行为已经发生，而“变更成功”表征变更行为所影响的功能或服务可以按预期运行，说明变更行为正确。

为了实现上述目的，根据本申请的另一方面，本申请实施例还提供了一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行上述所述的运维变更方法。

为了实现上述目的，根据本申请的另一方面，本申请实施例还提供了一种运维变更装置，所述装置包括存储介质；及一个或者多个处理器，所述存储介质与所述处理器耦合，所述处理器被配置为执行所述存储介质中存储的程序指令；所述程序指令运行时执行上述所述的运维变更方法。

进一步的，作为对上述图1及图2所示方法的实现，本申请另一实施例还提供了一种运维变更装置。该运维变更装置实施例与前述方法实施例对应，为便于阅读，本运维变更装置实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的装置能够对应实现前述方法实施例中的全部内容。所述运维变更装置主要目的在于解决当前运维变更的效率较低的问题，具体如图4所示，该运维变更装置包括：

获取单元41，可以用于接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据可以用于表征运维变更信息所对应的运维变更操作需修改的数据；

第一确定单元42，可以用于基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；

第二确定单元43，可以用于对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果。

进一步的，如图5所示，所述第一确定单元42还可以用于基于所述目标数据在预设数据库中获取对应所述目标数据的配置信息，其中，所述预设数据库中保存有至少一个目标数据、以及每个目标数据对应的配置信息，所述配置信息可以用于记录每个数据存在依赖关系的服务；以及，可以用于基于所述配置信息，获取与所述目标数据存在依赖关系的服务对应的数据，作为所述变更范围数据。

进一步的，如图5所示，所述第二确定单元43，还可以用于根据预设映射关系，在测试用例集合中获取对应所述变更范围数据的测试用例，其中，所述预设映射关系中包含有至少一个变更范围数据、以及每个所述变更范围数据和测试用例间的关系；以及，可以用于基于所述测试用例执行所述测试操作，得到测试结果。

进一步的，如图5所示，所述第二确定单元43，包括：

划分模块431，可以用于将多个所述测试用例按照业务功能进行划分，得到对应每种业务功能的测试用例组，其中，每个所述测试用例组中至少包括一个所述测试用例；

生成模块432，可以用于基于多个所述测试用例组生成测试计划，其中，所述测试计划中的多个测试用例组中存在第一逻辑关系时，所述执行顺序是基于所述第一逻辑关系确定的；

测试模块433，可以用于基于所述测试计划中所述执行顺序，依次对每个所述测试用例组执行所述测试操作。

进一步的，如图5所示，所述测试模块433，可以用于当确定所述测试用例组中的多个所述测试用例中存在第二逻辑关系时，按照所述第二逻辑关系确定测试顺序，并按照所述测试顺序在所述测试用例组中依次对每个所述测试用例执行所述测试操作；

所述测试模块433，还可以用于当确定所述测试用例组中的存在至少两个不存在所述第二逻辑关系的所述测试用例时，对不存在所述第二逻辑关系的所述测试用例按照预设方式执行所述测试操作。

进一步的，如图5所示，所述第二确定单元43包括：

统计模块434，可以用于统计多个所述测试用例的在执行所述测试操作后得到的第一结果的数量和第二结果的数据；其中所述第一结果的数量可以用于表征通过测试的数量，第二结果的数量可以用于表征未通过测试的数量；

第一确定模块435，可以用于当确定第一结果的数量达到第一预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第一预设条件为所述第一结果的数量超越预设数量或所述第一结果的数量大于预设比例；

第二确定模块436，可以用于当确定所述测试结果符合第二预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第二预设条件用于表征指定功能的测试用例通过测试。

进一步的，如图5所示，所述装置还包括：

添加单元44，可以用于基于运维变更操作信息和所述变更结果，为所述运维变更操作添加操作状态，其中，所述运维变更操作信息用于表征已对目标数据执行了所述运维变更操作，所述操作状态包括基于运维变更操作信息生成的行为信息，以及基于所述变更结果生成的可以用于表征变更操作是否符合发布条件的信息。

进一步的，如图5所示，所述第二确定单元43，还具体用于当确定目标测试用例在执行所述测试操作后得到的用例结果为异常时，则终止第一剩余测试用例的测试操作，并将所述用例结果确定为所述测试结果；其中，所述第一剩余测试用例为除已测试的测试用例和所述目标测试用例之外的测试用例。

进一步的，如图5所示，所述第二确定单元43，还具体用于当确定失败用例的比例超过预设比例时，则终止第二剩余测试用例的测试操作，并将所述失败用例的用例结果确定为所述测试结果；其中，所述失败用例为执行所述测试操作后得到的所述用例结果为异常的测试用例；所述第二剩余测试用例为除所述失败用例之外的测试用例。

本申请实施例提供一种运维变更方法及装置，本申请能够接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据；然后，基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；最后，对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果，从而实现运维变更功能。与现有技术相比，由于在运维变更过程中，能够基于目标数据和配置信息获取到变更范围数据，并以变更范围数据进行测试，这就使得在整个运维变更的过程中，可以使测试时的范围与变更操作所需修改的数据相对应，从而保证了测试范围与运维变更范围之间相匹配，从而避免了现有技术需要将整个业务范围作为测试范围的过程，与其相比，本申请的测试范围明显要小于为了确保测试完整性而将整个业务功能作为测试的范围，这就可以明显减少测试所需的时间，从而使得整个运维变更的过程会因测试时间的缩短而提高整个方案的执行效率，解决了现有技术因测试范围和运维变更范围之间不匹配而导致影响运维变更效率的问题。此外，在本申请中，上述方法执行时是可以自行运行，无需人工介入，也就避免了人工方式进行测试时需要人员消耗人力的问题，同时，也避免了人工测试过程需要人工与运维人员进行沟通来确定测试范围的过程，继而可以解决人力介入所带来的准确性和时效性的问题。

本申请实施例提供了一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行上述所述的运维变更方法。

存储介质可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本申请实施例还提供了一种运维变更装置，所述装置包括存储介质；及一个或者多个处理器，所述存储介质与所述处理器耦合，所述处理器被配置为执行所述存储介质中存储的程序指令；所述程序指令运行时执行上述所述的运维变更方法。

本申请实施例提供了一种设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现以下步骤：接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据；基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果。

进一步的，所述基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据包括：

基于所述目标数据在预设数据库中获取对应所述目标数据的配置信息，其中，所述预设数据库中保存有至少一个目标数据、以及每个目标数据对应的配置信息，所述配置信息用于记录每个数据存在依赖关系的服务；

基于所述配置信息，获取与所述目标数据存在依赖关系的服务对应的数据，作为所述变更范围数据。

进一步的，所述对所述变更范围数据执行测试操作，得到测试结果包括：

根据预设映射关系，在测试用例集合中获取对应所述变更范围数据的测试用例，其中，所述预设映射关系中包含有至少一个变更范围数据、以及每个所述变更范围数据和测试用例间的关系；

基于所述测试用例执行所述测试操作，得到测试结果。

进一步的，所述基于所述测试用例执行所述测试操作，得到测试结果，包括：

当所述测试用例为多个时，获取测试计划，并基于所述测试计划执行所述测试操作，得到所述测试结果，其中，所述测试计划包括多个所述测试用例、以及多个所述测试用例在执行所述测试操作时的执行顺序。

进一步的，在所述获取测试计划，并基于所述测试计划执行所述测试操作，得到所述测试结果之前，所述方法还包括：

将多个所述测试用例按照业务功能进行划分，得到对应每种业务功能的测试用例组，其中，每个所述测试用例组中至少包括一个所述测试用例；

基于多个所述测试用例组生成测试计划，其中，所述测试计划中的多个测试用例组中存在第一逻辑关系时，所述执行顺序是基于所述第一逻辑关系确定的；

所述获取测试计划，并基于所述测试计划执行所述测试操作，得到所述测试结果，包括：

基于所述测试计划中所述执行顺序，依次对每个所述测试用例组执行所述测试操作。

进一步的，所述基于所述测试计划中所述执行顺序，依次对每个所述测试用例组执行所述测试操作，包括：

当确定所述测试用例组中的多个所述测试用例中存在第二逻辑关系时，按照所述第二逻辑关系确定测试顺序，并按照所述测试顺序在所述测试用例组中依次对每个所述测试用例执行所述测试操作；

和/或，

当确定所述测试用例组中的存在至少两个不存在所述第二逻辑关系的所述测试用例时，对不存在所述第二逻辑关系的所述测试用例按照预设方式执行所述测试操作。

进一步的，述基于所述测试结果确定变更结果包括：

统计多个所述测试用例的在执行所述测试操作后得到的第一结果的数量和第二结果的数据；其中所述第一结果的数量用于表征通过测试的数量，第二结果的数量用于表征未通过测试的数量；

当确定第一结果的数量达到第一预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第一预设条件为所述第一结果的数量超越预设数量或所述第一结果的数量大于预设比例；

当确定所述测试结果符合第二预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第二预设条件用于表征指定功能的测试用例通过测试。

进一步的，在所述基于所述测试结果确定变更结果之后，所述方法还包括：

基于运维变更操作信息和所述变更结果，为所述运维变更操作添加操作状态，其中，所述运维变更操作信息用于表征已对目标数据执行了所述运维变更操作，所述运维变更操作信息用于表征已对目标数据执行了所述运维变更操作，所述运维变更操作信息用于表征已对目标数据执行了所述运维变更操作，所述操作状态包括基于运维变更操作信息生成的行为信息、以及基于所述变更结果生成的用于表征变更操作是否符合发布条件的信息。

进一步的，所述基于所述测试用例执行所述测试操作，得到测试结果，包括：

当确定目标测试用例在执行所述测试操作后得到的用例结果为异常时，则终止第一剩余测试用例的测试操作，并将所述用例结果确定为所述测试结果；其中，所述第一剩余测试用例为除已测试的测试用例和所述目标测试用例之外的测试用例。

或者，

当确定失败用例的比例超过预设比例时，则终止第二剩余测试用例的测试操作，并将所述失败用例的用例结果确定为所述测试结果；其中，所述失败用例为执行所述测试操作后得到的所述用例结果为异常的测试用例；所述第二剩余测试用例为除所述失败用例之外的测试用例。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序代码：接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据；基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种运维变更方法，其特征在于，所述方法包括：

接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据；

基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；

对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果。

2.根据权利要求1所述的方法，其特征在于，所述基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据包括：

基于所述目标数据在预设数据库中获取对应所述目标数据的配置信息，其中，所述预设数据库中保存有至少一个目标数据、以及每个目标数据对应的配置信息，所述配置信息用于记录每个数据存在依赖关系的服务；

基于所述配置信息，获取与所述目标数据存在依赖关系的服务对应的数据，作为所述变更范围数据。

3.根据权利要求1所述的方法，其特征在于，所述对所述变更范围数据执行测试操作，得到测试结果包括：

根据预设映射关系，在测试用例集合中获取对应所述变更范围数据的测试用例，其中，所述预设映射关系中包含有至少一个变更范围数据、以及每个所述变更范围数据和测试用例间的关系；

基于所述测试用例执行所述测试操作，得到测试结果。

4.根据权利要求3所述的方法，其特征在于，所述基于所述测试用例执行所述测试操作，得到测试结果，包括：

当所述测试用例为多个时，获取测试计划，并基于所述测试计划执行所述测试操作，得到所述测试结果，其中，所述测试计划包括多个所述测试用例、以及多个所述测试用例在执行所述测试操作时的执行顺序。

5.根据权利要求4所述的方法，其特征在于，在所述获取测试计划，并基于所述测试计划执行所述测试操作，得到所述测试结果之前，所述方法还包括：

将多个所述测试用例按照业务功能进行划分，得到对应每种业务功能的测试用例组，其中，每个所述测试用例组中至少包括一个所述测试用例；

基于多个所述测试用例组生成测试计划，其中，所述测试计划中的多个测试用例组中存在第一逻辑关系时，所述执行顺序是基于所述第一逻辑关系确定的；

所述获取测试计划，并基于所述测试计划执行所述测试操作，得到所述测试结果，包括：

基于所述测试计划中所述执行顺序，依次对每个所述测试用例组执行所述测试操作。

6.根据权利要求5所述的方法，其特征在于，所述基于所述测试计划中所述执行顺序，依次对每个所述测试用例组执行所述测试操作，包括：

当确定所述测试用例组中的多个所述测试用例中存在第二逻辑关系时，按照所述第二逻辑关系确定测试顺序，并按照所述测试顺序在所述测试用例组中依次对每个所述测试用例执行所述测试操作；

和/或，

当确定所述测试用例组中的存在至少两个不存在所述第二逻辑关系的所述测试用例时，对不存在所述第二逻辑关系的所述测试用例按照预设方式执行所述测试操作。

7.根据权利要求3-6中任一项所述的方法，其特征在于，所述基于所述测试结果确定变更结果包括：

统计多个所述测试用例的在执行所述测试操作后得到的第一结果的数量和第二结果的数据；其中所述第一结果的数量用于表征通过测试的数量，第二结果的数量用于表征未通过测试的数量；

当确定第一结果的数量达到第一预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第一预设条件为所述第一结果的数量超越预设数量或所述第一结果的数量大于预设比例；

当确定所述测试结果符合第二预设条件时，确定所述测试结果为测试成功，并确定所述变更结果为变更成功；其中，所述第二预设条件用于表征指定功能的测试用例通过测试。

8.根据权利要求3所述的方法，其特征在于，所述基于所述测试用例执行所述测试操作，得到测试结果，包括：

当确定目标测试用例在执行所述测试操作后得到的用例结果为异常时，则终止第一剩余测试用例的测试操作，并将所述用例结果确定为所述测试结果；其中，所述第一剩余测试用例为除已测试的测试用例和所述目标测试用例之外的测试用例；

或者，

当确定失败用例的比例超过预设比例时，则终止第二剩余测试用例的测试操作，并将所述失败用例的用例结果确定为所述测试结果；其中，所述失败用例为执行所述测试操作后得到的所述用例结果为异常的测试用例；所述第二剩余测试用例为除所述失败用例之外的测试用例。

9.一种运维变更装置，其特征在于，所述装置包括：

获取单元，用于接收运维变更信息，所述运维变更信息包括待修改的目标数据，所述目标数据用于表征运维变更信息所对应的运维变更操作需修改的数据；

第一确定单元，用于基于所述目标数据获取对应所述目标数据的配置信息，并基于所述配置信息确定变更范围数据，所述变更范围数据为与所述目标数据存在依赖关系的数据；

第二确定单元，用于对所述变更范围数据执行测试操作，得到测试结果，并基于所述测试结果确定变更结果。

10.一种运维变更装置，其特征在于，所述装置包括存储介质；及一个或者多个处理器，所述存储介质与所述处理器耦合，所述处理器被配置为执行所述存储介质中存储的程序指令；所述程序指令运行时执行权利要求1至8中任一项所述的运维变更方法。