Dynamic load perception and early warning method and device based on operation behavior

Abstract

The application aims to provide a dynamic load sensing and early warning method and device based on operation behavior. A non-sensing operation behavior flow pipeline is constructed by a behavior collection agent and a behavior flow processing engine to realize fine-grained and non-intrusive observation on a test execution process. A coupling calculation mechanism of a multi-bit feature vector and a dynamic load index is combined with a weight-adjustable behavior feature to form an adaptive load evaluation model. Through a linkage design of a warning and scheduling interface and task allocation of a test management system, a closed-loop intervention from state sensing to resource scheduling is realized.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and device for dynamic load sensing and early warning based on operational behavior. Background Technology

[0002] In current software engineering practices, Test Case Management Systems (TCMS) are core tools for ensuring software quality, typically integrating modules for test case writing, review, task allocation, execution status tracking, and report generation. Typical systems such as TestRail, Zephyr, and PingCode assign test tasks to designated personnel through a user interface and rely on manual marking of statuses like "starting execution," "blocked," and "completed" to reflect progress. The system backend records the number of assigned tasks, estimated working hours, and completion rate, serving as the primary basis for load assessment. However, existing technologies still have the following technical shortcomings: Load assessment is based solely on the number of static tasks or preset working hours, without considering differences in use case complexity and actual progress during execution, which leads to overestimation or underestimation of the actual workload. Once a tester marks a test case status as "in execution," the system stops perceiving the execution details and cannot identify prolonged pauses caused by environmental failures, missing dependencies, or ambiguous test cases, thus creating a black box of execution status. Problem feedback relies on manual reporting and lacks an automated anomaly detection mechanism. Managers need to conduct frequent manual inspections, which is inefficient and prone to overlooking key risks. The testers' individual ability characteristics (such as skill preferences, operating rhythm, and focus patterns) were not modeled, and the task allocation adopted uniform rules, making it difficult to achieve optimized matching between people and positions. Summary of the Invention

[0003] One objective of this application is to provide a dynamic load perception and early warning method and device based on operational behavior. Through a seamless operational behavior flow pipeline jointly constructed by a behavior acquisition agent and a behavior flow processing engine, fine-grained and non-intrusive observation of the test execution process is achieved. Based on the coupling calculation mechanism of multi-bit feature vectors and dynamic load index, combined with the adjustable weights of each behavioral feature, an adaptive load assessment model is formed. Through the linkage design of early warning and scheduling interfaces with the task allocation of the test management system, closed-loop intervention from state perception to resource scheduling is realized.

[0004] According to one aspect of this application, a dynamic load sensing and early warning method based on operational behavior is provided, wherein the system includes: A dynamic load perception and early warning method based on operational behavior, comprising: a behavior acquisition agent deployed in the front-end page of the test management system, and a behavior flow processing engine, a load status classification model, and an early warning and scheduling interface deployed in the back-end server or independent microservice node of the test management system, wherein the method includes: The behavior acquisition agent captures in real time the data stream corresponding to all operational behavior events of each tester during the execution of test tasks; The behavior stream processing engine receives the data streams pushed by at least two behavior acquisition agents, and performs time window aggregation and feature extraction on the data streams corresponding to all the operation behavior events of each tester according to the anonymous session ID of the tester, so as to obtain the behavior feature vector corresponding to each time window of each tester in at least two time windows. The behavioral feature vector corresponding to each time window of each of the at least two time windows is input into the load state classification model for state identification, so as to obtain the load state label and dynamic load index of each of the at least two time windows for each of the testers. The early warning and scheduling interface determines whether the tester's operation meets the preset early warning conditions based on the load status label and dynamic load index of each tester in at least two time windows. If so, the warning and scheduling interface generates a structured warning message and pushes it to the project manager's instant messaging tool; at the same time, it calls the task allocation API of the test management system to suspend the allocation of new tasks to testers who have reached the preset warning conditions, until the operation of the testers who have reached the preset warning conditions returns to the time when the preset warning conditions are lifted.

[0005] Furthermore, in the above method, the behavior acquisition agent captures in real time the data stream corresponding to all operational behavior events of each tester during the execution of the test task, including: The behavior acquisition agent captures raw data in real time corresponding to all operational behavior events of each tester during the execution of test tasks; Local anonymization processing is performed on the original data corresponding to all the aforementioned operation behavior events, removing user identity information and adding anonymous session IDs and timestamps to obtain the data stream corresponding to all the operation behavior events of each of the testers, wherein the data stream is in encrypted format.

[0006] Furthermore, in the above method, the operational event includes at least one of the following: Test case details page open / close event; Test step submission event; Log query click events; Page tab switching event; Mouse idle event.

[0007] Further, in the above method, the behavior stream processing engine receives data streams pushed by at least two behavior acquisition agents, and performs time window aggregation and feature extraction on the data streams corresponding to all operational behavior events of each tester according to the anonymous session ID of the tester, to obtain the behavior feature vector corresponding to each time window of each of the at least two time windows, including: The behavior stream processing engine receives data streams corresponding to all operational behavior events of each tester during the execution of a test task, pushed by at least two of the behavior collection agents. The behavior stream processing engine splits the data streams corresponding to all the operation behavior events of each tester according to the anonymous session ID of the tester, and aggregates all the operation behavior events of each tester within a time window with a preset time window as the sliding window length. Extract the behavioral features of each tester in each of the at least two time windows from the corresponding data stream to obtain the behavioral feature vector of each tester in each of the at least two time windows. The behavioral characteristics include: task switching frequency, execution focus, and debugging intensity. The task switching frequency is used to indicate the number of page switches for different test cases per unit time. The execution focus is used to indicate the proportion of effective operation time to the total window time. The debugging intensity is used to indicate the weighted combination of log query frequency and mouse idle time.

