CN115600819A - 风险评估方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明公开了一种风险评估方法、装置、电子设备及存储介质。该方法包括：在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项；其中，所述评估维度包括功能需求、软件设计、软件版本、功能变更和用户中至少一个；确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果；基于各评估项所对应的评估结果，确定与所述待评估应用相对应的风险应对方式。解决了现有技术中将所有测试风险进行应对处理，导致成本高，实现效果差的问题，实现提高风险评估的准确性，减少成本消耗，进而达到提高测试效果的效果。

Description

风险评估方法、装置、电子设备及存储介质

技术领域

本发明涉及计算机处理技术领域，尤其涉及一种风险评估方法、装置、电子设备及存储介质。

背景技术

目前在软件测试的过程中，通过往往存在一些可估量或者不可估量的风险，这些风险可能会影响软件的测试效果，因此需要分析并识别出这些风险，并且找出应对风险的措施，以实现尽最大程度的降低这些风险。

现有技术中，分析风险的方式通常是需要将测试过程中所有可能发生的风险在项目开发过程中的每一个阶段进行规避，但是在实际应用中，有的风险是难以避免的，如缺陷风险：某些缺陷是偶发的，测试时难以重现，很难规避此风险；有的风险又是从理论上可以避免的，但在操作过程中可能由于时间或成本等因素，难以完全避免该风险的出现。这种将所有可能发生的风险进行规避的方式不仅实现效果差，还存在成本高的问题。

发明内容

本发明提供了一种风险评估方法、装置、电子设备及存储介质，以实现提高风险评估的准确性，减少成本消耗，进而达到提高测试效果的技术效果。

根据本发明的一方面，提供了一种风险评估方法，该方法包括：

在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项；其中，所述评估维度包括功能需求、软件设计、软件版本、功能变更和用户中至少一个；

确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果；

基于各评估项所对应的评估结果，确定与所述待评估应用相对应的风险应对方式。

根据本发明的另一方面，提供了一种风险评估装置，该装置包括：

评估项确定模块，用于在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项；其中，所述评估维度包括功能需求、软件设计、软件版本、功能变更和开发用户中至少一个；

评估结果确定模块，用于确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果；

风险应对方式确定模块，用于基于各评估项所对应的评估结果，确定与所述待评估应用相对应的风险应对方式。

根据本发明的另一方面，提供了一种电子设备，所述电子设备包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行本发明任一实施例所述的风险评估方法。

根据本发明的另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使处理器执行时实现本发明任一实施例所述的风险评估方法。

本发明实施例的技术方案，通过在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项；其中，评估维度包括功能需求、软件设计、软件版本、功能变更和用户中至少一个；确定与评估项相对应的评估配置条件，并基于评估配置条件对待评估应用进行测试分析，得到评估结果；基于各评估项所对应的评估结果，确定与待评估应用相对应的风险应对方式，解决了现有技术中将所有测试风险进行应对处理，导致成本高，实现效果差的问题，实现了通过对测试风险进行不同维度的划分，得到不同的风险评估维度，进而基于不同风险评估维度所对应的至少两个评估项的评估配置条件对待评估应用进行测试分析，得到评估结果，提高风险评估的准确性，在评估结果为存在风险时，准确定位到应对风险所需的风险应对方式，在减少成本消耗，提高风险定位准确性的同时，达到提高测试效果的技术效果。

应当理解，本部分所描述的内容并非旨在标识本发明的实施例的关键或重要特征，也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。

附图说明

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

图1是根据本发明实施例一提供的一种风险评估方法的流程图；

图2是根据本发明实施例二提供的功能需求维度的风险评估方法示意图；

图3是根据本发明实施例二提供的软件设计维度的风险评估方法示意图；

图4是根据本发明实施例二提供的软件版本维度的风险评估方法示意图；

图5是根据本发明实施例二提供的功能变更维度的风险评估方法示意图；

图6是根据本发明实施例二提供的用户维度的风险评估方法示意图；

图7是根据本发明实施例三提供的一种风险评估装置的结构示意图；

图8是实现本发明实施例的风险评估方法的电子设备的结构示意图。

具体实施方式

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

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

实施例一

图1是根据本发明实施例一提供的一种风险评估方法的流程图，本实施例可适用于风险评估的情况，该方法可以由风险评估装置来执行，该风险评估装置可以采用硬件和/或软件的形式实现，该风险评估装置可配置于计算设备中。如图1所示，该方法包括：

S110、在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项。

其中，待评估应用可以理解为需要评估其测试风险的软件或产品。风险评估请求可以是请求进行测试风险评估的指令或代码，用于请求进行测试风险的评估。

需要说明的是，在实际应用中，软件测试面临的风险可能存在多种，如，对软件需求理解不准确，导致测试范围存在误差风险；或者测试用例设计不完整，导致存在测试遗漏风险；或者测试环境与生产环境不能完全一致，导致测试结果存在误差风险等。可以通过对软件测试面临的风险进行划分，得到多个风险类别，如软件需求类别，测试设计类别，测试环境类别等等，以使可以分别针对于各风险类别进行风险评估，最终确定存在哪种测试风险。相应的，可以基于各风险类别确定对应的评估维度，评估维度可以用于表征软件测试面临的风险的属性信息。可选的，评估维度中可以包括但不限于功能需求、软件设计、软件版本、功能变更和开发用户中至少一个。每个评估维度下可以对应相应的评估项。评估项可以用于表征软件测试面临的风险的评估信息。评估项的数量可以为一个，也可以为多个。例如，功能需求评估维度下的评估项可以包括需求变更评估项、需求遗漏评估项、需求理解情况的评估项等。软件设计下的评估项可以包括产品更新评估项、产品设计性能评估项等等。

在本实施例中，可以当用户点击了系统页面的风险评估控件时，认为系统接收到了风险评估请求，风险评估请求中可以携带有待评估应用的信息。进一步的，可以从预设缓存中调取出预先配置的各评估维度所对应的评估项，以基于各评估项检测待评估应用于测试环境中的话，可能出现哪些测试风险。

S120、确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果。

其中，评估配置条件是指用于执行评估的配置信息，如对于需求变更评估项，其对应的评估配置条件可以为检测是否存在需求变更；需求遗漏评估项，其对应的评估配置条件可以为检测是否存在需求遗漏。评估结果可以用于表征是否存在测试风险的结果，如存在测试风险，或不存在测试风险等。

在本实施例中，可以基于各评估项所对应的评估配置条件对待评估应用进行测试分析，并测试待评估应用是否存在该评估配置条件所对应的风险，若是，可以输出存在测试风险的评估结果，若否，则可以输出不存在测试风险的评估结果。示例性的，在基于检测是否存在需求变更的评估配置条件对待评估应用测试分析时，若判断存在需求变更，那么可以说明可能存在需求变更的风险，评估结果可以为有需求变更风险。

需要说明的是，每个评估维度所对应的评估项可能是不同的，相对应的评估配置条件也是不同的，不同的评估配置条件所对应的处理方式是不同的，为了清楚的介绍本技术方案，可以对不同评估维度下评估项所对应的评估配置条件进行测试分析的实现方式进行分别介绍，具体的，可参见下述内容：

可选的，若评估维度为功能需求，确定与评估项相对应的评估配置条件，并基于评估配置条件对待评估应用进行测试分析，得到评估结果，包括：获取与功能需求维度相对应的待评估应用的需求测试数据；基于需求测试数据确定需求属性信息；根据与评估项相对应的评估配置条件和需求属性信息对待评估应用测试分析，得到与评估项相对应的评估结果。

其中，若评估维度为功能需求，则与功能需求维度相对应的评估项可以为需求内容的完整度和清晰度、开发人员对需求内容的理解度、测试人员对需求内容的理解度。每个评估项分别对应的评估配置条件可以为：评估需求内容不完整、清晰、评估开发人员对需求理解不充分、评估测试人员对需求理解不充分。需求属性信息中包括需求完整度、需求清晰度和/或需求理解度。需求完整度可以用于表征需求内容的完整程度，如，需求内容中若遗漏了部分需求，则认为需求完整度较低。需求清晰度可以用于表征需求内容的清晰程度，例如，若需求内容表述的差，则清晰程度较低，清晰程度低的话可能会导致用户对需求内容理解不清楚。需求理解度可以用于表征用户对需求内容的理解程度，如对软件需求理解不准确，即认为需求理解度低，此种情况可能会导致确定测试范围时存在误差风险。

在本实施例中，在确定待评估应用是否存在功能需求的测试风险时，可以基于功能需求维度下的各评估配置条件分别对待评估应用进行测试分析，测试待评估应用是否存在相应的测试风险。在测试分析的过程中，可以获取在基于评估配置条件测试分析时，所需的与待评估应用相对应的数据，如功能需求维度下所需的应用数据可以为需求属性信息。进而可以根据需求属性信息分析待评估应用是否存在功能需求风险，例如，可当需求完整度小于第一预设阈值时，认为可能存在需求不完整的测试风险；或者，在需求清晰度小于第二预设阈值时，认为可能存在需求内容不清楚的测试风险；或者在需求理解度小于第三预设阈值时，认为可能存在用户对需求内容理解不充分的测试风险，相应的，可以得到功能需求维度下各评估配置条件测试确定的评估结果，以使后续基于评估结果确定对风险的应对措施。

可选的，若评估维度为软件设计，确定与评估项相对应的评估配置条件，并基于评估配置条件对待评估应用进行测试分析，得到评估结果，包括：获取与软件设计维度相对应的待评估应用的设计测试数据；基于设计测试数据确定设计属性信息；根据与评估项相对应的评估配置条件和设计属性信息对待评估应用测试分析，得到与评估项相对应的评估结果。

