Overlay installation verification method, device and computer readable storage medium

Abstract

Embodiments of the present application disclose a kind of covering installation verification method, device and computer readable storage medium;By obtaining the installation data package of target version corresponding to application program and verification component data from server;According to installation data package, the target version of application program is carried out covering installation processing, and verification component data is generated according to verification component;Matching target event source is filtered out in the preset event source set based on verification component;At least one type of verification processing is carried out to target event source, and verification result is obtained;Based on verification result, the covering installation of application program is verified.Therefore, when the target version of application program is carried out covering installation processing, verification component is generated, and multiple target event sources are matched based on verification component, so that multiple types of verification are carried out when the application program is carried out covering installation, the security in the process of application program covering installation is improved, and then the efficiency of covering installation is improved.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and specifically to a method, apparatus and computer-readable storage medium for covering installation verification. Background Technology

[0002] In recent years, with the rapid development of internet technology, applications have become increasingly widespread. To meet the needs of technological updates and changing product requirements, developers frequently need to upgrade their applications. During the overwrite installation process of upgrading an application from an older version to a newer one, verification is required to ensure the new version runs correctly. Most existing overwrite installation verification methods compare the database information of the old and new versions of the application, and determine whether the relevant functions in the new version are working properly based on the comparison results, thus ensuring the successful completion of the overwrite installation.

[0003] Research and practice on existing technologies have revealed that existing methods for verifying application version upgrades through comparative database information cannot verify the security of applications during the overwrite installation process. This results in low security during application overwrite installation and consequently, low efficiency in the overwrite installation process. Summary of the Invention

[0004] This application provides an overlay installation verification method, apparatus, and computer-readable storage medium, which can improve the security of the application overlay installation process and thus improve the efficiency of overlay installation.

[0005] This application provides an overlay installation verification method, including:

[0006] Retrieve the installation data package and verification component data for the target version of the application from the server;

[0007] The application is installed over the target version according to the installation data package, and a verification component corresponding to the application is generated according to the verification component data.

[0008] Based on the verification component, a matching target event source is selected from the preset event source set;

[0009] Perform at least one type of verification process on the target event source to obtain the verification result;

[0010] The application's overwrite installation is verified based on the verification results.

[0011] Accordingly, this application provides a cover installation verification device suitable for terminals, including:

[0012] The acquisition unit is used to obtain the installation data package for the target version of the application and the verification component data from the server.

[0013] The installation unit is used to perform a target version overwrite installation of the application according to the installation data package, and to generate a verification component corresponding to the application according to the verification component data.

[0014] A filtering unit is used to filter out matching target event sources from a preset event source set based on the verification component;

[0015] An execution unit is used to perform at least one type of verification processing on the target event source to obtain a verification result;

[0016] A verification unit is used to verify the overwrite installation of the application based on the verification result.

[0017] In one embodiment, the execution unit includes:

[0018] The type parameter acquisition subunit is used to obtain the project variable information corresponding to the application from the server, and extract the verification type parameter from the project variable information;

[0019] The verification type identification subunit is used to identify at least one verification type that matches the target event source from a preset verification type set according to the type parameter;

[0020] The execution subunit is used to perform verification processing on the target event source based on the verification type, and obtain the verification result corresponding to each verification type.

[0021] In one embodiment, the execution subunit includes:

[0022] The data security verification module is used to perform data security verification on the target event source when the verification type corresponding to the target event source is data security verification type, and obtain the data security verification result.

[0023] The event triggering logic verification module is used to perform event triggering logic verification on the target event source when the verification type corresponding to the target event source is the event triggering logic verification type, and obtain the event triggering logic verification result;

[0024] The software development kit update verification module is used to perform software development kit update verification on the target event source when the verification type corresponding to the target event source is software development kit update verification type, and obtain the software package update verification result.

[0025] The verification result determination module is used to determine the verification result based on the data security verification result, the event-triggered logic verification result, and the software package update verification result.

[0026] In one embodiment, the data security verification module includes:

[0027] The interface data attribute acquisition submodule is used to acquire the interface data attributes of the interface corresponding to the target event source;

[0028] The interface input parameter determination submodule is used to determine the interface input parameters based on the interface data attributes and the preset data security verification type.

[0029] The data security verification result determination submodule is used to call the interface corresponding to the target event source based on the interface input parameters, and determine the data security verification result based on the call result.

[0030] In one embodiment, the event-triggered logic verification module includes:

[0031] An interactive instruction set acquisition submodule is used to acquire an interactive instruction set, which includes at least one interactive instruction and the expected execution result corresponding to the interactive instruction.

[0032] The execution submodule is used to execute the target event source based on the interactive instructions and record the call stack corresponding to the target event source after execution;

[0033] The comparison submodule is used to compare the call stack with the expected execution result to obtain the event triggering logic verification result.

[0034] In one embodiment, the mounting unit includes:

[0035] The part-of-speech analysis subunit is used to extract character data from the verification component data and perform part-of-speech analysis on the character data to obtain the tag data corresponding to the character data.

[0036] The syntax analysis subunit is used to perform syntax analysis on the marked data and construct code structure information based on the syntax analysis results;

[0037] The verification component construction subunit is used to construct the verification component corresponding to the application based on the code structure information.

[0038] In one embodiment, the acquisition unit includes:

[0039] The data acquisition subunit is used to acquire verification component data and obtain the project variable information corresponding to the application from the server when it receives an application overwrite installation request for the target version.

[0040] The data packet search subunit is used to extract the version field from the project variable information and search the local storage for the installation data packet of the target version of the application based on the version field.

[0041] The installation data package retrieval subunit is used to extract the file path information corresponding to the installation data package from the project variable information when the installation data package is not found, and retrieve the installation data package based on the file path information.

[0042] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute steps in any of the overwrite installation verification methods provided in embodiments of this application.

[0043] Furthermore, this application also provides a computer device, including a processor and a memory, wherein the memory stores an application program, and the processor is used to run the application program in the memory to implement the overwrite installation verification method provided in this application.

[0044] This application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps in the overlay installation verification method provided in this application.

[0045] This application embodiment obtains the installation data package and verification component data corresponding to the target version of the application from the server; performs a target version overwrite installation of the application based on the installation data package, and generates a verification component corresponding to the application based on the verification component data; filters matching target event sources from a preset event source set based on the verification component; performs at least one type of verification processing on the target event sources to obtain verification results; and verifies the overwrite installation of the application based on the verification results. Thus, by generating a verification component during the target version overwrite installation of the application, and matching multiple target event sources based on the verification component, various types of verification processing are performed on the target event sources, achieving multiple types of security verification during the overwrite installation of the application, improving the security of the application overwrite installation process, and thereby increasing the efficiency of the overwrite installation. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a schematic diagram illustrating an implementation scenario of an overlay installation verification method provided in this application embodiment;

[0048] Figure 2 This is a flowchart illustrating an overlay installation verification method provided in an embodiment of this application;

[0049] Figure 3 This is a schematic diagram illustrating the specific framework of an overlay installation verification method provided in an embodiment of this application;

[0050] Figure 4 This is a schematic diagram of the overall process of an overlay installation verification method provided in an embodiment of this application;

[0051] Figure 5 This is a schematic diagram of a tag branch in an overlay installation verification method provided in an embodiment of this application;

[0052] Figure 6 This is another flowchart illustrating an overlay installation verification method provided in an embodiment of this application;

[0053] Figure 7 This is a schematic diagram of the structure of the cover installation verification device provided in the embodiments of this application;

[0054] Figure 8 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0055] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0056] This application provides an overlay installation verification method, apparatus, and computer-readable storage medium. The overlay installation verification apparatus can be integrated into a computer device, which may be a server or a terminal, etc.

[0057] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN) acceleration services, and big data and artificial intelligence platforms. The terminal can include, but is not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0058] Please see Figure 1 Taking the integration of a cover installation verification device into a computer device as an example, Figure 1 This is a schematic diagram illustrating an implementation scenario of the overwrite installation verification method provided in this application. The computer device can be a terminal. The computer device can obtain installation data packets and verification component data corresponding to the target version of the application from the server; perform overwrite installation processing on the application based on the installation data packets, and generate a verification component corresponding to the application based on the verification component data; filter matching target event sources from a preset event source set based on the verification component; perform at least one type of verification processing on the target event sources to obtain verification results; and verify the overwrite installation of the application based on the verification results.

[0059] It should be noted that, Figure 1 The illustrated scenario of the coverage installation verification method is merely an example. The implementation environment scenario of the coverage installation verification method described in this application is for the purpose of more clearly illustrating the technical solution of this application and does not constitute a limitation on the technical solution provided in this application. Those skilled in the art will understand that with the evolution of coverage installation and the emergence of new business scenarios, the technical solution provided in this application is also applicable to similar technical problems.

[0060] The solutions provided in this application are specifically illustrated through the following embodiments. It should be noted that the order of description of the following embodiments is not intended to limit the preferred order of the embodiments.

[0061] This embodiment will be described from the perspective of an overlay installation verification device, which can be integrated into a computer device, which can be a terminal, and this application does not limit it.

[0062] Please see Figure 2 , Figure 2 This is a flowchart illustrating the overlay installation verification method provided in an embodiment of this application. The overlay installation verification method includes:

[0063] In step 101, the installation data package for the target version of the application and the verification component data are obtained from the server.

[0064] Here, the application can be the application to be upgraded, the target version can be the version of the application to be upgraded to, the installation package can be the binary package of the target version of the application, the verification component data can be data including pre-written source code for creating the verification component, a source code file (.cpp file, source code file written in C++) can be generated based on the verification component data, the .cpp file can be a configuration file including the source code for generating the verification component, the verification component is created through the source code file, the installation package is pulled and the verification component is inserted into the installation package, and the verification component data can be a plugin built into the installation package for performing security verification during the overwrite installation of the installation package of the target version of the application.

[0065] Overwrite installation refers to reinstalling the software from scratch, fixing bugs and other issues. For newly installed users, data storage is unaffected by the migration of old data because newly installed applications don't have prior data. However, overwrite installations require data migration after upgrading from an older version to a newer one. Therefore, security during overwrite installations requires more robust mechanisms. For example, please refer to [reference needed]. Figure 3 , Figure 3 This is a schematic diagram of a specific framework for an overwrite installation verification method provided in this application embodiment. During the overwrite installation process of upgrading an old version to a new version, hook files (gitHook) and verification modules (i.e. verification components) can be used to realize the migration of old data and security verification such as event triggering and interface compatibility. After the verification is passed, the corresponding binary package is packaged out for users to download and use.

[0066] There are several ways to obtain the installation data package and verification component data corresponding to the target version of the application from the server. For example, when a request to overwrite the target version of the application is received, the verification component data can be obtained, and the project variable information corresponding to the application can be obtained from the server. The version field can be extracted from the project variable information, and the installation data package corresponding to the target version of the application can be searched in the local storage based on the version field. If the installation data package is not found, the file path information corresponding to the installation data package can be extracted from the project variable information, and the installation data package can be retrieved based on the file path information.

[0067] The overwrite installation request can be a request to overwrite the application with the target version. The project variable information can be the variable information of the development project corresponding to the application. This project variable information can be obtained from the server via a network protocol, for example, using Hypertext Transfer Protocol (HTTP). Optional, please refer to... Figure 4 , Figure 4 This is a schematic diagram of the overall process of an overlay installation verification method provided in an embodiment of this application. A hook script file (hook.yml file) can be created in the development project corresponding to the application. This hook script file can be a pre-designed script file used to detect branch push operations triggered for the project corresponding to the application and to configure project variable information in the project. The version field can be a field that includes the version information of the application's installation data package, and the file path information can be information including the storage path of the installation data package.

[0068] In one embodiment, the engineering variable information can be represented as:

[0069]

[0070]

[0071] Therefore, upon receiving an application's request to overwrite the target version, verification component data can be obtained, and the application's corresponding project variable information can be retrieved from the server. The version field can be extracted from this project variable information, and the installation data package for the target version of the application can be searched for in local storage based on this version field. If the installation data package is not found, i.e., the target version's installation data package has not been downloaded locally, the file path information corresponding to the installation data package can be obtained from the configuration file path (ep_entry_file_path) field in the project variable information, and the installation data package can be retrieved based on this file path information. The configuration file path field can store the installation data package, or, if the installation data package is large, the download address of the installation data package can be configured in the configuration file path field.

[0072] There are several ways to retrieve the installation data package based on the file path information. For example, the target version's installation data package can be found based on the file path information, and then a downloader can be started using a thread tool (pthread) to download the installation data package. After the download is complete, a version folder corresponding to the target version's installation data package can be created first, and finally the installation data package can be stored in that version folder. Then, the target version's installation data package can be retrieved from that version folder for overwriting installation.

[0073] In one embodiment, based on the overlay installation verification method for terminals provided in this application, a corresponding overlay installation verification method for servers can be provided. Please continue to refer to... Figure 4 The method may include: obtaining target program code; constructing an installation data package for the target version of the application based on the target program code; generating a tag branch for the target version based on the commit node corresponding to the target program code, and storing the installation data package based on the tag branch; receiving a data package retrieval request sent by a terminal, and sending the installation data package to the terminal based on the data package retrieval request.

[0074] The target program code can be the program code corresponding to the target version of the application. The commit node can be the node in the distributed workflow of the application's project that triggers the branch push operation. During project development, the development team generally uses a distributed version control system (git) to manage the application's code. The branch push operation (git push) can be used to upload and merge the local branch version to the remote repository, that is, to push the code currently committed to the local git repository to a remote branch on the remote host. The hook file (git Hook) can trigger a custom script when a pre-defined important action occurs. For example, when a developer triggers the git push command, the script in the hook script file can be triggered to check the execution of the script. The tagged branch can be a branch in the application's local git repository that is tagged and marked as the target version of the application's code. It can refer to the most recent commit node when the application released a version for the target version. The data package retrieval request can be a request sent by the terminal to retrieve the installation data package.

[0075] The process involves obtaining the target program code, constructing an installation package for the target version of the application based on that code, generating a tag branch for the target version based on the commit node corresponding to the target program code, and storing the installation package on that tag branch. There are several ways to do this. For example, the target program code can be obtained when a developer triggers a `git push` command to commit the application's code for the target version. When the currently executed branch push operation requires the script to generate a binary package (i.e., an installation package), the script can construct the installation package for the target version of the application based on the target program code, automatically generate a tag branch, and store the installation package in the configuration file path. If the installation package is large, the download address can be configured in the configuration file path field. Optional, please refer to... Figure 5 , Figure 5 This diagram illustrates a tag branching method for overlay installation verification provided in this application. A tag branch can be generated at the most recent commit node during program release to store the installation data package. For example, when generating application version 1.0, a tag branch can be generated at the most recent commit node (tag 1.0) to store the installation data package; when generating application version 1.1, a tag branch can be generated at the most recent commit node (tag 1.1); and when generating application version 1.2, a tag branch can be generated at the most recent commit node (tag 1.2) to store the installation data package. When generating the tag branch, the baseline version number of a specific version can be customized by configuring the baseline type and baseline version. Therefore, during development and testing of overlay installation, the corresponding version's installation data package can be retrieved and installed based on the configured version number. After successful installation, compilation and execution can then proceed.

[0076] There are several ways to send the installation data package to the terminal based on the data package acquisition request. For example, the project variable information configured in the hook script file (hook.yml file) built into the project corresponding to the application can be sent to the terminal so that the terminal can extract the storage path of the installation data package based on the configuration file path in the project variable information. Thus, the terminal can obtain the installation data package of the target version according to the storage path of the installation data package.

[0077] In step 102, the application is overwritten with the target version based on the installation data package, and a verification component corresponding to the application is generated based on the verification component data.

[0078] There are several ways to perform target version overwrite installation of the application based on the installation package and generate the corresponding verification component based on the verification component data. For example, a lightweight compiler (clang) developed based on the Low Level Virtual Machine (LLVM) can be used to write the plugin source code corresponding to the verification component, i.e., the cpp file in the verification component data. Based on the cpp file, the corresponding plugin, i.e., the verification component, can be created and inserted into the installation package. The content of the cpp file can be add_llvm_loadable_module. During the compilation of the cpp file, the target version of the installation package can be obtained, the verification component can be inserted into the installation package, and the installation package can be downloaded to the terminal for installation.

[0079] There are several ways to generate the corresponding verification component for the application based on the verification component data. For example, character data can be extracted from the verification component data, and part-of-speech analysis can be performed on the character data to obtain the tag data corresponding to the character data. Syntax analysis can be performed on the tag data, and code structure information can be constructed based on the syntax analysis results. Based on the code structure information, the corresponding verification component for the application can be constructed.

[0080] The character data can be text in the validation component data, such as letters, words, Chinese characters, numbers, etc. The tag data can be data obtained after part-of-speech analysis of the character data. The code structure information can be information representing the grammatical structure in the tag data. For example, the code structure information can be information about the syntax tree structure, such as the Abstract Syntax Tree, which represents the syntax structure of the programming language in the validation component data in a tree-like form.

[0081] Specifically, the character data in the validation component data can be parsed, and then part-of-speech analysis (also known as scanning) can be performed on this character data. This involves converting all words or characters in the interface definition file into tokens according to predetermined rules. Simultaneously, whitespace, comments, etc., are removed. Ultimately, the character data in the entire validation component data is segmented into a token list, generating corresponding token data. Then, syntax analysis can be performed on this token data, converting the token list obtained from the lexical analysis into a tree structure. Syntax verification can also be performed, and unnecessary tokens, such as incomplete parentheses, can be removed. Based on the syntax analysis results, the code structure information corresponding to the validation component data can be obtained, and the validation component for the application can be built based on this code structure information.

[0082] In step 103, the matching target event source is selected from the preset event source set based on the verification component.

[0083] The preset event source set can be a pre-defined set of event sources, consisting of at least one event source. Each event source can be an object that triggers an event, referring to a specific component. For example, if a user clicks a button component, that button component becomes the event source. Optionally, the event sources in the preset event source set can be program fragments from the target version's installation data package, such as functions. The target event source can be an event source selected from the preset event source set by the verification component. After the application download is complete on the terminal device, a callback can be executed in the cpp file of the verification component data to continue compiling the source code and then executing the verification component. The built-in detection script in the verification component can be used to input events into the application and store the callback messages executed by the application in the terminal for security verification of the overwrite installation based on the callback messages. The verification component can include protocol types, variable arrays, and anonymous functions. After executing the detection script in the verification component, the corresponding target event source can be matched according to the protocol type in the verification component. After performing arithmetic or logical operations on the target event source, the execution result can be placed in a variable array, and then the anonymous function can call back the information in the variable array to the verification module.

[0084] There are several ways to filter matching target event sources from a preset event source set based on the verification component. For example, matching target event sources can be filtered from the preset event source set based on the protocol type in the verification component. The protocol type can be a pre-defined protocol rule used to filter matching target event sources from the preset event source set. The protocol type can include various pre-designed protocol methods. When the script in the verification component is executed, the code segment that needs to be verified can be determined in the corresponding code segment of the application by implementing the protocol method, thus filtering out matching target event sources from the preset event source set.

[0085] In step 104, at least one type of verification processing is performed on the target event source to obtain the verification result.

[0086] The verification result can be the result obtained after performing at least one type of verification processing on the target event source. For example, it can be the execution result obtained by executing the target event source based on different verification types. For instance, when verifying whether the function corresponding to the target event source has data security, the input parameters can be adjusted and input to the target execution target event source. The corresponding execution result can be obtained based on the input parameters, i.e. whether it is within the specified value range. Thus, the verification result of this verification type can be obtained based on whether the execution result is correct.

[0087] There are several ways to perform at least one type of verification processing on the target event source. For example, the project variable information corresponding to the application can be obtained from the server, and the verification type parameter can be extracted from the project variable information. Based on the type parameter, at least one verification type matching the target event source can be identified in the preset verification type set. The target event source can be verified based on the verification type to obtain the verification result corresponding to each verification type.

[0088] The parameter type can be a parameter that determines the verification type corresponding to the target event source. The preset verification type set can be a whole consisting of at least one pre-defined verification type. This verification type can be a type of security verification performed during the overwrite installation of the target version of the application. For example, it can include verification types such as data security verification, event triggering logic verification, and software development kit (SDK) update verification. Data security verification can be used to verify whether the target version of the application correctly identifies data constraints during operation. For example, it verifies whether the target version of the application correctly handles null checks, data compatibility, and value range processing, thereby ensuring the security of the target version of the application during data processing. Event triggering logic verification can be used to verify whether the event triggering logic of the target version of the application is normal during operation. Software development kit update verification can be used to verify whether the interface calls and other functions of the updated software development kit (SDK) of the target version of the application are normal during operation.

[0089] There are several ways to extract the verification type parameter from the project variable information and identify at least one verification type matching the target event source from the preset verification type set based on the type parameter. For example, the server can obtain the project variable information from the hook script file (hook.yml file) created in the project corresponding to the application. The verification type parameter can be extracted from the rule field (RULE) in the project variable information. The type parameter can be a pre-designed protocol rule used to determine the verification type corresponding to the target event source. Thus, at least one verification type matching each target event source can be identified from the preset verification type set based on the verification parameter.

[0090] After identifying at least one verification type matching the target event source from the preset verification type set based on the type parameter, the target event source can be verified based on the verification type to obtain the verification result corresponding to each verification type. There are several ways to verify the target event source based on the verification type. For example, if the verification type corresponding to the target event source is data security verification, data security verification can be performed on the target event source to obtain a data security verification result; if the verification type corresponding to the target event source is event triggering logic verification, event triggering logic verification can be performed on the target event source to obtain an event triggering logic verification result; if the verification type corresponding to the target event source is software development kit (SDK) update verification, software development kit (SDK) update verification can be performed on the target event source to obtain a software package update verification result; and the verification result is determined based on the data security verification result, the event triggering logic verification result, and the software package update verification result.

[0091] Specifically, the data security verification result can be the result obtained by performing data security verification on the target event source, the event triggering logic verification result can be the result obtained by performing event triggering logic verification on the target event source, and the software package update verification result can be the result obtained by performing software development kit update verification on the target event source.

[0092] There are several ways to perform data security verification on the target event source. For example, the interface data attributes of the interface corresponding to the target event source can be obtained, the interface input parameters can be determined according to the interface data attributes and the preset data security verification type, the interface corresponding to the target event source can be called based on the interface input parameters, and the data security verification result can be determined based on the call result.

[0093] The interface data attributes can be attributes of the data contained in the interface corresponding to the target event source. For example, they can include attribute information such as the value range of the interface data, data type requirements, and whether it is null. Data types can include strings, integers, floating-point types, pointers, functions, etc. The preset data security verification type can be a pre-defined data security verification type. For example, it can include data security verification types such as null logic verification, data compatibility verification, and value range verification. The interface input parameters can be the input parameters of the interface corresponding to the target event source, used to verify the data security of the interface corresponding to the target event source.

[0094] There are several ways to determine the interface input parameters based on the interface data attributes and the preset data security verification type. For example, the value range of the interface data can be obtained from the interface data attributes, and then the interface input parameters can be determined according to the value range verification in the preset data security verification type. For instance, assuming the value range of the interface data is 0 to 10, values ​​outside this range can be obtained as interface input parameters according to the value range verification in the preset data security verification type. For example, values ​​outside the range such as -1 and 12 can be used as interface input parameters to check whether the data value range verification of the interface corresponding to the target event source is normal. Alternatively, the interface input parameter can be determined to be an empty value. This allows for the invocation of the corresponding interface of the target event source to verify its null check logic. It also allows the data type of the interface data to be obtained from its data attributes, and the interface input parameters are determined to be values ​​of different data types based on the data compatibility check in the preset data security check type. This allows for the invocation of the corresponding interface of the target event source based on the different data type input parameters, thereby verifying the data compatibility function of the interface. In this way, by adjusting the interface input parameters to invoke the data contained in the corresponding interface of the target event source, the null check logic, data compatibility, and value range of the target event source are detected to ensure data security during application operation.

[0095] There are several ways to perform event triggering logic verification on the target event source and obtain the event triggering logic verification result. For example, you can obtain a set of interactive instructions, execute the target event source based on the interactive instructions, record the call stack corresponding to the target event source after execution, compare the call stack with the expected execution result, and obtain the event triggering logic verification result.

[0096] The set of interactive instructions may include at least one interactive instruction and the expected execution result corresponding to that instruction. The interactive instruction can be an instruction that triggers an event, such as an instruction that triggers operations like swiping, clicking, or zooming. The expected execution result is the desired result after executing the interactive instruction. That is, if the result obtained after executing the interactive instruction is the expected execution result, it indicates that the event triggering logic of the target event source is functioning normally. If the result obtained after executing the interactive instruction is not the expected execution result, it indicates that the event triggering logic of the target event source is not functioning normally. For example, the expected execution result may include information from the call stack obtained by the target event source based on the expected record of the interactive instruction. The call stack can be a space that records function call paths and parameters during program runtime. The function call process recorded in the call stack can be used to verify whether the target version of the application is functioning normally during runtime in terms of event triggering logic.

[0097] There are several ways to obtain the set of interactive instructions, execute the target event source based on the interactive instructions, and record the call stack corresponding to the target event source after execution. For example, the pre-set automated test script for event triggering logic verification can be executed through the relevant instructions in the rule field of the project variable information to trigger operation instructions such as sliding, clicking, and zooming. When the instruction reaches the detection segment, the call stack corresponding to the target event source in the event trigger can be recorded.

[0098] There are several ways to determine the verification result based on the data security verification result, the event-triggered logic verification result, and the software package update verification result. For example, the data security verification result, the event-triggered logic verification result, and the software package update verification result can be directly determined as the verification result.

[0099] There are several ways to verify the software development kit update for the target event source. For example, automated scripts can be used to test the calls to newly added SDK interfaces, while regular calls can be made to modify old SDK interfaces. The software package update verification result can then be obtained based on the call results.

[0100] Optionally, when the target version of the application is running normally, the verification component can run the current detection script after the program starts. When it is detected that the upgraded target version of the application calls sensitive application interfaces or transmits sensitive data, the corresponding interface or data can be obtained through the corresponding output parameter in the extraction parameter field (atomCode) of the hook.yml file for modification. Targeted tests can be performed on certain modified interfaces, empty data and page displays in the target version of the application to verify whether there are any problems with the modifications.

[0101] In step 105, the overwrite installation of the application is verified based on the verification results.

[0102] There are several ways to verify the application overwrite installation based on the verification results. For example, if anomalies are found in the verification results, such as in data security verification, event-triggered logic verification, or package update verification, it indicates that there are anomalies in the target version of the application during the overwrite installation process. These anomalies need to be fixed to ensure the runtime security of the target version of the application. If no anomalies are found in the data security verification, event-triggered logic verification, or package update verification results, it indicates that the target version of the application is running normally during the overwrite installation process, meaning the overwrite installation of the target version of the application is normal and can be subsequently released. Therefore, by using gitHook to execute automated detection scripts, package generation, download, compilation, and finally the overwrite installation process, the manual operation costs during the overwrite installation process are saved. At the same time, the verification component verifies the data types, sensitive interfaces and data, data compatibility, and SDK interface extensibility of the target version of the application, realizing multiple types of security verification during the application overwrite installation process and improving the security of the application overwrite installation process.

[0103] As described above, this embodiment of the application obtains the installation data package and verification component data corresponding to the target version of the application from the server; performs a target version overwrite installation of the application based on the installation data package, and generates a verification component corresponding to the application based on the verification component data; filters matching target event sources from a preset event source set based on the verification component; performs at least one type of verification processing on the target event sources to obtain verification results; and verifies the overwrite installation of the application based on the verification results. Thus, by generating a verification component during the target version overwrite installation of the application, and matching multiple target event sources based on the verification component, multiple types of verification processing are performed on the target event sources, thereby achieving multiple types of security verification during the overwrite installation of the application, improving the security of the application overwrite installation process, and thus improving the efficiency of the overwrite installation.

[0104] Based on the method described in the above embodiments, the following examples will provide further detailed explanations.

[0105] In this embodiment, the overlay installation verification device will be specifically integrated into a computer device as an example for explanation. The overlay installation verification method will be specifically described using a terminal as the execution subject.

[0106] For a better description of the embodiments of this application, please refer to Figure 6 , Figure 6 Another flowchart illustrating the overlay installation verification method provided in this application embodiment is shown below.

[0107] In step 201, when a request to overwrite the target version of the application is received, the terminal obtains the verification component data and obtains the project variable information corresponding to the application from the server. The version field is extracted from the project variable information, and the installation data package corresponding to the target version of the application is searched in the local storage based on the version field.

[0108] There are several ways for the terminal to obtain the verification component data. For example, the verification component data can include pre-written source code for creating the verification component. A source code file (cpp file, source code file written in C++) can be generated based on the verification component data. The cpp file can be a configuration file that includes the source code for generating the verification component. The verification component is created through the source code file, the installation data package is pulled, and the verification component is inserted into the installation data package. The verification component data can be a plugin built into the installation data package for security verification during the overwrite installation of the target version of the application's installation data package.

[0109] In step 202, when no installation data package is found, the terminal extracts the file path information corresponding to the installation data package from the project variable information and retrieves the installation data package based on the file path information.

[0110] There are several ways for the terminal to retrieve the installation data package based on the file path information. For example, the target version of the installation data package can be found based on the file path information, and then the downloader can be started using the pthread tool to download the installation data package. After the download is completed, a version folder corresponding to the target version of the installation data package can be created first, and finally the installation data package can be stored in the version folder. Then, the target version of the installation data package can be retrieved from the version folder and overwritten for installation.

[0111] Optionally, when an installation data package is found, the terminal can retrieve the found installation data package and directly perform subsequent overwrite installation verification operations based on the found installation data package.

[0112] In step 203, the terminal performs a target version overwrite installation of the application based on the installation data package, extracts character data from the verification component data, performs part-of-speech analysis on the character data to obtain the tag data corresponding to the character data, performs syntactic analysis on the tag data, constructs code structure information based on the syntactic analysis results, and constructs the verification component corresponding to the application based on the code structure information.

[0113] The code structure information can be a syntax tree. Specifically, the terminal can parse the character data in the validation component data, and then perform part-of-speech analysis (also known as scanning), which converts all words or characters in the interface definition file into tokens according to predetermined rules. Simultaneously, it removes whitespace, comments, etc., ultimately segmenting the character data in the entire validation component data into a token list, thus generating corresponding token data. Next, it can perform syntax analysis on this token data, converting the token list obtained from the lexical analysis into a tree structure. It can also verify the syntax and delete unnecessary tokens, such as incomplete parentheses. Based on the syntax analysis results, the terminal can obtain the code structure information corresponding to the validation component data and construct the validation component for the application based on this code structure information.

[0114] In step 204, the terminal filters out the matching target event source from the preset event source set based on the verification component, obtains the engineering variable information corresponding to the application from the server, extracts the verification type parameter from the engineering variable information, and identifies at least one verification type that matches the target event source from the preset verification type set according to the type parameter.

[0115] There are several ways for the terminal to filter matching target event sources from a preset event source set based on the verification component. For example, the terminal can filter matching target event sources from the preset event source set according to the protocol type in the verification component. The protocol type can be a pre-defined protocol rule used to filter matching target event sources from the preset event source set. The protocol type can include various pre-designed protocol methods. When the script in the verification component is executed, the code segment that needs to be verified can be determined in the corresponding code segment of the application by implementing the protocol method, thus filtering out the matching target event source from the preset event source set.

[0116] In step 205, when the verification type corresponding to the target event source is data security verification type, the terminal obtains the interface data attributes of the interface corresponding to the target event source, determines the interface input parameters based on the interface data attributes and the preset data security verification type, calls the interface corresponding to the target event source based on the interface input parameters, and determines the data security verification result based on the call result.

[0117] There are several ways for the terminal to determine the interface input parameters based on the interface data attributes and the preset data security verification type. For example, the terminal can obtain the value range of the interface data from the interface data attributes, and then determine the interface input parameters according to the value range verification in the preset data security verification type. For example, assuming the value range of the interface data is 0 to 10, values ​​outside this range can be obtained as interface input parameters according to the value range verification in the preset data security verification type. For example, values ​​outside the range such as -1 and 12 can be used as interface input parameters to detect whether the data value range verification of the interface corresponding to the target event source is normal. Alternatively, the interface input parameter can be determined to be an empty value. This allows the terminal to call the corresponding interface of the target event source to verify the null check logic of the interface. It can also obtain the data type of the interface data from its data attributes and, based on the data compatibility check in the preset data security check type, determine the interface input parameters to values ​​of different data types. This allows the terminal to call the corresponding interface of the target event source based on the different data type input parameters, thereby verifying the data compatibility of the interface. In this way, the terminal can adjust the interface input parameters to call the data contained in the interface of the target event source to detect the null check logic, data compatibility, and value range of the target event source, ensuring data security during application operation.

[0118] In step 206, when the verification type corresponding to the target event source is the event triggering logic verification type, the terminal obtains the set of interactive instructions, executes the target event source based on the interactive instructions, records the call stack corresponding to the target event source after execution, compares the call stack with the expected execution result, and obtains the event triggering logic verification result.

[0119] The set of interactive instructions may include at least one interactive instruction and the expected execution result corresponding to that instruction. The interactive instruction can be an instruction that triggers an event, such as an instruction that triggers operations like swiping, clicking, or zooming. The expected execution result is the desired result after executing the interactive instruction. That is, if the result obtained after executing the interactive instruction is the expected result, it indicates that the event triggering logic of the target event source is functioning normally. If the result obtained after executing the interactive instruction is not the expected result, it indicates that the event triggering logic of the target event source is not functioning normally. For example, the expected execution result may include an expected call stack, i.e., information about the call stack that the target event source is expected to record based on the interactive instructions. This call stack can be a space at runtime that records function call paths and parameters. The function call process recorded in the call stack can be used to verify whether the target version of the application is functioning normally during runtime in terms of event triggering logic.

[0120] There are several ways for the terminal to acquire a set of interactive instructions, execute the target event source based on the interactive instructions, and record the call stack corresponding to the target event source after execution. For example, the terminal can execute a preset automated test script for event triggering logic verification through the relevant instructions in the rule field of the project variable information to trigger operation instructions such as sliding, clicking, and zooming. When the instruction reaches the detection segment, the call stack corresponding to the target event source in the event trigger can be recorded and generated.

[0121] After recording the call stack corresponding to the target event source after execution, the terminal can compare the call stack with the expected execution result to obtain the event triggering logic verification result. There are several ways the terminal can compare the call stack with the expected execution result. For example, the terminal can compare the call stack with the expected call stack in the expected execution result. If the call process recorded in the call stack is the same as the call process recorded in the expected call stack, it indicates that the event triggering logic corresponding to the target event source is functioning normally. If the call process recorded in the call stack is different from the call process recorded in the expected call stack, it indicates that the event triggering logic corresponding to the target event source is not functioning normally.

[0122] In step 207, when the verification type corresponding to the target event source is the software development kit update verification type, the terminal performs software development kit update verification on the target event source and obtains the software package update verification result.

[0123] There are several ways for the terminal to verify the software development kit update of the target event source. For example, it can perform automated script testing on the calls to newly added SDK interfaces, and perform regular calls on the modifications to old SDK interfaces, so as to obtain the software package update verification result based on the call results.

[0124] Optionally, when the target version of the application is running normally, the terminal can run the current detection script after the program is launched. When it is detected that the upgraded target version of the application calls sensitive application interfaces or transmits sensitive data, the corresponding interface or data can be obtained by extracting the corresponding output parameters in the parameter field of the hook.yml file for modification. Targeted tests can be performed on certain modified interfaces, empty data and page displays in the target version of the application to verify whether there are any problems with the modifications.

[0125] In step 208, the terminal determines the verification result based on the data security verification result, the event triggering logic verification result, and the software package update verification result, and verifies the overwrite installation of the application based on the verification result.

[0126] The terminal can perform various methods to verify the application overwrite installation based on the verification results. For example, if anomalies are found in the verification results, such as in data security verification, event-triggered logic verification, or package update verification, it indicates that the target version of the application has anomalies during the overwrite installation process and these anomalies need to be repaired to ensure the security of the target version of the application at runtime. If no anomalies are found in the data security verification, event-triggered logic verification, or package update verification results, it indicates that the target version of the application is running normally during the overwrite installation process, meaning the overwrite installation of the target version of the application is normal and can be subsequently released. In this way, the terminal uses gitHook to automate the entire process from executing the detection script, generating the package, downloading, compiling, to the final overwrite installation, saving manual operation costs during the overwrite installation process. Simultaneously, the verification component verifies the data types, sensitive interfaces and data, data compatibility, and SDK interface extensibility of the target version of the application, realizing multiple types of security verification during the application overwrite installation and improving the security of the application overwrite installation process.

[0127] As can be seen from the above, in this embodiment, when a request to overwrite the target version of an application is received, the terminal obtains verification component data and obtains the project variable information corresponding to the application from the server. The version field is extracted from the project variable information, and the terminal searches for the installation data package corresponding to the target version of the application in local storage based on the version field. If no installation data package is found, the terminal extracts the file path information corresponding to the installation data package from the project variable information and retrieves the installation data package based on the file path information. The terminal performs overwrite installation of the application for the target version based on the installation data package, extracts character data from the verification component data, performs part-of-speech analysis on the character data to obtain the tag data corresponding to the character data, performs syntactic analysis on the tag data, and constructs code structure information based on the syntactic analysis results. Based on the code structure information, the terminal constructs the verification component corresponding to the application. The terminal filters the matching target event source from a preset event source set based on the verification component, obtains the project variable information corresponding to the application from the server, extracts the verification type parameter from the project variable information, and performs verification based on the type parameter. The terminal identifies at least one verification type matching the target event source from a preset set of verification types. When the verification type corresponding to the target event source is a data security verification type, the terminal obtains the interface data attributes of the interface corresponding to the target event source, determines the interface input parameters based on the interface data attributes and the preset data security verification type, calls the interface corresponding to the target event source based on the interface input parameters, and determines the data security verification result based on the call result. When the verification type corresponding to the target event source is an event triggering logic verification type, the terminal obtains a set of interaction instructions, executes the target event source based on the interaction instructions, records the call stack corresponding to the target event source after execution, compares the call stack with the expected execution result, and obtains the event triggering logic verification result. When the verification type corresponding to the target event source is a software development kit update verification type, the terminal performs software development kit update verification on the target event source and obtains the software package update verification result. Based on the data security verification result, the event triggering logic verification result, and the software package update verification result, the terminal determines the verification result and verifies the overwrite installation of the application based on the verification result. Therefore, by generating a verification component during the overwrite installation of the application for the target version, and matching multiple target event sources based on the verification component, the verification type corresponding to each target event source is determined according to the verification parameters. Then, various types of verification processing are performed on the target event source according to verification types such as data security verification, event triggering logic verification, and package update verification. This enables multiple types of security verification during the overwrite installation of the application, improves the security of the application overwrite installation process, and thus improves the efficiency of the overwrite installation.

[0128] To better implement the above methods, this application also provides an overlay installation verification device, which can be integrated into a computer device, which can be a terminal.

[0129] For example, such as Figure 7 The diagram shown is a schematic representation of the overlay installation verification device provided in this application embodiment. The overlay installation verification device may include an acquisition unit 301, an installation unit 302, a filtering unit 303, an execution unit 304, and a verification unit 305, as follows:

[0130] The acquisition unit 301 is used to obtain the installation data package and verification component data corresponding to the target version of the application from the server.

[0131] Installation unit 302 is used to perform target version overwrite installation of the application according to the installation data package, and generate the verification component corresponding to the application according to the verification component data;

[0132] The filtering unit 303 is used to filter out matching target event sources from a preset event source set based on the verification component.

[0133] Execution unit 304 is used to perform at least one type of verification processing on the target event source and obtain the verification result;

[0134] Verification unit 305 is used to verify the overwrite installation of the application based on the verification result.

[0135] In one embodiment, the execution unit 304 includes:

[0136] The type parameter acquisition subunit is used to obtain the project variable information corresponding to the application from the server and extract the verification type parameter from the project variable information;

[0137] The verification type identification subunit is used to identify at least one verification type that matches the target event source from a preset verification type set based on the type parameter.

[0138] The execution subunit is used to perform verification processing on the target event source based on the verification type, and obtain the verification result corresponding to each verification type.

[0139] In one embodiment, the execution subunit includes:

[0140] The data security verification module is used to perform data security verification on the target event source when the verification type corresponding to the target event source is data security verification type, and obtain the data security verification result.

[0141] The event triggering logic verification module is used to perform event triggering logic verification on the target event source when the verification type corresponding to the target event source is event triggering logic verification type, and obtain the event triggering logic verification result.

[0142] The Software Development Kit (SDK) update verification module is used to perform SSD update verification on the target event source when the verification type corresponding to the target event source is SSD update verification type, and obtain the software package update verification result.

[0143] The verification result determination module is used to determine the verification result based on the data security verification result, the event-triggered logic verification result, and the software package update verification result.

[0144] In one embodiment, the data security verification module includes:

[0145] The interface data attribute retrieval submodule is used to retrieve the interface data attributes of the interface corresponding to the target event source;

[0146] The interface input parameter determination submodule is used to determine the interface input parameters based on the interface data attributes and the preset data security verification type.

[0147] The data security verification result determination submodule is used to call the interface corresponding to the target event source based on the input parameters of the interface, and determine the data security verification result based on the call result.

[0148] In one embodiment, the event triggers a logic verification module, including:

[0149] The interactive instruction set acquisition submodule is used to acquire an interactive instruction set, which includes at least one interactive instruction and the expected execution result corresponding to the interactive instruction;

[0150] The execution submodule is used to execute the target event source based on the interactive instruction and record the call stack corresponding to the target event source after execution;

[0151] The comparison submodule is used to compare the call stack with the expected execution result to obtain the event triggering logic verification result.

[0152] In one embodiment, the mounting unit 302 includes:

[0153] The part-of-speech analysis subunit is used to extract character data from the data of the verification component, perform part-of-speech analysis on the character data, and obtain the tag data corresponding to the character data.

[0154] The syntax analysis subunit is used to perform syntax analysis on the tagged data and construct code structure information based on the syntax analysis results;

[0155] The verification component construction subunit is used to construct the verification component corresponding to the application based on the code structure information.

[0156] In one embodiment, the acquisition unit 301 includes:

[0157] The data acquisition subunit is used to acquire verification component data and obtain the corresponding project variable information of the application from the server when a request for overwrite installation of the target version of the application is received.

[0158] The data packet search subunit is used to extract the version field from the project variable information and search the local storage for the installation data packet corresponding to the target version of the application based on the version field.

[0159] The installation data package retrieval subunit is used to extract the file path information corresponding to the installation data package from the project variable information when the installation data package is not found, and then retrieve the installation data package based on the file path information.

[0160] In practice, each of the above units can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units, please refer to the previous method embodiments, which will not be repeated here.

[0161] As described above, in this embodiment, the acquisition unit 301 obtains the installation data package and verification component data corresponding to the target version of the application from the server; the installation unit 302 performs a target version overwrite installation of the application based on the installation data package and generates a verification component corresponding to the application based on the verification component data; the filtering unit 303 filters out matching target event sources from a preset event source set based on the verification component; the execution unit 304 performs at least one type of verification processing on the target event sources to obtain verification results; and the verification unit 305 verifies the overwrite installation of the application based on the verification results. Thus, by generating a verification component during the target version overwrite installation of the application and matching multiple target event sources based on the verification component, multiple types of verification processing are performed on the target event sources, achieving multiple types of security verification during the overwrite installation of the application, improving the security of the application overwrite installation process, and thereby increasing the efficiency of the overwrite installation.

