CN114840177A - 软件产品的验收方法、装置以及电子设备 - Google Patents

Abstract

本申请公开了一种软件产品的验收方法、装置以及电子设备。涉及金融科技领域，该方法包括：获取预先存储于核心需求信息库中的核心业务需求信息，其中，上述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的；采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例；对上述测试案例进行评审处理，得到评审结果；根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器。通过本申请，解决了相关技术中基于人工参与的软件产品的生命周期管理方法存在的产品验收效率低、周期长且无法保证产品质量的问题。

Description

软件产品的验收方法、装置以及电子设备

技术领域

本申请涉及金融科技领域，具体而言，涉及一种软件产品的验收方法、装置以及电子设备。

背景技术

随着市场运营的不断变化，软件产品体验的声音越来越备受关注，为了能够快速地跟进市场的步伐，软件产品的需求会根据用户的要求不断的调整，而软件产品验收作为研发过程中一项必不可少的工程也越来越受到重视。

现有技术中软件产品的验收方法，比如人为参与的需求分析、验收案例编写、验收案例执行、问题定位等方法，验收周期长、效率低下，且不能灵活的覆盖市场上业务需要的核心场景，难以满足研发周期较短的场景下软件产品的高质量快速交付，软件产品验收效率较低，难以有效保障软件产品质量。

针对相关技术中基于人工参与的软件产品的生命周期管理方法存在的产品验收效率低、周期长且无法保证产品质量的问题，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种软件产品的验收方法、装置以及电子设备，以解决相关技术中基于人工参与的软件产品的生命周期管理方法存在的产品验收效率低、周期长且无法保证产品质量的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种软件产品的验收方法。该方法包括：获取预先存储于核心需求信息库中的核心业务需求信息，其中，上述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的；采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例；对上述测试案例进行评审处理，得到评审结果；根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器。

为了实现上述目的，根据本申请的另一方面，提供了一种软件产品的验收装置。该装置包括：获取单元，用于获取预先存储于核心需求信息库中的核心业务需求信息，其中，上述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的；转化单元，用于采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例；评审单元，用于对上述测试案例进行评审处理，得到评审结果；交付单元，用于根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器。

为了实现上述目的，根据本申请的另一方面，提供了一种处理器。上述处理器用于运行程序，其中，上述程序运行时执行任意一项上述的软件产品的验收方法。

为了实现上述目的，根据本申请的另一方面，提供了一种电子设备。该电子设备包括：包括一个或多个处理器和存储器，上述存储器用于存储一个或多个程序，其中，当上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个或多个处理器实现任意一项上述的软件产品的验收方法。

通过本申请，采用以下步骤：获取预先存储于核心需求信息库中的核心业务需求信息，其中，上述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的；采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例；对上述测试案例进行评审处理，得到评审结果；根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器，达到了采用自动化管理方式对软件产品的生命周期进行管理的目的，解决了相关技术中基于人工参与的软件产品的生命周期管理方法存在的产品验收效率低、周期长且无法保证产品质量的问题。进而达到了缩短软件产品的验收周期，提升软件产品的生命周期管理效率，有效保证软件产品开发质量的效果。

附图说明

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

图1是根据本申请实施例提供的软件产品的验收方法的流程图；

图2是根据本申请实施例的一种可选的软件产品的验收方法的流程图；

图3是根据本申请实施例的一种可选的产品验收框架模块示意图；

图4是根据本申请实施例的一种可选的验收案例执行模块示意图；

图5是根据本申请实施例的一种可选的问题诊断模块示意图；

图6是根据本申请实施例的一种可选的自动交付模块示意图；

图7是根据本申请实施例的一种可选的报告生成模块示意图；

图8是根据本申请实施例的一种可选的信息同步模块示意图；

图9是根据本申请实施例的一种可选的核心需求识别模块示意图；

图10是根据本申请实施例的一种可选的验收标准模块示意图；

图11是根据本申请实施例的一种可选的验收案例生成模块示意图；

图12是根据本申请实施例的一种可选的验收案例评审模块示意图；

图13是根据本申请实施例的一种可选的数据同步模块示意图；

图14是根据本申请实施例的一种可选的产品验收测试框架的示意图；

图15是根据本申请实施例的软件产品的验收装置的示意图；

图16是用于实施本申请实施例中软件产品的验收方法的电子设备示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

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

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

需要说明的是，本申请所涉及的相关信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于展示的数据、分析的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。例如，本系统和相关用户或机构间设置有接口，在获取相关信息之前，需要通过接口向前述的用户或机构发送获取请求，并在接收到前述的用户或机构反馈的同意信息后，获取相关信息。

随着市场运营的不断变化，软件产品体验的声音越来越备受关注，为了能够快速地跟进市场的步伐，软件产品的需求会根据用户的要求不断的调整，而软件产品验收作为研发过程中一项必不可少的工程也越来越受到重视。随着“以用户为中心”、“缩短需求项研发测试周期”为目标的软件产品研发模式的推进，对于软件产品验收效率和质量提出了更高的要求。为了更好的满足用户的需求，需要不断的缩短研发周期并快速的对软件产品进行验收，提高用户满意度。

目前有通过检测模块和判断模块等技术实现的软件产品验收系统和验收测试方法，即在前一个子模块运作完成并且前一个子模块的检测结果正常的情况下，下一个子模块进行运作以对软件产品检测，在任一子模块的检测结果不正常的情况下，判断模块决定软件产品扣留。该系统类似于瀑布模型，一定程度上避免人工检测的费时费力，主要针对软件产品结果后期进行验证。但是软件产品验收最终要保证的业务需求-程序设计-编码实现的一致性，基于Devops研发测试流水线，需要在前中后期均要介入软件产品验收，避免程序设计频繁返工，需求沟通等一系列问题，在敏捷迭代的情况下，需要尽快识别出更接近市场的核心需求，并在研发过程中快速验证并及时定位问题，提高软件产品验收效率。

现有技术中软件产品的验收方法，比如人为参与的需求分析、验收案例编写、验收案例执行、问题定位等方法，验收周期长、效率低下，且不能灵活的覆盖市场上业务需要的核心场景，难以满足研发周期较短的场景下软件产品的高质量快速交付，软件产品验收效率较低，难以有效保障软件产品质量。

基于上述问题，本发明实施例提供了一种软件产品的验收方法，图1是根据本申请实施例提供的软件产品的验收方法的流程图，如图1所示，该方法包括如下步骤：

步骤S12，获取预先存储于核心需求信息库中的核心业务需求信息；

步骤S14，采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例；

步骤S16，对上述测试案例进行评审处理，得到评审结果；

步骤S18，根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器。

可选的，上述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的。例如，采用规则匹配方法和机器学习算法(如XGBoost算法)对上述初始业务需求信息进行筛选训练，得到上述核心业务需求信息。

可选的，通过对上述核心业务需求信息进行解析处理得到验收标准信息，采用用户故事方式将上述验收标准信息转化为测试案例，并将上述测试案例纳入到案例库，其中，上述测试案例至少包括：需求条件、触发条件、预期结果。

可选的，若上述评审结果指示上述测试案例评审通过，则执行上述测试案例；若执行结果指示上述测试案例执行通过，则将上述测试案例自动交付至目标服务器。

本申请实施例提供的软件产品的验收方法，通过获取预先存储于核心需求信息库中的核心业务需求信息，其中，上述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的；采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例；对上述测试案例进行评审处理，得到评审结果；根据上述评审结果确定是否将上述测试案例进行自动交付，即根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器，解决了相关技术中基于人工参与的软件产品的生命周期管理方法存在的产品验收效率低、周期长且无法保证产品质量的问题。进而达到了缩短软件产品的验收周期，提升软件产品的生命周期管理效率，有效保证软件产品开发质量的效果。

作为一种可选的实施例，图2是根据本申请实施例的一种可选的软件产品的验收方法的流程图，如图2所示，该方法包括：

步骤S21，从数据源平台获取初始业务需求信息和生产运营指标信息纳入到信息库；

步骤S22，通过规则匹配和学习算法进行训练，结合生产运营指标信息，筛选核心需求信息；

步骤S23，根据核心需求编写得到验收标准信息，将上述验收标准信息采用用户故事方式转化成案例，逐步纳入验收测试案例信息库；

步骤S24，案例在线评审通过后，自动获取数据，对评审通过的测试案例自动触发自动化脚本进行验证，对有问题的案例自动分析；

步骤S25，验收案例纳入到Devops体系中，对于执行通过的测试案例自动交付至目标服务器，并自动生成验收测试报告。

在一种可选的实施例中，上述根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器，包括：

若上述评审结果指示上述测试案例评审通过，则执行上述测试案例；

若执行结果指示上述测试案例执行通过，则将上述测试案例自动交付至上述目标服务器。

可选的，若执行结果指示上述测试案例执行通过，则将上述测试案例纳入到过程-方法-系统Devops体系进行自动交付，并生成上述待测软件产品对应的测试报告，其中，上述测试报告中至少包括上述测试案例的详细信息、各类型案例的占比信息、执行成功率、红线检查等信息。

可选的，若执行结果指示验收案例失败，则触发报警器，通知相关人员，同时对失败的测试案例进行分析。

可选的，在将上述测试案例纳入案例库之后进入在线评审阶段，对评审通过的测试案例进行打标签，并从生产运维系统中获取测试数据，采用自动化测试框架对评审通过的测试案例进行验证。例如，在将上述测试案例纳入案例库之后采用自动触发方式对上述测试案例进行在线评审，针对已评审通过的案例进行打标签并纳入结果信息库，根据血缘分析工具对源表信息，自动的从数据源平台同步数据到测试环境，然后执行上述测试案例对应的案例脚本，对于有问题的案例进行自动分析，以达到驱动完善代码的目的。

可选的，如图3所示，若上述评审结果指示上述测试案例评审通过，则通过验收案例执行模块7执行上述测试案例，首先将上述测试案例纳入到自动化验收Cucumber工具框架中，并部署到持续集成上自动验证，自动触发案例执行器，根据案例中的断言对需求代码进行执行验证，若执行结果指示验收案例通过，则将执行结果纳入到结果存储器中，若执行结果指示验收案例失败，则触发报警器，通知相关人员，同时对执行失败的测试案例进行分析。

