CN115080351A - 一种系统交互方法、装置、设备及介质 - Google Patents

Abstract

本申请公开了一种系统交互方法，涉及计算机领域，该方法包括：按照预设监测方法监测预设需求管理系统中项目的执行状态，将满足预设第一条件的项目确定为第一目标项目，向预设需求管理系统发送阶段更新指令；预设需求管理系统接收到阶段更新指令，将第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，从预设测试用例管理系统查询其用例执行结果；若结果为执行失败，则通过预设缺陷管理系统确定第二目标项目的bug信息中的bug状态；基于bug状态与用例执行结果确定实际需求执行阶段，并判断当前需求阶段与实际需求阶段是否一致；若不一致，将当前需求阶段更新为实际需求阶段。本发明在分平台管理需求、用例、bug时可降低测试成本。

Description

一种系统交互方法、装置、设备及介质

技术领域

本发明涉及计算机领域，特别涉及一种系统交互方法、装置、设备及介质。

背景技术

随着科技和网络的发展，需求管理系统、用例管理系统、缺陷管理系统越来越多，其中，禅道、jira、metersphere等开源的开发管理软件，在日常工作中广为大家所用。但因各个公司业务差别，有时需要将需求、用例和bug放在不同系统上进行维护，此时，因为各个软件之间本身并不互通，当测试人员执行需求的测试或提交Bug时，只能通过手动的形式实现关联。而其中，禅道内的需求研发阶段是需求管理的重要参数，该参数可选项一般包括：未开始(wait)、已计划(planned)、已立项(projected)、已关闭(closed)、研发中(developing)、研发完毕(developed)、已提测(showcase)、测试中(testing)、测试完毕(tested)等，项目管理人员可以通过该指标来确认需求当前所处阶段，从而判断项目进度是否正常。

当前，若需求、用例、bug需要分别在多平台管理(例如禅道、metersphere、jira)时，当更新禅道内需求所属阶段时，需要人为根据用例管理系统上的多条用例执行情况计算出需求所属阶段，再去禅道内找到对应需求，逐条更改需求的研发阶段，可能存在更新错误等不确定情况，造成了时间和人力的巨大浪费。

由上可见，在项目需求测试的过程中，如何避免出现由于手工关联系统导致需求管理系统中的项目进度更新操作复杂费力的情况是本领域有待解决的问题。

发明内容

有鉴于此，本发明的目的在于提供一种系统交互方法、装置、设备及介质，能够自动通过将需求管理系统、用例管理系统、缺陷管理系统进行连接，进而能够利用三个系统的交互实现项目进度的自动化准确更新，且可以为不具备测试用例的bug自动添加用例，提升测试效率。其具体方案如下：

第一方面，本申请公开了一种系统交互方法，包括：

按照预设监测方法监测预设需求管理系统中全部项目的执行状态，并将所述执行状态满足预设第一条件的项目确定为第一目标项目，然后向所述预设需求管理系统发送阶段更新指令；

当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果；

若所述用例执行结果为执行失败，则通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态；

基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致；

若所述第二目标项目的当前需求阶段与所述实际需求阶段不一致，则将所述预设需求管理系统中所述当前需求阶段更新为所述实际需求阶段。

可选的，所述按照预设监测方法监测预设需求管理系统中全部项目的执行状态，包括：

在所述预设需求管理系统中的控制层创建用于监测项目执行状态的管理服务，并通过所述管理服务按照预设监测方法监测预设需求管理系统中全部项目的执行状态。

可选的，所述按照预设监测方法监测预设需求管理系统中全部项目的执行状态，包括：

确定当前时间，并确定预设需求管理系统中各项目对应的计划完成时间；

将所述计划完成时间大于当前时间，且满足预设第一时差条件对应的项目确定为第一项目，并按照第一监测频率监测所述第一项目的执行状态；

将所述计划完成时间大于当前时间，且满足预设第二时差条件对应的项目确定为第二项目，并按照第二监测频率监测所述第二项目的执行状态；

将所述计划完成时间小于当前时间的项目确定为第三项目，并按照第三监测频率监测所述第三项目的执行状态。

可选的，所述当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果，包括：

