A VTE performance test adaptive method, device and equipment for a hospital clinical environment and a storage medium

Abstract

The application discloses a hospital clinical environment-oriented VTE performance test adaptive method and device, equipment and a storage medium, and the method comprises the following steps: capturing interference factors of an in-hospital VTE test environment at a preset period, the interference factors comprising at least one of network state parameters, terminal type information and test library data volume information; in response to detecting network bandwidth jitter or delay rising, adjusting the number of concurrent terminals according to the network quality level, and splitting batch data transmission batches; in response to identifying old terminals executing VTE scale tests, switching a lightweight pressure test protocol and performing compatibility conversion on a front-end script, and splitting new and old terminals into independent pressure test groups; and in response to detecting insufficient test library case data volume, starting a data compensation model to generate simulation data to expand a test data set. The application eliminates three environmental interferences of network jitter, old terminal compatibility and insufficient test library data, and guarantees the accuracy of VTE performance test indexes and the continuity of test tasks.

Description

Technical Field

[0001] This invention relates to the field of medical information technology, and in particular to an adaptive method, apparatus, equipment, and storage medium for VTE performance testing in hospital clinical environments. Background Technology

[0002] The hospital's integrated VTE prevention and control system integrates the entire treatment process for inpatient VTE risk screening, stratified assessment, intervention plan development, thrombosis early warning, follow-up tracking, and hospital-wide data statistics and reporting. The system's operational stability, multi-department concurrent response speed, and big data batch analysis capabilities directly determine the quality of the hospital's thrombosis prevention and control work. Therefore, a complete and rigorous performance stress test must be conducted before going live, iterating, or upgrading. The stability and realism of performance testing highly depend on hardware and software testing resources such as server computing power, memory, network links, database clusters, and container nodes.

[0003] Currently, the performance testing of integrated VTE prevention and control systems in the industry generally follows the traditional manual static resource allocation model, which has the following drawbacks: The existing testing system lacks the ability to adapt to the hospital clinical environment. There are many unstable variables in the hospital VTE business scenario environment: the linkage of multiple systems such as HIS, LIS and monitoring equipment in the hospital causes frequent fluctuations in network bandwidth; some old wards still deploy Windows 7 + IE11 terminals for nurse station VTE questionnaire filling; the amount of patient thrombosis-related case data stored in the test library is only 1 / 10 or even less of the production library, which cannot reproduce the pressure of querying real million-level patient data.

[0004] The aforementioned environmental interferences can cause test script errors, concurrent task crashes, and misjudgments of performance metrics, significantly extending the testing cycle.

[0005] Therefore, there is an urgent need for an adaptive solution for VTE performance testing in hospital clinical environments. Summary of the Invention

[0006] In view of the above-mentioned defects in the prior art, the purpose of the present invention is to provide an adaptive method, device, equipment and storage medium for VTE performance testing in hospital clinical environment, so as to solve the defect of weak adaptability of the prior art to complex clinical environment and realize adaptive adjustment.

[0007] To achieve the above objectives, the present invention provides the following technical solution: According to a first aspect of the present invention, an adaptive method for VTE performance testing in a hospital clinical environment is provided, comprising the following steps: Step 1: Capture interference factors in the VTE test environment within the institute at a preset period (e.g., 2 seconds). Interference factors include at least one of the following: network status parameters, terminal type information, and test library data volume information. Step 2: In response to the detection of network bandwidth jitter or increased latency, adjust the number of concurrent terminals according to the network quality level and split the batch data transmission into batches; Step 3: In response to the detection of old terminals performing VTE scale testing, switch to the lightweight load testing protocol and perform compatibility conversion on the front-end script, and separate the old and new terminals into independent load testing groups; Step 4: In response to the detection of insufficient case data in the test database, the data compensation model is activated to generate simulation data to expand the test dataset; Steps 2, 3, and 4 are executed collaboratively according to a preset priority, and the adaptation results of each step are independent of each other.

[0008] In some implementations, step 2, adjusting the number of concurrent terminals based on the network quality level, includes: Network quality levels are classified based on network round-trip latency as the main indicator. A concurrency adjustment coefficient is determined based on the network quality level, and the number of concurrent terminals is adjusted according to the concurrency adjustment coefficient.

[0009] In some implementations, step 2, which adjusts the number of concurrent terminals according to the network quality level, further includes: Network quality levels are classified based on RTT (Round-Trip Time) as the main indicator, including at least: excellent level when RTT is less than a first threshold, medium level when RTT is greater than or equal to the first threshold and less than a second threshold, and poor level when RTT is greater than or equal to the second threshold; the poor level is further divided into at least two sub-levels according to the degree of jitter. The first concurrent adjustment coefficient corresponds to the excellent level, the second concurrent adjustment coefficient corresponds to the medium level, the third concurrent adjustment coefficient corresponds to the milder jitter in the poor level, and the fourth concurrent adjustment coefficient corresponds to the severe jitter in the poor level. The fourth concurrency adjustment coefficient is less than the third concurrency adjustment coefficient, the third concurrency adjustment coefficient is less than the second concurrency adjustment coefficient, and the second concurrency adjustment coefficient is less than the first concurrency adjustment coefficient; The larger of the adjusted concurrent number and the minimum guaranteed number of terminals is used as the actual concurrent number.

[0010] In some implementations, step 2 involves splitting the batch data transmission into smaller batches, including: Increase the transmission interval between batches to split a single batch of data into multiple batches and send them sequentially.

[0011] In some implementations, step 2, which involves splitting the batch data transmission into batches, further includes: Record network fluctuation parameters, and perform linear correction on the test indicators based on the network fluctuation parameters; After the network recovers, the number of concurrent connections will gradually increase according to the preset gradient.

[0012] In some implementations, step 3 involves switching the lightweight load testing protocol and performing compatibility conversion on the front-end script, including: The WebSocket long-connection load test was downgraded to HTTP short polling, and the front-end script was converted for compatibility.

[0013] In some implementations, compatibility conversion of the front-end script includes at least one of the following: Translate ES6 syntax into ES5 syntax; Inject a Polyfill into a Promise asynchronous object; Degrade the Fetch API to an XMLHttpRequest request; Remove animated vector graphics and replace them with static images; Switch from Flexbox to float layout.

[0014] In some implementations, step 4 involves activating the data compensation model to generate simulation data, including: Check whether the proportion of the total number of cases in the test database to the effective cases in the production database is lower than a preset threshold; When the threshold is lower than the preset threshold, the conditional data compensation model is activated, taking desensitized real VTE case samples and test scenario condition labels as input, and outputting a structured virtual thrombosis case dataset (i.e., simulation dataset). The data compensation model performs one-hot encoding on the input discrete variables and Min-Max normalization on the input continuous variables, concatenating them to form a multi-dimensional standardized feature vector. The loss function of the data compensation model is superimposed with the distribution constraint loss, and the generated simulation data is subjected to distribution consistency verification. After the verification is qualified, it is merged with the real case data to form a test dataset. The simulation data resides only in the test memory and is automatically destroyed after the test is completed.

[0015] In some implementations, steps 2, 3, and 4 are scheduled with priority and executed sequentially according to a preset priority to adapt to multiple environmental interferences in the hospital: step 3 is executed during the test script loading phase, step 4 is executed before the test starts, and step 2 is executed in real time during the test run; the priority of step 3 is higher than that of steps 2 and 4. In step 3, the old and new terminals are separated into independent stress testing groups, and test indicators are collected separately to isolate the interference of the old terminals on the overall testing process.

[0016] In some implementations, the terminal type identification result in step 3 does not affect the network status monitoring in step 2 and the data volume detection in step 4; the data compensation result in step 4 does not affect the terminal adaptation in step 3 and the network fluctuation adjustment in step 2; the concurrent quantity adjustment in step 2 does not affect the terminal type identification in step 3 and the test dataset in step 4.

[0017] According to a second aspect of the present invention, an adaptive device for VTE performance testing in a hospital clinical environment is provided, characterized in that it comprises: An environment awareness module is used to capture interference factors in the VTE testing environment within the institute at a preset period. The interference factors include at least one of network status parameters, terminal type information, and test library data volume information. The network fluctuation adaptation module is used to adjust the number of concurrent terminals and split batch data transmission into batches when network bandwidth jitter or latency increase is detected. The legacy terminal adaptation module is used to switch the lightweight load testing protocol and perform compatibility conversion of the front-end script when the legacy terminal is identified to perform VTE scale testing, and to separate the new and old terminals into independent load testing groups. The data compensation module is used to generate simulation data to expand the test dataset when the amount of case data in the test library is insufficient.

[0018] In some implementations, the legacy terminal adaptation module is specifically used to: identify the browser type and version of the legacy terminal, downgrade WebSocket long connection stress testing to HTTP short polling, translate ES6 syntax to ES5 syntax, inject Polyfill into Promise asynchronous objects or downgrade the Fetch interface to XMLHttpRequest requests, remove dynamic vector graphics and replace them with static images, and switch Flex layout to float layout.

[0019] In some implementations, the data compensation module is specifically used to: detect whether the proportion of the total number of cases in the test library to the effective cases in the production library is lower than a preset threshold; when it is lower than the preset threshold, the conditional variational autoencoder data compensation model is activated, taking desensitized real VTE case samples and test scenario condition labels as input, outputting a structured virtual thrombosis case dataset, and performing hard truncation of clinical indicator intervals and stratified case proportion replication on the generated simulation data; the simulation data only resides in memory and is automatically destroyed after the test ends.

[0020] According to a third aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory storing one or more programs that, when executed by the processor, implement the above-described adaptive method for VTE performance testing.

[0021] According to a fourth aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the above-described adaptive method for VTE performance testing.

[0022] The beneficial effects of this invention are: This invention has the following key technical points: 1. Network fluctuation adaptive adjustment technology: Based on the RTT three-level network quality classification and dynamic control of concurrency adjustment coefficient, supplemented by batch splitting and linear correction of indicators, the interference of network jitter on test indicators is eliminated.

[0023] 2. Full-stack compatibility adaptation technology for older terminals: dual downgrade from the protocol layer (WebSocket → HTTP short polling) and the script layer (ES6 → ES5, Polyfill, Fetch → XMLHttpRequest, Flex → float) to solve compatibility issues for older terminals such as IE11.

[0024] 3. VTE test library data CVAE compensation technology: The simulated case data that fits the real clinical distribution is generated by the conditional variational autoencoder. Combined with MMD distribution constraints and KS test correction, the pressure of the production library data is restored while protecting patient privacy.

[0025] These key technologies have achieved the following beneficial effects: 1. Eliminate the interference of network fluctuations on test metrics: Dynamically adjust the concurrency through RTT levels to avoid network lag being misjudged as a system performance defect, and ensure that test metrics truly reflect the system's capabilities.

[0026] 2. Completely solves compatibility issues with older terminals: Through full-stack scripts and protocol-based lightweight adaptation, the VTE questionnaire reporting test can run stably on older terminals such as IE11 without the need to replace hardware devices.

[0027] 3. To compensate for insufficient test data: By generating simulation data that closely matches the actual clinical distribution through CVAE, the testing pressure is made closer to the real production environment, avoiding overly optimistic test indicators due to insufficient data.

[0028] 4. Fully automated operation, no manual intervention required: The identification, judgment and adaptation of environmental interference are completed automatically by the system, without the need for maintenance personnel to manually adjust test parameters.

[0029] 5. Fully adapted to the special clinical environment of hospital VTE: It is specifically designed to address the three major pain points commonly found in hospitals: network fluctuations, outdated terminals, and insufficient test library data. Performance testing that closely resembles real-world scenarios can be carried out without modifying existing hardware.

[0030] In summary, this invention discloses an adaptive method, apparatus, equipment, and storage medium for VTE performance testing in hospital clinical environments, relating to the technical field of integrated VTE prevention and control systems. The method includes: capturing interference factors in the hospital's VTE testing environment at a preset cycle; these interference factors include network status parameters, terminal type information, and test database data volume information; adjusting the number of concurrent terminals according to the network quality level and splitting batch data transmission into batches in response to detected network bandwidth jitter or increased latency; switching to a lightweight stress testing protocol and performing compatibility conversion on the front-end script in response to the identification of old terminals performing VTE scale testing, and splitting new and old terminals into independent stress testing groups; and starting a data compensation model to generate simulation data to expand the test dataset in response to the detection of insufficient case data in the test database. This invention eliminates the impact of three major environmental interferences—network jitter, compatibility issues with old terminals, and insufficient test database data—on VTE performance testing, ensuring the accuracy of test indicators and the continuity of test tasks, and is suitable for VTE performance testing scenarios in complex hospital clinical environments. Attached Figure Description

[0031] Figure 1 This is a flowchart of the adaptive method for VTE performance testing in a hospital clinical environment according to the present invention. Figure 2 This is a detailed flowchart of the network fluctuation adaptive adjustment of the present invention; Figure 3 A detailed flowchart illustrating the adaptive adaptation for legacy terminals of this invention; Figure 4 A detailed flowchart of the adaptive compensation for test library data in this invention; Figure 5 This is a framework diagram of the adaptive device for VTE performance testing in a hospital clinical environment according to the present invention. Figure 6 This is a simplified schematic diagram of the electronic device of the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0033] Example 1: Detailed Implementation of Adaptive Adjustment for Network Fluctuations like Figure 1-2As shown in the figure, this embodiment describes in detail the specific implementation process of the network fluctuation adaptive adjustment strategy in this invention, including network quality perception, dynamic adjustment of concurrency, data batch splitting, and test index calibration.

[0034] The following is a detailed description of each step: 1. Real-time network quality awareness: The environmental perception module captures the network status parameters within the hospital every 2 seconds. The network status parameters include at least RTT (Round-Trip Time), packet loss rate, and bandwidth jitter.

[0035] Preferably, RTT is measured using an active probing method: the environmental sensing module sends ICMP Echo requests (Ping packets) to the host computer or a designated intra-hospital network reference node (such as the HIS system gateway) at 1-second intervals, and the average value of 5 consecutive measurements is taken as the current RTT value. The formula for calculating RTT is as follows: RTT = (T reply - T request ) / 2 Among them, T request The time when the probe request is sent, T reply The moment the response message is received is used to improve measurement accuracy. Each measurement is repeated 5 times, and the arithmetic mean is taken after removing the maximum and minimum values.

[0036] Preferably, the packet loss rate is measured using a passive monitoring method: the environment awareness module monitors TCP connection retransmission and timeout events during the VTE test, and calculates the ratio of the number of lost packets to the total number of packets sent within a preset time window (e.g., 30 seconds), which is taken as the current packet loss rate. The packet loss rate calculation formula is: Packet loss rate = (Number of lost packets / Total number of sent packets) × 100% As a preferred method, the bandwidth jitter amplitude is measured using a differential calculation method: the environmental sensing module continuously collects the bandwidth utilization value for 10 sampling periods, calculates the absolute value of the difference between adjacent sampling points, and takes the average value as the jitter amplitude. The bandwidth jitter amplitude reflects the stability of the network bandwidth, and the larger the value, the more unstable the network.

