A function verification method and device, computer device and storage medium

Abstract

The application discloses a function verification method and device, computer equipment and a storage medium. The method comprises the following steps: acquiring code corresponding to a to-be-verified function and test requirement information; determining a test focus range based on the code corresponding to the to-be-verified function and the test requirement information; performing analysis and processing on the test focus range to obtain a dependent call relationship; generating a dependent isolation object based on the dependent call relationship, and configuring the dependent isolation object in a test execution context to obtain a controlled execution environment; in the controlled execution environment, determining test code based on the test focus range, and verifying the code corresponding to the to-be-verified function based on the test code to obtain a verification result. The method is beneficial to improving the accuracy of the verification result.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and more particularly to a functional verification method, apparatus, computer device, and storage medium. Background Technology

[0002] With the development of artificial intelligence (AI) technology, more and more fields are adopting AI for feasibility verification. In the field of system development, AI technology can be applied to code generation and code testing. In traditional system development processes, continuous integration / continuous delivery (CI / CD) can be used to achieve functional verification and deployment of code. In the CI stage, automated functional verification of the code is performed, and in the CD stage, code that passes automated tests is deployed to achieve rapid code deployment.

[0003] However, existing solutions that rely on artificial intelligence technology to automate code generation and functional verification suffer from problems such as limited verification code coverage, restricted testing environments, and inaccurate verification results. These issues not only make it difficult to conduct code functional verification in a comprehensive and efficient manner, but also further lead to inaccurate automated functional verification results. Summary of the Invention

[0004] This application provides a functional verification method, apparatus, computer equipment, and storage medium, which helps to improve the accuracy of verification results.

[0005] Firstly, embodiments of this application provide a functional verification method. This method is applied to an electronic device and can be executed by the electronic device or by a device within the electronic device, such as a processor, chip, or chip module. When the electronic device is configured with a multi-level architecture, this method can also be executed by a system with a multi-level architecture. Taking the execution of this method by an electronic device as an example, the method includes: obtaining code and test requirement information corresponding to the function to be verified; the test requirement information includes functional requirement information and / or code change information; determining a test focus based on the code corresponding to the function to be verified and the test requirement information; analyzing and processing the test focus to obtain dependency call relationships; generating a dependency isolation object based on the dependency call relationships and configuring the dependency isolation object in a test execution context to obtain a controlled execution environment; in the controlled execution environment, determining test code based on the test focus and verifying the code corresponding to the function to be verified based on the test code to obtain a verification result; the verification result is at least used to indicate whether the code corresponding to the function to be verified meets the requirements corresponding to the functional requirement information, and whether the code corresponding to the function to be verified can run normally.

[0006] It is evident that constructing a controlled execution environment for electronic devices can effectively reduce external dependency interference and improve the accuracy of verification results. Determining targeted test code based on the scope of testing concerns for electronic devices is beneficial for improving the accuracy of verification results and the efficiency of functional verification.

[0007] In one possible implementation, the above-mentioned determination of the test focus based on the code and test requirement information corresponding to the function to be verified may include: if the test requirement information includes code change information, performing a structured difference analysis on the code change information to obtain one or more of the target class, target method, and target interface corresponding to the function to be verified; and determining one or more of the target class, target method, and target interface corresponding to the function to be verified as the test focus.

[0008] It is evident that when the test requirements information for electronic devices includes code change information, the structured difference analysis results based on the code change information can determine the scope of test focus, thereby achieving precise definition of the scope of test focus, avoiding verification of unnecessary code segments, and thus improving the efficiency of functional verification of electronic devices.

[0009] In one possible implementation, the above-mentioned generation of dependency isolation objects based on dependency call relationships may include: generating a proxy object based on the native interface call relationship when the dependency call relationship includes native interface call relationships; using the proxy object to return the preset result or error status of the native interface call relationship when the electronic device does not depend on the underlying resources; generating an interception object based on the cross-process communication interface call relationship when the dependency call relationship includes cross-process communication interface call relationships; using the interception object to simulate the underlying resources for cross-process communication when the electronic device does not depend on the underlying resources; and determining the proxy object and / or the interception object as dependency isolation objects when the proxy object returns the preset result of the native interface call relationship and the interception object successfully simulates the underlying resources for cross-process communication.

[0010] It is evident that electronic devices handle different dependency call relationships specifically, achieving precise isolation of these relationships, which facilitates the construction of a controlled execution environment. Once the dependency isolation object is determined, the electronic device can obtain accurate call simulation results without relying on underlying resources. This helps reduce the risk of verification failures due to hardware or operating environment instability, thereby improving the accuracy of the verification results.

[0011] In one possible implementation, configuring the dependency isolation object in the test execution context may include: configuring the dependency isolation object in the test execution context, and having the test execution context control the class loading order, interface call routing, and lifecycle management.

[0012] It is evident that configuring dependency isolation objects in the test execution context allows electronic devices to perform verification without relying on underlying resources, which helps improve the accuracy of verification results.

[0013] In one possible implementation, the verification result is a structured verification result, which includes one or more of the following: error type identifier, location information and call path information of the code that triggered the error, test case information, and dependency isolation status information.

[0014] As can be seen, the verification results include various types of information, which can provide comprehensive and reliable data support for automated functional verification, thereby helping to improve the accuracy of electronic device verification results. In one possible implementation, the method further includes: sending the verification result to a first intelligent agent when the verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, or the code corresponding to the function to be verified cannot run normally; receiving correction code from the first intelligent agent; the correction code is code generated by the first intelligent agent based on the verification result; determining the test focus scope and controlled execution environment corresponding to the correction code based on the correction code, and verifying whether the correction code meets the requirements corresponding to the functional requirement information and whether the correction code can run normally in the controlled execution environment corresponding to the correction code.

[0015] As can be seen, when the electronic device fails verification, it sends the verification result to the first intelligent agent to generate corrective code. This achieves a closed loop of verification and modification of the code corresponding to the function to be verified, avoiding manual intervention and improving the efficiency of electronic device function verification. Furthermore, the first intelligent agent generates corrective code based on the verification result, enabling the corrective code to specifically overcome the logical defects of the code corresponding to the function to be verified, increasing the probability of successful verification of the corrective code, thereby improving the efficiency of the first intelligent agent in generating verifiable code.

[0016] In one possible implementation, the above method further includes: performing multiple rounds of verification and feedback correction on the code generated by the first intelligent agent, so that the code corresponding to the function to be verified is gradually optimized until the code generated by the first intelligent agent passes the verification or reaches the preset termination condition.

[0017] It is evident that performing a limited number of functional verifications and feedback corrections on electronic devices can not only optimize the code corresponding to the function to be verified, but also effectively prevent the verification from falling into an infinite loop.

[0018] In one possible implementation, the above method further includes: when the verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, or the code corresponding to the function to be verified cannot run normally, obtaining a first fault feature, and determining a first fault cause based on the first fault feature; the first fault feature is feature information generated by the execution of the code corresponding to the function to be verified; and adding the first fault cause and the first fault feature to the verification result.

[0019] It is evident that when verification fails, the electronic device automatically identifies the primary cause of the failure. This allows the electronic device to address the code corresponding to the function to be verified based on the primary cause, thereby improving the efficiency of the first agent in generating verifiable code.

[0020] In one possible implementation, the method further includes: searching for a repair suggestion that matches the first cause of failure in the repair knowledge base; and, if a repair suggestion is found, adding the repair suggestion to the verification results.

[0021] As can be seen, when matching repair suggestions are found, these suggestions are added to the verification results. This allows electronic devices to perform targeted repairs on the code corresponding to the function to be verified based on the verification results, improving the efficiency of the first agent in generating verifiable code.

[0022] In one possible implementation, the above method further includes: obtaining a second fault characteristic when the proxy object returns an error state of the native interface call relationship, or when the interception object fails to simulate cross-process communication using underlying resources; the second fault characteristic is characteristic information generated by the generated dependency isolation object; performing anomaly analysis on the second fault characteristic to obtain the second fault cause; determining the second fault cause and the second fault characteristic as the verification result, the verification result indicating that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, and the code corresponding to the function to be verified cannot run normally.

[0023] It is evident that when an electronic device fails to successfully construct a controlled execution environment, it interrupts the functional verification process to avoid wasting computing resources. Identifying the second cause and second characteristic of the failure as the verification result increases the likelihood of successfully constructing the controlled execution environment subsequently, thereby improving the efficiency of functional verification.

[0024] Secondly, embodiments of this application provide a functional verification device, which includes a transceiver unit and a processing unit.

[0025] The transceiver unit is used to acquire the code and test requirement information corresponding to the function to be verified; the test requirement information includes functional requirement information and / or code change information.

[0026] The processing unit is configured to: determine the scope of test concern based on the code corresponding to the function to be verified and the test requirement information; analyze and process the scope of test concern to obtain dependency call relationships; generate dependency isolation objects based on the dependency call relationships and configure the dependency isolation objects in the test execution context to obtain a controlled execution environment; in the controlled execution environment, determine test code based on the scope of test concern and verify the code corresponding to the function to be verified based on the test code to obtain a verification result; the verification result is used to at least indicate whether the code corresponding to the function to be verified meets the requirements corresponding to the function requirement information, and whether the code corresponding to the function to be verified can run normally.

[0027] In one possible implementation, the processing unit is further configured to perform structured difference analysis on the code change information when the test requirement information includes code change information, to obtain one or more of the target class, target method and target interface corresponding to the function to be verified; and to determine one or more of the target class, target method and target interface corresponding to the function to be verified as the scope of test concern.

[0028] In one possible implementation, the processing unit is further configured to: generate a proxy object based on the native interface call relationship when the dependency call relationship includes the native interface call relationship; return a preset result or error status of the native interface call relationship when the electronic device does not depend on the underlying resources; generate an interceptor object based on the cross-process communication interface call relationship when the dependency call relationship includes the cross-process communication interface call relationship; simulate cross-process communication using the underlying resources when the electronic device does not depend on the underlying resources; and identify the proxy object and / or the interceptor object as dependency isolation objects when the proxy object returns a preset result of the native interface call relationship and the interceptor object successfully simulates cross-process communication using the underlying resources.

[0029] In one possible implementation, the processing unit is also used to configure dependency isolation objects in the test execution context, and the test execution context controls the class loading order, interface call routing, and lifecycle management.

[0030] In one possible implementation, the verification result is a structured verification result, which includes one or more of the following: error type identifier, location information and call path information of the code that triggered the error, test case information, and dependency isolation status information.

[0031] In one possible implementation, the transceiver unit is further configured to send the verification result to the first intelligent agent when the verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, or the code corresponding to the function to be verified cannot run normally; receive correction code from the first intelligent agent; the correction code is code generated by the first intelligent agent based on the verification result; the processing unit is further configured to determine the test focus scope and controlled execution environment corresponding to the correction code based on the correction code, and verify whether the correction code meets the requirements corresponding to the functional requirement information and whether the correction code can run normally in the controlled execution environment corresponding to the correction code.

[0032] In one possible implementation, the processing unit is also used to perform multiple rounds of verification and feedback correction on the code generated by the first agent, so that the code corresponding to the function to be verified is gradually optimized until the code generated by the first agent passes the verification or reaches the preset termination condition.

[0033] In one possible implementation, the transceiver unit is further configured to acquire a first fault feature when the verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, or the code corresponding to the function to be verified cannot run normally; the processing unit is further configured to determine a first fault cause based on the first fault feature; the first fault feature is feature information generated by the execution of the code corresponding to the function to be verified; and the first fault cause and the first fault feature are added to the verification result.

[0034] In one possible implementation, the processing unit is further configured to search for a repair suggestion that matches the first fault cause in the repair knowledge base; and if a repair suggestion is found, to add the repair suggestion to the verification result.

[0035] In one possible implementation, the transceiver unit is further configured to obtain a second fault characteristic when the proxy object returns an error state of the native interface call relationship, or when the interceptor fails to simulate cross-process communication using underlying resources; the second fault characteristic is characteristic information generated by the generated dependency isolation object; the processing unit is further configured to perform anomaly analysis on the second fault characteristic to obtain the cause of the second fault; the cause of the second fault and the second fault characteristic are determined as the verification result, and the verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, and the code corresponding to the function to be verified cannot run normally.

[0036] Thirdly, embodiments of this application provide an electronic device, which includes: a memory and one or more processors; the memory is coupled to the one or more processors. The memory is used to store a computer program, the computer program including program instructions; the one or more processors are used to execute the instruction program stored in the memory, wherein when the program is executed by the processors, the processors perform the method as described in the first aspect and any possible implementation thereof.

[0037] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including program instructions, wherein when the program instructions are executed by a processor, the processor performs a method as described in the first aspect and any possible implementation thereof. Attached Figure Description

[0038] Figure 1a This is a schematic diagram of a cross-process communication structure provided in an embodiment of this application; Figure 1b This is a schematic diagram of a system architecture using an embodiment of this application; Figure 2 A flowchart illustrating a functional verification method provided in an embodiment of this application; Figure 3 A flowchart illustrating another functional verification method provided in an embodiment of this application; Figure 4 A flowchart illustrating a PMS functional verification method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a functional verification device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0039] The embodiments of this application will now be described with reference to the accompanying drawings.

[0040] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0041] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0042] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0043] The terms “component,” “module,” “system,” etc., used in this specification are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0044] First, some of the terms used in this application will be explained to facilitate understanding by those skilled in the art.

[0045] I. Dependency Isolation Dependency isolation is a technique for resolving dependency conflicts between code. These conflicts arise when different projects require different versions of third-party resources (such as native libraries). Dependency isolation creates virtual runtime environments, isolating project code and allowing each code to run correctly within its own virtual environment. Therefore, using dependency isolation in software development, program maintenance, and code inspection not only ensures the smooth operation of each project's code and reduces the risk of runtime anomalies caused by dependency conflicts, but also enables the simultaneous execution of multiple projects, improving the efficiency of software development, program maintenance, and code inspection.

[0046] The following section uses common dependency isolation methods as examples: dynamic isolation using JNI (Java Native Interface) (a programming language interaction mechanism) and low-level interception using Binder (a cross-process communication mechanism).

[0047] (1) JNI dynamic isolation In electronic devices with a layered system architecture, different layers typically use different programming languages. For example, the application layer and framework layer primarily use Java; the kernel layer and hardware abstraction layer primarily use C or C++. Program files compiled using C / C++ can be stored in a native library (a code-sharing library; in Android, native libraries have the .so extension; in Windows, they have the .dll extension). In other words, Java can call program files stored in the native library via JNI.

[0048] JNI dynamic isolation redirects calls originally implemented in C / C++ to the Java layer and is then executed by Java without loading underlying resources. A common method for JNI dynamic isolation is bytecode instrumentation. This technique involves the electronic device retrieving project code and, if it finds a predefined code suffix (e.g., ACC_NATIVE), modifying that suffix with the predefined bytecode, thereby redirecting the call and preventing it from being implemented in C / C++.

[0049] In this embodiment of the application, the native interface call relationship is the Java call to the native library implemented by the electronic device through JNI.

[0050] (2) Binder interception For cross-process communication, Binder is a communication mechanism between different processes.

[0051] Please see Figure 1a , Figure 1a This is a schematic diagram illustrating a cross-process communication structure provided in an embodiment of this application. Figure 1a As shown, Binder communication consists of four parts: the user (client) process 110a, the server process 120a, the service manager process 130a, and the Binder driver 140a. The user process 110a is used to access the service; the server process 120a provides the service; the service manager process 130a manages service registration and querying; and the Binder driver 140a acts as the intermediary between the user process, the server process, and the service manager process, used to transfer inter-process data and implement thread control.

[0052] Since the user process and the service process are two independent processes, meaning one process cannot directly manipulate or access the other, the user process and the service process control the Binder driver through IPCThreadState to achieve cross-process data interaction. The data exchanged across processes is parcel data.

[0053] Binder interception involves an electronic device inserting custom logic (Hook) into IPCThreadState to interrupt Binder communication; obtaining the parcel data of cross-process communication transmission; parsing and processing the parcel data to obtain the service, method, and parameters indicated by the parcel data; and simulating the service, method, and parameters indicated by the parcel parameters in user space to obtain the result of simulated cross-process communication.

[0054] In this embodiment of the application, the cross-process communication interface call relationship is cross-process communication implemented by the electronic device through Binder.

[0055] II. Program Abstraction Unit (1) class Classes encapsulate data and behavior, serving as abstract descriptions and implementations of entities or services within a specific domain. They encapsulate an object's state (member variables) and behavior (member methods), acting as a blueprint for instantiating executable objects. In the Android system's framework layer, system services such as the Package Manager Service (PMS) exist as classes, responsible for managing system metadata and business logic specific to a particular domain.

[0056] (2) Method A method is an executable block of code within a class or object that performs a specific function; it encapsulates the behavior of the code. Upon receiving input parameters, a method can execute predefined logic on those parameters and return the result.

[0057] A method consists of a method signature, return type, method body, modifiers, and exception declarations. The method signature, including the method name and parameter list (parameter types, number of parameters, and parameter order), is the unique identifier of the method. The return type specifies the type of the execution result returned by the method. The method body contains the code block containing the execution logic. Modifiers define the behavioral characteristics. Exception declarations handle exceptions.

[0058] (3) Interface An interface is a reference type used to define behavioral contracts. An interface declares only the set of behavioral capabilities without containing concrete implementations, forming a decoupling contract between the caller and the implementer. In the Android system, interfaces implement formal specifications for cross-process communication by defining standardized signature methods, allowing different implementations of the same interface to be transparently replaced.

[0059] III. Package Manager Service (PMS) Package Manager Service (PMS) is a system service in Android, running in the `system_server` process. It manages the parsing, installation, uninstallation, information retrieval, permission management, and related verifications of all applications in the application layer. The interaction between PMS and various applications relies on Binder inter-process communication (IPC). In IPC, PMS is the service process, and the applications are user processes. Taking application installation as an example, the application sends a Binder call request to the Binder driver through the user interface (package manager) to request PMS to install the corresponding application package.

[0060] IV. CI / CD CI / CD is a software development practice and methodology. Its core principle is to improve the efficiency of development teams and the quality of software through the automated and continuous integration, building, testing, and delivery of software.

[0061] CI (Continuous Integration) is a software development practice that automates building and testing by continuously integrating developers' code into a shared codebase to ensure that every code change works correctly. CD (Conversion and Deployment) automates the software delivery process, including building, testing, deployment, and monitoring, to ensure that new features or fixes are delivered to production environments quickly.

[0062] Currently, CI / CD is a common method for functional verification. However, using CI / CD to verify the functionality of electronic devices has drawbacks, including limited code coverage, restricted testing environments, and inaccurate verification results.

[0063] In view of this, embodiments of this application provide a functional verification method, apparatus, computer device, and storage medium. The electronic device constructs a controlled execution environment and performs functional verification within this environment. This allows the electronic device to perform verification without relying on underlying resources and the external environment, thus improving the accuracy of the verification results. The electronic device determines test code based on the scope of testing concern. By using test code, the code corresponding to the function to be verified can be verified specifically, which helps improve the accuracy of the verification results and reduces the resource consumption of the electronic device.

[0064] Before introducing the functional verification method provided in the embodiments of this application, a system architecture applying the embodiments of this application will be described. Please refer to [link to relevant documentation]. Figure 1b , Figure 1b This is a schematic diagram of a system architecture applying an embodiment of this application. For example... Figure 1b As shown, the system architecture includes a first agent 1000 and a second agent 2000.

[0065] The first intelligent agent 1000 is used to generate or modify the code corresponding to the function to be verified. The first intelligent agent 1000 includes a modification / generation module 1010, which can generate code based on functional requirement information and / or verification results, or modify code based on functional requirement information and / or verification results.

[0066] In this embodiment of the application, the first intelligent agent 1000 can also be used to determine code change information.

[0067] The second intelligent agent 2000 is used to construct a controlled execution environment and perform functional verification on the code corresponding to the function to be verified generated by the first intelligent agent 1000 within the controlled execution environment. The second intelligent agent 2000 includes a difference analysis module 1020, a dependency isolation module 1030, a testing module 1040, a collection module 1050, a fault analysis module 1060, and a feedback module 1070.

[0068] The difference analysis module 1020 can be used to determine code change information.

[0069] The dependency isolation module 1030 can be used to generate dependency isolation objects and build a controlled execution environment.

[0070] Test module 1040 is used to generate test code and verify the code corresponding to the function to be verified. If the code corresponding to the function to be verified meets the requirements of the functional requirements information and can run stably, the code is considered to have passed verification. Otherwise, the code is considered to have failed verification.

[0071] The collection module 1050 collects error characteristics when the test module 1040 determines that the code corresponding to the function to be verified has failed verification. Alternatively, it collects error characteristics when the dependency isolation module 1030 fails to build a controlled execution environment.

[0072] The fault analysis module 1060 is used to determine the cause of the fault based on the error characteristics. The fault analysis module 1060 can also search the repair database for repair suggestions that match the fault cause based on the fault cause.

[0073] The feedback module 1070 can add the cause of the fault and repair suggestions to the verification result and send the verification result to the first intelligent agent 1000, so that the first intelligent agent 1000 can correct the code corresponding to the function to be verified based on the verification result.

[0074] The system architecture also includes a historical execution library 1090 and a stability metric library 1100. The historical execution library stores the verification results determined by the feedback module 1070. When the data stored in the historical execution library 1090 reaches a storage threshold, the historical execution library 1090 can be used to update and repair the database 1080. The stability metric library 1100 stores the stability test results from the verification results. When the data stored in the stability metric library 1100 reaches an update threshold, the stability metric library 1100 is used to adjust the parameters in the modification / generation module 1010, enabling the modification / generation module 1010 to generate more stable code.

[0075] The functional verification method provided in the embodiments of this application is described below.

[0076] Please see Figure 2 , Figure 2 This is a flowchart illustrating a functional verification method provided in an embodiment of this application. Figure 2 As shown, this functional verification method may include, but is not limited to, the following steps: S201, The electronic device obtains the code and test requirement information corresponding to the function to be verified.

[0077] The code corresponding to the function to be verified (hereinafter referred to as the first code for ease of description) is the code determined by the electronic device invoking the first intelligent agent based on the functional requirement information. The first code is used to implement the functional requirements that need to be added or modified as indicated by the functional requirement information.

[0078] There are three ways in which an electronic device can obtain the first code by calling the first intelligent agent: Method 1: The electronic device invokes the first intelligent agent to generate the first code based on the functional requirement information.

[0079] Method Two: The electronic device invokes a first intelligent agent to modify the original code based on functional requirement information, thus obtaining the first code. The original code is the code stored in the electronic device.

[0080] Method 3: The electronic device invokes the first intelligent agent to modify the previously obtained first code based on the functional requirement information and the verification result, thus obtaining the new first code. The verification result refers to the electronic device's verification of the previously obtained first code. The specific implementation method for the electronic device to verify the first code and obtain the verification result will be described in detail in step S205.

[0081] The test requirement information includes functional requirement information and / or code change information. The code change information includes difference codes. For the first code obtained through Method 1 above, the electronic device invokes the first intelligent agent to identify the first code as the difference code. For the first code obtained through Method 2 above, the electronic device invokes the first intelligent agent to compare the first code with the original code to obtain the difference code. For the first code obtained through Method 3 above, the electronic device invokes the first intelligent agent to compare the first code with the previously obtained first code to obtain the difference code.

[0082] It should be understood that, since the first intelligent agent can modify the code multiple times, the code change information also includes the modification file of the first code and the version identifier of the first code to clearly identify the modified version and the content of the modification. The modification file of the first code is used to indicate the content of the modification; for example, the modification file may include comments indicating the differences in the code. The version identifier of the first code is used to indicate the version of the first code.

[0083] In one possible implementation, the electronic device can invoke a first intelligent agent to determine one or more of the code change information and functional requirement information as test requirement information.

[0084] S202, Electronic devices determine the scope of testing based on the code and test requirements information corresponding to the functions to be verified.

[0085] The testing focus scope is the code scope for functional verification of the electronic device. In other words, the electronic device will perform functional verification on the code within the testing focus scope. The testing focus scope can be used to determine dependency call relationships and test code. The specific implementation method for the electronic device to determine dependency call relationships based on the testing focus scope is described in detail in step S203; the specific implementation method for the electronic device to determine test code based on the testing focus scope is described in detail in step S205.

[0086] In one possible implementation, when the test requirement information includes code change information, the electronic device performs a structured difference analysis on the differing code in the code change information to obtain one or more of the target class, target method, and target interface corresponding to the function to be verified; and determines one or more of the target class, target method, and target interface corresponding to the function to be verified as the scope of test interest.

[0087] In one possible implementation, when the test requirement information only includes functional requirement information, the electronic device can compare the first code with the original code (or the previously obtained first code) to obtain the difference code. Optionally, the electronic device can also determine the difference code from the first code based on the functional requirement information. For example, the electronic device can search for comment information in the first code based on the functional requirement information. If the comment information indicates the functional requirement indicated by the functional requirement information, the electronic device determines the code corresponding to that comment information as the difference code. After determining the difference code, the electronic device performs structured difference analysis on the difference code to obtain the scope of test interest.

[0088] Determining the scope of test focus based on initial code and test requirements information improves the accuracy of the scope and reduces deviations. Furthermore, defining the scope of test focus effectively reduces the verification of irrelevant code, thereby improving the efficiency of functional verification.

[0089] S203, the electronic device analyzes and processes the scope of test interest to obtain the dependency call relationship.

[0090] Dependency call relationships include native interface call relationships and / or cross-process communication interface call relationships. Native interface call relationships refer to Java calls to native libraries implemented by electronic devices via JNI; cross-process communication interface call relationships refer to cross-process service calls implemented by electronic devices via Binder.

[0091] In one possible implementation, the existence of native interface call relationships in the dependency call relationships can be determined by the following method: Method 1: The electronic device detects whether a preset code suffix exists in the code corresponding to the test focus area. If a preset code suffix is ​​detected in the code corresponding to the test focus area, the electronic device determines the dependency call relationships of the test focus area, including native interface call relationships.

[0092] For example, the default code suffix includes ACC_NATIVE. That is, if the electronic device detects the presence of ACC_NATIVE in the code corresponding to the scope of test interest, the electronic device can determine that the dependency call relationships of the scope of test interest include native interface call relationships.

[0093] Method 2: The electronic device detects whether the native library is in a loading state. If the native library is detected to be in a loading state, the electronic device determines the dependency call relationships of interest for testing, including native interface call relationships.

[0094] Methods 1 and 2 described above are for illustrative purposes only and do not constitute a limitation on this application.

[0095] In one possible implementation, the electronic device determines whether there are cross-process communication interface call relationships in the dependency call relationships of the test focus by means of the following method.

[0096] Method (1): The electronic device detects in user mode whether a preset class exists in the code corresponding to the test focus. If a preset class is detected in the code corresponding to the test focus, the electronic device determines the dependency call relationship of the test focus, including the cross-process communication interface call relationship.

[0097] For example, the preset class includes IPCThreadState. If the electronic device detects the presence of IPCThreadState in the code corresponding to the scope of test interest in user space, the electronic device can determine that the dependency call relationships of the scope of test interest include cross-process communication interface call relationships.

[0098] Method (2): The electronic device detects the transaction statistics of the code corresponding to the test focus in kernel mode. When the output of the transaction statistics exceeds the count threshold, the electronic device determines the dependency call relationships of the test focus, including cross-process communication interface call relationships.

[0099] The methods (1) and (2) described above are for illustrative purposes only and do not constitute a limitation on this application.

[0100] Electronic devices determine dependency and call relationships based on the scope of testing interest, which not only enables automatic analysis of the link and improves verification efficiency, but also expands the verification scope and improves the accuracy of verification results.

[0101] S204, the electronic device generates a dependency isolation object based on the dependency call relationship, and configures the dependency isolation object in the test execution context to obtain a controlled execution environment.

[0102] Dependency isolation objects are the result of electronic devices isolating dependency calls. A controlled execution environment is an execution environment that does not depend on underlying resources.

[0103] When the dependency call relationship includes native interface call relationships, the electronic device dynamically isolates these relationships using JNI, generating proxy objects based on the native interface call relationships. These proxy objects represent the preset results or error states of the native interface call relationships simulated at the Java layer when the electronic device does not depend on underlying resources. When the native interface call relationships run normally at the Java layer, JNI dynamic isolation succeeds, and the electronic device generates a proxy object indicating the preset result; when the native interface call relationships run abnormally at the Java layer, JNI dynamic isolation fails, and the electronic device generates a proxy object indicating the error state.

[0104] For example, suppose the electronic device detects a preset code suffix (ACC_NATIVE) in the code corresponding to the scope of test interest. The electronic device removes ACC_NATIVE and adds new bytecode, enabling the call to the native interface to be simulated in Java; if the native interface call relationship runs normally in Java, a proxy object is generated to indicate the preset result; if the native interface call relationship runs abnormally in Java, a proxy object is generated to indicate the error status.

[0105] Electronic devices use JNI for dynamic isolation, directing calls to native libraries to the Java layer. This avoids the electronic devices calling native libraries directly, thus preventing them from accessing underlying resources. This helps electronic devices build a stable and controlled execution environment.

[0106] When the dependency call relationship includes inter-process communication interface call relationships, the electronic device intercepts through Binder and generates an interception object based on the inter-process communication interface call relationship. This interception object indicates the state of simulating inter-process communication using underlying resources without relying on them. When the inter-process communication interface call relationship is simulated successfully in user space, Binder isolation is successful, and the electronic device generates an interception object indicating successful simulation of inter-process communication using underlying resources. When the inter-process communication interface call relationship is simulated abnormally in user space, Binder isolation fails, and the electronic device generates an interception object indicating whether the simulation of inter-process communication using underlying resources succeeded or failed.

[0107] For example, the electronic device intercepts Binder in user space by hooking IPCThreadState; when Binder inter-process communication is intercepted, the encapsulated data transmitted in the inter-process communication is parsed, and the underlying resources are simulated to perform inter-process communication based on the parsed encapsulated data; the electronic device generates an interception object based on the simulated state of inter-process communication performed by the underlying resources. In one possible implementation, when the dependency call relationship only includes native API calls, if the proxy result returns a preset result, the electronic device identifies the proxy object as a dependency isolation object. When the dependency call relationship only includes inter-process communication API calls, if the interceptor object indicates successful simulation of underlying resource inter-process communication, the electronic device identifies the interceptor object as a dependency isolation object. When the dependency call relationship includes both native API calls and inter-process communication API calls, if the proxy object returns a preset result and the interceptor object indicates successful simulation of underlying resource inter-process communication, the electronic device identifies both the proxy object and the interceptor object as dependency isolation objects.

[0108] After determining the dependency isolation objects, the electronic device configures the dependency isolation objects in the test execution context. The test execution context controls the class loading order, interface call routing, and lifecycle management to obtain a controlled execution environment. That is, if the proxy object returns an error status and / or the interceptor object indicates that simulating cross-process communication with underlying resources has failed, the electronic device has not successfully built a controlled execution environment. When the electronic device fails to build a controlled execution environment, step S304 is executed.

[0109] S205 In a controlled execution environment, the electronic device determines the test code based on the test concern, and verifies the code corresponding to the function to be verified based on the test code to obtain the verification result.

[0110] The test code is used to verify whether the first code meets the functional requirements and whether it can run normally. The test code includes output test code and stability test code.

[0111] In one possible implementation, the electronic device can determine the stability index of the first code through stability test code. If the stability index is greater than or equal to a stability threshold, the electronic device determines that the first code meets the stability standard, meaning the first code can run stably; if the stability index is less than the stability threshold, the electronic device determines that the first code does not meet the stability standard, meaning the first code fails the stability test. The stability index can not only be used to determine the stability test results but also to update the first agent, enabling it to generate stable code.

[0112] Since the first code can be of different types (for example, the first code can be code in PMS or code in Activity Manager AMS), it is necessary to obtain test samples of the corresponding type of the first code when verifying its functionality.

[0113] In one possible implementation, the electronic device performs sample type analysis on the difference code to determine the test sample type corresponding to the first code; based on the test sample type of the first code, the electronic device retrieves the target test sample from the sample library, processes the target test sample using the first code, and obtains the processing result; the electronic device uses the result test code in the test code to verify whether the processing result meets the requirements indicated by the functional requirement information. The electronic device uses the stability test code in the test code to verify whether the first code can run stably.

[0114] For example, suppose the requirement corresponding to the functional information is that an electronic device installs an application via path 'a', and the function corresponding to the original code in the PMS is that the electronic device installs an application via path 'b'. The electronic device determines test code based on the test focus scope. This test code verifies whether the electronic device installs the application via path 'a'. The electronic device determines the test sample type based on the difference code and retrieves the target test sample (application A) from the sample library based on the test sample type. The electronic device installs application A using the first code. The electronic device verifies the path information for installing application A using the result test code within the test code. If the verification result of the result test code indicates that application A was installed via path 'a', the first code satisfies the requirement indicated by the functional requirement information. The electronic device determines the stability index of the first code using the stability test code within the test code. If the stability index is greater than or equal to the stability threshold, the first code runs stably. The electronic device determines the verification result based on the verification result of the result test code and the test result of the stability test code.

[0115] It should be understood that determining the test code for electronic devices based on the scope of testing concerns helps to accurately verify the scope, avoid invalid verification, and improve the efficiency and accuracy of functional verification of electronic devices.

[0116] When the verification results indicate that the first code meets the functional requirements and functions correctly, the electronic device can perform one or more of the following processes: merging, building, releasing, or approval. Merging involves the electronic device updating the codebase based on the first code. Specifically, if the original code does not exist in the codebase, the electronic device stores the first code; if the original code exists, the electronic device updates the original code in the codebase with the first code. Building involves the electronic device building an image file based on the updated codebase. Releasing involves burning the image file to a designated device. Approval involves manual acceptance of the first code, which effectively ensures the accuracy of the verification results. When the first code passes verification, the electronic device automatically triggers one or more of these processes, automating the entire process from code development to delivery and improving the efficiency of functional verification of the first code.

[0117] If the verification result indicates that the first code does not meet the functional requirements and / or the first code cannot run normally, the electronic device acquires a first fault feature and adds it to the verification result. The first fault feature is characteristic information generated by the execution of the first code, and includes one or more of the following: error type identifier, location information of the code that triggered the error, call path information of the code that triggered the error, test case information, or dependency isolation status information. The error type identifier indicates the type of error reported by the first code (e.g., the first code's operational stability is substandard); the test case information is used as the sample identifier for the target test sample; and the dependency isolation status information indicates the dependency isolation status of each dependency call relationship of the electronic device.

[0118] In one possible implementation, the electronic device can determine a first fault cause based on a first fault characteristic. After determining the first fault cause, the electronic device searches a repair knowledge base for a repair suggestion that matches the first fault cause. If a matching repair suggestion is found, the first fault cause and the repair suggestion are added to the verification results; if no matching repair suggestion is found, the first fault cause is added to the verification results.

[0119] The electronic device sends the verification results to the first intelligent agent, which then modifies the first code based on the verification results and functional requirements, resulting in corrected code. After obtaining the corrected code, the electronic device determines its corresponding test focus and controlled execution environment, and performs functional verification on the corrected code within that controlled execution environment.

[0120] The electronic device can perform multiple rounds of verification and feedback correction on the code generated by the first intelligent agent, allowing the code to be gradually optimized until it passes verification. However, the electronic device terminates the functional verification process when a preset termination condition is met. For example, the electronic device terminates the functional verification process when the number of verifications reaches a preset verification threshold. By terminating the functional verification process with preset termination conditions, the electronic device effectively avoids performing unlimited verifications, reducing resource waste.

[0121] As can be seen, the functional verification method provided in this application allows electronic devices to perform functional verification in a controlled execution environment, effectively reducing external dependencies and improving the accuracy of verification results. The electronic device determines test code based on the scope of testing concern, enabling targeted verification of the first code and improving the efficiency of functional verification.

[0122] Please see Figure 3 , Figure 3 This is a flowchart illustrating another functional verification method provided in an embodiment of this application. Figure 3 As shown, this functional verification method may include, but is not limited to, the following steps: S301, The electronic device obtains the code and test requirement information corresponding to the function to be verified.

[0123] S302, Electronic devices determine the scope of testing based on the code and test requirements information corresponding to the functions to be verified.

[0124] S303, the electronic device analyzes and processes the scope of test interest to obtain the dependency call relationship.

[0125] The implementation methods for steps S301-S303 can be found in the following reference: Figure 2 The steps S201-S203 shown above, as well as the description of steps S201-S203 above, will not be repeated here.

[0126] S304, when the proxy object returns an error state of the native interface call relationship, or when the intercepting object fails to simulate the underlying resources for cross-process communication, the electronic device acquires a second fault characteristic.

[0127] The second fault characteristic is the characteristic information generated by the dependency isolation object. The second fault characteristic includes one or more of the following: error type identifier, location information of the code that triggered the error, call path information of the code that triggered the error, or dependency isolation status information.

[0128] If the electronic device fails to isolate the dependency call relationship, the electronic device terminates the function verification process and obtains the second fault characteristic.

[0129] S305, the electronic equipment performs anomaly analysis on the second fault characteristic and obtains the cause of the second fault.

[0130] The second cause of the failure was the electronic device's inability to isolate dependencies in the call relationships.

[0131] After identifying the second cause of the electronic device failure, it can search the repair knowledge base for repair suggestions that match the second cause. If a matching repair suggestion is found, the second cause of failure and the repair suggestion are added to the verification results; if no matching repair suggestion is found, the second cause of failure is added to the verification results.

[0132] S306, the electronic device identifies the second fault cause and the second fault characteristic as verification results.

[0133] In the event that the controlled execution environment construction fails, the electronic device interrupts the functional verification process and identifies the features related to dependency isolation and the reasons for the dependency isolation failure as the verification results. If the electronic device finds a remedial suggestion that matches the second cause of failure, the electronic device also adds the remedial suggestion that matches the second cause of failure to the verification results.

[0134] The electronic device sends the verification result to the first intelligent agent and calls the first intelligent agent to modify the first code based on the second fault cause, the second fault characteristics and the required function information, so as to obtain the modified first code.

[0135] The first intelligent agent determines the modified first code based on the second fault cause and the second fault characteristics. This helps the first intelligent agent to specifically repair the causes of the failure to build the controlled execution environment, thereby increasing the possibility that the electronic device can successfully build the controlled execution environment based on the modified first code.

[0136] It is evident that when the controlled execution environment construction of an electronic device fails, the functional verification process is interrupted, and new code is re-acquired based on the verification results. This controlled execution environment for constructive code helps improve the accuracy of the verification results. Please see Figure 4 , Figure 4 This is a flowchart illustrating a PMS functional verification method provided in an embodiment of this application. Figure 4 As shown, the PMS functional verification method includes, but is not limited to, the following steps: s1, Electronic device receives functional requirement information.

[0137] The functional requirements information indicates that modifications should be made to the code related to application parsing and application authorization in the PMS source code.

[0138] s2, the electronic device calls the first intelligent agent to modify the original PMS code based on the functional requirement information, and obtains the first PMS code.

[0139] s3, the electronic device calls the first intelligent agent to determine the test function requirement information based on the first PMS code and the original PMS code.

[0140] The electronic device compares the first PMS code with the original PMS code to obtain the PMS difference code; the electronic device obtains the version identifier of the first PMS code and the modification file of the first PMS code, and identifies the first PMS code, the version identifier of the first PMS code, and the modification file of the first PMS code as code change information; the electronic device identifies the code change information and functional requirement information as test requirement information.

[0141] s4, Electronic devices perform structured difference analysis on PMS difference codes to obtain the scope of PMS testing.

[0142] s5, whether the electronic device has successfully passed the PMS test and built a controlled execution environment.

[0143] The electronic device analyzes and processes the scope of PMS testing to obtain PMS dependency call relationships. These PMS dependency call relationships include cross-process communication interface call relationships. The electronic device then uses Binder to intercept these cross-process communication interface call relationships, obtaining the intercepted objects.

[0144] If the intercepted object indicates that the electronic device has successfully simulated inter-process communication using underlying resources, the electronic device identifies the intercepted object as a dependency isolation object and configures the isolation object in the test execution context to build a controlled execution environment, thus executing step s6. If the intercepted object indicates that the electronic device has failed to simulate inter-process communication using underlying resources, and the electronic device has not successfully built a controlled execution environment, steps s8-s10 are executed.

[0145] s6. The electronic device determines the test code based on the PMS test focus scope, and verifies the PMS modified code based on the test code to obtain the verification results.

[0146] The test code includes execution result test code and stability test code; the execution result test code is used to test whether the execution result of the first PMS code meets the requirements indicated by the functional requirement information; the stability test code is used to verify whether the first PMS code can run normally and stably in electronic devices.

[0147] If the verification result indicates that the first PMS code meets the requirements indicated by the functional requirement information, and the first PMS code can run normally and stably, then the first PMS code verification is successful. If the verification result indicates that the first PMS code does not meet the requirements indicated by the functional requirements information and / or the first PMS code operates abnormally, then the verification of the first PMS code fails. The electronic device acquires the first fault characteristic and determines the first fault cause based on the first fault characteristic. The electronic device adds the first fault characteristic and the first fault cause to the verification result. The electronic device searches for a repair suggestion matching the first fault cause in the repair knowledge base. If the electronic device finds a matching repair suggestion in the repair knowledge base, it adds the repair suggestion matching the first fault cause to the verification result. The electronic device sends the verification result to the first intelligent agent and executes step s7.

[0148] s7, the electronic device obtains the second PMS code based on the verification results and functional requirement information, and performs functional verification on the second PMS code.

[0149] The implementation method of the electronic device to perform functional verification of the second PMS code can be found in the description of steps s3-s6 above, and will not be repeated here.

[0150] s8, the electronic device acquires the second fault characteristic and performs anomaly analysis on the second fault characteristic to obtain the cause of the second fault.

[0151] The second fault characteristic is the characteristic generated by the intercepted object; the second fault cause is used to indicate the reason why the electronic device fails to simulate the underlying resources for cross-process communication during Binder interception.

[0152] s9, the electronic device determines the second fault cause and the second fault characteristic as the verification result.

[0153] The electronic device identifies the second fault characteristic and the second fault cause as verification results and sends the verification results to the first intelligent agent.

[0154] s10, the electronic device calls the first intelligent agent to obtain the third PMS code based on the functional requirement information and verification results, and performs functional verification on the third PMS code.

[0155] The implementation method of electronic devices performing functional verification of the third PMS code can be found in the description of steps s3-s6 above, and will not be repeated here.

[0156] As can be seen, when the controlled execution environment is successfully constructed, the electronic device verifies the first code based on the test code; when the controlled execution environment is not successfully constructed, the electronic device interrupts the functional testing process and returns the verification result to modify the first code. In other words, the electronic device only performs functional verification in a controlled execution environment, which is beneficial for obtaining accurate functional verification results.

[0157] The following describes the functional verification device provided in the embodiments of this application.

[0158] Please see Figure 5 , Figure 5 This is a schematic diagram of a functional verification device provided in an embodiment of this application. The functional verification device may include a transceiver unit 510 and a processing unit 520.

[0159] The transceiver unit 510 is used to acquire the code and test requirement information corresponding to the function to be verified; the test requirement information includes functional requirement information and / or code change information.

[0160] Processing unit 520 is configured to: determine the scope of test concern based on the code corresponding to the function to be verified and the test requirement information; analyze and process the scope of test concern to obtain dependency call relationships; generate dependency isolation objects based on the dependency call relationships and configure the dependency isolation objects in the test execution context to obtain a controlled execution environment; in the controlled execution environment, determine test code based on the scope of test concern and verify the code corresponding to the function to be verified based on the test code to obtain a verification result; the verification result is used at least to indicate whether the code corresponding to the function to be verified meets the requirements corresponding to the function requirement information, and whether the code corresponding to the function to be verified can run normally.

[0161] In one possible implementation, the processing unit 520 is further configured to perform structured difference analysis on the code change information when the test requirement information includes code change information, to obtain one or more of the target class, target method and target interface corresponding to the function to be verified; and to determine one or more of the target class, target method and target interface corresponding to the function to be verified as the scope of test concern.

[0162] In one possible implementation, the processing unit 520 is further configured to: generate a proxy object based on the native interface call relationship when the dependency call relationship includes the native interface call relationship; use the proxy object to return the preset result or error status of the native interface call relationship when the electronic device does not depend on the underlying resources; generate an interception object based on the cross-process communication interface call relationship when the dependency call relationship includes the cross-process communication interface call relationship; use the interception object to simulate the underlying resources for cross-process communication when the electronic device does not depend on the underlying resources; and determine the proxy object and / or the interception object as dependency isolation objects when the proxy object returns the preset result of the native interface call relationship and the interception object successfully simulates the underlying resources for cross-process communication.

[0163] In one possible implementation, the processing unit 520 is also used to configure dependency isolation objects in the test execution context, and the test execution context controls the class loading order, interface call routing, and lifecycle management.

[0164] In one possible implementation, the verification result is a structured verification result, which includes one or more of the following: error type identifier, location information and call path information of the code that triggered the error, test case information, and dependency isolation status information.

[0165] In one possible implementation, the transceiver unit 510 is further configured to send the verification result to the first intelligent agent when the verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, or the code corresponding to the function to be verified cannot run normally; receive the correction code from the first intelligent agent; the correction code is the code generated by the first intelligent agent based on the verification result; the processing unit 520 is further configured to determine the test focus scope and controlled execution environment corresponding to the correction code based on the correction code, and verify whether the correction code meets the requirements corresponding to the functional requirement information and whether the correction code can run normally in the controlled execution environment corresponding to the correction code.

[0166] In one possible implementation, the processing unit 520 is also used to perform multiple rounds of verification and feedback correction on the code generated by the first intelligent agent, so that the code corresponding to the function to be verified is gradually optimized until the code generated by the first intelligent agent passes the verification or reaches the preset termination condition.

[0167] In one possible implementation, the transceiver unit 510 is further configured to acquire a first fault feature when the verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, or the code corresponding to the function to be verified cannot run normally; the processing unit is further configured to determine a first fault cause based on the first fault feature; the first fault feature is feature information generated by the execution of the code corresponding to the function to be verified; and the first fault cause and the first fault feature are added to the verification result.

[0168] In one possible implementation, the processing unit 520 is further configured to search for a repair suggestion that matches the first fault cause in the repair knowledge base; and if a repair suggestion is found, to add the repair suggestion to the verification result.

[0169] In one possible implementation, the transceiver unit 510 is further configured to obtain a second fault characteristic when the proxy object returns an error state of the native interface call relationship, or when the interceptor fails to simulate cross-process communication using underlying resources; the second fault characteristic is characteristic information generated by the generated dependency isolation object; the processing unit is further configured to perform anomaly analysis on the second fault characteristic to obtain the cause of the second fault; the cause of the second fault and the second fault characteristic are determined as the verification result, and the verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, and the code corresponding to the function to be verified cannot run normally.

[0170] This application also provides a computer device; please refer to [link / reference]. Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application.

[0171] like Figure 6 As shown, the computer device may include one or more processors 610, one or more memories 630, one or more communication interfaces 620, and a bus 640, wherein the processors 610, memories 630, and communication interfaces 620 are connected via the bus 640. The computer device may be the functional verification device described above.

[0172] The memory 630 is used to store a program; the processor 610 is used to execute the program stored in the memory. When the program is executed, the processor 610 performs the method in any possible implementation of the above-described functional verification method.

[0173] It should be understood that, in the embodiments of this application, the memory 630 mentioned above includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CDROM), as well as external memory other than computer memory and processor cache. A portion of the memory 630 may also include non-volatile random access memory. For example, the memory 630 may also store device type information.

[0174] The processor 610 described above can be one or more central processing units (CPUs). If the processor 610 is a CPU, it can be a single-core CPU or a multi-core CPU. The processor 610 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0175] The steps performed in the foregoing embodiments can be based on the above. Figure 6 The computer device shown is implemented in a way that the processor 610 can execute any of the optional implementations of the functional verification method provided in this application, or it can execute the implementation of the functional verification device described in this application. Specifically, the processor 610 can implement... Figure 5 The processing unit 520 in the functional verification device shown herein performs the functions of the device. The communication interface 620 enables... Figure 5 The transceiver unit 510 in the functional verification device shown herein has the following functions. The memory 630 can provide a cache when the processor 610 executes the implementation of the functional verification device described in the embodiments of this application, and can also store the computer programs required by the processor 610 to execute the implementation of the functional verification device described in the embodiments of this application.

[0176] This application also provides a computer storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, enable the processor to implement the above-mentioned functions. Figure 2 and Figure 3 The method shown.

[0177] This application also provides a computer program product, which includes: instructions or a computer program; when the instructions or the computer program are executed, the above-mentioned functions can be achieved. Figure 2 and Figure 3 The method shown.

[0178] This application also provides a chip, which includes a processor. The processor executes instructions, enabling the chip to achieve the aforementioned... Figure 2 and Figure 3 The method shown is described above. Optionally, the chip also includes a communication interface for receiving or transmitting signals.