[0008] Furthermore, in the above method, the load state classification model is a lightweight neural network model, wherein the input layer receives the behavioral feature vector corresponding to each time window of each of the testers in at least two time windows; The hidden layer adopts a two-layer fully connected structure. The first hidden layer contains 16 neurons, and the second hidden layer contains 8 neurons. The activation function used for both layers is ReLU. The output layer contains four types of load states, corresponding to: high-efficiency execution, environment congestion, frequent switching, and inefficient operation, and synchronously outputs dynamic load indices.

[0009] Furthermore, in the above method, the formula for calculating the dynamic load index is: DLI = w1·f_switch + w2·(1 f_focus) + w3·f_debug, Where f_switch is the value of task switching frequency, f_focus is the value of execution focus, and f_debug is the value of debugging intensity; w1, w2, and w3 are the weights of task switching frequency, execution focus, and debugging intensity, respectively, and all of them are adjustable.

[0010] Furthermore, in the above method, the early warning and scheduling interface determines whether the tester's operation meets the preset early warning conditions based on the load status label and dynamic load index of each tester in at least two time windows. If so, the early warning and scheduling interface generates a structured early warning message, including: The warning and scheduling interface performs threshold judgment on the dynamic load index: if a tester's load status index exceeds the preset first index threshold for two consecutive time windows, it is considered a high load risk; simultaneously, The warning and scheduling interface determines the duration of the status: if a tester's load status label is "environmental blockage" and the duration of the environmental blockage exceeds the preset duration, it is considered that the execution is blocked, wherein the preset duration is at least two consecutive time windows. If a high load risk and / or execution obstruction are met, the warning and scheduling interface generates a structured warning message, which includes the tester's anonymous session ID, the current value of the load status index, the load status label, a list of test case IDs involved, and the duration.

[0011] Furthermore, the above method further includes: The time when the preset warning condition is lifted is used to indicate the moment when the dynamic load index of the tester falls back to the preset second index threshold and the load status label changes to high efficiency execution in a subsequent time window, wherein the second index threshold is less than the first index threshold.

[0012] According to another aspect of this application, a non-volatile storage medium is also provided, on which computer-readable instructions are stored, which, when executed by a processor, cause the processor to implement the above-described dynamic load sensing and early warning method based on operational behavior.

[0013] According to another aspect of this application, a dynamic load sensing and early warning device based on operational behavior is also provided, wherein the device includes: One or more processors; Computer-readable medium for storing one or more computer-readable instructions. When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors enable dynamic load perception and early warning based on operational behavior as described above.

[0014] Compared with existing technologies, this application uses behavior acquisition agents deployed in the front-end page of the test management system to capture in real time the data streams corresponding to all operational behavior events of each tester during the execution of test tasks; the behavior stream processing engine receives the data streams pushed by at least two of the behavior acquisition agents, and performs time window aggregation and feature extraction on the data streams corresponding to all operational behavior events of each tester according to the anonymous session ID of the tester, to obtain the behavior feature vectors corresponding to each time window of each of the at least two time windows for each tester; the behavior feature vectors corresponding to each time window of each of the at least two time windows for each tester are input into the load state classification model for further processing. The system identifies the load status of each tester within at least two time windows, obtaining their load status label and dynamic load index. The early warning and scheduling interface, based on these labels and indexes, determines whether the tester's actions meet preset early warning conditions. If so, the interface generates a structured early warning message and pushes it to the project manager's instant messaging tool. Simultaneously, it calls the task allocation API of the test management system to pause the allocation of new tasks to testers meeting the preset early warning conditions, until their actions return to the point where the conditions are lifted. In this application, a seamless operation behavior flow pipeline, collaboratively constructed by a behavior acquisition agent and a behavior flow processing engine, enables fine-grained, non-intrusive observation of the test execution process. An adaptive load assessment model is formed based on a coupled computation mechanism of multi-bit feature vectors and dynamic load indices. Furthermore, the linkage design between the early warning and scheduling interface and the task allocation of the test management system achieves closed-loop intervention from status awareness to resource scheduling. Attached Figure Description

[0015] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A flowchart illustrating a dynamic load sensing and early warning method based on operational behavior according to one aspect of this application is shown. Figure 2 A schematic diagram of the overall architecture of a system for a dynamic load sensing and early warning method based on operational behavior according to one aspect of this application is shown. Figure 3This diagram illustrates the types of operational behavior events captured by the behavior acquisition agent in the front-end page of a test management system and their data flow in a dynamic load perception and early warning method based on operational behavior, according to one aspect of this application. Figure 4 This diagram illustrates the process of a behavior flow processing engine performing time window aggregation and three-dimensional behavior feature calculation on an operational behavior-based dynamic load perception and early warning method according to one aspect of this application. Figure 5 The diagram illustrates the structure and input-output relationship of a load state classification model in a dynamic load sensing and early warning method based on operational behavior, according to one aspect of this application. Figure 6 This diagram illustrates the linkage logic of the early warning and scheduling interface triggering early warning message push and task allocation intervention in a dynamic load perception and early warning method based on operational behavior, according to one aspect of this application. Detailed Implementation

[0016] The present application will now be described in further detail with reference to the accompanying drawings.

[0017] In a typical configuration of this application, the terminal, the device of the service network, and the trusted party all include one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0018] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0019] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0020] like Figure 1 As shown, Figure 1 The flowchart illustrates a dynamic load perception and early warning method based on operational behavior, as proposed in one aspect of this application. The method includes: a behavior acquisition agent deployed in the front-end page of a test management system; a behavior flow processing engine deployed in the back-end server or independent microservice node of the test management system; a load status classification model and an early warning and scheduling interface; and a front-end and back-end integration module with an existing test management system. A detailed overall architecture diagram is shown below. Figure 2 As shown.

[0021] In terms of hardware, Figure 2 One aspect of this application proposes a system architecture for a dynamic load perception and early warning method based on operational behavior. This architecture comprises four core modules: a behavior acquisition agent, a behavior flow processing engine, a load status classification model, and an early warning and scheduling interface. Each module integrates with the existing test management system's front-end page and back-end services via standard network protocols, forming a closed-loop dynamic perception and intervention mechanism. Specifically, the behavior acquisition agent is deployed in the test management system's web front-end page, embedded as a lightweight JavaScript script, without relying on any client plugins or local installation programs. The behavior flow processing engine, load status classification model, and early warning and scheduling interface are all deployed on the test management system's back-end server or independent microservice nodes, communicating with the main system through an internal API gateway.

[0022] Regarding the implementation logic, in Figure 1 In this application, one aspect of a dynamic load sensing and early warning method based on operational behavior includes steps S101, S102, S103, S104, and S105, specifically including the following steps: Step S101: The behavior acquisition agent captures in real time the data stream corresponding to all operational behavior events of each tester during the execution of the test task; Step S102: The behavior stream processing engine receives the data streams pushed by at least two behavior acquisition agents, and performs time window aggregation and feature extraction on the data streams corresponding to all operation behavior events of each tester according to the anonymous session ID of the tester, so as to obtain the behavior feature vector corresponding to each time window of each of the at least two time windows. Step S103: Input the behavioral feature vector of each tester in each of the at least two time windows into the load state classification model for state identification, and obtain the load state label and dynamic load index of each tester in each of the at least two time windows. Step S104: The early warning and scheduling interface determines whether the tester's operation meets the preset early warning conditions based on the load status label and dynamic load index of each tester in at least two time windows. If so, then proceed to step S105, wherein in step S105, the warning and scheduling interface generates a structured warning message and pushes it to the project manager's instant messaging tool; at the same time, the task allocation API of the test management system is called to suspend the allocation of new tasks to testers who have reached the preset warning conditions, until the operation of the testers who have reached the preset warning conditions returns to the time when the preset warning conditions are lifted.

[0023] If not, the alarm will not be triggered, and the processing flow from step S101 to step S104 will continue.

[0024] Through steps S101 to S105 above, a seamless operation behavior flow pipeline is constructed through the collaborative construction of behavior acquisition agent and behavior flow processing engine, enabling fine-grained and non-intrusive observation of the test execution process; an adaptive load assessment model is formed based on the coupled calculation mechanism of multi-bit feature vector and dynamic load index; and a closed-loop intervention from state perception to resource scheduling is realized through the linkage design of early warning and scheduling interface with task allocation of test management system.

[0025] Continuing with the above embodiments of this application, step S101, in which the behavior acquisition agent captures in real time the data stream corresponding to all operational behavior events of each tester during the execution of the test task, specifically includes: The behavior acquisition agent captures raw data in real time corresponding to all operational behavior events of each tester during the execution of test tasks; Local anonymization processing is performed on the original data corresponding to all the aforementioned operation behavior events, removing user identity information and adding anonymous session IDs and timestamps to obtain the data stream corresponding to all the operation behavior events of each of the testers, wherein the data stream is in encrypted format.

[0026] The behavior capture agent is embedded in the web front-end of the test management system as a JavaScript script. By listening to DOM events and browser APIs, it captures raw data corresponding to all the operational behavior events of testers during the execution of test tasks in real time. The raw data of these operational behavior events includes: the timestamps of opening and closing the test case details page, the time interval between test step submissions, the click frequency of the log query button, the number of page tab switching times, and the idle time when the mouse stops moving for more than 5 seconds (or other time intervals). The raw data corresponding to all the testers' operational behavior events is locally anonymized by the behavior capture agent. User identity information is removed, and an anonymous session ID and timestamp are added. This data is then encrypted using the WebSocket protocol to obtain the data stream corresponding to all the testers' operational behavior events, and sent to the behavior stream processing engine as encrypted streaming data packets.

[0027] In a preferred embodiment of this application, based on a real-world application scenario where a software company uses PingCode as its test case management system (TCMS), the structural relationships, data flow, processing logic, and collaborative working mechanisms of the various components of the system are described in detail: During the deployment process, the behavior collection agent injects data into the `<behavior>` tag within the front-end HTML page of the test management system. <script>标签实现加载。

[0028] 该脚本注册多个浏览器事件监听器，包括window.onbeforeunload、document.addEventListener('visibilitychange')、document.body.addEventListener('click')、和，document.body.addEventListener('mousemove')等，用于捕获测试人员在执行测试任务过程中的给类操作行为。如图3所示，行为采集代理所捕获的操作行为事件具体包括以下至少任一项：测试用例详情页打开 / 关闭事件（通过监听页面URL变化及窗口可见性状态判断）；测试步骤提交事件（监听表单提交按钮点击或键盘回车事件）；日志查询点击事件（监听特定CSS类名或ID的日志查询按钮的click事件）；页面标签切换事件（通过document.visibilityState API检测用户是否切换至其他浏览器标签页）；鼠标空闲事件（通过mousemove事件的时间戳差值判断，若连续5秒无移动则记录为空闲事件）。

[0029] 所有操作行为事件的原始数据在本地经过脱敏处理，移除用户真实的身份信息（如姓名、邮箱等），仅保留匿名会话ID和时间戳，并通过WebSocket协议以加密JSON格式实时推送至行为流处理引擎。

[0030] 接着本申请的上述实施例，所述步骤S102，行为流处理引擎接收至少两个所述行为采集代理推送的所述数据流，并按照测试人员的匿名会话ID对每个所述测试人员的所有的操作行为事件对应的数据流进行时间窗口的聚合和特征提取，得到每个所述测试人员在至少两个时间窗口中的每个时间窗口对应的行为特征向量，具体包括：所述行为流处理引擎接收来自至少两个所述行为采集代理推送的每个所述测试人员在执行测试任务过程中的所有的操作行为事件对应的数据流；所述行为流处理引擎按照测试人员的匿名会话ID，对每个所述测试人员的所有的操作行为事件对应的数据流进行分流处理，并以预置的所述时间窗口为滑动窗口长度，对每个所述测试人员的所有的操作行为事件进行时间窗口的聚合；从对应的数据流中提取每个所述测试人员在至少两个时间窗口中的每个时间窗口对应的行为特征，以得到每个所述测试人员在至少两个时间窗口中的每个时间窗口对应的行为特征向量；其中，所述行为特征包括：任务切换频率、执行专注度和调试强度，其中，所述任务切换频率用于指示单位时间内不同测试用例的页面切换次数，所述执行专注度用于指示有效操作时长占窗口总时长的比例，调试强度用于指示日志查询频率与鼠标空闲时长的加权组合。

[0031] 需要说明的是，所述时间窗口可以是任意取值的时长，在本申请一优选实施例中，可以将所述时间窗口优选为5分钟，当然，其他取值的时长均可包含在本申请的保护范围内。

[0032] 在此，行为流处理引擎部署于测试管理系统的后端服务器，接收来自多个行为采集代理的数据流。该行为流处理引擎以5分钟为滑动窗口长度，对每个测试人员的操作行为事件进行时间窗口聚合。在每个时间窗口内，计算多维的行为特征：任务切换频率（f_switch）定义为单位时间内不同测试用例页面切换次数；执行专注度（f_focus）定义为有效操作时长（含步骤提交、日志查询）占窗口总时长的比例；调试强度（f_debug）定义为日志查询频率与鼠标空闲时长的加权组合。

[0033] 接着本申请的上述优选实施例，行为流处理引擎接收来自多个行为采集代理的数据流后，按测试人员的匿名会话ID对数据进行分流处理。如图4所示，该行为流处理引擎以分钟为滑动时间窗口，采用Flink或Kafka Streams等流处理框架对每个测试人员的操作行为事件进行时间窗口聚合。在每个时间窗口内，行为流处理引擎依次计算三项行为特征：任务切换频率（f_switch）定义为该时间窗口内不同测试用例详情页的打开次数减一（即页面切换次数）除以窗口时长（单位：次 / 分钟）；执行专注度（f_focus）定义为有效操作时长占窗口总时长的比例，有效操作时长包括但不限于测试步骤提交事件的持续时间（从页面打开到提交的时间段，若未提交则不计入）、日志查询点击事件发生时的活跃时段，以及排除页面标签切换事件和鼠标空闲事件所标识的非活跃时段；调试强度（f_debug）定义为日志查询点击事件的频率（单位时间内点击次数）与鼠标空闲事件的累计时长（单位：秒）的加权组合，权重分别初始设为0.6和0.4，后续可由在线学习机制调整。上述三项行为特征的特征值经归一化处理后，构成一个三维的行为特征向量 [f_switch, f_focus, f_debug]，作为负载状态分类模型的输入。

[0034] 接着本申请的上述实施例，所述负载状态分类模型为轻量级神经网络模型，其中，输入层接收每个所述测试人员在至少两个时间窗口中的每个时间窗口对应的行为特征向量；隐藏层采用两层全连接结构，第一层隐藏层包含16个神经元，第二层隐藏层包含8个神经元，激活函数均采用函数ReLU；输出层包含四种负载状态的类别节点，分别对应：高效执行、环境阻塞、频繁切换和低效操作，并同步输出动态负载指数。

[0035] 进一步地，所述动态负载指数DLI的计算公式为：DLI = w1·f_switch + w2·(1f_focus) + w3·f_debug，其中，f_switch为任务切换频率的取值，f_focus为执行专注度的取值，f_debug为调试强度的取值；w1、w2、w3依序分别为任务切换频率、执行专注度和调试强度的权重，且均可调。

[0036] 接着本申请的上述实施例，如图5所示，负载状态分类模型采用两层全连接神经网络结构，输入层接收每个所述测试人员在至少两个时间窗口中的每个时间窗口对应的三维的行为特征向量，第一隐藏层包含16个神经元，第二隐藏层包含8个神经元，激活函数均采用ReLU；输出层包含四个节点，分别对应高效执行、环境阻塞、频繁切换、低效操作四种负载状态标签，并同步输出一个标量值——动态负载指数（DLI）。其中，动态负载指数DLI的计算公式为：DLI = w1·f_switch + w2·(1f_focus) + w3·f_debug，其中，f_switch为任务切换频率的取值，f_focus为执行专注度的取值，f_debug为调试强度的取值；w1、w2、w3依序分别为任务切换频率、执行专注度和调试强度的权重，且均可调，将任务切换频率、执行专注度和调试强度的权重的初始值依序分别设为：0.3、0.4、0.3。

[0037] 该负载状态分类模型在训练阶段使用历史标注数据进行监督学习，历史标注数据来源于项目复盘会议中管理者对异常执行情况的确认记录。在运行阶段，负载状态模型每5分钟（时间窗口）接收一次来自行为流处理引擎的新的行为特征向量，输出当前的时间窗口的负载状态标签和动态负载指数DLI的当前值。

[0038] 在本实施例中，为使负载状态模型适应团队实际工作模式的变化，系统引入在线学习模块。该在线学习模块每24小时执行一次权重优化，以实现通过在线学习机制执行权重的更新：首先，从数据库中提取过去最近7天内所有的测试人员的动态负载指数的历史值及其对应测试任务的实际完成延迟（定义为实际完成时间减去计划完成时间，单位：小时）；然后，计算动态负载指数的历史值的DLI序列与延迟序列之间的皮尔逊相关系数；若计算到的皮尔逊相关系数低于预设相关系数阈值（可以是任意取值，在本申请一优选实施例中，将预设相关系数阈值优选为0.6，其他的任何取值也可以包含在本申请的保护范围之内），则触发权重更新流程。其中，权重更新采用梯度上升法，目标函数为最大化相关系数，通过反向传播调整w1、w2、w3的值，直至收敛或达到最大迭代次数；更新后的权重立即应用于后续的动态负载指数的计算，确保评估指标与实际工作负荷保持高度相关。

[0039] 接着本申请的上述实施例，所述预警与调度接口基于每个所述测试人员在至少两个时间窗口中的每个时间窗口的负载状态标签和动态负载指数，判断所述测试人员的操作是否达到预设预警条件，若是，所述预警与调度接口生成结构化预警消息，包括：所述预警与调度接口进行动态负载指数的阈值判断：若一测试人员的负载状态指数在连续两个时间窗口均超过预设的第一指数阈值，则视为高负载风险；同时，所述预警与调度接口进行状态持续时间判断：若一测试人员的负载状态标签为环境阻塞且环境阻塞的状态持续时间超过预设持续时长，则视为执行受阻，其中，所述预设持续时长为连续至少两个所述时间窗口；若满足高负载风险和 / 或执行受阻时，所述预警与调度接口生成结构化预警消息，其中，所述结构化预警消息包括测试人员的匿名会话ID、负载状态指数的当前值、负载状态标签、涉及的测试用例ID列表及持续时间。

[0040] 需要说明的是，所述第一阈值可以任意取值，在本申请一优选实施例中，将所述第一阈值优选为85，当然，其他的任意取值均可包含在本申请的保护范围内；所述第二阈值可以任意取值，但需保证第二阈值小于第一阈值，在本申请一优选实施例中，将所述第二阈值优选为70，当然，其他的任意取值均可包含在本申请的保护范围内。所述预设持续时长可以是至少两个时间窗口的长度，在本申请的优选实施例中，将所述预设持续时长优选为优选的时间窗口（五分钟）的6倍，即将所述预设持续时长优选为30分钟，当然，所述预设持续时长的其他任意时长的取值均可包含在本申请的保护范围内。

[0041] 接着本申请的上述优选实施例，当负载状态分类模型输出结果后，预警与调度接口开始执行判断逻辑。如图6所示，该预警与调度接口，首先，进行动态负载指数的阈值判断：若某测试人员的负载状态指数DLI的值连续两个时间窗口（即连续10分钟）超过预设的第一阈值：85，则视为高负载风险；其次，进行状态持续时间判断：若负载状态标签为环境阻塞且该环境阻塞的状态持续时间超过30分钟（即连续6个窗口均为环境阻塞），则视为执行受阻。若满足高负载风险和执行受阻中的任一条件时，预警与调度接口生成结构化预警消息，通过企业微信或Slack的Webhook API等方式推送至项目管理者的即时通讯工具，所述结构化预警消息包括测试人员的匿名会话ID、负载状态指数的当前值、负载状态标签、涉及的测试用例ID列表及持续时间。同时，该预警与调度接口调用测试管理系统提供的任务分配API，发送任务分配暂停指令，阻止系统向该测试人员分配新的测试任务。

[0042] 接着本申请的上述实施例，本申请的所述方法还包括：所述预设预警条件的解除时刻用于指示当测试人员在后续的时间窗口的动态负载指数回落至预设的第二指数阈值且负载状态标签变更为高效执行的时刻，其中，所述第二指数阈值小于所述第一指数阈值。例如，当后续时间窗口中动态负载指数的值回落至第二阈值：70以下且状态标签变更为高效执行时，预警与调度接口自动发送恢复指令，重新启用任务分配。

[0043] 在本申请的上述实施例中，在系统集成方面，行为采集代理与测试管理系统前端的交互通过DOM事件绑定实现，无需修改原系统业务逻辑；行为流处理引擎通过内网WebSocket服务与前端建立持久连接，确保低延迟数据传输；负载状态分类模型以Docker容器形式部署，通过gRPC接口接收特征向量并返回分类结果；预警与调度接口通过RESTfulAPI与测试管理系统的任务调度模块对接，使用OAuth 2.0协议进行身份认证。所有模块间的数据传输均采用TLS 1.3加密，行为数据存储于独立数据库，保留周期不超过30天，符合GDPR及企业隐私政策要求。

[0044] 在本申请一实际应用场景中的一优选实施例中，在实际运行中，假设测试人员A在上午10:00开始执行测试用例TC-1001，行为采集代理记录其打开详情页事件；10:02点击日志查询按钮两次，10:03提交测试步骤；10:05切换至TC-1002，10:07又切回TC-1001，期间有3次鼠标空闲事件（每次超过5秒）。在10:00–10:05的第一个时间窗口内，行为流处理引擎计算得f_switch=1（切换1次）、f_focus=0.7（有效操作3.5分钟 / 5分钟）、f_debug=0.5（日志点击2次+空闲15秒）；在10:05–10:10的第二个时间窗口内，f_switch=2、f_focus=0.4、f_debug=0.8。负载状态分类模型在第二个时间窗口输出动态负载指数DLI=0.3×2 + 0.4×(10.4) + 0.3×0.8 = 0.6 + 0.24 + 0.24 = 1.08（归一化后为92），负载状态标签为：频繁切换。由于动态负载指数在连续两个时间窗口>85，预警与调度接口在10:10触发预警消息推送，并发送任务分配暂停指令。项目经理收到通知后，可查看该测试人员A近期操作轨迹，判断是否因用例设计不清导致反复切换，进而介入协调或调整任务优先级。

[0045] 整个系统通过行为采集代理、行为流处理引擎、负载状态分类模型与预警与调度接口的紧密协作，实现了从操作行为捕获、特征提取、状态识别到预警干预的完整链路。各模块之间通过标准化接口连接，数据流向清晰，处理逻辑可追溯，且所有关键参数支持动态调整，确保系统在不同团队规模、项目类型和人员构成下均能稳定运行。

[0046] 在本申请一实际应用场景中的又一优选实施例中，某企业采用PingCode作为测试用例管理平台的敏捷开发项目中，测试团队每日需执行数百个涉及支付、风控与对账模块的测试用例。为解决传统负载评估失真与执行状态不可见的问题，将行为采集代理部署于PingCode前端页面。当测试人员B于工作日上午9:15打开测试用例TC-2045详情页时，行为采集代理通过监听页面URL变化及document.visibilityState状态，生成测试用例详情页打开事件；9:18其点击"查看日志”按钮两次以排查接口返回异常，行为采集代理捕获两次日志查询点击事件；9:20提交测试结果，触发测试步骤提交事件；期间因接听电话离开座位，鼠标连续7秒无移动，行为采集代理记录一次鼠标空闲事件；9:22切换至浏览器其他标签页查阅需求文档，行为采集代理通过visibilitychange API识别页面标签切换事件。上述所有的操作行为事件均在本地脱敏后，以加密JSON格式经WebSocket实时推送至行为流处理引擎。

[0047] 行为流处理引擎接收到测试人员B的该匿名会话ID对应的数据流后，按5分钟的时间窗口进行聚合处理。在9:15–9:20的时间窗口内，行为流处理引擎统计到测试用例详情页仅打开一次，无切换，故任务切换频率（f_switch）为0；有效操作时段包括9:15–9:20的页面停留（因最终提交了步骤），扣除9:19–9:20的1秒空闲（未达5秒阈值），有效操作时长为4分59秒，执行专注度（f_focus）为0.997；调试强度（f_debug）由日志点击2次（频率0.4次 / 分钟）与空闲累计0秒加权计算得0.24。在9:20–9:25的时间窗口内，因发生页面标签切换事件（持续2分钟）及1次鼠标空闲事件（7秒），有效操作时长仅1分53秒，f_focus降至0.38；同时因未提交新步骤且无日志查询，f_debug为0.14；f_switch仍为0。行为流处理引擎将两个时间窗口的行为特征向量分别归一化后输出至负载状态分类模型。

[0048] 负载状态分类模型接收9:20–9:25的时间窗口对应的行为特征向量[f_switch=0,f_focus=0.38, f_debug=0.14]后，依据当前的权重w1=0.3、w2=0.4、w3=0.3计算动态负载指数DLI= 0.3×0 + 0.4×(10.38) + 0.3×0.14 = 0 + 0.248 + 0.042 = 0.29，归一化后为29，负载状态标签判定为高效执行。

[0049] 而在另一实际应用场景中，测试人员C执行集成测试用例TC-3012时，因依赖服务频繁超时，其在10分钟内反复点击日志查询按钮12次，并多次在页面间切换重试，行为流处理引擎在10:30–10:35的时间窗口内计算得f_switch=3.2、f_focus=0.25、f_debug=0.92；负载状态分类模型据此输出DLI=0.3×3.2 + 0.4×(10.25) + 0.3×0.92 = 0.96 +0.30 + 0.276 = 1.536（归一化后为96），负载状态标签为环境阻塞。将负载状态标签和动态负载指数送入预警与调度接口。

[0050] 预警与调度接口对来自负载状态分类模型的输出执行双重判断逻辑：首先进行DLI阈值判断，若动态负载指数DLI连续两个时间窗口超过85，则触发高负载预警；其次进行状态持续时间判断，若负载状态标签为环境阻塞且连续6个窗口（30分钟）保持不变，则判定为执行受阻。在测试人员C的案例中，其在10:30–10:35、10:35–10:40两个时间窗口负载动态指数DLI分别为96与94，均超过85，预警与调度接口于10:40生成结构化预警消息，通过企业微信Webhook推送至测试组长终端，内容包含匿名会话ID、DLI值、状态标签为：环境阻塞、关联用例TC-3012及已持续10分钟的信息；同时，该预警与调用接口调用PingCode提供的任务分配API，发送任务分配暂停指令，临时冻结向该人员分配新任务。至10:55，依赖服务恢复，测试人员C连续提交三个步骤，行为流处理引擎在10:50–10:55的时间窗口计算f_focus回升至0.82，动态负载指数DLI降至65，负载状态标签变更为高效执行，预警与调度接口随即发送恢复指令，解除任务分配限制。

[0051] 上述过程表明，通过行为采集代理对测试用例详情页打开 / 关闭事件、测试步骤提交事件、日志查询点击事件、页面标签切换事件及鼠标空闲事件的细粒度捕获，行为流处理引擎在时间窗口内精确量化任务切换频率、执行专注度与调试强度，使负载状态分类模型能够区分真实高效与表面忙碌；而预警与调度接口基于动态负载指数的阈值判断与状态持续时间判断的联动机制，确保仅在持续异常时触发干预，避免误报。整个链路无需修改PingCode原有业务逻辑，仅通过前端事件监听与后端微服务集成，即实现对测试执行过程的透明化感知与自动化调度，解决了现有技术中负载评估静态化、执行状态黑盒化及反馈机制被动化的根本缺陷。

[0052] 在本申请的可选实施例中，所述行为采集代理可替换为浏览器扩展程序或移动端SDK，只要能捕获相同类型的操作事件并保证数据脱敏；行为流处理引擎中的时间窗口的长度可调整为3分钟或10分钟等任何时间长度的取值，行为特征的计算逻辑可引入键盘敲击节奏、滚动行为等补充维度；负载状态分类模型可采用支持向量机、随机森林或Transformer编码器，只要输入为多维行为特征、输出包含状态标签与量化指数；预警与调度接口的预设预警条件的触发可扩展为DLI变化率突增、连续低专注度等复合规则，调度动作可包括自动分配辅助人员或触发环境健康检查。

[0053] 在本申请的所有实施例中，行为采集代理仅利用浏览器原生事件，无需安装客户端监控软件，避免侵入性操作，符合隐私保护规范；通过任务切换频率、执行专注度、调试强度三类行为特征的融合分析，区分高效忙碌与低效卡顿，提升负载判断准确性；5分钟得到时间窗口与流式处理架构支持近实时状态更新，预警延迟控制在10秒以内；动态负载指数DLI的数值与四种负载状态标签为管理者提供可解释的决策依据，避免主观猜测；在线学习机制使权重参数随团队实际工作模式动态演化，适配不同组织的流程文化与人员构成。

[0054] 根据本申请的另一方面，还提供了一种非易失性存储介质，其上存储有计算机可读指令，所述计算机可读指令可被处理器执行时，使所述处理器实现如上述的基于操作行为的动态负载感知与预警方法。

[0055] 根据本申请的另一方面，还提供了一种基于操作行为的动态负载感知与预警设备，其中，该设备包括：一个或多个处理器；计算机可读介质，用于存储一个或多个计算机可读指令，当所述一个或多个计算机可读指令被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上述基于操作行为的动态负载感知与预警方法。

[0056] 在此，所述基于操作行为的动态负载感知与预警设备中的各实施例的详细内容，具体可参见上述基于操作行为的动态负载感知与预警方法实施例的对应部分，在此，不再赘述。

[0057] 综上所述，本申请通过部署于测试管理系统的前端页面中的行为采集代理，实时捕获每个测试人员在执行测试任务过程中的所有的操作行为事件对应的数据流；行为流处理引擎接收至少两个所述行为采集代理推送的所述数据流，并按照测试人员的匿名会话ID对每个所述测试人员的所有的操作行为事件对应的数据流进行时间窗口的聚合和特征提取，得到每个所述测试人员在至少两个时间窗口中的每个时间窗口对应的行为特征向量；将每个所述测试人员在至少两个时间窗口中的每个时间窗口对应的行为特征向量输入所述负载状态分类模型进行状态识别，得到每个所述测试人员在至少两个时间窗口中的每个时间窗口的负载状态标签和动态负载指数；所述预警与调度接口基于每个所述测试人员在至少两个时间窗口中的每个时间窗口的负载状态标签和动态负载指数，判断所述测试人员的操作是否达到预设预警条件，若是，所述预警与调度接口生成结构化预警消息，并推送至项目管理者的即时通讯工具；同时，调用所述测试管理系统的任务分配API，暂停向达到所述预设预警条件的测试人员分配新任务，直至达到所述预设预警条件的测试人员的操作回落至所述预设预警条件的解除时刻。在本申请中，通过行为采集代理与行为流处理引擎协同构建的无感操作行为流管道，实现对测试执行过程的细粒度、非侵入式观测；基于多位特征向量与动态负载指数的耦合计算机制，形成自适应负载评估模型；并通过预警与调度接口与测试管理系统的任务分配的联动设计，实现了从状态感知到资源调度的闭环干预。

[0058] 需要注意的是，本申请可在软件和 / 或软件与硬件的组合体中被实施，例如，可采用专用集成电路（ASIC）、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序（包括相关的数据结构）可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

[0059] 另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和 / 或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和 / 或通过广播或其他信号承载媒体中的数据流而被传输，和 / 或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和 / 或技术方案。

[0060] 对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然"包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。< / script>

Claims