[0037] 2. RTT Three-Tier Network Quality Classification: The environment awareness module uses RTT latency as the primary indicator, combined with packet loss rate and bandwidth jitter, to comprehensively determine the current network quality, classifying it into three levels: Superior network: RTT less than 100ms, packet loss rate less than 0.5%, and bandwidth jitter less than 10%; at this time, the network condition is good, and the VTE test can run at full speed without any adjustment.

[0038] Intermediate network: RTT greater than or equal to 100ms and less than 300ms, or packet loss rate between 0.5% and 2%, or bandwidth jitter between 10% and 30%; at this time, the network is experiencing a certain degree of congestion or interference, and the concurrent load needs to be appropriately reduced.

[0039] Poor network: RTT greater than or equal to 300ms, or packet loss rate greater than 2%, or bandwidth jitter greater than 30%; at this time the network is severely congested or unstable, and it is necessary to significantly reduce the concurrent pressure and take additional protection measures.

[0040] As a preferred approach, when the results of the three indicators—RTT, packet loss rate, and bandwidth jitter—are inconsistent, the principle of "choosing the higher one" is adopted. That is, if any one indicator reaches the poor standard, the overall network quality is judged as poor; if any one indicator reaches the medium standard and there are no poor indicators, the overall quality is judged as medium.

[0041] 3. Dynamic adjustment of concurrent connection count: Based on the network quality level, the environment awareness module determines the concurrency adjustment coefficient and dynamically adjusts the number of concurrent terminals in the current VTE test: Superior network: Concurrency adjustment factor = 1.0, keeping the original number of concurrent connections unchanged.

[0042] Intermediate network: Concurrency adjustment factor = 0.8, reducing the number of concurrent terminals to 80% of the original.

[0043] Differential networks: Mild jitter (RTT between 300-500ms, or packet loss rate between 2%-5%): Concurrency adjustment factor = 0.6.

[0044] Severe jitter (RTT greater than 500ms, or packet loss rate greater than 5%): Concurrency adjustment factor = 0.4.

[0045] As a preferred method, the calculation method for adjusting the concurrency level is as follows: Adjusted concurrency = max(floor(current concurrency × concurrency adjustment factor), minimum concurrency) Floor() is a function that rounds down to the nearest integer. The minimum concurrent connection is preset to 50 to ensure that the test can maintain basic concurrent coverage even under the worst network conditions, thus avoiding complete test interruption.

[0046] 4. Data batch splitting and transmission interval control: When the network quality is determined to be medium or poor, the environment awareness module automatically triggers the data batch splitting mechanism: As a preferred approach, the VTE batch data (such as 10GB of historical thrombosis screening data) that was originally transmitted in a single batch is split into multiple smaller batches, with each batch containing no more than 500MB of data.

[0047] As a preferred method, an 80ms transmission interval is added between batches to avoid continuous network congestion caused by the continuous transmission of multiple large batches of data. The formula for calculating the transmission interval is: Transmission interval = 80ms × network quality coefficient.

[0048] Among them, the network quality coefficient of the medium-level network is 1.0 (interval 80ms), the poor level with slight jitter is 1.5 (interval 120ms), and the poor level with severe jitter is 2.0 (interval 160ms).

[0049] As a preferred option, the split batches of data are sorted and renumbered before being sent to ensure that the host computer can reassemble the data in the original order after receiving it, without affecting the statistical accuracy of the test indicators.

[0050] 5. Fluctuation parameter recording and linear calibration of test indicators: The environment awareness module records network fluctuation parameters in real time, including fluctuation occurrence time, fluctuation duration, maximum RTT, peak packet loss rate, and concurrency adjustment coefficient, and stores these parameters in a temporary cache.

[0051] Preferably, a linear correction model is used for test metric calibration: for test metrics collected during periods of fluctuation (such as interface response time, QPS, etc.), compensation and correction are performed according to the severity of the fluctuation. For response time-related metrics (the larger the value, the worse the performance), the correction formula is: Corrected response time = original measured value ÷ (1 + correction coefficient) to eliminate the error caused by network latency and restore the system's true response capability. For throughput metrics (such as QPS, where a higher value indicates better performance), the correction formula is: Corrected QPS = Original measured value × (1 + correction coefficient) to compensate for downlink deviations caused by network rate limiting.

[0052] Once the network is restored, stop the calibration and restore the original measurement values.

[0053] The correction coefficient is determined according to the network quality level: 0.05-0.10 for medium-level networks, 0.15-0.20 for poor-level mild jitter, and 0.25-0.35 for poor-level severe jitter. The specific value of the correction coefficient is dynamically calculated based on the duration and severity of the fluctuation. The more severe the fluctuation and the longer the duration, the larger the correction coefficient.

[0054] As a preferred option, the corrected index value should be compared and verified with the index value during the stable period before and after the fluctuation. If the corrected value deviates from the average value of the stable period by more than 20%, the data for that period will be marked as "high fluctuation impact data" and separately marked in the final test report for testers to refer to and judge.

[0055] 6. Concurrency gradient recovery after network recovery: The environment awareness module continuously monitors the network status. When it detects that the RTT has recovered to below 100ms, the packet loss rate is below 0.5%, the bandwidth jitter is below 10%, and the above statuses last for more than 30 seconds, it determines that the network has recovered.

[0056] As a preferred approach, the concurrency level is increased using a gradient strategy: the concurrency is increased by 10% each time, then observed for 5 seconds. Only after confirming that the network condition has not deteriorated is the next increase performed, until the original concurrency level is restored. The gradient increase formula is as follows: Concurrency after the nth rebound = min(current concurrency × 1.1, original concurrency) The maximum number of recovery times is 20 (ln(original concurrency / minimum concurrency) / ln(1.1) rounded up, generally between 10 and 20 times), with a 5-second interval between each recovery to prevent secondary bandwidth impact.

[0057] A complete time-series example of adaptive network fluctuation adjustment: Take a specific network fluctuation event as an example: T=0 seconds: Network is normal, RTT=60ms, 800 concurrent terminals, concurrency adjustment coefficient 1.0; T=5 seconds: The in-hospital image transmission system is started, RTT is increased to 180ms, the network quality is judged as medium, the concurrency adjustment coefficient is 0.8, the number of concurrent devices is reduced to 640, and the batch transmission interval is set to 80ms. T=15 seconds: Image transmission enters peak period, RTT rises to 350ms, network quality is judged as poor with slight jitter, concurrency adjustment coefficient is 0.6, concurrency is further reduced to 384 units (minimum of 50 units or more), and transmission interval is adjusted to 120ms; T=45 seconds: Image transmission ends, RTT gradually decreases; T=75 seconds: RTT drops to 85ms (below the excellent threshold), and continuous monitoring is performed for 30 seconds from this moment. RTT stabilizes within the range of 85±10ms. T=105 seconds: After the continuous stable monitoring period is completed, it is determined that the network has been fully recovered, triggering the concurrent gradient recovery process, which increases by 10% every 5 seconds, and recovers to 800 units after about 50 seconds.

[0058] Example 2: Specific Implementation Methods for Adaptive Compatibility with Older Terminals like Figure 1 and Figure 3 As shown in the figure, this embodiment describes in detail the specific implementation process of the adaptive adaptation strategy for old terminals in this invention, including old terminal identification, protocol downgrade adaptation, front-end script compatibility processing, and grouping and isolating new and old terminals.

