Abnormity verification method, device and equipment of insurance policy service system and storage medium

Abstract

The invention relates to the technical field of testing, in particular to an exception verification method and device for an insurance policy service system, equipment and a storage medium, and the method comprises the steps: recognizing a software architecture and all operation subsystems of the insurance policy service system; performing state abnormity verification on a plurality of layers of the software architecture to obtain a first verification result; performing environment connectivity abnormity verification on all the operation subsystems to obtain a second verification result; and generating an abnormal verification result of the full-link operation environment of the insurance policy service system according to the first verification result and the second verification result. Therefore, the problems of relatively high test cost, relatively poor coverage comprehensiveness and the like in related technologies are solved.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to an abnormality verification method, device, equipment and storage medium for an insurance policy business system. Background Art

[0002] The insurance business system is an important part of the modern financial system, involving multiple complex subsystems and business processes. Some systems are composed of several microservices, and the interaction between systems is relatively complex. If any system or subservice has a problem, the environment will not work, resulting in the failure of insurance business signing.

[0003] The following methods are mainly used in related technologies to test the environment of the insurance policy business system: 1. Manual testing, but manual inspection and data comparison are time-consuming, labor-intensive, and prone to errors, especially when the system is large. The efficiency of manual testing is very low and the cost is high; 2. Scripted testing, writing scripts to automatically check the status of the system, but often only focusing on the status of a certain level or a subsystem, lacks comprehensive verification of the entire link environment. Summary of the invention

[0004] The present application provides an abnormality verification method, device, equipment and storage medium for an insurance policy business system to solve the problems of high testing cost and poor comprehensive coverage in related technologies.

[0005] The first aspect of the present application provides an exception verification method for an insurance policy business system, comprising the following steps: identifying the software architecture and all running subsystems of the insurance policy business system; performing status exception verification at multiple levels of the software architecture to obtain a first verification result; performing environmental connectivity exception verification on all running subsystems to obtain a second verification result; and generating an exception verification result for the full-link operating environment of the insurance policy business system based on the first verification result and the second verification result.

[0006] Optionally, the multiple levels of the software architecture include first to third levels, and status anomaly checks are performed on the multiple levels of the software architecture to obtain a first verification result, including: at the first level of the software architecture, status anomaly checks are performed according to the container deployment type; at the second level of the software architecture, status anomaly checks are performed according to the external business interface status of the running subsystem; at the third level of the software architecture, status anomaly checks are performed according to the actual number of nodes and actual parameters of the running subsystem; and the first verification result is determined based on the status anomaly check results of the first to third levels.

[0007] Optionally, the container deployment type includes a container deployment class and a non-container deployment class, and a status abnormality check is performed according to the container deployment type, including: if the running subsystem is a container deployment class, a status abnormality check is performed according to the running status of each Pod in the running subsystem; if the running subsystem is a non-container deployment class, a status abnormality check is performed according to the status of a related application process of the running subsystem on the server to which the running subsystem belongs.

[0008] Optionally, a status abnormality check is performed according to the status of the external business interface of the running subsystem, including: calling the external business interface of the running subsystem; if the interface returns normal, the running subsystem status is determined to be normal, otherwise the running subsystem status is determined to be abnormal.

[0009] Optionally, a status abnormality check is performed based on the actual number of nodes and actual parameters of the running subsystem, including: obtaining the reference number of nodes and reference parameters of the running subsystem; if the actual number of nodes is inconsistent with the reference number of nodes, and / or the actual parameters are inconsistent with the reference parameters, it is determined that the status of the running subsystem is abnormal, otherwise the status of the running subsystem is normal.

[0010] Optionally, an environmental connectivity anomaly check is performed on all running subsystems to obtain a second check result, including: obtaining a target quantity of test data; inputting the test data into the insurance policy business system, and checking the actual quantity of database records of all running subsystems; if the actual quantity is inconsistent with the target quantity, the second check result is abnormal, otherwise the second check result is normal.

[0011] Optionally, after performing status abnormality checks on multiple levels of the software architecture to obtain a first verification result, it also includes: if the first verification result is a status abnormality, then no environmental connectivity abnormality check is performed on all running subsystems, and an abnormality verification result of the full-link operating environment of the insurance policy business system is generated based on the first verification result.

[0012] The second aspect of the present application provides an abnormality verification device for an insurance policy business system, including: an identification module, used to identify the software architecture and all running subsystems of the insurance policy business system; a first verification module, used to perform status abnormality verification on multiple levels of the software architecture to obtain a first verification result; a second verification module, used to perform environmental connectivity abnormality verification on all running subsystems to obtain a second verification result; a generation module, used to generate an abnormality verification result of the full-link operating environment of the insurance policy business system based on the first verification result and the second verification result.

[0013] Optionally, the multiple levels of the software architecture include first to third levels, and the first verification module is further used to: at the first level of the software architecture, perform a status anomaly check according to the container deployment type; at the second level of the software architecture, perform a status anomaly check according to the external business interface status of the running subsystem; at the third level of the software architecture, perform a status anomaly check according to the actual number of nodes and actual parameters of the running subsystem; determine the first verification result based on the status anomaly check results of the first to third levels.

[0014] Optionally, the container deployment type includes a container deployment class and a non-container deployment class, and the first verification module is further used to: if the running subsystem is a container deployment class, perform a status abnormality check based on the running status of each Pod in the running subsystem; if the running subsystem is a non-container deployment class, perform a status abnormality check based on the status of a related application process of the sub-running system on the server to which the running subsystem belongs.

[0015] Optionally, the first verification module is further used to: call the external business interface of the running subsystem; if the interface returns normal, determine that the running subsystem is in a normal state, otherwise determine that the running subsystem is in an abnormal state.

[0016] Optionally, the first verification module is further used to: obtain the reference node number and reference parameters of the running subsystem; if the actual node number is inconsistent with the reference node number, and / or the actual parameters are inconsistent with the reference parameters, determine that the subsystem state is abnormal, otherwise the subsystem state is normal.

[0017] Optionally, the second verification module is further used to: obtain a target quantity of test data; input the test data into the insurance policy business system, and check the actual quantity of database records of all running subsystems; if the actual quantity is inconsistent with the target quantity, the second verification result is abnormal, otherwise the second verification result is normal.

[0018] Optionally, it also includes: a first generation module, which is used to perform status exception verification on multiple levels of the software architecture to obtain a first verification result. If the first verification result is a status exception, no environmental connectivity exception verification is performed on all running subsystems, and an exception verification result of the full-link operating environment of the insurance policy business system is generated according to the first verification result.

[0019] The third aspect of the present application 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 execute an abnormality check method for the insurance policy business system as in the above-mentioned embodiment.

[0020] The fourth aspect of the present application provides a computer-readable storage medium on which a computer program or instruction is stored. The computer program or instruction is executed by a processor to perform an abnormality verification method for an insurance policy business system as in the above-mentioned embodiment.

[0021] Therefore, this application has at least the following beneficial effects:

[0022] The embodiment of the present application can perform state abnormality verification on all operating subsystems of the insurance policy business system at multiple levels to obtain a first verification result, and perform environmental connectivity abnormality verification on all operating subsystems of the insurance policy business system to obtain a second verification result, and generate abnormality verification results of the full-link operating environment of the insurance policy business system based on the first verification result and the second verification result, so as to realize operation abnormality verification of the insurance policy business system at different levels, ensure the accuracy and comprehensiveness of the verification results, and do not require manual operation, which can be realized through automated tools and scripts, thereby improving the automation level of the test and saving labor costs and testing time. Therefore, technical problems such as high testing costs and poor comprehensive coverage in related technologies are solved.

[0023] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0025] Figure 1 A flowchart of an abnormality verification method for an insurance policy business system provided according to an embodiment of the present application;

[0026] Figure 2 A structural diagram of an insurance policy business system provided according to an embodiment of the present application;

[0027] Figure 3 This is an example diagram of an abnormality checking device of an insurance policy business system provided according to an embodiment of the present application;

[0028] Figure 4 It is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0029] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0030] The following describes the abnormality verification method, device, equipment and storage medium of the insurance policy business system of the embodiment of the present application with reference to the accompanying drawings. In view of the problems of high efficiency and low cost of manual testing and poor comprehensiveness of scripted testing in the related technologies mentioned in the above background technology center, the present application provides an abnormality verification method for an insurance policy business system, in which all running subsystems of the insurance policy business system can be checked for state abnormalities at multiple levels to obtain a first verification result, and all running subsystems of the insurance policy business system can be checked for environmental connectivity abnormalities to obtain a second verification result, and an abnormality verification result of the full-link operating environment of the insurance policy business system is generated based on the first verification result and the second verification result, so as to realize the operation abnormality verification of the insurance policy business system at different levels, ensure the accuracy and comprehensiveness of the verification results, and do not require manual operation, and can be realized through automated tools and scripts, thereby improving the degree of automation of the test and saving labor costs and testing time. As a result, the problems of high testing cost and poor comprehensive coverage in the related technologies are solved.

[0031] Specifically, Figure 1 A flowchart of an abnormality verification method for an insurance policy business system provided in an embodiment of the present application.

[0032] like Figure 1 As shown, the abnormality verification method of the insurance policy business system includes the following steps:

[0033] In step S101, the software architecture and all operating subsystems of the insurance policy business system are identified.

[0034] Among them, the policy business can also be understood as the insurance business, which usually involves multiple subsystems; the software architecture includes the first level to the third level, the first level can be the deployment level, the second level can be the service level, and the third level can be the configuration level, and the three levels are in a progressive relationship.

[0035] For example, the Abaotong insurance and signing process involves more than a dozen subsystems, such as policy service domain, core, image, seal, message center, etc.

[0036] In step S102, a state abnormality check is performed on multiple levels of the software architecture to obtain a first check result.

[0037] It can be understood that the embodiment of the present application can perform status anomaly checks on multiple levels of the software architecture to obtain a first check result, that is, perform status anomaly checks on the first to third levels respectively, as follows.

[0038] In an embodiment of the present application, a state abnormality check is performed at multiple levels of the software architecture to obtain a first check result, including: at the first level of the software architecture, a state abnormality check is performed according to the container deployment type; at the second level of the software architecture, a state abnormality check is performed according to the external business interface status of the running subsystem; at the third level of the software architecture, a state abnormality check is performed according to the actual number of nodes and actual parameters of the running subsystem; and the first check result is determined based on the state abnormality check results of the first to third levels.

[0039] It is understandable that the embodiment of the present application can determine how to perform status abnormality check based on the level of software architecture, specifically:

[0040] At the first level, status anomaly check is performed based on the container deployment type of the running subsystem;

[0041] At the second level, status abnormality check is performed based on the external business interface status of the running subsystem;

[0042] At the third level, anomaly checks are performed based on the actual number of nodes and actual parameters of the running subsystem;

[0043] Then, the first verification result, ie, the abnormal state or the normal state, is determined according to the abnormal state verification results at the three levels.

[0044] It should be noted that if the status is abnormal during verification at the first level, the verification of the second level, third level and environmental connectivity will not be performed directly. Similarly, if the status of the first level is normal and the status of the second level is abnormal, the verification of the third level and environmental connectivity will not be performed.

[0045] In an embodiment of the present application, the container deployment type includes a container deployment class and a non-container deployment class, and a status abnormality check is performed according to the container deployment type, including: if the running subsystem is a container deployment class, a status abnormality check is performed according to the running status of each Pod in the running subsystem; if the running subsystem is a non-container deployment class, a status abnormality check is performed according to the status of the related application process of the running subsystem on the server to which the running subsystem belongs.

[0046] Among them, the container deployment class is the k8s container class.

[0047] It can be understood that in the embodiment of the present application, when the running subsystem is a container deployment class, an exception check is performed according to the running status of each Pod in the running subsystem. For example, the k8s service verifies whether the status of each pod is running, and the non-running status is determined to be unavailable (pending, crash, etc.);

[0048] When the running subsystem is a non-container deployment type, perform status abnormality check based on the status of the relevant application process of the subsystem on the server to which the running subsystem belongs. For example, check whether the application process is alive to determine whether the status is abnormal. You can use ps aux|grep'service keyword' to determine the process status, which can ensure that effective status check can be performed regardless of how the system is deployed.

[0049] In an embodiment of the present application, a status abnormality check is performed based on the status of the external business interface of the running subsystem, including: calling the external business interface of the running subsystem; if the interface returns normal, the running subsystem status is determined to be normal, otherwise the running subsystem status is determined to be abnormal.

[0050] It can be understood that the embodiment of the present application can call the external business interface exposed by the subsystem, and judge the status of the subsystem by the return of the interface. If the interface returns normal, for example, the interface returns 1, the subsystem status is normal; if the interface returns 0, the subsystem status is abnormal.

[0051] For another example, use the curl command to call the POST / createPolicy interface and check whether the returned status code is 200 and whether the response content contains a success prompt message.

[0052] In an embodiment of the present application, a status abnormality check is performed based on the actual number of nodes and actual parameters of the running subsystem, including: obtaining the reference number of nodes and reference parameters of the running subsystem; if the actual number of nodes is inconsistent with the reference number of nodes, and / or the actual parameters are inconsistent with the reference parameters, it is determined that the status of the running subsystem is abnormal, otherwise the status of the running subsystem is normal.

[0053] The reference node number and reference parameters are standard values ​​in the running subsystem, and the parameters include JVM parameters such as limit and request.

[0054] It is understandable that the present application may compare the current actual number of nodes and actual parameters of the running subsystem with the reference number of nodes and reference parameters respectively, and if any one of them is inconsistent, it is determined that the running subsystem state is abnormal.

[0055] For example, if the target number of nodes is 3 and the jwm parameter is -Xms512m-Xmx1024m, if the actual number of nodes is 4 and the jwm parameter is -Xms512m-Xmx1024m, it is considered abnormal. If the actual number of nodes is 3 and the jwm parameter is -Xms513m-Xmx1024m, it is also considered abnormal.

[0056] In step S103, an environmental connectivity anomaly check is performed on all running subsystems to obtain a second check result.

[0057] It can be understood that the embodiment of the present application can perform an environmental connectivity anomaly check on all running subsystems and obtain a second check result, that is, perform an environmental connectivity check on the entire insurance policy business system to determine whether the connectivity between all subsystems is normal.

[0058] In an embodiment of the present application, an environmental connectivity anomaly check is performed on all running subsystems to obtain a second check result, including: obtaining a target number of test data; inputting the test data into the insurance policy business system, and checking the actual number of database records of all running subsystems; if the actual number is inconsistent with the target number, the second check result is abnormal, otherwise the second check result is normal.

[0059] The target number is represented by N, which is an integer.

[0060] It can be understood that the embodiment of the present application can input the target number of test data into the insurance policy business system, and check the actual number of database records of each running subsystem. If the actual number is inconsistent with the target number, the second verification result is abnormal, otherwise the second verification result is normal, ensuring that the data is not lost during the transmission and storage process within the system. Among them, the stress testing tool can use JMeter to send the test data to the insurance policy business system.

[0061] It should be noted that the above situation is applicable to the case where the amount of data in the database is zero, and whether the environmental connectivity is abnormal can be determined by comparing the actual number and the target number. If the number in the database is not zero, whether the environmental connectivity is abnormal can be determined by comparing the added number in the database with the target number.

[0062] For example, 10 test data are prepared and sent to the creation interface of the insurance policy service using JMeter. The database of each running subsystem is checked to see if the actual number of records is 10. If not, it is considered abnormal, otherwise it is normal.

[0063] In step S104, an abnormality verification result of the full-link operating environment of the insurance policy business system is generated according to the first verification result and the second verification result.

[0064] It can be understood that the embodiment of the present application can generate an abnormal verification result of the full-link operating environment of the insurance policy business system based on the first verification result and the second verification result. If the first verification result is normal and the second verification result is abnormal, the abnormal verification result of the full-link operating environment of the insurance policy business system is also abnormal, thereby realizing operation abnormality verification of the insurance policy business system at different levels without the need for manual operation. It can be achieved through automated tools and scripts, thereby improving the degree of automation of the test and saving labor costs and testing time.

[0065] In an embodiment of the present application, after performing status abnormality checks on multiple levels of the software architecture to obtain a first verification result, it also includes: if the first verification result is a status abnormality, then no environmental connectivity abnormality check is performed on all running subsystems, and an abnormality check result of the full-link operating environment of the insurance policy business system is generated based on the first verification result.

[0066] It can be understood that the embodiment of the present application may not perform environmental connectivity abnormality check on all running subsystems when the first verification result is an abnormal status, and generate an abnormality check result of the full-link operating environment of the insurance policy business system based on the first verification result. The abnormality check result of the full-link operating environment of the insurance policy business system is directly generated based on the first verification result, without the need for subsequent redundant testing, saving testing resources and time.

[0067] The following describes the abnormality checking method of the insurance policy business system of the embodiment of the present application through a specific embodiment. Figure 2 Taking the insurance system in as an example, the verification is divided into four steps.

[0068] 1. Deployment level verification

[0069] (1) Container deployment: The k8s service verifies whether the status of each pod is running. Non-running status is considered unavailable (pending, crash, etc.);

[0070] (2) Non-container deployment: Check whether the relevant application process on the corresponding server is alive. Specifically, use ps aux|grep 'service keyword' to determine the process status.

[0071] 2. Service-level verification: All system business interfaces on the link are checked for activity (to ensure single service availability).

[0072] 3. Configuration level verification: Verify key performance parameters such as the number of deployed nodes and JVM parameters.

[0073] (1) Kubernetes container class: Check the namespace dimension corresponding to the system and verify the deployment configuration of the corresponding service, including key performance parameters such as the number of replicas and java_heap.

[0074] The benchmark is set in advance, which is the number of pods, jvm parameters, limits, and request standard values ​​corresponding to each running subsystem. Then, the deployment of the real service is checked through the k8s command to see whether the configuration is consistent with the benchmark. The overall process can be automated through shell scripts.

[0075] (2) Non-container class: The JVM parameters of non-container class can be viewed by checking the startup script or by running ps aux|grep 'system keyword'.

[0076] 4. Environmental connectivity verification: Perform interface stress testing on the slave end, stress testing N pieces of data, and verify in turn whether the N pieces of data are actually stored in the database table corresponding to each system. If any system data does not match, it is determined that the system environment is abnormal.

[0077] According to the abnormality verification method of the insurance policy business system proposed in the embodiment of the present application, the status abnormality verification can be performed on all running subsystems of the insurance policy business system at multiple levels to obtain a first verification result, and the environment connectivity abnormality verification can be performed on all running subsystems of the insurance policy business system to obtain a second verification result. Based on the first verification result and the second verification result, the abnormality verification result of the full-link operating environment of the insurance policy business system is generated, and the operation abnormality verification of the insurance policy business system at different levels is realized to ensure the accuracy and comprehensiveness of the verification results. No manual operation is required, and it can be achieved through automation tools and scripts, thereby improving the degree of automation of the test and saving labor costs and testing time.

[0078] Next, the abnormality checking device of the insurance policy business system proposed in the embodiment of the present application is described with reference to the accompanying drawings.

[0079] Figure 3 It is a block diagram of an abnormality checking device of the insurance policy business system of an embodiment of the present application.

[0080] like Figure 3 As shown, the abnormality verification device 10 of the insurance policy business system includes: an identification module 100, a first verification module 200, a second verification module 300 and a generation module 400.

[0081] Among them, the identification module 100 is used to identify the software architecture and all running subsystems of the insurance policy business system; the first verification module 200 is used to perform status abnormality verification at multiple levels of the software architecture to obtain a first verification result; the second verification module 300 is used to perform environmental connectivity abnormality verification on all running subsystems to obtain a second verification result; the generation module 400 is used to generate an abnormality verification result of the full-link operating environment of the insurance policy business system based on the first verification result and the second verification result.

[0082] In an embodiment of the present application, the multiple levels of the software architecture include the first to third levels, and the first verification module 200 is further used to: at the first level of the software architecture, perform a status anomaly check according to the container deployment type; at the second level of the software architecture, perform a status anomaly check according to the external business interface status of the running subsystem; at the third level of the software architecture, perform a status anomaly check according to the actual number of nodes and actual parameters of the running subsystem; determine the first verification result based on the status anomaly check results of the first to third levels.

[0083] In an embodiment of the present application, the container deployment type includes a container deployment class and a non-container deployment class, and the first verification module 200 is further used to: if the running subsystem is a container deployment class, then perform a status abnormality check based on the running status of each Pod in the running subsystem; if the running subsystem is a non-container deployment class, then perform a status abnormality check based on the status of the related application process of the running subsystem on the server to which the running subsystem belongs.

[0084] In an embodiment of the present application, the first verification module 200 is further used to: perform a status abnormality check based on the status of the external business interface of the running subsystem, including: calling the external business interface of the running subsystem; if the interface returns normal, the running subsystem status is determined to be normal, otherwise the running subsystem status is determined to be abnormal.

[0085] In an embodiment of the present application, the first verification module 200 is further used to: obtain the reference node number and reference parameters of the running subsystem; if the actual node number is inconsistent with the reference node number, and / or the actual parameters are inconsistent with the reference parameters, then it is determined that the state of the running subsystem is abnormal, otherwise the state of the running subsystem is normal.

[0086] In an embodiment of the present application, the second verification module 300 is further used to: obtain a target quantity of test data; input the test data into the insurance policy business system, and check the actual quantity of database records of all running subsystems; if the actual quantity is inconsistent with the target quantity, the second verification result is abnormal, otherwise the second verification result is normal.

[0087] In the embodiment of the present application, the device 10 of the embodiment of the present application further includes: a first generating module.

[0088] Among them, the first generation module is used to perform status exception verification on multiple levels of the software architecture to obtain the first verification result. If the first verification result is a status exception, no environmental connectivity exception verification is performed on all running subsystems, and an exception verification result of the full-link operating environment of the insurance policy business system is generated according to the first verification result.

[0089] It should be noted that the above explanation of the embodiment of the abnormality verification method of the insurance policy business system is also applicable to the abnormality verification device of the insurance policy business system of this embodiment, and will not be repeated here.

[0090] According to the abnormality verification device of the insurance policy business system proposed in the embodiment of the present application, the status abnormality verification can be performed on all operating subsystems of the insurance policy business system at multiple levels to obtain a first verification result, and the environment connectivity abnormality verification can be performed on all operating subsystems of the insurance policy business system to obtain a second verification result. Based on the first verification result and the second verification result, the abnormality verification result of the full-link operating environment of the insurance policy business system is generated, and the operation abnormality verification of the insurance policy business system at different levels is realized to ensure the accuracy and comprehensiveness of the verification results. No manual operation is required, and it can be achieved through automation tools and scripts, thereby improving the degree of automation of the test and saving labor costs and testing time.

[0091] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include:

[0092] Memory 401 , processor 402 , and a computer program stored in the memory 401 and executable on the processor 402 .

[0093] When the processor 402 executes the program, the abnormality checking method of the insurance policy business system provided in the above embodiment is implemented.

[0094] Furthermore, the electronic device further comprises:

[0095] The communication interface 403 is used for communication between the memory 401 and the processor 402 .

[0096] The memory 401 is used to store computer programs that can be executed on the processor 402 .

[0097] The memory 401 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0098] If the memory 401, the processor 402 and the communication interface 403 are implemented independently, the communication interface 403, the memory 401 and the processor 402 can be connected to each other through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0099] Optionally, in a specific implementation, if the memory 401, the processor 402 and the communication interface 403 are integrated on a chip, the memory 401, the processor 402 and the communication interface 403 can communicate with each other through an internal interface.

[0100] The processor 402 may be a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0101] The embodiment of the present application also provides a computer-readable storage medium on which a computer program or instruction is stored. When the computer program or instruction is executed by a processor, the above-mentioned abnormality verification method of the insurance policy business system is implemented.

[0102] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0103] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0104] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or N executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0105] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above embodiment, the N steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one or a combination of multiple of the following technologies known in the art: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0106] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

Claims

1. An abnormality checking method for an insurance policy business system, characterized in that: The following steps are involved: Identify the software architecture and all operational subsystems of the insurance policy business system; Performing status anomaly verification at multiple levels of the software architecture to obtain a first verification result; Performing an environmental connectivity anomaly check on all the operating subsystems to obtain a second check result; An abnormal verification result of the full-link operating environment of the insurance policy business system is generated based on the first verification result and the second verification result.

2. The abnormality checking method of the insurance policy business system according to claim 1, characterized in that: The multiple levels of the software architecture include first to third levels, and the state abnormality check is performed on the multiple levels of the software architecture to obtain a first check result, including: At the first level of the software architecture, status anomaly check is performed according to the container deployment type; At the second level of the software architecture, a status abnormality check is performed according to the external business interface status of the operating subsystem; At the third level of the software architecture, a status abnormality check is performed according to the actual number of nodes and actual parameters of the running subsystem; The first verification result is determined according to the status abnormality verification results of the first to third levels.

3. The abnormality checking method of the insurance policy business system according to claim 2, characterized in that: The container deployment type includes a container deployment type and a non-container deployment type, and the abnormal state check according to the container deployment type includes: If the running subsystem is the container deployment class, a status abnormality check is performed according to the running status of each Pod in the running subsystem; If the running subsystem is of the non-container deployment type, a status abnormality check is performed according to the status of the application process related to the running subsystem on the server to which the running subsystem belongs.

4. The abnormality checking method of the insurance policy business system according to claim 2, characterized in that: The performing a status abnormality check according to the external service interface status of the operating subsystem includes: Calling the external business interface of the operating subsystem; If the interface returns to normal, it is determined that the operating subsystem is in a normal state; otherwise, it is determined that the operating subsystem is in an abnormal state.

5. The abnormality checking method of the insurance policy business system according to claim 2, characterized in that: The performing of status abnormality check according to the actual number of nodes and actual parameters of the running subsystem includes: Obtaining the reference node number and reference parameters of the running subsystem; If the actual number of nodes is inconsistent with the reference number of nodes, and / or the actual parameters are inconsistent with the reference parameters, it is determined that the state of the operating subsystem is abnormal; otherwise, the state of the operating subsystem is normal.

6. The abnormality checking method of the insurance policy business system according to claim 1, characterized in that: The performing of an abnormal environment connectivity check on all the running subsystems to obtain a second check result includes: Get the target amount of test data; Input the test data into the insurance policy business system and check the actual number of database records of all running subsystems; If the actual quantity is inconsistent with the target quantity, the second verification result is abnormal; otherwise, the second verification result is normal.

7. The abnormality checking method of the insurance policy business system according to claim 1, characterized in that: After performing status abnormality checks on multiple levels of the software architecture to obtain a first check result, the method further includes: If the first verification result is an abnormal state, the environment connectivity abnormality check is not performed on all the operating subsystems, and the abnormality check result of the full-link operating environment of the insurance policy business system is generated according to the first verification result.

8. An abnormality checking device for an insurance policy business system, characterized in that: include: Identification module, used to identify the software architecture and all operating subsystems of the insurance policy business system; A first verification module, used for performing state abnormality verification on multiple levels of the software architecture to obtain a first verification result; A second verification module is used to perform an abnormal environment connectivity verification on all the operating subsystems to obtain a second verification result; A generation module is used to generate an abnormal verification result of the full-link operating environment of the insurance policy business system based on the first verification result and the second verification result.

9. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the abnormality verification method of the insurance policy business system as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: The computer program or instruction is executed by a processor to implement the abnormality verification method of the insurance policy business system as described in any one of claims 1-7.

Images