Interface test and electromagnetic lock replacement method and device, electronic equipment and readable medium

Abstract

Embodiments of the present disclosure disclose an interface test and electromagnetic lock replacement method, device, electronic equipment and readable medium. A specific embodiment of the method comprises: generating an atomized interface configuration file sequence corresponding to test request information; loading an environment variable pool from a preset storage; sequentially for each atomized interface configuration file in the atomized interface configuration file sequence, performing the following test steps: injecting the environment variable pool and the operation configuration parameter information in the atomized interface configuration file into the execution context of an external test script file; updating the current environment variable pool; initiating an operation request to the electromagnetic lock of the cabinet access control equipment; in response to determining that each interface test data generated indicates that the lock control operation test fails, controlling the relay and lock replacement mechanical arm on the cabinet access control equipment to replace the electromagnetic lock with a backup electromagnetic lock. This embodiment reduces the number of times the cabinet door cannot be normally opened or closed or the electromagnetic lock is replaced by mistake.

Description

Technical Field

[0001] Embodiments of this disclosure relate to the field of computer technology, and more specifically to interface testing and electromagnetic lock replacement methods, apparatus, electronic devices, and readable media. Background Technology

[0002] With the increasing demand for equipment security management in data centers, server rooms, and other similar locations, rack access control equipment, as a crucial facility for ensuring the security of equipment within racks, is of paramount importance in terms of stability and reliability. Electromagnetic locks, as a key locking component in rack access control equipment, directly impact the security of the rack. To ensure the proper functioning of electromagnetic locks, regular interface testing is necessary to verify their locking operation functionality. Interface testing and electromagnetic lock replacement are techniques for testing and replacing the interfaces of electromagnetic locks in rack access control equipment. Currently, the common method for testing and replacing electromagnetic lock interfaces in rack access control equipment is to use traditional interface testing tools to store all interface requests and scripts in a single large file, execute this file to test the electromagnetic lock interface, and then replace the electromagnetic lock based on the test results.

[0003] However, when testing the interface of the electromagnetic lock in the cabinet access control equipment and replacing the electromagnetic lock using the above method, the following technical problems often occur: Because all interface requests and test scripts are mixed in the same large file, Git version control conflicts occur frequently and test scripts cannot be maintained independently. Storing all interface requests and scripts in a single large file will make the file extremely large and complex as test requirements continue to change and increase. When modifying, updating or adding new test scripts to the file content, it is easy to make operational errors, resulting in file corruption or test logic errors. This will lead to missed or false alarms for real faults of the electromagnetic lock (such as coil burnout, contact sticking, mechanical jamming), which in turn will cause the cabinet door to fail to open and close normally or increase the number of times the electromagnetic lock is replaced due to incorrect triggering.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not form prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure provide methods, apparatus, electronic devices, and computer-readable media for interface testing and electromagnetic lock replacement to address one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide an interface testing and electromagnetic lock replacement method. The method includes: responding to receiving a test request information from a user-inputted cabinet access control device for an electromagnetic lock; scanning a pre-created set of atomic interface configuration files corresponding to the test request information in a preset memory to generate a sequence of atomic interface configuration files corresponding to the test request information, wherein each atomic interface configuration file stores operation configuration parameter information and reference path information pointing to an external test script file; loading an environment variable pool from the preset memory; and sequentially performing the following test steps on each atomic interface configuration file in the sequence of atomic interface configuration files: loading the external test script file pointed to by the reference path information in the atomic interface configuration file. This document describes how to inject the environment variable pool and operation configuration parameter information from the atomic interface configuration file into the execution context of an external test script file to execute test tasks in a pre-created sandbox environment and obtain execution result data. Based on the execution result data, the current environment variable pool is updated, and the updated environment variable pool is used as the environment variable pool for subsequent execution of the above test steps in the atomic interface configuration file. Based on the above operation configuration parameter information, an operation request is initiated to the electromagnetic lock of the cabinet access control device to obtain actual response data and generate interface test data. In response to the determination that the generated interface test data indicates that the lock control operation test has failed, the relays and lock-changing robotic arms on the cabinet access control device are controlled to replace the electromagnetic lock with a backup electromagnetic lock.

[0008] Secondly, some embodiments of this disclosure provide an interface testing and electromagnetic lock replacement device. The device includes: a scanning unit configured to, in response to receiving a test request information from a user-inputted cabinet access control device regarding an electromagnetic lock, scan a pre-created set of atomic interface configuration files corresponding to the test request information in a preset memory to generate a sequence of atomic interface configuration files corresponding to the test request information, wherein each atomic interface configuration file stores operation configuration parameter information and reference path information pointing to an external test script file; a loading unit configured to load an environment variable pool from the preset memory; and a testing unit configured to sequentially perform the following test steps on each atomic interface configuration file in the sequence: loading the reference path information in the atomic interface configuration file. The system points to an external test script file and injects the environment variable pool and operation configuration parameter information from the atomic interface configuration file into the execution context of the external test script file to execute test tasks in a pre-created sandbox environment and obtain execution result data. Based on the execution result data, the current environment variable pool is updated and used as the environment variable pool for subsequent execution of the above test steps in the atomic interface configuration file. Based on the above operation configuration parameter information, an operation request is initiated to the electromagnetic lock of the cabinet access control device to obtain actual response data and generate interface test data. The replacement unit is configured to respond to the determination that the generated interface test data indicates that the lock control operation test has failed, and control the relay and lock-changing robotic arm on the cabinet access control device to replace the electromagnetic lock with a backup electromagnetic lock.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0011] The above-described embodiments of this disclosure have the following beneficial effects: The interface testing and electromagnetic lock replacement methods of some embodiments of this disclosure reduce the number of times the cabinet door cannot be opened or closed normally or the electromagnetic lock is incorrectly triggered for replacement. Specifically, the reason for the increased number of times the cabinet door cannot be opened or closed normally or the electromagnetic lock is incorrectly triggered for replacement is that: because all interface requests and test scripts are mixed in the same large file, Git version control conflicts occur frequently, and the test scripts cannot be maintained independently. Storing all interface requests and scripts in a single large file makes the file extremely large and complex as testing requirements change and increase. When modifying, updating, or adding new test scripts to the file content, operational errors are easily made, leading to file corruption or test logic errors. This results in missed or false alarms for actual electromagnetic lock faults (such as coil burnout, contact adhesion, mechanical jamming), thus increasing the number of times the cabinet door cannot be opened or closed normally or the electromagnetic lock is incorrectly triggered for replacement. Based on this, the interface testing and electromagnetic lock replacement method of some embodiments of this disclosure firstly, in response to receiving a test request information for the electromagnetic lock in the cabinet access control device input by a user, scans a pre-created set of atomic interface configuration files corresponding to the test request information in a preset memory to generate a sequence of atomic interface configuration files corresponding to the test request information. Each atomic interface configuration file stores operation configuration parameter information and reference path information pointing to an external test script file. Thus, a scan can be performed on the set containing various independent atomic configuration files to find the sequence of atomic interface configuration files corresponding to the test request information. The separate storage of atomic configuration files allows for automatic merging when multiple users modify different interfaces, eliminating version control conflicts. Next, an environment variable pool is loaded from the preset memory. Then, the following test steps are performed sequentially on each atomic interface configuration file in the sequence: First, the external test script file pointed to by the reference path information in the atomic interface configuration file is loaded, and the environment variable pool and the operation configuration parameter information in the atomic interface configuration file are injected into the execution context of the external test script file to execute the test task in a pre-created sandbox environment and obtain execution result data. Therefore, each test script executes in an independent sandbox environment, without interfering with each other, and can accurately obtain the required environment variables and operation configuration parameters, ensuring the accuracy and stability of the test and reducing test logic errors caused by incorrect environment variables or configuration parameters. The second step involves updating the current environment variable pool based on the execution result data, and using the updated environment variable pool as the environment variable pool for subsequent execution of the above test steps using atomic interface configuration files.This enables dynamic environment variable propagation, ensuring that subsequent tests dependent on preceding interfaces (such as token acquisition) can be executed accurately. Environment variables are dynamically updated based on test results, ensuring subsequent tests are based on the latest environmental state, further improving test accuracy and aiding in accurately determining whether the electromagnetic lock is faulty. The third step involves initiating an operation request to the electromagnetic lock of the cabinet access control device based on the aforementioned operation configuration parameters, obtaining actual response data to generate interface test data. This provides actual response data that accurately reflects the working state of the electromagnetic lock, completing the testing of the electromagnetic lock interface. Finally, in response to the generated interface test data indicating a lock control operation test failure, the relays and lock-changing robotic arm on the cabinet access control device are controlled to replace the electromagnetic lock with a backup electromagnetic lock. This allows for driving the replacement action based on test results to replace the damaged electromagnetic lock. Because of the use of atomic configuration file separation storage, version control conflicts are eliminated, and problems such as inaccurate testing, file corruption, or test logic errors caused by a single large file are solved. The use of external script independent storage and dynamic updates of environment variables improves the maintainability of test scripts and the accuracy of test context, thereby avoiding the occurrence of missed or false alarms. It ensures that the electromagnetic lock is only replaced when it is actually malfunctioning, ensuring that the cabinet door can be opened and closed normally and reducing the number of times the cabinet door cannot be opened and closed normally or the electromagnetic lock is replaced due to incorrect triggering. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0013] Figure 1 This is a flowchart of some embodiments of the interface testing and electromagnetic lock replacement method according to this disclosure; Figure 2 This is a schematic diagram of the structure of some embodiments of the interface testing and electromagnetic lock replacement device according to this disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0014] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0015] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0016] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0017] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0018] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0019] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] Figure 1 A flow 100 of some embodiments of the interface testing and electromagnetic lock replacement method according to this disclosure is shown. The interface testing and electromagnetic lock replacement method includes the following steps: Step 101: In response to receiving the test request information of the electromagnetic lock in the cabinet access control device input by the user, scan the set of pre-created atomic interface configuration files corresponding to the test request information in the preset memory to generate the atomic interface configuration file sequence corresponding to the test request information.