[0162] This application also provides a computer device, such as... Figure 8 As shown, it illustrates a structural schematic diagram of a computer device involved in an embodiment of this application. This computer device can be a terminal, specifically:

[0163] The computer device may include components such as a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, a power supply 403, and an input unit 404. Those skilled in the art will understand that... Figure 8 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0164] Processor 401 is the control center of the computer device, connecting various parts of the computer device through various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in memory 402, and by calling data stored in memory 402. Optionally, processor 401 may include one or more processing cores; preferably, processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 401.

[0165] The memory 402 can be used to store software programs and modules. The processor 401 executes various functional applications and performs overlay installations by running the software programs and modules stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 402 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.

[0166] The computer device also includes a power supply 403 that supplies power to the various components. Preferably, the power supply 403 can be logically connected to the processor 401 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 403 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0167] The computer device may also include an input unit 404, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0168] Although not shown, the computer device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 401 in the computer device loads the executable files corresponding to the processes of one or more applications into the memory 402 according to the following instructions, and the processor 401 runs the applications stored in the memory 402 to realize various functions, as follows:

[0169] Obtain the installation data package and verification component data corresponding to the target version of the application from the server; perform an overwrite installation of the application based on the installation data package and generate a verification component corresponding to the application based on the verification component data; filter out matching target event sources from a preset event source set based on the verification component; perform at least one type of verification processing on the target event source to obtain the verification result; verify the overwrite installation of the application based on the verification result.

[0170] The specific implementation of each of the above operations can be found in the preceding embodiments, and will not be repeated here. It should be noted that the computer device provided in this application embodiment and the overlay installation verification method in the above embodiments belong to the same concept, and its specific implementation process can be found in the above method embodiments, and will not be repeated here.

[0171] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0172] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the overwrite installation verification methods provided in embodiments of this application. For example, the instructions can execute the following steps:

[0173] Obtain the installation data package and verification component data corresponding to the target version of the application from the server; perform an overwrite installation of the application based on the installation data package and generate a verification component corresponding to the application based on the verification component data; filter out matching target event sources from a preset event source set based on the verification component; perform at least one type of verification processing on the target event source to obtain the verification result; verify the overwrite installation of the application based on the verification result.

[0174] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0175] Since the instructions stored in the computer-readable storage medium can execute the steps in any of the overlay installation verification methods provided in the embodiments of this application, the beneficial effects that any of the overlay installation verification methods provided in the embodiments of this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0176] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations of the above embodiments.

[0177] The foregoing provides a detailed description of an overlay installation verification method, apparatus, and computer-readable storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for verifying overlay installation, characterized in that, include: Retrieve the installation data package and verification component data for the target version of the application from the server; The application is installed over the target version according to the installation data package, and a verification component corresponding to the application is generated according to the verification component data. Based on the verification component, a matching target event source is selected from the preset event source set; Perform at least one type of verification process on the target event source to obtain the verification result; The application's overwrite installation is verified based on the verification results.

2. The overlay installation verification method as described in claim 1, characterized in that, The step of performing at least one type of verification processing on the target event source to obtain a verification result includes: Obtain the project variable information corresponding to the application from the server, and extract the verification type parameter from the project variable information; Based on the type parameter, at least one verification type matching the target event source is identified from a preset verification type set; The target event source is validated based on the validation type to obtain the validation result corresponding to each validation type.

3. The overlay installation verification method as described in claim 2, characterized in that, The step of performing verification processing on the target event source based on the verification type to obtain the verification result corresponding to each verification type includes: When the verification type corresponding to the target event source is the data security verification type, the target event source is subjected to data security verification to obtain the data security verification result; When the verification type corresponding to the target event source is the event triggering logic verification type, the event triggering logic verification is performed on the target event source to obtain the event triggering logic verification result; When the verification type corresponding to the target event source is the software development kit update verification type, the target event source is subjected to software development kit update verification to obtain the software package update verification result; The verification result is determined based on the data security verification result, the event triggering logic verification result, and the software package update verification result.

4. The overlay installation verification method as described in claim 3, characterized in that, The step of performing data security verification on the target event source to obtain the data security verification result includes: Obtain the interface data attributes of the interface corresponding to the target event source; The interface input parameters are determined based on the interface data attributes and the preset data security verification type. The interface corresponding to the target event source is called based on the interface input parameters, and the data security verification result is determined based on the call result.

5. The overlay installation verification method as described in claim 3, characterized in that, The step of performing event triggering logic verification on the target event source to obtain the event triggering logic verification result includes: Obtain an interactive instruction set, the interactive instruction set including at least one interactive instruction and the expected execution result corresponding to the interactive instruction; The target event source is executed based on the interactive instructions, and the call stack corresponding to the target event source after execution is recorded; The call stack and the expected execution result are compared to obtain the event triggering logic verification result.

6. The overlay installation verification method as described in claim 1, characterized in that, The step of generating the verification component corresponding to the application based on the verification component data includes: Extract character data from the verification component data, and perform part-of-speech analysis on the character data to obtain the tag data corresponding to the character data; The tagged data is subjected to syntactic analysis, and code structure information is constructed based on the syntactic analysis results; Based on the code structure information, construct the verification component corresponding to the application.

7. The overlay installation verification method as described in claim 1, characterized in that, The step of obtaining the installation data package and verification component data corresponding to the target version of the application from the server includes: When a request to overwrite the target version of an application is received, the verification component data is obtained, and the project variable information corresponding to the application is obtained from the server. Extract the version field from the project variable information, and search the local storage for the installation data package of the target version of the application based on the version field; If the installation data package is not found, the file path information corresponding to the installation data package is extracted from the project variable information, and the installation data package is retrieved based on the file path information.

8. A cover-mounted verification device, characterized in that, include: The acquisition unit is used to obtain the installation data package for the target version of the application and the verification component data from the server. The installation unit is used to perform a target version overwrite installation of the application according to the installation data package, and to generate a verification component corresponding to the application according to the verification component data. A filtering unit is used to filter out matching target event sources from a preset event source set based on the verification component; An execution unit is used to perform at least one type of verification processing on the target event source to obtain a verification result; A verification unit is used to verify the overwrite installation of the application based on the verification result.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the overlay installation verification method according to any one of claims 1 to 7.

10. A computer device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the overlay installation verification method according to any one of claims 1 to 7.

11. A computer program product, characterized in that, The computer program product includes a computer program / instruction that, when executed by a processor, implements the steps of the overlay installation verification method according to any one of claims 1 to 7.

Images