A Non-Destructive Synchronization Method and System for Test Cases Based on Template Instructions and Atomic Transactions
By using a template instruction and atomic transaction-based approach, the problems of difficult incremental synchronization, non-atomic operations, and imprecise intent expression in existing technologies are solved, achieving efficient and reliable test case management and improving system processing efficiency and user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING ZHONGQI YUNLIAN IND FINANCE TECHNOLOGY CO LTD
- Filing Date
- 2026-02-02
- Publication Date
- 2026-06-02
Smart Images
Figure CN122132121A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software test management technology, and in particular to a non-destructive synchronization method and system for test cases based on template instructions and atomic transactions. Background Technology
[0002] In software development, test cases are a crucial means of ensuring product quality. With frequent product iterations, the number of test cases is enormous and updates are frequent. Testing teams typically use a combination of online and offline methods for test case management. For example, test cases are written and modified in Excel and then synchronized to an online test management platform. However, existing data synchronization mechanisms are mostly based on a full-coverage model, where users need to export all test case templates from the platform, modify them, and then re-upload them all, with the platform directly overwriting the original data. While simple to implement, this model has significant drawbacks: First, it cannot support incremental synchronization; even modifying only a few test cases requires uploading the entire dataset, leading to low network transmission and processing efficiency. Second, it lacks atomicity guarantees; when some instructions fail in batch operations, the platform data is prone to inconsistencies, compromising data integrity. Third, it's difficult to express multiple operational intentions such as create, update, delete, and reorder simultaneously in a single operation; users often need multiple discrete operations to complete complex changes, making the process cumbersome and error-prone. Furthermore, existing methods often use a write-after-over mechanism in concurrent scenarios, failing to detect data conflicts and easily leading to data overwriting and loss during collaboration. Summary of the Invention
[0003] In view of this, embodiments of the present invention provide a non-destructive synchronization method and system for test cases based on template instructions and atomic transactions, in order to solve the problems of existing technologies that do not support incremental synchronization, lack operational atomicity, and are difficult to accurately express the intent of mixed operations.
[0004] On one hand, the present invention provides a non-destructive synchronization method for test cases based on template instructions and atomic transactions, the method comprising: Receive a structured template file, which contains at least one data record row. Each data record row includes at least an operation instruction field and a unique identifier field. The operation instruction field is used to indicate the type of operation to be performed on the test case corresponding to the data record row. The operation type includes create, update, delete, or reorder. The structured template file is parsed to generate an instruction object corresponding to each data record row, forming an instruction list; Based on the unique identifier field of each instruction object in the instruction list, the corresponding test case records are pre-queried from the database, and a hash mapping with the unique identifier field as the key is constructed in memory; Start a database transaction; Iterate through each instruction object in the instruction list and perform corresponding data operations based on the operation instruction field of the instruction object and the hash mapping: if the operation instruction field indicates creation, insert a new test case record into the database; if it indicates update, locate the corresponding test case record from the hash mapping based on the unique identifier field, verify the version information is consistent, and then perform the update; if it indicates deletion, locate and delete the corresponding test case record; if it indicates reordering, update the order values of multiple test cases in batches according to the sorting algorithm. If all instruction objects are executed successfully, the database transaction is committed; otherwise, the database transaction is rolled back. Generate a synchronization report, which includes the execution results and conflict information.
[0005] In some embodiments of the present invention, based on the unique identifier field of each instruction object in the instruction list, the corresponding test case record is pre-queried from the database, and a hash mapping is constructed in memory, including: Before initiating the database transaction, a batch query is initiated to the database to retrieve test case records associated with all unique identifier fields in the instruction list; The retrieved records are stored in the server memory using the unique identifier field as the key, forming the hash map, which is used for quick location during subsequent data operations.
[0006] In some embodiments of the present invention, the update is performed after verifying that the version information is consistent, including: Extract the expected version number from the current instruction object; The current version number of the target test case recorded in the database is obtained through the hash mapping. Compare the expected version number with the current version number; if they match, perform a database update operation and update the version number recorded in the target test case; if they do not match, determine that there is a version conflict, stop the execution of the current instruction and record the conflict information.
[0007] In some embodiments of the present invention, the method further includes: When a database transaction is rolled back due to a version conflict, a conflict report is generated and output. The conflict report includes at least a unique identifier field for the test case that caused the conflict, and the data content differences between the expected version number and the current version number.
[0008] In some embodiments of the present invention, updating the order values of multiple test cases in batches according to a sorting algorithm includes: Collect all operation instructions into a reordered instruction object; Based on the new order value specified in the instruction object, a set of final order values that are non-repeating and maintain relative order are calculated for all affected test cases using the gap sorting algorithm; The final sequence value is atomically written to the corresponding test case record through a batch database update operation.
[0009] In some embodiments of the present invention, the structured template file is a spreadsheet file.
[0010] In some embodiments of the present invention, the column identifier of the operation instruction field in the spreadsheet file is "action", and the column identifier of the unique identifier field is "uid".
[0011] In some embodiments of the present invention, when the operation instruction field indicates creation and the corresponding unique identifier field is empty, inserting a new test case record into the database includes: A system-globally unique identifier is generated for the new test case record, and this identifier is stored as the value of the unique identifier field.
[0012] On the other hand, the present invention provides a non-destructive synchronization system for test cases based on template instructions and atomic transactions, including a processor, a memory, and a computer program / instructions stored in the memory, wherein the processor is used to execute the computer program / instructions, and when the computer program / instructions are executed, the system implements the steps of any of the methods mentioned above.
[0013] On the other hand, the present invention also provides a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of any of the methods mentioned above.
[0014] This invention provides a non-destructive test case synchronization method and system based on template instructions and atomic transactions. By reconstructing traditional data templates into structured files containing explicit operation instructions and unique identifiers, the system can accurately identify and execute complex mixed operations such as user creation, updating, deletion, and reordering of test cases. This fundamentally changes the previous full-coverage synchronization mode and achieves precise, non-destructive data synchronization based on intent.
[0015] Furthermore, in terms of technology, this invention introduces a pre-built memory hash mapping mechanism, which pre-builds and caches a large number of database query operations in memory, reducing the data location overhead during instruction execution from the database I / O level to the memory access level, thereby significantly improving the processing efficiency and system response speed of large-scale test case synchronization.
[0016] Furthermore, by encapsulating the entire synchronization process within a single database transaction, this invention ensures the atomicity of all heterogeneous data operations, completely eliminating the risk of intermediate data states caused by partial operation failures, and providing enterprise-level data consistency and integrity guarantees for the test management platform. Its integrated optimistic locking conflict detection mechanism can intelligently identify data version conflicts in concurrent scenarios and provide a diagnostic report containing detailed data differences after rolling back the transaction. This enables the system not only to prevent data overwriting but also to proactively assist users in locating and resolving collaboration conflicts, significantly improving the system's robustness and multi-user collaboration experience.
[0017] In summary, this invention not only solves the long-standing pain points in test case management, such as difficulty in incremental synchronization, non-atomic operations, and imprecise expression of intent, but also achieves substantial breakthroughs in multiple dimensions, including efficiency, security, reliability, and user experience, through a series of synergistic technical means, providing a complete technical solution for the efficient, reliable, and collaborative management of software test data.
[0018] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.
[0019] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description
[0020] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. In the drawings: Figure 1 This is a schematic diagram illustrating the steps of a non-destructive synchronization method for test cases based on template instructions and atomic transactions in one embodiment of the present invention.
[0021] Figure 2 This is a flowchart illustrating a non-destructive synchronization method for test cases based on template instructions and atomic transactions in one embodiment of the present invention. Detailed Implementation
[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.
[0023] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.
[0024] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.
[0025] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.
[0026] In the following description, embodiments of the invention will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.
[0027] It should be emphasized here that the step markers mentioned below are not a limitation on the order of the steps, but should be understood as meaning that the steps can be executed in the order mentioned in the embodiments, or in a different order than in the embodiments, or several steps can be executed simultaneously.
[0028] To address the shortcomings of existing technologies, such as lack of support for incremental synchronization, lack of operational atomicity, and difficulty in accurately expressing the intent of mixed operations, this invention provides a non-destructive synchronization method for test cases based on template instructions and atomic transactions, such as... Figure 1 As shown, the method includes the following steps S101~S107: Step S101: Receive a structured template file containing at least one data record row. Each data record row includes at least an operation instruction field and a unique identifier field. The operation instruction field indicates the type of operation to be performed on the test case corresponding to the data record row. The operation type includes create, update, delete, or reorder.
[0029] Step S102: Parse the structured template file to generate instruction objects corresponding to each data record row, forming an instruction list.
[0030] Step S103: Based on the unique identifier field of each instruction object in the instruction list, pre-query the corresponding test case records from the database and construct a hash mapping in memory with the unique identifier field as the key.
[0031] Step S104: Start the database transaction.
[0032] Step S105: Traverse each instruction object in the instruction list and perform the corresponding data operation based on the operation instruction field and hash mapping of the instruction object: If the operation instruction field indicates creation, insert a new test case record into the database; if it indicates update, locate the corresponding test case record from the hash mapping based on the unique identifier field, verify the version information is consistent, and then perform the update; if it indicates deletion, locate and delete the corresponding test case record; if it indicates reordering, update the order values of multiple test cases in batches according to the sorting algorithm.
[0033] Step S106: If all instruction objects are executed successfully, commit the database transaction; otherwise, roll back the database transaction.
[0034] Step S107: Generate a synchronization report, which includes execution results and conflict information.
[0035] like Figure 2 The diagram shows a flowchart of a non-destructive synchronization method for test cases based on template instructions and atomic transactions.
[0036] In step S101, a structured template file is received.
[0037] This step aims to receive and identify user-submitted input files that convey explicit data manipulation intentions. Its core function is to redefine traditionally static data templates as a dynamic set of executable instructions, thereby providing structured input for subsequent intent parsing and precise synchronization. This solves the problem in existing technologies where mixed operational intentions cannot be accurately expressed in a single operation.
[0038] In some embodiments, step S101 is specifically implemented by combining a client-server interaction mode with structured file parsing technology, including two parts: file submission and reception, and the structured definition of template files, including: Users can select a locally edited template file (such as a spreadsheet file with the extension .xlsx or .csv) and submit it through the upload component integrated into the test management platform's web interface or desktop client.
[0039] The client transmits the file stream to the system's backend server via HTTP / HTTPS protocol using a POST request (typically using multipart / form-data encoding). The server deploys a dedicated file upload interface (such as a RESTful API endpoint), which is responsible for receiving the uploaded file stream, performing basic validity checks such as file size, type, and non-empty checks, and temporarily storing the file in a secure directory or memory buffer specified by the server for subsequent parsing.
[0040] The data received in this step is not an arbitrary data file, but a structured template file with a predefined structure. Each row (i.e., a data record row) of the template corresponds to an independent operation instruction for the test case, and each column defines different attributes of the instruction.
[0041] In some embodiments, the semantics and format of key fields are defined as follows: Action Field: This field is the core of each record. Its value is a predefined enumerated string or code used to precisely instruct the system what atomic operation to perform for the test case associated with this record. Typical values include: "Create" or "C": indicates that a new test case is added.
[0042] "Update" or "U": indicates updating an existing test case.
[0043] "Delete" or "D": This indicates that an existing test case will be deleted.
[0044] “Reorder” or “R”: indicates adjusting the display or execution order of one or more test cases.
[0045] The Unique Identifier (UID) field is used to uniquely and permanently associate a specific test case record in the database.
[0046] This field is required for Update, Delete, and Reorder operations. Its value should be a unique identifier (such as a database primary key or a globally unique UUID) that has been assigned and remains unchanged in the system for the target test case, to ensure that the system can accurately locate the operation object.
[0047] For the Create operation, this field can be empty. If empty, the system will generate a new identifier for it in subsequent steps; if the user pre-fills a value (e.g., pre-generated by an external system), the system will attempt to use that value as the UID of the new record (uniqueness verification is required).
[0048] In some embodiments, in addition to the core fields mentioned above, fields for implementing advanced functions and carrying business data are also included: Version Field: Typically used in conjunction with the Update operation, it carries the user's expected data version number and is a key input for implementing optimistic locking conflict detection.
[0049] Order Field: Typically used in conjunction with the Reorder operation, it specifies the new order value that the user expects.
[0050] Business content fields, such as title (test case title), steps (test steps), and expected_result (expected result), are used to populate or modify the specific content of the test case when it is created or updated.
[0051] In step S102, the structured template file is parsed to generate instruction objects corresponding to each data record row, forming an instruction list.
[0052] This step is the core transformation link connecting user intent (structured template) and system execution logic (instruction processing engine). Its function is to accurately and efficiently transform the structured operation instructions received in step S101, stored in a specific file format (such as a spreadsheet), into an internal data structure that the computer program can directly recognize and process. This process achieves a qualitative change from data files to executable instruction sequences, laying the foundation for subsequent atomic and routed execution.
[0053] In some embodiments, step S102 includes four parts: file format recognition and loading, data structure mapping and field extraction, constructing instruction objects, and building and verifying instruction lists. The following technical operations are executed sequentially through the template parser module: First, the system identifies the specific format of the received file based on its file extension (e.g., .xlsx) or header information. Then, it calls the appropriate file processing library, such as Apache POI for processing Excel files or OpenCSV for processing CSV files, to load the file from a binary stream or temporary storage location into the server's memory, forming a program-accessible Document Object Model (DOM) or a data row iterator.
[0054] Next, the parser traverses each data record row of the template according to the predefined field mapping rules, including: The parser locates the corresponding cell in each line of the file based on pre-configured column names (such as action, uid, version, order, title, etc.) or column indices.
[0055] Read raw data (strings, numbers, etc.) from the located cell.
[0056] Perform necessary processing on the extracted raw values, such as: removing leading and trailing spaces from the string; converting empty cells or specific placeholders (such as N / A) to null values within the program; and standardizing the case of the action field values (such as converting them all to uppercase CREATE) or mapping them to predefined enumeration constants.
[0057] For each line of cleaned data, the parser instantiates an instruction object. This object is an in-memory data structure (e.g., an instance of a specific class, which might be an InstructionDTO or Command object in Java), and its attributes correspond one-to-one with the template fields. Typical instruction object attributes include: action (enumeration type): Stores the operation type, such as CREATE, UPDATE, DELETE, REORDER.
[0058] uid (string type): Stores a unique identifier, which may be null (for new operations).
[0059] version (long integer or string type): Stores the expected version number, which may be null for non-update operations.
[0060] order (integer or floating-point): Stores the expected order of values.
[0061] content (object or mapping type): Stores the extracted business fields (such as title, steps, etc.), usually encapsulated as an independent business data object.
[0062] Each successfully constructed instruction object is added to an ordered collection (such as a List) in the order it appears in the template. <instruction>In the end, an instruction list is formed.
[0063] In some embodiments, during or after the build process, the parser performs basic business logic validation, including: Check required fields: For UPDATE, DELETE, and REORDER operations, verify that the uid field is not empty.
[0064] Check the validity of the operation type: Verify that the value of the action field belongs to the set of allowed enumeration values.
[0065] Check data format: Verify that fields such as version and order meet the expected number or format requirements.
[0066] If verification fails, the parser can immediately throw an exception and abort the process, or mark the verification error in the instruction object and summarize the error information into the final report.
[0067] In step S103, based on the unique identifier field of each instruction object in the instruction list, the corresponding test case records are pre-queried from the database, and a hash mapping with the unique identifier field as the key is constructed in memory.
[0068] This step is a key performance optimization step in this invention, aiming to solve the problem of huge I / O overhead and response latency caused by traditional record-by-record database queries. Its core function is to sacrifice a single efficient batch query before formally executing data operations to achieve instantaneous memory access speed for all subsequent data location operations. By preloading database records into memory and establishing an efficient index structure, the path is paved for subsequent atomic transaction execution, which is the core technical guarantee for achieving high-performance non-destructive synchronization.
[0069] In some embodiments, step S103 is to convert from database-intensive operations to memory-intensive operations, sequentially performing unique identifier set extraction and deduplication, performing efficient batch database queries, and constructing a memory hash map, specifically including: First, iterate through the instruction list generated in step S102, collecting all non-empty uid values from each instruction object. These uid values represent all existing test cases intended to be affected by this synchronization operation (i.e., objects of UPDATE, DELETE, REORDER operations, and records with pre-filled uids in CREATE operations). The collected uid set is deduplicated because the same test case may be referenced in multiple instructions. This ensures the uniqueness of subsequent queries and avoids invalid duplicate queries.
[0070] Based on the deduplicated set of uids, the system constructs a parameterized query. For example, in relational databases (such as MySQL and PostgreSQL), it generates an SQL statement like `SELECT * FROM test_cases WHERE uid IN (?, ?, ...)`, binding the deduplicated set of uids as a parameter list. This query is sent and executed all at once through the database connection, returning all relevant test case records as a result set. This query process is completed before starting the formal database transaction (step S104), constituting a preparatory operation outside the transaction, thus not consuming transaction execution time and unaffected by transaction isolation levels, ensuring the timeliness of data retrieval.
[0071] After the query results are returned, the system initializes a hash map data structure in the server's memory (such as the Java Heap). Then, the program iterates through each test case record returned by the database and performs the following operations: Extract the uid field value from the record as the primary key or unique identifier.
[0072] The key status information of this record is encapsulated into a lightweight data snapshot object. This object should contain at least the following: the record's primary key (usually the same as the uid), the current version number, the current order number, and other key fields (such as title, hash value of steps, or the content itself) that are cached as needed for conflict comparison.
[0073] The extracted uid is used as the key, and the encapsulated data snapshot object is used as the value, which is then stored in the previously initialized hash map.
[0074] At this point, an in-memory database (cache) indexed by uid and containing the current state of the target test case is complete. This mapping achieves a lookup performance with an average time complexity of O(1).
[0075] In step S104, a database transaction is initiated.
[0076] This step aims to establish an atomic, consistent, isolated, and durable execution context for all subsequent heterogeneous data operations. Its core function is to create a logical unit of work at the database level, encapsulating and isolating all data modification operations (insert, delete, update, sort) that will occur after step S103. This ensures that these operations either all complete successfully or are completely rolled back in the event of any failure, thereby guaranteeing the eventual consistency of the platform's data. This is a core technical approach to solving the problem of intermediate data states caused by partial success in existing technologies.
[0077] In some embodiments, step S104 includes invoking the transaction management module, obtaining and configuring the database connection and transaction context binding, which is achieved through the system's transaction management module working in conjunction with the database driver, specifically including: After pre-querying and memory mapping are completed, and before the actual instruction list is traversed and executed, the system's transaction management module is invoked. This module is typically implemented based on the transaction management API provided by the programming language or framework.
[0078] The transaction management module obtains an available connection object from the database connection pool. Then, it performs a critical operation: setting the automatic commit mode of the connection to off. This means that all SQL statements (INSERT, UPDATE, DELETE) executed through this connection will not be immediately persisted to the database; the resulting changes will temporarily reside in the database server's transaction log and the context of this connection, forming a pending state.
[0079] In some embodiments, to ensure that the synchronization operation is not interfered with by other concurrent transactions and to avoid unnecessary blocking of other parts of the system, the transaction management module usually sets an appropriate isolation level for this transaction. For example, it may be set to Read Committed or Repeatable Read. This can prevent the reading of dirty data that has not been committed by other transactions during the synchronization process, and ensure that the data view on which this synchronization is based is stable and consistent.
[0080] Once a transaction is initiated, the database connection (or the context object representing the transaction) is bound to the thread or request context currently executing the business logic. This ensures that all database operations performed through the Data Access Layer (DAO) in subsequent execution loops use the same transactional connection.
[0081] In step S105, each instruction object in the instruction list is traversed, and the corresponding data operation is performed according to the operation instruction field and hash mapping of the instruction object: if the operation instruction field indicates creation, a new test case record is inserted into the database; if it indicates update, the corresponding test case record is located from the hash mapping based on the unique identifier field, and the update is performed after verifying that the version information is consistent; if it indicates deletion, the corresponding test case record is located and deleted; if it indicates reordering, the order values of multiple test cases are updated in batches according to the sorting algorithm.
[0082] This step is responsible for accurately and efficiently converting the parsed user intent (instruction list) into specific database operations. Its purpose is to implement an instruction routing and distribution mechanism based on operation type. According to the `action` field of each instruction, it schedules it to the corresponding dedicated processing unit for execution, thereby atomically completing heterogeneous operations such as insert, delete, update, and sort within a unified transaction framework. This solves the problem of existing technologies being unable to mix and execute multiple intents within a single operation.
[0083] In some embodiments, step S105 is executed by the synchronization processing engine within an initiated database transaction. Specifically, it is implemented as a loop control structure that iterates through the instruction list and performs multi-path branching based on the action value. This includes: Initialize a loop that iterates over the instruction list generated in step S102, processing each instruction object in the order listed. For each instruction object, execute the following logic.
[0084] First, for the current instruction object, the synchronous processing engine reads the value of its `action` field. Based on this value, the engine uses conditional branching (such as a switch-case statement) or the strategy pattern to route the instruction object to the corresponding, single-function execution logic unit.
[0085] Then, when the action is Create, the system is routed to the Create execution unit to perform the following operations: Extract business fields (such as title, steps, etc.) from the content attribute of the instruction object and combine them into a complete test case data record.
[0086] Check the uid field of the instruction object. If uid is empty or a specific placeholder, a globally unique identifier is generated by the system (e.g., a version 4 UUID is generated using the UUID algorithm). If uid has a value (pre-generated by the user), that value is used, but its global uniqueness must be ensured before insertion by using database unique constraints or querying the memory map (if the UUID is already included in the pre-query phase).
[0087] Construct an SQL statement `INSERT INTO test_cases (uid, title, steps, ..., version, order) VALUES (?, ?, ..., 1, ?)` that binds the assembled data (including the generated or passed-in `uid`, and the default initial version number, such as `version=1`) to the parameters, and executes it through a database connection within a transaction. The `order` value of the new record can be specified according to the instruction or set according to the system default rules.
[0088] When the action is Update, the system routes to the Update Execution Unit, which integrates an optimistic locking conflict detection mechanism and performs the following operations: Using the instruction object's uid as the key, the memory hash mapping constructed in step S103 is queried to instantly obtain the data snapshot object of the target test case. If this uid does not exist in the mapping, it means that the target record does not exist, and the instruction execution is immediately marked as failed.
[0089] The value of the version field (expected version number) is extracted from the instruction object and compared with the current version number (current_version) in the data snapshot object retrieved from the memory map to achieve optimistic locking conflict detection.
[0090] If the version numbers match, an atomic update SQL statement is constructed and executed, for example: `UPDATE test_cases SET title=?, steps=?, ..., version = version + 1 WHERE uid = ? AND version = ?`. This statement uses row-level locking and atomic increment operations to update the content while simultaneously incrementing the version number. After execution, if the database returns 1 affected rows, the update is successful; if it is 0, a checksum race condition may have occurred, which is also considered a conflict.
[0091] If the version numbers are inconsistent, or if the database returns 0 affected rows after an atomic update, it is considered an operation conflict (including optimistic locking conflicts). The system immediately records the conflict details (conflict UID, expected value, and current value, etc.) and marks the current instruction as failed, which will trigger a transaction rollback.
[0092] When the action is Delete, the system is routed to the delete execution unit, which performs the following operations: Similarly, using the instruction object's uid as the key, query the memory hash mapping to confirm the existence of the target record.
[0093] Construct and execute the SQL statement `DELETE FROM test_cases WHERE uid = ?`. Alternatively, perform a logical delete based on business rules (`UPDATE test_cases SET is_deleted = 1 WHERE uid = ?`).
[0094] When the action is Reorder, the route is directed to the reordering execution unit. This unit uses batch processing mode to optimize performance and ensure the atomicity of sorting, and specifically performs the following operations: Since sorting typically involves rearranging the order of a set of use cases, the system collects all instruction objects with the action "Reorder" in the current instruction list, or maintains a temporary list of instructions to be sorted within the unit. To optimize performance, the loop can be paused when the first "Reorder" instruction is encountered, and all sorting instructions can be processed at once before continuing.
[0095] Based on the collected instructions (each instruction contains a uid and a desired order value), a gap sorting algorithm is employed. This algorithm calculates the final order value of all affected test cases by assigning a new, non-conflicting order value to each record, for example, by generating an arithmetic sequence with a fixed step size such as 1000, or by using floating-point numbers or string sorting, thus forming a mapping from uid to new_order.
[0096] Based on the above mapping, construct a batch update SQL statement, such as `UPDATE test_cases SET order = CASEuid WHEN ? THEN ? ... END WHERE uid IN (?, ...)`, and execute it all at once using a transaction join. This ensures that all order adjustments are atomic at the database level.
[0097] In step S106, if all instruction objects are executed successfully, the database transaction is committed; otherwise, the database transaction is rolled back.
[0098] This step is the final implementation stage of the atomicity commitment and consistency guarantee of this invention. Its function is to make a final decision on the database transaction initiated in step S104: based on the execution results of all instruction objects in step S105, it decides whether to make all data changes within the transaction permanent or to completely roll back all changes. This ensures the all-or-nothing characteristic of synchronous operations, which is a key step in solving the core defect in the prior art where data is in an inconsistent intermediate state due to the failure of some operations.
[0099] In some embodiments, step S106 is triggered after the complete completion of the traversal execution loop in step S105. The transaction management module performs logical judgments and database operations based on the status information collected during execution, including summarizing and determining execution results, transaction commit, and transaction rollback. Specifically: Maintain a global execution status flag. During the traversal execution in step S105: After each instruction is successfully executed (such as INSERT / UPDATE / DELETE, or Reorder batch update), the system does not perform any special operations and continues in a loop.
[0100] If any instruction fails to execute (including but not limited to: optimistic locking conflict in update operations, non-existent target record in delete operations, primary key conflict in create operations, any database SQL execution exception, or business logic validation failure), the system immediately terminates the current traversal loop. Simultaneously, the global execution status flag is marked as failed, and specific error and conflict information is recorded. This information will be used to generate a report in step S107.
[0101] After the traversal is complete, the transaction management module checks this global status flag.
[0102] If the global status flag is successful (i.e., all instructions were successfully processed without any failures), the transaction management module sends a COMMIT instruction to the database server through the database connection bound to the current transaction. Specifically, this includes: After receiving the COMMIT instruction, the database server persists all modifications recorded in the transaction log since the start of this transaction (i.e., data page changes caused by all successful INSERT, UPDATE, and DELETE operations in step S105) to the master data file.
[0103] At the same time, the database releases all row locks, table locks, and other resources held by the transaction.
[0104] After a successful submission, the system's internal transaction management module marks the connection as available and may return it to the connection pool. At this point, all data changes officially and permanently take effect and become visible to other concurrent transactions.
[0105] If the global status flag is "failure" (i.e., at least one instruction failed to execute), the transaction management module sends a ROLLBACK instruction to the database server through the database connection bound to the current transaction. Specifically, this includes: After receiving the ROLLBACK instruction, the database server will use the transaction log to undo all modifications made within the current transaction. Regardless of how many data change statements have been successfully executed before, the database will use its recovery mechanism to accurately restore the relevant data rows to their state before the start of the current transaction.
[0106] At the same time, the database releases all lock resources held by the transaction.
[0107] After the rollback is complete, the system's internal transaction management module also handles the connection. At this point, from the database's perspective, the synchronization operation is as if it never happened, and data integrity is absolutely guaranteed.
[0108] In step S107, a synchronization report is generated, which includes the execution results and conflict information.
[0109] This step is the final embodiment of the transparency and traceability of the operation in this invention. Its purpose is to provide the user with a structured and comprehensive synchronous report, regardless of whether the transaction is committed or rolled back in step S106, clearly displaying the complete execution result, detailed status, and any abnormal information of this operation. This solves the problems of opaque operation results and difficulty in diagnosing failure reasons in the prior art, upgrading the system from black-box operation to white-box feedback, greatly improving user experience and troubleshooting efficiency.
[0110] In some embodiments, step S107 is executed after step S106 is completed, and is handled by the report generation module, including report data structure initialization, data collection and population, conflict information processing, and report formatting and output, specifically: First, instantiate a SyncReport object. This object is a composite data structure containing multiple structured fields, used to hold the final result. The main fields include: overallStatus: An enumeration value, such as SUCCESS (all succeeded), PARTIAL_SUCCESS (may exist in non-atomic mode), or FAILED_WITH_ROLLBACK (failed and rolled back).
[0111] transactionCommitted (Whether the transaction has been committed): Boolean value, directly reflecting the decision result of step S106.
[0112] totalInstructions: The total number of instructions processed in this synchronous operation.
[0113] successfulCount (number of successes) and failedCount (number of failures).
[0114] conflictList: A list that stores details of all detected conflicts.
[0115] executionSummary: A list or map that optionally includes a brief execution result for each instruction (such as sequence number, UID, Action, status).
[0116] The report generation module collects and integrates runtime information from previous steps, specifically: Collection from the instruction list traversal process (step S105): During the execution loop of step S105, the system has maintained or recorded the execution status (success / failure) of each instruction and the specific reason for failure (such as optimistic locking conflict, non-existent UID, etc.) in real time. This information is then summarized.
[0117] Collect from the conflict detection unit (step S105): all conflict details detected in the optimistic locking verification (including the conflict's UID, expected version number and corresponding data content, and the current database version number and corresponding data content), which have been temporarily stored when the conflict occurs.
[0118] Collect from the transaction management module (step S106): The final state of the transaction (committed / rolled back) is obtained.
[0119] In some embodiments, if a conflict list exists and the transaction has been rolled back, the report generation module enhances each conflict details object to generate more actionable diagnostic information, specifically: The algorithm uses a difference comparison algorithm (such as a text-based difference algorithm or a field-by-field comparison of structured fields) to compare the expected data content stored in the conflict record with the current data content in the database. This is not just a comparison of version numbers, but delves into the differences in content of business fields (such as title, steps).
[0120] The comparison results are then converted into easily understandable descriptive text or structured difference tags. For example, the changed parts are highlighted in HTML format, or a field like "Title" is generated: the expected value is "Login Functionality Test," and the current value is a description of the "Login Functionality Test (V2.0)."
[0121] The generated detailed discrepancy information is incorporated as part of the conflict details object and ultimately integrated into the conflict list of the synchronization report object.
[0122] Corresponding to the above method, the present invention also provides a non-destructive synchronization system for test cases based on template instructions and atomic transactions, including a processor, a memory, and a computer program / instructions stored in the memory. The processor is used to execute the computer program / instructions, and when the computer program / instructions are executed, the system implements the steps of the aforementioned method.
[0123] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned method. The computer-readable storage medium may be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, floppy disk, hard disk, removable storage disk, CD-ROM, or any other form of storage medium known in the art.
[0124] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.
[0125] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.
[0126] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.
[0127] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.< / instruction>
Claims
1. A non-destructive synchronization method for test cases based on template instructions and atomic transactions, characterized in that, The method includes: Receive a structured template file, which contains at least one data record row. Each data record row includes at least an operation instruction field and a unique identifier field. The operation instruction field is used to indicate the type of operation to be performed on the test case corresponding to the data record row. The operation type includes create, update, delete, or reorder. The structured template file is parsed to generate an instruction object corresponding to each data record row, forming an instruction list; Based on the unique identifier field of each instruction object in the instruction list, the corresponding test case records are pre-queried from the database, and a hash mapping with the unique identifier field as the key is constructed in memory; Start a database transaction; Iterate through each instruction object in the instruction list and perform corresponding data operations based on the operation instruction field of the instruction object and the hash mapping: if the operation instruction field indicates creation, insert a new test case record into the database; if it indicates update, locate the corresponding test case record from the hash mapping based on the unique identifier field, verify the version information is consistent, and then perform the update; if it indicates deletion, locate and delete the corresponding test case record; if it indicates reordering, update the order values of multiple test cases in batches according to the sorting algorithm. If all instruction objects are executed successfully, the database transaction is committed; otherwise, the database transaction is rolled back. Generate a synchronization report, which includes the execution results and conflict information.
2. The non-destructive synchronization method for test cases based on template instructions and atomic transactions according to claim 1, characterized in that, Based on the unique identifier field of each instruction object in the instruction list, the corresponding test case records are pre-queried from the database, and a hash mapping is constructed in memory, including: Before initiating the database transaction, a batch query is initiated to the database to retrieve test case records associated with all unique identifier fields in the instruction list; The retrieved records are stored in the server memory using the unique identifier field as the key, forming the hash map, which is used for quick location during subsequent data operations.
3. The non-destructive synchronization method for test cases based on template instructions and atomic transactions according to claim 1, characterized in that, After verifying that the version information matches, perform the update, including: Extract the expected version number from the current instruction object; The current version number of the target test case recorded in the database is obtained through the hash mapping. Compare the expected version number with the current version number; if they match, perform a database update operation and update the version number recorded in the target test case; if they do not match, determine that there is a version conflict, stop the execution of the current instruction and record the conflict information.
4. The non-destructive synchronization method for test cases based on template instructions and atomic transactions according to claim 3, characterized in that, The method further includes: When a database transaction is rolled back due to a version conflict, a conflict report is generated and output. The conflict report includes at least a unique identifier field for the test case that caused the conflict, and the data content differences between the expected version number and the current version number.
5. The non-destructive synchronization method for test cases based on template instructions and atomic transactions according to claim 1, characterized in that, Update the order values of multiple test cases in batches according to the sorting algorithm, including: Collect all operation instructions into a reordered instruction object; Based on the new order value specified in the instruction object, a set of final order values that are non-repeating and maintain relative order are calculated for all affected test cases using the gap sorting algorithm; The final sequence value is atomically written to the corresponding test case record through a batch database update operation.
6. The non-destructive synchronization method for test cases based on template instructions and atomic transactions according to claim 1, characterized in that, The structured template file is a spreadsheet file.
7. The non-destructive synchronization method for test cases based on template instructions and atomic transactions according to claim 6, characterized in that, The operation instruction field is identified as the "action" column in the spreadsheet file, and the unique identifier field is identified as the "uid" column.
8. The non-destructive synchronization method for test cases based on template instructions and atomic transactions according to claim 1, characterized in that, When the operation instruction field indicates creation and the corresponding unique identifier field is empty, inserting a new test case record into the database includes: A system-globally unique identifier is generated for the new test case record, and this identifier is stored as the value of the unique identifier field.
9. A non-destructive synchronization system for test cases based on template instructions and atomic transactions, comprising a processor, a memory, and a computer program / instructions stored in the memory, characterized in that, The processor is configured to execute the computer program / instructions, and when the computer program / instructions are executed, the system implements the steps of the method as described in any one of claims 1 to 8.
10. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method as described in any one of claims 1 to 8.