[0021] In some embodiments, the execution entity of the interface testing and electromagnetic lock replacement method (e.g., a computing device, such as a server, personal computer, or embedded industrial control computer) can, in response to receiving a test request information from a user input regarding the electromagnetic lock in a rack access control device, scan a pre-created set of atomic interface configuration files corresponding to the aforementioned test request information in a preset memory to generate a sequence of atomic interface configuration files corresponding to the aforementioned test request information. Each atomic interface configuration file stores operation configuration parameter information and a reference path information pointing to an external test script file. The aforementioned test request information includes a test function module identifier. The test function module identifier can be the name of a function module that defines the test scope, for example, "door" represents the access control module, and "light" represents the lighting control module. The user can be a person maintaining the rack access control device. The rack access control device refers to an electronic lock control device installed on a rack for controlling the opening and closing of the rack door. The test request information can be a digital instruction representing a test request, specifying the electromagnetic lock to be tested and its interface, including a target device identifier, test type (e.g., open door, close door, status query), and optional function module identifiers. Operation configuration parameter information refers to the collection of fields recorded in the atomic interface configuration file that describe a specific interface request. The aforementioned reference path information refers to the string-based description in the atomic interface configuration file pointing to the location of the corresponding external test script file in the preset storage.

[0022] Optionally, the aforementioned implementing entity may also perform the following steps: The first step is to display the test data for each of the aforementioned interfaces on the preset rack access control device test page. This preset rack access control device test page can be a graphical user interface or a web-based console used to display the test data for each interface.

[0023] Optionally, the aforementioned implementing entity may also perform the following steps: The first step is to create a root directory folder in the aforementioned preset storage. The root directory folder is the top-level folder of the test project; its path is specified by the user or is the system default, and it contains all subfolders and configuration files of the entire test project. In practice, the executing entity can call directory creation functions provided by the operating system (such as `mkdir` in Linux or `CreateDirectory` in Windows) to generate a folder as the root directory folder at a specified path in the preset storage.

[0024] The second step is to create subfolders named after the functional module identifiers within the root directory folder. In practice, the execution entity can iterate through a pre-defined list of functional module identifiers, concatenate the subfolder path for each identifier (e.g., / data / cabinet_tests / 01-door / ), and then call the directory creation function to generate the subfolder.

[0025] Third, for each functional module subfolder, perform the following steps: The first sub-step involves creating a set of atomic interface configuration files corresponding to the functional module subfolder and storing this set within the same functional module subfolder. The atomic interface configuration file set refers to all atomic interface configuration files (files with the .yaml or .yml extension) stored within the same functional module subfolder. Each atomic interface configuration file corresponds to an independent test request for an interface (e.g., an open request or a close request). Each atomic interface configuration file contains operation configuration parameters (such as request method, URL, and request body parameters) and a reference path to an external test script file. In practice, the executing entity can generate one or more files with the .yaml extension based on a predefined template (e.g., containing default request methods, URLs, assertion rules, etc.) and write the content to the subfolder using file writing functions (such as fopen, fprintf, and fclose). Optionally, specifically, the executing entity can determine the filename of the functional module subfolder as the target functional module identifier. Then, it retrieves the pre-created set of YAML configuration files corresponding to the target functional module identifier from a preset storage location as the atomic interface configuration file set. The aforementioned pre-created set of YAML configuration files can be a set of independent YAML files that testers can manually write for each interface or generate using auxiliary tools according to the interface testing requirements.

[0026] The second sub-step involves creating a script subfolder within the aforementioned functional module subfolder. Each atomic interface configuration file stores operation configuration parameters and reference paths to external test script files. The script subfolder is a subdirectory within the functional module subfolder specifically designed to store external test script files (e.g., typically named `scripts`). Each atomic interface configuration file (i.e., a `.yaml` or `.yml` file) internally references a specific script file within this script subfolder (e.g., `post_request: / scripts / open_door.js`) using its reference path information. As an example, in the first step, the executing entity can obtain the full path of the functional module subfolder (e.g., ` / data / cabinet_tests / 01-door / `), and then append a predefined subfolder name (e.g., `scripts`) to that path to obtain the target path of the script subfolder (e.g., ` / data / cabinet_tests / 01-door / scripts / `). In the second step, the executing entity calls the operating system's directory creation function to generate the script subfolder. Specifically, the executing entity can call the directory creation API provided by the operating system (e.g., the `mkdir` function in Linux or the `CreateDirectory` function in Windows), passing the target path as a parameter. The operating system creates a directory named "scripts" in the file system. If this directory already exists, the executing entity can choose to skip it (without reporting an error) or overwrite it (delete and then create it), depending on the configuration. Typically, it skips it by default to avoid overwriting existing script files. After successful directory creation, the executing entity can log "Script subfolder created". When creating the atomic interface configuration file, the executing entity or tester will write a relative path to the script subfolder in the configuration file. The aforementioned script files need to be pre-written by the tester and manually or otherwise placed in this folder.

[0027] The third sub-step involves storing the pre-written set of external test script files in the aforementioned script subfolder, thus obtaining the external test script file set. Each atomic interface configuration file in the aforementioned atomic interface configuration file set corresponds to one external test script file in the aforementioned external test script file set.

[0028] In some optional implementations of certain embodiments, the execution entity may scan a pre-created set of atomic interface configuration files corresponding to the test request information in a preset memory through the following steps to generate a sequence of atomic interface configuration files corresponding to the test request information: The first step is to identify the subfolder in the preset storage that is named after the aforementioned test function module identifier as the target function module subfolder. The execution entity then uses directory traversal functions provided by the operating system (such as `opendir` and `readdir` in Linux, or `FindFirstFile` and `FindNextFile` in Windows) to open the root directory folder in the preset storage (the path is pre-configured). Next, it reads the names of all first-level subfolders under this root directory one by one. For each subfolder name, a string comparison function is called to compare it with the user-input test function module identifier, and the subfolder named after the aforementioned test function module identifier is identified as the target function module subfolder.