其中，若评估维度为软件设计，则与软件设计维度相对应的评估项可以包括产品更新信息、架构新增特性的性能、产品设计的可解释度、开发人员的对产品设计的理解度、产品设计的全面性等。每个评估项分别对应的评估配置条件可以为：使用了新技术、新平台、新架构、新算法；现有架构不能满足新增特性的性能；产品设计复杂且难以理解；开发人员对产品设计不熟悉并不理解；对异常场景和非功能考虑不全面。设计属性信息中包括新增设计信息、设计可靠度、设计可理解度、设计清晰度和/或设计全面度。新增设计信息中包括产品的程序变更信息、架构变更信息、部署平台变更信息等等。设计可靠度是指产品在规定的时间内，在规定的条件下，完成预定功能的能力，包括产品的安全性，适用性和耐久性等各项性能。设计可理解度可以用于表征产品设计被理解的程度。设计清晰度可以用于表征产品设计的清晰程度，是否易读。设计全面度可以用于表征产品设计的全面性。

在本实施例中，可以基于软件设计维度下的各评估配置条件分别对待评估应用进行测试分析，测试待评估应用是否存在相应的软件设计风险。在测试分析的过程中，可以获取在基于评估配置条件测试分析时，所需的与待评估应用相对应的数据，如软件设计维度下所需的应用数据可以为设计属性信息。进而可以根据设计属性信息分析待评估应用是否存在设计风险，例如，可当设计属性信息中的架构不能满足新增特性的性能、可靠性低时，可以认为可能存在架构不可行的风险；或者，在设计属性信息中存在使用新技术、新平台、新架构或新算法时，可以认为可能存在设计内容变化的测试风险；或者在产品设计存在可理解度低和清晰度差时，认为可能存在设计复杂且难以理解的测试风险；或者存在开发人员对产品设计不熟悉、不理解的情况时，认为存在设计熟悉度低的风险；或者，若设计全面度低，则可以认为存在设计对异常场景和非功能考虑不全面的测试风险。相应的，可以得到软件设计维度下各评估配置条件测试确定的评估结果，以使后续基于评估结果确定对风险的应对措施。

可选的，若评估维度为软件版本，确定与评估项相对应的评估配置条件，并基于评估配置条件对待评估应用进行测试分析，得到评估结果，包括：获取与软件版本维度相对应的待评估应用的版本测试数据；基于版本测试数据确定版本属性信息；根据与评估项相对应的评估配置条件和版本属性信息对待评估应用测试分析，得到与评估项相对应的评估结果。

其中，若评估维度为软件版本，则与软件版本维度相对应的评估项可以包括软件流程更新信息、开发自测信息、版本管理信息等。可以为每个评估项配置相应的评估配置条件，如，每个评估项分别对应的评估配置条件可以为：使用了新的流程和开发方式、开发未完成自测、开发未做好代码版本管理，以基于评估配置条件检测待评估应用是否存在与对应评估项相对应的测试风险。版本属性信息中包括新增版本信息、版本测试度和/或版本管理度。例如，新增版本信息中可以包括软件版本更新信息，版本流程更新信息，开发方式更新信息等。版本测试度可以用于表征开发自测程度，版本管理度可以用于表征代码版本管理的情况。

在本实施例中，在确定待评估应用是否存在软件版本的测试风险时，可以基于软件版本维度下的各评估配置条件分别对待评估应用进行测试分析，测试待评估应用是否存在相应的测试风险。在测试分析的过程中，可以获取在评估配置条件测试分析时所需的与待评估应用相对应的数据，如开发自测信息评估项对应的评估配置条件测试所需的应用数据可以为版本测试度，通过版本测试度测试是否存在该评估项所对应的测试风险，提高数据处理效率。相应的，每个评估配置条件在测试分析的过程中，可以通过对与之对应的待评估应用相关的应用数据进行分析，得到每个评估配置条件所评估的评估结果。具体的，可以根据版本属性信息分析待评估应用是否存在软件版本风险，例如，可当待评估应用使用了新的流程和开发方式时，认为可能存在流程变更的测试风险；或者，在开发未完成自测时，认为可能存在开发性能差的测试风险；或者在开发未做好代码版本管理时，认为可能存在代码版本出错的测试风险，相应的，可以得到软件版本维度下各评估配置条件测试确定的评估结果，以使后续基于评估结果确定对风险的应对措施。

可选的，若评估维度为功能变更，确定与评估项相对应的评估配置条件，并基于评估配置条件对待评估应用进行测试分析，得到评估结果，包括：获取与功能变更维度相对应的待评估应用的变更测试数据，并基于变更测试数据确定变更属性信息；根据与评估项相对应的评估配置条件和变更属性信息对待评估应用测试分析，得到与评估项相对应的评估结果。

其中，若评估维度为功能变更，则与功能变更维度相对应的评估项可以包括需求变更项、功能变更情况等，可以为每个评估项配置相应的评估配置条件，如，每个评估项分别对应的评估配置条件可以为：项目研发过程中存在需求变更、新功能相较于旧功能的变动存在不清楚，以基于评估配置条件检测待评估应用是否存在与对应评估项相对应的测试风险。变更属性信息中包括需求变更信息和/或功能变更信息。例如，需求变更信息可以包括用户对软件应用的新需求，功能变更信息可以包括相较于软件应用前一次测试，此次的新功能项。

在本实施例中，在确定待评估应用是否存在功能变更的测试风险时，可以基于功能变更维度下的各评估配置条件分别对待评估应用进行测试分析，测试待评估应用是否存在相应的测试风险。在测试分析的过程中，可以获取在评估配置条件测试分析时所需的与待评估应用相对应的数据，如需求变更评估项对应的评估配置条件测试所需的应用数据可以为用户对软件应用提出的新需求，进而可以通过该应用数据判断是否存在新需求，以评估是否存在该评估项对应的测试风险。相应的，每个评估配置条件在测试分析的过程中，可以通过对与之对应的待评估应用相关的应用数据进行分析，得到每个评估配置条件所评估的评估结果。具体的，可以根据变更属性信息分析待评估应用是否存在功能变更风险，例如，可当待评估应用在研发过程中存在需求变更时，认为可能存在需求变更的测试风险；或者，在新功能相较于旧功能的变动存在不清楚时，认为可能存在功能变更的测试风险，相应的，可以得到功能变更维度下各评估配置条件测试确定的评估结果，以使后续基于评估结果确定对风险的应对措施。

可选的，若评估维度为用户，确定与评估项相对应的评估配置条件，并基于评估配置条件对待评估应用进行测试分析，得到评估结果，包括：获取与用户维度相对应的待评估应用的用户构成信息；基于用户构成信息确定用户属性信息；根据与评估项相对应的评估配置条件和用户属性信息对待评估应用测试分析，得到与评估项相对应的评估结果。

其中，若评估维度为用户，则与用户维度相对应的评估项可以包括，人员构成信息，人员流动信息，人员执行能力等，可以为每个评估项配置相应的评估配置条件，如，每个评估项分别对应的评估配置条件可以为：项目团队任务分配存在多方人员配合、项目团队人员不稳定、项目团队人手不足，以基于评估配置条件检测待评估应用是否存在与对应评估项相对应的测试风险。用户属性信息中包括用户隶属信息、用户构成稳定度和/或用户执行信息。用户隶属信息是指用户隶属方，如用户隶属团队、小组、部门、公司等。用户构成稳定度可以用于表征用户的流动程度，如，若存在一个或多个用户离开测试项目团队，则用户构成稳定度差。用户执行信息可以用于表征用户对项目的完成能力，如，若项目A的团队中存在人手不足的情况，则说明开发或测试项目A时可能会被拖期，认为团队执行能力差。

在本实施例中，在确定待评估应用是否存在用户的测试风险时，可以基于用户维度下的各评估配置条件分别对待评估应用进行测试分析，测试待评估应用是否存在相应的测试风险。在测试分析的过程中，可以获取在评估配置条件测试分析时所需的与待评估应用相对应的数据，如人员构成信息评估项对应的评估配置条件测试所需的应用数据可以为用户隶属信息，通过用户隶属信息判断是否存在多方人员配合完成待评估应用项目。相应的，每个评估配置条件在测试分析的过程中，可以通过对与之对应的待评估应用相关的应用数据进行分析，得到每个评估配置条件所评估的评估结果。具体的，可以根据用户构成信息分析待评估应用是否存在用户风险，例如，可当用户隶属信息中存在多个隶属方的成员时，认为项目团队任务分配存在多方人员配合，即可能存在用户的测试风险；或者，存在项目团队人员出现请假、离开时，认为可能存在人员不稳定的测试风险；或者，存在项目团队人员数量少，且不足以完成项目时，认为可能存在用户的测试风险，相应的，可以得到用户维度下各评估配置条件测试确定的评估结果，以使后续基于评估结果确定对风险的应对措施。

S130、基于各评估项所对应的评估结果，确定与所述待评估应用相对应的风险应对方式。

其中，风险应对方式可以理解为应对风险的措施。

具体的，在确定各评估项所对应的评估结果之后，若评估结果为存在风险，可以确定应对该评估结果的评估项风险的措施，作为风险应对方式。

需要说明的是，在实际测试场景中，存在有些风险可能是可以避免的，有些风险是不可避免的，不同的风险所对应的处理措施可能是不同的，例如，不可避免的风险的处理措施可能是不作处理，可以避免的风险的处理措施可能是寻求技术支持等，但可避免的风险在实际措施操作过程中，可能会出于时间和成本考虑，也难以完全回避，如：回归测试风险等，因此若是对这种风险采取措施避免风险可能影响软件测试效率。为了提高风险评估的准确性，以及提高风险应对措施确定的准确性，进而提高软件测试效率，可以对不同评估维度的风险进行结构化的风险类别细化，得到每个评估维度下不同风险类别所对应的评估项，进一步的，每个风险类别评估项下可以对应相应的应对措施，以在评估项所对应的评估结果为存在风险，可以基于相应的应对措施进行应对处理。例如，在功能需求维度下的需求内容的完整度和清晰度的评估项所对应的应对措施可以为制定需求准入标准，检查需求质量；在检测到需求内容的完整度和清晰度低时，检测该应对措施是否可以正常被执行，若是存在某些影响，导致不能正常被执行，则可以认为该评估项所对应的风险为回避风险类型；如果该应对措施是否可以正常被执行，则可以将该评估项对应的应对措施作为风险应对方式。

可选的，基于各评估项所对应的评估结果，确定与待评估应用相对应的风险应对方式，包括：若评估结果为存在风险，则确定与评估结果对应的评估项所对应的风险处理方式；若确定风险处理方式为可执行方式，则将风险处理方式作为风险应对方式。

在本实施例中，每个评估项所对应的风险处理方式可以为预先配置好的。在基于评估配置条件进行测试分析之后，如果评估结果为不存在风险，那么此种风险可以不作考虑。如果评估结果为存在风险，那么此种风险需作考虑，此时需要确定与该评估配置条件的评估项所对应的风险处理方式，并判断该风险处理方式是否可执行，若可执行，则为可执行方式，此时可以将该风险处理方式作为风险应对方式。例如，需求内容评估项的评估结果为存在风险，可以获取与该评估项所对应的风险处理方式：制定需求准入标准，检查需求质量，判断是否可制定需求准入标准检查需求质量，若不可实现制定需求准入标准检查需求质量，则确定该风险处理方式为不可执行方式，此时处理方式为回避风险。若可实现制定需求准入标准检查需求质量，则确定该风险处理方式为可执行方式，可以将风险处理方式作为风险应对方式输出。

本实施例的技术方案，通过在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项；其中，评估维度包括功能需求、软件设计、软件版本、功能变更和用户中至少一个；确定与评估项相对应的评估配置条件，并基于评估配置条件对待评估应用进行测试分析，得到评估结果；基于各评估项所对应的评估结果，确定与待评估应用相对应的风险应对方式，解决了现有技术中将所有测试风险进行应对处理，导致成本高，实现效果差的问题，实现了通过对测试风险进行不同维度的划分，得到不同的风险评估维度，进而基于不同风险评估维度所对应的至少两个评估项的评估配置条件对待评估应用进行测试分析，得到评估结果，提高风险评估的准确性，在评估结果为存在风险时，准确定位到应对风险所需的风险应对方式，在减少成本消耗，提高风险定位准确性的同时，达到提高测试效果的技术效果。

实施例二

作为上述实施例的一可选实施例，为了使本领域技术人员进一步清楚本发明实施例的技术方案，给出具体的应用场景实例。具体的，可以参见下述具体内容。

在本技术方案中，可以将软件测试面临的风险可以归为至少五个评估维度：功能需求、软件设计、软件版本、功能变更和用户。对每个评估维度的风险进行结构化的风险细化，得到每个评估维度下的至少两个评估项，以及评估项所对应的评估配置条件，以基于评估配置条件评估待评估应用是否存在相应的测试风险。每个评估项的风险的应对处理方式可以分为至少四类：转移风险、减轻风险、接受风险、回避风险，其中，转移风险对应的风险处理方式可以为：将新功能转移其他团队执行，或者寻求其他团队支持；减轻风险所对应风险处理方式可以为：裁剪掉当前优先级低的功能，重新调整资源分配情况；接受风险所对应风险处理方式可以为：接受新需求，通过加长开发时长实现新需求；回避风险所对应风险处理方式可以为：不做处理。每个评估项的风险的应对处理方式可以相同，也可能不同，示例性的，如下表1所示：

表1

续表

在上述方案的基础上，可以基于各评估维度所对应的至少两个评估项的评估配置条件对待评估应用进行风险评估，示例性的，参见图2，图2可以表示为功能需求维度的风险评估方法示意图；其具体实现方式可以是：在分析功能需求维度的风险时，判断需求内容是否完整和清晰(评估配置条件)，如果是，则“没有风险”；如果否，则判断是否可以制定需求准入标准，检查需求质量(应对处理方式)。如果可以制定需求准入标准来检查需求质量，则将该应对处理方式作为“减轻风险”的风险应对方式；如果不可以制定需求准入标准来检查需求质量，则“回避风险”。还可以判断开发人员对需求理解是否充分，如果是则“没有风险”；如果否，则判断能否召开需求讨论会，如果是则可以通过此措施“减轻风险”，即召开需求讨论会作为风险应对方式，如果不是则“回避风险”。还可以判断测试人员对需求理解是否充分，如果是则“没有风险”；如果否，则判断能否召开需求讨论会，如果是则可以通过此措施“减轻风险”，即召开需求讨论会作为风险应对方式，如果不是则“回避风险”。

示例性的，参见图3，图3可以表示为软件设计维度的风险评估方法示意图；其具体实现方式可以是：在分析软件设计维度的风险时，可以判断待评估应用是否使用了新技术、新平台、新架构、新算法，如果否则“没有风险”；如果是，则判断是否可以针对新的内容进行差异性分析和进行专项测试，如果是则“减轻风险”，如果否，则“回避风险”。还可以判断现有架构是否能满足新增特性的性能、可靠性需求，如果是，则“没有风险”；如果否，则判断是否可以设置架构整体负责人，如果是则“减轻风险”，如果否则“回避风险”。还可以判断产品设计是否复杂且难以理解，如果否则“没有风险”；如果是则判断是否可以寻求其他团队支持，如果是则“转移风险”，如果否则“回避风险”。还可以判断开发人员是否熟悉设计并能清晰的描述，如果是则“减轻风险”，如果否则判断是否可以加强开发人员培训，以通过设计图、开会评审方式加强设计熟悉度，如果否则“回避风险”，如果是，则“减轻风险”。还可以判断对异常场景和非功能考虑是否全面，如果是则“没有风险”；如果否则判断是否可以梳理典型异常场景清单，如果否则“回避风险”，如果是则“减轻风险”。

示例性的，参见图4，图4可以表示为软件版本维度的风险评估方法示意图；其具体实现方式可以是：在分析软件版本维度的风险时，可以判断是否使用了新的流程和开发方式，如果否，则“没有风险”，如果是，则“接受风险”。还可以判断开发是否完成自测，如果是，则“没有风险”，如果否则判断是否可以要求开发完成自测并出具报告才接受提测，如果否则只能“回避风险”，如果是则“减轻风险”。还可以判断开发是否做好代码版本管理，如果是则“没有风险”，如果否则判断是否可以制定代码管理规范，如果是则可以“减轻风险”，如果否则“回避风险”。

示例性的，参见图5，图5可以表示为功能变更维度的风险评估方法示意图；其具体实现方式可以是：在分析功能变更维度的风险时，判断是否在项目研发过程中存在需求变更，如果否则“没有风险”，如果是则“接受风险”。还可以判断是否清楚新功能相较于旧功能有哪些变动，如果是则“没有风险”，如果否，则判断是否有专人负责梳理功能变动，如果否则“回避风险”，如果是则“减轻风险”。

示例性的，参见图6，图6可以表示为用户维度的风险评估方法示意图；其具体实现方式可以是：在分析用户维度的风险时，可以判断项目团队任务分配是否存在多方人员配合，如果否则“没有风险”，如果是则判断是否能加强各方沟通协调，如果否则只能“回避风险”，如果是则“减轻风险”。还可以判断项目团队人员是否不稳定，如果否则“没有风险”，如果是则判断是否能通过激励等多项措施来提升团队凝聚力，如果否则“回避风险”，如果是则“减轻风险”。还可以判断项目团队是否人手不足，如果否则只能“回避风险”，如果是则判断是否能将部分功能转出其他团队承接，如果否则“回避风险”；如果能将部分功能转出其他团队承接，则“转移风险”，并把将部分功能转出其他团队承接作为风险应对方式。

本技术方案通过从软件测试风险的角度上进行多个风险评估维度的划分，并对各风险评估维度进行结构化的细化，确定每个风险评估维度下的风险评估项，能够做到对每个风险能快速的定位到对应的风险类别；能够快速确定出对应风险评估项对应的应对措施，帮助解决降低风险。同时通过根据风险应对措施是否适用，快速的给出最终的识别风险的风险应对方式，快速的定位风险和解决方法，从而提高软件测试的效率和准确性。

本实施例的技术方案，通过在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项；其中，评估维度包括功能需求、软件设计、软件版本、功能变更和用户中至少一个；确定与评估项相对应的评估配置条件，并基于评估配置条件对待评估应用进行测试分析，得到评估结果；基于各评估项所对应的评估结果，确定与待评估应用相对应的风险应对方式，解决了现有技术中将所有测试风险进行应对处理，导致成本高，实现效果差的问题，实现了通过对测试风险进行不同维度的划分，得到不同的风险评估维度，进而基于不同风险评估维度所对应的至少两个评估项的评估配置条件对待评估应用进行测试分析，得到评估结果，提高风险评估的准确性，在评估结果为存在风险时，准确定位到应对风险所需的风险应对方式，在减少成本消耗，提高风险定位准确性的同时，达到提高测试效果的技术效果。

实施例三

图7是根据本发明实施例三提供的一种风险评估装置的结构示意图。如图7所示，该装置包括：评估项确定模块710、评估结果确定模块720和风险应对方式确定模块730。

其中，评估项确定模块710，用于在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项；其中，所述评估维度包括功能需求、软件设计、软件版本、功能变更和开发用户中至少一个；评估结果确定模块720，用于确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果；风险应对方式确定模块730，用于基于各评估项所对应的评估结果，确定与所述待评估应用相对应的风险应对方式。

本实施例的技术方案，通过在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项；其中，评估维度包括功能需求、软件设计、软件版本、功能变更和用户中至少一个；确定与评估项相对应的评估配置条件，并基于评估配置条件对待评估应用进行测试分析，得到评估结果；基于各评估项所对应的评估结果，确定与待评估应用相对应的风险应对方式，解决了现有技术中将所有测试风险进行应对处理，导致成本高，实现效果差的问题，实现了通过对测试风险进行不同维度的划分，得到不同的风险评估维度，进而基于不同风险评估维度所对应的至少两个评估项的评估配置条件对待评估应用进行测试分析，得到评估结果，提高风险评估的准确性，在评估结果为存在风险时，准确定位到应对风险所需的风险应对方式，在减少成本消耗，提高风险定位准确性的同时，达到提高测试效果的技术效果。

在上述装置的基础上，可选的，所述目标短信切片类型确定模块520，包括目标短信模板确定单元和目标短信切片类型确定单元。

在上述装置的基础上，可选的，若所述评估维度为功能需求，所述评估结果确定模块720，包括：

需求测试数据确定单元，用于获取与所述功能需求维度相对应的所述待评估应用的需求测试数据；

需求属性信息确定单元，用于基于所述需求测试数据确定需求属性信息；其中，所述需求属性信息中包括需求完整度、需求清晰度和/或需求理解度；

评估结果确定第一单元，用于根据与所述评估项相对应的评估配置条件和所述需求属性信息对所述待评估应用测试分析，得到与所述评估项相对应的评估结果。

在上述装置的基础上，可选的，若所述评估维度为软件设计，所述评估结果确定模块720，还包括：

设计测试数据确定单元，用于获取与所述软件设计维度相对应的所述待评估应用的设计测试数据；

设计属性信息确定单元，用于基于所述设计测试数据确定设计属性信息；其中，所述设计属性信息中包括新增设计信息、设计可靠度、设计可理解度、设计清晰度和/或设计全面度；

评估结果确定第二单元，用于根据与所述评估项相对应的评估配置条件和所述设计属性信息对所述待评估应用测试分析，得到与所述评估项相对应的评估结果。

在上述装置的基础上，可选的，若所述评估维度为软件版本，所述评估结果确定模块720，还包括：

版本测试数据确定单元，用于获取与所述软件版本维度相对应的所述待评估应用的版本测试数据；

版本属性信息确定单元，用于基于所述版本测试数据确定版本属性信息；其中，所述版本属性信息中包括新增版本信息、版本测试度和/或版本管理度；

评估结果确定第三单元，用于根据与所述评估项相对应的评估配置条件和所述版本属性信息对所述待评估应用测试分析，得到与所述评估项相对应的评估结果。

在上述装置的基础上，可选的，若所述评估维度为功能变更，所述评估结果确定模块720，还包括：

变更属性信息确定单元，用于获取与所述功能变更维度相对应的所述待评估应用的变更测试数据，并基于所述变更测试数据确定变更属性信息；其中，所述变更属性信息中包括需求变更信息和/或功能变更信息；

评估结果确定第四单元，用于根据与所述评估项相对应的评估配置条件和所述变更属性信息对所述待评估应用测试分析，得到与所述评估项相对应的评估结果。

在上述装置的基础上，可选的，若所述评估维度为用户，所述评估结果确定模块720，还包括：

用户构成信息确定单元，用于获取与所述用户维度相对应的所述待评估应用的用户构成信息；

用户属性信息确定单元，用于基于所述用户构成信息确定用户属性信息；其中，所述用户属性信息中包括用户隶属信息、用户构成稳定度和/或用户执行信息；

评估结果确定第五单元，用于根据与所述评估项相对应的评估配置条件和所述用户属性信息对所述待评估应用测试分析，得到与所述评估项相对应的评估结果。

在上述装置的基础上，可选的，所述风险应对方式确定模块730包括：

风险处理方式确定单元，用于若所述评估结果为存在风险，则确定与所述评估结果对应的评估项所对应的风险处理方式；

风险应对方式确定单元，用于若确定所述风险处理方式为可执行方式，则将所述风险处理方式作为风险应对方式。

本发明实施例所提供的风险评估装置可执行本发明任意实施例所提供的风险评估方法，具备执行方法相应的功能模块和有益效果。

实施例四

图8是实现本发明实施例的风险评估方法的电子设备的结构示意图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备(如头盔、眼镜、手表等)和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本发明的实现。

如图8所示，电子设备10包括至少一个处理器11，以及与至少一个处理器11通信连接的存储器，如只读存储器(ROM)12、随机访问存储器(RAM)13等，其中，存储器存储有可被至少一个处理器执行的计算机程序，处理器11可以根据存储在只读存储器(ROM)12中的计算机程序或者从存储单元18加载到随机访问存储器(RAM)13中的计算机程序，来执行各种适当的动作和处理。在RAM 13中，还可存储电子设备10操作所需的各种程序和数据。处理器11、ROM 12以及RAM 13通过总线14彼此相连。输入/输出(I/O)接口15也连接至总线14。

电子设备10中的多个部件连接至I/O接口15，包括：输入单元16，例如键盘、鼠标等；输出单元17，例如各种类型的显示器、扬声器等；存储单元18，例如磁盘、光盘等；以及通信单元19，例如网卡、调制解调器、无线通信收发机等。通信单元19允许电子设备10通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

