CN101930399A

CN101930399A - 一种对软件测试进行记录的方法

Info

Publication number: CN101930399A
Application number: CN 201010253935
Authority: CN
Inventors: 于秀山; 于长钺
Original assignee: Individual
Current assignee: Individual
Priority date: 2010-08-16
Filing date: 2010-08-16
Publication date: 2010-12-29

Abstract

本发明公开了一种对软件测试进行记录的方法，所述方法包括以下步骤：在执行测试用例时，通过钩子技术捕获操作被测软件时产生的鼠标消息和被测软件的反馈信息，获得测试流程信息，并记录下来；软件测试结束后，根据记录的测试流程信息，生成测试记录文档。本发明通过钩子技术记录测试过程，在测试软件的同时生成测试记录等文档，大大节省测试时间；同时，实时地记录测试过程中的每一步操作，不会造成遗漏，生成的测试文档准确规范。

Description

一种对软件测试进行记录的方法

技术领域

本发明涉及软件测试技术领域，特别是涉及一种对软件测试进行记录的方法。

背景技术

软件测试是保证软件质量的主要方法之一，而在软件测试过程中，一项重要的工作是编写各种测试文档，其中最重要的文档包括测试记录文档和软件问题报告。详细、准确的测试记录和软件问题报告可以规范测试工作的整个流程，可以减少测试人员之间、以及测试人员和开发人员间的沟通成本，并使得测试工作易于检查，便于进行测试总结。

目前测试文档的生成都是通过全手工或半手工的方式完成。全手工记录的方式就是由测试人员在测试过程中一边测试一边手工编写测试文档，或者是测试人员在测试结束之后凭借记忆编写测试文档，或者是测试人员在测试之前先编写好测试说明文档；半手工记录的方式就是测试人员借助一些软件来完成测试文档。一些工具(如Mercury Interactive TestDirector、BugZilla等测试过程管理工具)能完成测试文档的半自动化生成，即测试人员只需输入文档的内容(如测试步骤、软件操作实际结果等)，工具会自动生成规定格式的文档。而如Winrunner、QTP等工具也能对测试过程进行记录，但这些工具主要的功能是测试过程的录制/回放，其录制的脚本是为回放而设计的，脚本信息对测试人员来说可读性差，无法从中提取测试记录文档所要求的内容。

不论是全手工方式还是半手工方式，都具有以下缺点：1、耗费大量时间。无论那种方式，都需要测试人员手工输入测试步骤、测试输入等信息。即使是半手工的方式，文档的主要内容还是需要测试人员手工输入，这需要大量的时间；2、无法保证文档的准确性。由于文档内容由测试人员编写，其准确性由测试人员的细心程度、认真程度和文字表达能力决定；3、影响测试过程的连续性。为保证文档内容的准确性，测试人员需要中断测试来记录测试步骤和发现的问题。

因此，开发一种不需要或者尽量少人工介入的测试文档自动生成工具，有着非常现实的意义，不但可以大大降低测试文档的编写时间和人工花费，而且可以改进测试文档和测试活动的质量。GUI软件是常见、重要的一类软件，其图形化的人机交互界面为获取软件操作流程提供了途径。

发明内容

本发明提供一种对GUI软件测试过程进行记录的方法，用以解决现有技术中存在测试记录工作量大、记录不准确的问题。

为达上述目的，本发明提供一种对软件测试过程进行记录的方法，所述方法包括以下步骤：

在执行测试用例时，通过钩子技术捕获操作被测软件时产生的鼠标消息和被测软件的反馈信息，获得测试流程信息，并记录下来；

软件测试结束后，根据记录的所述测试流程信息，生成测试记录文档。

进一步，在执行测试用例时，当测试出被测软件出现错误，暂停记录所述测试流程信息，对出现的问题进行手工记录；手工记录完毕之后，继续记录下一步操作所产生的测试流程信息。

进一步，在执行测试用例时，如果发现被操作控件为无法识别的非标准控件，则暂停记录测试流程信息，对与该控件相关的操作步骤进行手工记录；手工记录完毕之后，继续记录下一步操作所产生的测试流程信息。

进一步，所述方法还包括对软件控件进行识别的步骤，该步骤具体包括：

监听到鼠标消息后，获取当前光标位置的控件句柄，然后获取控件类名字符串；

根据控件类名与控件类名字符串的对应关系，获取控件类名。

进一步，所述软件控件包括即点控件和后处理控件两类；

所述即点控件，是指在监听到对该控件的鼠标操作后即进行处理，处理一次完成；

所述后处理控件，是指在监听到对该控件的鼠标操作后先进行预处理，记录下该控件的句柄、类名、父窗口属性，在进行下一个鼠标操作处理前再完成对该控件的处理。

进一步，所述即点控件包括：菜单、按钮、工具条、标签页、标签控件。

进一步，所述后处理控件包括：下拉列表框、列表框、文本框、IP地址输入框控件。

进一步，在对软件测试之前，还包括以下步骤：配置测试项目。

进一步，配置测试项目，具体包括：配置测试项目信息、测试人员信息及测试项目的组织信息。

进一步，测试项目的组织信息包括测试项目的构成、每个子项目的测试类型以及每个测试类型的具体测试用例。

本发明有益效果如下：

本发明通过钩子技术记录测试过程，在测试软件的同时生成测试记录等文档，大大节省测试时间；同时，实时地记录测试过程中的每一步操作，不会造成遗漏，生成的测试文档准确规范。

附图说明

图1是本发明实施例一种对软件测试进行记录的方法的流程图；

图2是本发明实施例测试过程中记录测试过程的流程图；

图3是本发明实施例菜单控件处理流程图；

图4是本发明实施例获取分组控件内的控件句柄的流程图；

图5是本发明实施例获取工具条按钮内容的流程图；

图6是本发明实施例获取列表视图控件被选项内容的流程图；

图7是本发明实施例获取树型视图控件被选项内容的流程图；

图8是本发明实施例识别窗口打开或关闭的流程图。

具体实施方式

以下结合附图以及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。

本发明实施例涉及一种对软件测试进行记录的方法，尤其是面向GUI(Graphical User Interface，图形用户界面)软件的测试项目管理和测试文档自动生成。对测试项目进行配置管理后，在后台对测试过程进行监控、记录，记录详细的测试过程信息，测试结束后，测试记录文档和软件问题报告的内容也已具备，可自动生成相应文档。

如图1所示，本发明实施例涉及一种对软件测试进行记录的方法，该方法包括三个步骤：配置测试项目、记录测试过程和文档生成。其中，配置测试项目可以在对软件测试之前完成，也可以在软件测试完成之后进行，也可以不进行配置。

步骤一：配置测试项目

一个新的测试项目开始时，先进行测试项目的配置，主要内容包括配置测试项目信息、测试人员信息及测试项目的组织信息。测试项目信息包括被测软件的名称、编号、测试时间等信息；测试人员信息包括测试人员的姓名、职位等信息；测试项目的组织信息包括测试项目的构成(新建项目及其多级子项目)、每个子项目的测试类型(功能测试、性能测试、边界测试等)以及每个测试类型的具体测试用例(用例名称及标识等)。

步骤二：记录测试过程

测试项目配置完成后，在测试人员进行测试操作的同时，对测试过程进行记录，获取需要的软件信息，并记录下操作流程。在测试人员执行测试用例(对被测软件进行测试)时，通过钩子技术捕获操作被测软件时产生的鼠标消息和被测软件的反馈信息，通过处理获得测试流程信息(操作步骤和执行结果)；其中，鼠标消息是指鼠标操作、以及鼠标操作的对象。例如：鼠标操作为单击，鼠标操作的对象为打印按钮。软件的反馈信息是指，软件针对鼠标操作所作出的反应。例如，软件针对鼠标点击打印按钮的鼠标事件，作出弹出打印对话框的反应。

