A system for remotely managing notebook computers for WLAN testing in a centralized manner

Abstract

The present application relates to the technical field of network testing, and particularly relates to a system for remotely centrally managing notebook computers to perform WLAN testing. The method comprises the following steps: a WLAN testing task containing a target network, a testing duration and a delay parameter is centrally issued by a remote central management terminal; each notebook terminal generates a random delay value according to system load and performs testing in sequence; when a user activity is detected, the testing is automatically interrupted and the position is recorded; then, the testing is resumed according to the interruption position, and finally, the complete testing result and interruption information are uploaded to the management terminal. The present application realizes unified management and staggered execution of multi-terminal WLAN testing through remote centralized issuance and intelligent delay scheduling mechanism, and guarantees the stability, continuity of the testing process and the integrity and reliability of the result by combining user state monitoring and interruption and resumption technology.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network testing, and in particular to a system for remotely centrally managing notebook computers to perform WLAN testing. BACKGROUND

[0002] Before leaving the factory or in enterprise-level operation scenarios, notebook computers usually need to be centrally tested for WLAN wireless performance to verify the connection stability, signal strength and data throughput capacity of the device in different network environments. In order to improve the testing efficiency, the prior art generally adopts a remote centralized management method, that is, a central server issues unified test task instructions to multiple notebook computers, and each terminal automatically performs WLAN connection and data transmission testing within a predetermined time, and then transmits the results back.

[0003] However, in the actual centralized testing process, due to differences in the running state, environment and user intervention of each notebook computer, the following problems still exist in the conventional method: first, most centralized testing systems use unified scheduling or timing triggering mechanisms, and all terminals start testing at the same time, which can easily cause resource contention on the same channel, data interference or testing delay, thereby leading to unstable test results; second, some improved schemes introduce high-precision time synchronization, unified clock protocol or centralized load control systems to alleviate the conflict, but such schemes are complex to implement, high in deployment cost, and require high permissions for the tested terminals, which are not suitable for general enterprise or consumer-level scenarios. SUMMARY

[0004] Therefore, it is necessary to provide a system for remotely centrally managing notebook computers to perform WLAN testing to solve at least one of the above technical problems.

[0005] To achieve the above purpose, a system for remotely centrally managing notebook computers to perform WLAN testing, the method comprising the following steps:

[0006] A test issuing module is configured to issue unified WLAN test task instructions to a plurality of notebook computer terminals through a remote centralized management terminal, wherein the test task instructions include target network identification, test duration and delay window parameters;

[0007] A delay test module is configured to generate a random delay value based on the current system load state when each notebook computer terminal receives the test task instructions, wherein the random delay value is limited within the delay window parameters; each notebook computer terminal is sorted and tested based on the random delay value to obtain a test instruction;

[0008] The state monitoring module is used for obtaining a user activity state based on a test instruction; interrupt detection is performed on the test instruction according to the user activity state, and when the user activity state is detected, the current WLAN test is automatically paused, and a test interruption position is recorded in a local cache;

[0009] The test resuming module is used for interrupting the test of the notebook computer according to the interruption position, obtaining a final test result, and uploading the final test result and corresponding interruption information to the remote centralized management end.

[0010] The application has the following beneficial effects:

[0011] Firstly, the application realizes the unified test task issuing and centralized control of the remote centralized management end on multiple notebook computer terminals by arranging the test issuing module, so that the WLAN test is changed from the traditional manual single-machine operation to the automatic and batch remote scheduling process. The centralized structure not only improves the efficiency and consistency of the test task distribution, but also avoids the test deviation caused by the manual configuration error. Meanwhile, by introducing the target network identifier, test duration and delay window parameters in the test task instruction, flexible adaptation to different network environments and test requirements can be realized, so that the organization efficiency and controllability of the WLAN test are greatly improved.

[0012] Secondly, the delay test module of the application generates a corresponding load level label by obtaining the system load state data of each notebook computer, and then generates a random delay value adaptively in combination with a preset delay interval table, so that the dynamic peak-shaving test scheduling between multiple terminals is realized. The design makes the test triggering time randomly distributed according to the real-time system load, avoids the network congestion and channel interference caused by the simultaneous execution of the test by multiple terminals. On this basis, the system further sets the clock jitter period and the dynamic delay compensation interval, so that the delay triggering time is intelligently dispersed in the peak and valley intervals, thereby optimizing the time distribution and resource utilization of the overall test task. The mechanism effectively improves the stability of the test and the comparability of the data, and ensures that the test result is more objective and reliable.

[0013] Thirdly, the application realizes the dynamic protection of the test process by the state monitoring module which senses the user activity state in real time and automatically pauses the current WLAN test when the user operation is detected, and buffers the interruption information and task position locally. When the user returns to the idle state, the test resuming module can automatically load the test environment configuration based on the interruption position, perform the interrupt resuming test, and ensure the smooth continuation of the test task from the interruption point. By integrating the resuming test data set and the interruption information and uploading them to the remote centralized management end, the test process can be completely restored, and the continuous tracing of the test data can be realized. The design ensures the recoverability and result integrity of the test task in the complex use scenario, and greatly improves the robustness and maintainability of the system in the multi-terminal distributed test environment. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 A module schematic diagram of a system for remotely centrally managing a notebook computer to perform WLAN test;

[0015] Figure 2 A module schematic diagram of a system for remotely centrally managing a notebook computer to perform WLAN test; Figure 1 A detailed implementation step flow schematic diagram of the delay test module;

[0016] Figure 3 A module schematic diagram of a system for remotely centrally managing a notebook computer to perform WLAN test;

[0017] The implementation, functional features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0018] The technical method of the present application will be described clearly and completely below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all the other embodiments obtained by those skilled in the art without creative work fall within the scope of the present application.

[0019] In addition, the accompanying drawings are only schematic illustrations of the present application, and are not necessarily drawn to scale. The same reference numerals in the drawings represent the same or similar parts, and thus repeated description thereof will be omitted. Some block diagrams shown in the drawings are functional entities, and do not necessarily correspond to physically or logically independent entities. The functional entities can be implemented in software, or in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0020] It should be understood that although the terms "first", "second" and the like can be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element without departing from the scope of the example embodiments. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0021] To achieve the above object, please refer to Figures 1 to 3 The system for remotely centrally managing a notebook computer to perform WLAN test comprises:

[0022] The test issuing module is configured to execute step S1: issuing a unified WLAN test task instruction to a plurality of notebook computer terminals through a remote centralized management terminal, wherein the test task instruction comprises a target network identifier, a test duration and a delay window parameter;

[0023] In an embodiment, the remote centralized management terminal serves as a unified task scheduling and issuing platform, and is configured to centrally control and manage the notebook computer terminals distributed in different locations. When the system starts a WLAN test task, the remote centralized management terminal first generates a corresponding test task instruction according to a preset test plan, and the instruction comprises a target network identifier, a test duration and a delay window parameter and other key information.

[0024] The target network identifier is used to indicate a specific wireless local area network to which each notebook computer terminal needs to be connected or tested, for example, a specific SSID or BSSID. The test duration is used to limit the time period for each terminal to execute the WLAN test, so as to collect network performance data in different time periods. The delay window parameter is used to determine the time resolution and calculation interval of network delay data sampling, so as to ensure that the subsequent test data has a consistent statistical standard.

[0025] After generating the task instruction, the remote centralized management terminal issues the unified test task instruction to each notebook computer terminal through a secure communication channel (such as a TLS encrypted channel). After receiving the instruction, each terminal automatically performs task analysis and parameter loading operations, confirms the test target network, task execution duration and delay analysis parameter, and starts the corresponding WLAN test process in the specified test period.

[0026] For example, in a centralized test, the remote centralized management terminal issues a task instruction to 20 notebook computers, the target network identifier is the enterprise intranet SSID "Office_WLAN", the test duration is set to 30 minutes, and the delay window parameter is set to 100 milliseconds. After receiving the instruction, each terminal synchronously starts the test task at the predetermined time, and realizes multi-point distributed performance collection of the same wireless network.

[0027] The delay test module is configured to execute step S2: generating a random delay value according to a current system load state after each notebook computer terminal receives the test task instruction, wherein the random delay value is limited within the delay window parameter; and performing a sorting test on each notebook computer terminal based on the random delay value to obtain a test instruction.

[0028] In an embodiment, when each notebook computer terminal receives the WLAN test task instruction issued by the remote centralized management terminal, it first performs self-checking according to the local system load state. The system load state includes but is not limited to CPU occupancy, memory usage, background process quantity, network interface activity state and other information, which are used to evaluate the performance margin of the terminal in executing the test task.

[0029] After completing the system load state detection, the notebook computer terminal generates a random delay value based on the detection result, and the delay value is within the delay window parameter preset in the task instruction. For example, when the delay window parameter is set to 0-200 milliseconds, the system can automatically generate a larger delay value (such as 150 milliseconds) when the current load is high, and a smaller delay value (such as 30 milliseconds) when the system load is low, so as to realize the peak-shaving start of distributed test tasks and prevent test interference caused by network congestion or resource competition.

[0030] Subsequently, the remote centralized management terminal sorts and controls all notebook computer terminals according to the random delay values reported by each terminal. Specifically, the management terminal preferentially arranges the terminal with a smaller random delay value in the front of the test sequence, and arranges the terminal with a larger delay value in the subsequent execution sequence, so as to form a test execution queue that is reasonably distributed in time and has low network interference.

[0031] After sorting, the management terminal generates corresponding test instructions according to the sorting result, which includes the task execution start time, target network connection steps and data sampling strategy of each terminal. After receiving the test instructions, each notebook computer terminal automatically starts WLAN connection and performance test after the specified random delay time.

[0032] For example, in a centralized test, assuming that the delay window parameter of 10 terminals is 0-200 milliseconds, the generated random delay values are 15 milliseconds, 60 milliseconds, 125 milliseconds, 190 milliseconds, etc. The management terminal forms an execution order list according to these random delay values, and issues time-sharing start test instructions to the corresponding terminals, so as to realize efficient and orderly execution of WLAN test tasks.

[0033] The state monitoring module is configured to perform step S3: obtaining a user activity state based on the test instruction; and performing interruption detection on the test instruction according to the user activity state, and automatically pausing the current WLAN test when detecting the user activity state and recording the test interruption position in the local cache;

[0034] In an embodiment, when the WLAN test program is started, the tablet continuously receives test instructions from the test module, while enabling the user activity monitoring module to obtain the user's operation state in real time. The user activity state can be obtained through various sensors, including touch input of the touch screen, motion detection of the gyroscope and accelerometer, mouse or keyboard operation, etc. The system processes the sensor data to generate user activity state identifiers, such as "still", "in operation", or "in movement".

[0035] After the tablet receives the test instructions, it associates the instructions with the current user activity state for judgment. Preferably, when it is detected that the user activity state is "in operation" or "in movement", the system considers that the current user may interfere with the accuracy of the WLAN test.

[0036] In response to detecting the user activity state, the test module automatically triggers the WLAN test interruption operation: suspending the test task being executed, including suspending data collection, signal analysis, and log recording; recording the interruption position of the current test task, completed test data, and test instruction state in the local cache, so that the test can be resumed after the user activity ends; updating the test state identifier to "interrupted", while recording the timestamp of the interruption occurrence.

[0037] For example, when the tablet is executing the 5th network node test of the signal strength scan, if the user starts to operate the touch screen to slide the page, the test module detects the touch input and suspends the test process, while saving the 5th network node and the current scan progress to the cache to ensure that the test can continue from the interruption position after the subsequent test is resumed.

[0038] To improve response efficiency, the user activity detection and WLAN test interruption judgment can use an event-driven mechanism, i.e., only when the user activity state changes, the interruption judgment is triggered, avoiding unnecessary impact on test performance.

[0039] It should be noted that the interruption information recorded in the local cache includes test instruction identifier, current network node information, collected data summary, and interruption time, etc., which are used for subsequent test resumption and abnormality analysis to ensure the integrity and continuity of the WLAN test data.

[0040] The test resumption module is used to perform step S4: resume the test of the notebook computer according to the interruption position, obtain the final test result, and upload it to the remote centralized management end together with the corresponding interruption information.

[0041] In an embodiment, according to the interrupt position and the saved test instruction state, the test module resumes the WLAN test task and continues to perform subsequent tests from the interrupt node, including signal strength measurement, network response delay collection and network connectivity detection, etc., to ensure the continuity of the subsequent data collection and the data before the interruption.

[0042] During the interrupt continuous measurement process, the tablet computer records the continuous measurement data in real time and performs time sequence correlation on the continuous measurement data and the data before the interruption to generate a complete test result set. To ensure data accuracy, the continuous measurement data can be checked, for example, by comparing the continuity of the network signal or the rationality of the response delay to exclude abnormal fluctuations.

[0043] When the entire WLAN test task is completed, the tablet computer packages the final test result together with the corresponding interrupt information, including the test node sequence, the signal strength of each network node, the response delay, the test start and end time, the interrupt occurrence time and the interrupt position, etc.

[0044] The tablet computer uploads the complete test result and the interrupt information to the remote centralized management end through a secure communication channel for network management personnel to analyze, optimize and remotely schedule. Preferably, the uploaded data can use a segmented transmission and verification mechanism to ensure that the data is not lost or tampered with during transmission.

[0045] For example, when a WLAN test is interrupted by user operation at the 7th network node, the tablet computer caches the test progress of the node. After the user stops operating, the system continues to test the remaining nodes from the 7th node and finally generates complete node signal strength and response delay data, together with the interrupt information uploaded to the remote management end, realizing the complete closed loop of interrupt continuous measurement.

[0046] It should be noted that the continuous measurement and upload operation should be coordinated with the user activity monitoring module to avoid interruption again when the user re-operates, and to ensure that the final uploaded data contains the full information before and after the interruption, so that the remote management end obtains continuous and complete WLAN test data.

[0047] As an example of the present application, refer to Figure 2 The execution steps of the delay test module in the present example include:

[0048] Step S21: After receiving the test task instruction, obtain the current system load state data of the notebook computer terminal;

[0049] Step S22: Determine the load level of the notebook computer terminal according to the current system load state data, and record the load level as a load level label;

[0050] Step S23: reading a delay value interval corresponding to the load level from a preset delay interval table based on the load level;

[0051] Step S24: generating a random delay value within the delay value interval, and recording the random delay value together with a corresponding load level label and a timestamp as delay scheduling data;

[0052] Step S25: performing a sorting test on each notebook terminal respectively based on the delay scheduling data to obtain a test instruction.

[0053] In an embodiment, after receiving the test task instruction, the notebook terminal can sequentially call a monitoring interface or a driver provided by an operating system to collect the following data: CPU core utilization rate, memory usage rate, disk read / write speed, network throughput, and current running process quantity. The terminal aggregates the above indicators into structured data records, such as a multi-dimensional array or a key-value pair table, and appends a collection timestamp, which is used for subsequent load analysis.

[0054] In some embodiments, to avoid the influence of instantaneous fluctuations on the judgment, the collected continuous data can be subjected to short-time averaging or smoothing processing, for example, sampling every 100 milliseconds and calculating the average of the last 5 samples.

[0055] The indicators such as CPU utilization rate, memory occupancy rate, and disk activity can be compared with preset threshold values: lower than the low threshold value is low load, in the middle interval is medium load, and higher than the high threshold value is high load. The load level can be further combined with weight calculation to obtain a comprehensive score, for example, CPU occupancy rate 50%, memory occupancy rate 30%, and disk occupancy rate 20%. After weighted summation of the scores of each indicator, the load level is mapped to low / medium / high level. The system generates a load level label and records it together with the current timestamp to form a load level record entry, which provides a direct basis for delay generation.

[0056] The delay interval table is stored in the terminal or a centralized database in advance, and each load level corresponds to a set of minimum delay and maximum delay values, for example: low load 0-50 milliseconds, medium load 50-150 milliseconds, and high load 150-300 milliseconds. The terminal retrieves the corresponding interval in the table according to the load level label to generate a delay interval data structure, including the start delay, the end delay, and the mapping relationship with the load level label.

[0057] In some embodiments, the interval can be dynamically adjusted according to the environment or test requirements, for example, expanding the upper limit of the interval in the case of high network delay to ensure uniform test distribution.

[0058] The random number generation module can be used to generate a random delay value within the delay interval corresponding to the current load level, for example, a value of 87 milliseconds is randomly generated within the medium load interval of 50-150 milliseconds. The generated random delay value is combined with the load level tag and the current sampling timestamp to form a complete delay scheduling data entry.

[0059] In some embodiments, to ensure smooth distribution of tests, the generated random delay value can be de-duplicated or distribution-verified to avoid test conflicts caused by consecutive terminals obtaining the same delay.

[0060] All notebook terminals can be sorted in ascending order according to the delay values to form a final execution order list. The system issues test instructions in accordance with the sorting order to make terminals of different load levels execute tasks in a non-synchronous state, thereby avoiding performance bottlenecks caused by high-load terminals and low-load terminals responding at the same time.

[0061] In some embodiments, if the terminals are found to be in the same time window after sorting, the system can fine-tune the delay values or re-insert some terminals into the idle time period to ensure uniform distribution of test tasks.

[0062] It should be noted that during implementation, the dynamic changes in the load state of the terminals should be continuously monitored, and if the load fluctuates significantly, the delay interval can be updated in real time and the random delay value can be regenerated to ensure the stability and fairness of the test.

[0063] Preferably, generating a random delay value within the delay value interval includes:

[0064] confirming a minimum delay threshold and a maximum delay threshold according to the delay value interval;

[0065] randomly selecting a delay sampling point between the minimum delay threshold and the maximum delay threshold, wherein the delay sampling point corresponds to a candidate delay value;

[0066] combining the candidate delay value with the current system time to form a delay trigger time;

[0067] verifying the availability of the delay trigger time, and confirming the candidate delay value as the final random delay value when the verification result satisfies a preset delay constraint condition.

[0068] In one embodiment, the minimum delay threshold and the maximum delay threshold are obtained according to the delay value interval, for example, the low load interval is 0-50 milliseconds, the medium load interval is 50-150 milliseconds, and the high load interval is 150-300 milliseconds. Then, a delay sampling point is selected between the minimum delay threshold and the maximum delay threshold by a random number generation method. The value corresponding to the delay sampling point is the candidate delay value, for example, a candidate delay value of 87 milliseconds is randomly selected within the medium load interval.

[0069] The candidate delay value is combined with the current terminal timestamp to form a delay trigger time, which is used to determine a specific time node for task assignment or test execution. For example, if the current time is 12:00:00 and the candidate delay value is 87 milliseconds, the delay trigger time is 12:00:00.087. The delay trigger time is verified for availability, including checking whether it conflicts with existing tasks, whether it exceeds the test time limit, and whether it meets the preset delay constraint conditions, such as not exceeding the upper limit of the interval or not being lower than the lower limit of the interval.

[0070] When the verification result meets the preset delay constraint condition, the candidate delay value is confirmed as the final random delay value, and the random delay value is recorded together with the load level label and the timestamp as delay scheduling data for subsequent terminal sorting and test task assignment.

[0071] In some embodiments, if the verification result fails, a candidate delay value can be generated again within the delay value interval, and the above steps can be repeated until a usable random delay value is confirmed, to ensure the uniformity of delay scheduling and the reliability of test execution.

[0072] Preferably, combining the candidate delay value with the current system time to form the delay trigger time includes:

[0073] Obtaining a system timestamp, wherein the system timestamp is used to represent the current system clock state of the notebook terminal;

[0074] Performing a time accumulation operation on the candidate delay value and the system timestamp to obtain an initial calculation value of the delay trigger time;

[0075] Performing a system clock synchronization correction on the initial calculation value to obtain a corrected delay trigger time, and recording the corrected delay trigger time as the delay trigger time.

[0076] In an embodiment, a current system timestamp of the notebook terminal is obtained, and the system timestamp is used to represent the current system clock state of the terminal. For example, the obtained system timestamp can be a current time point accurate to milliseconds.

[0077] Then, the candidate delay value generated in the foregoing step is accumulated with the system timestamp to obtain an initial calculation value of the delay trigger time. For example, if the current system time is 12:00:00.500 and the candidate delay value is 87 milliseconds, the initial calculation value is 12:00:00.587.

[0078] To ensure the accuracy of the delay trigger time, the initial calculated value is also corrected by system clock synchronization. The correction can include comparing the initial calculated value with a network time or an external time source, and fine-tuning according to the deviation to eliminate system clock drift or time synchronization error. For example, if the system clock is 0.005 seconds faster than the network standard time, the delay trigger time is corrected to 12:00:00.582.

[0079] Finally, the corrected delay trigger time is recorded as the delay trigger time and used for subsequent delay scheduling data generation and task distribution. For example, the corrected delay trigger time is stored together with the load level label, timestamp, and candidate delay value to ensure that the task execution of each terminal is performed with the expected delay.

[0080] In some embodiments, to ensure the stability of task scheduling, the above steps can be repeated before each task scheduling to update the delay trigger time in real time to adapt to system time fluctuations and load changes.

[0081] Preferably, the availability of the delay trigger time is verified, and when the verification result does not meet the preset delay constraint condition, the method for obtaining the random delay value further includes:

[0082] According to the distribution of the delay trigger time and the task queue time of the test task instruction, the current task distribution gap time is confirmed;

[0083] The task distribution gap time is added to the boundary of the delay value interval to obtain a dynamic delay compensation interval, wherein the dynamic delay compensation interval is used to automatically disperse the trigger time when the system load is uneven;

[0084] In the dynamic delay compensation interval, a time point corresponding to the peak or valley of the current system clock is determined by selecting the clock jitter period corresponding to the system timestamp, to determine a new delay sampling point;

[0085] The time offset corresponding to the new delay sampling point is determined as the random delay value.

[0086] In an embodiment, when the generated delay trigger time does not meet the preset delay constraint condition, the current task distribution gap time can be first confirmed according to the distribution of the delay trigger time and the task queue time of the test task instruction. The task distribution gap time is used to represent the available time window between adjacent tasks, so as to judge whether the delay trigger time is in conflict or too concentrated.

[0087] Then, the task distribution gap time is added to the boundary of the delay value interval to generate a dynamic delay compensation interval. The dynamic delay compensation interval is used to automatically disperse the delay trigger time in the case of uneven load or task concentration, thereby optimizing the balance of task execution. For example, if the original delay value interval is 50-100 milliseconds and the task distribution gap is 20 milliseconds, the dynamic delay compensation interval can be adjusted to 50-120 milliseconds.

[0088] In the dynamic delay compensation interval, a time point corresponding to a peak or a trough of the system clock can be selected based on a clock jitter period corresponding to a current system timestamp to determine a new delay sampling point. The time point corresponding to the peak or the trough can be used to avoid task trigger errors caused by system time jitter and improve the stability of the delay trigger time.

[0089] Finally, a time offset corresponding to the new delay sampling point is determined as a random delay value and replaces the original candidate delay value. The new random delay value can be recorded together with the load level label and the task timestamp for subsequent delay scheduling and test task issuance. For example, the new delay sampling point is added to the current time to obtain a revised delay trigger time, thereby realizing dynamic and adjustable delay allocation.

[0090] In some embodiments, the above steps can be cyclically executed until the verification result meets the preset delay constraint condition, thereby ensuring that the test tasks of each terminal are triggered uniformly under the premise of meeting the load constraint and time distribution requirements.

[0091] Preferably, in the dynamic delay compensation interval, selecting a time point corresponding to a peak or a trough of the current system clock based on a clock jitter period corresponding to the system timestamp comprises:

[0092] determining a phase position of the current system clock according to the clock jitter period corresponding to the system timestamp;

[0093] when the phase position of the system clock is in the rising edge to peak interval, the time point corresponding to the peak is selected as the priority candidate trigger point; when the phase position of the system clock is in the falling edge to trough interval, the time point corresponding to the trough is selected as the backup candidate trigger point;

[0094] in the priority candidate trigger point and the backup candidate trigger point, a time point most balanced in system task load distribution is selected according to the time coverage ratio of the dynamic delay compensation interval;

[0095] the selected time point is selected as the new delay sampling point.

[0096] In an embodiment, the phase position of the current system clock can be determined according to the clock jitter period corresponding to the system timestamp, which is used to represent the specific stage of the current system clock in its periodic fluctuations, so as to determine the corresponding relationship between the current triggering time and the clock waveform.

[0097] When the phase position of the system clock is in the interval from the rising edge to the peak, the time point corresponding to the peak can be used as the preferred candidate trigger point to trigger the delay using the most stable stage of the system clock. Conversely, when the phase position of the system clock is in the interval from the falling edge to the valley, the time point corresponding to the valley can be used as the backup candidate trigger point to provide an alternative trigger opportunity when the preferred trigger point is unavailable or conflicts.

[0098] Subsequently, among the preferred candidate trigger point and the backup candidate trigger point, the time point with the most balanced system task load distribution can be selected according to the time coverage ratio of the dynamic delay compensation interval, and the selection process can be used to ensure that each test task is evenly distributed within the entire load interval, avoiding the concentration of multiple tasks to cause load peaks.

[0099] Finally, the selected time point is recorded as a new delay sampling point. The new delay sampling point can be used to generate a random delay value and to trigger the test task of the notebook computer terminal to achieve dynamic optimization and balance of delay allocation.

[0100] Preferably, the method further comprises the following steps before sorting and testing each notebook computer terminal through the delay scheduling data:

[0101] Performing a fast signal detection operation on each notebook computer terminal through the delay scheduling data to obtain the channel occupancy rate of each notebook computer terminal;

[0102] If the channel occupancy rate is higher than the preset occupancy threshold, the test time of the corresponding notebook computer terminal is automatically delayed, and the delay reason is reported to the remote centralized management end.

[0103] In an embodiment, a fast signal detection operation can be performed on each notebook computer terminal according to the delay scheduling data to obtain the channel usage state of the current terminal. The fast signal detection operation can include: sending a detection trigger signal to the corresponding wireless interface of each notebook computer terminal when starting a short detection mode; recording the receiving feedback after sending the detection trigger signal, including signal delay, interference noise, and response strength of occupied channel; calculating the channel occupancy rate of each terminal based on the amplitude and response time of the feedback signal, and generating a channel occupancy rate data set.

[0104] The acquired channel occupancy data is compared with a preset occupancy threshold. The occupancy threshold can be set according to network load capacity or test environment, for example, can be set to 70% to 85%. When it is detected that the channel occupancy of a notebook terminal is higher than the preset threshold, the following operations are performed: automatically delaying the test trigger time of the terminal to the next available time window; updating the delay scheduling data, and recording the delay time, delay reason and terminal identification information as a delay log; reporting the delay log to the remote centralized management end, including the delay start time, delay duration, channel occupancy value and terminal identification information.

[0105] After the delay adjustment, the delay trigger time of all terminals is corrected and sorted to ensure that each notebook terminal is sorted for testing when the channel occupancy is lower than the threshold, thereby reducing the influence of channel interference on the test results.

[0106] In some embodiments, the test task in a multi-terminal environment can be dynamically optimized by repeating the fast signal detection and delay adjustment operations. After each delay adjustment, the sorting test sequence is regenerated to ensure that the test task is executed in the optimal time window in sequence, and the load balancing and signal quality stability of each terminal are maintained.

[0107] Preferably, the test recovery module comprises:

[0108] According to the interruption position, the resumption starting point is determined;

[0109] According to the interruption position, the resumption starting point is determined;

[0110] During the resumption process, the state and running data of each test item are recorded in real time, and they are corresponded to the interruption position to generate a resumption data set;

[0111] After the resumption is completed, the resumption data set and the interruption information are integrated to obtain a test result data packet;

[0112] The test result data packet is uploaded to the remote centralized management end through the communication interface.

[0113] In an embodiment, the index information of the current unfinished test item is obtained according to the interruption time or the interruption position; the interruption position is analyzed to identify the completion state and the last recorded running data of each test item; and the resumption starting point, i.e. the first test item that needs to be re-executed or continued to execute from the interruption position, is determined.

[0114] The resuming test task list is generated according to the resuming starting point, including the task number, parameter setting and priority of each test item; the resuming test task is loaded to the test scheduling module, and the unfinished WLAN test items are executed in sequence according to the task list; the parameters of the test items are checked before the task execution, to ensure that the parameters are consistent with the parameters before the interruption.

[0115] During the resuming test, the state information of each test item is collected in real time, including the completion state, signal quality, delay, packet loss rate and other running data; the collected running data is corresponded to the interruption position, to generate a resuming test data record table; the test items with abnormality or interruption again are marked, and the subsequent test sequence or delay is automatically adjusted, to ensure the integrity of the resuming test task. After the resuming test is completed, the resuming test data set is compared and integrated with the original interruption information; the data is merged according to the test item sequence and time stamp, to form a complete test result data package, to ensure the continuity and accuracy of the test result.

[0116] The integrated test result data package is sent to the remote management end through the communication interface; during the uploading process, the uploading log can be generated, to record the data package sending time, size and receiving confirmation state; if the uploading fails, the retransmission mechanism is started until the confirmation is successful, to ensure the reliability and integrity of the test result.

[0117] Preferably, the interruption information acquisition method comprises: obtaining the interruption information through the task state log recorded by the notebook computer terminal in real time during the resuming test, wherein the interruption information comprises the interruption time, the task interruption position, the trigger reason, the completed test item state and the related system running state.

[0118] In an embodiment, the notebook computer terminal records the operation of the terminal and the task execution state in real time by continuously monitoring the task state log during the execution of the delay scheduling test task. The task state log is used to provide the time sequence information of the task running, including the start time, end time and execution state of each test item.

[0119] When the test task is interrupted due to abnormal events, user operation or external environmental factors, the notebook computer terminal records the interruption information in the log. The interruption information includes but is not limited to: the interruption time, i.e. the specific time point when the task is stopped; the task interruption position, i.e. the specific execution node in the test flow or test sequence; the trigger reason, such as too high load, network interruption, user manual stop or system abnormality; the completed test item state, including the test item list and the results of the test items successfully executed before the interruption; and the related running state information, such as CPU usage, memory occupation and power state.

[0120] In some embodiments, the step of obtaining the interruption information comprises: extracting the timestamps and task node information related to the interruption from the task state log; analyzing the log records to determine the execution position and completion status at the time of task interruption; combining the terminal running monitoring data to determine the interruption trigger cause; and forming a set of interruption information data including the interruption time, task interruption position, trigger cause, completed test item status and related running status, for subsequent task recovery, delay adjustment or scheduling optimization.

[0121] In preferred embodiments, the notebook terminal can store the interruption information associated with the task identification and timestamps immediately after each interruption event occurs, thereby ensuring the integrity and traceability of the interruption information. At the same time, a log caching mechanism can be set up to ensure that the interruption information is not lost even if the terminal is temporarily disconnected from the network.

[0122] Preferably, the interruption continuous measurement of the notebook computer according to the interruption position comprises:

[0123] identifying the test task phase corresponding to the interruption position and the completed test items;

[0124] calling the task state parameters before the interruption from the local cache and restoring the test environment configuration through the task state parameters;

[0125] continuing to execute the WLAN test task instructions from the interruption position based on the test task phase and the completed test items using the test environment configuration until all test items are completed, obtaining the final test results.

[0126] In an embodiment, when the notebook terminal detects the interruption of the test task, the test task can be continuously measured according to the interruption position in the interruption information. The interruption position corresponds to the specific phase of the test task execution before the interruption and the completed test item information.

[0127] In preferred embodiments, the continuous measurement operation comprises the following steps: first, identifying the test task phase corresponding to the interruption position and obtaining the list of completed test items before the interruption to determine the starting point of the continuous measurement; second, calling the task state parameters recorded before the interruption from the local cache, including the current load level, delay scheduling data, test environment configuration parameters and related system state information, for restoring the test environment before the interruption;

[0128] Then, using the restored test environment configuration, the notebook terminal continues to execute the subsequent WLAN test task instructions from the interruption position based on the test task phase and the completed test items, ensuring seamless continuation of the task from the correct phase; during the continuous measurement process, the terminal can continue to record the task state log for tracking and recovery of the next interruption;

[0129] In some embodiments, when the resuming is completed, the notebook computer terminal aggregates the test items completed before the interruption and the test items completed after the resuming to generate a final test result data set for subsequent test analysis, performance evaluation or delay scheduling optimization.

[0130] Especially important is that the interruption detection of the test instruction according to the user activity state further includes:

[0131] Real-time monitoring of user activity state information of the notebook computer, wherein the user activity state information includes keyboard input, touchpad operation, screen focus switching and system foreground activity indication;

[0132] When any user activity behavior is detected, determining whether the activity conflicts with the current test task;

[0133] If it is determined that there is a conflict, triggering a test interruption flag immediately and recording the execution position of the current test task and the system time to generate interruption position information;

[0134] If the user activity lasts more than a preset time, suspending the execution of subsequent test instructions and entering an interruption waiting to resume state;

[0135] When the user activity ends and the system returns to an idle state, updating the interruption detection record.

[0136] In an embodiment, to prevent the operations performed by the user during the execution of the WLAN test task of the notebook computer from interfering with the accuracy of the test result, the test instruction is interrupted according to the user activity state.

[0137] Preferably, the interruption detection process includes the following steps: first, the notebook computer terminal real-time monitors user activity state information. The user activity state information includes keyboard input signals, touchpad operation signals, screen focus switching events and system foreground activity indication information, which are used to reflect the current interactive behavior characteristics of the user.

[0138] When any user activity behavior is detected, the notebook computer terminal performs correlation analysis on the activity to determine whether the activity conflicts with the test task being executed. For example, when the user switches to a non-test interface, performs system update or opens a high-load application, it can be determined that there is a conflict.

[0139] When the detection result indicates that there is a conflict, the terminal triggers a test interruption flag immediately and records the execution position of the current test task and the system time in real time to generate interruption position information, so as to perform interruption recovery operation of the test task subsequently.

[0140] Further, when the user activity duration is detected to exceed the preset time threshold, the notebook terminal automatically suspends the execution of the subsequent test instructions and enters an interrupted state to be resumed, so as to prevent false test or data interference during the continuous user operation.

[0141] When the system detects that the user activity ends and the notebook computer reenters the idle state, the terminal updates the interruption detection record and resumes the execution of the test task according to the interruption position information, so as to ensure the continuity and data validity of the WLAN test process. Through the above embodiment, potential interference behaviors can be dynamically detected when the user activity and the automated test task are parallel, and the test state can be interrupted and recorded in time, so that the test abnormality or result deviation caused by the user operation can be effectively avoided, and the accuracy and controllability of the test task are ensured.

[0142] Especially importantly, determining whether the activity conflicts with the current test task specifically includes:

[0143] performing event type identification on the user activity state information, obtaining input event, system call or network request information corresponding to the activity and integrating the information into activity information;

[0144] matching and analyzing the activity information with the WLAN test task instructions being executed at present;

[0145] if it is detected that the activity information involves the same system resource, interface call or data write channel as the test task, it is determined that the activity conflicts with the test task, otherwise, it is determined that the activity is not a conflict activity.

[0146] In an embodiment, to improve the accuracy of interruption detection, event level analysis can be performed on the user activity state information to determine whether the activity conflicts with the current test task.

[0147] Preferably, after detecting the user activity state information, the notebook terminal first performs event type identification on the information. The event type identification can be implemented based on a system event monitoring module, and is used to distinguish whether the user activity belongs to a keyboard input event, a touchpad operation event, a system call event or a network request event. Through classification of the event type, input event data, system call identifier and network request content corresponding to the activity can be extracted.

[0148] Subsequently, the terminal integrates the extracted input event, system call and network request information to form activity information. The activity information is used to describe the operation characteristics of the user behavior on the system level, including the process name, target interface, resource occupation type and timestamp and the like.

[0149] After obtaining the activity information, the terminal matches and analyzes it with the WLAN test task instruction currently being executed. The matching and analyzing includes comparing the system resources, interface calls and data channels involved in the activity information with the resource configuration table used in the test task. When it is detected that the activity information and the test task share the same system resource, interface call or data write channel, it indicates that the user operation can interfere with the test process.

[0150] If the comparison result shows that the activity information involves the same system resource, interface call or data write channel as the test task, the terminal determines that the activity and the current test task have operation conflict, and triggers the interruption flag in time to abort the execution of the subsequent test instruction; otherwise, if the activity information does not involve the above-mentioned resource overlap, it is determined as non-conflict activity, and the test task continues to be executed. Through the above-mentioned implementation, the user activity conflict judgment based on event level analysis can be realized, the interruption detection no longer depends on single behavior trigger, but is based on the comprehensive judgment of the resource layer, the interface layer and the data layer, thereby effectively preventing the user behavior from causing implicit interference to the test process, and improving the stability and reliability of the test task execution.

[0151] Therefore, from any viewpoint, the embodiments should be considered as exemplary and non-limiting, the scope of the present application being defined by the appended claims and not by the above description, and all changes falling within the meaning and range of equivalency of the elements of the claimant file are intended to be embraced therein.

[0152] The above description is merely one specific implementation of the present application, which enables those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to these embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A system for remotely and centrally managing laptops for WLAN testing, characterized in that, Includes the following steps: The test delivery module is used to send unified WLAN test task instructions to several laptop terminals through a remote centralized management terminal. The test task instructions include the target network identifier, test duration and delay window parameters. The latency testing module is used to generate a random latency value for each laptop terminal based on the current system load status after receiving the test task instruction. The random latency value is limited to the latency window parameter. Based on the random latency value, each laptop terminal is sorted and tested to obtain the test instruction. The status monitoring module is used to obtain the user activity status based on the test command; to detect the interruption of the test command according to the user activity status; when the user activity status is detected, the current WLAN test is automatically paused and the test interruption position is recorded in the local cache. The test recovery module is used to resume interrupted testing of the laptop based on the interruption location, obtain the final test results and upload them along with the corresponding interruption information to the remote centralized management terminal.

