产品需求文档、测试信息的生成方法及装置与流程

本申请涉及产品开发技术领域，特别涉及产品需求文档、测试信息的生成方法、及装置。

背景技术：

在软件产品开发时，一个软件产品涉及很多产品功能，不同的产品经理需要针对特定产品功能进行研发，生成产品需求文档，而产品经理在生成产品需求文档时，完全凭借自己对产品的了解，以及自己独有的文字撰写习惯，手动撰写生成产品需求文档，以便测试人员根据该产品需求文档作进一步的软件产品开发处理。

在实际开发过程中，由于企业人员流动性较大，当新产品经理对产品进行二次开发时，就需要阅读理解原产品需求文档，在此基础上再做二次开发，由于每个人的思维方式不同，撰写习惯也不相同，因此，这种纯粹依赖个人理解能力的方式，大大限制了产品开发效率。

另外，由于同一企业的产品会有一定技术相关性，不同的产品经理需要相互沟通了解产品功能需求，之后才能够研发生成一个合格的产品需求文档，这种纯粹依赖个人语言沟通能力的方式，在一定程度上也限制了产品开发效率。

技术实现要素：

为解决上述技术问题，本申请实施例提供了产品需求文档、测试信息的生成方法、及装置，能够实现标准化的产品需求文档，进而可以在该文档基础上自动生成测试用例或测试脚本。

为此，本申请实施例提供了如下技术方案：

一种产品需求文档生成方法，包括：

提供用于对产品需求进行配置的操作选项；

通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的产品需求文档模板、组件集以及各组件下的业务规则集；

根据所述配置信息生成产品需求文档。

一种产品测试信息生成方法，包括：

提供用于对产品需求进行配置的操作选项；

通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的组件集以及各组件下的业务规则集；

根据所述配置信息，以及预先获得的业务之间的拓扑关系信息，生成用于进行产品测试的测试用例。

一种产品需求文档生成装置，包括：

操作选项提供单元，用于提供用于对产品需求进行配置的操作选项；

配置信息接收单元，用于通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的产品需求文档模板、组件集以及各组件下的业务规则集；

需求文档生成单元，用于根据所述配置信息生成产品需求文档。

一种产品测试信息生成装置，包括：

操作选项提供单元，用于提供用于对产品需求进行配置的操作选项；

配置信息接收单元，用于通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的组件集以及各组件下的业务规则集；

测试用例生成单元，用于根据所述配置信息，以及预先获得的业务之间的拓扑关系信息，生成用于进行产品测试的测试用例。

一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供用于对产品需求进行配置的操作选项；

通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的产品需求文档模板、组件集以及各组件下的业务规则集；

根据所述配置信息生成产品需求文档。

一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供用于对产品需求进行配置的操作选项；

通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的产品需求文档模板、组件集以及各组件下的业务规则集；

根据所述配置信息，以及预先获得的业务之间的拓扑关系信息，生成用于进行产品测试的测试用例。

与现有技术相比，本申请实施例具有以下优点：

本申请实施例提供了通过配置的方式生成产品需求文档的实现方案，在该方案中，可以通过对产品所需的文档模型、组件集以及业务规则集进行配置，自动生成产品需求文档，因此，能够实现产品需求文档的规范化及标准化，同时，能够缩短研发时间，提升效率，并且能够有效沉淀产品开发文档，提高数据资源利用率。

另外，由于能够记录具体产品的配置信息，包括具体的组件、业务规则等，因此，可以通过预先保存产品中的业务拓扑关系信息，为具体的业务规则自动生成测试用例，从而使得测试效率也得到提升。

再者，由于能够实现业务规则的结构化表达，其中包括业务规则对应的特征值信息，因此，还能够在实现测试用例的基础上，自动从真实的业务数据中筛选出测试数据，并生成测试脚本，更进一步提高了研发效率。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1为本申请在实际应用中的场景示例图；

图2为本申请实施例提供的第一方法的流程图；

图3-1至3-4为本申请实施例提供的配置界面的示意图；

图4为本申请实施例提供的第二方法的流程图；

图5为本申请实施例提供的第一装置的示意图；

图6为本申请实施例提供的第二装置的示意图；

图7为本申请实施例提供的计算机系统的示意图。

具体实施方式

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

为了便于理解，下面首先对产品相关的概念进行介绍。在本申请实施例中，一个产品通常可以涉及一个多个页面，一个页面中可以关联多个组件，一个组件中又可以包括多条业务规则。

例如，对于“天猫国际”这一产品，其涉及的页面可能包括详情页面、下单页面等，下单页面中可能包括“收货地址组件”、“优惠券组件”，等等。其中，组件可以看作是一系列相互关联的业务规则的集合，是将相关联的业务规则的功能聚合生成的页面元素；组件一般可以包括组件显示示例图、组件介绍和业务规则。举例说明，以发票组件为例，发票组件可以包含很多业务规则，如生鲜类商品下单支持开具电子发票，但不支持开具纸质发票、图书商品下电页面可选择是否开具发票、电器商品下单页面强制开具发票；再比如，将与收货地址模块相关的业务规则聚合归纳为“收货地址”组件，例如在“淘宝”下单页面中“收货地址”组件可以包含很多业务规则，例如：1、买家没有保存过收货地址，则下单页面会引导买家完善收货地址信息；2、下单页面中收货地址模块最多允许保存20个收货地址信息等业务规则；在本申请实施例中，将这个和收货地址模块有关的页面逻辑和底层逻辑的业务规则归纳定义成一个“收货地址”组件。

基于上述分析，在本申请实施例提供的研发平台中，首先可以为产品经理(pd)用户提供用于通过配置的方式生成产品需求文档(prd)的功能，通过该功能，可以为用户提供配置界面，pd可以通过配置界面，对产品所涉及的页面，所需的组件，以及组件内的业务规则等进行配置，另外还可以提供文档模板，pd通过配置上述信息，选择具体的模板，便可以自动生成prd文档。通过这种方式生成的prd文档具有标准性规范化的特点。另外，由于具体的组件信息、业务规则等信息可以以配置信息的形式进行保存，因此，还可以在此基础上自动生成测试信息，例如，测试用例或者测试脚本等，而不需要再由相关的测试人员通过阅读prd文档的方式手动生成测试用例或测试脚本。

另外，为了更好的支持测试信息的自动生成，在本申请的优选实施例中，还可以支持将业务规则可以采用结构化形式进行定义。例如，一条具体的业务规则可以包括：特征值、操作步骤和预期结果三部分。例如，一个业务规则，其自然语言表述为“图书类网站的图书类商品中的下单页面用户是否开具发票”，经过结构化处理，对应的结构化表达式语言包括：前置条件中的特征值为图书类商品，操作步骤为用户下单，预期结果为发票选项可以选择是否开具发票，等等。这样，对于一条业务规则而言，可以根据特征值的定义，从全链路功能平台中生成具体的测试数据，并根据预置的业务之间的拓扑关系图等信息，生成测试脚本。测试脚本可以是根据具体的操作步骤生成的执行代码，之后，通过测试平台执行具体的测试脚本，则相当于是执行也业务规则所包含的操作步骤，将脚本执行结果与预期结果进行比对，则可以确定是否通过测试。

下面写结合实际应用场景对本申请的实现进行介绍。

参见图1，图1是本申请在实际应用中的场景示例图，如图1所示，本申请提供的产品需求文档生成方法分别以客户端以及服务端的形式应用于终端和服务器中，如图1所示的终端101和服务器102中，终端101与服务器102相互通信为开发人员提供开发平台，使得产品需求文档开发人员基于统一标准化的开发平台进行开发，从而能够有效沉淀产品需求文档，提高数据资源利用率。如图1所示，pd用户a利用终端101访问服务器102，终端101可以为pd用户提供配置界面，将用户在该配置界面上输入的配置信息发送给服务器102，服务器102根据用户选择的prd文档模板和用户输入的配置信息，组合生成prd文档。之后，服务器102可以将该prd文档进行保存，另外还可以将该prd文档发送给终端101，由终端101向pd用户a显示该产品需求文档。需要说明的是，服务器102可以通过网络为多个pd用户的终端，同时提供自动生成产品需求文档服务。

另外，服务器102还可以存储已设计好的产品需求文档，则其他pd用户或者测试人员等可以查看已设计好的产品需求文档，如图1中所示，pd用户b可以通过终端103与服务器102的网络通信，来查看产品需求文档，从而能够快速了解该产品需求文档，方便进行产品升级。需要说明的是，服务器102可以通过网络为多个pd用户的终端，同时提供产品需求文档查询服务，同步并行处理多个产品需求文档的查询过程。

这里需要说明的是，终端101可以为台式计算机、笔记本电脑、平板等终端设备；终端103与终端101相类似；服务器102为提供数据服务的设备，如web服务器，app服务器等，在实际应用中，可以为独立部署的服务器设备，也可以采用集群部署的服务器。

基于上述应用场景，下面对本申请实施例提供的具体实现方案进行详细介绍。

实施例一

本申请实施例一首先提供了一种产品需求文档生成方法，参见图2，该方法具体可以包括：

s201、提供用于对产品需求进行配置的操作选项；；

在本申请实施例中，可以通过服务端-客户端，或者服务器-浏览器的网络构架，为pd用户提供标准化的开发平台，pd用户利用客户端通过网络通信，就能够进行产品需求文档的生成。

具体的，pd用户在需要开发产品需求文档时，则可以启动终端中配置的客户端，例如点击客户端，或者通过浏览器登录配置界面的网址，开发人员实施这些操作，客户端监听到pd用户实施这些操作时，向服务端发送配置界面的渲染请求。

服务端接收客户端发送的关于产品需求文档配置界面的渲染请求后，可以向客户端反馈配置界面的界面数据，该界面数据是指能够通过渲染生成配置界面的数据；对于服务端而言，其通过网络通信可以同时为多个客户端提供数据支持，则当服务端同时接收到多个渲染请求时，服务端可以同时发起多个进程并行向多个客户端反馈界面数据。

具体的，为了提供标准化的配置界面，本申请实施例基于产品研发的实际需求提出了分层的配置方式，该分层的配置方式更具体的以分层的配置界面来呈现；其中，主要分层逻辑可以根据前文所述的产品中各要素之间的关系来确定。例如，由于一个产品至少包括一个页面，而一个页面至少包括一个组件，而一个组件至少包括一个业务规则；基于此，进一步提出了该分层的配置界面包括：根据产品、页面、组件、以及业务规则这四个部分之间的层次关系构建的不同的配置界面。

更具体的，所述配置界面包括：根据产品配置控件生成的第一层配置界面，所述第一层配置界面用于承载配置产品基本信息的配置控件；

根据页面配置控件生成的第二层配置界面，所述第二层配置界面用于承载配置页面相关信息的配置控件；

根据组件配置控件生成的第三层配置界面，所述第三层配置界面用于承载配置组件相关信息的配置控件；所述组件是根据业务规则生成的。，其中，组件是根据业务规则生成的。

则服务端向客户端反馈的界面数据具体包括：上述第一层配置界面的界面数据、上述第二层配置界面的界面数据、上述第三层配置界面的界面数据以及上述第四层配置界面的界面数据。

需要说明的是，在具体开发prd文档的过程中，上述各层界面可能并不是全部都需要用到，而是可以根据具体情况的需求而确定使用哪些层的配置界面。

s202：通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的产品需求文档模板、组件集以及各组件下的业务规则集；

其中，具体实现时，pd用户发起prd文档生成的方式可以有多种。例如，在一种方式下，由于在每次生成prd文档之后，服务器都可以对具体的产品信息进行保存，其中，所述产品信息包括具体的prd文档，以及关联的组件集信息、测试用例、测试脚本，等等。而后续的产品可能是在之前某个产品基础上继续开发，或者，与之前某个产品的关联性非常强，则当前产品的pd用户可以通过在已有产品的相关配置信息的基础上进行定制。或者，在另一种方式下，也可以是定制全新的产品，也即，当前产品与之前已有产品的关联性可能不大，因此，可以定制全新的产品。

其中，对于第一种方式，可以提供用于从已有产品中进行选择的操作选项，通过所述操作选项接收选择的目标已有产品信息，提供所述目标已有产品关联的配置信息，以及用于在该目标已有产品关联的配置信息基础上进行编辑的操作选项，以便通过在目标已有产品关联的配置信息基础上进行编辑的方式，确定当前产品的配置信息。例如，具体实现时，可以在第一层配置界面中为pd用户展示可选的产品标签，其中既可以包括当前pd用户自己开发的产品，还可以包括其他pd用户开发的产品，在具体进行展示时，可以区分为“我的产品”与“全部产品”两个目录，以便于当前pd用户进行选择。在选择了具体的产品标签后，便可以将该已有产品对应的prd文档模板作为当前产品选定的prd文档模板，另外，可以在第三层配置界面中，展示出该已有产品对应的组件集信息。这样，该pd用户可以在该已有产品关联的组件集的基础上继续进行定制，包括增加新的组件，对已有组件进行业务规则的重新定制，等等，以生成当前产品的组件树。其中，在新增组件或者对已有组件进行定制的过程中，可以通过第四层配置界面，实现对业务规则的编辑或者录入等操作。

对于第二种方式，由于是定制全新的产品，因此，可以提供用于对产品进行全新定制的操作选项，以及可选的产品需求文档模板以及页面信息，之后，可以通过所述操作选项接收选择的目标产品需求文档模板，以及所涉及的目标页面。进而，可以提供所述目标页面关联的基础组件信息集合，以及用于对所述基础组件进行编辑的操作选项，以便通过对所述目标页面关联的基础组件信息进行编辑的方式，确定当前产品的组件集以及业务规则集。例如，具体实现时，在接收到当前pd用户的请求后，还可以提供用于对产品名称、prd文档中包含的文档结构区块等进行配置的界面，其中，文档结构区块可以以树状结构进行表达，可以支持多级树状结构。例如，一级节点可以包括概述以及功能，概述节点下还可以包括背景、目标、规划、风险等二级节点，功能节点下还可以包括功能总表、需求详情等二级节点，等等。通过这种对文档区块的定制，可以生成一个新的prd文档模板，并且，当前的开发过程中就默认使用该模板进行prd文档的生成。

另外，还可以通过第二层配置界面，提供可选的页面信息，pd用户根据自己所需开发产品所涉及的页面，通过该第二层配置界面进行目标页面的选择。在目标页面被选择后，可以通过第三层配置界面，将该目标页面关联的基础组件集合进行展示。进而，pd用户可以在该第三层配置界面中进行组件的选择，或者，在需要使用新的组件时，还可以通过该第三层配置界面增加新的组件；在需要对已有基础组件进行定制时，还可以通过该第三次配置界面发起对该基础组件的定制，等等。之后，可以通过第四层配置界面，对组件内具体的业务规则进行录入或者编辑等操作。

也就是说，无论是上述第一种方式还是第二种方式，都可以提供用于进行组件集编辑的操作选项，进而，还可以根据组件集编辑结果生成组件树；其中，所述用于进行组件集编辑的操作选项可以包括：从已知组件中进行选择的操作选项，用于增加新组件的操作选项，以及用于对原有组件进行定制的操作选项，等等。例如，具体实现时，在第三层配置界面中，可以以组件树的形式展示pd用户选择的组件，并且，这种组件树支持新增和修改，保存后存储到文档模板信息中。在点击业务组件树节点时，展示页面基础信息，主要包括页面前置信息(用于识别当前页面准入条件以及页面提供的系统操作，系统操作可以透传给每个组件操作)，同时按照规则展示当前页面组件信息。其中，如果是全新定制，默认展示当前页面所有基础组件名称，组件详情以及其他业务组件，支持点击展开。如果是原产品升级，默认展示产品定制组件名称，组件详情以及其他组件，支持点击展示。

其中，组件有两种分类维度，第一种按照功能聚合，主要用于组件关联逻辑维护；第二种主要用于维护页面ui位置识别，可由每个页面自定义，如下单页面可分为：商品区块、店铺区块、包裹区块、全局、系统级别等，区块分类直接显示在用户需求定制页面。

在需要新增系统不存在的组件(需求先于代码开发时)时，组件操作、校验点等都可能未知，此时，可以抽取操作、校验点逻辑模型，用于新增时识别。例如，具体新增组件的配置界面可以如图3-1所示，其中，组件名称可以由pd用户自定义，可以对名称的长度、字符类型等进行限制，例如，限制为10个字符以内，不支持特殊字符。另外，组件名称还可以与测试平台组件中的代码进行映射。关于组件介绍信息，可以支持用户输入，用于介绍组件主要业务及当前线上现状，以及其他需要备注的信息。前置信息为基本特征的一级节点，例如，对于某网络销售平台中的产品，基本特征可以分为：买家、卖家、商品、订单等，用于规则配置时圈定场景。测试平台提供选项选择，仅用于识别操作，代码功能上线后，可以将实际动作配置到对应的选项上。业务规则分为两类：组件本身、关联组件相关，其中，关联组件用于识别改动范围预估，关联影响是否成立由用户最终决定。

在需要对原有组件进行定制时是指，平台已实现业务组件，初期产品中已经完成了组件定制，但是，在当前产品中需要对业务规则进行更改。对此，可以通过在第三层配置界面中点击组件名称后展开组件详情，每个组件可以分为组件介绍、组件前置、组件操作、业务规则(组件业务规则、关联业务规则)、关联组件。其中，为了避免对其他已有产品造成影响，可以要求原有业务规则不可更改，仅支持新增规则和删除已有规则。在完成定制后，可以保存组件版本、组件快照，并且，还可以记录产品引用组件时设置信息和组件差异显示。另外，产品中组件版本发生变更时，还可以提示用户组件变更，支持查看变更详情，包括新老组件配置信息以及所属产品。

无论是新增组件，还是在原有组件中新增新的业务规则，具体都可以在第四层配置界面中进行业务规则的新增操作。其中，新增规则界面可以支持切换不同模式，例如，自然语言模板和表达式化语言模板，以“天猫超市”商品详情页面运费显示为例，自然语言：天猫超市商品详情页面运费显示为“满88元包邮”；表达式语言为前置条件：商品-天猫超市，操作步骤：渲染商品详情，预期结果：运费模块展示“满88元包邮”。不同模板中的区块可以相同，例如，可以包括条件、操作及结果、规则预览以及操作按钮区等。

以表达式化语言模板为例，配置界面可以如图3-2所示。其中可以包括终端选择、前置条件、操作方式设置、组件关联关系信息设置、规则预览等多个配置选项。

其中，关于前置条件的配置，如图3-3所示，可以提供系统预设的基本特征维度进行定制。例如，在网络销售系统产品中，基本特征可以包括买家、商品、卖家、订单等。其中，选中的基本特征默认可以无表达式，但是系统可以提供当前组件下已存在的业务特征供参考、快速定制。而在基本特征基础上生成的业务特征(例如，图3-3中所示的买家特征1，买家特征2，商品特征1，商品特征2，等等)可以存储在全链路平台中，系统预设的基本特征、业务特征由全链路平台提供接口支持，同时全链路平台还可以提供接口支持新增新的业务特征。特征表达式则可以由本申请实施例中提供的研发平台进行拼装并传递给全链路平台进行解析，拼装结果中可以包含：期望特征值、运算符、表达式顺序、数据是否锁定，等。总之，通过“前置条件”配置，可以实现对业务规则特征值相关信息的配置。

关于操作配置，具体的配置界面可以如图3-4所示，其中，具体的操作和结果实现可以由测试平台(例如，matrix平台等)提供，本申请实施例中的研发平台仅需完成操作、结果的解析识别以及结果校验点的定制。具体实现时，可以自动带入组件所属页面基本操作、组件基本操作，有默认选中值(系统提供)，如下单页面默认选中确认订单。一个操作可以支持多个结果验证，一个规则可以支持多个操作，本申请实施例中的服务器可以维护操作的顺序并传递给测试平台。校验点可以以组件维度提供查询，系统已有校验点可以以枚举形式供用户选择、量化的校验点支持输入。

需要说明的是，操作方式的使用场景主要可以分为下面三种场景：

1.无需操作方式设置，例如：单商品下单场景下，积分组件选择“使用积分”操作，系统默认为全量使用，无需用户选择；

2.需要对操作方式进行设置，例如：单商品下单场景下，发票组件选择“开票”操作，用户需要对发票组件的发票抬头、发票类型、发票内容进行选择；

3.需要对操作方式进行设置，例如：多商品下单场景下，“花呗分期”组件选择“修改花呗分期”操作，用户需要选择对哪一个商品进行修改。

在将上述对特征值以及操作方式信息配置完成后，可以将这两个区块内容自动封装，生成业务规则，并且，可以提供对规则的预览。

在完成上述配置之后，可以通过点击图3-2中的“保存”按钮，对配置的内容进行保存。另外，在表达式页面中，还可以提供“生成测试用例”的选项，用户可以通过点击该选项，生成具体的测试用例。

s203：根据所述配置信息生成产品需求文档。

在完成上述对组件集以及规则集以及prd文档模板的配置后，便可以自动生成具体的prd文档。可见，通过本申请实施例，可以通过配置的形式进行prd文档的生成，从而有利于实现pdr文档的规范化以及标准化。

另外，在本申请实施例提供的研发平台中，还可以提供搜索功能，支持按照组件类别(基础组件、业务组件)、组件名称、支持的终端(pc、native、h5等)、平台(导购、正向交易、逆向交易)、页面(下单、购物车、退款申请等)、组件状态(新增、使用中、归档、删除)等查询。另外，还可以提供各种操作，包括全局新增组件、批量选中组件、批量删除组件、批量归档组件等；针对单条组件有删除组件、归档组件、业务规则详情等。

在实际产品开发过程中，开发人员完成产品需求文档的开发之后，测试人员需要依据该产品需求文档编写测试用例，测试用例是为某个测试目标而制定的一组测试输入、执行条件以及预期结果。测试用例是产品的测试核心，测试用例的数量和质量直接决定该产品的开发质量，因此测试用例的开发也是产品开发的一个重要环节。传统方式是由测试人员依据个人开发经验手动编写测试用例，由于个人经验的参差不齐，导致开发的测试用例的数量和质量会不满足产品需求，再者手动编写测试用例的效率也不能满足开发需求。

而本申请实施例中，由于prd文档是通过配置的方式自动生成的，在保存prd文档时，还可以保存下文档中的配置信息，包括具体包括的组件集以及规则集等信息。因此，还可以在上述配置信息的基础上，自动生成测试用例。具体的，服务器中可以预先获得业务之间的拓扑关系信息，并且，还可以预先设置相关的算法，这样，可以根据所述产品需求文档关联的配置信息，生成用于进行产品测试的测试用例。

具体的，服务端可以根据预设的产品业务拓扑关系图，确定与产品的业务规则相关的业务信息；进而，可以根据所述业务信息，以及产品需求文档中的配置信息以及业务关系拓扑关系信息，生成与所述业务规则对应的测试用例。

