Sand box testing methods, apparatuses, devices, media, and program products

Abstract

The application provides a sandbox testing method, device, equipment, medium and program product, which can be applied to the field of financial technology or other fields. The method comprises the following steps: in response to receiving a test request, initializing a sandbox environment based on the test request, the test request at least comprising to-be-verified code, the sandbox environment being a logically isolated area deployed in a target running environment, and the sandbox environment comprising mirror database objects corresponding to each database object in the target running environment; analyzing the to-be-verified code to obtain an operation instruction type and a target database object corresponding to the operation instruction type; in response to the target database object belonging to the target running environment and the operation instruction type being a data definition language instruction or a non-query type data manipulation language instruction, redirecting the operation of the target database object in the to-be-verified code to the corresponding mirror database object in the sandbox environment; and executing the redirected to-be-verified code in the sandbox environment to return a test result.

Description

Technical Field

[0001] This application relates to the field of fintech or other fields, specifically to a sandbox testing method, apparatus, equipment, medium, and program product. Background Technology

[0002] As software systems become increasingly large-scale and complex, software testing has become crucial for ensuring delivery quality.

[0003] In mainstream software testing engineering practices, three common solutions are used: independent testing environments, direct verification in production environments, and data virtualization technology. Independent testing environments sample or anonymize some production data, but due to insufficient data integrity, synchronization delays, and differences in hardware and software configurations, they struggle to accurately reproduce real-world business scenarios, resulting in low reliability of test results. Furthermore, their environment construction and maintenance costs are high. Direct verification in production environments, while ensuring data integrity and authenticity, carries the risk of data contamination; accidental modifications or deletions of production data by test code can disrupt business continuity. Data virtualization technology uses data virtualization tools to provide read-only access to production data without moving the data itself, but its support for write operations is limited, failing to cover the entire testing process.

[0004] Therefore, there is an urgent need to provide a testing method to overcome the defects and shortcomings of the above-mentioned testing methods. Summary of the Invention

[0005] In view of the above problems, embodiments of this application provide a sandbox testing method, apparatus, device, medium, and program product.

[0006] According to a first aspect of this application, a sandbox testing method is provided, comprising: in response to receiving a test request, initializing a sandbox environment based on the test request, wherein the test request includes at least code to be verified, the sandbox environment is a logically isolated area deployed within a target runtime environment, and the sandbox environment includes mirror database objects corresponding to each database object in the target runtime environment; parsing the code to be verified to obtain operation instruction types and target database objects corresponding to the operation instruction types; in response to the target database object belonging to the target runtime environment and the operation instruction type being a data definition language instruction or a non-query data manipulation language instruction, redirecting the operation on the target database object in the code to be verified to the corresponding mirror database object in the sandbox environment; and executing the redirected code to be verified in the sandbox environment to return test results.

[0007] According to an embodiment of this application, parsing the code to be verified in the test request to obtain the operation instruction type and the target database object corresponding to the operation instruction type includes: performing lexical analysis and syntactic analysis on the code to be verified to obtain an abstract syntax tree; traversing each node in the abstract syntax tree and determining the operation instruction type corresponding to the node based on the node type; and locating the target database object corresponding to the operation instruction type from the abstract syntax tree based on the syntax rules corresponding to the operation instruction type.

[0008] According to an embodiment of this application, initializing a sandbox environment based on a test request includes: in response to a reference to an unpublished database object contained in the code to be verified, creating a corresponding database structure within the sandbox environment based on the structure definition information of the unpublished database object; generating a virtual view of the unpublished database object based on the database structure; and redirecting the reference identifier to the unpublished database object in the code to be verified to the identifier of the virtual view.

[0009] According to an embodiment of this application, the method further includes: generating a temporary role corresponding to the current test session based on the test request, wherein the temporary role has read-only permissions for database objects in the target runtime environment and read / write permissions for mirrored database objects in the sandbox environment; obtaining session features of the test request, inputting the session features into a pre-trained time series prediction model to obtain the predicted runtime, wherein the session features include at least request type features and complexity features of the code to be verified, and the time series prediction model is constructed based on a long short-term memory network; setting the predicted runtime as the lifetime of the temporary role; and revoking the permissions of the temporary role in response to the expiration of the lifetime.

[0010] According to an embodiment of this application, initializing a sandbox environment based on a test request includes: in response to the end of the current test session, generating a changeset snapshot corresponding to the current test session and storing it in a snapshot repository, wherein the changeset snapshot includes at least temporary data records redirected to the sandbox environment and the database structure of unpublished database objects created within the sandbox environment; in response to receiving a new test request, calculating the similarity between the new test request and each changeset snapshot in the snapshot repository; based on the similarity, selecting multiple changeset snapshots whose similarity meets a preset threshold from the snapshot repository; merging the multiple changeset snapshots in chronological order to generate a composite snapshot; and initializing the sandbox environment corresponding to the new test request based on the composite snapshot.

[0011] According to an embodiment of this application, the method further includes: in response to the end of the current test session, collecting operation logs triggered by the code to be verified within the sandbox environment; performing lexical and syntactic analysis on the operation logs to obtain database object access sequences; constructing a data lineage graph based on the database object access sequences, wherein the data lineage graph is a directed graph structure, nodes are used to represent database objects, edges are used to represent data flow relationships between database objects, and edge weights are used to represent data flow frequency; and generating a structured audit report based on the data lineage graph and a preset audit template.

[0012] According to an embodiment of this application, a data lineage graph is obtained by: extracting data access records from operation logs, wherein the data access records at least include a source database object, a target database object, and operation conversion rules, wherein the operation conversion rules are the types of data operations performed by the code to be verified on the source database object; constructing directed edges with the source database object as the starting node and the target database object as the ending node, wherein the edge attributes of the directed edges include the operation conversion rules; and combining multiple directed edges and corresponding nodes to form a data lineage graph.

[0013] According to a second aspect of this application, a sandbox testing apparatus is provided, comprising: a sandbox environment initialization module, configured to initialize a sandbox environment based on a received test request, wherein the test request includes at least code to be verified, the sandbox environment is a logically isolated area deployed within a target runtime environment, and the sandbox environment includes mirror database objects corresponding to each database object in the target runtime environment; a code parsing module, configured to parse the code to be verified to obtain operation instruction types and target database objects corresponding to the operation instruction types; a redirection module, configured to redirect operations on the target database object in the code to be verified to the corresponding mirror database object in the sandbox environment in response to the target database object belonging to the target runtime environment and the operation instruction type being a data definition language instruction or a non-query data manipulation language instruction; and a test execution module, configured to execute the redirected code to be verified within the sandbox environment to return test results.

[0014] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0016] According to a fifth aspect of this application, a computer program product is also provided, comprising a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0017] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 The illustrations depict application scenarios of sandbox testing methods, apparatus, devices, media, and program products according to embodiments of this application.

[0019] Figure 2 A flowchart illustrating a sandbox testing method according to an embodiment of this application is shown schematically.

[0020] Figure 3 This illustration schematically shows a flowchart of the processing of an unpublished database object according to an embodiment of this application;

[0021] Figure 4 A flowchart illustrating the initialization of a sandbox environment according to an embodiment of this application is shown schematically;

[0022] Figure 5 This schematically illustrates the overall flowchart of a sandbox testing method according to an embodiment of the present application;

[0023] Figure 6 A timing diagram of a sandbox testing method according to an embodiment of this application is illustrated schematically;

[0024] Figure 7 A schematic diagram illustrating the structure of a sandbox testing apparatus according to an embodiment of this application is shown.

[0025] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a sandbox testing method according to an embodiment of this application. Detailed Implementation

[0026] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0027] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0028] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0029] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0030] It should be noted that the sandbox testing methods, apparatus, equipment, media, and program products defined in this application can be used for business system testing in the fintech field, as well as in any field other than fintech. The application fields of the sandbox testing methods, apparatus, equipment, media, and program products defined in this application are not limited.

[0031] Figure 1 The illustration schematically depicts application scenarios of sandbox testing methods, apparatus, devices, media, and program products according to embodiments of this application. For example... Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send information, etc.

[0032] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. A client application for the target application can be installed and run on the terminal devices. This target application can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (these are just examples). Furthermore, this application embodiment does not limit the form of the target application, and it can include, but is not limited to, applications, mini-programs, etc., installed on the terminal devices, and can also be in the form of web pages.

[0033] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and basic cloud computing services such as big data. The server can be the backend server of the aforementioned target application, used to provide backend services to the clients of the target application.

[0034] It should be noted that the sandbox testing method provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-103. Accordingly, the sandbox testing device provided in this application embodiment can generally be set in server 105 and / or terminal devices 101-103.

[0035] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0036] Figure 2 A flowchart illustrating a sandbox testing method according to an embodiment of this application is shown schematically. Figure 2 As shown, the sandbox testing method 200 according to the embodiments of this application may include steps S210 to S240.

[0037] In step S210, in response to receiving a test request, the sandbox environment is initialized based on the test request.

[0038] In the embodiments of this application, a test request may refer to a sandbox test request initiated by a target user (such as a tester or developer), and the test request includes at least the code to be verified. The code to be verified may refer to various types of executable code that are to be tested and verified for logical correctness and runtime performance, including but not limited to application software source code, data processing scripts, configuration code, etc. Furthermore, the test request may also include information such as a list of database objects required for this test task, sandbox environment usage time, resource quotas, and business scenarios.

[0039] The target runtime environment can refer to the actual production environment of the running business system, including real production data, database objects, and running business services. It should be noted that the target runtime environment described in this application is not limited to a production environment; it can also include quasi-production environments (such as simulation environments, gray-scale environments), and other environments, suitable for various sensitive scenarios requiring testing and verification while mitigating the risk of data contamination. The sandbox environment is a logically isolated area deployed within the target runtime environment. The sandbox environment contains mirrored database objects corresponding to each database object in the target runtime environment. A mirrored database object can refer to a copy of the database object structure corresponding to the target runtime environment, created within the sandbox environment, which includes table structures and related objects.

[0040] Data R&D and operation integration can refer to a collaborative management approach that covers the entire data lifecycle. It forms an end-to-end data verification closed loop by integrating automated approval, permission orchestration, and continuous monitoring. By adopting this approach, the coordination costs between data R&D and operation and maintenance in terms of environment configuration and management can be reduced, and on-demand and flexible supply of testing resources can be achieved.

[0041] For example, after the simulation portal of the integrated data R&D and operation model receives a test request submitted by a user, containerization technology can be used to initialize the isolated execution environment required for the sandbox, ensuring that sandbox tasks and production business tasks do not interfere with each other. Specifically, the container orchestration interface can be called first to create a new container instance as the sandbox environment carrier within the same physical node or cluster of the target runtime environment. Based on the resource quota in the test request (e.g., a processor quota of 0.5 cores and a memory limit of 1GB), the container instance can be configured with resource limits through an independent control group to achieve logical isolation of computing resources. Subsequently, a read-only connection pool for the data source of the target runtime environment can be configured for the container instance through the database proxy component, and a temporary database instance can be generated as the sandbox storage area. Then, the database metadata dictionary of the target runtime environment is traversed to obtain each object in the list of database objects involved in the test request. For each object in the list of database objects, an object with the same name as that object is created in the sandbox storage area as a mirror database object. These mirror database objects only retain the structural definition and do not contain production data. Finally, the container instance is bound to the sandbox storage area to form a complete sandbox environment.

[0042] Optionally, when the test request does not contain a list of database objects, static analysis (such as abstract syntax tree, regular expression matching, or semantic parsing) can be performed on the code to be verified to automatically extract the database objects (such as tables, views, stored procedures, etc.) referenced therein.

[0043] Optionally, a permission approval process can be included before the sandbox environment is initialized. Specifically, after the target user submits a test request, the application is routed to the relevant responsible person (such as the data owner or security administrator) for approval according to preset rules (such as approval level). If the approval fails, the process terminates.

[0044] By building a logically isolated sandbox environment within the target runtime environment, the cost and latency issues of traditional testing solutions, which require building independent physical clusters or copying large amounts of test data, are avoided. Using containerization, virtualization proxies, or session-level isolation technologies, the sandbox environment can be initialized in seconds or milliseconds, while sharing underlying resources with production operations without interfering with each other.

[0045] In step S220, the code to be verified is parsed to obtain the operation instruction type and the target database object corresponding to the operation instruction type.

[0046] In the embodiments of this application, the operation instruction type can refer to the database statement type in the code to be verified, which typically includes two main categories of instruction sets: Data Definition Language (DDL) instruction sets, such as creating and deleting database tables; and Data Manipulation Language (DML) instruction sets, such as inserting and querying data. The target database object can refer to database entities such as tables, views, and fields in the code to be verified that are read, modified, or have their structure changed.

[0047] For example, the code to be verified can be intercepted through an interception mechanism (such as a database driver proxy or bytecode enhancement), the database statements generated by it can be captured, each database statement can be parsed (such as regular expressions), the operation instruction type can be identified (such as query, insert, update, delete, etc.), and the target database object (such as table name, view name, index name, etc.) pointed to by the operation instruction can be further parsed to generate an association list of "operation instruction type - target database object".

[0048] In step S230, in response to the target database object belonging to the target runtime environment and the operation instruction type being a data definition language instruction or a non-query data manipulation language instruction, the operation on the target database object in the code to be verified is redirected to the corresponding mirror database object in the sandbox environment.

[0049] In the embodiments of this application, redirection can refer to transferring operations on the target runtime environment database object in the original code to be verified to the corresponding mirror database object in the sandbox environment for execution by rewriting. Non-query data manipulation language instructions refer to instructions used for adding, modifying, and deleting data, and do not include data query operations.

[0050] For example, for each target database object involved in the code to be verified, the runtime environment to which the target database object belongs is determined based on the metadata registration information. If the target database object is marked as a target runtime environment (such as a production environment), and the operation instructions for the target database object are classified as DDL instructions or non-query DML instructions, then the execution path hijacking logic is triggered. That is, the physical identifier in the original database statement pointing to the target runtime environment is transparently replaced with the physical identifier of the mirror database object corresponding to the target database object in the sandbox storage area, thereby isolating the data pollution risk caused by the code to be verified directly operating the target runtime environment. Query DML instructions are directly allowed to access the database objects of the target runtime environment.

[0051] In step S240, the redirected code to be verified is executed within the sandbox environment to return the test results.

[0052] Specifically, the redirected code to be verified is submitted to the database execution engine in the sandbox environment for execution verification. The generated test results are sent back to the target user who initiated the test request through the simulation portal. The target user compares the test results with the old process results to verify the consistency of the logic. After confirming that the performance meets the standards, the code is released to the target runtime environment.

[0053] Optionally, when running test tasks within a container or computing unit in a sandbox environment, circuit breaker protection can be implemented through the following mechanism: First, set abnormal behavior rules and circuit breaker thresholds for resource usage metrics. Then, continuously perform semantic analysis on executed database statements to identify various operational behaviors (such as batch deletion and full table queries); simultaneously, continuously collect multi-dimensional resource usage metrics, such as processor utilization, memory usage, disk read / write speed, scanned data volume, and number of returned records. Then, match the identified operational behaviors with the abnormal behavior rules and compare the resource metrics with the circuit breaker thresholds. Once a match is found or the thresholds are exceeded, circuit breaker protection is triggered to protect the target runtime environment.

[0054] According to the embodiments of this application, by isolating and deploying the sandbox environment within the target runtime environment in a containerized manner, on the one hand, there is no need to build a separate independent test environment; the test environment directly reuses the target runtime environment, significantly reducing deployment and maintenance costs. On the other hand, the testing process can directly use the full, real-time data in the target runtime environment, ensuring the authenticity and timeliness of the test data, thereby improving the reliability of the test results. At the same time, by effectively isolating test tasks from production business, the contamination of production data by test operations is avoided, ensuring the data security and business continuity of the target runtime environment.

[0055] In the embodiments of this application, parsing the code to be verified in the test request to obtain the operation instruction type and the target database object corresponding to the operation instruction type may include: performing lexical analysis and syntactic analysis on the code to be verified to obtain an abstract syntax tree; traversing each node in the abstract syntax tree and determining the operation instruction type corresponding to the node based on the node type; and locating the target database object corresponding to the operation instruction type from the abstract syntax tree based on the syntax rules corresponding to the operation instruction type.

[0056] Lexical analysis refers to the process of segmenting an input code string into individual tokens according to lexical rules. Syntax analysis refers to further analyzing the syntactic relationships between different tokens based on the sequence of tokens obtained from lexical analysis, in order to identify the code structure. An Abstract Syntax Tree (AST) is a tree-like data structure that represents the syntactic structure of code in the form of tree nodes, with each node corresponding to a syntactic unit. The node type refers to the category of syntactic structure represented by each node in the AST.

[0057] Specifically, the process begins by obtaining the database statements from the code to be verified. Then, a lexical analysis tool is used to perform lexical analysis on these statements, breaking them down into a series of lexical units. For example, for the database statement "SELECT name FROM users WHERE age > 18", lexical analysis yields the units [SELECT, name, FROM, users, WHERE, age, >, 18]. Next, these units are subjected to syntactic analysis, verifying the logical combination of units according to standard database syntax rules to identify the statement's syntactic structure, operation instruction types, and syntactic components, while recursively constructing an Abstract Syntax Tree (AST). Subsequently, the node types in the AST are used to determine if the current operation is an instruction type, and the corresponding operation instruction (such as query, insert, update, delete, etc.) is obtained. Finally, based on the syntax rules corresponding to the operation instruction type, the syntax tree is traversed hierarchically to precisely locate the source table, target table, fields, and other database objects involved in the statement.

[0058] According to embodiments of this application, by parsing the code to be verified through an abstract syntax tree, the complete syntax structure of the code can be obtained, thereby identifying the operation type of each instruction and locating its target database object, thus providing data support for operation reclassification.

[0059] Figure 3 A flowchart illustrating the processing of an unpublished database object according to an embodiment of this application is shown. Figure 3 As shown, the method 300 of this embodiment may include steps S310 to S330.

[0060] In step S310, in response to the code to be verified containing a reference to an unpublished database object, a corresponding database structure is created within the sandbox environment based on the structure definition information of the unpublished database object.

[0061] In the embodiments of this application, an unpublished database object may refer to a database entity that has completed its structural design but has not yet been formally created or deployed to the target operating environment (such as a production environment), such as a new table, new view, new stored procedure in the development stage, or an intermediate table structure temporarily used for testing.

[0062] For example, firstly, the database objects involved in the code to be verified are obtained, such as by obtaining a list of database objects in the test request or by parsing the code to be verified. Then, these objects are compared item by item with the database metadata dictionary of the target runtime environment. Objects that already exist in the metadata dictionary are marked as published database objects; objects that do not exist in the metadata dictionary but are referenced in the code to be verified are identified as unpublished database objects. For the identified unpublished database objects, their structure definition information, including column names, data types, constraints, and partition keys, is obtained from the code to be verified. Subsequently, in the sandbox storage area of ​​the sandbox environment, a table creation operation is performed based on the structure definition information to create the corresponding database structure.

[0063] In step S320, a virtual view of the unpublished database object is generated based on the database structure.

[0064] In the embodiments of this application, after the database structure is created, a virtual view with the same name is generated based on the created database structure. This view points to the actual physical table in the sandbox environment.

[0065] In step S330, the reference identifier to the unpublished database object in the code to be verified is redirected to the identifier of the virtual view.

[0066] In the embodiments of this application, after intercepting the code to be verified through an interception mechanism (such as database driver proxy, bytecode enhancement), if the target database object involved in the code to be verified is an unpublished database object, the reference identifier to the unpublished database object in the code to be verified is redirected to the identifier of the virtual view, and the rewritten code is submitted to the sandbox environment for execution. This process is completely transparent to the target user, and automatic redirection and isolation verification of unpublished database objects can be achieved without modifying the original test code.

[0067] According to the embodiments of this application, by creating unreleased tables in a sandbox environment, testing of database objects that have not yet been officially released is achieved without intruding on the target runtime environment. This effectively eliminates test blocking caused by dependence on unreleased objects and ensures the continuity of the testing process.

[0068] In embodiments of this application, the method may further include: generating a temporary role corresponding to the current test session based on the test request, wherein the temporary role has read-only permissions for database objects in the target runtime environment and read / write permissions for mirrored database objects in the sandbox environment; obtaining session features of the test request, inputting the session features into a pre-trained time series prediction model to obtain the predicted runtime, wherein the session features include at least request type features and complexity features of the code to be verified, and the time series prediction model is constructed based on a long short-term memory network; setting the predicted runtime as the lifetime of the temporary role; and revoking the permissions of the temporary role in response to the expiration of the lifetime.

[0069] A test session can refer to a complete verification process from receiving a test request to the completion of all sandbox resource cleanup. A temporary role can refer to a database permission entity dynamically created for a single test session, with a preset validity period that automatically expires or is reclaimed upon expiration. Read-only permissions can refer to access permissions that only allow querying and reading database object data, prohibiting modification, deletion, or structural changes. Read-write permissions can refer to full operation permissions that allow querying, adding, modifying, and deleting object data and structures within the sandbox.

[0070] Specifically, upon receiving a test request, a temporary role uniquely bound to the current test session can be created based on the principle of least privilege. This temporary role is granted read-only permissions to the target runtime environment and read / write permissions to the sandbox database within a limited scope. The limited scope can be determined based on the range of database objects involved in the code to be verified, which in turn can be determined based on the list of database objects in the test request or the parsing results of the code to be verified. Based on the role-based access control mechanism, the temporary role is granted to the target user after its creation.

[0071] Temporary roles have a session-level lifecycle, with their effective time window synchronized with the duration of the test session. The lifespan of a temporary role can be obtained using a pre-trained time-series prediction model. Specifically, the request type characteristics and the complexity characteristics of the code to be verified are first obtained. The request type characteristics can refer to the classification of the business scenario of the test request, such as transaction scenarios, risk control scenarios, and report statistics scenarios. The code complexity characteristics can refer to indicators that quantify the difficulty of running the code to be verified and its resource consumption, such as the number of related tables and the number of lines of code. Finally, the above characteristics are input into the pre-trained time-series prediction model to obtain the predicted runtime as the lifespan of the temporary role. When the lifespan expires, permissions are automatically revoked, all production and sandbox object permissions for the role are revoked, and then the temporary role is deleted.

[0072] Temporal prediction models can be built based on Long Short-Term Memory (LSTM) networks. The model training phase includes the following steps: First, data is collected from the execution logs of historical test tasks, extracting session features (including request type features and code complexity features) and actual runtime for each task to form a training sample set. Then, the session features are normalized to eliminate dimensional differences between features, generating a feature vector with uniform dimensions. Next, the feature vector is used as input, and the actual runtime as the label, to be fed into the LTM network for iterative training, with the network weights optimized through backpropagation. After model training is complete, the feature vector of the current test request is input into the trained model to obtain the predicted runtime.

[0073] Optionally, resource reclamation can be performed simultaneously when deleting a temporary role. That is, after revoking the temporary role's permissions, a cleanup task for the sandbox environment database objects is automatically triggered, deleting virtual views, intermediate result sets, and expired data generated during the current test session, and transferring content requiring archiving to a backup database according to a preset strategy. This application automates steps such as environment application, permission configuration, and resource reclamation, shortening the preparation time for data development and verification tasks, thereby accelerating the overall delivery process.

[0074] According to the embodiments of this application, by setting a temporary role bound to the test session and setting a session-level lifecycle for it, the automated dynamic management of permissions is realized, avoiding the problem of permission residue caused by untimely permission eviction in traditional static permission schemes, ensuring that permissions are only valid during the lifespan of the test session, thereby comprehensively protecting the security of data access.

[0075] Figure 4 A flowchart illustrating the initialization of a sandbox environment according to an embodiment of this application is shown. Figure 4 As shown, the method 400 of this embodiment may include steps S410 to S470.

[0076] In step S410, in response to the end of the current test session, a change set snapshot corresponding to the current test session is generated and stored in the snapshot repository.

[0077] In embodiments of this application, the change set snapshot includes at least temporary data records redirected to the sandbox environment and the database structure of unpublished database objects created within the sandbox environment.

[0078] For example, at the end of the test session, the database objects related to the current test request within the sandbox environment are scanned. For ordinary data tables, the table structure and data are exported as a file format; for unpublished database objects, their DDL table creation statements are exported as a database text file. Based on the exported content, a changeset snapshot file can be generated. This file can contain at least the following metadata information: snapshot number, session number, business type, identifiers of the database objects involved, creation time, checksum, etc. Finally, the changeset snapshot file is uploaded to the snapshot repository for persistent storage.

[0079] In step S420, in response to receiving a new test request, the similarity between the new test request and each change set snapshot in the snapshot repository is calculated.

[0080] For example, firstly, the business scenario and the identifiers of the database objects involved can be obtained from the new test request and converted into numerical or hash-type feature vectors. For change set snapshots, the business type and the table structure information involved are extracted from the snapshot metadata, and corresponding feature vector representations are generated. Then, the similarity, such as cosine similarity, between the feature vector of the new test request and the feature vector of each snapshot is calculated.

[0081] In step S430, it is determined whether the similarity is greater than the threshold.

[0082] In the embodiments of this application, the preset threshold may refer to a pre-set similarity threshold. Only change set snapshots with a similarity greater than or equal to this value will be selected for subsequent merging processing, while change set snapshots with a similarity lower than this value will be considered to have low reuse value and will be filtered out.

[0083] In step S440, based on similarity, multiple change set snapshots that meet a preset threshold of similarity are selected from the snapshot repository.

[0084] For example, a preset similarity threshold is read, the similarity calculation results of all snapshots in the snapshot repository are traversed, and change set snapshots below the threshold are filtered out in batches, while multiple change set snapshots that meet the conditions are retained.

[0085] Since similar business scenarios often rely on the same basic data and table structure logic, by calculating the similarity of feature vectors, it is possible to accurately identify candidate snapshots containing the required test data and unpublished object definitions, thereby providing reliable data support for the rapid initialization of the subsequent environment.

[0086] In step S450, multiple change set snapshots are merged in chronological order to generate a composite snapshot.

[0087] In the embodiments of this application, the selected change set snapshots are arranged in ascending order of creation time and applied sequentially starting from the earliest snapshot (i.e., sequential merging). For unpublished database objects, their DDL statements can be merged. By analyzing the change history of the DDL, intermediate state statements that have been modified or obsolete by subsequent snapshots are identified and removed, ensuring that the composite snapshot contains executable and up-to-date table creation scripts. When merging data records, for records with the same key value, the old value in the previous snapshot is overwritten with data from the subsequent snapshot; for newly added records, they are directly appended. In this way, it can be ensured that the merged data reflects the result of the most recent change, thereby generating a composite snapshot file that integrates multiple snapshots.

[0088] In step S460, the sandbox environment corresponding to the new test request is initialized based on the composite snapshot.

[0089] In the embodiments of this application, data from the composite snapshot can be used to create a database object in the sandbox environment and load the data, so that the sandbox environment is restored to the state recorded by the composite snapshot, thereby providing a data environment that can be used directly for new test tasks.

[0090] In step S470, the sandbox environment corresponding to the new test request is directly initialized.

[0091] In the embodiments of this application, if there is no change set snapshot in the snapshot repository that meets the similarity threshold, initialization is performed directly based on the test request.

[0092] According to the embodiments of this application, by reusing historical snapshots, the repetitive overhead of building a complete database structure and importing basic data from scratch for each test is avoided, which significantly shortens the initialization time of the sandbox environment and improves the startup efficiency and resource utilization of sandbox testing.

[0093] In embodiments of this application, the method may further include: in response to the end of the current test session, collecting operation logs triggered by the code to be verified within the sandbox environment; performing lexical and syntactic analysis on the operation logs to obtain database object access sequences; constructing a data lineage graph based on the database object access sequences, wherein the data lineage graph is a directed graph structure, nodes are used to represent database objects, edges are used to represent data flow relationships between database objects, and edge weights are used to represent data flow frequency; and generating a structured audit report based on the data lineage graph and a preset audit template.

[0094] Operation logs can refer to all the records of actions generated by code execution during the running of a test task.

[0095] For example, after the current test session ends, firstly, all operation logs generated during the execution of the code to be verified are collected. Then, lexical and syntactic analysis are performed on each collected log entry to identify and extract structured fields, such as the start timestamp of the operation, source database object identifier, target database object identifier, operation type, involved field names, and conditional expressions. These are then organized into a database object access sequence in chronological order, reflecting the data reading, writing, and transformation paths of the code to be verified in the sandbox environment. Next, each independent database object in this access sequence is mapped to a node in a graph, and directed edges are generated based on the dependencies between objects recorded in the access sequence. Simultaneously, the frequency of occurrence of the same data flow path during the session is counted and quantified as edge weights to distinguish between high-frequency and low-frequency data processing links. Finally, the field rules of the preset audit template are parsed, and corresponding data is extracted from the data lineage graph and original operation logs, automatically mapped and filled into the template fields, generating a standardized structured audit report.

[0096] According to embodiments of this application, technical support is provided for meeting compliance review requirements by collecting operation logs, parsing access sequences, constructing data lineage maps, and generating audit reports.

[0097] In the embodiments of this application, the data lineage graph can be obtained by: extracting data access records from the operation log, wherein the data access records at least include a source database object, a target database object, and operation conversion rules, wherein the operation conversion rules are the types of data operations performed by the code to be verified on the source database object; constructing directed edges with the source database object as the starting node and the target database object as the ending node, wherein the edge attributes of the directed edges include the operation conversion rules; and combining multiple directed edges and corresponding nodes to form the data lineage graph.

[0098] Specifically, firstly, several data access records are parsed from the operation log; then, the source database object, target database object, and specific operation transformation rules triggered by the code to be verified are extracted for each data access behavior, such as operation types like query, insert, update, delete, or aggregation; then, directed edges are established with the source database object as the starting node and the target database object as the ending node, with the operation type as the edge attribute and the data flow frequency as the weight of the directed edge; finally, all parsed directed edges and their associated nodes are globally integrated and deduplicated to eliminate redundant connections and duplicate nodes, forming a data lineage graph.

[0099] According to the embodiments of this application, by automatically extracting database object access sequences from operation logs and further constructing a visualized data lineage graph, the complete flow path and dependencies of data during the testing process can be intuitively and accurately restored. This can eliminate omissions and biases caused by manual sorting, significantly improve audit efficiency and transparency, and provide a reliable and traceable structured basis for subsequent security compliance checks, abnormal behavior tracing, and data governance.

[0100] Figure 5 A schematic flowchart illustrating the sandbox testing method according to an embodiment of this application is shown. Figure 5 As shown, the method 500 of this embodiment may include steps S510 to S590.

[0101] In step S510, the sandbox application is submitted. The target user submits a test request through the sandbox portal, specifying the read-only list of production tables to be accessed, the temporary table requirements, the expected usage duration, and the resource quota.

[0102] In step S520, permission approval is performed. The target user's test request is automatically routed to the relevant approver, such as the data owner or security administrator, according to preset rules. The approver conducts a compliance and security assessment based on the request content. If approval is granted, step S530 is executed; if approval is denied, step S540 is executed.

[0103] In step S530, permissions are orchestrated. After approval, a temporary role bound to this session is generated, and its lifespan is set. Based on the principle of least privilege, this role is granted read-only permissions for objects within the target runtime environment, and read / write permissions for objects within the sandbox environment.

[0104] In step S540, the request is terminated. The test request is terminated to avoid invalid resource allocation.

[0105] In step S550, the sandbox is prepared. The isolated execution environment required for this test request is initialized, including configuring a read-only access proxy for the target runtime environment and creating a dedicated sandbox database to handle write operations. If the request involves unpublished table structures, the corresponding table structures and virtual views will be created in the sandbox environment to support subsequent transparent code access.

[0106] In step S560, execution is isolated. The test task runs in an independent computing container. The interceptor parses each database statement in real time. For write operations targeting the target runtime environment, the interceptor automatically rewrites the target table to the corresponding table in the sandbox database, thus redirecting the write operation. For instructions referencing unpublished tables, they are transparently mapped to a pre-generated virtual view. Simultaneously, resource consumption can be monitored, and a circuit breaker mechanism can be triggered for abnormal behavior to ensure the stability of the production cluster.

[0107] In step S570, the result is verified. The target user can view the execution result in the sandbox environment to verify the correctness of the code logic, the data processing effect, and the performance. If the verification fails, proceed to step S590; if the verification passes, proceed to step S580.

[0108] In step S580, resource cleanup occurs. After verification ends or the preset lifespan is reached, a recycling mechanism is triggered to revoke all permissions of the temporary role, delete temporary data in the sandbox database, and clean up or archive related resources according to the policy. At the same time, the full-link operation log of this test session is summarized to generate a compliance audit report for subsequent review.

[0109] In step S590, problem diagnosis is performed. The cause of failure is analyzed and the code is adjusted. Then, step S510, sandbox application, is executed again.

[0110] Figure 6 A timing diagram of a sandbox testing method according to an embodiment of this application is illustrated schematically.

[0111] like Figure 6As shown, the target user submits a sandbox application through the sandbox portal. The application can specify the read-only list of required production tables, temporary table requirements, usage duration, and resource quotas. The sandbox portal will initiate an approval process and submit the application to the approval system. Upon receiving the application, the approval system automatically routes the request to the data owner and security administrator for approval according to preset rules. The data owner assesses whether the production tables involved in the application can be accessed and confirms whether the read-only scope of the application is reasonable. If the approval fails, the process terminates. The security administrator reviews the application from a security policy perspective, confirming whether the principle of minimizing temporary permissions is followed, and whether the verification duration, resource quotas, etc., comply with security specifications. Once both the data owner and the security administrator have approved the application, the results are returned to the sandbox portal, and the process enters the environment preparation phase. Based on the approved application, the sandbox execution engine begins to initialize the isolated sandbox environment for this session, including resource configuration and container isolation. Then, a temporary role with a lifespan is generated, and according to the principle of least privilege, read-only permissions are granted to this role to the specified production tables, ensuring that production data cannot be directly modified. Then, a separate sandbox database is created within the target runtime cluster for this session to handle the results of all write operations, achieving read-write separation. Once the sandbox environment is ready, the sandbox execution engine returns connection information (such as the database address and temporary credentials) to the sandbox portal, allowing the target user to submit verification tasks. The target user submits code to be verified to the sandbox execution engine through the sandbox portal, containing database statements. Upon receiving the code, the sandbox execution engine passes it to the built-in database statement interceptor for processing. The database statement interceptor uses abstract syntax tree technology to parse the database statements in the code to be verified: if a write operation to a production table is identified, the target table is automatically rewritten to the corresponding table in the sandbox-specific database; if an unpublished table structure is referenced, it is transparently mapped to a pre-generated virtual view; if it is a read-only query to a production table, it is passed as is. The rewritten read-only query instruction is sent to the production database to read all, real-time production data, ensuring the authenticity of the verification results. The redirected write operation instructions write the calculation results (such as feature data) to the sandbox-specific database. After the target user completes verification, they submit a resource cleanup request to the sandbox execution engine through the sandbox portal; or the cleanup process is automatically triggered after a preset lifespan. Upon receiving the cleanup request, the sandbox execution engine begins the resource reclamation process. All permissions for the temporary roles previously generated for this test session are immediately revoked to prevent security risks caused by residual permissions. Then, according to a preset policy, temporary data in the sandbox-specific database is archived. Next, all operation logs throughout the lifecycle of this sandbox session are summarized, including permission changes, database execution records, resource consumption, etc., and a structured audit report is automatically generated according to a compliance template. The audit system notifies the sandbox portal that the cleanup is complete and provides a download link for the audit report. The target user can obtain the report for compliance review.

[0112] Based on the above sandbox testing method, embodiments of this application also provide a sandbox testing apparatus. The following will combine... Figure 7 The device is described in detail.

[0113] Figure 7 A schematic block diagram of a sandbox testing apparatus according to an embodiment of this application is shown.

[0114] like Figure 7 As shown, the sandbox testing device 700 of this embodiment includes a sandbox environment initialization module 710, a code parsing module 720, a redirection module 730, and a test execution module 740.

[0115] The sandbox environment initialization module 710 is used to initialize a sandbox environment in response to a received test request. The test request includes at least the code to be verified. The sandbox environment is a logically isolated area deployed within the target runtime environment, and it contains mirrored database objects corresponding to each database object in the target runtime environment. In one embodiment, the sandbox environment initialization module 710 can be used to execute step S210 described above, which will not be repeated here.

[0116] The code parsing module 720 is used to parse the code to be verified to obtain the operation instruction type and the target database object corresponding to the operation instruction type. In one embodiment, the code parsing module 720 can be used to execute the step S220 described above, which will not be repeated here.

[0117] The redirection module 730 is used to redirect operations on the target database object in the code to be verified to the corresponding mirrored database object in the sandbox environment when the target database object belongs to the target runtime environment and the operation instruction type is a data definition language instruction or a non-query data manipulation language instruction. In one embodiment, the redirection module 730 can be used to execute step S230 described above, which will not be repeated here.

[0118] The test execution module 740 is used to execute the redirected code to be verified within a sandbox environment to return test results. In one embodiment, the test execution module 740 can be used to execute step S240 described above, which will not be repeated here.

[0119] According to an embodiment of this application, the code parsing module 720 is further configured to perform lexical analysis and syntactic analysis on the code to be verified to obtain an abstract syntax tree; traverse each node in the abstract syntax tree and determine the operation instruction type corresponding to the node based on the node type; and locate the target database object corresponding to the operation instruction type from the abstract syntax tree based on the grammar rules corresponding to the operation instruction type.

[0120] According to an embodiment of this application, the sandbox environment initialization module 710 is further configured to, in response to the code to be verified containing a reference to an unpublished database object, create a corresponding database structure in the sandbox environment based on the structure definition information of the unpublished database object; generate a virtual view of the unpublished database object based on the database structure; and redirect the reference identifier of the unpublished database object in the code to be verified to the identifier of the virtual view.

[0121] According to an embodiment of this application, the sandbox testing device 700 further includes: a temporary role module, an audit report generation module, and a data lineage graph generation module.

[0122] The Temporary Role module is used to generate a temporary role corresponding to the current test session based on the test request. The temporary role has read-only permissions for database objects in the target runtime environment and read / write permissions for mirrored database objects in the sandbox environment. The module obtains the session features of the test request and inputs them into a pre-trained time series prediction model to obtain the predicted runtime. The session features include at least the request type feature and the complexity feature of the code to be verified. The time series prediction model is built based on a Long Short-Term Memory network. The predicted runtime is set as the lifetime of the temporary role. In response to the expiration of the lifetime, the permissions of the temporary role are revoked.

[0123] The audit report generation module is used to collect operation logs triggered by the code to be verified within the sandbox environment in response to the end of the current test session; perform lexical and syntactic analysis on the operation logs to obtain database object access sequences; construct a data lineage graph based on the database object access sequences, where the data lineage graph is a directed graph structure, nodes are used to represent database objects, edges are used to represent the data flow relationships between database objects, and edge weights are used to represent the frequency of data flow; and generate a structured audit report based on the data lineage graph and a preset audit template.

[0124] According to an embodiment of this application, a data lineage graph generation module is used to extract data access records from operation logs. The data access records include at least a source database object, a target database object, and operation conversion rules. The operation conversion rules are the types of data operations performed by the code to be verified on the source database object. Directed edges are constructed with the source database object as the starting node and the target database object as the ending node. The edge attributes of the directed edges include the operation conversion rules. Multiple directed edges and corresponding nodes are combined to form a data lineage graph.

[0125] In another embodiment of this application, the sandbox environment initialization module 710 is further configured to, in response to the end of the current test session, generate a changeset snapshot corresponding to the current test session and store it in a snapshot repository, wherein the changeset snapshot includes at least temporary data records redirected to the sandbox environment and the database structure of unpublished database objects created within the sandbox environment; in response to receiving a new test request, calculate the similarity between the new test request and each changeset snapshot in the snapshot repository; based on the similarity, select multiple changeset snapshots whose similarity meets a preset threshold from the snapshot repository; merge the multiple changeset snapshots in chronological order to generate a composite snapshot; and initialize the sandbox environment corresponding to the new test request based on the composite snapshot.

[0126] According to embodiments of this application, any multiple modules among the sandbox environment initialization module 710, code parsing module 720, redirection module 730, and test execution module 740 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the sandbox environment initialization module 710, code parsing module 720, redirection module 730, and test execution module 740 can be at least partially implemented as hardware circuitry, such as field-programmable gate arrays, programmable logic arrays, systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits, or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the sandbox environment initialization module 710, code parsing module 720, redirection module 730, and test execution module 740 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0127] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a sandbox testing method according to an embodiment of this application.

