Software system monitoring method, equipment and medium

Abstract

The embodiment of the invention provides a software system monitoring method and device and a medium. The method comprises the steps of obtaining a target code interval of a software system, wherein the target code interval is a code interval being modified or a modified code interval to be tested; pushing a historical problem corresponding to the target code interval and a rewriting risk point and a test key point of the target code interval based on a pre-established data structure table; the data structure table comprises a historical problem corresponding to each code interval in the software system and a mark prompt, and the mark prompt of each code interval is used for indicating whether the code interval has a rewriting risk or not and / or whether each historical problem of the code interval is a test key point or not. The method is used for intelligently providing code transformation risks and test key points, and the reliability and high efficiency of analysis results are effectively guaranteed while the cost required by analysis is reduced.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a monitoring method, device, and medium for a software system. Background Art

[0002] Large-scale customer-facing software systems (software systems, such as online banking and mobile banking) are prone to code defects or problems (bugs) during their development, testing, and maintenance stages. Technical professionals hope that after fixing a code defect or problem, they can minimize the occurrence of the same bug or problem during subsequent modifications.

[0003] In the existing technology, technical personnel are usually required to summarize and analyze the code based on the content recorded by the monitoring device configured for the software system (for example, the operation status and historical problems of the software system, etc.) to provide guidance for subsequent code testing and modification processes and avoid the occurrence of repeated problems.

[0004] However, the methods in the existing technology not only require technicians to spend a lot of time to analyze, but also require technicians to have a full understanding of the software system code and pay close attention to the business functions and modification history of the software system. There are problems such as low analysis efficiency and high analysis costs. Summary of the Invention

[0005] The embodiments of the present application provide a monitoring method, device, and medium for a software system to intelligently provide code modification risks and test priorities. This not only reduces the workload of technical personnel and the cost of analysis, but also effectively ensures the reliability and efficiency of the analysis results, providing more convenience for the development and testing of software systems.

[0006] In a first aspect, an embodiment of the present application provides a method for monitoring a software system, comprising:

[0007] Obtaining a target code interval of the software system, wherein the target code interval is a code interval being modified or a modified code interval to be tested;

[0008] Based on a pre-established data structure table, historical issues corresponding to the target code interval, as well as rewriting risk points and test focus of the target code interval are pushed; the data structure table includes historical issues and marking prompts corresponding to each code interval in the software system, and the marking prompt of each code interval is used to indicate whether there is a rewriting risk in the code interval and / or whether each historical issue in the code interval is a test focus.

[0009] In a second aspect, an embodiment of the present application provides a monitoring device for a software system, comprising:

[0010] An acquisition unit, configured to acquire a target code interval of the software system, wherein the target code interval is a code interval being modified or a modified code interval to be tested;

[0011] The first push unit is used to push the historical problems corresponding to the target code interval, as well as the rewriting risk points and test focus of the target code interval based on a pre-established data structure table; the data structure table includes historical problems and marking prompts corresponding to each code interval in the software system, and the marking prompt of each code interval is used to indicate whether there is a rewriting risk in the code interval and / or whether each historical problem in the code interval is a test focus.

[0012] In a third aspect, an embodiment of the present application provides a computer device, including: a memory, a processor;

[0013] The memory stores computer-executable instructions;

[0014] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0015] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementation methods of the first aspect.

[0016] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0018] Figure 1 A flowchart of a monitoring method for a software system provided in Example 1 of the present application;

[0019] Figure 2 A flowchart of a software system monitoring method is provided for the third embodiment of the present application;

[0020] Figure 3 A schematic diagram of the structure of a monitoring device for a software system provided in Example 4 of the present application;

[0021] Figure 4 A schematic diagram of the structure of a monitoring device for a software system provided in Example 5 of the present application;

[0022] Figure 5 A schematic diagram of the structure of the computer device provided in this application.

[0023] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0024] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0025] First, let’s explain the terms involved in this application:

[0026] Bugs are undetected flaws or issues hidden within computer systems or software programs. If bugs aren't fixed promptly, they can be exploited by malicious attackers, threatening system security. They can also cause software malfunctions, preventing users from operating the software normally, ultimately leading to data loss and reduced work efficiency.

[0027] Large-scale customer-facing software systems are integrated and combined from multiple software or modules. Each module within the system has its own upstream and downstream connections, requiring multiple development, testing, and maintenance personnel. These systems are characterized by the potential for a single module defect to impact the entire system. They are targeted at a broad audience, involve a large number of customers, experience high concurrency, and exhibit strong real-time interactivity, making system bugs highly susceptible to customer losses.

[0028] In order to facilitate the understanding of the technical content of this solution, the following is a detailed introduction to the background technology:

[0029] Large-scale customer-facing software systems (such as online and mobile banking) are prone to bugs during their development, testing, and maintenance phases. For technical professionals, fixing a single code defect can be difficult to guarantee against similar issues during subsequent code modifications. Cases of production incidents caused by the same issue are common. This problem is particularly prone to occur during system handovers, or when two similar modules or functions have different owners, and a problem in one module is too late for the other to promptly identify and troubleshoot. Technical personnel aim to minimize repeating mistakes, learn from past mistakes, and use other issues to investigate their own systems, thereby reducing production incidents.

[0030] Existing software automation technology can currently monitor and generate alerts for software systems, as well as record past events. However, its limitations lie in that existing software system monitoring methods only record historical operational status, leaving subsequent analysis based on historical records to be performed manually. However, a software system has a long lifecycle, involves numerous technical personnel, and involves complex development and testing tasks. Relying solely on human effort to accurately analyze a software system's operational history to guide subsequent code testing and modification processes, thereby avoiding recurring issues, is an extremely difficult process. This process not only requires technicians to spend a significant amount of time analyzing the software, but also requires them to have a thorough understanding of the software code and a deep understanding of the software system's business functions and modification history. This leads to low analysis efficiency and high costs.

[0031] In response to the technical problems in the above-mentioned background technology, the inventors discovered during their research that for a software system, by pre-establishing a data structure table that includes historical problems that have occurred in each code interval layer of the software system, as well as marking prompts determined based on the frequency of occurrence of historical problems corresponding to the code interval, when developers modify the code or testers conduct system testing, they can automatically push historical problems corresponding to the code interval being modified or the modified code interval to be tested, as well as rewriting risk points and test priorities based on the data structure table.

[0032] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0033] Figure 1 A flowchart of a monitoring method for a software system provided in Example 1 of the present application is shown in FIG. Figure 1 As shown, the method includes:

[0034] S101 : Obtain a target code interval of a software system, wherein the target code interval is a code interval that is being modified or a modified code interval to be tested.

[0035] In this step, when a developer modifies the code of a software system or a tester tests the software system, the code section being modified or the modified code section to be tested will be obtained.

[0036] S102. Based on a pre-established data structure table, historical issues corresponding to the target code interval, as well as rewriting risk points and test priorities of the target code interval are pushed. The data structure table includes historical issues and marking prompts corresponding to each code interval in the software system. The marking prompt of each code interval is used to indicate whether the code interval has a rewriting risk and / or whether each historical issue in the code interval is a test priority.

[0037] In this step, it is necessary to obtain the historical problems corresponding to the target code interval based on the historical problems corresponding to each code interval recorded in the pre-established data structure table, and push the historical problems corresponding to the target code interval to the target terminal; at the same time, based on the historical problems and marking prompts corresponding to each code interval recorded in the pre-established data structure table, obtain the rewriting risk points and test focus of the target code interval, and push the rewriting risk points and test focus of the target code interval.

[0038] For each code interval, the historical issues corresponding to the code interval refer to the bugs that have occurred in the code interval in the past.

[0039] Specifically, the marking prompt for each code interval is used to indicate whether the code interval has a rewrite risk and / or whether each historical issue in the code interval is a test focus. It should be understood that for a code interval, whether the code interval has a rewrite risk can be determined based on the total number of historical issues corresponding to the code interval. When the total number is large, it indicates that the code interval has a rewrite risk. The number of identical historical issues in the historical issues corresponding to the code interval can be used to determine whether each historical issue in the code interval is a test focus. When the number is large, it indicates that the historical issue in the code interval is a test focus.

[0040] Furthermore, the pushed rewrite risk point is used to indicate to the developer whether the target code interval is a risky code interval. Optionally, if the target code interval is a risky code interval, the rewrite risk point may also include at least one code modification prompt based on the historical issues and markup prompts corresponding to the target code interval.

[0041] For example, if the mark corresponding to the target code interval in the data structure table indicates that the target code interval has a rewrite risk, and the historical problems corresponding to the target code interval include the historical problem of "precision errors occurred when calculating the payment amount, resulting in overcharging customers", then the pushed rewrite risk point may be: "The target code interval is a risky code interval. It should be noted that there were precision errors in the payment amount calculation in this code interval before. If the code logic related to the amount calculation is involved during rewriting, precision problems may be introduced again. It should be understood that the rewrite risk point is only illustrated here. When there are multiple historical problems corresponding to the target code interval, there will also be multiple corresponding code modification prompts.

[0042] The pushed test focus is used to indicate to the tester which issues in the target code interval require focused testing. For example, if the marker corresponding to the target code interval in the pre-established data structure table indicates that the historical issues corresponding to the target code interval, such as "precision errors occurred when calculating payment amounts, resulting in overcharging customers" and "the payment interface occasionally experiences connection timeouts under high concurrency conditions," are the test focus, then the pushed test focus may be: focusing on testing the accuracy of payment amount calculation (including payment situations of various amounts, handling of decimal amounts, etc.), and the connection status of the payment interface when multiple orders are paid simultaneously.

[0043] In the specific implementation of this solution, if the rewriting risk point indicates that the target code interval is a risky code interval, development technology experts and testing technology experts can be invited to conduct a seminar based on the historical issues corresponding to the target code interval obtained through push notification, as well as the rewriting risk points and testing priorities of the target code interval, to further determine the rewriting plan and testing process for the target code interval. By conducting seminars based on the historical issues corresponding to the target code interval obtained through push notification, as well as the rewriting risk points and testing priorities of the target code interval, not only can the pertinence of the meeting be improved, but the quality of the final rewriting plan and testing process can also be effectively improved.

[0044] In a specific implementation, the following method can be used to push historical issues corresponding to the target code interval, as well as rewriting risk points and test focus points of the target code interval based on a pre-established data structure table:

[0045] Step 1: Based on the historical issues and marked prompts corresponding to the target code interval in the data structure table, an analysis model is used to analyze and obtain the rewriting risk points and test focus of the target code interval. The analysis model is a model pre-trained by a machine learning model to analyze rewriting risk points and test focus based on code interval information.

[0046] In this step, the historical problems and marking prompts corresponding to the target code interval extracted from the data structure table need to be input into the analysis model. The analysis model performs a comprehensive analysis based on the historical problems corresponding to the target code interval and the information indicated in the marking prompts, and outputs the rewriting risk points and test focus of the target code interval.

[0047] Optionally, in actual applications, the analysis model can be an artificial intelligence analysis model, such as a large language model; it can also be an analysis model obtained by training an initial analysis model based on a sample set, wherein the sample set includes historical issues and marking prompts corresponding to multiple code intervals, as well as rewriting risk points and testing priorities of the code interval determined by expert discussions. The initial analysis model can be a deep learning model, a machine learning model, etc.

[0048] Optionally, the code in the target code range may be input into the analysis model so that the analysis model can analyze the code to identify more specific rewriting risk points and test priorities.

[0049] Optionally, if the data structure table also includes the priority of the degree of impact of each historical problem on the software system; then the rewriting risk points and test priorities can be obtained in the following manner: the historical problems, marking prompts and the priority of each historical problem corresponding to the target code interval in the data structure table are input into the analysis model for analysis to obtain the rewriting risk points and test priorities of the target code interval. It should be understood that adding the priority of the degree of impact of each historical problem on the software system to the input of the analysis model can further enrich the information in the rewriting risk points and test priorities output by the analysis model, so that technical personnel can pay more attention to problems that have occurred in the target code interval in the past and have serious impacts, and provide more convenience for the development and testing of the software system. Exemplarily, the test priorities can also include the top three historical problems with the highest priority.

[0050] Step 2: Push the historical issues corresponding to the target code interval, as well as the rewriting risk points and test focus of the target code interval to the target terminal, where the target terminal is a terminal device for modifying or testing the software system.

[0051] In this step, the rewrite risk points and test focus of the target code interval need to be pushed to the target terminal. Specifically, if the target code interval is a code interval being modified by a developer while modifying the software system code, the rewrite risk points of the target code interval will be pushed to the terminal device that modified the code in the software system; if the target code interval is a modified code interval to be tested by a tester while testing the software system, the test focus of the target code interval will be pushed to the terminal device that tested the code in the software system.

[0052] Optionally, if the data structure table also includes a priority for each historical issue's impact on the software system, after obtaining the historical issues corresponding to the target code interval from the data structure table, the historical issues can be sorted in descending order based on their priorities to obtain the sorted historical issues corresponding to the target code interval. The sorted historical issues corresponding to the target code interval can then be pushed to the target terminal. It should be understood that sorting historical issues by priority allows technicians to more intuitively focus on the key points of code rewriting or testing.

[0053] In a specific implementation, the software system monitoring method provided in this embodiment further includes:

[0054] Step 1: If other code intervals are called when modifying the target code interval, historical issues existing in the other code intervals in the data structure table are obtained.

[0055] In this step, if other code intervals are called when the developer modifies the target code interval, the historical issues corresponding to the other code intervals are obtained in the data structure table.

[0056] Among them, other code intervals are public methods or components in the software system that can be called by multiple different classes, modules or code areas.

[0057] Step 2: If it is found that there are historical issues in other code intervals, the historical issues and their priorities are pushed to the terminal that modifies the target code interval.

[0058] In this step, if the historical issues corresponding to the other code interval can be obtained in the data structure table, the obtained historical issues and their priorities will be pushed to the terminal that modifies the target code interval, so that developers can avoid the occurrence of repeated issues in advance.

[0059] In the specific implementation, if there is no historical problem in the other code interval in the data structure table, no push is performed; if there is one historical problem in the other code interval in the data structure table, the historical problem is pushed directly; if there are two or more historical problems in the other code interval in the data structure table, the acquired historical problems are first sorted in descending order of priority to obtain the sorted historical problems corresponding to the other code interval, and the sorted historical problems are pushed.

[0060] This implementation method obtains historical problems existing in other code intervals in the data structure table when calling other code intervals when modifying the target code interval. When historical problems are found in other code intervals, the historical problems and their priorities are pushed to the terminal that modifies the target code interval. This allows developers to avoid the occurrence of repeated problems in advance when modifying the target code interval, thereby ensuring the reliability of their calling operations.

[0061] The software system monitoring method provided in this embodiment first obtains the target code interval of the software system, and then based on the historical problems corresponding to each code interval in the pre-established data structure table and the mark prompt for indicating whether the code interval has a rewriting risk and / or whether each historical problem in the code interval is a test focus, pushes the historical problems corresponding to the target code interval, as well as the rewriting risk points and test focus of the target code interval, intelligently provides code transformation risks and test focus, and provides guidance for the development and testing of the software system. This not only greatly reduces the summary and analysis costs of technical personnel and reduces their workload, but also reduces the possibility of omissions and errors in manual analysis, effectively ensures the reliability and efficiency of the analysis results, and provides more convenience for the development and testing of the software system. Further, developers rewrite the code based on the rewriting risk points obtained by pushing, which can reduce the occurrence of repeated problems and improve the quality of code rewriting and the development efficiency of the software system; testers perform code testing based on the test focus obtained by the test, which can achieve accurate testing of the code, avoid the blindness of the test, and improve the efficiency of the test by accurately locating the test focus.

[0062] Figure 2 A flowchart of a monitoring method for a software system is provided for the second embodiment of the present application, such as Figure 2 As shown, based on the above embodiment, the software system monitoring method provided by the present application further includes the following method of establishing a data structure table before pushing the rewriting risk points and test focus of the target code interval based on the pre-established data structure table:

[0063] S201: Obtain historical issues corresponding to multiple code intervals of a software system.

[0064] In this step, the problems or defects that have occurred in each code interval of the software system should be summarized to obtain historical problems corresponding to multiple code intervals of the software system. It should be understood that the historical problems corresponding to a code interval should include various defects or problems that have occurred in the code interval in the past and have affected the normal operation of the software system.

[0065] S202: For each code interval, count the number of identical historical issues in the code interval. If the number of any historical issue is greater than a preset first value, mark the historical issue as a test focus.

[0066] The first value is determined according to the specific application of this solution. For example, it can be 2, 3, 4, 5, etc. This application does not limit the selection of the first value.

[0067] It should be understood that for each code interval, the corresponding historical problems may include multiple historical problems with the same problem, that is, a problem occurs repeatedly many times, which means that this problem needs to be paid special attention to during the testing phase. Therefore, the historical problems in the code interval can be marked as test focus to push the test focus of the code interval when the code interval is tested.

[0068] S203: Count the total number of historical issues in the code interval. If the total number is greater than a preset second value, mark the code interval as a rewrite risk.

[0069] The second value is determined according to the specific application of this solution. For example, it can be 3, 4, 5, 6, etc. This application does not limit the selection of the second value.

[0070] It should be understood that for each code section, if the total number of historical issues that have occurred in that code section is high, it indicates that this code section has a high modification risk. This means that when modifying this code section, the modification method and strategy should be carefully considered, and accordingly, at least one code modification prompt should be provided. Therefore, by marking the code section as a rewrite risk, the risk modification point for this code section can be promoted when the code section is modified.

[0071] S204: Obtain marking hints corresponding to the code interval according to the marked test focus and rewriting risk.

[0072] In this step, for each code interval, based on the test focus and rewriting risk marked in the code interval, a marking prompt corresponding to the code interval is obtained to indicate whether the code interval has rewriting risk and / or whether each historical problem in the code interval is a test focus.

[0073] S205: Construct a data structure table based on the historical issues and annotation prompts corresponding to each code interval.

[0074] In this step, based on the correspondence between each code interval and its corresponding historical issues and marking prompts, a data structure table is constructed, and the data structure table includes the historical issues and marking prompts corresponding to each code interval in the software system.

[0075] In a specific implementation, the software system monitoring method provided in this embodiment further includes:

[0076] Step 1: For each historical issue in each code interval, determine the type of the historical issue based on its source.

[0077] In this step, since historical issues from different sources have different degrees of impact on the software system, each historical issue in each code interval can be classified according to its source to determine the type of each historical issue. Then, for each code interval, the priority of the impact of each historical issue on the software system can be determined.

[0078] In the specific implementation of this solution, the sources of historical problems may include production events, monitoring alarms, industry warnings and customer feedback in the production operation dimension, as well as test defects, interface errors, optimization suggestions and configuration differences in the development and testing dimension.

[0079] Among them, in the production operation dimension, a production event refers to an event in which, after the software code has gone through a complete development and testing cycle and is put into production, hidden defects that were not discovered in the early stage are exposed during customer use, thereby affecting the normal use of the customer and causing economic losses. If any historical problem comes from a production event, the type of the historical problem is a production event type; a monitoring alarm refers to an automated alarm triggered when the software operation indicators detected by the monitoring system are abnormal (such as response delay, service unavailability, etc.), and the software system code is modified according to the alarm content. If any historical problem comes from a monitoring alarm, the type of the historical problem is a monitoring alarm type; an industry warning refers to an event that is triggered through public channels when the software operation indicators are abnormal (such as response delay, service unavailability, etc.). An event in which the corresponding repair measures are applied to one's own system after problems or defects exposed by other companies in the same industry or similar systems are obtained through channels such as industry reports and news. If any historical problem comes from a peer warning, the type of this historical problem is the peer warning type; customer feedback refers to an event in which the software system code is modified based on problems, complaints or suggestions raised by users during the use of products or services (for example, user feedback about slow loading of APP pages, failed order submissions, etc.) collected through customer service tickets, user reviews, social media and other channels. If any historical problem comes from customer feedback, the type of this historical problem is the customer feedback type.

[0080] In the development and testing dimension, a test defect refers to an event in which software system repairs are performed after discovering functional anomalies, performance issues, or compatibility issues in the software system during the testing phase (such as unit testing, integration testing, and chaos testing). If any of these historical issues stem from test defects, the type of this historical issue is a test defect. An interface error refers to an event in which software code is repaired after an error message is encountered during data exchange or function calls between different modules or between the software system and external software systems through interfaces. If any of these historical issues stem from interface errors, the type of this historical issue is an interface error. An optimization suggestion refers to an event in which system code is modified based on improvement suggestions made by technical personnel such as developers or testers regarding the performance, functionality, and maintainability of the software system. If any of these historical issues stem from optimization suggestions, the type of this historical issue is an optimization suggestion. A configuration difference refers to an event in which system code is modified based on configuration parameter settings issues in different environments (such as development, test, and production) or deployment scenarios. If any of these historical issues stem from configuration differences, the type of this historical issue is a configuration difference.

[0081] Step 2: For each code interval, determine the priority of each historical issue corresponding to the code interval based on a preset type hierarchy and the type of each historical issue corresponding to the code interval; wherein the type hierarchy includes the type of each historical issue and the corresponding priority of the degree of impact on the software system.

[0082] It should be understood that the type hierarchy should include the types of all historical issues corresponding to all code intervals of the software system, as well as the priority of the impact degree on the software system corresponding to each type.

[0083] For example, the type hierarchy for a certain software system is Production Event Type > Peer Alert Type > Monitoring Alert Type >= Test Defect Type. Accordingly, for a code section in the software system, if the code section includes three historical issues (Issue 1, Issue 2, and Issue 3), where Issue 1 is of the Peer Alert type, Issue 2 is of the Monitoring Alert type, and Issue 3 is of the Production Event type, then the priority of Issue 3 is > the priority of Issue 1 > the priority of Issue 2. This application does not impose specific restrictions on the specific types included in the type hierarchy or the priority of each type.

[0084] Step 3: Build a data structure table based on the historical issues corresponding to each code interval, the annotation prompts, and the priority of each historical issue.

[0085] In this step, the obtained data organization table is constructed, which includes not only the historical issues and annotation prompts corresponding to each code interval, but also the priority of each historical issue.

[0086] This implementation method first classifies the acquired historical issues according to their sources, and determines the priority of each historical issue corresponding to each code interval according to a preset type hierarchy, and then constructs a data structure table based on the priority of each historical issue. When the code interval is the target code interval, the information in the pushed rewriting risk points and test priorities can be further enriched based on the priority of each historical issue in the data structure table, or the historical issues can be more intuitively displayed in the terminal device in order of priority, so that technical personnel can further pay attention to the focus of code rewriting or testing.

[0087] A third embodiment of the present application provides a software system monitoring method. Based on the above embodiment, the data structure table further includes an association relationship between each code interval and at least one code interval with similar functionality to the code interval. Accordingly, after the target code interval is modified or tested, the software system monitoring method provided in this embodiment further includes:

[0088] Method 1: If a problem is detected in the modified or tested code in the target code interval, the problem is pushed to the terminal of the technician responsible for the at least one code interval.

[0089] Method 2: If a problem is detected in the modified or tested code in the target code interval, detect whether the at least one code interval has the same problem, and push the detection result to the terminal of the technician responsible for the at least one code interval.

[0090] It should be understood that code sections with similar functions generally have similar logic, algorithms, or use the same technical framework. Therefore, when a problem occurs in any code section, similar code sections with similar functions will usually also have similar hidden dangers.

[0091] Based on this, in this solution, by detecting the running status of the modified or tested code in the target code interval, when a problem is detected in the target code interval, at least one code interval associated with the target code interval is obtained from the data structure table, and the problem is pushed to the terminal of the technician responsible for the at least one code interval, so that the technician can perform a self-check to see whether the problem also exists in the at least one code interval; or, after obtaining at least one code interval associated with the target code interval from the data structure table, directly detect whether the at least one code interval has the same problem, and push the detection result to the terminal of the technician responsible for the at least one code interval, so as to comprehensively check whether the code intervals with similar functions to the code interval have the same problem, and timely eliminate the adverse effects caused by the problem.

[0092] In a specific implementation, a data structure table including the association relationship between each code interval and at least one code interval having a function similar to that of the code interval may be obtained in the following manner:

[0093] Step 1: For each code interval, based on the implemented function of the code interval, obtain at least one code interval with similar functions to the code interval.

[0094] Optionally, since technicians will follow the code writing specifications to perform standardized naming when compiling the code, for each code interval, they can first preliminarily screen out multiple code intervals that may have similar functions to the code interval according to the naming of the code in the code interval. Furthermore, by judging the implementation functions of these multiple code intervals that may have similar functions to the code interval, they can efficiently obtain at least one code interval with similar functions to the code interval.

[0095] Exemplarily, code intervals that implement similar functions are, for example, singlepay and batchpay, where singlepay is a code interval for processing a single payment transaction, and batchpay is a code interval for processing payment transactions in batches.

[0096] Step 2: Establish an association relationship between the code interval and at least one code interval in the data structure table.

[0097] In this step, for each code interval, an association relationship is established in the data structure table between the code interval and at least one code interval obtained that has similar functions to the code interval, so that the data structure table also includes an association relationship between each code interval and at least one code interval that has similar functions to the code interval.

[0098] The software system monitoring method provided in this embodiment establishes an association relationship between each code interval and at least one code interval with similar functions to the code interval in a data structure table in advance, so that when a problem is detected in the code being modified or tested in the target code interval, at least one code interval with similar functions to the target code interval can be obtained from the data structure table, thereby pushing the problem to the terminal of the technician responsible for the at least one code interval, or detecting whether the at least one code interval has the same problem, and pushing the detection result to the terminal of the technician responsible for the at least one code interval. This method can comprehensively detect whether the code intervals with similar functions to the code interval have the same problems, and thus promptly eliminate the adverse effects caused by the same problems in these functionally similar code intervals, thereby facilitating the maintenance of the software system code.

[0099] Figure 3This is a schematic diagram of the structure of the monitoring device of the software system provided in Example 4 of the present application, as shown in FIG. Figure 3 As shown, the monitoring device 30 of the software system provided in this embodiment includes:

[0100] An acquisition unit 301 is configured to acquire a target code interval of a software system, where the target code interval is a code interval being modified or a modified code interval to be tested;

[0101] The first push unit 302 is used to push the historical problems corresponding to the target code interval, as well as the rewriting risk points and test focus of the target code interval based on a pre-established data structure table; the data structure table includes historical problems and marking prompts corresponding to each code interval in the software system, and the marking prompt of each code interval is used to indicate whether there is a rewriting risk in the code interval and / or whether each historical problem in the code interval is a test focus.

[0102] The monitoring device 30 of the software system provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effects are similar and will not be described in detail in this embodiment.

[0103] Figure 4 A structural diagram of the monitoring device of the software system provided in Example 5 of the present application is shown as follows: Figure 4 As shown, based on the above embodiment, the monitoring device 30 of the software system provided in this embodiment further includes:

[0104] The second push unit 303 is used to push the problem to the terminal of the technician responsible for the at least one code interval if a problem is detected in the code modified or tested in the target code interval; or, if a problem is detected in the code modified or tested in the target code interval, detect whether the at least one code interval has the same problem, and push the detection result to the terminal of the technician responsible for the at least one code interval.

[0105] In a possible implementation, the monitoring device 30 of the software system further includes:

[0106] The third push unit 304 is used to obtain historical problems existing in the other code intervals in the data structure table if other code intervals are called when modifying the target code interval; if historical problems are found in the other code intervals, push the historical problems and their priorities to the terminal that modifies the target code interval.

[0107] In a possible implementation, the monitoring device 30 of the software system further includes:

[0108] Building unit 305, including:

[0109] A first acquisition module is used to acquire historical issues corresponding to multiple code intervals of the software system;

[0110] A first marking module is configured to count the number of identical historical issues in each code interval, and mark the historical issue as a test focus if the number of any historical issue is greater than a preset first value;

[0111] a second marking module, configured to count the total number of historical issues in the code interval, and mark the code interval as a rewrite risk if the total number is greater than a preset second value;

[0112] The second acquisition module acquires the marking prompt corresponding to the code interval according to the marked test focus and rewriting risk;

[0113] A construction module is used to construct the data structure table according to the historical issues corresponding to each code interval and the annotation prompts.

[0114] In a possible implementation, the construction unit 305 further includes:

[0115] A first determination module is configured to determine, for each historical problem in each code interval, a type of the historical problem according to a source of the historical problem;

[0116] The second determining unit determines, for each code interval, a priority of each historical issue corresponding to the code interval based on a preset type hierarchy and the type of each historical issue corresponding to the code interval; wherein the type hierarchy includes the type of each historical issue and the corresponding priority of the degree of impact on the software system;

[0117] Accordingly, the construction module is used to construct the data structure table according to the historical issues corresponding to each code interval, the annotation prompts, and the priority of each historical issue.

[0118] In a possible implementation, the monitoring device 30 of the software system further includes:

[0119] The establishing unit 306 is configured to obtain, for each code interval, at least one code interval with similar functions to the code interval based on the implemented functions of the code interval; and establish an association relationship between the code interval and the at least one code interval in the data structure table.

[0120] In a possible implementation, the first pushing unit 302 includes:

[0121] an analysis module configured to analyze and obtain rewriting risk points and test priorities of the target code interval using an analysis model based on historical issues and mark prompts corresponding to the target code interval in the data structure table, wherein the analysis model is configured to obtain the rewriting risk points and test priorities of the target code interval based on input information corresponding to the target code interval;

[0122] A push module is used to push historical issues corresponding to the target code interval, as well as rewriting risk points and test focuses of the target code interval to a target terminal; wherein the target terminal is a terminal device for modifying or testing the code in the software system.

[0123] In one possible implementation, the push unit is specifically used to: input the historical issues, marking prompts and the priority of each historical issue corresponding to the target code interval in the data structure table into the analysis model for analysis to obtain the rewriting risk points and test focus of the target code interval.

[0124] The monitoring device 30 of the software system provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effects are similar and will not be described in detail in this embodiment.

[0125] Figure 5 This is a schematic diagram of the structure of the computer equipment provided in this application. Figure 5 As shown, the computer device 40 provided in this embodiment includes: at least one processor 401 and a memory 402. Optionally, the computer device 40 further includes a communication component 403. The processor 401, the memory 402 and the communication component 403 are connected via a bus 404.

[0126] In a specific implementation process, at least one processor 401 executes the computer-executable instructions stored in the memory 402, so that the at least one processor 401 performs the above method.

[0127] The specific implementation process of the processor 401 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0128] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the present invention may be directly implemented by a hardware processor or implemented by a combination of hardware and software modules in the processor.

[0129] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage.

[0130] A bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be categorized as address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.

[0131] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0132] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0133] The readable storage medium may be implemented by any type of volatile or nonvolatile memory device, or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0134] An exemplary readable storage medium is coupled to a processor, such that the processor can read information from and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an ASIC. Of course, the processor and the readable storage medium can also exist as discrete components in a device.

[0135] The division of units is merely a logical functional division; actual implementations may employ alternative divisions, such as combining or integrating multiple units or components into another system, or omitting or disabling certain features. Furthermore, any direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units, either through an interface, electrical, mechanical, or other means.

[0136] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0137] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0138] If a function is implemented as a software functional unit and sold or used as a standalone product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product, stored in a storage medium, includes instructions for enabling a computer device (such as a personal computer, server, or network device) to perform all or part of the steps of the various embodiments of the method of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, removable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0139] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0140] Finally, it should be noted that those skilled in the art will readily identify other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art not disclosed herein. The present invention is not limited to the precise structure described above and illustrated in the accompanying drawings, and various modifications and variations may be made without departing from the scope thereof. The scope of the present invention is limited solely by the appended claims.

Claims

1. A software system monitoring method, characterized in that: include: Obtaining a target code interval of the software system, wherein the target code interval is a code interval being modified or a modified code interval to be tested; Based on a pre-established data structure table, historical issues corresponding to the target code interval, as well as rewriting risk points and test focus of the target code interval are pushed; the data structure table includes historical issues and marking prompts corresponding to each code interval in the software system, and the marking prompt of each code interval is used to indicate whether there is a rewriting risk in the code interval and / or whether each historical issue in the code interval is a test focus.

2. The method according to claim 1, characterized in that The method of pushing historical issues corresponding to the target code interval, as well as rewriting risk points and test focus points of the target code interval based on the pre-established data structure table, includes: Based on the historical issues and marking prompts corresponding to the target code interval in the data structure table, an analysis model is used to analyze and obtain rewriting risk points and test priorities of the target code interval. The analysis model is a model that analyzes rewriting risk points and test priorities based on code interval information obtained by pre-training a machine learning model; The historical issues corresponding to the target code interval, as well as the rewriting risk points and test focus of the target code interval are pushed to the target terminal; wherein the target terminal is a terminal device for modifying or testing the code in the software system.

3. The method according to claim 1 or 2, characterized in that The data structure table also includes an association relationship between each code interval and at least one code interval with similar functions to the code interval; After the target code interval is modified or tested, the method further includes: If a problem is detected in the modified or tested code in the target code interval, the problem is pushed to a terminal of a technician responsible for the at least one code interval; or, If a problem is detected in the modified or tested code in the target code interval, the at least one code interval is detected to see if the same problem exists, and the detection result is pushed to the terminal of the technician responsible for the at least one code interval.

4. The method according to claim 1 or 2, characterized in that The data structure table also includes a priority of the impact of each historical issue on the software system. The method further includes: If other code intervals are called when modifying the target code interval, obtaining historical issues existing in the other code intervals in the data structure table; If it is obtained that the other code interval has historical problems, the historical problems and the priorities of the historical problems are pushed to the terminal that modifies the target code interval.

5. The method according to claim 1 or 2, characterized in that Before pushing the rewriting risk points and test focus of the target code interval based on the pre-established data structure table, the method further includes: Obtaining historical issues corresponding to multiple code intervals of the software system; For each code interval, the number of the same historical problems in the code interval is counted. If the number of any historical problem is greater than a preset first value, the historical problem is marked as a test focus. Counting the total number of historical issues in the code interval, and if the total number is greater than a preset second value, marking the code interval as a rewrite risk; Obtaining marking tips corresponding to the code interval based on the marked test focus and rewriting risk; The data structure table is constructed according to the historical issues corresponding to each code interval and the annotation prompts.

6. The method according to claim 5, characterized in that The method further comprises: For each historical issue in each code interval, determine the type of the historical issue according to the source of the historical issue; For each code interval, determine the priority of each historical issue corresponding to the code interval based on a preset type hierarchy and the type of each historical issue corresponding to the code interval; wherein the type hierarchy includes the type of each historical issue and the corresponding priority of the degree of impact on the software system; Accordingly, the data structure table is constructed according to the historical issues corresponding to each code interval and the annotation prompts, including: The data structure table is constructed according to the historical issues corresponding to each code interval, the annotation prompts, and the priority of each historical issue.

7. The method according to claim 5, characterized in that The method further comprises: For each code interval, based on the implemented function of the code interval, obtaining at least one code interval having a function similar to that of the code interval; An association relationship between the code interval and the at least one code interval is established in the data structure table.

8. The method according to claim 2, characterized in that The data structure table also includes the priority of the impact of each historical problem on the software system; Accordingly, based on the historical issues and marking prompts corresponding to the target code interval in the data structure table, an analysis model is used to analyze and obtain the rewriting risk points and test focus of the target code interval, including: The historical issues, marking prompts and the priority of each historical issue corresponding to the target code interval in the data structure table are input into the analysis model for analysis to obtain the rewriting risk points and test focus of the target code interval.

9. A computer device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 8 when executed by a processor.

Images