CN117873845A

CN117873845A - Large-scale performance test method, system and equipment in financial security scene

Info

Publication number: CN117873845A
Application number: CN202311682570.9A
Authority: CN
Inventors: 李皈颖; 杨鹏; 张剑; 韩朝勇; 林智发; 姚新; 李奇隆; 叶梦; 张俊; 许丹昊; 赵国强
Original assignee: SHENZHEN SECURITIES INFORMATION CO Ltd; Southwest University of Science and Technology
Current assignee: SHENZHEN SECURITIES INFORMATION CO Ltd; Southwest University of Science and Technology
Priority date: 2023-12-07
Filing date: 2023-12-07
Publication date: 2024-04-12

Abstract

The embodiment of the application provides a large-scale performance test method, system and equipment under a financial security scene, and belongs to the technical field of big data. The method comprises the following steps: acquiring total pressure measurement data to be tested and a service scheduling file corresponding to the total pressure measurement data, wherein the total pressure measurement data and the service scheduling file are obtained based on a financial security scene; dividing total pressure measurement data into a plurality of pressure measurement items according to a preset service request type, and generating a corresponding target pressure measurement script based on the pressure measurement items; determining the execution sequence and the execution concurrency corresponding to each pressure measurement item based on the service scheduling file, and generating a target configuration file corresponding to each pressure measurement item; and distributing a host for each target pressure testing script and the corresponding target configuration file so that the host executes performance testing according to the target pressure testing script and the target configuration file. The method and the device can realize large-scale performance test on data including short link type and long link type in financial security scene.

Description

Large-scale performance test method, system and equipment in financial security scene

Technical Field

The application relates to the technical field of big data, in particular to a method, a system and equipment for testing large-scale performance in a financial security scene.

Background

Financial activities have a critical role in modern economies, which involve a wide range of information, and the community of users conducting financial transactions each day is quite large, thus hastening massive financial data.

Typically, such financial data is run by the associated financial system and, to improve the stability and reliability of the financial system, it is necessary to perform performance testing on it in advance. Typically, a financial system is tested using a test platform that distributes and schedules the required test data to ensure successful execution of the test.

However, the vast amount of financial data has exceeded the upper limit that can be carried by the associated test platform; and, financial data typically includes static data based on HTTP short links and dynamic data based on WebSocket long links, however, the related test platforms do not have the ability to test both data on a large scale at the same time.

Disclosure of Invention

The main purpose of the embodiments of the present application is to provide a method, a system, and a device for testing large-scale performance in a financial security scene, which can realize large-scale performance testing in a financial security scene.

To achieve the above object, a first aspect of an embodiment of the present application provides a method for testing large-scale performance in a financial security scene, the method comprising:

acquiring total pressure measurement data to be tested and a service scheduling file corresponding to the total pressure measurement data, wherein the total pressure measurement data and the service scheduling file are obtained based on a financial security scene;

splitting the total pressure measurement data into a plurality of pressure measurement items according to a preset service request type, and generating a corresponding target pressure measurement script based on the pressure measurement items;

determining the execution sequence and the execution concurrency corresponding to each pressure measurement item based on the service scheduling file, and generating a target configuration file corresponding to each pressure measurement item;

and distributing a cloud host for each target pressure testing script and the corresponding target configuration file so that the cloud host executes performance testing according to the target pressure testing script and the target configuration file.

In some embodiments, the total pressure measurement data is formed based on a plurality of business scenarios under each of the financial security scenarios, the target pressure measurement scenario comprising a target static request scenario and a target dynamic request scenario;

The step of splitting the total pressure measurement data into a plurality of pressure measurement items according to a preset service request type and generating a corresponding target pressure measurement script based on the pressure measurement items comprises the following steps:

if the service request type is short link type, generating a plurality of corresponding short link pressure measurement items according to a plurality of service scenes;

generating a target static request script corresponding to each short link pressure measurement item according to a preset first text format;

if the service request type is a long link type, generating a plurality of corresponding long link pressure measurement items according to a plurality of service scenes;

and generating a target dynamic request script corresponding to each long-chain link pressure measurement item according to a preset second text format.

In some embodiments, the business schedule file includes a sequence file and a scene weight file;

the determining the execution sequence and the execution concurrency corresponding to each pressure measurement item based on the service scheduling file comprises the following steps:

determining the execution sequence corresponding to each pressure measurement item according to the sequence arrangement file;

and determining a plurality of scene weights corresponding to the pressure measurement items according to the scene weight file, and multiplying the preset total concurrence with the scene weights one by one to obtain execution concurrence corresponding to the pressure measurement items.

In some embodiments, the target configuration file includes a target static configuration file and a target dynamic configuration file, the target static request script corresponds to the target static configuration file, and the target dynamic request script corresponds to the target dynamic configuration file; the target static configuration file is provided with a first starting time, and the target dynamic configuration file is provided with a second starting time;

after the cloud host is allocated to each target pressure measurement script and the corresponding target configuration file, the method further comprises:

creating a first thread pool on the cloud host, determining a first batch of tasks from each target static request script and the corresponding target static configuration file according to each first starting time, and executing the first batch of tasks in the first thread pool according to the target static request script and the target static configuration file;

destroying the first thread pool after completing the execution of the first batch of tasks;

creating a second thread pool on the cloud host, and executing the target dynamic request script and the corresponding target dynamic configuration file in the second thread pool according to each second starting time;

And destroying the second thread pool until all the target dynamic scripts and the target dynamic configuration files are executed, or the cloud host receives an execution ending instruction.

In some embodiments, the assigning cloud hosts for each of the target crush scripts and the corresponding target profiles includes:

calculating the test load capacity of each target pressure measurement script according to the total pressure measurement data quantity and each target configuration file, and automatically creating or destroying the cloud host according to the test load capacity;

and acquiring cloud host address information of the cloud hosts after automatic creation or destruction, and automatically completing unified configuration of the running environments of the cloud hosts based on a preset environment configuration file and the cloud host address information.

In some embodiments, after the cloud host is allocated to each target pressure measurement script and the corresponding target configuration file according to the total pressure measurement data, the method further includes:

monitoring the state of the cloud host, and if the cloud host is in an idle state, sending the new target pressure measurement script and the target configuration file to the corresponding cloud host;

If the cloud host is in an execution state, collecting abnormal data generated by the cloud host in the process of executing the target pressure measurement script and the target configuration file;

if the cloud host is in a cleaning state, collecting test data generated after the cloud host finishes executing the target pressure test script and the target configuration file;

and obtaining a test result according to the abnormal data and the test data.

summarizing the test results, wherein the test results comprise test success results and test failure results;

determining the success rate of the performance test according to the number ratio of the test success result to the test result;

determining the test failure rate of the performance test according to the number ratio of the test failure result to the test result;

and obtaining a performance test result according to the test success rate and the test failure rate.

In some embodiments, the method further comprises:

displaying a visual interface, and displaying a test starting component and a performance test interface on the visual interface;

Responding to clicking operation of a test starting component, and displaying a plurality of test result areas on the performance test interface;

responding to the first test result checking operation, and displaying a performance test log in a first test result area;

responding to the second test result checking operation, and displaying the performance test service state in a second test result area;

responding to the third test result checking operation, and displaying a performance test operation result in a third test result area;

and responding to the fourth test result checking operation, and displaying the performance test index result in a fourth test result area.

To achieve the above object, a second aspect of the embodiments of the present application proposes a large-scale performance test system in a financial security scene, the system being divided into a hardware layer, a control layer, a data layer, an analysis layer and a display layer, the system comprising:

the control component is used for determining a cloud host in the hardware layer, configuring a unified operation environment for the cloud host, and acquiring total pressure measurement data to be tested and a service scheduling file corresponding to the total pressure measurement data in the control layer based on the configured cloud host, wherein the total pressure measurement data and the service scheduling file are obtained based on a financial security scene; splitting the total pressure measurement data into a plurality of pressure measurement items according to a preset service request type, and generating a corresponding target pressure measurement script based on the pressure measurement items; determining the execution sequence and the execution concurrency corresponding to each pressure measurement item based on the service scheduling file, and generating a target configuration file corresponding to each pressure measurement item; distributing a cloud host for each target pressure test script and the corresponding target configuration file so that the cloud host executes performance test according to the target pressure test script and the target configuration file and generates test data in the data layer;

The monitoring components are deployed on each cloud host, and when the cloud hosts execute the performance test, abnormal data and the test data generated by the cloud hosts on the data layer are collected;

the application component is used for analyzing the abnormal data and the test data at the analysis layer to obtain a performance test result, and displaying the performance test result in a visual mode at the display layer.

To achieve the above object, a third aspect of the embodiments of the present application provides an electronic device, where the electronic device includes a memory and a processor, where the memory stores a computer program, and the processor executes the computer program to implement the method for testing large-scale performance in a financial security scene according to the first aspect.

The method, the system and the equipment for testing the large-scale performance under the financial security scene are characterized in that firstly, total pressure measurement data to be tested and service scheduling files corresponding to the total pressure measurement data are obtained, wherein the total pressure measurement data and the service scheduling files are obtained under the financial security scene; then, according to the preset service request type, splitting the total pressure measurement data into a plurality of pressure measurement items, and generating a corresponding target pressure measurement script based on the pressure measurement items; then, based on the service scheduling file, determining the execution sequence and the execution concurrency corresponding to each pressure measurement item, and generating a target configuration file corresponding to each pressure measurement item; the service request type comprises two types of short links and long links of financial data, namely, a huge amount of total pressure measurement data can obtain a plurality of target pressure measurement scripts and corresponding target configuration files based on service scheduling files and service request types, and a host is allocated to the target pressure measurement scripts and the corresponding target configuration files obtained after splitting, so that the host can execute performance tests according to the target pressure measurement scripts and the target configuration files, and therefore, the application can realize large-scale performance tests on data including short link types and long link types in financial security scenes.

Drawings

Fig. 1 is a schematic diagram of an application scenario of a large-scale performance test system in a financial security scenario provided in an embodiment of the present application;

FIG. 2 is a schematic diagram of an alternative architecture of a large-scale performance testing system in a financial security scenario provided in an embodiment of the present application;

FIG. 3 is a schematic diagram of an alternative architecture of a large-scale performance testing system in a financial security scenario provided in an embodiment of the present application;

FIG. 4 is an alternative flow chart of a method of large-scale performance testing in a financial security scenario provided by an embodiment of the present application;

FIG. 5 is a flow chart of one implementation of step S102 in FIG. 4;

FIG. 6 is a flow chart of one implementation of step S103 in FIG. 4;

FIG. 7 is a flow chart of one implementation after step S104 in FIG. 4;

FIG. 8 is a flow chart of one implementation of step S104 in FIG. 4;

FIG. 9 is another implementation flowchart after step S104 in FIG. 4;

FIG. 10 is a flowchart of yet another implementation following step S104 in FIG. 4;

FIG. 11 is another alternative flow chart of a method of mass performance testing in a financial security scenario provided by an embodiment of the present application;

FIG. 12 is a schematic diagram of an alternative performance test log of a method for large-scale performance testing in a financial security scenario provided by embodiments of the present application;

FIG. 13 is a schematic diagram of an alternative performance testing service state of a method for large-scale performance testing in a financial security scenario provided in an embodiment of the present application;

FIG. 14 is a schematic diagram of an alternative performance testing service status of a method for large-scale performance testing in a financial security scenario provided by an embodiment of the present application;

FIG. 15 is a schematic diagram of an alternative performance test run of the method for large-scale performance testing in a financial security scenario provided in an embodiment of the present application;

FIG. 16 is a schematic diagram of an alternative performance test index result of the method for large-scale performance testing in a financial security scenario provided in an embodiment of the present application;

FIG. 17 is a schematic diagram of an alternative system functional module of a method for large-scale performance testing in a financial security scenario provided in an embodiment of the present application;

fig. 18 is a schematic hardware structure of an electronic device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the present application.

First, several nouns referred to in this application are parsed:

HTTP (Hyper Text Transfer Protocol), hypertext transfer protocol, is one of the most widely used network protocols on the internet.

WebSocket, a protocol for implementing two-way communication in Internet applications, provides a persistent connection, allows a server to actively send data to a client, and also allows the client to send data to the server, thereby realizing real-time performance and high efficiency.

JSON (JavaScript Object Notation) format, which is a lightweight data interchange format that is based on a subset of the JavaScript language, but also independent of the programming language, JSON format represents structured data in text form that is easy to read and write, typically for data interchange between different systems.

Financial activities have a critical role in modern economies, involving a wide range of information, and a vast population of users conducting financial transactions daily, it being understood that financial scenarios may include securities, stocks, foreign exchange, futures, and other financial derivative markets, and that a vast amount of transaction data, including, for example, stock prices, trade volume, rise and fall, interest rates, exchange rates, etc., is typically generated in each financial scenario. Financial users at home and abroad generate transaction data by acquiring activity data in a financial market at extremely high frequency every day, thereby generating ultra-large-scale data volume.

The method, the system and the equipment for testing the large-scale performance under the financial security scene are characterized in that firstly, total pressure measurement data to be tested and service scheduling files corresponding to the total pressure measurement data are obtained, wherein the total pressure measurement data and the service scheduling files are obtained under the financial security scene; then, according to the preset service request type, splitting the total pressure measurement data into a plurality of pressure measurement items, and generating a corresponding target pressure measurement script based on the pressure measurement items; then, based on the service scheduling file, determining the execution sequence and the execution concurrency corresponding to each pressure measurement item, and generating a target configuration file corresponding to each pressure measurement item; the service request type comprises two types of short links and long links of financial data, that is, a huge amount of total pressure measurement data can obtain a plurality of target pressure measurement scripts and corresponding target configuration files based on service scheduling files and service request types, and cloud hosts are distributed for the target pressure measurement scripts and the corresponding target configuration files obtained after splitting, so that the cloud hosts execute performance tests according to the target pressure measurement scripts and the target configuration files, and therefore large-scale performance tests can be carried out on data including short link types and long link types in financial security scenes.

The large-scale performance test method under the financial security scene can be applied to the terminal, the server side and software running in the terminal or the server side. In some embodiments, the terminal may be a smart phone, tablet, notebook, desktop, etc.; the server side can be configured as an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, and a cloud server for providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, basic cloud computing services such as big data and artificial intelligent platforms and the like; the software may be an application or the like that implements a large-scale performance test method in a financial security scenario, but is not limited to the above form.

The subject application is operational with numerous general purpose or special purpose computer system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

In the various embodiments of the present application, when information related to the identity or characteristics of a user according to user information, user location information, and the like is referred to, permission or consent of the user is obtained first, and the collection, use, processing, and the like of the data complies with relevant laws and regulations and standards. In addition, when the embodiment of the application needs to acquire the sensitive personal information of the user, the independent permission or independent consent of the user is obtained first, and after the independent permission or independent consent of the user is obtained definitely, relevant data such as necessary pressure measurement data, service scheduling files and the like for enabling the embodiment of the application to operate normally are acquired.

The method, system and equipment for testing large-scale performance in a financial security scene provided by the embodiment of the application are specifically described through the following embodiments, and the system for testing large-scale performance in a financial security scene in the embodiment of the application is first described.

As shown in fig. 1, fig. 1 is a schematic view of an application scenario of a large-scale performance test system in a financial security scenario provided in the embodiment of the present application, where the large-scale performance test system in the financial security scenario includes a first terminal device 11 and a server 12, and since testing directly on the financial system may affect real data of a user, a performance test platform (hereinafter may also be simply referred to as a "test platform") may be deployed on the first terminal device 11, and the server 12 includes a large amount of pressure test data to be tested, and by sending the pressure test data to the test platform and distributing and scheduling the pressure test data by the test platform, the large-scale performance test in the financial security scenario is completed. The test platform and the financial system may be located in the same first terminal device 11, or may be located in two different terminal devices, which is not limited herein.

In an example, as shown in fig. 2, fig. 2 is a schematic structural diagram of an optional large-scale performance testing system in a financial security scenario according to an embodiment of the present application, where the testing platform includes three main modules: the device comprises a meat machine flicking module, a pressure scheduling module and an analysis reporting module. The meat machine is a created cloud host, and can be considered as one meat machine in the test platform when a certain condition is met: (1) resources for initiating pressure are owned; (2) the method has certain calculation and storage resources; (3) the performance test tasks in the designated computation can be run. The pressure scheduling module can divide and distribute the data for performance test to each meat machine, and the analysis reporting module can analyze and visually display the performance test result.

In another example, as shown in fig. 3, fig. 3 is another optional structural schematic diagram of a large-scale performance testing system in a financial security scenario provided in an embodiment of the present Application, where the large-scale performance testing system in the financial security scenario is divided into a hardware layer, a control layer, a data layer, an analysis layer and a display layer, and a test platform architecture may be managed by 3 core components, where the 3 components are a control component, a monitor component and an Application component, and specific functions of the control component, the monitor component and the Application component are as follows:

The control component is used for determining a cloud host in the hardware layer, configuring a unified operation environment for the cloud host, and acquiring total pressure measurement data to be tested and service scheduling files corresponding to the total pressure measurement data in the control layer based on the configured cloud host, wherein the total pressure measurement data and the service scheduling files are obtained based on a financial security scene; dividing total pressure measurement data into a plurality of pressure measurement items according to a preset service request type, and generating a corresponding target pressure measurement script based on the pressure measurement items; determining the execution sequence and the execution concurrency corresponding to each pressure measurement item based on the service scheduling file, and generating a target configuration file corresponding to each pressure measurement item; distributing a cloud host for each target pressure test script and corresponding target configuration file, so that the cloud host executes performance test according to the target pressure test script and the target configuration file and generates test data in a data layer;

the monitoring component is deployed on each cloud host, and when the cloud hosts execute performance tests, abnormal data and test data generated by the cloud hosts on the data layer are collected;

In some embodiments, the Controller component is responsible for split scheduling of the pressure measurement data and control of the overall flow, the Application component is responsible for running the pressure measurement data on the meat machine, and the Supervisor component is responsible for collecting monitoring, summarizing, analyzing and displaying the data.

Further, the Controller component is used for controlling a hardware layer, a control layer, a data layer and an analysis layer, wherein the hardware layer comprises basic hardware equipment required by a performance test platform, and can support a cloud virtual machine, a cloud platform and cloud monitoring required by performance test; the control layer is used for controlling the cloud host and the pressure measurement task to be carried out; the data layer is used for collecting execution state information, logs and error reporting and abnormal data; the analysis layer is used for analyzing and counting the pressure measurement result, the error reporting situation and the key index error reporting situation. In addition, the Supervisor component is used for controlling the data layer and the control layer, the Application component is used for controlling the display layer, and the display layer is used for displaying the pressure measurement result statistical chart and the key indexes.

Further, when executing a certain performance test task, the Controller may split the total pressure measurement data to obtain a plurality of target pressure measurement scripts and corresponding target configuration files, then, the Controller may distribute and schedule the target pressure measurement scripts and the corresponding target configuration files to different meat machines, each meat machine is provided with a Supervisor component, the Supervisor can monitor the execution condition of the meat machine test task, and report the monitored execution condition to the Controller, and then, the Controller reports the data to be analyzed and displayed in a summarized manner to Application, and the Application generates an analysis result for display.

The method for testing large-scale performance in the financial security scene in the embodiment of the application can be illustrated by the following embodiment.

As shown in fig. 4, fig. 4 is an optional flowchart of a method for testing large-scale performance in a financial security scenario provided in an embodiment of the present application, where the method in fig. 4 may include, but is not limited to, steps S101 to S104.

Step S101, total pressure measurement data to be tested and service scheduling files corresponding to the total pressure measurement data are obtained, wherein the total pressure measurement data and the service scheduling files are obtained based on financial securities scenes.

In some embodiments, the total pressure measurement data and the business scheduling file are obtained based on a financial security scene, and the purpose of the total pressure measurement data is to simulate real financial data, and the total pressure measurement data can be obtained from a database, wherein the database can be a database set based on a financial system or a third party database; alternatively, the total pressure measurement data may also be obtained by an analog data generator. It will be appreciated that the total pressure measurement data is typically large in quantity, which is typically millions, tens of millions or even billions in quantity.

Further, the service scheduling file includes preset scenes and scene weights corresponding to the scenes, and an exemplary service scheduling file includes three service scene conditions as follows:

(a) Service scheduling scenario one: PC end (10%), mobile end (90%);

(b) Service scheduling scene two: rights 1 (90%), rights 2 (10%);

(c) Service scheduling scene three: new user (10%), old user (90%).

It can be understood that the service scheduling file is used for simulating various service conditions in an actual financial scene, so that an operator can modify the scene weight corresponding to each service scheduling condition and can add or delete a certain service scheduling scene.

Step S102, splitting the total pressure measurement data into a plurality of pressure measurement items according to a preset service request type, and generating a corresponding target pressure measurement script based on the pressure measurement items.

In some embodiments, the service request types corresponding to the financial data include both short link types and long link types, so when the performance test is performed using the pressure test data, the service request types included in the total pressure test data should also include both types.

Further, the financial data often includes two types of data, HTTP and WebSocket, where HTTP is a short link type, webSocket is a long link type, the HTTP short link type is based on a request-response mode, each communication needs to establish a new connection and send a request, after the server returns a response, the connection is closed, and the WebSocket long link type supports two-way communication, once the connection is established, a persistent communication channel can be maintained between the client and the server, and both parties can send messages at any time without reestablishing the connection. That is, HTTP short link type tests are capable of initiating HTTP network requests of extremely high instantaneous pressure, while WebSocket long link type tests are capable of maintaining the continued presence of a large number of long links.

Further, since the data of the short link type and the long link type have large differences in performance and reliability, the total pressure measurement data can be split into a plurality of pressure measurement items according to the service request type. The service request types of each batch of the compression test items are the same, so that the data of the same type can be further divided and tested uniformly later, and the efficiency of large-scale performance test (hereinafter also referred to as performance test) in a financial scene is improved.

Further, after the total pressure measurement data is split into a plurality of pressure measurement items, a corresponding target pressure measurement script can be generated based on the split pressure measurement items, the target pressure measurement script adopts a description mode to describe the pressure measurement items to be executed, and the pressure of the pressure measurement items is not related, so that specific configurations of test logic and test loads can be separated, and the flexibility and maintainability of the test can be improved.

Further, a set of general pressure test script templates can be pre-written, and the templates contain required information such as a data request library, a data processing library, definitions of global variables, requested addresses, requested parameters and the like, so that a target pressure test script can be determined according to a split pressure test project and a preset template, writing and maintenance of the pressure test script are simplified, and test data can be conveniently expanded to cover more test scenes.

Step S103, based on the business scheduling file, determining the execution sequence and the execution concurrency of each pressure measurement item, and generating a target configuration file corresponding to each pressure measurement item.

In some embodiments, the service schedule file further includes a sequence arrangement file, where the sequence arrangement file indicates an execution sequence between the pressure test items. The test scenario includes user login, individual market subscription and plate hotspot display, and the sequential arrangement file records that user login must be performed first to execute individual market subscription and/or plate hotspot display, so after total pressure test data is split into multiple pressure test items, an execution sequence of each pressure test item can be determined according to the service scheduling file, so that performance test tasks can be executed orderly according to the execution sequence.

Further, because the service scheduling file defines the scene of the required test and the corresponding weight thereof, the execution concurrency of each pressure measurement item can be determined according to the total pressure measurement data, wherein the execution concurrency refers to the number of requests which can be processed simultaneously by a certain system in a certain time, and the number is used for measuring the performance and the bearing capacity of the system. And then, according to the execution sequence and the execution concurrency quantity corresponding to each pressure measurement item, forming a corresponding target configuration file, so that when the tested scene and the corresponding scene weight change, the target configuration file corresponding to the target pressure measurement script can be quickly adjusted, and the efficiency of performance test is improved.

Step S104, distributing a cloud host for each target pressure test script and the corresponding target configuration file so that the cloud host executes performance test according to the target pressure test script and the target configuration file.

In some embodiments, multiple virtual cloud hosts can be created in the test platform, and the generated target pressure test script and the corresponding target configuration file are distributed to a certain cloud host, wherein the concurrency indicated by the target configuration file is borne by the virtual cloud host, and the performance test is executed according to the determined execution sequence and the execution concurrency by splitting the large-scale pressure test data, so that the overall concurrency performance is improved, and the pressure test requirements of different scales and complexity are better adapted.

Further, the number of virtual cloud hosts may be determined according to the number of total pressure measurement data, when the number of total pressure measurement data is larger, a plurality of virtual cloud hosts may be created to carry the pressure measurement data, and when the number of total pressure measurement data is smaller, a plurality of virtual cloud hosts may be created to reduce waste of resources, that is, the number of virtual cloud hosts may be set according to actual situations, and embodiments of the present application are not limited specifically.

It can be understood that the data size in the financial scene is large and even exceeds the common online purchase transaction scene, so that, unlike the test platform in other scenes, which only performs the test by increasing the number of virtual cloud hosts, the method and the device divide large total pressure test data into a plurality of small pressure test items, generate a target pressure test script and a target configuration file corresponding to each pressure test item, and distribute and dispatch the target pressure test script and the target configuration file to the cloud host, so that the cloud host performs the performance test according to the target pressure test script and the target configuration file, and thus, the large-scale performance test on the data including the short link type and the long link type in the financial security scene can be realized.

As shown in fig. 5, fig. 5 is a flowchart of one implementation of step S102 in fig. 4, and in some embodiments, step S102 may include steps S201 to S204:

step S201, if the service request type is short link type, generating a plurality of corresponding short link pressure measurement items according to a plurality of service scenes.

In some embodiments, the aggregate pressure measurement data is formed based on a plurality of business scenarios under each financial security scenario, the target pressure measurement scenario comprising a target static request scenario and a target dynamic request scenario. The target pressure measurement script formed according to the HTTP short link type is a target static request script, and the target pressure measurement script formed according to the WebSocket long link type is a target dynamic request script.

Further, in the case of dividing the total pressure measurement data into short link type data and long link type data according to the service request type, further division is required according to the service scenario, and since the measured total pressure measurement data is generated based on a plurality of service scenarios, it is also required to generate a short link item or a long link item according to the service scenario. For example, user login and individual ticker subscription are two common business scenarios, and therefore, user login short link press test items and individual ticker subscription short link press test items may be generated.

Step S202, generating a target static request script corresponding to each short link pressure measurement item according to a preset first text format.

In some embodiments, the first text format may be JSON format, or may be other data exchange formats such as XML (eXtensible Markup Language) format or YAML (YAML Ain't Mark-up Language) format, which are only illustrated by way of preferred example and not limitation.

Illustratively, a short link crush event file may be generated according to Table 1 below:

TABLE 1

Further, a target static request script may include one or more short link crush test item files, where the number of short link crush test item files included in the target static request script is determined by the content to be tested. For example, if the content to be tested is user login, a corresponding target static request script can be generated according to the short link pressure test item file logged by the user according to the "pressure test item name".

In another example, the content to be tested is a user subscription, and then a corresponding target static request script may be generated for the short link compression test project file of the user login, the user subscription, and the user subscription according to the "compression test project name".

Step S203, if the service request type is a long link type, generating a plurality of corresponding long link pressure measurement items according to a plurality of service scenes.

In some embodiments, the same service scenario may include two different service request types, for example, the service scenario of user login, including short link request login and long link request login. In the above steps S201 and S202, a method for generating a target short connection pressure test script based on user login in a short connection type request is described, and similarly, in order to ensure the comprehensiveness of performance test, a corresponding target long connection pressure test script needs to be generated based on user login in a long connection type request.

And step S204, generating a target dynamic request script corresponding to each long-link pressure measurement item according to a preset second text format.

In some embodiments, to ensure uniformity of testing, the first text format and the second text format are generally the same, i.e., when the first text format is JSON format, the second text format is likewise JSON format.

It can be understood that, the method for generating the target dynamic request script is similar to the above step S201 and step S202, and will not be repeated herein, except that the "request type" in the long-chain connection pressure measurement project file needs to be replaced by "WebSocket" to represent that the current pressure measurement project is a long-chain connection type.

As shown in fig. 6, fig. 6 is a flowchart of one implementation of step S103 in fig. 4, and in some embodiments, step S103 may include steps S301 to S302:

step S301, determining the execution sequence corresponding to each pressure measurement item according to the sequence arrangement file.

In some embodiments, the service schedule file includes a sequence file and a scene weight file, and, as described in step S103, the sequence file may be preset, which indicates an execution sequence between the pressure measurement items. It should be noted that, one service scenario may include an execution sequence corresponding to a plurality of different pressure measurement scripts, for example, the execution sequence of the service scenario of "user quotation subscription" in the pressure measurement script a is 2, and the execution sequence of the service scenario in the other pressure measurement script B is 3.

Step S302, determining a plurality of scene weights corresponding to the pressure measurement items according to the scene weight file, and multiplying the preset total concurrence with each scene weight one by one to obtain the execution concurrence corresponding to each pressure measurement item.

In some embodiments, the scene weight file is used to characterize the weight duty ratio under each service scene, and a higher weight duty ratio indicates a higher importance of the corresponding service scene to the overall performance test. For example, if the first business scheduling scenario includes a PC (10%) and a mobile (90%), ninety percent of the measured pressure measurement data comes from the analog mobile, which is also for the actual financial scenario, most users are logged into the mobile device to perform financial activities.

Further, before performance testing is performed, a total concurrency is usually required to be preset, where the total concurrency is used to estimate the data volume generated by the user in each service scenario, and according to the total concurrency and the service scheduling file, a target configuration file corresponding to each pressure testing item can be determined.

For example, assuming that the total concurrency is 500 ten thousand times in a certain performance test, the service schedule file includes the following service scenarios and the scenario weights occupied by each service scenario:

(1) Business scenario and weight of pressure measurement: panoramic image display (20%), individual stock market subscription (40%), plate hotspot display (20%), K line time sharing display (5%), and optional stock display (15%);

(2) Service initiation order and weight: time period 1 (20%), time period 2 (60%), time period 3 (20%);

(3) Simulating user distribution: (1) PC end (10%), mobile end (90%); (2) rights 1 (90%), rights 2 (10%); (3) new user (10%), old user (90%).

Based on the above, a target configuration file corresponding to the target pressure measurement script, namely "the new user PC end authority 1 stock quotation subscription in the time period 3", can be calculated, and the concurrency of the target configuration file is as follows: 500×20% (time period 3 weight) 40% (individual stock subscription scene weight) 10% (new user ratio) 10% (PC end ratio) 90% (rights 1 ratio) =3600, and then the target profile can be generated according to table 2 below:

TABLE 2

/>

As shown in fig. 7, fig. 7 is a flowchart of an implementation after step S104 in fig. 4, and in some embodiments, step S104 may further include steps S401 to S404:

step S401, a first thread pool is created on a cloud host, a first batch of tasks are determined from each target static request script and a corresponding target static configuration file according to each first starting time, and in the first thread pool, the first batch of tasks are executed according to the target static request script and the target static configuration file;

In some embodiments, to ensure performance testing is performed on the cloud host and a corresponding concurrency scale is achieved, it is generally necessary to first create a thread pool on the cloud host and execute each target static request script according to a first start-up time indicated by each target static configuration file. The first start time includes start waiting and start duration in table 2 above, and since the first start times in the target static configuration files are different, the cloud host can sequentially execute each target static request script in a staggered peak manner in the first thread pool according to the target static configuration files, so that the concurrency pressure of the test can be effectively reduced, and the stability of the performance test can be improved.

Further, a first batch of tasks may be first determined from all the target static request scripts and the corresponding target static configuration files, where the first batch of tasks includes a portion of the target static request scripts and the target configuration files. Likewise, a second batch of tasks may again be determined, and after completion of the first batch of tasks in the first thread pool, execution of the second batch of tasks may continue.

Further, the first thread pool can be used to execute only the target static request script, which is created and maintained by the Supervisor component. In this way, since the HTTP short link type request and the WebSocket long link type request are independent, there is no need for a certain service to request HTTP and WebSocket at the same time, so that the supervisors can centralize independent HTTP requests for execution, and centralize independent WebSocket requests for execution, so that performance test tasks can be better controlled and managed.

Step S402, destroying the first thread pool after completing the execution of the first batch of tasks;

in some embodiments, if the second batch of tasks differs from the first start time of the first batch of tasks by a long period, the first thread pool may be destroyed after the first batch of tasks is completed in order to avoid wasting resources.

Step S403, creating a second thread pool on the cloud host, and executing the target dynamic request script and the corresponding target dynamic configuration file in the second thread pool according to each second starting time.

In some embodiments, if the thread pool of the HTTP short link type and the WebSocket long link type is to be maintained at the same time, the thread pool of the WebSocket long link type is idle when testing the data of the HTTP short link type, so that efficient performance test cannot be achieved. Therefore, after a batch of target static request scripts is executed in the first thread pool, if the next batch of data to be tested is of WebSocket long link type, the Supervisor destroys the first thread pool and re-creates a second thread pool on the cloud host for testing the target static request scripts.

Further, similar to testing the target static request scripts in the first thread pool, each target dynamic request script may also be executed in the second thread pool according to a second start-up time indicated by each target dynamic configuration file.

Further, if the data of the next batch of test is still data of the HTTP short link type, the first thread pool may not be destroyed, but the next test task is executed in the first thread pool, so that the resource utilization rate of the thread pool is improved, and resource waste caused by destroying and creating the thread pool with the same property is avoided.

And step S404, destroying the second thread pool until the execution of all the target dynamic scripts and the target dynamic configuration files is completed, or the cloud host receives an execution ending instruction.

In some embodiments, since the target dynamic request script is executed in the second thread pool, and the target dynamic request script is generated based on the long link type WebSocket, which needs to keep a persistent connection, the second thread pool is not destroyed until execution of all the target dynamic script and the target dynamic configuration file is completed, or the cloud host receives an execution end instruction.

As shown in fig. 8, fig. 8 is a flowchart of one implementation of step S104 in fig. 4, and in some embodiments, step S104 may include steps S501 to S502:

step S501, calculating the test load capacity of each target pressure measurement script according to the total pressure measurement data quantity and each target configuration file, and automatically creating or destroying the cloud host according to the test load capacity.

In some embodiments, the test load capacity characterizes the load capacity of the cloud hosts to the test data in a unit time, and since the load bearing capacity of each cloud host is different, after determining each target configuration file, the test load capacity of each target pressure test script can be calculated according to the total pressure test data, and the corresponding cloud host is determined according to the test load capacity, where the cloud hosts include the total number of cloud hosts and the configuration condition of each cloud host.

Further, after the initial cloud host is determined, the cloud host can be dynamically adjusted in a later performance test process, and the cloud hosts with the specified number are quickly created/destroyed to realize optimal cost control. The creation and destruction of the cloud host may be implemented through network facilities such as a cloud virtual machine and/or a virtual private cloud (Virtual Private Cloud, VPC).

Further, network facilities of cloud hosts can be created and destroyed through Terraform management, specifically, terraform realizes purchase, operating system configuration and destruction of batched cloud virtual machines, wherein operating system images of the cloud virtual machines are packaged by project groups, default images are not adopted, the functions are provided by cloud virtual machine products, and therefore, based on the capabilities provided by Terraform, infrastructure management capabilities irrelevant to cloud service providers are completed, and rapid migration can be realized even if new cloud manufacturers are subsequently amplified or cloud platforms under wiring are subjected to. Therefore, the test platform can automatically complete the creation and destruction of the cloud host without manual monitoring, and realizes optimal control of cost while maximizing performance test efficiency.

Step S502, collecting cloud host address information of the cloud hosts after automatic creation or destruction, and automatically completing unified configuration of the running environments of all cloud hosts based on preset environment configuration files and the cloud host address information.

In some embodiments, cloud host address information of each cloud host is collected while the cloud hosts are determined, so that a unified operating environment is configured for each cloud host based on each cloud host address information. Specifically, acquisition of cloud host address information can be accomplished using an onsible, an open-source automation tool that can help to achieve automated IT (Information Technology) management and deployment.

Further, the environment configuration file may be an active Playbook, where active Playbook is a component of active, which is a configuration file for describing an automation task, and active may configure a unified operation environment for each cloud host according to the collected cloud host address information and active Playbook, so as to implement unified management of cloud hosts.

As shown in fig. 9, fig. 9 is another implementation flowchart after step S104 in fig. 4, and in some embodiments, step S104 may include steps S601 to S604 after step S104:

Step S601, monitoring the state of the cloud host, and if the cloud host is in an idle state, transmitting a new target pressure measurement script and a target configuration file to the corresponding cloud host.

In some embodiments, the superiors may monitor an operational state of a corresponding cloud host, where the operational state includes an idle state, a pressure measurement state, and a clean state, where the idle state indicates that the cloud host is not currently executing a test task, and may receive a new test task; the pressure measurement state indicates that the cloud host is currently executing a test task; the cleaning state indicates that the cloud host just executes to complete a certain test task and resource cleaning is being performed. According to the running state monitored by the Supervisor, test tasks can be reasonably distributed to all cloud hosts.

Further, when the cloud host is in an idle state, the Supervisor can report the state to the Controller, and the Controller can send the target pressure test script and the target configuration file to be tested to the cloud host in the idle state, so that the test efficiency of the performance test can be accelerated.

Step S602, if the cloud host is in the execution state, collecting abnormal data generated by the cloud host in the process of executing the target pressure measurement script and the target configuration file.

In some embodiments, when the cloud host is in an execution state, the Supervisor may collect, in real time, abnormal data generated during execution of the test task, and if the collected abnormal data indicates that a serious fault occurs in the current test task, the Supervisor may report the abnormal data to the Controller, and the Controller stops the test task of the current cloud host.

Further, if the exception data collected by the Supervisor is sporadic exception data or other exception data without significant influence, the exception data may be reported to Application, and the Application may complete the operations such as analysis and display of the exception data.

Step S603, if the cloud host is in a cleaning state, collecting test data generated after the cloud host completes execution of the target pressure test script and the target configuration file.

In some embodiments, when the cloud host is in a cleaning state, test data obtained by the cloud host in an operation state is collected first, and then, resources such as log files, left unbroken network connections and the like generated in the operation process are cleaned so as to recycle the resources, so that the local storage is prevented from being exhausted.

Step S604, according to the abnormal data and the test data, obtaining a test result.

In some embodiments, the test results may be obtained based on collected exception data and test data, where the exception data reflects performance of the system in the face of exception conditions and the test data reflects performance and functionality of the test platform in the face of normal operating conditions, and based on the exception data and test data, performance test conditions may be comprehensively evaluated.

As shown in fig. 10, fig. 10 is a further implementation flowchart after step S104 in fig. 4, and in some embodiments, step S104 may include steps S701 to S704 after step S104:

step S701, summarizing test results, wherein the test results comprise test success results and test failure results.

In some embodiments, the Supervisor can aggregate test results and report to Application by the Supervisor, which can analyze the test results, including but not limited to calculating test success rate and test failure rate, to determine the performance stability of the test platform in the face of large scale compression molding test data.

Further, information such as response time, throughput, concurrency, resource utilization rate and the like can be obtained according to the test result, and required information can be determined according to actual conditions, and the application is not particularly limited.

Step S702, determining the success rate of the performance test according to the number ratio of the test success result to the test result.

For example, if the total number of test results is 500 ten thousand and the test success result is 480 ten thousand, the test success rate= (test success result +.total number of test results) ×100% = 96% can be obtained, which means that the ratio of the test success times to the total test times is 96%, and the current test platform has higher stability and reliability.

Step S703, determining the test failure rate of the performance test according to the ratio of the number of test failure results to the number of test results.

For example, if the total number of test results is 500 ten thousand and the test success result is 20 ten thousand, the test failure rate= (test failure result +.total number of test results) ×100% =4% may be obtained, which indicates that the test failure number is 4% of the total test number, and the current test platform has higher stability and reliability, but there is a certain risk, and the data corresponding to the test failure result may be displayed through the visual display interface, so that an operator may take appropriate measures according to the result to improve the stability of the system.

And step S704, obtaining a performance test result according to the test success rate and the test failure rate.

In some embodiments, the test success rate and the test failure rate are important indexes for evaluating performance tests, which reflect whether the test platform can normally operate in such large-scale data in a financial scene, and the stability of the test platform in processing large-scale financial data can be further improved according to the response time, throughput, concurrency, resource utilization and other information under the condition that the test success rate can meet the requirements.

As shown in fig. 11, fig. 11 is another alternative flowchart of a method for testing large-scale performance in a financial security scene provided in an embodiment of the present application, where the method in fig. 11 may include, but is not limited to, steps S801 to S806.

Step S801, displaying a visual interface, and displaying a test starting component and a performance test interface on the visual interface.

In some embodiments, the performance test results may be displayed in a visual display interface of the test platform, so that the performance test conditions may be more intuitively and more efficiently displayed to the operator, and the performance test results may be selected in various manners, such as charts or report sheets, according to actual needs.

Further, the visual interface of the test platform includes a plurality of commonly used components and an interface for displaying results, for example, a test starting component is generally used for starting a new performance test, and a performance test interface is used for displaying the results of the performance test.

Step S802, responding to the clicking operation of the test starting component, and displaying a plurality of test result areas on the performance test interface.

In some embodiments, when the test initiation component is clicked, multiple test result areas are displayed in the performance test interface, each of which can be used to display a different performance test result.

In step S803, in response to the first test result viewing operation, a performance test log is displayed in the first test result area.

In some embodiments, the first test result area may display a performance test log, where the performance test log is a record file generated when performing a performance test of the software system, and is used to track and record various events, errors, warnings, performance indexes, and other information during the execution of the test. As shown in fig. 12, fig. 12 is a schematic diagram of an optional performance test log of the large-scale performance test method in the financial security scenario provided in the embodiment of the present application, where a performance test log may be displayed in a first test result area of the test platform, and specifically includes a test timestamp, a test performance index, monitored test data, and the like.

In step S804, in response to the second test result checking operation, the performance test service status is displayed in the second test result area.

In some embodiments, the second test result area may display a performance test service state, where the performance test service state may monitor a data test condition of the test platform in real time, as shown in fig. 13 and fig. 14, fig. 13 is an optional performance test service state schematic diagram of a large-scale performance test method in a financial security scene provided by the embodiment of the present application, fig. 14 is another optional performance test service state schematic diagram of a large-scale performance test method in a financial security scene provided by the embodiment of the present application, and the performance test service state includes a market place service state and a data stream service state, where the market place service state reflects a current state of a market place where the test platform is connected with a market place where data information is stored, for example, fig. 13 shows a market place connection state, a market place update time, a market place data analysis state, and related data of a market place update time difference value when the test platform is connected with a market place store, and the test platform may also be connected with other market places, where the present application is not limited specifically. In addition, the data flow service status reflects the current status of the data flow processed by the test platform, for example, fig. 14 shows the data flow status, the latest data flow time, the data flow analysis status and the relevant data of the latest analysis time difference value of the data flow processed by the test platform, and likewise, the test platform can visually display the service status of other data flows.

Further, if the test platform is further connected to other functional libraries, such as a natural language processing library for processing text data in a financial scenario, the service status of the relevant library may also be displayed in the second test result area.

Step S805, in response to the third test result viewing operation, displaying the performance test operation result in the third test result area.

In some embodiments, the third test result area may display performance test operation results, as shown in fig. 15, and fig. 15 is a schematic diagram of an optional performance test operation result of the large-scale performance test method in the financial security scenario provided in the embodiment of the present application, where the schematic diagram shows the current number of active connections and the number of active users, which indicates that the current test platform can carry the data volume generated by the currently connected 150 ten thousand users.

Step S806, in response to the fourth test result checking operation, displaying the performance test index result in the fourth test result area.

In some embodiments, the fourth test result area may display performance test index results, as shown in fig. 16, and fig. 16 is an optional performance test index result schematic diagram of the large-scale performance test method in the financial security scenario provided in the embodiment of the present application, which summarizes each performance test index result in the individual market subscription scenario, including the test execution condition, response time, throughput condition, and the like of the tested data. Illustratively, the action of querying individual strands of information in FIG. 15 includes 8000 test Samples (Samples), totaling 0.05% Error (Error), an Average (Average) response time of 2726.15 milliseconds, a minimum (Min) response time of 21 milliseconds, a maximum (Max) response time of 6991 milliseconds, a Median (Median) response time of 2855.5 milliseconds, a 90 th percentile response time of 4384 milliseconds, a 95 th percentile response time of 4618 milliseconds, a 99 th percentile response time of 5058.9 milliseconds, and a Throughput (Throughput) of 146.59 megabits per second.

Further, performance test indexes related to other operation actions in the individual market subscription scene can be summarized, or performance test index results in other financial scenes can be summarized, so that a complete and comprehensive evaluation result of large-scale performance test in the financial scene is formed. It should be noted that, the performance test index may be set according to the actual situation, and the embodiment of the present application is only described in a preferred situation, and is not particularly limited.

As shown in fig. 17, fig. 17 is a schematic diagram of an optional system functional module of a method for testing large-scale performance in a financial security scenario provided in an embodiment of the present application, and the embodiment of the present application further provides a system for testing large-scale performance in a financial security scenario, which can implement the method for testing large-scale performance in a financial security scenario, where the system for testing large-scale performance in a financial security scenario includes:

the acquiring module 901 is configured to acquire total pressure measurement data to be tested and a service scheduling file corresponding to the total pressure measurement data, where the total pressure measurement data and the service scheduling file are both obtained based on a financial security scene;

the target pressure measurement script module 902 is configured to split total pressure measurement data into a plurality of pressure measurement items according to a preset service request type, and generate a corresponding target pressure measurement script based on the pressure measurement items;

The target configuration file module 903 is configured to determine an execution sequence and an execution concurrency amount corresponding to each pressure measurement item based on the service scheduling file, and generate a target configuration file corresponding to each pressure measurement item;

the performance test module 904 is configured to allocate a cloud host to each target pressure test script and a corresponding target configuration file, so that the cloud host performs performance test according to the target pressure test script and the target configuration file.

(a) Service scheduling scenario one: PC end (10%), mobile end (90%);

(b) Service scheduling scene two: rights 1 (90%), rights 2 (10%);

(c) Service scheduling scene three: new user (10%), old user (90%).

Further, since the data of the short link type and the long link type have large differences in performance and reliability, the total pressure measurement data can be split into a plurality of pressure measurement items according to the service request type. The service request types of each batch of compression test items are the same, so that the data of the same type can be further divided and tested uniformly later, and the efficiency of large-scale performance test in a financial scene is improved.

The specific implementation of the large-scale performance test system in the financial security scene is basically the same as the specific embodiment of the large-scale performance test method in the financial security scene, and will not be repeated here. On the premise of meeting the requirements of the embodiment of the application, the large-scale performance test system under the financial security scene can be provided with other functional modules so as to realize the large-scale performance test method under the financial security scene in the embodiment.

The embodiment of the application also provides electronic equipment, which comprises a memory and a processor, wherein the memory stores a computer program, and the processor realizes the large-scale performance test method under the financial security scene when executing the computer program. The electronic equipment can be any intelligent terminal including a tablet personal computer, a vehicle-mounted computer and the like.

As shown in fig. 18, fig. 18 is a schematic hardware structure of an electronic device provided in an embodiment of the present application, where the electronic device includes:

the processor 1001 may be implemented by using a general-purpose CPU (Central Processing Unit ), a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc. to execute related programs to implement the technical solutions provided by the embodiments of the present application;

The Memory 1002 may be implemented in the form of a Read Only Memory (ROM), a static storage device, a dynamic storage device, or a random access Memory (Random Access Memory, RAM). The memory 1002 may store an operating system and other application programs, and when the technical solutions provided in the embodiments of the present application are implemented by software or firmware, relevant program codes are stored in the memory 1002, and the processor 1001 invokes a large-scale performance test method in the financial security scenario for executing the embodiments of the present application;

an input/output interface 1003 for implementing information input and output;

the communication interface 1004 is configured to implement communication interaction between the present device and other devices, and may implement communication in a wired manner (e.g. USB, network cable, etc.), or may implement communication in a wireless manner (e.g. mobile network, WIFI, bluetooth, etc.);

a bus 1005 for transferring information between the various components of the device (e.g., the processor 1001, memory 1002, input/output interface 1003, and communication interface 1004);

wherein the processor 1001, the memory 1002, the input/output interface 1003, and the communication interface 1004 realize communication connection between each other inside the device through the bus 1005.

The embodiment of the application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program realizes the large-scale performance test method in the financial security scene when being executed by a processor.

The memory, as a non-transitory computer readable storage medium, may be used to store non-transitory software programs as well as non-transitory computer executable programs. In addition, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory optionally includes memory remotely located relative to the processor, the remote memory being connectable to the processor through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The embodiments described in the embodiments of the present application are for more clearly describing the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application, and as those skilled in the art can know that, with the evolution of technology and the appearance of new application scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

It will be appreciated by those skilled in the art that the technical solutions shown in the figures do not constitute limitations of the embodiments of the present application, and may include more or fewer steps than shown, or may combine certain steps, or different steps.

The above described apparatus embodiments are merely illustrative, wherein the units illustrated as separate components may or may not be physically separate, i.e. may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

Those of ordinary skill in the art will appreciate that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof.

The terms "first," "second," "third," "fourth," and the like in the description of the present application and in the above-described figures, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It should be understood that in this application, "at least one" means one or more, and "a plurality" means two or more. "and/or" for describing the association relationship of the association object, the representation may have three relationships, for example, "a and/or B" may represent: only a, only B and both a and B are present, wherein a, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b or c may represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b, c may be single or plural.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the above-described division of units is merely a logical function division, and there may be another division manner in actual implementation, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described above as separate components may or may not be physically separate, and components shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including multiple instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of the various embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing a program.

Preferred embodiments of the present application are described above with reference to the accompanying drawings, and thus do not limit the scope of the claims of the embodiments of the present application. Any modifications, equivalent substitutions and improvements made by those skilled in the art without departing from the scope and spirit of the embodiments of the present application shall fall within the scope of the claims of the embodiments of the present application.

Claims

1. A method for large-scale performance testing in a financial security scene, the method comprising:

2. The method of claim 1, wherein the total pressure measurement data is formed based on a plurality of business scenarios in each of the financial security scenarios, the target pressure measurement scenarios including a target static request scenario and a target dynamic request scenario;

3. The method for testing large-scale performance in a financial security scene according to claim 2, wherein the service schedule file includes a sequential arrangement file and a scene weight file;

4. The method for testing large-scale performance in a financial security scene according to claim 3, wherein the target configuration files comprise a target static configuration file and a target dynamic configuration file, the target static request script corresponds to the target static configuration file, and the target dynamic request script corresponds to the target dynamic configuration file; the target static configuration file is provided with a first starting time, and the target dynamic configuration file is provided with a second starting time;

5. The method of claim 4, wherein assigning a cloud host to each of the target pressure test scripts and the corresponding target profiles comprises:

6. The method according to claim 5, further comprising, after said assigning cloud hosts to each of said target crush scripts and corresponding said target profiles according to the amount of said total crush data:

and obtaining a test result according to the abnormal data and the test data.

7. The method according to claim 6, further comprising, after said assigning cloud hosts to each of said target crush scripts and corresponding said target profiles according to the amount of said total crush data:

8. The method of mass performance testing in a financial security scene as recited in claim 7, further comprising:

9. A large-scale performance testing system in a financial security scene, the system being divided into a hardware layer, a control layer, a data layer, an analysis layer and a display layer, the system comprising:

10. An electronic device comprising a memory storing a computer program and a processor that when executing the computer program implements the method of mass performance testing in a financial security scenario of any one of claims 1 to 8.