[0059] The detailed explanations of each step are as follows: 1. Identification of outdated terminals: The environment awareness module identifies the terminal type and browser version by parsing the User-Agent field in the HTTP request header.

[0060] As a preferred method, the criteria for identifying old terminals are: the operating system is Windows 7 or earlier, and the browser is Internet Explorer 11 or earlier. The specific identification logic is: the User-Agent string contains "Windows NT 6.1" (Windows 7) and contains "Trident / 7.0" (IE11) or an earlier Trident version number.

[0061] As a preferred method, the identification process is executed when the VTE test script is first loaded. If the terminal is determined to be an old terminal, the environment awareness module will label the terminal as "legacy" and route it to a dedicated old terminal stress test channel. All subsequent adaptation logic will only take effect for this channel.

[0062] 2. Protocol layer downgrade adaptation: By default, the new terminal uses the WebSocket long connection protocol for stress testing to achieve low-latency bidirectional communication and high-concurrency connection management.

[0063] As a preferred method, upon detecting an IE11 terminal, the system automatically downgrades the protocol from WebSocket long connection to HTTP / 1.1 short polling. The short polling interval is preset to 800ms, meaning that an HTTP request is sent every 800ms to obtain the latest data.

[0064] As a further preferred option, the fallback solution also provides long polling as a backup: when the server supports it and network conditions permit, long polling can be used, where the server keeps the connection open after the client sends a request, and only returns a response when there is new data; otherwise, it returns an empty response after a timeout, and the client immediately initiates the next request. Long polling reduces the number of empty requests compared to short polling, but its implementation complexity is slightly higher.

[0065] As a further preferred option, the protocol downgrade switching is automatically completed by the environment awareness module without manual intervention, and is transparent to the upper-layer test scripts—the test scripts can run under both protocols without modification.

[0066] It should be noted that the "transparency" of the protocol downgrade to the upper-layer test script is achieved through a lightweight protocol adaptation proxy layer set up between the old terminal and the test server, as detailed below: Front-end proxy layer architecture: Inject a WebSocket compatibility layer into the test page of the old terminal. This compatibility layer checks whether the browser natively supports WebSocket when the page loads. If it does not support it, it loads the adaptation script and injects a virtual WebSocket class into the global window object.

[0067] API mapping rules: `new WebSocket(url)` → This is converted to creating an HTTP session, recording the Session ID, and starting a polling timer (every 800ms interval). ws.send(data) → Converts to an HTTP POST request, carrying the Session ID and data as the request body. ws.onmessage → Triggered by the response callback of the polling timer, wrapping the response data into a virtual MessageEvent object. ws.onopen → Triggered when the first polling response is successful. ws.onclose → Triggered after active closing or timeout. ws.close() → Sends an HTTP DELETE request to destroy the server session. Server-side proxy layer: Deploy a protocol conversion gateway to receive short HTTP polling requests from legacy terminals, convert them into internal WebSocket connections, maintain session state, and forward messages.

[0068] With the above adaptation layer, the upper-layer test script can run normally on the IE11 terminal without modifying the WebSocket API call code.

[0069] 3. Front-end script compatibility handling: For IE11 devices, it is necessary to downgrade to modern front-end technologies that are not supported or are poorly supported: (1) ES6 syntax translation: IE11 does not support the syntax features of ES6 (ECMAScript 2015) and later versions, including arrow functions, let / const block-scope variable declarations, destructuring assignment, and template literals.

[0070] As a preferred option, the system has a built-in Babel transpiler that automatically transpiles ES6+ syntax to ES5 syntax in real time before the test script is sent to older terminals. Specific transpilation rules include: The arrow function () => {} is translated to function () {}; let / const declarations are translated into var declarations; Destructuring assignment `const {a, b} = obj` translates to `var a = obj.a; var b = obj.b;` The template string `${name}` is translated into a string concatenation syntax for name.

[0071] (2) Compatibility with Promise asynchronous objects: IE11 does not support native Promise objects.

[0072] As a preferred approach, when loading test scripts on older terminals, the system first checks if window.Promise exists; if it does not exist, it automatically injects a lightweight Promise Polyfill (approximately 2KB compressed) to provide basic Promise functionality support (then, catch, finally methods).

[0073] As a further preferred option, for complex asynchronous scenarios that cannot be covered by Polyfill (such as deep nesting of multiple then calls in chained calls), the system provides a fallback solution: rewrite Promise as an ES5 callback function and use setTimeout to simulate asynchronous delay to ensure that the test script can be executed normally on IE11.

[0074] (3) Fetch interface downgrade: IE11 does not support the Fetch API.

[0075] As a preferred approach, the system automatically checks if `window.fetch` exists on older terminals; if it does not exist, all Fetch requests are downgraded to native IE XMLHttpRequest (XHR) requests. The downgrade mapping rules are as follows: fetch(url, {method: 'POST', body: data}) → new XMLHttpRequest();xhr.open('POST', url); xhr.send(data); The `fetch(url).then(res =>res.json())` method, in turn, parses `xhr.responseText` into a JSON object in the `xhr.onreadystatechange` callback.

[0076] As a further optimization, to reduce the risk of errors when writing XHR by hand, the system uses a lightweight wrapper library (such as the polyfill version of whatwg-fetch) to uniformly handle the degradation logic, ensuring that all Fetch calls are transparently switched to XHR implementation on older terminals.

[0077] (4) Degradation of WebGL heatmaps and complex SVG visualization: IE11 does not support WebGL and has deficiencies in its support for complex SVG (Scalable Vector Graphics).

[0078] Preferably, when an outdated terminal is detected, the system automatically removes visualization components that rely on WebGL or complex SVG rendering, such as the VTE thrombosis risk heatmap and dynamic thrombosis path map. The replacement solution is: Replace the animated vector graphics with pre-generated static PNG images; Key information such as risk level and thrombus location is displayed in plain text risk labels, such as "[High Risk] Deep vein thrombosis in the left lower extremity"; Turn off all animation rendering effects (such as CSS animations and JavaScript animation frames) to reduce the terminal rendering load.

[0079] (5) Binary data transmission degradation: IE11's support for binary data types such as Blob and ArrayBuffer is incomplete.

[0080] Preferably, when binary data (such as VTE scale attachments, patient signature images, etc.) needs to be transmitted, the system automatically converts the binary data into Base64 encoded text payloads for transmission. The amount of data after Base64 encoding increases by about 33%, but for VTE scale reporting scenarios (the amount of data per instance is usually a few KB to tens of KB), the increase is acceptable.

[0081] (6) Flexbox compatibility: IE11 has many bugs in its support for Flexbox, especially in the implementation of properties such as flex-wrap, flex-basis, and align-items, which are inconsistent with the standard.

[0082] As a preferred option, the system automatically switches the Flexbox layout to the traditional float layout on older terminals. Specific conversion rules include: display: flex → display: block + floating child elements; flex-direction: row → child elements float: left or display: inline-block; justify-content: space-between → Manually control the spacing using padding or margin; `flex-wrap: wrap` → When the parent container has a fixed width, child elements will wrap automatically.

[0083] As a further optimization, the system also automatically injects IE11-specific CSS hacks (conditional comments or CSS prefixes) to fix IE11-specific layout bugs and ensure that form elements, buttons, input boxes, etc. on the VTE questionnaire filling page are displayed and interacted with normally.

[0084] 4. Isolation of old and new terminals in groups: Preferably, the system separates older and newer terminals into independent load testing Pod groups, collecting test metrics separately. The specific method is as follows: New type of terminal: Pod groups assigned to the "modern" label are subjected to WebSocket long-connection stress testing to collect complete performance metrics.

[0085] For legacy devices: Pod groups assigned to the "legacy" label are subjected to HTTP short polling load testing to collect performance metrics in the degraded mode.

[0086] As a preferred approach, the two sets of test data are stored and reported separately to avoid the low performance of older terminals contaminating the overall test conclusions. The test report clearly indicates the differences in the data acquisition environment and stress testing protocols between the two sets of data, allowing testers to make a comprehensive judgment.

[0087] As a further optimization, the system also provides an automatic removal fallback mechanism for single-terminal rendering failures: when an old terminal experiences page rendering timeouts or script execution errors three times in a row during the test, the terminal is automatically removed from the test queue, and the reason and time of removal are recorded to avoid the anomaly of a single terminal dragging down the overall test progress.

[0088] Complete timing example for adapting to older terminals: Taking a Windows 7 + IE11 terminal as an example to participate in the VTE scale completion test: T=0 seconds: The terminal initiates a connection, and the environment awareness module identifies it as IE11 through User-Agent; T=0.1 seconds: The system labels the terminal as "legacy" and routes it to the old terminal stress test channel; T=0.2 seconds: The protocol is downgraded from WebSocket to HTTP / 1.1 short polling (interval 800ms); T=0.3 seconds: Before the test script is deployed, Babel will translate the ES6 syntax into ES5 in real time; T=0.4 seconds: Window.Promise is detected as non-existent; Promise Polyfill is injected. T=0.5 seconds: If window.fetch is not found, the Fetch request will be downgraded to XMLHttpRequest; T=0.6 seconds: The WebGL heatmap is replaced with a static image, and the Flex layout is switched to a float layout; T=1.0 seconds: The questionnaire filling page has finished loading and the test will begin.

[0089] During the test: an HTTP request was sent every 800ms to submit the scale data, and the terminal page remained stable without crashing.

[0090] Example 3: Detailed Implementation of Adaptive Compensation for Test Library Data like Figure 1 and Figure 4 As shown in the figure, this embodiment describes in detail the specific implementation process of the adaptive compensation strategy for test library data in this invention, including data volume detection, CVAE model construction and training, data generation and distribution correction, privacy desensitization and data destruction, etc.

[0091] The detailed explanations of each step are as follows: 1. Test library data volume detection: Preferably, the environment perception module performs a data volume check before the VTE test starts to obtain the total number of valid thrombosis cases in the test library and compares it with the total number of valid cases in the production library.

[0092] As a preferred option, the formula for determining data volume detection is: Data gap ratio = (Number of valid cases in production database - Number of valid cases in test database) / Number of valid cases in production database × 100%.

[0093] As a preferred approach, the data compensation process is initiated when the data gap ratio is greater than or equal to 90% (i.e., the number of cases in the test database is less than 10% of the number in the production database). For example, if the production database has 1 million valid thrombosis cases and the test database has only 80,000 cases, the data gap ratio is 92%, triggering data compensation.

[0094] Preferably, the definition of valid cases in the test library and the production library is consistent: both refer to thrombosis-related case records of hospitalized patients that contain complete VTE risk assessment elements (at least one of the following: basic patient information, type of surgery, department, D-dimer value, Caprini score, or Padua score) and have been desensitized.

[0095] 2. CVAE Model Architecture and Training: (1) Model selection As a preferred choice, the data compensation model uses a Conditional Variational Autoencoder (CVAE). The advantages of CVAE over Generative Adversarial Networks (GANs) are: it can precisely control the distribution of clinical indicators in the generated data and will not produce outliers that do not conform to medical common sense; compared with data generated by rule engines, it can preserve the multidimensional correlations in real data (such as the correlation between age and D-dimer, and the correlation between surgical type and thrombosis risk).

[0096] (2) Input / output design: The input to the CVAE model consists of two parts: Desensitized real VTE case samples: Original case records extracted from the test library, without patient identification.

[0097] Test scenario condition label: Specifies the target scenario for generating data, such as "Batch thrombosis statistics scenario requires 1 million cases" or "High-risk early warning scenario requires 500,000 postoperative high-risk cases".

[0098] Preferably, the test scenario condition labels are represented using one-hot encoding, for example: Batch statistics scenario: [1,0,0] High-risk warning scenario: [0,1,0] Multidisciplinary concurrent screening scenario: [0,0,1] The model output is a structured virtual thrombosis case dataset, with each case containing the same field structure as real cases.

[0099] (3) Feature engineering coding: For the input real case samples, standardized feature encoding is required: As a preferred approach, one-hot encoding is used for discrete categorical variables such as surgery type, department, and history of thrombosis. For example, surgery types include categories such as "orthopedic surgery," "general surgery," and "obstetrics and gynecology surgery," with each encoding an independent binary feature dimension.

[0100] Preferably, continuous numerical variables such as age, D-dimer, and Caprini score (or Padua score) are subjected to Min-Max normalization, mapping them to the [0,1] interval. The normalization formula is: x norm = (x - x min ) / (x max - x min ) Where, x min and x max These are the minimum and maximum values ​​of the variable in all valid cases in the test library, respectively. When normalizing D-dimer, it should be noted that its distribution is usually right-skewed, and logarithmic transformation can be used before normalization.

[0101] Preferably, all encoded feature vectors are concatenated to form a 21-dimensional standardized feature vector, which is used as the input to the CVAE model. The specific composition of the 21-dimensional feature vector includes: 8-dimensional surgical type unique hot coding, 6-dimensional department unique hot coding, 3-dimensional thrombosis history unique hot coding, and 4-dimensional continuous variables (age, D-dimer, Caprini score, and length of hospital stay).

[0102] As a further preferred embodiment, the 21-dimensional standardized feature vector is specifically constructed as follows: 8-dimensional unique-hot encoding is used for surgical types, covering eight categories: orthopedic surgery, general surgery, obstetrics and gynecology surgery, neurosurgery, cardiothoracic surgery, urological surgery, vascular surgery, and other surgeries; 6-dimensional unique-hot encoding is used for departments, covering six categories: orthopedics, general surgery, obstetrics and gynecology, neurosurgery, cardiothoracic surgery, and other departments; 3-dimensional unique-hot encoding is used for thrombotic history, corresponding to three categories: no history of thrombotic disease, history of deep vein thrombosis (DVT), and history of pulmonary embolism (PE); [further details omitted]. The variables include four variables: age, D-dimer, Caprini score, and length of hospital stay. Each variable is mapped to the [0,1] interval through Min-Max normalization. The above 8-dimensional, 6-dimensional, 3-dimensional, and 4-dimensional features are added together to form a 21-dimensional feature vector. After all encoding is completed, the 17-dimensional one-hot encoded vector is concatenated with the 4-dimensional normalized vector to form the 21-dimensional standardized feature vector. The above classification and normalization parameters are only examples. Different hospitals can make adaptive adjustments according to their own department settings, surgical classification standards, and case data distribution characteristics, all of which are within the protection scope of this invention.

[0103] (4) Model training: Preferably, the CVAE model is trained offline, using existing desensitized real cases from the test library as the training set. The training set is divided into training data and validation data in an 8:2 ratio.

[0104] Preferably, the objective function (loss function) of the CVAE model consists of three parts: Reconstruction Loss: Measures the difference between generated data and input data, using binary cross-entropy or mean squared error.

