CN116974910A - 区块链sdk的持续交付方法、装置、存储介质以及电子设备 - Google Patents

Abstract

本申请公开了一种区块链SDK的持续交付方法、装置、存储介质以及电子设备。该方法包括：根据目标SDK的目标代码特性确定与目标代码特性对应的目标区块链产品包，其中，目标SDK为本次提交的版本；将目标区块链产品包部署在创建的容器中；在容器中执行与目标代码特性对应的第一测试用例，并输出第一测试报告，其中，第一测试用例为至少一个测试用例；在第一测试报告的第一测试结果全部为测试通过的情况下，执行目标SDK的发版命令。本申请解决了SDK发版流程自动化程度低的技术问题。

Description

区块链SDK的持续交付方法、装置、存储介质以及电子设备

技术领域

本申请涉及计算机领域，具体而言，涉及一种区块链SDK的持续交付方法、装置、存储介质以及电子设备。

背景技术

由于区块链SDK(Software Development Kit软件开发工具包)的测试流程需要强依赖区块链版本，且不同的SDK版本可能需要使用不同版本的区块链产品，甚至不同产品的区块链包。目前针对区块链SDK发版时，有几种方法。方法一、开发人员将SDK开发完成后，在本地部署该SDK依赖的区块链产品。开发人员完成单元测试后提交测试代码至代码管理平台远端(GitLab仓库管理系统、SVN(Subversion版本管理工具)等)。代码提交后，测试人员手动触发CD流程(通常为Jenkins搭建的任务)，选择此次SDK发版所依赖的区块链产品、区块链产品的版本，并执行全量测试，全量测试完成以后自动实现SDK的发版。该方法中虽然通过Jenkins这一持续集成工具实现了SDK在通过全量测试以后的自动发版过程，但是仍然处于半自动化状态。方法二、在单元测试、冒烟测试、全量测试以前，测试人员与开发人员沟通好该版本的区块链SDK所依赖的区块链产品，并在公共位置部署好区块链集群，以供开发人员进行单元测试、冒烟测试，以及测试人员进行全量测试。该方法虽然可以提高CICD的自动化程度，即可以让开发人员在一键提交代码后，自动运行各个阶段的测试，并在测试结束后自动发版。但该过程仍然需要强依赖于公共位置部署的区块链集群，仍然不能完全做到自动化，需要强依赖于公共平台的测试集群部署，当开发人员需要同时发布多个SDK版本时，对部署区块链的机器数量要求较多，容易导致资源紧缺，公用的区块链集群，容易造成不同阶段的测试用例之间相互干扰。

发明内容

本申请实施例提供了一种区块链SDK的持续交付方法、装置、存储介质以及电子设备，以至少解决SDK发版流程自动化程度低的技术问题。

根据本申请实施例的一个方面，提供了一种区块链SDK的持续交付方法，包括：根据目标SDK的目标代码特性确定与上述目标代码特性对应的目标区块链产品包，其中，上述目标SDK为本次提交的版本；将上述目标区块链产品包部署在创建的容器中；在上述容器中执行与上述目标代码特性对应的第一测试用例，并输出第一测试报告，其中，上述第一测试用例为至少一个测试用例；在上述第一测试报告的第一测试结果全部为测试通过的情况下，执行上述目标SDK的发版命令。

根据本申请实施例的另一方面，提供了一种区块链SDK的持续交付装置，包括：确定模块，用于根据目标SDK的目标代码特性确定与上述目标代码特性对应的目标区块链产品包，其中，上述目标SDK为本次提交的版本；部署模块，用于将上述目标区块链产品包部署在创建的容器中；第一执行模块，用于在上述容器中执行与上述目标代码特性对应的第一测试用例，并输出第一测试报告，其中，上述第一测试用例为至少一个测试用例；第二执行模块，用于在上述第一测试报告的第一测试结果全部为测试通过的情况下，执行上述目标SDK的发版命令。

作为一种可选的示例，上述确定模块包括：第一确定单元，用于在上述目标SDK为首次发布，且存在指定的区块链产品包的情况下，确定上述目标SDK的上述目标代码特性，并将上述指定的区块链产品包确定为与上述目标代码特性对应的上述目标区块链产品包；更新单元，用于根据上述指定的区块链产品包，将在数据库中的目标关系映射表中上述目标代码特性与上述目标区块链产品包的对应关系进行更新，其中，上述目标关系映射表中保存有代码特性与区块链产品包的对应关系。

作为一种可选的示例，上述确定模块包括：第二确定单元，用于在上述目标SDK为首次发布，且不存在指定的区块链产品包的情况下，确定上述目标SDK的上述目标代码特性，并在目标关系映射表中查找与上述目标代码特性对应的上述目标区块链产品包；第三确定单元，用于在上述目标SDK为非首次发布，且不存在指定的区块链产品包的情况下，根据上述目标SDK和第一SDK确定上述目标SDK的代码修改范围，其中，上述第一SDK为上述目标SDK的上一版SDK；第四确定单元，用于根据上述代码修改范围确定上述目标SDK的上述目标代码特性，并在上述目标关系映射表中查找与上述目标代码特性对应的上述目标区块链产品包。

作为一种可选的示例，上述第一执行模块包括：第五确定单元，用于根据上述目标代码特性确定与上述目标代码特性对应的上述第一测试用例；执行单元，用于将上述第一测试用例中的每一个测试用例作为当前测试用例，对上述当前测试用例执行如下操作：在上述容器中执行上述当前测试用例，同时统计当前测试覆盖率，输出对应的上述当前测试用例对应的当前测试报告，其中，上述当前测试报告为上述第一测试报告中的任意一个，上述当前测试报告包括当前测试结果、当前失败原因以及当前解决办法，上述当前解决办法是在数据库中的学习记录中根据上述当前失败原因查找得到的，上述学习记录中保存有上述当前失败原因对应的当前解决办法；在上述当前测试结果为测试通过，且上述当前测试覆盖率大于第一阈值的情况下，将下一个第一测试用例作为上述当前测试用例，直到上述第一测试用例中每一个测试用例都完成执行。

作为一种可选的示例，上述装置还包括：修改模块，用于在上述容器中执行上述当前测试用例，同时统计当前测试覆盖率，输出对应的上述当前测试用例对应的当前测试报告之后，在上述当前测试结果为未测试通过，或上述当前测试覆盖率小于或等于上述第一阈值的情况下，根据上述当前失败原因和当前解决办法对上述目标SDK进行修改，得到修改后的上述目标SDK。

作为一种可选的示例，上述装置还包括：第一获取模块，用于在上述容器中执行上述当前测试用例，同时统计当前测试覆盖率，输出对应的上述当前测试用例对应的当前测试报告之后，在上述当前测试结果为未测试通过，或上述当前测试覆盖率小于或等于上述第一阈值的情况下，获取用户根据当前失败原因得到的目标解决办法；更新模块，用于根据上述目标解决办法，将上述学习记录中的上述当前失败原因对应的解决办法进行更新。

作为一种可选的示例，上述装置还包括：检查模块，用于在上述容器中执行与上述目标代码特性对应的第一测试用例，并输出第一测试报告之后，在上述第一测试结果全部为测试通过的情况下，在上述容器中进行静态代码检查与漏洞扫描，并输出第二测试报告；处理模块，用于在上述第二测试报告中的第二测试结果为测试通过的情况下，将上述目标SDK的代码从GIT仓库的子分支合并至主分支；第二获取模块，用于获取第二测试用例，其中，上述第二测试用例为除上述第一测试用例外的所有测试用例；第三执行模块，用于在上述容器中执行上述第二测试用例，并输出第三测试报告；第四执行模块，用于在上述第三测试报告的第三测试结果全部为测试通过的情况下，执行上述目标SDK的发版命令。

根据本申请实施例的又一方面，还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被处理器运行时执行上述区块链SDK的持续交付方法。

根据本申请实施例的又一方面，还提供了一种电子设备，包括存储器和处理器，上述存储器中存储有计算机程序，上述处理器被设置为通过所述计算机程序执行上述的区块链SDK的持续交付方法。

在本申请实施例中，采用了根据目标SDK的目标代码特性确定与上述目标代码特性对应的目标区块链产品包，其中，上述目标SDK为本次提交的版本；将上述目标区块链产品包部署在创建的容器中；在上述容器中执行与上述目标代码特性对应的第一测试用例，并输出第一测试报告，其中，上述第一测试用例为至少一个测试用例；在上述第一测试报告的第一测试结果全部为测试通过的情况下，执行上述目标SDK的发版命令的方法，由于在上述方法中，通过动态选择目标SDK所对应的目标区块链产品包，自动部署区块链集群并自动触发测试流程，测试完成后，自动发布目标SDK，从而实现了SDK发版的全自动化的目的，进而解决了SDK发版流程自动化程度低的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种可选的区块链SDK的持续交付方法的流程图；

图2是根据本申请实施例的一种可选的区块链SDK的持续交付方法的框架图；

图3是根据本申请实施例的一种可选的区块链SDK的持续交付方法的主要流程图；

图4是根据本申请实施例的一种可选的区块链SDK的持续交付方法的调度模块图；

图5是根据本申请实施例的一种可选的区块链SDK的持续交付装置的结构示意图；

图6是根据本申请实施例的一种可选的电子设备的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本申请实施例的第一方面，提供了一种区块链SDK的持续交付方法，可选地，如图1所示，上述方法包括：

S102，根据目标SDK的目标代码特性确定与目标代码特性对应的目标区块链产品包，其中，目标SDK为本次提交的版本；

S104，将目标区块链产品包部署在创建的容器中；

S106，在容器中执行与目标代码特性对应的第一测试用例，并输出第一测试报告，其中，第一测试用例为至少一个测试用例；

S108，在第一测试报告的第一测试结果全部为测试通过的情况下，执行目标SDK的发版命令。

可选地，本实施例中，SDK(Software Development Kit软件开发工具包)，软件开发工具包一般是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。代码特性可以为did、系统升级、零知识证明等特性。区块链产品包可以为hyperchain V1.0.0产品包、hyperchian V1.1.0产品包、Fabric V2.0产品包等，hyperchain V1.0.0产品包与hyperchian V1.1.0产品包是相同区块链产品不同版本，hyperchain V1.0.0产品包与Fabric V2.0产品包为不同区块链产品。

可选地，本实施例中，如图2所示，确定区块链产品包与SDK版本的代码特性的对应关系，并存储至数据库中。开发人员完成目标SDK的代码开发或修改工作，并将目标SDK的代码推送至代码管理工具的远端服务器。持续集成工具Jenkins识别到代码推送动作，触发区块链调度模块中的相关代码，识别目标SDK的目标代码特性并确定所对应的目标区块链产品包。将目标区块链产品包部署区块链集群容器(如Docker)中，以区分不同任务中的区块链集群。运行目标SDK的第一测试用例，第一测试用例可以为至少一个，例如，单元测试用例、冒烟测试用例等，每执行一个测试用例，输出一个测试报告。在第一测试用例中的所有测试用例测试通过后，自动执行目标SDK的发版命令。

可选地，本实施例中，通过动态选择目标SDK所对应的目标区块链产品包，自动部署区块链集群并自动触发测试流程，测试完成后，自动发布目标SDK，从而实现了SDK发版的全自动化的目的，进而解决了SDK发版流程自动化程度低的技术问题。

作为一种可选的示例，根据目标SDK的目标代码特性确定与目标代码特性对应的目标区块链产品包包括：

在目标SDK为首次发布，且存在指定的区块链产品包的情况下，确定目标SDK的目标代码特性，并将指定的区块链产品包确定为与目标代码特性对应的目标区块链产品包；

根据指定的区块链产品包，将在数据库中的目标关系映射表中目标代码特性与目标区块链产品包的对应关系进行更新，其中，目标关系映射表中保存有代码特性与区块链产品包的对应关系。

可选地，本实施例中，持续集成工具Jenkins在识别目标SDK的代码推送动作之后，首先确定目标SDK是否为首次发布，若是，则确定开发人员在提交目标SDK的代码时是否指定了其依赖的区块链产品包，若指定了，则将指定的区块链产品包确定为与目标代码特性对应的目标区块链产品包，并记录在数据库中的记录了SDK的代码特性与区块链产品包的对应关系的目标关系映射表中。若目标SDK为非首次发布，但开发人员在提交目标SDK的代码时指定了其依赖的区块链产品包，则获取目标SDK的上一版SDK，根据上一版SDK与本次提交的目标SDK确定本次的代码修改范围，确定代码修改范围的目标代码特性，最后将目标代码特性与指定的区块链产品包的对应关系记录在目标关系映射表中。

作为一种可选的示例，根据目标SDK的目标代码特性确定与目标代码特性对应的目标区块链产品包包括：

在目标SDK为首次发布，且不存在指定的区块链产品包的情况下，确定目标SDK的目标代码特性，并在目标关系映射表中查找与目标代码特性对应的目标区块链产品包；

在目标SDK为非首次发布，且不存在指定的区块链产品包的情况下，根据目标SDK和第一SDK确定目标SDK的代码修改范围，其中，第一SDK为目标SDK的上一版SDK；

根据代码修改范围确定目标SDK的目标代码特性，并在目标关系映射表中查找与目标代码特性对应的目标区块链产品包。

可选地，本实施例中，若目标SDK是首次发布，且开发人员在提交目标SDK的代码时未指定其依赖的区块链产品包，则在目标关系映射表中查找与目标SDK的目标代码特性对应的目标区块链产品包。若目标SDK不是首次发布，且开发人员在提交目标SDK的代码时未指定其依赖的区块链产品包，获取目标SDK的上一版SDK，根据上一版SDK与本次提交的目标SDK确定本次的代码修改范围，确定代码修改范围的目标代码特性，最后在目标关系映射表中查找与目标代码特性对应的目标区块链产品包。

作为一种可选的示例，在容器中执行与目标代码特性对应的第一测试用例，并输出第一测试报告包括：

根据目标代码特性确定与目标代码特性对应的第一测试用例；

将第一测试用例中的每一个测试用例作为当前测试用例，对当前测试用例执行如下操作：

在容器中执行当前测试用例，同时统计当前测试覆盖率，输出对应的当前测试用例对应的当前测试报告，其中，当前测试报告为第一测试报告中的任意一个，当前测试报告包括当前测试结果、当前失败原因以及当前解决办法，当前解决办法是在数据库中的学习记录中根据当前失败原因查找得到的，学习记录中保存有当前失败原因对应的当前解决办法；

在当前测试结果为测试通过，且当前测试覆盖率大于第一阈值的情况下，将下一个第一测试用例作为当前测试用例，直到第一测试用例中每一个测试用例都完成执行。

可选地，本实施例中，容器中执行与目标代码特性对应的第一测试用例时，根据目标代码特性确定每一个第一测试用例，例如第一测试用例包括单元测试用例和冒烟测试用例，在容器中先执行单元测试用例，并统计测试覆盖率，当单元测试用例未通过时，则通过机器学习模型分析单元测试用例失败的原因，并尝试给出解决办法。如果之前没有类似的失败场景，则给出失败原因以帮助开发人员快速定位失败原因，并在下次重建该任务时，学习并更新该问题的解决方案。当单元测试用例通过时，仍然需要对测试覆盖率进行统计，如果测试覆盖率低于设定的第一阈值，仍需要退出CICD流程，并给出任务失败原因。当单元测试用例通过，且测试覆盖率大于第一阈值，继续执行冒烟测试用例，与上一个测试用例相同，若未通过，则输出该测试用例的测试结果、失败原因以及解决办法，同时学习开发人员给出的解决方法并记录在数据库中的学习记录中。

作为一种可选的示例，在容器中执行当前测试用例，同时统计当前测试覆盖率，输出对应的当前测试用例对应的当前测试报告之后，上述方法还包括：

在当前测试结果为未测试通过，或当前测试覆盖率小于或等于第一阈值的情况下，根据当前失败原因和当前解决办法对目标SDK进行修改，得到修改后的目标SDK。

可选地，本实施例中，当单元测试用例未通过，或测试覆盖率小于或等于第一阈值，机器学习模型可以分析出失败原因和解决方法时，根据失败原因和解决办法对目标SDK进行修改，得到修改后的目标SDK，并将修改后的SDK自动重跑任务。

