Code testing method and device, equipment and medium

Abstract

The invention discloses a code testing method. The code testing method comprises the steps of performing first verification on a pre-published application program with code change according to a first verification process; wherein the first verification is multi-dimensional quality verification; performing functional splitting on the ROM code subjected to code change, and performing second verification on a plurality of functional modules obtained by splitting according to a second verification process; wherein the second verification is independent verification, and under the condition that both the first verification and the second verification pass, the pre-published application program and the ROM code are subjected to edition composing, and an edition composing result is obtained; and testing the plate composition result. Through a mode of combining multi-dimensional quality verification and independent verification, comprehensive testing of the application program and the ROM code is completed before version composition, early capture of problems is realized, a large amount of time cost is saved for subsequent testing and development, and the method has the advantages of improving the testing efficiency, reducing the maintenance cost and guaranteeing the software delivery quality.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent cockpit software testing, and in particular to a code testing method, device, equipment and medium. BACKGROUND

[0002] In the field of intelligent cockpit development and testing, the code iteration to the ROM (Read-Only Memory, ROM) version link has become a "neck" stage that hinders project progress. With the increasing complexity of cockpit software functions, the code size grows exponentially, and the version iteration frequency is greatly improved. In this process, serious problems such as boot failure and system crash frequently occur, and these problems have strong concealment and suddenness. Sometimes after a regular code update, seemingly unrelated functional module modifications will cause the cockpit system to be in a black screen state and have no response after the ROM version (which refers to the key link of fixing the final verified software code as a read-only memory ROM image and burning it to the vehicle hardware chip) is completed. Or in the process of system running, there is no feedback for operation, and it is completely deadlocked. The fault reproduction conditions are complex and it is difficult to quickly locate the root cause.

[0003] Currently, the project team has not yet built a complete and efficient problem interception mechanism. Traditional code review and unit testing can only find some surface logic errors, and there is almost no way to deal with deep-seated problems such as system-level compatibility and resource scheduling conflicts. This makes a large number of potential risks easily break through the early defense line and flow into the downstream testing and delivery process. In the testing link, the exposure of problems becomes more complex and difficult to deal with. Due to the lack of early interception, testers need to spend a lot of time and effort to conduct a comprehensive inspection of the entire system, not only prolonging the testing period, but also possibly causing the tester to be overwhelmed due to repeated problems, affecting the testing quality. These problems lead to prolonged testing period, increased maintenance cost, and seriously restrict the iteration efficiency of intelligent cockpit software. SUMMARY

[0004] In view of the above-mentioned shortcomings of the prior art, the present application provides a code testing method, device, equipment and medium for solving at least one defect in the prior art.

[0005] The code testing method provided by the present application comprises:

[0006] The pre-release application that has code changes is verified according to a first verification process; wherein the first verification is multi-dimensional quality verification;

[0007] The ROM code that has the code change is functionally split, and the plurality of function modules obtained by the splitting are subjected to second verification according to a second verification process; the second verification is independent verification,

[0008] In a case where the first verification and the second verification are both passed, the pre-release application and the ROM code are composed to obtain a composition result;

[0009] The composition result is tested.

[0010] In an embodiment of the present application, the first verification process comprises:

[0011] A first application is obtained, and the first application is a pre-release application after code change;

[0012] Difference analysis is performed on the first application and a second application to obtain a code change record; the second application is a reference application; the code change record comprises an incremental code change record and a function impact range list;

[0013] First verification is performed based on the code change record, and a test result report is generated.

[0014] In an embodiment of the present application, the second verification process comprises:

[0015] The ROM code is obtained at a set frequency as a first code;

[0016] Based on the first code and a second code, an incremental code is obtained; the second code is a baseline code;

[0017] The incremental code is subjected to incremental compilation, and a ROM image file is generated after the compilation is completed;

[0018] The ROM image file is subjected to second verification.

[0019] In an embodiment of the present application, before the ROM image file is subjected to second verification, the method further comprises:

[0020] The ROM image file is subjected to hash check and structure check.

[0021] In an embodiment of the present application, the incremental code is subjected to incremental compilation, comprising:

[0022] The incremental code is subjected to incremental compilation in a containerized environment.

[0023] In an embodiment of the present application, the incremental code is subjected to incremental compilation, comprising:

[0024] The incremental code is classified to determine a code change type; the code change type includes at least one of a Bug type change, a requirement type change, and another type change;

[0025] According to the code change type, a function impact point list is generated by using an analysis strategy corresponding to the code change type.

[0026] In an embodiment of the present application, if the code change type is a Bug type change, the analysis strategy includes:

[0027] A historical test case associated with the code change type is acquired;

[0028] A Bug repair suggestion is generated based on the historical test case.

[0029] In an embodiment of the present application, if the code change type is a requirement type change, the analysis strategy includes:

[0030] A requirement document associated with the code change type is acquired;

[0031] A key function point is extracted from the requirement document;

[0032] New function logic is generated based on the key function point.

[0033] In an embodiment of the present application, if the code change type is another type change, the analysis strategy includes:

[0034] A function module to which the incremental code belongs is located by analyzing a path of the incremental code;

[0035] A code dependency graph is constructed, and a superior-inferior reference relationship of the function module to which the incremental code belongs is determined based on the code dependency graph;

[0036] Based on the superior-inferior reference relationship, an associated module of the function module to which the incremental code belongs is identified;

[0037] A change propagation path of the associated module in the dependency graph is calculated;

[0038] A function impact point is generated based on the change propagation path.

[0039] In an embodiment of the present application, a ROM image file is generated after compilation is completed, and the second verification process further includes:

[0040] The ROM image file is acquired by using a ROM download tool, and hash check and structure check are performed on the ROM image file;

[0041] When the hash check and the structure check are passed, the ROM image file is decompressed by using a ROM download tool to obtain a target file.

[0042] In an embodiment of the present application, after the ROM image file is decompressed, the second verification process further includes:

[0043] establishing a data transmission channel between the ROM download tool and a flashing tool;

[0044] acquiring the target file by the flashing tool based on the data transmission channel;

[0045] performing parameter matching based on the target file;

[0046] when the parameter matching is successful, performing a burning operation by the flashing tool; wherein the target file is tested after the burning operation is completed.