[0105] KL Divergence Loss: Measures the difference between the encoded latent variable distribution and the standard normal distribution.

[0106] Maximum Mean Discrepancy Loss (MDD): Measures the difference between the distribution of generated data and the distribution of real data, ensuring that the statistical properties of the simulation data are consistent with those of the real data.

[0107] The total loss function is: L total = L recon + β KL · L KL + β MMD · L MMD Where, β KL and β MMD These are weighting coefficients that control the proportion of KL divergence loss and MMD loss in the total loss, typically set to β. KL =0.5, β MMD =0.3.

[0108] Preferably, the termination condition for model training is: the total loss on the validation set no longer decreases for 10 consecutive epochs, or the preset maximum number of training epochs is reached (e.g., 200 epochs).

[0109] 3. Data generation and scaling factor control: Preferably, after model training is complete, simulation data is generated based on the data gap ratio of the test scenario. The formula for calculating the data gap ratio is: Data gap ratio = Number of valid cases in production database / Number of valid cases in test database For example, if the production database contains 1 million records and the test database contains 80,000 records, the data gap ratio is 12.5, which is rounded up to 12. This means that the test database needs to be expanded by 12 times.

[0110] Preferably, the generation process employs a batch generation method: 50,000 simulated cases are generated each time, and this process is repeated until the target number is reached. Each generation involves inputting a different random noise vector and corresponding scene condition labels to ensure data differences between batches and avoid data duplication.

[0111] Preferably, the generated simulated cases undergo hard clipping of clinical indicator ranges before output to ensure that all clinical indicator values ​​fall within medically reasonable ranges. For example: Age is cut off to [0, 120] years; D-dimer was cut off to [0, 50] mg / L; Caprini scores are truncated to [0, 20] points; The length of hospital stay is cut off to [1,365] days.

[0112] 4. Distribution consistency correction: As a preferred approach, after the simulation data is generated, the system performs a distribution consistency check to ensure that the statistical distribution of the simulation data is consistent with the actual data in the production database.

[0113] As a preferred method, the Kolmogorov-Smirnov test is used to verify the consistency of distributions. For each continuous variable (such as age, D-dimer, etc.), the KS statistic is calculated between the distribution of the simulated data and the distribution of the production database data. If the p-value is greater than 0.05 (i.e. the null hypothesis that "the two distributions are the same" cannot be rejected), the distributions are considered to be consistent; if the p-value is less than 0.05, distribution correction is triggered.

[0114] As a preferred method, the specific approach to distribution correction is to perform stratified resampling on the simulation data, using the proportion of stratified cases in the production database as a benchmark. For example, if orthopedic surgery patients account for 30%, general surgery patients account for 25%, and obstetrics and gynecology surgery patients account for 20% in the production database, then the simulation data is resampled in the same proportion to ensure that the proportion of cases at each level is consistent with that in the production database.

[0115] As a preferred option, after distribution correction, the KS test is performed again for verification. If it still fails, a second round of correction is performed until the KS test p-values ​​for all key variables are greater than 0.05 or the maximum number of corrections is reached (e.g., 5 times).

[0116] 5. Privacy anonymization and data lifecycle management: As a preferred option, the training samples for the CVAE model have undergone privacy desensitization processing before being input into the model: information that can directly or indirectly identify the patient, such as name, hospital number, ID number, and contact information, has been removed; the training samples retain only medical feature fields related to VTE risk assessment.

[0117] As a preferred option, the simulation data generated by the CVAE model consists only of structured numerical values ​​and does not contain any real patient identification information; all simulation data is not related to real patients and cannot be traced back to any specific individual, fully complying with the Personal Information Protection Law of the People's Republic of China and medical data privacy compliance requirements.

[0118] Preferably, the simulation data resides only in system memory (RAM) during test execution and is not written to any persistent storage medium (such as hard disk, database, SD card, etc.). After the test, the system automatically performs memory cleanup and destroys all simulation data. The data destruction method is to overwrite all the buffers in memory that store simulation data with zero (Zeroization) or random numbers (Secure Erasure) to ensure that the data cannot be recovered.

[0119] As a preferred approach, for the same test scenario that needs to be executed multiple times, simulation data is regenerated for each test, without using the previously generated cached data, thus avoiding the accumulation of distribution offset caused by data reuse.

[0120] Complete Data Compensation Process Example Taking a specific test of annual VTE case statistics as an example: Step 1: The environmental perception module detected 80,000 valid cases in the test library and 1 million valid cases in the production library, resulting in a data gap of 92%, triggering compensation. Step 2: Calculate the data gap ratio to be 12.5, round it to 12. Step 3: Input 80,000 real cases into the CVAE model and set the scene condition label to "batch statistical scene"; Step 4: Generate simulation data in batches of 50,000 samples each, for a total of 19 batches (the last batch has less than 50,000 samples), totaling 920,000 simulation cases; Step 5: Merge 80,000 real cases with 920,000 simulated cases to form a test dataset of 1 million. Step 6: Perform the KS test. The p-value for the age distribution is 0.32, the p-value for the D-dimer distribution is 0.18, and the p-value for the Caprini score distribution is 0.41. All key variables have p-values ​​greater than 0.05, indicating that the distribution consistency is satisfactory. Step 7: During the test execution, 1 million data entries reside in memory to simulate the query pressure of a real production database; Step 8: After the test is completed, all 920,000 simulation data sets will be automatically destroyed.

[0121] Example 4: Cooperative Scheduling of Three Adaptive Strategies like Figure 1-4As shown, this embodiment describes a priority-coordinated scheduling mechanism for three strategies: network fluctuation adaptation, old terminal adaptation, and test library data compensation.

[0122] As a preferred approach, the three strategies are prioritized as follows (from highest to lowest): Highest priority: Adaptive testing of legacy terminals – Terminal identification and protocol downgrade must be completed during the test script loading phase; otherwise, the test cannot start.

[0123] Second highest priority: Network fluctuation adaptation – Changes in network status directly affect whether the test can continue to run, requiring real-time response.

[0124] Basic priority: Test library data compensation - Data volume detection is completed before the test starts, and the compensation results serve as the basic data environment for the test.

[0125] As a preferred approach, when multiple interferences coexist, the system performs adaptation in order of priority: first, it identifies outdated terminals and downgrades protocols; then, it detects and compensates for test library data; and finally, it monitors and responds to network fluctuations in real time during the test run.

[0126] As a preferred approach, the adaptation results of the three strategies are independent of each other and do not interfere with each other: adaptation of old terminals only affects the execution method on the terminal side and does not affect network fluctuation detection and data compensation; data compensation only affects the size and distribution of the test dataset and does not affect terminal adaptation and network adjustment; network fluctuation adjustment only affects the number of concurrent connections and the data transmission rhythm and does not affect terminal type identification and test data content.

[0127] To verify the overall effect of the synergistic effect of the three types of adaptive strategies in this invention, the same VTE performance test task was executed under three different configurations: Control Group 1 (no adaptive strategy): Performed in a standard test environment, without enabling network fluctuation adaptation, old terminal adaptation, and data compensation. Test results: With 500 concurrent terminals, the test was interrupted 3 times due to network fluctuations, the IE11 terminal script error rate was 62%, and the QPS was artificially high due to insufficient test library data (45% higher than the actual production environment). The overall test cycle was approximately 6.5 hours.

