Business system pressure test method and device, storage medium and electronic equipment

Abstract

The invention provides a pressure test method and device for a service system, a storage medium and electronic equipment, and relates to the technical field of tests.The method comprises the steps that a system architecture diagram of a to-be-tested service system can be obtained; generating a pressure test file according to the system architecture diagram; generating a monitoring data template corresponding to the pressure test file, and setting a first constraint threshold and a second constraint threshold for the monitoring data template; the first constraint threshold comprises an alarm level threshold; the second constraint threshold value is obtained by setting monitoring reference data obtained based on historical test records, or is obtained by setting based on a resource index threshold value configured by a user; if the service system is subjected to the pressure test, collecting pressure test monitoring data of the service system; and detecting the pressure test monitoring data according to the first constraint threshold and the second constraint threshold to obtain a detection result of the pressure test monitoring data, the detection result being used for indicating whether the pressure test passes or not. The judgment accuracy of a test result can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of testing, in particular to a business system stress testing method and device, a storage medium and an electronic equipment. BACKGROUND

[0002] In the field of software engineering, especially in the aspect of ensuring the stability of core business systems, production environment stress testing is a crucial quality assurance activity. In the prior art, such testing usually relies on test personnel to predefine test scenarios, manually configure monitoring indicators and set fixed performance thresholds. After the test is executed, the performance data of the field responsible by the person in charge of each system module, such as server resource utilization, database response performance and network bandwidth usage, etc., needs to be collected and analyzed by the person in charge of each system module, and finally the test conclusion is formed by manual summary and cross comparison.

[0003] However, in the prior art, a high degree of reliance on manual experience and cross-team collaboration results in low testing efficiency and difficulty in ensuring the consistency of the test conclusion. Specifically, due to the lack of systematic sedimentation and automatic reuse mechanism of historical effective test data, the threshold setting and result analysis of each stress test are almost from scratch, which not only consumes a lot of manpower and time, but also makes the test results inaccurate due to the differences in technical level and judgment standard of different personnel. SUMMARY

[0004] The technical problem to be solved by the present application is to provide a business system stress testing method, device, storage medium and electronic equipment, which can improve the judgment accuracy of the test results. The specific scheme is as follows:

[0005] A business system stress testing method, comprising:

[0006] In response to a stress testing instruction, a system architecture diagram of a business system to be tested uploaded by a user is obtained;

[0007] According to the system architecture diagram, a stress testing file is generated;

[0008] A monitoring data template corresponding to the stress testing file is generated, and a first constraint threshold and a second constraint threshold are set for the monitoring data template; the first constraint threshold includes an alarm level threshold; the second constraint threshold is set based on monitoring benchmark data obtained from historical test records or based on a resource indicator threshold configured by the user;

[0009] Under the condition of stress testing the business system, stress testing monitoring data of the business system is collected;

[0010] According to the first constraint threshold and the second constraint threshold, detection is performed on the pressure test monitoring data, and a detection result of the pressure test monitoring data is obtained, the detection result being used to indicate whether the pressure test is passed.

[0011] The method described above, optionally, the generating the monitoring data template corresponding to the pressure test file comprises:

[0012] Based on the pressure test file, it is determined whether there is a historical test record of the same system architecture;

[0013] If there is a historical test record of the same system architecture, monitoring reference data in the historical test record is extracted to generate the monitoring data template;

[0014] If there is no historical test record of the same system architecture, the monitoring data template containing the pressure test tool index and the hardware resource monitoring index is generated based on the resource type keyword contained in the pressure test file.

[0015] The method described above, optionally, the process of setting the second constraint threshold based on the monitoring reference data obtained from the historical test record comprises:

[0016] The monitoring reference data and the corresponding historical pressure test scene information are obtained, the historical pressure test scene information including a historical number of concurrent users;

[0017] According to the ratio of the number of concurrent users of the current pressure test to the historical number of concurrent users, the index value in the monitoring reference data is scaled to calculate the second constraint threshold.

[0018] The method described above, optionally, the detection of the pressure test monitoring data according to the first constraint threshold and the second constraint threshold to obtain a detection result comprises:

[0019] The pressure test monitoring data is compared with the first constraint threshold and the second constraint threshold;

[0020] If any monitoring index in the pressure test monitoring data exceeds the first constraint threshold or the second constraint threshold, it is determined that the detection result indicates that the pressure test is not passed;

[0021] In response to the fact that no monitoring index in the pressure test monitoring data exceeds the first constraint threshold and the second constraint threshold, it is determined that the detection result indicates that the pressure test is passed.

[0022] The method described above, optionally, the method further comprises:

[0023] In response to the detection result indicating that the stress test passes, the stress test monitoring data and its corresponding stress test scene information are stored as new monitoring benchmark data.

[0024] A stress test device of a business system comprises:

[0025] An acquisition unit is configured to acquire a system architecture diagram of a user-uploaded business system to be tested in response to a stress test instruction.

[0026] A first generation unit is configured to generate a stress test file according to the system architecture diagram.

[0027] A second generation unit is configured to generate a monitoring data template corresponding to the stress test file and set a first constraint threshold and a second constraint threshold for the monitoring data template. The first constraint threshold comprises an alarm level threshold. The second constraint threshold is set based on monitoring benchmark data obtained from historical test records or based on a resource index threshold configured by a user.

[0028] An acquisition unit is configured to acquire stress test monitoring data of the business system under stress test.

[0029] A detection unit is configured to detect the stress test monitoring data according to the first constraint threshold and the second constraint threshold to obtain a detection result of the stress test monitoring data, which is used to indicate whether the stress test passes.

[0030] The device described above can optionally comprise:

[0031] A retrieval subunit is configured to retrieve whether there is a historical test record of the same system architecture based on the stress test file.

[0032] A first execution subunit is configured to extract monitoring benchmark data in the historical test record to generate the monitoring data template if there is a historical test record of the same system architecture.

[0033] A second execution subunit is configured to generate the monitoring data template containing stress test tool indexes and hardware resource monitoring indexes based on resource type keywords contained in the stress test file if there is no historical test record of the same system architecture.

[0034] The device described above can optionally comprise:

[0035] An acquisition subunit is configured to acquire the monitoring benchmark data and its corresponding historical stress test scene information, wherein the historical stress test scene information comprises historical concurrent user numbers.

[0036] The computing subunit is configured to scale the index value in the monitoring benchmark data according to the ratio of the current concurrent user number to the historical concurrent user number, to calculate a second constraint threshold.

[0037] A storage medium including stored instructions, wherein the instructions, when executed, control a device in which the storage medium is located to perform the stress testing method of the business system as described above.

[0038] An electronic device including a memory, and one or more instructions, wherein the one or more instructions are stored in the memory and configured to be executed by one or more processors to perform the stress testing method of the business system as described above.

[0039] The application provides a stress testing method, device, storage medium and electronic device for a business system. The method comprises: in response to a stress testing instruction, obtaining a system architecture diagram of a business system to be tested uploaded by a user; generating a stress testing file according to the system architecture diagram; generating a monitoring data template corresponding to the stress testing file, and setting a first constraint threshold and a second constraint threshold for the monitoring data template; the first constraint threshold comprises an alarm level threshold; the second constraint threshold is set based on monitoring benchmark data obtained from historical test records or based on a resource index threshold configured by the user; under stress testing of the business system, collecting stress testing monitoring data of the business system; detecting the stress testing monitoring data according to the first constraint threshold and the second constraint threshold to obtain a detection result of the stress testing monitoring data, which is used to indicate whether the stress testing is passed. The method provided by the application can improve the accuracy of the test result. BRIEF DESCRIPTION OF DRAWINGS

[0040] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the drawings needed in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only embodiments of the present application, and those skilled in the art can obtain other drawings according to the provided drawings without creative labor.

[0041] Figure 1 A method flowchart of a stress testing method of a business system provided by the present application;

[0042] Figure 2 A flowchart of a test process provided by the present application;

[0043] Figure 3 A structural schematic diagram of a stress testing device of a business system provided by the present application;

[0044] Figure 4 Fig. 1 is a structural schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0045] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative effort fall within the protection scope of the present application.

[0046] In the present application, the term "comprising" or "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of another identical element in the process, method, article or device including the element.

[0047] The embodiments of the present application provide a stress test method of a business system, which can be applied to an electronic device and the like, and a method flowchart of the method is shown in Fig. 1, which specifically includes the following steps. Figure 1

[0048] S101: In response to a stress test instruction, a system architecture diagram of a business system to be tested uploaded by a user is acquired.

[0049] In the present embodiment, the triggering of the stress test instruction can be but is not limited to being realized by a user through a button on an operation interface or receiving an automatic test task from a dispatching system.

[0050] Optionally, the system architecture diagram is a schematic diagram describing the constituent elements of the business system and the connection relationship thereof, and an exemplary file format thereof can be a common format such as PNG, JPEG or VISIO.

[0051] In actual implementation, the electronic device can automatically recognize and analyze the uploaded architecture diagram by calling a pre-written script program, and the recognized targets include but are not limited to a user PC, a load balancing device, various servers, database instances and network switching devices and the like hardware entities.

[0052] Optionally, the business system can be a bank internal system.

[0053] S102: A stress test file is generated according to the system architecture diagram.

[0054] ​In the embodiment, a system architecture diagram is identified, the identified system components and their connection relationship are arranged, and a structured data file is output, which can be used as the pressure test file.

[0055] It is easy to understand that the pressure test file is a full-link pressure test resource list, and the specific implementation form is, for example, a CSV format text file, which records the type, identification and topological connection information of each hardware resource in the link in a row. In addition, the user can perform modification, addition or deletion operation on the file content to ensure that it accurately reflects the actual test environment.

[0056] S103: Generate a monitoring data template corresponding to the pressure test file, and set a first constraint threshold and a second constraint threshold for the monitoring data template; the first constraint threshold includes an alarm level threshold; the second constraint threshold is set based on historical test record monitoring reference data or based on user-configured resource index threshold.

[0057] In the embodiment, the process of generating the monitoring data template has certain intelligent judgment logic. Specifically, the program will search the historical test records in the storage according to the aforementioned pressure test file to determine whether there is monitoring reference data of the same or similar system architecture. If there is, the monitoring index items contained in the historical monitoring reference data are directly extracted to generate the template; if there is not, a set of general monitoring indicators are automatically filled according to the resource type keywords in the pressure test file, such as "server", "database", etc., to generate an initial template.

[0058] The content of the monitoring data template covers two categories of indicators: one is the performance indicators output by the pressure test tool itself, such as TPS (transactions per second), average response time, business request success rate, etc.; the other is the running state indicators of hardware resources. For example, for a server, CPU usage and memory usage need to be monitored; for a database, SQL average execution time and deadlock state need to be monitored; for a network device, total bandwidth and occupied bandwidth need to be monitored.

[0059] When setting the threshold for the monitoring data template, the embodiment divides it into a first constraint threshold and a second constraint threshold. The first constraint threshold mainly corresponds to the alarm level threshold, which can also be understood as a hard constraint, which is a fixed threshold preset according to the upper limit of system resource performance, for example, CPU usage should not exceed 90%, network bandwidth occupation should not exceed 10G.

[0060] The second constraint threshold can be understood as a soft constraint, which is more flexible in setting. There are two main approaches: first, if there are available historical test records, the program will mainly refer to the monitoring benchmark data in the historical test records, and combine the ratio of the current concurrent user number in the pressure test and the historical benchmark concurrent user number to adaptively calculate the threshold range. For example, if the historical benchmark is 10,000 concurrent, and the current test is 5,000 concurrent, the threshold can be set to 50% of the historical benchmark value. Second, if there is no historical data for reference, the system allows users to customize threshold conditions for each resource indicator according to experience or business requirements. These conditions can even include associated logic between resource indicators, such as "when the memory usage is less than 50%, the F5 load balancer does not trigger flow limiting".

[0061] S104: In the case of stress testing the business system, collecting stress testing monitoring data of the business system.

[0062] In this embodiment, when the stress test is formally executed, the automated program collects the actual values of each monitoring indicator in the stress test process by calling various monitoring interfaces (such as API interfaces) provided by the stress test tool itself and the operating system, middleware, database, etc. The real-time monitoring data collected will be automatically and correspondingly filled into the prepared monitoring data template, and finally a full-link stress test monitoring result file containing specific monitoring values will be formed.

[0063] S105: According to the first constraint threshold and the second constraint threshold, detecting the stress testing monitoring data to obtain a detection result of the stress testing monitoring data, the detection result being used to indicate whether the stress testing passes.

[0064] In this embodiment, the actual data in the stress test monitoring result file is compared with the first constraint threshold (hard constraint) and the second constraint threshold (soft constraint) one by one. Specifically, if the actual value of any monitoring indicator exceeds the upper limit of its corresponding first constraint threshold or second constraint threshold, it is determined that the current stress test does not pass, and all abnormal items and their specific deviation values that exceed the threshold are explicitly listed in the detection result. If all monitoring indicators are within the threshold range, it is determined that the test passes.

[0065] In addition, for monitoring indicators whose actual values are significantly lower than the lower limit of the second constraint threshold, the program will further analyze the deviation degree to generate resource redundancy determination or warning prompts, and can accordingly give practical suggestions such as "suggest reducing this resource configuration" or "current resources can support higher concurrency". Finally, all this information will be summarized to form a structured stress test monitoring report, and the conclusion part of the report will clearly indicate whether the current stress test passes the quality requirements of the system.

[0066] The method provided in the application can improve the accuracy of the test result.

[0067] In an embodiment provided in the application, based on the above scheme, the monitoring data template corresponding to the stress test file is generated, comprising:

[0068] Based on the stress test file, it is checked whether there is a historical test record of the same system architecture;

[0069] If there is a historical test record of the same system architecture, the monitoring reference data in the historical test record is extracted to generate the monitoring data template;

[0070] If there is no historical test record of the same system architecture, the monitoring data template containing the stress test tool indicators and the hardware resource monitoring indicators is generated based on the resource type keywords contained in the stress test file.

[0071] In the embodiment, the test case library is used as an organizational process asset, and complete data records of previous stress test tasks are accumulated, and each historical test record at least contains the corresponding system architecture characteristic description, monitoring reference data and test scene parameters.

[0072] Optionally, if it is confirmed through the search that there is a historical test record of the same system architecture, a data extraction operation is performed to obtain the corresponding monitoring reference data from the matched historical record. The monitoring reference data refers to a set of monitoring indicators verified under the system architecture and can be used as a reference standard and its historical value. Subsequently, the monitoring data template required for stress testing is constructed based on the extracted monitoring reference data, and the template will inherit the monitoring indicator items that have been tested in practice in the historical record, such as transaction processing rate, database connection pool usage rate and other monitoring elements specific to the architecture.

[0073] Specifically, the content of the stress test file can be parsed to identify one or more resource type keywords contained therein, such as “application server”, “database node”, “network load balancing device” and the like. Then, according to the identified resource type, the monitoring indicators strongly associated with each resource type are selected from a preset general monitoring indicator rule library. For example, for the “application server” keyword, the central processor utilization rate, memory occupancy rate and other indicators are selected; for the “database node” keyword, the structured query language execution time, cache hit rate and other indicators are selected. Finally, the selected monitoring indicators of various types are aggregated to form a new monitoring data template covering the performance indicators of the stress test tool and the running state indicators of the hardware resources. Although the template is generated for the first time, the indicators have rationality and completeness, and can meet the basic monitoring needs of stress testing of the new architecture.

[0074] In an embodiment provided in the present application, based on the above scheme, optionally, the process of setting the second constraint threshold based on the monitoring benchmark data obtained from the historical test records comprises:

[0075] Obtaining monitoring benchmark data and its corresponding historical stress test scene information, the historical stress test scene information including historical concurrent user number;

[0076] According to the ratio of the concurrent user number of the current stress test to the historical concurrent user number, scaling the index values in the monitoring benchmark data to calculate the second constraint threshold.

[0077] The monitoring benchmark data refers to the actual values of various monitoring indexes recorded in the historical test process for the same or similar system architecture under the condition of test passing, which can be used as the comparison benchmark for subsequent tests. The historical stress test scene information refers to the test environment parameters associated with the monitoring benchmark data, which must include the historical concurrent user number, and the parameter represents the system load scale applied when obtaining the monitoring benchmark data.

[0078] Specifically, the concurrent user number set for the current planned stress test scene needs to be obtained, compared with the historical concurrent user number, and the ratio of the two is calculated. For example, if the historical concurrent user number is 10000 and the concurrent user number set for the current stress test is 5000, the calculated ratio is 50%.

[0079] Then, according to the calculated user number ratio, the scaling operation is performed on the index values in the monitoring benchmark data to finally calculate the second constraint threshold. It is easy to understand that the scaling operation here is to adjust the historical benchmark data linearly or nonlinearly according to the ratio of the current load to the historical load. For example, for the index "CPU usage rate 70%" recorded in the historical monitoring benchmark data, the second constraint threshold calculated under the condition of 50% concurrent user number ratio may be set to 35%, or after considering the nonlinear characteristics of the system, a certain margin is added to obtain an adjusted threshold value of 38%.

[0080] In addition, it should be noted that the threshold calculation method based on scaling has the technical effect of enabling the setting of the second constraint threshold to be adaptive to different pressure load scenarios, avoiding the tedious manual setting of thresholds for different concurrent scales, and since the threshold is derived from historical actual data that has been tested, it has higher rationality and accuracy in reflecting the true performance boundary of the system compared to a fixed threshold set purely based on experience. It is worth noting that in the specific implementation of scaling, simple arithmetic multiplication can be used for linear scaling, or more complex fitting functions can be introduced to deal with the non-linearity of system performance indicators and load, and such modifications should still fall within the spirit of the present embodiment.

[0081] In an embodiment provided in the present application, based on the above-mentioned scheme, the pressure test monitoring data is detected according to the first constraint threshold and the second constraint threshold, and a detection result is obtained, including:

[0082] The pressure test monitoring data is compared with the first constraint threshold and the second constraint threshold;

[0083] If any monitoring indicator in the pressure test monitoring data exceeds the first constraint threshold or the second constraint threshold, it is determined that the detection result indicates that the pressure test fails;

[0084] In response to the fact that none of the monitoring indicators in the pressure test monitoring data exceeds the first constraint threshold and the second constraint threshold, it is determined that the detection result indicates that the pressure test passes.

[0085] The pressure test monitoring data represents the specific values of each monitoring indicator actually collected through the monitoring interface during the pressure test, such as the specific percentage of CPU usage and the specific millisecond of transaction response time. These actually collected values can be compared with the hard alarm limit represented by the first constraint threshold and the adaptive or custom soft limit represented by the second constraint threshold in terms of size or range.

[0086] If it is found in the comparison process that the specific value of any monitoring indicator in the pressure test monitoring data exceeds the allowed range of the first constraint threshold or the second constraint threshold set for it, it is determined that the detection result indicates that the pressure test fails. For example, the actual monitoring value of the database connection number indicator exceeds the upper limit set by the first constraint threshold, or the application server memory usage rate exceeds the second constraint threshold obtained by scaling based on historical benchmark data, which will trigger a failure determination. Here, "exceeds" means that the actual value is greater than the upper limit of the threshold for indicators such as CPU usage, and for indicators such as success rate, it may mean that the actual value is less than the lower limit of the threshold, depending on the performance meaning of the specific indicator.

[0087] In response to all monitoring indicators in the pressure test monitoring data not exceeding their respective first constraint threshold and second constraint threshold, i.e., the actual values of all indicators are within the qualified range defined by the two thresholds, it is determined that the detection result indicates that the current pressure test is passed. It is easy to understand that this determination condition is relatively strict, and all monitored indicators need to meet the requirements. This all-indicator compliance determination method can effectively ensure that the overall stability and reliability of the system in the pressure test meet the expected standards.

[0088] In an embodiment provided in the present application, based on the above scheme, the method further comprises:

[0089] In response to the detection result indicating that the pressure test is passed, the pressure test monitoring data and the corresponding pressure test scene information are stored as new monitoring reference data.

[0090] In the embodiment, the pressure test scene information at least includes the number of concurrent users set in the current test, the pressure test duration, the pressure mode and other key test parameters. Through this updating mechanism, the monitoring reference database can continuously accumulate effective performance data under different test scenes, thereby providing more abundant and accurate reference for subsequent pressure tests on the same or similar system architecture, and realizing the benign circulation and continuous optimization of test organization assets.

[0091] The monitoring reference data refers to a set of historical test data verified and can be used as a reference for subsequent tests. The pressure test monitoring data includes the specific values of various performance indicators actually collected during the pressure test, such as real-time monitoring values of CPU usage, memory occupancy, transaction response time and other indicators. The pressure test scene information is the key parameters describing the execution environment of the pressure test, in addition to the aforementioned number of concurrent users, pressure test duration and pressure mode, it can also include test time, system configuration version and other environmental feature information.

[0092] In specific implementation, the pressure test monitoring data and the corresponding pressure test scene information are associated and packaged, organized into a complete record according to a predefined data structure, and then persistently stored in the monitoring reference database. For example, the database can be implemented by using a relational database or a NoSQL database, etc. to support subsequent efficient retrieval and data reuse.

[0093] In addition, it is easy to understand that through this automatic reference data accumulation mechanism, the system can continuously enrich its historical data assets as the number of tests increases, which not only provides more reference for the threshold self-adaptive calculation in subsequent tests, but also provides a data basis for analyzing the performance evolution trend of the system. Especially when the system architecture is changed, by comparing the monitoring reference data in different periods, the specific impact of the architecture adjustment on the system performance can also be evaluated.

[0094] As Figure 2 shown, the flowchart of a test process provided by an embodiment of the present application includes the following steps:

[0095] Step one: automatically parse the system architecture diagram uploaded by the user through the script program, and complete the production stress test full-link architecture analysis. This step clearly identifies all branch links through which the stress test traffic flows, and generates an intermediate file in CSV format after identification is completed. The user can edit and adjust the identification results, and finally form a full-link stress test resource file. For example, the identification results include system components such as user PC, front-end load balancing device, application server, and database instance.

[0096] Step two: based on the full-link stress test resource file, search the stress test monitoring benchmark database to determine whether there is a test record of the same system architecture. If there is a same architecture record, extract the corresponding monitoring benchmark data to generate a monitoring data template; if there is no same architecture record, automatically generate a monitoring data template according to the device type keywords in the resource file. The template content covers stress test tool indicators (such as TPS, response time, and success rate) and hardware resource monitoring indicators (such as server CPU usage, database SQL time consumption, and network bandwidth). The user can customize and modify the template, and finally form a full-link stress test monitoring indicator file.

[0097] Step three: set double threshold constraints for the monitoring indicators. The hard constraint is a fixed alarm threshold set based on the upper limit of system performance, such as CPU usage not exceeding 90%; the soft constraint uses different setting strategies according to whether there is historical benchmark data: when there is benchmark data, the threshold is adaptively calculated according to the ratio of the current and historical concurrent users; when there is no benchmark data, on the basis of setting the hard constraint, the user can define a soft constraint condition containing resource association logic.

[0098] Step four: after the stress test is implemented, collect the monitoring data through the API interface of the stress test tool and system monitoring, automatically fill it into the monitoring indicator file, and generate a full-link stress test monitoring result file.

[0099] Step five: automatically generate a stress test report by comparing the monitoring result file with the threshold setting. The report not only determines whether the test is passed, but also performs early warning analysis on abnormal indicators, gives configuration suggestions for resource redundancy, and estimates the higher concurrent scale that the system can support.

[0100] Step six: when the test conclusion is passed, store the monitoring results and scenario parameters of this test as new monitoring benchmark data, and enrich the test organization assets.

[0101] Based on the above technical solutions, this application has the following advantages: by automatically identifying the architecture diagram and intelligently generating the monitoring template, it achieves full coverage of the entire link monitoring indicators; by adopting a threshold setting mechanism that combines hard constraints and soft constraints, it not only ensures the system stability requirements but also achieves adaptive adjustment based on historical data; through automated data collection and intelligent analysis, it significantly improves the efficiency of stress testing and provides a reliable basis for system capacity planning and performance optimization.

[0102] and Figure 1 Corresponding to the method described above, this application also provides a stress testing device for a business system, applied to a data processing node in a blockchain, specifically for testing... Figure 1 The specific implementation of the method is shown in the following structural diagram. Figure 3 As shown, it includes:

[0103] The acquisition unit 301 is used to acquire the system architecture diagram of the business system to be tested uploaded by the user in response to the stress test command.

[0104] The first generation unit 302 is used to generate stress test files based on the system architecture diagram;

[0105] The second generation unit 303 is used to generate a monitoring data template corresponding to the stress test file, and set a first constraint threshold and a second constraint threshold for the monitoring data template; the first constraint threshold includes an alarm level threshold; the second constraint threshold is set based on monitoring benchmark data obtained from historical test records, or based on resource indicator thresholds configured by the user.

[0106] The data acquisition unit 304 is used to collect stress test monitoring data of the business system when stress testing is performed on the business system.

[0107] The detection unit 305 is used to detect the stress test monitoring data according to the first constraint threshold and the second constraint threshold, and obtain the detection result of the stress test monitoring data. The detection result is used to indicate whether the stress test has passed.

[0108] In one embodiment provided in this application, based on the above-described solution, optionally, the second generation unit 303 includes:

[0109] The retrieval subunit is used to search for historical test records with the same system architecture based on the stress test file.

[0110] The first execution subunit is used to extract monitoring baseline data from historical test records to generate monitoring data templates if historical test records with the same system architecture exist.

[0111] The second execution subunit is configured to generate a monitoring data template containing a pressure testing tool index and a hardware resource monitoring index based on a resource type keyword contained in the pressure testing file if there is no historical test record of the same system architecture.

[0112] In an embodiment provided by the present application, based on the above scheme, the second generation unit 303 comprises:

[0113] The acquisition subunit is configured to acquire monitoring reference data and corresponding historical pressure testing scene information, wherein the historical pressure testing scene information comprises a historical number of concurrent users.

[0114] The calculation subunit is configured to scale an index value in the monitoring reference data according to a ratio of the number of concurrent users in the current pressure testing to the historical number of concurrent users, to calculate a second constraint threshold.

[0115] The specific principles and execution processes of each unit and module in the pressure testing device of the business system disclosed by the embodiments of the present application are the same as those of the pressure testing method of the business system disclosed by the embodiments of the present application, and can be referred to the corresponding parts in the pressure testing method of the business system provided by the embodiments of the present application, which will not be repeated here.

[0116] The embodiments of the present application further provide a storage medium, which comprises stored instructions, wherein when the instructions are executed, the device where the storage medium is located performs the pressure testing method of the business system.

[0117] The embodiments of the present application further provide an electronic device, a structure diagram of which is shown in Figure 4 The electronic device specifically comprises a memory 401 and one or more than one instruction 402, wherein the one or more than one instruction 402 is stored in the memory 401 and is configured to be executed by one or more than one processor 403 to execute the pressure testing method of the business system.

[0118] It can be understood that before using the technical solutions disclosed by the embodiments of the present application, the type, use range, use scene and the like of the personal information involved in the present application should be informed to the user and the authorization of the user should be obtained through appropriate means according to relevant laws and regulations.

[0119] For example, when responding to the active request of the user, prompt information is sent to the user to explicitly prompt the user that the operation requested to be executed will need to obtain and use the personal information of the user. Thus, the user can voluntarily choose whether to provide the personal information to the electronic device, application program, server or storage medium and the like software or hardware which execute the operation of the technical solutions of the present application according to the prompt information.

[0120] As an optional but non-limiting implementation manner, in response to receiving the active request of the user, the manner of sending the prompt information to the user may be, for example, a pop-up window manner, and the prompt information may be presented in the pop-up window in the form of text. In addition, the pop-up window may also carry a selection control for the user to select "agree" or "disagree" to provide the personal information to the electronic device.

[0121] It can be understood that the above notification and user authorization obtaining process is only illustrative and does not limit the implementation manners of the present application, and other manners meeting the relevant laws and regulations can also be applied to the implementation manners of the present application.

[0122] It can be understood that the data (including but not limited to the data itself, the acquisition or use of the data) involved in the technical solution should comply with the requirements of the relevant laws and regulations and the relevant provisions.

[0123] It should be noted that each embodiment in the specification is described in a progressive manner, and each embodiment focuses on the difference from other embodiments. The same and similar parts between embodiments can be referred to each other. For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts are referred to the part of the method embodiment.

[0124] Finally, it should be noted that in this paper, relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between the entities or operations.

[0125] For the convenience of description, the above device is described as various units divided by functions. Of course, in the implementation of the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0126] From the above description of the embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software and necessary general hardware platforms. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes a plurality of instructions for making a computer device (which can be a personal computer, server, or network device, etc.) execute the methods described in various embodiments or some parts of the embodiments of the present application.

[0127] The above describes in detail the pressure test method of the service system provided by the application. The principles and implementation manners of the application are described by using specific examples. The above description of the examples is only used to help understand the method of the application and its core idea. Meanwhile, for those skilled in the art, according to the idea of the application, the specific implementation manners and application ranges will be changed. In conclusion, the content of the specification should not be understood as a limitation of the application.

Claims

1. A stress testing method for a business system, characterized in that, include: In response to a stress test command, obtain the system architecture diagram of the business system to be tested uploaded by the user; Based on the system architecture diagram, generate stress test files; Generate a monitoring data template corresponding to the stress test file, and set a first constraint threshold and a second constraint threshold for the monitoring data template; the first constraint threshold includes an alarm level threshold; the second constraint threshold is set based on monitoring benchmark data obtained from historical test records, or based on resource indicator thresholds configured by the user. When stress testing is performed on the business system, stress test monitoring data of the business system is collected. The stress test monitoring data is detected based on the first constraint threshold and the second constraint threshold to obtain the detection result of the stress test monitoring data. The detection result is used to indicate whether the stress test has passed.

2. The method according to claim 1, characterized in that, The monitoring data template corresponding to the stress test file is generated as follows: Based on the stress test file, search for historical test records with the same system architecture; If there are historical test records with the same system architecture, extract the monitoring baseline data from the historical test records to generate the monitoring data template; If no historical test records with the same system architecture exist, a monitoring data template containing stress test tool metrics and hardware resource monitoring metrics is generated based on the resource type keywords contained in the stress test file.

3. The method according to claim 1, characterized in that, The process of setting the second constraint threshold based on monitoring benchmark data obtained from historical test records includes: Obtain the monitoring baseline data and its corresponding historical load test scenario information, wherein the historical load test scenario information includes the historical number of concurrent users; The indicator values ​​in the monitoring baseline data are scaled based on the ratio of the current number of concurrent users to the historical number of concurrent users to calculate the second constraint threshold.

4. The method according to claim 1, characterized in that, The step of detecting the stress test monitoring data based on the first constraint threshold and the second constraint threshold to obtain detection results includes: The stress test monitoring data is compared with the first constraint threshold and the second constraint threshold; If any monitoring indicator in the stress test monitoring data exceeds the first constraint threshold or the second constraint threshold, then the detection result indicates that the stress test has failed. If none of the monitoring indicators in the stress test monitoring data exceed the first constraint threshold and the second constraint threshold, then the detection result indicates that the stress test has passed.

5. The method according to claim 1, characterized in that, The method further includes: In response to the detection result indicating that the stress test has passed, the stress test monitoring data and its corresponding stress test scenario information are stored as new monitoring baseline data.

6. A stress testing device for a business system, characterized in that, include: The acquisition unit is used to acquire the system architecture diagram of the business system to be tested uploaded by the user in response to the stress test command; The first generation unit is used to generate stress test files based on the system architecture diagram; The second generation unit is used to generate a monitoring data template corresponding to the stress test file, and to set a first constraint threshold and a second constraint threshold for the monitoring data template; the first constraint threshold includes an alarm level threshold; the second constraint threshold is set based on monitoring benchmark data obtained from historical test records, or based on resource indicator thresholds configured by the user. The data acquisition unit is used to collect stress test monitoring data of the business system when stress testing is performed on the business system. The detection unit is used to detect the stress test monitoring data according to the first constraint threshold and the second constraint threshold, and obtain the detection result of the stress test monitoring data. The detection result is used to indicate whether the stress test has passed.

7. The apparatus according to claim 6, characterized in that, The second generation unit includes: The retrieval subunit is used to retrieve, based on the stress test file, whether there are historical test records with the same system architecture. The first execution subunit is used to extract monitoring benchmark data from the historical test records to generate the monitoring data template if there are historical test records with the same system architecture. The second execution subunit is used to generate a monitoring data template containing stress testing tool indicators and hardware resource monitoring indicators based on the resource type keywords contained in the stress test file if no historical test records with the same system architecture exist.

8. The apparatus according to claim 6, characterized in that, The second generation unit includes: The acquisition subunit is used to acquire the monitoring baseline data and its corresponding historical load test scenario information, wherein the historical load test scenario information includes the historical number of concurrent users. The calculation subunit is used to scale the indicator values ​​in the monitoring benchmark data according to the ratio of the current number of concurrent users in the stress test to the historical number of concurrent users, so as to calculate the second constraint threshold.

9. A storage medium, characterized in that, The storage medium includes storage instructions, wherein, when the instructions are executed, the device where the storage medium is located is controlled to perform the stress test method of the business system as described in any one of claims 1 to 5.

10. An electronic device, characterized in that, It includes a memory, and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors using the stress testing method for the business system as described in any one of claims 1 to 5.

Images