A fault test method, device, storage medium and electronic equipment

Abstract

The specification discloses a fault test method, device, storage medium and electronic equipment. First, a fault test task is received. Then, according to the fault test task, a pointcut base pre-deployed in an application container is used to determine a pointcut of a business application program in the application container and a pointcut program to be deployed, the pointcut program being used to cause the business application program in the application container to fail. Then, the pointcut base is used to inject the pointcut program into the pointcut of the business application program in the application container. When the pointcut program is triggered during business execution, the pointcut program is executed, an exception of the application container is triggered, and / or an exception of the business application program is triggered. Finally, according to a business execution result of the business application program, a fault test result is determined. The pointcut program is used to implement fault test, the coupling degree of the business application program and the fault test program is reduced, the workload is reduced, and the cost is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a fault testing method, apparatus, storage medium, and electronic device. Background Technology

[0002] Currently, with the rapid development of the Internet, users are paying more and more attention to their own privacy data, and the fault testing of business applications is also developing accordingly.

[0003] In the prior art, there are chaos engineering methods that perform fault testing by inducing business application failures and observing the state of the business application. Chaos engineering is based on the way that the business application actively induces failures for fault testing.

[0004] However, implementing chaos engineering requires writing fault test programs based on the business application to induce faults. This results in a high degree of coupling between the business application and the fault test programs, leading to a large workload and high cost for chaos engineering.

[0005] Based on this, this specification provides a method for fault testing using a safety cross-section. Summary of the Invention

[0006] This specification provides a fault testing method, apparatus, storage medium, and electronic device, which are used to at least partially solve the problems existing in the prior art.

[0007] The following technical solution is adopted in this specification:

[0008] This manual provides a fault testing method, including:

[0009] Receive fault test tasks;

[0010] According to the fault test task, the aspect to be deployed and the pointcut of the business application in the application container are determined by the aspect base pre-deployed in the application container. The aspect is used to trigger a fault in the business application in the application container.

[0011] The faceting program is injected into the point of the business application in the application container through the faceting base;

[0012] When the aspect is triggered during business execution, the aspect is executed, which triggers an exception in the application container and / or triggers an exception in the business application.

[0013] The fault test results are determined based on the business execution results of the business application.

[0014] This manual provides a fault testing device, including:

[0015] The receiving module is used to receive fault test tasks;

[0016] The determination module is used to determine the aspect to be deployed and the pointcut of the business application in the application container based on the fault test task and the aspect base pre-deployed in the application container. The aspect is used to cause the business application in the application container to fail.

[0017] The deployment module is used to inject the aspect program into the pointcut of the business application in the application container through the aspect base;

[0018] An execution module is used to execute the aspect when it is triggered during business execution, triggering an exception in the application container and / or triggering an exception in the business application.

[0019] The testing module is used to determine the fault test results based on the business execution results of the business application.

[0020] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described fault testing method.

[0021] This specification provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described fault testing method.

[0022] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects:

[0023] The fault testing method provided in this specification first receives a fault testing task. Then, based on the fault testing task, an aspect to be deployed and the pointcut of the business application in the application container are determined through an aspect base pre-deployed in the application container. This aspect is used to trigger a fault in the business application in the application container. Then, through the aspect base, the aspect is injected into the pointcut of the business application in the application container. When the aspect is triggered during business execution, it is executed, triggering an exception in the application container and / or triggering an exception in the business application. Finally, the fault test result is determined based on the business execution result of the business application. By using aspect-based testing, the coupling between the business application and the fault testing program is reduced, the workload is reduced, the cost is lowered, and the flexibility of fault testing is improved. Attached Figure Description

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

[0025] Figure 1 This manual provides a schematic diagram of a fault testing process.

[0026] Figure 2 This is a schematic diagram of a test system provided in this specification;

[0027] Figure 3 This is a schematic diagram of a fault testing device provided in this specification;

[0028] Figure 4 This is a schematic diagram of an electronic device for implementing a fault testing method as provided in this specification. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this application 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 application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort are within the scope of protection of this application.

[0030] Currently, with the rapid development of internet technology, the requirements for the stability of business application systems are becoming increasingly stringent. To detect system faults as early as possible, fault testing techniques can be used. Currently, chaos engineering is employed for system stability fault testing. Essentially, chaos engineering involves actively inducing or simulating faults within the business application system, observing the system's response, and determining whether the system has defects, i.e., its stability. To test the system's real-world performance, chaos engineering fault testing is typically performed in a production environment.

[0031] Generally, chaos engineering requires implementing fault testing programs based on the business application to induce faults. During application development or maintenance, different developers are typically responsible for developing both the business application and the fault testing programs. This approach, where fault testing programs are based on the business application, results in a high degree of coupling between the two. This necessitates extensive communication between developers responsible for different tasks to achieve fault testing, leading to a significant workload and high time cost. Furthermore, during version iterations, whether it's iterating the business application or the fault testing programs, developers from both sides need to further adjust their respective programs based on the code changes made during the iteration. This ensures that the iteration process and fault testing proceed synchronously, continuously improving system stability. However, during this communication and adjustment process, code faults unrelated to testing are highly likely to occur, increasing the risk of code modification, further increasing workload, and raising time costs.

[0032] On the other hand, since fault testing through chaos engineering is typically conducted in a production environment, while fault testing is implemented directly through coding based on business applications, it is difficult to adjust the code in a timely manner to control the blast radius of the fault when unexpected test results occur, resulting in poor system stability. The blast radius refers to the scope of the final fault caused by a chain reaction triggered by a local fault during business application execution.

[0033] In addition, there are methods for testing chaotic engineering faults using black-box testing. However, on the one hand, black-box testing often only allows input to the system's exposed input interfaces, making it difficult to conduct targeted testing on various methods of the business application, resulting in poor testing effectiveness. Furthermore, if unexpected events occur during testing, it is difficult to undo the system changes introduced by black-box testing, thus controlling the blast radius of the fault and easily causing unexpected failures during testing, leading to poor system stability.

[0034] This specification provides a fault testing method that reduces the coupling between business applications and fault testing programs by adopting a secure aspect ratio approach. This allows business applications and fault testing to develop independently, reduces the workload of implementing fault testing, increases the flexibility of adjusting fault testing, and reduces costs.

[0035] The security aspect mentioned above refers to a method that uses aspect-oriented programming (AOP) to dynamically add or modify aspects within the runtime logic of a business application to implement security-related business logic without modifying the application itself. This decouples the implementation of security-related business logic from the business application, thus avoiding development iteration problems caused by high coupling.

[0036] The aspect program mentioned here refers to an enhancement program that implements security aspect functionality based on business logic. By using aspect-oriented programming, aspect programs can be injected into corresponding pointcuts in the business application. These aspect programs are triggered and executed during the execution of the business application to achieve the required security aspect functionality.

[0037] When a business application executes its business logic, it typically does so through method calls. Therefore, any method within the business application can be used as a pointcut for an aspect, as mentioned above, and the aspect can be injected into the corresponding pointcut. This ensures that when the business application reaches a pointcut—that is, when it calls a method of the business application corresponding to that pointcut—the injected aspect is executed.

[0038] Typically, the code responsible for injecting aspects into pointcuts has high reusability. Therefore, the program implementing this process is usually abstracted into a service module, namely the aspect base. The aspect base can obtain the aspects to be deployed and the pointcuts in the business application from a third party that provides secure aspect services. After the application container starts, it is configured by the environment and the corresponding aspects are injected at the pointcuts in the business application.

[0039] A business application can be a business application that provides business services on the servers of a business platform. These business services can be services provided by the business platform's servers to users, such as query services and payment services. Business services can also be services provided by one server of the business platform to other servers, such as settlement services.

[0040] Of course, as described above, to decouple the security aspect service program from the business application, this specification employs aspect-oriented programming (AOP) to allow the security aspect service program and the business application to intertwine during business execution, while remaining parallel and independently maintainable. Therefore, unlike the business application provider, the third party providing the security aspect service can manage the content related to the security aspect service through a management platform, such as configuring security aspect service management policies, iterating aspect program versions, configuring aspect program deployment rules, etc. Of course, the provider of the security aspect service can be either a third party or a business application provider.

[0041] When managing the content related to security aspect services, the management platform can record various configuration information through configuration files, such as the configuration of various policies and the deployment rules for aspect programs. This allows the aspect base to deploy aspect programs based on the configuration files, or the management platform to implement security aspect services based on the configuration files.

[0042] In practical applications, service providers typically set up data centers containing several physical machines or servers, providing the physical resources required by business applications. Of course, a business application may not require all the physical resources of a single physical machine; therefore, virtualization technology is often used to run multiple virtual hosts on a single physical machine. Each virtual host is independent, sharing a portion of the physical resources of the physical machine. Application containers can then be deployed within these virtual hosts, and business applications can run through these containers. Application containers typically contain the physical resources allocated to them, such as CPU and memory, as well as the runtime environment provided to them, such as the operating system (OS) or other runtime environment data (e.g., container serial number, assigned IP address, application name, tenant, environment variables, etc.). Business applications can be deployed within these application containers to execute business logic.

[0043] In scenarios where secure aspect-based business execution is used, the server of the business provider or a third party providing secure aspect services can provide a management platform. The management platform can manage the content involved in the secure aspect services and deploy the aspect base in the application container. The aspect program is injected into the business application in the business application container through the aspect base, so as to provide secure aspect service support for the application container of the business provider.

[0044] Therefore, the aspect-oriented framework can be pre-deployed in the application container of the service provider. Typically, when the application container starts, the operating system provided to the application container is invoked, and the pre-deployed aspect-oriented framework runs. The aspect-oriented framework obtains the aspect programs and pointcuts of the business application from the management platform and injects the aspect programs into the pointcuts of the business application within the application container. Furthermore, the aspect-oriented framework can also obtain the aspect programs and pointcuts of the business application from the management platform during the execution of the business application and inject the aspect programs into the pointcuts of the business application within the application container.

[0045] Of course, how the segmentation base obtains the information required for deploying the segmentation program from the management platform can be configured as needed. For example, it can actively pull the required information from the management platform based on the configuration file, or the management platform can actively send the required information to the segmentation base.

[0046] After injecting an aspect into a pointcut of a business application, the business application can trigger the aspect during execution to achieve the corresponding security aspect business function.

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

[0048] Figure 1 This is a schematic diagram of a fault testing process in this manual, which specifically includes the following steps:

[0049] S100: Receive fault test task.

[0050] Generally, business applications can be deployed in application containers, and business operations are executed through method calls. Based on the calling relationships between methods, at least some methods can be selected as pointcuts. Fault test code can be injected into the pointcuts through aspect-oriented programming, and then the system status can be observed to test whether the business application system will fail.

[0051] Therefore, in one or more embodiments of this specification, the application container can receive a fault test task through a faceted base pre-deployed in the application container, and complete the fault test according to the fault test task.

[0052] The aspect-based platform is a service module responsible for receiving fault testing tasks and loading aspect programs. Business applications can be deployed through application containers. The application container, in response to a startup command, completes the deployment of the business application and receives fault testing tasks through the aspect-based platform, which is pre-deployed within the application container. These fault testing tasks may include aspect deployment rules, specifically the aspect to be deployed, the pointcuts of the business application in the application container, and the deployment method. This allows the aspect-based platform to further deploy and perform fault testing based on the fault testing task. The specific information included in the fault testing task can be determined as needed; this specification does not impose any restrictions on this.

[0053] The application container mentioned in this specification can be an application container provided by a service platform, such as a PaaS platform. Application containers typically run on the business platform's servers. For ease of explanation, the following description focuses solely on the application container as the execution entity.

[0054] S102: Based on the fault test task, the aspect to be deployed and the point of the business application in the application container are determined by the aspect base pre-deployed in the application container. The aspect is used to trigger a fault in the business application in the application container.

[0055] Upon receiving the fault test task, the application container can determine the aspect to be deployed and the pointcut of the business application in the application container based on the aspect base pre-deployed in the application container. The aspect is used to trigger a fault in the business application in the application container.

[0056] The fault testing task may include aspects to be deployed, pointcuts in the business application within the application container, and deployment methods. Of course, aspects can contain multiple types of sub-aspects, each used to generate different types of exceptions at different pointcuts in the business application.

[0057] Therefore, the application container can determine the deployment rules of the aspect program through the aspect base according to the aforementioned fault test task, and then determine the correspondence between the various sub-aspects to be deployed and the various sub-aspects to be deployed and the pointcuts of the business application in the application container according to the deployment rules, so that the aspect program can be deployed in the future according to the correspondence.

[0058] Of course, the business application in the application container can preset multiple methods as multiple pointcuts. Then, the application container can first use the aspect base to determine the deployment pointcuts corresponding to the fault test task from the pointcuts of the business application, and determine the correspondence between the various sub-aspects to be deployed and the deployment pointcuts according to the deployment rules.

[0059] For example, in an e-commerce POS application system, testing can be conducted to determine whether the system will experience financial losses or accounting discrepancies under extreme business scenarios. The application container, through an aspect-based architecture, determines the deployment rules of aspect programs based on the fault testing task. Based on these rules, it identifies the various sub-aspects to be deployed and the corresponding deployment pointpoints for the fault testing task from the various pointpoints of the e-commerce POS application. In this case, the e-commerce POS application can identify pointpoints for CPU burn, memory exhaustion, and transient turbulence, and determine the corresponding sub-aspects for these scenarios. This allows for the subsequent injection of these sub-aspects into the respective pointpoints for fault testing.

[0060] S104: Inject the faceting program into the point of the business application in the application container through the faceting base.

[0061] After determining the aspect to be deployed and the pointcut of the business application in the application container, the application container can further inject the aspect into the pointcut of the business application in the application container through the aspect daemon, so as to trigger a fault at the corresponding pointcut through the aspect.

[0062] Of course, in one or more embodiments of this specification, each type of sub-aspect program may correspond to multiple versions of the sub-aspect program, and different sub-aspect programs correspond to different exception triggering strategies. The exception triggering strategy can be understood as conducting fault testing by triggering exceptions of different degrees.

[0063] Taking the memory exhaustion sub-aspect as an example, this type of sub-aspect can correspond to multiple sub-aspects, each with different levels of memory usage. For example, there could be a sub-aspect that uses 300MB of memory, a sub-aspect that uses 600MB of memory, and a sub-aspect that uses 900MB of memory, etc. This is just an example, and this specification does not impose any limitations. Other types of sub-aspects are similar.

[0064] The received fault test task may include at least the correspondence between the exception triggering strategy and each sub-aspect, so that the application container can first determine the target sub-aspect from the multiple sub-aspects corresponding to each type of sub-aspect based on the current exception triggering strategy of the business application in the application container and the correspondence, and then inject each target sub-aspect into each point of the business application through the aspect base according to the correspondence between each type of sub-aspect and each point of the business application in the application container.

[0065] For example, taking the example in step S102, it can be determined that the target sub-aspect of the CPU burning sub-aspect is the sub-aspect with a CPU utilization rate of 80%, and the target sub-aspect of the memory exhaustion sub-aspect is the sub-aspect that occupies 600MB of memory, and so on. Then, the target sub-aspects corresponding to each type of sub-aspect are injected into the corresponding pointcuts.

[0066] S106: When the aspect is triggered during business execution, the aspect is executed, triggering an exception in the application container and / or triggering an exception in the business application.

[0067] S108: Determine the fault test result based on the business execution result of the business application.

[0068] After the aspect program is deployed as described above, when the business process reaches the point of attack through method calls, the aspect program corresponding to the point of attack will be executed, and the aspect program will generate the corresponding exception at the point of attack.

[0069] Therefore, in one or more embodiments of this specification, when an aspect is triggered during business execution, the application container can execute the aspect, triggering an exception in the application container and / or triggering an exception in the business application.

[0070] When the aspect programs corresponding to each pointcut are triggered, an exception may occur at that point. However, business application systems can usually improve their disaster recovery capabilities to avoid operational failures caused by local exceptions, thus improving system stability. Therefore, by generating exceptions at each pointcut and observing the system's state, it is possible to test whether the business application is experiencing operational failures.

[0071] For various sub-aspects, when the sub-aspect corresponding to the application container hardware class is executed, it can trigger a hardware exception in the hardware corresponding to the application container. Taking the aforementioned CPU burning sub-aspect as an example, it can trigger a hardware exception in the CPU of the application container. Alternatively, when the sub-aspect corresponding to the business application class is executed, it can trigger a program exception in the business application during business execution. For example, the process killing sub-aspect can randomly kill the process by calling the system interface, causing the process to terminate abnormally, and the business application will generate a program exception.

[0072] Then, the application container can determine the fault test result based on the business execution results of the business application. For example, taking the example in step S102 again, if a failure occurs during the execution of the business application, such as financial loss or unbalanced accounts, this failure can be taken as the fault test result, indicating that the stability of the e-commerce POS business application system needs to be improved, and the user can be prompted to further iteratively optimize based on the cause of the failure. If no failure occurs during the execution of the business application, the fault test result can be determined as good, indicating that the e-commerce POS business application system has good stability when facing the pressure corresponding to this test, and the user can be prompted to continue to conduct other tests.

[0073] based on Figure 1 The fault testing method described herein receives fault testing tasks via an aspect-based platform pre-deployed in an application container. Based on the fault testing tasks, it determines the aspects to be deployed and the pointcuts of the business application within the application container. The aspects are used to trigger faults in the business application within the application container. Through the aspect-based platform, the aspects are injected into the pointcuts of the business application within the application container. When the aspect is triggered during business execution, it is executed to test whether the business application has failed. By using aspects for fault testing, the coupling between the business application and the fault testing program is reduced, workload is decreased, costs are lowered, and the flexibility of fault testing is improved.

[0074] Furthermore, in one or more embodiments of this specification, in step S104, when the application container injects the aspect program into the pointcut of the business application in the application container via the aspect base, the aspect program is typically stored in a compressed format on the aspect management platform. Therefore, the application container can obtain the compressed aspect program to be deployed from the aspect management platform via the aspect base, and then inject the aspect program into the pointcut of the business application in the application container via the aspect base. The deployment of the aspect program is then completed for fault testing.

[0075] Furthermore, in one or more embodiments of this specification, when an aspect is triggered for execution, the application container can, during the execution of the aspect, determine the fault condition corresponding to the fault test result based on the fault test result. That is, it monitors the operational faults generated by the business application in the application container. Then, based on the fault condition and the preset test conditions for fault testing, it determines whether the fault condition matches the test conditions. If yes, it indicates that no unexpected situation has occurred in the current fault testing process, and fault testing can continue. If no, it indicates that an unexpected situation has occurred in the current fault testing, which may have caused additional faults. To avoid causing greater damage and reduce the fault blast radius, the application container can switch the execution state of the aspect to a closed state, so that the aspect is not triggered when the business application executes. That is, the current fault test is stopped. Of course, for cases where the aspect contains multiple modules, the execution state of each type of sub-aspect can be switched to a closed state one by one according to a preset order, so that the test is downgraded and the scope of the fault is prevented from expanding.

[0076] For fault testers, fault testing can typically be conducted according to a fault test plan. The optimal scenario for each fault test is that the system is relatively stable and no faults occur, while the worst scenario is that the faults specified in the test plan occur. In the worst scenario, optimization and iteration can be performed to improve system stability. The optimal to worst scenario represents the preset test conditions for fault testing described above.

[0077] Furthermore, in one or more embodiments of this specification, if an additional fault is triggered and the current test is stopped, the application container can also receive a fault test request through the aspect base. Based on the fault test request, the state corresponding to each sub-aspect in the aspect program is determined. Then, for each sub-aspect, when the state corresponding to the sub-aspect is in the open state, the execution state corresponding to the sub-aspect is switched to the open state through the aspect base. When the aspect is executed, an exception of the corresponding type is generated by executing the sub-aspect. When the state corresponding to the sub-aspect is in the closed state, the execution state corresponding to the sub-aspect is switched to the closed state through the aspect base. When the aspect is executed, the sub-aspect is not executed, so that when the aspect is triggered, no exception of the corresponding type is generated. Then, through the aspect base, the adjusted aspect is injected into the pointcut of the business application in the application container, and fault testing is performed again to determine the cause of the additional fault, so as to optimize and iterate the business application system according to the cause.

[0078] Furthermore, in one or more embodiments of this specification, during fault testing, the application container can adjust the execution status of various sub-section programs at any time through the section base, adjust the test content, and improve the flexibility of fault testing.

[0079] In one or more embodiments of this specification, Figure 2 This is a schematic diagram of a test system provided in this specification, such as... Figure 2 As shown, the testing system includes a business application system and a fault testing system.

[0080] like Figure 2 As shown, the fault testing system may include a control platform, a cross-section base, a cross-section program, and a fault testing server.

[0081] The management platform can be used by administrators to manage aspect deployment and different aspect programs. For example, it can perform aspect logic orchestration, that is, determine which program to inject at which point to achieve fault testing. It can also maintain and manage the point list, that is, save the unique identifier of each point preset by the business application. It can also manage the version management and management configuration of different versions of sub-aspect programs corresponding to different exception triggering strategies. The management configuration is to enable which type of sub-aspect program in the aspect program.

[0082] The aspect-based base can be used to inject aspect programs into business applications of business application systems based on the pointcut identifiers and deployment rules contained in the fault test tasks issued by the management platform. The pointcut identifier is a unique identifier for each pointcut, used to distinguish different pointcuts.

[0083] Aspect-oriented programming (AOP) can be used to trigger execution during the execution of a business application. When a sub-aspect of the aspect corresponding to the hardware class of the application container is executed, it can trigger a hardware exception in the hardware corresponding to the application container. Alternatively, when a sub-aspect of the aspect corresponding to the business application class is executed, it can trigger a program exception in the business application during business execution. As mentioned above, sub-aspects can include CPU-type sub-aspects, storage-type sub-aspects (which may include memory, cache, etc.), and other types of sub-aspects.

[0084] The business application system provides examples of various pre-configurable pointcuts in business applications, such as CPU burn pointcuts, process kill pointcuts, memory exhaustion pointcuts, etc. The aspect base can inject corresponding type of sub-aspect programs into the corresponding pointcuts, causing each pointcut to generate corresponding exceptions. For a detailed description, please refer to the aforementioned explanations.

[0085] The above are fault testing methods provided by one or more embodiments of this specification. Based on the same idea, this specification also provides corresponding fault testing devices, such as... Figure 3 As shown.

[0086] Figure 3 A schematic diagram of a fault testing device provided in this specification includes:

[0087] Receiver module 200 is used to receive fault test tasks;

[0088] The determination module 202 is used to determine the aspect to be deployed and the point of the business application in the application container based on the fault test task and the aspect base pre-deployed in the application container. The aspect is used to cause the business application in the application container to fail.

[0089] Deployment module 204 is used to inject the aspect program into the pointcut of the business application in the application container through the aspect base;

[0090] The execution module 206 is used to execute the aspect program when the aspect program is triggered during business execution, triggering an exception in the application container and / or triggering an exception in the business application.

[0091] The test module 208 is used to determine the fault test results based on the business execution results of the business application.

[0092] Optionally, the aspect procedure includes multiple types of sub-aspect procedures, each type of sub-aspect procedure being used to generate different types of exceptions at different cut points in the business application;

[0093] The determining module 202 determines the deployment rules of the aspect program according to the fault test task, and determines the correspondence between the various types of sub-aspect programs to be deployed and the various types of sub-aspect programs to be deployed and the pointcuts of the business application in the application container according to the deployment rules.

[0094] Optionally, the business application has multiple preset cutpoints;

[0095] The determining module 202 determines, from the various cutpoints of the business application, the deployment cutpoints corresponding to the fault test task according to the fault test task, and determines the correspondence between the various sub-aspect programs to be deployed and the deployment cutpoints according to the deployment rules.

[0096] Optionally, each type of sub-aspect program corresponds to multiple sub-aspect programs, and different sub-aspect programs correspond to different exception triggering strategies. The fault testing task includes at least the correspondence between the exception triggering strategies and each sub-aspect program.

[0097] The deployment module 204 determines the target sub-aspect from multiple sub-aspects corresponding to each type of sub-aspect based on the current exception triggering strategy of the business application in the application container and the correspondence. Through the aspect base, it injects each target sub-aspect into each point of the business application according to the correspondence between each type of sub-aspect and each point of the business application in the application container.

[0098] Optionally, the execution module 206 executes the sub-aspect of the aspect program corresponding to the hardware class of the application container, triggering a hardware exception in the hardware corresponding to the application container, or executes the sub-aspect of the aspect program corresponding to the business application class, triggering a program exception in the business application during business execution.

[0099] Optionally, the device further includes: a stop module 210, configured to determine the fault condition corresponding to the fault test result based on the fault test result, and determine whether the fault condition matches the test condition based on the fault condition and the preset test conditions of the fault test. If yes, the fault test result is sent to the user; if no, it is determined that an additional fault has been caused, and the execution state of the aspect program is switched to a closed state so that the aspect program is not triggered when the business application is executed, and the current fault test is stopped.

[0100] Optionally, the stop module 210 receives a fault test request through the aspect base, determines the state of each sub-aspect in the aspect program according to the fault test request, and for each sub-aspect, when the state of the sub-aspect is on, switches the execution state of the sub-aspect to on through the aspect base, and when the aspect program is executed, it generates an exception of the corresponding type by executing the sub-aspect. When the state of the sub-aspect is off, it switches the execution state of the sub-aspect to off through the aspect base, and when the aspect program is executed, it does not execute the sub-aspect, so that when the aspect program is triggered, it does not generate an exception of the corresponding type of the sub-aspect. Through the aspect base, the aspect program is injected into the pointcut of the business application in the application container, and the fault test is performed again.

[0101] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-described... Figure 1 The provided fault testing methods.

[0102] This instruction manual also provides Figure 4 The diagram shows the structure of the electronic device. Figure 4At 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 the business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above-mentioned functions. Figure 1 The provided fault testing methods.

[0103] Of course, in addition to the software implementation method, this specification does not exclude other implementation methods, such as the combination of hardware and software XOR logic devices, etc. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0104] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0105] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0106] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0107] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0108] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0109] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0110] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0111] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0112] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0113] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0114] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

[0116] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0117] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0118] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0119] 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 fault testing method, the method comprising: Receive fault test tasks; According to the fault testing task, the aspect programs to be deployed and the pointcuts of the business applications in the application container are determined by the aspect base pre-deployed in the application container. The aspect programs are used to cause the business applications in the application container to fail. The aspect programs include multiple types of sub-aspect programs, each type of sub-aspect program corresponds to multiple sub-aspect programs, and different sub-aspect programs correspond to different exception triggering strategies. The fault testing task includes at least the correspondence between the exception triggering strategies and each sub-aspect program. Based on the current exception triggering strategy of the business application in the application container and the corresponding relationship, the target sub-aspect is determined from multiple sub-aspects corresponding to each type of sub-aspect. Based on the correspondence between various sub-section programs and the cut points of the business application in the application container, each target sub-section program is injected into each cut point of the business application through the section base. When the aspect is triggered during business execution, the aspect is executed, which triggers an exception in the application container and / or triggers an exception in the business application. The fault test results are determined based on the business execution results of the business application.

2. The method as described in claim 1, wherein the business application has multiple preset pointcuts; Based on the deployment rules, the correspondence between the various sub-aspects to be deployed and the pointcuts of the business applications in the application container is determined, specifically including: Based on the fault test task, determine the deployment points corresponding to the fault test task from the various pointcuts of the business application; Based on the deployment rules, determine the correspondence between the various sub-aspects to be deployed and each deployment point.

3. The method as described in claim 1, wherein executing the aspect procedure triggers an exception in the application container and / or triggers an exception in the business application, specifically includes: Execute the sub-aspect of the aspect procedure corresponding to the hardware class of the application container, and trigger the hardware corresponding to the application container to generate a hardware exception; or Execute the sub-aspect of the aspect program corresponding to the business application class, triggering a program exception in the business application during business execution.

4. The method of claim 1, further comprising: Based on the fault test results, determine the fault condition corresponding to the fault test results; Based on the fault condition and the preset test conditions for the fault test, determine whether the fault condition matches the test conditions; If so, the fault test results will be sent to the user; If not, it is determined that an additional fault has been caused, and the execution state of the aspect program is switched to a closed state so that the aspect program is not triggered when the business application is executed, and the current fault test is stopped.

5. The method described in claim 4, stopping the current fault test, specifically includes: The fault test request is received through the slicing base, and the status of each sub-slicing program in the slicing program is determined according to the fault test request. For each sub-aspect program, when the corresponding state of the sub-aspect program is in the open state, the execution state of the corresponding sub-aspect program is switched to the open state through the aspect base. When the aspect program is executed, an exception of the corresponding type is generated by executing the sub-aspect program. When the state corresponding to the sub-aspect is closed, the execution state corresponding to the sub-aspect is switched to closed by the aspect base. When the aspect is executed, the sub-aspect is not executed, so that when the aspect is triggered, no exception of the type corresponding to the sub-aspect is generated. Using the faceted base, the faceted program is injected into the cutpoint of the business application in the application container, and a fault test is performed again.

6. A business execution apparatus, the apparatus comprising: The receiving module is used to receive fault test tasks; The determination module is used to determine, based on the fault test task and through the aspect base pre-deployed in the application container, the aspect to be deployed and the pointcut of the business application in the application container. The aspect is used to cause the business application in the application container to fail. The aspect includes multiple types of sub-aspects, each type of sub-aspect corresponds to multiple sub-aspects, and different sub-aspects correspond to different exception triggering strategies. The fault test task includes at least the correspondence between the exception triggering strategies and each sub-aspect. The deployment module is used to determine the target sub-aspect from multiple sub-aspects corresponding to each type of sub-aspect based on the current exception triggering strategy of the business application in the application container and the correspondence; and to inject each target sub-aspect into each point of the business application through the aspect base according to the correspondence between each type of sub-aspect and each point of the business application in the application container. An execution module is used to execute the aspect when it is triggered during business execution, triggering an exception in the application container and / or triggering an exception in the business application. The testing module is used to determine the fault test results based on the business execution results of the business application.

7. 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 to 6.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any one of claims 1 to 6.

Images