1. A dynamic load sensing and early warning method based on operational behavior, the method comprising: The method comprises a behavior acquisition agent deployed on the front-end page of the test management system and a behavior flow processing engine, a load status classification model, and an alert and scheduling interface deployed on the back-end server or independent microservice node of the test management system, wherein the method includes: The behavior acquisition agent captures in real time the data stream corresponding to all operational behavior events of each tester during the execution of test tasks; The behavior stream processing engine receives the data streams pushed by at least two behavior acquisition agents, and performs time window aggregation and feature extraction on the data streams corresponding to all the operation behavior events of each tester according to the anonymous session ID of the tester, so as to obtain the behavior feature vector corresponding to each time window of each tester in at least two time windows. The behavioral feature vector corresponding to each time window of each of the at least two time windows is input into the load state classification model for state identification, so as to obtain the load state label and dynamic load index of each of the at least two time windows for each of the testers. The early warning and scheduling interface determines whether the tester's operation meets the preset early warning conditions based on the load status label and dynamic load index of each tester in at least two time windows. If so, the warning and scheduling interface generates a structured warning message and pushes it to the project manager's instant messaging tool; at the same time, it calls the task allocation API of the test management system to suspend the allocation of new tasks to testers who have reached the preset warning conditions, until the operation of the testers who have reached the preset warning conditions returns to the time when the preset warning conditions are lifted.

2. The method according to claim 1, wherein, The behavior acquisition agent captures in real time the data stream corresponding to all operational behavior events of each tester during the execution of test tasks, including: The behavior acquisition agent captures raw data in real time corresponding to all operational behavior events of each tester during the execution of test tasks; Local anonymization processing is performed on the original data corresponding to all the aforementioned operation behavior events, removing user identity information and adding anonymous session IDs and timestamps to obtain the data stream corresponding to all the operation behavior events of each of the testers, wherein the data stream is in encrypted format.

3. The method according to claim 2, wherein, The operational event includes at least one of the following: Test case details page open / close event; Test step submission event; Log query click events; Page tab switching event; Mouse idle event.

4. The method according to claim 1, wherein, The behavior stream processing engine receives data streams pushed by at least two behavior acquisition agents, and performs time window aggregation and feature extraction on the data streams corresponding to all operational behavior events of each tester according to the tester's anonymous session ID, to obtain the behavior feature vector corresponding to each time window of each of the at least two time windows, including: The behavior stream processing engine receives data streams corresponding to all operational behavior events of each tester during the execution of a test task, pushed by at least two of the behavior collection agents. The behavior stream processing engine splits the data streams corresponding to all the operation behavior events of each tester according to the anonymous session ID of the tester, and aggregates all the operation behavior events of each tester within a time window with a preset time window as the sliding window length. Extract the behavioral features of each tester in each of the at least two time windows from the corresponding data stream to obtain the behavioral feature vector of each tester in each of the at least two time windows. The behavioral characteristics include: task switching frequency, execution focus, and debugging intensity. The task switching frequency is used to indicate the number of page switches for different test cases per unit time. The execution focus is used to indicate the proportion of effective operation time to the total window time. The debugging intensity is used to indicate the weighted combination of log query frequency and mouse idle time.

5. The method according to claim 4, wherein, The load state classification model is a lightweight neural network model, wherein the input layer receives the behavioral feature vector of each tester in at least two time windows; The hidden layer adopts a two-layer fully connected structure. The first hidden layer contains 16 neurons, and the second hidden layer contains 8 neurons. The activation function used for both layers is ReLU. The output layer contains four types of load states, corresponding to: high-efficiency execution, environment congestion, frequent switching, and inefficient operation, and synchronously outputs dynamic load indices.

6. The method according to claim 5, wherein, The formula for calculating the dynamic load index is as follows: DLI = w1·f_switch + w2·(1 f_focus) + w3·f_debug, Where f_switch is the value of task switching frequency, f_focus is the value of execution focus, and f_debug is the value of debugging intensity; w1, w2, and w3 are the weights of task switching frequency, execution focus, and debugging intensity, respectively, and all of them are adjustable.

7. The method according to claim 1, wherein, The early warning and scheduling interface determines whether the tester's operation meets the preset early warning conditions based on the load status label and dynamic load index of each tester in at least two time windows. If so, the early warning and scheduling interface generates a structured early warning message, including: The warning and scheduling interface performs threshold judgment on the dynamic load index: if a tester's load status index exceeds the preset first index threshold for two consecutive time windows, it is considered a high load risk; simultaneously, The warning and scheduling interface determines the duration of the status: if a tester's load status label is "environmental blockage" and the duration of the environmental blockage exceeds the preset duration, it is considered that the execution is blocked, wherein the preset duration is at least two consecutive time windows. If a high load risk and / or execution obstruction are met, the warning and scheduling interface generates a structured warning message, which includes the tester's anonymous session ID, the current value of the load status index, the load status label, a list of test case IDs involved, and the duration.

8. The method according to claim 7, wherein, The method further includes: The time when the preset warning condition is lifted is used to indicate the moment when the dynamic load index of the tester falls back to the preset second index threshold and the load status label changes to high efficiency execution in a subsequent time window, wherein the second index threshold is less than the first index threshold.

9. A non-volatile storage medium having stored computer-readable instructions thereon, which, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 8.

10. A dynamic load sensing and early warning device based on operational behavior, wherein, The device includes: One or more processors; Computer-readable medium for storing one or more computer-readable instructions. When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors perform the method as described in any one of claims 1 to 8.

Images