一种软件运行监测与故障识别方法

袁博文,张 威,皇甫睿帅,袁 聪

(1.陆军装甲兵学院 信息通信系，北京 100072；2.湖南省军区 数据信息室，长沙 410000；3.中国人民解放军95852部队，海南 东方 572600)

软件系统在社会各个领域的作用日益重要，人们对软件系统的要求也日益增高，软件质量首当其冲。尽管存在代码审查、形式化验证等辅助手段，但软件测试依然是目前最主要的软件质量保障手段[1]。而软件测试方法与测试数据是软件测试过程中重要组成部分。为了提高测试工作效率，选择合适的方法显得十分重要。单锦辉等[2]提出一种由故障检测、故障定位、故障排除、交付等组成的集成化的软件故障诊断过程框架。同时，将智能算法运用到测试用例自动生成上已经有了一些研究。刘龙霞等[3-4]将分类树，贪心算法，遗传-蚁群混合算法等运用到了测试数据自动生成中。

Windows Hook (即Windows钩子)是Win32系统中用于监视、截获或重定向发往目标窗口消息的特殊接口[5]，该接口常常用于软件录制回放。Windows 系统的异常处理机制除了能够帮助软件开发人员发现和解决软件中的错误外，被广泛应用于软件保护技术、软件漏洞利用等方面[6]。在经过用户同意的前提条件下，利用Hook接口记录用户软件应用数据，同时利用Windows系统结构化异常处理机制对软件进行故障识别。并且生成相对应的测试用例以实现相应的故障重现。有针对性的测试用例能为软件发布后期测试与维护提供有效的帮助，降低测试成本。所以，对于软件运行过程中应用数据的监测处理研究具有相当重要的现实意义。

1 软件运行监测框架

1.1 总体框架设计

本系统主要分为两个功能模块实现：用户操作监测模块；软件故障识别模块。系统功能框图如图1所示。用户操作监测模块和软件故障识别模块分别监测用户操作和待测软件状态，并将结果和软件故障时错误报告一起记录下来。根据记录的结果生成测试用例。

图1 系统功能框图

1.2 用户操作监测模块

该模块主要功能为记录用户对被监测软件的操作。软件测试人员在对软件进行黑盒测试时，往往采用大量测试用例对软件进行测试，以达到更高的测试覆盖率，因此测试用例的设计成为了提高测试效率关键点。Windows本身是事件驱动的，而消息就是为了描述事件特征而产生的格式化信息。消息产生后被追加到消息队列中，并被分发到对应的应用程序窗口进行处理。如果能将在应用程序窗口处理消息之前，先截获有用的消息，从中取出需要的数据，便能实现对待测软件进行用户操作监测。同时，为了不影响待测软件的自身正常运行，将需要的数据从消息取出后，应将消息完整的传递给原目标窗口。

基于本模块需求，选择利用Windows系统提供Hook消息处理机制实现。Hook根据处理消息分为许多种类，同时又分为全局与局部。全局 Hook可以监视系统范围的消息，而局部 Hook只能监视本程序的消息。本模块在实现过程中用到的Hook包括WH_CALLWNDPROC、WH_KEYBOARD、WH_MSGFILTER，其类型与作用如表1所示。

本模块预先将钩子程序封装在动态链接库文件中，并预留待测软件进程号接口。为实现目标软件监测，本模块设计在进行监测之前提供系统运行所有进程名与其对应的进程号于列表框中，用于监测软件的选定。当选择需要监测的软件之后，本模块调用钩子函数，将钩子注入到目标软件中。由于用户对于软件有效操作主要包括菜单操作，对话框操作，字符串输入操作等，结合Hook机制特点，本模块识别并记录的信息有：被点击菜单名(包括多级菜单)；菜单项关闭；对话框中被点击的按键名；对话框中文本框内容变化；对话框中文本输入。

表1 用户操作监测模块使用的Hook

将用户操作依次按照上述方式记录，生成用户操作序列。因此用户操作的再实现将变得十分简单，也为软件后期测试与升级提供了测试用例的来源。本模块流程框图如图2。

图2 用户操作监测模块流程框图

1.3 软件故障识别模块

该模块主要功能为识别待监测软件故障。本模块是基于Windows系统结构化异常处理机制(Structure Exception Handler,SEH)。当异常发生时，软件会向系统抛出异常，请求系统对异常进行处理。而Windows系统允许嵌套式异常处理机制的存在，即当异常发生时，操作系统的异常分发函数在进行处理后，如果异常没有被处理就会遍历异常处理链，直到异常被处理，如果仍没有注册函数处理异常，则将异常交缺省处理函数或者直接结束产生异常的进程[6]。基于此，本模块设计一个异常处理函数与钩子程序一起封装成动态链接库。当待监测软件发生异常时会调用异常处理函数，而此时堆栈中为 EXCEPTION_REGISTRATION结构体将会保存本次异常的错误信息。本模块通过记录错误信息实现故障的识别，错误信息中部分异常代码含义如表2所示。

表2 错误信息中部分异常代码含义

同时Windows系统自身会将软件异常信息记录并发送到微软公司服务器，但系统用户只能通过错误报告窗口查看部分错误信息。为了能更加深入的了解故障信息，更好的帮助解决错误，通过自编软件记录显然是更好的选择。设计一个简单程序窗口，该窗口能通过用户输入一元二次方程等式，自动计算出等式解。当该软件发生故障时，可通过错误报告窗口查看相关错误信息，如图3所示。

图3 软件问题报告窗口

2 软件应用数据记录与故障识别

2.1 软件应用数据记录

当用户运行目标程序的同时运行监测程序，即可开始实现软件应用数据的提取。具体步骤如下：

步骤1：监测软件开始运行，选择需要监测的进程名或者进程号；

步骤2：创建记录文件；

步骤3：将钩子程序与异常处理程序挂入系统，监测目标软件；

步骤4：当目标软件正常运行时记录目标软件操作信息，当目标软件发生异常时记录异常信息；

步骤5：重复步骤4，直到目标进程终止；

步骤6：重复步骤1，直到监测软件关闭。监测程序流程框图如图4。

图4 监测程序流程框图

2.2 软件故障识别

软件运行过程中的数据与不正常停止后产生的错误报告对于软件后期维护与升级具有重要的作用。在Windows系统的运行过程中，某个程序出现非法操作或错误提示是每个用户都会遇到的情况。而此时，Windows会启动错误报告机制(Windows Error Reporting，简称WER)，询问用户是否发送错误信息到微软公司，同时程序将停止运行。

当程序出现非法操作或者错误提示时，程序会向系统抛出异常消息。监测系统通过捕获软件抛出的异常消息，判定软件出现异常。而后监控系统会调用EXCEPTION_RECORD结构中ExceptionInformation成员进行二次识别。由于Windows错误报告机制为当错误发生之后会立即产生许多有效的数据报告并将报告上传至后台服务器，而后将大部分数据报告删除，所以为了获得尽量多的数据，当系统发生故障时，应尽快将错误报告备份。基于此，当识别出目标软件发生故障之后，监测系统应立即软件错误报告中的信息提取备份，作为后期分析数据。

用户在对平台进行操作时会产生大量操作数据，而与被监测软件相关的操作往往都是在同一窗口下的。软件测试人员在获取测试数据后，结合错误报告与操作记录，经过数次反向实验便能确定用户操作中的有效部分，进而生成能够重现相应软件故障的测试用例。

3 实例与对比分析

3.1 实验软件与监测软件介绍

本文中提出一种基于用户应用数据记录与分析的错误还原方法，主要是利用用户应用数据，实现错误再还原。设计一个具有代表性的待测试软件，软件窗口页面如图5(a)所示。该软件拥有基本菜单功能，在此基础上增加“对话框”菜单项。点击“对话框”项后出现图5(b)页面。其中图5(b)的功能：

图5 待测软件窗口

1)在“Number1”与“Number2”中分别输入两个数，点击“divide”键后，“Number3”出现两数相除的结果。此功能设计时应考虑除数不能为“0”，在计算结果之前应先判定除数是否为“0”。此处不做判断，检验监测软件监测结果；

2)“error”键：此处设计另一个错误，点击“error”键后，软件会对空指针赋值；

3)“Cancel”键：关闭此对话框；

4)“收缩/扩展”键：关闭/打开对话框下方展示部分。

监测软件窗口页面如图6所示。其图中各部分功能：

1)目标软件选择框：此框为下拉选择框，监测软件运行之后先访问系统，将系统中所有的进程列至框内，供选择；

2)“确定”键：选定目标进程后，点击该键，监测软件对指定进程进行监测；

3)“完成”键：监测工作完成，关闭软件；

4)“取消”键：取消监测，关闭软件。

图6 监测软件窗口

3.2 实验结果

先运行待监测软件，而后在监测软件上对目标进程注入消息钩子，开始记录实验数据。得到的操作记录如图7所示。

图7 操作记录

由实验记录的数据可知，目标软件产生了大量操作，包括文件新建，文件打开，以及“对话”菜单生成对话框中相关功能。其中，操作过程中产生了两个错误，相关错误代码为“C0000094”，“C0000005”。通过查询微软公司发布的Microsoft Docs开发技术文档可知，相关代码含义分别为“线程试图将整数值除以零的整数除数”，“该线程试图读取或写入其没有适当访问权限的虚拟地址”。结果与实验设计相吻合，生成相关的测试用例如表3所示。

3.3 对比分析

目前有很多自动化回归测试工具，例如QTP、WinRunner、QARun、VisualTest等。这类工具一般采用捕获/回放的模式，记录用户操作的流程，保存下来作为备选测试用例，通过应用程序对流程脚本的自动执行来验证被测系统的响应是否正确。以Quick Test Professional(简称QTP)为例，Micro Focus公司的QTP工具是一种自动测试工具，用于执行重复的自动化测试。通过自动录制、检测和回放用户的应用操作，QTP工具能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试。

为了更加详尽的对比QTP与监测软件，设计QTP软件对上述待测软件进行监测，并且对待测软件进行与第3.2节中相同操作，得到QTP记录的实验监测结果如图8所示。

表3 软件“divide”功能测试用例

图8 QTP实验监测结果

根据对比可以发现，QTP软件能够较为详细的记录目标软件操作过程并且生成相应的测试用例。而本文中设计的监测软件同样能够详细的记录并生成测试用例，除此之外，监测软件会记录下待测软件不正常终止情况，并识别出相应的故障类型。显然，运用本方法对待测软件进行监测与故障识别更加有助于软件测试工作的进行。本文设计的监测软件与QTP的测试情况如表4所示。

相对已有的测试工具，本文中提出的监测软件仍然存在一定不足。其中包括：软件测试用例的生成尚未实现自动化与精简，最简化的测试用例仍需要依靠测试人员根本软件报告多次测试生成；软件错误定位还不够精细，只能通过错误代码与操作记录综合分析确定大概位置。

表4 监测软件与QTP的测试情况

4 结论

本文提出一种软件运行监测与故障识别方法，通过监测程序监视用户的操作和程序状态，结合Windows错误报告和监测记录对软件动态故障进行识别和测试用例生成。通过实例证明，当程序出现故障时，合理借用Windows系统错误报告机制能够有效地对软件故障进行识别，并且结合用户操作记录，生成了能够让软件故障重现的测试用例，为软件发布之后的维护与升级提供了巨大帮助。

软件运行过程中的数据报告除了可以用于故障识别之外，还可以用于具体错误的分析预定位与软件可靠度分析。将软件监测实现底层化，获取更多的程序运行数据，软件测试工作会更加深入。