作为一种可选的示例，在容器中执行当前测试用例，同时统计当前测试覆盖率，输出对应的当前测试用例对应的当前测试报告之后，上述方法还包括：

在当前测试结果为未测试通过，或当前测试覆盖率小于或等于第一阈值的情况下，获取用户根据当前失败原因得到的目标解决办法；

根据目标解决办法，将学习记录中的当前失败原因对应的解决办法进行更新。

可选地，本实施例中，当单元测试用例未通过，或测试覆盖率小于或等于第一阈值，机器学习模型未分析出失败原因和解决方法时，学习开发人员给出的目标解决方法，并记录在数据库中的学习记录中。

作为一种可选的示例，在容器中执行与目标代码特性对应的第一测试用例，并输出第一测试报告之后，上述方法还包括：

在第一测试结果全部为测试通过的情况下，在容器中进行静态代码检查与漏洞扫描，并输出第二测试报告；

在第二测试报告中的第二测试结果为测试通过的情况下，将目标SDK的代码从GIT仓库的子分支合并至主分支；

获取第二测试用例，其中，第二测试用例为除第一测试用例外的所有测试用例；

在容器中执行第二测试用例，并输出第三测试报告；

在第三测试报告的第三测试结果全部为测试通过的情况下，执行目标SDK的发版命令。

可选地，本实施例中，在第一测试用例全部测试通过之后，对目标SDK进行静态代码检查和漏洞检查，可以查找到目标SDK代码中可能存在的潜在问题、高危漏洞等，并生成第二测试报告。上述测试都通过后，获取除第一测试用例外的所有测试用例，并执行每一个测试用例，输出一个测试报告，全部测试通过后执行目标SDK的发版命令。

可选地，本申请涉及一种区块链SDK的持续交付方法，框架图如图2所示，具体流程如下，如图3所示，：

1、确定区块链产品包与SDK版本对应关系的初始值，并存储至数据库中。

2、开发人员完成区块链SDK的代码开发或修改工作，并将代码推送至代码管理工具的远端服务器。

3、持续集成工具Jenkins识别到代码推送动作，触发区块链调度模块中的相关代码，识别SDK代码修改的范围并确定所依赖的区块链产品包。首先根据SDK代码修改的范围，在数据库中查找是否存在对应的区块链产品，如果存在对应关系，则执行步骤4，否则提示无法确定SDK版本与区块链版本的对应关系，退出CICD流程。如果不存在对应关系，但是开发人员在提交代码时指定了其依赖的区块链产品包，则记录该依赖关系，给出区块链产品包或下载链接。

4、将步骤3中选择的区块链产品包部署区块链集群容器(如Docker)中，以区分不同任务中的区块链集群。

5、运行SDK的单元测试、冒烟测试、全量测试，同时对SDK修改的代码进行测试覆盖率统计、安全漏洞扫描。

6、步骤5中的单元测试、冒烟测试、全量测试均测试通过且测试覆盖率满足设定的阈值后，自动执行发版操作。如果步骤5中的单元测试、冒烟测试、全量测试不通过，则对失败原因进行分析，对于常见的错误原因给出解决方案提示，并退出CICD流程。如果步骤5中的测试覆盖率不足设定的阈值，则给出低于阈值的具体模块。如果步骤5中的安全漏洞扫描不通过，则给出具体原因以及修改建议。

可选地，上述方法包括区块链调度模块，如图4所示，区块链调度模块是一段程序代码，用来分析SDK修改的代码范围，并根据修改的SDK代码确定其依赖的区块链包。开发人员指定本次SDK开发或修改的代码所依赖的区块链产品包。如果开发人员在上传SDK的开发或修改代码时，指定其依赖的区块链产品包，则对所依赖的区块链产品，与SDK代码进行机器学习，更新SDK代码与区块链产品包对应关系。如果开发人员在上传SDK的开发或修改代码时，不指定其依赖的区块链产品包，则分析本次SDK开发或修改代码范围，并根据SDK代码与区块链产品包的对应关系在数据库中查找对应的区块链产品包。在SDK的CICD流程中，如果某一阶段未通过，在重新构建任务时，需要重新确定后续测试过程中依赖的区块链产品包。重新分析SDK开发或修改的代码范围与上次任务时的范围是否有差异，如果未变更或变更范围不大，则继续沿用上次任务时使用的区块链产品包。如果变更涉及到到需要修改区块链产品包，则更新SDK代码与区块链产品对应关系。如果无法确定与本次提交的SDK代码对应的区块链产品，则退出CICD流程并给出相应提示。并在下次构建任务时，学习并记录开发人员人工输入的区块链产品包，并更新SDK代码与区块链产品对应关系。在确定好区块链产品后，将区块链产品包或下载路径传递给下游任务。

可选地，上述方法为了使不同构建任务之间的区块链集群环境互相之间没有影响，采用容器技术(如Docker)进行资源隔离。每个任务使用单独的容器进行区块链部署，并将集群访问端口映射出来以供单元测试、冒烟测试、全量测试等场景使用。

可选地，在确定好区块链集群并完成环境搭建以后，上述方法还需要开展持续测试流程：

1、单元测试，执行开发人员编写的单测代码，并统计测试覆盖率。当单元测试未通过时，则通过机器学习模型分析单元测试失败的原因，并尝试给出解决办法。如果之前没有类似的失败场景，则给出失败原因以帮助开发人员快速定位失败原因，并在下次重建该任务时，学习并更新该问题的解决办法。当单元测试通过时，仍然需要对测试覆盖率进行统计，如果测试覆盖率低于设定的阈值，仍需要退出CICD流程，并给出任务失败原因。