当所述预设需求管理系统中的控制层接收到所述阶段更新指令，则调用所述预设需求管理系统中的模型层从与所述预设需求管理系统连接的数据库内确定所述第一目标项目对应的需求和当前需求执行阶段，并将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目；

调用所述模型层向预设测试用例管理系统发送用于查询所述第二目标项目的用例执行结果的查询请求，以获取所述第二目标项目的用例执行结果。

可选的，所述将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，包括：

将所述第一目标项目中当前需求执行阶段为测试中或已提测状态的项目确定为第二目标项目。

可选的，所述将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目之后，还包括：

基于所述第二项目对应的需求和当前需求执行阶段生成第一字符串；

相应的，所述基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致，包括：

基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段生成第二字符串，并判断所述第一字符串与所述第二字符串是否一致。

可选的，所述将所述执行状态满足预设第一条件的项目确定为第一目标项目之后，还包括：

通过预设缺陷管理系统提供的接口获取所述第一目标项目的项目bug列表，并将所述项目bug列表中无测试用例的bug确定为待补充用例项；

基于所述项目bug列表待补充用例项对应的bug信息，并利用预设测试用例管理系统中预设的用例模板为所述待补充用例项创建用例。

第二方面，本申请公开了一种系统交互装置，包括：

状态监测模块，用于按照预设监测方法监测预设需求管理系统中全部项目的执行状态，并将所述执行状态满足预设第一条件的项目确定为第一目标项目，然后向所述预设需求管理系统发送阶段更新指令；

需求查询模块，用于当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果；

Bug状态确定模块，用于若所述用例执行结果为执行失败，则通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态；

实际需求确定模块，用于基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致；

需求更新模块，用于若所述第二目标项目的当前需求阶段与所述实际需求阶段不一致，则将所述预设需求管理系统中所述当前需求阶段更新为所述实际需求阶段。

第三方面，本申请公开了一种电子设备，包括：

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

处理器，用于执行所述计算机程序，以实现前述的系统交互方法。

第四方面，本申请公开了一种计算机存储介质，用于保存计算机程序；其中，所述计算机程序被处理器执行时实现前述公开的系统交互方法的步骤。

本申请先按照预设监测方法监测预设需求管理系统中全部项目的执行状态，并将所述执行状态满足预设第一条件的项目确定为第一目标项目，然后向所述预设需求管理系统发送阶段更新指令；当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果；若所述用例执行结果为执行失败，则通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态；基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致；若所述第二目标项目的当前需求阶段与所述实际需求阶段不一致，则将所述预设需求管理系统中所述当前需求阶段更新为所述实际需求阶段。这样一来，本申请可以通过利用预设需求管理系统外的预设测试管理系统的用例执行情况来更新预设需求管理系统需求研发阶段，实现了预设需求管理系统、预设测试用例管理系统以及缺陷管理系统的互通，保证了预设需求管理系统内需求研发阶段与实际研发阶段的一致性。应用本发明后，在分平台管理需求、用例、bug时，可以大大降低测试成本，无需通过人工干预逐条对需求研发阶段进行更新，减少不必要的工作时间，提升效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请提供的一种系统交互方法流程图；

图2为本申请提供的一种策略示意图；

图3为本申请提供的一种具体的系统交互方法流程图；

图4为本申请提供的一种流程示意图；

图5为本申请提供的一种系统交互装置结构示意图；

图6为本申请提供的一种电子设备结构图。

具体实施方式

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

现有技术中，需求、用例、bug需要分别在多平台管理(例如禅道、metersphere、jira)时，当更新禅道内需求所属阶段时，需要人为根据用例管理系统上的多条用例执行情况计算出需求所属阶段，再去禅道内找到对应需求，逐条更改需求的研发阶段，可能存在更新错误等不确定情况，造成了时间和人力的巨大浪费。在本申请中，能够自动通过将需求管理系统、用例管理系统、缺陷管理系统进行连接，进而能够利用三个系统的交互实现项目进度的自动化准确更新，且可以为不具备测试用例的bug自动添加用例，提升测试效率。

本发明实施例公开了一种系统交互方法，参见图1所述，该方法包括：

步骤S11：按照预设监测方法监测预设需求管理系统中全部项目的执行状态，并将所述执行状态满足预设第一条件的项目确定为第一目标项目，然后向所述预设需求管理系统发送阶段更新指令。

可以理解的是，本实施例中所述预设需求管理系统中保存有全部项目的执行状态，且本实施例会利用预设监测方法对所述全部项目的执行状态进行监测。

需要指出的是，在本发明中一些较优的实施方式中，所述预设需求管理系统可以是禅道。在具体的实施过程中，会对禅道中全部项目的执行状态进行监测，当某一项目的执行状态由进行中变为已关闭时，则会将此项目确定为第一目标项目，然后触发发送阶段更新指令的步骤。

需要指出的是，本实施例中若项目管理员想在项目结束前获取需求研发阶段情况，则所述向所述预设需求管理系统发送阶段更新指令的过程也可以通过人工手动触发。

本实施例中，还可以在预设需求管理系统前端添加按钮界面入口，用户点击后则会获取当前项目中的所有需求及当前各个需求的当前需求研发阶段，在点击后还可以向所述预设测试用例管理系统发起最新用例执行情况获取请求。

步骤S12：当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果。

可以理解的是，本实施例中所述第二目标项目为需要进行阶段更新的项目。本实施例中，所述将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，可以包括：将所述第一目标项目中当前需求执行阶段为测试中(testing)或已提测(showcase)状态的项目确定为第二目标项目。且本实施例中用例执行结果分为pass、block、fail以及未执行。

可以理解的是，本实施例中所述预设需求管理系统在接收到所述阶段更新指令后，会触发相应的参数更新动作，其具体过程为：确定预设需求管理系统中目标项目对应的需求和当前记录的当前需求执行阶段。然后会获取预设测试用例管理系统中预先执行用例之后得到的用例执行结果。具体地，本实施例中，在确定目标项目对应的需求和当前需求执行阶段时，可以从与所述需求管理系统链接的数据库内查询。

在一些具体实施方式中，所述用例执行结果可以以json串形式表示，且一个需求可以对应有多个用例，则当一个需求可以对应有两个用例时，用例执行结果具体格式可以是：{需求1：用例1执行结果，用例2执行结果}。

步骤S13：若所述用例执行结果为执行失败，则通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态。

本实施例中，一个需求可以对应有一个或多个用例，当一个需求对应一个用例时，若此用例的用例执行结果为执行失败，则通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态；当一个需求对应多个用例时，若此需求对应的任一用例的用例执行结果为执行失败，则会通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态。

本实施例中，所述预设缺陷管理系统中保存有所述第二目标项目对应的bug信息，且所述bug信息保存有bug状态。在一些具体实施方式中，所述bug状态包括bug已关闭状态与未关闭状态。

步骤S14：基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致。

因一条需求可能对应多条用例，故需要根据该需求下所有用例执行情况来共同确定该需求所处阶段，所以本步骤中会基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段。具体地，可以根据图2中的方法确定所述项目的实际需求执行阶段，也即，若第二目标项目对应的所有用例的用例执行结果均为未执行，则将所述第二目标项目的实际需求执行阶段确定为已提测showcase；若第二目标项目对应的所有用例的用例执行结果均为pass，则将所述第二目标项目的实际需求执行阶段确定为测试完毕tested；若第二目标项目对应的所有用例的用例执行结果均为block，则将所述第二目标项目的实际需求执行阶段确定为测试中testing；若第二目标项目对应的所有用例的用例执行结果存在fail，则确定所述第二目标项目的bug状态，若所述第二目标项目的bug状态全部为已关闭状态，则将实际需求执行阶段确定为测试完毕tested，若所述第二目标项目的bug状态存在未关闭状态，则将实际需求执行阶段确定为测试中testing。

本实施例中，所述将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目之后，还可以包括：基于所述第二项目对应的需求和当前需求执行阶段生成第一字符串；相应的，所述基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致，包括：基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段生成第二字符串，并判断所述第一字符串与所述第二字符串是否一致。

本实施例中，所述第一字符串与第二字符串均可以json串形式表示，具体地，所述第一字符串的格式可以是：{需求1:当前需求研发阶段}，其中当前需求研发阶段为testing或showcase。所述第二字符串的格式可以是：{需求1:实际需求研发阶段}，其中实际需求研发阶段为testing、showcase或tested。

