Service flow testing method and device
By obtaining and replaying the target logs of service requests, the problem of low test coverage of complex traffic scenarios in the prior art is solved, and high accuracy and reliability service traffic testing is achieved, and the performance indicators of back-end services can be monitored.
Patent Information
- Application Number
- CN202510228841.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-27
- Publication Date
- 2025-06-24
AI Technical Summary
When facing complex traffic scenarios, the test coverage rate of simulated user operations is limited, and abnormalities and errors cannot be found, and the accuracy and reliability of the test results are low.
By obtaining the target logs of business requests, use the log playback tool to play back these logs in the test environment, monitoring the test metrics of the backend service to generate test results for business traffic.
It realizes the real simulation of business traffic in the production environment, timely discovers exceptions and errors, ensures the accuracy and reliability of test results, and can monitor the performance indicators of back-end services and identify performance bottlenecks.
Smart Images
Figure CN120196545A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the technical field of software testing, and particularly to a method and apparatus for testing business traffic. Background Art
[0002] During the software development and upgrade process, it is usually necessary to verify the compatibility of new functions and ensure the stability of the software system.
[0003] Traditional testing methods for verifying the compatibility of new functions and ensuring system stability often require a large amount of manual intervention, which is not only time-consuming and laborious, but also difficult to cover all test scenarios.
[0004] With the development of technology, automated testing has gradually become the mainstream. The automated testing methods in the related technologies can use technical means such as software tools and scripts to execute the process of test tasks. These tools and scripts can simulate the operations of users and perform functional tests on the software. However, the automated testing methods in the related technologies have problems such as limited test coverage for simulating user operations, inability to detect anomalies and errors, and low accuracy and reliability of test results when facing complex traffic scenarios. Summary of the Invention
[0005] In view of this, the present disclosure provides a method and apparatus for testing business traffic to solve the problems in the prior art such as limited test coverage for simulating user operations, inability to detect anomalies and errors, and low accuracy and reliability of test results when facing complex traffic scenarios.
[0006] In a first aspect, the present disclosure provides a method for testing business traffic. The method includes: obtaining target logs of business requests, where the business requests include at least one of the following: user management requests, commodity management requests, order management requests, payment management requests, inventory management requests, comment requests, preferential information requests, and system management requests; in the target system architecture built in the test environment, using a log replay tool to replay the target logs of the business requests according to the timestamps of the business requests; monitoring test metrics of backend services in the target system architecture, where the backend services include at least one of the following: user service, commodity service, order service, payment service, inventory service, recommendation system service; generating a test result of the business traffic based on the test metrics of the backend services in the target system architecture.
[0007] The method for testing business traffic in this embodiment can truly simulate the business traffic in the production environment through a log replay tool, can timely detect anomalies and errors in the business traffic, ensure the accuracy and reliability of the test results, and can monitor various performance metrics of the backend services to help identify the performance bottlenecks and potential problems of the business system.
[0008] Second aspect, the present disclosure provides a test apparatus for service traffic, the apparatus comprising: a log acquisition module, configured to acquire target logs of service requests, where the service requests include at least one of the following: user management requests, product management requests, order management requests, payment management requests, inventory management requests, comment requests, promotion information requests, and system management requests; a log replay module, configured to use a log replay tool to replay the target logs of the service requests in a target system architecture built in a test environment according to the timestamps of the service requests; a metric monitoring module, configured to monitor test metrics of backend services in the target system architecture, where the backend services include at least one of the following: user services, product services, order services, payment services, inventory services, recommendation system services; and a result generation module, configured to generate a test result of the service traffic based on the test metrics of the backend services in the target system architecture.
[0009] Third aspect, the present disclosure provides a computer device, comprising: a memory and a processor, which are communicatively connected to each other, where computer instructions are stored in the memory, and the processor executes the computer instructions to execute the test method for service traffic according to the first aspect or any corresponding embodiment thereof.
[0010] Fourth aspect, the present disclosure provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to cause a computer to execute the test method for service traffic according to the first aspect or any corresponding embodiment thereof.
[0011] Fifth aspect, the present disclosure provides a computer program product, comprising computer instructions, and the computer instructions are used to cause a computer to execute the test method for service traffic according to the first aspect or any corresponding embodiment thereof. Description of the Drawings
[0012] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present disclosure. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.
[0013] Figure 1a is a schematic flowchart of the test method for service traffic according to an embodiment of the present disclosure;
[0014] Figure 1b is a schematic diagram of collecting log data of service requests from a production environment according to an embodiment of the present disclosure;
[0015] Figure 1cSchematic diagram of labeling log data of business requests collected from a production environment according to an embodiment of the present disclosure;
[0016] Figure 1d Schematic diagram of replaying target logs according to timestamps according to an embodiment of the present disclosure;
[0017] Figure 2 Schematic diagram of the flowchart of another method for testing business traffic according to an embodiment of the present disclosure;
[0018] Figure 3 Schematic diagram of the flowchart of yet another method for testing business traffic according to an embodiment of the present disclosure;
[0019] Figure 4 Block diagram of the structure of a business traffic testing device according to an embodiment of the present disclosure;
[0020] Figure 5 Schematic diagram of the hardware structure of a computer device according to an embodiment of the present disclosure. Detailed implementation manners
[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present disclosure. Apparently, the described embodiments are some, but not all, of the embodiments of the present disclosure. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present disclosure without creative efforts shall fall within the protection scope of the present disclosure.
[0022] In the present disclosure, a traffic label (TrafficLabel) is a technical means for labeling traffic to perform more detailed traffic control and management. By attaching specific labels to traffic requests between application services, they can be divided into different services or versions. This helps to implement operations such as traffic control, circuit breaker degradation, and flow limiting, thereby improving the stability and availability of the system.
[0023] Log replay is a way of traffic replay. By printing the logs of interfaces in advance in the business code logic, including necessary interface information such as interface request parameters, URLs, and request methods, and then simulating and replaying the collected user request log data in a specified test environment to verify the performance and stability of the backend service, so as to simulate real user request scenarios and discover potential problems.
[0024] Automated testing refers to the process of using technical means such as software tools and scripts to execute test tasks. These software tools and scripts can simulate user operations and perform various types of tests on software, such as functional testing, performance testing, and stability testing. Through automated testing, part of the manual testing work can be replaced, improving test efficiency and accuracy.
[0025] According to an embodiment of the present disclosure, an embodiment of a method for testing service traffic is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.
[0026] In this embodiment, a method for testing service traffic is provided, which can be used in the above computer system, software testing platform, etc. Figure 1a It is a flowchart of a method for testing service traffic according to an embodiment of the present disclosure, as Figure 1a shown, and the process includes the following steps:
[0027] Step S101, obtain the target log of the service request.
[0028] In this embodiment, the service request may include at least one of the following: user management requests (such as registration, login, etc.), commodity management requests (such as commodity search, commodity detail query, etc.), order management requests (such as commodity search, commodity detail query, etc.), payment management requests (such as payment requests, payment callbacks, etc.), inventory management requests (such as inventory query, inventory locking, etc.), comment requests (such as submitting comments, obtaining comments, etc.), preferential information requests (such as obtaining coupons, using coupons, etc.), and system management requests (such as log query, monitoring data acquisition, etc.).
[0029] The above software testing platform can collect log data of service requests from the production environment (see Figure 1b , Figure 1b is a schematic diagram of collecting log data of service requests from the production environment according to an embodiment of the present disclosure). The log data should contain information such as timestamps, request types, request parameters, response statuses, etc. These log data record the actual operations of users and system responses. Subsequently, the above software testing platform can store the log data in a log management system (such as the ELK stack, that is, a log management system such as the ELK Stack or a self-developed log management system), so that it can be collected, cleaned, and filtered through log collection tools (such as existing log collection tools such as Fluentd and Logstash or self-developed log collection tools), removing invalid and redundant data, and tagging according to the uniform resource locator (url) of the request and the returned log data (seeFigure 1c , Figure 1c is a schematic diagram of marking the log data of business requests collected from the production environment according to an embodiment of the present disclosure), so as to classify and organize them for subsequent playback and analysis testing.
[0030] Step S102, in the target system architecture built in the test environment, use a log playback tool to playback the target logs of business requests according to the timestamps of the business requests.
[0031] In this embodiment, the target system architecture built in the test environment can be the same as the business system in the production environment, for example, including components such as the front end, back-end service, database, cache, message queue, etc. Build the same target system architecture in the test environment as in the production environment to ensure that the test environment can truly reflect the production environment. In the target system architecture built in the test environment, a log playback tool (such as existing log playback tools Goreplay, Tcpreplay, or self-developed log playback tools, etc.) can be used to playback the target logs according to the timestamps (as Figure 1d shown, Figure 1d is a schematic diagram of playing back the target logs according to the timestamps according to an embodiment of the present disclosure), simulating real business traffic to ensure the timing and authenticity of the test traffic.
[0032] Step S103, monitor the test metrics of the back-end service in the target system architecture.
[0033] In this embodiment, during the log playback process, the software test platform can use a monitoring tool to monitor the test metrics of the back-end service in real time, and use a distributed tracing tool to analyze the processing link of requests to locate performance bottlenecks. Here, the monitoring tool can be an existing monitoring tool in the prior art (such as Prometheus, Grafana, etc.) or a self-developed monitoring tool. The distributed tracing tool can also be an existing distributed tracing tool in the prior art (such as Jaeger) or a self-developed distributed tracing tool.
[0034] The back-end service can include at least one of the following: user service (including registration, login, user information query, etc.), product service (including product search, product details query, etc.), order service (including order creation, order status query, etc.), payment service (including payment request, payment callback, etc.), inventory service (including inventory query, inventory locking, etc.), recommendation system service (including product recommendation, personalized recommendation, etc.).
[0035] The test metrics can include but are not limited to at least one of the following: response time, throughput, error rate, resource utilization (such as CPU, memory, disk I / O), etc.
[0036] Step S104: Generate a test result of the service traffic based on the test metrics of the backend service in the target system architecture.
[0037] In this embodiment, the software testing platform can generate a test result report of the service traffic according to the monitored test metrics of the backend service in the target system architecture. For example, the test results may include: the performance of the system under high load; metrics such as the response time, throughput, and error rate of each backend service; the bottlenecks of the system and optimization suggestions (such as capacity expansion, code optimization, cache optimization), etc.
[0038] The test method of the service traffic in this embodiment can use a log replay tool to truly simulate the service traffic in the production environment, can timely detect anomalies and errors in the service traffic, ensure the accuracy and reliability of the test results, and can monitor various performance metrics of the backend service to help identify the performance bottlenecks and potential problems of the business system.
[0039] In some alternative embodiments, obtaining the target log of the service request may include: printing the log of the actual traffic in the service request to obtain an initial log; cleaning and filtering the initial log to obtain an intermediate log; tagging the intermediate log according to the URL of the service request and the response of the service request to obtain the target log of the service request.
[0040] In this embodiment, during the actual business operation process, the above software testing platform can use a logging framework (such as Log4j, Logback, etc.) to insert log printing statements in the code to record the detailed information of each service request, including the URL of the request, request parameters, response status code, response time, etc. These log data are usually stored in the original format and are called "initial logs".
[0041] In the initial log, there may be a large amount of redundant information (such as debugging information, irrelevant system logs) or noise data (such as invalid requests, test traffic). The above software testing platform can remove the useless information through cleaning and filtering, and retain the log data related to the service request to obtain an "intermediate log", so as to ensure the quality and relevance of the log data and avoid interference of irrelevant information on the analysis results.
[0042] After that, the above software testing platform can further process the intermediate log, and tag each intermediate log according to the URL and response status of the service request (such as service type, request result), so as to obtain the high-quality target log of the service request that has been cleaned, filtered, and labeled.
[0043] The method for obtaining the target log of a service request in this embodiment removes redundant and noisy data through cleaning, filtering, and annotation, ensuring the accuracy and relevance of the log data, so that the target log has a cleaned business semantics, facilitating refined analysis according to business modules, request types, etc., and further helping developers and operation and maintenance personnel quickly locate problems and improve the maintainability of the business system.
[0044] In some optional embodiments, in the target system architecture built in the test environment, a log replay tool is used to replay the target log of the service request according to the timestamp of the service request, including: building the same target system architecture as the production environment in the test environment, using containerization technology to deploy and configure the backend service in the target system architecture; deploying the production data exported from the production environment to the test environment; deploying the log replay tool in the test environment; using the log replay tool to replay the target log of the service request according to the timestamp of the service request.
[0045] In this embodiment, the target system architecture can be the same as that in the production environment, including the front end, backend service, database, cache, and message queue. Containerization technology (such as Docker, Kubernetes) can package the backend service into a container image and deploy independent and portable containers in the test environment, configuring the dependencies of the service (such as database connection, cache configuration) to ensure the normal operation of the service, thus achieving a consistent runtime environment in different environments.
[0046] After that, the above software testing platform can use a database export tool (such as mysqldump, pg_dump) to export the production data. Furthermore, a data import tool can be used to import the data into the database of the test environment. Furthermore, sensitive data can be desensitized to ensure data security. This process of exporting some data (such as user data, product data, order data) from the production environment and importing it into the database of the test environment can ensure that the data in the test environment is consistent with that in the production environment to simulate a real business scenario.
[0047] After that, the above software testing platform can deploy a log replay tool (such as Goreplay, Tcpreplay) in the test environment, configure the parameters of the tool (such as replay speed, target address), etc., to ensure that the log replay tool can access the backend service in the test environment.
[0048] After that, the above software testing platform can configure the log replay tool, specify the target log file and timestamp field, and then start the log replay tool to monitor the system performance during the replay. Replay the target log of the service request according to the timestamp of the service request to simulate real business traffic.
[0049] In the target system architecture built in the test environment in this embodiment, by using a log replay tool to replay the target logs of business requests according to the timestamps of the business requests, through the target system architecture, containerization technology, deployment of production data, and replaying the target logs of business requests, the production environment can be realistically simulated, and the accuracy and reliability of test results in the test environment can be improved.
[0050] In some alternative embodiments, monitor the test metrics of the backend services in the target system architecture, including: using a target monitoring tool deployed in the target system architecture to monitor at least one of the following test metrics of the backend services in the target system architecture: the response time of business requests, the number of business requests processed per unit time, the proportion of failed business requests in business requests, the proportion of successful business requests in business requests, resource utilization rate, request queue length, and cache hit rate.
[0051] In this embodiment, in the target system architecture, monitoring tools (such as Prometheus, Grafana, Datadog, etc.) can be deployed to collect and visualize the test metrics of backend services in real time. After selecting a suitable monitoring tool, a monitoring agent (such as Prometheus Exporter) can be configured according to the system architecture to ensure that the monitoring tool can cover all backend services and can collect data in real time.
[0052] The response time of a business request refers to the time from the issuance of a business request to the receipt of a response, which is an important indicator for measuring system performance. The above software test platform can insert a timer into the code to record the processing time of each request, and use a monitoring tool (such as Prometheus) to collect and display the response time data.
[0053] The number of business requests processed per unit time, that is, the throughput, refers to the number of business requests processed by the business system per unit time, reflecting the processing capacity of the business system. The above software test platform can use a monitoring tool to count the number of requests per unit time and set an alarm rule to trigger an alarm when the throughput is lower or higher than expected.
[0054] The proportion of failed business requests in business requests, that is, the error rate, can reflect the stability and reliability of the system. The above software test platform can record the success or failure status of each request in the code, use a monitoring tool to calculate the error rate, and set an alarm rule.
[0055] The proportion of successful business requests in business requests, that is, the success rate, is an important indicator of system reliability. The above software test platform can record the success status of each request in the code, use a monitoring tool to calculate the success rate, and set an alarm rule.
[0056] Resource utilization rate refers to the usage of system resources (such as CPU, memory, disk I / O, network I / O), which reflects the load situation of the system. The above software testing platform can collect resource utilization rate data using monitoring tools (such as Node Exporter) and set alarm rules to trigger alarms when the resource utilization rate is too high.
[0057] The request queue length refers to the number of requests waiting to be processed, which reflects the load situation of the system. The above software testing platform can record the length of the request queue in the code and use monitoring tools to collect and display the queue length data.
[0058] The cache hit rate refers to the proportion of requests hit in the cache system, which reflects the effectiveness of the cache. The above software testing platform can set alarm rules to trigger alarms when the resource utilization rate is too high.
[0059] The test metrics for the backend services in the monitored target system architecture in this embodiment can comprehensively evaluate the performance and stability of the system by deploying monitoring tools in the target system architecture and monitoring test metrics such as the response time, throughput, error rate, success rate, resource utilization rate, request queue length, and cache hit rate of business requests. It also provides real-time system status monitoring, supports quick problem location and solution, optimizes the performance of the business system, and improves the reliability of the business system.
[0060] In this embodiment, another testing method for business traffic is also provided, which can be used for the above computer systems, software testing platforms, etc. Figure 2 It is a flowchart of another testing method for business traffic according to an embodiment of the present disclosure, as Figure 2 shown. The process includes the following steps:
[0061] Step S201, obtain the target log of the business request.
[0062] In this embodiment, the business request may include at least one of the following: user management request, commodity management request, order management request, payment management request, inventory management request, comment request, preferential information request, and system management request. For details, please refer to Figure 1a step S101 of the embodiment shown, which will not be elaborated here.
[0063] Step S202, in the target system architecture built in the test environment, use the log replay tool to replay the target log of the business request according to the timestamp of the business request.
[0064] In this embodiment, the target system architecture for setting up the test environment is usually the same as the business system in the production environment. For example, it includes components such as the front end, back-end services, database, cache, message queue, etc. Setting up the same target system architecture in the test environment as in the production environment can ensure that the test environment can truly reflect the production environment. For details, please refer to Figure 1a Step S102 of the embodiment shown, which will not be elaborated here.
[0065] Step S203, monitor the test metrics of the back-end services in the target system architecture.
[0066] In this embodiment, the back-end services may include at least one of the following: user service, product service, order service, payment service, inventory service, recommendation system service. For details, please refer to Figure 1a Step S103 of the embodiment shown, which will not be elaborated here.
[0067] Step S204, determine the performance bottleneck based on the test metrics of the back-end services in the target system architecture.
[0068] In this embodiment, the above software testing platform can identify the performance bottlenecks in the business system by analyzing the monitored test metrics (such as response time, throughput, error rate, resource utilization, etc.). For example, the performance bottlenecks may include but are not limited to at least one of the following: CPU bottleneck: The CPU usage is too high, resulting in request processing delays. Memory bottleneck: Insufficient memory, resulting in frequent memory recycling or swap partition usage. Input / Output (I / O) bottleneck: High disk I / O or network I / O, resulting in slow request processing. Database bottleneck: Poor database query performance, resulting in increased response time, etc.
[0069] Furthermore, the above software testing platform can use monitoring tools (such as Prometheus, Grafana) to visualize the test metrics, help identify outliers, and combine historical data and baseline data to determine which metrics are outside the normal range.
[0070] Step S205, use a distributed tracing tool to analyze the processing chain of business requests and locate performance issues in the processing chain.
[0071] In this embodiment, the above software testing platform uses a distributed tracing tool (such as Jaeger, Zipkin) to analyze the processing chain of business requests and identify performance issues in the chain. Specifically, the distributed tracing tool can record the complete processing path of the request in the system, including the various services passed through, the databases and external interfaces called. Furthermore, the above software testing platform can integrate the distributed tracing tool into the code, record the processing chain of the request, and analyze the tracing data to identify slow requests, high-latency services, or error calls in the chain.
[0072] Step S206: Generate the test result of the service traffic based on the performance bottleneck and the performance issues in the processing link.
[0073] In this embodiment, the above software test platform can combine the performance bottleneck and the analysis result of the distributed tracing tool to generate a test result report of the service traffic. The test result report may include: the overall performance of the system, the identified performance bottlenecks and issues, optimization suggestions (such as capacity expansion, code optimization, cache optimization), etc. The above software test platform can use data analysis tools (such as Kibana, Tableau) to generate a visual test result report, and formulate and implement an optimization plan according to the test result report.
[0074] The test method of the service traffic in this embodiment, compared with Figure 1a the test method of the service traffic shown in
[0075] In this embodiment, another test method of the service traffic is further provided, which can be used for the above computer system, software test platform, etc. Figure 3 It is a flowchart of another test method of the service traffic according to an embodiment of the present disclosure, as shown in Figure 3 shown, and the process includes the following steps:
[0076] Step S301: Obtain the target log of the service request.
[0077] In this embodiment, the service request may include at least one of the following: user management request, commodity management request, order management request, payment management request, inventory management request, comment request, preferential information request, and system management request. For details, please refer to Figure 2 step S201 of the embodiment shown in
[0078] Step S302: In the target system architecture built in the test environment, use the log replay tool to replay the target log of the service request according to the timestamp of the service request.
[0079] In this embodiment, the target system architecture built in the test environment is usually the same as the business system in the production environment, and includes components such as the front end, back-end service, database, cache, and message queue. Building the same target system architecture in the test environment as in the production environment can ensure that the test environment can truly reflect the production environment. For details, please refer to Figure 2 step S202 of the embodiment shown in
[0080] Step S303: Monitor the test metrics of the backend services in the target system architecture.
[0081] In this embodiment, the backend services may include at least one of the following: user service, product service, order service, payment service, inventory service, recommendation system service. For details, please refer to Figure 2 Step S203 of the illustrated embodiment, which will not be elaborated here.
[0082] Step S304: Determine the performance bottleneck based on the test metrics of the backend services in the target system architecture.
[0083] In this embodiment, the above software testing platform can identify the performance bottleneck in the business system by analyzing the monitored test metrics (such as response time, throughput, error rate, resource utilization, etc.). For details, please refer to Figure 2 Step S204 of the illustrated embodiment, which will not be elaborated here.
[0084] Step S305: Use a distributed tracing tool to analyze the processing chain of business requests and locate the performance issues in the processing chain.
[0085] In this embodiment, the above software testing platform uses a distributed tracing tool (such as Jaeger, Zipkin) to analyze the processing chain of business requests and identify the performance issues in the chain. Specifically, the distributed tracing tool can record the complete processing path of the request in the system, including the various services passed through, the databases and external interfaces called. For details, please refer to Figure 2 Step S205 of the illustrated embodiment, which will not be elaborated here.
[0086] Step S306: Perform system optimization based on the performance bottleneck and performance issues.
[0087] In this embodiment, system optimization may include at least one of the following: database query optimization (such as optimizing slow queries, adding indexes, reducing unnecessary queries, adjusting database configurations, etc.), cache optimization (such as increasing cache hit rate, optimizing cache policies (such as LRU, TTL), etc.), and code optimization (such as optimizing algorithms, reducing resource consumption, fixing memory leaks).
[0088] The above software testing platform can optimize query performance according to performance bottlenecks and performance issues, in combination with database monitoring tools (such as MySQL Slow Query Log), and optimize cache policies using cache tools (such as Redis and Memcached). For example, according to the update frequency of cached data, as well as the weighted sum of the importance and urgency of the content before and after the update, the cache expiration time TTL is dynamically adjusted (such as when the update frequency is higher than the first threshold, and the weighted sum of the difference in the importance and urgency of the content before and after the data update is higher than the second threshold, the cache expiration time TTL is dynamically increased). When a cache miss occurs, a mutex lock (such as SETNX in Redis) is used to ensure that only one request accesses the database, and other requests wait for the cache to be updated.
[0089] Step S307: Based on the optimized business system, the log replay tool is re-executed to replay the target log of the business request according to the timestamp of the business request, and the test metrics of the backend service in the target system architecture are monitored to obtain the test metrics after optimizing the system.
[0090] In this embodiment, the above software testing platform can re-use the log replay tool in the optimized business system to replay the target log of the business request according to the timestamp, monitor the test metrics of the optimized system (such as response time, throughput, error rate, etc.), and evaluate the optimization effect. The above software testing platform can use a log replay tool (such as Goreplay and Tcpreplay) to replay the log again, and use monitoring tools (such as Prometheus and Grafana) to collect and display test metrics in real time.
[0091] Step S308: Generate the test results of the business traffic based on the performance bottlenecks, performance issues in the processing chain, and the test metrics after optimizing the system.
[0092] In this embodiment, the above software testing platform can combine the performance bottlenecks, performance issues in the processing chain, and the optimized test metrics to generate a detailed test result report. The test results may include: performance comparison before and after optimization, identified performance bottlenecks and issues, effect evaluation of optimization measures, and further optimization suggestions, etc. The above software testing platform can use data analysis tools (such as Kibana and Tableau) to generate a visual test result report, and formulate a further optimization plan based on the test result report.
[0093] Another testing method for business traffic in this embodiment, compared with Figure 2Compared with the test method of service traffic shown, it can, on the basis of comprehensively evaluating the performance and stability of the system, further optimize the system according to performance bottlenecks and performance issues, monitor the test metrics after optimizing the system to verify the optimization effect, and generate a data-driven test result report, improving the performance and reliability of the business system for subsequent continuous improvement and optimization, and reducing the risk of the business system in the production environment.
[0094] In some alternative embodiments, the above method may further include: Step S309, using charts and visualization tools to generate an interactive interface based on the test results of service traffic.
[0095] In this embodiment, in order to more intuitively display the test results of service traffic, charts and visualization tools (such as ECharts, Grafana, etc.) can be used to generate an interactive interface. By generating an interactive interface, the trends of test data can be displayed, the effects of different optimization schemes can be compared, and potential performance issues can be highlighted, so that the development team and decision-makers who can interact can more easily understand and analyze the test results and make more informed decisions.
[0096] In this embodiment, a test device for service traffic is also provided. This device is used to implement the above embodiments and preferred embodiments, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.
[0097] This embodiment provides a test device for service traffic, as Figure 4 shown, including:
[0098] A test device for service traffic, the device includes:
[0099] A log acquisition module 401, configured to acquire the target log of a service request, where the service request includes at least one of the following: user management request, commodity management request, order management request, payment management request, inventory management request, comment request, preferential information request, and system management request;
[0100] A log replay module 402, configured to replay the target log of the service request according to the timestamp of the service request in the target system architecture built in the test environment by using a log replay tool;
[0101] A metric monitoring module 403, configured to monitor the test metrics of the backend service in the target system architecture, where the backend service includes at least one of the following: user service, commodity service, order service, payment service, inventory service, recommendation system service;
[0102] A result generation module 404, configured to generate a test result of service traffic based on test metrics of a backend service in a target system architecture.
[0103] In some alternative embodiments, the log acquisition module 401 includes (not shown in the figure):
[0104] A log printing sub-module, configured to print logs for the actual traffic in a service request to obtain initial logs;
[0105] A log processing sub-module, configured to clean and filter the initial logs to obtain intermediate logs;
[0106] A log tagging sub-module, configured to tag the intermediate logs according to the URL of the service request and the response of the service request to obtain target logs of the service request.
[0107] In some alternative embodiments, the log replay module 402 includes (not shown in the figure):
[0108] An architecture building sub-module, configured to build a target system architecture identical to the production environment in a test environment, where the target system architecture includes a front end, a backend service, a database, a cache, and a message queue;
[0109] A service configuration sub-module, configured to deploy and configure a backend service in the target system architecture using containerization technology;
[0110] A data deployment sub-module, configured to deploy production data exported from the production environment to the test environment;
[0111] A tool deployment sub-module, configured to deploy a log replay tool in the test environment;
[0112] A request replay sub-module, configured to use the log replay tool to replay the target logs of the service request according to the timestamp of the service request.
[0113] In some alternative embodiments, the metric monitoring module 403 is further configured to:
[0114] Adopt a target monitoring tool deployed in the target system architecture to monitor at least one of the following test metrics of the backend service in the target system architecture:
[0115] The response time of a service request, the number of service requests processed per unit time, the proportion of failed service requests in the service requests, the proportion of successful service requests in the service requests, resource utilization rate, request queue length, and cache hit rate.
[0116] In some alternative embodiments, the result generation module 404 includes:
[0117] A bottleneck determination sub-module, configured to determine a performance bottleneck based on test metrics of a backend service in a target system architecture;
[0118] A problem location sub-module, configured to use a distributed tracing tool to analyze a processing link of a service request and locate performance problems in the processing link;
[0119] A result generation sub-module, configured to generate a test result of service traffic based on the performance bottleneck and performance problems in the processing link.
[0120] In some alternative embodiments, the result generation module 404 further includes:
[0121] A system optimization sub-module, configured to perform system optimization according to the performance bottleneck and performance problems;
[0122] A metric optimization sub-module, configured to, based on the optimized system, re-execute using a log replay tool to replay the target logs of service requests according to the timestamps of service requests, and monitor test metrics of the backend service in the target system architecture to obtain test metrics after optimizing the system; and
[0123] The result generation sub-module is further configured to: generate a test result of service traffic based on the performance bottleneck, performance problems in the processing link, and test metrics after optimizing the system.
[0124] In some alternative embodiments, the apparatus further includes:
[0125] An interface generation module 405, configured to use charts and visualization tools to generate an interactive interface based on the test result of service traffic.
[0126] The further function descriptions of the above-mentioned various modules and units are the same as those in the corresponding foregoing embodiments, and will not be elaborated herein.
[0127] A test apparatus for service traffic in this embodiment is presented in the form of functional units. Here, the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and a memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.
[0128] Please refer to Figure 5 , Figure 5FIG. 0 is a schematic structural diagram of a computer device provided by an optional embodiment of the present disclosure. The computer device includes one or more processors 10, a memory 20, and interfaces for connecting various components, including a high-speed interface and a low-speed interface. Each component communicates with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (such as a server array, a set of blade servers, or a multi-processor system).
[0129] The processor 10 can be a central processing unit, a network processor, or a combination thereof. Among them, the processor 10 can further include a hardware chip. The above hardware chip can be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The above programmable logic device can be a complex programmable logic device, a field programmable gate array, a generic array logic, or any combination thereof.
[0130] Among them, the memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.
[0131] The memory 20 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the computer device. In addition, the memory 20 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 can optionally include a memory remotely set relative to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.
[0132] The memory 20 can include a volatile memory, such as a random access memory; the memory can also include a non-volatile memory, such as a flash memory, a hard disk, or a solid-state drive; the memory 20 can also include a combination of the above types of memories.
[0133] Embodiments of the present disclosure also provide a computer-readable storage medium. The methods according to the embodiments of the present disclosure can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented as computer code that is originally stored in a remote storage medium or a non-transitory machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the methods described herein can be processed by such software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code, and when the software or computer code is accessed and executed by the computer, the processor, or the hardware, the methods shown in the above embodiments are implemented.
[0134] A part of the present disclosure can be applied as a computer program product, for example, computer program instructions, which when executed by a computer, can call or provide the methods and / or technical solutions according to the present disclosure through the operation of the computer. Those skilled in the art should be able to understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Herein, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to the computer.
[0135] Although the embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.
Claims
1. A method for testing business traffic, characterized in that: The method comprises: Obtaining a target log of business requests, wherein the business requests include at least one of the following: a user management request, a product management request, an order management request, a payment management request, an inventory management request, a comment request, a discount information request, and a system management request; In the target system architecture built in the test environment, a log playback tool is used to play back the target log of the business request according to the timestamp of the business request; Monitoring the test indicators of the backend services in the target system architecture, wherein the backend services include at least one of the following: user services, product services, order services, payment services, inventory services, and recommendation system services; Generate business traffic test results based on the test indicators of the backend services in the target system architecture.
2. The method according to claim 1, characterized in that The target log of obtaining the service request includes: Print the log of the actual traffic in the business request to obtain the initial log; Cleaning and filtering the initial log to obtain an intermediate log; According to the URL of the service request and the response of the service request, the intermediate log is marked to obtain the target log of the service request.
3. The method according to claim 1, characterized in that In the target system architecture built in the test environment, a log playback tool is used to play back the target log of the business request according to the timestamp of the business request, including: Building a target system architecture that is the same as the production environment in the test environment, the target system architecture including the front-end, back-end services, database, cache, and message queue; Deploy and configure the backend service in the target system architecture using containerization technology; Deploy the production data exported from the production environment to the test environment; Deploy log playback tools in the test environment; The log playback tool is used to playback the target log of the business request according to the timestamp of the business request.
4. The method according to claim 1, characterized in that: The test indicators for monitoring the backend services in the target system architecture include: Using a target monitoring tool deployed in the target system architecture, monitor at least one of the following test indicators of the backend service in the target system architecture: The response time of business requests, the number of business requests processed per unit time, the proportion of failed business requests, the proportion of successful business requests, resource utilization, request queue length and cache hit rate.
5. The method according to claim 1, characterized in that The generating of the test result of the business traffic based on the test index of the backend service in the target system architecture includes: Determine performance bottlenecks based on test metrics of backend services in the target system architecture; Use distributed tracing tools to analyze the processing link of business requests and locate performance problems in the processing link; Based on the performance bottleneck and the performance problem in the processing link, a test result of the service traffic is generated.
6. The method according to claim 5, characterized in that The generating of the test result of the business traffic based on the test index of the backend service in the target system architecture also includes: Perform system optimization according to the performance bottleneck and the performance problem; Based on the optimized system, re-execute the log playback tool, replay the target log of the business request according to the timestamp of the business request, and monitor the test indicators of the backend service in the target system architecture to obtain the test indicators after the optimized system; and The generating of the test result of the business traffic based on the performance bottleneck and the performance problem in the processing link includes: generating the test result of the business traffic based on the performance bottleneck, the performance problem in the processing link and the test index after the system is optimized.
7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: Use charts and visualization tools to generate interactive interfaces based on the test results of the business traffic.
8. A service flow testing device, characterized in that: The device comprises: A log acquisition module, used to acquire a target log of a business request, wherein the business request includes at least one of the following: a user management request, a product management request, an order management request, a payment management request, an inventory management request, a comment request, a discount information request, and a system management request; A log playback module is used to use a log playback tool in the target system architecture built in the test environment to play back the target log of the business request according to the timestamp of the business request; An indicator monitoring module, used to monitor the test indicators of the backend services in the target system architecture, wherein the backend services include at least one of the following: user service, product service, order service, payment service, inventory service, and recommendation system service; The result generation module is used to generate the test results of the business traffic based on the test indicators of the backend services in the target system architecture.
9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the service flow testing method according to any one of claims 1 to 7 by executing the computer instructions.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the service flow testing method according to any one of claims 1 to 7.