2、冒烟测试，SDK的发版在执行完开发人员编写的单元测试用例后，仍然需要完成测试人员编写的冒烟测试代码。该流程用来满足测试部门需要验证的SDK功能。冒烟测试的内容与单元测试的侧重点不同，冒烟测试用例为测试人员编写更侧重于重点模块或P0级用例的测试。且只有冒烟测试通过以后，SDK的测试代码才能从子分支合并进主分支中。如果测试不通过，则仍然能够给出用例失败的原因、常见问题的解决方法以及测试报告，便于测试人员快速定位问题。

3、全量测试，在SDK的代码从子分支合入主分支后、正式发版前，需要运行全量测试或回归测试，用于确定SDK的修改是否会引起其他模块的新缺陷。如果测试全部通过，则执行后续步骤。否则能够给出用例失败的原因、常见问题的解决办法以及测试报告，便于测试人员快速定位问题。其中，测试报告集成了Allure可视化测试报告工具，用来展示上述单元测试、冒烟测试、全量测试中的测试结果、问题日志、常见问题解决办法等。

4、静态代码检查与漏洞扫描，用来指出不规范的代码问题、可能存在的隐患以及漏洞，并给出相应的解决办法。

可选地，上述方法包括还包括机器学习训练模型，用于分析SDK代码与区块链产品对应关系。当SDK开发或修改完成时，如果开发人员指定本次涉及到SDK代码段所依赖的区块链产品包，则分析、学习并记录该次对应关系。如果开发人员未指定本次SDK代码所依赖的区块链产品包，则分析SDK代码的修改范围，并从已有的关系中给出区块链产品包。以此往复，逐渐优化机器学习模型以便给出与SDK代码更匹配的区块链产品。还用于分析测试过程中的失败原因以及解决办法。当在单元测试、冒烟测试、全量测试阶段中出现测试用例失败的情况，分析用例失败的原因，学习并记录测试人员给出的解决办法。以便在下次出现类似问题时，能够给出准确的解决办法。以此往复，逐渐优化机器学习模型，给出更精准的问题解决方案，并针对简单问题能够实现自动修复。

结合一中示例进行说明，上述区块链SDK的持续交付方法包含以下步骤：

1、给出区块链产品包与SDK对应关系初始模型。部分关系为did相关特性代码需要使用hyperchainV1.0.0产品包；系统升级相关特性需要使用hyperchian V1.1.0产品包；零知识证明相关特性代码需要使用FabricV2.0产品包。hyperchainV1.0.0产品包、hyperchian V1.1.0产品包为相同区块链产品的不同版本，hyperchainV1.0.0产品包、FabricV2.0产品包为不同区块链产品。上述did、系统升级、零知识证明仅为部分特性的举例。

2、开发人员完成SDK关于did特性的代码开发或修改，并将代码从Git仓库的子分支合并至主分支，并推送至代码管理平台(GitLab)的远程服务端。

3、持续集成工具Jenkins捕捉到此次代码推送的动作，调用区块链产品调度模块代码。分析本次代码提交修改的代码段为did相关特性代码，则给出hyperchainV1.0.0产品包的下载链接至下游任务。

4、下游任务在获取到区块链产品包后，创建容器并部署区块链集群，并将区块链集群信息传递给测试单元。如ip地址、端口、账户、密码等信息。

5、在部署好区块链集群后，执行SDK代码的单元测试。如果测试失败，则给出失败原因、常见问题解决办法并退出。如表1所示：

(表1)

如果本次用例失败，机器模型无法给出解决办法。则自动学习并记录，在下次重建任务时学习开发人员给出的解决办法并记录，更新机器学习模型。如果机器模型能够给出正确的解决办法，如第一个失败问题，则修改后自动重跑任务。测试通过后，执行后续步骤。

6、进行冒烟测试，执行测试部门编写的冒烟测试用例，用来对重点场景、优先级高的测试场景展开更全面的测试。如果测试失败，则同单元测试，机器学习模型给出常见问题解决办法、系统日志等信息。测试通过后，执行后续步骤。

7、执行静态代码检查和漏洞扫描，指出代码中可能存在的潜在问题、高危漏洞等，并给出解决办法。(此步骤也可放置于单元测试以前)

8、单元测试、冒烟测试与代码检查通过后，子分支代码自动合入主分支。并触发全量测试，运行所有模块的测试用例，以验证除did模块以外的其他模块是否有因此次代码修改引起的问题。如果测试失败，则同单元测试，机器学习模型给出常见问题解决办法、系统日志等信息。并展示在测试报告中，该测试报告在Allure工具中显示，包含各模块测试分析、通过率、历史失败信息等信息。测试通过后，执行后续步骤。

9、等上述步骤都完成以后，自动执行SDK发版命令。

可选地，通过上述流程，从而可以全自动化实现区块链SDK的发版流程，提高SDK发版效率，解决区块链SDK发版时CI、CD流程衔接不流畅的问题。上述方法在SDK发版时无需人工选择对应的区块链版本，从而可以减少人工干预步骤，释放人力资源。上述方法在测试过程中出现用例失败时，自动给出合理的解决办法，从而可以减少测试分析的时间。通过隔离区块链集群环境，从而可以减少不同SDK发版任务之间的环境干扰，提升SDK并行发版的能力。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

根据本申请实施例的另一方面，还提供了一种区块链SDK的持续交付装置，如图5所示，包括：

确定模块502，用于根据目标SDK的目标代码特性确定与目标代码特性对应的目标区块链产品包，其中，目标SDK为本次提交的版本；

