在用于编译自动化半导体器件测试的测试计划的开发环境内实施编辑并更新功能性的制作方法_3

文档序号:9457552阅读:来源:国知局
试类开发者而言不是很有用。如果用户在制备测试类时出现实质性错误或者当测试计划正在执行时由于任何其他原因而需要替换测试类,则他们通常必须停止测试计划并且首先将测试计划卸载。接着,他们需要重新加载测试计划并且在返回到代码的源点之前从开始处重新启动该测试计划。这种工作流程是费时的并且容易出错。
[0056]因此,本发明的实施例提供了一种允许用户在测试计划执行过程中对测试类做出改变而不需要手动执行所有以上讨论的步骤的自动化方法和系统。这允许开发者以比使用常规系统所允许他们的方式显著更高效且不易出错的方式来制备和调试测试类。
[0057]为了达到这一目的,本发明的实施例在测试仪软件系统内提供了编辑并更新功能。当调试时,用户可以在测试类源代码中设置引起系统停止的断点。用户可以编辑源代码,由此发起编辑并更新会话。然后,存储状态信息并且卸载编辑后的测试类。随后,编辑并更新程序将重新编译编辑后版本的测试类并用新编译的版本替换原始版本。然后,编辑后的测试类被重新执行并自动后退到与用户中断调试的地方相同的断点,并且之前存储的状态信息被恢复。然后,测试计划可以用新编辑的代码继续进行。
[0058]使用本发明的实施例,开发者可以对测试类做出实质性改变而不局限于仅实施微小编辑。实际上,本发明的一个实施例支持改变整个测试类文件而不是文件的仅一小部分。
[0059]图2A是根据本发明的一个实施例,可在其上实施编辑并更新程序的实施例的自动化测试设备(ATE)装置的示意性框图。在一实施例中,系统控制器201包括一个或多个链接的计算机。例如,测试系统(如爱德万测试株式会社的T2000测试仪系)可以使用计算机网络。在其他实施例中,系统控制器经常仅包括单个计算机。系统控制器201是整个系统控制单元,并且运行ATE的负责完成所有用户级测试任务的软件,包括运行用户的主测试计划。这种测试仪软件的一个示例是T2000系统软件。通常,测试仪软件(如T2000)包括编译器,该编译器对用测试仪系统的编程语言(例如,0PENSTAR测试编程语言(“0TPL”))编写的测试计划进行编译。
[0060]通讯器总线215在系统控制器与测试仪硬件之间提供高速电子通信信道。该通讯器总线还可以称为背板、模块连接使能器、或系统总线。物理上,通讯器总线215是快速、高带宽双工连接总线,该总线可以是电学的、光学的等。在一个实施例中,通讯器总线215可以使用TCP/IP协议。系统控制器201通过经由通讯器总线215发送的命令来对测试仪硬件进行编程,从而设立用于测试DUT 211-214的条件。
[0061 ] 测试仪硬件202包括向被测器件(DUT) 211-214提供测试激励和测量DUT对该激励的响应并且将其与预期响应进行比较所需的电子和电气零件和连接器的复杂集合。
[0062]图2B是图2A的自动化测试设备装置的一个实施例的更详细的示意性框图。在图2B中所示的实施例中,测试仪硬件202可以包括多个现场控制器207,其中每个现场控制器连接至多个DUT。每个现场控制器是在器件测试中所使用的计算机。测试计划程序可以在现场控制器上执行,该现场控制器在执行DUT 290的器件测试过程中控制测试模块280。现场控制器270连接至系统控制器,该系统控制器通过通讯器总线215控制现场控制器。在某些实施例中,测试开发者不能直接操作现场控制器,而是在系统控制器201上处理由开发者执行的操作,该系统控制器通过通讯器总线215控制现场控制器。
[0063]在一个实施例中,现场控制器270和测试模块280可以通过高速光总线连接。总线开关285具有用于将现场控制器与测试模块连接的矩阵结构。使用总线开关285允许现场控制器与任意测试模块280连接,并且允许配置总线连接的灵活性。
[0064]器件测试所需的测试模块280通常安装在测试系统测试头中。测试模块配置可以适配于目标器件。器件测试所需的测试模块280的集合被称为测试现场。每个测试现场295由现场控制器控制。对于许多应用而言,可能存在各种类型的测试模块。一些示例性类型的模块是同步发生器模块、同步矩阵模块、器件电源模块、模拟模块、RF模块和数字模块。
[0065]图3展示了关于不同测试实例可以从单个测试类创建的方式的图。如以上详细讨论的,测试类允许用户通过提供用于为该项测试的具体实例指定选项的参数来配置类行为。例如,用于实施功能测试的测试类可以提供用于指定在正被测试的DUT上执行的测试模式的参数。其还可以提供用来为测试指定等级和定时条件的参数。为这些参数指定不同的值允许用户创建功能测试的不同实例。
[0066]在如T2000的测试仪软件系统中,可以用如上讨论的测试编程语言(如0TPL)描述测试计划。OTPL可以用于描述测试执行顺序和所用的相应测试条件。虽然OTPL可以描述测试计划,但通常不描述任何测试算法。例如,系统中的测试算法(如T2000)可以使用如以上所披露的测试类中的C++语言来描述。
[0067]虽然对本发明的讨论是以T2000测试仪软件为背景,其中测试计划是使用OTPL开发的,并且测试类是使用C++开发的,但是本发明不局限于本实施例。其他实施例中可以采用使用不同编程语言的其他类型的测试仪软件。本领域内的普通技术人员应理解的是,本发明的教示可以涵盖可包括在所附权利要求书限定的本公开的精神和范围内的替代、修改以及等同形式。
[0068]在来自图3的示例中,测试类310可以用于创建测试“测试类型X”的三个单独的实例。这三个实例中的每个实例(实例I 320、实例2 340和实例3 350)接收该测试的每个实例的单独的参数数据集。例如,实例I 320接收参数数据330,而其余的实例接收其自己的参数集。
[0069]图4是展示了测试计划内的测试类的验证和执行的示例性软件过程的示意性框图。
[0070]在一实施例中,用户将关于各个测试类的必要参数和其他一般特性的所有信息输入到预头文件410。关于这些参数的信息可以包括参数名、其允许值、其类型等。
[0071]在常规测试仪系统中,测试仪系统软件可以提供用于验证适当的参数可供用于包括在所生成的源代码中的机制。该测试仪系统软件提供了允许测试类开发者在每测试类基于文本的源文件中完全指定的方法,开发者已经指定的测试类的公共方法和属性是参数化该类别所需的方法和属性。在文本文件中指定其方法和属性允许测试仪软件容易地确定适当的参数是否可供使用,这方便了转换阶段期间测试计划的错误检测和验证。在常规ATE系统中,这种基于文本的描述内置在测试类的预头文件中,其由测试仪软件中的编译器用来确定测试类的方法和属性。进一步地,其由编译器用于生成测试类的报头。在一实施例中,与测试类本身类似,测试类的报头也可以用常规编程语言,如C++。所生成的C++头文件是用于最后编译测试类C++代码的头文件。
[0072]如所讨论的,预头文件由测试仪系统软件用于直接从预头文件自动生成测试类声明C++头文件415。所生成的C++头文件是用于最后编译测试类C++代码435的头文件。C++测试类代码435被编译成可以被加载以便在测试仪系统软件420中执行的二进制DLL文件。
[0073]在验证阶段期间,测试仪系统软件420(又被称为“测试仪操作系统”)读入测试计划作者所开发的测试计划OTPL代码450并分析其错误。预头文件410由测试仪操作系统420用于描述测试类和测试类所需的参数。通过描述测试类,预头文件允许测试仪系统软件420验证适合的参数被传递至测试类的各个实例。
[0074]OTPL代码450和二进制DLL测试类文件475然后被加载到测试仪系统软件420中。在一个实施例中,在验证了 OTPL代码450之后,测试计划代码450然后实例化测试类并且使用来自预头文件410的信息来确定用于测试类实例化的适当参数。测试仪操作系统420可以基于预头文件410中所提供的信息填充各个测试类的参数。例如,在图4中,测试仪操作系统可以读入模式列表490和模式495,模式列表490和模式495可以用作在OTPL代码450中实例化的某些测试类的参数。然后,测试仪系统软件420执行测试计划425。
[0075]图5是根据本发明的一个实施例,展示了编辑并更新功能的实施方式的示例性软件过程的框图。
[0076]在一个实施例中,在框501,用户启动开发环境(例如,Visual Stud1)并且加载用户想要使用该应用进行调试的测试类项目。在框502,用户启动测试仪系统软件(“TSS”)。在启动TSS之后,在503,用户加载测试计划或测试程序。然后,在504,用户将调试器附接至现场控制器,该现场控制器可以连接至正被测试的DUT,以开始测试会话。用户还在他们想要调试的测试类的方法中设置断点。例如,用户可以在被称为“preExecO ”的方法中设置断点,该方法是包括如框508中所示的流程项2519的方法之一。包括流程项519的其他示例性方法分别是框509和510处的“execute O ”和“postExec O ”。
[0077]然后,在框505,用户将会执行测试流程。首先执行518处的第一流程项(流程项Do然而,在执行框519处的流程项2的过程中,调试器将会在框508处的preExecO中的断点处中断,并且源代码在调试环境的代码窗口中是可见的。在此点,用户可以单步通过该代码直至用户到达需要对代码进行编辑的点。用户可以对与测试类项目相关联的同一文件或其他文件中的代码进行编辑。在一个实施例中,不是进行编辑,而是用户还可以只是离开调试器并且继续执行。
[0078]如果进行编辑,则在完成编辑之后,在516,用户可以调用编辑并更新程序。例如,当执行流程项2时,用户可以在preExecO内的方法“AAA O ”处调用编辑并更新。在一个实施例中,当调用编辑并更新程序时,正在被调试的整个测试类方法(即,方法preExecO、execute O和postExecO)的执行将会在测试仪操作系统在框511暂停之前完成。在另一个实施例中,编辑并更新程序可以在没有完成测试流程项中的其余方法的执行的情况下立即暂停。在本实施例中,用户可以立即跳出执行任何其余的测试类代码,然后暂停执行测试计划以允许重建和重新加载测试类。
[0079]在一个实施例中,编辑并更新程序将会记录其被调用所在的行,从而使得编辑并更新程序可以在测试类已经被更新和重新加载之后使用户返回至同一行(在下文中被称为“当前行”)。
[0080]在框512,调试器与其在框504所附接到的现场控制器脱离。现场控制器270通常是测试类正在执行的地方。系统控制器201通常是开发环境运行的地方。因此,用户通常在现场控制器270上实施来自系统控制器201的远程调试会话。
[0081]在框512,调试器与现场控制器脱离,并且卸载已实现的测试类。在图5的示例中,将会须要卸载与流程项2519相关联的任何测试类和从其中得到的任何其他类。这是因为如果该程序要针对已实现的“基础”类而改变内存,则该程序还需要针对基于该基础测试类的其他“派生”类而改变内存。因此,编辑并更新程序首先需要标识所有衍生的测试类。接下来,卸载基础测试类和基于该基础测试类的所有衍生的测试类。因为测试类在本阶段是DLL,所以它们需要在它们可以被编辑并更新之前被卸载。在不卸载已实现的测试类DLL的情况下,处于其暂停状态的可执行测试计划仍然处理它们,这阻止了它们被写入。
[0082]在框513,编辑并更新程序将在开发环境的代码窗口中修改的源测试类文件进行保存,然后编译测试类
当前第3页1 2 3 4 5 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1