一种测试用例生成方法、装置及设备与流程

1.本发明涉及软件设计技术领域，一种测试用例生成方法、装置及设备。


背景技术：

2.随着互联网技术的不断发展，软件开发越来越多，在快速迭代的节奏下，如何开展高效、有价值的测试，确保业务功能正常是测试的一大挑战。另外，软件规模与复杂度迅速增长，自动化测试的应用也越来越广泛。自动化测试是一种机器执行的测试行为，然而在自动化测试的过程中通常需要使用到大量的测试用例，并且不同的业务场景往往需要不同的测试用例。因此，对于测试用例的生成就显得尤为重要。测试用例(test case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。
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.图1为本发明提供的测试用例生成方法流程示意图；
43.图2为本发明提供的测试用例生成方法中思维导图模板示意图；
44.图3为本发明提供的测试用例生成方法对应的思维导图示意图；
45.图4为本发明提供的测试用例生成装置结构示意图；
46.图5为本发明提供的测试用例生成设备结构示意图。
具体实施方式
47.为了便于清楚描述本发明实施例的技术方案，在本发明的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一阈值和第二阈值仅仅是为了区分不同的阈值，并不对其先后顺序进行限定。本领域技术人员可以
理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
48.需要说明的是，本发明中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本发明中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
49.本发明中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b的情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，a和b的结合，a和c的结合，b和c的结合，或a、b和c的结合，其中a，b，c可以是单个，也可以是多个。
50.现有技术中，app软件的测试过程中，要提高app的使用体验，需要单独面向用户实际使用场景来设计测试用例，但是在未知具体应用场景的情况下，测试人员根据个人经验模拟用户的使用过程，其设计的场景测试用例不一定能对事件流进行全面的分析，导致设计出来的用例不完整、不准确或遗漏重点高频行为，而测试方案不准确；测试用例的设计水平，往往和测试人员的工作经验有很大关系，在测试设计人员经验不足的情况下，测试用例的覆盖率难以保证。
51.对此，本发明提供一种测试用例生成方案。可以解决黑盒测试用例测试点覆盖不全面、逻辑不清晰、评审难以发现测试点遗漏的问题，缩短了测试用例开发周期，提高了测试用例编写、评审效率。
52.接下来，结合附图对本说明书实施例提供的方案进行说明：
53.图1为本发明提供的测试用例生成方法流程示意图，如图1所示，该流程可以包括以下步骤：
54.步骤110：获取思维导图模板，并在所述思维导图模板的一级子节点录入所述思维导图模板对应的测试点以及测试场景；所述测试场景中至少包括功能测试场景。
55.思维导图(the mind map)，又名心智导图、脑图以及脑力激荡图等，是一种表达发散性思维的有效图形。可以是围绕一个中心主题对分支节点进行搭建的操作过程。是表达发散性思维的有效图形思维工具，它简单却又高效，是一种实用性的思维工具。思维导图有很多展现格式常见的有逻辑图，树状组图，鱼骨图等。
56.其中，测试场景至少可以包括测试模式场景以及应用领域场景；所述测试模式场景可以包括：功能测试场景、兼容性测试场景、安全测试场景、长期测试场景以及上下电测试场景等等，即本方案中考虑了多种场景，甚至考虑是否涉及兼容性测试、安全测试、长期测试等场景，为能够覆盖不同的测试场景以及具体应用领域场景设计场景覆盖率高的测试用例，从而提高软件质量。
57.进一步地，思维导图模板可以结合图2进行说明：
58.图2为本发明提供的测试用例生成方法中思维导图模板示意图。如图2所示，以eflash启动测试为例，测试内容为eflash三种不同启动方式的测试，根据思维导图模板，在
规格中找到对应的测试点、用户场景、功能测试、兼容性测试、安全测试、长期测试、上下电测试等等。其中，测试点可以是具体的用户需求，图2中的ordr可以表示测试点，图2中的ordr支持三种启动模式，分别为：sram、flash、bootrom，用户场景中可以包括：“调试时从sram启动”、“嵌入式设备启动”以及“从flash启动，引导flash行为”；思维导图模板中除了录入ordr、用户场景之外，还可以录入启动模式、上下电测试、长期测试、安全测试以及兼容性测试等场景。
59.步骤120：按照预设分解规则，将每个所述测试点分解为具有单一属性的测试点集合；所述测试点集合中的每一个小测试点对应一个测试场景。
60.在功能测试下将每个测试点分解成更小的测试点，直到分解成一个单一的属性为止。其中，分解原则可以是测试场景的预设维度，也可以是实际使用需求的分类等等，具体地，可以根据实际使用场景设定预设分解规则，例如：根据软件开发指南、用户手册等文档中用户需求或者产品功能，对每个测试点进行分解。单一属性可以理解为将测试点分解为最小维度的小测试点，例如：用于接口测试的测试点，每个接口对应多个参数，那么对测试点进行分解时，可以先将测试点分解为接口对应的测试点，随后将测试点继续分解为每个参数对应的测试点。维度表示为：接口-参数。将测试点分解为最小维度(即参数)对应的小测试点。
61.步骤130：基于所述测试点集合，生成初始测试用例。
62.初始测试用例可以是基于最开始在一级子节点录入软件规格中模块对应的测试点以及测试场景生成的。即初始测试用例可以是需要测试验证的测试用例。在实际应用中，理想情况下，如果起初录入的测试点以及测试场景足够详细，那么初始测试用例就可以作为目标测试用例。但是实际应用中，初始测试用例极有可能不能覆盖所有的测试场景，通过思维导图，可以直观确定遗漏的测试场景，可以及时对测试场景进行补充完善，如步骤140。
63.步骤140：若所述初始测试用例的设计场景未覆盖预设的全部测试点以及测试场景，则基于标准文件以及历史经验数据，补充新的设计场景，直至覆盖预设的全部所述测试点以及所述测试场景，生成目标测试用例。
64.检查测试用的设计场景是否已经覆盖软件规格中的全部测试点和测试场景并补充。步骤140中，预设的全部测试点可以是软件规格中的全部测试点，预设的测试场景可以是标准文件中的测试场景，也可以是历史经验数据中对应的测试场景，其中，更为具体地，标准文件可以是预先获取的软件开发指南、用户手册、指导文档等等。历史经验数据可以是开发人员或者专家的历史经验数据，可以包括：测试用例评审标准、历史测试用例包含的测试场景等等数据。
65.在初始测试用例的基础上，基于标准文件以及历史经验数据可以对测试场景进行补充，从而提高测试用例的场景覆盖率。
66.图1中的方法，通过获取思维导图模板，并在思维导图模板的一级子节点录入思维导图模板对应的测试点以及测试场景；按照预设分解规则，将每个测试点分解为具有单一属性的测试点集合；基于测试点集合，生成初始测试用例；若初始测试用例的设计场景未覆盖标准文件中全部测试点以及测试场景，则基于标准文件以及历史经验数据，补充新的设计场景，直至覆盖全部测试点以及测试场景，生成目标测试用例。基于思维导图模板进行测试用例的生成，对测试点进行分解之后，每个小测试点对应一个测试场景，因此，可以快速
确定测试用例覆盖的所有场景以及测试点，逻辑性强，易发现遗漏的测试场景并及时进行补充，从而提高测试用例的场景覆盖率，缩短了测试用例的开发周期，从而从根本上提高软件质量。
67.基于图1的方法，本说明书实施例还提供了该方法的一些具体实施方式，下面进行说明。
68.在具体应用过程中，判断初始用例的测试场景是否覆盖预设的测试点以及测试场景时，可以先基于标准文件进行判断。然后再基于历史经验数据继续判断，接下来，对具体的判断过程进行说明：
69.若所述初始测试用例的设计场景未覆盖预设的全部测试点以及测试场景，则基于标准文件以及历史经验数据，补充新的设计场景，直至覆盖预设的全部所述测试点以及所述测试场景，生成目标测试用例之前，还可以包括：
70.判断所述初始测试用例中的设计场景是否覆盖软件规格中的全部测试点以及标准文件中全部测试场景；所述标准文件为预先获取的文件，所述标准文件中至少包含需要涵盖的测试场景；所述历史经验数据至少包括相关用户的历史应用场景数据；
71.若所述初始测试用例中的设计场景覆盖软件规格中的全部测试点以及标准文件中全部测试场景，则基于历史经验数据补充设计场景，直至覆盖预设的全部所述测试点以及所述测试场景，生成目标测试用例；
72.若所述初始测试用例中的设计场景既能覆盖软件规格中的全部测试点，又能覆盖标准文件以及历史经验数据中全部测试场景，则将所述初始测试用例确定为目标测试用例。
73.上述实现过程中，基于标准文件补充设计场景，补充的可以是标准文件中未被初始测试用例对应的测试场景覆盖的测试场景，即初始用例对应的测试场景中没有，但是标准文件中存在的测试场景，将其补充至思维导图中，形成新的测试用例。同样的思路，基于历史经验数据补充设计场景，补充的可以是历史经验数据中未被初始测试用例对应的测试场景覆盖的测试场景，即初始用例对应的测试场景中没有，但是历史经验数据中存在的测试场景，将其补充至思维导图中，形成新的测试用例。
74.若标准文件以及历史经验数据中均存在未被初始测试用例对应的测试场景覆盖的测试场景，则将标准文件以及历史经验数据中未被覆盖的测试场景均添加至思维导图中，形成新的测试用例。
75.若初始测试用例对应的测试场景覆盖了标准文件以及历史经验数据中所有的测试场景，覆盖了软件规格中的全部测试点，则可以将初始测试用例作为目标测试用例。
76.通过上述实现方法，可以基于标准文件以及历史经验数据对测试场景进行补充完善，从而提高测试用例的场景覆盖率。
77.采用本技术的方案，基于思维导图模板，生成测试用例时，可以结合图3进行说明：
78.图3为本发明提供的测试用例生成方法对应的思维导图示意图。如图3所示，以eflash启动测试为例，测试内容为eflash三种不同启动方式的测试。具体配置可以结合表1进行说明：
79.表1.启动配置表
80.boot0(pad)boot[1:0](optb)boot_sel(optb)rdpboot from
0xxb0:from pad0/1main memory11xb0:from pad0/1boot memory10xb0:from pad0/1sramxx0b1:from optionbyte0/1main memoryx11b1:from optionbyte0/1boot memoryx01b1:from optionbyte0/1sramxxxbx2main memory
[0081]
用户场景中可以包括：“调试时从sram启动”、“嵌入式设备启动”以及“从flash启动，引导flash行为”；思维导图模板中除了录入ordr、用户场景之外，还可以录入启动模式、上下电测试、长期测试、安全测试以及兼容性测试等场景。在启动功能测试下，结合表1以及图3，启动功能测试下，可以包含三种启动方式：sram启动、flash启动以及bootrom启动。其中，在sram启动下：
[0082]
boot0(pad)＝1，boot[1:0](optb)＝2，boot_sel(optb)位＝0，rdp＝0/1，启动成功。
[0083]
boot0(pad)＝0，boot[1:0](optb)＝1，boot_sel(optb)位＝0，rdp＝0/1，启动成功；
[0084]
flash为空，sram不为空，设置从flash启动，从sram启动，启动成功。
[0085]
在flash启动下：
[0086]
boot0(pad)＝0，boot[1:0](optb)＝0，boot_sel(optb)位＝0,rdp＝0/1，启动成功；
[0087]
boot0(pad)＝1，boot[1:0](optb)＝0，boot_sel(optb)位＝1,rdp＝0/1，启动成功；
[0088]
boot0(pad)＝1，boot[1:0](optb)＝3，boot_sel(optb)位＝1,rdp＝2，启动成功。
[0089]
bootrom启动下：
[0090]
boot0(pad)＝1，boot[1:0](optb)＝2，boot_sel(optb)位＝0,rdp＝0/1，启动成功；
[0091]
boot0(pad)＝1，boot[1:0](optb)＝3，boot_sel(optb)位＝1,rdp＝0/1，启动成功。
[0092]
上述启动功能模式中，每一种启动方式都对应有相应的配置信息。思维导图中，除了启动功能测试场景，还包括其他场景，例如：上下电测试场景中，启动过程中下电，再上电，能够再次正常启动，不出现启动失败等异常。再长期测试中，长期静置后，可以再次正常启动。安全测试场景则主要在读写保护中应用。
[0093]
本说明书的实施例中，在功能测试下将每个测试点分解成更小的测试点，直到分解成一个单一的属性为止。具体地，在本实施例中，可以根据规格说明书、用户手册等资料分解成更小的测试点，选择适用的黑盒测试用例方法，构造测试数据，梳理测试步骤，写出预期结果。其中，黑盒测试用例方法可以包括：等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法以及场景法等等，在实际应用中，可以根据实际需求选择需要的黑盒测试用例方法，对此，本说明书不作具体限定。
[0094]
根据分解出来的测试点和用户手册中的相关信息，设计具体的测试数据，写出预
期结果。检查测试用的设计场景是否已经覆盖软件规格中的全部测试点和测试场景，并补充。
[0095]
具体地，根据分解出来的测试点和用户手册中的相关信息，检查是否已经覆盖所有的规格，然后再设计具体的测试数据，写出预期结果。考虑是否涉及兼容性测试、安全测试、长期测试等场景。具体地，可以基于开发人员或其他专家的历史经验数据确定需要补充的相关场景。测试用例生成之后，可以进行测试用例评审，完善并补充测试用例场景，具体地，评审时可以基于se和开发等相关人员的历史经验数据进行自动评审，也可以找对应的se和开发等相关人员评审，根据评审结果，补充完善相关测试用例场景。最后根据输出的思维导图分支，生成目标测试用例，具体地，在所述思维导图模板中添加了新的设计场景之后，输出思维导图分支，生成目标测试用例；一个所述思维导图分支对应一种所述测试场景；根据所述目标测试用例的格式，将所述思维导图中的测试场景存入测试用例表格中。例如：图3中启动功能测试中的sram启动可以对应一个分支，该分支对应sram启动测试场景。
[0096]
上述实施例中，结合思维导图设计、生成黑盒测试用例，解决了现有技术中黑盒测试用例设计没有逻辑、测试场景容易遗漏的问题。提高了测试用例的场景覆盖率，缩短了测试用例开发周期，提高了测试用例编写、评审效率，从而在根本上提高了软件质量。
[0097]
基于同样的思路，本发明还提供测试用例生成装置，如图4所示，所述装置可以包括：
[0098]
思维导图模板获取模块410，用于获取思维导图模板，并在所述思维导图模板的一级子节点录入所述思维导图模板对应的测试点以及测试场景；所述测试场景中至少包括功能测试场景；
[0099]
测试点分解模块420，用于按照预设分解规则，将每个所述测试点分解为具有单一属性的测试点集合；所述测试点集合中的每一个小测试点对应一个测试场景；
[0100]
初始测试用例生成模块430，用于基于所述测试点集合，生成初始测试用例；
[0101]
目标用例生成模块440，用于若所述初始测试用例的设计场景未覆盖预设的全部测试点以及测试场景，则基于标准文件以及历史经验数据，补充新的设计场景，直至覆盖预设的全部所述测试点以及所述测试场景，生成目标测试用例。
[0102]
基于图4中的装置，还可以包括一些具体的实施单元：
[0103]
可选的，装置还可以包括：
[0104]
判断模块，用于判断所述初始测试用例中的设计场景是否覆盖软件规格中的全部测试点以及标准文件中全部测试场景；所述标准文件为预先获取的文件，所述标准文件中至少包含需要涵盖的测试场景；所述历史经验数据至少包括相关用户的历史应用场景数据；
[0105]
设计场景补充模块，用于若所述初始测试用例中的设计场景覆盖软件规格中的全部测试点以及标准文件中全部测试场景，则基于历史经验数据补充设计场景，直至覆盖预设的全部所述测试点以及所述测试场景，生成目标测试用例；
[0106]
目标测试用例确定模块，用于若所述初始测试用例中的设计场景既能覆盖软件规格中的全部测试点，又能覆盖标准文件以及历史经验数据中全部测试场景，则将所述初始测试用例确定为目标测试用例。
[0107]
可选的，所述测试场景至少可以包括测试模式场景以及应用领域场景；所述测试
模式场景可以包括：功能测试场景、兼容性测试场景、安全测试场景、长期测试场景以及上下电测试场景。
[0108]
可选的，目标用例生成模块440，具体可以包括：
[0109]
目标测试用例生成单元，用于在所述思维导图模板中添加了新的设计场景之后，输出思维导图分支，生成目标测试用例；一个所述思维导图分支对应一种所述测试场景；
[0110]
测试场景保存单元，用于根据所述目标测试用例的格式，将所述思维导图中的测试场景存入测试用例表格中。
[0111]
可选的，测试点分解模块420，具体可以包括：
[0112]
测试点分解单元，用于对于任意一种测试场景，将所述测试点按照功能维度对测试点进行分解，直至分解后的小测试点对应最小维度的对象为止。
[0113]
可选的，装置还可以用于：选择对应的黑盒测试用例设计方法，构造测试数据、梳理测试步骤并确定预期结果。
[0114]
基于同样的思路，本说明书实施例还提供了测试用例生成设备。如图5所示。可以包括：
[0115]
通信单元/通信接口，用于获取思维导图模板；
[0116]
处理单元/处理器，用于在所述思维导图模板的一级子节点录入所述思维导图模板对应的测试点以及测试场景；所述测试场景中至少包括功能测试场景；
[0117]
按照预设分解规则，将每个所述测试点分解为具有单一属性的测试点集合；所述测试点集合中的每一个小测试点对应一个测试场景；
[0118]
基于所述测试点集合，生成初始测试用例；
[0119]
若所述初始测试用例的设计场景未覆盖预设的全部测试点以及测试场景，则基于标准文件以及历史经验数据，补充新的设计场景，直至覆盖预设的全部所述测试点以及所述测试场景，生成目标测试用例。
[0120]
如图5所示，上述终端设备还可以包括通信线路。通信线路可包括一通路，在上述组件之间传送信息。
[0121]
可选的，如图5所示，该终端设备还可以包括存储器。存储器用于存储执行本发明方案的计算机执行指令，并由处理器来控制执行。处理器用于执行存储器中存储的计算机执行指令，从而实现本发明实施例提供的方法。
[0122]
如图5所示，存储器可以是只读存储器(read-only memory，rom)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，ram)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、只读光盘(compact disc read-only memory，cd-rom)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过通信线路与处理器相连接。存储器也可以和处理器集成在一起。
[0123]
可选的，本发明实施例中的计算机执行指令也可以称之为应用程序代码，本发明实施例对此不作具体限定。
[0124]
在具体实现中，作为一种实施例，如图5所示，处理器可以包括一个或多个cpu，如图5中的cpu0和cpu1。
[0125]
在具体实现中，作为一种实施例，如图5所示，终端设备可以包括多个处理器，如图5中的处理器。这些处理器中的每一个可以是一个单核处理器，也可以是一个多核处理器。
[0126]
基于同样的思路，本说明书实施例还提供了上述实施例对应的计算机存储介质，计算机存储介质中存储有指令，当所述指令被运行时，实现上述实施例中的方法。
[0127]
上述主要从各个模块之间交互的角度对本发明实施例提供的方案进行了介绍。可以理解的是，各个模块为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件单元。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本发明能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
[0128]
本发明实施例可以根据上述方法示例进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
[0129]
本说明书中的处理器还可以具有存储器的功能。存储器用于存储执行本发明方案的计算机执行指令，并由处理器来控制执行。处理器用于执行存储器中存储的计算机执行指令，从而实现本发明实施例提供的方法。
[0130]
存储器可以是只读存储器(read-only memory，rom)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，ram)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、只读光盘(compact disc read-only memory，cd-rom)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过通信线路与处理器相连接。存储器也可以和处理器集成在一起。
[0131]
可选的，本发明实施例中的计算机执行指令也可以称之为应用程序代码，本发明实施例对此不作具体限定。
[0132]
上述本发明实施例揭示的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(digital signal processing，dsp)、asic、现成可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明
实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
[0133]
一种可能的实现方式中，提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当指令被运行时，用于实现上述实施例中的方法。
[0134]
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机程序或指令。在计算机上加载和执行所述计算机程序或指令时，全部或部分地执行本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、终端、用户设备或者其它可编程装置。所述计算机程序或指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机程序或指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是集成一个或多个可用介质的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，例如，软盘、硬盘、磁带；也可以是光介质，例如，数字视频光盘(digital video disc，dvd)；还可以是半导体介质，例如，固态硬盘(solid state drive，ssd)。
[0135]
尽管在此结合各实施例对本发明进行了描述，然而，在实施所要求保护的本发明过程中，本领域技术人员通过查看附图、公开内容、以及所附权利要求书，可理解并实现公开实施例的其他变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其他单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。
[0136]
尽管结合具体特征及其实施例对本发明进行了描述，显而易见的，在不脱离本发明的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本发明的示例性说明，且视为已覆盖本发明范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包括这些改动和变型在内。