部署模块504，用于将目标区块链产品包部署在创建的容器中；

第一执行模块506，用于在容器中执行与目标代码特性对应的第一测试用例，并输出第一测试报告，其中，第一测试用例为至少一个测试用例；

第二执行模块508，用于在第一测试报告的第一测试结果全部为测试通过的情况下，执行目标SDK的发版命令。

可选地，本实施例中，SDK(Software Development Kit软件开发工具包)，软件开发工具包一般是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。代码特性可以为did、系统升级、零知识证明等特性。区块链产品包可以为hyperchain V1.0.0产品包、hyperchian V1.1.0产品包、Fabric V2.0产品包等，hyperchain V1.0.0产品包与hyperchian V1.1.0产品包是相同区块链产品不同版本，hyperchain V1.0.0产品包与Fabric V2.0产品包为不同区块链产品。

可选地，本实施例中，如图2所示，确定区块链产品包与SDK版本的代码特性的对应关系，并存储至数据库中。开发人员完成目标SDK的代码开发或修改工作，并将目标SDK的代码推送至代码管理工具的远端服务器。持续集成工具Jenkins识别到代码推送动作，触发区块链调度模块中的相关代码，识别目标SDK的目标代码特性并确定所对应的目标区块链产品包。将目标区块链产品包部署区块链集群容器(如Docker)中，以区分不同任务中的区块链集群。运行目标SDK的第一测试用例，第一测试用例可以为至少一个，例如，单元测试用例、冒烟测试用例等，每执行一个测试用例，输出一个测试报告。在第一测试用例中的所有测试用例测试通过后，自动执行目标SDK的发版命令。

可选地，本实施例中，通过动态选择目标SDK所对应的目标区块链产品包，自动部署区块链集群并自动触发测试流程，测试完成后，自动发布目标SDK，从而实现了SDK发版的全自动化的目的，进而解决了SDK发版流程自动化程度低的技术问题。

作为一种可选的示例，确定模块包括：

第一确定单元，用于在目标SDK为首次发布，且存在指定的区块链产品包的情况下，确定目标SDK的目标代码特性，并将指定的区块链产品包确定为与目标代码特性对应的目标区块链产品包；

更新单元，用于根据指定的区块链产品包，将在数据库中的目标关系映射表中目标代码特性与目标区块链产品包的对应关系进行更新，其中，目标关系映射表中保存有代码特性与区块链产品包的对应关系。

可选地，本实施例中，持续集成工具Jenkins在识别目标SDK的代码推送动作之后，首先确定目标SDK是否为首次发布，若是，则确定开发人员在提交目标SDK的代码时是否指定了其依赖的区块链产品包，若指定了，则将指定的区块链产品包确定为与目标代码特性对应的目标区块链产品包，并记录在数据库中的记录了SDK的代码特性与区块链产品包的对应关系的目标关系映射表中。若目标SDK为非首次发布，但开发人员在提交目标SDK的代码时指定了其依赖的区块链产品包，则获取目标SDK的上一版SDK，根据上一版SDK与本次提交的目标SDK确定本次的代码修改范围，确定代码修改范围的目标代码特性，最后将目标代码特性与指定的区块链产品包的对应关系记录在目标关系映射表中。

作为一种可选的示例，确定模块包括：

第二确定单元，用于在目标SDK为首次发布，且不存在指定的区块链产品包的情况下，确定目标SDK的目标代码特性，并在目标关系映射表中查找与目标代码特性对应的目标区块链产品包；

第三确定单元，用于在目标SDK为非首次发布，且不存在指定的区块链产品包的情况下，根据目标SDK和第一SDK确定目标SDK的代码修改范围，其中，第一SDK为目标SDK的上一版SDK；

第四确定单元，用于根据代码修改范围确定目标SDK的目标代码特性，并在目标关系映射表中查找与目标代码特性对应的目标区块链产品包。

可选地，本实施例中，若目标SDK是首次发布，且开发人员在提交目标SDK的代码时未指定其依赖的区块链产品包，则在目标关系映射表中查找与目标SDK的目标代码特性对应的目标区块链产品包。若目标SDK不是首次发布，且开发人员在提交目标SDK的代码时未指定其依赖的区块链产品包，获取目标SDK的上一版SDK，根据上一版SDK与本次提交的目标SDK确定本次的代码修改范围，确定代码修改范围的目标代码特性，最后在目标关系映射表中查找与目标代码特性对应的目标区块链产品包。

作为一种可选的示例，第一执行模块包括：

第五确定单元，用于根据目标代码特性确定与目标代码特性对应的第一测试用例；

执行单元，用于将第一测试用例中的每一个测试用例作为当前测试用例，对当前测试用例执行如下操作：

在容器中执行当前测试用例，同时统计当前测试覆盖率，输出对应的当前测试用例对应的当前测试报告，其中，当前测试报告为第一测试报告中的任意一个，当前测试报告包括当前测试结果、当前失败原因以及当前解决办法，当前解决办法是在数据库中的学习记录中根据当前失败原因查找得到的，学习记录中保存有当前失败原因对应的当前解决办法；

在当前测试结果为测试通过，且当前测试覆盖率大于第一阈值的情况下，将下一个第一测试用例作为当前测试用例，直到第一测试用例中每一个测试用例都完成执行。

可选地，本实施例中，容器中执行与目标代码特性对应的第一测试用例时，根据目标代码特性确定每一个第一测试用例，例如第一测试用例包括单元测试用例和冒烟测试用例，在容器中先执行单元测试用例，并统计测试覆盖率，当单元测试用例未通过时，则通过机器学习模型分析单元测试用例失败的原因，并尝试给出解决办法。如果之前没有类似的失败场景，则给出失败原因以帮助开发人员快速定位失败原因，并在下次重建该任务时，学习并更新该问题的解决方案。当单元测试用例通过时，仍然需要对测试覆盖率进行统计，如果测试覆盖率低于设定的第一阈值，仍需要退出CICD流程，并给出任务失败原因。当单元测试用例通过，且测试覆盖率大于第一阈值，继续执行冒烟测试用例，与上一个测试用例相同，若未通过，则输出该测试用例的测试结果、失败原因以及解决办法，同时学习开发人员给出的解决方法并记录在数据库中的学习记录中。

作为一种可选的示例，上述装置还包括：

修改模块，用于在容器中执行当前测试用例，同时统计当前测试覆盖率，输出对应的当前测试用例对应的当前测试报告之后，在当前测试结果为未测试通过，或当前测试覆盖率小于或等于第一阈值的情况下，根据当前失败原因和当前解决办法对目标SDK进行修改，得到修改后的目标SDK。

可选地，本实施例中，当单元测试用例未通过，或测试覆盖率小于或等于第一阈值，机器学习模型可以分析出失败原因和解决方法时，根据失败原因和解决办法对目标SDK进行修改，得到修改后的目标SDK，并将修改后的SDK自动重跑任务。

作为一种可选的示例，上述装置还包括：

第一获取模块，用于在容器中执行当前测试用例，同时统计当前测试覆盖率，输出对应的当前测试用例对应的当前测试报告之后，在当前测试结果为未测试通过，或当前测试覆盖率小于或等于第一阈值的情况下，获取用户根据当前失败原因得到的目标解决办法；

更新模块，用于根据目标解决办法，将学习记录中的当前失败原因对应的解决办法进行更新。

可选地，本实施例中，当单元测试用例未通过，或测试覆盖率小于或等于第一阈值，机器学习模型未分析出失败原因和解决方法时，学习开发人员给出的目标解决方法，并记录在数据库中的学习记录中。

作为一种可选的示例，上述装置还包括：

检查模块，用于在容器中执行与目标代码特性对应的第一测试用例，并输出第一测试报告之后，在第一测试结果全部为测试通过的情况下，在容器中进行静态代码检查与漏洞扫描，并输出第二测试报告；

处理模块，用于在第二测试报告中的第二测试结果为测试通过的情况下，将目标SDK的代码从GIT仓库的子分支合并至主分支；

第二获取模块，用于获取第二测试用例，其中，第二测试用例为除第一测试用例外的所有测试用例；

第三执行模块，用于在容器中执行第二测试用例，并输出第三测试报告；

第四执行模块，用于在第三测试报告的第三测试结果全部为测试通过的情况下，执行目标SDK的发版命令。

可选地，本实施例中，在第一测试用例全部测试通过之后，对目标SDK进行静态代码检查和漏洞检查，可以查找到目标SDK代码中可能存在的潜在问题、高危漏洞等，并生成第二测试报告。上述测试都通过后，获取除第一测试用例外的所有测试用例，并执行每一个测试用例，输出一个测试报告，全部测试通过后执行目标SDK的发版命令。

本实施例的其他示例请参见上述示例，在此不在赘述。

图6是根据本申请实施例的一种可选的电子设备的示意图，如图6所示，包括处理器602、通信接口604、存储器606和通信总线608，其中，处理器602、通信接口604和存储器606通过通信总线608完成相互间的通信，其中，

存储器606，用于存储计算机程序；

处理器602，用于执行存储器606上所存放的计算机程序时，实现如下步骤：

根据目标SDK的目标代码特性确定与目标代码特性对应的目标区块链产品包，其中，目标SDK为本次提交的版本；

将目标区块链产品包部署在创建的容器中；

在容器中执行与目标代码特性对应的第一测试用例，并输出第一测试报告，其中，第一测试用例为至少一个测试用例；

在第一测试报告的第一测试结果全部为测试通过的情况下，执行目标SDK的发版命令。

可选地，在本实施例中，上述的通信总线可以是PCI(Peripheral ComponentInterconnect，外设部件互连标准)总线、或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括RAM，也可以包括非易失性存储器(non-volatile memory)，例如，至少一个磁盘存储器。可选地，存储器还可以是至少一个位于远离前述处理器的存储装置。

作为一种示例，上述存储器606中可以但不限于包括上述区块链SDK的持续交付装置中的确定模块502、部署模块504、第一执行模块506以及第二执行模块508。此外，还可以包括但不限于上述区块链SDK的持续交付装置中的其他模块单元，本示例中不再赘述。

上述处理器可以是通用处理器，可以包含但不限于：CPU(Central ProcessingUnit，中央处理器)、NP(Network Processor，网络处理器)等；还可以是DSP(DigitalSignal Processing，数字信号处理器)、ASIC(Application Specific IntegratedCircuit，专用集成电路)、FPGA(Field －Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图6所示的结构仅为示意，实施上述区块链SDK的持续交付方法的设备可以是终端设备，该终端设备可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile Internet Devices，MID)、PAD等终端设备。图6并不对上述电子设备的结构造成限定。例如，电子设备还可包括比图6中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图6所示的不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、ROM、RAM、磁盘或光盘等。

根据本申请的实施例的又一方面，还提供了一种计算机可读的存储介质，该计算机可读的存储介质中存储有计算机程序，其中，该计算机程序被处理器运行时执行上述区块链SDK的持续交付方法中的步骤。

可选地，在本实施例中，本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random Access Memory，RAM)、磁盘或光盘等。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种区块链SDK的持续交付方法，其特征在于，包括：

根据目标SDK的目标代码特性确定与所述目标代码特性对应的目标区块链产品包，其中，所述目标SDK为本次提交的版本；

将所述目标区块链产品包部署在创建的容器中；

在所述容器中执行与所述目标代码特性对应的第一测试用例，并输出第一测试报告，其中，所述第一测试用例为至少一个测试用例；

在所述第一测试报告的第一测试结果全部为测试通过的情况下，执行所述目标SDK的发版命令。

2.根据权利要求1所述的方法，其特征在于，所述根据目标SDK的目标代码特性确定与所述目标代码特性对应的目标区块链产品包包括：

在所述目标SDK为首次发布，且存在指定的区块链产品包的情况下，确定所述目标SDK的所述目标代码特性，并将所述指定的区块链产品包确定为与所述目标代码特性对应的所述目标区块链产品包；

根据所述指定的区块链产品包，将在数据库中的目标关系映射表中所述目标代码特性与所述目标区块链产品包的对应关系进行更新，其中，所述目标关系映射表中保存有代码特性与区块链产品包的对应关系。

3.根据权利要求1所述的方法，其特征在于，所述根据目标SDK的目标代码特性确定与所述目标代码特性对应的目标区块链产品包包括：

在所述目标SDK为首次发布，且不存在指定的区块链产品包的情况下，确定所述目标SDK的所述目标代码特性，并在目标关系映射表中查找与所述目标代码特性对应的所述目标区块链产品包；

在所述目标SDK为非首次发布，且不存在指定的区块链产品包的情况下，根据所述目标SDK和第一SDK确定所述目标SDK的代码修改范围，其中，所述第一SDK为所述目标SDK的上一版SDK；

根据所述代码修改范围确定所述目标SDK的所述目标代码特性，并在所述目标关系映射表中查找与所述目标代码特性对应的所述目标区块链产品包。

4.根据权利要求1所述的方法，其特征在于，所述在所述容器中执行与所述目标代码特性对应的第一测试用例，并输出第一测试报告包括：

根据所述目标代码特性确定与所述目标代码特性对应的所述第一测试用例；

将所述第一测试用例中的每一个测试用例作为当前测试用例，对所述当前测试用例执行如下操作：

在所述容器中执行所述当前测试用例，同时统计当前测试覆盖率，输出对应的所述当前测试用例对应的当前测试报告，其中，所述当前测试报告为所述第一测试报告中的任意一个，所述当前测试报告包括当前测试结果、当前失败原因以及当前解决办法，所述当前解决办法是在数据库中的学习记录中根据所述当前失败原因查找得到的，所述学习记录中保存有所述当前失败原因对应的当前解决办法；

在所述当前测试结果为测试通过，且所述当前测试覆盖率大于第一阈值的情况下，将下一个第一测试用例作为所述当前测试用例，直到所述第一测试用例中每一个测试用例都完成执行。

5.根据权利要求4所述的方法，其特征在于，在所述容器中执行所述当前测试用例，同时统计当前测试覆盖率，输出对应的所述当前测试用例对应的当前测试报告之后，所述方法还包括：

在所述当前测试结果为未测试通过，或所述当前测试覆盖率小于或等于所述第一阈值的情况下，根据所述当前失败原因和当前解决办法对所述目标SDK进行修改，得到修改后的所述目标SDK。

6.根据权利要求4所述的方法，其特征在于，在所述容器中执行所述当前测试用例，同时统计当前测试覆盖率，输出对应的所述当前测试用例对应的当前测试报告之后，所述方法还包括：

在所述当前测试结果为未测试通过，或所述当前测试覆盖率小于或等于所述第一阈值的情况下，获取用户根据当前失败原因得到的目标解决办法；

根据所述目标解决办法，将所述学习记录中的所述当前失败原因对应的解决办法进行更新。

7.根据权利要求1所述的方法，其特征在于，在所述容器中执行与所述目标代码特性对应的第一测试用例，并输出第一测试报告之后，所述方法还包括：

在所述第一测试结果全部为测试通过的情况下，在所述容器中进行静态代码检查与漏洞扫描，并输出第二测试报告；

在所述第二测试报告中的第二测试结果为测试通过的情况下，将所述目标SDK的代码从GIT仓库的子分支合并至主分支；

获取第二测试用例，其中，所述第二测试用例为除所述第一测试用例外的所有测试用例；

在所述容器中执行所述第二测试用例，并输出第三测试报告；

在所述第三测试报告的第三测试结果全部为测试通过的情况下，执行所述目标SDK的发版命令。

8.一种区块链SDK的持续交付装置，其特征在于，包括：

第一确定模块，用于根据目标SDK的目标代码特性确定与所述目标代码特性对应的目标区块链产品包，其中，所述目标SDK为本次提交的版本；

部署模块，用于将所述目标区块链产品包部署在创建的容器中；

第一执行模块，用于在所述容器中执行与所述目标代码特性对应的第一测试用例，并输出第一测试报告，其中，所述第一测试用例为至少一个测试用例；

第二执行模块，用于在所述第一测试报告的第一测试结果全部为测试通过的情况下，执行所述目标SDK的发版命令。

9.一种计算机可读的存储介质，所述计算机可读的存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器运行时执行所述权利要求1至7任一项中所述的方法。

10.一种电子设备，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为通过所述计算机程序执行所述权利要求1至7任一项中所述的方法。