步骤S15：若所述第二目标项目的当前需求阶段与所述实际需求阶段不一致，则将所述预设需求管理系统中所述当前需求阶段更新为所述实际需求阶段。

本实施例中，当所述第二目标项目的当前需求阶段与所述实际需求阶段一致时，则表示所述预设需求管理系统中记录的当前需求阶段为正确状态，此时无需进行更新；当所述第二目标项目的当前需求阶段与所述实际需求阶段不一致时，则表示所述预设需求管理系统中记录的当前需求阶段为错误状态，则此时会将所述当前需求阶段更新为所述实际需求阶段，以保证任务进度中记录的信息符合实际情况。

在具体实施方式中，当第二目标项目的当前需求阶段与所述实际需求阶段不一致时，将相应的项目确定为待更新项目，然后确定所述待更新项目的项目ID，接着基于所述待更新项目的项目ID从所述实际需求研发阶段中获取所述待更新项目对应的实际研发阶段，最后将待更新项目的当前需求阶段更新为所述实际需求阶段。

在现有的测试过程中，有时会存在bug没有对应用例的情况，这种情况一般需要测试人员记录对应bug，待测试完成或复盘时编写对应的测试用例并上传到用例管理系统，可能会存在漏掉或遗忘的情况。

本实施例中，所述将所述执行状态满足预设第一条件的项目确定为第一目标项目之后，还可以包括：通过预设缺陷管理系统提供的接口获取所述第一目标项目的项目bug列表，并将所述项目bug列表中无测试用例的bug确定为待补充用例项；基于所述项目bug列表待补充用例项对应的bug信息，并利用预设测试用例管理系统中预设的用例模板为所述待补充用例项创建用例，并将创建的用例导入所述预设用例管理系统。

需要指出的是，本实施例中还可以利用预设测试用例管理系统中预设的用例模板根据缺陷管理系统内bug列表对没有用例的bug进行用例补充，实现了预设需求管理系统与预设测试用例管理系统的互通。无需通过人工干预便可自动识别缺少用例的bug，利用预设模板即可快速准确地创建合适的用例，减少不必要的工作时间，提升测试效率。

本实施例中，所述系统交互方法，还可以包括：在所述缺陷管理系统中添加第一自定义字段require与第二自定义字段case，其中第一自定义字段用于bug与需求间的关联；第二自定义字段case用于bug与用例间的关联。在一些较优的实施方式中，所述缺陷管理系统可以是jira，则此步骤具体可以是：在jira中添加第一自定义字段require与第二自定义字段case。则本实施例中添加用例的过程具体可以是：获取第二目标项目在预设缺陷管理系统内的bug列表，过滤出require！～empty AND case～empty的bug，根据bug内容生成测试用例，然后调用预设测试用例管理系统添加用例API(即Application ProgrammingInterface，应用程序编程接口)动态添加用例。

本实施例中，先按照预设监测方法监测预设需求管理系统中全部项目的执行状态，并将所述执行状态满足预设第一条件的项目确定为第一目标项目，然后向所述预设需求管理系统发送阶段更新指令；当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果；若所述用例执行结果为执行失败，则通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态；基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致；若所述第二目标项目的当前需求阶段与所述实际需求阶段不一致，则将所述预设需求管理系统中所述当前需求阶段更新为所述实际需求阶段。这样一来，本实施例可以预设需求管理系统外的测试管理系统的用例执行情况来更新预设需求管理系统需求研发阶段，并根据缺陷管理系统内bug列表对没有用例的bug进行用例补充，实现了需求管理系统与测试用例管理系统的互通，保证了需求管理系统内需求研发阶段与实际研发阶段的一致性。应用本发明后，在分平台管理需求、用例、bug时，可以大大降低测试成本，无需通过人工干预逐条对需求研发阶段进行更新，并对缺少的用例进行补充，减少不必要的工作时间，提升效率。

图3为本申请实施例提供的一种具体的系统交互方法流程图。参见图3所示，该方法包括：

步骤S21：在所述预设需求管理系统中的控制层创建用于监测项目执行状态的管理服务，并通过所述管理服务按照预设监测方法监测预设需求管理系统中全部项目的执行状态，并将所述执行状态满足预设第一条件的项目确定为第一目标项目，然后向所述预设需求管理系统发送阶段更新指令。

在实际操作过程中，开发及测试的实际完成时间与计划时间可能有偏差，所以不能将计划完成时间作为唯一指标。所以本实施例中，可以在预设需求管理系统中的控制层中创建一个用于监测项目执行状态的管理服务。在一些较优的实施方式中，当所述预设需求管理系统为禅道时，可以在禅道的Controller层引入一个常驻monitor-compare服务，该服务动态获取进行中项目内项目的状态，并将项目状态记为project_status。

本实施例中，所述monitor-compare服务会按照预设监测方法监测预设需求管理系统中全部项目的执行状态。所述按照预设监测方法监测预设需求管理系统中全部项目的执行状态，可以包括：确定当前时间，并确定预设需求管理系统中各项目对应的计划完成时间；将所述计划完成时间大于当前时间，且满足预设第一时差条件对应的项目确定为第一项目，并按照第一监测频率监测所述第一项目的执行状态；将所述计划完成时间大于当前时间，且满足预设第二时差条件对应的项目确定为第二项目，并按照第二监测频率监测所述第二项目的执行状态；将所述计划完成时间小于当前时间的项目确定为第三项目，并按照第三监测频率监测所述第三项目的执行状态。

在一些具体的实施方式中，当有项目为“进行中”时，所述monitor-compare服务首先获取进行中项目的计划完成日期t1，并确定当前日期t2，当t1-t2大于第一预设数值时，每天(即24小时)获取一次project_status；当t1-t2小于等于第一预设数值且大于等于第二预设数值时，每隔12小时获取一次project_status；当t1-t2小于等于第二预设数值，每隔4小时获取一次project_status；若t1-t2小于零时(项目已过预计完成时间但项目仍未结束)，每隔2小时获取一次project_status。需要指出的是，所述第一预设数值、所述第二预设数值以及所述参数获取频率均可根据实际应用场景进行随意设置与更改。在一些较优的实施方式中，所述第一预设数值可以设置为3，所述第二预设数值可以设置为1。

当monitor-compare服务获取到的project_status为“已关闭”时，会停止该项目的monitor-compare进程，并将相应的项目确定为第一目标项目，然后向所述预设需求管理系统中的控制层发送阶段更新指令，以触发更新项目需求的动作。

步骤S22：当所述预设需求管理系统中的控制层接收到所述阶段更新指令，则调用所述预设需求管理系统中的模型层从与所述预设需求管理系统连接的数据库内确定所述第一目标项目对应的需求和当前需求执行阶段，并将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目。

本实施例中，若所述预设需求管理系统为禅道，则在Controller层接收到所述阶段更新指令时，Controller层会调用Model层查询数据库内第一目标项目对应的需求及当前需求研发阶段，并将当前需求研发阶段为已提测(showcase)和测试中(testing)的项目确定为第二目标项目，然后生成json串格式的第一字符串。在具体的实施方式中，monitor-compare服务会在确定第一目标项目后，将所述第一目标项目的项目ID写入阶段更新指令中，所述Model层便可根据阶段更新指令中的项目ID查询数据库内第一目标项目对应的需求及当前需求研发阶段。

步骤S23：调用所述模型层向预设测试用例管理系统发送用于查询所述第二目标项目的用例执行结果的查询请求，以获取所述第二目标项目的用例执行结果。

在具体实施方式中，禅道内的Model层可以向预设测试用例管理系统发出用例执行结果查询请求，以获取以json串格式生成的用例结果字符串。

步骤S24：若所述用例执行结果为执行失败，则通过预设缺陷管理系统确定所述目标项目对应的bug信息中的bug状态。

在一些具体实施方式中，若缺陷管理系统为jira，且存在一用例结果为fail，则可以通过jira中预设的API获取对应的bug信息(携带参数：require～file的需求)，得到对应bug状态。

步骤S25：基于所述bug状态与所述用例执行结果确定所述目标项目的实际需求执行阶段，并判断所述当前需求阶段与所述实际需求阶段是否一致。

其中，关于步骤S25的更加具体的处理过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

