CN117785716A - 一种基于模型检测的复杂软件源码验证方法 - Google Patents

Abstract

本发明公开了一种基于模型检测的复杂软件源码验证方法，该方法包括：对待验证模块中的软件源码进行预处理；形式化输入模块和被调用模块，并且构建所述输出模块和被调用模块中的桩函数；对输入模块进行过滤，过滤的内容包括不合法输入和会导致循环次数过多的输入；将处理后的输入模块中的内容输入待验证模块；针对输出模块编写断言；使用模型检测工具对预处理后的软件源码以及前述编写的代码进行验证；对验证结果进行分析。本申请采用了模块划分的方法，将软件源码中的各个元素划分为模块，使得整个验证工程的结构更加清晰，便于验证计划的制定和实施。

Description

一种基于模型检测的复杂软件源码验证方法

技术领域

本发明属于计算机软件源码的验证领域，特别是对于C语言编写的复杂软件的模型检测，尤其涉及一种基于模型检测的复杂软件源码验证方法。

背景技术

长久以来，软件的安全性和功能正确性由软件测试保障。软件测试通常的流程是：构造测试样例，随后调用待测试的函数或方法，最后检验得出的结果。可以把待测试的目标称为一个模块，这个模块可以对特定的输入给出特定的输出。但构造测试样例只能覆盖部分输入，尤其是当输入参数增多时，可能的输入数量快速膨胀，软件测试能覆盖的输入数量显得更加微不足道。

模型检测(model checking)技术将程序源码转化为公式，再用公式解析器来证明公式的正确性。模型检测特有的未定型(non-deterministic)变量可以覆盖所有的输入。而且相比于其他形式化验证技术，模型检测有着更高的自动化程度。不过模型检测技术无法处理无限循环的问题，有界模型检测(bounded model checking)通过设定循环上界的方式，来验证有限次循环中待验证模块的正确性，只要实际执行的循环次数未超过设定的上界，就可以认为待验证模块具有完备的正确性。有时一些极端的输入会导致循环次数超过设定的上界，此时验证的完备性不能保证，不过覆盖的输入数量依然远大于软件测试。

模型检测工具大多只提供简单的前后置条件原语，对于结构较为简单的模块，可以较为直观地编写出前后置条件进而完成验证，但对于结构较为复杂的模块，输入输出的数量多并且形式较为多样化，验证这些模块需要编写大量的验证代码以及对验证工具进行细粒度的配置。因此，有必要针对复杂的软件模块，设计一套模型检测的标准流程，来增加验证工作的效率，提高验证的准确性。

发明内容

目前的模型检测验证工程大多停留在编写简单的前后置条件，验证简单模块。而对于软件模块中的宏、文件、函数指针、系统调用、跨模块调用以及跨模块通信等未形成标准的处理方法。而当前复杂软件的安全性检测只能通过软件测试保障，但经过测试后的软件可能依然有着大量的缺陷。对上述问题，本发明提出了一种基于模型检测的复杂软件源码验证方法，将模型检测技术引入对大型软件的安全性检测中，为复杂软件的测试提供新的、更安全的选

本申请实施例提供一种基于模型检测的复杂软件源码验证方法，基于一种复杂软件源码验证系统实现，该系统包括待验证模块、输入模块、被调用模块和输出模块，包括：

(1)对待验证模块中的软件源码进行预处理；

(2)形式化输入模块和被调用模块，并且构建所述输出模块和被调用模块中的桩函数；

(3)对输入模块进行过滤，过滤的内容包括不合法输入和会导致循环次数过多的输入；

(4)将处理后的输入模块中的内容输入待验证模块；

(5)针对输出模块编写断言；

(6)使用模型检测工具对预处理后的软件源码以及步骤(2)-(5)编写的代码进行验证；

(7)对步骤(6)中的验证结果进行分析。

进一步地，所述输入模块中的输入包括：

数据型参数，传递方式为调用接口时作为参数传递给待验证模块；

数据文件，传递方式为调用接口时传递文件路径给待验证模块，待验证模块需要根据路径自行读取文件的内容；

配置文件，用于修改待验证模块的行为，传递方式为调用接口时传递文件路径给待验证模块，待验证模块需要根据路径自行读取文件的内容；

宏文件，用于修改待验证模块的行为，传递方式为通过include预处理指令引入；

函数指针，传递方式为调用接口时作为参数传递给待验证模块；

控制型参数，用于控制待验证模块的行为，传递方式为调用接口时作为参数传递给待验证模块；

其中数据型参数、数据文件为数据型输入，配置文件、宏文件、函数指针、控制型参数为控制型输入。

进一步地，所述被调用模块中包括其他模块接口和桩函数：

所述其他模块接口为未使用桩函数而直接调用其他软件模块的服务；

所述桩函数用于将软件源码中其他软件模块的服务接口进行抽象并用模型检测的语言描述其功能。

进一步地，所述输出模块用于体现待验证模块对于某次输入的处理结果，包括直接返回的结果、对状态的修改以及对其他模块的调用：

返回值，主要包括直接获取的接口返回值，或者将指针作为参数传入后，待验证模块对指针内容做出的修改；

对静态变量和全局变量的修改，其中对静态变量的修改通过使用接口来间接地验证该部分的输出获得，对全局变量的修改通过读取全局变量获得；

接收桩函数，用于记录调用信息和功能模拟。

进一步地，步骤(1)具体为：将软件源码中的宏文件和配置文件进行组合，得到若干配置。

进一步地，步骤(2)中，形式化输入模块，包括：

判断是否需要验证所有配置；

若需要验证所有配置，则使用脚本生成配置文件/宏；反之则按照需求编写特定的配置文件/宏；

将控制型参数、数据型参数设置为未定型；

将数据文件、配置文件以及函数指针设置为确定型参数。

进一步地，步骤(3)中，对控制型参数和取值有限制的数据型参数进行过滤，其中控制型参数需要确保值为有效的配置取值，数据型参数按照限制进行过滤。

进一步地，步骤(7)中，对失败的断言进行分析，其中：

对于功能性断言的失败，需要检查软件源码和步骤(2)-(5)编写的代码的正确性，若无误，则证明软件源码中存在缺陷；

对于安全性断言的失败，其证明软件源码中存在安全性缺陷。

本申请的实施例提供的技术方案可以包括以下有益效果：

采用了模块划分的方法，将软件源码中的各个元素划分为模块，使得整个验证工程的结构更加清晰，便于验证计划的制定和实施。

对于文件的处理，采用编写桩函数替换掉write和read系统调用的方式，解决了模型检测工具无法直接读取文件的问题，并使得验证人员可以自由控制文件的内容，针对不同的文件名返回不同的结果。

对于待验证模块最终将输出通过接口或传入的函数指针向外输出的情况，编写可以获取参数内容的桩函数，并替换掉对应的接口和函数指针，获取待验证模块的输出。获取到输出后，针对输出编写相应的后置条件。解决了模型检测难以获取此类输出的问题。

对于待验证模块对于其他模块的调用，采用“描述型桩函数”的方法，只模拟被调用接口的对外表现，而去掉具体的功能，从而提高验证的效率，并剔除被调用接口中不安全的代码对待验证模块的影响。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是根据一示例性实施例示出的复杂软件源码验证系统的示意图。

图2是根据一示例性实施例示出的一种基于模型检测的复杂软件源码验证方法的流程图。

图3是根据一示例性实施例示出的形式化输入模块的流程图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请提供一种基于模型检测的复杂软件源码验证方法，该方法基于如图1所示的一种复杂软件源码验证系统实现，该系统包括待验证模块、输入模块、被调用模块和输出模块，除待验证模块外，其他模块都可以为空，除了待验证模块外，缺少任一其他模块中的任一部分都不会影响验证方法的运行，例如该模块不适用配置文件，输入模块中的‘配置文件’部分则可以省略。

需要说明的是，本申请中的复杂软件指实现方式复杂的软件，实现方式的复杂包括使用了较多高级的语言特性、使用复杂的配置文件以及频繁地和操作系统交互等。

输入模块中的所有可能的输入组成的集合为输入空间，本申请需要验证(1)功能正确性：对于任意一个输入空间中的输入，将其输入到待验证模块后，产生的输出都是符合预期的；(2)安全性：对于任意一个输入空间中的输入，将其输入到待验证模块后，执行过程都中不会产生安全异常，安全异常括但不限于指针异常、内存异常、除零错误以及计算溢出等。

对于待验证模块，其应该对外暴露一些接口，用户可以通过调用这些接口来使用该模块提供的服务。本方法应该覆盖所有的接口，并检验每个接口的功能正确性和安全性。

输入模块中的输入可以分为两大类(1)数据型输入：待验证模块将该类型的输入当作数据来处理，从结果上来看，该输入不会影响待验证模块的行为，但会影响待验证模块的输出；(2)控制型输入：此类输入可以影响待验证模块的行为，也可以影响待验证模块的输出。事实上，输入类型并非精确的定义，只是对输入模块中各个部分的一个分类，以便后续对两种输入类型的分开处理。控制型输入为确定值，数据型输入为未定型，特定值为确定的字面值或者字面值的集合。未定型是模型检测中特有的值类型。当代码中的某一变量未被赋值时，模型检测工具会认为其为未定型，在验证过程中会验证未定型的所有可能的取值。输入模块中的输入具体包括：

1、数据型参数，传递方式为调用接口时作为参数传递给待验证模块，大多数参数都属于此部分，该部分属于数据型输入；

2、数据文件，传递方式为调用接口时传递文件路径给待验证模块，待验证模块需要根据路径自行读取文件的内容，文本文件、word文档以及excel表格大多属于此部分，该部分属于数据型输入；

3、配置文件，传递方式与数据文件相同，但此类文件的目的是修改待验证模块的行为，xml、json以及一些自定义类型的配置文件大多属于此部分，该部分属于控制型输入；

4、宏文件，该部分输入不通过接口直接传递，而是通过include预处理指令引入，该部分可以以多种方式改变待验证模块的行为，例如通过宏定义来改变缓冲区的大小，或者通过ifdef等预处理指令直接改变待验证模块的源码，该部分属于控制型输入；

5、函数指针，传递方式为调用接口时作为参数传递给待验证模块。该部分特殊在函数指针必须是取自真正存在的函数，而不能使用未定型。对于函数指针的处理方式与普通参数不同，故将函数指针单独作为一部分。该部分属于控制型输入。

6、控制型参数，其传递方式与数据型参数相同，不过其意图是用来控制待验证模块的行为，例如位标志大多属于此部分，此外如果采用命令模式，将命令以字符串形式传入待验证模块，该命令字符串也属于控制型参数。该部分属于控制型输入；

所述被调用模块中包括其他模块接口和桩函数：

其他模块接口，即未使用桩函数而直接调用其他软件模块的服务，这种方式有两个缺点：一是其他模块的正确性无法保证；二是会增加被验证的代码量，降低验证工程的效率；

桩函数，是将源码中其他软件模块的服务接口进行抽象，用模型检测的语言描述其功能，抽象目的可以是实现验证模块间的隔离、增加验证工程的效率以及实现一些特殊的验证工程的需求，在验证过程中，如果编写了某个函数的桩函数，模型检测工具会用桩函数替换掉该函数的源码。

在具体实施中，桩函数应尽量多，其他模块接口应尽量少。

所述输出模块用于体现待验证模块对于某次输入的处理结果，主要表现为直接返回的结果、对状态的修改以及对其他模块的调用，具体包括：

1、返回值，主要包括直接获取的接口返回值，或者将指针作为参数传入后，待验证模块对指针内容做出的修改。在复杂的软件模块中，接口的返回值大多表示接口的执行状态，而不直接反应此次调用的输出。而对于指针型参数的修改大多出现在中间级的模块，用于数据结构的转化，在顶层模块中则较为少见，该部分属于直接返回的结果；

2、对静态变量的修改，该部分的修改对外不可见，因此需要使用接口来间接地验证该部分的输出，该部分属于对状态的修改；

3、对全局变量的修改，该部分的修改可以直接通过读取全局变量获得。不过直接修改全局变量不太符合软件设计的原则，所以较为少见，该部分属于对状态的修改；

4、接收桩函数，该部分是输入出模块中最主要的部分，主要功能包括记录调用信息和功能模拟。大部分模块的输出行为都表现为对子模块，其他模块以及操作系统的调用。因此，需要编写桩函数以获取到待验证模块调用其他模块时所使用的参数，进而验证其功能正确性，例如，待验证模块最终使用网络发送自身的处理结果，则需要编写桩函数来替换掉操作系统的网络接口，并对发送的内容进行检查。此外，也有部分输出表现为文件的写入，但该类型也属于对操作系统的调用的一种，用桩函数覆盖掉操作系统的文件写入接口即可，该部分属于对其他模块的调用。

基于上述系统，如图2所示，本方法具体包括如下步骤：

(1)对待验证模块中的软件源码进行预处理；

具体地，步骤(1)中预处理的部分包括宏和配置文件。其中宏编写在头文件中，通过include预处理指令被待验证模块引入，本申请中把此类文件称为宏文件。进一步地，本申请中把一组特定的宏文件和配置文件称为一个配置。预处理部分需要最终得到若干个配置，并分别在每个配置上通过以下步骤进行一次验证，但更换配置时无需修改其他模块的代码。当需要验证的配置过多时，使用配置生成器自动生成配置。

需要说明的是，配置的形式(有哪些配置文件以及每个文件有哪些配置参数)是软件的开发者决定的。例如某个模块接收一个头文件和一个xml文件作为配置，那么任意一组按照格式编写的头文件和xml文件都可以组成一个特定的配置。不同的配置格式相同，但配置参数的值不同。

(2)形式化输入模块和被调用模块，并且构建所述输出模块和被调用模块中的桩函数；

验证工程开启后，先进行初始化阶段，该阶段用模型检测语言描述未在步骤(1)中进行预处理的所有部分。

本步骤中，对于输入模块、输出模块和被调用模块的处理过程可以并行。

被调用模块和输出模块都需要编写桩函数。桩函数只负责模拟真实函数的行为以及记录调用信息，而不应该有真实的处理逻辑。其中调用信息的获取接口应暴露给验证工程的其他部分。此外，桩函数的范围应限于与其他模块或者操作系统的具有通信功能的函数，对于工具型的函数，不应对其编写桩函数。

对于读取类型的桩函数，其应该实现相应的确定型版本和未定型版本，可以对按照需求生成对应版本的数据。其中对于未定型流式数据，其内容和长度均应为未定型。但待验证模块的源码不会有控制生成确定型或者未定型数据版本的参数，因此应在桩函数内部，针对不同的文件描述符或资源描述符，生成特定类型的数据。此外，读取类型的桩函数应记录生成的内容，并将获取生成内容的接口暴露给验证工程的其他部分。

需要说明的是，被调用模块的形式化即为利用桩函数和接口对被调用模块的功能进行描述，例如待验证模块调用了某个字符串加密函数，这个函数的实现可能非常复杂，甚至存在一些缺陷。但对于待验证模块来说，只知道这个加密函数接收一个字符串并返回另一个，对它进行了什么工作并不关心。因此在验证时没有必要使用原来的加密函数，而是编写一个尽量简单并且安全的桩函数(例如直接返回输入的字符串)来替换掉它。

图3所示为形式化输入模块的详细流程，包括以下子步骤：

S311：判断是否需要验证所有配置；

具体地，一套配置文件和宏文件可以成为一个配置，一个验证方法只能对一个配置进行验证。因此对于不同的配置，需要运行多次验证方法，但无需修改验证方法的其他部分。对于配置的处理可以分为两种：(1)验证待验证模块在所有配置下的正确性，来确保验证的完备性。该方式需要通过脚本自动生成所有可能的配置，但可能的配置数量会根据配置项的增多呈指数级上升，验证的效率较低。(2)验证待验证模块在部分配置下的正确性，通常情况下，待验证模块运行在一个或若干个特定的配置下，可以只针对这些配置进行验证，来增加验证的效率，但也会损失掉对于其他配置的覆盖。

S312：若需要验证所有配置，则使用脚本生成配置文件/宏；反之则按照需求编写特定的配置文件/宏；

具体地，宏难处理的原因是宏无法设置成未定型，所以只能设置成确定型并多次尝试。配置文件虽然可以通过桩函数的方式设置成未定型，但也较为繁琐。但二者有一个共同的特点就是在运行时配置参数的值不会再改变。本文中对配置的处理没有使用模型检测的方法，而是在验证中像常规调用那样，使用一个确定的配置。如果需要验证不同的配置，需要修改配置文件，重新进行一次验证。S312讨论的是如何编写配置文件的过程，手动编写或者脚本编写都是可以的，只要最终得到一组配置文件即可。但如果要验证的配置过多，最好使用脚本。这样设计的原因如第一段所说，配置很难使用未定型，不过好在配置在程序运行前就决定了，因此我们选择“验证在多个特定配置下的正确性”而不是“验证在所有可能配置下的正确性”。

需要说明的是，所述“验证所有配置下的正确性”，其实是覆盖了所有特定的配置。大部分情况下是不可能做到的。例如宏中有一个BUF_SIZE来定义buffer的大小，如果考虑所有无符号32位整型，那要编写4294967296个配置。不过如果配置中只有一些布尔型，例如USE_BUFFER来决定是否使用buffer，则验证所有的配置是可能的，不过需要编写配置的数量依然随着配置参数的增加呈指数级上升。

S313：将控制型参数、数据型参数设置为未定型；

S314：将数据文件、配置文件以及函数指针设置为确定型参数；

和普通的调用相同，不用做特殊处理，传入需要传入的函数指针以及文件名即可。不过传入的函数指针通常是桩函数的函数指针，而对于文件的具体处理在读取文件内容时执行，传递文件名时不需要处理。

步骤S315的参数均为确定型参数，包括数据文件、配置文件以及函数指针。虽然数据文件、配置文件分属于数据型输入和控制型输入，但二者同为文件参数，传参的方式相同，都以文件名的方式传入。对于文件类型参数，待验证模块最终会使用读文件系统调用(如read)，通过文件名读取文件内容，对于该场景，必须要编写相应系统调用的桩函数，待验证模块通过桩函数读取文件内容。为了方便验证，可以将验证工程中用到的文件编写为一个文件库，read的桩函数通过文件名去库中读取得到特定的字符串和长度。其中文件内容也应分为确定型和未定型，其中未定型文件的长度和每个字符的值均为未定型，但长度应该根据配置做出限制。配置文件应为确定型文件，并且其内容来自步骤S312，数据文件的内容应为未定型。

函数指针参数可按用途分为两种，一种为协助待验证模块的工作，一种为输出的一部分，前者需要传入所述其他模块接口的函数指针或者桩函数的函数指针，后者需要传入接收桩函数的函数指针。

对于接收桩函数，主要包含两部分：(1)调用信息，记录函数被调用的次数以及每次调用时传入的参数，调用信息应该使用变量记录，并且可以被验证工程获取，以检验待验证模块的输出。(2)模拟功能，此处无需编写真实的处理逻辑，而是对一些功能的模拟，例如使用一个未定布尔型变量模拟函数操作失败的情况，此部分主要用于将特定的返回值提供给待验证模块。

桩函数则只需要包含模拟功能的部分。

对于所述其他模块接口，无需做特殊处理，但注意该部分的接口均为源码，应尽量为该部分的接口编写桩函数使其变为桩函数。

输出模块中的返回值以及修改全局变量可以较为直接地获取并验证，但修改静态变量需要使用待验证模块的其他接口间接获得。也有一些完全无法获得的静态变量，对于这些静态变量的检验可以忽略。因为验证方法本就站在模块使用者的角度，完全不对外暴露的静态变量属于待验证模块的内部状态，而只要对外的接口全部通过了验证，就可以认为待验证模块的功能正确性和安全性通过了验证。

(3)对输入模块进行过滤，过滤的内容包括不合法输入和会导致循环次数过多的输入；

需要对步骤(2)所得到的输出进行过滤，原因有两点：有些接口对输出部分有着一定的要求，例如对某些整型参数有着范围要求，因此需要过滤掉不合法的输入；由于模型检测在循环次数增多时效率会大幅下降，有时为了验证工程的可执行性，必须过滤掉某些会导致循环次数过多的输入。

初始时控制型参数和数据型参数均为未定型，其中控制型参数和对取值有限制的数据型参数需要进行过滤，控制型参数需要确保值为有效的配置取值，数据型参数按照限制进行过滤。

过滤主要在前置条件中，所有的源码模型检测工具都会提供assume原语来声明验证的前置条件。例如待验证模块要求传参时某个参t数只能取正数，则在前置条件中加入assume(t>0)来过滤掉负数和0。

确定型只能覆盖一个值，想要覆盖多个值必须使用未定型。例如t＝1只能验证t为1时的正确性。相应地，想要验证t在(0,100)上的正确性需要执行

t＝nondet_int()；

assume(t>0)；

assume(t<100)；

其中第一行即为设置未定型，第2、3行即为进行过滤。

(4)将处理后的输入模块中的内容输入待验证模块；

待验证模块会调用处理过后的被调用模块中的服务，并将结果输入进接收桩函数中。

(5)针对输出模块编写断言；

断言应按照验证需求编写，断定输出满足期望的性质，此外还有一些由模型检测工具自动生成的断言，此类断言无需手动编写。

需要说明的是，步骤(3)和步骤(5)分别对应待验证模块安全性和功能正确性的前置条件和后置条件，其编写应严格按照验证需求。

(6)使用模型检测工具对预处理后的软件源码以及步骤(2)-(5)编写的代码进行验证；

具体地，对前述编写的所有代码，以及待验证模块的源码输入模型检测工具中进行验证。此外还需根据验证需求对模型检测工具进行特定的配置，特殊的配置可能会使模型检测工具生成额外的断言。

需要说明的是，“根据验证需求对模型检测工具进行特定的配置”即为根据实际情况对要使用的模型检测工具进行设置，例如使用CBMC时，需要设置循环展开上界，是否需要检测数组越界以及是否需要检测指针错误等。

(7)对步骤(6)中的验证结果进行分析；

具体地，对步骤(6)中的验证结果进行分析，分析主要针对于失败的断言。对于功能性断言的失败，除了要检查源码，还需要检查验证代码的正确性。验证代码的数量和复杂度低于源码，可以较快的检查。确认验证代码准确无误并且源码确实会出现对应的错误后，证明此次验证工程发现了缺陷，可以将缺陷上保给待验证模块的开发者。而安全性断言的失败往往证明源码中确实存在安全性缺陷，可以直接上报。

需要说明的，上述所有步骤都不应涉及对待验证模块中软件源码的修改。

本领域技术人员在考虑说明书及实践这里公开的内容后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。

Claims (8)

1.一种基于模型检测的复杂软件源码验证方法，其特征在于，基于一种复杂软件源码验证系统实现，该系统包括待验证模块、输入模块、被调用模块和输出模块，该方法包括：

(1)对待验证模块中的软件源码进行预处理；

(2)形式化输入模块和被调用模块，并且构建所述输出模块和被调用模块中的桩函数；

(3)对输入模块进行过滤，过滤的内容包括不合法输入和会导致循环次数过多的输入；

(4)将处理后的输入模块中的内容输入待验证模块；

(5)针对输出模块编写断言；

(6)使用模型检测工具对预处理后的软件源码以及步骤(2)-(5)编写的代码进行验证；

(7)对步骤(6)中的验证结果进行分析。

2.根据权利要求1所述的方法，其特征在于，所述输入模块中的输入包括：

数据型参数，传递方式为调用接口时作为参数传递给待验证模块；

数据文件，传递方式为调用接口时传递文件路径给待验证模块，待验证模块需要根据路径自行读取文件的内容；

配置文件，用于修改待验证模块的行为，传递方式为调用接口时传递文件路径给待验证模块，待验证模块需要根据路径自行读取文件的内容；

宏文件，用于修改待验证模块的行为，传递方式为通过include预处理指令引入；

函数指针，传递方式为调用接口时作为参数传递给待验证模块；

控制型参数，用于控制待验证模块的行为，传递方式为调用接口时作为参数传递给待验证模块；

其中数据型参数、数据文件为数据型输入，配置文件、宏文件、函数指针、控制型参数为控制型输入。

3.根据权利要求1所述的方法，其特征在于，所述被调用模块中包括其他模块接口和桩函数：

所述其他模块接口为未使用桩函数而直接调用其他软件模块的服务；

所述桩函数用于将软件源码中其他软件模块的服务接口进行抽象并用模型检测的语言描述其功能。

4.根据权利要求1所述的方法，其特征在于，所述输出模块用于体现待验证模块对于某次输入的处理结果，包括直接返回的结果、对状态的修改以及对其他模块的调用：

返回值，主要包括直接获取的接口返回值，或者将指针作为参数传入后，待验证模块对指针内容做出的修改；

对静态变量和全局变量的修改，其中对静态变量的修改通过使用接口来间接地验证该部分的输出获得，对全局变量的修改通过读取全局变量获得；

接收桩函数，用于记录调用信息和功能模拟。

5.根据权利要求1所述的方法，其特征在于，步骤(1)具体为：将软件源码中的宏文件和配置文件进行组合，得到若干配置。

6.根据权利要求1所述的方法，其特征在于，步骤(2)中，形式化输入模块，包括：

判断是否需要验证所有配置；

若需要验证所有配置，则使用脚本生成配置文件/宏；反之则按照需求编写特定的配置文件/宏；

将控制型参数、数据型参数设置为未定型；

将数据文件、配置文件以及函数指针设置为确定型参数。

7.根据权利要求1所述的方法，其特征在于，步骤(3)中，对控制型参数和取值有限制的数据型参数进行过滤，其中控制型参数需要确保值为有效的配置取值，数据型参数按照限制进行过滤。

8.根据权利要求1所述的方法，其特征在于，步骤(7)中，对失败的断言进行分析，其中：

对于功能性断言的失败，需要检查软件源码和步骤(2)-(5)编写的代码的正确性，若无误，则证明软件源码中存在缺陷；

对于安全性断言的失败，其证明软件源码中存在安全性缺陷。