具体实现时，可以从提供多种用于发起测试用例/测试脚本生成的操作选项。例如，一种方式下，可以按产品一键生成用例，具体的，可以提供用于针对指定产品生成测试用例的第一操作选项，通过所述第一操作选项接收到对应的请求时，根据所述指定产品关联的各业务规则，分别生成对应的测试用例。例如，具体的，可以在“产品管理”页面每一个prd后面对应有一个“用例管理”的链接，点击【用例管理】后触发用例生成。具体的，可以按每条业务规则生成一份用例集合，生成成功后跳转到用例管理列表。还可以按照产品、页面、组件集、规则集的树形结构生成用例目录，每一条规则都会对应一个最底层的叶子目录。对于含有特征值的结构化的规则，在生成用例的同时还可以生成对应的测试脚本，测试用例与测试脚本可以一一关联对应。当然，对于没有特征值的非结构化规则，只能生成无对应脚本的测试用例。之后，可以由相关的测试人员等用户通过人工关联测试数据的方式，为这种测试用例关联测试数据，进而得到对应的测试脚本，再通过执行这种测试脚本进行产品测试。

另一种实现方式下，还可以为指定产品关联的各组件下的各业务规则分别提供用于生成测试用例的第二操作选项，这样，通过所述第二操作选项接收到针对指定业务规则生成测试用例的请求时，为该指定业务规则生成测试用例。具体实现时，产品内每个组件的每条规则都可以有对应的【生成用例】操作选项。具体实现时，还可以按照产品、页面、组件集、规则集的树形结构生成用例目录，生成的用例存放在对应规则的目录下。

其中，无论是针对整个产品一键生成的测试用例，还是针对具体的业务规则生成测试用例，每条规则都可以生成多个测试用例。

为了便于理解测试用例，下面进行举例说明，以“系统登录”的业务规则为例，生成的一个测试用例如下：

用例名称：系统登录；

前置条件：用户名存在、密码正确；

测试数据：已存在的用户和密码：test/hello1234；

测试步骤1：打开ie浏览器，在地址栏输入相应目标地址，进入系统登录页面；

测试步骤2：输入用户名test、输入密码hello1234；

测试步骤3：点击“登录”；

预期结果：登录成功。

在一种可选的实现方式中，服务端可以根据不同的业务规则生成不同数量的测试用例。例如，当某业务规则不涉及到产品业务时，服务端可以针对该业务规则生成一条测试用例，比如系统登录测试用例；当某业务规则涉及到具体的产品业务时，服务端可以针对该业务规则生成多条测试用例，以便能够全面覆盖产品业务，保证产品的有效性和稳定性。

其中，当某业务规则涉及到具体的产品业务时，服务端可以根据预先建立的产品业务拓扑关系图和所述产品所包括的业务规则的配置信息，为产品的每个业务规则生成测试用例；该产品业务拓扑关系图可以是根据实际产品的业务之间的关联关系生成的关系图；该产品业务拓扑关系图反映了真实的业务关联情况，服务端利用该产品业务拓扑关系图能够自动为一条业务规则膨胀出多个测试用例。

具体的，在本申请实施例中，由于每条业务规则被结构化表示为前置条件、操作步骤、以及预期结果这三大部分，服务端针对以上三部分在底层封装了对应的特征值和校验方法的代码，前置条件对应有特征值，而操作步骤和预期结果分别对应有校验方法的代码，因此，针对一个业务规则所涉及的产品业务之间的关系能够膨胀出多个测试用例。

举例说明，以“电器城商品下单必须开具发票”这一业务规则为例，由于电器城商品业务关联大家电、小家电、3c数码等具体业务，因此在生成测试用例时，可以生成3条测试用例：1、大家电商品下单必须开具发票；2、小家电商品下单必须开具发票；3、3c数码商品下单必须开具发票等。

需要说明的是，一条业务规则可以对应多个测试用例，但是，一个测试用例只能对应一个业务规则。举例说明，以商品详情页为例，商品详情页面关联的组件可以有运费组件、商品主图组件、商品价格组件等等多个组件，其中运费组件可以包含多个业务规则：1、天猫超市商品详情页运费显示“满88包邮”；2、普通天猫商品，运费展示对应的价格，如运送到杭州为运费包邮、运送到广州为运费5元等等；服务端根据产品业务拓扑关系图针对业务规则1可以生成多个测试用例；同时针对业务规则2也可以生成多个测试用例。

需要说明的是，对于未做改动的业务规则生成测试用例时，不需要再次生成测试用例，可以直接将之前的测试用例导入到现有产品测试用例列表中。同时，服务端可以支持用户查看生成的测试用例。

通过上述方法，服务端通过产品业务拓扑关系图和结构化业务规则，能够自动生成的多个测试用例，这些测试用例足够全面和具体，能够达到很好的测试效果。而传统的测试用例生成需要测试人员依据经验手动编写，效率较低而且由于受人为因素的影响，测试效果不理想。因此，本申请实施例中，在以配置的方式自动生成prd文档的同时，还可以利用这种配置信息以及预先保存的业务拓扑关系信息，自动生成测试用例，因此，能够提升整体研发效率，保障产品质量。

需要说明的是，在实际应用中，除了测试用例，在进行产品测试过程中，还需要用到测试脚本，其中，测试脚本一般是指一个特定测试的一系列指令，这些指令可以被测试工具执行，用于测试产品的质量是否满足需求。传统方式是由测试人员依据个人开发经验手动编写测试脚本，编写测试脚本时还需要编写虚假的测试数据，由于个人经验的参差不齐，导致开发的测试脚本不合适，或者测试数据不合适，导致测试无法正常运行，再者手动编写测试脚本的效率也不能满足开发需求。

而在本申请实施例中，由于支持对业务规则的结构化表达，其中包括前置条件、操作步骤和预期结果，并且在底层已封装对应的代码，服务端通过业务与业务的关联关系拓扑图，针对一条业务规则生成一个或多个测试用例；进一步地，针对结构化的测试用例，利用其前置条件对应的特征值能够筛选出真实的业务数据作为测试数据，进而，根据该测试数据和已封装的代码自动生成测试脚本。

当然，对于非结构化业务规则即为自然语言的业务规则，该业务规则由于没有结构化，则无法通过特征值进行测试数据筛选，而测试脚本的生成需要有对应的测试数据，因此非结构化业务规则可以自动生成测试用例但不能生成相应的测试脚本。

可见，在本申请实施例中，对于进行了结构化表达的业务规则，服务端可以自动地调用线上运行的真实数据作为测试数据，自动生成测试脚本，在提高脚本生成效率的同时，还可以保证测试的有效性。测试脚本执行完成之后，可以生成相应的测试报告，在测试报告中可以读取成功测试用例的数量、失败测试用例的数量。同时，用户可以在失败测试用例日志中查找失败的具体原因，以便于用户可以快速定位错误，及时修改，保证产品的质量。

利用上述方法，服务端可以在自动生成测试用例的同时生成对应的测试脚本，并且可以调用线上运行的数据作为测试数据，保证了测试的真实性和有效性，使得用户可以快速开展测试工作，提高测试效率。

上述本申请实施例提供的产品需求文档生成的方法，为产品开发人员提供统一标准结构化的产品需求文档开发方式，通过结构化的配置界面引导开发人员快速了解业务，快速生成产品需求文档，并根据产品需求文档中的业务规则以及业务关系拓扑图自动生成对应的测试用例和测试脚本，这种标准化的开发方式能够缩短研发时间，并且能够有效沉淀产品开发文档，使整个研发流程一体化、自动化和智能化，保障产品质量。

实施例二

如前文所述，在按照本申请实施例提供的方式完成对产品需求的配置之后，也可以直接根据这种配置信息生成测试用例，而不需要等到生成具体的prd文档之后再生成测试用例。因此，该实施例二主要提供了一种产品测试信息生成方法，参见图4，该方法具体可以包括：

s401：提供用于对产品需求进行配置的操作选项；

s402：通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的组件集以及各组件下的业务规则集；

s403：根据所述配置信息，以及预先获得的业务之间的拓扑关系信息，生成用于进行产品测试的测试用例。

具体实现时，如果所述业务规则为包含特征值的结构化规则，则还可以根据所述特征值从真实的业务数据中筛选出测试数据，并根据所述测试数据，为所述业务规则对应的测试用例生成测试脚本。

关于该实施例二中各步骤的具体实现，可以参见前述实施例一中的记载，这里不再赘述。

与上述方法相对应的，本申请实施例还提供了一种产品需求文档生成装置，参见图5，该装置具体可以包括：

操作选项提供单元501，用于提供用于对产品需求进行配置的操作选项；

配置信息接收单元502，用于通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的产品需求文档模板、组件集以及各组件下的业务规则集；

需求文档生成单元503，用于根据所述配置信息生成产品需求文档。

具体实现时，该装置还可以包括：

测试用例生成单元，用于根据所述产品需求文档关联的配置信息，以及预先获得的业务之间的拓扑关系信息，生成用于进行产品测试的测试用例。

具体的，所述测试用例生成单元具体可以包括：

第一操作选项提供子单元，用于提供用于针对指定产品生成测试用例的第一操作选项；

第一生成子单元，用于通过所述第一操作选项接收到对应的请求时，根据所述指定产品关联的各业务规则，分别生成对应的测试用例。

或者，所述测试用例生成单元具体也可以包括：

第二操作选项提供子单元，用于为指定产品关联的各组件下的各业务规则分别提供用于生成测试用例的第二操作选项；

第二生成子单元，用于通过所述第二操作选项接收到针对指定业务规则生成测试用例的请求时，为该指定业务规则生成测试用例。

另外，该装置还可以包括：

规则判断单元，用于确定所述业务规则是否为包含特征值的结构化规则；

第一测试脚本生成单元，用于如果是，则根据所述特征值从真实的业务数据中筛选出测试数据，并根据所述测试数据，为所述业务规则对应的测试用例生成测试脚本。

或者，还可以包括：

第二测试脚本生成单元，用于如果是接收为非结构化业务规则对应测试用例提交的测试数据，并根据所述测试数据为所述测试用例生成对应的测试脚本.

再者，还可以包括：

测试脚本执行单元，用于通过在预置的测试平台中执行所述测试脚本，获得测试结果。

具体实现时，所述操作选项提供单元具体可以用于：

提供用于从已有产品中进行选择的操作选项；

所述配置信息接收单元具体可以用于：

通过所述操作选项接收选择的目标已有产品信息；

提供所述目标已有产品关联的配置信息，以及用于在该目标已有产品关联的配置信息基础上进行编辑的操作选项，以便通过在目标已有产品关联的配置信息基础上进行编辑的方式，确定当前产品的配置信息。

或者，所述操作选项提供单元具体可以用于：

提供用于对产品进行全新定制的操作选项，以及可选的产品需求文档模板以及页面信息；

所述配置信息接收单元具体可以用于：

通过所述操作选项接收选择的目标产品需求文档模板，以及所涉及的目标页面；

提供所述目标页面关联的基础组件信息集合，以及用于对所述基础组件进行编辑的操作选项，以便通过对所述目标页面关联的基础组件信息进行编辑的方式，确定当前产品的组件集以及业务规则集。

从另一角度而言，所述操作选项提供单元具体可以用于：

提供用于进行组件集编辑的操作选项，以便根据组件集编辑结果生成组件树；其中，所述用于进行组件集编辑的操作选项包括：从已知组件中进行选择的操作选项，用于增加新组件的操作选项，以及用于对原有组件进行定制的操作选项。

另外，所述操作选项提供单元具体还可以用于：

在接收到对所述组件树中的目标组件执行的操作后，提供用于对该目标组件进行业务规则编辑的界面，以便确定该目标组件对应的业务规则集。

其中，所述用于对该目标组件进行业务规则编辑的界面中包括：用于对组件前置条件、组件操作方式和/或组件关联关系信息进行配置的操作选项，以便根据所述组件前置条件、操作方式信息生成结构化的业务规则信息，其中，所述前置条件用于对业务规则的特征值信息进行配置。

另外，该装置还可以包括：

搜索单元，用于提供用于进行搜索的操作选项，所述搜索的维度包括：组件类别、组件名称、支持的终端、平台、页面、组件状态。

与实施例二相对应，本申请实施例还提供了一种产品测试信息生成装置，参见图6，该装置可以包括：

操作选项提供单元601，用于提供用于对产品需求进行配置的操作选项；

配置信息接收单元602，用于通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的组件集以及各组件下的业务规则集；

测试用例生成单元603，用于根据所述配置信息，以及预先获得的业务之间的拓扑关系信息，生成用于进行产品测试的测试用例。

具体实现时，该装置还可以包括：

规则判断单元，用于确定所述业务规则是否为包含特征值的结构化规则；

测试脚本生成单元，用于如果是，则根据所述特征值从真实的业务数据中筛选出测试数据，并根据所述测试数据，为所述业务规则对应的测试用例生成测试脚本。

另外，与实施例一相对应，本申请实施例还提供了一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供用于对产品需求进行配置的操作选项；

通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的产品需求文档模板、组件集以及各组件下的业务规则集；

根据所述配置信息生成产品需求文档。

与实施例二相对应，本申请实施例还提供了一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供用于对产品需求进行配置的操作选项；

通过所述操作选项接收产品需求配置信息，所述配置信息中包括产品所需的产品需求文档模板、组件集以及各组件下的业务规则集；

根据所述配置信息，以及预先获得的业务之间的拓扑关系信息，生成用于进行产品测试的测试用例。

其中，图7示例性的展示出了计算机系统的架构，具体可以包括处理器710，视频显示适配器711，磁盘驱动器712，输入/输出接口713，网络接口714，以及存储器720。上述处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720之间可以通过通信总线730进行通信连接。

其中，处理器710可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器720可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器720可以存储用于控制计算机系统700运行的操作系统721，用于控制计算机系统700的低级别操作的基本输入输出系统(bios)。另外，还可以存储网页浏览器723，数据存储管理系统724，以及产品需求文档处理系统725等等。上述产品需求文档处理系统725就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器720中，并由处理器710来调用执行。

输入/输出接口713用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口714用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。

总线730包括一通路，在设备的各个组件(例如处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720)之间传输信息。

另外，该计算机系统700还可以从虚拟资源对象领取条件信息数据库741中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，存储器720，总线730等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。在实际应用过程中，可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的，本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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