[0047] In an embodiment of the present application, the parameter matching based on the target file includes:

[0048] accessing a data configuration file library by the flashing tool, and retrieving vehicle configuration parameters corresponding to the version identifier based on the version identifier of the target file;

[0049] matching the vehicle configuration parameters with current connected vehicle bench information; wherein, when the vehicle configuration parameters and the current connected vehicle bench information are matched successfully, the burning operation is performed by the flashing tool.

[0050] The present application provides a code testing device, which comprises:

[0051] a first verification module configured to perform first verification on a pre-release application with code change according to a first verification process; wherein the first verification is multi-dimensional quality verification;

[0052] a second verification module configured to perform functional splitting on a ROM code with code change, and perform second verification on a plurality of functional modules obtained by the splitting according to a second verification process; wherein the second verification is independent verification,

[0053] a layout module configured to perform layout on the pre-release application and the ROM code to obtain a layout result when the first verification and the second verification are both passed;

[0054] a testing module configured to test the layout result.

[0055] The present application provides an electronic device, which comprises:

[0056] one or more processors;

[0057] and a memory for storing one or more programs that, when executed by the one or more processors, cause the memory to implement the code testing method described above.

[0058] The application provides a machine readable medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the code testing method described above.

[0059] The application has the following advantages:

[0060] The code testing method comprises: performing first verification on a pre-release application with code change according to a first verification process; the first verification is multi-dimensional quality verification; performing functional splitting on ROM code with code change, and performing second verification on the plurality of functional modules obtained by the splitting according to a second verification process; the second verification is independent verification; when the first verification and the second verification are both passed, performing layout on the pre-release application and the ROM code to obtain a layout result; and testing the layout result. The application completes comprehensive testing of the application and the ROM code before layout by combining multi-dimensional quality verification and independent verification, realizes early capture of problems, saves a large amount of time cost for subsequent testing and development, and has the advantages of improving testing efficiency, reducing maintenance cost and guaranteeing software delivery quality. BRIEF DESCRIPTION OF DRAWINGS

[0061] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and serve to explain the principles of the application. It is readily apparent to one of ordinary skill in the art that the accompanying drawings only illustrate some embodiments of the application, and other drawings can be obtained from the accompanying drawings without creative labor.

[0062] In the drawings:

[0063] Figure 1 A flowchart of a code testing method according to an embodiment of the application;

[0064] Figure 2 A flowchart of a first verification process according to an embodiment of the application;

[0065] Figure 3 A flowchart of a second verification process according to an embodiment of the application;

[0066] Figure 4 A flowchart of an analysis strategy according to an embodiment of the application;

[0067] Figure 5 A flowchart of an analysis strategy according to another embodiment of the application;

[0068] Figure 6 a flow chart of a second verification process of an embodiment of the present application;

[0069] Figure 7 a schematic diagram of a code testing device of an embodiment of the present application;

[0070] Figure 8 a structural schematic diagram of a computer system suitable for implementing a memory of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0071] The embodiments of the present application will be described in detail with specific reference felt to the drawings, but the skilled in the art will understand that the present application is not limited to the specific examples described, and that the specific examples are provided for illustrative purposes only. The following embodiments and features of the embodiments can be combined with each other, where not in contradiction, and can be combined with other embodiments and features of the embodiments.

[0072] It should be noted that the diagrams in the following embodiments are only schematic and that, for clarity, the drawing can not demonstrate all of the components of the devices described herein. Further, dimensions of components may

[0073] In the following description, numerous specific details are discussed in order to provide a thorough understanding of the embodiments of the present application. However, the skilled in the art will understand that the embodiments of the present application can be practiced without these specific details. In other instances, well-known structures and devices are not described in detail in order not to obscure the understanding of this description.

[0074] Reference is made to Figure 1 , Figure 1 a flow chart of a code testing method of an embodiment of the present application. In Figure 1 the code testing method comprises:

[0075] In step S110, a first verification is performed on the pre-release application with code changes according to a first verification process; wherein the first verification is a multi-dimensional quality verification.

[0076] It should be noted that the multi-dimensional quality verification includes function test, performance test, compatibility test and complex scene test, and the multi-dimensional parallel test can be realized by using an automatic test framework. The function test includes verifying the logical completeness and boundary condition processing of the added / modified function, for example, detecting function abnormalities by inputting extreme parameter values. The performance test is used to detect resource consumption indicators, such as CPU / memory occupation, response delay, power consumption and other key indicators, which can be realized by using a performance analysis tool. The compatibility test refers to the test covering different Android versions, hardware configurations and third-party application interaction scenes, for example, verifying the UI adaptability on the vehicle machine screen with different resolutions. The complex scene simulation test refers to the stability test by constructing extreme scenes such as network fluctuation, low power and multi-task concurrency, and the fault injection technology can be used, for example, a signal jammer is used to simulate the vehicle-mounted electromagnetic interference environment.

[0077] In step S120, the ROM code that has undergone code changes is functionally split, and the plurality of function modules obtained by the splitting are subjected to second verification according to a second verification procedure; wherein the second verification is independent verification.

[0078] The ROM code refers to system-level software that is fixed to the vehicle machine hardware. The independent verification refers to the integrity verification of a single function module.

[0079] When the ROM code is modified, the code needs to be divided into a plurality of independent modules according to functions, and each function module is verified independently to ensure that each module can normally run in logic and function and does not interfere with each other.

[0080] In step S130, when the first verification and the second verification are both passed, the pre-release application and the ROM code are integrated to obtain an integrated result.

[0081] Under the premise that the first verification and the second verification are completed and the verification results are passed, the pre-release application (i.e. the software version that has not been officially released) and the ROM code are integrated to generate a final integrated result.

[0082] In step S140, the integrated result is tested.

[0083] Specifically, when the pre-release application undergoes code changes, multi-dimensional quality verification is first performed. Meanwhile, the ROM code is split according to function modules, and each module is independently compiled and verified. After the application verification and all module verifications are passed, the integrated operation is performed and the integrated system is tested as a whole.

[0084] The application effectively reduces the risk of faults caused by code changes and shortens the problem troubleshooting period by intercepting potential defects of the application layer and the system layer respectively before the composition of the version through a phased verification mechanism. Meanwhile, the multi-dimensional quality verification discovers the performance bottlenecks of the application program in advance, the independent verification avoids the abnormal propagation between modules, and the overall test verifies the stability of the system integration after the composition of the version. The method not only helps to reduce the problems in the downstream test and delivery process, but also comprehensively and substantially improves the overall quality of the project composition, significantly improves the quality controllability of the intelligent cockpit software version, and ensures that the composition process can run smoothly and stably.

[0085] Please refer to Figure 2 , Figure 2 The figure is a flowchart of the first verification process of an embodiment of the application. In Figure 2 , the first verification process includes:

[0086] Step S210, obtaining a first application program, the first application program being a pre-release application program after code changes;

[0087] The first application program refers to a to-be-verified version after code changes, which is used to represent the code state of the current iteration stage.

[0088] Step S220, performing difference analysis on the first application program and a second application program to obtain a code change record; the second application program being a benchmark application program; the code change record including an incremental code change record and a functional impact range list;

[0089] The second application program refers to a stable version as a comparison benchmark, which is used to compare the differences with the version after changes.

[0090] The difference analysis refers to identifying the code differences between the two versions through a code comparison tool, which can be implemented by using a Git Diff tool to generate a change content list by scanning the code library line by line.

[0091] The code change record includes an incremental code change record and a functional impact range list. The incremental code change record can extract the added, modified or deleted code fragments through the version control system log. The functional impact range list can track the functional modules associated with the changed code through a code dependency analysis tool.

[0092] Step S230, performing first verification based on the code change record and generating a test result report.

[0093] The test result report refers to a structured document recording the verification process and results, which is used to summarize the test coverage, defect list and verification conclusion.

[0094] Specifically, after completing the code change, a pre-release management system submits a task, automatically triggers a compilation process according to preset rules, adopts a specific version naming specification (such as a major version number, a minor version number, a revision number + a compilation timestamp), generates an APK (Android application package, application package, abbreviated as APK) file, that is, a first application program, by automatically packaging the changed code. The version control system extracts the pre-release application program with code changes as the first application program, and obtains the second application program as the reference. The first application program and the second application program are analyzed by a code diff tool to generate a code change record containing incremental code change records and a functional impact range list. The incremental code change record accurately marks the newly added, modified or deleted code lines, and the functional impact range list determines the modules and interfaces affected by the changed code through dependency analysis. After determining the code change record, the pre-release task system pushes the code change record to the test personnel. The pushed content includes APK download link, change point list attachment and test scope description. After downloading the APK package, the test personnel selects the appropriate installation method according to the car model and operating system version. During installation, record the installation time, whether there are error prompts, etc. If the installation fails, the developer needs to be notified in time, and detailed information such as installation logs and error screenshots needs to be provided. After the APK package is installed, the test personnel strictly follows the test cases to test the changed points and associated functional modules.

[0095] During the test process, professional test tools are used to record the performance data of the APP (such as response time, memory usage, CPU usage), and the test process evidence is retained through screenshots, screen recordings, etc. After the test is completed, according to the established result evaluation standard (such as passing for normal function implementation, and not passing for crash, data loss, etc.), a detailed test result report is output, including test environment, test steps, problem description, and problem severity classification. After the test is completed, the test personnel fills in the test result form in the APP approval assistant, uploads the test result report attachment, and clearly marks whether the test passes. At the same time, the test personnel needs to explain the processing suggestions for the problems found during the test in the form. If the test passes, the test personnel clicks the "agree" button in the APP approval assistant. The approval assistant automatically triggers the APK versioning process, merges the APK package with the official version ROM, and generates a versioning log. After the merging is completed, the system sends a version update success notification to the relevant personnel, and synchronously updates the version release record. When the test does not pass, the test personnel clicks the "reject" button in the APP approval assistant and fills in the rejection reason in detail. At this time, the APK will be locked and prohibited from merging into the official version ROM. The APP approval assistant automatically sends an email notification containing the test result report and the rejection reason to the corresponding developer.

[0096] The application accurately locks the change influence range through difference analysis, dynamically adjusts the test strategy in combination with the function influence list, focuses the verification process on the actual change area, avoids the resource waste of full regression test, can accurately identify the direct influence range of the code change, and avoids the fault omission caused by the code change.

[0097] Please refer to Figure 3 , Figure 3 The flowchart of the second verification process of an embodiment of the application is shown in FIG. 2. Figure 3 In the second verification process, the following steps are included.

[0098] In step S310, the ROM code is acquired at a set frequency as the first code.

[0099] The set frequency refers to an interval parameter of periodically triggering the code acquisition operation, and can be implemented in the form of hourly or daily timing triggering, for example, to ensure that the latest code change is captured in time.

[0100] In step S320, the incremental code is obtained based on the first code and the second code; the second code is the baseline code.

[0101] The incremental code refers to the difference code set between the current version and the baseline version, and can be generated by a code version comparison tool to realize the generation of a difference file, for avoiding full processing.

[0102] In step S330, the incremental code is compiled, and the ROM image file is generated after the compilation is completed.

[0103] The incremental compilation refers to the local compilation operation on the changed code, for reducing the compilation time and resource consumption.

[0104] The ROM image file refers to a firmware package containing a complete system running environment, for subsequent system flashing and test verification.

[0105] In step S340, the ROM image file is subjected to the second verification.

[0106] Specifically, after completing the modification of the system-level code (such as the instrument function module), the ROM code after the code change is submitted to the Gerrit service platform. At the same time, according to the unified naming specification (such as YYYYMMDD_function module abbreviation_requirement number, for example: 20250509_DashBoard_001), the code to be merged into the ROM is labeled with a Topic tag to clearly identify the functional attributes and integration requirements of the code, facilitating subsequent process tracking and management. During the code change process, the compilation service scans the Gerrit service platform at a set time interval, automatically obtains the latest ROM code with a Topic tag as the current version, and obtains the incremental code set of the current version relative to the stored baseline version through the git diff tool. At the same time, according to the project path matching the pre-set information in the compilation service knowledge base, a compilation parameter script is automatically generated. After the compilation service obtains the incremental code set and the compilation parameter script, it executes the compilation command in an isolated containerized environment, and monitors the compilation process and key indicators in real time. During the compilation process, incremental compilation, parallel processing (such as multiple compilation tasks) and resource optimization strategies (such as reasonable allocation of container resources) are adopted to shorten the compilation time and improve the utilization of server resources. After the compilation is completed, a ROM image file containing complete system components is generated, and then the file integrity and format specification are verified by a double verification mechanism of hash check and structure check. After completing the verification of the ROM image file, the ROM image file that passes the verification is stored in the storage service according to the date creation path of the Topic tag. During the compilation process, the compilation log is recorded in real time, and if a compilation error occurs, the ROM code is repaired according to the fault recorded in the compilation log.

