Section module detection method and device, medium and equipment

Abstract

The embodiment of the invention discloses a section module detection method, which comprises the following steps of: for a section module compiled by a code to be detected, determining an application environment required by deployment based on a configuration file, configuring the section module into a container corresponding to the application environment, injecting the section module into a part of application programs, and taking the rest of the application programs as a reference; and automatically testing the operation parameters of whether the section module is injected or not through the test case, and determining the detection result of the section module by comparing the difference of the operation parameters. By automatically constructing a container test environment and a standardized detection process, efficient and accurate detection of the section module is realized, and the detection result is more practical while the labor cost is reduced.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method, apparatus, storage medium and device for detecting cross-section modules. Background Technology

[0002] Currently, Aspect-Oriented Programming (AOP) is widely used as a programming paradigm for software modularization and code logic decoupling. With the increasing complexity of business requirements and the widespread adoption of distributed architectures, higher demands are being placed on the flexibility and manageability of aspect injection.

[0003] Because aspect modules coexist with the runtime of business processes, they inevitably have a direct impact on the stability and performance of business applications. Therefore, it is necessary to test aspect modules to avoid vulnerabilities introduced by them that could lead to errors in business execution. Furthermore, with the continuous updates to aspect modules and the increasing number of business applications, the testing burden on aspect modules is also growing rapidly.

[0004] In existing technologies, aspect-based modules still primarily rely on manual testing. Testers need to perform functional verification and performance benchmarking on each module version and its aspect points. It is evident that current aspect-based module testing is extremely complex, time-consuming, and highly dependent on human labor. Furthermore, due to the lack of standardized testing procedures, not only is testing efficiency low, but the comparability of different testing processes is also poor, making it difficult to meet the practical needs of high-frequency iterations.

[0005] This significantly increases the risk of defective aspect modules being deployed into business applications, potentially leading to performance degradation or even failures. This contradicts the original intention of aspect injection technology to enhance application security and also results in high manpower investment and maintenance costs.

[0006] Based on this, this specification provides a method for detecting cross-section modules to partially solve the problems existing in the prior art. Summary of the Invention

[0007] This specification provides a method, apparatus, storage medium, and electronic device for detecting cross-section modules, in order to partially solve the problems existing in the prior art.

[0008] The embodiments in this specification adopt the following technical solutions: This specification provides a method for detecting a cross-section module, the method comprising: Receive the aspect file to be detected, and compile the code in the aspect file to obtain the aspect module; Based on the configuration file in the aspect file, determine the application environment that matches the aspect module, and deploy the application environment in the preset application container; The aspect module is deployed to the application container, at least one application for testing is selected and injected with the aspect module as a test application; and applications that have not been injected with the aspect module are identified as benchmark applications. Determine the test cases for the aspect module, and determine the first running parameters of the benchmark application and the second running parameters of the test application using the test cases respectively; The detection result of the section module is determined based on the difference between the first operating parameter and the second operating parameter.

[0009] This specification provides a cross-section module detection device, the device comprising: The receiving module is used to receive the aspect file to be detected and compile the code in the aspect file to obtain the aspect module; An environment building module is used to determine the application environment that matches the aspect module based on the configuration file in the aspect file, and to deploy the application environment in a preset application container. The detection preparation module is used to deploy the aspect module to the application container, select at least one application for testing, inject the aspect module as a test application, and determine the application that has not been injected with the aspect module as a benchmark application. The test module is used to determine the test cases for the aspect module, and to determine the first running parameters of the benchmark application and the second running parameters of the test application through the test cases. The analysis and detection module is used to determine the detection result of the section module based on the difference between the first operating parameter and the second operating parameter.

[0010] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned section module detection method.

[0011] This specification provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described section module detection method.

[0012] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects: This specification discloses an aspect module detection method. For the aspect module compiled into the code under test, the required application environment for deployment is determined based on the configuration file. After configuring the aspect module into the container of the corresponding application environment, the aspect module is injected into a portion of the application. The remaining applications serve as a baseline. Test cases are used to automatically test the runtime parameters of whether or not the aspect module is injected. By comparing the differences in runtime parameters, the detection result of the aspect module is determined. Through the automatic construction of the container testing environment and the standardized detection process, efficient and accurate detection of aspect modules is achieved, reducing manual costs and making the detection results more practical. Attached Figure Description

[0013] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings: Figure 1 A flowchart of a section module detection process provided in the embodiments of this specification; Figure 2 This is a schematic diagram of the structure of the section module detection provided in the embodiments of this specification; Figure 3 This is a schematic diagram of a section module detection device provided in an embodiment of this specification; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this specification. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0015] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0016] Figure 1 A section module detection process diagram provided in the embodiments of this specification specifically includes the following steps: S100: Receive the aspect file to be detected, and compile the code in the aspect file to obtain the aspect module.

