为了本专利申请的目的，将计算机病毒作如下定义：病毒是一种 在没有直接的人类交互作用的情况下以可能变形的方式传播的自我复 制程序或例程。这一方面可参考共同受让的美国专利号5,613,002， 这里引用其全文作为参考。
自动软件测试工具在所属技术领域是已知的。例如，可参考 Warfield的美国专利号5,754,760“Automatic Software testing tool”(自动软件测试工具)和Parker等人的美国专利号5,600,789 “Automated GUI Interface Testing”(自动化GUI界面测试)。 也可以参考Halviatti等人的美国专利号5,475,843“System and Methods for Improved Program Testing”(用于改进的程序测试的 系统和方法)。
某些类型的计算机病毒仅当特定的代码段被执行时才复制。这是 因为，与普通病毒不同的是，它们把自己插入到宿主应用程序中的一 个不是应用程序的入口的位置。为了复制这类病毒，必须尝试测试程 序的每个部分，即必须尝试达到最大的代码覆盖率。可以知道，复制 这些病毒是非常困难和耗费时间的，因为要求通过宿主程序的GUI对 宿主程序的每一个特征功能(feature)进行系统的测试。在本发明之 前，发明人不清楚有任何适合于复制这类计算机病毒的自动软件评估 或测试工具。

按照本发明实施方案的方法和装置克服了上述的和其它的问题。
本发明的第一个方面是提供一种实现计算机病毒的自动复制的机 制。
本发明的第二个方面是提供以模拟不熟悉应用程序的特征功能的 没有经验的用户的动作的方式实现对带有用户界面的计算机软件应用 程序的自动测试的方法和装置。
公开一种用于自动地测试带有图形用户界面(GUI)的目标应用程 序进程的方法，一种用于实现该方法的系统和一种存储在计算机可读 介质上的体现该方法的计算机程序。该方法包括计算机执行的以下步 骤：开始目标应用程序进程；检测由目标应用程序进程打开的第一窗 口的出现；通过确定第一窗口的内容包括用户控件(controls)列表， 处理第一窗口；测试用户控件，一直到所有的用户控件都已经被测试， 有可能导致终止(termination)的用户控件被识别并在较小可能导致 终止的用户控件之后被测试；关闭第一窗口。测试的步骤包括估计用 户控件的最佳执行顺序和要被输入到用户输入栏的文字的步骤。如果 测试某特定用户控件导致第一窗口在第一窗口的所有用户控件已经被 测试之前就关闭，该方法进一步包括以下步骤：重新打开第一窗口； 除非要求该特定用户控件在该窗口的所有用户控件都被测试后关闭第 一窗口，否则测试该窗口的除该特定用户控件以外的用户控件。
如果测试某特定用户控件导致第二窗口打开，该方法包括以下步 骤：确定包括用户控件列表的第二窗口的内容；测试用户控件，一直 到第二窗口的所有用户控件都已经被测试；关闭第二窗口；继续对第 一窗口的处理。
测试的步骤包括估计用户控件的最佳执行顺序和要被输入到用户 输入栏的文字的步骤，最好至少部分地根据从打开的窗口获得的信息 进行估计。该顺序确定适用于所有的用户控件，诸如按钮控件、编辑 前选择栏(selection fields before edit)控件、按钮控件前编辑控 件(edit controls before button controls)、等等。
在各个用户控件被测试之后，本方法包括的进一步的步骤是：枚 举系统窗口；确定在所枚举的系统窗口中是否已经有因新的窗口被打 开而产生的变化；如果已经有变化，则在恢复处理第一窗口之前处理 该新窗口。该方法的这个方面进一步通过比较目标应用程序进程的程 序标识与每个新打开的窗口的程序标识而确定新打开的一个或多个窗 口是否是与目标应用程序相关联的。如果新窗口不是与目标应用程序 相关联的，该方法就通过处理该新窗口或关闭该新窗口而继续；然后 继续处理第一窗口。如果检测到多个新窗口已经被打开，该方法确定 该多个新窗口之间是否存在父子关系。如果发现存在父子关系，该方 法就在处理父窗口之前处理子窗口。如果没有发现该多个新窗口之间 存在父子关系，该方法可以以任意顺序处理该多个新窗口；然后继续 处理第一窗口。
处理的步骤包括一个维持一个与目标应用程序相关联的窗口的列 表的步骤，该列表含有每个窗口的编号(handle)、名称、类、窗口中 含有的用户控件列表、窗口的状态、和已经导致该窗口关闭的任何用 户控件的标识。两个窗口仅当如果它们至少有相同的类、名称和用户 控件时才被视为是相同的，并且如果某新窗口至少有与窗口列表中现 有的某窗口相同的类、名称和用户控件时，就不把新窗口添加到窗口 列表中，而是把列表中的对应窗口的编号及其用户控件作相应的更 新。
在该方法的优选实施例中，对话(dialog)用户控件的处理的顺 序根据的是它们的类型，其中，组合框对话用户控件首先被处理，接 着是编辑栏，接着是按钮用户控件。在按钮用户控件中，最可能导致 终止的那些按钮用户控件被最后处理。
组合框包括一个与一个静态控件(static control)或者编辑控件 (edit control)组合的列表框。控件的列表框部分可以在所有时间内 都被显示，或者可以仅当用户选择控件旁边的下拉(drop-down)箭头 时才下拉(drop down)。这个控件和其它控件的说明见于微软出版社 出版的微软开发者网络知识库(Microsoft Developer Network knowledge base)中，特别是在出版物“Visnal C++程序员指南” “Visual C++programmer guide”中。
用户控件也可以包括菜单项和子菜单项，在执行的步骤期间，通 过发送一个命令消息来模拟在某特定菜单或子菜单项上的点击，在 Windows环境中，这个命令消息诸如是一个发往目标应用程序进程的 WM_COMMAND消息，传送命令标识作为参数。处理的步骤包括一个进一 步的创建一个所有子菜单项列表的步骤，以及一个通过考虑每个菜单 项的名称及其位置而确定测试菜单项的顺序的步骤，那些可能导致终 止的菜单项在最后被执行。
附图简介
随后的发明详述结合附图更清楚地说明本发明的上述以及其它特 点。
图1是适合于实现和实践本发明的数据处理系统的框图；
图2、3和4是按照这些示教的方法的逻辑流程图；
图5表示一个具有菜单和编辑区的典型应用程序窗口；和
图6表示一个典型的对话窗口。
发明详述
作为介绍，参看表示典型的应用程序窗口的图5和6。常规的带有 GUI的应用程序可能包括一个或多个这样的窗口。典型的窗口含有标题 501、601，并且一般包含界面对象的多个主要类型(interface objects)：例如，带有子菜单505和控件或者仅带有控件的菜单504、 505。控件包括任何种类的按钮，诸如按键式按钮(push button)606、 607，单选按钮(radio button)605，复选框(check box)等等，还 包括允许用户输入的栏506和604，选择框和其它界面对象。这些控件 的每个本身就是窗口，可被视为包含窗口的“子”窗口。这个父-子关 系使用户能获得由每个窗口显示的控件的一个列表。在这些示教的优 选实施例中，只有标准类型的控件被处理，因为这些控件是最常见的。 然而，这些示教并不仅仅限于只处理标准类型的控件，而是可以包括 各种各样的控件类型。
应当注意到，尽管在系统上的顶层窗口之间有父-子关系，例如， 某个作为对主窗口的操作结果而显示的对话窗口被视为该主窗口的一 个字窗口，窗口中包含的对象经常是用特殊的标志来区分的。例如， 在微软视窗系统上，包含在某窗口内的对象有一个显示的 WS_CHILDWINDOW标志，而顶层窗口则没有。如果有关的特定窗口不采 用这种标志，则可能需要根据可获得的系统特定的信息对关系进行估 计或猜测。例如，在一个假设的系统中，编号数量(handle numbers) 可能存在差别。
通过“点击”各种控件或菜单项，以及在诸如编辑框等用户可控 制的栏中设置信息，按照这些示教的方法，自动地模拟各个用户的动 作。这些示教的一个重要方面是不要求对GUI各部件有预先的知识。
尽管可能由若干种方法向另一个程序发送信息，这些示教的目前 的优选实施例利用窗口消息接发(messaging)和标准应用程序接口 (APIs)进行通信。不过，本发明的示教并不限于仅仅使用一种特定类 型的消息接发和/或APIs。总之，对APIs和消息的说明是平台特定的， 能在对应特定平台的文件中找到。仅举一个例子，对于Window环境来 说，可以在微软开发者网络知识库提供的Platform SDK：Windows User Interface文件中找到Windows APIs的说明。
图1中所示的框图表示系统的基本结构。在这个示意图中，假设 目标应用程序进程104显示窗口122。目标应用程序进程104被怀疑 可能染上了计算机病毒，诸如上文中讨论的类型的计算机病毒。为了 验证计算机病毒的存在，以及/或者获得多个该计算机病毒的样本或实 例，有必要尽可能彻底地测试目标应用程序进程104。图1中所表示的 系统用于以自动的方式执行这个任务，而无需具有目标应用程序进程 104的或各种窗口的细节的预先知识，包括其GUI可能采用的用户控件 和对话框。控制器100用进程API 103和消息接发API 121测试目标 应用程序进程104。
在本优选实施例中，控制器100的主要部件包括一个程序分析器 101，它控制处理的各个方面，并维持窗口的列表，包括当前在系统窗 口列表109中和在应用程序窗口列表116中显示的那些窗口。控制器 110因此进一步包括一个窗口枚举器106、一个窗口探测器112和一个 窗口处理器119。窗口枚举器106用进程API 103枚举(107)所有当 前打开的窗口，进程API 103返回唯一地标识窗口系统上打开的每一 个窗口的编号。窗口枚举器106用系统窗口列表109来确定在列表创 建以后已经被打开的窗口。新打开的窗口的编号然后被传送(110)到 程序分析器101，程序分析器确定那些属于目标应用程序进程104的窗 口。目标应用程序进程104的新打开的窗口的编号被逐个地传送(111) 到窗口探测器112，窗口探测器然后用每个窗口编号来确定每个窗口是 否已经被看到，或者还是新的。这可以通过检查在路径113上接收的 来自已经存储在应用程序窗口列表116中的关于每个窗口的信息而实 现。在前一种情况下，“新的”窗口已经被看到，窗口探测器用窗口 的新编号和其控件的新编号来更新(114)应用程序窗口列表116中的 新打开的窗口的条目。在后一种情况下，新打开的窗口以前没被看见 过，窗口探测器112在路径115上把该新窗口的条目加到应用程序窗 口列表116中并确定其控件和菜单项。每个新打开的窗口的编号然后 通过路径118被传送到窗口处理器119，后者用应用程序窗口列表116 中含有的信息来测试窗口122的每个控件。
应当注意的是，事实上，尽管能用新打开的窗口的窗口编号来获 得窗口信息(类、名、控件列表)，如果窗口已经在被关闭后再打开， 则存储在应用程序窗口列表116中的编号信息是过时的，但是其余信 息仍然是可用的。
人们在试图自动化一个未知程序时遇到的一个重要问题是通常缺 少关于控件必须被按下或测试的预期顺序的信息，以及预期要被传送 到用户可控制的窗口栏的信息的类型。
测试这样的程序的最直截了当的方式是简单地随机测试菜单项和 控件。然而，这个技术有许多缺点。例如，它可能导致目标应用程序 进程104的立即终止，因为它最可能导致产生太多的错误条件，甚至 导致开始一个无限循环。
这些技术所采用的一个更有用的方法是试图根据从每个个别窗口 获得的信息估计各个窗口的内容、预期的输入以及最佳执行顺序。就 是说，对各个窗口的内容、预期的输入以及用户控件的最佳执行顺序 的估计，根据的是从窗口派生出的关联内容，可能也根据某种试探法， 诸如由某类型的用户可加载文本框所预期的典型输入(例如文件名， 或者某种类型的设备，诸如驱动程序的标识与打印机的标识等。)
控制处理的最佳顺序是由最佳顺序确定部件117在视窗探测器 112获得新窗口的控件列表时确定的。对最佳顺序确定部件的输入来自 一个名为控件的序列列表123的模块。
最佳顺序确定部件117的任务由于大多数GUI应用程序都使用许 多标准窗口而被简化。最常见的界面，类型例如多文档界面(MDI- Multiple Document Interface)或单文档界面(SDI)，含有在第一 子菜单中的文件操作(新建、打开、关闭、...、退出)菜单，以及大 的用户可控栏(见图5，特别是部件502-505以及506)。此外，许多 应用程序所显示的许多对话都是标准的：(打开、另存、寻找、替换、 等等)。通过利用这些对话的常见外观，程序或控制器100就能对最 常见的操作顺序以及预期在用户可控栏中的信息作出准确的估计。
在处理未知窗口时，最好使用最常用的处理顺序。例如，大多数 对话都要求用户首先从列表中选择信息，然后在编辑栏敲入数据，用 其它控件设置选项，最后点击按键式按钮。对有些按钮的点击有可能 导致对话的终止。本文将这些类型的按钮称作“终止”按钮，“终止” 按钮的执行最好放在对给定窗口的处理的最后。例如，在图6中，指 示符606表示终止按钮“OK”(同意)和“取消”。
从图6中显而易见，一个窗口可含有多个“终止”按钮。此外， 其它栏还可以导致窗口的终止。因此，窗口可能会在其所有控件都被 处理之前消失。然而，为了最大化代码覆盖率(code coverage)，在窗 口关闭之前应当测试窗口中存在的所有的控件。
按照本发明当前的优选实施例，如果新窗口在其所有的控件都被 探测和测试之前就消失，则重复最初导致窗口显示的操作，直到窗口 中所有的控件都被处理，但是不要重复导致窗口关闭的步骤，除非需 要它来终止窗口并且它是唯一的终止控件。
许多操作通常将导致另一个窗口或几个窗口被显示。在这种情况 下，在继续处理最初的窗口之前，要对每个新打开的窗口循环地应用 所述的方法。一旦新窗口被处理，控制就被返回到先前被处理的窗口， 在下一个界面对象处恢复其界面对象的处理。
反映按照本发明的示教的方法被表示在图2、3和4中的逻辑流程 图中。
以图2作为开始，也参看图1，在步骤201，先从系统窗口列表109 获得系统上所有打开的窗口的列表，再在步骤202启动应用程序。在 步骤203再次枚举各窗口，以便在步骤204确定是否有任何窗口被在 步骤202启动的应用程序显示过。如果该应用程序没有显示过任何窗 口，则假设该应用程序没有GUI，因此不能被本方法测试。在这种情况 下，本方法终止。如果有一个或多个窗口被目标应用程序进程104显 示，就处理每个新打开的窗口，如图3中所示的那样，直到所有新窗 口都被处理(步骤205、206)。
参看图3，控件列表和菜单项在步骤301被创建并按照优选的测试 顺序被排序。可以将排好序的列表存储在控件的序列列表123中，供 窗口处理器119使用。在步骤302，判断以前是否看到过当前的窗口。 如果看到过，则在步骤303用新的编号更新控件列表，否则，在步骤 304确定关于新窗口的信息并将其加到应用程序窗口列表116中。在步 骤305和307，按确定的顺序处理当前打开的窗口中的每个控件，直到 所有控件都被处理，此时，在步骤306判断窗口(在所有控件都已经 被处理后)是否仍然被显示。如果窗口仍然被显示，则在步骤308例 如利用WM_CLOSE(...)消息将其强行关闭。各个窗口处理例程然后退 出，然后在步骤205继续对下一个新窗口的处理。
现在再次参看图3的处理下一个控件的步骤307，并参看图4中获 得更多细节，在每个控件被处理后，窗口在步骤401再次被枚举。任 何属于目标应用程序进程104的新窗口都在步骤403、404和405(图 2的步骤204)被循环地处理。一旦完成，就在步骤405检测对新显示 的窗口的处理是否过早地终止(窗口关闭或者消失)。在这种情况下， 个别窗口处理通过适当的返回代码退出。该代码在步骤404中被检测。
应当注意的是，一旦确定某控件导致窗口过早地关闭，则最好不 要再次调用该同一个控件。这避免启动一个无限循环的可能，因为在 随后的窗口处理调用中，要测试不同的控件。
目标应用程序进程104可以因为一个命令而终止。在这种情况下， 目标应用程序进程104被重新启动。为了最大化覆盖率，避免不必要 的重复和可能的无限循环，在图1的应用程序窗口列表116中保持一 个界面覆盖率的尺度(metric)。就是说，保持一个导致目标应用程序 进程104终止的步骤的记录。如果目标应用程序进程104被重新启动， 则测试目标应用程序进程104的方法在下一个步骤继续。导致程序终 止的步骤不被重复(除非以后需要它来终止目标应用程序进程)。当 足够的代码覆盖率被检测过后，该方法终止。如果为计算机病毒复制 的目的-诸如为了获得特定计算机病毒的一些实例-而执行本发明的方 法，则该方法在这个目的实现时终止。
关于代码覆盖率的测量，可以通过任意适当的方法或外部影响确 定一个表示这个代码覆盖率的量的适当的最小值，这不必是本发明的 示教的一部分。
关于属于目标应用程序进程104的窗口的识别，图1的程序分析 器101的其中一个任务是识别新打开的窗口122哪些属于目标应用程 序进程104。这是在该方法的早期通过进程API 103确定目标应用程 序进程104的进程id以及通过比较所识别的目标应用程序进程id与 每个新打开的窗口的id而完成的。
系统显示的每个窗口122被赋予一个唯一的编号。所有其它关于 窗口的信息，包括其名称、类、和创建它的进程的id，都可以通过标 准APIs用窗口编号获得。例如，EnumWindows(...)API遍历系统中的 所有顶层窗口并可以将每个窗口的窗口编号传送给用户提供的回叫 (callback)程序。只要目标应用程序进程104的进程id是已知的，就 能很方便地确定属于目标应用程序进程104的窗口。根据目标应用程 序进程104是如何被调用的，进程id可能是已知的。例如，如果目标 应用程序进程104是通过CreateProcess(...)API调用来启动，则进 程id是已知的。
另一个用于在不知道目标应用程序进程104的进程id时确定目标 应用程序窗口122的技术是在目标应用程序进程104被启动之前和之 后调用EnumWindows(...)。这样在该方法执行的自始至终保持系统上 所有窗口的列表(系统窗口列表109)。
关于新窗口的处理，在测试一个界面对象之后出现的任一新窗口 都被通过在每个操作之前和之后枚举顶层窗口而识别。这是窗口枚举 器106的任务。
在有些情况下，新窗口可能属于另一个应用程序。例如，在有些 应用程序中激活一个帮助(Help)菜单项将导致调用窗口帮助程序。发 生这种情况时，可以采取两种行动方式。在优选实施例中，新的程序 被循环地测试。然而这可能并不切合实际，因为这对效率有相当大的 影响。在另一个实施例中，任何打开的新窗口如果不属于当前正在测 试的目标应用程序进程104，就被立即关闭。
在多数情况下，一个操作将导致一个新窗口的出现。然而，在有 些情况下，可能出现两个或更多的窗口。由于这些示教的目标是在最 大可能的程度上模拟普通用户的行动，最好以用户与新窗口交互的相 同的方式处理新窗口。为了确定用户如何选择首先操作的窗口，了解 多个窗口被典型的应用程序显示时的条件是重要的。
被应用程序显示的窗口例如可能是另一个菜单窗口(例如MDI界 面中的一个新视图(view)或相同窗口的一个新视图)、一个在继续程 序之前要求用户响应的模式对话(modal dialog)、或者一个停留在屏 幕上并且任何时候都能被使用的无模式对话(modeless dialog)，但 是允许其它用户活动。由于无模式对话框任何时候都能被使用，它们 的执行的选择顺序并不重要。
当应用程序一次显示多于一个窗口时，这经常是以下操作的结 果：应用程序试图显示一个窗口(例如模式对话框或另一个视图)； 或者窗口处理模块119检测到错误或者要求额外的信息并因此显示另 一个用来获得这个信息的窗口(如果第一窗口是个视图，则该另一个 窗口一般是消息框(message box)或模式对话框)。
在这两种情况下，新显示的窗口大多都可能互相具有父子关系， 要被首先处理的窗口是没有顶层子窗口的窗口。
例如，在以下情况中：
程序->程序的子窗口A->窗口A的子窗口B
因此，窗口B先被处理，接着是窗口A。
如果新显示的窗口互相没有父子关系，则假设它们的处理顺序无 关紧要，可以随机地或者通过试探法选择下一个要被处理的窗口。
关于各个窗口的处理，该方法保持与正在被测试的目标应用程序 进程104有关的窗口的列表(列表116)。被保持的关于每个应用程序 窗口的信息包括其编号、名称(在窗口顶部显示的名称)、类(被系 统使用的内部标识符)、包含在窗口中的界面对象的列表、窗口的状 态(打开的或是关闭的)、覆盖率信息和导致窗口关闭的界面对象。
窗口编号仅仅在窗口打开(在系统上被显示)期间是恒定的。当 窗口被关闭后再被打开时，其编号改变。这在窗口在处理结束之前关 闭然后为完成处理而被重新打开的情况中产生额外的复杂性。在这些 情况中，最好识别该窗口为部分处理过的窗口。类一名组合并非总是 唯一地识别窗口，因为窗口可能有相同类和名，而有不同外观。因为 在本例中窗口的外观和感觉很重要，所以仅当两个窗口有相同的类、 名称和控件，则认为它们是相同的。如果新打开的窗口有与应用程序 窗口列表116上现有的某窗口相同的名称、类和控件，就不把它加到 列表116中。相反，通过路径114由窗口探测器112更新列表116上 的对应窗口的编号及其每个控件。
尽管有时需要不止一次地使用非终止(non-terminal)控件，对菜 单项来说则不是这样。例如，在对话被取消(Cancel)按钮关闭之前以 及被OK按钮关闭之前，有可能需要在输入栏中设置一个值并选取一个 或多个框。然而，没有理由在每次打开窗口时重复测试相同的菜单项。 因此，不管某窗口被打开多少次，每个菜单项最好只用一次。
既避免终止(terminal)控件又避免以前用过的菜单项，在解决使 用一个界面对象导致同一个窗口有不同外观-例如出现另外的控件或 菜单项-的情况中是有好处的。这种情况表现为用具有相同的类和名 称但是不同的控件的新窗口替换老窗口。因为该新窗口具有不同的控 件，所以就本发明示教的目的而言，将其视为一个新窗口。然而，如 果对这种情况的处理不当，会导致产生无限循环：
(1)窗口1
对象1
对象2->窗口1被替换为窗口2(相同名称和类)
对象3
(2)窗口2
对象1
对象2->窗口2被替换为窗口1
对象3
(3)窗口1
对象1
对象2->窗口1被替换为窗口2
对象3
等等。
避免已经被探测过并且被确定是终止的窗口对象能解决这种情 形，因为(3)中的新窗口将被认为是部分处理过的窗口(1)，对象2 被认为是终止对象。对象2因此将不被重复。如果对象1和对象2二 者都是菜单项，则它们的任意一个都不在(3)中被重复使用。因此， 在这种情况下，步骤(3)类似于：
如果对象1、对象2和对象3是控件，则对象2被作为终止对象而 跳过：
(3)窗口1
对象1
对象3
如果对象是菜单项，则对象1和对象2二者都被跳过
(3)窗口1
对象3
关于获得窗口的界面对象的列表，要注意的是，为了模拟GUI的 用户，该方法需要获得某些关于每个窗口的外观(look)的信息。该 信息包括-但不限于-窗口名称和类、窗口菜单的出现和内容、以及控 件的类型和外观。关于菜单项的信息可以用标准APIs获得。例如，在 微软视窗TM系统中，所使用的APIs是GetMenu(...)和GetSubMenu (...)。
关于控件的信息可以用窗口的父子关系获得。这是因为在窗口系 统中，所有的控件也是窗口，某个窗口中含有的所有控件都是含有这 些控件的窗口的子窗口。因此，特定窗口的所有控件的列表可以通过 利用标准窗口APIs遍历该特定窗口的子窗口的列表而获得。
至少有两个与窗口控件有关的问题。第一个问题是对诸如编辑栏 等输入栏的值的选择。第二个问题是各个控件应当被使用的顺序。
在一个实施例中，标准对话是通过它们的名称被识别的。然而， 如果应用文字是英语以外的语言，这个方法并不可取。因此，在优选 实施例中，要确定目标应用程序进程104的语言，词库124向最佳顺 序确定单元117提供一个输入。词库124被用来确定标准对话的名称 和识别标准按钮上的文字。关于对话的类型的信息，可被用在对要被 传送到输入栏的信息的类型的确定中以及对执行顺序的确定中。
有几个标准类型的窗口控件，它们所有最好被按照本示教的方法 处理。控件的类型是由其窗口类确定的。例如，实现编辑(Edit)控件 的窗口将有一个类“Edit”(编辑)或“RichEdit”(复文本编辑)。 组合框窗口将有一个类“ComboBox”。复选框、单选按钮、按键式按 钮将有一个类“Button”(按钮)。当几个类型的控件被同一个类代 表时--如在按钮控件中的那样，则可以通过标准APIs获得更详细的信 息。
对Edit控件的值的选择是要重点考虑的，因为对Edit控件值的 不正确选择通常将检测目标应用程序进程104的一般是最简单的错误 路径。尽管一般不可能总是猜到预期的值，本方法的本实施例检查对 话的类型及其其它控件，诸如Combo框。也有可能通过分析在与输入 栏相邻的静态控件中显示的文字来“猜测”预期的值。例如，Open(打 开)对话的值应当是一个现有文件的名称。这个文件的最可能的扩展 名是该栏中当前规定的扩展名，或者是在同一个对话上显示的Combo 框栏中含有的扩展名。
本方法的本实施例处理“可设置”控件的最可能的设置，而优选 实施例测试有效的和无效的两种设置。
对话控件的处理的顺序以它们的类型为根据。例如，Combo框一 般首先被处理，接着是Edit栏，各按钮被最后处理，因为它们可能导 致对话的终止。按钮中那些最可能导致对话终止的按钮(打开、另存、 OK、取消、等等)被最后处理。可以将这个序列信息存储在控件模块 的序列的列表123中。
因为某对话可能在其所有控件被处理之前就终止，对话可能需要 被多次调用。为了避免开始一个无限循环，所有被确定是终止控件的 控件都不再被处理，直到对话被完全处理。
关于菜单项的处理，可获得的关于每个菜单或子菜单项的信息包 括其名称(打开、关闭、等等)和其命令标识符。命令标识符是一个 号码，当用户点击菜单项时，该号码能作为WM_COMMAI消息中的参数 被传送。因此，为了让本方法模拟在特定菜单项上的鼠标“点击”， 该方法向目标应用程序进程104发送一个WM_COMMAI消息，将命令id 作为参数传送。一旦所有子菜单项的列表被创建后，菜单项的测试顺 序就被确定。在优选实施例中，测试菜单项的有意义的顺序的有限列 表。在确定顺序时，最好对每个菜单项的名称及其位置都加以考虑。 与控件一样，导致程序终止的菜单项最后被执行。在一个实施例中， 首先测试第一个菜单项(最可能是New(新建))，接着是所有的窗口 控件，接着是其余的菜单项。
应当注意的是，以上讨论的各种功能都能用在图1的系统控制器 上执行的软件来实现。因此，本发明的教导也涉及一种体现在计算机 可读介质上的计算机程序。可以运行该程序来通过引导计算机开始目 标应用程序进程而自动地测试带有图形用户界面(GUI)的目标应用程 序进程；检测被目标应用程序进程的GUI打开的窗口的出现；通过确 定窗口的内容，包括在窗口中发现的用户控件的列表，处理打开的窗 口；按照计算机程序估计的顺序测试用户控件，直到所有用户控件都 被测试过；然后关闭窗口。如果测试特定用户控件导致窗口在所有用 户控件都被测试之前就关闭，则程序进一步引导计算机重新打开窗 口，然后测试除了该特定用户控件以外的用户控件，除非在所有用户 控件都被测试过后需要该特定用户控件来关闭窗口。如果测试某特定 用户控件导致第二窗口打开，则程序进一步引导计算机确定第二窗口 的内容，包括用户控件列表；测试用户控件，一直到第二窗口的所有 用户控件都已经被测试；关闭第二窗口；然后继续对第一窗口的处理。 在各个用户控件被测试过后，程序引导计算机枚举系统窗口，以确定 是否所枚举的系统窗口中由于多个新窗口被打开而变化，以确定是否 在多个新窗口之间存在父子关系，如果存在父子关系，就在处理父窗 口之前处理子窗口，然后继续对第一窗口的处理。在测试用户控件一 直到所有用户控件都被测试时，最好将可能导致终止的用户控件被识 别出来并在不太可能导致终止的用户控件之后测试。
尽管本发明的教导可以被应用于这样的系统-其中需要引出在被 怀疑隐藏有病毒的程序中的病毒活动，和/或获得被怀疑的病毒的样 本，但是本发明的教导并不仅仅限于这一个重要应用。
因此，尽管是就本发明的优选实施例对本发明作出特定表示和说 明的，本领域的熟练人员应当明白，在不偏离本发明的精神和范围的 情况下可以对本发明的形式和细节作出改变。