可选的，如图4所示，上述验收案例执行模块7包括案例执行器701、断言702。具体地：上述案例执行器701采用的自动化测试框架Cucumber工具实现案例自动化执行。该工具是一个能够用自然语言描述测试用例的行为驱动开发的自动化测试工具，可以支持多种开发语言，充当作为业务与技术之间桥梁的角色，实现端到端的测试框架，由于简单的测试脚本架构，Cucumber提供了代码可重用性。该工具有三个重要部分组成：Feature(功能)、Step-definitions(步骤定义)和Cucumber comman(对象声明)。其中，Feature：用于描述测试功能、测试场景、测试步骤和测试结果的工具，包含Given、When、Then关键步骤。根据验收案例模块4中的需求条件Given401、触发条件When402、预期结果Then403转化到Feature文件中，形成可被代码理解的自然语言，有助于Cucumber工具解释和执行测试脚本。Step-definitions：根据Feature中文件中定义的步骤编写对应的测试代码，Step定义必须以关键字Given、When、Then等开始，用于实现验收案例模块4中的需求条件Given401、触发条件When402、预期结果Then403具体的测试代码，可视化的实现需求到代码之间的对应关系，使得每个需求都有对应的代码支撑，实现需求透明化、清晰化。Cucumber comman：运行Feature文件，Cucumber会分析Feature文件中定义的步骤Step(Given、When、Then)，然后去Step-definitions寻找以Given、When、Then开始相匹配的Step，执行Step中对应的代码。运行结果以HTML的形式保存，失败的案例将保存到对应的日志，便于对问题进行分析。上述断言702用于在案例正在执行的过程中根据设置的断言作为案例是否成功的标志，如果案例执行成功，将对应的案例纳入结果存储器中，并打上成功的标签，如果案例执行失败，将触发报警器，对日志进行解析，分析问题，将结果推送给相关人员，实现验收测试驱动完善过程。

可选的，仍如图3所示，通过问题诊断模块8对案例执行失败情况进行问题分析，当案例失败时会触发问题识别器，对问题通过专家规则进行分析。问题可分为两大类，一是需求问题，包括需求未实现和需求实现有误；二是程序问题，包括SQL语句问题，代码问题，配置文件问题，规范问题等，将分析的问题记录到问题信息库，同时反馈给相关人员进行修改。

可选的，如图5所示，上述问题诊断模块8包括问题诊断器801、需求问题802、程序问题803。具体地：上述问题诊断器801用于当执行验收案例断言702时，返回结果和事先设置的预期断言不一致的情况下，说明验收案例执行失败，此时会触发问题诊断器，对案例日志进行分析，识别的问题分为两种，一是需求问题，二是程序问题。上述需求问题802分为2种，一是需求未实现，二是需求实现有误。如果验收案例抛出验收案例未定义异常，则说明需求未实现，需要补充需求对应的代码；如果报错是由于和事先设置的断言不一致的情况，则说明需求识别有误，需要重新优化。上述程序问题803分为4种，包括SQL问题、代码问题、配置文件问题以及规范问题。其中SQL问题有执行计划、表容量、倾斜、语句不下推、大表未分区等，代码问题包含类重名等，配置文件问题包括写死IP、域名等，规范问题包括后缀、命名规范等。

可选的，仍如图3所示，通过自动交付模块9对直行通过的测试案例进行自动交付，将测试案例纳入到Devops体系的交付门禁，若案例执行通过后，则将该问题进行直接交付，若案例执行失败后，则拒绝交付，并触发问题识别器对问题进行解析。

可选的，如图6所示，上述自动交付模块9包括交付门禁901、需求调优器、自动交付。其中交付门禁901由于验收测试整个会纳入到Devops体系中实现自动交付模式，包括提交流水线和交付流水线。提交流水线会判断提交的代码是否有问题，若有问题则会触发问题识别器801，对问题进行完善，交付流水线会判断提交的案例是否全部通过，若全部通过，则自动进行交付。

可选的，仍如图3所示，在执行结果指示上述测试案例执行通过并完成自动交付后，通过报告生成模块10生成验收测试报告，其中，上述验收测试报告中包括需求基本信息、案例信息、红线检查信息、执行人、问题发现数等信息，并对整个验收测试给出整体结论，即测试通过还是不通过的相关信息。

可选的，如图7所示，上述报告生成模块10包括报告生成工具1001、需求基本信息1002、案例信息1003、红线检查信息1004。具体地：上述报告生成工具1001用于当验收案例自动交付之后，则会自动触发报告生成工具，对当前提交的验收案例生成可视化报告，主要包含需求基本信息、案例信息和红线检查信息，较少人工编写成本，方便报告进行归档，并将结果推送给相关人员上述需求基本信息1002；主要体现验收标准的Who-What-Value中的具体需求信息，便于掌握验收标准-验收案例-验收脚本的一致性；上述案例信息1003主要体现的是Feature文件中Given-When-Then关键案例信息，并将具体采用的哪些数据作为测试数据进行可视化，同时展现出案例个数、占比、成功率以及案例执行后的验收状态，通过还是不通过，并用不同颜色标注出用于区分；上述红线检查信息1004主要用于保证需求在生产上的运维应急信息，包括可用性监控检查、应急预案检查以及新老系统并行情况检查等。

在一种可选的实施例中，上述获取预先存储于核心需求信息库中的核心业务需求信息，包括：

获取上述初始业务需求信息和上述待测软件产品对应的生产运营指标信息；

对上述初始业务需求信息进行分类处理，得到分类后的需求信息；

基于上述生产运营指标信息和上述分类后的需求信息，确定模型训练特征；

基于上述模型训练特征，采用机器学习算法训练得到上述核心业务需求信息。

可选的，采用规则匹配方法对上述初始业务需求信息进行分类处理，得到分类后的需求信息。

可选的，从生产运维数据源平台获取得到上述初始业务需求信息和上述生产运营指标信息，并将上述初始业务需求信息和上述生产运营指标信息纳入到需求信息库。

可选的，上述生产运营指标信息至少包括指标访问量、用户活跃量、生产问题数、用户满意度。

可选的，采用规则匹配方法和机器学习算法XGBoost算法对上述初始业务需求信息进行筛选训练，得到上述核心业务需求信息，例如，首先对上述初始业务需求信息进行分类处理，得到分类后的需求信息，结合上述生产运营指标信息，采用机器学习算法(如XGBoost算法)进行建模，筛选出用户活跃度高、访问量高、生产问题数少、用户满意度高等多维一体的上述核心业务需求信息，并将上述核心业务需求信息纳入到核心信息库，以达到自动维护核心需求信息的目的。

可以理解，上述生产运营指标信息为基于产品层面实时获取到的；上述初始业务需求信息为预先存储于业务需求库中的需求信息，在确定上述核心业务需求信息时，综合产品层面的生产运营指标信息和业务需求库中的初始业务需求信息分析得到模型训练特征，基于上述模型训练特征，采用机器学习算法训练得到上述核心业务需求信息。由此获取到的核心业务需求信息综合考虑产品实际应用层面和业务需求层面，更加贴近用户的实际需求。

可选的，仍如图3所示，通过信息同步模块1获取上述初始业务需求信息和上述生产运营指标信息，用户可以根据前台页面方式录入上述初始业务需求信息，生产运维会提供后台查询逻辑，实时地将上述初始业务需求信息纳入到生产运维信息表，通过Devops体系配置持续集成任务，准实时地从运维平台后台表中获取上述初始业务生产需求信息；同时提供一个信息采集的接口，定时传送上述生产运营指标信息，包括指标访问量、用户活跃量、生产问题数、用户满意度等，对指标信息准实时进行获取，最终将需求信息和产品运营信息纳入到信息库。

可选的，如图8所示，上述信息同步模块1包括信息采集器101、信息解析器102和信息存储器103。其中，上述信息采集器101用于生产运维，即数据源平台会输出当前生产上对各个产品提出的初始业务需求信息和产品运营指标信息。上述初始业务需求信息可以从源平台数据库获取，产品运营指标信息可以通过信息采集接口获取，通过信息采集器，包括信息的采集时间和数量，通过可以调整配置参数，如果设置定时参数，每天进行从生产上获取一定数据量的信息，也可以根据实际情况，不定时的获取信息；上述信息解析器102用于使用信息采集器101获取初始业务需求信息和产品运营指标信息，采用信息解析器对初始业务需求信息进行解析，提炼出可以数字化的信息。初始业务需求信息可以解析出应用名、子系统、系统模块、需求类型、需求属性、需求模块、需求描述等信息，其中需求类型包括功能、性能、安全、异用性、稳定性等，需求属性包含新增、优化，需求模块包括移动端、PC端等。产品运营指标信息可以解析出产品各个功能在生产上运营的访问量、用活跃度、用户满意度、生产问题数等信息；上述信息存储器103用于根据信息解析器102获取的信息，按照信息类型保存在信息存储器中。

可选的，仍如图3所示，通过核心需求识别模块2获取上述核心业务需求信息，结合上述生产运营指标信息，根据规则匹配和机器学习算法对需求的特征提取进行具体的分析，构建需求分析识别模型，该模型可以智能化的对需求信息进行不断的训练，识别出优先级比较高的核心业务需求信息，纳入到核心需求信息库中。

可选的，如图9所示，上述核心需求识别模块2包括分类打标签201、特征提取202、XGBoost算法建模203，具体地：上述分类打标签201用于从信息存储器103中随机选取20％的需求信息进行分类，对这些初始业务需求信息进行做标签，可以从各个维度需求进行判断，比如功能、性能、安全、易用性、稳定性、高可用、可扩展、监控措施等，判断初始业务需求是否是核心业务需求信息，如果是，将该初始业务需求信息置为0标签；如果不是，将该初始业务需求信息置为1标签。