处理器11可以是各种具有处理和计算能力的通用和/或专用处理组件。处理器11的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的处理器、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。处理器11执行上文所描述的各个方法和处理，例如风险评估方法。

在一些实施例中，风险评估方法可被实现为计算机程序，其被有形地包含于计算机可读存储介质，例如存储单元18。在一些实施例中，计算机程序的部分或者全部可以经由ROM 12和/或通信单元19而被载入和/或安装到电子设备10上。当计算机程序加载到RAM 13并由处理器11执行时，可以执行上文描述的风险评估方法的一个或多个步骤。备选地，在其他实施例中，处理器11可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行风险评估方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本发明的方法的计算机程序可以采用一个或多个编程语言的任何组合来编写。这些计算机程序可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，使得计算机程序当由处理器执行时使流程图和/或框图中所规定的功能/操作被实施。计算机程序可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本发明的上下文中，计算机可读存储介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的计算机程序。计算机可读存储介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。备选地，计算机可读存储介质可以是机器可读信号介质。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在电子设备上实施此处描述的系统和技术，该电子设备具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给电子设备。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)、区块链网络和互联网。

计算系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务中，存在的管理难度大，业务扩展性弱的缺陷。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发明中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本发明的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (10)

1.一种风险评估方法，其特征在于，包括：

在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项；其中，所述评估维度包括功能需求、软件设计、软件版本、功能变更和用户中至少一个；

确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果；

基于各评估项所对应的评估结果，确定与所述待评估应用相对应的风险应对方式。

2.根据权利要求1所述的方法，其特征在于，若所述评估维度为功能需求，所述确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果，包括：

获取与所述功能需求维度相对应的所述待评估应用的需求测试数据；

基于所述需求测试数据确定需求属性信息；其中，所述需求属性信息中包括需求完整度、需求清晰度和/或需求理解度；

根据与所述评估项相对应的评估配置条件和所述需求属性信息对所述待评估应用测试分析，得到与所述评估项相对应的评估结果。

3.根据权利要求1所述的方法，其特征在于，若所述评估维度为软件设计，所述确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果，包括：

获取与所述软件设计维度相对应的所述待评估应用的设计测试数据；

基于所述设计测试数据确定设计属性信息；其中，所述设计属性信息中包括新增设计信息、设计可靠度、设计可理解度、设计清晰度和/或设计全面度；

根据与所述评估项相对应的评估配置条件和所述设计属性信息对所述待评估应用测试分析，得到与所述评估项相对应的评估结果。

4.根据权利要求1所述的方法，其特征在于，若所述评估维度为软件版本，所述确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果，包括：

获取与所述软件版本维度相对应的所述待评估应用的版本测试数据；

基于所述版本测试数据确定版本属性信息；其中，所述版本属性信息中包括新增版本信息、版本测试度和/或版本管理度；

根据与所述评估项相对应的评估配置条件和所述版本属性信息对所述待评估应用测试分析，得到与所述评估项相对应的评估结果。

5.根据权利要求1所述的方法，其特征在于，若所述评估维度为功能变更，所述确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果，包括：

获取与所述功能变更维度相对应的所述待评估应用的变更测试数据，并基于所述变更测试数据确定变更属性信息；其中，所述变更属性信息中包括需求变更信息和/或功能变更信息；

根据与所述评估项相对应的评估配置条件和所述变更属性信息对所述待评估应用测试分析，得到与所述评估项相对应的评估结果。

6.根据权利要求1所述的方法，其特征在于，若所述评估维度为用户，所述确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果，包括：

获取与所述用户维度相对应的所述待评估应用的用户构成信息；

基于所述用户构成信息确定用户属性信息；其中，所述用户属性信息中包括用户隶属信息、用户构成稳定度和/或用户执行信息；

根据与所述评估项相对应的评估配置条件和所述用户属性信息对所述待评估应用测试分析，得到与所述评估项相对应的评估结果。

7.根据权利要求1所述的方法，其特征在于，所述基于各评估项所对应的评估结果，确定与所述待评估应用相对应的风险应对方式，包括：

若所述评估结果为存在风险，则确定与所述评估结果对应的评估项所对应的风险处理方式；

若确定所述风险处理方式为可执行方式，则将所述风险处理方式作为风险应对方式。

8.一种风险评估装置，其特征在于，包括：

评估项确定模块，用于在接收到与待评估应用对应的风险评估请求时，确定各评估维度所对应的至少两个评估项；其中，所述评估维度包括功能需求、软件设计、软件版本、功能变更和开发用户中至少一个；

评估结果确定模块，用于确定与所述评估项相对应的评估配置条件，并基于所述评估配置条件对所述待评估应用进行测试分析，得到评估结果；

风险应对方式确定模块，用于基于各评估项所对应的评估结果，确定与所述待评估应用相对应的风险应对方式。

9.一种电子设备，其特征在于，所述电子设备包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-7中任一项所述的风险评估方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使处理器执行时实现权利要求1-7中任一项所述的风险评估方法。

Images