A logistics intelligent outbound call full-link performance test method and system

Abstract

This invention discloses a method and system for testing the full-link performance of intelligent outbound calls in logistics, relating to the field of intelligent voice communication testing technology. The method includes: acquiring basic information for intelligent outbound call testing in logistics and generating standardized test sessions; establishing a unique association between logistics waybills, business signatures, and voice calls; constructing a dual-pressure-source collaborative scheduling mechanism to execute real voice calls and full-link tests according to business sequence; collecting link test events to construct a session event chain; implementing voltage boosting, anomaly isolation, and synchronous voltage reduction based on link health status; performing business closed-loop verification and anomaly stratification; calculating full-link performance indicators; and determining stable capacity boundaries and major performance bottlenecks. This invention improves the authenticity, completeness, and reliability of capacity judgment in the performance evaluation of intelligent outbound calls in logistics.

Description

Technical Field

[0001] This invention relates to the field of intelligent voice communication testing technology, and in particular to a method and system for testing the full-link performance of intelligent outbound calls in logistics. Background Technology

[0002] With the development of logistics informatization, intelligent customer service, and artificial intelligence voice technology, intelligent outbound calling systems have been gradually applied to logistics business scenarios such as pickup notifications, delivery reminders, handling of abnormal shipments, and service follow-ups. These systems typically do not consist of a single voice call module, but rather involve multiple processing stages, including outbound task initialization and business authentication, voice communication line call establishment, robot script scheduling, text-to-speech synthesis, user voice or keypad interaction, call recording generation, voice recognition and logistics business intent judgment, business callback, and recording archiving. To ensure the stable operation of intelligent outbound calling systems during peak logistics periods, existing technologies typically conduct performance testing before system launch, version updates, or resource expansion. This testing can include concurrent request testing for business interfaces, simulating a large number of concurrent calls for voice communication lines, and testing the execution of text-to-speech and voice recognition services. Concurrency testing at the interface level utilizes logs, response times, task counts, and error records generated by each server or business module to evaluate the performance of the corresponding module. As the level of system service-orientation increases, the performance testing objects have gradually expanded from single interfaces to multi-module business links that include communication lines and AI voice services. This places higher demands on the realism of the testing scenario, the ability to correlate data across modules, and the evaluation of actual business carrying capacity. However, logistics intelligent outbound calling has obvious business causal timing and cross-system correlation characteristics. Existing performance testing methods that implement separate testing for business interfaces, voice communication, and AI voice services can easily make each test pressure source independent of each other, making it difficult to ensure that the business signature, script template, voice communication line, actual call, call recording, and voice recognition task corresponding to the same logistics waybill are always in the same business context. Summary of the Invention

[0003] In view of the aforementioned existing problems, the present invention is proposed.

[0004] Therefore, this invention provides a method and system for testing the full-link performance of intelligent outbound calls in logistics, which solves the problem that existing technologies cannot guarantee that the business signature, script template, voice communication line, actual call, call recording and voice recognition task corresponding to the same logistics waybill are always in the same business context.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a method for testing the performance of the entire logistics intelligent outbound call chain, comprising, Acquire basic information for intelligent outbound calling testing in logistics, establish a basic test configuration set and determine the full-link test scenario, generate standardized test sessions based on the basic test configuration set, and establish a unique association between logistics waybills, business signatures and voice calls; A dual-pressure-source collaborative scheduling mechanism is established based on standardized test sessions, and test execution is driven by the causal sequence of logistics outbound call business. Real voice call interaction is executed based on the dual-pressure-source collaborative scheduling results, and the corresponding full-link test process is completed according to the test mode. Collect full-link test events corresponding to standardized test sessions, construct session event chains based on global tracking identifiers and logistics waybill numbers, determine the full-link health status based on session event chains, and coordinate the execution of stepped pressure boosting, anomaly isolation, and dual pressure source synchronous pressure reduction according to the health status; The system performs business closed-loop verification of standardized test sessions based on the session event chain, performs hierarchical localization of abnormal test sessions, calculates full-link business performance indicators based on the business closed-loop verification results, and determines stable capacity boundaries and major performance bottlenecks based on different pressure levels.

[0006] As a preferred embodiment of the logistics intelligent outbound call full-link performance testing method of the present invention, the step of obtaining basic information for logistics intelligent outbound call testing, establishing a basic test configuration set, and determining the full-link test scenario specifically includes: Acquire the business interface information, logistics business information, voice communication line information, robot script information, text-to-speech service information, speech recognition service information, and preset test control information of the logistics intelligent outbound call system to be tested, and classify and record them according to the role of each type of information in the logistics intelligent outbound call process; Obtain voice communication line information in the environment to be tested, including the line identifier, operator identifier, calling number resources, called number range, maximum number of concurrent calls allowed for each voice communication line, and media transmission methods supported by the line, and establish voice communication line configuration records according to the line identifier; Obtain robot script information, and create script templates based on the actual use of the logistics intelligent outbound call system for pickup notifications, delivery reminders, abnormal shipment notifications, service follow-ups, or other logistics business scenarios. Set a unique script template identifier for each script template and establish an association between the script template identifier and the corresponding logistics business type. Obtain the service configuration information for the text-to-speech service and the speech recognition service. If there are multiple service instances, set a service instance identifier for each service instance. The test mode is determined according to the actual test purpose, and the test modes are uniformly divided into the full-link test mode, the text-to-speech test mode and the speech recognition test mode. Based on the design capacity of the system under test and the resource availability of the test environment, test control parameters are set, including initial test pressure, pressure increase rate, stable observation time for each pressure stage, maximum allowable test pressure, concurrency limit for each voice communication line, concurrency limit for text-to-speech service, and concurrency limit for speech recognition service. Business interface information, logistics business information, voice communication line information, robot dialogue information, text-to-speech service information, speech recognition service information, test modes, and test control parameters are uniformly organized to form a basic test configuration set.

[0007] As a preferred embodiment of the logistics intelligent outbound call full-link performance testing method of the present invention, the step of generating standardized test sessions based on the test base configuration set and establishing a unique association between logistics waybills, business signatures, and voice calls specifically includes: Read the logistics order to be tested from the test base configuration set, and establish standardized test sessions in sequence according to the principle that one logistics order corresponds to one standardized test session; Based on the business type of the current logistics waybill, the corresponding script template is searched from the script template configuration, and the corresponding script template identifier is written into the standardized test session. Based on the voice communication line configuration corresponding to the test task, the candidate voice communication line is determined for the current standardized test session. At the same time, the current test mode is written into the standardized test session to form the basic session parameters of the current logistics waybill. For the logistics intelligent outbound call system under test that uses time-sensitive business signatures for business authentication, extract the waybill business parameters and common request parameters that need to participate in the business signature based on the current logistics waybill. Sort all the parameters participating in the signature in ascending order according to the dictionary order of the parameter names, and generate ordered signature raw data according to the parameter concatenation rules actually used by the logistics intelligent outbound call system under test. After adding the business key to the signature raw data, perform message digest processing to obtain the time-sensitive business signature corresponding to the current standardized test session. When generating a time-sensitive business signature, both the signature generation time and the signature expiration time are recorded. For standardized test sessions that have already started business initialization but still need to call business callback interfaces or recording archive interfaces later, check the validity of the current time-limited business signature again before executing the corresponding interface call. If the signature is still valid, continue to use the current business signature. If the signature is close to expire or has expired, regenerate a valid business signature based on the original business parameters of the same logistics waybill and write the new signature status back to the current standardized test session. Establish a unified session information record for each standardized test session; Write the generated standardized test sessions into the shared session parameter pool, and set five session states for each standardized test session in the shared session parameter pool: unassigned, locked, executing, pending verification, and completed. When a standardized test session enters the test execution process from an unassigned state, an exclusive lock is performed on the standardized test session, and a session scheduling credential uniquely corresponding to the current standardized test session is generated.

[0008] As a preferred embodiment of the logistics intelligent outbound call full-link performance testing method of the present invention, the step of establishing a dual-pressure source collaborative scheduling mechanism based on standardized test sessions and driving test execution according to the causal sequence of logistics outbound call business specifically includes: After the end-to-end performance testing begins, establish pressure sources for business interfaces and voice calls; Search for standardized test sessions that are in an unallocated state and whose business signatures are still valid from the shared session parameter pool, and select the standardized test session to be executed according to the session release order preset by the test task. After selection, immediately adjust its state to locked. The logistics waybill number, business parameters, and timeliness business signature in the current standardized test session are sent to the business interface pressure source, which then initiates an outbound call initialization request according to the business interface rules of the logistics intelligent outbound call system to be tested. The collaborative scheduling process receives the service authentication result returned by the service interface pressure source and controls the subsequent state of the current standardized test session based on the service authentication result; When the business interface returns a successful authentication result or a successful outbound call task creation result, the current standardized test session is changed from a locked state to an executing state. At the same time, the corresponding session scheduling voucher, logistics waybill number, target phone number, script template identifier and voice communication line identifier are sent to the voice call pressure source. When the business interface returns a signature error, signature invalidation, authentication failure, or business task creation failure, the current standardized test session is not allowed to continue into the voice call stage, and the business interface exception that occurred in the current standardized test session is recorded. After the voice call pressure source obtains a standardized test session that is allowed to be executed, it selects the corresponding line according to the voice communication line identifier recorded therein, and establishes a voice call according to the calling number, target number and call parameters configured for that line. After the call is established, the corresponding call identifier is generated and the call identifier is written back to the current standardized test session. Establish a session execution state chain for each standardized test session, and set it sequentially according to the actual logistics intelligent outbound call business process: waiting for authentication, authentication completed, call allowed, call setup, voice interaction, call ended, voice recognition, business archiving, and closed loop completion. During the collaborative scheduling process, the start time, end time, execution result, and responsible business node of each state transition in the standardized test session are recorded, and the state transition records are saved together with the global tracking identifier and logistics waybill number in the standardized test session. For the three testing modes, after the standardized test session passes the pre-processing stage, the number of sessions entering different processing stages is controlled differently.

[0009] As a preferred embodiment of the logistics intelligent outbound call full-link performance testing method of the present invention, the step of performing real voice call interaction based on the dual-pressure source collaborative scheduling result and completing the corresponding full-link test process according to the test mode specifically includes: Once the standardized test session enters the call-allowed state, the voice call pressure source reads the target contact number, voice communication line identifier, robot identifier, and script template identifier corresponding to the current standardized test session, initiates a voice call to the target test terminal through the selected voice communication line, and records the call process status in sequence. Once the voice communication line returns a valid answer and establishes a media channel, the current standardized test session is changed from the call establishment state to the voice interaction state. Based on the script template identifier in the standardized test session, the corresponding script content is read from the robot script configuration and submitted to the text-to-speech service. The text-to-speech service generates corresponding voice data based on the speech content and sends the generated voice data to the media channel corresponding to the current voice call for playback. When the speech is submitted to the text-to-speech service, the speech submission time is recorded. When the media channel detects the first valid speech, the arrival time of the first sound is recorded. When the complete speech is finished, the playback end time is recorded. The playback end time record is associated with the current standardized test session. User behavior scripts are pre-built for different logistics business types in the test base configuration set; When the robot business process determines that the current call has ended, the voice call pressure source executes the hang-up operation, records the call end time, adjusts the current standardized test session from voice interaction state to call end state, and the logistics intelligent outbound call system under test generates the corresponding audio file of this call according to the normal business processing flow. After detecting the generation of an audio file, obtain the corresponding audio identifier, audio file generation time, recording duration, and recording storage location, and write the audio identifier into the current standardized test session; The recording is submitted to the speech recognition service, and the current standardized test session is adjusted to speech recognition state. The speech recognition service recognizes the user's speech in the recording, generates speech recognition text, and outputs the corresponding logistics business intent result according to the intent classification rules of the logistics business to be tested. The speech recognition task identifier, recognition start time, recognition completion time, recognition text and logistics business intent result are written into the current standardized test session. After speech recognition is completed, the business interface pressure source calls the session end callback interface and the recording archive interface based on the logistics waybill number, business status and business signature that is still valid in the current standardized test session. After completing the business callback and recording archiving, adjust the current standardized test session to the business archive state; For the three test modes, the same set of standardized test sessions, the same set of voice call execution processes, and the same set of subsequent result association mechanisms are used. The release method of the standardized test sessions at different stages is adjusted according to the test objectives.

[0010] As a preferred embodiment of the logistics intelligent outbound call full-link performance testing method of the present invention, the step of collecting full-link test events corresponding to standardized test sessions and constructing a session event chain based on global tracking identifiers and logistics waybill numbers specifically involves: Before the test begins, a unified time calibration is performed on the business interface server, collaborative scheduling node, voice communication node, robot business service node, text-to-speech service node, speech recognition service node, and recording processing node participating in the test. For processing events that occur consecutively within the same execution node, the relative time between events is retained while recording the unified time. The system continuously collects operation records corresponding to outbound call initialization requests, business authentication responses, business callback requests, and recording archiving requests from the business interface pressure source; it also collects operation records corresponding to call initiation, first line response, call connection, media channel establishment, and call end from the voice call pressure source; it collects operation records corresponding to dialogue requests, speech generation start, first sound generation, complete speech generation, and call exceptions from the text-to-speech service; it collects operation records corresponding to recording task submission, task entry into parsing, parsing completion, and output of recognized text and business intent from the speech recognition service; and it collects robot conversation status, recording generation status, and recording archiving status from the robot business service and recording processing system. The records that represent the start, completion, or state change of a test processing action are converted into unified link test events; When generating a link test event, the global tracking identifier and logistics waybill number corresponding to the current event are read from the standardized test session, and both are written into the link test event. When the voice communication line itself cannot directly carry a global tracking identifier, the correspondence between the standardized test session and the call identifier is used to supplement the association; The standard business sequence of various events is determined based on the session execution state chain, and the link test events under the same standardized test session are sorted according to the actual event occurrence time to form a session event chain; Based on the temporal relationship between test events in each link, basic time information that can characterize the test running status is extracted from the session event chain.

[0011] As a preferred embodiment of the logistics intelligent outbound call full-link performance testing method of the present invention, the step of determining the full-link health status based on the session event chain and coordinating the execution of stepped pressure increase, anomaly isolation, and dual pressure source synchronous pressure reduction according to the health status specifically includes: After the test begins, a series of test observation windows are established according to a preset sampling period. At the end of each test observation window, the standardized test sessions that have been executed or are being executed within that test observation window are extracted from the session event chain. Based on standardized test sessions, obtain the real-time running results corresponding to the business interface layer, voice communication layer, text-to-speech processing, speech recognition processing, and robot business processing respectively; The above-mentioned different levels of operation results are compared with the preset allowable conditions in the test basic configuration set to obtain the link health status corresponding to the current test observation window; The collaborative scheduling process forms the current stress level based on the number of standardized test sessions allowed to enter the locked and executing states per unit time. When the current stress level reaches the preset stable observation time, and multiple consecutive test observation windows are determined to be healthy observation windows, the process is allowed to enter the next stress level. When any test observation window shows an anomaly, the anomaly object is determined based on the execution node, voice communication line identifier, or service instance identifier corresponding to the anomaly event in the session event chain. When an anomaly occurs simultaneously in multiple voice communication lines, multiple AI voice service instances, or multiple technical layers of business interfaces, voice communication, and AI voice processing, resulting in continuous performance degradation, the current state is determined to be an end-to-end overload state. Once the entire link is overloaded, stop releasing new standardized test sessions at the current rate from the shared session parameter pool, and reduce the number of standardized test sessions allowed to enter the execution state per unit time. After the pressure reduction is completed, the recovery observation phase begins. During the recovery observation phase, the release rate of the standardized test session after the pressure reduction is maintained, the original pressure is not restored immediately, and the link health status of multiple test observation windows is continuously checked. Once the entire link operation status returns to normal after multiple consecutive test observation windows, the release speed of the standardized test session is gradually increased by a recovery pressure increase amount that is lower than the normal step pressure increase, until the pressure level before the anomaly occurred is restored.

[0012] As a preferred embodiment of the logistics intelligent outbound call full-link performance testing method of the present invention, the step of performing business closed-loop verification of standardized test sessions based on session event chains and hierarchical localization of abnormal test sessions specifically includes: After the standardized test session enters the verification state, all link test events corresponding to the current standardized test session are read from the session event chain. At the same time, the test mode, logistics waybill number, global tracking identifier, voice communication line identifier, script template identifier, call identifier, recording identifier, and voice recognition task identifier of the standardized test session are read, and the corresponding expected event sequence is generated according to the current test mode. After determining the expected event sequence, the actual obtained session event chain is compared item by item with the expected event sequence corresponding to the current test mode, and event integrity verification is performed. After completing the event integrity verification, perform object consistency verification on the current standardized test session; Perform a business semantic consistency check on the speech recognition results; After the event integrity, object consistency, recording integrity and business semantic consistency are all verified, the business closed-loop status is determined for the current standardized test session. For standardized test sessions that meet all necessary event requirements of the current test mode, have consistent business object associations, normal recording results and whose speech recognition and business archiving processes meet the preset business requirements, they are determined to be closed-loop completed sessions and the standardized test sessions are changed from pending verification to completed status. Standardized test sessions that have entered the actual testing process but failed to complete the corresponding business links due to malfunctions in the intelligent outbound calling system for logistics under test are judged as business failure sessions. For standardized test sessions that fail to proceed to subsequent business phases due to the execution of proactive voltage reduction, line isolation, service instance isolation, or test termination control, and whose termination is not caused by the failure of the system under test itself, they are marked as test control terminated sessions. For business failure sessions, fault stratification is performed based on the first occurrence of the exception in the session event chain, the execution node to which the exception event belongs, and the object consistency verification result. When multiple consecutive exceptions occur in a standardized test session, the exception handling stage that appears earliest in the session event chain and can explain subsequent exceptions is taken as the main exception level, and the exceptions that continue to propagate from that exception are recorded as associated exceptions. For each standardized test session that has completed verification, a business closed-loop verification record is generated, which records its logistics waybill number, global tracking identifier, test mode, closed-loop status, event integrity verification result, object consistency verification result, audio recording integrity verification result, business semantic consistency verification result, main exception level and main exception event, and establishes association between the business closed-loop verification record and the corresponding stress level and link health status.

[0013] As a preferred embodiment of the logistics intelligent outbound call end-to-end performance testing method of the present invention, the step of calculating the end-to-end business performance indicators based on the business closed-loop verification results and determining the stable capacity boundary and main performance bottlenecks based on different pressure levels specifically includes: Read all standardized test sessions generated during this test, and divide the standardized test sessions into closed-loop completion sessions, business failure sessions, and test control abort sessions according to the business closed-loop status; Using standardized test sessions as a unified unit of business statistics, the business-level throughput capacity corresponding to the current test task is calculated. After determining the business-level throughput capacity, the processing latency of each business is calculated based on the occurrence time of test events in different links of the session event chain. Based on the closed-loop verification results, statistics are compiled on call connection status, text-to-speech broadcast status, speech recognition processing status, logistics business intent recognition status, recording integrity status, and recording archiving status. After completing the performance index calculations for a single standardized test session and each category of objects, read different stress levels and establish stress stage records in order of stress from low to high. Based on the changing relationship between continuous pressure stages, determine whether each pressure stage belongs to a stable bearing stage, and increase the release speed of the standardized test session according to the step-up pressure method; If any persistent state occurs after entering a new pressure level, the current pressure level will be defined as an unstable bearing stage. The pressure level that meets the stable load-bearing conditions before the unstable load-bearing stage is determined as the stable capacity boundary under the current test conditions, and the main performance bottleneck is located for the first unstable load-bearing stage after the stable capacity boundary. A performance test report on the entire logistics intelligent outbound call chain is generated based on the processing results.

[0014] Secondly, this invention provides a logistics intelligent outbound call end-to-end performance testing system, comprising, The test configuration and session building module is used to obtain basic information for intelligent logistics outbound call testing, establish a basic test configuration set and determine the full-link test scenario, generate standardized test sessions based on the basic test configuration set, and establish a unique association between logistics waybills, business signatures and voice calls. The dual-pressure source coordination and test execution module is used to establish a dual-pressure source coordination scheduling mechanism based on standardized test sessions, drive test execution according to the causal sequence of logistics outbound call business, execute real voice call interaction based on the dual-pressure source coordination scheduling results, and complete the corresponding full-link test process according to the test mode. The link monitoring and pressure control module is used to collect full-link test events corresponding to standardized test sessions, construct session event chains based on global tracking identifiers and logistics waybill numbers, determine the full-link health status based on the session event chains, and coordinate the execution of stepped pressure increase, anomaly isolation, and dual pressure source synchronous pressure reduction according to the health status. The closed-loop verification and performance evaluation module is used to perform business closed-loop verification of standardized test sessions based on the session event chain, and to locate abnormal test sessions in a layered manner. Based on the business closed-loop verification results, it calculates the full-link business performance indicators and determines the stable capacity boundary and main performance bottlenecks based on different pressure levels.

[0015] The beneficial effects of this invention are as follows: It establishes a basic test configuration set to achieve unified configuration of multiple types of test resources; it achieves accurate binding of waybills, signatures, calls, and recordings through standardized test sessions and unique associations; it ensures that test pressure conforms to the real outbound call process through dual-pressure source causal timing scheduling; it improves the authenticity of specialized tests by reusing real voice links to complete three types of tests; it improves the accuracy of latency statistics and anomaly tracing by uniformly associating cross-layer data through session event chains; it avoids local overload contaminating test results by implementing stepped voltage increase, anomaly isolation, and collaborative voltage reduction based on link health status; it distinguishes between business failure and test control termination through business closed-loop verification and locates the anomaly level; and finally, it improves the authenticity, completeness, and reliability of capacity judgment in logistics intelligent outbound call performance evaluation by completing session analysis through pressure stages and closed loops. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart of the logistics intelligent outbound call full-link performance testing method in Example 1.

[0018] Figure 2 This is a structural diagram of the logistics intelligent outbound call full-link performance testing system in Example 1. Detailed Implementation

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0020] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0021] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0022] Example 1, referring to Figure 1 This is the first embodiment of the present invention, which provides a method for testing the performance of the entire logistics intelligent outbound call chain, including the following steps: S1. Obtain basic information for intelligent outbound calling testing in logistics, establish a basic test configuration set and determine the full-link test scenario, generate standardized test sessions based on the basic test configuration set, and establish a unique association between logistics waybills, business signatures and voice calls; Specifically, the system acquires the business interface information, logistics business information, voice communication line information, robot script information, text-to-speech service information, speech recognition service information, and preset test control information of the intelligent logistics outbound calling system to be tested, and classifies and records them according to the role of each type of information in the intelligent logistics outbound calling process. The business interface information includes at least the access address, request method, request parameters, return parameters, authentication rules, and normal response status corresponding to the outbound call task initialization interface, business authentication interface, session end callback interface, and recording archive interface. The logistics business information includes at least the logistics waybill number, outbound call business type, target contact number, and business status corresponding to the current logistics waybill, which is used to determine the actual logistics business object corresponding to each test outbound call. Acquire voice communication line information in the test environment, including the line identifier, operator identifier, calling number resources, called number range, maximum allowed concurrent call count, and media transmission methods supported by each voice communication line. Establish voice communication line configuration records according to the line identifier. By establishing configuration records for different voice communication lines, call pressure and line operation status can be distinguished according to the line during subsequent testing, avoiding the mixed statistics of performance differences caused by different operator lines or different line resources. Acquire robot dialogue information and create dialogue templates based on the actual use of the intelligent logistics outbound call system for pickup notifications, delivery reminders, abnormal shipment notifications, service follow-ups, or other logistics business scenarios. Set a unique dialogue template identifier for each dialogue template and establish a relationship between the dialogue template identifier and the corresponding logistics business type. This will enable the system to automatically determine the dialogue content to be used in the outbound call when generating test sessions based on logistics waybills, and further locate the business scenarios corresponding to different dialogue templates based on the test results. Obtain the service configuration information of the text-to-speech service and the speech recognition service. The text-to-speech service is used to generate actual broadcast speech based on the robot's dialogue. Record its service address, service instance, speech model version and the number of allowed concurrent calls. The speech recognition service is used to recognize the recording formed after the call ends and generate logistics business intent results. Record its service address, service instance, recognition model version and the number of allowed concurrent parsing. In the case of multiple service instances, set service instance identifiers for each service instance so that the running status of different service instances can be independently monitored and anomalies isolated in the future. The test mode is determined according to the actual test purpose, and the test modes are uniformly divided into the full-link test mode, the text-to-speech test mode and the speech recognition test mode. Among them, the full-link test mode is used to fully execute the entire process of logistics business initialization, business authentication, call establishment, script broadcasting, user behavior simulation, call recording generation, recording recognition, business callback, and recording archiving. The text-to-speech dedicated test mode is used to increase the number of test sessions entering the script reading stage while retaining the real call and voice transmission environment, so that the main test pressure is concentrated on the text-to-speech service. The speech recognition-specific test mode is used to increase the recording recognition task by using call recordings generated from real outbound calls or test recording sets formed from real call recordings, so that the main test pressure is focused on the speech recognition service. The three testing modes do not establish independent testing processes for each other. Instead, they use the same logistics business information, voice communication lines, standardized test sessions and result verification mechanisms. The focus of the test is switched only by changing the pressure distribution of different processing stages during the test, so as to ensure that the results of the special test can still reflect the operating status of the real logistics outbound call link. Based on the design capacity of the system under test and the resource availability of the test environment, test control parameters are set, including initial test pressure, pressure increase rate, stable observation time for each pressure stage, maximum allowable test pressure, concurrency limit for each voice communication line, concurrency limit for text-to-speech service, and concurrency limit for speech recognition service. Business interface information, logistics business information, voice communication line information, robot dialogue information, text-to-speech service information, speech recognition service information, test modes, and test control parameters are uniformly organized to form a basic test configuration set.

[0023] Specifically, the test logistics order is read from the test base configuration set, and standardized test sessions are established sequentially according to the principle that one logistics order corresponds to one standardized test session. For each standardized test session, a unique global tracking identifier is generated in the current complete test task, and the global tracking identifier is bound to the current logistics order number. This allows the global tracking identifier to be used to associate the technical execution process inside the test system, and the logistics order number to identify the actual logistics business object. Based on the business type of the current logistics waybill, the corresponding script template is searched from the script template configuration, and the corresponding script template identifier is written into the standardized test session. Based on the voice communication line configuration corresponding to the test task, the candidate voice communication line is determined for the current standardized test session. At the same time, the current test mode is written into the standardized test session to form the basic session parameters of the current logistics waybill. For the logistics intelligent outbound call system under test that uses time-sensitive business signatures for business authentication, extract the waybill business parameters and common request parameters that need to participate in the business signature based on the current logistics waybill. Sort all the parameters participating in the signature in ascending order according to the dictionary order of the parameter names, and generate ordered signature raw data according to the parameter concatenation rules actually used by the logistics intelligent outbound call system under test. After adding the business key to the signature raw data, perform message digest processing to obtain the time-sensitive business signature corresponding to the current standardized test session. The signature generation process adopts the same signature rules as the actual logistics intelligent outbound call system. Its purpose is not to verify the message digest algorithm alone, but to ensure that each logistics waybill has a valid signature that can be properly authenticated by the business system during high concurrency and long-term testing. The reference instructions clearly state that the method of sorting the parameters in ascending order, concatenating the key and generating a time-limited signature is adopted. At the same time, the signature is refreshed periodically according to the validity period of the business signature. When generating time-sensitive business signatures, the signature generation time and signature expiration time are recorded simultaneously. For standardized test sessions that have not yet entered the execution state, when the current time is detected to be within the preset signature refresh time range, the current time information is retrieved again and the time-sensitive business signature is regenerated to avoid a large number of standardized test sessions from experiencing concentrated signature expiration after a long wait. For standardized test sessions that have already started business initialization but still need to call business callback interfaces or recording archive interfaces later, check the validity of the current time-limited business signature again before executing the corresponding interface call. If the signature is still valid, continue to use the current business signature. If the signature is close to expire or has expired, regenerate a valid business signature based on the original business parameters of the same logistics waybill and write the new signature status back to the current standardized test session. Establish a unified session information record for each standardized test session, including at least the global tracking identifier, logistics waybill number, signature generation time, anti-duplicate random parameters, time-sensitive business signature, script template identifier, voice communication line identifier, robot identifier, test mode, call identifier, recording identifier, voice recognition task identifier, and session status. Among them, the call identifier, recording identifier, and voice recognition task identifier are allowed to be empty at the beginning of the standardized test session. After the corresponding objects are actually generated, the corresponding identifiers will be written into the same standardized test session. Write the generated standardized test sessions into the shared session parameter pool, and set five session states for each standardized test session in the shared session parameter pool: unassigned, locked, executing, pending verification, and completed. Unassigned indicates that the standardized test session has been prepared but has not yet been acquired by the test execution process; "Locked" means that the current standardized test session has been assigned to a test task and other concurrent test tasks are not allowed to acquire it again. "Executing" indicates that the corresponding logistics business initialization or voice call has begun. The message "Pending Verification" indicates that the call and subsequent AI voice processing have been completed and are awaiting business integrity verification. "Completed" indicates that the current standardized test session has completed all required test processing and result verification. When a standardized test session enters the test execution process from an unassigned state, an exclusive lock is performed on the standardized test session, and a session scheduling certificate uniquely corresponding to the current standardized test session is generated. The session scheduling certificate is only used to confirm whether the subsequent business interface pressure source and voice call pressure source belong to the same test session, and is not used as a business signature for external use by the logistics business system. Only test execution tasks that have obtained the session scheduling credentials corresponding to the current standardized test session can continue to call the subsequent call process corresponding to that standardized test session. Before the current standardized test session is completed or terminated due to an exception, other test threads are not allowed to repeatedly obtain the same standardized test session.

[0024] S2. Establish a dual-pressure-source collaborative scheduling mechanism based on standardized test sessions, and drive test execution according to the causal sequence of logistics outbound call business. Execute real voice call interaction based on the dual-pressure-source collaborative scheduling results, and complete the corresponding full-link test process according to the test mode. Specifically, after the end-to-end performance test begins, a business interface pressure source and a voice call pressure source are established. The business interface pressure source is used to simulate the logistics business system continuously initiating outbound call task initialization, business authentication, business callback and recording archiving requests under high concurrency conditions. The voice call pressure source is used to simulate the establishment, maintenance and termination of voice calls between a large number of user terminals and the logistics intelligent outbound call robot, and to execute the user responses and media interactions that need to be generated during the call. Instead of reading test parameters from the logistics waybill set separately, the two test stress sources obtain standardized test sessions from the shared session parameter pool through a unified collaborative scheduling process. This avoids inconsistencies in waybill numbers, signatures, script templates, or voice communication lines when the two stress sources read waybill data separately. The system searches for standardized test sessions that are in an unallocated state and whose business signatures are still valid in the shared session parameter pool. It then selects the currently scheduled standardized test session to be executed according to the session release order set in the test task. After selection, it immediately sets the session to locked to prevent other concurrent execution tasks from obtaining the same standardized test session again. The logistics waybill number, business parameters, and timeliness business signature in the current standardized test session are sent to the business interface pressure source, which then initiates an outbound call initialization request according to the business interface rules of the logistics intelligent outbound call system to be tested. The collaborative scheduling process receives the service authentication result returned by the service interface pressure source and controls the subsequent state of the current standardized test session based on the service authentication result; When the business interface returns a successful authentication result or a successful outbound call task creation result, the current standardized test session is changed from a locked state to an executing state. At the same time, the corresponding session scheduling voucher, logistics waybill number, target phone number, script template identifier and voice communication line identifier are sent to the voice call pressure source. When the business interface returns a signature error, signature invalidation, authentication failure, or business task creation failure, the current standardized test session is not allowed to continue into the voice call stage, and the business interface exception that occurred in the current standardized test session is recorded. After the voice call pressure source obtains a standardized test session that is allowed to be executed, it selects the corresponding line according to the voice communication line identifier recorded therein, and establishes a voice call according to the calling number, target number and call parameters configured for that line. After the call is established, a corresponding call identifier is generated and the call identifier is written back to the current standardized test session, so that the current logistics waybill is further directly associated with the actual voice call establishment. Establish a session execution state chain for each standardized test session, and set it sequentially according to the actual logistics intelligent outbound call business process: waiting for authentication, authentication completed, call allowed, call setup, voice interaction, call ended, voice recognition, business archiving, and closed loop completion. The collaborative scheduling process only allows standardized test sessions to transition to the next state in a preset state order; for example, a standardized test session that has not yet entered the authentication completion state cannot directly enter the call allowed state, a standardized test session that has not yet formed a valid call cannot directly enter the voice interaction state, and a standardized test session that has not yet ended the call and formed a recording cannot directly enter the subsequent voice recognition state. When a certain pre-processing stage fails, subsequent testing pressure dependent on that stage will no longer be generated. For example, when business authentication fails, the corresponding voice call pressure will no longer be generated; when voice call establishment fails, the test session will no longer be counted in the normal text-to-speech service pressure; and when no effective recording is formed, the standardized test session will not be directly counted in the normal speech recognition service completion volume. During the collaborative scheduling process, the start time, end time, execution result, and responsible business node of each state transition in the standardized test session are recorded. The state transition records are saved together with the global tracking identifier and logistics waybill number in the standardized test session to provide basic data for the subsequent establishment of full-link test events, calculation of the actual time consumption of each processing stage, and location of specific abnormal stages. For the three test modes, the collaborative scheduling process does not change the above-mentioned standardized test session establishment and business authentication pre-principle. After the standardized test session passes the pre-stage, the number of sessions entering different processing stages is differentiated and controlled. In the full-link test mode, the standardized test session is driven in the order of the complete logistics intelligent outbound call business, going through voice call, script broadcast, user interaction, recording generation, speech recognition and business archiving in sequence; In the text-to-speech test mode, the number of standardized test sessions entering the script reading stage is increased while maintaining effective voice calls; In the speech recognition-specific test mode, while maintaining the correspondence between standardized test sessions and real recordings, the release speed of recording tasks entering the speech recognition processing stage is increased.

[0025] Specifically, once the standardized test session enters the call-allowed state, the voice call pressure source reads the target contact number, voice communication line identifier, robot identifier, and script template identifier corresponding to the current standardized test session, initiates a voice call to the target test terminal through the selected voice communication line, and records the call process status in sequence, including call initiation, line response, ringing, answering, and media channel establishment. Once the voice communication line returns a valid answer and establishes a media channel, the current standardized test session is changed from the call establishment state to the voice interaction state. Based on the script template identifier in the standardized test session, the corresponding script content is read from the robot script configuration and submitted to the text-to-speech service. The text-to-speech service generates corresponding voice data based on the speech content and sends the generated voice data to the media channel corresponding to the current voice call for playback. When the speech is submitted to the text-to-speech service, the speech submission time is recorded. When the media channel detects the first valid speech, the arrival time of the first sound is recorded. When the complete speech is finished, the playback end time is recorded. The playback end time record is associated with the current standardized test session. User behavior scripts are pre-established for different logistics business types in the test basic configuration set. The user behavior scripts are used to specify the user behavior that the test terminal needs to perform after answering the robot's voice. At least the following behaviors are set according to the corresponding logistics business scenario: normal voice response, button confirmation, continuous waiting, repeated questioning, active hanging up, and no response. For example, in the delivery reminder scenario, the system can be set to play a test voice message that confirms receipt, says delivery later, or has a clear logistics business intent after the user listens to the robot's announcement. In the button interaction scenario, the system will send the corresponding button signal to the current call according to the preset waiting time. In the no-response scenario, the system will keep the current call open but will not send any valid user feedback until the robot executes the business rules to re-announce or end the call. For situations requiring simulated user voice responses, a set of standard test voices is pre-established, and corresponding expected text content and expected logistics business intent labels are set for each standard test voice. During the specified interaction phase, the voice call pressure source sends the corresponding standard test voice to the robot business service through the current media channel, so that the system under test can receive user voice according to the real call process, instead of directly submitting text or interface parameters that are out of the call scenario to the voice recognition service. When the robot business process determines that the current call has ended, the voice call pressure source executes the hang-up operation, records the call end time, adjusts the current standardized test session from voice interaction state to call end state, and the logistics intelligent outbound call system under test generates the corresponding audio file of this call according to the normal business processing flow. After detecting the generation of an audio file, obtain the corresponding audio identifier, audio file generation time, recording duration and recording storage location, and write the audio identifier into the current standardized test session, so that the current audio file is directly associated with the logistics waybill, voice call and global tracking identifier; The recording is submitted to the speech recognition service, and the current standardized test session is adjusted to speech recognition state. The speech recognition service recognizes the user's speech in the recording, generates speech recognition text, and outputs the corresponding logistics business intent result according to the intent classification rules of the logistics business to be tested. The speech recognition task identifier, recognition start time, recognition completion time, recognition text and logistics business intent result are written into the current standardized test session. After speech recognition is completed, the business interface pressure source calls the session end callback interface and the recording archive interface based on the logistics waybill number, business status and business signature that is still valid in the current standardized test session. If the original business signature has expired before calling the callback interface or the recording archive interface, a valid business signature corresponding to the current logistics waybill will be regenerated and the corresponding business interface call will be executed. After completing the business callback and recording archiving, the current standardized test session is adjusted to the business archive state, awaiting subsequent steps to perform full-link data association and integrity verification on the standardized test session; For the three test modes, the same set of standardized test sessions, the same set of voice call execution processes, and the same set of subsequent result association mechanisms are used. The release method of the standardized test sessions at different stages is adjusted according to the test objectives. In the full-link testing mode, for each standardized test session, the entire process of business initialization, voice call establishment, text-to-speech broadcast, user behavior simulation, call recording generation, speech recognition, business callback and recording archiving is executed, and test pressure is formed according to the actual number of complete logistics outbound calls completed. In the text-to-speech dedicated test mode, the pre-service authentication, real voice call and media channel establishment process are still retained. Instead of directly and continuously calling the text-to-speech service outside the voice call environment, the session release interval that allows entry into the script playback stage is shortened. This allows more standardized test sessions that have already established real voice calls to initiate script playback simultaneously within a unit of time, so that the test pressure is mainly concentrated on the text-to-speech service. At this time, the voice communication line, script template and actual media playback result corresponding to each text-to-speech task are still recorded to distinguish between the performance degradation of the text-to-speech service itself and the playback abnormality caused by the abnormal voice communication line. In the speech recognition-specific testing mode, the test recording set is established using recordings generated during this test according to the aforementioned real call flow. For each recording in the test recording set, the logistics waybill number, global tracking identifier, recording identifier, and expected logistics business intent corresponding to the original standardized test session are retained. Based on this, speech recognition tasks are submitted in batches according to the preset task release speed. By gradually increasing the number of recordings released per unit time, the actual backlog state of the recording set entering the speech recognition system after a large number of calls during the peak period of logistics outbound calls is simulated.

[0026] S3. Collect full-link test events corresponding to standardized test sessions, and construct a session event chain based on global tracking identifiers and logistics waybill numbers. Determine the full-link health status based on the session event chain, and coordinate the execution of stepped pressure boosting, anomaly isolation, and dual pressure source synchronous pressure reduction according to the health status. Specifically, before the test begins, a unified time calibration is performed on the business interface server, collaborative scheduling node, voice communication node, robot business service node, text-to-speech service node, speech recognition service node, and recording processing node participating in the test, so that the event times generated by each node have a unified time reference. For processing events that occur consecutively within the same execution node, while recording the unified time, the relative time between events is retained. This is to reduce the statistical errors caused by slight time deviations between different servers when calculating shorter time indicators such as text-to-speech initial sound delay and speech recognition processing time. The system continuously collects operation records corresponding to outbound call initialization requests, business authentication responses, business callback requests, and recording archiving requests from the business interface pressure source; it also collects operation records corresponding to call initiation, first line response, call connection, media channel establishment, and call end from the voice call pressure source; it collects operation records corresponding to dialogue requests, speech generation start, first sound generation, complete speech generation, and call exceptions from the text-to-speech service; it collects operation records corresponding to recording task submission, task entry into parsing, parsing completion, and output of recognized text and business intent from the speech recognition service; and it collects robot conversation status, recording generation status, and recording archiving status from the robot business service and recording processing system. Records that represent the start, completion, or status change of a test processing action are converted into unified link test events. Each link test event includes at least a global tracking identifier, logistics waybill number, event type, event occurrence time, event execution node, voice communication line identifier or service instance identifier, processing result, abnormal status, and associated object identifier. The event type is uniformly set according to the actual business processing stage of logistics intelligent outbound calls, and includes at least the following events: business authentication request event, business authentication completion event, voice call initiation event, line first response event, call connection event, text-to-speech request event, text-to-speech first voice event, script playback completion event, user interaction event, call end event, recording generation event, voice recognition task submission event, voice recognition completion event, business callback event, and recording archiving completion event. When generating a link test event, the global tracking identifier and logistics waybill number corresponding to the current event are read from the standardized test session and written together into the link test event. The global tracking identifier serves as the main association identifier for the test technology link and is used to identify whether different system operation records belong to the same standardized test session. The logistics waybill number serves as the business association identifier and is used to verify whether the associated technical event always corresponds to the same actual logistics business object. When the voice communication line itself cannot directly carry the global tracking identifier, the correspondence between the standardized test session and the call identifier is used to supplement the association. Specifically, when the call identifier is generated, the mapping record of global tracking identifier - logistics waybill number - call identifier - voice communication line identifier is saved synchronously. After the call event generated by the voice communication line is obtained, the corresponding mapping record is first found according to the call identifier, and then the corresponding global tracking identifier and logistics waybill number are added to the link test event. For the recording process, the correspondence between the call identifier and the recording identifier is used to associate the recording generation event with the original standardized test session. For the speech recognition process, the speech recognition task is further associated with the original standardized test session based on the recording identifier and the speech recognition task identifier. The standard business sequence of various events is determined based on the session execution state chain, and the link test events under the same standardized test session are sorted according to the actual event occurrence time to form a session event chain; During the establishment of the session event chain, event exception flags are set for cases where expected preceding events are missing, the event sequence is abnormal, or the same business object has repeated critical events. However, the final fault type is not determined directly at this time. Instead, the corresponding exception events and related events are retained and judged by the subsequent business closed-loop verification process in combination with the complete session state. Based on the temporal relationships between test events in each link, basic time information that can characterize the test operation status is extracted from the session event chain. This includes business authentication processing time, voice call first response time, call setup time, text-to-speech first tone waiting time, script completion time, call duration, recording generation waiting time, speech recognition processing time, and recording archiving processing time. This basic time information is used as the raw data for subsequent link health status judgment and business performance statistics, instead of directly using the summary results generated by any stress tool itself.

[0027] Specifically, after the test begins, a series of test observation windows are established according to a preset sampling period. At the end of each test observation window, the standardized test sessions that have been executed or are being executed within that test observation window are extracted from the session event chain. Based on standardized test sessions, obtain the real-time running results corresponding to the business interface layer, voice communication layer, text-to-speech processing, speech recognition processing, and robot business processing respectively; The results of the business interface layer operation should include at least the business authentication success status, business interface response time, business callback success status, and the number of business interface exceptions. The results of the voice communication layer operation include at least the number of voice calls initiated, the number of valid connections, the number of call setup failures, the first response time of the line, the number of abnormal hang-ups, and the number of current concurrent calls on different voice communication lines; The text-to-speech processing results should include at least the number of text-to-speech requests, the number of successful generation, the initial sound waiting status, the generation timeout status, and the number of current tasks for different service instances. The speech recognition processing results should include at least the number of speech recognition tasks submitted, the number of tasks completed, the number of tasks pending processing, the parsing time, the parsing failure status, and the current task backlog status of different service instances. The robot's business processing results should include at least the status of normal recording generation, business callback completion, recording archiving completion, and the percentage of standardized test sessions that can successfully enter the next state. The results of the above-mentioned different levels of operation are compared with the preset allowable conditions in the test basic configuration set to obtain the link health status corresponding to the current test observation window. The link health status is not determined based on a single indicator, but rather by simultaneously checking whether there are persistent performance anomalies at each level within the current test observation window. Only when the business interface, voice communication line, text-to-speech service, speech recognition service, and robot business processing have not reached the preset anomaly conditions is the current test observation window determined as a healthy observation window. When the test starts, the pressure is not directly applied according to the maximum concurrency capacity of the test environment, but rather according to the preset initial test pressure, and standardized test sessions are released from the shared session parameter pool at a lower rate. The collaborative scheduling process forms the current stress level based on the number of standardized test sessions allowed to enter the locked and executing states per unit time. When the current stress level reaches the preset stable observation time, and multiple consecutive test observation windows are determined to be healthy observation windows, the process is allowed to enter the next stress level. When entering the next pressure level, the release speed of standardized test sessions is increased according to the pressure increase, so that more standardized test sessions can enter the locked state from the unassigned state within a unit of time. The business interface pressure source increases business initialization and authentication requests according to the number of newly added standardized test sessions. Only after the newly added standardized test sessions have completed business authentication will the voice call pressure source increase voice calls according to the timing constraints. When any test observation window shows an anomaly, the entire test task is not stopped immediately. Instead, the anomaly object is first determined based on the execution node, voice communication line identifier, or service instance identifier corresponding to the anomaly event in the session event chain. When anomalies occur on a single voice communication line while other voice communication lines are operating normally, the corresponding voice communication line is set to a line isolation state. Voice communication lines in line isolation state will no longer receive new standardized test sessions, but voice calls already established through this line are allowed to continue to be executed according to the normal business process until the call ends. Standardized test sessions that were originally to be assigned to the abnormal line but have not yet started will be returned to the schedulable state and reallocated by the collaborative scheduling process based on the remaining carrying capacity of other normal lines. When anomalies occur concentrated in a specific text-to-speech service instance, that service instance is set to a speech service isolation state, and the assignment of new speech generation tasks to that service instance is suspended; tests continue to be performed on other normally running text-to-speech service instances. When anomalies occur in a single speech recognition service instance, new recording recognition tasks will be suspended from being submitted to the abnormal service instance. However, speech recognition tasks that have already entered the processing stage will be retained so that they can return processing results normally or form a real processing timeout record. When an anomaly occurs simultaneously in multiple voice communication lines, multiple AI voice service instances, or multiple technical layers of business interfaces, voice communication, and AI voice processing, resulting in continuous performance degradation, the current state is determined to be an end-to-end overload state. After entering the full-link overload state, the shared session parameter pool stops releasing new standardized test sessions at the current rate, and the number of standardized test sessions allowed to enter the execution state per unit time is reduced. Since both the business interface pressure source and the voice call pressure source are driven by the standardized test session release process, the business interface request pressure and subsequent voice call pressure decrease synchronously after the standardized test session release speed decreases, achieving coordinated pressure reduction of the two pressure sources. During the voltage reduction process, standardized test sessions that are still in the "unassigned state" will be temporarily suspended. For standardized test sessions that have completed authentication but have not yet initiated a voice call, the speed at which they enter the call phase will be controlled according to the remaining capacity of the current line. For standardized test sessions that have already established a voice call, they will not be forcibly disconnected directly, but will continue to execute the script, user interaction, call end, recording generation and subsequent business processing. After the pressure reduction is completed, the recovery observation phase begins. During the recovery observation phase, the release rate of the standardized test session after the pressure reduction is maintained, the original pressure is not restored immediately, and the link health status of multiple test observation windows is continuously checked. When an abnormal voice communication line or service instance meets the allowed conditions in the basic test configuration again after recovery detection, the corresponding isolation status is lifted. However, only a small number of new standardized test sessions are allocated to it for recovery verification. After the same abnormality does not reappear in multiple consecutive test observation windows, it is allowed to resume normal scheduling. Once the entire link operation status returns to normal after multiple consecutive test observation windows, the release speed of the standardized test session is gradually increased by a recovery pressure increase amount lower than the normal step-up pressure increase, until the pressure level before the anomaly occurred is restored. If the same anomaly occurs again during the recovery process, the system re-enters the depressurization state, and retains the pressure level corresponding to the occurrence of this anomaly as an important basis for subsequent judgment of the system's stable capacity boundary.

[0028] S4. Perform business closed-loop verification of standardized test sessions based on the session event chain, and perform hierarchical localization of abnormal test sessions. Calculate the full-link business performance indicators based on the business closed-loop verification results, and determine the stable capacity boundary and main performance bottlenecks based on different pressure levels. Specifically, after a standardized test session enters the pending verification state, all link test events corresponding to the current standardized test session are read from the session event chain. At the same time, the test mode, logistics waybill number, global tracking identifier, voice communication line identifier, dialogue template identifier, call identifier, recording identifier, and voice recognition task identifier of the standardized test session are read, and the corresponding expected event sequence is generated according to the current test mode. For the full-link testing mode, the following events are identified as the main link test events that need to occur sequentially to complete a normal standardized test session: business authentication completion event, voice call initiation event, line first response event, call connection event, text-to-speech request event, text-to-speech first sound event, script playback completion event, user interaction event, call end event, recording generation event, speech recognition task submission event, speech recognition completion event, business callback event, and recording archiving completion event. For the text-to-speech special test mode, the current standardized test session is still required to have events such as business authentication, voice call establishment, text-to-speech request, text-to-speech first tone and script completion, and retain subsequent call end and recording processing events as auxiliary verification information, so as to ensure that the text-to-speech performance test results come from the actual voice call environment, rather than isolated text-to-speech interface requests. For the speech recognition-specific test mode, at least there must be a recording generation event or a valid test recording associated record, a speech recognition task submission event, and a speech recognition completion event corresponding to the original standardized test session. It is also required that the recording identifier, logistics waybill number, and expected logistics business intent can all be traced back to the original standardized test session that generated the recording. This ensures that although batch speech recognition tasks can be released in a centralized manner, each recording still has a clear source of logistics business. After determining the expected event sequence, the actual obtained session event chain is compared item by item with the expected event sequence corresponding to the current test mode, and event integrity verification is performed. For each major link test event in the expected event sequence, check whether there is a corresponding event in the actual session event chain according to the business processing order, and check whether the current event is located between the correct preceding and following business events. If all the required events exist and the event order is consistent with the session execution state chain, then mark the event integrity verification result of the current standardized test session as normal. If a major link test event is missing, the last normal event before the missing event and the actual events that occurred after the missing event are obtained. For example, if the business authentication completion event and the voice call initiation event both exist, but the call connection event does not exist, the scope of the anomaly is first limited to the voice call establishment stage. If the call connection, text-to-speech request, and text-to-speech initial tone are all normal, but there is no subsequent recording generation event, the scope of the anomaly is limited to the recording generation stage after the call ends. By checking the session event chain item by item from front to back, the position where the current standardized test session first deviates from the normal business execution order can be obtained. For cases where the same type of critical event occurs repeatedly, an event exception flag is also set. For example, if two different call identifiers appear in the same standardized test session, the same recording identifier corresponds to multiple standardized test sessions at the same time, or the same business callback is executed repeatedly, the duplicate events are not deleted directly. Instead, all events are retained and entered into subsequent object consistency checks to determine whether there is session chaining or business object mismatch under high concurrency. After completing the event integrity verification, perform object consistency verification on the current standardized test session. Using the global tracking identifier as the basis for technical link association, check whether each link test event in the current session event chain can be associated with the same standardized test session. Using the logistics waybill number as the basis for business object verification, check whether the logistics waybill number recorded in each stage of business authentication, voice call, recording generation, voice recognition, business callback and recording archiving is consistent with the logistics waybill number in the current standardized test session. For voice communication events where the logistics waybill number cannot be directly recorded, reverse verification is performed based on the global tracking identifier—logistics waybill number—call identifier—voice communication line identifier mapping record. If the logistics waybill corresponding to the call identifier is different from the current standardized test session, the current session is marked as call object association abnormal. Check the correspondence between the call identifier and the recording identifier, read the actual recording record generated after the call ends, and confirm that the call identifier associated with the recording record is consistent with the call identifier in the current standardized test session. Then check the correspondence between the recording identifier and the speech recognition task identifier to confirm that the recording actually processed by the speech recognition service is the same as the recording generated by the current call. By performing the above consistency checks step by step, we can identify problems such as mismatched logistics waybills, misbound calls, misbound recordings, and misbound speech recognition tasks that may occur under high-concurrency test conditions, rather than judging whether the business is normal based solely on whether each interface returns success. The speech recognition results are checked for consistency in business semantics. For standardized test sessions that use standard test speech to simulate user responses, the expected text content and expected logistics business intent are read from the user behavior script. The actual recognized text and logistics business intent results returned by the speech recognition service are also obtained. In performance testing, the consistency of logistics business intent is prioritized as the result of business semantics check. For example, if the user behavior script specifies that the test user answers "confirm receipt" and the logistics business intent is set to "confirm receipt" in advance, then the final logistics business intent output by the speech recognition service is checked to see if it is also "confirm receipt". If the speech recognition interface returns success, but the output logistics business intent is inconsistent with the expected logistics business intent, it is not considered as normal speech recognition completion, but is marked as an abnormal speech recognition result. After the event integrity, object consistency, recording integrity and business semantic consistency are all verified, the business closed-loop status is determined for the current standardized test session. For standardized test sessions that meet all necessary event requirements of the current test mode, have consistent business object associations, normal recording results and whose speech recognition and business archiving processes meet the preset business requirements, they are determined to be closed-loop completed sessions and the standardized test sessions are changed from pending verification to completed status. Standardized test sessions that have entered the actual testing process but failed to complete the corresponding business links due to malfunctions in the intelligent outbound calling system for logistics under test are judged as business failure sessions. For standardized test sessions that fail to proceed to subsequent business phases due to the execution of proactive voltage reduction, line isolation, service instance isolation, or test termination control, and whose termination is not caused by the failure of the system under test itself, they are marked as test control termination sessions. Test control termination sessions are saved separately and are not mixed with business failure sessions in the statistics to avoid the proactive control behavior of the test system being incorrectly counted as a failure of the system under test. For business failure sessions, fault stratification is performed based on the first occurrence of the exception in the session event chain, the execution node to which the exception event belongs, and the object consistency verification result. When an exception first occurs during the business initialization, time-sensitive business signature, business authentication, business callback, or recording and archiving interface call phase, and the corresponding voice call or AI voice processing has not yet shown an independent exception, it is classified as a business interface layer exception. When an anomaly is first manifested as a failure to establish a voice call, an abnormal first response of the line, a continuously busy line, an inability to establish a media channel, or an abnormal interruption of the call, it is classified as an anomaly in the voice communication layer. When voice calls and media channels are established normally, but anomalies are first manifested as text-to-speech request failure, text-to-speech first tone waiting anomaly, speech generation failure, speech recognition task backlog, speech recognition failure, or logistics business intent recognition anomaly, they are classified as an anomaly in the artificial intelligence voice service layer. When the aforementioned business interfaces, voice communication lines and AI voice services can all complete the corresponding processing, but errors occur such as robot dialogue state transition errors, recording failures, incorrect association between logistics waybills and recordings, inconsistencies between business processing status and callback results, or errors in business archiving objects, these are classified as robot business layer anomalies. When multiple consecutive anomalies occur in a standardized test session, the anomaly handling stage that appears earliest in the session event chain and can explain subsequent anomalies is taken as the primary anomaly level. Anomalies that continue to propagate from this anomaly are recorded as associated anomalies. For example, if the voice communication line fails to establish a media channel, resulting in the absence of subsequent text-to-speech audio and call recordings, the primary anomaly is still located at the voice communication layer, and the subsequent missing recordings are not identified as a separate primary anomaly at the robot business layer, thereby reducing the problem of the same cause being counted repeatedly. For each standardized test session that has completed verification, a business closed-loop verification record is generated, which records its logistics waybill number, global tracking identifier, test mode, closed-loop status, event integrity verification result, object consistency verification result, audio recording integrity verification result, business semantic consistency verification result, main exception level and main exception event, and establishes association between the business closed-loop verification record and the corresponding stress level and link health status.

[0029] Specifically, all standardized test sessions generated during this test are read, and the standardized test sessions are divided into closed-loop completion sessions, business failure sessions, and test control termination sessions according to the business closed-loop status. Among them, the closed-loop completion sessions are used to count the number of logistics intelligent outbound calls actually completed and the normal business processing performance. The business failure sessions are used to count the business failures and anomaly distribution of the system under test under the current pressure conditions. The test control termination sessions are only used to record test tasks that are suspended when executing pressure protection, line isolation, service instance isolation, or test end control, and are not directly included in the number of business failures of the logistics intelligent outbound call system under test. Using standardized test sessions as a unified business statistics unit, the business-level throughput capacity corresponding to the current test task is calculated. Within the stable observation time range of each pressure level, the number of standardized test sessions that actually enter the business execution process and the number of those that eventually become closed-loop completed sessions are counted. The effective logistics outbound call business completion capacity under the current pressure level is represented by the number of closed-loop completed sessions actually completed per unit time. After determining the business-level throughput capacity, the processing latency of each business is calculated based on the occurrence time of test events in different links of the session event chain. For the end-to-end processing time, the time interval between the business authentication request event or outbound call initialization start event and the final recording archive completion event of the same standardized test session is used to represent the total time actually experienced by a logistics outbound call from the start of execution to the completion of the business loop. For the first response time of voice communication, the time interval between the voice call initiation event and the first response event of the line is read to determine the response speed of the voice communication line after receiving a new call in the current concurrent state; For call setup time, the time interval between the voice call initiation event and the call connection event is read to evaluate the time required for the current voice communication line to complete the actual call setup. For the text-to-speech first sound waiting time, the time interval between the text-to-speech request event and the text-to-speech first sound event is read, with the first playable voice obtained in the actual media channel as the end position, so that this indicator simultaneously reflects the waiting time generated by the text-to-speech service queuing, voice generation, and the transmission of the first voice segment to the actual call media link. For speech recognition processing time, the time interval between the speech recognition task submission event and the speech recognition completion event is read to represent the time elapsed from when the recording enters the speech recognition processing queue to when a complete recognition result is obtained. Regarding the recording generation waiting time, the time interval between the call end event and the recording generation event is read to determine whether there is a significant backlog in the recording processing system after a high-concurrency call ends. Based on the closed-loop verification results, statistics are compiled on call connection status, text-to-speech broadcast status, speech recognition processing status, logistics business intent recognition status, recording integrity status, and recording archiving status. The call connection status is determined based on the number of successful call connection events in a standardized test session that actually initiates a voice call; The text-to-speech broadcasting status is determined based on the number of text-to-speech initial sounds that are normally generated and the speech is broadcast in the standardized test sessions that have entered the text-to-speech processing stage. The speech recognition processing performance is determined based on the number of speech recognition tasks that are successfully completed in standardized test sessions with valid recordings submitted. The identification of logistics business intent is determined based on the number of standardized test sessions in which the expected logistics business intent matches the actual logistics business intent. The completeness of the recording is determined based on the number of standardized test sessions that pass the verification of recording existence, readability, recording duration, and object consistency. The recording archiving status is determined based on the number of valid recording archiving completion events actually formed in the standardized test sessions where recording archiving should be performed; The above indicators are statistically analyzed according to test mode, stress level, voice communication line, script template and AI voice service instance, so that the same test task can not only obtain the overall system performance, but also judge the performance difference of different lines, different business scripts and different AI voice service instances during the stress increase process. After completing the performance index calculations for a single standardized test session and each category of objects, read different stress levels and establish stress stage records in order of stress from low to high. Each stress phase should record at least the standardized test session release rate, the number of actual executed sessions, the number of closed-loop completed sessions, the number of business failure sessions, the business-level throughput capacity, the end-to-end processing time, the first response time of voice communication, the first tone waiting time of text-to-speech, the speech recognition processing time, the success status of various services, the link health status, the local anomaly isolation status, and the corresponding business anomaly stratification results. Based on the changing relationship between consecutive pressure stages, it is determined whether each pressure stage belongs to the stable bearing stage. When a certain pressure level has gone through a complete stable observation period, its multiple consecutive test observation windows maintain the link health status, the number of standardized test sessions completed in closed loop per unit time can increase accordingly with the increase of the standardized test session release speed, and there is no continuous growth of pending task backlog or continuous major business anomalies, then the pressure level is determined to be the stable bearing stage, and the standardized test session release speed is increased in a step-by-step pressure increase manner. When any persistent state occurs after entering a new pressure level, the current pressure level is determined to be an unstable bearing phase. Persistent states include: the release rate of standardized test sessions continues to increase but the number of closed-loop completed sessions no longer increases accordingly; the number of failed service sessions continues to increase; the backlog of pending calls on voice communication lines continues to accumulate; the text-to-speech or speech recognition task queue continues to increase; and the core operating state continuously enters the abnormal range and triggers full-link synchronous pressure reduction. The last pressure level that meets the stable capacity conditions before the unstable capacity phase is determined as the stable capacity boundary under the current test conditions. The stable capacity boundary records at least the number of standardized test sessions that can be released under the pressure level, the actual business-level throughput, and the main business performance indicators corresponding to the pressure level. The main performance bottleneck is located for the first unstable capacity phase after the stable capacity boundary. Read the business anomaly layering results in the unstable bearing phase, and obtain the first occurrence time and duration of anomalies in the business interface layer, voice communication layer, AI voice service layer, and robot business layer. If the business interface response is consistently abnormal first, and then the standardized test session cannot enter the voice call phase normally, the business interface layer is identified as the main performance bottleneck layer. If the business interface processing remains normal, but the voice communication first response time increases continuously, the call establishment failure increases continuously, or a certain voice communication line becomes continuously congested first, the voice communication layer is identified as the main performance bottleneck layer, and the bottleneck line is further identified according to the corresponding voice communication line identifier. If the business interface and voice communication process are still normal, but the text-to-speech first tone wait or the voice recognition task backlog worsens continuously first, the AI ​​voice service layer is identified as the main performance bottleneck layer, and the text-to-speech service instance or voice recognition service instance that is experiencing the bottleneck is further identified according to the service instance identifier. If the aforementioned technical services can be completed normally, but the robot session state processing, recording generation, or business archiving becomes consistently abnormal first, the robot business layer is identified as the main performance bottleneck layer. When multiple levels experience anomalies during the same stress phase, instead of simply identifying the bottleneck based on the level with the most anomalies, we combine the session event chain and fault layering results to find the earliest continuously occurring technical level that can lead to subsequent anomalies from the business processing direction, and identify it as the main performance bottleneck level. Subsequent level anomalies caused by this anomaly are recorded as related performance anomalies. Based on the processing results, generate a full-link performance test report for intelligent logistics outbound calls, which should include at least the test mode, the release status of standardized test sessions corresponding to each pressure level, business-level throughput, full-link processing time, voice communication performance, text-to-speech performance, speech recognition performance, recording and business archiving results, stable capacity boundaries, main performance bottleneck levels, abnormal voice communication lines or AI voice service instances, and the number and distribution of anomalies at each level.

[0030] like Figure 2 This embodiment also provides a logistics intelligent outbound call end-to-end performance testing system, including: The test configuration and session building module is used to obtain basic information for intelligent logistics outbound call testing, establish a basic test configuration set and determine the full-link test scenario, generate standardized test sessions based on the basic test configuration set, and establish a unique association between logistics waybills, business signatures and voice calls. The dual-pressure source coordination and test execution module is used to establish a dual-pressure source coordination scheduling mechanism based on standardized test sessions, drive test execution according to the causal sequence of logistics outbound call business, execute real voice call interaction based on the dual-pressure source coordination scheduling results, and complete the corresponding full-link test process according to the test mode. The link monitoring and pressure control module is used to collect full-link test events corresponding to standardized test sessions, construct session event chains based on global tracking identifiers and logistics waybill numbers, determine the full-link health status based on the session event chains, and coordinate the execution of stepped pressure increase, anomaly isolation, and dual pressure source synchronous pressure reduction according to the health status. The closed-loop verification and performance evaluation module is used to perform business closed-loop verification of standardized test sessions based on the session event chain, and to locate abnormal test sessions in a layered manner. Based on the business closed-loop verification results, it calculates the full-link business performance indicators and determines the stable capacity boundary and main performance bottlenecks based on different pressure levels.

[0031] In summary, this invention achieves unified configuration of multiple types of test resources by establishing a basic test configuration set; accurately binds waybills, signatures, calls, and recordings through standardized test sessions and unique associations; ensures test pressure conforms to the real outbound call process through dual-pressure source causal timing scheduling; improves the authenticity of specialized tests by reusing real voice links to complete three types of tests; improves the accuracy of latency statistics and anomaly tracing by uniformly associating cross-layer data through session event chains; avoids local overload contaminating test results by implementing tiered voltage increase, anomaly isolation, and collaborative voltage reduction based on link health status; distinguishes between business failure and test control termination through business closed-loop verification and locates the anomaly level; and finally, improves the authenticity, completeness, and reliability of capacity judgment in logistics intelligent outbound call performance evaluation by completing session analysis through pressure stages and closed loops.

[0032] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for testing the performance of the entire logistics intelligent outbound call chain, characterized in that: include, Acquire basic information for intelligent outbound calling testing in logistics, establish a basic test configuration set and determine the full-link test scenario, generate standardized test sessions based on the basic test configuration set, and establish a unique association between logistics waybills, business signatures and voice calls; A dual-pressure-source collaborative scheduling mechanism is established based on standardized test sessions, and test execution is driven by the causal sequence of logistics outbound call business. Real voice call interaction is executed based on the dual-pressure-source collaborative scheduling results, and the corresponding full-link test process is completed according to the test mode. Collect full-link test events corresponding to standardized test sessions, construct session event chains based on global tracking identifiers and logistics waybill numbers, determine the full-link health status based on session event chains, and coordinate the execution of stepped pressure boosting, anomaly isolation, and dual pressure source synchronous pressure reduction according to the health status; The system performs business closed-loop verification of standardized test sessions based on the session event chain, performs hierarchical localization of abnormal test sessions, calculates full-link business performance indicators based on the business closed-loop verification results, and determines stable capacity boundaries and major performance bottlenecks based on different pressure levels.

2. The logistics intelligent outbound call end-to-end performance testing method as described in claim 1, characterized in that: The specific steps for obtaining basic information for intelligent outbound calling testing in logistics, establishing a basic test configuration set, and determining the full-link test scenario are as follows: Acquire the business interface information, logistics business information, voice communication line information, robot script information, text-to-speech service information, speech recognition service information, and preset test control information of the logistics intelligent outbound call system to be tested, and classify and record them according to the role of each type of information in the logistics intelligent outbound call process; Obtain voice communication line information in the environment to be tested, including the line identifier, operator identifier, calling number resources, called number range, maximum number of concurrent calls allowed for each voice communication line, and media transmission methods supported by the line, and establish voice communication line configuration records according to the line identifier; Obtain robot script information, and create script templates based on the actual use of the logistics intelligent outbound call system for pickup notifications, delivery reminders, abnormal shipment notifications, service follow-ups, or other logistics business scenarios. Set a unique script template identifier for each script template and establish an association between the script template identifier and the corresponding logistics business type. Obtain the service configuration information for the text-to-speech service and the speech recognition service. If there are multiple service instances, set a service instance identifier for each service instance. The test mode is determined according to the actual test purpose, and the test modes are uniformly divided into the full-link test mode, the text-to-speech test mode and the speech recognition test mode. Based on the design capacity of the system under test and the resource availability of the test environment, test control parameters are set, including initial test pressure, pressure increase rate, stable observation time for each pressure stage, maximum allowable test pressure, concurrency limit for each voice communication line, concurrency limit for text-to-speech service, and concurrency limit for speech recognition service. Business interface information, logistics business information, voice communication line information, robot dialogue information, text-to-speech service information, speech recognition service information, test modes, and test control parameters are uniformly organized to form a basic test configuration set.

3. The logistics intelligent outbound call end-to-end performance testing method as described in claim 2, characterized in that: The process of generating standardized test sessions based on a test base configuration set and establishing a unique association between logistics waybills, business signatures, and voice calls specifically involves: Read the logistics order to be tested from the test base configuration set, and establish standardized test sessions in sequence according to the principle that one logistics order corresponds to one standardized test session; Based on the business type of the current logistics waybill, the corresponding script template is searched from the script template configuration, and the corresponding script template identifier is written into the standardized test session. Based on the voice communication line configuration corresponding to the test task, the candidate voice communication line is determined for the current standardized test session. At the same time, the current test mode is written into the standardized test session to form the basic session parameters of the current logistics waybill. For the logistics intelligent outbound call system under test that uses time-sensitive business signatures for business authentication, extract the waybill business parameters and common request parameters that need to participate in the business signature based on the current logistics waybill. Sort all the parameters participating in the signature in ascending order according to the dictionary order of the parameter names, and generate ordered signature raw data according to the parameter concatenation rules actually used by the logistics intelligent outbound call system under test. After adding the business key to the signature raw data, perform message digest processing to obtain the time-sensitive business signature corresponding to the current standardized test session. When generating a time-sensitive business signature, both the signature generation time and the signature expiration time are recorded. For standardized test sessions that have already started business initialization but still need to call business callback interfaces or recording archive interfaces later, check the validity of the current time-limited business signature again before executing the corresponding interface call. If the signature is still valid, continue to use the current business signature. If the signature is close to expire or has expired, regenerate a valid business signature based on the original business parameters of the same logistics waybill and write the new signature status back to the current standardized test session. Establish a unified session information record for each standardized test session; Write the generated standardized test sessions into the shared session parameter pool, and set five session states for each standardized test session in the shared session parameter pool: unassigned, locked, executing, pending verification, and completed. When a standardized test session enters the test execution process from an unassigned state, an exclusive lock is performed on the standardized test session, and a session scheduling credential uniquely corresponding to the current standardized test session is generated.

4. The logistics intelligent outbound call end-to-end performance testing method as described in claim 3, characterized in that: The establishment of a dual-pressure-source collaborative scheduling mechanism based on standardized test sessions, and the execution of tests driven by the causal sequence of logistics outbound call business, are specifically as follows: After the end-to-end performance testing begins, establish pressure sources for business interfaces and voice calls; Search for standardized test sessions that are in an unallocated state and whose business signatures are still valid from the shared session parameter pool, and select the standardized test session to be executed according to the session release order preset by the test task. After selection, immediately adjust its state to locked. The logistics waybill number, business parameters, and timeliness business signature in the current standardized test session are sent to the business interface pressure source, which then initiates an outbound call initialization request according to the business interface rules of the logistics intelligent outbound call system to be tested. The collaborative scheduling process receives the business authentication result returned by the business interface pressure source and controls the subsequent state of the current standardized test session based on the business authentication result; When the business interface returns a successful authentication result or a successful outbound call task creation result, the current standardized test session is changed from a locked state to an executing state. At the same time, the corresponding session scheduling voucher, logistics waybill number, target phone number, script template identifier and voice communication line identifier are sent to the voice call pressure source. When the business interface returns a signature error, signature invalidation, authentication failure, or business task creation failure, the current standardized test session is not allowed to continue into the voice call stage, and the business interface exception that occurred in the current standardized test session is recorded. After the voice call pressure source obtains a standardized test session that is allowed to be executed, it selects the corresponding line according to the voice communication line identifier recorded therein, and establishes a voice call according to the calling number, target number and call parameters configured for that line. After the call is established, the corresponding call identifier is generated and the call identifier is written back to the current standardized test session. Establish a session execution state chain for each standardized test session, and set it sequentially according to the actual logistics intelligent outbound call business process: waiting for authentication, authentication completed, call allowed, call setup, voice interaction, call ended, voice recognition, business archiving, and closed loop completion. During the collaborative scheduling process, the start time, end time, execution result, and responsible business node of each state transition in the standardized test session are recorded, and the state transition records are saved together with the global tracking identifier and logistics waybill number in the standardized test session. For the three testing modes, after the standardized test session passes the pre-processing stage, the number of sessions entering different processing stages is controlled differently.

5. The logistics intelligent outbound call end-to-end performance testing method as described in claim 4, characterized in that: The process of performing real voice call interaction based on the dual-pressure source collaborative scheduling result and completing the corresponding full-link test according to the test mode is as follows: Once the standardized test session enters the call-allowed state, the voice call pressure source reads the target contact number, voice communication line identifier, robot identifier, and script template identifier corresponding to the current standardized test session, initiates a voice call to the target test terminal through the selected voice communication line, and records the call process status in sequence. Once the voice communication line returns a valid answer and establishes a media channel, the current standardized test session is changed from the call establishment state to the voice interaction state. Based on the script template identifier in the standardized test session, the corresponding script content is read from the robot script configuration and submitted to the text-to-speech service. The text-to-speech service generates corresponding voice data based on the speech content and sends the generated voice data to the media channel corresponding to the current voice call for playback. When the speech is submitted to the text-to-speech service, the speech submission time is recorded. When the media channel detects the first valid speech, the arrival time of the first sound is recorded. When the complete speech is finished, the playback end time is recorded. The playback end time record is associated with the current standardized test session. User behavior scripts are pre-built for different logistics business types in the test base configuration set; When the robot business process determines that the current call has ended, the voice call pressure source executes the hang-up operation, records the call end time, adjusts the current standardized test session from voice interaction state to call end state, and the logistics intelligent outbound call system under test generates the corresponding audio file of this call according to the normal business processing flow. After detecting the generation of an audio file, obtain the corresponding audio identifier, audio file generation time, recording duration, and recording storage location, and write the audio identifier into the current standardized test session; The recording is submitted to the speech recognition service, and the current standardized test session is adjusted to speech recognition state. The speech recognition service recognizes the user's speech in the recording, generates speech recognition text, and outputs the corresponding logistics business intent result according to the intent classification rules of the logistics business to be tested. The speech recognition task identifier, recognition start time, recognition completion time, recognition text and logistics business intent result are written into the current standardized test session. After speech recognition is completed, the business interface pressure source calls the session end callback interface and the recording archive interface based on the logistics waybill number, business status and business signature that is still valid in the current standardized test session. After completing the business callback and recording archiving, adjust the current standardized test session to the business archive state; For the three test modes, the same set of standardized test sessions, the same set of voice call execution processes, and the same set of subsequent result association mechanisms are used. The release method of the standardized test sessions at different stages is adjusted according to the test objectives.

6. The logistics intelligent outbound call end-to-end performance testing method as described in claim 5, characterized in that: The process of collecting standardized test sessions and constructing session event chains based on global tracking identifiers and logistics waybill numbers is as follows: Before the test begins, a unified time calibration is performed on the business interface server, collaborative scheduling node, voice communication node, robot business service node, text-to-speech service node, speech recognition service node, and recording processing node participating in the test. For processing events that occur consecutively within the same execution node, the relative time between events is retained while recording the unified time. The system continuously collects operation records corresponding to outbound call initialization requests, business authentication responses, business callback requests, and recording archiving requests from the business interface pressure source; it also collects operation records corresponding to call initiation, first line response, call connection, media channel establishment, and call end from the voice call pressure source; it collects operation records corresponding to dialogue requests, speech generation start, first sound generation, complete speech generation, and call exceptions from the text-to-speech service; it collects operation records corresponding to recording task submission, task entry into parsing, parsing completion, and output of recognized text and business intent from the speech recognition service; and it collects robot conversation status, recording generation status, and recording archiving status from the robot business service and recording processing system. The records that represent the start, completion, or state change of a test processing action are converted into unified link test events; When generating a link test event, the global tracking identifier and logistics waybill number corresponding to the current event are read from the standardized test session, and both are written into the link test event. When the voice communication line itself cannot directly carry a global tracking identifier, the correspondence between the standardized test session and the call identifier is used to supplement the association. The standard business sequence of various events is determined based on the session execution state chain, and the link test events under the same standardized test session are sorted according to the actual event occurrence time to form a session event chain; Based on the temporal relationship between test events in each link, basic time information that can characterize the test running status is extracted from the session event chain.

7. The logistics intelligent outbound call end-to-end performance testing method as described in claim 6, characterized in that: The process of determining the overall health status based on the session event chain and then collaboratively executing stepped voltage boosting, anomaly isolation, and simultaneous voltage reduction from both pressure sources based on the health status specifically involves: After the test begins, a series of test observation windows are established according to a preset sampling period. At the end of each test observation window, the standardized test sessions that have been executed or are being executed within that test observation window are extracted from the session event chain. Based on standardized test sessions, obtain the real-time running results corresponding to the business interface layer, voice communication layer, text-to-speech processing, speech recognition processing, and robot business processing respectively; The above-mentioned different levels of operation results are compared with the preset allowable conditions in the test basic configuration set to obtain the link health status corresponding to the current test observation window; The collaborative scheduling process forms the current stress level based on the number of standardized test sessions allowed to enter the locked and executing states per unit time. When the current stress level reaches the preset stable observation time, and multiple consecutive test observation windows are determined to be healthy observation windows, the process is allowed to enter the next stress level. When any test observation window shows an anomaly, the anomaly object is determined based on the execution node, voice communication line identifier, or service instance identifier corresponding to the anomaly event in the session event chain. When an anomaly occurs simultaneously in multiple voice communication lines, multiple AI voice service instances, or multiple technical layers of business interfaces, voice communication, and AI voice processing, resulting in continuous performance degradation, the current state is determined to be an end-to-end overload state. Once the entire link is overloaded, stop releasing new standardized test sessions at the current rate from the shared session parameter pool and reduce the number of standardized test sessions allowed to enter the execution state per unit time. After the pressure reduction is completed, the recovery observation phase begins. During the recovery observation phase, the release rate of the standardized test session after the pressure reduction is maintained, the original pressure is not restored immediately, and the link health status of multiple test observation windows is continuously checked. Once the entire link operation status returns to normal after multiple consecutive test observation windows, the release speed of the standardized test session is gradually increased by a recovery pressure increase amount that is lower than the normal step pressure increase, until the pressure level before the anomaly occurred is restored.

8. The logistics intelligent outbound call end-to-end performance testing method as described in claim 7, characterized in that: The specific steps for performing business closed-loop verification of standardized test sessions based on session event chains and hierarchical localization of abnormal test sessions are as follows: After the standardized test session enters the verification state, all link test events corresponding to the current standardized test session are read from the session event chain. At the same time, the test mode, logistics waybill number, global tracking identifier, voice communication line identifier, script template identifier, call identifier, recording identifier, and voice recognition task identifier of the standardized test session are read, and the corresponding expected event sequence is generated according to the current test mode. After determining the expected event sequence, the actual obtained session event chain is compared item by item with the expected event sequence corresponding to the current test mode, and event integrity verification is performed. After completing the event integrity verification, perform object consistency verification on the current standardized test session; Perform a business semantic consistency check on the speech recognition results; After the event integrity, object consistency, recording integrity and business semantic consistency are all verified, the business closed-loop status is determined for the current standardized test session. For standardized test sessions that meet all necessary event requirements of the current test mode, have consistent business object associations, normal recording results and whose speech recognition and business archiving processes meet the preset business requirements, they are determined to be closed-loop completed sessions and the standardized test sessions are changed from pending verification to completed status. Standardized test sessions that have entered the actual testing process but failed to complete the corresponding business links due to malfunctions in the intelligent outbound calling system for logistics under test are judged as business failure sessions. For standardized test sessions that fail to proceed to subsequent business phases due to the execution of proactive voltage reduction, line isolation, service instance isolation, or test termination control, and whose termination is not caused by the failure of the system under test itself, they are marked as test control terminated sessions. For business failure sessions, fault stratification is performed based on the first occurrence of the exception in the session event chain, the execution node to which the exception event belongs, and the object consistency verification result. When multiple consecutive exceptions occur in a standardized test session, the exception handling stage that appears earliest in the session event chain and can explain subsequent exceptions is taken as the main exception level, and the exceptions that continue to propagate from that exception are recorded as associated exceptions. For each standardized test session that has completed verification, a business closed-loop verification record is generated, which records its logistics waybill number, global tracking identifier, test mode, closed-loop status, event integrity verification result, object consistency verification result, audio recording integrity verification result, business semantic consistency verification result, main exception level and main exception event, and establishes association between the business closed-loop verification record and the corresponding stress level and link health status.

9. The logistics intelligent outbound call end-to-end performance testing method as described in claim 8, characterized in that: The specific steps for calculating end-to-end service performance indicators based on the service closed-loop verification results, and determining stable capacity boundaries and major performance bottlenecks based on different pressure levels, are as follows: Read all standardized test sessions generated during this test, and divide the standardized test sessions into closed-loop completion sessions, business failure sessions, and test control abort sessions according to the business closed-loop status; Using standardized test sessions as a unified unit of business statistics, the business-level throughput capacity corresponding to the current test task is calculated. After determining the business-level throughput capacity, the processing latency of each business is calculated based on the occurrence time of test events in different links of the session event chain. Based on the closed-loop verification results, statistics are compiled on call connection status, text-to-speech broadcast status, speech recognition processing status, logistics business intent recognition status, recording integrity status, and recording archiving status. After completing the performance index calculations for a single standardized test session and each category of objects, read different stress levels and establish stress stage records in order of stress from low to high. Based on the changing relationship between continuous pressure stages, determine whether each pressure stage belongs to a stable bearing stage, and increase the release speed of the standardized test session according to the step-up pressure method; If any persistent state occurs after entering a new pressure level, the current pressure level will be defined as an unstable bearing stage. The pressure level that meets the stable load-bearing conditions before the unstable load-bearing stage is determined as the stable capacity boundary under the current test conditions, and the main performance bottleneck is located for the first unstable load-bearing stage after the stable capacity boundary. A performance test report on the entire logistics intelligent outbound call chain is generated based on the processing results.

10. A logistics intelligent outbound call end-to-end performance testing system, based on the logistics intelligent outbound call end-to-end performance testing method according to any one of claims 1 to 9, characterized in that: include, The test configuration and session building module is used to obtain basic information for intelligent logistics outbound call testing, establish a basic test configuration set and determine the full-link test scenario, generate standardized test sessions based on the basic test configuration set, and establish a unique association between logistics waybills, business signatures and voice calls. The dual-pressure source coordination and test execution module is used to establish a dual-pressure source coordination scheduling mechanism based on standardized test sessions, drive test execution according to the causal sequence of logistics outbound call business, execute real voice call interaction based on the dual-pressure source coordination scheduling results, and complete the corresponding full-link test process according to the test mode. The link monitoring and pressure control module is used to collect full-link test events corresponding to standardized test sessions, construct session event chains based on global tracking identifiers and logistics waybill numbers, determine the full-link health status based on the session event chains, and coordinate the execution of stepped pressure increase, anomaly isolation, and dual pressure source synchronous pressure reduction according to the health status. The closed-loop verification and performance evaluation module is used to perform business closed-loop verification of standardized test sessions based on the session event chain, and to locate abnormal test sessions in a layered manner. Based on the business closed-loop verification results, it calculates the full-link business performance indicators and determines the stable capacity boundary and main performance bottlenecks based on different pressure levels.

Images