一种测试用例维护方法及装置与流程

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.变更子单元，用于存储所述新增绑定关系，并将所述用例列表导入用例平台进行存储。
39.进一步地，所述变更单元包括：
40.获取子单元，用于当所述当前变更类型为修改类型时，获取与所述思维导图变更文件绑定的原始用例列表；
41.对比子单元，用于对比所述用例列表和所述原始用例列表，得到列表差异数据；
42.变更子单元，用于根据所述列表差异数据对用例平台中的所述原始用例列表进行修改处理。
43.进一步地，所述变更子单元包括：
44.确定模块，用于根据所述列表差异数据确定需要修改的用例、需要删除的用例以及需要新增的用例；
45.修改模块，用于根据所述需要修改的用例、所述需要删除的用例以及所述需要新增的用例对用例平台中的所述原始用例列表进行修改处理。
46.本技术实施例第三方面提供了一种电子设备，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行本技术实施例第一方面中任一项所述的测试用例维护方法。
47.本技术实施例第四方面提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本技术实施例第一方面中任一项所述的测试用例维护方法。
附图说明
48.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本技术的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
49.图1为本技术实施例提供的一种测试用例维护方法的流程示意图；
50.图2为本技术实施例提供的另一种测试用例维护方法的流程示意图；
51.图3为本技术实施例提供的一种测试用例维护装置的结构示意图；
52.图4为本技术实施例提供的另一种测试用例维护装置的结构示意图；
53.图5为本技术实施例提供的一种测试用例维护方法的举例流程示意图。
具体实施方式
54.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。
55.应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本技术的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
56.实施例1
57.请参看图1，图1为本实施例提供了一种测试用例维护方法的流程示意图。其中，该测试用例维护方法包括：
58.s101、接收测试人员上传的思维导图变更文件。
59.s102、根据思维导图变更文件确定当前变更类型。
60.作为一种可选的实施方式，根据思维导图变更文件确定当前变更类型，包括：
61.判断思维导图变更文件是否绑定有对应的用例列表；
62.如果是，则确定当前变更类型为修改类型；
63.如果否，则确定当前变更类型为新增类型。
64.s103、对思维导图变更文件进行解析处理，得到解析文件。
65.s104、根据解析文件生成用例列表。
66.s105、根据用例列表对用例平台的用例进行变更处理。
67.作为一种可选的实施方式，根据用例列表对用例平台的用例进行变更处理，包括：
68.当当前变更类型为新增类型时，将思维导图变更文件与用例列表进行绑定，得到
新增绑定关系；
69.存储新增绑定关系，并将用例列表导入用例平台进行存储。
70.作为一种可选的实施方式，根据用例列表对用例平台的用例进行变更处理，包括：
71.当当前变更类型为修改类型时，获取与思维导图变更文件绑定的原始用例列表；
72.对比用例列表和原始用例列表，得到列表差异数据；
73.根据列表差异数据对用例平台中的原始用例列表进行修改处理。
74.本实施例中，该方法的执行主体可以为计算机、服务器等计算装置，对此本实施例中不作任何限定。
75.在本实施例中，该方法的执行主体还可以为智能手机、平板电脑等智能设备，对此本实施例中不作任何限定。
76.可见，实施本实施例所描述的测试用例维护方法，能够对xmind文件采用git管理维护，易于管理；在文件产生变动时，自动按照预设模板对xmind文件进行解析，并将解析结果导入到统一的测试用例管理平台。同时，该方法不需要测试人员二次编写测试用例，也不需要测试人员在后期对xmind进行持续维护更新。可见，该方法能够大大提高测试效率，且导入用例平台后实现测试用例的共享，在使得测试执行过程以及测试报告产出都可以直观查看。
77.实施例2
78.请参看图2，图2为本实施例提供了一种测试用例维护方法的流程示意图。其中，该测试用例维护方法包括：
79.s201、接收测试人员上传的思维导图变更文件。
80.s202、判断思维导图变更文件是否绑定有对应的用例列表，若是，则执行步骤s203；若否，则执行步骤s204。
81.s203、确定当前变更类型为修改类型，并执行步骤s205～s206。
82.s204、确定当前变更类型为新增类型，并执行步骤s205～s206。
83.s205、对思维导图变更文件进行解析处理，得到解析文件。
84.s206、根据解析文件生成用例列表，当当前变更类型为新增类型时，触发执行步骤s207～s208；当当前变更类型为修改类型时，触发执行步骤s209～s212。
85.s207、当当前变更类型为新增类型时，将思维导图变更文件与用例列表进行绑定，得到新增绑定关系。
86.s208、存储新增绑定关系，并将用例列表导入用例平台进行存储。
87.s209、当当前变更类型为修改类型时，获取与思维导图变更文件绑定的原始用例列表。
88.s210、对比用例列表和原始用例列表，得到列表差异数据。
89.s211、根据列表差异数据确定需要修改的用例、需要删除的用例以及需要新增的用例。
90.s212、根据需要修改的用例、需要删除的用例以及需要新增的用例对用例平台中的原始用例列表进行修改处理。
91.目前，测试人员都习惯执行使用xmind等思维导图工具来编写测试用例，因为思维导图形式思路清晰，编写方便，实际使用过程中，每个人写的用例都不一样，缺少具体的格
式及规范。同时，采用这种方式维护用例通常直接在xmind源文件上做标记，缺乏详细的用例执行记录，xmind中的部分信息无法共享，且xmind文件维护也大多再本地维护，数据留存以及数据共享上存在较大的问题，同时测试完成没有具体的依据以及报告产生。一般情况下都会要求所有的case都要导入到系统统一维护，现有系统对于xmind的支持并不完善，很多都不支持xmind，或者对于导入后的用例都是错乱的，没有测试步骤以及预期结果等等。对于xmind后续的维护，以及与现有系统中用例的联动也存在较多有很多的问题：一次性导入并不支持后续联动。为了解决这一问题，该方法提出了一种基于xmind生成用例的方法，具体能够通过制定合适的xmind编写用例规范，使用gitlab管理xmind源文件，同步gitlab更新状态，触发xmind文件解析成用例，生成测试用例到平台侧。
92.本实施例中，该方法的创新点如下：
93.(1)使用git进行维护xmind，易于管理维护共享；
94.(2)hook触发方式能够实现文件持续更新迭代同步平台用例。
95.本实施例中，结合图5说明如下：
96.(1)xmind文件产生变更：测试人员对思维脑图进行编辑。
97.(2)触发hook：git上预设一个hook为变更api，上传文件或者变更文件时候，会触发该api。
98.(3)确定该次变更是xmind的新增还是修改：xmind初次上传时候，会又与用例的绑定的关系，根据绑定关系判断是修改的原来的xmind还是新增。
99.(4)如果是新增：
100.①
解析新增的xmind文件；
101.②
将解析出的xmind文件与用例列表做绑定，做法主要是为了后续判断xmind关系设定；
102.③
并将用例导入到统一的用例平台，便于统一维护管理以及数据的留存共享。
103.(5)检测到该xmind已经又用例列表对应关系，说明本次是修改操作：
104.①
平台对文件进行解析生成用例列表；
105.②
新生成的用例列表与原有的用例列表相比较；
106.③
通过上述步骤
②
得到比较差异。
107.在本实施例中，上述差异中存在：
108.①
旧表中又但是新表中没有，则说明该用例为舍弃的用例，同步用例平台执行删除用例操作；
109.②
旧表，新表中都存在，但部分内容不一样，则说明该用例为修改维护的用例，同步维护更新到用例平台；
110.③
新表中存在，但是旧表中没有，说明该用例为新增用例，新增至用例平台。
111.在本实施例中，对平台解析部分进行说明如下：
112.①
解析xmind，需要根据情况首先预设xmind模板，一般情况下应该统一维护一套规则来进行编写，也可以根据实际需要支持不通情况，解析时候通过xmind文件类型进行采用不同的模板进行解析；
113.②
获取xmind中根节点；
114.③
获取根目录到叶子节点的所有路径：一条路径可以简单理解为字符列表，每个
字符对应用例不同的属性；
115.④
遍历路径，得到所有用例。
116.本实施例中，该方法的执行主体可以为计算机、服务器等计算装置，对此本实施例中不作任何限定。
117.在本实施例中，该方法的执行主体还可以为智能手机、平板电脑等智能设备，对此本实施例中不作任何限定。
118.可见，实施本实施例所描述的测试用例维护方法，能够对xmind文件采用git管理维护，易于管理；在文件产生变动时，自动按照预设模板对xmind文件进行解析，并将解析结果导入到统一的测试用例管理平台。同时，该方法不需要测试人员二次编写测试用例，也不需要测试人员在后期对xmind进行持续维护更新。可见，该方法能够大大提高测试效率，且导入用例平台后实现测试用例的共享，在使得测试执行过程以及测试报告产出都可以直观查看。
119.实施例3
120.请参看图3，图3为本实施例提供的一种测试用例维护装置的结构示意图。如图3所示，该测试用例维护装置包括：
121.接收单元310，用于接收测试人员上传的思维导图变更文件；
122.确定单元320，用于根据思维导图变更文件确定当前变更类型；
123.解析单元330，用于对思维导图变更文件进行解析处理，得到解析文件；
124.生成单元340，用于根据解析文件生成用例列表；
125.变更单元350，用于根据用例列表对用例平台的用例进行变更处理。
126.本实施例中，对于测试用例维护装置的解释说明可以参照实施例1或实施例2中的描述，对此本实施例中不再多加赘述。
127.可见，实施本实施例所描述的测试用例维护装置，能够对xmind文件采用git管理维护，易于管理；在文件产生变动时，自动按照预设模板对xmind文件进行解析，并将解析结果导入到统一的测试用例管理平台。同时，该装置不需要测试人员二次编写测试用例，也不需要测试人员在后期对xmind进行持续维护更新。可见，该装置能够大大提高测试效率，且导入用例平台后实现测试用例的共享，在使得测试执行过程以及测试报告产出都可以直观查看。
128.实施例4
129.请参看图4，图4为本实施例提供的一种测试用例维护装置的结构示意图。如图4所示，该测试用例维护装置包括：
130.接收单元310，用于接收测试人员上传的思维导图变更文件；
131.确定单元320，用于根据思维导图变更文件确定当前变更类型；
132.解析单元330，用于对思维导图变更文件进行解析处理，得到解析文件；
133.生成单元340，用于根据解析文件生成用例列表；
134.变更单元350，用于根据用例列表对用例平台的用例进行变更处理。
135.作为一种可选的实施方式，确定单元320包括：
136.判断子单元321，用于判断思维导图变更文件是否绑定有对应的用例列表；
137.确定子单元322，用于当判断出思维导图变更文件绑定有对应的用例列表时，则确
定当前变更类型为修改类型；
138.确定子单元322，还用于当判断出思维导图变更文件未绑定有对应的用例列表时，则确定当前变更类型为新增类型。
139.作为一种可选的实施方式，变更单元350包括：
140.绑定子单元351，用于当当前变更类型为新增类型时，将思维导图变更文件与用例列表进行绑定，得到新增绑定关系；
141.变更子单元352，用于存储新增绑定关系，并将用例列表导入用例平台进行存储。
142.作为一种可选的实施方式，变更单元350包括：
143.获取子单元353，用于当当前变更类型为修改类型时，获取与思维导图变更文件绑定的原始用例列表；
144.对比子单元354，用于对比用例列表和原始用例列表，得到列表差异数据；
145.变更子单元352，用于根据列表差异数据对用例平台中的原始用例列表进行修改处理。
146.作为一种可选的实施方式，变更子单元352包括：
147.确定模块，用于根据列表差异数据确定需要修改的用例、需要删除的用例以及需要新增的用例；
148.修改模块，用于根据需要修改的用例、需要删除的用例以及需要新增的用例对用例平台中的原始用例列表进行修改处理。
149.本实施例中，对于测试用例维护装置的解释说明可以参照实施例1或实施例2中的描述，对此本实施例中不再多加赘述。
150.可见，实施本实施例所描述的测试用例维护装置，能够对xmind文件采用git管理维护，易于管理；在文件产生变动时，自动按照预设模板对xmind文件进行解析，并将解析结果导入到统一的测试用例管理平台。同时，该装置不需要测试人员二次编写测试用例，也不需要测试人员在后期对xmind进行持续维护更新。可见，该装置能够大大提高测试效率，且导入用例平台后实现测试用例的共享，在使得测试执行过程以及测试报告产出都可以直观查看。
151.本技术实施例提供了一种电子设备，包括存储器以及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述电子设备执行本技术实施例1或实施例2中的测试用例维护方法。
152.本技术实施例提供了一种计算机可读存储介质，其存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行本技术实施例1或实施例2中的测试用例维护方法。
153.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本技术的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也
可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
154.另外，在本技术各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
155.所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
156.以上所述仅为本技术的实施例而已，并不用于限制本技术的保护范围，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
157.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应所述以权利要求的保护范围为准。
158.需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。