An application code diagnosis method, device and system

Abstract

The application discloses an application code diagnosis method, device and system, and aims at solving the problem of low efficiency in judging whether the application code for updating is abnormal. The scheme provided by the application comprises the following steps: obtaining second test result information of application code to be diagnosed; when the second test result information comprises abnormal information, obtaining first test result information of a target application of the first version; generating test result similarity according to the test result information and the first test result information; and when the test result similarity is less than a first preset similarity threshold, generating a first diagnosis result representing that the application code is abnormal. According to the scheme, whether the abnormality of the application after updating is caused by the application code is determined by comparing the test result of the application after updating with the test result of the application before updating, and the efficiency of diagnosing the application code is effectively improved.

Description

Technical Field

[0001] This invention relates to the field of application diagnostics, and more particularly to an application code diagnostic method, apparatus, and system. Background Technology

[0002] An application program can refer to a computer program that performs one or more specific tasks, runs on a user's terminal, and interacts with the user. Because user needs are constantly changing, applications also need to be continuously updated to meet various user requirements.

[0003] When an older version of an application is updated, errors may occur due to program bugs or other reasons. Because the structure of applications is often complex, it is difficult to efficiently determine whether an application error is caused by an update.

[0004] The technical problem this application aims to solve is how to efficiently determine whether the application code used for updates is abnormal. Summary of the Invention

[0005] The purpose of this application embodiment is to provide an application code diagnosis method to solve the problem of low efficiency in determining whether application code used for updates is abnormal.

[0006] Firstly, an application code diagnostic method is provided, including:

[0007] Obtain second test result information of the application code to be diagnosed, the application code being used to update the first version of the target application to the second version of the target application, the second test result information representing the result of performing functional tests on the second version of the target application;

[0008] When the second test result information includes abnormal information, the first test result information of the first version of the target application is obtained, and the first test result information represents the result of performing functional testing on the first version of the target application.

[0009] Based on the second test result information and the first test result information, a test result similarity is generated;

[0010] When the similarity of the test results is less than a first preset similarity threshold, a first diagnostic result representing the abnormality of the application code is generated.

[0011] Secondly, an application code diagnostic device is provided, comprising:

[0012] The first acquisition module acquires the second test result information of the application code to be diagnosed. The application code is used to update the first version of the target application to the second version of the target application. The second test result information represents the result of performing a functional test on the second version of the target application.

[0013] The second acquisition module acquires the first test result information of the first version of the target application when the second test result information includes abnormal information. The first test result information represents the result of performing functional tests on the first version of the target application.

[0014] The first generation module generates a test result similarity based on the second test result information and the first test result information;

[0015] The second generation module generates a first diagnostic result that characterizes the application code as abnormal when the similarity of the test results is less than a first preset similarity threshold.

[0016] Thirdly, an application code diagnostic system is provided, including:

[0017] An application code diagnostic device as described in the second aspect;

[0018] A test equipment group communicatively connected to the application code diagnostic device, the test equipment group including at least one test device, the test devices in the test equipment group meeting the test standards of the application code to be diagnosed.

[0019] Fourthly, an electronic device is provided, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the method of the first aspect.

[0020] Fifthly, a computer-readable storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the steps of the method of the first aspect.

[0021] In this embodiment, second test result information of the application code to be diagnosed is obtained; when the second test result information includes abnormal information, first test result information of the target application of the first version is obtained; a test result similarity is generated based on the test result information and the first test result information; when the test result similarity is less than a first preset similarity threshold, a first diagnostic result characterizing the abnormality of the application code is generated. This solution effectively improves the efficiency of diagnosing application code by comparing the test results of the updated application with the test results of the application before the update to determine whether the abnormality of the updated application is caused by the application code. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0023] Figure 1 This is one of the flowcharts illustrating an application code diagnostic method according to an embodiment of the present invention;

[0024] Figure 2 This is a second schematic flowchart of an embodiment of the application code diagnosis method of the present invention;

[0025] Figure 3 This is a schematic flowchart of the application code diagnosis method according to an embodiment of the present invention;

[0026] Figure 4 This is the fourth flowchart illustrating an embodiment of the application code diagnostic method of the present invention;

[0027] Figure 5 This is the fifth flowchart illustrating an embodiment of the application code diagnostic method of the present invention;

[0028] Figure 6 This is a schematic flowchart of an embodiment of the application code diagnosis method of the present invention, number six.

[0029] Figure 7 This is the seventh flowchart of an embodiment of the application code diagnosis method of the present invention;

[0030] Figure 8 This is a schematic diagram of the structure of an application code diagnostic device according to an embodiment of the present invention;

[0031] Figure 9 This is a schematic diagram of the structure of an application code diagnostic system according to an embodiment of the present invention. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. The drawing numbers in this application are only used to distinguish the various steps in the solution and are not used to limit the execution order of the various steps. The specific execution order is as described in the specification.

[0033] To address the problems in the prior art, this application provides an application code diagnostic method. The executing entity can be a server, terminal, or other electronic device, and it can be applied to fields such as network management, big data, web applications, and business support. This solution... Figure 1 As shown, it includes the following steps:

[0034] S11: Obtain the second test result information of the application code to be diagnosed, the application code being used to update the first version of the target application to the second version of the target application, the second test result information representing the result of performing functional tests on the second version of the target application.

[0035] The target application in this application embodiment can be a terminal application in the Android system or the iOS system, a web application, or an application in various systems developed through collaborative code development by multiple people.

[0036] The second test result information may include the test results of pre-performed functional tests on the second version of the target application. These test results can indicate whether the functionality of the second version of the target application meets the update requirements. For example, suppose the first version of the target application cannot call the target plugin, and the application code is used to update the target application to a second version that can call the target plugin. Then, the aforementioned functional test may include testing whether the second version of the target application can call the target plugin normally. If it can call it normally, a second test result indicating that the second version of the target application functions normally is generated.

[0037] S12: When the second test result information includes abnormal information, obtain the first test result information of the first version of the target application, wherein the first test result information represents the result of performing functional testing on the first version of the target application.

[0038] The target application (version 1), first test result information, target application (version 2), and second test result information mentioned above can be pre-stored in a code repository and a log repository. For example, the code repository can store code for all versions of the target application, specifically including unreleased, rolled-back, and released code. The log repository can store production records from user terminals or test terminals with the target application installed. Optionally, the log repository can store information about requests between each interface related to the target application, including request return codes, request initiation times, and request end times.

[0039] If the second test result information includes exception information, it indicates that the second version of the target application has a functional exception. To determine in subsequent steps whether the exception in the second version of the target application is caused by the application code used for the update, this step obtains the first test result information of the first version of the target application before the update. This first test result information can be obtained by performing functional tests on the first version of the target application beforehand. This first test result information can be stored in a code repository or a log repository; this step can retrieve the first test result information of the first version of the target application from the code repository and the log repository.

[0040] Additionally, this step utilizes a pre-defined monitoring and analysis module to detect the second test result information and determine whether it contains any abnormal information. Furthermore, detected abnormal information can be collected, summarized, and marked so that subsequent steps can determine whether the anomalies in the second version of the target application are caused by the aforementioned application code.

[0041] S13: Generate a test result similarity based on the second test result information and the first test result information.

[0042] The second and first test results respectively characterize whether the second and first versions of the target application function correctly. In this step, a test result similarity score can be generated based on features such as the number and type of errors in the second and first test results. This score represents the similarity between the functional abnormalities of the second and first versions of the target application.

[0043] S14: When the similarity of the test results is less than the first preset similarity threshold, a first diagnostic result representing the abnormality of the application code is generated.

[0044] For example, if the types and number of functional exceptions increase significantly after updating the target application from version 1 to version 2, it can be determined that these increased functional exceptions are caused by the application code, thus generating a primary diagnostic result characterizing the application code's anomalies. If the types and number of functional exceptions do not change significantly after the update, it can be determined that these functional exceptions are those exhibited by the target application in version 1, and are not caused by the update.

[0045] The aforementioned first preset similarity threshold can be manually set in advance according to actual needs, or it can be automatically generated based on historical data.

[0046] This solution compares the test results of the updated application with those of the application before the update to determine whether the anomalies in the updated application are caused by the application code. This effectively improves the efficiency of diagnosing application code, making it easier for staff to efficiently diagnose anomalies in the target application and improve repair efficiency.

[0047] Optionally, the solution provided in this application embodiment can be executed before releasing the application code to diagnose the application code and determine whether there are any anomalies in the application code used to update the target application. If the diagnosis determines that the application code has anomalies, the application code can be modified in a timely manner, avoiding the problem of a large number of users experiencing target application errors due to the widespread release of the application code.

[0048] Based on the solutions provided in the above embodiments, optionally, such as Figure 2As shown, after step S13 above, the following steps are also included:

[0049] S21: When the similarity of the test results is greater than the second preset similarity threshold, a second diagnostic result is generated to characterize the abnormality of the target application in the first version, wherein the second preset similarity threshold is greater than or equal to the first preset similarity threshold.

[0050] In this embodiment, the second preset similarity threshold can be manually set in advance according to actual needs, or it can be automatically generated based on historical data. This second preset similarity threshold is greater than or equal to the first preset similarity threshold mentioned above.

[0051] When the similarity of the test results exceeds a second preset similarity threshold, it indicates that the functional anomalies exhibited by the first version of the target application are similar to those exhibited by the updated second version of the target application. In other words, the application code used to update the target application did not cause any new anomalies to appear in the target application. At this point, it can be determined that the anomalies in the updated second version of the target application are anomalies present in the previous version, thereby generating a second diagnostic result characterizing the anomalies of the first version of the target application.

[0052] The solution provided in this application can efficiently diagnose whether anomalies in an updated target application are caused by the application code used for the update. When the anomalies exhibited by the target application before and after the update are similar, a second diagnostic result representing the anomalies of the first version of the target application before the update is generated. This allows staff to efficiently determine whether the anomalies exhibited by the second version of the target application are caused by the application code, and thus allows for the execution of repairs for the anomalies in the first version of the target application, thereby improving the efficiency of repairing abnormal applications.

[0053] Based on the solutions provided in the above embodiments, optionally, such as Figure 3 As shown, step S13 above includes the following steps:

[0054] S31: Perform clustering on the first error log in the second test result information and the first error log in the first test result information respectively to obtain the second clustering result and the first clustering result.

[0055] Specifically, error logs in the test results information can be identified based on preset field identifiers, and then text analysis tools and big data analysis tools can be used to perform clustering on the first and second error logs respectively.

[0056] For example, assuming the first error log contains multiple error logs, these logs can be categorized based on features such as the process or page that caused the error, the time of the error, the relevant interface, the process that caused the error, and the IP and port that caused the error, resulting in a first clustering result. Clustering allows error logs with similar characteristics to be categorized and summarized, facilitating comparison between the first and second error logs and thus improving the efficiency of diagnosing application code.

[0057] S32: Generate the test result similarity based on the second clustering result and the first clustering result.

[0058] In this step, the second and first clustering results can be compared based on the characteristics of the error logs to generate a test result similarity score. For example, the similarity score can be generated based on the type and number of errors, the process of the error, and the page on which it occurs. The test result similarity score generated in this step can characterize the difference between the first and second clustering results, indirectly indicating the difference in error reporting between the target application before and after the update.

[0059] Based on the solutions provided in the above embodiments, optionally, such as Figure 4 As shown, step S32 above includes:

[0060] S41: Generate feature similarity based on at least one of the following features from the second clustering result and the first clustering result: the processing page where the error occurred, the time when the error occurred, the calling interface where the error occurred, the calling process where the error occurred, and the server address and port address called when the error occurred.

[0061] In this embodiment, it is assumed that the target application is a web application. The error handling page mentioned above can include the web page that reported the error, which can be used to locate the code segment in the target application that caused the error. The time of the error can include the time period or moment when the target application reported the error or the server received the error, which can be used to locate the process that caused the error. The API call that caused the error, the calling process that caused the error, and the server address and port address called when the error occurred can be used to improve the accuracy of locating the code segment that caused the error.

[0062] S42: Generate the test result similarity based on the feature similarity of each feature of the second clustering result and the first clustering result.

[0063] When multiple feature similarities are generated from the above steps, a test result similarity can be calculated based on these multiple feature similarities and their corresponding weights. This test result similarity characterizes the differences in various features between the first and second versions of the target application.

[0064] The solution provided by the embodiments of this application can generate a test result similarity based on the similarity of various features of the first clustering result and the second clustering result, so that the generated test result similarity accurately represents the difference between the second test result information and the first test result information.

[0065] Based on the solutions provided in the above embodiments, optionally, such as Figure 5 As shown, before step S11 above, the following steps are also included:

[0066] S51: Obtain the application code to be diagnosed and the test standard of the application code to be diagnosed.

[0067] The aforementioned testing criteria may include the application code's functionality, applicable platform or system, and hardware and software requirements. For example, the testing criteria may include that the target application is version 1 and has available storage space greater than MB.

[0068] S52: The application code is sent to a test equipment group including at least one test device to instruct the test equipment group to perform functional tests on the application code and provide feedback on the test results of the application code to be diagnosed, wherein the test devices in the test equipment group meet the test standards of the application code to be diagnosed.

[0069] The aforementioned test equipment group may include multiple test devices, all of which meet the testing standards for the application code. For example, each device in the test equipment group has the first version of the target application installed, and each has more than M of storage space to perform functional testing on the application code, thus avoiding functional test failures due to software or hardware incompatibility.

[0070] The aforementioned testing equipment group, also known as a gray-scale environment, is used to test application code before its large-scale release, identifying errors and vulnerabilities so that staff can make corrections before mass deployment. For example, this gray-scale environment could be a subsystem comprising a backend testing environment and a frontend production environment. A new version of the code is released to a small group of customers via a limited number of servers, allowing these customers to use the application's functionality and for monitoring and testing. If no anomalies are found in the gray-scale environment, the application code is then extended to the full release environment. This release environment can refer to all customers with the target application installed. If anomalies are found in the gray-scale environment, the application service is stopped and the version is rolled back to the previous version. This allows for timely correction of the application code based on any anomalies detected in the gray-scale environment.

[0071] Based on the solutions provided in the above embodiments, optionally, such as Figure 6 As shown, the solution provided in this embodiment also includes:

[0072] S61: Obtain the association information of the application code to be diagnosed, the association information including at least one of the following: terminal information associated with the application code, user information associated with the application code, software information associated with the application code, and communication address information associated with the application code;

[0073] Following step S14 above, the following is also included:

[0074] S62: Send the first diagnostic result based on the association information of the application code to be diagnosed.

[0075] After identifying an application code anomaly, this step sends a preliminary diagnostic result based on the associated information of the application code. Specifically, this associated information may include account information of relevant personnel such as the development team and development managers associated with the application code. Sending the preliminary diagnostic result based on this associated information ensures that these personnel are promptly informed of the application's diagnostic results, facilitating the corrective action taken against the abnormal application code.

[0076] In addition, the associated information of the application code to be diagnosed may also include terminal information associated with the application code, such as the address information of the terminal that edited or modified the application code. The terminal can be a mobile phone, a smart wearable device, a computer, a server, or other electronic device. This terminal information can be presented in various forms. For example, the terminal information can be a mobile phone number. The first diagnostic result can be sent to the mobile phone via voice call, SMS, etc., so that relevant personnel of the application code can learn about the application code anomaly by answering the call or checking the SMS.

[0077] By linking the application code to the terminal information, the application diagnostic results can be sent to the terminal that edited or modified the application code in a timely manner. This allows relevant personnel to be notified of application code anomalies through the aforementioned terminal and to make timely corrections.

[0078] The associated information of the application code to be diagnosed may also include software information associated with the application code. For example, the software information may include information about office software, chat software or other communication software associated with the application code. Sending the first diagnostic result through the associated software information can facilitate the relevant personnel of the application code to be informed of the application code abnormality in a timely manner through the associated software and to process the application code as soon as possible.

[0079] In addition, the associated information of the application code to be diagnosed may also include communication address information, such as the IP address of the electronic terminal or the email address associated with the application code. This communication address information allows messages about application code anomalies to be sent to the relevant personnel corresponding to that address, enabling timely correction.

[0080] In addition, the initial diagnostic results can be sent in other ways that are easily accessible to relevant personnel. For example, they can be sent via web pop-ups, application notification messages, etc., so that personnel involved in the application code can view the initial diagnostic results immediately and efficiently, which helps improve the efficiency of fixing application code anomalies.

[0081] The aforementioned first diagnostic result may include information on anomalies characterized by the first and second versions of the target application, first test result information, second test result information, and test result similarity. Furthermore, a fault notification can be generated based on this first diagnostic result to notify relevant personnel of the abnormal code to promptly fix it. This facilitates efficient error localization in the application code by staff using the first diagnostic result, thereby improving repair efficiency.

[0082] See Figure 7 Below, we will illustrate the execution steps of this solution with examples from real-world application scenarios:

[0083] Step 1: Developers submit a new code release request through the work order flow management module to request the release of a new version of the code to the gray environment. The work order should include at least the person in charge or the team in charge, the superior and subordinate managers, the code information attached, the corresponding process, and the corresponding interface module information.

[0084] Step 2: The superior approves the work order. If approved, the work order proceeds to the next step; otherwise, it is returned and the process ends.

[0085] This step is optional. The superior approver can be someone associated with the target application and its code. This step enables access control and prevents unauthorized execution of application code.

[0086] Step 3: The work order flow management module records the approved new code release application forms and backs up the associated code information to the code repository.

[0087] The aforementioned work order flow management module can be a functional module set up on the server, and the attached code information can include the application code itself and related comments and other information.

[0088] Step 4: The server will release the new version of the code to the gray-scale environment as required.

[0089] In this step, the new version code, i.e. the application code mentioned above, can be released by the server after the work order flow management module has completed its recording process, or it can be manually released by staff according to actual needs.

[0090] Step 5: The monitoring and analysis module simulates user behavior at a specified period and initiates functional tests in a gray-scale environment. If the test runs successfully, proceed to Step 6. If the test returns unexpected results or there are errors, proceed to Step 7, the anomaly diagnosis process.

[0091] The specified period can be set according to requirements, and the monitoring and analysis module can be a functional module set up within the server. Specifically, user behavior can be pre-recorded and periodically executed by the monitoring and analysis module to simulate user behavior. Alternatively, the monitoring and analysis module can automatically generate behaviors based on the user's historical behavior using machine learning or other methods to simulate user actions. A successful test includes the target application in the gray-scale environment implementing the specified function; otherwise, the test is considered a failure.

[0092] Step 6: The monitoring and analysis module scans the background logs at a specified period to confirm whether there are any error records in the logs of the gray-scale environment. If there are no log errors and the simulation test in step 5 is successful, the scanning period is considered normal. The monitoring and analysis module will process step 5 in a cycle according to the periodic plan. If log errors are found, the process will proceed to step 7, the anomaly diagnosis process.

[0093] Step 7: The monitoring and analysis module enters the anomaly diagnosis process. Using text analysis and big data analysis tools, it compares the error logs discovered in this cycle with the error information in the logs before the new version was released. Through cluster analysis and difference rate analysis, it focuses on comparing the similarity of fields such as the error processing page, processing time, called interface, calling process, called server IP and port, and description of the returned result after processing. If the similarity with previous logs is below the threshold, it is considered an anomaly caused by the release of the new version code, and proceeds to Step 9; if the similarity with previous logs is above the threshold, it is considered a code error that existed in the original version, and proceeds to Step 8.

[0094] Step 8: The monitoring and analysis module determines that the error log is a code error present in the original version. It then calls the work order management module to check if any previous errors corresponding to this error have already been handled by someone. If someone has already handled it, the current cycle's anomaly diagnosis process ends, and the log error is tagged "Registered" to avoid duplicate processing. If no one has yet handled it, proceed to Step 10.

[0095] The aforementioned work order flow management module can be used to manage work order flow information for all personnel and teams, and manage the status information of each code release work order, including at least the person in charge of the work order, the responsible team, the superior and subordinate managers, the development application, the attached code information, the corresponding process, the corresponding interface module information, the release application, the rollback application, and other information.

[0096] Step 9: The monitoring and analysis module determines that the error log is an exception caused by the release of a new version of the code. It further identifies the code element information involved and confirms which version of the code the error belongs to, the process number, and the interface number by further analyzing the log records. It then queries the corresponding version of the interface and process code in the code repository to confirm the code segments that may be affected.

[0097] Step 10: If the monitoring and analysis module cannot find information such as the code version, interface number, and process number of the error, it is determined that the fault has no responsible party. The work order flow management module is then called to automatically create a work order and notify the person in charge to handle it.

[0098] Step 11: If the monitoring and analysis module finds code element information such as the code version, interface number, and process number of the error, it will use the relevant information as keywords to call the work order flow management module interface to find the person in charge or the team responsible for the code.

[0099] Step 12: If the work order flow management module interface returns confirmation that the person in charge or the team responsible for the problem code is on duty, the monitoring and analysis module calls the work order flow management module interface to create a fault notification form for the corresponding personnel, notify them to check and repair the code, and notify them to take the problem code offline and roll it back.

[0100] Step 13: If the person in charge or the team responsible for the problem code returned by the work order flow management module interface is not on duty, the monitoring and analysis module calls the work order flow management module interface to create a fault notification form for the corresponding person in charge, notifying them to check and fix the code, and to take the problem code offline and roll it back.

[0101] Step 14: After receiving the fault notification, the fault handler can access the corresponding code in the code repository through the work order, and can also control the offline rollback of the code in the canary release / release environment through the work order.

[0102] After completing the above steps and confirming that the application code is free of errors, it can be deployed to the release environment to update the target application for a large number of users.

[0103] This invention can be applied to systems where multiple developers collaborate on code development. The execution entity of this method can include modules such as a code repository, a workflow management module, a log repository, a monitoring and analysis module, and a canary release / release environment. This invention manages and records code releases in a workflow format and analyzes system log information after release and canary releases through multi-dimensional monitoring and scanning. By analyzing error log tags, it intelligently detects which errors are caused by a specific version of the code release, which programmers or development teams are responsible for the programming, and automatically pushes the workflow to relevant personnel to issue alerts and drive code error repair.

[0104] The solution provided in this embodiment specifically addresses the limitation of application code diagnosis and can be applied to various systems developed through multi-person collaborative code development. Furthermore, this invention proposes automated and intelligent detection of abnormal code after system deployment, effectively improving the efficiency of repairing and handling abnormal application code. This invention's solution can analyze log information after code deployment, establishing a retrieval relationship between error-prone interfaces, versions, and other tag information and records within the workflow. This allows for quick identification of the developers / teams and responsible parties of the original problematic code through the workflow, enabling timely inspection and repair. In addition, by analyzing the differences in system logs before and after deployment, this invention effectively identifies which errors are caused by the current version of the code deployment, significantly improving the efficiency of anomaly localization.

[0105] To address the problems existing in the prior art, this application also provides an application code diagnostic device 80, such as... Figure 8 As shown, it includes:

[0106] The first acquisition module 81 acquires the second test result information of the application code to be diagnosed. The application code is used to update the first version of the target application to the second version of the target application. The second test result information represents the result of performing a functional test on the second version of the target application.

[0107] The second acquisition module 82, when the second test result information includes abnormal information, acquires the first test result information of the first version of the target application, wherein the first test result information represents the result of performing functional testing on the first version of the target application.

[0108] The first generation module 83 generates a test result similarity based on the second test result information and the first test result information;

[0109] The second generation module 84 generates a first diagnostic result characterizing the application code as abnormal when the similarity of the test results is less than a first preset similarity threshold.

[0110] The apparatus provided in this embodiment can acquire second test result information of the application code to be diagnosed; when the second test result information includes abnormal information, it acquires first test result information of the target application of the first version; based on the test result information and the first test result information, it generates a test result similarity; when the test result similarity is less than a first preset similarity threshold, it generates a first diagnostic result characterizing the abnormality of the application code. This solution effectively improves the efficiency of diagnosing application code by comparing the test results of the updated application with the test results of the application before the update to determine whether the abnormality of the updated application is caused by the application code.

[0111] Optionally, the apparatus provided in this embodiment further includes a third generation module 85, used for:

[0112] When the similarity of the test results is greater than the second preset similarity threshold, a second diagnostic result is generated that characterizes the first version of the target application as abnormal, wherein the second preset similarity threshold is greater than or equal to the first preset similarity threshold.

[0113] Optionally, in the apparatus provided in this embodiment, the first generation module 83 is used for:

[0114] Clustering is performed on the first error log in the second test result information and the first error log in the first test result information respectively to obtain the second clustering result and the first clustering result;

[0115] The test result similarity is generated based on the second clustering result and the first clustering result.

[0116] Optionally, in the apparatus provided in this embodiment, the first generation module 83 is used for:

[0117] A feature similarity is generated based on at least one of the following features from the second clustering result and the first clustering result: the processing page where the error occurred, the time when the error occurred, the API call where the error occurred, the calling process where the error occurred, and the server address and port address called when the error occurred.

[0118] The test result similarity is generated based on the feature similarity of each feature of the second clustering result and the first clustering result.

[0119] Optionally, the device provided in this embodiment further includes a third acquisition module 86:

[0120] Obtain the application code to be diagnosed and the test standards for the application code to be diagnosed;

[0121] The application code is sent to a test equipment group, which includes at least one test device, to instruct the test equipment group to perform functional tests on the application code and provide feedback on the test results of the application code to be diagnosed, wherein the test devices in the test equipment group meet the test standards of the application code to be diagnosed.

[0122] Optionally, the device provided in this embodiment further includes a fourth acquisition module 87:

[0123] Obtain the associated work order for the application code to be diagnosed, the associated work order including the address that generated the application code;

[0124] It also includes a sending module 88, which, after generating a first diagnostic result characterizing the application code as abnormal, sends the first diagnostic result to the address where the application code was generated.

[0125] The solution provided in this embodiment specifically addresses the limitation of application code diagnosis and can be applied to various systems developed through multi-person collaborative code development. Furthermore, this invention proposes automated and intelligent detection of abnormal code after system deployment, effectively improving the efficiency of repairing and handling abnormal application code. This invention's solution can analyze log information after code deployment, establishing a retrieval relationship between error-prone interfaces, versions, and other tag information and records within the workflow. This allows for quick identification of the developers / teams and responsible parties of the original problematic code through the workflow, enabling timely inspection and repair. In addition, by analyzing the differences in system logs before and after deployment, this invention effectively identifies which errors are caused by the current version of the code deployment, significantly improving the efficiency of anomaly localization.

[0126] To address the problems existing in the prior art, embodiments of this application also provide an application code diagnostic system, such as... Figure 9 As shown, it includes:

[0127] An application code diagnostic device 91 as described in any of the above embodiments;

[0128] A test equipment group 92 is communicatively connected to the application code diagnostic device 91. The test equipment group includes at least one test device 93, and the test device 93 in the test equipment group 92 meets the test standards of the application code to be diagnosed.

[0129] Optionally, embodiments of the present invention also provide an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described application code diagnostic method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0130] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, this computer program implements the various processes of the above-described application code diagnostic method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0131] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0132] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0133] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. An application code diagnostic method, characterized in that, include: The second test result information is obtained from the grayscale environment of the application code to be diagnosed. The application code is used to update the first version of the target application to the second version of the target application. The second test result information represents the result of performing functional tests on the second version of the target application. When the second test result information includes abnormal information, the first test result information of the first version of the target application is obtained, and the first test result information represents the result of performing functional testing on the first version of the target application. Based on the second test result information and the first test result information, a test result similarity is generated; When the similarity of the test results is less than a first preset similarity threshold, a first diagnostic result characterizing the abnormality of the application code is generated; When the similarity of the test results is greater than the second preset similarity threshold, a second diagnostic result is generated that characterizes the first version of the target application as abnormal, wherein the second preset similarity threshold is greater than or equal to the first preset similarity threshold.

2. The method as described in claim 1, characterized in that, Based on the second test result information and the first test result information, a test result similarity is generated, including: Clustering is performed on the first error log in the second test result information and the first error log in the first test result information respectively to obtain the second clustering result and the first clustering result; The test result similarity is generated based on the second clustering result and the first clustering result.

3. The method as described in claim 2, characterized in that, Based on the second clustering result and the first clustering result, the similarity of the test results is generated, including: A feature similarity is generated based on at least one of the following features from the second clustering result and the first clustering result: the processing page where the error occurred, the time when the error occurred, the API call where the error occurred, the calling process where the error occurred, and the server address and port address called when the error occurred. The test result similarity is generated based on the feature similarity of each feature of the second clustering result and the first clustering result.

4. The method as described in claim 1, characterized in that, Before obtaining the second test result information for the application code to be diagnosed, the following is also included: Obtain the application code to be diagnosed and the test standards for the application code to be diagnosed; The application code is sent to a test equipment group, which includes at least one test device, to instruct the test equipment group to perform functional tests on the application code and provide feedback on the second test result information of the application code to be diagnosed, wherein the test devices in the test equipment group meet the test standards of the application code to be diagnosed.

5. The method as described in claim 1, characterized in that, Also includes: Obtain the association information of the application code to be diagnosed, the association information including at least one of the following: terminal information associated with the application code, user information associated with the application code, software information associated with the application code, and communication address information associated with the application code; After generating the first diagnostic result characterizing the application code anomaly, the process also includes: The first diagnostic result is sent based on the association information of the application code to be diagnosed.

6. An application code diagnostic device, characterized in that, include: The first acquisition module acquires second test result information of the application code to be diagnosed from the grayscale environment. The application code is used to update the first version of the target application to the second version of the target application. The second test result information represents the result of performing functional tests on the second version of the target application. The second acquisition module acquires the first test result information of the first version of the target application when the second test result information includes abnormal information. The first test result information represents the result of performing functional tests on the first version of the target application. The first generation module generates a test result similarity based on the second test result information and the first test result information; The second generation module generates a first diagnostic result indicating an anomaly in the application code when the similarity of the test results is less than a first preset similarity threshold; and generates a second diagnostic result indicating an anomaly in the target application of the first version when the similarity of the test results is greater than a second preset similarity threshold, wherein the second preset similarity threshold is greater than or equal to the first preset similarity threshold.

7. An application code diagnostic system, characterized in that, include: An application code diagnostic device as described in claim 6; A test equipment group communicatively connected to the application code diagnostic device, the test equipment group including at least one test device, the test devices in the test equipment group meeting the test standards of the application code to be diagnosed.

8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the method as described in any one of claims 1 to 5.

9. 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 steps of the method as described in any one of claims 1 to 5.

Images