[0128] Control Group 2 (Single-type strategy enabled only): One strategy from network fluctuation adaptation, old terminal adaptation, or data compensation was enabled individually. Test results: After enabling a single-type strategy, the corresponding type of problem was improved (network interruption reduced to 0 times, IE11 error rate reduced to 5%, QPS error reduced to 8%), but the other two types of problems still existed. The overall test period was approximately 4.2-5.0 hours.

[0129] Experimental Group (simultaneous activation of three types of strategies): Three types of adaptive strategies were activated simultaneously. Test results: 0 network interruptions, 0% error rate in IE11 terminal, QPS error controlled within 3%, and the overall test cycle shortened to 2.8 hours.

[0130] The above comparative experiments show that when the three strategies work together, the overall test cycle (2.8 hours) is 70% shorter than the optimal value of a single strategy, the test interruption rate is reduced to 0, and the script compatibility is improved to 100%. The synergistic effect of the three strategies complements each other in the three dimensions of network, terminal, and data: network fluctuation adaptation ensures the stability of the transport layer, old terminal adaptation eliminates execution obstacles at the terminal layer, and data compensation ensures the authenticity of the pressure at the data layer.

[0131] Example 5: Alternative Example As a preferred embodiment, the specific values ​​in the above embodiments (such as RTT grading threshold of 100ms / 300ms, concurrency adjustment coefficient of 0.6 / 0.8 / 1.0, minimum number of terminals of 50, batch interval of 80ms, gradient recovery step size of 10%, IE11 polling interval of 800ms, etc.) are all illustrative examples. In actual applications, they can be flexibly adjusted according to the hospital network environment baseline, terminal configuration and testing requirements.

[0132] As a preferred approach, in addition to HTTP / 1.1 short polling, long polling or an automatic degradation scheme based on SockJS can also be used for protocol degradation in the adaptation of older terminals.

[0133] As a preferred option, in addition to CVAE, other generative models can be used for the test library data compensation model, such as variational autoencoders (VAE), generative adversarial networks (GAN) or their variants (such as WGAN, DCGAN, etc.), as long as they can preserve the distribution characteristics of clinical indicators and meet the privacy desensitization requirements.

[0134] As a preferred option, in addition to Min-Max normalization, continuous variable normalization in feature engineering coding can also use Z-score standardization (mean of 0, standard deviation of 1) or Robust standardization (based on median and interquartile range).

[0135] Preferred methods for RTT measurement in network fluctuation detection include active ICMP probes, passive monitoring (analyzing the actual round-trip time of TCP connections), or a hybrid method (combining active probes and passive monitoring).

[0136] Preferred methods include, in addition to fixed-step gradient recovery, exponential backoff recovery (fast at first, slow later) or adaptive recovery based on real-time feedback of network quality, for concurrent recovery after network recovery.

[0137] As a preferred approach, in addition to User-Agent string matching, the identification of older terminals can also be combined with feature detection, such as detecting whether the WebSocket constructor exists and whether Promise is natively supported, to comprehensively determine the terminal's compatibility level.

[0138] Example 6: System Hardware Example like Figure 5 As shown, this embodiment describes the overall structure and workflow of an adaptive device for VTE performance testing in a hospital clinical environment. For details of the specific implementation of each module, please refer to Embodiments 1 to 3.

[0139] The following is a further description of the adaptive VTE performance testing device for a hospital clinical environment according to this embodiment: 1. Overall composition of the device: like Figure 5 As shown, this adaptive device is deployed in the control layer of the VTE performance testing system and includes four functional modules: Environment Awareness Module: Responsible for capturing interference factors in the hospital's VTE testing environment at a preset period (default 2 seconds). Interference factors include network status parameters (RTT, packet loss rate, bandwidth jitter), terminal type information (User-Agent, browser version), and test database data volume information (total number of valid cases). Network fluctuation adaptation module: responsible for dynamically adjusting the number of concurrent terminals according to the network quality level, splitting batch data transmission into batches when the network deteriorates, and gradually increasing the concurrency after the network recovers; The legacy terminal adaptation module is responsible for performing protocol downgrading (WebSocket → HTTP short polling) and front-end script compatibility conversion (ES6 → ES5, Polyfill, Fetch → XMLHttpRequest) on legacy terminals such as Windows 7 and IE11, and separating the new and old terminals into independent load testing groups. Data compensation module: responsible for detecting the amount of case data in the test database. When the number of valid cases in the test database is less than 10% of the production database, the CVAE data compensation model is activated to generate simulation data to expand the test dataset.

[0140] Preferably, the four modules can be deployed on the same physical server (such as the VTE test control node) or distributed across multiple nodes, with the modules communicating with each other via an internal message bus (gRPC or message queue).

[0141] 2. Overview of the functions of each module: The environmental perception module collects data on three types of interference factors through two methods: active detection (ICMP Ping) and passive listening (analyzing HTTP request headers and querying the database). The collected results are stored in a memory cache in a structured data format for other modules to read in real time.

[0142] The network fluctuation adaptation module reads network status parameters from the environment awareness module, classifies network quality into three levels—excellent, medium, and poor—based primarily on RTT latency, determines the corresponding concurrency adjustment coefficient, calculates the adjusted concurrency count, and takes the larger value between this and the minimum guaranteed number of terminals (default 50) as the actual concurrency count. It then sends concurrency adjustment instructions to the test execution unit via API. Simultaneously, it triggers batch splitting during network degradation and performs gradient recovery after network recovery.

[0143] The legacy terminal adaptation module reads terminal type information from the environment awareness module, identifies Windows 7+IE11 terminals through User-Agent matching, downgrades WebSocket long connections to HTTP / 1.1 short polling (interval of 800ms) at the request level, and performs compatibility operations such as ES6→ES5 transpilation, Promise Polyfill injection, Fetch→XMLHttpRequest downgrade, Flex→float layout conversion, and WebGL / SVG→static image replacement at the script level, and assigns independent load testing groups.

[0144] The data compensation module reads the data volume information of the test library from the environmental perception module, calculates the data gap ratio, and triggers compensation when the gap ratio is ≥90%. It loads the pre-trained CVAE model, generates a structured virtual case dataset with desensitized real VTE case samples as input, and merges them into a complete test dataset after the distribution is corrected by KS test.

[0145] 3. Device working process: Before the test starts, the environment awareness module checks the amount of data in the test library. If it is insufficient, the data compensation module is triggered to generate simulation data. During the test, the old terminal adaptation module identifies old terminals and performs protocol downgrading and script conversion, isolating new and old terminals in groups. During the test, the network fluctuation adaptation module continuously monitors the network status and dynamically adjusts the number of concurrent connections and batch transmission strategies. The three strategies are coordinated and scheduled according to priority (old terminal adaptation has the highest priority, followed by data compensation, and network fluctuation adaptation has the lowest priority), and the adaptation results do not interfere with each other.

[0146] 4. Inter-module communication: The environment awareness module provides real-time environmental data to the other three modules through a shared memory cache; the network fluctuation adaptation module, the legacy terminal adaptation module, and the data compensation module issue adaptation commands to the test execution unit through the gRPC interface, or modify test configuration parameters through internal APIs. The running status and adaptation records of each module are synchronously written to the log storage for traceability by the results analysis module.

[0147] Example 7: Electronic Device Example This embodiment provides an electronic device that can execute the above-described method embodiments.

[0148] like Figure 6 As shown, the electronic device 1 includes, but is not limited to: a memory 11, a processor 12, a display 13, and a network interface 14. The electronic device 1 connects to the network through the network interface 14 to obtain raw data or upload recognition results. The network can be an intranet, the Internet, a 4G / 5G network, Wi-Fi, etc.