上述特征提取202用于对认为可能是核心业务需求信息的特征进行提取，包含用户活跃度2021、访问量2022、价值输出度2023、用户画像2024、生产问题数2025、用户满意度2026，建立六项维度的特征作为影响核心需求的可能因素；上述用户活跃度2021用于根据信息存储器103中解析的产品运营指标信息，对于产品的各个在线功能的用户活跃度进行统计，可以按照月的频度获取用户开启时间、启动次数和停留时间，判断该初始业务需求信息的用户活跃度是否超过某个阈值，该阈值可以根据开启时间、启动次数和停留时间的加权平均值，作为用户活跃度的阈值。如果超过该阈值，则该特征可以作为训练因素之一。上述访问量2022用于根据信息存储器103中解析的产品运营指标信息，按照天的频度获取产品功能每天的访问量，判断该初始业务需求信息的访问次数是否超过某个阈值，该阈值可以通过上一季度访问量的平均值，作为需求访问量的阈值。如果超过该阈值，则该特征值可以作为训练因素之一。上述价值输出度2023用于根据信息存储器103中解析的产品运营指标信息，由于需求完成前需要设置一个预期值，如果功能上线后可以达到事先设置的价值预期值，则该特征值可以作为训练因素之一。上述用户画像2024用于根据信息存储器103中解析的产品运营指标信息，对于产品的需求用户集中度进行统计，判断该初始业务需求信息对应的用户集中度是否超过某个阈值，该阈值可以根据用户性别、年龄、文化、专属职业、地域五个维度进行加权平均值，作为该初始业务需求信息的阈值。如果该超过该阈值，则该特征值做可以作为训练因素之一。上述生产问题数2025用于根据信息存储器103中解析的产品运营指标信息，获取产品上线后出现的生产问题数，判断该初始业务需求信息对应的问题数是否超过某个阈值，该阈值可以通过需求上一个季度的问题平均值，作为判断该产品的稳定性的依据，如果超过该阈值，则该特征值可以作为训练因素之一。上述用户满意度2026用于根据信息存储器103中解析的产品运营指标信息，获取用户使用产品的满意度，每次上线后评价一次，最高为五星好评，判断该初始业务需求信息对应的用户满意度是否低于某个阈值，该阈值可以通过计算上一季度用户满意度得分的平均值获得，如果低于该阈值，则该特征值可以作为训练因素之一。

上述XGBoost算法建模203用于根据用户活跃度2021、访问量2022、价值输出度2023、用户画像2024、生产问题数2025、用户满意度2026，6个影响核心需求的因素传入到XGBoost算法中，对这些特征不断的训练，从信息存储器103中随机选取60％的需求信息进行做标签验证，其中70％的语句用于训练，构造出模型，20％的语句进行测试模型；10％的语句通过调整参数进行验证模型，不断的提高模测的精准度，最终训练出可以精确的判断出核心需求的模型，从而得到核心需求信息，纳入到核心需求信息库。

可选的，仍如图3所示，通过验收标准模块3将上述核心业务需求信息转化成更加标准化、规范化的需求描述，作为验收案例编写的基础，根据谁提出的需求(Who)、该需求用来干什么(What)、需求产生的价值(Value)的方式，采用需求点、场景和步骤的规则对核心需求进行解析，形成验收标准信息，并将上述验收标准信息纳入到信息存储器中。

可选的，如图10所示，上述验收标准模块3包括需求信息库、需求解析器301、信息存储器302。具体地：上述需求解析器301用于根据获取的核心业务需求信息对验收标准进行编写，采用谁提出的需求(Who)、该需求用来干什么(What)、需求产生的价值(Value)的方式对需求信息进行细化，包括需要完成的需求点，该功能的场景大纲以及实施步骤，使得需求进行标准化、数字化；上述信息存储器302用于根据需求解析器301中获取的方式，按照Who-What-Value的方式对信息进行存储，为后续的验收案例提供数据支撑。

在一种可选的实施例中，上述采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例，包括：

将上述核心业务需求信息转化为目标格式的验收标准信息；

采用用户故事方式对上述验收标准信息进行转化处理，得到上述测试案例。

可选的，上述测试案例至少包括：需求条件、触发条件、预期结果。

可选的，采用需求解析器对上述核心业务需求信息进行解析处理得到验收标准信息，采用用户故事方式将上述验收标准信息转化为测试案例。例如，首先使用需求解析器按照需求点、场景、步骤的规则对需求进行解析入库，得到目标格式的验收标准信息，然后基于上述验收标准信息，采用用户故事方式Given-When-Then进行案例编写，得到上述测试案例，并将上述测试案例纳入到案例库，实现需求案例一致性。

可选的，仍如图3所示，通过验收案例生成模块4，采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例。即验收案例生成模块4将上述验收标准信息转化成自然语言，采用用户故事的方式对案例进行编写，即给定什么上下文/条件(Given)，触发什么样的条件(When)，产生什么样的结果(Then)，采用自然语言方式自动维护原始需求含义不变，生成测试案例，并将上述测试案例纳入到验收案例库。

可选的，如图11所示，上述验收案例生成模块4，包括需求条件Given401、触发条件When402、预期结果Then403，具体地：上述需求条件Given401用于根据信息存储器302获取的验收标准信息，针对信息中What的需求点对需求做出各种假设条件，即给定什么上下文/条件，作为需求的前提；上述触发条件When402用于根据信息存储器302获取的验收标准信息，采用需求条件Given401的上下文条件，当提供给一定的数据后，触发给定的条件，验证是否可以满足预期；上述预期结果Then403用于采用触发条件When402给定的数据，用到需求条件Given401中场景中，根据断言判断当前需求是否满足实际预期结果。

在一种可选的实施例中，上述根据上述评审结果确定上述测试案例的自动交付结果，包括：

若上述评审结果指示上述测试案例评审未通过，则响应作用于对上述验收标准信息的更新操作，得到更新后的验收标准信息；

基于上述更新后的验收标准信息确定得到更新后的测试案例；

将上述更新后的测试案例作为上述测试案例，确定得到上述评审结果。

可选的，仍如图3所示，通过验收案例评审模块5对测试案例进行自动审核，当上述测试案例提交后会自动触发审核器对该测试案例进行评审，若案例审核通过后，则对已通过的测试案例打标签，并自动纳入到结果库，若该测试案例没有审核通过，说明该测试案例的需求和验收标准不一致，则返回验收标准模块4，继续完善，直到该测试案例审核通过。

可选的，如图12所示，上述验收案例评审模块5包括验收案例信息库501、触发器502、结果信息库503。具体地：上述验收案例信息库501用于根据验收案例模块4采用的用户故事Given-When-Then的方式编写的验收测试案例(即测试案例)，并纳入到案例信息库(即案例信息库)中，然后对这些案例进行评审验证是否符合最初的要求；上述触发器502用于当验收测试案例编写好提交并纳入到验收案例信息库后501，会自动触发审核器，然后对案例进行评审，对评审的案例进行打标签，如果评审通过后，将该案例标签标注为1，如果评审没有通过，将该案例标签标注为0，同时将没有通过的案例自动发送给验收标准模块3，对验收标准进行优化后再进行验收案例编写、评审，直到所有案例都评审通过，标签为1；上述结果信息库503用于对所有评审通过的验收案例信息纳入到结果信息库中。

在一种可选的实施例中，上述根据上述评审结果确定上述测试案例的自动交付结果，还包括：

在上述评审结果指示上述测试案例评审通过后，获取与上述测试案例对应的源表信息；

基于上述源表信息，从生产运维端获取与上述测试案例对应的生产数据；

将上述生产数据同步至测试环境。

可选的，在获取得到上述源表信息后，上述方法还包括：对上述源表信息进行结构化存储。

可选的，仍如图3所示，通过数据同步模块6同步审核通过测试案例涉及的表数据，首先通过血缘分析获取该测试案例涉及的源表信息，获取目前生产运维上表的大小，对接生产运维，通过自动化数据同步工具对源表信息对应的生产数据进行同步到测试环境。

在一种可选的实施例中，上述将上述生产数据同步至测试环境，包括：

获取上述生产数据的数据量；

判断上述数据量是否超过上述测试环境的预设容量；

若上述数据量未超过上述预设容量，则将上述生产数据直接同步至上述测试环境；

若上述数据量超过上述预设容量，则对上述生产数据进行裁剪处理，将裁剪后的上述生产数据同步至上述测试环境。

可选的，如图13所示，上述数据同步模块6包括血缘分析601、信息存储器602、自动数据同步工具603。具体地：上述血缘分析601是一种技术手段，用于对数据处理过程的全面追踪，从而找到某个数据对象为起点的所有相关元数据对象以及这些元数据对象之间的关系。在本发明中实施例中，具体是对需求验收案例涉及的表进行血缘分析，用于生成验收测试案例的血缘分析结构化数据，包括：表、字段等，取基础元素对象，对上述基础元素对象进行机构化存储，从而获得上述脚本的血缘分析结构化数据。本次数据同步通过血缘分析获取源表信息，是利用开源词法解析工具Sqlparse，通过对验收案例涉及表进行解析，从而可以提取其中的基础元素对象，并将这些基础元素对象进行结构化存储，最终可以将一个验收案例涉及表的字段级映射信息结构化存储在4张表(即表BR_TARGET_FIELD、表BR_SOURCE_ALIAS、表BR_SOURCE_RELATION、表BR_TEMP_FIELD)中。其中：表BR_TARGET_FIELD用于保存目标字段与源字段的映射逻辑；表BR_SOURCE_ALIAS用于保存取数源表的表别名信息；表BR_SOURCE_RELATION用于保存源表的表关联及字段筛选信息；表BR_TEMP_FIELD用于保存临时表字段信息。

上述信息存储器602用于将血缘分析601获取的源表信息，自动的存储起来，用于从生产上同步数据；上述自动数据同步工具603用于获取验收案例的源表信息后，通过对接生产运维，获取生产上表数据量大小，如果测试环境可以容纳下，则把生产数据同步到测试环境上；如果测试环境容纳不下，则按照节点、分布键、分区等方式对数据进行裁剪，再同步到测试环境上。

作为一种可选的实施例，图14是根据本申请实施例的一种可选的产品验收测试框架的示意图，如图14所示，该测试框架具体包括：

生产运维模块141：数据源平台，用于提供原始需求信息和产品运营信息。

源数据采集模块142：用于需求信息通过采用生产查询逻辑以及产品运营通过提供的信息接口封装成配置持续集成任务，准实时的从生产运维环境获取初始业务需求信息和产品运营指标信息。

核心需求识别模块143：用于通过规则匹配和XGBoost机器学习算法构建需求分析模型，根据产品运营指标信息的六项维度以及各项特征的权重配比公式计算出需求的核心度值，然后与各项特征值的阈值进行比对，超过或者低于该阈值的，则自动纳入到核心需求信息库中。

验收标准模块144：用于采用Who-What-Value的方式对原始需求进行澄清，为验收案例提供数据支撑，若不符合要求则继续完善。

验收案例模块145：用于采用用户故事Given-When-Then的方式对验收标准进行拆解，转化成自然语言方式存储在验收测试案例库。

案例评审标签模块146：用于验收案例提交后会自动触发案例评审器，对验收案例进行评审，对评审的结果进行标签化，如果验收案例审核通过，将该案例标注为成功的标致，如果案例审核失败，说明最初的验收标准没有说明清楚，需要再次优化验收标准，直到验收案例评审通过。

同步生产数据模块147：用于对审核通过的案例涉及的表信息通过血缘分析工具获取源表信息，从生产同步数据到测试环境。

验收脚本模块148：用于将验收案例纳入到Cucumber自动化验收框架中，对验收案例进行执行。

问题识别模块149：用于如果验证案例执行失败，则对问题进行自动识别并反馈给先关人员，如果验收案例执行成功，则自动交付，投产后给用户使用，将生产上运营的结果获取下来，形成需求验收的闭环机制。

本发明实施例提供的软件产品的验收方法，能够实现一种自动驱动模式下缩短研发周期的产品的快速验证，有效提升测试效率，快速响应测试需求。表1示出了传统验收测试框架与使用发明实施例提供的框架进行测试的比较结果。

表1

需要说明的是，该框架已应用于页面交易类和接口类应用，通过自动获取业务需求信息，全自动维护核心业务需求信息对案例进行维护，并分析出核心案例涉及的表信息自动从生产同步数据，进行动态验证，结合产品运营指标信息，根据实际市场运营情况使得需求获取的灵活性高，数据准备时间短，问题诊断协助问题分析，全面提高整个产品验收测试的效率，快速验证需求实现情况。

仍需要说明的是，本发明实施例提供的软件产品的验收方法，提高了核心需求获取的灵活性、可靠性、价值性，降低了数据准备和测试周期，提高了案例自动化，增加了问题诊断机制，提高了测试效率。该框架主要包含了3个特性：1)自动维护核心需求。对接生产运维获取需求信息，结合产品运营结果，根据机器学习算法进行建模，识别出当前版本优先级较高的核心需求，并自动入库，全自动维护需求信息，无需人工介入，灵活性高。2)实现验收案例自动化。为了解决业务需求-程序设计-编码实现不一致的短板，采用用户故事方式实现验收标准-验收案例-验收脚本保持一致，纳入到自动化验收测试框架中，实现验收测试案例的持续验证，提高了自动化。同时根据市场需求获取不同场景的数据，自动从生产同步数据，数据准备少，时间短，实现数据的保鲜，缩短了测试周期，提高整个流程的测试效率，且保障需求的一致性。3)问题诊断并动态持续验证，提高解决效率。增加了问题诊断机制，若验收案例失败后会自动触发问题诊断机制，识别出不同类型的问题，推送给相关人员进行完善，节省了人工分析的成本，提高问题的解决效率，缩短整个研发周期。

可以看出，本发明实施例提供的软件产品的验收方法，克服了目前业界人为参与验收测试不灵活、周期长、效率低下的缺陷，提供一种自动维护核心需求且动态验证并识别问题自动驱动完善产品需求的方法和测试框架。可实现对接生产运维，将业务需求信息和产品运营指标信息纳入到需求信息库，根据机器学习算法对需求信息进行分层管理，筛选出核心业务需求信息纳入到需求信息库，灵活的获取生产上运营比较成功且能够产生更多价值的需求，并进行优先完成；然后对和核心业务需求信息进行解析，将需求的验收标准纳入到信息库中，根据用户故事方式对案例进行编写，并进行在线评审，将评审后的案例进行打标签纳入到案例库中，然后通过自动化测试框架对评审通过的案例进行验证，通过断言的方式判断当前需求是否符合要求，对于不符合要求的程序进行报警，然后对问题进行诊断，识别出报错的原因推送相关人员进行解决；对于验收通过的案例进行自动交付，并自动生成报告。该框架灵活性高，可实现研发周期较短的场景下产品的高质量快速交付，提升验收测试的效率。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例还提供了一种软件产品的验收装置，需要说明的是，本申请实施例的软件产品的验收装置可以用于执行本申请实施例所提供的用于软件产品的验收方法。以下对本申请实施例提供的软件产品的验收装置进行介绍。

图15是根据本申请实施例的软件产品的验收装置的示意图。如图15所示，该装置包括：

获取单元150，用于获取预先存储于核心需求信息库中的核心业务需求信息，其中，上述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的；

转化单元152，用于采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例；

评审单元154，用于对上述测试案例进行评审处理，得到评审结果；

交付单元156，用于根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器。

本申请实施例提供的软件产品的验收装置，通过设置获取单元150，用于获取预先存储于核心需求信息库中的核心业务需求信息，其中，上述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的；转化单元152，用于采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例；评审单元154，用于对上述测试案例进行评审处理，得到评审结果；交付单元156，用于根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器，解决了相关技术中基于人工参与的软件产品的生命周期管理方法存在的产品验收效率低、周期长且无法保证产品质量的问题，进而达到了缩短软件产品的验收周期，提升软件产品的生命周期管理效率，有效保证软件产品开发质量的效果。

上述软件产品的验收装置包括处理器和存储器，上述单元等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来(本发明的目的)。

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

本发明实施例提供了一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时实现上述软件产品的验收方法。

本发明实施例提供了一种处理器，上述处理器用于运行程序，其中，上述程序运行时执行上述软件产品的验收方法。

如图16所示，本发明实施例提供了一种电子设备，该电子设备160包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现以下步骤：获取预先存储于核心需求信息库中的核心业务需求信息，其中，上述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的；采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例；对上述测试案例进行评审处理，得到评审结果；根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器。本文中的设备可以是服务器、PC、PAD、手机等。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序：获取预先存储于核心需求信息库中的核心业务需求信息，其中，上述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的；采用用户故事方式对上述核心业务需求信息进行转化处理，得到与上述核心业务需求信息对应的测试案例；对上述测试案例进行评审处理，得到评审结果；根据上述评审结果确定上述测试案例的自动交付结果，其中，上述自动交付结果用于指示将上述测试案例自动交付至目标服务器。

可选的，上述计算机程序产品还适于执行初始化有如下方法步骤的程序：若上述评审结果指示上述测试案例评审通过，则执行上述测试案例；若执行结果指示上述测试案例执行通过，则将上述测试案例自动交付至上述目标服务器。

可选的，上述计算机程序产品还适于执行初始化有如下方法步骤的程序：获取上述初始业务需求信息和上述待测软件产品对应的生产运营指标信息；对上述初始业务需求信息进行分类处理，得到分类后的需求信息；基于上述生产运营指标信息和上述分类后的需求信息，确定模型训练特征；基于上述模型训练特征，采用机器学习算法训练得到上述核心业务需求信息。

可选的，上述计算机程序产品还适于执行初始化有如下方法步骤的程序：将上述核心业务需求信息转化为目标格式的验收标准信息；采用用户故事方式对上述验收标准信息进行转化处理，得到上述测试案例。

可选的，上述计算机程序产品还适于执行初始化有如下方法步骤的程序：若上述评审结果指示上述测试案例评审未通过，则响应作用于对上述验收标准信息的更新操作，得到更新后的验收标准信息；基于上述更新后的验收标准信息确定得到更新后的测试案例；将上述更新后的测试案例作为上述测试案例，确定得到上述评审结果。

可选的，上述计算机程序产品还适于执行初始化有如下方法步骤的程序：在上述评审结果指示上述测试案例评审通过后，获取与上述测试案例对应的源表信息；基于上述源表信息，从生产运维端获取与上述测试案例对应的生产数据；将上述生产数据同步至测试环境。

可选的，上述计算机程序产品还适于执行初始化有如下方法步骤的程序：获取上述生产数据的数据量；判断上述数据量是否超过上述测试环境的预设容量；若上述数据量未超过上述预设容量，则将上述生产数据直接同步至上述测试环境；若上述数据量超过上述预设容量，则对上述生产数据进行裁剪处理，将裁剪后的上述生产数据同步至上述测试环境。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、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.根据权利要求1所述的方法，其特征在于，所述采用用户故事方式对所述核心业务需求信息进行转化处理，得到与所述核心业务需求信息对应的测试案例，包括：

将所述核心业务需求信息转化为目标格式的验收标准信息；

采用用户故事方式对所述验收标准信息进行转化处理，得到所述测试案例。

5.根据权利要求4所述的方法，其特征在于，所述根据所述评审结果确定所述测试案例的自动交付结果，包括：

若所述评审结果指示所述测试案例评审未通过，则响应作用于对所述验收标准信息的更新操作，得到更新后的验收标准信息；

基于所述更新后的验收标准信息确定得到更新后的测试案例；

将所述更新后的测试案例作为所述测试案例，确定得到所述评审结果。

6.根据权利要求1所述的方法，其特征在于，根据所述评审结果确定所述测试案例的自动交付结果，还包括：

在所述评审结果指示所述测试案例评审通过后，获取与所述测试案例对应的源表信息；

基于所述源表信息，从生产运维端获取与所述测试案例对应的生产数据；

将所述生产数据同步至测试环境。

7.根据权利要求6所述的方法，其特征在于，所述将所述生产数据同步至测试环境，包括：

获取所述生产数据的数据量；

判断所述数据量是否超过所述测试环境的预设容量；

若所述数据量未超过所述预设容量，则将所述生产数据直接同步至所述测试环境；

若所述数据量超过所述预设容量，则对所述生产数据进行裁剪处理，将裁剪后的所述生产数据同步至所述测试环境。

8.一种软件产品的验收装置，其特征在于，包括：

获取单元，用于获取预先存储于核心需求信息库中的核心业务需求信息，其中，所述核心业务需求信息是基于待测软件产品的初始业务需求信息提取得到的；

转化单元，用于采用用户故事方式对所述核心业务需求信息进行转化处理，得到与所述核心业务需求信息对应的测试案例；

评审单元，用于对所述测试案例进行评审处理，得到评审结果；

交付单元，用于根据所述评审结果确定所述测试案例的自动交付结果，其中，所述自动交付结果用于指示将所述测试案例自动交付至目标服务器。

9.一种处理器，其特征在于，所述处理器用于运行程序，其中，所述程序运行时执行权利要求1至7中任意一项所述的软件产品的验收方法。

10.一种电子设备，其特征在于，包括一个或多个处理器和存储器，所述存储器用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至7中任意一项所述的软件产品的验收方法。

Images