2. The system for remotely and centrally managing a laptop computer for WLAN testing according to claim 1, characterized in that, The latency testing module includes: Upon receiving the test task instruction, obtain the current system load status data of the laptop terminal; The load level of the laptop terminal is determined based on the current system load status data, and the load level is recorded as a load level label; Based on the load level, read the delay value range corresponding to the load level from the preset delay range table; A random delay value is generated within the delay range, and the random delay value, along with the corresponding load level label and timestamp, is recorded as delay scheduling data. Each laptop terminal is sorted and tested using delayed scheduling data to obtain test instructions.

3. The system for remotely and centrally managing a laptop computer for WLAN testing according to claim 2, characterized in that, Generating random delay values ​​within the delay value range includes: The minimum and maximum delay thresholds are determined based on the delay value range; A delay sampling point is randomly selected between the minimum delay threshold and the maximum delay threshold, where the delay sampling point corresponds to a candidate delay value; The candidate delay value is combined with the current system time to form the delay trigger time; Availability verification is performed on the delayed trigger time. When the verification result meets the preset delay constraints, the candidate delay value is confirmed as the final random delay value.

4. The system for remotely and centrally managing a laptop computer for WLAN testing according to claim 3, characterized in that, Combining the candidate delay values ​​with the current system time to form the delay trigger times includes: Obtain the system timestamp, which represents the current system clock state of the laptop terminal; The candidate delay value is summed with the system timestamp to obtain the initial calculated value at the delay trigger time; The initial calculated value is corrected by system clock synchronization to obtain the corrected delayed trigger time, and the corrected delayed trigger time is recorded as the delayed trigger time.

5. The system for remotely and centrally managing a laptop computer for WLAN testing according to claim 3, characterized in that, Availability verification is performed on the delayed trigger time. When the verification result does not meet the preset delay constraints, the method for obtaining the random delay value also includes: Determine the current task distribution interval time based on the delayed trigger time and the task queue time distribution of the test task instructions; The task distribution interval time is superimposed onto the boundary of the delay value range to obtain the dynamic delay compensation range, which is used to automatically distribute the trigger time when the system load is uneven. Within the dynamic delay compensation interval, a new delay sampling point is determined by selecting the time point corresponding to the peak or trough of the current system clock through the clock jitter period corresponding to the system timestamp. The time offset corresponding to the new delayed sampling point is determined as a random delay value.

6. The system for remotely and centrally managing a laptop computer for WLAN testing according to claim 5, characterized in that, Within the dynamic delay compensation interval, the time point corresponding to the peak or trough of the current system clock is selected by using the clock jitter period corresponding to the system timestamp, including: The current phase position of the system clock is determined based on the clock jitter period corresponding to the system timestamp; When the phase position of the system clock is in the rising edge to peak interval, the time point corresponding to the peak is taken as the priority candidate trigger point; when the phase position of the system clock is in the falling edge to trough interval, the time point corresponding to the trough is taken as the backup candidate trigger point. Among the priority candidate trigger points and the backup candidate trigger points, the time point that is most balanced with the system task load distribution is selected based on the time coverage ratio of the dynamic delay compensation interval. Use the selected time point as the new delayed sampling point.

7. The system for remotely and centrally managing a laptop computer for WLAN testing according to claim 2, characterized in that, Before performing sorting tests on each laptop terminal using delayed scheduling data, the following steps are also included: By performing a fast signal detection operation on each laptop terminal using delayed scheduling data, the channel occupancy rate of each laptop terminal can be obtained. If the channel occupancy rate is higher than the preset occupancy rate threshold, the test time for the corresponding laptop terminal will be automatically delayed, and the reason for the delay will be reported to the remote centralized management terminal.

8. The system for remotely and centrally managing a laptop computer for WLAN testing according to claim 1, characterized in that, The test recovery module includes: Determine the starting point for continuation of the test based on the location of the interruption; Initialize the continuation test task based on the interruption location, and execute the incomplete WLAN test items according to the start point of the continuation test; During the continued testing process, the status and running data of each test item are recorded in real time and mapped to the interruption location to generate a continued testing dataset; After the continued testing is completed, the continued testing dataset and the interruption information are integrated to obtain the test result data packet; The test result data packet is uploaded to the remote centralized management terminal through the communication interface.

9. The system for remotely and centrally managing a laptop computer for WLAN testing according to claim 7, characterized in that, The methods for obtaining interruption information include: obtaining interruption information through the task status log recorded in real time during the continued testing process on a laptop terminal. The interruption information includes the interruption time, task termination location, triggering reason, status of completed test items, and related system operating status.

10. The system for remotely and centrally managing a laptop computer for WLAN testing according to claim 1, characterized in that, The interruption resumption test for the laptop based on the interruption location includes: Identify the test task phase and completed test items corresponding to the interruption location; The task status parameters before the interruption are retrieved from the local cache, and the test environment configuration is restored using the task status parameters. The test environment is configured to continue executing WLAN test task instructions from the interrupted position based on the test task stage and completed test items until all test items are completed, and the final test results are obtained.

Images