[0029] The second step is to determine the set of atomic interface configuration files stored in the target functional module subfolder as the set of atomic interface configuration files corresponding to the aforementioned test request information. The filename of each atomic interface configuration file in this set is prefixed with a numerical number.

[0030] The third step is to read the prefix of the atomic interface configuration files in the atomic interface configuration file set to obtain the set of numerical IDs.

[0031] The fourth step involves sorting the atomic interface configuration files in the set of atomic interface configuration files corresponding to the aforementioned test request information, based on the set of numerical IDs, to obtain a sequence of atomic interface configuration files. In practice, the execution entity uses a general sorting algorithm (such as quicksort, mergesort, or directly calls the built-in sort function of the programming language) to sort the numerical IDs in the set of numerical IDs in ascending order of integers. During sorting, the numerical IDs of two elements are compared; if the ID is smaller, it is placed first, resulting in a sequence of numerical IDs. After sorting, the sorted sequence of numerical IDs is traversed sequentially, and the atomic interface configuration file corresponding to each numerical ID in the set of atomic interface configuration files is retrieved in turn, resulting in a sequence of atomic interface configuration files.

[0032] Step 102: Load the environment variable pool from the preset memory.

[0033] In some embodiments, the execution entity can load an environment variable pool from the preset storage. The environment variable pool is a configuration file (e.g., dev.yaml, prod.yaml) containing a set of key-value pairs, stored in the preset storage, used to provide global or environment-related parameters for interface testing, such as the base URL, access token, username, and password.

[0034] Step 103: Perform the following test steps for each atomic interface configuration file in the atomic interface configuration file sequence in sequence: Step 1031: Load the external test script file pointed to by the reference path information in the atomic interface configuration file, and inject the environment variable pool and the operation configuration parameter information in the atomic interface configuration file into the execution context of the external test script file, so as to execute the test task in the pre-created sandbox environment and obtain the execution result data.

[0035] In some embodiments, the aforementioned execution entity can load an external test script file pointed to by the reference path information in the atomic interface configuration file, and inject the environment variable pool and operation configuration parameter information from the atomic interface configuration file into the execution context of the external test script file to execute test tasks in a pre-created sandbox environment and obtain execution result data. The external test script file can be a file containing executable code (such as JavaScript or Python) stored independently of the configuration file, used to implement complex test logic (e.g., extracting tokens from responses, updating environment variables). The sandbox environment is an isolated, controlled code execution space (e.g., a virtual machine created by the VM module in Node.js) used to prevent errors or malicious code in the script from affecting the main engine. Test tasks refer to the specific operations performed by the executed script (e.g., preprocessing, post-assertions, environment variable updates). Execution result data includes the script's original return value and environment update instruction information generated during script execution.

[0036] In some optional implementations of certain embodiments, the aforementioned execution entity can inject the environment variable pool and the operation configuration parameter information in the atomic interface configuration file into the execution context of the external test script file through the following steps, so as to execute the test task in a pre-created sandbox environment and obtain the execution result data: The first step is to obtain the source code content of the external test script file mentioned above, thus obtaining the script source code string.

[0037] The second step involves invoking the virtual machine module within the pre-created sandbox environment to create a secure sandbox instance, resulting in a sandbox environment object. The pre-created sandbox environment refers to an isolated execution environment prepared by the executing entity before the test begins or when initially needed, utilizing the virtual machine functionality provided by the programming language (e.g., Node.js's `vm` module, Python's `exec` function combined with global variable restrictions). The virtual machine module is an isolated component provided by the operating system or runtime for executing code. In practice, the executing entity calls the virtual machine module's creation function (such as `new vm.Sandbox()` or `vm.createContext()` in Node.js) to generate a new, clean sandbox instance. This instance has its own independent global object and does not share state with the main process or other sandboxes. This instance is stored as the sandbox environment object.

[0038] The third step is to mount the aforementioned environment variable pool as an environment property of the aforementioned sandbox environment object. In practice, the executing entity can create an environment property named a first preset property name (such as environment) in the sandbox environment object and assign the key-value pair set represented by the environment variable pool to the environment property.

[0039] The fourth step is to mount the above operation configuration parameter information as an operation parameter attribute of the sandbox environment object. In practice, you can create an operation parameter attribute named with a second preset attribute name (such as params or requestParams) in the sandbox environment object and assign the operation configuration parameter information to the operation parameter attribute.

[0040] The fifth step is to inject a pre-defined global environment variable setting function into the aforementioned sandbox environment object. This pre-defined global environment variable setting function is a utility function pre-defined by the execution entity for updating the environment variable pool.

[0041] The sixth step is to compile the script source code string into an executable function, resulting in a script function object. In practice, you can use the compilation functions provided by the virtual machine module (such as vm.compileFunction or newvm.Script in Node.js) to compile the script source code string into a callable function object.

[0042] Step 7: Within the scope of the aforementioned sandbox environment object, call the script function object to execute the script represented by the external test script file and obtain the original execution return value. In practice, the execution entity can execute the script represented by the external test script file within the context of the sandbox environment object using a virtual machine module's calling function (such as vm.runInContext or directly using script.runInNewContext) to obtain the original execution return value.

[0043] Step 8: During the execution of the script represented by the external test script file, when the script calls the preset global environment variable setting function, at least one key-value pair passed to the global environment variable setting function when it is called is extracted as environment update instruction information. The environment update instruction information refers to one or more key-value pairs generated during script execution by calling the preset global environment variable setting function. Each key-value pair contains a key name (e.g., access_token) and a key value (e.g., a specific token string).

[0044] Step 9: Determine the original execution return value and the environment update instruction information as the execution result data.

[0045] Step 1032: Based on the execution result data, update the current environment variable pool and use the updated environment variable pool as the environment variable pool for subsequent atomic interface configuration file execution test steps.

[0046] In some embodiments, the aforementioned execution entity can update the current environment variable pool based on the execution result data, and use the updated environment variable pool as the environment variable pool when the aforementioned test steps are executed in subsequent atomic interface configuration files. In practice, the aforementioned execution entity can modify the key value of the corresponding key name in the current environment variable pool, or add a non-existent key name, based on the key-value pairs in the environment update instruction information.

[0047] In some optional implementations of certain embodiments, the aforementioned execution entity may update the current environment variable pool based on the execution result data through the following steps: The first step is to sequentially perform the following steps on each key-value pair in at least one of the key-value pairs included in the above execution result data: The first sub-step involves searching the current environment variable pool for entries that correspond to the key names included in the key-value pairs.

[0048] The second sub-step involves replacing the key-value pairs in the aforementioned entries of the environment variable pool with the key-value pairs included in the aforementioned key-value pairs, thereby updating the environment variable pool.

[0049] Step 1033: Based on the operation configuration parameter information, initiate an operation request to the electromagnetic lock of the cabinet access control device, obtain the actual response data, and generate interface test data.

[0050] In some embodiments, the aforementioned execution entity may initiate an operation request to the electromagnetic lock of the aforementioned cabinet access control device based on the aforementioned operation configuration parameter information, and obtain actual response data to generate interface test data. The actual response data refers to the response message returned by the electromagnetic lock controller (e.g., JSON format {"code": 0, "message": "ok"}).

[0051] In the process of adopting technical solutions to solve the technical problems mentioned above, the automated testing of electromagnetic lock interfaces in the application scenarios—data centers, server rooms, and unattended cabinet access control systems—often presents the following technical problems: the extension and retraction of the electromagnetic lock's bolt has an inherent mechanical action time (usually tens to hundreds of milliseconds). Traditional fixed timeout mechanisms cannot adapt to the mechanical characteristics of different models of electromagnetic locks. If the timeout setting is too short, the physical action may not be completed before the timeout is judged as a timeout. Network communication has unpredictable delays and packet loss. A single request may easily misreport a momentary network failure as an electromagnetic lock failure, resulting in unnecessary replacement of the electromagnetic lock. Furthermore, relying solely on the digital response messages (such as "door opened successfully") returned by the electromagnetic lock controller for testing may result in inconsistencies between the response messages and the actual state. This fails to reflect whether the latch has actually moved or the door has actually opened (for example, the mechanical transmission structure of the electromagnetic lock has certain precision errors. Backlash in gear transmissions or elastic slippage in belt drives can cause the actual position of the latch to differ from the controller's expected position, leading to a failed opening operation and a returned message, even though the latch may have actually partially extended). This results in unnecessary replacement of the electromagnetic lock. To address the following requirements for this application scenario: adaptability to different electromagnetic lock models (e.g., setting a shorter timeout for faster-moving locks and a longer timeout for slower-moving locks), it is necessary not only to rely on the digital response messages from the electromagnetic lock controller but also to integrate physical sensor feedback to accurately verify whether the latch has actually moved and whether the door has effectively opened. Faced with these technical challenges, we have decided to adopt the following solution: In some optional implementations of certain embodiments, the execution entity may initiate an operation request to the electromagnetic lock of the cabinet access control device based on the operation configuration parameter information, and obtain actual response data to generate interface test data through the following steps: The first step is to perform a request message assembly operation based on the above operation configuration parameter information to obtain the request message to be sent. In practice, the above-mentioned execution entity can convert the operation configuration parameter information (including fields such as request method, URL, request header, and request body) into binary or text data packets that conform to the format of a specific protocol (such as HTTP) as the request message to be sent.

[0052] The second step involves obtaining the mechanical action duration of the electromagnetic lock on the aforementioned cabinet access control device, and generating a tolerance time threshold based on this duration. The mechanical action duration refers to the physical time required for the electromagnetic lock to complete its operation (e.g., extend or retract) from receiving a command. The tolerance time threshold refers to the maximum allowed time for the executing entity to wait for a response message after sending a request. In practice, the executing entity can read the mechanical action duration of the electromagnetic lock from a preset configuration file. Then, the executing entity adds a fixed offset (e.g., 300ms) or multiplies it by a safety factor (e.g., 1.5 times) to obtain the tolerance time threshold.

[0053] The third step is to perform network quality testing on the network connected to the aforementioned cabinet access control equipment to generate the number of probe rollbacks. In practice, the aforementioned execution entity can send an ICMP echo request (ping) to the electromagnetic lock controller and measure the round-trip time. If three consecutive packet losses or delays exceed a preset baseline, the network quality is judged to be poor, and the sum of the preset number of probe rollbacks and the preset number of incremental rollbacks is determined as the number of probe rollbacks. If three consecutive packet losses or delays do not exceed the preset baseline, the preset number of probe rollbacks is determined as the number of probe rollbacks.

[0054] The fourth step is to initialize the current probe count to a preset value. The probe rollback count refers to the maximum number of retries allowed after a request times out.

[0055] Fifth, based on the current query count, perform the following generation steps: The first sub-step involves sending the requested message to the electromagnetic lock of the cabinet access control device via a preset communication interface. This allows the electromagnetic lock controller to execute the physical locking action corresponding to the requested message, obtaining actual response data as a response message. The preset communication interface can be a network socket (TCP / IP), serial port, or industrial bus (such as RS485). The actual response data refers to the digital response message (e.g., an HTTP response, including status code and response body) received from the electromagnetic lock controller after the executing entity initiates an operation request to the electromagnetic lock of the cabinet access control device. In practice, the executing entity can use network sending functions provided by the operating system (such as send or write in Linux) to send the requested message to the IP address and port of the electromagnetic lock controller. After receiving the request, the electromagnetic lock controller parses the instruction and drives the electromagnetic lock to perform an unlocking or locking action (e.g., energizing the latch to retract). Simultaneously, the controller returns a response message (e.g., an HTTP response). A response message can contain a status line (e.g., HTTP / 1.1 200 OK), response headers (e.g., Content-Type: application / json), and a response body (e.g., {"code": 0", "message": "ok", "state": "opened"}). The response body includes the response status code (e.g., "code": 0).

[0056] The second sub-step involves determining the sending time as the request timestamp and generating a request time window based on the request timestamp and the tolerance threshold. In practice, the timeout point can be determined by adding the request timestamp to the tolerance threshold. Then, the time period from the request timestamp to the timeout point can be defined as the request time window.

[0057] The third sub-step involves performing the following steps within a preset time window following the request for the timestamp: In the first sub-step, the real-time current value of the electromagnetic lock coil is continuously acquired using a current sensor at a preset sampling frequency to obtain the lock current timing data. A current sensor (e.g., a Hall effect sensor or shunt resistor) is a device capable of detecting the magnitude of current in the electromagnetic lock's power supply circuit. It is typically connected in series on the electromagnetic lock's power line and outputs an analog voltage or digital signal proportional to the current. The lock current timing data is a series of current values ​​recorded in chronological order, reflecting the current change waveform of the electromagnetic lock coil during operation (e.g., the inrush current at the moment of energization, the holding current, and the decay after power failure). In practice, the actuator reads the output value of the current sensor using an analog-to-digital converter (ADC) at a preset sampling frequency. A current value is obtained at each sampling moment, and these values ​​are stored in an array in chronological order to form the lock current timing data.

[0058] Sub-step two involves continuously collecting door status timing data of the cabinet door using a door magnetic switch sensor at a preset sampling frequency. A door magnetic switch sensor is a switching sensor composed of a reed switch and a permanent magnet, typically installed on the cabinet door frame and panel. When the door is closed, the reed switch contacts close (or open); when the door is open, the contact state flips. Door status timing data refers to a sequence of changes in door opening / closing states (e.g., "closed" or "open") or door gap distance, recorded chronologically. In practice, the aforementioned execution unit can read the status value of the door magnetic switch via a digital input interface (GPIO) at a preset sampling frequency, recording the door state at each sampling moment (e.g., 1 indicates closed, 0 indicates open), thus forming the door status timing data.

[0059] Step three involves continuously collecting vibration waveforms of the cabinet door latch at a preset sampling frequency using a vibration sensor to obtain timing data of the latch movement characteristics. The vibration sensor (e.g., a piezoelectric accelerometer) is typically mounted on the cabinet surface near the electromagnetic lock latch to capture the impact vibration signals generated when the latch extends or retracts. The timing data of the latch movement characteristics refers to a sequence of vibration amplitudes recorded in chronological order, reflecting the timing and intensity of the latch movement, as well as any abnormalities such as jamming.

[0060] Sub-step four involves packaging the aforementioned lock current timing data, door state timing data, and lock tongue action characteristic timing data into a physical feedback data package. The physical feedback data package refers to combining the three types of timing data into a structured data object (e.g., a JSON object or binary data block) after time alignment (i.e., the sampling point at the sampling time simultaneously includes the current value, door state, and vibration amplitude). In practice, the executing entity creates a data container (such as a dictionary or structure) and stores the lock current timing data, door state timing data, and lock tongue action characteristic timing data as different fields to form the physical feedback data package.

[0061] The fourth sub-step, in response to the lack of a response message received within the aforementioned request time window and the current probe count being less than or equal to the probe rollback count, updates the current probe count by the sum of the current probe count and the preset cumulative count. Based on the updated current probe count, the generation step described above is executed again. The preset cumulative count is typically 1, meaning that each retry increments the current probe count by 1. The response message refers to the digital message returned by the electromagnetic lock controller. The current probe count is an integer variable recording the number of times the request has been attempted (initially 0). The probe rollback count refers to the maximum number of retries allowed after a request timeout (generated in the third step). The preset cumulative count is typically 1, meaning that each retry increments the current probe count by 1. In practice, the execution entity continuously checks whether a response message has been received within the request time window. If no response message is received by the timeout deadline, the current probe count is compared with the probe rollback count. If the current probe count is less than or equal to the probe rollback count, increment the current probe count by 1, then jump to the first sub-step, resend the pending request message, and repeat the entire fifth step (including re-timing and re-collecting physical parameters). If the current probe count is already greater than the probe rollback count, do not retry.

[0062] The fifth sub-step involves generating interface test data based on the response message received within the aforementioned request time window, using the response message and the physical feedback data packet. In practice, the status code corresponding to the test function module identifier in the aforementioned test request information can be obtained. Upon confirming that the status code matches the response status code in the response message, the difference between the maximum and minimum current values ​​in the physical feedback data packet is determined as the current difference. If the following conditions are met simultaneously: the current difference is greater than a preset current difference threshold; the physical feedback data packet contains a gate state changing from "0" (closed) to "1" (open) or from "1" to "0"; and the vibration amplitude sequence in the physical feedback data packet contains a preset number of consecutive vibration amplitudes exceeding a preset amplitude threshold, the information indicating a successful lock operation test is determined as interface test data. In response to determining that at least one of the following conditions is met: the status code is different from the response status code in the response message; the difference between the maximum current value and the minimum current value in the physical feedback data packet is determined to be a current difference value less than or equal to a preset current difference threshold; there is no status value in the physical feedback data packet where the gate state changes from "0" (closed) to "1" (open) or from "1" to "0"; and there is no consecutive preset number of vibration amplitude values ​​exceeding the preset amplitude threshold in the vibration amplitude sequence of the physical feedback data packet, the information characterizing the lock operation test failure is determined as interface test data.

[0063] The above technical solution, combined with step 104 and related content, serves as an inventive point of this disclosure, solving the technical problem of "causing unnecessary replacement of electromagnetic locks." Factors leading to unnecessary replacement of electromagnetic locks often include: the extension and retraction of the electromagnetic lock's bolt has an inherent mechanical action time (usually tens to hundreds of milliseconds). Traditional fixed timeout mechanisms cannot adapt to the mechanical characteristics of different models of electromagnetic locks, and are prone to timeouts due to excessively short timeout settings, resulting in timeouts before the physical action is completed. Network communication suffers from unpredictable delays and packet loss; a single request can easily misreport a momentary network failure as an electromagnetic lock malfunction, causing unnecessary replacement. Furthermore, testing solely based on the digital response message returned by the electromagnetic lock controller (such as "door opened successfully") may result in inconsistencies between the response message and the actual state, failing to reflect whether the bolt has actually moved or the door has actually opened (e.g., the mechanical transmission structure of the electromagnetic lock has certain precision errors. For example, backlash in gear transmission or elastic slippage in belt transmission can cause the actual bolt position to differ from the controller's expected position, leading to the assumption of a failed opening operation and a returned message, even though the bolt may have actually partially extended), resulting in unnecessary replacement of electromagnetic locks. If the above factors are addressed, unnecessary replacements of electromagnetic locks can be reduced. To achieve this, firstly, a request message assembly operation is performed based on the operation configuration parameter information to obtain a request message to be sent. The mechanical action duration of the electromagnetic lock of the cabinet access control device is obtained, and a tolerance duration threshold is generated based on this duration. This allows the timeout mechanism to adapt to the inherent mechanical action characteristics of different electromagnetic locks, avoiding misjudgment of incomplete physical actions due to excessively short timeouts. Next, network quality testing is performed on the network connected to the cabinet access control device to generate the number of probe rollbacks. The current probe count is initialized to a preset value. Based on the current probe count, the following steps are executed: a request message to be sent is sent through a preset communication interface, allowing the electromagnetic lock controller to execute the corresponding locking physical action and receive a response message. The sending time is determined as the request timestamp, and a request time window is generated based on the request timestamp and the tolerance duration threshold. Within this time window, the real-time current value of the electromagnetic lock coil is continuously collected by a current sensor to obtain lock current timing data, the door status timing data of the cabinet door is continuously collected by a door magnetic switch sensor, and the vibration waveform of the latch action is continuously collected by a vibration sensor to obtain latch action characteristic timing data. These three types of timing data are packaged into a physical feedback data packet. Thus, real physical evidence of latch action can be obtained from three dimensions: current, door status, and vibration, overcoming the deficiency that digital response messages alone cannot verify actual actions. If no response message is received within the requested time window and the current polling count is less than or equal to the number of polling backoffs, the current polling count is increased by a preset cumulative number and updated. Based on the updated count, the generation step (i.e., retrying to send the request) is executed again.Upon receiving a response message within the requested time window, interface test data is generated based on the response message and physical feedback data packets. This allows for tolerance of network latency and packet loss through a probing backoff count and multiple retry mechanisms, preventing the misreporting of transient network failures as electromagnetic lock malfunctions. Furthermore, the adoption of an adaptive mechanical action duration tolerance threshold, a network quality detection-driven retry mechanism, and a physical feedback verification method incorporating current / door magnetic / vibration sensors simultaneously addresses technical issues such as incompatibility with fixed timeouts, susceptibility to false alarms from single network requests, and inconsistencies between digital response messages and physical states, thus improving the realism and reliability of automated testing. Finally, in step 104, upon determining that the generated interface test data indicates a lock control operation test failure, the relays and lock-changing robotic arm on the aforementioned cabinet access control equipment are controlled to replace the electromagnetic lock with a backup electromagnetic lock. This allows for replacement of the electromagnetic lock based on highly realistic and reliable interface test data, reducing unnecessary electromagnetic lock replacements.

[0064] Step 104: In response to the determination that the generated interface test data indicates that the lock control operation test has failed, control the relays and lock-changing robotic arm on the cabinet access control device to replace the electromagnetic lock with a backup electromagnetic lock.

[0065] In some embodiments, the aforementioned execution entity may, in response to determining that the generated interface test data indicates a lock control operation test failure, control the relays and lock-changing robotic arm on the aforementioned cabinet access control device to replace the electromagnetic lock with a backup electromagnetic lock. In practice, in response to determining that at least one interface test data in the various interface test data indicates a lock control operation test failure, control the relays and lock-changing robotic arm on the aforementioned cabinet access control device to replace the electromagnetic lock with a backup electromagnetic lock. The aforementioned lock-changing robotic arm may be a multi-degree-of-freedom actuator composed of a base, joints, servo motors, grippers (end effectors), and a controller, capable of moving, positioning, gripping, and releasing objects in three-dimensional space according to a preset program or real-time commands.

[0066] In addressing the technical problems mentioned above, and considering the application scenario—the replacement of electromagnetic locks in data center, server room, and unattended rack access control systems—the following technical issues often arise: Due to long-term use or environmental factors, relays are prone to contact sticking, which prevents the sent power-off command from truly cutting off the electromagnetic lock's power supply circuit, easily causing short circuits during lock replacement. Simultaneously, during the unlocking process, the electromagnetic lock may jam due to rust, foreign objects, or mechanical failure; forcibly unlocking it could damage the robotic arm or the lock body. The following characteristics are required for this application scenario: automatic detection and handling of relay contact sticking; real-time monitoring of unlocking force and displacement to identify jamming faults and provide timely alarms. Faced with these technical problems, we decided to adopt the following solution: In some optional implementations of certain embodiments, the aforementioned execution entity can control the relays and lock-changing robotic arm on the aforementioned cabinet access control device through the following steps to replace the electromagnetic lock with a backup electromagnetic lock: The first step is to send a preset power-off command to the rack access control device to control the relay to disconnect the power supply circuit of the faulty electromagnetic lock. This preset power-off command can be a command to open the internal contacts of the relay on the rack access control device.

[0067] The second step involves using a current sensor to collect the current in the electromagnetic lock's power supply circuit, obtaining the current value after power failure. The current sensor is connected in series with the power supply circuit of the faulty electromagnetic lock, enabling real-time monitoring of the current in the circuit. The current value after power failure refers to the remaining current reading in the circuit after the relay disconnects.

[0068] The third step involves sending a preset number of pulse oscillation commands to the relay in response to the determination that the current value is not zero after the power outage. This drives the relay contacts to perform an oscillating separation operation. The non-zero current value after power outage indicates that the relay contacts may have stuck together due to arc welding and failed to truly disconnect. The pulse oscillation command can be a control signal that drives the relay contacts to perform the oscillating separation operation (e.g., turning on every 50 milliseconds, turning off every 50 milliseconds, repeated 5 times), using the mechanical impact generated by electromagnetic force to attempt to shake open the stuck contacts. The oscillating separation operation refers to the process of repeated contact engagement and disengagement.

[0069] The fourth step involves acquiring the power supply circuit current after the oscillation separation operation using a current sensor to obtain the post-oscillation current value. In practice, after completing a preset number of pulse oscillations, the actuator reads the current sensor value again to obtain the post-oscillation current value.

[0070] The fifth step involves determining that the current value is zero after the oscillation, and then acquiring the end-effector coordinates of the lock-changing robotic arm using position sensors to obtain the current position of the robotic arm. These position sensors can be encoders (e.g., photoelectric encoders or magnetic encoders) or laser trackers installed at various joints of the robotic arm, capable of outputting joint angles. Kinematic calculations are then performed to obtain the coordinates (X, Y, Z) of the end effector (gripper) in three-dimensional space. The current position of the robotic arm refers to the actual coordinates of the end effector in the cabinet coordinate system. In practice, the actuator reads the encoder values ​​from each joint, calls the forward kinematics function, and calculates the end-effector coordinates; alternatively, the end-effector coordinates of the lock-changing robotic arm can be directly read using a laser tracker.

[0071] Step 6: Compare the current position of the robotic arm with the preset electromagnetic lock installation position coordinates to obtain the position deviation. The preset electromagnetic lock installation position coordinates are the coordinates of the faulty electromagnetic lock's installation point on the cabinet. The position deviation refers to the Euclidean distance between the current position of the robotic arm and the preset electromagnetic lock installation position coordinates.

[0072] Step 7: In response to the determination that the position deviation is not within the preset threshold range, a position correction command is generated to drive the lock-changing robotic arm to perform micro-adjustments until the position deviation is within the preset threshold range. The position correction command is a control command that moves the robotic arm towards the target position by a preset step length.

[0073] Step 8: In response to the determination that the position deviation is within a preset threshold range, control the lock-changing robotic arm to perform the following steps: The first sub-step involves controlling the lock-changing robotic arm to perform the lock-pulling operation. In practice, the executing unit sends a pre-set lock-pulling command (including parameters such as speed and maximum pulling force limit) to the robotic arm controller, which then uses the grippers of the lock-changing robotic arm to hold the housing of the faulty electromagnetic lock and pull it outward along the mounting groove axis.

[0074] The second sub-step involves collecting the pulling force value via a tension sensor at the end of the lock-changing robotic arm, obtaining pulling force data, and simultaneously collecting the displacement of the electromagnetic lock relative to the mounting slot via a displacement sensor, obtaining displacement detection data. In practice, during the lock-changing process, the aforementioned execution entity can collect the pulling force value in real time via the tension sensor at the end of the lock-changing robotic arm as pulling force data. The displacement sensor synchronously collects the displacement of the electromagnetic lock relative to the mounting slot in real time as displacement detection data. The displacement sensor can be installed on the mounting slot to measure the distance (in millimeters) the electromagnetic lock moves out of the mounting slot.

[0075] The third sub-step involves generating a jamming alarm message and sending it to a preset maintenance terminal when the aforementioned pull-out force data exceeds a preset upper limit threshold and the displacement detection data indicates a displacement less than a preset movement threshold. The preset upper limit threshold for pull-out force refers to the maximum permissible pull force (e.g., 200N) set to avoid damage to the robotic arm or cabinet. The preset movement threshold refers to the minimum displacement (e.g., 1 mm) required to determine if the electromagnetic lock has started to move. If the pull force is excessively high while the displacement is almost negligible (e.g., displacement <1 mm), it indicates that the electromagnetic lock is jammed. The jamming alarm message can be text information indicating that the electromagnetic lock is jammed.

[0076] The fourth sub-step is to control the lock-changing robotic arm to continue performing the lock-pulling operation when the above-mentioned lock-pulling force data is less than or equal to the preset upper limit threshold for pull-out force or when the above-mentioned displacement detection data indicates that the displacement is greater than or equal to the preset movement threshold.

[0077] The fifth sub-step involves acquiring the real-time displacement of the electromagnetic lock relative to its mounting slot during the lock-picking operation. When the displacement reaches a preset removal displacement threshold, the lock-changing robotic arm is controlled to place the removed electromagnetic lock into a preset recycling area. The preset removal displacement threshold refers to the displacement required for the electromagnetic lock to completely detach from the mounting slot (e.g., lock body length plus 5mm). When the displacement reaches this threshold, the lock-picking is considered successful. The preset recycling area is a pre-marked container or area used to store used electromagnetic locks. In practice, the executing unit controls the robotic arm to move to the recycling area coordinates, releases the gripper (sending a "release" command), and places the faulty lock into the recycling area.

[0078] The sixth sub-step involves controlling the lock-changing robotic arm to grasp a spare electromagnetic lock from a preset area and insert it into the mounting slot. The spare electromagnetic lock refers to a functional replacement electromagnetic lock pre-stored in a designated area (e.g., a spare lock storage area). The preset area refers to the calibrated location of the spare electromagnetic lock storage area. In practice, the executing entity can control the robotic arm to move to this area, grasp the spare lock (sending a "clamp" command), then move back to the mounting position, align it with the mounting slot, and push the spare lock in with a preset force (sending an "insert" command) until an insertion signal is detected (e.g., the displacement sensor reaches the insertion depth threshold or the pressure sensor detects a sharp drop in resistance). After insertion, the robotic arm releases the gripper and returns to its initial position.

[0079] The ninth step involves sending a preset energizing command to the relay via the communication interface to activate the power supply circuit of the backup electromagnetic lock. This preset energizing command can be a pre-defined control command that closes the relay contacts.

[0080] The above-described technical solution and its related content, as an inventive point of this disclosure, solve the technical problem of "short circuits easily occurring during lock replacement, and potential damage to the robotic arm or lock body." Factors that easily lead to short circuits and potential damage to the robotic arm or lock body during lock replacement are often as follows: Due to long-term use or environmental factors, relays are prone to contact adhesion, which prevents the sent power-off command from truly cutting off the electromagnetic lock's power supply circuit, easily causing a short circuit during lock replacement. Simultaneously, during the lock-picking process, the electromagnetic lock may become stuck due to rust, foreign objects, or mechanical failure; forcibly pulling the lock could potentially damage the robotic arm or lock body. Solving these factors can reduce short circuits and damage to the robotic arm or lock body during lock replacement. To achieve this, a preset power-off command is sent to the cabinet access control device to control the relay to disconnect the power supply circuit of the faulty electromagnetic lock. Furthermore, a current sensor collects the current in the electromagnetic lock's power supply circuit to obtain the current value after power failure. Thus, it is possible to detect in real time whether the power supply circuit is truly de-energized and obtain the current value after power failure. Next, in response to the determination that the current value after the power outage is not zero, a pulse oscillation command of a preset number of times is sent to the relay to drive the relay contacts to perform an oscillation separation operation. This utilizes the rapidly switching pulse current to generate electromagnetic impact force, forcibly shaking apart stuck contacts, solving the problem of contact sticking caused by relay aging or environmental factors, and preventing short circuits caused by pulling the lock while it is powered on. Afterwards, the current in the power supply circuit after the oscillation separation operation is collected by a current sensor to obtain the current value after oscillation. Thus, the current value of the power supply circuit after the pulse oscillation operation, i.e., the current value after oscillation, can be obtained. Next, in response to the determination that the current value after oscillation is zero, the end coordinates of the lock-changing robotic arm are collected by a position sensor to obtain the current position of the robotic arm. This allows the current position of the robotic arm to be collected after a complete power outage. Then, the current position of the robotic arm is compared with the preset electromagnetic lock installation position coordinates to obtain the position deviation. In response to the determination that the position deviation is not within a preset threshold range, a position correction command is generated to drive the lock-changing robotic arm to perform micro-adjustments until the position deviation is within the preset threshold range. This allows for the quantification of positioning errors. When the position deviation is outside the preset threshold range, a position correction command is generated to drive the lock-changing robotic arm to perform micro-adjustments until the position deviation is within the preset threshold range. Closed-loop control eliminates positioning deviations caused by motion accuracy, wear, or environmental vibrations, ensuring that subsequent lock-picking actions are aligned with the electromagnetic lock's installation position and preventing damage due to misalignment. Then, in response to determining that the position deviation is within the preset threshold range, the lock-changing robotic arm is controlled to perform the following steps: First, the lock-changing robotic arm is controlled to perform a lock-picking operation. Thus, the lock-changing robotic arm can be controlled to perform a lock-picking operation only after the position deviation meets the requirements.The second step involves collecting the pulling force value via a force sensor at the end of the lock-changing robotic arm, obtaining pulling force data, and collecting the displacement of the electromagnetic lock relative to the mounting slot via a displacement sensor, obtaining displacement detection data. This allows for real-time monitoring of the two key physical quantities during lock removal: force and displacement. The third step involves generating a jamming alarm when the pulling force exceeds a preset upper limit threshold and the displacement detection data indicates a displacement less than a preset movement threshold, and sending the alarm to a preset maintenance terminal. This allows for timely identification of the typical jamming characteristic of "excessive pulling force but almost no lock movement," preventing damage to the robotic arm or lock body from forced lock removal, and simultaneously notifying maintenance personnel. The fourth step involves controlling the lock-changing robotic arm to continue the lock removal operation when the pulling force is less than or equal to the preset upper limit threshold or the displacement detection data indicates a displacement greater than or equal to the preset movement threshold. This allows for lock removal operations to be performed even when no lock jamming is detected, reducing damage to the robotic arm or lock body caused by forced lock removal. Fifth, during the lock-picking operation, the displacement of the electromagnetic lock relative to the mounting slot is acquired in real time. When the displacement reaches the preset pull-out displacement threshold, the lock-changing robotic arm is controlled to place the pulled-out electromagnetic lock into the preset recycling area. This automatically completes the removal and recycling of faulty locks, freeing up space for installing a spare lock. Sixth, the lock-changing robotic arm is controlled to grasp the spare electromagnetic lock from the preset area and insert it into the mounting slot. Finally, a preset power-on command is sent to the relay via the communication interface to connect the power supply circuit of the spare electromagnetic lock. Because pulse oscillation commands are used to solve relay contact sticking, position closed-loop correction eliminates robotic arm deviation, and joint monitoring of tension and displacement identifies jamming faults, the risk of short circuits caused by the inability to disconnect power is avoided, preventing equipment damage caused by forcibly pulling out a jammed lock. This reduces short circuits during lock-changing and minimizes damage to the robotic arm or lock body.

[0081] The above-described embodiments of this disclosure have the following beneficial effects: The interface testing and electromagnetic lock replacement methods of some embodiments of this disclosure reduce the number of times the cabinet door cannot be opened or closed normally or the electromagnetic lock is incorrectly triggered for replacement. Specifically, the reason for the increased number of times the cabinet door cannot be opened or closed normally or the electromagnetic lock is incorrectly triggered for replacement is that: because all interface requests and test scripts are mixed in the same large file, Git version control conflicts occur frequently, and the test scripts cannot be maintained independently. Storing all interface requests and scripts in a single large file makes the file extremely large and complex as testing requirements change and increase. When modifying, updating, or adding new test scripts to the file content, operational errors are easily made, leading to file corruption or test logic errors. This results in missed or false alarms for actual electromagnetic lock faults (such as coil burnout, contact adhesion, mechanical jamming), thus increasing the number of times the cabinet door cannot be opened or closed normally or the electromagnetic lock is incorrectly triggered for replacement. Based on this, the interface testing and electromagnetic lock replacement method of some embodiments of this disclosure firstly, in response to receiving a test request information for the electromagnetic lock in the cabinet access control device input by a user, scans a pre-created set of atomic interface configuration files corresponding to the test request information in a preset memory to generate a sequence of atomic interface configuration files corresponding to the test request information. Each atomic interface configuration file stores operation configuration parameter information and reference path information pointing to an external test script file. Thus, a scan can be performed on the set containing various independent atomic configuration files to find the sequence of atomic interface configuration files corresponding to the test request information. The separate storage of atomic configuration files allows for automatic merging when multiple users modify different interfaces, eliminating version control conflicts. Next, an environment variable pool is loaded from the preset memory. Then, the following test steps are performed sequentially on each atomic interface configuration file in the sequence: First, the external test script file pointed to by the reference path information in the atomic interface configuration file is loaded, and the environment variable pool and the operation configuration parameter information in the atomic interface configuration file are injected into the execution context of the external test script file to execute the test task in a pre-created sandbox environment and obtain execution result data. Therefore, each test script executes in an independent sandbox environment, without interfering with each other, and can accurately obtain the required environment variables and operation configuration parameters, ensuring the accuracy and stability of the test and reducing test logic errors caused by incorrect environment variables or configuration parameters. The second step involves updating the current environment variable pool based on the execution result data, and using the updated environment variable pool as the environment variable pool for subsequent execution of the above test steps using atomic interface configuration files.This enables dynamic environment variable propagation, ensuring that subsequent tests dependent on preceding interfaces (such as token acquisition) can be executed accurately. Environment variables are dynamically updated based on test results, ensuring subsequent tests are based on the latest environmental state, further improving test accuracy and aiding in accurately determining whether the electromagnetic lock is faulty. The third step involves initiating an operation request to the electromagnetic lock of the cabinet access control device based on the aforementioned operation configuration parameters, obtaining actual response data to generate interface test data. This provides actual response data that accurately reflects the working state of the electromagnetic lock, completing the testing of the electromagnetic lock interface. Finally, in response to the generated interface test data indicating a lock control operation test failure, the relays and lock-changing robotic arm on the cabinet access control device are controlled to replace the electromagnetic lock with a backup electromagnetic lock. This allows for driving the replacement action based on test results to replace the damaged electromagnetic lock. Because of the use of atomic configuration file separation storage, version control conflicts are eliminated, and problems such as inaccurate testing, file corruption, or test logic errors caused by a single large file are solved. The use of external script independent storage and dynamic updates of environment variables improves the maintainability of test scripts and the accuracy of test context, thereby avoiding the occurrence of missed or false alarms. It ensures that the electromagnetic lock is only replaced when it is actually malfunctioning, ensuring that the cabinet door can be opened and closed normally and reducing the number of times the cabinet door cannot be opened and closed normally or the electromagnetic lock is replaced due to incorrect triggering.

[0082] Further reference Figure 2 As an implementation of the methods shown in the figures, this disclosure provides some embodiments of an interface testing and electromagnetic lock replacement device, which are similar to... Figure 1 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices.

[0083] like Figure 2As shown, the interface testing and electromagnetic lock replacement device 200 of some embodiments includes: a scanning unit 201, a loading unit 202, a testing unit 203, and a replacement unit 204. The scanning unit 201 is configured to, in response to receiving a test request information for an electromagnetic lock in a cabinet access control device input by a user, scan a pre-created set of atomic interface configuration files corresponding to the test request information in a preset memory to generate a sequence of atomic interface configuration files corresponding to the test request information. Each atomic interface configuration file stores operation configuration parameter information and reference path information pointing to an external test script file. The loading unit 202 is configured to load an environment variable pool from the preset memory. The testing unit 203 is configured to sequentially perform the following test steps on each atomic interface configuration file in the sequence: loading the external test script file pointed to by the reference path information in the atomic interface configuration file, and... The environment variable pool and the operation configuration parameter information in the atomic interface configuration file are injected into the execution context of the external test script file to execute the test task in the pre-created sandbox environment and obtain the execution result data. Based on the execution result data, the current environment variable pool is updated and the updated environment variable pool is used as the environment variable pool when the above test steps are executed in subsequent atomic interface configuration files. Based on the above operation configuration parameter information, an operation request is initiated to the electromagnetic lock of the cabinet access control device to obtain the actual response data and generate interface test data. The replacement unit 204 is configured to control the relay and lock-changing robotic arm on the cabinet access control device to replace the electromagnetic lock with a backup electromagnetic lock in response to the determination that the generated interface test data indicates that the lock control operation test has failed.

[0084] It is understandable that the units described in the device 200 are related to the reference. Figure 1 The steps in the method described above correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the device 200 and the units contained therein, and will not be repeated here.

[0085] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0086] like Figure 3As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, the ROM 302, and the RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0087] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0088] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0089] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0090] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0091] The computer-readable medium may be contained within an electronic device or may exist independently, not assembled into the electronic device. The computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: respond to receiving a test request from a user for an electromagnetic lock in a cabinet access control device; scan a pre-created set of atomic interface configuration files corresponding to the test request in a preset memory to generate a sequence of atomic interface configuration files corresponding to the test request, wherein each atomic interface configuration file stores operation configuration parameters and a reference path to an external test script file; load an environment variable pool from the preset memory; and sequentially perform the following test steps for each atomic interface configuration file in the sequence of atomic interface configuration files: load the external test script file pointed to by the reference path information in the atomic interface configuration file... The test script file, along with the operation configuration parameters from the environment variable pool and atomic interface configuration file, is injected into the execution context of the external test script file to execute test tasks in a pre-created sandbox environment and obtain execution result data. Based on the execution result data, the current environment variable pool is updated and used as the environment variable pool for subsequent execution of the above test steps using the atomic interface configuration file. Based on the above operation configuration parameters, an operation request is initiated to the electromagnetic lock of the cabinet access control device to obtain actual response data and generate interface test data. In response to the determination that the generated interface test data indicates that the lock control operation test has failed, the relays and lock-changing robotic arms on the cabinet access control device are controlled to replace the electromagnetic lock with a backup electromagnetic lock.

[0092] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0093] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0094] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be located in a processor; for example, a processor may be described as including a scanning unit, a loading unit, a testing unit, and a replacement unit. The names of these units do not necessarily limit the unit itself; for example, a loading unit may also be described as "a unit that loads an environment variable pool from the aforementioned preset memory."

[0095] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0096] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of technical features, but should also cover other technical solutions formed by arbitrary combinations of technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for interface testing and electromagnetic lock replacement, comprising: In response to receiving a test request information for the electromagnetic lock in the cabinet access control device input by the user, the system scans the set of pre-created atomic interface configuration files corresponding to the test request information in the preset memory to generate a sequence of atomic interface configuration files corresponding to the test request information. Each atomic interface configuration file stores operation configuration parameter information and reference path information pointing to an external test script file. Load the environment variable pool from the preset memory; For each atomic interface configuration file in the atomic interface configuration file sequence, perform the following test steps in sequence: Load the external test script file pointed to by the reference path information in the atomic interface configuration file, and inject the environment variable pool and operation configuration parameter information in the atomic interface configuration file into the execution context of the external test script file to execute the test task in the pre-created sandbox environment and obtain the execution result data; Based on the execution result data, the current environment variable pool is updated, and the updated environment variable pool is used as the environment variable pool when the test steps are executed in subsequent atomic interface configuration files. Based on the operation configuration parameter information, an operation request is initiated to the electromagnetic lock of the cabinet access control device to obtain actual response data and generate interface test data; In response to the determination that the generated interface test data indicates that the lock control operation test has failed, the relays and lock-changing robotic arm on the cabinet access control device are controlled to replace the electromagnetic lock with a backup electromagnetic lock.

2. The method according to claim 1, wherein, The method further includes: The test data for each interface is displayed on the preset cabinet access control device test page.

3. The method according to claim 1, wherein, The method further includes: Create a root directory folder in the preset storage; Create subfolders named after the identifiers of each functional module under the root directory folder; For each functional module subfolder, perform the following steps: Create a set of atomic interface configuration files corresponding to the functional module subfolder, and store the set of atomic interface configuration files in the functional module subfolder; Create a script subfolder under the functional module subfolder, where each atomic interface configuration file stores operation configuration parameter information and reference path information pointing to external test script files; The pre-written set of external test script files is stored in the script subfolder to obtain the external test script file set, wherein each atomic interface configuration file in the atomic interface configuration file set corresponds to one external test script file in the external test script file set.

4. The method according to claim 3, wherein, The test request information includes a test function module identifier and a pre-created set of atomic interface configuration files corresponding to the test request information, scanned in a preset memory, to generate a sequence of atomic interface configuration files corresponding to the test request information, including: The subfolder of the function module in the preset memory that is named after the test function module identifier is identified as the target function module subfolder; The set of atomic interface configuration files stored in the target functional module subfolder is determined as the set of atomic interface configuration files corresponding to the test request information, wherein the file name of each atomic interface configuration file in the set of atomic interface configuration files is prefixed with a number. Read the prefix of the atomic interface configuration file in the atomic interface configuration file set to obtain the set of numerical numbers; Based on the set of numerical IDs, the atomic interface configuration files in the set of atomic interface configuration files corresponding to the test request information are sorted to obtain the atomic interface configuration file sequence.

5. The method according to claim 1, wherein, The process of injecting the operation configuration parameter information from the environment variable pool and the atomic interface configuration file into the execution context of the external test script file to execute the test task in a pre-created sandbox environment and obtain execution result data includes: Obtain the source code content of the external test script file to get the script source code string; In the pre-created sandbox environment, the virtual machine module is invoked to create a secure sandbox instance and obtain the sandbox environment object; The environment variable pool is attached as the environment attribute of the sandbox environment object; The operation configuration parameter information is mounted as the operation parameter attribute of the sandbox environment object; Inject a preset global environment variable setting function into the sandbox environment object; The script source code string is compiled into an executable function to obtain a script function object; Within the scope of the sandbox environment object, the script function object is called to execute the script represented by the external test script file and obtain the original execution return value. During the execution of the script represented by the external test script file, when the script calls the preset global environment variable setting function, at least one key-value pair passed when the global environment variable setting function is called is extracted as environment update instruction information. The original execution return value and the environment update instruction information are determined as the execution result data.

6. The method according to claim 5, wherein, Each key-value pair in the at least one key-value pair includes a key name and a key value, and the process of updating the current environment variable pool based on the execution result data includes: For each key-value pair in at least one key-value pair included in the execution result data, the following steps are performed sequentially: Search the current environment variable pool for an entry corresponding to the key name included in the key-value pair; The environment variable pool is updated by replacing the key values ​​in the entries with the key values ​​included in the key-value pairs.

7. An interface testing and electromagnetic lock replacement device, comprising: The scanning unit is configured to, in response to receiving a test request information for the electromagnetic lock in the cabinet access control device input by a user, scan a set of pre-created atomic interface configuration files in a preset memory corresponding to the test request information, so as to generate a sequence of atomic interface configuration files corresponding to the test request information, wherein each atomic interface configuration file stores operation configuration parameter information and reference path information pointing to an external test script file; The loading unit is configured to load the environment variable pool from the preset memory; The test unit is configured to sequentially execute the following test steps for each atomic interface configuration file in the atomic interface configuration file sequence: load the external test script file pointed to by the reference path information in the atomic interface configuration file, and inject the environment variable pool and the operation configuration parameter information in the atomic interface configuration file into the execution context of the external test script file to execute the test task in a pre-created sandbox environment and obtain execution result data; update the current environment variable pool according to the execution result data, and use the updated environment variable pool as the environment variable pool when the test steps are executed in subsequent atomic interface configuration files; and initiate an operation request to the electromagnetic lock of the cabinet access control device according to the operation configuration parameter information to obtain actual response data and generate interface test data. The replacement unit is configured to control the relays and lock-changing robotic arm on the cabinet access control device in response to the determination that the generated interface test data indicates that the lock control operation test has failed, so as to replace the electromagnetic lock with a backup electromagnetic lock.

8. An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 6.

9. A computer-readable medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 6.

Images