[0107] The present application accurately limits the compilation range to the changed code area through the incremental processing mechanism, effectively shortening the build time. At the same time, a double verification strategy is introduced to complete the integrity verification during the file generation stage, avoiding the problem of image damage in the traditional process being discovered only in the subsequent link, realizing accurate identification and efficient verification of ROM code changes, reducing the compilation resource consumption to the level of only processing differential code, and effectively intercepting image file abnormalities through the pre-check mechanism.

[0108] In an embodiment, before the second verification of the ROM image file, the method further comprises: performing hash check and structure check on the ROM image file.

[0109] The hash check refers to verifying data integrity by generating a fixed-length check value through a hash algorithm, which can be implemented by using SHA-256 or MD5 algorithm, and is used to detect whether the ROM image file has been tampered with or accidentally damaged during transmission or storage.

[0110] The structure verification refers to verifying whether the format and partition structure of the ROM image file meet preset specifications, and can be implemented by analyzing file header information, checking partition table integrity and verifying file system format, and is used to ensure that the ROM image file can be correctly identified and loaded by target hardware.

[0111] Specifically, after the ROM code is incrementally compiled to generate an image file, the verification process is automatically triggered. The hash verification module first calculates the hash value of the ROM image file and compares it with the pre-stored reference hash value. If they are inconsistent, it is determined that the file is abnormal. Then, the structure verification is performed. By analyzing the binary structure of the image file, it is verified whether the partition layout matches the storage mapping rules of the target device, for example, checking whether the starting addresses and sizes of the boot partition, system partition and data partition meet the design requirements. If both verifications pass, the ROM image file is marked as valid and enters the subsequent process; if any verification fails, an alarm log is generated and the process is interrupted.

[0112] The present application can prevent data abnormalities and ensure hardware compatibility through a double verification mechanism, significantly reducing the risk of system startup failure caused by image errors, effectively intercepting system failures caused by damaged or structurally incorrect image files before ROM versioning, and avoiding problems such as black screen and freezing from flowing into downstream testing links.

[0113] In an embodiment, the incremental code is incrementally compiled, including: incrementally compiling the incremental code in a containerized environment.

[0114] The containerized environment refers to an independent running environment constructed through operating system-level virtualization technology, which can be implemented using Docker or Kubernetes platform, and is used to isolate the system environment of the host from the dependencies required for compilation, avoiding compilation errors caused by environment differences.

[0115] Specifically, during the code change processing, a standardized compilation environment image is first created by the container engine, and the image is pre-installed with compiler tool chains, third-party libraries and configuration files. When the incremental code is identified, the incremental code is mounted to the working directory of the container instance, and then the compilation instruction is executed in the container. During the compilation process, the container ensures the consistency of the dependency version through file system isolation, and only calls the compiler to generate target files for the changed code files. For example, when fixing a bug in a module, the containerized compilation only rebuilds the module and its directly associated code, without processing the entire code base.

[0116] The application unifies the compilation dependency through the containerized environment, eliminates the environmental configuration interference, significantly shortens the compilation time by combining the incremental compilation strategy, solves the compilation failure problem caused by inconsistent development environments, reduces the build risk introduced by code changes, and improves the compilation efficiency. In the scene of intelligent cockpit multi-supplier code integration, the verification and compilation of specific modules can be quickly completed, stable ROM image files are provided for subsequent test links, and the problem interception and repair process is accelerated.

[0117] In an embodiment, the incremental code is incrementally compiled, including: classifying the incremental code, determining the code change type; the code change type includes at least one of the following: Bug type change, requirement type change, other type change; according to the code change type, an analysis strategy corresponding to the code change type is used to generate a function affected point list.

[0118] The code change type refers to the category of attribute division of the code modification content, which can be automatically identified by using the label information in the code submission record. The change type label is forced to be selected during code submission, so that the modification intention can be quickly distinguished. During code submission, commit information is synchronously submitted. The structured fields in the commit information include: Type: change type (Bug / requirement / other), IssueId: problem / demand ID, Project: belonging project, Description: change description, Aoe: affected function point / module

[0119] The analysis strategy is a differentiated processing logic designed for different change types, for example, automatically associating the historical test case library for Bug type changes, extracting requirement document keywords for requirement type changes, and performing code path analysis for other type changes.

[0120] The function affected point list refers to the list of function module association relationships that may be triggered by the code change.

[0121] Specifically, when the incremental code is classified as a Bug type change, the system automatically retrieves the historical test cases associated with this type of change, for example, by matching the code modification location and the function name covered by the test case, generating repair suggestions and marking the boundary conditions that need to be verified. For requirement type changes, the system parses the function description in the requirement document, extracts the key parameter threshold or interaction process, and generates a test path for the new function logic. When the change type belongs to other types, the system parses the code file storage path, locates the corresponding function module, constructs a code call dependency graph, identifies the upper modules directly called and the lower modules called, and traverses the dependency chain by combining the change propagation algorithm to generate a list of all possible affected associated modules.

[0122] The application can dynamically adjust the analysis depth according to different change types through the classification processing mechanism, in this way, the latest ROM version and its change details can be obtained in time, so that the test work can be carried out in a targeted manner, and the communication of the whole research and development and test process is more smooth, and the efficiency is significantly improved.

[0123] In an embodiment, if the code change type is a Bug type change, the analysis strategy includes: obtaining historical test cases associated with the code change type; and generating Bug repair suggestions based on the historical test cases.

[0124] The historical test cases refer to a set of executed test cases associated with the current Bug type change, and the historical Bug repair records and corresponding test cases can be retrieved through a defect tracking module in a test management system.

[0125] The Bug repair suggestions refer to a set of optimization measures for the current code change, and the code modification records in the historical test cases are analyzed through a code difference comparison tool, and the code modification suggestions and test case adjustment schemes are generated in combination with the current change content.

[0126] Specifically, when it is detected that the code change type belongs to the Bug repair type, the Bug ID (such as JIRA number) is extracted from the IssueId field to determine the corresponding Bug, and then the affected function points are obtained according to the Aoe field, and the Bug management system is queried to automatically extract the historical test cases and corresponding repair suggestions associated with the Bug type from the Bug management system library, and finally the targeted test points are generated. For example, in the scene of repairing the problem of touch screen failure of the intelligent cockpit touch module, the system will retrieve all test cases related to touch logic in the historical case library, extract the test steps, input parameters and expected results. Subsequently, the differences between the current change code and the historical repair code are analyzed through a code version comparison tool, the common characteristics of the repair logic are identified, and based on these common characteristics, a repair suggestion document containing code modification suggestions, regression test range and risk prompts is generated, and the new test cases are updated to the test case library.

[0127] The application reduces the manual investigation time through the automatic matching of historical cases and the generation of repair suggestions, avoids the repeated occurrence of similar problems after the ROM group version, thereby shortens the test period and reduces the maintenance cost.

[0128] Please refer to Figure 4 , Figure 4 is the flowchart of the analysis strategy of an embodiment of the application. In Figure 4 , if the code change type is a requirement type change, the analysis strategy includes:

[0129] In step S410, the requirement documents associated with the code change type are obtained.

[0130] The demand document refers to a complete technical document recording the change of the function demand, and is used for clearly defining the specific function target and implementation path of the demand change.

[0131] In step S420, the key function points are extracted through the demand document.

[0132] The key function points refer to the core function modules or interface specifications defined in the demand document, and ensure that the change content covers all necessary function elements.

[0133] In step S430, the new function logic is generated based on the key function points.

[0134] The new function logic refers to the code implementation scheme designed according to the key function points, and ensures that the code implementation and the demand definition maintain a strict corresponding relationship.

[0135] Specifically, when it is detected that the code change belongs to the demand type, the system extracts the demand ID from the IssueId field, parses the associated module from the Aoe field, and then automatically associates the demand document in the version control library, so as to extract the key function points in the demand document. Based on the extracted function points, the code generator automatically creates the corresponding interface class and method framework, and generates a unit test case template. In this process, the function constraint conditions in the demand document are converted into parameter verification logic in the code, so as to prevent the function implementation from deviating from the original demand definition.

[0136] The present application establishes the topological relationship graph between the function points by structurally analyzing the demand document, automatically identifies the cross-module influence points, ensures the integrity of the change implementation, and effectively solves the problem of incomplete function coverage in the demand change implementation process.

[0137] Please refer to Figure 5 , Figure 5 the flowchart of the analysis strategy of an embodiment of the present application. In Figure 5 , if the code change type is other type change, the analysis strategy includes:

[0138] In step S510, the function module to which the incremental code belongs is located by analyzing the path of the incremental code.

[0139] The path analysis of the incremental code refers to determining the function module involved in the code modification by analyzing the directory level and naming rules in the code storage path, and can specifically use a file system path analysis algorithm or a version control tool to achieve, and is used for quickly locating the physical position of the code change.

[0140] In step S520, a code dependency graph is constructed, and the superior-inferior reference relationship of the function module to which the incremental code belongs is determined based on the code dependency graph.

[0141] The code dependency graph refers to a module interdependence visualization model generated by analyzing function calls and variable reference relationships in the code, and is used to reveal the calling links between modules.

[0142] In step S530, the associated modules of the function module to which the incremental code belongs are identified based on the upper and lower reference relationships.

[0143] The upper and lower reference relationships refer to the calling dependencies between code modules, including upper reference and lower reference. The upper reference refers to the fact that a certain module is referenced, called, and dependent on other modules. The lower reference refers to the fact that a certain module references, calls, and depends on other modules. For example, the function module to which the incremental code belongs is the instrument panel backlight control module, the upper reference of which is the automatic headlight module, and the lower reference of which is the internal call PWM driver.

[0144] In step S540, the change propagation path of the associated module in the dependency graph is calculated.

[0145] The change propagation path refers to a path set of all associated modules that can be reached from the changed module through the dependency edges in the dependency graph, and is used to predict the possible cascading impact range caused by the code change.

[0146] In step S550, the function impact points are generated based on the change propagation path.

[0147] The function impact point list is a list of function modules to be verified generated based on the propagation path, and can be generated by path node extraction, and is used to guide the priority ordering of test cases.

[0148] Specifically, when the code change type does not belong to bug fixing or requirement change, the function module involved in the modification is first determined by analyzing the file path information in the code submission record. Then, the code dependency graph is constructed based on the function call relationship between modules, and the upstream calling module and the downstream called module of the function module are identified. For example, the audio control module can be called by the car entertainment system, and the underlying driver interface is also called. All reachable module paths from the changed module are calculated by a graph traversal algorithm. Finally, the function impact point list is generated according to the propagation path.

[0149] The present application can systematically identify the associated module exceptions triggered by the change by constructing the code dependency graph and the propagation path analysis, thereby covering the potential risk scenarios in the test phase in advance, and effectively solving the problem of hidden system failure caused by complex code changes.

[0150] In an embodiment, a ROM image file is generated after the compilation is completed, and the second verification process further includes: obtaining the ROM image file by a ROM download tool, and performing hash checking and structure checking on the ROM image file; when the hash checking and the structure checking are both passed, decompressing the ROM image file by the ROM download tool to obtain the target file.

[0151] The ROM download tool is a special software for securely transmitting and analyzing the ROM image file.