对于基于GUI的软件，测试人员在进行功能测试时主要与图形用户界面交互。一个个单独的控件是GUI软件界面的组成元素，控件功能的组合则构成了软件的功能。要实现对测试过程的记录，首先要捕获测试中操作的控件信息。

测试人员操作软件，就是通过鼠标、键盘与软件交互。利用钩子(hook)技术我们可以捕获Windows操作系统的鼠标、键盘消息，这些消息中包括了操作类型(键盘输入、鼠标单击、鼠标双击等)、控件种类(按钮、列表框、菜单等)、控件内容、控件所属窗口等。这些信息是描述测试过程的基本组成元素。这些工作的完成都依赖Windows API函数。

钩子(Hook)，是Windows消息处理机制的一个平台，应用程序可以在上面设置子程以监视指定窗口的某种消息，而且所监视的窗口可以是其他进程所创建的。当消息到达后，在目标窗口处理函数之前处理它。钩子机制允许应用程序截获处理Windows消息或特定事件。钩子实际上是一个处理消息的程序段，通过系统调用，把它挂入系统。每当特定的消息发出，在没有到达目的窗口前，钩子程序就先捕获该消息，亦即钩子函数先得到控制权。这时钩子函数即可以加工处理(改变)该消息，也可以不作处理而继续传递该消息，还可以强制结束消息的传递。钩子也可以理解为Windows留给我们的后门，比如你想控制键盘，在DOS时代很简单通过INT即可，而Windows时代不允许我们直接操作硬件；由于Windows是消息驱动，所以我们可以拦截键盘消息以达到控制键盘的目的。但是控制自己进程的消息固然很简单，要控制所有进程消息就要利用钩子了。将钩子函数放在DLL中，所有的有关键盘的消息都必须经过钩子函数过滤。Windows下的钩子程序就像DOS下的TSR(内存驻留程序)一样，用来截获Windows下的特定的消息，进行相应的处理。比如可以截获键盘输入的消息，来获得键盘输入的信息等。钩子程序可以通过API调用来驻留和脱钩。

在获取了上述基本信息后，进一步捕获控件状态变化、控件所属窗口状态变化等场景信息，并结合记录的测试场景上下文信息，就可以得到测试流程的规范化描述。如点击一个按钮Button1弹出一个窗口Window1。对于这个操作，我们可以得到测试步骤：点击(操作类型)按钮(控件种类)Button1(控件名称)。根据场景上下文信息分析(当前窗口发生变化)还可以得出软件反馈(即操作产生的结果)：打开新窗口Window1。

下面结合图2，详细描述软件测试过程中进行测试记录的步骤。

在对软件测试之前，先运行鼠标钩子；运行鼠标钩子之后，则会对鼠标的任何操作进行记录。在每次录制开始的时候，安装钩子。SetWindowsHookEx(int idHook，HookProc MouseHookProc，IntPtr hInstance，int threadId)函数将钩子加入到钩子链表中，idHook＝14表示全局钩子监听系统鼠标消息，在钩子子程MouseHookProc中具体处理监听到的鼠标消息(鼠标点击事件)。在每次录制任务结束时卸载钩子。

然后对软件进行测试(执行测试用例)，在软件测试过程中，钩子线程一直处于监听状态，在捕获下一个鼠标消息前先判断软件是否出错，如果出错，测试人员也可暂停记录，输入错误描述信息，如果需要截取屏幕信息，可通过截屏按钮自动截取描述错误信息的报错框并保存，屏幕截图与错误描述信息一起写入测试过程记录文本中。

如果测试软件没有出错，则进一步判断鼠标事件是否发生；如果没有发生，则返回监听状态；如果发生了鼠标操作，则获取控件信息及当前场景。然后判断控件是否为标准控件，即判断控件是否能够被识别。测试过程中如果遇到无法识别的非标准控件，会弹出提示，测试人员可以暂停记录，手工输入相关的测试描述，以保证测试记录的准确性。手工输入完成之后再继续记录。对于能够识别的控件，针对不同控件，进行不同的处理(下面有消息描述，暂不详述)，

对于控件的识别，通过以下步骤：鼠标钩子监听到鼠标点击消息后，调用API函数WindowFromPoint()获取当前光标位置的控件句柄，然后调用GetClassName()获取控件类名字符串，根据控件类名与控件类名字符串的对应关系，获取控件类名。表1为控件类名与控件类名字符串的对应关系表。

表1

序号	类名中主要字符串	控件种类
			1	#32768	菜单(Menu)
2	#32770	对话框(Dialog)
			3	Combolbox	下拉列表框(CombLBox)
4	Listbox	列表框(Listbox)

5	Button、Btn	按钮(Button)
			6	Edit、Textbox	文本框(Edit)
7	Toolbar	工具条(Toolbar)
			8	Listview	列表视图(Listview)
9	Tabcontrol、Tpagecontrol	标签页(Tabcontrol)
			10	Treeview	树型视图(Treeview)
11	Static、Forminput	标签(Label)
			12	IPAddress	IP地址输入框
13	Panel	分组框(Panel)

根据对控件的处理方式，将控件分为即点控件和后处理控件两类。对于即点控件，在监听到对该控件的鼠标事件(点击按钮、点击菜单等)后即进行处理，处理一次完成，这一类控件包括：菜单(Menu)、按钮(Button)、工具条(Toolbar)、标签页(Tabcontrol)、标签(Label)等；对于后处理控件，在监听到对该控件的鼠标事件后先进行预处理，记录下该控件的句柄、类名、父窗口等属性，在进行下一个鼠标事件处理前再完成对该控件的处理——读取其文本值/选项值，这一类控件包括：下拉列表框(CombLBox)、列表框(Listbox)、文本框(Edit)、IP地址输入框等。

引入后处理控件的概念后，我们不关心用户对这类控件操作的中间状态(输入、删除、粘贴、选择等)，而只需获得最终的状态(最后输入的文本内容、最后确定的选择项等)，从而使得通过鼠标钩子即可以获取用户键盘输入。

无论是对标准控件还是非标准控件，都将其描述记录写入测试过程记录文本中。然后判断录制(对测试过程的记录)是否结束，如果结束，生成测试过程记录文件。如果没有结束，则进一步判断当前记录是否为暂停状态，如果是，则继续录制，钩子线程回到监听状态；如果否，则直接返回监听状态。

下面详细描述针对各种控件的记录步骤：

1、菜单控件(Menu)处理

菜单控件分为两类：标准菜单和右键快捷菜单。当系统判断当前捕获的控件为菜单时，根据当前鼠标事件的消息类型判断是否为右键单击，从而判断当前的菜单控件是右键快捷菜单还是标准菜单。对两类菜单处理的不同主要是标准菜单多了获取第一级菜单文字的步骤。如图3所示，菜单控件的处理包括以下步骤：

首先获取当前控件类名、句柄等；然后根据钩子子程的wParam参数判断当前操作是否是右键单击，如果否，则获取第一级菜单句柄、获取第一级菜单索引，根据第一级菜单索引与菜单文字的对应关系，获取第一级菜单文字；然后进一步获取子菜单句柄、子菜单索引，根据子菜单索引与子菜单文字的对应关系，获取子菜单文字；如果当前操作是右键单击，则直接获取子菜单句柄、子菜单索引，根据子菜单索引与子菜单文字的对应关系，获取子菜单文字；将上述步骤得到的结果写入测试过程记录文本中。

2、按钮控件(Button)处理

按钮控件分为三类：普通按钮(Button)、单选按钮(RadioButton)(互斥，必须选一个或者不选)、复选按钮(CheckBox)(多选，可选可不选)。当捕获到按钮相关事件后，调用GetWindowLong(wHdl，GWL_STYLE)获得按钮风格属性，根据风格属性判断按钮所属类型。

如果是普通按钮，直接调用SendMessage(wHdl，WM_GETTEXT，...)获得按钮文本，然后根据当前鼠标操作将此次操作规范化描述为：(右键)点击按钮“xxx”。

如果是单选按钮，调用SendMessage(wHdl，WM_GETTEXT，...)获得按钮文本，然后调用SendMessage(wHdl，BM_GETCHECK，...)获得按钮状态，根据这些信息将此次操作规范化描述为：选定单选按钮“xxx”，或者单选按钮“xxx”状态为不可选，或者右键单击单选按钮“xxx”。

如果是复选按钮，调用SendMessage(wHdl，WM_GETTEXT，...)获得按钮文本，然后调用SendMessage(wHdl，BM_GETCHECK，...)获得按钮状态，根据这些信息将此次操作规范化描述为：选定复选按钮“xxx”，或者取消选定复选按钮“xxx”，或者复选按钮“xxx”状态为不可选，或者右键单击复选按钮“xxx”。

3、分组控件(Groupbox、Panel)处理

在很多程序中，为了有条理地组织窗口中的控件，会将相关的控件放到一个分组控件中，如果使用鼠标钩子直接获取位于分组控件中的控件，得到的信息(句柄、类名)都是分组控件的，因此碰到此类控件时，需要做的是“穿过”分组控件获得目标控件的句柄，从而得到目标控件的信息。

在钩子子程的开始，获取控件句柄、当前光标位置等信息后，紧接着就判断目标控件是否位于分组控件中。根据前面已得到的句柄调用GetWindowLong(wHdl，GWL_STYLE)得到相应的控件风格，用于判断是否是GroupBox，或者根据类名判断是否是Panel。如果是分组控件，则表示目标控件位于分组控件中，则通过下面的递归过程获取目标控件的句柄。如图4所示，具体步骤如下：

首先获取分组控件句柄wHdl、光标位置等，然后调用GetWindow(wHdl，GW_HWNDNEXT)获取Z序中下一个窗口句柄H，wHdl＝H；调用GetWindowRect(H，...)，获取新获取窗口的矩形；判断当前光标是否在该矩形内，如果是，H即为目标控件句柄；如果否，则调用GetWindow(wHdl，GW_HWNDNEXT)获取Z序中下一个窗口句柄H，wHdl＝H。

5、工具条控件(Toolbar)的处理

工具条控件的处理步骤如图5所示，包括以下步骤：

首先，获取工具栏按钮的提示的句柄tipHdl；然后判断Tiphdl是否等于0，其中，0为初始值。如果是，则将当前坐标写入目标进程的内存空间，向其发送TB_HITTEST消息，获取按钮的索引；然后根据按钮索引获取其info属性，发送消息TB_GETBUTTONTEXTW获取按钮文本字符数；最后从目标进程空间读出该控件的文本，写入测试过程记录文本中。如果Tiphdl不等于0，则发送WM_GETTEXT消息获取提示文本；再进一步判断当前光标是否处于屏幕底部，如果是，则当前控件为操作系统任务栏，如果否，则当前控件为被测程序工具栏；最后将得到的结果写入测试过程记录文本中。

6、列表视图控件(Listview)的处理

列表视图控件的处理步骤如图6所示，包括以下步骤：

首先，获取被测软件进程的ID，在该进程中开辟一块内存空间，控件相关信息存储在LVITEM结构中；其次，向控件发送LVM_GETNEXTITEM消息，获取当前被选项的索引，再次，向控件发送LVM_GETITEMTEXT消息，获取被选项内容字符数，最后，从目标进程空间读出被选项的文本，记录对该控件操作语句。

7、树型视图控件(Treeview)的处理

树型视图控件的处理步骤如图7所示，包括以下步骤：

首先，获取被测软件进程的ID，在该进程中开辟一块内存空间，控件相关信息存储在TVITEM结构中；其次，向控件发送TVM_GETNEXTITEM消息，获取当前被选项的索引，再次，向控件发送TVM_GETITEMTEXT消息，获取被选项内容字符数；最后，从目标进程空间读出被选项的文本记录对该控件操作语句。

8、窗口打开和关闭

根据最前端窗口及其父窗口，以及前一次的最前端窗口及其父窗口的关系可以识别窗口打开和关闭事件。具体步骤如图8所示：

首先，初始化上一次最前端窗口句柄PreFHdl＝0，初始化上一次最前端窗口父窗口句柄PreParHdl＝0；每次进行鼠标消息处理时先调用GetForegroundWindow()获取最前端窗口句柄FHdl，调用GetParent()获得其父窗口句柄ParHdl；然后，判断是否FHdl＝PreFHdl，如果是，则PreFHdl＝FHdl，PreParHdl＝ParHdl；如果否，则进一步判断是否FHdl＝PreParHdl，如果是，则当前操作为关闭当前窗口，如果否，则当前操作为打开新窗口，更新PreFHdl和PreParHdl，令PreFHdl＝FHdl，PreParHdl＝ParHdl；最后判断是否录制结束，如果是，则结束，如果否，则进入下一次窗口切换的判断处理。

9、控件与对应标签的匹配

测试记录中要描述操作的步骤就需要知道该控件的名字，对于像按钮之类的控件，直接取控件文本就是它的名字了，但是如下拉列表框、文本框等控件，在界面中是使用一个标签(Label)来给其命名的。在实现中使用逐点搜索法来搜索控件对应的标签。搜索区域包括三个，依次为：控件的左侧区域、控件的左上方区域、控件的上方区域。即依次在这三个区域取点，根据该点坐标调用WindowFromPoint()，如果该点存在控件且为Label，即为目标控件的对应标签，调用SendMessage(hwnd，WM_GETTEXT，...)得到标签的文本即为目标控件的名字。

10、写文件操作

使用StreamWriter类完成写文件操作。每次录制开始(或暂停后恢复录制)时新建一个StreamWriter实例，录制时每次将标准化的操作描述语句写入指定文件末尾。录制结束(或暂停)时关闭该实例。

11、软件错误记录

当测试中发现错误时，可暂停录制(卸载钩子)进入“问题描述”窗口对发现的软件错误进行描述，内容包括：问题类型、问题等级、改进类型、问题描述。如需要保存当前窗口以便更清楚描述问题，可使用“截图”按钮，按下鼠标左键并拖动选取要截取的屏幕区域并双击，截图便被保存在录制文本文件目录下的Image文件夹(如不存在则新建)中，一次问题描述过程中共可截取20张图片。操作完成后点击“确定”按钮使用StreamWriter类将错误描述信息写入文件。

错误信息录入完成后可继续录制(重新安装钩子)。

12、非标准控件的处理

测试中有时会碰到不能识别的非标准控件(如用户自己定制的控件)，遇到这类控件时，使控件矩形闪烁以提醒测试人员。此时，测试人员可选择忽略此控件继续录制，也可选择暂停录制，手动添加对此控件的操作。如选择后者，则在暂停(卸载钩子)后进入手动添加操作步骤窗口。进入该窗口时，使用FileStream类和StreamReader类将已录制内容从文件中读取到窗口的文本框中，测试人员可对录制文本进行编辑(添加操作步骤或修改已录制的内容)，编辑完成后点击“确定”按钮使用StreamWriter类将编辑后的文本重新写入录制记录文件，并覆盖原内容。

手动添加操作步骤完成后可继续录制(重新安装钩子)。

控件闪烁效果实现如下：调用ControlPaint.DrawReversibleFrame()函数在控件周围画个矩形框，共画4次，每两次中间调用语句Thread.Sleep(100)(即闪烁间隔时间为100ms)。

步骤三：测试文档自动生成

测试结束后，根据记录的鼠标消息和响应消息，生成测试记录文档。即：根据在步骤一填写的项目信息(项目名称、测试种类、测试人员等)和步骤二获得的测试过程记录文本(测试用例操作步骤、操作结果、软件问题信息等)，可自动生成规定格式的测试文档。

文档自动生成模块通过数据处理接口将数据处理后，添加相应的标记，然后保存在项目里的测试文件中，这些测试文件包括测试记录、测试说明、测试追踪和问题报告。测试文件中加入标记的作用是标识出记录对象、记录内容、格式、问题与用例的对应关系等。表2列出了常见标记的具体含义：

表2录制文件中的标记及对应含义

标记	含义	标记	含义
				#--#	弹出或者关闭窗口	#！！#	输入内容
#PH#	自动捕获的图片	#Defect#	问题记录
				#@@#	问题记录	&&！！	并列与分隔

测试项目已完成所有测试文档录制工作以后，对一个测试项目可以进行文档的生成，用户在人机界面中选择生成测试文档类型，通过使用文档生成管理内核调用测试文档接口来生成文档。

第一步，程序先创建一个Java-COM Bridge，通过JNI操作并生成一个ActiveX Component文档对象，这个对象即代表了一个已打开了的Word文档对象，获取其Document对象，以备操作。

第二步，读取程序的配置文件，确定文档所需的封面，并将这些封面内容加入到当前Word对象中，根据当前项目的具体信息，将日期和具体的人员信息填写到封面中对应的位置。

第三步，利用文档业务类对当前项目中的每一个文件的内容进行分析，首先剔除空文档，然后启动一个单独的Thread循环对单个的文档进行分析并将其内容加入到当前Word对象中，直到所有的所需要内容已添加在相应的文档位置中，处理完文档结尾数据后，线程结束，人机界面上的文档生成进度条消失，文档自动添加到项目中并显示在项目结点的下方，文档生成完毕，双击项目树中的Word文档节点，即可以打开相应的word应用程序，查看word文档内容。

由上述实施例可以看出，本发明通过钩子技术记录测试过程，在测试软件的同时生成测试记录，大大节省测试记录时间；同时，实时地记录测试过程中的每一步操作，不会造成遗漏，生成的测试文档准确规范。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种对软件测试进行记录的方法，其特征在于，所述方法包括以下步骤：

软件测试结束后，根据记录的测试流程信息，生成测试记录文档。

2.如权利要求1所述对软件测试进行记录的方法，其特征在于，在执行测试用例时，当测试出被测软件出现错误，暂停记录所述测试流程信息，对出现的问题进行手工记录；手工记录完毕之后，继续记录下一步操作所产生的测试流程信息。

3.如权利要求1所述对软件测试进行记录的方法，其特征在于，在执行测试用例时，如果发现被操作控件为无法识别的非标准控件，则暂停记录测试流程信息，对与该控件相关的操作步骤进行手工记录；手工记录完毕之后，继续记录下一步操作所产生的测试流程信息。

4.如权利要求1所述对软件测试进行记录的方法，其特征在于，所述方法还包括对软件控件进行识别的步骤，该步骤具体包括：

5.如权利要求1所述对软件测试进行记录的方法，其特征在于，所述软件控件包括即点控件和后处理控件两类；

6.如权利要求5所述对软件测试进行记录的方法，其特征在于，所述即点控件包括：菜单、按钮、工具条、标签页、标签控件。

7.如权利要求5所述对软件测试进行记录的方法，其特征在于，所述后处理控件包括：下拉列表框、列表框、文本框、IP地址输入框控件。

8.如权利要求1所述对软件测试进行记录的方法，其特征在于，在对软件测试之前，还包括以下步骤：

配置测试项目。

9.如权利要求8所述对软件测试进行记录的方法，其特征在于，配置测试项目，具体包括：配置测试项目信息、测试人员信息及测试项目的组织信息。

10.如权利要求9所述对软件测试进行记录的方法，其特征在于，测试项目的组织信息包括测试项目的构成、每个子项目的测试类型以及每个测试类型的具体测试用例。