CN115756393A - 基于研发周期的风险评估方法和装置、处理器及电子设备 - Google Patents
基于研发周期的风险评估方法和装置、处理器及电子设备 Download PDFInfo
- Publication number
- CN115756393A CN115756393A CN202211426972.8A CN202211426972A CN115756393A CN 115756393 A CN115756393 A CN 115756393A CN 202211426972 A CN202211426972 A CN 202211426972A CN 115756393 A CN115756393 A CN 115756393A
- Authority
- CN
- China
- Prior art keywords
- design
- requirement
- point
- information
- item information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请公开了一种基于研发周期的风险评估方法和装置、处理器及电子设备,涉及人工智能技术领域,该方法包括:将预测设计点和需求设计点进行比对分析,得到第一分析结果;对每个代码包进行解析,得到每个代码包对应的第二需求项信息,第二需求项信息和需求设计点进行比对分析,得到第二分析结果;获取目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,以确定目标应用的测试阶段是否存在风险点。通过本申请,解决了相关技术中采用人工审核的方式评估目标应用在不同研发阶段下的风险性,导致应用风险评估的准确度比较低的问题。
Description
技术领域
本申请涉及人工智能技术领域,具体而言,涉及一种基于研发周期的风险评估方法和装置、处理器及电子设备。
背景技术
在IT架构的转型和数字化转型的背景下,应用架构设计的稳定是满足市场需求、不断竞争的前提条件。为了不断提高架构设计的高质量和外部感知力,需要进一步对架构设计进行强化,保障在研发周期内的总体设计-程序设计-编码实现的一致性,提升产品运行稳定。
目前有通过建立目标软件的程序文件与所述程序文件对应的业务场景以及业务节点的映射;根据所述映射获取所述程序文件中的每个代码文件对应的所述业务场景以及业务节点;根据所述业务场景以及所述业务节点确定所述目标软件研发进程。但是这一研究主要体现在编码阶段,然而实际的研发过程中,需要在前中后期各阶段都要关注架构设计点是否有实现,与现有技术相比,传统的方法一般采用人工审核,存在各阶段之间不连通性,且往往在测试阶段去发现设计的缺陷,周期长、效率低下,且验收时间滞后,实现的架构设计难以满足高质量产品交付和生产稳定的需求。
针对相关技术中一般采用人工审核的方式评估目标应用在不同研发阶段下的风险性,导致应用风险评估的准确度比较低的问题,目前尚未提出有效的解决方案。
发明内容
本申请的主要目的在于提供一种基于研发周期的风险评估方法和装置、处理器及电子设备,以解决相关技术中一般采用人工审核的方式评估目标应用在不同研发阶段下的风险性,导致应用风险评估的准确度比较低的问题。
为了实现上述目的,根据本申请的一个方面,提供了一种基于研发周期的风险评估方法。该方法包括:基于目标应用的功能需求,确定所述目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对所述第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,所述第一需求项信息表征实现所述需求设计点的需求;将所述预测设计点和所述需求设计点进行比对分析,得到第一分析结果,其中,所述第一分析结果用于确定所述目标应用的设计阶段是否存在风险点;获取所述目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并将所述第二需求项信息和所述需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定所述目标应用的编码阶段是否存在风险点,所述代码包依据所述需求设计点得到;获取所述目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将所述第三需求项信息与所述第二需求项信息进行比对分析,得到第三分析结果,其中,所述第三分析结果用于确定所述目标应用的测试阶段是否存在风险点。
进一步地,基于目标应用的功能需求,确定所述目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息包括:获取设计标准库,其中,所述设计标准库中至少包括多个应用信息和每个应用信息对应的需求设计点;基于目标应用的功能需求,从所述设计标准库中确定所述目标应用对应的多个需求设计点;对每个需求设计点进行功能需求拆分,以得到每个需求设计点对应的第一需求项信息。
进一步地,获取设计标准库包括:确定多个应用以及每个应用对应的技术领域;依据每个应用对应的技术领域,确定每个应用的需求设计点;基于每个应用的需求设计点,确定每个需求设计点的判断标准,其中,所述判断标准用于在所述编码阶段和所述测试阶段判断每个需求设计点对应的功能是否被实现的标准;基于所述多个应用、所述需求设计点和所述判断标准,获取所述设计标准库。
进一步地,在将所述预测设计点和所述需求设计点进行比对分析,得到第一分析结果之后,所述方法还包括:若所述第一分析结果表征所述预测设计点与所述需求设计点一一对应,则确定所述目标应用的设计阶段不存在风险点;若所述第一分析结果表征所述预测设计点与所述需求设计点不是一一对应,则确定所述目标应用的设计阶段存在风险点,将所述风险点对应的风险信息发送至目标对象,以对所述风险点进行处理。
进一步地,在对每个代码包进行解析,得到每个代码包对应的第二需求项信息之前,所述方法还包括:依据预设检查规则对每个代码包的形式进行检测,以确定每个代码包是否满足预设要求。
进一步地,在将所述第二需求项信息和所述需求设计点进行比对分析,得到第二分析结果之后,所述方法还包括:若所述第二分析结果表征所述第二需求项信息与所述需求设计点一一对应,则依据所述设计标准库中需求设计点的判断标准,判断所述第二需求项信息对应的代码包是否实现所述需求设计点对应的功能;若所述第二需求项信息对应的代码包已实现所述需求设计点对应的功能,则所述目标应用的编码阶段不存在风险点。
进一步地,在判断所述第二需求项信息是否与所述需求设计点一一对应之后,所述方法还包括:若所述第二分析结果表征所述第二需求项信息与所述需求设计点不是一一对应,或者所述第二需求项信息对应的代码包未实现所述需求设计点对应的功能,则所述目标应用的编码阶段存在风险点。
进一步地,在将所述第三需求项信息与所述第二需求项信息进行比对分析,得到第三分析结果之后,所述方法还包括:获取所述目标应用在生产阶段中的运行信息数据,对所述运行信息数据进行分析,得到目标数据信息,其中,所述目标数据信息中至少包括所述目标应用的潜在风险点信息和所述目标应用在生产阶段已发生的风险点信息;依据目标数据信息对所述目标应用进行更新处理。
进一步地,在获取所述目标应用的运行信息数据,对所述运行信息数据进行分析,得到目标数据信息之后,所述方法还包括:依据所述目标数据信息,判断所述设计标准库中的需求设计点是否需要更新,以及是否需要增加所述设计标准库中的需求设计点,得到判断结果;依据所述判断结果,对所述设计标准库中的数据进行操作。
为了实现上述目的,根据本申请的另一方面,提供了一种基于研发周期的风险评估装置。该装置包括:第一确定单元,用于基于目标应用的功能需求,确定所述目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对所述第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,所述第一需求项信息表征实现所述需求设计点的需求;分析单元,用于将所述预测设计点和所述需求设计点进行比对分析,得到第一分析结果,其中,所述第一分析结果用于确定所述目标应用的设计阶段是否存在风险点;第一获取单元,用于获取所述目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并将所述第二需求项信息和所述需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定所述目标应用的编码阶段是否存在风险点,其中,所述代码包依据所述需求设计点得到;解析单元,用于获取所述目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将所述第三需求项信息与所述第二需求项信息进行比对分析,得到第三分析结果,其中,所述第三分析结果用于确定所述目标应用的测试阶段是否存在风险点。
进一步地,所述第一确定单元包括:获取模块,用于获取设计标准库,其中,所述设计标准库中至少包括多个应用信息和每个应用信息对应的需求设计点;确定模块,用于基于目标应用的功能需求,从所述设计标准库中确定所述目标应用对应的多个需求设计点;拆分模块,用于对每个需求设计点进行功能需求拆分,以得到每个需求设计点对应的第一需求项信息。
进一步地,所述获取模块包括:第一确定子模块,用于确定多个应用以及每个应用对应的技术领域;第二确定子模块,用于依据每个应用对应的技术领域,确定每个应用的需求设计点;第三确定子模块,用于基于每个应用的需求设计点,确定每个需求设计点的判断标准,其中,所述判断标准用于在所述编码阶段和所述测试阶段判断每个需求设计点对应的功能是否被实现的标准;获取子模块,用于基于所述多个应用、所述需求设计点和所述判断标准,获取所述设计标准库。
进一步地,所述装置还包括:第二确定单元,用于在将所述预测设计点和所述需求设计点进行比对分析,得到第一分析结果之后,若所述第一分析结果表征所述预测设计点与所述需求设计点一一对应,则确定所述目标应用的设计阶段不存在风险点;第三确定单元,用于若所述第一分析结果表征所述预测设计点与所述需求设计点不是一一对应,则确定所述目标应用的设计阶段存在风险点,将所述风险点对应的风险信息发送至目标对象,以对所述风险点进行处理。
进一步地,所述装置还包括:第四确定单元,用于在对每个代码包进行解析,得到每个代码包对应的第二需求项信息之前,依据预设检查规则对每个代码包的形式进行检测,以确定每个代码包是否满足预设要求。
进一步地,所述装置还包括:第一判断单元,用于在将所述第二需求项信息和所述需求设计点进行比对分析,得到第二分析结果之后,若所述第二分析结果表征所述第二需求项信息与所述需求设计点一一对应,则依据所述设计标准库中需求设计点的判断标准,判断所述第二需求项信息对应的代码包是否实现所述需求设计点对应的功能;第五确定单元,用于若所述第二需求项信息对应的代码包已实现所述需求设计点对应的功能,则所述目标应用的编码阶段不存在风险点。
进一步地,所述装置还包括:第六确定单元,用于在判断所述第二需求项信息是否与所述需求设计点一一对应之后,若所述第二分析结果表征所述第二需求项信息与所述需求设计点不是一一对应,或者所述第二需求项信息对应的代码包未实现所述需求设计点对应的功能,则所述目标应用的编码阶段存在风险点。
进一步地,所述装置还包括:获取单元,用于在将所述第三需求项信息与所述第二需求项信息进行比对分析,得到第三分析结果之后,获取所述目标应用在生产阶段中的运行信息数据,对所述运行信息数据进行分析,得到目标数据信息,其中,所述目标数据信息中至少包括所述目标应用的潜在风险点信息和所述目标应用在生产阶段已发生的风险点信息;更新单元,用于依据目标数据信息对所述目标应用进行更新处理。
进一步地,所述装置还包括:第二判断单元,用于在获取所述目标应用的运行信息数据,对所述运行信息数据进行分析,得到目标数据信息之后,依据所述目标数据信息,判断所述设计标准库中的需求设计点是否需要更新,以及是否需要增加所述设计标准库中的需求设计点,得到判断结果;操作单元,用于依据所述判断结果,对所述设计标准库中的数据进行操作。
为了实现上述目的,根据本申请的一个方面,提供了一种处理器,处理器用于运行程序,其中,所述程序运行时执行上述任意一项所述的基于研发周期的风险评估方法。
为了实现上述目的,根据本申请的一个方面,提供了一种电子设备,电子设备包括一个或多个处理器和存储器,存储器用于存储一个或多个处理器实现上述任意一项所述的基于研发周期的风险评估方法。
通过本申请,采用以下步骤:基于目标应用的功能需求,确定目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,第一需求项信息表征实现需求设计点的需求;将预测设计点和需求设计点进行比对分析,得到第一分析结果,其中,第一分析结果用于确定目标应用的设计阶段是否存在风险点;获取目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并第二需求项信息和需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定目标应用的编码阶段是否存在风险点,其中,代码包依据需求设计点得到;获取目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将第三需求项信息与第二需求项信息进行比对分析,得到第三分析结果,其中,第三分析结果用于确定目标应用的测试阶段是否存在风险点,解决了相关技术中一般采用人工审核的方式评估目标应用在不同研发阶段下的风险性,导致应用风险评估的准确度比较低的问题。在本方案中,在设计阶段、编码阶段、测试阶段各个阶段对应用设计进行验收,在设计阶段,根据需求设计点对当期应用涉及到的内容进行风险评估,可以快速识别出设计阶段遗漏的设计点;在编码阶段,根据第二需求项信息和需求设计点继续匹配,可以快速识别出编码阶段遗漏的设计点;在测试阶段,将第三需求项信息与第二需求项信息进行比对分析,可以快速识别出测试阶段遗漏的设计点;通过上述步骤将整个研发生命周期打通,及时准确地识别设计风险,进而达到了提高应用风险评估的准确度的效果。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1是根据本申请实施例提供的基于研发周期的风险评估方法的流程图;
图2是根据本申请实施例提供的可选的基于研发周期的风险评估方法的流程图;
图3是根据本申请实施例提供的基于研发周期的风险评估装置的示意图;
图4是根据本申请实施例提供的可选的基于研发周期的风险评估装置的示意图;
图5是根据本申请实施例提供的设计标准库模块的示意图;
图6是根据本申请实施例提供的设计基础信息模块的示意图;
图7是根据本申请实施例提供的设计分析模块的示意图;
图8是根据本申请实施例提供的设计风险信息模块的示意图;
图9是根据本申请实施例提供的代码分析模块的示意图;
图10是根据本申请实施例提供的代码风险信息模块的示意图;
图11是根据本申请实施例提供的案例分析模块的示意图;
图12是根据本申请实施例提供的案例风险信息模块的示意图;
图13是根据本申请实施例提供的生产运行模块的示意图;
图14是根据本申请实施例提供的生产风险信息模块的示意图;
图15是根据本申请实施例提供的电子设备的示意图。
具体实施方式
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
为了便于描述,以下对本申请实施例涉及的部分名词或术语进行说明:
需求拆分:需求分析阶段针对业务意向或业务正式需求进一步细化管理的活动。在需求阶段,研发团队在遵循业务部门意向且兼顾技术实现的基础上,对业务部门的需求意向或方案进行分解,形成对应的需求项。
需求项:是具有业务价值并能产生业务效果的,包含端到端完整业务场景的,最小范围可独立投产的需求。需求项基于业务意向目标拆解,是满足业务期望的、业务与科技沟通衔接的、可独立安排版本计划的最小单元。根据具体业务目标的不同,需求项相当于敏捷开发中的一个或多个用户故事(User Story)的集合。
需求条目:是需求项的更小粒度拆分,在其需求项内独立可测试、完备的需求描述,体现具有终端使用价值的功能特性。其验收标准约等于用户使用场景,可以体现或转化为流程测试。
需求子条目:是需求的最小粒度,也是测试的最小粒度,测试可以根据每个需求子条目内容开展测试。
需要说明的是,本公开所涉及的相关信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于展示的数据、分析的数据等),均为经用户授权或者经过各方充分授权的信息和数据。例如,本系统和相关用户或机构间设置有接口,在获取相关信息之前,需要通过接口向前述的用户或机构发送获取请求,并在接收到前述的用户或机构反馈的同意信息后,获取相关信息。
下面结合优选的实施步骤对本发明进行说明,图1是根据本申请实施例提供的基于研发周期的风险评估方法的流程图,如图1所示,该方法包括如下步骤:
步骤S101,基于目标应用的功能需求,确定目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,第一需求项信息表征实现需求设计点的需求;
具体地,在目标应用设计阶段时,根据目标应用的实际的功能需求,明确用于实现该功能需求的多个需求设计点,然后对需求设计点进行需求拆分,拆分为需求项,需求条目以及需求子条目等,得到上述的第一需求项信息。将拆分的需求项、需求条目和需求子条目等按照信息类型保存在信息存储器中。将上述的第一需求项信息输入到目标神经网络模型中,通过目标神经网络模型对第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点。
需要说明的是,目标神经网络模型可以是XGBoost算法模型,可以采用以下步骤进行训练得到:随机获取设计需求点信息,判断拆分出来的需求项、需求条目和需求子条目描述是否为对应的设计需求点,如果是,将对应的需求项、需求条目和需求子条目描述置为0标签;如果不是,则置为1标签。对0标签的特征进行提取,包含高可用、可扩展、联机交易、批量交易、PaaS(Platform as a Service平台即服务)、SLB(Server Load Balance负载均衡)、解耦、升级改造、主机下平台、资源监控等,建立多维度的特征作为是设计需求的可能因素。通过多维度的特征信息对XGBoost算法进行训练,通过调整参数,不断的提高模型预测的精准度,最终训练出可以精确的判断出设计需求点的模型。
步骤S102,将预测设计点和需求设计点进行比对分析,得到第一分析结果,其中,第一分析结果用于确定目标应用的设计阶段是否存在风险点;
具体地,在得到预测设计点后,将预测设计点和需求设计点进行比对分析,如果需求设计点对应的内容在预测设计点中没有找到,则说明预测设计点有遗漏,也就是说目标应用的设计阶段存在风险点,将当期应用的设计风险信息推送给相关人员。如果没有遗漏,说明目标应用的设计阶段不存在风险点。
根据识别到设计风险点,将对应的信息推送给架构师,进行完善设计第一需求项信息的内容,推送的信息包括应用名、版本、需求设计点、已纳入实现的设计点、未纳入实现的设计点、设计需求时间、架构师等相关信息。综上所述,通过上述步骤能够及时准确地识别目标应用的设计阶段是否存在风险点。
步骤S103,获取目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并第二需求项信息和需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定目标应用的编码阶段是否存在风险点,其中,代码包依据需求设计点得到;
具体地,开发人员根据第一需求项信息进行代码编写,在程序代码实现时,由于需求子条目是设计需求的最小粒度,所以在代码编写时对完成设计的程序对应的需求子条目标识对应的编号,以便之后对每个代码包进行解析时,能够根据标识的编号得到每个代码包对应的第二需求项信息。通过将第二需求项信息和需求设计点进行比对分析,可以判断代码是否有遗漏,进而确定目标应用的编码阶段是否存在风险点。
步骤S104,获取目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将第三需求项信息与第二需求项信息进行比对分析,得到第三分析结果,其中,第三分析结果用于确定目标应用的测试阶段是否存在风险点。
具体地,测试人员根据代码包的实现的功能点进行测试案例编写,由于需求子条目是也是测试案例编写的最小粒度,因此每个测试案例都应该标识是哪个需求子条目的测试案例,并编写具体的测试案例描述、数据准备、预期结果等信息,便于后续解析。通过对每个测试日志进行解析得到每个测试日志对应的第三需求项信息,通过对第三需求项信息与第二需求项信息进行比对分析,以确定目标应用的测试阶段是否存在风险点。
综上所述,在设计阶段,根据需求设计点对当期应用涉及到的内容进行风险评估,可以快速识别出设计阶段遗漏的设计点;在编码阶段,根据第二需求项信息和需求设计点继续匹配,可以快速识别出编码阶段遗漏的设计点;在测试阶段,将第三需求项信息与第二需求项信息进行比对分析,可以快速识别出测试阶段遗漏的设计点;通过上述步骤将整个研发生命周期打通,及时准确地识别设计风险,提高了应用风险评估的准确度。
在本申请实施例提供的基于研发周期的风险评估方法中,基于目标应用的功能需求,确定目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息包括:获取设计标准库,其中,设计标准库中至少包括多个应用信息和每个应用信息对应的需求设计点;基于目标应用的功能需求,从设计标准库中确定目标应用对应的多个需求设计点;对每个需求设计点进行功能需求拆分,以得到每个需求设计点对应的第一需求项信息。
具体地,建立设计标准库,设计标准库中至少包括多个应用信息和每个应用信息对应的需求设计点,然后依照目标应用的功能需求,从设计标准库中确定目标应用对应的多个需求设计点;对每个需求设计点进行功能需求拆分,以得到每个需求设计点对应的第一需求项信息。
在本申请实施例提供的基于研发周期的风险评估方法中,采用以下步骤获取设计标准库:确定多个应用以及每个应用对应的技术领域;依据每个应用对应的技术领域,确定每个应用的需求设计点;基于每个应用的需求设计点,确定每个需求设计点的判断标准,其中,判断标准用于在编码阶段和测试阶段判断每个需求设计点对应的功能是否被实现的标准;基于多个应用、需求设计点和判断标准,获取设计标准库。
具体地,确定多个应用以及每个应用对应的技术领域,主要是企业所在产品中涉及的设计领域,用于改进和提高产品在市场中的稳定性,提高用户满意度。主要包含分布式设计、性能设计、安全设计、临界资源、应用入云、主机下平台、大数据领域、云计算等领域。
根据设计领域提炼出可能存在产品问题的需求设计点,针对分布式设计,主要在分布式服务、分布式缓存、分布式批量、分布式数据库、分布式消息等;针对性能设计领域,主要在架构调整、联机交易、批量交易、大数据批量等存在的性能问题;针对安全设计,在敏感数据、表结构变更、客户端使用、动态交易时等涉及到的安全数据问题;针对临界资源,主要在资源池、线程池、熔断机制、队列大小、资源监控等存在资源使用问题;针对应用入云,主要在负载均衡、容器起停、云上灰度、应用镜像、应用日志等涉及上云注意的风险点;针对主机下平台,主要在转型路径解耦、并行核对观察、应用数据切换、业务一致性保障等问题上的需求设计点。
根据提炼出可能存在产品问题的需求设计点,确定出在代码阶段和测试阶段能够验证该需求设计点正确与否的断言(即上述的判断标准),使得在各阶段都有对应的验收措施。基于多个应用、需求设计点和判断标准,获取设计标准库。
综上所述,通过建立对应的设计标准库便于后续快速设计出需要的目标应用。
如何确定目标应用的设计阶段是否存在风险点是至关重要的,因此,在本申请实施例提供的基于研发周期的风险评估方法中,在将预测设计点和需求设计点进行比对分析,得到第一分析结果之后,还包括:若第一分析结果表征预测设计点与需求设计点一一对应,则确定目标应用的设计阶段不存在风险点;若第一分析结果表征预测设计点与需求设计点不是一一对应,则确定目标应用的设计阶段存在风险点,将风险点对应的风险信息发送至目标对象,以对风险点进行处理。
具体地,在得到预测设计点后,将预测设计点和需求设计点进行比对分析,如果需求设计点对应的内容在预测设计点中没有找到,则说明预测设计点有遗漏,也就是说目标应用的设计阶段存在风险点,将当期应用的设计风险信息推送给相关人员。如果没有遗漏,说明目标应用的设计阶段不存在风险点。
可选地,在本申请实施例提供的基于研发周期的风险评估方法中,在对每个代码包进行解析,得到每个代码包对应的第二需求项信息之前,该方法还包括:依据预设检查规则对每个代码包的形式进行检测,以确定每个代码包是否满足预设要求。
具体地,开发人员根据第一需求项信息进行代码编写,在程序代码实现时,由于需求子条目是设计需求的最小粒度,所以在代码编写时对完成设计的程序对应的需求子条目标识对应的编号,以便之后对每个代码包进行解析时,能够根据标识的编号得到每个代码包对应的第二需求项信息。
代码包提交时,并不是所有的代码包都能提交成功,所有代码包需要经过门禁对程序问题进行检查,对代码包进行完善。程序检查规则(即上述的预设检查规则)分为4种,包括SQL检查规则、代码检查规则、配置文件检查规则以及规范检查规则。其中,SQL检查规则有执行计划、表容量、倾斜、语句不下推、大表未分区等,代码检查规则包含类重名等,配置文件检查规则包括写死IP、域名等,规范检查规则包括后缀、命名规范等。
通过对代码包进行规范检测有助于提高代码包运行成功的概率,以及减少后续的代码运行风险。
如何确定目标应用的编码阶段是否存在风险点是至关重要的,因此,在本申请实施例提供的基于研发周期的风险评估方法中,在将第二需求项信息和需求设计点进行比对分析,得到第二分析结果之后,还包括:若第二分析结果表征第二需求项信息与需求设计点一一对应,则依据设计标准库中需求设计点的判断标准,判断第二需求项信息对应的代码包是否实现需求设计点对应的功能;若第二需求项信息对应的代码包已实现需求设计点对应的功能,则目标应用的编码阶段不存在风险点。
若第二分析结果表征第二需求项信息与需求设计点不是一一对应,或者第二需求项信息对应的代码包未实现需求设计点对应的功能,则目标应用的编码阶段存在风险点。
具体地,在对代码包解析得到对应的第二需求项信息后,对比第二需求项信息和需求设计点,如果需求设计点的内容在第二需求项信息中没有找到,则说明代码实现有遗漏,存在风险点;如果第二需求项信息与需求设计点一一对应,则依照设计标准库中需求设计点的判断标准,判断第二需求项信息对应的代码包是否实现需求设计点对应的功能,如果没有实现对应的功能,说明存在风险点;如果第二需求项信息对应的代码包已实现需求设计点对应的功能,则说明目标应用的编码阶段不存在风险点。
为了不断完全目标应用,在本申请实施例提供的基于研发周期的风险评估方法中,在将第三需求项信息与第二需求项信息进行比对分析,得到第三分析结果之后,该方法还包括:获取目标应用在生产阶段中的运行信息数据,对运行信息数据进行分析,得到目标数据信息,其中,目标数据信息中至少包括目标应用的潜在风险点信息和目标应用在生产阶段已发生的风险点信息;依据目标数据信息对目标应用进行更新处理。
具体地,可以通过生产监控器监控目标应用投产的实际运行情况(即上述的运行信息数据),包括目标应用响应时间、资源情况、是否有批量中断、语句的执行计划、统计信息等。对运行信息数据进行分析,得到对需求设计点有价值的信息(即上述的目标数据信息)。例如,针对批量交易,记录交易起始时间、是否中断、资源使用情况、语句的执行计划、统计信息等;针对联机交易,记录响应时间、是否有报错、资源是否溢出等;针对临界资源情况,记录线程池和连接池的上下资源使用情况、队列大小等;针对应用入云的情况,记录应用容器数量、容器资源情况、负载均衡等生产运行情况。通过解析出来的目标数据信息对目标应用进行优化和更新处理。
为了实现整个研发周期的架构设计的闭环,在本申请实施例提供的基于研发周期的风险评估方法中,在获取目标应用的运行信息数据,对运行信息数据进行分析,得到目标数据信息之后,该方法还包括:依据目标数据信息,判断设计标准库中的需求设计点是否需要更新,以及是否需要增加设计标准库中的需求设计点,得到判断结果;依据判断结果,对设计标准库中的数据进行操作。
具体地,通过目标数据信息,判断设计标准库中的需求设计点是否需要更新,以及是否需要增加设计标准库中的需求设计点,得到判断结果;依据判断结果,对设计标准库中的数据进行操作,以避免在后续的设计中出现此类问题,形成设计的闭环工作。
在一可选的实例中,可以采用如图2所示的流程图实现对目标应用的风险评估,具体地:
步骤S1,根据设计标准库确定当期版本的应用的需求设计点,将需求设计点纳入到设计基础信息库。
步骤S2,通过XGBoost学习算法进行训练,识别出预测设计点。首先根据实际研发过程中拆分的需求项、需求条目、需求子条目的内容,采用机器学习算法XGBoost进行建模,筛选出实际研发中已纳入的预测设计点,纳入到设计信息库,与设计基础信息库进行匹配,识别出设计风险点。
步骤S3,在代码程序中对已实现的设计点所属的需求子条目编号进行标识,代码包提交后自动对代码包进行解析,得到对应的需求项信息,并纳入到代码信息库,通过与设计信息库进行匹配,识别在代码中缺失的设计风险。
步骤S4,测试案例执行后,对测试案例的日志进行解析,得到对应的需求项信息,以设计标准库中的验证点中的判断准则为基准,识别出代码实现的设计问题,以及测试案例是否存在库。
步骤S5,部署到生产后,采用非功能性风险扫描工具对目标应用的生产运行情况进行扫描,将潜在的或者已经发生的生产问题纳入到生产风险信息库,并自动更新设计标准库,形成架构设计验收闭环。
本申请实施例提供的基于研发周期的风险评估方法,通过基于目标应用的功能需求,确定目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,第一需求项信息表征实现需求设计点的需求;将预测设计点和需求设计点进行比对分析,得到第一分析结果,其中,第一分析结果用于确定目标应用的设计阶段是否存在风险点;获取目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并第二需求项信息和需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定目标应用的编码阶段是否存在风险点,其中,代码包依据需求设计点得到;获取目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将第三需求项信息与第二需求项信息进行比对分析,得到第三分析结果,其中,第三分析结果用于确定目标应用的测试阶段是否存在风险点,解决了相关技术中一般采用人工审核的方式评估目标应用在不同研发阶段下的风险性,导致应用风险评估的准确度比较低的问题。在本方案中,在设计阶段、编码阶段、测试阶段各个阶段对应用设计进行验收,在设计阶段,根据需求设计点对当期应用涉及到的内容进行风险评估,可以快速识别出设计阶段遗漏的设计点;在编码阶段,根据第二需求项信息和需求设计点继续匹配,可以快速识别出编码阶段遗漏的设计点;在测试阶段,将第三需求项信息与第二需求项信息进行比对分析,可以快速识别出测试阶段遗漏的设计点;通过上述步骤将整个研发生命周期打通,及时准确地识别设计风险,进而达到了提高应用风险评估的准确度的效果。
需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
本申请实施例还提供了一种基于研发周期的风险评估装置,需要说明的是,本申请实施例的基于研发周期的风险评估装置可以用于执行本申请实施例所提供的用于基于研发周期的风险评估方法。以下对本申请实施例提供的基于研发周期的风险评估装置进行介绍。
图3是根据本申请实施例的基于研发周期的风险评估装置的示意图。如图3所示,该装置包括:第一确定单元301,分析单元302,第一获取单元303和解析单元304。
第一确定单元301,用于基于目标应用的功能需求,确定目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,第一需求项信息表征实现需求设计点的需求;
分析单元302,用于将预测设计点和需求设计点进行比对分析,得到第一分析结果,其中,第一分析结果用于确定目标应用的设计阶段是否存在风险点;
第一获取单元303,用于获取目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并第二需求项信息和需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定目标应用的编码阶段是否存在风险点,其中,代码包依据需求设计点得到;
解析单元304,用于获取目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将第三需求项信息与第二需求项信息进行比对分析,得到第三分析结果,其中,第三分析结果用于确定目标应用的测试阶段是否存在风险点。
本申请实施例提供的基于研发周期的风险评估装置,通过第一确定单元301基于目标应用的功能需求,确定目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,第一需求项信息表征实现需求设计点的需求;分析单元302将预测设计点和需求设计点进行比对分析,得到第一分析结果,其中,第一分析结果用于确定目标应用的设计阶段是否存在风险点;第一获取单元303获取目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并第二需求项信息和需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定目标应用的编码阶段是否存在风险点,其中,代码包依据需求设计点得到;解析单元304获取目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将第三需求项信息与第二需求项信息进行比对分析,得到第三分析结果,其中,第三分析结果用于确定目标应用的测试阶段是否存在风险点,解决了相关技术中一般采用人工审核的方式评估目标应用在不同研发阶段下的风险性,导致应用风险评估的准确度比较低的问题。在本方案中,在设计阶段、编码阶段、测试阶段各个阶段对应用设计进行验收,在设计阶段,根据需求设计点对当期应用涉及到的内容进行风险评估,可以快速识别出设计阶段遗漏的设计点;在编码阶段,根据第二需求项信息和需求设计点继续匹配,可以快速识别出编码阶段遗漏的设计点;在测试阶段,将第三需求项信息与第二需求项信息进行比对分析,可以快速识别出测试阶段遗漏的设计点;通过上述步骤将整个研发生命周期打通,及时准确地识别设计风险,进而达到了提高应用风险评估的准确度的效果。
可选地,在本申请实施例提供的基于研发周期的风险评估装置中,所述第一确定单元包括:获取模块,用于获取设计标准库,其中,所述设计标准库中至少包括多个应用信息和每个应用信息对应的需求设计点;确定模块,用于基于目标应用的功能需求,从所述设计标准库中确定所述目标应用对应的多个需求设计点;拆分模块,用于对每个需求设计点进行功能需求拆分,以得到每个需求设计点对应的第一需求项信息。
可选地,在本申请实施例提供的基于研发周期的风险评估装置中,所述获取模块包括:第一确定子模块,用于确定多个应用以及每个应用对应的技术领域;第二确定子模块,用于依据每个应用对应的技术领域,确定每个应用的需求设计点;第三确定子模块,用于基于每个应用的需求设计点,确定每个需求设计点的判断标准,其中,所述判断标准用于在所述编码阶段和所述测试阶段判断每个需求设计点对应的功能是否被实现的标准;获取子模块,用于基于所述多个应用、所述需求设计点和所述判断标准,获取所述设计标准库。
可选地,在本申请实施例提供的基于研发周期的风险评估装置中,所述装置还包括:第二确定单元,用于在将所述预测设计点和所述需求设计点进行比对分析,得到第一分析结果之后,若所述第一分析结果表征所述预测设计点与所述需求设计点一一对应,则确定所述目标应用的设计阶段不存在风险点;第三确定单元,用于若所述第一分析结果表征所述预测设计点与所述需求设计点不是一一对应,则确定所述目标应用的设计阶段存在风险点,将所述风险点对应的风险信息发送至目标对象,以对所述风险点进行处理。
可选地,在本申请实施例提供的基于研发周期的风险评估装置中,所述装置还包括:第四确定单元,用于在对每个代码包进行解析,得到每个代码包对应的第二需求项信息之前,依据预设检查规则对每个代码包的形式进行检测,以确定每个代码包是否满足预设要求。
可选地,在本申请实施例提供的基于研发周期的风险评估装置中,所述装置还包括:第一判断单元,用于在将所述第二需求项信息和所述需求设计点进行比对分析,得到第二分析结果之后,若所述第二分析结果表征所述第二需求项信息与所述需求设计点一一对应,则依据所述设计标准库中需求设计点的判断标准,判断所述第二需求项信息对应的代码包是否实现所述需求设计点对应的功能;第五确定单元,用于若所述第二需求项信息对应的代码包已实现所述需求设计点对应的功能,则所述目标应用的编码阶段不存在风险点。
可选地,在本申请实施例提供的基于研发周期的风险评估装置中,所述装置还包括:第六确定单元,用于在判断所述第二需求项信息是否与所述需求设计点一一对应之后,若所述第二分析结果表征所述第二需求项信息与所述需求设计点不是一一对应,或者所述第二需求项信息对应的代码包未实现所述需求设计点对应的功能,则所述目标应用的编码阶段存在风险点。
可选地,在本申请实施例提供的基于研发周期的风险评估装置中,所述装置还包括:获取单元,用于在将所述第三需求项信息与所述第二需求项信息进行比对分析,得到第三分析结果之后,获取所述目标应用在生产阶段中的运行信息数据,对所述运行信息数据进行分析,得到目标数据信息,其中,所述目标数据信息中至少包括所述目标应用的潜在风险点信息和所述目标应用在生产阶段已发生的风险点信息;更新单元,用于依据目标数据信息对所述目标应用进行更新处理。
可选地,在本申请实施例提供的基于研发周期的风险评估装置中,所述装置还包括:第二判断单元,用于在获取所述目标应用的运行信息数据,对所述运行信息数据进行分析,得到目标数据信息之后,依据所述目标数据信息,判断所述设计标准库中的需求设计点是否需要更新,以及是否需要增加所述设计标准库中的需求设计点,得到判断结果;操作单元,用于依据所述判断结果,对所述设计标准库中的数据进行操作。
基于研发周期的风险评估装置包括处理器和存储器,上述的第一确定单元301,分析单元302,第一获取单元303和解析单元304等均作为程序单元存储在存储器中,由处理器执行存储在存储器中的上述程序单元来实现相应的功能。
处理器中包含内核,由内核去存储器中调取相应的程序单元。内核可以设置一个或以上,通过调整内核参数来实现对目标应用的风险评估。
存储器可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM),存储器包括至少一个存储芯片。
本发明实施例还提供了一种可选的基于研发周期的风险评估装置,如图4所示,主要涉及了10大模块,具体地:
设计标准库模块40:用于在设计时可以参考的一个设计标准库,架构师在做产品架构调整,以及完成业务需求时都需要参照该标准库进行设计产品,可以有效地避免由于经验不足的导致设计疏漏,包括分布式相关设计、性能调优、安全设计、临界资源、主机下平台等一系列设计领域。
设计基础信息模块41:用于获取当前版本目标应用涉及的设计内容,由于设计标准库的内容较多,并不是所有产品将设计标准库的设计点全部考虑,按需选择。为了避免线下传达存在遗漏,因此针对每月版本都让架构师根据当前需求设计的内容进行评估,将从设计标准库筛选的设计点同步到当前版本目标应用的设计档案中,由线下转为线上,便于数据流转,纳入到设计基础信息库中。
设计分析模块42:用于识别在设计阶段的设计点,结合需求项、需求条目、需求子条目的需求项内容,根据机器学习算法对拆分的任务中需求项内容的特征提取进行具体的分析,构建设计分析模型,该模型可以智能化的对拆分的任务信息进行不断训练,识别已纳入实现视野的设计点,纳入到设计信息库中,包括应用名、版本、需求项、需求条目、需求子条目、设计领域、设计点等信息。
设计风险信息模块43:用于识别在设计阶段存在设计遗留的风险信息,结合设计基础信息库和设计信息库的内容,两者进行匹配,如果在设计信息库中没有找到设计基础信息库中的内容,说明设计点有遗漏,纳入到设计风险信息库中,并驱动架构师完善设计点。
代码分析模块44:用于识别在编码阶段实现设计点的信息,在程序实现时,对完成设计的程序进行标识需求子条目编号,由于需求子条目是需求的最小粒度,在程序提交时,对其进行解析,纳入到代码信息库中,包含应用名、版本、设计领域、设计点、需求子条目、实现的代码等信息。
代码风险信息模块45:用于识别在编码阶段存在设计遗留的风险信息,结合设计信息库和代码信息库的内容,两者进行匹配,如果在代码信息库中没有找到在设计信息库中的内容,说明代码实现有遗漏,纳入到代码风险信息库中,并驱动开发人员实现。
案例分析模块46:用于识别在测试阶段设计点的测试案例信息,通过对自动化案例的日志继续解析,将测试案例相关信息纳入到案例信息库,包括应用名、版本、需求子条目、设计领域、设计点、案例描述、使用数据、预期结果等信息。
案例风险信息模块47:用于识别在测试阶段案例遗漏的风险信息,以设计基础信息库的验证点为基准,对其结果进行验证,如果两者匹配,说明设计实现验证通过,如果不匹配驱动开发人员完善,同时与设计信息库进行比对,如果在案例信息库中没有识别到相关内容,则说明案例有遗漏,纳入到案例风险信息库中,驱动测试人员补充完善。
生产运行模块48:用于识别在生产阶段设计点的运行情况,通过生产监控器对器进行监控,通过信息解析器对执行的日志进行解析,并记录到生产信息库中,包括应用名、设计领域、设计点、运行展现等信息
生产风险信息模块49:用于识别在生产阶段设计点的异常情况信息,通过风险识别器,对问题进行分析,包括设计基本信息、问题影响程度、异常展现、解决措施等,并自动更新现有的设计标准库,在后续的设计中避免出现此类问题。
以上叙述了在研发周期内自动识别架构设计风险的各个模块的功能,以及各模块之间联系,接下来详细说明各个模块的设计。
图5是设计标准库模块40的示意图,包括设计领域401、设计点402以及验证点403。具体地:
设计领域401:主要是企业所在产品中涉及的设计领域,用于改进和提高产品在市场中的稳定性,提高用户满意度。主要包含分布式设计、性能设计、安全设计、临界资源、应用入云、主机下平台、大数据领域、云计算等领域。
设计点402:根据设计领域401提炼出可能存在产品问题的技术点,针对分布式设计,主要在分布式服务、分布式缓存、分布式批量、分布式数据库、分布式消息等;针对性能设计领域,主要在架构调整、联机交易、批量交易、大数据批量等存在的性能问题;针对安全设计,在敏感数据、表结构变更、客户端使用、动态交易时等涉及到的安全数据问题;针对临界资源,主要在资源池、线程池、熔断机制、队列大小、资源监控等存在资源使用问题;针对应用入云,主要在负载均衡、容器起停、云上灰度、应用镜像、应用日志等涉及上云注意的风险点;针对主机下平台,主要在转型路径解耦、并行核对观察、应用数据切换、业务一致性保障等问题上的技术点。
验证点403:根据设计点402的设计点,提炼出在代码阶段和测试阶段能够验证该设计点正确与否的断言,使得在各阶段都要对应的验收措施。
图6是设计基础信息模块41的示意图,包含信息采集器411、信息解析器412、信息存储器413。具体地:
信息采集器411:从设计标准库中输出当前应用涉及到的设计需求点,通过信息采集器,实时的从数据源平台上获取信息采集时间和设计需求点,并对采集的信息进行分析。
信息解析器412:使用信息采集器411获取的当期应用版本的设计需求点,对信息进行解析,提炼出可以数字化的信息,包括应用名、版本、设计领域、设计需求点、验证点、架构师确认的时间等信息,作为当期应用版本的需求设计的基础信息。
信息存储器413:根据信息采集器412获取的信息,以及拆分的需求项、需求条目和需求子条目等按照信息类型保存在信息存储器中。
图7是设计分析模块42的示意图,包括分类打标签421、特征提取422、XGBoost算法建模423,具体地:
分类打标签421:从信息存储器413中随机选取20%的设计需求信息进行分类,并对这些设计信息进行做标签,判断拆分的需求项、需求条目和需求子条目描述是否是设计需求,如果是,将该设计需求描述置为0标签;如果不是,将该设计需求描述置为1标签。
特征提取422:对认为可能是设计需求的特征进行提取,包含高可用、可扩展、联机交易、批量交易、PaaS(Platform as a Service平台即服务)、SLB(Server Load Balance负载均衡)、解耦、升级改造、主机下平台、资源监控等,建立多维度的特征作为是设计需求的可能因素。
XGBoost算法建模423:根据特征提取422多维影响是设计需求的因素传入到XGBoost算法中,对这些特征不断的训练,最终训练出可以精确的判断出设计需求的模型,从而得到拆分时需要实现的设计需求信息,纳入到设计信息库中。
图8是设计风险信息模块43的示意图,包括设计风险识别器431、设计风险触发器432、推送设计风险信息433。具体地:
设计风险识别器431:用于识别实际有设计需求而在设计阶段没有的风险信息,根据信息存储器413的设计基础信息与423的设计信息进行比对,如果设计基础信息库的内容在设计信息库中没有找到,则说明设计需求点有遗漏,并记录下来设计风险信息库中。
设计风险触发器432:如果设计风险识别器431能够识别到有遗漏的情况,则触发报警器,将当期应用的设计风险信息推送给相关人员。
推送设计风险信息433:根据识别到设计风险,将对应的信息推送给架构师,进行完善设计信息库的内容,推送的信息包括应用名、版本、设计需求点、已纳入实现的设计点、未纳入实现的设计点、设计需求时间、架构师等相关信息。
图9是代码分析模块44的示意图,代码编写提交441、门禁442、信息解析器443。具体地:
代码编写提交441:开发人员根据设计信息库的设计点进行代码编写,在程序实现时,由于需求子条目是设计需求的最小粒度,对完成设计的程序进行标识需求子条目编号,便于后续解析,编码完成后,通过DevOps研发测试流水线进行自动部署提交。
门禁442:代码提交时,并不是所有的程序都能提交成功,所有代码经过门禁对程序问题进行检查,对代码进行完善,程序问题分为4种,包括SQL问题、代码问题、配置文件问题以及规范问题。其中SQL问题有执行计划、表容量、倾斜、语句不下推、大表未分区等,代码问题包含类重名等,配置文件问题包括写死IP、域名等,规范问题包括后缀、命名规范等。
信息解析器443:根据441提交的代码包对其解析,将解析得到相关的需求项信息纳入到代码信息库中,包含应用名、版本、设计领域、设计点、需求子条目、实现的代码等信息。
图10是代码风险信息模块45的示意图,包括代码风险识别器451、代码风险触发器452、推送代码风险信息453。具体地:
代码风险识别器451:用于识别有设计点而在代码阶段没有的风险信息,根据信息存储器413的设计信息与443的代码信息进行比对,如果设计信息的内容在代码信息库中没有找到,则说明代码实现有遗漏,并记录到代码风险信息库中。
代码风险触发器452:如果代码风险识别器451能够识别到有遗漏的情况,则触发报警器,将当期应用的代码风险信息推送给相关人员。
推送代码风险信息453:根据识别到的代码风险,将对应的信息推送给开发人员,进行完善代码信息库的内容,推送的信息包括应用名、版本、设计点、已实现的设计点、未实现的设计点、未实现的需求子条目、开发人员等相关信息。
图11是案例分析模块46的示意图,案例编写提交461、信息解析器462。具体地:
案例编写提交461:测试人员根据代码信息库的实现的功能点进行案例编写,由于需求子条目是也是案例编写的最小粒度,因此每个案例都应该标识是哪个需求子条目的案例,并编写具体的案例描述、数据准备、预期结果等信息,便于后续解析,同时编写对应的自动化脚本进行实施验证。
信息解析器462:用于识别在测试阶段设计点的测试案例信息,通过对自动化案例的日志继续解析,将测试案例相关信息纳入到案例信息库,包括应用名、版本、需求子条目、设计领域、设计点、案例描述、使用数据、预期结果等信息。
图12是案例风险信息模块47的示意图,包括案例风险识别器471、案例风险触发器472、推送案例风险信息473。具体地:
案例风险识别器471:用于有识别设计点而在测试阶段没有的风险信息,根据信息存储器413的代码信息与462的案例信息进行比对,如果编码实现的设计点在案例信息库中没有找到,则说明案例实现有遗漏,并记录到案例风险信息库中。
案例风险触发器472:如果案例风险识别器471能够识别到有遗漏的情况,则触发报警器,将当期应用的案例风险信息推送给相关人员。
推送代码风险信息473:如果识别到案例遗漏风险,将对应的信息推送给测试人员,进行补充相关的案例,推送的信息包括应用名、版本、设计点、已覆盖的案例、未覆盖的案例、未覆盖的需求子条目、测试人员等相关信息。以设计基础信息库的验证点为基准,对其结果进行验证,如果两者匹配,说明设计实现验证通过,如果不匹配驱动开发人员完善。
图13是生产运行模块48的示意图,包括生产监控器481、信息解析器482、信息存储器483。具体地:
生产监控器481:通过生产监控器监控产品投产的实际运行情况,包括产品响应时间、资源情况、是否有批量中断、语句的执行计划、统计信息等。
信息解析器482:针对生产监控器481监控的信息,解析出对设计点完善有价值的信息。针对批量交易,记录交易起始时间、是否中断、资源使用情况、语句的执行计划、统计信息等;对于联机交易,记录响应时间、是否有报错、资源是否溢出等;针对临界资源情况,记录线程池和连接池的上下资源使用情况、队列大小等;针对应用入云的情况,记录应用容器数量、容器资源情况、负载均衡等生产运行情况。
信息存储器483:将信息解析器482解析的生产数据,保存到信息存储器中,记录到生产信息库中。
图14是生产风险信息模块49的示意图,包括风险识别器491和信息对比器492。具体地:
风险识别器491:对于生产存在的潜在风险或者已经发生的问题,根据信息存储器483记录的内容,识别出设计基本信息,包括设计领域、设计点等,问题影响程度,包括高、中、低以及问题表现,解决的措施等,记录到生产风险信息库中。
信息比对器492:根据生产风险信息库中的内容与现有的设计标准库进行比对,如果设计标准库中没有,则自动更,在后续的设计中避免出现此类问题,形成设计的闭环工作。
综上所述,本发明是一种在研发周期中自动识别架构设计风险的方法,自动化高、减少人力成本,并已落地到实际的应用中,打通了研发阶段的连通性,提高了风险识别的灵活性、可靠性、价值性,降低了定位问题周期和出现生产问题的概率提高了自动化。
本发明实施例提供了一种处理器,处理器用于运行程序,其中,程序运行时执行基于研发周期的风险评估方法。
如图15所示,本发明实施例提供了一种电子设备,设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序,处理器执行程序时实现以下步骤:基于目标应用的功能需求,确定目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,第一需求项信息表征实现需求设计点的需求;将预测设计点和需求设计点进行比对分析,得到第一分析结果,其中,第一分析结果用于确定目标应用的设计阶段是否存在风险点;获取目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并第二需求项信息和需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定目标应用的编码阶段是否存在风险点,其中,代码包依据需求设计点得到;获取目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将第三需求项信息与第二需求项信息进行比对分析,得到第三分析结果,其中,第三分析结果用于确定目标应用的测试阶段是否存在风险点。
可选地,基于目标应用的功能需求,确定目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息包括:获取设计标准库,其中,设计标准库中至少包括多个应用信息和每个应用信息对应的需求设计点;基于目标应用的功能需求,从设计标准库中确定目标应用对应的多个需求设计点;对每个需求设计点进行功能需求拆分,以得到每个需求设计点对应的第一需求项信息。
可选地,获取设计标准库包括:确定多个应用以及每个应用对应的技术领域;依据每个应用对应的技术领域,确定每个应用的需求设计点;基于每个应用的需求设计点,确定每个需求设计点的判断标准,其中,判断标准用于在编码阶段和测试阶段判断每个需求设计点对应的功能是否被实现的标准;基于多个应用、需求设计点和判断标准,获取设计标准库。
可选地,在将预测设计点和需求设计点进行比对分析,得到第一分析结果之后,该方法还包括:若第一分析结果表征预测设计点与需求设计点一一对应,则确定目标应用的设计阶段不存在风险点;若第一分析结果表征预测设计点与需求设计点不是一一对应,则确定目标应用的设计阶段存在风险点,将风险点对应的风险信息发送至目标对象,以对风险点进行处理。
可选地,在对每个代码包进行解析,得到每个代码包对应的第二需求项信息之前,该方法还包括:依据预设检查规则对每个代码包的形式进行检测,以确定每个代码包是否满足预设要求。
可选地,在将第二需求项信息和需求设计点进行比对分析,得到第二分析结果之后,该方法还包括:若第二分析结果表征第二需求项信息与需求设计点一一对应,则依据设计标准库中需求设计点的判断标准,判断第二需求项信息对应的代码包是否实现需求设计点对应的功能;若第二需求项信息对应的代码包已实现需求设计点对应的功能,则目标应用的编码阶段不存在风险点。
可选地,在判断第二需求项信息是否与需求设计点一一对应之后,该方法还包括:若第二分析结果表征第二需求项信息与需求设计点不是一一对应,或者第二需求项信息对应的代码包未实现需求设计点对应的功能,则目标应用的编码阶段存在风险点。
可选地,在将第三需求项信息与第二需求项信息进行比对分析,得到第三分析结果之后,该方法还包括:获取目标应用在生产阶段中的运行信息数据,对运行信息数据进行分析,得到目标数据信息,其中,目标数据信息中至少包括目标应用的潜在风险点信息和目标应用在生产阶段已发生的风险点信息;依据目标数据信息对目标应用进行更新处理。
可选地,在获取目标应用的运行信息数据,对运行信息数据进行分析,得到目标数据信息之后,方法还包括:依据目标数据信息,判断设计标准库中的需求设计点是否需要更新,以及是否需要增加设计标准库中的需求设计点,得到判断结果;依据判断结果,对设计标准库中的数据进行操作。
本文中的设备可以是服务器、PC、PAD、手机等。
本申请还提供了一种计算机程序产品,当在数据处理设备上执行时,适于执行初始化有如下方法步骤的程序:基于目标应用的功能需求,确定目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,第一需求项信息表征实现需求设计点的需求;将预测设计点和需求设计点进行比对分析,得到第一分析结果,其中,第一分析结果用于确定目标应用的设计阶段是否存在风险点;获取目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并第二需求项信息和需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定目标应用的编码阶段是否存在风险点,其中,代码包依据需求设计点得到;获取目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将第三需求项信息与第二需求项信息进行比对分析,得到第三分析结果,其中,第三分析结果用于确定目标应用的测试阶段是否存在风险点。
可选地,基于目标应用的功能需求,确定目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息包括:获取设计标准库,其中,设计标准库中至少包括多个应用信息和每个应用信息对应的需求设计点;基于目标应用的功能需求,从设计标准库中确定目标应用对应的多个需求设计点;对每个需求设计点进行功能需求拆分,以得到每个需求设计点对应的第一需求项信息。
可选地,获取设计标准库包括:确定多个应用以及每个应用对应的技术领域;依据每个应用对应的技术领域,确定每个应用的需求设计点;基于每个应用的需求设计点,确定每个需求设计点的判断标准,其中,判断标准用于在编码阶段和测试阶段判断每个需求设计点对应的功能是否被实现的标准;基于多个应用、需求设计点和判断标准,获取设计标准库。
可选地,在将预测设计点和需求设计点进行比对分析,得到第一分析结果之后,该方法还包括:若第一分析结果表征预测设计点与需求设计点一一对应,则确定目标应用的设计阶段不存在风险点;若第一分析结果表征预测设计点与需求设计点不是一一对应,则确定目标应用的设计阶段存在风险点,将风险点对应的风险信息发送至目标对象,以对风险点进行处理。
可选地,在对每个代码包进行解析,得到每个代码包对应的第二需求项信息之前,方法还包括:依据预设检查规则对每个代码包的形式进行检测,以确定每个代码包是否满足预设要求。
可选地,在将第二需求项信息和需求设计点进行比对分析,得到第二分析结果之后,该方法包括:若第二分析结果表征第二需求项信息与需求设计点一一对应,则依据设计标准库中需求设计点的判断标准,判断第二需求项信息对应的代码包是否实现需求设计点对应的功能;若第二需求项信息对应的代码包已实现需求设计点对应的功能,则目标应用的编码阶段不存在风险点。
可选地,在判断第二需求项信息是否与需求设计点一一对应之后,该方法还包括:若第二分析结果表征第二需求项信息与需求设计点不是一一对应,或者第二需求项信息对应的代码包未实现需求设计点对应的功能,则目标应用的编码阶段存在风险点。
可选地,在将第三需求项信息与第二需求项信息进行比对分析,得到第三分析结果,其中,第三分析结果用于确定目标应用的测试阶段是否存在风险点之后,该方法还包括:获取目标应用在生产阶段中的运行信息数据,对运行信息数据进行分析,得到目标数据信息,其中,目标数据信息中至少包括目标应用的潜在风险点信息和目标应用在生产阶段已发生的风险点信息;依据目标数据信息对目标应用进行更新处理。
可选地,在获取目标应用的运行信息数据,对运行信息数据进行分析,得到目标数据信息之后,该方法还包括:依据目标数据信息,判断设计标准库中的需求设计点是否需要更新,以及是否需要增加设计标准库中的需求设计点,得到判断结果;依据判断结果,对设计标准库中的数据进行操作。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
存储器可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。
Claims (12)
1.一种基于研发周期的风险评估方法,其特征在于,包括:
基于目标应用的功能需求,确定所述目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对所述第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,所述第一需求项信息表征实现所述需求设计点的需求;
将所述预测设计点和所述需求设计点进行比对分析,得到第一分析结果,其中,所述第一分析结果用于确定所述目标应用的设计阶段是否存在风险点;
获取所述目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并将所述第二需求项信息和所述需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定所述目标应用的编码阶段是否存在风险点,所述代码包依据所述需求设计点得到;
获取所述目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将所述第三需求项信息与所述第二需求项信息进行比对分析,得到第三分析结果,其中,所述第三分析结果用于确定所述目标应用的测试阶段是否存在风险点。
2.根据权利要求1所述的方法,其特征在于,基于目标应用的功能需求,确定所述目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息包括:
获取设计标准库,其中,所述设计标准库中至少包括多个应用信息和每个应用信息对应的需求设计点;
基于目标应用的功能需求,从所述设计标准库中确定所述目标应用对应的多个需求设计点;
对每个需求设计点进行功能需求拆分,以得到每个需求设计点对应的第一需求项信息。
3.根据权利要求2所述的方法,其特征在于,获取设计标准库包括:
确定多个应用以及每个应用对应的技术领域;
依据每个应用对应的技术领域,确定每个应用的需求设计点;
基于每个应用的需求设计点,确定每个需求设计点的判断标准,其中,所述判断标准用于在所述编码阶段和所述测试阶段判断每个需求设计点对应的功能是否被实现的标准;
基于所述多个应用、所述需求设计点和所述判断标准,获取所述设计标准库。
4.根据权利要求1所述的方法,其特征在于,在将所述预测设计点和所述需求设计点进行比对分析,得到第一分析结果之后,所述方法还包括:
若所述第一分析结果表征所述预测设计点与所述需求设计点一一对应,则确定所述目标应用的设计阶段不存在风险点;
若所述第一分析结果表征所述预测设计点与所述需求设计点不是一一对应,则确定所述目标应用的设计阶段存在风险点,将所述风险点对应的风险信息发送至目标对象,以对所述风险点进行处理。
5.根据权利要求1所述的方法,其特征在于,在对每个代码包进行解析,得到每个代码包对应的第二需求项信息之前,所述方法还包括:
依据预设检查规则对每个代码包的形式进行检测,以确定每个代码包是否满足预设要求。
6.根据权利要求3所述的方法,其特征在于,在将所述第二需求项信息和所述需求设计点进行比对分析,得到第二分析结果之后,所述方法还包括:
若所述第二分析结果表征所述第二需求项信息与所述需求设计点一一对应,则依据所述设计标准库中需求设计点的判断标准,判断所述第二需求项信息对应的代码包是否实现所述需求设计点对应的功能;
若所述第二需求项信息对应的代码包已实现所述需求设计点对应的功能,则所述目标应用的编码阶段不存在风险点。
7.根据权利要求6所述的方法,其特征在于,在判断所述第二需求项信息是否与所述需求设计点一一对应之后,所述方法还包括:
若所述第二分析结果表征所述第二需求项信息与所述需求设计点不是一一对应,或者所述第二需求项信息对应的代码包未实现所述需求设计点对应的功能,则所述目标应用的编码阶段存在风险点。
8.根据权利要求3所述的方法,其特征在于,在将所述第三需求项信息与所述第二需求项信息进行比对分析,得到第三分析结果之后,所述方法还包括:
获取所述目标应用在生产阶段中的运行信息数据,对所述运行信息数据进行分析,得到目标数据信息,其中,所述目标数据信息中至少包括所述目标应用的潜在风险点信息和所述目标应用在生产阶段已发生的风险点信息;
依据目标数据信息对所述目标应用进行更新处理。
9.根据权利要求8所述的方法,其特征在于,在获取所述目标应用的运行信息数据,对所述运行信息数据进行分析,得到目标数据信息之后,所述方法还包括:
依据所述目标数据信息,判断所述设计标准库中的需求设计点是否需要更新,以及是否需要增加所述设计标准库中的需求设计点,得到判断结果;
依据所述判断结果,对所述设计标准库中的数据进行操作。
10.一种基于研发周期的风险评估装置,其特征在于,包括:
第一确定单元,用于基于目标应用的功能需求,确定所述目标应用的多个需求设计点和每个需求设计点对应的第一需求项信息,并通过目标神经网络模型对所述第一需求项信息进行特征识别,得到每个第一需求项信息对应的预测设计点,其中,所述第一需求项信息表征实现所述需求设计点的需求;
分析单元,用于将所述预测设计点和所述需求设计点进行比对分析,得到第一分析结果,其中,所述第一分析结果用于确定所述目标应用的设计阶段是否存在风险点;
第一获取单元,用于获取所述目标应用的代码包,对每个代码包进行解析,得到每个代码包对应的第二需求项信息,并将所述第二需求项信息和所述需求设计点进行比对分析,得到第二分析结果,其中,所述第二分析结果用于确定所述目标应用的编码阶段是否存在风险点,所述代码包依据所述需求设计点得到;
解析单元,用于获取所述目标应用的测试案例对应的测试日志,对每个测试日志进行解析,得到每个测试日志对应的第三需求项信息,并将所述第三需求项信息与所述第二需求项信息进行比对分析,得到第三分析结果,其中,所述第三分析结果用于确定所述目标应用的测试阶段是否存在风险点。
11.一种处理器,其特征在于,所述处理器用于运行程序,其中,所述程序运行时执行权利要求1至9中任意一项所述的基于研发周期的风险评估方法。
12.一种电子设备,其特征在于,包括一个或多个处理器和存储器,所述存储器用于存储一个或多个程序,其中,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现权利要求1至9中任意一项所述的基于研发周期的风险评估方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211426972.8A CN115756393A (zh) | 2022-11-15 | 2022-11-15 | 基于研发周期的风险评估方法和装置、处理器及电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211426972.8A CN115756393A (zh) | 2022-11-15 | 2022-11-15 | 基于研发周期的风险评估方法和装置、处理器及电子设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115756393A true CN115756393A (zh) | 2023-03-07 |
Family
ID=85371153
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211426972.8A Pending CN115756393A (zh) | 2022-11-15 | 2022-11-15 | 基于研发周期的风险评估方法和装置、处理器及电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115756393A (zh) |
-
2022
- 2022-11-15 CN CN202211426972.8A patent/CN115756393A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11099237B2 (en) | Test prioritization and dynamic test case sequencing | |
US10960541B2 (en) | Analytical robotic process automation | |
US20210279164A1 (en) | Real Time Application Error Identification and Mitigation | |
CN111240994B (zh) | 漏洞处理方法、装置、电子设备及可读存储介质 | |
US8954930B2 (en) | System and method for reducing test effort by object risk analysis | |
US20150347212A1 (en) | Error classification in a computing system | |
US10579357B2 (en) | Cognitive expected program code installation result assessment | |
CN108897686B (zh) | 全分录自动化测试方法和装置 | |
US20210157716A1 (en) | Pre-populating continuous delivery test cases | |
CN112241360A (zh) | 一种测试用例生成方法、装置、设备及存储介质 | |
CN112035363A (zh) | 接口自动化测试方法及装置 | |
CN110188036A (zh) | 一种软件测试方法及装置 | |
CN108074033A (zh) | 指标数据的处理方法、系统、电子设备和存储介质 | |
CN111654495B (zh) | 用于确定流量产生来源的方法、装置、设备及存储介质 | |
CN111240981A (zh) | 一种接口测试方法、系统及平台 | |
CN114490413A (zh) | 测试数据的准备方法及装置、存储介质和电子设备 | |
CN112433933A (zh) | 一种接口自动化测试的方法及设备 | |
CN115756393A (zh) | 基于研发周期的风险评估方法和装置、处理器及电子设备 | |
CN116932360A (zh) | 一种页面测试方法、装置、计算机设备和存储介质 | |
CN113934595A (zh) | 数据分析方法及系统、存储介质及电子终端 | |
CN112604295A (zh) | 游戏更新失败的上报方法、装置及管理方法、服务器 | |
CN113448822A (zh) | 测试方法、装置、计算机可读介质及电子设备 | |
CN112631930B (zh) | 动态系统测试方法及相关装置 | |
CN114840177A (zh) | 软件产品的验收方法、装置以及电子设备 | |
CN116954975A (zh) | 软件产品的故障处理方法、系统、装置以及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |