CN110543423A - software dependence package capability detection method, system and medium - Google Patents

software dependence package capability detection method, system and medium Download PDF

Info

Publication number
CN110543423A
CN110543423A CN201910838012.4A CN201910838012A CN110543423A CN 110543423 A CN110543423 A CN 110543423A CN 201910838012 A CN201910838012 A CN 201910838012A CN 110543423 A CN110543423 A CN 110543423A
Authority
CN
China
Prior art keywords
software
function
library
tested
package
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201910838012.4A
Other languages
Chinese (zh)
Other versions
CN110543423B (en
Inventor
秦莹
汤佳伟
马俊
李小玲
朱浩
董攀
高珑
杨沙洲
谭郁松
吴庆波
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
National University of Defense Technology
Original Assignee
National University of Defense Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by National University of Defense Technology filed Critical National University of Defense Technology
Priority to CN201910838012.4A priority Critical patent/CN110543423B/en
Publication of CN110543423A publication Critical patent/CN110543423A/en
Application granted granted Critical
Publication of CN110543423B publication Critical patent/CN110543423B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3684Test management for test design, e.g. generating new test cases

Abstract

The invention discloses a method, a system and a medium for detecting the capability of a software dependence package, wherein the step of judging whether the software to be tested is compatible with a target system comprises the steps of judging whether the software to be tested is compatible with the target system or not and outputting a compatibility detection report by dependence library detection, library package calling function detection and external function test case execution detection after the input software to be tested is obtained; the step of judging whether the interface provided by the software library to be tested is consistent with the expected function comprises the steps of calling function detection through a library package and executing detection of an external function test case after the input software to be tested is obtained, judging whether the interface provided by the software library to be tested is consistent with the expected function and outputting an expected function detection report. The invention can effectively solve the problems of compatibility and safety of the software dependence package by judging whether the software to be tested is compatible with the target system and is consistent with the expected function.

Description

software dependence package capability detection method, system and medium
Technical Field
The invention relates to an execution detection technology of a computer operating system and application software, in particular to a software dependence package capability detection method, a system and a medium.
background
Modern Linux operating systems manage the installation of application software in the form of a software package manager, such as the apt tool under the Ubutnu operating system, the yum tool under the CentOS, and the like. The software package can be automatically installed, configured, uninstalled and upgraded through the software package manager. Meanwhile, based on a dynamic link mechanism of elf files under Linux, each software package can refer to functions or data structures in other library packages, the relation caused by function reference among the library packages is called dependency, and packages providing the functions or the data structures for other software packages are called dependency packages. The introduction of the dependency relationship greatly reduces the volume of the software package, and reduces the development cost and the difficulty of version upgrade of the software package, but the method also has disadvantages, mainly including the following two points:
1. Compatibility issues: due to the increase of functions and the modification of defects, the software package can be upgraded irregularly, and developers generally use a certain version of the package according to the current situation when referencing the dependent package. Compatibility problems may arise if two software packages in the system each use a different version of a library package.
2. safety problems are as follows: the developers of the library packages can only ensure that the library packages are safe and cannot ensure that the library packages depended on the developers are safe. The same is true for the developer of the dependent library package. In a dependency relationship, if a security problem exists in an upstream library package, all the downstream library packages that depend on it directly or indirectly are affected.
for compatibility issues, abickock or abitracker can be used to examine function calls between a software package and its dependencies. The software package may also use the dependent libraries after promotion or demotion if these functions remain unchanged in the dependent libraries after promotion or demotion. A more direct approach is to run the software package directly in an environment that relies on either a library upgrade or downgrade. In both of the above two modes, the compatibility problem of the software library of the local machine can be checked only in the local environment, and the compatibility problem of the software library in the operating system of the other version cannot be remotely detected. In addition, the two ways of inspection are relatively crude. Only after detecting a version change, the function prototype has not changed and the function capability cannot be checked. For security issues, the Ubuntu software repository accepts only pushes from trusted, active developers. Therefore, the prior art has the problems of low detection capability of the software dependent package, influences and restricts the application of the software dependent package in the linux system, and has poor safety.
Disclosure of Invention
The technical problems to be solved by the invention are as follows: the present invention can determine whether an application can be run on a target operating system without running the application, and can be applied to various security systems. At the same time, it can analyze application dependencies, find the smallest library package that the target operating system lacks to support application execution. In addition, the invention can automatically test the function library by introducing the test case.
in order to solve the technical problems, the invention adopts the technical scheme that:
a method for detecting the capability of a software dependent package comprises the step of judging whether software to be tested is compatible with a target system, wherein the step comprises the following steps:
1) Acquiring input software to be tested;
2) acquiring all dependency libraries of software to be tested, and judging whether all dependency libraries of the software to be tested are compatible with a target system or not according to a preset first depth dependency model, wherein the first depth dependency model records dependency library information of the target system;
3) Acquiring a library package calling function list of software to be tested, and judging whether function prototypes of homonymous functions exist in each library package calling function called by the library package of the software to be tested in a preset first deep dependence model, wherein the first deep dependence model records function prototypes which can be called and are possessed by a target system;
4) acquiring each external function of software to be tested, acquiring a corresponding test case from a preset first depth-dependent model and judging whether the operation is successful, wherein the first depth-dependent model records the test case of each external function;
5) and outputting a compatible detection report according to the detection results of the steps 2) to 4).
optionally, the detailed steps of step 2) include:
2.1) obtaining all the dependency libraries of the software to be tested to obtain a dependency library set;
2.2) traversing and selecting a current dependent library from the dependent library set, obtaining the library name of the current dependent library, checking whether the library name of the current dependent library exists in a preset first deep dependent model, if not, skipping to execute the step 2.3), otherwise, obtaining the version, the format, the size and the digit of the current dependent library in the first deep dependent model, judging whether the version, the format, the size and the digit of the current dependent library in a target system meet the requirements, if so, judging that the compatibility check of the current dependent library is passed, otherwise, judging that the compatibility check of the current dependent library is not passed;
2.3) judging whether the traversal of the dependency library set is finished, and if not, skipping to execute the step 2.2); otherwise, skipping to execute the step 3).
optionally, the detailed steps of step 3) include:
3.1) acquiring a library package calling function list of the software to be tested;
3.2) traversing and selecting a current external function prototype from the external function prototype list, judging whether the current external function prototype has a function prototype of the same name function in a preset first depth dependence model, if so, judging that the compatibility check of the current external function prototype passes, otherwise, judging that the compatibility check of the current external function prototype does not pass;
3.3) judging whether the traversal of the external function prototype list is finished or not, and if not, skipping to execute the step 3.2); otherwise, skipping to execute step 4).
optionally, the detailed steps of step 4) include:
4.1) acquiring a library package calling function list of the software to be tested;
4.2) traversing and selecting a current external function from the external function list, judging whether the current external function has a corresponding test case in a preset first depth dependence model, if so, running the test case and judging whether the test case runs successfully, if so, judging that the compatibility check of the current external function passes, otherwise, judging that the compatibility check of the current external function does not pass;
4.3) judging whether the traversal of the external function list is finished or not, and if not, skipping to execute the step 3.2); otherwise jump to execute step 5).
In addition, the invention also provides a software dependence package capability detection method, which comprises the step of judging whether the interface provided by the software library to be tested is consistent with the expected function, wherein the step comprises the following steps:
s1) acquiring input software to be tested;
S2) obtaining a library package calling function list of the software to be tested, and judging whether function prototypes of homonymous functions exist in a preset second depth dependence model of each library package calling function called by the library package of the software to be tested, wherein the second depth dependence model records an external function prototype list expected by the software to be tested;
s3) obtaining each external function of the software to be tested, obtaining a corresponding test case from a preset second depth-dependent model and judging whether the operation is successful, wherein the second depth-dependent model records an expected external function list of the software to be tested;
s4) outputs an expected function test report according to the test results of steps S2) to S3).
Optionally, the detailed step of step S2) includes:
s2.1) acquiring a library package calling function list of the software to be tested;
s2.2) traversing and selecting a current external function prototype from the external function prototype list, judging whether the current external function prototype has a function prototype of a homonymous function in a preset second depth-dependent model, if so, judging that the current external function prototype is consistent with an expected function, otherwise, judging that the current external function prototype is inconsistent with the expected function;
S2.3) judging whether the traversal of the external function prototype list is finished or not, and if not, skipping to execute the step 3.2); otherwise jump to step S3).
Optionally, the detailed steps of step 4) include:
s3.1) acquiring a library package calling function list of the software to be tested;
S3.2) traversing and selecting a current external function from the external function list, judging whether the current external function has a corresponding test case in a preset second depth dependence model, if so, running the test case and judging whether the test case is successfully run, if so, judging that the current external function is consistent with an expected function, otherwise, judging that the current external function is inconsistent with the expected function;
S3.3) judging whether the traversal of the external function list is finished or not, and if not, skipping to execute the step S3.2); otherwise jump to step S4).
in addition, the invention also provides a software dependency package capability detection system, which comprises a program unit for judging whether the software to be tested is compatible with the target system, wherein the program unit comprises:
the input program unit is used for acquiring input software to be tested;
the dependency library checking program unit is used for acquiring all dependency libraries of the software to be tested, and judging whether all the dependency libraries of the software to be tested are compatible with the target system or not according to a preset first depth dependency model, wherein the first depth dependency model records dependency library information of the target system;
The external function prototype checking program unit is used for acquiring a library package calling function list of the software to be tested, and judging whether function prototypes of homonymous functions exist in each library package calling function called by the library package of the software to be tested in a preset first deep dependence model or not, wherein the first deep dependence model records function prototypes which can be called and are possessed by a target system;
The external function checking program unit is used for acquiring each external function of the software to be tested, acquiring a corresponding test case from a preset first depth-dependent model and judging whether the operation is successful, wherein the first depth-dependent model records the test case of each external function;
And the output program unit is used for outputting a compatible detection report according to the detection result.
Furthermore, the present invention also provides a software dependency package capability detection system, comprising a computer device programmed or configured to execute the steps of the software dependency package capability detection method, or a storage medium of the computer device having stored thereon a computer program programmed or configured to execute the software dependency package capability detection method.
furthermore, the present invention also provides a computer-readable storage medium having stored thereon a computer program programmed or configured to execute the software dependent package capability detection method.
Compared with the prior art, the invention has the following advantages:
aiming at the compatibility problem: the dependency package capability detection tool provided by the invention realizes the off-line detection of the compatibility of the software package and the target operating system under the environment of any version of operating system by introducing the deep dependency model of the target system. The method for judging the function consistency between the library package versions comprises the steps of recording the interface function prototype in the library package and the predicted function of the interface function, carrying out interface function comparison detection on the library package versions before and after upgrading, and judging whether the prototype and the function of an external interface in the library package are changed or not after the library package versions are upgraded. In addition, the dependency package capability detection tool detects whether the capability of the function is changed after the version is changed by running the test case of the function called by the software package.
aiming at the safety problem: the packet-dependent capability detection tool provided by the invention can detect the abnormal behavior of the interface of the problem library packet by automatically detecting the function data and the function of the library packet. The method can automatically detect the function data and the function of the library package by the package-dependent capability detection, thereby solving the safety problem and the version compatibility problem of the library package.
in summary, the present invention can determine whether an application can be run on a target operating system without running the application, and can be applied to various security systems. At the same time, it can analyze application dependencies, find the smallest library package that the target operating system lacks to support application execution. In addition, the invention can automatically test the function library by introducing the test case.
drawings
FIG. 1 is a schematic diagram of a basic process of an embodiment of the present invention.
fig. 2 is a schematic diagram of a basic flow of a method step 2 according to an embodiment of the present invention.
fig. 3 is a schematic diagram of a basic flow of step 3 of a method according to an embodiment of the present invention.
Fig. 4 is a schematic basic flowchart of a method step 4 according to an embodiment of the present invention.
FIG. 5 is a schematic diagram of a basic flow chart of a second method according to an embodiment of the present invention.
Detailed Description
as shown in fig. 1, the software dependency package capability detection method of this embodiment includes a step of determining whether software to be tested is compatible with a target system, where the step includes:
1) Acquiring input software to be tested;
2) Acquiring all dependency libraries of software to be tested, and judging whether all dependency libraries of the software to be tested are compatible with a target system or not according to a preset first depth dependency model, wherein the first depth dependency model records dependency library information possessed by the target system;
3) Acquiring a library package calling function list of software to be tested, and judging whether function prototypes of homonymous functions exist in each library package calling function called by the library package of the software to be tested in a preset first deep dependence model or not, wherein the first deep dependence model records function prototypes which can be called and are possessed by a target system;
4) Acquiring each external function of software to be tested, acquiring a corresponding test case from a preset first depth-dependent model and judging whether the operation is successful, wherein the first depth-dependent model records the test case of each external function;
5) And outputting a compatible detection report according to the detection results of the steps 2) to 4).
As shown in fig. 2, the detailed steps of step 2) of this embodiment include:
2.1) obtaining all dependency libraries of the software to be tested to obtain a dependency library set, wherein the dependency library set not only comprises the dependency libraries on which the software to be tested directly depends, but also comprises the dependency libraries on which the software to be tested indirectly depends;
2.2) traversing and selecting a current dependent library from the dependent library set, obtaining the library name of the current dependent library, checking whether the library name of the current dependent library exists in a preset first deep dependent model, if not, skipping to execute the step 2.3), otherwise, obtaining the version, the format, the size and the digit of the current dependent library in the first deep dependent model, judging whether the version, the format, the size and the digit of the current dependent library in a target system meet the requirements, if so, judging that the compatibility check of the current dependent library is passed, otherwise, judging that the compatibility check of the current dependent library is not passed;
2.3) judging whether the traversal of the dependency library set is finished, and if not, skipping to execute the step 2.2); otherwise, skipping to execute the step 3).
as shown in fig. 3, the detailed steps of step 3) of this embodiment include:
3.1) acquiring a library package calling function list of the software to be tested;
3.2) traversing and selecting a current external function prototype from the external function prototype list, judging whether the current external function prototype has a function prototype of the same name function in a preset first depth dependence model, if so, judging that the compatibility check of the current external function prototype passes, otherwise, judging that the compatibility check of the current external function prototype does not pass;
3.3) judging whether the traversal of the external function prototype list is finished or not, and if not, skipping to execute the step 3.2); otherwise, skipping to execute step 4).
as shown in fig. 4, the detailed steps of step 4) of this embodiment include:
4.1) acquiring a library package calling function list of the software to be tested;
4.2) traversing and selecting a current external function from the external function list, judging whether the current external function has a corresponding test case in a preset first depth dependence model, if so, running the test case and judging whether the test case runs successfully, if so, judging that the compatibility check of the current external function passes, otherwise, judging that the compatibility check of the current external function does not pass;
4.3) judging whether the traversal of the external function list is finished or not, and if not, skipping to execute the step 3.2); otherwise jump to execute step 5).
In this embodiment, the first deep dependency model specifically provides an xml file for each library package therein, so as to record information such as a name, a version, a format, a number of bits, a size, an external interface function, and the like of the library package.
in this embodiment, the format of the xml file of a certain library package is as follows:
<library>
< name > libxxx </name > # library name of the library package
version of < version >1.0.0< version > # library package
all direct dependent libraries of the < entries > # library package
some direct dependent library of < parent > # library package
<name>libxxx</name>
<version>1.0.0</version>
</parent>
</parents>
<! - -list all functions in the library- - ]
all functions in < functions > # library package
Function in < function > # library package
< name > fn _ test [1.0.0] </name > # function version
Parameters of the < params > int, int, int </params > function
< return > int </return > # function return value
< side effect > when function runs, </side effect > # function
< testcase > path/to/testcase > # path of test case for function
</function>
</functions>
</library>
In addition, this embodiment further provides a software dependency package capability detecting system, which includes a program unit for determining whether software to be tested is compatible with a target system, where the program unit includes:
the input program unit is used for acquiring input software to be tested;
The dependency library checking program unit is used for acquiring all dependency libraries of the software to be tested, judging whether all the dependency libraries of the software to be tested are compatible with the target system or not according to a preset first depth dependency model, and recording dependency library information possessed by the target system by the first depth dependency model;
the external function prototype checking program unit is used for acquiring a library package calling function list of the software to be tested, and judging whether function prototypes of homonymous functions exist in each library package calling function called by the library package of the software to be tested in a preset first deep dependence model or not, wherein the first deep dependence model records function prototypes which can be called and are possessed by a target system;
the external function checking program unit is used for acquiring each external function of the software to be tested, acquiring a corresponding test case from a preset first depth-dependent model and judging whether the operation is successful or not, wherein the first depth-dependent model records the test case of each external function;
And the output program unit is used for outputting a compatible detection report according to the detection result.
in addition, the present embodiment also provides a software-dependent package capability detection system, which includes a computer device programmed or configured to execute the steps of the software-dependent package capability detection method, or a storage medium of the computer device having stored thereon a computer program programmed or configured to execute the software-dependent package capability detection method.
furthermore, the present embodiment also provides a computer-readable storage medium having stored thereon a computer program programmed or configured to execute the software dependent package capability detection method.
Example two:
this embodiment is similar to the embodiment in a way, but the technical problem to be solved is different.
As shown in fig. 5, the method for detecting the software dependency package capability of this embodiment includes a step of determining whether an interface provided by a software library to be tested is consistent with an expected function, where the step includes:
S1) acquiring input software to be tested;
S2) obtaining a library package calling function list of the software to be tested, and judging whether function prototypes of homonymous functions exist in a preset second depth dependence model of each library package calling function called by the library package of the software to be tested, wherein the second depth dependence model records an external function prototype list expected by the software to be tested;
s3) obtaining each external function of the software to be tested, obtaining a corresponding test case from a preset second depth-dependent model and judging whether the operation is successful, wherein the second depth-dependent model records an expected external function list of the software to be tested;
S4) outputs an expected function test report according to the test results of steps S2) to S3).
It should be noted that the second depth-dependent model has the same format as the first depth-dependent model of the first embodiment, and the difference point is that the first depth-dependent model of the first embodiment describes information of the target system, and the second depth-dependent model of the embodiment describes information expected by the software to be tested, so details are not repeated here.
in this embodiment, the detailed step of step S2) includes:
s2.1) acquiring a library package calling function list of the software to be tested;
s2.2) traversing and selecting a current external function prototype from the external function prototype list, judging whether the current external function prototype has a function prototype of a homonymous function in a preset second depth-dependent model, if so, judging that the current external function prototype is consistent with an expected function, otherwise, judging that the current external function prototype is inconsistent with the expected function;
s2.3) judging whether the traversal of the external function prototype list is finished or not, and if not, skipping to execute the step 3.2); otherwise jump to step S3).
In this embodiment, the detailed steps of step 4) include:
s3.1) acquiring a library package calling function list of the software to be tested;
S3.2) traversing and selecting a current external function from the external function list, judging whether the current external function has a corresponding test case in a preset second depth dependence model, if so, running the test case and judging whether the test case is successfully run, if so, judging that the current external function is consistent with an expected function, otherwise, judging that the current external function is inconsistent with the expected function;
S3.3) judging whether the traversal of the external function list is finished or not, and if not, skipping to execute the step S3.2); otherwise jump to step S4).
It should be noted that the test case may be compiled and then run by using a call compiler according to needs, or may be interpreted and run by using a call interpreter, which is specifically related to the development language of the function.
In addition, this embodiment further provides a software dependency package capability detection system, including a program unit for determining whether an interface provided by a software library to be tested is consistent with an expected function, where the program unit includes:
the input program unit is used for acquiring input software to be tested;
the external function prototype checking program unit is used for acquiring a library package calling function list of the software to be tested, judging whether function prototypes of the homonymous functions exist in each library package calling function called by the library package of the software to be tested in a preset second depth dependence model or not, and recording an expected external function prototype list of the software to be tested by the second depth dependence model;
The external function checking program unit is used for acquiring each external function of the software to be tested, acquiring a corresponding test case from a preset second depth-dependent model and judging whether the operation is successful, wherein the second depth-dependent model records an expected external function list of the software to be tested;
and the output program unit is used for outputting an expected function detection report according to the detection result.
in addition, the present embodiment also provides a software-dependent package capability detection system, which includes a computer device programmed or configured to execute the steps of the software-dependent package capability detection method, or a storage medium of the computer device having stored thereon a computer program programmed or configured to execute the software-dependent package capability detection method.
furthermore, the present embodiment also provides a computer-readable storage medium having stored thereon a computer program programmed or configured to execute the software dependent package capability detection method.
Example three:
In this embodiment, the functions of the first embodiment and the second embodiment are actually reused in a modular manner, so that the functions of the first embodiment and the second embodiment are integrated. On this basis, the present embodiment provides a method for detecting and analyzing the minimum required library package set during the operation of the software library package, so as to determine whether the software library package can normally operate on an operating system of a certain version. The adopted specific technical means comprises the steps of judging whether a target operating system can compatibly install a software library package by checking whether the library package depended on by the software library package exists in the target operating system or not and comparing whether the version, the number of bits, the format, the size and the like of the library package are compatible with the target operating system or not; meanwhile, the software library package can be judged whether to run compatibly by carrying out data detection and capability detection on the external interface function of the library package and checking the functional consistency among the library package versions.
In this embodiment, the following reusable functional modules are implemented for the first embodiment and the second embodiment:
1. A first module: packet deep dependency detection for function libraries and software packages, i.e., the correlation step of step 2) of embodiment one: and acquiring all the dependency libraries of the software to be tested, and judging whether all the dependency libraries of the software to be tested are compatible with the target system or not according to a preset first depth dependency model.
2. and a second module: for the external function prototype detection, step 3) of the first embodiment and step S2) of the second embodiment are used only in the difference of the called depth-dependent model.
3. And a third module: for external function detection, step 4) of the first embodiment and step S3) of the second embodiment are used only in the difference of the called depth-dependent model.
it should be noted that in this embodiment, the first depth-dependent model and the second depth-dependent model may adopt a single model, or may adopt independent models as needed.
the above description is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments, and all technical solutions belonging to the idea of the present invention belong to the protection scope of the present invention. It should be noted that modifications and embellishments within the scope of the invention may occur to those skilled in the art without departing from the principle of the invention, and are considered to be within the scope of the invention.

Claims (10)

1. a method for detecting the capability of a software dependent package is characterized by comprising the step of judging whether software to be tested is compatible with a target system or not, wherein the step comprises the following steps:
1) Acquiring input software to be tested;
2) acquiring all dependency libraries of software to be tested, and judging whether all dependency libraries of the software to be tested are compatible with a target system or not according to a preset first depth dependency model, wherein the first depth dependency model records dependency library information of the target system;
3) acquiring a library package calling function list of software to be tested, and judging whether function prototypes of homonymous functions exist in each library package calling function called by the library package of the software to be tested in a preset first deep dependence model, wherein the first deep dependence model records function prototypes which can be called and are possessed by a target system;
4) Acquiring each external function of software to be tested, acquiring a corresponding test case from a preset first depth-dependent model and judging whether the operation is successful, wherein the first depth-dependent model records the test case of each external function;
5) and outputting a compatible detection report according to the detection results of the steps 2) to 4).
2. the software dependency package capability detecting method as claimed in claim 1, wherein the detailed step of step 2) comprises:
2.1) obtaining all the dependency libraries of the software to be tested to obtain a dependency library set;
2.2) traversing and selecting a current dependent library from the dependent library set, obtaining the library name of the current dependent library, checking whether the library name of the current dependent library exists in a preset first deep dependent model, if not, skipping to execute the step 2.3), otherwise, obtaining the version, the format, the size and the digit of the current dependent library in the first deep dependent model, judging whether the version, the format, the size and the digit of the current dependent library in a target system meet the requirements, if so, judging that the compatibility check of the current dependent library is passed, otherwise, judging that the compatibility check of the current dependent library is not passed;
2.3) judging whether the traversal of the dependency library set is finished, and if not, skipping to execute the step 2.2); otherwise, skipping to execute the step 3).
3. The software dependency package capability detecting method as claimed in claim 1, wherein the detailed step of step 3) comprises:
3.1) acquiring a library package calling function list of the software to be tested;
3.2) traversing and selecting a current external function prototype from the external function prototype list, judging whether the current external function prototype has a function prototype of the same name function in a preset first depth dependence model, if so, judging that the compatibility check of the current external function prototype passes, otherwise, judging that the compatibility check of the current external function prototype does not pass;
3.3) judging whether the traversal of the external function prototype list is finished or not, and if not, skipping to execute the step 3.2); otherwise, skipping to execute step 4).
4. The software dependency package capability detecting method as claimed in claim 1, wherein the detailed step of step 4) comprises:
4.1) acquiring a library package calling function list of the software to be tested;
4.2) traversing and selecting a current external function from the external function list, judging whether the current external function has a corresponding test case in a preset first depth dependence model, if so, running the test case and judging whether the test case runs successfully, if so, judging that the compatibility check of the current external function passes, otherwise, judging that the compatibility check of the current external function does not pass;
4.3) judging whether the traversal of the external function list is finished or not, and if not, skipping to execute the step 3.2); otherwise jump to execute step 5).
5. a method for detecting software dependency package capability is characterized by comprising a step of judging whether an interface provided by a software library to be tested is consistent with an expected function, wherein the step comprises the following steps:
s1) acquiring input software to be tested;
s2) obtaining a library package calling function list of the software to be tested, and judging whether function prototypes of homonymous functions exist in a preset second depth dependence model of each library package calling function called by the library package of the software to be tested, wherein the second depth dependence model records an external function prototype list expected by the software to be tested;
s3) obtaining each external function of the software to be tested, obtaining a corresponding test case from a preset second depth-dependent model and judging whether the operation is successful, wherein the second depth-dependent model records an expected external function list of the software to be tested;
S4) outputs an expected function test report according to the test results of steps S2) to S3).
6. The software dependency package capability detecting method as claimed in claim 5, wherein the detailed step of step S2) includes:
s2.1) acquiring a library package calling function list of the software to be tested;
S2.2) traversing and selecting a current external function prototype from the external function prototype list, judging whether the current external function prototype has a function prototype of a homonymous function in a preset second depth-dependent model, if so, judging that the current external function prototype is consistent with an expected function, otherwise, judging that the current external function prototype is inconsistent with the expected function;
S2.3) judging whether the traversal of the external function prototype list is finished or not, and if not, skipping to execute the step 3.2); otherwise jump to step S3).
7. The software dependency package capability detecting method as claimed in claim 5, wherein the detailed step of step 4) comprises:
s3.1) acquiring a library package calling function list of the software to be tested;
s3.2) traversing and selecting a current external function from the external function list, judging whether the current external function has a corresponding test case in a preset second depth dependence model, if so, running the test case and judging whether the test case is successfully run, if so, judging that the current external function is consistent with an expected function, otherwise, judging that the current external function is inconsistent with the expected function;
s3.3) judging whether the traversal of the external function list is finished or not, and if not, skipping to execute the step S3.2); otherwise jump to step S4).
8. a software dependency package capability detection system comprising a program element for determining whether software to be tested is compatible with a target system, the program element comprising:
the input program unit is used for acquiring input software to be tested;
the dependency library checking program unit is used for acquiring all dependency libraries of the software to be tested, and judging whether all the dependency libraries of the software to be tested are compatible with the target system or not according to a preset first depth dependency model, wherein the first depth dependency model records dependency library information of the target system;
The external function prototype checking program unit is used for acquiring a library package calling function list of the software to be tested, and judging whether function prototypes of homonymous functions exist in each library package calling function called by the library package of the software to be tested in a preset first deep dependence model or not, wherein the first deep dependence model records function prototypes which can be called and are possessed by a target system;
the external function checking program unit is used for acquiring each external function of the software to be tested, acquiring a corresponding test case from a preset first depth-dependent model and judging whether the operation is successful, wherein the first depth-dependent model records the test case of each external function;
and the output program unit is used for outputting a compatible detection report according to the detection result.
9. A software dependency package capability detection system comprising a computer device, characterized in that the computer device is programmed or configured to perform the steps of the software dependency package capability detection method of any one of claims 1 to 7, or that a storage medium of the computer device has stored thereon a computer program programmed or configured to perform the software dependency package capability detection method of any one of claims 1 to 7.
10. a computer-readable storage medium having stored thereon a computer program programmed or configured to perform the software dependent package capability detection method of any one of claims 1 to 7.
CN201910838012.4A 2019-09-05 2019-09-05 Software dependence package capability detection method, system and medium Active CN110543423B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910838012.4A CN110543423B (en) 2019-09-05 2019-09-05 Software dependence package capability detection method, system and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910838012.4A CN110543423B (en) 2019-09-05 2019-09-05 Software dependence package capability detection method, system and medium

Publications (2)

Publication Number Publication Date
CN110543423A true CN110543423A (en) 2019-12-06
CN110543423B CN110543423B (en) 2022-12-30

Family

ID=68712549

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910838012.4A Active CN110543423B (en) 2019-09-05 2019-09-05 Software dependence package capability detection method, system and medium

Country Status (1)

Country Link
CN (1) CN110543423B (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111008152A (en) * 2019-12-26 2020-04-14 中国人民解放军国防科技大学 Kernel module compatibility influence domain analysis method, system and medium based on function dependency graph
CN111399830A (en) * 2020-03-16 2020-07-10 北京五八信息技术有限公司 Application program capacity monitoring method and device, electronic equipment and storage medium
CN112104736A (en) * 2020-09-17 2020-12-18 广州汽车集团股份有限公司 OTA-based multi-ECU upgrading method
CN112328494A (en) * 2020-11-26 2021-02-05 浪潮电子信息产业股份有限公司 Compatibility detection method, device, equipment and readable storage medium
CN115934157A (en) * 2022-12-28 2023-04-07 中国人民解放军国防科技大学 Software dependency range automatic inference method, device, computer equipment and memory

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1987797A (en) * 2005-12-23 2007-06-27 国际商业机器公司 Method and system for avoiding software conflict
CN102073582A (en) * 2010-07-30 2011-05-25 兰雨晴 Conflict-based method for checking dependency of software package
CN102073583A (en) * 2010-07-30 2011-05-25 兰雨晴 Method for checking software package dependency relationship based on dependency
US20170060560A1 (en) * 2015-08-26 2017-03-02 Bank Of America Corporation Software and associated hardware regression and compatiblity testing system
CN108549605A (en) * 2018-04-13 2018-09-18 郑州云海信息技术有限公司 A kind of automated testing method
CN109726136A (en) * 2019-01-28 2019-05-07 上海达梦数据库有限公司 Test method, device, equipment and the storage medium of database

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1987797A (en) * 2005-12-23 2007-06-27 国际商业机器公司 Method and system for avoiding software conflict
CN102073582A (en) * 2010-07-30 2011-05-25 兰雨晴 Conflict-based method for checking dependency of software package
CN102073583A (en) * 2010-07-30 2011-05-25 兰雨晴 Method for checking software package dependency relationship based on dependency
US20170060560A1 (en) * 2015-08-26 2017-03-02 Bank Of America Corporation Software and associated hardware regression and compatiblity testing system
CN108549605A (en) * 2018-04-13 2018-09-18 郑州云海信息技术有限公司 A kind of automated testing method
CN109726136A (en) * 2019-01-28 2019-05-07 上海达梦数据库有限公司 Test method, device, equipment and the storage medium of database

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111008152A (en) * 2019-12-26 2020-04-14 中国人民解放军国防科技大学 Kernel module compatibility influence domain analysis method, system and medium based on function dependency graph
CN111008152B (en) * 2019-12-26 2022-10-11 中国人民解放军国防科技大学 Kernel module compatibility influence domain analysis method, system and medium based on function dependency graph
CN111399830A (en) * 2020-03-16 2020-07-10 北京五八信息技术有限公司 Application program capacity monitoring method and device, electronic equipment and storage medium
CN112104736A (en) * 2020-09-17 2020-12-18 广州汽车集团股份有限公司 OTA-based multi-ECU upgrading method
CN112328494A (en) * 2020-11-26 2021-02-05 浪潮电子信息产业股份有限公司 Compatibility detection method, device, equipment and readable storage medium
CN112328494B (en) * 2020-11-26 2022-02-18 浪潮电子信息产业股份有限公司 Compatibility detection method, device, equipment and readable storage medium
WO2022110863A1 (en) * 2020-11-26 2022-06-02 浪潮电子信息产业股份有限公司 Compatibility detection method and apparatus, device, and readable storage medium
CN115934157A (en) * 2022-12-28 2023-04-07 中国人民解放军国防科技大学 Software dependency range automatic inference method, device, computer equipment and memory
CN115934157B (en) * 2022-12-28 2024-04-16 中国人民解放军国防科技大学 Automatic software dependency range deducing method, device, computer equipment and memory

Also Published As

Publication number Publication date
CN110543423B (en) 2022-12-30

Similar Documents

Publication Publication Date Title
CN110543423B (en) Software dependence package capability detection method, system and medium
KR100868762B1 (en) Method of error detecting method for embedded sofeware
US7284237B2 (en) Testing flow control at test assertion level
CN106020873B (en) Patch package loading method and device
US7882495B2 (en) Bounded program failure analysis and correction
CN111026601A (en) Monitoring method and device for Java application system, electronic equipment and storage medium
KR20060045072A (en) Test case inheritance controlled via attributes
US20080133977A1 (en) Non-stop debugging apparatus for correcting errors in embedded systems and method thereof
CN112181858B (en) Automatic detection method for Java software project dependent conflict semantic consistency
US9405906B1 (en) System and method for enhancing static analysis of software applications
CN109614107B (en) Integration method and device of software development kit
CN103186463B (en) Determine the method and system of the test specification of software
CN111176722A (en) Method and device for detecting file version of third-party library and storage medium
US20180032735A1 (en) System and method for enhancing static analysis of software applications
CN112925524A (en) Method and device for detecting unsafe direct memory access in driver
US20080127118A1 (en) Method and system for dynamic patching of software
KR102141287B1 (en) Fault injection test method and system for vehicle software based on autosar
KR20190128457A (en) Testing method and apparatus of target function incluede in target program
CN102169458A (en) Software accuracy verification system and method for automobile electric control component
CN110286912B (en) Code detection method and device and electronic equipment
CN113127367B (en) Defect detection method for Android dynamic permission application
EP2885712A1 (en) Imperative attribution for elements in managed runtimes
KR102042996B1 (en) Method and apparatus for measuring code coverage not by using probes and computer readable recording medium having program the same
Rao et al. Mutation testing based evaluation of formal verification tools
CN115145595A (en) Dependency library installation method and device, server, electronic equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant