A software product detection method, device, equipment and storage medium

Abstract

This invention proposes a software product testing method, apparatus, equipment, and storage medium. The method includes: parsing the program structure of the software product to be tested, extracting module dependencies, and calculating structural complexity parameters; determining the behavioral statistical caliber based on the structural complexity parameters; dividing the running event sequence into statistical windows according to the behavioral statistical caliber, calculating the correction behavior intensity, and generating running behavior feature values; obtaining reference feature sequences from historical stable running phases, calculating the stable behavior reference center value and fluctuation width; and calculating the deviation score using the running behavior feature values, reference center value, fluctuation width, and behavioral statistical caliber to generate the testing result. This invention effectively solves the problem of insufficient accuracy of fixed threshold detection in complex software scenarios by adaptively adjusting the statistical caliber based on structural complexity and combining dynamic behavioral features with historical benchmarks for deviation determination, thereby improving the stability and reliability of software running status monitoring.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a method, apparatus, equipment and storage medium for testing software products. Background Technology

[0002] Software products typically require quality inspection and consistency verification during delivery, deployment, and continuous iteration to identify functional defects, stability vulnerabilities, and potential operational anomalies before release. Common inspection methods in existing engineering practices can be broadly categorized into static analysis and dynamic inspection. Static analysis primarily relies on rule bases, syntax matching, dependency scanning, or pattern recognition to examine source code or binary files. While it can detect some known issues without running the software, it often lacks sufficient ability to identify abnormal behaviors that only surface during runtime, such as short-term fluctuations caused by module linkage, concentrated calls during initialization, sudden increases in behavior due to cache preheating, and behavior drift under complex dependency chains. Dynamic inspection, while capable of identifying some runtime issues by running the software and collecting call information, access records, or system events during execution, often heavily relies on the deployment environment, scheduling strategies, system load, and the software's structure. The same version of the software may exhibit significantly different behavioral intensities and fluctuation rhythms under different operating conditions, making it difficult for inspection methods based on fixed thresholds, fixed statistical windows, or fixed sampling methods to simultaneously achieve both accuracy and stability. Especially in software products with complex module dependencies and high coupling of functional components, normal operation itself may exhibit significant behavioral fluctuations. If the structural complexity of the software product is not incorporated into the statistical and judgment process of operational behavior during detection, normal linkages can easily be misjudged as abnormalities, or true anomalies can be masked by structural fluctuations. Therefore, existing technologies still lack a detection scheme that addresses the overall form of the software product, first generating a complexity representation based on the program structure, then determining the statistical criteria for behavior based on this, and further forming operational behavior judgment results adapted to the characteristics of the software product itself. Consequently, it is difficult to obtain stable, reliable, and consistent detection conclusions in complex software systems. Summary of the Invention

[0003] This invention discloses a software product testing method, apparatus, equipment, and storage medium to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, the first aspect of the present invention provides a software product testing method, the method comprising: Analyze the program structure of the software product to be tested, extract the module dependencies related to the main execution path, and calculate the structural complexity parameters. Based on the structural complexity parameters, the behavioral statistics caliber is determined through bounded rational form mapping and derivative correction terms. Based on the aforementioned behavior statistics criteria, the collected sequence of running events is divided into statistical windows, the intensity of corrected behavior in each statistical window is calculated, and the running behavior feature values ​​are generated by summarizing them. Obtain the reference characteristic sequence of historical stable operation phases, and calculate the reference center value and reference fluctuation width of stable behavior; Using the operational behavior feature value, the stable behavior reference center value, the stable behavior reference fluctuation width, and the behavior statistical caliber, the deviation score is calculated, and the detection result is generated based on the deviation score.

[0005] Furthermore, the process of parsing the program structure of the software product to be tested, extracting module dependencies related to the main execution path, and calculating structural complexity parameters includes: Traverse the source files or binary files of the software product to identify the number of active calls and the number of calls between modules; Filter valid dependencies starting from the startup entry point or main scheduling module, and eliminate dependencies corresponding to test code and build scripts; Calculate the dependency of each module, where the dependency is the sum of the number of active calls and the number of called modules divided by the maximum value of the corresponding sums across all modules; The structural complexity parameter is obtained by summing the dependencies of all modules and taking the average value.

[0006] Furthermore, the step of determining the behavioral statistical caliber based on the structural complexity parameter through bounded rational form mapping and derivative correction terms includes: Substituting the structural complexity parameter into the basic mapping formula yields the basic statistical coefficient, where the basic mapping formula is the ratio of the structural complexity parameter to the structural complexity parameter plus a constant. Calculate the derivative of the basic mapping formula with respect to the structural complexity parameter, and multiply the derivative by the structural complexity parameter and a preset correction coefficient to obtain the correction term; The basic statistical caliber coefficient is added to the correction term to obtain the behavioral statistical caliber.

[0007] Furthermore, based on the aforementioned behavioral statistical criteria, the collected sequence of operational events is divided into statistical windows, the intensity of corrected behavior for each statistical window is calculated, and the operational behavior feature values ​​are aggregated and generated, including: Select the corresponding window template according to the behavior statistics criteria, and divide the continuous sequence of running events into adjacent statistical windows; Count the number of events in the current statistics window and the number of events in the previous statistics window; Using the number of events, the number of events in the previous statistical window, and the behavior statistics caliber, the corrected behavior intensity of the current statistical window is obtained through normalized counting and differential stabilization coupling calculation. The average value of the correction behavior intensity for all statistical windows is used to obtain the characteristic value of the running behavior.

[0008] Furthermore, in the formula for calculating the intensity of the corrected behavior, the numerator contains the number of events in the current statistical window, and the denominator contains the statistical scope of the behavior. The formula for calculating the intensity of the corrected behavior also includes a penalty factor, the base of which is a constant, and the exponent is the product of the relative change in the number of events in adjacent statistical windows and the statistical caliber of the behavior.

[0009] Furthermore, the step of obtaining the reference feature sequence of historical stable operation phases and calculating the stable behavior reference center value and stable behavior reference fluctuation width includes: Read the set of historical operational behavior feature values ​​generated by the same software version during the stable operation phase from the reference feature library; Calculate the arithmetic mean of all historical operational behavior feature values ​​in the set of historical operational behavior feature values, and use it as the reference center value for stable behavior; Calculate the absolute deviation between each historical operating behavior feature value in the set of historical operating behavior feature values ​​and the stable behavior reference center value, and calculate the arithmetic mean of all the absolute deviations as the stable behavior reference fluctuation width.

[0010] Further, the step of calculating the deviation score using the operational behavior characteristic value, the stable behavior reference center value, the stable behavior reference fluctuation width, and the behavior statistical caliber includes: The absolute value of the difference between the operational behavior characteristic value and the stable behavior reference center value is used as the numerator; The product of the stable behavior reference fluctuation width, the behavior statistical caliber, and the stable behavior reference center value, plus the sum of the preset constant terms, is used as the denominator. Divide the numerator by the denominator to obtain the deviation fraction.

[0011] A second aspect of the present invention provides a software product testing apparatus, the apparatus comprising: The structure parsing module is used to parse the program structure of the software product to be tested, extract the module dependencies related to the main execution path, and calculate the structure complexity parameter based on the number of calls between modules. The caliber generation module is used to perform mapping and correction calculations based on the structural complexity parameters to determine the behavioral statistical caliber. The feature extraction module is used to divide the collected sequence of running events into statistical windows according to the behavior statistics criteria, calculate the corrected behavior intensity based on the number of events in the statistical window, and summarize and generate running behavior feature values. The benchmark calculation and output module is used to obtain the reference feature sequence of historical stable operation phases, calculate the stable behavior reference center value and the stable behavior reference fluctuation width; calculate the deviation score using the operation behavior feature value, the stable behavior reference center value, the stable behavior reference fluctuation width and the behavior statistical caliber, and generate the detection result based on the deviation score.

[0012] In a third aspect, an electronic device is provided, characterized in that it includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method described above.

[0013] In a fourth aspect of the invention, a computer-readable storage medium is provided having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the method described above.

[0014] The beneficial technical effects of the present invention are at least as follows: To address the aforementioned problems, this invention provides a software product testing method, apparatus, device, and storage medium. Its core lies in first analyzing the program structure of the software product, extracting module dependencies, and forming structural complexity parameters. Then, based on these structural complexity parameters, it generates behavioral statistical criteria matching the current software product, ensuring that subsequent event collection, windowing, summarization, and feature extraction no longer rely on fixed statistical methods but remain consistent with the software product's own structural form. On this basis, it performs window-based statistics and cross-window summarization on behavioral events generated during operation, generating operational behavioral feature values ​​that characterize the current testing cycle's operational rhythm. Furthermore, it combines these with reference feature sequences formed during historical stable operation phases to determine the deviation of the current operational behavior, ultimately outputting the software product testing results. Through this processing method, software structural complexity is no longer confined to static analysis but is transformed into actual control parameters in operational behavior testing, permeating the entire process of statistical criterion setting, feature value generation, and testing judgment. This allows the testing results to simultaneously reflect the software product's structural characteristics, operational behavioral characteristics, and stable operating benchmarks.

[0015] This solution transforms software product testing from the traditional fixed threshold and fixed window mode to a product-level testing mode that adapts to the characteristics of the software structure. This makes it more suitable for software product scenarios with strong module coupling and significant operational fluctuations, and can more effectively identify abnormal operating states, operational degradation, and unexpected behavioral changes. Attached Figure Description

[0016] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0017] Figure 1 This is a flowchart of a software product testing method according to the present invention.

[0018] Figure 2 This is a framework diagram of a software product testing device according to the present invention. Detailed Implementation

[0019] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0020] In one or more embodiments, such as Figure 1 As shown, a software product testing method is disclosed, the method comprising the following: S1: Analyze the program structure of the software product to be tested, extract the module dependencies related to the main execution path, and calculate the structural complexity parameters; Specifically, this step targets the software product to be tested. Extract the module dependencies within the program and compress these dependencies into a unified structural complexity parameter. The focus here is not on performing a general software architecture assessment, but rather on preparing an input quantity that can directly participate in setting statistical criteria for subsequent software product testing. The reason for doing this step first is that the same fluctuations in operational behavior often indicate anomalies in simple software, while in complex software it may simply be normal interaction. Therefore, it is essential to first determine "how complex the software itself is" so that subsequent testing steps have a basis. There are two actual forms. The first is the source code project, such as a complete project directory exported from a version control system; the second is the build artifacts, such as installation packages, executable files, dynamic library files, or program files in container images. In practice, it is not required that all software products provide source code. If source code is available, module dependencies are extracted through source code parsing; if source code is unavailable, module dependencies are extracted through binary analysis and runtime entry point scanning. In other words, although the input is uniformly denoted as... However, its data collection method is actually implementable and can be put into practice, rather than remaining an abstract description.

[0021] First, the software product Perform program structure reading. If... If it's a source code project, the structure parser traverses the project directory, reading package references, class definitions, function definitions, and function call statements from the source files. This can be achieved directly through a compilation frontend or syntax tree parsing component. For example, for a Java project, dependencies can be extracted from import statements, class statements, and method call statements; for a C / C++ project, dependencies can be extracted from header file references, function symbol calls, and linking relationships; for a Python project, dependencies can be extracted from import statements, object method calls, and module access paths. If the file is a binary file instead of source code, the symbol extraction component reads the import table, export table, function symbols, call jump instructions, and dynamic linking information. This information, combined with the program entry point scan results, reconstructs the call relationships between modules. Here, "module" is not strictly limited to a specific granularity; it can be uniformly selected as "class," "file," "service component," or "function cluster" depending on the software product's form, but the granularity must remain consistent within the same software product. For ease of subsequent testing, this solution prioritizes the "functional module" granularity, aggregating multiple strongly related functions into a single module. This avoids being too fine-grained as the function level and too coarse-grained as the entire subsystem level.

[0022] After obtaining the raw structural information, instead of directly treating all dependencies as valid dependencies, a dependency filtering process tailored to the detection scenario is performed first. This is because software products typically contain many static dependencies unrelated to the actual runtime state, such as test code dependencies, build script dependencies, debugging aid dependencies, pseudo-references in comments, and backup modules not called by the main program entry point. Including all these relationships would result in excessive complexity, which wouldn't reflect the actual source of runtime behavior fluctuations. Therefore, this step only retains valid dependencies related to the main program execution path. Specifically, starting from the software startup entry point, main scheduling module, or external service entry point, the chain is expanded downwards, retaining module dependencies reachable from the entry point; dependencies in the test directory, example directory, and build script directory are directly removed; and duplicate dependencies are retained only once. This processing yields a module dependency set tailored to the detection scenario, which is closer to subsequent runtime behavior statistics than ordinary architecture analysis.

[0023] Next, the dependencies are organized into computable module dependency records. For each module, two quantities are counted: one is how many other modules this module actively calls, denoted as _____. The other is how many other modules call this module, denoted as... The former reflects the control relationships that propagate outward from the module, while the latter reflects the degree of concentration to which the module is depended upon by other parts of the system. In software product testing scenarios, both types of relationships are important because if a module both extensively calls upon others and is called by numerous other modules, fluctuations in its subsequent operation often trigger broader behavioral changes. Therefore, this step incorporates both types of relationships into the statistical process of module dependency. Specifically, the first... Dependency of each module The normalized module dependency is obtained by summing the number of active calls and the number of called modules for that module, and then dividing by the maximum sum of the number of active calls and the number of called modules across all modules. This is done to obtain a unified structural complexity parameter. Then, summarize the dependencies of all modules. (Structural complexity parameters) Calculate according to the following formula: ; in, This represents the software structure complexity parameter and is the output of this step. This represents the total number of modules participating in the calculation after entry screening, which is obtained by the structure parsing program. Indicates the first The dependency of the module is calculated as follows: Number of active calls to each module With the number of calls The sum of these is then divided by the maximum sum of the corresponding sums across all modules; Indicates the first The number of times a module actively calls other modules is obtained by the structure parsing program traversing the module dependency records; Indicates the first The number of times a module is called by other modules is obtained by the structural parsing program using the inverted dependency index. Indicates the module number, used for sequential indexing from the first module to the next. Each module. Here... These are not abstractly defined symbols, but rather directly calculated from the parsing results. For example, if a payment processing module calls the order module, log module, and risk control module, and is also called by the settlement module and reconciliation module, then the dependency relationships of this module are more complex than those of a regular utility module called only by a single path. As another example, in a desktop application, if the UI / UX module calls the configuration module, rendering module, and caching module, while the configuration module itself rarely calls other modules, then the former's dependency will be significantly higher than the latter's. By performing this processing on all modules, the overall structural complexity of the entire software product can be obtained.

[0024] To prevent parameter distortion between software of different sizes simply due to differences in the number of modules, this step calculates each... Normalization is used at this time. The purpose of this is not to simplify complex problems, but to normalize the structural complexity parameters. It is more suitable as input for setting subsequent statistical standards. For example, two software products both contain a structure of "core scheduling module + multiple business modules", but one software has 20 modules and the other has 200 modules. If the original number of dependencies is used directly, the complexity of the latter will almost certainly be much higher than that of the former, and the subsequent statistical standards will be amplified by the scale factor. After normalization, the parameters can better reflect "whether there is a high degree of coupling between modules" rather than simply "how many modules there are".

[0025] In practice, this step does not require manual reading of the code step by step. A structure parsing program can be deployed on the software product testing equipment, which will automatically read the software product... Output a module dependency record file, and then calculate based on this record file. In continuous integration scenarios, this step is executed automatically after each build; in offline quality inspection scenarios, this step is executed when the version to be tested is loaded into the database. Regardless of the method, the output is uniformly a structural complexity parameter. Subsequent steps can be performed directly by reading the data; there's no need to go back and parse the structure again. The final result is... Based on the software product by the structure parsing program The effective module dependencies are calculated and saved as numerical parameters that can be directly read in subsequent steps. Except... In addition, this step will not output any other core variables, thus ensuring the simplicity and stability of subsequent processes. The actual operation of this step can be summarized as follows: start with the software product... Extract the module dependencies related to the main execution path, then normalize the dependency statistics for each module, and finally obtain a unified structural complexity parameter. This parameter is not a general architecture score, but rather a structural input specifically prepared for subsequent software product testing. Through this step, the subsequent statistical criteria are no longer fixed, but can be set according to the structural complexity of the software itself. This is precisely what distinguishes this solution from directly statistically analyzing runtime behavior before testing.

[0026] S2: Based on the structural complexity parameters, determine the behavioral statistics caliber through bounded rational form mapping and derivative correction terms; Specifically, the structural complexity parameters have already been obtained in the previous step. Based on this, this step further converts the parameter into a behavioral statistical caliber. , so that subsequent running behavior statistics no longer use a fixed window, but are adjusted according to the structural complexity of the software product itself. The core idea here comes from bounded monotonic mapping in mathematics: when the input quantity is a normalized positive value, it is suitable to use a bounded rational expression with the input itself in the denominator to compress it into a stable interval, so as to avoid infinite amplification of the output when the input is too large. The obtained in the previous step is essentially a structural strength characterization formed after normalizing module dependency statistics. The larger the value, the closer the coupling between modules, and the more likely multi-module linkage occurs during the running stage. If is directly linearly mapped to the statistical window, the statistical window of complex systems will grow too fast, resulting in excessive smoothing of real anomalies; if the structural complexity is not introduced at all, the detection will regard the normal linkage of complex systems as anomalies. Therefore, this step uses the method of "compression first, then compensation" to generate : First, use a bounded rational expression to establish a basic mapping from structural complexity to statistical caliber, and then add a derivative-based correction term to the medium complexity interval, so that the statistical caliber has more detailed resolution ability in the low complexity and medium complexity intervals, and remains stable in the high complexity interval.

[0027] The basic mapping comes from the common processing form of bounded normalization of positive variables in mathematics, and its original form can be written as the ratio of the input quantity to "the input quantity plus a constant". Substituting the structural complexity parameter obtained in the previous step directly, the basic caliber coefficient can be obtained: ; Among them, represents the basic statistical caliber coefficient directly obtained from the structural complexity parameter; represents the structural complexity parameter calculated according to the module dependency relationship of the software product in the previous step. Since has been normalized in the previous step, is also a dimensionless proportional coefficient, and the calculation relationship between the two is continuous and monotonic. The meaning of this formula can be directly understood in combination with the software product detection scenario: when the structure of the software product is relatively simple, is smaller, is also smaller, corresponding to a subsequent shorter statistical window, which can expose abnormal behaviors faster; when the structure of the software product gradually becomes complex, As the value increases, the subsequent statistical window will widen accordingly, thus covering a longer normal linkage cycle. The advantage of this formula is that the values ​​always remain within a stable range, facilitating the selection of statistical templates using unified rules. After the basic mapping is formed, a practical application issue needs to be considered: software product testing is more concerned with the discrimination stability of "medium-complexity systems." This is because module linkage in such systems is already evident, but it hasn't reached the level of naturally long-cycle fluctuations seen in large-scale distributed systems. If only relying on… The statistical scope changes more slowly during this period, making it difficult to distinguish between some coordinated behaviors and abnormal behaviors in statistics.

[0028] Therefore, this step further introduces a correction term derived from the derivative of the fundamental mapping. The derivative reflects the sensitivity of the fundamental mapping to changes in structural complexity, and the medium complexity range is precisely the range where sensitivity needs to be maintained. Taking the derivative of the above equation yields... right rate of change Then compare the rate of change with the current complexity level. Multiply by a fixed correction factor. This results in a compensation term that enhances performance in low and medium complexity ranges and naturally decays in high complexity ranges. Superimposing this compensation term onto the base mapping yields the final behavioral statistics: ; in, This indicates the statistical criteria used for subsequent operational behavior statistics. This still represents the structural complexity parameter output in the previous step. The first term in the formula is the basic mapping term, used to ensure that the scope increases monotonically with complexity; the second term is the correction term, which is the compensation amount obtained by multiplying the rate of change of the basic mapping with respect to complexity by the current complexity level, used to improve the statistical resolution of medium-complexity software products. Because... The parameters are dimensionless after normalization; both terms are dimensionless and can be directly added. This modified design is suitable for software product testing scenarios because software systems need to maintain high anomaly sensitivity in low complexity ranges, prevent short-term linkages from being directly treated as anomalies in medium complexity ranges, and avoid further significantly widening the statistical window in high complexity ranges, otherwise it may mask the real problem. This formula possesses precisely such numerical characteristics: when When I was very young, the second item followed It works by increasing complexity, and can differentiate between software of varying complexity much faster than basic mapping; when When it is very large, the second term will naturally weaken, making The growth gradually stabilizes, thus avoiding an indefinite expansion of the statistical window.

[0029] In practice, the statistical caliber generation program in the testing equipment reads the data stored in the previous step. Calculated according to the above formula Then based on Select the corresponding statistical template. These templates are pre-configured during system deployment, and each template includes at least two configuration parts: the statistical window length and the aggregation method within the window. For ease of implementation, you can map the scope according to continuous intervals, for example, by... When it falls within a lower interval, it is mapped to a short window template. When it falls within the middle range, it is mapped to the middle window template. When the value falls within a higher range, it is mapped to a long window template. The statistical caliber generation program does not need to read the source code again or rebuild dependencies; instead, it directly calls the output from the previous step. The completion of the calculation establishes a strict input-output connection between the steps. Further considering the practicalities of software product testing, this step goes beyond simply "providing a parameter." It compresses structural complexity into operational statistical rules, ensuring that subsequent steps, when collecting data on software behavior, pre-consider the structural and interconnected characteristics of the software system in their statistical scope. The resulting behavioral statistics are not fixed sampling parameters found in general monitoring systems, but rather detection-specific parameters driven by the internal structure of the software product.

[0030] To illustrate the feasibility of this calculation method, a specific calculation process can be provided. Let the structural complexity parameter calculated for a certain software product in the previous step be... Then the basic mapping term is The correction item is The two are added together to obtain the final statistical caliber. Once the caliber generation program reads this value, it can select a caliber from the template library. The corresponding middle window statistics template is then used by the next step's runtime behavior statistics module. For example, if the structural complexity parameter of another software product is... Then the basic mapping term can be obtained as The correction item is Finally obtained This corresponds to the short window statistical template. The difference between the two sets of results indicates that this calculation method can directly transform differences in software structure into differences in behavioral statistics, thus enabling subsequent detection to have statistical strategies that are more in line with actual operating characteristics when facing software products of different complexities.

[0031] The final result This will serve as the sole input for the next step, determining the window range and aggregation scope for runtime behavior statistics. Because... Completely derived from the output of the previous step Calculations show that a direct parameter transfer relationship exists between this step and the previous step; and because... The next step directly controls the generation method of operational behavior feature values, and this step also establishes clear statistical boundaries for subsequent detection. In this way, the structural complexity of the software product is no longer limited to the structural analysis level, but is transformed into actual control parameters in operational detection, thereby ensuring that the entire solution remains continuous and feasible in the "structural complexity - statistical caliber - behavioral features - detection results" chain.

[0032] S3: Based on the aforementioned behavior statistics criteria, the collected sequence of running events is divided into statistical windows, the intensity of corrected behavior in each statistical window is calculated, and the running behavior feature values ​​are generated by summarizing them. Specifically, in the previous step, we obtained the behavioral statistics criteria. This step then revolves around the same software product to be tested. Generate runtime behavior characteristic values The object of processing here is no longer the static structure of the software, but rather the sequence of behavioral events continuously generated during software runtime. The first two steps have already completed the process from module dependencies to structural complexity parameters. From behavioral statistics to Therefore, this step will not re-discuss the structure analysis, but will directly convert the transformation. As a control variable for operational behavior statistics, it determines the scale at which behavioral events should be observed, smoothed, and summarized. The resulting operational behavior feature value is not a simple count value detached from preceding steps, but a detection-specific feature value that has absorbed the influence of software structural complexity. This is crucial for software product testing scenarios because phenomena such as batch initialization, cache preheating, centralized logging, and concurrent triggering of scheduled tasks frequently occur during software operation. Simply summing the raw events generated by these phenomena would lead to over-reliance on instantaneous peak values ​​in the detection results; conversely, a large-scale averaging would weaken the visibility of abnormal behavior. This step uses a method of "windowing by scope, window-by-window correction, and cross-window summarization" to generate the feature value. This allows the eigenvalues ​​to retain the true fluctuations during operation while also tolerating normal linkages in structurally complex systems.

[0033] In practice, the testing equipment launches the software product. The runtime monitoring component collects runtime events. This component can read runtime events through instrumentation interfaces, function tracing interfaces, module access log interfaces, or system event collection interfaces. For instrumentable software products, sampling points can be written at function entry points, module call entry points, and resource request locations; for binary software where instrumentation is inconvenient, module access events can be extracted using system call tracing and process event sampling mechanisms. Each event record contains at least the event sequence and module identifier, and the runtime monitoring component writes these records to a sequence buffer. Subsequently, the window control component uses the behavior statistics obtained in the previous step. Select the corresponding window template to divide the continuous event sequence into several adjacent statistical windows. The window template has already been preset in the detection device, and the template content includes the window coverage length and the connection method between adjacent windows. The larger the value, the more complex the software product structure, and the larger the corresponding window coverage area. The smaller the value, the simpler the software product structure, and the smaller the corresponding window coverage area. In this way, the output from the previous step... The structural characteristics of the software product are then fully transmitted to the runtime behavior statistics stage, thus entering the process of generating behavioral feature values.

[0034] After dividing the statistical windows, first count the number of events within each window. Let the number of events in the window be... The number of events in each statistics window is The number of events in the adjacent previous window is Use only This is insufficient as a detection feature because it only reflects the local activity intensity of the current window and cannot distinguish between "stable activity" and "sudden activity." Therefore, this step constructs window-level behavior intensity based on two classic approaches: the first approach comes from normalized counting in statistics, which converts the original number of events into a caliber coefficient. The first approach is to adjust to a uniform scale; the second approach comes from first-order difference stabilization in time series analysis, using the relative changes of adjacent windows to suppress short-term bursts. Let's first look at normalized counts. If we directly use the number of window events as the behavior intensity, then when... When dealing with longer windows, the number of events naturally increases, making results from different perspectives incomparable. Therefore, the number of window events is written as... In the denominator here The statistical caliber obtained in the previous step serves to compress the number of window events corresponding to different calibers to a uniform comparison scale. Next, consider difference stabilization. In time series analysis, the relative changes of adjacent samples are often used to describe the degree of suddenness; therefore, the first... The changes between this window and the previous window are written as follows: In this notation, the numerator represents the absolute change between adjacent windows, and the denominator represents the total activity of the current window and the previous window. A constant term is added to the denominator to maintain computational stability. Since the current step aims to suppress sudden changes more sensitively in structurally complex systems, it multiplies by the value obtained in the previous step. This means that the larger the statistical scope, the stronger the suppression of drastic outbreaks. To ensure that the intensity of window-level behavior remains positive and gradually decays as the difference term increases, a classic penalty factor is used. In the form of, This is a relative change term. Combining these two parts, we get the first... The strength of the correction behavior for each window: ; in, Indicates the first The strength of the corrective behavior for each statistical window is calculated by the operation monitoring component after completing the window event count; Indicates the first The number of running events in each statistics window is obtained by the running monitoring component counting the function call events, module access events, and system events collected in the current window; Indicates the first The number of running events in each statistics window is obtained by counting the events in the previous window using the same component; This represents the statistical caliber of the behavior output from the previous step, used to control the window size and adjust the suppression strength against sudden changes. The derivation of this formula is clear: first, the window activity intensity is obtained from normalized counts; then, a penalty factor is constructed from the relative differences between adjacent windows; finally, a corrected behavioral intensity is formed through multiplicative coupling, reflecting both the activity level and stability level of the current window. Because... and Both are event counts. It is a dimensionless statistical coefficient. All terms in the fraction have been normalized, so the left and right sides of the whole formula are consistent.

[0035] Get each window Next, the window-level behavioral intensities need to be combined into a single overall feature value that can be used for the next detection step. Here, the mathematical concept of sample mean is used to average the correction behavioral intensities of all windows. This approach is chosen because the behavioral feature value needs to reflect the overall rhythm across the entire detection interval, rather than the occasional fluctuations of a single window. Averaging the window-level results allows for the preservation of the aforementioned correction effect while further suppressing occasional fluctuations in individual windows. The final behavioral feature value calculation formula is: ; in, This indicates that the final output of the running behavior feature value in this step is obtained by summing the correction behavior intensity of all windows within the current detection interval; This indicates the total number of statistical windows formed within the current detection interval, determined by the window control component based on behavioral statistical criteria. The statistics were obtained after dividing the window; Indicates the first The strength of the correction behavior for each statistical window is calculated using the formula above; Indicates the window number, used to track windows from the first window to the second. The windows are indexed sequentially. The relationship between the two formulas is local first, then global: the first formula constructs local features at the window level through "caliber normalization + differential stabilization," while the second formula performs overall summarization at the detection interval level, thus obtaining a single operational behavior feature value. This means It is not a simple scaling result of the number of events, but an expression of the running behavior that has absorbed the statistical information from the previous step and has undergone cross-window stabilization processing.

[0036] To make this calculation process directly implementable, a complete example can be provided. Suppose that the behavioral statistics obtained from the previous step for a certain software product are... The window control component selects the appropriate window template accordingly, forming three consecutive windows within a detection interval. The monitoring component then counts the number of events in each of the three windows. , , If the first window has no preceding window, the initialization window is recorded as being the same as the first window, i.e., it is taken as... Therefore, the strength of the correction behavior in the first window is The correction intensity for the second window is... Substituting the values, we get approximately The correction intensity for the third window is... Substituting the values, we get approximately Substituting these three window intensities into the second formula yields the characteristic values ​​of the running behavior. The result is approximately This example directly demonstrates that the second window with the most window events does not mechanically obtain the maximum proportion of output, but is smoothed out under the constraint of the difference between adjacent windows; simultaneously, the overall eigenvalues... It also preserves the overall operational strength of the entire testing range, making it suitable as input for the next step of software product testing and judgment.

[0037] In the entire scheme, this step is responsible for converting the "structural complexity parameters" obtained in the first two steps. -Behavioral statistics caliber "This truly translates into operational behavior data and generates operational behavior feature values ​​that can be directly used in the next step." The output of the previous step This step utilizes the entire process, not only in window template selection but also directly in window-level correction formulas; running behavior characteristic values. This value is explicitly calculated in this step and will serve as input for the next step of software product testing. The resulting chain is not a loose patchwork; rather, the statistical criteria from the previous step drive the feature construction in this step, and the feature values ​​generated in this step drive the next detection and judgment. The final result... Generated sequentially by the operation monitoring component, window control component, and feature calculation component, it can stably represent the software operation rhythm in software product testing scenarios and provide a unified input for subsequent anomaly judgment.

[0038] S4: Obtain the reference feature sequence of historical stable operation phases, calculate the stable behavior reference center value and the stable behavior reference fluctuation width; use the operation behavior feature value, the stable behavior reference center value, the stable behavior reference fluctuation width and the behavior statistical caliber to calculate the deviation score, and generate the detection result based on the deviation score; Specifically, in the previous step, runtime behavior characteristic values ​​are generated. Next, this step involves the software product. Determine the current operating status and output the detection results. The decision object here is not the original event stream, but rather the stream that has already undergone the "structural complexity parameter". -Behavioral statistics caliber - Operational behavior characteristics "This is the feature record after processing in this link. Due to..." The generation process has been affected Due to the constraints, this step does not use a fixed threshold independent of the software structure for judgment, but continues to use the same statistical caliber. The current feature value is interpreted. In specific implementation, the judgment module in the detection equipment reads the operational behavior feature value generated in the current detection cycle. And read the behavioral statistics corresponding to the detection period from the statistical records generated in step two. Subsequently, the determination module reads stable operating reference sequences from the reference feature library under the same software version, same deployment configuration, and same startup method. ,in Indicates the first The operational behavior characteristic values ​​corresponding to each stable detection cycle from Increment to , This represents the total number of stable detection cycles in the reference feature library that participated in the benchmark calculation. Each of the reference feature libraries... All from software products During periods of stable historical operation, statistical methods consistent with the current monitoring cycle will be used. The feature values ​​are obtained using the same feature generation method as the current feature values. With reference sequence If the statistical standards and calculation methods are kept consistent, the same judgment process can be directly entered.

[0039] This step first establishes a stable behavior benchmark for the current software product based on a reference feature library. The initial sources used here are the sample mean and mean absolute deviation (MAD) from statistics. The sample mean represents the central feature under stable operating conditions, and the MAD represents the natural fluctuation range around the central feature under stable operating conditions. Considering that the software product detection scenario focuses on "whether the current behavior deviates from the stable range," a reference central value is first calculated using the feature sequence from the stable operating phase, and then the average deviation width around this central value is calculated. The calculation method can be written as a simultaneous expression as follows: ; in, The reference center value representing stable behavior is derived from the reference feature library. Stable detection cycle characteristic value Calculated from the sample mean; The reference fluctuation width for stable behavior is represented by the characteristic value of each stable detection period relative to the reference center value. The absolute deviation is averaged to obtain the result; Indicates the first The operational behavior characteristic value of a stable detection cycle, which is generated by the preceding link that is completely consistent with the current step; This represents the number of stable detection cycles in the reference feature library participating in this calculation. The first part of this formula comes directly from the mean estimation formula, and the second part comes directly from the mean absolute deviation formula. The reason for combining them is that the reference benchmark in software product testing scenarios needs to describe not only the "typical operating level" but also the "natural fluctuations allowed by stable operation itself." Because... , and They are all composed of normalized eigenvalues, so they are on the same numerical scale and can be directly used in subsequent calculations.

[0040] After obtaining the reference center value and reference fluctuation width Next, this step constructs the deviation score for the current detection period. Its initial source is the concept of standardized deviation in statistics, which divides the difference between the current observation and the reference center value by the allowable fluctuation width to obtain the comparable degree of deviation between different samples. In the software product detection scenario, behavioral statistics are used... The impact of software structural complexity on runtime behavior has already been demonstrated; therefore, based on the standardized deviation, we can further... Compared with the reference center value After multiplication, the terms are added to the denominator to form a structurally adaptive buffer term. This allows for a wider range of natural fluctuations during judgment for software products with more complex structures and higher stability centers; conversely, simpler software products maintain higher sensitivity in judgment. This yields the deviation score for the current detection period: ; in, It represents the deviation score of the current detection period, used to characterize the degree of deviation of the current operating behavior feature value from the stable behavior benchmark; This represents the operational behavior characteristic value of the current detection cycle, determined by the behavior statistics criteria from the previous step. This was obtained through statistics on the sequence of running events; The reference center value for stable behavior is calculated using the formula above; The reference fluctuation width for stable behavior is also calculated using the previous formula; This represents the statistical caliber of behavior, obtained from step two based on the structural complexity parameter mapping, and participates in the generation of runtime behavioral feature values ​​in step three. The derivation of this formula is clear: first, the central value is obtained from historical stable data. and fluctuation width Then, using the current eigenvalue relative center value The absolute deviation is used as the numerator, and the "natural fluctuation width" is used as the numerator. +Structural buffer item The "+stability term constant" forms the denominator, creating a structural adaptive standardized bias suitable for software product testing scenarios. Here, we add... The reason is that the larger the behavioral statistics caliber, the more complex the software structure, and the more likely the interaction of multiple modules will create larger, but still normal, behavioral fluctuations. Therefore, the structural buffer term in the denominator will increase accordingly, making the detection results more consistent with the actual operating rules of complex software products. , , and Since all quantities are normalized dimensionless quantities, the numerator and denominator should remain consistent, and the calculation result will be the same. It is also a dimensionless deviation fraction, which can be directly used for grading.

[0041] In actual deployment, the determination module determines the outcome each time it receives a result. Then, the test results are generated according to the preset grading rules. The grading rules can be determined through debugging records and historical stable operation data, for example, by... Determined to be normal, will It was determined to be a warning, and The result is determined to be abnormal. When generating the result, the determination module will include the status label and the current feature value. Deviation score The corresponding software version identifier is written into the test result record to form the final test result. To illustrate the feasibility of this process, a complete computational example can be provided. Assume the reference feature library contains feature values ​​for four stable detection periods, which are... , , , Then, the reference center value is first obtained from the first set of formulas. Then calculate the reference fluctuation width. If the current detection cycle has the same operational behavior feature value as the one obtained in the previous step... And the behavioral statistics corresponding to this feature value are Substituting this into the second formula, we get... Because this result is below the above-mentioned normal threshold. Therefore, the results of this test... It was determined to be in a normal state. If the feature value obtained in another detection cycle rises to... In the same , and The following can be obtained The result falls within the abnormal range, therefore the determination module generates an abnormal state detection result. This substitution process directly reveals that the detection result is not determined by a single fixed threshold, but rather by the current behavioral characteristics, historical stable benchmarks, and structural adaptive buffers.

[0042] After this step is completed, the output detection results will be... This corresponds to software products. The operating status within the current detection cycle. Because... The generation is directly based on the output of the preceding steps. and those bound to it In addition, a reference feature sequence formed during the stable operation phase of the same version was also introduced. Therefore, the entire detection chain forms a complete closed loop from structural analysis, statistical definition generation, behavioral feature extraction to final detection and judgment. The detection results obtained in this way can simultaneously reflect the structural characteristics, operational behavior characteristics, and stable operation benchmarks of the software product, and can be directly used for scenarios such as pre-deployment quality inspection, gray-scale release monitoring, and version regression verification.

[0043] In one or more embodiments, such as Figure 2 As shown, a software product testing device is disclosed, the device comprising: The structure parsing module is used to parse the program structure of the software product to be tested, extract the module dependencies related to the main execution path, and calculate the structure complexity parameter based on the number of calls between modules. The caliber generation module is used to perform mapping and correction calculations based on the structural complexity parameters to determine the behavioral statistical caliber. The feature extraction module is used to divide the collected sequence of running events into statistical windows according to the behavior statistics criteria, calculate the corrected behavior intensity based on the number of events in the statistical window, and summarize and generate running behavior feature values. The benchmark calculation and output module is used to obtain the reference feature sequence of historical stable operation phases, calculate the stable behavior reference center value and the stable behavior reference fluctuation width; calculate the deviation score using the operation behavior feature value, the stable behavior reference center value, the stable behavior reference fluctuation width and the behavior statistical caliber, and generate the detection result based on the deviation score.

[0044] It is worth noting that the specific workflow of the software product testing device provided in this embodiment of the invention is the same as that of the software product testing method described in the above embodiment, and will not be repeated here.

[0045] This invention also provides a software product testing device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the steps described in the above-described software product testing method embodiment, for example... Figure 1 The steps S1 to S4 described above; or, when the processor executes the computer program, it implements the functions of each module in the above-described device embodiments.

[0046] For example, the computer program may be divided into one or more modules, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the software product testing device.

[0047] The software product testing equipment can be a desktop computer, laptop, handheld computer, or cloud server, etc. The software product testing equipment may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the software product testing equipment may also include input / output devices, network access devices, buses, etc.

[0048] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the software product testing equipment, connecting all parts of the equipment via various interfaces and lines.

[0049] The memory can be used to store the computer program and / or modules. The processor implements various functions of the software product testing device by running or executing the computer program and / or modules stored in the memory and calling the data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc.; the data storage area may store data created according to the operation of the controller, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital card (SD card), flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0050] If the modules integrated in the software product testing equipment are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0051] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0052] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for testing software products, characterized in that, The method includes: Analyze the program structure of the software product to be tested, extract the module dependencies related to the main execution path, and calculate the structural complexity parameters. Based on the structural complexity parameters, the behavioral statistics caliber is determined through bounded rational form mapping and derivative correction terms. Based on the aforementioned behavior statistics criteria, the collected sequence of running events is divided into statistical windows, the intensity of corrected behavior in each statistical window is calculated, and the running behavior feature values ​​are generated by summarizing them. Obtain the reference characteristic sequence of historical stable operation phases, and calculate the reference center value and reference fluctuation width of stable behavior; Using the operational behavior feature value, the stable behavior reference center value, the stable behavior reference fluctuation width, and the behavior statistical caliber, the deviation score is calculated, and the detection result is generated based on the deviation score.

2. The software product testing method according to claim 1, characterized in that, The process involves analyzing the program structure of the software product under test, extracting module dependencies related to the main execution path, and calculating structural complexity parameters, including: Traverse the source files or binary files of the software product to identify the number of active calls and the number of calls between modules; Filter valid dependencies starting from the startup entry point or main scheduling module, and eliminate dependencies corresponding to test code and build scripts; Calculate the dependency of each module, where the dependency is the sum of the number of active calls and the number of called modules divided by the maximum value of the corresponding sums across all modules; The structural complexity parameter is obtained by summing the dependencies of all modules and taking the average value.

3. The software product testing method according to claim 1, characterized in that, The step of determining the behavioral statistical caliber based on the structural complexity parameter through bounded rational form mapping and derivative correction terms includes: Substituting the structural complexity parameter into the basic mapping formula yields the basic statistical coefficient, where the basic mapping formula is the ratio of the structural complexity parameter to the structural complexity parameter plus a constant. Calculate the derivative of the basic mapping formula with respect to the structural complexity parameter, and multiply the derivative by the structural complexity parameter and a preset correction coefficient to obtain the correction term; The basic statistical caliber coefficient is added to the correction term to obtain the behavioral statistical caliber.

4. The software product testing method according to claim 1, characterized in that, Based on the aforementioned behavioral statistical criteria, the collected sequence of operational events is divided into statistical windows, the intensity of corrected behavior for each statistical window is calculated, and the resulting summaries generate operational behavior feature values, including: Select the corresponding window template according to the behavior statistics criteria, and divide the continuous sequence of running events into adjacent statistical windows; Count the number of events in the current statistics window and the number of events in the previous statistics window; Using the number of events, the number of events in the previous statistical window, and the behavior statistics caliber, the corrected behavior intensity of the current statistical window is obtained through normalized counting and differential stabilization coupling calculation. The average value of the correction behavior intensity for all statistical windows is used to obtain the characteristic value of the running behavior.

5. The software product testing method according to claim 4, characterized in that, In the formula for calculating the intensity of the corrected behavior, the numerator contains the number of events in the current statistical window, and the denominator contains the statistical scope of the behavior. The formula for calculating the intensity of the corrected behavior also includes a penalty factor, the base of which is a constant, and the exponent is the product of the relative change in the number of events in adjacent statistical windows and the statistical caliber of the behavior.

6. The software product testing method according to claim 1, characterized in that, The process of obtaining the reference feature sequence of historical stable operation phases and calculating the reference center value and reference fluctuation width of stable behavior includes: Read the set of historical operational behavior feature values ​​generated by the same software version during the stable operation phase from the reference feature library; Calculate the arithmetic mean of all historical operational behavior feature values ​​in the set of historical operational behavior feature values, and use it as the reference center value for stable behavior; Calculate the absolute deviation between each historical operating behavior feature value in the set of historical operating behavior feature values ​​and the stable behavior reference center value, and calculate the arithmetic mean of all the absolute deviations as the stable behavior reference fluctuation width.

7. The software product testing method according to claim 1, characterized in that, The step of calculating the deviation score using the operational behavior characteristic value, the stable behavior reference center value, the stable behavior reference fluctuation width, and the behavior statistical caliber includes: The absolute value of the difference between the operational behavior characteristic value and the stable behavior reference center value is used as the numerator; The product of the stable behavior reference fluctuation width, the behavior statistical caliber, and the stable behavior reference center value, plus the sum of the preset constant terms, is used as the denominator. Divide the numerator by the denominator to obtain the deviation fraction.

8. A software product testing device, characterized in that, The device includes: The structure parsing module is used to parse the program structure of the software product to be tested, extract the module dependencies related to the main execution path, and calculate the structure complexity parameter based on the number of calls between modules. The caliber generation module is used to perform mapping and correction calculations based on the structural complexity parameters to determine the behavioral statistical caliber. The feature extraction module is used to divide the collected sequence of running events into statistical windows according to the behavior statistics criteria, calculate the corrected behavior intensity based on the number of events in the statistical window, and summarize and generate running behavior feature values. The benchmark calculation and output module is used to obtain the reference feature sequence of historical stable operation phases, calculate the stable behavior reference center value and the stable behavior reference fluctuation width; calculate the deviation score using the operation behavior feature value, the stable behavior reference center value, the stable behavior reference fluctuation width and the behavior statistical caliber, and generate the detection result based on the deviation score.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.

Images