步骤S26：若所述当前需求阶段与所述实际需求阶段不一致，则将所述预设需求管理系统中所述当前需求阶段更新为所述实际需求阶段。

其中，关于步骤S26的更加具体的处理过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

本实施例中，可以根据预设缺陷管理系统内bug列表对没有用例的bug进行用例补充，在具体实施方式中可以通过禅道外用例管理系统中的用例执行情况，动态更新禅道对应需求的需求研发阶段，且当bug没有测试用例相对应时，生成测试用例并导入用例管理系统。在一定程度上实现了禅道、缺陷管理系统与用例管理系统的互通，且保证禅道内需求研发阶段与最新执行情况一致。应用本发明后，可以在分平台管理需求、用例、bug时，可以大大降低测试成本，减少不必要的工作时间，提升效率。

如图4所示为本申请提供的一种具体流程示意图，图中以禅道作为预设需求管理系统，并以jira作为预设缺陷管理系统进行展开，当禅道中项目为进行中状态时，利用禅道中预设的monitor-compare服务获取各项目的执行状态。其中监测项目状态时具体可以根据项目预计完成时间动态调整监控区间，当距离项目预计完成时间越近时，获取状态的频率越频繁。当监测到项目的执行状态变为已关闭时，将会触发更新需求阶段的流程(其中触发更新需求阶段的流程也可以通过手动触发)，然后会确定该项目每条需求的当前需求研发阶段，将当前需求研发阶段为showcase和testing状态的项目的作为第二目标项目，并调用用例管理系统的API确定第二目标项目的用例执行情况列表。其中，会将其余项目的json串从第一字符串列表中剔除，也即保留下的第一字符串均为所述第二目标项目对应的字符串。然后会判断用例执行情况列表中是否存在某用例的执行结果为fail，若存在，则调用jira的API确定项目对应的bug状态是否为关闭，然后将bug状态也写入所述用例执行情况列表，当禅道内部的接收模块接收到用例执行情况列表对应的用例执行数据后，会根据图2中的策略确定第二字符串，接着会判断第一字符串与第二字符串是否一致，若一致则表明该需求的研发阶段不需要更新，若不一致，则应将当前需求研发阶段更新为所述实际需求研发阶段。另外，在监测到项目转改变为已关闭时，还会触发补充用例流程，具体是通过jira的API获取项目bug列表，确定出用例存在需求但无对应用例的bug，然后根据bug内容生成用例并导入预设测试用例管理系统。

参见图5所示，本申请实施例公开了一种系统交互装置，具体可以包括：

状态监测模块11，用于按照预设监测方法监测预设需求管理系统中全部项目的执行状态，并将所述执行状态满足预设第一条件的项目确定为第一目标项目，然后向所述预设需求管理系统发送阶段更新指令；

需求查询模块12，用于当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果；

Bug状态确定模块13，用于若所述用例执行结果为执行失败，则通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态；

实际需求确定模块14，用于基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致；

需求更新模块15，用于若所述第二目标项目的当前需求阶段与所述实际需求阶段不一致，则将所述预设需求管理系统中所述当前需求阶段更新为所述实际需求阶段。

本申请先按照预设监测方法监测预设需求管理系统中全部项目的执行状态，并将所述执行状态满足预设第一条件的项目确定为第一目标项目，然后向所述预设需求管理系统发送阶段更新指令；当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果；若所述用例执行结果为执行失败，则通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态；基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致；若所述第二目标项目的当前需求阶段与所述实际需求阶段不一致，则将所述预设需求管理系统中所述当前需求阶段更新为所述实际需求阶段。这样一来，本申请可以通过利用预设需求管理系统外的预设测试管理系统的用例执行情况来更新预设需求管理系统需求研发阶段，实现了预设需求管理系统、预设测试用例管理系统以及缺陷管理系统的互通，保证了预设需求管理系统内需求研发阶段与实际研发阶段的一致性。应用本发明后，在分平台管理需求、用例、bug时，可以大大降低测试成本，无需通过人工干预逐条对需求研发阶段进行更新，减少不必要的工作时间，提升效率。

在一些具体实施例中，所述状态监测模块11中，具体包括：

服务创建单元，用于在所述预设需求管理系统中的控制层创建用于监测项目执行状态的管理服务，并通过所述管理服务按照预设监测方法监测预设需求管理系统中全部项目的执行状态。