[0152] Specifically, the ROM download tool establishes a connection with the storage service, and when the storage service completes the generation of the new version ROM file, immediately sends a message to the ROM download tool (a notification message containing metadata such as version number, storage path, and file hash value). The ROM download tool automatically monitors the file generation path, and immediately starts a download task after recognizing the new file, and transmits the ROM file to the specified storage directory. After the download is completed, the tool automatically calls the decompression program to decompress the compressed package according to the preset path, and generates a file directory structure that can be used for flashing. During the downloading of the ROM file, the ROM download tool automatically calculates the hash value of the ROM image file, and compares it with the original hash value recorded by the compilation server. If they are inconsistent, the process is terminated and an alarm log is generated. After the hash checking is passed, the ROM download tool further analyzes the internal structure of the image file, verifies whether the partition table offset and the file header identifier are consistent with the preset standard. If the structure checking fails, an error handling mechanism is triggered and an exception report is generated. When both double checks are passed, the ROM download tool calls the built-in decompression module to automatically process the ROM file according to the preset configuration, and arranges the decompressed files according to a specific directory structure (such as classified storage of firmware files, configuration files, and resource files), and finally outputs the file format that meets the requirements of the flashing tool, providing input for subsequent programming and testing links.

[0153] After downloading and decompressing, the latest version of the ROM file is in a ready state and can be directly used for automatic updating. Testers can save time and focus more on the core aspects of the testing work, such as function verification and performance testing, thereby significantly improving testing efficiency and quality and accelerating the overall progress of the project.

[0154] The double verification mechanism of hash checking and structure checking can effectively intercept image file abnormalities caused by network transmission errors, compilation environment abnormalities, or human operation errors, significantly reducing the risk of invalid programming and testing resource waste, and can identify and intercept data integrity damage and structure abnormality problems before the deployment of the ROM image file, avoiding system startup failure, function module loading abnormality, and other faults caused by image file errors, thereby improving the reliability of the intelligent cockpit system versioning link, shortening the problem troubleshooting period, and reducing the rework cost.

[0155] Referring to Figure 6 , Figure 6 A flowchart of a second verification process of an embodiment of the present application. In Figure 6 , after decompressing the ROM image file, the second verification process further includes:

[0156] Step S610, establishing a data transmission channel between the ROM download tool and the flashing tool;

[0157] The data transmission channel refers to a communication link for realizing data interaction between the ROM download tool and the flashing tool, and can specifically establish a physical connection by using USB direct connection or wireless network protocol, to ensure the stability and integrity of file transmission. The data transmission channel can adopt double-link redundancy design, for example, USB wired connection and Wi-Fi direct connection channels are established at the same time, and when the main link is interrupted, the standby link is automatically switched to continue transmission.

[0158] The flashing tool refers to a special software with firmware programming function, used for performing analysis and writing operation of the ROM image file.

[0159] Step S620, acquiring the target file through the flashing tool based on the data transmission channel;

[0160] Step S630, performing parameter matching based on the target file;

[0161] The parameter matching refers to verifying the compatibility of the target file and the target hardware device, to prevent programming failure or hardware damage caused by version mismatch. The parameter matching process can further integrate a digital signature verification mechanism, for example, embedding an encrypted hash value in the target file, and the flashing tool synchronously verifies the signature legality when matching the hardware parameters.

[0162] Step S640, performing programming operation through the flashing tool when the parameter matching is successful; wherein, the target file is tested after the programming of the target file is completed.

[0163] The parameter matching success means that the target file corresponds to the parameters of the target hardware device.

[0164] Specifically, after the ROM image file passes the hash check and the structure check, a dedicated communication link is first established between the ROM download tool and the flashing tool. The link can realize high-speed data transmission through the USB interface, and at the same time, the state synchronization of the two devices is ensured through the handshake protocol. When the flashing tool obtains the target file through the link, it immediately accesses the preset data configuration file library stored locally, extracts the metadata information such as the version number and the hardware adaptation list of the target file. Then, the vehicle bench device model and the hardware version number currently connected are compared with the metadata item by item, and when it is detected that the mainboard chipset model, memory capacity and other core parameters are completely consistent, the burning program execution is triggered.

[0165] The present application adds a parameter matching link before burning through a phased verification mechanism, effectively intercepts system failures caused by incompatible software versions and hardware platforms, effectively solves the problem of device failure caused by version mismatch during the ROM burning process of the intelligent cockpit, and intercepts the hardware compatibility risk before the execution of the burning operation through the parameter pre-verification mechanism.

[0166] In an embodiment, the parameter matching based on the target file includes: accessing the data configuration file library through the flashing tool, retrieving the vehicle configuration parameters corresponding to the version identifier based on the version identifier of the target file; and matching the vehicle configuration parameters with the current vehicle machine bench information; wherein, in the case that the vehicle configuration parameters and the current vehicle machine bench information are matched successfully, the flashing tool is used to execute the burning operation.

[0167] Among them, the data configuration file library refers to a database storing hardware configuration parameters of different vehicle models, which is used to quickly locate the adaptive configuration parameter set according to the version identifier.

[0168] The version identifier refers to a unique code used to distinguish different vehicle software versions, which can be implemented by using a hash value or a version number string, and is used to establish a parameter retrieval index in the data configuration library.

[0169] The vehicle configuration parameter refers to the driving parameter, interface protocol and performance threshold related to the hardware device of a specific vehicle model, which is used to ensure the compatibility of the software version and the hardware platform.

[0170] The vehicle machine bench information refers to the hardware model, firmware version and interface protocol of the currently connected test device, which is used to verify the matching degree of the target file and the physical device.

[0171] Specifically, before the burning operation is performed, the flashing tool first extracts the vehicle model configuration parameter set associated with the target file version identifier from the data configuration file library. For example, when the version identifier of the target file is V2.3.5, the flashing tool retrieves all vehicle model configuration parameters bound to this version in the database. Then, the system compares the retrieved configuration parameters with the currently connected vehicle bench hardware information item by item, for example, verifies whether the main control chip model of the vehicle bench is consistent with the processor architecture requirement in the configuration parameter. If all parameter items are matched, the burning process is triggered; if there are unmatched items, the operation is interrupted and an error log is generated.

[0172] The present application establishes a dynamic association mechanism between version identifier and configuration parameter, and forcibly performs hardware compatibility verification before burning, thereby blocking the operation risk caused by configuration mismatch from the root.

