CN117234945A - 测试思维导图的展示方法、装置、电子设备和存储介质 - Google Patents
测试思维导图的展示方法、装置、电子设备和存储介质 Download PDFInfo
- Publication number
- CN117234945A CN117234945A CN202311489451.1A CN202311489451A CN117234945A CN 117234945 A CN117234945 A CN 117234945A CN 202311489451 A CN202311489451 A CN 202311489451A CN 117234945 A CN117234945 A CN 117234945A
- Authority
- CN
- China
- Prior art keywords
- test
- directory
- target
- under
- contained
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 921
- 238000000034 method Methods 0.000 title claims abstract description 67
- 238000010586 diagram Methods 0.000 title claims description 79
- 238000012795 verification Methods 0.000 claims description 34
- 238000004088 simulation Methods 0.000 claims description 5
- 238000012423 maintenance Methods 0.000 abstract description 9
- 238000009960 carding Methods 0.000 abstract description 8
- 238000004321 preservation Methods 0.000 abstract description 8
- 230000009286 beneficial effect Effects 0.000 abstract description 7
- 230000004044 response Effects 0.000 abstract description 5
- 230000006870 function Effects 0.000 description 23
- 230000003068 static effect Effects 0.000 description 14
- 241000282326 Felis catus Species 0.000 description 9
- 239000003086 colorant Substances 0.000 description 9
- 230000008569 process Effects 0.000 description 9
- 230000008901 benefit Effects 0.000 description 5
- 238000004590 computer program Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 5
- 230000008520 organization Effects 0.000 description 4
- 230000007547 defect Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 238000013522 software testing Methods 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本申请涉及计算机技术领域，具体涉及测试思维导图的展示方法、装置、电子设备和存储介质，包括：在目标***内接收第一命令，第一命令用于指示在终端工具上打印目标目录下的目录和/或文件，至少一个目录下添加有测试回归用例；响应于第一命令，在目标***内调用目标脚本，以获取并在终端工具上展示目标测试项目的测试思维导图。这样，在对测试点进行测试并获得测试回归用例之后，可以将测试回归用例添加至包含相应测试点的目录下，而目录本身又包含于思维导图内。可见，本申请实现了将测试回归用例整合于思维导图之上，从而避免了多个软件的交叉使用，降低了测试思维导图与测试回归用例之间的对应关系的梳理难度，利于测试数据的保存以及维护。
Description
技术领域
本申请涉及计算机技术领域，更具体地说，涉及测试思维导图的展示方法、装置、电子设备和存储介质。
背景技术
EDA的全称是电子设计自动化（Electronics Design Automation），它是指利用计算机辅助设计软件来辅助完成超大规模集成电路芯片的设计、制造、封装以及测试等多个流程。
EDA软件测试是评估和验证EDA软件产品是否按照预期运行的过程，通过测试可以防止出现错误、降低开发成本和提高性能。相关技术中，在进行测试的过程中，通常使用Xmind等工具来编写测试思维导图，并且利用Excel等工具来编写测试回归用例。
但是，由于多个软件的交叉使用，不利于测试数据的保存以及维护。例如，一般情况下，工作人员利用Excel等工具编写好测试回归用例之后，需要在测试思维导图中与该测试回归用例对应的测试点处进行标记，表明已经针对该测试点进行过测试。如果工作人员编写好测试回归用例之后，却忘记在测试思维导图中与该测试回归用例对应的测试点处进行标记，或者，在标记时标错了位置，均会导致测试回归用例与测试思维导图无法正确对应。可见，相关技术中，测试思维导图与测试回归用例之间的对应关系的梳理难度较大。
发明内容
本申请提供测试思维导图的展示方法、装置、电子设备和存储介质，以至少解决上述相关技术中，测试思维导图与测试回归用例之间的对应关系的梳理难度较大的问题。
根据本申请实施例的第一方面，提供一种测试思维导图的展示方法，包括：在目标***内接收输入于终端工具的第一命令，其中，所述第一命令用于指示基于目标脚本在所述终端工具上以树状图形式打印目标目录下的目录和/或文件，所述目标目录包含多级子目录，所述目标目录及其多级子目录根据目标测试项目被预先创建，所述目标目录以及所述多级子目录中的至少一个目录下添加有针对所述至少一个目录对应的测试点进行测试所获得的测试回归用例；响应于所述第一命令，在所述目标***内调用所述目标脚本，以获取并在所述终端工具上展示所述目标目录对应的树状图作为所述目标测试项目的测试思维导图。
根据本申请实施例的第二方面，提供一种测试思维导图的展示装置，包括：第一命令接收模块，被配置为在目标***内接收输入于终端工具的第一命令，其中，所述第一命令用于指示基于目标脚本在所述终端工具上以树状图形式打印目标目录下的目录和/或文件，所述目标目录包含多级子目录，所述目标目录及其多级子目录根据目标测试项目被预先创建，所述目标目录以及所述多级子目录中的至少一个目录下添加有针对所述至少一个目录对应的测试点进行测试所获得的测试回归用例；测试思维导图展示模块，被配置为响应于所述第一命令，在所述目标***内调用所述目标脚本，以获取并在所述终端工具上展示所述目标目录对应的树状图作为所述目标测试项目的测试思维导图。
根据本申请实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现根据本申请的测试思维导图的展示方法。
根据本申请实施例的第四方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行根据本申请的测试思维导图的展示方法。
本申请的实施例提供的技术方案至少带来以下有益效果：
在本申请中，在对测试点进行测试并获得测试回归用例之后，可以将测试回归用例添加至包含相应测试点的目录下，而目录本身又包含于思维导图内。可见，本申请实现了将测试回归用例整合于思维导图之上，从而避免了多个软件的交叉使用，降低了测试思维导图与测试回归用例之间的对应关系的梳理难度，利于测试数据的保存以及维护。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理，并不构成对本申请的不当限定。
图1是示出根据本申请的示例性实施例的Linux***的文件***树形图；
图2是示出根据本申请的示例性实施例的测试思维导图的展示方法的流程图；
图3是示出根据本申请的示例性实施例的readme文件所包含的内容的示意图；
图4是示出根据本申请的示例性实施例的在至少一个目录下添加测试回归用例的示意图；
图5是示出根据本申请的示例性实施例的执行“./showmindmap demo”命令之后获得的测试思维导图；
图6是示出根据本申请的示例性实施例的执行“./showmindmap demo --clean”命令之后获得的测试思维导图；
图7是示出根据本申请的示例性实施例的一种利用树状结构连接符号连接各个目录以及文件所获得的树状图；
图8是示出根据本申请的示例性实施例的另一种利用树状结构连接符号连接各个目录以及文件所获得的树状图；
图9是示出根据本申请的示例性实施例的测试思维导图的展示装置的框图；
图10是示出根据本申请的示例性实施例的电子设备的框图。
具体实施方式
为了使本领域普通人员更好地理解本申请的技术方案，下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
相关技术中，一般使用Mind Manager、XMind等工具来编写测试思维导图，测试思维导图可以帮助可视化测试工作的结构和关系，方便组织和查看测试信息。并且，相关技术中一般使用Excel等工具来编写测试回归用例，即使用Excel工具或其他电子表格工具创建表格，并记录测试任务、测试状态、测试进度、测试优先级等信息。
需要说明的是，采用Xmind等工具编写测试思维导图优势明显，但是同时也存在一些缺点。其优点为可以采用图形化界面编写测试思维导图，清晰直观且操作简单；其缺点主要为以下3点：
1、需要协同工作的每个参与人员都安装相关的测试思维导图绘制软件；
2、测试思维导图的保存与维护问题；
3、测试思维导图与测试回归用例之间难以准确对应。
并且，采用Excel等工具编写测试回归用例也同样存在相应的优点和缺点。其优点为Excel工具的功能齐全、覆盖范围广，利用Excel工具编写测试回归用例的操作过程比较简单，快捷易行；其缺点主要为以下3点：
1、需要协同工作的每个参与人员都安装相关的office办公软件；
2、测试回归用例的保存与维护问题；
3、测试思维导图与测试回归用例之间难以准确对应。
可见，相关技术中，在编写测试思维导图以及测试回归用例时，不仅需要依赖第三方软件，还需要多个第三方软件交叉使用，这会增加测试思维导图与测试回归用例之间的对应关系的梳理难度，不利于测试数据的保存以及维护。
为了解决相关技术存在的上述问题，本申请提供的测试思维导图的展示方法、装置、电子设备和存储介质，在对测试点进行测试并获得测试回归用例之后，可以将测试回归用例添加至包含相应测试点的目录下，而目录本身又包含于思维导图内。可见，本申请实现了将测试回归用例整合于思维导图之上，从而避免了多个软件的交叉使用，降低了测试思维导图与测试回归用例之间的对应关系的梳理难度，利于测试数据的保存以及维护。
需要说明的是，在Linux操作***中，所有的文件和目录都可以被组织成以一个根节点“/”开始的树状结构。其中，这里的“目录”就相当于Windows***中的文件夹，目录中存放的既可以是文件，也可以是其他的子目录，而文件中存储的是数据。在终端工具中，可通过命令“tree”来查看Linux***的文件***树形图。
图1是示出根据本申请的示例性实施例的Linux***的文件***树形图。参照图1，“demo”这个目录下一共存在4个分支目录，分别为“test-dir-1”、“test-dir-2”、“test-dir-3”、“test-dir-4”，这4个分支目录均与目录“demo”相连接。并且，“test-dir-4”这个分支目录下还存在两个分支目录，分别为“test-dir-4-1”和“test-dir-4-2”，这两个分支目录均与目录“test-dir-4”相连接。进一步的，目录“demo”、目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4”、目录“test-dir-4-1”和目录“test-dir-4-2”下均对应有一个文件，且该文件可以为自述文件（readme）。并且，在图1的底部还显示了分支目录的数量：6 directories，以及文件的总数量：7 files。
在Linux文件***树形图的启发下，本申请设计了测试思维导图与测试进度统计的代码实现脚本，该代码实现脚本能够在终端工具中实现诸如展示测试思维导图与测试进度统计等功能。代码实现脚本的名称可以自定义，示例性的，可以为showmindmap脚本。并且，本申请中的代码实现脚本中并不使用tree命令，换言之，本申请与通过tree命令查看Linux文件***树形图的实现方式并不相同。
下面，将结合图2~图9来详细解释本申请提供的测试思维导图的展示方法。需要说明的是，根据本申请的示例性实施例的测试思维导图的展示方法可以应用于集成电路电子设计自动化（EDA）软件测试，然而本申请对此不做限制，本领域技术人员也可将其应用于其他类型软件的测试过程中。
图2是示出根据本申请的示例性实施例的测试思维导图的展示方法的流程图。
参照图2，在步骤201中，可以在目标***内接收输入于终端工具的第一命令。其中，该第一命令可以用于指示基于目标脚本在终端工具上以树状图形式打印目标目录下的目录和/或文件。该目标目录可以包含多级子目录，目标目录及其多级子目录可以根据目标测试项目被预先创建。目标目录以及多级子目录中的至少一个目录下可以添加有针对至少一个目录对应的测试点进行测试所获得的测试回归用例（case），即.tcl文件。上述“目标***”可以为但不限于Linux***。
需要说明的是，测试人员可以预先将展示测试思维导图与统计测试进度的整个实现流程编辑为可执行的目标脚本，即showmindmap脚本。该showmindmap脚本可以使用工具命令语言（Tool Command Language，TCL），也可以使用其他脚本语言，本申请对代码实现脚本具体使用什么样的脚本语言不作具体限制。并且，showmindmap脚本内主要涉及到“__SHOW_TREE__”和“__STATISTICS__”这两个自定义的函数。其中。“__SHOW_TREE__”函数主要用于展示相应目录对应的测试思维导图；“__STATISTICS__”函数主要用于对相应目录的测试进度进行统计。
根据本申请的示例性实施例，在目标***内接收输入于终端工具的第一命令之前，还可以根据目标测试项目创建目标目录以及多级子目录，进而可以在目标目录以及多级子目录中的每个目录下创建自述文件（readme）。返回参照图1，“目标目录”可以为目录“demo”，“多级子目录”可以为目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4”、目录“test-dir-4-1”和目录“test-dir-4-2”。并且，这些目录中的每个目录下均对应有一个自述文件。
进一步的，还可以按照第一预设格式在每个目录下的自述文件中编写目标测试项目中相应的测试点（test），并可以在至少一个目录下添加测试回归用例。其中，测试回归用例可以为针对至少一个目录下的自述文件中所编写的至少一个测试点进行测试所获得的测试回归用例。
其中，上述“第一预设格式”，即测试点的格式可以按照“测试点+测试描述”的方式，即测试点的格式可以为：“test”+“数字”+“：”+“描述”。示例性的，可以将“test1：description”记为一条测试点，且该测试点的名称可以为“test1”。
需要说明的是，如果测试点没有按照上述第一预设格式进行编写，则后续就无法被识别为测试点。示例性的，针对“（not test point）test4：XXX”，由于“test”前面多出了额外的文本内容，即“（not test point）”，这会导致其格式与第一预设格式不匹配，此时，该test4在后续过程中就不会被识别为测试点。
图3是示出根据本申请的示例性实施例的readme文件所包含的内容的示意图。参照图3，示出了目标目录“demo”下的分支目录“test-dir-4”所对应的readme文件内所包含的内容。该readme文件指定了目录test_dir_4下存在3条测试点，分别为test1、test2和test3；此外，该readme文件还指定了目录test_dir_4下存在两个子目录，即两个分支目录，也即两个方向（there are some directions），分别为“test_dir_4_1”和“test_dir_4_2”。
这样，可以有针对性的针对特定目录下的自述文件中所包含的测试点进行测试，并可以将相应的测试回归用例添加至包含相应测试点的目录下，而目录本身又包含于测试思维导图内。因此，本申请实现了将测试回归用例整合于测试思维导图之上，从而避免了多个软件的交叉使用，降低了测试思维导图与测试回归用例之间的对应关系的梳理难度，利于测试数据的保存以及维护。
根据本申请的示例性实施例，上述测试回归用例可以包含以下至少一项：
按照第二预设格式指定的所编写的至少一个测试点。其中，该“第二预设格式”可以为：“set test {测试点}”，用于表明测试回归用例中到底包含哪些测试点，即用于表明相应的测试回归用例到底为针对哪些测试点进行测试而获得的。并且，测试回归用例中所包含的测试点的数量可以为多个。例如，按照第二预设格式指定的至少一个测试点可以为：“set test {test1 test2}”。
需要说明的是，本申请中的“测试点”可以利用“test point”来表示，也可以直接使用“test”来表示，本申请对此不作限制。此时，按照第二预设格式指定的至少一个测试点除了可以表示为：“set test {test1 test2}”之外，还可以表示为“set test point {testpoint 1 test point 2}”等等。
测试回归用例还可以包含用于验证所编写的至少一个测试点的验证数据；用于验证所编写的至少一个测试点的模拟人工操作步骤；期望结果；验证结果；期望结果与验证结果是否匹配的指示信息；所编写的至少一个测试点验证是否通过的结论信息。其中，上述“验证结果”可以为基于验证数据执行模拟人工操作步骤之后获得的结果；上述“期望结果”可以为基于验证数据执行模拟人工操作步骤之后应当获得的准确结果。
示例性的，假设需要进行测试的测试点为一个加法运算，则上述“验证数据”可以被设置为数据a=2和数据b=3；上述“模拟人工操作步骤”可以包含以下4个模拟步骤：（1）、将验证数据a=2、b=3输入测试回归***；（2）、将a=2、b=3进行相加运算；（3）、将基于验证数据进行相加运算获得的验证结果与期望结果进行比对；（4）、基于比对结果输出加法运算测试点是否通过的结论信息。
上述“期望结果”即为基于验证数据a=2、b=3 执行相加运算之后应当获得的准确结果：5；上述“验证结果”即为基于验证数据a=2、b=3 执行相加运算之后获得的实际结果，该实际结果可能为正确的加和结果，也可能为错误的加和结果。例如，该实际结果可能为正确的加和结果5，也可能为错误的加和结果4、6或者7等等。
上述“期望结果与验证结果是否匹配的指示信息”即为正确加和结果5与实际运算结果是否相同的指示信息；上述“所编写的至少一个测试点验证是否通过的结论信息”即为在期望结果5与实际运算结果相同时的“验证通过”信息；或者，在期望结果5与实际运算结果不相同时的“验证失败”信息。
图4是示出根据本申请的示例性实施例的在至少一个目录下添加测试回归用例的示意图。参照图4，目标目录“demo”下被添加了两个测试回归用例，分别为1.tcl和2.tcl；分支目录“test-dir-1”下被添加了3个测试回归用例，分别为1.tcl、2.tcl和3.tcl等等。并且，在图4的底部还显示了分支目录的数量：6 directories，以及文件的总数量：15 files。
这样，通过控制测试回归用例中包含已经进行过测试的测试点，便于后续基于测试回归用例中所包含的测试点及时知晓到底已经针对哪些测试点进行了测试，进而可以方便、快速的统计出测试进度；进一步的，通过控制测试回归用例中包含验证数据、模拟人工操作步骤、期望结果、验证结果；期望结果与验证结果是否匹配的指示信息、测试点验证是否通过的结论信息，相当于针对测试点进行测试的完整过程进行了一个详细的记录，便于后续的查漏和纠错。
根据本申请的示例性实施例，在目标***内接收输入于终端工具的第一命令之后，还可以判断第一命令中是否包含目录的路径名称。需要说明的是，代码实现脚本，即showmindmap脚本中可以包含“[info exist v1]”，该[info exist v1]用于判断第一命令中是否指定了目录。
在第一命令中包含路径名称的情况下，可以将该路径名称对应的目录作为上述目标目录。即在[info exist v1]判断出第一命令中指定了目录的情况下，可以将指定目录的绝对路径名称赋值给“workPath”变量，以将指定的目录作为上述目标目录。
否则，可以将目标***的当前工作目录作为上述目标目录。即在[info exist v1]判断出第一命令中未指定目录的情况下，可以将当前工作目录的绝对路径名称赋值给“workPath”变量，以将当前工作目录作为上述目标目录。
这样，用户可以根据自身需要决定是否在第一命令中指定相应的目录，即用户可以根据自身需要决定到底展示哪个目录的测试思维导图，展示测试思维导图的自主性和灵活性较好。进一步的，在第一命令中未指定相应目录的情况下，终端可以自动将当前工作目录确定为待展示测试思维导图的目录，节省了用户手动指定目录的操作步骤，降低了确定待展示测试思维导图的目录的繁琐程度。
需要说明的是，代码实现脚本，即showmindmap脚本中还可以包含很多其他函数和命令，每个函数或者命令用于实现其特有的功能。例如，showmindmap脚本中可以包含但不限于““__STATE__”函数”、““__POINT_NUM__”函数”、“pwd命令”、“cd命令”、“find命令”、“[llength [exec find{workPath} -name/>.tcl]]”等等。
其中，“__STATE__”函数用于统计目录的测试工作状态，“__POINT_NUM__”函数用于统计目录的测试点数量。
pwd（英文全拼：print work directory）命令用于显示工作目录，执行pwd指令可立刻得知当前所在的工作目录的绝对路径名称。
cd（英文全拼：change directory）命令用于改变当前工作目录，切换到指定的路径。若目录名称省略，则变换至使用者的家目录（home），也就是刚登录（login）时所在的目录。另外，“~”也表示为home目录的意思；“.”则是表示当前所在的目录；“..”则表示当前目录位置的上一层目录。
find命令用于在指定目录下查找文件和目录，它可以使用不同的选项来过滤和限制查找的结果。-name pattern：按文件名查找，支持使用通配符“”和“?”。
[llength [exec find{workPath} -name/>.tcl]]中，“exec”用于调用外部命令，例如find命令；“llength”用于获取指定列表中的元素个数。
在步骤202中，响应于第一命令，可以在目标***内调用目标脚本，以获取并在终端工具上展示目标目录对应的树状图作为目标测试项目的测试思维导图。即响应于第一命令，可以在Linux***内调用showmindmap脚本，以展示测试思维导图并统计测试进度。
需要说明的是，上述第一命令必须包含基础命令，同时，可以包含附加选项。
其中，上述“基础命令”可以指示showmindmap脚本的脚本路径、showmindmap脚本的脚本名称、目标目录。在第一命令仅包含基础命令的情况下，能够全流程地完整展示目标目录下的测试思维导图并统计测试进度。上述“附加选项”为可选的功能选项，用于实现例如“只展示目录层级”、“最大展示目录层级”、“打印时禁止携带颜色”等个性化功能。
以第一命令仅包含基础命令的“./showmindmap demo”为例。在Linux命令行中，目录以正斜杠“/”结尾，“.”表示当前所在的目录，两者的组合符号“./”本身不是命令，但它允许shell直接从终端运行可执行文件，并在***中安装任何解释器，不用再双击图形文件管理器中的文件。
“showmindmap”为可执行脚本的名称，demo为上述目标目录。具体而言，示例命令中的“demo”部分指示目标目录为当前目录下的demo目录，此外，也可将示例命令中的“demo”部分省略，省略后则指示目标目录为当前工作目录。或者，还可将示例命令中的“demo”部分替换为目标目录的绝对路径，以避免出错。
执行“./showmindmap demo”这条命令之后，就可以获得目标目录demo对应的测试思维导图。图5是示出根据本申请的示例性实施例的执行“./showmindmap demo”命令之后获得的测试思维导图。参照图5，示出了目标目录demo以及该目标目录demo的多级子目录。并且，目标目录demo及其多级子目录中的各个目录下均对应有各种类型的文件。示例性的，各种类型的文件可以包含但不限于自述文件（readme）、测试回归用例（case），即.tcl文件、测试进度文件（statistics）等等。并且，在图5的底部还显示了分支目录的数量：6directories，以及文件的总数量：22 files。
进一步的，以第一命令为包含附加选项“--clean”的“./showmindmap demo --clean”为例。“--clean”可以为前述“附加选项”，其功能是展示测试思维导图之后不保留统计生成的“statistics”文件。其优点是展示出来的测试思维导图更加简洁，其缺点是由于缺少“statistics”文件导致本次无法进一步查看测试进度统计结果。并且，“--clean”这个附加选项可以控制终端不会执行进度统计这个动作，即采用忽略statistics的方式做测试思维导图的展示，并且还会将之前已经存在的“statistics”文件删除。
执行第一命令“./showmindmap demo --clean”之后可以获得不包含测试进度文件的测试思维导图。图6是示出根据本申请的示例性实施例的执行“./showmindmap demo--clean”命令之后获得的测试思维导图。参照图6，示出了目标目录demo以及该目标目录demo的多级子目录。并且，目标目录demo及其多级子目录中的各个目录下均对应有各种类型的文件。执行 “./showmindmap demo --clean”命令与执行“./showmindmap demo”命令的不同之处，即图6与图5的不同之处在于图6中的测试思维导图不包含测试进度文件statistics。进一步的，在图6的底部还显示了分支目录的数量：6 directories，以及文件的总数量：15 files。
根据本申请的示例性实施例，还可以在测试思维导图中展示目标目录以及多级子目录中各个目录对应的自述文件、测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项。其中，任一目录对应的自述文件可以包含任一目录的介绍信息、测试点信息以及分支目录的信息。
示例性的，返回参照图5，图5中的测试思维导图示出了目标目录“demo”以及该目标目录“demo”的多级子目录：“test-dir-1”、“test-dir-2”、“test-dir-3”、“test-dir-4”、“test_dir_4_1”、“test_dir_4_2”。
上述这些目录中的每个目录下均对应有自述文件（readme），该自述文件（readme）可以包含相应目录的功能介绍信息、所包含的测试点信息以及分支目录，即子目录的信息。例如，目标目录“demo”下的自述文件（readme）内可以包含0个测试点信息、4个分支目录的信息（“test-dir-1”、“test-dir-2”、“test-dir-3”、“test-dir-4”）、以及目标目录“demo”的功能介绍信息；或者，子目录“test-dir-4” 下的自述文件（readme）内可以包含3个测试点信息、2个分支目录的信息（“test_dir_4_1”、“test_dir_4_2”）、以及子目录“test-dir-4”的功能介绍信息等等。
进一步的，上述这些目录中的每个目录均可以对应有测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项。例如，目标目录“demo”对应的测试点的数量为18，即18个测试点（18 test points）、测试回归用例的数量为8，即8个测试回归用例（8cases）、目录测试状态为“正在测试中（ongoing）”状态；或者，子目录“test-dir-1”对应的测试点的数量为3，即3个测试点（3 test points）、测试回归用例的数量为3，即3个测试回归用例（3 cases）、目录测试状态为“完成（done）”状态；或者，子目录“test-dir-4-2”对应的测试点的数量为3，即3个测试点（3 test points）、测试回归用例的数量为0，即0个测试回归用例（0 cases）、目录测试状态为“尚未启动测试（no start）”状态等等。
这样，通过在测试思维导图中展示各个目录对应的自述文件、测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项，便于用户对各个目录的测试任务轻重、测试进度快慢有一个直观、清晰的了解，方便用户对整体测试状况有一个宏观、大体的把控。
根据本申请的示例性实施例，针对每个第一子目录，可以根据第一子目录下的自述文件中所包含的测试点与第一子目录下的测试回归用例所包含的测试点的重合情况，确定第一子目录的目录测试状态，并可以在第一子目录下展示目录测试状态。其中，第一子目录可以为多级子目录中不存在下级目录的子目录。
返回参照图5，图5示出的测试思维导图中的目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4-1”和目录“test-dir-4-2”均为不存在下级目录的第一子目录。针对每个第一子目录，均可以根据该第一子目录下的自述文件中所包含的测试点，与，该第一子目录下的测试回归用例所包含的测试点的重合情况，确定该第一子目录的目录测试状态，并可以在该第一子目录的右侧展示该目录测试状态。
示例性的，针对第一子目录“test-dir-1”，可以先确定其下的自述文件（readme）中是否包含测试点。在其下的自述文件中不包含测试点的情况下，可以直接确定该第一子目录“test-dir-1”对应的目录测试状态为完成状态（done）。在其下的自述文件中包含测试点的情况下，可以确定该自述文件中所包含的测试点，与，其下的测试回归用例（1.tcl、2.tcl、3.tcl）中所包含的测试点的重合情况，进而可以基于该重合情况确定该第一子目录“test-dir-1”对应的目录测试状态。
进一步的，在自述文件中所包含的测试点与测试回归用例（1.tcl、2.tcl、3.tcl）中所包含的测试点完全重合，或者，自述文件中所包含的测试点属于测试回归用例（1.tcl、2.tcl、3.tcl）中所包含的测试点的真子集的情况下，可以确定第一子目录“test-dir-1”对应的目录测试状态为“完成状态（done）”；在自述文件中所包含的测试点与测试回归用例（1.tcl、2.tcl、3.tcl）中所包含的测试点部分重合的情况下，可以确定第一子目录“test-dir-1”对应的目录测试状态为“正在测试中（ongoing）”状态；在自述文件中所包含的测试点与测试回归用例（1.tcl、2.tcl、3.tcl）中所包含的测试点完全不重合，或者，在自述文件中存在测试点，但第一子目录“test-dir-1”下不存在测试回归用例.tcl的情况下，可以确定第一子目录“test-dir-1”对应的目录测试状态为“尚未启动测试（nostart）”状态。进一步的，确定其他第一子目录对应的目录测试状态的方式与上述确定第一子目录“test-dir-1”对应的目录测试状态的方式类似，这里不再赘述。
需要说明的是，由于测试回归用例为针对目录对应的测试点进行测试所获得的，一旦某个测试回归用例中所包含的某个测试点与目录下的自述文件中所包含的某个测试点相重合，说明自述文件中所包含的该测试点已经被测试完成。因此，可以基于目录下的自述文件中所包含的测试点，与，该目录下的测试回归用例所包含的测试点的重合情况，来确定该目录对应的全部测试点是否已经测试完成，即可以基于上述测试点的重合情况来确定目录测试状态，可以保证所确定的目录测试状态的准确性。
根据本申请的示例性实施例，针对目标目录和第二子目录中的每个目录，可以根据每个目录下的自述文件中所包含的测试点的测试状态以及每个目录的下级目录的目录测试状态，确定每个目录的目录测试状态，并可以在每个目录下展示目录测试状态。其中，上述第二子目录可以为多级子目录中存在下级目录的子目录。
返回参照图5，图5示出的测试思维导图中的目录“demo”为目标目录，目录“test-dir-4”为存在下级目录（ “test-dir-4-1”和“test-dir-4-2”）的第二子目录。针对目标目录demo以及第二子目录“test-dir-4”，均可以根据相应目录下的自述文件中所包含的测试点的测试状态以及相应目录的下级目录的目录测试状态，确定该相应目录的目录测试状态，并可以在该相应目录的右侧展示该目录测试状态。
进一步的，在相应目录下的自述文件中所包含的测试点的测试状态以及该相应目录的全部下级目录的目录测试状态均为完成状态的情况下，才可以确定该相应目录的目录测试状态为完成状态；在相应目录下的自述文件中所包含的测试点的测试状态以及该相应目录的全部下级目录的目录测试状态均为尚未启动测试状态的情况下，才可以确定该相应目录的目录测试状态为尚未启动测试状态；否则，可以确定该相应目录的目录测试状态为正在测试中状态。
示例性的，针对目标目录demo，其下的自述文件中包含0个测试点，即其下的自述文件中不包含任何测试点，因此，可以直接确定该自述文件对应的文件测试状态为完成状态。并且，目标目录demo的下级目录，即多级子目录中，目录test-dir-1和目录test-dir-4-1对应的目录测试状态均为完成状态；目录test-dir-2和目录test-dir-4对应的目录测试状态均为正在测试中状态；目录test-dir-3和目录test-dir-4-2对应的目录测试状态均为尚未启动测试状态。可见，目标目录demo的下级目录中尚存在处于正在测试中状态以及尚未启动测试状态的目录，即目标目录demo的所有下级目录并未全部测试完成，因此，可以确定目标目录demo对应的目录测试状态为正在测试中（ongoing）状态。
或者，针对第二子目录test-dir-4，其下的自述文件中包含3个测试点，并且，第二子目录test-dir-4的下级目录中的目录“test-dir-4-1”对应的目录测试状态为完成状态；第二子目录test-dir-4的下级目录中的目录“test-dir-4-2”对应的目录测试状态为尚未启动测试状态。可见，第二子目录test-dir-4的下级目录中尚存在处于尚未启动测试状态的目录，即第二子目录test-dir-4的所有下级目录并未全部测试完成，因此，可以确定第二子目录test-dir-4对应的目录测试状态为正在测试中（ongoing）状态。
需要说明的是，某个目录只有在和另一个目录的关系比较紧密的情况下，才可能成为该另一个目录的下级目录。因此，针对存在下级目录的目录，在确定该目录的目录测试状态时，除了要考虑该目录自身下面的自述文件中的测试点的测试状态，还需要考虑该目录的所有下级目录的目录测试状态。这样，用户只需基于某个目录的目录测试状态，就可以大体判断出该目录的下级目录大致处于什么样的测试状态，便于用户对当前目录的下级目录到底处于何种测试状态有一个直观、清晰的了解。
进一步的，在确定目标目录以及第二子目录的目录测试状态时，除了上述方式，还可以存在其他方式。例如，也可以直接基于相应目录下的全部测试点，与，该相应目录下的所有测试回归用例中所包含的测试点的重合情况，来确定该相应目录的目录测试状态等等。其中，“相应目录下的全部测试点”包含该相应目录下的自述文件中所包含的测试点以及该相应目录的所有下级目录的自述文件中所包含的测试点；“该相应目录下的所有测试回归用例”包含该相应目录下的测试回归用例以及该相应目录的所有下级目录下的测试回归用例。
根据本申请的示例性实施例，针对每个第一子目录，可以确定第一子目录下的自述文件中所包含的测试点的数量。其中，该第一子目录可以为多级子目录中不存在下级目录的子目录。然后，可以在第一子目录下展示自述文件中所包含的测试点的数量。
返回参照图5，图5示出的测试思维导图中的目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4-1”和目录“test-dir-4-2”均为不存在下级目录的第一子目录。针对每个第一子目录，均可以确定该第一子目录下的自述文件中所包含的测试点的数量，进而可以在该第一子目录的右侧展示自述文件中所包含的测试点的数量。
示例性的，针对第一子目录“test-dir-2”，其下的自述文件中包含3个测试点，因此，可以在该第一子目录“test-dir-2”的右侧展示其下的自述文件中所包含的测试点的数量：“3 test points”；或者，针对第一子目录“test-dir-4-2”，其下的自述文件中也包含3个测试点，因此，可以在该第一子目录“test-dir-4-2”的右侧展示其下的自述文件中所包含的测试点的数量：“3 test points”。
根据本申请的示例性实施例，针对目标目录以及第二子目录中的每个目录，可以确定每个目录下的自述文件所包含的测试点的第一数量。其中，该第二子目录可以为多级子目录中存在下级目录的子目录。然后，还可以确定每个目录的所有下级目录的自述文件中所包含的测试点的第二数量。接下来，可以计算上述第一数量与第二数量的加和，获得测试点的总数量。最后，可以在每个目录下展示测试点的总数量。
返回参照图5，图5示出的测试思维导图中的目录“demo”为目标目录，目录“test-dir-4”为存在下级目录（ “test-dir-4-1”和“test-dir-4-2”）的第二子目录。
针对目标目录demo，可以确定该目标目录demo下的自述文件所包含的测试点的第一数量。其中，该第一数量为0。然后，还可以确定目标目录demo的所有下级目录的自述文件中所包含的测试点的第二数量。例如，可以确定目标目录demo的所有下级目录：目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4”、目录“test-dir-4-1”和目录“test-dir-4-2”中每个下级目录的自述文件中所包含的测试点的第二数量。其中，上述6个下级目录中每个下级目录的自述文件中所包含的测试点的第二数量均可以为3。接下来，可以计算上述第一数量与第二数量的加和，获得测试点的总数量：0+3+3+3+3+3+3=18。最后，可以在目标目录demo的右侧展示测试点的总数量：“18 test points”。
或者，针对第二子目录“test-dir-4”，可以确定该第二子目录“test-dir-4”下的自述文件所包含的测试点的第一数量。其中，该第一数量为3。然后，还可以确定第二子目录“test-dir-4”的所有下级目录的自述文件中所包含的测试点的第二数量。例如，可以确定第二子目录“test-dir-4”的所有下级目录：目录“test-dir-4-1”和目录“test-dir-4-2”中每个下级目录的自述文件中所包含的测试点的第二数量。其中，上述2个下级目录中每个下级目录的自述文件中所包含的测试点的第二数量均可以为3。接下来，可以计算上述第一数量与第二数量的加和，获得测试点的总数量：3+3+3=9。最后，可以在第二子目录“test-dir-4”的右侧展示测试点的总数量：“9 test points”。
这样，如前所述，某个目录只有在和另一个目录的关系比较紧密的情况下，才可能成为该另一个目录的下级目录。因此，针对存在下级目录的目录，在确定该目录对应的测试点的数量时，除了要考虑该目录自身下面的自述文件中的测试点的数量，还需要考虑该目录的所有下级目录的自述文件中所包含的测试点的数量。这样，用户只需基于某个目录对应的测试点的数量，就可以大体判断出该目录的下级目录的自述文件中大致包含多少个测试点，便于用户对当前目录的下级目录到底对应多少个测试点有一个直观、清晰的了解。
根据本申请的示例性实施例，针对目标目录以及第二子目录中的每个目录，可以确定每个目录下测试回归用例的第三数量。然后，还可以确定每个目录的所有下级目录下的测试回归用例的第四数量。接下来，可以计算第三数量和第四数量的加和，获得测试回归用例的总数量。最后，可以在每个目录下展示测试回归用例的总数量。
返回参照图5，图5示出的测试思维导图中的目录“demo”为目标目录，目录“test-dir-4”为存在下级目录（ “test-dir-4-1”和“test-dir-4-2”）的第二子目录。
针对目标目录demo，可以确定该目标目录demo下的测试回归用例的第三数量。其中，该第三数量为2，分别为1.tcl和2.tcl。然后，还可以确定目标目录demo的所有下级目录下的测试回归用例的第四数量。例如，可以确定目标目录demo的所有下级目录：目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4”、目录“test-dir-4-1”和目录“test-dir-4-2”中每个下级目录下的测试回归用例的第四数量。其中，目录“test-dir-2”、 目录“test-dir-4”、目录“test-dir-4-1”中每个目录下的测试回归用例的第四数量均为1；目录“test-dir-3”、目录“test-dir-4-2”中每个目录下的测试回归用例的第四数量均为0；目录“test-dir-1”下的测试回归用例的第四数量为3。接下来，可以计算上述第三数量和第四数量的加和，获得测试回归用例的总数量：2+1+1+1+0+0+3=8。最后，可以在目标目录demo的右侧展示测试回归用例的总数量：“8 cases”。
或者，针对第二子目录“test-dir-4”，可以确定该第二子目录“test-dir-4”下的测试回归用例的第三数量。其中，该第三数量为1。然后，还可以确定第二子目录“test-dir-4”的所有下级目录下的测试回归用例的第四数量。例如，可以确定第二子目录“test-dir-4”的所有下级目录：目录“test-dir-4-1”和目录“test-dir-4-2”中每个下级目录下的测试回归用例的第四数量。其中，目录“test-dir-4-1”下的测试回归用例的第四数量为1；目录“test-dir-4-2”下的测试回归用例的第四数量为0。接下来，可以计算上述第三数量和第四数量的加和，获得测试回归用例的总数量：1+1+0=2。最后，可以在第二子目录“test-dir-4”的右侧展示测试回归用例的总数量：“2 cases”。
这样，如前所述，某个目录只有在和另一个目录的关系比较紧密的情况下，才可能成为该另一个目录的下级目录。因此，针对存在下级目录的目录，在确定该目录对应的测试回归用例的数量时，除了要考虑该目录自身下面的测试回归用例的数量，还需要考虑该目录的所有下级目录下的测试回归用例的数量。这样，用户只需基于某个目录对应的测试回归用例的数量，就可以大体判断出该目录的下级目录下大致包含多少个测试回归用例，便于用户对当前目录的下级目录到底对应多少个测试回归用例有一个直观、清晰的了解。
根据本申请的示例性实施例，上述第一命令内还可以包含附加选项。其中，该附加选项可以包含以下项中的至少一项：
展示脚本的使用手册（“-h”或“--help”选项），该附加选项主要用于展示代码实现脚本，即showmindmap脚本的使用手册。
待展示的目录，即可以利用一个参数（argument）指定需要展示测试思维导图的目标目录，例如上述示例中的目录demo。
只展示目录层级（“-d”选项），该附加选项主要用于控制测试思维导图仅展示目录层级，即控制自述文件（readme）；测试回归用例（case），即X.tcl；测试进度文件（statistics）等文件都不展示。
需要说明的是，如果第一命令中包含附加选项“-d”，则可以调用showmindmap脚本中的“__SHOW_TREE_D__”函数来展示测试思维导图，并且该测试思维导图中仅仅会展示目标目录以及各级子目录，并不会展示目录下的文件；如果第一命令中没有包含附加选项“-d”，则可以调用showmindmap脚本中的“__SHOW_TREE__”函数来展示测试思维导图。此时，该测试思维导图中会包含目标目录、该目标目录下的多级子目录以及每个目录下的各种类型的文件。除了打印结果有所不同，“__SHOW_TREE_D__”和“__SHOW_TREE__”这两个函数在总体执行流程上是类似的。
最大展示目录层级（“-l<level>”选项），该附加选项主要用于指定测试思维导图中的最大展示目录层级。
示例性的，返回参照图5，目标目录demo的展示层级为第0级；目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4”的展示层级为第1级；目录“test-dir-4-1”和目录“test-dir-4-2” 的展示层级为第2级。如果用户在第一命令中指定“最大展示目录层级”为第1级，则测试思维导图中仅仅会展示目标目录demo；目标目录demo下的自述文件（readme）、测试回归用例（1.tcl，2. tcl）、测试进度文件（statistics）；以及目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4”。而其他的目录和/或文件由于其对应的展示层级均超过第1级，因此，这些展示层级超过第1级的目录和/或文件均不会在测试思维导图上进行展示。
打印时禁止携带颜色（“--color=none”选项），该附加选项主要用于控制在打印测试思维导图时禁止携带颜色。
禁止展示测试进度文件（“--ignore=statistics”选项），该附加选项主要用于控制在打印测试思维导图时禁止展示“statistics”文件。
禁止展示自述文件和测试进度文件（“--ignore”选项），该附加选项主要用于控制在打印测试思维导图时禁止展示自述文件和测试进度文件。
展示后禁止保留生成的测试进度文件（statistics）（“--clean”选项），该附加选项主要用于控制在打印测试思维导图之后不保留统计生成的“statistics”文件。
可以按照第一命令所包含的附加选项，获取并在终端工具上展示目标目录对应的树状图作为目标测试项目的测试思维导图。
这样，用户可以根据自身需要决定在第一命令中包含哪些附加选项，进而可以在展示测试思维导图时实现相应的功能，即用户可以自主决定测试思维导图具体展示为什么样的形式，展示测试思维导图的自主性和灵活性更好。
根据本申请的示例性实施例，在第一命令中包含“打印时禁止携带颜色”的选项的情况下，可以按照目标***中所预先设置的默认颜色打印并在终端工具上展示测试思维导图，即可以按照Linux***中所预先设置的默认颜色打印测试思维导图。示例性的，Linux***中所预先设置的默认颜色可以为黑色。
在第一命令中不包含“打印时禁止携带颜色”的选项的情况下，可以基于目标脚本中针对各个对象所预先设置的展示颜色，打印各个对象以在终端工具上展示测试思维导图。
需要说明的是，可以预先在目标脚本，即showmindmap脚本中设置不同类型的颜色变量。示例性的，showmindmap脚本中可以包含但不限于以下颜色变量：“默认：cdefault”、“目录：cdirectory”、“可执行文件：cfileexe”、“文档：cfilers”、“字符串：cstrred、cstrblue、cstrgreen、cstryellow、cstrbred”。
如果第一命令中包含附加选项“--color=none”或“--color=NONE”，则可以将showmindmap脚本中所包含的各个颜色变量（例如cdefault、cdirectory等）的赋值设置为空。此时，就会按照Linux***中所预先设置的默认颜色打印测试思维导图。
如果第一命令中不包含附加选项“--color=none”或“--color=NONE”，则可以按照showmindmap脚本中预先设置的自定义颜色，为各个颜色变量进行赋值。示例性的，可以预先在showmindmap脚本中设置“目录：cdirectory”这个颜色变量对应的展示颜色为蓝色。这样，在实际打印测试思维导图时，就可以根据showmindmap脚本中针对“目录：cdirectory”这个颜色变量的颜色设置将测试思维导图中的目录打印为蓝色。
进一步的，"\033\[0m"、"\033\[1;34m"、"\033\[32m"等变量值可以是TCL脚本语言自带的字体值和/或色号值。例如，"\033\[1;34m"中的“1”可以表示字体加粗；“34”可以表示色号。这两部分的取值可以调整，而其余部分则是固定用法。
这样，用户可以根据自身需要在showmindmap脚本中预先设置各个颜色变量的取值，进而可以利用不同的颜色打印不同的对象，可以实现向用户呈现一个不同类型对象之间界限分明、架构清晰的测试思维导图，便于用户快速、准确的了解整个测试思维导图的组织架构和成分组成。
根据本申请的示例性实施例，目标脚本还可以用于生成目标目录以及多级子目录中每个目录对应的测试进度文件。其中，任一目录对应的测试进度文件可以用于指示任一目录下的测试进度。即在目标***内调用目标脚本之后，还可以在目标***内接收输入于终端工具的第二命令。其中，该第二命令中可以包含指定目录的路径名称，该指定目录可以为目标目录或者多级子目录的其中之一。接下来，响应于第二命令，可以在终端工具上打印指定目录下的测试进度文件中的内容。
示例性的，返回参照图5，图5示出的测试思维导图中包含目标目录demo以及目标目录demo的多级子目录，这些目录中的每个目录下均对应有一个测试进度文件（statistics）。用户只需在第二命令中填入在上述目录中指定的一个目录，就可以实现展示该指定目录下的测试进度文件所包含的具体内容。这样，用户可以根据自身需要决定到底展示哪个目录下的测试进度文件的内容，展示目录对应的测试进度的自主性和灵活性较好。
根据本申请的示例性实施例，可以在终端工具上打印指定目录下的测试进度文件中所包含的以下至少一项：
指定目录对应的测试点的数量、指定目录对应的测试回归用例的数量、指定目录对应的测试点中已经完成测试的测试点数量与指定目录对应的全部测试点数量之间的百分比；指定目录下的自述文件对应的文件测试状态、指定目录下的自述文件所包含的测试点中尚未启动测试的测试点、指定目录下的自述文件所包含的测试点中已经完成测试的测试点数量与自述文件所包含的全部测试点数量之间的百分比。
示例性的，以“cat demo/statistics”为第二命令为例，即假设第二命令中所包含的指定目录为目标目录demo。
其中，第二命令“cat demo/statistics”中的“cat”是“concatenate”的缩写，其用于直接从终端创建、查看和连接文件，主要用于在不打开图形文本编辑器的情况下预览文件。第二命令“cat demo/statistics”中的“demo/statistics”表示目标目录demo下的“statistics”文件。
以下为执行第二命令“cat demo/statistics”之后所展示的测试进度文件中的内容：
YYY@ip-111111111111: ~ ]cat demo/statistics
The total number of the test points：18
The total number of the regression cases：8
The rate of progress（finished-test-point-num/ total-test-point-num）：8/18=44%
-- home/YYY/demo：done
-- home/YYY/demo/ test-dir-1：done
--The rate of progress of the home/YYY/demo/ test-dir-1：3/3=100%
-- home/YYY/demo/ test-dir-2：ongoing
-- test1 is not being tested
-- test3 is not being tested
-- The rate of progress of the home/YYY/demo/ test-dir-2：1/3=33%
-- home/YYY/demo/ test-dir-3：nostart
-- test1 is not being tested
-- test2 is not being tested
-- test3 is not being tested
-- The rate of progress of the home/YYY/demo/ test-dir-3：0/3=0%
-- home/YYY/demo/ test-dir-4：ongoing
-- test2 is not being tested
-- test3 is not being tested
-- The rate of progress of the home/YYY/demo/ test-dir-4：1/3=33%
-- home/YYY/demo/ test-dir-4/test-dir-4-1：done
--The rate of progress of the home/YYY/demo/ test-dir-4/ test-dir-4-1：3/3=100%
-- home/YYY/demo/ test-dir-4/test-dir-4-2：nostart
-- test1 is not being tested
-- test2 is not being tested
-- test3 is not being tested
-- The rate of progress of the home/YYY/demo/test-dir-4/test-dir-4-2：0/3=0%
由上述执行第二命令“cat demo/statistics”之后所展示的测试进度文件中的内容可知，目标目录demo下的“statistics”文件中包含目标目录demo对应的测试点的数量：“The total number of the test points：18”；目标目录demo对应的测试回归用例的数量：“The total number of the regression cases：8”；目标目录demo对应的测试点中已经完成测试的测试点数量与目标目录demo对应的全部测试点数量之间的百分比：“Therate of progress（finished-test-point-num/ total-test-point-num）：8/18=44%”。
并且，如前所述，由于目标目录demo下的自述文件中所包含的测试点的数量为0，即目标目录demo下的自述文件中不包含任何测试点，因此，目标目录demo下的自述文件对应的文件测试状态可以直接被确定为“完成状态done”，即“-- home/YYY/demo：done”。
进一步的，目标目录demo的测试进度文件中还可以包含目标目录demo下的各级子目录下的自述文件中所包含的测试点的测试情况。例如，还可以示出目标目录demo下的多级子目录：目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4”、目录“test-dir-4-1”和目录“test-dir-4-2”中每个子目录下的自述文件中所包含的测试点的测试状况。
其中，针对子目录“test-dir-1”，其下的自述文件中一共包含3个测试点，并且这3个测试点均已测试完毕。因此，子目录“test-dir-1”下的自述文件对应的文件测试状态为完成状态：“-- home/YYY/demo/ test-dir-1：done”；子目录“test-dir-1”下的自述文件所包含的测试点中已经完成测试的测试点数量与自述文件所包含的全部测试点数量之间的百分比为100%：“The rate of progress of the home/YYY/demo/ test-dir-1：3/3=100%”。
针对子目录“test-dir-2”，其下的自述文件中一共包含3个测试点，并且这3个测试点中有两个测试点还没有被测试：“test1 is not being tested；test3 is not beingtested”。因此，子目录“test-dir-2”下的自述文件对应的文件测试状态为正在测试中状态：“-- home/YYY/demo/ test-dir-2：ongoing”；子目录“test-dir-2”下的自述文件所包含的测试点中已经完成测试的测试点数量与自述文件所包含的全部测试点数量之间的百分比为33%：“The rate of progress of the home/YYY/demo/ test-dir-2：1/3=33%”。
针对子目录“test-dir-3”，其下的自述文件中一共包含3个测试点，并且这3个测试点全都没有被测试：“test1 is not being tested、test2 is not being tested、test3is not being tested”。因此，子目录“test-dir-3”下的自述文件对应的文件测试状态为尚未启动测试状态：“-- home/YYY/demo/ test-dir-3：nostart”；子目录“test-dir-3”下的自述文件所包含的测试点中已经完成测试的测试点数量与自述文件所包含的全部测试点数量之间的百分比为0%：“The rate of progress of the home/YYY/demo/ test-dir-3：0/3=0%”。
针对子目录“test-dir-4”，其下的自述文件中一共包含3个测试点，并且这3个测试点中存在两个测试点尚未被测试：“test2 is not being tested、test3 is not beingtested”。因此，子目录“test-dir-4”下的自述文件对应的文件测试状态为正在测试中状态：“-- home/YYY/demo/ test-dir-4：ongoing”；子目录“test-dir-4”下的自述文件所包含的测试点中已经完成测试的测试点数量与自述文件所包含的全部测试点数量之间的百分比为33%：“The rate of progress of the home/YYY/demo/ test-dir-4：1/3=33%”。
针对子目录“test-dir-4-1”，其下的自述文件中一共包含3个测试点，并且这3个测试点全都已经被测试完毕，因此，子目录“test-dir-4-1”下的自述文件对应的文件测试状态为完成状态：“-- home/YYY/demo/test-dir-4/ test-dir-4-1：done”；子目录“test-dir-4-1”下的自述文件所包含的测试点中已经完成测试的测试点数量与自述文件所包含的全部测试点数量之间的百分比为100%：“The rate of progress of the home/YYY/demo/test-dir-4/ test-dir-4-1：3/3=100%”。
针对子目录“test-dir-4-2”，其下的自述文件中一共包含3个测试点，并且这3个测试点全都没有被测试：“test1 is not being tested、test2 is not being tested、test3 is not being tested”。因此，子目录“test-dir-4-2”下的自述文件对应的文件测试状态为尚未启动测试状态：“-- home/YYY/demo/test-dir-4/ test-dir-4-2：nostart”；子目录“test-dir-4-2”下的自述文件所包含的测试点中已经完成测试的测试点数量与自述文件所包含的全部测试点数量之间的百分比为0%：“The rate of progress of thehome/YYY/demo/test-dir-4/ test-dir-4-2：0/3=0%”。
或者，假设第二命令为“cat demo/test-dir-4/statistics”，即假设用户在第二命令中指令的目录为目录“test-dir-4”，则执行第二命令“cat demo/test-dir-4/statistics”之后就可以展示目录“test-dir-4”下的测试进度文件的内容。
示例性的，可以展示以下项中的至少一项：
test-dir-4对应的测试点的数量：“The total number of the test points：9”；test-dir-4对应的测试回归用例的数量：“The total number of the regression cases：2”；test-dir-4对应的测试点中已经完成测试的测试点数量与test-dir-4对应的全部测试点数量之间的百分比；test-dir-4下的自述文件对应的文件测试状态，即test-dir-4下的自述文件所包含的3个测试点的测试状态；test-dir-4下的自述文件所包含的3个测试点中尚未启动测试的测试点；test-dir-4下的自述文件所包含的3个测试点中已经完成测试的测试点数量与自述文件所包含的全部测试点数量3之间的百分比。
这样，通过在测试进度文件中设置与测试点、测试回归用例相关的多项内容，便于用户对相应目录下的测试进度有一个清晰全面的了解，方便用户对相应目录下的测试状况有一个全方位的把控。
根据本申请的示例性实施例，在指定目录下的自述文件所包含的测试点均已完成测试的情况下，可以确定指定目录下的自述文件对应的文件测试状态为完成状态done；在指定目录下的自述文件所包含的测试点均未启动测试的情况下，可以确定指定目录下的自述文件对应的文件测试状态为尚未启动测试状态nostart；否则，可以确定指定目录下的自述文件对应的文件测试状态为正在测试中状态ongoing。
示例性的，返回参照上述示出的目标目录demo的测试进度文件的内容，针对目录“test-dir-4-1”，由于该目录下的自述文件中所包含的3个测试点均已测试完毕，因此，可以确定该目录“test-dir-4-1”下的自述文件对应的文件测试状态为完成状态done；针对目录“test-dir-4-2”，由于该目录下的自述文件中所包含的3个测试点均未启动测试：“test1is not being tested、test2 is not being tested、test3 is not being tested”，因此，可以确定该目录“test-dir-4-2”下的自述文件对应的文件测试状态为尚未启动测试状态nostart；针对目录“test-dir-4”，由于该目录下的自述文件内所包含的3个测试点中存在两个测试点尚未被测试：“test2 is not being tested、test3 is not being tested”，因此，可以确定该目录“test-dir-4”下的自述文件对应的文件测试状态为正在测试中状态ongoing。
根据本申请的示例性实施例，还可以以目标目录为起点，通过递归遍历的方式，依次对目标目录下的目录和/或文件进行打印，直至目标目录、多级子目录、目标目录下的文件以及多级子目录下的文件均被遍历完成。即还可以以目标目录demo为起点，通过递归遍历的方式，依次对目标目录demo下的目录和/或文件进行打印，直至目标目录demo、多级子目录（目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4”、目录“test-dir-4-1”和目录“test-dir-4-2”）、目标目录demo下的文件以及多级子目录下的文件均被遍历完成。
其中，针对每一次遍历，可以执行以下操作：
获取当前遍历对象的类型。其中，当前遍历对象的类型可以包含两种，分别为“目录”类型和“文件”类型。
在当前遍历对象的类型为文件的情况下，可以基于目标脚本中针对文件所预先设置的展示颜色，打印当前遍历对象。需要说明的是，用户可以在showmindmap脚本中预先设置不同种类文件的展示颜色。示例性的，可以预先设置测试回归用例.tcl文件的展示颜色为黑色、预先设置自述文件的展示颜色为蓝绿色等等。这样，在实际打印测试思维导图时，就可以根据showmindmap脚本中针对不同种类文件所预先设置的展示颜色打印相应的文件。
在当前遍历对象的类型为目录的情况下，可以获取当前遍历对象对应的目录测试状态、测试点的数量以及测试回归用例的数量，进而可以基于目标脚本中针对目录所预先设置的展示颜色，打印当前遍历对象，并可以基于目标脚本中针对字符串所预先设置的展示颜色，在当前遍历对象下打印当前遍历对象对应的目录测试状态、测试点的数量以及测试回归用例的数量。
需要说明的是，用户可以在showmindmap脚本中预先设置目录以及不同种类字符串的展示颜色。示例性的，可以预先设置目录的展示颜色为蓝色、预先设置测试点的数量以及测试回归用例的数量这两种字符串的展示颜色为黄色、预先设置“完成测试”这种目录测试状态的展示颜色为绿色、“正在测试中”这种目录测试状态的展示颜色为紫色、“尚未启动测试”这种目录测试状态的展示颜色为红色等等。这样，在实际打印测试思维导图时，就可以根据showmindmap脚本中针对目录以及各种字符串所预先设置的展示颜色打印相应的对象。
这样，通过递归遍历的方式打印各个目录和/或文件，可以避免任何一个目录或者文件被遗漏掉。并且，通过在showmindmap脚本中预先设置不同类型对象的展示颜色，可以实现向用户呈现一个不同类型对象之间界限分明、架构清晰的测试思维导图，便于用户快速、准确的了解整个测试思维导图的组织架构、成分组成以及测试状况。
需要说明的是，还可以在showmindmap脚本中预先设置用于连接不同目录以及连接目录和文件的连接符号变量。示例性的，可以在showmindmap脚本中预先设置以下代表不同部位的连接符号变量：
第一对齐符号：branch_vline，在指定目录不是其上一层级目录中的最后一个元素（元素指代目录或文件）的情况下，针对该指定目录中的元素来使用；
第二对齐符号：branch_null，在指定目录是其上一层级目录中的最后一个元素的情况下，针对该指定目录中的元素来使用；
中间分支符号：middle_branch_end，在指定目录中的元素不是该指定目录中的最后一个元素的情况下使用；
最后分支符号：last_branch_end，在指定目录中的元素为该指定目录中的最后一个元素的情况下使用；
层级对齐变量：branch_sum，用于与“branch_vline”或“branch_null”相配合，从而在打印测试思维导图时将各层级分支对齐。
进一步的，还可以在showmindmap脚本中为不同的连接符号变量预先设置对应的树状结构连接符号。示例性的，第一对齐符号：branch_vline对应的树状结构连接符号可以为：“|··”；第二对齐符号：branch_null对应的树状结构连接符号可以为：“···”；中间分支符号：middle_branch_end对应的树状结构连接符号可以为：“├──”；最后分支符号：last_branch_end对应的树状结构连接符号可以为：“└──”。
根据本申请的示例性实施例，在当前待打印的元素为目标目录所直接包含的元素的情况下，可以判断当前待打印的元素是否为目标目录下的最后一个元素。其中，如前所述，这里的“元素”的含义可以为“目录”，也可以为“文件”。图7是示出根据本申请的示例性实施例的一种利用树状结构连接符号连接各个目录以及文件所获得的树状图。参照图7，目标目录demo下一共直接包含7个元素，按先后顺序分别为目录“test-dir-1”、目录“test-dir-2”、目录“test-dir-3”、目录“test-dir-4”、自述文件（readme）、1.tcl和2.tcl。针对这7个元素中的任一个元素，可以判断该任一个元素是否为目标目录demo下的最后一个元素。
在当前待打印的元素不为目标目录下的最后一个元素的情况下，可以利用预设第一符号在树状图中连接目标目录与该当前待打印的元素。示例性的，假设当前待打印的元素为目录“test-dir-2”，由于目录“test-dir-2”为目录demo下的第2个元素，即目录“test-dir-2”不为目标目录demo下的最后一个元素，因此，可以利用预设第一符号在树状图中连接目标目录demo与该当前待打印的元素：目录“test-dir-2”。其中，“预设第一符号”可以为上述中间分支符号：“├──”。
否则，即在当前待打印的元素为目标目录下的最后一个元素的情况下，可以利用预设第二符号在树状图中连接目标目录与该当前待打印的元素。示例性的，返回参照图7，假设当前待打印的元素为目标目录demo下的2.tcl文件，由于“2.tcl文件”为目标目录demo下的第7个元素，即“2.tcl文件”为目标目录demo下的最后一个元素，因此，可以利用预设第二符号在树状图中连接目标目录demo与该当前待打印的元素：“2.tcl文件”。其中，“预设第二符号”可以为上述最后分支符号：“└──”。
这样，通过基于当前待打印的元素在所属目录中的位置，来利用不同类型的树状结构连接符号来连接当前待打印的元素与所属目录，可以实现向用户呈现一个等级分明、层次清晰的测试思维导图，便于用户快速、准确的梳理不同目录之间、文件与目录之间的架构关系。
根据本申请的示例性实施例， 在当前待打印的元素为目标目录所间接包含的元素的情况下，针对当前待打印的元素的各层级上级目录中的每个目录，可以判断该每个目录是否为该每个目录的直接上级目录下的最后一个元素。图8是示出根据本申请的示例性实施例的另一种利用树状结构连接符号连接各个目录以及文件所获得的树状图。参照图8，目标目录demo下一共直接包含7个元素，按先后顺序分别为自述文件（readme）、a.tcl、b.tcl、目录“zz-dir-1”、目录“zz-dir-2”、目录“zz-dir-3”、目录“zz-dir-4”。而目录“zz-dir-1”、目录“zz-dir-2”、目录“zz-dir-3”、目录“zz-dir-4”中每个目录下面的分支目录以及文件则为目标目录demo所间接包含的元素。
在每个目录不为每个目录的直接上级目录下的最后一个元素的情况下，可以利用预设第三符号在树状图中连接直接上级目录与该当前待打印的元素。其中，“预设第三符号”可以为上述第一对齐符号：“|··”。
示例性的，返回参照图8，针对目录“zz-dir-1”下面的自述文件（readme），该自述文件（readme）的上级目录为目录“zz-dir-1”，由于该上级目录 “zz-dir-1”为该上级目录“zz-dir-1”的直接上级目录demo下的第4个元素，即该上级目录“zz-dir-1”不为该上级目录“zz-dir-1”的直接上级目录demo下的最后一个元素，因此，可以利用预设第三符号在树状图中连接直接上级目录demo与该当前待打印的元素：目录“zz-dir-1”下面的自述文件（readme），进而可以获得这样的树状结构：“|··├──readme”，具体见图8中的（A）。
否则，即在每个目录为每个目录的直接上级目录下的最后一个元素的情况下，可以利用预设第四符号在树状图中连接直接上级目录与当前待打印的元素。其中，“预设第四符号”可以为上述第二对齐符号：“···”。
示例性的，返回参照图8，针对目录“zz-dir-4”下面的1.tcl文件，该“1.tcl文件”的上级目录为目录“zz-dir-4”，由于该上级目录 “zz-dir-4”为该上级目录 “zz-dir-4”的直接上级目录demo下的第7个元素，即该上级目录“zz-dir-4”为该上级目录“zz-dir-4”的直接上级目录demo下的最后一个元素，因此，可以利用预设第四符号在树状图中连接直接上级目录demo与该当前待打印的元素：目录“zz-dir-4”下面的1.tcl文件，进而可以获得这样的树状结构：“···├──1.tcl”，具体见图8中的（B）。
或者，返回参照图8，针对目录“zz-dir-2-1”下面的自述文件（readme），该“自述文件（readme）”一共存在两个上级目录，分别为目录“zz-dir-2-1”和目录“zz-dir-2”。其中，针对上级目录“zz-dir-2-1”，由于该上级目录 “zz-dir-2-1”为该上级目录 “zz-dir-2-1”的直接上级目录“zz-dir-2”下的第3个元素，即该上级目录“zz-dir-2-1”为该上级目录“zz-dir-2-1”的直接上级目录“zz-dir-2”下的最后一个元素，因此，可以利用预设第四符号在树状图中连接直接上级目录“zz-dir-2”与该当前待打印的元素：目录“zz-dir-2-1”下面的自述文件（readme），进而可以获得这样的树状结构：“···├──readme”，具体见图8中的（C1）。
进一步的，针对上级目录“zz-dir-2”，由于该上级目录 “zz-dir-2”为该上级目录“zz-dir-2”的直接上级目录“demo”下的第5个元素，即该上级目录“zz-dir-2”不为该上级目录“zz-dir-2”的直接上级目录“demo”下的最后一个元素，因此，可以利用预设第三符号在树状图中连接直接上级目录“demo”与该当前待打印的元素：目录“zz-dir-2-1”下面的自述文件（readme），进而可以获得这样的树状结构：“|·····├──readme”，具体见图8中的（C2）。
或者，返回参照图8，针对目录“zz-dir-4-1”下面的1.tcl，该“1.tcl”一共存在两个上级目录，分别为目录“zz-dir-4-1”和目录“zz-dir-4”。其中，针对上级目录“zz-dir-4-1”，由于该上级目录“zz-dir-4-1”为该上级目录 “zz-dir-4-1”的直接上级目录“zz-dir-4”下的第3个元素，即该上级目录“zz-dir-4-1”不为该上级目录“zz-dir-4-1”的直接上级目录“zz-dir-4”下的最后一个元素，因此，可以利用预设第三符号在树状图中连接直接上级目录“zz-dir-4”与该当前待打印的元素：目录“zz-dir-4-1”下面的1.tcl，进而可以获得这样的树状结构：“|··└──1.tcl”，具体见图8中的（D1）。
进一步的，针对上级目录“zz-dir-4”，由于该上级目录 “zz-dir-4”为该上级目录“zz-dir-4”的直接上级目录“demo”下的第7个元素，即该上级目录“zz-dir-4”为该上级目录“zz-dir-4”的直接上级目录“demo”下的最后一个元素，因此，可以利用预设第四符号在树状图中连接直接上级目录“demo”与该当前待打印的元素：目录“zz-dir-4-1”下面的1.tcl，进而可以获得这样的树状结构：“···|··└──1.tcl”，具体见图8中的（D2）。
这样，通过基于当前待打印的元素在所属目录中的位置以及当前待打印的元素的各层级上级目录在相应的直接上级目录中的位置，来利用不同类型的树状结构连接符号来连接当前待打印的元素与各层级上级目录，可以实现向用户呈现一个等级分明、层次清晰的测试思维导图，便于用户快速、准确的梳理不同目录之间、文件与目录之间的架构关系。
下面，以具体的示例来说明“branch_sum”与“branch_vline”相配合的过程。具体地说，在打印指定目录中的元素fn时，其格式可以为“{branch_sum}/>{middle_branch_end}/>{fn}”，其中，其具体配合方式可以如下：/>
在目标目录层级时，branch_sum的初始赋值可以为空，即在打印第一层级的元素时，branch_sum可以为空，从而在相应元素前不打印branch_vline，此时该相应元素的打印结果可以为：“├──{fn}”或者为“└──/>{fn}”。
示例性的，返回参照图8，图8中的目标目录demo为第0级元素，而目录“zz-dir-1”、目录“zz-dir-2”、目录“zz-dir-3”、目录“zz-dir-4”则属于第1级元素，这样，在打印第一层级的元素时，branch_sum可以为空，即在相应元素前不打印branch_vline，此时该相应元素的打印结果可以为“├──{fn}”或者为“└──/>{fn}”。例如，目录“zz-dir-1”的打印结果可以为“├──zz-dir-1”，目录“zz-dir-4”的打印结果可以为“└──zz-dir-4”等等。
在打印第二层级中的元素时，通过“set branch_sum"{branch_sum}/>{branch_vline}"”将branch_sum赋值增加/>{branch_vline}，从而可以在相应元素前打印1次branch_vline，此时该相应元素的打印结果可以为“|··├──/>{fn}”或者为“|··└──/>{fn}”。
示例性的，返回参照图8，目录“zz-dir-2”下的自述文件（readme）、1.tcl、目录“zz-dir-2-1”均属于第二层级的元素，此时，可以通过“set branch_sum"{branch_sum}/>{branch_vline}"”将branch_sum赋值增加/>{branch_vline}，从而可以在相应元素前打印1次branch_vline，此时该相应元素的打印结果可以为“|··├──/>{fn}”或者为“|··└──/>{fn}”。例如，目录“zz-dir-2”下的自述文件（readme）的打印结果可以为“|··├──readme”、目录“zz-dir-2”下的1.tcl的打印结果可以为“|··├──1.tcl”、目录“zz-dir-2”的下级目录“zz-dir-2-1”的打印结果可以为“|··└──zz-dir-2-1”。
在打印第三层级中的元素时，可以再次通过“set branch_sum"{branch_sum}/>{branch_vline}"”将branch_sum赋值增加/>{branch_vline}，从而在相应元素前打印2次branch_vline，此时，该相应元素的打印结果可以为“|·····├─/>{fn}”、“|·····└──/>{fn}”、“···|··├──/>{fn}”、“···|··└──/>{fn}”、“······└──/>{fn}”等等。
示例性的，返回参照图8，目录“zz-dir-2-1”下的自述文件（readme）、1.tcl均为第三层级的元素，此时，目录“zz-dir-2-1”下的自述文件（readme）的打印结果可以为“|·····├─readme”；目录“zz-dir-2-1”下的1.tcl的打印结果可以为“|·····└──1.tcl”。或者，目录“zz-dir-4-2”下的自述文件（readme）为第三层级的元素，此时，目录“zz-dir-4-2”下的自述文件（readme）的打印结果可以为“······└──readme”。在打印后续层级中的元素时，以此类推，这里不再赘述。
需要说明的是，在递归打印的过程中，当从下一层级的元素回退到上一层级的元素时，可以通过“set branch_sum [string range{branch_sum} 0 end-[string length{branch_vline}]]”将branch_sum的赋值减少1次/>{branch_vline}。
返回参照图7和图8，图7和图8为树状结构连接符号的打印结果的两种示例。其中，图7中的示例主要示出了“branch_sum”与“branch_vline”相配合的情况，包括“|··├──{fn}”、“|··|··├──/>{fn}”、“|··└──/>{fn}”等等；图8中的示例主要示出了“branch_sum”与“branch_null”相配合的情况，包括“···├──/>{fn}”、“|··├──/>{fn}”、“···|··├──/>{fn}”、“···└─/>{fn}”等等。/>
图9是示出根据本申请的示例性实施例的测试思维导图的展示装置的框图。
参照图9，该测试思维导图的展示装置900可包括第一命令接收模块901和测试思维导图展示模块902。其中，第一命令接收模块901用于在目标***内接收输入于终端工具的第一命令。其中，该第一命令可以用于指示基于目标脚本在终端工具上以树状图形式打印目标目录下的目录和/或文件，目标目录可以包含多级子目录，目标目录及其多级子目录可以根据目标测试项目被预先创建，目标目录以及多级子目录中的至少一个目录下可以添加有针对至少一个目录对应的测试点进行测试所获得的测试回归用例。并且，测试思维导图展示模块902用于响应于第一命令，在目标***内调用目标脚本，以获取并在终端工具上展示目标目录对应的树状图作为目标测试项目的测试思维导图。
根据本申请的示例性实施例，展示装置900还可以包括其他信息展示模块。其中，该其他信息展示模块用于在测试思维导图中展示目标目录以及多级子目录中各个目录对应的自述文件、测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项。其中，任一目录对应的自述文件可以包含任一目录的介绍信息、测试点信息以及分支目录的信息。
根据本申请的示例性实施例，其他信息展示模块还可以用于针对每个第一子目录，根据第一子目录下的自述文件中所包含的测试点与第一子目录下的测试回归用例所包含的测试点的重合情况，确定第一子目录的目录测试状态，并可以在第一子目录下展示目录测试状态。其中，第一子目录可以为多级子目录中不存在下级目录的子目录。
根据本申请的示例性实施例，其他信息展示模块还可以用于针对目标目录和第二子目录中的每个目录，根据每个目录下的自述文件中所包含的测试点的测试状态以及每个目录的下级目录的目录测试状态，确定每个目录的目录测试状态，并可以在每个目录下展示目录测试状态。其中，第二子目录可以为多级子目录中存在下级目录的子目录。
根据本申请的示例性实施例，其他信息展示模块还可以用于针对每个第一子目录，确定第一子目录下的自述文件中所包含的测试点的数量。其中，第一子目录可以为多级子目录中不存在下级目录的子目录。然后，可以在第一子目录下展示自述文件中所包含的测试点的数量。
根据本申请的示例性实施例，其他信息展示模块还可以用于针对目标目录以及第二子目录中的每个目录，确定每个目录下的自述文件所包含的测试点的第一数量。其中，第二子目录可以为多级子目录中存在下级目录的子目录。然后，可以确定每个目录的所有下级目录的自述文件中所包含的测试点的第二数量。接下来，可以计算第一数量与第二数量的加和，获得测试点的总数量。最后，可以在每个目录下展示测试点的总数量。
根据本申请的示例性实施例，其他信息展示模块还可以用于针对目标目录以及第二子目录中的每个目录，确定每个目录下测试回归用例的第三数量。然后，可以确定每个目录的所有下级目录下的测试回归用例的第四数量。接下来，可以计算第三数量和第四数量的加和，获得测试回归用例的总数量。最后，可以在每个目录下展示测试回归用例的总数量。
根据本申请的示例性实施例，目标脚本还可以用于生成目标目录以及多级子目录中每个目录对应的测试进度文件。其中，任一目录对应的测试进度文件用于指示任一目录下的测试进度。展示装置900还可以包括第二命令接收模块和测试进度文件打印模块。其中，第二命令接收模块用于在目标***内接收输入于终端工具的第二命令。其中，该第二命令中可以包含指定目录的路径名称，指定目录可以为目标目录或者多级子目录的其中之一。测试进度文件打印模块用于响应于第二命令，在终端工具上打印指定目录下的测试进度文件中的内容。
根据本申请的示例性实施例，测试进度文件打印模块可以用于在终端工具上打印指定目录下的测试进度文件中所包含的以下至少一项：指定目录对应的测试点的数量、指定目录对应的测试回归用例的数量、指定目录对应的测试点中已经完成测试的测试点数量与指定目录对应的全部测试点数量之间的百分比；指定目录下的自述文件对应的文件测试状态、指定目录下的自述文件所包含的测试点中尚未启动测试的测试点、指定目录下的自述文件所包含的测试点中已经完成测试的测试点数量与自述文件所包含的全部测试点数量之间的百分比。
根据本申请的示例性实施例，展示装置900还可以包括完成状态确定模块、尚未启动测试状态确定模块和正在测试中状态确定模块。其中，完成状态确定模块用于在指定目录下的自述文件所包含的测试点均已完成测试的情况下，确定指定目录下的自述文件对应的文件测试状态为完成状态；尚未启动测试状态确定模块用于在指定目录下的自述文件所包含的测试点均未启动测试的情况下，确定指定目录下的自述文件对应的文件测试状态为尚未启动测试状态；正在测试中状态确定模块用于：否则，确定指定目录下的自述文件对应的文件测试状态为正在测试中状态。
根据本申请的示例性实施例，第一命令内还可以包含附加选项。其中，该附加选项可以包含以下项中的至少一项：展示脚本的使用手册、待展示的目录、只展示目录层级、最大展示目录层级、打印时禁止携带颜色、禁止展示测试进度文件、禁止展示自述文件和测试进度文件、展示后禁止保留生成的测试进度文件。测试思维导图展示模块902还可以用于按照第一命令所包含的附加选项，获取并在终端工具上展示目标目录对应的树状图作为目标测试项目的测试思维导图。
根据本申请的示例性实施例，测试思维导图展示模块902还可以用于在第一命令中包含打印时禁止携带颜色的选项的情况下，按照目标***中所预先设置的默认颜色打印并在终端工具上展示测试思维导图；以及，在第一命令中不包含打印时禁止携带颜色的选项的情况下，基于目标脚本中针对各个对象所预先设置的展示颜色，打印各个对象以在终端工具上展示测试思维导图。
根据本申请的示例性实施例，测试思维导图展示模块902还可以用于以目标目录为起点，通过递归遍历的方式，依次对目标目录下的目录和/或文件进行打印，直至目标目录、多级子目录、目标目录下的文件以及多级子目录下的文件均被遍历完成。其中，针对每一次遍历，可以执行以下操作：获取当前遍历对象的类型；在类型为文件的情况下，可以基于目标脚本中针对文件所预先设置的展示颜色，打印当前遍历对象；在类型为目录的情况下，可以获取当前遍历对象对应的目录测试状态、测试点的数量以及测试回归用例的数量。接下来，可以基于目标脚本中针对目录所预先设置的展示颜色，打印当前遍历对象，并可以基于目标脚本中针对字符串所预先设置的展示颜色，在当前遍历对象下打印当前遍历对象对应的目录测试状态、测试点的数量以及测试回归用例的数量。
根据本申请的示例性实施例，展示装置900还可以包括判断模块、第一执行模块和第二执行模块。其中，判断模块用于判断第一命令中是否包含目录的路径名称；第一执行模块用于在第一命令中包含路径名称的情况下，将路径名称对应的目录作为目标目录；第二执行模块用于：否则，将目标***的当前工作目录作为目标目录。
根据本申请的示例性实施例，展示装置900还可以包括目录创建模块、自述文件创建模块和测试回归用例添加模块。其中，目录创建模块用于根据目标测试项目创建目标目录以及多级子目录；自述文件创建模块用于在目标目录以及多级子目录中的每个目录下创建自述文件；测试回归用例添加模块用于按照第一预设格式在每个目录下的自述文件中编写目标测试项目中相应的测试点，并可以在至少一个目录下添加测试回归用例。其中，测试回归用例可以为针对至少一个目录下的自述文件中所编写的至少一个测试点进行测试所获得的测试回归用例。
根据本申请的示例性实施例，测试回归用例可以包含以下至少一项：按照第二预设格式指定的所编写的至少一个测试点，用于验证所编写的至少一个测试点的验证数据、用于验证所编写的至少一个测试点的模拟人工操作步骤、期望结果、验证结果、期望结果与验证结果是否匹配的指示信息、所编写的至少一个测试点验证是否通过的结论信息；其中，验证结果为基于验证数据执行模拟人工操作步骤之后获得的结果；期望结果为基于验证数据执行模拟人工操作步骤之后应当获得的准确结果。
根据本申请的示例性实施例，测试思维导图展示模块902还可以用于在当前待打印的元素为目标目录所直接包含的元素的情况下，判断当前待打印的元素是否为目标目录下的最后一个元素。在当前待打印的元素不为目标目录下的最后一个元素的情况下，可以利用预设第一符号在树状图中连接目标目录与当前待打印的元素；否则，可以利用预设第二符号在树状图中连接目标目录与当前待打印的元素。
根据本申请的示例性实施例，测试思维导图展示模块902还可以用于在当前待打印的元素为目标目录所间接包含的元素的情况下，针对当前待打印的元素的各层级上级目录中的每个目录，判断每个目录是否为每个目录的直接上级目录下的最后一个元素。在每个目录不为每个目录的直接上级目录下的最后一个元素的情况下，可以利用预设第三符号在树状图中连接直接上级目录与当前待打印的元素；否则，可以利用预设第四符号在树状图中连接直接上级目录与当前待打印的元素。
图10是示出根据本申请的示例性实施例的电子设备1000的框图。
参照图10，电子设备1000包括至少一个存储器1001和至少一个处理器1002，所述至少一个存储器1001中存储有指令，当指令被至少一个处理器1002执行时，执行根据本申请的示例性实施例的测试思维导图的展示方法。
作为示例，电子设备1000可以是PC计算机、平板装置、个人数字助理、智能手机、或其他能够执行上述指令的装置。这里，电子设备1000并非必须是单个的电子设备，还可以是任何能够单独或联合执行上述指令（或指令集）的装置或电路的集合体。电子设备1000还可以是集成控制***或***管理器的一部分，或者可被配置为与本地或远程（例如，经由无线传输）以接口互联的便携式电子设备。
在电子设备1000中，处理器1002可包括中央处理器（CPU）、图形处理器（GPU）、可编程逻辑装置、专用处理器***、微控制器或微处理器。作为示例而非限制，处理器还可包括模拟处理器、数字处理器、微处理器、多核处理器、处理器阵列、网络处理器等。
处理器1002可运行存储在存储器1001中的指令或代码，其中，存储器1001还可以存储数据。指令和数据还可经由网络接口装置而通过网络被发送和接收，其中，网络接口装置可采用任何已知的传输协议。
存储器1001可与处理器1002集成为一体，例如，将RAM或闪存布置在集成电路微处理器等之内。此外，存储器1001可包括独立的装置，诸如，外部盘驱动、存储阵列或任何数据库***可使用的其他存储装置。存储器1001和处理器1002可在操作上进行耦合，或者可例如通过I/O端口、网络连接等互相通信，使得处理器1002能够读取存储在存储器中的文件。
此外，电子设备1000还可包括视频显示器（诸如，液晶显示器）和用户交互接口（诸如，键盘、鼠标、触摸输入装置等）。电子设备1000的所有组件可经由总线和/或网络而彼此连接。
根据本申请的示例性实施例，还可提供一种计算机可读存储介质，当计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述测试思维导图的展示方法。这里的计算机可读存储介质的示例包括：只读存储器（ROM）、随机存取可编程只读存储器（PROM）、电可擦除可编程只读存储器（EEPROM）、随机存取存储器（RAM）、动态随机存取存储器（DRAM）、静态随机存取存储器（SRAM）、闪存、非易失性存储器、CD-ROM、CD-R、CD+R、CD-RW、CD+RW、DVD-ROM、DVD-R、DVD+R、DVD-RW、DVD+RW、DVD-RAM、BD-ROM、BD-R、BD-RLTH、BD-RE、蓝光或光盘存储器、硬盘驱动器（HDD）、固态硬盘（SSD）、卡式存储器（诸如，多媒体卡、安全数字（SD）卡或极速数字（XD）卡）、磁带、软盘、磁光数据存储装置、光学数据存储装置、硬盘、固态盘以及任何其他装置，所述任何其他装置被配置为以非暂时性方式存储计算机程序以及任何相关联的数据、数据文件和数据结构并将所述计算机程序以及任何相关联的数据、数据文件和数据结构提供给处理器或计算机使得处理器或计算机能执行所述计算机程序。上述计算机可读存储介质中的计算机程序可在诸如客户端、主机、代理装置、服务器等计算机设备中部署的环境中运行，此外，在一个示例中，计算机程序以及任何相关联的数据、数据文件和数据结构分布在联网的计算机***上，使得计算机程序以及任何相关联的数据、数据文件和数据结构通过一个或多个处理器或计算机以分布式方式存储、访问和执行。
根据本申请提供的测试思维导图的展示方法、装置、电子设备和存储介质，在对测试点进行测试并获得测试回归用例之后，可以将测试回归用例添加至包含相应测试点的目录下。进一步的，可以有针对性的针对特定目录下的自述文件中所包含的测试点进行测试，并可以将相应的测试回归用例添加至包含相应测试点的目录下，而目录本身又包含于测试思维导图内。可见，本申请实现了将测试回归用例整合于思维导图之上，从而避免了多个软件的交叉使用，降低了测试思维导图与测试回归用例之间的对应关系的梳理难度，利于测试数据的保存以及维护。
进一步的，通过控制测试回归用例中包含已经进行过测试的测试点，便于后续基于测试回归用例中所包含的测试点及时知晓到底已经针对哪些测试点进行了测试，进而可以方便、快速的统计出测试进度；进一步的，通过控制测试回归用例中包含验证数据、模拟人工操作步骤、期望结果、验证结果；期望结果与验证结果是否匹配的指示信息、测试点验证是否通过的结论信息，相当于针对测试点进行测试的完整过程进行了一个详细的记录，便于后续的查漏和纠错。
进一步的，用户可以根据自身需要决定是否在第一命令中指定相应的目录，即用户可以根据自身需要决定到底展示哪个目录的测试思维导图，展示测试思维导图的自主性和灵活性较好。进一步的，在第一命令中未指定相应目录的情况下，终端可以自动将当前工作目录确定为待展示测试思维导图的目录，节省了用户手动指定目录的操作步骤，降低了确定待展示测试思维导图的目录的繁琐程度。
进一步的，通过在测试思维导图中展示各个目录对应的自述文件、测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项，便于用户对各个目录的测试任务轻重、测试进度快慢有一个直观、清晰的了解，方便用户对整体测试状况有一个宏观、大体的把控。
进一步的，由于测试回归用例为针对目录对应的测试点进行测试所获得的，一旦某个测试回归用例中所包含的某个测试点与目录下的自述文件中所包含的某个测试点相重合，说明自述文件中所包含的该测试点已经被测试完成。因此，可以基于目录下的自述文件中所包含的测试点，与，该目录下的测试回归用例所包含的测试点的重合情况，来确定该目录对应的全部测试点是否已经测试完成，即可以基于上述测试点的重合情况来确定目录测试状态，可以保证所确定的目录测试状态的准确性。
进一步的，某个目录只有在和另一个目录的关系比较紧密的情况下，才可能成为该另一个目录的下级目录。因此，针对存在下级目录的目录，在确定该目录的目录测试状态时，除了要考虑该目录自身下面的自述文件中的测试点的测试状态，还需要考虑该目录的所有下级目录的目录测试状态。这样，用户只需基于某个目录的目录测试状态，就可以大体判断出该目录的下级目录大致处于什么样的测试状态，便于用户对当前目录的下级目录到底处于何种测试状态有一个直观、清晰的了解。并且，针对存在下级目录的目录，在确定该目录对应的测试点的数量时，除了要考虑该目录自身下面的自述文件中的测试点的数量，还需要考虑该目录的所有下级目录的自述文件中所包含的测试点的数量。这样，用户只需基于某个目录对应的测试点的数量，就可以大体判断出该目录的下级目录的自述文件中大致包含多少个测试点，便于用户对当前目录的下级目录到底对应多少个测试点有一个直观、清晰的了解。以及，针对存在下级目录的目录，在确定该目录对应的测试回归用例的数量时，除了要考虑该目录自身下面的测试回归用例的数量，还需要考虑该目录的所有下级目录下的测试回归用例的数量。这样，用户只需基于某个目录对应的测试回归用例的数量，就可以大体判断出该目录的下级目录下大致包含多少个测试回归用例，便于用户对当前目录的下级目录到底对应多少个测试回归用例有一个直观、清晰的了解。
进一步的，用户可以根据自身需要决定在第一命令中包含哪些附加选项，进而可以在展示测试思维导图时实现相应的功能，即用户可以自主决定测试思维导图具体展示为什么样的形式，展示测试思维导图的自主性和灵活性更好。
进一步的，用户可以根据自身需要在showmindmap脚本中预先设置各个颜色变量的取值，进而可以利用不同的颜色打印不同的对象，可以实现向用户呈现一个不同类型对象之间界限分明、架构清晰的测试思维导图，便于用户快速、准确的了解整个测试思维导图的组织架构和成分组成。
进一步的，用户可以根据自身需要决定到底展示哪个目录下的测试进度文件的内容，展示目录对应的测试进度的自主性和灵活性较好。
进一步的，通过在测试进度文件中设置与测试点、测试回归用例相关的多项内容，便于用户对相应目录下的测试进度有一个清晰全面的了解，方便用户对相应目录下的测试状况有一个全方位的把控。
进一步的，通过递归遍历的方式打印各个目录和/或文件，可以避免任何一个目录或者文件被遗漏掉。并且，通过在showmindmap脚本中预先设置不同类型对象的展示颜色，可以实现向用户呈现一个不同类型对象之间界限分明、架构清晰的测试思维导图，便于用户快速、准确的了解整个测试思维导图的组织架构、成分组成以及测试状况。
进一步的，通过基于当前待打印的元素在所属目录中的位置，来利用不同类型的树状结构连接符号来连接当前待打印的元素与所属目录，并且，还可以通过基于当前待打印的元素在所属目录中的位置以及当前待打印的元素的各层级上级目录在相应的直接上级目录中的位置，来利用不同类型的树状结构连接符号来连接当前待打印的元素与各层级上级目录，可以实现向用户呈现一个等级分明、层次清晰的测试思维导图，便于用户快速、准确的梳理不同目录之间、文件与目录之间的架构关系。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由所附的权利要求指出。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。
Claims (21)
1.一种测试思维导图的展示方法，其特征在于，包括：
在目标***内接收输入于终端工具的第一命令，其中，所述第一命令用于指示基于目标脚本在所述终端工具上以树状图形式打印目标目录下的目录和/或文件，所述目标目录包含多级子目录，所述目标目录及其多级子目录根据目标测试项目被预先创建，所述目标目录以及所述多级子目录中的至少一个目录下添加有针对所述至少一个目录对应的测试点进行测试所获得的测试回归用例；
响应于所述第一命令，在所述目标***内调用所述目标脚本，以获取并在所述终端工具上展示所述目标目录对应的树状图作为所述目标测试项目的测试思维导图。
2.如权利要求1所述的展示方法，其特征在于，所述展示方法还包括：
在所述测试思维导图中展示所述目标目录以及所述多级子目录中各个目录对应的自述文件、测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项；
其中，任一目录对应的自述文件包含所述任一目录的介绍信息、测试点信息以及分支目录的信息。
3.如权利要求2所述的展示方法，其特征在于，所述在所述测试思维导图中展示所述目标目录以及所述多级子目录中各个目录对应的自述文件、测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项，包括：
针对每个第一子目录，根据所述第一子目录下的自述文件中所包含的测试点与所述第一子目录下的测试回归用例所包含的测试点的重合情况，确定所述第一子目录的目录测试状态，并在所述第一子目录下展示所述目录测试状态，其中，所述第一子目录为所述多级子目录中不存在下级目录的子目录。
4.如权利要求2所述的展示方法，其特征在于，所述在所述测试思维导图中展示所述目标目录以及所述多级子目录中各个目录对应的自述文件、测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项，包括：
针对所述目标目录和第二子目录中的每个目录，根据所述每个目录下的自述文件中所包含的测试点的测试状态以及所述每个目录的下级目录的目录测试状态，确定所述每个目录的目录测试状态，并在所述每个目录下展示所述目录测试状态，其中，所述第二子目录为所述多级子目录中存在下级目录的子目录。
5.如权利要求2所述的展示方法，其特征在于，所述在所述测试思维导图中展示所述目标目录以及所述多级子目录中各个目录对应的自述文件、测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项，包括：
针对每个第一子目录，确定所述第一子目录下的自述文件中所包含的测试点的数量，其中，所述第一子目录为所述多级子目录中不存在下级目录的子目录；
在所述第一子目录下展示所述自述文件中所包含的测试点的数量。
6.如权利要求2所述的展示方法，其特征在于，所述在所述测试思维导图中展示所述目标目录以及所述多级子目录中各个目录对应的自述文件、测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项，包括：
针对所述目标目录以及第二子目录中的每个目录，确定所述每个目录下的自述文件所包含的测试点的第一数量，其中，所述第二子目录为所述多级子目录中存在下级目录的子目录；
确定所述每个目录的所有下级目录的自述文件中所包含的测试点的第二数量；
计算所述第一数量与所述第二数量的加和，获得测试点的总数量；
在所述每个目录下展示所述测试点的总数量。
7.如权利要求2所述的展示方法，其特征在于，所述在所述测试思维导图中展示所述目标目录以及所述多级子目录中各个目录对应的自述文件、测试点的数量、测试回归用例的数量以及目录测试状态中的至少一项，包括：
针对所述目标目录以及第二子目录中的每个目录，确定所述每个目录下测试回归用例的第三数量；
确定所述每个目录的所有下级目录下的测试回归用例的第四数量；
计算所述第三数量和所述第四数量的加和，获得测试回归用例的总数量；
在所述每个目录下展示所述测试回归用例的总数量。
8.如权利要求1所述的展示方法，其特征在于，所述目标脚本还用于生成所述目标目录以及所述多级子目录中每个目录对应的测试进度文件，其中，任一目录对应的测试进度文件用于指示所述任一目录下的测试进度；
其中，在所述目标***内调用所述目标脚本之后，所述展示方法还包括：
在所述目标***内接收输入于所述终端工具的第二命令，其中，所述第二命令中包含指定目录的路径名称，所述指定目录为所述目标目录或者所述多级子目录的其中之一；
响应于所述第二命令，在所述终端工具上打印所述指定目录下的测试进度文件中的内容。
9.如权利要求8所述的展示方法，其特征在于，所述在所述终端工具上打印所述指定目录下的测试进度文件中的内容，包括：
在所述终端工具上打印所述指定目录下的测试进度文件中所包含的以下至少一项：
所述指定目录对应的测试点的数量、所述指定目录对应的测试回归用例的数量、所述指定目录对应的测试点中已经完成测试的测试点数量与所述指定目录对应的全部测试点数量之间的百分比；所述指定目录下的自述文件对应的文件测试状态、所述指定目录下的自述文件所包含的测试点中尚未启动测试的测试点、所述指定目录下的自述文件所包含的测试点中已经完成测试的测试点数量与所述自述文件所包含的全部测试点数量之间的百分比。
10.如权利要求9所述的展示方法，其特征在于，所述展示方法还包括：
在所述指定目录下的自述文件所包含的测试点均已完成测试的情况下，确定所述指定目录下的自述文件对应的文件测试状态为完成状态；
在所述指定目录下的自述文件所包含的测试点均未启动测试的情况下，确定所述指定目录下的自述文件对应的文件测试状态为尚未启动测试状态；
否则，确定所述指定目录下的自述文件对应的文件测试状态为正在测试中状态。
11.如权利要求1所述的展示方法，其特征在于，所述第一命令内还包含附加选项，其中，所述附加选项包含以下项中的至少一项：
展示脚本的使用手册、待展示的目录、只展示目录层级、最大展示目录层级、打印时禁止携带颜色、禁止展示测试进度文件、禁止展示自述文件和测试进度文件、展示后禁止保留生成的测试进度文件；
所述获取并在所述终端工具上展示所述目标目录对应的树状图作为所述目标测试项目的测试思维导图，包括：
按照所述第一命令所包含的附加选项，获取并在所述终端工具上展示所述目标目录对应的树状图作为所述目标测试项目的测试思维导图。
12.如权利要求11所述的展示方法，其特征在于，所述按照所述第一命令所包含的附加选项，获取并在所述终端工具上展示所述目标目录对应的树状图作为所述目标测试项目的测试思维导图，包括：
在所述第一命令中包含所述打印时禁止携带颜色的选项的情况下，按照所述目标***中所预先设置的默认颜色打印并在所述终端工具上展示所述测试思维导图；
在所述第一命令中不包含所述打印时禁止携带颜色的选项的情况下，基于所述目标脚本中针对各个对象所预先设置的展示颜色，打印所述各个对象以在所述终端工具上展示所述测试思维导图。
13.如权利要求1所述的展示方法，其特征在于，所述获取并在所述终端工具上展示所述目标目录对应的树状图作为所述目标测试项目的测试思维导图，包括：
以所述目标目录为起点，通过递归遍历的方式，依次对所述目标目录下的目录和/或文件进行打印，直至所述目标目录、所述多级子目录、所述目标目录下的文件以及所述多级子目录下的文件均被遍历完成；
其中，针对每一次遍历，执行以下操作：
获取当前遍历对象的类型；
在所述类型为文件的情况下，基于所述目标脚本中针对文件所预先设置的展示颜色，打印当前遍历对象；
在所述类型为目录的情况下，获取当前遍历对象对应的目录测试状态、测试点的数量以及测试回归用例的数量；
基于所述目标脚本中针对目录所预先设置的展示颜色，打印当前遍历对象，并基于所述目标脚本中针对字符串所预先设置的展示颜色，在当前遍历对象下打印当前遍历对象对应的目录测试状态、测试点的数量以及测试回归用例的数量。
14.如权利要求1所述的展示方法，其特征在于，在目标***内接收输入于终端工具的第一命令之后，所述展示方法还包括：
判断所述第一命令中是否包含目录的路径名称；
在所述第一命令中包含所述路径名称的情况下，将所述路径名称对应的目录作为所述目标目录；
否则，将所述目标***的当前工作目录作为所述目标目录。
15.如权利要求1所述的展示方法，其特征在于，在目标***内接收输入于终端工具的第一命令之前，所述展示方法还包括：
根据所述目标测试项目创建所述目标目录以及所述多级子目录；
在所述目标目录以及所述多级子目录中的每个目录下创建自述文件；
按照第一预设格式在所述每个目录下的自述文件中编写所述目标测试项目中相应的测试点，并在所述至少一个目录下添加测试回归用例，其中，所述测试回归用例为针对所述至少一个目录下的自述文件中所编写的至少一个测试点进行测试所获得的测试回归用例。
16.如权利要求15所述的展示方法，其特征在于，所述测试回归用例包含以下至少一项：
按照第二预设格式指定的所述所编写的至少一个测试点，用于验证所述所编写的至少一个测试点的验证数据、用于验证所述所编写的至少一个测试点的模拟人工操作步骤、期望结果、验证结果、所述期望结果与所述验证结果是否匹配的指示信息、所述所编写的至少一个测试点验证是否通过的结论信息；
其中，所述验证结果为基于所述验证数据执行所述模拟人工操作步骤之后获得的结果；
所述期望结果为基于所述验证数据执行所述模拟人工操作步骤之后应当获得的准确结果。
17.如权利要求1所述的展示方法，其特征在于，所述获取并在所述终端工具上展示所述目标目录对应的树状图作为所述目标测试项目的测试思维导图，包括：
在当前待打印的元素为所述目标目录所直接包含的元素的情况下，判断当前待打印的元素是否为所述目标目录下的最后一个元素；
在当前待打印的元素不为所述目标目录下的最后一个元素的情况下，利用预设第一符号在所述树状图中连接所述目标目录与当前待打印的元素；
否则，利用预设第二符号在所述树状图中连接所述目标目录与当前待打印的元素。
18.如权利要求1所述的展示方法，其特征在于，所述获取并在所述终端工具上展示所述目标目录对应的树状图作为所述目标测试项目的测试思维导图，包括：
在当前待打印的元素为所述目标目录所间接包含的元素的情况下，针对当前待打印的元素的各层级上级目录中的每个目录，判断所述每个目录是否为所述每个目录的直接上级目录下的最后一个元素；
在所述每个目录不为所述每个目录的直接上级目录下的最后一个元素的情况下，利用预设第三符号在所述树状图中连接所述直接上级目录与当前待打印的元素；
否则，利用预设第四符号在所述树状图中连接所述直接上级目录与当前待打印的元素。
19.一种测试思维导图的展示装置，其特征在于，包括：
第一命令接收模块，被配置为在目标***内接收输入于终端工具的第一命令，其中，所述第一命令用于指示基于目标脚本在所述终端工具上以树状图形式打印目标目录下的目录和/或文件，所述目标目录包含多级子目录，所述目标目录及其多级子目录根据目标测试项目被预先创建，所述目标目录以及所述多级子目录中的至少一个目录下添加有针对所述至少一个目录对应的测试点进行测试所获得的测试回归用例；
测试思维导图展示模块，被配置为响应于所述第一命令，在所述目标***内调用所述目标脚本，以获取并在所述终端工具上展示所述目标目录对应的树状图作为所述目标测试项目的测试思维导图。
20.一种电子设备，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求1至18中任一项所述的测试思维导图的展示方法。
21.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1至18中任一项所述的测试思维导图的展示方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311489451.1A CN117234945B (zh) | 2023-11-10 | 2023-11-10 | 测试思维导图的展示方法、装置、电子设备和存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311489451.1A CN117234945B (zh) | 2023-11-10 | 2023-11-10 | 测试思维导图的展示方法、装置、电子设备和存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117234945A true CN117234945A (zh) | 2023-12-15 |
| CN117234945B CN117234945B (zh) | 2024-01-30 |
Family
ID=89095082
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311489451.1A Active CN117234945B (zh) | 2023-11-10 | 2023-11-10 | 测试思维导图的展示方法、装置、电子设备和存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117234945B (zh) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150161031A1 (en) * | 2013-12-06 | 2015-06-11 | Testfire, Inc. | Embedded test management for mobile applications |
| CN107256148A (zh) * | 2017-05-24 | 2017-10-17 | 龙芯中科技术有限公司 | 界面的生成方法及***、电子设备及存储介质 |
| WO2018121442A1 (zh) * | 2016-12-30 | 2018-07-05 | 腾讯科技（深圳）有限公司 | 软件信息的处理方法和装置及存储介质、电子装置 |
| CN109558317A (zh) * | 2018-11-22 | 2019-04-02 | 网易（杭州）网络有限公司 | 测试用例的处理方法及装置 |
| US20190324894A1 (en) * | 2018-04-20 | 2019-10-24 | EMC IP Holding Company LLC | Method, device and computer readable storage medium for visualization of test cases |
| CN111881036A (zh) * | 2020-07-23 | 2020-11-03 | 云账户技术(天津)有限公司 | 测试用例的管理方法、装置和电子设备 |
| CN113094288A (zh) * | 2021-05-18 | 2021-07-09 | 绿漫科技有限公司 | 一种基于Xmind思维导图转测试用例的方法 |
| CN114996131A (zh) * | 2022-05-30 | 2022-09-02 | 深圳希施玛数据科技有限公司 | 一种思维导图转换测试用例方法及装置 |
| WO2022237253A1 (zh) * | 2021-05-11 | 2022-11-17 | 华为云计算技术有限公司 | 一种测试用例生成方法、装置及设备 |
| CN116225968A (zh) * | 2023-05-06 | 2023-06-06 | 易方信息科技股份有限公司 | 在线化测试用例脚本文件管理方法、装置、终端以及介质 |
-
2023
- 2023-11-10 CN CN202311489451.1A patent/CN117234945B/zh active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150161031A1 (en) * | 2013-12-06 | 2015-06-11 | Testfire, Inc. | Embedded test management for mobile applications |
| WO2018121442A1 (zh) * | 2016-12-30 | 2018-07-05 | 腾讯科技（深圳）有限公司 | 软件信息的处理方法和装置及存储介质、电子装置 |
| CN107256148A (zh) * | 2017-05-24 | 2017-10-17 | 龙芯中科技术有限公司 | 界面的生成方法及***、电子设备及存储介质 |
| US20190324894A1 (en) * | 2018-04-20 | 2019-10-24 | EMC IP Holding Company LLC | Method, device and computer readable storage medium for visualization of test cases |
| CN109558317A (zh) * | 2018-11-22 | 2019-04-02 | 网易（杭州）网络有限公司 | 测试用例的处理方法及装置 |
| CN111881036A (zh) * | 2020-07-23 | 2020-11-03 | 云账户技术(天津)有限公司 | 测试用例的管理方法、装置和电子设备 |
| WO2022237253A1 (zh) * | 2021-05-11 | 2022-11-17 | 华为云计算技术有限公司 | 一种测试用例生成方法、装置及设备 |
| CN113094288A (zh) * | 2021-05-18 | 2021-07-09 | 绿漫科技有限公司 | 一种基于Xmind思维导图转测试用例的方法 |
| CN114996131A (zh) * | 2022-05-30 | 2022-09-02 | 深圳希施玛数据科技有限公司 | 一种思维导图转换测试用例方法及装置 |
| CN116225968A (zh) * | 2023-05-06 | 2023-06-06 | 易方信息科技股份有限公司 | 在线化测试用例脚本文件管理方法、装置、终端以及介质 |
Non-Patent Citations (4)
| Title |
|---|
| I. OTADUY 等: "User acceptance testing for Agile-developed web-based applications: Empowering customers through wikis and mind maps", 《 JOURNAL OF SYSTEMS AND SOFTWARE》, vol. 133, pages 212 - 229 * |
| WQCHING: "使用思维导图书写测试用例", Retrieved from the Internet <URL:《https://www.jianshu.com/p/963a97ea3625》> * |
| 李宁: "Web自动化测试与监控工具的设计与实现", 《中国优秀硕士学位论文全文数据库信息科技辑》, no. 4, pages 138 - 1129 * |
| 陈晓宇: "基于流程推荐的数据库测试脚本可视化工具的设计与实现", 《中国优秀硕士学位论文全文数据库信息科技辑》, no. 3, pages 138 - 563 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117234945B (zh) | 2024-01-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8881105B2 (en) | Test case manager | |
| US10223338B2 (en) | Visual designer for editing large schemaless XML file | |
| US11762717B2 (en) | Automatically generating testing code for a software application | |
| WO2018010552A1 (zh) | 测试方法和装置 | |
| US8943423B2 (en) | User interface indicators for changed user interface elements | |
| US9141518B2 (en) | GUI testing | |
| JP3407809B2 (ja) | コンピュータ・アプリケーション・ソフトウェアの自動化試験システム | |
| US9032371B2 (en) | Method and apparatus for automatic diagnosis of software failures | |
| JP6761441B2 (ja) | ソフトウェアアプリケーションプログラミングインタフェース（ａｐｉ）を用いた自動テスト機能のユーザによる制御 | |
| US20070214173A1 (en) | Program, method, and apparatus for supporting creation of business process model diagram | |
| CN112270149B (zh) | 验证平台自动化集成方法、***及电子设备和存储介质 | |
| CN111124867B (zh) | 一种OpenStack测试方法及装置 | |
| US7661053B2 (en) | Methods and apparatus for patternizing device responses | |
| CN108874649B (zh) | 自动化测试脚本的生成方法、装置及其计算机设备 | |
| US5768499A (en) | Method and apparatus for dynamically displaying and causing the execution of software diagnostic/test programs for the silicon validation of microprocessors | |
| CN115080398A (zh) | 一种接口自动化测试***及方法 | |
| CN110659197B (zh) | 应用程序的测试用例生成方法、装置和软件测试*** | |
| Nickel et al. | Ibm ilog cplex optimization studio—a primer | |
| JP2000112784A (ja) | プログラムテスト支援装置及びプログラムテスト支援プログラムを記録した記録媒体 | |
| CN117234945B (zh) | 测试思维导图的展示方法、装置、电子设备和存储介质 | |
| CN116128448B (zh) | Fpga工程项目的设计数据处理方法、装置、电子设备 | |
| CN113326193A (zh) | 一种小程序测试方法及装置 | |
| CN113377468A (zh) | 一种脚本执行方法、装置、电子设备及存储介质 | |
| CN111930456A (zh) | 一种测试日志的显示方法及电子设备、存储介质 | |
| CN114895877B (zh) | 基于网页的低代码模块化创建企业erp的方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |