CN111782553A - 一种基于故障注入的软件反应缺陷分析方法 - Google Patents

Abstract

本发明公布一种基于故障注入的软件反应缺陷分析方法，包括以下步骤：一、预先读入软件配置信息；二、遍历集合中的每个元素，对元素执行配置故障生成；三、对于配置项遍历配置故障集合的每个配置故障，将配置故障注入到配置文件中；四、使用配置文件启动被测试的软件系统；五、启动软件的功能测试；六、关闭被测试的软件系统；七、对测试结果进行分析；八、将配置故障和结果构成二元组并将其添加到集合中；九、重复第二到八步直到配置项集合被测试完；十、反应缺陷分析的结果；本发明从配置类型得到相关约束，帮助产生配置故障，将传统方法当中含糊不清的反应缺陷进行了统一规范的描述，帮助软件开发人员更加高效地对软件反应缺陷进行分析。

Description

一种基于故障注入的软件反应缺陷分析方法

技术领域

本发明涉及大型开源软件代码中配置相关缺陷自动分析的解决方法，尤其指针对大型开源软件复杂代码，提出的一种基于故障注入的软件反应缺陷分析方法。

背景技术

当前信息化技术不断发展，软件系统在系统规模和软件功能方面发生了巨大变化。在系统规模方面，目前大部分常用的开源软件规模均已达到百万行量级且在不断增加。据Coverity公司年度开源软件代码分析报告指出，在过去3年中，Linux内核代码行数以每年百万行量级增长。另一方面，软件功能日益多样，复杂软件往往通过大量配置参数提高系统的高可定制性，用户可以通过不同配置参数的设置得到期望的功能和性能，然而功能的强大以及可定制性的提高使得配置的复杂性不断提高，给用户正确配置带来了极大挑战。

软件配置的日益复杂主要体现在配置数量的不断增加和配置约束的日益复杂两个方面。在配置项数量方面，Xu等人的《Hey,you have given me too many knobs！:understanding and dealing with over-designed configuration in systemsoftware》研究表明，在大型开源软件及商业软件的演化过程中，配置项的数目呈现逐年递增的趋势，且大部分常用软件的配置项已经达到了成百上千个。到2014年，MySQL的配置项数量就达到了近500个，用户通过对这些配置项的设置控制软件的内存资源大小，工作路径，网络端口，工作模式等，为用户使用软件提供了极大的灵活性，但也给用户的正确配置带来极大困难。每个配置项的正确设置都需要满足一定的约束，这些约束除了包括数据类型，取值范围，字符串格式等语法层面的约束之外，还包括了软件与环境之间的依赖关系。例如，在PostgreSQL的配置项中，Port除了要设置成一个0-65535之间的整数值外，还需要是一个未被其他应用占用的端口值。配置项数量的增加以及配置约束的日益复杂使得用户的正确配置难度不断增大，配置故障日益普遍。

配置错误的普遍性和严重性引起了人们的广泛关注。部分研究人员开始转向配置故障发生前的故障预防工作，主要通过对用户配置约束和规则进行检查，检测配置的约束和规则违背，减少配置故障的发生。相对于故障发生后的被动诊断与修复，配置故障预防能够在故障发生之前降低其发生的可能性，从而避免配置故障带来的系统损失。但配置故障预防非常依赖于软件测试暴露潜在的软件反应缺陷。因此，如何提出一种有效的反应缺陷暴露的方法具有十分重要的意义。

很多研究人员都致力于设计新的故障注入方法来分析软件当中的反应缺陷。为了实现该目标，Zhang等人的研究《EnCore:Exploiting System Environment andCorrelation Information for Misconfiguration Detection》提出了一种基于统计学习的配置故障注入框架。其工作的主要思想是通过机器学习，找到软件运行过程中配置项之间，配置项与环境之间应该需要保持的约束关系，从而主动监测用户配置违背了哪些约束，从而注入故障分析软件反应缺陷，然而该方法依赖专家知识定义约束模板，同时需要大量的配置样本进行机器学习。Xu等人的工作《Do Not Blame Users for Misconfigurations》主要利用程序分析的方法对配置变量进行数据流和控制流分析，获取配置项的基本类型，数值范围，多值依赖，控制依赖等约束。通过违反配置约束生成配置错误，注入到软件系统，检测软件的反应缺陷，帮助开发者提高软件的可靠性。该方法在对配置变量进行分析时，需要人工编写注释实现配置项和配置变量之间的映射，增加了开发者的负担，同时依赖开发者提供软件源码，限制了该方法的使用场景。

另一方面，配置项类型与配置约束之间存在着强关联关系，通过配置项类型能推断出很多用程序分析难以得到的语义约束。同时，不同软件的反应缺陷能够被普遍归纳成特定类型，因此设计一种通用的方法，通过故障注入分析软件反应缺陷具备一定的可行性。

综上所述，建立通用的配置故障注入框架是软件反应缺陷分析的关键问题，目前的方法仍无法实现通用的配置故障注入分析框架，并且具有很差的可扩展性，应用场景仍然受到局限。因此，研究通用的配置故障注入和反应缺陷分析方法是本领域技术人员极为关注的技术问题。现有的影响最大化问题研究中没有公开文献涉及通用的故障注入和反应缺陷分析框架的方法。

发明内容

本发明要解决的技术问题是：如何进行开源软件反应缺陷检测。本发明提出了一种基于故障注入的软件反应缺陷分析方法，通过构建各种配置故障注入方法，以达暴露软件反应缺陷、提升软件可靠性目的。

为了解决上述技术问题，本发明技术方案是：首先预先读入软件配置相关信息，通过故障生成技术产生配置故障；其次，通过故障注入对软件系统当中的配置故障进行测试；再次，通过记录日志，软件行为等信息，收集软件系统对于配置故障的反应；最后通过分析软件日志等，得到软件系统中的反应缺陷报告。

具体的技术方案是：

第一步：预先读入软件A配置信息，包含配置项集合S，其中每个元素s包含配置项名key，配置项值value，配置项约束constraint。

第二步：遍历集合S中的每个元素，对元素s执行配置故障生成，方法是：

(2.1)对每个配置项key，首先解析约束constraint。constraint包括以下信息：配置项类型type，该类型对应的规约specification，配置项类型和规约如附图1所示；

(2.2)如附图2所示，本专利按照各个配置项类型使用对应的规约配置故障生成方法，产生若干个配置故障misconf₁,misconf₂...misconf_i，将其构成配置故障集合M；其中misconf代指错误的配置值misconfiguration，i代指取值范围，为自然数，根据生成方法而变化；

(2.3)基于MD5的消息摘要算法产生一个32位的随机字符串作为配置故障misconf_i+1，并将其添加到配置故障集合M中；

(2.4)如附图3所示，专利按照图中的变异方法产生5个配置故障，misconf_i+2,misconf_i+3...misconf_i+6，并将其添加到配置故障集合M中。

第三步：对于配置项key，遍历配置故障集合M的每个配置故障，将配置故障m注入到配置文件中，注入过程如附图4所示，具体方法是：

(3.1)利用配置文件解析工具Augeas解析目标软件的配置文件conffile；其中Augeas是一种广泛使用的配置文件解析工具，能够将配置文件解析成键值对的形式；

(3.2)找到和配置项名称key同名的键值对；

(3.3)将键值对当中的配置项值替换为配置故障m；

(3.4)保存成修改后的包含配置故障的配置文件conffile_m；

第四步：使用配置文件confile_m，启动被测试的软件系统，记录下启动的日志log_start和启动结果result_start，启动成功结果则为“success”，失败则为“failure”。

第五步：启动目标测试软件A的功能测试，A是第一步当中使用的目标软件。具体步骤是：

(5.1)对于测试用例集合T，遍历其中的每个测试用例t，运行测试t；

(5.2)记录测试产生的日志log_t和测试的结果result_t，测试全部成功结果则为“success”，失败则为“failure”；

第六步：关闭被测试的软件系统；

第七步：对测试结果进行分析，具体方法为：

(7.1)判断是否所有结果都为成功，即result_start＝result_t＝“success”。若是，则认为该反应为不确定的反应，r为“Indeterminate Reaction”，跳转到第八步。其中result_start为第四步当中软件的启动结果，start代表该结果来自启动过程。result_t为第五步当中软件测试的结果，t代表该结果来自测试过程。。r为本次故障注入测试的反应分类。其分类的可能结果包含四种“Indeterminate Reaction”(不确定的反应)，“PinpointingTermination”(能够帮助诊断配置故障)，“Inadequate Diagnostics”(不充分的诊断日志)或者“Early Termination”(提前终止)。

(7.2)如果启动时的结果为失败，即result_start＝“failure”，则判断启动时的日志是否能够帮助诊断配置故障，其中result_start为第四步当中软件的启动结果，start代表该结果来自启动过程。具体方法为：

(7.2.1)遍历日志log_start当中所有的文本信息。其中log_start为第四步当中软件的日志输出，start代表该结果来自启动过程。

(7.2.2)检查日志log_start信息中是否包含配置项key，注入故障m，或配置文件的路径信息。若包含则认为能够帮助诊断配置故障，r为“Pinpointing Termination”。若不能，该测试结果则标记为不充分的诊断日志，r为“Inadequate Diagnostics”。跳转到第八步。

(7.3)如果运行的测试未能通过，即result_t为“failure”，则检查测试结果，具体方法为：

(7.3.1)如果出现了崩溃挂起现象，则判定为提前终止，r为“EarlyTermination”。具体判断方法为，检查操作系统是否产生了coredump文件。

(7.3.2)如果出现了程序异常行为，则判定为运行中的故障，r为“Run-timeMisbehaviors”。具体判断方法为，测试过程软件是否出现了与测试预言不一致的软件行为，结果等。

(7.3.3)如果测试未通过不是由于配置故障导致的，则判定为误报，r为“FalseFailures”，具体判断方法为，配置故障是否满足配置约束，若满足约束则认为是误报。

第八步：将配置故障m和结果r构成二元组<m,r>，并将其添加到集合X中。

第九步：重复第二到八步，直到配置项集合S被测试完。

第十步：最后集合X即软件反应缺陷分析的结果。

与现有技术相比，采用本发明能达到以下有益效果：

本发明配置故障生成，与现有技术相比避免了专家知识指导的复杂程序分析，直接从配置类型得到相关约束，帮助产生配置故障，将传统方法当中含糊不清的反应缺陷进行了统一规范的描述，能够帮助软件开发人员更加高效地对软件反应缺陷进行分析。

本发明构建了一个通用的配置故障与反应缺陷分析框架，用预先定义的配置故障生成方法，大幅度减少了配置故障生成和注入的难度，同时量化定义了软件反应缺陷的分类，具有良好的应用。

附图说明

图1是本专利具体流程图。

图2是基于规约的配置故障生成方法示例图。

图3是基于变异的配置故障生成方法示例图。

图4是配置故障注入方法示例图。

具体实施方式

以下将结合说明书附图和具体实施例对本发明做进一步详细说明。

下面将结合附图及具体实施例对本发明进行详细说明。

本发明实施方式的关键在于如何产生配置故障，以及如何分析软件的反应缺陷，下面分别针对这两方面阐述典型的实施方式。

第一步，是配置故障生成。主要通过预先定义的软件配置故障生成规则来辅助生成配置故障，以配置项“max_file_size”为例，该配置项类型为NUMERIC，其默认值为1024，其规约为整形，合法值范围为0到65535。

(1.1)首先通过基于规约的配置故障生成方法产生配置故障，具体过程如附图2所示：

(1.1.1)根据NUMERIC的规约1，“max_file_size”为整型，能够产生以下三个配置故障：1.非整型值，例如浮点值0.5。2.整型越界的情况，例如2147483648。3.一个英文字符串“string”；

(1.1.2)根据NUMERIC的规约2，能够产生以下一个配置故障：65536(因为该值大于“max_file_size”的合法范围0到65535)；

(1.1.3)根据NUMERIC的规约3和4，“max_file_size”不存在以上规约，因此不必产生配置故障；

(1.1.4)此时基于规约的配置故障产生方法产生的配置故障集合为{0.5,2147483648,“string”,“65536”}；

(1.2)其次通过基于MD5的哈希算法产生一个32位的随机字符串作为配置故障，例如“e10adc3949ba59abbe56e057f20f883e”，并将其加入到故障集合中。此时的故障集合为{0.5,2147483648,“string”,“65536”，“e10adc3949ba59abbe56e057f20f883e”}；

(1.3)最后通过变异的方式产生配置故障，具体流程如附图3所示：

(1.3.1)删除目前的值，因此使用空字符串作为配置故障的输入；

(1.3.2)从相同的数据类型当中随机选择一个值，例如“2555709”；

(1.3.3)从不同的数据类型当中随机选择一个值，例如“randomVerb”；

(1.3.4)随机产生拼写错误，例如将1拼写错误成a，“a024”；

(1.3.5)大小写错误，将所有值使用shift产生偏移输入，例如“！)@$”；

(1.3.6)此时将所有配置故障再次添加到现有的集合中，此时的故障集合为{0.5,2147483648,“string”,“65536”，“e10adc3949ba59abbe56e057f20f883e”，“2555709”，“randomVerb”，“a024”，“！)@$”}；

(1.4)此时的配置故障集合即所有产生的配置故障。

第二步，分析软件的反应缺陷。主要通过分析软件日志的测试结果的方式来进行推定(假定已经得到配置项“max_file_size”的故障“0.5”测试的结果及日志)

(2.1)首先判断是否软件启动，测试用例是否都为通过。发现软件启动和测试用例均未通过；

(2.2)启动时的结果为失败，则判断启动时的日志能否帮助诊断配置故障；

(2.2.1)找到软件启动时的日志，遍历其中的每一句进行判断。例如，对于日志“system start failed”，其中不包括配置项名称“max_file_size”，不包括注入的配置故障“0.5”也不包括配置文件路径“/etc/pgsql.conf”等信息，因此该日志无法帮助诊断配置故障；

(2.2.2)重复遍历直到所有日志被判断结束为止。结果显示没有日志能够帮助诊断配置故障。因此该反应被标记为“Inadequate Diagnostics”，即不充分的诊断信息；

(2.3)对于配置项“max_file_size”而言，他的配置故障“0.5”的软件反应存在缺陷，且缺陷为“Inadequate Diagnostics”，该结果会被保存到软件反应缺陷报告中；

(2.4)重复遍历配置项“max_file_size”的剩余配置故障，并将结果保存到软件反应缺陷报告中。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (6)

1.一种基于故障注入的软件反应缺陷分析方法，其特征在于步骤为：

第一步：预先读入软件配置信息，包含配置项集合S，其中每个元素s包含配置项名key，配置项值value，配置项约束constraint；

第二步：遍历集合S中的每个元素，对元素s执行配置故障生成；

第三步：对于配置项key，遍历配置故障集合M的每个配置故障，将配置故障m注入到配置文件中；

第四步：使用配置文件confile_m，启动被测试的软件系统，记录下启动的日志log_start和启动结果result_start，启动成功结果则为“success”，失败则为“failure”；

第五步：启动软件的功能测试；

第六步：关闭被测试的软件系统；

第七步：对测试结果进行分析；

第八步：将配置故障m和结果r构成二元组<m,r>，并将其添加到集合X中；

第九步：重复第二到八步，直到配置项集合S被测试完；

第十步：最后集合X即软件反应缺陷分析的结果。

2.根据权利要求1所述的一种基于故障注入的软件反应缺陷分析方法，其特征在于，所述获取步骤二中对元素s执行配置故障生成的方法是：

(1)对每个配置项key，首先解析约束constraint；constraint包括以下信息：配置项类型type，该类型对应的规约specification；

(2)按照各个配置项类型使用对应的规约配置故障生成方法，产生配置故障misconf₁,misconf₂...misconf_i，将其构成配置故障集合M，其中misconf代指错误的配置值misconfiguration，i指取值范围，为自然数；

(3)基于MD5的哈希算法产生一个32位的随机字符串作为配置故障misconf_i+1，并将其添加到配置故障集合M中；

(4)按照变异方法产生5个配置故障，misconf_i+2,misconfi₊₃,...misconf_i+6，并将其添加到配置故障集合M中。

3.根据权利要求1所述的一种基于故障注入的软件反应缺陷分析方法，其特征在于，所述获取步骤三中配置故障m注入到配置文件中的具体方法是：

(1)利用配置文件解析工具Augeas解析目标软件的配置文件conffile；

(2)找到和配置项名称key同名的键值对；

(3)将键值对当中的配置项值替换为配置故障m；

(4)保存成修改后的包含配置故障的配置文件conffile_m。

4.根据权利要求1所述的一种基于故障注入的软件反应缺陷分析方法，其特征在于，所述步骤五启动软件的功能测试具体步骤是：

(1)对于测试用例集合T，遍历其中的每个测试用例t，运行测试用例t；

(2)记录测试产生的日志log_t和测试的结果result_t，测试全部成功结果则为success，失败则为failure。

5.根据权利要求1所述的一种基于故障注入的软件反应缺陷分析方法，其特征在于，所述步骤七中测试结果进行分析具体步骤为：

(1)判断是否所有结果都为成功，即result_start＝result_t＝success；若是，则认为该反应为不确定的反应，r为不确定的反应“Indeterminate Reaction”；跳转到第八步；

(2)如果启动时的结果为失败，即result_start＝failure，则判断启动时的日志是否能够帮助诊断配置故障；

(3)如果运行的测试未能通过，即result_t为“failure”，则检查测试结果，具体方法为：

(3.1)如果出现了崩溃挂起现象，则判定为提前终止，r为提前终止“EarlyTermination”，具体判断方法为，检查操作系统是否产生了coredump文件；

(3.2)如果出现了程序异常行为，则判定为运行中的故障，r为“Run-timeMisbehaviors”，具体判断方法为，测试过程软件是否出现了与测试预言不一致的软件行为、结果；

(3.3)如果测试未通过不是由于配置故障导致的，则判定为误报，r为“FalseFailures”。具体判断方法为，配置故障是否满足配置约束，若满足约束则认为是误报。

6.根据权利要求1至5任意一项所述的一种基于故障注入的软件反应缺陷分析方法，其特征在于，所述步骤(2)中判断启动时的日志是否能够帮助诊断配置故障的具体方法为：

(1)遍历日志log_start当中所有的文本信息；

(2)检查日志log_start信息中是否包含配置项key，注入故障m，或配置文件的路径信息,若包含则认为能够帮助诊断配置故障，r为“Pinpointing Termination”，若不能，该测试结果则标记为不充分的诊断日志，r为“Inadequate Diagnostics”，跳转到第八步。

Images