[0128] like Figure 8As shown, an electronic device 800 according to an embodiment of this application includes a processor 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory 802 or a program loaded from a storage portion 808 into a random access memory 803. The processor 801 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 801 may also include onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0129] Random access memory 803 stores various programs and data required for the operation of electronic device 800. Processor 801, read-only memory 802, and random access memory 803 are interconnected via bus 804. Processor 801 executes various steps of the method flow according to embodiments of this application by executing programs stored in read-only memory 802 and / or random access memory 803. It should be noted that the programs may also be stored in one or more memories other than read-only memory 802 and random access memory 803. Processor 801 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0130] According to embodiments of this application, the electronic device 800 may further include an input / output interface 805, which is also connected to a bus 804. The electronic device 800 may also include one or more of the following components connected to the input / output interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card, such as a local area network card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the input / output interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 810 as needed so that computer programs read from it can be installed into the storage section 808 as needed.

[0131] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0132] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can 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. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 802 described above, and / or random access memory 803, and / or one or more memories other than read-only memory 802 and random access memory 803.

[0133] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0134] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 809, and / or installed from a removable medium 811. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0135] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 809, and / or installed from removable medium 811. When the computer program is executed by processor 801, it performs the functions defined in the system of embodiments of this application. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0136] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0137] 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 application. 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 a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may 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.

[0138] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A sandbox testing method, characterized in that, The method includes: In response to receiving a test request, a sandbox environment is initialized based on the test request, wherein the test request includes at least the code to be verified, the sandbox environment is a logically isolated area deployed within the target runtime environment, and the sandbox environment contains mirror database objects corresponding to each database object in the target runtime environment; The code to be verified is parsed to obtain the operation instruction type and the target database object corresponding to the operation instruction type; In response to the fact that the target database object belongs to the target runtime environment and the operation instruction type is a data definition language instruction or a non-query data manipulation language instruction, the operation on the target database object in the code to be verified is redirected to the corresponding mirror database object in the sandbox environment; The redirected code to be verified is executed within the sandbox environment to return the test results.

2. The method according to claim 1, characterized in that, The step of parsing the code to be verified in the test request to obtain the operation instruction type and the target database object corresponding to the operation instruction type includes: Lexical and syntactic analysis are performed on the code to be verified to obtain an abstract syntax tree; Traverse each node in the abstract syntax tree and determine the operation instruction type corresponding to the node based on the node type; Based on the syntax rules corresponding to the operation instruction type, the target database object corresponding to the operation instruction type is located from the abstract syntax tree.

3. The method according to claim 1, characterized in that, The initialization of the sandbox environment based on the test request includes: In response to the fact that the code to be verified contains a reference to an unpublished database object, a corresponding database structure is created in the sandbox environment based on the structure definition information of the unpublished database object. Based on the database structure, a virtual view of the unpublished database object is generated; The reference identifier to the unpublished database object in the code to be verified is redirected to the identifier of the virtual view.

4. The method according to claim 1, characterized in that, The method further includes: Based on the test request, a temporary role corresponding to the current test session is generated, wherein the temporary role has read-only permissions for database objects in the target runtime environment and read / write permissions for mirrored database objects in the sandbox environment; The session features of the test request are obtained, and the session features are input into a pre-trained temporal prediction model to obtain the predicted runtime. The session features include at least the request type features and the complexity features of the code to be verified. The temporal prediction model is built based on a long short-term memory network. Set the predicted runtime to the survival time of the temporary role; In response to the expiration of the specified lifespan, the permissions of the temporary role are revoked.

5. The method according to claim 4, characterized in that, The initialization of the sandbox environment based on the test request includes: In response to the end of the current test session, a change set snapshot corresponding to the current test session is generated and stored in the snapshot repository. The change set snapshot includes at least temporary data records redirected to the sandbox environment and the database structure of unpublished database objects created within the sandbox environment. In response to receiving a new test request, the similarity between the new test request and each change set snapshot in the snapshot repository is calculated; Based on the similarity, multiple change set snapshots whose similarity meets a preset threshold are selected from the snapshot repository; The multiple change set snapshots are merged in chronological order to generate a composite snapshot; The sandbox environment corresponding to the new test request is initialized based on the composite snapshot.

6. The method according to claim 4, characterized in that, The method further includes: In response to the end of the current test session, the operation logs triggered by the code to be verified within the sandbox environment are collected; Lexical and syntactic analysis are performed on the operation log to obtain the database object access sequence; Based on the database object access sequence, a data lineage graph is constructed, wherein the data lineage graph is a directed graph structure, nodes are used to represent database objects, edges are used to represent the data flow relationship between the database objects, and edge weights are used to represent the data flow frequency. Based on the data lineage map and the preset audit template, a structured audit report is generated.

7. The method according to claim 6, characterized in that, The kinship map data was obtained using the following method: Extract data access records from the operation log. The data access records include at least a source database object, a target database object, and an operation conversion rule. The operation conversion rule is the type of data operation performed by the code to be verified on the source database object. A directed edge is constructed with the source database object as the starting node and the target database object as the ending node, wherein the edge attributes of the directed edge include the operation transformation rules; The multiple directed edges and their corresponding nodes are combined to form a data lineage graph.

8. A sandbox testing device, characterized in that, The device includes: A sandbox environment initialization module is used to initialize a sandbox environment based on a received test request. The test request includes at least code to be verified. The sandbox environment is a logically isolated area deployed within the target runtime environment. The sandbox environment contains mirror database objects corresponding to each database object in the target runtime environment. The code parsing module is used to parse the code to be verified to obtain the operation instruction type and the target database object corresponding to the operation instruction type; The redirection module is configured to, in response to the target database object belonging to the target runtime environment and the operation instruction type being a Data Definition Language instruction or a non-query Data Manipulation Language instruction, redirect the operation on the target database object in the code to be verified to the corresponding mirror database object within the sandbox environment; and The test execution module is used to execute the redirected code to be verified within the sandbox environment to return test results.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images