[0179] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by hardware related to computer programs. The computer programs can be stored in computer storage media, and when executed, they can implement the processes of the above method embodiments. The aforementioned computer storage media include various media capable of storing computer program code, such as read-only memory (ROM) or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A functional verification method, characterized in that, The method is applied to an electronic device, and the method includes: Obtain the code and test requirement information corresponding to the function to be verified; the test requirement information includes functional requirement information and / or code change information. Based on the code corresponding to the function to be verified and the test requirement information, the scope of test focus is determined; The test focus area is analyzed and processed to obtain the dependency call relationship; A dependency isolation object is generated based on the dependency call relationship, and the dependency isolation object is configured in the test execution context to obtain a controlled execution environment; In the controlled execution environment, test code is determined based on the test focus, and the code corresponding to the function to be verified is verified based on the test code to obtain a verification result; the verification result is at least used to indicate whether the code corresponding to the function to be verified meets the requirements corresponding to the functional requirement information, and whether the code corresponding to the function to be verified can run normally.

2. The method as described in claim 1, characterized in that, The determination of the testing focus based on the code corresponding to the function to be verified and the testing requirement information includes: If the test requirement information includes the code change information, perform a structured difference analysis on the code change information to obtain one or more of the target class, target method, and target interface corresponding to the function to be verified. One or more of the target class, target method, and target interface corresponding to the function to be verified are identified as the scope of test interest.

3. The method as described in claim 1, characterized in that, The dependency call relationships include native interface call relationships and / or cross-process communication interface call relationships. Generating a dependency isolation object based on the dependency call relationships includes: When the dependency call relationship includes the native interface call relationship, a proxy object is generated based on the native interface call relationship; when the electronic device does not depend on the underlying resources, the proxy object is used to return the preset result or error status of the native interface call relationship. When the dependency call relationship includes the cross-process communication interface call relationship, an interception object is generated based on the cross-process communication interface call relationship; when the electronic device does not depend on the underlying resources, the interception object is used to simulate the underlying resources for cross-process communication. If the proxy object returns a preset result of the native interface call relationship, and the interceptor object successfully simulates cross-process communication using underlying resources, the proxy object and / or the interceptor object will be identified as dependency isolation objects.

4. The method as described in claim 3, characterized in that, Configuring the dependency isolation object in the test execution context includes: Configure the dependency isolation object in the test execution context, and let the test execution context control the class loading order, interface call routing and lifecycle management.

5. The method as described in claim 1, characterized in that, The verification result is a structured verification result, which includes one or more of the following: error type identifier, location information and call path information of the code that triggered the error, test case information, and dependency isolation status information.

6. The method as described in claim 1, characterized in that, The electronic device includes a first intelligent agent, and the method further includes: If the verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the function requirement information, or if the code corresponding to the function to be verified cannot run normally, the verification result is sent to the first intelligent agent. Receive correction code from the first agent; the correction code is code generated by the first agent based on the verification result; Based on the corrected code, determine the test focus and controlled execution environment corresponding to the corrected code, and in the controlled execution environment corresponding to the corrected code, verify whether the corrected code meets the requirements corresponding to the functional requirement information, and whether the corrected code can run normally.

7. The method as described in claim 6, characterized in that, The method further includes: The code generated by the first intelligent agent is subjected to multiple rounds of verification and feedback correction, so that the code corresponding to the function to be verified is gradually optimized until the code generated by the first intelligent agent passes the verification or reaches the preset termination condition.

8. The method as described in claim 6, characterized in that, Before sending the verification result to the first intelligent agent, the method further includes: If the verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, or if the code corresponding to the function to be verified cannot run normally, a first fault feature is obtained, and a first fault cause is determined based on the first fault feature; the first fault feature is feature information generated by the execution of the code corresponding to the function to be verified. Add the first fault cause and the first fault characteristic to the verification result.

9. The method as described in claim 8, characterized in that, The method further includes: Search the repair knowledge base for repair suggestions that match the cause of the first fault; If the suggested repair is found, it will be added to the verification results.

10. The method as described in claim 3, characterized in that, The method further includes: If the proxy object returns an error state regarding the native interface call relationship, or if the interception object fails to simulate cross-process communication using underlying resources, a second fault characteristic is obtained; the second fault characteristic is the characteristic information generated by the dependency isolation object. Anomaly analysis was performed on the second fault characteristic to determine the cause of the second fault. The second fault cause and the second fault characteristic are determined as the verification result. The verification result indicates that the code corresponding to the function to be verified does not meet the requirements corresponding to the functional requirement information, and the code corresponding to the function to be verified cannot run normally.

11. A functional verification device, characterized in that, The functional verification device includes: The transceiver unit is used to acquire the code and test requirement information corresponding to the function to be verified; the test requirement information includes functional requirement information and / or code change information. The processing unit is used to determine the scope of testing concern based on the code corresponding to the function to be verified and the test requirement information; The processing unit is also used to analyze and process the scope of test interest to obtain dependency call relationships; The processing unit is also configured to generate a dependency isolation object based on the dependency call relationship, and configure the dependency isolation object in the test execution context to obtain a controlled execution environment; The processing unit is further configured to determine test code based on the test concern scope in the controlled execution environment, and verify the code corresponding to the function to be verified based on the test code to obtain a verification result; the verification result is at least used to indicate whether the code corresponding to the function to be verified meets the requirements corresponding to the functional requirement information, and whether the code corresponding to the function to be verified can run normally.

12. An electronic device, characterized in that, The device includes a memory and one or more processors; the memory is coupled to the one or more processors for storing a computer program, the computer program including program instructions; the one or more processors invoke the program instructions to cause the electronic device to perform the method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-10.

Images