1.本发明实施例涉及芯片
技术领域：
：，具体涉及一种测试序列生成方法、装置、系统及相关设备。
背景技术：
：：2.逻辑验证是数字芯片前端设计过程中的一个关键步骤，通常利用验证平台实现。具体的，验证平台可模拟芯片设计的实际运行环境，检验芯片设计功能的正确性。3.选用uvm(universalverificationmethodology，通用验证方法学)验证方法学搭建验证环境，易于实现iplevel到soclevel验证环境的集成。而在具体的验证过程中，通常基于systemverilog验证语言编写测试用例(test)的测试序列(testsequence)，从而使得验证平台基于测试序列产生相应的激励，测试芯片设计中在该激励下的运行结果，并基于该运行结果进行芯片设计功能的检验。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.可选的，所述基础约束包括：各测试元素在所述应用场景下的硬件约束和软件约束，所述硬件约束为测试用例的位宽、地址、所占用的存储空间中的至少一种，所述软件约束为测试用例的数据格式、测试元素的数据类型、测试元素对应的rtl设计规则中的至少一种。36.可选的，所述描述文件为xml格式，所述解析所述描述文件，确定所述测试用例中的测试元素，具体为，采用脚本工具解析所述描述文件，确定所述测试用例中的测试元素。37.可选的，所述规则文件为xsd格式，所述解析所述规则文件，具体为，采用脚本工具解析所述规则文件。38.第二方面，本发明实施例提供一种测试序列生成装置，包括：39.文件获取模块，用于获取测试用例的描述文件，所述描述文件包括所述测试用例的控制逻辑，所述测试用例的控制逻辑至少用于描述测试用例中各测试元素的逻辑关系；40.文件解析模块，用于解析所述描述文件，确定所述测试用例中的测试元素；41.约束获取模块，用于从基本规则库中获取对应所述测试元素的约束；其中，所述基本规则库中至少包括所述测试元素的基础约束；42.序列生成模块，用于基于所述描述文件和所述基本规则库中的约束，生成对应所述测试用例的测试序列。43.可选的，所述测试序列生成装置还包括：44.规则库构建模块，用于构建与测试用例的应用场景对应的基本规则库，所述基本规则库包括至少基于所述应用场景下各测试元素的基础约束。45.第三方面，本发明实施例提供一种芯片验证系统，所述芯片验证系统被配置为执行如上述第一方面所述的测试序列生成方法。46.第四方面，本发明实施例提供一种计算机设备，包括至少一个存储器和至少一个处理器；所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如上述第一方面所述的测试序列生成方法。47.第五方面，本发明实施例提供一种存储介质，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令用于执行如上述第一方面所述的测试序列生成方法。48.本发明实施例提供了一种测试序列生成方法、装置、系统及相关设备，所述方法包括：获取测试用例的描述文件，所述描述文件包括所述测试用例的控制逻辑，所述测试用例的控制逻辑至少用于描述测试用例中各测试元素的逻辑关系；解析所述描述文件，确定所述测试用例中的测试元素；从基本规则库中获取对应所述测试元素的约束；其中，所述基本规则库中至少包括所述测试元素的基础约束；基于所述描述文件和所述基本规则库中的约束，生成对应所述测试用例的测试序列。49.可以看出，本发明实施例中的测试序列生成方法，同时基于描述文件以及解析描述文件后，从基本规则库中获取的测试用例中测试元素的约束，实现测试序列的生成，从而使得所述描述文件中，并不需要描述基本规则库中的约束，从而降低描述文件中写入的约束的数量，降低撰写测试用例所耗费的人力成本，进而降低生成测试序列所耗费的人力成本。附图说明50.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。51.图1为本发明实施例提供的测试序列生成方法的可选流程图。52.图2为本发明实施例提供的测试用例的测试元素示例图；53.图3为本发明实施例提供的基础约束的示例图；54.图4为本发明实施例提供的测试用例的结构示例图；55.图5为本发明实施例提供的测试序列文件的结构示例图；56.图6为本发明实施例提供的测试用例的逻辑结构示例图；57.图7为本发明实施例提供的测试序列生成方法的另一可选流程图；58.图8为本发明实施例提供的步骤s10的可选流程图；59.图9为本发明实施例提供的步骤s14的可选流程图；60.图10为本发明实施例提供的步骤s14的另一可选流程图；61.图11为本发明实施例提供的测试序列生成装置的框图；62.图12为本发明实施例提供的测试序列生成装置的另一框图。具体实施方式63.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。64.基于
背景技术：
：所述，现有芯片设计的验证过程中，生成测试序列的方式需要耗费大量的人力成本。65.这是由于，在进行芯片设计的验证过程中，需要设置大量的约束以产生符合条件的测试序列，从而使得该用于产生序列的方式，需要耗费大量的人力成本进行约束的设置。66.基于此，本发明实施例提供了一种测试序列生成方法、装置、系统及相关设备，所述方法包括：获取测试用例的描述文件，所述描述文件包括所述测试用例的控制逻辑，所述测试用例的控制逻辑至少用于描述测试用例中各测试元素的逻辑关系；解析所述描述文件，确定所述测试用例中的测试元素；从基本规则库中获取对应所述测试元素的约束；其中，所述基本规则库中至少包括所述测试元素的基础约束；基于所述描述文件和所述基本规则库中的约束，生成对应所述测试用例的测试序列。67.可以看出，本发明实施例中的测试序列生成方法，同时基于描述文件以及解析描述文件后，从基本规则库中获取的测试用例中测试元素的约束，实现测试序列的生成，从而使得所述描述文件中，并不需要描述基本规则库中的约束，从而降低描述文件中写入的约束的数量，降低撰写测试用例所耗费的人力成本，进而降低生成测试序列所耗费的人力成本。68.图1示例性的示出了本发明实施例提供的测试序列生成方法的可选流程图。如图1所示，该测试序列生成方法可以包括：69.步骤s10：构建与测试用例的应用场景对应的基本规则库；70.所述基本规则库包括至少基于所述应用场景下各测试元素的基础约束。71.其中，所述测试用例可以由测试元素构成，基于测试元素之间的逻辑关系和各测试元素对应的约束，可以形成完整的测试用例。所述测试元素，可以理解为测试用例的元素(element)，例如可以为测试用例中的变量，参考图2示出的测试用例的测试元素示例图，测试用例中的测试元素可以为操作码(opcode)、命令(command)、地址(addr)、数据(data)等。72.在进行测试用例的描述文件的撰写之前，首先可以构建对应的基本规则库。所述基本规则库用于描述特定环境下测试用例中共用的约束作为基础约束，参考图3示出的基础约束的示例图，所述基本规则库可以针对一个应用场景下的测试用例，相应的，所述基本规则库中则可以描述有针对该应用场景下，各测试元素共用的约束；或者，所述基本规则库可以针对一个应用场景下的一个项目组内的测试用例，相应的，所述基本规则库中则可以描述有针对该应用场景下的项目组内，各测试元素共用的约束，这些共用的约束用于反映对应测试用例的基础规则。73.基于不同应用场景下，测试用例对应的硬件环境不同，因此，所述基本规则库至少针对一个应用场景。相应的，所述基本规则库中至少基于所述应用场景的测试逻辑形成测试元素的基础约束。74.继续参考图3，所述基础约束至少包括测试元素对应在应用场景中的硬件约束，所述硬件约束例如可以为测试元素的位宽、地址、所占用的存储空间中的至少一种。当然，在一些可选的示例中，所述基础约束还可以包括对应测试元素在应用场景中的软件约束，例如，测试元素的数据格式、测试元素的数据类型、测试元素对应的rtl(registertransferlevel，寄存器转换级)设计规则等。75.在一个可选的示例中，所述基本规则库用于定义应用场景(例如整个访问验证环境)中所用到的所有元素(element)，而对元素的定义例如可以包括对元素的位宽以及取值范围的约束，对元素的随机数的取值方法的约束。其中，对元素的随机数的取值方法的约束例如可以为以下情况的任意一种或多种：(i)在约束范围内的完全随机取值；(ii)在需要发送多个指令组时，每个指令中元素的值自动加固定值；(iii)单个指令组中，每个cycle(时钟周期)自动加固定值等。76.可以理解的是，在针对的特定环境越明确时，对应的共用约束越多，且约束的范围越小，对应在基本规则库中，体现为基础约束越多，且约束的范围越小。例如，在一个应用场景下，对应的基础约束可能仅为应用场景的硬件约束和较为基础的软件约束，而在一个应用场景下的一项目组内，对应的基础约束还可以进一步包括该项目组内的，测试元素共用的约束，例如，测试元素的取值范围、测试元素在该项目组内的属性参数、测试元素在该项目组内进一步定义的rtl设计规则等。77.其中，基本规则库中提供的约束越多，对应测试用例的描述文件需要写入的约束越少，进而耗费的人力成本也越少。78.在一个可选的示例中，所述基本规则库可以为哈希(hash)数据库，可以采用schema技术描述其中的基础约束，当然，在其他示例中，所述基本规则库也可以为b 树数据库、fix-length数据库、table数据库等。79.其中，所述基本规则库中还可以进一步进行基础规则的配置，例如，配置随机机制，以使得生成的测试序列在符合相应约束的前提下随机化。在进一步的示例中，所述基本规则库中还可以根据需求进行基础规则的配置，本发明在此不做具体的限定。80.在基本规则库定义了基础约束后，即可进行测试用例的描述文件的撰写。可以理解的是，在应用场景固定的情况下，所述基本规则库也可以为提前构建的，从而，相应的示例中可以不包括步骤s10，进而可以直接基于基本规则库，进行描述文件的撰写，并进一步执行步骤s11～步骤s14，以生成对应的测试序列。81.接着，继续参考图1，执行步骤s11：获取测试用例的描述文件；82.其中，所述描述文件包括所述测试用例的控制逻辑，所述测试用例的控制逻辑至少用于约束测试用例中各测试元素的逻辑关系；83.在一个可选的示例中，参考图4示出的测试用例的结构示例图，测试用例中可以包含环境设置(environment)、启动设置(setup)、测试流程(steps)、结果设置(result)等，其中，所述环境设置中可以包括相应的硬件约束和部分基础的软件约束，可以作为基础约束存储在基本规则库中，所述启动设置中至少部分约束可以作为共用约束存储在基本规则库中，或者，将所述启动设置中的所有约束存储在基本规则库中；所述测试流程、结果设置作为测试用例的控制逻辑，可以描述在测试用例的描述文件中；或者，在其他实施例中，还可以进一步将测试流程、结果设置中的部分可共用的约束存储在基本规则库中，从而进一步简化描述文件，当然，至少所述测试用例的控制逻辑的主逻辑应当保留在所述描述文件中。84.所述描述文件可以为xml(extensiblemarkuplanguage，可扩展标记语言)格式，用于组织、存储相应的测试用例的数据，但并不参与数据的生成、读取、传送、存储等操作。85.其中，基于描述文件中的约束的数量降低，使得对应的描述文件写入过程中，出现写入错误的概率大幅下降。同时，随着描述文件中的约束的数量的降低，还降低了核对描述文件所耗费的人力成本。86.基于本发明实施例中，描述文件包括用于描述测试用例中各测试元素的逻辑关系的控制逻辑，使得测试人员能够清楚直观的确定测试用例的逻辑结构，进而避免多层约束下可能产生的约束冲突，且易于实现对测试用例的修改和复用。87.接着，继续参考图1，执行步骤s12：解析所述描述文件，确定所述测试用例中的测试元素；88.基于所述描述文件中的描述，可以通过解析的方式，确定其中的测试元素。其中，所述描述文件例如可以为xml格式，对应的，可以利用脚本工具解析所述描述文件，确定所述测试用例中的测试元素。89.可以理解的是，所述描述文件可以同时包括测试用例的控制逻辑和对应测试元素的约束，在一个可选的示例中，所述步骤s12中，还可以同时解析确定所述描述文件中对应各测试元素的约束，从而可以在后续步骤中直接利用该部分解析结果，生成相应的测试序列。90.继续参考图1，执行步骤s13：从基本规则库中获取对应所述测试元素的约束；91.基于所述基本规则库中至少包括所述测试元素的基础约束，从而可以从所述基本规则库中获取对应测试元素的约束。具体的，可以基于所述测试元素，查找得到对应所述测试元素的约束。92.具体的，可以通过查询的方式，确定所述基本规则库中，是否包含有对应测试元素的约束。在查询到对应约束时，获取该约束。93.继续参考图1，执行步骤s14：基于所述描述文件中的约束和所述基本规则库中的约束，生成对应所述测试用例的测试序列；94.在获取所述基本规则库中的约束后，即可同时基于所述描述文件中的约束和所述基本规则库中的约束，生成对应所述测试用例的测试序列。95.其中，在所述描述文件中同时包括测试用例的控制逻辑和对应各测试元素的约束时，本步骤具体可以为，基于所述描述文件中，所述测试用例的控制逻辑和对应各测试元素的约束，以及所述基本规则库中对应各测试元素的约束，生成对应所述测试用例的测试序列。96.在一个可选的示例中，步骤s14所生成的测试序列可以为文件的形式，对应的，所述生成对应所述测试用例的测试序列，具体为，生成测试序列文件，所述测试序列文件包括所述测试序列。为提高测试序列文件的可读性，在进一步的可选示例中，所述测试序列文件中还进一步包括生成所述测试序列的约束，其中，所述测试序列还可以分为多个部分，各部分的测试序列可以与生成该部分测试序列的约束一一对应，从而使得测试人员可以直观的得知测试序列及其对应的约束。97.参考图5示出的测试序列文件的结构示例，其中，测试序列包括部分11、部分12和部分13，其中，部分11对应约束21，且约束21对应设置在部分11一侧；部分12对应约束22，且约束22对应设置在部分12一侧；部分13对应约束23，且约束23对应设置在部分13一侧。可以理解的是，图5中仅示出了测试序列文件的其中一种设置方式，在其他可选的示例中，还可以包括采用其他的设置方式，例如将相应的约束对应设置在各部分的上方等等，本发明实施例在此不做具体的限定。98.需要说明的是，在本发明实施例中所述的测试序列的生成方法，基于基本规则库中可以获取到不同测试元素的约束，使得描述文件无需描述过多冗余的约束，即可实现测试序列的生成，降低了用于生成测试序列所需的人力成本。并且，基于描述文件无需描述过多冗余的约束，使得其结构清晰、层次分明，在需要进行调整复用时，更加简单方便，进一步节省了人力成本。99.可以理解的是，所述描述文件中包括所述测试用例的控制逻辑，且不需要写入过多的基础约束，从而使得所述描述文件中可以清晰准确的体现测试用例的数据结构和控制层次，从而在后续测试用例的调整过程中，能够及时准确的找到需要调整的位置，实现测试用例的调整和复用。100.以图6中示出的测试用例的逻辑结构示例图为例，图6中的测试用例(testcase)中包括两个指令组(instructiongroup)，即指令组0和指令组1，每个指令组中均包括有加载(load)/存储(store)/原子操作(atomic)指令，寄存器操作(register)指令，测试平台(testbench)配置指令等。而对应每个指令中，需要基于相应的控制逻辑，对各测试元素进行约束，例如，加载/存储/原子操作指令包括了命令(command)、地址(addr)、数据(data)等不同类型的测试元素，其中，命令可以基于相应的操作码(opcode)，数据格式(dataformat)，数值格式(numericformat)，存储类型(memorytype)等控制域进行对应的约束；地址可以基于索引(index)和偏移量(offset)等进行对应的约束；数据可以基于整数(int)，浮点数(float)，短整数(sint)等不同的数据类型进行约束；相应的，寄存器指令可以包括配置数据(data)，地址(addr)，读写操作类型(read/writetype)等测试元素；测试平台配置指令可以包括命令(command)、控制数据(data)等测试元素。101.而在对应该测试用例的描述文件中，可以包括测试用例所包含的指令组，以及各指令组中，不同指令对应的命令、地址、数据等测试元素，并描述对应该测试元素的控制逻辑，以及在该测试用例中，所述测试元素所对应的具体的约束。102.而在步骤s12中，可以利用脚本工具，解析确定测试用例中的测试元素。例如图6所示的测试用例中，可以解析确定测试用例中各指令中对应的地址、数据等测试元素，并同时可以确定描述文件中，对应该测试元素的约束，以便执行后续的步骤。103.在一个可选的示例中，参考图7示出的测试序列生成方法的另一可选流程图，在生成测试序列之前，还可以对描述文件中的约束进行确认，在描述文件中的约束符合相应的规则时，再执行测试序列的生成。104.具体的，在步骤s13之后，步骤s14之前，执行对描述文件中的约束的确认流程，包括：105.步骤s21：确定所述基本规则库中是否存在所述测试用例中所有测试元素的约束；106.其中，基本规则库中默认定义了测试用例中的所有测试元素，在描述文件中存在基本规则库中没有定义的测试元素时，则产生错误信息，退出测试序列的生成流程。在确定所述基本规则库中存在所述测试用例中所有测试元素的约束时，则执行步骤s22。107.步骤s22：基于所述基本规则库中，各测试元素的约束，确定描述文件中的测试元素的约束范围是否在所述基本规则库中对应测试元素的约束范围内；108.所述描述文件中的测试元素的约束范围应当在所述基本规则库中对应测试元素的约束范围内，从而避免描述文件的约束越界。109.其中，需要说明的是，描述文件中的测试元素的约束范围等同于所述基本规则库中对应测试元素的约束范围，也可以理解为，描述文件中的测试元素的约束范围在所述基本规则库中对应测试元素的约束范围内。110.例如，基本规则库中对应各测试元素的约束，可以确定描述文件中的测试元素的取值范围是否越界，或者，测试元素的取值方法是否为基本规则库中定义的方法之一，以判断描述文件中的测试元素的约束范围是否在所述基本规则库中对应测试元素的约束范围内。111.描述文件中的测试元素的约束范围不在所述基本规则库中对应测试元素的约束范围内时，则认为描述文件为错误，进而产生错误信息，退出测试序列的生成流程。112.在确定描述文件中的测试元素的约束范围在所述基本规则库中对应测试元素的约束范围内时，执行步骤s14。113.通过对描述文件进行约束的确认流程，可以及时发现描述文件中可能出现的错误，避免错误的描述文件影响芯片设计的验证/测试流程。114.在一个可选的示例中，所述基本规则库可以基于相应的规则文件生成。参考图8所示的步骤s10的可选流程图，步骤s10可以包括：115.步骤s101：获取规则文件；116.其中，所述规则文件用于描述测试元素的基础约束。117.所述规则文件可以由测试人员撰写得到，也可以由用于生成规则文件的工具生成。在一个可选的示例中，所述规则文件可以通过schema技术对基础约束进行描述，从而可以方便的进行block层到soc层的移植和集成，进而在仿真验证阶段，实现与仿真验证平台的衔接。118.通过schema技术可以简单方便的描述testcase的基本规则，包括操作码、命令、地址、数据的位宽和类型等，从而使得测试用例的描述文件只需要完成少量的配置和约束，即可基于基本规则库生成想要的测试序列。119.具体的，所述规则文件的格式可以为xsd(xmlschemadefinition，文档结构描述)。120.步骤s102：解析所述规则文件，确定所述测试元素的基础约束；121.通过解析所述规则文件，可以获取相应的基础约束信息，从而基于所述基础约束信息，构建所述基本规则库。122.具体的，可以采用脚本工具进行所述规则文件的解析。123.步骤s103：基于所述测试元素的基础约束，构建形成基本规则库；124.其中，所述基本规则库可以为哈希数据库，也可以为其他类型的数据库，在进行基本规则库的构建过程中，可以采用与对应的类型的数据库相匹配的构建方式，例如，在基本规则库为哈希数据库时，可以采用哈希数据库的构建方式进行基本规则库的构建。125.另外，需要说明的是，所述基本规则库中同时可以配置有基础规则，例如用于实现测试序列随机化的随机机制等，该基础规则可以在基本规则库的构建过程中配置。相应的，构建所述基本规则库可以包括：配置所述测试用例的应用场景下，测试元素的基础约束；配置所述测试用例的应用场景下的基础规则。126.需要说明的是，基本规则库可以为固定不变的，也可以基于预设的时机进行更新，例如，在应用场景有变更时，相应的进行基本规则库的更新，或者，基于预设的周期对基本规则库进行适应性的调整(即更新)。其中，所述更新的内容可以为基础约束，也可以为基础规则，本发明在此不做具体的限定。127.在一些的示例中，参考图9示出的步骤s14的可选流程图，在生成测试序列时，可以基于测试元素在前一流程的取值的基础上确定测试元素在当前流程的取值。128.具体的，步骤s14可以包括：129.步骤s14a：确定所述测试用例中，所述测试元素的前一取值；130.其中，所述测试元素的前一取值，可以理解为在测试用例需要发送多个指令组时，对应当前指令中的测试元素在前一指令组中的取值，或者，在测试用例的单个指令组中，测试元素在前一时钟周期的取值。131.可以理解的是，在测试用例需要发送多个指令组时，当前指令可以为已经确定了多个指令组的取值之后的指令组中的指令，也可以为第一个需要确定的指令组中的指令。在当前指令为执行的第一个需要确定的指令组中的指令时，可以确定测试元素的前一取值为空值。132.相应的，在单个指令组的取值过程可以包括多个时钟周期内的取值时，当前时钟周期前可以为已经确定了多个时钟周期内的取值之后的时钟周期，也可以为需要确定的第一个时钟周期。在当前时钟周期为需要确定的第一个时钟周期时，可以确定测试元素的前一取值为空值。133.步骤s14b：基于所述测试元素的前一取值以及对应该测试元素的约束，确定该测试元素的当前取值；134.在确定了测试元素的前一取值后，可以基于该前一取值，以及对应该测试元素的约束(例如可以为测试元素的取值方法)，确定该测试元素的当前取值。135.例如，所述测试元素的取值方法约束为：(ii)在需要发送多个指令组时，每个指令中元素的值自动加固定值；相应的，可以基于测试元素的前一取值，加上固定值，确定测试元素的当前取值。136.或者，所述测试元素的取值方法约束为：(iii)单个指令组中，每个cycle(时钟周期)自动加固定值；相应的，可以基于测试元素的前一取值，加上固定值，确定测试元素的当前取值。137.可以理解的是，基于测试平台(testbench)不同，所需要的测试序列的类型也不同，例如，测试平台可以为c ，systemverilog，verilog，systemc等，其对应的测试序列的类型也应当是适应于对应测试平台。基于前述步骤已经获取了描述文件中的约束和所述基本规则库中的约束，本步骤已经得知了用于描述测试用例的所有信息，在此前提下，本发明实施例可以基于该测试用例的信息，生成任一类型的测试序列。138.在一个可选的示例中，参考图10示出的步骤s14的另一可选流程图，步骤s14可以进一步包括：139.步骤s141：获取用于生成的测试序列的类型信息；140.其中，所述测试序列的类型信息可以写入在描述文件中，并作为约束从所述描述文件的解析过程中获取。或者，所述测试序列的类型信息可以在生成测试用例时，基于用户输入的信息确定，例如，在显示器件上弹出提示信息，使得用户基于该提示信息，输入所需生成的测试序列的类型信息，进而获取该测试序列的类型信息。141.步骤s142：调用与所述类型信息对应的指令类型的处理子函数，生成测试序列。142.可以理解的是，基于不同的类型信息，对应有不同的指令类型(instructiontype)，在确定所述类型信息后，可以基于对应指令类型的处理子函数，生成测试序列。其中，所述处理子函数为定义在脚本工具中，用于辅助流程执行的函数。143.在生成对应类型的测试用例后，可以直接将测试用例提供给相应的测试平台使用。144.可以理解的是，基于不同指令类型的处理子函数，可以生成不同类型的测试序列，也就是说，本发明实施例中的描述文件是可以对应不同测试平台的通用文件，从而扩展了本发明实施例的适用环境。并且，本发明实施例中描述文件的适用环境的扩展，使得描述文件并不需要基于不同的测试平台撰写不同的代码，进一步降低了人力成本。145.下面对本发明实施例提供的测试序列生成装置进行介绍，下文描述的装置内容可以认为是芯片测试设备或者计算机设备，为实现本发明实施例提供的测试序列生成方法所需设置的功能模块。下文描述的装置内容可与上文描述的方法内容相互对应参照。146.图11示出了本发明实施例提供的测试序列生成装置的框图。如图11所示，该装置可以包括：147.文件获取模块200，用于获取测试用例的描述文件，所述描述文件包括所述测试用例的控制逻辑，所述测试用例的控制逻辑至少用于描述测试用例中各测试元素的逻辑关系；148.文件解析模块210，用于解析所述描述文件，确定所述测试用例中的测试元素；149.约束获取模块220，用于从基本规则库中获取对应所述测试元素的约束；其中，所述基本规则库中至少包括所述测试元素的基础约束；150.序列生成模块230，用于基于所述描述文件和所述基本规则库中的约束，生成对应所述测试用例的测试序列。151.在一些实施例中，参考图12示出的本发明实施例提供的测试序列生成装置的另一框图，所述测试序列生成装置还包括：152.规则库构建模块240，用于构建与测试用例的应用场景对应的基本规则库，所述基本规则库至少包括基于所述应用场景下各测试元素的基础约束。153.在一些实施例中，所述规则库构建模块240，用于构建与测试用例的应用场景对应的基本规则库，包括：154.获取规则文件，所述规则文件用于描述测试元素的基础约束；155.解析所述规则文件，确定所述测试元素的基础约束；156.基于所述测试元素的基础约束，构建形成基本规则库。157.在一些实施例中，所述规则库构建模块240，用于构建形成基本规则库，包括：158.配置所述测试用例的应用场景下，测试元素的基础约束；159.配置所述测试用例的应用场景下的基础规则。160.在一些实施例中，所述序列生成模块230，用于生成对应所述测试用例的测试序列，具体为，生成测试序列文件，所述测试序列文件包括所述测试序列和生成所述测试序列的约束。161.在一些实施例中，所述测试序列包括多个部分，所述测试序列文件中，各部分测试序列与生成该部分测试序列的约束一一对应。162.在一些实施例中，所述序列生成模块230，用于生成对应所述测试用例的测试序列，包括：163.获取用于生成的测试序列的类型信息；164.调用与所述类型信息对应的指令类型的处理子函数，生成测试序列。165.在一些实施例中，所述文件解析模块210，用于解析所述描述文件，确定所述测试用例中的测试元素的过程中，所述解析过程还确定所述描述文件中对应各测试元素的约束；166.所述序列生成模块230，用于基于所述描述文件和所述基本规则库中的约束，生成对应所述测试用例的测试序列，具体为，基于所述描述文件中，所述测试用例的控制逻辑和对应各测试元素的约束，以及所述基本规则库中对应各测试元素的约束，生成对应所述测试用例的测试序列。167.在一些实施例中，所述基础约束包括：各测试元素在所述应用场景下的硬件约束和软件约束，所述硬件约束为测试用例的位宽、地址、所占用的存储空间中的至少一种，所述软件约束为测试用例的数据格式、测试元素的数据类型、测试元素对应的rtl设计规则中的至少一种。168.在一些实施例中，所述描述文件为xml格式，所述文件解析模块210，用于解析所述描述文件，确定所述测试用例中的测试元素，具体为，采用脚本工具解析所述描述文件，确定所述测试用例中的测试元素。169.在一些实施例中，所述规则文件为xsd格式，所述规则库构建模块240，用于解析所述规则文件，具体为，采用脚本工具解析所述规则文件。170.本发明实施例还提供一种芯片验证系统，在一些实施例中，该芯片验证系统可以被配置为执行本发明实施例提供的测试序列生成方法。171.本发明实施例还提供一种计算机设备，该计算机设备可以包括：至少一个存储器和至少一个处理器；所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行本发明实施例提供的测试序列生成方法。172.本发明实施例提供一种存储介质，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令用于执行上述的测试序列生成方法。173.上文描述了本发明实施例提供的多个实施例方案，各实施例方案介绍的各可选方式可在不冲突的情况下相互结合、交叉引用，从而延伸出多种可能的实施例方案，这些均可认为是本发明实施例披露、公开的实施例方案。174.虽然本发明实施例披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。当前第1页12当前第1页12
技术领域：
：，具体涉及一种测试序列生成方法、装置、系统及相关设备。
背景技术：
：：2.逻辑验证是数字芯片前端设计过程中的一个关键步骤，通常利用验证平台实现。具体的，验证平台可模拟芯片设计的实际运行环境，检验芯片设计功能的正确性。3.选用uvm(universalverificationmethodology，通用验证方法学)验证方法学搭建验证环境，易于实现iplevel到soclevel验证环境的集成。而在具体的验证过程中，通常基于systemverilog验证语言编写测试用例(test)的测试序列(testsequence)，从而使得验证平台基于测试序列产生相应的激励，测试芯片设计中在该激励下的运行结果，并基于该运行结果进行芯片设计功能的检验。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.可选的，所述基础约束包括：各测试元素在所述应用场景下的硬件约束和软件约束，所述硬件约束为测试用例的位宽、地址、所占用的存储空间中的至少一种，所述软件约束为测试用例的数据格式、测试元素的数据类型、测试元素对应的rtl设计规则中的至少一种。36.可选的，所述描述文件为xml格式，所述解析所述描述文件，确定所述测试用例中的测试元素，具体为，采用脚本工具解析所述描述文件，确定所述测试用例中的测试元素。37.可选的，所述规则文件为xsd格式，所述解析所述规则文件，具体为，采用脚本工具解析所述规则文件。38.第二方面，本发明实施例提供一种测试序列生成装置，包括：39.文件获取模块，用于获取测试用例的描述文件，所述描述文件包括所述测试用例的控制逻辑，所述测试用例的控制逻辑至少用于描述测试用例中各测试元素的逻辑关系；40.文件解析模块，用于解析所述描述文件，确定所述测试用例中的测试元素；41.约束获取模块，用于从基本规则库中获取对应所述测试元素的约束；其中，所述基本规则库中至少包括所述测试元素的基础约束；42.序列生成模块，用于基于所述描述文件和所述基本规则库中的约束，生成对应所述测试用例的测试序列。43.可选的，所述测试序列生成装置还包括：44.规则库构建模块，用于构建与测试用例的应用场景对应的基本规则库，所述基本规则库包括至少基于所述应用场景下各测试元素的基础约束。45.第三方面，本发明实施例提供一种芯片验证系统，所述芯片验证系统被配置为执行如上述第一方面所述的测试序列生成方法。46.第四方面，本发明实施例提供一种计算机设备，包括至少一个存储器和至少一个处理器；所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如上述第一方面所述的测试序列生成方法。47.第五方面，本发明实施例提供一种存储介质，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令用于执行如上述第一方面所述的测试序列生成方法。48.本发明实施例提供了一种测试序列生成方法、装置、系统及相关设备，所述方法包括：获取测试用例的描述文件，所述描述文件包括所述测试用例的控制逻辑，所述测试用例的控制逻辑至少用于描述测试用例中各测试元素的逻辑关系；解析所述描述文件，确定所述测试用例中的测试元素；从基本规则库中获取对应所述测试元素的约束；其中，所述基本规则库中至少包括所述测试元素的基础约束；基于所述描述文件和所述基本规则库中的约束，生成对应所述测试用例的测试序列。49.可以看出，本发明实施例中的测试序列生成方法，同时基于描述文件以及解析描述文件后，从基本规则库中获取的测试用例中测试元素的约束，实现测试序列的生成，从而使得所述描述文件中，并不需要描述基本规则库中的约束，从而降低描述文件中写入的约束的数量，降低撰写测试用例所耗费的人力成本，进而降低生成测试序列所耗费的人力成本。附图说明50.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。51.图1为本发明实施例提供的测试序列生成方法的可选流程图。52.图2为本发明实施例提供的测试用例的测试元素示例图；53.图3为本发明实施例提供的基础约束的示例图；54.图4为本发明实施例提供的测试用例的结构示例图；55.图5为本发明实施例提供的测试序列文件的结构示例图；56.图6为本发明实施例提供的测试用例的逻辑结构示例图；57.图7为本发明实施例提供的测试序列生成方法的另一可选流程图；58.图8为本发明实施例提供的步骤s10的可选流程图；59.图9为本发明实施例提供的步骤s14的可选流程图；60.图10为本发明实施例提供的步骤s14的另一可选流程图；61.图11为本发明实施例提供的测试序列生成装置的框图；62.图12为本发明实施例提供的测试序列生成装置的另一框图。具体实施方式63.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。64.基于
背景技术：
：所述，现有芯片设计的验证过程中，生成测试序列的方式需要耗费大量的人力成本。65.这是由于，在进行芯片设计的验证过程中，需要设置大量的约束以产生符合条件的测试序列，从而使得该用于产生序列的方式，需要耗费大量的人力成本进行约束的设置。66.基于此，本发明实施例提供了一种测试序列生成方法、装置、系统及相关设备，所述方法包括：获取测试用例的描述文件，所述描述文件包括所述测试用例的控制逻辑，所述测试用例的控制逻辑至少用于描述测试用例中各测试元素的逻辑关系；解析所述描述文件，确定所述测试用例中的测试元素；从基本规则库中获取对应所述测试元素的约束；其中，所述基本规则库中至少包括所述测试元素的基础约束；基于所述描述文件和所述基本规则库中的约束，生成对应所述测试用例的测试序列。67.可以看出，本发明实施例中的测试序列生成方法，同时基于描述文件以及解析描述文件后，从基本规则库中获取的测试用例中测试元素的约束，实现测试序列的生成，从而使得所述描述文件中，并不需要描述基本规则库中的约束，从而降低描述文件中写入的约束的数量，降低撰写测试用例所耗费的人力成本，进而降低生成测试序列所耗费的人力成本。68.图1示例性的示出了本发明实施例提供的测试序列生成方法的可选流程图。如图1所示，该测试序列生成方法可以包括：69.步骤s10：构建与测试用例的应用场景对应的基本规则库；70.所述基本规则库包括至少基于所述应用场景下各测试元素的基础约束。71.其中，所述测试用例可以由测试元素构成，基于测试元素之间的逻辑关系和各测试元素对应的约束，可以形成完整的测试用例。所述测试元素，可以理解为测试用例的元素(element)，例如可以为测试用例中的变量，参考图2示出的测试用例的测试元素示例图，测试用例中的测试元素可以为操作码(opcode)、命令(command)、地址(addr)、数据(data)等。72.在进行测试用例的描述文件的撰写之前，首先可以构建对应的基本规则库。所述基本规则库用于描述特定环境下测试用例中共用的约束作为基础约束，参考图3示出的基础约束的示例图，所述基本规则库可以针对一个应用场景下的测试用例，相应的，所述基本规则库中则可以描述有针对该应用场景下，各测试元素共用的约束；或者，所述基本规则库可以针对一个应用场景下的一个项目组内的测试用例，相应的，所述基本规则库中则可以描述有针对该应用场景下的项目组内，各测试元素共用的约束，这些共用的约束用于反映对应测试用例的基础规则。73.基于不同应用场景下，测试用例对应的硬件环境不同，因此，所述基本规则库至少针对一个应用场景。相应的，所述基本规则库中至少基于所述应用场景的测试逻辑形成测试元素的基础约束。74.继续参考图3，所述基础约束至少包括测试元素对应在应用场景中的硬件约束，所述硬件约束例如可以为测试元素的位宽、地址、所占用的存储空间中的至少一种。当然，在一些可选的示例中，所述基础约束还可以包括对应测试元素在应用场景中的软件约束，例如，测试元素的数据格式、测试元素的数据类型、测试元素对应的rtl(registertransferlevel，寄存器转换级)设计规则等。75.在一个可选的示例中，所述基本规则库用于定义应用场景(例如整个访问验证环境)中所用到的所有元素(element)，而对元素的定义例如可以包括对元素的位宽以及取值范围的约束，对元素的随机数的取值方法的约束。其中，对元素的随机数的取值方法的约束例如可以为以下情况的任意一种或多种：(i)在约束范围内的完全随机取值；(ii)在需要发送多个指令组时，每个指令中元素的值自动加固定值；(iii)单个指令组中，每个cycle(时钟周期)自动加固定值等。76.可以理解的是，在针对的特定环境越明确时，对应的共用约束越多，且约束的范围越小，对应在基本规则库中，体现为基础约束越多，且约束的范围越小。例如，在一个应用场景下，对应的基础约束可能仅为应用场景的硬件约束和较为基础的软件约束，而在一个应用场景下的一项目组内，对应的基础约束还可以进一步包括该项目组内的，测试元素共用的约束，例如，测试元素的取值范围、测试元素在该项目组内的属性参数、测试元素在该项目组内进一步定义的rtl设计规则等。77.其中，基本规则库中提供的约束越多，对应测试用例的描述文件需要写入的约束越少，进而耗费的人力成本也越少。78.在一个可选的示例中，所述基本规则库可以为哈希(hash)数据库，可以采用schema技术描述其中的基础约束，当然，在其他示例中，所述基本规则库也可以为b 树数据库、fix-length数据库、table数据库等。79.其中，所述基本规则库中还可以进一步进行基础规则的配置，例如，配置随机机制，以使得生成的测试序列在符合相应约束的前提下随机化。在进一步的示例中，所述基本规则库中还可以根据需求进行基础规则的配置，本发明在此不做具体的限定。80.在基本规则库定义了基础约束后，即可进行测试用例的描述文件的撰写。可以理解的是，在应用场景固定的情况下，所述基本规则库也可以为提前构建的，从而，相应的示例中可以不包括步骤s10，进而可以直接基于基本规则库，进行描述文件的撰写，并进一步执行步骤s11～步骤s14，以生成对应的测试序列。81.接着，继续参考图1，执行步骤s11：获取测试用例的描述文件；82.其中，所述描述文件包括所述测试用例的控制逻辑，所述测试用例的控制逻辑至少用于约束测试用例中各测试元素的逻辑关系；83.在一个可选的示例中，参考图4示出的测试用例的结构示例图，测试用例中可以包含环境设置(environment)、启动设置(setup)、测试流程(steps)、结果设置(result)等，其中，所述环境设置中可以包括相应的硬件约束和部分基础的软件约束，可以作为基础约束存储在基本规则库中，所述启动设置中至少部分约束可以作为共用约束存储在基本规则库中，或者，将所述启动设置中的所有约束存储在基本规则库中；所述测试流程、结果设置作为测试用例的控制逻辑，可以描述在测试用例的描述文件中；或者，在其他实施例中，还可以进一步将测试流程、结果设置中的部分可共用的约束存储在基本规则库中，从而进一步简化描述文件，当然，至少所述测试用例的控制逻辑的主逻辑应当保留在所述描述文件中。84.所述描述文件可以为xml(extensiblemarkuplanguage，可扩展标记语言)格式，用于组织、存储相应的测试用例的数据，但并不参与数据的生成、读取、传送、存储等操作。85.其中，基于描述文件中的约束的数量降低，使得对应的描述文件写入过程中，出现写入错误的概率大幅下降。同时，随着描述文件中的约束的数量的降低，还降低了核对描述文件所耗费的人力成本。86.基于本发明实施例中，描述文件包括用于描述测试用例中各测试元素的逻辑关系的控制逻辑，使得测试人员能够清楚直观的确定测试用例的逻辑结构，进而避免多层约束下可能产生的约束冲突，且易于实现对测试用例的修改和复用。87.接着，继续参考图1，执行步骤s12：解析所述描述文件，确定所述测试用例中的测试元素；88.基于所述描述文件中的描述，可以通过解析的方式，确定其中的测试元素。其中，所述描述文件例如可以为xml格式，对应的，可以利用脚本工具解析所述描述文件，确定所述测试用例中的测试元素。89.可以理解的是，所述描述文件可以同时包括测试用例的控制逻辑和对应测试元素的约束，在一个可选的示例中，所述步骤s12中，还可以同时解析确定所述描述文件中对应各测试元素的约束，从而可以在后续步骤中直接利用该部分解析结果，生成相应的测试序列。90.继续参考图1，执行步骤s13：从基本规则库中获取对应所述测试元素的约束；91.基于所述基本规则库中至少包括所述测试元素的基础约束，从而可以从所述基本规则库中获取对应测试元素的约束。具体的，可以基于所述测试元素，查找得到对应所述测试元素的约束。92.具体的，可以通过查询的方式，确定所述基本规则库中，是否包含有对应测试元素的约束。在查询到对应约束时，获取该约束。93.继续参考图1，执行步骤s14：基于所述描述文件中的约束和所述基本规则库中的约束，生成对应所述测试用例的测试序列；94.在获取所述基本规则库中的约束后，即可同时基于所述描述文件中的约束和所述基本规则库中的约束，生成对应所述测试用例的测试序列。95.其中，在所述描述文件中同时包括测试用例的控制逻辑和对应各测试元素的约束时，本步骤具体可以为，基于所述描述文件中，所述测试用例的控制逻辑和对应各测试元素的约束，以及所述基本规则库中对应各测试元素的约束，生成对应所述测试用例的测试序列。96.在一个可选的示例中，步骤s14所生成的测试序列可以为文件的形式，对应的，所述生成对应所述测试用例的测试序列，具体为，生成测试序列文件，所述测试序列文件包括所述测试序列。为提高测试序列文件的可读性，在进一步的可选示例中，所述测试序列文件中还进一步包括生成所述测试序列的约束，其中，所述测试序列还可以分为多个部分，各部分的测试序列可以与生成该部分测试序列的约束一一对应，从而使得测试人员可以直观的得知测试序列及其对应的约束。97.参考图5示出的测试序列文件的结构示例，其中，测试序列包括部分11、部分12和部分13，其中，部分11对应约束21，且约束21对应设置在部分11一侧；部分12对应约束22，且约束22对应设置在部分12一侧；部分13对应约束23，且约束23对应设置在部分13一侧。可以理解的是，图5中仅示出了测试序列文件的其中一种设置方式，在其他可选的示例中，还可以包括采用其他的设置方式，例如将相应的约束对应设置在各部分的上方等等，本发明实施例在此不做具体的限定。98.需要说明的是，在本发明实施例中所述的测试序列的生成方法，基于基本规则库中可以获取到不同测试元素的约束，使得描述文件无需描述过多冗余的约束，即可实现测试序列的生成，降低了用于生成测试序列所需的人力成本。并且，基于描述文件无需描述过多冗余的约束，使得其结构清晰、层次分明，在需要进行调整复用时，更加简单方便，进一步节省了人力成本。99.可以理解的是，所述描述文件中包括所述测试用例的控制逻辑，且不需要写入过多的基础约束，从而使得所述描述文件中可以清晰准确的体现测试用例的数据结构和控制层次，从而在后续测试用例的调整过程中，能够及时准确的找到需要调整的位置，实现测试用例的调整和复用。100.以图6中示出的测试用例的逻辑结构示例图为例，图6中的测试用例(testcase)中包括两个指令组(instructiongroup)，即指令组0和指令组1，每个指令组中均包括有加载(load)/存储(store)/原子操作(atomic)指令，寄存器操作(register)指令，测试平台(testbench)配置指令等。而对应每个指令中，需要基于相应的控制逻辑，对各测试元素进行约束，例如，加载/存储/原子操作指令包括了命令(command)、地址(addr)、数据(data)等不同类型的测试元素，其中，命令可以基于相应的操作码(opcode)，数据格式(dataformat)，数值格式(numericformat)，存储类型(memorytype)等控制域进行对应的约束；地址可以基于索引(index)和偏移量(offset)等进行对应的约束；数据可以基于整数(int)，浮点数(float)，短整数(sint)等不同的数据类型进行约束；相应的，寄存器指令可以包括配置数据(data)，地址(addr)，读写操作类型(read/writetype)等测试元素；测试平台配置指令可以包括命令(command)、控制数据(data)等测试元素。101.而在对应该测试用例的描述文件中，可以包括测试用例所包含的指令组，以及各指令组中，不同指令对应的命令、地址、数据等测试元素，并描述对应该测试元素的控制逻辑，以及在该测试用例中，所述测试元素所对应的具体的约束。102.而在步骤s12中，可以利用脚本工具，解析确定测试用例中的测试元素。例如图6所示的测试用例中，可以解析确定测试用例中各指令中对应的地址、数据等测试元素，并同时可以确定描述文件中，对应该测试元素的约束，以便执行后续的步骤。103.在一个可选的示例中，参考图7示出的测试序列生成方法的另一可选流程图，在生成测试序列之前，还可以对描述文件中的约束进行确认，在描述文件中的约束符合相应的规则时，再执行测试序列的生成。104.具体的，在步骤s13之后，步骤s14之前，执行对描述文件中的约束的确认流程，包括：105.步骤s21：确定所述基本规则库中是否存在所述测试用例中所有测试元素的约束；106.其中，基本规则库中默认定义了测试用例中的所有测试元素，在描述文件中存在基本规则库中没有定义的测试元素时，则产生错误信息，退出测试序列的生成流程。在确定所述基本规则库中存在所述测试用例中所有测试元素的约束时，则执行步骤s22。107.步骤s22：基于所述基本规则库中，各测试元素的约束，确定描述文件中的测试元素的约束范围是否在所述基本规则库中对应测试元素的约束范围内；108.所述描述文件中的测试元素的约束范围应当在所述基本规则库中对应测试元素的约束范围内，从而避免描述文件的约束越界。109.其中，需要说明的是，描述文件中的测试元素的约束范围等同于所述基本规则库中对应测试元素的约束范围，也可以理解为，描述文件中的测试元素的约束范围在所述基本规则库中对应测试元素的约束范围内。110.例如，基本规则库中对应各测试元素的约束，可以确定描述文件中的测试元素的取值范围是否越界，或者，测试元素的取值方法是否为基本规则库中定义的方法之一，以判断描述文件中的测试元素的约束范围是否在所述基本规则库中对应测试元素的约束范围内。111.描述文件中的测试元素的约束范围不在所述基本规则库中对应测试元素的约束范围内时，则认为描述文件为错误，进而产生错误信息，退出测试序列的生成流程。112.在确定描述文件中的测试元素的约束范围在所述基本规则库中对应测试元素的约束范围内时，执行步骤s14。113.通过对描述文件进行约束的确认流程，可以及时发现描述文件中可能出现的错误，避免错误的描述文件影响芯片设计的验证/测试流程。114.在一个可选的示例中，所述基本规则库可以基于相应的规则文件生成。参考图8所示的步骤s10的可选流程图，步骤s10可以包括：115.步骤s101：获取规则文件；116.其中，所述规则文件用于描述测试元素的基础约束。117.所述规则文件可以由测试人员撰写得到，也可以由用于生成规则文件的工具生成。在一个可选的示例中，所述规则文件可以通过schema技术对基础约束进行描述，从而可以方便的进行block层到soc层的移植和集成，进而在仿真验证阶段，实现与仿真验证平台的衔接。118.通过schema技术可以简单方便的描述testcase的基本规则，包括操作码、命令、地址、数据的位宽和类型等，从而使得测试用例的描述文件只需要完成少量的配置和约束，即可基于基本规则库生成想要的测试序列。119.具体的，所述规则文件的格式可以为xsd(xmlschemadefinition，文档结构描述)。120.步骤s102：解析所述规则文件，确定所述测试元素的基础约束；121.通过解析所述规则文件，可以获取相应的基础约束信息，从而基于所述基础约束信息，构建所述基本规则库。122.具体的，可以采用脚本工具进行所述规则文件的解析。123.步骤s103：基于所述测试元素的基础约束，构建形成基本规则库；124.其中，所述基本规则库可以为哈希数据库，也可以为其他类型的数据库，在进行基本规则库的构建过程中，可以采用与对应的类型的数据库相匹配的构建方式，例如，在基本规则库为哈希数据库时，可以采用哈希数据库的构建方式进行基本规则库的构建。125.另外，需要说明的是，所述基本规则库中同时可以配置有基础规则，例如用于实现测试序列随机化的随机机制等，该基础规则可以在基本规则库的构建过程中配置。相应的，构建所述基本规则库可以包括：配置所述测试用例的应用场景下，测试元素的基础约束；配置所述测试用例的应用场景下的基础规则。126.需要说明的是，基本规则库可以为固定不变的，也可以基于预设的时机进行更新，例如，在应用场景有变更时，相应的进行基本规则库的更新，或者，基于预设的周期对基本规则库进行适应性的调整(即更新)。其中，所述更新的内容可以为基础约束，也可以为基础规则，本发明在此不做具体的限定。127.在一些的示例中，参考图9示出的步骤s14的可选流程图，在生成测试序列时，可以基于测试元素在前一流程的取值的基础上确定测试元素在当前流程的取值。128.具体的，步骤s14可以包括：129.步骤s14a：确定所述测试用例中，所述测试元素的前一取值；130.其中，所述测试元素的前一取值，可以理解为在测试用例需要发送多个指令组时，对应当前指令中的测试元素在前一指令组中的取值，或者，在测试用例的单个指令组中，测试元素在前一时钟周期的取值。131.可以理解的是，在测试用例需要发送多个指令组时，当前指令可以为已经确定了多个指令组的取值之后的指令组中的指令，也可以为第一个需要确定的指令组中的指令。在当前指令为执行的第一个需要确定的指令组中的指令时，可以确定测试元素的前一取值为空值。132.相应的，在单个指令组的取值过程可以包括多个时钟周期内的取值时，当前时钟周期前可以为已经确定了多个时钟周期内的取值之后的时钟周期，也可以为需要确定的第一个时钟周期。在当前时钟周期为需要确定的第一个时钟周期时，可以确定测试元素的前一取值为空值。133.步骤s14b：基于所述测试元素的前一取值以及对应该测试元素的约束，确定该测试元素的当前取值；134.在确定了测试元素的前一取值后，可以基于该前一取值，以及对应该测试元素的约束(例如可以为测试元素的取值方法)，确定该测试元素的当前取值。135.例如，所述测试元素的取值方法约束为：(ii)在需要发送多个指令组时，每个指令中元素的值自动加固定值；相应的，可以基于测试元素的前一取值，加上固定值，确定测试元素的当前取值。136.或者，所述测试元素的取值方法约束为：(iii)单个指令组中，每个cycle(时钟周期)自动加固定值；相应的，可以基于测试元素的前一取值，加上固定值，确定测试元素的当前取值。137.可以理解的是，基于测试平台(testbench)不同，所需要的测试序列的类型也不同，例如，测试平台可以为c ，systemverilog，verilog，systemc等，其对应的测试序列的类型也应当是适应于对应测试平台。基于前述步骤已经获取了描述文件中的约束和所述基本规则库中的约束，本步骤已经得知了用于描述测试用例的所有信息，在此前提下，本发明实施例可以基于该测试用例的信息，生成任一类型的测试序列。138.在一个可选的示例中，参考图10示出的步骤s14的另一可选流程图，步骤s14可以进一步包括：139.步骤s141：获取用于生成的测试序列的类型信息；140.其中，所述测试序列的类型信息可以写入在描述文件中，并作为约束从所述描述文件的解析过程中获取。或者，所述测试序列的类型信息可以在生成测试用例时，基于用户输入的信息确定，例如，在显示器件上弹出提示信息，使得用户基于该提示信息，输入所需生成的测试序列的类型信息，进而获取该测试序列的类型信息。141.步骤s142：调用与所述类型信息对应的指令类型的处理子函数，生成测试序列。142.可以理解的是，基于不同的类型信息，对应有不同的指令类型(instructiontype)，在确定所述类型信息后，可以基于对应指令类型的处理子函数，生成测试序列。其中，所述处理子函数为定义在脚本工具中，用于辅助流程执行的函数。143.在生成对应类型的测试用例后，可以直接将测试用例提供给相应的测试平台使用。144.可以理解的是，基于不同指令类型的处理子函数，可以生成不同类型的测试序列，也就是说，本发明实施例中的描述文件是可以对应不同测试平台的通用文件，从而扩展了本发明实施例的适用环境。并且，本发明实施例中描述文件的适用环境的扩展，使得描述文件并不需要基于不同的测试平台撰写不同的代码，进一步降低了人力成本。145.下面对本发明实施例提供的测试序列生成装置进行介绍，下文描述的装置内容可以认为是芯片测试设备或者计算机设备，为实现本发明实施例提供的测试序列生成方法所需设置的功能模块。下文描述的装置内容可与上文描述的方法内容相互对应参照。146.图11示出了本发明实施例提供的测试序列生成装置的框图。如图11所示，该装置可以包括：147.文件获取模块200，用于获取测试用例的描述文件，所述描述文件包括所述测试用例的控制逻辑，所述测试用例的控制逻辑至少用于描述测试用例中各测试元素的逻辑关系；148.文件解析模块210，用于解析所述描述文件，确定所述测试用例中的测试元素；149.约束获取模块220，用于从基本规则库中获取对应所述测试元素的约束；其中，所述基本规则库中至少包括所述测试元素的基础约束；150.序列生成模块230，用于基于所述描述文件和所述基本规则库中的约束，生成对应所述测试用例的测试序列。151.在一些实施例中，参考图12示出的本发明实施例提供的测试序列生成装置的另一框图，所述测试序列生成装置还包括：152.规则库构建模块240，用于构建与测试用例的应用场景对应的基本规则库，所述基本规则库至少包括基于所述应用场景下各测试元素的基础约束。153.在一些实施例中，所述规则库构建模块240，用于构建与测试用例的应用场景对应的基本规则库，包括：154.获取规则文件，所述规则文件用于描述测试元素的基础约束；155.解析所述规则文件，确定所述测试元素的基础约束；156.基于所述测试元素的基础约束，构建形成基本规则库。157.在一些实施例中，所述规则库构建模块240，用于构建形成基本规则库，包括：158.配置所述测试用例的应用场景下，测试元素的基础约束；159.配置所述测试用例的应用场景下的基础规则。160.在一些实施例中，所述序列生成模块230，用于生成对应所述测试用例的测试序列，具体为，生成测试序列文件，所述测试序列文件包括所述测试序列和生成所述测试序列的约束。161.在一些实施例中，所述测试序列包括多个部分，所述测试序列文件中，各部分测试序列与生成该部分测试序列的约束一一对应。162.在一些实施例中，所述序列生成模块230，用于生成对应所述测试用例的测试序列，包括：163.获取用于生成的测试序列的类型信息；164.调用与所述类型信息对应的指令类型的处理子函数，生成测试序列。165.在一些实施例中，所述文件解析模块210，用于解析所述描述文件，确定所述测试用例中的测试元素的过程中，所述解析过程还确定所述描述文件中对应各测试元素的约束；166.所述序列生成模块230，用于基于所述描述文件和所述基本规则库中的约束，生成对应所述测试用例的测试序列，具体为，基于所述描述文件中，所述测试用例的控制逻辑和对应各测试元素的约束，以及所述基本规则库中对应各测试元素的约束，生成对应所述测试用例的测试序列。167.在一些实施例中，所述基础约束包括：各测试元素在所述应用场景下的硬件约束和软件约束，所述硬件约束为测试用例的位宽、地址、所占用的存储空间中的至少一种，所述软件约束为测试用例的数据格式、测试元素的数据类型、测试元素对应的rtl设计规则中的至少一种。168.在一些实施例中，所述描述文件为xml格式，所述文件解析模块210，用于解析所述描述文件，确定所述测试用例中的测试元素，具体为，采用脚本工具解析所述描述文件，确定所述测试用例中的测试元素。169.在一些实施例中，所述规则文件为xsd格式，所述规则库构建模块240，用于解析所述规则文件，具体为，采用脚本工具解析所述规则文件。170.本发明实施例还提供一种芯片验证系统，在一些实施例中，该芯片验证系统可以被配置为执行本发明实施例提供的测试序列生成方法。171.本发明实施例还提供一种计算机设备，该计算机设备可以包括：至少一个存储器和至少一个处理器；所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行本发明实施例提供的测试序列生成方法。172.本发明实施例提供一种存储介质，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令用于执行上述的测试序列生成方法。173.上文描述了本发明实施例提供的多个实施例方案，各实施例方案介绍的各可选方式可在不冲突的情况下相互结合、交叉引用，从而延伸出多种可能的实施例方案，这些均可认为是本发明实施例披露、公开的实施例方案。174.虽然本发明实施例披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