[0017] In the embodiments described in this specification, the following are employed: Figure 1The device used to perform the business operations as shown can be any electronic device, such as a computer, a server, or a server cluster consisting of multiple servers. For ease of description, the following explanation uses a server as an example only.

[0018] To address the issues of manually configuring test cases for aspect module testing, the complexity of the testing process, lack of repeatability, and low usability of the test results, this specification proposes an automated process for configuring the environment based on aspect files and performing comparative testing. This process can automatically test aspect modules without manual intervention, and the standardized testing process avoids most testing interference factors, making different test results comparable and greatly increasing the practicality of the testing.

[0019] It should be noted that, in the embodiments of this specification, the aspect injection process is a technical process in aspect-oriented programming (AOP) that dynamically or statically integrates the enhancement logic to be injected into the pointcut of a business application. It includes the entire process from identifying the need for aspect injection to finally injecting the aspect module. In the embodiments of this specification, the identity of the user requiring aspect module detection is not limited; it can be a service operator providing aspect programming services, a business operator of the application requiring aspect module injection, etc. Any user with a need to detect aspect modules can do so through... Figure 1 The process shown provides the aspect file to be detected, and the detection of the aspect module is implemented through the server.

[0020] Furthermore, the aspect module detection in the embodiments of this specification refers to the detection of the incremental impact of aspect code on the application after it is injected into the application. This detection process, in addition to focusing on the correctness and security of the aspect code itself, also examines its overall impact on the host application and environment, in order to detect the impact of aspect programming on the performance and stability of the injected system when improving functionality.

[0021] Specifically, in this embodiment, the server, acting as the entity performing aspect detection, can receive the aspect file to be detected sent by the user, which is the user-side user mentioned above. This aspect file contains at least the aspect code, i.e., the original code of the aspect module, and the configuration file of the aspect module. Since different aspect modules have different application environments and corresponding pointcuts depending on requirements, the aspect file also contains a configuration file. This configuration file describes the metadata definition of the aspect module's runtime environment and dependency constraints, ensuring that the application environment built based on the configuration file can guarantee the normal operation of the application into which the aspect module is injected, and the normal operation of the aspect module itself. It can also be understood that the configuration file contains the technology stack and runtime environment that the aspect module can accurately match with the application, and includes the context information of the environment during subsequent detection. Of course, this configuration file can be a standardized definition of the aspect module's runtime requirements and technical dependencies; for example, the configuration file can be based on configuration parameters provided by the server and selected by the user side.

[0022] As can be seen, the configuration files for aspect modules differ depending on the application environment. To detect the overall impact of aspect module injection on the injected application and environment, configuration files are included in the aspect files. In the embodiments described in this specification, these configuration files may include: basic runtime environment parameters, application framework parameters, application container parameters, middleware parameters, etc. Basic runtime environment parameters may include basic environment runtime information such as JDK version, operating system type and version, and memory allocation strategy. Application framework parameters include version information for frameworks such as Spring Boot, Dubbo, and MyBatis. Of course, the specific application frameworks supported can be set as needed, and this specification does not impose any restrictions. Application container parameters are used to define the type, version, and port configuration requirements of web containers such as Tomcat, Jetty, and Undertow. For example, the version, connection pool parameters, and cluster configuration information of middleware such as Redis, MySQL, and RocketMQ are considered middleware parameters.

[0023] Of course, the configuration file can also include detection parameters, such as observational configurations like data sampling frequency, JVM monitoring metrics, log output format, and pointcut tracing level. It can also include business application context parameters, such as application grouping, business domain identifiers, and environment isolation policies—business-level environment distinguishing identifiers. Furthermore, it can include environmental constraint parameters, such as CPU quotas, memory limits, network bandwidth, and persistent storage limits—infrastructure resource limits. Additionally, if the aspect module needs to rely on third-party data, the configuration file can also include compatibility versions of third-party libraries, SDK versions, and other shared components. Of course, as mentioned earlier, the server can determine a selection range based on its available resources, and the user can then choose from this range.

[0024] Furthermore, in the embodiments of this specification, after obtaining the aspect file, the server can determine the application environment of the code in the aspect file based on the configuration file in the aspect file. Then, based on the application environment, the code is compiled to obtain an aspect module that matches that application environment, i.e., an aspect module that can run in the target environment where the aspect needs to be injected.

[0025] Specifically, after obtaining the aspect file, the server first parses its configuration file. This configuration file contains core metadata defining the runtime dependencies of the aspect module, explicitly specifying the required runtime environment parameters, such as the specific JDK version, the type and version of the underlying framework (e.g., Spring Boot), the type of application container (e.g., Tomcat or Undertow), and the version information of middleware such as Redis and MySQL. By parsing these key configuration items, the server can accurately determine the target application environment for the aspect module design, providing accurate environment context and dependency constraints for subsequent compilation and deployment.

[0026] Subsequently, the server will initiate the compilation process for the aspect source code based on the determined application environment. According to the configuration requirements, the server selects a matching version of the JDK, imports the corresponding versions of framework dependency libraries and middleware clients, ensuring that the dependencies at compile time are completely consistent with the future runtime environment. Finally, through the compilation process associated with the application environment, an aspect module that is compatible with the target environment and can be run directly is generated.

[0027] S102: Based on the configuration file in the aspect file, determine the application environment that matches the aspect module, and deploy the application environment in the preset application container.

[0028] In the embodiments described in this specification, after obtaining the aspect file, the server can further construct an application and its runtime environment for deploying the aspect detection module. Therefore, a corresponding application environment can be deployed in a preset application container according to the configuration file. This application environment contains at least one application for detecting the aspect module.

[0029] Specifically, firstly, the server can determine the runtime environment parameters of the aspect module based on the configuration file in the aspect file; these parameters describe the application environment. These runtime parameters are similar to the application environment described above, but they refer to the specific parameters for building the target environment, such as key configuration items like JDK version, framework type, container specifications, and middleware version. The application environment refers to the runtime environment parameters required to compile the aspect module.

[0030] After obtaining the aspect file, the server can parse the configuration file and extract the runtime environment parameters. These parameters constitute the necessary dependencies for the aspect module to run, including but not limited to the target JDK version, the version of the underlying framework, the type and specifications of the application container, and the version information of various middleware (such as Redis and MySQL) that it depends on.

[0031] The server then selects an application environment image from a pre-defined application environment library that matches the runtime environment parameters. The server uses the parsed runtime environment parameters as filtering criteria to search and match within the pre-built and maintained application environment library. By comparing the parameters, the server selects application environment images compatible with the aspect module requirements to ensure environmental consistency during subsequent testing. The application environment library contains a large number of pre-defined, standardized application environment images, each corresponding to a complete and immediately usable technology stack.

[0032] Finally, the application environment image is distributed to the preset test device, enabling the test device to deploy the aspect-based application environment in its own application container based on the image. The server can distribute the matched application environment image to the preset test device. After receiving the image, the test device will use it as a template to quickly instantiate and start a complete runtime environment in its own isolated application container (such as a Docker container).

[0033] Furthermore, since the system environment alone within an application container is insufficient for testing aspect modules—meaning an isolated application environment cannot trigger the business logic of an aspect module—it is necessary to deploy an application within the application container that can activate the aspect. In other words, deploy an application that matches the aspect module. Matching here means that the deployed application contains the specific join points that the aspect module is designed to intercept. Specifically, the application's code must contain classes, methods, or execution paths precisely described by the advice type and pointcut expression defined in the aspect, ensuring that the aspect module can be correctly triggered and its enhanced logic executed during runtime in the application deployed in the application environment, thus verifying its functionality and performance.

[0034] Furthermore, deploying the complete application within the application environment ensures accurate detection, more closely resembling the actual effect after aspect module injection. However, this also increases the operational cost and pressure on the application container. Therefore, in some cases, servers can choose to deploy only partial application slices based on their settings.

[0035] Specifically, deploying a complete business application in the application environment would result in lower detection efficiency due to the large number of components unrelated to the current aspect module. Therefore, in the embodiments of this specification, the server can also deploy a targeted simulated application or application slice in the application environment. The specific application deployed can be determined by reverse inference based on the detection target of the aspect module. The server can parse the pointcut expressions in the aspect file to clarify the business operations it intends to intercept, and then automatically select or dynamically assemble a minimal functional unit containing these target operations from a pre-built application use case library. This unit only needs to implement the business process required to trigger the pointcut, thus forming a refined and efficient test carrier.

[0036] Through the above process, the construction of the test environment is made precise and automated. This ensures that the containers used for testing not only have the correct basic runtime environment but also contain the simplest application capable of effectively triggering aspect logic. This avoids the resource waste of deploying the full application while guaranteeing the relevance and effectiveness of the tests. It lays a reliable foundation for subsequently collecting accurate performance data and behavioral differences after aspect module injection, thereby comprehensively improving the efficiency of the testing process and the accuracy of the results.

[0037] S104: Deploy the aspect module to the application container, select at least one application for testing, inject the aspect module into it as a test application; and determine the application that has not been injected with the aspect module as a benchmark application.

[0038] In the embodiments described in this specification, after the server compiles the aspect module and deploys the application environment in the application container, it can deploy the aspect module into the application container and inject it into at least one application for testing through the aspect daemon within the container. Simultaneously, a test application in the same application environment without the injected aspect module serves as the baseline application.

[0039] Specifically, the testing equipment used to inspect aspect ratio modules may simultaneously support multiple test pipelines from different teams and projects, with each pipeline independently occupying one or more application containers. Therefore, it is necessary to determine the container corresponding to the current testing process from among multiple application containers to avoid erroneously interfering with other ongoing tests, which could lead to data contamination and invalid test results.

[0040] The server can first identify application container instances from each application container that have successfully deployed the application environment. These application containers pre-install one or more applications specifically designed for testing, which possess the basic business logic required to trigger aspect modules.

[0041] Next, the server can select at least one application from within the application container as a target and inject the compiled aspect module into that application via bytecode weaving or runtime loading, thereby generating a test application carrying aspect logic. Simultaneously, at least one other identical application instance within the application container is left in its original state without any injection processing, serving as a baseline application.

[0042] Then, by performing the same business operations in the test application as in the benchmark application, the running parameters in the two scenarios are obtained, forming an A / B test comparison model.

[0043] S106: Determine the test cases for the aspect module, and determine the first running parameters of the benchmark application and the second running parameters of the test application through the test cases.

[0044] S108: Determine the detection result of the section module based on the difference between the first operating parameter and the second operating parameter.

[0045] In the embodiments of this specification, after deploying the aspect module and obtaining the test application and benchmark application, test cases can be used to run the test, obtain the running parameters in the application container, and determine the detection result based on the difference in running parameters before and after injection. Of course, if the difference in running parameters after injecting the aspect module is small compared to before injection, it indicates that the aspect module performs well and has a small impact on the overall performance. Therefore, it can be simply assumed that the smaller the difference, the better the detection result. Generally, a threshold is set; if the difference exceeds the threshold, the detection fails, meaning that the aspect module's impact is too large and it is not suitable for deployment.

[0046] Specifically, the server first determines the test cases used to evaluate the aspect module. The server selects a set of test cases from a preset test case library or traffic pool that can trigger the logic of the aspect module. These test cases cover core business paths, boundary conditions, and abnormal situations to ensure comprehensive detection.

[0047] Next, the server executes the defined test cases on the benchmark application. During execution, the server synchronously monitors and records various performance metrics of the benchmark application as primary runtime parameters. These parameters include average interface response time, interface throughput, interface error rate, execution time of code pointcuts, number of pointcut calls, JVM heap memory usage, JVM garbage collection frequency and time, total application startup time, system CPU usage, system memory consumption, and the number of active threads in the thread pool, among other metrics.

[0048] Simultaneously, the server executes the exact same set of test cases on the test application. The server detects and records various performance metrics of the test application in the same manner as secondary runtime parameters. The server ensures that the environment and load conditions are completely identical for both tests to obtain a valid dataset for accurate comparison.

[0049] After acquiring the first and second operating parameters, the server can perform a detailed difference analysis on the two sets of parameters. The server calculates the performance changes or percentage changes of the test application relative to the benchmark application on various indicators, thereby quantifying the impact of the aspect module.

[0050] The server then compares the various performance differences with preset thresholds. The server determines whether the differences exceed the preset thresholds, such as whether the increase in interface response time exceeds 5% or the increase in memory usage exceeds 10%. These thresholds are performance baselines preset based on business requirements.

[0051] Finally, the server determines the final detection result based on the threshold comparison. If the differences of all key indicators do not exceed their corresponding preset thresholds, the server determines that the aspect module's detection result is passed and generates a notification indicating that the aspect file can be used for aspect programming. If the difference of any key indicator exceeds the preset threshold, the server determines that the detection result is failed.

[0052] In addition, when determining the test results, the server can compare various performance differences with preset multi-level thresholds. For example, performance indicators can be divided into key indicators (such as response time and error rate of core interfaces) and observation indicators (such as performance of secondary functions and resource consumption in specific scenarios), and different thresholds can be configured for them. The server determines whether the differences of each indicator exceed their respective threshold range. Of course, key indicators can be set as needed, and this manual does not impose any restrictions.

[0053] Alternatively, the server determines the total score based on the preset weights of each indicator and the differences between the indicators. If the final total score is higher than the preset threshold, the test is considered passed; otherwise, it is considered failed.

[0054] Alternatively, for each key indicator, if the difference in that key indicator exceeds its corresponding threshold, the server immediately determines the detection result as failing. Alternatively, the server can provide multi-level results such as "Excellent," "Pass," "Needs Optimization," and "Fail" based on the number and severity of non-compliant items, and provide a detailed improvement suggestion report for the "Needs Optimization" results.

[0055] Through this comprehensive judgment strategy, the server can provide more instructive test results. It can identify fatal defects that render aspect modules unusable, such as directly determining a test failure if key indicators exceed thresholds, or provide quantitative assessments of modules with optimization potential but not yet blocked from release, such as determining test results through weighted or tiered methods. This enhances the practicality and guidance value of the testing process while ensuring a minimum quality standard.

[0056] based on Figure 1 The aspect module detection method described above, for the aspect modules compiled into the code under test, determines the required application environment for deployment based on the configuration file. After configuring the aspect modules into the container of the corresponding application environment, the aspect modules are injected into a portion of the application. The remaining applications serve as a baseline. Test cases are used to automatically test the runtime parameters of whether or not the aspect modules are injected. By comparing the differences in runtime parameters, the detection result of the aspect modules is determined. By automatically building the container test environment and adopting a standardized detection process, efficient and accurate detection of aspect modules is achieved, reducing manual costs and making the detection results more practical.

[0057] In addition, in step S104, to test the versatility and stability of the aspect module in applications with different business logics and architectural characteristics, it is necessary to detect potential scenario-specific defects in the aspect module, i.e., it may work well under certain types of operations but cause performance degradation or functional abnormalities under other operations.

[0058] In the embodiments of this specification, after the server determines the application container, it can select multiple applications that differ in one or more aspects of business functions, architectural characteristics, or resource consumption patterns from multiple applications deployed inside it for testing, according to a preset strategy, as a candidate set.

[0059] The server then performs aspect injection on each of these selected applications, generating a set of test applications. For example, a service handling high-concurrency queries, a service performing complex transaction updates, and a service involving a large number of I / O operations might be injected with the same aspect module simultaneously. Furthermore, for each injected test application, the server can retain one or more identical, un-injected applications within the application container as its directly corresponding baseline applications.

[0060] By setting up this one-to-one comparison group, subsequent steps can collect multi-dimensional performance data of the aspect module under different business scenarios and technical paths. This not only verifies the versatility of the aspect function but also identifies its unusual impact on specific types of application operations, improving the comprehensiveness of the detection.

[0061] Furthermore, the embodiments in this specification extend the testing dimension to the infrastructure level. The server can first schedule multiple distributed application containers according to the environment requirements of the aspect module configuration file, and deploy a completely consistent application environment and application set in each container to build a homogeneous distributed test cluster.

[0062] Then, the server employs a distributed injection strategy, assigning test applications and benchmark applications to application instances in different containers to eliminate interference with test results caused by resource contention or performance fluctuations that may exist in a single container. In other words, full application injection is not performed in every container; for example, all applications in containers A and B are injected with aspect modules as the test group, while all applications in container C remain pure as the benchmark group.

[0063] The server can then simulate the real-world performance of the aspect module in a distributed architecture close to production conditions. By comparing the overall performance metrics of the test group and the baseline group on different physical nodes, the comprehensive impact of the aspect module at the server level can be evaluated more accurately, including its potential effects on network communication, resource contention, and cluster stability.

[0064] In the embodiments described in this specification, to facilitate fine-grained control and risk management of the testing process, the server first selects only one application within a single application container, injects the aspect module to form the first test application, defines its benchmark application, and performs the first round of rapid verification.

[0065] Subsequently, the server enters the extended testing phase. After passing the preset quality threshold in the first round of testing, the injection scope is automatically expanded. For example, the server may select two more applications with more complex business logic for injection within the same container, forming a second batch of test applications, and similarly set up their corresponding baseline applications. The extended testing phase can set up multiple extension processes to gradually increase the number and complexity of the injected applications or change the scope of the injection pointcut.

[0066] This phased, rolling testing approach is similar to an automated canary release process. It allows any negative impact introduced by aspect modules to be quickly identified and located early and on a small scale, thus avoiding the waste of time and resources caused by discovering major compatibility issues only after full-scale testing has begun. This minimizes the risk and optimizes the efficiency of the testing process.

[0067] In this context, the quality threshold refers to a set of metrics used to determine performance and stability, serving as the decision-making basis for whether an aspect module can proceed to the next stage in the automated testing pipeline. Specifically, the quality threshold is a series of technical standards used by the server in processes such as extended testing to determine whether the results of the current testing phase meet the requirements. These standards typically include, but are not limited to: the response time of core interfaces must not increase by a predetermined percentage (e.g., 5%), the business error rate must be zero, key JVM performance metrics (e.g., Full GC counts) must not show abnormal fluctuations, and system resource utilization must not reach the warning threshold. Only when the aspect module meets the requirements of these specified operating parameters in the current testing phase will the server automatically approve its entry into subsequent more complex and larger-scale testing stages; otherwise, the testing process will be terminated and the module will be marked as failing the current stage's test results.

[0068] In the embodiments described in this specification, in order to obtain detection results that more closely resemble actual conditions, the server can first schedule a group of heterogeneous application containers. For example, different CPU and memory quotas can be configured, and a hybrid application set consisting of multiple technology stacks and business modules can be deployed in them to highly simulate the complexity of a production environment.

[0069] Afterward, the server performs intelligent application orchestration and injection. Instead of simply injecting all applications or randomly selecting applications, the server dynamically calculates an injection strategy based on the target point of the aspect module, the application's call chain relationship, and the resource dependency graph. For example, it injects aspects into three related applications that are upstream and downstream of the same call chain to observe the full-link impact, while also including another independent, resource-intensive application in the test group, and setting the side application of the call chain as the baseline group.

[0070] Ultimately, through this highly realistic, topology-based hybrid deployment, the server can collect real-world performance data of the aspect module in complex servers. This includes not only direct performance overhead but also its potential impact on macro-level metrics such as inter-service call latency, transaction consistency, and overall server throughput, providing more valuable test results for the production-level deployment of the aspect module.

[0071] In addition, in one or more embodiments of this specification, after the server obtains the aspect code, it may first perform static code analysis. The server first performs static code rule analysis on the received aspect file. This analysis process is based on a set of rules derived from preset coding standards and / or practices, scanning for code style, structural regularity, and logical bugs. The server determines whether the code conforms to the established development standards by analyzing dimensions such as code complexity, naming conventions, and comment completeness.

[0072] Once the server determines that the aspect file has passed the static code rule detection, it can continue scanning for code security vulnerabilities. The server can perform in-depth analysis of potential security vulnerabilities in the code based on its built-in vulnerability rule base, focusing on detecting high-risk points such as SQL injection, command execution, path traversal, and insecure reflection.

[0073] Finally, in response to the aspect file successfully passing security checks and finding no security vulnerabilities, the server compiles the code according to the environment parameters specified in the configuration file attached to the aspect file. Based on parameters such as the JDK version and dependent library versions declared in the configuration, the server calls the matching compilation environment to compile the source code into aspect modules that can be deployed and run in the target environment.

[0074] Of course, the static analysis process can be executed after the server receives the code. If any test fails, the subsequent steps will not continue, and an error message will be returned.

[0075] Furthermore, in the embodiments described in this specification, a richer environment can be provided by adjusting the middleware when building the application environment. Similar to the application extensions described above, the two can be used in combination to further increase the versatility of detection.

[0076] For application environment updates only, the server selects an application environment image from a preset application environment library that matches the runtime environment parameters. Then, based on a preset adjustment strategy, it updates the middleware of the application environment image, identifying several non-standard application environment images. This strategy specifies the middleware type to be adjusted, the target version number, and the change rules. The server, according to this strategy, modifies the corresponding dependency configurations within the image to generate a series of non-standard application environment images with differences in middleware versions.

[0077] The core purpose of doing this is to systematically evaluate the compatibility and behavioral consistency of aspect modules in different middleware version environments, thereby identifying and avoiding potential risks caused by differences in dependency environments in advance.

[0078] Specifically, in the real software development and operation lifecycle, version upgrades, rollbacks, or heterogeneous deployments of middleware (such as Redis, MySQL, and message queues) are common. If an aspect module passes testing only in a specific standard environment image, it may cause functional abnormalities or performance degradation due to incompatibility when deployed to other versions of the application environment. By proactively creating a set of non-standard environment images covering a range of common versions, the server can simulate various deployment scenarios that may be encountered in the future.

[0079] Therefore, this step essentially treats environmental dependency as a clear testing dimension, constructing a matrix-like set of test environments through automation. This allows the server to verify the sensitivity of aspect modules to middleware versions before delivery, identify the range of stable versions, and provide accurate data support and decision-making basis for secure deployment in the production environment, effectively avoiding the problem of working normally in the test environment but malfunctioning in the production environment.

[0080] Subsequently, when deploying the application environment, the server can distribute the obtained non-standard application environment images to the test device, so that the test device can deploy the non-standard application environment image in different application containers for each non-standard application environment image as the application environment for the aspect module.

[0081] After receiving these images, the test equipment will create an independent application container instance for each non-standard application environment image and complete the deployment of the corresponding application environment in each container, thereby building a diverse aspect module runtime environment that can be compared with the benchmark environment for subsequent testing.

[0082] In one or more embodiments of this specification, in step S104, the server can determine the required test cases from a preset set of test cases. However, as the purpose of aspect modules goes beyond simple logging or performance monitoring and involves complex business logic, such as specific parameter validation, business process orchestration, or exception handling retry mechanisms, these general test cases become difficult to simulate the highly specific contextual scenarios necessary to trigger deep aspect logic. For example, an aspect used to intercept orders exceeding a threshold requiring risk control review may not be able to reach the risk control branch using only a general order placement test case.

[0083] Therefore, the server needs to further generate corresponding test cases using the Large Language Model (LLM) based on the deep context information extracted from the pointcuts. These test cases can accurately construct scenarios that may be missing from the preset test case set, such as "large orders" and "high-risk product orders," thus complementing the preset test cases and together forming a complete test set that can both guarantee basic coverage and verify complex aspect intentions.

[0084] Specifically, relying solely on manually written or interface-based generic test cases is insufficient to fully cover the complex and hidden code execution paths intercepted by aspects. Aspects often operate on common nodes of multiple methods, and their behavior is highly dependent on the specific calling context of the target method. By parsing the pointcut definition and extracting its contextual information, such as class name, method signature, and parameter types, the server can determine the information of the input model, i.e., where and under what code environment the input model needs to trigger aspects. This allows for the generation of targeted test cases for the large model.

[0085] Specifically, the server parses the configuration file in the aspect file, which contains the pointcut expression information of the aspect module, such as `@Pointcut("execution(* com.example.service.*.*(..))")`. By parsing the expression information, the server can identify the specific class, method, or code path that the aspect module intends to intercept, thereby determining the pointcut location injected into the application. For example, if the configuration file specifies that the pointcut is all public methods of the `UserService` class, the server will locate methods such as `createUser` and `deleteUser` under that class as the specific injection points.

[0086] Subsequently, the server extracts the context information of these pointcuts, including the name of the class containing the pointcut, the method signature, parameter types, and return type, and passes this information as input to the large model. The large model then uses this context to generate test cases covering normal processes, boundary conditions, and exceptional scenarios. For example, for the `createUser` method of `UserService`, the large model might generate one test case simulating a successful creation scenario with a valid username and password, and another test case simulating a parameter validation failure scenario with an empty username, thus ensuring that the test cases fully trigger the aspect logic and verify its behavior.

[0087] Figure 2 This is a structural diagram of the section module testing provided in this manual. The middle part is a process diagram of a testing procedure, including the steps described above. The left side is a process diagram of building a non-standard application environment. The right side is a diagram of the testing equipment and the server that determines the test results based on the operating parameters.

[0088] The above is an embodiment of a section module detection method provided in this specification. Based on the same idea, this specification also provides corresponding devices, storage media and electronic devices.

[0089] Figure 3 This is a schematic diagram of a section module detection device provided in an embodiment of this specification. The device includes: The receiving module 401 is used to receive the aspect file to be detected and compile the code in the aspect file to obtain the aspect module; The environment building module 402 is used to determine the application environment that matches the aspect module according to the configuration file in the aspect file, and to deploy the application environment in a preset application container; The detection preparation module 403 is used to deploy the aspect module to the application container, select at least one application for testing, inject the aspect module as a test application, and determine the application that has not been injected with the aspect module as a benchmark application. The test module 404 is used to determine the test cases for the aspect module, and to determine the first running parameters of the benchmark application and the second running parameters of the test application through the test cases. The analysis and detection module 405 is used to determine the detection result of the section module based on the difference between the first operating parameter and the second operating parameter.

[0090] Optionally, the receiving module 401 is configured to perform rule detection on the code in the aspect file according to preset static code rules; when the rule detection is passed, the code is determined to be correctly written, and the code is further subjected to security detection according to preset risk control vulnerability rules; in response to the security detection being passed, the code is determined to have no security vulnerabilities, and the code is compiled to obtain the aspect module according to the configuration file in the aspect file.

[0091] Optionally, the receiving module 401 is configured to determine the application environment of the code in the aspect file based on the configuration file in the aspect file; and compile the code according to the application environment to obtain an aspect module that matches the application environment.

[0092] Optionally, the environment building module 402 is used to determine the runtime environment parameters of the aspect module according to the configuration file in the aspect file; select an application environment image that matches the runtime environment parameters from a preset application environment library; and distribute the application environment image to a preset test device, so that the test device deploys the application environment of the aspect module in its own application container according to the application environment image.

[0093] Optionally, the environment building module 402 is used to update the middleware of the application environment image according to a preset adjustment strategy, determine several non-standard application environment images, and distribute the obtained non-standard application environment images to the test device, so that the test device deploys the non-standard application environment image in different application containers for each non-standard application environment image as the application environment of the aspect module.

[0094] Optionally, the detection preparation module 403 is used to determine the application container of the application environment in which the aspect module has been deployed; determine at least one application from the applications installed in the application container for testing, inject the aspect module into it to obtain an application containing the aspect module as a test application; and determine at least one application that has not been injected with the aspect module as a benchmark application.

[0095] Optionally, the test execution module 404 is used to determine the pointcut injected into the application by the aspect module according to the configuration file in the aspect file; and to generate several test cases through a large model according to the context information of the pointcut.

[0096] Optionally, the analysis and detection module 405 is used to determine the difference between the first operating parameter and the second operating parameter; determine whether the difference exceeds a preset threshold; if yes, then determine that the detection result of the aspect module is a failure; if no, then determine that the detection result of the aspect module is a success and return a notification, the notification being used to prompt that the aspect file is used for aspect programming.

[0097] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can be used to perform the section module detection method provided above.

[0098] based on Figure 1 The cross-section module detection method shown in this specification also provides embodiments that... Figure 4 The diagram shows the structure of the electronic device. Figure 4 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to implement the aforementioned aspect module detection method.

[0099] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for detecting a section module, the method comprising: Receive the aspect file to be detected, and compile the code in the aspect file to obtain the aspect module; Based on the configuration file in the aspect file, determine the application environment that matches the aspect module, and deploy the application environment in the preset application container; The aspect module is deployed to the application container, at least one application for testing is selected and injected with the aspect module as a test application; and applications that have not been injected with the aspect module are identified as benchmark applications. Determine the test cases for the aspect module, and determine the first running parameters of the benchmark application and the second running parameters of the test application using the test cases respectively; The detection result of the section module is determined based on the difference between the first operating parameter and the second operating parameter.

2. The method as described in claim 1, wherein compiling the code in the aspect file to obtain the aspect module specifically includes: According to preset static code rules, the code in the aspect file is subjected to rule detection; Once the rule check is passed, the code is determined to be correct, and the code is then subjected to security checks according to the preset risk control vulnerability rules. In response to the security test passing, it is determined that the code has no security vulnerabilities. Based on the configuration file in the aspect file, the code is compiled to obtain the aspect module.

3. The method as described in claim 1, wherein compiling the code in the aspect file to obtain the aspect module specifically includes: The application environment of the code in the aspect file is determined based on the configuration file in the aspect file; Based on the application environment, the code is compiled to obtain an aspect module that matches the application environment.

4. The method as described in claim 1, wherein the application environment matching the aspect module is determined according to the configuration file in the aspect file, and the application environment is deployed in a preset application container, specifically includes: Based on the configuration file in the aspect file, determine the runtime environment parameters of the aspect module; Select an application environment image that matches the runtime environment parameters from the preset application environment library; The application environment image is distributed to a preset test device, so that the test device deploys the application environment of the aspect module in its own application container according to the application environment image.

5. The method as described in claim 4, wherein the application environment image is distributed to a preset test device, specifically including: According to the preset adjustment strategy, the middleware of the application environment image is updated to identify several non-standard application environment images. The obtained non-standard application environment images are distributed to the test device, so that the test device can deploy the non-standard application environment image in different application containers for each non-standard application environment image as the application environment of the aspect module.

6. The method as described in claim 1, wherein the aspect module is deployed to the application container, at least one application for testing is selected, the aspect module is injected into it as a test application, and an application without the aspect module is identified as a benchmark application, specifically including: Identify the application container of the application environment in which the aspect module has been deployed; From the applications installed in the application container for testing, at least one application is identified, and the aspect module is injected to obtain an application containing the aspect module, which serves as the test application; and at least one application without the aspect module is identified as the benchmark application.

7. The method as described in claim 1, wherein determining the test cases for the aspect module specifically includes: Based on the configuration file in the aspect file, determine the pointcut injected into the application by the aspect module; Based on the context information of the cutpoint, several test cases are generated using the large model.

8. The method as described in claim 2, wherein determining the detection result of the section module based on the difference between the first operating parameter and the second operating parameter specifically includes: Determine the difference between the first operating parameter and the second operating parameter; Determine whether the difference exceeds a preset threshold; If so, then the detection result of the section module is determined to be a failure. If not, the detection result of the aspect module is determined to be a successful detection, and a notification is returned. The notification is used to prompt that the aspect file is used for aspect programming.

9. A section module detection device, the device comprising: The receiving module is used to receive the aspect file to be detected and compile the code in the aspect file to obtain the aspect module; An environment building module is used to determine the application environment that matches the aspect module based on the configuration file in the aspect file, and to deploy the application environment in a preset application container. The detection preparation module is used to deploy the aspect module to the application container, select at least one application for testing, and inject the aspect module as a test application. In addition, identify applications that have not been injected with the aforementioned section module as benchmark applications; The test module is used to determine the test cases for the aspect module, and to determine the first running parameters of the benchmark application and the second running parameters of the test application through the test cases. The analysis and detection module is used to determine the detection result of the section module based on the difference between the first operating parameter and the second operating parameter.

10. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method according to any one of claims 1-8.

Images