[0149] The memory 11 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc. In this embodiment, the memory 11 can be an internal storage unit of the electronic device 1 (e.g., hard disk or memory) or an external storage device. The memory 11 is used to store the operating system and various application software installed on the electronic device 1, such as storing the program code of the VTE performance test adaptive program 10 described in this invention.

[0150] The processor 12 may be a central processing unit (CPU), controller, microcontroller, microprocessor or other data processing chip. The processor 12 is used to control the overall operation of the electronic device 1, such as performing data interaction or communication-related control and processing. In this embodiment, the processor 12 is used to run the program code stored in the memory 11, such as running the VTE performance test adaptive program 10, to implement any of the steps described in the above method embodiments.

[0151] The display 13 is used to display information processed in the electronic device 1 and to display a visual working interface, such as a rich text editor interface and filled document content.

[0152] Network interface 14 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface), which is typically used to establish a communication connection between electronic device 1 and other electronic devices (such as an HIS server).

[0153] Figure 6 Only an electronic device 1 having components 11-14 and procedure 10 is shown, but it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0154] Example 8: Example of a computer-readable storage medium The present invention also proposes an embodiment of a computer-readable storage medium, which may be non-volatile or volatile, and may be any one or any combination of several of the following: hard disk, multimedia card, SD card, flash memory card, SMC, read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), and USB memory.

[0155] The computer-readable storage medium stores a VTE performance testing adaptive program, which, when executed by a processor, can perform all or part of the steps described in the above method embodiments.

[0156] The specific implementation of the computer-readable storage medium of the present invention is largely the same as the specific implementation of the above-described adaptive method for VTE performance testing, and will not be repeated here.

[0157] The above are merely preferred embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An adaptive method for VTE performance testing in a hospital clinical environment, characterized in that, Includes the following steps: Step 1: Capture interference factors in the VTE testing environment within the facility at a preset period. The interference factors include at least one of network status parameters, terminal type information, and test library data volume information. Step 2: In response to the detection of network bandwidth jitter or increased latency, adjust the number of concurrent terminals according to the network quality level and split the batch data transmission into batches; Step 3: In response to the detection of old terminals performing VTE scale testing, switch to the lightweight load testing protocol and perform compatibility conversion on the front-end script, and separate the old and new terminals into independent load testing groups; Step 4: In response to the detection of insufficient case data in the test database, the data compensation model is activated to generate simulation data to expand the test dataset; Steps 2, 3, and 4 are executed collaboratively according to a preset priority, and the adaptation results of each step are independent of each other.

2. The adaptive method for VTE performance testing in a hospital clinical environment according to claim 1, characterized in that, Step 2, which adjusts the number of concurrent terminals according to the network quality level, includes: Network quality levels are classified based on network round-trip latency as the main indicator. A concurrency adjustment coefficient is determined based on the network quality level, and the number of concurrent terminals is adjusted according to the concurrency adjustment coefficient.

3. The adaptive method for VTE performance testing in a hospital clinical environment according to claim 2, characterized in that, Step 2, which adjusts the number of concurrent terminals according to the network quality level, also includes: Network quality levels are classified based on RTT (Round-Trip Time) as the main indicator, including at least: excellent level when RTT is less than a first threshold, medium level when RTT is greater than or equal to the first threshold and less than a second threshold, and poor level when RTT is greater than or equal to the second threshold; the poor level is further divided into at least two sub-levels according to the degree of jitter. The first concurrent adjustment coefficient corresponds to the excellent level, the second concurrent adjustment coefficient corresponds to the medium level, the third concurrent adjustment coefficient corresponds to the milder jitter in the poor level, and the fourth concurrent adjustment coefficient corresponds to the severe jitter in the poor level. The fourth concurrency adjustment coefficient is less than the third concurrency adjustment coefficient, the third concurrency adjustment coefficient is less than the second concurrency adjustment coefficient, and the second concurrency adjustment coefficient is less than the first concurrency adjustment coefficient; The larger of the adjusted concurrent number and the minimum guaranteed number of terminals is used as the actual concurrent number.

4. The adaptive method for VTE performance testing in a hospital clinical environment according to claim 1, characterized in that, Step 2, which involves splitting the batch data transmission into batches, includes: Increase the transmission interval between batches to split a single batch of data into multiple batches and send them sequentially.

5. The adaptive method for VTE performance testing in a hospital clinical environment according to claim 4, characterized in that, Step 2, which involves splitting batch data transmission into multiple data transfer batches, also includes: Record network fluctuation parameters, and perform linear correction on the test indicators based on the network fluctuation parameters; After the network recovers, the number of concurrent connections will gradually increase according to the preset gradient.

6. The adaptive method for VTE performance testing in a hospital clinical environment according to any one of claims 1-5, characterized in that, Step 3, which involves switching the lightweight load testing protocol and performing compatibility conversion on the front-end script, includes: The WebSocket long-connection load test was downgraded to HTTP short polling, and the front-end script was converted for compatibility.

7. The adaptive method for VTE performance testing in a hospital clinical environment according to claim 6, characterized in that, The compatibility conversion of the front-end script includes at least one of the following: Translate ES6 syntax into ES5 syntax; Inject a Polyfill into a Promise asynchronous object; Degrade the Fetch API to an XMLHttpRequest request; Remove animated vector graphics and replace them with static images; Switch from Flexbox to float layout.

8. The adaptive method for VTE performance testing in a hospital clinical environment according to any one of claims 1-5, characterized in that, Step 4, which involves starting the data compensation model to generate simulation data, includes: Check whether the proportion of the total number of cases in the test database to the effective cases in the production database is lower than a preset threshold; When the threshold is lower than the preset threshold, the data compensation model is activated, taking desensitized real VTE case samples and test scenario condition labels as input, and outputting a structured virtual thrombosis case dataset. The data compensation model performs one-hot encoding on the input discrete variables and Min-Max normalization on the input continuous variables, concatenating them to form a multi-dimensional standardized feature vector. The loss function of the data compensation model is superimposed with the distribution constraint loss, and the generated simulation data is subjected to distribution consistency verification. After the verification is qualified, it is merged with the real case data to form a test dataset. The simulation data resides only in the test memory and is automatically destroyed after the test is completed.

9. The adaptive method for VTE performance testing in a hospital clinical environment according to any one of claims 1-5, characterized in that, Steps 2, 3, and 4 are configured with priority and coordinated scheduling, and are executed sequentially according to preset priorities to adapt to multiple environmental interferences in the hospital: Step 3 is executed during the test script loading phase, Step 4 is executed before the test starts, and Step 2 is executed in real time during the test run; Step 3 has a higher priority than Step 2 and Step 4, and Step 4 has a higher priority than Step 2. In step 3, the old and new terminals are separated into independent stress testing groups, and test indicators are collected separately to isolate the interference of the old terminals on the overall testing process.

10. An adaptive device for VTE performance testing in a hospital clinical environment, characterized in that, include: An environment awareness module is used to capture interference factors in the VTE testing environment within the institute at a preset period. The interference factors include at least one of network status parameters, terminal type information, and test library data volume information. The network fluctuation adaptation module is used to adjust the number of concurrent terminals and split batch data transmission into batches when network bandwidth jitter or latency increase is detected. The legacy terminal adaptation module is used to switch the lightweight load testing protocol and perform compatibility conversion of the front-end script when the legacy terminal is identified to perform VTE scale testing, and to separate the new and old terminals into independent load testing groups. The data compensation module is used to generate simulation data to expand the test dataset when the amount of case data in the test library is insufficient.

Images