[0173] After the test end obtains the ROM version of the completed flashing, the corresponding Topic submission information (including code change content, functional impact range, test focus prompt, etc.) in the Gerrit platform is combined to perform targeted testing. For example, a combination of black box testing and white box testing is adopted to focus on verifying the correctness and stability of the modified function and associated modules, record abnormal phenomena and performance data in the testing process, and output detailed test reports. If the test result meets the expectation, the tester performs Verified+1 operation on the code submission in the Gerrit system, indicating that the code passes the verification. At this time, the system automatically unlocks the code submission, allowing it to enter the subsequent Code Review stage. After the review is passed, the code will be officially merged into the master repository according to the established process and become part of the project baseline version. If the test finds problems, the tester performs Verified-1 operation in the Gerrit system and fills in the test failure reason in detail, uploads the test report and problem screenshots as evidence. After the operation is completed, the code submission will be automatically locked and prohibited from entering the subsequent merging process, and the system will notify the R&D personnel through email and project management tools to repair the code. After the R&D personnel complete the repair, they need to resubmit the code and repeat the above verification process until the test passes.

[0174] In an embodiment, a test management system for managing the entire life cycle of testing is also provided. The test management system can implement the following functions:

[0175] 1) Test data real-time reporting: When performing a test task, enter the key information related to the test point through the test management system, including project basic information such as project name, product line, and person in charge; version information such as ROM version number, APP version number, and compilation time; test information such as test case number, test steps, and execution environment; and test result information such as test pass / fail status, defect description, and reproduction steps. The test management system uses structured form design to standardize data entry format and ensure information integrity and accuracy.

[0176] 2) Automatic data aggregation: The test management system has an intelligent data processing engine built-in, which automatically extracts all data generated by testing within a week based on project dimensions. Through pre-set data models and algorithms, key indicators such as test frequency, pass rate, defect distribution, and problem resolution rate are statistically analyzed to generate visual data reports. It also supports custom filtering conditions, allowing testers to flexibly adjust the data display range according to their needs.

[0177] 3) Visual report presentation: The test management system presents weekly test data aggregation results in intuitive chart forms such as bar charts, line charts, and pie charts. The report covers project overall test progress, version test pass rate trends, and defect proportion of different functional modules. Through dynamic interactive interfaces, users can click on charts to drill down to detailed data, quickly locate problems and assess test work effectiveness, providing strong data support for project management and decision-making.

[0178] Through the above test management system, detailed information, execution results, and problems discovered during each test task can be systematically recorded. At the same time, relying on the automated statistical functions of the test management system, weekly and monthly work achievement reports can be efficiently generated, and the value output of the test work can be quantitatively presented, completely avoiding the omissions and errors that may occur during manual statistics, significantly reducing labor costs. In addition, the test management system has good scalability and compatibility, laying a solid foundation for future project test management needs and continuous improvement of test efficiency.

[0179] Please refer to Figure 7 , Figure 7 for the schematic diagram of a code testing device according to an embodiment of the present application. In Figure 6 , the code testing device comprises:

[0180] a first verification module 710, configured to perform first verification on the pre-release application with code changes according to a first verification process; wherein the first verification is multi-dimensional quality verification;

[0181] The second verification module 720 is configured to perform functional splitting on the ROM code in which the code is changed, and perform second verification on the plurality of functional modules obtained by the splitting according to a second verification procedure. The second verification is independent verification.

[0182] The layout module 730 is configured to perform layout on the pre-release application and the ROM code when the first verification and the second verification are both passed, to obtain a layout result.

[0183] The test module 740 is configured to test the layout result.

[0184] It should be noted that the code testing apparatus provided in the above embodiments and the code testing method provided in the above embodiments belong to the same concept, and the specific operation manner of each module and unit has been described in detail in the method embodiments, which will not be repeated here. The code testing apparatus provided in the above embodiments can be used in actual application, and the above functions can be completed by different functional modules according to needs, that is, the internal structure of the apparatus is divided into different functional modules to complete all or part of the above described functions, and this is not limited herein.

[0185] Embodiments of the present application also provide an electronic device, including: one or more processors; and a memory for storing one or more programs, when the one or more programs are executed by the one or more processors, the memory implements the code testing method in the above embodiments.

[0186] Embodiments of the present application also provide one or more machine readable media having instructions stored thereon, when executed by one or more processors, the processors perform the code testing method in the above embodiments.

[0187] Figure 8 The structure schematic diagram of the computer system of the memory suitable for implementing the embodiments of the present application is shown. It should be noted that, Figure 8 The computer system of the memory shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0188] As Figure 8As shown, the computer system 800 includes a central processing unit (CPU) 801 which can perform various appropriate actions and processes in accordance with a program stored in a read-only memory (ROM) 802 or a program loaded from a storage section into a random access memory (RAM) 803, such as executing the method in the above-described embodiments. In the RAM, various programs and data required for the operation of the system are also stored. The CPU 801, the ROM 802, and the RAM 803 are connected to each other through a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0189] Connected to the I / O interface 805 are an input section 806 including a keyboard, a mouse, etc.; an output section 807 including a display device such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as necessary. A removable recording medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 810 as necessary, so that a computer program read therefrom is installed into the storage section 808 as necessary.

[0190] In particular, the processes described above with reference to the flowcharts can be implemented as a computer software program in accordance with embodiments of the present application. For example, embodiments of the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing code for performing the aforementioned code testing method. In such embodiments, the computer program can be downloaded and installed from a network via the communication section, and / or installed from the removable recording medium 811. When the computer program is executed by the central processing unit (CPU) 801, various functions defined in the system of the present application are performed.

[0191] It should be noted that the computer-readable medium in the embodiments of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium may, for example, be an electrical, magnetic, optical, electromagnetic, infrared or semiconductor system, device or component or any combination of the above. More specific examples of the computer-readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) 803, a read-only memory (ROM) 802, an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM), an optical storage device, a magnetic storage device or any suitable combination of the above. In the present application, the computer-readable signal medium can include a data signal carried in a baseband or as a carrier wave part of a carrier wave, which carries the computer-readable computer program. Such a propagated data signal can take various forms, including but not limited to an electromagnetic signal, an optical signal or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, which can send, propagate or transmit programs for use by or in connection with an instruction execution system, device or component. The computer program contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination of the above.

