一种测试方案生成方法及系统与流程

1.本技术涉及软件测试技术领域，更具体地说，涉及一种测试方案生成方法及系统。


背景技术：

2.测试方案是软件测试过程的主要依据。传统的测试方案生成方式包括两种，一种是以测试人员经验和专业技术能力为主，通过对软件产品测试需求的人工分析圈定测试范围，制定测试策略；另一种是借助系统生成测试方案的思路，主要通过新老测试方案比对的方式生成，且主要针对测试案例的继承。
3.传统的测试方案主要依靠测试人员的经验来制定，对测试人员的个人能力水平依赖程度较高，往往需要花费大量的准备时间却很难得到完备可靠的测试方案。
4.现有的测试方案，主要通过对比和补充差集方式实现测试方案的生成，缺少对系统资产的体系性建设和充分运用，测试方案聚焦于测试范围和测试用例的生成，覆盖内容具有局限性。并且现有技术生成测试方案的颗粒度较粗，在方案生成时无法实现资产完整继承。
5.因此，现有生成测试方案的方式的局限性低，且完整性低。


技术实现要素：

6.有鉴于此，本技术公开了一种测试方案生成方法及系统，旨在确保测试方案的准确性、全面性和完整性，提高得到测试方案的效率。
7.为了实现上述目的，其公开的技术方案如下：
8.本技术第一方面公开了一种测试方案生成方法，所述方法包括：
9.获取测试需求，所述测试需求由用户输入对应的需求语句得到；
10.将所述测试需求输入至预先建立的资产库模型，得到测试信息集合；所述资产库模型由各个资产元素按照预设构建顺序构建得到；所述测试信息集合用于表征从所述资产库模型抽取出的信息集合与所述测试需求相对应；
11.通过预设模板形式对所述测试信息集合进行输出，得到所述测试需求对应的测试方案并展示。
12.优选的，所述将所述测试需求输入至预先建立的资产库模型，得到测试信息集合，包括：
13.通过预设检索顺序，将所述测试需求输入至预先建立的资产库模型进行检索，并从所述资产库模型中抽取出所述测试需求对应的测试信息集合。
14.优选的，所述测试信息集合包括业务种类信息、分支信息、关联系统信息和数据类型信息，所述通过预设模板形式对所述测试信息集合进行输出，得到所述测试需求对应的测试方案并展示，包括：
15.获取所述测试需求中的名称内容，并基于所述名称内容生成测试方案名称；
16.通过预设模板形式，将所述测试方案名称、所述业务种类信息、所述分支信息、所
述关联系统信息和所述数据类型信息进行输出，得到所述测试需求对应的测试方案并展示。
17.优选的，还包括：
18.对所述数据类型信息进行判定；
19.若所述数据类型信息为预设敏感类型信息，则执行申请敏感数据操作。
20.优选的，在所述通过预设模板形式对所述测试信息集合进行输出，得到所述测试需求对应的测试方案并展示之后，还包括：
21.将所述测试方案作为更新资产，并通过所述更新资产对所述资产库模型进行更新。
22.本技术第二方面公开了一种测试方案生成系统，所述系统包括：
23.获取单元，用于获取测试需求，所述测试需求由用户输入对应的需求语句得到；
24.输入单元，用于将所述测试需求输入至预先建立的资产库模型，得到测试信息集合；所述资产库模型由各个资产元素按照预设构建顺序构建得到；所述测试信息集合用于表征从所述资产库模型抽取出的信息集合与所述测试需求相对应；
25.输出单元，用于通过预设模板形式对所述测试信息集合进行输出，得到所述测试需求对应的测试方案并展示。
26.优选的，所述输入单元，具体用于：
27.通过预设检索顺序，将所述测试需求输入至预先建立的资产库模型进行检索，并从所述资产库模型中抽取出所述测试需求对应的测试信息集合。
28.优选的，所述输出单元，包括：
29.获取模块，用于获取所述测试需求中的名称内容，并基于所述名称内容生成测试方案名称；
30.输出模块，用于通过预设模板形式，将所述测试方案名称、所述业务种类信息、所述分支信息、所述关联系统信息和所述数据类型信息进行输出，得到所述测试需求对应的测试方案并展示。
31.优选的，还包括：
32.判定模块，用于对所述数据类型信息进行判定；
33.执行模块，用于若所述数据类型信息为预设敏感类型信息，则执行申请敏感数据操作。
34.优选的，还包括：
35.更新单元，用于将所述测试方案作为更新资产，并通过所述更新资产对所述资产库模型进行更新。
36.经由上述技术方案可知，获取测试需求，测试需求由用户输入对应的需求语句得到，将测试需求输入至预先建立的资产库模型，得到测试信息集合，资产库模型由各个资产元素按照预设构建顺序构建得到，测试信息集合用于表征从资产库模型抽取出的信息集合与测试需求相对应，通过预设模板形式对测试信息集合进行输出，得到测试需求对应的测试方案并展示。通过上述方案，无需通过测试人员的经验来制定测试方案，减少了对测试人员的经验的依靠，并且以较为完善的资产库模型，将测试需求输入至资产库模型中，按照预设检索方式自动抽取出与测试需求相对应的测试信息集合并以模板化形式将进行输出，得
到模板化的测试方案，确保测试方案的准确性、全面性和完整性，提高得到测试方案的效率。
附图说明
37.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
38.图1为本技术实施例公开的一种测试方案生成方法的流程示意图；
39.图2为本技术实施例公开的构建资产库模型过程的示意图；
40.图3为本技术实施例公开的测试需求输入至资产库模型进行检索，并抽取出测试需求对应的测试信息集合的过程的示意图；
41.图4为本技术实施例公开的通过预设模板形式得到测试需求对应的测试方案的示意图；
42.图5为本技术实施例公开的测试方案生成系统的运行机制图；
43.图6为本技术实施例公开的一种测试方案生成系统的结构示意图。
具体实施方式
44.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
45.在本技术中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
46.由背景技术可知，现有生成测试方案的方式的局限性低，且完整性低。
47.为了解决上述问题，本技术实施例公开了一种测试方案生成方法及系统，无需通过测试人员的经验来制定测试方案，减少了对测试人员的经验的依靠，并且以较为完善的资产库模型，将测试需求输入至资产库模型中，按照预设检索方式自动抽取出与测试需求相对应的测试信息集合并以模板化形式将进行输出，得到模板化的测试方案，确保测试方案的准确性、全面性和完整性，提高得到测试方案的效率。具体实现方式通过下述实施例进行说明。
48.参考图1所示，为本技术实施例公开的一种测试方案生成方法的流程示意图，该测试方案生成方法主要包括入如下步骤：
49.s101：获取测试需求，测试需求由用户输入对应的需求语句得到。
50.其中，测试需求即为用户需要对软件产品、软件项目等进行测试的需求。
51.在测试活动中，测试需求的需求语句包括测试时间、所需人数、测试环境、测试中
需要的技能、相应的背景知识、测试中可能遇到的风险等等，只有获取到测试需求后才能决定如何进行软件测试。
52.s102：将测试需求输入至预先建立的资产库模型，得到测试信息集合；资产库模型由各个资产元素按照预设构建顺序构建得到；测试信息集合用于表征从资产库模型抽取出的信息集合与测试需求相对应。
53.在s102中，通过预设检索顺序，将测试需求输入至预先建立的资产库模型进行检索，并从资产库模型中抽取出测试需求对应的测试信息集合。
54.预设检索顺序为自顶向下的顺序，通过自顶向下的检索顺序将测试需求输入至资产库模型进行检索，逐级检索至视图元素级。
55.视图元素级即为最小视图因子，不能再分解成更细颗粒的视图。视图作为资料资产，本身里面也可以包含图表，多个层级，关联其他文件视图。元素级即为最小单位的意思。
56.构建资产库模型的过程结合图2进行如下说明：
57.图2中，资产库模型包括视图元素bv1e1、视图元素bv1e2、视图元素bvnen、视图元素tv1e1、视图元素tv1e2、视图元素tvnen、视图元素dv1e1、视图元素dv1e2、视图元素dvnen、视图元素cv1e1、视图元素cv1e2和视图元素cvnen、业务视图bv1、业务视图bvn、技术视图tv1、技术视图tvn、数据视图dv1、数据视图dvn、配置视图cv1、配置视图cvn、业务视图集群bv
‑
group、技术视图集群tv
‑
group、数据视图集群dv
‑
group、配置视图集群cv
‑
group、系统级视图群集sv
‑
group、领域级视图群集fv
‑
group等。
58.通过自底向上归集的顺序进行资产库模型建设，资产库模型中包括系统级视图群集sv
‑
group、领域级视图群集fv
‑
group等。资产库模型建立是从建设每一个视图因子开始，在系统建设、优化的每一次项目中、开展研发和测试工作的同时，进行各类系统(如支付类系统、外联通道系统等)资产相关的视图制作，从底层开始积累资产元素，逐步向上累积建设，最后形成整个资产库模型。
59.在资产库模型中存储的资料统一都称之为视图，这个视图可以是文件、矩阵、思维导图、架构图等等，每一个视图都是有效利用的资源，可以作为生成测试方案的输入内容，称为视图因子。
60.通过预设检索顺序，将测试需求输入至预先建立的资产库模型进行检索，并从资产库模型中抽取出测试需求对应的测试信息集合的过程，可参考图3所示。
61.图3中，预设检索顺序为自顶向下的检索顺序，从资产库模型中抽取出测试需求对应的测试信息集合，测试信息集合即为测试需求所命中的信息集合。
62.预设检索顺序为自顶向下抽取的检索顺序，从资产库模型中抽取出测试需求，抽取过程涉及到领域级视图群集fv
‑
group、系统级视图群集sv
‑
group、业务场景、交易分支、数据、环境、配置文档、业务场景1、业务场景n、交易分支1、交易分支n、测试类数据集、铺底类数据集、环境配置文档、脱敏规则文档、流程案例1、流程案例2、流程案例n、交易案例1、交易案例2、交易案例n、测试数据1、测试数据2、测试数据n、执行策略、数据使用规则、参数配置文档等。
63.其中，领域级视图群集fv
‑
group、系统级视图群集sv
‑
group、业务场景、交易分支、数据、环境、配置文档、业务场景n、交易分支1、测试类数据集、环境配置文档、流程案例1、流程案例n、交易案例2、测试数据1、测试数据2、执行策略和数据使用规则，均为测试需求输入
至资产库模型进行检索后所命中的数据，命中的数据即为测试信息集合。
64.测试信息集合包括业务种类信息(a1，...an)，程序分支信息(b1，...bn)，关联系统信息(c1，...cn)，数据类型信息(d1，...dn)，测试案例/脚本，以及本次测试需求涉及的配置文档出库等，基于上述信息形成与测试需求相对应的测试信息集合。
65.其中，业务种类信息、程序分支信息、关联系统信息和数据类型信息均为属性项，是根据系统的具体特点进行定义和确定的内容。
66.业务种类信息如汇兑业务、票据业务、查询业务、对账业务等。
67.程序分支信息根据系统代码具体程序设计来分类，如查询分支、记账分支等。
68.关联系统信息比如支付类系统上游关联掌上银行、超级柜台等渠道端系统，下游关联外联通道系统等。
69.数据类型信息如byte、short、int、long等类型信息。
70.s103：通过预设模板形式对测试信息集合进行输出，得到测试需求对应的测试方案并展示。
71.在s103中，获取测试需求中的名称内容，并基于名称内容生成测试方案名称，通过预设模板形式，将测试方案名称、业务种类信息、分支信息、关联系统信息和数据类型信息进行输出，得到测试需求对应的测试方案并展示。
72.对测试信息集合中抽取的主干数据信息以测试方案的文档形式进行输出，测试范围(业务流程、程序分支信息、场景覆盖、异常分析等)以测试方案的文档格式输出，配置库中测试策略执行相关文件合并入测试方案的文档格式输出，用例、脚本、配置文件等以附件形式输出。
73.其中，配置文件是一种计算机文件，可以为一些计算机程序配置参数和初始设置。即对不同对象进行不同配置的文件。
74.具体通过预设模板形式，将测试方案名称、业务种类信息、分支信息、关联系统信息和数据类型信息进行输出的方式如a1
‑
a8所示。
75.a1：以设置格式自动生成文档标识符，作为文档唯一标记。
76.a2：根据项目名称及设定内容自动生成测试方案名称。
77.其中，项目名称作为生成本次测试方案的驱动需求的一部分，为外界输入项(测试需求)得到。
78.a3：根据规范化需求形成测试范围概述。
79.其中，资产库模型作为已有的可视化可检索系统，通过将测试需求输入资产库模块，可视化可检索系统自动整理，形成一个测试范围概述，是一段文字。测试范围概述作为测试方案的一部分，位于文档最开始，其目的是简要的、概括性的介绍本次测试的整体范围。
80.a4：根据抽取数据业务种类信息与程序分支信息先组出交易场景e(a1b1，...anbn)，具体如表1所示。
[0081][0082]
表1
[0083]
其中，业务种类信息包括a1、a2、an等，程序分支信息包括b1、b2、bn等，组出的交易场景e包括a1b1、a2b1、anb1、a1b2、a2b2、anb2、a1bn、a2bn、anbn等。<a1b1>、<a2b2>、<a2bn>和<anbn>等标记为重点覆盖项。
[0084]
标记为重点覆盖项的标记方式可以是通过<>号区分，也可以是标记为其他颜色来区分，具体重点覆盖项的标记方式本技术不做具体限定。
[0085]
a5：根据抽取数据关联系统信息与数据类型组出交易场景f(c1d1，...cndn)，具体如表2所示。
[0086][0087]
表2
[0088]
其中，关联系统信息包括c1、c2
…
cn，数据类信息包括d1、d2
…
dn，<c1d1>、<c2d2>和<cnd1>标记为重点覆盖项。
[0089]
a6：以表格或矩阵图的形式输出具体的测试范围。具体如表3所示。
[0090][0091][0092]
表3
[0093]
其中，交易场景e包括a1b1、a2b2
…
anbn，交易场景f包括c1d1、c2d2
…
cndn。[a1b1c1d1]、[a2b12c2d2]和[anbncnd1]为一级重点覆盖项、{a1b1c2d2}和{a2b2c2d1}为二级重点覆盖项。
[0094]
矩阵图是从多维问题的事件中，找出成对的因素，排列成矩阵图，然后根据矩阵图来分析问题，确定关键点的方法。它是一种通过多因素综合思考、探索问题的方法。从问题事项中照处承兑的因素群，分别排列成行和列，照处其中行与列的相关性或相关程度大小
的一种方法。
[0095]
标记为一级重点覆盖项的标记方式可以是通过[]号区分，也可以是标记为其他颜色来区分，具体一级重点覆盖项的标记方式本技术不做具体限定。
[0096]
标记为二级重点覆盖项的标记方式可以是通过{}号区分，也可以是标记为其他颜色来区分，具体二级重点覆盖项的标记方式本技术不做具体限定。
[0097]
a7：对数据类型信息进行判定，若数据类型信息为预设敏感类型信息，则执行申请敏感数据操作。
[0098]
其中，根据抽取出的数据类型信息，若数据涉及个人信息(如姓名、证件号、住址、电话、账号、密码、邮箱等)、设备密钥(设备主密钥kek、工作密钥pik/mak)、凭证关键信息(二磁、三磁等)等敏感信息，则要申请敏感数据，需列出申请的数据类型。
[0099]
本方案中进行测试方案生成所涉及到的个人信息均提前得到用户授权，数据处理均符合相关法律法规要求。
[0100]
a8：测试需求若涉及测试库案例及脚本，则通过附件的形式进行输出。
[0101]
通过a1
‑
a8进行模板形式输出，得到测试方案，测试方案可参考图4所示。
[0102]
图4中，测试方案包括xxx项目测试方案、测试方案文档标识符、模板版本号、测试范围概述、具体的测试项、共有xxx场景，xxx为重点覆盖项、交易场景e、交易场景f、综上所述:xxx、敏感数据、是否要申请敏感数据、敏感数据类型及使用时间、敏感数据类型包括标识数据、特殊数据等、使用时间为1
‑
3月，脱敏脚本为附件1、审批流程、案例：附件2、脚本：附件3。
[0103]
其中，上述各个“xxx”是根据预设模板形式输出后可自动生成与测试需求对应的内容。
[0104]
交易场景e包括a1b1、a2b2
…
anbn等；交易场景f包括c1d1、c2d2
…
cndn等；项目测试方案是通过测试需求生成的项目名称；[a1b1c1d1]、[a2b12c2d2]和[anbncnd1]为一级重点覆盖项；{a1b1c2d2}和{a2b2c2d1}为二级重点覆盖项；覆盖项包括一级重点覆盖和二级重点覆盖项，覆盖项还包括a1b1cndn、a2b2cndn、anbncndn等。
[0105]
资产库作为已有的可视化可检索系统，将需求按照输入规范输入，系统自动整理，形成一个测试范围概述，是一段文字，测试范围概述作为测试方案的一部分，位于文档最开始，其目的是简要的、概括性的介绍本次测试的整体范围。
[0106]
可选的，在通过预设模板形式对所述测试信息集合进行输出，得到测试需求对应的测试方案并展示之后，将测试方案作为更新资产，并通过更新资产对资产库模型进行更新。
[0107]
在a1
‑
a8基础上可继续对整个资产模型进行持续循环训练。
[0108]
可形成模型训练环(资产库建立
→
测试需求输入
→
测试方案生成
→
测试过程执行
→
资产库刷新)，每当有新测试需求输入时，在测试需求的驱动下，触发模型训练环运转一周，完成一次训练，促成组织级资产库的日趋完善，并有效运用于测试方案的生成，如附图5所示，图5为整个测试方案生成系统的运行机制图。
[0109]
图5中，领域级资产库f、系统级资产库s1、系统级资产库s2、测试需求输入i1、测试需求输入i2、测试方案p1、测试方案p2、群集因子v1、群集因子v2、群集因子vn、测试过程输出o1、测试过程输出o2。
[0110]
图5中，新的测试需求(测试需求输入i1、测试需求输入i2)作为输入项，输入测试方案生成系统，进行逐层检索，生成测试方案(测试方案p1、测试方案p2)，测试方案在测试过程中进行运用后，结合实际经验进行调整，生成测试过程输出(测试过程输出o1、测试过程输出o2)，输出产物(测试方案)作为测试资产(更新资产)，累计、更新到资产库，形成资产利用循环。
[0111]
本技术中阐述的基于测试资产生成测试方案的思路，将资产充分运用于测试执行过程中，最大程度削弱测试质量对人的依赖，并有效提升测试方案的生成速度和质量。
[0112]
本技术实施例中，无需通过测试人员的经验来制定测试方案，减少了对测试人员的经验的依靠，并且以较为完善的资产库模型，将测试需求输入至资产库模型中，按照预设检索方式自动抽取出与测试需求相对应的测试信息集合并以模板化形式将进行输出，得到模板化的测试方案，确保测试方案的准确性、全面性和完整性，提高得到测试方案的效率。
[0113]
基于上述实施例图1公开的一种测试方案生成方法，本技术实施例还对应公开了一种测试方案生成系统，如图6所示，该测试方案生成系统包括获取单元601、输入单元602和输出单元603。
[0114]
获取单元601，用于获取测试需求，测试需求由用户输入对应的需求语句得到。
[0115]
输入单元602，用于将测试需求输入至预先建立的资产库模型，得到测试信息集合；资产库模型由各个资产元素按照预设构建顺序构建得到；测试信息集合用于表征从资产库模型抽取出的信息集合与测试需求相对应。
[0116]
输出单元603，用于通过预设模板形式对测试信息集合进行输出，得到测试需求对应的测试方案并展示。
[0117]
进一步的，输入单元602具体用于通过预设检索顺序，将测试需求输入至预先建立的资产库模型进行检索，并从资产库模型中抽取出测试需求对应的测试信息集合。
[0118]
进一步的，输出单元603包括获取模块和输出模块。
[0119]
获取模块，用于获取测试需求中的名称内容，并基于名称内容生成测试方案名称。
[0120]
输出模块，用于通过预设模板形式，将测试方案名称、业务种类信息、分支信息、关联系统信息和数据类型信息进行输出，得到测试需求对应的测试方案并展示。
[0121]
进一步的，还包括判定单元和执行单元。
[0122]
判定单元，用于对数据类型信息进行判定。
[0123]
执行单元，用于若数据类型信息为预设敏感类型信息，则执行申请敏感数据操作。
[0124]
进一步的，还包括更新单元。
[0125]
更新单元，用于将测试方案作为更新资产，并通过更新资产对资产库模型进行更新。
[0126]
本技术实施例中，无需通过测试人员的经验来制定测试方案，减少了对测试人员的经验的依靠，并且以较为完善的资产库模型，将测试需求输入至资产库模型中，按照预设检索方式自动抽取出与测试需求相对应的测试信息集合并以模板化形式将进行输出，得到模板化的测试方案，确保测试方案的准确性、全面性和完整性，提高得到测试方案的效率。
[0127]
对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描
述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本技术所必须的。
[0128]
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于系统类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0129]
本技术各实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。
[0130]
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
[0131]
对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
[0132]
以上所述仅是本技术的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。