在一些具体实施例中，所述状态监测模块11中，具体包括：

时间确定单元，用于确定当前时间，并确定预设需求管理系统中各项目对应的计划完成时间；

第一执行状态检测单元，用于将所述计划完成时间大于当前时间，且满足预设第一时差条件对应的项目确定为第一项目，并按照第一监测频率监测所述第一项目的执行状态；

第二执行状态检测单元，用于将所述计划完成时间大于当前时间，且满足预设第二时差条件对应的项目确定为第二项目，并按照第二监测频率监测所述第二项目的执行状态；

第三执行状态检测单元，用于将所述计划完成时间小于当前时间的项目确定为第三项目，并按照第三监测频率监测所述第三项目的执行状态。

在一些具体实施例中，所述需求查询模块12，包括：

第二目标项目确定单元，用于当所述预设需求管理系统中的控制层接收到所述阶段更新指令，则调用所述预设需求管理系统中的模型层从与所述预设需求管理系统连接的数据库内确定所述第一目标项目对应的需求和当前需求执行阶段，并将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目；

执行结果查询单元，用于调用所述模型层向预设测试用例管理系统发送用于查询所述第二目标项目的用例执行结果的查询请求，以获取所述第二目标项目的用例执行结果。

在一些具体实施例中，所述需求查询模块12中，包括：

项目确定单元，用于将所述第一目标项目中当前需求执行阶段为测试中或已提测状态的项目确定为第二目标项目。

在一些具体实施例中，所述系统交互装置，还包括：

第一字符串生成单元，用于基于所述第二项目对应的需求和当前需求执行阶段生成第一字符串；

相应的，实际需求确定模块14中，包括：

第二字符串生成单元，用于基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段生成第二字符串，并判断所述第一字符串与所述第二字符串是否一致。

在一些具体实施例中，所述系统交互装置，还包括：

待补充用例项确定单元，用于通过预设缺陷管理系统提供的接口获取所述第一目标项目的项目bug列表，并将所述项目bug列表中无测试用例的bug确定为待补充用例项；

创建用例单元，用于基于所述项目bug列表待补充用例项对应的bug信息，并利用预设测试用例管理系统中预设的用例模板为所述待补充用例项创建用例。

进一步的，本申请实施例还公开了一种电子设备，图6是根据示例性实施例示出的电子设备20结构图，图中的内容不能认为是对本申请的使用范围的任何限制。

图6为本申请实施例提供的一种电子设备20的结构示意图。该电子设备20，具体可以包括：至少一个处理器21、至少一个存储器22、电源23、显示屏24、输入输出接口25、通信接口26和通信总线27。其中，所述存储器22用于存储计算机程序，所述计算机程序由所述处理器21加载并执行，以实现前述任一实施例公开的系统交互方法中的相关步骤。另外，本实施例中的电子设备20具体可以为电子计算机。

本实施例中，电源23用于为电子设备20上的各硬件设备提供工作电压；通信接口26能够为电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

另外，存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源可以包括操作系统221、计算机程序222及虚拟机数据223等，虚拟机数据223可以包括各种各样的数据。存储方式可以是短暂存储或者永久存储。

其中，操作系统221用于管理与控制电子设备20上的各硬件设备以及计算机程序222，其可以是Windows Server、Netware、Unix、Linux等。计算机程序222除了包括能够用于完成前述任一实施例公开的由电子设备20执行的系统交互方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。

进一步的，本申请还公开了一种计算机可读存储介质，这里所说的计算机可读存储介质包括随机存取存储器(Random Access Memory，RAM)、内存、只读存储器(Read-OnlyMemory，ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、磁碟或者光盘或技术领域内所公知的任意其他形式的存储介质。其中，所述计算机程序被处理器执行时实现前述公开的系统交互方法。关于该方法的具体步骤可以参考前述实施例中公开的相应内容，在此不再进行赘述。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本发明所提供的系统交互方法、装置、设备、存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种系统交互方法，其特征在于，包括：

按照预设监测方法监测预设需求管理系统中全部项目的执行状态，并将所述执行状态满足预设第一条件的项目确定为第一目标项目，然后向所述预设需求管理系统发送阶段更新指令；

当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果；

若所述用例执行结果为执行失败，则通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态；

基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致；

若所述第二目标项目的当前需求阶段与所述实际需求阶段不一致，则将所述预设需求管理系统中所述当前需求阶段更新为所述实际需求阶段。

2.根据权利要求1所述的系统交互方法，其特征在于，所述按照预设监测方法监测预设需求管理系统中全部项目的执行状态，包括：

在所述预设需求管理系统中的控制层创建用于监测项目执行状态的管理服务，并通过所述管理服务按照预设监测方法监测预设需求管理系统中全部项目的执行状态。

3.根据权利要求2所述的系统交互方法，其特征在于，所述按照预设监测方法监测预设需求管理系统中全部项目的执行状态，包括：

确定当前时间，并确定预设需求管理系统中各项目对应的计划完成时间；

将所述计划完成时间大于当前时间，且满足预设第一时差条件对应的项目确定为第一项目，并按照第一监测频率监测所述第一项目的执行状态；

将所述计划完成时间大于当前时间，且满足预设第二时差条件对应的项目确定为第二项目，并按照第二监测频率监测所述第二项目的执行状态；

将所述计划完成时间小于当前时间的项目确定为第三项目，并按照第三监测频率监测所述第三项目的执行状态。

4.根据权利要求1所述的系统交互方法，其特征在于，所述当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果，包括：

当所述预设需求管理系统中的控制层接收到所述阶段更新指令，则调用所述预设需求管理系统中的模型层从与所述预设需求管理系统连接的数据库内确定所述第一目标项目对应的需求和当前需求执行阶段，并将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目；

调用所述模型层向预设测试用例管理系统发送用于查询所述第二目标项目的用例执行结果的查询请求，以获取所述第二目标项目的用例执行结果。

5.根据权利要求4所述的系统交互方法，其特征在于，所述将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，包括：

将所述第一目标项目中当前需求执行阶段为测试中或已提测状态的项目确定为第二目标项目。

6.根据权利要求5所述的系统交互方法，其特征在于，所述将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目之后，还包括：

基于所述第二项目对应的需求和当前需求执行阶段生成第一字符串；

相应的，所述基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致，包括：

基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段生成第二字符串，并判断所述第一字符串与所述第二字符串是否一致。

7.根据权利要求1至6任一项所述的系统交互方法，其特征在于，所述将所述执行状态满足预设第一条件的项目确定为第一目标项目之后，还包括：

通过预设缺陷管理系统提供的接口获取所述第一目标项目的项目bug列表，并将所述项目bug列表中无测试用例的bug确定为待补充用例项；

基于所述项目bug列表待补充用例项对应的bug信息，并利用预设测试用例管理系统中预设的用例模板为所述待补充用例项创建用例。

8.一种系统交互装置，其特征在于，包括：

状态监测模块，用于按照预设监测方法监测预设需求管理系统中全部项目的执行状态，并将所述执行状态满足预设第一条件的项目确定为第一目标项目，然后向所述预设需求管理系统发送阶段更新指令；

需求查询模块，用于当所述预设需求管理系统接收到所述阶段更新指令，则将所述第一目标项目中当前需求执行阶段为预设阶段的项目确定为第二目标项目，并从预设测试用例管理系统查询所述第二目标项目的用例执行结果；

Bug状态确定模块，用于若所述用例执行结果为执行失败，则通过预设缺陷管理系统确定所述第二目标项目对应的bug信息中的bug状态；

实际需求确定模块，用于基于所述bug状态与所述用例执行结果确定所述第二目标项目的实际需求执行阶段，并判断所述第二目标项目的当前需求阶段与所述实际需求阶段是否一致；

需求更新模块，用于若所述第二目标项目的当前需求阶段与所述实际需求阶段不一致，则将所述预设需求管理系统中所述当前需求阶段更新为所述实际需求阶段。

9.一种电子设备，其特征在于，包括处理器和存储器；其中，所述处理器执行所述存储器中保存的计算机程序时实现如权利要求1至7任一项所述的系统交互方法。

10.一种计算机可读存储介质，其特征在于，用于存储计算机程序；其中，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的系统交互方法。

Images