[0192] The flowcharts and block diagrams in the drawings illustrate the possible implementation architectures, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In the flowcharts or block diagrams, each block can represent a module, a program segment or a part of code, which contains one or more executable instructions for implementing the specified logic function. It should also be noted that in some alternative implementations, the functions indicated in the blocks can also occur in a different order from that indicated in the drawings. For example, two blocks indicated in succession can actually be executed substantially in parallel, and sometimes in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart or a combination of blocks in the flowchart can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0193] The units described in the embodiments of the present application can be implemented in the form of software, or can be implemented in the form of hardware, and the described units can also be arranged in a processor. In some cases, the names of the units do not constitute a limitation on the units themselves.

[0194] Another aspect of the present application also provides a computer readable storage medium, which stores a computer program. When the computer program is executed by a processor of a computer, the computer executes the code testing method as described above. The computer readable storage medium can be included in the memory described in the above embodiments, or can exist separately and not be assembled into the memory.

[0195] Another aspect of the present application also provides a computer program product or a computer program, which includes computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device executes the code testing method provided in each of the above embodiments.

[0196] The above embodiments only exemplarily illustrate the principles and effects of the present application, and are not used to limit the present application. Any person skilled in the art can modify or change the above embodiments without departing from the spirit and scope of the present application. Therefore, all equivalent modifications or changes completed by those skilled in the art without departing from the spirit and technical thought of the present application should be covered by the claims of the present application.

Claims

1. A code testing method, characterized in that: The code testing method includes: Performing a first verification on the pre-released application program that has undergone code changes according to a first verification process; wherein the first verification is a multi-dimensional quality verification; Functionally split the ROM code that has undergone code changes, and perform a second verification on the multiple functional modules obtained by the split according to the second verification process; wherein the second verification is an independent verification, If both the first verification and the second verification are passed, performing a compilation on the pre-release application and the ROM code to obtain a compilation result; The typesetting result is tested.

2. The code testing method according to claim 1, characterized in that: The first verification process includes: Obtaining a first application, where the first application is a pre-released application after a code change occurs; Performing a difference analysis on the first application and the second application to obtain a code change record; wherein the second application is a baseline application; the code change record includes: an incremental code change record and a list of functional impact scopes; A first verification is performed based on the code change record, and a test result report is generated.

3. The code testing method according to claim 1, wherein: The second verification process includes: Obtain ROM code at a set frequency as the first code; Obtaining an incremental code based on the first code and the second code, wherein the second code is a baseline code; Compile the incremental code incrementally and generate a ROM image file after the compilation is complete; A second verification is performed on the ROM image file.

4. The code testing method according to claim 3, characterized in that: Before performing the second verification on the ROM image file, the method further includes: Perform hash verification and structure verification on the ROM image file.

5. The code testing method according to claim 3, characterized in that: The incremental compilation of the incremental code includes: Incremental compilation of incremental code in containerized environments.

6. The code testing method according to claim 3, characterized in that: The incremental compilation of the incremental code includes: Classifying the incremental code to determine a code change type; the code change type includes at least one of the following: bug type change, requirement type change, and other type change; According to the code change type, an analysis strategy corresponding to the code change type is used to generate a function impact point list.

7. The code testing method according to claim 6, characterized in that: If the code change type is a bug type change, the analysis strategy includes: Get historical test cases associated with code change types; Generate bug fixing suggestions based on the historical test cases.

8. The code testing method according to claim 6, characterized in that: If the code change type is a requirement type change, the analysis strategy includes: Get the requirements document associated with the code change type; Extract key functional points through the requirement document; Generate new functional logic based on the key functional points.

9. The code testing method according to claim 6, characterized in that: If the code change type is other types of changes, the analysis strategy includes: Locating the functional module to which the incremental code belongs by parsing the path of the incremental code; Constructing a code dependency graph, and determining the upper and lower level reference relationships of the functional modules to which the incremental code belongs based on the code dependency graph; Based on the upper and lower level reference relationships, identifying associated modules of the functional module to which the incremental code belongs; Calculating a change propagation path of the associated module in the dependency graph; Functional impact points are generated based on the change propagation path.

10. The code testing method according to claim 3, characterized in that: After the compilation is completed, a ROM image file is generated, and the second verification process further includes: Obtain the ROM image file through a ROM download tool, and perform hash verification and structure verification on the ROM image file; When both the hash check and the structure check are passed, the ROM image file is decompressed using a ROM download tool to obtain a target file.

11. The code testing method according to claim 10, characterized in that: After decompressing the ROM image file, the second verification process further includes: Establish a data transmission channel between the ROM download tool and the flash tool; Based on the data transmission channel, obtaining the target file through the flashing tool; Perform parameter matching based on the target file; When the parameters are matched successfully, the burning operation is performed through the flashing tool; wherein, the target file is tested after the burning of the target file is completed.

12. The code testing method according to claim 11, characterized in that: The parameter matching based on the target file includes: Accessing the data configuration file library through the flashing tool, and retrieving the vehicle model configuration parameters corresponding to the version identifier based on the version identifier of the target file; The vehicle model configuration parameters are matched with the currently connected vehicle machine test bench information; wherein, if the vehicle model configuration parameters are successfully matched with the currently connected vehicle machine test bench information, a burning operation is performed through a flashing tool.

13. A code testing device, characterized in that: The code testing device comprises: A first verification module, configured to perform a first verification on a pre-release application program that has undergone code changes according to a first verification process; wherein the first verification is a multi-dimensional quality verification; The second verification module is used to functionally split the ROM code that has undergone code changes, and perform a second verification on the multiple functional modules obtained by the split according to the second verification process; wherein the second verification is an independent verification, a compilation module, configured to, if both the first verification and the second verification are passed, compile the pre-release application and the ROM code to obtain a compilation result; The testing module is used to test the typesetting result.

14. An electronic device comprising: one or more processors; and a memory for storing one or more programs, so that when the one or more programs are executed by one or more processors, the memory implements the code testing method according to any one of claims 1 to 12.

15. A machine-readable medium, characterized in that Instructions are stored thereon, which, when executed by one or more processors, enable the processors to execute the code testing method according to any one of claims 1 to 12.

Images